引き継ぎ資料の書き方｜システム保守テンプレートとチェック表

システム保守の引き継ぎ資料とは、担当者が替わっても同じ品質でシステムを動かし続けられるように、「何があり・どこにあり・どう動かし・困ったら誰に聞くか」を一冊にまとめた文書です。業務の引き継ぎ書と違うのは、環境やアカウント、リポジトリ、デプロイ、監視、障害対応、外部サービスの契約といった「システム固有の持ち物」を漏れなく渡す必要がある点です。そして、資料を渡すだけでは完了せず、受け取る側が1人で作業できることを確認して初めて引き継ぎが終わります。

この記事では、システム保守で渡すものの一覧表、コピペで使える Markdown テンプレートと、架空の「社内向け備品管理システム」の記入例、並走期間を含む進め方と「やってみせる → やってもらう」確認表、シークレット（パスワードや API キー）の安全な渡し方、引き継ぎ漏れチェックリスト30項目と受け取る側の確認質問リストをまとめます。チェックリストの進み具合や .env のキーの差分を数える小さなスクリプトも、実行結果つきで載せました。

システム保守の引き継ぎで渡すもの一覧

まずはこの表の11項目がそろっているかを確認します。「形式」と「受け取れたかの確認方法」まで決めておくと、渡したつもり・受け取ったつもりを防げます。

引き継ぎ資料と、ほかの文書との役割分担

引き継ぎ資料は「全部を書き直す文書」ではなく、「どこに何があるかを示し、足りない部分を補う文書」です。すでにある文書は、引き継ぎ書からリンクして使います。

運用設計書、リリース手順書、障害報告書、README の書き方は、それぞれの記事で詳しく扱っています。この記事では、それらを「どう束ねて渡すか」と「受け取る側が1人でできるまでの進め方」に絞ります。

引き継ぎ書にしか書けないのは、次のような「文書になっていない知識」です。

• 経緯：なぜこの構成なのか、なぜこの設定値なのか（例：夜間バッチが 2:00 ではなく 3:30 なのは、バックアップと重ならないようにするため）
• 判断：どこまでなら1人で判断してよいか、誰の承認が必要か
• 注意点：手順書どおりにやるとつまずく箇所、時期によって変わる作業量
• 人：誰に何を聞けばよいか、利用部門の窓口の人柄や連絡しやすい時間帯

引き継ぎ書の構成

次の12章で構成すると、上の一覧表の11項目をすべて収められます。

コピペ用 Markdown テンプレート

そのまま貼って、{ } の部分を埋めて使えるテンプレートです。Markdown で書いておくと、リポジトリや社内 Wiki で差分を見ながら更新できます。

# 引き継ぎ書：{システム名}

## 0. 基本情報
| 項目 | 内容 |
|---|---|
| システム名 | {システム名} |
| 引き継ぎ元 | {氏名・所属} |
| 引き継ぎ先 | {氏名・所属} |
| 引き継ぎ期間 | {開始日} 〜 {完了日}（並走期間：{開始日} 〜 {終了日}） |
| 承認者 | {氏名} |
| 文書の最終更新日 | {YYYY-MM-DD} |

## 1. システム概要
- 目的：{何のためのシステムか}
- 利用者：{部署・人数の目安}
- 主な機能：{機能を3〜5個}
- 利用時間帯：{平日 9:00〜18:00 など}
- 止まったときの影響：{誰が何をできなくなるか}

## 2. 構成
- 構成図：{リンク}
- 技術とバージョン：{言語・フレームワーク・DB・OS とバージョン}
- 外部連携：{連携先と方式}

## 3. 環境・アカウント台帳
| 環境 | URL | サーバー・サービス | アカウントの発行方法 | 権限の申請先 |
|---|---|---|---|---|
| 本番 | {URL} | {ホスト名・サービス名} | {方法} | {申請先} |
| 検証 | {URL} | {ホスト名・サービス名} | {方法} | {申請先} |

- シークレットの保管場所：{パスワード管理ツールの保管庫名・シークレット管理サービスのパス}（値はここに書かない）
- 引き継ぎ元のアカウントの扱い：{停止日・権限の削除日}

## 4. リポジトリとブランチ運用
| リポジトリ | 内容 | URL | README |
|---|---|---|---|
| {名前} | {アプリ／インフラ定義など} | {URL} | {リンク} |

- ブランチ：{main・develop・`feature/*` などの使い方}
- レビュー：{必要な承認数、誰がレビューするか}
- タグ・バージョン：{付け方}

## 5. ビルド・デプロイ
- リリース手順書：{リンク}
- CI/CD：{サービスと設定ファイルの場所}
- 切り戻し：{方法と判断基準のリンク}

## 6. 定期作業
| 頻度 | 作業 | 手順書 | 所要時間 | 次回予定日 |
|---|---|---|---|---|
| 日次 | {作業} | {リンク} | {分} | ― |
| 月次 | {作業} | {リンク} | {分} | {日付} |
| 年次 | {作業} | {リンク} | {分} | {日付} |

## 7. 監視・障害対応
- 監視ダッシュボード：{リンク}
- アラートの通知先：{チャンネル・メール}
| アラート | 意味 | 一次対応 | エスカレーション |
|---|---|---|---|
| {名前} | {何が起きているか} | {まずやること} | {誰に・どの条件で} |

- 過去の障害（読む順）：{障害報告書へのリンクを重要な順に}

## 8. 問い合わせ対応
- 窓口：{問い合わせが届く場所}
- 対応の期限：{一次回答の目安}
| よくある問い合わせ | 回答・対応 |
|---|---|
| {内容} | {回答} |

## 9. 未解決の課題・注意点
| 課題 | 状態 | 優先度 | 経緯・メモ | チケット |
|---|---|---|---|---|
| {内容} | {調査中など} | {高・中・低} | {なぜ残っているか} | {リンク} |

- 経緯のメモ：{設定値や構成の理由}

## 10. 関係者・外部サービス
| 役割 | 氏名・窓口 | 連絡手段 | 備考 |
|---|---|---|---|
| {利用部門の窓口} | {氏名} | {チャット・メール} | {連絡しやすい時間帯} |

| 外部サービス | 用途 | 契約者 | 更新日 | 支払い方法 | 管理画面 |
|---|---|---|---|---|---|
| {サービス名} | {用途} | {部署} | {YYYY-MM-DD} | {請求書など} | {リンク} |

## 11. 引き継ぎの進め方と確認
| 作業 | やってみせる（日付） | 一緒にやる（日付） | やってもらう（日付） | 確認者 |
|---|---|---|---|---|
| {作業} | {日付} | {日付} | {日付} | {氏名} |

- [ ] {チェック項目}
- 残課題：{引き継ぎ完了時点で残るもの}

記入例：社内向け備品管理システム

架空の「社内向け備品管理システム」で、テンプレートを埋めた例です。ノートPCやモニターなどの備品を、貸出・返却・棚卸しで管理する社内システムを想定しています。

# 引き継ぎ書：備品管理システム

## 0. 基本情報
| 項目 | 内容 |
|---|---|
| システム名 | 備品管理システム（社内名：Bihin） |
| 引き継ぎ元 | 鈴木（情報システム課） |
| 引き継ぎ先 | 高橋（情報システム課） |
| 引き継ぎ期間 | 2026-10-01 〜 2026-11-13（並走期間：2026-10-19 〜 2026-11-13） |
| 承認者 | 佐藤（情報システム課 課長） |
| 文書の最終更新日 | 2026-10-01 |

## 1. システム概要
- 目的：社内のPC・モニター・会議室機材の貸出と棚卸しを管理する
- 利用者：全社員（貸出申請）、総務課 3名（承認・棚卸し）
- 主な機能：貸出申請と承認、返却登録、備品台帳、月次棚卸し、CSV 出力
- 利用時間帯：平日 9:00〜19:00（夜間はバッチのみ）
- 止まったときの影響：新しい貸出の申請ができない。返却は紙の記録で一時対応できる

## 2. 構成
- 構成図：docs/architecture.md（Mermaid）
- 技術とバージョン：Python 3.12 / Django 5.2、PostgreSQL 16、Nginx、Ubuntu 24.04
- 外部連携：社内の認証基盤（SSO）、メール配信サービス（通知メール）

## 3. 環境・アカウント台帳
| 環境 | URL | サーバー・サービス | アカウントの発行方法 | 権限の申請先 |
|---|---|---|---|---|
| 本番 | https://bihin.example.internal | app01 / db01 | SSO で自動 | 佐藤課長の承認 → 情報システム課 |
| 検証 | https://bihin-stg.example.internal | stg01 | SSO で自動 | 情報システム課内で付与 |

- シークレットの保管場所：パスワード管理ツールの保管庫「Bihin-運用」（値はここに書かない）
- 引き継ぎ元のアカウントの扱い：2026-11-30 に本番サーバーの sudo 権限を削除

## 4. リポジトリとブランチ運用
| リポジトリ | 内容 | URL | README |
|---|---|---|---|
| bihin-app | アプリ本体 | https://git.example.internal/it/bihin-app | あり |
| bihin-infra | サーバー設定（Ansible） | https://git.example.internal/it/bihin-infra | あり |

- ブランチ：main が本番。作業は `feature/*`、緊急修正は `hotfix/*`
- レビュー：1名の承認で main へマージ
- タグ・バージョン：本番反映時に v1.4.0 の形式でタグを付ける

## 5. ビルド・デプロイ
- リリース手順書：docs/release.md
- CI/CD：main へのマージで検証環境へ自動デプロイ。本番はタグを付けて手動承認
- 切り戻し：1つ前のタグを再デプロイ。DB 変更がある場合はリリース手順書の切り戻し欄に従う

## 6. 定期作業
| 頻度 | 作業 | 手順書 | 所要時間 | 次回予定日 |
|---|---|---|---|---|
| 日次 | バックアップ成功の確認（監視画面） | docs/ops/backup.md | 5分 | ― |
| 月次 | 退職者・異動者のアカウント棚卸し | docs/ops/account-review.md | 30分 | 2026-10-30 |
| 月次 | OS のセキュリティ更新（検証 → 本番） | docs/ops/patch.md | 60分 | 2026-10-21 |
| 年次 | SSL 証明書の更新 | docs/ops/cert.md | 30分 | 2026-12-15 |

## 7. 監視・障害対応
- 監視ダッシュボード：監視ツールの「Bihin」ダッシュボード
- アラートの通知先：チャットの #it-bihin-alert、夜間はメール
| アラート | 意味 | 一次対応 | エスカレーション |
|---|---|---|---|
| HTTP 5xx 率 5% 超 | アプリのエラーが増えている | 直近のデプロイ有無を確認し、あれば切り戻しを検討 | 15分で改善しなければ佐藤課長へ |
| ディスク使用率 85% 超 | ログか CSV 出力が増えている | docs/ops/disk.md の手順で古いログを圧縮 | 95% 超なら即時連絡 |
| バックアップ失敗 | 夜間バックアップが完了していない | ジョブのログを確認し、手動で再実行 | 2回続けて失敗したら連絡 |

- 過去の障害（読む順）：2026-03 証明書の期限切れ → 2025-11 ディスク満杯 → 2025-06 SSO 連携の設定変更

## 8. 問い合わせ対応
- 窓口：チャットの #it-helpdesk（総務課からの問い合わせが中心）
- 対応の期限：一次回答は当日中
| よくある問い合わせ | 回答・対応 |
|---|---|
| 返却したのに「貸出中」のまま | 総務課が返却登録を忘れていることが多い。総務課に確認を依頼 |
| CSV が文字化けする | Excel で開く場合は「データ」→「テキストから」で UTF-8 を指定 |

## 9. 未解決の課題・注意点
| 課題 | 状態 | 優先度 | 経緯・メモ | チケット |
|---|---|---|---|---|
| 棚卸し画面が 3,000件超で遅い | 調査中 | 中 | 一覧でページ分割をしていない | #182 |
| Django 6 系への更新 | 保留 | 低 | 5.2 はサポート期間内。来年度に計画 | #175 |

- 経緯のメモ：夜間バッチが 3:30 開始なのは、2:00〜3:00 の DB バックアップと重ならないようにするため

## 10. 関係者・外部サービス
| 役割 | 氏名・窓口 | 連絡手段 | 備考 |
|---|---|---|---|
| 利用部門の窓口 | 田中（総務課） | チャット | 月末は棚卸しで忙しい |
| インフラ担当 | 情報システム課 基盤チーム | #it-infra | サーバー再起動は事前連絡 |

| 外部サービス | 用途 | 契約者 | 更新日 | 支払い方法 | 管理画面 |
|---|---|---|---|---|---|
| SSL 証明書 | HTTPS | 情報システム課 | 2026-12-15 | 請求書 | 証明書サービスの管理画面 |
| メール配信サービス | 通知メール | 情報システム課 | 2027-03-31 | 請求書 | サービスの管理画面 |
| ドメイン | example.internal の外部向け | 総務課 | 2027-05-20 | 請求書 | レジストラの管理画面 |

記入のコツ

引き継ぎの進め方

期間の目安と並走期間

引き継ぎ期間は「資料の説明」だけでなく、「受け取る側がひと通りの作業を1回ずつ担当する時間」を含めて組みます。月次作業を1回経験するには最低1か月かかるため、並走期間（引き継ぎ元と受け取る側が両方いる期間）に月次の作業日を入れることが大切です。

期間はシステムの規模や体制で変わるので、「何を何回、受け取る側が担当できたか」で完了を判断します。

gantt
  title 備品管理システムの引き継ぎ（例）
  dateFormat YYYY-MM-DD
  section 準備
  資料の作成・更新            :a1, 2026-10-01, 10d
  アカウント・権限の発行       :a2, 2026-10-05, 5d
  section 説明
  全体説明・構成図の読み合わせ  :b1, 2026-10-13, 3d
  リポジトリ・デプロイの説明    :b2, 2026-10-15, 3d
  section 並走
  やってみせる・一緒にやる      :c1, 2026-10-19, 10d
  やってもらう（引き継ぎ元は見守り） :c2, 2026-10-29, 12d
  section 完了
  完了確認・権限整理           :d1, 2026-11-10, 4d

「やってみせる → 一緒にやる → やってもらう」確認表

作業ごとに3段階で進め、受け取る側が1人でできた日を記録します。資料を読んだだけの状態と、1人で作業できた状態を区別するための表です。

アラート対応のように本番で起きるのを待てない作業は、過去の障害報告書を題材に説明したり、検証環境で疑似的にアラートを出したりして練習します。本番リリースや年次作業のように引き継ぎ期間中に1回しかない作業は、「一緒にやる」までを完了条件とし、次回は引き継ぎ元に相談できるようにしておきます。

シークレット（パスワード・API キー）の渡し方

パスワードや API キーなどのシークレットは、引き継ぎ書やチャット、メールに値を書かずに渡します。引き継ぎ書には「どこにあるか」と「どう発行・更新するか」だけを書きます。

値を渡した後にやること

1. 引き継ぎ元だけが知っていた値は、引き継ぎ完了後に更新（ローテーション）する。更新の手順書がない場合は、引き継ぎ期間中に一緒に作ります。
2. 引き継ぎ元の個人アカウント・権限を、決めた日に停止・削除する。台帳の「引き継ぎ元のアカウントの扱い」に日付を書いておきます。
3. 共有アカウントが残っている場合は、個人アカウントへの切り替えを未解決の課題に入れる。

.env などの設定ファイルは、値ではなく「キーの一覧」を突き合わせます。次のスクリプトは、リポジトリにある .env.example と実際の環境のファイルのキー名だけを比べ、値は表示しません（Python 3.11、標準ライブラリのみ）。

# env_keys.py
""".env.example と実際の .env のキー（名前だけ）を比べる。値は表示しない。"""
import sys
from pathlib import Path

def keys(path: str) -> set[str]:
    out = set()
    for line in Path(path).read_text(encoding="utf-8").splitlines():
        line = line.strip()
        if line and not line.startswith("#") and "=" in line:
            out.add(line.split("=", 1)[0].strip())
    return out

example, actual = keys(sys.argv[1]), keys(sys.argv[2])
print("example にあり実環境にない:", sorted(example - actual) or "なし")
print("実環境にあり example にない:", sorted(actual - example) or "なし")

ダミーの値を入れた .env.example（DATABASE_URL・MAIL_API_KEY・STORAGE_BUCKET・SESSION_SECRET）と .env.production（DATABASE_URL・MAIL_API_KEY・SESSION_SECRET・LEGACY_EXPORT_TOKEN）で実行した結果です。

$ python3 env_keys.py .env.example .env.production
example にあり実環境にない: ['STORAGE_BUCKET']
実環境にあり example にない: ['LEGACY_EXPORT_TOKEN']

「実環境にあり example にない」キーは、文書に書かれていない設定です。何に使っているのかを引き継ぎ元に確認し、.env.example と引き継ぎ書に追記します。逆に「example にあり実環境にない」キーは、既定値で動いているのか、設定漏れなのかを確認します。

リポジトリの状況を把握する Git コマンド

受け取る側は、引き継ぎの初日にリポジトリの「今の状態」を把握しておくと、質問が具体的になります。次のコマンドは、架空の備品管理システムのリポジトリを模したデモで実行した結果です（git 2.43.0）。

$ git shortlog -sn --all            # 誰がどれだけコミットしているか
     4  鈴木
     1  佐藤
$ git branch -a --sort=-committerdate --format='%(refname:short) %(committerdate:short) %(authorname)'
main 2026-09-25 佐藤
hotfix/login-timeout 2026-09-05 鈴木
$ git tag --sort=-creatordate       # 本番に出たバージョン
v1.4.0
$ git branch --no-merged main       # main に入っていないブランチ
  hotfix/login-timeout
$ git log --since=2026-09-01 --oneline --all   # 最近の変更
baa6aa8 chore: 依存更新
585b0db fix: ログインのタイムアウト

git branch --no-merged main に出たブランチは、そのまま「確認質問」になります。この例では hotfix/login-timeout が main に入っていないので、「本番に反映済みか、不要になったか、作業途中か」を引き継ぎ元に確認し、未解決の課題に記録します。

引き継ぎ漏れチェックリスト30項目

引き継ぎ完了の前に、この30項目を引き継ぎ元と受け取る側の2人で確認します。「はい」と言えない項目は、未解決の課題として残すか、完了日を延ばして対応します。

チェックリストの進み具合を数えるスクリプト

引き継ぎ書の中のチェックリスト（- [ ]・- [x]）を Markdown で管理すると、進み具合と未記入の箇所を機械的に数えられます。次のスクリプトは、完了数・未完了の項目・「（未記入）」「TODO」「TBD」の残っている行を表示します（Python 3.11、標準ライブラリのみ）。

# check_handover.py
"""引き継ぎ書（Markdown）のチェックリスト進捗と未記入箇所を数える。Python 3.11 標準ライブラリのみ。"""
import re
import sys
from pathlib import Path

path = Path(sys.argv[1] if len(sys.argv) > 1 else "handover.md")
text = path.read_text(encoding="utf-8")

done = re.findall(r"^\s*- \[[xX]\] (.+)$", text, re.M)
todo = re.findall(r"^\s*- \[ \] (.+)$", text, re.M)
total = len(done) + len(todo)
print(f"チェックリスト: {len(done)}/{total} 完了 ({len(done) / total:.0%})" if total else "チェック項目なし")
for item in todo:
    print(f"  未完了: {item}")

blanks = [(n, line.strip()) for n, line in enumerate(text.splitlines(), 1)
          if re.search(r"（未記入）|TODO|TBD|xxx", line)]
print(f"未記入: {len(blanks)} 件")
for n, line in blanks:
    print(f"  {path.name}:{n}: {line}")
sys.exit(1 if todo or blanks else 0)

8項目中4項目に x を付け、未記入の行を2つ残した handover.md で実行した結果です。

$ python3 check_handover.py handover.md; echo "exit=$?"
チェックリスト: 4/8 完了 (50%)
  未完了: 検証環境へのデプロイを受け取る側が1人で実施した
  未完了: 月次のアカウント棚卸しを一緒に実施した
  未完了: アラート発生時の一次対応を受け取る側が1人で実施した
  未完了: SSL 証明書の更新日（2026-12-15）をカレンダーに登録した
未記入: 2 件
  handover.md:14: - バックアップの保存期間：（未記入）
  handover.md:15: - 外部メール配信サービスの契約更新日：TODO
exit=1

未完了・未記入があると終了コード 1 を返すので、週1回の引き継ぎ定例でこの出力を共有したり、CI で文書の更新時に確認したりできます。

受け取る側の確認質問リスト

受け取る側から質問すると、文書に書かれていない知識が引き出せます。引き継ぎ元が「当たり前」と思っていることほど文書に残りにくいので、次の質問を順に聞いていきます。

質問の答えは、その場で引き継ぎ書の該当する章に追記します。口頭のやり取りだけで終わらせず、次に担当が替わるときにも使える形にしておきます。

よくあるつまずきと対策

よくある質問

Q. 引き継ぎ資料は、引き継ぎ元と受け取る側のどちらが書くものですか？ A. 骨組みと事実（環境・アカウント・契約など）は引き継ぎ元が書き、説明を受けながら受け取る側が追記・修正する分担がおすすめです。受け取る側が自分の言葉で書き足すと、理解できていない箇所がはっきりし、次の担当者にも伝わりやすい文書になります。

Q. 引き継ぎ期間が短く、並走期間を取れません。 A. 優先順位を「止まると困る作業」から付けます。障害の一次対応、デプロイと切り戻し、直近の定期作業と更新日の3つを先に「やってもらう」まで進め、それ以外は引き継ぎ書と確認質問リストで補います。引き継ぎ後に相談できる期間と方法を決めておくと、短い期間でも安心して担当を替えられます。

Q. Excel と Markdown のどちらで作るのがよいですか？ A. どちらでも項目がそろっていれば機能します。システム保守では、リポジトリや Wiki で Markdown 管理すると、構成やコードの変更と同じタイミングで更新でき、差分も追いやすくなります。チェックリストを - [ ] 形式にしておけば、この記事のスクリプトのように進み具合も数えられます。

Q. 引き継ぎが完了したと判断する基準は？ A. 「チェックリスト30項目がはい」「確認表の主な作業に『やってもらう』の日付が入った」「残課題が一覧になり、承認者が確認した」の3つをそろえて完了とするのが分かりやすい基準です。

まとめ

• 引き継ぎ資料は 「何が・どこに・どう動かし・誰に聞くか」の地図 で、既存の運用設計書・リリース手順書・障害報告書・README へリンクして束ねる
• 渡すものは 環境・アカウント台帳から外部サービスの契約・更新日までの11項目。受け取れたかの確認方法まで決める
• 引き継ぎ書にしか書けないのは 経緯・判断・注意点・人 の4つ
• 進め方は やってみせる → 一緒にやる → やってもらう。並走期間に月次作業を1回入れる
• シークレットは 値を書かずに保管場所と権限で渡し、引き継ぎ後に更新。.env はキー名だけ突き合わせる
• 完了前に チェックリスト30項目と受け取る側の確認質問 で漏れを拾う
• 引き継ぎ書は 作って終わりにせず、変更と同時に更新する文書 として育てる

株式会社RJCでは、システムを次の担当者へ確実に渡すための文書づくりを仲間と学び合っています。こうした知識を共有しながら、日々技術を磨いています。

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。