先日，情報システム構築のプロジェクトマネジメント支援を手がけているコンサルタントに，「IT業界とエンジニアリング業界のプロジェクトマネジメントの違い」について話を伺った。彼は，エンジニアリング業界でプラント建設のプロジェクトマネジメントを経験した後，IT業界でのコンサルティングに携わっている。

　彼によれば「IT業界のプロジェクトマネジメントはエンジニアリング業界に比べて数年は遅れている」そうだ。例えば，IT業界ではWBS（Work Breakdown Structure）の作成もEVM（Earned Value Management）も，すべてのプロジェクトにおいてきちんと実現できているとは言い難い。ところが，「エンジニアリング業界では（どちらも）80年代初めから確立されている」（同）。

　エンジニアリング業界のプロジェクトマネジメントでは「常識」だが，IT業界ではできていないことは多い。例えばエンジニア業界では，オーナー（石油会社など）が極めて詳細で分厚いRFP（提案依頼書）を作成する。IT業界では，オーナー（ユーザー企業）が自力で詳細なRFPを作成できる企業は多くはない。

　また，エンジニアリング会社は，RFPに従って見積もる際，「デビエーション・リスト」（RFPとの差異の一覧）を作成し，オーナー側と交渉，納得してもらう。これにより，仕様が明確になるため，「追加は認めない」とエンジニアリング会社側が言いやすくなる。オーナーに文句を付ける「クレームレター」のひな形まで用意されている。厳密な仕様変更管理も可能になる。これも，仕様変更が相次ぐIT業界と異なる点である。

　最近では3次元CAD（コンピュータ支援による設計）によるシミュレーションで，事前にオーナーやエンジニアリング会社などのステークホルダーが完成物をビジュアルに確認することにより，仕様変更自体も激減しているという。

　契約時には石油会社などのオーナーが，ドキュメントの種類やミーティングの時期，議事録の作成義務，組織体制，役割分担などの作業手順を詳細に記した「コーディネーション・プロシジャ」（契約書の付属物）を作成。これらの膨大なドキュメントに厳密に従いながら，エンジニアリング会社はプラントを製造することになる。コーディネーション・プロシジャに相当する文書を作成しているシステム開発プロジェクトは，そう多くはないだろう。

　プロジェクト・マネジャー（PM）の権限も違う。エンジニアリング業界では，専門職としてのPMの権限は，IT業界とは比較にならないほど高く，「並の部長より偉い」（先のコンサルタント）。PMの研修制度もしっかりしており，PMにはPM補佐が何人も付く。このPM補佐が，将来のPM候補となる。PM補佐が実際のプロジェクトマネジメントを経験しながら，PMへと育っていく仕組みができあがっているわけである。ただし，PMに求められるスキルは極めて高い。何千億円に及ぶプロジェクトの遅延は絶対に許されない。

　PMO（プロジェクト・マネジメント・オフィス）についても，エンジニアリング会社では昔からある。エンジニアリング会社のPMOには優秀なPMとPM補佐がプールされ，個別のプロジェクトを支援する。この点も，IT業界より進んでいる点だろう。最近ではPMOを置くITベンダーが増えているが，必ずしも優秀な人材を配置しているとは限らない。

必要な「オーナー機能」の強化

　もちろん，IT業界とエンジニアリング業界をそのまま比較するのは乱暴であることは百も承知である。まず歴史が違う。企業向けのシステム開発の歴史はたかだか30年。これに対し，例えばエンジニアリング大手の日揮は1930年代にエンジニアリング事業を始めている。受注金額も違う。エンジニアリング業界では数千億円規模の案件がある。IT業界とはケタが違うのだ。

　さらに，プラントは目に見える物であり，ソフトは目に見えない。加えて，プラント製造の場合は，フロー（処理の流れ）と配置図の「標準的なひな形」が存在している。これを基にオーナー側が詳細なRFPを作成できるわけだ。一方，ソフト開発の対象は複雑であいまい，機能も千差万別である。また，エンジニアリング業界では電気／計装，配管など，エンジニアの専門職種が確立しているのに対し，IT業界での専門職種の確立は始まったばかりである。

　とは言え，「プロジェクトをマネジメントする」という点は同じはず。とすれば，IT業界よりも長い歴史を持つエンジニアリング業界のプロジェクトマネジメントに学ぶ点は多いはずだ（「NET&COM2007」での関連セミナー）。

　実際，上で述べたPMの育成や権限，PMOの質の向上については，多くのITベンダーが取り組んでいる。エンジニアの専門職種の確立についても，多くのITベンダーが取り組んでいる。

　ただ，いまのままではどうにもならない問題がある。それは「オーナーの弱さ」だ。先述したように，エンジニアリング業界では，標準的な処理フローや配置図を基に詳細なRFPをオーナー側が作成。それを基に厳密な仕様変更管理が可能となっている。詳細なコーディネーション・プロシジャにより，作業手順もオーナー側がコントロールする。

　要するに，エンジニアリング業界では「オーナーが強い」のである。実際，エンジニアリング会社の元PMは，「オーナーであるエクソンやモービルなどの石油メジャーに教えられたことは多い」と語る。エクソンやモービルなどの強力なオーナーを相手に商売をしているうちに，エンジニアリング会社のプロジェクトマネジメントも洗練されていった，という構図だ。

　エンジニアリング業界における処理フローや配置図は，システム開発では「業務プロセス」に当たる。そして，これを作成できるのはオーナーしかいない。詳細なRFPの作成も，作業手順書も本来はオーナー（ユーザー企業）が作成すべきだろう。システムはオーナーのものなのだから。

　とは言っても，システム部門の縮小や子会社化，アウトソーシングなどにより，システム開発にかかわるユーザー企業の「オーナー機能」は（一部の先進企業を除いて）弱い。これが，システム開発に関する大きな問題であることは，同意していただけるだろう。このために，業務プロセスの明確化やRFPの作成，システム開発の作業手順に至るまで，かなりの部分でITベンダーの手を借りざるを得ない状況になっている。

　しかし，オーナー（ユーザー企業）とITベンダーでは，根本的に利害は一致しない。ITベンダーがいくら「オーナーの立場になって考える」と言っても，ITベンダーの最終的な目的は自社が儲けることだからだ。

　そこで，記者が必要だと思うのが，オーナーの立場に立って業務プロセスの明確化やRFP作成，作業手順の作成，ベンダーの選定までを支援する，ITベンダーとは独立したコンサルタントである。オーナー側は人材不足。ITベンダーとは利害が一致しない。となれば，ITベンダーとは独立してオーナーを助けるコンサルタントが必要になるのは，自然な流れだろう。これをコンサルタントと呼んでいいのかどうかは微妙だが，要はオーナーとITベンダーの橋渡しをする役割だ（ITベンダーからは煙たがられる存在だろうが）。

　この役割を果たすには，高度な経験とノウハウが必要になるが，IT業界では現在多くのベテラン・エンジニアが，リタイアしつつある。その中には，業務もITも分かった上でプロジェクトマネジメントもこなせる優秀な人材もいる。

　今後は，団塊の世代前後の優秀なベテランが，オーナーの立場に立ったコンサルタントを担うべきだと思うのだが，いかがだろうか。数は少ないが，すでにそうした会社はいくつか登場してきている。こうしたブリッジ的な役割が産業として成り立つようになれば，日本のIT業界はもっと良くなると思う。