継ぐ人たち
（念のために書いておくと， この話はオープンソース・プロジェクト等では当てはまらないと思うのであしからず）
興味深い話。
どんなプロジェクトであれ「引き継ぎ」は重要なプロセスだ。 「引き継ぎ」というのはプロジェクト内のある役割から離れる人と次にその役割に就く人との間で交わされるコミュニケーションをさす。 「引き継ぎ」はプロジェクト内での異動でも発生するしプロジェクト外の人的資産を入れ替える場合にも発生する。 しかし（プロジェクトの規模や内容にもよるが）プロジェクト内での異動であれば引き継ぎは端折られることも多い。 何故なら， 引き継ぐ人も引き継がれる人も， そのプロジェクト（とその中におけるメンバの役割）についてよく知っているからだ。
ところで「プロジェクトについてよく知っている」とはどういうことだろう。 もちろんプロジェクトの目的や要求等について知っているのは当然だが， 他にも重要なものがある。 プロジェクトメンバ間で共有される「文書化されない情報」だ。 それは普段は個々のメンバの頭の中にあって本人も忘れているが， メンバ間のコミュニケーションを通じ必要に応じて引き出されるものだ。 どんなに上手く「引き継ぎ資料」を書いても， そこに「文書化されない情報」は載らない。 何故なら普段その情報は忘れられているから。 忘れているものを文書化などできない。
私は基本的には「引き継ぎ資料」なるものは不要だと考える。 「引き継ぎ資料」として文書化できる情報は， どう上手く書いても既にある文書の劣化コピーにしかならない。 それならば既にある仕様書や設計書や（ソフトウェアならプログラムコードや）議事録や通信記録を見たほうが早い。 （余談だが， メール等の通信記録はメンバ間で共有し常に閲覧できる状態にすべきだ。 FAX 文書も残らず PDF 化しておくべき。 一番いいのは Wiki 等の黒板型ツールやバグトラッキングツールのようなものを使うことだ）
ならば「引き継ぎ」とは何をすればいいのか。 それは引き継ぐ人と引き継がれる人が一緒になって作業をすることだ。 その間に引き継がれる人がすることはひとつ。 （文書化されているいないに関わらず）プロジェクト内の情報にアクセスする方法を知ることだ。
新しく入ってくる人が最初に困るのは， 自分が分からないことについて， どうやって解決すればいいか（つまりどうやって目的の情報にアクセスするか）が分からないことである。 膨大な資料を与えられても資料のどこを見れば解決するのか分からなければ（それを完全に知ってるのは資料を書いた人のみだ）ただの資源ごみである。 だから前任者に訊きまくることになる。 どうせ訊きまくるのだから， 最初からそれを勘定に入れた上で「引き継ぎ」というプロセスを組んだほうが賢明である。
新任者に引き継ぐ人は， 決められた期間内に新任者が独り立ちできるようサポートする。 読み手を無視した「引き継ぎ資料」をガリガリ書いた上で更に新任者に訊きまくられるなんてのはコストの無駄であり人的資産の損失でもある。 それなら最初から新任者とペアで作業したほうが効率的だし， 「引き継ぎ」によるプロジェクトの遅延も小さくできる（前任者も向後の憂いなく新しい仕事に専念できる）。 もしこの過程で今まで文書化されなかった情報が顕在化すれば更にラッキーである。 それを文書にしていけば， それはそのままプロジェクトの資産になる。 つまり「引き継ぎ資料」というのは引き継ぐための資料ではなく， 「引き継ぎ」というプロセスにおける成果物なのだ。
大抵の場合， プロジェクト全体の生存期間に比べて， メンバの就任期間のほうが短いものだ。 故に， あるプロジェクトにおいて「引き継ぎ」は必然的に発生するものである。 だから「引き継ぎ」を（単なるイベントではなく）プロセスとして積極的に組み込むことを考えるべきだと思う。