ADRの始まりや各社事例を整理しておきたいのでまとめる
Architecture Decision Records(ADR)とは
ADRについて記述されているadr.github.ioでは下記のように書かれている。
アーキテクチャ上の決定（Architectural Decision:AD）はアーキテクチャ上重要な機能的または非機能的要件に対応する、正当な設計上の選択である。アーキテクチャ上の重要な要件(Architecturally Significant Requirements:ASR)はソフトウェアおよびハードウェアシステムのアーキテクチャと品質に測定可能な影響を与える要件である。ADR（Architectural Decision Record）は、1つのADとその根拠を記録するもので、プロジェクトで作成・維持されるADRの集合は、その決定ログを構成する。これらはすべてアーキテクチャナレッジマネジメント（Architectural Knowledge Management:AKM）のトピックに含まれるが、ADRの使用は設計やその他の決定（「あらゆる決定記録」）に拡張できる。
上記のように「アーキテクチャ上の決定に関して根拠を記録するもの」として紹介されている。また呼び方にはブレがあるが上記サイトでは Architectural Decision に連動して Architectural Decision Record と呼ばれているが意味合いとしては同じ様子。
提唱されたブログ
書籍「ソフトウェアアーキテクチャの基礎」によるとMichael Nygard氏が「Documenting Architecture Decisions」にて提唱した方法論がはじまりとされています。
このPostそのものがADRのフォーマットを体現した状態での内容になっている。提唱されているフォーマットは以下の5つの要素を持つ.
- Title（タイトル）
- Context（コンテキスト）
- Decision（決定）
- Status（ステータス）
- Consequences（結果/影響）
各要素と記述内容は以下
| 要素名 | 意味 |
|---|---|
| Title（タイトル） | 決定に対してのタイトル、例では「ADR:Ruby on Rails3.0.10へのデプロイ」など通し番号とドキュメントの端的な説明の文となっている |
| Context（コンテキスト） | この決定に関しての前提となる事実など、決定に作用している予備情報を記述する |
| Decision（決定） | 具体的に決定した内容を記述する。能動態の文章とするべきで「私達は◯◯します」と記述する。 |
| Status（ステータス） | このADR文章自体の取り扱い状況について記述する。例では「提案」「承認」「非推奨」「置換」の4つを持つ。「提案」がされ、合意形成がなされて同意を得られた場合は「承認」となり、その後別のADRに取ってかわわれた場合は廃止を意味する「非推奨」や他のADRに置き換えられた旨の「置換」のいずれかになる。 |
| Consequences（結果/影響） | この決定を適用したあとに対する結果や影響を記述する。例ではポジティブなものもネガティブなものも含めて結果を記述することが望まれている。 |
参考リンク
各社原典の内容を基軸にアレンジが加えられて運用がされている。事例なども含めてリンクをまとめる。
ADRそのものについて
- アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud
- アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト
- 意思決定を記録するArchitecture Decision Record (ADR)の話 - NIFTY engineering
- アーキテクチャディシジョンレコード(ADR) | Wantedly Engineering Handbook
- ADR – アーキテクチャ上の設計判断を記録しよう｜技術ブログ｜北海道札幌市・宮城県仙台市のVR・ゲーム・システム開発 インフィニットループ
