私のプロジェクトでは Architecture Decision Record (以降 ADR と記載) を導入しています。プロジェクトで ADR を使い始めてから 1 年以上が経過したので、実際に使ってみての感想と今現在の捉え方についてここに残します。
ADR とはなにかという説明や具体的な運用方法については検索したら十分に発見できると思うので、ここでは割愛し、私たちのチームでの経験にフォーカスします。
私たちのチームの状況
私たちのチームは、新しいプロジェクトの開始にあわせて 1 年ほど前に結成したチームです。
現在は 4 人くらいのチームですが、開発スピードを上げるためにフロントエンドとサーバーサイドでほぼチームが独立して動いているような時期もありました。
そのときは最大で 10 人以上が同じプロジェクトに関わっているような状態でした。
私たちのチームでの使い方
ADR の導入はチームが大きくなる前から決定していました。それは私の意見として、意思決定時点のコンテキストをドキュメントに残しておくことを重要視していたためです。
これは、意思決定を可能な限り可逆にすることで安全に進むための技術だと認識しています。
なので、ADR という名前ですが、私たちのチームではアーキテクチャだけに限らずいろんな意思決定を残すようにしています。
これをより適切に表せるいい名前をずっと探しているのですが、今はアーキテクチャの部分を取った DR (Decision Record) か、たまたま見かけた ADR (Any Decision Record) がいいかなと思っています。
使ってみての感想
今現在プロジェクトのリポジトリ内に入っている ADR は 60 個ほどです。まだ書けていない ADR 候補は 20 個ほどあります。
良かったこととしては、共通認識の作成にとても役立っています。
まず ADR を作成するプロセス自体が言語化を促します。これによって作成者の中で意思決定が整理されます。
そしてこれをチームメンバーにレビューしてもらうことによって、ADR を通してチームメンバーの認識をアップデートできます。
コメントなどで抜けていた観点を補足することなどもできます。
実際、口頭で合意したので ADR を書いてみたら、認識がズレている部分があった、話し忘れていた観点があった、ということはよくありました。
コミュニケーションのチャンネルが変わることでちゃんと考える時間が作れる、というのも良い点だと思います。
ここはどうしてこういう決定にしたんだっけ？ -> そうだこれに困ってたんだった、というようなことを確認することもあり、再び方針をどうするか考えなおす、ということを避けられたこともありました。
また、他のプロジェクトのメンバーに、私たちのプロジェクトではこのような理由でこのように決定しました、というようなことを共有できたり、他の人がどういう観点でどこをチェックしてどういう意図で意思決定をしたのか、ということを学ぶこともできました。
トレードオフとしては、ドキュメントを書くコストは書く分だけかかると感じています。
もちろんドキュメントを書けばドキュメントを書いた分だけコストがかかる、ということは当たり前のことなので、想定通りのことでした。
かけたコストに対してリターンがある分だけを書こうと考えていましたが、むしろ想定以上にリターンが大きいと感じており、もっと積極的に書いてもいいかも知れないと思い始めています。
私が考える ADR の本質
ADR を実際に使っていて、私の ADR に対する認識も少しずつアップデートされてきました。
今現在の ADR に対する認識を端的に表現すると、「アーキテクチャがどのようにモデリングされていったのかを時系列まで含めて残すことでソフトウェア開発者がメンタルモデルを正しく構築するのを支援する手法」と捉えています。
これは、学びを失わないための技術の 1 つかなと考えています。
すべての記録、すべてのチャットやすべてのミーティングの録画など、すべての記録を残してすべての記録を読み込めば、学びを失わずにメンタルモデルを構築することは可能なのかもしれません。
しかし、それは人間には現実的に不可能なことです。
ソフトウェア開発というドメイン上で残すべき変更をモデリングして限られた情報を残すことで、これらの情報を構造化し、現実的に読み込み可能にする、そうすることで初めて再利用可能となり、価値が生まれる。
これが ADR の本質だと現在は感じています。
ソフトウェア開発とは、なにかを作ることではなく、なにかを作り続けることだと私は考えています。
それは学び続ける旅のようなもので、ADR はこの物語のチェックポイントのようなものだと感じています。
過去の経験があることによって、未来への意思決定が行えると思っています。
ADR はビジネス要求をアーキテクチャの側面から記録しているものと言えると思います。
今後は、ADR をアーキテクチャだけではなく、いろんな側面に拡張して適用していきたいと私は考えています。
