ソフトウェア開発プロジェクトとTOC

制約条件理論（TOC: theory of constraints）というのがあります。いきなり難しそうな言葉で身構えてしまうかも知れませんが、基本的な考え方は割とシンプルなのでご安心を。ちなみに関連の書籍やザ・ゴール ― 企業の究極の目的とは何かといった小説も出ていますので興味のある方は一読をお勧めします。私は最速で開発し最短で納めるプロジェクト・マネジメント―TOCの管理手法という本で初めて知りました。

TOCの基本的な考え方について、思い切り噛み砕いて説明すると、

1. 作業全体の流れの中で、ボトルネック

　　（TOCでは制約プロセスと呼ぶらしい）となる箇所を見つけて

2. ボトルネック箇所の性能を最大限に引き出すよう改善

3. ボトルネック箇所がこなせるタスク量にあわせて

　　全体のスループットを調整

4. ボトルネック箇所用のタスクがなくならないように注意

5. 上記のボトルネックが改善されたら

　　別のボトルネックを探す（1へループし改善を続ける）

となります（噛み砕きすぎて別物になっていたらすみません）。

ここで、強引にソフトウェア開発のプロジェクトに当てはめた例を挙げてみましょう。たとえば…

・複数のプロジェクトが平行して進んでいる中で

・フレームワーク周りを担当できるのは、Zさんだけ

・Zさんはちょっとした役職についているので雑用も多い

・各プロジェクトはそれぞれ勝手にスケジューリングしてしまい

・フレームワーク周りのテスト時期がよく重なる（※）

・フレームワーク周りのテストが遅れると直接

　全体スケジュールに波及する

（※…開発はさすがにずらすと思いますが…）

という状況だとどうなるでしょう？

「各プロジェクトのフレームワークのテスト時期になると　Zさんしか対応できないバグが続出。雑用の多いZさんは徹夜続きで効率があがらず、それ以降の工程が大幅にずれ込む」という現象が発生しそうです。

ここでTOCの観点から対処を考えてみましょう。

1.

各プロジェクトのスケジュールからクリティカルパス（ここが遅れたらダイレクトにスケジュール全体が遅れる、という一連のタスクの流れ）を引いていく。すると各プロジェクトともフレームワーク周りのテストがクリティカルパスに含まれそう。ここでバグが続出した場合、Zさんの処理能力を超えてしまうと思われるため、Zさんがボトルネックになりそうだと判断する。

2.

Zさんの処理効率を最大限に高めるためには？まず複数のプロジェクトで、Zさん対応が必要になるフェーズ（フレームワーク周りのテスト）が重ならないように調整し、バグが続出してもZさんの負荷が異常に高くならないようにする。他のメンバーでサポートできる雑用はZさんから切り離しZさんの負荷を軽減。もちろん中長期的にはフレームワーク周りを担当できるメンバーを育てZさん以外でも対応できるようにする。

3.

依然としてZさんの負荷が高いようなので、ある程度未解決のバグが残っている場合、フレームワークテストメンバーは、平行して進められる作業に専念するか、それも無ければ、さくっと仕事を切り上げてしまいましょう。Zさんが一杯一杯だとバグを見つけても対応してもらえませんし…

4.

付加価値の高い仕事をするZさんがタスク待ちになってしまうと、全体的に大きな損失になるので、未解決のバグが少なくなってきた場合は…フレームワークテストメンバーは頑張ってテストを進めましょう。

5.

適度な余裕をもって元気に仕事ができるようになったZさん。一方、各プロジェクトの基本設計レビューを一手に引き受けているXさんの顔色が悪い。徹夜続きだそうで、タスクが山積みであるにも関わらず、昼過ぎは居眠りをしがちという噂も…作業もはかどっておらず基本設計書のFIX時期が延び延びになっているようだ。今度はXさんの負荷を軽減しなければ。

まぁ、例示したプロジェクトの状況ができすぎている感がありますが、雰囲気だけでもつかんで頂けたら嬉しいです。また、プロジェクトマネジメントとは関係ないと思っている新人プログラマの方も、自発的にボトルネックになっているメンバーを見つけて、可能であればフォローしたり、上司に相談したりすると素晴らしいと思います。経験上、そういうメンバーは重宝がられるような気がしますねぇ。

TOCには今回紹介した基本的な考え方「制約を見つけて最大限のパフォーマンスを発揮できるよう改善する」以外にも、非常に効果的な考え方が補足的に存在します。こちらのほうが初心者向きな気がしますので、次回紹介したいと思います。

なお、私はTOCの論文を読んでおりませんので、内容について勘違い等ありましたら、お手数ですがご指摘頂けるととても有難いです。