LASSIC Media らしくメディア
稼働中アプリへの機能追加費用｜改修コストの構造と見積もり方
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- 稼働中アプリへの機能追加費用が新規開発と異なる理由と、費用を押し上げる要因を解説します
- 既存コード調査・影響範囲・回帰テストが費用に与える影響と、技術的負債との関係を整理します
- 開発元以外への移管（ベンダー切り替え）時の留意点と、適切な見積依頼の進め方を説明します
目次
既存アプリへの機能追加費用とは何か
既存アプリへの機能追加費用とは、すでに本番稼働中のアプリケーションに対して、新しい画面・ロジック・外部サービス連携などの機能を後から追加する際に発生する開発コストの総称です。単に「新しい機能を書く費用」だけでなく、既存コードの調査・影響範囲の特定・品質を保証するための回帰テストまでを含む点が、新規開発との大きな違いです。
稼働中のアプリは、ユーザーが利用しながら改修が進みます。そのため、「追加した機能が既存機能を壊していないか」を確認するテスト工程が欠かせません。この回帰テスト（デグレード確認）のコストは、既存機能の規模に比例して増加します。
また、アプリを稼働させながら開発するため、本番環境への影響を最小化するための開発環境管理・デプロイ手順の整備も費用に含まれます。「新しい機能1本を作るだけ」とはいかない複雑な工程が存在することを、発注担当者は最初に認識しておくことが大切です。
新規開発と費用構造が異なる4つの理由
既存アプリへの機能追加は、ゼロから開発する場合と比べて費用の計算方法が異なります。「すでにベースがあるから安いはず」と考えがちですが、現実には新規開発より割高になるケースもあります。その背景にある4つの要因を整理します。
理由1：既存コードの読解・調査コストが発生する
新規開発では、仕様をもとにゼロからコードを書けます。一方、機能追加では、担当エンジニアがまず既存コードを読み解く必要があります。ドキュメントが整備されていない場合、コードを逆読みして仕様を把握する作業が発生し、これが時間・費用の大きなロスになります。
特に、前の開発者が慣習から外れた書き方をしていたり、コメントが少ないコードだったりすると、読解にかかる工数は数倍に膨らむことがあります。この「調査フェーズ」は発注時には見えにくいため、見積もりを依頼する際に明示的に確認しておく必要があります。
理由2：影響範囲の特定に手間がかかる
稼働中のアプリには、複数の機能が互いに連携しているケースが大半です。新機能を1つ追加するだけで、予期しない既存機能へのデータ流れの変更が生じることがあります。どの範囲に影響が出るかを事前に洗い出す作業（影響範囲分析）は、設計フェーズの重要な工程です。
影響範囲が広いほど、設計・テストの工数が増えます。特に決済処理・認証・外部API連携など、アプリのコアとなる機能と連動する変更は、影響範囲の特定だけで相当な工数が必要になります。
理由3：回帰テストのコストが規模に比例する
機能追加後に「既存の機能が壊れていないか」を確認する回帰テスト（リグレッションテスト）は、既存機能の数に比例してテスト項目が増えます。アプリの機能が充実しているほど、1つの機能追加に対して確認すべきテスト項目が多くなる仕組みです。
自動テストが整備されているアプリでは回帰テストの工数を抑えられますが、手動テストに頼っている場合は追加費用が生じます。また、iOSおよびAndroidの両対応アプリであれば、両プラットフォームでのテストが必要となり、工数がさらに増加します。
理由4：本番稼働中ゆえのリリース管理コスト
新規アプリの初回リリースと異なり、稼働中アプリへの変更は「ダウンタイムを最小化しながら」デプロイする必要があります。ブルーグリーンデプロイやカナリアリリースなどのリリース手法を選択する場合はインフラ構成の工夫が求められ、その分コストが加算されます。モバイルアプリの場合はAppStore・Google Playへの審査期間も考慮が必要です。
費用を左右する3要因：設計品質・ドキュメント・技術的負債
機能追加の費用は、追加する機能の規模だけでなく、「既存アプリの状態」に大きく左右されます。以下の3つの要因が費用変動に直接影響します。
要因1：既存設計の品質（アーキテクチャの整理度）
機能の追加・変更がしやすい設計か、しにくい設計かによって、同じ機能追加でも工数が大きく変わります。責務が明確に分離されたモジュール設計（例：MVCやClean Architecture）で作られたアプリは、追加箇所が明確で変更の影響が局所的に留まります。
一方、処理がひとつのファイルに集中している設計（スパゲッティコード）では、1カ所を変更すると別の箇所に連鎖的な影響が出やすく、調査・実装・テストすべての工程でコストが増加します。設計品質が低い場合、リファクタリング（コード整理）のコストを先行して見積もるケースもあります。
要因2：ドキュメントの有無（設計書・仕様書の整備状況）
設計書・画面仕様書・API仕様書・DB定義書などのドキュメントが整備されているアプリは、調査フェーズの工数を大幅に削減できます。逆に、ドキュメントがない場合はコードを読み解く逆引き調査が発生し、その工数が見積もりに上乗せされます。
「ドキュメントが一切ない」ケースでは、既存機能の仕様把握だけで全体工数の30〜40%以上を費やすことも実務上あり得ます（市場参考値・一次資料ではありません）。発注前に自社アプリのドキュメント整備状況を把握しておくことが、見積もり精度を高めるうえで重要です。
要因3：技術的負債の蓄積状況
技術的負債とは、開発スピードを優先した結果として積み上がった「後で直すべき問題」の総称です。古いライブラリへの依存・テストコードの未整備・不統一な命名規則などが代表的な例です。
IPAが公表した「DX白書2023」（IPA、2023年3月発行）では、既存システムの老朽化・複雑化・ブラックボックス化がDX推進を妨げる要因として指摘されており、技術的負債の蓄積が運用保守・機能追加コストを押し上げる問題は多くの企業に共通しています。技術的負債が多いアプリでは、機能追加の前に部分的なリファクタリングや依存ライブラリの更新が必要となり、追加コストが発生する場合があります。
| 状態 | 費用への影響 | 対応方針 |
|---|---|---|
| 設計が整理されている・ドキュメント充実 | 調査・設計工数を抑えられる。 機能追加を本来の規模で見積もれる |
追加機能の開発に集中して着手できる |
| ドキュメントなし・設計書不在 | 逆引き調査工数が発生し、 見積もりに不確実性が増す |
調査フェーズを先行して行い、実費精算か概算見積もりで対応 |
| 技術的負債が大きい（古いライブラリ・スパゲッティコード） | リファクタリングや依存更新が 先行して必要になるケースがある |
負債解消と機能追加のスコープを分けて優先順位を設定する |
費用の目安と主要工程の内訳
機能追加の費用は「機能の複雑さ」「既存アプリの状態」「開発チームの体制」によって大きく幅が出ます。ここでは費用に含まれる主要工程と、それぞれに影響する要素を整理します。なお、以下に示す工数・期間はあくまで市場参考値であり、一次資料に基づく確定値ではありません。
費用に含まれる主要工程
- 既存コード調査・影響範囲分析：見積もりをするための前提調査。ドキュメントがない場合は特に工数がかかります
- 詳細設計：追加機能の画面・ロジック・DB変更などの設計。既存仕様との整合確認を含みます
- 実装（コーディング）：新機能のコーディングと既存コードへの組み込み作業です
- 単体テスト・結合テスト：追加機能単体の動作確認と、既存機能との連携動作確認です
- 回帰テスト（リグレッションテスト）：既存機能がデグレード（劣化）していないかの全体確認です
- リリース管理・デプロイ：本番環境への反映作業。モバイルアプリはストア申請手続きも含まれます
費用の変動要因
同じ「ログイン機能の追加」であっても、既存ユーザー管理システムとの連携が必要か、どのOAuth（認証標準仕様）プロバイダーに対応するかによって、工数は数倍から十倍近く変わることがあります。画面1枚増やすだけの小規模な変更であれば数日以内に完了するケースもあれば、外部API（外部サービスとのデータ連携インターフェース）連携を伴う中規模追加では数週間を要することもあります。
見積もりを依頼する際は「何を追加したいか」に加え、「現在の機能との連携が必要かどうか」「既存データの移行・変換が発生するか」の情報を提供することで、発注側・受注側双方で見積もり精度を高められます。
開発元以外への依頼（移管）で生じる追加コストと留意点
何らかの理由で元の開発会社に依頼できない場合、新たな開発会社に既存アプリの保守・機能追加を移管することになります。この「移管」には特有のコストと注意点があります。
移管時に生じるキャッチアップコスト
新しい開発会社は、アプリの開発経緯・設計思想・業務ルールをゼロから把握しなければなりません。ソースコードの読解・既存ドキュメントの確認・動作確認環境の構築など、純粋な機能追加とは別に「キャッチアップ工数」が発生します。ドキュメントが充実していれば短縮できますが、ドキュメント不備の場合はこの工数が大きくなります。
元の開発会社との契約上の留意点
移管を検討する際に確認すべき主要な契約上の論点は以下の通りです。
- 著作権・知的財産権の所在：ソースコードの著作権が発注者（自社）にあるか、開発会社にあるかを確認してください。契約書に明記がなければ開発会社帰属とみなされるリスクがあります（知的財産権の帰属は契約締結前に書面で確認することを推奨します）
- ソースコードの開示義務：現在の開発会社がソースコードをいつでも渡せる状態にしているか確認が必要です
- 環境情報（サーバー・DB・外部API認証情報）の引き継ぎ：本番稼働に必要な環境情報の一覧を整理し、引き継ぎ手順を事前に文書化することが大切です
- 移管期間中の二重コスト：新旧開発会社が並走する期間が生じると、両社への費用が一時的に重複する場合があります
移管を成功させるための準備事項
移管をスムーズに進めるには、移管前に以下の情報を整備しておくことが有効です。システム構成図・画面仕様書・API仕様書・インフラ構成図・外部サービス連携先の一覧・過去の不具合履歴などを一式まとめることで、新しい開発会社のキャッチアップ工数を短縮でき、移管コスト全体の圧縮につながります。
見積依頼の進め方と費用を抑えるポイント
機能追加の費用を適切に見積もるには、発注担当者側の準備が重要です。「とりあえず相談」では概算しか出せず、後から大幅な変更が生じるリスクがあります。
見積依頼に必要な情報を準備する
見積依頼時に提供すべき情報は次の通りです。
- 追加したい機能の概要（画面イメージ・ユーザーストーリー・処理フロー）
- 現在のアプリの技術スタック（利用言語・フレームワーク・DBの種類）
- 既存の設計書・ドキュメントの有無
- 外部サービスとの連携要否（決済・認証・地図・通知など）
- リリース希望時期とその理由（事業上のマイルストーンがあるか）
- 対象プラットフォーム（iOS・Android・Webどれを先行するか）
上記の情報が揃っているほど、開発会社は詳細な見積もりを出しやすくなります。逆に情報が不足していると、リスクバッファとして多めの工数が見積もりに含まれることがあります。
調査フェーズを先行させる
既存アプリの状態が不明な場合、最初から全体の固定費用で発注するのではなく、まず「既存コード調査・影響範囲分析」のフェーズを小規模な実費精算または固定費用で先行依頼する方法があります。調査結果をもとに機能追加の本見積もりを取ることで、見積もりの精度が格段に上がります。
費用を抑えるための優先順位付け（MoSCoW法の活用）
追加したい機能を「Must have（今回対応）」「Should have（できれば必要）」「Could have（あれば良い）」「Won’t have（今回は対象外）」の4段階に分類する方法（MoSCoW法）は、スコープを絞り込んで費用を抑えるうえで効果的です。すべての要望を一度に盛り込もうとすると見積もりが膨らみやすく、段階的なリリース計画を組む方が費用管理しやすくなります。
複数の開発会社から見積もりを取る
機能追加の費用は開発会社によって大きく異なることがあります。単価差だけでなく、調査フェーズの扱い方・回帰テストの範囲・リリース後の保証範囲の違いも確認することが大切です。費用だけでなく、既存技術スタックへの習熟度・類似案件の実績・コミュニケーションの丁寧さも評価軸に加えることを検討してください。
LASSIC が担える体制と元請（プライムベンダー）としての役割
機能追加開発を外部に委託する際、発注先として「元請（プライムベンダー）」に依頼するか、開発専業の協力会社に直接依頼するかで、プロジェクト管理の負担が変わります。
元請（プライムベンダー）に依頼するメリット
元請（プライムベンダー）とは、発注者から直接委託を受けて全体のプロジェクト管理・品質管理・進捗報告を担う立場の開発会社を指します。複数の協力会社を束ねてプロジェクトを推進するため、発注者側の管理コスト（ベンダーとの窓口対応・課題管理・品質チェック）を集約できます。
特に機能追加では、既存システムの調査フェーズ・設計フェーズ・実装フェーズ・テストフェーズで異なるスキルセットが必要になります。元請（プライムベンダー）に依頼することで、各フェーズに適したリソースを柔軟に調整してもらえる点が実務上の利点です。
LASSICが提供する機能追加支援の特徴
LASSICは元請（プライムベンダー）として、稼働中アプリの機能追加・保守・改修を受託しています。
元請（プライムベンダー）として、調査フェーズから要件定義・設計・実装・テスト・リリースまで一貫して担い、発注者様がプロジェクト全体を1社に任せられる体制を整えています。特に移管案件やドキュメントが不十分なアプリへの対応も行っており、まずはお気軽にご相談いただけます。
まとめ：機能追加費用を正しく把握するための3つの判断軸
本稿では、稼働中アプリへの機能追加費用がなぜ新規開発と異なるのか、費用を左右する要因、移管時の留意点、見積依頼の進め方について整理しました。要点を3つに集約します。
第一に、機能追加費用は「追加機能の規模」だけでなく「既存アプリの状態（設計品質・ドキュメント整備・技術的負債の蓄積）」によって大きく変動します。発注前に自社アプリの現状を把握しておくことが、正確な見積もりを得るための前提条件です。
第二に、回帰テストのコストは見落とされがちですが、既存機能が多いほど確認範囲が広がり、費用に直結します。「機能1本追加だから安いはず」という前提は、実務では成り立たないケースがあります。
第三に、開発元以外へ移管する場合は著作権の所在・ソースコードの引き渡し可否・環境情報の整備を事前に確認し、キャッチアップ工数を短縮する準備を整えることが費用対効果を高めるポイントになります。
よくある質問
機能追加の見積もりを依頼する前に準備しておくべきことはありますか？
見積もり精度を高めるために、最低限「追加したい機能の概要・現在の技術スタック・設計書の有無・外部連携の要否・希望納期」の5点を整理してから依頼することをおすすめします。特に既存の設計書やAPI仕様書があれば、共有することで開発会社が適切な工数を算出しやすくなります。情報が揃っていない場合は、まず調査フェーズだけを先行依頼する方法も有効です。
機能追加と新機能の新規開発、どちらが費用を抑えられますか？
一概にどちらが安いとは言えません。既存アプリに追加する場合、調査・影響範囲分析・回帰テストのコストが加わるため、シンプルな機能を新規で別アプリに開発するほうが安い場合もあります。一方、すでに認証・DB・外部連携の基盤が整っているアプリであれば、ゼロから基盤を作るコストが不要なため機能追加が有利になることもあります。判断には既存アプリの設計品質と技術的負債の確認が前提となります。
技術的負債があるアプリは機能追加できますか？
技術的負債があっても機能追加は可能です。ただし、負債の程度によっては追加コストや期間の長期化が生じます。開発会社は通常、機能追加前に現状コードを調査し、リファクタリングの必要性と費用を提示します。全体の負債を一度に解消するのではなく、機能追加対象の周辺だけを先行整理する「部分リファクタリング」が費用対効果の面で採用されるケースもあります。
元の開発会社が廃業・連絡不可になった場合でも機能追加を依頼できますか？
依頼はできますが、ソースコードと環境情報が手元にあることが前提です。ソースコードがあれば、新しい開発会社がコードを読解してキャッチアップするところから始められます。ソースコードが手元にない場合は、動作している本番環境からの解析が必要となり、追加コストが大きくなります。このような事態を防ぐため、開発委託時点でソースコードの所有権と定期的なリポジトリ提供を契約書に明記しておくことが大切です。
機能追加の費用は固定費用と実費精算のどちらで依頼するのが良いですか？
既存アプリの状態が把握できている場合は固定費用（請負契約）が予算管理しやすくなります。一方、調査をしてみないと影響範囲が不明な場合は、まず調査フェーズを実費精算（準委任契約）で依頼し、結果をもとに機能追加フェーズを固定費用にする「フェーズ分割アプローチ」が有効です。いずれの場合も、契約前に「何が固定範囲でどこが変動するか」を書面で確認することをおすすめします。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：IPA（情報処理推進機構）「DX白書2023」（2023年3月発行）
