意思決定ログ：最も少ない労力で最も効果的なドキュメント

ある会社のエンジニアリングチームは、18か月前に廃止したはずのサードパーティAPIへの依存を再構築しようとしていました。廃止した理由を誰も覚えていませんでした。当時の決定に関わったエンジニアは3人全員が退職していました。そのため2週間かけて同じ評価を再度行い、同じ結論に至りました。

意思決定ログがあれば、15分で済んでいたはずです。

意思決定ログは、チームが下す決定と、なぜそう決めたかを記録する軽量なドキュメントです。複雑なツールは必要ありません。特定のフォーマットへの厳格な遵守も不要です。ただ、後から参照できる場所に記録するだけでいいのです。

なぜほとんどの意思決定ログは機能しないのか

多くのチームが意思決定ログを試みて、3か月以内にやめてしまいます。理由は決まっています：複雑にしすぎるか、間違った決定を記録するかのどちらかです。

複雑にしすぎる場合：ログが詳細すぎるフォームになり、各エントリに30分かかります。そうなると、誰も書かなくなります。

間違った決定を記録する場合：すべての決定を記録しようとします。昼食の場所、来週のミーティングの時間、フォントの選択。ログはすぐにノイズで満たされ、実際に重要な決定が埋もれてしまいます。

効果的な意思決定ログは、記録する価値のある決定と記録する必要のない決定を区別します。

どの意思決定を記録するか

すべてを記録しようとしないでください。次の基準のいずれかを満たす決定のみを記録してください：

容易に覆せない決定：アーキテクチャの選択、ベンダーの選定、採用、主要なプロセス変更。これらは後で「なぜそうしたの？」という質問を引き起こします。

複数の合理的な選択肢があった決定：1つの明らかな選択肢しかない場合は、記録する価値はほとんどありません。しかし2〜3つの合理的なオプションがあり、1つを選んだ場合、その理由は価値があります。

定期的に表面化する決定：「これについてはすでに議論したことがある」と思ったら、それはログに属します。

新入社員が新たに一から評価しそうな決定：Onboarding中に誰かが「なぜXではなくYを使うの？」と尋ねるでしょう。答えがどこかに存在すべきです。

5つのフィールド

各エントリには5つのフィールドだけが必要です。それ以上でも以下でもありません：

1. 日付 決定がいつ行われたか。精確な時刻は不要、日付だけで十分です。

2. 決定内容 何が決定されたかを1〜2文で記述します。「XではなくYを使うことにした」または「Zを廃止することにした」。能動態で書いてください。

3. コンテキスト なぜこの決定が必要だったのか。解決しようとしていた問題、存在していた制約、考慮した要因。これが最も価値ある部分です。なぜなら、これが時間とともに失われる部分だからです。

4. 検討した代替案 選ばなかったオプションと、なぜ選ばなかったのか。これにより、後で「なぜXを試さなかったのか？」という議論を防ぎます。

5. 決定者 誰が最終的な決定を下したか。委員会ではなく、個人の名前で記します。「チーム」や「マネジメント」とは書かないでください。

これだけです。良いエントリは1〜3段落で書けます。それ以上かかるようなら、複雑にしすぎています。

3か所でログを定着させる

意思決定ログの最大の失敗は、ドキュメントを作成しても誰もそこに書かないことです。定着させる鍵は、決定が起きる場所にログを組み込むことです。

ミーティングのアウトプットとして：ミーティングで決定が行われたら、その場でログに記録することをアジェンダに含めてください。ミーティング後に誰かが「決定事項をログに追加してください」というメッセージを送るよりも、ミーティング中にやる方がはるかに定着します。ミーティングノートとは別のドキュメントを作る必要はありません。ミーティングノートの末尾に「決定」セクションを追加するだけでも十分です。

Slackスレッドのクロージャーとして：非同期の会話で決定が行われたとき、スレッドはしばしばそのまま消えていきます。ルールを作ってください：何らかの決定で解決したSlackスレッドは、最後のメッセージに意思決定ログへのリンクを含めるべきです。これはスレッドに結論をつけると同時に、決定を検索可能にします。

コードレビューやデザインレビューのコメントとして：エンジニアリングやデザインチームにとって、最も価値ある決定はしばしばレビュープロセス中に行われます。「なぜこのアーキテクチャを選んだのか」または「なぜこのパターンではなくこちらを選んだのか」というコメントは、その場でログに追加する価値があります。

ログを実際に使えるものにする

意思決定ログは書かれるだけでは意味がありません。実際に参照されなければなりません。参照されるドキュメントにする方法：

検索可能にする：ログが検索できないなら、存在しないも同然です。Notion、Confluence、Reworkは全文検索が可能です。チームが使うツールに置いてください。

1か所に保管する：チームで1か所のログを持ってください。プロジェクトごとに別々のログを持つと、「あの決定はどのログにあったっけ？」という問題が生じます。チームの主要なドキュメントハブに1つのログを持ち、プロジェクトやドメインでタグ付けしてください。

Onboarding時に使う：新しいチームメンバーのOnboardingで意思決定ログを参照するプロセスに含めてください。「このログを読むと、私たちが過去2年間に行った主要な決定と、なぜそうしたかがわかります」。これが最も速くログの価値を示す方法です。

古い決定を更新する：決定が変わったとき、古いエントリを削除しないでください。新しいエントリを追加して、以前の決定を参照し、なぜ変えたかを説明してください。これにより「この決定は変わっているが、古いエントリはまだある」という混乱を防ぎます。

四半期レビュー

意思決定ログを書くだけでなく、四半期ごとに短いレビューを実施してください。

レビューは30分以下で行えます：

  • 過去の四半期のエントリをスキャンします
  • まだ有効な決定を確認します
  • 変わった、または再検討が必要な決定を特定します
  • 最も頻繁に参照されたエントリを確認します（何が最も価値があるかを示します）

四半期レビューには追加の利点があります：ログを最新の状態に保つ習慣を作り出します。古いエントリが消えずに記録に残るので、「私たちはいつ、なぜこれを決めたのか？」というケースを追いかけられます。

よくある失敗

意思決定ではなくタスクを記録する：「デプロイを完了した」はログに入れるべきではありません。「マイクロサービスアーキテクチャを採用することにした」は入れるべきです。

コンテキストを省略する：「YではなくXを選んだ」はほとんど役に立ちません。「コストと保守性の理由でYではなくXを選んだ。Yは50%安価だが、独自のライブラリに依存しているため将来の乗り換えコストが高い」がログの価値です。

ログをドキュメントではなく議論の場にする：意思決定ログは記録であり、議論の場ではありません。決定が既に下された後に書いてください。意思決定プロセス自体は別の場所で行ってください。

役割ではなく名前を使わない：「エンジニアリングチームが決定した」ではなく、「Tanaka（テックリード）が決定した」と書いてください。役割は変わりますが、決定のコンテキストは残ります。

次のステップ

今週、1か所に意思決定ログを作成してください。テンプレートは過剰に複雑にしないでください。5つのフィールドのシンプルな表またはドキュメントで十分です：日付、決定内容、コンテキスト、代替案、決定者。

次に、過去の四半期から3〜5件の重要な決定を思い出し、今遡って記録してください。これによりログに初期コンテンツが入り、どのような決定を記録すべきかについてのチームの直感を較正します。

最後に、次のチームミーティングの最後に5分間を確保してください。そのミーティングで行われた決定を一緒に記録してください。習慣が始まるのはそこからです。

関連記事