リスクが高くなり過ぎて、カットオーバーを大幅延期：事例に学ぶシステム刷新（4）（1/2 ページ）

現在、システム全面刷新と大規模ERPパッケージ導入のプロジェクトに取り組んでいるゴルフダイジェスト・オンライン。前回はERPパッケージ製品を選定過程などを説明した。今回は、システム刷新プロジェクトの進行状況を紹介する。

[吉村哲樹，＠IT]

　前回まで、株式会社ゴルフダイジェスト・オンライン（以下、GDO）がシステム全面刷新プロジェクト「G10プロジェクト」を立ち上げることになった背景を紹介してきた。今回からはいよいよ、同プロジェクト発足後の推移を順次紹介していく。

マルチベンダ体制を、あえて採用

　G10プロジェクトは、GDO社内にあるほぼすべての業務システムと基幹システムの全面刷新をゴールにしている。そのため、複数のプロジェクトが同時平行で幾つも走る格好となる。その体制は、以下の通りだ。

　まず各業務システムに関しては、それを実際に使用する各業務部門がプロジェクトオーナーとなり、それぞれ個別にプロジェクトを進めていく。こうした個別プロジェクトの数は、後述する「サブプロジェクト」も含めて、全体で13にも上った。その内訳は以下の通りだ。

プロジェクト名	プロジェクト内容
G10-MS	ERP、情報流通基盤
G10-GR	物販／eコマースシステム
G10-GS	ゴルフ場予約システム
G10-MM	会員データベース基盤
G10-MC	サイトデザイン
G10-CS	カスタマーサポートシステム
G10AD	メルマガ配信システム
メール	メルマガ配信システム
現行改修	現行システムの改修
移行推進	システム移行計画の策定・手配・実行
インフラ	新システムのためのインフラ構築
マスタ	マスタデータ設計
インターフェイス	システム間インターフェイスの設計・実装

　各プロジェクトは、それぞれが独自にRFPを作成し、開発ベンダの選定を行う。そのため、G10プロジェクト全体として見た場合は、複数の異なるベンダが参画する「マルチベンダ体制」となった。

　通常、G10プロジェクトのように大規模で複雑な案件の場合、単一ベンダに一括して発注した方がリスクもコストも低減できるとされている。同社はなぜ、あえてマルチベンダ体制を採用したのだろうか？ 同社上級執行役員・コーポレートユニット担当 兼 システム戦略担当の大日健氏は、その理由を次のように説明する。

　「本当は、要件定義から設計、開発、テスト、運用までを一括して同じベンダに頼むのが現実的だし、そうしたいと思っていた。しかし、G10プロジェクトは、互いに関連する複数のプロジェクトを同時平行で進めるマルチプロジェクト体制を採っていたため、全体として見ると非常に大規模かつ複雑で、開発リスクが極めて高くなる。従って、プロジェクトの節目ごとにチェックポイントを設けて、その都度進め方を見直せるようにしたかった。これが、単一ベンダにすべて一括して丸投げするやり方だと、途中で見直しややり直しがきかなくなってしまう。そこで、個別プロジェクトごとに別々のベンダに発注するマルチベンダ体制を採ることにした。また、各ベンダに対する発注も、要件定義、設計、開発と分けて行う」

　またこのように、複数のプロジェクトがそれぞれ個別に、異なるベンダの下で開発を進める場合、プロジェクト相互の調整作業がなかなかスムーズに運ばないことが多い。G10プロジェクトはそもそも、各業務システム間で密接にデータ連携を行えるようにすることが目的であった。従って、すべてのプロジェクトを横断的に統括し、それぞれのシステムが最終的にうまく連携できるよう、データ形式やインターフェイスの仕様を調整する役割を誰かが担わなくてはいけない。さらに、G10プロジェクト全体のスケジュール調整・管理も行う必要がある。

　そのため、G10プロジェクト全体を統括し、各個別プロジェクト間の調整に当たる組織として、「G10プロジェクト推進チーム」が設けられた。同チームの主要メンバーは、同社の情報システム部門の人員、およびアビームコンサルティング（以下、アビーム）のコンサルタントで構成された。さらに各個別プロジェクトにも、アビームのコンサルタントがPM支援として参加することになった。

　こうして、マルチプロジェクト体制における開発リスクを低減させるため、GDOはあえて複数のベンダと組み、さらに工程ごとに分けて発注を行うという方法を採った。こうすることで、プロジェクトに対する自社のコミットを強化し、リスクをきちんと監視できる体制を整えようとしたわけだ。さらに、マルチプロジェクト・マルチベンダ体制の弱点であるプロジェクト間連携も、PMOの体制を強化し、さらに社外のコンサルタントの支援を仰ぐことにより補完した。