「This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント」を読んで

TPS(トヨタ生産方式)、リーンとは何か、フロー効率を上げるためにどうしたらよいかが書かれていて、珍しく1日で読み切った本でした。

自身のソフトウェア開発経験を本書に当てはめてみて理解し、今後に活かせたらと思いました。
もしかしたら間違って解釈していることがあるかもしれないので、その際はご指摘をいただけたら。

本書で使われている用語等の説明は省略します。ぜひ本書を読んでいただけたらと思います。

あと、全部無料で読めるようにしていますが、気に入ったらカンパしていただけたらと思っています。

一次ニーズ

本来は顧客要求が一次ニーズですが、自分の理解を助けるために、顧客要求を満たすための製品を開発する、を一次ニーズとしてみました。

フローユニット

この場合、フローユニットは製品を完成するために必要な開発アイテム（ソフトウェアモジュールや取扱説明書、認証のための作業など）と定義することができます。また、これらの開発アイテムは、開発着手時は情報が少なく、それぞれが独立して作業タイミングがかぶらないことが前提である。

初期オペレーション戦略

開発アイテムを進めるため、開発アイテムごとに担当者を割り当てて各自で独立して作業を進める、といった戦略が考えられます。開発アイテムが同じくらいの粒度で独立している前提であれば、チームを作ったばかりでコミュニケーションに難があってもうまくいくような気がします。

これは、フロー効率よりリソース効率を重視した戦略と考えることができます。一からの製品開発で開発スケジュールが長く、その開発スケジュールに合意しているのであれば、リソース効率を高くしたいと考えるのは自然な気がします。

プロセスに対する変動

本書では、フロー効率とリソース効率を同時に実現することは難しいとされていますが、その理由としてプロセスに対する変動を原因としています。ここでは、次のようなものが挙げられると思います。

・開発アイテムによって、複雑度・難易度が異なる
・担当者の工数の見積もりが甘く、計画通りに作業が終わらない
・担当者の設計が甘く、不足している機能が後になって出てくる
・終わった作業や想定外のところで不具合が出る

当初、対応可能なスケジュールで組んでいたと思います。しかし考慮していなかった変動によって、実際のプロセスにはボトルネックが存在することになります。
結果、特定の担当者の開発アイテムの完成が遅れるようになります。一方で、余裕が生まれている担当者もいることになり、担当者によって作業量に偏りが現れます。

発生する二次ニーズ

一次ニーズである製品開発が計画通りに満たされないようになり、結果的に副次的なニーズが発生します。二次ニーズは、余計な仕事を生み出すことになります。

・製品開発の計画を変更する。チーム内での作業の調整から、製品の発表の延期など、影響度によって様々ある。
・余裕がある担当者は、別の作業を並行的に着手する。担当していた開発アイテムは完成していたとしても、結合テスト・システムテストが終わるまで完全には終わっていないためマルチタスクになり、作業の切り替えに余計な時間がかかるようになる。
・もし、機能を先行してリリース・評価しているのであれば、不具合が発生すると割り込み作業になり、さらに製品の完成が遅れる。
・不具合が起こった場合は原因の調査や対策が必要である。影響が大きかったり長引くと、対策会議が開催されるようになり、定期的に報告するようになる。

効率性マトリクスに当てはめる

以上の状況を、リソース効率とフロー効率のマトリクスに当てはめると、次のように変化したと考えることができると思います。

・開発当初は、独立した開発アイテムそれぞれに担当者を割り当てて開発した（高リソース効率・低フロー効率）
・プロセスに対する様々な変動要因によって、特定のリソースに作業が集中し、それ以外は比較的遊んでいる状態になった（低リソース効率・低フロー効率）

今後のオペレーション戦略

リーンはフロー効率を高めるためのオペレーション戦略ですが、実際のところ、低リソース効率・低フロー効率な場合、どちらの効率を重視するのが適切なのでしょうか？

これについては、TOCfEのクラウドを使ってみました。

リソース効率を高くする理由は、開発者の開発工数を無駄にしないと仮定しましたが、結局のところリソースに遊びができるし、マルチタスクや割り込みが発生したら効率が悪くなるので、リソース効率を高くするのはよくないだろうと思いました。
そのため、解決策は、顧客が欲しいものに対してフロー効率を高くするのがよいだろうと思いました。

もし、フロー効率を高くする理由が「資金を早く回収する」だったら、リソース効率を高くする方が解決策になる可能性があるかもしれないですね。

実際は、適切なタイミングで何度か見直すようにした方がよいと思います。

今後どうやっていくか

フロー効率を高くしていくが今後の解決策となりましたが、リーンであるために、価値観、原則、メソッド、ツールを決めていく必要があります。これらは、現在抱えている数件の案件を使って、徐々に決めていくのがよいと思いました。

そういえば、こんな事ってないですか？

最近、1日の会議の時間が業務時間を占めていて、定時以降から自分の仕事の開始みたいなことになりかけています。
他にも、上司の会議がたくさん埋まってしまいレビューが行えず、次の工程に進めない、みたいなことってないですか？

このような状況を改善するために、各会議時間を短くするのが自然な考えだと思います。
でも、単純に短くしたとしても別の会議が入るようになり、また会議が終わらなかった場合は別日に改めて会議を設定することになり、現状は悪化していくことってよくありますよねー。

このような問題も、リーンの考え方を導入できれば会議自体を減らすことができると思いました（すぐに減らすことができるとは言っていませんｗ

おわりに

本書は、リーンについてわかりやすく丁寧に説明されていると思いましたのでお勧めします。

This is Lean 「リソース」にとらわれずチームを変える新時代のリーン・マネジメント