This is Leanを読んで - その1
はじめに
先日This is Leanを読了しました。この本を読むきっかけとしては、アジャイル開発やScrumという文脈で度々耳にすることもあるLeanという言葉について、改めて自分の認識を固めておきたかったためです。 本ブログではこの本を通して語られる内容に対して、ソフトウェア開発、アジャイル、Scrumでの経験に落とし込んで、僕なりの整理をしていきたいと思います。
それぞれ効率について
リソース効率
リソース効率とは、従来効率と呼ばれる多くの場合に意味しているものとなります。 具体的には、ある業務を担当している担当者に対して稼働率が100%に近づくように担当業務を割り振るための効率化を指します。 つまり、ある価値を生じさせる機能(人、機械など)にスポットを当てた効率性となります。 多くの企業において、セールス部門、エンジニアリング部門、企画部門など、機能ごとに組織化してこのリソース効率を高めるための構造を構築しています。
Scrumにおけるリソース効率
リソース効率という観点から、Scrumを見ていくことにします。 以下の図の通り、あるScrumチームにはInfra engineer、Backend engineer、Frontend engineerがいると仮定します(engineerの名称については簡略化のためこのように記載しております、ご容赦ください)。 それぞれのPBI(Product Backlog Item)には、各種Infra、Backend、Frontendに関するタスクが存在します。 リソース効率を念頭において各PBIに取り組むとすると、担当であるタスクに注力することとなります。
例えば、Infra engineerにスポットを当ててみると、Sprint内でInfra関連のタスクにリソースを全投入しようとしています。 プロダクトの採算を管理している事業部がPO(Product Owner)の場合には、リソース効率を高めることを要望してくることがありました(engineerにももちろん人件費がかかっているのでわからなくもない話しではありますが)。 具体的にはSprint外のItemにおけるタスクを実施するなどといった要望です。そもそもScrumとしてのルールから逸脱している要望ですが、実際にあった話しです。
リソース効率を高めた際に起こり得ること
では、リソース効率を高めた場合にどのようなことが発生するのでしょうか？ここで簡単な例を挙げます。 以下の図に示す通り、リソース効率を高めようとすると、各engineerはそれぞれのタスクに取り組みます。
すると、あるItemに対しての開始から完了までの時間が徐々に長くなっていくのがわかるかと思います。 また、あるタイミングにおいては複数Itemに対するタスクが並列で処理されていることもあります。 これらリソース効率により発生する事象によって、Scrumチームのパフォーマンスにどのような影響が発生するかは、2. 両効率を同時に満たすことはできないでお伝えできればと思います。
フロー効率
上記でリソース効率はある価値を生じさせる機能にスポットを当てた効率性ということを書きました。 一方で、フロー効率とは、あまり耳馴染みのない言葉かもしれませんが、ある価値を付与する対象への効率性ということができます。 また、ある価値を付与する対象のことをフローユニットと呼びます。
Scrumにおけるフローユニットと効率性
リソース効率でも行ったように、Scrumという観点におけるフロー効率を見ていきたいと思います。 フロー効率はフローユニットへの効率性を高めるものです。ScrumにおけるフローユニットはPBIとなることが多いと思います。
ご覧のように、リソース効率で発生していた事象である開始から完了までの時間が安定し、複数Itemに対するタスクの並列処理が解消されたことがわかると思います。 実際にScrumにおいて、このフロー効率を高めるプラクティスは種々ありますが、それは別のブログや書籍にお任せしようと思います。
さいごに
如何だったでしょうか。本投稿では、リソース効率とフロー効率について、Scrumという観点から情報をまとめてみました。 今回の内容に関連して、モブプログラミングなどのプラクティスとの関連性も垣間見えた方がいらっしゃるかと思いますが、This is Leanからは少し蛇足となりそうだったので割愛してます。 ただし、実際にScrumで実践しているプラクティスの背景や動機を考える上のスタートラインとしての意義はあったのかな、と個人的には思ってます。 僕が整理したい部分にフォーカスしてますので、網羅性などはあまりありませんが誰かのお役に立てれば幸いです。