/note/tech

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

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

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

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

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

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

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

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

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

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