スキルと業務を体系的に引き継ぐ全手順。余裕が無いときの応急措置も【パウリ】

第1回では「なぜ引継ぎは難しいのか」というテーマで、引継ぎを阻む3つの根深い要因を紐解きました。

そちらでも述べた通り、引継ぎは「重要だが緊急ではない」業務と見なされがちで、日々の業務に追われるうちに「パンク状態」となり、着手できなくなるのが常です。

この問題を避けるためには、根本的な意識改革が必要です。

本稿では、まず「なぜ引継ぎがあなたのキャリアにとって重要なのか」という問いを掘り下げながら、引継ぎに求められるマインドセットを再定義します。

次に「後任者が決まるまでの準備（=日々の業務）」で何をすべきかを解説し、最後に「後任者が決まってからの具体的な引継ぎプロセス」をステップバイステップで説明します。

なお、組織全体として引継ぎがしづらい環境という課題については今回の主題から逸れてしまうため、あえて改善策については深く言及しません。

• keyboard_arrow_down 引継ぎは「組織のため」だけにあらず。「自分のキャリア」のためにある
• keyboard_arrow_down 後任が決まるまでは、「入社前の自分」の視点で日々の業務で得た知見を書き留める
• keyboard_arrow_down 今更メモや資料をつくる時間がない人はトリアージ＆マップ化で緊急対応
• keyboard_arrow_down 後任者が決まったら、 関係構築と期待値のすり合わせをする
• keyboard_arrow_down 後任者の気持ちと組織からの期待にズレを生まないゴールを設定する
• keyboard_arrow_down 業務の解像度を上げ、引継ぎの確度を高めるためのプラクティス
• keyboard_arrow_down まとめ：引継ぎは「未来への投資」である

「引継ぎ」という言葉は、どうして「会社のため」「組織のため」という響きが強いのでしょうか。

「今は自分のスキルを伸ばす時だ」といった意欲を持っている方ほど、引継ぎ業務を「キャリアの本筋とは関係のない雑務」と捉えてしまうかもしれません。

しかし、本稿で私が一番声を大にして言いたいのは、むしろ自分のキャリアを本気で考える人ほど、引継ぎを戦略的に行ってほしいということです。

例えば、あなたがエンジニアとして「将来はCTOになりたい」というキャリアを描いているとします。

そのステップは様々ですが、多くの場合、プロダクトコードへの直接介入から、レビューや技術選定、育成の仕組みづくりへと、より影響範囲の広い間接的な役割へとシフトしていきます。

このようにキャリアアップする過程では、必ず「それまでの業務を誰かに任せる」という引継ぎが発生します。

ここに落とし穴があります。

第1回で述べたように、いざ次のステップへ挑戦しようという時には、すでに「パンク状態」に陥っていることが多いのです（もちろん、あなたのキャリアプランを深く理解し、先んじて業務調整をしてくれる優れたマネージャーのもとにいる場合は別ですが）。

つまり、せっかくキャリア計画を立て、次の役割に必要なスキルを身につけても、「今の業務を離れられない」という理由で、その領域へ挑戦することすらできなくなるのです。

そして挑戦が阻まれ続けた先で、本来好きな環境でも「成長が見込めないから」と転職することになるケースもあります。

だからこそ、組織のためである以上に、あなた自身のキャリアを機敏に動かせるようにするために、常に業務の引継ぎ（＝言語化・体系化）ができる状態を維持することが、強力な戦略となります。

この努力は、キャリアの途中で目標が変わったとしても決して無駄にはなりません。

例えば、先の例の中で「1つのチームで成果を出すこと」にCTOになることより情熱を見出したとします。

その場合でも、日々の業務を適切にメンバーへ引継ぎできていれば、あなたは「環境の変化に対応する」「新しいツールを導入する」「隣接チームとの摩擦を少なくする」「チームの成果を社外へ発信する」といった、より付加価値の高い活動に自分の時間を使うことができるようになります。

本稿でお伝えしたいのは、まさにこの点です。

「引継ぎ」は、組織貢献だけではなく、あなた自身の可能性を広げるための重要な営みなのです。

成功する引継ぎの最大の秘訣は、役割を担うその時から、常に引継ぎを前提として業務に取り組むという姿勢にあります。

重要なのは、完璧なドキュメントを毎日つくることではありません。将来の自分や後任者のために、思考の断片を「種」として残しておくことです。

新しいツールの使い方、トラブルシューティングの記録、複雑な仕様に関する自分なりの解釈など、どんな些細なことでも構いません。とにかく新しい知見を得たら、手元のメモに書き留めていきます。

とはいえ、日々の業務をすべて綺麗なドキュメントに残そうとしたら、それだけで業務時間が終わってしまいかねません。

ここで役立つのが、「入社前の自分だったら何を知りたかったか？」という視点です。

ふとした業務の中で「この会社（チーム）の『当たり前』は、入社前の自分は知らなかったな」と感じたことをメモしていくだけで良いのです。企業文化に染まってしまう前に、その「違和感」や「発見」を記録する意識を持つことが、理想的なスタートです。

しかし、常にすべての事象に気を配っていては業務に集中できません。

そこで、特にメモを残すべき「3つのシグナル」を意識するとよいでしょう。

• シグナル1. ワークフローや規則・ルールが存在した時
• シグナル2. 判断に必要な情報がなかった（他者に聞く必要があった）時
• シグナル3. 独自の判断で意思決定をした時

これらのシグナルの背景にある情報は、概ね以下の3点に集約されると考えています。

このタイミングで残したメモは、後から入ってきた人が「このオンボーディング資料、助かる！」と感じる内容といえるでしょう。

• 1. この組織・チームではどんな流れで業務が進んでいるか？
• 2. 誰が何を知っていて、誰に聞けばよいのか？
• 3. この役割・役職へはどんな期待があり、どこまでが裁量か？

このようにして、「Xドメインの仕様変更時にPlatform チームへも連絡していた」や「Nさんが施策のターゲットユーザーをよりシャープにすることに意思決定していた」、「アプリのデザインはデザイナーチームだけでなくPdMにも承認を得る必要があった」など、ADR（Architecture Decision Records）のように日々のシグナルに基づいてメモ（＝種）を蓄積していきます。

この「種」の蓄積は、個人の役割、チームの特性、そして本当に必要なスキルセットを客観的に浮き彫りにします。

例えば、「自律的なチーム」と謳いながらも、意外とチーム内で完結している業務が少ない、あるいはマネージャーに対する期待がPdMとメンバー間でズレていて困っている、といった課題が明らかになることもあります。

蓄積に基づく資料があれば、必須スキルや歓迎スキルを言語化し、時に求人票を作成したり、採用計画を練ったりすることに繋げられます。

もし自身に人事権があればそれを実行し、なければこの資料を元に上長へ「この役割にはこういうスキルが必要です」といった提案に繋げることも期待できます。

この日々の小さな積み重ねが、いざ引継ぎが始まった時のあなたを助ける最大の資産となります。

「この記事を読んだ時点で、すでに第1回で述べた「パンク状態」にあり、「理想は分かったが、もう時間がない」と焦っている方もいらっしゃるかもしれません。

結論から言えば、決して遅すぎることはありません。

その状態で目指すのは、「完璧な引継ぎ」ではなく、「最低限の引継ぎ」です。

完璧を目指すあまり0点になるより、最低限の30点を確実に渡す方が、組織にとっても後任者にとっても遥かに価値があります。

時間が全くない時は、以下の2点に絞って対応してください。

1. 業務のトリアージ（優先順位付け）

まず、「明日あなたがいなくなったら、事業が停止する（あるいは大きな損害が出る）業務は何か？」を自問してください。

緊急ですべての業務を引き継ぐのは不可能に近いです。

「自分しか知らない、かつ、頻度が高い（あるいは影響範囲が広い）業務」はどれか、上位3つだけでも特定します。

2. 「What（作業）」と「Who（人）」のマップ化

特定した最優先業務について、「完璧なドキュメント」を作るのではなく、その分野に詳しいメンバーと直接顔合わせのセッティングをします。

セキュリティはAさん、予算はBさんのように、「この件は〇〇さん」というリストを元に、その人の観点で注意点を引き出すことでリスクヘッジをします。

上記の 1. で「最悪な事態」を防ぎつつ、 2. で業務推進可能な状態にする。

これにより、時間がない人のための緊急引継ぎが可能となります。

▲本稿で解説する、後任者決定後の引継ぎの流れ

ここからは、実際に後任者が決まった際の具体的なプロセスを、社外から新規に参画者を迎え入れたケースを元に説明します。

後任者が決まって、すぐにすべての業務を引継ぎたくなる気持ちは分かりますが、まずは後任者となってくれることへの感謝と、その「人」の解像度を上げ、どのような引継ぎをすれば良いか計画を立てることが重要です。

業務における後任者である前に、一人の人間としてどんなライフプランを描いているのか、その中でどんなキャリア設計をしていて、まずは何をしようとしているのか、どんな働き方を好んでいるのかなど、十人十色です。

そのため、最初の2週間程度は、技術的なキャッチアップよりも、チームに馴染み、人間関係を構築することに焦点を当てます。

インプット過多になりがちな時期だからこそ、遊び心のある「オンボーディングクエスト」を用意するし「この冒険（オンボーディング）を経ることで、業務を進められるようになる」というゴールを共有します。

開始と終結点を明示し、「今何%、何面まで進んだ？」とラフに進捗を確認できると、心理的ハードルを下げられます。

そのオンボーディング内には、以下の内容が含まれています。

• 1. 個人特性の把握
• 2. チーム特性への昇華
• 3. 企業の基本情報
• 4. 役割期待の整理
• 5. 権限と業務プロセス整理

一見、業務と関係ないように思えるこの個人特性の理解こそが、引継ぎの土台となります。

なぜなら、引継ぎとは「何を伝えるか」だけでなく、「AさんからBさんへ伝える」という個々人の特性を前提とした営みであり、人間関係の質にも大きく左右されるからです。

そのため、この個人特性の理解は、後任者が安心してパフォーマンスを発揮できる環境を意図的に作り上げ、引継ぎのコミュニケーションコストを下げるための重要なプロセスであり、この「信頼の土台」が整って初めて、後続の「実際の業務のすり合わせ」が意味を持つといえます。

以下では、個人特性を把握する方法をいくつか紹介します。

1. ウソ・ホント自己紹介

自己紹介をゲーム仕立てにすることで自然と盛り上がるようにします。

この自己紹介では、1つだけウソを含め、クイズを行うアイスブレイクです。

話し手は複数のエピソードを話し、聞き手は質問しながらウソを当てます。

結果自然と対話が生まれ、人となりを知るきっかけになります。

2. 価値観カード

他者の価値観はもちろん、自分の価値観を理解するのも難しいものです。

そこでwevoxのバリューズカードなどを使い、お互いが仕事で何を大切にしているかを共有し、自分と他者の行動原理の違いを把握しましょう。

これは、後任者の価値観を尊重するだけでなく、組織の価値観をアップデートする機会にもなります。

3. 自己紹介ページの作成

いわゆる「私の取扱説明書」のような自己紹介ページを作成します。

これにより、好んでいる業務の取り組み方やコミュニケーションの取り方などの暗黙的でありながらも不要な衝突に繋がりやすいリスクが一定回避されます。

このように、ただ口頭で自己紹介をして終わりにするのではなく、先述の通り引継ぎのコミュニケーションコストを下げる目的があるため、出力された情報はドキュメント化します。

また、ただ決められた項目を入力するだけだと退屈に感じてしまうので、このせっかくの相互理解の場をより楽しむためゲームやワークショップを用います。

人となりや価値観の共有が進んだら、次に実際の業務の進め方やすり合わせに入ります。

まずは自走できる状態を目指し、期間と業務範囲のスコープを決めます。

このスコープは「前任者がフォローできる内に、最低限必要な知識・スキル・タスクを有する」のような、どの水準までいったら成功なのかを判断できる必要があります。それができない状態だと、単位期間内のゴールの輪郭がぼやけてしまい引継ぎの効率が下がってしまいます。

そのため「後任者が3ヶ月後に自走できる状態にするため、職域XのN等級相当の期待に基づき、自身の判断で〇〇できている」のように、達成できたか否かを判断できる程度にゴールを具体化できるようにしましょう。

スコープを決めたうえで、お互いにとって無理のない引継ぎをするために、以下の流れで進めます。

• 1. Will-Can-Shouldで引継ぎ対象者の内面を可視化する
• 2. Risk-Effort マトリクスで「発達の最近接領域」を見極める
• 3. 単位期間ごとの「あるべき姿」を、ストーリー形式で言語化する

以下で、それぞれについて解説します。

1. Will-Can-Shouldで引継ぎ対象者の内面を可視化する

まずWill-Can-Shouldフレームワークを用いて、引継ぎ対象者が心の中で何を思い、どう感じているのかを探索します。

引継ぎの際、ただ業務リストを渡して「これをやって」と伝えるだけでは、その業務が本人にとって「やりたいこと（Will）」なのか、「できること（Can）」なのか、あるいは「やるべきと感じること（Should）」なのかが見えてきません。

Will（やりたいこと）： 本人のキャリア観や興味関心。
Can（できること）： 自身のスキルの棚卸し。
Should（すべきこと）：本人が認識する、 組織や上司から期待されていること。

特に重要なのが Should（期待） の扱いです。多くの現場では、ここが「上司に言われたから」という理由だけで埋められがちです。

なぜそれをする必要があるのか、背景や意義が腹落ちしていない状態では、それは単なる「作業」になってしまいます。

このワークを通じて、「本人が認識しているShould」と「組織が求めているMust」のズレを認識することが重要です。

また、後任者が見えていない「隠れた重要業務（Must）」を、「実はこういう業務もあるよ」と前任者が追記することで、認識のギャップを埋めていきます。

2. Risk-Effort マトリクスで「発達の最近接領域」を見極める

次に、Will-Can-Should で整理された業務をRisk-Effort マトリクスで再配置し、発達の最近接領域を可視化します。

発達の最近接領域（Zone of Proximal Development）とは、自分一人ではできないが、他者のサポートがあればできる領域です。

縦軸（Risk）： 1人でその業務を行って失敗した際のリスクやインパクトの大きさ。
横軸（Effort）：1人でその業務を行う際にかかる時間、努力、精神的な負荷（心労）。

このマトリクスに業務を配置することで、各領域に対する引継ぎのアプローチが明確になります。

High Risk / High Effort：パニックゾーン
1人でやらせると失敗のリスクが高く、時間もかかり精神的負荷も大きすぎる領域です。

ここをいきなり任せると、後任者は自信を喪失します。

ここはまだ任せず、成果物や活動時に必要な知見や思考プロセスを開示し、まずはその業務や成果物を「見る」ことから始めます。

Middle Risk / Middle Effort：ストレッチゾーン
今の能力より少し高いレベルですが、他者のサポートがあればできる・できそうな領域（発達の最近接領域）です。

ここを重点的な引継ぎ対象とします。

定期的なフィードバックや壁打ち相手になりながら、徐々に裁量を渡していきます。

Low Risk / Low Effort：コンフォートゾーン
すでに1人で問題なくできる、安心・安全な領域です。

完全に任せます（移譲）。

ただし、ここに業務が留まっていくと、次第にストレッチゾーンへの挑戦がしづらくなることから成長が止まるため、この業務群をどう効率良くするかやアウトソーシングするかを考えてもらいます。

他にも Low Risk / High Effort に配置された業務は、不確実性が低いが時間も心労もかかる「個人的にやりたくない業務」かもしれないなど、配置されたエリア別で対話しその配置の背景を聴いていくと、より効果的な引継ぎや育成の方針が見えてきます。

これにより、「何でもかんでも教える」のではなく、「どこをサポートし、どこを任せ、どこは守るべきか」のメリハリがつきます。

3. 単位期間ごとの「あるべき姿」を、ストーリー形式で言語化する

Risk-Effort分析で、発達の最近接領域が明確になったら、次はそれを具体的なアクションに落とし込みます。

まずは WillかつShould やストレッチゾーンに配置された業務から、ユーザーストーリーのように「Aさんの上半期ストーリー」として、単位期間でどのような状態遷移をするのかを明示的にします。

例えば「マニュアルを読む」ではなく、「緊急時のアラート対応において、マニュアルを参照しながら1人で一次対応を完了できる」という状態を定義します。

また最後に、「結論としてどのような状態になりたいのか」をゴールとして掲げ、単位期間内に行動軸がブレないよう設定します。

こうすることで、引継ぎのゴールが「作業の完了」ではなく「状態の遷移（できない→できる）」になり、後任者も達成感を感じやすくなります。

無理のない引継ぎロードマップを作成したら、後任者が自走するための具体的なツールを整備します。

業務の流れを図示する（RACI図、業務フロー図）

複雑な業務プロセスや関係性は、文章よりも図で示す方が遥かに効果的です。

「業務フロー図」で全体の流れを可視化し、「RACI図」でステークホルダーとの関わりを明確にします。

これにより、後任者は「どういった業務の際に、どの程度、誰に何を聞けばいいか」を把握でき、間接的にどのような業務があるのかを一覧することもできます。

スキルマップ（星取表）を作成する

▲エンジニアのスキルマップの例

後任者が「今どのレベルにいて、次に何を目指せばよいか」を示すコンパス＝スキルマップ（星取表）は不可欠です。もし既存の基準がなければ、つくりましょう。

ここは根気がいりますが、今後引継ぎ時に必要な能力開発をする上で重宝しますし、評価をする上で指標がないと説明しきれず、無駄な軋あつ轢れきを生むことを防げます。

例えば私が技術広報として活動していた際は、この専門性を示す指標が調べた限りだと存在していませんでした。そこで広報活動オクトパスモデル分析を参考に、自身でPREOモデルというスキルマップを作成し、後任者がこの4つの観点を5段階のスコアで分け、自分の役割期待を立体的に理解できるようにしました。

P (Planning)：戦術策定力 目的を達成するための戦略を具体的な戦術に落とし込み、計画・実行する力。
R (Relationship)：関係構築力 社内外のステークホルダー（開発者、コミュニティ、他部署）と良好な関係を築き、協力を引き出す力。
E (Expressiveness)：情報表現力 技術的な知見や活動の成果を、ブログ、登壇、SNSなど最適な形で分かりやすく発信・表現する力。
O (Organization)：組織構築力 活動を属人化させず、組織的に推進するための仕組みづくりや、リスク管理、ブランド構築を行う力。

（作成の背景や詳細についてはこちらの記事に明記：「『PREOモデル』で整理する技術広報の専門性」 ）

このように暗黙的な役割期待に対しても言語化、可視化、整理をすることで、期待のズレを防止することができます。

本稿では、引継ぎを成功させるためのロードマップづくりとスキルの体系化について解説しました。

引継ぎは、単なる業務の伝達作業ではありません。

あなたが築き上げた価値を次の世代に繋ぎ、組織全体の力を底上げする「未来への投資」です。

そして、自分自身のスキルや経験を言語化し、他者へ移譲可能にするプロセスは、あなた自身のキャリアにとっても強力な武器となるはずです。

次回、最終回となる第3回では、引継ぎ直後の「自走を支えるコミュニケーション」について掘り下げていきます。