
この記事の要点
- 開発会社は、金額だけでなく、似た仕事の経験・体制・契約の形・公開した後の対応をあわせて比べます
- 実際に作業する人が誰か、再委託するかどうかを確かめておくと、後の食い違いを防げます
- 同じ条件で複数の会社に提案を頼むと、見積もりの中身や考え方の違いを比べやすくなります
開発会社を選ぶときは、見積もりの金額だけで決めず、似た仕事の経験、実際に作業する体制、契約の形、公開した後の対応をあわせて比べることが大切です。システムは、作って終わりではなく、公開した後も直したり改善したりしながら長く使うものです。最初の金額が安くても、後の改修や保守に手間がかかると、全体の費用はかえって高くなることがあります。
この記事では、はじめてシステム開発を発注する方に向けて、開発会社を比べるときの観点と、提案の場で聞いておきたい質問を整理します。
選ぶ前に、自社でまとめておくこと
開発会社を比べる前に、自社で「何のために、何を作りたいか」をまとめておくと、比べやすくなります。目的があいまいなまま提案を頼むと、会社ごとに想定する範囲がばらばらになり、見積もりを並べても比べられないためです。
まとめておきたいのは、次のような点です。
- システムを作る目的と、解決したい業務の課題
- 使う人と、おおよその人数
- 欠かせない機能と、あるとよい機能の区別
- いま使っているシステムやサービスと、つなぐ必要があるもの
- 予算の目安と、使い始めたい時期
これらを文書にまとめたものをRFP(提案依頼書)と呼びます。書き方はRFP(提案依頼書)の書き方:載せる項目と注意点で説明しています。同じRFPを複数の会社に渡して提案を頼む(相見積もり)と、違いを比べやすくなります。
比べるときの5つの観点
開発会社を比べる観点は、大きく5つに分けられます。
| 観点 | 確かめること |
|---|---|
| 似た仕事の経験 | 同じような業務・規模・技術のシステムを作った経験があるか |
| 体制 | 誰が責任者で、誰が作業するか。再委託するか |
| 契約の形 | 請負か準委任か。成果物の権利や不具合の責任の扱い |
| 見積もりの中身 | 作業の内訳と前提が書かれているか |
| 公開した後の対応 | 保守・運用・改善を続けて頼めるか |
似た仕事の経験
実績を見るときは、会社の規模や件数よりも、自社の作りたいものに近い経験があるかを見ます。業務の種類(販売管理、予約、社内の申請など)、規模、使う技術が近いと、つまずきやすい点を先に教えてもらえることが多いです。
実績のページに載っていない仕事も多いため、提案の場で「似た仕事でどんな点に苦労したか」を聞いてみると、経験の深さが分かりやすくなります。
体制と再委託
実際に作業する人が誰かは、品質に大きく関わります。提案をする人と、実際に作業する人が違うこともあるため、責任者と作業する人の体制を確かめておきます。
開発会社が、作業の一部をほかの会社に任せる(再委託する)こともあります。IPA(情報処理推進機構)の「情報システム・モデル取引・契約書」では、開発会社が事前に発注者の書面での承諾を得た場合などに、業務の一部を再委託できるとし、再委託先の履行についても、原則として開発会社が自ら行った場合と同じ責任を負う、という条項例を示しています。再委託の有無と、その場合の承諾の手順は、契約の前に確かめておきます(多重下請けの構造と、発注者が確かめること)。
契約の形
システム開発の契約には、仕事の完成を約束する請負契約と、作業を行うことを約束する準委任契約があります。どちらの形を提案されているかで、報酬の払い方や、不具合の責任の扱いが変わります。違いはシステム開発の請負契約と準委任契約は、何が違うかで説明しています。
成果物の著作権をどちらが持つか、ソースコードや設計書を受け取れるかも、比べるときの大切な観点です。権利の扱いはシステム開発の成果物の著作権は誰のものかにまとめています。
見積もりの中身
見積もりは、合計の金額よりも、内訳と前提を見ます。どの作業に何人がどのくらいの期間かかる想定か、何が含まれていて何が含まれていないかが書かれていると、ほかの会社の見積もりと比べやすくなります。
金額が大きく違うときは、前提の違いが原因のことが多いです。安い見積もりは範囲が狭い、高い見積もりはテストや移行まで含んでいる、といった違いです。見方はシステム開発の見積もりは、どこを見ればよいかで説明しています。
公開した後の対応
公開した後に、不具合の修正や改善を続けて頼めるかも確かめます。保守の範囲、対応の時間帯、費用の形は会社によって違います。保守で決めることはシステムの保守契約で決めておくことにまとめています。
提案の場で聞いておきたい質問
提案の説明を受ける場では、次のような質問をすると、会社ごとの考え方の違いが見えやすくなります。
- この計画で、つまずきやすいと考える点はどこですか
- 責任者と、実際に作業する人は誰ですか。途中で替わることはありますか
- 作業の一部をほかの会社に任せる予定はありますか
- 見積もりに含まれていない作業は何ですか
- 仕様を変えたくなったときは、どんな手順で扱いますか
- 公開した後の保守は、どのような形で頼めますか
- ソースコードや設計書は、納品物に含まれますか
答えの内容だけでなく、分からないことを分からないと言うか、リスクを先に伝えてくれるかも、信頼できるかを見る手がかりになります。
選んだ後に大切なこと
開発会社を選んだ後も、発注者の関わり方がプロジェクトの成否を左右します。発注者が決めることを期限までに決め、定例の会議で進み具合を確かめることが大切です(開発プロジェクトの遅れに早く気づくには)。また、契約の形が請負でも準委任でも、作業の指示は開発会社の責任者を通して出すのが基本です。社内で作るか外に頼むかの考え方はシステムとAIの開発、内製と外注をどう分けるかで説明しています。
本記事は一般的な選び方を整理したものです。契約書の内容の判断については、弁護士などの専門家にご確認ください。
当社のご支援
当社は、作るものと範囲を決めて進めるプロジェクト、相談や小さな開発を月単位で頼めるAIタイムシェア、技術者がお客様の現場に入るFDE、専任のチームで進めるラボ開発の4つの関わり方でお受けしています。違いは関わり方と料金の目安にまとめています。開発会社を比べる段階のご相談も、お問い合わせからお気軽にどうぞ。
- 開発会社の選び方
- 発注
- 見積もり
- 契約
この記事に出てくる用語
関連する法令・指針(参考情報)
- 指針
独立行政法人情報処理推進機構(IPA)「情報システム・モデル取引・契約書」(第二版(2020年12月22日))
情報システムの受託開発(一部の企画を含む)と保守運用の取引について、モデル契約と解説をまとめた資料です。民法の改正に直接関係する論点と、それ以外の論点の両方を見直しています。
法令は2026年10月21日時点の内容です。要旨は当社がまとめたもので、条文・判決・指針の全文ではありません。個別の事案への当てはめは、弁護士・社会保険労務士などの専門家にご確認ください。表記の決まりは法令・指針の参考情報と凡例をご覧ください。
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。