フレームワーク活用ガイドひとことで言うと#
会議での議論を**「問い」「アイデア」「賛成」「反対」**の4要素でリアルタイムにマップ化し、全員が見える形で構造化する手法。議論の迷走や堂々巡りを防ぎ、対立を建設的な合意に導くファシリテーション技法である。ジェフ・コンクリンのIBIS（Issue-Based Information System）記法がベース。
押さえておきたい用語#
- IBIS記法（Issue-Based Information System）
- 議論を**問い（Question）・アイデア（Idea）・賛成論（Pro）・反対論（Con）**の4ノードで構造化する記法。ダイアログマッピングの文法にあたる。
- 問いノード（Question Node）
- 「どうすれば○○できるか？」など、議論の出発点となる問い。すべての議論はここから始まる。
- アイデアノード（Idea Node）
- 問いに対する提案・選択肢・回答。1つの問いに対して複数のアイデアがぶら下がる。
- 共有ディスプレイ（Shared Display）
- 会議参加者全員が同時に見られるマップの表示面。ホワイトボード、プロジェクター、オンラインツールなどで共有する。
ダイアログマッピングの全体像#
こんな悩みに効く#
- 会議が毎回堂々巡りで、同じ議論を何度も繰り返す
- 声の大きい人の意見が通りがちで、建設的な議論にならない
- 複雑な意思決定で、何がどこまで合意されたか全員の認識がズレる
- 反対意見が出ると議論が感情的になり、対立が深まる
基本の使い方#
会議の目的を1つの問いとして言語化し、全員が見える場所に書く。
- 「どうすれば○○を達成できるか？」「○○の方針をどうするか？」の形
- 問いが曖昧だと議論も拡散する。具体的で答えが出せる問いにする
- ホワイトボード、Miro、Mural、Notionなど何でもよい。全員が同時に見られることが条件
参加者の発言を聞きながら、IBIS記法の4要素に分類してマップに追加していく。
- 発言が「提案」ならアイデアノード
- 「それいいね、なぜなら〜」なら賛成ノード
- 「でも〜が心配」なら反対ノード
- 「そもそも○○はどうする？」なら新しい問いノード
- 発言者に「これは提案ですか？懸念ですか？」と確認すると分類精度が上がる
反対ノードをそのまま放置せず、新しい問いに変換して解決策を探る。
- 「リソースが足りない」→「どうすればリソースを確保できるか？」
- 「コストが高い」→「コストを下げる方法はあるか？」
- この変換が対立を建設的な探求に転換するダイアログマッピングの核心
マップ全体を俯瞰し、賛成が多く反対が解消されたアイデアを合意ポイントとして特定する。
- 完全に反対がなくなるのを待つ必要はない。残るリスクを明示した上で決定する
- マップそのものが議事録になるので、決定事項とその根拠が後から追跡できる
- 保留になった問いは次回の会議のアジェンダに回す
具体例#
12名のプロダクトチーム。次の四半期のロードマップを決める会議で、エンジニア・デザイナー・営業の意見が対立し、前回は3時間かけて結論が出なかった。
ダイアログマッピングを導入:
中心の問い:「Q3に最も注力すべき機能はどれか？」
マップに出たアイデア:
- アイデアA: 検索機能の改善（営業推し）
- 賛成: 顧客要望の1位（42%）
- 反対: 技術的負債の解消が先（エンジニア）
- アイデアB: パフォーマンス改善（エンジニア推し）
- 賛成: ページ読み込みが3.2秒で離脱率に影響
- 反対: 顧客からの直接要望が少ない
- アイデアC: UI刷新（デザイナー推し）
- 賛成: NPS改善につながる
- 反対: 工数が大きく他を圧迫
反対意見を問いに変換:
- 「技術的負債の解消と検索改善を同時に進められないか？」→ 検索改善のリファクタリングで負債の一部を解消するハイブリッド案が浮上
- 「UI刷新を段階的にできないか？」→ 検索画面だけ先行リニューアルする案に
結果: 「検索機能の改善＋リファクタリング」を主軸に、検索画面のUI刷新を同時実施する方針で合意。所要時間は75分（前回の半分以下）。マップがそのまま議事録になり、欠席メンバーにも意思決定の経緯が伝わった。
M&Aで統合された2つの営業部門（旧A社チーム15名、旧B社チーム12名）。顧客管理システムをどちらに統一するかで3か月間もめていた。
ファシリテーターがダイアログマッピングを導入。
中心の問い: 「統合後の顧客管理をどのシステムで行うか？」
マップの展開:
- アイデア1: 旧A社のSalesforceに統一
- 賛成: 機能が豊富、大企業での実績
- 反対: 旧B社の顧客データ移行に3か月かかる
- アイデア2: 旧B社のHubSpotに統一
- 賛成: 操作が簡単、コストが**40%**安い
- 反対: 旧A社のカスタマイズが再現できない
- アイデア3: 新しいシステムを導入
- 賛成: 両チームが対等にスタートできる
- 反対: 導入コストと移行期間が2倍
反対を問いに変換:
- 「データ移行を3か月より短くできるか？」→ 専門ベンダーに依頼すれば6週間で可能と判明
- 「HubSpotでA社のカスタマイズを再現できるか？」→ 必須カスタマイズ5件中3件は対応可能と確認
結果: マップを全員で見ながら議論した結果、「Salesforceに統一＋データ移行はベンダー委託」で合意。感情的な「うちのシステムのほうがいい」という対立が、マップ上では賛成・反対の根拠として可視化されたことで、建設的に収束した。
フルリモートの開発チーム8名。週次ミーティングが毎回60分を超え、「何が決まったのかわからない」「同じ話が繰り返される」と不満が出ていた。
ダイアログマッピング導入方法: Miroボード上にIBISテンプレートを用意し、ファシリテーター（PM）がリアルタイムで発言をノードに変換。
初回の改善:
- 中心の問い:「今週のリリースをブロックしている問題は何か？」
- 従来はメンバーが順番に報告して40分消費していたが、ブロッカーに焦点を絞ったことで報告が15分に短縮
- 「APIの仕様変更への対応」にアイデアが3つ出て、賛成・反対を整理した結果、10分で方針決定
3か月後の変化:
- 会議時間が60分 → 35分に短縮
- 決定事項の明確度（メンバーアンケート）が2.8 → 4.3（5点満点）に改善
- Miroのマップが議事録代わりになり、議事録作成の工数がゼロに
- 欠席者もマップを見れば議論の経緯と結論がわかるため、キャッチアップ時間が半減
やりがちな失敗パターン#
- ファシリテーターが内容に介入する — マッピング担当者は「構造化する人」であり、「意見を言う人」ではない。両方やると分類が歪む。自分の意見は一旦脇に置く
- すべての発言をノードにしようとする — 雑談や脱線もマップに入れると収拾がつかなくなる。「それは今の問いに対する提案ですか？」と軌道修正する勇気が必要
- 反対意見を問いに変換しない — 反対ノードをそのまま放置すると「否定された」と感じた人が黙ってしまう。反対を問いに変換する一手間が、対立を建設に変える
- 共有ディスプレイなしでやる — マップを自分のノートだけに書いていると、参加者は「何が書かれているのかわからない」。全員が同時に見える環境が大前提
まとめ#
ダイアログマッピングは、議論を「問い・アイデア・賛成・反対」の4要素でリアルタイムに可視化し、堂々巡りや感情的対立を構造化された合意形成に変えるファシリテーション技法である。最大のポイントは反対意見を「問い」に変換すること。これにより対立が「解くべき課題」に変わり、全員が同じ方向を向ける。次に結論が出にくい会議があったら、ホワイトボードに「？」と書き、中心の問いを立てるところから始めてみてほしい。