開発会社の「できます」は、どこまで本当なのか？ ― 実績の"中身"を確かめる3つの質問
いきなり結論です。開発会社の「できます」は、嘘ではありません。ただし会社によって、指している中身がまるで違います。自社に近い既製パッケージを持っているという意味の「できます」と、似た案件を最後までやり切ったという意味の「できます」と、技術的には可能という意味の「できます」。この3つは価格も期間もリスクも別物です。だから発注前に聞くべきは「できますか？」ではなく、「何をもって、できると言っていますか？」です。
はじめまして。システム開発会社でCOOをしているaki.mといいます。経歴は総務・労務と経理で、コードは書けません。だからこそ、発注する側と同じ目線で「開発の中で起きていること」を書いていこうと思っています。
そもそも、なぜどの会社も「できます」と言うのか？
以前、新規事業のシステムを検討していた方と商談をしたときのことです。その方はすでに複数社から見積もりを取っていて、こう言っていました。
「今は向こうは"大丈夫です"って、ものすごくいい返事で全部大丈夫って答えてた。でも、ダメですって言う会社いないですからね」
これ、発注者側の本音として、かなり正確だと思います。
わかります。というか、業界側の人間として認めなければいけないことなんですが、受注前の開発会社が「それはできません」と言うのは、そのまま失注を意味します。だから言わない。悪意があるわけではなく、そういう構造になっているだけです。
展示会に視察に行ったときにも、同じことを感じました。受託開発の会社のブースをいくつも回ったんですが、「開発は何でもできます」と大きく掲げているところが本当に多い。で、通路を歩いて全部見終わったあと、どこがどう違ったのか、まったく思い出せないんですよね。
社内ではこれを「魔法使い問題」と呼んでいます。何でもできる魔法使いに見せようとすると、選ぶ側からは何が得意なのか分からなくなって、結果として選ばれない。守備範囲を明示している会社のほうが、はるかに記憶に残る。
ここで、もうひとつ。
「何でもできます」には、技術的な意味のものと、もうひとつ予算的な意味のものがあります。「その予算でもできますよ」というやつです。私はむしろ、こっちのほうが要注意だと思っています。
低予算でできるというのは、営業努力だけでは成り立ちません。必ずどこかに、それを成り立たせている構造があります。
海外にオフショアで流している。
社員ではなく、その会社の下にいるフリーランスに任せている。
実績づくりのために赤字で受けている。
どれも即座に悪いというわけではありませんが、それが発注者に知らされないまま進むと、品質や継続性のリスクは発注した側に返ってきます。
でも発注する側からすると、「予算まで飲んでくれるんだ、この会社は何でもできるんだ」となりますよね。わかります。何でも受け入れてもらえる会社は、話の早い会社に見えます。
ここのリテラシーが上がるだけで、発注先の選定は格段に強くなります。安いこと自体は問題ではありません。問題は、安さの理由が見えないことです。
つまり、技術の話でも予算の話でも、「できます」「大丈夫です」という言葉そのものは、判断材料になりません。全ベンダーが言うからです。判断材料になるのは、その後ろにある中身だけです。
「できます」の中身は、会社ごとに何が違うのか？
システム発注が初めてだという経営者の方から、こんな話を聞いたことがあります。
「相場は1,000万円くらいかなと思っていたんです。でも調べていたら、その半分くらいでできるという会社もあった。実際どこが本当の金額なのか、あんまり詳しくないので分からなくて」
これは金額の話に見えて、実は「できます」の中身の話です。
同じ依頼に対して見積もりが倍近く違うとき、その差はエンジニアの単価差ではありません。
ほとんどの場合、依頼範囲（スコープ）の違いと、その業種に特化した既製パッケージを持っているかどうかの差です。
具体的には、「できます」は少なくとも3つの意味に分かれます。
1つめ。「自社に近い既製パッケージを持っている」という意味の"できます"。 これは安く速いです。実際に強い選択肢になります。ただし、自社の業務がそのパッケージに収まるかどうかが勝負で、収まらない部分のカスタマイズ費と、月々のランニング費用は別で乗ってきます。安さの内訳を聞かないと、後から総額が変わります。
2つめ。「似た案件を、最後までやり切ったことがある」という意味の"できます"。 これが一番あてになります。似ているのは技術ではなく、業務の複雑さや関係者の多さです。
3つめ。「技術的には可能」という意味の"できます"。 これも嘘ではありません。技術的にはたいていのことが可能です。ただ、この意味の「できます」は、実質「これから調べます」とほぼ同じです。それが悪いわけではなく、パイオニア的な案件ならそうなるのが当然です。問題は、発注する側がそれを1つめや2つめと区別できていないことです。
3つとも「できます」と言います。だから、区別は聞かないと分かりません。
「作り切った経験」はどうやって確かめるのか？
いま一番この見極めが難しくなっているのが、AI関連です。
うちが関わっている大手企業のAI案件で、実際に人を探していて分かったことがあります。「AIエージェントを本格的に作り切った実績のある人材」は、極端に少ないんです。多くは「良さそうだけど、まだ本格的には試していない」段階。それでも履歴書や会社紹介には「AI開発の実績あり」と書けてしまいます。
しかも、もう一段ややこしい話があります。コードが書けることと、お客さんの業務に入り込んで、要件を形にしながら1人でプロジェクトを完遂できることは、別のスキルなんです。
「エンジニアリングでいけても、1人で突っ込めるかは別」これは社内でも繰り返し出てくる話です。
だから発注側として確認すべきなのは「実績があるか」ではありません。「誰が、どこまでやったか」です。
これ、業界の中ではほとんど常識なんですが、発注する側にはまったく共有されていません。開発が失敗する最大の原因は、技術力の不足ではないんですよね。発注した時点で「誰が作るのか」が誰にも見えていないことです。
以前お話しした地方の倉庫系の事業者の方は、こう言っていました。「1人社長の属人化リスクは高い。今までは内製で済んでいたけれど、外に展開していくならシステム会社の継続性が重要になる」。まさにそこです。契約するのは会社ですが、動かすのは人です。
ここからは、もう少し細かい話をします。
どの開発会社にも、経験の浅いエンジニアから、かなり任せられるエンジニアまでがいます。ざっくり5段階に分けるとして、レベル1の人もいればレベル5の人もいる。当たり前の話です。
そして、これは開発会社の経営側の本音として正直に書きますが、会社としてはレベル1のエンジニアにも仕事を与えなければいけません。育てないと、次のレベル5が生まれないからです。発注する側の会社にも新人がいるのと、同じ構造です。
ただ、発注する立場で考えたら、どうせ同じお金を払うなら、レベル4か5の人に入ってほしいですよね。わかります。私もそう思います。
このレベル4〜5の層が何なのかというと、新しいこと──最近ならAI関連の技術を使ったプロダクトのような領域でも、自分で調査して成果まで持っていける人たちです。前例のない仕事を任せられるかどうかが、この層の境目です。
で、当たり前ですが、そういう人は市場で引っ張りだこです。だから、すぐにリソースが空いていません。
だから私からのおすすめは、これです。
確実に成功させたいなら、少し期日を遅らせてでも、その人の稼働を先に予約してしまうこと。
「今すぐ動ける人でお願いします」と言った瞬間に、選択肢は空いている人に限定されます。
プロダクトの質を求めるなら、忙しい人に頼む。これはどの業界でも鉄則だと思っています。
つまり、確認すべきは会社の実績ではなく、「誰が、いつ入るか」です。
発注前に聞くべき3つの質問は何か？
ここまでを、明日そのまま使える形にします。技術の知識はいりません。3つだけです。
質問1「この見積もりは、どこまでを含んでいますか？」
これは金額を値切るための質問ではなく、範囲を揃えるための質問です。複数社の見積もりを比べるなら、金額を比べる前にこれをやってください。
ちなみに、見積もりを何社も見ていて一番よく抜けているのは、画面設計・UI/UXの工数です。システムを作るなら避けて通れない工程なのに、入っていない見積もりが普通にあります。抜けている分は消えるわけではなく、後から出てきます。
質問2「今回、実際に手を動かすのは誰ですか？ その方は、同じような案件を最後まで担当したことがありますか？」
会社の実績ではなく、担当者の実績を聞く質問です。ここを聞かないと、大きな会社に頼んだのに担当者がくじ引きのように決まってしまう、という事故が起きます。「作る本人と直接話せるか」は、それ自体が判断軸になります。
答えにくそうにされたら、それも情報です。悪い会社という意味ではなく、まだ体制が決まっていないという意味なので、いつ決まるのかを聞けばいい。そして、その方がいつから入れるのかも必ず聞いてください。先ほど書いたとおり、良い人ほど空いていません。
質問3「うちのケースで、うまくいかない可能性があるのはどこですか？」
これが一番効く質問です。
先ほどの倉庫系の事業者の方が、こう言っていました。「メリットだけでなく、デメリットも教えてくれる会社とパートナーシップを組みたい」。発注する側は、リスクを隠されるのが一番怖いんです。
そして実務の感覚として、「やりたいことはシンプルなんです」と言われる案件ほど、要件の詰め方で品質が決まります。シンプルに見えるからこそ、どの情報を残すか、どんな形で出力するかの設計が全体を左右する。ここを一緒に心配してくれる会社は、たいてい信用できます。
結論。「できます」を疑う必要はありません。中身を聞けばいいだけです。この3つを聞くだけで、相手が1つめの「できます」なのか、3つめの「できます」なのかは、だいたい分かります。
よくある質問
Q. 同じ依頼なのに、A社とB社で見積もりが倍近く違います。どちらが本当の金額なんでしょうか？
A. どちらも本当です。差の正体は、ほぼ「依頼範囲の違い」と「その業種向けの既製パッケージを持っているかどうか」です。エンジニアの単価差で倍になることはあまりありません。まず範囲を揃えて、それでも差が残るかを見てください。
Q. 「どのツールや基盤でやるのがいいですか？」と聞いたとき、何を見ればいいですか？
A. 提案そのものより、選んだ理由を見てください。業務のどこが標準機能で足りて、どこが独自に作る必要があるのか。将来どこまで拡張する想定なのか。この2点に触れずに製品名だけが返ってくる場合は、まだ業務を理解していないサインです。
Q. 開発会社がいなくなったり、担当者が辞めたりしても、システムは引き継げますか？
A. 引き継げるかどうかは、契約時にほぼ決まります。ソースコードを受け取れること、設計や仕様の資料が残ること、成果物の権利が自社に帰属すること。この3点を最初に確認しておけば、引き継ぎのハードルは大きく下がります。契約後に交渉するのは難しいので、発注前に聞いてください。
最後に少しだけ宣伝です。
私たちテックビーンズでは、契約の前に無料で動くプロトタイプを作れる「ゼロスタート」というサービスをやっています。「どの開発会社に頼めばいいのか、判断する材料がない」──そんな段階の方こそ、提案書を並べて比べるより、一度"形になるもの"を見て判断するのが早いと思っています。誰が作るのかも、どこまでできるのかも、実物が出てくれば分かります。話を聞くだけでも、辞退していただいても大丈夫です。
→ ゼロスタート（無料プロトタイプ作成）の詳細はこちら
筆者：aki.m 株式会社テックビーンズ COO。総務・労務・経理出身の非エンジニア。システム開発を「発注する側と同じ目線」で書いています。契約前に無料で動くプロトタイプを試せる開発サービス「ゼロスタート」を運営中。
