| name | decision-deck-architecture |
| description | 経営会議・役員会・経営合宿など「経営に何かを決めてもらう」資料の論理構造を設計する方法論。背骨の問い 1 本 + 決定項目リスト N 個を初日に凍結し、各決定を (選択肢 / 推奨 / やる理由 / 先行指標 / 撤退ライン / 退室時の状態) のセットで設計する。 意思決定資料・ボード資料・合宿資料・投資判断資料・戦略提案を「構成する/章立てする/作り直す」とき、特に「経営に決めてほしいことがある」「論点が複数ある」資料では、本文を書き始める前に必ずこの skill を使う。資料が発散する・何を決める会議か曖昧・決定がフォローされない、を防ぐ。 実際の HTML 化は exec-deck skill、一次情報の確定度管理は source-fact-intake、当日の進行は meeting-run-design に渡す。単なる情報共有資料・報告書には使わない (決定がないなら不要)。 |
decision-deck-architecture — 意思決定資料の構造設計
経営資料が崩れる最大の原因は「何を決める場か」が曖昧なまま、情報を足し続けて発散すること。この skill は書き始める前に論理構造を凍結し、各決定を意思決定者が判断できる形に設計する。HTML の作り方 (exec-deck)、ファクトの確定度 (source-fact-intake)、当日の運営 (meeting-run-design) とは分離する — ここは「中身の論理」だけを扱う。
鉄則: ゴール構造を初日に凍結する
意思決定資料は次の 2 つを最初に固定し、以降ずらさない。
- 背骨の問い (1 本) — この場で経営に答えてほしい、横断する 1 つの問い。例:「縮小する事業を統合する前提で、来期どこに投資を寄せるか」。複数あるなら、それは別の会議。1 本に絞れないうちは資料を書かない。
- 決定項目リスト (N 個) — 背骨の問いに答えるために決めるべき個別の判断。これがセクションの数 N を決める。
出力構造に Step を後から append しない。 章は決定項目 N で凍結する。「あ、これも入れたい」で Step を足すと、9 Step・20 回編集の発散になる (実証あり)。新しい論点が出たら「既存 N のどれに属すか / 背骨を変えるか」を判断する — 安易に N+1 にしない。
番号は最後に振る (late binding)。 設計中はセクションを ID (意味のある名前) で扱い、順序が固まってから 01/02… を振る。早く番号を振ると、入れ替え・削除のたびに番号がずれて編集コストが上がる。
背骨が未確定なら、意思決定者への 30 分ヒアリングを初日のブロッカーにする。 オーナーが何を決めたいか分からないまま作った資料は、ほぼ作り直しになる。
背骨を変えるときは入口と出口を同時に直す。 オープニング (この場で決めること) とラップアップ (決まったこと) は背骨の写像。背骨が変わったら両方を差し替える — 片方だけ直すと資料が自己矛盾する。
各決定項目の設計 — 「決められる形」にする
決定項目 1 つにつき、意思決定者がその場で判断できるよう次をそろえる。HTML では exec-deck の .discussion ブロックに収める。
- 論点 (何を決めるのか) — 一文で。「投資総額 X 億を承認するか」のように Yes/No か選択で答えられる粒度に。
- 選択肢 — 2-4 個。各選択肢のトレードオフを表で並べる。「やる/やらない」だけでなく中間案も。
- 推奨 — どれを推すか + 理由。推奨を隠さない。経営は「叩き台」を求めている。
- やる理由 (Why now) — なぜ今この判断が必要か。先送りのコストは何か。
- 先行指標 — 決めた後、それが効いているかを早期に測る指標。「半年後の売上」でなく「来月の○○件数」。
- 撤退ライン — どうなったらやめるか/見直すか。これが無い決定は「やりっぱなし」になる。数値で。
- 退室時の状態 (空欄) — 合意 / 保留+宿題 / 却下 のいずれか + 宿題の owner・期限。会議中に埋める欄を資料に同梱する (meeting-run-design と接続)。
資料全体の流れ — 情報共有 → 意思決定 → アクション
1 つの資料 (または長いセクション) は、性質の違う 3 つの塊に分け、exec-deck の .part-divider で区切る。
- 情報共有 (背景) — 決定の前提。現在地・市場・制約。ここを各決定の直前に front-load し、当日の議論は決定に集中させる (背景を当日読ませない)。
- 意思決定 — 決定項目 N 個。各
.discussion で上記 7 点。
- アクション — 決まったことの実行受け皿。決定サマリー表 + 宿題表 (owner/期限) + 次のゲート (1/3/6 ヶ月)。
各セクション冒頭に .answers で「この節は背骨のどの問いに答えるか」を一文で置くと、N 個の決定が 1 本の背骨にぶら下がっていることが可視化される。
設計の進め方 (チェックリスト)
- 背骨の問いを 1 文で書けるか? 書けないならヒアリング (source-fact-intake / meeting-run-design へ)。
- 決定項目を N 個リストアップ。各々が独立に Yes/No か選択で答えられるか?
- セクション = 決定項目 N + 情報共有ブロック + アクションブロック。ID で仮置き (番号は後)。
- 各決定に 7 点セット (論点/選択肢/推奨/Why now/先行指標/撤退ライン/退室時状態) がそろうか? 埋まらない点は「出典待ち」で可視化 (source-fact-intake)。
- オープニングとラップアップが背骨の写像になっているか?
- exec-deck に渡して HTML 化。当日の進行は meeting-run-design。
アンチパターン
- 背骨を決めずに情報から書き始める (発散して作り直し)
- 決定項目に推奨・やる理由・先行指標・撤退ラインが欠ける (やりっぱなしになる)
- Step を後から足して章が増殖する / 早すぎる番号付け (入れ替えで全部ずれる)
