はじめに：絶望の「過去資料ここにあるから、よろしく」
「これ、過去の案件フォルダここにあるから。適当に見といて。で、よろしく！」
職場に転がっている「マニュアルなき定常業務」。
共有サーバーの奥深くには、過去の対応履歴やExcelファイルが地層のように積み重なっています。
しかし、「どんなトリガーで処理が始まるのか」「納期からどう逆算して工程を組むのか」といった 「フロー」や「判断基準」はどこにも書かれていません。
「ある程度決まった業務なのに、なぜマニュアルやテンプレートがないのか？」
そう嘆きたくなる気持ちは痛いほどわかります。しかし、嘆いていても仕事は進みません。無いのであれば、自分が理解し、自分が最初のマニュアル作成者になるしかないのです。
今回は、このブラックボックス化した業務を紐解き、先輩から効率よく情報を引き出しながら「自分用マニュアル」を構築していくサバイバル術を共有します。
1. 過去資料の「リバースエンジニアリング」
まずは、散乱する過去の遺物（ファイル群）から、業務の「見えない輪郭」を掴みます。
完成品から仕様を推測する、まさにリバースエンジニアリングです。
-
タイムスタンプから「処理の順序」を読む
ファイルの中身ではなく、「更新日時」を時系列に並べてみます。「Aという表が作られた3日後に、Bという申請書が作成されている」といった事実から、見えなかったワークフローが浮かび上がります。 -
成果物の「差分」を見る
複数の過去案件の同じ資料を見比べます。毎回変わっている部分（変数）と、コピペで済んでいる部分（定数）を見極めることで、「どこに頭を使うべきか」がわかります。
2. 質問の質を上げる「仮説構築」アプローチ
過去資料を眺めたら、次は先輩へのヒアリングです。ここで一番やってはいけないのは、「次、何をすればいいですか？」「日程はどう引けばいいですか？」とゼロベースで丸投げすることです。
先輩の頭の中にある「暗黙知」を引き出すには、「仮説」という呼び水が必要です。
- ❌ 悪い聞き方：「納期から逆算したスケジュールはどう立てればいいですか？」
- ⭕ 良い聞き方：「過去資料を見ると、A工程の後に約2週間の空きがあります。今回の納期から逆算すると、来週水曜までにA工程を終わらせるスケジュールで合っていますか？」
間違っていても構いません。具体的な仮説をぶつけることで、先輩は「いや、そこは別部署の承認待ちが絡むから3週間見た方がいいよ」と、 マニュアル化されていない「判断基準」や「例外処理」 をぽろっとこぼしてくれます。
3. パーツを溜めて「チェックリスト」を育てる
先輩から得た知見や、解読したフローは、その日のうちに「パーツ」として記録します。
最初から完璧なWordのマニュアルを作ろうとすると確実に挫折します。
おすすめは、テキストエディタで「消込可能なチェックリスト」を作ることです。
# 〇〇業務フロー・自分用チェックリスト (v0.1)
## 1. 受注時フェーズ
- [ ] 過去案件のフォルダをコピーして雛形を作成する
- [ ] 〇〇部門へ仕様確認のメール送信
※メモ：ここで大体2日待たされるので、早めに投げること！
## 2. スケジュール逆算の基本ルール
- [ ] 最終納期 - 14日：社内レビュー完了
- [ ] 最終納期 - 30日：初期設計（または一次対応）完了
このリストを案件のたびに使い回し、つまずいた点や先輩に指摘された点を追記していくことで、 「生きたマニュアル」 へと進化していきます。
4. おわりに：あなたが「次世代のインフラ」になる
マニュアルがない業務を引き継ぐのは、本当に骨が折れます。
しかし、見方を変えれば、それは 「自分が一番使いやすいように業務フローを再定義（リファクタリング）できるチャンス」 でもあります。
「わからない」と嘆くのではなく、過去のログから仕様を推測し、先輩をデバッガーに見立てて仮説を検証し、小さなチェックリストを残していく。
この過程で培った「業務を体系化し、言語化する力」は、
どんな部署、どんな会社に行っても通用する最強のポータブルスキルになります。
「これ、自分がやめるときはどうやって引き継ぐんだろう…？」
そんな不安を感じたら、今日から少しずつパーツを溜めていきましょう。
あなたが残した小さなチェックリストが、いつか後輩を救う立派なインフラになるはずです。