フレームワーク活用ガイドひとことで言うと#
プロジェクトのフェーズ移行・チーム間連携・担当者交代で発生する情報の断絶を防ぐための標準化された引き継ぎ手順。「何を・誰に・どの形式で・いつまでに」を事前にルール化し、引き継ぎ漏れをゼロに近づける。
押さえておきたい用語#
- ハンドオフ（Handoff）
- あるチームや担当者から別のチームや担当者へ作業・責任・情報を移転する行為。バトンタッチとも呼ばれる。
- SBAR（エスバー）
- Situation・Background・Assessment・Recommendationの頭文字。医療業界発の構造化された引き継ぎフォーマットで、重要情報の漏れを防ぐ。
- 引き継ぎチェックリスト
- ハンドオフ時に確認すべき項目を網羅的にリスト化したものを指す。暗黙知の伝達漏れを構造的に防止する。
- ウォークスルー
- 引き継ぎ元が引き継ぎ先に対して、成果物やシステムの全体を順を追って説明する対面セッション。文書だけでは伝わらない文脈を共有するための手法。
ハンドオフ・プロトコルの全体像#
こんな悩みに効く#
- 担当者が異動するたびに「前任者に聞かないとわからない」が発生する
- フェーズ移行で情報が抜け落ち、後工程で手戻りが起きる
- 引き継ぎ文書があっても、暗黙知が伝わっていない
基本の使い方#
引き継ぎが必要な情報を、以下のカテゴリで洗い出す。
| カテゴリ | 例 |
|---|---|
| 成果物 | 設計書、コード、テスト結果、議事録 |
| 進行中の作業 | 未完了タスク、保留事項、承認待ち |
| 関係者情報 | ステークホルダーの連絡先、意思決定者、担当範囲 |
| リスク・課題 | 既知のリスク、未解決の課題、過去のトラブル事例 |
| 暗黙知 | 「この顧客にはこう対応する」「このシステムのこの部分は触ってはいけない」 |
暗黙知こそ最も漏れやすく、最もトラブルの原因になる。
構造化されたフォーマットで文書を作成する。
- S（Situation / 現状）: プロジェクトの現在の状態。何がどこまで進んでいるか
- B（Background / 背景）: なぜこの状態なのか。過去の経緯と意思決定の理由
- A（Assessment / 評価）: 現状の課題・リスク・注意点
- R（Recommendation / 推奨）: 後任が最初にやるべきこと、優先順位
SBARは医療業界の引き継ぎ標準で、短時間で重要情報を漏れなく伝えるのに最適化されている。
文書だけでは伝わらない文脈を、対面（またはオンライン）で共有する。
- 引き継ぎ文書を元に、前任者が後任者に全体を説明する
- 後任者は質問・懸念点をその場で確認する
- ウォークスルーは 録画 しておくと、後から参照できる
- 実際のシステムやツールを操作しながら説明するのが効果的
引き継ぎ直後に前任者がいなくなると、小さな疑問が解消できず大きなトラブルに発展する。
- 引き継ぎ後 2週間 は前任者が質問に対応できる体制を維持
- 質問内容は引き継ぎ文書に追記して、次回の引き継ぎに活かす
- フォロー期間終了時に「これ以上不明点はないか」を最終確認
具体例#
状況: 従業員300名のSIer。要件定義チーム→設計チーム→開発チームとフェーズごとにチームが変わる体制。設計チームが「要件定義で決まったはずの仕様が見つからない」という問題が年間 15件 発生し、手戻りコストが推定 1,200万円。
導入したプロトコル
| 項目 | 内容 |
|---|---|
| 引き継ぎ文書 | SBAR形式のフェーズ移行書（テンプレート化） |
| チェックリスト | 28項目の引き継ぎチェックリスト（成果物・決定事項・未解決課題） |
| ウォークスルー | フェーズ移行時に2時間の対面セッション |
| フォロー期間 | 移行後1週間はSlackチャンネルで前チームが質問対応 |
1年後の結果
- 「仕様が見つからない」問題: 15件 → 2件（87%削減）
- 手戻りコスト: 1,200万円 → 180万円
- フェーズ移行にかかる時間: 増加（1フェーズあたり+3時間）だが、手戻りの減少で全体工期は短縮
引き継ぎに3時間かけることで、手戻りの数十時間を防げるという費用対効果が明確になった。
状況: 病床数350床の総合病院。看護師のシフト交代時の申し送りが口頭のみで、「前のシフトで言われたはず」という情報の抜け漏れが月 8〜12件 発生。うち2件がインシデント（医療事故の一歩手前）に至った。
SBAR導入
申し送りをSBARフォーマットの定型シートに変更。
- S: 患者名、病室、現在のバイタル
- B: 入院理由、治療経過、当日の処置内容
- A: 注意すべき変化（「血圧が午後から上昇傾向」など）
- R: 次のシフトでの対応事項（「22時に血圧再測定」「点滴残量確認」）
6ヶ月後の結果
- 申し送り漏れ: 月 10件平均 → 1.5件
- インシデント: 0件
- 申し送り時間: 1患者あたり5分 → 3分に短縮（構造化で無駄な会話が減った）
口頭の自由形式では「何を伝えるか」が個人の判断に依存していたが、SBARの型に沿うことで漏れが構造的に防止された。
状況: シリーズBのSaaSスタートアップ（従業員55名）。共同創業者のCTOが退任し、後任CTOに引き継ぐ。システムアーキテクチャ、技術的負債、ベンダー契約、チームの暗黙知など、引き継ぎ範囲が膨大。期限は 3週間。
引き継ぎプロトコル
| 週 | 内容 |
|---|---|
| 第1週 | 引き継ぎ項目の洗い出し（87項目）+ 文書化開始 |
| 第2週 | ウォークスルー5回（アーキテクチャ/インフラ/セキュリティ/チーム/ベンダー）+ 録画 |
| 第3週 | 後任CTOが1週間「影」として全ミーティングに同席、疑問点をリアルタイムで解消 |
引き継ぎ文書の構成
- システムアーキテクチャ図（ADR含む）: 15ページ
- 技術的負債リスト: 23項目（優先度付き）
- ベンダー契約一覧: 12社分（契約更新日・担当者・交渉経緯）
- 「知っておくべきこと」リスト: 暗黙知34項目（「このAPIは月末にレスポンスが遅くなる」等）
退任後1ヶ月間はSlackで質問対応可能とし、実際に 47件 の質問が寄せられた。質問と回答はすべて引き継ぎ文書に追記し、将来の引き継ぎにも使えるナレッジとして蓄積された。
やりがちな失敗パターン#
- 文書だけで引き継ぎを終える — 文書に書けない暗黙知（判断の基準、関係者の人柄、過去のトラブルの文脈）はウォークスルーでしか伝わらない
- 引き継ぎ日を1日だけ設定する — 1日で全情報を伝えるのは不可能。数日〜数週間のプロセスとして設計する
- フォロー期間を設けない — 引き継ぎ直後が最も疑問が多い時期。前任者がすぐいなくなると、小さな疑問が大きなトラブルに発展する
- 引き継ぎを「前任者の仕事」だけにする — 後任者も積極的に質問し、理解度を確認する責任がある。受け身の引き継ぎは漏れの温床
まとめ#
ハンドオフ・プロトコルは、引き継ぎを「準備→実行→確認」の3フェーズで構造化し、情報の断絶を防ぐ手法。SBAR形式の文書化、対面のウォークスルー、フォローアップ期間の3つが核となる。引き継ぎに時間をかけることは一見コストだが、引き継ぎ漏れによる手戻り・トラブルのコストと比較すれば圧倒的に安い。暗黙知こそ最も漏れやすく最もトラブルの原因になるため、意識的に言語化・共有する仕組みを作ることが重要になる。