はじめに
こちらの記事は カケハシ Advent Calendar 2023 の 7日目の記事になります。
カケハシの患者リスト開発チームでスクラムマスターをしている松本と申します 患者リスト開発チームでは、10月以降技術負債解消の取り組みを変更しました この記事では、チームで抱えていた技術負債の解消についての悩みとチームでどうやって解決したかについて、書きたいと思います
患者リスト開発チームでの技術負債の定義
- 患者リスト開発チームでは以下のような問題を技術負債と捉えております
- ソフトウェアの内部的な問題
- 設計上の問題点
- 自動化できるはずの箇所の手動処理など
- セキュリティ上の問題点（バージョンアップなど）
元々どのように技術負債に対応していたのか
- （前提として、私たちのチームでは2週間スプリントを採用しています）
- エンジニアが作業中に見つけた技術負債を技術負債バックログに積んでいく
- 技術負債解消デーに取り組む技術負債については、各スプリントに開催させる技術負債整理会にて、技術負債バックログの優先順位付けを行い決定する
- 2週間スプリントの最終週の木金を技術負債解消デーとして確保し、エンジニアが技術負債を解消する
直面した問題
- スプリントの日付を2日間固定して取り組むという性質上、大きな技術負債に取り組みずらい
- 以下の要因から、技術負債解消に取り組む時間が取りずらく、技術負債バックログの在庫が増える一方で減らなくなっていた
- スプリント最終週の木金は、スプリントイベント及び全社会議が多い
- スプリント期間中にはスプリントバックログの対応に集中するため、劣後していた雑務の対応をする必要がある
- 緑色の部分がスプリントバックログの在庫。昨年の9月以降、継続的に在庫が増加している
- セキュリティやエラー対応などのリスクが高い技術負債はかろうじて解消できているものの、デプロイサイクルの自動化（デプロイやマイグレーションの自動化）や運用作業の自動化など生産性の向上に直結するような技術負債には取り組めていなかった
どのように技術負債への取り組み方を変えたか
10月以降、「技術負債バックログへの積み方」、「取り組む技術負債の決定の仕方」、「技術負債の解消の仕方」の3つの観点で取り組み方を変更しました
技術負債バックログへの積み方
- まず、以下の理由からセキュリティやエラー対応などのリスク観点で優先度が高い技術負債以外は削除しました
- 技術負債バックログは、優先順位（高、中、低）で並び替えられていたが、そもそも優先順位の基準が曖昧
- ずっと残っており管理がされていないものが多数存在していた
- 技術負債の追加と優先順位付け
- 技術負債整理会で解決したい問題と期待される効果を明確にした上で追加することで、解決したい問題と期待される効果が曖昧な技術負債が追加されないようにした
- 例）デプロイサイクルの自動化（デプロイやマイグレーションの自動化）
- 問題：コマンドの打ち間違えなどにより、ヒューマンエラーが発生している。加えて、手作業に最大70分ほど要しているため、一回あたりのリリースにかかる工数が大きい（検証会及びリリース会を合わせて週2時間）
- 期待される効果：自動化によるヒューマンエラーの低減、一回あたりのリリースにかかる工数について、最大60分の削減につながる（検証会及びリリース会を合わせて週1時間程度になる見込み）
- 例）デプロイサイクルの自動化（デプロイやマイグレーションの自動化）
- 追加する際に、解決したい問題と期待される効果の観点で、技術負債バックログで積まれている他の技術負債と比較し、優先順位付けをする
- 技術負債整理会で解決したい問題と期待される効果を明確にした上で追加することで、解決したい問題と期待される効果が曖昧な技術負債が追加されないようにした
取り組む技術負債の決定の仕方
- 技術負債整理会で、優先順位が高い技術負債順で、次のスプリントで対応するものを選定する。併せて、タスクの詳細化と見積もりを行う
- 選定した技術負債について、リファインメントで対象となる技術負債について解決したい問題と期待される効果、必要となるリソース（見積もり）を説明し、次スプリントで組み込むことをPdMと合意する
技術負債の解消の仕方
プランニングでスプリントバックログに組み込み、スプリント内で対応する
効果
メリット
- 上記の取り組み開始後、4スプリントのベロシティとベロシティに含まれる技術負債の割合です。一時的な低下はありますが、ベロシティの20%前後のリソースを使い、技術負債の解消に取り組むことができております
- セキュリティやエラー対応などのリスク観点で優先度が高い技術負債以外に、運用作業の自動化、マイグレーションやデプロイの自動化などデプロイサイクルの自動化にも対応でき、より効果的な開発プロセス作りにも繋がっております。また、マイグレーションやデプロイの自動化などのデプロイサイクルの自動化については、合計9ポイント程度（患者リスト開発チームのベロシティの40〜50%程度）の大きさであり、大きな技術負債にも取り組むことができていると言えるかと思います
デメリット
現時点では大きなデメリットは顕在化しておりませんが、小さなデメリットは「解決したい問題と期待される効果が定義しずらい優先度が低い技術負債に取り組みづらくなった点」があります
最後に
以上が患者リスト開発チームの技術負債に関する取り組みでした 患者リスト開発チームでは、上述の通り「技術負債バックログへの積み方」、「取り組む技術負債の決定の仕方」、「技術負債の解消の仕方」を変更することで、本取り組み前に技術負債で直面していた問題を解消することができました 技術負債は、多くの開発チームが経験する普遍的な問題であり、その解消に際しては、さまざまな要因から問題を抱えられているチームが多いかと思います。患者リスト開発チームの取り組みが、同じような問題に直面している他のチームにとって有益な一助になれば幸いです ご拝読いただきありがとうございました！
