製造業のプロジェクトがうまく進まない、本当の理由

• プロマネはどこにいるのか？

先日、名古屋工業大学で開催されたプロジェクトマネジメント学会中部支部のシンポジウムに参加し、アビーム・コンサルティングの阿部さんと一緒に講演をする機会があった。メインテーマは「MES導入のための標準業務テンプレート」の紹介で、我々の研究会で開発リーダーである阿部さんが解説されたが、わたしはその前振りとして、製造業におけるプロジェクトの共通課題についてお話しした。

わたしが訴えたかった共通課題とは、一言でいうと『プロマネ不在問題』である。プロジェクトは必要があって発足し、進んでいくのだが、肝心のプロマネが誰だか分からない。大事な決断を誰が下し、誰が権限と責任を持つのか分からない。そんなバカな、と思う人もいるだろうが、しばしば見かける現実である。こんな状態では、ものづくり改革だとか工場スマート化などが、うまく進むわけがない。

プロマネが誰だかわからないのだから、「プロジェクト・マネジメント計画書」なども、きちんと存在するわけがない。当然ながら、ベースライン計画を前提としたマネジメント・プロセスも機能するわけがない。つまり、普通の意味でPM標準が規定するような知識や技術は、適用されない（適用しがたい）ことになる。

日本PM学会は、米国PMIが策定したPMBOK Guide(R)の紹介活動や、最近は欧州IPMAとの提携によるPM標準の普及などを進めている。そしてPM学会の構成員の大多数を占めるIT業界では、確かにプロマネなりプロジェクトリーダーなりの職種も、かなり確立してきた。しかし、プロマネすら不在の組織では、PMBOKの10のマネジメント領域どころではない。非常に大きなギャップが存在する。どうしてこうなのか？

• 製造業におけるプロジェクトとは

ずいぶん以前のことだが、プロジェクト・マネジメントの本を読んでいたら、

「『プロジェクトはタコ壺であり骨壺だ。一度入ると生きては戻れない』－－こんな感想をよく耳にする」

と書かれていて驚いたことがあった（「書評：『はじめてのプロジェクトマネジメント』近藤哲生・著」 ）。著者は製造業の重鎮・日立製作所のOBである。「そういう会社なんだなあ」と、当時思った（今は違うのかもしれないが）。

日立は製造業であり、かつIT受託開発の元請けもやる会社だ。だがIT受託の分野をもたない普通の製造業でも、実際には様々なプロジェクトに取り組む必要がある。それは新製品開発プロジェクトであり、新工場ないし製造ライン増設プロジェクトであり、新販路開拓プロジェクトであり、あるいは業務改革プロジェクト（これにはしばしば、ITシステム開発プロジェクトが付随する）であろう。ものづくり改革とか工場スマート化は、最後のカテゴリーの一つと捉えても良い。

これらのプロジェクトに共通する1つの特徴は、複数部門の協力がいる点だ。もちろんそれはプロジェクトの規模や複雑性に依存する。比較的シンプルな製品のバージョンアップに伴う新製品開発などは、設計開発部門だけで完結するかもしれないし、 小規模なラインの増設は、生産技術部門だけでほとんど終わるだろう。仮に他部門の協力が必要だとしても、業務上隣接する部門、例えば企画部門と設計部門、あるいは生産技術部門と製造部門といった、接点の多い部署との調整で良い。

ところが、新しい製品ファミリーを作るようなタイプの新製品開発では、企画・設計・研究・生産技術・調達・製造・物流・営業…といった、かなり多数の機能部門が関わることになる。 そして、それぞれの部門は、お互いに異なる目標やKPIの尺度を持っていて、意見調整が簡単にいかないことがある。大型の新工場建設や、未経験の地域や国での販路開拓などでも、似たような事情が起きやすい。

• プロジェクトは部門横断（クロス・ファンクショナル）な取り組みである

日本企業は業務を回す実務レベルの人々が優秀で、それなりに権限範囲を持ち、隣接する部門同士の調整は上手にできると、前回の記事で書いた。 しかし、隣同士でのすり合わせで問題が解決しない場合、問題の全体構造を見た上で、誰かが決断を下す必要がある。それは本来、プロジェクト・マネージャーの役割である。

問題の全体構想とは何か。それはプロジェクトの予算であり、納期であり、またスコープ＝責任範囲（役務範囲）の制約である。 製造業の3大パフォーマンス目標値がQCDで、トリレンマの関係にあることを前回記事で書いたが、 プロジェクトでは、一般に品質の代わりにスコープ（役務範囲）をとる。これはスコープが全体の仕事量を表すからだ。品質を 確保するためのレビューやテスト等のアクティビティーもスコープの中に含まれるため、このようにする習慣だ。

そしてこの3つもトリレンマの関係にある。どれか1つを変更すると、他の2つに何らかの影響が及ぶ。だからプロジェクト・マネージャーの1番大切な仕事は、この3つの制約条件の中で、プロジェクトの価値を最大化するような選択肢を探して、決断することにある。

決断のためには、プロジェクト・チームの中で議論を戦わせ、様々な事実認識を共有し、いろいろな方策・オプションを提示し検討することが大切だ。だが、最終的には何らかの決断を下さなければならない。そして決断はタイムリーに行わなければならないのが、プロジェクトの現実である。

ところで、ほとんどの製造業は、機能別の組織になっている。1番上に経営者がおり、それを支える形で人事・財務といった本社機能と、研究開発機能があり、そしてライン業務を受け持つ部門が並ぶ。具体的には営業であり、技術、製造、物流などである。では、プロマネのいるべき部門はどこなのだろうか？

• 機能型縦割り組織と、プロジェクトの論理

ところで読者諸賢は、上のようなピラミッド型の組織図で、各部門を結ぶ線のことを、何と呼ぶかご存知だろうか？　英語では、これをレポーティング・ライン(Reporting line)という。 つまりレポートする（報告する）線である。「私の上司はジョンだ」を、英語では "I report to John"と表現する。 組織図の線は、報告及び指示を伝達するコミュニケーションのルートを意味している。

すなわち、組織における公式なコミュニケーションは、この線を経由しなければならないルールなのである。もちろん、昼食時に食堂でおしゃべりしたり、休日に一緒にスポーツを楽しんだりするような非公式のコミニケーションは、個人同士で直接行って構わない。

しかし例えば新工場プロジェクトで、検査部門の担当者が、生産技術部門の工程設計技術者に対して、新しい検査装置についての要望を出すとしたら、 本当は検査課長から製造部門長に上げて、技術部門長を通って、生産技術課長経由で下ろさなければならない。 これがピラミッド型機能別組織の、本来のルールなのである。

だがご存じの通り、部長同士が定例的に顔を合わせる部長会など、週1回か隔週である。プロジェクトの連絡調整を、いちいちそのルートでやっていたら、日が暮れてしまう。そして各部門は異なる目標値KPIと、異なる利害意識を持っている。それらが対立した場合、誰が意見調整をするのか？　まさか多忙な社長が、いちいちプロジェクトの個別の決断を下してはいられまい。

そこで本来は、経営者がプロジェクトに必要な権限と予算と責任を、『プロジェクト・スポンサー』という役職に委譲する。そしてスポンサーはプロジェクト・マネージャーを任命して、プロジェクト実務に専任させる、という建て付けでPMBOK Guideなどはできているのである。プロマネは、手を上げて自分でなるものではない。スポンサーが（あるいは、プロジェクトの上位にプログラムがある場合は、プログラム・マネージャーが）任命するものなのだ。

プロマネは、プロジェクト・チーム内の意見をとりまとめて、必要な決断を下す。決断を下すからには、その結果についても責任を持つ。それでも、周囲のステークホルダーが納得しないような重大な問題がもしも生じたら、スポンサーが経営層を通じて説得・調整を行う。これが欧米などのPM標準を貫く思考原則なのである。

• 製造業のプロジェクトは、「プロジェクト以前」に真の問題がある

ところが、日本の多くの製造業では、こうした思考習慣自体が存在しない。だから、プロマネ不在のまま、プロジェクトが始まってしまう。

拙著『世界を動かすプロジェクトマネジメントの教科書』 も、じつはこの問題を取り扱っている。本書の内容は元々、東大や静大の大学院でのPM講義がベースだが、講義そのままでは面白くないので、ストーリー仕立てに設定した。主人公は製造業の若手エンジニアである。年齢は30歳そこそこ。まだプロマネに立てるような年代ではない。

ところが彼の会社では、社長の思いつきで突如、アジア新興国の海外企業との「共同製品開発プロジェクト」が走り出すのだ。とはいえ、誰がプロジェクト・マネージャーなのかも、定かでない状態なのである。

主人公は設計部門に属していて、彼の直属上司の課長は本プロジェクトに大いに乗り気だが、その上の部長は腰が引けている、といったシチュエーションになっている。どう見ても、このままではプロジェクトはうまく行かない。そしてその問題は、担当者である自分の上に被さってくるはずだ。

危機感を覚えた主人公が、偶然空港で出会った大学時代の大先輩に、「プロジェクト・マネジメントの基本を教えてください」と他の頼み込むところから、本書のストーリーは始まる。単なる担当者の立場でありながら、主人公はどうプロジェクトを動かし、リスクを乗り越えていくべきか？

無論、著者としては主人公をこのまま放り出しておく訳にはいかないから、製造業の組織論に即した現実解の一つを、本には書いている（ご興味があれば、ぜひお読みくだされ^^）。でも、こういう風に進むかどうかは無論、個別の企業の状況によっている。

長引く不況の間、日本の製造業は、差別化を求めて新製品を開発し、新興国などの市場を開拓し、あるいは海外工場の移転などで活路を求めてきた。それらは皆、プロジェクトだ。だが、プロマネ不在の機能型組織でプロジェクトを進めたって、納期もコストも守れず、目指したアウトカムは得られまい。失われた30年は、製造業におけるプロジェクトの不調がもたらした結果である。

そして、その真の理由は、PMBOKみたいなPM標準が普及しない事にあるのではない。もっとそれ以前のところ、企業がプロジェクトを『プロジェクト』だと認知していないこと、決断が必要なのにプロマネが不在なことに起因するのである。

＜関連エントリ＞

「書評：「はじめてのプロジェクトマネジメント」　近藤哲生・著」 https://brevis.exblog.jp/10266445/ (2009-05-18)

「製造業のトリレンマ・QCDを決めるのは誰か」 https://brevis.exblog.jp/33340696/