仕様書がない既存システムでも改修を依頼できる？最初に行う調査とは
- 4 日前
- 読了時間: 10分
更新日：3 日前
長年使っている業務システムを改修したい。しかし、開発当時の仕様書が見つからない、前の開発会社とも連絡が取れない。こうした状態でも、別の開発会社へ改修を依頼することはできるのでしょうか。
結論から言えば、仕様書がなくても、調査から始められるケースは少なくありません。 重要なのは資料が揃っているかどうかではなく、現在動いているシステムを確認し、ソースコードやデータベース、実行環境などから現状を読み解けるかどうかです。
はじめに：仕様書がないことと、改修できないことは同じではない
既存システムを長く運用していると、開発当時には存在したはずの資料や記録が残っていないことがあります。
たとえば、
開発当時の仕様書が見つからない
仕様書はあるが、その後の改修内容が反映されていない
開発を担当した会社や担当者がもういない
社内にシステムの詳しい人がいない
ソースコードはあるが、現在の本番環境と一致しているか分からない
といった状態です。
実際、長く運用されてきたシステムでは、「誰かが知っているはず」「どこかに記録があるはず」と思っていた情報が、いざ改修しようとすると残っていないことがあります。
しかし、仕様書がなくなったからといって、システムの動作そのものまで分からなくなったとは限りません。
現在動いている画面、ソースコード、データベース、サーバーやクラウドの設定、外部サービスとの接続、ログ、そして実際の業務運用など、現在の仕様を確認する手掛かりは複数あります。
そのため、まず必要なのは「仕様書を作り直すこと」ではありません。
改修対象について、現在どのように動いていて、どこを変更すると何に影響するのかを判断できる状態にすることです。
結論：最初に行うのは「改修」ではなく「現状把握」
仕様書がない既存システムでは、いきなり改修内容と金額を確定するのではなく、まず現行システムの調査が必要です。
調査の目的は、すべての仕様を完全に復元することではありません。
今回改修したい範囲について、
どこを変更する必要があるのか
変更すると、どこまで影響するのか
変更してはいけない部分はどこか
どのように試験すれば安全に変更できるのか
を判断できる状態にすることです。
この状態まで整理できれば、初めて具体的な改修範囲や見積条件を決めやすくなります。
既存システム改修を外部へ依頼するときの全体的な進め方については、関連記事「既存システムの改修を外注するときに失敗しないためのポイント」で詳しく解説しています。
調査を相談するとき、最初に分かる範囲で用意したい情報
最初から完璧な資料を作る必要はありません。
次の5点が分かる範囲であれば、調査の相談を始められます。
何を変更したいのか
現在どのような業務で使っているのか
システムへログイン・操作できるか
ソースコードや既存資料が残っているか
サーバー・クラウド・データベースなどの管理情報を確認できるか
分からない項目があっても問題ありません。
「何があるのか分からない」「どの会社が管理しているのか分からない」という情報自体も、調査範囲を決める材料になります。
仕様書より先に確認したい5つのもの
仕様書がなくても、現在のシステムを確認する材料が残っていれば、調査を進められる可能性があります。
1. 現在動いているシステム
まず確認したいのは、実際に利用されているシステムです。
画面を操作しながら、
どのような入力があるのか
どのような処理が行われるのか
どの画面へ遷移するのか
どのデータが表示・更新されるのか
を確認します。
利用者へのヒアリングも重要です。
「この画面でCSVを取り込んだ後、担当者が別画面で確認する」といった実際の業務手順は、資料だけでは分からない現在の仕様を理解する手掛かりになります。
2. ソースコード
ソースコードが確認できるかどうかは、改修可能性を判断する大きな材料です。
ただし、「ソースコードのファイルが残っている」だけでは十分ではありません。
確認したいのは、
現在本番で動いているものと同じソースコードなのか
Gitなどの履歴管理が残っているか
対象機能の処理を追えるか
ビルドや起動に必要な設定が揃っているか
といった点です。
古いソースコードが残っていても、現在稼働しているシステムと一致しているとは限りません。
そのため、ソースコード単体ではなく、現在の稼働環境や実際の動作と突き合わせて確認します。
3. データベース
業務システムでは、画面やソースコードだけを見ても影響範囲が分からない場合があります。
どのテーブルに何が保存され、どのデータが関連しているのかを確認することで、機能同士のつながりが見えてきます。
たとえば、画面上では単純な「顧客情報の変更」に見えても、
契約情報
請求情報
履歴情報
外部サービス連携用データ
などへ影響している可能性があります。
そのため、既存システムの改修では、データの持ち方まで確認することが重要です。
4. 実行環境・設定
既存システムでは、ソースコード以外の設定やプログラムが動作を支えていることがあります。
たとえば、
サーバーやAWSなどの構成
環境変数
定期実行されるバッチ
常駐プロセス
ファイルの保存先
メール送信設定
外部APIとの接続
ジョブスケジューラ
などです。
過去にシステム移行へ関わった案件では、移行計画上の構成要素には載っていなかった常駐デーモンが、実際にはシステムの動作に必要だったことがありました。
アプリケーション本体だけを見ていると、このような周辺処理を見落とす可能性があります。
既存システムを引き継ぐ際には、ソースコードだけではなく、実際の環境で何が動いているのかまで確認することが重要です。
5. 実際の業務運用
最後に確認したいのが、システムを実際に使っている人の業務です。
システム上では不自然に見える処理でも、
「この後に担当者がExcelで加工する」
「月末だけこの操作を行う」
「エラーになった場合は別画面から再実行する」
といった業務上の理由があることがあります。
一方、利用者へヒアリングすればすべて分かるわけでもありません。
長年使われているシステムでは、利用者自身も「この操作をすると結果が出ること」は知っていても、内部でどの処理が動き、どのデータへ影響しているのかまでは把握していないことがあります。
その場合には、ヒアリングで得た情報を手掛かりに、ソースコードやデータベース、実行環境から処理を逆方向にたどる、いわゆるリバースエンジニアリングが必要になります。
この読み解きにどれだけ時間がかかるかが、調査工程の期間と費用を左右します。
資料・画面・コード・運用を突き合わせて確認する
確認対象 | 主に確認すること |
既存資料 | 当初どのように設計されていたか |
現在の画面 | 現在利用者から見えている動作 |
ソースコード | 実際にどのような処理が実装されているか |
データベース | データの持ち方と機能間の関連 |
実行環境 | バッチ・外部連携・設定を含む実際の動作条件 |
利用者ヒアリング | 現在の業務でどのように使われているか |
既存資料は重要ですが、資料が存在するからといって、現在のシステムと一致しているとは限りません。
その後の改修が設計書へ反映されていなかったり、運用途中で設定だけ変更されていたりすることがあります。
そのため、既存システムの調査では、一つの資料だけを正解とせず、複数の情報を突き合わせて現在の状態を確認することが重要です。
仕様書が存在する場合でも、最終的には現在動いているシステムとの整合性を確認します。
改修したい場所だけでなく、その周辺まで調べる
既存システム改修で注意したいのが、「変更したい機能」だけを見て影響範囲を判断することです。
たとえば、
顧客管理画面に項目を1つ追加したい。
という依頼だったとします。
画面だけを見れば、小さな変更に見えるかもしれません。
しかし、その項目が、
顧客データベース
検索処理
CSV出力
帳票
外部システムへのデータ連携
夜間バッチ
などでも使われていれば、それらも確認する必要があります。
この場合、画面に入力欄を追加するだけでは改修は完了しません。
仕様書がない案件では特に、「変更する場所」ではなく、「変更するデータや処理が、ほかのどこから使われているか」まで追うことが重要です。
これが、調査前には改修規模を確定しにくい理由の一つです。
調査の結果、すぐに改修へ進めないこともある
仕様書がなくても調査可能なケースはありますが、必ず改修できるとは限りません。
たとえば、
稼働中のシステムへアクセスできない
ソースコードが残っていない
本番環境と手元のソースコードが一致しているか確認できない
データベースや実行環境を確認できない
開発環境を再現できない
古い技術や製品に依存し、検証環境を用意できない
ソースコードを保有していても、契約上、新しい開発会社が利用・改変できるのか確認できない
といった場合です。
特にソースコードについては、「手元にファイルがあること」と「第三者へ渡して改修を依頼できること」は別の問題です。
以前の開発会社との契約書や著作権・利用条件などを確認し、必要に応じて専門家へ確認することも検討してください。
また、技術調査の結果、
部分改修を続けるより、対象機能を作り直した方が安全
と判断することもあります。
その場合は、
そのまま改修する
一部だけ作り直す
段階的に置き換える
現状維持する
といった選択肢を比較します。
最初から「改修できる」「できない」を決めるのではなく、調査した結果をもとに次の判断をすることが大切です。
プレイリーソリューションズでは、現行システムの調査から相談できます
バックエンド開発に特化したシステム開発会社 プレイリーソリューションズ合同会社では、既存Webシステムについて、仕様書が揃っていない段階でも、現行調査・技術調査からご相談いただけます。
仕様書の有無だけで改修可否を判断するのではなく、
現在動いているシステム
ソースコード
データベース
サーバー・AWSなどの実行環境
APIや外部サービスとの連携
バッチ・常駐処理
実際の業務運用
などから、改修対象と影響範囲を整理します。
調査に一定の時間が必要な場合には、最初から改修全体の金額を固定するのではなく、まず調査工程を切り出し、
現状把握 → 影響範囲・リスクの整理 → 改修方針と対象範囲の確定 → 改修
と段階を分けて進める方法もあります。
「仕様書がないので依頼できない」と判断する前に、まず現在どの情報を確認できるのかを整理することで、次に取るべき方法を判断できます。
まとめ：仕様書の有無より、現行システムを読み解けるかを確認する
仕様書がない既存システムでも、すぐに改修を諦める必要はありません。
最初に確認したいのは、「設計書が何ページ残っているか」ではなく、
現在動いているシステムを、どこまで読み解ける状態にあるか
です。
画面、ソースコード、データベース、実行環境、外部連携、実際の業務運用を確認し、それぞれの情報を突き合わせることで、仕様書がなくても改修可能な状態へ整理できるケースがあります。
一方で、システムを読み解く難易度によっては、調査自体に相応の期間・費用が必要になることもあります。
だからこそ、いきなり改修見積を求めるのではなく、まず調査によって「何が分かるのか」「どこまで安全に変更できるのか」を明確にすることが重要です。
既存システムについて、「仕様書がない」「前の開発会社から十分に引き継げていない」「どこまで調査すれば改修できるのか分からない」という場合は、プレイリーソリューションズへご相談ください。
Java / AWSを中心としたバックエンド開発、API連携、既存Webシステム改修について、現行調査・要件整理から設計・実装・試験まで対応しています。
