引き継ぎ資料に必ず入れる「アカウント・連絡先・契約」一覧テンプレート
「引き継ぎ資料、そろそろ作っておかないと」。
そう思ってから、どれくらい経ったでしょうか。 異動の話が出た。後輩が入ることになった。あるいは、ただ漠然と「自分が倒れたらこのシステム誰が見るんだろう」と夜に不安がよぎった。
でも、いざ作ろうとすると手が止まります。 システムの構成、運用の流れ、過去のトラブル……書くことが多すぎて、どこから手をつければいいか分からない。結局「時間があるときに」と後回しになり、また日が過ぎていく。
引き継ぎ資料が進まないのは、あなたがサボっているからではありません。 完璧なものを一気に作ろうとするから、重くて動けないだけです。
だから、まず割り切りましょう。技術的な手順の前に、最初に埋めるべきは「アカウント・連絡先・契約」の3つだけ。自分がいなくなった後、次の人が本当に立ち往生するのは、たいていこの3つが分からないときだからです。この記事では、その3つの項目テンプレートと、無理なく続く作り方を一緒に整理していきます。
結論：引き継ぎ資料は、いきなり全部を書かなくていいです。まず、次の人がいちばん困る「アカウント（どこに何のIDで入るか）」「連絡先（困ったら誰に聞くか）」「契約（誰と何の契約があり、いつ更新か）」の3つを一覧にします。やることは4つ。①この3つを1枚のシートにする、②パスワードそのものは書かず「保管場所」を書く、③思い出せる範囲で埋め、空欄は空欄のまま残す、④何かに気づいたら1行ずつ足す。まずは今日、アカウント一覧の1行目を書くところから始めます。
パスワードや契約情報は機微な情報です。引き継ぎ資料の保管場所・共有範囲は、社内のルールに従って安全に管理してください。この記事は一般的な項目整理の考え方です。自分の環境・会社の規程に読み替えてご確認ください。
なぜ「アカウント・連絡先・契約」が最優先なのか
システムの仕様や運用手順は、時間をかければ現物やコードからある程度たどれます。ログを見て、画面を触って、少しずつ理解していける。
でも、アカウント・連絡先・契約は、知っている人がいなくなると、外から復元するのがとても難しい情報です。
- アカウントが分からないと、そもそも中に入れない：サーバーにログインできない、管理画面のIDが分からない、SSL証明書を管理しているサービスに入れない。手順書があっても、入口の鍵がなければ何もできません。
- 連絡先が分からないと、詰まったときに聞けない：障害が起きた、でもサーバー会社のサポート窓口も、前任者の連絡先も、業務委託先の担当も分からない。一人で抱えて動けなくなります。
- 契約が分からないと、ある日突然止まる：ドメインやSSL証明書の更新契約、サーバーの契約が誰の名義で、いつ切れるか分からない。気づかないうちに期限が来て、ある朝サイトが表示されなくなる——これは実際によく起きる事故です。
つまりこの3つは、「あれば便利」ではなく「なければ次の人が動けなくなる／止まる」情報です。だから、立派な運用ドキュメントを書く前に、まずここから押さえます。
① アカウント一覧：どこに・何のIDで入るか
まず、自分がそのシステムを運用するために「どこにログインしているか」を棚卸しします。ふだん無意識に入っている場所ほど、書き忘れやすいので、思いつくままに挙げていきます。
書く項目は次のとおりです。パスワードそのものは資料に直接書かず、「どこに保管してあるか」を書くのが安全のコツです。
| 項目 | 書くこと |
|---|---|
| サービス／システム名 | 例：本番サーバー、管理画面、ドメイン管理、SSL、監視サービス |
| 用途 | 何のために使うか（1行） |
| ログインURL／接続先 | 管理画面のURL、SSHの接続先など |
| ID（ユーザー名） | ※ここは書いてよいことが多い。会社ルールに従う |
| パスワードの保管場所 | パスワード管理ツール名・金庫・封筒の場所など。パスワード本体は書かない |
| 権限の種類 | 管理者／編集のみ、など |
| 備考 | 二段階認証の有無、認証アプリの端末、注意点 |
思い出しやすくするために、まず「入口」から埋めるのがおすすめです。
- サーバー：本番サーバー、検証・開発サーバーへの接続情報
- ドメイン・DNS：ドメイン管理会社の管理画面、DNSの設定画面
- SSL証明書：証明書を発行・更新しているサービス
- 管理画面（CMS等）：WordPressなどの管理者アカウント
- 監視・外形監視：監視サービス、通知先の設定
- メール・通知：障害通知が飛ぶメールアドレスやチャット
- クラウド・外部サービス：利用しているクラウド、決済、外部API など
二段階認証の落とし穴：二段階認証（ログイン時にIDとパスワードに加えて、スマホアプリの数字などもう一つの確認を求める仕組み）は安全ですが、その認証用アプリが前任者のスマホにしか入っていないと、退職した瞬間にログインできなくなります。「認証はどの端末・どのアプリか」「バックアップコードはどこか」も、必ず備考に残しておきます。
② 連絡先一覧：困ったら誰に聞くか
システムは自分だけで完結していません。詰まったとき、壊れたとき、誰に連絡すればいいか——それが分からないと、次の人は障害の夜に電話帳もないまま放り出されます。
「相手」「用件」「連絡方法」をセットで残します。
| 相手 | 書くこと |
|---|---|
| サーバー・インフラ会社 | サポート窓口、契約者名、問い合わせ方法、対応時間 |
| ドメイン・SSLの会社 | 更新・障害時の連絡先 |
| 開発・制作会社／業務委託先 | 誰に・何を頼めるか、担当者名、緊急時の連絡先 |
| 社内の関係者 | このシステムの責任者、決裁できる人、業務側の窓口 |
| 前任者・詳しい人 | 「これは○○さんが詳しい」という属人情報も正直に書く |
| 監視・アラートの通知先 | どこに通知が飛ぶか、鳴ったら誰が見るか |
ポイントは、「会社名」だけでなく「その障害のとき、実際にどう連絡が取れるか」まで書くことです。夜間や休日に連絡がつくのか、平日日中だけなのか。ここが分かっているだけで、いざというときの安心感がまるで違います。
社内の「このシステム、業務としては誰の担当か」も忘れず入れておきます。技術は分かっても、「止めていいのか」「いつ作業していいのか」を判断できる人が分からないと、次の人は動けません。
③ 契約一覧：誰と・何の契約が・いつ切れるか
いちばん見落とされやすく、いちばん静かに事故を起こすのが契約です。契約は、誰も触っていなくても、期限が来れば勝手に切れます。
- ドメインの有効期限が切れて、サイトが表示されなくなった
- SSL証明書の更新契約が切れて、ブラウザに警告が出た
- サーバーの契約更新に気づかず、データごと止まった
これらは「担当が代わって、更新のメールに誰も気づかなかった」ときに起こります。だから、契約は必ず一覧にして、期限を見える化しておきます。
| 項目 | 書くこと |
|---|---|
| 契約の対象 | ドメイン、SSL、サーバー、監視、外部サービス、保守委託 など |
| 契約先（会社名） | どこと契約しているか |
| 契約者・名義 | 会社名義か、個人名義か（個人名義は退職時に要注意） |
| 更新時期・期限 | いつ切れるか、自動更新か手動更新か |
| 支払い方法 | クレジットカード（誰の）、請求書払い など |
| 更新の通知先 | 更新案内のメールがどこに届くか |
| 費用 | だいたいの金額（予算・棚卸しの参考に） |
とくに注意したいのは、支払いに使っているクレジットカードや、更新通知の届くメールアドレスが「前任者個人のもの」になっているケースです。その人が退職すると、カードが失効して契約が止まったり、更新案内に誰も気づかなくなったりします。名義と通知先が「個人」になっている契約は、引き継ぎのタイミングで会社のものへ切り替える相談をしておくと安心です。
具体例：この3枚があった引き継ぎと、なかった引き継ぎ
同じ「担当者が代わる」でも、この3枚があるかないかで、次の人の最初の数か月がまるで違います。
- 3枚がなかった引き継ぎ：後任者は、まずログインできる場所を手探りで探すところから始める。障害が起きても連絡先が分からず、社内を走り回って前任者の私物メモを探す。数か月後、ある朝ドメインが切れてサイトが停止。誰も更新通知に気づいていなかった。技術力の問題ではなく、情報がなかっただけで、事故が積み重なる。
- 3枚があった引き継ぎ：後任者は、アカウント一覧を見て必要な場所にログインし、まず全体を把握。障害時は連絡先一覧のサポート窓口にすぐ連絡できる。契約一覧のおかげで、更新期限をカレンダーに入れ直し、期限切れを未然に防げた。分からないことは残っていても、「どこに聞けば・どこを見れば分かるか」の地図があるだけで、落ち着いて立ち上がれる。
差を生んだのは、資料の分厚さではありません。次の人が本当に困る3つを、先に押さえてあったかだけです。
影響：3枚を持つと、今の自分も軽くなる
この3枚は、次の人のためだけのものではありません。作ることで、今のあなた自身の運用も静かになります。
- 「自分しか分からない」不安が減る：倒れたら、休んだら、と考えたときの重さが軽くなる。堂々と休める。
- 期限切れ事故を自分でも防げる：契約一覧を作る過程で、忘れていた更新期限に自分が気づける。
- 棚卸しになる：「あれ、このアカウントもう使ってないな」「この契約、実は不要かも」と、無駄や退職者アカウントの残骸に気づける。
- 引き継ぎの初日が短くなる：いざ人が代わるとき、ゼロから説明しなくて済む。渡す側も、受ける側も楽になる。
逆に、この3つが頭の中だけにあると、システムは「あなたが健康で在籍している間しか安全に回らない」状態が続きます。1枚ずつ外に出しておくことは、次の人への配慮であると同時に、今の自分を守る備えでもあります。
明日やること：アカウント一覧の「1行目」を書く
引き継ぎ資料を「ちゃんと作ろう」と構えると、たいてい動けません。おすすめは、いちばんよく使う入口を、1行だけ書いてみることです。
- テキストファイルでも表計算でもいいので、1枚シートを用意する。
- 上に「サービス／用途／URL／ID／パスワード保管場所／権限／備考」の見出しを置く。
- 今日いちばん最近ログインした場所（たとえば本番サーバーや管理画面）を、1行目に書く。
- パスワードは書かず、「保管場所」だけ書く。二段階認証があれば備考にメモする。
- 明日また1つ、思い出した入口を足す。連絡先・契約は、思い出したときに別シートへ。
これで、引き継ぎ資料の「いちばん大事な1枚」の初版が動き出します。一気に完成させる必要はありません。運用しながら、気づいたアカウント・連絡先・契約を1行ずつ足していく。それだけで、数週間後には「人に渡せる3枚」ができています。
引き継ぎ資料チェックリスト（アカウント・連絡先・契約）
作るとき・見直すときに、抜けがないかを確かめる項目です。コピーして使ってください。まずは「これだけは」の3つから。
これだけは（最低ライン）
- 本番サーバー・主要な管理画面に「どこから・どのIDで」入るかが書いてあるか
- 障害時に連絡するサポート窓口が、少なくとも1つ書いてあるか
- ドメイン・SSL・サーバーの更新期限が、どこかに見える形であるか
アカウント（任意で追加）
- パスワード本体を資料に直書きせず、「保管場所」を書いているか
- 二段階認証の有無・認証端末・バックアップコードの場所を残したか
- サーバー／ドメイン／SSL／CMS／監視／外部サービスの入口を一通り拾ったか
- もう使っていない・退職者のアカウントが混ざっていないか確認したか
連絡先（任意で追加）
- インフラ・ドメイン・制作/委託先・社内責任者の連絡先があるか
- 夜間・休日に連絡が取れるかどうかまで書いてあるか
- アラート通知がどこに飛ぶか、鳴ったら誰が見るかが分かるか
契約（任意で追加）
- 契約の名義（会社／個人）と、更新が自動か手動かが書いてあるか
- 支払いカードや更新通知の届く先が「個人のもの」になっていないか
- 更新期限をカレンダーやリマインダーに登録したか
全部に○が付かなくても大丈夫です。上の3つがあれば、次の人が入口で立ち往生することは、ぐっと減ります。残りは運用しながら少しずつ足していけば十分です。
よければ、こちらも
引き継ぎは、この3枚を土台に、運用ドキュメントや構成情報とつなげていくと、さらに渡しやすくなります。あわせて整えておくと安心です。
- 運用ドキュメントに最低限書くべき項目テンプレート：アカウント・連絡先・契約の次に整えたい、運用全体のドキュメントの最低ラインです。
- サーバー・サービスの構成情報を1枚にまとめる方法：「どこに何があるか」の構成図を1枚持つと、引き継ぎがさらに軽くなります。
- 退職者アカウントの棚卸しと権限の最小化：アカウント一覧を作る過程で見つかる「使っていないアカウント」の片づけ方です。
- 作った人がいないシステムを引き継いだ初日にやること：受け取る側の視点。渡す資料に何を入れると助かるかの逆引きにもなります。
引き継ぎ資料が進まないのは、あなたの段取りが悪いからではありません。全部を一度に、と思うから重いだけです。次の人が本当に困る3つ——アカウント・連絡先・契約——から、1行ずつ書いていけば大丈夫です。 今日は、いちばんよく使う入口を1行書くだけで十分です。その1枚が、いつか人が代わる日の自分と、次の誰かを、静かに助けてくれます。
ほかの実務ヒントは記事一覧からどうぞ。保守運用の小さな備えを、メールでも少しずつお届けしています。