ITシステム軽微改修は一見すると簡単に思えますが、要望の受付から本番反映までを一つの流れで進めます。全体は5つの段階に分かれ、中心は「軽微か仕様変更か」の判定です。
まず決めたいのは、保守契約の範囲と追加費用の境界です。ここが曖昧だと、想定外の請求や、保守ベンダーに依頼を断られて改修が塩漬けになる事態を招きます。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
ITシステム軽微改修の全体像と「軽微」の定義
ITシステム軽微改修とは、稼働中のシステムに対して行う小規模な変更作業のことです。プログラムの根本的な構造は変えずに、部分的な調整が中心になります。対象は、画面表示や文言、帳票レイアウト、軽微な計算ロジックなどです。
多くの保守契約では、この軽微改修が月額保守費用の範囲内に含まれています。保守費の内訳の標準割合では、全体の10〜15%程度を占めるのが一般的とされています。
まずは「どこまでが軽微改修か」という輪郭を正しくつかむことが、適切な運用の出発点になります。
軽微改修に含まれる作業と含まれない作業
典型例は、画面上のボタン文言やラベルの変更です。ほかにも、入力チェックのメッセージ修正や、帳票・CSV出力への項目1〜2点の追加が該当します。表示順や並び替えの調整、マスタデータの軽微な変更も含まれます。
- 作業の範囲：基本設計を変えず、限られた範囲のソースコードを修正すれば対応できます。
- 工数と影響範囲：一般に、数時間から数人日程度の工数で完結し、既存機能への影響範囲も限られるのが特徴です。
一方で、新しい画面を追加したり業務フローそのものを変えたりする機能追加は、軽微改修には含まれません。外部システムとの新規連携、データベース構造の大幅な変更、大規模なデザインリニューアルなども、軽微改修の範囲を超えます。
これらは、プログラムの根本修正を伴う仕様変更に当たります。そのため、ほぼすべての保守契約では保守範囲の外となり、別途制作作業として追加費用が発生します。
軽微改修と仕様変更の違いは、影響範囲の広さと、設計への踏み込み度合いで見分けるのが基本的な考え方です。
保守費用に占める軽微改修の位置づけ
ITシステムの保守費用は、一般に複数の作業区分で構成されています。標準的な内訳割合は、次の3区分で整理できます。
- 定期保守・メンテナンス：20〜30%
- 障害対応：25〜35%
- 軽微な改修・改善：10〜15%
発注側は、保守費の過剰請求や不要な項目がないかを確かめる際、この割合を目安に自社の契約内容と照らし合わせます。
保守費用全体の相場は、初期開発費の年間5〜20%が目安とされています。業界標準では15〜20%が中心です。たとえば1,000万円で開発したシステムなら、年間150〜200万円程度になります。
このうち軽微改修に充てられる枠は限られているため、改修要望が枠を超えて積み重なると、保守契約の範囲では対応しきれず、別途見積が必要になります。自社の改修ニーズの量と保守契約の枠が見合っているかを、定期的に確かめることが、コストの適正化につながります。
ITシステム軽微改修の進め方（5ステップ）
軽微改修を安全かつ効率的に進めるには、要望の受付から本番反映までを一定の手順に沿って流すのが基本です。場当たり的に「とりあえず直してもらう」を繰り返すと、改修履歴が追えなくなったり、別の機能に予期せぬ不具合（デグレード）を生んだりします。
軽微改修は、受付から本番反映までを、改修要望の受付、軽微か仕様変更かの判定、工数見積、改修作業と検証、本番反映と記録の5つのステップに分けて進めます。
ステップ1：改修要望の受付と起票
最初のステップでは、現場から上がる改修要望を一か所で受け付け、正式に起票します。
- 口頭・チャットでの依頼：断片的なまま着手すると、認識のずれや「言った・言わない」のトラブルが起きがちです。
- 受付の方法：専用のフォームやチケット管理ツールに集め、最低限「誰が・いつ・どの画面の・何を・なぜ変えたいのか」を残しておくのが望ましい運用です。
起票の段階では、表面的な要望の裏にある本当の目的をつかむことが大切です。要望の件数や合計だけでなく、発生する場面や利用者ごとの違いも確かめます。そうすると、依頼の背後にある課題が分かってきます。
「項目を追加したい」という要望も、背景には別の運用上の課題があることが少なくありません。そのため、背景まで掘り下げて記録しておくと、少ない改修で本質的な解決につながることがあります。
ステップ2：「軽微改修 or 仕様変更」の判定
このステップでは、起票された要望が月額保守の範囲で対応できる軽微改修か、別途見積が必要な仕様変更かを判定します。
- 判定基準：ここが最大の分かれ目で、基準が曖昧だと、発注側と保守側の双方に不満が残ります。
- 判定の観点：影響範囲、設計への踏み込み度合い、想定工数の3点を見ます。
影響範囲は、修正が及ぶ画面や機能の数で測ります。想定工数は、おおむね数人日以内に収まるかを確かめます。この3点を組み合わせて判定するのが実務的です。
判定で迷いやすいのは、外部要因に起因する改修です。OSのメジャーアップデートやブラウザの仕様変更がその典型です。また、法改正対応や、WordPressなどOSSのバージョンアップで不具合が出た場合も、保守内か別途見積かを発注側と保守側で決めておきます。
一般に、現状維持を目的とした軽微な追従修正は保守範囲内、機能の作り直しを伴う対応は範囲外と整理されます。ただし、契約書に明記されていないと解釈が分かれます。
判定基準と外部要因の扱いを事前に取り決めておくことが、後のトラブル回避に直結します。
ステップ3：工数見積と対応可否の合意
軽微改修と判定された要望でも、工数を見積もり、対応可否を合意する手順は省けません。見積の手法には、大きく3つの考え方があります。
- 工数積算：エンジニアの作業時間を積み上げた見積です。
- 機能ポイント法：改修対象の機能の複雑さを数値に置き換えた見積です。
- 過去改修との比較：類似の過去案件と照らした概算です。
軽微改修では、工数積算を基本としつつ、影響調査やテストの時間も含めて見積もるのが現実的です。
見積では、改修そのものの作業時間以外に発生する付随コストを見落としがちです。たとえば、既存機能への影響調査や回帰テストには、改修とは別に工数がかかります。
リリース作業やドキュメント更新にも工数が要ります。これらを含めないと、後から「思ったより時間がかかった」となりがちです。
月額保守の改修枠を使う場合は、今回の改修で枠をどれだけ使い、残りがいくつになるかを一覧にしておくと、枠の使い方を計画的に管理できます。
ステップ4：改修作業と検証（テスト）
合意が取れたら、実際の改修作業に入ります。軽微改修であっても、本番環境にいきなり手を加えず、開発環境や予備機（テスト環境）で修正と検証を行うのが安全な運用の鉄則です。
- 動作確認：改修箇所が意図どおり動くかを見るだけでなく、他の機能を壊していないかを確かめる回帰テストも欠かせません。
- 軽い改修での油断：小さな改修ほど「これくらいなら大丈夫」と検証を省きがちですが、軽微改修の影響が思わぬ箇所に波及する事例は珍しくありません。
検証の効率を高めるには、定型の確認作業をスクリプトにして自動化しておくのも有効です。
バックアップやログ削除、再起動などの定型作業は自動化できます。さらに、テストの一部も自動化すれば、軽微改修のたびに発生する確認の工数を減らせます。
改修の頻度が高いシステムほど、検証を自動化する効果は大きくなります。
ステップ5：本番反映と変更履歴の記録
検証が完了したら、本番環境へ反映します。ユーザーへの影響が想定されるときは、メンテナンスウィンドウ（影響の少ない時間帯）を設けて反映するのが基本です。
- 事故への備え：万が一、反映後に問題が見つかった場合にすぐ元へ戻せるよう、反映前のバックアップ取得とロールバック手順の準備も欠かせません。
- 反映の順序：軽微改修でも、戻せる状態を確保してから反映すれば、リスクを小さく抑えられます。
反映後には、変更履歴を必ず記録します。設計書やソースコードのバージョンを一か所で管理し、いつ・何を・なぜ変更したかを追えるようにする「変更管理」が、安定運用の前提になります。
軽微改修は1件1件が小さいぶん、記録が省かれがちです。ただし、積み重なるとシステムがブラックボックス化し、将来の改修コストを押し上げる原因になります。
一件ずつ改修を確実に記録しておくことが、長期的な運用コストを抑えることにつながります。
軽微改修の費用相場と見積のポイント
軽微改修の費用は、月額保守費用に含まれるか、別途のスポット見積になるかで考え方が変わります。
費用を適正に把握するには、保守費全体の相場感、軽微改修の工数単価、隠れコストの見つけ方が手がかりになります。
工数単価と費用の目安
軽微改修を別途見積で依頼する場合、費用は一般に、エンジニアの工数単価に作業工数を掛けて算出されます。
- 単価相場：フリーランスやSESで平均月70〜76万円前後が中心とされます。上流のITコンサルやPMでは、最高295万円に達するケースもあります。
- 人日単価：月単価を人日に換算すると、1人日あたりおおむね3〜4万円前後です。
半日〜数日で完結する軽微改修なら、数万円から十数万円程度になることが多いといえます。
発注先を比べるときは、単価の安さより総コストに目を向けたいところです。たとえば、単価は高くても生産性が圧倒的に高いエンジニアと、単価は安くても工数がかさむ下請けとでは、最終的な総コストが逆転することがあります。
SESの実態として、企業側のマージン率は平均35〜40%、エンジニアへの還元率は約60%程度とされています。このため、表示単価の内訳も総コストに影響します。
軽微改修を継続して依頼するなら、1件あたりの単価より、「同じ要望をどれだけ早く確実に仕上げられるか」という品質と生産性で発注先を見極めたいところです。
隠れコストの見つけ方
軽微改修の費用を適正にするには、月額保守費の内訳を精査し、隠れコストを見つけることが欠かせません。
- 削減事例：保守費の内訳を精査して未利用のサービスを見つけ、月額28万円を20万円へと28.6%削減した民間企業の事例があります（年間で約96万円の削減）。
- 一括払いの保守費：「軽微改修込みの保守費」として一括で支払っていると、本当に必要な改修対応にいくら使われたかが見えにくくなります。
保守会社に内訳を区分ごとに開示してもらうことが、適正化の第一歩です。また、時間外対応費や緊急対応の追加料金、定義が曖昧なまま請求される「その他作業費」などは、隠れコストになりやすい項目です。
契約上の費用配分と実際の利用状況を比べれば、過剰請求や不要な項目が見つかります。さらに、毎月、軽微改修の枠をどれだけ使い切っているかを確かめることも、無駄な費用を見つける有効な手段です。
軽微改修の経理処理と契約上の注意点
軽微改修は技術的な作業であると同時に、経理処理や契約形態の面でも判断が必要な領域です。同じ改修でも費用処理の区分が変わることがあり、契約形態によって対応の柔軟性も異なります。
発注側の情報システム部門が経理と法務の視点も押さえておくと、改修をめぐる社内調整が進めやすくなります。
修繕費と資本的支出の判断軸
軽微改修の費用をどう会計処理するかは、改修の目的によって分かれます。バグの除去や現状維持を目的とした修正は、「修繕費（期間費用）」として、支出した年度の費用に計上できます。
- 資本的支出：新機能の追加や性能向上を伴う改修は、資産に計上して耐用年数にわたり減価償却します。
- 多くの軽微改修：現状維持目的の修正に当たるため修繕費で処理できます。ただし、改修内容によっては資本的支出と判断されるケースもあります。
判断に迷うときは、「既存部分の除却」という視点が役立ちます。資本的支出として資産計上する際には、建物の一部を取り壊すのと同じように、既存の資産計上部分は除却されたと捉えます。そうすれば、その部分を費用として処理できる、という考え方です。
既存の機能が改修で作り替えられた場合には、旧機能に対応する資産計上分を除却損として処理できる余地が生まれます。
経理処理の区分は税負担にも影響するため、判断が難しい改修は税理士など専門家に相談しながら進めます。
請負と準委任、契約形態の選び方
軽微改修を継続して依頼する場合は、契約形態の選び方も、対応のしやすさを左右します。
- 請負契約：成果物の完成義務と契約不適合責任（瑕疵担保）を伴うため、仕様が明確な単発の改修には向きますが、要望が次々と変わる運用にはやや硬直的です。
- 準委任契約：善管注意義務のもとで柔軟に作業を進められるため、頻繁に発生する小さな改修要望に対応しやすい特性があります。
継続して改修や保守を行うなら、要件変更に強い準委任が適するケースが多いとされています。
契約時には、月額保守で対応する改修枠の上限を決めておきます。あわせて、枠を超えた場合の追加費用や、OSアップデートや法改正など外部要因の負担区分も、できるだけ具体的に書面で取り決めます。
これらを曖昧にしたまま契約すると、「軽微だと思っていた改修が追加費用になった」というトラブルにつながります。役割分担と費用区分を明文化しておくことが、軽微改修をめぐる無用な摩擦を防ぐ最善の対策です。
ITシステム軽微改修に関する関連記事
費用相場や発注方法、開発会社の選び方について、さらに詳しく知りたい方は、以下の関連記事もご覧ください。
関連記事は4本あり、知りたいテーマに合わせて選んでください。費用、発注方法、会社選び、全体像を順に比較できます。
- ITシステム軽微改修でおすすめの開発会社/ベンダー6選と選び方
- ITシステム軽微改修の見積相場や費用/コスト/値段について
- ITシステム軽微改修の発注/外注/依頼/委託方法について
- ITシステム軽微改修の完全ガイド
まとめ
ITシステム軽微改修を適切に進めるには、軽微か仕様変更かの境界線を正しく引くことが分かれ目になります。判断の基準は、影響範囲、設計への踏み込み、想定工数の3点です。
流れは、要望の受付と起票から始まり、判定、工数の見積と合意へと続きます。そのうえで、改修と検証、本番反映と変更履歴の記録まで進めれば、ブラックボックス化やデグレードを防げます。
費用面では、軽微改修が保守費内訳の10〜15%で運用されているかを確認します。また、エンジニア単価の相場は月70〜76万円前後です。保守費の内訳を精査して28.6%削減した事例もあり、適正化の余地は少なくありません。
さらに、修繕費と資本的支出の経理処理、請負と準委任の契約形態の選び方まで含めて整理しておけば、軽微改修をめぐる社内外の調整を一段とスムーズに進められます。
本記事の判断基準を活用し、自社のシステム改修を計画的かつ適正なコストで運用していきましょう。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。