リモートチームのための意思決定ログテンプレート：決定ごとに1ページ、担当者と却下した選択肢を残す

非同期チームが決定を文章で残す理由

同じオフィスにいるチームは、ほとんどの決定を口頭で済ませ、関係者はその場で耳にします。タイムゾーンが分かれた途端、それは機能しなくなります。起きていた人が決め、寝ていた人は後から知り、理由はすでに失われています。確定前に決定を書き出すと、3つのことが起こります。

• 決定を探せるようになる。 新しいメンバー、外部の協力者、そして1年後の自分が、誰かに聞く代わりに検索できます。
• 代替案が残る。 選んだ案そのものは、たいてい面白い部分ではありません。却下した案とその理由こそが、同じ議論が四半期ごとに蒸し返されるのを防ぎます。
• 決定に担当者がつく。 誰のものでもない決定は、静かに覆されます。名前の入った決定は、守られるか、意図を持って変更されます。

ソフトウェアの世界には、2011年からこのための形式があります。Michael Nygardが「Documenting Architecture Decisions」を公開した年です。彼のアーキテクチャ決定記録（ADR）は、タイトル、コンテキスト、決定、ステータス、影響の5つの部分から成り、ステータスの値はproposed、accepted、deprecated、supersededです。以下のテンプレートはその骨格を保ちつつ、一般的なチームに必要な項目を足しています。担当者、独立した節としての却下案、見直し日、そして相談した相手です。

意思決定ログのテンプレート

決定ごとに新しいページを作り、これを貼り付けてください。見出しは残し、不要な説明文は消して構いません。

タイトル: 短い名詞句。「データベース」ではなく「イベントストアにPostgresを使う」。
ID: DEC-014
ステータス: 提案中 | 承認済み | DEC-0xxにより置き換え | 廃止
担当者: 1人の名前。この決定を変更できる人。
決定日: 2026-10-28
見直し日: 2027-04-28（取り消せない決定なら「なし」）
相談した相手: 決定前に意見を求めた人
通知先: 決定後に知らせた人やチャンネル

== 背景
どんな状況が選択を迫ったか。意見ではなく、事実、制約、期限。
2〜6文で。

== 決定
選んだ内容を、能動態の完全な文で1〜2文：
「私たちは〜する」。

== 却下した選択肢
1. 案A：なぜ選ばれなかったか。
2. 案B：なぜ選ばれなかったか。
3. 何もしない：その場合の損失。

== 影響
何が楽になり、何が難しくなり、何を新たに負うか
（移行作業、トレーニング、後続の決定）。

== 確認方法
決定が正しかったとどう分かるか：指標、日付、チェック項目。

連番のID（DEC-001、DEC-002）は見た目以上に重要です。チャットのメッセージ、コミット、タスクが、いずれ切れるリンクなしに「DEC-014を参照」と書けるようになり、「DEC-021により置き換え」が曖昧でなくなります。

各項目の役割

ステータス。 「提案中」は担当者が書き上げてコメントを待っている状態。「承認済み」はコメント期間が終わり、決定が有効になった状態。「置き換え」は、これに代わる新しい決定を指します。「廃止」は、もう適用されず、代わりもないという意味です。承認済みの決定の本文は決して編集しないでください。新しい決定を書き、古い方を置き換えます。

担当者。 きっかり1人。チームでも、共同担当2人でもありません。担当者は決定を提案し、コメント期間を締め、誰かが変更したいときに最初に相談される人です。担当者を名指しできないなら、その決定はまだ準備ができていません。

背景。 働いている力：期限、予算、壊れた連携、要望を出した顧客。1年後の読者が「何もしない」が選べなかった理由を理解できるように書きます。議論は入れません。それは選択肢の節に書きます。

却下した選択肢。 ほとんどのテンプレートが省く節であり、最も見返りの大きい節です。却下した案ごとに1行と理由を書きます。「高すぎる」は理由になりません。「今のシート数だと月450ドル、こちらは39ドル」なら理由です。

影響。 良い面と悪い面の両方。良いことしかない決定は、考え抜かれていません。負債も含めます：これから必要になる移行作業、新たに採用が必要なスキル、先送りにした後続の決定。

確認方法。 決定が期待どおりに働いたかを、後からどう確かめるか。これはadr.github.ioのMADR（Markdown Architectural Decision Records）テンプレートから借りた項目です。MADRはContext and Problem Statement、Decision Drivers、Considered Options、Decision Outcome、Pros and Cons of the Optionsに加えてConfirmationの節を追加しました。確認方法の1行があると、見直し日は単なるカレンダーの通知ではなく、答えのある問いになります。

意思決定ログ、ADR、MADRの比較

チームの決定がすべてコードに関わるなら、ADRをリポジトリに置き、この記事の残りは読まなくて構いません。「どの給与計算サービスを使うか」「年額プランを出すか」といった決定が含まれるなら、リポジトリを開かない人も読める場所が必要です。

決定を非同期で文書化する手順

テンプレートは簡単な部分です。プロセスこそが、これを「入力作業が増えた会議」ではなく非同期の仕組みにします。

1. 決める前に「提案中」としてエントリを開く。 担当者が背景、決定の草案、少なくとも2つの却下案を書きます。先に代替案を書くことが本当の思考を強いるのであり、事後に書かれた決定はプレスリリースにすぎません。
2. コメント期間を明示する。 エントリに「木曜17:00 UTCまでコメント受付」と書きます。48時間あればすべてのタイムゾーンを2回カバーできます。取り消せる決定なら24時間で十分です。
3. 1つのチャンネルに、1つのメッセージだけ投稿する。 エントリへのリンク、期間、相談相手の名前を書きます。決定の全文をチャットに貼らないでください。ページが記録で、チャットは通知です。
4. スレッドではなくページにコメントする。 インラインコメントは対象の文に紐づいたまま残ります。チャットのスレッドは1週間で消えます。
5. 担当者が期間を締める。 コメントを反映して編集したうえで「承認済み」にするか、変更した理由を書いてより短い期間を再度設けます。沈黙は同意です。誰も驚かないよう、エントリにそう明記します。
6. 承認時に見直し日を設定する。 ツールやプロセスの決定なら6か月が妥当な既定値です。安く取り消せない決定なら「なし」と書き、理由を添えます。
7. 通知先に知らせる。 チームチャンネルに1行：「DEC-014承認：Xを使う。見直しは4月」。告知はこれで全部です。

ログを生かし続ける見直しのサイクル

ログが死ぬのは、誰も読まないからです。定期的な2つのチェックでそれを防げ、どちらも1人でできます。

毎週5分。 ログの管理者（通常はオペレーション担当）がステータス = 提案中で絞り込み、各エントリのコメント期間が黙って過ぎていないか確認します。期限切れのものは承認済みにするか、催促します。

毎月20分。 見直し日が今後30日以内のものを絞り込みます。各決定について、担当者が確認方法の行に対して1つのコメントで答えます：維持、変更ありで維持、または維持できず。維持できなかった決定には、置き換える新しい「提案中」エントリを作ります。ログに必要な会議はこれだけで、通話ではなく書面のまとめでも構いません。

ログが機能しているかは2つの数字で分かります。1つ目は、却下案が1つ以上書かれている決定の割合。80%を下回るなら、事後に記録されています。2つ目は「置き換え」になったエントリの数。1年経ってゼロなら、決定はチャットで変えられ、ログは作り話になっています。

Atrixでのログの運用

決定ごとに1ページを持ち、項目で絞り込めるツールなら何でも使えます。リポジトリのMarkdownファイル、Notionのデータベース、Confluenceのスペースなど。私たちはAtrixのページデータベースで運用しています。これはサブページが行になるページで、実際には次のようになります。

データベースのページに7つのプロパティを設定します（上限は20なので余裕があります）。ステータスは提案中・承認済み・置き換え・廃止の選択式、担当者は人物、決定日と見直し日は日付、相談した相手はテキスト、置き換え元は旧IDを入れるテキスト、確認済みは月次の見直しで付けるチェックボックスです。各行は完全なページなので、上のテンプレートは行の本文に、プロパティは表に入ります。使えるプロパティの型はテキスト、数値、選択、日付、チェックボックス、人物、URLで、数式やロールアップはありません。必要なら、隣にスプレッドシートを置いてください。

技術職でないチームにとって、ファイルのフォルダより優れている点が2つあります。コメントが対象の文の上に残ること、そしてページ履歴がすべての編集を保持するので、「承認後に誰が決定を変えたか」に答えが出ることです。ドキュメントとホワイトボードに、ページでできることの一覧があります。

毎日使うとは思っていなかったのがMCPサーバーです。AtrixのMCPサーバーはpages_createとpages_appendを含む85のツールを公開しているので、ワークスペースに接続したAIアシスタントがチャットのスレッドから決定エントリの草案を書き、誰も会話を離れることなくログに追記できます。pages_appendツールは、同時にページを編集している人を上書きせずにマージするので、担当者が文の途中でも問題ありません。アシスタントは「提案中」で草案を書くだけで、担当者の設定、期間の締め、承認済みへの変更は人が行います。設定はclaude mcp addコマンド1つとOAuthサインインだけです。MCPドキュメントにスコープの説明があり、Claudeや他の掲載アシスタントも同じ方法で動きます。

制限も明記しておきます。無料プランはなく、ワークスペースはBuilderで月39ドル（5シート）、Studioで月149ドル（15シート）、カード登録が必要な7日間のトライアル付きです。データベースに数式列はなく、ページのプロパティに対する「見直し期限」の自動通知もまだありません。私たちは代わりに月次の絞り込みを使っています。

よくある質問

意思決定ログと意思決定レジスターの違いは何ですか？

意味のある違いはありません。プロジェクトマネージャーはレジスター、ソフトウェアチームはログと呼びがちですが、どちらもステータスと担当者を持つ決定ごとのエントリを指します。検索が効くように、一つの呼び方に統一してください。

意思決定ログのエントリはどのくらい詳しく書くべきですか？

関わっていなかった人が、なぜその決定になり、何が却下されたかを理解できる長さで、それ以上は不要です。ほとんどのエントリは150〜400語に収まります。1ページを超えるなら、おそらく2つの決定が混ざっているか、決定からリンクすべき設計文書になっています。

アーキテクチャ決定記録（ADR）とは何ですか？

ADRは、アーキテクチャ上重要な決定を1件記録する短い文書です。背景、決定、ステータス、影響を書きます。形式はMichael Nygardの2011年の記事「Documenting Architecture Decisions」に由来し、通常はリポジトリ内に連番のMarkdownファイルとして置かれます。MADRはより構造化されたADRテンプレートで、検討した選択肢とその長所・短所の節があります。

意思決定ログの管理者は誰にすべきですか？

ログ全体の管理者は1人で、通常はオペレーション担当かエンジニアリングリードが務め、週次と月次のチェックを行います。各決定にはそれぞれ担当者がいて、その決定を変更できる人です。これらは別の役割で、通常は別の人が担うべきです。

小さな決定も記録すべきですか？

取り消しに1時間以上かかる、複数人の仕事に影響する、6か月後に誰かが「なぜ」と聞きそうなら記録します。どのlinterルールを有効にするかは記録不要ですが、どのlinterを使うかは記録します。

決定が間違いだったと分かったらどうしますか？

新しいエントリを書きます。古い方を新しいIDによる「置き換え」にし、本文はそのまま残します。ログは歴史であり、理由がそのまま残った間違った決定の記録は、当時分かっていたことを隠す修正済みの記録より役に立ちます。

次のステップ

「Decisions」というページを作り、ステータス、担当者、見直し日を持つデータベースにして、最初の行にテンプレートを貼り付けてください。ドキュメントとホワイトボードでエディタを確認でき、自分のチームで試すなら料金ページに各プランの上限があります。