難しいようで実はとても難しい開発プロジェクト引継の心得

こんにちは。FLINTERSでシステム開発プロジェクトのプロジェクトマネージャーを勤める加藤です。2024年1月にFLINTERSが10周年であることを記念して絶賛ブログリレー中です。今回私は69日目のはず。

最近はありがたいことに弊社を指名していただき、お取引先から既存の開発プロジェクトを弊社の開発チームへ引継ぎたいといったご相談を頂くことが少しづつ増えてきました。

会社としてはビジネスチャンスが増えるということで大歓迎です。一方で、システム開発プロジェクトの引継は、新規開発と比べてもそれ同等、いやむしろ、新規開発プロジェクトよりも難易度が高いかもしれないと個人的には考えています。

FLINTERSは、FLINTERS VIETNAMというオフショア会社があるため、会社としても私個人としても日本国内で開発した開発物が運用保守フェーズに移行した際に、その保守運用をハノイの開発チームに移管するといった経験が多い会社だと思います。

今回のブログでは、非エンジニアであるプロジェクトマネージャー観点からみた、開発プロジェクトの引継のコツについて、当時私が管轄していたチーム向けに作成した社内用文章を改変しながら、私の考えを紹介したいと思います。

引継の基本精神

引継を受ける者にとって、有用であるものであること。引継される側の観点で進めること。
完全な資料は作成しない（できない）ということを理解すること。

引継の場面を考えると、既存知識を持った開発プロジェクトを手放す側(引渡す側)が主導することになります。その時に引継を受ける側の視点にどれだけ寄り添えるかというのは、とても大事な基本精神となります。また、コードがわかりやすく書いてあるからそれを読めば全てがあるといった傲慢な考えはすてるべきです。コードのなかには、なぜその実装に至ったのかと言った背景などは書かれていることはほぼありません。

一方で、引継を受ける側は、全てを完全に説明するドキュメント　（仕様書、機能一覧等）を引渡す側へ求めることは不可能であるという事実を認識すべきです。読んで全て理解できるドキュメントを求められても引渡す側は用意できません。また、今、動いているツールの仕様は、実際のコード及び利用環境の設定内に書いてあることが全てで、ドキュメントと一致する保証はありません。同時に、バグやエラーのないシステムはないため、コードに書いてあることが、正解とは限りません。

引渡す側、引継ぐ側ともに、引継資料だけでなく、引継プロセス（議論、実際の運用）なしに、引継ぐシステムを引継ぐ側が理解できることはないことを受け容れましょう。

そして、全てを理解してもらえるまで引継げない、全てを理解できるまで引継がない、どちらの姿勢にも私は反対します。実際に運用や、リファクタ・リビルド作業を通じて理解が深まるものです。

引継プロセスが開始したら、予め、引渡す側が責任をもっている期間と、引継を受けた側が責任をもつが、引渡す側もサポートできる期間のように並走期間を計画しておきましょう。

引継資料とは詳細な設計書ではなくバケーション写真である

Jeff Pattonの名著である「ユーザーストーリマッピング」を真似て言えば、引継資料はバケーション写真です。その写真に楽しかった休暇の光景が全てが記録されているわけではありません。その写真をみることで、議論のきっかけ、参照資料として理解を助ける、記憶を維持させるために有効なものです。

繰り返しになりますが、引継資料とは、正解が全て網羅されているものではありません。また全ての内容がアップデートされるものではありません。

引継プロセス及び準備すべき資料

引継資料はあくまでバケーション写真です。このバケーション写真を通して、議論を重ね、実際に手を動かしていくプロセスを通じて、既存ツールについて理解が深まります。ドキュメントの読み込みはもちろん引継ぎプロセスには欠かせないものですが、それが全てではありません。ドキュメントはきっかけであり、それをもとに議論し、手を動かしていくことが引継プロセスです。

標準資料・プロセス

くどいですが、今まで紹介した基本精神を理解した上で、引継時に準備する資料、プロセスについては下記のものを標準として定めます。

標準資料

インセプションデッキ（プロジェクトの目的、ステークホルダー分析などを含むもの）
ER図
システム構成図(インフラ)
機能概要
ユースケース概要
統合テスト受入テストなどのテストケース
ユビキタス言語表
コードリポジトリ

インセプションデッキはアジャイル開発の現場ではよく利用されるドキュメントですが、これはプロジェクト憲章と読み替えて頂いても結構です。

発展資料

対象プロジェクト・開発物の難易度に応じてとくに必要な箇所のみにしぼって用意するとよいもの。

データフローチャート
シークエンス図
ロジックフローチャート

引継プロセス

標準資料と発展資料の説明会・質問会
ユビキタス言語の理解を深めるためのディスカッション
現機能のデモンストレーション
協働で現ツールを運用保守する並行運用期間

引継完了判断

残念ながら、引継にかけられる時間は無限では有りません。完璧ではないとわかりながらも、引渡す側の関与をどこかでゼロにする必要があります。それぞれのプロジェクトに応じて判断基準は異なるとは思いますが、参考として過去の私のチームの判断基準を紹介します。

■ProjectManager

　引渡す側の参加がなくても顧客の要望を理解し、理解できなければ質問をできる状態になった。
　チームの状況に応じて、開発側の要望を伝えることが出来る関係性を構築できた。

■開発チーム

ツールが求められる標準的な使い方をしてる範囲における、監視・エラー対応が、例えばユースケースが一巡する期間（例えば月末月初のバッチ処理がある場合は1ヶ月）独力で運用できるようになった。
前任者に確認することなく、追加機能要望がきた際に、改修箇所の特定と具体的な見積もりが実施できる状態までシステム理解が進んだ。