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

「リーン開発の現場」で読みながら気づいた点をメモ。
ラフなメモ書き。
間違っていたら後で直す。

【1】WIP制限(仕掛り作業の上限値)を下げるのがいつも有効とは限らない

デスマーチプロジェクトでは、メンバー全員の稼働率は100％を超えて働きすぎている状況だ。
だから、プロジェクトの作業負荷が高すぎる場合、WIP制限の値を下げて、メンバーから方の重荷を減らし、本来の力を発揮できるようにする。
WIP制限を下げるのが有効な状況は、過剰なマルチタスクが多く、後続プロセスに負荷をかけすぎる場合だ。
在庫をたくさん作っても、後続のプロセスが処理できなければ、効率が悪い。

例えば、テスト環境が1個しか無いのにたくさんの障害修正を送りこもうとするケース、レビューアが1人しかいないのにたくさんの設計書レビューを詰め込むケース、継続的デプロイの環境がないのに頻繁にリリースしようとするケースがあげられるだろう。
そんな場合は、ボトルネックとなる前工程の仕掛り作業の上限値を下げて、後続プロセスの作業負荷をかけすぎないようにする。

しかし、WIP制限を下げるのが本来の根本的解決ではない場合がある。

例えば、テスト環境が1個しか無いのにたくさんの障害修正を送りこもうとするケースでは、そもそもテスト環境が1個しか無いのがボトルネックなのだ。
テスト環境を仮想化して開発者1人に1個、あるいは、システムテストブランチごとに1個用意できれば、スムーズに作業が流れるだろう。

同様に、レビューアを複数人配置できれば、設計書レビューをもっとはかどらせることも出来るだろう。
継続的デプロイできるように、リリース作業を自動化すれば、頻繁にリリースできるようになるだろう。

つまり、目の前の問題の根本原因は別のところにある。
WIP制限を下げる方法は実は対症療法でしかない場合もありうるし、おそらくWIP制限を下げることが根本原因ではない場合が多いのでないだろうか。

【2】ヘンリックが編み出した因果関係図とは

「リーン開発の現場」第20章には、因果関係図の説明がある。
因果関係図は「リーン開発の現場」独自の根本原因を突き止める手法だ。
内容を読むと、QC7つ道具の特性要因図やシステム思考の因果ループ図をミックスしたような頭を使って、目の前の問題から悪循環となっていく症状や原因を洗い出し、根本原因を突き詰めていく手法みたいだ。

実際に「リリースサイクルが遅い」「バグが多い」「ペアプロできない」問題を因果関係図で深掘りしていく内容はとても面白い。

この因果関係図を読んで疑問に思ったことは、何故、ヘンリックは、かんばんとは直接関係のない「因果関係図」の手法を説明しているのか？

その疑問を考えていると、トヨタがかんばんやなぜなぜ分析を生み出した事実を何となく連想させる。

【3】かんばんと因果関係図は何故セットで運用されるのか？

以下はあくまでも僕の推測だ。

かんばんの最大の特徴は、強力な「見える化ツール」である点だと思う。
かんばんで進捗管理を始めると、従来のガントチャートとは違って、作業の流れが見えるようになる。

普通は、プロジェクト内部で発生するすべての作業をコントロールしているのは、プロマネの頭の中だけだ。
開発者は、自分のタスクをこなすだけで精一杯で、自分のタスクがプロジェクトのどの部分を占めているのか、理解しづらい。
そんな状況では、チームは一体感を持ちにくい。

ところが、ヘンリックの運用事例のように、かんばんで進捗管理を見える化すると、ユーザ観点の機能カードの流れが一目で分かるし、機能カードをさらに各チームがタスクカードに分割して作業するから、自分のタスクカードがどの機能カードに直結しているか、開発者にも分かる。

かんばんで良い点は、作業待ちが発生するカードやフェーズが目につきやすいことだ。
特定のカードが特定の場所で滞留していたら、そこがボトルネックになっていて、後続のプロセスに作業が流れていない。
ちょうど、糞詰まりみたいなものだ。
特定のフェーズで流量が狭くなっているので、後続のプロセスに作業が流れていないのだ。

そんな状況を解決するには、一つは、ボトルネック工程の前工程の仕掛り作業の量を減らして、ボトルネックの処理量に合わせるように調整する方法がある。
これがWIP制限を下げる手法に相当する。
でもこの方法は対症療法でしかなく、問題を悪化させる場合もありうる。

もう一つは、ボトルネックとなる工程は何故スループットが少なすぎるのか、その原因を徹底的に深掘りして、根本的な解決を試みる手法がある。
おそらく、この状況で、なぜなぜ分析が使われて、根本原因を突き止めて、解決方法を見出すのだろうと思う。

すなわち、かんばんとなぜなぜ分析は、セットで運用されるべき手法なのだと思う。

なぜなぜ分析の経験は僕はないけれども、経験者から聞いた話では、根本原因は最終的には心理的要因に落ち着くらしい。
例えば、油断、思い込み、先入観など。
だから、なぜなぜ分析をやるのは、精神的に追い詰められる時が多く、やるのは結構しんどい、と聞いた時がある。
おそらくそこまで突き止めないと、根本的解決にならないのかもしれない。

そんな事を考えると、ヘンリックがかんばんを使った運用事例をかなり詳しく説明した最後に、因果関係図で根本原因を追跡する手法を説明している理由は、かんばんと因果関係図が密接に相互に関係しあっているからだと思う。
かんばんでボトルネックが見える化されるからこそ、因果関係図でボトルネックとなる原因を徹底的に究明する必要があるわけだ。

以上のようなことを考えると、欧米人はトヨタが生み出したかんばんやなぜなぜ分析をソフトウェア開発に上手く適用して、効果が出るようにうまく実現したように思える。
その考えが正しいか、調べてみる。