PMにはなぜ設計論がないのか？

前回の記事（「プロジェクト＆プログラム・アナリシス研究部会」（12月2日）開催のお知らせ）でも少しふれたが、なぜPMBOK Guide(R)には「設計論」がないのか、不思議に思われている方も多いと思う。米PMI (Project Management Institute)が'90年代に作成し、現在は改定第６版になっているPM界の標準ガイドブックは、10個のマネジメント領域を定義している（最初は9個だったが、途中からStakeholder Engagementが加わって、10個になった）。その10のエリアには、「調達」や「品質」があるのに、肝心の設計マネジメントがない。

プロジェクトにおいて、もしも設計がまずかったら、実装段階でどんなに頑張っても、良いプロダクトは生まれない。つまりプロジェクトの価値は上がらない訳だ。プロジェクト・マネージャーの任務は、プロジェクトの価値を最大化することのはずである。だとしたら、なぜ、設計論が欠落しているのか？

どうやら、初期のPMBOK Guideを作った人たちの頭の中には、設計（Design）の重要性の概念がなかった、としか思えない。その結果、今頃になって、やはりプロジェクトの成功には、良い基本設計が欠かせない、と気づいた。だからPMIはビジネス・アナリシスの標準プラクティスを制定しようとしたりしている。

ちなみに、設計と実装が一つのプロジェクトの中で一貫して行われるか、それとも別の企業に担われるかについては、業界および国の慣習によって、まちまちである。

たとえば、ビルや橋などをたてる、いわゆる一般建築や土木建設の分野についていうと、日米でバターンが異なる。基本的に、米国の建設会社には、設計機能がない。この点は日本のゼネコンと大きく異なっている。日本のゼネコンは（とくに大手は）かなりレベルの高い設計部門を抱えていて、独立した建築設計事務所と張り合っている。そしてしばしば、「設計施工一貫」という方式でプロジェクトを受注する。

しかし米国や英国は違う。建築設計は、設計事務所にいるアーキテクト（建築家）たちの専任事項である。アーキテクトがデザインした図面と仕様書をもとに、建設会社が工事をする。工事が図面通り適正に行われているかを、建築事務所がチェックする。この仕事を日本語では設計監理とよぶ（同じ音の「管理」と区別するため、「さらかん」といったりする。監の漢字の下にお皿があるからである）。設計と施工を分業するので、「設計施工分離」方式と呼ぶ。

このような分業と相互チェックの体制になっているため、英米の建設会社では一般に、設計機能を持たないのである。そして彼らは、工事のプロジェクト・マネジメント能力をもっぱら売り物にする。

ちなみに日本の官公庁のかかわる一般建築は、制度を英国に見習ったためだろう、同じように設計施工分離の方式がベースになっている。そして原則として、設計の後、工事は入札が行われる。だがふつうの民間工事では、しばしば同一のゼネコンが設計も施工も行う。理由の一つには、途中で工事入札をはさむよりも、全体期間が短くなるためである。

一般建築の他にも、発注者である官庁側が基本仕様の定義や基本設計までを行い、受注者が詳細設計と実装（製造）を担う、という業界はまだいろいろと存在する。米軍と軍需産業の関係なども、わたしは詳しくは知らないが、実はそうなっているのではないか。だから初期のプロジェクト・マネジメント概念を育てた米国の航空宇宙産業だって、似たような感覚があったのもしれない。

ちなみに、わたしが働いているプラント・エンジニアリングの業界は、両方のパターンが存在する。原則として、基本設計（業界でFEED = Front-End Engineering Designと呼ばれる）と、詳細設計・調達・建設（EPC = Engineering, Procurement & Construction）とは、別フェーズで遂行されるのだが、どちらも担うのは同じエンジニアリング業界の企業であり、プレイヤーが一般建築のように分業化していない。

おまけに、FEEDとEPCを一貫して遂行するプロジェクトも、ときどき存在する（とくに入札による透明性よりも工期短縮を重視する私企業が発注者の場合）。だから、エンジニアリング業界では、PM能力の重要な要素として、『エンジニアリング・マネジメント』が入ってくるのだ。

話を戻すが、設計と施工（実装）を受け持つ会社が別々になっていて、前者はデザイン能力を、後者は実装のプロジェクト・マネジメント能力を売り物にする、という業界にいる人達は、PMの技術の中に設計論がなくても、不思議はないだろう。

ただし、設計と実装が会社（業界）として分離していると、まずいこともある。

一番大きな問題は、実装段階における技術やノウハウが、設計段階にフィードバックされにくい点だ。たとえば、ビル建築の世界で、新しい建設工法が開発されたとしよう（たとえばジャッキアップ工法など）。当然ながら、その工法を活かせるような設計が必要である。しかし建設工法の開発はゼネコンが行っていて、そのノウハウは建築設計事務所にはすぐに共有されない。

製造の分野でも似たような事情はあるはずだ。新しい加工方法（たとえば3D printerによる金属積層造形など）が開発されたとしても、設計はデザインハウスが行い、製造は受託製造企業EMSが行う、というような分業が進んでいると、製造技術の進歩がすぐに設計に取り入れにくくなってしまう。

つまり、設計と実装が分離した形でプロジェクトを進められるのは、実装技術の進歩がゆっくりしている分野のみだ、とも言えよう。

もちろん、設計段階はスコープが柔らかく、実装段階に入ると、スコープはかなり固まるのが常だ。だから、発注者と受注者がフェアなリスク分担をはかるために、あえて設計と実装のフェーズを分けて、設計段階は実費償還型契約（日本のIT業界の言い方でいえば準委任契約）で行い、実装段階は一括請負型契約で行う、というのはもちろんあり得る。ただ、これはプロジェクトのフェージング技法であって、だからプロジェクト全体における設計マネジメントの重要性が減る、というわけではない。

あるいは、アジャイル開発のケースを考えてもいい。アジャイル開発はソフトウェア分野特有の方法論だが、設計と実装を細かな単位のサイクルで回し、機能を順に付加していく。アジャイル開発活動の主要なモチベーションは、それまで設計の下請け状態に置かれていた実装の仕事を、設計と同格の位置に持ち上げたい、というプログラマたちの悲願にあった。だからあえて、設計と実装が渾然一体となったグループ組織で進めるのだ。

下請け。そう、IT業界では長らく、SI系の受託開発プロジェクトを、大手計算機メーカーが「ゼネコン」として元請け受注し、実装部分を子会社や関係会社に下請けに出す、という業務形態がとられてきた。設計と実装の分業は、建築分野のような業界単位の棲み分けではなく、「企業の順位」を基準に行われてきた。何やら江戸時代みたいな「身分差」で決まる、とさえ言いたくなる実態があった。

そのくせ、元請けの大企業が担うから、設計品質や設計マネジメントはちゃんとしていた、と言えるかは、けっこう疑問なのである。システム設計とは、どういう仕事なのか。設計の品質（「前向き品質」）はどう、とらえるべきか。いわゆる「システムズ・エンジニアリング」の手法は、ITシステムの設計に応用可能なのかどうか・・とった設計に関する本質的な議論を、あまり聞いたことがない。聞こえてくるのは、開発方法論と、ソフトウェア工学の手法論がせいぜいだ。

もしも日本の大手IT企業が、本当に設計に大きな価値を認めているならば、SIビジネスの利益構造は別の形になっているべきだった。すなわち、「設計段階」で大きな報酬を得て、「実装段階」では、かつかつの利幅で受ける、という風になるはずである。だって良い設計のほうが、正しい実装よりも、ずっと顧客にとって価値が高いのだから。そしてエンジニアという人種は、何より、優れた知恵をお金に変えたいと願う存在だ。

しかし、現実にはそうならなかった。SIビジネスは、なんといっても実装部分で、全体工数の人月に比例して売上と利益を得る構造になっていた。このようなビジネス慣習の元で、設計の重要性がハイライトされるだろうか？　

米国PMIが'90年代にPMBOK Guideを作成するにあたって、設計論のエリアを省略してしまったのは、彼らの国の事情があったのだと想像する。日本が（とくにIT業界が）それを広く受け入れたのは、2000年代に入ってからだ。だが、爾来10数年間、誰もあまり設計マネジメントの欠落を、問題に思ってこなかった。それはとりもなおさず、設計という仕事を、価値の源泉ではなく、単なるコストの一部だととらえてきた結果に思えるのである。

＜関連エントリ＞

　→「システムズ・エンジニアリングとは何か」https://brevis.exblog.jp/25682507/（2017-04-09）

　→「設計の価値」 https://brevis.exblog.jp/2408181/ （2006-01-01）