はじめに
私が所属する開発チームでは意思決定の結果だけでなく、議論した内容などその結論に至ったまでの経緯をデータとして残すよう工夫しています。
まだまだ試行錯誤の段階ですが、今時点で採用している方式を紹介します。
ADRとは
Architecture Decision Records（アーキテクチャ決定記録）の略で、
開発における重要な意思決定の経緯をドキュメントに起こす手法です。
なぜ残す必要があるのか？
私のチームでは0→1の開発を担当しています。特に不確定な要素が多く、当然ですが答えが一つであるケースはほぼ無いです。時間の流れとともに答えが変わります。
そんな状況でも、毎日沢山の意思決定をして、前に進めなければいけません。
そこで私たちは、Two-Way Door の考え方を取り入れています。
とにかくやってみて、上手くいかなかったら戻そう、と共通の認識のもと開発を進めています。
上手くいかなかった時に、直ぐに戻せたり、方向転換が出来るように、意思決定の結論だけでなく、議論した内容など過程を残すようにしています。
とにかくやってみて分かったこと
はじめはGit Hubのリポジトリに、ADRを残すことにしました。
決定事項/背景/議論の内容/懸念事項 の項目など丁寧なテンプレを用意していました。
最初は良かったものの、進めていくうちに課題が見つかりました。
- ADRを残す人は固定され、その人の負荷になる
- Git Hubを開かないと確認できない
- 続かない
中身がどうであれ、まずは残すことが何よりも重要だと考え工夫をいれることにしました。
新ADRの仕組み
とにかく「続けられる」仕組みにするため、メンバー全員が簡単にADRを残せることをポイントに考えました。
- 普段から使っているSlackを使う
- 議論スレッドごと（生データ）をADRとする
- リアクションを押すだけでADRが残る
日頃からSlackでコミュニケーションをとるため、意思決定に重要なデータはSlackに集まっていました。
スレッドで議論することもあり、その投稿ごと残せないかと思いSlackを選びました。
Slack だと投稿が流れていってしまい、検索に時間が掛かることもあるため、ADRの投稿自体をCanvas にブックマークが出来るフローを用意しました。
最後に
Slackに切り替えて3か月が経ち、ADRを残す癖は付いているように思いますが、まだまだ改善できることはあるなと思います。プロダクト全体にかかるような大きな意思決定だけでなく、各開発チーム内での意思決定なども残したいと思います。
ADRを残すことで、将来の自分たちを助けることが出来ると思っています。
続ける為には強い意思だけでなく、続けられる仕組みが必要だと感じます。
まずはやってみて、そこで見つかった課題に対して工夫を取り入れる。常にブラシュアップして業務をより良くしていきたいです。