もしSIerがまともなエンジニアリングの会社だったとしたらどんな仕事が考えられるか?

以前にも何度か書いたように私自身一応SIerと呼ばれる会社で(肩書き上SEとして)働いているのですが、このブログでSIerのことについて書くと、おそらく技術力のある優秀なPGの方からだと思うのですが、

なぜみんなSI業界から飛び出さないんでしょうね

真っ当なプログラマーを目指すのならSI屋には就職しちゃダメ

のようなコメントをいただくことが多いですね。本当にPGが技術力を発揮しようと考えたら、SIerやその下請け専門の会社ではなくて、最新のWebサービスをやっている会社とか、ネットゲームの会社とか優秀なPGにとってもっと働き甲斐のある魅力的な分野が他にたくさんあるということでしょうか。極端な話、外資系の銀行とか、海外で仕事をすべきという意見すら時々聞きます。
ただし、(私自身そういった分野で活躍しようと考えるほど最新の高度な技術力を持っているという自信がないというのもありますが)、私がもともとSI業界で働こうと思ったきっかけは、基幹業務を支える業務システムの開発というものに最大のやりがいを感じたというところにありますね。
実際、理論が整然と確立されており、仕様が明確に記述できるコンパイラーの開発とは違って、業務システムの要件はもともと無駄が多かったり、矛盾だらけだったり、重複が多かったりするわけです。しかも、要件はどんどん変更されたり、追加されたりします。そういう制約が多くぐちゃくちゃな世界から綺麗な構造を見つけ出して、機能拡張や変更に耐えられるアーキテクチャーを考え出していくというところに私は業務システム開発の本来の面白さがあるはずだと期待しました。業務システムは社会を支えるインフラを構築するという社会的な責任の面でも重要だし、プログラミング技術としても本来非常にチャレンジングで面白みのある分野であると信じていました。このブログでも紹介したファウラーなんかの本を読むとドメインモデリングリファクタリングなどの設計技法を駆使して複雑な業務要件を綺麗に解きほぐして無駄のない設計にしていくというようなことが書かれていますが、そういった手法によって、システム開発のやり方をもっとスマートに効率的に改善することができるに違いないと素直に信じてしまったということがあります。(私も若かった、笑。)
残念ながら、私のそうした期待とは違い、多くの場合企業の業務システム開発を担当する中心的な存在である大手SIerは大きなプロジェクトを請けて下請けに丸投げするITゼネコンと化してしまっています。*1だから、大手SIer側は技術の会社ではなくて、単なる人集めと営業のビジネスとなり、下請けの中小SIerソフトハウスの側は付加価値の低い単純労働作業となってしまっているという現実があります。Java EEや.NETのようなオブジェクト指向のプラットフォームやESBといった技術も既に何度も指摘してきたように現状あまり有効に活用されているとは言えないようです。
ところで、実は「SIerとは何か」という点を考えると、そもそも非常に分かりにくいところがあります。システムインテグレーター - Wikipediaだと、

システムインテグレーター(英語:System Integrator)は、個別のサブシステムを集めて1つにまとめ上げ、それぞれの機能が正しく働くように完成させる「システムインテグレーション」を行なう企業のことである。
日本の情報システムにおけるシステムインテグレーターとは、情報システムの開発において、コンサルティングから設計、開発、運用・保守・管理までを一括請負する情報通信企業である。SIerエスアイアー)とも呼ばれる。

と定義していますね。もともとの英単語の意味からすると前半の定義の通り、EAISOAなどの技術を使ってシステムを統合するのが仕事のように思われますが、実際はシステム統合案件ばかりやっているわけではなくて、業務システムを一括請負して開発したり、保守、運用、管理までやっている会社ということになるようです。歴史的な理由や雇用の問題からゼネコン化しているという実態はありますが、本来SIerという言葉自体にはエンジニアリングと対立するもの、PGと敵対するもの(?)という意味は含まれていないようです。
私は、SIerが初心に戻って本来のSIとな何かという点を考えなおすことで現状の請負中心のビジネス構造をある程度保ちながらも、本来あるべきエンジニアリングとしての仕事ができる道がないわけではないと思います。いくつかアイデアをあげると

  • SIerは業務フローやユースケース分析などシステムの純粋にwhatの部分のみ考え、画面定義や実装などhowの部分は実装者の自由に任せる。(howとwhatの分離)
  • SIerはシステム固有の業務知識が必要なドメイン層を実装まで含めて担当し、画面開発や帳票など業務知識があまり要らないところを専門の業者に外注する。(コアドメインと周辺機能との分離)
  • SIerはシステムの全体的なベースラインアーキテクチャ(もちろんモデル図だけでなくてソースコードも作成する前提。)やコンポーネントのインターフェース、SLA上の規約のみを決め、コンポーネントの実装を外注する場合中身の実装には口を出さない。実装の詳細や設計は下請けに自由に考えさせる。(インターフェースと実装の境界で役割を分担する)
  • SIerは名前のとおり、コンポーネントやサービスの統合案件を中心に仕事をする。(モノリシックな大規模アプリケーションの開発は避ける。)
  • SIerはユーザーの代理として最終的な機能試験、システム試験、性能試験を行う役割を担う。これらの試験のエキスパートを育成する。(試験タスクの体系化、知識集約化)
  • SIerは生産性の高い開発環境一式(ビルドシステムなどを含む)を構築、標準化する役割を担う*2(開発生産ライン構築)

この場合、最初の案はコンサルファームのように純粋に上流工程に特化した仕事となりますが、それ以外はPGまで含めて上流から下流まで担当する要素がある点に注意してください。少なくとも現状は建設業や製造業の発想で工程で上流、下流と分け商流の構造もその工程に対応したものとなっています。しかし、それ以外のオブジェクト指向、サービス指向、クラウドにより適合した方法で分離する方法もあってしかるべきと考えます。
ビジネスモデルとしては収益構造など難しい問題があるため簡単ではないはずですが、少なくとも現状のように工程で分離して下請けに丸投げする方法よりエンジニアリングの観点からもっと賢い方法があるのではと思います。そうすることでPG(この場合本来のSEを含めてもよい)がSIerでもっと活躍できる場所が増えるのではないでしょうか。しかも、顧客や下請けからもっと尊敬される会社になることができるのではないでしょうか。
※なお、SIerにはハードウェアなどシステム基盤や運用の仕事もありますが、ここではPGとして興味のある開発の部分に絞って考えました。

*1:こうなってしまった背景にはさまざまな合理的な理由が考えられるようですが。http://blog.goo.ne.jp/ikedanobuo/e/e4391dbc2cedccfac7d3b57061b2ab14

*2:最近は仮想技術を使って開発環境一式をオンデマンドで配置するといった技術もあるようです。