ROADYOM
JA
始める
無料テンプレート ・ 意思決定ログ

意思決定は会議よりも長く残ります。その理由も記録しましょう。

人は意思決定をした後、次の業務へと移ります。決定事項は残りますが、その理由は本人と共に消えてしまいます。意思決定ログがあれば、「何を」決めたかだけでなく「なぜ」決めたかも記録され、その場にいなかった同僚にも共有できます。

アラビア語版: XLSX ・ CSV

却下した選択肢と、その理由 自動で通知されるレビュー日 英語・アラビア語

積み上げられたファイルと、窓際に置かれたプリントアウトがあるデスク
重要性について

後知恵は記憶を書き換えますが、記録は書き換えません。

理由がなければ、チームは理解できないまま決定に従い続けるか、決定を覆して解決済みの問題を再発させることになります。

1975

心理学者のBaruch Fischhoffは、人は結果を知ってしまうと、それが実際よりも予測可能であったと判断してしまうことを示しました。彼はこれを「クリーピング・デターミニズム(漸進的決定論)」と呼びました。

Journal of Experimental Psychology
忘却

Microsoftのアーキテクチャ・ガイダンスでは、記録されない意思決定は「おそらく忘れ去られ、繰り返される議論を招く」とされています。ログは追記専用(append-only)とし、各決定に信頼度を付与して管理しましょう。

Microsoft Learn
2011

Michael Nygardは、タイトル、コンテキスト、決定事項、ステータス、影響(consequences)からなる意思決定記録を提案しました。「影響は『ポジティブなもの』だけでなく、すべてここに記載すべきである」としています。

Michael Nygard
採用

Thoughtworksは、その最も強力な推奨事項として、Technology RadarのAdoptリングに軽量な意思決定記録を配置しています。

Thoughtworks
テンプレート

1決定につき1行。新しいものから順に記載。

クリニック、学校、サービスセンター、銀行の支店。これらすべてにおいて、重要な意思決定には共通の項目が用いられます。

IDタイトル決定済み担当者決定期待される成果信頼度レビューステータス
D-005口座開設の事前予約制2026-10-20支店長口座開設の事前予約枠を設け、当日受付も継続する。簡易的な依頼に対する待ち時間の短縮。低2027-02-28提案中
D-004コーディネーターの役割に退院電話を追加2026-06-12オペレーションマネージャー7月からコーディネーターの役割に退院連絡業務を追加する。12月までに、看護師の電話対応時間を削減する。中2026-12-15承認済み ・ D-001を上書き
D-003サービスカウンターは月曜日の7:30に開店2026-05-05サービスセンターマネージャー6月から毎週月曜日のカウンターを7:30にオープンする。9月末までに、月曜日の平均待ち時間を短縮する。高2026-10-15承認済み ・ レビュー期限
D-002学期末試験に代わり、2回の短期間アセスメントを実施2026-04-22教頭(教務)9月より、7年生から9年生を対象に、各学期につき2回の短期間アセスメントを実施します。教師は、学期中盤の結果を受けて2週間以内に対応を行います。中2027-01-31承認済み
D-001フォローアップ電話をコーディネーターへ移行2026-02-10オペレーションマネージャー3月1日より、フォローアップの電話業務を専任のコーディネーターへ移管します。3ヶ月以内に完了率が向上します。中2026-06-01D-004により置き換え済み

XLSXファイルは、レビュー日が経過しても結果が記入されていない場合、「レビュー期限」のフラグを表示します。 これらのファイルには、背景、検討した選択肢、根拠、不明な点、レビュー時の結果に加え、1ページの記録シートが含まれます。

検討した選択肢

却下されたものとその理由を含めます。最も記入漏れが多く、かつ最も必要とされる項目です。

決定

「We will...(私たちは〜します)」で始まる、能動態の1文。

根拠

アンケート、レポート、またはログ自体へのリンクを貼り、後から読む人がその妥当性を判断できるようにします。

期待される成果

機能が有効である場合に期待される状態と、その期限。詳細が確定する前に記述します。

信頼度

高、中、または低。あわせて、不明な点について1行記述します。

ステータス

提案、承認、置き換え、または廃止。置き換えの場合は、後継の記録へリンクさせます。

使用方法

決定した週に記入してください。

  1. 対象を選択する

    業務の進め方を左右するもの、品質や安全性に影響するもの、または取り消しが困難な決定事項。すべての購入品が対象ではありません。

  2. その週のうちに記録する

    決定した週に書かれた記録は正確です。数ヶ月後に書かれたものは、単なる再構成に過ぎません。

  3. 却下された選択肢を明記する

    そして、なぜそれぞれが選ばれなかったのか。それこそが、次のチームが再検討したいと考える情報です。

  4. 期待値を述べる

    結果、日付、および確信度。後知恵は、これら3つすべてを消し去ろうとします。

  5. 期日にレビューを行う

    期待していた内容の隣に、実際に何が起きたかを記入します。根拠の不足、状況の変化、あるいは不運など、その理由を明記してください。

  6. 上書きせず、置き換える

    新しい記録が古い記録を置き換え、古い記録へとリンクさせます。方針転換の履歴こそが、しばしば最も価値のある部分となります。

よくある間違い

なぜ決定ログは形骸化するのか。

すべてを記録する

ログが議事録のようになってしまう。誰も読まなくなり、その結果、誰も書かなくなります。

採用された選択肢のみを記録する

却下された選択肢がなければ、1年後に全く同じ議論が繰り返されることになります。

数ヶ月後に書き起こす

その頃には結果が判明しており、記録が結果に左右されてしまうからです。

承認された決定事項の編集

足跡が途絶えてしまいます。新しい記録を作成し、古い記録は「更新済み」としてマークしてください。

レビュー日なし

それでは、その決定が約束通りの成果を上げたのか、誰も知ることができなくなります。

別のフォルダに保管

計画や手順のすぐ横にあるログは読まれますが、フォルダの中にあるものは読まれません。

スプレッドシートでは不十分になる時

ログ自体が、自律的に記憶を保持する必要があるとき。

スプレッドシートは行を保持するだけです。それぞれの行がどこまで信頼できるのか、あるいはその次に何が起きたのかを示すことはできません。

  • 「なぜあの決定をしたのか?」という問いへの答えが、誰かの受信トレイの中に眠っています。
  • 決定、手順、教訓が、決して交わることのない別々のファイルに存在しています。
  • 承認された決定と、誰かの推測を区別することができません。
  • チームが使用しているアシスタントは、あなたがなぜその決定を下したのかを知ることができません。

ROADYOM PRISM

すべての決定には、その重みがあります。

Prismは、組織の決定と知識を、承認済み、根拠あり、観察済み、推論済みといった「信頼レベル」を持つアイテムとして保持します。各決定は、その根拠、実行ステップ、そしてその後に続く結果や「Pause and Learn」の教訓へとリンクします。決定が更新されても、以前の決定は可視化されたままです。決定を下すのは人間ですが、その理由を保持するのがPrismです。

疑問への回答

これは議事録と同じものですか?

いいえ。議事録は「話されたこと」を記録するものです。決定記録は、「何が決まったのか」「なぜ決まったのか」「他にどのような選択肢があったのか」「何を期待していたのか」を記録します。長さは1ページ以内です。

誰が記録を書くべきですか?

決定の責任者、またはその責任者が指名した人物が、決定と同じ週に作成します。相談を受けた人々は、その記録を読み、事実関係を修正できる状態である必要があります。

数年前に下した決定についてはどうすればよいですか?

まずは新しい決定から始めてください。その後、頻繁に質問される過去の決定をいくつか再構築し、「再構築済み」としてマークしてください。

これはソフトウェアエンジニアリングの手法ではないのですか?

始まりは、アーキテクチャ決定記録(ADR)でした。しかし、この手法にソフトウェア特有の要素はありません。入会規則、評価ポリシー、営業時間にも、コンテキスト、選択肢、そして影響が存在します。

Confidence(確信度)は何をもたらしますか?

結果を知る前に、何を信じていたかを記録します。レビューの際、確信を持って下した決定が失敗した場合と、慎重に下した決定が失敗した場合では、得られる教訓が異なります。

決定を削除すべき時はありますか?

いいえ。廃止するか、更新してください。覆された決定の記録こそが、次のチームが同じ過ちを繰り返さないための手段となります。

ソース (5)
  1. Hindsight ≠ foresight: The effect of outcome knowledge on judgment under uncertainty. Journal of Experimental Psychology: Human Perception and Performance 1(3) (B. Fischhoff), 1975.
  2. Documenting Architecture Decisions. Michael Nygard, Relevance (now Cognitect) blog, 2011.
  3. Architecture decision record (Azure Well-Architected Framework). Microsoft Learn, 2024.
  4. Decision Log (Code-With Engineering Playbook). Microsoft, 2024.
  5. Lightweight Architecture Decision Records (Technology Radar). Thoughtworks, 2018.

目的を持って決定する。それを2度繰り返す。

一度目は選択するとき。二度目はレビューするとき。無料、英語およびアラビア語に対応。