ADRの効率的な使い方とは
「スタディサプリ」では、マイクロサービス化が進展し、現在はCTOやリードアーキテクトがいないため、チームが個々のサービスについての意思決定を裁量で行うことが多い。チームが裁量を持つことで、ADRの使い方にも特色が現れている。使い方にはチームごとの特色があり、ADRを利用しないチームもある。言い換えれば、ADRはチームごとにカスタマイズ可能なドキュメンテーション手法と言える。内山氏はいくつかの使い方を説明した。
1つのissueに複数の意思決定を書き連ねる場合、情報が散逸しないメリットがある。一方、1つのissueに1つのADRというシンプルな方法もあり、その場合はGitHubの機能を使ってADRラベルを付与することで情報の散逸を防いでいる。例えば、マイクロサービスのシステム名やプロジェクト名が入ったissueに、関連するADRを集約するような使い方がされている。
1つのissueに1つのADRという手法の場合、各タイトルは具体的な意思決定の内容を反映している。例えば、「AWSコスト最適化活動」や「■■の分割統治とIngressへの移行」、「MagicPodとAutifyの住み分け」といった具体的なADRがあり、これらに対応するissueが起こされている。意思決定を明確にすることで議論がしやすくなる利点がある。
ADRのテンプレートフォーマットを用いずに、意思決定した事柄の実内容のみを記述する場合もある。必要最低限の内容を記録することで、意思決定を記録する際のハードルを下げる効果があると考えられる。
ADRの「A（アーキテクチャ）」にこだわらない場合もある。例えば、チームの編成方針や自動生成コードのレビューに関する決め事など、組織やチームの開発フローに関する意思決定をADRとして記録することもあるのだ。「ADRというツールを通じて、チーム内で意思決定した内容を記録する文化が内面化した結果と言えます」（内山氏）。
また、新人のオンボーディングにADRを利用する場合もある。新人に対し、特定のシステムやエリアに関するADRを読むことを推奨し、「なぜこの設計なのか」「どうしてこのサービスを使っているのか」といった疑問を明らかにしているのだ。
そのほか、エンジニアリングマネージャーにとって、ADRの存在はチームメンバーが開発するシステムの動向を追いやすくする効果があるとの声も聞かれた。その一方で、プロダクトマネージャーからは、ADRにあまり関心を示さない声が多く聞かれた。これは、アーキテクチャ上の意思決定は、開発者以外の振る舞いに影響を及ぼさないためだ。
