先週の金曜日、京都経済フォーラムで「関西設計管理研究会」（略称KEAC）に呼ばれて講演させていただく機会を得た。テーマは『エンジニアリング・マネジメントの役割と価値 〜 プロジェクトの視点から設計をとらえ直す』である。幸い活発な質疑を得て、それなりに好評だったのではないかと感じている。
テーマは設計業務をたばねるエンジニアリング・マネージャーの仕事だったが、前提として、プロジェクトとは何か、という説明から入った。設計という仕事には、厳密な意味での繰返し性がない。すくなくとも、全く同一の図面を繰返し作成するということは、決してしない。これは工場の製造業務と対照的である。工場では同一の部品を繰返し作る。その繰返し性が、PDCAサイクルによる改善の基礎となっている。
ところで、世界で最も通用している「プロジェクト」の定義は、PMBOK Guide(R)による、「独自の製品、サービス、所産を創造するために実施される有期性の業務」という定義だろう。冒頭の『独自』の原語は Unique で、これはつまり、全く同一のものは他に無い、という意味である。だとすると設計業務は全て、プロジェクトといえるのだろうか?
わたしの答えは、留保付きのNOである。ある種の条件がそろえば、設計業務はプロジェクトとなる。上記の抽象化されたプロジェクトの定義では分かりにくいのでは、わたしは普段、学生などにはこう説明している。「プロジェクトとはある種の活動で、次の三つの条件を満たすものである」
達成すべきゴールが決まっている （完了条件）
複数の人間が協力して行なう （協力条件）
失敗のRiskを伴う （リスク条件）
これらがなりたてば、その活動はプロジェクトと考えることができる。そして、プロジェクト・マネジメントの手法を適用すると、効果的である。
プロジェクト vs. 定常業務：ここが違う
プロジェクトの最大の特徴は、達成すべきゴールが決まっている、終わりがある仕事だ、という点だ。これをPMBOKなどはTemporary（有期性の・時限的な）と表現している。言いかえるとプロジェクトは、終わるために努力する仕事である。ところが、ふつうの仕事（これをプロジェクトと対比するために『定常業務』と呼ぶことにする）は違う。定常業務とは終わらないために努力する仕事である。我々の毎日の仕事は、会社が終わってしまわないように努力している。方向性が真逆なのだ。
ゴールがあるために、プロジェクトには『進捗』の概念が必要になる。これも定常業務との違いだ。定常的な業務をしている、例えば銀行の窓口に行って、「今日の進捗はどれくらいですか？」と聞いても、答えは返ってくるまい。だがプロジェクトでは、進捗を正確に、できれば数値化して、把握したい。
またプロジェクトは1回限りのユニークな存在であるため、通常の意味PDCAサイクルが成り立たない。改善すると言っても、前回と条件が違うのだから、何を比べるのか。
加えて、プロジェクトのチームは「その場限りの」（Temporaryな）組織である。 普通の会社の部門は、基本的に全て永続的な組織だ。 実際には組織改編などもあり得るが、設計を担当する技術部門が、来年は急に消失するかも、などとは誰も考えない。永続的な組織では、人の育成や人事評定、昇進などが非常に重要になる。 その場限りのプロジェクトチームでは、これらは必ずしも重要ではない。大事なのは各人の現在の技量とパフォーマンスである。どんなに優秀でも、「終わるための努力」に役に立たなければ、プロジェクトチームにとって価値は無い。
定常業務のマネジメント研修は役に立たない
1つ目の条件だけでも、これだけの違いが見えてくる。プロジェクトは定常業務とは相当に異なる仕事だとわかる。それなのに製造業を始め、多くの企業では、定常業務とプロジェクトの違いを理解しないまま、様々な施策を進めてしまう。
新たに部下を持ったり後輩を指導する立場になったりした中堅層に対して、新任管理職研修やリーダーシップ教育を行う企業も多い。内容としては、ビジネス系の知識教育と、「心構え」「人間力」系のスキル教育の組合せだろう。知識教育といっても経理と設計と営業では業務知識が全く異なるので、集合研修では主に、会社経営とか財務などの共通知識になる。無論、KPI目標設定をしてPDCAサイクルを回せとか、部下の育成評価手法といった、共通的なマネジメント論も含まれる。
しかし、こうした定常業務のマネジメント手法が、プロジェクトにうまく当てはまらないのは、上に述べたとおりだ。プロジェクト・マネジメントに固有の、スコープをWBSに構造化するとか、チーム組織と役割・責任マトリクスを作るとか、実行予算表を作って実績出費と進捗率とETCを追いかけるとかいった、特有のマネジメント手法の知識は手薄なままだ。
そもそも会社自体が、そうした領域のマネジメント技術の存在をよく理解していない場合も多い。知らなければ教えることはできない。教わらないから、プロジェクトのリーダー達も、PDCAサイクルとKPI測定とか、部下の動機付け（プロジェクト・チーム員はプロマネの部下とは限らないのだが）といった手法で立ち向かうことになる。
だが、当然ながら各人が真面目に一所懸命に頑張っても、なぜだか成果が上がらなかったり、度重なる変更やスケジュール遅れでモチベーションが下がったりしていく。プロジェクト・マネジメントとして必要な対策を、適切なタイミングで打てていないからだ。それはちょうどオーケストラに対して、指揮者が適切なタクトを振れずに、演奏がバラバラになっていくのに近い。これを、「気合いと根性」で解決できるだろうか？
PMに必要なハード・スキルとソフト・スキル
プロジェクト・マネジメントの能力は、じつはプロマネ個人の能力だけでなく、プロマネを支える組織全体の能力である。図は以前の記事からの再掲だが、プロマネが仕事を進めるためには、プロジェクトに向いた業務手順やWBS体系、適切なPMソフトウェア、そして過去プロジェクトのデータなどが必要だ。これはプロマネ個人の頑張りでカバーできるものではない。
かりにプロマネ個人の能力に限っても、そこには知識中心のハード・スキル面と、「人間力」みたいに総称されるソフト・スキルの面がある。ハード・スキルは座学で伝えやすい。だから育成ではまず、こちらを勉強してもらうべきだ。わたしは複数の大学でPM講義をしているが、75%以上の時間は、この知識面を伝えるのに使う。拙著「世界を動かすプロジェクトマネジメントの教科書」も、ストーリー仕立てにはしたが、この面が中心だ。
しかし「人間力」的なソフト・スキルは違う。コミュニケーション、交渉、決断、問題解決といったソフト・スキルは、知識伝達だけでは不十分で、繰返し練習しないと身につかない。その練習の場は、職場が用意する必要がある。
もちろん一般のリーダーシップ教育でも、ソフト・スキル面はある程度、カバーするのが普通だ。コミュニケーション、信頼関係構築などは定常業務でも必要だからだ。しかし、プロジェクトのアウトカムから適切なアウトプットを導き出す「構想力」や、必要なアクション群とリソースを導出する「計画力」などは、おそらく十分ではない。
普通の会社のための、普通のプロジェクト・マネージャーはどうあるべきか。最近はこの問題を考え直している。旧著「世界を動かすプロジェクトマネジメントの教科書」についても、できれば改訂版ないし続編を構想しようと思っている。通常のリーダーシップ教育だけでは、プロマネ育成には不十分なのだ。多くの企業がプロジェクトの進め方について悩む中、わたしのささやかな知見が役に立てられれば、と願っている。
＜関連エントリ＞
「ふつうの会社のためのプロジェクト・マネジメントとは ～ モダンじゃないPMの特徴」 (2026-02-08)
「製造業のプロジェクトがうまく進まない、本当の理由」 (2024-12-01)
]]>