開発途中のシステムを別会社へ引き継ぐときの進め方
- 2 日前
- 読了時間: 10分
システム開発の途中で、「現在の開発会社から別の会社へ切り替えたい」という状況になることがあります。
このとき最初に整理したいのは、次の開発会社ではなく、現在のシステムが機能ごとにどこまで完成しているのかです。「全体の8割が完成」といった進捗率だけでは、残っている開発をそのまま別会社へ渡すことはできません。
はじめに：開発途中の引継ぎでは「未完成の現在地」を渡す
完成したシステムの保守を別会社へ引き継ぐ場合と、開発途中のシステムを引き継ぐ場合には、大きな違いがあります。
開発途中では、機能ごとに状態が異なるからです。
たとえば、同じプロジェクトの中でも、
仕様が確定し、実装・テストまで完了している機能
実装は終わっているが、テストしていない機能
実装途中の機能
設計だけ終わっている機能
仕様そのものが決まっていない機能
が混在していることがあります。
この状態で「続きをお願いします」と新しい開発会社へ依頼しても、すぐに開発を再開できるとは限りません。
まず必要なのは、何が完成していて、何が未完成なのかを機能ごとに確認することです。
なお、すでに以前の開発会社と連絡が取れない場合については、開発会社がいなくなった既存システムでも、別会社へ改修を依頼できるのかで整理しています。
本記事では、現在の開発会社と連絡を取りながら、開発途中の案件を別会社へ切り替えるケースに絞って解説します。
結論：「何％完成」ではなく、機能ごとの現在地を固定する
開発途中の引継ぎで最も重要なのは、プロジェクト全体の進捗率を出すことではありません。
たとえば、
全体として80％完成しています。
という説明だけでは、新しい開発会社は残作業を判断できません。
必要なのは、機能ごとに、
仕様確定済み
設計済み
実装済み
テスト済み
開発中
未着手
仕様未確定
などの状態を整理することです。
さらに、現在残っている不具合や保留事項、これから決めなければならない仕様も合わせて整理します。
旧開発会社が考える「残作業」と、新しい開発会社が確認した「残作業」は一致するとは限りません。
その差を最初に確認することが、途中案件を引き継ぐ際の重要な工程になります。
まず作りたいのは「機能別の現在地一覧」
引継ぎ資料を大量に集める前に、まず機能一覧を作ります。
たとえば、次のように整理します。
機能 | 現在の状態 | 次に必要なこと |
ログイン | 完了 | なし |
会員登録 | 実装済み | 結合テスト |
CSV取込 | 開発中 | エラー処理の実装 |
外部API連携 | 実装済み | 異常系テスト |
管理画面 | 仕様検討中 | 項目・権限の確定 |
この一覧で大切なのは、単に「完了／未完了」の2択にしないことです。
たとえば「実装済み」でも、
開発者自身の確認だけ終わっている
単体テストまで終わっている
他機能と組み合わせたテストまで終わっている
発注側の確認まで終わっている
では状態が違います。
新しい開発会社から見れば、実装済みでもテストされていなければ、その機能を完成品として扱えない場合があります。
どの工程まで終わったのかを機能ごとに見えるようにすることが、途中引継ぎの出発点です。
未解決事項は「決まっていないまま」引き継ぐ
もう一つ重要なのが、まだ決まっていないことです。
開発途中では、
顧客側で検討中の仕様
開発会社から質問が出ている事項
一時的に保留した機能
未解決の不具合
暫定対応している処理
将来変更する前提で実装している箇所
などが残っていることがあります。
これらを無理に「仕様」として確定させる必要はありません。
むしろ、
この項目はまだ決まっていない この問題はまだ解決していない この実装は暫定である
という状態を、そのまま新しい開発会社へ伝えることが重要です。
開発途中の引継ぎで危険なのは、未確定事項が、確定済みの仕様と混ざってしまうことです。
仕様書だけでは判別できない場合は、課題管理ツール、メール、チャット、会議記録なども確認し、未解決事項だけを一覧にします。
「8割完成しています」だけでは引き継げない
たとえば、ある業務Webシステムを開発していて、
ログイン・会員管理
CSVデータ取込
外部API連携
管理画面
の4つの機能があるとします。
旧開発会社から、
全体として8割程度完成しています。
と説明されたとします。
ところが、機能ごとに確認してみると、
ログイン・会員管理：実装・テスト済み
CSV取込：実装済みだが、大量データのテスト未実施
外部API連携：正常系のみ実装済み
管理画面：画面はあるが仕様変更予定
という状態かもしれません。
この場合、「残り2割を作れば完成する」とは考えられません。
新しい開発会社は、
現在のシステムを確認する
機能別の実装状況を確認する
どこまでテスト済みなのか確認する
未解決事項を確認する
残作業をあらためて定義する
必要があります。
場合によっては、「完成済み」とされていた部分にも追加テストや修正が必要になるかもしれません。
だからこそ、旧会社が考える残作業をそのまま新会社への発注範囲にしないことが重要です。
ソースコードや環境情報は「現在地を確認できる最低限」を押さえる
もちろん、引継ぎにはソースコードや開発環境の情報も必要です。
ただし、本記事の中心は資産一覧を作ることではなく、途中まで進んだ開発の状態を確認することです。
最低限、
現在のソースコードを新しい会社が確認できるか
現在動いているシステムとソースコードの関係を確認できるか
開発・検証環境を確認できるか
は押さえておきます。
ソースコード、アカウント、契約、環境情報など「別会社へ渡す前に何を準備するか」については、途中案件とは別の論点も多いため、引継ぎ資産の整理として分けて考えた方が分かりやすくなります。
また、クラウドや各種サービスを旧開発会社側が管理しており、「誰の契約なのか」「自社側で管理権限を持っているのか」が分からない場合は、開発会社がいなくなった既存システムでも、別会社へ改修を依頼できるのかで解説している管理主体・権限の確認も必要です。
現在の開発会社が協力できるなら、質問できる期間を作る
旧開発会社と連絡が取れるのであれば、資料を受け取った時点で関係を完全に終了させるより、新しい開発会社が内容を確認して質問できる期間を作る方が引継ぎしやすくなります。
たとえば、
この機能はどこまでテストしたのか
この処理はなぜこの仕様になっているのか
この課題は対応予定だったのか
この画面は確定仕様なのか
この処理は暫定実装なのか
といった質問です。
コードを読めば分かる情報もありますが、「なぜそうしたのか」「この先どうする予定だったのか」はコードだけでは分からないことがあります。
進め方としては、
旧開発会社が現在地を整理する ↓ 新開発会社が確認する ↓ 不明点をまとめて質問する ↓ 残作業を再整理する
という流れが現実的です。
長期間、新旧の開発会社を同じ体制にする必要はありません。
質問窓口と回答期間を決めるだけでも、途中案件ならではの情報を回収しやすくなります。
開発途中の引継ぎは「調査先行」になりやすい
途中案件を新しい開発会社へ相談するとき、いきなり残開発全体の固定価格を求めると、双方にリスクがあります。
新しい会社は、
完成済みとされている機能の品質
実際に残っている作業
未確定仕様の影響
テスト不足の範囲
既存部分を修正する必要性
をまだ確認できていないからです。
そのため、途中案件ではまず、
固定価格で残開発を見積もれる状態なのか
を判断する必要があります。
プレイリーソリューションズでは、見積を出す前に案件の状態を確認し、未確定事項を前提条件として明示すれば積算できる**「条件付き」なのか、既存仕様や技術状態の不確実性が大きく、先に現状確認が必要な「調査先行」**なのかを判断しています。
たとえば、次のように分けられます。
条件付きで見積もれるケース
残っている不確定事項が軽微で、前提条件として明示すれば開発範囲を決められる。
調査を先行した方がよいケース
既存機能の完成状態、テスト状況、未確定仕様などが分からず、それによって工数や責任範囲が大きく変わる。
開発途中の引継ぎは、後者の**「調査先行」になりやすい案件**です。
分からない部分まで残開発の固定価格へ含めるのではなく、
現状調査 ↓ 残作業の確定 ↓ 開発見積もり
と段階を分けた方が、発注側も「何にいくら掛かるのか」を把握しやすくなります。
IPAの「システム開発の健全化に向けて」でも、最終的な成果物の完成状態を早期には明確に定義しづらい場合について、開発検討の進展に合わせて契約を段階化する「多段階契約」が紹介されています。資料では、多段階契約によって、徐々に明確になる仕様や開発途中の仕様変更による影響を抑える考え方が示されています。
これは開発途中のベンダー変更そのものを説明したものではありませんが、不確実な状態ですべてを一度に確定させず、情報が明確になる段階に応じて範囲を確定するという点では、途中引継ぎを考える際にも参考になる考え方です。
すぐに旧開発会社との関係を切らない方がよい場合もある
別会社へ切り替える方針が決まっていても、即座に旧開発会社へのアクセスをすべて停止することが安全とは限りません。
特に、
機能ごとの進捗が分かっていない
未解決事項をまだ回収できていない
現在の仕様を説明できる担当者が旧会社にしかいない
本番リリース直前である
重要な作業が途中である
場合には、先に引継ぎ情報を回収した方がよいことがあります。
切り替えで重要なのは「旧会社との契約をいつ終えるか」だけではなく、新しい会社が続きを判断できる情報をいつまでに揃えるかです。
仕様書などが十分に残っていない場合は、仕様書がない既存システムでも改修を依頼できる？最初に行う調査とはで、資料不足のシステムをどこから調べるかを解説しています。
引継ぎ前に確認したいチェック項目
新しい開発会社へ相談する前に、まず次を確認します。
機能一覧を作れるか
各機能を「完了・テスト中・開発中・未着手・仕様未確定」などに分けられるか
「完了」とした機能は、どこまでテスト済みか説明できるか
未解決の仕様・課題・不具合を一覧化できるか
暫定実装になっている箇所を把握できるか
現在のソースコードを新しい開発会社が確認できるか
旧開発会社へ質問できる期間を確保できるか
現在の情報だけで残開発を見積もれるか
難しい場合、現状調査を先に発注できるか
すべて揃っていなければ引継ぎできない、という意味ではありません。
分からない項目が多いほど、残開発そのものより先に「現在地を確認する調査」が必要だと判断できます。
プレイリーソリューションズでは現状調査から対応できます
開発途中の案件では、最初の相談時点で残作業を正確に確定できないことがあります。
プレイリーソリューションズでは、そのような場合に無理に残開発一式を固定するのではなく、
現在のソースコード・システムの確認
機能ごとの進捗整理
未解決事項の整理
技術的な調査
残開発範囲の整理
といった調査・整理工程から対応できます。
調査後に開発範囲を確定できる状態になれば、設計・実装・試験などを成果物単位で切り出して進めます。
途中案件だから最初から開発会社を変更できない、ということではありません。
まず、現在の情報で残開発を確定できるのか、それとも調査を先行すべきなのかを判断することが重要です。
まとめ：「残り何割」ではなく「何が残っているか」を引き継ぐ
開発途中のシステムを別会社へ引き継ぐときに重要なのは、
全体の何％が完成しているか
ではありません。
確認したいのは、
どの機能が完成しているのか
どこまでテストされているのか
どの機能が開発途中なのか
何がまだ決まっていないのか
どの課題が未解決なのか
です。
「8割完成」という全体進捗を、「機能ごとの現在地」へ分解する。
そのうえで、新しい開発会社が確認した残作業をあらためて整理し、固定価格で開発範囲を決められない場合は調査を先行させます。
事業会社の方で、「現在の開発会社から切り替えたいが、どこまで完成しているのか自社では判断できない」「途中まで作ったシステムを別会社へ引き継げる状態か確認したい」という場合は、プレイリーソリューションズへご相談ください。
