質問とコンテキスト
この質問では、重要な技術的トレードオフを、検索可能でレビュー可能、かつ進化可能なチームのナレッジに変えられるかを評価します。ADRが必要となるタイミング、却下された選択肢の記録方法、レコードがコードレビューやトラブルシューティングをどのようにサポートするか、そして新しい決定によって置き換えられた決定をどのように扱うかを網羅して回答してください。
このトピックはバックエンド、プラットフォーム、SRE、スタッフエンジニア、およびクロスファンクショナルな役割に適しています。チームにはリポジトリとレビュープロセスはあるものの、共通の決定レコードの規約がない状況を想定してください。選択には信頼性、セキュリティ、インターフェース、依存関係、または不可逆なコストのトレードオフが関わる可能性があります。
面接官が評価しているポイント
第1に、すべての実装詳細をドキュメント化するのではなく、アーキテクチャ上重要な決定を特定できるか。第2に、中立的なコンテキスト、制約、選択肢、結果を用いてその選択を説明できるか。第3に、ADRを Proposed、Reviewed、Accepted、Superseded などのライフサイクルに位置づけられるか。第4に、コードレビュー、オンボーディング、インシデント対応においてその記録を有用なものにできるかです。
確認すべき質問
- その決定は、システム構造、主要な品質属性、パブリックインターフェースに影響しますか、それとも局所的な実装のみに影響しますか？
- どのようなハード制約（レイテンシ、可用性、コンプライアンス、スキル、移行期間、コストなど）が適用されますか？
- その選択肢はすでにデプロイされていますか、それともADRはまだ Proposed の状態ですか？誰が承認または却下できますか？
- ADRはリポジトリ、ドキュメントシステム、またはその両方のどこで管理しますか？影響を受けるチームはどのように更新を把握しますか？
- トラフィック、障害率、コスト、規制の変更など、どのようなシグナルが再評価のトリガーになりますか？
30秒の回答フレームワーク
「まず、その選択がシステム構造、主要な品質属性、または変更が困難なインターフェースを変更するかどうかを確認します。該当する場合は、簡潔なADRを作成します。コンテキスト、制約、検討した選択肢、却下した代替案、決定内容、トレードオフ、リスク、ステータスを記録し、Proposed の間に影響を受けるチームでレビューします。承認後は変更不可の履歴として扱い、要件が変わった場合は後継となるADRを作成して古いレコードをリンクし、インデックスを更新します。レコードはアクセス可能なバージョン管理されたリポジトリで保持し、設計レビュー、コードレビュー、オンボーディング、トラブルシューティングで参照します。」
ステップごとの回答
ステップ1: 記録基準を設定する
選択がシステム構造、主要な品質属性、パブリックインターフェース、重要な依存関係、または不可逆なコストに影響を与える場合にADRを作成します。命名規約、単発のリファクタリング詳細、またはすでに明確な標準によって規定されている選択は、通常個別のレコードを必要としません。この基準により、ドキュメントのノイズを生み出すことなく、将来の判断に影響を与える決定を保持できます。
ステップ2: 問題を中立的に記述する
問題、ユーザーまたはビジネスへの影響、機能要件および非機能要件、期限、交渉の余地がない制約を記述します。コンテキストに都合の良い選択肢を潜り込ませたり、事実を『チームXが強く主張した』といった記述に置き換えたりしてはいけません。新しいコントリビューターが、なぜ今決定が必要なのかを理解できるようにすべきです。
ステップ3: 選択肢とトレードオフを比較する
実際に検討された選択肢を、却下された選択肢およびその却下理由を含めてリストアップします。レイテンシ、可用性、影響範囲、セキュリティ、移行コスト、運用負荷、チームのスキルを比較します。不確実な値がある場合は、前提条件と確信度を明記します。ADRは決定そのものに集中させ、詳細なスパイクや設計書は別途リンクします。
ステップ4: 決定内容と結果を明記する
『リージョンごとのキューを使用し、クロスリージョンのフェイルオーバーには手動承認を受け入れる』のように、単体で意味が通る決定を記述します。その上で、期待されるメリット、コスト、リスク、必要な統制、影響を受けるコンポーネントを記録します。『選択肢Aを採用する』だけでは不十分です。将来のレビュアーが理由や支払った代償を確認できないためです。
ステップ5: ステータス、オーナーシップ、レビューを設定する
Proposed、Accepted、Rejected、Deprecated、Superseded などの状態を使用します。オーナーを割り当て、Proposed の間に影響を受けるチームに閲覧とコメントを促します。承認時には日付、関係者、バージョンを追加します。レビューは事実、制約、選択肢、結果が明確であることを検証するものであり、全員が永続的に合意することを保証するものではありません。
ステップ6: ADRをエンジニアリングワークフローに組み込む
ADRをリポジトリまたはドキュメントシステムでバージョン管理し、検索可能なインデックスを維持します。設計レビューやコードレビューで承認済みの決定と矛盾する変更が見つかった場合は、ADRをリンクし、明示的な変更レコードの作成を求めます。オンボーディング、引き継ぎ、インシデント対応でもADRを活用して『なぜこの方法なのか』に答え、同じ議論の繰り返しを減らします。
ステップ7: 決定が変更されたら新しいレコードを追加する
承認済みまたは却下されたADRは不変（イミュータブル）として扱います。新しい証拠、スケール、コスト、規制によって結論が変わる場合は、新しいコンテキスト、過去の制約、新しいトレードオフを記述した新しいADRを作成します。承認されたら、古いレコードを Superseded とマークし、両方のレコードを相互リンクします。これにより、現在の決定を見つけやすくしつつ、過去の履歴を保持できます。
優れた回答例
「まず、システム構造、主要な品質属性、インターフェース、または不可逆なコストに影響するかどうかを確認します。単なる局所的な実装にすぎない場合は、ADRを追加しません。基準を満たす場合、問題のコンテキスト、ユーザー要件および非機能要件、制約、選択肢、却下した代替案、決定、トレードオフ、リスク、確信度を含む Proposed レコードを作成します。
レビュー議論の前に影響を受けるチームに読んでもらい、ステータス、オーナー、日付、関係者を記録します。承認後は、ADRを検索可能でバージョン管理されたリポジトリに保持し、設計レビュー、コードレビュー、オンボーディング、トラブルシューティングで参照します。完全な設計書を置き換えるのではなく、簡潔かつ事実に基づいた状態を保ちます。
要件や証拠が変わった場合、承認済みレコードを直接編集することはありません。古い決定が適さなくなった理由、新しい選択肢、およびその結果を説明する新しいADRを作成します。承認後に古いレコードを Superseded とマークして2つをリンクさせることで、チームが意思決定の経緯を失うことなく現在の選択を確認できるようにします。」
よくある間違い
- 完全な設計ガイドを書いてしまう → 決定が見つけにくくなる → コンテキスト、選択肢、決定、結果を簡潔に保ち、詳細はリンクする。
- 採用された選択肢のみを記録する → 後で同じ議論が繰り返される → 却下された選択肢と当時の制約を含める。
- 制約を個人の好みに置き換える → レコードの客観的なレビューができない → 中立的で観察可能な事実と前提条件を使用する。
- 承認済みのレコードをインプレースで編集する → 履歴が失われる → 新しいレコードを追加し、古いものに Superseded マークをつける。
- ステータスとオーナーを省略する → それが適用されているかどうかが誰にもわからない → ライフサイクル、オーナー、承認日を追跡する。
- ADRを一切参照しない → ドキュメントに運用の価値がなくなる → 設計レビュー、コードレビュー、オンボーディング、インシデント対応に結びつける。
フォローアップの質問と回答
フォローアップ1: メンバーの意見が一致していない場合でも、チームはADRを承認できますか？
はい。解決していない反対意見、リスク、および誰がその決定を承認できるかを記録します。レビューは選択とそのコストを可視化するためのものであり、永続的な満場一致を作り出すものではありません。根拠が不足している場合は、ADRを Proposed のままにして検証タスクをスケジュールします。
フォローアップ2: ADRを過去に遡って作成（バックフィル）すべきなのはどのような場合ですか？
既存の構造、インターフェース、または品質のトレードオフが重要であるにもかかわらず、誰もそれを説明できない場合にバックフィルします。コミット履歴、インシデントデータ、メンテナーへのインタビューを活用し、当時の事実と推測を混同しないよう遡及レコード（Retrospective）として明記します。
フォローアップ3: リポジトリとWikiのどちらを使うべきですか？
実装と一緒にレビューできるよう、影響を受けるコードの近くにあるバージョン管理されたリポジトリを優先します。ビジネスやセキュリティの関係者がより広いアクセスを必要とする場合は、情報の乖離を防ぐために単一の信頼できる情報源（Single Source of Truth）を保ちつつ、インデックスやサマリーをミラーリングします。
フォローアップ4: ADRの価値をどのように示しますか？
新メンバーが重要な選択を理解するまでの時間、繰り返される議論の頻度、レビューで見つかった承認済み決定への違反件数、インシデント対応者がコンテキストを見つけるまでのスピードを追跡します。メトリクスによって改善点が明らかになります。ドキュメントの数自体が目的ではありません。