会社でみんなが残業して頑張っているのに、なかなか成果が出ない状況が続いています。そんなときに出会ったのが「リソース効率」と「フロー効率」という考え方。この本を読んで、いまの開発のやり方を見直すきっかけになったので、感想とともに自分の体験を交えてまとめてみます。
リソース効率とフロー効率の違い
本書では、まずこの2つの効率について病院の例を挙げて説明しています。
大病院では各診療科がフル稼働していても、患者は診断まで長時間待たされる。これが「リソース効率は良いけど、フロー効率は悪い」状態。
これは、ウォーターフォール開発もまさに同じ構造だと感じました。
フェーズごとに人をかければリソース効率は高まりますが、ユーザはすべての工程が終わるまで成果物を確認できない。この構造が、現場が疲弊しているわりに顧客には良い価値を提供できていない温床になっていると改めて思いました。
改善のための3つの法則
本書では、以下の3つの法則をもとに改善方法が解説されていました。
1. リトルの法則
スループット時間＝プロセス内のフローユニット数×サイクル時間
リソース効率を高めるには一度にたくさんのフローユニットを抱え込んだ方が良い。しかしリトルの法則に当てはめるとこれがスループット時間を長くする原因になっている。フローユニット数を少なくすることでスループット時間が短縮でき、フロー効率を高めることができる。
2. ボトルネックの法則
プロセス内でサイクル時間の最も長いステージのせいで、プロセス全体のスループット時間が影響される
ボトルネックを特定し解消するアプローチはソフトウェア開発をやっていると自然に身につく考えです。例えば、ソフトウェアの性能改善の場面では処理ステップごとの時間を計測し、全体を俯瞰した際にいちばん時間のかかる部分から手を付けるのが定石。 ただし、作業プロセスの改善になると途端に見逃しがちになるのも事実かと思います。というのも、組織が細分化されて誰も作業の全体像を把握できていないためです。本書のTOYOTAの例のように、作業の可視化と共有が重要だと再認識しました。
3. プロセスに対する変動効果の法則
稼働率が高くなるとスループット時間が上がる、この相関は変動が高いほど強くなる
もし高速道路を走るすべての車が同じ速度で進むなら、渋滞が起こることはないだろう
これも実感があります。
スケジュールのズレが積み重なると、最後にしわ寄せがきて、いつも遅れるのは同じ部分。変動を抑えるために、作業を標準化したり変動しないように管理するなどの仕組みづくりが必要です。
一次ニーズと二次ニーズを整理する
本書のなかで特に印象に残ったのが「一次ニーズと二次ニーズ」の整理。
例えば、私の職場では設計は自社、コーディングとテストは協力会社に依存しています。
そのため詳細設計書をソースコードレベルで作り込むのですが、本来、設計と実装を同じ人がやるならもっとシンプルにできる作業。これは二次ニーズの典型だと思っています。
- 本当に必要な一次ニーズなのか？
- 構造上、発生してしまっている二次ニーズなのか？
この視点でプロセスを整理することが、無駄を減らし改善の第一歩になると感じました。
できるなら自社で手を動かす範囲を増やすか、協力会社に設計も任せるなど、無駄な境界線を減らしていきたいところです。
フロー効率改善の難しさと日本の開発構造
そして最後に、本書を読んで改めて感じたのがフロー効率改善の難しさです。
なぜなら、フロー効率を改善するには顧客と接点を持ち、プロセス全体をコントロールする主導権が必要だから。
今の日本のソフトウェア開発は多重請負構造になっていて、生産性が低いことで知られています。
この構造だとプロセス全体の問題意識の共有が難しくなる。
フロー効率を上げるには、下請けに丸投げせず、自分たちで手を動かしていくことも大事。これが簡単ではないけれど、現場で改善できるところから始めていきたいと思いました。
まとめ
『This is Lean』は、現場改善に悩むエンジニアにとって、具体的なヒントと改善の視点をくれる一冊でした。
- 一次ニーズと二次ニーズの整理
- ボトルネックの可視化と改善
- フロー効率を意識したタスク設計
こうした実践的な考え方を、少しずつ現場に取り入れていきたいと思います。
