2014年6月16日掲載
開発担当と運用担当の利害が食い違うために協力体制が作れない、IT部門が良かれと思って導入したシステムが利用部門や顧客から不評である、ITが業績に貢献しているのかどうか分からないと経営陣から言われる―これらはよく聞かれる話ではないでしょうか。このような問題を解決した企業が口をそろえて言うのは、「ITをサービスとして捉えよ」ということです。では、「ITをサービスとして捉える」とはどういうことなのでしょうか。
* 本文中の登場人物・企業名はすべて架空のものです。
埼玉県春日部市にある従業員約280人のEMS（Electronics Manufacturing Service：電子機器の受託生産）企業、YMC電子工業（仮名）。美咲いずみは、同社のITコンサルタントとして定期的に訪問している。週1回のシステム部の会議に参加し、その後でCIOの山田とシステム部の課題について確認するという形態だ。
今回の訪問では、システムインテグレーターからの常駐者を含めても4名しかいないシステム部のメンバーが、一時、開発と運用に分かれて対立するという展開になってしまった。こういうことはいつもあるわけではないが、トラブルが発生した場合などには起こりがちだと言う。そんな状況を何とかしたいと思っていた山田に、いずみは「ITをサービスとして捉えるようにしてはどうか」と提案したのだった。
いずみによると、保険会社A社ではかつて重大なシステム障害が年間150件を超えていたが、「ITをサービスとして捉える」という意識改革の結果、年に1件から2件にまで減ったという。その話に興味を持った山田は、少し休憩してから詳しく話を聞くことにした。
山田がコーヒーカップを2つ持って戻ってきた。いずみはその1つを恐縮しながら受け取った。
「“ITをサービスとして捉える”ということだけど、そういう意識改革はなかなか難しいと思うんですよね」山田があらためて切り出した。
「おっしゃるとおりですね。ITをサービスとして捉えろと言われても、抽象的でよく分からないと思います。ですけど、これを最初から言い続けるべきです」といずみ。
「うーん、分かるようで分からないな」
「では、先ほどのA社の例で考えてみましょう」
「頼みます」山田はにっこりして言う。
「ポイントは、小さな成果を早く出すことです。これを“スモール・スタート”“クイック・ウィン”と言います」
「それは聞いたことがある。で、具体的には？」
「A社ではシステムの重大な障害が年に150件以上もあり、それを何とか減らしたいと思っていました。まず、こういう具体的な課題に取り組むことが肝心なんです」
しばらく間を置いて、いずみが質問した。「ところで、重大な障害が年に150件以上あったと言いましたが、原因として多かったのは何だと思いますか？」
「それは、やはりプログラムの欠陥、いわゆるバグが多かったということじゃないんですか？」
「もちろんそれもありましたが、多いのはヒューマンエラーだったんです。」
「というと？」
「A社は、もともと日本でも有数のITユーザー企業です。ですからヒューマンエラーといっても、オペレーションミス（システム運用者の操作ミス）のようなケアレスミスはそれほど多いわけではありませんでした」
「それじゃ、どんなエラーが多かったんだろう」
「設計の不備です。機能の設計という意味ではあまり問題はなかったんですが、運用する人のことをあまり考えていない設計だったというんです」
「どういうこと？」
「例えば、システムコンソールに出るメッセージが多すぎることが挙げられます。エラーメッセージが出力されたとき、すぐに対応すれば重大な障害にはならないのに、あまりにメッセージが多いとエラーメッセージを見落としてしまうおそれがあります。実際に、それで顧客や利用部門に迷惑をかけたことがあったそうです」
「なるほど、うちでもそういうことはあるなあ」
「こういう障害はヒューマンエラーとしてカウントされるんですね」いずみはよどみなく説明を続ける。「そもそもなぜエラーが発生するのかと言うと、例えば、運用マニュアルの説明が分かりづらいために、運用側が必要な手順を見落としてしまい、それでシステムの起動に失敗してしまう」
「うーん、それもある」
「そういうものもヒューマンエラーですね。それらの根本原因は、運用のことを考えていないシステム設計にあるというわけです」
「そこでA社が取り組んだのが、“運用サイド主体”のリリース判定会議（システムをユーザーに開放していいかを検討する会議）だったんです」
「リリース判定会議ならうちでもISO 9001にのっとってやっているけど、出荷条件がそろっているかをチェックするためのもので、“運用サイド主体”というのはイメージが湧かないなあ」
「運用サイドが主体というのは、運用マニュアルに不備はないかとか、コンソールに出力されるメッセージは必要十分な量でかつ分かりやすいかなどをチェックするということです。また、障害が発生したときに、最適・最短の手順で、かつ簡単に復旧ができるかをチェックすることもそうですね」
「なるほど。でも、開発側の抵抗がありそうですね。なにしろ、機能を作り込むだけでもギリギリのスケジュールでやっているわけだから」
「おっしゃるとおりですね。運用設計をきちんとやること自体が手間がかかる上に、リリース判定会議のための資料もそろえないといけない。それも納入期日前のいちばん大変な時に。ですから大義名分が必要になるわけです」
「分かった！その大義名分が“ITをサービスとして捉える”ということなんだね？」
「そのとおりです。それは意識改革ですから、トップダウンで実施することになります。その際には、トップとしてこれだけは譲れないというスローガンが必要になりますよね。『ITは顧客や利用者へのサービスなのだから、運用できないシステムでは駄目に決まっているだろう』と言い切ることで、運用サイド主体のリリース判定会議に開発サイドもしぶしぶ参加せざるを得なくなるんです」
「でも、しぶしぶ参加して結果が出ますかね」
「それはA社の首脳陣には確信があったようで、とにかくやってみろと。ただし、いきなり結果を求めることはしない。まずは小さな成功体験を作ろうと、一部の開発チームからやり始めたそうです」
「“スモール・スタート”というわけですね？」
「はい。そうしたら、そのチームが開発したシステムで、実際に障害件数が減りました。これは開発チームの利益にもなるわけです」
「障害が発生するたびに呼び出されますからね。その回数が減れば開発に集中できる。そうなれば、開発したソフトウェアの品質も上がり、さらに障害が減る。そういう好循環になったということですね？」
「はい。障害件数の減少といった成果は半年ぐらいで出てきたそうです」
「それが“クイック・ウィン”というわけだ」
「そうです。こうなると、開発サイドの意識も変わってきます。A社では、リリース判定会議は規模が大きいか重要度が高いものだけでいいということにしていたんですが、『例外なくやってほしい』と、開発サイドから言ってくるようになったんです」
「別の開発チームも協力的になるということですね？」
「まず、リリース判定会議が全社に定着しました。また、開発の初期から運用サイドに入ってもらってレビューをするほうがいいということにもなりました。運用と開発が共同でシステム設計をするという風土ができ上がったんです。その結果、重大な障害が年に5件程度にまで減りました。ここまで3年ぐらいかかったそうです」
山田は大きく息をした。「いやあ、CIOとしてはたまらない話ですね。しかし、うちでもできるんだろうか」
「このような事例は、会社の規模に関係なくたくさんあります。A社はシステム部員が150人ぐらいですが、システム部員が数名といった会社でも同じような成果を上げているところがあります」
「それじゃ、うちでも運用サイド主体のリリース判定会議に取り組んでみよう。ただ、今の話だと、“ITをサービスとして捉える”というのは大義名分だということですよね。実際にITをサービスとして捉えることは必要なんだろうか」
「はい。まずは成功パターンを作ることが大事なので、最初の段階では大義名分でかまいませんが、ビジネスとして成果を出そうと思うと、やはり本当の意味でITをサービスとして捉えていく必要があると思います」
「なるほどね。ここまでの運用品質の向上という話は、ややITに閉じたものだけども、利用者やお客さんに迷惑をかけることがないように、運用がもっと積極的にビジネスに関わらなくてはいけないということだね」
「そのとおりだと思います。システム部門が積極的にビジネスに関わるという意識を持つことで士気も高まります。意識が外を向くと、開発と運用のそれぞれの立場を主張するということもなくなるはずです」
「その話、もっと詳しく聞きたいんだけど…」
山田は、いずみとの約束の時間が15分ぐらいしか残っていないのを気にしているようだ。
「私のほうは大丈夫ですけど、続きはランチをしながらでいかがでしょうか？」
「もちろん、そうしてもらえると嬉しいなあ。じゃあ、ここに昼食を持ってきてもらいましょう」と言って山田は社員食堂に内線電話をかけた。
まとめ
メールマガジン
最新のイベント情報、商品情報など、お役立ち情報をご紹介するメールマガジンをお送りしております。
日立システムズは、システムのコンサルティングから構築、導入、運用、そして保守まで、ITライフサイクルの全領域をカバーした真のワンストップサービスを提供します。
