決定ログ（Decision Log）とは？意思決定を記録・管理する方法

決定ログとは

決定ログ（Decision Log）とは、プロジェクトにおいて行われた意思決定を体系的に記録・追跡するための文書です。「何を決めたか」だけでなく、「なぜその選択肢を選んだか」「他にどのような案があったか」「誰が決定したか」を一元的に管理します。

プロジェクトでは日々多くの意思決定が行われますが、それらが記録されないまま進行すると深刻な問題が発生します。メンバーの入れ替わり時に「なぜこのアーキテクチャを選んだのか」が分からなくなる、同じ議論が何度も蒸し返される、後から「そんな決定は聞いていない」と言われるなどの事態です。

決定ログはこれらの問題を防ぐための組織的な記憶装置です。プロジェクトマネジメントの標準的なプラクティスとして、PMBOKやPRINCE2でも意思決定の文書化が推奨されています。アジャイル開発においても、ADR（Architecture Decision Record）として技術的な意思決定を記録する慣行が広まっています。

構成要素

決定ログに記録すべき項目は以下のとおりです。必要に応じて項目を追加・削減しますが、最低限「決定事項」「背景」「決定理由」の3つは含めるべきです。

項目	内容	記載例
決定ID	一意の識別番号	DEC-2026-042
日付	決定が行われた日	2026-02-20
決定事項	何が決まったか	認証基盤はOAuth2.0を採用する
背景	なぜ検討が必要になったか	セキュリティ要件の強化に伴い認証方式の見直しが必要になった
代替案	検討した他の選択肢	案A: SAML、案B: 独自認証、案C: OAuth2.0
決定理由	選んだ根拠	SaaS連携の拡張性、業界標準への準拠、開発コスト
決定者	承認した人物	プロジェクトオーナー山田太郎
影響範囲	決定がどこに及ぶか	全サービスの認証フロー、API設計
ステータス	決定の現在の状態	有効 / 撤回 / 保留

ステータス管理

決定は永続的とは限りません。プロジェクトの状況変化に応じて撤回や変更が必要になることもあります。そのため、各決定に「有効」「保留」「撤回」「差し替え」などのステータスを付与し、常に現在の有効な決定が一目でわかる状態を維持します。

撤回や差し替えの場合は、元の決定を削除するのではなく、ステータスを更新した上で新しい決定への参照を追記します。決定の履歴を残すことで、判断の変遷を追跡できます。

実践的な使い方

ステップ1: テンプレートと記録ルールを決める

プロジェクト開始時に決定ログのテンプレートとルールをチームで合意します。重要なのは以下の3点です。

どのレベルの決定を記録するか（閾値の設定）
誰がいつ記録するか（責任者の明確化）
どこに保管するか（ツールの選定）

全ての意思決定を記録するのは非現実的です。「影響範囲がチーム外に及ぶもの」「コストが一定額以上のもの」「技術的に後戻りが困難なもの」など、記録対象の基準を設定します。

ステップ2: 決定のタイミングで記録する

意思決定が行われた直後に記録します。後回しにすると、背景や代替案の詳細が忘れられてしまいます。会議中にリアルタイムで記録するか、遅くとも24時間以内に記録を完成させるルールが効果的です。

記録担当者は、決定に至った議論の要点を整理し、特に「なぜ他の選択肢を選ばなかったか」を明確に記載します。この「不採用の理由」こそが、後から振り返る際に最も価値のある情報です。

ステップ3: 定期的にレビューする

決定ログは書きっぱなしでは意味がありません。月次や四半期ごとにチームでレビューし、以下の観点で確認します。

前提条件が変化した決定はないか
ステータスの更新が必要な決定はないか
新メンバーに共有すべき重要な決定はどれか
関連する複数の決定に矛盾はないか

このレビューにより、決定ログが「生きた文書」として機能し続けます。

活用場面

プロジェクトの引き継ぎ: メンバー交代やチーム再編時に、過去の意思決定の経緯を新メンバーに伝達する際の基本資料となります
監査・コンプライアンス対応: 意思決定のプロセスと根拠が文書化されているため、内部監査や外部監査への対応が容易になります
同じ議論の蒸し返し防止: 「以前この件は検討済みで、理由Xにより案Aを採用した」と決定ログを参照すれば、不毛な再議論を回避できます
アーキテクチャの意思決定: ADR（Architecture Decision Record）として技術選定の理由を記録し、将来の技術的判断の参考にします
ステークホルダーへの説明: 経営層やクライアントに対して、意思決定の根拠を説明する際のエビデンスとして活用します

注意点

記録の粒度を適切に保つ

全ての細かい決定を記録するとオーバーヘッドが大きくなり、チームが記録を怠るようになります。逆に重要な決定だけに絞りすぎると、後から「あの判断はどこにも残っていない」という事態になります。プロジェクトの規模と特性に応じて、適切な粒度を試行錯誤しながら定めます。

形式にこだわりすぎない

テンプレートは出発点であり、プロジェクトの進行に合わせて柔軟に調整します。項目が多すぎて記入が面倒になるよりも、最低限の項目を確実に記録する方が実用的です。

ツールの選定

ExcelやSpreadsheetは手軽ですが、検索性やリンク管理に限界があります。Confluence、Notion、GitHubのADRリポジトリなど、チームが日常的に使うツールに統合するのが理想的です。決定ログのために別のツールを導入すると、参照されなくなるリスクがあります。

決定理由の記載が最も重要

「何を決めたか」は比較的記録されやすいですが、「なぜその選択をしたか」は省略されがちです。しかし、後から最も必要とされる情報は決定理由です。「コスト面で有利だった」「スケジュール制約から消去法で選んだ」「技術的リスクが最も低かった」など、判断の根拠を具体的に残します。

まとめ

決定ログは、プロジェクトにおける意思決定の背景・代替案・理由を体系的に記録し、組織の記憶として活用するための文書です。意思決定の透明性を確保し、メンバー交代時の引き継ぎ、同じ議論の蒸し返し防止、監査対応など多くの場面で価値を発揮します。「何を決めたか」だけでなく「なぜその選択をしたか」を残すことが、決定ログを真に有用なものにする鍵です。