エッセンシャルスクラムとリーン開発の現場という本を読んだ。ざっと読んだくらいだが、ここで私が重要だと思った概念をメモっておく。

1. 基本思想

2. リーン開発の重要概念

Batch

バッチは小さく保つべきである。

WIP制限

仕掛け中のものは経済的妥当のサイズを保つべきである

例

WIP limit = 3
A B C 完了後 → D開始

重要な理念としては「作業者手待ちではなく作業手待ちをなくせ」。 JTC的組織の場合、タスクアサインは並行して「全部やらせよう」とする。結果次のようになる。

A 80%  
B 50%  
C 30%  
D 10%

リーン的思想の場合は、このシチューエーションでは、「Aをさっさと片付ける」ことを重視する。

A 完了
↓
B
↓
C

一部の作業者が少し暇なことは、リーン開発ではむしろ「好ましい」と考えられる。なぜなら、作業がすぐ流れる（フロウする）からだ。これがStart less, Finish moreの思想につながる。

3. 開発指標

遅延は重要だが、本来計画は次の発想によってなされることが重要だ。つまり、計画は固定性は重要ではない。

Decide as late as possibleと言っているのは、「早く決めるほど、間違う確率が高い」と相場が決まっていることからである。つまり、「情報は集めよ、状況の変化は待て」と言っている。

「リーン開発の現場」によれば、計画遅延の理由には「無駄な要求がないか」などのプロセスの問題はままあることとプラクティスで挙げられている。

目指すべきところとしては、「ベロシティは週安定していることが望ましく、サイクルタイムは短く」があるべき姿だ。

Leanの基本法則

Little’s Law

結論

WIPを減らすと効率は上がる　（あらゆることをマルチタスクで進めるな。さもなければ、全て遅延する。集中せよ）

4. スクラム開発の構造

スプリント計画のバックログでは、

• 1. ユーザーストーリー
• 2. 技術ストーリー

を記載するべきだが、1は重視するべきである。なにより、「価値（value）」に重きを置くべきなのが主張。

ストーリーはMike Cohnによれば、次のようにするべきである。

As a <ユーザー>
I want <やりたいこと>
So that <得られる価値>

恐らく、SI現場では「So that」があまりに不明確なことが多く、だからこそ困惑しがちになりがちではなかろうか。

つまり、タスクの捌く順序とは、次のようにするべきである。

5. デイリースクラム

スクラム理論にとって、朝会は重要である。

目的

チームの作業調整

ここでのBlockerとは、つまり作業が止まる要因のことだが、例えば1つとしては「外部要因」だ。

SI現場で分かりやすいのは、「AWSとかX部署に問い合わせてるから、その対応を待っている」といったようなことである。

ルール

考察としては、以下のものが言えるであろう

6. リーン・スクラムの核心

総じて、以下のようなことが言えるであろう。

つまり

仕事を増やすな。流れを改善せよ。

7. マインド

自己組織化が重要であると考えられており、銃士の姿勢（ All for one and one for all )は重視される。これは共同責任 (Collective Ownership)とも言う。

実際にはSI現場もそうであるはずであり、契約だのなんだの言い始めるのは、ほぼ自己破滅の兆候である（しかし、お偉方ほどそれで対応だと考える）。顧客はPJを見ており、プライムはBPを見る。我々は、どこまで切り取っても店の顔にしか結局ならない。役割論と責任論を言い出すと何の改善にもならない。
そのような動きでツケが回され理不尽を被るのは、結局常に現場の人間だということだ。まるで何の足しにもならない、現場を知らない人間の「べき論」に何も期待してはならない。我々に必要なことは、最上層の顧客を向いて何がベストかの仕事をすることだけだ。
また、誤解してはならないのは、「困っている人を助けよ」だがサボってる人を助けよではない。 ここで言ってるのはそれぞれのOwnershipは果たせと言っているのだ。

そして、メンバが真に把握するべきものはバックログの全てではない。 実際には焦点を当てられるべきは、Sprintである。

8. まとめ

SI現場の視点から、以下のようなものがリーン・スクラム的プラクティスとバッドプラクティスと言えるだろう