プロジェクトは失敗しやすい？
今までにも何度か説明していますが、結論として『プロジェクト』とは
「新しいものを作るために行う、スタートとゴールのある仕事」
という意味で、限りある資源（人手/時間/資金）を投資して初めて
取り組む物事であり、その先にある成果を上げていかなければならない
というものです。
初めて取り組む要素がありつつもビジネスとして成果を上げるというのは、なかなか簡単なことではありません。
当然、何の備えもなしにテキトーなことをしていれば確実に失敗します。
私はプロジェクトとして取り組む際、いつからか「航海」をイメージするようになっていました。「何があるかわからない」ところが天候や海の状態のような自然の脅威に近い気がしているからです。
しかし、何があるかわからないといっても、何一つ予測できないというものではありません。想定できるシチュエーションはいくつもあります。過不足はともあれ、思いつく限りはやはり準備しておかないと、いざというときに後悔することになります。
では、世の中のプロジェクトはどれくらい成功（あるいは失敗）しているのでしょう。
実際にググって調べていただけると面白いと思いますが、プロジェクトの成功率/失敗率にはいろんな調査があり、
概ね50%～70%ぐらいの幅で失敗している
と出てくることでしょう。
たとえば、日経コンピュータが定期的に実施しているITプロジェクト実態調査では「成功率が52.8％」となっていますが、より大規模な国際調査である Standish Group による CHAOS Report では「成功率は29%」とされています。
また、国内でもアジャイル開発が比較的増えていることも起因しています。
アジャイル型の開発手法の場合、成功率がウォーターフォール型のおよそ３倍という数字もあるそうです。これは決してアジャイルが優れた開発モデルだからというわけではないことだけ付け加えておきたいと思います。
アジャイル型（大半がスクラムでしょうけど）の場合、ＩＰＡ（経産省）が推奨している契約モデルにもあるように、通常は準委任契約を結ぶことになるかと思います。要件がしっかりと決まってからでないと完成責任を負えないため請負で実施するには非常にリスクがともなうからです。
そのため、アジャイルでは善管注意義務やＰＭ義務をしっかりと果たしさえしていれば完成責任を伴わないため、トラブルとして扱われにくいという側面があるのです。
要件も定まっているのかいないのかハッキリしないまま（変更管理のベースラインを定めることもできないまま）リスクを冒してでも請負契約で進めようとするウォーターフォール型のプロジェクトと比べると圧倒的にトラブル率が低くなるのは当然です。
それ以外にもアジャイル型のほうが失敗しにくい要素がいろいろあるのはもちろんわかっていますが、こうした側面も理解したうえで常に客観視できるようにしておきましょう。
少し脱線しましたが、では日経コンピュータが定期的に実施しているITプロジェクト実態調査では「成功率が52.8％」と言われているうちの何割がアジャイルで、何割がウォーターフォールなのでしょうか。
実はここが最も重要なところではないかと思います。
アジャイルの成功率がウォーターフォールの３倍だというのであれば、ウォーターフォールの平均成功率を「ｘ」、ウォーターフォールの件数を「ｎ」、アジャイルの件数を「ｍ」とした場合、
（（ｘ × ｎ）＋（３ｘ × ｍ））÷ （ｎ＋ｍ）＝ 52.8%
ということになりますよね。
具体的な数字はわかりませんが、こうやって見てみると2003年や2008年に調査した際の成功率が30%前後だったことを考えても、アジャイルが平均点を上げてくれていなければ50%以上の数字になっていなかったのではないかと思えてきます。つまりウォーターフォール型の開発モデル自体はほとんど成功率が上がっていない（= 先達が経験してきた過去の失敗から何も継承されていない）ということが透けて見えてきます。
さらに面白いのは、企業名を出して協力している調査では成功率が高く（失敗率が低く）出ているのに対して、匿名の調査では失敗率が高く出ているという点です。
つまり、失敗しているプロジェクトはまだまだ裏に潜んでいて、失敗を言いたくないから隠している企業やプロジェクトが全調査の３割近くいるかもしれないと言うことも考えられます。
また、ITPro の調査ではなんと 94.5% のプロジェクトが深刻な失敗を経験したと回答されており、さらにそのうちの9割が同じ失敗を繰り返しているとされています。
プロジェクトは自然現象ではないためどうしても回答者の属性や主観、回答方法によって調査結果が大きく変わってしまいますが、もし本当の成功率が 50% でも 5% でも、
"世の中の膨大なプロジェクト予算や人々の労力が
無駄になっているという事実"
には変わりがありません。それだけ多くのエンジニアが深刻な失敗…いわゆるトラブルを経験しているということは、要するに「成功率５割」というのもいよいようさん臭くなってきているのではないでしょうか（アンケート対象に偏りがある可能性も…）。
そうなる可能性はどのプロジェクトにも存在するはずなのに、ロクに監視・コントロールもしないであちこち飛び回っているプロジェクトマネージャーや管理職なんてのがいるから、いっこうにこういった失敗プロジェクトが絶えないという側面もあるのでしょう。
もし周りに何かのプロジェクトをやっている人がいたら聞いてみるといいと思います。忖度の必要なく、正直に物事を言い合える関係性であれば、現時点でのスナップショットを切り出してみれば「オンスケ」「問題なし」だとしても
「何一つ不安要素はない」
と回答する人はきっと少ないはずです。
私自身、結果としてトラブルプロジェクトの解決にかかわる機会が非常に多かったために、逆に新規での開発というのは20代～30代前半までに集中していたのですが、結果的に成功と言われるようなものでもやはり綱渡りになりそうなプロジェクトは多かったと思います。
・お客さまがなかなか腹を割って内情を教えてくれない
・仕様について詰めようとしても建設的な意見が出てこない
・お客さま自身が実施すべきタスクがどんどん遅れて、
こちらの作業が進まない
・お客さまの新人を受け入れてＯＪＴしなくてはならない
・自分以外、新人・若手・未経験の外注しかいない
・チームで決めた進め方をしないメンバーがいて統率を乱される
etc.…
なにかしら１つや２つは面倒な要素はありました。
すべてが順調になる瞬間なんて、ごくわずかの期間だけです。
プロジェクト全体に影響を与えないまでも、細かい失敗は数え切れないほどありました。その一つひとつは反省として次に活かし、プロジェクト内で再発させないようにしてきました。この徹底だけはホント人並み以上にやってきました。実際、１度は失敗しても再発する頻度は周囲を見回しても圧倒的に低かった（5~10年に1回程度）と思います。
今思い起こしても、どれ１つとっても気の抜けるようなものはありませんでした。と言うか、気を抜いてトラブルを起こすほど無責任なことはできませんでした。
これまで数多くのプロジェクト／トラブルプロジェクトに関わっていく中で突き詰めたのは
「事前準備を怠らないこと」
「その準備に慢心せず、常に気を張って慎重に進行すること」
「慎重さにかまけてスピードを落とさないこと（その両立を果たすこと）」
「なによりメンバーに余計な負担はかけないこと」
を最大限実施すると言うことでした（ちなみに、事前準備の大半は開発そのものに関係するしないに関わらず、プロジェクトに関わる情報（特に業務、利用、顧客都合）を収集し、整理し、不足箇所に対して何重にも予防線を張り巡らせることを言います）。
もしみなさんがプロジェクトマネジメントに取り組もうと思うなら、そしてそのプロジェクトで失敗させたくないと本気で思うなら、
登山のようにちゃんと準備して取り組む必要がある
と認識しておくことが大事です。
準備の大切さを理解していないプロジェクトは失敗率が上昇します。
富士山に軽装で挑めば十中八九死のと同じです。
低い山でも遭難することはあるのです。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。