システム開発会社の選び方｜比較ポイント7つ

01はじめに｜この記事でわかること

要点：システム開発会社の選び方を、比較ポイント7つに絞って整理します。会社のタイプの違い、工程ごとに変わる契約の型、見積書のそろえ方、第三者認証の見方まで順に見ていきます。費用の目安はシステム開発の費用相場もあわせてご覧ください。

「3社から見積りをもらったのですが、金額が3倍も違っていて、どう比べればいいのかわかりません」。システム開発のご相談で、いちばん多くいただく声です。金額の差そのものより、なぜ差が出たのかが見えないことが不安の正体ではないでしょうか。

差の理由は、たいてい3つのどれかです。含まれている工程が違う。想定している規模が違う。公開後の面倒を見るかどうかが違う。そろえないまま金額だけを並べると、いちばん抜けの多い見積書がいちばん安く見えます。

この記事は、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、実際のご相談をもとにまとめました。判断の材料には、IPA（情報処理推進機構）のモデル契約や中小企業庁の白書など、誰でも確認できる資料を使います。

本題に入る前に、発注する側が見積りを受け取ったあとに何を確かめるべきか、実務の視点でまとめられた動画をご紹介します。

02まず、システム開発会社は3タイプに分かれます

要点：システム開発会社は「大手・元請け型」「中堅・自社開発型」「小規模・特化型」の3タイプに分かれます。同じ看板でも、誰が実際に手を動かすかが違います。ここを取り違えると、選び方そのものがずれます。

会社の看板だけでは、中の体制まではわかりません。ホームページに並ぶ実績が、その会社の社員が作ったものとはかぎらないためです。まずは体制で分けて考えてみてください。

• 大手・元請け型。大規模な基幹システムに強く、管理体制も整っています。ただし実際の開発は協力会社に流れることが多く、中小企業の数百万円規模の案件は受けてもらいにくい傾向があります。
• 中堅・自社開発型。設計から開発までを自社の技術者で回します。中小企業の業務システムやECサイト構築は、この層が主戦場です。
• 小規模・特化型。特定の技術や業種に絞って動きます。単価は抑えられますが、同時に走らせられる案件数とメンテナンスの余力に限りがあります。

個人と会社のどちらに頼むかで迷っている段階なら、ホームページ制作は会社とフリーランスどっちかを先にご覧ください。判断の軸は、システム開発でもほぼ同じです。

03比較ポイント1｜近い規模・近い業務の実績があるか

要点：実績は「同じ業種か」より「同じ規模・同じ業務か」で見ます。在庫管理や受発注の仕組みは、業種が違っても構造がよく似ています。逆に、同じ業種でも従業員5名と500名では、必要な設計がまったく変わります。

実績ページは、写真や社名ではなく次の3点を聞いてください。答えられない会社は、その案件に深く関わっていない可能性があります。

1. どの工程を担当したか。要件定義から入ったのか、決まった仕様を作っただけなのか。
2. 何人月かかったか。規模感がわかると、自社の案件と比べられます。
3. 公開後もメンテナンスを続けているか。作って終わりなのか、運用まで見ているのかがわかります。

業務システムの事例は、公開されていないものが多いのも実情です。守秘義務があるためで、隠しているわけではありません。その場合は「近い構成のものを、口頭で説明してもらえますか」と頼めば十分です。Excel業務のシステム化のように、出発点が近い事例なら参考になります。

04比較ポイント2｜要件定義から一緒に入ってくれるか

要点：要件定義を発注側に丸投げする会社は避けてください。IPAのモデル契約では、ベンダは開発を適切に進め、発注側がプロジェクトへ関与するよう働きかける義務を負うとされています。最初の設計に入らない会社は、この役割を果たしていません。

「やりたいことを整理してから来てください」と言われて困った、という話をよく聞きます。ただ、業務を言葉にする作業こそ、いちばん専門性が要るところです。IPAの情報システム・モデル取引・契約書（第二版）でも、ベンダのプロジェクトマネジメント義務と、発注側の協力義務は対になるものとして整理されています。

とはいえ、発注側が何も準備しなくていいわけではありません。困っていること、今のやり方、譲れない条件。この3つを箇条書きにしておくだけで、初回の打ち合わせの密度は変わります。書き方はRFPの書き方と要件定義の進め方にまとめています。

05比較ポイント3｜見積書が工程と工数に分かれているか

要点：「システム開発一式」と書かれた見積書は、比較の土俵に乗りません。最低でも工程ごとに行が分かれ、それぞれ何人月かが書かれている必要があります。内訳がないと、あとから増える作業がどこに乗るのかも見えません。

見積書を受け取ったら、まず行数を見てください。3行の見積書と15行に分かれた見積書では、後者のほうが高く見えます。でも実際には、前者に入っていない作業が後から請求されることのほうが多いのです。

とくに漏れやすいのが、テスト、データ移行、操作説明です。今使っているExcelや旧システムからデータを移す作業は、量と汚れ具合で工数が大きく動きます。移行の行がなければ、その分は誰かが後で負担します。読み方はシステム開発の見積もりの見方で解説しています。

06工程ごとに、契約の型は変わります

要点：システム開発は、最初から最後までを1本の請負契約で結ぶとは限りません。IPAのモデル契約では、工程ごとに契約を分ける多段階契約の考え方が示されています。工程によって、成果物が決まっているか決まっていないかが違うためです。

大事なのは、型そのものより「なぜこの工程はこの型なのか」を説明できるかです。要件が固まっていない段階を請負で受ける会社は、リスク分を金額に上乗せするか、あとで追加請求をするかのどちらかになります。アジャイル型で進める場合は、IPAが別途アジャイル開発版のモデル契約も公開しています。

07比較ポイント4｜契約の型と検収の条件を説明できるか

要点：もめごとの多くは、検収の場面で起きます。何をもって完成とするかを先に決めていないためです。契約前に「検収の基準」「不具合が見つかったときの扱い」「その期間」の3つを確認しておけば、後半の揉め方はかなり変わります。

納品されたけれど動きが遅い、想像していた画面と違う。こうした食い違いは、仕様書に書いていなかったから起きます。2020年施行の改正民法では、請負における契約不適合責任として報酬減額請求権が加わり、権利行使の期間制限も整理されました。契約書の該当条項を、担当者が説明できるかどうかを見てください。

検収の基準を決めていない契約は、完成の定義がないまま走り出す契約です。

あわせて、体感速度や同時利用人数といった、数字で表せる条件も先に書いておいてください。IPAは重要情報を扱うシステムの要求策定ガイドで、こうした要求の整理の仕方を公開しています。

08比較ポイント5｜公開後のメンテナンスと、担当が代わったときの備え

要点：システムは、公開してからのほうが長く使います。メンテナンス契約の中身と、担当者が代わったときに誰が引き継ぐかを先に確認してください。設計書が残っていない案件は、次の会社が触れず、作り直しになることがあります。

メンテナンスの見積りは、月額の金額よりも中身を聞いてください。よく差が出るのは次の5つです。

• 障害対応の受付時間。平日日中だけなのか、夜間や休日も含むのか。
• 月あたりの軽微な修正枠。何時間まで含まれ、超えたらいくらか。
• サーバーとミドルウェアの更新。OSやデータベースの更新作業が入っているか。
• バックアップと復旧の手順。いつのデータまで戻せるか。
• ドキュメントの更新。改修のたびに設計書も直すのか。

担当者の交代は、いつか起きるものと考えておくのが安全です。設計書と、環境構築の手順書。この2つが最新の状態で残っていれば、会社を変えることになっても引き継げます。Webシステム開発を長く続けるうえで、ここが実はいちばん効いてきます。

09見積書を、同じ土俵にそろえる

要点：見積書を比べるときは、金額ではなく構成比で並べてください。開発だけが極端に大きく、要件定義とテストが薄い見積書は、決めごとを後回しにしている合図です。下は、業務システムの一般的な工数配分をモデルケースとして示したものです。

要件定義が数%しかない、あるいはテストの行が見当たらない見積書は、どこかで帳尻を合わせることになります。3社の見積書をこの6行に振り分けてみると、差の正体がはっきりします。

10比較ポイント6｜情報の預け先として信用できるか

要点：システム開発を委託すると、開発会社は顧客情報や売上データを預かることになります。営業担当の印象ではなく、第三者が確認した仕組みがあるかで判断してください。認証や登録は、外から確かめられる数少ない材料です。

個人情報を扱うシステムでは、開発中のテストデータの扱いが問題になります。本番データをそのまま開発環境に置く運用は、いまでも見かけます。「テストデータはどう作りますか」と一言聞くだけで、その会社の姿勢がわかります。

海外の拠点で開発する場合は、データがどの国に置かれるかも確認が必要です。オフショア開発とは何かを押さえたうえで、契約書に保管場所と持ち出し禁止の条項が入っているかを見てください。

11会社を客観的に見極める、第三者の指標

要点：会社の信用は、公開されている制度から確かめられます。プライバシーマーク、ISMS、DX認定、そして法人としての登記情報。いずれも自社サイトの記載を鵜呑みにせず、制度の公式サイトで検索できるかどうかまで見てください。

認証がないから悪い会社、ということではありません。少人数の会社では、費用の面で取得していないこともあります。ただ、個人情報や決済に関わるなら、外部の目が入っているほうが安心です。ZenWeb Japanの体制は会社概要に記載しています。

12比較ポイント7｜ソースコードと権利が自社に残るか

要点：納品物にソースコードが含まれるか、著作権がどちらに帰属するかは、契約書に明記されていなければ後で困ります。コードを渡さない契約だと、その会社以外は手を入れられません。乗り換えの自由がなくなるということです。

実際に多いのが、開発会社のサーバー上でしか動かない状態のまま引き渡され、契約を切ると使えなくなるケースです。契約前に、次の4つを書面で確認しておいてください。

1. ソースコードの引き渡し。納品物に含まれるか、別料金か。
2. 著作権の帰属。自社に移転するのか、利用許諾にとどまるのか。
3. サーバーとドメインの名義。自社名義になっているか。
4. 第三者ライブラリの扱い。使っているOSSのライセンス条件は何か。

汎用の部品まで譲渡するのは、開発会社側にも無理があります。「自社向けに作った部分は自社に、汎用部分は利用許諾で」という線引きが現実的です。この考え方はECサイト制作会社の選び方でも同じです。

13いま、中小企業は「着手」の次の段階にいます

要点：中小企業庁の2025年版中小企業白書によると、「紙や口頭による業務が中心」と答える事業者の割合は前回調査から大きく減りました。道具を入れる段階は終わりつつあります。次に問われるのは、業務そのものを設計し直せる相手を選べるかどうかです。

同じ白書では、どの段階でも「費用の負担が大きい」「DXを推進する人材が足りない」と答える割合が高いことも示されています。社内に専任者がいないなら、その前提で伴走してくれる相手を選んでください。線引きはシステム開発の外注と内製、全体像は小規模から始めるDXにまとめています。

14相見積りは3社まで｜同じ条件を渡すのがコツ

要点：相見積りは3社が適量です。5社以上に声をかけると、説明の手間が増えるわりに比較の精度は上がりません。大事なのは社数ではなく、全社に同じ資料と同じ条件を渡すことです。

渡す資料は、次の4点がそろっていれば十分です。完璧な仕様書は要りません。

• 今の業務の流れ。誰が、何を、どの順番でやっているか。
• 困っていること。手作業の重複、転記ミス、確認に時間がかかる箇所。
• 使う人数と時期。同時に何人が使うか、いつまでに必要か。
• 予算の幅。上限を伝えると、身の丈に合った提案が返ってきます。

予算を隠す方は多いのですが、逆効果になりがちです。幅を伝えないと各社が勝手に規模を想定するため、比べられない3枚が並びます。オフショアで費用を抑える選択肢もありますが、その場合もベトナムオフショア開発のように、日本側の窓口が誰かを確認してください。

15契約前に、必ず聞く7つの質問

要点：最後の判断は、7つの質問で足ります。答えの内容より、答え方を見てください。曖昧にごまかす、話をそらす、持ち帰ると言ったまま返事がない。この3つが出たら、そこで止めるのが安全です。

1. 設計と開発は、御社の社員が担当しますか。協力会社に出す場合、その割合と管理方法。
2. この見積りに含まれていない作業は何ですか。含まれないものを言える会社は信用できます。
3. 工程ごとの契約の型は、どう分けますか。理由まで説明できるかを見ます。
4. 検収の合格基準は、どこに書かれますか。契約書か仕様書か、条文の場所を示してもらいます。
5. 公開後のメンテナンスには、何が含まれますか。受付時間、修正枠、更新作業の範囲。
6. ソースコードと著作権は、どちらに残りますか。書面での確認が前提です。
7. 担当者が代わったとき、何が引き継がれますか。設計書と手順書の更新ルール。

この7つは、そのまま比較ポイント7つに対応しています。3社に同じ質問をして、回答を並べてみてください。金額表だけを見比べていたときとは、印象が変わるはずです。

16まとめ｜安さではなく、続けられる体制で選ぶ

要点：システム開発会社の選び方は、7つの比較ポイントに集約されます。実績の中身、要件定義への関与、見積書の粒度、契約の型、メンテナンス体制、情報の扱い、権利の帰属。ここがそろってはじめて、金額の比較に意味が出ます。

システムは、公開した日が出発点です。業務は変わり、法律も変わり、使う人も入れ替わります。そのたびに直せる相手かどうかが、5年後の差になります。作る費用だけを見て決めると、直せない資産が残ってしまいます。

ZenWeb Japanは2000年の創業以来、日本国内とベトナムの拠点で業務システムやECサイトの開発を続けてきました。要件を伺ってからのお見積りとしているのは、同じ機能名でも必要な工数が違うためです。他社の見積書を見ながらの整理からでも承ります。

17よくある質問

1. システム開発会社の選び方で、いちばん重要な項目はどれですか

公開後のメンテナンス体制です。開発は数か月で終わりますが、システムは何年も使い続けます。設計書と手順書が更新され続ける運用かどうかで、他社への乗り換えやすさも決まります。金額の比較は、この確認のあとで間に合います。

2. 見積金額が3社で大きく違うのはなぜですか

含まれている工程が違うためです。要件定義、テスト、データ移行、操作説明のどれかが抜けていると、その分だけ安く見えます。システム開発の見積もりの見方で工程ごとに並べ直すと、差の理由が見えてきます。

3. 小さな会社に頼むと不安でしょうか

規模だけでは決まりません。少人数でも設計書を残し、契約書に権利の帰属を明記する会社はあります。逆に規模が大きくても、開発が何次にも再委託されていれば、誰が作ったのかは見えなくなります。体制と書面で判断してください。

4. パッケージと個別開発は、どちらを先に検討すべきですか

まずパッケージからです。業務をパッケージに合わせられるなら、費用も期間も抑えられます。合わせられない事情がはっきりしたときに、個別開発が選択肢になります。判断材料は予約システムの導入方法で具体例をあげています。

5. 開発会社は、どの時点で決めるべきですか

要件定義を一緒にやってもらう会社を先に決め、その結果を見て開発の契約に進むのが現実的です。IPAの情報システム・モデル取引・契約書も、工程ごとに契約を結び直す考え方を示しています。