品質向上に役立つ情報提供――。これが、運用側が果たすべき三つ目の役割だ。前回までに説明した二つの役割は、プロジェクトに直接関わる役割だった。これに対して三つ目の役割は「情報提供」という形で開発側に貢献するものである。

　では、開発側にどんな情報を提供すればよいのか。アビーム コンサルティングの小野沢氏らは、社内のナレッジマネジメントのグループウエアを通じて、監視やバックアップなど、開発時に考慮すべき運用項目の情報を開発側に提供している。

　さらにこのグループウエアは、開発側が運用側に対して、質問を投稿できる機能を持つ。運用部門の誰かがその質問に回答するものだ。

　ユニークなのは、回答した件数が、人事評価と連動している点である。「運用担当者の貢献度合いが、直接人事評価に反映されることで、積極的な情報提供につながっている」と、小野沢氏は説明する。

　宇部情報システムの登根氏は、アラートからフィルタリングした、予防保守に役立つイベント情報を開発側に伝えている（図1）。

図1●イベント情報を開発部門にいち早く伝える
障害が発生した後にインシデント情報を伝えても遅い一方、監視システムの警告情報では量が多すぎる。宇部情報システムの登根 浩氏らは、アラートからフィルタリングした、予防保守に役立つイベント情報を、大型モニターや週次報告書で開発部門にいち早く伝えている
[画像のクリックで拡大表示]

　障害が発生した後にインシデント情報を伝えるのでは遅いし、監視システムの警告情報（アラート）では量が多すぎる。例えば同社の場合、監視システムが発行するアラート数は1日約3000件に及ぶ。「膨大なアラート情報をそのまま開発側に伝えても、無視されて当然だ」（登根氏）。

　そこで登根氏らは、障害を事前に防ぐために役立つ情報をアラート情報から選び出し、いち早く開発側に伝える。これがイベント情報だ。

　例えば、CPU使用率は80％が警告値（アラート）、90％が障害値（インシデント）だとしよう。このとき仮に85％のアラートをイベント情報としてフィルタリングする、という具合だ。これらの絞り込みで、1日当たり30件程度の情報提供で済む。

　具体的なイベント情報は、CPUやメモリーといったリソースの使用状況、応答時間など多岐にわたる。開発側はこのイベント情報を基に、アプリケーション保守（予防保守）に着手。また「障害が発生した場合の原因調査において、事前に伝えたイベント情報が重要な手掛かりになる」（登根氏）という。

　登根氏は情報提供の仕方にも工夫を凝らす。共有スペースの大型モニターを使って、開発側が自然に目に付くようにしているのだ。「今はイベント情報の選び出しを手作業で行っているが、いずれ自動化したい」と、今後の発展も検討している。フィルタリングのルール作りと自動化への取り組みが、イベント情報を提供する上での課題といえる。