📖
プロジェクト引継ぎマニュアル：まずはプロジェクトを引き継げるという幻想を捨てろ

2024/10/01に公開
 はじめにこの記事ではシンプルな前提から、現実的な引継ぎのプロトコルを導出する。
結論だけ見たい人は『ではどうすればプロジェクトをうまく引き継げるのか』をご覧ください。

 前提引継ぎという行為を以下のように定義する。
【定義】

業務(task)の引継ぎ(handover)とは、前任者が行っていた業務を後任者が十全に行える状態にすること、またはその状態にしようとする行為を指す。
プロジェクト(project)とは複数の業務からなる集合で、プロジェクトの引継ぎとはプロジェクト内で前任者が担当するすべての業務を後任者に引継ぐことを指す。
より抽象的には、引継ぎとは時間を隔てた作業者(worker)間の情報の伝達である。過去における業務x _ sをその未来において業務x _ tとして再現したい場合、過去の作業者Aは業務x _ sを再現するに足る情報を未来の作業者Bに送らねばならない。未来の作業者は自分で調査を行って不足情報を補うことも可能であることを考えれば、引継ぎを成功させるための条件は以下である。
すなわち、タスクx _ sに関する引継ぎの情報量H(x _ s)と、時刻tにおいて調査可能な情報量H(y _ t)の和が、タスクx _ tを十全に実行するに足る情報量I(x _ t)と同等かそれ以上でなければならない[1]。
逆にH(x _ s) + H(y _ t) < I(x _ t)となる場合、引き継ぎは失敗するものとする。引継ぎが失敗した業務は再現することができない。
作業者Aと作業者Bは同一人物であってもよいし、同一人物でなくてもよい。一般に同一人物である場合は引継ぎとは言わず、その人物が過去の作業を忘却することで作業を再現できなくなる現象として現れる。作業者の違いは本質的ではなく、引継ぎの本質とは過去から未来への情報伝達H(x _ s)のロスを未来時刻tにおいて調査可能な情報H(y _ t)以下に抑えることである。

 情報量条件をもう少し深く解釈する情報量は負になることはない。

I(x _ s), I(x _ t), H(x _ s), H(y _ t) \geq 0
また、過去の作業を再現する場合、未来でも同じだけの情報量が必要になると考えるのであれば、以下の条件は仮定してよい。

I(x _ s) = I(x _ t)
未来時刻tにおいて調査可能な情報量H(y _ t)は、その時刻におけるネット上の情報や社内にいてそのプロジェクトのことを覚えている人などの環境で上限が規定される。そこに作業者Bの情報収集能力がかかって決まるものであって、これはプロジェクトにとってコントロール可能な変数ではない。
したがってプロジェクトが引継ぎ可能であるかどうかを決める変数のうち、プロジェクト側でコントロール可能なものは引継ぎ情報H(x _ s)のみである。
一般に情報は
変換
伝達
などによって失われる。ゆえに

H(x _ s) \leq I(x _ s)
であると考えたほうがよい。より具体的には、

AとBが同一人物であれば
タスクx _ sの情報をメモに変換する過程で情報が失われる
過去の自分から未来の自分に記憶を介して情報伝達するとき、忘却することで情報が失われる


AとBが異なる人物であれば
タスクx _ sの情報をドキュメントに変換する過程で情報が失われる

AからBに情報を伝えるとき、伝え忘れたり誤った情報を伝えることで情報が失われる

といった伝送ロスが発生する。
H(y _ t)がアンコントローラブルである、つまり最悪のケースではH(y _ t) = 0となりえることを前提とすると、引継ぎを必ず成功させる条件は以下の条件しかありえない。

H(x _ s) = I(x _ s)
これがどういうことかを解釈すると、
作業者Bが言われたことを十分にこなす能力さえ持っているならば
作業者Bは作業者Aの指示通りに業務を行い、その業務を完了できる
という状態である。この条件が満たされているかをもっとも簡単に確認する方法は、実際に作業者Bが作業してみて、業務を完了できるかどうか試すことである。
むしろそれ以外の手段では確認が難しいことから、実際に作業者Bが引継ぎ情報H(x _ s)にしたがって作業を完了したことがない業務に関しては、伝送ロスが発生している可能性があり、引継ぎは失敗する可能性がある。

 この前提を認めるならば認識を改めるべきことまず引継ぎという作業自体に成功と失敗が存在し、無条件に成功するものではない。明確に成功条件を満たさなければ失敗するものである。引継ぎが成功する前提に計画を立ててはいけない。
引継ぎのための仕組みが作られていない組織での引継ぎ成功率は、体感５割程度である。
私が引継ぎを命じられた業務は歴戦のサラリーマンに比べれれば少ないかもしれないが、通常の苦労の範囲で引継ぎが可能であった業務は５割程度に留まる。３割程度は作り直しが必要、２割程度は再現が不可能であると上司に進言することになった。

 引継ぎの責任は誰にあるべきなのか引継ぎが失敗した場合、その責任は誰にあるのか？
一般に、労働者は自分に責任のない業務はやらなくてもよい。責任という言葉をどう捉えるかは人によると思うが、この記事では責任を以下のように定義する。
【定義】

責任者(person in charge)とは、業務に対して割り当てられるものであり、以下の条件のうち１つ以上を満たすものである。
その業務に対して主体的に取り組むことを命じられている。
その業務を正常に提供し、または改善することを期待されている。
その業務の継続可能性について判断する権限を持つ。
その業務が停止または継続不可能となった場合に不利益を被る。
不利益とは、復旧措置を実施する、代替手段を探す、異動や処罰の対象となるといった、当人にとっての負担の増加を指す。

責任(responsibility)があるとは、その業務の責任者であることを指す。
つまりその業務について責任がない者とは、言われたことさえやっていればよくて、業務の継続や改善を誰からも期待されておらず、業務の継続可能性について意見できる立場になく、業務が停止したり継続不可能になっても何の不利益もない者である。
その業務に対して責任がない場合、一般に労働者は自分に責任がある別の業務を優先する。また、労働者が自分が行う全体的な業務量を最小化したい場合は、自分に責任のない仕事を行わないことで達成される。逆に言えば、労働者の裁量で実施しない判断ができる業務がその労働者にとって責任のない業務である。
引継ぎの文脈に戻ると、一般に前任者はその業務を後任者に引き継いだ時点でその業務への責任を解除される。したがって引継ぎが完了した時点でその業務の責任者は後任者となる。
ここまでは明確であるが、問題は「引継ぎという業務自体の責任は誰にあるのか」という点である。
引継ぎが行われなかった場合に不利益を被るのは後任者である。一般に引継ぎが失敗と言える状態であっても前任者は引継ぎ完了後はなんら追及を受ける立場にはないことが多い。
しかし引継ぎ業務のすべての責任が後任者にあると定めた場合、前任者にとって労働量を最小化する最適戦略は一切の引継ぎ業務を行わないことである。現実的な解としては、前任者の善意、誇り、義務感や打算によってある程度の引継ぎがなされることが多いが、大抵は不十分な状態で引継ぎのタイムリミットに至る。
『情報量条件をもう少し深く解釈する』でも述べたが、プロジェクトの引継ぎにおいてその成否を決めるのは前任者から後任者へ伝達される引継ぎ情報H(x _ s)であることと合わせても、引継ぎ失敗の本質は、前任者にとって後任者に業務を引き継ぐべき動機がないことにある。
つまり引継ぎにおける前任者の責任や、前任者から後任者への責任移行の手順が明確化されていない組織は、プロジェクトを引き継げる仕組みになっていないのである。

 ではどうすればプロジェクトをうまく引き継げるのかここまでの議論で、少なくとも
業務に関する情報
業務に対する責任
の２つの要素が引継ぎにおいて重要な項目であることが分かった。
プロジェクトの引継ぎを行う場合には、この情報と責任を適切な手順で前任者Aから後任者Bに移行させなければならない。
ここでは議論をスムーズにするためにプロジェクトマネージャーMの存在も仮定する。Mは簡単に言えばAとBの上司で、AやBに対して業務命令を下せる立場にある。業務命令違反は懲戒処分の対象となる可能性がある[2]ため、Mは直接的に業務の責任者を定めることができる。

 手順１. Mは後任者Bを引継ぎ業務の責任者とする前任者Aには引継ぎを成功させる動機はないので、プロジェクトマネージャーMは引継ぎを成功させる動機のあるBを引継ぎ業務の責任者とする。
同時に前任者Aは引継ぎ業務においては後任者Bの指揮下に入る。後任者Bは引継ぎに必要な情報を前任者Aから聞き出す権利を持つ。前任者Aが情報を提供しない場合は、後任者BがプロジェクトマネージャーMに報告し、業務命令を発行してもらうことでその権利を強制的に行使することができる。
プロジェクトマネージャーMは後任者Bの引継ぎ業務責任者への任命と、上記の権利について、前任者Aと後任者Bについて明確に説明を行う。

 手順２. 後任者Bは前任者Aに引き継ぐべき業務の列挙を命じるプロジェクトは複数の業務からなる集合であるから、後任者Bが前任者Aから引き継ぐべき業務は一般に複数存在する。また、プロジェクトにおける役割をこなすためにどのような業務を引き継ぐべきであるかの情報は前任者Aしか把握していない。そのためこの作業は前任者Aの責任において実行されるべきものである。
したがってまずは後任者Bが前任者Aに対して引き継ぐべき業務の列挙を命じる。前任者Aが列挙した業務のリストLに対して、後任者BやプロジェクトマネージャーMは適宜修正を要求してもよい。
ここで作成したリストLに列挙されていない業務の引継ぎは行われない[3]。前任者A、後任者B、プロジェクトマネージャーMはこのリストLに基づいて引継ぎを行えば十分であることを合意する。
一般に人間は漏れなく列挙することが苦手であることから、このリストLは引継ぎ期間中であれば修正してもよい。
引継ぎ期間終了後には責任境界を明確にするため、このリストLを修正してはならない。
引継ぎ期間終了後にこのリストLにない項目の業務が必要になった場合にどう対処するかは、チームにおいて明確化しておく。たとえば以下のようなルールが考えられる。
このリストLは前任者A、後任者B、プロジェクトマネージャーM全員の合意に基づいて作成されたものであるから、その責任は全員にある。ゆえに全員に以下の義務を課する。
前任者A：引継ぎ期間終了後でも必要な情報を提供する義務[4]
後任者B：足りない情報は自ら補い必要な業務を再構築する義務[5]
プロジェクトマネージャーM：業務の再構築に必要な工数を確保する義務[6]

 手順３. 後任者Bは前任者Aに引継ぎ優先順の決定を命じるリストLに列挙された業務は引継ぎの優先順に基づいて並び替える。この並び替えは前任者A、後任者B、プロジェクトマネージャーMの誰が行なってもよく、基本的には合意に基づいて決定されるべきものであるが、もっとも多くの情報を有しているのは前任者Aであることから前任者Aの判断に基づいて実施されるべきものである。したがって後任者Bは前任者Aに引継ぎ優先順の決定を命じる。
どのように優先順をつけるかについては自由度があるが、一般にあとから復元できない情報ほど優先順が高い。すなわち、以下の順で優先順が高い。
前任者A自身が決めたこと
この宇宙でAしか知らない情報なので、引き継がれなかった場合、復元することは不可能である。

前任者Aが試行錯誤によって手に入れた情報
後任者Bも試行錯誤によって同じ情報を手に入れられるかもしれないが、まず不可能で、よくても前任者Aがかけたのと同じだけの労力を必要とすることが予想される。

前任者Aが長時間の調査によって手に入れた情報
後任者Bも調査によって同じ情報を手に入れられるかもしれないが、情報源が失われる可能性があるため、復元不可能となる可能性もある。

引継ぎに使える時間は有限であることから、この優先順に応じて可能な範囲で引継ぎが実施される。

 手順４. 前任者Aと後任者Bは業務の引継ぎ可能性を判断する前任者Aと後任者BはリストLに列挙されている業務について、現実的な時間内での引継ぎが可能であるかどうかを判断する。
前任者Aは主に引継ぎ資料の作成や業務の整理が引継ぎ期間内に完了するかどうかに基づいて判断し、後任者Bは主に引き継ぐ業務の難易度に対する自らの技量に基づいて判断する。後任者Bは前任者Aと相談し、引継ぎに不安のある業務を列挙する。
前任者Aと後任者Bはリスト内で引継ぎに不安のある業務がある場合、プロジェクトマネージャーMに速やかに報告する。
引継ぎが不可能であると判断された業務はプロジェクトマネージャーに報告の後、リストLから削除する。

 手順５. 後任者Bは前任者Aに引継ぎ計画の作成を命じるこの時点でリストLには引継ぎ可能である業務が優先度順に並んでいる。後任者Bは前任者Aに対して、このリストに基づいて引継ぎ計画Pの作成を命じる。引継ぎ計画とは、どの業務を引継ぎ期間中のいつまでに引き継ぐかを表にしたものである。
この手順は技術的には引継ぎ可能であっても時間的な制約により引き継ぐことができない業務を洗い出すものである。
引継ぎ計画Pの作成に必要な情報は以下の２つである。
前任者A：引継ぎ資料を作成するのに必要な時間
後任者B：引継ぎ資料に記された業務手順を追試するのに必要な時間
したがってこの計画書Pは前任者Aが叩き台を作成し、後任者Bが前任者Aと相談しながら修正する。
後任者Bは作成した引継ぎ計画PをプロジェクトマネージャーMに提出する。この計画書にない業務は現実的に引継ぎが不可能である。プロジェクトマネージャーMは以下の情報をもとに計画に不備がないことを確認し、前任者A、後任者B、および必要に応じてそれ以外のプロジェクトメンバーに対して業務調整を実施する。
引継ぎ可能な業務が優先度順に並べられたリストL。
手順４においてリストLから削除された、引継ぎが不可能であると判断された業務。
現実的な時間内に引継ぎ可能な業務がスケジュールされた引継ぎ計画P。

 手順６. 後任者Bは前任者Aに引継ぎ資料の作成を命じる後任者Bは前任者Aに対して、引継ぎ計画Pに基づいて引継ぎ資料Dの作成を命じる。
前任者Aは引継ぎ資料Dと口頭での指示があれば後任者Bが引継ぎ対象となる業務x _ sを業務x _ tとして再現できるように引継ぎ情報H(x _ s)を作成する。このあとで後任者Bが作業を追試して引継ぎ資料を加筆修正する手順があるので、この引継ぎ資料は不完全でもよい。
引継ぎ計画Pにおいて引き継がれるべき業務が

L _ P = \{ x ^ 1 _ s, x ^ 2 _ s, \ldots, x ^ n _ s \}
と列挙されるとき、引継ぎ資料Dとはこれら業務の引継ぎ情報の集合で、

D _ P = \bigl\{ H(x ^ 1 _ s), H(x ^ 2 _ s), \ldots, H(x ^ n _ s) \bigr\}
である。

 手順７. 後任者Bは前任者Aの引継ぎ資料を追試し加筆修正する引継ぎ成功の情報量条件に基づき、調査y _ tに依存しない引継ぎ成功の条件は

H(x _ s) = I(x _ t)
であった。これをもっとも簡単かつ確実に確認する方法は、実際に作業者Bが引継ぎ情報H(x _ s)に基づいて作業してみて、業務を完了できるか試すことであった。
そして逆に、実際に作業者Bが引継ぎ情報H(x _ s)にしたがって作業を完了したことがない業務に関しては、伝送ロスが発生している可能性があり、引継ぎは失敗する可能性があるのだった。
したがって引継ぎは後任者Bが前任者Aの作成した引継ぎ資料D _ Pに基づいて業務の追試を行い、成功できるようになるまで引継ぎ資料D _ Pを後任者Bが加筆修正することで完了とする。

 手順８. 前任者Aから後任者Bに業務の責任を移譲する手順７までで、前任者Aが引き継ぐべき業務は後任者Bも実施することが可能になっている。引継ぎが完了した業務から、その責任を前任者Aから後任者Bへと移譲する。
以上をもって前任者Aから後任者Bへ、プロジェクトについての情報と責任の委譲を完了とする。
再掲しておくと、責任者とは以下のような立場の者である。
責任者(person in charge)とは、業務に対して割り当てられるものであり、以下の条件のうち１つ以上を満たすものである。
その業務に対して主体的に取り組むことを命じられている。
その業務を正常に提供し、または改善することを期待されている。
その業務の継続可能性について判断する権限を持つ。
その業務が停止または継続不可能となった場合に不利益を被る。
不利益とは、復旧措置を実施する、代替手段を探す、異動や処罰の対象となるといった、当人にとっての負担の増加を指す。

責任(responsibility)があるとは、その業務の責任者であることを指す。
後任者Bは前任者Aの業務を代替していく必要があるので、たとえ引継ぎ期間中であっても、責任を委譲した業務については後任者Bが主体的に実施するのが理想である。引継ぎ期間中に前任者Aの指導のもとで業務に携われる利点があるほか、引継ぎ期間終了後に一度にすべての業務を移行したときに後任者Bの工数がパンクするリスクを避けることができる。

 引継ぎに備えたチーム運営を行う上記のような引継ぎ手順を書くと「理想的にはそうだけど現実的にはそんな工数取れないよね」などと下らないコメントが届きそうなのでその点についても対策しておこう。
まず、いざ引継ぎを行うことが分かってから上記のような手順を始めても遅いのである。引継ぎとは前任者の異動や退職に伴って発生するものであり、そうであるがゆえに知らされるのはギリギリになってからであることが多い。だがそうであるならば引継ぎとは将来的に発生することが確定している事象なのである。
そもそも担当者が突然死んだらどうするのだ。チームメンバーの死亡リスクに備えたチーム運営を行うのであれば、引継ぎとは本来工数 0 で完了できなければならない業務である。
『ではどうすればプロジェクトをうまく引き継げるのか』の章で説明した手順のいくつかは、あえて引継ぎ期間を設けなくとも、平常時の業務中に準備しておける部分が多くある。
平時からその準備をしていないのであれば、単に無計画であるか、引継ぎが失敗するリスクのヘッジよりも他の作業を進める判断をしたプロジェクトマネージャーの責任であって、要するにプロジェクトをマネジメントできていないだけである。

 行われた意思決定に関する情報は可能な限り残しておく引き継ぐべき情報の中でもっとも重要度が高いのは意思決定に関する情報である。
意思決定とは自動的に判断することができない不確定な状況に対して、人間が無理やりにでも判断を下して状況を確定させる行為である。したがって「なぜその意思決定をしたのか」は後任者が過去の状況を振り返っても復元することが不可能な情報であり、また引継ぎが始まってから過去のすべての意思決定について思い出して列挙することはほとんど不可能である[7]。
ゆえに重要な意思決定の記録はあとから参照できる形式で可能な限り記録しておくことが望ましい[8]。

 業務の再現手順書は常に作成しておくあなたがプロジェクトマネージャーであれば、プロジェクトメンバーにはチェックポイントごとに業務の再現手順書を作成するよう指示すべきである。
プロジェクトメンバーには業務の再現手順書を作成する動機は存在しないので、明確にルール化して責任を与えない限り、作業手順書（≒将来の引継ぎ資料）が作成されることはない。

 同一の業務に対して複数の担当者を割り当てて冗長化しておく重要度の高い業務に対しては主担当と副担当のように最低でも２名以上の担当者を割り当てる。業務の実施は主担当の判断で副担当とローテーションを組み、どちらの担当者でも同様に業務を実施できる状態を常に維持するべきである。
同じ業務を行えるメンバーが２人以上いるのであれば、うち１名のプロジェクト離脱に対して引継ぎにかかる工数は 0 である。

 以上の手順や準備を実施できないのであれば、引継ぎは諦めるここまでに述べたような手順や準備を実施できない、そしてその代替案すらも用意できないのであれば、引継ぎは担当者間の運ゲーであって失敗はやむなしである。
泣いても騒いでも引継ぎの失敗が帳消しになることはない。誰を咎めても失われた情報が蘇ることはない。潔く諦めよう。血は流れ続けるかもしれないが切り替えて次に行こう。次からは突然の引継ぎに備えてプロジェクトを運営しよう。

 おしまい責任の所在が明確でない業務は必ずなぁなぁになる。この記事はほとんど当然のことしか言っていないと思うが、この記事に価値があるとすれば、責任の境界と誰がどんな作業をするかを明確にしたことである。
引継ぎの悲劇が少しでも減りますように。

脚注
この関係は数学的にもかなり厳密に成り立つ。たとえば作業者Aのもとでタスクx _ sを行うプログラムが I(x _ s) = 900MB であったとして、引継ぎ時に作業者Bに手渡されたプログラムH(x _ s)が 700MB しかなければ、おそらく 200MB 分のモジュールを引継ぎ忘れている。この 200MB 分のモジュールがネット上からダウンロードできるプラグインであれば作業者Aの業務を復元することが可能だが、作業者A自身が作成したもので引継ぎ漏れしていた場合、作業者Bは作業者Aの作業を復元することは不可能である。 ↩︎
労働者は法律や倫理に反する場合を除き、業務上の必要性に基づく業務命令には従わなければならない。従わない場合は業務命令違反や債務不履行により懲戒処分の対象となることがある。 ↩︎
すなわち引継ぎ情報量がH(x _ s) = 0となるから、このリストLに存在しない業務は、あとから調べて分かる情報H(y _ t)のみから構成できる業務でなければならない。 ↩︎
前任者Aにとってアンフェアな状況は、引継ぎを行なったはずの業務に関して引継ぎ後も問い合わせが来ることである。 ↩︎
後任者Bにとってアンフェアな状況は、引継ぎが行われていない業務に関してその責任を追及されることである。 ↩︎
プロジェクトマネージャーMは管理者であるから取りこぼしたすべての事象の責任を自動的に負う。管理者はこのアンフェアを受け入れねばならない重い責任がゆえに大きな意思決定権を持つのである。大いなる力には、大いなる責任が伴う。 ↩︎
それができる天才的な記憶力を有しているものを除く。 ↩︎
私は GitHub の issue に書いてから decision_making というタグをつけてクローズしている。後任者はあとから decision_making タグで検索すれば時系列に意思決定の記録を検索することができる。 ↩︎