チームでADRを書くようになってしばらく経つので個人的に振り返ってみる

今自分が関わっているプロジェクトあたりからADRを書き始めて、それ以外のことでもいくつかADRが書かれたりしている。
まだそんなに長く運用したわけではないけど、ここら辺で一回振り返って所感を残しておこうと思う。

現状のADRの運用方針

現状は詳細さや丁寧さよりも、まず書くことを重視している。テンプレ的なのもあるけど、中身を全部埋めていなくともOK。
何かしらの意思決定や変更、導入などがあった際には、その背景や判断基準を残しておいて、状況が変わった際に適切に振り返っていけるようにするためだ。

嬉しいこと

それまでは「メリットあるし、何となくこれが良いだろう」くらいのノリでやってた変更も、ADRを書くことでデメリットを挙げたり、他の選択肢にならなかった理由や判断軸をしっかり考えることになる。
技術的な選択における「何となく」は未来の技術的負債になりえるので、それを排除したりあるいは意図的に技術的負債を積んだりできるようになる。

また、自分たちの意思決定において、メリットだけじゃなくどういうデメリットを受容してきたかを把握しておくことで、その後の他の意思決定時にも一貫性を持たせたりできるのは有難い。

悩ましい部分

アーキテクチャそのものだけじゃなく運用に関する部分、例えばIAMの設計やコンテナイメージのタグの命名規則なども、まずはADRとして書いて比較検討する感じにしている。
この時に決定した内容を改めてポリシーやルール的なドキュメントとして書き直すのが面倒だったりする。

ぶっちゃけADR側を参照すれば良いので今のところそうしているのだけど、それらとは別にリリースポリシーとかその手のドキュメントは存在するので、この辺りは足並みそろえるというか、ADR自体の運用をもう少し最適化させたい部分だなあと思う。

今後意識したいところ

何よりも意識したいのは、書くことが目的にならないようにすること。「迷ったらとりあえず書こうぜ」的なノリではあるものの、とりあえず書けばいいものでもない。
特に大事なのはその決定をした判断軸や理由の部分。決まった結果どうなったかはその後コードに反映されたりするだろうから見たらわかるけど、なぜどういう理由でこうしたのかは結果からはわからない。
どうしてADRを書くのか、それによって何を得たいのかは常に意識しながら運用していきたい所存。