「リーン開発の現場」の感想part6～累積フロー図は生産管理の流動曲線管理または追番管理である

生産管理の記事を読んで、「リーン開発の現場」に出てくる累積フロー図は生産管理の流動曲線管理または追番管理であることに気づいた。
考えたことをラフなメモ書き。

【元ネタ】
目次 - 生産管理パッケージ導入の留意点　本間峰一：ITpro Active

リーン ソフトウェア開発～プラクティス　累積フロー ダイアグラム

第3回　何のために生産管理システムを構築するのか - 生産管理パッケージ導入の留意点：ITpro Active

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

「リーン開発の現場」の感想part5～かんばんと因果関係図がセットで運用されるのは何故か: プログラマの思索

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

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

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

「リーン開発の現場」はアジャイルサムライの再来となるか: プログラマの思索

「受注生産に徹すれば利益はついてくる」の感想～ERP普及が上流工程の軽視を助長している: プログラマの思索

第33回関西IT勉強会の感想～製造業の基幹システムのパターンが知りたい: プログラマの思索

【1】「受注生産に徹すれば利益はついてくる」の本にも出てくる流動曲線管理または追番管理とは、工場で使われるかんばんにおいて、各工程の製造個数を時系列に集計したグラフ「累積フロー図」で在庫管理や進捗管理を行う手法。
追番管理は、戦前の中島飛行機が発祥と言われているらしい。

【1-1】流動曲線管理の特徴は、工程間の製造スピードの差、製造個数の差、滞留在庫の差、投入から完了までのリードタイムを簡単に計算して把握できること。
単純に時系列にステータス(未着手、仕掛中、完了)ごとに集計しているだけだから、単なる引き算で計算できる。
基本は、グラフの縦が仕掛かり在庫、グラフの横がリードタイム、傾きが生産能力に対応する。

つまり、グラフの横の間隔が広いほど、リードタイムが長くなり、納期が遅れる。
グラフの縦の間隔が大きいほど、倉庫に在庫がたまり、どこかでボトルネックが発生しているわけだ。

【1-2】「受注生産に徹すれば利益はついてくる」の本で、流動曲線管理または追番管理を推奨する理由は二つある。

一つ目は、生産管理システムの実績データを流用するだけで、累積フロー図を簡単に実装できること。
日次バッチで当日の実績データが確定すれば、その実績データをステータスごとに集計するだけで累積フロー図を簡単に作れる。
ERPの枠外にバッチ処理を1本追加するだけで作れるから、MRPやERPをカスタマイズして作る必要もない。

二つ目は、累積フロー図による流動曲線管理がMRPの弱点を補ってくれること。
MRPの弱点は、生産計画におけるリードタイムや納期があいまいな状況に弱い。
ちょうど、計画重視のWF型開発が仕様変更や突発的な変更要求に弱い状況と同じだ。

しかし、流動曲線管理で、工程間の製造スピードの差、仕掛品在庫の量を簡単に把握できるため、どこでボトルネックが発生して遅延が発生したのか、を調査することができる。
例えば、工場の製造工程において、第1工程と第2工程の差を累積フロー図で見れば、どこで差分が時系列に大きくなっているのか、は見るだけですぐに原因を特定できる。
そこから、対策を打てばよい。

つまり、MRPで部品の所要量展開を行って、必要な部品の個数とリードタイムを大まかに把握し、流動曲線管理で日々の製造実績からボトルネックを監視・追跡するように進捗管理すればいい。

【1-3】流動曲線管理は、例えば、大量生産の食品工場、クリーニング工場のように季節変動が激しい工場の納期管理に向いている、とのこと。
すなわち、需要変動が激しく、生産計画を事前に決定するのが難しい製造業で有効である、という指摘なのだろう。

では、この発想をソフトウェア開発にどのように生かせばよいのか？

【2】『リーン開発の現場』第12章に累積フロー図 (P.90)という概念が出てくる。
【2-1】累積フロー図とは、かんばん上にあるカード(ストーリーカードまたはタスクカード)をステータス(ToDo、Doing、Doneまたは、バックログ～受入完了)ごとに時系列に集計したグラフ。

累積フロー図の目的は、どのステータスのカードがたまり過ぎてボトルネックになっているか、を見える化するツールだ。

(引用開始)
累積フロー ダイアグラムは、ワークフローの各状態にある累積作業項目の面グラフをプロットします。 これは豊富な情報を含み、プロセス内のステップの平均サイクル タイムとスループット率 ("ベロシティ") を調べるために使用できます。 累積フロー ダイアグラムに表示される視覚的特徴は、ソフトウェア開発ライフサイクル プロセスによって異なります。 作業者は、面グラフに表示されたプロセスの機能不全のパターンを見分ける方法を習得できます。 真のリーン プロセスでは、安定したペースでなだらかに上昇する、均等に分布した色の領域が表示されます。 図は、のこぎり状になったステップや一見してわかる色の塊がなく、滑らかに見えます。

最も基本的な形式の累積フロー ダイアグラムは、作業項目ライフサイクルの特定のステップにある仕掛品の量を視覚化するために使用されます。 また、ボトルネックを検出し、"ムラ" (フローのばらつき) の影響を監視するためにも使用できます。
(引用終了)

【2-2】しかし、「リーン開発の現場」では、実際の開発現場ではあまり有効ではなかった、と書いていた。

グラフに増減があったとしても、その原因は、カードを数える基準を変えたり、ボードのレイアウトを変えたりしたことが多いから。
つまり、人為的に計測基準を変えてしまったために、累積フロー図の傾きの増減の原因分析に有効でなかった、と言っている。

【3】なぜ、製造業の進捗管理では有効である「流動曲線管理(追番管理)」に出てくる「累積フロー図」は、リーンソフトウェア開発では有効でなかったのか？

その理由は、製造業では明確に工程を識別できるのに、リーンソフトウェア開発では工程という概念が明確でないために、累積フロー図の見せ方がマッチしていないのが原因にあると思う。

アジャイル開発では、WF型開発のように、要件定義→設計→プログラミング→テスト→リリースのような工程別の作業が「機能単位」にすべて一体化されている。
機能ごとのカードをステータスごとに時系列に集計しているから、どのステータスがボトルネックにあるのか、は分かるが、根本原因を累積フロー図から見つけ出すのは難しいだろう。

たとえば、累積フロー図を見て、設計工程のレビューに時間がかかっているのがボトルネックだ、単体テストのやり直しが発生して単体テストのリードタイムが長くなっているのがボトルネックだ、というような現象を見出しにくい。

だからと言って、リーンソフトウェア開発で累積フロー図が使えない、という結論は早急すぎる。
本来は、累積フロー図から、リードタイムや仕掛かり在庫の差を時系列に比較して、その傾向を分析したいのだ。

おそらく、累積フロー図の作り方、つまり、何を集計して累積フロー図を作成すべきか、という点に問題があるのではないか？
つまり、集計する単位が間違っているのではないか？

この辺りはもっと試行錯誤しながら考えるしかないだろうと思う。

【4】そんなことを思いつきながら書いてみると、疑問に思うことがある。

トヨタが生み出した「リーン」「かんばん」、中島飛行機が生み出した「追番管理」「累積フロー図」という概念のように、日本人は製造業の進捗管理で優れた概念を生み出したのに、なぜ、ソフトウェア開発にそれらの概念を適用して、アジャイル開発を生み出せなかったのか？

この辺りも色々探ってみたい。