ITコンサルタント美咲いずみが行く

第5回　ITをサービスとして捉える～ITサービス、DevOps（3）

2014年7月18日掲載

「ITはサービス」を旗印にクイック・ウィンで意識改革

埼玉県春日部市にある従業員約280人のEMS（Electronics Manufacturing Service：電子機器の受託生産）企業、YMC電子工業（仮名）。美咲いずみは、同社のITコンサルタントとして定期的に訪問をしている。

YMC電子工業のシステム部門は、CIOの山田とメンバーが4名。ふだんは和気あいあいと仕事を進めているのだが、トラブルが発生するとメンバーがそれぞれ開発と運用の立場を主張して、責任追及をしようという傾向があった。
いい方法はないだろうかと言う山田に、いずみは「ITはサービス」という大義名分を掲げて開発と運用の一体感を生み出し、まずは小さな成功事例を早く作ること（スモール・スタート、クイック・ウィン）で意識改革を進めることが重要だと話す。

山田はいずみの話に納得し、YMC電子工業でも取り組むことにしたが、「ITはサービス」という大義名分を、実質を伴うものにするためにはどうしたらいいのかと質問した。ちょうどお昼になっていたので、その話の続きは会議室でランチを取りながらということになった（前回）。

ITをサービスと捉えるための技法

「失礼します」女性社員が2人、山田といずみのために昼食をトレイに載せて持って来てくれた。ご飯と味噌汁、そしておかずを入れたきれいな小鉢が並んでいる。

「おいしそうですね」いずみは目を丸くして言う。

「社員食堂の定食のおかずを適当に混ぜてもらったんです。役員だからと特別扱いしてくれているわけじゃないですよ」と山田。

「では、食べながらお話ししましょう。で、早速ですが、“ITをサービスとして捉える”ということについて、あらためて具体的に教えてください」山田は早く聞きたくてたまらないという様子だ。

「分かりました」そう言いながら、いずみはカバンの中から1枚のシートを取り出した。

「これは、サービスブループリントと呼ばれるものです。左から右に時系列に業務とシステムの関係を書いていきます」

「ふむ、業務フローと似ているけど、ポイントはどこなのかな？」

「はい。縦に5つの項目が並んでいますが、重要なのは“顧客の行動”と“プロセス・サポート”の2つです。これ以外の項目は、この2つを無理なく結び付けるためのものと言っていいでしょう」

山田がそれを引き取って「この図を見れば、顧客と、プロセスつまり社内システムとの関係がよく分かるということだね」

「そうです。このような図を関係者みんなで作ることが大切です。自分たちで考えることで理解が深まりますし、共有もスムーズです。さらに教育効果もあります」

「そうだね。今度みんなで作ってみることにしよう」

「はい。それも急いで全部作るのではなく、例えば“社内システム勉強会”という名前を付けて、優先度の高いシステムから少しずつ作っていくのがいいと思います」

「なるほど。スモール・スタート、クイック・ウィンだね」

いずみは、にっこり微笑むことで返事の代わりとした。

利用者に分かる言葉で話す癖をつける

「しかし、美咲さんはコンサルタントだから慣れているかもしれないけど、サービスブループリントをいきなり作るのは難しいなあ」

「確かにそうですね。私も最初は苦労しました」

「もっと身近な取り組みはないですかね」

「あります。これからお話ししようと思っていました。サービスブループリントは、“ITをサービスと捉える”ということのイメージを分かっていただこうと思ってお見せしました」

山田は盛んにうなずきながら目で続きを促した。

「損保会社B社の取り組みなんですが、その会社では、家族に自分の仕事を説明するという課題を出すんだそうです。家族が理解してくれるまで説明せよという課題です」

「それはいいね。専門用語を使ったら家族にはほとんど分かってもらえないからね」

「そうなんです。ITを知らない人たちが納得できるように説明しようと思ったら、どうしても利用者側の立場に立って、その人がイメージできるような例え話をすることが必要になりますね。説明していくうちに、自分の仕事と一般のユーザーの関係に自分で気づいていきます」

「誰が考えたか知らないけど、すばらしいアイデアだね。これもやってみよう。ほかにもあるかな？」

「はい。不動産会社にサービスを提供している会社の例ですが、ここでは開発と運用の合同会議では必ず利用者目線の言葉を使うというルールを設けているんだそうです」

「利用者目線の言葉ですか、イメージが湧かないなあ」

「例えばシステム障害があったとき、利用者としては、詳細な原因よりも影響範囲やいつ復旧するかということが気になるわけですよね？」

山田は無言でうなずく。

「でも、開発サイドは、障害原因と復旧方法を専門用語を交えて詳細に説明しがちです。利用者どころか運用サイドにも分からない言葉も出てきます」

「それは、しかたがないかもしれないなあ」

「ですが、利用者が気になることを利用者に分かる言葉で説明させるようにするだけで、意識が利用者に向くようになるというんです。そうすると、まず利用者にできるだけ迷惑をかけないようにするには、という視点で話をするようになります。これが、まさに“ITをサービスと捉える”ための訓練になります」

「同じ方向を向くことで、開発サイドと運用サイドの意思疎通も良くなり、誤解が生じなくなるという効果もありそうだね」

「はい。もともとはそれを考えていたんですが、結果として“ITをサービスとして捉える”いい訓練になっていたんですね」

「皆さん、いろいろと考えているんだなあ」

目標管理制度と結び付ける

山田が急に考え込むように黙ったので、いずみはしばらくの間、食事を取りながら待っていた。

山田はたっぷり1分間考えてから、ようやく口を開いた。

「ふだんの取り組みについては分かりました。ただ、ITをサービスと捉えている人が報われる評価制度も欲しいところだね。そうでなくてもシステム部員の評価は難しくて、どうしても減点主義になりがちです。加点主義にできないか以前から考えていたんだけど、その答えになりそうな気がするんですよ」と山田は考え込んでいたことの内容を説明した。

「実は、先ほど例に挙げたB社では目標管理制度と結び付けているそうですよ」

「どうやっているんだろう」

「目標を立てるときの上司の関与のしかたがポイントです。先ほどのサービスブループリントのようなものを作りながら、部員の業務と利用者への影響を、上司と部員が納得いくまで話し合うんだそうです」

「うちなら、私が全員とそういう話し合いをするということだね？」

「はい。ミドルマネジメント以上になると、利用者とシステムの関連性は理解できているはずです。しかし、現場の部員はあまり意識していない。そのギャップを役職者が埋めていくわけです」

「単純に、『障害数をこれだけ減らせ』などという目標を押し付けるだけではいけないということだね」

「はい。押し付けられた目標では、達成意欲が湧かないし、達成しても達成感がありません。何よりも利用者と自分の関係が分からずじまいになってしまいます」

「そのとおりだね」

「B社では、そうやって上司と部下が一緒になって作った目標をすべて達成した上で、さらにシステム部門や利用者に貢献する取り組みをした人を全員の前でトップが表彰するんだそうです」

「どういう取り組みが表彰されるんだろう」

「例えば、ある業務に関する運用マニュアルがなかったので、それを作って後任者が困らないようにした、というようなものです」

「なるほど。はっきり職務とされていないことに自発的に取り組んだ人を表彰することで、自律的な組織にしていこうということだね」

「はい。B社はシステム部門だけで数百人もいるので、全員を表彰できないという事情もあります。御社の場合は、部門としての目標を達成したら、例えばパーティーを開いて一人ひとりに何らかの賞を出す、というのも良さそうですね」

「それはいい、絶対にやりましょう！」

山田はすっきりとした顔で言った。より強くなったシステム部門をイメージしてわくわくしているようだ。

［ITブレークスルー代表　森川　滋之　記］