既存システム改修では、画面上は小さな変更でも、現行調査や外部API、影響確認、試験によって作業量が大きくなることがあります。本記事では、改修費用を左右する要素と見積を比較するポイントを解説します。

既存システムの開発会社を変更するとき、ソースコードだけを渡してもすぐに開発を再開できるとは限りません。現在のバージョン、開発環境、DB・外部サービス、機密情報や権利関係まで整理することが重要です。本記事では、実際の引継ぎ経験も交えながら、別会社へ渡す前に確認したい項目と、情報不足時の進め方を解説します。

開発途中で委託先を変更するとき、「全体の8割が完成」という進捗率だけでは続きを発注できません。重要なのは、機能ごとの完成状態、テスト状況、未解決事項を整理することです。本記事では、途中案件の現在地を整理し、調査先行か残開発の見積もりへ進めるかを判断する方法を解説します。

以前の開発会社がいなくなっても、既存システムを別会社へ引き継げる場合があります。重要なのは、仕様書の量だけでなく、自社がシステムの管理権限を確保できているかです。本記事では、別会社で改修を再開するために整理したい管理主体と、引継ぎ調査の進め方を解説します。

仕様書がない既存システムでも、現在の画面やソースコード、データベース、実行環境などから調査を始められる場合があります。改修可否を判断するために最初に確認したいポイントを解説します。

既存システムの改修では、新規開発とは異なる難しさがあります。仕様書がない、開発会社が分からない、影響範囲が判断できない場合でも、調査工程から整理することで安全に外注できます。