はじめに
レコチョクでバックエンドエンジンアをしています、早坂です。
これまでシステム開発業務を中心に担当してきましたが、今期から初めてチームの改善活動を推進する役割を担うこととなりました。タイトルにもあるADR（Architecture Decision Records）の導入・活用が改善活動に当たります。この記事は、どのように取り組みを進めたのかの紹介と、個人としての振り返りを含めた体験記となります。
目次
- ADRとは
- 取り組みの背景
- 導入
- KPTによる振り返りの実施
- 自分に対するKPT
- まとめ
ADR（Architecture Decision Records）とは
ソフトウェア開発プロジェクトにおいて重要なアーキテクチャ上の意思決定を記録・共有するためのドキュメントです。具体的には、なぜその決定がなされたのか、その決定の背景や理由、影響を明確にするために使われます。
取り組みの背景
チームの課題として、時間が経つと意思決定した内容を忘れてしまい、以前と同じことを議論していることがありました。開発チームで日々発生する意思決定の例としては、以下があります。
- システム運用・開発における課題の解決に向けた議論
- システム開発方針の決定に関する議論
この背景を基に、以下2点を満たすことを目的とし、ADR（Architecture Decision Records）を導入しました。
- 過去の意思決定内容と、それに紐づく経緯や理由の調査コスト
- 1を基にした議論による意思決定のスピード
結局のところ、この2点は意思決定のコストを下げる意味での生産性向上につながります。 また、意思決定の透明性を上げる目的もあります。これにより、チーム単位でナレッジが貯まる効果も期待しています。
なぜADRか?
ADRという形ではなくとも、議論の意思決定を記録してさえしておけば、意思決定のコスト削減は達成できるという考え方もあります。
しかし、これまでも議事録を書くことや、議論の記録は残すという動きはあったものの、継続しませんでした。原因には、記録を残すことへの作業負担や、記録方法のルールが曖昧であること、記録を残すことの意義が醸成されていなかったことがあると思いました。
そこで、単に記録を残すことを習慣付けるのではなく、ADRという概念を取り入れました。捉え方の話ではありますが、ADRという形式化された新しい施策を取り入れる、という位置付けにすることで意識の浸透がしやすいのではないかと思いました。
ただし、ここでも単に導入するだけでは具体的にどうやってやるのか、導入のメリットはあるのかなどの議論が必要なため、振り返りを定期的に行います。また、検索しやすくするため、1箇所にまとめて保存することとしました。
導入
まずは、詳細なルールを設けることはせず、大枠の決定後すぐにADRを取り入れることとしました。詳細にルールを決めてから取り入れようとすると、ルールを決める段階で議論が進み切らず、いつの間にか取り組み自体なかったことに..という結果を避けるためです。
この時の決定内容は、GitHubにADR専用リポジトリを作成し、チームで意思決定した内容をマークダウン形式で記録していくというものです。取り組みの背景に書いた、意思決定した内容を調査するコストの削減は、Githubの検索機能を手段とします。さらに、簡易に書けるように大まかなフォーマットを設けました。 なぜGitHubかというと、メンバー全員が日常的に利用しており、検索がしやすいという点を重視したためです。
初回ルール
- 専用のGitHubリポジトリのmainブランチのみを利用する
- ファイル名は
YYYY-MM-DD_{意思決定の対象}-{ADRのID}.md - 以下フォーマットで記載する
- ステータス (承認 or 提案 or 拒否)
- 背景
- 決定内容
- 決定内容による影響
- 良い影響
- 悪い影響
- メモ(備考)
- ラベル
このルールを2週間運用し、KPTを用いて振り返りMTGを行うこととしました。 前述している通り、チーム内で認識を合わせながらブラッシュアップしていく前提の取り組みとなります。
KPTによる振り返りの実施
振り返りの方法は、KPTを採用しました。振り返りのフレームは様々ありますが、まだ取り組みは初期ということで、シンプルなものを選定しました。 KPTを行うため、まずはGitHubのProjects機能を使ってカンバンボードを作成しました。Keep、Problemの2つ作成し、意見をざっくばらんに出していくスタイルでの実施です。
- Keep: 既存の良い点、続けるべき点
- Problem: 改善するべき点
ここで、なぜTry(改善アクション)がないかというと、TryはProblemを解決するアクションの定義となる位置づけですが、カンバン表示で議論を進めると、複数の整理されていないProblemが見えているため、論点が曖昧になりがちになると考えました。そうなってしまうと、具体的なアクションまで落とし込むことが難しくなります。
また、カンバンで可視化されたKeepやProblemには重複する内容が含まれているため、カンバンの内容を別の形式に整理し直します。これにより、整理されたKeep、Problemを可視化した状態でTryが議論できます。
以下は実際に意見出しをした結果になります。
Keep、Problemの整理は、マークダウン形式で行いました。可視化できれば良いという点と、既存のADR作成ルールはマークダウンであるため、統一性を持たせたい点が理由です。
1つずつ出たKeep、Problemを確認しながら、整理した結果が以下となります。
Keep、Problem共にフォーマットやADRの機能性について触れた意見が多いことを可視化できました。 ここから、整理されたメモを見ながら、解決することで最も効果が高いと考えられるProblemを議論します。
今回の振り返りでは、運用した2週間の中で作成されたADRの数が少ないことが議論に上がりました。そもそも、メンバー内でADRの利活用や意味付けが浸透していないことが原因として、以下2点を議論するProblemとして挙げました。
- そもそも何に対してADRを作成するべきか共通理解がない
- 個々人におけるADR作成への技術的・心理的ハードルが高い
それぞれのProblemに対して、どのように議論が進んだかを後述します。
1. そもそも何に対してADRを作成するべきか共通理解がない
共通理解がないことに対しては、ADRとして記述される意思決定の具体的な基準を設けることが重要だという議論となりました。以下のような基準が意見として挙がりました。
チームへの影響度が高い意思決定チーム全体に大きな影響を与える意思決定は、必ずADRとして記録することが必要。これにより、重要な意思決定が適切に記録・共有され、後々の参照が容易になる。複雑性を持った意思決定複雑な意思決定についてもADRに記録することで、複雑な意思決定の背景や理由が明確になり、将来的な参考資料として利用できる。システムや運用ルールの変更に関する意思決定チームが管理するシステムや運用ルールに関する変更（新規作成、削除、修正）をADRに記録。これにより、システムや運用ルールの変更履歴が明確になり、変更の理由や経緯を容易に把握が可能となる。
結果、3のシステムや運用ルールの変更に関する意思決定を記述するべき、という基準が最もメンバーの理解がしやすいものとして策定されました。
早坂啓太
