ADR を1年間書いてみた感想 - 一休.com Developers Blog

宿泊開発チームでエンジニアをしている @kosuke1012 です。チームで ADR を書き始めて1年くらい経ったので、その感想を書いてみたいと思います。 この記事は 一休.comのカレンダー | Advent Calendar 2023 - Qiita の13日目の記事です。 ADRとは アーキテクチャ・ディシジョン・レコードの略で、アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録していくものです。 出典はこちらで、 Documenting Architecture Decisions わかりやすい和訳は以下の記事が、 アーキテクチャ決定レコードの概要 | Cloud アーキテクチャ センター | Google Cloud アーキテクチャ・デシジョン・レコードの勧め | 豆蔵デベロッパーサイト アーキテクチャの「なぜ？」を記録する！ADRってなんぞや？ #設計 -

[PrivateIntMain]

設変に至る経緯を残しておくと過去にやらかした轍を踏みにくくなるし、逆に過去に却下されたけど状況が変わった今ならできるんじゃねぇのなど議論の端緒にもなってよさげ。物量が気になるが読めぬよりはよいか。

[kentana20]

ADRによって仕様や設計の意思決定を残せる / 残す癖がついてとてもよいです。

[peketamin]

すげえ。議論が蒸し返らないのいいな。これが世の中のイニシャルバージョンのプロダクトの全てにあればいいなあ。特に行政案件みたいな受託者がコロコロ変わるヤツ。

[yarumato]

“ Architecture Decision Record。アーキテクチャに関する意思決定を軽量なテキストドキュメントで記録。どうしてこの仕様になったかを後から知ることができる。議論が蒸し返らない。意思決定するべきことが明確になる”

[snsn9pan]

技術資料まとめ方フォーマット参考になる

[progrhyme]

良い取り組みだと思う。SCQA知らなかった

[diveintounlimit]

書いたほうが良いのは同意だが、一つ言いたいこととして。議論が蒸し返されないとずっと当時の思考のまま5年、10年と悪い意味でkeepされてしまうので、時には蒸し返すことも重要だよ。

[kiririmode]

ADRの習慣化うまく行った試しがないけど記事を読んで否決/可決されるものを書くのではなく、SCQを埋めることで議論を効率化しAを導いて記録するという考え方であれば習慣化するのではないかと思った

[toyoshi]

以前は「書くはいいけど後からみるか？」というのがあったけど今後はAIに「なぜこういう実装なの？」みたいな質問が全体にできるだろうからADRとかデザインDocの有用性が高まりそう。