意思決定ログ：理由を確実に残すための記録方法

組織は「何を決定したか」は覚えていても、「なぜ決定したか」は忘れてしまいます。意思決定記録の仕組み、記録すべき項目、軽量なテンプレート、そして各記録を成果に結びつける方法について解説します。

Ibrahim Elkobeissi · 2026年11月2日 · リーディング時間 6分 ·

要約すると、

決定は、その理由よりも長く存続することがよくあります。理由が失われると、チームは理解できないままルールを維持し続けたり、根拠なく決定を覆したりしてしまいます。
後知恵は記憶を歪めます。そのため、決定した瞬間に書かれた記録だけが、その時に何を知っており、何を期待していたかを正確に保存できるのです。
有用な意思決定記録には、コンテキスト、選択肢、決定事項、責任者、根拠、期待される成果、レビュー日、およびステータスが含まれます。
過去の決定を編集してはいけません。それは「置き換え済み」としてマークし、新しい決定へとリンクさせてください。

チームに「なぜこのポリシーがあるのか」と尋ねると、しばしば沈黙が流れます。ある人は会議のことを思い出し、別の人はサプライヤーの問題だったと考えています。事情を知っていた担当者は、昨年退職してしまいました。決定は残りましたが、その理由は残らなかったのです。

これはよくあることですが、コストがかかる問題です。理由がなければ、チームには2つの悪い選択肢しか残されません。理解できないまま決定を維持するか、決定を覆して、かつて解決したはずの問題を再発させるリスクを冒すかです。意思決定ログは、第3の選択肢を提供します。記録を読み、条件が今も有効かを確認し、意図を持って再び決定を下すのです。

なぜ組織は「決定の理由」を忘れてしまうのか

組織が自らの決定を忘れてしまう背景には、3つの要因があります。

理由は会話の中に存在する。 決定は会議や電話、メッセージのやり取りの中で行われます。その結果はポリシーや計画に反映されますが、コンテキスト（背景）が反映されることは稀です。
人は移動する。 選択肢を検討した人々は、役割が変わったり退職したりします。彼らの理解とともに、知識も失われてしまいます。
記憶は書き換えられる。 1975年の研究で、心理学者のBaruch Fischhoffは、人は結果を知ってしまうと、それを実際よりも予測可能であったと判断することを発見しました。彼はこれを「クリーピング・デターミニズム（忍び寄る決定論）」と呼びました。事後的に見れば、結果が悪かった正当な決定は「不注意」に見え、運が良かった決定は「賢明」に見えてしまうのです。

最後の一点が最も重要です。たとえ同じメンバーが残っていたとしても、なぜその決定を下したかという記憶は、その後に起きた出来事によって形作られてしまいます。決定した瞬間に書かれた記録だけが、何を知っていたか、何を期待していたか、そして何が不確実であったかを保存できるのです。

Microsoftのアーキテクチャ・ガイダンスは、そのコストを明確に述べています。記録されない決定は「忘れ去られる可能性が高く、繰り返される議論を招く」とされています。

ソフトウェアチームが学んだこと：アーキテクチャ決定記録（ADR）

ソフトウェアエンジニアリングには、確立された回答があります。2011年11月、Michael Nygardは「アーキテクチャ決定記録（ADR）」を提案しました。これは、重要な決定ごとに作成される短い文書で、番号を順に振り、プロジェクトと共に保管されるものです。彼のフォーマットは5つの要素で構成されています。

タイトル。 「ADR 9: マルチテナント統合のためのLDAP」のように、番号を含む短い名詞句。
コンテキスト。 技術的、政治的、社会的、あるいは局所的な要因。Nygardは、このセクションは価値中立的であり、事実の記述であるべきだと述べています。
決定。 それらの要因に対する回答。「私たちは……を行う」といった、能動態の完全な文章。
ステータス。 提案中、承認済み、廃止、または置き換え済み。置き換えられた場合は、その参照先を明記します。
結果。 その決定によって生じる状況。Nygardは、「『ポジティブな』結果だけでなく、すべての結果をここに記載すべきである」と述べています。

この手法は広がりました。Thoughtworksは、軽量なADRをTechnology Radarの「Adopt」リング（最も推奨されるレベル）に配置し、個別のWikiではなくソース管理に保管することを推奨しました。MicrosoftのAzure Well-Architected Frameworkでも、意思決定記録はソリューションアーキテクトの最も重要な成果物の一つとされています。そのガイダンスには、取り入れる価値のある2つのルールがあります。ログは「追記のみ（append-only）」として扱い、各決定に「確信度」を記録することです。

これらはソフトウェア特有の話ではありません。病院は入院手続きを変更し、学校は評価ポリシーを変更し、機関はサプライヤーを変更します。これらの決定にはすべてコンテキスト、選択肢、結果があり、後になって、その場にいなかった誰かによって疑問を呈されることになるのです。

意思決定記録に含めるべき項目

意思決定ログとは、これらの記録を集約し、各記録を要約したインデックスを持つものです。Microsoftのエンジニアリング・プレイブックでは、ログを「詳細な記録に含まれる決定事項の、メタデータ付きのエグゼクティブ・サマリー（要約）のテーブル」と定義しています。以下の意思決定ログのテンプレートは、エンジニアリング以外の分野でも有効です。各項目には明確な役割があります。

IDとタイトル。 番号と、何が決定されたかを示すフレーズ。
日付。 決定が下された日（記録が作成された日ではありません）。
責任者。 その決定に対して責任を持つ人物、および相談した人物。
コンテキスト。 課題、制約、および対立する要因。
検討した選択肢。 却下したものとその理由も含みます。これは最も欠落しがちであり、かつ最も必要とされる項目です。
決定。 「私たちは……を行う」で始まる、明確な一文。
根拠。 決定の拠り所となったデータ、レポート、監査結果、またはフィードバックへのリンク。
期待される成果。 決定が機能した場合に、いつまでに、何が実現しているべきか。
信頼度。 高・中・低で示し、不確実な要素を明示します。
レビュー日。 決定事項が期待通りの結果となったかを確認する日です。
ステータス。 提案中、承認済み、上書き、または廃止。置き換えとなる項目へのリンクも含まれます。

期待される結果と信頼度のフィールドは、Decision Journal（決定のジャーナル）としての役割を果たします。結果を知る前の「確信」を記録することで、後知恵によって消し去られてしまうプロセスを正確に残します。

私たちは、自社の製品開発においても同じ習慣を大切にしています。観察された事実と推論された内容は明確に分けて記録し、対立する意見も無理にまとめず、そのまま残します。意思決定には、少なくともそれだけの慎重さが必要だからです。

各決定を、その根拠と結果にリンクさせます。

単独で存在する記録よりも、何もないよりはマシですが、リンクされた記録の方がはるかに有用です。

根拠へのリンク。 決定の根拠として患者アンケート、コスト分析、またはインシデントレポートを引用する場合は、ソース自体にリンクしてください。後から読む人が、その根拠が今も有効かどうかを判断できるようになります。Microsoftのガイダンスでも同様の点が指摘されています。正当な理由のない記録は「時間の経過とともに価値を失う」のです。

結果へのリンク。 レビュー日には、期待されていたことに対し、実際に何が起きたかを記述します。もし大きな乖離がある場合は、その理由を問い直してください。根拠が弱かったのか？条件が変わったのか？決定は正しかったが、単に運が悪かっただけなのか？その答えこそが教訓であり、同じ連鎖の中に残すべきものです。次のプロジェクトを変える教訓に関する記事では、そのような教訓を定着させる方法を解説しています。

後継へのリンク。 決定が覆された場合、古い記録を編集しないでください。「上書き（superseded）」としてマークし、新しい記録へ誘導します。方向転換の履歴こそが、ログの中で最も価値のある情報になることが多いためです。

仮の例で、この連鎖を見てみましょう。あるクリニックが、フォローアップの電話を看護師から専任のコーディネーターへ移行することを決定しました。記録には、電話完了率のデータが引用され、責任者としてオペレーションマネージャーが指定され、3ヶ月以内に完了率が上がると予測され、レビュー日が設定されています。レビュー時、完了率は上がりましたが、看護師の業務負荷は期待ほど減っていませんでした。新しい記録が最初の記録を上書きし、役割を調整して、最初の記録へとリンクを戻します。2年後、新しいマネージャーは、わずか5分でこれまでの経緯をすべて読み解くことができます。

継続できるよう、軽やかに保つ

決定ログが失敗する理由は、ほとんどのドキュメントが失敗する理由と同じです。それが「作業」になってしまい、やめてしまうのです。5つのルールが、ログを機能させ続けます。

重要な決定のみを記録する。 Microsoftの基準が有用です。構造を形作るもの、主要な品質に影響するもの、あるいは覆すのが困難な決定を記録します。
各記録は簡潔に。 1ページ以内。詳細をコピーするのではなく、補足資料へのリンクを活用してください。
決定した瞬間に書く。 同じ週に書かれた記録は正確ですが、数ヶ月後に書かれたものは「再構成」に過ぎません。
業務が行われる場所に置く。 計画や手順のすぐそばにあるログは読まれます。別のフォルダに隔離されたログは読まれません。
今すぐ始め、後からいくつか補完する。 まずは新しい決定から始めましょう。その後、頻繁に質問される過去の決定をいくつか再構成し、それらが「再構成されたもの」であることを明記します。

理由のない決定は単なる「指示」です。理由が添えられた決定は、注意深く検証し、維持し、あるいは変更することができます。

Prismが決定の記録を管理する方法

Prism は、組織の決定と知識を、Ratified（承認済み）、Evidenced（根拠あり）、Observed（観察済み）、Inferred（推論済み）といった信頼レベルを持つアイテムとして保持します。各決定は、その根拠、実行ステップ、そしてその後に続く結果や「Pause and Learn（立ち止まって学ぶ）」の教訓へとリンクします。決定が上書きされても、以前の記録は可視化されたままです。チームがすでに使用しているアシスタントも記録を読み取れるため、誰かが尋ねたときに、いつでも理由を確認できます。決定を下すのは人間です。Prismはその理由を保持します。