この記事の要約
- 80年前の日本軍の戦略的失敗パターンは、現代のプロダクト開発組織にも共通するものがある
- 戦略の曖昧性、過去の成功体験への固執、権限と責任の不一致という構造的問題がPdMの悩みの根源
- OKR設定、心理的安全性の確保、Two-way door decisionsなど具体的な処方箋で組織を変革できる
「なぜ我々のプロダクトは失敗したのか？」
この問いに対して、多くのPdMは技術的な問題や市場分析の甘さを挙げます。しかし、本当の原因はもっと根深いところにあるかもしれません。
『失敗の本質』によると、80年前日本軍は圧倒的な物量差がありながらも、それ以上に組織的な失敗（戦略の不在、硬直的な意思決定、環境変化への適応失敗）によって敗北しました。この失敗パターンは現代のプロダクト開発組織でも繰り返されているものがあります。
個人の能力不足よりも、組織構造そのものに問題があるケースが圧倒的に多いのです。
なぜ今、PdMが「失敗の本質」を学ぶべきなのか
『失敗の本質』は、野中郁次郎氏らが日本軍の組織的敗因を分析した名著です。ノモンハン事件、ミッドウェー海戦、ガダルカナル作戦など、日本軍の代表的な失敗事例を通じて、組織が陥りやすい構造的欠陥（システムやプロセス、文化に内在する根本的な問題）を明らかにしています。
現代のプロダクト開発現場でも、似たような失敗が起きています。
例えば、メルカリとヤフオク!の競争を思い出してください。ヤフオク!は圧倒的な先行者優位と資本力を持ちながら、なぜ新興のメルカリに市場を奪われたのでしょうか。それは過去の成功体験への固執と環境変化への適応失敗という、まさに日本軍と同じ失敗パターンだったのです。
メルカリがヤフオク!に勝てた理由の詳細はこちらで解説していますが、ヤフオク!は「オークション形式」という成功パターンに固執し、スマホ時代の「即売れる」というユーザーニーズの変化を見逃しました。
戦略の曖昧性：「何を作るか」が不明確なまま進む開発
「明確な統一的目的なくして作戦はないはずだが、日本軍ではこうしたありうべからざることがしばしば起こった」
『失敗の本質』のこの指摘は、現代のプロダクト開発にそのまま当てはまります。
例えば、「AIを使った新機能を作る」という漠然とした起点で始まるプロジェクトは近頃はあるあるですよね。
- 誰のどんな課題を解決するのか
- 成功の定義は何か
これらが曖昧なまま半年が過ぎ、結果的に誰も使わない機能が生まれてしまう。
戦略の曖昧性は以下のような症状として現れます。
- プロダクトビジョンとKPIの不整合：「ユーザー体験の向上」を謳いながら、売上だけを追う
- 顧客価値と内部都合の優先順位逆転：技術的に面白いから作る、既存資産を活用したいから作る
- 意思決定基準の不在：何を基準に機能の優先順位を決めるのか不明確
NetflixのCPO（Chief Product Officer）だったGibson Biddleは、「Product Strategy（製品戦略）なくしてProduct Roadmapは描けない」と述べています。彼らは「Delight customers in hard-to-copy, margin-enhancing ways」という明確な戦略のもと、レコメンドアルゴリズムへの投資を決定しました。
この戦略的明確性があったからこそ、NETFLIXは10年以上にわたる継続的な改善が可能だったのです。
情報断絶とフィードバック不全：データを活かせない組織の実態
日本軍の失敗要因の一つに「対人関係を過度に配慮して、一度起きてしまった失敗をしっかり総括できない」という点があります。
現代のプロダクト開発でも同じです。失敗プロジェクトの振り返りは形式的なものになりがち。「次は頑張ろう」で終わり、真の原因分析や学習が行われません。
例えばGoogleではポストモーテム（事後検証会議）という仕組みがあります。これは「Blameless（非難しない）」を原則とし、システムとプロセスの改善に焦点を当てます。
一方、多くの日本企業では以下のような状況が発生するケースもあります。
- 失敗の責任者探しに終始する
- 表面的な原因（予算不足、時間不足）で片付ける
- 同じ失敗を別のチームが繰り返す
また、情報の縦割り化も深刻。営業は顧客の声を知っているが開発に伝わらない。開発は技術的制約を知っているが営業に伝わらない。この断絶が「いらない機能」を生み出し続けています。
大企業病とプロダクトマネジメント：効率化がもたらす硬直化の罠
「カオスなプロダクト開発を効率化したら、硬くて息苦しい官僚組織になってしまった」
スタートアップ的な文化を持っていた組織が、規模拡大とともにプロセスを整備した結果、イノベーションが生まれなるケース。
大企業病の典型的症状
| 症状 | 具体例 | 影響 |
|---|---|---|
| 意思決定の遅さ | 新機能の承認に3ヶ月かかる | 市場機会の喪失 |
| 内向き志向 | 社内調整が仕事の8割 | 顧客理解の欠如 |
| リスク回避 | 前例のない施策は却下 | イノベーションの停滞 |
Spotifyの「Squad Model」は、この問題への一つの解答です。8人程度の自律的なチーム（Squad）に権限を委譲し、大企業でありながらスタートアップ的な機動力を維持しています。各Squadは独自のミッションを持ち、End-to-End Ownership（企画から運用まで一貫した責任）を負います。
権限と責任の不一致：PdMの構造的ジレンマを解消する
「プロダクトの成功に責任を持ちながら、エンジニアに指示する権限がない」
これは多くのPdMが抱える根本的なジレンマです。日本軍でも、参謀は作戦立案の責任を負いながら、実行部隊への直接的な指揮権を持たないという構造的問題がありました。
プロジェクトマネジメントとプロダクトマネジメントの違いでも触れていますが、PdMは「影響力」で人を動かす必要があります。しかし、これは個人のスキルに依存する不安定な状態です。
ここに対して、Amazon の「Single Threaded Leader」モデルは参考になります。新規事業や重要プロダクトには、完全な権限と責任を持つリーダーを一人アサインします。このリーダーは予算、人事、戦略のすべてを決定できる。結果、AWS、Prime、Alexaなど、革新的なサービスが次々と生まれました。
環境適応の罠：過去の成功体験が未来の失敗を生む
「環境に適応しすぎた」ことも失敗の本質的原因の一つ。
日本軍は日露戦争の成功体験（白兵戦、精神主義）に固執し、第二次世界大戦の機械化戦争に適応できませんでした。
MicrosoftのSatya Nadellaは、CEOに就任した2014年、「Growth Mindset（成長マインドセット）」を組織文化の中心に据えました。Windows依存から脱却し、クラウドファーストへ大胆に転換。結果、時価総額は就任時の3,000億ドルから2兆ドル超へと成長しました。
過去の成功体験への固執は、以下のような形で現れます
- 機能追加症候群：「機能を増やせば価値が上がる」という思い込み
- ユーザー像の固定化：「うちのユーザーはこういう人」という決めつけ
- 競合の過小評価：「あんな小さな会社は脅威ではない」という油断
対処法①：戦略的明確性を確立する
では、どうすれば戦略の曖昧性を解消できるのか。具体的な手法を3つ紹介します。
1. OKRとNorth Star Metricの設定
OKRの基礎から実践までで詳しく解説していますが、重要なのは「Objective（目標）」を定性的に、「Key Results（主要な結果）」を定量的に設定することです。
例：
- Objective：ユーザーの日常的な習慣にプロダクトを組み込む
- Key Result 1：DAU/MAUを40%から60%に向上
- Key Result 2：1ユーザーあたりの週間セッション数を3から7に増加
- Key Result 3：リテンション率（30日）を25%から40%に改善
2. Product Strategy Canvasの活用
Gibson Biddleが提唱するこのフレームワークは、以下の要素で構成されます：
- Target Segment：誰のために作るのか
- Customer Problem：どんな課題を解決するのか
- Value Proposition：どんな価値を提供するのか
- Competitive Advantage：なぜ我々が勝てるのか
3. RICE/ICEスコアリングによる優先順位付け
RICEスコアリングの詳細はこちらで解説していますが、Reach（到達範囲）× Impact（影響度）× Confidence（確信度）÷ Effort（工数）で機能の優先順位を数値化します。
対処法②：組織の学習能力を高める仕組みづくり
失敗から学ぶ組織になるための具体策：
1. 心理的安全性の確保
心理的安全性の重要性について詳しく書きましたが、Googleの研究では、心理的安全性がチームパフォーマンスの最重要因子であることが判明しています。
実践方法：
- 週次の「Failure Party」開催（失敗を共有し学ぶ場）
- 「I don’t know」と言える文化の醸成
- 実験の失敗を「学習」として評価する制度
2. データドリブンな振り返りプロセス
感覚ではなくデータで振り返る：
- ユーザー行動ログの詳細分析
- A/Bテスト結果の共有と考察
- 定性調査（ユーザーインタビュー）の実施
3. クロスファンクショナルな知識共有
SlackやNotionを活用した知識の民主化：
- 失敗事例のデータベース化
- ベストプラクティスの文書化
- 定期的な勉強会の開催
対処法③：権限委譲と自律的組織の構築
1. Empowered Product Teamの構築
Marty Caganが『INSPIRED』で提唱する「Empowered Team」は、以下の特徴を持ちます：
- 問題解決のHowを自分たちで決められる
- 顧客と直接対話する権限がある
- 実験と失敗が許容される
2. Two-way door decisionsの導入
Amazonの意思決定フレームワーク：
- One-way door：後戻りできない重大な決定（慎重に）
- Two-way door：やり直し可能な決定（素早く）
ほとんどの機能開発はTwo-way doorです。完璧を求めず、70%の確信度で実行し、早期に学習する。
3. プロダクトオーナーシップの明確化
各機能やKPIに「Owner」を明確に設定：
- 成功も失敗も個人/チームに帰属
- 権限と責任の一致
- 定期的なOwnershipレビュー
失敗を成功に変える：組織文化をどう醸成するか
最後に、「それでも組織は失敗する」ことを前提とした組織設計が必要です。
SpaceXのElon Muskは「Failure is an option here. If things are not failing, you are not innovating enough」と述べています。実際、SpaceXは数多くのロケット打ち上げ失敗を経験しながら、それを学習機会として活用し、現在では世界最先端の宇宙企業となりました。
失敗を活かす文化の3要素
| 要素 | 具体的施策 | 期待効果 |
|---|---|---|
| 透明性 | 失敗事例の全社共有、ポストモーテムの公開 | 組織全体の学習速度向上 |
| 実験文化 | 10%ルール（業務時間の10%を実験に）、Hack Day | イノベーションの創出 |
| 長期視点 | 四半期だけでなく年間・3年計画での評価 | 本質的な価値創造 |
歴史に学び、未来を創る
『失敗の本質』が示す日本軍の組織的失敗は、80年経った今でも私たちに重要な示唆を与えています。戦略の曖昧性、学習の欠如、環境適応の失敗。これらは形を変えて、現代のプロダクト開発組織にも存在しています。
しかし、悲観する必要はありません。歴史から学び、具体的な処方箋を実践することで、組織は確実に変わります。NetflixもSpotifyもAmazonも、失敗を重ねながら学習し続けることで今の成功を築きました。
PdMとして重要なのは、個人の能力向上だけでなく、組織の構造的問題に目を向けること。そして、小さくても確実な一歩を踏み出すことです。
「愚者は経験に学び、賢者は歴史に学ぶ」。ビスマルクのこの言葉を胸に、失敗の本質を理解し、成功への道筋を描いていきましょう。
今日から実践できるアクション
- 戦略の言語化：今のプロダクトの戦略を1文で表現してみる。できなければ、それが問題の始まり
- 失敗の棚卸し：過去3ヶ月の失敗を3つ挙げ、その真因を「なぜなぜ分析」で探る
- 権限マッピング：自分が決められること/決められないことをリスト化し、上司と認識を合わせる
- 小さな実験開始：Two-way doorな施策を1つ選び、今週中に実行する
- 学習の仕組み化：チームで週30分の「Learning Session」を設定する
Q&A
Q1: 小規模スタートアップでも「失敗の本質」の教訓は適用できますか？
A: むしろスタートアップこそ重要です。組織が小さいうちに正しい文化とプロセスを確立することで、スケール時の「大企業病」を予防できます。特に「戦略の明確性」と「学習する組織」の2点は、リソースが限られるスタートアップにとって生命線となります。
Q2: 上司が保守的で、新しい取り組みに消極的な場合はどうすればよいですか？
A: 上司からのNOを減らす方法でも書きましたが、まず小さな成功事例を作ることです。リスクの低い施策から始め、データで成果を示す。「失敗の本質」の教訓も、歴史的事実という客観的な根拠として活用できます。
Q3: 心理的安全性を高めようとしても、評価制度が減点主義の場合は？
A: 確かに制度と文化のギャップは難しい問題です。まずは自分のチーム内だけでも「実験の失敗は学習」という価値観を共有し、チーム内での心理的安全性を確保する。その成果を可視化して、徐々に組織全体に広げていくボトムアップアプローチが現実的です。
Q4: OKRを導入したいが、どこから始めればよいですか？
A: まず個人OKRから始めることをお勧めします。3ヶ月単位で自分の目標を設定し、週次で進捗をトラッキングする。この経験を踏まえてチームOKRへ展開すると、実感を持って導入できます。OKRの詳細な運用方法はこちらを参考にしてください。
参考文献・情報
- 野中郁次郎他『失敗の本質―日本軍の組織論的研究』（中公文庫、1991年）
- Marty Cagan『INSPIRED: How to Create Tech Products Customers Love』（Wiley、2017年）
- Gibson Biddle「How to Define Your Product Strategy」（Medium、2019年）
- Google re:Work「Guide: Understand team effectiveness」（2016年）
- Jeff Bezos「2016 Letter to Shareholders」（Amazon、2017年）
- Satya Nadella『Hit Refresh』（HarperBusiness、2017年）
- SpaceX「Falcon 9 First Stage Landing」（SpaceX、2015年）
- Spotify Engineering Culture（Spotify、2014年）
コメント