追加開発の完全ガイド

稼働中のシステムに機能を追加するという行為は、新規開発とはまったく性質が異なります。動いているものを触る以上、わずか一行の修正が連鎖的に他の機能を巻き込み、これまで正常だった処理が止まる「デグレ（デグレード）」を引き起こす可能性が常につきまといます。費用感が読みにくく、ベンダーから追加費用を後出しで請求されないかと身構える方も少なくありません。本記事では、追加開発における全体像から会社選び、費用相場、発注方法、そして失敗しないための判断軸までを一気通貫で整理し、現場で即使える完全ガイドとしてまとめます。

スルガ銀行と日本IBMの大型訴訟で見られた95億円から89億円、127億円要求、最終的に41億7,210万円の支払命令という金額推移や、訴訟記録72冊・宴会の箸袋に手書きされた金額交渉メモが証拠採用された事例、プログラム数が182本から414本へ膨らんだ追加開発の判例など、一次情報を踏まえた実務知見を盛り込んでいます。商法512条による追加費用請求の成立条件、機能数×品質レベル×人月単価という算出式、コンコルド効果を回避する中止判断スコアなど、競合記事にはない切り口を取り入れていますので、追加開発を検討される方は最後までご一読いただければと思います。

▼関連記事
・追加開発の進め方とは？要件定義から回帰テストまでの全工程
・追加開発の会社選び｜既存ベンダー継続か切替かの判断軸
・追加開発の費用相場｜機能数×品質レベルで算出する見積構造
・追加開発の発注方法｜準委任契約と変更管理プロセスの実装

追加開発の全体像

追加開発とは、すでに稼働している業務システムや製品サービスに対して、機能の追加・改修・拡張を行う開発活動全般を指します。新規開発がゼロから組み上げる作業であるのに対し、追加開発は「動いているものに手を入れる」作業であり、既存資産の保全と新規価値の追加を両立させる難しさを抱えています。フレシットの増田氏が「敗戦処理」の経験から語る通り、追加開発は「どこを直すか」ではなく「何が連動して動いているか」を理解することから始まる領域となります。

追加開発は大きく分けて、機能追加型・改修型・拡張型・連携型の四つに整理できます。機能追加型は新しいメニューや画面を加えるもので、改修型は既存機能の挙動を変更するもの、拡張型は処理データの種類や量を増やすもの、連携型は外部システムとのインターフェースを追加するものを指します。発生パターンとしては、法改正対応や利用部門からの追加要望、利用者数増加に伴う性能拡張、競合製品との機能差解消、業務フロー変更への追従などが典型例です。

たとえば建設資材卸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%では実装コストが大きく異なりますので、業務インパクトから逆算して定量設計する考え方を欠かさないようにしてください。

設計フェーズでは、既存システムの構成図やデータフロー図を再点検し、追加する機能がどの既存資産と相互作用するかをマッピングします。開発フェーズに入ったら、変更管理プロセスを発注側責任で運用し、影響範囲調査・承認・実装・テスト・本番反映の各ゲートを明示的に通すことが重要です。リグレッションテストは、影響範囲の機能洗い出し、重点テスト項目の設計、自動テストの実装という流れで進めると効率が上がります。

ANAはモバイルアプリでDevOpsを定着させるため、Pivotal Labsを参考に5ヶ月で課題整理・トライアル開発・評価を回し、組織として継続的に改善を行える体制を作り上げました。追加開発を一度きりのプロジェクトとして扱うのではなく、Day2（リリース後）まで含めた継続的な営みとして設計することで、回帰テストの自動化や監視運用のSRE的アプローチが組み込みやすくなります。

▶ 詳細はこちら：追加開発の進め方とは？要件定義から回帰テストまでの全工程

開発会社の選び方

追加開発の発注先選びは、新規開発以上に慎重さが求められます。現行ベンダーを継続するのか、別のベンダーへ切り替えるのかという判断軸自体が論点となり、選定基準も「業界知識」「既存資産の理解度」「回帰テストの自動化実績」「リスクの正直な開示姿勢」「SRE体制の有無」など多面的に評価する必要があります。

実績の確認では、同業種・同規模の追加開発案件をいくつ手掛けたかだけでなく、どの程度の既存システムに対して改修を実施したかという「触ったシステムの複雑度」が重要になります。レガシーシステムへの改修経験、業務基幹システムへの機能追加実績、外部連携の追加開発事例などを具体的にヒアリングしてください。技術力の評価では、リグレッションテストの自動化率や、CI/CDパイプラインの構築実績、コードレビュー体制の整備状況を質問しましょう。

商談で力量を測るキラークエスチョンとしては、「過去に発生したデグレ事象とその再発防止策を一例教えてください」「追加開発における工数増加が見込まれた際、御社から発注側へどう提案しますか」「ソースコードとドキュメントの権利・引継ぎはどう取り扱う方針ですか」などが有効です。安すぎる見積もりはテスト工程削減の裏返しである可能性が高いため、テスト工数の比率と内訳まで具体的に確認することをおすすめします。

プロジェクト管理体制の評価では、変更管理プロセスがベンダー側にも整備されているか、議事録や記録の管理ルールが明文化されているかを確認します。スルガ銀行と日本IBMの訴訟では、訴訟記録72冊、宴会の箸袋に手書きされた金額交渉メモが証拠提出されたという経緯が示すように、「言った言わない」を防ぐ記録運用の質はリスク管理に直結します。発注前から、議事録テンプレートや変更管理票のサンプルを共有してもらえる会社を選びたいところです。

また、リリース後（Day2）のサポート体制も重要な評価軸となります。監視・SLA設計・エラーバジェット運用といったSRE的な観点を持ち、追加開発の納品後も継続して品質を支えられるパートナーであるかを見極めてください。リスクを正直に開示してくれるか、無理な納期に「できます」と即答せず合理的な根拠を示してくれるかという姿勢面も、長期で付き合うベンダー選定には欠かせない判断材料です。

▶ 詳細はこちら：追加開発の会社選び｜既存ベンダー継続か切替かの判断軸

追加開発の費用相場

追加開発の費用は「機能数 × 品質レベル × 人月単価」という式で構造的に算出するのが実務的な見方です。人件費が原価の約8割を占めるため、誰が、どの品質レベルで、何機能を開発するかという三要素が見積もりを支配します。単純な「いくらでできますか」という質問では本質に迫れないため、内訳構造に踏み込んで議論することが重要です。

人月単価の相場感としては、上級SEで100〜160万円、初級SEで60〜100万円、大手プログラマーで50〜100万円、下請けや個人事業主で40〜60万円、外国籍プログラマーで30〜40万円というレンジが目安となります。スマホアプリの追加開発はiOSとAndroidで別実装が必要なため、Webシステムの1.5〜2.5倍の費用感になりやすい点も覚えておきたいところです。

規模別では、軽微な改修1〜2機能で数十万円〜数百万円、中規模の機能追加で数百万円〜1,000万円台、基幹システムへの大型追加開発になると数千万円から億単位まで膨らみます。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運用を最初から織り込むこと、そして「やめる勇気」を支える中止判断スコアをあらかじめ設計しておくことが鍵となります。

コンコルド効果とは、すでに投じたコスト（サンクコスト）を惜しんで、合理的には中止すべきプロジェクトを継続してしまう心理傾向を指します。追加開発は当初の予算と納期を超えやすい性質を持つため、経営者がこの効果に陥ると損失が雪だるま式に拡大しがちです。スルガ銀行訴訟が示唆するように、紛争規模が大きくなるほど傷の深さも増しますので、明示的な中止判断基準を持っておくことが防衛策となります。

中止判断スコアの組み方としては、(1)当初見積からの工数超過率、(2)残作業のリスク評価、(3)業務インパクトの再評価、(4)代替案のコスト比較、(5)ステークホルダー合意の難易度、という五つの指標をそれぞれ点数化して合算する方式が実務的です。一定の閾値を超えた段階で、継続・縮小・凍結・中止のいずれかを役員会議体に上程するルールにしておくと、感情論ではなく数値ベースで意思決定できる土壌が生まれます。

追加開発であっても、セキュリティ要件と法令対応は新規開発と同等以上の厳しさで扱う必要があります。既存システムに新しい個人情報項目を追加する、外部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%で着地させた事例など、成功事例の学びを取り入れつつ、コンコルド効果を回避する中止判断スコアまで含めた意思決定の仕組みを社内に持つことが、追加開発を継続的な競争力に変えていく近道となります。

▼関連記事
・追加開発の進め方とは？要件定義から回帰テストまでの全工程
・追加開発の会社選び｜既存ベンダー継続か切替かの判断軸
・追加開発の費用相場｜機能数×品質レベルで算出する見積構造
・追加開発の発注方法｜準委任契約と変更管理プロセスの実装

株式会社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を創業。