3つのパラダイム変化の2番目の「作って終わりから使ってナンボへ」というのは、システム構築のゴールはどこかという話になります。つまり、作ることがゴールではなく、動かしてみて、もっと言えば成果を上げた時点がゴールですよと言っているのです。こんなことは至極当たり前だと思われるかもしれませんが、存外そうなっていない例を多くみかけます。

なぜそうなってしまったのかは、ユーザとITベンダーやSIerとの関係に見ることができます。ユーザはITのことがわからないからといってこんなものが作りたいと言っただけでITベンダーやSIerに丸投げします。特に一昔前の経営者は最初からITを遠ざけている人が多かった。また、ITベンダーやSIerはあいまいな要求仕様のままプログラム仕様書を書き、プログラマーに丸投げします。無責任連鎖です。

さて開発会社はそうやってできたシステムはこれだけ人月を要したのでそれに見合う費用を請求して受け取るわけです。だから、開発会社は極端な話その時点で仕事は終わります。ITベンダーもSIerも同様にユーザに対して言われたことをやりましたと言って、"プログラムが正常に動くこと"を確認して検収してもらうことになります。

これってどこかおかしいと思いませんか。ITベンダーやSIerにしても受託した開発会社にしても「作ってナンボ」と考えているわけです。そうした成果物を使いだしたユーザは使おうと思ったら使えないとか、使い出すとこう変えたいとかいったことが出てくるがもうどうしようもない。というわけで、半数以上のシステムが使うことなく眠ってしまっているのだ。

ユーザにとってのゴールは、当然のようにビジネス上の成果が出ることである。そのために大きな投資をしているのである。ではどうしたら、使って役に立ったというところまできちんと確認して終わりとなるシステム作りができるようになるのでしょうか。もちろん意識の持ち方もあるだろうし、契約の問題もあるでしょうが、大きいのは開発方法とか体制の問題だと思います。

つまり、ウオータフォールのようなフェーズドアプローチだとフェーズ間の受け渡しがうまくいかないとか、できあがりイメージがつかめない中でユーザが要求仕様を出していかなくてはいけないといった問題がどうしてもおきてくるから、そこから変えていく必要があります。

こうした問題を解決するには、いきつ戻りつでき、早い段階である程度動くものをみせていく反復型のやり方にするとともに、そこにユーザが参画してIT技術者と一体になって進めていくのが必須になってきます。こうすれば、ユーザーが真に欲しいものが具体的イメージとして出てきてそれをブラッシュアップしていくのでできた時は必ず使いものになるシステムになっているわけです。

こうしたやり方を前提として、使い手側も作り手側も意識を変革し、難しいかもしれませんが、契約形態も受託開発ではなく成功報酬に近いようなものにしていけばよいのではないでしょうか。そのくらいのことをしないとイノベーションを支援することはできないと思います。
  

No TrackBacks

TrackBack URL: http://blog.wadit.jp/mt/mt-tb.cgi/133

Leave a comment