SIerがなぜ、こうなってしまうのか

ほぼ、1年ぶりに日記かな。

SIはやめておけ


そもそもSIとは要件定義から保守までを一括請負するという意味であって、例えば、いわゆるWeb系エンジニアがそれの対極かというと、どうも違うような気がする。SIでもWeb系の仕事をするだろうし、いわゆるWeb系エンジニアがコンサルティングだけを請負ったり、プログラミングだけを請け負ったりするわけでもない。

では、いわゆるWeb系エンジニアとの違いは何か?私はこう思う。

他社向けのシステムを、請負契約などに基づいて構築するか、社内のエンジニアとして自社のためのシステムを構築するか

こういう意味では実はSierの中でも、社内システムやパッケージ開発などを行っているセクションはWeb系の開発のように新しい技術を受け入れやすいはずだ。実際は違うかもしれないが。

他社向けのシステムを構築する場合、契約が非常に重要になる。これはそう簡単に変えられるものではない。契約を守るために必要なものは、納期・予算・品質(いわゆるQCD)である。一方、社内向けのシステムであれば、システムの構築自体が契約によって定められているわけではない。ある程度の調整はできる。
契約を履行するうえで、新しい技術を導入して大きな失敗を生むわけにはいかない。このため、できる限り保守的な解決を図ろうとする。
また、他社向けのシステムが大規模な場合は、様々な下請け会社を含めて大量の人員を使ってQCDをコントロールするため、過剰なルール主義に陥りやすい。できる限り作業する人に考えさせないようにする。これにより、同質のものを大量に製造することができる。とにかく想定の範囲内にプロジェクトをコントロールすることが最も重要な関心事であって、この匿名日記の作者のようなルール以外のことをしようとすると、はじかれるのだ。

よって、SIはこうなりやすい。

もう少し幸せに働くためには、

  • 要件をあいまいにしない。何を作るのかを明確にする。固定コスト・納期の厳守が顧客のニーズであるなら、要件の厳密化は譲れないはずだ。(アジャイル開発等を受け入れてくれるならともかくとして)
  • ルール作りは重要だが、ルールの改良を行うのも重要
  • 初期の学習コストを投資して、効率性を改善するための新技術の投入を行う

SIというビジネスがなくなるとき、それはきっと、顧客企業がシステム会社に丸投げするのではなく、自製し始めたときだと思う。