「リーン開発の現場」はアジャイルサムライの再来となるかpart2～重要な概念は仕掛り(WIP)とサイクルタイム

ヘンリック著「リーン開発の現場」の感想をラフなメモ書き。

【1】「リーン開発の現場」で最重要の概念は「仕掛り(WIP：Work In Progress)」である。
僕もレビューに加わったのだが、WIPをどう訳すか、という問題を翻訳者の藤原さんや市谷さんだけでなく、レビューアも巻き込んで議論となった。
「リーン開発の現場」の翻訳書では、WIPという単語をそのまま表現し、脚注で「仕掛かり」と記載されているが、僕は、WIPのような英単語ではなく、仕掛かりという日本語で表現すべきだったと考えている。
その理由を、以下、色々書いてみる。

【2】理由の一つ目は、会計簿記の観点だ。

工業簿記(簿記2級)の観点では、工場では原材料→仕掛品→製品の流れでモノが作られる。
原材料を仕入れて、仕掛品という未完成の中間物を経て、製品という完成品へモノが価値あるもの(実際は売上計上されるもの)へ変わる。

仕掛品という言葉には、工場ないし倉庫で、まだ完成途中のモノで、100％の価値があるわけではないが、少なくとも資産価値はあるものとして捉えられる。
実際、工業簿記では、仕掛品という科目は資産科目になっている。

「リーン開発の現場」本を読むと、ユーザから収集したフィーチャ(機能)から仕掛中のタスクやシステムテストを経て、ソフトウェアが作られる流れだ。
その場合、仕掛品に相当するものが「かんばん」で表現されているストーリーやタスクなどに相当する。
アジャイル開発の観点では、それら仕掛品はソフトウェア開発においては価値がない(未完成のソフトウェアはユーザの要望を満たすものではなく、全く価値がない)という主張が、ソフトウェア特有の観点であり、従来の製造業と違う点だと思う。

餃子の王将を例にすれば、玉ねぎや小麦粉が原材料で、生の餃子や餃子の皮が仕掛品、焼き餃子や水餃子が製品に相当するだろう。
但し、餃子の仕掛品は単品でも売れる(つまり価値がある)所にソフトウェア開発とは違う特徴がある。
でも、生の餃子(仕掛品)は焼き餃子や水餃子(製品)よりも安いので価値は低い。

会計知識のある方が「WIPとは仕掛中のモノ(仕掛品)の状態だよ」と聞けば、似たような概念として認識しやすくなり、かつ、ソフトウェア特有の考え方にもなるほどと思ってもらえるのではないか、と考えている。

ここで、製造業の場合は、餃子の王将の例のように、仕掛品である生餃子や玉ねぎや肉などの原材料は、価値は低いけれども資産価値があるという点に注意しよう。
製造業などのビジネスでは、製造工程で作られる仕掛品や廃棄物などの副産物を、他の業者に転売できたり、他の工程に再利用できれば、多少なりとも売上を上げることができる。
実際、工場では、廃棄物を燃やして廃熱を発電に使ったり、廃棄物を牛などの飼料にするなど、副産物を再利用する方法がある。

副産物を再利用することができれば、無駄な在庫が発生したとしても、転売できる手段があれば、在庫の価値は少なくともゼロではない。

しかし、製造業では製造工程で作られる仕掛品などの副産物を有効活用できる場面があるのに対し、ソフトウェア開発では、開発工程で作られる作業中の設計書やプログラムの断片、テストスクリプトは正直余り価値がない。

例えば、リリースされておらず、総合テスト中のモジュールやライブラリは、まだ障害が残っている可能性もあり、そのままでは使えない。
むしろ、どこまでテストすればリリースできる品質になるのか、という調査工数もいるし、回帰テストや障害修正の工数も余分にかかる。
テスト工程で作られたテストスクリプトやビルドスクリプトも、参考にはなるけれど、そのスクリプトが別のシステムでそのまま使えるわけではなく、中身を調査して、流用できる部分とカスタマイズする部分を区別して開発し直す必要がある。

つまり、ソフトウェア開発では、仕掛かり中の機能、それに派生する設計書やモジュール、ライブラリ、スクリプトなどの副産物は、そのままでは再利用しづらい。
ソフトウェアを再利用するには、工数がかかりすぎるのだ。
それだけの工数を投入するのが難しい場合、再利用できないために、最初からスクラッチで開発した方がマシという決断もありえる。

だから、ソフトウェア開発では、仕掛かり中の機能やそれに派生する成果物は、価値がゼロと見なした方が、無駄な作業が発生しづらいという場面があるのだろう。

【2】もう一つの理由は、製造業のかんばんの観点だ。
製造業におけるかんばんの観点では、ソフトウェアかんばんに出てくるタスクカード(又は障害管理票)は仕掛かんばんに相当するという話がある。
例えば、「実践 反復型ソフトウェア開発」のP.207「トヨタかんばん方式とバグ追跡方式」を参考にしてください。

本来の製造業のかんばんでは、仕掛かんばんが工場内部の製造指示書に相当し、工場の各工程で加工される仕掛品という現物とセットで仕掛かんばんが渡される。

仕掛かんばんが仕掛品という未完成の現物と必ずセットで動くことから、例えば、
「かんばんなしでは部品の生産は開始しない」
「かんばんに書かれた製造方法と品質を満たさなければ後工程に回さない」
「工場内に流通するかんばんの量を制限することで在庫を減らし、作業負荷を下げる」
などの幾つかの特徴が出てくる。

この特徴は、今回の本に書かれているソフトウェア開発の「かんばん」の考え方に同一だ。
むしろ、トヨタを代表とする製造業のかんばんが発生源で、そのアイデアをソフトウェア開発に適用して派生した特徴でもある。

つまり、製造業のかんばんの考え方に慣れている人にとっては、「仕掛り」という言葉からWIPが意味することを理解できるだろうし、ソフトウェア開発にも同様に適用できることを理解してもらえると僕は考えている。

【3】製造業におけるかんばんをカイゼンの道具として扱う場合、故意に仕掛かんばんの枚数を減らすことで、仕掛かんばんとセットになっている仕掛品を減らす方法がある。
この手法の意図は、在庫を意図的に減らすことで、ボトルネックを故意に出現させて、課題を明確にすることだ。

TOCが教える所では、ボトルネックの生産能力が全体プロセスのスループットを決めるので、ボトルネックの工程が中断しないように稼働率を維持するようにすれば、他のプロセスは特に気にしなくてよい。
逆に言えば、在庫を減らしてもボトルネックも課題も出なければ、無駄な在庫が多すぎたという話になる。
「工場内に流通するかんばんの量を制限することで在庫を減らし、作業負荷を下げる」と書いた話はその意味になる。

今回の本では、WIPが仕掛り作業(仕掛品)を意味していて、11.1節「WIPの制限を活用する」という所で同様の手法が書かれている。
ヘンリックも、WIPの数をコントロールすることで、機能をたくさん開発し過ぎてテストに作業負荷がかかり過ぎないようにしたり、チームの稼働率を100％にし過ぎないようにすることに注力しているように思える。

実際、機能をたくさん開発しても、テストチームがテストできる機能の量よりも多ければ、テスト待ちの機能が発生し、そこでテスト待ち時間が発生する。
開発できてテスト待ちと言う仕掛かり中の機能をたくさん作ることは、無駄な在庫をたくさん作っているのと同義なのだ。

ヘンリックの意見が興味深い点は、機能(フィーチャ)はWIPで制限するが、バグや技術課題はWIPの制限対象でないことだ。
11.2節「なぜ機能開発だけWIP制限するのか」に記載のように、バグは緊急かつ重大な場合があるのでやむを得ずに優先する場合がある。
技術課題は、それを解決すると、後続のプロセスのボトルネックが解消するために、技術課題のWIPは制限しない。
解決によって別のプロセスへボトルネックが移動するからだ。

実際、UIの障害を一通り解消した後、性能要件の障害がクローズアップされてくるなどの場合もあるだろう。
つまり、障害や作業の優先度によって、プロジェクトのボトルネックはどんどん変わる。

では、機能のWIPが満杯の時、暇になった開発者は、どうすべきか？
ヘンリックが言うように、TOCが教える内容と同様に、ボトルネックになったプロセスの作業を手伝ったり、技術課題の解決に従事したりして、チーム全体でボトルネックの作業に注力するのだ。
この場面で、アジャイル開発の信念である「人重視」「チーム重視」が有効に活きるのだろう。

【4】在庫管理の業務では、倉庫に残った製品や仕掛品の数量だけでなく、リードタイムの計算がとても重要だ。
ある工程の生産性がいくら高くても、必要な部品や機材が揃っていなければ、後工程に必要な部品を納期までに揃えることができない。
作業前に、必要な部品や機材を発注して納品してもらうことも必要だからだ。
リードタイムは普通、作業時間だけでなく、発注や納品にかかる期間(リードタイム)や検査・運搬そして作業待ちの時間も含まれる。
リードタイムを計算することで、スケジュール管理がやりやすくなるだけでなく、顧客に的確に納期回答できる利点がある。

小売業や生産管理の業務システム開発に携わった経験がある人なら知っていると思うが、リードタイムの計算ロジックはとても難しいし、業務の中で最も重要な機能の一つだ。

例えば、餃子の王将のように、原材料が食材で発注する場合、食材は倉庫で保持できる期間がとても短いため、納品したらすぐに餃子を作って全て売り払わないと、せっかく仕入れた食材が腐ってしまって無駄になる。
シャンプーやペンのような商品とは違って、普通の生鮮食料品は1週間も持たないからだ。

だから、販売日にこれだけ売れると見込み生産の計画を立てて、食材の発注リードタイムや作業時間、検査時間などを計算することで、玉ねぎや肉などの食材がいつどれだけ必要かを予測する。
王将の店の休業日に食材が納品されても困るし、調理場に溢れんばかりの食材が届いても困るので、食材の発注リードタイム計算は結構シビアだ。

12.3節「サイクルタイム（1機能にかかった開発時間）」に出てくるサイクルタイムは、1機能にかかった作業時間のことだが、リードタイムと同義だと思う。
例えば、ある機能を開発するには、別チームが作ったライブラリが必要だったり、特殊なテスト環境が必要だったりする理由で準備時間がサイクルタイム(リードタイム)に含まれるだろう。
あるいは、テストデータのパターンが多いために、回帰テストの時間を別途増やすなど、検査の時間もサイクルタイムに含まれる場合があるだろう。
サイクルタイムには純粋な作業時間だけではない場合もあると思う。

ヘンリックの意見で興味深いのは、サイクルタイムを減らすには、WIPを制限することだ。
機能のWIPが大きいほど、サイクルタイムに準備時間や作業待ちの時間が多く含まれて、実際の作業時間は少ない場合があるからだ。
だから、一つの機能の開発に集中できるように、WIPを制限してマルチタスクを避けて、他チームが作るライブラリの完成までの待ち時間を避けるように運用するのだと思う。
つまり、全てのリソースを一つの機能の開発またはボトルネックの作業に注力できる環境をWIP制限で実現しているのだ。

サイクルタイムの計測に意味がある理由は、おそらくソフトウェア開発の現場は製造業とは違って、開発環境の準備やライブラリの準備などの作業待ちが多く、仕様漏れによる手戻り修正などが多発しているために、価値あるソフトウェアを作っている作業時間が極端に短い事実を示しているのだろう。

だから、「リーン開発の本質」でメアリーが提唱するバリューストリームマップは、サイクルタイムが何故長いのか、を分析する道具の一つとして使われているのだろうと推測する。
バリューストリームマップは、ある作業の処理時間が作業中の時間か作業待ちの時間かを判別するマップだ。
バリューストリームマップを使うと、作業中は価値を作成している時間帯として意味があるが、作業待ちの時間は何も価値を作り出していないので無駄であり、排除すべきだと言うことが分かる。

そして、ソフトウェア開発では特に、作業待ちの時間が多すぎるというのが最大の特徴だろう。
実際、たくさん機能を作ったのにテストチームの作業が手一杯でテスト待ちの機能が大量に発生したり、せっかく設計書を作ったのにレビューアが手一杯でレビュー待ちの設計書が大量に発生して手戻りが後で大量に発生する場面などがあげられるだろう。
いかにテスト待ち、レビュー待ち、開発待ちなどのような、無駄な作業待ち時間を減らすか、がソフトウェア開発では特に重要になってくる。

サイクルタイムの概念が重要なのは、作業待ち時間を減らすことで、サイクルタイム(リードタイム)が短くなり、頻繁にリリースできる仕組みがそろうからだ。
サイクルタイムは、リリース頻度と大きく直結する。
頻繁にリリースできる開発プロセスになれば、安定してアジャイルに開発できるようになる。

次回は、サイクルタイムの計算方法と待ち行列理論の関係について考えてみたい。