プロジェクトマネジメント、プロジェクト管理におけるポータルサイト

HOME > プロマネの勘所 > 【林衛の業界探求シリーズ】第二回 ユーザー側の意識、IT部門側の意識

2006年11月17日

【林衛の業界探求シリーズ】第二回 ユーザー側の意識、IT部門側の意識

矢澤篤志さん

矢澤篤志氏プロフィール
最終学歴 中央大学 商学部
1981(昭和56)年 4月 カシオ計算機入社
2003(平成15)年 4月 業務開発部長
2006(平成18)年 6月 執行役員 業務開発部長

ユーザー側の意識、IT部門側の意識

矢澤篤志さん


やはり矢澤さんがユーザー部門でキャリアを積まれたことは大きいと思います。IT部門でも、我々のようなコンサルタントもそうですけど、ユーザー系企業の利用者の立場を経験していると成功する確率が高いです。なぜかというと提供する側だけの論理で押し通すのではなく、ユーザーの痛みが分かるからです。

矢澤
確かに、そういうものかもしれませんね。


弊社のコンサルタントの何割かはユーザー系企業の出身ですよ。そういうコンサルタントがリーダーシップをとるとお客さまと相性がいい。同じ気持ちになれるというのは大きいです。もっとも弊社のお客さまの中にも、ずっとIT部門の人もいれば、ユーザー側からIT部門に移ってきた人、ユーザーなのにITに興味がある人といろいろですから、そことのバランスもありますが。

矢澤
そのようなわけでユーザー部門からIT部門にきましたから、私はユーザーと対話するときのコミュニケーションという意味ではあまり問題なかったんですけど、むしろIT部門の人たちとのコミュニケーションなり、IT部門の人たちをどう変えるかというところがたいへんでした。


極端ないい方をしますと、言葉が通じませんものね(笑)。

矢澤
通じないですね(笑)。まず役割認識が全然違います。ユーザー側で考えているIT部門の役割とIT部門が考えている自分たちの役割とが、もう全然違う。
IT部門に異動して最初に会議に出たときのことでした。課長さんくらいを集めた会議に、私は一応システム企画室所属という立場で出席したのです。そこで他の出席者たちが言うには、「システム部門から企画することなんてないんだ」と言うわけですよ。「ユーザーが企画したことをそのままやればいい」。それを聞いた時にはもう唖然としましたね(笑)。
その上さらに、彼らは「自分たちに企画はできない」と言うわけですよ。「ユーザーが言うとおりにシステム化をしていけばいい」と。ユーザーが構想してユーザーが設計に落として、そのとおりに自分たちが作っていけばいいんだという認識なのです。

ユーザーを繋ぐ「のりしろ」はIT部門の役割

矢澤篤志さん


自分たちの論理ではそれなりの理屈には聞こえてしまうところが怖いですね。要するにどちらも相手側を知らないということだから、誰かが間に立って仕事しないと。

矢澤
そうなんです。じゃあ、どちらが間に立つかということになるのですが、ユーザーというのは、私もその立場でしたからよく分かるんですけども、結局、自分の世界しか見えていませんから、「のりしろ」になるのはIT部門しかいないわけです。システムというのはそれぞれ個別の業務だけでできるわけではなくて、繋がって初めてシステムになるわけですから、その「繋がる」部分を担わなければならない。極論な言い方をすれば、それができなかったらIT部門には何にも役割がないということですよね。


それは特別そのころのカシオさんだけが変だったわけではなくて、世の中にはけっこうそれと似たような状況があふれているようです。そうなってしまうのはなぜだと思われますか。いろいろな原因があるとは思うのですけど、矢澤さんのような経験をした方がおられれば、すぐ「これはおかしい」と感じるはずなのに。それがなぜそういうふうになるのでしょうか。

矢澤
コンピュータ技術の進化ということを考えてみると、一時期確かにユーザーが言うとおりにシステム化をしていけばいいという側面もあったかと思うのです。特に多くのシステムの構築をしていた80年代というのは、工数が掛かるのはプログラムのところじゃないですか。そうすると、どうしてもシステム側のマネジメントの方はプログラム構築が期間どおりに立ち上がることに注力せざるを得ない。意識がそこに向いていたのだと思うのですね。まあ、それはやむを得ない面があったと。


産めよ増やせよ・システム版というわけですね(笑)。

矢澤
そうですね(笑)。


構築したシステムがどのような効果を発揮するのかという問題ではなくて、とにかく作れと。

矢澤
ええ。ところがもう時代が変わってきて、今言われたようにやはり効果が問題になりますし、そのシステム自体を速いスピードで変化させていかなければならない。そうなるとエンジニアが自分で考えて、それに対して行動していくというパターンを作っていかないと、もうどうにもならない時代になってきていますよね。やはり時代背景がかなり変わってきているのじゃないかと思います。でも、時代の変化についていけていなくて、昔のまま、ウォーターフォール型でプログラムを作っている延長線上で発想している方々が多かったのじゃないかな、という感じがするんですけど。


自分たちで考えて、良くしていくことが大切です。私はシステム屋はシステム屋で必要だと思うのですね。しかし、システムを作ることでビジネスにどう役に立つのかという発想や、ビジネス側から見てどう活用するのかという発想があって初めて、システム屋たちが知恵を絞って、その結果よいシステムというものが成り立つのだと思います。

なぜIT部門に頭の固い人が多いのか

矢澤篤志さん


ずっとプログラムをやっているとそういう頭になってしまうということですけれど、それはいわば病のようなもので、そこに何か、そんなふうになってしまうもっと強い要因があるのじゃないかとも思えるんですよ。組織の体質的なものですとか。

矢澤
そうですね。もう一つ言えるのは、うちなんかもそれまでは販売部門の下の情報システム、あるいは生産部門の下の情報システムということで、従属的な関係が出来上がっていたんじゃないかと思うのです。体制としても販売は販売、生産は生産、あるいは人事経理は人事経理、その中の情報システム部門ということになっていました。先ほど「システムとは、繋がっていなければいけない」という話をしたのですが、そういう縦割りの組織の中では全体を見渡したり、あるいはユーザーの部門と部門、業務と業務の間を越えてシステムを構築するという発想がなかなか生まれにくかったんじゃないかと思うんですね。


やはりそこに壁が築かれていたのですね。今日もある人と話をしていていたのですが、養老先生が『バカの壁』という本を書きましたよね。それと同じようにわれわれの目の前には「組織の壁」とか「会社の壁」「予算の壁」「技術の壁」などがある。その中で「自分の壁」が一番厚いんだよと。

矢澤
結局は「自分の壁」ですよね。


みなさん「自分の壁」を一生懸命、内側にどんどん分厚く塗り固めていっている。それで「破れない、破れない」と言っているわけです。一つには制度としてのジョブ・ローテーションがあって、外から自分のやっていた仕事を眺めるというのも重要だけど、長年IT部門にいてもちゃんと外からの視点を持って仕事をしている人もいます。

矢澤
そうですね。確かにいます。


でも、それが本当にわずかしかいないというのが不思議ですよ。もともとIT部門にいた人が、システムとはどうあるべきかを理解する素養がなかったかとか、優秀ではなかったのかというと、そんなことはない。入社した時はみんな一緒だと思います。むしろシステムに興味があった人が入ったわけですよね。おそらく若いうちに、仕事をどう理解するかという心の部分と言うか、自分の中で「これが自分の仕事だ」と決める部分でちょっと間違ったのじゃないかと思うのです。それをずっと引きずっている。

矢澤
まあ、もう一つ言うと、80年代に本当にシステムを一から作ってきた人たちはそうではなかったと思うのですが、結局、90年代になると情報システム部門が保守する役割だけになってきましたよね。


そうですね、大きいプロジェクトはあまりなかったですから。

矢澤
そうすると単にユーザーから言われてメンテナスをするという仕事がルーティンになってきて、それがだんだんボリュームとして大きくなってくると、どうしても発想自体が既存のものからの発想となってしまう。一から発想して作るということができなくなってきている。それが、各社のIT部門の大きな悩みなんじゃないかなと思うのです。

進まないプロジェクトの中に改革のヒントが

矢澤篤志さん


それで、矢澤さんがIT部門の責任者になってからは、人の面の改革というのは、どういうことをおやりになったのですか。人を変えるのが一番難しいですよね。

矢澤
一つは、先ほども林さんがおっしゃっていたように、当社の情報システム部門の中にも優秀な人達はいるわけですよ。ERPのプロジェクトの時が象徴的なのですが、97年から始めて、98年は本当にダッチロールをしていてぜんぜん前に進まない。国内3社、海外5社、それから、その頃は事業部門がみんなバラバラにシステムを作っていましたので5事業部くらいのシステムを一気に2000年までに変えなきゃいけないのですが、98年が終わった時、ほとんど進んでいないという状況でした。情報システム部門にERPを自分でやろうという発想がなくて、外のコンサルに任せて、自分は間に立って、本当にIT側のこと、たとえばインターフェースを作るといったことだけやろうとして、結局前に進まないということがあったんです。


なるほど。

矢澤
でも、プロジェクトの中にはきちんと進んでいるものもあったんです。何が違ったかと言うと、やはりやり方だったのですよ。そのやり方というのは非常にシンプルなことですが、まず業務の全体像を把握して、業務機能と情報のつながり、私達はプロセスフローと呼んでますが、これを描いて、それから他の業務との関連というものを整理して、そこからまず自分たちでプロトタイプと言うかシンプルなシステムの姿を作る。そこから初めて業務と対峙して、プロトタイプに肉付けをしていくというやり方ですね。ERPは当然その機能は限られていますけども、不足しているのは特にインプット、アウトプットの機能ですから、IT主導で進めていたグループではERPで不足する機能はは自分たちの工夫の中でどうにか別の手段を用いてユーザーの課題を最小限にしていったわけですよね。結局、それをやっているところとやっていないところでは、大きく差が出てきていたのです。


プロジェクトが進むのと、進まないのでは大きな違いですね。
私は以前「達人のつぶやき」というシリーズの中で書いたですが、問題意識がどこから現れるかというと、まず関心があるかどうかです。関心がないものに対しては問題意識は生まれない。それとその問題は自分のものだという意識があるかどうか。それは自分がこれをやり遂げないといけないという当事者意識です。発注側であればIT部門の方は一番真ん中に入るはずです。でも実際には入っていない人もいますし、入っている人もいますよね。それはまさにその差ですよ。

矢澤
そうですよね。


当事者意識がある人は逃げられない。そもそも逃げる気がないのだから。けれど逃げないがゆえにその人は成功します。ゴルフと一緒じゃないですか。技術的な問題以前にスタンスが重要です。アドレスが間違っていればいくら振ってもボールの真芯に当たらないんです。その部分を変えていかないといけないと思います。

ヒューマンスキルのコンピタンシー・マネジメント強化へ

矢澤篤志さん

矢澤
そのプロジェクトの時点では、私はまだ部門長じゃなかったので「変えましょう」という提言しかできなかったのですけども、形だけ示しても、なかなか実践はできないものでした。そこで、実際にIT部門が先導して成功していたチームの人間をプロジェクト全体の中心に据えて、その人間が影響力を行使しやすいように組織も組み替えました。期間もあと1年半くらいしかなかったですから、間に合わせるには体制とやり方を変えるしかないという事で、一気に変えました。そこから徐々に、IT主導のやり方や意識変革を広げていって。で、ようやく2000年までに一応の形ができたかなあ、というところですね。


そうですか。今それが生きているんですね。

矢澤
ええ、それがコアスキルのベースになっていると思うのです。2001年に私が部門長になってから、そういうIT部門に必要な基本的なスキルを固めていくようにしました。技術的な事ももちろんあるのですが、どちらかと言うとヒューマンスキルですとか、あるいは問題解決能力、つまりビジネスをやるうえで一番必要な基礎能力を重視するようにしました。
それとリーダーシップですね。これも非常に重要で、我々がリーダーシップをとるか、ユーザーがリーダーシップをとるかによってプロジェクトの進捗は大きく変わってくると思いますので、我々がリーダーシップをとれるようにする。そのためには、さっき言いましたプロセスフローやシステムの関連図を自分たちが書けるようにすることが大事です。ユーザーは自分のところしか知らないわけですから、プロセスや関連図をユーザーの目の前で繋げてみせて、初めて「こういうふうにすればどうですか」ということが言えて納得してもらえる。そういったツールを揃えることも並行して進めながら、スキルを身につけさせていくようにしました。


なるほど、おっしゃることはよくわかります。

矢澤
また、もともとカシオ計算機の中では90年くらいからコンピテンシーマネジメントを全社的にやっていたのですけが、2001年からそのコンピテンシー・マネジメントをIT部門ではさらに強化していくことにしました。技術的なところではなくてヒューマンスキルやビジネススキルの部分、特に問題解決能力、あるいは自分であるべき姿を描く力、あるいは全体最適をどう考えるのか、リーダーシップをどうとるか等を評価項目にして、そのコンピテンシーシートを作りました。
カシオの中ではそれまで上司、部下の評価しかしていなかったのですけど、360度評価を行うことにして、自分の行動についてまずメンバーから気づきを与えてもらおうという事から始めました。


コンピテンシーの評価をした時に、それにマッチする人はいいですが、これはちょっと具合が悪いなという人が出てくると思うのですが、そういう場合はどのように指導されたんですか。

矢澤
まずコンピテンシーが評価シートから数字で出てくるわけですね。人材育成も必ず個人の業務目標の中に入れて考えます。自分が弱いところ、例えば問題解決能力では平均よりも低い点数が付いたとすれば、上司と「これから何をやってその問題解決能力を上げていけばよいのか」を相談して、その目標の中に入れ込んで改善をしていくサイクルを作っています。


自分のコンピテンシーが見えるように、自己評価と360度評価の結果を各人にフィードバックしますよね。そのとき、自分では高いと思っていても周りはその人のスキルが低いと思っている人って実はたくさんいますよね(笑)。けっこうショックだと思うんですが、そういう点はどう納得してもらうのですか?

矢澤
そうですね。みんなITは得意ですから、ビジュアルな仕組みを作れと言うとすぐに作っちゃうわけです。これはある意味で「能力だな!」って感じたところですが、他人の評価と自分の自己評価がどれだけ違うかがビジュアルに見えるような仕組みを自分たちで作れと言うと、すぐ作ってしまうんです。その仕組みを見ると一目で、他人との評価のギャップがわかり、「ああ、そうなのか」と気づきが生まれます。そんなものも利用しながら、まず自分の行動に対しての気付きを与えていくところが自己改善の第一歩です。


なるほど。私も80年代に一生懸命に開発をやっていたので、いままでお話いただいたような時代背景とやるべきことについては、感覚としてもよくわかります。
そしてやはり、コンピテンシーというのは重要ですよね。80年代からすでに、そういう言葉は使っていなくても重要なことだった。そしてさらに重要になってきていると思います。

矢澤
ええ、私もそう思います。

(次回に続く)

構成;萩谷美也子

| トラックバック[0件]

トラックバック

このページのトラックバックURL:
http://www.promane.jp/blog_manager/mt-tb.cgi/447

↑ このページの先頭へ