新卒1年目こそADRを書いたほうが良いと思った話

ADRの概要

ADRはアーキテクチャ・ディシジョン・レコードの略で設計に関する意思決定を軽量なドキュメントで残していくものです。DesignDocというのもありますが、DesignDocは全体の設計を表し、時間軸は今を表しています。一方、ADRは部分的な意思決定を表しており、時間軸は意思決定をした時です。そのため、ADRは意思決定のスナップショットとして認識すると良いと思います。

ADRのメリット

過去に行った議論を再度行うことが無くなる

ADRには意思決定の内容と理由を記載しており、理由には他の案とメリット・デメリットなどを記載しています。そのため、過去に議論したことを蒸し返すことがありません。

認識を統一した状態で開発を最後まで進められる

意思決定を記録した状態で実装に入るため、途中で方針を忘れたとしてもADRを見直せば思い出すことが可能です。

ADRがチームに与えた影響

議論した内容をその場で残すという文化が浸透

実装する前にチームで設計方針や実装の懸念点などを議論します。 その時に「この話はADRとして残しましょう」というような会話が生まれるようになりました。

新卒1年目の僕がADRを書いて良かったと思ったこと

決定した設計方針に対してより深い理解を得られた

ADRを作成し先輩に確認してもらったところ、「この意思決定は現在のプロダクトの設計で~のようなことがあるから〇〇とした。」と書いた方が良いなどのアドバイスを貰いました。 ADRは部分的な意思決定ですが意思決定の理由はプロダクト全体の設計が関わることがあります。 また、設計方針の考え方として 「理想の定義」→「現状の設計を整理」→「設計案（複数）を考える」→「判断する軸を整理」→「方針を決定」 の順番で考えると良いことを教えていただきました。特に設計の議論においては理想の認識を合わせておくことが重要です。ADRを書いたことで、先輩の考え方を言語化して理解する機会にもなりました。

まとめ

チームにADRを導入したことで開発が進めやすくなったと思います。また、個人としてもADRを書いたことで設計の知識を深めることが出来たと思いました。ADRが生まれる機会を見つけたら積極的に手を上げて書いていきたいと思います。

ADRの参考

https://docs.cloud.google.com/architecture/architecture-decision-records?hl=ja https://github.com/joelparkerhenderson/architecture-decision-record https://blog.studysapuri.jp/entry/architecture_decision_records#f-f0e70d32 https://user-first.ikyu.co.jp/entry/2023/12/13/115112