おはようございます。
本日も私のブログをお読み頂きありがとうございます。
過去、４０年近くシステムに携わった中で、行ってはいけないIT化の定石が見えてきました。成功するIT化の方法論は色々ありますが、失敗する方法論は、そんなに沢山ないと思います。その、数少ない失敗の法則をシリーズでお話したいと思います。
一つ目の失敗の法則は『個人のお悩みをITで解決するべからず』です。
これを、『EUC（エンド・ユーザー・コンピューティング）』と言います。部門の生産性を上げるには、個人の生産性に突き当たります。そこで、毎日残業しても追いつかない入力処理を、どうしたら少しでも早く終わらせる事ができるかを、個人レベルで解決しようとします。これが、『EUC』なのです。
『EUC』は、一見すると合理的に見えますが、実は大きな落とし穴が待っています。つまり、仕事の無駄の固定化と属人化です。
『仕事の無駄の固定化』とは、『作業そのものが無駄』というパターンです。
上司がとある報告に必要な数字を部下に尋ねたとします。部下は、また同じ要求がくる可能性を感じ、その日から毎日、その数字を記録する仕事を作り出します。でも、その機会はやって来ないのです。そんな作業が、少しずつ増えて行き、本来の仕事を圧迫して行きます。
また、『過剰なクオリティの追求』もあります。上司が求めているのは「概算」なのに、精緻な数字を求められていると誤認して、どんどん精度を高めて行きます。当然、精度の高い結果を得るには、手間が掛かります。そして、本来の仕事を圧迫していきます。
また、本来の仕事でも、前工程を少し改善するだけで、自分の部署の仕事が大幅に生産性が上がる場合もありますが、目の前の仕事しか目に入らないため、前工程の改善をすることなく、改善できる余地があるのに自分の仕事を何とかこなす方向に走りだします。これも、大きな無駄です。
これらの無駄を受入れながら、本来の仕事も遂行しなければならないため、仕事の効率化と称して、仕事の自動化を行います。つまり、エクセルであれば、マクロを駆使した表を作り始めます。マクロで間に合わなくなると、エクセルのプログラム機能を利用するようになります。こうなってくると、作った本人もメンテナンスできなくなります。
そして、何かの制度変更等で仕事の流れを変えなくてはならなくなった時、これらの個人的に構築した仕組みが変更出来ないことがネックとなり、社内の全体の仕組みを変える事が難しくなります。
このような弊害の存在は、大企業では１９９０年代後半から認識されるようになりました。冒頭に書いた『EUCの弊害』です。そして、現代もまた、その『EUC』の波が来ているのです。
クラウド上には、様々なサービスがあります。個人のスケジュール管理から始まったグループウエアーや、プログラミングを行うことなくデータベースを作れるというふれこみの仕組みなどがそれです。
しかし、これらは、昔の『EUC』と同じで、個人レベルのお困りを解決すルツールであり、企業全体の最適化には不向きなのです。
例えば、グループウエアーは、メール機能やスケジュール管理は美しい画面と痒いところに手が届く高機能でとても使いやすいです。
しかし、組織として必要な機能が備わっていない場合があります。
例えば、何かの出来事に連動して自動的に通知する機能を実現する場合、グループウエアーのカスタマイズが必要な場合があります。でも、カスタマイズできないか、出来たとしてもとても高額なカスタマイズ費用が必要な場合があります。
また一方の「クラウド型データベースサービス」は、使用できる機能が少なく、サービスメニューにある仕事以外を行う場合には、別途開発しなければならず、ここでも多額に費用が発生する場合があります。
このように、システムを企業の生産性向上につなげる為に『全体最適』の観点から仕組みを導入しなければ、真に企業の業務の生産性を高めることが出来ないのです。手軽で廉価に使用できるツールを散発的に導入すると、必ず『EUCの弊害』が発生します。
散発的なIT化は、百害あって一利なし。
この事を、まず第一に知って欲しいと思います。
終