TL;DR
- 1PBI=1価値
- レビュー最優先
- WIP制限
まずはこの3つを浸透させることでフロー効率重視の開発基盤を作る！
はじめに
レバテックの多くのチームではスクラムに取り組んでいます。
スクラムでは継続的な価値提供が重視され、そのためにはリソース効率よりもフロー効率を優先して日々の業務に取り組むことが必要となります。
今回は、自チームの価値提供速度を高めるために実施したことをまとめようと思います。
フロー効率とは
ソフトウェア開発において、人の稼働率を重視することがリソース効率重視、稼働率よりも1つ1つのタスクに着目してそのタスクが得るリソースの時間を重視することがフロー効率重視という状態になります。
つまり、フロー効率重視の開発は、1つのタスクの待ち時間をできる限り少ない状態で開発していくので、1つ1つの価値を最速で届けたいという環境に最適です。
やったこと
自チームでは、タスクが並行で進むことが常態化しており価値提供速度が遅い状態でした。
そこでフロー効率を重視した開発スタイルに変更していきたいと考え、以下3点に取り組みました。
1. 1PBI=1価値
1つのPBIに複数の価値が含まれると、PBIのサイズが大きくなり1つ1つの価値提供速度は落ちます。
そこで1PBI=1価値となるようにタスクを細分化することで、そのPBIで提供できる価値を明確にし、その1つの価値に集中して開発する体制を築きました。
2. レビュー最優先
開発まではスムーズに進んでもレビューやレビュー戻りの修正で停滞すると価値の提供速度が落ちます。
リソース効率偏重な考え方だと、タスクは個人ごとに持つので他者のレビューは空き時間でやることになり、レビュー待ち時間が長くなりがちです。
フロー効率重視の考え方を導入する以前の自チームは、タスクを個人単位で持っていたため、このレビュー待ち時間が長くなりがちでした。
そこで開発以降のフェーズもスムーズに進むよう、まずはレビューを最優先にやる意識だけでも持ちたいと考え、レビュー最優先のルールをチームに設けました。
また、最初は意識付けのみの実施でしたが、徐々に仕組み化するため対面レビュー・ペアプロ/モブプロにも積極的に取り組みました。
3. WIP制限
WIP制限とは進行中の作業(WorkInProgress)に上限数を設けることで同時進行できる作業量を制限する手法です。
WIP制限を設けると1つのタスクを完了させるまで次のタスクに取りかかれないため、「ほぼ完了」の状態を減らすことができます。
フロー効率を意識する開発において、スプリントの中では1つ1つの価値に集中したいです。
理想はスクラムチーム全員で1つのPBIのみに集中することですが、チームの人数やタスクの緊急度などを加味すると全てのスプリントでそれをやることは難しい状況でした。
そこで、WIP制限を「3」に設定して向き合う価値の選択と集中を実施しました。
やってみて...
価値提供速度は体感として向上し、FourKeysにおける変更のリードタイムも向上しました。
そして最も効果があったと思う点は「チームがフロー効率を意識して開発し始めた」点かと思います。
従来のやり方では1人1タスクを進めつつ、空いた時間でレビューや詰まっている人がいたらフォローに入るというやり方でしたが、フロー効率を重視し始めたことで明確に協働作業をする機会が増えました。
終わりに
今回、価値提供速度を高めるために、フロー効率を重視した開発ルールを設けて実践したことについて話しました。
この行動によってフロー効率を重視する視点を持つことはできましたが、あくまで基盤となる考え方やプロセスが整ったのであって、全てが整ったわけではありません。
昨今ではFourKeysの向上が話題に上がりやすいですが、デプロイ頻度や変更のリードタイムの短縮でも、フロー効率向上の取り組みでも、まずは上述したような意識やプロセスレベルの基盤を整えることが前提条件となり、この前提条件となる考え方を浸透させた上でDevOpsのケイパビリティを高める行動(CI/CDの整備など)が重要となってきます。
この記事は非常に初歩的な取り組み例でしたが、この記事を読んで下さった方々の開発プロセス策定の一助となれば嬉しい限りです！
Discussion