PMO10年で作った引き継ぎ資料の型|3つの要素で忘れられない仕組み

引き継ぎ資料が「読まれない」現場のリアル

引き継ぎ資料を作ったのに、後任者から同じ質問が何度も来る。そんな経験はありませんか。私はPMOとして10年以上、さまざまなプロジェクトで引き継ぎに関わってきましたが、引き継ぎ資料が「作られているのに機能していない」現場を数え切れないほど見てきました。

引き継ぎ資料がWordやExcelで数十ページ作られている。目次もある。体裁も整っている。でも、後任者は結局、前任者に電話をかけてくる。「あの件、どうなってましたっけ?」と。前任者は「資料に書いたんだけどな…」と思いながらも、また同じ説明をする。この繰り返しなんですよね。

なぜこんなことが起きるのか。それは、引き継ぎ資料が「情報の羅列」になっているからです。プロジェクトの概要、体制図、スケジュール、課題一覧。確かにこれらは必要な情報です。でも、後任者が本当に知りたいのは、表面的な情報ではないんです。

私がPMOとして10年以上、多数のプロジェクトで引き継ぎを経験してきた経験を語ります。若手時代の引き継ぎ資料は、プロジェクトの経緯、体制、スケジュール、課題一覧などの情報を網羅した100ページの大作でした。しかし後任者から『情報はあるけど、どう動けばいいか分からない』と言われた経験があります。この体験から、私は引き継ぎ資料の型を根本的に見直しました。忘れられない引き継ぎ資料の3要素は、(1)なぜこの判断をしたのか(背景)、(2)関係者の癖(人間関係の暗黙知)、(3)地雷ポイント(避けるべき落とし穴)。表面的な情報ではなく、後任者が本当に困る場面で役立つ情報を体系化する仕組みです。20年以上磨いてきたこの型で、多くの後任者から『助けられた』と感謝の言葉をもらいました。引き継ぎ資料は『情報を残す』ではなく『経験を伝える』ことが本質だと痛感しています。

後任者が本当に困るのは、「なぜこうなっているのか」が分からないときです。なぜこの仕様になったのか。なぜこの担当者にこの頼み方をしているのか。なぜこのベンダーとの会議は毎週月曜なのか。そういった「背景」や「文脈」が資料に書かれていないから、後任者は判断できないんです。

私が見てきた中で最も悲惨だったのは、金融系の大規模プロジェクトでの引き継ぎでした。前任のPMOが退職し、私が引き継ぎを受けたのですが、渡された資料は100ページを超えるExcelファイル。会議体の一覧、課題管理表、進捗管理表、リスク管理表…すべて揃っていました。でも、3ヶ月後に大きなトラブルが起きました。

ある重要な意思決定を、私は「合理的」だと思って進めたんです。でも、顧客の責任者が激怒しました。後で分かったのは、過去に同じ提案をして大揉めした経緯があったこと。その「地雷」が、どの資料にも書かれていなかったんです。前任者に連絡を取ったら、「ああ、あれは口頭で伝えたつもりだったんだけど…」と。

引き継ぎ資料に「何があったか」は書かれていても、「なぜそうなったか」「次に何をすべきでないか」が書かれていない。これが、引き継ぎが失敗する最大の原因なんです。

引き継ぎ資料が使われない3つの典型パターン

私が現場で見てきた「使われない引き継ぎ資料」には、共通するパターンがあります。

1つ目は「情報の羅列型」です。プロジェクトに関するあらゆる情報を網羅的に書き出したもの。一見すると丁寧に見えますが、情報量が多すぎて後任者は何が重要か分かりません。結果、全体をざっと読んで終わり。必要なときに必要な情報を探せない状態になります。

2つ目は「手順書型」です。「毎週月曜に進捗会議」「毎月末に報告書作成」といった定型業務の手順だけが書かれているもの。確かに日常業務は回せますが、イレギュラーな事態が起きたとき、後任者は判断できません。なぜこの手順なのか、変更してもいいのか、変更するとどんな影響があるのか。そういった判断材料がないんです。

3つ目は「思い出話型」です。前任者の個人的な感想や、プロジェクトの裏話ばかりが書かれているもの。「○○さんは気難しい人でした」「△△の件は大変でした」といった主観的な記述。これも後任者には使えません。具体的にどう対処すればいいのかが分からないからです。

後任者が「資料を見ない」本当の理由

もう1つ、現場でよく見る光景があります。引き継ぎ資料が「作られた時点で終わっている」パターンです。

前任者が退職の1週間前に、慌てて引き継ぎ資料を作る。その時点での情報をまとめて、後任者に渡して終わり。でも、プロジェクトは生き物です。引き継ぎから1ヶ月後には状況が変わっている。資料に書かれた情報が古くなっている。後任者は「この資料、もう使えないな」と判断し、資料を見なくなります。

私がPMOとして学んだのは、引き継ぎ資料は「作って終わり」ではなく、「継続的に更新される仕組み」でなければ意味がないということです。そして、更新されるためには、資料の構造そのものが「更新しやすい」形になっている必要があるんです。

引き継ぎが機能しない構造的な理由

私が30年近くIT業界にいて気づいたのは、引き継ぎの失敗には構造的な原因があるということです。単に「前任者が手を抜いた」とか「後任者が資料を読まない」といった個人の問題ではないんですよね。

「形式知」と「暗黙知」の分断

引き継ぎが失敗する最大の構造的原因は、「形式知」と「暗黙知」の分断です。形式知というのは、文書化できる知識のこと。プロジェクトの体制、スケジュール、課題一覧などです。一方、暗黙知というのは、言語化しにくい知識。人間関係の機微、組織の力学、暗黙のルールなどです。

一般的な引き継ぎ資料は、形式知だけを扱います。なぜなら、形式知は書きやすいから。既存の資料をコピペすれば、それなりの体裁になります。でも、後任者が本当に困るのは暗黙知が必要な場面なんです。

例えば、「A部長に相談するときは、必ず事前に根回しをする」という暗黙のルール。これを知らずにいきなり会議で提案すると、A部長の機嫌を損ねてプロジェクトが止まる。でも、こういう情報は引き継ぎ資料には書かれません。「書きにくい」「属人的すぎる」と判断されるからです。

私が金融系プロジェクトで経験した「地雷」も、まさにこれでした。過去の意思決定の経緯、顧客との関係性、避けるべき提案の仕方。これらはすべて暗黙知です。でも、この暗黙知こそが、プロジェクトを円滑に進めるための最重要情報なんです。

「時系列」と「文脈」の欠落

もう1つの構造的問題は、引き継ぎ資料が「現時点のスナップショット」になっていることです。現在の体制、現在の課題、現在のスケジュール。確かにこれらは必要ですが、「なぜ今この状態なのか」という文脈が欠落しています。

プロジェクトは時間の中で変化します。当初の計画があって、途中で問題が起きて、方針を変更して、今の状態に至っている。この「経緯」を知らないと、後任者は適切な判断ができません。

例えば、スケジュールが当初より2ヶ月遅れている状態を引き継いだとします。資料には「現在2ヶ月遅延」と書かれています。でも、なぜ遅れたのか、どんな対策を取ったのか、今後どうリカバリーする予定なのか。これらが書かれていなければ、後任者は「遅れている」という事実を知るだけで、何をすべきか分かりません。

私がPMOとして学んだのは、引き継ぎ資料には「判断の履歴」を残す必要があるということです。誰が、いつ、なぜ、その判断をしたのか。この情報があれば、後任者は同じ文脈で次の判断ができます。

「作成者視点」と「利用者視点」のギャップ

3つ目の構造的問題は、引き継ぎ資料が「作成者視点」で作られていることです。前任者は自分が知っている情報を、自分が理解している順序で書きます。でも、後任者が知りたい情報、知りたい順序は違うんです。

前任者にとっては「当たり前」のことが、後任者にとっては「全く分からない」ことだったりします。略語、専門用語、社内用語。前任者は無意識に使っていますが、後任者はその意味すら分かりません。

また、前任者は「重要だと思う情報」を書きますが、それが後任者にとっても重要とは限りません。前任者が苦労した部分は詳しく書かれていますが、スムーズに進んだ部分は省略されている。でも、後任者にとっては、スムーズに進んだ部分こそ「なぜうまくいったのか」を知りたい情報だったりします。

私が10年以上PMOをやってきて分かったのは、引き継ぎ資料は「後任者が困る場面」から逆算して作る必要があるということです。後任者がどんな状況で、どんな情報を必要とするか。それを想像して、資料の構造を設計しなければならないんです。

引き継ぎ失敗のパターン一覧

私が現場で見てきた引き継ぎ失敗のパターンを、原因と結果で整理するとこうなります。

失敗パターン	原因	結果
情報の羅列型	網羅性を優先し、重要度の区別がない	後任者が何が重要か判断できず、全体を読まなくなる
手順書型	定型業務の手順のみで、判断基準が書かれていない	イレギュラー時に後任者が判断できず、前任者に問い合わせが来る
思い出話型	主観的な感想ばかりで、具体的な対処法がない	後任者が同じ状況に直面しても、どう行動すべきか分からない
スナップショット型	現時点の情報のみで、経緯や背景が書かれていない	後任者が「なぜこうなったか」が分からず、誤った判断をする
作って終わり型	更新の仕組みがなく、情報が古くなる	後任者が資料を信用しなくなり、使われなくなる

PMO10年で作った「忘れられない」引き継ぎ資料の型

私がPMOとして10年以上かけて作り上げた引き継ぎ資料の型は、3つの要素で構成されています。「判断の背景」「関係者の癖」「地雷ポイント」です。この3つを体系化することで、後任者が本当に困る場面で役立つ引き継ぎ資料になります。

要素1:判断の背景を残す

私が引き継ぎ資料で最も重視しているのは、「なぜその判断をしたのか」という背景情報です。単に「現在の状態」を書くのではなく、「なぜこの状態になったのか」を必ず書きます。

例えば、進捗会議が毎週月曜10時に設定されているとします。通常の引き継ぎ資料なら「毎週月曜10時に進捗会議」と書いて終わりです。でも、私はこう書きます。

「進捗会議は毎週月曜10時。当初は火曜午後に設定していたが、顧客の○○部長が月曜午前に社内会議を持っており、その直後に我々の進捗を確認したいという要望で変更。火曜に戻すと、部長の機嫌を損ねる可能性あり」

この情報があれば、後任者は「なぜ月曜なのか」を理解できます。そして、もし日程変更の要望が来たとき、適切に判断できるんです。単に「月曜10時」とだけ書かれていたら、後任者は安易に変更して、関係性を壊してしまうかもしれません。

判断の背景を残すためには、日常的に「判断の記録」を取る習慣が必要です。私は重要な意思決定があるたびに、簡単なメモを残すようにしています。誰が、いつ、何を決めて、なぜその判断をしたのか。これを蓄積しておくことで、引き継ぎ資料を作るときに、ただのコピペではなく「文脈のある情報」を提供できます。

要素2:関係者の癖を具体的に書く

2つ目の要素は、「関係者の癖」です。これは書きにくい情報ですが、後任者にとっては最も価値のある情報なんです。

私は引き継ぎ資料に、主要な関係者ごとに「コミュニケーションの癖」を書きます。ただし、感情的な表現は避けます。例えば「A部長は気難しい」ではなく、「A部長は事前の根回しなしに会議で提案されることを嫌う。重要事項は必ず事前に1on1で相談すること」と書きます。

これは単なる悪口ではなく、プロジェクトを円滑に進めるための実務情報です。A部長がなぜ事前相談を好むのか、それは部長のマネジメントスタイルであり、それに合わせることがプロジェクト成功の鍵なんです。

私が実際に引き継ぎ資料に書いた例を挙げます。「B社の○○さんは、メールでの依頼に反応が遅い。緊急の場合は電話が確実。ただし、電話の後に必ずメールで議事録を送ること。○○さんは口頭での約束を忘れる傾向がある」

これを知っているかどうかで、後任者の業務効率が大きく変わります。知らなければ、メールを送って待ち続け、納期に間に合わなくなるかもしれません。知っていれば、最初から電話して、証跡をメールで残すという効率的な対応ができます。

要素3:地雷ポイントを明示する

3つ目の要素は、「地雷ポイント」です。これは「絶対にやってはいけないこと」「過去に失敗したこと」を明示的に書くことです。

私が金融系プロジェクトで経験した「地雷」のように、過去に大きな問題を引き起こした提案や、顧客が強く拒否した内容があれば、それを具体的に書きます。「○○という提案は、20XX年に顧客が強く拒否。理由は△△。今後も同様の提案は避けること」

地雷ポイントを書く際は、「なぜそれが地雷なのか」という理由も必ず添えます。単に「やるな」と書いても、後任者は理解できません。背景を知ることで、後任者は類似の状況でも適切に判断できるようになります。

また、組織の政治的な地雷もあります。「C部とD部は過去に対立があり、両部門が関わる案件は慎重に進めること。必ず両部門に同時に情報共有し、どちらかを優先したと思われないようにする」といった情報です。

こういった情報は、表面的な業務マニュアルには絶対に載りません。でも、これを知らないと、後任者は無意識に地雷を踏んで、プロジェクトを危機に陥れてしまいます。

ツールの選択と比較

これらの情報を体系化するためには、適切なツールが必要です。私が現場で使ってきた経験から、引き継ぎ資料の管理に向いているツールを比較します。

ツール名	特徴	向いている企業	コスト感
Notion	階層構造で情報整理が容易。テンプレート化しやすく、継続的な更新に強い。検索性も高い	中小企業、スタートアップ。柔軟な情報整理を求める組織	無料〜月10ドル/人
Confluence	企業向けWiki。権限管理が強く、大規模組織でも使える。Jiraとの連携が強み	中堅〜大企業。既にJiraを使っている組織	月5.75ドル/人〜
SharePoint	Microsoft 365に含まれる。既存のOffice環境と統合しやすい。ただし設定が複雑	Microsoft環境を使っている企業。IT部門のサポートがある組織	Microsoft 365に含まれる

私が個人的に推奨するのはNotionです。理由は3つあります。1つ目は、情報の構造化がしやすいこと。見出し、ページのネスト、データベース機能を使って、3つの要素(判断の背景、関係者の癖、地雷ポイント)を明確に分類できます。

2つ目は、更新のハードルが低いこと。Wordのように「ファイルを開いて編集して保存してアップロード」という手順ではなく、ブラウザで直接編集できます。これにより、ちょっとした情報もすぐに追記できます。引き継ぎ資料は「継続的に更新される」ことが重要なので、この手軽さは大きなメリットです。

3つ目は、検索性です。後任者が「あの件、どうだったっけ?」と思ったとき、すぐに検索して見つけられます。Wordファイルが複数あると、どのファイルに何が書いてあるか探すだけで時間がかかります。Notionなら全文検索で一発です。

ただし、私が30年見てきた経験から言えるのは、ツールはあくまで手段だということです。どんなツールを使っても、「何を書くか」という本質が間違っていれば、引き継ぎは失敗します。大事なのは、判断の背景、関係者の癖、地雷ポイントという3つの要素を、継続的に蓄積する仕組みを作ることなんです。

実際の引き継ぎ資料の構造

私が実際に使っている引き継ぎ資料の構造を紹介します。Notionを例にしますが、他のツールでも同じ考え方で作れます。

トップページには、プロジェクトの概要と、最も重要な3つの情報へのリンクを置きます。「現在の最重要課題」「今週の注意事項」「よくある質問」です。後任者が最初に見るべき情報を、ここに集約します。

次に、「判断の記録」ページを作ります。ここには時系列で、重要な意思決定とその背景を記録します。日付、決定事項、理由、関係者を明記します。このページは継続的に更新され、プロジェクトの「判断の履歴」になります。

「関係者マップ」ページには、主要な関係者ごとに、役割、連絡先、コミュニケーションの癖を書きます。ここが「関係者の癖」を蓄積する場所です。新しい関係者が増えたら、その都度追記します。

「地雷リスト」ページには、過去の失敗事例、避けるべき提案、組織の政治的な注意点をリスト化します。このページは後任者が「やってはいけないこと」を素早く確認できる、いわばチェックリストです。

最後に、「定型業務マニュアル」ページを作ります。ここには日常的な業務の手順を書きます。ただし、単なる手順書ではなく、「なぜこの手順なのか」という背景も必ず添えます。

この構造の利点は、後任者が「自分が今必要な情報」にすぐアクセスできることです。日常業務を回すだけなら定型業務マニュアルを見る。重要な判断をするときは判断の記録を見る。関係者とコミュニケーションを取るときは関係者マップを見る。そして、何か新しいことをする前に地雷リストを確認する。

30年現場にいた私が思うこと

私がIT業界で30年、PMOとして10年以上やってきて痛感するのは、引き継ぎの質がプロジェクトの成否を左右するということです。優秀な人材が去っても、その人の知識と経験が組織に残る仕組みがあれば、プロジェクトは継続できます。でも、その仕組みがなければ、人が去るたびにプロジェクトは混乱します。

私が見てきた成功しているプロジェクトには、共通点があります。それは、「ナレッジが個人に属していない」ことです。判断の背景、関係者の癖、地雷ポイント。これらの情報が、個人の頭の中ではなく、チーム全体で共有されている。だから、誰かが抜けても、プロジェクトは止まらないんです。

逆に、失敗するプロジェクトは、すべてが属人化しています。「あの人じゃないと分からない」という状態です。その人が休むとプロジェクトが止まる。その人が辞めるとプロジェクトが崩壊する。こういう状態は、組織として非常に脆弱なんですよね。

引き継ぎ資料は、単なる「退職時の義務」ではありません。組織のナレッジを蓄積し、属人化を防ぎ、プロジェクトの継続性を担保する、戦略的な仕組みなんです。だからこそ、「作って終わり」ではなく、「継続的に育てる」ものとして扱うべきだと私は思います。

私がPJM-A資格を取得したとき、プロジェクトマネジメントの教科書には「ナレッジマネジメント」という項目がありました。でも、現場でナレッジマネジメントが本当に機能している例は、正直あまり見たことがありません。多くの組織では、ナレッジマネジメントは「理想論」で終わっているんです。

でも、私が10年かけて作った引き継ぎ資料の型は、現場で本当に機能しています。なぜなら、「後任者が困る場面」から逆算して設計しているからです。教科書的な理想論ではなく、現場の実務から生まれた仕組みだから、使われるんです。

もしあなたが今、引き継ぎに悩んでいるなら、まず小さく始めてみてください。明日から、重要な判断をしたときに、その背景を1行メモする。関係者とのやり取りで気づいた「癖」を書き留める。失敗したことがあれば、それを「地雷リスト」に追加する。

これだけで、半年後には立派な引き継ぎ資料の土台ができています。そして、次に誰かが引き継ぐとき、その人は「なぜこうなっているのか」を理解でき、同じ失敗を避けられます。それが、組織の財産になっていくんです。

引き継ぎ資料は、前任者から後任者への贈り物です。でも、それは単なる情報の羅列ではなく、「現場で本当に役立つ知恵」であるべきです。あなたの10年後の後任者が、あなたの残した資料を見て「この人のおかげで助かった」と思える。そんな引き継ぎ資料を、今日から作り始めてみませんか。