追加開発の保守・運用費用・ランニングコストについて

追加開発費は、機能数、品質レベル、担当者の役割によって変わります。人月単価の相場は30〜160万円で、外国籍エンジニアの月30〜40万円から、上級SEの月100〜160万円まで幅があります。

保守費と追加開発費は目的が違うため、分けて契約し、見積もるのが基本です。保守費は開発費の年5〜15%程度が目安です。

▼全体ガイドの記事
・追加開発の完全ガイド

保守費用と追加開発費用の違い

保守・運用費用と追加開発費用を、目的と契約・見積もりの扱いで左右に比較した図解。
費用の目的を分けると、契約範囲も整理しやすくなります。

リリース後の費用は、保守・運用費用と追加開発費用に分けて捉えます。前者は稼働中のシステムを正常に保つための費用で、後者は新しい価値や機能を実装するための費用です。

どちらも運用フェーズで発生しますが、目的は異なります。そのため、境界を共有しないまま契約すると、発注者とベンダーの認識がずれ、トラブルになりかねません。

保守=現状維持(監視・問い合わせ・障害・バグ修正・軽微改修)

保守は「現状維持」が前提で、今ある機能を変えずに、稼働を安定して保つ作業が対象になります。保守・運用費用は、この作業にかかる費用です。

  • 監視・問い合わせ:稼働状況の確認と利用者からの質問に対応します。
  • 障害・バグ修正:サーバーダウンやエラー、不具合を正常な状態に戻します。
  • 軽微な改修:表記の修正やパラメータ調整などです。

これらは、正常な状態を維持し、回復させる作業です。たとえば、ボタンが反応しない不具合を直すのも、本来の動作に戻すための保守にあたります。

保守費は、毎月の固定的なランニングコストとして発生するのが一般的です。年間の保守費に明確な基準比率はありませんが、開発費全体の概ね5〜15%が目安となるケースが多くあります。

機能の拡張や新しい業務への対応は、小規模でも保守の範囲を超えます。線引きが曖昧だと、保守契約に含まれるはずだという期待から認識がずれてしまいます。そこで契約書では、保守費の範囲で無償対応する現状維持の範囲と、別途見積もる追加開発の範囲を定義しておくことが、トラブルを避けるうえで最も確実です。

追加開発=新たな機能・価値の実装。区分を分けて契約・見積もりする理由

追加開発は、稼働中のシステムに機能を加えたり、UI/UXを変更したり、新しい業務に対応させたりする費用です。

  • 決済・分析機能:ECサイトへの決済手段の追加や、売上分析画面の新設です。
  • 画面変更:スマートフォンに対応するレイアウトの作り込みです。

バグ修正が壊れたものを直す作業であるのに対し、追加開発はなかったものを新しく作ります。この違いがあるため、契約と見積もりを分けて扱います。

保守は対象範囲が決まっているため、月額固定などの定額契約に馴染みます。一方で、追加開発は内容によって工数が変わり、案件ごとに要件定義が必要です。そのため、「機能数×品質レベル」や「作業単価×人月」で個別に見積もります。

一括で管理すると、毎月の保守費を払っているのに機能追加の費用も必要なのかと、発注者が不満を抱くことがあります。また、ベンダーは保守範囲外の新規開発だと主張し、両者の対立につながります。

保守は安定運用のためのランニングコスト、追加開発は事業成長への投資です。そのため、予算を管理するには、発注時から両者を別枠の契約として設計しておくのが基本です。

ポイント

判断に迷ったら、その依頼が今の機能を正常に保つものか、新しい機能や価値を加えるものかで分けてください。前者は保守費、後者は追加開発費として、別々に扱います。

追加開発費用の見積もり方法と人月単価相場

上級SE、初級SEなど5つの役割について、本文にある月額人月単価の範囲をパネルで示した図解。
単価だけでなく、必要な人月との組み合わせが総額を左右します。

見積もりが妥当かどうかを判断するには、費用の構成を知っておく必要があります。内訳に分解すれば、どの部分にどれだけ費用がかかっているかを評価できます。

追加開発費の大部分は人件費で、「作業単価×人月」で決まります。さらに、機能数と品質レベル、役割別の人月単価の相場も費用を左右します。

費用の約8割は人件費——「機能数×品質レベル」「作業単価×人月」

追加開発費の約8割は人件費です。そのため、費用はサーバー費用やライセンスよりも、エンジニアの作業量に大きく左右されます。

  • 費用の算出:作業単価と人月を掛け合わせて、おおよその費用を求めます。
  • 工数の大枠:機能数と品質レベルで、必要な人月の大枠が決まります。
  • 費用を抑える方法:機能を絞るか、過剰な品質要件を見直すことです。

人月は、1人のエンジニアが1か月働く作業量を表す単位です。たとえば3人月は、1人が3か月、または3人が1か月かけて行う作業量を指します。そのうえで、人月にエンジニア1人あたりの月単価を掛けて、費用を出します。

機能数が多いほど工数は増えます。同じ機能でも、動けばよい水準と、大量アクセスや堅牢なセキュリティ、丁寧なエラー処理を求める水準とでは工数が異なります。また、機能や品質要件を変えずに値下げを求めると、品質低下や納期遅延につながりかねません。

見積もりを見るときは、総額だけでなく、何人が何か月、どの単価で関わる前提なのかを確認しましょう。人月の内訳こそ、見積もりの妥当性を見極める鍵です。

役割別の人月単価相場(上級SE100〜160万円ほか)

人件費の単価は、担当するエンジニアの役割やスキルで大きく変わります。そのため、役割ごとの相場を知っておくと、見積もりの妥当性を評価できます。

  • 上級SE:設計やマネジメントを担い、月100〜160万円です。
  • 初級SE:一般的な実装や設計を担当し、月60〜100万円です。
  • 大手企業のプログラマー:月50〜100万円です。
  • 下請け・個人のエンジニア:月40〜60万円ほどです。
  • 外国籍エンジニア:海外リソースを活用し、月30〜40万円程度です。

同じ機能でも、担当者によって費用が数倍変わることがあります。単価の相場は、見積もりに必要な役割が配置されているかを確かめる材料になります。たとえば、軽微な改修に上級SEの単価を当てていないか、高度な設計を伴う機能を下請けの個人だけで担う体制に品質リスクがないかを確認できます。

単価が安いからといって、総額も安いとは限りません。高スキルの担当者は、単価が高くても少ない人月で完了し、総額を抑えられる場合があります。一方で、低単価の体制では、手戻りや品質トラブルで人月が膨らみ、総額が高くなることもあります。

単価と人月の両方を見て、役割を見極めましょう。また、役割別の単価と工数が明記された見積書は、内訳を検討しやすくなります。その透明性は、ベンダーを選ぶ指標の一つにもなります。

ポイント

同じ総額でも、関わる役割と人月の内訳で妥当性は変わります。内訳の人月が、機能数と品質レベルに見合っているかを基準にしてください。

機能追加が割高・割安になる要因と技術的負債

技術的負債を中心に、資料整備・コードの読みやすさ、既存コードの解読工数、人件費の増加を注釈線で示した図解。
既存構造を読み解く作業が、追加開発時の工数に加わります。

同じような機能追加でも、システムや進め方によって費用は変わります。費用は作業単価×人月で決まるため、工数を左右する条件が差を生みます。

割安になる条件(部分修正・拡張性を持たせた初期設計)と割高になる条件(要件すり合わせ不足・想定外作業)

既存の機能をどこまで活かせるかと、要件がどこまで固まっているかが、追加開発の費用を左右します。

  • 割安になりやすい条件:既存機能の部分修正や、拡張性のある初期設計です。
  • 割高になりやすい条件:要件の認識ずれや、着手後に判明する想定外作業です。

部分修正で目的を達成できる場合は、既存の機能や仕組みを土台にできるため、新規開発より期間が短く、人月も抑えられます。

将来の機能追加を見越して、初期設計で拡張性を持たせておくと、追加費用を抑えられます。後から手を加えやすく、既存部分の大幅な作り直しも避けられます。さらに、追加開発のしやすさは、初期開発の設計品質によってあらかじめ決まる部分が大きいのです。

一方で、要件のすり合わせ不足は費用を押し上げます。発注者とベンダーの認識が異なると、完成物の作り直しや改修ミスが起こり、手戻り分の工数と人件費が増えます。また、着手後に既存機能との連携やデータ移行が判明すると、工数が延びて費用が膨らみます。

要件定義で何をどこまで作り、どの既存機能と関連づけるかを詰めておくと、認識のずれや想定漏れを防げます。このように、費用は着手前の準備でも大きく決まります。

技術的負債が追加開発コストを押し上げる仕組み

技術的負債は、「とりあえず動けばよい」と資料整備やコードの読みやすさを後回しにした結果、内部に蓄積する「見えない借金」です。

  • 追加開発時:影響範囲の解読に工数がかかり、人件費が増えることがあります。
  • ベンダー切り替え時:既存コードの解読負担が、改修や再開発の判断に影響します。
  • 予防策:資料とコードの可読性を保ち、保守性を高めることです。

納期を優先して保守性を軽視したシステムは、正常に動いていても負債を抱えている場合があります。この負債が、追加開発のコストを押し上げます。

機能追加では、変更が既存のどこに影響するかを把握する必要があります。資料がなくコードも読みにくいと、当初の開発者ではないエンジニアが複雑な構造を一から読み解くことになり、工数がかかります。さらに、本来数日で終わる機能追加でも、理解だけに何週間もかかることがあります。

解読工数が増えると人件費も増え、追加開発費が割高になります。特に、ベンダーを切り替えるときには問題が深刻になり、新しいベンダーが既存コードを解読するため、多額の人件費が生じる場合があります。

場合によっては、既存コードを改修するより一から作り直すほうが安くなることもあります。負債は将来の選択肢を狭め、特定のベンダーに縛る要因にもなります。そのため、追加開発でも負債を増やさない実装を求めることが、長い目で見たコストを抑えることにつながります。

ポイント

追加開発の依頼で費用が膨らみそうなときは、着手前に既存機能との連携やデータ移行を洗い出してください。資料やコードが乏しいシステムでは、解読の工数も見込んでおく必要があります。

継続的に追加開発する契約とランニングコスト

リリース後の追加開発は、一度きりで終わらないことがほとんどです。利用者の声を受けたUI改善や、事業の変化に応じた機能追加、競合への対策が続きます。

その都度見積もりと契約を行うと、手間もコストもかさみます。そのため、継続開発に合う契約形態とランニングコストを検討しましょう。

ラボ型(準委任)契約の費用構造(月額固定/時間単価)とメリット

継続的な追加開発では、ラボ型(準委任)契約が主流になりつつあります。請負契約との違いを押さえると、選ばれる理由が分かります。

  • 請負契約:成果物の完成を約束する契約です。
  • ラボ型(準委任)契約:流動的な要件に合わせて、一定の体制で作業する形です。
  • 費用と利点:月額固定や時間単価で稼働に応じて支払い、優先順位を柔軟に変えられます。

仕様と成果物が事前に決まっている新規システムの本開発は、請負契約に適しています。一方で、リリース後の機能追加やUI改善、アジャイル開発では、利用者の反応を見ながら次に作るものを変えていきます。このような開発は要件が流動的で、範囲を事前に固定しにくいため、請負契約には向きません。

請負契約では、仕様が変わるたびに契約変更や追加見積もりが必要になり、速度や柔軟性が損なわれます。これに対してラボ型契約は、成果物の完成よりも、一定の体制で作業することに報酬を支払う仕組みです。

たとえば、エンジニア2名の体制を一定期間、月額で確保し、その枠の中で優先度の高い開発から着手します。そのため、仕様や優先度が変わるたびに追加見積もりや契約変更を行わずに済み、事業判断に合わせて柔軟かつ迅速に対応できます。また、今月はこの機能、来月は別の改修を優先するといった判断にも、契約枠を変えずに追従できます。

継続開発が前提なら、確保した人員を月額のコストとして計上できます。開発の優先順位を機動的に調整しながら、コスト管理と柔軟性を両立できる選択肢です。

ベンダー切替の引き継ぎ・解読コストと、保守費の年間目安

ベンダーを切り替える場合は、引き継ぎと既存システムの解読にかかる費用も考慮します。新しいベンダーは、設計思想や構造を、コードや資料から読み解くことになります。

現在のベンダーへの不満や、費用面でより良い条件を求めて、切り替えを検討することもあります。

  • 切り替え費用:保守性が低いと解読負担が増し、作り直しが必要な場合もあります。
  • 保守費の目安:開発費全体の年5〜15%程度です。
  • 予算管理:保守費と追加開発費を分け、年間費用を見積もります。

技術的負債があると、解読だけで多額の人件費が発生し、切り替えが再開発になる場合もあります。ベンダーを切り替えられる自由度も、システムの保守性で大きく変わります。日頃から資料を整え、保守性を高く保っておくことが、将来の選択肢を確保することにつながります。

保守費に明確な基準値はありませんが、たとえば開発費1,000万円のシステムなら、年間の保守費は50万〜150万円程度が目安です。これとは別に、事業成長のための追加開発費が発生します。

予算では、現状維持の保守費と成長投資の追加開発費を分け、年間のシステム関連費用を把握しましょう。

ポイント

月ごとに優先度が変わる開発が続くなら、ラボ型(準委任)契約の検討に値します。範囲が事前に固まっている案件は、請負契約が向いています。

まとめ

保守費は現状を正常に保つための費用で、追加開発費は新しい価値や機能を加える投資です。性質が異なるため、契約と見積もりは分けて扱います。

追加開発費の約8割は人件費で、機能数と品質レベルが工数を左右します。そのうえで、作業単価と人月を掛け合わせて費用を算出します。

部分修正や拡張性のある初期設計は費用を抑えられます。一方で、要件のずれや想定外作業、技術的負債は工数を増やし、ベンダーの切り替えも難しくします。

継続開発の選択肢には、月額固定や時間単価のラボ型契約があります。保守費は開発費の年5〜15%程度を目安に、追加開発費とは分けて予算化しましょう。

リリース後の費用設計に迷うときは、保守と追加開発の両方を見据えた開発パートナーに相談するのがおすすめです。

▼全体ガイドの記事
・追加開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。