決めごとの記録i-Willink
意思決定はADRで残す——61本書いて分かったこと
社長1名とAIで回す会社が、方針転換や承認の決め方を「なぜ決めたか」まで1枚ずつ残してきた記録です。61本のADRのうち、承認基準を3回作り直した実例と、続けるための書き方の決めごとをまとめます。
決めた結論だけでなく、捨てた選択肢と理由まで1枚に残すと、半年後に前提を点検して決め直せます。私たちはこれをADRという型で61本続けています。
小さな会社でいちばん失われやすいのは、お金でも時間でもなく「なぜそう決めたのか」という記憶です。会議も議事録もないので身軽ですが、半年後に同じ論点が出てきたとき、前に考えたはずの理由が思い出せません。
私たちは社長1名と、実務の多くを担うAI（Claude Code）で会社を回しています。AIは会話をまたいで記憶を持ち越せないので、理由が書いていない決定は、次の作業のときには存在しないのと同じです。そこで、後から効いてくる決定はADRという型で1枚ずつ残してきました。この記事は、その61本から分かったことの記録です。
この記事の要点
- 1ADRは1つの決定を「背景・選択肢・決定・理由・影響」で1枚に残す型。設計だけでなく事業や承認の決め方にも使える
- 2効くのは結論より理由の部分。前提が崩れたら、古いADRを消さずに新しいADRで決め直す
- 3全部は残さない。「半年後に『なぜ』と聞かれて詰まりそうか」で選び、書く手間はコマンド1つで消す
ADRとは「なぜ決めたか」を残す1枚
ADRは1つの決定につき、背景・選択肢・決定・理由・影響を1枚に書く軽い記録の型です。
ADR（Architecture Decision Record）は、もともとソフトウェアの設計判断を残すために広まった書式です。1つの決定につき1枚。仰々しい設計書ではなく、後から読んで「あのとき何を考えていたか」を復元できれば十分です。書式は、実践者がまとめたテンプレート集を見れば迷いません。
私たちはこれを設計の外にも広げました。61本の中身は、使う技術の選定のような設計判断もありますが、多くは事業や運営の決定です。たとえば次のようなものです。
- 作っていた SaaS の外販をやめ、オープンソースとして公開する方へ切り替えた決定
- 売上の目標を現実的な水準に引き直した決定
- AIの自動作業を「何回回したか」でなく「状態がそろったか」で止めるようにした決定
- 社長が承認する対象を「外に出るもの」だけに絞った決定
どれも、そのとき何を捨てて何を選んだかを1枚に残しています。
結論だけ残すと、半年後に決め直せない
理由が書いていないと、過去の決定は動かせない前提になります。理由があれば、前提がまだ生きているかを点検できます。
「SaaSの外販はやめる」とだけ書いてあると、数か月後の自分はこう思います。なぜやめたんだっけ、今ならいけるのでは。そこからまたゼロで考え直すことになります。
捨てた選択肢と、捨てた理由が一緒に残っていれば、見るべきは差分だけです。「あのとき見送った前提は、今も変わっていないか」。変わっていなければ結論はそのまま、変わっていれば新しいADRで決め直します。古いADRは消しません。なぜその判断が古びたのか自体が、次の判断の材料になるからです。
AIと働く場合、この効き方はさらに大きくなります。AIは過去の会話を覚えていないので、決定の理由を毎回ファイルから読みます。理由が書いてあれば、AIは条文の字面でなく考え方の出どころに立ち返って、「これは自分で進めてよいか、社長に聞くべきか」を判断できます。
実例: 承認の決め方を3回作り直した
承認の基準は、6月・10月・11月の3本のADRで作り直しました。毎回、前のADRの前提を点検してから上書きしています。
いちばん効いたのは、社長の承認をどこで求めるかの決定です。3本のADRが順に積み重なっています。
- 6月（ADR-015）: 最初の基準は「重要そう・技術的に重いものは社長承認、迷ったら承認」でした。運用すると、元に戻せる社内作業まで承認待ちに積み上がりました。そこで判定の軸を「元に戻せるか・社外に届くか・お金や法律が絡むか」の3つに張り替えました。
- 10月（ADR-058）: 社長の時間が週1回の判断にほぼ限られることになり、定型の配信や投稿は「この種類なら毎回聞かなくてよい」とまとめて承認する形を足しました。
- 11月（ADR-061）: それでも社内だけで完結する変更が社長の承認待ちで止まっていました。1週間で作った63本の変更のうち18本が止まったままだったことを数えたうえで、原因を5つに分け、社長が承認するのは「外に出るもの」だけと決め直しました。
3回とも、前のADRを読み返して「当時の前提は何だったか」を確かめてから書いています。特に11月の見直しでは、10月のADRで「顧客のリポジトリでは、マージは社長」と書いたはずの一文が、別の文書へ写されるうちに「マージは社長」と対象の抜けた全社ルールになっていたことが見つかりました。理由まで残していたから、どこで意味がずれたかを1行単位でたどれたのです。承認の決め方そのものは、承認は「元に戻せるか」で決めるに詳しく書いています。
失敗から引き出したルールも1枚にする
恥ずかしい失敗ほど、何を禁じて代わりに何で判断するかまで残します。同じ誘惑が来たときに立ち止まれます。
もう1本よく効いているのが、「作業が終わったかどうかをAIの自己申告で判断しない」と決めたADRです。きっかけは実験でした。AIは目標の9割を達成したと申告しましたが、機械で測り直すと実際は55.9%でした。
このADRには、禁じることだけでなく、代わりに何で判断するか（テストや数値の検査が通ったかどうか）まで書きました。だから今も、AIに作業を任せるときは「終わりの判定を機械に置いたか」を最初に確かめます。経緯はAIの「できました」は機械で確かめるにまとめています。
記録の側の失敗も残しています。ある決定は、決めた日に要約の一覧には書いたものの、1枚のADRとしては作り忘れていました。3日後、記録の抜けを点検する検査で見つかり、一覧を指す短いADRを後から足しています。人の記憶に頼らず、抜けは機械に見つけさせる。これもADRを続けるうちに身についた型です。
続けるための決めごと
書く手間はコマンド1つで消し、残す決定は「半年後に理由を聞かれて詰まるか」で選び、刻々と変わる値は書き込みません。
良い習慣も、面倒だと続きません。私たちが61本続けられたのは、次の3つを決めているからです。
- 書く手間を消す: 背景・選択肢・決定・理由という同じ骨格を、決まったコマンド1つで書き起こせるようにしています。毎回書式を思い出さなくてよいので、「これは残すべきか」の判断だけに集中できます。下書きはAIが書き、社長が読んで採るか決めます。
- 残すものを選ぶ: 元に戻せて影響の小さい決定は、いちいち残しません。目安は「半年後に『なぜこうした』と聞かれて、答えに詰まりそうか」です。
- 変わる値を書かない: 版の番号、期日、残りの数のような刻々と変わる値は、ADRに書き込みません。書くと現実とすぐずれ、読んだAIが古い数字を信じて誤った報告をします。ADRは考え方と決定を残す場所で、今の状態は毎回、実物を測って確かめます。
よくある質問
ADRは何から書き始めればよいですか？
次に「効いてくる決定」をしたとき、結論の下に「捨てた選択肢」と「その理由」を3行足すところからで十分です。書式は公開されているテンプレート集を1つ選べば迷いません。
議事録や日報と何が違いますか？
議事録は話した順の記録で、日報はその日の作業の記録です。ADRは1つの決定だけを、理由と捨てた選択肢つきで1枚に残します。後から「なぜ」を引くための記録です。
決定を変えたくなったら、古いADRを書き換えますか？
書き換えずに新しいADRを足し、古い方には「どのADRで決め直したか」を書きます。古い前提がなぜ崩れたかが、次の判断の材料になるからです。
AIに書かせても大丈夫ですか？
下書きはAIに任せられます。ただし採るかどうかは人が決め、理由の欄に書かれた前提が事実かは、元の数字や記録に当たって確かめてから採ります。
参考・出典
- Architecture decision record (ADR)（GitHub・joelparkerhenderson）（ADRの考え方と、実践者がまとめたテンプレート集）
- ai-coo-starter（GitHub）（私たちが公開している運営の雛形。ADRの書式と記録用のコマンドを含む）