フレームワーク活用ガイドひとことで言うと#
プロジェクトで下した意思決定の内容・背景・代替案・決定者を時系列で記録するドキュメント。「なぜその判断をしたのか」が残っていないと、後から同じ議論が繰り返されたり、背景を知らない人がひっくり返したりする。それを防ぐのが意思決定ログである。
押さえておきたい用語#
- ADR（Architecture Decision Record）
- ソフトウェアの設計判断を記録するフォーマット。意思決定ログのうち、技術的な判断に特化したもの。
- 決定コンテキスト（Decision Context）
- その判断が下された時点での前提条件・制約・情報。後から見たときに「なぜこの選択肢を選んだか」を理解するための背景情報。
- 代替案（Alternatives）
- 採用しなかった選択肢と、その棄却理由。後から「なぜBを選ばなかったのか」と問われたときの回答がここに残る。
- 決定ステータス（Decision Status）
- 決定の現在の状態。提案中・承認済み・廃止・差し替えなどで管理する。
プロジェクト意思決定ログの全体像#
こんな悩みに効く#
- 「これ誰がいつ決めたの？」という質問がプロジェクト中に何度も出る
- 同じ論点が会議のたびに蒸し返され、議論がループする
- 新メンバーが参画するたびに過去の決定を口頭で説明し直す手間がかかる
- 決定を覆すとき、元の判断理由がわからず「とりあえず全部やり直し」になる
基本の使い方#
すべての判断を記録するのは現実的でないため、ログに残す基準を設ける。
- 影響範囲が2チーム以上にまたがる決定
- 後から変更するコストが大きい決定（技術選定、スコープ変更など）
- ステークホルダーの承認が必要だった決定
- 日常的な実装判断は対象外。迷ったら「3か月後に理由を聞かれそうか」で判断する
決定が下されたら24時間以内に記録する。時間が経つと背景や代替案の記憶が薄れる。
- 決定ID: 連番（DEC-001, DEC-002…）で管理
- 決定内容: 何を決めたかを一文で
- 背景・コンテキスト: なぜこの判断が必要になったか
- 代替案と棄却理由: 他にどんな選択肢があり、なぜ選ばなかったか
- 決定者: 最終的に承認した人
- リスク: この決定に伴うリスク
- 再評価条件: どんな状況になったら見直すか
ログは「誰でもいつでも見られる場所」に置く。
- Confluence、Notion、GitHub Wikiなどチームが日常的に使うツールに集約する
- 議事録の中に埋もれさせない。決定ログは独立したページにする
- 決定IDで検索できるようにしておくと、Slackで「DEC-023参照」と書くだけで伝わる
四半期に一度、過去の決定ログを棚卸しする。
- 前提条件が変わった決定はないか？（例: 当時は小規模だったが、ユーザーが10倍に増えた）
- 「再評価条件」に該当する状況が発生していないか？
- ステータスを「承認済み→廃止」「承認済み→差し替え（DEC-045で更新）」に更新する
具体例#
12名のエンジニアチームが新サービスの開発を開始。認証基盤を自前で作るかAuth0を使うかで議論になり、最終的にAuth0を採用した。
意思決定ログの記録内容:
| 項目 | 内容 |
|---|---|
| ID | DEC-003 |
| 決定 | 認証基盤にAuth0を採用 |
| 背景 | 認証の自前実装は3人月かかる見積もり。セキュリティ要件がSOC2準拠で、自前だと監査コストも増大 |
| 代替案 | ①自前実装（工数大）②Firebase Auth（カスタマイズ性不足）③Cognito（AWS以外への移行が困難） |
| 決定者 | CTO |
| リスク | Auth0の料金がMAU 50,000超で月額$1,500超。ベンダーロックイン |
| 再評価条件 | MAUが100,000を超えた場合、コスト比較を再実施 |
半年後、セールスチームから「自前認証に切り替えればコスト削減になるのでは」と提案があった。PMがDEC-003を共有し、棄却理由（工数3人月・SOC2監査コスト）を示したところ、30分で議論が終結。ログがなければ再度見積もりから始まり、少なくとも1週間は消費していた。
受託開発プロジェクトで、クライアントから「検索機能に全文検索を追加したい」と要望が出た。追加コスト150万円と納期3週間延長を提示し、クライアントが承認。意思決定ログに記録した。
| 項目 | 内容 |
|---|---|
| ID | DEC-012 |
| 決定 | 全文検索機能を追加（スコープ変更） |
| 背景 | クライアントの社内ユーザーから「キーワード部分一致で検索したい」要望が多数 |
| 代替案 | ①前方一致のみ（ユーザー要望に不十分）②外部検索SaaS（月額コスト継続発生） |
| 決定者 | クライアント側PM＋自社PM |
| 承認証跡 | メール日付 2026-03-15、見積書No.E-2026-042 |
納品後、クライアントの経理部門から「なぜ当初見積もりより150万円高いのか」と問い合わせが来た。DEC-012と承認メールを即座に共有し、紛争ゼロで解決。過去に同様のケースで「言った言わない」問題が発生し60万円の値引きを余儀なくされた経験があったため、ログの価値を実感した。
20名のプロジェクトチームに、途中参画のエンジニアが3名加わった。従来は「過去の経緯」を口頭で伝えるのに2週間かかっていたが、意思決定ログが47件蓄積されていたためオンボーディングのアプローチを変えた。
新メンバーのオンボーディング手順:
- 意思決定ログの一覧を渡し、まず全タイトルに目を通す（30分）
- 自分の担当領域に関連する決定を精読する（2〜3時間）
- 疑問点をリストアップし、既存メンバーと30分のQ&Aセッション
結果、新メンバーが「戦力化」するまでの期間が2週間 → 1週間に短縮。特に「なぜこの技術を使っているのか」「なぜこの仕様になっているのか」という質問が激減し、既存メンバーの説明工数が月あたり約20時間削減された。
新メンバーの一人は「ログがなかったら、過去の決定を無意識にひっくり返していたと思う」とコメントした。
やりがちな失敗パターン#
- 決定内容だけ書いて背景を省略する — 「PostgreSQLを採用」だけでは半年後に「なぜ？」が発生する。背景と代替案の棄却理由こそがログの本体
- 記録のタイミングが遅い — 1週間後に書こうとすると、代替案の詳細や議論のニュアンスが消えている。24時間ルールを設けるのが効果的
- ログの場所がバラバラ — 議事録、Slack、個人メモに散在すると検索できない。一箇所に集約し、決定IDで参照可能にする
- 一度決めたら永遠に有効だと思い込む — 前提条件は変わる。再評価条件を書いておかないと、古い決定が足枷になり続ける
まとめ#
プロジェクト意思決定ログは、「何を決めたか」だけでなく**「なぜそう決めたか」「他に何を検討したか」**を記録する仕組みである。ログがあれば同じ議論の蒸し返しを防げるし、新メンバーへの引き継ぎも格段に早くなる。記録するコストは1件あたり10〜15分だが、手戻りや議論のループに費やされる時間を考えれば、この投資は何倍にもなって返ってくる。