チーム力向上のためのADR導入とKPTを使った振り返り

はじめに

レコチョクでバックエンドエンジンアをしています、早坂です。

これまでシステム開発業務を中心に担当してきましたが、今期から初めてチームの改善活動を推進する役割を担うこととなりました。タイトルにもあるADR（Architecture Decision Records）の導入・活用が改善活動に当たります。この記事は、どのように取り組みを進めたのかの紹介と、個人としての振り返りを含めた体験記となります。

目次

• ADRとは
• 取り組みの背景
• 導入
• KPTによる振り返りの実施
• 自分に対するKPT
• まとめ

ADR（Architecture Decision Records）とは

ソフトウェア開発プロジェクトにおいて重要なアーキテクチャ上の意思決定を記録・共有するためのドキュメントです。具体的には、なぜその決定がなされたのか、その決定の背景や理由、影響を明確にするために使われます。

取り組みの背景

チームの課題として、時間が経つと意思決定した内容を忘れてしまい、以前と同じことを議論していることがありました。開発チームで日々発生する意思決定の例としては、以下があります。

• システム運用・開発における課題の解決に向けた議論
• システム開発方針の決定に関する議論

この背景を基に、以下2点を満たすことを目的とし、ADR（Architecture Decision Records）を導入しました。

1. 過去の意思決定内容と、それに紐づく経緯や理由の調査コスト
2. 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として挙げました。

1. そもそも何に対してADRを作成するべきか共通理解がない
2. 個々人におけるADR作成への技術的・心理的ハードルが高い

それぞれのProblemに対して、どのように議論が進んだかを後述します。

1. そもそも何に対してADRを作成するべきか共通理解がない

共通理解がないことに対しては、ADRとして記述される意思決定の具体的な基準を設けることが重要だという議論となりました。以下のような基準が意見として挙がりました。

1. チームへの影響度が高い意思決定
   チーム全体に大きな影響を与える意思決定は、必ずADRとして記録することが必要。これにより、重要な意思決定が適切に記録・共有され、後々の参照が容易になる。

2. 複雑性を持った意思決定
   複雑な意思決定についてもADRに記録することで、複雑な意思決定の背景や理由が明確になり、将来的な参考資料として利用できる。

3. システムや運用ルールの変更に関する意思決定
   チームが管理するシステムや運用ルールに関する変更（新規作成、削除、修正）をADRに記録。これにより、システムや運用ルールの変更履歴が明確になり、変更の理由や経緯を容易に把握が可能となる。

結果、3のシステムや運用ルールの変更に関する意思決定を記述するべき、という基準が最もメンバーの理解がしやすいものとして策定されました。

2. 個々人におけるADR作成への技術的・心理的ハードルが高い

技術的なハードルについては、個々人のスキル差によっても課題は異なるため、チームとしての取り決めというより、個人に依存する面が大きいという意見がありました。

心理的なハードルの具体例として、文章作成が挙げられました。ADRは重要な意思決定を記録するためのドキュメントであり、正確かつ明確な文章を作成する必要があります。このような厳密さが求められているために書くことへの心理的なハードルが高いという論旨です。

また、明確なフォーマットがないこともハードルの一つとして挙がりました。統一されたフォーマットが存在しないため、何をどのように記載すれば良いのか不明確な点が文章作成のハードルとなっていました。

厳密さが求められている点については、ADR作成にかけるコストと残す情報の価値のバランスであるため、解決するためのアクションを定めるのは難しいと判断しました。一旦、議論としてはフォーマットの課題に集約し、「作成コストを低減するためにフォーマット定義をどうするか」という論点としました。

結果、初回に決まったフォーマットを踏襲しつつ、以下のフォーマットが決まりました。

ADRフォーマット

- ステータス (承認 or 提案 or 拒否)
- 決定内容
- 背景
  - 事実 (決定に関わる事実情報を記載)
  - 事実に対する解釈 (意思決定するに至った理由と経緯)
- 根拠
  - 評価ポイントを踏まえての決定 (後述する評価ポイントに基づいて、なぜその決定を行ったのかを説明)
- 選択肢
  - 評価ポイント (重要視した観点で、メリット、デメリットなど)
  - 決定されなかった選択肢
- 関連するADR (影響するADR)

初回のフォーマットと違う点は、以下です。

• 背景を事実と事実に対する解釈に分解している
• 意思決定した事柄のいい影響、悪い影響を書くのではなく、意思決定に至った根拠を書く
• 評価ポイントとして、何を重要視して意思決定したのかを書く
• ある意思決定は他の意思決定とつながっているため、関連するADRを書く

なお、決まったフォーマットの順番は、重要度を指標としています。
決まった意思決定と背景、根拠が重要で、決まらなかった選択肢はその後、という順番です。

このフォーマットも、一時的に決まったフォーマットであるため、2週間後の振り返りMTGでどのようなKeep、Problemが挙がるかによって、変更される予定です。

自分に対するKPT

ここまで書いた活動内容を推進した私の立場から、自身に対してのKPTを書きます。

Keep

• チーム単位での取り組みを主導したのは初めてだが、チーム内で認識を揃えながらより良いものを作る感覚が楽しいと感じた
• チームで出る意見を仕組みとして取り入れることが、規模や方向は違えどプロダクト開発につながる考え方で、エンジニアとして流用できるスキルだと感じた

Problem

• 施策の導入を推進する立場だと、課題が多く見えてもなんとか推進する方向に進みがちで、視野狭窄となってしまう
• 振り返りMTGでは、ファシリテートする立場でありつつ、自分がしたい話をして脱線してしまうことがあった
• 「どうしたいか」をチーム全体に問うだけでは進みづらい

Try

• 施策の導入を推進する立場だと、課題が多く見えてもなんとか推進する方向に進みがちで、視野狭窄となってしまう

• 施策は導入することが目的となってはいけないので、課題が多く、施策を取り入れるメリットが不足している場合、施策を辞めることも選択として認識しておく

• 振り返りMTGでは、ファシリテートする立場でありつつ、自分がしたい話をして脱線してしまうことがあった

• 議論のファシリテートでは、会話している論点を整理して可視化しておく

「どうしたいか」をチーム全体に問うだけでは進みづらい

• 会議の参加者にざっくり意見を求めることは円滑な議論に進みづらいため、自分の意見を持ち、それを叩き台とする

まとめ

この記事では、ADR（Architecture Decision Records）導入の取り組みについてご紹介しました。まだ導入初期段階で諸々ハードルはありますが、継続していくことで効果を実感しやすいものだと思います。
なにより、チームで議論しながら進めていくことで、全体で納得感を得ながら改善を図っていくプロセスが重要と感じました。

これからも、チームでの取り組みを通じて得た経験を活かし、さらに効果的なプロセスを構築していきたいと思います。同時に、新しい施策や改善点を柔軟に取り入れ、チームとして成長を続けていくことを目指します。この記事が一助となれば幸いです。

最後までお読みいただき、ありがとうございました！