This is Leanを読んで~その1~

はじめに

先日This is Leanを読了しました。この本を読むきっかけとしては、アジャイル開発やScrumという文脈で度々耳にすることもあるLeanという言葉について、改めて自分の認識を固めておきたかったためです。 本ブログではこの本を通して語られる内容に対して、ソフトウェア開発、アジャイル、Scrumでの経験に落とし込んで、僕なりの整理をしていきたいと思います。

This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント

アジェンダ

This is Leanを読んでは以下のアジェンダについて、複数の投稿に分けていこうと考えてます。

1. リソース効率とフロー効率について
2. 両効率を同時に満たすことはできない
3. Leanとは

今回は、1. リソース効率とフロー効率についてをまとめていきます。

リソース効率とフロー効率について

リソース効率

リソース効率とは、従来効率と呼ばれる多くの場合に意味しているものとなります。具体的には、ある業務を担当している担当者に対して稼働率が100%に近づくように担当業務を割り振るための効率化を指します。 つまり、ある価値を生じさせる機能(人、機械など)にスポットを当てた効率性となります。 多くの企業において、セールス部門、エンジニアリング部門、企画部門など、機能ごとに組織化してこのリソース効率を高めるための構造を構築しています。

Scrumにおけるリソース効率

リソース効率という観点から、Scrumを見ていくことにします。以下の図の通り、あるScrumチームにはInfra engineer、Backend engineer、Frontend engineerがいると仮定します(engineerの名称については簡略化のためこのように記載しております、ご容赦ください)。それぞれのPBI(Product Backlog Item)には、各種Infra、Backend、Frontendに関するタスクが存在します。リソース効率を念頭において各PBIに取り組むとすると、担当であるタスクに注力することとなります。

Scrumにおけるリソース効率

例えば、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で実践しているプラクティスの背景や動機を考える上のスタートラインとしての意義はあったのかな、と個人的には思ってます。 僕が整理したい部分にフォーカスしてますので、網羅性などはあまりありませんが誰かのお役に立てれば幸いです。

はじめに

お礼

数あるブログの中から、このブログにアクセスしていただき、ありがとうございます。 本投稿では、今後どのような内容を記載していこうかということを簡単ですがお伝えできればな、と思っています。

このブログの目的について

記載内容

基本的には、ソフトウェア開発についての内容を記載していこうかと思ってます。 ただし、そこまで大仰な話しではなく、僕自身が実際に手を動かしていく中で直面した壁などについて、備忘録的に書いていきたいです。 どこかで、僕が体験したことと同じような壁にぶち当たって、困っている方の一助になれれば幸いです。

更新頻度

仕事などの関係から多少前後はするかもしれませんが、1週間に1回は更新したいと思います。

さいごに

継続は力なり、投稿を積み重ねることで、僕自身の知識の深化もできればいいな。 みなさん、よろしくお願い致します。