この質問を考えるに当たって、ちょっと第1回「なぜプロジェクトの進行計画はいつも壊れるの?」を振り返ってみましょう。もし完ぺきに計画どおり開発を遂行できるのであれば、計画を立案し、上市するタイミングに対して最遅で着手すれば投資を最小化できます。
しかしこれまで見てきたようにわれわれの開発業務は、不確実な要素が多く完ぺきな計画など絵に描いたもちにしかすぎません。多くの開発現場では、状況に対応するために安全余裕(サバ)を確保するという防衛手段も有効に機能しているとはいえません。
これに対してTOCでは個々のタスクに振り分けられた安全余裕を1カ所に集め、時間的なバッファとして有効に使うことを考えるのです。不確実性に対処するためには時間的な余裕は絶対に必要です。しかし安全余裕を多く取り過ぎれば、開発期間は長くなり、投資を増加させてしまいます。
ではどのような考え方で管理したらよいのでしょうか。
これまで安全余裕は個々のタスクを守るために、すべての資源に「こっそり」織り込まれていました。TOCでは、考え方を変えて全体のアウトプットを決めているボトルネックの前にだけバッファを集中配備します。そしてボトルネックは市場ですから、納期を守るためのバッファ(プロジェクト・バッファ)を開発プロセスの最後に置いてやればよいのです。
実は「安全余裕」は集めて管理すれば小さくできるという特徴があります。バッファの性質を理解するため自動車保険を例に取って考えてみましょう。
1人1人が、自分の貯金でこれに対処する場合は、2000万円×1万人=2兆円となり、全員合計で2兆円の預金が必要になります。
しかし、自動車保険という仕組みを作れば2兆円ものお金をプールする必要はありません。なぜなら、全員が自動車事故を起こすわけではないからです。このように、いざというときのための安全は、信頼できるところに集めると量的に小さくしても対処できるという特徴があります。
同じように、開発プロジェクトの業務もすべてがトラブルに見舞われるわけではありません。保険金をプールするように、プロジェクト全体でバッファを持つようにすれば、全体のバッファサイズを小さくできるのです。
「ボトルネックが効率的に稼働する計画を立て、計画を守るためのバッファをボトルネック前に集中配備する」。これがスループット最大化、バッファ最小化のためのTOCの考え方なのです(図2)。
バッファは、計画段階で不確実なことや突発的なことがどれだけ発生するかに応じて計画する必要があります。しかし、分からないことは分かりませんから、当然それがいつ、どこで、どれくらい起きるかを完全に予測することなどできません。ですから、あらかじめ「このくらいだろう」という大まかな設定を行い、実行段階でバッファの状態を管理し適切に対策を実行していくのです。
ボトルネックの前にバッファを集中的に配備するよう計画すると、プロジェクト全体の状況がバッファによって一目で分かるようになります。具体的には、横軸にプロジェクト進ちょく率、縦軸にバッファ消費率を記載したグラフを作り、日々変化する状況をグラフにプロットするのです(図3)。バッファがどのゾーンにあるかによって、グラフを見た瞬間にプロジェクトの状況を把握できるようになり、先手を取って組織的な対策を打つことが可能になります。
ゴールを達成するためには、ボトルネックを徹底的に活用し、安全余裕をバッファとして生かさなければならないことが分かりました。最後に、「業務費用を減らすことができたか?」という質問にはどう考えたらいいのでしょうか。
ここまで考えた方法を使えば、開発業務の混乱を収め、スループットと投資を改善できます。混乱の収束によって生まれる時間を活用すれば、さらに開発テーマを増やすことができるようになります。要するに人を増やさず、多くの開発テーマをこなせるようになる、相対的に業務費用を減らすことが実現できるのです。
TOCの考え方は従来の開発マネジメントのどの部分(何を)、どのように(何に)変えてくれるのでしょうか。
従来の開発マネジメントは、プロジェクト全体を個々の作業レベルにまで分解し、それぞれの作業時間を個々人に守らせるように、責任分担を細かく落とし込んで管理を行おうとしていました。要するに個別のリソースがゴールを達成する「カギ」ととらえているということなのです。
一方TOCでは、ゴールはスループット向上であり、スループットを決めているものはボトルネックだと考えます。スループットを向上させるためにはボトルネックが歩みを止めずに歩き続けているかが重要であり、それ以外はボトルネックに影響を与えない限りさして重要ではありません。
従って計画段階ではボトルネックを発見し、これを守るためにバッファを組み込んだ計画を立案します。そして実施段階ではバッファの消費状況をきめ細かくモニターし、バッファの状態が許容範囲を超えた場合は回復策を速やかに実施するというバッファマネジメントを確実に行います(図4)。
これによってマネージャは、個々のリソースの稼働状況やタスクの進ちょく度合いを細かく管理するという役割から、開発プロジェクト全体をバッファという仕組みを使って見渡す役割に変化します。そして収益を脅かす不確実性をコントロールし、開発業務をスムーズにマネジメントします。業務費用の視点も、すべてのタスクを見る必要がなくなりますから、より少ない工数で多くのテーマを開発できる=「業務費用を減らすことができたか?」に答えられるようになるのです。
◇
次回は、この考え方を実際に適用するために再びPDCAに戻って考えていきましょう。
Plan プロジェクトのどこにどれぐらいの時間のバッファを計画すべきか?
Do バッファ消費はどのようにすればモニターできるのか?
Check バッファの許容範囲はどのように管理すべきなのか?
Action バッファ許容範囲を超えたときどのように対策すべきなのか?
Copyright © ITmedia, Inc. All Rights Reserved.