はじめに

自社開発のエンジニアをやっています。
毎スプリント振り返りを実施しているのですが、ある日計画したタスクのほとんどの作業は完了できているけどちゃんとクローズできたものが１つ２つしかないよねという話があがり、その改善案として「フロー効率」という言葉が出ました。
当時はフロー効率というものを知らなかったのですが、調べてみると確かに今の自チームにおいて必要であると理解できたので、フロー効率の向上を目的とした改善案を見出してアクションをとりました。
その結果、良い効果がいくつか見られたので、フロー効率の概要と得られた効果について書いていこうと思います。

フロー効率とリソース効率

フロー効率は前述で出てきましたが、それを知る上で「リソース効率」というものも理解すると良さそうです。
簡単に概要をまとめます。*誤りがありましたらすみません

リソース効率とは

リソース(作業者)が作業できている割合を示していると考えています。
例えば作業者Aさんがタスク1とタスク2をもっており、業務時間内常にタスク1→タスク2を着手できている場合のリソース効率は100%になります。
もし、Aさんがタスク1を着手されている途中で別件の庶務作業が入り業務時間の50%割かれてしまったとすればリソース効率は50%になると考えられます。

フロー効率とは

タスクが作業されている割合を示していると考えています。
前述と同じ例で作業者Aさんがタスク1とタスク2をもっており、業務時間内常にタスク1を着手している場合にタスク1のフロー効率は100%、タスク2のフロー効率は0%であると言えます。
もしBさんもチームに加わり、Aさんがタスク1、Bさんがタスク2を常に着手できている場合はタスク1、タスク2共にフロー効率は100%であると考えられます。

チームの課題感

自チームでは作業メンバー全員が常にタスクに着手できるような動きはできていました。言い換えると、リソース効率は常に100%に近い動きはできていました。
しかし、タスクが1~5あったとしてタスクの優先度もタスクの連番順としたときの最優先度のタスクのフロー効率が低いという疑惑が浮上していました。
実例として、下記を前例と置きます。

チームメンバーは3人(Aさん、Bさん、Cさん)
タスクは5つ(タスク1 ~ タスク5)で優先度は1~5の順で高い
各タスクはテスト設計、実装、STG環境テストの実施のサブのタスク含んでいる
サブのタスクはそれぞれ作業者以外のレビューが必須

この場合にスタート地点ではAさんがタスク1のテスト設計、Bさんがタスク2のテスト設計、Cさんがタスク3のテスト設計を着手していきます。そこではじめにAさんがテスト設計を終え、レビュー依頼をするのですが、BさんとCさんは自分のタスクがやりかけであるためレビューを後回しにして、自分のタスクが完了したらAさんのレビューに移るという動きになっていました。
そうしたことで優先度の高いタスク1は一旦ペンディングの状態になり、タスク2、タスク3の足並みが揃ってからタスク1の作業が進み始めるためほぼほぼ同時進行でタスクが進んでいくという動きになってしまったのです。その結果、スプリントで完了させたいタスク全てほとんど完了はしているものの完全にクローズができているタスクがほとんどないということに繋がってしましました。
これは優先度の高いタスクのフロー効率を意識できていないと考えることができ、本来であればAさんがレビューを投げた時点でそのタスクよりも優先度が劣るタスクを着手されているBさんとCさんはすぐにAさんのレビューに移ることで優先度の高いタスクから着実にクローズできる動きが実現できるのではと考えました。

実際にやったこと

優先度の高いタスクのフロー効率を高めることを目的として下記を実施しました。

チーム内で改めて優先度高いタスクから確実に終わらせたいという認識を合わせる
- 目的における認識齟齬が起きないようにするため
レビュー完了が後続タスクの着手可能条件であると認識を合わせる
- 後回しにすることがフロー効率を下げてしまうと意識付けるため
レビュー依頼者が直接会話で呼びかけていち早くレビューを実施できるようにフォローをする
- チャットのみで依頼をしても実施までに時間がかかる可能性があるため

上記を行ったことで確実に優先度の高いタスクからクローズすることができました。

優先度高いタスクのフロー効率を高めたことで得られたメリット

ここまでの記述で優先度高いタスクのフロー効率を高めたことで何が嬉しいのかいまいち見えてこないと思いますので、良かった点を挙げていきます。

不備や要件変更による後戻りが少なくなった

定期的にチーム外に向けて実機レビュー会を実施させていただいているのですが、着実にタスクのクローズができていなかったときは成果物が大規模になってしまい、レビュー会でいただく指摘の対応範囲が広くなっていました。
着実にクローズできるようになってからは細々レビューに持っていける動きが実現でき、対応範囲を狭めることができました。

スケジュールの見積もり差異のリスクが減らすことができた

自チームではタスク量をポイントで見積もっているのですが、今週どれくらいポイントを消化できたかという話をする際にクローズできていないタスクに関しては「大体8割くらい完了できているからタスクのポイント5ptのうち4ptは消化ポイントで計上しとこう」みたいな感じでスケジュール管理をしていました。
このようにざっくりで見積もってしまうと実はこの受け入れ条件が満たせていなかったと判明した時に大きくスケジュールに影響が及ぶ可能性があると考えられます。
着実にタスクをクローズする動きを確立してからはざっくり見積もりが激減し、スケジュール管理のリスクを減らすことができました。

まとめ

自チームで優先度高いタスクのフロー効率を高める動きを実施したことで、開発効率とスケジュール管理の質を向上することできました。
この動き方は現場のプロダクトや案件内容によって有用性が変わってくると思うのでその時折々で動き方については検討する必要があると思いました。
自分はまだまだだスクラムの経験は少ないので留意点やもっと良いやり方があればご教示いただきたいです。