ディフェンシブな開発 〜 SIビジネスの致命的欠陥

Rubyをはじめとするスクリプト言語ではなく、なぜJavaを選ぶのか。

そして、XPをはじめとするアジャイル開発ではなく、なぜウォーターフォールを選ぶのか。

そこには、言語の良し悪しや、開発プロセスの考え方などが理由の中心にあるわけではなくて、SIerというビジネスの仕事の仕方（ビジネスモデル）に起因している。

RubyやXPは、考え方や技術としてはとても良くて、生産性もあがるし、何よりもソフトウェアをクリエイティブに作り上げることができ、利用者にとっても使い勝手がよく、スポンサー（経営者）にとっても経営戦略に沿ったものが手に入り、開発者にとっては何よりも仕事に対してやりがいを感じることができる。すばらしい！・・・・が。。。

しかし、だからといって、誰でもRubyやXPを使って開発をするべきか、というとそうではない。もし、本質を理解しない誰かが、「やってみたいのだが・・・」と相談に来たら、それはやめて、Javaとウォーターフォールでやりなさい、と助言するだろう。それは・・・なぜか？

まず、XPやRubyをうまく実践するには、それなりのスキルとマインドが必要になってくるのは確かで、それも理由のひとつではあるが、オススメしない本質はそこではない。それは、SIerのビジネスモデル（受託開発）がディフェンシブ（防御的）な開発しか許さないからである。

ディフェンシブな開発とは、開発途上のリスクを計画上の時点でなるべく潰し、開発側に発生する利益分を減らさないような開発の進め方をすることを言っている。加えて、この場合、開発側はリスク分はなるべく多めに見積もり金額にいれようとしがちだ。

なぜそうなるのか。今のSIビジネスでは、決められた金額の中でどれだけ安く作り上げることで利益を出す構造だからである。つまり、お客様と金額と内容で合意し、発注を受けたら、後は、その中で当初の金額よりも安く作れば利益率は上がるのである。人月幾らで受発注している段階で、そこを安くするには、単価を下げるしかなく、オフショアなどの下請け会社に投げることで多くのマージンを獲得できるのである。

そうなると、良いシステムができあがるはずもなく、如何にローコストで作るかということだけに力点が移ってしまう。もちろん、品質が悪ければクレームとなり次の仕事につながらないという問題が発生するが、震度５の地震などほとんど起きることもないので、なんとかなっているという、まるでどこかの話みたいな構図ができあがっている。

SIの会社でシステム開発業務をしている限り、ディフェンシブにならざるを得ないのである。だからこそ、上流工程と呼んでさもシステム開発には重要だと言って要件定義に注目してみたり、ITアーキテクトが重要だと言って方式設計に注目してみたりしているのだろう。その注目している理由は、いかに自分達の利益分を守るか、という背景の中で起きていると考えれば自然なことである。それらの個々の活動にはまっとうな理由があるだろうが、その理由が生まれる背景となる文脈にディフェンシブな開発という側面があればこそである。

要件定義で、なるべく事前に要求を全部洗い出して、決めきって、合意を取って、必要とあらばハンコも押して、それ以外に発生したら別料金をもらえるようにして、開発に取り掛かろうと。そうしておけば、後は、下請けをどんだけ叩いて安く作らせるかに注力できる。方式設計も同じこと。なるべく事前に方式を決めて、構造を決めて、できることを決めきっておこうという話。・・・しかし、こうしたやり方で、本当に要件が決めきれるのだろうか。そして、方式も決めきれるのだろうか。逆に、決めきれたとしても、それが本当に求めている要求なのだろうか。その方式で良いのだろうか。これでは、顧客にとっての新しいイノベーションは生まれることはないだろう。

余談ではあるが、今のシステム開発だと、使うライブラリなどのバージョンはどう考えているか？システムの提案時で安定しているバージョンを提案するか、ちょっと考えたリリース時期を見越して、そこに向けたバージョンを提案するかもしれない。SIerはそれで良いが、システムを使うユーザにとってはそのシステムが１０年使われるかもしれない。その間のバージョンアップはどう考えているのか。そんなこと考えてない提案は多すぎる。一発作ってしまえば良い考え方があまりに多い。とはいえ、そういう提案だときっと、リリース後、数年でリプレース提案をかけてまた儲けられる、なんてことも考えられる。でも、これって、なんだかビジネスとしては、あまりにチンピラすぎる。ドカンと作って数年もって、またドカンと作るのは、もうやめた方が良い。2004年に策定したEJB2.0をベースにした方式のシステムを2007年にリリースするなんて、まったくもってナンセンスだ。

さて、本題に戻すが、SIの開発ではディフェンシブにならざるを得ないのである。そうなると、プログラミング言語としても、インタフェースを作れたり、コンパイラで型チェックが入ったりするようなJava言語が向いているのである。これは、Javaでクリエイティブな開発ができないとは言ってない。Javaの一部の特性が、SIというビジネスにフィットしていたというだけの話である。ただ、Javaを使うことによって下請けやオフショアに開発を出すことを容易にすることができる。だから、Javaを選ぶのである。

そして、このことはウォーターフォールも同じである。工程ごとに確実に決めて、なるべく被害が発生しないように石橋を叩きながら進めようと考えれば、ウォーターフォールを選ばざるを得まい。ただし最近では、仕様書で石橋を叩いたつもりでも、結局うまくいかない場合が多いのであるが。それにしても普通に考えたら、いかに上手にウォーターフォールを進めるかということに注力してしまう。

このように、ディフェンシブにならざるを得ないということを考えると、今のSI業界の抱えている矛盾や構造が全てつながってくる。契約の問題もしかり、工数計算の問題もしかり、会計基準の問題もしかり。ディフェンシブであるために、本来は新しい技術要素なんて本番のプロジェクトに入れてはいけないのだ。。。

さて一方、RubyとXPで開発をすると、オフェンシブ（攻撃的）な開発が実現する。どんどんと新しい機能を追加できるし、アイディアも実現までの時間が短くて済む。何か新しいシステムを作り上げようと言う時は、こうした軽さが無いと作れないだろう。そして、ソフトウェア開発は、本来、こうであるべきだと思う。ただし、このオフェンシブな開発を実現するためには、今のSIerのビジネスの仕方では、障壁が多すぎる。簡単なところだと、そもそも人月計算をする時点で、沢山のものを同じ時間で作ってしまうと、受注金額が下がってしまう。これでは意味が無い。また、見積もり時以外の機能を、エクセレントに作ったとしても、単に開発者が苦労するだけで、お金が貰えなかったら意味がない、などである。長年アジャイル開発を続けて感じ続けていた違和感がこれであった。

RubyとXPはオフェンシブだから品質が悪いのでは、という危惧もあるかと思うが、品質の問題に関しては、オフェンシブかディフェンシブかなんて関係の無い話だし、いずれにせよ最重要に考えるべき話だ。そして、ディフェンシブな開発ではないがしろにされてしまいかねないのは既に話した通りだ。「攻撃こそ最大の防御」という言葉もある。一定の基準値で品質を確保するような品質の考え方ではなく、品質さえも作りこんでいくぐらいの開発の生産性があれば良いのではないか。

ディフェンシブであることは、多くの弊害をもたらしている。やはり見積もり金額でよーいドンの世界だと、プロジェクトの成功は能力や付加価値よりも運が重要な要素になってしまいがちだ。良い顧客がついたとか、高めの見積もり金額で受注できたとかで、プロジェクトの成否が変わってきて、どれだけ高い技術力があっても、顧客によってはプロジェクトがポシャる時は往々にしてある。また、このゲームのルールに従ってビジネスを続ける限り、会社の規模とか体力でしか大きな案件は取れず、小さな会社はサブコントラクターにしかなれないのである。

こうした構造には、受注側のSIerだけの問題が原因ではなく、発注側にも原因がないわけではない。多くの発注者にとってみれば、システム開発はアウトソースするものという意識があり、予算額でシステムを作らせれば良いと考えがちだ。そうなると、お金を出してるんだから・・・という態度になってしまいがちだし、いかに予算額の中で沢山の機能を盛り込めるか、というところがその発注側の担当者のミッションになってしまい、やはり不幸な結果になるのは目に見えている。なので、バグが仕様かで揉めることが多いのだろう。そうなると、受注側は、さらにディフェンシブになって、どれだけリスクを低くできるかと同時にリスク分を見積もりに詰め込めるかを考えるようになる。もはや、悪魔のスパイラルが走っているといっても過言ではない。

そこで、システムを必要としている企業であれば、もはや、SIerなどに頼むのではなく自社で優秀なプログラマーを雇用して、そこで開発をした方が良いのではないだろうか。その方が、コストも安くてすむし、何より、柔軟なシステム開発が可能となる。その場合、RubyやXPを使ってオフェンシブな開発も実現できるのではないか。SIerに頼んで、どこの馬の骨かわからん奴等に作られるよりは、よっぽど安心できるのではないか。SIerの中にいる優秀な人材は、顧客側のシステム部門に行った方が良いのではないだろうか。

しかし、それも現在の日本では中々難しい。日本の経営層には、いまだにシステム部門をコストセンターとしか見ていない場合が多い。そうなると、システム部の立場は社内で弱く、システムとは予算内でいかに作るかだけで、それを活用してビジネスを上手に展開していこうとまでは考えられていない。そうなると、先ほどの直雇用のモデルではうまくいかない。せっかくのプログラマーも社内調整に走るようでは、宝の持ち腐れ、やめてしまうに違いない。

やはり、システムに対する重要度の認識が高くないと、そういった構造には中々なりえない。逆に、重要度が高いと認識しているIT企業は、自社で作っている場合がほとんどだろう。IT企業にとっては、システムこそが事業の中心だからだ。（ちなみにIT企業とSIerは完全に別の業界である）だからこそ、本当に優秀なエンジニアは、SI業界など去って、IT企業に行った方が良いんじゃないかと思ってる。

そうはいっても、最近では徐々にIT投資が重要だという認識が広まりつつあると聞いている。おそらく近い将来、経営とITは今よりももっと密接なものとなるだろう。そうなった場合、経営はゴーイングコンサーンであり、一年ごとに見直しをして続けていかねばならないのに対して、システムだけが従来どおり、数年に１度ドカンと作って減価償却していくような作り方で良いのだろうか。いや、経営とITが密接に結びつくのであれば、システム開発も１年ごとに見直すべきだろう。１年以上のプロジェクトは禁止の方向で。そして、システムは、常に改修を続けていくスタイルに変えていくべきじゃないか。

そうなったときに、今のディフェンシブな開発の延長上に、SIerの未来は無いと思える。そういう世の中になったとき、今後どうしていくべきか考える時期に来ているのではないか。むしろ、その変化を待つのではなく、未来に向けたSIerのビジネスモデルを考え、ゲームのルールを変えてしまえば、輝かしい未来となるかもしれない。そうなってしまうと、もはやSIerとは呼べないかもしれないけれど。

つまり、現場での改善活動も重要だけれども、ドラスティックに今の問題だらけのSI業界を変えてしまうには、SIerのビジネスモデルを変えるしかない。現場の改善活動ってことでアジャイルの普及とかしているけれど、そもそものビジネスモデルを変えるためには、経営者の判断が必要になる。それも、ある程度影響力のある企業の経営者でなければ難しいだろう。独立してフリーランスになったとしても、同じゲームのルールに従っていては勝ち目はない。

勿論、ここまで悲観的になることもなく、新しい技術要素を学び取り入れ、生産性を上げてお客様に良いシステムを提供し喜んでもらうということはとても大事なことだし、個々のレベルで取り組まなければならないことではある。それで、エンジニアとしてのQoEL（Quality of Engineering Life）は高められるに違いない。しかし一方で、業界全体が袋小路に差し掛かった感もぬぐえない。自然とQoELをあげることができ、それが豊かな生活に直結するような業界に変えることも考えていかなければ、と思う。