人気ブログランキング | 話題のタグを見る

ユーザ側の『ITイノベーター』こそ、急いで育成するべきだ

昨年のことだが、あるIT系コンサル兼調査会社の主催するカンファレンスに出席した。参加者は大手企業や官庁などのITリーダーばかり40〜50人ほど。「ITリーダー」というのはやや微妙な表現だ。主催者側は本当は「CIO」の参加を期待したのだろうが、実際の参加者の大多数は、情報システム部長さん達だったので、こういう言葉を使ったらしい。わたしはCIOでも情報システム部長でもないが、まあ現在は社内の中期的な情報戦略をつかさどる立場なので、この場に混ぜていただいた。

わたしが参加したセッションは二つ。「グローバル企業のITガバナンス」と、「IT人材の育成」をテーマにしたものだった。円卓を10数名で囲んでディスカッションする形式で、コンサルタントが議論をファシリテートする。なかなか興味深い試みだったと思う。同席したのは、自動車会社が3社、大手通信業者、大手製造業、外資系メーカー、エネルギー企業、航空会社などなど。わたしの勤務先など、この中ではかなり小ぶりな方である。なお、呼ばれたのはユーザ側企業ばかりで、いわゆるIT専門のベンダー企業はいない。

グローバル化した日本企業が、海外子会社を含めたITガバナンスと統制をどう行うか、というテーマも意外な苦労話が多くて面白かったが割愛する。今回は、ユーザ企業のIT部門長さん達が、部門内の人材育成にどう取り組んでいるか、という話の方を紹介したい。

ま、紹介したいと書いたが、じつは「IT人材の育成に、これといった決め手はないですね」というのが参加者の共通した感想なので、紹介すべき妙法はとくにないのである(^^;)。みな似たような苦心を重ねているんだな、と互いに確認し合えただけだ。どういう苦心かというと、『人材のミスマッチ』である。

なにせユーザ企業なので、IT部門に所属するITエンジニアといっても、元からそれを志望して会社に入る例は少ない。ただ配属された以上は、それなりに能力とキャリアアップが求められるし、また自らも志向するのがサラリーマンというものだ。そこで、エンジニアとしては専門技術を求めて、ITのスペシャリティを深めよう、それで評価されよう、としていく。それはITインフラ系であったり通信系だったり、データベースやWeb技術、パッケージの知識だったりする。

しかし、ユーザ系企業が情報システム部門に本当に求めているのは、もっと別の能力なのだ。それはエンドユーザー業務を理解し、IT技術をテコにして、それを改革していく提案能力である。開発フレームワークだのクラウド並列処理だのは、専門のITベンダーや情報子会社のプロに任せておけばよい。それよりも、最新の技術を応用すれば、ライン業務をどう変えることができるかの知恵を、会社の側は期待しているのである。ITスペシャリストとして生きたい部員の側と、業務改革のリーダーを期待する経営側の期待がミスマッチを起こしている。それが今の問題なのだった。

(もっとも、上記の話はシステムの開発や修正改善を主に外部委託する企業の話で、内製志向の強い会社には必ずしも当てはまらない。ただその会合にきていた20社弱の内、ネット専業の企業を除くと、極力内製する方針の会社は1社のみだった)

また、多くの企業の悩みは、そうした情報システム部員が、「ユーザから要求されたものを作ります」という受け身の姿勢に留まっていて、業務側への提案や踏み込み姿勢が足りない、という点であった。ここは個人の資質にもよるとは思うのだが、とにかく消極的である、提案能力が足りない、というのが不満点らしかった。

では、かくいう部門長さん達ご自身はどうなのだろうか。みな、一応の業績を上げてきたからこそ、大企業の部長までなられた訳だろう。それなりに業務側への踏み込みも、提案能力もおありに違いない。そう思って話を聞いているうちに、分かったことが一つあった。部長さん達の中には、ずっとIT畑一筋の人もいれば、途中からIT部門に配属になった人もいた。ただ多く共通している点は、何か大規模なシステムの改革や、あるいは企業自体の合併などもっと大きな改革に立ち会って、そこで頑張って力を発揮したことだった。

かりに情報システム部長職というのが、ユーザ企業におけるITエンジニアの到達点だとしよう。この点にたどりつける人は、たまたま大規模システムの作り直しや、業務改革の波にぶつかった人だ。その中で業務の知識も得たし、開発プロジェクト・マネジメントの全体像も実感をもって身につけることができた。ユーザと交渉し押し切ったこともあろう。だが、そうした大きな変革は、毎年ある訳じゃない。ふつうは、よくて5〜7年に一度という程度ではないだろうか。 10年に一度かもしれない。では、そういう「大波」に立ち会えなかった技術者達はどうしたらいいのか?

これが米国のように、IT技術者の流動性の高い社会ならば話は別だ。米国は日本よりもずっと内製志向が高いが、そのかわりIT分野はエンジニアの転職も多い。昨年わたしはボストンでPMとアナリストのカンファレンスに出席したが、そこで話した感じでは、3,4回の転職歴の持ち主はザラだ。大きなプロジェクトがあると会社は人を集める。それが終わると、また機会を求めて別の職場に移っていく。こうして、しょっちゅう業務システムをつくる技術と経験を得る、という感じだ。だが、日本でITエンジニアだけ急に転職市場が増えるとは、考えにくい。

議論を聞いているうちに、わたしは、ユーザ企業の側がなんだか無い物ねだりをしているような気がしてきた。ユーザ企業はIT技術を活用して、社内業務を改善したり、あたらしい市場へのリーチを広げたりしたい。それはいいのだが、じゃあ業務を改善する主役となるのは、情報システム部門のITエンジニアであるのか、それとも業務部門側のユーザであるべきなのか? ユーザ側で業務に詳しい人のことを、SME (Subject Matter Expert)とIT分野では呼んだりする。つまり業務エキスパートである。業務をイノベーションし、新しい業務を設計するのは、ユーザ側の業務エキスパートなのか、ITエンジニアなのか? 本当はユーザ側がイノベーションをリードし、IT側がサポートする、というのが正しい姿ではないだろうか?

これは、逆の面から考えてみると分かりやすい。つまり、改革後の新しい業務システムができあがったとき、そのシステムのオーナーシップは誰が持つべきか、という視点である。それはユーザ側であるべきだと、わたしは思う。情シス側がオーナーシップを持つのはおかしい。新しい家を建てたら、所有者は住民である。まさか建築家がオーナーにはならない。その新しい家が、住む上でまだ不都合だったら、補修や改良工事もする必要がある。その判断は、オーナーである住人がするべきだ。工事にかかるお金と、その改良で得られる便益を比べて、判断するのだ。これを工務店の側がやったらおかしい。

である以上、わたしは情報システム部門のエンジニアが、IT技術のプロとして控えめであることは、けっしておかしな姿だとは思わない。建築家だって弁護士だって医師だって、優秀な人はむしろ謙虚で控えめではないか。ただしプロとして主張すべきことは、断固として主張する。筋がおかしいことは指摘する。でも、「あんたは住み方をこう変えるべきだ」なんて押しつけがましいことは言わない。

業務を変える視点を持つべきなのは、むしろ業務ユーザ側の人間なのである。彼らが、このご時世、最新のIT技術を使えばもっと効率の良い、あるいはイノベーティブな業務の仕方に変えられるはずだ、と発想し、リードしていくのが、本来の正常な姿ではないか。違うだろうか?

今のIT技術者への期待論を見ていると、まるで建築士に、「何でも良いからカッコいい家を作ってよ」とそっくりかえって言い放つ住人の姿のようだ。自分がどんな暮らしをしたいのかも言えないくせに、提案だけを求める。そして、出てきた図面を見ると、「こんな値段じゃ高すぎるよ!」と、必ず文句をつける。そんな施主ばかりだから、日本には良い建築が増えないのだ。いや、話題がそれた。

こうした視点から見ると、わたし達の社会では、むしろユーザ側におけるITの教育が不足しているように思われる。まあ、ユーザ全員がITに詳しくなる必要はない。ただ、10人に一人で良いから、IT的なセンスのあるユーザがいた方が絶対、組織にとって有用なはずである。

ここでいう「IT的なセンス」とは、別段パソコンに詳しいとか、Excelのマクロが器用にかける、といったことは意味していない。むしろ、システムで得られるデータの分析と問題抽出、解決の仕組みのデザイン、要件の確定、といった能力が肝要なはずである。

こう考えてみた結果、ユーザ側の(仮称)『ITイノベーター』に必要なスキルと能力は、大きく分けて6つのエリアからなるのではないかと、今のわたしは思っている。それは以下のようなものだ。
ユーザ側の『ITイノベーター』こそ、急いで育成するべきだ_e0058447_2159095.jpg

1. 要件定義(業務デザイン)の能力

業務フローを理解・作成し、ありたい姿を構想できる設計能力。これが第一だ。さらにいえば、データ処理機能の理解や、コード(ナンバリング)設計のセンスまでカバーできれば、もっといい。ユーザ側はいろいろな業務要求をもっているものだが、その「要求の品質」を確保する能力が大事である。そのためには、短期・中長期な要求をバランスさせ、部門・全体の両方の視点から、考えなくてはならない。

2. システムのもたらす価値評価の能力

情報システムがもたらす価値を評価できる能力が、ユーザには絶対に必要だ。これは、結局オーナーシップをもつのがユーザ側だからである。その価値が、ウン千万円の開発投資や運用コストに見合うかどうかを判断し、経営層にアピールするのもユーザ側である。ITコストを見積もる作業は、ITエンジニア側の仕事だ。ただITコストの概算感覚とか、開発スケジュールの推定感覚とかがあると、もっと素晴らしい。

3. 開発プロセスにおけるユーザ側リーディング能力

開発プロジェクトは山あり谷ありである。その間、ユーザ側の代表として、他のユーザを引っ張ってもらわなければならない。そのためには、開発プロセスへの基本的な理解や、ユーザ・インタフェースの構想・デザイン案の評価能力が、どうしても必要である。

4. 業務へのシステム展開とチェンジ・マネジメントの能力

まさにこの部分こそ、情シス部門のITエンジニアにはできない仕事である。「チェンジ・マネジメント」自体はかなり広い概念だが、新業務運用のための組織化や、新業務手順のマニュアル作成などは、その仕事の一部になる。むろん、ユーザへの教育トレーニング実施もリードしてもらわなくてはならない。

5. データ分析・活用能力

情報システムには、すぐに膨大なデータが蓄積されていく。このデータは(今時のバズワードであるビッグなんとかを持ち出さないまでも)「宝の山」であるはずだ。そのデータを集計し、傾向分析する能力は、ユーザ側においてとても大切である。手法としてはExcelの散布図だって、十分なケースが多い。だが、「データを読む目」はもってほしい。そして、その中から、さらなる改善課題を抽出したいのである。

6. 共通能力

これはユーザ側だけに限ったことではないが、自社の経営戦略・事業戦略の理解、デザイン思考、問題解決力、そして説得力・交渉力などは、誰にも必要なスキルである。


こうしたことを、従来ITエンジニアばかりに要求し、ユーザ側には「日々の業務多忙に埋没」を許してきたことこそ、多くの組織が今日直面している問題の根底にあるのだ・・といったら大げさに過ぎるだろうか。だが、「ITをテコにした業務の改良・改革」は、ユーザ側のITセンスを持ったイノベーターと、IT部門側でプロの経験と力量をもったパートナーとの、二人三脚の仕事であるべきだと、わたしは信ずるようになった。

だから問題なのは「情シス部門の人材の育成」だけではない。むしろ、「ユーザ部門におけるITイノベーターの育成」こそ急務なのではないか。はやく適性のある者を選んで、スキルや技術を身につけさせていかないと、組織が環境変化についていけなくなってしまう。もっとも育成と言っても、世を見渡した限り、あいにくIT分野では情報技術者向けの育成カリキュラムしか、研修セミナーでも書店でも見当たらない。どこか先進的な大学かどこかが、ユーザ部門のIT能力向上のコースを開発してくれないものかと、切に願っている次第である。なければ、いっそ世に浄財を求めて自分で私塾でもつくろうか(^^)

<関連エントリ>
 →「品質とは(本当は)何だろうか - (2) 応答」 (2012-04-24)
by Tomoichi_Sato | 2016-03-06 22:04 | ビジネス | Comments(0)
<< プロジェクト&プログラム・アナ... 同じモノか、違うモノか? - ... >>