追加開発は、稼働中のシステムに手を入れる難しさが常につきまとう取り組みです。新規開発と違って「動いているものを触る」緊張感があり、たった一行の修正が連動機能を壊し、デグレード（既存機能の劣化）を引き起こすリスクを常に抱えます。費用感が読みにくいうえに、ベンダーから追加費用を請求されるのではないかという不安、プロジェクト炎上の恐れ、デグレに伴うサービス停止リスクなど、発注側が抱える悩みは複合的です。
本記事では、追加開発の進め方を「影響範囲調査 → 要件整理 → 見積取得 → 契約形態選定 → 開発・回帰テスト → リリース・Day2運用」というライフサイクル全体で解説します。商法512条や、プログラム数が182本から414本に膨らんだ判例、スルガ銀行と日本IBMの訴訟で確定した41億7,210万円の支払命令といった法的根拠を踏まえつつ、発注側が主体的に組み立てる「変更管理プロセス」のテンプレートを提示します。読み終えるころには、デグレリスクと追加費用リスクの双方をコントロールし、追加開発を炎上させない実装手順を手に入れられるはずです。
追加開発の全体像と「動いているものを触る」緊張感
追加開発とは、既に稼働しているシステムに新しい機能を追加したり、既存機能を改修したりする開発活動を指します。新規開発がゼロからの設計・実装であるのに対し、追加開発は「動いているものを触る」前提があり、既存データ・既存連携・既存業務フローを壊さないことが最優先となります。フレシットの増田氏が「敗戦処理」と呼ぶ案件に共通するのは、開発側が「どこを直すか」ばかりに目を向け、「何が連動して動いているか」を理解しないまま着手することで炎上するパターンです。
追加開発が必要になるシーンは多岐にわたります。法改正への対応、業務拡大に伴う機能拡張、現場ユーザーからの改善要望、外部システムとの新規連携、セキュリティ要件の強化などが典型です。いずれのケースも「小さな修正」に見えがちですが、連動する機能・データ・外部連携への波及まで含めると工数が跳ね上がるのが追加開発の本質的な難しさです。
デグレリスクと影響範囲調査が追加開発の主軸になる理由
デグレード（デグレ）とは、追加開発によって既存の正常機能が動作しなくなったり、性能が劣化したりする現象を指します。発生原因の多くは、共通モジュールや共通テーブルの修正が他機能に予期せず影響することです。たとえば在庫テーブルにフラグを一つ追加しただけで、受発注機能・棚卸機能・帳票出力・データ連携など複数のサブシステムが連動して動作不良を起こすケースは珍しくありません。
そのため追加開発の進め方は、新規開発のように「要件定義→設計→実装→テスト→リリース」を線形に進めるのではなく、入口に「影響範囲調査」を置き、出口に「リグレッションテスト（回帰テスト）」を置く構造になります。中央のフェーズが新規開発と同じであっても、入口と出口の重みが大きく異なる点こそ追加開発の特徴です。
影響範囲調査では、(1)対象機能のソースコード依存関係 (2)データベーステーブル・カラム間の参照関係 (3)外部システム・APIとの連携箇所 (4)バッチ処理・帳票処理など非同期処理への影響 (5)業務フロー上の前後工程への波及、の5観点を網羅します。発注側はこの5観点を「影響範囲調査チェックリスト」として標準化し、ベンダーに必ず提出させる運用にすべきです。
発注側が主体で組む「変更管理プロセス」の必要性
追加開発で発注側が陥りがちな失敗が、変更管理プロセスをベンダーに丸投げすることです。ベンダー側は「言われた範囲を実装する」のが基本姿勢のため、影響範囲調査の網羅性や、本番リリース可否の判断はどうしても発注側で握る必要があります。変更管理プロセスを発注側責任として設計しないまま開発を進めると、運用開始後に「想定していなかった機能が動かない」「業務が止まる」という事態に直面します。
変更管理プロセスとは、変更要求の起票から、影響範囲評価、優先度判定、承認、設計、実装、テスト、リリース、結果記録までを一貫した流れにし、発注側がフェーズゲートで承認権を持つ仕組みです。スルガ銀行と日本IBMの訴訟では、初期費用95億円から始まったプロジェクトが89億円の合意書に至り、開発中断時に127億円が追加要求され、最終的に高裁で日本IBMに41億7,210万円の支払命令が確定しました。証拠として宴会の箸袋に書かれた金額メモが提出された経緯は、発注側が変更管理プロセスを欠いていた典型例として語り継がれています。
発注側が持つべき変更管理プロセスの中核は、(1)変更要求票のフォーマット化 (2)影響範囲評価レポートの提出義務化 (3)金額・期間影響を含む承認基準 (4)議事録・チャットログを含む文書管理 (5)リリース可否判定の最終承認権、です。これらをベンダーとの基本契約や個別契約に明記し、運用設計まで詰めておくことが追加開発を炎上させない最大の防衛策となります。
追加開発の進め方ステップ1：影響範囲調査と要件整理
追加開発の出発点は、影響範囲調査と要件整理を一体で進めることです。要件だけ先に固めてから影響範囲を調べると、後出しで実装不可能と判明したり、想定外のコスト爆発が起きたりします。発注側は最初から「やりたいこと」と「触れる範囲」を並行で検証する姿勢が必要です。
影響範囲調査チェックリストの実装テンプレート
影響範囲調査チェックリストは、追加開発の起票時にベンダーへ必ず記入させるフォーマットとして整備します。具体的には、変更対象モジュール名、参照しているテーブル・カラム、共通関数・共通画面の利用箇所、外部連携API・バッチの一覧、業務フロー上の前後工程、過去の障害履歴との関連性、自動テストでカバーされている範囲、未カバー領域での手動テスト計画、の8項目をベースとして用意します。
このチェックリストはWordやExcelで「変更要求票」として一枚化し、毎回起票・承認・保存される運用にします。書面化することで、後にトラブルになった際に「どこまで影響を読み切ったうえで進めたか」を客観的に示せる証拠資料となります。プログラム数が182本から414本へ膨らんだ判例では、見積書に「工数が大幅変動する場合は別途相談」と明記されていたことが追加請求の認容判決につながりました。発注側にとっても、影響範囲を文書で握っておくことが守りの基本となります。
「必要な機能」と「あったら良い機能」の仕分け方
要件整理では「必要な機能（Must）」と「あったら良い機能（Want）」を切り分け、Mustからリリースしていく優先順位付けが欠かせません。要件が膨らみすぎると、追加開発の費用は「機能数 × 品質レベル × 人月単価」で算出されるため、簡単に倍々に跳ね上がります。品質レベルが低なら×50〜70%、中なら×100〜150%、高なら×200〜400%という変動率が一般的で、Wantを高品質で実装するだけで全体費用が2〜4倍に膨らみます。
仕分けの実践では、(1)業務が止まるかどうか (2)法令・契約遵守に必要か (3)売上・利益に直結するか (4)既存機能の代替手段で凌げるか、の4つの問いを各要件に当てます。これに該当すればMust、それ以外はWantに振り分け、MustだけをMVPとして先行リリースする方針が、追加開発を炎上させないための鉄則となります。デンソーの運転スコアリングアプリ「yuriCargo」は、2020年7月のローンチから5ヶ月で1,700ユーザーを獲得した事例ですが、これも初期スコープを絞ったMVP戦略の典型例です。
追加開発の進め方ステップ2：見積取得と契約形態の選定
影響範囲と要件が固まったら、見積取得と契約形態の選定に進みます。追加開発は要件が流動化しやすいため、新規開発で使われる「請負契約」だけに頼ると、追加見積や契約変更が頻発して、進捗が止まる原因になります。発注側は契約形態の選択肢を理解し、状況に合わせて使い分ける必要があります。
品質レベル変動率を見積に組み込んで読み解く
追加開発の見積は「機能数 × 品質レベル × 人月単価」で構成され、人件費が約8割を占めます。人月単価の相場は、上級SEで100〜160万円、初級SEで60〜100万円、大手SIerのプログラマーで50〜100万円、下請けや個人事業主で40〜60万円、外国籍プログラマーで30〜40万円と幅があります。安すぎる見積はテスト工程が削られている可能性が高く、結果としてデグレ多発でリカバリ費用が膨らむため、人月単価だけを比較するのは危険です。
品質レベルは「低」「中」「高」で分け、それぞれ×50〜70%、×100〜150%、×200〜400%の変動率を持ちます。スマホアプリ（iOS/Android別実装）はWebシステムの1.5〜2.5倍高くなる傾向があり、要件次第で総額が一気に動きます。OSSやパッケージを活用すれば、カスタマイズ前提で費用を40〜60%削減できる場合もあり、品質レベルと開発スタイルを掛け合わせて読み解く視点が欠かせません。
見積取得時は、相見積もりを2〜3社から取得し、人月単価・想定工数・テスト工程の内訳・前提条件を必ず比較します。前提条件には「影響範囲は変更要求票記載の範囲に限定」「品質レベルは中」「自動テストを80%カバー」など、後で「言った言わない」にならないよう数値で書き込みます。商法512条では、契約書に追加条項が明記されていない場合でも「別途費用発生を文書で明示」「仕様変更の取決めをシステム会社が破っていない」を満たせば相当な報酬請求が法的に成立するため、発注側にとっても文書化は防御策となります。
請負契約と準委任契約の選び分け
追加開発に適した契約形態の選択は、要件の固まり具合で判断します。要件が明確で完成形が定義できる場合は請負契約が向き、要件が流動的でユーザーフィードバックを反映しながら進めたい場合は準委任契約が適します。請負契約は完成責任が受託側にあり成果物単位で支払いますが、要件変更があれば都度見積・契約変更が必要となり、追加開発の現場では摩擦の原因になりがちです。
一方の準委任契約は、稼働対価（人月や時間単位）で支払う形式で、要件変更を前提とした運用に馴染みます。アジャイル開発や段階的リリース、Day2運用フェーズの保守追加開発などは準委任契約が実態に合っています。デンソーやANAのモバイルアプリ事例で見られるアジャイル開発も、準委任ベースの稼働で動かす前提で組み立てられているケースが大半です。
実務では、要件定義フェーズと初期構築は請負契約、追加開発・保守フェーズは準委任契約というハイブリッド構成が現実的です。重要なのは、契約変更時の手続き・ソースコードの帰属・ドキュメント引継ぎ・ベンダーロックイン回避条項などを基本契約に盛り込み、フェーズが変わるたびに揉めない設計を最初に行うことです。
追加開発の進め方ステップ3：開発とリグレッションテスト
契約と見積が固まり開発フェーズに入ってからも、追加開発はリリース直前のリグレッションテスト（回帰テスト）が成否を分けます。リグレッションテストとは、追加開発の対象機能だけでなく、影響範囲調査で洗い出した周辺機能・連携機能まで含めて「既存の正常箇所が動作することを再確認する」テスト工程です。新規開発のテストが「新機能が要件通り動くか」を確かめるのに対し、追加開発では「既存機能を壊していないか」を確かめる視点が中心となります。
リグレッションテストの設計と自動化
リグレッションテストの設計は、影響範囲調査チェックリストと一対一で対応させるのが基本です。チェックリストで挙がった連動機能・共通モジュール・外部連携・バッチ処理・帳票出力のそれぞれにテストケースを割り当て、変更前と同じ結果が得られることを確認します。テストケースは「業務シナリオ単位」で組むと網羅性が高まり、机上での仕様確認では発見できない実運用に近い不具合を検出できます。
追加開発は繰り返し発生する性質のため、リグレッションテストの自動化投資はROIが高い領域です。CI/CDパイプラインに自動テストフレームワークを組み込み、コードがマージされるたびに既存テストが自動実行される仕組みを整えることで、リグレッションを早期に検出できます。テスト自動化のカバレッジ目標は、業務クリティカルな機能で80%以上、その他で50%以上を目安に置くと、追加開発のたびに手動テストの工数が爆発する事態を避けられます。
本番リリース可否の最終判定は、(1)新機能の受入テスト合格 (2)既存機能のリグレッションテスト合格 (3)非機能要件（性能・セキュリティ・可用性）の合格 (4)障害発生時の切戻し手順の確認、の4条件で行います。切戻し手順は、データベースのスナップショット取得、アプリケーションの旧バージョンへの戻し、外部連携先への影響告知の3点を最低限含み、リリース当日に動かせる状態にしておく必要があります。
段階的リリースとアジャイル開発の活かし方
追加開発を一括で大きくリリースすると、デグレ発生時の影響範囲が広がり切戻しが困難になります。そのため、段階的リリース（カナリアリリース、ブルーグリーンデプロイ、機能フラグ運用）を組み合わせ、影響を限定的に検証しながら本番展開する手法が定着しつつあります。アジャイル開発における短いスプリント単位のリリースも、これと同じ思想です。
ANAはPivotal Labsを参考に、5ヶ月で課題整理・トライアル開発・評価を回しDevOpsを組織に定着させました。Spotifyが採用しているSquad/Tribe/Chapter/Guildの独自組織体制は、Squadごとにフレームワーク選択権を持たせ、変更を素早く反映する文化を支える仕組みとして有名です。これらは「追加開発を内包した運用設計」であり、完成形を固定せず常に変化を前提とした追加開発スタイルの好例といえます。
追加開発の進め方ステップ4：リリース後のDay2運用と中止判断
追加開発の終わりはリリースではなく、Day2と呼ばれるリリース後の運用フェーズです。本番環境での挙動監視、SLA（サービス品質保証）に基づく可用性管理、エラーバジェットを使った改善計画、SRE（Site Reliability Engineering）的なアプローチを組み込むことで、追加開発を継続的な改善サイクルに変換できます。逆にDay2を軽視すると、追加開発が積み重なるごとに技術的負債と運用負荷が雪だるま式に膨らみます。
監視・SLA・エラーバジェットを前提に置く
Day2運用の基本は、アプリケーションログ・インフラメトリクス・ビジネスKPIの3層で監視を組み立てることです。各層に閾値とアラートを設定し、異常検知時に即座に対応できる体制を整えます。可用性99.9%と99.99%では年間ダウンタイム許容値が約9時間から約53分まで一桁変わるため、業務インパクトから逆算してSLAを定義し、それに見合う冗長構成・監視粒度を設計します。
エラーバジェット運用は、SLA目標と実績の差分を「許容可能なエラー量」として可視化し、追加開発のスピードと品質のバランスを取る考え方です。エラーバジェットを使い切った月は新機能開発を止めて品質改善に集中し、余裕がある月は追加開発を加速させる、というように発注側の意思決定を数値で支えます。Day2の運用ルールをベンダーとの契約に盛り込んでおけば、追加開発フェーズに入っても炎上せず継続的に改善できる体制が組めます。
コンコルド効果を避ける中止判断スコア
追加開発が泥沼化しても「ここまで投じた費用が惜しい」とサンクコストにとらわれ、中止判断を先送りしてしまう心理を「コンコルド効果」と呼びます。経営者がコンコルド効果に陥ると、損失が雪だるま式に膨らみ、最終的にプロジェクト全体が破綻します。スルガ銀行と日本IBMの訴訟で確定した41億7,210万円の支払命令は、開発中断の判断遅れがいかに高くつくかを示しています。
中止判断は感情ではなく数値スコアで行うべきです。(1)残工数と当初計画の乖離率が50%超 (2)主要要件の達成率が70%未満 (3)受入テストの合格率が60%未満 (4)月次バーンレートが当初予算の1.5倍超 (5)経営層・現場の合意形成が崩壊している、これら5項目のうち3項目以上に該当した時点で中止または大幅縮退の検討に入る、という事前ルールを策定しておきます。
事前ルールは、プロジェクト開始時に経営層・現場・ベンダーの三者で合意し、議事録に記録しておくことが重要です。事後にルールを持ち出すと「言った言わない」の議論になり、コンコルド効果を強化してしまいます。スコアに基づく機械的な中止判断は、関係者を感情的な対立から守る防御策として機能します。
まとめ：追加開発を炎上させない発注側の構え
追加開発は「動いているものを触る」緊張感を抱える領域であり、新規開発のフレームをそのまま流用すると必ず炎上します。影響範囲調査を入口に置き、リグレッションテストを出口に置き、その間を変更管理プロセスでつなぐという基本構造を発注側が主体的に設計することが、デグレリスクと追加費用リスクを同時にコントロールする最短ルートです。商法512条、プログラム数182本から414本に膨らんだ判例、スルガ銀行と日本IBMの訴訟といった法的事例は、文書化と承認フローを怠ったときに生じる損失の大きさを生々しく教えてくれます。
進め方を整理すると、(1)影響範囲調査と要件整理を一体で進める (2)Must/Wantを仕分けて品質レベルを意識した見積を取得する (3)請負と準委任のハイブリッド契約で要件流動性に備える (4)リグレッションテストの自動化と段階的リリースで品質を担保する (5)Day2のSRE/エラーバジェット運用とコンコルド効果回避の中止判断スコアを最初に決めておく、の5ステップに集約できます。これらを変更管理プロセスとして発注側の手元に置き、ベンダーに丸投げしない姿勢こそが、追加開発を成功に導く最大の鍵となります。
追加開発は一度きりのイベントではなく、システムが稼働している限り続く継続的な営みです。デンソーのyuriCargo、ANAのDevOps定着、Spotifyの組織モデル、大塚商会のフィッティングコンサルといった実例は、いずれも「変化を前提とした運用設計」を組織として持つことで成果につなげています。発注側の構えを変えることが、追加開発の質を変える出発点です。
株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。
また、弊社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。