保守案件に入るとき、最初に難しいのが引き継ぎです。資料はあるものの、どこを見ればよいのか分からない。前任者から説明を受けても、実際に障害や問い合わせが来たときに判断できるか不安になる。初心者SEであれば、このように感じることは珍しくありません。
保守案件の引き継ぎでは、単に資料を受け取るだけでは不十分です。システムの構成、業務の流れ、定例作業、障害時の連絡先、リリース時の注意点などを、実際に自分が対応できる状態まで整理する必要があります。この記事では、現役SEの実務目線で、保守案件の引き継ぎ時に確認すべきことをまとめます。
保守案件の引き継ぎで最初に見るべきもの
引き継ぎで最初に見るべきなのは、細かいソースコードではなく、システム全体の位置づけです。誰が使っているシステムなのか、どの業務に関係しているのか、止まると何に影響するのかを把握しないまま細部に入ると、問い合わせや障害時に優先順位を間違えやすくなります。
まずは、システム概要、業務フロー、機能一覧、連携先、バッチ処理、監視対象、問い合わせ窓口を確認します。資料が古い場合もあるため、資料に書かれている内容と実際の運用が一致しているかを前任者やチームに確認することが大切です。
| 確認対象 | 見る理由 | 確認できないと困る場面 |
|---|---|---|
| システム概要 | 業務上の役割を理解するため | 問い合わせの重要度を判断できない |
| 連携先 | 影響範囲を把握するため | 障害時にどこまで確認すべきか迷う |
| 定例作業 | 毎日・毎月の運用を把握するため | 作業漏れや確認漏れが起きる |
| 監視・アラート | 異常検知時の初動を知るため | 通知が来ても対応判断ができない |
| 連絡先 | 相談先と報告先を明確にするため | 障害時の連絡が遅れる |
引き継ぎでよく漏れるポイント
引き継ぎでは、設計書や手順書のような正式な資料は共有されやすい一方で、実際の運用で使っている暗黙知が漏れやすいです。たとえば「このエラーは月初だけ出るが業務影響はない」「このバッチは失敗しても再実行前に確認が必要」「この問い合わせは担当部署に確認してから回答する」といった情報です。
こうした情報は資料に書かれていないことが多く、前任者に聞かないと分かりません。引き継ぎ時には、正常時の手順だけでなく、過去に起きた障害、問い合わせが多い機能、よくある作業ミス、判断に迷いやすいケースを確認しておくと、実務に入りやすくなります。
障害時の判断基準を確認しておく
保守案件で特に重要なのが、障害時の判断基準です。障害が起きたときに、すぐエスカレーションするのか、一次調査をしてから報告するのか、暫定対応を先に進めるのかは、案件によって違います。この判断基準を知らないまま対応すると、報告が遅れたり、不要な作業を進めたりする可能性があります。
引き継ぎ時には、障害レベル、影響範囲、連絡先、報告テンプレート、一次対応の範囲、切り戻し判断の基準を確認します。障害対応の基本的な考え方は、障害対応・保守運用まとめ!現役SEが実務で確認するポイントでも整理しています。
定例作業とバッチ処理は実行条件まで見る
定例作業やバッチ処理は、手順書だけを見ると簡単に見えることがあります。しかし実務では、実行前の確認、実行後の確認、失敗時の再実行条件、実行してはいけないタイミングが重要です。特に月次処理や外部連携がある処理では、安易に再実行するとデータ不整合につながることがあります。
引き継ぎでは、バッチ名、実行時間、処理内容、入力データ、出力データ、ログの場所、失敗時の対応、再実行可否を確認します。手順書に「再実行する」とだけ書かれている場合でも、再実行前に誰の承認が必要か、どのデータを確認するかを聞いておくと安心です。
初心者SEがやりがちな失敗
資料を読んだだけで理解したつもりになる
資料を読むことは大切ですが、資料だけでは実際の運用は分かりません。古い資料、更新されていない手順、現場でだけ使われている判断基準があるためです。資料を読んだ後は、「この手順は今も使っていますか」「失敗した場合はどうしますか」と確認する必要があります。
連絡先を後回しにする
技術的な内容を優先して、連絡先や報告ルールの確認を後回しにするのもよくある失敗です。障害時は、誰に何を報告するかが分からないだけで対応が遅れます。特に保守案件では、技術調査と同じくらい報告のタイミングが重要です。
過去障害を確認しない
過去障害は、システムの弱点を知るための重要な情報です。過去にどの機能で問題が起きたか、原因は何だったか、再発防止は実施済みかを確認すると、今後の問い合わせや障害対応で注意すべき点が見えてきます。障害報告書の見方は、障害報告書の書き方!原因・暫定対応・再発防止を分けるコツも参考になります。
引き継ぎ後1週間で確認したいチェックリスト
- システムの利用者と業務影響を説明できるか
- 問い合わせが来たときの一次確認先が分かるか
- 障害時の連絡先と報告ルールを把握しているか
- 定例作業の実行タイミングと確認方法を理解しているか
- バッチ失敗時の再実行条件を確認しているか
- 過去障害とよくある問い合わせを確認したか
- リリース時の注意点と切り戻し手順を把握しているか
リリース前の確認観点については、リリース前に確認すべきこと!本番反映で見落としやすい設定・DB・権限でも詳しくまとめています。保守案件では、日々の問い合わせ対応だけでなく、リリースや設定変更の影響も意識しておく必要があります。
まとめ:引き継ぎは資料を受け取る作業ではなく、対応できる状態にする作業
保守案件の引き継ぎでは、資料を受け取っただけでは十分ではありません。システムの役割、業務影響、定例作業、障害時の判断基準、連絡先、過去障害を確認し、自分が一次対応できる状態にすることが大切です。
初心者SEは、最初からすべてを覚える必要はありません。ただし、分からないときにどこを見ればよいか、誰に確認すればよいか、どの情報を残せばよいかを整理しておくと、現場で動きやすくなります。保守案件に入った直後の確認項目は、保守案件に入ったら最初に確認すること!現役SEが実務で見ているポイントもあわせて読むと理解しやすいです。