１ システムのスペックや仕様を書くのは誰か？
大前研一のブログ「ニュースの視点」で、日本のIT人材について書いています。［本来、CIOの役割は、スタッフと協力して開発するシステムのスペックを決めて仕様に落とし込み、それをベンダーに提示すること］であるとのこと。
ところが日本の場合、［システムのスペックや仕様を書き出せるCIOが少ないので、ITベンダーやITコンサルティング会社に丸投げすることになります］と指摘しています。現在の日本では、大前が指摘する通りかもしれません。私の知る限りでも、そ通りです。
なぜ問題なのか。［このやり方を取ると、発注した側がスペックや仕様を理解して落とし込んでいないので、実際にシステムを稼働させてみたら不具合が見つかるということがよくあり］、［使い始めて数年後に不具合が発覚すること］もあるからです。
さらに［日本企業のCIOの多くは「予算だけ」は握っており、責任を追及されるため、無償で改修するようにITベンダーに要求します］。その結果、ベンダーは利益が上がらず、IT人材は報われないというのです。こうした現実があるのも確かでしょう。
２ 業務の把握が前提
アメリカのように、［米ゴールドマンサックスなどの米金融機関では、IT人材が多数在籍し、活躍］している状態になるのが、よいのでしょうか。しかし現実は違う方向に進まざるを得ないと思います。大前の見ているのは、グローバル企業の一部であるようです。
日本の中小企業でIT人材を確保して、その人たちに［システムのスペックや仕様を書き出］してもらう必要があるでしょうか。個別企業ごとに、システムのスクラッチ開発をすることは、逆に無理や無駄があるように思います。それ以前の問題があるからです。
システム化するとき、業務に上手に組み込むには、その前提として業務を把握できていなくてはなりません。すくなくとも自社で行われている業務について、業務マニュアルが書ける程度に、業務を把握している必要があります。しかしそれが出来ていないのです。
３ システムを導入してから構築するモデル
現状の業務を把握したなら、実際に効果を上げるシステムをある程度考えることが出来るはずです。中小企業の場合、そんなに大規模なシステム化は必要ありませんし、現実としてシステム化が遅れています。こういうとき、シンプルなシステムの方が効果的です。
大前は［使い始めて数年後に不具合が発覚すること］と書いていますが、使ってみると、不具合でなくても、使い勝手が悪かったり、必要ない機能がたくさんついていたりということがよくあります。改善を進める企業ほど、変更したくなりがちです。
いまシステムの専門家たちと、先にシンプルで汎用的なシステムを導入してから、そのあとで、構築していくモデルを詰めています。日本の組織の場合、システムを使ううちに、あれこれわかってくることが多いはずです。ならば導入してから構築がよいでしょう。
シンプルで汎用性のあるシステムが、大幅に変更・改修できるなら、中小企業では、現在よりも効率的なシステム導入が出来るはずです。業務の把握は、システムの構築に先立ちます。日本の場合、IT人材の確保以前に、業務の把握がなされるべきだと思うのです。
