はじめに
先週に以下の記事を読み、これまで参画したプロジェクトで上手くいかなかった原因の１つがこれか！と腹落ちしたので、その備忘録です。
リソース効率が高い＝生産性が低い？
これまで参画したプロジェクトではリソース効率（Devメンバーの稼働率）を日々チェックし、マネジメントを行っていました。
Devメンバー全員が常に、何かのタスクを持っている状態を維持することが最短でリリースできる手段だと信じて、日々進捗状況を細かく確認してWBSを更新していました。
この考え方に以下のデメリットがあることを十分に認識できていませんでした。。
引用
リソース効率を高めると個人のやっている感は高くなりますが、一方で
・待ちが発生する分マルチタスク化が進み、リードタイムも悪化する
・マルチタスクが作業効率をさらに低下させる（スイッチングコストの上乗せ）
・予備戦力がないので完了時期が読めなくなる
などの凶悪な弊害も発生します。
↑の引用記事に記載の通り、これが正しいと教わってきた身でしたが、「スイッチングコストが〜」や「予備戦力がなくて〜」については、Devメンバーから時折投げかけられていたキーワードにあったなぁとも思い出し、、リソース効率を追い求めることに疑問を感じる場面はありながらも、これ以外の手段を検討せずに進めてしまっていたなぁと後悔の念が湧いてきました。。
フロー効率が高い＝生産性が高い？
各タスクの開始から終了までのリードタイムや、ある機能を開発するためのバックログが起票されてからリリースするまでの期間が短い、＝フロー効率が良いと理解しました。
引用
フロー効率に焦点をあてると、「生産性を高める」という言葉の指す意味が変わります。開発者を「リソース」と見立て、彼らがどれだけ多くの仕事をさばいているかというメトリクスへの関心が薄れます。稼働率（リソース効率）がいくら高くても、フローが停滞し、進みが遅ければ意味がないことに気づくからです。
追求すべきは、フロー効率を高めてリードタイムを短くし、フローのスループットを高め続けることです。そうすれば、稼働率も自然と適切なレベルにまで上がります。それこそが、「生産性が高い」と呼べる状態でしょう。
フロー効率の良さをざっくりと引用してしまったが引用元の記事を読んで、フロー効率を高めることがプロダクトの価値、そのプロダクトを利用する人たちの満足度を高めることに繋がると感じました。
まとめ
リソース効率を追い求めていた過去の現場では、その関係者が疲弊する日々でした。
フロー効率を良くすることと、それに関する関係者理解を追い求めることが、無理のないプロジェクト運用を実現できると感じました。
リソース効率に捉われずに、フロー効率を意識したマネジメントを実践していきたいと思います。
