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