レガシーシステムに挑む! 既存業務の把握から逃げない再構築の極意

今回取り上げるのは、リクルートグループで人材派遣ビジネスを展開する、スタッフサービス・ホールディングス（以後、スタッフサービス）の業務系システム再構築プロジェクトです。

スタッフサービスでは、事業成長の過程で会社や事業の統合を繰り返してきました。その結果、複数の業務システムが個別で運営され、首都圏と地方拠点でもシステムが異なる状況でした。それぞれで採用されているアーキテクチャも、システム化されている業務範囲も異なり、いわば「継ぎ接ぎのシステム」により事業運営を行っていたのです。

そんななか、それぞれのシステムでEOSL（End Of Service Life）が連続して発生しており、情報システム部門では対応が迫られている状況でした。

再構築にはまず既存把握が王道。でもどうやるか

そこで、業務系システムを再構築するプロジェクトが立ち上がりました。日本最大級の人材派遣ビジネスを担うスタッフサービスの業務システムが止まってしまうと、大きな売上影響があるだけでなく、顧客の皆さまに多大な迷惑をお掛けしてしまうこと、また開発規模も非常に大きく難易度が高いことから、リクルートテクノロジーズからプロジェクト推進部が参画して担当することになりました。

一方、このタイミングで全国5つのエリアごとに分かれていた業務を統一し、業務の生産性向上や運用コストの削減を図る千載一遇のチャンスでもありました。そこで、下図のように、5つのシステムを統合し刷新する計画を立案しました。

• 図1：今回のプロジェクトの背景と課題

ところが、リクルートにおける大規模開発の経験において、既存システムの再構築、特に業務システムの再構築は度重なる苦戦を強いられていました。当時はその打開策が明確になっているわけではなく、過去の苦戦から新たな仮説を立てて大きなチャレンジに取り組むプロジェクトにもなりました。

過去に苦戦した再構築プロジェクトをひも解くと、業務が正しく把握できておらずテストやリリース後に業務トラブルを招いているケースが見受けられました。業務把握の重要性は理解していたものの、何からどうやって行うべきなのかという手法が確立できていなかったのです。

これまでのやり方から見えてきたのは、以下の2つの課題でした。

1. 既存の設計書仕様書は存在しないか、あっても正しくない
2. 既存の知見者は断片的な知識しか持っていない

そこで、現在動いているシステムのソースから仕様を読み解くこと（いわゆる「リバースエンジニアリング」をすること）でシステム仕様だけでなく、その先の業務仕様を漏らさず正しく再現することができるのではないかという仮説を立てました。取り組むことでしか検証できないと腹をくくり計画し、経営陣と合意をして進めることとなりました(図2)。

• 図2：リバースエンジニアリングが必要な理由

想定通り進まない既存要件の把握。把握すべきものは果たして何か

リバースエンジニアリングを中心とした現行業務やシステム仕様の把握は、要件定義前にする必要があり、新たに「調査フェーズ」を設置して推進しました。

調査フェーズとして、既存システムのソースから設計書を整理し、すべての仕様を把握しに行きました。始めのうちは順調に進捗していると思われました。

進捗が半分を越えようとするころ、リバースエンジニアリングを担当するチームリーダーから「これは何のためにやっているのか? リバースした内容を設計書にまとめて何がわかるのか?」とエスカレーションが上がりました。出来上がった設計書を見て気づいたのは、「システムの内部仕様がわかっても、その仕様が何のためのものか業務や目的が見えてこない」ということでした。

このタイミングで、当初の仮説にはやはり無理があり、システムの「処理」はあくまで「処理」でしかないという結論に至りました。

例えば、「あるイレギュラー業務をした時だけ、仕事内容のテーブルに特別な更新をしている」という処理があったとします。「なぜそのような処理をしているのか」「イレギュラー業務とは何なのか」を把握しない限り、要件を明らかにすることはできません。つまり、既存業務を踏まえた上でないと、本当に必要な新システムの要件は描けないのです。

しかし、この調査フェーズでの検証を経たことで、システムの処理を起点に「なぜ?」と目的に昇華させて、業務部門のユーザーにヒアリングを行うような、既存システムと既存業務の“要件定義”をしないといけないことに気づくことができました(図3)。

• 図3：抽出する要件は何か?

既存業務背景や目的把握のためにプロセスや体制を見直す

そこで、方針転換をして、ソースのリバースを機械的に実施するプロセスと体制を見直しました。要件定義ができるシステムエンジニア(SE)をそろえ、業務部門のユーザーをアサインしてもらい、双方が協力して”既存“に対する要件定義を行う体制を構築しました。

SEメンバーは、ソースやデータモデルを見ながら、業務目的が不明な点を洗い出し、業務部門のユーザーにヒアリングして、業務フローや要件定義書を整理することで、ようやく業務の全体像を把握することができました。

その後は、新システムの要件定義、開発からC/Oまで安定して進めることができました。

学び：既存業務の把握に近道はない、今後も続く再構築との戦い

最終的に、プロジェクトにかかった工数は650人月、期間は15カ月に及びました。調査フェーズは後に振り返ると、プロジェクト全体の10%のコストをかけ、期間も4分の1に上るものとなりました(図4)。

• 図4：プロジェクトの調査工数のサマリ

今後の再構築やパッケージ導入のプロジェクトに対峙する際、実際どこまで既存把握をやるのか、どれくらいかければよいのかという論点は常にあります。設計書が必ずメンテナンスされている場合や、要件定義書が残っている場合はすべてソースから掘り起こすことも必要はなく、プロジェクトの特性や状況に応じた最適化を考える必要があります。

このプロジェクトでの経験をもとに、プロジェクト推進部では大きく以下の2点について最適化を行っています。

調査フェーズの磨き込み

何を調査・把握できればゴールなのか、最適なプロセスとはどんなものか、求められるスキルセットやチーム編成は、といった内容を磨き続けコストや期間の短縮を目指しています(図5)。

• 図5：調査フェーズプロセスの振り返り

再構築手法の分類と最適化

主要な再構築手法として「リビルド」「リライト」「リホスト」の3つが存在します。今回のプロジェクトにおいて活用したリバースエンジニアリングや業務仕様のトレースが求められるプロジェクトは、リビルドやリライトのパターンに当てはまります。リビルドを行うプロジェクトであっても、要件の変更具合や有識者の有無などに応じて、どこまでどのような調査を行うかが変わります。

今後も既存システムの再構築は、われわれの頭を悩ます課題であることに違いありません。ですが、今回得た知見をベースに、より高次な気づきを見出して、さらなるベストプラクティスに仕上げて行きたいと思います。