「『CCPMを適用する』ことはマネジメントが変わること」
 ゴールドラット・コンサルティング ディレクター
 岸良 裕司氏

 CCPM(クリティカルチェーン・プロジェクトマネジメント)は、現場の“サバ読み”を取り除くというユニークな特徴があるため、「現場を変える手法」と捉えられがちだ。だがTOC(制約条件の理論)の提唱者エリヤフ・ゴールドラット博士から直接薫陶を受けたゴールドラット・コンサルティング・ディレクター、岸良裕司氏は「CCPMとはマネジメント層が変わるための手法である」と言い切る。同氏にCCPMの本質を聞いた。(聞き手は井上 健太郎=ITpro)

*  *  *

 CCPMには幾つか誤解されがちな点がある。例えばCCPMは「問題を無くすための手法だ」という勘違いがその1つ。以前「CCPMを適用しているが問題続出で困っている」という相談を受けたことがあった。よく聞くと、確かに問題が浮かび上がってトップが対応に追われていた。

 そこで「来年3月の納期に向けて10月時点で問題が発覚し、トップが先頭に立って手を打とうとしている状態はいいことですか、悪いことなんですか」と聞くと、ハッとその人は、手遅れとなるはるか前に、現場の支援に着手していることに気がついたようだった。「いつもなら、手遅れになってから問題が上がってきて、納期ギリギリでバタバタしていたのに、確かにこれは違う。なるほど、CCPMは経営を変えるんだな」と、かえって効果を実感していた。

 不確実性があるのがそもそもプロジェクトの特徴。プロジェクトから不確実性を完全に無くすことはできない。もし達成確実なプロジェクトばかりな企業があったとしたら、目標設定がそもそも低すぎるなど、何も競争優位を築こうとしていないに等しいとさえ言えるだろう。

 CCPMで解決を図っているのは、プロジェクトの不確実性を無くすことではなく、「手遅れになる前に、問題に手を打たない」状態を無くすことだ。つまり、プロジェクトにつきものの避けられない不確実性に対して、手遅れになる前にマネジメント層が手を打てることを可能にするのがCCPMなのだ。

 プロジェクト関係者は「不確実性があること」を恐れるあまりに、かえって不適切な管理をしてしまう。これは世界中の人間に共通の傾向で、ゴールドラット博士は生前、「プロジェクトのタスクを数千も細かく分けて緻密に管理しようとするのは、プロジェクトが確実なものだと思いたい人の心理から来るもの。不確実性に対する恐怖心が動機である」と分析し、「そもそも不確実性のあるものに確実性を無理矢理押しつけること自身が根本的な間違いである」と指摘していた。

目標が曖昧なプロジェクトは前提にしてはいけない

 CCPMに寄せられる別な勘違いは「何を作るかさえ分からない目標の曖昧なプロジェクトには使えない」というものだ。そもそもプロジェクトには、目標は必ずあるはず。これはプロジェクトの体を成しているのかどうかの基本的な問題であって、この点をないがしろにしたらうまくいかない。

 目標、成果物、成功基準をプロジェクト関係者で詰めていくことは、「キホンのキ」ともいえるはずだ。IT投資を行う目的は「ライバル企業よりも効率的で有効な業務プロセスを実現すること」などだろうし、新商品を開発するのは「ライバルよりも売れる商品を作ること」などであるはずだ。

 ところが、ITプロジェクトでは「現場が使いやすい仕様」の要求を山ほど盛り込んでしまうことが多い。これにより、それぞれの現場の部分最適のオペレーションがシステムに反映されてしまい、結果的に非効率な業務システムとなってしまうことになる。プロジェクトの目的を関係者間できちんと共有してあれば、ベストプラクティスの業務プロセスを全社展開するための要件定義になるはずだ。

 商品開発プロジェクトでは「ライバル商品にある仕様はすべて取り込む」という企画になりがちだ。ところが、お客様が本当に活用している仕様や機能なのか、ライバルと差別化できるのかを再度検討すると、本当に集中すべき仕様と機能が明確になり、開発項目が5割減ってしまうことも珍しくない。

「重要なことに集中できる」状態をマネジャーが作る

 以上の問題は言い換えれば、「重要なことに集中して取り組む」状態を作れるかどうかということでもある。これはTOCの「ボトルネックに資源を集中する」という考え方をプロジェクト管理に適用することにつながる。

 ベストプラクティスを抽出したり、お客様からの要求を見極めるといったことは、マネジメントがきちんとしていないとできない。ここに責任を持つのはマネジメントであって、開発技術者やソフト開発者などが責任を持てることではないのは、誰でも分かるはずだ。

 真面目な現場ほど、nice to have(あれば嬉しい)な要求も取り込んでしまいがちで、こうした判断にマネジメント層がきちんと関わらないといけない。こうした判断をするためにも、プロジェクトの目標をマネジメントと現場が共有することが欠かせないのだ。

 また、冒頭の不確実性の話にも関連するが、プロジェクトの遅れには「良い遅れ」と「悪い遅れ」がある。「良い遅れ」とは、プロジェクトにつきものの不確実性に起因する予想できない遅れ、技術的問題、参加者の病気といったもので、こうした遅れは、事前に無くしきれないものだから、不確実性としてマネジメントできればよい。

 しかし、「事前に関係者がしっかり目標を共有していない」「引き継ぎ不足」「問題解決が稚拙」「問題発見が遅れる」「優先順位に従っていない」などは、事前の準備がきちんとしていなかったためで、「悪い遅れ」と言える。不確実性のために確保しておいたバッファを、事前に準備すれば防げる問題で使ってしまうのは、もったいない。だから「悪い遅れ」を無くすようにマネジメントが遅れの理由を分析して、継続的に改善していくことが大切なのだ。

「私が変わった」とマネジャーが言えるか

 複数のプロジェクトが同時進行しているマルチプロジェクト型の組織では、そもそも全社あるいは事業部全体でどのくらいのプロジェクトが走っているのかを、誰も把握できていないことが少なくない。現場にあるプロジェクトは、本業のプロジェクトだけとは限らない。社内の品質改善プロジェクト、生産性改善プロジェクト、コストダウンプロジェクトなど、改善文化が盛んな日本企業ほど、たくさんのプロジェクトが組織に存在する。

 プロジェクトを始めるのは簡単だが、やめるのは難しい。年月がたつといつの間にかたくさんのプロジェクトが現場に存在するようになる。それが、現場にマルチタスクを引き起こしている場合も少なくないのが現実だ。

 オムロンヘルスケアのマルチプロジェクトでのCCPM適用事例では、まずプロジェクトの洗い出しをした。すると小さなものも含めると427のプロジェクトがあると分かり、一覧を見た瞬間に誰もが「これは無理だな」と考えた。現場と幹部クラスが話し合って、遅らせられないプロジェクトを25に絞り込んだ。その英断は生前のゴールドラット博士をも驚かせた。

 このようにして現場からマルチタスクを無くして、集中できる状態を作ってあげると、仕事の質が上がり、工期も大幅に短くなった。ちょっとした改善プロジェクトがたくさんあることが、逆に本業のプロジェクトの足を引っ張ることもあるということだ。現場からマルチタスクを無くすことに、現場もマネジメントも、もっと注意を払うべきだろう。

 また、CCPMではマネジメント層から現場に「何か助けられることはありませんか」と問いかける。すると、現場はよく考えて「これを助けてもらえると助かるんですが」と言い出すようになる。これは、命令で言いなりにさせるより、実は現場に頭を使わせる。このようなやり取りを通じて、マネジメント層も現場も考え方が変わり成長していく。

 プロジェクトの事前の準備がしっかりとしていて、このようにマネジメントが問題をきちんと解決する姿勢で取り組むならば、CCPMは確実に成果を出す。先端技術を使った開発プロジェクトや、企画など上流工程のプロジェクトにも適用できる。もちろん挑戦的なプロジェクトであれば、途中で「技術的に達成不可能」と判明するケースもあるだろうが、従来の管理手法よりもはるかに早い段階で、見直したり中止したりできるだろう。挑戦的なプロジェクトが早い段階で「無理」と分かることも、経営者にとって必要かつ望ましいことだ。

現場からマネジメントを変える

 CCPMの一つひとつの要素はとてもシンプルだが、現場から、自然に無理なくマネジメントを変えられるようにうまくできている。今回の連載で紹介された事例はまさにそれを示す、すばらしい事例といえるだろう。オムロンヘルスケアの幹部が語った以下の言葉がCCPMの本質を捉えていると思うので引用させてもらいたい。

変えるのは、現場ではない。マネジメントである。
マネジメントが変われば、現場が変わる。

■変更履歴
1ページの最後から遡って2つ目の段落で石橋民生代表取締役副社長の氏名を誤って記載していました。お詫びして訂正します。本文は修正済みです。[2012/3/6 14:50]

この先は会員の登録が必要です。今なら有料会員(月額プラン)は12月末まで無料!

日経 xTECHには有料記事(有料会員向けまたは定期購読者向け)、無料記事(登録会員向け)、フリー記事(誰でも閲覧可能)があります。有料記事でも、登録会員向け配信期間は登録会員への登録が必要な場合があります。有料会員と登録会員に関するFAQはこちら