作成者以外が触れないと分かったら
作った人しか直せないシステムを改修する前に 最初に確認する5項目
画面の項目を一つ増やしたいだけなのに、どこへ影響するか分からない。作った人へ聞かないと触れない。そんなとき、いきなり全面刷新から考える必要はありません。
まず一つの変更について、5項目をそろえます。分からない項目は、実装前に調べる範囲です。これで、小さく直せる可能性があるのか、調査を先にするのか、部分的に作り直すのかを検討できます。
5項目を先に見る先に結論
先に決めるのは、直し方ではなく「安全に変えられる範囲」
作った人しか直せないと分かったとき、よくある反応は二つです。動いているので触らないか、全部を新しくするか。しかし、一つの変更のために全体を決める必要はありません。
小改修として実装見積もりへ進むのは、5項目に未確認がない場合です。つまり、止められない業務、変更の再現条件、稼働版と変更履歴、確認・公開・復旧、データ・連携・権限を説明できる状態です。未確認が一つでもあれば、その欄を先行調査として切り出します。5項目は改修可否を保証する基準ではなく、調査と実装のどちらを先に見積もるかを整理する入口です。
作らない選択肢も残します。変更を止める、業務手順を変える、既存サービスの設定で代える、今の道具を連携する。それでも必要な部分だけを改修します。
見積もりの前に
改修前に確認する5項目
システム全体ではなく、いま一番困っている変更を一件だけ選びます。確認できない欄は「未確認」と書き、調査範囲にします。
- 01
止められない業務
その画面ではなく、止まると困る仕事を書きます。誰が、いつ、何を完了できなくなるのか。許容できる停止時間と、変更を避ける日も決めます。
書くこと：対象業務 / 利用者 / 締め時刻 / 許容停止時間 / 避ける日 - 02
変えたい動きと再現手順
「使いにくい」ではなく、一件の具体的な操作で現状と変更後を比べます。入力、押すボタン、表示される結果、期待する結果を並べます。
書くこと：対象データ / 操作順 / 現在の結果 / 変更後の結果 / 完了の証拠 - 03
今動いている版と変更履歴
手元のソースコードと、本番で動いているものが同じとは限りません。保管場所、最後に公開した日、変更した人、設定ファイル、手作業の修正を確認します。
書くこと：ソースの場所 / 稼働版 / 最終変更日 / 変更記録 / 環境ごとの差 - 04
確認・公開・戻し方
どこで試し、誰が良否を決め、どう本番へ反映し、問題が起きたら何分でどこまで戻すかを書きます。戻した後に業務を再開できるかまで見ます。
書くこと：確認環境 / 確認データ / 判定者 / 公開手順 / 復旧手順 - 05
データ・連携・権限
一つの画面変更でも、CSV、帳票、他システム、夜間処理、利用者権限へ影響することがあります。読み書きするデータと実行アカウントを一覧にします。
書くこと：更新データ / 出力帳票 / 外部連携 / 定時処理 / 実行アカウント
一件だけ埋める
「改修前の現状確認シート」の記入例
ここでは、受注一覧へ「保留理由」を追加したい場面で、5項目の埋め方を示します。
- 01止められない業務
- 平日17時の出荷データ確定
営業・倉庫が利用。停止は30分以内。月末最終営業日の変更は避ける。
- 02変更の再現条件
- 受注番号A-1024を保留にする
現在は一覧で理由が見えない。変更後は一覧と出荷CSVへ同じ理由を表示する。
- 03稼働版と変更履歴
- 本番との一致は未確認
ソースの保管場所は分かるが、本番へ最後に反映した版との照合が必要。
- 04確認・公開・復旧
- 復旧の再現が未確認
確認環境はない。データのバックアップはあるが、戻す手順を試した記録がない。
- 05データ・連携・権限
- 夜間連携の権限が未確認
一覧、出荷CSV、夜間連携が関係。夜間処理の実行アカウントを確認する。
稼働版の照合、確認環境、復旧手順、夜間連携の影響を、実装見積もりから分けます。「項目を追加する費用」だけを先に確定しません。
未確認は同じ重さではない
業務が止まる順に、調べる項目を並べる
空欄をすべて埋めてからでないと改修できない、という意味ではありません。止まったときに戻せるか、誤ったデータを広げないか、変更の理由を説明できるかの順に見ます。
業務停止と復旧
本番だけで試す、戻す手順を再現できない、業務再開の判定者が決まっていない。この未確認が残る間は、実装より先に確認環境と復旧を整えます。
データ・連携・権限
画面では小さな変更でも、CSV、帳票、夜間処理、外部サービスへ同じ値が渡ることがあります。入出力と実行アカウントを追ってから範囲を決めます。
履歴と設計の理由
過去の理由が分からなくても、稼働版、再現条件、公開・復旧がそろえば限定改修できる場合があります。変更対象に関わる理由から調べ、全履歴の復元を前提にしません。
たとえば、説明コメントが少ないことより、バックアップを戻した後に業務を再開できるか分からないことを先に扱います。資料の量ではなく、失敗時に守れない業務から順に調査します。
分かった状態に合わせる
5つの開始方法を分ける
変更の大きさではなく、安全条件をどこまで説明できるかで、最初に見積もる作業を変えます。
変更しない・業務手順で代える
既存の備考欄や手順変更で目的を満たせるなら、今回は作らない。変更による停止リスクと比べます。
小改修として進める
5項目に未確認がない。影響範囲と完了条件を一枚にし、最終判断は必要な技術調査で確かめる前提で実装見積もりへ進みます。
調査を先にする
稼働版が分からない、本番以外で試せない、復旧を再現できない。未確認事項を減らす成果物と期限を見積もります。
部分再設計を比べる
一つの機能へ依存が集中しているが、周囲との境界は分かる。同じ手戻りが起きる範囲だけを分け、テストを置いて直します。
再構築を比較する
公開・復旧を再現できず、止められない業務を守れない。部分的に切り離す境界も作れないときに、段階移行を含めて比べます。
外部へ頼む前に
調査と実装の見積もりを分ける
「全部調べて、直してください」では、どこまでが調査で、いつ実装費が決まるのかが曖昧になります。最初の依頼では、次の四つを確認します。
- 1
現在のソースと稼働版が同じだと、何を使って確かめますか。
- 2
影響範囲の確認に、どの環境・データ・権限が必要ですか。
- 3
調査後に、影響一覧、確認項目、公開手順、復旧手順のどれが返りますか。
- 4
何が分かれば、小改修・部分再設計・再構築の実装見積もりへ移れますか。
調査の終了条件が決まっていれば、調べ続ける契約にも、根拠のない実装見積もりにもなりにくくなります。
今日、一件だけ
分からない欄を、最初の調査範囲にする
システム全体の仕様書を完成させる必要はありません。いま一番困っている変更を一件選び、5項目を埋めます。分からない欄には「未確認」と書きます。
その未確認が、最初に調べる範囲です。安全条件がそろったら、小改修の依頼メモへ進みます。
迷ったときの確認
よくある質問
ソースコードがあれば、小改修として依頼できますか？
ソースがあるだけでは決められません。本番で動いている版との一致、一件の再現条件、影響先、確認・公開・復旧を説明できるかを見ます。一致を確かめられなければ、最初の依頼は実装ではなく照合です。
AIでソースを解析すれば、すぐ直せますか？
ソースの読み取りは助けられても、現在の稼働版、業務上の正しい動き、実データ、外部連携、公開・復旧の可否まではソースだけで決まりません。AIの解析結果も、5項目のどこを確認できたかで使います。
どの状態なら再構築を比較しますか？
公開・復旧を再現できず、止められない業務を守れないうえ、部分的に切り離して直す境界も作れない場合です。調査前から全面刷新と決めず、継続改修と段階移行を同じ条件で比べます。
根拠と着想
確認した公開資料
次の2件は、作成者以外が理解しにくい状態と、社内だけで品質を確かめきれない状態で、責任者が外部の診断・検証を選んだ事実を確認するために使いました。
- オージス総研「組み込みソフトウェア開発品質改善事例 株式会社デュプロ様」内容・所属は2024年2月時点。デュプロのソフトウェア設計責任者が、担当交代と継ぎ足しで設計経緯が分からなくなり、外部の品質改善支援を選んだ事例です。主題の発火と外部診断の購入を支えます。
- SHIFT「株式会社ROUTE06様 導入事例」取材内容は2026年4月時点。ROUTE06の取締役が、自社だけではテストを網羅できないとして第三者検証を選び、追加テスト・期間・予算を承認した事例です。品質確認を外部へ頼む判断を補強しますが、作成者依存の直接事例ではありません。
本文の5項目と開始方法は、この2資料の様式ではなく、知式が実務上の初期整理としてまとめたものです。改修の安全性や開始方法を保証する基準ではなく、未確認事項を調査範囲として明らかにするための入口です。