ADRを導入しよう、と決めて、テンプレートを配る。
書き方も説明する。
それでも、なぜか埋まらない。
数週間もすると、誰も書かなくなっている。

フォーマットが悪いのだろうか。
レビューが甘いのだろうか。
そう考えて運用ルールを足すほど、ハードルだけが上がって、ますます書かれなくなる。
問題は、たぶんフォーマットのもっと手前にある。

ADRが定着しない構造的な原因

意思決定している自覚がない

書かれない理由を、フォーマットの外に探してみる。
すると、意外なところに行き着く。
そもそも、意思決定している自覚がないのだ。

議論は、「なんとなく合意が形成されて」流れていく。
どこが分岐点だったのか、当人たちも認識していない。
だからADRを書こうにも、何を書けばいいか分からない。
これはフォーマットの問題ではなく、メタ認知スキルの問題だ。

まず「決定の言語化」の習慣から始める

だとすれば、最初に必要なのはテンプレートではない。
決定を、決定として意識する習慣だ。

いきなりADRを求める前に、会議の最後にこう聞く。
「今日決まったことって、何でしたっけ」。
この一言だけで、「何が決まったか」「何を捨てたか」が浮かび上がる。
ADRは、その延長線上に自然と置ける。
順番が逆だと、習慣の土台がないところにフォーマットだけが浮いて、機能しない。

ADRを定着させるための設計

品質水準は「文脈が分かればいい」で十分

土台ができたら、次は品質の話だ。
ここでも、力を入れる方向を間違えやすい。
正確性を担保しようとレビュープロセスを重ねると、書く側にも読む側にもハードルが上がりすぎる。

ADRは本来、「後から読んで文脈が分かればいい」程度のものだ。
なぜその選択肢を選んだのか。
他に何を検討したのか。
どんな制約があったのか。
これらが大まかに分かれば、目的は果たせている。
会議の議事録ベースで書けば、自然とこの水準に収まる。
完璧を目指すと、かえって定着しない。

会議のアウトプット形式に組み込む

そして、書く起点を個人に置かない。
「ADRを書いてください」と個人に頼むのと、会議のアウトプット形式にADRを組み込むのとでは、行動の起点がまるで違う。
前者は個人の意志に依存するから、続かない。
後者はプロセスに埋め込まれるから、定着する。
ただし、会議中に「何が決まったか」「何を捨てたか」を整理できるファシリテーターは要る。

ADRは全部読むものではない

運用の話になると、「増えすぎたら読み切れない」という懸念が出る。
だが、コードのGit履歴を全コミット読む人がいないのと同じだ。
ADRも、全部読む必要はない。
「必要なときに必要なものを引ける」状態であればいい。

量には、二つの手当てが効く。

• 階層化。個別ADRとは別に「主要な意思決定の地図」を1ページ持つ。新メンバーはまずそれだけ読み、詳細は個別ADRへリンクで辿る
• ライフサイクル管理。有効・廃止・置換のステータスで、最新の決定だけが見えるようにする

ADRの必要性をどう伝えるか

最後に、いちばん動かしにくいものが残る。
そもそも、なぜADRが要るのかを、周囲にどう伝えるか。

「ドキュメントがないと将来困る」では、人は動かない。
人は、未来の痛みより、今のコストに反応するからだ。
効くのは、自分の経験を語ることではなく、相手に小さく経験させることだ。
たとえば、会議でこう聞いてみる。
「3ヶ月前に、なぜこの仕様にしたか、誰か覚えてますか」。
誰も答えられない、その沈黙の数秒。
ADRの必要性は、どんな説明よりも、その沈黙のほうが強く伝える。
そして次にその沈黙が訪れたとき、書き始めるかどうかは、もう説得の問題ではなくなっている。