作った人がいないシステムを引き継いだ初日に、まず全体像を1枚にまとめようとサーバー構成を落ち着いて確かめている一人運用の保守担当者
レガシー・技術的負債約16分

作った人がいないシステムを引き継いだ初日にやること

「このシステム、今日からお願いね」。 そう言われて画面を開いてみたら、作った人はもう退職していて、仕様書も見当たらない。 コードを開いても、どこから動いているのかさえ分からない。

引き継ぎ初日のこの感覚、本当に心細いですよね。 何が動いているのか分からない。 どこを触ると壊れるのか分からない。 そして「もし今、これが止まったら、自分は何もできない」という不安だけが、はっきりある。

でも大丈夫です。初日にやることは、コードを理解することでも、全部を覚えることでもありません。 「触らない。でも、止まっても困らない準備をする」。今日はこれだけで十分です。 この記事では、作った人がいないシステムを引き継いだ初日に、何を・どの順で確かめておけばいいかを、一人運用の現場目線で一緒に整理していきます。

結論：引き継ぎ初日は、改修や理解より先に「守りの足場」を固めます。順番は、①ログイン手段を確保して二度と締め出されないようにする → ②システムの全体像（どこに何があるか）を1枚にまとめる → ③今まさに動いているもの（プロセス・cron・監視）を把握する → ④止まったときの連絡先とエスカレーション先を確認する → ⑤バックアップの有無と所在を確かめる → ⑥自分が見聞きしたことをメモに残し始める。コードを読むのは、この足場ができたあとで大丈夫です。

引き継ぐシステムの構成（オンプレかクラウドか、言語、DBの種類）や、社内のルールによって、初日にできることは変わります。 この記事の手順は出発点として、自分の現場に置き換えて使ってください。前任者と話せる時間がまだ少しでも残っているなら、それが何よりの一次情報です。後で読み解くより、今聞けることを優先しましょう。

ただ、現実には前任者が完全にいない引き継ぎも珍しくありません。本記事には「前任者に聞く」が何度か出てきますが、聞ける相手がいなくても置いてけぼりにはなりません。前任者がいない場合は、過去の障害対応メール・チャット履歴・請求書や契約書・コミットログ（Git の変更履歴）が、次に効く一次情報になります。「いつ・何が・なぜ変わったか」「どこに連絡していたか」「どの業者と契約しているか」は、人ではなくこうした記録の中に残っていることが多い。以降で「前任者に聞く」と出てきたら、相手がいなければこれらの記録を当たると読み替えてください。

なぜ「初日」がそんなに大事なのか

引き継ぎは、初日に流れを作れるかどうかで、その後の数か月の落ち着き方がまるで変わります。理由を言葉にしておくと、これから挙げる手順の一つひとつが「なぜ今日やるのか」で腑に落ちます。

つまり初日の主役は、コードを読む力ではありません。「分からないまま、止まっても困らない状態を作る」という段取りです。 だったら、見えるようにして、連絡できるようにして、戻せるようにすればいい。それが次の手順です。

まず「触らない」と決める

具体的な手順に入る前に、ひとつだけ約束をしておきます。初日は、設定もコードも本番データも、原則として変えない。

引き継いだ直後は、何が「正常」かが分かりません。良かれと思って直した1行が、実は他の処理が前提にしていた挙動かもしれない。「動いているが触れない」のがレガシーの怖さで、初日のあなたには、まだそれが見分けられなくて当然です。

だから初日は、読む・見る・控えるに徹します。 変更が必要だと感じても、まずはメモに「直したい候補」として書き留めるだけにしておく。実際に手を入れるのは、全体像が見えて、戻し方が分かってからで十分です。これは臆病なのではなく、プロとして順番を守っているだけです。

初日に集めておきたい情報（一覧）

アクセス手段・全体像・稼働中のもの・連絡先・バックアップの5つを、引き継ぎ初日に集める情報として中心から枝分かれで整理したマップ図
初日はこの5領域を「分かる範囲で」埋める。空欄が見つかることこそ収穫

初日にすべてを理解する必要はありません。でも、「どこに何があるか」の見取り図だけは、分かる範囲で埋めておきます。 次の表は、初日に集めたい情報を種類ごとに整理したものです。全部そろわなくて大丈夫。埋まらない欄（＝引き継ぎの抜け）が見つかること自体が、初日の収穫です。

集める情報具体的に何をどこを見る・誰に聞く優先度
アクセス手段サーバー・管理画面・DB・ドメイン/SSLの管理元へのログイン情報、SSH鍵前任者、パスワード管理、契約書類最優先
全体像どのサーバーで何が動き、どこにDB・外部連携があるか構成図、/etc、設定ファイル、前任者最優先
稼働中のもの常駐プロセス、cron/バッチ、監視、外形監視ps、crontab -l、監視ツール高
連絡先障害時の連絡先、エスカレーション先、ベンダー、利用者の窓口運用ルール、契約先、上長高
バックアップ何が・どこに・いつ取られ、戻し方は何かバックアップ設定、ストレージ、前任者高
コード/変更履歴ソースの場所、リポジトリ、デプロイ方法Git、サーバー上のディレクトリ中
契約・期限ドメイン・SSL・サーバー契約・サポートの期限請求書、契約書、管理コンソール中

上から順に、「最優先」が今日中に押さえたい守りの足場です。 「中」のコードや契約は、初日に全部分からなくても、明日以降に少しずつでかまいません。

初日にやること（順番に）

ログイン確保・全体像・稼働中の把握・連絡先・バックアップ・記録の順に、引き継ぎ初日の作業を上から進める6段の手順図
上から順に。理解より先に「締め出されない・連絡できる・戻せる」を作る

集める情報が見えたら、次の順番で進めます。各ステップは「締め出されない」「連絡できる」「戻せる」を先に作るためのものです。焦っているときほど、上から順に。

① ログイン手段を確保し、二度と締め出されないようにする

何より先に、自分がこのシステムに入れる状態を確実にします。ここが抜けると、いざという日に手も足も出ません。

「どのログインが手元にあって、足りない分は誰にいつ申請するか」を言える状態を作ってから、次へ進みます。

② システムの全体像を1枚にまとめる

次に、どこに何があるかの地図を、ざっくりでいいので描きます。きれいな構成図でなくて大丈夫。手書きのメモで十分です。

ここでの目的は、完璧な理解ではなく、「障害のとき、どこを見ればいいか当たりがつく」状態です。空白のままの箱があってもいい。それは「ここは後で調べる」という印になります。

設定ファイルやコードが多くて全体像をつかむのに時間がかかるとき、社内で外部AIの利用が許可されているなら、それらをAIに読ませて「どんな処理が、どこに、何につながっていそうか」を要約させ、地図づくりの下書きにするのも手です。接続先（DBのホスト、外部APIのURL）や常駐していそうな処理を一覧にしてもらえると、初日のとっかかりがぐっと早くなります。ただし、これはあくまで最初のあたりをつけるための要約です。AIは設定の意図や本番だけの事情までは知りません。鍵やパスワードなどの機微な情報は渡す前に伏せ、要約が指す接続先やcronは実際の設定ファイル・crontab -l・前任者への確認で裏を取ってから地図に書き込んでください。聞ける時間が残っているなら、要約より前任者の一言が一次情報です。

社内にAI利用のルールが無い・許可待ち・禁止という現場も多いはずです。その場合は無理に使わず、手元だけで完結する方法で代替できます。たとえば設定ファイルのあるディレクトリで grep を使い、ホスト名・URL・接続先（IPアドレス、http、DB名など）を拾い出せば、AIに頼らなくても「どこにつながっていそうか」のあたりはつけられます。許可が下りたら使う、という順番で十分間に合います。

③ 今まさに動いているものを把握する

システムは、画面の裏でも動いています。常駐プロセス・定期実行（cron/バッチ）・監視を把握しておくと、「いつの間にか止まっていた」を防げます。

「何が、いつ、勝手に動くか」をリスト化しておくと、障害の切り分けが一気に楽になります。

④ 止まったときの連絡先とエスカレーション先を確認する

中身を理解する前でも、「止まったら誰に何を言うか」さえ決まっていれば、初動は打てます。一人運用ほど、ここが命綱です。

第一報の型がまだ無いなら、初日のうちに簡単なテンプレを用意しておくと、いざという日の自分がぐっと楽になります。

⑤ バックアップの有無と所在、戻し方を確かめる

「もし壊れても戻せる」——この一点があるだけで、引き継ぎ後の毎日の不安はまるで違います。初日に、バックアップの現状を確かめておきます。

戻せる準備の有無が分かれば、これから先「どこまで触っていいか」の判断もしやすくなります。

⑥ 見聞きしたこと・分からないことをメモに残し始める

最後に、今日見たこと・聞いたこと・分からなかったことを、1か所のメモに書き始めます。これが、未来のあなたと次の担当者への引き継ぎ資料の芽になります。

メモは、きれいにまとめようとしなくて大丈夫。「あとで自分が読んで分かる」だけで、初日は十分です。

やってしまいがちな落とし穴

初日は気が張っていて、つい先回りしたくなります。知っているだけで避けられる、よくあるつまずきを先に共有します。

落とし穴はどれも、「触らず・地図を作り・戻せるか確かめる」という初日の方針で、ほとんど受け止められます。

明日、いちばん小さく試せること

全部を初日に終えなくて大丈夫です。引き継いだ翌日、まずひとつだけ試してみてください。

  1. 担当するシステムのログインを、自分の手で一通りたどれるかを確認する（サーバー・管理画面・DB・ドメイン）。
  2. たどれた範囲で、全体像を手書きで1枚に描いてみる(利用者→サーバー→DB→外部連携)。
  3. crontab -l などで、いつ・何が動くかを1つでも控える。
  4. 「止まったら誰に連絡するか」を、一行メモに書く。

この4つができれば、たとえ中身が分からなくても、「止まっても初動は打てる」状態になります。理解は、この足場の上に少しずつ積めば大丈夫です。

「引き継ぎ初日」チェックリスト

その日のうちに、どこまで足場が固まったかを見る項目です。コピーして、自分のメモに当ててみてください。全部に○が付かなくても、空欄が「次にやること」を教えてくれます。

まず最低ライン：今日は ①ログイン確保と⑤バックアップ確認の2つだけでも合格です。通常業務と並行する一人運用の初日に、10項目すべてを消化するのは現実には厳しいもの。残りは「次にやること」リストへ回して大丈夫。権限待ちで確認しきれない項目は、○ではなく「申請中」と書けば、それで前進です。

全部そろわなくて大丈夫です。①のログイン確保と⑤のバックアップ確認だけでも、何も準備しないより、ずっと落ち着いて翌日を迎えられます。

よければ、こちらも

引き継ぎ初日に作った足場は、このあとの障害対応や改修とそのままつながります。「止まっても動ける型」「直す前に影響を見る型」をセットで持っておくと、当日とても楽になります。

引き継ぎ初日に全体像のメモを描き上げ、これなら止まっても動けると前向きな表情を見せる一人運用の保守担当者

作った人がいないシステムを引き継いだ初日が心細いのは、中身が見えないまま、止まったら何もできない気がするからでした。でも、ログインを確保して、全体像を1枚に描いて、戻せるかを確かめておけば、「分からない」と「動けない」は別のことになります。分からなくても、動ける。 今日はまず、自分の手でログインを一通りたどってみるだけで十分です。その一歩が、心細い初日を、落ち着いて始められる初日に変えてくれます。仕様書が無いところから引き継ぐ——それは、あなたが思うよりずっと、丁寧で価値のある仕事です。

ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。

関連用語