ITゼネコン構造と情報システムの品質

2011年2月17日(木曜日)

ITゼネコン構造と情報システムの品質

公開: 2011年2月27日21時20分頃

こんな記事があり、面白いと思いました……「新卒一括採用が「ITゼネコン構造」を生む (ascii.jp)」。

いわゆるITゼネコンは基本的に上流工程しか担当せず、コーディングは下請けにやらせるのが大半です。普通に考えると、「ITゼネコンは上流工程しかやらない」、だから「プログラマは不要であり、主にSEになる人材を採用している」という順番に思えますが、この記事では逆の見方をしています。

たとえばJavaのコーディング能力で採用すると、それを使うソフトウェアの開発をやめたとき、そのプログラマーが社内失業してしまう。日本以外の企業では仕事のなくなった社員は解雇されるのが普通だが、日本では解雇規制や「終身雇用」の規範が強いので、仕事がなくなってもクビにできない。

つまり、「大企業では解雇規制が強いために特定の言語に特化したプログラマが採用できない」ということが先にあり、それゆえに「ITゼネコンは上流工程しかできない」という分析ですね。非常に面白いと思います。

おそらく、プログラマについて以下のような前提があるのでしょう。

Javaのコーディング能力が高い人はJava以外の言語は書けないし、コーディング以外の仕事は全くできない。そのため、Javaの仕事が無くなると、その人には何の仕事もなくなってしまう。
IT産業では転職や独立のハードルが高いため、たとえ仕事が無くなっても転職や独立を考えることはなく、仕事の無い会社に居続ける。

あるいは、昔のプログラマは実際にそうだったのかもしれませんね。「Javaしか書けない人」はちょっと想像しづらいですが、「COBOLしか書けない人」なら想像できるような気がします。外部のシステムと連携することも今よりは少なかったでしょうから、一つの言語しか書けなくても問題なかったのかもしれないですね。

しかし、このような雇用慣行を続けた結果、日本のソフトウェア産業では親会社は仕様の決定と工程管理を行なうだけで、コーディングなどの専門的な仕事は下請けに出されるITゼネコン構造が生まれた。こうした構造は、高度成長期の製造業のように単純な技術で安くつくるブルーカラーが競争力の源泉だったときには、一定の合理性があった。
(～中略～)
ソフトウェア技術者の能力によってコーディングの能率は大幅に変わるので、才能のあるスターを何人もっているかで企業の競争力が決まる。だからソフトウェア企業はハリウッドのスタジオのような専門家集団になり、その中心はエンジニアやプロデューサーのようなクリエイターだ。ホワイトカラーはスターをサポートするマネジャーで、企業は芸能プロダクションのような才能の入れ物になる。
このような変化は、日本でも不可能ではない。

今や海外では、大規模な情報システムはITゼネコンではなく、「ハリウッドのスタジオのような専門家集団」によって構築されているのだそうで。海外の情報システムの事情はよく知らないので、事実なのかどうかは良く分かりませんが、事実なら面白いですね。

いずれにしても、ITゼネコン型のメリットはもはや無いように思えます。発注側はITゼネコンを通さずに下請けに直接発注するべきであり、そうすれば大幅なコスト削減ができるでしょう。それはおそらく正しく、実際に「この案件はITゼネコンを通す必要がないのではないか」と思えるような状況は結構あります。

しかし、少なくとも現在の日本では、システム構築の能力よりも企業の規模が重要になる案件があります。たとえば、以下のようなケースです。

ハードウェアやネットワークインフラの導入とシステム開発がセットで発注される場合。大企業であれば社内で、あるいはグループ企業でインフラを調達できるため有利になる。ちなみにこのような発注の背景には、ハードウェアの保守とソフトウェアの保守を別会社にしたくないという事情があることが多いようです。
地方自治体や行政機関が発注する案件の場合、ある程度の規模の企業でないと入札できないことがある (売上げなどの規模によってランク付けが行われ、足切りされる場合がある)。認証取得などの要件を厳しく定めることで、事実上の足切りが行われる場合もある。

いずれも、システム構築の能力とは関係ない要因で大企業に受注が集まります。こういった案件を受注しようとする場合、まず企業の規模が重要であり、次いで重要なのが提案や見積もりの能力です。優秀なSEは必要ですが、プログラマは必要ありません。ITゼネコン構造ができる原因はその辺りにあるのでしょう。

インフラとの抱き合わせはまだしも、ランクによる足切りは単なる参入障壁です。純粋にシステム構築の能力で発注が行われることが望ましい……とは思いますが、それは容易ではありません。なぜなら、システム構築の能力を判断することは難しいからです。

システム構築の能力が判断できないから、企業の規模、認証の取得状況、提案のうまさなどで判断せざるを得なくなります。そうやって判断した発注先に能力が不足していると、プロジェクトは失敗するおそれがあります。そして実際に失敗しているケースがたくさんあります。

しかし、失敗の事例はほとんど公表されません。そもそも、構築された情報システムを評価して「失敗」と判断することも容易ではありません。たとえば、岡崎市立中央図書館の事件でシステムに問題があったことは明らかですが、当初、図書館では「システムが悪いかもしれない」という見方を全くしていませんでした。自分が実際に運用しているシステムに対しても、「失敗」という評価はなかなか出来ないものなのです。

このあたりの構造をうまく変えることができれば、もう少し効率の良い発注・受注ができるのではないかと思いますが……。

※そういう意味でも、岡崎市立中央図書館の件が世に知られることには意味があったのではないかと思います。

「ITゼネコン構造と情報システムの品質」にコメントを書く

前(古い): 徳丸さんのセキュリティ本レビューの感想など
次(新しい): 死亡フラグが立ちました!