ADR以外のドキュメントの利用や、ADR運用の注意点
内山氏は「全てのドキュメントをADRで代替するわけではありません」と話す。チームのワーキングアグリーメント、サービスのDesign Doc、Production Readiness Checklistなどの重要なドキュメントは、ADRと共存しながらも別途管理されている。内山氏のチームでは、ADRとワーキングアグリーメントは別に管理されており、基本方針やコードレビューの方針などが記録されている。ADRの利用は柔軟であり、チームやプロジェクトのニーズに合わせて異なる形で活用されている。
開発者は、サービスをプロダクションにリリースする際に、Production Readiness Checklistを用いてチェックを行う。このプロセスの一環として、コードを書く前にDesign Docを作成し、リリース前にProduction Readiness Checklistを埋めることが求められる。その場合、個々の意思決定の記録だけではなく、体系的に網羅された情報が必要となる。SREは、サービス特性を確認するためにADRよりもこれらのドキュメントをチェックすることが多い。
Design DocとProduction Readiness Checklistの運用について初期検討で意思決定が行われた際には、ADRを記録し、その上でDesign Docを網羅的に作成する。続く初期開発の段階で意思決定が行われた場合も同様にADRを記録し、Production Readiness Checklistを埋めていく。このプロセスを経て、プロダクションにリリースができた後、エンハンス開発での意思決定時にもADRを記録すると流れとなっている。
「スタディサプリ」には重厚長大なドキュメントもある。ADRが軽量で使い勝手がいいからといって、重厚なドキュメントが不要になるわけではない。例えば、技術的な挑戦を伴う設計を実施した場合、結果論的にアーキテクチャが形成され、意思決定が不明瞭になることがある。またプロダクトマネージャーやカスタマーサポートと協力する際には、網羅的な仕様を参照するシーンもある。加えて、機能が複雑化した結果、自然言語で網羅的にまとめなければならない資料もある。
内山氏はADR運用上のいくつかの課題も挙げた。目立つのは、意思決定を行った後にその内容をADRに記録し忘れるケースである。この問題に対処するために、承認済み以前のステータスを有効活用する方法が考えられる。具体的には、意思決定前の段階である下書き、提案済みのステータスのときから記述しておくのだ。
特定のADRを廃止扱いにすることも難しい。複数の意思決定が連続して行われる状況では、新しい意思決定が以前のものを覆すことがあるからだ。ADRのシンプルなテキストベースの記録形式では、過去のADRとの関連性を把握するのも難しい。ADRの適切な管理方法には今後も継続した試行錯誤が必要とされる。
現在、「スタディサプリ」の開発チームは、「意思決定をしたら、ADRを書かなければ」という意識を共有している。アジャイルな開発では、各工程でのドキュメントの明確な位置付けがなされないことが多いが、このような開発環境での意思決定の記録は重要である。
ADRは「スタディサプリ」の開発チームにマッチしたと言えるが、カスタマイズの余地と軽量さによるスモールスタートの容易さがあるためほかの開発現場でも活用できるだろう。内山氏は、ADRが全てのドキュメントを代替するわけではないため、個々の意思決定のイベントのスナップショットとしての役割に留意する必要があるとし、最後に次のようにコメントした。
「アーキテクチャは、意思決定というイベントが積み重なって形成されるものと考えています。意思決定の記録のハードルを下げることは、アーキテクチャを構築する際のハードルを下げることに直結すると信じています。アーキテクチャ構築において、ADRが少しでもお役に立てることを願っています」
