ウォーターフォールなんて最初から形骸化している
アジャイル推進派はいちいちウォータフォール（および、伝統的にそれを使ってきたSIer）を非難しているが、大きな案件に関して言えば純粋なウォーターフォールの方が珍しいだろうし、小さな案件でいえばそもそもアジャイルにしたところでそう何回もスプリントを回せない＝あまりフィードバックを反映できない＝つまりアジリティを持てないようなレベルの案件も割とあったりする。つまり一方を非難することにたいした意味は無いはずだ。 まあ大きな失敗案件が取り立ててウォーターフォールである事を喧伝されるのだろうが、そうでない（大きく失敗していない）案件で言えば逐次的な顧客との調整とゴールの変更はいわゆるSEと呼ばれる人たちの仕事として認識されているはずだし、多くの案件はそうやって進められているように思っている。個々のプラクティスに関して見ても一見ウォーターフォール案件でもアジャイルのプラクティスが多用されているケースも結構ある。
個人的には大規模統一プロセス信奉者ではある。ただ、いわゆる国内大手以下の一企業がそれを追求するのはとても難しい。 基本的に統一プロセスは失敗した経験を二度と起こさないために、また効果的な経験を広く適用していくために、そういった経験を形式知として統合していくことでプロセスの性能を磨いていくものだ。つまりそれなりに失敗する事を予め覚悟しておかなければならないし、そもそも今自分がどうやって仕事をしているのかを形式知にそのまま落とし込める人材も希有であろうから、統一プロセスを作ろうとし始めると、「今の自分たち流の仕事の仕方」ができなくなるため先ず生産性が落ちるはずだ。 大多数の企業に取ってこの決断は難しいし、実際耐えられる企業も多くないのだろうと思っている。
ソフトウェア開発プロセス周りで今まで起こってきた事
ソフトウェア開発が建築に例えられることが多いのは個人的には問題だと思っているが、あえてその例になぞらえるのであれば、建築において設計の確かさを裏付ける物理法則や法的基準がソフトウェア開発には存在していない。なのでソフトウェア開発に置いて不足している "法則" や "基準" から埋めていかなければならないのだと思っている。
ソフトウェア業界が今まで積み重ねた知見や成果の積み重ねが "法則" を成し、ITスキル標準のようなエンジニアとしてのスキルセットの規定や、CMMIのような手法の標準化と認定制度の成熟によって "基準" が形成されるのだと思っていた。
だがエンジニア（か、あるいは経営層なのか）はどちらも嫌ったようだ。
法則については個人的にはソフトウェア構成の標準化のような物だと考えている。特にフレームワークやソフトウェアコンポーネントがこの役割を担うはずだったが、あまりに多様化しすぎたため法則として機能させることが難しくなった。Java EEはこのような状況下でさらにソフトウェア構成の法則を規定・標準化することを可能にするように思われたのだが、それも今や求心力を失いつつあるように思える（あるいは、すでに失っている）。代替としてはRuby界隈でのRuby on Railsあたりだろうが、これもRoR自体を固めて次の次元へ進められばよいのだが、エンジニア側は既に軽量フレームワークに目移りする状況になっており、RoR自身もバージョンアップを重ねる度構成コンポーネントを変えることに積極的なようで標準化される事など無いのだろう。
他方の基準についてはアジャイル推進派が語る通り、過去に組み上げられた重厚長大なプロセスは無理なので捨ててアジャイルへ、エンジニアのスキルセット定義もむずかしいのでとりあえず少数精鋭でみんなで何でもやる体制へ、というのが大勢の状況になりつつある。
何にしろ、ここにいたってつまり、建築でいう法則も基準も、ITに於いてはいまだに成熟することなく堂々巡りを繰り返そうとしている。このままでは、おそらくいつまでたってもSI業は商業として不完全なままだろう。
これから起こるであろうこと
SIや請負に関して上記の事が成り立たないと、そもそも「期間はいつまででこんなシステムを」見たいな発注がきても特に根拠のある見積ができない。これができないとそもそも商売として成立しない気がしている。根拠のある見積ができないと経験として蓄積できないので生産性が上がらない。確実に黒字にすることが難しくなるので、突き詰めていくと顧客の言う通りに受注していくのはそもそも無理がある、みたいな話になる。
ただ根拠の提示できる土台の上でなら話は別だ。
なので個人的に今後SI関係業者が取るであろうと考えている選択肢は以下。
パッケージ屋かサービス屋に転向する
通常の商習慣とソフトウェアの請負開発の合成は商業として成立していない。なのでさっさとやめてしまう。自分たちの土台で自分たちの顧客のためにサービスする。
あくまで請負開発をやる
この場合、さらに選択肢がある
技術を固定する
常に特定の技術のみを使用する。これを土台とする。 開発手法や使用するシステムを固定することによって顧客の期待値を固定する。要員には常に一定の教育を施せばよくなるはずである。SI作業の属人性が排除される傾向が強くなり、期間工のような雇い方も可能になるかもしれない。
個人的には国レベルで標準技術セットを決めてしまい、請負開発の依頼や取引はそれに沿って行うことなどとするのも一つの道ではないかと思っている（例えば国内のソフトウェア請負取引はRuby以外での実装を禁止する、など。これだけでエンジニアやベンダーのレベル感をはかる物差しが今よりだいぶ明確になりそうだし、ベンダーにしても見積の目星をつけやすくなるだろう）。もちろんSI業界における技術の発展はなくなる可能性がある。が、おそらくコモディティ化を促進できるので代わりに取引の難易度が下がり顧客にシステムがいきわたりやすくなるのではないか（個人的には、これに強く意義を感じる）。技術の新陳代謝はどこかで必要になるかもしれないが、要は過剰な（というよりはビジネス以外の動機による）技術の変遷を抑えるべきだと考えている。
派遣会社になる
先にも述べた通り請負は商業として成立しないので、技術者を顧客先に派遣してその労働力としての価値に対価を払ってもらう形がもっとも突き詰めた形になるだろう。社員への教育は自分たちでは行わないし、組織的な意識を持たせることも難しくなるだろう。こうなると単にモチベーションのある技術者とモチベーションのある顧客のマッチング業みたいなものだろう。
