IBISで対話を整理する：ダイアログマッピングの進め方

営業時間外のサポートについて1時間話しても、同じ問いに答えていないことがあります。ある人は返信の速さを求め、別の人は担当者の負担を心配し、もう一人は「緊急」の定義を明確にしたいと考えています。どれも重要ですが、発言順の議事録では、一つの議論が堂々巡りをしているように見えてしまいます。

ダイアログマッピングは、会話の構造を見えるようにする方法です。問い、答えの候補、その答えを支持する理由や反対する理由をつなぎます。前の発言をすべて覚えておく代わりに、どの論点を明らかにしたいのかを指し示せます。

ダイアログマッピングで会議に何が加わるか

Jeff ConklinのDialogue Mappingでは、進行役が会話を聞きながら更新する図を、参加者全員で見ます。記法の基礎はIBIS（Issue-Based Information System）です。問いで論点を示し、アイデアで答えの候補を示し、論拠でそのアイデアを支持したり、異論を示したりします。

進行役は発言を聞き、短いラベルを提案し、それが話した人の意図を表しているか確認します。参加者が図の順番どおりに話す必要はありません。前の選択肢を検討している途中で、新しい問いが出ても構いません。

ダイアログマップは、選択肢を検討している最中の理由を記録します。一方、意思決定ログ（英語）は、重要な選択が行われた後、または意図的に保留された後に、その内容と理由を残すものです。二つをつなげることはできますが、マップ上である選択肢に印を付けただけでは、承認にはなりません。

答えを集める前に、問いを定める

架空のソフトウェアサポートチームを例に、「担当者が勤務していない時間の、顧客からの緊急依頼をどう扱うか？」から始めます。これなら、一つの方法を正解と決めずに、期待されるサービス、振り分け、担当体制を検討できます。

「なぜオンコールの当番制を導入しないのか？」では、問いが狭くなります。提案済みの答えを支持するか拒否するか、という議論になるためです。当番制が候補の一つなら、広い問いの下にアイデアのノードとして置きます。

参加者は、何を決められるのかも知る必要があります。この例は、サポート責任者に示す選択肢を検討する会議です。顧客との既存の約束は制約として残り、ワークショップで勝手に変更できません。対応範囲を減らす案を候補に入れる前に、関係する合意内容を確認します。

問いに影響する定義は、見えるところに残します。「緊急」はサービス停止、業務の行き詰まり、あるいは単に強い言葉で書かれたメッセージを指すかもしれません。「次の勤務時間帯を待たずに対応すべきケースはどれか？」という別の問いを追加します。その答えによって、検討する選択肢が変わる可能性があります。

IBISの要素を一貫して使う

CogNexusのIBIS Field Guideは、問い、その答えとなるアイデア、アイデアを支持する理由と反対する理由を区別しています。新しい問いは、問い、アイデア、論拠のどこからでも生まれます。矢印は応答先のノードへ向け、アイデアから問いへ、支持・反対の理由からアイデアへ、新しい問いからその問いが生まれるきっかけとなったノードへ引きます。凝った見た目よりも、この関係を正しく示すことが重要です。

疑問符、アイデアのラベル、明確なプラス・マイナス記号を使い、色がなくても役割を読めるようにします。一つのノードには一つの考えを書きます。「当番制は費用が高く、皆が嫌がる」は二つの懸念を含み、必要な根拠や対応も異なるかもしれません。

支持する理由が、そのまま事実になるわけではありません。「外部サービスの方が安い」は、有効な比較ができるまでは参加者の主張です。その案とのつながりを残し、費用についての問いや、手元の根拠への参照を加えます。進行役が言い換えたことで、お墨付きが付いたようにしないことが大切です。

三つの対応案を検討する

チームは、社内の当番制、外部の一次切り分けサービス、明確な受付経路を設けて既存の約束で許される範囲は勤務時間内に返答する方法、という三つを提案します。いずれもこの例の選択肢であり、すべてのサポート業務への推奨ではありません。

案1：社内で対応者を持ち回りにする

製品の専門担当者は、社内の対応者なら難しいケースを理解できると述べます。その理由を当番制のアイデアの横に置きます。別の参加者は勤務時間外の仕事が増えることを指摘します。「人員」という曖昧な枝に隠さず、反対する理由として記録します。

負担の懸念から、「チームはどの程度の対応体制なら無理なく維持できるか？」という問いが生まれます。これは「顧客はもっと速い支援を必要としているか？」とは別の議論です。両方を残すことで、一方がもう一方の答えであるかのような混同を防げます。

案2：外部サービスで一次切り分けを行う

ある参加者は、外部サービスで緊急ケースと通常の質問を区別する案を出します。すべての受信メッセージを社内の専門家に割り当てなくても、初動を担える可能性があります。一方で、製品に詳しくない対応者が特殊な問題を誤った先へ振り分ける懸念があります。

「提供元は、当社でエスカレーションすべきケースをどの程度確実に識別できるか？」と問いにします。後で提供元と例題を使って確かめることはできますが、マップ上で、すでに能力が実証されたように扱ってはいけません。

案3：受付方法と返答する時間を明確にする

この案は、即時の返答が不要なケースについて、期待をそろえる助けになります。しかし、対象となる緊急ケースをもっと早く解決すると約束しているなら、その約束は満たせません。この異論を案に付け、実際のサービス上の義務を確認する問いへつなげます。

最終的に、外部で受け付け、限定した条件で社内へエスカレーションするなど、案を組み合わせるかもしれません。有力な提案になったら、新しいアイデアとして追加します。以前の案を黙って上書きしないようにします。それぞれの論拠が、組み合わせた案が生まれた理由を説明するためです。

どちらかに肩入れせず、食い違いを記録する

「それは絶対にうまくいかない」と言われたら、何が、どの条件で失敗するのかを尋ねます。「対応者がケースの分類に必要な情報へアクセスできない」というラベルにできるかもしれません。追加する前に読み返すと、問題はアクセス自体ではなく、アクセスできる時点だと訂正されることもあります。

主張が対立する場合は、その違いを明確に残します。本当に緊急の依頼はほとんどないと思う人と、大変だった週末を何度か覚えている人がいるとします。自信のある方の記憶を選ぶのではなく、「最近の依頼履歴は何を示しているか？」を追加します。

プラスとマイナスの数を得点として扱ってはいけません。弱い理由が四つあっても、守らなければならない制約一つを上回るわけではありません。マップは理由を検討するためのもので、理由を同じ重みの票に変えるものではありません。

すべての文を記録することも避けます。繰り返しなら既存のノードを示せますが、条件が実質的に違うなら別のメモにします。進行役の役割は、チームの考え方が読み取れる状態を保つことであり、接続線で飾った逐語録を作ることではありません。

Boardmixで共有できるIBISマップを作る

Boardmixを開き、空白のキャンバスの左側に主な問いを置きます。その右に三つのアイデアの枠を作り、それぞれの対応案を入れます。周囲には、支持する理由と反対する理由を置く十分な余白を取ります。

1. 起点には疑問符と、検討する問いを正確に書きます。話し合いの間、その文言が見えるようにします。
2. 各アイデアをその問いにつなぎます。「社内当番制」「外部で一次切り分け」のような、短く中立的なラベルを使います。
3. 各アイデアの横に、＋と−を付けた理由を別々のメモで置きます。近くにあるだけではなく、どの案に関する理由か分かるように線で結びます。
4. 社内当番制を支持する理由の横に、「すぐ専門知識が必要なケースは？」という問いを置きます。どの主張から生まれたのかを接続線で示します。
5. 根拠資料や短い参照ラベルを、関係する主張の近くに置きます。不明な点は、推測した値で埋めず、問いとして残します。

会話の最中は、一人がマップを更新し、参加者は口頭で表現を直す方法が使えます。同時編集で理由をたどりにくくしないよう、事前に進め方を決めます。図形と接続線は手作業で維持するマップであり、作図だけでIBISの規則を強制したり、論拠を自動評価したりするわけではありません。

次の問いに根拠が必要なら、いったん作図を止める

この例では、実際に勤務時間外の専門対応が必要なのはどの依頼か、既存の約束は何を求めているかを知らなければ、案を比較できないと分かるかもしれません。話し合いを続けても、その事実は生まれません。二つの問いを残し、なぜ調べる必要があるのかをマップで説明します。

根拠がそろったら、関係する主張に結び付けて案を再検討できます。その後、サポート責任者が体制を選んだら、決定を記録し、理由を示すマップへリンクします。後から読む人が、なぜその案を選び、どの未解決の懸念を承知で受け入れたか、両方を分かるようにしておきます。