リーンソフトウェア開発～できるだけ速く提供する

「決定をできるだけ遅らせる」とともに、この「できるだけ速く提供する」は重要です。

変化に対応させて手戻りを生じさせないために、コンカレントに広さ優先で、効果的なオプションを残し、最終責任時点まで決定を遅らせて開発することを説明しました。並列処理の効率を上げ、オプションのコストを下げ、最終責任時点をより遅い時期にするのがこのできるだけ遅く提供するです。

できるだけ速くというのはアジャイルすなわち機敏ということで、早い時期という意味ではありません。これを実現するには、前に説明したプルシステムで効率よく開発するとともに、各作業をスムーズに流れさせ、パイプの詰まりを生じさせないようにします。「リーンソフトウェア開発」ではこれを待ち行列理論で説明しています。

待ち行列を効率よくするにはサイクルタイムを短縮する必要があります。それには到着の平準化とサービス時間の平準化が有効です。到着の平準化が有効な例としてテストがあげられています。ウォータフォールプロセスではテストが後工程に集中し、十分なテスターがいないとボトルネックになってしまいます。作業を平準化してより速く提供するには、リリースを分ける、つまりイテレーション(繰り返し)開発が必要になります。到着の平準化はテストのみでなくもっと詳細なプロセスにおいても有効だと思います。

サービス時間の平準化には作業を細かな単位に分割することが有効です。作業時間のばらつきをなくすことで待ち行列は効率よく動かすことができます。これは、対象ソフトウェアで制御できるはずです。オブジェクト指向で推奨されているように、より細かなクラス・メソッドに分割することで、実現できると思います。なお、上流でばらつくときは下流に影響が出るので、ばらつきそうな作業は、なるべく下流にもって行くほうが良いようです。

なお、この待ち行列は人間が処理しますので、ゆとりを持たせなければなりません。作業負荷が高くなると人間が疲弊・故障し、待ち行列は止まってしまいします。XPの様に適切な作業量を守らなければなりません。

(全体にカテゴリーを変えてみました。いずれカテゴリーを独自のものに変えるようにします。)