追加開発の頼み方: 小さな改修を安く早く進めるコツ

「トップページのこの文言、ちょっと直したいんですが」「この項目、もう1個追加してもらえますか」——大きな開発プロジェクトが終わり、システムが無事に稼働し始めた後も、こうした小さな依頼は次から次へと出てきます。ところが、いざ開発会社に連絡してみると、「概算でも構いませんので、まず見積もりをお送りします」と返ってきて、思っていたより日数がかかったり、想定より高い金額が提示されたりして戸惑った経験はないでしょうか。

この記事は、そんな「システムは動いているが、日常的な小さな改修依頼をどう出せば、余計な費用や時間をかけずに済むのか知りたい」という担当者に向けて書いています。大きなプロジェクトの仕様変更や追加要望の伝え方については、別の記事『仕様変更・追加要望の正しい伝え方と追加費用の考え方』で扱っていますが、あちらは開発の途中で発生する変更が対象です。この記事は、システムがすでにリリースされ、運用が始まった後に発生する、ボタンの文言修正や項目の追加といった小規模な改修依頼に焦点を当てます。

結論を先に言うと、小さな追加開発を安く早く進めるコツは、依頼を思いついた順にバラバラと出すのではなく、いったん「ためて」から、まとめて、優先順位をつけて依頼することです。1件ずつ都度依頼すると、そのたびに見積もり作成・打ち合わせ・請求処理といった固定的な事務コストが発生し、内容以上に割高になりがちです。逆に、まとめて依頼すれば、開発会社側も一括で工数を見積もれるため、単価が下がりやすく、スケジュールも組みやすくなります。

この記事では、次のような疑問に順番に答えていきます。小さな改修はどのタイミングでまとめて依頼するのが得なのか。依頼を出すときにどんな情報を添えれば、見積もりが早く正確に返ってくるのか。無償で対応してもらえる範囲と、有償になる境界線はどこにあるのか。優先順位をどうつければ、限られた予算の中で効果の高い改修から進められるのか。読み終える頃には、次に「ちょっと直したい」と思ったときに、どう動けばよいかがイメージできているはずです。

小さな改修依頼が高くつく理由

小さな改修が「思ったより高い」「思ったより時間がかかる」と感じる背景には、作業内容そのものの難易度とは別に、依頼のたびに発生する固定的なコストがあります。

システム開発の現場では、どんなに小さな作業であっても、次のような一連の工程を経ることが一般的です。

• 依頼内容の確認・ヒアリング
• 影響範囲の調査(その修正が他の機能に影響しないかの確認)
• 見積もり作成
• 依頼者への見積もり提示と合意
• 実装
• 動作確認(検収)
• リリース作業

このうち、実装そのものにかかる時間はほんの数十分から数時間程度でも、確認・見積もり・合意・リリースといった前後の工程には、内容の大小にかかわらずほぼ一定の時間がかかります。つまり、1件あたりの実質的な工数は「作業時間」よりも「段取りの時間」の比重が大きくなりやすい、という構造があります。

この構造を理解しておくと、なぜ「1件ずつ都度依頼」が割高になりやすいかが見えてきます。10件の小さな修正を1件ずつ10回に分けて依頼した場合、段取りの時間も10回分発生します。一方、10件をまとめて1回で依頼すれば、段取りの時間は基本的に1回分で済み、影響範囲の調査もまとめて一度に行えるため、全体の工数が圧縮されやすくなります。

目安として、開発会社に依頼するときは「今すぐ直さないと業務が止まる」ものでない限り、2〜4週間分をためてからまとめて依頼する方が、都度依頼より総コストを抑えやすい傾向があります。

もちろん、ためすぎるとその間ユーザーが不便な状態を我慢し続けることになるため、後述するように「緊急度」による仕分けは必要です。

依頼を出すタイミングの見極め方

すぐに依頼すべきケース

すべての改修依頼を「ためてまとめる」対象にしてよいわけではありません。次のようなケースは、ためずにすぐ依頼すべきです。

• システムが正常に動作しない、あるいはエラーで業務が止まっている(不具合対応)
• セキュリティ上の懸念がある(個人情報が意図せず表示される、アクセス制御が効いていないなど)
• 法令や制度の変更により、表示内容の修正が必須になった(税率変更、表記義務の追加など)
• 特定の日付までに公開しなければならない情報がある(キャンペーン、告知など)

これらは「小さな改修」の体裁をとっていても、対応の遅れが業務やユーザーへの実害につながるため、優先度を最上位に置いて個別に依頼します。開発会社との契約にSLA（サービス品質保証）がある場合は、その対応時間の基準に沿って動くことになります。

ためてから依頼すべきケース

一方、次のようなケースは、緊急性が低いため、ためてからまとめて依頼する対象に向いています。

• 文言や表記の微調整(誤字修正を除く、より分かりやすい表現への変更など)
• 見た目の細かい調整(余白、色味、配置など)
• 「あったら便利」程度の機能追加
• 社内向け管理画面の使い勝手改善

これらは、今すぐ直さなくても業務が止まるわけではないため、依頼リストにためておき、後述する「まとめ依頼」のタイミングで一括して伝えるのが効率的です。

依頼をためる仕組みを作る

「ためてから依頼する」を実践するには、思いついた改修依頼を書き留めておく仕組みが必要です。頭の中だけで覚えておこうとすると、忘れる、優先順位があいまいなまま依頼してしまう、といった問題が起きやすくなります。

おすすめは、簡単な改修依頼リストを表計算ソフトやメモアプリで作り、気づいた時点で1行ずつ追記していく方法です。最低限、次の項目があれば十分機能します。

この一覧表があれば、月末や隔週など決まったタイミングで見返し、たまった項目をまとめて開発会社に送るだけで済みます。また、「これは以前も似た依頼をしていないか」を振り返る材料にもなり、重複依頼や場当たり的な依頼を減らす効果もあります。

社内に複数人が関わっている場合は、この一覧を共有シートにしておくと、誰がいつどんな依頼をしたかが可視化され、属人化の防止にもつながります。

依頼内容の書き方: 見積もりが早く返ってくる伝え方

小さな改修であっても、依頼の伝え方次第で、見積もりが返ってくるまでの日数や、実際にかかる金額が変わってきます。開発会社が見積もりを出すのに時間がかかる最大の理由は、多くの場合「依頼内容があいまいで、開発会社側が確認のやり取りを何往復もしなければならない」ことにあります。

最低限含めるべき情報

依頼を出すときは、次の4点を最初から書いておくと、確認の往復を大きく減らせます。

1. 対象画面・機能: どのページ、どの機能の話か(URLやスクリーンショットがあると確実)
2. 現状: 今どうなっているか
3. 希望する状態: どう変えてほしいか
4. 理由・背景: なぜ変えたいのか(理由が分かると、開発会社側からより良い代替案が出ることもある)

たとえば、「トップページを直してほしい」とだけ伝えるのではなく、次のように書くと伝わり方が変わります。

対象: トップページ(https://example.com/)のお知らせ一覧

現状: お知らせが古い順に表示されている

希望: 新しい順に表示を変更したい

理由: 最新のお知らせがユーザーの目に入りにくいという声が複数あった

この4点セットは、大きなプロジェクトで使う要件定義ほど厳密な資料である必要はありません。数行のメールやチャットメッセージで構いませんが、この骨格があるかないかで、見積もりの精度と速度が変わります。

スクリーンショットと矢印は最強の武器

文章だけで画面上の変更を説明しようとすると、どうしても解釈のずれが生まれます。対象画面のスクリーンショットを撮り、直したい箇所に矢印や丸印を書き込んで送るだけで、開発会社側の確認時間は大きく短縮されます。無料の画像編集ツールやOSの標準スクリーンショット機能で十分対応できます。

依頼をまとめて送るときの書き方

複数件をまとめて依頼するときは、1件ずつ番号を振り、優先順位も併記しておくと、開発会社側が全体像を把握しやすくなります。

【追加改修のご依頼(2026年8月分・全5件)】

1. (優先度: 高)会員登録フォームの電話番号を任意入力に変更
   対象: /register
   現状: 電話番号が必須項目
   希望: 任意入力に変更(未入力でも登録可能に)
   理由: 離脱率が高いとの指摘あり

2. (優先度: 中)お知らせ一覧の並び順を新しい順に変更
   ...

このように箇条書きで整理して送るだけで、開発会社側は全体の工数を見積もりやすくなり、結果として見積もり提示までの日数が短縮されます。

見積もり依頼で確認すべきポイント

依頼を送った後、開発会社から見積もりが返ってきたら、金額の大小だけを見るのではなく、次のポイントを確認すると、認識のずれを防げます。

内訳を確認する

見積もりに工数(人時・人日)や単価の内訳が示されているかを確認します。内訳がなく総額だけが提示されている場合は、遠慮せず「内訳を教えてください」と聞いて問題ありません。内訳の読み方については『システム開発の見積書、この内訳の見方で損を防ぐ』で詳しく解説しています。

対応範囲を確認する

見積もりに含まれる作業範囲(実装のみか、動作確認やリリース作業も含むか)を確認します。特に、複数の環境(テスト環境・本番環境)がある場合、どちらへの反映まで含まれるかは事前に確認しておく方がよい点です。

スケジュールを確認する

着手可能な時期と、完了予定日の両方を確認します。開発会社は複数の顧客案件を並行して抱えていることが多く、依頼した瞬間にすぐ着手してもらえるとは限りません。急ぎでない改修であれば、多少の待ち時間があることを前提にスケジュールを組んでおくと、余計な催促のやり取りを減らせます。

無償か有償かを確認する

「これくらい軽微な修正なら無償でやってもらえるのでは」と思っていた依頼が、実は有償だった、というすれ違いはよく起きます。次の章で、無償・有償の境界線について整理します。

無償対応と有償対応の境界線

「小さな改修」という言葉のイメージだけで無償・有償を判断すると、開発会社との間で認識のずれが生じやすくなります。一般的な考え方の目安を整理すると、次のようになります。

ポイントは、「不具合(バグ)」と「仕様変更」は法的にも実務的にも扱いが異なる、ということです。不具合とは、契約で決めた仕様通りに動いていない状態を指し、開発会社側の責任で無償修正の対象になることが一般的です。これは契約不適合責任に関わる話でもあります。一方、仕様変更とは、当初の仕様通りには動いているものの、その仕様自体を変えたいという依頼であり、これは追加の作業として有償になるのが基本です。

「思っていたのと違う」がすべて無償修正の対象になるわけではありません。契約時に合意した仕様通りに動いているのであれば、それは仕様変更(=新たな依頼)にあたります。

リリース直後の不具合と有償対応の境界線については、『リリース後の不具合、無償対応と有償対応の境界線』でさらに詳しく解説していますので、合わせて参照してください。

保守契約がある場合の考え方

すでに開発会社と保守契約を結んでいる場合、月額保守費の中に軽微な修正作業がどこまで含まれているかは、契約書ごとに異なります。「保守費を払っているから何でも無償でやってもらえる」という思い込みは避け、契約内容を確認しておくことが重要です。この点については『月額保守費で何をやってもらえるのか』で、契約書の読み解き方を含めて詳しく整理しています。

保守契約がない場合、小さな改修は都度見積もり・都度発注になるため、この記事で解説している「ためてまとめて依頼する」工夫の効果がより大きくなります。

優先順位のつけ方: 効果とコストのバランス

依頼リストがたまってきたら、まとめて依頼する前に優先順位をつけます。すべてを同じ重みで扱うと、限られた予算の中で効果の薄い改修に予算を使い切ってしまうことがあります。

優先順位づけの考え方として、次の2軸で整理する方法があります。

• 影響の大きさ: どれだけ多くのユーザー・業務に影響するか
• 対応の手間: 開発会社側の作業量がどれくらいか(体感でよい)

この2軸を掛け合わせると、次のような優先順位の目安が立てられます。

1. 最優先: 影響が大きく、手間が小さいもの(いわゆる「早い・安い」改修)
2. 計画的に対応: 影響が大きいが、手間もかかるもの(予算を確保して次のまとめ依頼で)
3. 余裕があれば対応: 影響は小さいが、手間も小さいもの
4. 後回しでよい: 影響が小さく、手間が大きいもの

改修依頼リストに「緊急度」だけでなく「影響の大きさ」の欄も追加しておくと、まとめて依頼するタイミングで、この優先順位づけがしやすくなります。すべてを一度に依頼する必要はなく、予算や開発会社の稼働状況に応じて、優先度の高いものから段階的に依頼していく判断も有効です。

依頼から納品までの一般的な流れ

小さな改修依頼であっても、基本的な流れは大きな開発プロジェクトと変わりません。全体像を把握しておくと、今どの段階にいるのかが分かり、無用な催促や不安を減らせます。

1. 依頼: 改修内容を開発会社に伝える(この記事で解説した4点セットを含める)
2. 見積もり・スケジュール提示: 開発会社から工数・金額・対応時期の提示を受ける
3. 合意: 内容と金額に問題がなければ発注の意思を伝える(メールやチャットでの記録を残す)
4. 実装: 開発会社側で作業が行われる
5. 動作確認: テスト環境などで、依頼通りの内容になっているか確認する(検収に相当する工程)
6. 本番反映: 問題がなければ本番環境に反映してもらう
7. 完了報告の記録: いつ・何を・どのように直したかの記録を残しておく

特に7番目の「記録を残す」工程は見落とされがちですが、次回似たような依頼をする際や、担当者が交代した際に、過去の改修履歴を追える資料として役立ちます。改修依頼リストの「対応状況」欄を「完了」に更新し、完了日を書き添えておくだけでも十分です。

よくある失敗パターンとその対処

小さな改修依頼を続けていると、いくつかの典型的な失敗パターンに陥りがちです。ここでは代表的な4つを紹介し、それぞれの対処法を整理します。

失敗パターン1: 口頭やその場のチャットだけで済ませてしまう

打ち合わせの雑談の中で「そういえば、あの画面のあれも直しておいてもらえますか」と口頭で依頼し、そのまま記録に残さないケースです。開発会社側の担当者がメモを取り忘れたり、優先度の低い依頼として後回しにされたまま忘れられたりすることがあります。

対処法はシンプルで、口頭で依頼した内容も、必ずメールやチャットなど記録に残る形で改めて送ることです。「先ほどお話しした件ですが、念のため文面でも送ります」の一言を添えるだけで、双方の認識のずれを防げます。

失敗パターン2: 「ついでにこれも」を際限なく積み増す

依頼を出した後、開発会社から返信が来るまでの間に、「そういえばこれも直したい」「あ、これも」と次々に依頼を追加してしまうケースです。開発会社側からすると、見積もりの前提条件が依頼のたびに変わるため、都度見積もりをやり直す必要が生じ、結果として全体の対応が遅れます。

対処法として、依頼はいったん区切りをつけてから送ることをおすすめします。改修依頼リストを見返して「今回まとめて依頼する分」を確定させてから送信し、その後に思いついたものは次回のまとめ依頼に回す、というルールを自分の中で決めておくと、依頼のたびに揺れ動くことがなくなります。

失敗パターン3: 金額だけを見て内容を確認せずに発注する

見積もり金額が想定より低かった、あるいは予算内に収まっていたという理由だけで、内容を精査せずに発注してしまうケースです。後になって「この部分は含まれていなかったのか」という認識のずれが発覚し、追加の見積もりが必要になることがあります。

対処法は、金額の大小にかかわらず、見積もりに添付されている作業範囲の記載を必ず読むことです。作業範囲の記載がない、あるいは曖昧な場合は、発注前に「この見積もりには、テスト環境への反映とマニュアルの更新は含まれていますか」のように、具体的に確認する一文を送ると、後々の認識違いを防げます。

失敗パターン4: 依頼の背景・理由を伝えない

「この項目を非表示にしてほしい」という依頼だけを伝え、なぜそうしたいのかという背景を伝えないケースです。開発会社側は言われた通りに実装しますが、実は背景を伝えていれば、もっと良い代替案(たとえば、非表示にするのではなく初期値を変更するだけで済む、など)を提案してもらえた可能性があります。

対処法は、この記事で紹介した4点セット(対象・現状・希望する状態・理由)のうち、特に「理由」を省略しないことです。理由を伝えることで、開発会社は単なる作業者ではなく、システムを理解した相談相手として提案してくれるようになります。

依頼メールの文例集

実際に依頼を出す際にそのまま使える文例を、緊急度別に2パターン紹介します。自社の状況に合わせて内容を差し替えて活用してください。

緊急ではない改修をまとめて依頼する場合

件名: 追加改修のご依頼(8月分・4件)

いつもお世話になっております。〇〇株式会社の〇〇です。

運用の中で気になった点がいくつかたまりましたので、
まとめてご依頼させていただきます。
急ぎのものはございませんので、通常のスケジュールで
ご対応いただければ幸いです。

【依頼1】(優先度: 中)
対象: 会員登録フォーム(/register)
現状: 電話番号が必須項目になっている
希望: 任意入力に変更したい
理由: 入力途中での離脱が多いとの声があるため

【依頼2】(優先度: 低)
対象: トップページのお知らせ一覧
現状: 古い順に表示されている
希望: 新しい順に表示を変更したい
理由: 最新情報が埋もれてしまうため

(以下、件数分続く)

お手数をおかけしますが、概算のお見積もりと
対応可能時期を教えていただけますでしょうか。
よろしくお願いいたします。

緊急度の高い不具合を依頼する場合

件名: 【至急】〇〇機能が正常に動作しない不具合について

いつもお世話になっております。〇〇株式会社の〇〇です。

本日〇時頃より、〇〇画面(URL: 〇〇)にて
以下の不具合が発生しております。業務に影響が出ておりますため、
恐れ入りますが優先的にご対応いただけますでしょうか。

【現象】
〇〇ボタンを押しても画面が切り替わらない

【発生状況】
・発生日時: 2026年〇月〇日 〇時頃から
・発生頻度: 毎回発生
・影響範囲: 〇〇機能を利用する全ユーザー

【添付】
現象を撮影したスクリーンショットを添付します。

至急のご確認をお願いいたします。

このように、緊急度に応じて件名や書き出しのトーンを変えるだけでも、開発会社側が優先順位を判断しやすくなります。特に「至急」と「通常」を混在させて送ると、本当に緊急なものが埋もれてしまうことがあるため、緊急の依頼は単独で、まとめ依頼とは分けて送ることをおすすめします。

開発会社に依頼を出しにくいと感じたときは

「こんな細かいことを何度も聞いていいのだろうか」「小さすぎて依頼するのが申し訳ない」と感じて、依頼を出すこと自体をためらってしまう担当者は少なくありません。しかし、開発会社にとって、依頼内容が整理されずに来る方がむしろ対応しづらく、逆にこの記事で紹介したような整理された形で依頼が来る方が、対応しやすく好意的に受け止められることが一般的です。

依頼を出しにくいと感じる背景には、そもそものフルスクラッチ開発開発時の要件のまとめ方に不慣れなまま運用フェーズに入ってしまった、という事情がある場合もあります。要件をまとめて伝える基本的な考え方は、『要件のまとめ方: 開発会社に伝わる資料の作り方』でも解説していますので、参考にしてください。

また、契約形態によっても依頼のしやすさは変わります。準委任契約で保守運用を契約している場合と、都度請負契約で発注する場合とでは、依頼の出し方や費用の発生タイミングが異なります。契約形態の違いについては『請負契約と準委任契約の違い』で整理しています。

まとめ

運用開始後の小さな追加改修は、1件ずつ都度依頼すると、内容以上に割高になりやすいという構造があります。緊急度の低い改修は改修依頼リストにためておき、月次や隔週などのタイミングでまとめて依頼することで、開発会社側の見積もり・確認の手間が圧縮され、結果として費用も時間も抑えやすくなります。

依頼を出すときは、対象・現状・希望する状態・理由の4点セットを添えることで、見積もりの精度と速度が上がります。また、不具合修正と仕様変更では無償・有償の扱いが異なることを理解しておくと、見積もりを受け取ったときに「なぜこの金額なのか」を納得しやすくなります。

次に「ちょっと直したいな」と思うことがあれば、すぐに連絡する前に、まず改修依頼リストに1行書き加えてみてください。それだけで、次にまとめて依頼するときの精度が変わってきます。

すでに月額保守契約を結んでいて、そもそも今の契約でどこまでの作業がカバーされているのか把握できていない、という方は、次に『月額保守費で何をやってもらえるのか』を読んでみてください。契約書の読み解き方から、開発会社への確認の仕方まで整理しています。