「リーン開発の現場」はアジャイルサムライの再来となるか

ヘンリック著「リーン開発の現場 カンバンによる大規模プロジェクトの運営」の翻訳がついに出版されました。
藤原さん、市谷さん、お疲れ様でした。

ざっくり読み直した感想をラフなメモ書き。
ネタバレを含んでいるので、読んでない人は注意。

【1】内容はとても読みやすいです。
スウェーデンの公共システムという大規模プロジェクトに対し、アジャイル開発を適用した事例のお話。
カンバンを使って、アジャイル開発を補強している。
内容がとても実践的なので、何となくアジャイルサムライの本を予感させる。

「リーン開発の現場」のカンバンは、XPやスクラムで出てくるタスクボードとは違う。
「リーン開発の現場」のカンバンは、機能ボード、フィーチャかんばんだ。
(但し、タスクボードに相当するタスクかんばんも出てくる)

つまり、開発者の作業(タスクカード)を管理するタスクボードではなく、ユーザ観点で機能(ストーリーカード)を進捗管理するカンバンがこの本の主役であり、カンバンをいかに効果的に使うべきか、カンバンを使うと以前とはどのように違う効果が出てくるのか、が主題テーマだ。
だから、プログラマの観点よりも、発注者のユーザやプロジェクトリーダーの立場で見た方が分かりやすいと思う。

Twitter / akipii: 「リーン開発の現場 カンバンによる大規模プロジェクトの運営」の日本語版解説(@hiranabeさん)がとても分かりやすい。どの本でも平鍋さんの解説を読むと本の内容を読まなくてもエッセンスがすぐにつかめるのがすごい。 http://www.amazon.co.jp/dp/427406932X

【2】ヘンリックが運用しているカンバンは、XPやスクラムが定義するタスクボードよりも複雑だ。
タスクボードは、ToDo→Doing→Doneの3つしかステータスがない。
ヘンリックが運用しているカンバンでは、少なくとも下記のフェーズ(ステータス)がある。

・アイデア
・機能
・開発準備OK
・次の10機能
・開発中
・システムテスト準備OK
・システムテスト中
・受入テスト準備OK
・受入テスト中
・本番リリース前
・本番リリース完了

見ての通り、フェーズが多く、その仕組みがウォーターフォールプロセスのように見えてしまうかもしれない。
しかし、ウォーターフォールプロセスとは大きく違う。

WF型プロセスでは、前工程の作業が全て完了して初めて後工程の作業が始まる。
しかし、カンバンシステムでは、各フェーズは並行して動く。
実現したい機能はアイデアとして生まれ、開発できる単位まで分割されて詳細化されると、機能単位で開発されていく。
開発着手の前に、すべての機能が出そろう必要はない。
機能(フィーチャ)単位に、カンバン上をフローとして流れていく。

ヘンリックが運用しているカンバンは、アイデアで生まれた機能が仕様化され開発され、システムテストや受入テストを経て、リリースされて実現されるので、Push型だ。
本来のかんばんは、マーケットが必要とされる製品に必要な部品が前工程にPullされることで各工程に波及していくので、その違いはある。

第4章プロジェクトボードにその理由が詳しく書かれている。
更に、ヘンリックが運用しているカンバンは、下記のような彼独自の特徴がある。
この辺りも「リーン開発の現場」に詳しく書かれている。

・アナリスト、テスターを機能開発チームに所属するものの、彼らだけの仮想的なチームをなしていること。
・デイリースタンドアップミーティングを3階層で分けて、プロジェクト内の風通しを良くすること
・プロジェクト全体とチームのタスク管理の観点を、プロジェクトかんばんとチームかんばんで使い分けること
・WIPをうまく使うことで、タスクが溢れることがないように調整していること
・技術課題やバグは別のかんばんで試すこともできる(カンバンのスケールアップにもつながる)

【3】カンバンで最も重要な概念がある。
それはWIP(Work In Progress)、つまり、仕掛り中の作業、仕掛中の機能だ。

「第11章 WIPをマネジメントする」「第12章 プロセスメトリクスを計測し活用せよ」は内容が濃くて面白い。
生産管理では、かんばんの枚数を減らして在庫を減らすことで問題を具現化させて、改善していく手法を取ると聞くが、WIPも似たような考え方があると思える。
リトルの法則や「最も小さくて小さ過ぎない」ようにWIPを設定するの説明は、この本で最も興味深い内容の一つだ。

WIPが重要な理由は、稼働率が高すぎても低すぎても生産性が上がるどころか、むしろ下がってしまうため、生産性が最も高くなる時点の稼働率にするのにWIPの概念が使われるからだと思う。
実際、稼働率100％のプロジェクトは、チーム全員が毎日残業して休日出勤も強いられているために、たくさんの障害が頻発し、レビューもテストもろくに行われておらず、品質がボロボロだろう。
逆に、稼働率が低すぎるプロジェクトは、暇な開発者が多すぎて、肝心の成果物が全く作られておらず、進捗が遅延しているだろう。

つまり、「最も小さくて小さ過ぎない」ようにWIPを設定する。
第12章プロセスメトリクスでは、「WIP制限を必要最低限に保つ」という文章で記載されている。
(個人的には、「必要最低限」という言葉よりも「最も小さくて小さ過ぎない」の方が好きだ。)

ヘンリックは、カンバン上のフローをスムーズに流すために、WIPを制限することで、サイクルタイム(リードタイム)を短くすることで、機能をリリースする期間を短くしている。
つまり、頻繁にリリースできるような仕組みを作るために、WIP制限を有効に使っているのだ。

Twitter / akipii: 「リーン開発の現場」の最重要キーワードはWIP。WIPは着手中の未完成の機能や作業。WIPは稼働率を意味すると思う。待ち行列理論から類推するとWIPは大きすぎると皆忙しすぎて作業待ち時間が増えて生産性が減る。逆にWIPが低すぎると皆暇すぎて生産性が減る。ほどほどのWIPが重要。

ヘンリックは、カンバンを高速道路の交通量に例えている。
車の流れをスムーズにしたいと思うならば、高速道路に車をぎっしり詰めるべきではない。
高速道路で渋滞が発生するのは、本来の交通量を超えた車が道路に溢れているから。
だから、交通量の変化を吸収して、流れを速くするには、スペースやゆとり(Slack)が必要。

Twitter / akipii: 「リーン開発の現場」を読むとカンバン中心のプロジェクト管理の本質には、リトルの法則または待ち行列理論が背後にあるのが分かる。カンバンを高速道路の交通量にたとえて、タスクの消化を早めるには、交通量(WIP)を制限してスペースを作ることと同じと言っている。この比喩は本質的だと思う

また、WIP制限(仕掛中の機能・作業の上限値)が必要な理由をプリンタにも例えている。
プリンタは一度に1枚しか印刷できないので、WIP制限は1になる。
もし紙が詰まれば、警告を出して、速く修理すべきだ。
逆に、より多くのページを印刷しようとプリンタのキューに貯めこむのは、プリンタ故障の問題をより大きくさせるだけ。
WIP制限によって、プリンタが処理できる本来の能力を実現しているわけだ。

Twitter / akipii: リーンの言葉で言えば、XPやスクラムはタイムボックスという期間で在庫を制御する。カンバンは仕掛り作業(WIP)を直接制限することで在庫を制御する。「リーン開発の現場」の@hiranabeさんの解説より　http://www.amazon.co.jp/dp/427406932X

【4】レビューにも参加させて頂いて、今読み直してみて、まだまだ奥が深いと感じる。
そして、まだ僕がカンバンを経験していないために理解できていない問題は2つある。

一つは、ヘンリックが運用しているカンバンは、日本のトヨタが生み出したかんばんとどの部分が似ていて、どの部分が異なっているのか？
いわゆるソフトウェアかんばんが、製造業のかんばんとは異なる本質的な特徴や性質は何か？
欧米人が「かんばん」を彼らなりにどのように理解してソフトウェア開発へ適用したのか、を明確にしたい。

もう一つは、生産性や稼働率が待ち行列理論からどのように分析されて説明できるか？
カンバンがソフトウェア開発の進捗管理でとても有効な理由は、生産性や稼働率の見える化が強力であるからだと思う。
カンバンを使うと、WIP制限によって、稼働率を調整することでリリースサイクル(サイクルタイム、リードタイム)を短くでき、それによって、頻繁なリリースを安定して実現できる。
その仕組みの背後には、待ち行列理論が関係していると直感しているので、その構造を明らかにしたい。

上記の問題意識で、更に読んでみたいと思う。