追加開発の全体像は、進め方、会社選び、費用、発注の順に押さえると理解しやすくなります。動いているシステムを扱うため、目的と影響範囲を明確にしてから進めることが欠かせません。
わずかな修正でも他の機能を止めてしまう「デグレ」の恐れがあり、費用の見通しも立てにくい領域です。
進め方、会社選定、費用、発注の各テーマは、次の個別記事で詳しく確認できます。
- 追加開発の進め方とは？要件定義から回帰テストまでの全工程
- 追加開発の会社選び｜既存ベンダー継続か切替かの判断軸
- 追加開発の費用相場｜機能数×品質レベルで算出する見積構造
- 追加開発の発注方法｜準委任契約と変更管理プロセスの実装
Webサービス開発の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
追加開発の全体像
追加開発とは、すでに稼働している業務システムや製品サービスに対して、機能の追加・改修・拡張を行う開発活動全般を指します。
新規開発がゼロから組み上げる作業であるのに対し、追加開発は「動いているものに手を入れる」作業です。このため、既存資産の保全と新しい価値の追加を両立させる難しさを抱えています。
フレシットの増田氏が「敗戦処理」の経験から語るように、追加開発は「どこを直すか」より先に「何が連動して動いているか」を理解することから始まります。
追加開発の種類と発生パターン
追加開発は大きく分けて、機能追加型・改修型・拡張型・連携型の四つに整理できます。機能追加型は新しいメニューや画面を加えるもの、改修型は既存機能の挙動を変えるもの、拡張型は処理データの種類や量を増やすもの、連携型は外部システムとのインターフェースを追加するものを指します。
発生パターンには、法改正対応や利用部門からの追加要望があります。ほかにも、利用者数の増加に伴う性能拡張、競合製品との機能差の解消、業務フロー変更への追従などが典型例です。たとえば建設資材卸A社は、大塚商会の「フィッティングコンサル」を活用して、パッケージシステムの追加開発・刷新を進めました。
この取り組みでは、ヒアリングに11週、パッケージ運用の議論に8週、方針検討に6週、業務フロー提案に1週を充て、計5.5ヶ月22週、会議40回弱という重厚な分析投資を行いました。その結果、開発費全体の5〜6%という比率に抑えたまま、安全に着地させた事例として知られています。動いているシステムを触るうえで、入念な事前分析が結果的にコストを下げる好例といえます。
「動いているものを触る」緊張感とデグレリスク
追加開発の最大のリスクは、デグレード（いわゆるデグレ）と呼ばれる現象です。一つの機能を直したつもりが、共通モジュールやデータ連携を通じて他の機能の挙動を壊してしまう事象を指します。新規開発であれば未稼働のため影響は限定的ですが、追加開発では本番運用中の業務にすぐ波及し、顧客対応や売上計上に支障をきたすおそれがあります。
このリスクを抑えるには、変更前に影響範囲調査を行い、変更箇所が呼び出される全経路を洗い出すことが欠かせません。そのうえで、既存機能を再検証するリグレッションテスト（回帰テスト）を、CI/CDの自動テスト基盤と組み合わせれば、検証コストを抑えつつ品質を保てます。発注側もベンダー任せにせず、影響範囲調査の依頼・承認・記録を自社の責任として持つ姿勢が求められます。
▶ 詳細はこちら：追加開発の進め方とは？要件定義から回帰テストまでの全工程をご覧ください。
追加開発の進め方
追加開発を成功させる進め方は、発生シーンの特定から始まり、リリース後（Day2）の運用まで続くライフサイクルとして整理できます。影響範囲の調査と要件の整理を経て見積を取り、契約形態を選んだうえで、開発と回帰テストに進みます。その後にリリースし、運用へと移ります。
新規開発と異なり、各フェーズで「既存資産にどう影響するか」を必ず確認する点が肝になります。
要件定義・企画フェーズ
追加開発の要件定義では、「必要な機能」と「あったら良い機能」を明確に仕分けることが最初の作業になります。また、要件は機能要件だけでなく、可用性・性能・セキュリティといった非機能要件まで踏み込んで定義する必要があります。
アジャイル開発や段階的リリース（スパイラル開発）を採用する場合は、最小限の機能で先にリリースし、利用者の反応を見ながら次の追加を決める進め方が有効です。デンソーの運転スコアリングアプリ「yuriCargo」は、2020年7月のローンチから5ヶ月で1,700ユーザーを獲得しました。フィードバックを取り入れた反復改善が機能拡張の方向を導いた、参考になる事例です。
非機能要件の定義精度はROIを左右する大きな要因です。たとえば、可用性99.9%と99.99%では実装コストが大きく異なるため、業務インパクトから逆算して定量的に設計する考え方を欠かさないことが大切です。
設計・開発・テストフェーズ
設計フェーズでは、既存システムの構成図やデータフロー図を再点検し、追加する機能がどの既存資産と相互作用するかを一覧にします。開発に入ったら、変更管理プロセスを発注側の責任で運用し、実装の前に影響範囲の調査と承認を通します。
テストを終えてから本番に反映するまで、各段階で明示的に確認を通すことが大切です。リグレッションテストは、影響範囲の機能の洗い出し、重点テスト項目の設計、自動テストの実装という流れで進めると効率が上がります。
追加開発を一度きりの案件で終わらせず、Day2（リリース後）まで含めた継続的な営みとして設計すると、回帰テストの自動化や監視運用のSRE的なアプローチを組み込みやすくなります。たとえばANAは、モバイルアプリにDevOpsを定着させるため、Pivotal Labsを参考に5ヶ月で課題整理、トライアル開発、評価を回し、組織として継続的に改善できる体制を作りました。
開発会社の選び方
追加開発の発注先選びは、新規開発以上に慎重さが求められます。
現行ベンダーを続けるか、別のベンダーに切り替えるかが、そもそもの論点になります。選定では、「業界知識」「既存資産の理解度」「回帰テストの自動化実績」といった点を見ます。さらに、「リスクの正直な開示姿勢」「SRE体制の有無」なども含め、多面的に評価する必要があります。
実績と技術力の確認ポイント
実績を見るときは、同業種・同規模の追加開発案件をいくつ手掛けたかに加えて、どの程度の既存システムを改修してきたか、つまり「触ったシステムの複雑度」が重要になります。レガシーシステムへの改修経験、業務基幹システムへの機能追加実績、外部連携の追加開発事例などを、具体的にヒアリングしてください。
技術力を評価するには、リグレッションテストの自動化率や、CI/CDパイプラインの構築実績、コードレビュー体制の整備状況を質問しましょう。安すぎる見積もりは、テスト工程削減の裏返しである可能性が高いため、テスト工数の比率と内訳まで確認することをおすすめします。
商談で力量を測るキラークエスチョンとしては、「過去に発生したデグレ事象と、その再発防止策を一例挙げてもらえますか」「追加開発で工数の増加が見込まれたとき、御社から発注側へどう提案しますか」が有効です。そのほか、「ソースコードとドキュメントの権利・引継ぎは、どう取り扱う方針ですか」と聞いてみるのも手です。
プロジェクト管理体制とサポートの評価
プロジェクト管理体制を評価するには、変更管理プロセスがベンダー側でも整備されているか、議事録や記録の管理ルールが明文化されているかを確認します。スルガ銀行と日本IBMの訴訟では、訴訟記録72冊や、宴会の箸袋に手書きされた金額交渉メモが証拠として提出されました。この経緯が示すように、「言った言わない」を防ぐ記録運用の質は、リスク管理に直結します。
発注前に確かめたいのは、次の点です。
- 記録のひな形：議事録テンプレートや変更管理票のサンプルを、発注前に共有してもらえるか
- リリース後（Day2）のサポート体制：どこまで対応してもらえるかを見ておきたい観点です
監視・SLA設計・エラーバジェット運用といったSRE的な観点を持ち、追加開発の納品後も継続して品質を支えられるパートナーかどうかを見極めることが大切です。さらに、リスクを正直に開示してくれるか、無理な納期に「できます」と即答せず合理的な根拠を示してくれるかという姿勢も、長期で付き合うベンダーを選ぶうえで欠かせない判断材料です。
▶ 詳細はこちら：追加開発の会社選び｜既存ベンダー継続か切替かの判断軸をご覧ください。
追加開発の費用相場
追加開発の費用は、「機能数 × 品質レベル × 人月単価」という式で構造的に算出するのが実務的な見方です。人件費は原価の約8割を占めるため、誰が、どの品質レベルで、何機能を開発するかという三つの要素が見積もりを左右します。
「いくらでできますか」という単純な質問では、見積もりの本質に迫れません。そのため、内訳の構造まで踏み込んで議論することが大切です。
規模別の費用目安
人月単価の相場感は、担当する人によって幅があります。上級SEは100〜160万円、初級SEは60〜100万円、大手プログラマーは50〜100万円が目安です。下請けや個人事業主は40〜60万円、外国籍プログラマーは30〜40万円というレンジです。
規模別に見ると、軽微な改修（1〜2機能）は数十万円から数百万円、中規模の機能追加は数百万円から1,000万円台に及びます。基幹システムへの大型追加開発になると、数千万円から億単位まで膨らみます。
スマホアプリの追加開発は、iOSとAndroidで別々に実装するため、Webシステムの1.5〜2.5倍の費用感になりやすい点も覚えておきたいところです。一方で、OSSやパッケージ製品をカスタマイズして使えば、ゼロから組む場合より40〜60%の費用削減が見込めます。だからこそ、追加開発でも既存のOSSを組み込むことを検討する価値は十分にあります。
費用を左右する主な要因
費用変動の最大要因は品質レベルで、低品質では標準の50〜70%、中品質では100〜150%、高品質では200〜400%となり、同じ機能数でも2〜4倍の振れ幅が生じます。ミッションクリティカルな業務基幹システムでは高品質レベルが必須となるため、見積額が大きく膨らみます。発注側は機能数に目が行きがちですが、費用を支配するのは品質レベルの選択だと認識しておくことが大切です。
追加費用の請求では、商法512条の存在も押さえておく価値があります。契約書に追加条項がなくても、(1)別途費用が発生する旨を文書で明示し、(2)システム会社が仕様変更の取決めを破っていなければ、「相当な報酬」の請求が成立する可能性があります。追加費用をめぐる紛争は規模を問わず起こりうるため、見積根拠と変更管理の記録を残す運用が、発注側の防衛策になります。
費用をめぐって争いになった例として、次の二つを挙げます。
- プログラム数の増加：182本から414本へ大幅に増えた裁判例では、見積書の「工数大幅変動時は別途相談」の一文を根拠に、追加請求が認められています。
- スルガ銀行と日本IBMの訴訟：初期費用95億円が合意書の段階で89億円となり、開発中断時には127億円の追加が要求されました。
この訴訟では、最終的に高裁で日本IBMに41億7,210万円の支払命令が確定しています。
▶ 詳細はこちら：追加開発の費用相場｜機能数×品質レベルで算出する見積構造をご覧ください。
追加開発の発注・外注方法
追加開発の発注では、要件が流動的になることを前提に、契約形態と発注プロセスを設計する必要があります。
新規開発の請負契約をそのまま流用すると、追加要望のたびに見積取得や契約変更が発生し、現場の負担が高まる傾向にあります。そのため、準委任契約や複数フェーズに分けた契約設計、変更管理の手順のひな形を用意しておくことが、発注運用を安定させる鍵です。
発注先の種類と契約形態の選び方
発注先には、現行ベンダーの継続やSIerへの新規発注といった選択肢があります。ほかに、専門ブティックファームへの発注、フリーランスの活用、内製化チームの組成もあります。それぞれにメリットとデメリットがありますが、追加開発では既存資産の理解度と回帰テスト体制が最も大きな判断材料になるため、現行ベンダーを続ける方が有利になりやすいというのが基本的な構図です。
契約形態は、要件が固まっている小規模な機能追加であれば請負契約、要件が流動的なフェーズや長期の機能拡張であれば準委任契約が合います。アジャイル開発や段階リリースを前提とする場合は、準委任ベースで稼働対価を支払いつつ、スプリント単位で機能を積み上げる進め方が実態に即しています。
Spotifyに代表されるSquad/Tribe/Chapter/Guildの組織モデルのように、追加開発を含めた運用体制を最初から設計しておくと、契約・組織・開発手法を一貫して運用できます。
発注前に準備すべきドキュメント
既存の仕組みと追加要件をベンダーに正しく伝えるため、発注前に資料をそろえておきます。
- 現行システム構成図
- データフロー図
- 追加要件の優先順位リスト
- 非機能要件定義書
- 変更管理プロセスの運用ルールと議事録テンプレート
これらの準備が甘いと、ベンダーから提案を引き出しにくくなり、結果として見積もりの精度も下がります。ベンダーロックインを避ける観点では、ソースコードと知的財産権の帰属、ドキュメント引継ぎ条項、コンテナ標準化や標準API活用の方針を、契約に明記しておきたいところです。
IT導入補助金やものづくり補助金の活用を考える場合は、事業計画書の作成に工数がかかることや、交付決定前は契約や着手ができないという制約も考慮に入れます。補助金を当てにして発注時期を決めると、商談全体が補助金の日程に縛られてしまいます。そのため、補助金は「使えればラッキー」くらいに位置づけ、発注計画は事業ROIで判断するのが現実的です。
▶ 詳細はこちら：追加開発の発注方法｜準委任契約と変更管理プロセスの実装をご覧ください。
追加開発で失敗しないためのポイント
追加開発の失敗パターンは五つに集約されます。デグレが多発することや、要件が膨らんで予算を超えることがあります。加えて、ベンダー任せによる品質劣化、経営層と現場の対立、コンコルド効果で中止を判断できないことが挙げられます。
これらを回避するには、変更管理プロセスを発注側の責任で運用することが鍵です。そのうえで、見積の構造を理解して品質レベルを設計し、リリース後のDay2運用も最初から織り込んでおきます。さらに、「やめる勇気」を支える中止判断スコアを、あらかじめ設計しておくことも欠かせません。
コンコルド効果を回避する中止判断スコア
コンコルド効果とは、すでに投じたコスト（サンクコスト）を惜しんで、合理的には中止すべきプロジェクトを継続してしまう心理傾向を指します。追加開発は当初の予算と納期を超えやすい性質があるため、経営者がこの効果に陥ると、損失が雪だるま式に拡大しがちです。
中止判断スコアは、五つの指標をそれぞれ点数化して合算する方式が実務的です。指標には、当初見積からの工数超過率や残作業のリスク評価があります。そのほか、業務インパクトの再評価、代替案のコスト比較、ステークホルダー合意の難易度を入れます。
スルガ銀行訴訟が示唆するように、紛争規模が大きくなるほど傷の深さも増すため、明示的な中止判断の基準を持っておくことが防衛策になります。たとえば、一定の基準を超えた段階で、継続・縮小・凍結・中止のいずれかを役員会議体に上程するルールを決めておくと、感情論ではなく数値をもとに判断できるようになります。
セキュリティ・法令対応の考え方
追加開発であっても、セキュリティ要件と法令対応は、新規開発と同じか、それ以上に厳しく扱う必要があります。既存システムに個人情報の項目を加える、外部APIと新たに連携する、決済機能を拡張するといった場合、影響は機能拡張にとどまらず、コンプライアンス全体に広がります。
要件定義には、情報セキュリティ規程との整合、個人情報保護法やGDPRなど該当法令の確認、監査ログの取得設計を必ず組み込んでください。また、商法512条と関連する判例の知識は、追加費用の請求や契約解釈で揉めた際の判断材料として役立ちます。
プログラム数が182本から414本へ増加し、問題になった裁判例のように、見積書の一文や議事録の記載が証拠として機能する場面は珍しくありません。このため、法務部門や顧問弁護士と相談しながら、契約書・見積書・議事録の三点セットを整える姿勢が、コストとリスクを抑える最も確実な投資になります。
まとめ
追加開発は、「動いているものを触る」緊張感を本質的に抱えた営みです。そのため、デグレのリスク管理や影響範囲の調査、回帰テストの自動化を、新規開発以上に注意深く扱う必要があります。変更管理を発注側の責任で運用することや、品質レベルの選択で費用を設計することも、押さえておきたい論点です。
費用は「機能数 × 品質レベル × 人月単価」で構造的に算出され、品質レベルの選択次第で50%から400%まで、2〜4倍の振れ幅が生じます。
OSS活用で40〜60%の削減余地があります。また、商法512条の追加請求の条件や、プログラム数が182本から414本へ増えて追加請求が認められた判例も、実務の知識として押さえておきたいところです。
スルガ銀行と日本IBMの訴訟では、初期費用95億円が合意書の段階で89億円となり、開発中断時には127億円の追加が要求されました。最終的には、41億7,210万円の支払命令が確定しています。
訴訟記録72冊や、宴会の箸袋に手書きされた金額交渉メモといった一次情報は、「言った言わない」リスクと記録運用の重要性を象徴しています。
デンソーのyuriCargo（5ヶ月で1,700ユーザーを獲得）、ANAのDevOps定着、大塚商会フィッティングコンサルの事例（開発費の5〜6%で着地）など、成功事例から学ぶ姿勢も役立ちます。そのうえで、コンコルド効果を回避する中止判断スコアまで含めた意思決定の仕組みを社内に持つことが、追加開発を継続的な競争力に変える近道となります。
開発を相談する前に確認できる資料は、無料ホワイトペーパー
・Webサービス開発の完全ガイドブックと【2026年最新版】AI駆動開発の完全ガイドブックです。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。