Spotifyのいくつかのチームは、アーキテクチャ決定レコード（ADR）を使用して、彼らが下した決定を記録する。ADRはSpotifyに多くのメリットをもたらした。たとえば、新しい開発者向けの新人研修の改善、組織の変更によるプロジェクトの所有を引き継ぐ際のアジリティの向上、ベストプラクティスに関するチーム間の連携の改善などである。
Architectural Decision（AD）は、アーキテクチャ上重要な機能要件または非機能要件に対処するソフトウェア設計の選択肢です。
アーキテクチャ決定レコードは、常に進化する性質のため、アジャイルのコンテキストでよく使用される手法である。アジャイルの専門家であるMichael Nygard氏が次のように書いている。
アジャイルプロジェクトのアーキテクチャは、異なる方法で記述および定義する必要があります。すべての決定が一度に行われるわけではなく、プロジェクトの開始時にすべての決定が行われるわけでもありません。
アーキテクチャの決定レコードには、特定の決定に至った背景とその結果を理解するための情報が含まれる。さらに、行われなかった決定とその理由を文書化することもできる。
SpotifyのエンジニアであるJosef Blake氏は、決定がプロジェクトに大きな影響を与えるときを理解する方法は複数あるため、ADRを作成する時期を決定することは必ずしも容易ではないと述べている。彼の経験では、考えるまでもなくADRを作成すべきシナリオが少なくとも3つある。
最初に、文書化されていない過去の決定を取り込むためにADRを記述する。これにより、決定が存在することが誰にとっても明らかになる。
同様に、決定が下されたが記録されなかった場合、それを標準にできますか。文書化されていない決定を特定する1つの方法は、Peer Review中にあります。競合するコードパターンまたはライブラリの導入のときに、レビュー担当者は文書化されていない決定を発見する可能性があります。
多くの場合、ADRの作成は、システムに大きな影響を与える変更（APIを壊すような変更など）を行うプロセスの最後のステップである。この場合、Spotifyのエンジニアは、すべての利害関係者が共通のアプローチで同意する手段として、request for comments (RFC)を作成するために使用する。RFCプロセスが完了すると、合意されたソリューションがADRに取り込まれる。
ただし、ADRは大きな影響を与える決定のみのために作成されるべきではないとBlake氏は述べている。
文書化されていない決定のコストを測定することは困難です。しかし、通常、影響としては、重複作業（他のエンジニアが同じ問題を解決しようとする）または競合するソリューション（同じことを行う2つのサードパーティライブラリ）があります。
このような場合、ADRを作成すると、特に複雑にならないという利点がある。
アーキテクチャ決定レコードは決して新しい技術ではない。特に、軽量の意思決定レコードは数年間、ThoughtWorksテクノロジーレーダー上にあった。試してみたい場合は、このリポジトリで追加情報やすぐに使えるテンプレートを見つけることができる。