オープンシステムの運用が危ない――。そうした思いから,日経システム構築の6月号で「“強い”運用に変える」という特集記事を企画した。

ジャパンネット銀行(関連記事)をはじめ,稼働中のシステムを見舞うトラブルは後を絶たない。システム停止に至らずとも,“突然,性能が劣化した”といった話は取材先でよく耳にする。一方,コスト削減しか要求されない状況では,運用を支える担当者のモチベーションは下がるばかりだ。

サービス・レベルを維持する実行部隊へ

 結論をいえば,運用部門が「サービス・レベル」を維持する集団に変わらなければ,オープンシステムの運用は支え切れない。サービス・レベルとは“ユーザーが快適にシステムを使えているか”を示す指標。その中身は,可用性と性能の2つがある。
 
 多様な製品,技術を組み合わせたオープンシステムは,ホストに比べ,サービス・レベルの維持が格段に難しい。クラスタリングなどの障害対策を施し,監視を徹底しなければ,可用性や性能の要件が満たせない。

 システムの開発を急いできた企業が,ここにきて“運用”に注力し始めた。いずれも,サービス・レベルの目標を掲げることが特徴だ。カブドットコム証券は2002年11月,インターネット株取引における遅延時間を最悪でも5分と規定。それを維持するために,開発担当者が当番制で監視コンソールに張り付く。

 損害保険ジャパンは,「顧客情報データベース」のサービス・レベルを数値化した上で,独自の運用改善サイクルを確立した。開発部門やベンダーといったチームごとに可用性などの目標を定め,運用部門が中心となって改善作業を継続する。

求められる“強い”運用

 システムの可用性や性能を数値として押さえ,それを武器に開発者や経営にシステムの改善を促す――。これが“強い”運用のイメージである。冒頭の特集では,各企業の取り組みから,変革に向けたシナリオを描いた。

 変革の起点は,もちろん運用担当者である。サービス・レベルの維持をミッションとすることで,担当者のモチベーションも向上できる。障害対策や性能改善といった仕事の成果が数値で把握できるため,“システムを支えている”ことが実感しやすい。稼働実績を基にシステム改善に踏み込めば,社内へのアピールにもなる。

 “システムが落ちないと存在感が乏しい”と揶揄されるように,これまで運用への社内評価は決して高くはなかった。開発者と比べても,その立場は相対的に弱いものだ。

 例えば,運用担当者としては「運用設計は開発の上流工程で実施したい」。ところが現実には,運用設計は後回し,「完成したのでシステムを引き継いで」という開発側の圧力に押し切られるケースは少なくない。そうなると,稼働直前に慌てて運用を決めざるを得ない。その結果,稼働後の運用にしわ寄せがくる。

 ただし,運用が後手に回る原因はその担当者にもある。システムの状況を説明できない,オペレーションが精一杯で改善提案に手が回らない,そんなレベルであれば,だれが上流工程で声をかけるだろう。“だれにでもできる”オペレーションは,自動化を推し進め,場合によってはアウトソーシングしてもかまわない。

“運用”への共通認識が広がる

 サービス・レベルの維持こそが運用の新たなミッションである。もちろん,サービス・レベルを振りかざせ,と言っているわけではない。運用がユーザーの方を向いて仕事をする“本来の姿”に戻るきっかけとしたい。その腕前がサービス・レベルに直結する分,「オープンシステムの本格化は運用をアピールするチャンス」との声は今回の取材でも多く聞かれた。

 運用改革を後押しする動きは社外にもある。その一つとして,5月9日に設立が認可された「itSMF Japan」に注目したい(関連記事)。itSMFは,運用プロセスのベスト・プラクティスを広めるための会員制ユーザー・フォーラム。1991年に英国で設立された。itSMFが推進するのが,「ITIL(IT Infrastructure Library)」と呼ぶ運用のフレームワークである。

 筆者が期待するのは,ITILによって“運用の言葉”が整理されること。開発に比べ,運用は話題を共有しづらい状況にある。「MVCモデル」や「アジャイル開発」など,最近だけを見ても,開発を語るキーワードには事欠かない。それに比べて運用は,“どのように運用しているか”という問いに答えにくい。

 ITILをベースに運用項目や手法について共通認識が広がれば,情報交換がしやすくなる。ちなみに,先の損害保険ジャパンの改善サイクルもITILを取り込んでいる。“システムは運用して初めて稼ぐ”――。もっと運用の話をしよう。

(森山 徹=日経システム構築副編集長)