はじめに：PdMが「発散」と「収束」を深く学ぶべき理由
プロダクトマネージャー（以下、PdM）にとって、アイデア発想から要件定義・優先度付け・実装・検証に至る一連の工程をスムーズに進めることは最重要課題の一つ。
その過程では以下2つのフェーズが繰り返し訪れます。
- 「ダイバージェント思考（発散思考）」によって多様なアイデアを創出するフェーズ
- 「コンバージェント思考（収束思考）」によって要点を絞り込み、リソースを最適配
これら2つの思考の切り替えをミスると、発想が広がらず中途半端な機能に落ち着く、あるいはアイデアばかりが乱立して意思決定できなくなるというリスクが高まります。
この記事では、単なるブレインストーミング（ブレスト）や優先度付けの話にとどまらず、実践的なフレームワークと手法を「使い方のステップ」まで詳しく解説します。
ダイバージェント思考（発散思考）を深堀りする
ダイバージェント思考の目的は「できるだけ多角的に可能性を広げ、まだ言語化されていない課題や潜在的なチャンスを掘り起こすこと」。しかし実際には「ブレストしましょう」の一言だけで終わり、単なる意見交換で流れてしまうケースが多いです。ここでは、より奥深いダイバージェント思考を実践するためのフレームワークを紹介します。
SCAMPER法
SCAMPERは下記7つの観点に基づき、既存のアイデアやプロダクトを変形し、新しい価値を創造するフレームワークです。
- Substitute（代替できないか）
- Combine（組み合わせられないか）
- Adapt（応用できないか）
- Modify / Magnify（変更・拡張できないか）
- Put to other uses（他の用途に転用できないか）
- Eliminate（除去・削減できないか）
- Reverse / Rearrange（逆転・再配置できないか）
SCAMPER法の具体的な使い方
- まず「見直したい対象（既存機能・新機能のアイデア）」を1つ決める
- ホワイトボードやオンラインツール（Miro, FigJamなど）を使い、上記7観点を縦軸に並べる
- チームメンバーには、各観点で思いつく限りのアイデアを箇条書きで書き出すよう促す。この段階で「こんなアレンジは無理だろう」「非現実的だろう」という否定は一切NG。
- 全員が書き終わったら、重複したものをまとめたり関連性が高いものをグルーピングし、アイデアを俯瞰。この段階でチームは「こんなアプローチもあったのか」という驚きを得るはず。
6 Thinking Hatsで発散を“感情・ロジック・創造”に切り分ける
エドワード・デ・ボノが提唱する「6 Thinking Hats」は、チームメンバーの思考を6つの視点（感情・肯定・否定・ロジック・創造・プロセス管理）に切り分けて進める方法。具体的には、会議の中で
- 「白帽タイムはファクトに集中」
- 「緑帽タイムは自由にアイデアを出す」
- 「黒帽タイムはリスクを徹底的に想定する」
など、帽子（視点）を被り変えながら議論を展開します。
6 Thinking Hatsの具体的な使い方
- まずファシリテーターが「今は白帽。数字や事実、ログ分析、ユーザーインタビュー結果など客観的情報のみを出しましょう」と宣言。
- 次に「今は緑帽。事実の縛りを一旦忘れて、新しいアイデアを自由にブレスト」という時間に切り替えます。
- 「今は黒帽。リスクや問題点をすべて洗い出す」など、一定時間ごとに帽子を交代して視点を変化させます。
このように各視点に集中することで、アイデアを膨らませる時間と課題を洗い出す時間を明確に区切れるため、本来同時並行では生まれない質の高い発散が得られます。議論が混線しにくい点もメリットです。
コンバージェント思考（収束思考）の実践フレームワーク
アイデアを大量に出しても、最終的に実装できるのはごく一部です。リソースには限りがあるため、コンバージェント思考を用いて「優先度を適切につける」「本当に必要なアイデアを見極める」工程が必須。
Opportunity Solution Tree (OST)で全体俯瞰しながら決める
Teresa Torres氏が提唱した「Opportunity Solution Tree（OST）」は、「実際に解決すべき機会（Opportunity）」を木の幹に見立て、その枝として様々な解決策（Solution）を紐づけ、さらに実行プランを細分化していく手法です。
具体的なステップ
- まずユーザーインタビューなどの定性情報から、解決すべきコア課題＝「機会（Opportunity）」を洗い出す（例：組織内のコミュニケーション不足）。
- そこから派生する形で、考え得る解決策（Solution）を枝状に配置（例：「チャット機能強化」「ピアレビューの仕組み」「匿名フィードバック制度」など）。
- 各Solutionに対して、インパクト・実装難易度・リスクなどを検討し、優先度を並べ替える（最上位の枝が実際に最優先となる解決策）。
- 上位の解決策について、さらに具体的な施策案や検証計画（ペーパープロトタイプ作成、スプリントでの実装）を枝葉として追加する。
こうして「どの機会に対して、どの解決策を最優先すべきか」をビジュアルに把握できるようになります。チーム全員が同じツリーを見ているため、収束の議論がブレにくくなるメリットがあります。
AHP（Analytic Hierarchy Process）による多層的比較
AHPは大規模・複雑な意思決定に向いた手法で、「重要な意思決定要素を階層構造に分解→ペアワイズ比較→重み付け」を行うことで定量的な評価を導きます。
例えば「売上インパクト」「開発工数」「利用ユーザー数」「リスク」などの要素を階層化し、各要素を2つずつ比較して重みを決定します。そのうえでアイデア候補を評価すると、主観を排除しやすくなります。
具体的な手順
- PdMやステークホルダーで「評価項目」を決める
- 例：①市場規模 ②技術的難易度 ③UX向上度 ④既存ユーザーへの影響 ⑤実装の緊急度 など。
- 2「市場規模 vs 技術的難易度」「市場規模 vs UX向上度」のように、各ペアを比較し、どちらがどれだけ重要かを数値（1～9など）で入力する。
- AHPのアルゴリズムで一貫性をチェックしながら、最終的な重みを算出。
- 候補となる各アイデアを、手順2で得た重みに基づいて合計スコア化し、優先度を順位付けする。
このように客観的な数値によって評価するため、チーム内で「感覚的にこれがいい気がする」という議論が減り、よりスムーズに絞り込みを行えるのがメリットです。
発散と収束を繰り返す実務プロセスの設計
アイデア創出（ダイバージェント）と優先度付け（コンバージェント）は一度で終わりではなく、スプリントやフェーズごとに繰り返されます。実務に落とし込む際に陥りやすい問題と、それを解決するための工夫を紹介します。
「発散会議」と「収束会議」を明確に分ける
ブレスト（発散）と要件定義（収束）を同じ会議でやってはダメです。その結果、発散フェーズで「でも開発工数は…」といった収束的なツッコミが入り、アイデアが十分に広がる前に萎んでしまう状況が起こります。
そこで、会議のゴールを明確に2つに分割するのがおすすめ。
- 「今日はひたすら発想・アイデア抽出だけを行い、判断や批判は一切しない」
- 「後日、別の会議で優先順位や実装の現実性を精査して収束する」
このように場を分けるだけで、各フェーズに集中しやすくなります。
短いスプリントで検証を回す：“試して→学んで→また発散”の反復
新しいアイデアは、実際にプロトタイプやMVPを早期に作り検証するのがベストです。例えば2週間スプリントを組み、前半1週間でアイデアを発散・開発、後半1週間でユーザーテストやインタビューを行いフィードバックを得る。
得られた学びをもとに、次のスプリントでは再度発散→収束を繰り返す。この反復サイクルを回すことで、アイデアのブラッシュアップが加速します。ちなみにユーザーインタビューの具体的な実施方法は、ユーザーインタビューの目的・設計・やり方・分析まで完全ガイドで解説していますので、参考にしてみてください。
事例で見る「発散→収束→検証」の流れ
ここでは架空のケースでここまで紹介した「発散→収束→検証」の流れを具体的なイメージに落とし込みます。
ダイバージェント思考：SCAMPER法でアイデアを徹底拡散
例えば、「既存のチャット機能」を題材に、SCAMPER法をフル活用してアイデアを出すケース。
- Substitute（代替）：「テキストではなくボイス・動画メッセージを使えないか？」
- Combine（組み合わせ）：「雑談チャンネルと評価の仕組みを連動させると面白いかも」
- Adapt（応用）：「ゲーム的要素を取り入れ、チャット参加率でポイント付与をするのはどうか」
…という具合にチーム全員で考え、合計30以上の新機能候補を洗い出す。要点はブレスト中は否定やコスト計算を一切しないこと。どんなに奇抜な案も歓迎します。
コンバージェント思考：OSTを用いて優先度を決定
いきなり「これはムリ」「工数がかかりそう」と判断せず、まずOpportunity Solution Tree（OST）を描く。
- Opportunity（機会）＝「ユーザーが組織内で孤立しがち、部署間連携不足」という点を幹に設定。
- その下に、前段階で出した30以上のアイデアを小枝のように配置。
- 各アイデアに対して「影響度（部署・役職を超えて使われるか）」「実装難易度」「将来的な事業戦略への合致度」などを議論し、最優先となる枝を選定。
この結果、リアルタイムな「ボイスチャット機能」は労力が大きいわりに需要が限定的ということで一旦優先度低め。代わりに「雑談スペース+匿名フィードバックを掛け合わせる仕組み」が最優先の枝に決まりました。
検証：MVPで早期リリース→ユーザーインタビュー
選定したアイデアをMVP（実用最小限の製品）として短期間で開発。アルファ版を社内と一部顧客にリリースし、ユーザーインタビューを実施。「匿名だと意外と発言しやすい」「思った以上に雑談投稿が増えた」など、ポジティブな反響と課題を取得。
さらにそこで出た新しい気づきを、再度発散フェーズでブレストし、必要なら機能拡張を検討。このように「発散→収束→検証→また発散」というサイクルを繰り返し、最終的にユーザー満足度の高い機能が完成しました。
架空のケースで流れを説明しましたが、イメージが湧きましたでしょうか？
組織に根付かせるコツ—“仕組み化”と“文化”の両輪
いくら発散と収束の手法を学んでも、1人のPdMだけが頑張っても組織全体の動きは変わりません。継続的に発散と収束を回せるようにするには、仕組みと文化の両面で整える必要があります。
会議設計とファシリテーションの型化
ブレスト会議や要件定義会議で使うアジェンダ、参加メンバー、時間配分、使用するツールやフレームワークを「テンプレート化」しておくと便利です。
- ブレスト会議（60分）
- 導入5分
- SCAMPER/6Hatsなど手法説明5分
- 個人でアイデア出し15分
- 共有20分
- まとめ15分
- 収束会議（45分）
- 前回のアイデアリストおさらい5分
- フレームワーク(AHPやOST)を活用した優先度付け25分
- 最終決定・今後の方針15分
このように型を決め、誰がファシリテーターになっても同じプロセスで進められる状態にしておくと、組織全体がバタつきにくくなります。
“褒める文化”と“否定しない文化”をセットで育てる
発散フェーズでは「あのアイデア、面白いね」「斬新だね」とポジティブに評価する雰囲気が重要です。一方、収束フェーズでは「優先度が低い」と判断したアイデアでも決して個人攻撃をせず、「今はベストなタイミングじゃないから後回し」と建設的に扱うことが肝要です。
そうすることで、組織の中に「アイデアをどんどん言っていい」「いつかまた活用されるかもしれない」という安心感が生まれます。PdMの“アイデアマネジメント”でも解説しましたが、アイデアの保管・再活用の仕組みがあれば、拒否された案でも将来の財産になる可能性があります。
参考情報
- De Bono, E. (1985). Six Thinking Hats. Little, Brown, & Company.
- Osborn, A. F. (1957). Applied Imagination. Scribner.
- Torres, T. (2021). Continuous Discovery Habits. Product Talk Publishing.
- Ulwick, A. (2016). Jobs to Be Done: Theory to Practice. IDEA BITE Press.
- Kano, N. (1984). Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control.
- 本サイト内記事：「ユーザーインタビューの目的・設計・やり方・分析まで完全ガイド」
- 本サイト内記事：「PdMの“アイデアマネジメント”」
今日から実践できるアクション
1. 発散会議を“フレームワーク前提”で一度やってみる
次回のアイデア創出会議ではSCAMPERまたは6 Thinking Hatsなど、一つのフレームワークに絞って実践する。人数が多いなら2〜3人のグループに分かれ、各グループで手法を試してみる。
2. 収束プロセスでは「短時間AHP」を導入する
全メンバーで本格的にAHPをやると時間がかかるが、まずは主要ステークホルダーと小規模でペアワイズ比較を行い、簡易スコアを作成してみる。その結果をチームに提示して議論を深める形でもOK。
3. 一度MVPを作り、ユーザーインタビューや定量データを交えた検証を回す
とくにHRテックやSaaS系サービスの場合、仕様書や議論だけで完結せず「動くもの」をユーザーに見せるのが近道。2週間程度の短いスプリントを組み、リリース→インタビュー→再考察という流れを体験する。
Q&A
Q1. SCAMPER法を実施すると、あり得ないくらい荒唐無稽なアイデアばかり出るのですが？
A. それで大丈夫です。ダイバージェント思考では「行き過ぎかな」と思うものも含め、多様な着想を歓迎するのが重要です。収束段階で実装可能性を検証すればいいので、発散時に制限をかけないのがポイントです。
Q2. OST（Opportunity Solution Tree）は綺麗な図で終わってしまい、実行に移りません
A. OSTだけ描いて満足してしまうパターンはよくあります。大切なのは、上位に来た解決策を「いつまでに、誰が、どのレベルで検証するのか」を明確に決めることです。小さな検証計画を枝葉に落とし込み、スプリント開始時のタスクとして設定すると動きやすくなります。
Q3. 発散と収束を繰り返すうちに、チームが疲弊してモチベーションが下がることはありませんか？
A. 一気に詰め込みすぎると疲弊しやすいです。そこで、発散会議を月1回、収束会議を週1回など、チームが無理なく継続できるリズムを作るとよいです。さらに「ここまで発散できたらOK」「ここまで収束したら次のフェーズに行く」といった完了条件を事前に共有しておけば、だらだら会議が長引くことを防げます。
コメント