なぜプロジェクトの進行計画はいつも壊れるの？ 「クリティカルチェーン・プロジェクトマネジメント」とは：TOC流の開発型プロジェクト管理術「CCPM」（1）（1/3 ページ）

量産型工場の生産管理手法として生まれたTOCは、そのエッセンスを拡張させて設計開発型業務のマネジメントにも応用されている。TOCの最新ツール「クリティカルチェーン・プロジェクトマネジメント」を紹介しよう。

[村上悟, 西原隆／ゴール・システム・コンサルティング，＠IT MONOist]

発想を変えればできる！ TOCによる開発設計プロジェクトマネジメント

　皆さん、こんにちは。今回は、プラント建設業務や製品・ソフトウェアの開発、設計業務といったプロジェクト型業務に適用する「クリティカルチェーン・プロジェクトマネジメント」（以下、CCPM）について一緒に考えていきましょう。

　CCPMは、数あるTOCツールの中でも比較的最近開発されました。TOCの出発点は数多くの製品を生産する量産型の管理です。しかしプラント建設や製品開発のようなプロジェクト型業務の管理には、製造現場の管理法とは異なった視点が必要になります。そこでTOCを開発したエリヤフ・M・ゴールドラット博士はプロジェクト業務の生産業務とは異なる特性や環境を考慮して、DBRに新しい洞察を加え、このCCPMを開発したのです。

　本連載では、プロジェクト型業務の中でも最も管理が難しいといわれる「開発型業務」に焦点を絞り、TOC-CCPMを活用して開発業務をいかに管理するかを紹介したいと思います。

いま、開発現場はどうなっているか

　1991年のバブル崩壊からの10年は、日本経済にとって失われた10年と呼ばれます。この間、製造業は生き残りをかけて製造現場を低コストの中国や東南アジアに積極的に移転しました。さらに製造のコストダウンと並行して、新製品開発による高付加価値競争もかつてないほどに激化しました。この結果、開発部門には非常に多くの開発テーマが課されることになったのです。

　しかし開発テーマが増えたにもかかわらず、企業は低迷する業績の影響で採用を抑制し続けました。この結果、開発部門の人員構成は、40歳過ぎのバブル入社組に偏り、30代が非常に少なく、20代が多いといういびつな瓢箪（ひょうたん）型になっている企業が多く見受けられます。

　偏った人員構成は中間管理職の過負荷を引き起こし、開発現場を疲弊させています。40歳前後のエンジニアたちは現在、肩書上は課長やプロジェクトリーダーといったマネジメント職に就いていますが、現実には部下が少なく、日常的にプレーイングマネージャを掛け持ちせざるを得ないのです。また採用抑制の反動から、その後大量採用された20代の若手教育も彼らの肩にずしりとのし掛かります。本来プロジェクトリーダーとして開発部門の中核を担うべき管理職が、肩書はともかく、プロジェクトリーダー兼チームリーダー、さらに教育担当、揚げ句の果ては担当エンジニアとして直接業務までこなす「何でも屋」になりさがっているのが開発現場の実態なのです。

製品の高度化による複雑化

　製品の高度化に伴い、開発プロセスも大きく変わりました。これまでは、製品企画や新技術はハードウェア要素が競争の中心でした。しかし今日では製品の多くは組み込みシステムと呼ばれるコンピュータ制御が普及し、組み込まれたソフトウェアの優劣で製品の売れ行きが大きく左右されるようになっています。この製品に組み込まれるソフトウェアは開発の最終段階、結合工程でさまざまなトラブルを引き起こし、エンジニアを混乱のふちにたたき込むのです。

コンカレントエンジニアリングで家に帰れない

　昨今流行のコンカレントエンジニアリングもくせ者です。以前は開発工程が終了した段階で量産開発が行われるのが一般的でした。しかし現在ではコンカレントエンジニアリングと称して、開発と量産立ち上げをオーバーラップさせ、開発リードタイムを短縮する開発が一般的になりつつあります。これによってエンジニアは、開発キックオフから量産までの間ずっと、プロジェクトに張り付いていなければならない状況に追い込まれています。

　このように今日の開発現場では、創造的な業務は夢のまた夢、すべてが体力勝負、忙し過ぎて状況の改善を考える暇もないのが偽らざる現実なのです。こんな状況では、開発者はプロジェクトをうまく運営したいと考えるより、「ともかく早く家に帰りたい」というのが本音ではないでしょうか。

PDCAサイクルに潜む阻害要因

　しかし会社もこのような状況を放置しているわけではありません。開発力強化のためのさまざまな取り組みを行っています。苦境から何とか脱却すべく、すなわち人間の体力に頼った開発から、マネジメント（管理と統制）を基本とした開発体制に変えていこうとしているのです。

　例えばPMBOK（注1）という、プロジェクト業務に関するマネジメント体系は多くの会社で広く導入されています。ところが不思議なことにマネジメント体系であるこのPMBOKを導入し、開発マネジメントを実施しようとすると多くの困難に遭遇するのです。なぜでしょうか。マネジメントとはデミング博士（注2）の提唱したPDCAサイクル

• 計画（P：Plan）
• 実行（D：Do）
• 確認（C：Check）
• 対策（A：Action）

を回していくことです。多くの困難に遭遇するということは、このサイクルを阻害する何かが開発現場に存在するということになります。そこで次ページ以降、マネジメントサイクルを回すために、現場でPDCAそれぞれにどんな問題があるかを具体的に見ていきましょう。

注1：PMBOK（Project Management Body of Knowledge）　米国プロジェクトマネジメント協会（PMI）が取りまとめたプロジェクトマネジメントに関する知識体系。各種プロジェクトを実施する際のフレームワーク──基本的な考え方、手順、ツールとして利用される。事実上の国際標準になっている。

注2：W・エドワーズ・デミング　アメリカ合衆国の統計学者、大学教授、著述家、講演者、コンサルタントである。第二次世界大戦時にアメリカの生産性向上に尽力したが、それよりも日本で行った業績でよく知られている。1950年から日本の企業経営者に、設計／製品品質／製品検査／販売などを強化する方法を伝授した。