「なぜこの仕様にしたのか、後から聞かれても説明できなかった」
受託開発のPMがトラブル時によく直面する状況です。当時の判断には根拠があった。でもそれを記録していなかったため、後から「なぜそうなっているの？」と聞かれたとき答えられない。
議事録には「決定：○○で進める」とは書いてある。でも「なぜその選択をしたのか」「他にどんな選択肢があったのか」「誰が承認したのか」は残っていない。後から揉める案件の多くは、この「判断背景の欠落」から始まります。
議事録だけでは判断背景が残らない理由
議事録は「会議で何が決まったか」を記録するものです。当日の決定事項を残すことが目的なので、決定に至るまでの検討プロセスや背景は省かれることが多い。
これは議事録の使い方として間違っていませんが、後から「この判断はなぜ行われたのか」を説明するには不十分です。
特に以下の場面で困ります：
- 顧客から「この仕様はなぜこうなっているのか」と問われる
- プロジェクト途中からジョインしたメンバーが過去の判断を追えない
- 炎上後の原因分析でなぜその判断になったかを整理できない
- 次の案件で同じ判断ポイントを活かせない
判断ログに残す5項目
議事録とは別に「判断ログ」として記録しておくべき内容は5つです。
項目1：判断の内容（何を決めたか）
「○○機能の実装方式をAパターンとする」という形で、決定内容を1行で記録します。
項目2：背景（なぜその判断が必要だったか）
「○月○日に顧客から変更要求が来たため」「テスト結果でパフォーマンスに問題が出たため」という形で、判断が必要になった経緯を記録します。
項目3：検討した選択肢（どんな選択肢があったか）
「A案（今回採用）・B案・C案を検討した」という形で、他にどんな選択肢があったかを残します。選択肢が1つしかない判断もありますが、その場合も「他の選択肢を検討したか」は書いておく価値があります。
項目4：選んだ理由とリスク（なぜその選択肢を選んだか）
「A案を選んだ理由は○○。ただし○○のリスクがある」という形で、採用理由とリスクをセットにします。後から「そのリスクは分かっていたのか」という質問への答えになります。
項目5：承認・合意者（誰が確認したか）
「顧客○○様に○月○日に承認いただいた」「PM上司に相談・了承済み」という形で、誰が確認・合意したかを残します。
悪い記録・良い記録の例
悪い記録（議事録止まり）：
決定：○○機能はAパターンで進める
これだけでは、なぜAパターンになったかは分かりません。
良い記録（判断ログ）：
【判断】○○機能の実装方式をAパターンとする
【背景】顧客から○月○日に「○○画面の応答速度を改善してほしい」という要望
【選択肢】A案（非同期処理追加）・B案（キャッシュ追加）・C案（バッチ処理化）
【採用理由】B案はインフラ変更が必要で工数が大きい。C案はUIの変更が伴う。A案は既存アーキテクチャへの影響が最小。ただしA案は○○処理への副作用リスクあり→別途テスト追加で対処
【合意】顧客○○様に○日にメールで承認いただいた
顧客合意とのつなげ方
顧客に承認・確認をもらった判断は、判断ログと合わせてメールやチャットの文書番号・日付を記録しておきます。
「○月○日のメールで顧客が承認」という形で記録があると、後から「そんな合意はしていない」という話になった際に、ログを参照できます。議事録と判断ログをセットにして保管することで、プロジェクトの意思決定の流れが再現できます。
週次で棚卸しする運用
週に一度、以下の確認を判断ログに対して行うと、記録が活きてきます。
- 今週の判断で記録していないものがないか
- 先週の判断でリスクとして書いたものが現実になっていないか
- 来週以降に影響する判断で、顧客合意が必要なものが残っていないか
この棚卸しを週次定例の準備と同時に行うと、週次定例で共有すべき情報と判断ログが同期されます。
PM実務パックで実践力を高める
判断記録・議事録・顧客合意管理のスキルは以下で学べます。
決定ログの「運用ルール」を設定する
決定ログのテンプレートを作成しても、運用ルールがなければ記録が蓄積されません。「どのような決定を記録するか（重要度のしきい値）」「誰が記録するか（PMのみ・チーム全員）」「いつ記録するか（決定直後・週次まとめ）」という運用ルールを最初に設定することで、継続的な記録が実現します。
運用ルールを決めることが、決定ログを「形式だけの文書」から「実際に機能するプロジェクト記録」に変えます。
「検索可能な」決定ログを作る
決定ログが蓄積された後、必要な情報を素早く見つけられる構造にすることが重要です。「日付」「決定カテゴリ（技術・スコープ・スケジュール・コストなど）」「関係するステークホルダー」などのタグや分類が、後から検索しやすい決定ログを作ります。
検索可能な決定ログが、「あの決定はどこに記録したか」という探索コストをなくし、ログの実用性を高めます。
決定ログを「ナレッジベース」として活用する
プロジェクト完了後の決定ログを「次のプロジェクトへのナレッジベース」として活用することで、同じ判断を繰り返す際の参照情報になります。「過去のプロジェクトで同じ問題が生じた際、どう決定したか」という記録が、次の意思決定の質を高めます。
決定ログのナレッジベース化が、個人の経験を組織の資産に変える最も実践的な方法の一つです。
まとめ：決定ログが「言った・言わない」を消滅させる
プロジェクト管理における「言った・言わない」問題の多くは、決定ログの欠如によって生じます。決定ログのテンプレートを持ち、継続的に記録することで、この問題が根本から解消されます。記録の習慣が、PMとしての信頼性と説明責任を支える最も基本的な実践です。
決定ログへのアクセスと「共有範囲」の設定
決定ログを誰が見られるか、誰が更新できるかというアクセス権限の設定が重要です。「チーム全員が閲覧できるが、更新はPMのみ」「ステークホルダーも閲覧可能」などのアクセス権限の設定が、情報のセキュリティと透明性のバランスを取ります。
決定ログの共有範囲を明確にすることで、情報の過剰公開と情報の秘匿のバランスが取れた運用が可能になります。
「決定の品質」を後から振り返る
定期的に過去の決定を振り返り「その決定は良い結果をもたらしたか」を確認することで、意思決定の品質を高める学習が生まれます。良い決定のパターンと悪い決定のパターンの理解が、将来の意思決定を改善します。
決定ログの振り返りが、PMとしての意思決定力を継続的に高める仕組みになります。
「良い決定プロセス」を称賛する文化を作る
結果が良かった決定だけでなく、「良いプロセスで行った決定」を称賛することで、チームの意思決定の質が高まります。「この決定は関係者の意見を丁寧に集めた上でなされた」という評価が、チームの意思決定への取り組み方を改善します。決定ログが、良い決定プロセスを可視化し、チームが学ぶための材料を提供します。良い決定プロセスを組織の文化として育てることが、PMとしての最も長期的で価値ある貢献の一つです。
決定ログの一貫した管理が、PMとしての説明責任と信頼性を組織の中で確立します。記録の習慣がPMとしての評判を長期にわたって守ります。