追加開発の発注/外注/依頼/委託方法について

既存システムへの追加開発を外部ベンダーへ発注する際、「動いているシステムに手を入れる怖さ」「旧ベンダーに足元を見られそうな不安」「契約書のない追加作業に対して費用請求してきたらどうしよう」といった悩みを抱える担当者は少なくありません。新規開発と異なり、追加開発は「動いているもの」を触る緊張感が常につきまといます。発注側が変更管理プロセスを主導し、RFP・SOW・契約条項のレベルで防衛策を組み込むことが、炎上回避と適正コストの実現に直結します。

本記事では、既存システムへの追加発注時のRFP/SOW設計、要件流動時の準委任活用、変更管理プロセスのフェーズゲート設計、商法512条に適合した契約条項、旧ベンダーが拒否した際の弁護士相談タイミングと第三者仲裁、リバースエンジニアリングの選択基準、ベンダーロックイン回避の具体策まで、追加開発の発注実務を網羅的に解説します。スルガ銀行訴訟（41.72億円支払命令）やプログラム数182→414本増加裁判例といった具体事例も交えて、発注側が法的・実務的に取るべきアクションを明確に示します。

▼関連記事
・追加開発完全ガイド

追加開発の発注前準備

追加開発の発注前準備は新規開発以上に重要となります。既に動いている本番システムに手を入れるため、「どこに連動して何が動いているか」を理解しないまま発注すると、デグレード（既存機能の悪化）が必ず発生します。影響範囲調査・要件の優先順位付け・発注先の選定軸という3つの観点で準備を進めることが成功への第一歩です。

追加開発の発注前にまず行うべきは、既存システムの影響範囲調査です。フレシットの増田氏が「敗戦処理」の経験から語る通り、システム変更は「どこを直すか」ではなく「何が連動して動いているか」を理解することから始まります。たとえば顧客マスタに項目を1つ追加するだけでも、参照する画面・帳票・バッチ処理・外部連携APIが10箇所、20箇所と連鎖していくケースが現実には頻発しています。

影響範囲調査の具体的な進め方として、まず既存システムのドキュメント（基本設計書・テーブル定義書・画面遷移図・バッチ一覧）を棚卸しします。ドキュメントが古い場合や存在しない場合は、現行ベンダーから現行版を取り寄せるか、後述するリバースエンジニアリングで補完する必要があります。次に、追加したい機能が触るテーブル・画面・処理を洗い出し、それぞれが参照される側として何件の依存先を持つかを表形式で整理します。

影響範囲が広大すぎる場合は、追加開発のスコープを再検討する判断も必要となります。「あったら良い機能」を切り捨てて「必要な機能」だけに絞り込むことで、回帰テストの工数と費用を半減できるケースもあります。デンソーの「yuriCargo」事例では、コア機能のみで小さくローンチし、5ヶ月で1,700ユーザー獲得後にユーザーフィードバックを反映する形で段階的に機能追加していきました。スモールスタート・段階リリースは、追加開発のリスクを下げる王道アプローチです。

追加開発の発注先として最初に検討すべきは、現行システムを構築した既存ベンダーです。既存ベンダーは内部構造を熟知しているため影響範囲調査の工数が短縮でき、最短ルートでリリースまで到達できる可能性が高くなります。一方で、料金が割高になりがちであったり、保守要員の質が低下していたり、要求した品質基準を満たせないケースも実務では頻繁に発生します。

現ベンダーから別ベンダーへ切り替える判断軸としては、(1)現ベンダーの保守稼働が形骸化しエンジニアの入れ替わりが激しい、(2)見積もりが市場相場の1.5倍以上で交渉余地がない、(3)障害対応のリードタイムが長期化している、(4)新技術への対応力に疑問がある、(5)契約上のソースコード権利・ドキュメント引継ぎ条件で揉めている、といった5つを基準にすると判断しやすくなります。1つでも該当する場合は別ベンダー切替の見積もりを並走させ、比較材料を集めるのが定石です。

別ベンダーへ切り替える場合は、リバースエンジニアリングの工数を見込む必要があります。リバースエンジニアリングとは、既存のソースコード・データベース・稼働中の挙動から仕様書を逆生成する作業です。元のドキュメントが不十分な場合の選択基準としては、(1)コード行数が5万行を超える大規模システムなら現ベンダー継続が無難、(2)月間障害発生率が高く現ベンダーへの不信感が強いなら別ベンダー＋リバースエンジニアリング、(3)中規模で技術スタックが標準的なら別ベンダーでもリバース工数が見積もり総額の15〜25%程度に収まる、という3軸で判断します。

追加開発で最も費用が膨らみ、最も炎上しやすいのが「要望の無制限受け入れ」です。経営層・現場・各部門から上がってくる「あれもやりたい、これも追加して」を全て取り込むと、初期見積もりの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に加えて「既存システムの前提条件」を厚く記載する必要があります。具体的には、(1)現行システムのアーキテクチャ図と技術スタック、(2)現行ベンダーから取り寄せた基本設計書・データベース定義書、(3)現行の月間トランザクション量・ピーク負荷データ、(4)既存システムが連携する外部システムの一覧と接続仕様、(5)現行の障害発生履歴と対応事例、を必須項目として開示します。

追加開発の要件記述では、「機能要件」と「非機能要件」を明確に分けて記述します。機能要件は何を作るか（画面・処理・帳票）、非機能要件は性能・可用性・セキュリティ・運用・保守の品質基準です。追加開発では特に「既存機能の品質を悪化させないこと」を非機能要件として明文化する必要があります。具体的には「レスポンスタイム劣化が10%以内」「既存バッチの実行時間が現行+15%以内」「既存APIの後方互換性100%維持」といった定量基準で示します。

RFPには回帰テストの責任分界も明記します。「ベンダーが実施する回帰テストの範囲」「発注側が受入テストで担当する範囲」「テスト自動化の有無と継続運用責任」を契約前に合意しておくことで、リリース後の不具合発生時の責任の所在が明確になります。回帰テスト範囲が曖昧だと、ベンダーは「これは触っていない箇所だから影響範囲外」、発注側は「同一システムなので品質保証範囲内」と主張が衝突し、追加費用負担をめぐる紛争に発展します。

SOWは契約書に紐づく作業指示書で、「何を、いつまでに、どの品質で納品するか」を具体的に記述する文書です。追加開発のSOWでは、フェーズごとの成果物リスト・受入基準・検収条件を明示する必要があります。たとえば設計フェーズなら「修正対象機能の詳細設計書」「影響範囲調査報告書」「回帰テスト計画書」を成果物として列挙し、それぞれのレビュー・承認手順を記載します。

SOWの粒度は、成果物の章立てレベルまで踏み込んで定義することを推奨します。「設計書1冊」では曖昧すぎるため、「画面設計（修正画面5本×3ページ）」「データベース変更設計（追加3テーブル・修正5テーブル）」「外部I/F仕様変更箇所一覧」のようにページ数・項目数まで指定します。これにより、後日「成果物が足りない」「これも入っていると思っていた」というスコープ紛争を防げます。

検収条件もSOWで明確化します。検収条件とは「成果物が合格と判定される基準」で、機能要件の確認方法・非機能要件の測定方法・受入テストの合格率（たとえば「致命的不具合ゼロ、重要不具合5件以内、軽微不具合10件以内」）といった形で定量化します。検収条件が不明確だと、ベンダーは「納品済み」と主張し、発注側は「合格していない」と支払いを保留するという紛争が発生しやすくなります。

追加開発の見積もりは「機能数 × 品質レベル × 人月単価」で算出され、人件費が約8割を占めます。このうち品質レベルの選択が見積額を最も大きく左右します。品質レベル低なら通常の50〜70%、中なら100〜150%、高なら200〜400%という変動幅があり、同じ機能でも品質要件次第で4倍以上の差が生まれます。発注側が品質レベルを明示的に指定しないと、ベンダーは保守的に高品質を仮定して見積もりを膨らませがちです。

品質レベルの判断軸として、(1)業務クリティカル度（停止が経営に直撃するか）、(2)外部公開範囲（社内のみか顧客向けか）、(3)取扱データの機密性、(4)法規制（個人情報保護・財務情報・医療情報）、(5)可用性要件（24時間365日かビジネスアワーのみか）、の5項目で評価します。たとえば社内の管理画面の機能追加なら「中」、顧客が直接触れる決済機能の追加なら「高」、内部の社員向けレポート機能なら「低〜中」、というように振り分けます。

非機能要件は具体的な数値で示します。「可用性99.9% vs 99.99%」という違いは、停止許容時間に換算すると年間8.76時間 vs 52.6分で、実装コストも数倍違ってきます。レスポンスタイムも「3秒以内」と「1秒以内」では負荷試験・チューニング工数が2〜3倍変わります。これらの非機能要件をRFPで明示し、品質レベルを業務インパクトから逆算して指定することで、見積もりの過剰品質を防ぎ、適正コストでの発注が可能になります。

契約形態の選択と商法512条適合契約

追加開発で最も揉めるのが契約形態と追加費用の取り扱いです。スルガ銀行と日本IBMの訴訟では、初期費用95億円が合意書89億円となり、開発中断時に追加127億円が要求され、最終的に高裁で日本IBMに41億7210万円の支払命令が確定しました。訴訟記録は72冊に及び、宴会の箸袋に手書きされた金額交渉メモまでが証拠提出される泥沼となりました。発注前の契約設計がいかに重要かを物語る象徴的事例です。

追加開発の契約形態は「請負契約」と「準委任契約」のどちらを選ぶかが最大の論点です。請負契約は「成果物の完成」に対して支払う形態で、機能仕様・品質基準を契約時に確定できる場合に向きます。一方で要件が流動的だと追加見積もり・契約変更が頻発し、結果的に契約管理コストが膨らみます。一方の準委任契約は「稼働時間」に対して支払う形態で、要件が流動するアジャイル型の追加開発に適しています。

使い分けの基準として、(1)要件が確定済みで短期間のスコープ固定型なら請負、(2)要件が流動的で2〜3ヶ月以上の継続的な追加開発なら準委任、(3)初期は要件定義を準委任で実施し、設計以降を請負に切り替えるハイブリッド型、の3パターンが実務的によく採用されます。準委任型でのアジャイル開発は「完成形を固定しない」契約設計であり、デンソーのyuriCargoや国内の多くのスタートアップが採用する形態です。

準委任契約を選ぶ場合の注意点として、稼働時間の上限・下限を明示し、ベンダーの工数管理を可視化させる仕組みを契約条項に組み込む必要があります。具体的には「月間稼働時間レンジ140〜180時間」「日次の作業報告と月次の工数集計報告」「想定稼働を超える場合の事前承認プロセス」を契約書に明記します。これを怠ると、準委任契約が「稼働時間無制限の追加請求装置」になりかねません。

追加開発で頻発するのが「契約書にない追加作業に対して、後日ベンダーから費用請求される」というケースです。発注側は「契約していないから払わない」と主張したくなりますが、商法512条（商人がその営業の範囲内において他人のために行為をしたときは、相当な報酬を請求できる）により、契約書がなくても費用請求が法的に成立するケースがあります。判例では、(1)別途費用発生を文書で明示しており、(2)システム会社が仕様変更取決めを破っていない、という2要件を満たせば「相当な報酬請求」が認容されています。

具体的な裁判例として、プログラム数が当初見積もりの182本から実装時に414本へ増加し、追加費用を巡って争われた事案があります。この裁判では、見積書に「工数大幅変動時は別途相談」と記載されており、契約書には追加条項が明記されていませんでしたが、商法512条を根拠に追加費用の請求が認容されました。発注側にとっては「契約書にない＝払わなくて良い」という認識が通用しないことを示す重要な判例です。

商法512条に適合した契約設計とは、発注側の防衛の観点では「追加作業発生時の事前承認プロセスを契約条項に組み込む」ことを意味します。具体的には、(1)ベンダーが追加作業を発見した時点で発注側に書面通知する義務、(2)発注側の事前承認なき追加作業の費用負担はベンダー側に帰属することを明記、(3)追加作業の見積もり・スケジュール・影響範囲を承認フォーマットに沿って提示する義務、を契約書に盛り込みます。これにより、商法512条による「相当な報酬請求」の余地を限定的にできます。

追加開発を続けるうちに、システムの内部構造を熟知するベンダーが事実上の唯一の発注先となり、価格交渉力を完全に失う「ベンダーロックイン」が頻発します。これを契約段階で防ぐためには、(1)ソースコードの所有権・利用権が発注側に帰属することを明記、(2)第三者が引き継げる水準のドキュメント納品義務、(3)技術スタックの標準化（コンテナ・標準API・OSSベース）、(4)契約終了時の引継ぎ協力義務と引継ぎ期間中の人件費単価、を契約条項に組み込みます。

ソースコードの権利帰属は特に重要です。デフォルトでは多くのベンダー契約書がソースコード著作権をベンダー側に留保しており、発注側は「使用権のみ」しか持たないケースが大半です。これを発注側帰属に変更交渉するか、最低でも「ソースコードの第三者開示権」「ソースコード改変権」を確保しないと、別ベンダーへの切替が事実上不可能になります。交渉時には、「これはripla社の知的財産にも関わるため、契約締結前に明文化したい」と直接的に伝えるのが効果的です。

技術スタックの標準化も契約条項として有効です。「特定ベンダー固有のフレームワーク・ライブラリの使用は事前承認制」「コンテナ（Docker / Kubernetes）ベースの実装を原則とする」「データベースは標準SQL準拠とし、独自拡張機能の利用は事前承認制」といった条項により、別ベンダーへ移行する際の技術的障壁を下げられます。これらは将来の追加開発を別ベンダーに発注する選択肢を残すための戦略的な防衛策となります。

変更管理プロセスの設計と発注側責任

追加開発の炎上を防ぐ最大の防御策が、発注側主導の変更管理プロセスです。多くの企業が「変更管理はベンダー側でやってくれるもの」と誤解していますが、ベンダーは「契約と作業指示」に対応する立場であり、発注側の意思決定を整流化する役割は担いません。変更管理プロセスを発注側の責任で設計し、フェーズゲートに沿って運用することが、追加開発の品質・コスト・スケジュールを守る要となります。

変更管理プロセスのコアは、仕様変更承認フローです。具体的には、(1)変更要望の受付（誰からの要望か、緊急度はどうか）、(2)影響範囲調査（ベンダーが何営業日で実施するか）、(3)変更内容の社内レビュー（プロジェクトオーナー・PM・SMEの承認）、(4)見積もり・スケジュールの提示、(5)発注側の予算承認と契約変更、(6)実装・テスト・リリース、という6段階のフェーズゲートを設計します。

各フェーズゲートの通過条件を契約書に紐づけた書面で定義します。たとえば「影響範囲調査は3営業日以内」「社内レビューは週1回の変更管理会議で議題化」「予算承認は経営層・財務部・IT部の三者承認」といった通過条件を明文化することで、変更要望が放置されたり、逆に未承認のまま実装が進行したりする事態を防げます。

変更管理会議体の設計も重要です。週次の定例会議でその週に発生した変更要望を棚卸しし、優先度を判定して承認・差戻し・保留を判定します。会議の議事録は「変更管理台帳」として一元管理し、各変更要望のステータス・影響範囲・費用・スケジュール影響を記録します。この台帳が、後日のスコープ紛争を防ぐ最強のエビデンスとなります。

影響範囲調査をベンダー任せにすると、調査の網羅性に大きなばらつきが発生します。発注側で標準的なチェックリストを準備し、ベンダーに記入させる運用が効率的です。チェックリスト項目としては、(1)修正対象のテーブル一覧と参照系の影響範囲、(2)修正対象の画面・帳票一覧、(3)バッチ処理への影響、(4)外部システム連携への影響、(5)既存APIの後方互換性、(6)性能への影響（レスポンスタイム・スループット）、(7)セキュリティへの影響、(8)運用手順書の改訂要否、の8項目を必須にします。

議事録テンプレートも標準化します。会議体ごとに「決定事項」「保留事項」「次回までのアクション項目（担当者・期限・成果物）」「変更管理上の影響」を必須項目として記録します。議事録は会議の翌営業日までにドラフトを共有し、3営業日以内にベンダー・発注側の双方で正式版を確定するプロセスを契約条項に組み込みます。「言った言わない」を完全に防ぐためには、議事録の確定タイミングまで明文化することが効果的です。

議事録の管理は電子的に行い、改訂履歴・閲覧履歴を残せるプラットフォームを使用します。Confluence・Notion・SharePointといったコラボレーションツール上で、編集ログが残る形で管理することで、後日「議事録が改ざんされた」「修正されていない」といった紛争を回避できます。スルガ銀行訴訟で「宴会の箸袋」が証拠提出された教訓を踏まえ、正式な議事録以外の口頭合意・メモ書きを残さない運用ルールも徹底すべきです。

追加開発で必ず発生するのが回帰テスト（リグレッションテスト）です。回帰テストとは、追加開発によって既存の正常動作箇所に悪影響が出ていないかを確認するプロセスで、追加開発の品質保証の根幹を担います。回帰テストの責任分界は契約段階で明確化し、ベンダー側のテスト範囲・発注側の受入テスト範囲・自動化の運用責任を文書化します。

回帰テストの自動化はCI/CDパイプラインに組み込むのが現代の標準です。Selenium・Cypress・PlaywrightといったE2Eテストツール、JUnit・pytestといった単体テストフレームワーク、Postman・JMeterといったAPI/負荷テストツールを組み合わせ、毎回の追加開発で自動実行できる体制を構築します。自動化の初期構築コストは高くなりますが、3〜5回目の追加開発から累積工数が下回り、長期的に大きなコストメリットを生みます。

回帰テストの自動化資産の所有権も契約条項で明示します。「テストコード・テスト計画書・テストデータの著作権は発注側に帰属」「契約終了時にはテスト資産一式を引き継ぐ義務」を明記することで、ベンダー切替時にゼロから再構築する必要がなくなります。これもベンダーロックイン回避の重要な防衛策です。

旧ベンダー拒否時の弁護士相談と第三者仲裁

追加開発を旧ベンダーが拒否する、または引継ぎに非協力的になるケースは少なくありません。「契約上の保守範囲を超える」「現在のリソースでは対応不可」「ソースコードは開示できない」といった理由で発注側を追い詰めるベンダーも存在します。このような事態に直面した時に「いつ弁護士に相談すべきか」「どのような第三者仲裁が有効か」を知っておくことは、追加開発を続ける上での必須知識となります。

旧ベンダーとの間で追加開発を巡るトラブルが発生した場合、弁護士相談のタイミングを誤ると不利な立場に追い込まれます。相談の最適タイミングは、(1)書面で追加費用の請求や作業拒否を受けた時、(2)契約解除や保守打ち切りを示唆された時、(3)ソースコード・ドキュメントの開示を拒否された時、(4)プロジェクト全体の遅延が3ヶ月を超え炎上の兆候が出た時、の4つです。いずれも「揉めはじめた最初の書面のやり取りの時点」が、弁護士相談の最も効果的なタイミングとなります。

弁護士相談を遅らせるリスクとして、(1)時効による請求権の消滅、(2)証拠保全のタイミングを逸する、(3)和解可能なタイミングを逃して訴訟費用が膨らむ、(4)取締役の善管注意義務違反を問われる、といった複合的な不利益があります。スルガ銀行訴訟は提訴から判決確定まで11年を要し、訴訟費用・人件費・本業への影響を含めると数十億円規模の経営インパクトを与えました。早期相談こそが最大のリスク管理となります。

相談先の弁護士は、IT・ソフトウェア法務に専門特化した事務所を選ぶことを推奨します。一般的な企業法務の弁護士では、技術仕様書・契約書・成果物の評価が困難なケースが多くあります。経済産業省「情報システム・モデル取引・契約書」を熟知し、過去にシステム開発紛争の判例実務を扱った経験のある弁護士であれば、和解交渉から訴訟まで適切な戦略を立案できます。日弁連の「IT・ソフトウェア専門弁護士」リストや、ITコーディネータ協会の紹介サービスから候補を探すと効率的です。

訴訟に至る前の選択肢として、第三者仲裁機関の活用があります。代表的な機関として、(1)ソフトウェア紛争解決センター（IT-ADR、IPA管轄）、(2)日本商事仲裁協会、(3)弁護士会の仲裁センター、(4)情報処理学会のIT分野ADR、などがあります。仲裁機関を活用する利点は、訴訟と比べて短期間（3〜6ヶ月）で解決でき、技術専門家による中立的な判断が得られ、訴訟費用の数分の一で済むことです。

ソフトウェア紛争解決センター（IT-ADR）の場合、申立費用は紛争額に応じて10万円〜100万円程度、仲裁手続費用も比較的安価です。IT専門家（技術士・情報処理技術者・ITコーディネータ）が仲裁人として選任されるため、技術的な争点を含む紛争でも公正な判断が期待できます。「仲裁判断は強制執行力があり判決と同等の効力を持つ」点も、訴訟を回避しつつ実効性を確保できる利点です。

仲裁条項を契約書に事前に組み込んでおくことも有効です。「本契約に関する紛争は、まずソフトウェア紛争解決センターの仲裁手続を経るものとし、仲裁不成立の場合に限り訴訟提起できる」という条項を契約段階で合意しておけば、紛争発生時に直ちに仲裁プロセスへ移行できます。これは双方にとって長期紛争のリスクを下げる効果があり、ベンダー側にも合意してもらいやすい条項です。

旧ベンダーがドキュメント開示を拒否した場合、または既存ドキュメントが古く実態と乖離している場合は、リバースエンジニアリングによる仕様復元を選択することになります。リバースエンジニアリングとは、稼働中のソースコード・データベース・実際の挙動から仕様書を逆生成する作業です。発注側が自前で行うこともあれば、別ベンダーや専門会社（メインフレーム系・レガシー系の専門事業者）に委託することもあります。

リバースエンジニアリングを選択すべき判断基準として、(1)既存ドキュメントの正確性が60%未満と推定される、(2)旧ベンダーからの情報開示が法的・実務的に困難、(3)コード行数が5万行以下で短期間（2〜4ヶ月）で復元可能、(4)技術スタックが標準的（Java/PHP/Python等）で専門知識のリバース工程が成立、(5)復元の費用が新規構築の30%以下で済む見込み、の5項目で評価します。3つ以上該当すればリバースエンジニアリングを選択する合理性が高くなります。

リバースエンジニアリングのコストは、対象システムの規模と複雑性で大きく変動します。一般的には、コード5万行規模で2〜4ヶ月・1,500〜3,000万円程度、20万行規模で6〜12ヶ月・8,000万円〜2億円程度が目安となります。費用が新規再構築の30〜50%に達する場合は、リバースエンジニアリングではなくフルリプレイスを選択する判断もあり得ます。判断時には、リバースで得られる「過去の業務知識・例外処理ロジック」の価値も考慮する必要があります。

リリース後のDay2運用と継続的な追加発注

追加開発はリリース時点でゴールではなく、Day2（リリース翌日以降の運用フェーズ）こそが本当のスタートとなります。リリース直後は障害発生率が一時的に上昇し、ユーザーフィードバックが集中する時期です。Day2運用の設計を発注前に組み込んでおかないと、リリース後に対応リソースが不足し、次の追加発注のサイクルに悪影響を及ぼします。SLAの定量設計と継続的な追加発注プロセスの整流化が重要です。

追加開発を継続的に行うシステムでは、SLA（Service Level Agreement：サービス水準合意）を発注前から設計しておく必要があります。SLAには、(1)可用性（稼働率99.9%以上など）、(2)応答時間（画面表示3秒以内など）、(3)障害発生時の対応開始時間（重大障害なら30分以内など）、(4)障害復旧目標時間（4時間以内など）、(5)月次レポートの提出義務、を盛り込みます。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%を下回ったら中止）を事前に決めておくことで、コンコルド効果を回避できます。「やめる勇気」も発注側の重要な意思決定能力です。

長期的な視点では、追加開発を100%外部委託し続けるのではなく、段階的に内製化していくロードマップを描くことも検討すべきです。内製化のメリットは、(1)ベンダー単価より自社採用コストが安い、(2)業務知識が社内に蓄積し意思決定が速くなる、(3)ベンダーロックインリスクが下がる、(4)技術選択・採用戦略を自社で決められる、の4点です。Spotifyの「Squad / Tribe / Chapter / Guild」モデルのように、各開発チームがフレームワーク選択権を持つ組織体制も可能になります。

内製化ロードマップの典型例として、(1)初期1年目はベンダー100%、自社からPM・SMEを派遣して伴走、(2)2年目はベンダーと自社エンジニアのペアプログラミング、自社採用を加速、(3)3年目に自社エンジニアが50%、ベンダーは要件定義・アーキテクト的役割に移行、(4)4年目以降は自社70%、ベンダーは特定領域（モバイル・データ基盤等）に特化、という段階移行が現実的です。この移行を契約条項に組み込み、ベンダーの引継ぎ協力義務を明文化することが重要です。

内製化を進めるためには、技術ドキュメント・テストコード・運用手順書を発注側で受け取り、自社エンジニアが読み解ける状態にしておく必要があります。これも契約段階で、「ドキュメント納品基準（粒度・形式・更新頻度）」「内製化フェーズでのナレッジトランスファー支援工数」を盛り込むことで実現できます。riplaのようなコンサルティングから開発・内製化支援まで一気通貫で行える企業を伴走パートナーとして活用すると、内製化トランスファーをスムーズに進められます。

まとめ

追加開発の発注は、新規開発と比べて「動いているものを触る」緊張感が常につきまとう、難易度の高いプロジェクトです。本記事で解説した通り、発注前準備としての影響範囲調査・現ベンダー継続か切替かの判断・要件の優先順位仕分け、RFP/SOWの粒度設計と品質レベルの明示、請負か準委任かの契約形態選択と商法512条適合契約、変更管理プロセスの発注側主導設計、旧ベンダー拒否時の弁護士相談タイミングと第三者仲裁、リバースエンジニアリングの選択基準、Day2運用とSLA設計、継続的な追加発注サイクルと内製化トランスファーといった複合的な観点を、発注前から契約・運用フェーズまで一貫して設計することが成功の鍵となります。

スルガ銀行訴訟（41.72億円支払命令確定）やプログラム数182→414本増加裁判例が示すように、契約書の細部設計や変更管理プロセスの不備は、最終的に数十億円規模の経営インパクトを生み出します。一方で、デンソーのyuriCargoのように小さく始めて段階的に追加していく形であれば、5ヶ月で1,700ユーザーを獲得する成功事例も生まれます。発注側がリーダーシップを取り、変更管理プロセス・契約条項・品質レベル基準を主導的に設計することこそが、追加開発を成功に導く最大の武器となります。

株式会社riplaは、コンサルティングから開発まで一気通貫で支援できる企業として、追加開発の発注前準備・RFP/SOW設計・変更管理プロセスの構築・ベンダー選定・内製化トランスファーまで、発注側に寄り添った形でプロジェクト全体を支援します。IT事業会社として社内DXを推進してきた経験を活かし、ビジネスへの成果創出とシステムの定着支援に強みを持つriplaへ、追加開発でお悩みの企業はぜひ一度ご相談ください。

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