軽微改修を外部へ発注する流れは、まず軽微改修か仕様変更か、保守費用内か別途見積かを線引きするところから始まります。次に依頼内容を改修要望票にまとめ、工数の根拠と反映時期を確かめたうえで発注先を比べ、契約形態と契約書の条項を決めていきます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム軽微改修の発注で押さえる「線引き」
軽微改修の発注では、月額保守の範囲と追加費用の境界をはっきりさせておく必要があります。境界を決めないまま依頼を始めると、トラブルの原因になります。発注者側がこの線引きを理解しておくと、見積の妥当性を判断でき、想定外の追加請求を避けられます。
軽微改修と仕様変更の判定
軽微改修とは、既存システムの構造（データベース設計やプログラムの根幹ロジック）を大きく変えずに行う小規模な手直しを指します。
- 影響範囲：修正が及ぶ画面や機能の数
- 設計への影響：既存のデータベース設計やプログラムの根幹ロジックに踏み込むかどうか
- 想定工数：作業が数時間から数日程度に収まるかどうか
たとえば、画面の表示文言の変更や入力チェックの条件追加は、既存構造への影響が小さい例です。帳票やCSV出力のレイアウトの微調整、ボタンの位置や色の修正、マスタ項目の追加も、これに当たります。
一方で、新機能の追加や画面遷移フローの再設計は「仕様変更」です。外部システムとの新規連携やデータベース構造の変更も仕様変更に該当し、プログラムの根本修正を伴うため、保守範囲外の別途制作作業になります。
発注時には、依頼内容が「既存機能の微調整」か「新しい価値の追加」かを見極めます。そのうえで、自社で軽微改修か仕様変更かを判定しておくと、ベンダーとの認識合わせがスムーズに進みます。
判断に迷うグレーゾーンの依頼ほど、後の費用トラブルにつながりやすいものです。そのため、依頼の前にベンダーへ判定の根拠を確かめておく必要があります。
保守費用内と別途見積の見分け方
多くの月額保守契約では、バグ修正・障害対応・OSやミドルウェアの軽微なアップデート適用までが保守費用の範囲内とされます。
- 含む範囲：契約によっては、一定の工数までの軽微改修も保守費用に含まれることがあります。
- 保守への組み入れ：軽微改修が保守に含まれるかどうかを、契約書に書き込んでおきます。
一方で、大幅なデザイン変更や新機能追加など根本修正を伴うものは保守範囲外として追加費用が発生します。ただし、軽微改修が保守に含まれる場合は、月あたり何時間まで、あるいは何件までかも確かめておく必要があります。
判定に迷いやすい例は、OSのメジャーアップデートやブラウザの仕様変更で、既存機能が動かなくなった場合の対応です。
外部要因による不具合修正の扱いは契約によって分かれ、軽微なパッチ適用の延長として保守内とするベンダーもあれば、調査・改修の工数が大きい場合に別途見積とするベンダーもあります。法改正対応やOSS（WordPress等）のバージョンアップに起因する不具合も、契約の取り決め次第で扱いが変わります。
発注者は、発注前の契約の段階で「どの種類の改修が保守内か」をできるだけ具体的に決めておくことが、後のトラブル回避につながります。
軽微改修の発注・外注の進め方
軽微改修の発注は、単発で都度依頼する場合と、月額保守契約のなかに改修枠を組み込んで継続的に依頼する場合で進め方が異なります。年間を通じて改修依頼が一定量発生する企業では、後者の枠取り方式のほうが単価とスピードの両面で有利になりやすいです。どちらの場合も、依頼内容を整理してから発注先の候補を選び、比べていく流れになります。
依頼内容の整理と改修要望票
軽微改修は、改修要望票（変更依頼書）に情報を整理して渡します。口頭やメール本文だけで伝えるより、見積の精度とスピードが上がります。
- 記載項目：対象の画面や機能名、現状の動き、改修後のあるべき姿に加え、理由・背景、希望する反映時期、優先度も入れます。
- 画面の添付：スクリーンショットに赤入れした資料を添えると、認識のずれが大きく減ります。
とくに大切なのは、「改修の理由・背景」を書くことです。理由が伝わると、ベンダーが依頼の本質をつかみ、より少ない工数で目的を果たせる代替案を出してくれることがあります。
たとえば、項目追加の背景が「集計をしやすくしたい」という場合は、既存データの出力方法を変えることで解決でき、工数を抑えられることがあります。このように、依頼の表面的な指示だけでなく目的も共有しておくと、結果としてコスト削減につながります。
月額保守内の「改修枠」による発注方式
軽微改修が継続的に発生する場合に有効なのが、月額保守契約のなかに一定の改修工数枠を組み込む発注方式です。
- 取り決め例：「月10時間までの軽微改修は月額保守費用に含む」と定めると、都度の見積の手間が省け、依頼から反映までのリードタイムを短縮できます。
- 改修の割合：保守費用の内訳では、軽微な改修・改善が全体の10〜15%程度を占めるとされます。
枠を契約に明示すれば、改修対応にかかる予算の見通しが立ちます。そのうえで、改修枠を設けるときは、未消化の枠を繰り越せるかどうか、枠を超えた分の単価、枠を超える依頼の承認の流れを、あらかじめ決めておく必要があります。
枠が毎月余っているのに固定費を払い続けるのは、過剰投資にあたります。逆に毎月超過しているなら、枠の拡大か単価の交渉を検討すべきサインです。
月ごとに改修の実績工数を一覧にし、半期に一度は枠が適切かどうかを見直すと、保守費用の高止まりを防げます。実際に、保守費の内訳を精査して未利用のサービスを見つけた結果、月額28万円が20万円になり、約28.6%の削減につながった事例があります。
年間では96万円の削減です。内訳を一覧にすることが、見直しの出発点になります。
工数の透明性を確保する見積の取り方
軽微改修の発注で、もっとも不満が出やすいのは「工数の根拠が見えない」ことです。「画面の文言を1つ変えるだけなのに、なぜこの金額なのか」という疑問は、工数の算出方法と内訳が開示されていないことから生まれます。そのため、発注者は工数の積み方を理解し、見積の妥当性を判断できるようにしておく必要があります。
工数積算と機能ポイント法の使い分け
軽微改修の見積手法には、大きく分けて工数積算と機能ポイント法があります。
- 工数積算：改修作業を「調査・設計」「実装」「テスト」「リリース作業」などの工程に分け、それぞれに必要な人時を見積もって積み上げる方式です。
- 見えにくい工数：一見1行の文言修正でも、影響範囲の調査や動作確認、本番反映まで含めると相応の工数になることが、内訳を見ると分かります。
発注者は、見積に実装だけでなくテストやリリースの工数が入っているかを確かめると、見積の妥当性を判断できます。
機能ポイント法は、改修対象の機能の複雑さを数値にして見積もる方式で、似た改修の単価をそろえやすいという利点があります。
軽微改修を頻繁に依頼する場合は、改修パターン別の標準工数表を発注先と共有します。たとえば「文言修正は0.5人日」「項目追加は1人日」と決めておくと、見積交渉の手間を減らせます。
フリーランスやSESエンジニアの単価は、平均で月70〜76万円前後が中心です。人日や人時に換算した単価を把握しておくと、提示された工数が適正かどうかを確かめられます。
隠れコストの確認と相見積もりによる比較
軽微改修の発注では、改修工数の外に隠れコストが潜んでいることがあります。
- 隠れコストの例：時間外・休日対応の割増費用、緊急対応の特急料金。ほかに、リリース作業費、ドキュメント更新費、最低発注額（ミニマムチャージ）があります。
- 最低金額の設定：「1件あたり最低◯万円」と設定されていると、文言1つの修正でもまとまった金額になることがあります。発注前の確認が欠かせません。
これらを見落とすと、見積の総額が想定を大きく超えてしまいます。そこで、単価や条件が適正かを見極めるには、複数社からの相見積もりが有効です。
比べるときは、金額の安さだけでなく、工数内訳の開示度合いとリードタイムを見ます。さらに、やり取りの質と隠れコストの有無も、横並びで評価します。
注意したいのは、SES経由の場合です。企業側のマージン率が平均35〜40%にのぼり、エンジニアへの還元率が約60%程度というケースもあります。発注金額のうちどれだけが実作業に充てられているかを意識すると、価格構造の透明性を判断する材料になります。
ただし、安いだけの下請けは工数がかさみ、結局割高になることもあります。そのため、単価と生産性を合わせた総コストで比べることが必要です。
契約形態の選び方と発注先の見極め
軽微改修の発注では、契約形態の選び方が改修の柔軟性と責任範囲を左右します。仕様が固まりにくく、依頼がたびたび変わる軽微改修ほど、契約形態の特性を理解して選ぶことが、後のトラブル防止につながります。
請負と準委任の使い分け
請負契約は、成果物の完成義務と契約不適合責任（旧瑕疵担保責任）を伴う契約形態です。改修の内容と完成条件をはっきり決められる単発の軽微改修なら、「この改修を完成させて納品する」という請負が向いています。
- 完成後の保証：完成した成果物に対価を払い、不具合があれば修補を求められるため、成果が明確な依頼では安心感があります。
- 仕様変動への対応：準委任契約は善管注意義務にもとづいて作業を進め、仕様が固まりきらない改修や月次で内容が変わる改修に柔軟に対応しやすいです。
改修要望が次々に出て内容が変わり続ける運用では、準委任のほうが適しているケースが多いとされます。
そのため、月額保守の改修枠は準委任ベースで設計し、明確に切り出せる大型改修は請負で発注するというように、両者を使い分けるのが実務的です。発注時には、どちらの契約形態を選ぶかで責任の所在が変わることを理解しておく必要があります。
エンジニア品質と総コストの見極め
軽微改修の発注では、エンジニアの品質と生産性の差が総コストに与える影響が見落とされがちです。
- 作業の速さ：システムの構造を熟知したエンジニアなら、同じ改修でも短時間で安全に対応できます。
- 見かけの安さ：単価が高くても生産性が圧倒的に高いエンジニアと、単価は安いが工数がかさむ下請けでは、支払う総額が逆転することも珍しくありません。
一方で、構造を理解していない場合は調査に時間がかかります。影響範囲を見落として、二次障害を起こすこともあります。
発注先を選ぶ際は、単価に加えて品質面を重視すべきです。見るべきは、「このシステムをどれだけ理解しているか」と、「過去の改修がどれだけ正確かつ迅速だったか」です。
品質を見極めるには、小さな改修を試験的に発注する方法があります。見積の精度と納期の遵守を見るトライアル発注が有効で、成果物の品質やコミュニケーションも確かめられます。
さらに、ソースコードや設計書がバージョン管理されているかも確かめます。変更の理由と履歴を追えるかどうかも、ベンダー品質の指標になります。
属人化を避け、作業の決まりや設計を文書に残しているベンダーほど、担当者が替わっても安定した改修が期待でき、長期的な総コストを抑えられます。継続して発注する前に、こうした観点で見極めておくと、後悔のない発注につながります。
契約書の必須条項と経理処理の実務
軽微改修を継続して発注するなら、契約書に盛り込むべき条項と、改修費用の経理処理を理解しておくことが、発注後のトラブルとコスト管理の両面で役立ちます。改修費が修繕費か資産計上かは、税務と予算管理に直結します。発注者（情報システム部門と経理部門）が連携して確かめます。
軽微改修の契約で明記すべき条項
軽微改修の契約書には、改修対応の範囲と費用の境界を明確にする条項を入れておく必要があります。
- 含む改修の範囲：保守費用の対象とする範囲を、契約に明記します。
- 月あたりの上限：工数枠と、その枠で扱う対象機能を定めておきます。
- 超過時の扱い：枠を超えたときの単価と承認フロー。
これらの条件が曖昧だと、「言った言わない」のトラブルや想定外の追加請求が起きがちです。そのため、受付から着手・反映までの目安や、緊急・時間外対応を定めておきます。また、品質保証期間と不具合対応の責任範囲も決めておく必要があります。
加えて、改修によって作成・変更されたプログラムの著作権の帰属も、取り決めておく必要があります。権利をすべて自社に帰属させると、価格が上がる傾向があります。
一方で、ベンダーが他案件でソースを再利用できる余地を残して開発価格を抑えるという考え方もあります。自社の方針に応じて、権利の帰属と費用のバランスを契約の段階で整理しておくとよいでしょう。
発注者は、将来、別のベンダーへ運用を移す可能性に備えて、設計書やソースコードの引き継ぎ条件を契約に含めておくと、ベンダーロックインを避けられます。
修繕費と資本的支出の判定
軽微改修の費用は、税務・会計上「修繕費（期間費用）」と「資本的支出（資産計上）」のいずれかに分類されます。障害の除去や現状維持を目的とした修正は、修繕費としてその期の費用に計上できます。
- 機能拡張：新機能の追加や処理性能の向上など、システムの価値を高める改修は、資本的支出として資産計上し、減価償却していきます。
- 費用区分の判定：軽微改修の多くは現状維持目的の修繕費ですが、機能追加を伴う場合は資産計上が必要で、改修内容に応じた判定が欠かせません。
資本的支出として資産計上する改修でも、既存の部分を作り直すことがあります。その場合は、「既存の資産計上部分が除却された」と捉えて、その分を費用として処理できる考え方があります。たとえるなら、建物の一部を取り壊して建て直すのと同じ発想です。
見積では、ベンダーに「現状維持の修正部分」と「機能向上・追加部分」を分けて書いてもらいます。そうすると、修繕費と資本的支出の按分が行えるようになり、税務リスクも抑えられます。
発注の段階から経理部門を巻き込み、見積の内訳の細かさを指定しておくことをおすすめします。
ITシステム軽微改修の関連情報
軽微改修の発注を進めるには、進め方の全体像、依頼先となる開発会社の選定、費用相場の把握を理解しておくことが効果的です。発注・外注の方法を中心に扱いましたが、関連テーマは次の記事で詳しく解説しています。あわせてご覧いただくと、判断材料がより充実します。
進め方・会社選び・費用相場の関連記事
関連記事は、目的に応じて次の観点から選べます。詳しい説明は、それぞれの記事で確かめてください。
- 進め方：ITシステム軽微改修の進め方/やり方/流れや方法/手法/工程/手順
- 会社選び：ITシステム軽微改修でおすすめの開発会社/ベンダー6選と選び方
- 費用・全体像：ITシステム軽微改修の見積相場や費用/コスト/値段について、ITシステム軽微改修の完全ガイド
まとめ
ITシステムの軽微改修を発注・外注するときは、まず「軽微改修か仕様変更か」「保守費用内か別途見積か」の線引きを、発注者側が理解することが出発点です。そのうえで、改修要望票で依頼内容と目的を明確に伝えます。改修が継続して発生するなら、月額保守内に改修枠を組み込むと、リードタイムとコストの両面で改善できます。
見積は、工数積算や機能ポイント法などの内訳開示を求め、最低発注額や時間外割増などの隠れコストを確かめます。さらに、相見積もりで横並びに比べることが、適正な単価を引き出す鍵です。
契約面では、仕様が変わりやすい軽微改修には準委任の柔軟性が、成果の明確な改修には請負の完成責任が向きます。単価だけでなく、エンジニアの品質と生産性から総コストを判断して、トライアル発注で見極めるとよいでしょう。
契約書には、改修範囲と枠超過時の単価を明記し、著作権の帰属と引き継ぎ条件も書き込みます。また、経理処理では、修繕費と資本的支出の判定を見積の内訳と連動させて、適正に扱います。
内訳を一覧にして月額保守費を約28.6%削減した事例もあるように、軽微改修の発注は進め方次第で総額が大きく変わります。本記事のポイントを押さえ、透明で適正なコストで継続的な改善を回せる発注体制をつくってください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。