
失敗前提から挑戦前提へ — ITプロジェクトマネジメント 20年の進化
はじめに
2006年、私はITmediaで「超現場主義! 失敗しないITプロジェクトマネジメント」という連載を書いていました。当時、上場を控えた会社の取締役として、深夜まで続く議論と神経を削り合う進捗管理の日々。その現場で学んだ教訓を、ありったけの情熱で記事に叩き込んだものです。
あれから20年。iPhoneが登場し、AWSがインフラを変え、GitHubが標準になり、AIがコードを書く時代になりました。
では、プロジェクトの「炎上」はこの世からなくなったでしょうか。
答えは「No」です。ツールは進化しましたが、私たちは相変わらず見積もりを外し、仕様変更に苦しみ、人間関係で悩んでいます。本記事では、20年で何が変わり何が変わらなかったのかを整理し、現代のプロジェクトマネジメントに必要なマインドセットを提示します。
本記事は、Zenn連載「超現場主義!失敗しないITプロジェクトマネジメント Remake」全5回のエッセンスを、現代の実践フレームワークとして再構成したものです。
ロケットから自動運転車へ — パラダイムの転換
20年前のプロジェクトは「ロケットの打ち上げ」でした。開発期間は半年から1年、外に成果物は出ず、リリースの瞬間に成功か爆発かが決まる一発勝負。後戻りが許されないため、要件定義書や基本設計書を積み上げ、あらゆるリスクを机上で潰そうとしました。
現代のプロジェクトは「自動運転車での旅」です。間違った道に入ってもUターンでき、コード修正からデプロイまで数分。「とりあえず出して、ダメなら戻す」が物理的に可能になりました。
この変化は偉大な進歩です。しかし、ここに現代特有の落とし穴があります。
「アジャイル」という名の思考停止
「あとで直せるから」という安心感が、思考停止を招いている。 これが20年間の最も深刻な退化かもしれません。
ロケットの時代は、計画不足は即「爆発」でした。だから必死だった。自動運転車の時代は、計画がなくても「なんとなく走れてしまう」のです。
目的地(ビジネスゴール)も、ガソリン(予算)の残量も確認せず、「アジャイルなんで」と走り出す。気づけば予算は尽き、どこにもたどり着けないままプロジェクトは終了する。安易な仕様追加を許容し続け、車体はツギハギだらけ。スピードは落ち、誰もメンテナンスできなくなる。
20年前の「ロケット」は、失敗すれば派手に爆発してニュースになりました。現代の「自動運転車」は、静かに迷走し、誰にも気づかれないまま荒野で立ち尽くしています。これを「失敗」と呼ばずして何と呼ぶのでしょうか。
「変化前提」であることは「行き当たりばったり」でいいという意味ではありません。変化に対応し続けるためにこそ、強固な規律と、自分たちが今どこにいて、どこへ向かっているのかを常に計測する高度なマネジメント能力が求められます。
ワンチームの幻想と本当の心理的安全性
20年前の最大の敵は、「発注者」と「受注者」の間の深い溝でした。ユーザー企業のPMは「お客様」として君臨し、開発側は「下請け」として無理難題に耐える。ビジネスの目的を共有せず、「業者扱い」する。結果、進捗が隠蔽され、リリース直前で爆発する。
アジャイルが普及した現代、表面上の関係は改善しました。Slackの同じチャンネルでフランクに会話する「ワンチーム」が増えた。しかし、形を変えた新たなバグが潜んでいます。
責任の曖昧化。 「みんなで決めよう」は一見民主的ですが、問題が起きた瞬間に「誰が責任を取るか」が消える。ぬるま湯としての心理的安全性。 本来は「耳が痛いことでも言える状態」を指すのに、「仲が良い」「厳しいことを言わない」だけの空間になっている。お見合いによるタスクの蒸発。 テレワーク時代、明確に言語化・チケット化されないタスクは、誰の視界にも入らないまま消えていく。
20年前の「怖くて言えなかった隠蔽」と、現代の「雰囲気を壊したくないから言わない」は、結果において何も変わりません。
変化前提のマインドセット — 3つのフレームワーク
では、現代のPM(そしてすべてのエンジニア)は何を心がけるべきか。20年の教訓を3つの原則に集約します。
1. 致命傷を避ける(Resilience)
完璧な計画は立てられません。しかし、「致命的な失敗」と「許容できる失敗」を事前に区別することはできます。タイヤが1本パンクしても走り続けられる設計。それがレジリエンスです。
フェーズ分け契約でリスクを切り出す、バッファを「品質を守るための必須コスト」として正直に合意を取る、検収を細分化してキャッシュフローを防衛する。これらは全て、致命傷を避けるための具体的な戦術です。
2. 早く失敗して学ぶ(Fail Fast / Learn Faster)
「失敗してはいけない」の呪縛から「早く失敗して、早く学ぼう」へ。ただし、これは「行き当たりばったり」の免罪符ではありません。仮説を立て、最小限の実装で検証し、結果から学ぶ。このサイクルを意識的に回すことが重要です。
3. 本当に大切な価値に賭ける(Focus)
何かを捨てることは「敗北」ではなく、「一番大切な価値にリソースを集中させるための投資」です。「この機能を削ります」と言う代わりに、「この体験を最高にするために、今はここに全力を注ぎます」と言える。このポジティブな言い換えは、単なる言葉のあやではなく、プロダクトマネジメントの本質的な進化です。
まとめ
「失敗前提」で始まった20年前の物語は、「挑戦前提」へとアップデートされました。
ツールは変わり、場所は対面だけでなくGoogle Meetも加わりました。しかし、PMの本質は1ミリも変わっていません。
不確実な霧の中で、進むべき方向を指し示すこと。そして、その結果から逃げないこと。
データは判断材料ですが、決断は意志です。失敗した時の責任を取る覚悟があるからこそ、チームはあなたについてくる。
技術が進歩した分、私たちは「より速く、より複雑に」失敗する能力を手に入れました。だからこそ、20年前の泥臭い教訓が、今なお効力を持っています。
「現場は最高に面白い。さあ、次の決断をしよう」