私がアプリSEとして働いていたとき、大規模なシステムリプレースに周辺システム側の担当者として参加し、夜間作業を経験しました。
リプレースの中心となるシステムを担当していたわけではありませんが、周辺システム側でも接続先の変更や設定変更、疎通確認などが必要でした。
この記事では、そのとき実際に行っていた作業や、多人数で進めるリプレースで意識していたことを紹介します。
大規模リプレースでは周辺システム側も夜間対応していた
システムは24時間稼働していたため、リプレース後に問題が残れば、その後の日中業務へ影響する可能性がありました。
メインとなるシステムだけでなく、周辺システムとの接続や処理についても確認する必要があります。
そのため、自分の担当範囲についても、夜間に作業と確認を進める形でした。
接続先変更や設定変更、疎通テストを行っていた
周辺システム側で行う作業は、そのリプレース内容によって異なります。
私が経験した範囲では、
- 接続先の変更
- 設定値や各種設定の変更
- 疎通テスト
などがありました。
自分が担当するシステムそのものをリプレースする場合には、設定値の変更だけでなく、既存システムを停止するための準備を行うこともありました。
実際の接続先や設定値は案件ごとに異なりますが、私の場合は、リプレース後も周辺システムとの接続や処理が成立する状態に切り替えることが担当作業の一つでした。
手順書・タイムスケジュール・チェックリストを確認して進めていた
夜間作業では、手順書だけを見て作業していたわけではありません。
私は、
- 手順書
- 全体のタイムスケジュール
- チェックリスト
を確認しながら進めていました。
大規模なリプレースでは、自分の担当作業だけを見ていればよいわけではありません。
他チームの作業が終わらなければ、自分の作業を始められないこともあります。
そのため、自分が何をするかだけでなく、いつ作業を始めてよいのかも確認する必要がありました。
本番作業前に行っていた準備については、本番作業でミスを減らすために意識していたことでも紹介しています。
予定と違う作業が必要になっても勝手に進めなかった
夜間作業では、予定どおりに進まないこともあります。
私が特に気を付けていたのは、予定していた作業と違う対応が必要になったときに、自分の判断だけで変更しないことでした。
予定外の作業が必要になった場合は、上長へ連絡し、承認をもらってから対応していました。
本番に関わる作業では、技術的に対応できそうだからといって、その場で勝手に変更してよいとは考えていませんでした。
IPAの「情報処理システム高信頼化教訓集」にある本番環境の作業事例でも、作業タイムチャートや実施体制、作業手順、連絡体制などを事前に整理し、承認された作業手順以外を実施しないという対策が示されています。
これは私が経験した現場の手順そのものを示す資料ではありませんが、予定外の作業を担当者だけの判断で進めないという点では共通しています。
特に大人数が関わる作業では、一人の変更が後続作業へ影響する可能性もあります。
そのため、予定と違う場合ほど、まず状況を共有してから進めるようにしていました。
クリティカルパスに沿って他チームの完了を待っていた
大規模なリプレースでは、多くの担当者が同時に作業します。
ただし、それぞれが任意のタイミングで作業するわけではありません。
私が経験した作業ではクリティカルパスが作られていて、
「この作業が終わったら次の担当が開始する」
という順番が決まっていました。
そのため、自分の作業準備ができていても、前の担当者の完了を待つことがあります。
多人数で進める作業なので、こうした待ち時間はよく発生していました。
自分の担当作業が完了した場合は、統括へ連絡していました。
さらに、定期的なタイミングで全体進捗が一斉メールとして共有され、
- どの担当が終わったか
- どこまで作業が進んでいるか
を確認できるようになっていました。
私にとって夜間作業は、ずっと手を動かし続ける仕事というより、全体の進行を確認しながら、自分の作業タイミングを待ち、完了したら次へつなぐ作業でもありました。
周辺システムとの連携確認まで行っていた
設定変更が終われば、それだけで作業完了とは限りません。
私が経験したリプレースでは、周辺システムと実際に連携できるかを確認することもありました。
テストデータを使って連携を確認する場合もあれば、実データを使って確認する場合もありました。
実データを使って確認した場合には、処理結果を確認したあと、テスト実行によって作成されたデータを削除するところまで作業に含めていました。
これは私が経験した案件での進め方であり、実データを使ったテストを一般的な方法として勧めるものではありません。
単に通信できるかだけではなく、実際の処理が終わった後の状態まで確認していた経験です。
問題が起きたら調査するが、修正は独断で決めなかった
夜間作業中に問題が起きた場合は、その場で原因を調査していました。
ただし、原因が分かったからといって、そのまま自分の判断だけで修正するわけではありません。
私の場合は、修正が必要になったら上長や顧客へ状況を伝え、問題ないと判断された後に対応していました。
調査はその場で進めても、実際に何を変更するかは関係者と確認してから決めるという形です。
なお、私自身はリプレース作業で実際に切り戻しが発生した経験はありません。
そのため、この記事では切り戻し手順や判断方法までは扱いません。
夜間作業で一番強かったのは失敗できない緊張だった
夜間作業というと、眠さを想像する人もいるかもしれません。
私の場合、一番印象に残っているのは眠さよりも、失敗できないという緊張でした。
手順書やチェックリストが用意されていても、作業は長時間にわたります。
さらに、自分の担当だけでも複数の作業タスクがあります。
「次の作業で間違えないか」
「確認漏れがないか」
と考えながら、一つずつ進めていました。
多くの担当者が決められた順番で作業しているため、自分のミスが後続作業へ影響する可能性もあります。
私にとって大規模リプレースの夜間作業は、作業量そのものよりも、長時間にわたってミスを出さずに自分の担当を完了させることへの緊張が大きい仕事でした。
まとめ：夜間作業では全体の進行を見ながら自分の担当を進めていた
私が経験した大規模リプレースの夜間作業では、決められたタイムスケジュールやクリティカルパスに沿って、自分の担当作業を進めていました。
夜間作業は単に夜に作業するのではなく、複数の担当者の進捗と判断ルートを確認しながら、自分の担当を確実に完了させる仕事だと感じています。
