top of page

既存システムの改修を外注するときに失敗しないためのポイント

  • 5 日前
  • 読了時間: 5分

更新日：2 日前

既存システムの改修では、「何を直したいか」は分かっていても、「どこを変更すればよいか」「どの程度の影響があるか」が分からないケースが少なくありません。

本記事では、既存システム改修を外注する際に起こりやすい失敗や、調査から安全に進めるための考え方について解説します。


既存システムを調査し、影響範囲を確認しながら改修する様子

はじめに：既存システムの改修は、新規開発とは違う難しさがある


新しいシステムを開発する場合は、目的や必要な機能を整理した上で設計を進めることができます。


一方、既存システムの改修では、すでに動いている仕組みに対して変更を加える必要があります。


そのため、


  • 現在どのような処理が動いているのか分からない


  • 過去の仕様変更の経緯が残っていない


  • 開発した会社や担当者がいない


  • 仕様書と実際のシステム動作が一致していない


といった問題が発生することがあります。


「少し機能を追加したいだけ」のつもりでも、実際には影響範囲の確認から始めなければならないケースも珍しくありません。



既存システム改修でよくある失敗


1. いきなり改修見積を依頼してしまう


既存システム改修でよくある失敗が、十分な調査をしないまま「この機能を追加した場合の費用を教えてほしい」と依頼してしまうことです。


例えば、


「会員登録機能を変更したい」


「決済機能を追加したい」


という要望があったとしても、実際には以下の確認が必要になります。


  • 現在のシステム構成


  • 使用している技術


  • データベース構造


  • 関連する機能


  • 外部サービスとの連携状況


  • 運用中の制約


これらが分からない状態では、正確な開発範囲や費用を判断することは困難です。


結果として、


  • 最初の見積より作業量が増える


  • 追加費用が発生する


  • 予定していた期間内に終わらない


といった問題につながります。



2. 仕様書だけを前提に判断する


既存システムでは、仕様書が存在していても注意が必要です。


長期間運用されているシステムでは、


  • 仕様書が更新されていない


  • 実装と仕様書の内容が異なる


  • 運用上のルールが資料化されていない


ということがあります。


特に業務システムでは、「なぜこの処理になっているのか」という背景が重要になる場合があります。


単純にコードを修正するだけではなく、現在の利用方法や業務フローまで理解した上で変更する必要があります。



3. 安い見積だけで外注先を決める


既存システム改修では、調査不足の見積は後から問題になることがあります。


例えば、


  • 影響範囲を十分確認していない


  • 想定外の修正箇所が後から発生する


  • テスト範囲が不足している


といったケースです。


価格だけを見るのではなく、


  • 現行システムを理解できるか


  • 影響範囲を判断できるか


  • リスクを説明してくれるか


という点も重要になります。



改修前に確認しておきたいポイント


既存システムの改修を外注する場合、まず以下を整理します。


システムの管理状況


  • ソースコードは存在するか


  • 開発環境を再現できるか


  • 本番環境への反映方法は把握できているか


  • 現在の保守担当者は誰か


技術情報


  • 使用しているプログラミング言語


  • フレームワーク


  • データベース


  • 外部サービス連携


  • インフラ構成


改修対象


  • 何を変更したいのか


  • なぜ変更したいのか


  • 現在困っていることは何か


  • いつまでに必要なのか


ただし、これらがすべて最初から揃っている必要はありません。



仕様が分からない既存システムは、まず調査から始める


「改修したいが、現在のシステム構成が分からない」


「仕様書が残っていない」


このような場合、外注できないと考えてしまう方もいます。


しかし、実際には開発前に調査工程を設けることで進めることができます。


例えば、


  • ソースコード調査


  • データベース構造確認


  • 外部API連携確認


  • 現行処理の整理


  • 改修による影響範囲確認


などを先に実施します。


調査結果をもとに、


  • どこを変更する必要があるか


  • どの程度の開発規模になるか


  • 請負開発として切り出せる範囲はどこか


を整理できます。



調査工程と開発工程を分けるという進め方


既存システム改修では、最初から大きな開発契約を結ぶよりも、段階的に進める方が安全な場合があります。


例えば、


第1段階：現行調査・技術確認


目的：


「現在のシステムを理解し、改修方針を決める」


実施内容：


  • システム構成確認


  • ソース調査


  • DB確認


  • 改修ポイント整理


この段階では、目的や確認範囲を定めた準委任形式で進めることができます。


例えば、


「3営業日のうち8時間を目安に、現行システムを調査し、改修方針を整理する」


というように、目的・期間・確認範囲を明確にして進めます。



第2段階：改修範囲を確定


調査結果をもとに、


  • 開発対象


  • 成果物


  • 完了条件


  • 検収方法


を整理します。



第3段階：成果物単位で開発


範囲が明確になった後は、


「○○機能改修一式」


「○○API追加対応」


のように成果物単位で開発を依頼できます。


このように分けることで、発注側も開発側も責任範囲を明確にできます。



既存システム改修を依頼する会社選びのポイント


既存システム改修では、単純な実装能力だけではなく、調査・判断能力が重要になります。


確認したいポイントは以下です。


  • 既存コードを読み解いて調査できるか


  • 古い技術環境にも対応できるか


  • データベース構造まで理解できるか


  • APIや外部サービス連携を扱えるか


  • 改修範囲を整理して提案できるか


特に、仕様が完全に整理されていない段階から相談できる会社であれば、発注側の負担を大きく減らすことができます。



まとめ：既存システム改修は「分からない状態」から整理することが重要


既存システムの改修では、最初から完璧な仕様書や設計資料が揃っているとは限りません。


重要なのは、


「すべて整理してから開発会社を探す」


ではなく、


「分からない部分を調査工程として切り出し、整理してから開発範囲を決める」


という考え方です。


プレイリーソリューションズでは、Java / AWSを中心としたバックエンド開発、API連携、決済連携、既存Webシステムの改修に対応しています。


また、仕様書が残っていないシステムや、現在の構成が分からない状態でも、現行調査や技術確認からご相談いただけます。


調査によって改修範囲を整理した上で、成果物単位の受託開発へ進めることも可能です。


既存システムの改修や引き継ぎでお困りの場合は、お気軽にご相談ください。



bottom of page