LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてアプリ開発・バージョンアップを受託

バージョンアップ外注とは｜運用保守と異なるプロジェクト型発注

アプリのバージョンアップ外注とは、既存スマートフォンアプリへの機能追加・画面刷新・アーキテクチャ改修など大型アップデートの開発工程を、要件定義から納品・ストアリリースまでを含むプロジェクト単位で外部の開発会社に委託する発注形態を指します。新規アプリの受託開発と同じく「単発プロジェクト型」の契約であり、継続的な運用保守契約とは構造が異なります。

運用保守との違い——月額継続と単発一括の費用構造比較

アプリの外注には「継続型（運用保守）」と「プロジェクト型（バージョンアップ）」という2つの形態があります。両者は目的も費用構造も異なります。

継続型の運用保守は、サーバー監視・障害対応・OS定期更新・問い合わせ対応などを月額固定費で受託する形式です。一方、本記事が扱うプロジェクト型のバージョンアップ外注は、「新機能Xを追加したい」「画面をフルリニューアルしたい」という明確なゴールを持つ開発プロジェクトであり、要件定義から納品まで期間を区切って発注します。

外注が有効なバージョンアップの3類型

プロジェクト型の外注が特に有効なのは、次の3つの類型です。

①機能追加（機能開発型）は、既存アプリに新しい機能（決済機能・チャット機能・ポイントシステムなど）を追加するケースです。既存コードベースへの組み込みと新規開発の両方が必要なため、仕様の整合確認が重要になります。

②UI/UX刷新（リニューアル型）は、ユーザー体験の大幅な改善を目的に画面設計から作り直すケースです。デザイナーと開発者の連携が不可欠で、工程管理の難易度が上がります。

③技術的負債の解消（リファクタリング型）は、古いフレームワークやAPIバージョンへの依存を解消しながら内部構造を刷新するケースです。外部から見える動作を変えずに内部を刷新するため、テスト工数が特に大きくなる傾向があります。

費用の目安と決まり方｜工数×単価で見積もる仕組み

バージョンアップの外注費用は、基本的に「開発工数（人日・人月）×エンジニア単価」で算定されます。新規開発費用と同じ計算構造ですが、既存コードの読解・影響範囲調査・既存テストへの対応といった追加工数が発生する点が特徴です。

機能規模別のおおよその費用レンジ

費用の目安は機能の複雑さと規模によって大きく変動します。以下は実務的な参考レンジですが、既存コードの状態やOS対応範囲によって変動するため、複数社から見積りを取得することを推奨します。

※上記は市場参考値であり、一次資料による公的統計ではありません。実際の費用は既存コードの品質・OS対応範囲・テスト要件・開発会社の規模によって大きく異なります。複数社へのRFP提示後に見積りを取得することを推奨します。

見積りが高くなる4つの要因

バージョンアップの見積りが想定より高くなりやすい要因として、次の4点が挙げられます。

• 既存コードの可読性が低い：ドキュメントが不整備なコードベースは、影響範囲調査・読解の工数が上乗せされます。
• iOS・Android両OS対応：ネイティブアプリの場合、両プラットフォームへの対応は実質2プロジェクト分の工数になります。
• 外部API・バックエンド連携：決済ゲートウェイや認証基盤との連携は、仕様確認・テストケースが増え工数が膨らみます。
• 品質保証（QA）工程の比率：既存機能の回帰テストが必要なため、新規開発より品質保証の工数が相対的に大きくなります。

外注プロジェクトの5ステップ｜要件定義〜ストアリリース

バージョンアップを外注する際は、要件定義からリリースまでを5つのステップで進めることが一般的です。特に前半の「要件整理」と「RFP作成」の精度がプロジェクト全体の成否を左右します。

ステップ1：現状把握と要件整理——「できること」「したいこと」の棚卸し

外注前に自社で行うべき最初の作業は、現状のアプリの「できること（現機能）」と「したいこと（追加・改修内容）」の棚卸しです。この段階で明確にしておくべき項目は次のとおりです。

• 現行アプリのソースコード管理状況（リポジトリの有無・ドキュメントの整備度）
• 追加・改修したい機能のリストと優先順位
• 対応OSとバージョン（iOS/Android、最低対応バージョン）
• リリース希望時期と予算の上限

特にソースコードの状態は、外注費用に直接影響します。前任の開発会社が保有したままでドキュメントがない場合、コードの読解工数が大幅に加算されることがあります。外注先に渡す前にソースコードとドキュメントを回収・整理しておくことが、費用を抑えるうえで重要です。

ステップ2：RFP作成と相見積り——発注失敗を防ぐ提案依頼書の骨子

RFP（Request for Proposal：提案依頼書）とは、発注内容・要件・予算・スケジュール・選定基準をまとめた文書です。RFPを作成せずに口頭・メールだけで発注すると、開発会社との認識ズレが生じ、スコープ肥大や仕様変更の連鎖につながります。

バージョンアップ外注のRFPに含めるべき骨子は以下のとおりです。

• 現状のアプリ概要：機能一覧・技術スタック・対応OS・ユーザー規模
• 追加・改修する機能の要件：機能要件（何ができるか）と非機能要件（パフォーマンス・セキュリティ）の両方
• 成果物の定義：ソースコード・設計書・テスト報告書の納品範囲
• スケジュール：希望リリース日・マイルストーン
• 予算上限：提示できる場合は記載。提示が難しい場合は「見積り結果で判断」と明記
• 選定基準：技術力・実績・価格のウェイト

見積りは3社以上から取得することを推奨します。同一のRFPを提示することで、価格・体制・アプローチの差が比較しやすくなります。

ステップ3：開発会社の選定基準——技術スタック・実績・元請体制の確認

開発会社の選定では、価格だけでなく「既存アプリに使われている技術スタックへの対応力」を確認することが重要です。同じiOSアプリでも、Swift / Objective-C / React Native / Flutter など技術的な前提が異なり、使用言語が一致しない場合は技術移行コストが発生します。

確認すべきポイントは3点です。第一に、類似規模のバージョンアップ・機能追加の実績があるかどうか。第二に、元請（プライムベンダー）として受託しているか——下請け構造では仕様伝達のロスが生じやすいため、発注先が一次受けかどうかを確認します。第三に、ストアリリース対応の経験があるか——Apple App Store・Google Play ストアの審査対応には審査ガイドライン対応の実務知識が必要です。

ステップ4：開発・テスト段階の管理ポイント

開発が始まったら、週次・隔週での定期レビューを設定します。バージョンアップ外注での特有のリスクは、「既存機能への意図しない影響（デグレ（品質劣化））」です。新機能の開発と並行して、既存機能の動作確認（回帰テスト）がきちんと行われているかをマイルストーンごとに確認してください。

また、テスト環境（開発環境・ステージング環境・本番環境）の分離と、本番リリース前の最終確認フローを事前に合意しておくことが、リリース直前トラブルの防止につながります。

ステップ5：ストアリリースと引き渡し

iOS App Store・Google Play Store へのリリースは、それぞれ審査ガイドラインへの対応が必要です。ストアの審査期間は目安として数日〜1週間程度かかることがあります（時期やアプリ内容により変動します）。リリース希望日の1〜2週間前には審査申請できるよう逆算してスケジュールを組みます。

リリース後は、ソースコード・設計書・テスト仕様書の納品と、開発会社から自社への成果物引き渡し（引き継ぎ）を漏れなく行います。引き渡し後の運用保守体制（継続依頼か、別ベンダーへ切り替えか）もこの段階で確定させます。

内製vs外注の判断軸｜3つの観点で比較

機能追加・バージョンアップを自社内製でやるか外注するかは、「スピード」「コスト」「スキル」の3軸で判断します。

外注が向くケース・内製が向くケース

外注が向くのは、「定期的ではなく数年に1度の大型リニューアルが必要」「社内にモバイル専任エンジニアがいない」「既存コードを刷新しながら機能を大幅に拡張したい」といったケースです。

内製が向くのは、「小規模なUI修正や文言変更を頻繁に行う」「アプリが事業の中核でノウハウを社内に蓄積したい」「自社でエンジニアチームをすでに抱えており稼働が確保できる」というケースです。

両者を組み合わせた「ハイブリッド型」——大型バージョンアップは外注、日常的な小修正は内製——という運用も現実的な選択肢です。

よくある失敗パターンと回避策

バージョンアップ外注の失敗は、発注者側の準備不足と、受注者への情報伝達の不備から発生するケースが目立ちます。特に注意すべき失敗パターンを3つ整理します。

失敗1：要件定義が曖昧でスコープが際限なく広がる

発注時に「機能Xを追加してほしい」という大まかな依頼だけで開発を開始すると、開発が進むにつれて「あの画面も直してほしい」「この仕様では不十分だった」という追加要求が続き、スコープが際限なく広がります。

このような状況では、開発会社は追加費用を請求するか、品質を妥協して納期を優先するかの選択を迫られます。発注者としては、RFP段階で「今回のプロジェクトに含まれないもの」を明示的にリスト化する——いわゆる「スコープ外明示」——が有効な予防策です。

失敗2：既存コードの理解不足から手戻り多発

バージョンアップ特有のリスクとして、「既存コードの品質が想定より低く、調査・リファクタリング工数が見積り後に発覚する」というケースがあります。特に、前任の開発会社が引き渡しを行わず、コードの全容が把握できていない状態で新たな外注先に発注するとこの問題が起きやすくなります。

対策として、発注前に現行コードのソースレビュー（技術調査）を依頼する「フィジビリティスタディ」や「簡易調査フェーズ」を設けることが有効です。追加の調査費用はかかりますが、本開発での大幅な手戻りを防ぐ保険として機能します。

失敗3：運用保守の引き継ぎを考慮しない

バージョンアップ完了後の「誰が運用するか」を発注前に決めておかないと、リリース直後に保守体制が宙に浮きます。開発を担当した会社がそのまま運用を引き受けるケース、別のベンダーに移管するケース、内製に切り替えるケースなど、複数の選択肢があります。

いずれの場合も、設計書・テスト仕様書・API仕様書などのドキュメントが整備されていないと、次のベンダーへの引き継ぎが困難になります。成果物の定義に「ドキュメント納品」を含めておくことが、長期的なメンテナンスコストを抑えるうえで重要です。

発注先の選び方｜元請（プライムベンダー）に依頼すべき理由

外注先を選ぶ際、発注者が直接話す会社が「一次受け（元請）」として開発を担うのか、「下請け・孫請け」に業務を流す中間会社なのかを確認することが重要です。

一次受け（元請）と二次受け以降の違い

下請け構造では、発注者の要件が中間会社を経由して開発担当者に伝わるため、仕様の伝達ロスが発生しやすくなります。発注者が「機能Aと機能BをAPIで連携させたい」と伝えても、中間会社を経由するうちに「機能Aを追加」と短縮されて伝わることがあります。バージョンアップのように既存システムへの影響を慎重に管理する必要がある開発では、このロスが品質劣化の原因になります。

元請（プライムベンダー）に直接発注することで、要件の伝達ルートが短縮され、問題発生時の責任の所在も明確になります。契約前に「自社で開発するか、再委託するか」を事前に確認することを推奨します。

LASSICの受託体制

LASSICは元請（プライムベンダー）として、要件定義からストアリリースまでを一気通貫で対応します。既存コードの調査・読解から始め、技術的負債の洗い出しと改修範囲の合意形成を丁寧に行う体制を整えています。詳しくはIT事業部のサービス紹介をご覧ください。

まとめ｜バージョンアップ外注を成功させる3つの判断軸

本稿では、アプリのバージョンアップをプロジェクト型で外注する方法について、費用構造・5ステップ・失敗回避の観点から整理しました。要点を3つに集約すると次のとおりです。

第一に、バージョンアップ外注は「運用保守の月額継続」と費用構造が異なるプロジェクト型発注です。継続型の運用保守と混同すると予算設計が狂います。明確なゴール（何をどこまで改修するか）を決めてから発注することが前提です。

第二に、RFPの精度がプロジェクト成否を左右します。スコープ外の明示・非機能要件の記載・成果物定義を含む提案依頼書を作成し、3社以上から比較見積りを取得することで、発注後の認識ズレを防げます。

第三に、元請（プライムベンダー）への直接発注が品質リスクを下げます。下請け構造による仕様伝達ロスを避け、問題発生時の窓口を一本化することで、既存機能へのデグレ（品質劣化）を管理しやすくなります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：IPA 独立行政法人情報処理推進機構「DX動向2025」（2025年公表）

Tweet