アーキテクチャ・デシジョン・レコード（ADR）とは？
内山氏は現在、小学生／中学生／高校生向け学習サービス「スタディサプリ」のWebプラットフォーム開発を担当している。Ruby on Rails、React、GraphQL、node.js、Goなどを扱うWebエンジニアである。内山氏はまず、アーキテクチャ・デシジョン・レコード（ADR）とは何かを説明した。
ADRは、テキストベースの軽量なテンプレートを使用して、アーキテクチャ上の設計判断を記録するドキュメント形式である。通常、Markdownなどの形式で書かれ、タイトル、コンテキスト、ステータス、影響などのフォーマットで構成される。ステータスに関しては、チームに提案した後に「提案済み」にし、チームの合意を得たら「承認済み」に変更、有効ではないと判断した際には「廃止」とする。一つの意思決定に対して一つのADRを作成することが特徴である。
内山氏によると、ADRは2011年にMichael Nygard氏がブログで紹介したところから広まっていったと言われ、テクノロジーリーダーであるThoughtWorks社のMartin Fowlerは、新技術の評価集においてADRの採用を評価している。ADRを支援するCLIツールも存在し、GitHubには関連するリポジトリがあり、その人気を示すように4000ほどのスターが集まっている。ADRは広く使われている手法なのだ。
「スタディサプリ」開発チームメンバーは、社内で行われた『Design It!』（O'Reilly Japan）の読書会を通じてADRの存在を知り、その後、複数のプロジェクトでの活用が提案され、実際にADRを使用することになった。内山氏はRuby on Railsで書かれたモノリスシステムからGoによるマイクロサービスへの移行プロジェクトにおいてADRを採用した経緯を「スタディサプリ」のプロダクトチームブログに記したことが今回の登壇につながった。
このプロジェクトでは、設計決定が十分に記録されておらず、なぜそのような決定がなされたのかが、後から明確でない状況に気づいた。そこで、GitHubのissueコメントに意思決定のADRを記すことにした。その結果、プロジェクト全体の意思決定が散逸しなくなり、何を記録すべきかも明確になった。
また、全ての会議の議事録や網羅的な設計ドキュメントを書くのは現実的ではないため、チームでの意思決定後にADRに記録することにした。これにより、意思決定をカジュアルに記録する文化が形成され、ADRに関するコミュニケーションが自然となった。内山氏は「チームメンバーから議論の経緯を忘れがちだったのでADRの登場は革命だったという声が実際にあがっています」と語った。
