スクラム開発へのFour Keysの取り入れ方
Four Keysの有効活用には、チームメンバーが定期的に各指標をチェックすることが重要です。開発プロセスにFour Keysをどのように組み込むのか、私のチームが採用した方法を一例として紹介します。
私のチームでは、1週間のスプリントサイクルを採用してスクラム開発を行っており、スプリントのレトロスペクティブの際にFour Keysの指標をレビューする時間を設けていました。これにより、以下のプロセスを通じてスプリントごとの課題の洗い出しと次のアクションの決定に役立てています。
1. レトロスペクティブ開始時のFour Keys指標のチェック
レトロスペクティブでは、まずFour Keysの指標を確認し、悪化している指標や改善が期待通りに進んでいない指標をチェックします。特に問題がない場合は、無理にFour Keysにもとづくアクションを設定しないこともあります。
2. Pull Requestごとのボトルネックの特定
Four Keysの指標が低下している場合、原因となったPull Requestを詳細に確認します。この際、どのようなプランニングが行われたか、レビュープロセスでどのようなやり取りがあったかを振り返ります。
3. Four Keysの改善に向けた次のステップの設定
指標の低下原因を解析し、それを改善するための具体的なアクションプランを立てます。例えば、指標の低下が「設計や実装方法に関するレビューが長引き、承認までに時間がかかった」ことが原因であれば、「チーム全体でモブプログラミングを実施して実装の理解を深める」や「プランニング段階でより詳細な設計を行う」などのアクションを設定します。
Four Keysを活用して得られたメリット
次に、Four Keysをスクラムの中で活用してどのように指標が改善したか、そしてその中で感じたメリットについてお話します。
Four Keysによる改善を始める前、私のチームではメンバーの入れ替わりなどにより、設計やレビューのプロセスがスムーズに進まず、作業の手戻りやスプリントに積んだPBIが仕掛かってしまうことが問題となっていました。Four Keysの計測はすでに行っていましたが、スクラムのプロセスには積極的に組み込んでおらず、この機会にFour Keys指標を活用して生産性の向上を図ることを決めました。改善開始当初のFour Keysの計測値は以下の通りです。
- デプロイ頻度：0.2件/日（High）
- 変更のリードタイム：175時間（Medium）
- 変更障害率・サービス復元時間：0（Elite）
そして、3カ月後の計測値は次のように改善しました。
- デプロイ頻度：1.8件/日（Elite）
- 変更のリードタイム：19時間（High）
- 変更障害率・サービス復元時間：0（Elite）
スプリントのレトロスペクティブでFour Keysの数値を確認し、ボトルネックを特定して改善アクションを実施するプロセスを繰り返しました。結果として、デプロイ頻度は週1回から1日1回以上に増加し、変更のリードタイムも1週間から1日以内に短縮されました。数値の改善に加え、チケットの仕掛りも減少し、スプリントごとのベロシティも向上しました。
この改善過程では、プランニングの方法を変更したり、モブプログラミングを試したり、コミュニケーションの取り方を見直したりと、さまざまな取り組みを行いました。
Four Keysのような指標を用いることで、感覚的な判断ではなく、数値にもとづいて改善を行うことの重要性を実感しました。また、Four Keysの指標が良くなるにつれて、コードレビューでのやりとりが減り、書いたコードが迅速に本番環境にデプロイされるなど、開発体験の向上も感じることができました。
Four Keysの実践において直面した課題や困難
Four Keysは有用な指標ではありますが、すべての開発生産性の側面を網羅しているわけではありません。導入を進めていく中で以下の課題があることにも気づきました。
数値を追うことを目的にしてしまう
Four Keysを活用する過程で、ときには数値の改善だけを目的としてしまう傾向がありました。指標改善を目標とする際、本質的な改善とは無関係な数値の追求に偏ってしまうこともありました。例えば、リードタイムを短縮するために休み明けにコミットを行うなどです。開発生産性を向上させるという目的意識を持ち、あくまでもFour Keysは自分たちの状態を知るための健康指標として捉えるのが良いと思います。
アウトカムの計測が難しい
Four Keysは主にデプロイの頻度や変更のリードタイムなど、特定の側面に焦点を当てています。開発したコードがいかに不具合なく迅速にデプロイされているかは計測できますが、最終的にユーザーにどれだけの価値を提供しているか、というアウトカムの測定は行えません。
Four Keysだけを目標にしてしまうと、極端な話にはなりますが、価値の少ないものを高速に作っている状態にもなり得るので、ユーザーにどの程度価値を与えているかというアウトカムの部分については意識すべきだと感じました。
最後に
今回、Four Keysを導入した背景や実際にスクラム開発の中で活用してみて分かったことをお話しました。Four Keysの計測によって開発生産性の向上に役立てることができる部分は多いので、本記事が皆さまの参考になればうれしいです。
