連載
» 2003年12月05日 12時00分 公開

何かがおかしいIT化の進め方(1):世評やベンダの意見に踊らされていませんか?

中堅・中小企業のIT推進コンサルタントとして活躍する著者が、実際の見聞を基にしたエッセイの中でIT推進策を指南。第1回は世評やベンダの甘言に乗せられた「何かおかしい情報化の進め方」の原因を解明

[公江義隆,@IT]
編集局より:「中堅・中小企業のIT化問題を考える」というタイトルで始まった本連載ですが、「企業規模にかかわらず広く情報化推進の問題点を考えていきたい」という著者の意向から、タイトルを「何かがおかしいIT化の進め方」に変更することにしました。

まえがき

 編集部から、情報システム部門キーマンに向け、例えば「事例記事から得られない情報を引き出すにはどうすればよいか」、中堅・中小企業で「限られた予算の中でIT化を進めるにはどうすればよいか」、「社内のITリテラシーを上げる方策」などIT化推進に関するちょっとしたノウハウや情報収集活動などについて、体験や見聞した事例を基に書いてみないかというお話をいただいた。

 いつものことながら安請け合いをしてから慌て始める。私は普段読者として、雑誌などのIT事例記事やコンサルタントや学者の書いた経営改革成功物語を読んでいるが、正直にいえば、これらはうそではないが重要な事項や真実が必ずしも述べられているわけでもない“ノンフィクション小説”ぐらいのつもりで受け取っている思う。こうした情報は、むしろ日ごろのいろいろな人との付き合いの中で無意識に得ていることの方が多いと思うし、必要に迫られたときには手段を意識せずにやっていることなので、正面切って「どうすればよいか」と問われると考え込んでしまう。

 本当に困った場合には知っていそうな人間のところへ「こんにちは、XXを教えて下さい」と出掛けて行った。前提に条件はいろいろあっても、結果的には教えてもらえなかったことはほとんどなかった。私共のところへ時々お訪ねいただくこともあったが、「この忙しいときにかなわんな?」と思いながらも、時間も忘れて、われながら親切に応対していたように思う。人間というのはつくづく教えるのが好きな動物だと思ってきた。

 こんな場合、聞かれる方にすれば「何を聞きたいの?」であるし、聞く方にすれば何が問題かよく分かっていないから、何を聞けばいいのかが定かでない場合もある。こんなちょっとアマノジャク的なとらえ方をしながら、このシリーズのいろいろな問題の中で情報収集の問題にも触れていきたいと思う。

中小企業はシステム化の概念が通用しない?

 ここ数年、国の進める中堅・中小企業の情報化推進プロジェクトにかかわったり、コンサルタントのまね事をして20?30社の中小企業について少し詳しく状況を知る機会があった。

 投資対効果を考えた場合、「中小企業は従来のシステム化の概念の通用しない世界」という印象が残る。最重要の経営問題にアプリケーション課題を絞り込むことが1つのポイントだと思うが、現実には効果はよく見えないまま、「コストだけは確実に発生するインフラ整備をして終わり」というところも少なくない。効果に結び付くのは、アプリケーションシステムである。「パソコンやLAN、インターネットや電子メール、会計ソフトと表計算などを導入し、社員がコンピュータに慣れればそのうちうまいアイデアも出てきますよ」といったベンダにとっての“うまい話”は、ユーザー企業にとっては多くの場合“甘い話”に終わる。

 世に何となくある“インフラ先行論”は正しいのであろうか? 少なくとも技術の変化が激しいITの分野では、このインフラ部分が最も陳腐化の速い分野である。「そのうちに出てくる」(?)といううまいアイデアを実現するころには、思い切って導入したパソコンやソフトも時代遅れのものになっている可能性が高い。ほんの2?3年前、通信回線の利用料金が高くブロードバンドが普及していないことが、日本の情報化の阻害要因と騒ぎ立てられていた。現在、日本は通信回線コストの安さやブロードバンドの普及で世界有数の国になった。だが、果たして飛躍的に情報化が進んだのだろうか。

 「ITに関する世の中のいろいろな情報や考え方、どこかがおかしいと思いませんか?」

 ユーザー企業のIT関係者は相変わらず大変苦労している。仕事に苦労はつきものとはいえ、効果につながらない苦労が多過ぎはしないだろうか。「世間でいわれていることや、われわれが思い込んでいることが何かおかしいのではないか」??ITの問題全体にかかわるテーマとして、今回から数回、こんな問題を考えてみたいと思う。

社長かCIOのつもりで企画書を読んでみる

 例えば、下記のようなCRM(Customer Relationship Management)システム開発・導入のプロジェクトがあり、この企画書の内容が次のようなものであったとしよう。もちろん企業によって事情は違ってくるし、また唯一の正解がある問題でもないが、「どのあたりに、どんな問題がありそうか、注意点は何か」などを、決裁する側の社長かCIOになったつもりで、各項目をじっくりにらんでいただきたい。

情報化企画書
・プロジェクトの目的 CRMシステムの開発・導入
・システムの期待効果 顧客満足度の向上が図れる
・プロジェクト推進体制
・プロジェクト責任者 経営企画室IT戦略担当次長
・プロジェクトメンバー 実務に明るい主任クラスの営業担当者を営業各部からそれぞれ1〜2名(専任)
情報システムセンターおよびグループ子会社からシステム開発担当管理者(マネージャクラス)、およびSE数名(専任)(なお、SEは必要な際には非専任の応援者を考慮する)
・スケジュール 社長の決裁後、直ちに着手、1年後の稼働開始を目指す
・留意事項 営業各部には経営企画室長から協力を要請する
・開発費用 xxx
・運用費用 yyy
・費用負担 経営企画室
・起案 経営企画室IT戦略グループ

 経営上、大変重要な投資効果評価に関する問題として、まずこんなことが気にならないだろうか。

  • xxx円の投資、一時的なフローとしての問題とともに、償却費と名を変えて数年間費用として発生する。これと毎年yyy円の運用費用とを合わせて相当費用が増えるが、この費用増に勝る効果があるのか?
  • 「顧客満足度の向上が図れる」と書いてあるが、そもそも顧客満足度とは具体的に何か?
  • 現在の顧客満足度がどうであって、それをどのようにするというのか?
  • 顧客満足度を上げて、結果として何がどうなるのか? 売り上げは増えるのか?

 ……

 「こんな問題に対する判断ぐらい、経営者たるものできなくてはいけない」という、有識者やIT分野を背景にする人からの勇ましい意見もあるが、果たしてそれで問題は解決するのであろうか。

情報化は業務改革プロジェクトととらえる

 効果は情報システムそのものではなく、業務プロセスやこのプロセスにかかわる“人”を通じて発現する。「95点の立派な情報システムと、“関心の薄い人”との組み合わせ」より、「技術的には65点(かろうじて合格点)のシステムと、“やる気のある人”との組み合わせ」の方がはるかに大きな効果を上げるのが情報化の特性である。

 もちろん、上記の課題で求める効果は「売り上げ増」である。効果を出すためには、営業の仕事を見直し(業務プロセスの改革)、管理者や担当者の意識改革と、新しい業務の方法やCRMシステムを使いこなすための教育を行い、場合によれば何らかのインセンティブや、やろうとしない人に対してはある種のペナルティも必要かもしれない。つまり、情報化投資とは情報システム作りではなく、これら業務プロセスの改革、“人”にかかわる仕組み作り、そして情報システムの“もの”作り、これらを一体にした問題なのだ。この中で主役は業務プロセスと“人”であり、情報システムは高いギャラを取る脇役なのである。

 先日、あるIT関連団体のアンケート調査項目に「……IT投資を成功させるために、業務の標準化やBPR(業務改革)はどの程度重要と……」という文言があった。“ITは経営の道具”と理屈では分かっていながら、具体面では情報システムをうまく動かすために業務面の協力を求めるといったような、IT中心の“IT天動説”的な発想や行動になってはいなかっただろうか。

 企業は効果を求めて情報化投資をする。経営や業務上の問題解決や、目的達成を結果として完結する範囲が、企業にとって1つの仕事の単位になる。経営の道具であるITは、残念ながらそのもの自体が経営目的になることはない。情報システムの運用が、業務運用と表裏一体の「本来業務の一部」という考え方はあっても、情報システムの開発業務は本来業務からは非常に懸け離れた存在なのである。厳しい見方をすれば、「このような仕事に、お金も時間も人のエネルギーも使わなくても済むなら使いたくない」のだ。ITは効果を上げるために使うのであり、「仕方がないから作る」というのが経営者の本音であっても不思議ではない。情報システム開発作業こそが、IT部門にとっては長年にわたり中心的課題であった。この位置付けに関するギャップが、いろいろな問題の源の1つかもしれない。

 また経営側にとっては、ちまたで聞く「ITの効用論」という漠然としたプラスイメージと、足元を見ると必ずしも明確な説明のない効果、確実に増加しているITコストや、何をやっているのかよく理解できない多数のIT関係社員などのマイナス面的なITへの関心が交差している。

 そうした中、大きなキャッシュアウトの発生する情報システム開発作業に関心が集中するが、上記のように業務プロセス改革や“人”にかかわる仕組み作りにも、外からは見えにくい多大の内部コストや人的エネルギーの投入が必要で、こちらの作業が効果を出すうえで、問題の中核なのだという認識を関係者間で十分に共有しなければならない。

手段の目的化を防ぐ

 このように考えれば、上述の例におけるプロジェクトの目的は「売り上げの増加」であり、その方法・手段がCRMによる営業業務の革新であり、CRM情報システムの開発・導入は、そのために必要な要素・道具の1つだという位置付けが明確になるはずだ。何だかITの格下げのように感じられる方がおられるかもしれないが、これが本当の姿である。

 こういう枠組みで問題をとらえれば、やるべきことの全体像が浮かび上がってくる。業務面、システム面で「誰が何をやらなければならないか」がはっきりしてくる。これら全体の作業項目を含めて完結した1つのプロジェクトになる。こうすればプロジェクトの評価も容易になるし、目的がはっきりしているから、モノ作りの設計や管理の判断もやりやすい。

 一方、前出の企画書のような考え方で進めていけばどんなことになるであろうか? CRMのシステム開発が目的であるから、具体化しようとしても要件設定や設計条件のよりどころがない。「顧客満足とは何か」という訳の分からない議論で、本当に訳が分からなくなってしまうのが落ちである。自社の本当のニーズとは無関係に仕様の決定が進んでしまう。問題意識や具体的なニーズを感じていない利用部門にしても「この仕様でよいか? 問題があればXX日までに……」と問われても、そもそも業務をよく分かっていないIT部門が勝手に始めたテーマである。「そんなことを急にいわれても……」といいたいところだが、スケジュールに縛られたプロジェクト側は、返事がないのは了承を得たとして前に進めてしまう。

 利用部門からプロジェクトに参加させられたメンバーは大変気の毒な立場になる。プロジェクトと利用部門の懸け橋を期待していたはずの彼・彼女らは、プロジェクトに寄りつかなくなるか、利用部門に寄り付かなくなるなど、その場その場を何とか切り抜ける行動に走るようになる。その問題は総合テスト段階で顕在化する。建前上、利用部門が了承したことになっている仕様は、「こんなものでは使い物にならない」と批判される原因になっている。

 運よく宙ぶらりんにまではならなくても、機能変更・追加で修正作業が繰り返され、作業が進むほど、仕事が増えてくる。そのままやれば、コストやスケジュールはどこで収束するのか分からない状況になる。そして不本意ながらあまり根拠のないところで、ひとまず打ち切りということになる。関係者のすべてに不満を残したまま、出発点から形がい化したシステムになる。誰もこのシステムに愛着を持てないから、システムを活用して効果に結び付けようといった奇特な人は利用部門にはいない。必要性を認識していないから内容もよく理解しようとはしない。やがてIT部門にも、利用部門がまともに使おうとしないシステムを大事に扱おうという人がいなくなる。効果のないまま、確実に多大のコストを残してシステムは早期引退ということに陥る??これでもまだ、“不幸中の小不幸”のケースである。

 “不幸中の大不幸”もある。トップの思い付きを鳴り物入りで始めたため、「口が裂けても誰も失敗とはいえない、いつまでもやめられない」のだが、世の中には成功ケースで通っているこんなシステムもないわけではない。

起案・プロジェクト責任者はユーザー部門の長にお願いする

 いまもって、企画書の中で「期待効果」「XXができる」という表現を見ることがある。20?30年前、コンピュータメーカーが提案書の中で使っていた言葉だと思うが、これは本来外部の人が使う言葉だ。社内の企画書なら効果は「XXする」と書くべきだろう。この例なら「売り上げをXXにする、XX増大させる」である。

 効果を出すには、“人”の意志が極めて重要である。「何とかして売り上げをXX伸ばしたい、伸ばそう」という必要性と「強い意志」があって初めて困難を克服する発想や行動が生まれてくる。

 「XXができる」と「XXする」との差は大変大きい。「XXする」と書いたとき、主語は“私”つまり企画書を書いた人、起案者である。「私がXXする」と責任を持っていえる、裏返せば実現するために必要な権限を行使できる立場の人でなければ、プロジェクトの結果に対する責任は負い切れない。

 プロジェクトを成功させるためには、人事異動や組織変更が必要だったり、協力者へのインセンティブや、場合によってはやろうとしない人へのペナルティも必要になる。経営企画室やIT部門などのスタッフ組織には、仮にどうすべきか分かっていても、ラインである営業部に対して、具体的な指示や命令をする権限はないのが普通である。つまり「(理屈では)XXできる」としか書けない立場なのである。

 “理屈ではできるはずのことを、やるべき人がやってくれなかったので、うまくいかなかった。そのために大変苦労した”プロジェクトがあまりにも多い。その背景の1つがこんなところにある。利用部門に納得してもらえないような内容のシステムを、トップの虎の威を借りてやろうとしてもそう長続きするものではない。その時点ではITに関心のあるトップであっても、そういつまでもITにかかわってはおられない。

 スタッフ部門およびIT部門は、事前検討・準備、ユーザー部門への働きかけを行って、共同検討してユーザー部門をやる気にさせるまでが勝負、その後は事務局など黒子に徹して、表に立てたユーザー部門を支える役割にまわるのが正解のように思う。「何か割が合わない」と思われるかもしれないが、裏で支えて「結果良ければそれで善し」という実を取るのもまた良い人生かもしれない。世の多くのことには、表に出てやるべき立場の人と裏で支える役割の人、両者が必要である。

 現場の指揮も、人集めや広報などフロントの仕事も、1人でやってチームを優勝させたプロ野球監督がいた。“名実共に必要なことをすべて1人で”というのは、能力があっても大変に大変シンドイことである。全エネルギーを投入して、2年で引退する覚悟をして花を咲かせるといったことなのかもしれない。

profile

公江 義隆(こうえ よしたか)

ITコーディネータ、情報処理技術者(特種)、情報システムコンサルタント(日本情報システム・ユーザー協会:JUAS)

元武田薬品情報システム部長、1999年12月定年退職後、ITSSP事業(経済産業省)、沖縄型産業振興プロジェクト(内閣府沖縄総合事務局経済産業部)、コンサルティング活動などを通じて中小企業のIT課題にかかわる


「何かがおかしいIT化の進め方」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ

マーケット解説

- PR -