プロジェクトを失敗させる罠を公開します！
「プロジェクトを失敗させる55の罠」がようやく発売された。
この本については執筆中（2024年から25年にかけて）からたまにブログにも書いていたので、「まだ出ていなかったの？」と思っている読者もいるかもしれない。
自分で言うけど「これを読まずしてプロジェクトに特攻するのは無謀過ぎる」という本になった。プロジェクトワーカーという自覚がある方、またはいつプロジェクトに投入されるか分からない方は、読んだ方が良いです！
なお以前書いた「システムを作らせる技術」と同様、基本的にはプロジェクトの主体者（ベンダーやエンジニアではなく）の目線で書いた本である。もちろんベンダーに勤めるエンジニアさんが読んでもめちゃくちゃ勉強になると思うけど。
タイトルの通り、「これにハマるとプロジェクトが失敗する」というヤバイ罠（アンチパターン）を55個集めた本なのだが、このブログでは、55個を全部公開してしまおうと思う。
この罠のリストを完成させるのには2年かかった（収拾、整理）。しかも僕の30年のキャリアのエッセンスとも言えるもの。正直タダで公開することには迷いもあったが、それくらいでこの本の価値は毀損されない、と判断した。
つまり「罠をこのブログでさらっと眺めて分かった気になる」よりも「お金と大量の時間を投入して、本を舐めるように読む」方がずっとずっとコスパ、タイパがいい、ということだ。
どうしてこういう判断に至ったかについては、前にブログにも書いた。
AIに要約させれば読書は不要なのか？あるいはヤバイぞアンテナの実装方法
https://blogs.itmedia.co.jp/magic/2026/03/ai_2.html
もちろん全く知らないよりは、リストだけでも55の罠を頭に入れた人が増えた方が、プロジェクト成功率が上がる。だから（大げさに言えば）公開するのは社会貢献的な意味もある。もっとミクロな話としては、具体的なプロジェクトについてお客さんと会話している時に、いちいち説明しなくて良い方がありがたい。そんな感じ。
このブログでは、「どんな罠か？」に絞って100字以内で説明した。だから読んだ人は「ほんとにこんなこと起こるの？」「なんでこうなっちゃうの？」「どうすりゃいいの？」みたいな疑問が浮かぶだろう。そしたらほら、本を買ってください。
というか、このリストに目を通して、いまやっているプロジェクトが心配になった人は、マジで本を買った方がいいと思う。
なお、55の罠はざっとプロジェクトの最初から最後にかけて並べている。ウチの会社（ケンブリッジ）の方法論で定義しているフェーズごとに下記では段落を分けているが、何をやるフェーズか知らなくても、罠の理解にはあまり支障がないだろう。
【プロジェクトを失敗させる55の罠】
****【Concept Framing】****
罠01：何かやる、だけ決まっている
華々しい成果をあげるために経営層がプロジェクトを立ち上げる。具体的なゴールも必然性もないのに、成果を出す日付だけが決まっている。方向性が定まらないので迷走し、成果を出せないままひっそりと終わる。
罠02：稟議を通すための建前ゴール
本音のゴールを掲げても投資が承認されず、実行困難な無茶なゴールや、見栄えがするが成し遂げても会社が良くならない空虚なゴールを建前として掲げる。本音と建前、2つのゴールがあるのでチームは迷走してしまう。
罠03：脆弱なゴール
「Well-beingに貢献」のように、何も語っていないゴール。文句を言われないように、全部やる事になっているゴール。曖昧で好き勝手に解釈できるゴール。これでは、いずれ訪れる難所を乗り越えられない。
罠04：理想論で突き進む
ビジョナリーが壮大な理想を掲げてプロジェクト開始。理屈は正しく聞こえるが、現実の壁に阻まれ停滞。メンバーが疑問を呈しても論破され、誰も反対できないまま進行し、最終的には壮大に破綻する。
罠05：新規事業特有の失敗
新規事業推進室が発足すると、意義やビジョンの言葉遊びに終始したり、成果が出ないPOCを繰り返して「POC疲れ」に陥る。その後も経験不足で手探りでしか進まず、資金と人材を消耗した上で失望感だけが残る。
罠06：現行踏襲を掲げる
システムの再構築が必要だが、業務には課題を感じておらず、変化は望まない。現行システムをそのまま再構築しようとするが、変更を避ける設計は機能肥大化を招き、納期が遅延し、コストも超過していく。
罠07：プロジェクトオーナーが機能しない
役員がオーナーとして参加しても、高尚な言葉だけを残して「よきにはからえ」と丸投げしたり、意思決定を避けたりする。問題が起きても他部門との調整もしない。結果としてプロジェクトは漂流
する。
罠08：過去の失敗に向き合わない
失敗プロジェクトを分析すると、課題の本質的な難しさや成功を妨げる組織文化に気づくことができる。だがほとんどの組織は失敗に蓋をするのでノウハウや経験が蓄積せず、繰り返し同じ失敗をしてしまう。
****【Assessment】****
罠09：現状調査が甘い
「ゼロベースで新しいビジネスを作るから」などの理由で現状調査をサボる。考案した施策が無益なことに気づかなかったり、必要なシステム機能を漏らすことになり、プロジェクト途中で方向修正を迫られる。
罠10：業務メンバー不足
「あのプロジェクトは経営企画やIT部門がやってるんでしょ」と、業務部門が主体的に参加しない。変革プロジェクトは将来の業務を規定するので、本来は業務部門にとってこれ以上に大事な仕事はないはずなのに。
罠11：コンサルタント選びに失敗
コンサルティングサービスは高価な割に納品物が曖昧で、価値が事後的にしかわからない。そのため選定も手探り。能力が低かったり、自社に合わないコンサルタントを選んでしまうと変革の推進力にならない。
罠12：他社事例から学ばない
類似プロジェクトを経験した他社に教えを請うべきだが、「うちは特殊」などと言い訳して情報収集を怠る。経験不足を補えず、ソリューションの不適切な使い方などの勘違いを正せないままプロジェクトが進む。
****【BusinessModelフェーズ（施策立案）】****
罠13：施策がショボい
現状調査で課題（現場の困りごと）を数多くリストアップした。だがそれらを1つ1つ潰すような小粒の施策を数多く実行しても、ビジネスは抜本的に良くならない。投資が回収できないプロジェクトになってしまう。
罠14：流行り技術に飛びつく
AIなどの流行の最新技術に飛びつき「これを導入しさえすれば、我が社は飛躍できる！」と思うのだが、実際には技術を使ってビジネスをどう変革するか？が重要なので、そこをないがしろにすると効果を出せない。
罠15：制度や習慣をスクラップしない
効率化のために業務を設計しなおしたり、売上向上施策を検討したとしても、古い制度や慣習を残したままだと、「しなければならないこと」が積み上がるため、仕事の透明度や効率はどんどん悪化する。
罠16：データのガンを放置
業務の手順などを工夫したとしても、ビジネスで扱うデータが誤っていたり構造がぐちゃぐちゃだと、それをフォローするために無駄な作業が必要となる。ビジネスの見通しも悪くなるので適切な経営判断ができない。
罠17：覚悟なきFit to Standard
コスト削減や業務の効率化を目的として「パッケージが想定する標準業務に合わせる」という方針を掲げる。だが現実と標準業務の乖離を無視するわけにもいかず、業務はシンプル化せずにアドオンだらけのシステムに。
罠18：メンバーが皆ひとごと
メンバーが集められたものの、全員が「呼ばれたから来たけど」というノリで、成功に向け自主的に考え、行動するには程遠い。定常業務とは違い、役割や評価について曖昧にするとこういうメンバーばかりとな
る。
罠19：野蛮さ不足
小さな問題に目をつぶり、会社全体にとって本質的に重要なことを断行する野蛮さが変革には必要。しかし日本企業では協調性が重視され、衝突するよりは交渉や説得を避けようとするので、変革が尻すぼみに終わる。
****【BusinessModelフェーズ（計画立案）】**
罠20：一気に変える
これまで現状を放置していたのに、いざ改革の機運が高まると、すべてを一気に変えようとする。だが変革人材や投資予算には限りがあるため、優先順位を付けないとすべてが中途半端に終わり、改革は頓挫する。
罠21：最初に決めた納期に縛られる
具体的なことが決まっていない立ち上げ時にとりあえず掲げたプロジェクト完了日が、いつしか「必達スケジュール」になってしまう。計画を精緻化しても妥当な納期に変更できないので、コスト増、品質低下を招く。
罠22：最初に決めた予算に縛られる
具体的なことが決まっていない立ち上げ時に経営陣に伝えた概算投資額が「びた一文増やせない予算制限」となってしまう。成果を出すために最低限必要なお金も使えないため、中途半端な成果しか出せない。
罠23：IT部門が脆弱
変革は業務部門が主導すべきだが、ITを避けて通れないため、IT部門が脆弱だと失敗に直結する。例えばIT起因の課題を見逃したり、ベンダー提案の是非を判断出来なかったり、データ移行に苦戦したり。
罠24：業務部門とIT部門の相互不信
業務部門はIT部門を仕事をするうえでの対等なパートナーと考えない。一方でIT部門は業務部門が非協力的なこと、意志が不明確なことに困っている。両者が協力できないことが、妥当な意思決定を阻害する。
罠25：リーダーシップ不足
リーダーシップの訓練を積んでいる日本人は極端に少ないし、メンバーもうまくリードされる能力が低い。そのためみんなが目指したくなるビジョンを提示したり、ビジョン実現に向けてチームをまとめる力が不足する。
罠26：上流を端折る
下流工程は多くの人が活動するため、お金がかかるし計画変更もしにくい。だからその前に計画を練り込んでおくべきだが、「とにかく早く目に見える成果を出せ」という社内プレッシャーから上流工程を端折ってしまう。
罠27：永遠に始めない
「もっと調査に時間をかけ、計画を精緻にするべきだった」という反省から、スケジュール通り、予算通りに成功する確信が得られるまで、実行の決裁が下りない。結局何も変えられないまま、時が過ぎてしまう。
****【Scope】**
罠28：機能要求を漏らす
要件定義において見逃した機能が後の工程で必要だと分かり、五月雨式に追加される。設計やテストなどで手戻りが発生するためスケジュールが遅延。予算超過。中々完成に近づかないため、モチベーションも低下。
罠29：要件定義の障壁
現行システムに埋め込まれた複雑なビジネスロジックを業務担当者も把握していない状況。ロジックが存在していること、なぜ必要なのか、今回どう変更すべきか、などを説明出来ないため、要件定義が進まない。
罠30：一気に作る
ユーザーからの要望をすべて聞き入れざるを得なくなり、優先順位をつけずに機能をすべて同時に作ろうとする。納期と予算を守れない肥大化プロジェクトになった上に、作ったものの使われない機能が大量生産される。
罠31：組織受入態勢の軽視
システム機能の優先順位付けをする際、効果や技術面ばかりに注目し、「ユーザーはその機能を使いこなせるか？」「自主的に使うか？」という観点が抜けている。そのため機能を作っても全く利用されない。
罠32：組織内合意を作れず迷走
関係者ごとに立場があるため、全員が納得する方針を決めたり要望を叶えることは困難。だが方針に納得しない人々は新ルールをないがしろにしたり、新システム機能を使わないため、成果の刈り取りに影響が出る。
罠33：リスクとうまく付き合えない
人間は「リスク」を扱うのが苦手なので、根拠なく楽観的だったり、逆に割に合わないほどお金をかけてリスクをゼロにしようとするなど、プロジェクトの存続自体を危うくするような振る舞いをしがち。
****【PEW】****
罠34：ソリューション選定の失敗
設計思想が自社のビジネスモデルに合わなかったり、機能不足のパッケージを選定したり、想定とはかけ離れた方法で利用するなど、技術選定での失敗。エンジニアが創意工夫で解決しようとして事態が悪化することも。
罠35：ベンダー選定の失敗
安さやプレゼンのうまさなどでベンダーを選んでしまったが、提案通りにプロジェクトを進めるノウハウや知識を持っていないことが後々分かる。ベンダーをスイッチすると時間とお金を失うため、悩ましい判断となる。
罠36：OneTeamになれずバラバラ
関係者が立場を超えて1つのゴールを目指していると、課題解決スピードが上がったりミスを補い合うなど、様々なメリットがある。しかし真のOneTeamを実現するのは難しく、利害の相違が協力を阻みがち。
罠37：バッファを持たない
ITプロジェクトの平均コスト超過率は73%。見積時にバッファを持たないと、「予算や期間の超過に対処するために新たな作業が発生し、それが更に予算やスケジュールを圧迫する」という悪循環に陥る。
罠38：見積大ハズシ
構築する機能が明確になっていても、ソリューションに不慣れだったり、想定外の作業が発生したり、意思決定に必要な時間が読めなかったり・・。見積がブレる原因は多くあり、正確な見積は経験豊富なプロでも困難。
****【Depleyment】****
罠39：老舗温泉旅館化
全体構成を考慮せずに必要な機能を継ぎ足していった結果、複雑に入り組んだシステムとなってしまう。こうなると些細な変更をする際も影響範囲の見極めが困難で、テストの手間がかかったり不具合が頻発してしまう。
罠40：Scope Creep
優先的に構築する機能を慎重に選択したにも関わらず、後の工程でいつの間にか作る機能が次々追加されていく。当初の予定にはなかった作業が増えるので、多少残業してもずるずると進捗が遅れていく。
罠41：仕様変更頻発
後から偉い人が当初とは異なる要望を言い出したり、要件定義の際に考慮していなかった業務やロジックがあったため、一度決めた仕様が変わる。すでに設計や開発に着手していた場合は大きな手戻りになる。
罠42：品質がボロボロ
順調に思えたプロジェクトでも、考慮不足の設計書、バグだらけのプログラムなど、成果物の品質が悪いことがある。総合テストなどでようやく露呈したときには手遅れで、予定の納期では稼働できないことも。
罠43：データの引っ越しに失敗
システム機能をきちんと構築しても、旧システムからのデータ移行に失敗すると、新システムを使った業務はうまく回らない。業務とシステムの両方に精通していないとできない難しい作業だが、軽視されがちなのが原因。
罠44：会議で疲弊
大規模なプロジェクトには関係者が多く、互いの作業に影響を与え合うため、密なコミュニケーションが必要。そのために会議が多く開かれるが、うまくファシリテーションしないと時間ばかり取られて進捗を妨げる。
****【Change Management】****
罠45：課題が積み上がってパンク
変革が進むにつれて課題（決めるべきこと、厄介なこと）が発生するのは自然だが、課題解決に時間がかかり、解決する課題よりも新たに発生する課題が多くなると、プロジェクトは前に進まなくなる。
罠46：モチベーションが低い
先行きが見通せず不安、成長実感がない、怒号が飛び交う、などプロジェクト環境が悪いと、指示された最低限の仕事だけをやるメンバーばかりになっていく。関係者も協力したいとは思わず、変革は成功しない。
罠47：進捗悪化に気付けない
進捗遅れに早く気づけば対策を打って遅れを取り戻せるのに、遅延を表明すると叱責される文化のもとでは、隠蔽／誤魔化しが起きがち。プロジェクトマネージャーが気づいた時には致命的な遅延になっている。
罠48：管理過剰
進捗遅れや品質悪化を確実に察知するためにプロジェクトをガチガチに管理しようとすると、形式主義に陥ったり、やらされ仕事が蔓延してモチベーションが低下する。結果としてプロジェクトの推進力を削ぐ。
罠49：コンフリクトを避ける
変革には立場が違う関係者が集うので意見の相違や感情的なすれ違いがつきもの。揉め事を避けるために曖昧な表現でお茶を濁したり、決定を先延ばしていると、課題が大きくなったり、成果が出ないプロジェクトになる。
罠50：レミング的思考停止
「このプロジェクトは完了できないのではないか、完了してもビジネスは良くならないのではないか」と多くの関係者が薄々感じているにも関わらず、誰も声高に主張せずに大失敗に向けて進んでいく。
****【Rollout】****
罠51：テスト不足で見切り発車
十分なテストをしないまま本番稼働に突入。初日にログイン不能やデータ不整合などの障害が頻発する。システムは切り替え済みなので旧システムに戻る訳にもいかず、顧客に迷惑をかけるなど、ビジネスに損害を与える。
罠52：修羅場を乗り越えられず
業務切替時の想定違いやシステム不具合が発生しても、規模が小さければ現場が臨機応変に対応できるもの。だが事前対策が不十分だったり、トラブルの数や規模が大きすぎると対応力を超え、運用が破綻してしまう。
罠53：やりながら人を育てない
スケジュールを守るために眼の前の仕事を優先し、育成に時間を割かず、若手メンバーに経験を積ませない。そのプロジェクトは成功しても次世代の変革リーダーが育たず、次のプロジェクトの成功確率が下がっ
てしまう。
罠54：リプランの失敗
遅延しているプロジェクトを立て直すため、実行可能な計画を立て直し、再出発する。だが漏れが多い要件定義、誤った基本設計などの根本原因を放置してしまい、新しいスケジュールからもずるずると遅延していく。
罠55：やりっぱなしプロジェクト
息も絶え絶えで本番稼働にたどり着いたものの、そこで力尽き、将来業務として描いた通りになっていない状況や、山積みの業務課題を放置する。現場は混乱したままで、当初狙っていた成果もあげられない。
以上が、本を書くにあたって選定した55の罠だ。もしかしたら「もっとこんなのもあるんじゃない？」と思った方もいるかもしれない。僕が収集した失敗原因は当初100以上あったので、それは自然なことだ。8月に執筆を終えたあとだけでも「お、その失敗原因は本に書かなかったな」という話を3つくらい聞いた。つまりプロジェクトの失敗原因は無数に存在するのだ。
だが僕が55に選ばなかった罠は、普遍性がないものが多い。特定の会社、業界、ソリューションでしか起こらないとか。または、特定の人物があまりに非合理的、理不尽な意思決定をしたとか。
という訳で、多くの人が読む価値のある、プロジェクト成功率を上げるのに役に立つリストとしては、かなり妥当なものになった自信はある。
が、もし「いやいや、これが入ってないのはおかしいでしょ」というのを思いついた方は、ぜひTwitterかFacebookで教えてください。（そのうち改訂版出すかもしれないし）