開発会社の選び方 ── 実績の件数より、聞くと差が出る5つの質問

「開発会社 選び方」で検索すると、実績を確認しましょう、コミュニケーションの取りやすさを見ましょう、と書いてあります。間違ってはいないのですが、これで判断できた人はいないと思います。実績はどこの会社も並べているし、コミュニケーションが取りにくいと自分で言う会社はありません。

私たちは受注する側なので、相見積もりで比較される立場です。その中で「この質問をされると差が出るな」と感じることがいくつかあります。それを含めて、選ぶ手順として書いてみます。

まず、どのタイプに頼むかを決める

開発会社は規模で性格が変わります。優劣ではなく、得意な案件の大きさが違います。ここを決めずに相見積もりを取ると、金額が3倍違う見積もりが並んで、何を比べているのか分からなくなります。

タイプ	体制	金額帯の目安	向いている案件
大手SIer・システム開発会社	営業・PM・設計・開発・テストで分業。下請けを含む	1,000万円〜	基幹システム、既存システムとの連携が多いもの、長期の保守が要るもの
中堅の受託開発会社	PM＋エンジニア数名のチーム	300万〜1,000万円	業務システム、自社サービスの本開発
小規模チーム・個人	相談した相手がそのまま作る	50万〜300万円	最初の1本、業務の一部を置き換えるもの、試してから広げたいもの
ノーコード制作会社	既製サービスの設定・構築	数十万円〜	要件が既製品の枠に収まるもの

大手に小さい案件を持ち込むと、金額が合わないだけでなく、担当者の熱量も合いません。逆に小規模チームに全社の基幹システムを頼むと、体制が持ちません。自社の案件がどこに入るかを決めてから、その中で3社ほど並べるのが現実的です。

どの規模になるか分からない、という場合は、画面の数を数えてみてください。10画面前後で収まるなら小規模チームの領域です。数え方は業務システムの開発費用を、自分で見積もる方法に手順を書きました。

実績は、件数ではなく近さを見る

実績ページに並んでいるロゴの数は、判断材料としてはあまり使えません。見るのは次の2つです。

ひとつは規模の近さです。自社が10画面のものを作りたいときに、100画面の基幹システムの実績を見ても、その会社がこの規模を丁寧に扱えるかは分かりません。むしろ大きい案件ばかりの会社は、小さい案件を持て余すことがあります。

もうひとつは中身が書いてあるかです。「業務効率化システムを開発しました」だけの実績は、何も言っていないのと同じです。どんな困りごとがあって、何画面で、何を作らなかったか。そこまで書いてある実績が1件でもあれば、その会社の考え方が分かります。

実績を出せない会社もあります。守秘義務がある業界では普通のことなので、それ自体は問題ありません。「どこまでなら話せますか」と聞いてみてください。線引きの説明が丁寧なら、自社の情報も同じように扱ってもらえます。

ちなみに私たちは、実際の顧客事例を公開する代わりに、作れるものの例として架空の想定例を画面単位で公開しています。実績が少ないうちに実績風の表現をするより、構成そのものを見てもらうほうが正確だと考えたためです。

見積もりは、1年目の総額で並べる

相見積もりを取ると、表示されている金額を横に並べたくなります。ここで3つ、注意する点があります。

範囲が揃っているか。 A社の300万円とB社の500万円が、同じものを指しているとは限りません。要件定義が含まれているか、テストはどこまでやるか、データ移行はあるか。同じ説明をしたつもりでも、見積もりに入る範囲は会社ごとに違います。

内訳の粒度が揃っているか。 「システム開発一式 300万円」では、何が入っているか確認しようがありません。画面単位、機能単位、あるいは工程単位で分かれているものを出してもらってください。粒度の細かい見積もりを出せること自体が、範囲を把握できている証拠になります。

1年目の総額になっているか。 初期費用だけを比べると順位が逆転します。サーバー代、保守費、外部サービスの利用料、リリース後の修正費を足して、12ヶ月でいくらかを出してください。内製と外注を含めた並べ方は社内システムは内製か外注かに、1年の総額で比較した表があります。

聞くと差が出る5つの質問

ここからが本題です。打ち合わせでこの5つを聞くと、資料からは分からないことが出てきます。

1. この画面は、だいたい何時間くらいですか。
即答できる会社は、自分たちの手を動かす速さを把握しています。「持ち帰って見積もります」が毎回続く場合、実際に作る人と話していない可能性があります。

2. 今回、作らないほうがいい機能はありますか。
発注側が挙げた機能を全部「できます」と返す会社は、範囲を判断していません。予算と期間の中で優先順位をつけるのは受注側の仕事です。1つでも「それは後回しでいいと思います」が出てくるかを見てください。

3. 途中で仕様が変わったら、どうなりますか。
「追加見積もりになります」でも構いません。問題は、どのくらいの変更から追加になるのかの線が説明できるかです。線が引けていないと、あとで「これは追加です」「聞いていません」になります。契約の型によっても扱いが変わるので、システム開発の契約書で、発注側が読むべき5つの場所もあわせて見てください。

4. リリースしたあと、誰が対応しますか。
作った本人が続けて見るのか、保守の部署に引き継がれるのか。引き継がれる場合、引き継ぎの資料は誰が書くのか。ここが曖昧なまま始まると、リリース直後に急に話が通じなくなります。

5. ソースコードは、どこに置きますか。
自社のアカウントに置いてもらえるか、少なくとも読み取り権限をもらえるか。関係が終わったときに取り出せるかどうかの話です。嫌がる理由がある会社は、その理由を聞いてください。

断る前提で会ってよい

最後に、発注側の方に一番お伝えしたいことです。相談したら発注しなければならない、と思わなくて構いません。

私たちの場合、初回のお打ち合わせから画面構成のラフと見積もりの提出まで無料で行っています。ラフを見て「やっぱりやめます」も、「この内容なら社内でできそうです」も、普通のことです。ラフが手元に残れば、他社に相談するときの説明もしやすくなります。

複数社と話すと、同じ相談に対する反応の違いがはっきり出ます。全部できますと言う会社、範囲を削ってくる会社、そもそも作らないほうがいいと言う会社。その違いこそが、比較したかったものだと思います。

話す前に自社側で決めておくと精度が上がることは開発会社に相談する前に、決めておくと話が早い3つのことに、こちらの料金の考え方は料金のページにまとめています。