「どれだけ優れたエンジニアが、どれだけ美しいコードを、どれだけ速く書いたとしても、それが『作る価値のないもの』であれば、すべては無駄になる。」
プロダクトマネジメントの世界において、これほど残酷で、かつ核心を突いた真実はありません。世界中のプロダクトマネージャー（PM）がバイブルとして崇めるマーティ・ケーガンの著書『INSPIRED』は、私たちに一つの問いを突きつけます。あなたは、顧客の人生を豊かにする「製品」を作っているのか、それともただの「機能」を量産しているのか。
多くの現場では、今日も「誰も使わない機能」のために貴重なリソースが浪費されています。その背景には、開発を単なる「効率的な作業」と捉える前時代的な管理主義が潜んでいます。しかし、市場の不確実性が高まり続ける現代において、私たちが目指すべきは「確実な実行」ではなく「不確実な学習」です。
この記事では、伝説的なPMであるマーティ・ケーガンの思想を解体し、明日からあなたのチームを「機能工場」から「イノベーションの源泉」へと変えるための具体的なロードマップを提示します。この記事を読み終える頃、あなたは「ゴミを高速で作る」という悪夢から解放され、真に価値あるプロダクトを生み出すための武器を手にしているはずです。
なぜあなたのプロダクトは「使われない」のか？
「素晴らしいアイデアだと思ったのに、リリースしてみたら誰も使ってくれなかった」そんな経験をしたことはないでしょうか。実は、一般的な企業がリリースするプロダクト機能の約半分は、実際にはほとんど、あるいは全く使われていないという厳しい現実があります。なぜ、これほどまでに多くの時間と才能が、無意味なものに費やされてしまうのでしょうか。
その最大の理由は、私たちが「何を作るか」を決めるプロセスそのものに欠陥があるからです。多くの組織では、経営層や営業部門から降りてきた「機能リスト」を、PMが要件定義書に落とし込み、デザイナーがUIを整え、エンジニアが実装します。この流れは、一見効率的に見えますが、実は重大なリスクをすべて後回しにしています。
機能を作るだけの「機能工場」からの脱却
「プロダクトチーム」と名乗っていても、実態は「オーダー（注文）をこなすだけの機能工場（Feature Factory）」に陥っているケースが少なくありません。そこでは、ロードマップは単なる「納期の約束リスト」と化し、チームの評価は「どれだけ多くの機能をリリースしたか」というアウトプットで測られます。
しかし、本来プロダクト開発が目指すべきは、機能の数ではなく、顧客の課題を解決したという「成果（アウトカム）」であるべきです。機能工場から脱却するためには、PMの役割を「要件の伝達役」から「価値の発見者」へと再定義しなければなりません。
料理に例えるなら、ディスカバリー（発見）は「試食」です。客に提供する前に味を確認し、調味料を調整する。一方で、デリバリー（配信）は「調理」です。機能工場は、味見を一度もせずに100人分の料理を完成させ、テーブルに並べてから「まずい」と言われるのを待っているようなものです。どれだけ調理スピードが速くても、味が伴わなければその努力はすべて徒労に終わります。
「SNSでは『うちの会社はエンジニアがただの作業員になっている』という嘆きをよく目にしますが、それはまさに機能工場化の兆候です」という専門家の指摘もあります。私たちがまず取り組むべきは、開発（デリバリー）の前に、十分な検証（ディスカバリー）の時間を組み込むという劇的なマインドセットの転換なのです。
プロダクトマネージャーの真の役割：4つのリスク検証
PMの仕事とは何でしょうか。プロジェクトの進捗を管理し、チケットを切ることでしょうか。マーティ・ケーガンは、PMの真の職務は市場と技術の交差点で「価値」を発見することにあると断言します。
優れたPMは、開発に着手する前に必ず「4つのリスク」を潰します。これが有名なプロダクト・ディスカバリーのフレームワークです。これら4つの観点のうち、1つでも欠けていれば、そのプロダクトは失敗へと向かいます。
価値・使い勝手・実現性・事業性をどう見極めるか
- 価値リスク（Value Risk）：顧客は本当にお金や時間を払ってまで、これを使ってくれるか？
- 使い勝手リスク（Usability Risk）：ユーザーは使い方を理解できるか？
- 実現性リスク（Feasibility Risk）：現在の技術、時間、予算で実際に作れるか？
- 事業性リスク（Business Viability Risk）：その解決策は、営業、法務、財務など、自社のビジネスモデルと整合しているか？
「ユーザーが見るUIは氷山の一角。PMが解決すべき事業性や実現性のリスクは、水面下に隠れた巨大な本体である」という比喩がある通り、PMは目に見える部分だけでなく、プロダクトがビジネスとして成立するかどうかの土台を検証し続けなければなりません。
特に重要なのは、価値リスクの検証です。顧客に「これが欲しいですか？」と聞くのは不十分です。顧客は自分が何を求めているかを知らないことが多いからです。ディスカバリーの目的は「顧客の要望を叶えること」ではなく「顧客の課題を解くこと」でなければなりません。
業界内では「顧客の声を聞きすぎることは、漸進的な改善に留まり、破壊的イノベーションを阻害する」という見方が広がっています。真の発見は、顧客の発言の裏側にある「痛み」を観察し、プロトタイプを用いてその反応を測定することから生まれます。プロトタイプは、単なる「下書き」ではありません。それは、被害を最小限に抑えるための事前の避難訓練なのです。
エンジニアを「コードを書く人」として扱っていませんか？
『INSPIRED』の中で最も有名な教えの一つが、「エンジニアを傭兵（Mercenaries）にするな、宣教師（Missionaries）にせよ」という言葉です。
多くのPMは、仕様を完全に固めてからエンジニアに「これを作ってください」と依頼します。これは、エンジニアを単なる実装担当、つまり「傭兵」として扱っているのと同じです。傭兵は指示されたことだけをこなし、定時になれば去ります。彼らのモチベーションは給料であり、プロダクトの成功ではありません。
「傭兵」を「宣教師」に変えるディスカバリーへの巻き込み方
一方で「宣教師」は、解決すべき課題を深く理解し、そのビジョンを達成するために自分の技術をどう活かすかを考え抜きます。エンジニアは、組織の中で最も優れた課題解決能力（エンジニアリング的思考）を持っている存在です。彼らを仕様の末端で使うのは、宝の持ち腐れと言わざるを得ません。
「指示されたコードだけを書くのは給料のために戦う傭兵。課題解決のために技術を振るうのは、ビジョンのために戦う宣教師だ」というパンチラインが示す通り、エンジニアをディスカバリーの初期段階から巻き込むことが不可欠です。
具体的には、エンジニアを週に一度、顧客インタビューやデータ分析の議論に同席させてください。彼らが顧客の痛みを直接肌で感じることで、「あ、その技術的な制約なら、こういう別の方法で解決できますよ」という魔法のような提案が生まれることがあります。
航海に例えるなら、PMは「どこに向かうべきか」を記した海図を作る人、エンジニアは「荒波を越えて進む」操船を担当する人です。しかし、エンジニアも海図を一緒に見ていなければ、不意に現れた岩礁（技術的な困難や市場の急変）を回避することはできません。PMとエンジニアが同じ視界を共有したとき、チームの突破力は最大化されます。
「専門家の間では、イノベーションの8割はエンジニアの『これ、できるんじゃないか？』というひらめきから生まれるという意見もあります」という事実は、PMがいかに謙虚に、そして戦略的にエンジニアをパートナーとして扱うべきかを物語っています。
今日から始めるプロダクト・ディスカバリー実践ガイド
理論は分かりましたが、具体的にどのように組織を動かせばよいのでしょうか。機能リストで埋め尽くされたロードマップを目の前にして、立ち往生しているPMは多いはずです。
まず、ロードマップに対する認識をアップデートしましょう。「ロードマップは約束のリストではなく、仮説のリストであるべき」です。決まった日付に決まった機能を届ける約束をするのではなく、「どの課題を解決するか（＝アウトカム）」を約束するのです。
アウトカム重視のロードマップへの転換
今日からできる最小のアクションは、エンジニアを顧客インタビューの現場へ一人連れて行くことです。これだけで、チーム内の空気が変わり始めます。
中期的には、4つのリスクを検証するための「プロトタイプによるテスト」をルーチン化しましょう。高精度のモックアップを作成し、実際のユーザーに触ってもらう。コーディングを始める前に、それが価値を生むという確信（エビデンス）を得るプロセスを確立するのです。
しかし、ここで注意点があります。「ディスカバリーが優れていれば、それだけで勝てる」というわけではありません。どんなに素晴らしい海図があっても、船そのものがボロボロであったり、漕ぎ手が遅すぎたりすれば（開発品質・速度）、目的地にはたどり着けません。インスパイアされすぎるあまり、デリバリー（着実な開発）の規律を軽視するのは本末転倒です。
私たちは常に、知の探索（ディスカバリー）と知の深化（デリバリー）の両輪を回し続けなければなりません。それは、不確実な暗闇の洞窟を、信頼できる仲間と共に、松明を掲げて進む旅のようなものです。何度も転び、行き止まりに突き当たりながらも、検証という光を頼りに真の宝（価値）を見つけ出す。このプロセスこそが、プロダクト開発の本質的な面白さであり、苦しみでもあります。
まとめ：最強のプロダクトチームを作るために
『INSPIRED』が教えてくれるのは、単なるフレームワークではありません。それは、人間を「労働力」ではなく「知能（課題解決者）」として信じるという、文化的な覚悟の問い直しです。
本記事の要点を振り返ります。
- 「機能工場」からの脱却：アウトプット（機能数）ではなく、アウトカム（成果）で自分たちを評価する。
- 4つのリスク検証：価値・使い勝手・実現性・事業性を、開発着手前にプロトタイプで潰す。
- エンジニアを宣教師に：初期段階から課題を共有し、共創のパートナーとして巻き込む。
もしあなたが今日から何かを変えたいと思うなら、まずは次の会議でこう問いかけてみてください。「この機能は、誰の、どの課題を、どう解決し、それは我々のビジネスにどう貢献するのか？」と。
不確実な世界で、唯一確実なのは「今のままでは通用しなくなる」ということだけです。ゴミを高速で作るのをやめ、世界を少しだけ良くする「価値」を、あなた自身のチームで発見しにいきましょう。
エンジニアを傭兵にするな、宣教師にせよ。その一歩が、あなたのプロダクトを「伝説」に変えるのです。
コメント