はじめに

製造エネルギー事業部の後藤です。

初めてシステムの運用引き継ぎを経験しました。その中で得た知見や工夫した点を、「春の入門祭り2025」にあわせて共有します。

システムの運用を引き継ぐ立場の方はもちろん、日常的にシステム開発に携わっている方にも、参考になる点があれば幸いです。

1. システム運用引き継ぎとは？

通常システムは何かしらの目的を果たすために作られ稼働しているはずです。大前提としてシステムが何のために作られ、何を実現することが期待されているのかを理解しておく必要があります。

その目的を達成するために、引き継ぎを行った後でも、滞りなくシステムが運用される必要があります。そのためにも最低限「定常作業対応」「非定常作業対応」、「障害対応」を行える必要があります。

できる限り作業を自動化して「定常作業対応」「非定常作業対応」を減らしていくことは重要ですが、費用対効果の観点から難しい部分があるのも現実です。またどんなに良いプログラムを書いても、連携先のシステムのエラーやネットワークのエラーなど、どうしても障害対応に人の手が必要な場合があります。

システムを一度作って、そこで終わりでないケースがほとんどだと思います。利用しているライブラリなどにセキュリティの問題があればアップデートや修正が必要ですし、さらに高い目標の達成のためにシステムを改善したいという気持ちが湧いてくるのも自然でしょう。

詳細な手順書を用意すれば、ある程度の作業を任せられるようにはなりますが、未知の障害にぶつかった時、機能改修や機能追加を行う時には背景や全体像をしっかり理解していないと歯が立ちません。

運用引き継ぎを行う際に準備しておくべきこと、引き継ぎ手順、工夫した点、注意事項などをお伝えできればと思います。

2. 引き継ぎ概要

どんなシステムをどのくらいの期間でどんな手順で引き継いだのか概要をまとめています。

• 引き継ぎ手順
  • キックオフ&概要説明
  • 環境構築説明
  • システム全体像説明
  • IF連携説明
  • 定常作業説明&非定常作業説明
  • 障害対応手順説明
  • 定例会議資料作成＆ファシリテーション引き継ぎ
  • コードリーティング&ハンズオン
  • タスク引き継ぎ
  • 課題&その他共有

3. ドキュメント化の重要性

運用引き継ぎで何が重要かと問われれば「丁寧なドキュメント整備」と即答します。知りたい情報がドキュメントにまとまっていれば、時間がかかっても業務を進めることができます。

運用引き継ぎのためだけにドキュメントを書くのではなく、日頃から丁寧に整備する意識を持ち、チームで徹底することが重要です。急ぎの作業の時にソースコードさえ修正されていればいいと考える人もいると思いますが、実装の背景や経緯を記載していないと後々調査に時間がかかったり、誰も手がつけられないコードが増えてしまい、開発効率やサービスの質を落とすことにも繋がってしまいます。

ドキュメントの徹底的な整備は正直なところ辛い部分もありますが、結果的に自分たちの助けにもなります。私のチームではソースコードを変更した際には必ずレビュアーが設計書などのドキュメントが修正されたかを確認してPRをApproveするようにしていました。またドキュメントに不備があった場合には積極的に修正するなどチーム内での文化の形成が重要です。当たり前のことをしっかりやることがとても大切です。リンターやAIなど便利なツールも沢山あるので、なるべく楽をしつつドキュメントを整備していけるといいと思います。

ドキュメント管理

私のチームでは設計書や開発者向けの情報はGitHubのドキュメントフォルダ配下にまとめていました。参考までに下記のようにドキュメントをまとめていました。

ドキュメント/
├── 01_システム設計/
├── 02_インフラ設計/
├── 03_フロントエンド設計/
├── 04_フロントエンドアプリ利用ガイド/
├── 05_IF仕様書/
├── 06_データモデル/
├── 07_API設計書/
├── 08_ジョブ設計書/
├── 09_帳票一覧/
├── 10_定型運用/
├── 11_非定型運用/
├── 12_障害対応/
├── 13_リリース対応/
├── 14_開発規約/
└── 15_環境構築/

4. 引き継ぎ手順

実際にどのような順序で引き継ぎを行っていったかと工夫した点を説明していきます。大まかな流れは引き継ぎ概要に書いた通りです。

4.1. キックオフ&概要説明

実施事項

• メンバーの自己紹介
• 会議帯の設定
• 各種ツール準備
  • GitHubリポジトリ招待
  • AWSアカウント発行
  • チャットツール招待（Slack, Google Chatなど）
  • チケット管理ツール招待（Backlog、Jiraなど）
  • ストレージサービス招待（Google Driveなど）
• システムの概要の説明

ポイント

• 利用するツールやチャンネル一覧情報はGitHubのトップページに集約
• ツール準備はできるだけ早い段階で実施
• 基本的にドキュメントはGitHubに集約するが、特に重要な箇所や、困った時に参照すべき場所を伝えるため、簡単なスライドも用意

4.2. 環境構築説明

実施事項

• 環境構築手順の説明（どのドキュメントを見ればいいか）
• 環境構築のサポート

ポイント

• 環境構築が終了しないと改修タスクの依頼ができないため優先
• GitHubに環境構築用のページを用意
• コンテナやMakefileなどを利用して同じ環境を短時間で構築
• 環境構築の概要の説明をしたら基本はドキュメントに従って実行。サポートが必要な場合は会議を実施
• プロキシが存在する場合、その関係で詰まるケース多いので早い時期から対応

4.3. システム全体像説明

実施事項

• システム概要図説明
  • データの発生源や流れを意識して説明
• システム概念図説明
  • どのような関連システムがありどのような種類のデータを何のためにやり取りしているか大枠を説明
• データモデル説明
  • DB定義などどのようなデータを扱っていて、どのように関連しているのか説明。ER図なども有効
• 特に重要な処理の説明
  • システムで一番重要なデータや業務影響が大きい処理から説明

ポイント

• システム構成図の準備
  • 全てのJobやサービスを記載できると良い。大枠の構成図を１つ作成して詳細部分は複数に分けるのもあり
  • draw.ioでの作成がおすすめ（.drawio.png形式でマークダウンページに埋め込む）
• システム概念図
  • IF連携しているシステムを全て記載
  • 全てのやり取りを詳細に記載できなくても良いので、どんな情報を何のために連携するのか記載
• 用語集の準備
  • GitHubのトップページにスプレッドシートのリンクを貼り、スプレッドシートに用語集を作成。不明な用語を書いてもらい解説を記入（まずはリアルタイムでやり取りしやすいスプレッドシートで共有し、後にGitHubへ反映する運用）
• データの発生源から順にデータの流れを説明することで大枠の流れを伝える
• 業務影響が大きい処理を説明する際は、この処理が失敗すると、「○円かかる」「○人の顧客に影響がある」「復旧に○人の作業が必要」など具体的な影響を説明すると伝わりやすい

4.4. IF連携説明

実施事項

• IF仕様書説明
  • IF一覧説明
  • 重要なIF連携説明

ポイント

• 最悪詳細な仕様書がなくてもIF一覧は用意
  • API連携がある場合、どのエンドポイントをどのシステムが利用しているかまとめられるとなお良い
• システム改修時の影響範囲調査の際に利用するのでIF仕様の整理はしっかりと行う

（IF一覧例）

• 受信

  機能ID	機能名	連携システム	形式	頻度	日時	未着チェック	冪等	Path Prefix	説明
  IF_IN_01	A受信	Aシステム	S3	日次	0:00	○	○	prod-xxx-bucket/
  IF_IN_02	B受信	Bシステム	Kinesis	随時	-	-	○	prod-xxx-kinesis

• 配信

  機能ID	機能名	連携システム	形式	頻度	日時	Path Prefix	説明
  IF_OUT_01	X配信	Xシステム	S3	日次	0:00	prod-system-x-bucket/

4.5. 定常作業説明&非定常作業説明

実施事項

• 定常作業説明&実行
• 非定常作業説明&実行

ポイント

• 引き継ぎ前に可能な限り作業の自動化や簡略化を行う
• 作業一覧と作業手順書をGitHubに作成
• できるだけはない段階で引き継ぎ先に実行して慣れてもらう
• 説明会の内容を録画してGitHubにリンクを貼るのがおすすめ

4.6. 障害対応手順説明

実施事項

• 監視設計説明
• 障害発生時対応方法説明

ポイント

• 障害が発生した際にどのように通知されどのような対応が必要なのかを説明
• 最低過去6ヶ月に発生した障害の対応手順書をGitHubに作成する
  • 誰が見ても作業できるように画面のスクリーンショットを付ける
  • 引き継ぎ先に内容をレビューしてもらい作業が誰でもできる状態を一緒に目指す
• 可能であればJobエラーアクションリストを作成し全てのJobの全てのエラーを一覧化する
  • スプレッドシートを作成してGitHubにリンクを貼る
  • 全ての対応手順を作成するの難しいので全てを埋める必要はないが、過去どのように障害対応をしたのかわかるようにBacklogチケットなどのリンクを貼ると良い（普段から記録をしっかりと残すことが重要）
• 障害発生を見逃さぬようにメール送信、Slack通知、担当者設定など工夫が必要
  • 日次で障害の見過ごしがないか時間を取るのもおすすめ

（Jobエラーアクションリスト例）

4.7. 定例会議資料作成＆ファシリテーション引き継ぎ

実施事項

• 定例会議の資料作成法引き継ぎ
• 定例会議への参加
• 会議ファシリテーション引き継ぎ

ポイント

• 定例会議で顧客への報告などがある場合は、どのような資料を用意しているのかを共有する（過去の会議の資料はGoogle Driveなどに集約する）
• いきなり全てを引き継ぐのでなく、まずは会議の参加から部分的なタスクの進捗報告などから徐々に引き継ぐ
• いきなり全てを任せようとすると引き継ぎ先としては辛いので、気持ちに寄り添って伴走する姿勢も重要

4.8. コードリーティング&ハンズオン

実施事項

• システム構成と具体的なソースコードの処理内容を説明
• 開発規約の説明
  • テストの実施方針、コードレビューの方針なども含めて説明
• リリース手順説明&リリース作業

ポイント

• 重要なJobや改修タスクに関連するJobから順にソースコードリーディングを実施
  • なぜその実装をしているのか背景をソースコードにコメントがあると良い。GitHubのIssueのリンクをコメントに貼るのもおすすめ。引き継がれる側からするとコメントが充実している方が安心
• しっかりとした設計思想があると引き継ぎの際にも説明しやすく、すべての指針となるので、設計思想は重要
• リリース作業の引き継ぎは時間をかけて行う
  • リリース作業は引き継ぎ先と一緒に行い徐々に作業を任せていく
  • 週に１度リリース作業をしていたが、念のため毎回引き継ぎ期間にはリリース作業に立ち会った

4.9. タスク引き継ぎ

実施事項

• 機能改修説明
• レビュー
• リリース

ポイント

• できる限り早い段階で機能改修を任せるようにすると、システムへの理解が進む
• GitHubのissueに背景、修正対象のソースコード、対応方法、テスト方法、検証方法などを詳細に記載して、対面でタスクの説明をしてタスクの依頼をする
• 「困ったことがあればいつでも聞いてください」と伝え続けてよい関係性を作る
• 対応手順がわかっているタスクであれば、相手に考えさせるのではなく自分ならどうするかと、なぜそうするのかを説明してタスクを進めてもらう
  • 自分の力で考えてもらうことも時には必要ですが、より良い答えを持っているのであれば、出し惜しみをせずに全て伝えましょう
• ソースコードなどのレビューは手を抜かない
  • いくら不慣れだからといってレビューを甘くしてしまうと、結果的にサービスの質の低下につながってしまうので、しっかりと気になるところは伝えるようにしましょう
  • 大量の指摘事項をもらう側は辛いと思うので、伝え方には注意しましょう

4.10. 課題&その他共有

実施事項

• 課題共有（GitHub Issueにまとめて説明）
  • ユーザーが数倍に増えた時には○○の改修が必要なども説明できると良い
• バージョンアプ対応説明
  • プログラミング言語やツールのバージョンアップの方針の説明

ポイント

• 課題や問題がある場合には包みかくさずに全てを伝える

5. コミュニケーション

最終的にシステムを利用するのも運用していくのも人であり、システムの運用を引き継ぐのも人になるので、コミュニケーションは欠かせません。最後に引き継ぎにおいて特に重要だと思うコミュニケーション面のお話を共有します。

引き継がれる側は他の人が育てた未知のシステムの面倒を見ることになると理解する

システムを引き継ぐ側としては背景や問題点など熟知した身近な存在かもしれませんが、引き継がれる側からするとそうではありません。

引き継がれる側としては、いつ機嫌を悪くして暴れ回るかもわからない、性格も機嫌の取り方もわからない猛獣に見えるかもしれません。暴れ回った責任を育ててもいない自分達が負わなければならないという不安を抱えているかもしれません。

そんな相手の気持ちを理解して、システムの特徴や問題点などを根気よく説明していく必要があります。引き継ぎ元の担当者がしっかりとした人間だと思ってもらえれば、その人が見ているシステムもしっかりしていると思って貰いやすくなるので初めのコミュニケーションは大切です。

相手の中にある不安要素を理解して、それに寄り添いながらコミュニケーションを取っていこうという姿勢がとても大切だと思います。

いつでも情報を共有してもらうように関係性を構築する

円滑に引き継ぎを進めていく上で相手が何を理解できていなかを把握することはとても重要です。物事を理解しないままタスクを進めてしまうと、時間の無駄が発生したり障害を発生させてしまったりマイナスな影響を与える可能性があります。

相手がわからないことがあればすぐに解決できる体制を作ることで、システムへの理解度、タスクの進捗、信頼度を上げることができるので、「わからないことがあればいつでも聞いてください」と引き続き期間中に言い続けていました。困っていそうな時にはこちらから確認して会議を設定したり、チャットで情報共有をすることで、コミュニケーションを円滑に行うことができたと思います。

運用引き継ぎというプロジェクトを成功させるためにお互いに協力してゆくことがとても大切です。

3度説明しただけで理解してもらおうという思いは捨てる

引き継ぎ期間中、「前にも同じ説明を何度かしたな」と思うことが複数回ありました。もちろんドキュメントにも同じ説明を記載していますが、会話ベースで説明した方が伝わりやすいと思うことが多々ありました。

３度同じ説明をしたら理解して欲しいという気持ちはよくわかるのですが、引き継ぎ先としては日々膨大なインプットを行い情報の紐付けと整理に苦労していることを理解する必要があります。

３度同じ説明をしたら理解して欲しいではなく、15回同じ説明を別のアプローチで行いなんとか相手の頭の中に情報を整理してもらおうとする姿勢が大切だと思います。タスクを通して理解を進めるのが一番の近道だとは思いますが、根気よく重要な情報は複数回共有するべきたど思います。関係性ができてきたらクイズ大会を実施するのもいいと思います。

引き継ぎ前と引き継ぎ後で同じパフーマンスが出ないことを理解してもらう

長く引き継ぎの期間を取ったとしても、引き継ぎ後に引き継ぎ前と同じパフォーマンスを出すことは難しいことが多いです。ステークホルダーにはそのことを根気強く説明して理解してもらうことが大切です。

まとめ

システムの運用引き継ぎで学んだことを共有しました。

普段から自動化、ドキュメントの整備、情報の集約を行うことで、引き継ぎの有無に関係なく業務を効率化できるできると思います。有識者が不在な場合や移動になった場合にも、滞りなく業務が進められる必要があるので、今回まとめた内容を参考にしていただければと思います。ドキュメントの整理など当たり前のことをしっかり続けていくことが大切です。辛い部分もあるかもしれませんが結果的に自分達のためになると思います。

またコミュニケーションについてもお話ししましたが、一番大切なのは相手の気持ちを理解しつつゴールに向かって互い協力し合うことが大切だと思います。

最後まで読んでいただきありがとうございました。