自分が休んでも止まらない仕組み：一人情シスのための最小引き継ぎ資料
有給申請の画面を開いて、結局そのまま閉じたことがあるかもしれない。休んでいる間に何かが止まったら、対応できるのは自分しかいない——そう分かっているからだ。理由をつけて先送りにするうちに、気づけば何年も連続休暇を取っていない。
これは、抱え込んだ人が悪いわけではない。日々の依頼をひとつずつこなしているうちに、書く時間も、書くための仕組みも用意されないまま知識が一人の頭の中だけに積み上がっていく。引き継げる形になっていないのは、能力の問題ではなく、単に書く機会がなかっただけだ。
この記事では、その状態を変えるための最小限の引き継ぎ資料——何を書けば、自分がいない数日を誰かがしのげるようになるか——を整理する。
TL;DR
| 項目 | 最低ライン |
|---|---|
| 対象範囲 | 止まると困るシステム3〜5個に絞る（全部は不要） |
| 資料の置き場所 | 関係者が見られる場所に1カ所（共有ドライブ・Wiki等） |
| 作成にかける時間 | 半日〜1日（休みの直前に慌てて作るものではない） |
| 認証情報の扱い | 資料に直接書かない。保管場所への参照だけを書く |
| いちばん効くもの | 「まず誰に連絡するか」の1枚だけでも、無いよりずっとましになる |
なぜ一人情シスは休めなくなるのか
多くの中小企業では、IT担当は正式な採用ではなく「なんとなく詳しそうだから」という理由で任されている。最初は小さな作業だった。プリンタの設定、Wi-Fiのトラブル、ちょっとしたExcelの相談。それが少しずつ積み重なり、いつの間にかサーバー・SaaS契約・請求書処理まで、会社のIT関連のほぼすべてが一人の担当範囲になっている。
この積み上がり方には、そもそも「引き継ぎ資料を書く時間」が業務として割り当てられていない、という共通点がある。目の前の依頼をさばくことが優先され、後から誰かが困らないように記録しておく作業は、誰からも指示されないまま後回しになり続ける。気づいたときには、契約の詳細も、パスワードの置き場所も、トラブル対応の勘所も、すべてが一人の記憶の中にしかない状態になっている。
これは属人化した本人の落ち度ではなく、そうなるように積み上がった結果だ。書いてこなかったのではなく、書く時間そのものが最初から用意されていなかった、と捉えるほうが実情に近い。
最小限の引き継ぎ資料に書く5つのこと
完璧な運用ドキュメントを目指す必要はない。目的は「自分が数日いない間、誰かが最低限迷わず動ける」ことだけに絞る。
1. 重要システムの一覧
まず、会社の業務に関わるシステム・SaaSを一覧にする。すべてを網羅する必要はない。「これが止まったら業務が止まる」というものだけで十分だ。
| システム名 | 何のためのものか | 依存している部署 |
|---|---|---|
| 例: 基幹システム | 受発注管理 | 営業・経理 |
| 例: メールサーバー | 社内外の連絡 | 全社 |
| 例: 勤怠管理SaaS | 出退勤・給与連携 | 全社 |
一覧を作るだけで、「そもそも何が動いているか」が本人以外にも見える状態になる。これが無いことが、一人情シスが抜けたときに周囲が何もできなくなる最大の原因になっている。
2. 止まったら困る順
一覧ができたら、優先順位をつける。細かく点数化する必要はなく、次の3段階で足りる。
- 顧客に迷惑がかかる（受発注・請求・問い合わせ対応が止まる）
- 社内業務が止まる（勤怠・経理・社内連絡が止まる）
- 多少遅れても致命的ではない（社内向けの定型作業）
この順位づけがあることで、休んでいる間に何かが起きても、後任者は「まずどれから手をつければいいか」を自分で判断できるようになる。順位が無いと、些細な不具合と重大な障害の区別がつかず、すべてに同じ重さで慌てることになる。
3. 緊急連絡先
トラブルが起きたときにまず連絡すべき先をまとめておく。ここで重要なのは、個人の携帯番号ではなく、法人としてのサポート窓口を優先して書くことだ。
- サーバー・レンタルサーバー会社の法人サポート窓口（電話・メール・契約者番号）
- 主要SaaSベンダーのサポート窓口とプラン種別
- 保守契約がある場合はその契約番号と対応時間帯
担当者個人につながる連絡先だけに頼ると、その担当者が連絡を取れない状況そのものでも詰んでしまう。ベンダー側の窓口を先に書いておくことで、担当者不在でも一次対応が始められる状態になる。
4. 認証情報の保管場所（本文には直接書かない）
引き継ぎ資料に、パスワードやAPIキーそのものを書き込みたくなるかもしれないが、これはやってはいけない。資料が共有ドライブや紙に残る以上、認証情報そのものを書くことは別の大きなリスクを生む。
資料に書くのは「どこに保管されているか」という参照情報だけにする。
- パスワードマネージャー（1Password・Bitwarden等）のどのVaultに入っているか
- 誰がそのVaultへのアクセス権を持っているか
- サーバーの認証情報や環境変数の管理方針は、環境変数とシークレット管理で整理した「直書きしない」原則をそのまま踏襲する
認証情報の管理自体がまだ整っていない場合は、引き継ぎ資料を作る前提として、先にそちらを整理しておくと後々の手間が減る。
5. 「まず誰に連絡すればいいか」の一枚
ここまでの4つを全部揃えられなくても、これだけは先に作っておく価値がある。「何が起きたら」「まず誰に連絡し」「次に何を見るか」を1枚にまとめたものだ。
例:「メールが送受信できない」→ まずメールサーバーのベンダーサポートに連絡 → 次に社内の代替連絡手段（電話・チャット）に切り替える、といった形で、判断の起点だけを示す。
この1枚があるだけで、後任者は「何もわからない」状態から「とりあえず最初の一手は分かる」状態に変わる。全体の資料が未完成でも、この1枚だけは早めに作っておく理由がここにある。
半日〜1日で作れる、現実的な進め方
引き継ぎ資料は、完成度を求めるほど着手が遠のく。現実的な範囲に区切って進める。
- 時間を区切る: 半日、あるいは1日と決めて、その時間内で終わらせる。完璧を目指さない
- 優先順位1位のシステムだけ先に書く: 「止まったら困る順」の一番上から着手し、全部を同時にやろうとしない
- すでに使い慣れた場所に置く: 新しいツールを導入する必要はない。既存の共有ドライブやWikiで十分機能する
- 休みのたびに追記する: 一度で完成させようとせず、実際に休んだときに「これも書いておけばよかった」と思った点を、戻ってきてから追記していく
また、資料を作る過程で、サーバーやSaaSへのアクセス経路が整理されていないことに気づくことも多い。たとえばSSH鍵管理の崩壊パターンと修復手順にあるような、誰がどの鍵でどこにアクセスできるか把握できていない状態は、引き継ぎ資料をいくら書いても後任者が実際に手を動かせない原因になる。同様に、インフラ設定をGitで管理していない会社が必ず経験することにあるとおり、設定がどこにも記録されず本人の手元にしかない状態も、引き継ぎを難しくしている土台の一つだ。時間があれば、これらも合わせて見直すと、引き継ぎ資料そのものの寿命が延びる。
まとめ
一人情シスが休めなくなるのは、書く時間も仕組みも用意されないまま知識が積み上がった結果であり、抱え込んだ本人の責任ではない。引き継げないのは、能力ではなく、書いていないというだけの状態だ。
すべてを整えようとする必要はない。まずは「止まったら困る順」で1位のシステムと、「まず誰に連絡すればいいか」の1枚だけでも用意できれば、休むことへのハードルは確実に下がる。半日あれば、その最初の一歩は形にできる。
引き継ぎ資料をどこから手をつければいいか整理したい場合は、現状のシステム一覧の棚卸しからお手伝いできる。