みなさまこんにちは。ソニー・ミュージックエンタテインメントのいっくんです。
以前、グループウェアアプリケーションを「Microsoft 365」へマイグレーションする「グループウェア刷新プロジェクト」を進める過程で、内製チームを立ち上げた経緯について記事にしました。それから約2年、さまざまな苦労を経て、ようやくすべてのグループウェアアプリケーションのリニューアルを終えました。今回は、そんなプロジェクトの過程や成果、学んだことについてお伝えできればと思います。
300本のグループウェアアプリケーションを刷新せよ
以前まで運用していた先代グループウェアは、別のグループウェア基盤で稼働していました。この基盤上で、「会議室予約」「ファイル管理」「社内掲示板」など一般的なグループウェアの機能を持つアプリケーションから、ワークフローやステータス管理を内包する複雑な業務アプリケーションまで、大小さまざま、300本近いアプリケーションが稼働していたのです。従業員の大半が利用することから、システム部門が運営するアプリケーションの中でも比較的注目度の高い領域です。
そんな先代グループウェア基盤は、刷新プロジェクト開始時点で稼働から10年以上が経過していました。途中でインフラ更改は行いましたが、300本という膨大な数のアプリケーションに与える影響を考慮して、グループウェア基盤のソフトウェアバージョンアップは見送っていました。これは、大半のアプリケーションが基盤の標準機能をカスタマイズしたアプリケーションだったためです。現状維持のために多大な検証・改修コストを費やすわけにはいかず、判断自体は妥当なものでした。
時は流れ、当社でも新型コロナ禍を経てリモートワークが定着し、Microsoft 365の活用が進みました。そうした中、Microsoft 365がグループウェアの基本機能やローコード開発プラットフォームを備えていることを鑑み、Microsoft 365を移行先の前提とした検討を開始。グループウェア基盤のライセンスコストの削減やサポート切れへの対応、改修要望への対応スピードアップを目的とした「グループウェア刷新プロジェクト」が立ち上がりました。
300本は多すぎる！
とはいえ、300本ものアプリケーションすべてを刷新するには、膨大な時間と工数がかかります。そこで開発対象を絞り込むべく、まずは棚卸と現状分析に着手しました。恥ずかしながら、管理者が誰なのかわからないようなアプリケーションがいくつかあり、社内の人脈を頼りながら、1つひとつコンタクトを取って現状をヒアリングしていきました。
| 工程 | 目的 | 結果 |
|---|---|---|
| 1次ヒアリング | 継続利用の意思・必要性の確認 | 50アプリ廃止 |
| 2次ヒアリング | 移行先の選定とMicrosoft 365適合判断 | 40アプリ廃止、80アプリ開発 |
※廃止時は、必要に応じてデータのアーカイブを取得
2段階のヒアリングを経て、計90本のアプリケーション廃止を決定しました。1次ヒアリング段階で判断保留、“とりあえず”継続利用と判断されたアプリケーションも、段階を踏むことで廃止の判断を下すことができた印象です。残ったアプリケーションについては、すでに活用が進んでいた他の情報共有サイトやSaaS等への移管・統合等の検討を行い、最終的に80本のアプリケーションが新グループウェアとしての開発・移行対象となりました。中には、プロジェクト終盤まで移行方針が決まらず議論を続けたアプリケーションもありましたが、それも良い経験だったと思います。また、計画と並行して、開発コスト削減やシステム部門の内製力向上を狙い「内製チーム」を設立しています。こちらの詳細は、以前の記事をご覧ください。
開発のゆくえ
発足したばかりの内製チームがいきなり開発を担うのは難しいと判断し、パイロットアプリケーションを選定して、ビジネスパートナーベンダーに開発を委託しました。開発の過程で少しずつ開発標準を確立しながら、後続の開発計画を策定。難易度が比較的低いと想定されるアプリケーションを序盤の開発対象に据え、内製開発を本格的にスタートさせています。
開発は、現状調査と要件定義、データ移行の各工程をビジネスパートナーベンダー、その間の設計・実装・各種テストとリリースを内製チームが主導するハイブリッドな体制で行いました。工程間の引継によるオーバーヘッドが発生するいびつな体制ではありますが、先代グループウェア基盤の運用をビジネスパートナーにお任せしていたこともあり、分業する方がスムーズに進行できると判断しました。プロジェクト後半には、内製チームがすべてを主導する開発パターンもいくつかのアプリケーションで採用しました。
なおこの際、「シンプルかつコンパクトな移行」「Microsoft 365 E5に含まれない有償ライセンスサービスを極力使わない」という移行方針を掲げました。前者は、要件定義工程にてプロトタイプを作成しながら進行する形式とし、なるべく手戻りが出ないように工夫しています。実際に触れられる画面があることでエンドユーザーとの間の認識齟齬が減り、従来のスクラッチ開発に比べて実装フェーズでの手戻りが少なく開発できたと感じています。プロトタイプが簡単に作れる点は、ローコード開発ツール最大のメリットと言えるでしょう。
後者の有償ライセンスサービスに関しては、ランニングコストを抑制するために利用者単位での課金が発生するライセンスを必要としない実装方法を追求し、具体的にはDataverseやPower Automate Premiumコネクタの採用を見送りました。ただ、これは今回ターゲットとなったアプリケーションの特性や移行方針に合わなかったというだけで、利用者数の少ないアプリケーションを中心に高い費用対効果を発揮することがあり、ケースバイケースで判断するのが適切かと思います。
足掛け3年でマイグレーションを完遂
パイロットアプリケーションのリリースから2年少々、プロジェクト発足から足掛け3年でようやくすべてのアプリケーションの移行を終えました。苦労しながらも手応えを感じた序盤、思うように開発ペースと品質が上がらなかった中盤、鞭を入れて納期厳守で取り組んだ終盤。決して平坦な道のりではありませんでしたが、無事に予算内に収めることができ、メンバーの成長を随所に感じられる良いプロジェクトになったと考えています。先代グループウェア基盤がクローズしたのは、2024年末の最終営業日のこと。先代を作り上げた先輩と共に静かに見守り、そして感傷に浸りました。
なお、副次的な成果として、プロジェクトの進行と共に、部門内では内製に対する期待や需要が高まりました。本プロジェクトと並行して他のアプリケーション開発を行ったほか、内製チーム外のメンバーがMicrosoft 365をはじめとするローコード開発ツールにチャレンジする姿が見られるようになるなど、相乗効果が生まれています。プロジェクトを完遂した以上に、組織としての成長を実感できたのがうれしかったですね（支えてくれたメンバー、ビジネスパートナーのみなさまには心より感謝を申し上げます。あらためまして、ありがとうございました！）。
こうして「グループウェア刷新プロジェクト」は無事に幕引きとなりました。開発過程はもちろんのこと、実運用に入ってからも、さまざまな課題や壁にブチ当たり、そして乗り越え、時に遠回りをしました。技術的にハマったポイントも多数ありましたので、そのあたりはまたの機会に記事にできればと思っています。
それではまた！
