社内にITを根付かせる5つのポイントITガバナンスの正体(4)(1/2 ページ)

» 2004年03月06日 12時00分 公開
[三原渉(フューチャーシステムコンサルティング),@IT]

筆者より:

本稿では、ITガバナンスを各企業で確立していくために、ITマネージャが「考える・分かる・応える・使える・変わる・変える」ことを目指します。前回「IT改革・改善を実現する組織の作り方」で、業務部門の中にもIT推進担当者など種々の役割を置くこと、さらにIT部門は並行している業務に優先順位を付け、適切なリソース配分を行うことを解説しました。次に、ITマネージャは何をすべきでしょうか?


ショートストーリー 山の手精工株式会社物語

<前回までのあらすじ>社員2000人の製造業「山の手精工株式会社」では、上野社長の指揮の下、CIOの神田取締役と情報システム部門長・池袋マネージャがITガバナンスの確立に取り組んでいる。社内業務部門に協力を仰ぐため、実際に業務担当者がITについてどう考えているかヒアリングすることに。だが大崎さんの日程調整努力の甲斐もむなしく、業務部門の主だった人々には個別にお話を聞くことになった――。

池袋マネージャ:みんな忙しい、忙しいって結局一堂に会する時間がなかったので、個別に当たってるんですよ。開発部門は個別技術の研究でも、IT導入は進んでいるので、さほど問題があるとは思ってなかったんだけど……。


代々木課長(開発):う〜ん。いま現在の業務をこなすには困っていることはないけど、将来に不安があるねぇ……。というのは、「分業」というか役割が分担されているから、1つ1つのシステムはうまく使いこなせてるんだ。要は、人がシステムに付いちゃっているわけ。人にシステムや業務が付いちゃっているから、その人には居心地がいいんだけど、ほかの業務をさせられない。


巣鴨リーダー(課長職):そりゃもうITの問題じゃないですねぇ。開発部門で考えて進めてくれたらいいと思うんですけど……。


代々木課長(開発):そうじゃないだろ。君は、いつも最後まで話を聞いてくれないね。ローテーションできないから、人が育たない。与えられた業務やシステムをこなすだけだから、問題が何なのか出てこないんだ。このままだと、改善点も見えてこないし、将来の仕組みや業務も見えてこない。どうしたらいいんだろうなぁ。



そのころ、大崎さんは営業所を訪れていた。


日暮里くん(営業): SFA(sales force automation)が鳴り物入りで導入されましたよね。追加機能で経費精算ができるようになったのはみんな喜んでいるんだけど、パソコンの持ち運びは重いし、システムも使い勝手が思ったほど良くないと考えている人が多いんです。「隴を得て蜀を望む」って感じですね。


大崎さん(企画・業務部門サポート担当): 完璧なんてあり得ないのよ。ちょっと手に入ると、より良いものが欲しくなるのは人の常よね。それはそれで、良い情報を得られました。導入のときには気を付けて、教育や試用期間を設けているつもりだったんだけど……。足りなかったのかな?


日暮里くん(営業): 個々人のシステムを活用する意識だとか、パソコンを使う力、なんていいましたっけ? リテラシーが上がってこないこと自体、切実な問題だと思います。だって、SFAのために時間を使っている人が多いんですよ。当初もくろんでいた「IT導入によって業務の効率化を実現し、時間を作って、営業時間を増やす」ということの反対になっちゃってる。この間調査してみたら、営業そのものの時間は減ってるんですよ。「本末転倒」ですよ。



片や、秋葉原さん(運用担当)は、人事総務の新橋課長と対峙(?)していた。


新橋課長(人事総務):人事マスタを人事の人間が入力するようにしたときは、説得やら準備やら大変だったけど、正確性は増すし、異動のときもタイミングよくできるし、システム部門は時間がほかの業務に使えるようになって良かったよな。秋葉原さんにも世話になったね。


秋葉原さん(運用担当):なるほど!(あれ? 池袋マネージャの口癖がうつっちゃったかな?)あのときは苦労も多かったけど、達成感がありましたね。業務部門(人事部門)とシステム部門の役割分担がきちんとできたプロジェクトでした。人事異動もワンストップでできるようになったし。異動される方がたらい回しにされなくなったことも大きいですよね。


新橋課長(人事総務):でも、いま問題なのは、社員全員のIT研修のことなんだ。いや、IT研修だけじゃない。どんな人材を育てなきゃいけないかというところなんだ。システム部門にお願いしなきゃいけないことも出てくるだろ?



ビジネス上の目的・目標と、プロジェクトの目的・目標

今回は、「ITガバナンス」の5つの領域の3番目、「活用・展開力」だ。

活用・展開力:ITを導入するときには業務・組織の変化が必要だが、その変化をマネージする力を指す。具体的には、導入されたITを活用・展開する力であり、ITリテラシーも含む。業務改革を進める力

 そもそもITは何のために必要なのか。その目的・目標(効果目標)は、IT戦略で整理されていなければならないが、ITを必要とする業務部門でこそ、この目的・目標を議論する必要がある。そして必要な効果から逆算して、必要な業務の在り方やIT、それを組み立てる業務改革・システム構築プロジェクトのスケジュールを考えてもらわなくてはならない。その企画をサポートすることも、ITマネージャの役割の1つだ。

 トップマネジメント層や業務部門の中には、「プロジェクトを終了したら、効果が必ず、しかも即時に出る」という誤解をしている人が多い。またシステム部門やシステム構築関係者にも、「プロジェクトの終了は、情報システムが稼働し、新しい業務が動き始めたという時点」という誤解があることも確かだ。そうではない。

 ビジネス上の目的・目標と、プロジェクトの目的・目標は異なる。というより、プロジェクトの目的・目標は、ビジネス上のそれの中に含まれる関係にある。

図1 ビジネス上の目的・目標と プロジェクトの目的・目標の関係

 プロジェクトの目的・目標は、ビジネス上の目的・目標の通過点にすぎない。例を挙げると、

  • ビジネス上の目的・目標:人材の把握を行い適材適所への配置を行う。結果、作業効率の向上と人材育成(OJT)を可能にする。プロジェクト終了後の期末決算時(約1年後)に年間2億円の人件費削減(残業代含む)をもくろむ。
  • プロジェクトの目的・目標:社員の業務履歴・研修履歴・保有スキルを、随時最新の状態に保てる人材情報システムを構築する。同時に、全社員がこのシステムにアクセスし、自分の情報を入力できる環境の提供と教育を実施する。

 「プロジェクト」の範疇をどこまでにするかは各社各様なので、ここでは議論しないが、一般的に上記のような例に当てはめることができる。しかしながら、両者が同一視されることもよくある。その結果、業務・システム再構築プロジェクトが終了したのに、効果が出ず、「プロジェクトを実施したメンバーの責任だ」などと犯人捜しが始まったりする。読者の中には、被害者(?)になってしまったり、えん罪をこうむった人も少なくないだろう。

 効果とは、業務部門を中心とした「業務の遂行」があって初めて出るものだ。システム部門は、その効果発現のための仕組み作りや業務遂行の支援を行っており、使い勝手の良い仕組みや、将来にわたって更新・運用しやすい仕組みを作るという責任を持っている。これを業務部門やトップマネジメント層によく理解してもらわなくてはならない。

 ビジネス上の目的・目標とプロジェクトの目的・目標は、必ず区別して表現するとともに、関係者理解の下プロジェクトを発足させたい(トップマネジメント層とのコミュニケーションは、連載第2回でも説明した)。そして企画時や進ちょく報告時に、このことを確認・共有しておく必要がある。勝手に各人の頭の中に夢を形成されないようにするためだ。

 「プロジェクトの当初の目的が達成されない」という指摘があったときには、「プロジェクトの目的・目標」の話なのか、「ビジネス上の目的・目標」の話なのか、十分に吟味して会話に臨んでほしい。いずれにしろ、業務部門とシステム部門のどちらにも責任があり、どちらか片方(特にシステム部門)だけに責任があるということはあり得ない。

 ついては、「情報システムを使いこなして、効果を出す」というところに焦点を当てることにしよう。

必要な機能を装備し、ITを活用させるには

 情報システムを使いこなしてもらう大前提は、仕事に有用な機能がその情報システムに組み込まれているということだ。そこで業務部門と協力して、必要な機能は何かを整理しなくてはならない。

 もちろん、どのプロジェクトでも新旧の業務フローを書いたり、業務部門での問題点を洗い出すなどの作業をしているはずだが、ちょっと待ってほしい。まずはプロジェクトの中で、「そもそもそれが本当に必要な業務なのか」を考える時間を持ってもらいたい。もしくは、プロジェクト発足前や企画段階で、業務部門においてこうした問題を考える時間を取ってもらうのもよい。その業務は、企業の活動の中で、どのような付加価値を創出しているのか? その業務の顧客・サービスの向先(消費者・得意先・社内顧客)へのアウトプットは何か? その品質要求はどのようなものなのか?

図1 業務の5つの要素

 こうしてすべての業務を分解していくと、図1のような5つの要素の集合体になる。分解された5つの要素がそろっているか? そろっていなければ、何かがおかしい。おかしいということは、その「業務」と目されるものは、廃止・簡素化・効率化・移管のどれかによって、ほかのものと整理統廃合できる。大きくとらえても、小さく分解しても、業務はこの5つの要素から成り立っている。

 このような議論を、業務部門と整理・ディスカッションする機会を設けて、その業務の最も根幹の要素をとらえてほしい。これが必要機能の整理と密接にかかわってくる。業務の形が見えてきたら、その業務をITでどのように実現できるのかを考えればよい。もしかすると、IT化するより人手でやった方が効率的かもしれない。この部分もディスカッションを要する。

 こうすることで、IT化に失敗する確率は少なくなる。必要な機能を業務部門と十分にディスカッションできていれば、システム構築後に「こんな機能は要らない」「こんなはずじゃなかった」などというクレームに付き合わなくて済むし、何よりも合意のうえでのシステム構築となるので協力も得やすくなる。

 そのうえで、IT部門・システム部門から、新しい技術をどのように使えば、どの業務が簡便になるか(廃止・簡素化・効率化・移管のどれか)、ということを提案していくことで、より密接な関係を築き、より意味のあるディスカッションができるようになる。こうした取り組みが、「システムが有効活用される仕組み(作り)」につながっていく。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ