システム関連のプロジェクトにおいて、PMOの活動範囲は必ずしもシステムを稼働させるまでのフェーズだけではありません。とかく後手に回ったり、属人的になったりしやすい保守・運用フェーズにおいても、PMOのマネジメント能力を生かせる場があります。
一般的にシステムの保守・運用フェーズでは、障害や問い合わせの発生件数を最小化し、リソースとコストを最小化することが求められます。あるいは、保守・運用の現場が既存システムの改善や新システムの企画立案をすることで、プロフィットセンターにしようとする動きもあります。
しかし、現実はどうでしょうか。多くの保守・運用の現場では、十分にマネジメントできているとは言い難い状況です。キーワードを挙げるとすれば、「後手の対応」「情報共有不足」「属人的」といったところでしょうか。今回はこの課題を取り上げ、適切にマネジメントする仕組み作りを考えます。
保守・運用フェーズにおいて、システム利用者からの問い合わせ発生件数や解消件数を把握することは簡単ですが、それが健全なマネジメントの本質でないことはご存じの通りです。重要なのは、根本原因を追究し、適切な対策を取るための活動を続けることです。
ただし、問い合わせ発生件数を抑えようとする場合、「適切な対策をいつ打つか」という点で、マネジメントのレベルが違ってきます。例えば、昨日と今日でユーザービリティーが少し違うだけでも、利用者から何件もの問い合わせが発生するかもしれません。また、決算期や繁忙期には、利用者数が通常より大幅に増えたり、日頃は行われない例外的なオペレーションが増えたりして、一時的に問い合わせが増加するものです。このような傾向はある程度予測できますが、実際には問い合わせが増加することを黙認し、問い合わせが来てから対応するケースが多いのではないでしょうか。ユーザーの満足度や問い合わせ対応にかける時間コストを判断基準にしないまま、対応を続けることは適切なマネジメントとは言えません。
本来なら、問い合わせを発生させないための手を事前に打つべきです。問い合わせの発生件数を年間を通して平準化しなければ、発生件数の多い期間に対応できるだけのリソースを準備しなければなりません。問い合わせ件数の変動をできる限り減らし、最小限のリソースに抑える努力が必要です。
適切にマネジメントするには、システムのオーナー（発注者側）が主導的な立場を取り、例えば「問い合わせ発生件数は○○件以下」といった年間目標を立てて、目標達成に向けたアクションを継続的に実施する必要があります。
PMOの役割は、目標の設定や情報の収集、原因追究、事後・事前対策の検討、効果測定をはじめ、これらを実施するための計画立案に主体的に参画し、関係者に働きかけていくことです。いずれもPMOが得意とする任務です。
稼働から半年以上経つのに、一向に障害の発生件数が減らない、時には障害が増え続けるケースに出合うことがあります。保守・運用フェーズになると、1件の問題解消にかかるコストが設計/開発フェーズに比べて増大します。そのコストを削減するための仕組み作りが必要です。これも問い合わせ件数をマネジメントする場合と同じように、根本原因を追究し、その原因に対して直接的な対応を取ることで再発を防ぐ活動を継続することが基本です。
ただし、障害への対応は問い合わせのケースとかなり異なる部分もあります。事前に手を打てるタイプの障害は比較的少ないので、障害発生後の復旧の迅速さや再発防止策のクオリティーを高める仕組みの巧みさでマネジメントのレベルが決まります。障害の影響度や同一原因による別の障害の可能性、類似した別の原因による障害の可能性に目を配りつつ、障害対応時にはプログラムのバージョン管理や改修によって他の機能に影響が出るデグレーションを防ぐための対策も考慮しなければいけません。
PMOは、1つの障害を取り巻く広範囲の情報を見える化してメンバー間で共有し、適切な対策を検討できる仕組みを導入すべきです。つまり、障害の発生から解消までを追跡できるような運営を目指すのが望ましい形です。障害管理や構成管理のツールも多く出ているので、運用現場のニーズに合ったものを導入してもよいでしょう。
ツールがなかったとしても、障害対応の現場担当者や責任者に的確な情報を報告させ、メンバー間で共有する習慣を身に付けさせることが重要です。テストフェーズでも同様の考えが求められますが、テストフェーズの障害と稼働後の障害では、その重みが異なります。保守・運用フェーズでは、1つの障害対応をより深いレベルでマネジメントする必要があります。よく起こる問題として、設計書の不備やシステムの品質が悪く、対応者や責任者が影響範囲を正確に割り出せないことがあります。この場合、設計書のレベルから見直すなど、時間をかけて粘り強く対応していくことが求められるでしょう。
保守・運用フェーズにおけるマネジメントで悩ましいのは、メンバーが固定化されやすく、システム仕様や障害対応に関するナレッジが属人化しやすいことです。そのため、いざという時に、他の人に引き継げなくなってしまうケースが多々あります。できればプロジェクトの初期段階からドキュメントを体系化し、管理資料、設計資料、運用資料、申請資料、補足資料（ナレッジ資料）などを、日頃から整理する必要があります。
メンバーには常に引き継ぎを念頭に置いてドキュメントを整えてもらい、ブラックボックス化することを防ぎます。こうすることで、引き継ぎにかかるコストの削減だけでなく、問い合わせや障害への対応時に過去のナレッジを利用でき、対応が完了するまでにかかるコストやリードタイムを削減できます。