■保守段階
□システムのライフサイクルの8割が保守費用。
□メンテ段階では、自分の担当しているシステムの図面を引いてみることでシステムの構成がわかる
□1レコードのみ作成して一度全ての業務の流れを体験してみるべき。その際、DBの項目がどのように変化していくのかも確認する。
□いきなりソースを修正しない。全体のロジックを見渡してから。わからなければロジックを書き出して理解するのが先。
□障害調査は現象の再現性を確認することから始まる。
また、収集した情報をもとに、仮説を立ててその仮説の検証作業を行う。
何が事実で、何が推測であるのかをはっきりと認識する習慣をつける。
□情報システム部門が全ての作業の窓口になる。業務担当者との会話後もその内容について必ず情報システム部門に報告すること。
□サーバのファイルを編集するときは、事前にシステム管理者に連絡する。
□連絡票も精査する。それで顧客目標（顧客自身に決めさせる）を達成できるのか？
□リプレースにあたっては、どの部局で業務端末が何の業務に何台使用されているか把握する必要がある。特にILLと閲覧はカスタマイズプログラムが多いため、それを把握せずに導入すれば、運用に必要な機能が足りないとクレームを受けかねない。
□部局ごとに個別設定を行っているシステムのうち、リプレース前の現段階で標準化できるものはしておくべきである。
□リプレースでは、開発元の支援が必ず得られる点が強みである。開発元に余計な負担をかけないためにも、現在のお客様の運用をよく知る必要がある。
□保守段階における修正モジュールのテストは、修正内容が正しく修正されたかのテスト→最近対応した連絡票のレベルダウンテスト→一通りのテスト。
□修正モジュールの提供はテストの都合上、出来上がったものから順次渡されるよりも、まとめてもらうほうがよい。最初からテストしなければならなくなる。
□新規開発や仕様変更にあたっては、対応するかどうか検討の上、対応する場合はメンバのスキルや作業状況を考慮して対応方針(フォロー体制)を決定することが必要。
□「メンテナンス費用の範囲で対応してほしい」と言われても、実際に見積した結果、メンテナンス費用を超えるようであれば原価率悪化の道を検討する。
□自分の作業が終わっているかどうかは、自分がそのシステムを買いたいと思えるかどうか。半額くらいかなと思えば、それはテストが半分しか済んでいないことを示す。
□作業手順書
普段のメンテナンス作業にあたっては、作業手順書を作成しておけば、あらかじめ作業内容も明確になるし、それを用いて作業を行うことで、後日のトレースもラク。
□作業手順書に記載すべき項目
-いつ（作業日、時刻、作業時間）
-どこで（サーバ名、作業ディレクトリ）
-誰が（作業者。役割分担が必要なとき）
-何を（修正対象となるファイル群）
-何のために（修正の適用の目的。修正の契機となった連絡票番号など）
-どうする（どのように作業を行うかの作業概要、操作手順）
□セキュリティパッチの適用後は、サーバ等の再リンクが必要になる場合がある
最終更新：2011年08月14日 02:01
