Hatena::ブログ(Diary)

kuranukiの日記(移転しました)→ http://kuranuki.sonicgarden.jp このページをアンテナに追加 RSSフィード

2006-01-16

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

enpitsu1976enpitsu1976 2006/09/09 02:07 はじめまして。
「ユーザーの視点」こんな単純で大切な事が、SIerの目には映っていないのかもしれませんね。

katzchangkatzchang 2007/09/21 13:35 >震度5の地震などほとんど起きることもないので、なんとかなっているという、まるでどこかの話みたいな構図ができあがっている。
このエントリの趣旨は今となっては懐かしい建築強度偽装の件だったと思いますが、今同じことを言うと原発の耐震設計の問題になっちゃう辺り、面白いなぁ・・・
と思ってコメントさせていただきます。

jumpinjackjivejumpinjackjive 2007/09/22 11:43 SIerに勤務するSEとして、大変重みのある言葉をいただきました。SIの現場にいる人間でも、現在のSIerのビジネスモデルの先行きのなさは分かります。ゲームのルールを一気に変える力はSIerにはおそらくないでしょう(変革するためのモチベーションすらない)。が、まずはそれぞれのプロジェクトで小さな変革を起こしていくしかないのかなと。それも時間の無駄だと判断したら、とっとと退場するしか無いんでしょうね・・・

Sean_SFSean_SF 2010/10/27 14:50 この記事、いま読みました。ありがとうございます。
しかし、5年近くも前に書かれた記事なのに、今でも、ふんふん、ふんふん、と頷きながら読めてしまうのは、業界の構造が今でもほとんど変わっていないということでしょうか。
あるいは、変わってきている部分があるのでしょうか。そういった疑問を今後、頭に入れておきたいと思います。
それから、こういったビジネス構造においてSIerがアジャイル開発を採用するにはどうしたら良いのでしょうか。顧客側の協力が不可欠だと思いますが、その他にも条件があると思います。あちこちで議論されていると思いますので、調べて、私も考えていきたいと思います。

TownBeginnerTownBeginner 2011/05/08 14:27 今この記事読みました。自分がずっとSIerについて感じていたもやもやした感覚について、
はっきりと述べられていることに感銘を受けました。素晴らしい記事ありがとうございました。

 もう5年前の記事ですが、今なお頷きながら読めてしまうのは、この業界がまだ変わっていないことの証左のように思えます。中小SIerに勤務しているので、この問題はより切実な問題として受け止めています。変化が起こった時、袋小路に入っていくときに真っ先に無くなるのは、中小SIerだからです。だからこそ、中小SIerは攻撃的な姿勢を取るための経営方針を打ち出していかなければならないと感じました。

hidehide 2011/06/28 14:31 いま読みました。もやもやしていた部分を的確に文章に落とされていると感じた。
その時から、SI業はほとんど変わっていないような気がします。
経営者は何やってるんだろ?会社大きくすることだけ考えてるのか??
なんの魅力も無くなっていく。。。

jpjp 2011/08/18 22:54 長文だったので「小見出し」をつけたり「太字」にしたりすると見易くなりますね

economixmeistereconomixmeister 2011/09/01 09:02 自社を取り巻くビジネスにおいてもかなりの部分が一致していると感じた。
Agileに取り組みたいと言っても、目的と手段を混同するな!とか、そもそも解決すべき問題は何か?と訊かれ、ここに記載されいる事が断片的に頭をよぎるが、納得できる説明ができるわけでも無く・・・。
自分の周辺に起きていることを、深く分析・考察されている点に感服しました。

ばしくしばしくし 2011/11/28 02:00 ちなみに、SIerが対峙する顧客っていうのは
技術なんて最新のものだろうが、レガシーなものであろうが、そんなくだらんことは一切どうでもよくて
要は、きちんとシステムが動作しさえすれば、それでいいんですよね。
技術なんてどうでもよいから、システムが止まらないようにきちんと動かしてくれ…要求ってのは、単にそれだけなんですよ。
「難しい技術を使って高度なものを作りました」だから「より高いフィーをください」とか
「優秀な技術者を手配します」だから「より高いフィーをください」
なんて言っても、実サービスが止まってしまっては、全然使えないシステム(ベンダー)なわけです。そんな要求は呑めませんよ。
逆に、古くからある技術で定番のやり方で実装してても、オーソドックスな形で運用に入っても、サービスに支障なくきちんと運用できていれば、優秀なシステム(ベンダー)なわけです。たとえ技術スキルが古臭くとも。低スキラーの塊であろうとも。
各々逆もまたしかりですが。
SIerのトップの方針云々だけじゃなくて、そもそもSIerに金を払うのは顧客企業ですから
その顧客企業がSIerに騙されないように、ビジネスモデルの転換を提示しないと
SIerなんて、絶対に変われっこないです。ムリムリ。
ですが、顧客企業も情報システムについては、まだまだ意識は低いです。
情報システム部門なんて、本当に落ちこぼれ部署ですよ?
やっぱり、営業とか渉外とか購買とか企画とか研究開発とか…
そういう花形のところでやってこれなかったデキナイ君達を押し込めた部門ですからね。
一般企業の情報システム部というのは。
これだから、SIerの生きる余地も残ってるってもんです。

スパム対策のためのダミーです。もし見えても何も入力しないでください
ゲスト


画像認証

トラックバック - http://d.hatena.ne.jp/kuranuki/20060116/p1