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

システムをリリースして運用を始めると、必ず「リリース後の費用」という新たな論点に直面します。なかでも企業の担当者を悩ませるのが、毎月の運用で発生する「保守・運用費用」と、新しい機能を足したいときに発生する「追加開発費用」の境界がはっきりしないことです。「保守契約を結んでいるのだから、この機能追加も保守の範囲でやってもらえるはずだ」と考えていたら、ベンダーから別途見積もりを提示されて戸惑った、という声は少なくありません。逆に、軽微な不具合の修正にまで追加開発の費用を請求され、納得感が得られなかったというケースもあります。保守と追加開発は、システムを「正常に保つ」ためのコストと「新たな価値を生み出す」ためのコストという、根本的に性質の異なる費用です。この違いを理解しないまま発注すると、予算計画は狂い、ベンダーとの関係にも溝が生まれかねません。

本記事では、リリース後に発生する費用のうち、とりわけ「追加開発（新規機能の追加・既存機能の改修）」の費用に焦点を絞り、保守・運用費用との違いから丁寧に解き明かしていきます。具体的には、保守と追加開発で契約区分や見積もり方法がなぜ分かれるのか、追加開発費用の約8割を占める人件費の内訳と人月単価の相場、機能追加が割高・割安になる要因、見えにくいコストである「技術的負債」が追加開発費を押し上げる仕組み、そして継続的な追加開発に向いたラボ型（準委任）契約の費用構造やベンダー切り替え時のコストまでを、具体的な数値とともに体系的に解説します。リリース後のシステム投資を計画的に進めたい方、追加開発の見積もりの妥当性を見極めたい方にとって、判断軸となる知識が得られるはずです。これから追加開発の発注や運用フェーズの予算策定を検討されている方は、ぜひ最後までご覧ください。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

保守費用と追加開発費用は何が違うのか

リリース後の費用を正しくコントロールする第一歩は、「保守・運用費用」と「追加開発費用」を明確に切り分けて捉えることです。この2つは同じ「運用フェーズで発生するコスト」でありながら、目的がまったく異なります。保守・運用費用は、稼働しているシステムを「現状のまま正常に保つ」ためのコストであり、追加開発費用は、稼働中のシステムに「新たな価値・機能を実装する」ためのコストです。多くのトラブルは、発注者とベンダーがこの境界線を共有しないまま契約してしまうことに起因します。ここでは、それぞれが具体的にどんな業務を指すのか、そしてなぜ契約・見積もりを分けて管理すべきなのかを整理していきます。

保守・運用費用とは、ひとことで言えば「システムを正常に動き続けさせる」ための費用です。具体的な業務としては、システムが正しく稼働しているかを常時見張る「監視」、利用者からの操作方法やトラブルに関する「問い合わせ対応」、サーバーダウンやエラーが発生した際の「障害対応」、リリース後に発覚した不具合（瑕疵）を直す「バグ修正」、そして表記の修正やパラメータ調整といった「軽微な改修」が含まれます。これらに共通するのは、いずれも「新しい価値を加える」のではなく「あるべき正常な状態を維持・回復する」ことを目的としている点です。たとえば、ボタンを押しても反応しないという不具合を直すのは保守ですが、これは本来動くべきものが動いていない状態を正常に戻す行為だからです。保守費用は毎月の固定的なランニングコストとして発生するのが一般的で、年間の保守費用はソースに明記された比率があるわけではありませんが、目安として開発費用全体の概ね5〜15%程度に設定されるケースが多く見られます。重要なのは、保守はあくまで「現状維持の範囲」であり、システムの機能そのものを拡張したり、新しい業務に対応させたりする作業は、たとえ小さなものであっても本来の保守の枠を超える、という点です。この線引きを曖昧にしたまま「保守契約に含まれるはず」と期待すると、認識のずれが生じます。保守契約を結ぶ際には、どこまでが「現状維持」として無償（保守費の範囲内）で対応され、どこからが追加開発として別途見積もりになるのかを、契約書のレベルで具体的に定義しておくことが、後々のトラブルを避ける最も確実な方法です。

一方の追加開発費用とは、すでに稼働しているシステムに対して、新しい機能を追加したり、画面のUI/UXを変更したり、これまでなかった業務に対応させたりといった、「新たな価値・機能を実装する」ための開発工数に対して支払う費用です。たとえば、ECサイトに新しい決済手段を追加する、管理画面に売上分析のダッシュボードを新設する、スマートフォン対応のレイアウトを作り込む、といった作業はすべて追加開発に該当します。バグ修正が「壊れたものを直す」のに対し、追加開発は「なかったものを新しく作る」という点で、保守とは本質的に性質が異なります。この性質の違いこそが、保守と追加開発を別の区分として契約・見積もりすべき最大の理由です。保守は対象範囲がある程度決まっているため、月額固定のような定額契約に馴染みます。これに対し追加開発は、何をどこまで作るかによって工数が大きく変動するため、案件ごとに要件を定義し、その都度「機能数×品質レベル」「作業単価×人月」といった形で個別に見積もりを行う必要があります。両者を一括りにして「運用費」としてどんぶり勘定にしてしまうと、発注者側は「毎月これだけ払っているのに、なぜ機能追加にまた費用がかかるのか」と不満を抱き、ベンダー側は「これは保守の範囲外の新規開発だ」と主張する、という対立が生まれます。保守は安定運用を支えるランニングコスト、追加開発は事業成長のための投資、という具合に費用の意味づけ自体が異なるため、予算管理の観点からも分けて把握しておくことが、計画的なシステム投資につながります。発注時には、保守契約と追加開発の発注をあらかじめ別枠で設計しておくことを強くおすすめします。

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

追加開発の見積もりを受け取ったとき、その金額が妥当なのかどうかを判断するには、費用がどのような要素から組み立てられているのかを理解しておく必要があります。結論から言えば、追加開発費用の大部分は「人件費」であり、その金額は「作業単価×人月」という極めてシンプルな式で決まります。見積書に並ぶ数字の正体を分解して捉えられるようになれば、ベンダーから提示された金額の内訳を読み解き、どこにコストがかかっているのかを冷静に評価できるようになります。ここでは、追加開発費用の構造を「機能数×品質レベル」という大枠と「作業単価×人月」という算出ロジックの両面から解説し、さらに費用を左右する人月単価の役割別の相場感を具体的な数値で示していきます。

追加開発の費用を理解するうえで最も重要な事実は、その費用の約8割が「人件費」で占められているという点です。システム開発は、サーバー費用やソフトウェアライセンスといった物的なコストよりも、エンジニアが手を動かす「人の作業」に大きく依存します。そのため、追加開発の費用は基本的に「作業単価×人月」という式で算出されます。ここでいう「人月（にんげつ）」とは、1人のエンジニアが1か月働く作業量を1単位とする考え方で、たとえば「3人月」であれば「1人が3か月かかる、あるいは3人が1か月かかる作業量」を意味します。これに、エンジニア1人あたりの1か月の単価（作業単価）を掛け合わせることで、おおよその費用が決まります。そして、その人月の総量を大枠で決めるのが「機能数×品質レベル」です。追加したい機能の数が多ければ多いほど開発工数は増えますし、同じ機能でも「とりあえず動けばよい」レベルと「大量アクセスに耐え、セキュリティも堅牢で、エラー処理も丁寧に作り込む」レベルとでは、必要な工数がまったく異なります。つまり、見積もり金額を左右するのは「いくつの機能を」「どれだけの品質で」作るのか、という2軸なのです。この構造を理解しておくと、見積もりを抑えたいときの打ち手も見えてきます。費用の8割が人件費である以上、コストを下げる現実的な方法は「作る機能を絞る（機能数を減らす）」か「過剰な品質要件を見直す（オーバースペックを避ける）」かのいずれかに行き着きます。逆に、機能の数や品質要件を据え置いたまま金額だけを値切ろうとすると、どこかで無理が生じ、品質の低下や納期の遅延として跳ね返ってくることになります。見積もりを評価する際は、総額の大小だけでなく「何人のエンジニアが、何か月、どんな単価で関わる前提なのか」という人月の内訳まで確認することが、妥当性を見極める鍵となります。

追加開発費用の大半を占める人件費は、関わるエンジニアの役割やスキルレベルによって、1人月あたりの単価が大きく変わります。代表的な役割別の人月単価の相場感を示すと、まず高度な設計力やマネジメント力を担う「上級SE（システムエンジニア）」はおよそ100〜160万円、一般的な実装や設計を担当する「初級SE」は60〜100万円が目安となります。プログラミングを主に担う層では、大手企業に所属するプログラマーが50〜100万円、下請けや個人で受注するエンジニアが40〜60万円ほど、海外のリソースを活用する外国籍エンジニアでは30〜40万円程度と、幅広いレンジに分布します。同じ機能を作る場合でも、誰がその作業を担当するかによって費用が数倍変わり得るということです。この相場感を知っておくことは、追加開発の見積もりを評価するうえで非常に有効です。たとえば、ごく簡単な軽微改修に上級SEクラスの単価で見積もられていれば「この作業にそのスキル単価は過剰ではないか」と問いかけることができますし、逆に高度なアーキテクチャ設計を伴う重要な機能追加が下請け個人の単価だけで構成されていれば「品質面のリスクはないか」と確認する材料になります。ただし、単価が安ければそれだけ総額も安くなる、という単純な話ではない点には注意が必要です。スキルの高いエンジニアは単価こそ高いものの、少ない人月で確実に作り切ることが多く、結果として総額が抑えられるケースもあります。逆に、単価の安いエンジニアばかりで体制を組むと、手戻りや品質トラブルで人月が膨らみ、かえって総額が高くつくことも珍しくありません。重要なのは「単価×人月」の両方をセットで見て、その追加開発に必要な役割が適切に配置されているかを判断することです。見積書に役割ごとの単価と工数の内訳が明示されていれば、その透明性自体が信頼できるベンダーであることの一つの指標にもなります。

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

同じような機能追加であっても、システムによって、あるいは進め方によって、費用が大きく割高になることもあれば、想定よりも割安に収まることもあります。この差はどこから生まれるのでしょうか。追加開発の費用は「作業単価×人月」で決まる以上、費用が変動する要因とは、すなわち「必要な人月（工数）が増えるか減るか」を左右する条件にほかなりません。ここでは、機能追加が割安になる条件と割高になる条件を整理したうえで、追加開発のコストを静かに、しかし確実に押し上げていく「技術的負債」という見えにくいコスト要因について掘り下げていきます。

まず、機能追加が割安になる代表的な条件は「部分修正で済む」場合です。追加開発は、ゼロから新しいシステムを作るのとは違い、すでにある機能や仕組みを土台として活用できるため、既存部分に手を入れる「部分修正」で目的を達成できるなら、開発期間は本開発に比べてはるかに短く済みます。土台がある分、必要な人月が少なくて済むのです。そしてもう一つ、割安につながる極めて重要な条件が「初期設計の段階で拡張性を持たせてあるか」です。システムを最初に作る時点で「将来こういう機能を追加するかもしれない」という見通しのもとに、後から手を加えやすい構造で設計しておけば、いざ追加開発を行う際に既存部分を大きく作り変える必要がなく、追加コストを大幅に抑えることができます。逆に言えば、追加開発のしやすさは、実は最初の開発の設計品質によってあらかじめ決まっている部分が大きいのです。一方、機能追加が割高になる条件の筆頭は「要件のすり合わせ不足」です。発注者とベンダーの間で「何を作るか」の認識が十分に共有されないまま開発を進めると、出来上がったものが想定と違い、作り直しや改修ミスによる手戻りが発生します。手戻りはそのまま追加の作業工数、すなわち人月の増加に直結し、人件費を押し上げます。また、開発に着手してから「実はこの既存機能とも連携させる必要があった」「想定していなかったデータ移行が必要だった」といった「想定外の作業」が次々と発覚すると、当初の見積もりを超えて工数が延び、費用が膨張していきます。割高化を防ぐには、着手前の要件定義の段階で「何を・どこまで・どの既存機能と関連づけて作るのか」を可能な限り具体的に詰め、認識のずれと想定漏れを潰しておくことが何より効果的です。追加開発の費用は、作り始めてからではなく、作り始める前の準備段階で大きく決まると言っても過言ではありません。

追加開発のコストを語るうえで避けて通れないのが「技術的負債」という概念です。技術的負債とは、開発時に「とりあえず動けばよい」とドキュメントの整備を後回しにしたり、コードの可読性（読みやすさ）を軽視したりした結果、システムの内部に蓄積していく”見えない借金”のことを指します。納期優先で保守性をないがしろにして作られたシステムは、表面上は問題なく動いていても、内部には技術的負債が積み上がっています。この負債が、追加開発のコストを静かに、しかし確実に押し上げます。その仕組みはこうです。機能を追加するとき、エンジニアはまず「その変更が既存のどこに影響するのか（影響範囲）」を把握しなければなりません。ところが、ドキュメントが整備されておらず、コードも読みにくい状態だと、最初に作った本人ではない別のエンジニアが、その複雑に絡み合った構造を一から読み解かなければならず、この解読作業だけで膨大な工数がかかってしまいます。本来なら数日で終わるはずの機能追加が、「どこをどう直せば安全なのかを理解する」ためだけに何週間も費やす、といった事態が起こるのです。読み解く工数が増えれば、当然その分の人件費も増え、追加開発費用は割高になります。この問題が最も深刻な形で表面化するのが、開発を依頼するベンダーを切り替えるときです。保守性が低く技術的負債を抱えたシステムでは、新しいベンダーが既存のコードを解読するだけで膨大な人件費が発生し、場合によっては「既存のコードを読み解いて改修するよりも、いっそ一から作り直したほうが安く済む」という本末転倒なオーバーヘッド（無駄な負担）が発生することすらあります。つまり技術的負債は、目先の追加開発費を押し上げるだけでなく、将来の選択肢そのものを狭め、企業を特定のベンダーに縛りつける要因にもなるのです。これを避けるには、最初の開発の段階から、ドキュメントの整備とコードの可読性、すなわち「保守性」を重視してシステムを作っておくこと、そして追加開発の際にも負債を増やさない丁寧な実装を求めることが、長期的なコスト最適化につながります。

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

リリース後のシステムは、一度きりの機能追加で終わることはほとんどありません。利用者からのフィードバックを受けてUIを改善し、事業の変化に合わせて新機能を加え、競合に対抗するために改修を重ねる——というように、追加開発は「継続的に」発生していくのが実態です。この継続的な追加開発を、その都度ゼロから見積もり・契約していると、手間もコストもかさみます。そこで重要になるのが、継続的な追加開発に適した契約形態の選択と、ランニングコスト全体の見通しです。ここでは、リリース後の柔軟な開発に向いた「ラボ型（準委任）契約」の費用構造と、ベンダーを切り替える際に発生するコスト、そして年間の保守費の目安について解説します。

継続的な追加開発において近年主流になりつつあるのが「ラボ型（準委任）契約」です。なぜこの契約形態が選ばれるのかを理解するには、まず請負契約との違いを押さえる必要があります。新規にシステムを作る本開発では、完成すべき成果物（仕様）が事前にはっきり決まっているため、その完成を約束する「請負契約」が適しています。しかし、リリース後の機能追加やUI改善、アジャイル的に進める開発では、状況が異なります。利用者の反応を見ながら「次に何を作るか」を柔軟に変えていく必要があり、要件が流動的で、何をどこまで作るかを事前に固定することが困難なのです。このような探索的・継続的な開発に成果物の完成を約束する請負契約を当てはめると、仕様変更のたびに契約の変更や追加見積もりが必要になり、スピードも柔軟性も損なわれてしまいます。そこで、成果物の完成ではなく「一定の体制で作業に従事すること」に対して報酬を支払う「準委任契約」、すなわちラボ型契約への切り替えが多く選択されます。ラボ型契約の費用構造は、「月額固定」もしくは「時間単価」といった、稼働に応じた報酬の形をとるのが特徴です。たとえば「エンジニア2名の体制を月額いくらで一定期間確保する」という形で契約し、その枠のなかで優先順位の高い開発から柔軟に着手していきます。この契約形態の最大のメリットは、仕様変更や優先度の入れ替えが発生しても、そのたびに追加の見積もりや契約変更の手続きを踏む必要がなく、柔軟かつスピーディーに対応できる点にあります。「今月はこの機能を優先したいが、来月は別の改修を先にやりたい」といった事業判断の変化に、契約の枠組みを変えることなく追従できるのです。継続的に追加開発を行う前提があるなら、確保した開発リソースを月額のランニングコストとして計上し、そのなかで開発の優先順位を機動的にコントロールできるラボ型契約は、コスト管理と開発の柔軟性を両立させる有力な選択肢となります。

継続的な追加開発を見据えるとき、もう一つ意識しておきたいのが「ベンダーを切り替える際のコスト」です。現在の開発ベンダーに不満があったり、費用面でより条件の良いパートナーを探したくなったりして、別のベンダーへの切り替えを検討する場面は珍しくありません。しかし、ここで見落とされがちなのが、切り替えに伴う「引き継ぎ・解読コスト」です。新しいベンダーは、これまでのシステムがどのような設計思想で、どのような構造で作られているのかを、既存のコードやドキュメントから読み解くところから始めなければなりません。前述のとおり、システムの保守性が低く技術的負債を抱えている場合、この解読作業だけで膨大な人件費が発生します。極端なケースでは「読み解いて改修するより一から作り直したほうが安い」とすら言われる状況に陥り、ベンダー切り替えのつもりが実質的な再開発になってしまうこともあります。つまり、ベンダー切り替えの自由度は、システムの保守性の高さによって大きく左右されるのです。この観点からも、日頃からドキュメントを整備し、保守性の高い状態を保っておくことが、将来の選択肢を確保するうえで重要になります。最後に、リリース後のランニングコスト全体を見通すための保守費の年間目安にも触れておきます。保守費が開発費に対してどの程度の割合になるかについては、確立された明確な基準値があるわけではありませんが、一般的な目安としては、開発費用全体の概ね年5〜15%程度に設定されるケースが多いとされています。たとえば1,000万円で開発したシステムであれば、年間50万円から150万円程度が保守費の目安ということになります。これに加えて、事業成長のための追加開発費が別途発生する、という構造です。リリース後の予算計画を立てる際は、この「保守費（現状維持のランニングコスト）」と「追加開発費（成長のための投資）」を分けて見積もり、年間でどの程度のシステム関連コストが発生するのかを総額で把握しておくことが、無理のないシステム運用につながります。

まとめ

本記事では、リリース後に発生する費用のうち「追加開発費用」に焦点を当て、保守・運用費用との違いから見積もり方法、割高・割安要因、技術的負債、契約形態までを解説しました。最も重要なポイントは、システムを「現状のまま正常に保つ」保守・運用費用と、「新たな価値・機能を実装する」追加開発費用は、性質の異なる費用として切り分けて契約・見積もりすべきだということです。追加開発費用は約8割が人件費であり、「機能数×品質レベル」を大枠としつつ「作業単価×人月」で算出され、上級SEで月100〜160万円といった役割別の単価相場が金額を左右します。費用は、部分修正で済む場合や初期設計で拡張性を確保している場合に割安となり、要件すり合わせ不足や想定外作業があると割高になります。さらに、ドキュメント不足やコードの可読性の低さといった技術的負債は、影響範囲の解読工数を増やして追加開発費を静かに押し上げ、ベンダー切り替え時には「読み解くより作り直すほうが安い」という事態すら招きます。継続的な追加開発には、月額固定や時間単価で稼働に対して支払うラボ型（準委任）契約が、流動的な要件への柔軟性とコスト管理を両立させます。保守費は開発費の概ね年5〜15%程度を目安に、追加開発費とは分けて予算化しておくことが、計画的なシステム投資の第一歩です。リリース後の費用設計に迷われた際は、保守と追加開発の両面を見据えた開発パートナーに相談することをおすすめします。

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

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

株式会社riplaの会社HPはこちら

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。