Decision Record（コンテキスト）のすすめ。安定的にサービスを運用し続けるためのコンテキスト文化の構築 #チーム開発

私のコミットしているプロジェクトでは「Decision Record」を残すこと心がけております。
私は現在のプロジェクトに参加するまで「Decision Record」すら聞いたことない状態だったので記事を読んでくださる皆さんに知ってもらえればと思います！

【この記事に書くこと】

「Decision Record」とは？

一般的には「Architecture Decision Record (ADR)」と言われるものです。
プロジェクトチームではArchitectureの部分を省いて「Decision Record　（DR）」と読んでいます。
※以後DRと記載します。

プロジェクトでは、アーキテクトの決定のみならず…

など様々な決定事項、コンテキストを残すことにしたのでArchitectureの「A」をとって「DR」と呼ぶことになりました。

ただ、「DR」だと似たような言葉が多くあります…

なので文字で伝える場合には「Decision Record」と書くか、他の命名にするかが良いかもと思っています…

チームはハイコンテキスト、つまり阿吽の呼吸で動けるのが一番良いとは思います。

ただ、サービスの運用歴が長くなればメンバーだけでなく技術も変わります…

そんな時DRが残っていれば…

などを知るための手掛かりになります！

私は10年以上運用されたサービスにJoinして開発してきました。
なぜそうなっているのか？が分からずにどのように修正するのが良いのか判断の難しい場面によく出会いました…

DRが残っていない中修正したコードはやがて負債と言われ、改修の容易性やコードの見通しを悪くすることにつながり「生産性の低下」という形で現場の工数を逼迫する原因になる可能性が高いです…

DR（コンテキスト）が残っていれば、フレームワークをアップデートしようとした時やコードをリファクタリングする時に

その時の状況に応じた適切な判断を現場に生み出すための一助になるのがDRだと考えています！

運用方法について紹介します！

githubの「Discussions」を使います！
リポジトリーに入って、メニューの「Pull requests」の横にあります！

設定できてないと「Discussions」の項目は表示されないのでgithubのドキュメントを確認しながら行なってください！

Discusionsのページが表示されたら、画面右あたりにある「New discussion」で作成します。

次にカテゴリーを選択します。

デフォルトで様々なカテゴリーが用意されています。
「Decision Records」は新しくカテゴリーに追加する必要があります。

運用方法はシンプルです。

詳細な運用方法については後で触れますが、たったこれだけです！

Discussionにはラベルをつけられます。
チームでは　デフォルトで定義されているのに加えて「frontend」と「backend」を追加して、絞り込めるようにしています！

議論用のDiscussionには下記のような項目で内要を記載します！

上記の項目を記載したら、メンバーに意見を募ります。
コメントとして意見が投稿されるので、追加調査や再検討します。

最終的に検討事項がなくなったらDecision RecordsのラベルをつけてDiscussionを作成します。

基本的にチャットなどの非同期で行いますが、最終決定する時はMTGを設けて口頭で意見交換をします。

DR、コンテキストを残すことの大切さが少しでも伝われば幸いです。
DRを残すことは未来の開発者にとって唯一の道標になります。

ただ、Discussionを作るだけ作って放置されてしまうこともあります…。
なので意識的にチームで見直す時間を設けて運用するのが良いかと思います！

関わったサービスが安定的に持続していくために、まずDiscussionを作ってみることから始めてください！