引き継ぎの議論は、渡す側の話に偏りがちです。資料をどう作るか、権限をどう整理するか。しかし実際には、受け取る側の進め方で立ち上がりの速さは大きく変わります。
この回は、受け取る側の視点で最初の2週間を扱います。前提として、前任者の時間は限られているものとします。
1. 最初に確保すべき情報
全体像から入りたくなりますが、優先すべきは事故を起こさないための情報です。理解は後から追いつきますが、事故は取り返しがつきません。
- 1触ってはいけないもの — 何を操作すると本番に影響するか
- 2壊れたときの連絡先 — 誰に、どの経路で連絡するか
- 3定期的に動いているもの — いつ何が自動実行されるか
- 4直近で起きた障害 — 何が壊れやすいかが分かる
- 5進行中の作業 — 途中で止まっているものはないか
3番目が抜けると事故ります。知らないうちに何かが動いている状態で作業すると、実行中の処理と衝突します。「毎晩2時に何が動いているか」は最初に押さえてください。定期処理は画面に出てこないため、資料に書かれていなければ存在に気づけません。 があれば把握できますが、無ければ設定を直接読むしかありません。
受け取った直後は、改善したくなる箇所が山ほど見えます。ただし、不自然に見える実装には理由があることが多い。EP.4 で扱った「試して駄目だった案」を知らないまま変更すると、前任者が回避した問題を踏み直すことになります。
2. 質問の質を上げる
前任者の時間は限られています。同じ時間でどれだけ引き出せるかが、質問の作り方で変わります。
| 質問の型 | 得られるもの |
|---|---|
| 「全体を説明してください」 | 一般的な説明。既に資料にある内容 |
| 「この処理は何をしていますか」 | コードを読めば分かる内容 |
| 「ここでこう詰まりました。何を見落としていますか」 | 具体的な不足情報 |
| 「なぜ A ではなく B にしたのですか」 | 判断の理由。資料に無い情報 |
| 「これを変えたら何が壊れますか」 | 依存関係と、過去の失敗 |
下3つが有効です。共通しているのは、自分が手を動かした結果を持って聞いている点です。何もせずに「教えてください」と聞くと、相手も一般的な説明しかできません。
つまり順序としては、まず自分で触って詰まる → その詰まりを質問にする。詰まること自体が、質問の材料を作る作業になります。前任者の側から見ても、具体的な詰まりを持ち込まれるほうが答えやすい。「全体を説明してください」と言われると、どこから話すべきか分からず、結果として一般的な説明になります。
3. 動かしてみる
読むより速いのが、実際に動かしてみることです。ただし本番ではなく、壊してよい場所で。
- 手元で環境を立ち上げる — 手順書どおりに進み、詰まった箇所を記録する
- 定期処理を検証環境で流す — どれくらい時間がかかるかを体感する
- わざと失敗させてみる — エラーがどう出るか、どこに記録が残るか
- 過去の障害を再現してみる — 直近の障害は良い題材になる
3番目は特に価値があります。正常系だけ見ていると、異常時に何が起きるか分かりません。実際に障害対応が必要になったとき、エラーの出方を知っているかどうかで対応速度が変わります。どこに記録が残るかを知らないまま障害を迎えると、探すところから始めることになり、その時間がそのまま復旧の遅れになります。
そして、手順書どおりに進んで詰まった箇所は、そのまま EP.5 で扱った棚卸しの成果になります。受け取る側が詰まりを記録すれば、それが手順書の改善点として渡す側に返せます。
4. 記録しながら進む
受け取った側は、その案件について何も知らない唯一の期間にいます。これは価値のある状態です。何が分かりにくかったかを記録できるのは、この期間だけだからです。
# 引き継ぎメモ（受け取り側）
## 詰まった箇所- [ ] 環境変数 XXX の値が手順書に無い → 前任者に確認、追記済み- [ ] 日次バッチの実行時刻が資料と実際で違う（資料 2:00 / 実際 3:30）- [ ] 検証環境からは外部APIを叩けない（IP制限あり）
## 聞いたこと- Q: なぜ集計をビューにしている？ A: バッチだと当日分が翌朝まで見えないため。件数3倍で再検討
## まだ分からないこと- 月次処理の異常系（今月やってみる）- 特定顧客だけ遅い件の原因
## 気になったが、まだ触らないこと- 中間テーブルが3つあり、1つは使われていなさそう → 参照の記録を確認してから判断する最後の節が要点です。気になったが触らないものを明示的に記録しておくと、理解が進んだ段階で戻ってこられます。その場で手を出さず、しかし忘れない、という状態を作れます。
受け取り中に詰まった箇所は、次の人も同じところで詰まります。記録を残しておけば、次の でそのまま使えます。受け取る側の作業が、渡す側の資産になるという構造です。
5. 権限は必要になってから求める
EP.2 で「足りない状態から始める」と書きましたが、受け取る側でも同じです。最初に全権をもらうと、何が必要か分からなくなります。
加えて、強い権限を持った状態で理解が浅いというのは、事故が起きやすい組み合わせです。読み取りだけで進められる範囲は読み取りだけで進め、書き込みが必要になった時点で依頼するほうが安全です。 は組織の統制の話として語られがちですが、受け取る側自身を守る仕組みでもあります。持っていない権限では事故を起こせません。
| 段階 | 必要な権限 | この段階でやること |
|---|---|---|
| 最初の数日 | 読み取りのみ | コードと記録を読む、構成を把握する |
| 1週目後半 | 検証環境への書き込み | 手順を実行してみる、壊してみる |
| 2週目以降 | 本番の読み取り＋限定的な操作 | 実際の運用に入る |
| 理解が進んでから | 必要な範囲の本番権限 | 変更を加える |
6. 2週間で目指す状態
最後に、到達目標を明確にします。全部を理解するのは非現実的です。目指すのは次の状態です。
- 1事故を起こさない — 触ってはいけないものが分かっている
- 2止まったことに気づける — 何がいつ動くかを把握している
- 3一次対応ができる — 障害時に、少なくとも連絡と状況把握ができる
- 4質問の宛先が分かる — 誰に何を聞けばよいか
- 5分からないことが列挙できている — 未知が既知の未知になっている
5番目が実は最も重要です。何が分からないかが分かっている状態なら、そこから先は時間の問題です。逆に、分からないことが分からない状態では、事故が起きるまで気づけません。
引き継ぎの完了とは、全部を理解した状態ではなく、分からないことを自力で調べられる状態のこと。
最初に確保するのは事故を起こさないための情報（触ってはいけないもの、連絡先、動いているもの）。理解する前に変更しない。質問は自分で詰まってからすると質が上がる。動かして壊してみるのが読むより速い。権限は段階的に。そして受け取り中の記録は、そのまま次の人への資料になります。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。