「判断の構造」は、相談を受けてから施策を選ぶまでの過程を、読み比べるための入口です。 Webを作る、AIを導入する、広告を続けるといった結論だけでなく、なぜその選択になり、何が変われば見直すのかを見ます。
First byteが整理する読み方であり、同じ手順をたどれば同じ成果が出るという法則ではありません。匿名の説明があることと、実顧客の成果が検証されていることも別です。
30秒で要点
- 相談の言葉は、まだ解決策や原因を確定していません。
- 観察、仮説、採用理由、残った不明点を分けて読みます。
- 7つの観点で、結論だけでなく保留と見直しの条件まで確かめます。
- 匿名の実記録、複数状況を組み合わせた例、仮想例は区別します。本記事の具体例と図は仮想です。
- 守秘方針は情報の扱い方の説明です。それだけで支援者の能力や成果は証明されません。
どこから読むか — 自分の状況から選ぶ
この記事は判断の構造を扱います。具体的な局面と研究の読み方はそれぞれ別の記事にあります。
相談を受けた直後で、何から整えるか決めたい。 AIを入れたいと言われたときはまず整えること、リニューアルを頼まれたときはまず整理すること、担当者がいないときは何から相談すればいいか。
続ける・止めるを決めたい。 広告の判断は続ける・止める・変える、判断の前に揃えること、作り直しの軸はサイトを作り直す前に、揃えておく判断の軸、止める線の設計は止める線と責任の範囲を決める、決めないことの代償は「決めない」という選択のコスト。
判断の質が落ちる条件を知りたい。 積み重なる負荷は判断疲れが積み重なると、その反証は23万件の医療データが示した反証、対等性が崩れたときは発注者とベンダーの「対等性」、結果を見ない判断は経験を積んでも静かにずれていく。
AIとの壁打ちが機能していない。 気持ちよく終わる構造は迎合的なAIとの壁打ち、何に答えないかに出る迎合は20モデルの顕示選好実験、速くなった感覚の検算はAIは疲れを減らすが時計を進めない、戻れる設計かどうかは可逆性の問題。
研究や通説の確かめ方を知りたい。 追試で崩れた例は「締切を細かく切れば先延ばしは減る」は再現しなかった、単純化の危うさは「考える」場所は前頭前野の前方ではなかった、意思決定の実像は「決断を下す脳の部位」は存在するのか？、習慣の定着は2つの神経回路と定着診断。
記録と評価の設計をしたい。 過程の記録の価値は結果だけを記録した評価は、縮めると壊れる、言い切る精度の扱いは自信過剰と業績の関係、情報を集めても決まらない理由は「証拠の差」を探しているから。
まず、ケースが何を示す資料なのかを見る
「匿名ケース」という言葉だけでは、資料の由来も、確認できる範囲も分かりません。実際の記録を加工したものなら、その旨と変更した範囲が必要です。複数の状況を組み合わせた説明や仮想例なら、実際に同じ一連の出来事が起きたようには扱えません。
表が収まらない場合は、横にスクロールできます
| 資料の種類 | 読み取れること | 別に必要な確認 |
|---|---|---|
| 実記録を匿名化したケース | 記録が示す範囲の状況と判断 | 元の記録との対応、公開許可、省略した条件 |
| 複数の状況を組み合わせた例 | 共通する問題の説明 | どこが編集による組合せか |
| 説明用の仮想例 | 考え方、選択肢の比較方法 | 現場に同じ前提があるか |
| 成果を検証した報告 | 対象と設計の範囲での結果 | 比較条件、測定方法、誤差、他の状況への適用範囲 |
本記事では、下の仮想例を使って読む観点を示します。リンク先の記事も、公開されている説明を読むための入口として案内しており、リンクの存在を実績の証明には使いません。
判断過程を読む7つの観点
ここでの7項目はFirst byteによる整理です。全項目が揃えば必ず良い判断になるという採点表ではなく、説明の抜けを見つけるために使います。
表が収まらない場合は、横にスクロールできます
| 観点 | 読むときの問い | 具体的に残っていてほしいもの |
|---|---|---|
| 1. 相談の入口 | 最初に何を頼みたいと言っていたか | 依頼の言葉と、その背景 |
| 2. 即決しない理由 | なぜ、その依頼をすぐ実施しなかったか | 決める前に必要な情報、延期する負担 |
| 3. 論点の分解 | 一つに見える問題をどう分けたか | 対象、時期、工程、責任範囲 |
| 4. 仮説 | 原因や改善について何を想定したか | 支持する材料と、反対の説明 |
| 5. 選択 | 実施・縮小・保留・停止から何を選んだか | 選択理由と、採らなかった案 |
| 6. 残した資料 | 別の担当者が後から確認できるか | 定義、根拠、未解決点、担当者 |
| 7. 見直す条件 | 何が分かれば結論を変えるか | 次の確認、期限、停止条件 |
特に、観察と仮説の境目を見ます。GOV.UKの調査分析ガイドは、見聞きしたこと、そこからの解釈、次の行動を分けて整理しています。たとえば「フォームでエラーが起きた」は観察ですが、「顧客が当社を信用していない」はそれだけでは確定できない解釈です。
反対の材料も書いてあれば、もっともらしい説明だけで進めていないかを確かめられます。ただし、詳しく書かれた文章でも、元の観察が正しいか、重要な情報が省略されていないかは別の問題として残ります。
仮想例：Webを全面刷新する前に、分岐を残す
架空の事業者から「問い合わせが少ないので、サイトを全部作り直したい」という相談が来たとします。これは判断方法を説明するための例であり、First byteの実顧客の相談や結果ではありません。
入口の言葉は「全面刷新」でも、問い合わせが少ない理由はまだ分かりません。訪問者が減ったのか、必要な条件を満たす人が来ていないのか、送信に失敗しているのか、担当者が記録できていないのかを分けます。
仮に担当者が特定の端末で送信エラーを再現したなら、その条件での不具合は修正候補になります。ただし、それが問い合わせ減少のすべてを説明するとは限りません。記録を確認し、修正後にも同じ条件で送信を確かめます。1回成功しただけで、すべての利用環境が正常とは言いません。
一方で、事業や顧客層が変わり、現行の情報構成が合わなくなっているなら、部分修正だけでは足りないかもしれません。全面刷新、対象範囲を絞った再構成、現状維持の負担を比較します。「大きく作らない」という結論を先に決めるのでもありません。
この例を7観点で読むと、相談の入口は全面刷新、即決しない理由は原因と測定の不明確さ、分解は流入・閲覧・送信・受付です。仮説ごとに確認し、選択理由を記録し、修正後にも問題が残る場合や事業条件が変わる場合に見直します。結果を後から都合よく説明するのではなく、判断時点で分かっていたことを残す形です。
今の迷いに近い読み物を選ぶ
相談の入口を整理したい場合は、次の2本が出発点になります。
- Webを刷新したいとき、最初に何を整理するか：依頼の言葉と、着手前に必要な判断を分ける。
- AIを導入したいとき、最初に何を整理するか：導入目的、対象業務、導入前に決める境界を読む。
すでに選択肢があり、何で比較するかに迷っている場合は、Web刷新の判断軸や広告を続ける・止める・変える基準へ進めます。
実施後の責任や運用が問題なら、社内担当者がいない場合のWeb相談とAIの停止条件と責任範囲が対象です。ここでも、自分の条件と違う部分を探しながら読み、書かれた選択をそのまま自社の結論にしないようにします。
守秘方針と、支援内容の確認を分ける
First byteは守秘と信頼の方針で、顧客名や成果を原則公開せず、考え方や判断過程を公開する方針を示しています。制作実績を探す従来の入口である/casesと/projectsも、現在のサイト設定ではこの方針への案内にしています。
ただし、非公開を理由に、依頼前に必要な説明まで不要になるわけではありません。相談時には、何を提供するか、どの根拠を確認できるか、誰が実装・確認・停止を担当するか、追加費用が生じる条件などを確かめます。公開実績がないことを、能力が高い証拠にも低い証拠にも短絡させず、確認できる材料で判断します。
匿名化についても、名前を削れば何でも共有できるとは考えません。AAPORの調査実務指針は、属性と回答の組合せなどから個人が特定される可能性に触れています。これは調査資料に関する指針であり、特定案件の法的判断を代替しません。業種、時期、規模、珍しい出来事などをどこまで出せるかは、公開目的と合意を確認して扱います。
最小の検証：結論が変わる情報を1つ選ぶ
いま迷っている判断について、まず「決めたいこと」「確認済みの事実」「まだ仮説のこと」「誰がいつまでに確認するか」を書いてみます。そのうえで、確認結果によって選択が変わる項目を1つ選びます。
たとえば送信不具合が疑わしいなら、対象の操作と記録を照合します。AIの導入範囲なら、利用許可のある例だけを使い、誰が誤りを見つけられるかを確かめます。こうした確認は、運用や問題の存在を調べるもので、売上への効果を証明するものではありません。
観察から仮説を作り、必要なら保留し、理由を残す全体の考え方はFirst byte Methodへ。前提がまだ揃わない場合は前提設計、評価する考え方を確認したい場合は判断の質へ進めます。相談として言葉にする必要があれば、相談内容の整理から始められます。