保守フェーズにおける作業の概要

伊東 輝

システムはリリースして終わりではなく、リリースした後も、適切な保守作業を行うことで一般ユーザーが求める機能を提供し続ける必要がある。

システムを運用する中で、バグや機器の故障のような要因でシステム障害が発生したり、外部（公的機関や関連システム）から仕様変更を求められたりするため、機能を維持するためにはそれらに対応する必要がある。
また、一般ユーザーの満足を考えるのであれば、機能を維持するだけではなく、より少ないコストで同じ機能を提供したり、機能を強化したりすることも随時行うべきである。

この記事では、保守フェーズに相当する上記の作業について、その勘所を記載する。


(1)障害対応と事後対応

リリース後の仕様変更や機能強化であれば、通常の開発案件と同じような管理を行えば良い。
しかし、システム障害については緊急性が高いため、迅速な対応を行う必要がある。

システムの障害対応の大まかな流れは以下の通りである。

  • システムの障害検知

  • 障害対応の検討と実施

  • 再発防止策策定や金銭的補償といった事後的な対応

詳しく書くと、以下のような対応が必要になる。

【障害の検知】

システム障害を検知するために、入出力不整合や機器停止のような重大な事象が発生した場合にログを出力するようにシステムを作りこむ必要がある。
また、ログ内容を関係者へ自動でメール送信する、監視担当者を常駐させる監視室を作りパトライト鳴動で監視担当者に知らせる、といった、出力されたログを検知し関係者へ知らせる仕組みや体制の構築も必要となる。

リリース直後やイベント中のような障害が発生しやすい時期には、関係者を常駐させての特殊な監視体制も必要になる。

障害を検知する契機として「お客様に指摘される」という契機で見つかるのは最悪である。
事前に障害を発見できなかったためにお客様の心象が悪くなることで、その後の要求（障害対応、再発防止、補償）が厳しいものになるためである。
また、お客様に指摘されているということは、「画面」「帳票」といった形でお客様の目に触れており、そのデータを補正する必要が出てくるために障害対応の作業内容の難易度が上がるため、その意味でも事前の障害検知は重要となる。

なお、システム改修の結果、思いもよらぬ箇所に影響が発生し、重点的に監視していない箇所で障害が発生しお客様に指摘されるというのも良くあることである。
障害を事前検知する上では、影響調査を抜け漏れなく行うことも重要になる。

【障害に対するシステム的な対策】

発生が予期されている障害に対しては、その障害の影響を最小限にするための対応を事前にシステムに組み込むべきである。
影響が最小限になることで、お客様への実質的な影響や報告の必要が無くなり、以降の対応が不要になることも多い。

障害の影響を最小限にする事前的な対策としては、以下のような観点が挙げられる。

  • フェイルセーフ
    システムに障害が発生することを予期して、障害発生時に安全な処理が行われるようにシステムを構築すること。
    例：バッチ処理でデータ不整合が発生した時点で以降の処理を停止し、担当者によるデータ補正を待つ。

  • フェイルオーバー
    システムに障害が発生することを予期して、一方に障害が発生した時に障害が発生していないもう一方へ自動的に切り替わるようにシステムを構築すること。
    例：同じ処理を行うサーバを複数用意し、１つのサーバが停止した際に、停止していない方のサーバで処理を続行するように自動的に切り替えを行う。

  • フールプルーフ
    誤った操作が行われたとしても危険な動作をしないようにシステムを構築すること。
    例：金額が過小・過大な発注が画面から入力された際に、その入力の再確認を促すポップアップを表示させる、若しくは入力エラーとして受け付けないようにする。

【障害の対応方針の検討】

お客様に影響がある障害が発生した場合、どのような障害が発生したのか、その事象内容と原因をお客様に報告する必要がある。
そして、システムの都合の観点と、お客様の業務の継続の観点から、対応方針をすり合わせることになる。
検討している間にも障害は発生し続けているので、検討は迅速に行う必要がある。

システムの都合の観点で言うと、障害対応でプログラム作成が必要なのであればその期間を見る必要があり、プログラムを実行・リリースするタイミングも計る必要がある（サービス停止日にしか実行・リリースできないことも多い）。
それまでの間の暫定対応（運用作業）の計画も立てる必要がある。
暫定対応はお客様の業務を継続する上で必要なレベルを満たす必要があり、恒久対応では元々求められていたレベルに戻す必要がある。
暫定対応中に制約や機能制限が発生するのであれば、そのことについてもお客様の了承を得る必要がある。

なお、この時点で明らかに対応するべきことがあれば、検討中にも対応し続ける必要がある。
手順書に書かれた作業や、その他常識的に行うべき作業（例えばディスク容量オーバーでシステムが落ちたのであれば不要データの削除とシステム再起動）がそれに該当する。

【暫定対応の実施】

検討された方針に従って、暫定対応を行う。
この作業は基本的に手作業での運用になることが多いため、運用担当者を立てて体制を整える必要があり、運用作業でのミスが無いように手順書や簡易ツールを作成する必要もある。
また、暫定対応中に制約や機能制限が発生するのであれば、そのことを説明する文書の作成と周知という事務作業も発生する。

【恒久対応の実施】

プログラムの作成が必要なのであれば、それを作成する担当者を用意して工数を割り振る必要がある。
プログラムの本番環境での実行・リリースに向けた準備（手順書作成、社内手続き等）も必要になり、また実行・リリースに向けた出社体制を整える必要もある。
お客様の立ち合いが必要なのであれば、お客様にも立ち合いを依頼する必要がある。

【再発防止策策定】

恒久対応が完了した後、お客様へ恒久対応完了の報告を行う。

そして、それで終わりではなく、今後同じようなことが起こらないように、障害が発生した要因の報告と、再発防止策の策定を求められることが多い。
社内での再発防止策の検討、お客様を含めた関係者への再発防止策の説明、そして再発防止策の実施が必要となる。

【障害に対する金銭的な補償・影響】

障害が発生した場合、システムの提供者側が金銭的な補償をしなければならない場合もある。
システムのSLA（サービス内容に関する合意文書）に補償に関する項目があるのであれば、それに従って補償をする必要がある。
重大な障害である場合は、裁判で損害賠償請求されることもある。

仮に、直接的な補償がなかったとしても、障害を発生させたことでその後の交渉で提供者側が不利になり、システム継続利用時に値下げ要求をのまざるを得なくなることもある。
特に、ニュースで報道された場合は、直接被害が発生していないお客様との交渉でも不利になりやすくなる。
当然、競合システムに離反されることもあり、この場合も収益の低下に繋がる。

(2)保守性の確保

国際規格ISO/IEC 9126(JIS X 0129)での定義において、「保守性」とは「将来のシステムの改修の容易さを示す度合い」のことを指す。
保守フェーズでシステムを改修する際には、システム構築時点でこの保守性が確保されているかどうかが重要となり、保守性が確保されたシステムであれば低コストで確実な改修が可能となる。

保守性を確保する上で必要な観点として、ISO/IEC 9126(JIS X 0129)においては、以下のように細分化されている。

  • 解析性
    故障原因や改修箇所の確認を容易に行う能力。
    適切なログ出力、ドキュメント整備、コーディング規約、といったものが解析性の向上に繋がる。

  • 変更性
    改修作業を容易に行う能力。
    コーディング規約、バージョン管理システムを用いた適切なソース管理、といったものが変更性の向上に繋がる。

  • 安定性
    改修作業に伴う影響を抑える能力。
    適切な機能分割、フレームワークの適用、といったものが安定性の向上に繋がる。

  • 試験性
    改修作業に伴う試験を容易に行う能力。
    テスト環境の整備、テストコードの整備、といったものが試験性の向上に繋がる。

(3)保守関係者へのナレッジマネジメント

システムをリリースした後、保守作業を行うのはあくまでも人間である。
安定した保守体制を築くためには、保守に携わる関係者に対するナレッジマネジメントが必要となる。

システムの新規開発に携わった関係者がそのまま保守に携わることも多いが、異動・昇進・休職・退職といったイベントで保守作業から抜けることを予期して人員を入れ替えられる体制を整える必要がある。
人員の入れ替えを予期して、システムの保守に必要なノウハウを伝授、及び強化していくためのナレッジマネジメントが必要となる。

具体的な作業としては、引継ぎドキュメントを通した情報伝達、一緒に作業をすることを通したOJT的なノウハウ伝達、が必要となる。
また、保守作業を通して、手順の改良や自動化ツールの作成・導入といった、より低コストで確実な保守作業を可能とする新たなノウハウが生まれると理想的だろう。

ナレッジマネジメントの理論的な説明としては、「SECIモデル」がわかりやすいだろう。
「SECIモデル」とは、体の中に染みついているノウハウである「暗黙知」と、ドキュメント化されたノウハウである「形式知」を行ったり来たりすることで、ノウハウが強化されることを示したモデルである。
「SECI」は「共同化（Socialization）」「表出化（Externalization）」「連結化（Combination）」「内面化（Internalization）」の頭文字を取ったものであり、これらのプロセスを通して「暗黙知」と「形式知」がお互いに連関し強化される、としている。

図1-1：SECIモデル

「共同化」「表出化」「連結化」「内面化」について説明すると以下の通りである。

  • 共同化：暗黙知→暗黙知
    共通の体験や作業を通して暗黙知を伝達するプロセス。OJTや子弟制度といったものがこれに相当し、経験の中で培われた勘や信念を伝えるにはこのプロセスが適している。

  • 表出化：暗黙知→形式知
    暗黙知を他者へ共有するために形式知に変換するプロセス。文章や図表や映像を用いてドキュメント化することで、他者への共有を可能とする。

  • 連結化：形式知→形式知
    形式知を持ち寄ることで、よりレベルの高いノウハウを作り出すプロセス。過去の文献や他者のドキュメントを参照し、そのノウハウを吸収し統合することで、形式知の強化を図る。

  • 内面化：形式知→暗黙知
    形式知を実践することで、ノウハウを体得するプロセス。形式知を実践することで新たな経験、そして新たな勘や信念を得ることができ、これが新たな暗黙知となる。

この記事が気に入ったらサポートをしてみませんか？