May 2014 Archives

さて、3番目の「個人作業からチームワークへ」というのをみていきましょう。仕事というものは、特に会社の中で行われるものはほとんどが全く個人で独立してやるものではなく、複数の人間が関わって行われます。だからこそ、会社には組織というものがあるわけです。

最近ではネットが発達したから組織に属さないノマドワーカーなんていう人種も現れてきていますが、彼らだって、というより彼らこそチームで仕事をやっています。ただ、それはルーティンワークというのではなくプロジェクト的な動きにはなっていますが、より密な関係性を維持することが重要になっているように思います。

むしろ、企業の中のほうが個人的な振る舞いが多いのではないでしょうか。昔はそういった状況をよく見かけました。サラリーマンでも職人的な人が多かったのです。しかしながらいまだに変わっていない会社も少なからずあるのではないでしょうか。

ですから、業務にITが入り込んできた時、そうした個人の仕事を助けることが目的になっていました。すなわち、個人の仕事、作業が楽になるように機械が代わりにやってあげるというためのツールがITというわけです。従って、そろばんをはじく代わりに数字を打てば計算してくれるものでした。そこでの必要な機能は早く、正確に、大量に処理することです。

ところが、これだけ年月も経るとそうした処理マシンとしてのITはかなり行き渡りました。では普及した結果どうなったのでしょうか。みな仕事をITがやってくれていますか。どうも、ある程度は自動化も進み、生産性も上がってきたとは思いますが、ITでできない仕事がまだまだあるのが現状ではないでしょうか。残った仕事はどんなものなのか、おそらく個人のルーティンワークではないようですね。

非定型で複数の人が関係して進めていくような仕事が残ったように思えます。これは、実は昔は「タバコ部屋」で行われたものです。たばこを吸いながら関係する人たちが"摺り合わせ"てものごとを決めていたのです。これは、インフォーマルの世界ですから、表に出てこないのでごく一部の人だけが知っているというクローズしたものになってしまっていました。

これからは、こうした隠れた意思決定を表に出して、組織の皆が知った上で仕事を進めていくオープンなものにしていく必要があります。そのために、ITはどう使ったらいいのかを真剣に考えていかなくてはいけません。つまり、チームとしてコラボレーションを行いながら進めていくイメージです。まさに、個人作業からチームワークへの転換が重要なパラダイムになるのです。
  

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

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

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

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

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

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

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

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