システム開発のプロジェクトの成功率は、時代の流れとともに上昇しています。
すこし前の情報ですが、日経BP社の調査によれば、2018年時点のプロジェクトの成功率が約半数（52.8％）、2003年26.7％、2008年に31.1％となっています。
裏を返せば、まぁ半分は失敗プロジェクトになっています。
出典：日経ビジネス電子版『プロジェクト失敗の理由、15年前から変わらず』
今回は、ITのシステム開発プロジェクト、特に大規模なプロジェクトの失敗原因について探ってみたいと思います。
プロジェクトの失敗原因と対策
プロジェクトのさまざまな局面で失敗する原因が存在します、それぞれの工程で多い失敗として目にするものは、次のようなものです。
【上流工程】上流工程（構想検討や要件検討）がなかなか決まらず納期遅延になる
【開発工程】技術的に解決ができず、開発のタイミングで停滞する。
【テスト工程】テストをはじめたら品質や性能が悪いためリリースできなくなる。
上流工程
BP社の分析でもでてきてましたが、最も多いのは上流工程がなかなか終わらないというものです。
BP社のアンケートでは要件検討とありましたが、おもにシステムを開発するお客様側で実施することかもしれませんが、要件検討前の構想を決める段階で何年もきまらず暗礁にのりあげるプロジェクトも何度も見かけました。
結局そのプロジェクトは、何を目的として実施されるものなのか、決める人の腹に落ちてないと決まらないものです。
これを見てる方が上流工程を請け負う立場のリーダー、マネージャの場合は、お客様が何を狙いにしているかは、間違えないように何度も確認をしたほうがいいですね。
僕がこの業界で仕事をはじめた20年以上も前から、プロジェクトの失敗の最大の原因は、
「プロジェクト目的が不明瞭でプロジェクト内で共有されていない」
というものでした。これは現在でも変わっていないと思います。
開発工程
開発工程にはいると、技術的に解決困難な課題が発生して、プロジェクトがストップしてしまうというのは、よく直面しました。
これも２０年前から同じで当時ＩＢＭの調査記事に１位が上流工程の目的の不明瞭さ、２位が技術課題で開発遅延、をみた記憶があります。
これを避けるためには、いくつかの方法があります。
優秀な技術者をやとう。
技術的なネックになる部分に強い技術者を確保しておく。
事前に検証しておく。
技術的な問題が発生しそうな課題を一覧化して、プロジェクトの開発に入る前に検証フェーズをもうけて検証しておく。
スケジュールにのりしろを持つ。
スケジュールにリスクをみた期間をもうけておく。
理想は３つとも考慮した日程にしてしまうことですが、プロジェクトにそんな余裕はないのが普通です。
技術的なリスクが高いと思った場合には、プロジェクトの状況にあわせて、可能な対策をうっておくことが肝要です。
テスト工程
テストをはじめたらいきなり動かないとか、性能がでないとかいうことはよく耳にします。
大規模プロジェクトの場合、たいてい問題になるのは、個々のメンバが各自の担当分を開発している間はよくても、結合しだしたら問題が頻発するケースです。
不整合がありつながらない。
全体を結合する環境に不具合があって動かせない。
データを増やしたら性能が悪すぎて使えない。
夜間のバッチ処理がおわらないとか、画面のレスポンスがかえってくるのが数分かかるとか、大規模になればなるほど、問題が発生するリスクは増加します。
これらのリスクを回避するための対策も、プロジェクトの状況にあわせて実施すべきものを実施しておくことが、プロジェクトを成功に導くためのポイントになります。
早めにできた部分からつないでおく。
結合する環境も余裕をもって作成し仮結合のタスクをもうける。
結合前の各自が開発するタイミングから性能を考慮したテストを実施する。
また、要件を提示したお客さんやシステム部門の方に確認してもらうユーザテストも早めにスケジュールにくみこんでおいたほうがいいです。アジャイルで開発した場合には、要件と大きくずれるというリスクはウォーターフォールで順次開発する場合よりは減りますが、大規模プロジェクトの場合だと、まだまだ工程・局面別にフェーズをわけた開発が多いと思います。
気をつけるべきポイント
プロジェクトの失敗になりそうな内容と対策について述べてきましたが、ここからは、プロジェクトっていろいろなことが発生する、という、自分が目撃したり実際経験したりした内容を書いておきます。
プロジェクトで何点を目指す？
プロジェクトは１００点目指すというのが、もちろん理想なのですが、実際にはプロジェクトは当初の計画から減点されていって、現実的に１００点は厳しいです。
冒頭で書いた半分は失敗が現実で失敗プロジェクトが６０点以下だとすると、７０点、８０点で成功といっているプロジェクトが大半ということです。
最初にプロジェクトの計画を細部にわたりしっかりと立案して、あとはそこからどの程度減点にならずにプロジェクトを最後までもっていくか、というのがプロジェクトマネージャの仕事になります。
１００点から６０点の間が成功だとすると、納期、品質、コストをうまくコントロールしてどのあたりに着地させるか、それがプロマネの腕のみせどころです。
もちろん、お客様のことを考えて、なるべく高い点数に着地できることが望ましいし、あわよくば、１２０点を目指したいものです。
品質、性能、どこまで目指していたの？
テスト工程で、こんなはずではなかったということが発生するケースはよく目にします。
テストでシステムを結合しだすといろいろ問題が出始めます。
例えば、お金や電話番号の入力欄にアルファベットが入力できたりとか、データベースに接続できないだけで、システムエラーになってシステムがフリーズするとか、仕様書には記載がないけどそれって対応してあるのが、ある意味常識でしょという内容など。
こういう部分は上流工程でユーザとしっかり決めておくのが重要です。数字しかはいらないところにアルファベットを入力するというのは、プログラムのエラー処理ではなくて正常なオペレーションの一つです。人間は間違いもあります。
このあたりは、大規模プロジェクトであれば、開発標準としてまとめてつくり、開発者やシステム仕様を検討するメンバーに展開、徹底しておくといいですね。
また、性能についても時々見るのが、オンラインは何秒でレスポンスがかえってくればいいの？
夜間のバッチ処理の時間はどの程度のデータで何時間が許容範囲？
このようなシステム的な要件は、上流工程でユーザと決めておく必要があります。
性能要件の厳しさも実際にどこまで作りこむかという工数、費用に跳ね返ります。
ユーザは目に見える業務までしか気がまわらない場合がよくありますので、非機能要件もしっかり定義しておくことが、プロジェクトを成功させるためには重要なポイントになります。
人を入れると大変なことに、真面目に作業しすぎです
上流工程でのスケジュール遅延がプロジェクトの失敗のよくある原因だという話題は冒頭にでてきます。
とはいえ、厳格なＰＭだと、納期までに間に合わすためにと、ユーザと調整して人を追加投入というのを何回か見たことがあります。
結果はたいてい、規模増加で大変なことになってました。
決まらない遅れるからという理由で人を投入→
決まらないまま投入されても何をやっていいかわからない人が増加→
でも日本人はまじめなので作業をする→
その結果つくるシステムの要件はどんどん膨れ上がる
まじめにがんばる日本人気質がでてしまうのかもしれませんが、この繰り返しでプロジェクトが雪だるま式に大きくなっていき、お金の確保とか大変な話になります。
要件検討で人を追加しすぎないようにすることは、プロジェクトにもよりますが、大規模プロジェクトでは大切なポイントだと思います。
プロジェクトの要員計画は全体を通して大きく立てて、構想や要件を決める上流工程が、中盤以降の開発工程に近い山積みにならないようになっているかなど、きちんとバランスを見ておく必要があります。
どんな仕事でも同じですね。全体を広い視野をもって把握することがプロジェクトマネージャにとって必要な力になります。
プロジェクトで困った時
これまでの自分の経験やノウハウをもとに、プロジェクトのコンサル、ご支援/ＰＭＯ、プロジェクトマネージャの育成などを実施しております。
もしプロジェクトでお困りの時はご相談ください。下記にリンクも貼っておきます。
