inspired-product

エンパワードプロダクトチームのフレームワーク

継続的なディスカバリーとデリバリーを担う、権限を与えられたチームを通じて、顧客に愛されるプロダクトを構築するためのフレームワークです。優れたプロダクト企業は機能をリリースするのではなく、問題を解決し、その方法を見つけ出すための自律性と説明責任をチームに与えます。

基本原則

エンパワードプロダクトチーム ＝ 機能を開発するのではなく、解決すべき問題を与えられ、ディスカバリーからデリバリーまでを一貫して担う、部門横断型のグループです。

多くのプロダクトの失敗は、エンジニアリングやデザインの質が低いことではなく、誰も求めていないものを作ることが原因です。機能チームはロードマップを受け取って実行しますが、エンパワードチームは目標を受け取り、解決策を見つけ出します。機能工場とイノベーションエンジンを分けるのは、チームがビジョンと共感に動かされる宣教師なのか、上から渡されたバックログに動かされる傭兵なのかという点です。

スコアリング

目標：7/7。 以下のクイック診断に基づいて、プロダクトチームの構造、ディスカバリーの実践、またはデリバリープロセスを評価します。該当する行ごとに1ポイントを加算し、0～7点で採点します。評価区分：6～7 ＝ エンパワードチームが成果を担い、エンジニアも参加してディスカバリーが継続的に行われています。4～5 ＝ ディスカバリーは行われていますが一貫性がない、またはチームは成果物を担うものの、成果に対する説明責任は一部に限られています。3以下 ＝ 機能工場です。チームは日付指定の機能を並べたロードマップを受け取り、ディスカバリーを省略します。現在のスコアと、7/7を達成するために修正が必要な具体的な診断項目を必ず示してください。

フレームワーク

1. プロダクトディスカバリーとデリバリー

基本概念： プロダクト開発は、並行して進む2つのトラックで行われます。ディスカバリーでは、エンジニアリングに投資する前にリスクに対処し、何を作るかを見極めます。デリバリーでは、本番品質のソフトウェアを構築します。多くの組織はディスカバリーを完全に省略し、アイデアからバックログ、そしてスプリントへと進みます。

有効な理由： ディスカバリーは低コストかつ迅速ですが、デリバリーは高コストで時間がかかります。着手する前にアイデアを検証すれば、最もよくある失敗、つまり誰も求めていないものを作ることを避けられます。

主なポイント：

• ディスカバリーでは、4つのリスクに答えます。価値（顧客は使うか？）、ユーザビリティ（使い方がわかるか？）、実現可能性（構築できるか？）、事業性（ビジネスとして成り立つか？）
• ディスカバリーの成果は、PRDや仕様書ではなく、エビデンスに裏付けられた検証済みのアイデアです
• デリバリーに進む各機能について、ディスカバリーの反復を10～20回行います。ほとんどのアイデアはうまくいかないため、早く、低コストで失敗しましょう
• ディスカバリーは一度限りのフェーズではありません。デリバリーと並行して継続的に行い、エンジニアも参加します

プロダクトへの適用例：

コンテキスト	適用方法	例
新機能	着手を決める前に4つすべてのリスクを検証する	構築前に、5人のユーザーでオンボーディングフローのプロトタイプをテストする
ロードマップの優先順位付け	最も強いディスカバリーのエビデンスを優先する	CEOの要望ではなく、5人中4人のユーザーテストに成功した機能をリリースする
スプリント計画	検証済みのディスカバリー成果をバックログに反映する	ディスカバリーでテスト済みの項目だけをスプリントに含める

倫理的な境界： すでに決めた結論を正当化するために、都合のよいディスカバリーのエビデンスだけを選んではいけません。成功したテストだけでなく、失敗したテストも報告してください。

ディスカバリーサイクルを計画する際は、references/discovery-techniques.mdを参照してください。4つのリスクのフレームワーク、5段階のインタビュー台本、プロトタイピングの手法、「検証済み」とするための具体的なエビデンス基準が記載されています。

2. エンパワーされたプロダクトチーム

中核となる概念： プロダクトマネージャー、プロダクトデザイナー、エンジニアで構成される、小規模で長続きする職能横断型のグループです。解決すべき課題を与えられ、ディスカバリーとデリバリーを担い、アウトプットではなく成果に責任を負います。

効果がある理由： 顧客とテクノロジーに最も近い人々は、遠く離れたロードマップの作成者よりも優れた解決策を見つけます。また、自分たちで解決策を発見したチームは、プレッシャーの下でもその解決策を擁護し、改善します。一方、仕様書を渡されたチームは、それをリリースすると次へ移ります。

重要な洞察：

• PM はプロジェクトマネージャーやバックログ管理者ではありません。価値と実現可能性を担い、顧客、データ、ビジネス、業界について深い知識を持つ必要があります
• プロダクトデザイナーは、ビジュアルデザインだけでなく、ユーザー体験全体を担います
• エンジニアは技術的に可能なことを把握しているため、イノベーションの最良の源です
• チームを長続きさせ（メンバーを安定させ）、高度に協力し合えるようにします
• 説明責任の対象は成果（導入、継続率、収益）であり、アウトプット（リリースしたストーリー）ではありません

プロダクトへの応用：

コンテキスト	応用	例
チーム構成	コンポーネントではなく、成果を中心に編成する	「新規ユーザーのアクティベーション」チームが、初週の体験全体を担います
採用	資格ではなく能力を基準に PM を採用する	顧客に関する知識、データ活用能力、ビジネス感覚を評価します
パフォーマンス	速度ではなく結果を測定する	スプリントあたりのストーリー数ではなく、アクティベーション率の改善を追跡します

倫理的境界： 経営陣の指示でチームのディスカバリー結果を覆しながら、チームに権限を与えていると主張してはいけません。リーダーシップが解決策を決めるのであれば、チームは権限を与えられていません。

チームの人員配置や状況の診断を行う際は、references/empowered-teams.md を参照してください。役割ごとの能力の内訳と危険信号、ミッショナリーと傭兵の力学、コーチング、機能工場から権限を与えられたチームへの変革表が記載されています。

3. プロダクトディスカバリーの手法

中核となる概念： 機会評価、顧客インタビュー、プロトタイピング、ユーザーテストを用いて、4つのリスクに照らしてアイデアを体系的に検証し、迅速かつ低コストで証拠を得ます。

効果がある理由： アイデアは仮説です。迅速な検証を行わなければ、チームは未検証の仮説に基づいて何か月も開発し、リリース後に初めて失敗に気づきます。ディスカバリーの手法により、学習サイクルを数か月から数日に短縮できます。

重要な洞察：

• プロトタイプは主要なツールです。ユーザビリティには高忠実度、実現可能性にはライブデータ、価値には Wizard of Oz を使います
• 同僚ではなく、実際のターゲットユーザーでテストします。定性的テスト（5人のユーザー）で問題を見つけ、定量的テストで規模を拡大して検証します
• 意見（欲しいと言うもの）ではなく、行動（実際にしたこと）についてインタビューします
• データからパターンは分かりますが、原因は分かりません。定性的なディスカバリーと組み合わせます
• フィージビリティスパイクを行うと、エンジニアは本格的な実装をせずに技術的リスクを調査できます

プロダクトへの応用：

コンテキスト	応用	例
初期アイデア	デザイン作業の前に機会を評価する	誰のためのものか、どのような問題を解決するのか、成功をどう測定するのか？
ユーザビリティ	ターゲットユーザー5人を対象にした高忠実度プロトタイプ	クリック可能な Figma プロトタイプでタスク完了をテストします
価値	フェイクドアまたは Wizard of Oz テスト	未構築の機能のボタンを設置し、クリック率を測定します
実現可能性	エンジニアリングスパイク	リアルタイム同期のリスクを2日間かけて調査します

倫理的境界： 有効な結果を得るために必要な範囲を超えて、ユーザーを欺いてはいけません。Wizard of Oz プロトタイプは許容されますが、存在しない製品の代金を受け取ることは許されません。

4. 機会評価

中核となる概念: あらゆる機会に投資する前に、構造化された一連の問いに照らして、ビジネス価値、顧客ニーズの深刻度、市場の状況、組織の準備状況を評価します。

うまく機能する理由: 組織には実行能力をはるかに超えるアイデアがあります。厳格な評価がなければ、チームは最も声の大きいステークホルダーや競合との同等性に従ってしまいます。共通のフレームワークは、悪いアイデアを早い段階で断ち切り、リソースをインパクトの大きい仕事に集中させます。

主要な洞察:

• 主要な問い: これはどのビジネス目標に貢献するのか? ターゲット顧客は誰か? どんな課題か? 成功したことをどうやって知るのか? どのような代替案が存在するか?
• 顧客の課題の深刻度は、ソリューションの洗練度よりも重要である
• 市場のタイミングは決定的に重要である -- 早すぎることは遅すぎるのと同じくらい危険である
• 組織の準備状況を確認する: スキル、技術、Go-to-Market 能力
• リソースを投入する前に、評価を広く共有して合意形成を図る

プロダクトへの応用:

状況	応用	例
四半期計画	すべての候補を一貫した基準で採点する	機会ごとの顧客の深刻度、ビジネスインパクト、実現可能性
ステークホルダーからの要望	コミットではなく評価で応答する	「これを評価し、エンジニアリングにコミットする前に調査結果を共有します」
リソース配分	最も評価の高い機会に資金を配分する	深刻な課題 + 明確なビジネスとの整合性は、あれば嬉しい機能に勝る

設計作業の前に新しい機会を評価する際は、references/opportunity-assessment.md を参照してください -- 評価質問の完全なセット、市場タイミングの評価、優先順位付けのスコアリングについて記載されています。

役員や営業のステークホルダーがソリューションを押し付けてきたり、HiPPO がロードマップを誘導したりする場合は、references/stakeholder-management.md を参照してください -- ステークホルダーのマッピング、命令を評価すべき課題に変える方法、 evangelism、役員の信頼の構築について記載されています。

5. プロダクトビジョンと戦略

中核となる概念: ビジョンは目指す未来を描きます(2〜5年先)。戦略はそれを実現するターゲット市場、課題、ソリューションを順序立てます。両者が揃うことで、権限を与えられたチームが自律的に良い意思決定を行うための文脈が得られます。

うまく機能する理由: ビジョンがなければ、チームはバラバラな意思決定をします。戦略がなければ、あれもこれもと追いかけて何も達成できません。ビジョンは鼓舞し、戦略は焦点を絞ります。

主要な洞察:

• ビジョンは鼓舞するものであり、顧客中心である -- 作りたい世界であり、機能リストではない
• 戦略は難しい選択を順序立てる: どの顧客を先に、どの課題を先に、どのソリューションを先に
• プロダクト原則は、戦略がカバーしない意思決定のためのガードレールである
• OKR は戦略を測定可能なチームの目標に変換する。成果ベースのロードマップは、ソリューションを規定することなく意図を伝える
• ビジョンは年に一度、戦略は四半期ごとに見直す。原則はめったに変わらない

プロダクトへの応用:

状況	応用	例
全社の合意形成	ビジョンはすべてのチームを共通の未来に揃える	「すべての中小企業が世界水準の金融ツールを利用できるようにする」
チームの自律性	戦略は各チームの焦点を定める	「今四半期: 上位3つの課題を通じてミッドマーケットの解約を削減する」
意思決定	原則がトレードオフを解決する	「迷ったら、パワーよりもシンプルさを選ぶ」

倫理的な境界: チームを動機づけたり投資を集めたりするために、達成不可能だと分かっているビジョンを決して提示してはなりません。

ビジョンと戦略を起草または見直す際は、references/product-vision.md を参照してください -- それぞれの書き方、プロダクト原則、戦略の OKR への変換、成果ベースのロードマップの構築について記載されています。

6. 継続的な価値の提供

中核となる概念： デリバリーはローンチイベントではなく、検証済みの小さな単位をできるだけ頻繁に実ユーザーへ届ける継続的な流れです。

効果がある理由： 頻度の低い大規模なリリースはリスクを蓄積させ、学習を遅らせ、調整を悪夢のように困難にします。デリバリーとディスカバリーのフィードバックループは、学習エンジンとして効果を積み重ねます。リリースし、測定し、学び、調整します。

主な知見：

• 小さく頻繁にリリースします。リリースのたびに学ぶ機会が得られます
• 計測は必須です。測定できなければ、学ぶこともできません
• フィーチャーフラグを使うとデプロイとリリースを切り離せるため、段階的なロールアウトや迅速なロールバックが可能になります
• MVPは仮説を検証するための最小のリリースであり、未完成の製品ではありません
• 技術的負債は金銭的な負債と同様に、意識的なトレードオフとして管理します

プロダクトでの適用例：

コンテキスト	適用方法	例
リリース計画	個別にリリース可能な単位に分ける	まず基本的な検索を提供し、次にフィルター、最後に検索の保存機能を追加する
リスク管理	フィーチャーフラグでロールアウトを制御する	5%にリリースして測定し、対象を拡大するかロールバックする
学習ループ	すべてのリリースを計測し、ディスカバリーに役立てる	検索の利用率が低い場合、ディスカバリー調査を開始する

倫理的な境界： ロールバックできない変更は決してリリースしないでください。リスクのあるものはすべて、オフにできるフラグの背後に置きます。

フレームワークを適用する前に具体例を確認したい場合は、references/case-studies.mdを参照してください。これらの原則が、スタートアップ、成長期、エンタープライズの各段階でどのように実践されたかが記載されています。

よくある間違い

間違い	失敗する理由	対策
PMをプロジェクトマネージャーとして扱う	価値や実現可能性に責任を持たない、依頼をこなすだけの担当者になる	顧客理解、データ活用能力、ビジネス感覚を基準に採用し、成果に対する責任を持たせる
ディスカバリーを省略する	誰も求めていない機能の開発に数か月を費やす	アイデアがデリバリーバックログに入る前に、検証済みの根拠を求める
成果ではなくアウトプットを測定する	チームが顧客価値よりリリース速度の最適化を優先する	成功を、導入率、継続率、収益への影響で定義する
問題ではなく解決策をチームに渡す	意欲や創造性のない機能工場になる	目標と主要な成果を設定し、チームに解決策を見つけさせる
エンジニアを顧客から遠ざける	イノベーションの最大の源泉が問題を目にする機会を失う	インタビュー、ディスカバリー、プロトタイプのテストにエンジニアを参加させる
日付付きで機能を約束するロードマップ	ディスカバリーで検証する前に、約束が固定化される	機能ではなく解決すべき問題を示す、成果ベースのロードマップを使う

簡易診断

質問	「いいえ」の場合	対応
PMは直接観察した顧客の主要な課題を3つ挙げられますか？	PMが顧客を理解していない	毎週、顧客と接する機会を設けます。インタビュー、サポート対応の観察、テストなどを行います
構築前に、実ユーザーでアイデアをテストしていますか？	ディスカバリーを省略している	重要なアイデアごとに、ターゲットユーザー5人でプロトタイプをテストします
エンジニアはデリバリーだけでなく、ディスカバリーにも参加していますか？	イノベーションの最大の担い手を十分に活用していない	インタビューやプロトタイプのセッションにエンジニアを招きます
チームはアウトプット（機能）ではなく、成果（指標）に責任を持っていますか？	機能工場になっている	機能ロードマップを成果ベースのOKRに置き換えます
チームメンバーはビジョンと戦略を説明できますか？	自律的な意思決定に必要な文脈がない	ビジョンの文書と四半期ごとの戦略を作成し、周知します
ステークホルダーは解決策ではなく、問題を提示していますか？	リーダーシップが機能を指示している	ディスカバリーについてステークホルダーをコーチングし、機会評価を通じて事前に合意を得ます
検証済みの単位を少なくとも2週間ごとにリリースしていますか？	学習するには遅すぎる	より小さな単位にし、CI/CDとフィーチャーフラグに投資します

さらに読む

手法の全容、事例研究、より深い知見については、以下をご覧ください。

• "Inspired: How to Create Tech Products Customers Love"（Marty Cagan 著）
• "Empowered: Ordinary People, Extraordinary Products"（Marty Cagan、Chris Jones 著）

著者について

Marty Cagan は Silicon Valley Product Group（SVPG）の創設者であり、eBay の元プロダクト担当 VP です。HP、Netscape、AOL でもプロダクト分野の上級職を務めました。著書 Inspired（2008 年、第 2 版は 2017 年）は、現代のプロダクトマネジメントに関する決定版ガイドとなり、Empowered（2020 年）ではそのフレームワークをプロダクトリーダーシップへと広げています。SVPG を通じて、スタートアップから Fortune 500 企業まで、さまざまなプロダクトチームをコーチングしています。