運用・保守範囲の決め方ガイド

システムはリリースした日から実際の業務を担います。ところが、運用段階の範囲は構築の範囲より後回しにされ、問題が起きてから話し合われることがあります。どの依頼を誰がいつまでに処理するかをリリース前に決めておけば、運用中の判断が速くなり、互いの期待もそろえられます。

01. 保守と機能改善を分けて考えます

障害対応、エラーの修正、定期点検のように今の機能を守る作業と、新機能の追加や画面のリニューアルのようにサービスを変える作業とでは、性格が異なります。両者をひとつの範囲に混ぜると、優先順位やスケジュール、費用を判断しにくくなります。

構築直後に無償修正期間がある場合は、その範囲と終了時期もあわせて確認します。無償修正期間のあとに続く運用の方法をあらかじめ決めておけば、運用の空白を減らせます。

整理する項目

電話、メッセージアプリ、メールにばらばらに届く依頼は、漏れが生じやすく、処理の状況も把握しにくくなります。依頼を受ける窓口と書式を決め、受付から完了までの状況を、依頼した側と対応する側が一緒に確認できるようにします。

依頼ごとに、影響範囲と緊急度を基準に優先順位を決めます。社内の承認が必要な変更であれば、誰が承認し、いつ反映するのかも手順に含めます。

サービス全体が止まった場合と、一部の画面の表示エラーとでは、同じ速さで対応するわけにはいきません。障害をレベルに分け、レベルごとに初動対応と復旧の目標時間、報告の方法を決めます。

業務時間外に障害が起きたときの連絡経路と担当者を決めておきます。連携している外部システムやサーバーの運用会社など、一緒に対応すべき相手の連絡先も一覧に加えます。

整理する項目

サーバーのリソース、ログ、バックアップの状態、証明書やアカウントの有効期限のように、決まった周期で確認する項目を一覧にします。点検結果を記録しておけば、同じ問題が繰り返されているかを判断する根拠になります。

セキュリティ更新や運用環境のバージョン変更はサービスに影響することがあるため、適用前に確認の手順が必要です。本番反映の時間帯と元に戻す方法をあらかじめ決め、変更内容は履歴として残します。

運用担当者は替わることがあります。システム構成、連携情報、本番反映の方法、繰り返し起きた問題とその解決記録を文書にまとめておけば、新しい担当者も同じ基準で運用を引き継げます。

運用中に蓄積された依頼と障害の記録は、次の改善項目を決める材料になります。記録を定期的に一緒に振り返り、繰り返し生じる不便は機能改善の範囲に移して計画します。

以下の内容を整理しておくと、初期の打ち合わせで範囲をより早くすり合わせられます。すべてそろっていなくても、現在の状況からご相談いただけます。

KPSプロジェクトガイド · 具体的な技術構成と適用条件は、要件によって異なります。