井上 研一 「ディフェンシブな開発 ～ SIビジネスの致命的欠陥」は、日本XPユーザグループ代表の倉貫氏が書いた記事で、はてなブックマークでは今日時点で194人がブックマークした注目度の高いエントリーだ。
RubyとXPで…云々というくだりは、私は若干割り引いて見たほうが良いかと思う。しかし、この記事は私に大きなインパクトを与えた。
これまで6年間ほどSIerを生業としてきて、薄々感じていたことが白日の下にさらされた。頭の中のもやもやがすっきり晴れたような気がした。
SIerのビジネスモデルは、基本的に受託開発だ。実際には、SIerでも派遣の割合が高い会社もある。顧客企業に常駐して顧客社員の指示を受けて仕事をする派遣と何の違いもないスタイルを、契約上でだけ受託開発にしてしまうケースもある。（これは偽装請負であり違法行為だ。「IT業界のタブー「偽装請負」に手を染めてませんか」を参照。）
私は今まで受託開発案件しかやってこなかったので（派遣スタイルもやっているが、その時の仕事は開発ではなかった。）、その視点でしか語れない。
狭い視野での発言になってしまうが、私は受託開発には問題が多いと思っている。将来的に受託開発スタイルが継続できるか怪しいと思っている。故に、SIer＝受託開発ならば、SIerたるものが存在し続けられるかも怪しいとすら思っている。
では、受託開発の問題点とは何か？
それは、「開発が終わったら、そのシステムとの関係が切れる」ということだ。
そうである以上、一定の開発期間の中で、顧客の依頼事項を出来るだけ多く満たしていかなければならない。
一方、その一定の開発期間内でのSIerとしての採算を考えるから、仕様凍結を急ぎ、凍結したら絶対に仕様変更させないという断固たる決意を固めてしまう。無論、追加でお金を払ってくれれば、仕様変更を受けることもある。
そうやって出来たシステムは、仕様が未熟であり、最大の妥協が払われたものになる。それでも、使えるだけマシという状態であれば、成功事例だ。
いや待て、開発が終わっても数人は運用フェーズの担当として、開発したシステムとの関係が続くぞ！と思われる方が多いだろう。そのとおりだ。先ほどは、敢えて触れなかった。
運用フェーズの担当者は、主にシステムの運用や、バグ対応を行う。時には軽微な機能改善を行うこともある。
顧客が求める本当の仕様は、運用が始まらないと分からない。顧客は、動いているものを使うことで、初めて自分が求めているモノに気づき始める。
それを起点として行われる機能改善が、何より重要ではないかと思う。
あるシステムのライフサイクルが5年あったとして、受託開発スタイルでは、その初期の1年に開発のための膨大なコストがかけられ急速な成長を見せる。残る4年は運用フェーズであり、成長度合いは微々たるものだ。
ここで、その最初の1年と後の4年の成長度合いの格差を、均等とは言わないまでも、慣らしていくとどうなるだろうか。
私は、ここで反復型の開発プロセスを頭に思い描いている。契約は5年契約でも良いし、1年毎の契約更新でも良い。
反復型であっても、仕様凍結は重要だ。しかし、受託開発スタイルでは最初の1年で開発するから、仕様凍結は1回だ。それで反復型をやると、SIerにはメリットがあっても、顧客にはメリットがない。
そこで、開発期間をライフサイクルと同じ5年と見る。そうすると、例えば1年毎の契約更新として、その期間に開発プロセスを1反復させるとすると、5年で仕様凍結が5回出来る。半年で1反復なら10回だ。（ここで言っている1反復の中で、さらに2週間とか1ヶ月の単位で開発上の反復が行われている。）
つまり、システムのライフサイクルの中で、システムが漸進的に成長するモデルを描く必要がある。
Web 2.0では「永久にベータ版」というキーフレーズがあるが、正にそういうことだ。（ここでのベータ版というのは、機能の数や深さが理想像に至っていないという意味であって、提供されている機能の信頼性が欠けるという意味ではない。）
それだけ腰を据えて付き合っていく技術者が必要になる。
その技術者を、誰がどうやって提供するのかがポイントだ。
最も望ましいのは、顧客企業が自ら技術者を抱え込むことだ。昨今は経営とITの関係が密接であり、そうした面からも望ましいだろう。
次善は、SIerが提供することだが、このスタイルでは受託開発とは言わないだろう。
話が長くなったので、続きはまた今度。（もう少し、自分の頭が整理されたら…である。）