保守運用計画は要件定義の段階で決めておく

運用・保守の話は、システムが完成してから考え始めるものだと思われがちです。しかし実際には、要件定義の段階で決めておかないと選べなくなる項目が多くあります。

なぜ「後から考える」がうまくいかないのか

システムの設計は、リリース後にどう運用するかによって大きく変わります。たとえば、障害発生時にどのデータをどこまで遡って復旧できればよいか（RPO）を決めていないと、バックアップの取得頻度や保存先を後から変更するのは大掛かりな改修になります。ログをどこまで残すかも同様で、「あとから必要になったので追加してください」と言われても、過去のデータまでは遡って記録できません。

運用の要件は、機能要件と違って「動いてから気づく」ことが多いという特徴があります。だからこそ、要件定義の段階で意識的に項目を洗い出しておく必要があります。

要件定義で決めておきたい運用項目

障害時の許容範囲 ：システムが止まった場合、何時間以内に復旧すべきか。何分前のデータまで失われても業務が継続できるか。これによってバックアップ方式やインフラ構成が変わります。

保守の対応時間 ：平日日中のみの対応で十分か、休日や夜間の障害にも対応が必要か。24時間対応が必要な業務であれば、保守契約の条件だけでなくシステム構成（冗長化など）にも影響します。

利用状況の可視化 ：誰がいつ何を使っているかを、運用担当者が把握できる仕組みが必要か。アクセス数や処理件数のログは、あとから欲しくなっても仕込んでいなければ取得できません。

業務変更への追従方針 ：制度改正や業務フローの変更が頻繁に起こる業務であれば、改修のしやすさ（設定変更で対応できる範囲）を設計段階で確保しておく必要があります。

誰が主導して決めるか

これらの項目は、ベンダー任せにすると「一般的な水準」で決められてしまいがちです。しかし、業務への影響度は発注側にしか判断できません。売上に直結する受注データと、社内の備品管理データでは、求められる復旧の速さもデータの保存期間も違います。

要件定義の場では機能の話に注目が集まりやすいですが、運用担当者や情シス部門も同じテーブルで、稼働後の話を早い段階からしておくことが望ましいです。

決めきれない場合は「最低限」から

すべての運用要件を最初から精緻に決める必要はありません。判断材料が不足している場合は、まず最低限の水準（一般的なバックアップ頻度、標準的な対応時間帯など）で設計しておき、運用を通じて必要な水準を見直していくという進め方も現実的です。重要なのは、「決めていない」状態のままシステムを作り始めないことです。