以前Pull Requestから社内全チームの開発パフォーマンス指標を可視化し、開発チーム改善に活かそう - Hatena Developer Blogの記事で、開発パフォーマンスを可視化する話を書いた。その後、バリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みを行ったので、その経験についてブログに書いておく。
- 前回の記事のサマリー
- バリューストリームマップを作り、開発フローの課題を発見する
- 見つかった課題を解決する
- 開発パフォーマンスの指標で改善結果を振り返る
- まとめ：データを根拠にチーム改善するという進歩
- 参考
前回の記事のサマリー
前回の記事を前提として書くため、簡単にサマリーすると
- 開発チームのパフォーマンスを測るためには、以下の4つの指標を計測すべきと言われている
- 変更のリードタイム: first commit〜そのcommitが本番にリリースされるまでの時間
- デプロイの頻度: 本番環境へのデプロイの回数
- MTTR（平均修復時間）: サービスダウン〜復旧までの時間
- 変更失敗率: 本番デプロイ時のサービスダウン発生率
- 全てを一気に可視化するのは難しいため、一旦計測しやすい次の指標を可視化した
- 変更のリードタイムの一部分であるPull Requestのプロセスタイム : first commit〜Pull Requestのマージまでの時間
- デプロイの頻度
バリューストリームマップを作り、開発フローの課題を発見する
前回の記事で、開発チームの開発パフォーマンスの指標を可視化できた。しかし、この指標だけでは具体的にどのような改善すべきかは分からない。そこでまずバリューストリームマップを作り、開発フローのボトルネックを洗い出そうと考えた。
バリューストリームマップとは何か
バリューストリームマッピングとは、製品やサービス、機能を顧客へ届けるために必要なプロセスを可視化するツール。詳細や具体的なやり方については、ここはあえて紙とペン！ Value Stream Mappingで開発サイクルの無駄を炙り出せ！やバリューストリームマッピングをやってみたの記事が非常に参考になる。
チームのバリューストリームマップを作る
自分のチームの開発は、企画が決まった後は、次のように進んでいく。
- 機能のためのPull Requestを細かい粒度で作っていき、レビューが通り次第マージする
- ある程度の量マージされたら、リリースする
- リリースを繰り返して、最終的に機能が完成したら、ユーザーに公開する
そこで、Pull Requestの粒度の開発サイクルと、リリースの粒度の開発サイクルについて、バリューストリームマップを作ってみた。本当は企画から全てのフローを含めてバリューストリームマップにした方が良いのだが、最初から全部やろうとすると大変なため、まずは一部に絞って行った。
バリューストリームマップを作るポイントとしては以下の二点と考えている。
- 1) 課題を分かりやすくするため細かめにカードを分割し、それぞれ作業人数と時間を書くこと
- 2) 作業者が変わるところはボトルネックになりやすいので、その部分は点線でつなげること
- 自分は、作業者は同一だけど待ち時間が発生するものも点線でつなげた。コンテキストスイッチのボトルネックを分かりやすくするため
書いてみたバリューストリームマップは次の通り。
Pull Requestの粒度の開発サイクル
リリースの粒度の開発サイクル。「デプロイ」の部分は実際はもう少し詳細に分割していたが、外部公開の都合上1つのカードにしてしまっている。
バリューストリームマップから課題を見つける
バリューストリームマップから分析したところ、やはり20分もかかっているCIの遅さがさまざまな場所でのボトルネックになっていると分かった。CIの時間は、開発パフォーマンス指標における変更のリードタイム・デプロイ頻度・MTTRの全てに影響を与える。開発フローの中でインパクトが最も大きいので改善したい。
他にも、コードレビューにコストがかかりすぎている、リリースフローの関係上マージ禁止の期間がある、リリース時のパフォーマンス確認に時間がかかっているなどの課題も見つかった。見つかった部分には赤色の付箋で印をつけていった。
見つかった課題を解決する
バリューストリームマップによって課題を発見できたので、後は1つずつ解決していくだけである。
まずCIについては
- テストの並列化などを通して、5分ほど実行時間を短縮した
- フロントエンドしか変更していない場合、バックエンドのテストに影響することはないため、特定条件の場合バックエンドのテストをスキップした
という改善を行い、すべてのテストを動かしても15分弱で、フロントのみの変更なら4分でCIが終わるようになった。
他に見つかった課題も分析を行い、ランダムでコードレビューを割り当てるのをやめる、マージ禁止の条件を見直して1時間ほどマージ禁止期間を短縮する、パフォーマンス確認がしやすくなるMackerelのダッシュボードを作るなど、地道に改善していった。
開発パフォーマンスの指標で改善結果を振り返る
最後に開発パフォーマンス指標を観察し、改善結果を振り返った。今回の改善が直接的に効くのは変更のリードタイムであり、その一部であるPull Requestのプロセスタイムを見てみたところ、20％ほど改善していることが分かった。色々な要因で指標は変化しうるので、全てが改善した結果とは思っていないが、少なくとも良い方向に向かわせられたと思っている。
まとめ：データを根拠にチーム改善するという進歩
今回はバリューストリームマップを作り開発フローの課題を洗い出して、チームの改善を行い、そして開発パフォーマンス指標で効果を検証する取り組みについてブログを書いた。
今回の内容を読むと、チーム改善の施策については特に特別なことはしていない。これまでもCIが遅すぎるから直そうとか、レビューフローを見直そうとか、リリース大変すぎるから直そうなどは自然発生的に起こってきた。
しかし、これまでは何を改善すべきかは勘で決めていた部分も多く、かつチーム改善の振り返りもしづらかった。そこから、開発パフォーマンス指標やバリューストリームマップなどを用い、データを根拠にチーム改善し振り返りもできたのは、非常に大きな進歩だと感じている。
今後もチーム改善や組織改善をデータ駆動で行うという取り組みは続けていきたい。
