システム開発の途中で変更したいとき、追加費用はどう判断する？

試作品を触ってみると、打ち合わせでは気づかなかったことが出てきます。「この一覧にも担当者名がほしい」「確認してから帳票を出したい」。使う場面が見えて初めて分かることはあります。だから、変更が出たこと自体を失敗とは考えなくていい。ただ、思いついた順に足していけば、費用も使い始める日も決めにくくなります。

社長が心配なのは、どこまでが最初の見積もりで、どこからが追加になるか分からないこと。現場の担当者が心配なのは、使いにくいところを伝えても「もう決まったから」と止められることかもしれません。この記事では、開発中に出た希望を一枚の記録にまとめ、必要性と契約範囲を確かめて決める方法を説明します。以下の業務場面は説明用の仮定例で、Ｂ．Ｉ．Ｙの顧客の実話ではありません。

まず「何を直すか」より「何が困るか」を残す

変更希望を「ボタンを追加する」とだけ書くと、開発側には必要な理由が伝わりません。同じ希望でも、毎日止まる作業を解消するためなのか、たまに使う便利機能なのかで、優先順位は変わります。まず今の画面で何が起き、誰の次の仕事が止まるのかを書きます。

例えば倉庫の出荷確認画面に、担当者名を表示したいとします。「担当者名を足してほしい」だけでは、入力する人を増やす話なのか、既に記録している名前を一覧に出すだけなのか分かりません。「作業が途中で止まった一件について、次の担当者が確認先を探している」と理由を添えると、必要なのは名前なのか、担当の引き継ぎや確認待ちの表示なのかを検討できます。

要望した本人を責める必要はありません。画面を使って分かった問題を、仕事の言葉に戻すことが大切です。社長はそれが会社の優先課題に合うかを見て、現場はどの場面で困るかを伝える。役割を分けると、希望の大きさだけで判断しにくくなります。

不具合、範囲の認識違い、新しい希望を分けて確認する

次に、当初決めた内容と照らし合わせます。決めていた動作ができていないのか、同じ説明を違う意味で受け取っていたのか、それまで対象にしていなかった機能が必要になったのか。ここを一緒にして「変更は全部追加料金」「修正なら全部無料」と考えると、話がかみ合いません。費用の扱いは、契約や合意した内容を確かめて個別に決めます。

例えば「確認済みの注文だけを納品書に出す」と決めていたのに、未確認の注文まで出てしまうなら、まずその合意どおりに動いているかを確認する問題です。一方で、当初は担当者一人で確認する想定だったところへ、管理者の承認を追加したいなら、誰がいつ確定するかという新しい仕事も含めて整理します。見た目はチェック欄が一つ増えるだけでも、未承認の扱いや取消、権限、出力の条件に影響する可能性があります。

認識違いなら、見積書の項目名だけで決着をつけようとせず、帳票の見本、画面案、打ち合わせの記録を並べます。「請求書を作る」に何の書式と確認手順を含めていたか。一方が記憶を押し通すより、同じ資料を見て、決まっていることと追加で決めることを分けた方が進めやすくなります。

小さく見える変更も、次の仕事まで確かめる

画面一か所の修正が、その画面だけで終わるとは限りません。入力した情報が帳票、集計、通知に使われているなら、それぞれで確認が必要です。使う人が増える場合も、見せてよい情報や操作できる範囲を調べます。開発側には、変更する場所だけでなく、影響する場所と確認に必要な作業を説明してもらいましょう。

建築業の発注書を作るシステムで、発注後の変更理由を残したい場面を仮に考えます。自由に書く欄を一つ加えるだけで足りる場合もあります。ただ、その理由を協力会社に送る書類へ載せるのか、社内だけで見るのか、前の発注内容を残すのかによって作業は変わります。発注書を作り直したとき、既に渡した書類と区別できるかも確認したいところです。

ここで「せっかくだから請求書にも自動で反映しよう」と広げると、変更を誰が認めるか、請求を確定した後はどうするかという別の判断が必要になります。最初の問題が発注後の確認不足なら、まず変更理由と確認状態を見えるようにする。請求までつなぐ必要性は、次の段階として費用と運用を確かめる。このように、今直す部分を区切る選択もできます。

AIを使ってプログラムを作る場合でも、帳票や社内の判断まで自動で確認が済むわけではありません。コードの修正が早くできても、過去の記録との整合、出力の確認、社員への説明が残ります。「AIならすぐ足せるはず」だけで費用や納期を決めず、仕事全体への影響で考えることが大切です。

変更の記録は、一枚にまとめれば始められる

最初から立派な管理表を作る必要はありません。紙やExcelで、一つの希望について次の内容を同じ場所へ残します。チャットだけで相談すると、最新の判断が別の発言に埋まりやすいため、決まった結果を見返せる場所があると助かります。

• 今の動作と、変えたい動作。画面や帳票の見本があると伝えやすい。
• 困っている人、起きる場面と頻度、変えない場合に困ること。
• 当初の資料ではどう決めていたか。未確認ならそのまま残す。
• 影響する画面・帳票・データと、確認する担当者。
• 開発側と確認した費用・納期・作業範囲。誰が了承したか。
• 今対応する、次回に回す、今回は見送るという判断と、その理由。

例えば「一覧の表示項目を足す」希望なら、入力する項目も変わるのか、表示だけかを記録します。開発側から追加の作業が必要だと説明されたら、費用だけでなく、何を確認するための作業なのかも聞きます。追加費用が必要な変更は、作業に入る前に対象・金額・納期を確認し、双方の了承を記録します。金額の大小と必要性を混ぜず、今の予算で何を優先するかを社内で決めます。

保留した希望も消さずに、いつ見直すかを決めておくと判断が戻りにくくなります。「使い始めてから二週間の操作を見て、必要なら再相談する」など、自社で確認できる時点を置く方法です。これは運用の仮定例で、対応期限や無料改修を約束するものではありません。

追加する前に、今回の完成条件も更新する

費用と内容に合意しても、何ができれば完了かが曖昧だと、同じ希望が何度も出ます。変更後に使う画面や帳票で、通常の一件と変更の入った一件を確認し、誰が何を見て了承するかを決めます。元の機能に影響がないかの確認も必要です。

承認を追加した仮定例なら、承認した注文が出力されるだけでは足りません。未承認、差し戻し、承認後の変更をどう扱うかも確認します。すべてを同時に作り込むのではなく、今回対応する状態と、当面人が判断する状態を明確にする。操作説明や手順書に変更が必要なら、その作業も今回の範囲に含むか確かめます。

今日できることは、いま考えている変更希望を一つ選び、「誰が、どの作業で、何に困るか」を一文で書くことです。それを当初の資料と並べ、開発側へ「この変更は、どこに影響し、今回の範囲でどう扱いますか」と聞いてみてください。要望を飲むか断るかの話から、仕事に必要な変更を選ぶ話へ進められます。

埼玉県川口市のＢ．Ｉ．Ｙは、紙やExcelで回る仕事を確かめ、必要な部分を作り、導入説明や運用中の改善まで相談できる育てるシステム開発を提供しています。改善の対象や費用は、契約した範囲を確認して相談します。開発から直接相談でき、顧問契約は前提にしていません。途中の変更が心配なら、公式LINEへ「開発中に変更が出たときの進め方を相談したい」と一言送ってください。難しい言葉を用意する必要はありません。