This is Leanを読んで~その2~
はじめに
前回の投稿では、This is Leanを読んで~その1~と題して、リソース効率とフロー効率の概要をScrumの文脈で書いていきました。 今回はリソース効率におけるパフォーマンスへの影響を挙げ、フロー効率との完全なる両立が困難な理由を書いていければと思います。
リソース効率におけるパフォーマンスへの影響
まずは前回の投稿でのリソース効率について簡単に振り返ります。
Scrumを例にとった場合に、リソース効率を高めようとすると以下の図のような状態が予想されます。
長いスループット時間の影響
今までは開始から完了までの時間と書いていましたが、これをスループット時間と言います。 スループット時間とは、フローユニットに対する処理が開始してから完了するまでの時間を指します。 Scrumにおいては、ひとつのPBIをフローユニットといい、そのPBIへの処理が開始されてから完了するまでをスループット時間と呼ぶこととなると思います。 完了が何を指すのかは、Scrumチームにおける完了の定義(Definition of Done)によると思いますが、今回の投稿ではプロダクトを利用しているユーザに対して、PBIによる機能がリリースされたこととします。
スループット時間が長くなるとはどのようなことを意味するのでしょうか。 例えば、開発開始からリリースまでの時間が長くなります。すると、リリース対象の実装がどのようなものだったのかを思い出すことが必要になってくるかもしれません。 この思い出す作業が発生することにより、副次的なタスクとして、リリース対象の実装を別途ドキュメントとして書き出しておいたりといったものが追加される可能性もあります。 このような本来必要のないニーズ（上記の例でいえば、思い出す作業をスムーズにする）といったものを、本書では二次ニーズと呼び、スループット時間が長くなることで二次ニーズが発生しやすくなると書いてあります。 そして、このような二次ニーズにより不要なタスクが発生することも示唆しています。
不要なタスクが発生することで、本来注力すべきタスクに割く時間が減少してしまうのは、Scrumチームのパフォーマンス低下に結びつくのではないでしょうか。
多すぎるフローユニットの影響
リソース効率を高めようとした際には、上図からもわかるように、各engineerに対してフローユニットに関連するタスクに連続的に取り組んでいかなければなりません。つまり、フローユニットが多くなるのが常です。 そのため、Scrumチーム内で様々フローユニットに対するタスクが並列で実施されている状態となります。このような状態において発生する事象はどのようなものがあるでしょうか。
例えば、各engineerが並列するタスクにおいて、ひとつのGit Repositoryの各々のブランチで作業を実施していたとします。そのような場合にはコンフリクトやリベース作業などが発生しやすくなります。 コンフリクトの解消やリベース作業は本来不要なタスクだったかもしれません。並列するタスクを実施することにより、ムダなタスクが発生する可能性が高まることになります。 また、あるengineerが別のengineerが実施したタスクに対して質問したとします。しかし、質問されたengineerは現在はまた別のタスクを実施しており、その質問を答えるために頭の切り替えをしなければならなくなります。 このように、スイッチングコストが高まる可能性もでてきてしまいます。
つまり、フローユニットが多くなると、長いスループット時間の影響と同様にムダなタスクが発生することに加えて、スイッチングコストが高まることによるパフォーマンス低下が生まれてしまうかもしれません。
リソース効率とフロー効率の両立は困難
上記ではリソース効率を高めることで発生し得るパフォーマンスの低下について書きました。
これらの原因としては、長いスループットや多すぎるフローユニットなどが挙げられます。
この原因を解消するためのアプローチがフロー効率を高めることとなります。
そのため、フロー効率を高めようとすると必然的にリソース効率は低くなるのです。
さいごに
いかがでしたでしょうか。リソース効率を高めた際の影響については、読んでいただいた皆さまにも覚えがあることだったではないでしょうか。 また、リソース効率を高めた際のパフォーマンス低下を避けるための方法としてのフロー効率についても書きました。これによって、リソース効率とフロー効率の両立が困難なことも記載しました。
