プログラマの思索

本日開催された「リーンとカンバンの本質と現場改善 〜平鍋さんと現場課題を考える〜 - リーン開発の現場 塹壕コミュニティ | Doorkeeper」に参加してきた。

「リーン開発の現場」の裏話が聞けるかなと期待していた。
平鍋さんの話がとても面白かったので、メモした内容をそのままアップしておく。
感想をラフなメモ書き。

【参考】
リーンとカンバンの本質と現場改善 ?平鍋さんと現場課題を考える? - リーン開発の現場 塹壕コミュニティ | Doorkeeper

【1】現場は現れる

ヘンリックがかんばんを試しているうちに、アジャイルが現れた。
計画して出てきたわけではない。
経験して適応して、プロセスは出現する。

【2】リーンは分かりにくい

何故リーンは分かりにくいのか？
XPやScrumのようなプラクティスがないから、と。

XPなら、テストファースト、継続的インテグレーション、ペアプログラミング、ソースの共同所有などの具体的なプラクティスがある。
Scrumなら、プロダクトバックログ、デイリースクラム、スプリントレビュー、スプリントデモなどのプラクティスないし規律がある。
だから、そのプラクティスを使っていれば、自然にそれらの概念の本質を体で経験することができる。

でも、リーンにはそのような実践的なプラクティスがない。
6つの無駄、サイクルタイムの短縮など、抽象的な概念ばかり。
だから、分かりにくい、と。

この話を聞いて、リーンが分かりにくい理由がようやく分かった。

【3】スターバックスにおけるリーンサービスの例

TPS→リーン生産→リーンシンキング　の流れで抽象化されて、
リーンサービス、リーン製品開発、リーンソフトウェア開発へ発展した。

スターバックスではリーンを取り入れたリーンサービスを実践しているらしい。
例えば、オペレーションの効率化。
顧客の待ち時間を減らすために、リーンサービスを導入した。

でも、それだけが本質ではない。
オペレーションを効率化して、顧客と話しサービスする時間を増やしたのだ、と。

【4】製造業ではムダを指さすことができるのに、ソフトウェア開発ではムダが見えないので指差しできない

トヨタのコンサルタントは、工場の現場で、止まっている物を指差す。
これはムダでしょ、と。
ソフトウェア開発では、ムダが見えない。
だから、ムダな物を指差すことができない。

いかにムダを見えるようにするか。
その手法の一つがかんばんだ、と。

【5】リトルの法則

WIP＝LeadTime * Throughput

WIP：中間在庫
LeadTime：待ち時間
Throughput：生産性

⇔LeadTime＝WIP/Throughput

同じThroughputならば、WIPを減らせば、LeadTimeが短くなる。

【6】WF・Scrum・Leanに対し、リトルの法則による比較

WF型開発では、1年かけて作って、最後に1回だけのリリース。
Scrumは、1スプリント1ヶ月の単位に、順次リリース。
リーン開発では、1個ずつ1日毎にリリース。

リトルの法則の変数は、下記の比較になる。

変数	WF	Scrum	Lean
WIP	365個/年	30個/月	1個/日
LeadTime	1年	1ヶ月(1スプリント)	1日

注意する点は、WF・Scrum・Leanのいずれもスループットは同じであること。
365個/年＝30個/月＝1個/日だから。
つまり、同じスループットならば、WIPの量を減らすほど、1年＞1ヶ月＞1日のようにリードタイム(サイクルタイム)は短くなる。

平鍋さんは、WF・Scrum・Leanのリードタイムを爆弾処理に例えていた。
WF型開発は、大きな爆弾を分析→設計→実装→テストの工程ごとに、ドカンと渡す。
後工程に行くごとに爆弾が破裂するリスクが高くなり、最後のテスト工程で、ビッグバンテストで爆発して死人も出る。

Scrumでは、中くらいの爆弾をスプリントごとに渡す。
最初は慣れていないので、爆弾が破裂して、死人は出ないが、けが人は出る。
でも、スプリントを経るごとに、爆弾を渡す時は相手の目を見て渡す、とか、爆弾が破裂しないようなノウハウを経験して、爆弾の扱いがうまくなっていく。
Scrumで言われる適応と検査に相当する。

Leanでは、セル生産のように、スモールバッチで小さな爆弾で渡す。
けが人も出ないし、小さいからスムーズに渡せる。

【7】リトルの法則の応用例

平鍋さんから質問。
大野市は4万人いるが、1日何人亡くなるでしょうか？
あるいは、1日何人の赤ん坊が生まれるでしょうか？

回答は、1人の人間の平均寿命が80年とすれば、リトルの法則を使うと、
4万人/80歳＝500人/年＝1～2人/日。

この数値は、生まれる赤ん坊と死ぬ人がほぼ同率であるという前提だが、ほぼ当たっているらしい。
リトルの法則は色々使えるよ、という例。

【8】Scrum・Kanban・セル生産の共通点はWIP

アマゾン川を例に出す。
アマゾン川の河口が最終製品だとすれば、支流は前工程。
それだけたくさんの支流にある部品が必要。

Scrumでは、スプリント単位にWIPを制限する。
Kanbanでは、流量(フロー、物の流れ)でWIPを制限する。

つまり、河口から支流へ、製品が売れるたびにマーケット情報を送って、部品を河口側が引き取る。
すなわち、プル生産。
後工程の信号が来るまで、前工程ではムダな在庫を作らない。

プル生産の標語は、Stop Starting, Start Finishing。

セル生産では、1個作りで後工程に流す。
例えば、屋台。
屋台では、一人がソーセージを焼き、マスタードやケチャップを塗り、販売する。
一人でいろんな作業を触れて、顧客の好みに気付く。
今日はマスタードを塗ったほうが売れる、とか。

【9】方法論の終焉(End of Methodology) by Alistair Cockburn

End of Methodology (日本語訳)：An Agile Way：ITmedia オルタナティブ・ブログ

かんばんを使った現場は、どこも違う。
一つの方法論がすべての現場で使えるわけではない。

標準プロセスはいらない。
ふりかえり改善フレームワークで、経験的プロセスをそれぞれの現場で作っていく。

【10】ブラジルの受託アジャイルの事例

ブラジルでは、アメリカと時差が同じなので、アメリカからのソフト開発の受託案件が多い。
でも、100％アジャイル。

顧客のロゴを各チームに旗として飾る。
チケット管理システムからチケットを印刷して、かんばんに貼り付けて、かんばんでタスク管理する。
リリースしたら、シャンパンで乾杯する。
その後のふたを貯めている。

【11】Kanbanの良い所

かんばんを見れば、タスクは「ここ」にあります。
あと2週間でリリースできます。
と言える。
「ここ」「あそこ」と指差すことができる。

平鍋さんの現場で使うかんばんでは、ToDo→Doing→Doneではなく、ToDo→Doing→「Accept」にしたらしい。
Doneにしても、手戻りが発生する場合があり、Doneとは言いがたい。
最後のアクセプタ(Doneを判定する人)が受け取った状態を「Accept」としたらしい。

これは面白い。
Doneの定義は、Scrumでも言われるように、チームごとに違う。
しかも、チームが成長するたびに、Doneが定義する範囲は広がる。
定期的なふりかえりで、Doneの定義をいつもチェックすると良いのだろう。

【12】平鍋さんへの質問「SIでは、リーンの考え方は人減らしに使われてしまい、チームを生き生きさせる方向に向かないのではないか」に対する回答

僕は、ソフトウェア開発におけるリトルの法則については、以前色々考えた。

チケット駆動開発におけるサイクルタイムの計測方法～リーン開発で最も重要なメトリクス: プログラマの思索

「リーン開発の現場」の感想part4～トレーサビリティ、プロセスサイクル効率、構成管理: プログラマの思索

「リーン開発の現場」はアジャイルサムライの再来となるかpart3～サイクルタイムとリトルの法則の関係: プログラマの思索

ソフトウェア開発におけるリトルの法則は、下記になる。

CycleTime＝WIP/Velocity

・CycleTime：1タスクの平均完了日数。
　→チケット駆動なら、1チケットの平均完了日数。バグチケットなら平均障害修復時間(MTTR)を指す。
・WIP：開発チームの仕掛中のタスクの最大個数。
　→チケット駆動なら、開発チームが手をつけている着手済みチケットの最大枚数。
・Velocity：開発チームのタスク消化能力。
　→チケット駆動なら、1スプリントにおける完了チケットの平均枚数。開発チームが1スプリントで消化できるチケットの枚数を指す。

この公式から分かることは何か？
開発チームが作業に着手できるチケットの枚数には限界(つまり、WIP)があり、リトルの法則から論理的に計算できる。
チケット駆動開発ならば、サイクルタイムやベロシティというメトリクスは簡単に計測することができる。
実際、サイクルタイムは、チケットの開始日から終了日までの期間の平均値。
ベロシティは、1スプリントという一定期間における完了チケットの平均枚数。

すると、WIPはサイクルタイムやベロシティから計算できるので、開発チームが手を付けることができるチケットの最大枚数が導出される。
その意味は、開発チームはWIPという数値以上のチケットを抱えられないと言う事実であり、WIPを超えるほどのチケットがあっても、開発チームは消化できないのだ。

チケット駆動開発を実践すると、普通は、チケットがどんどん溢れる。
100枚、500枚の未完了チケットがバックログとして積まれている状態は普通だ。
しかし、リトルの法則が教える所では、開発チームがリリース可能なバックログとして選択できるチケットの枚数は、WIPというメトリクスによって、限界がある。

例えば、サイクルタイムが5日/枚、ベロシティが5枚/週の開発チームが、100枚の未完了チケットを抱えていたら、約1～2年分のチケットを抱えていることになる。
開発チームのWIPとしては、25枚/週程度になる。
それ以上のチケットがあったとしても、着手できずにキュー(待ち行列)として無限に溜まっていくだけだ。
つまり、開発チームの能力に応じて、WIPを減らす必要があり、チケットを捨てるか選択する必要がある。

サイクルタイムを短くすることは、アジャイル開発にとって重要な意味を持つ。
その理由は、サイクルタイムは文字通り1チケットのリリース間隔であり、サイクルタイムが短ければ、1機能1チケットをより早くリリースできる。
リリース間隔が短いほど、頻繁にリリースできるから、市場の状況や経営判断に応じて、柔軟にリリースする機能を取捨選択する余裕も生まれる。
この考えは、「リーン開発の本質」で言われる「オプション」「最終責任時点」の話につながる。
つまり、即座にリリースできる能力があるからこそ、選択肢を数多く持つことができるから、リスクを減らすことができる。

リトルの法則に従うと、サイクルタイム(リードタイム)を短くするには、WIPを減らせば良い。
すると、WIPを減らしすぎると、作業量が減るので、暇な人が生まれる。
つまり、ソフトウェア開発者の稼働率は落ちる。

平鍋さんの話では、リーンを実践すると、無駄な作業をする人が減る。
この現象を省人化と言うらしい。
つまり、ある製品の工程で人が余れば、ボトルネックとなる別の工程へ人を配置して、柔軟に変えていく。
すなわち、人は多能工になる。

しかし、SIにとって、SEやPGの稼働率は人月商売の要だ。
普通は、チームの生産性が上がり、人が余るようになると、火が噴いている別プロジェクトの応援に駆り出される場合が多い。
すると、せっかくチームとして上手く回っていたのに、抜けた人の役割を別の人がカバーせざるを得なくなるので、チームのバランスが崩れてしまう。
何よりも、チームの精神的雰囲気も悪くなる。

SIでリーンの考え方を導入すると、確かにソフトウェア開発のリードタイムは短くなり、無駄な作業をする人も減るだろう。
でも、リーンがSIでは人減らしに使われる危険は無いのか？

そんな質問を平鍋さんにしたら、こんな回答があった。

リーン製品開発やリーンソフトウェア開発の考え方としては、垂直方向(バーティカルライン)に人が動く。
例えば、開発工程で人が余り、テスト工程で人不足でボトルネックになっていたら、ボトルネック解消のために人がテスト工程に移って、支援する。
この現象を応受援という。
つまり、暇な人の労力を振り分けて応急の手助けをしていることになる。
製品単位、顧客単位に人が上下の工程に動く。

でも、SI業界では、水平方向(ホリゾンタルライン)に人が動く。
例えば、暇な人ができると、火が噴いている別プロジェクトにアサインされてしまう。
人はプロジェクトを転々と渡り歩く。
でも、リーンの本来の考え方は、顧客単位に人が動く。

SIの請負契約のせいですかね～と言われていた。

【13】「リーンはプラクティスがないから分かりにくい」「同じThroughputならWIPを減らせばLeadTimeは短くなる」という話は分かりやすかった。
リーンの考え方は6つのムダのような話もあるが、僕としては、リードタイム(サイクルタイム)というメトリクスを中心として、リーンの構造を探ってみたいと考えている。