〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録 - スタディサプリ Product Team Blog

こんにちは。スタディサプリのWeb開発をやっている@highwideです。 今日は、自分の所属する"コーチングチーム"(個別指導コースや合格特訓コースの機能開発を行っています)が、最近のプロジェクトで利用した「アーキテクチャ・デシジョン・レコード」、通称「ADR」について紹介したいと思います。 アーキテクチャ・デシジョン・レコード(ADR)とは 「ADR」「アーキテクチャ・デシジョン・レコード」という概念を知ったのは、社内で行っていた「Design It! プログラマーのためのアーキテクティング入門」(以後「Design It!」)の読書会でのことでした。 www.oreilly.co.jp 最初にそのキーワードが登場する「11.2.3 必要なときだけ形式的な記述に投資する」では、「"膨大な量のドキュメントになる傾向"がある形式的なドキュメンテーション」に対比して、以下のように紹介されます

[fog-og-frog2]

ADRいいよね。必ずしも打ち合わせの場を設けずGitHubやSlackのスレッド上で議論して一気に決めちゃうケースも多いから議事録があるとは限らないし、仕様書は仕様書で没案は文書の対象として乗ってこないし、嵌ったなー感

[pascal256]

ADRはまだ粒度が掴めてないのよなー。仕様書と議事録の間くらいとイメージしているが。

[hi-hats]

ADR採用するとこがここ1年くらいで増えてきたのを定期的に実感している 自分も記事書こうかな

[nagais]

“〜その意思決定を刻め〜「アーキテクチャ・デシジョン・レコード(ADR)」を利用した設計の記録”

[for-my-internet-demo]

タスク管理系で話すると消えがちなので、このくらいの温度感で残すのいいかも

[sezemi]

議事録からADRを書いておく、ということかな

[soachr]

なるほどな...うちはアジャイルの枠を使ったWFに近いから結局工程ごとの成果物をしっかり作り切ることをしていたけど、こういう中間に位置するドキュメントもありなのか

[letsspeak]

既存で動いてるやつはコード見りゃ分かるし仕様書通りかは分かるんだけれど、設計思想・方針が残ってないことがとても多いのよねえ

[endok]

良さげ。Design it読もうかなー。

[yigarashi]

慣れないコードベースでも一貫性のあるコードを書きたいのだけど、色々な部分を読んで雰囲気から察するという力技しか知らずに苦労してるのですごく良さそう。

[ohbarye]

“プロジェクトが終わるまで、1つのissueのコメントに設計判断を書き連ねていく” "フレームワークを内面化できたことで文化形成に繋がった"

[kachick]

ADRは本当に体験良かったので今後も新機能開発時には活用していきたい！