全社デジタル戦略 失敗の本質

発刊
2025年6月29日
ページ数
232ページ
読了目安
283分
推薦ポイント 4P
Amazonで購入する

Amazonで購入する

システム開発を失敗させないために経営陣がすべきこと
DXに向けた投資が増加している中、多くの日本企業のシステム開発で失敗が発生している。未だにレガシーシステムから脱却できずに、DX化が遅れている企業も多く、今後、システム投資が増える状況にあって、日本企業はどのようにシステム開発の失敗を回避すればいいのか。

システム開発プロジェクトにおける典型的な失敗パターンを解説しながら、プロジェクトを失敗させないために、経営陣がすべきことが紹介されています。多くの日本企業が外部のシステムベンダーに依存している状況において、企業自身がプロジェクト管理するための指針が示されています。

システム開発における罠

DXの領域では、仕様や要件を固めずに、計画→設計→実装→テストのサイクルを短期間で回す「アジャイル型」の開発手法がよく知られている。その際には現場担当者に大胆に権限を委譲し、スピーディーかつ柔軟に開発を進めることが求められる。

一方で、アジャイルに不慣れな日本企業は、大型案件でアジャイルを適用することは避けるのが賢明である。大型案件では、従来のシステム開発で用いられてきた「ウォーターフォール型」、つまり、ゴールを明確に定めて、全体計画を策定し、工程ごとにバトンタッチしていく方式で進めるのがよい。

 

システム開発を進める上で各工程の要諦を押さえておくことは重要だが、経営陣が意思決定する上では、大きく「企画構想」「要件定義」「実装」の3フェーズを意識する必要がある。各フェーズでは、以下のような典型的な落とし穴が待ち受けており、多くの企業がそれにはまってしまっている。

 

①企画構想フェーズの罠

  • 何を成し遂げたいのかが曖昧なまま投資の意思決定をしてしまう
  • 経営層がプロジェクトの中身を理解しないまま、現場主導で進めている
  • システムを利用する事業部門がコミットしないまま、IT部門が突っ走っている
  • 目的を達成するための実現手段の目処を立てないまま要件定義に進む
  • ベンダーの計画をうのみにし、自社として十分な検証をしていない

②要件定義フェーズの罠

  • 細部の議論に終始し、大きな論点の意思決定が行われない
  • 企画構想フェーズで定めた総論に対して、各論について反対の声が上がる
  • スケジュール優先で、要件定義が曖昧なまま次のフェーズに進めてしまう
  • 既存の業務のやり方を見直さずに「現行踏襲」のまま要件を定義してしまう
  • 新しいものをつくるからと「To Be(あるべき姿)」だけを定義して「As Is(現状)」を十分に把握せずに要件を定義する
  • 実装フェーズで必要になる作業の計画策定を後回しにしてしまう
  • 業務のプロセスや機能の仕様ばかりに注力し、データを意識しない

③実装フェーズの罠

  • 要件定義からの仕様変更の発生の見立てが甘い
  • ベンダーの仕事を評価する基準がなく、ベンダーの報告をうのみにする
  • 計画が遅れ、安易にフェーズを雁行する
  • メインベンダー以外の関係者が担う作業の見積もりが甘い

 

プロジェクトにおける失敗対策

失敗は社内では蓋をされてしまうため、海外企業では、ITの知見を持つCIOなどのプロ人材が企画構想、要件定義などの各フェーズの終わりに点検し、このまま突き進んでもうまくいかない、このシステムアーキテクチャでは実現不可能だとストップをかけたり、ベンダーに見直しを命じたりする例もある。当事者以外の人が各フェーズで次に進むかどうかを判断することで、客観的かつ冷静に失敗の芽を摘むことが大事である。

 

進行中のプロジェクトが失敗に片足を突っ込んでいるとしたら、どのように対処すればいいのか。経営陣が積極的に状況を理解しようとしさえすれば、実態を把握することは可能である。プロジェクトからの報告をうのみにせず、第三者目線で検証し、検証結果を踏まえて軌道修正した方がいい。

まず経営面では、プロジェクト責任者は何とかシステムをリリースさせようとするので、目的や効果の意識が薄れ、本来実現すべき内容を矮小化してでもコストと期間を厳守しようとする。従って、当初の目的やROI、対象としたスコープがおざなりになっていないかを、経営側はしっかり点検しなければならない。IT面については、純粋にプロジェクトの進捗、品質、コスト、期間について、ベンダーもしくはプロジェクトから上がってくる報告を妄信せずに評価することが重要である。

 

具体的な検証ポイントは以下の通り。

①目的や効果は明確か、当初掲げたものから逸脱していないか

当初の目的・効果は変わっていないか、投資対効果がまだ損なわれていないかと常に問い続けなければならない。プロジェクト外の部門が外部コンサルタントを雇って第三者評価を行なったりすることが有効。

 

②中身(品質、コスト、進捗)に問題はないか

各工程が終了する段階では、次工程への先送り事項が多くないか、重い負担となっていないか。QCDに影響をもたらす、よく起こりがちな事象に注目する。

  1. 安易な先送りや作業の「雁行」(未完了の作業が残っているのに、次工程に移って並行作業する)をしていないか
  2. 全体に波及する爆弾を抱えていないか
    新システムを導入する領域とそれ以外の領域のギャップをどのように埋めるか検証しているか
    特殊な業務が多数あり、五月雨式に追加要件が発生していないか

 

③プロジェクトが適切に運営・管理されているか

プロジェクト運営に関して経営陣が注視するとよいのが、ベンダーへの依存度である。自社社員が議論に参画しているか、ベンダーの成果物を適切にレビューしているか、ベンダー主体でプロジェクト運営されていないかを見ていく。

 

参考文献・紹介書籍