 |
|
「第194回例会」 報告 PMAJ 例会部会 原 宣男： 3月号
【はじめに】 TOCとCCPM及びそれらがうまくいかなかった原因について実話を交えてお話頂きました。当日は生憎質問の時間が取れませんでしたが、聴講された方にとって得るものの多い内容であったと思います。 以下にご講演内容を要約して記載致します。尚、冒頭に講師よりGoldrattConsulting社とそのメンバの紹介があり、また途中で参加者が体験したマルチタスクゲーム、他いくつかのスライドを説明頂きましたが、紙面の関係で内容は割愛させて頂きます。 【講演概要】 1. TOC (Theory Of Constraint)の話 1.1 TOCの前提 仕事には他の人や組織との「つながり」があり、人や組織の能力には「ばらつき」があります。これがTOCの前提となります。 1.2 TOCの概念 工場のラインや書類を回した時の処理能力を想定して下さい。最初の工程は1日に20個できる人、次の工程は15個できる人、その次の工程は10個できる人、さらに次の工程は12個できる人。この時、一日の出荷量はいくつでしょうか。10個ですね。いくら頑張っても10個しかできないですね。 それぞれの部署で一所懸命仕事をしたらどうなりますか？手待ちと仕掛の山になりますね。こんな状態の時の混乱を収めるのはどうしますか？10の部分の改善をしますね。まずは10の部分を徹底活用し、その後、人とか機械を入れたり、投資をしたりしますね。それで全体の出荷量が上がります。 TOCは常識の上になりたっています。ボトルネックの部分を改善することで全体のアウトプットを上げる。この状態が見えることによって、不要な在庫を作るより、そちらを助けてあげるようになる。つまり全体最適化が進み、調和にむすびついていきます。 1.3 TOCの効果 例えば、売上100億円、利益1億円で利益率1%とします。ボトルネックの工程で、そこの担当者以外ができる仕事を他の人が代わりに行うことで20%くらいアウトプットが上がったとします。そうすると売上が20億円増加し、仮にこのうちの材料費を10億円とすると増えた利益は10億円になり、新しい利益は計11億円になります。つまり、120億円の売上に対し利益率が約9%になります。即ち、1％の吹けば飛ぶような利益の会社が、ボトルネックを改善することにより、利益率9％の超一流企業になるということです。これがTOCの考え方です。 1.4 システムについて これらをシステムとして考えると、システムの一か所(＝ボトルネック)に取り組む(改善する)のと、全部に取り組むのとでは、どちらが早く結果が出るでしょうか、どちらが楽でしょうか、どちらがコストがかからないでしょうか？答えは一か所に取り組むほうですね。ではどちらが全体最適でしょうか。実は一か所に取り組むと全体のアウトプットがあがる為、一か所に取り組む方が全体最適につながります。つまり、「つながり」と「ばらつき」を前提とすると、全体の中の制約に取り組むことが全体最適につながります。制約以外のところ、即ち非制約に力を注ぐことは逆に無駄になります。TOCではFocusする。即ち今はやらないことを決め、他の工程改善はしないで制約だけに集中する、これがTOCです。 1.5 The 5 Focusing Steps 実際にどういうステップで行うかというと、最初に全体のシステムの制約を見せる。次にシステムの制約を徹底活用する方法を見つける。即ちボトルネックが手待ちをしているような状態を無くして常に物が流れてくるような状態を作る。三つ目にシステムの制約が止まらないよう前後を従属させる。四番目に新たな投資をするとかでシステムの制約の能力を高める。最後に警告ですが、惰性がシステムの制約にならないようにすること、制約が制約でなくなったらステップ1に戻ること。これが「The 5 Focusing Steps」です。 1.6 TOCの全体像 TOCは科学、マネジメントだということが前提。原因と結果のロジックで全体最適をもたらす。中心の考え方は「People are good」と「Inherent simplicity」という2つの信念で成り立っています。「People are good」は「人々は善良である」と訳しますが、これは問題が起きた時、その原因となる人を責めても何の問題解決にならないので、まず人は善良であるということを受け入れよう、その人の何らかの間違った思い込みに対してアタックしようチャレンジしよう、という考え方です。「Inherent simplicity」とは、物事はシンプルであると考えることが問題解決につながるということです。この2つの信念がTOCの中心にあるわけです。これに対して全体の制約をさきほどの「5 Focusing Steps」で見つけて制約をどんどん挙げていくわけです。変革のロジック、これは何を何にどうやって変えるかの3つの質問に答えられないと変革はできないと考えています。それから問題解決手法TP(Thinking Process)を使って色々な問題を解決していきましょうというのが中心となる考え方です。このTPを使って解決していく時に、Project即ち「同じものは二度となく納期が決まっているビジネス環境」や、Production即ち「同じものを正確にスケジュール通り作っていくという環境」、さらにSales & MarketingとRetail & Distribution(小売り)、それからFinance & Measurementというように、会社を取り巻く／構成するビジネス環境がいくつかあります。これに対しTOCはProjectであればCCPM (Critical Chain Project Management)というソリューション(＝インジェクション)を持っていて、ProductionについてはDBR (Drum Buffer Rope)、Sales & Marketingに対してはURO (Un-Refusable Offer)という手法があり、Retail & DistributionについてはDBM (Dynamic Buffer Management)、Finance & MeasurementについてはTA (Throughput Account)というそれぞれ違うビジネス環境に対して中心となる考え方(＝インジェクション)があります。これがTOCの全体像です。さらにS & T Tree (Strategic & Tactic Tree)という、いろいろなビジネス環境に対してどうやって改革を進めていくかの改革の設計図があります。 これらを使って全体最適にパラダイムシフトをしていくというのがTOCの考え方です。 2.CCPM (Critical Chain Project Management) 2.1 サバについて 儲け続けるためには沢山の仕事をこなす必要があり、サバ(安全余裕時間)を無くすことで、社員が最大の効率で仕事ができる。一方、儲け続けるためには良い仕事をする必要があり、サバを読む必要がある。即ちプロジェクトは不確実で何が起こるかわからない為、サバは必要である。このようにサバの取り方でコンフリクトがあります。そもそも正しい見積もりとは本当にあるのでしょうか。 2.2 プロジェクトの失敗のいいわけ プロジェクトがうまくいかない言い訳として、予算・人が足りない、時間が足りない、客先やマネジメントの判断が遅れる、等、というような声を聞きます。でも実はこれらはプロジェクトの外部要因です。つまりプロジェクトのうまくいかない理由はプロジェクトの外部がうまくいかないからです。つまりプロジェクトの成功はプロジェクトの周囲の支援が鍵となります。予算・人がある、ゆとりがたっぷり、客先やマネジメントの判断が遅れない、等、でしたらうまくいきそうですね。これを実現するためにクリティカルチェーンというものがあります。 2.3 サバを積極的に活用する プロジェクトのそれぞれのタスクの工期を安全余裕とぎりぎりの時間とに分けて考えます。例えば10日のタスクで、ぎりぎりが7日だと言った時には安全余裕は3日です。次に最も長いパスの各タスクの安全余裕をプロジェクトの最後のタスクに持っていきます。そして全体で安全余裕を管理します。この最後に持ってきた安全余裕がプロジェクトバッファで、これがゆとりになります。 ここで考えて頂きたいのは、ぎりぎりの納期、五分五分でできる納期を設定したので、それぞれのバッファを使う確率は50%です。例えば全体のプロジェクトバッファが全日数の半分になったとすると、CCPMでぎりぎりの納期を設定すると、それだけで25％の短縮になるということです。 また、クリティカルチェーンについて工程表を書く時、次のタスクの依存性をチェックしたり、時間がかかる理由を質問したりして、みんなでクリティカルチェーンに集中して議論していきます。プロジェクトはチームワークが鍵であるということをこれによって実感していきます。 2.4 サバをとると何が生まれるか 出来るかできないかは五分五分です。つまり2回に1回は納期に間に合わないということですから、工期を短くするやり方を先輩が伝授したり、個人が創意工夫を引き出したり、思わぬバグが初日に出たら間に合わない訳ですから自然と早め早めの報連相をするようになります。みんながそれぞれの納期をチャレンジしていくというこんなチェーンが出来上がり、最後に親方バッファが工期に間に合わない時に助けてくれるというのがクリティカルチェーンの大きな意味です。 今までとの一番大きな違いは、今までプロジェクトの工期はプロジェクトマネジメントの約束であり、遅れたら約束違反でしたが、CCPMでは工期はチャレンジ目標になります。工期は予測です。予測は外れて当然です。プロジェクトバッファをみんなが使って何とかプロジェクトを工期に入れようとすることが、チームワークの源泉となっていきます。 2.5 サバを共有するとは 今までは自分の責任でプロジェクトが遅れるとプレッシャーを感じて個人が残業とか徹夜とか休出して対応していましたが、進捗がチャート上で見えることによって、うまくいっているか否か色で判断し、赤くなっていればみんなで助けてくれるようになります。手遅れになる前に手を打てるということがCCPMです。且つ真赤赤のタスクを担当している人に仕事を頼む人はいなくなる為、仕事の掛け持ちを防ぎ、仕事に集中できるようになります。つまりバッファマネジメントは先手管理の道具であるということです。ここで重要なのは、すべて腹のうちをお互いプロジェクトメンバーが見せ合っているということです。マネジメントに対しても同様です。腹のうちを見せ合う信頼関係がCCPMをやるとできるということです。 2.6 現場を成長させる質問の力 現場に対して毎日どんな管理をしていくかというと非常にシンプルです。3つしかありません。1つ目は「あと何日ですか」と毎日15分くらい質問することです。現場は答えるために、あとどんな仕事が残っていてどんな段取りをしなければならないか考えなければならず、現場の見積もり力が鍛えられます。2つ目は「問題があるとしたら何ですか」とプロジェクトマネージャが現場に対して質問することです。現場はもしかしたらと、現場のリスクを予知する能力が鍛えられます。3つ目は「何か助けられることはありませんか？」と聞くことです。これは現場の考える力を鍛えることができます。この質問に答えるためには必ずどんなタスクで何が困っていてどんな手を打てばリカバーできるというのを考えなければならない訳です。この3つの質問をしていくだけで現場が成長していく。つまりCCPMは人を成長させる道具であって、現場を鍛えるためにも毎日この質問をしていく訳です。そうすると現場も自ら考えるということが実現できます。 3. TOCを台無しにするたった1つのこと Management by Fear 3.1 プロジェクトの背景とCCPMの導入 このプロジェクトは生産システムを作るITプロジェクトで危機的な状況でした。昨年同じプロジェクトをやって一旦成果物を納入したのですが、品質問題が多発して親会社から納品を断られ、再度納入することになっていました。もし今回も失敗すると今後親会社から取引停止となり、もともと親会社の情報システム部門を切り出した会社ですから、その存在すら危うくなる状況でした。 CCPMを導入して工程表を1.5か月かけて経営幹部にも入ってもらってみんなで作成し、お客様の要求する納期に何とか入り、プロジェクトメンバーもこれならできるといってスタートしました。ところが、直後に経営幹部から批判がでました。工程表作成に1.5か月は時間が掛かり過ぎである、GCは聞いても教えてくれない、他のコンサルと組みたいと。 そこで通常数日、長くても1週間で完成する工程表作成に、なぜこの会社だけ1.5か月もかかったのか理由がわからないので、GC内でミステリー分析を行いました。その結果は以下の通りです。 3.2 ミステリー分析 (結果) PMは納期に無理に合わせた工程表を持っている、チームが分断されて連携が無い、社内の納期と顧客の納期が曖昧、さらに成果が曖昧、聞いていないという話がどんどん出てくる、土壇場になって仕様に抜けがあることが判明、問題がいっぱいあるのに隠している、(一部省略)等、つまりプロジェクトはその体をなしていなかった。よって、タスクを徹底的に見直す必要があった。また、目標さえ誰にも共有されていなかった為、プロジェクトの一番初めに作るプロジェクト憲章から始めなければならなかった。さらに非常に厳しい納期の為、サバを取っては入れるということを徹底的に繰り返した。インジェクションとして我々(＝GC)は、愚直に質問をして工程表が納期に合うまで粘った。こうして、時間をかけて皆の知恵を集めてゼロから工程表を作り直し、メンバーが皆納得のできる納期に入った工程表ができた。ところが、「教えてくれないじゃないか」とその会社の経営層から言われ、「過去のコンサルティングはみんな答えを教えてくれてマニュアルを作ってくれた。教えてくれないなら他のコンサルを受けたい」と言われた。さらに時間をかけても工程表コンサル自らは作らない為、「時間のかけ過ぎだろ」とご批判を戴いた。 3.3 見落としていたポイント 我々の中でミステリーがあった時には全員が集まって1日かけて解析をするのですが、ある時、違うと傍と気付きました。それは以下の事実でした。 工程表がもうぎりぎりであと少しで何とか納期に入るという時に、プロジェクトマネージャが、実は肝心な仕様が抜けていて1か月位遅れると回答したところ、経営幹部はいきなり机をたたいて「なんだお前たちは、何をやっているんだ」と、プロジェクトメンバー全員がいる中で1時間以上、顔を真っ赤にしてそのプロジェクトマネージャに怒号をあびせ叱責した。プロジェクトメンバーはその間、皆下を向いたまま、ただ時間が過ぎるのを待った。PMは1週間後、プロジェクトをはずされた。 つまりこの会社は恐怖によるマネジメントをしていた訳です。我々が訪問している時には日ごろやっているようなことは行われなかった為わからなかったのですが、本当に追い込まれた時、この経営幹部は絶対に会社を救おうと心に決めてついつい出てしまったのです。わかったことは、他社と比較して異常に恐怖によるマネジメントが強い会社であったということです。 現場は、本当の状況を示したスケジュールを出すことができなかった。なぜかというと、経営幹部への恐怖で、うわべ上、間に合うスケジュールを示す選択肢しかなかった。つまり恐怖によるマネジメントが、問題の見える化を阻害する最大の障害であった。これは我々が学んだことです。 3.4 インジェクション (解決策) 我々は社長に質問しました。「役員がプロジェクトマネージャを怒ったらどうなりますか？」社長は「問題があがらなくなるな」と言いました。さらに社長は「うちは昔からそういう体質がある。これは自分達が変わらなければならない」。ようやくこの時点で問題の本質に合意してもらいました。 よって、社長にたったひとつ「何か助けられることはありませんか？」と現場に質問することをお願いしました。社長はこの後、毎日プロジェクトの進捗会議に参加してくれて「何か助けられることはありませんか？」と言ってくれました。そして「変えられない過去のことを叱責するのではなく、変えられる未来について議論をしようよ。進捗会議も進捗を会議するのではなく、これからのことを話そうよ」とのことで、「進捗会議」は「これから会議」と名前を変えました。社長は現場に行って「何か助けられることはない」と本当に尋ねてもらいましたから、その要請があった時には社長自らが手を打ってくれました。その結果、プロジェクトは納期の3日前に完了しました。 3.5 プロジェクトの総括 プロジェクトの総括として経営幹部との振り返りをやってみました。CCPMをやった場合とやらない場合では何が変わったでしょう。TRTという手法を使って社長と一緒にツリーを作ってみました。(ツリーの内容は省略)社長が言われたのは、マネジメントの姿勢は変わらなければ、今回も去年と同じことが起こり、プロジェクトは破綻していたと、社長自らが合意しました。 3.6 実際に起こったDE (好ましい現象) 社長のコメントです。「我々が永年抱えてきた本当の問題にGCは気づかせてくれた。CCPMで会社が救われた」。現場メンバのコメント、「CCPMによってみんなが助け合う風土にプロジェクトが変わりました」。 3.7 マネジメントのジレンマと解決策 プロジェクトを成功させるためには、相手に正しい行動をとってもらう必要があり、それは、きちっと叱ること。一方、プロジェクトを成功させるためには、早く仕事を進める必要があり、それは自らやること。「自らやる」と「相手に正しい行動をとってもらう」ことに対して妥協することになり、「叱る」と「早く仕事を進める」ことに妥協することになる。ただやりたいのは「相手に正しい行動をとってもらい」且つ「早く仕事を進める」こと。この2つさえできればOKなので、ここでのインジェクションはただひとつ「何か助けられることはありませんか」とマネジメントが現場に質問することです。 3.8 教訓 Goldratt博士はこんなことを言っています。「我々TOCは現場を変えるとよく言われるが、変えるのは現場ではなくマネジメントである。」「マネジメントが変われば必然的に現場が変わっていく。」これが今回のCCPMの投入で我々が学んだことです。 4. さいごに CCPMとは、問題が早く上がって、早くマネジメントが手を打てる、こんな仕組みです。そのためにはODSC目標をみんなで共有し、工程表をひき、ぎりぎりの納期で工期をつくってバッファマネジメントするのです。よく現場は人が足りないから人を入れてくれと言われますが、本当に人が必要な時とそうでない時があります。きちんと工程表を書いて初めて赤い状態になったらマネジメントは自信をもって人を投入できる訳です。でもその状況がわからず、どのプロジェクトに人を投入したらよいか、どのプロジェクトに人を投入しなくて良いのか判断がつかないというのが、皆さんが抱えているジレンマではないでしょうか。本日はご清聴ありがとうございました。 【所感】 TOCやCCPMの知識が無い人にとっても非常にわかりやすい内容でした。一番の制約は経営幹部の叱責だったというのが「落ち」でしたね。(笑) Goldratt博士執筆の「The Goal」の話を聞いた時、私の本箱の片隅に眠る黄色い本の存在を思い出しました。以前業務システム開発を担当していた際、購入したまま積読状態になっていたものです。本日のお話を聞いて、改めて読んでみたくなりました。貴重なお話ありがとうございました。(筆者) 以上
|
||||||||||||
 |