■ 1. Any Decision Recordとは
- 一般的なADRとAnyの違い:
- 一般的なADRはArchitecture Decision Recordの略で、アーキテクチャに関する意思決定を記録するドキュメント
- なぜこの技術を選んだか、なぜこの構成にしたかを、決定時のコンテキストとともに残す
- Dress CodeではAをAnyと読み替え、領域や大小を問わずあらゆる意思決定を記録する文化として運用
- 記録対象の範囲:
- アーキテクチャ選定に加え、開発プロセスの変更やツール選定、命名方針も記録対象
- この機能をやらないと決めた理由まで幅広く記録する
■ 2. Anyにした理由
- 意思決定は再構築のための事実:
- システムをデータ、コード、アーキテクチャの3層に分け、各層に守るべき源泉があると考える
- データ層の源泉はイベント、手段はEvent Sourcing
- コード層の源泉は仕様、手段はSDD(仕様駆動開発)
- アーキテクチャ層の源泉は意思決定、手段はADR
- データ層ではEvent Sourcingで状態でなく変化を記録し、状態はイベントから再生成できる派生物とみなす
- コード層ではOpenSpecを用いてSDDを導入し、仕様を源泉としてコードを書く・生成する
- 同じ原則をアーキテクチャ層に適用すると、現在のアーキテクチャ自体は派生物であり、守るべき源泉はなぜそう作ったかという意思決定
- 意思決定が失われると、現状の構成は動いているから触れないブラックボックスになっていく
- ADRからSDD、実装へと上流の事実が実装の根拠になる流れを目指している
- 機械的に再生成できるわけではないが、この流れがつながれば意思決定から作り直すことが現実的になる
- アーキテクチャ限定というバイアスの排除:
- アーキテクチャの意思決定を書くものと定義すると、設計以外の開発判断の置き場がなくなる
- これはADRに書くほどのことかというバイアスが働き、迷った意思決定が記録されずに消えてしまう
- フォーマットが形式的になりすぎ、読み書きのハードルが上がる問題もあった
- 対応として、設計以外の開発に関することも含め、あえて雑多に何でも書くことにした
- ちゃんとしたADRを書こうとする負担を減らし、品質より記録の網羅性を優先する割り切り
- 創業初期からの資産化:
- ドキュメント運用でよくある悩み:
- 探せない
- バラバラ
- 読まれない
- 残らない
- 更新されない
- 時間がかかる
- 組織が大きくなってから直すのは困難なため、初期のうちにフォーマットと置き場を統一し文化として定着させることにした
- 創業期のなぜが後から引けること自体が組織の資産になるという考え
■ 3. 運用方法
- Notionへの集約:
- ADRはすべてNotionのデータベースに集約し、分類やフォルダ整理は行わない
- 探索はNotion AIに任せる前提で、人間が探しやすい構造を維持するコストより書き溜めることを優先
- 実際のADRの作り:
- 判断当時の文脈と結論さえ書けば成立する、意図的にゆるいフォーマット
- 雑多さが伝わる例:
- Event Outbox共通基盤に関する検討
- Compute Savings Plan導入検討
- Zod v4アップグレード影響調査レポート
- レビューの心得
- アーキテクチャの検討からAWSのコスト削減、ライブラリアップグレードの調査、組織寄りの話まで対象領域が雑多
- レビューの心得というADRの内容:
- コードレビューに対するチームのマインドセットを言語化したもの
- Approveはバグがないことの保証ではなく、一緒に対応するという意思表示だという合意
- 依頼する側が意図や背景、自信のない箇所を添えてレビュワーの負荷を下げるという合意
- こうした決めごとは口頭やSlackだと流れてしまうため、Anyの枠があるからこそ残せた例
- 採用状況のプロパティには採用だけでなく不採用、保留もあり、やらないと決めたことも記録する
- 不採用の理由も口頭では失われるため、できる限り残すようにしている
- 記録量の推移:
- 約1年半で累計450本を超えた(2026年7月時点)
- 現在のチーム規模はエンジニア15人、PdM・デザイナー6人
- 記録ペースの推移:
- 導入から1年ほどは月に数本
- 2025年半ばに月10本台に到達
- 直近3ヶ月は月50〜60本ペースまで増加
- 文化として回り始めるまでに1年以上かかった
- ペース向上の背景には、ADRからSDD、実装という流れの定着とADR文化自体の浸透がある
- 週次の共有とフィードバック:
- 書き溜めたADRは週次の読み合わせで共有しフィードバックし合う
- 共有がないことを異常とみなし、共有ゼロは意思決定がなかったのではなく記録されなかっただけと考える
- 書かなかった人を責める目的ではなく、記録の取りこぼしを検知するシグナルとして使う
- 書くきっかけの仕組み化:
- 意思決定した瞬間にADRを書くのは難しいため、Slackで気になる話題にスタンプを押してストックする運用
- ストックした話題を雑多に書き貯め、週次で話し合う導線を作っている
- このストックから起票されたADRはデータベース上で分かるようにしている
- 現在はこの仕組みがなくてもメンバーが書いてくれるため、以前ほど重宝していない
- LLMによる読み書きの負荷軽減:
- 書く側は議事録や文書をAIで要約し、ADRの下書きにしている
- 読む側はAIへの質問で必要な意思決定を引き出し、開発時にコンテキストとして共有することもある
- 最近はADRの要約を画像生成AIでグラフィックレコーディング風の1枚画像にまとめる運用もテンプレートに組み込んだ
- 雑多に書いてもAIが探して要約してくれるという前提が、Anyという割り切りを成立させている
■ 4. 得られた効果
- なぜそうなったかが後から追える:
- コードや構成の経緯が分からなくなったとき、当時の意思決定に立ち返れる
- 考古学的な調査ではなくエンジニアリングができる状態を保てている
- 開発タスク側からADRが寄ってくる:
- バックログのタスクページのテンプレートに関連ADRピックアップというセクションを設けている
- Notion AIがタスク内容から関連しそうな過去のADRを自動で引っ張ってくる仕組み
- 書いた当時は誰が読むのかと思っていたADRが後で役立つこともある
- オンボーディングの質問がNotion AIで片付く:
- 新メンバーからのなぜこうなっているのかという質問の多くがNotion AIへの質問で解決するようになった
- 意思決定がすべて残っているため、AIがそれを引いて回答できる
- AIが古いADRを引いてしまうリスクはあるが、答えの源泉がまったく残っていない状態よりは改善している
■ 5. 残っている課題
- 更新されない問題:
- 最終更新からの経過日数を可視化して放置を検知しているが、古いADRを直すモチベーションは生まれにくい
- ADRは本来immutableな時点記録で、変更は新しいADRで置き換えるのが定石
- 置き換えのADRを書くモチベーション自体も生まれにくく、問題の根は同じ
- 境界の曖昧さ:
- Anyにしたことで、ある仕様をADRに書くかBacklogに書くか迷う場面が生じている
- 書いた人が報われにくい:
- ADRの恩恵を受けるのは未来の誰かであり、書いた本人への短期的なリターンが見えにくい
- 評価や称賛の仕組みとセットで考える必要があり、引き続き試行錯誤中
■ 6. おわりに
- 意思決定を再構築に必要な事実と捉え、アーキテクチャに限らずすべて(Any)残すという考え方
- これによってAI時代に変更し続けられるシステムと、知識が資産になる組織を目指している
- イベントを残す、仕様を残す、意思決定を残すというレイヤーの違いはあっても、事実を源泉として守るという原則は共通している