![見出し画像](https://assets.st-note.com/production/uploads/images/124238334/rectangle_large_type_2_ae01cd600806f66cf376fbee9bd96bcb.jpeg?width=1200)
Architecture Decision Records(ADR)を導入してみた
こんにちは。CAMPFIREエンジニアのhayashidaです。
前回、Four Keysの計測 について書かせていただきました。
今回は、2023年4月に入社してすぐのころに行った Architecture Decision Records(ADR)の導入 について、話させていただきます。
目次
Architecture Decision Records(ADR)とは
Architecture Decision Records(以下、ADR)は、ソフトウェアアーキテクチャにおける重要な意思決定をした際に、「決定した内容」「コンテキスト」「結果」を簡潔に記載して、ログとして残していくものです。
これらの情報をナレッジとして残していく上で、統一されたフォーマットで一箇所にまとまっていることが望ましいため、テンプレート化しておくことが一般的です。
これにより、重要な意思決定を、決定の時期や当時の状況を含めて把握できるようになります。また一箇所にまとまっていることで、情報の閲覧性や検索性の向上が期待でき、ナレッジベースとして利用できるようになります。
CAMPFIREに入社して感じたこと
CAMPFIREは、設立から10年以上が経っています。
その中で様々な方がプロダクトに関わり、また様々な環境の変化やサービスの統廃合もありながら、今のシステムに至っています。そのため多くの知見があり、また当時の状況にあわせた判断がされています。またCAMPFIREには、Notionが導入されており、そこに多くの情報が残されています。
一方でよくある状況ではありますが、そうした判断における多くの情報が議事録の中だけに存在したり、分散していたりする状況もありました。
そのため、システムのある箇所について改善や改修をしたいとなった場合に、当時の対応が今の状況でも継続するべきかわからないこともあります。それにより、調査し直したり、都度当時を知っているエンジニアがいないか確認したりする必要がありました。
ナレッジが散逸している状況を改善したい
CAMPFIREのサービスは、多くの方の知見や技術によってプロダクトが実装されています。そうしたナレッジが、今後にもいかしていける状況を作りたいと感じました。
他方で、CAMPFIREでは Value(CAMPFIRE way)を体現している人が多くいて、わからないことを尋ねると、多くの人が親切に答えてくれる環境があります。しかしながら、適切にドキュメント化されていれば不要になるようなコミュニケーションや調査などが発生している可能性もあります。より重要なことに注力できるためにも、この状況を改善できればと考えました。
そこで、とくに重要なアーキテクチャなどのシステム設計や実装の判断を残していくために、ADRを導入することにしました。
ADR導入までに行ったこと
ADRのテンプレートを作る
まずはテンプレートを作成することにしました。
とはいえ、一から自分で作成するのではなく、必要な情報が記載されている既存の公開されているテンプレートを参考にすることにしました。
そこで、最低限必要な情報を書くだけでよいように、Lightweight Architecture Decision Records(以下、LADR)を参考にすることにしました。
https://github.com/peter-evans/lightweight-architecture-decision-records
https://github.com/moomoo-ya/LADR-template
#【ADR】(タイトル)【YYYY-MM】
## 文脈
* 判断当時の経緯、観点、事情など
## 採用状況
* 採用(Accepted)/不採用(Rejected)/保留(On holding)
* 理由も簡単に記載する
## 決定事項
* 判断の結果として決定した内容など
## 結果
* この決定に対する評価
## 参考
* 参考にしたWebサイトや書籍、議事録などのURL
まずは自分が書いてみる
LADRを参考にテンプレートの準備はできたのですが、これだけでは全員がどういった内容を記載するのがよいのか、わかりにくそうだと感じました。
そこで $${\textit{Eat}}$$$${\textit{your}}$$$${\textit{own}}$$$${\textit{dog}}$$$${\textit{food}}$$ の精神で、まずは自分が実装していた社内向けのSlack BotのアーキテクチャをADRで記載しました。
このときに、実際に書いてみて気づいた点をもとに、テンプレートに修正を加えました。
ADRを書く文化を作る
最後に、ADRを書く文化を作っていくことにしました。
最初にエンジニアチーム全体の会議で、課題感やADRの頭出しをして、意見を募りました。
課題感については賛成の意見が多かったのですが、「いつ書くべきなのか」という点について、共通認識を持つのに苦労しました。結果的には、最初から個々人で判断するのは難しそうだ、という結論に至りました。
ただ、課題感の共通認識はあるから、まずはやってみようということにはなりました。
次に、新たに導入された仕組みを意識できるようにするため、Pull Request の Description のテンプレートに、「重要な決定をしている際にADRの記載をしているか?」のチェック項目を追加しました。
これにより、現在は少しずつですがADRを記載するメンバーが増えてきています。
まだまだ全員が書いたことがある、といった状況ではありませんが、ここから少しずつ全体に広まっていけばと考えています。
![](https://assets.st-note.com/img/1696555773024-6AeNGb2B69.jpg?width=1200)
過去のナレッジを活かせるように
CAMPFIREのサービスは、長期に渡って開発されてきています。その中でリプレイスや様々な技術導入、逆に導入しない判断をした技術などもあります。
また、新たな挑戦などでCAMPFIREの開発チームから離れていった方も一定数いらっしゃいます。そうした方々と作り上げたシステムだけでなく、開発時のナレッジについても将来活用できる資産として残していきたいところです。
CAMPFIREでさらなるチャレンジをしていく上で、こうしたナレッジが役に立つ日が来ると感じています。そのためにも、今後もADRを記載していく活動にチームで取り組んでいきたいと思います。
この記事が気に入ったらサポートをしてみませんか?