追加開発の発注は、既存システムへの影響を調べ、RFPとSOWで条件を示し、契約と変更管理を発注側が主導して組み立てる流れで進みます。
動いているシステムに手を入れる分、準備が足りないと炎上や追加費用の請求を招きやすくなります。
▼関連記事
・追加開発完全ガイド
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
追加開発の発注前準備
追加開発の発注前準備は、新規開発以上に重要です。既に動いている本番システムに手を入れるため、「どこに連動して何が動いているか」を理解しないまま発注すると、デグレード（既存機能の悪化）が必ず発生します。
準備は、影響範囲調査、要件の優先順位付け、発注先の選定軸という3つの観点で進めることが成功への第一歩です。
影響範囲調査と既存システムの棚卸し
追加開発の発注前にまず行うべきは、既存システムの影響範囲調査です。フレシットの増田氏が「敗戦処理」の経験から語るとおり、システム変更は「何が連動して動いているか」を理解することから始まります。たとえば顧客マスタに項目を1つ追加するだけでも、参照する画面・帳票・バッチ処理・外部連携APIが10箇所、20箇所と連鎖するケースが現実には頻発しています。
影響範囲調査では、まず既存システムのドキュメント（基本設計書・テーブル定義書・画面遷移図・バッチ一覧）を棚卸しします。ドキュメントが古い場合や存在しない場合は、現行ベンダーから現行版を取り寄せるか、後述するリバースエンジニアリングで補完する必要があります。次に、追加したい機能が触るテーブル・画面・処理を洗い出し、それぞれが参照される側として何件の依存先を持つかを表形式で整理します。
影響範囲が広大な場合は、スコープを再検討し、「あったら良い機能」を切り捨てて「必要な機能」だけに絞ると、回帰テストの工数と費用を半減できるケースもあります。デンソーの「yuriCargo」事例では、コア機能のみで小さくローンチし、5ヶ月で1,700ユーザーを獲得後、フィードバックを反映しながら段階的に機能を追加しました。スモールスタート・段階リリースは、追加開発のリスクを下げる王道アプローチです。
現ベンダー継続か別ベンダー切替かの判断
追加開発の発注先として最初に検討すべきは、現行システムを構築した既存ベンダーです。既存ベンダーは内部構造を熟知しているため影響範囲調査の工数を短縮でき、最短ルートでリリースに到達できる可能性が高くなります。一方で、料金が割高だったり、保守要員の質が低下していたり、要求した品質基準を満たせなかったりするケースも頻発します。
切り替えの判断軸は次の5点で、これらを基準にすると判断しやすくなります。
- 保守体制：保守稼働が形骸化し、エンジニアの入れ替わりが激しい
- 見積もり：市場相場の1.5倍以上で、交渉の余地がない
- 障害対応：リードタイムが長期化している
- 技術対応：新技術への対応力に疑問がある
- 権利・引継ぎ：契約上のソースコード権利・ドキュメント引継ぎ条件で揉めている
1つでも該当すれば、別ベンダーへの切替見積もりを並走させ、比較材料を集めるのが定石です。
別ベンダーへ切り替える場合は、リバースエンジニアリング（既存のソースコード・データベース・稼働中の挙動から仕様書を逆生成する作業）の工数を見込む必要があります。元のドキュメントが不十分な場合は、規模と技術スタックで判断します。
コード行数が5万行を超える大規模システムなら、現ベンダーの継続が無難です。月間障害発生率が高く現ベンダーへの不信感が強いなら、別ベンダーとリバースエンジニアリングを選びます。中規模で技術スタックが標準的なら、別ベンダーでもリバース工数は見積もり総額の15〜25%程度に収まります。
「必要な機能」と「あったら良い機能」の仕分け
追加開発で最も費用が膨らみ、最も炎上しやすいのが「要望の無制限受け入れ」です。経営層・現場・各部門から上がる要望を全て取り込むと、初期見積もりの2〜3倍まで膨張するのが典型的な失敗パターンです。そのため、発注前に要望の優先順位を厳密に仕分けてスコープを確定することが、コストとスケジュールを守り、後の追加費用請求リスクを抑える最大の防御策になります。
仕分けの実務手法としては、MoSCoW法（Must / Should / Could / Won’t）の適用が有効です。Mustは「これがないとリリースできない」必須機能、Shouldは「リリース時点で欲しいが代替手段がある」機能、Couldは「あったら良いが優先度は低い」機能、Won’tは「今回はやらない」機能と明示して分類します。
Won’tに分類した項目は議事録に残して「次フェーズで検討」と明記し、現場の納得感を保ちながらスコープを絞り込みます。仕分けの結果は発注前に経営層・現場・IT部門の三者で承認を取り、書面化しておきます。これを怠ると、開発途中で「言った言わない」の議論が起き、ベンダーから追加見積もりが提示された際に拒否しづらくなります。
追加発注のRFP/SOW設計と品質レベル明示
追加開発のRFP（提案依頼書）とSOW（Statement of Work：作業指示書）は、新規開発のテンプレートをそのまま使うべきではありません。
既存システムの前提条件、連動範囲、品質レベルの基準値、回帰テストの責任分界を明示しておかないと、ベンダー側が恣意的に解釈する余地が生まれ、後日の追加費用請求の根拠に使われます。
発注側が主導して、RFP/SOWの粒度を細かく設定することが追加発注成功の核です。
追加開発RFPに必ず記載すべき項目
追加開発のRFPには、新規開発のRFPに加えて「既存システムの前提条件」を厚く記載する必要があります。
既存システムの前提条件を次の5群に整理すると、見積もり条件を比較しやすくなります。
- アーキテクチャ図と技術スタック：現行システムの構成と技術要素を示します。
- 基本設計書とデータベース定義書：現行ベンダーから資料を取り寄せます。
- トランザクション量とピーク負荷：現行の月間量とピーク時データを開示します。
- 外部システムの一覧と接続仕様：連携先と接続条件を明記します。
- 障害発生履歴と対応事例：過去の障害と対応内容を共有します。
追加開発の要件記述では、機能要件と非機能要件を分けて書きます。機能要件は何を作るか（画面・処理・帳票）、非機能要件は性能・可用性・セキュリティ・運用・保守の品質基準です。
追加開発では特に「既存機能の品質を悪化させないこと」を非機能要件として明文化する必要があります。具体的には、「レスポンスタイム劣化が10%以内」「既存バッチの実行時間が現行+15%以内」「既存APIの後方互換性100%維持」といった定量基準で示します。
RFPには回帰テストの責任分界も明記します。「ベンダーが実施する回帰テストの範囲」「発注側が受入テストで担当する範囲」「テスト自動化の有無と継続運用責任」を契約前に合意しておくと、リリース後の不具合発生時に責任の所在が明確になります。
回帰テストの範囲が曖昧だと、ベンダーは「触っていない箇所だから影響範囲外」、発注側は「同一システムなので品質保証範囲内」と主張が衝突し、追加費用負担をめぐる紛争に発展します。
SOW（作業指示書）の粒度と成果物定義
SOWは契約書に紐づく作業指示書で、「何を、いつまでに、どの品質で納品するか」を具体的に記述する文書です。追加開発のSOWでは、フェーズごとの成果物リスト、受入基準、検収条件を明示します。たとえば設計フェーズなら、「修正対象機能の詳細設計書」「影響範囲調査報告書」「回帰テスト計画書」を成果物として列挙し、それぞれのレビュー・承認手順を記載します。
SOWの粒度は、成果物の章立てレベルまで踏み込んで定義することを推奨します。「設計書1冊」では曖昧すぎるため、「画面設計（修正画面5本×3ページ）」「データベース変更設計（追加3テーブル・修正5テーブル）」「外部I/F仕様変更箇所一覧」のように、ページ数・項目数まで指定します。これにより、後日の「成果物が足りない」「これも入っていると思っていた」というスコープ紛争を防げます。
検収条件もSOWで明確化し、「成果物が合格と判定される基準」として、機能要件の確認方法、非機能要件の測定方法、受入テストの合格率を定量化します。合格率の例は「致命的不具合ゼロ、重要不具合5件以内、軽微不具合10件以内」です。検収条件が不明確だと、ベンダーは「納品済み」、発注側は「合格していない」と支払いを保留するという紛争が起きやすくなります。
品質レベルの明示（低・中・高）と費用への影響
追加開発の見積もりは「機能数 × 品質レベル × 人月単価」で算出され、人件費が約8割を占めます。その中でも品質レベルの選択が見積額を最も大きく左右し、低なら通常の50〜70%、中なら100〜150%、高なら200〜400%と変動するため、同じ機能でも品質要件次第で4倍以上の差が生まれます。
発注側が品質レベルを明示しないと、ベンダーは保守的に高品質を仮定して見積もりを膨らませがちです。品質レベルの評価軸は次の5項目です。
- 業務クリティカル度：停止が経営に直撃するか
- 外部公開範囲：社内のみか顧客向けか
- 取扱データの機密性：扱う情報の機密の度合い
- 法規制：個人情報保護・財務情報・医療情報
- 可用性要件：24時間365日かビジネスアワーのみか
たとえば社内の管理画面の機能追加なら「中」、顧客が直接触れる決済機能の追加なら「高」、内部の社員向けレポート機能なら「低〜中」と振り分けます。
非機能要件は具体的な数値で示すことが大切で、たとえば可用性99.9%と99.99%の違いは、停止許容時間に換算すると年間8.76時間と52.6分にあたり、実装コストも数倍違ってきます。レスポンスタイムも「3秒以内」と「1秒以内」では、負荷試験・チューニング工数が2〜3倍変わります。
これらをRFPで明示し、品質レベルを業務インパクトから逆算して指定すると、過剰品質を防ぎ、適正コストでの発注が可能になります。
契約形態の選択と商法512条適合契約
追加開発で最も揉めやすいのが、契約形態と追加費用の取り扱いです。
スルガ銀行と日本IBMの訴訟では、初期費用95億円が合意書で89億円となり、開発中断時に追加127億円が要求されました。最終的には高裁で、日本IBMに41億7210万円の支払命令が確定しています。
訴訟記録は72冊に及び、宴会の箸袋に手書きされた金額交渉メモまでが証拠提出される泥沼となりました。発注前の契約設計がどれほど重要かを物語る象徴的な事例です。
請負契約と準委任契約の使い分け
追加開発の契約形態は、「請負契約」と「準委任契約」のどちらを選ぶかが最大の論点です。請負契約は「成果物の完成」に対して支払う形態で、機能仕様と品質基準を契約時に確定できる場合に向きます。一方で、要件が流動的だと追加見積もりや契約変更が頻発し、契約管理コストが膨らみます。
準委任契約は「稼働時間」に対して支払う形態で、要件が流動するアジャイル型の追加開発に適しています。使い分けの基準は次の3パターンで、実務でよく採られます。
- 請負：要件が確定しており、短期間でスコープを固定できる場合
- 準委任：要件が流動的で、2〜3ヶ月以上の継続的な追加開発の場合
- ハイブリッド型：初期は準委任で要件定義を行い、設計以降は請負に切り替える
準委任型のアジャイル開発は「完成形を固定しない」契約設計で、デンソーのyuriCargoや国内の多くのスタートアップが採用しています。
準委任契約を選ぶ場合は、稼働時間の上限・下限を明示し、ベンダーの工数管理を可視化する仕組みを契約条項に組み込む必要があります。具体的には、次の3点を契約書に明記します。
- 稼働時間の範囲：月間140〜180時間
- 工数の報告：日次の作業報告と月次の工数集計報告
- 想定超過時：想定稼働を超える場合の事前承認プロセス
明記を怠ると、準委任契約が「稼働時間無制限の追加請求装置」になりかねません。
商法512条と追加費用請求の法的成立条件
追加開発で頻発するのが、契約書にない追加作業に対して後日ベンダーから費用請求されるケースです。発注側は「契約していないから払わない」と主張したくなりますが、商法512条では、商人がその営業の範囲内において他人のために行為をしたときは相当な報酬を請求できます。そのため、契約書がなくても費用請求が法的に成立するケースがあります。
判例では、(1)別途費用発生を文書で明示しており、(2)システム会社が仕様変更取決めを破っていない、という2要件を満たせば「相当な報酬請求」が認められています。プログラム数が当初見積もりの182本から実装時に414本へ増えた裁判例では、追加費用が争われました。
この裁判では、見積書に「工数大幅変動時は別途相談」と記載があり、契約書に追加条項はなかったものの、商法512条を根拠に追加費用の請求が認められました。
発注側の防衛としては、「契約書にない＝払わなくて良い」が通用しない以上、商法512条に適合した契約設計、つまり追加作業発生時の事前承認プロセスを契約条項に組み込むことが必要です。具体的には、次の3点を契約書に盛り込みます。
- 事前の通知：追加作業を見つけた時点で、書面により発注側へ知らせる義務
- 費用の帰属：発注側の事前承認がない追加作業の費用は、ベンダー側に帰属
- 提示の形式：見積もり・スケジュール・影響範囲を、承認フォーマットに沿って示す義務
商法512条による「相当な報酬請求」の余地は、契約条項によって限定的にできます。
ベンダーロックイン回避条項の組み込み
追加開発を続けるうちに、システムの内部構造を熟知するベンダーが事実上の唯一の発注先となり、価格交渉力を失う「ベンダーロックイン」が頻発します。これを契約段階で防ぐには、次の4点を契約条項に組み込みます。
- 権利の帰属：ソースコードの所有権・利用権は発注側に帰属させる
- ドキュメント：第三者が引き継げる水準での納品を義務づける
- 技術スタック：コンテナ・標準API・OSSベースに統一する
- 引継ぎ：契約終了時の協力義務と、引継ぎ期間中の人件費単価
ソースコードの権利帰属は特に重要です。多くのベンダー契約書はソースコードの著作権をベンダー側に留保しており、発注側は「使用権のみ」しか持たないケースが大半です。これを発注側帰属に変更交渉するか、最低でも「ソースコードの第三者開示権」「ソースコード改変権」を確保しないと、別ベンダーへの切替は事実上不可能になります。
交渉時には、「これはripla社の知的財産にも関わるため、契約締結前に明文化したい」と直接的に伝えるのが効果的です。
加えて、次のような条項を置くと、別ベンダーへ移行する際の技術的障壁を下げられます。例として、「特定ベンダー固有のフレームワーク・ライブラリの使用は事前承認制」や「データベースは標準SQL準拠とし、独自拡張機能の利用は事前承認制」があります。「コンテナ（Docker / Kubernetes）ベースの実装を原則とする」も同じ考え方です。
ベンダーロックインを避ける条項は、将来の追加開発を別ベンダーに発注する選択肢を残すための戦略的な防衛策です。
変更管理プロセスの設計と発注側責任
追加開発の炎上を防ぐ最大の防御策は、発注側が主導する変更管理プロセスです。多くの企業は「変更管理はベンダー側でやってくれるもの」と誤解していますが、ベンダーは「契約と作業指示」に対応する立場で、発注側の意思決定を整理する役割は担いません。
変更管理プロセスを発注側の責任で設計し、フェーズゲートに沿って運用することが、追加開発の品質・コスト・スケジュールを守る要になります。
仕様変更承認フローのフェーズゲート設計
変更管理プロセスのコアは仕様変更承認フローで、6段階のフェーズゲートとして設計します。各段階は次の順に進みます。
- 変更要望の受付（誰からの要望か、緊急度はどうか）
- 影響範囲調査（ベンダーが何営業日で実施するか）
- 変更内容の社内レビュー（プロジェクトオーナー・PM・SMEの承認）
- 見積もり・スケジュールの提示
- 発注側の予算承認と契約変更
- 実装・テスト・リリースまで
各フェーズゲートの通過条件は、契約書に紐づけた書面で定義します。たとえば「影響範囲調査は3営業日以内」「社内レビューは週1回の変更管理会議で議題化」「予算承認は経営層・財務部・IT部の三者承認」といった条件を明文化します。これにより、変更要望が放置されたり、未承認のまま実装が進んだりする事態を防げます。
変更管理会議は週次の定例会議とし、その週に発生した変更要望を棚卸しして優先度を判定し、承認・差し戻し・保留を決めます。議事録は「変更管理台帳」として一元管理し、各変更要望のステータス・影響範囲・費用・スケジュール影響を記録します。この台帳は、後日のスコープ紛争を防ぐ有力な根拠になります。
影響範囲調査チェックリストと議事録テンプレ
影響範囲調査をベンダー任せにすると網羅性にばらつきが出るため、発注側で標準的なチェックリストを準備し、ベンダーに記入させるのが効率的です。
チェックリストの必須項目は次の5つです。
- 修正対象の範囲：テーブル一覧と参照系の影響範囲、画面・帳票一覧
- 連動する処理：バッチ処理と外部システム連携への影響
- API・性能：既存APIの後方互換性と、レスポンスタイム・スループットへの影響
- セキュリティ：変更が既存のセキュリティに与える影響
- 運用手順書：改訂が必要かどうか
議事録テンプレートも標準化し、会議体ごとに「決定事項」「保留事項」「次回までのアクション項目（担当者・期限・成果物）」「変更管理上の影響」を必須項目として記録します。議事録は会議の翌営業日までにドラフトを共有し、3営業日以内にベンダー・発注側の双方で正式版を確定する流れを契約条項に組み込みます。「言った言わない」を完全に防ぐには、議事録の確定タイミングまで明文化することが効果的です。
議事録は電子的に管理し、改訂履歴・閲覧履歴を残せるプラットフォームを使います。Confluence・Notion・SharePointなど編集ログが残る形で管理すれば、後日「改ざんされた」「修正されていない」といった紛争を回避できます。スルガ銀行訴訟で「宴会の箸袋」が証拠提出された教訓から、正式な議事録以外の口頭合意・メモ書きを残さない運用ルールも徹底すべきです。
回帰テストの責任分界と自動化
追加開発で必ず発生するのが回帰テスト（リグレッションテスト）です。回帰テストとは、追加開発によって既存の正常動作箇所に悪影響が出ていないかを確認するプロセスで、追加開発の品質保証の根幹を担います。責任分界は契約段階で明確にし、ベンダー側のテスト範囲、発注側の受入テスト範囲、自動化の運用責任を文書化します。
回帰テストの自動化は、CI/CDパイプラインに組み込むのが現代の標準です。次の種類のツールを組み合わせ、毎回の追加開発で自動実行できる体制を構築します。
- E2Eテストツール：Selenium・Cypress・Playwright
- 単体テストフレームワーク：JUnit・pytest
- API/負荷テストツール：Postman・JMeter
初期構築コストは高くなりますが、3〜5回目の追加開発から累積工数が下回り、長期的に大きなコストメリットを生みます。
テスト資産の所有権も契約条項で明示します。「テストコード・テスト計画書・テストデータの著作権は発注側に帰属」「契約終了時にはテスト資産一式を引き継ぐ義務」を明記すると、ベンダー切替時にゼロから再構築する必要がなくなります。ベンダーロックインを避けるうえでも、重要な防衛策になります。
旧ベンダー拒否時の弁護士相談と第三者仲裁
追加開発を旧ベンダーが拒否する、または引継ぎに非協力的になるケースは少なくありません。「契約上の保守範囲を超える」「現在のリソースでは対応不可」「ソースコードは開示できない」といった理由で、発注側を追い詰めるベンダーも存在します。
発注側にとって、「いつ弁護士に相談すべきか」「どのような第三者仲裁が有効か」を知っておくことは、追加開発を続けるうえで欠かせない知識です。
弁護士相談の最適タイミング
旧ベンダーとの間で追加開発を巡るトラブルが起きた場合、弁護士相談のタイミングを誤ると不利な立場に追い込まれます。相談の最適なタイミングは、次の4つです。
- 書面での請求・作業拒否：追加費用の請求や作業拒否を書面で受けた時
- 契約解除の示唆：契約解除や保守打ち切りをほのめかされた時
- 開示の拒否：ソースコードやドキュメントの開示を断られた時
- 長期の遅延：プロジェクト全体の遅延が3ヶ月を超え、炎上の兆候が出た時
どの場合も、揉めはじめた最初の書面のやり取りの時点が、最も効果的な相談のタイミングです。
相談を遅らせると、時効による請求権の消滅や証拠保全のタイミングを逸するといった不利益を招くうえ、和解可能なタイミングを逃して訴訟費用が膨らみ、取締役の善管注意義務違反を問われることもあります。
スルガ銀行訴訟は、提訴から判決確定まで11年を要し、訴訟費用・人件費・本業への影響を含めると数十億円規模の経営インパクトを与えました。早期相談こそが、最大のリスク管理になります。
相談先は、IT・ソフトウェア法務に専門特化した事務所を選ぶことを推奨し、日弁連の「IT・ソフトウェア専門弁護士」リストやITコーディネータ協会の紹介サービスから候補を探すと効率的です。一般的な企業法務では、技術仕様書・契約書・成果物の評価が困難なケースが多くあります。
経済産業省「情報システム・モデル取引・契約書」を熟知し、システム開発紛争の判例実務を扱った経験のある弁護士であれば、和解交渉から訴訟まで適切な戦略を立案できます。
第三者仲裁機関の活用と費用感
旧ベンダーとの争いを訴訟まで持ち込みたくないときは、第三者仲裁機関が候補になります。挙げられる機関は次の4つです。
- IPA管轄の機関：ソフトウェア紛争解決センター（IT-ADR）
- 商事の機関：日本商事仲裁協会
- 法律家の機関：弁護士会の仲裁センター
- 学会の機関：情報処理学会のIT分野ADR
仲裁機関を活用する利点は、訴訟と比べて短期間（3〜6ヶ月）で解決でき、技術専門家による中立的な判断が得られ、訴訟費用の数分の一で済むことです。IT-ADRの場合、申立費用は紛争額に応じて10万円〜100万円程度で、仲裁手続費用も比較的安価です。IT専門家（技術士・情報処理技術者・ITコーディネータ）が仲裁人として選任されるため、技術的な争点を含む紛争でも公正な判断が期待できます。
「仲裁判断は強制執行力があり判決と同等の効力を持つ」点も、訴訟を回避しつつ実効性を確保できる利点です。
仲裁条項を契約書に事前に組み込んでおくことも有効です。「本契約に関する紛争は、まずソフトウェア紛争解決センターの仲裁手続を経るものとし、仲裁不成立の場合に限り訴訟提起できる」という条項を双方が合意しておけば、紛争発生時に直ちに仲裁プロセスへ移行できます。これは双方にとって長期紛争のリスクを下げる効果があり、ベンダー側にも合意してもらいやすい条項です。
リバースエンジニアリングの選択基準
旧ベンダーがドキュメント開示を拒否した場合や、既存ドキュメントが古く実態と乖離している場合は、リバースエンジニアリングによる仕様復元を選ぶことになります。リバースエンジニアリングとは、稼働中のソースコード・データベース・実際の挙動から仕様書を逆生成する作業です。発注側が自前で行うこともあれば、別ベンダーや専門会社（メインフレーム系・レガシー系の専門事業者）に委託することもあります。
リバースエンジニアリングを選ぶ判断基準は、次の5項目です。3つ以上該当すれば、選択する合理性が高くなります。
- ドキュメントの正確性：既存ドキュメントの正確性が60%未満と推定される
- 情報開示：旧ベンダーからの情報開示が法的・実務的に困難
- 規模：コード行数が5万行以下で、2〜4ヶ月の短期間で復元可能
- 技術スタック：Java/PHP/Python等の標準的な構成で、リバース工程が成立
- 費用：復元費用が新規構築の30%以下で済む見込み
リバースエンジニアリングのコストは、対象システムの規模と複雑性で大きく変わり、コード5万行規模で2〜4ヶ月・1,500〜3,000万円程度、20万行規模で6〜12ヶ月・8,000万円〜2億円程度が目安です。
費用が新規再構築の30〜50%に達する場合は、リバースエンジニアリングではなくフルリプレイスを選ぶ判断もあり得ます。その判断では、リバースで得られる「過去の業務知識・例外処理ロジック」の価値も考慮する必要があります。
リリース後のDay2運用と継続的な追加発注
追加開発は、リリースの時点で終わるわけではなく、Day2（リリース翌日以降の運用フェーズ）こそが本当のスタートです。リリース直後は障害発生率が一時的に上昇し、ユーザーフィードバックが集中する時期です。
Day2運用の設計を発注前に組み込んでおかないと、リリース後に対応リソースが不足し、次の追加発注のサイクルに悪影響が及びます。SLAの定量設計と、継続的な追加発注プロセスの整理が重要です。
SLA設計と監視体制の組み込み
追加開発を継続的に行うシステムでは、SLA（Service Level Agreement：サービス水準合意）を発注前から設計しておく必要があります。SLAには、次の5項目を盛り込みます。
- 可用性（稼働率99.9%以上など）
- 応答時間（画面表示3秒以内など）
- 障害発生時の対応開始時間（重大障害なら30分以内など）
- 障害復旧目標時間（4時間以内など）
- 月次レポートの提出義務
SLAを満たさない場合のペナルティ条項（保守費用の減額・無償対応など）も、明示すると効果的です。
監視体制は、DevOps/SREアプローチで実装するのが現代の標準です。Datadog・New Relic・Prometheus+Grafanaといった監視ツールを導入し、システムの可観測性（オブザーバビリティ）を確保します。ANAのモバイルアプリ事例では、Pivotal Labsを参考に5ヶ月で課題整理・トライアル開発・評価を回し、DevOpsを組織に定着させました。
監視体制が整っていれば、追加開発のリリース時のリスクを早期に検知でき、ロールバック判断も迅速に行えます。エラーバジェットは、目標可用性を達成した上で許容される障害発生時間のことで、99.9%のSLAなら月間43.2分あり、Googleが提唱したSRE手法の核となる考え方です。
エラーバジェットを使い切った場合は新機能追加を停止し品質改善に注力するという運用ルールを置けば、追加開発の暴走を抑え、品質と機能追加のバランスを取れます。このエラーバジェットの考え方も、導入を検討する価値があります。
継続的な追加発注のサイクル設計
追加開発が単発で終わるケースは稀で、業務の変化・ユーザーフィードバック・法改正対応・セキュリティ要件強化により、継続的に追加発注が発生します。この連続性を見越して、「四半期に1回の追加開発リリース」「月次の小規模改修」「年次の大規模機能追加」といった発注サイクルを設計します。サイクルが決まっていると、ベンダー側もリソース計画を立てやすくなり、単価交渉でも発注側に有利に働きます。
発注サイクルに合わせて予算・スコープ・優先順位を継続管理するため、プロダクトバックログ（追加機能・改修要望の優先順位リスト）を発注側で管理し、四半期ごとにベンダーと優先度をすり合わせます。これにより、その時点で最も価値の高い機能から順に追加開発が進み、限られた予算を最大効率で活用できます。デンソーのyuriCargo事例では、この仕組みで5ヶ月で1,700ユーザーを獲得しました。
追加開発を続けるうちに「ここまで投資したのだから今やめられない」というコンコルド効果（サンクコスト効果）が経営層に生まれ、本来は中止すべきプロジェクトを延々と続けてしまうケースが頻発します。中止判断スコア（投資対効果が当初予測の50%を下回ったら見直し、30%を下回ったら中止）を事前に決めておけば、コンコルド効果を回避でき、「やめる勇気」も発注側の重要な意思決定能力になります。
内製化トランスファーへの段階移行
長期的には、追加開発を外部委託だけで続けず、段階的に内製化するロードマップも描くべきです。内製化のメリットは、次の4点です。
- ベンダー単価より自社採用コストが安い
- 業務知識が社内に蓄積し、意思決定が速くなる
- ベンダーロックインリスクが下がる
- 技術選択・採用戦略を自社で決められる
Spotifyの「Squad / Tribe / Chapter / Guild」モデルのように、各開発チームがフレームワーク選択権を持つ組織体制も可能になります。
内製化ロードマップの典型例は、次のような段階移行です。
- 1年目：ベンダー100%で、自社からPM・SMEを派遣して伴走
- 2年目：ベンダーと自社エンジニアがペアプログラミングを行い、自社採用を加速
- 3年目：自社エンジニアが50%になり、ベンダーは要件定義・アーキテクト的役割へ移る
- 4年目以降：自社70%で、ベンダーはモバイル・データ基盤等の特定領域に特化する形が現実的
この段階移行は契約条項に組み込み、ベンダーの引継ぎ協力義務を明文化することが重要です。内製化を進めるには、技術ドキュメント・テストコード・運用手順書を発注側で受け取り、自社エンジニアが読み解ける状態にしておく必要があります。
契約段階では「ドキュメント納品基準（粒度・形式・更新頻度）」「内製化フェーズでのナレッジトランスファー支援工数」を盛り込むことで、この段階移行を実現できます。riplaのように、コンサルティングから開発・内製化支援まで一気通貫で行える企業を伴走パートナーにすると、内製化トランスファーをスムーズに進められます。
まとめ
追加開発の発注は、新規開発と比べて「動いているものを触る」緊張感が常につきまとう、難易度の高いプロジェクトです。本記事で解説したとおり、発注前の準備から契約、変更管理、トラブル時の対応、リリース後の運用までを一貫して設計することが、成功の鍵となります。
発注前は、影響範囲調査、現ベンダー継続か切替かの判断、要件の優先順位仕分けを行い、RFP/SOWでは粒度設計と品質レベルの明示を進めます。契約では、請負か準委任かの形態選択と商法512条に適合した契約条項を整え、変更管理は発注側が主導して設計します。
トラブル時には、弁護士相談や第三者仲裁、リバースエンジニアリングの選択を検討します。リリース後は、Day2運用・SLA設計や継続的な発注・内製化を視野に入れることが大切です。
スルガ銀行訴訟（41.72億円支払命令確定）やプログラム数182→414本増加裁判例が示すように、契約書の細部設計や変更管理の不備は、最終的に数十億円規模の経営インパクトを生み出します。
デンソーのyuriCargoのように、小さく始めて段階的に追加していく形であれば、5ヶ月で1,700ユーザーを獲得する成功事例も生まれます。
発注側がリーダーシップを取り、変更管理プロセス・契約条項・品質レベル基準を主導的に設計することこそが、追加開発を成功に導く最大の要になります。
株式会社riplaは、コンサルティングから開発まで一気通貫で支援できる企業です。発注前準備からRFP/SOW設計、変更管理プロセスの構築、ベンダー選定、内製化トランスファーまで、発注側に寄り添った形でプロジェクト全体を支援します。
IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みを持つriplaへ、追加開発でお悩みの企業はぜひ一度ご相談ください。
▼RFP作成前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・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を創業。