アプリ開発の発注で後悔しないために発注前の判断基準と判定表

2026年9月21日

この記事でわかること

アプリ開発の発注で起きる後悔は2つの型に分かれる
【チェックリスト】発注前に確定させる10項目
依頼先の種類と選び方
発注後に後悔しはじめたときの判断
「作ったことの後悔」は、発注前に需要を確かめることで防ぐ

アプリ開発の発注で起きる後悔は、要件・費用・保守をめぐる「作り方の後悔」と、完成したのに使われない「作ったことの後悔」の2種類に分かれます。前者はRFP・相見積もり・契約条項で防げますが、後者は発注準備をどれだけ精緻にしても防げません。後者を防ぐには、発注の前に見込み客の反応を確かめる工程を別に置く必要があります。

問い	答え
後悔の原因は何か	作り方の後悔（要件・費用・品質・保守）と、作ったことの後悔（需要がない）の2種類
発注前に何をすべきか	作り方：RFP、3社程度の相見積もり、契約での権利と保守範囲の確定。作ったこと：需要を確かめる工程を発注の前に置く
社内でどう判断するか	記事内の判定表と判断シートで「GO／条件付きGO／NO-GO／判断不能」の4区分で判定する

アプリ開発の発注で起きる後悔は2つの型に分かれる

アプリ開発の発注でよく聞く後悔を並べてみると、性質の異なる2つの型が混ざっていることが分かります。ひとつは開発の進め方に問題があった後悔で、もうひとつは開発が予定どおりに終わったにもかかわらず生じる後悔です。原因も防ぎ方も異なるため、この記事では両者を分けて扱います。

作り方の後悔は、要件・費用・品質・保守をめぐって起きる

1つ目の型を「作り方の後悔」と呼びます。完成品が想定と違った、仕様変更が重なって費用が見積もりを超えた、といった後悔がこれにあたります。OSのアップデート対応が保守契約の外にあり、別料金になったという例もこの型に含まれます。

共通しているのは、発注者と開発会社の間で決めておくべきことが、発注の時点で決まっていなかったという点です。要件の範囲や変更時の費用、テストの基準、保守の対象が曖昧なまま契約すると、そのしわ寄せは開発の後半やリリース後に表面化します。そのため、この型の後悔は、発注前の準備と契約の内容によって防ぐことができます。

作ったことの後悔は、予定どおりに完成したあとで起きる

2つ目の型を「作ったことの後悔」と呼びます。要件どおりに、予算と納期の範囲内で完成したものの、顧客向けであれば利用者が集まらず、社内向けであれば現場で使われないという後悔です。

この型では、開発会社は合意した要件どおりに納品しているため、契約上の問題が見当たりません。原因が発注の進め方ではなく、何を作るかを決めた前提のほうにあるためです。その結果、責任の所在を問う先がなく、後悔は発注者の側にそのまま残ることになります。RFPや要件定義は、決めたものを正しく作るための手段であり、決めたものに需要があるかを確かめる手段ではないという点を押さえておきましょう。

公開されている調査が「作り方の後悔」を中心に示している理由

発注の後悔を数値で示した調査に、フロンティア株式会社が2024年2月に公表したものがあります。システム開発の発注で失敗した経験のある担当者110名に、「しっかり行うべきだった」項目を尋ねた調査です。上位は、発注先候補とのオリエンテーション（42.7%）とRFPの作成（41.8%）でした。

ただし、この調査の選択肢は、オリエンテーションやRFPから設計、コーディング、テストまで、発注と開発の工程で構成されています。そのため、「そもそも作るべきだったか」という問いは測定の対象に入っていません。これは発注工程の課題を把握するという調査目的に沿った設計ですが、結果を後悔の原因の全体像として読むことはできないということになります。また、対象はシステム開発全般であり、アプリ開発に限った結果ではありません。

作ったことの後悔が起きる割合については、アプリ開発に限った公開データが見当たりません。そのため、ここでは型として区別するところまでにとどめます。

引用元：フロンティア株式会社「システム開発の発注に関する失敗調査」2024年2月5日、調査URL：https://prtimes.jp/main/html/rd/p/000000086.000016175.html

【チェックリスト】発注前に確定させる10項目

作り方の後悔につながる項目を、発注前に社内で確定させておくものに絞って10項目の表にしました。いずれも開発会社に任せることができず、発注者の側でしか決められない項目です。「確認者」の列には社内で判断する立場の人を入れていますので、各項目を誰が決めるのかを割り振る際に使ってください。

区分	項目	確定させる内容	未確定のまま発注すると起きること	社内の確認者
目的	ビジネス目標	アプリで何をどう変えるかを、数値を含めて言語化する	機能の優先順位が決まらず、追加要望を断る根拠がなくなる	事業責任者
目的	KPIと計測方法	何を成果とし、どの操作を計測して判断するか	リリース後に効果を判定できず、計測のための改修が後から発生する	事業責任者・マーケティング
範囲	初回リリースの機能	最初のリリースに含める最小限の機能	機能が膨らみ、費用と納期が見積もりを超える	プロジェクト責任者
範囲	今回は作らない機能	次の段階以降に回すと合意した機能	開発中の追加要望に歯止めがかからなくなる	プロジェクト責任者・事業責任者
体制	最終意思決定者	仕様の判断を、誰が何日以内に下すか	開発会社への回答が遅れ、スケジュールが後ろにずれる	部門長・経営層
体制	変更の承認フロー	変更の申請、費用の判断、記録の残し方	追加費用の根拠が残らず、精算の段階で揉める	プロジェクト責任者
費用	開発費の上限と予備費	支払える上限額と、仕様変更に備えた予備の枠	追加費用が出た時点で社内承認が取れず、開発が止まる	部門長・経理
費用	保守・運用費	リリース後に毎年かかる費用とその範囲	運用予算がなく、不具合やOS更新への対応が止まる	部門長・経理
アプリ固有	対応OS・端末・配布方法	対応するOSと端末の範囲、ストア審査を見込んだ日程	特定の端末で不具合が出る、審査の否認でリリースが遅れる	プロジェクト責任者・情報システム
権利	ソースコードの扱い	著作権の帰属と、開発会社を変える場合の引き渡し方針	別の会社に保守を移せず、最初の開発会社に依存し続ける	法務

目的・範囲・体制は、要件定義の前に社内で決めておく

表の上から6項目は、開発会社と要件定義を始める前に、社内で結論を出しておく項目です。なかでも「今回は作らない機能」は見落とされやすく、作る機能だけを決めて発注すると、開発中に出てくる追加要望を断る基準がなくなってしまいます。追加要望の多くは善意から出るものであるため、あらかじめ合意した線がなければ、担当者の判断だけで断るのは難しいでしょう。

最終意思決定者には、名目上の責任者ではなく、実際に仕様を判断できる人を指名しておく必要があります。開発会社からの確認事項に回答できる人が社内にいないと、そのたびに会議を開くことになり、遅れがそのまま納期に積み上がっていきます。

費用は、開発費の外側にかかるお金まで見積もる

発注時の稟議では開発費だけが議論されがちですが、アプリはリリース後にも費用がかかり続けます。不具合の修正、OSの年次アップデートへの対応、ストアの規約変更への追従などがその代表です。これらの費用が開発費に対してどの程度になるかは、アプリの規模や保守の範囲によって大きく変わるため、ここでは目安の数値を示しません。発注前の相見積もりの段階で、保守の範囲と年間費用を開発費と分けて提示してもらい、比率として把握しておくことをおすすめします。

予備費についても、上限額ぴったりで稟議を通すと、仕様変更が一度出ただけで追加の承認手続きが必要になり、その間は開発が止まります。

アプリ固有の項目は、配布方法から決める

Webシステムと違い、アプリは利用者の端末に配布する必要があります。顧客向けのアプリであれば、App StoreとGoogle Playの審査を通す必要があります。そのため、審査で否認された場合の修正と再申請の期間を、日程に含めておかなければなりません。

一方、社内向けのアプリであれば、公開ストアを通さずに、法人向けの配布の仕組みやMDM（モバイルデバイス管理）を使って配布する方法もあります。どの方法を選ぶかによって、必要な審査や開発会社に求める経験が変わるため、対応OSや端末の範囲とあわせて、発注前に決めておくのがよいでしょう。権利関係の項目は、次のセクションで契約の確認事項として詳しく扱います。

依頼先の種類と選び方

アプリ開発の依頼先は、開発会社だけではありません。依頼先の形態によって、発注者の側に求められる体制が変わるため、ここでは5つの類型に分けて整理します。費用の相場は案件の規模による差が大きく、類型だけで比べられるものではないため、この表には載せていません。

依頼先は5つの類型に分かれ、発注者に必要な体制が異なる

依頼先の類型	向いている案件	注意しておく点	発注者側に必要な体制
受託開発会社	要件がある程度固まっている案件	会社ごとに得意な技術や業種が異なる	要件を判断できる担当者
オフショア・ラボ型	継続的に開発を続ける案件	仕様の伝え方と品質確認の手間が増える	仕様を文書で伝え、成果物を確認できる体制
元請（SIer）経由	既存システムとの連携が多い大規模案件	実際に開発する会社との間に一段階入る	元請との窓口担当者
フリーランス	小規模な案件、試作品の開発	本人の不在時に開発と保守が止まる	設計と進行を自社で管理できる人材
ノーコード開発	機能が標準的で、早く形にしたい案件	ツールの機能の範囲を超える要件には対応できない	ツールの制約を理解したうえでの要件の絞り込み

どの類型にも向き不向きがあり、優劣ではなく、案件の性質と自社の体制との組み合わせで選ぶことになります。たとえば、社内に開発を管理できる人がいない場合、フリーランスやオフショアに発注すると、本来は発注者が担うべき進行管理が抜け落ちてしまいます。

相見積もりでは、金額より見積もりの中身を比べる

依頼先の候補が決まったら、同じRFPを3社程度に渡して見積もりを取ります。比べる軸は、同種のアプリの開発実績、採用する技術、見積もりの内訳の細かさ、仕様変更時の費用の扱い、保守の体制の5つです。

このうち見落とされやすいのが、見積もりの内訳の細かさです。「一式」でまとめられた見積もりは、金額が低く見えても、どの作業が含まれていないのかが読み取れません。そのため、仕様変更や追加の作業が出た時点で、費用が膨らんでいく原因になります。工程ごと、機能ごとに内訳を出してもらい、各社の見積もりに含まれていない作業を並べて比べることをおすすめします。

契約では、変更の扱いと途中の確認を条文に入れる

契約形態は、完成した成果物に責任を負う請負契約と、作業の遂行に責任を負う準委任契約に大きく分かれます。どちらを選ぶかで、仕様変更の扱いや、成果物が要件を満たさなかったときの対応が変わるため、法務部門とあわせて確認しておく必要があります。

そのうえで条文に入れておきたいのは、仕様変更の費用をどう算出するかと、開発の途中で動く画面を確認する機会の2点です。社内の承認フローを決めていても、変更の費用算出の方法が契約にないと、追加の見積もりのたびに交渉が発生します。また、途中の確認の機会を契約に入れておけば、想定との違いに完成前の段階で気づくことができます。

発注後に後悔しはじめたときの判断

発注前の準備が十分でないまま、すでに開発が進んでいるケースもあるはずです。このセクションは当社の実績データに基づくものではなく、発注後に取れる判断を一般的な考え方として整理したものです。

開発の途中であれば、確認の機会を増やして範囲を縮める

契約に途中の確認が定められていなくても、動く画面を見せてほしいと依頼することはできます。完成品が想定と違うという後悔は、完成してから気づくほど修正の費用が大きくなるため、違和感を覚えた段階で確認を求めるほうが傷は浅く済みます。

そのうえで想定との違いが見つかった場合、機能を足して埋めるのではなく、初回リリースの範囲を縮める方向で開発会社と交渉するのがよいでしょう。機能を足すと費用と納期がさらに膨らみますが、範囲を縮めれば、少なくとも予算の中で一度リリースすることができます。

続けるか止めるかは、残りの費用で判断する

続けるかどうかの判断を難しくするのは、すでに支払った費用の存在です。ここまで払った以上は完成させたいという心理が働きますが、支払済みの費用は、続けても止めても戻ってきません。そのため判断の材料にすべきなのは、完成までに残りいくらかかるかと、完成したときに何が得られるかの2点だけです。取れる選択肢は、次の3つに整理できます。

選択肢	向いている状況	事前に確認すること
範囲を縮めて完成させる	中核の機能には価値があり、周辺の機能が膨らんでいる	縮めた範囲での追加費用と納期
別の開発会社に引き継ぐ	進め方や品質に問題があり、作るもの自体は妥当	ソースコードと設計書の引き渡し条件
開発を止める	作るもの自体の前提が崩れている	契約上の解除の条件と、それまでの作業費の精算

開発を止める場合、民法上は、請負契約であれば完成前に損害を賠償して解除でき、準委任契約であればいつでも解除できると定められています。ただし、個別の契約の条項によって扱いが変わるため、実際に解除を検討する段階では、契約書を持って弁護士に相談してください。

「作ったことの後悔」は、発注前に需要を確かめることで防ぐ

ここからは、当社が支援した需要検証の事例をもとに説明します。先にお断りしておくと、この事例はアプリ開発ではなく、法人向けレンタル・サプライ事業が新しい顧客層を開拓できるかを確かめた検証です。作るものは違いますが、事業者の想定と市場の反応のずれを実測した例として紹介します。

事業者が考える強みに、検索需要がなかった事例

この検証では、検索広告と専用のページを用意し、2週間、広告費約10万円で見込み客の反応を測りました。依頼元の企業は、設備を用いた品質検査、個体管理の仕組み、小ロット対応の3点を強みと考えていました。そのため、これらを言葉にしたキーワードも配信の対象に入れています。

結果は、品質検査と小ロット対応のキーワードは表示回数が0回で、個体管理のキーワードは11回表示されたもののクリックは0件でした。広告が表示される条件を満たす検索が、期間中にほとんど発生しなかったということです。一方で反応があったのは、業者を今すぐ探している人の検索でした。

この結果は3つの強みに価値がないことではなく、見込み客が業者を探すときに使う言葉ではなかったことを示しています。そのため検証後は、これらを比較の段階で伝える要素に位置づけ直しています。アプリの機能一覧も同じで、発注者が差別化になると考える機能が、利用者が使い始める理由になるとは限りません。

約10万円・2週間で、成約に至る反応まで観測できた

2週間の配信で、表示回数1,850回、クリック129件、問い合わせ15件を得ました。その後、問い合わせのうち5件が商談に進み、2件が成約しています。広告費を成約数で割ると1成約あたり約5万円ですが、成約1件あたりの売上を把握していないため、この金額が妥当かどうかは評価していません。

判定はGOとしましたが、この根拠には弱点があります。検証前に獲得単価などの数値基準を置いていなかったため、事前の基準に照らした判定ではなく、成約に至ったという事実に基づくGOだからです。また、約10万円・2週間という規模はこの案件での実績であり、どの案件にも足りるという意味ではありません。

小さな検証では、言えることと言えないことがある

この検証では顧客層によって反応に差が出ましたが、指標によって、その差を統計的に確かめられるものと確かめられないものがありました。宿泊業のうち小規模に運営されている層（層A）と、業種名で業者を探す汎用的な層（層B）を比べたのが次の表です。

指標	層A	層B	読み取れること
クリック率	17.0%（11.8〜23.9%）	5.7%（4.6〜7.1%）	範囲が重ならず、層Aのほうが高いと言える
問い合わせ率	20.0%（8.9〜39.1%）	9.3%（4.6〜18.0%）	範囲が重なっており、差があるとは言えない

括弧内は95%信頼区間で、実際の値がこの範囲にあると見込まれる幅を示しています。クリック率は分母の表示回数が多いため範囲が狭く、差を判断できます。一方、問い合わせ率は分母のクリック数が少ないため範囲が広く、この規模では判断できません。当社はこの結果をもとに、層Aに絞った展開を推奨しましたが、これは問い合わせ率ではなく、クリック率の差に基づく判断です。また、成約2件がどちらの層から出たかは追跡していません。

全体の平均だけでは、こうした層ごとの違いは見えません。この検証でも、広告費の28%は問い合わせが1件も出なかったキーワードに使われていました。

検索広告による検証が使えないケース

この方法は、見込み客が検索という行動を取ることを前提にしています。そのため、利用者が社内の従業員である業務アプリには使えません。社内アプリの場合は、現場の利用者に試作品を触ってもらうなど、別の方法で需要を確かめる必要があります。

また、これまでにない新しい種類のサービスは、見込み客がそれを表す言葉を持っていないことがあります。この場合、検索広告の表示回数が0回でも、需要がないとは判断できません。表示回数0回が意味するのは、その言葉で探している人がいないということまでです。

【判定表】需要を確かめた結果の読み方

需要を確かめる検証では、どの段階で反応が止まったかによって、結果の意味と次に取る行動が変わります。成約から先に見て、判断がつかなければ手前の段階へ下りていく順序で、状態ごとの読み方を表にしました。

観測された状態	意味	次の行動	参考：事例の該当
成約あり	需要と条件の両方が成立している	事前の基準と照らしてGOを判定する	該当（2件）
商談あり・成約なし	需要はあるが、価格や提供範囲が合っていない	失注の理由を集め、条件を見直す	—
問い合わせあり・商談なし	反応はあるが、購入を検討する段階の層ではない	問い合わせの中身を見て対象の層を絞る	—
クリックあり・問い合わせなし	ページが期待と合っていない、または件数不足	件数が少なければ判断不能として期間を延ばす	一部の層が該当（5クリック）
表示あり・クリックなし	その言葉で探す人はいるが、訴求が響いていない	広告の見出しを変えて再測定する	個体管理の訴求が該当
表示なし	その言葉で探す人がいない	言葉を変えるか、検索以外の方法で確かめる	品質検査・小ロットの訴求が該当

この表では「判断不能」を正式な結論の一つとして扱っています。GOとNO-GOの二択にしておくと、判断のつかない結果が出たときに、社内の力関係でどちらかに寄せられやすいためです。判断不能のときに期間をどこまで延ばすかも、事前に決めておきましょう。

事前に決める基準と、決めない基準

検証の前に決めておくのは、成約1件あたりにかけてよい費用の上限です。成約1件の売上と、想定する契約の継続期間から逆算して、判定の基準にします。前述の事例で1成約あたり約5万円という結果を評価できなかったのは、この上限を置いていなかったためです。

一方で、表示回数や問い合わせ率は、配信してみるまで水準の見当がつかないため、厳密な基準は置きません。なお、アプリの需要を確かめる場合は、問い合わせの代わりに事前登録やデモの申し込みを反応として数えます。

自社の案件で発注前に需要を確かめるべきか、何を基準に置けばよいかを整理したい場合は、無料相談をご利用ください。検証を前提とせず、発注に進むべき案件かどうかの判断からご一緒します。

発注前に取れる選択肢を公平に比べる

アプリの発注を検討している段階で取れる選択肢は、開発会社への発注だけではありません。需要を確かめる手段も、当社のような検証サービスに限らず複数あります。ここでは7つの選択肢を、分かることと分からないことを中心に並べました。

選択肢	得られること	分からないこと・限界	費用の目安	向いている状況
このまま開発会社に発注する	最短で形になる	需要の有無は完成後まで分からない	見積もり次第	需要がすでに確認できている
内製する	仕様変更に社内で柔軟に対応できる	体制づくりに時間がかかる	人件費と採用費	継続的に改善を続ける前提がある
Web・ノーコード・LINEミニアプリで代替する	小さく作って実際の利用状況を測れる	アプリ固有の機能は再現できない	見積もり次第	アプリである必要性がまだ弱い
調査会社に市場調査を依頼する	認知や購入意向を大人数に聞ける。検索されない新しい種類のサービスも調べられる	回答と実際の行動が一致するとは限らない	見積もり次第	市場の全体像や規模感を把握したい
広告代理店にテスト広告を依頼する	配信の規模と運用の知見を借りられる	何をもって判定するかは依頼側で設計する必要がある	広告費と運用手数料	判定の設計を社内でできる
需要検証サービスを使う	少額で実際の見込み客の行動を測れる	検索されない需要と社内アプリは測れない。1回の検証は件数が少ない	広告費（事例では約10万円）とサービス費	発注前に続けるかどうかを判断したい
何もしない（発注を見送る）	費用がかからない	需要があった場合の機会を失う	なし	事業上の優先度が下がっている

選択肢は、組み合わせて使うことができる

表の選択肢は、どれか一つを選ぶものではありません。たとえば、市場調査で規模感をつかんだうえで検索広告で実際の行動を確かめ、需要が見えた機能に絞って発注する、という順序も取れます。回答を集める調査と行動を測る検証は、分かることが異なるため、互いの限界を補い合う関係にあるといえるでしょう。

どの選択肢を取るかは、開発の見積もり額と、需要が外れた場合の損失の大きさで決まってきます。開発の見積もりが大きい案件ほど、発注の前に需要を確かめる費用は相対的に小さくなるため、確かめる価値が高くなる傾向にあります。

「何もしない」も、判断の結果として選んでよい

発注を見送ることも、失敗ではなく一つの判断として扱えます。社内で案件が走り出していると見送りは言い出しにくくなりますが、需要の確証がないまま発注するよりも、損失を小さく抑えられる場合があります。ただし、見送る場合も「何が分かれば再開するか」を決めておかないと、判断の先送りと区別がつかなくなります。

【社内説明用】アプリ開発の発注判断シート

最後に、ここまでの内容を社内説明用の1枚にまとめました。上段は作り方の後悔を防ぐ項目、下段は作ったことの後悔を防ぐ項目です。

区分	確認項目	基準の置き方	参考：事例（アプリではない）
作り方	目的とKPI	何をどう変えるかを数値で書く	—
作り方	初回の範囲と作らない機能	両方を一覧にして合意する	—
作り方	意思決定者と変更の承認フロー	仕様を判断する人と回答期限を決める	—
作り方	開発費の上限・予備費・年間保守費	保守費は開発費と分けて見積もらせる	—
作り方	相見積もりと契約	内訳を比べ、契約形態と途中確認を決める	—
作ったこと	需要を確かめた方法	回答ではなく行動を測ったか	検索広告と専用ページ、2週間、広告費約10万円
作ったこと	成約1件あたりの費用上限	売上と継続期間から事前に逆算する	置いていなかった
作ったこと	観測できた最も深い段階	判定表のどの段階まで反応が出たか	成約2件
判定	発注に進むか	GO／条件付きGO／NO-GO／判断不能	GO（層を限定）