YU2TA7KA's BLOG

派生開発、組み込み開発周りのこと。

システム開発途中のプロジェクトを引継ぐということ



はじめに

新しいプロジェクトを始める時にやっておくべきこと 8つという記事を書きました。しかし、現実には既にあるプロジェクトを途中で引継ぐことで自分がプロジェクトを始めるという場合があります。この引継ぎをする場合、どのような注意をするべかということをまとめます。

システム開発途中のプロジェクトを引継ぐということ

f:id:yuji-tanaak:20180414070502p:plain

引継ぎ後の立場

渡す側は、引継ぎ前までは責任者です。しかし、引継ぎ後の立場は無関係で他人になります。場合によっては、引継ぎ後もそのプロジェクト関係者と連絡をとれる状態にある場合もありますが、そうでない場合は無関係で他人になります。
引継ぐ側は、責任者の立場になります。そのため、プロジェクトを引き継いだ者なので状況不明です、のようなことは言い訳になります。つまり、引継ぎ完了時点でそのプロジェクトに対する100%の理解が理想です。しかし、現実的には感覚的に80%あれば良い方ですし、50~60%程度の理解で徐々に理解を深めてことが多いでしょう。

引継ぎ時の態度

渡す側は、引継ぎ前は責任者のため、能動的に引継ぎ作業を実施する責務があります。しかし、引継ぎ後の立場は他人となる構造のため、形式的に引継ぎ作業を実施すれば、その後自分にとって害はありません。
逆に引継ぐ側は、受動的に引継ぎ作業をする構造になっています。しかし、引継ぎ後の立場は責任者になります。そのため、引継ぎ作業時にはこの構造に抗って、能動的に情報収集するべきです。ただし、構造に抗うことになるため、非常に大変で難しいです。例えば、状況がよくわかっていないけれども、現状を推測して、引継ぎ説明に漏れがないか指摘する必要があるなど。

引継ぎ時に期待される振舞い

渡す側は、プロジェクトに必要な情報を全て提供する必要があります。プロジェクトの引継ぎに必要な8つの項目という記事に必要な情報が丁寧に整理されています。*1この8項目*2が引継がれることを期待します。
引継ぐ側は、プロジェクトに関する全理解(目的、状況、リスクなど)が期待されます。しかし、構造的に受け身でプロジェクト内容を説明される可能性が高いです。そこで、先の8つの項目を引継ぐ側が意識して、情報収集するべきです。引継ぎの場で質問をし、必要ならば新たに資料を作成することもすべきです。また、渡す側が口頭のみの説明で完了させようとしたら、それはドキュメント化するようにすべきです。後に記録されない情報は、大体忘れます。

おわりに

プロジェクトを引継ぐ際の注意点を、引継ぎの構造を元に整理しました。私はプロジェクトを引継いだ後に、時間差で引継ぎ不十分による問題にあいました。それに対する反省の意味を込めてまとめた次第です。プロジェクト引継ぎをされる方の助けになれば幸いです。



*1:素敵な記事をありがとうございます。そうそう!と思うことばかりで、完全に同意です。

*2:8項目
1.引継ぎの対象者と条件
2.プロジェクトの体制
3.システムの概要
4.スケジュール
5.主な懸案事項
6.予算状況
7.その他抱えている仕事
8.顧客の体制