社内アプリ外注の見積比較｜同じ土俵に乗せる11項目

社内アプリの外注で、A社80万円・B社250万円・C社600万円のような見積が並ぶことがあります。これは各社の良心や技術力の差ではなく、見積の前に置いた前提（要件の粒度・画面数・権限・移行データ量・保守の範囲）が各社で違うために起きます。したがって最初に揃えるのは金額ではなく前提です。この記事では、各社の見積を同じ土俵に乗せる11項目と、3年総額で比べると順位が逆転する理由、「一式」「別途お見積り」を潰すための質問文、そして「作らない」選択肢を同じ表に並べる方法までを順に確認します。

結論：見積が比較できない原因は、金額ではなく前提のズレ

金額が3倍違う見積でも、中身を開くと「同じものを作っていない」ことがほとんどです。実務で差の正体になりやすいのは、次の5つの前提です。

• 要件の粒度：要件定義が見積に含まれているか、それとも「要件は貴社から出てくる前提」で積まれているか
• 画面数：入力・一覧・詳細・検索・集計・マスタ管理をそれぞれ1画面と数えるか、まとめて1画面と数えるか
• 権限：全員が同じ画面を見るのか、役職や部署で見える行・列を変えるのか
• 移行データ量：既存シートをそのまま流し込めるのか、表記ゆれの統合やマスタ化が必要なのか
• 保守の範囲：障害対応だけなのか、項目追加や様式変更まで月額に含むのか

この5つのうち1つでも各社で違っていれば、金額の比較は成立しません。逆に言えば、前提を1枚の紙に書いて全社に同じものを渡せば、金額差はほぼ「やり方の差」だけに収まります。

この「工程を分けて、工程ごとに見積と契約を置く」考え方は、経済産業省とIPA（独立行政法人情報処理推進機構）が公表している情報システム・モデル取引・契約書（第二版・2020年12月22日公表）でも採られています。モデル契約では開発を要件定義・外部設計・開発・移行支援といった工程に分け、工程ごとに委託料を定める多段階契約と再見積りのプロセスが示されています。中小企業の小さな社内アプリでここまで分ける必要はありませんが、「要件定義より後ろの金額を、要件定義の前に確定させるのは無理がある」という前提だけは共通です。1本の総額だけが書かれた見積が出てきたら、そこを疑ってください。

同じ土俵に乗せるシート：並べる11項目

各社の見積を、次の11行だけのシートに転記します。相見積りを取る前にこのシートを先に作り、空欄のまま各社へ渡すのがいちばん早いやり方です。

11項目のうち、見積段階でいちばん抜けているのは4（データ移行）・5（権限設計）・11（納品物と権利）です。この3つは「作る側の作業量」ではなく「発注側が後で困る度合い」に直結するので、金額が入っていない見積は、その分だけ安く見えているだけと考えてください。

シートの使い方：先に渡して、同じ空欄を埋めてもらう

相見積りのときに各社へ自由に書かせると、様式がバラバラで比較不能な紙が3枚集まります。上の11項目を先にシートにしてから「この様式で出してください」と渡すと、各社が同じ粒度で書かざるを得なくなり、比較の手間が数時間から数十分に縮みます。この時点で様式に合わせられない会社は、そもそも前提を固めずに見積っている可能性があります。

3年総額で見ないと、安い順が逆転する

初期費用だけを並べると、判断を間違えます。社内アプリの費用は「初期開発費」と「毎月出ていくお金」に分かれ、後者は3年で初期費用を追い越すことがあるからです。比べるときは次の式を使ってください。

3年総額 ＝ 初期費用 ＋（保守月額 ＋ サーバー・ライセンス費）× 36 ＋ 想定する追加改修費

追加改修費は読みにくいので、「年に3回・1回あたり半日」程度を仮に置いて計算するのが現実的です。年3回 × 0.5日 × 時間単価相当で見ておけば、だいたいの振れ幅には収まります。

よくある3つの型を、同じ式に入れてみます（金額は型の違いを見るための仮の数字です。自社に来た見積の実数に置き換えてください）。

AとBは初期で3倍違うのに、3年総額ではBのほうが安くなりました。初期費用の安さは、保守月額に移し替えられているだけの場合があるということです。逆に、3年より長く使う前提なら差はさらに開きます。社内アプリは5年以上使われることも多いので、長く使う見込みがあるなら5年総額（×60か月）でも並べてみてください。

月額が「安全」に見えるときの落とし穴

月額が安い見積で確認すべきなのは、その月額に何が含まれないかです。「障害対応のみ」と書かれた保守は、項目を1つ追加するだけでも有償改修になります。項目追加が年に何回起きそうかは自社のほうが分かるので、月額の安さではなく「年に何回・いくら掛かるか」に直して比べてください。

「一式」「別途お見積り」が入っている行の潰し方

見積に「一式」「別途お見積り」「要件により変動」と書かれた行があると、それだけで比較が崩れます。相手を責める必要はなく、次の質問をそのまま投げれば、ほとんどは数字に変わります。

• 「一式」に対して：「この一式に含まれる作業を、工数（人日）と担当者の役割で内訳にしていただけますか。合計金額は変えなくて構いません」
• 「別途お見積り」に対して：「現時点で確定できないのは理解しています。上限と下限の幅と、幅が決まる条件（行数・画面数など）を教えていただけますか」
• 「要件により変動」に対して：「変動の対象になる要件を3つまで挙げるとすれば何ですか。その3つを今決めれば、この行は固定できますか」
• 保守の範囲に対して：「月額に含まれる作業と、含まれず有償になる作業を、それぞれ具体例3つで書いていただけますか」
• 追加改修に対して：「項目を1つ追加する場合、最小の課金単位はいくらですか（時間単位か、0.5日単位かなど）」
• 納品物に対して：「納品物の一覧を教えてください。ソースコードと設計書は含まれますか」

この6問に全部答えが返ってきた会社は、少なくとも前提を自分で把握しています。逆に「やってみないと分かりません」で終わる場合は、その会社の中でも見積の根拠が固まっていないということなので、金額の低さを理由に選ばないほうが安全です。

私たちはいま使っているスプレッドシートを置き場所として残したまま、入力画面だけを載せ替える形のサービスも行っております。記事の途中で恐縮ですが、「全部作り直す」以外の見積を1本足したいときの比較対象として、よろしければ合わせてご覧いただけたら嬉しいです。

安すぎる見積の読み方

相場より明らかに安い見積が1本だけ混じっているときは、だいたい次の4つのどれかが起きています。安いこと自体が悪いのではなく、何が引かれているかを確認してから選ぶのが要点です。

4つめの「触れない」は、金額に出ないのに影響が最も長く残ります。委託して作らせたプログラムの著作者は、料金を払ったかどうかに関係なく実際に創作した受注者側になるのが原則で、発注者が著作権を得るには契約での譲渡が必要です（文化庁「著作権テキスト」）。さらに著作権法61条2項では、譲渡契約で第27条（翻案権）・第28条（二次的著作物の利用）の権利を譲渡の目的として特に掲げていないと、これらは譲渡した側に留保されたものと推定されると定められています（著作権法・e-Gov法令検索）。つまり「著作権は譲渡する」と書いてあるだけでは、後から自社や別の会社が改造してよいかが曖昧に残ります。

高い見積が妥当なケース

一方で、高いほうが正しいこともあります。次のどれかに当てはまる場合、安い見積のほうが前提を読み落としている可能性が高いと考えてください。

• 権限の段数が多い：役割ごとに見える行・列を変える要件は、画面数より費用を動かします
• 既存システムと連携する：会計・販売管理・勤怠などと自動でつなぐ場合、相手側の仕様調査に時間が要ります
• 移行データが汚れている：同じ取引先が3通りに書かれている、日付が文字列で入っている、といった状態の整理は作業量が読みにくく、見積に幅が出ます
• 止まると業務が止まる：受注や請求に直結するなら、テストと復旧手順に工数を割くのが妥当です
• 要件定義から一緒にやる前提：要件を書く工数を正直に積んだ結果、総額が上がっている場合があります

見積の比較表に「権限の段数」「連携の本数」「移行する行数」の3つを書き込むと、高い理由が妥当かどうかがその場で判断できます。費用の出方そのものの違いを押さえておきたい場合は、業務アプリをノーコードで組むか開発するかの判断軸も参考になります。

「作らない」も同じ表に並べる

比較表に載せるべき選択肢は、外注先3社だけではありません。作らない案を同じ3年総額の式に入れると、判断がはっきりします。実務でよく効くのは次の2つです。

既存のSaaSを使う

汎用の業務アプリ基盤を使う案です。たとえばkintoneの公式価格は、ライトコースが1ユーザーあたり月1,000円、スタンダードコースが月1,800円（いずれも税抜）で、最小契約ユーザー数は10ユーザー、初期費用は無料とされています（kintone 公式料金ページ）。10人でスタンダードコースを使うなら月18,000円＝3年で648,000円です。ここにアプリを作ってもらう初期費用や、必要なら連携プラグインの費用が乗ります。

この案の損得は、ほぼ人数で決まります。使う人が増えるほど月額が線形に伸びるので、将来20人・30人が触る見込みがあるなら3年総額で必ず検算してください。すでにこの種のサービスを使っていて乗り換えを検討している場合は、kintone乗り換えの費用と代替案のほうが近い論点を扱っています。

いまのスプレッドシートに入力画面だけ足す

データの置き場所はスプレッドシートのまま残し、入力と検索の画面だけを別に作る案です。初期費用が小さく、やめるときも元のシートがそのまま残るので後戻りがききます。弱点は、行数が数万行を超えたときの速度と、複雑な権限制御です。

そもそもアプリにすべきかどうかから迷っている段階なら、社内アプリを作るべきかの判断と回収月数の試算で回収月数を先に出しておくと、見積の良し悪しが判断しやすくなります。小さな自動化で足りる場合は、GAS開発を外注するときの費用の考え方も比較対象に入れてみてください。

発注前に書面で確認する8項目

金額が決まったあと、契約書か発注書に次の8つが書かれているかを確認します。口頭での合意は、担当者が変わった時点で消えます。

1. 成果物の一覧：画面名、帳票、設計書、ソースコード、手順書のどれを納品するか
2. 著作権の帰属：譲渡するなら「著作権法第27条・第28条の権利を含む」と明記されているか
3. 検収の基準と期間：何をもって完了とするか、確認にかけられる日数は何日か
4. 保守に含まれる作業：障害対応・項目追加・様式変更のどこまでが月額内か
5. 追加改修の単価と最小単位：時間単価か日単位か、最小の課金単位はいくらか
6. サーバー・ライセンスの名義：契約主体が自社か受注先か（受注先名義だと解約時に移せません）
7. 解約と引き継ぎ：解約予告の期間、解約時にデータとソースコードをどの形式で受け取れるか
8. データの取り扱い：個人情報を含むか、作業時に持ち出すか、作業終了後の削除をどう確認するか

6と7は忘れられやすいのに、効き方が大きい項目です。サーバーやSaaSの契約が受注先の名義になっていると、関係が終わったときにデータだけが相手側に残ります。発注時に名義を自社にしておけば、あとで揉めません。

なお、発注先が法人ではなく個人事業主の場合は、2024年11月1日施行の「フリーランス・事業者間取引適正化等法」が関わります。取引条件を書面または電磁的方法で明示する義務と、成果物を受領した日から60日以内に報酬を支払う義務が発注側にあります（公正取引委員会・中小企業庁「フリーランス・事業者間取引適正化等法パンフレット」）。見積比較の段階から支払条件を揃えておくと、後の手戻りがありません。

比較のとき、やらなくていいこと

最後に、時間をかけても判断が良くならないものを挙げます。

• 各社の技術スタックの優劣を調べる：使う技術の名前は、3年総額と保守の範囲ほど結果を変えません
• 実績件数を比べる：件数より、自社と同じ業務（受注管理・在庫・原価など）を扱った例が1件あるかどうかが効きます
• デザインの作り込みを比べる：社内で使う画面は、見た目より入力の速さと権限の正確さで評価が決まります
• 全機能を1期目で揃える：最初は1業務・1画面に絞り、動いた実感が出てから広げるほうが総額が小さくなります

外注と内製のどちらに寄せるかで迷っている場合は、社内のAI活用を内製するか外注するかの判断と、社内アプリを内製して失敗する7パターンを先に見ておくと、見積に入れるべき自社側の工数が読めます。作ったあとに外部へ月額で入ってもらう形を検討するなら、社内DXで外部パートナーに月額で入ってもらう形と月額の出し方で保守月額の相場感を確認してください。

あわせて読みたい

• 社内アプリは作るべきか｜作らない判断と回収月数の試算
• 業務アプリはノーコードか開発か｜判断5軸と3年総額
• 見積もり自動化システムの費用相場
• 顧客管理システムを作るときの費用の考え方
• 脱エクセルの費用相場
• 社内DXの外部パートナー月額｜4形態と月額の出し方

見積が3本そろっていて、どれを選ぶか判断がつかないという段階でしたら、匿名化したうえで見せていただければ、前提の違いがどこにあるかの整理はお手伝いできます。