運用・保守とは｜ビジネスサイドのための IT 用語集

 運用・保守とは運用・保守は、システムを稼働させてから廃止するまでの期間を対象とする工程です。

開発がシステムを構築する工程であるのに対し、運用・保守は利用開始から廃止までの状態を維持します。
運用はシステムの機能を利用者に提供し続ける活動です。

実稼働している構成を原則として変更せず、稼働状態をあらかじめ定めた品質基準で維持する活動を指します。

監視、バックアップ、プログラムのリリース、利用者からの問合せへの対応が中心です。
保守はシステムが予定された機能と水準を提供するように、システムそのものに働きかける活動です。

機能要件を変更しない修正を保守、機能の改善を目的とする修正を改修として区別します。

保守の作業は不具合の修正、障害の予防、環境の変化への追従、性能と保守性の改善の4種類に分類できます。

バックアップ、リカバリ、システム管理といった運用の作業は、ソフトウェアの保守の標準では対象外とされており、国際標準でも運用する者が行う作業として区別されています。
運用と保守は同じ障害に関係します。

発生時には監視と復旧、一次的な原因の所在の特定が運用の作業、プログラムの修正が保守の作業になります。

原因の調査は双方に共通し、特定が完了するまで責任分界を確定できません。
 稼働後も前提は変わる開発の期間が数か月から1年程度であるのに対し、稼働後の維持は数年から10年程度に及ぶことが多いです。この長さが、稼働後に何を備えるかを決めます。
稼働中もシステムの前提は変化します。前提の変化を前提に、更新の計画と担当を決めておく必要があります。

ソフトウェア製品のサポートが終了し、脆弱性が公表され、証明書とドメインの有効期限が到来し、法制度や取引条件が改正されます。

データ量が増大し、アクセス数も変化します。
運用・保守の目的には、安定した稼働の維持だけでなく、利用者へのサービスの継続的な改善と運用コストの低減も含まれます。
 障害の検知と復旧が速くなる障害の発生を早期に検知し、復旧までの時間を短縮できる
セキュリティの修正を適用し、脆弱性の残存を防止できる
問合せの一次対応を窓口に集約し、業務部門の手戻りを削減できる
法制度と取引条件の変更に、改修の範囲を限定して追従できる
手順と構成を文書として記録し、担当者が交代しても運用を継続できる
 毎年の費用と担当者への依存が残る運用・保守の費用は、開発の費用とは別に毎年発生します。

基幹業務を委託する場合の年間費用は、そのシステムの開発費の1〜2割程度になることが多いです。

利用者と改修の頻度が限られる社内ツールは、これより少額になります。
費用の内訳は監視とアラートへの一次対応、利用者からの問合せへの対応、修正プログラムの適用と脆弱性への対応、アカウントと権限の棚卸し、ソフトウェア製品と実行環境の更新、手順書と構成図の更新です。

稼働開始時の引継ぎも費用に含まれます。

監視の設計、手順書の作成、当番体制の構築、利用部門の教育は、発注側が開発の完了条件に定めないと、稼働直前の追加費用になります。
委託する場合も予算の確保、改善の優先順位の決定、委託先の管理という発注側の工数が発生します。

見積もりに含めないと担当者の負荷が後から増加します。
作業範囲を契約で特定しないと、障害のたびに追加費用の交渉になる
特定の担当者しか変更できない箇所が増加すると、担当の交代と委託先の変更に移管の費用と期間がかかる
委託先を単年度の契約で変更すると、引継ぎの費用と期間が毎回発生する
複数の組織や情報システムをまたいでサービスを運営する場合、責任分界点を設定しただけでは責任の押し付け合いを招き、解決が遅れる懸念があります。

障害の原因が運用と保守のどちらにあるかは、発生直後には特定できないことが多いためです。
 運用・保守にどこまで求めるか運用・保守の体制は、社内に常時担当を配置できるかで委託と内製に分けます。求める水準は、業務が停止してよい時間から決めます。
 委託か内製か障害の一次対応と改善の優先順位について日常的に意思決定できる人が常時2名以上いるなら内製、いないなら委託とする会社が多いです。人数だけでなく、夜間と休日の対応を社内で回せるかも併せて見ます。

2名のうち1名はもう1名が不在のときに代替できる人である必要があります。
内製には採用と育成、休暇と退職の際の代替要員、夜間と休日の対応体制が必要です。

担当者が1名ではその1名が不在のときに復旧を担う人がいなくなります。

内製は費用が不要になるのではなく、人件費が社内に発生します。
委託では作業範囲と責任分界を契約で定めます。

改善の優先順位を決める人が発注側にいないと、障害対応だけが進行します。委託する場合も、誰が優先順位を決めるかを先に定めます。
国の調達では、継続的な改善を伴うシステムは複数年の契約が合理的とされています。

単年度の契約を繰り返す場合は、事業者を変更する際の対応と得失を評価する必要があります。
 見積の妥当性見積の妥当性は金額ではなく内訳で確認します。

含まれる作業と、別料金になる作業を区分します。
監視の対象と、アラートを受信する時間帯
問合せの窓口と、一次対応の範囲
修正プログラムの適用の可否を誰が決定するか
障害対応に充当する時間の上限と、超過した場合の単価
改修を保守に含めるか、別の契約にするか
目安の1〜2割を明確に下回る見積は、範囲が限定的か、障害対応が従量課金になっていることが多いです。比率だけで判断せず、内訳を確認します。

情報システム・モデル取引・契約書には、保守・運用を含む契約のひな形と解説が公開されています。

開発の完了を確認する検収の時点で、発注側が保守に含める作業を一覧にしておくと、稼働後の追加費用の交渉を削減できます。
調達の価格はライフサイクルコストの一部でしかありません。ライフサイクルコストを低減する提案を技術点として評価するなど、評価方法の考案が推奨されています。
 求める水準業務カレンダーを先に確定します。

月末と年度末の処理、夜間の連絡体制、復旧の手順を含めます。
給与、会計、受注のように停止の影響が重大なシステムは、数十分から数時間の復旧と、夜間も連絡可能な体制を求める
社内の情報共有とファイル共有は、翌営業日までの復旧を目標とする
試作と利用者数名の社内ツールは、応答時間を約束せず担当者が可能な範囲で対応すれば十分です。

監視の自動化も窓口の設置も不要で、担当者が直接対応し、障害の記録だけは保存します。
可用性の数値目標は停止してよい時間から逆算します。

1か月を30日で計算すると、月に4時間の停止は99.4%、40分は99.9%に相当します。

契約ではサービス水準として別に合意し、復元の目標は定めるだけでなく手順を実際に検証します。
 よくある誤解 運用・保守は開発の完了後の片付け稼働後の期間のほうが長く、判断の対象も広範になります。

運用・保守では、開発の成果物をそのまま維持するのではなく、制度と業務の変化に対応し、改修の要否を継続して判定します。
 クラウドサービスを利用すれば運用・保守は不要になるサーバーの管理はクラウド事業者に移管しますが、利用料の確認、アカウントと権限の管理、構成の更新、問合せ対応という運用・保守の作業は残存します。

システムを刷新しても運用が従来のままでは、コスト削減の効果が十分に発現しません。
 保守契約を結べば機能の追加もしてもらえる保守は機能要件を変更しない修正で、機能の追加と改善は改修として保守の対象外です。

改修は別の契約や別の見積もりの対象になるのが一般的です。

保守と改修は区別されています。
 障害が起きていなければ保守の作業はない修正プログラムの適用、アカウントの棚卸し、証明書の更新は、障害が発生する前に実施する運用・保守の作業です。

修正プログラムの適用は保守、アカウントの棚卸しと証明書の更新は運用に属します。

点検と更新を省くと障害に直結します。