仕様変更で炎上しない──決定ログ（ADR）を“1枚”で残す方法

仕様変更は、悪ではありません。
むしろ、良いプロダクトほど途中で変わります。市場が動く。学びが出る。ユーザーの声が集まる。技術的な制約が見えてくる。
問題は「変わること」ではなく、変わった理由と決め方が残らないことです。

• 「なんでこうなったんだっけ？」

• 「誰が決めたんだっけ？」

• 「前は別案じゃなかった？」

• 「いまさら戻すの？」

こういう会話が増えたら、炎上の入口に立っています。
そしてこの炎上は、コードの品質以前に、記憶の品質で起きます。

そこで効くのが、ADR（Architecture Decision Record）――決定ログです。
ただ、ADRという言葉を出すと、急に“重い運用”に見えることがあります。
テンプレが増える。レビューが増える。ドキュメントが増える。
結果、続かない。

だから、今日の記事は「1枚」に絞ります。
仕様変更で炎上しないための決定ログを、A4 1枚（または1画面）で残す方法。
プロセスを増やすのではなく、手戻りを減らすための最小設計としてまとめます。

炎上の多くは「決定」ではなく「再議論」が原因

仕様変更があると、必ず議論が起きます。
その議論自体は健全です。問題は、議論が何度も繰り返されること。

繰り返される理由は単純で、過去の決定が再利用できないからです。

• 前提（制約）が何だったか思い出せない

• 検討した選択肢が残っていない

• 何を優先して決めたかが曖昧

• “なぜその案になったか”の理由がない

• 後から参加した人に説明できない

つまり、決定が「その場限り」になっている。
その結果、同じ論点を何度も回し、会議が増え、手戻りが増え、責任の押し付け合いが始まる。

炎上は、仕様変更の頻度ではなく、再議論の頻度で起きます。

ADRは「正しさ」より「再利用性」を残すためにある

ADRは、立派な設計書ではありません。
あとから読んだ人が「当時の判断を再現できる」ことが目的です。

ここで大事なのは、完全な情報を残すことではなく、判断に必要な要素を残すこと。
だから“1枚”で十分です。むしろ、1枚のほうが続きます。

“1枚ADR”が向いている決定はどれか

まず、全部の決定をADRにしようとすると破綻します。
書くべき決定は、未来の手戻りを発生させやすい決定だけです。

目安は次のどれかに当てはまるとき。

• 影響範囲が広い（複数モジュール、複数チーム、運用まで波及）

• 後戻りコストが高い（DB、API、データ移行、契約、SLA）

• トレードオフがある（性能 vs 保守性、速度 vs 品質、短期 vs 長期）

• 意見が割れた（合意形成が必要だった）

• 仕様変更が起きやすい領域（要件が揺れる、未知が多い）

逆に、単なる実装詳細や微小な変更は書かない。
ADRは“重さ”ではなく“効き目”で選ぶのがコツです。

仕様変更で炎上しない“1枚ADR”

ここから本題です。
これだけ埋めれば、後から「再議論」しなくて済む確率が一気に上がります。

1枚ADR（1画面）テンプレ

1) タイトル（決定の名前）
例：ユーザー検索のソート仕様を「関連度優先」に変更する

2) ステータス
Proposed / Accepted / Superseded（置き換え） / Deprecated
※置き換えたら、リンクで追えるようにする

3) コンテキスト（背景）— 5行以内

• 何が問題だったか

• どんな制約があるか

• 何が変わったのか（新情報）

4) 決める問い（Decision）— 1行
例：「検索のデフォルトソートを何にするか」

5) 判断基準（Constraints / Criteria）— 最大3つ
例：

• 検索体験（CVR）を優先

• 既存ユーザーの混乱を最小化

• 実装/運用コストが増えすぎない

6) 選択肢（Options）— A/B/Cで十分

• A：現状維持

• B：関連度優先（推奨）

• C：ユーザーごとに学習（将来案）

各選択肢に、メリット/デメリットを箇条書きで2～3行。

7) 決定（Outcome）

• 採用案：B

• 理由：判断基準に照らして最もバランスが良い

8) 影響範囲（Consequences）

• 変わるもの：API、DB、UI、運用、サポート

• リスク：パフォーマンス、回帰、問い合わせ増

• 依存：データ、他チーム、外部契約

9) ロールバック/置き換え条件（Exit / Revisit）
ここが炎上防止の肝です。
「何が起きたら見直すか」を先に書く。

例：

• 指標XがY%悪化したら戻す

• 例外ケースが一定数を超えたら再検討

• ○月のABテスト結果で確定

10) 決定日・参加者・リンク

• Date

• Deciders（決定者）

• Contributors（議論参加者）

• 関連PR/Issue/Doc/Slackスレ

この10項目で、十分です。
長文である必要はありません。大事なのは“空欄がない”ことです。

なぜこのテンプレが炎上を止めるのか

1) 「誰が」「何を」「なぜ」を固定できる

炎上では、議論の内容よりも「責任の所在」が曖昧になります。
決定者と決定理由が残っていれば、責任追及ではなく改善に向かいます。

2) 「基準」が残ると、議論が短くなる

後から参加した人が違う意見を持つのは自然です。
でも基準が残っていれば、議論は「好み」ではなく「基準の更新」に変わります。
これが建設的です。

3) 「置き換え条件」があると、恐怖が減る

仕様変更が怖いのは、“戻れない”感覚があるからです。
見直し条件があると、決定は賭けではなく実験になります。
チームが動けるようになります。

運用でつまずくポイントと対策

つまずき1：書くのが面倒で続かない

対策：最初から「書く人」を固定しない。
決定の提案者が書く。レビューで補う。
ADRは議事録ではなく、意思決定の成果物です。

つまずき2：完璧に書こうとして重くなる

対策：“5分で書ける”ことを守る。
1枚に収まらないなら、論点が大きすぎるか、決定が分割できるサインです。

つまずき3：ADRが読まれない

対策：リンクの導線を強制的に作る。

• PRテンプレに「関連ADR」欄を作る

• IssueにADRリンクを貼る

• 仕様変更の会議招集文にADRリンクを入れる

「そこに行けばわかる」を作ると、文化になります。

実務で最も効くコツ：ADRは「議論の後」ではなく「議論の前」に作る

ADRを“決まった後の清書”にすると、だいたい書かれません。
おすすめは逆です。

• まずADRをProposedで作る

• 議論はADRにコメントして進める

• 決まったらAcceptedにする

こうすると、ADRはドキュメントではなく“議論の器”になります。
決定が自然に残ります。これが最もラクです。

まとめ：仕様変更に強いチームは「記憶」を仕組みにしている

仕様変更で炎上しないチームは、特別に優秀だからではありません。
「決めたこと」を、人の記憶に頼らず、再利用できる形で残しているだけです。

1枚ADRは、その最小単位です。

• 背景（コンテキスト）

• 決める問い

• 判断基準（最大3つ）

• 選択肢

• 決定と理由

• 影響範囲

• 見直し条件

• 決定者とリンク

これだけで、再議論は減り、手戻りは減り、責任の押し付け合いも減ります。
そして何より、仕様変更が“怖くなくなる”。

変化が多い時代に、仕様変更をゼロにすることはできません。
でも、炎上は減らせます。
そのために必要なのは、根性ではなく、決定ログという仕組みです。

次に読む

はじめての方へ：