アプリ改修の発注先は、対象範囲と完了条件を決めてから、作業の種類に合う会社と契約を選びます。依頼が曖昧なままだと、想定より広い提案になり、見積もりも比べにくくなります。
課題を具体化して種類を見定めたうえで、発注先の評価から見積もり、リリース後の確認まで順に整理します。
▼全体ガイドの記事
・アプリ改修の完全ガイド
スマホアプリ開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スマホアプリ開発の完全ガイドブック」で詳しく解説しています。
アプリ改修を選定する前に整理すべき自社の課題
発注先を探す前に、困っている業務とアプリ上の対象箇所を結び付けておきます。範囲と規模の認識がそろっていれば、各社に同じ条件を伝えられ、見積もりも比べられます。
対象範囲と完了基準の明文化
「アプリ全体を良くしたい」といった依頼だけでは、会社ごとに作業範囲の解釈が分かれてしまいます。なお、元記事の目安では、改修は数十万円から100万円未満、0.5人月から1人月未満とされています。
そこで、直す画面や機能、目指す状態、関係する既存の機能やデータを書き出し、見積もりの前提をそろえます。利用部門や問い合わせ窓口にも、どの画面で何に困っているかを確認します。現場の状況を一つの依頼文にまとめてから候補探しに進めば、意図と異なる修正による手戻りを抑えられます。
緊急度と発生頻度の切り分け
依頼の時期と繰り返しの有無も整理しておきます。急ぎの不具合対応、予定できるOS対応、継続的な機能追加では、必要な体制がそれぞれ異なります。そのため、単発か継続かを踏まえて、既存アプリを理解している会社と依頼しやすい契約形態を選びます。
アプリ改修の3つの種類
改修内容は、OSの新バージョン対応、不具合修正、軽微な機能追加の3種類に分けて考えます。どの種類に当たるかを定めておけば、予算を組む時期や依頼の方法、確認すべき範囲を決められます。
OS新バージョン対応は、事前に予算化しやすい定期対応
iOS・Androidのメジャーアップデート対応は、元記事では数十万円程度が目安とされています。時期をある程度見通せるため、年間計画に保守契約または別枠の予算として織り込んでおくと、発生時の判断を進めやすくなります。
バグ修正のスポット対応と機能追加の都度企画
不具合修正は発生時期を読みにくいため、必要なときに都度依頼するスポット対応が想定されます。元記事の目安は、月10万〜30万円程度です。
一方で、問い合わせ、プッシュ通知、ログインなどの小規模な機能追加は、10万〜80万円程度、0.3〜1.5人月程度とされています。どちらも、既存の画面やデータとの関係を先に伝えておく必要があります。
新規機能開発との境界の見極め
複数の画面にまたがる仕様変更や、新しい業務フローの設計は、軽微な改修ではなく新規機能開発に当たる場合があります。そこで、影響する画面の数とデータベース変更の有無を整理したうえで、見積もりの際に開発会社へ規模の判断を求めると、費用や納期の前提を確認できます。
発注先を比較するときの評価軸
発注先は、既存アプリの理解と影響範囲の調査を中心に比べます。ほかに、審査を含む進行管理、契約の柔軟性、見積もりの内訳も比べる対象になります。そこで、同じ条件と質問を各社に示せば、回答の具体性で比べられ、比較の軸がそろいます。
既存コードの理解度と影響範囲調査の姿勢
既存コードと設計の理解は、改修箇所以外への影響を見つけるうえで欠かせません。見積もりの時点で、どこを調べ、どの範囲に影響する可能性があるかを説明できるかを確認します。調査の内容を示さず金額だけを出してくる場合は、発注側から見積もりの前提を尋ねます。
開発会社を切り替えると、コードや設計を把握するための調査が必要になることがあります。とくに、引き継ぎ資料が不足している場合は、その分の工数が見積もりに含まれているかを確認します。
初回見積もりの段階で調査範囲を明らかにしておけば、後からの追加作業も把握できます。
スケジュール管理と契約形態の柔軟性
ストア審査の期間は、元記事の目安で通常1〜3日、リジェクト時は数日から数週間とされています。この期間を予定に織り込み、審査状況をどの時点で共有するかも決めておきます。
単発の請負と、月ごとに優先順位を調整できる準委任・ラボ型では、継続的な改修の進めやすさが異なります。今後も依頼が続くなら、利用できる契約形態を比べておきます。
見積もりが「一式」だけだと、追加費用が生じたときに対象範囲を追いにくくなります。そこで、工程ごとの費用と工数を各社に示してもらい、同じ粒度で比べます。工程には、調査や実装、テストに加えて、ストア申請も含めます。
保守契約内での対応か追加開発かの選び分け
新しい発注先を探す前に、現在の保守契約で対象の改修を扱えるかを確認します。契約内で対応できるなら、追加開発として別に依頼する必要がない場合があります。
既存の保守契約の範囲の確認
元記事に記載された保守費用の目安は、初期開発費の年5〜15％程度です。複雑なカスタマイズがある場合は、最大20％程度とされています。
不具合修正や小さな改善は契約に含まれることがある一方で、新機能やデータベース設計の変更は追加の見積もりになる場合があります。そのため、契約書やSLAを読み、今回の依頼がどちらに当たるかを担当者に確認します。
契約書に線引きがない場合は、依頼ごとに保守内か追加開発かをメールなどで確かめ、記録を残します。とくに、口頭のまま作業を重ねると、双方の想定がずれ、更新の時点で費用の認識違いが表面化するおそれがあります。
改修が繰り返し発生する場合の契約形態の見直し
追加開発が何度も起きると、請負契約では都度の見積もりや社内決裁が必要になります。元記事には、準委任・ラボ型の月額例として8,000〜37万5,000円、伴走型で月10万円程度からとあります。
まず、年間の改修頻度を振り返ります。そのうえで、月間の稼働内で優先順位を調整できる契約が合うかを検討します。
既存部品活用とフルスクラッチの選び分け
機能ごとに、既存のライブラリやSaaSを使うか、独自に作るかを検討します。この選択は、費用と仕様の自由度の両方に関わります。
汎用的な機能での既存部品の活用
顧客管理、決済、チャットなど汎用的な機能は、ライブラリ・OSS・SaaS部品を使うことで費用を抑えられる場合があります。元記事の比較目安では、独自開発より40〜60％程度の削減とされています。ただし、採用する前に、標準仕様と必要な動作が合うかを確かめます。
独自業務に直結する部分のフルスクラッチ
独自の商習慣や業務フローが競争力に直結する機能は、既存部品の標準仕様では要件を満たせないことがあります。そのため、その部分は個別に開発し、共通機能には既存部品を使うことで、予算を必要な箇所に配分しやすくなります。
迷ったときは、その機能が他社にも同じ形で提供できる汎用要件か、自社固有の強みを形にする要件かを分けて考えます。前者は既存部品、後者はフルスクラッチを候補にすると、判断の理由を説明できます。
見積もり依頼と検証の進め方
見積もりの精度を上げるには、対象機能の現在と変更後を具体的に伝え、関連機能や検収方法も共有します。そのうえで、依頼条件を文書にまとめて各社に渡せば、同じ前提で提案を受けられます。
見積もり依頼書に書く現状と期待値
依頼書には、改修条件と希望する進め方を分けて記載します。各社へ同じ情報を渡すことが、比較の前提になります。
- 対象アプリのOSとバージョン
- 対象画面・機能の現在の動作と、変更後に期待する動作
- 関連機能、希望納期、契約形態と今後の改修見込み
条件が曖昧なまま依頼すると、会社ごとに前提の異なる見積もりが届き、比較をやり直すことがあります。
また、社内決裁に使う情報も同じ資料にまとめておきます。解消したい業務課題、期待する効果、対応しない場合の懸念を整理しておけば、候補を選んだ理由を説明しやすくなります。
リリース後の検証方法の事前確認
リリース後の確認担当と手順も、依頼前に決めておきます。開発会社のテストに加えて、発注側が主要な操作を確かめる期間を設けておけば、問題が見つかったときに修正や切り戻しを早めに相談できます。
生成AIや新しい外部APIを使う場合は、本番に近いデータでの確認に加えて、外部サービスが停止したときの動作も検証範囲に含めます。
アプリ改修選定前に確認しておきたいポイント
候補を絞ったら、事前検証の必要性、比較条件、合意内容を確認します。表に出にくい前提を契約の前にそろえておくと、着手後の認識違いを防ぎやすくなります。
PoCの要否と新技術の有無
既存データの表示や画面配置の変更など、技術面の不確実性が小さい改修では、事前検証を省ける場合があります。
一方で、生成AIや外部APIなど未使用の技術を組み込む場合は、本番に近いデータで確かめるPoCの要否を、見積もりの際に相談します。
相見積もりの対象範囲のそろえ方
各社に同じ資料と完了条件を渡し、調査や実装、テストに加えてストア申請の費用も分けて提示してもらいます。前提と内訳がそろえば、金額だけでなく作業範囲も比べられます。
小規模な改修における書面での合意
小規模な改修でも、対象範囲と完了条件、納期、追加費用の条件を書面やチャットに残しておきます。口頭のままにすると、完了の認識や追加作業の扱いが食い違うおそれがあります。
まとめ
対象範囲と完了条件を定め、作業をOS対応・不具合修正・機能追加に分類します。そのうえで、この条件を共通の資料にまとめ、各社の調査力や進行方法を比べます。契約や費用の内訳も、同じ基準で見比べます。
保守内か追加開発か、既存部品か個別開発かを見極めると、費用と自由度のバランスを調整しやすくなります。また、riplaは既存部品で要件を満たせない場合、影響範囲を調べて改修設計を支援します。
アプリ改修のパッケージ・クラウド製品一覧では、具体的な選択肢をご覧いただけます。
▼全体ガイドの記事
・アプリ改修の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・スマホアプリ開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。