情報化プロジェクトは、経営層や業務部門など多くの人間がかかわりを持つ。当然、そこにはさまざまな不安や不満が生まれる。こうした心理学的な側面からプロジェクトの進め方を考えてみる。
前回、企画書の例示から、従来の情報化プロジェクトの考え方や進め方についての問題点の提起をしてみた。
――の重要性を述べた。
少しくどくなるが、今回はその続きである。情報化プロジェクトをうまく進めるためには、多くの関係者を巻き込んでいくことが必要になる。1つの問題をいろいろな立場からとらえ考えてみるのも大切な点だと思う。今回は、“人”??情報化推進の心理学的な面に少し踏み込んでみる。
IT関係者の苦労話の中に、「“NO”とはいわないが、“YES”ともいわないトップ」への不満(?)を時々聞く。前回「企画書内容を、決裁するトップかCIOの立場でみてほしい」と書いた。
・プロジェクトにはリスクや不安が付き物
トップやCIOの立場を想像してこの問題を考えてみよう。意思決定は、メリットとリスクを勘案して行われる。プロジェクトに不確実性を伴うのは当然であり、最終的には勘と度胸と経験の世界だろうが、不確実性が少ないほど決定しやすい。トップといえども会社の隅々まで知り尽くしているわけではない。情報システムの内容にかかわってくるのは、多くの場合、業務プロセスもかなり細部のところである場合が多い。ビジネスの話としての総論なら分かっても、IT関係者に多い機能的表現の各論や、技術の話はよく理解できない方が普通だろう。起案者がIT分野に経験の浅いトップに対し、不必要なリスクや不安を感じなくても済むように留意しておけば、結果は少しは違ってくるであろう。
プロジェクト成功の鍵は「ビジネス上の必要性(必然性)」と、「やり遂げよう」という関係者の強い意志である。「説明した各論から、全体像を想像して重要性を判断して下さい」「理屈ではこんな効果が期待できるはずです」「関係部門にはできるだけ協力を要請してみます」といった、いわばリスクを丸投げするようなスタッフからの提案では、この話のリスクは大変高いといえる(こんな話に乗ってしまったケースも現実には少なからずあるようだが……)。
トップも1人の人間である。結果に対し、誰が責任を取るのか分からないような問題の決裁をするのはシンドイ。一方、ビジネス上の必要性や効果をはっきり説明したうえで、「目的・目標は達成しますから、具体的なところは任せてください」というように当事者がコミットしたことの内容に対し、トップとしてのリスクを考えるのなら、はるかに覚悟しやすいはずである。情報化という業務改革課題について、このようにいえる立場にあるのは、当該業務部門の責任者であり、IT部門の責任者にいえるのは情報システムの部分についてだけである。
情報化のプロジェクトの企画に際して徹底的に議論すべきは、“WHYとWHAT”(何のために何を=目的・効果と課題)と“HOW MUCH”(投資額やコスト)である。ここで納得(「説得」するのではないことに注意!)を得られてはじめて、「それで具体的にどのようにするのか、参考までに知っておきたい」という“HOW TO”(各論や技術の話)に関心を持ってもらえる。
逆に、各論レベルや技術論、「ERPとは」といったよく分からない言葉の説明から始めれば、そのために新たに3つぐらいの分からない項目を使って説明しなければならなくなる。その3項目に質問が出る。それぞれの説明に、さらに3つぐらいの理解困難な話が必要になり、合計9つの疑問が残る。そしてトップもさすがにこれ以上質問することはあきらめて、「問題をよく整理し直して、また次の機会に」といったことに陥る??あなたの会社はこうなってはいないだろうか?
関西のある大手家電企業では、「ITはInnovation & Transformationの担い手」と業務プロセスの革新を進めている。ユーザー企業における情報化の課題は技術の問題ではなく、業務と人の意識の改革問題である。
責任を果たすには、権限の行使が必要になることを前回述べた。
「責任と権限」「義務と権利」、これらは1対のものだ。1対のものは1対のものとして完結されることが、物事をうまく運ぶための必要条件だ。最近は責任を取らずに権限ばかり行使する人間や、権利ばかり主張し、義務を果たそうとしない人間の問題が叫ばれているが、IT問題については「ITに関する仕事」という名の下に、権限を行使できない問題の範囲にまで、IT部門やそのスタッフに責任を求める傾向があった。例えば、CIOに人員整理の責任を負わす企業もあると聞く。
これらの問題と同様に、情報化による「メリットの受益」と「コストの負担」も1対のものとして考えておくべき問題である。先日ある調査を見ていて、ITコストの利用部門への賦課をしていない企業がまだ相当あるようなので、この問題を取り上げてみよう。
「コストの受益者負担の原則」は、情報化投資が効果を生み出すうえでの重要な条件である。1組織の責任者の下でコスト(投資)と効果が完結される形でなければ、「投資対効果の評価」を自分の問題として感じることは大変難しい。自分で費用を負担しないのであれば、「タダなら効果がなくてもともと」と、できる努力もしなくなることがある。また自分に負担が掛からないならば、深く考えずに「思いつくものは何でも要求しておこう」といった無責任な傾向になりがちである。
例として営業組織を考えてみる。
こういった問題は、営業組織を運営管理し、業績に責任を持つ責任者でないと、判断・覚悟のできない。だからこそ真剣に考えてもらうための仕組みが必要なのだ。
だが業績に責任を負う立場の人にとって、コストの負担は重要な条件になる。「本社主導で行う全社課題であるので、費用は本社で持つから各部門は協力してほしい」。??こんな話を聞くことがある。企業ごとや状況により、いろいろな考え方があるとは思う。しかし「コスト負担がないから協力してもらいやすい」と考えるのは少し甘いのではないだろうか。やろうとしていることは、結果的に各部門にもためになるはずだ。各部門にも応分の負担があってしかるべきなのである。一方的に実施が決められ、そのうえコスト負担まで求められれば、文句もいいたくなるのが自然だろう。そうすれば「どうしてもやるなら、ここはこうしてほしい」と真剣に要求も考える。けんか腰の議論や交渉が始められるかもしれない。こうした真剣な議論や苦労があって、その結果本当に有効なものが生まれる。
あなたの仕事や個人生活の中にも同じようなことはないだろうか。「安易さに気を許し、簡単に飛び付いてしまったが役に立たなかった」「値段が安いため、あまり考えもせずガラクタを買ってしまった」「お金の掛からないテレビやラジオの外国語会話講座は途中で挫折し、身銭を切った会話学校の月謝分だけが身に付いた」……などなど。
古い話で恐縮だが、オンラインシステムやデータベースの黎明期であった30年も昔は、これらのシステム開発プロジェクトの3割程度が、プロジェクト進行途上で暗礁に乗り上げてしまうような時代であった。当時筆者はシステム開発担当の課長をしていて、“システム開発方法論”の導入を考えていた。それは価格が600万円、数日分のコンサルテーション付き・厚さ数センチメートルの資料だった。なぜ600万円か理解してくれる人は少なかった。
600万円というのは“良い(適切な)”値段だったと思う。もし1けた高ければ、経済的に導入は不可能だったし、もし1けた安い60万円だったら「ダメでもともと」といった安易な気持ちで真剣に取り組まなかったかもしれない。周囲になかなか理解してもらいにくい「ソフト」にお金を払う習慣のない時代の大枚600万円の代物である。自社に適合させるため数カ月かけて意地になってカスタマイズした。ウォーターフォール型で基幹システムをCOBOLで作ることを暗黙の前提においた内容は、現在では技術的にはそのままでというわけにはいかなくなった。しかし開発プロセスの個々の作業に対するユーザ部門の役割、IT部門の役割、あるいはプロジェクトの体制、フェイズレビューなどプロジェクトマネジメントの基本的な仕組み、さらにはプロジェクトのスポンサー、システムのオーナーシップに対する考え方やシステム評価など、ITガバナンスの仕組みは社内常識として現在も機能している。
こんな古い話をわざわざ持ち出したのは、モノの適切な値段とコスト負担の重要性を述べたかったからである。払う方からすれば、そのときには安いほどありがたい。しかしその半面、代償として失うものが少なからずあることをも認識しておくべきだと思う。
国のIT政策の一環として、中小企業のIT化にかなりの補助金が使われている。費用の3分の1を国から、残りを府県や市からの助成に頼ろうという企業もある。どうしてもやりたいことがあるが、資金がなくて手が付けられないという企業にとってはありがたい制度であろうが、一方には「補助金をもらえるのならやってみようか」といった安易な考え方のところもないわけではない。補助金の申請書の作文にエネルギーを使った企業と、本来の自助努力にエネルギーを向けた企業では、将来どちらがより強靭な企業になるだろうか。
IT部門や経営スタッフ部門が作る情報化の企画案は、その対象とされた業務部門にはどのように映るであろうか。
情報化の課題の引き金は新技術にあるのではなく、そのほとんどが社内の業務問題にある。ユーザー企業の視点に立てば、業務の在り方を抜本的に変えるような画期的な技術は、過去20?30年を通してみても数年に1つあるかないかである(技術を商品化して商売に結び付ける売り手側にとっては、技術は日進月歩の問題だろう)。
情報化は、前に書いたように業務改革であり、情報化の企画とは、業務部門が「自分の領土」と思っている業務の仕組みや体制にあれこれ注文を付ける、いわば内政干渉行為でもある。ほかの経営スタッフ部門も経営の方向を示し、その具体策の検討や実施を求めたり、監査部門が問題を指摘して改善を求めたり、問題を提起して答えを求めている。しかし、情報化の企画には、業務プロセスの問題を拾い出し、その変更や情報システムなどという具体レベルの“答え”を提案するという点が、上記の他部門の行為と大きく異なり、ここにいろいろな問題が存在しているように思う。
最初の問題は、「企画内容の妥当性」の問題である。「具体的なレベルで本当に問題点が正確に把握できているのか」「解決策は的確なのか」。つまり、企画する人の状況把握力や判断力、見識を問われる問題がある。相手にしてもらえる合格ライン「あたらずといえども遠からずの内容と、何か1つ“これは!”と思わせる点があること」、このレベルをクリアすることが必須である。
「業務プロセスを熟知すること」は必須要件である。現場を知らない、現場に出掛けたがらない人に企画は難しい。どの部門にも比較的自由に出入りできる立場にあることを、IT部門の特権として最大限に生かすことだ。
業務の現状を最もよく知っているのは業務部門の担当者だ。しかし、その業務部門を改革するには別の知恵が必要になる。全体プロセスの最適化を考えるならば、仕事の流れに沿って隣の部門のプロセスをも把握しているIT部門のメリットを生かせるかもしれない。なぜなら、自分の組織の常識になっていることには、たとえそれ自体が問題であっても問題として気付かない場合が多いからだ。こんな問題が業務部門にあるなら、少し離れて客観的な目で実態を見られる(あるいはほかの業界の状況について情報入手できる)IT部門に利がある。
同じ会社の中にいれば、業界の動向や会社の進もうとしている方向や問題点、業務の実態や携わっている人たちの特性などは、特に手を掛けないでも把握できる。少し意識していれば、頭の中に会社全体の問題イメージを形成しておくことも容易である。この点は社外のコンサルタントなどに比べて圧倒的に有利な点である。
つまり、IT部門はその気になれば、あまり苦労することなく問題やその背景を把握・熟知でき、かつ問題を少し離れたところから客観的に見られるという立場に立てる。この立場を生かし、社内の業務プロセスを仕事の土俵とし、業務改革の考え方をマスターすれば、自社の情報化・業務改革の問題に対して、世の中のほかの誰よりも良い答えを短時間で出せるはずである。この分野でなら、オンリーワン/ナンバーワンになれる可能性がある。
IT部門は以下のことを真剣に考えてみてはどうだろうか。
ITの技術については社外にもっと優れた専門家がたくさんいる。IT部門がITの技術だけにしがみついている限り、オンリーワン・ナンバーワンになることは大変難しい。
さて、ここまでは“理”の世界の話である。こんなことを背景に、合格点の情報化の企画案ができるところまできたとしよう。方向や内容を決めるのは“理屈”であっても、人の行動を左右するのは“感情”だ。そこで、いまから“情”の世界の話に入ることにする。
各部門は経営トップや上層部から、業績の向上や組織の効率化、業務革新策を求められている。ここへ立派な情報化の企画を持ち込めば、ありがたいと思われるであろうか。もちろん、会社の文化、相手の性格、相手との人間関係などにより違いは出てくるが、理屈はそうでも結果はそうはならないから、問題は微妙である。
相手からすれば、自分の領分と考えている業務の内容への一種の干渉である。こちらの状況を完全には把握できていない他部門の人間が考えたことだ。それだけでも面白くない。自分も問題があることは先刻承知しているが、それより優先度の高いほかの問題があり、いまこんな企画を持ち出されるのは迷惑という場合もある。
さらに複雑な問題もある。提示された企画内容がお粗末なものならまだ救われるが、大変優れた内容であったならどうであろうか。業務の内容にかかわる問題であるから、「本来自分が考えるべき」という気持ちも心の底にあり、少しは後ろめたさもある。そこへ外部の人間から、もしかしたら自分が考えるより優れているかもしれない問題解決案を示されれば、面白くない気持ちになるのが自然であろう。
もし、こんな企画が自分の承知しないうちに、トップの前で提案されるようなことにでもなれば、こんな感情に加えて、自分の立場を守るためにも、その企画つぶしに走らざるを得ないような立場に追い込まれることになる。勝手知ったる自分が管轄する業務である。あることないこと並べて、いかにその企画の内容が的外れであるか、問題だらけかを述べざるを得なくなる。
それでも、トップがGOの指示をしたとすれば、問題はますます複雑になる。形のうえではトップの指示に従うポーズを取りながら、自分のいったことの正当性を証明するためにも、そのプロジェクトの失敗を願う気持ちが心の底に残っても不思議ではない。彼/彼女の部下は、その上司の顔色を見ながら仕事をする。その部門のその後の行動は中途半端なものとなり、上司の望みどおり、成果の見えない結果に終わる。
これは分かりやすくするために少し極端な表現をしているが、企画検討?調整?提案?決裁の一連のプロセスの中で、「タイミングを取り違えた」「話の切り出し方を間違った」「話をしていく相手と順序を間違えた」など、どこかで虎のしっぽを踏んでいたり、ボタンの掛け違えをしていることはないだろうか。ユーザー部門の協力が得られないと悩んでおられる方は、こんなことになっていないか1度振り返ってみてはどうだろう。
情報システムは作ることが目的ではない。人・部門がうまく使い、この部門が効果を上げることが目的である。人間誰しも自分が必要と感じ、自分がやろうと結論を出した(と思える)ことには一生懸命になれる。逆に、いくら「良い」と理屈では思っても、他人からいわれたことをやるのは何か抵抗感があるのが普通だ。
情報化の企画の仕事は、1人で立派な完成した内容にまとめ上げることではない。絶妙のタイミングで“最適な未完成度”のたたき台を適切な相手に提示し、関係者をうまく巻き込み、一緒に検討しながら結果的には相手に「自分が完成させた」と思わせるようにする、そんな形がその後の作業がうまく進む基本的なパターンのように思う。
公江 義隆(こうえ よしたか)
ITコーディネータ、情報処理技術者(特種)、情報システムコンサルタント(日本情報システム・ユーザー協会:JUAS)
元武田薬品情報システム部長、1999年12月定年退職後、ITSSP事業(経済産業省)、沖縄型産業振興プロジェクト(内閣府沖縄総合事務局経済産業部)、コンサルティング活動などを通じて中小企業のIT課題にかかわる
Copyright © ITmedia, Inc. All Rights Reserved.