リスク低減を最優先したため、期間とコストは倍に：事例に学ぶシステム刷新（5）（1/2 ページ）

現在、システム全面刷新と大規模ERPパッケージ導入のプロジェクトに取り組んでいるゴルフダイジェスト・オンライン。前回は、システム刷新プロジェクトの進行状況を紹介した。今回は、プロジェクトが遅延した原因や、その際に同社が何を優先したかなどを紹介する。

[吉村哲樹，＠IT]

　2009年12月、株式会社ゴルフダイジェスト・オンライン（以下、GDO）は、社内のほぼすべての業務システムと基幹システムを一斉に刷新する「G10プロジェクト」を発足した。同プロジェクトは、各システムごとに計13の開発プロジェクトを同時平行で走らせ、それらを最終的にはビッグバン方式で一斉に稼働開始させようという大胆な試みだ。

　当初は、2010年中にすべてのプロジェクトの開発を完了させ、2011年の1月1日に一斉に稼働開始する予定だった。同社上級執行役員・コーポレートユニット担当 兼 システム戦略担当の大日健氏は、この当初計画について次のように説明する。

　「1月1日という当初のカットオーバー予定日は、会社の会計処理上の節目であり、またゴルフのオフシーズンでトランザクションも少ない時期なので、ビジネス上のインパクトが少なく済む。そのため、システムの入れ替えを行うには都合が良かった」

　しかし、結論から先に言うと、同社はこの予定を丸々半年延ばして、2011年7月1日のカットオーバーにスケジュールを大幅変更した。この大胆なリスケジューリングの背景には、大日氏をはじめとしたG10プロジェクト関係者のさまざまな意図があった。

「五月雨方式」のリスク

　前回紹介した通り、各システムの開発プロジェクトは、そのシステムを実際に使う業務部門がプロジェクトオーナーとなり、それぞれ独自に開発ベンダを選定した。2010年4月に各プロジェクトで要件定義の作業が終わり、その時点で2011年1月1日カットオーバーを前提とした設計・開発フェイズのスケジュールが、各ベンダから提出された。大日氏はこれらを一目見て、「これはまずい。このスケジュールではリスクが高すぎる」と即座に判断したという。

　「各ベンダとも、個別の機能やモジュールごとに設計・開発・テストの作業を五月雨式に行う計画を出してきた。確かにこうした進め方なら、作業要員の稼働率を最大限に引き上げられるので、開発に要する期間やコストを圧縮できるように見える。しかし、われわれにとっては逆にリスクが高いと判断した」（大日氏）

　作業を「五月雨式に行う」とは、例えばこういうことだ。

　設計担当者は、ある機能の設計作業が終わったら、その機能の開発とテストの完了を待たずに、すぐにほかの機能の設計に着手する。開発担当者も、あるモジュールの開発が終わったら、そのテストが完了するのを待たずに別のモジュールの開発にすぐに着手する。テスト担当者も同様だ。

　このように、各個別機能やモジュールの設計・開発・テスト作業を少しずつ重ね合わせながら、入れ子式にスケジューリングすることで、リソースを最適化することができる。結果として、プロジェクトの期間やコストを圧縮できるという考え方だ。

手戻り作業のリスクを回避する

　この方法は一見すると、プロジェクトの発注側にとっても受注側にとっても良いことずくめのように思える。しかし、そこには大きな落とし穴が潜んでいる。同社 IT戦略室 室長の志賀智之氏は、次のように述べる。

　「設計と開発を五月雨式に同時平行で進めていくやり方だと、発注する側は設計と開発の作業双方に対して一括で投資し、コミットせざるを得ない。そうなると、もし万が一設計作業が失敗に終わったとしても、途中でストップを掛けることができない。また、開発作業を始める前に、各プロジェクト間でシステム連携インターフェイスの調整と確認を横断的に行う必要がある。これをきちんとやらないと、総合テストで各システムを実際につなげたときに、仕様漏れが山ほど出てくるのは目に見えている。しかし五月雨方式だと、設計と開発が同時平行で進んでしまうため、すべてのプロジェクトで同時にインターフェイス設計をレビューする機会を設けることができない」

GDO 上級執行役員・コーポレートユニット担当 兼 システム戦略担当　大日健氏

　G10プロジェクトは、13の開発プロジェクトの集合体だ。各プロジェクトで開発するシステムが最終的にお互いにきちんと連携して動作するためには、設計フェイズが完了した時点でそれぞれの連携インターフェイスの仕様をすべて机上に載せて、すり合わせる必要がある。これを怠り、総合テストの段階になって初めてインターフェイス仕様の不具合が発覚した場合、そのリカバリには膨大な工数を要することになる。大日氏も次のように述べる。

　「当然、膨大な手戻り作業が発生するし、問題の切り分けも困難になる。また、たとえ問題の切り分けができたとしても、連携する双方のシステムのどちらに非があって、どちらを修正するのかという話になると、お金も絡んでくるので一層ややこしくなる。そんなことを総合テストの段階でやっていては、カットオーバーの時期がいつまで経っても確定できない。カットオーバーをコミットできないようなプロジェクトに金を出すことは、経営陣は到底了承しないし、そもそもシステムをローンチさせることが絶対条件なので、現場としてもこうした事態はなるべく避けたい」（大日氏）

　また、当初スケジュールでは総合テストに割く時間も、各プロジェクトごとにまちまちだった。例えば、あるプロジェクトでは10月から12月までの3カ月間を総合テストに割り当てているのに対して、別のプロジェクトでは1カ月弱しか割り当てられていないといった具合だ。

　総合テストは本番環境を前提としたものなので、すべてのシステムが開発を完了し、連携できる状態になっていることが絶対条件だ。従って、結局は最も遅れてテスト準備が完了するプロジェクトのスケジュールに、全体のスケジュールを合わせざるを得ないのだ。

　逆に言えば、そのプロジェクトがほんの少し遅れただけでも、ほかのプロジェクトすべての進ちょくに影響が及び、途端にG10プロジェクト全体のカットオーバーが危うくなってしまう。