リクルートグループ全体で利用される基幹業務システムの刷新

今回紹介するのは、リクルートグループ全社で利用される、とある基幹業務システムのリプレース案件です。もともとこのシステムは、かなり前にパッケージ製品を使って構築された後、10年間にわたり利用され続けてきたものです。

その間、細かな機能拡張を繰り返しながら延命してきたものの、さすがに老朽化が目立ち、かつパッケージ製品の保守切れが近付いてきたため、別のパッケージ製品を使って全面的に再構築することになりました。

この再構築プロジェクト、結果だけを見れば無事予定通りカットオーバーを迎えることができ、出来上がったシステムの品質も極めて優れていました。ただし、カットオーバーまでの道のりは極めて過酷で、予定よりかなり多くの人員をつぎ込んで何とかカットオーバーまでたどり着くことができた、というのが実情です。

そこで今回は、このプロジェクトがなぜそのような状況に陥ったのかを振り返るとともに、同じ轍を踏まないために、プロジェクトマネジメントにおいてどのようなポイントをおさえるべきなのか考察してみたいと思います。

プロジェクト開始当初から数々の困難に直面

本プロジェクトは、要件定義の段階でいきなり暗礁に乗り上げてしまいました。まず、現行システムの仕様を誰も把握できていなかったため、業務やシステムの「あるべき姿」を正確に定義できませんでした。

10年前に構築を手掛けたメンバーは誰一人として残っていませんでしたし、構築が完了した後も細かな増改築が繰り返されており、その経緯を知る人間もドキュメントも残っていません。スクラッチ開発したシステムであれば、設計書やソースコードから仕様を読み解くこともできますが、パッケージ製品は中身がブラックボックスになっているため、これも叶いません。

しかも、フィット＆ギャップを慎重に行って「この製品の機能なら、弊社のニーズを満たせるはずだ」と満を持して選定したパッケージ製品が、要件定義を進めるうちに、そのままでは細かな業務ロジックをカバーできないことが次々と判明しました。その結果、当初は予定していなかったアドオン開発が大量に発生することになりました。

テスト工程においても、現行システムのロジックがブラックボックス化されているため、そもそもどんな動作や出力が正解なのかがわからず、作業が難航することになりました。

また、現行システムから新システムへのデータ移行も難所の1つでした。現行システムでは、パッケージ製品がもともと備えるデータモデルに独自の拡張を加えていましたが、その目的や定義があいまいで、これを読み解いて新システムのデータモデルに適切にマッピングするだけでも膨大な工数を強いられました。

これだけ多くの課題が噴出したら、普通ならいったん立ち止まって、プロジェクトのスケジュールや体制を根本的に見直したいところです。しかし、本プロジェクトは経営からの要請により納期が厳密に定められていたため、期日を伸ばすことが許されませんでした。その結果、上記のような数々の困難を乗り切るために追加人員を大量に投入したり、社内からも援軍として腕利きのエンジニアをアサインしてもらったりなどして、ようやく乗り切ったというのが実情でした。