ページの先頭です。
ヘッダをスキップして本文へ。

TOPコラムITコンサルタント美咲いずみが行く > 第3回 ITをサービスとして捉える~ITサービス、DevOps(1)

第3回 ITをサービスとして捉える~ITサービス、DevOps(1)

開発担当と運用担当の利害が食い違うために協力体制が作れない、IT部門が良かれと思って導入したシステムが利用部門や顧客から不評である、ITが業績に貢献しているのかどうか分からないと経営陣から言われる―これらはよく聞かれる話ではないでしょうか。このような問題を解決した企業が口をそろえて言うのは、「ITをサービスとして捉えよ」ということです。では、「ITをサービスとして捉える」とはどういうことなのでしょうか。

* 本文中の登場人物・企業名はすべて架空のものです


第3回 ITをサービスとして捉える~ITサービス、DevOps(1)


ある企業のシステム部門では

埼玉県春日部市にある従業員約280人のEMS(Electronics Manufacturing Service:電子機器の受託生産)企業、YMC電子工業(仮名)。美咲いずみは、同社のCIO兼システム部長山田昭(仮名)の面接に通り、この9月から同社のITコンサルタントとして定期的に訪問している。週1回のシステム部の会議に参加し、その後で山田とシステム部の課題について確認するという形態だ。
いずみは、面接の時には緊張したものの、師匠の経営コンサルタント、亀田金太郎と一緒にクライアントを訪問していた経験が物を言って、早くもYMC電子工業のシステム部に溶け込んでいた。

システム部員は、パートナー企業の社員も含めて4名。開発、運用、インフラのすべての責任者で山田の信頼も厚い真鍋課長(仮名、男性39歳)、主にシステム企画と外注管理を担当する木村主任(仮名、女性33歳)、社内外の運用窓口である宮下(仮名、男性24歳)、システム開発と運用のアウトソーシング先である大手システムインテグレーター伊達システムズ(仮名)から常駐で来ている高橋(仮名、男性35歳)である。

高橋の役割は、YMC電子工業と伊達システムズの橋渡しだ。例えば、システム障害が発生したときには、原因の1次切り分けをし、YMC電子工業に障害状況を報告するとともに、伊達システムズにも連絡を入れる。また、月々の保守案件に関しては、YMC電子工業と高橋で話し合った上で、高橋が仕様書を作成して伊達システムズに連絡する。伊達システムズが作成したソフトウェアは高橋が検査して木村主任に引き渡す。

少ない人数で役割分担をしているため、メンバーの仲が良く、一人ひとりの責任感が強い。外部の人間である高橋もすでに5年以上常駐していることもあって、ほかのメンバーからの信頼も厚く、本人も外部の人間という意識は希薄なようだ。
ただし、それがマイナスになることもある。仲が良いだけに、お互いに遠慮がない。そのため、トラブルが起きたりするとかえって言い争いになることが少なくない。今回、いずみはそのような言い争いに遭遇した。

大事なのは責任論ではない

「この3カ月間、毎月のバージョンアップのリリース直後のトラブルが増えてるのよね。高橋さん、伊達システムズさんはどう言ってるの?」と木村主任。

「いや、ソフトウェアに起因する障害はむしろ減っていて、YMC側の運用管理の問題だと思うんですよね。まあ、伊達側もそんな言い方はしてないけれど、彼らからの報告書を意訳するとそんな感じです」高橋が答える。

「ちょっと待ってくださいよ。じゃあ、僕の問題だということですか?でも運用は基本的には伊達システムズでやってるわけじゃないですか」自分の責任にされてはたまらないと、宮下が反論する。

「それは、開発と運用の分離ということで、運用チームには必ずYMCを経由して指示を出すことになってるんだよね。だから宮下さんが悪いと言ったつもりはないんだけど、少なくともYMCのシステム部に何かの問題があるということなんじゃないかな」と高橋が再び反論する。

「だったら伊達システムズの運用チームはなんて言ってるの?」と木村主任。

高橋が何か言いかけたが、真鍋課長がそれを制して言った。「今、大事なのは責任論じゃないよ。みんなで知恵を出して問題解決しようじゃないか」

「でも、責任の所在がはっきりしないと、誰が何を調べるかということも曖昧にならないでしょうか?」と木村主任。

「この件については、いったん私が預かるということでいいかな?」それまで静観していた山田が初めて口を開き、「真鍋課長、次の議題に行きましょう」と促した。

議題が変わると、一同は何事もなかったかのように和気あいあいと話し合いを続けた。いずみにはやや不思議な光景にも見えたが、やはり仲がいいのだと思った。

問題の根っこは同じ

「みっともないところをお見せしました。責任論というか建前論というか、どうしてもそういう議論になりがちなんですよ。どうしたら変わるでしょうね?」

部門会議が終わり、メンバーが退出してから山田が切り出した。

いずみが答える。「開発は開発、運用は運用という役割分担ができているように見えますが、率直に言って、協力体制がうまく築けていないように思えます」

「そうだね。たった4人しかいないのに、どうしてこうなるんだろう」

「もしかしたら、利用部門とシステム部門でも同じようなことになっていませんか?」

「そう、利用部門の要望を入れてシステムを導入したのに、こんなの役に立たないと言われることはありますね」

「システムが原因で、お客さまや取引先から文句を言われたことは?」

「それもありますね、データベース内のデータの不備やレスポンスの悪さが原因で。それも悩みの種なんです」

「それらは全部、根っこが同じなのかもしれません。だとすると、全部を同時に解決することも可能ということになります」

「なるほど。そうなってくれるといいんですがね」山田は身を乗り出した。

ある保険会社の取り組み

「ここ数年、DevOpsという言葉が定着してきましたが、お聞きになったこともあるのではないでしょうか?」といずみ。

「うん。開発と運用の一体化とか、強い協力体制というような意味でしょ?」と山田。

「そのとおりです。先日、DevOpsに積極的に取り組んでいる保険会社A社の運用センター長の講演を聴きに行ったんです。テーマはずばりDevOpsでした」

山田は先を促すようにうなずいた。

「A社も、2000年頃は、開発部門と運用部門との連携がうまくいっていなかったんだそうです。本番リリースまでが開発の仕事で、その後が運用の仕事だという暗黙の了解があって、お互い口を出さないという文化だったというんです」

「今のYMCと同じだね。伊達システムズの体制も含めての話だけど」

「はい、似ていると思います。で、その頃は年間に150件を超える重大な障害があったと言ってました」

「利用部門と顧客に迷惑をかけてしまった障害ですね。150件とは大変だ」

「それが、約3年の取り組みでまず5件にまで減って、現在では1件か2件だそうです」

「まるでマジックみたいだね。どんなことをしたんだろう」

「はい。さまざまな取り組みをしているんですが、講演者によれば、DevOpsへとつながる意識改革がいちばん大きかったとのことです」

「確かに、こういうことは考え方を変えないとうまくいかないね。で、具体的にはどんな意識改革なの?」

「それが、“ITをサービスとして捉える”ということだったんです」

従来の意識や考え方に問題があった

「その言葉は聴いたことがありますね。でも、そもそも、われわれが提供するシステムには利用者がいて、その人たちの満足度を高めることが重要なのは当然ですよね。“ITをサービスとして捉える”というのはそういうこととは違うんですか?」山田は疑問を口にした。

いずみが答える。「おっしゃるとおり、利用者満足や顧客満足につながる活動をしようというのが、“ITをサービスとして捉える”ことの本質だと私も思います。ただ、それを実践しようとするときのシステム部門の意識や考え方に問題はなかったか、ということを講演者は主張したかったようです」

「どういうこと?」

「例えばコールセンターのことを考えてみましょう。システム部門が重視する満足度指標は何でしょうか」

「やはり応答時間でしょう。問い合わせた人にとって短ければ短いほどいい。そこで、例えばオペレーターが過去の事例を検索した結果を3秒以内に表示する、といったようにシステムを作り込むことになりますね」

「その場合に、1画面当たりのレスポンスタイムを3秒以内にするために、やたらと画面分割をしたらどうでしょうか」

「そうだなあ、何度も画面も行き来することになってオペレーターには不便かもしれないね。それが顧客への対応を悪くすることにつながる」

同じ相手に向くことで対立関係を解消

山田は少しの間、考えていた。システム部門の意識や考え方が問題だというのはいずみの言うとおりだと思える。しかし、何がどう間違っているのかうまく言葉にできない。そこでそれについて率直に聞いてみた。

いずみはの答えはこうだ。「それが、ITとサービスが分離した状態なんです。システムの提供側としては、利用者の満足度を高めようと思って頑張る。しかし、そのための達成目標がシステムとしての目標になっているんですね」

山田はまたしばらく考えていた。いずみは山田が口を開くのを待った。

「ITとサービスが分離した状態か…。なるほど、問題の根っこが同じという意味が分かってきたよ。開発と運用が対決姿勢になってしまうのも同じことなんだね。システムリリース以前は開発、以後は運用と線引きをすることによって、開発は開発、運用は運用のそれぞれの目標を設定して、それぞれがそれに安住してしまうということなんだね」

「はい、A社でもそうだったんですね。お互い口出しをしない」

「どうしたらいいと思いますか?」

「見つめるものを変えればいいんだと思います。それぞれが、自分たちの都合で作った目標だけを見ている限りは、それを達成することが目的になりますから、どうしても対立的になってしまいます。御社のシステム部の人間関係はとてもいいのに、開発と運用というような話になると反発し合ってしまうのもそのためだと思います」

「どちらも利用者の目標を自分たちの目標にすればいいということだね?」

「そうです。同じものを見るようにすれば協力関係が生まれます。それこそが、講演者の言う意識改革ではないでしょうか」

「なるほど。ならば、システム部門と利用部門の間の溝を埋めようと思ったら、経営指標や顧客満足度など同じものを目標にすればいいということだね」

「おっしゃるとおりです」

「一見当たり前のようだけど、とても難しいことでもあるよね。いい方法はあるんだろうか」

「はい、いくつかあると思います」

「それではちょっと休憩して、その後で続きを聞かせてもらうことにしましょう」山田は5分後に再開しようと言い残して、コーヒーサーバーが置いてある廊下に向かった。

まとめ

  • 開発と運用の対立、IT部門と利用部門の対立、顧客満足度の低さなどが課題であるときは、ITをサービスとして捉えられていない可能性がある
  • ITをサービスとして捉えられているときは、ITを導入する際の目標と、利用者や顧客へのサービス目標とが一致している
  • ITをサービスとして捉えることで、開発と運用、IT部門と利用部門が同じ方向を向くことができるようになり、対立関係が協力関係に変わる

いずみの目

ITをサービスとして捉え、その品質を向上させていく活動を「ITサービスマネジメント」と言います。ITサービスマネジメントのベストプラクティスを集めたITIL(Information Technology Infrastructure Library)という書籍群は、具体的な取り組みのために非常に参考になります。

紹介記事:【大手金融機関で実績】開発・運用部門に対して、継続的改善活動を通して運用統括業務を代行する「IT運用統括サポートサービス」

[ITブレークスルー代表 森川 滋之 記]

* この物語は、筆者の見解をもとに構成されています。
  日立システムズの公式見解を示すものではありません。
* 資料の、無断引用・転載・改ざん・配布および、そのままでの教材としての利用は、すべて禁止します。

▲画面トップへ戻る
【前回】第2回 そのシステム投資額は妥当か?(2)~システム価値の"見える化"
【次回】第4回 ITをサービスとして捉える~ITサービス、DevOps(2)
ITコンサルタント美咲いずみが行く

関連サービス

ITサービスマネジメントに関する当サイトのサービスはこちら

資料請求・お問い合わせはこちらから

お問い合わせ

利用開始までの流れ

詳しくはこちらから。

利用開始までの流れはこちら