安定化期間とSMへの引き継ぎ

一言でいうと

安定化は、残ったバグを直す時間ではなく、運用組織が自力で回せるようにする時間であり、これを誤解すると、契約が終わったあとでも電話がかかってきます。

なぜこれが問題なのか

急ぎの仕事と重要な仕事が、ちょうど反対の方向にあるからです。サービスイン直後は障害と問い合わせが殺到するので、1日が対応だけで埋まり、運用の文書化と知識移転は、「今週だけ乗り切って」と言って、ずっと後回しになります。

そうして安定化期間が終わると、保守(SM)担当者は、システムを知らないまま引き継ぎを受けます。その結果が、数か月後の明け方2時の電話です。契約は終わったのに、聞ける人があなたしかいないからです。安定化の成果は、「障害が何件あったか」ではなく、「もう私たちなしで回っているか」で測る必要があります。

安定化期間は普通3–6か月である

契約書に「安定化期間」という項目があります。サービスイン直後の一定期間、受託ベンダーが障害対応と初期の欠陥修正を担う区間です。この期間の性格を誤解している新人が多いです。安定化は「残ったバグを直す時間」ではなく、運用組織が自力で回せるようにする時間です。

そのため、安定化期間にやるべきことは3つに分かれます。

実際の障害・問い合わせへの対応(急ぎの仕事)
運用の文書化: 運用者マニュアル、障害対応手順書、バッチ運用ガイド(重要な仕事)
知識移転: SM担当者への教育、同行勤務、引き継ぎ確認書(契約上の義務)

急ぎの仕事にだけかかりきりになると、安定化が終わる日に、SM担当者は何も知らないまま残されます。そして6か月後の明け方2時に、あなたに電話がかかってきます。契約は終わったのに、電話はかかってきます。

サービスイン直後の1週間に、実際に何が起こるのか

時点	典型的な課題
サービスイン当日の午前	ログインの殺到。全社員が同時にアクセス。コネクションプール・セッション設定が最初の関門
1–2日目	画面エラーの問い合わせ。大半はデータの問題(コード値の欠落、移行データの異常)
3日目	最初の夜間バッチの結果の異常。データ移行の境界条件
1週目	月末/週次業務の初めての実行。「この画面はどこですか」という問い合わせが急増
1か月	最初の月次締め。統計・精算の数字が合わないという報告

パターンが見えます。サービスイン直後の課題の多数は、コードの欠陥ではなく、データと設定です。そのため、カットオーバーのときに作ったデータ検証スクリプトと設定バックアップが、安定化期間中ずっと使われます。

障害対応の標準フロー

現場では、この順序を外れると、たいてい悪化します。

1. 접수·기록      언제, 누가, 무슨 화면에서, 어떤 메시지
2. 영향 범위 파악  전체인가 일부인가. 특정 사용자/특정 데이터만인가
3. 임시 조치      서비스 복구 우선 (재기동, 우회, 기능 임시 차단)
4. 원인 분석      로그·모니터링·최근 변경 이력
5. 항구 조치      코드/데이터/설정 수정과 배포
6. 재발 방지      모니터링 추가, 검증 로직 추가, 문서 갱신

このコードブロックの韓国語は、番号順に、受付・記録(いつ、誰が、どの画面で、どんなメッセージか)、影響範囲の把握(全体か一部か、特定のユーザー・特定のデータだけか)、暫定対応(サービス復旧を優先し、再起動、回避、機能の一時遮断)、原因分析(ログ・モニタリング・最近の変更履歴)、恒久対応(コード・データ・設定の修正とデプロイ)、再発防止(モニタリングの追加、検証ロジックの追加、文書の更新)を表しています。

3つ目と4つ目の順序を、入れ替えないでください。原因をすべて把握してから対応するという態度は、障害の時間を延ばします。ただし、3つ目を行いながら、証拠は必ず残します。再起動の前に、スレッドダンプとログを確保しなければ、原因を永遠に見つけられません。「とりあえず再起動したら直りました」が3回繰り返されると、4回目には再起動でも直りません。

欠陥管理台帳と「欠陥対要件」の争い

安定化期間の最大の対立は、これです。

顧客: 「これ、動かないじゃないですか。欠陥なので直してください。」

受託ベンダー: 「それは要件になかったものです。追加開発です。」

この争いで根拠になるのが、要件定義書とRTMです。だから、1か月目に作った文書が、8か月目に会社を守ります。

欠陥管理台帳は、次のように管理します。

欠陥ID / 登録日 / 登録者 / 現象 / 再現手順 / 重大度(致命・中・軽) / 担当者 / 対応日 / 対応内容 / 判定(欠陥/依頼/問い合わせ)
判定列が核心です。判定なしにすべて直してあげると、プロジェクトが終わりません。

重大度の基準も、あらかじめ合意しておきます。普通、「致命」は業務の停止、「中」は回避可能、「軽」は不便です。重大度によって、対応時間(SLA)が違います。

保守(SM)に移るとき、引き渡すべきもの

引き継ぎ確認書に、一覧が入ります。実務的には、これくらいはあるべきです。

システム構成図(サーバー・ポート・アカウント・パス。実物と一致しているもの)
デプロイ手順書とロールバック手順書(実際に一度、その通りにやってみたもの)
バッチ一覧: スケジュール、先行・後続の関係、失敗時の対応
インターフェース一覧: 相手システム、担当者の連絡先、障害時の連絡順序
アカウント一覧: DB、WAS、OS、外部システム(そしてパスワードの管理主体)
既知の課題と暫定対応の一覧: これを隠してはいけません。どうせ3週間以内に露呈します
モニタリング項目としきい値

保守段階の仕事とは何か

SMは「壊れたら直す仕事」ではありません。実際の業務の比重は、おおよそ次のとおりです。

変更要求が40%(法改正、業務ルールの変更、画面の追加)
定例作業が25%(バッチのモニタリング、月次/四半期の締めの支援、バックアップの確認)
問い合わせ対応が20%
障害対応が15%

そのため、SM担当者に必要な能力は、「速い開発」ではなく、影響範囲を正確に判断する能力です。カラムを1つ増やす依頼が、連携システム3か所に影響を与えることを知っている人が、良いSMです。その判断の根拠は、結局、インターフェース仕様書とテーブル定義書です。文書は、プロジェクトが終わってから、本当の価値を発揮します。

現場での姿

サービスイン最初の週は、順序がほとんど決まっています。

当日の午前はログインが集中します。全社員が同じ時刻にアクセスするので、コネクションプールとセッション設定が最初の関門で、ここで詰まると、システムではなくサービスイン自体が失敗したように見えます。1–2日目には画面エラーの問い合わせが入ってきますが、かなりの部分は欠陥ではなく、「以前のシステムと違う」という話です。これを欠陥として受け付けると、欠陥台帳が数日で数百件になり、本物の欠陥が、その中に埋もれます。

そのため、この時期に最も重要な文書が、欠陥台帳の分類基準です。欠陥なのか新規要件なのかを、そのつど決めていると毎回争いになりますが、基準が先にあれば、判定は事務作業になります。

引き継ぎも同じです。最後の週にまとめて行う教育は、身に付きません。SM担当者が、実際の障害に一緒に対応した回数が、引き継ぎの本当の指標です。