BCGが指摘、「ビルを建てようとして橋をつくりかねない」日本のシステム開発の現実

日本企業は不慣れな「アジャイル型」開発は避けるべき

　ここでは、DX戦略を実現するために企画された個々のシステム開発プロジェクトに着目する。具体的には、システム開発プロジェクトで失敗しないために、プロジェクトの各フェーズで実施すべきことを取り上げる。ここでいうシステム開発プロジェクトは、経営会議で投資の意思決定を仰ぐような、企業にとって大規模なIT投資を必要とする案件を前提とする。多くの場合、基幹システムの刷新や、メインフレーム上で動くシステムのオープン化と言われる案件が対象となる。

　業界にもよるが一般的にITコストは企業の売上高の2％程度とされるので、売上高1,000億円の企業であれば年間20億円程度、その半分をこのような大規模システムの刷新に投じているとすると、年間10億円、それが数年間のプロジェクトとなるので30億～50億円程度の案件になる。売上高がそれ以上の企業であれば、その投資は数百億円以上になることもある。

　DXの領域では、仕様や要件を固めずに、計画→設計→実装→テストのサイクルを短期間で回す「アジャイル型」という開発手法がよく知られている。その際には現場担当者に大胆に権限を委譲し、スピーディーかつ柔軟に開発を進めることが求められる。一方で、アジャイルに不慣れな日本企業が、ここで取り上げるような大型案件にアジャイルを適用することは避けるのが賢明だ。このような大型案件では、従来のシステム開発で用いられてきた「ウォーターフォール型」、つまり、ゴールを明確に定めて、全体計画を策定し、工程ごとにバトンタッチしていく方式で進めるのがよい。

　ウォーターフォール型でシステム開発を進める場合の工程の切り方や呼び名は、それぞれの企業やITベンダーによって異なることが多い。システム開発を進める上で各工程の要諦を押さえておくことは非常に重要ではあるが、経営陣が意思決定をする上では、大きく「企画構想」「要件定義」「実装」の3フェーズを意識する必要がある（図表1）。

「企画構想」「要件定義」「実装」フェーズで陥りがちな罠

　企画構想フェーズは、どのような目的で、どのスコープ（対象範囲）で、どのくらいの期間・コストをかけて、どのようなやり方で、何を成し遂げたいのかを、経営、事業、ITの各部門で合意し、プロジェクト全体を前に進める意思決定をする。特に経営層などが高い目線で投資や方向性を決めることが求められる。

　要件定義フェーズは、企画構想フェーズで決めたスコープの中で、事業部門（発注者）が実現したいこと（要求）を洗い出していく。それに対してベンダー（受注者）は具体的な要件（仕様）を明らかにする。

　実装フェーズは、定められた要件を実現するための設計を行い、実際に開発し、それが正しく動作するかを確認する。実際のプロセスではIT部門が中心となって推進することになる。

　こうした大規模な開発は、投資額も大きく、プロジェクトをやり遂げる難度が非常に高い。また、投資の結果としてビジネスの成果も求められるため、経営陣・事業部門・IT部門が三位一体となり、3つのフェーズのそれぞれで、三者が果たすべき役割を担いながら、また状況による役割のバランスを考慮しながら、着実に進めていくことが重要となる。

　ただし、これまでさまざまなシステム開発プロジェクトを見てきた経験からいうと、3フェーズの各所で落とし穴が待ち受けており、多くの企業がそれにはまってしまっている。その結果、多額の追加投資を余儀なくされた、スケジュールが大幅に遅れた、完成はしたが有効に活用されない、生産性向上や収益増につながっていないといった、システム開発後によく耳にする問題が生じてしまう。各フェーズで陥りやすい典型的な罠は次の通りだ。

通常なら質問攻めの末に却下されるはずが…

　典型的な罠について不可解な印象を抱いた人もいるかもしれない。

　たとえば、何をつくるのかが曖昧で、中身を理解していないものに対して、果たして経営会議で大規模投資の承認が下りるだろうか。通常の製品開発や新規事業プロジェクトであれば、間違いなく考えにくい。そんな不確かな提案をしても、たちまち質問攻めに遭い、却下されるだろう。

　ところが、システム開発ではそうならないことが多い。

　それはシステム開発には特殊な事情があるからだ。そこで各フェーズの罠について検討するときの前提として、システム開発ならではの特徴を整理してみたい。 【次ページ】システム開発ならではの“特殊な事情”4つ