設計の能力と、設計マネジメントの能力はまったく別物である

• 「設計」＝モダンPMにおけるミッシング・ピース
  

先日の記事でもお知らせしたように、9月5日に行われた「PMシンポジウム2025」（日本プロジェクトマネジメント協会）で、「PMから見た『設計』論の課題」という講演をさせていただいた。ちょうど台風が関東に近づき天気の良くない中、会場までおいで下さった聴衆の皆さん、またオンラインで参加された皆さんにお礼を申し上げたい（講演自体はまだオンデマンド配信でも視聴可能）。

ちなみに、日本におけるPM業界の事情に詳しくない読者のために、念のためご説明しておくと、今回のシンポジウムを主催したのは、PMAJと略される団体である。'90年代に経産省の肝いりで、（財）エンジニアリング協会のバックアップのもと設立された日本発の団体だ。このほかに、（社）PMI日本支部という大きな団体もあり、こちらはPMIJと略されたりもする。 米国発の世界的な団体であるPMI(Project Management Institute)の日本支部として設立された。

世界的に有名なPM標準であるPMBOK Guide(R)は、後者のPMIが'90年代はじめに米国で制定したもので、PMP資格試験とともに、世界中に広まった。最新版は第7版で、今年中にも第8版が出ると言われている。一方、日本のPMAJの方は、 プログラム・マネジメントを包括した「P2M(Program & Project Management) 標準ガイドブック」を2001年に制定し、昨年第4版を公開した。わたし自身は、第3版の執筆に協力し、第4版はレビュアーとして参画している。

にもかかわらず、今回はあえて、“モダンPMにおけるミッシング・ピースを考える”との副題を付けて、P2MにもPMBOK Guideにも欠けていると思われる、『設計論』をとりあげてお話しさせていただいた。

• 設計論の課題とは
  

皆さんにお話ししたかったポイントは、大きく3つある。

(1)成果物の設計は、WBSを通じてプロジェクトの組織や遂行戦略に影響する、ということ。

(2)設計のうち最も価値が高い仕事は、機能を満たすよう形状・構造と制御機構を合成する『逆問題』であって、 それはサイエンスとアートの両面を持つこと。

(3) 設計のマネジメントは、優れた設計を行うこととは別の仕事であって、その中心には設計変更のコントロールがあること。

具体的な内容については、ここでは繰り返さない。講演資料をダウンロードし読んでいただくことも可能だし、本サイトでも折りに触れて記事にしてきた。いい足りない部分は今後も書いていくだろう。

さて、講演の後で何人かの方から、「なぜPM標準には設計が欠けているのでしょう？」という質問をいただいた。わたし自身もPM標準の創世期に直接関わったわけでは無いから、想像でお答えするしかないが、こんなふうに申し上げた：

• なぜPM標準には設計が欠けているのか
  

初期のPMBOKは、建設・エンジニアリング業界や防衛宇宙業界など、受注産業の人々が中心になって作り上げたと聞いている。米国は契約社会で、受注契約時にはかなり明確にスコープを規定する。つまり基本設計や標準仕様や規定類がかなり固まった状態で、契約する訳である。

特に一般建築分野では、英米は明確に設計施工分離の原則で動いており、設計は建築事務所が行う。建設会社には設計部門が存在しない（この点は、設計施工一貫の商習慣も強い日本のゼネコン業界とはだいぶん違っている）。このように設計と施工（広い意味での実装）がフェーズ的に分離しており、企業業種も異なっている。

このような文化の中では、「設計者は自立した知的プロフェッショナル」「実装は力仕事をやるだけ」という風潮も生まれやすい。初期のPM標準を作った人たちは、「バカにするな。実装をきちんと納期通り予算内に仕上げるマネジメントは、大変知的で高度な仕事だぞ」という気概を持って取り組んだ。だから資格名称にも、わざわざProject Management Professionalという語を選んだのだろう。

彼らがPMBOKの主要なマネジメント領域を決めた時（今は10個あるが初期は9個だった）、そこに「調達」があっても「設計」を入れなかったのは、そんな理由からではないか。

• 設計のマネジメントは、設計分野によって全く異なるのか
  

こんなふうにご説明したところ、ある方から、「設計と一口に言っても、土木とITシステムでは異なるし、同じくITといっても、業務系と基盤系では全く違う。PM標準は業界に依存しない原則だから、設計については書きようがなかったのではないか」とご指摘いただいた。

もっともなご意見にも思うが、わたしの考えは少し違った。「設計の仕事それ自体は、その通りです。しかし、ここで論じたいのは、プロジェクト・マネジメントにおける設計のあり方、すなわち設計マネジメントです。『マネジメント』の中核は、人に仕事をしてもらう事で、その中身は講演のスライドにも挙げたような項目からなっています。」

• 設計業務のWBS（作業項目タスクリスト）を作成する
  
• 設計のアクティビティに、それぞれの特性に適した担当者をアサインする
  
• 設計チームを組織し、基準・ルール等をインプットする
  
• 設計対象のボリュームを推算し、工数とスケジュールを見積もる
  
• 設計の進捗をモニタリングする
  
• 設計の品質をレビューする
  
• 設計に関わるインフォメーションと文書・図面類をコントロールする
  
• 設計変更をコントロールする
  
• トラブルの問題解決を行い、教訓（LL）をまとめる・・・等々
  

「設計を一人で完結できるような規模の仕事、たとえば個人の住宅建築とか中小企業の業務システムとかだったら、設計のマネジメントなんて別に要りません。しかし大人数で設計にとりからなければならない規模の仕事では、分担もあるし、期限や予算もあるし、品質も不揃いで変更も起きるし、取りまとめ役が必要です。

講演では大規模プロジェクトのプロマネを、オーケストラの指揮者にたとえましたが、作曲家（＝設計者）と指揮者は別の職能です。作曲者がタクトを振るのがいつでも最善、とは限りません。設計の能力と、設計マネジメントの能力はまったく別物だからです。

もちろん、設計のことを何も知らない人間が、設計マネジメントを完璧にできるとは思っていません。トラブルの問題解決にも、品質れビューにも、作業ボリュームの推算にも、それなりの分野知識と経験が必要です。ですが、設計能力と設計マネジメントの能力の重なりは、仕事の規模が大きくなるほど少なくなります。

わたしの勤務先のプラント・エンジニアリングでは、機械、土木、建築、電気、制御・・と1ダース以上の分野の設計領域が関わってきます。それを取りまとめるのが「エンジニアリング・マネージャー」職種ですが、一人で全部の領域の設計ができるスーパーマンなんて、いません。それでも、相手の用語がわかり、話が通じる程度には知っている。それが、設計マネジメントの仕事です。」

・・とまあ、こんな風なお答えをした。しながら、こう思った。土木プロジェクトとITプロジェクトは全く違う。確かに違うが、だとしたら業界を横断したPM標準など、作りようがないではないか。ただ、そこには共通したマネジメントのスキルと技術がある、とPM界の先人たちは信じた。

マネジメントとは「技術に秀でた者が、人の上に立つ事だ」という、日本社会の信憑も、そろそろ書き換えても良い頃なのではないだろうか？