井上 研一 「SIer」・・・。この言葉が一般に通用する言葉なのかはよく分かりませんが、必ず通じる言葉で言い直すとSI（システム・インテグレーション）企業です。NTTデータとか、伊藤忠系のCTC、独立系のCSKといった、まぁシステム構築を一手に担う企業のことですが、こうしたSIerは一つの限界に達しつつあり、次の扉を開けようとしている時期にいるのではないかと思うのです。
私もある中堅のSIerに勤める身です。そのSIerは30数年の歴史を持っている老舗だけに、過去の資産を引きずって、新しい分野に乗り切れないでいます。汎用機向けにCOBOLでプログラムを書く歴史があり、概要定義から基本設計～詳細設計～プログラミング～単体テスト～結合テストといった大型システム向けのウォーターフォールモデルを、ずっと引き継いでいます。
ウォーターフォールモデルというのは、システム入門者向けの教科書の最初のほうに必ず出てくるシステム構築の方法論の名前ですが、あくまで汎用機時代の大型システムにこそマッチするものであり、現在のWebシステムのような小型システムに適したものとは言えません。なぜなら、ウォーターフォールモデルが要求するのは、多くの手順を踏むことであり、一つの手順が終わって次の手順に入ると、後戻りを許さないことです。しかし、小型システムとなると、納期までが短期間であるため、とりあえず作ってみないと分からないという状態に陥ります。ある程度のものが出来たと思うと、クライアントから仕様変更が言い渡され、やむを得ず、ウォーターフォールモデルが禁じているはずの手順の後戻りをしてしまう。仕様変更の発生は、設計者があらかじめクライアントの要望をきちんと理解していなかったかもしれませんが、それが出来るほどの時間の余裕もなかったのでしょう。こうなると必然的に「やっつけ開発」が進むことになり、物はなんとか納品したものの、SIerは赤字を受け入れなければならず、後には何も残らない・・・、というような「ただ、こなしただけ」という結果になります。
やはりウォーターフォールモデルは短納期の小型システムには適さないのだと考えて、こうした事情を逆手に取ってみるとどうでしょうか。クライアントの要求イメージがある程度、出来たところで物を作り始める（これがプロトタイプ）。仕様変更はあって当然とする。そのために仕様変更に強い柔軟なシステムを作っておく。・・・これはプロトタイプモデルのやり方です。プロトタイプの作成と、フィードバックを繰り返す形になるとスパイラルモデルという別の呼び名もあります。
私はこうしたプロトタイプモデルの手法が、現在のシステムには適していると思います。しかし、プロトタイプモデルというもの自体は過去からありながら、今でも積極的に用いられているとは言えません。これは、おそらくSIerの見積もり計算の方法のためだと考えられます。SIerは何の疑いも持たずに「基本設計が何人月で、詳細設計が何人月で・・・」というウォーターフォールモデルでの手順の一つ一つにあわせて、必要となるであろう人月を予想し、それを加算して全体の工数を計算します。ここに必要な人材の単価をそれぞれ掛け合わせて、そこにSIerの利益を乗っけて見積もり金額とします。
このやり方を何の疑いもなくやる以上、手順が固定化され、一定に上から下への流れ作業となるウォーターフォールモデルは非常に都合が良く、同じ手順の繰り返しが前提となるプロトタイプモデルや、スパイラルモデルは見積もりが面倒なものとなります。また、プロトタイプモデルやスパイラルモデルでは、システム開発前には完成後の詳細な仕様はあやふやであることを容認しなければならないのも、SIerとクライアントの間で交わされる「契約」という考え方に適したものではありません。
これからのシステム開発を考える上で、ウォーターフォールモデルを否定するやり方は、プロトタイプモデルだけではありません。もう一つ、パッケージプロダクトの使用というものがあります。現在、多くの会社からシステムの半完成品とも言えるパッケージプロダクトが発売されています。SIerに持ち込まれた開発案件によって、使うパッケージプロダクトを吟味し、カスタマイズによってシステムを作り上げ、納品してしまうのです。このやり方は、まず短納期に対応しますし、予算も圧縮できるかもしれません。また、システムの根幹は十分なテストが行われているパッケージプロダクトを用いるために品質向上の効果もあるでしょう。
そもそも「SI」はシステム開発ではなく、システム構築なのですから、すべてをオーダーメイドしなければならないわけではないのです。
何にせよ、SIerは昔ながらの古いやり方に固執することなく、その場に合った新しいやり方にもトライする努力が必要です。