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

[吉村哲樹，＠IT]

膨大な数に上ったシステム間連携インターフェイス

　2009年12月にG10プロジェクトが発足した後、まず真っ先に行われたのが「グランドデザイン」の作業だった。これは、各個別システムの要件定義や設計を行う前に、すべての個別システムを合わせた社内システム全体の大まかな構成を設計し、課題点を洗い出す作業である。

　前回紹介した通り、G10プロジェクトが発足した時点で、基幹システムにはSAP ERPを導入することが既に決まっていた。そこで、SAP ERPと各業務システムとの連携部分を中心に、どのようなシステム間連携インターフェイスを設ければ良いのか、机上ですべて洗い出した。この作業に中心メンバーとして携わった同社 IT戦略室 室長の志賀智之氏は、次のように語る。

　「グランドデザインフェイズで各システム間の連携インターフェイスの定義を行ったところ、全体で500〜600ものインターフェイスが必要になることが判明した。また、SAP ERP側にシステム間連携のためのカスタマイズを施すことは、極力避けたかった。そのため、インターフェイスの部分はほかのプロジェクトとは切り離して、きちんと検討する必要があった」

　志賀氏らの動きは早かった。

GDO 上級執行役員・コーポレートユニット担当 兼 システム戦略担当の大日健氏 （左、IT戦略室 室長の志賀智之氏（右

　早速、システム間連携のインターフェイスだけを個別に検討する「インターフェイスチーム」を、G10プロジェクト内のサブプロジェクトとして新たに発足させた。同チームは早速、それぞれのインターフェイスに適した連携手法の検討を開始する。

　SAP ERP側はもちろんのこと、業務システム側もなるべくインターフェイス開発の負担を減らした。また、膨大な数に上るインターフェイスを、なるべくシンプルに管理したい。こうした要件を満たすため、EAIツールを新たに導入することが決まった。

マスタデータ設計のサブプロジェクトも設立

　2010年2月に各プロジェクトでベンダ選定が終わり、要件定義作業が始まって間もなく、もう1つの新しい課題が見つかった。マスタデータに関する解釈の不一致だ。

　本連載の第2回でも触れたように、GDOは2000年の創業以来、マスタデータを一度も整備することなくビジネスを拡大させてきた。しかしそれ故に、ビジネスの実態とITシステムとの間に食い違いが発生している状況だった。

　この課題を解決するため、G10プロジェクトではまず、各業務システムを連携させるための前提条件として、マスタデータをきちんと構築する予定だった。しかし、いざ作業を始めてみると、これまで自社内でマスタデータを一度も持ったことがないため、「そもそも、自分たちの業務に必要なマスタデータとは何か？」という議論から始めなくてはいけなかった。これは、当初予想していた以上に困難な作業となった。

　「各プロジェクトでは、『マスタデータを整備しなくてはいけない』という気付きはあったものの、マスタデータに対するイメージがプロジェクトごとにばらばらだった。これを調整して、統一したデータ構造やコード体系を定義しなくてはいけない。しかも、マスタデータの仕様が決まらないことには、ほとんどのプロジェクトの要件定義が先に進まない。従って、ほかの作業に先駆けて真っ先にマスタデータの定義を行う必要があった」（志賀氏）

　志賀氏らはここでも、マスタデータに関する検討を集中的に行うためのサブプロジェクト「マスタチーム」を即座に立ち上げ、データベース設計の作業を一気に進めた。その甲斐あって、各プロジェクトの要件定義作業の遅れを最小限に抑えることができた。

　このように、新たな課題が見つかった際に、独立した対策チームを設けて集中的に討議することは、たとえ一時的には工数が増えることになったとしても、後々の工程で手戻り作業が発生するリスクを考えれば、効果的な方法だと言えよう。こうした柔軟なプロジェクト運営を可能にするには、G10プロジェクトにおける推進チームのように、すべての個別プロジェクトを横断的に統括する組織を設け、それ相応の権限を付与しておくことが必要になるのだ。

要件定義が終わった時点でスケジュールを大幅見直し

　個別の課題検討だけでなく、スケジュールに関しても大日氏と推進チームがG10プロジェクト全体の管理と調整を行った。しかし、ことスケジュール調整に関しては、さまざまな紆余曲折があったようだ。

　2009年12月の同プロジェクト発足当初は、全システムの開発作業を2010年中に完了させ、2011年1月1日に一斉にカットオーバーする予定だった。しかし、各プロジェクトの要件定義が完了した4月末時点で再度スケジュールを検討したところ、当初の予定ではあまりにもリスクが高過ぎることが判明した。そのため、カットオーバー時期を大幅に伸ばすことになった。

　こうした判断の裏には、開発リスクに対する同社独自の考え方があった。この辺りについては、次回詳しく紹介する。

「事例に学ぶシステム刷新」バックナンバー

• リスク低減を最優先したため、期間とコストは倍に
• リスクが高くなり過ぎて、カットオーバーを大幅延期
• CIOが経営を説得し、最もコスト高のSAP ERPを導入
• 最優先事項は“絶対ローンチさせること！”
• GDOが大規模システム刷新を決意したワケ