ホワイトボードの凡例：事実・仮説・決定・アクションを分ける

ホワイトボードの凡例は、共有ボード上のメモをどう読むかを示す小さな説明欄です。ワークショップでは、どの部署が書いたかよりも、そのメモが「事実」「仮説」「決定」「アクション」のどれに当たるかを区別することが役立ちます。

四つが同じ見た目で並んでいると、「これが役立つと思う」が、いつの間にか「これを作ると決めた」に変わってしまいます。Boardmixの共有ホワイトボードなら、それぞれの意味を分けたまま、同じ場所に置いて話し合えます。

説明のない四色ではなく、四つのラベルから始める

凡例はワークショップの問いの横に置きます。ラベルは凡例だけでなく、各メモにも記入しましょう。色は見つけやすくする補助にはなりますが、配色を覚えていないと意味がわからない状態は避けます。

「事実」は、いつでもどこでも変わらない真理という意味ではありません。「参加者三人がメールを開いた」は記録された観察になり得ますが、「人はメールを好む」は、そこから広げた解釈です。発言の引用も、その人がそう話したことを示すだけで、発言内容の正しさまで保証するものではありません。

ラベルはメモの役割を示すもので、進捗を表すものではありません。アクションが終わったら、「完了」などの状態を別に追記します。「事実」に分類し直したり、同じ色を別の場所では承認の意味に使ったりしないようにしましょう。

複数の意味が混ざったメモを分ける

次のようなメモがワークショップに出てきたとします。

参加者がイベントの開始時刻を見つけられないので、申込完了画面を作り直し、マラに木曜日に公開してもらう。

この一文には、観察、考えられる原因、改善案、そして本人がまだ引き受けていないかもしれない作業が混ざっています。計画に入れる前に、四つの問いに分けて確認します。

• 実際に何を観察し、その記録はどこにあるのか。
• 観察に対して、どのような説明を付け加えているのか。
• 決定権を持つ人が対応を選んだのか、それともまだ提案なのか。
• 名前の挙がった人は、具体的な成果物と期限を引き受けたのか。

まだ選ばれていない案は、議論用の領域に「提案」と書いて残します。未回答の質問も同じ場所に置けます。内容がわかる前から、すべての発言を四分類のどれかに押し込める必要はありません。

具体例：イベントの申込完了画面を見直す

イベント運営チームが申込フローを検討する場面を考えます。この説明用の例では、現在のフローを五人に試してもらった記録があります。チームの問いは、「次のユーザビリティ確認までに、申込完了画面の何を変えるか」です。

事実 F1：観察した範囲で記録する

五人中三人が、イベントの開始時刻を探すために確認メールを開き直した。 実施日と該当する記録への参照を添えます。これは、利用者全体の五人に三人が同じ行動を取る、あるいはメールが問題を起こした、という意味ではありません。単にメールで確認するほうが便利だった可能性もあります。

仮説 H1：解釈であることを見えるようにする

申込完了画面で開始時刻を目立たせれば、メールを開かずに見つけられるかもしれない。 F1を参照しつつ、H1は別のメモとして残します。修正したプロトタイプで時刻を探してもらえば、この説明を検討できます。目立つ位置にあっても見落とす可能性はあるため、仮説は引き続き検証の対象です。

決定 D1：検証と公開を分ける

次の確認用に、開始時刻を目立たせたプロトタイプを作る。公開中の申込フローはまだ変更しない。 イベント責任者が自分の名前と決定日を記録します。これはH1を調べるための選択であり、H1が正しいという証明ではありません。「全員が気に入った」だけでは、同じ範囲や決定権限は伝わりません。

アクション A1：受け渡す仕事を具体化する

マラが木曜日までに、確認に使う現行版と修正版の申込完了画面を用意する。 マラが作業を引き受け、画面をどこに置くかをチームで決めます。これはデザイン作業であり、公開を約束するものではありません。D1への参照を付けると、別のメンバーにも作業の理由が伝わります。

四つのメモは別々に残します。F1を手がかりにH1を考え、D1で限定的な対応を認め、A1でその対応を実行します。つながりが表すのはチームの考え方であって、仮説が自動的に事実へ変わったことではありません。

Boardmixで凡例と具体例を作る

空白のボードを開き、ワークショップの問いをテキストで追加します。Boardmixのユーザーガイド（英語）には、テキスト、付箋、基本図形、接続線の説明があります。このレイアウトは、そうした基本的な道具で作れます。

1. 小さな凡例を作る。 「事実」「仮説」「決定」「アクション」と書いた見本のメモを四つ置きます。ラベルの下には、先ほどの表にある必要項目を記入します。凡例は遠くの隅ではなく、問いの近くに残します。
2. 具体例の四つのメモを追加する。 F1、H1、D1、A1を短い参照番号として使い、その前に分類名を記入します。これは自分で入力するラベルであり、Boardmix固有のレコード種別ではありません。
3. 根拠を内容の近くに置く。 F1の横に出典への参照を置きます。H1には「F1を基にした仮説」、D1には「H1を検証」、A1には「D1に対応」と書きます。接続線を添えると、関係をたどりやすくなります。
4. 未整理の内容を置く場所を残す。 分割後のメモが元の意図を保っていると書き手が確認するまでは、最初の混ざったメモを近くに残します。提案段階の作業を、合意済みアクションの領域に入れないようにします。
5. 表現を一緒に確認する。 何がわかっていて、何が不確かで、マラが何を用意するのかを、同僚に説明してもらいます。曖昧なメモにはコメントで質問し、表現が合意できたらメモ本文を更新します。

参加者を招待する前に、内容に合ったボードのアクセス権を選びます。参加者の個人情報は組織が認めた保管先に置き、ボードには出典への参照を記入してください。この例のラベル、担当、関係は手作業で管理します。担当者や期限を書くだけで、自動通知や承認処理が作られるわけではありません。

根拠や決定が変わっても、区別を保つ

次の確認で新しい観察が得られたら、その出典と日付を付けて追加します。そのうえで、仮説の説明や確信の度合いを更新します。最初の観察を、期待していた結論で上書きしないことが大切です。

決定が変わったら、以前の決定を「置き換え済み」とし、新しい記録を示します。木曜日の作業が終わったら、成果物を記録してアクションを完了にします。これらは異なる更新です。プロトタイプの完成は、仮説の裏付けにも公開の許可にもなりません。

仮説が増えて「どれから調べるか」が次の課題になったら、前提条件マッピングで重要性と根拠を比較する方法が役立ちます。凡例が解決するのは、もっと手前の問題です。同じ一文を、参加者全員が同じ意味で読めるようにします。

Boardmixを開き、次のワークショップで一つの曖昧なメモに四つのラベルを使ってみましょう。目指すのは、きれいに色分けされたボードではありません。同僚が、観察、考えられる説明、権限に基づく選択、誰かが引き受けた作業を区別できることです。