toBプロダクト開発の受託先・開発会社の選び方

「開発会社」で検索すると、似たようなコーポレートサイトが何十社も出てきます。実績ページはどこも綺麗で、対応領域も「要件定義〜運用保守まで一気通貫」とほぼ同じ文言が並ぶ。何を基準に選べばいいのか分からないまま、結局は紹介や知人の評判で決めてしまう——これは多くの発注者が通る道です。

しかし発注先の選び方を誤ると、要件が固まらないまま実装が進んだり、契約後に技術の相性が合わないと分かったりして、時間とお金を失います。この記事では、toBプロダクト開発を外部に頼む際に、発注者が実際に確認すべき基準を整理します。

要件整理から入れるか、丸投げ前提か

最初に確認すべきは、その会社が「要件整理を一緒にやる会社」か「要件は決まっている前提で実装だけ請け負う会社」かです。この2つは似ているようで、提供する価値がまったく違います。

• 実装だけを請け負う会社は、渡された仕様書通りに正確に作ることは得意ですが、仕様の曖昧さや矛盾を指摘してくれるとは限りません。仕様が甘いままだと、その甘さごと実装されます。
• 要件整理から入れる会社は、着手前に「何を作るべきか」「何を作らないべきか」を発注者と一緒に詰めます。手戻りは実装後半になるほど高くつくため、この工程を早い段階で挟めるかどうかは、最終的な開発コストに直結します。

自社に要件を固め切る力がある(PdMやCTOが社内にいる)なら実装専門の会社でも問題ありません。逆に要件がまだ粗い状態で発注先を探しているなら、要件整理を含めて頼める会社を優先すべきです。

技術領域の相性を確認する

「対応技術」の欄に並んでいる技術スタックの数の多さは、あまり参考になりません。確認すべきは、自社のプロダクトに近い領域の開発を実際にやったことがあるかです。

• toC向けの大量トラフィックを捌く開発と、toB向けの業務システム開発とでは、設計で重視するポイントが違う
• 既存システムとの連携(API連携・データ移行・レガシー刷新)が必要なら、その手の経験があるか
• 業界特有の制約(規制・セキュリティ要件・既存の業務フロー)を理解しているか

事例ページで社名が出ていなくても、「業界・課題・担当範囲・技術スタック」が具体的に書かれていれば、相性を判断する材料になります。torcheees の開発実績もこの考え方で構成しています。実績が抽象的な言葉(「Webシステム開発」「業務効率化」)だけで終わっている場合は、担当者に具体的な事例を直接聞いてみるのが確実です。

小さく試せるかどうか

契約形態がいきなり「要件定義〜リリースまで一括」しか用意されていない会社は要注意です。最初の関わりを小さく設計できるかどうかは、その会社が発注者のリスクを理解しているかの試金石になります。

• 数週間の要件整理・診断フェーズを単体で発注できるか
• 最初のフェーズの成果物(要件定義書・技術構成案・見積もり)を受け取った上で、続けるかどうかを発注者が判断できるか
• 「小さく始めて、合わなければ切れる」設計になっているか

いきなり大きな契約を結ばせようとする会社より、小さく試す入口を用意している会社の方が、双方にとってリスクが低い選び方です。実際に手を動かしてもらってからでないと、コミュニケーションの相性や仕事の進め方の相性は分かりません。

コミュニケーションの取り方を見る

技術力と同じくらい重要なのが、開発期間中どれくらいの頻度でどんな形のコミュニケーションを取るかです。契約前の商談段階で、次を確認してください。

• 進捗報告の頻度と形式(週次で動くものを見せてもらえるか、月末にまとめて報告されるだけか)
• 窓口になる担当者が固定されているか、案件ごとに変わるか
• 仕様変更や追加要望が出たときの対応フロー(都度見積もりか、一定範囲は柔軟に吸収するか)

これらは契約書には書かれないことが多いですが、実際のプロジェクトの満足度を大きく左右します。商談の場での受け答えのスピードや具体性は、契約後の対応の縮図と考えて差し支えありません。

実績の見方 — 「何を作ったか」より「何を担当したか」

実績ページを見るときに陥りやすい誤りは、成果物の見た目だけで判断することです。確認すべきは次の点です。

• 要件定義から関わったのか、デザイン・仕様が固まった状態から実装だけ担当したのか
• リリース後の運用・改善まで伴走したのか、納品して終わりだったのか
• チーム体制(何人でどれくらいの期間か)は自社の規模・予算感と合っているか

同じ「ECサイト構築実績」でも、担当範囲によって発注者が得られる価値は大きく異なります。会社概要にある会社情報や代表者の経歴も、どういう案件を得意としてきたかを推測する材料になります。

相見積もりの取り方

相見積もりは「安いところを選ぶため」ではなく、相場観と提案の質を比較するために取るものです。取り方を間違えると、かえって判断を誤ります。

• 同じ粒度の要件を渡す。会社によって粗さの違う要件を渡すと、見積もりの前提が揃わず比較にならない
• 見積もりの内訳を必ず確認する。金額だけでなく、どの工程にどれだけの工数を見ているかを見れば、その会社が何を重視しているかが分かる
• 3社前後が目安。多すぎると各社への説明コストがかさみ、かえって要件整理が疎かになる
• 最安値だけで決めない。極端に安い見積もりは、要件の見落とし・後からの追加請求・品質の作り込み不足のいずれかを疑う

価格だけで選ぶ危険は、契約後に顕在化します。要件の解釈違いによる手戻り、追加費用の発生、サポート体制の薄さなど、見積もり時点では見えないコストが後から積み上がることが少なくありません。総額ではなく、その金額で何をどこまでやってくれるかを比較することが重要です。

契約形態の柔軟性

請負(成果物に対して支払う)と準委任(稼働時間に対して支払う)のどちらが適切かは、プロジェクトの性質によって変わります。

• 要件が固まっている・成果物が明確に定義できる場合は請負が向いている
• 要件が変化しやすい・アジャイルに進めたい場合は準委任の方が実態に合う
• 両方に対応できる会社の方が、プロジェクトの性質に応じて適切な契約形態を提案してくれる可能性が高い

契約形態を一種類しか用意していない会社は、それがプロジェクトに合わない場合でも無理にその形式に当てはめようとすることがあります。

まとめ

• 要件整理から一緒にやれるかを最初に見極める。丸投げ前提の会社に粗い要件を渡すと、その粗さごと実装される。
• 技術領域の相性と実績の担当範囲を具体的に確認する。実績の見た目より「何を担当したか」を聞く。
• 小さく試せる入口があるか、相見積もりの内訳まで比較したかを確認する。価格だけで選ぶと、見えないコストが契約後に顕在化する。

発注先選びで一番難しいのは、「要件がまだ固まっていない段階で、どの会社に相談すればいいか分からない」ことです。torcheees の要件整理・開発診断は、1〜4週間で、要件の言語化と技術構成案、優先順位付きの開発ロードマップまでを作成するサービスです。他社への相見積もり素材としてもそのまま使える形で作成します。発注先を決める前の材料集めとして、お問い合わせから気軽にご相談ください。