「Runbookがない」は属人化の最大要因
情シスの業務は属人化しやすい構造を持っています。判断業務が多く、毎回少しずつ条件が違い、暗黙知に頼りやすいからです。属人化が進むと、退職時の引き継ぎコストが膨らみ、休暇取得が難しくなり、新メンバーが立ち上がりません。
本記事では、属人化を防ぐRunbook（運用手順書）の標準テンプレートと、書きっぱなしにしない運用ルールを提示します。
Runbookで書くべき業務の見極め
すべての業務をRunbook化する必要はありません。以下の優先順位で取り組みます。
| 優先度 | 業務の特徴 | 例 |
|---|---|---|
| ★★★（必須） | 頻度が高い／影響範囲が広い／緊急度が高い | 入社時アカウント発行、PCトラブル対応、ランサムウェア初動 |
| ★★（重要） | 頻度は低いが、ミスると影響が大きい | テナント管理者引継ぎ、ライセンス更新、監査対応 |
| ★（任意） | 頻度が低く、影響も小さい | 会議室予約システムの設定変更、複合機トナー交換 |
標準テンプレート（Runbookの構造）
すべてのRunbookで以下の8セクションを統一します。読み手は「どこに何が書いてあるか」を覚える必要がなくなり、書き手も迷わずに済みます。
セクション構成
- 目的：この手順は何のためか（1〜2行）
- 適用範囲：いつ、誰が、どの条件で使うか
- 所要時間・頻度：標準所要時間と実施頻度
- 必要権限・前提：必要な管理者権限、事前準備、関連サービス契約
- 手順：番号付きステップ、各ステップにスクリーンショット
- 確認事項：完了後にチェックすべきこと（5〜7項目）
- 例外・トラブルシューティング：よくある失敗とその対処
- 関連情報：関連Runbook、関連ドキュメントのリンク
サンプル：M365ユーザー作成Runbook（抜粋）
目的：新入社員が初日からM365を業務利用できる状態にする。
適用範囲：入社1週間前〜前日に情シス担当が実施。
所要時間：1名あたり15分。
頻度：採用に応じて随時。
必要権限：M365 グローバル管理者またはユーザー管理者。
前提：人事から発行依頼書（部署、役職、氏名、メールエイリアス希望）を受領済み。
手順：
1. Entra ID 管理センターを開く
2. ユーザー > 新しいユーザー > 内部ユーザーの作成
3. ユーザー名・表示名・部署・役職を入力
4. パスワードを発行（自動生成 or 一時パスワード）
5. ライセンスを割当て（M365 Business Premium）
6. グループに追加（部署別配信リスト、共有メールBOX）
7. パスワード初期通知を発行（暗号化PDFまたは口頭）
確認事項：サインイン可能、メール送受信可能、Teams参加可能、ライセンス未消費警告なし、MFA初期設定が促される
例外：ライセンス枯渇時は管理本部長承認のもとで追加購入
命名規則と保管場所
ファイル命名規則
RB-[カテゴリ]-[番号]-[業務名]-v[バージョン] の形式で統一します。例：
RB-AC-001-M365ユーザー作成-v1.2（AC = Account）RB-SE-005-フィッシング受信時の対応-v2.0（SE = Security）RB-NW-003-VPNトラブル対応-v1.0（NW = Network）
保管場所の選択肢
| 保管場所 | メリット | デメリット |
|---|---|---|
| SharePoint | 権限管理しやすい、検索しやすい、M365で統一 | 大量の場合の階層管理がやや煩雑 |
| Notion / Confluence | 編集UIが優秀、リンク管理が楽 | 追加コスト、M365外 |
| OneNote | 無料、M365で統一 | 検索性・バージョン管理が弱い |
| Git（Markdown） | 変更履歴が完璧、レビューフロー | 非エンジニアには敷居が高い |
50名以下の中小企業ならSharePointの専用ライブラリが最もコスト効率良く、運用負荷も低いです。
Runbookのライフサイクル管理
書きっぱなしのRunbookは古くなって誰も使わなくなります。以下のライフサイクル管理を導入します。
- 新規作成：手順を実施した直後（記憶が新しいうちに）
- レビュー：作成後1週間以内に別の情シスメンバー or 当該業務未経験者が読み、不明点をフィードバック
- 定期見直し：年1回、すべてのRunbookを読み直し、UI変更や手順の変化を反映
- 使用時の更新：Runbookに沿って実施した際、不一致があればその場で修正
- 廃止：1年使われなかったRunbookは「廃止候補」フォルダへ移動、半年経過で削除
古いRunbookに従って作業すると、UI変更による誤操作・意図しない設定変更が発生します。「最終更新日」をメタデータに必ず入れ、3ヶ月以上更新されていない場合は警告色で表示する仕組みを推奨します。
AIによるRunbook作成・更新の自動化
2026年現在、Runbook作成にはAIを積極的に使えます。
パターン1：操作の自動文書化
ScreenpalやSnagitで作業を録画し、Microsoft 365 Copilotや別途LLMに「この動画を文章化してRunbookテンプレートに当てはめて」と依頼します。10分の作業で80%完成のRunbookが出力されます。
パターン2：既存ナレッジからの自動生成
過去のSlack/Teamsの会話・チケット履歴をAIに読み込ませ、「同じ問題が複数回起きている業務」を抽出してRunbook化候補を提示してもらいます。
パターン3：Copilot Studioでの対話型ヘルプデスク
Runbookの内容をCopilot Studioに学習させ、社員からの問合せに対して該当Runbookの該当箇所を自動回答するBotを作ります。情シスの一次対応工数が大幅に削減されます。
「Runbookを書く文化」を作る
Runbookは技術ではなく文化です。以下の仕組みで文化を定着させます。
- 新規業務には必ずRunbookを書く：手順書がない業務はやらない原則
- レビューを必須化：書いて終わりではなく、別メンバーのレビューを通す
- 評価指標に組み込む：四半期評価で「Runbook作成数」「Runbook参照率」を見る
- 新メンバー研修で必ず使う：新メンバーが立ち上がる際、Runbookを使って自走させる
BTNコンサルティングの支援
情シス365のサービスでは、業務代行と並行してRunbook作成を進めます。当社の標準テンプレート・サンプルRunbook集（150種類以上）の提供、Runbook化対象業務の優先順位付け、社員によるRunbook運用文化の定着まで支援します。
業務棚卸し、Runbook作成、SharePoint構築、Copilot Studio連携、社内研修までワンストップ対応。
→ ITアウトソーシングの詳細
→ 退職前30日に作成すべき5文書
まとめ
情シスのRunbookは、属人化を防ぎ、退職リスクを下げ、新メンバーの立ち上げを加速させる最重要ドキュメントです。標準テンプレートで書き方を統一し、命名規則・保管場所・ライフサイクル管理を整備することで、書きっぱなしを防げます。AIによる作成・更新の自動化、Copilot StudioでのBot化を組み合わせれば、Runbookは情シスの「分身」として機能し始めます。