TOC流の開発型プロジェクト管理術「CCPM」

TOC流の開発型プロジェクト管理術「CCPM」(3)

プロマネが本当に管理すべきポイントはどこか

村上 悟/西原 隆 ゴール・システム・コンサルティング株式会社 2009/1/20

- PR -

開発期間は短縮できたか?

 この質問を考えるに当たって、ちょっと第1回「なぜプロジェクトの進行計画はいつも壊れるの?」を振り返ってみましょう。もし完ぺきに計画どおり開発を遂行できるのであれば、計画を立案し、上市するタイミングに対して最遅で着手すれば投資を最小化できます。

 しかしこれまで見てきたようにわれわれの開発業務は、不確実な要素が多く完ぺきな計画など絵に描いたもちにしかすぎません。多くの開発現場では、状況に対応するために安全余裕(サバ)を確保するという防衛手段も有効に機能しているとはいえません。

 これに対してTOCでは個々のタスクに振り分けられた安全余裕を1カ所に集め、時間的なバッファとして有効に使うことを考えるのです。不確実性に対処するためには時間的な余裕は絶対に必要です。しかし安全余裕を多く取り過ぎれば、開発期間は長くなり、投資を増加させてしまいます。

 ではどのような考え方で管理したらよいのでしょうか。

 これまで安全余裕は個々のタスクを守るために、すべての資源に「こっそり」織り込まれていました。TOCでは、考え方を変えて全体のアウトプットを決めているボトルネックの前にだけバッファを集中配備します。そしてボトルネックは市場ですから、納期を守るためのバッファ(プロジェクト・バッファ)を開発プロセスの最後に置いてやればよいのです。

 実は「安全余裕」は集めて管理すれば小さくできるという特徴があります。バッファの性質を理解するため自動車保険を例に取って考えてみましょう。

  • 自動車事故を起こしてしまったときには、1人当たり2000万円の費用負担が発生するとする
  • 自動車に乗る人が1万人いるとする

 1人1人が、自分の貯金でこれに対処する場合は、2000万円×1万人=2兆円となり、全員合計で2兆円の預金が必要になります。

 しかし、自動車保険という仕組みを作れば2兆円ものお金をプールする必要はありません。なぜなら、全員が自動車事故を起こすわけではないからです。このように、いざというときのための安全は、信頼できるところに集めると量的に小さくしても対処できるという特徴があります。

 同じように、開発プロジェクトの業務もすべてがトラブルに見舞われるわけではありません。保険金をプールするように、プロジェクト全体でバッファを持つようにすれば、全体のバッファサイズを小さくできるのです。

 「ボトルネックが効率的に稼働する計画を立て、計画を守るためのバッファをボトルネック前に集中配備する」。これがスループット最大化、バッファ最小化のためのTOCの考え方なのです(図2)。

図2 ボトルネック=市場の直前にバッファを集中させる

バッファを計画する

 バッファは、計画段階で不確実なことや突発的なことがどれだけ発生するかに応じて計画する必要があります。しかし、分からないことは分かりませんから、当然それがいつ、どこで、どれくらい起きるかを完全に予測することなどできません。ですから、あらかじめ「このくらいだろう」という大まかな設定を行い、実行段階でバッファの状態を管理し適切に対策を実行していくのです。

 ボトルネックの前にバッファを集中的に配備するよう計画すると、プロジェクト全体の状況がバッファによって一目で分かるようになります。具体的には、横軸にプロジェクト進ちょく率、縦軸にバッファ消費率を記載したグラフを作り、日々変化する状況をグラフにプロットするのです(図3)。バッファがどのゾーンにあるかによって、グラフを見た瞬間にプロジェクトの状況を把握できるようになり、先手を取って組織的な対策を打つことが可能になります。

図3 プロジェクトの進ちょく率とバッファの消費率

業務費用を減らすことができたか?

 ゴールを達成するためには、ボトルネックを徹底的に活用し、安全余裕をバッファとして生かさなければならないことが分かりました。最後に、「業務費用を減らすことができたか?」という質問にはどう考えたらいいのでしょうか。

 ここまで考えた方法を使えば、開発業務の混乱を収め、スループットと投資を改善できます。混乱の収束によって生まれる時間を活用すれば、さらに開発テーマを増やすことができるようになります。要するに人を増やさず、多くの開発テーマをこなせるようになる、相対的に業務費用を減らすことが実現できるのです。

TOCでマネージャの仕事が変わる

 TOCの考え方は従来の開発マネジメントのどの部分(何を)、どのように(何に)変えてくれるのでしょうか。

 従来の開発マネジメントは、プロジェクト全体を個々の作業レベルにまで分解し、それぞれの作業時間を個々人に守らせるように、責任分担を細かく落とし込んで管理を行おうとしていました。要するに個別のリソースがゴールを達成する「カギ」ととらえているということなのです。

 一方TOCでは、ゴールはスループット向上であり、スループットを決めているものはボトルネックだと考えます。スループットを向上させるためにはボトルネックが歩みを止めずに歩き続けているかが重要であり、それ以外はボトルネックに影響を与えない限りさして重要ではありません。

 従って計画段階ではボトルネックを発見し、これを守るためにバッファを組み込んだ計画を立案します。そして実施段階ではバッファの消費状況をきめ細かくモニターし、バッファの状態が許容範囲を超えた場合は回復策を速やかに実施するというバッファマネジメントを確実に行います(図4)。

図4 マネージャの仕事はどう変化するか

 これによってマネージャは、個々のリソースの稼働状況やタスクの進ちょく度合いを細かく管理するという役割から、開発プロジェクト全体をバッファという仕組みを使って見渡す役割に変化します。そして収益を脅かす不確実性をコントロールし、開発業務をスムーズにマネジメントします。業務費用の視点も、すべてのタスクを見る必要がなくなりますから、より少ない工数で多くのテーマを開発できる=「業務費用を減らすことができたか?」に答えられるようになるのです。

 次回は、この考え方を実際に適用するために再びPDCAに戻って考えていきましょう。

  • Plan:プロジェクトのどこにどれぐらいの時間のバッファを計画すべきか?
  • Do:バッファ消費はどのようにすればモニターできるのか?
  • Check:バッファの許容範囲はどのように管理すべきなのか?
  • Action:バッファ許容範囲を超えたときどのように対策すべきなのか?

(次回に続く)

筆者紹介
 
ゴール・システム・コンサルティング株式会社

代表取締役社長
村上 悟(むらかみ さとる)

 
国際TOC認証機構 正式認定コンサルタント。
大手製造業にて経理、原価計算を担当、社団法人日本能率協会を経て株式会社日本能率協会マネジメントセンター分離独立に伴い移籍。1997年、TOC(Theory of Constraints)研究会を組織し、TOC研究とコンサルティングを開始する。2002年8月にゴール・システム・コンサルティング株式会社を設立し、代表取締役に就任。現在、法政大学講師、日本TOC推進協議会理事長。
ゴール・システム・コンサルティング株式会社は日本最大のTOC専業コンサルティング会社。導入企業に確実に利益をもたらすコンサルティング力はゴールドラット博士より多くの絶賛を受けている。
近著に『儲かる会社のモノづくり マーケティング 売るしくみ』(中経出版)、『問題解決を「見える化」する本』(中経出版)がある。
 
 
ゴール・システム・コンサルティング株式会社

マーケティンググループリーダー
チーフコンサルタント
西原 隆(にしはら たかし)

 
1971年神戸市生まれ。2003年、ゴール・システム・コンサルティングに参画。製造業設計開発業務、IT、建設業などの大手企業に対するプロジェクトマネジメント・コンサルティングを主に担当。TOCのプロジェクトマネジメント手法「CCPM」に関する豊富な理論的知識および実践スキルを持ち、インプリメンテーションの経験は日本随一である。また、TOC思考プロセスを用いたファシリテーションに精通しており、現場スタッフのモチベーションを向上させる技術には定評がある。
CCPM対応ソフトウェア「BeingManagement-CCPM」共同開発担当。中小企業診断士、TOC‐ICO Jonah。
  • 連載バックナンバー
  • 全記事インデックス
  • 生産管理トップ
  • MONOistトップ

ホワイトペーパーTechTargetジャパン

メールマガジン

スキルアップ/キャリアアップ(JOB@IT)

スポンサーからのお知らせ

生産管理フォーラムの新着記事をRSSで購読

メールで新着情報をチェックする

@IT MONOist 求人情報