開発会社を選ぶとき、最初に比べるのは「金額」と「実績数」になりがちです。しかしプロジェクトが終わったあとに聞こえてくる後悔の声は、たいていそこから来ていません。
「言ったとおりには出来ている。でも、欲しかったものとは違う」 「見積り以外の請求が、気づけば積み上がっていた」 「納品はされた。ただ、社内の誰も触れない」
いずれも、技術力が足りなかったから起きた失敗ではありません。契約する前に確認できたはずの前提が、確認されないまま進んだために起きています。
この記事では、発注を検討している経営者・事業責任者・情シス責任者の方に向けて、受託開発会社を比較する際の7つの観点、提案段階で見抜ける危険なサイン、そして発注側が自社で準備しておくべきことを整理します。特定の会社を薦めるためではなく、自社の判断基準を持つための材料としてお使いください。
なぜ受託開発は「会社選び」で決まるのか
受託開発は、完成品を買う取引ではありません。まだ形のないものを、数ヶ月かけて一緒に作る取引です。カタログから選ぶ買い物と違い、契約時点では成果物の実体が存在しません。
この性質から、失敗のパターンは驚くほど似通います。
典型的な失敗①:完成したら、イメージと違う
最も多いのがこれです。要件定義書には確かにそう書いてある。仕様どおりに動いている。しかし、事業として使えるものになっていない。
原因の多くは、発注側が言語化できていなかった前提を、受注側が確認しなかったことにあります。「管理画面が欲しい」という言葉の背後には、誰がどんな頻度で何を判断するのか、という業務の実体があります。そこを掘らずに機能一覧へ変換すると、仕様どおりで役に立たないものが出来上がります。
そして厄介なことに、このズレは動くものを見るまで発覚しません。設計書のレビューで「問題ありません」と答えた担当者が、実物を触った瞬間に「これじゃない」と気づく。これは担当者の落ち度ではなく、紙で完成形を想像することの限界です。
典型的な失敗②:追加費用が積み上がる
契約時に提示された金額と、最終的に支払った総額が大きく食い違うケースです。
追加費用そのものが悪いわけではありません。作りながら理解が深まれば、当初想定になかった要素は必ず出てきます。問題は、その追加が「仕様変更」として扱われるのか、「当然含まれるべきもの」として扱われるのか、判断する基準が契約に書かれていないことです。基準がなければ、話し合いは力関係で決まります。
典型的な失敗③:納品後に、自社で触れない
見落とされがちですが、影響が最も長く続くのがこれです。
システムは納品された時点が完成ではなく、運用の開始点です。ところが、ソースコードの構造も、なぜその設計になったのかの背景も、開発会社の中にしか残っていない。結果として、画面の文言をひとつ直すだけでも、見積りと順番待ちが必要になる。開発会社を替えたくても替えられない状態が出来上がります。
これら3つは、いずれも開発が始まってから対処するには遅すぎます。だからこそ、会社選びの段階で確認しておく価値があります。
比較すべき7つの観点
以下の7つは、複数社を比較する際にそのまま質問項目として使えるように整理しました。相見積りを取る際、各社に同じ質問をしてみてください。回答の内容以上に、回答の具体性に差が出ます。
観点1:要件が固まる前から入れるか(上流)
最初の分岐点です。開発会社には大きく分けて、固まった要件を受け取って作る会社と、要件を固めるところから関与する会社があります。
どちらが優れているという話ではありません。社内に要件定義できる人材がいて、仕様が明確なら、前者のほうが速く安く済みます。問題は、自社がどちらの状態にあるかを見誤ることです。
確認したい質問は次のとおりです。
- 要件が固まっていない段階から相談できますか
- その場合、最初の数週間で何を成果物として出しますか
- RFP(提案依頼書)がないと提案できませんか
「RFPをご用意ください」と返ってくる場合、その会社は要件定義を発注側の責任範囲と考えています。社内に要件をまとめられる人がいるなら問題ありません。いないなら、RFPを書くこと自体が最初の難関になります。
参考までに、当社(サービス内容)はRFPを前提とせず、事業側の言葉を要件・設計・スコープへ翻訳する工程から入る形をとっています。これは「上流から入る会社」の一例として捉えてください。重要なのは当社を選ぶことではなく、自社に必要なのがどちらのタイプかを判断することです。
観点2:誰が実際に手を動かすか(体制)
提案書に載っている人と、実際にコードを書く人が同じとは限りません。
一般に、開発業界には多層の下請け構造が存在します。元請けが受注し、二次請け・三次請けへ流れる形です。この構造自体が悪いわけではなく、大規模案件では合理的な面もあります。ただし発注側として認識しておくべきなのは、層が増えるほど、伝言の精度が落ち、単価に対する実作業者の取り分が減るという事実です。
確認したい質問は次のとおりです。
- 実際に開発するのは、御社の社員ですか、パートナー企業ですか
- 提案書の体制図に載っている方は、稼働率何%でこの案件に入りますか
- 開発期間中、私たちは実装担当者と直接話せますか
3つ目が特に有効です。発注側と実装者のあいだに何層あるかが、この質問への反応で見えます。
観点3:進め方 — ウォーターフォールか、週次で動くものを見るか
失敗①(イメージと違う)を防げるかどうかは、ほぼこの観点で決まります。
要件定義→設計→実装→テストと順に進み、終盤まで動くものが出てこない進め方は、認識のズレが発覚するタイミングが最も遅くなる構造を持っています。一方、短い周期で動くものを確認しながら進める方式なら、ズレは早期に、まだ修正が安い段階で見つかります。
確認したい質問は次のとおりです。
- 私たちが最初に「動くもの」を触れるのは、契約から何週間後ですか
- 進捗確認は、資料ベースですか、実物ベースですか
- 途中で優先順位を変えたい場合、どう扱われますか
1つ目への答えが「3ヶ月後」なら、3ヶ月分のリスクを紙の上で背負うことになります。当社が毎週の定例デモという形をとっているのも、この期間を1週間まで縮めるためです。
なお、アジャイル的な進め方は万能ではありません。発注側が毎週1時間を確実に確保できることが前提になります。この時間を出せないなら、その進め方を選んでも機能しません。
観点4:契約 — 請負か準委任か、検収基準は何か
非エンジニアの方にとって最も分かりにくく、そして最も重要な観点です。
一般に、開発の契約形態は大きく2つに分かれます。請負契約は成果物の完成に対して責任を負う形、準委任契約は業務の遂行に対して責任を負う形です。上流の調査や技術支援は準委任、実装は請負、という使い分けもよく見られます。
どちらであっても、確認すべきは同じ一点です。
何をもって「完成」とし、何をもって支払いが発生するのか。それは契約書に書かれているか。
これが曖昧なまま進むと、失敗②(追加費用)が起きます。確認したい質問は次のとおりです。
- 契約形態は請負ですか、準委任ですか。なぜその形ですか
- 検収基準は、契約前に文書で合意できますか
- 検収基準を満たさなかった場合、どうなりますか
- 仕様変更と追加開発の線引きは、誰がどう判断しますか
3つ目に対して明確に答えられる会社は多くありません。当社は成果報酬制、すなわち事前に合意した検収基準を満たした成果にのみ請求が発生する形をとっています(適用範囲は個別契約で定めます)。これも一つの答え方であって、唯一の正解ではありません。基準が事前に文書化されているかどうかが本質です。
観点5:見積りの構造 — 一括か、段階か
「全部でいくらですか」という質問に、初回相談の場で即答できる会社は、実は注意が必要です。まだ要件が固まっていない段階で総額を出すには、リスク分を上乗せするか、スコープを都合よく狭く解釈するかのどちらかしかないためです。
一般的な選択肢は2つあります。
一括見積りは、総額が最初に確定するため予算を通しやすい形です。一方で、不確実性が高い案件ではバッファが厚くなりがちで、途中でスコープが変わると再交渉が必要になります。
段階見積りは、フェーズごとに区切って見積る形です。総額が読みにくい代わりに、各段階の終わりで継続・中止・方針転換を判断できます。当社の場合はディスカバリー(1〜2週)→PoC(4〜6週)→要件定義(4〜8週)→開発(3〜6ヶ月)→内製化支援、という区切り方をしています。
要件が固まっているなら一括、不確実性が高いなら段階、というのが一般的な考え方です。確認したい質問は次のとおりです。
- この見積りに含まれないものは何ですか(この質問が最も効きます)
- 段階を区切る場合、途中でやめる判断はどの時点でできますか
- 保守・運用費は月額いくらで、何が含まれますか
費用の相場観と内訳については論点が多いため、稿を改めて扱います。
観点6:実績の開示粒度 — 数値まで出せるか
実績ページに並ぶロゴの数は、自社の案件がうまくいく確率を何も保証しません。見るべきは数ではなく、開示の粒度です。
守秘義務があるため、企業名を出せないケースは当然あります。ですから企業名の有無は判断材料になりません。判断材料になるのは、「何を、どこまで、どう改善したか」を具体的な数値で語れるかです。
確認したい質問は次のとおりです。
- 私たちと似た規模・業種の案件で、期間と体制はどうでしたか
- その案件で、うまくいかなかった点は何ですか
- 結果を数値で説明できますか
2つ目が効きます。失敗を語れる会社は、失敗を認識して次に活かしているからです。全ての案件が順調だったと答える会社より、率直に課題を挙げる会社のほうが、実務では信頼できます。
当社の実績ページでは、たとえば製造業の業務統合案件で業務ロジックを42から8へ集約し、月次集計を4日から1.3日へ短縮した、といった粒度で公開しています(スピンオフ元である衣株式会社の受託開発事業での支援実績を含みます)。この粒度で聞けるかどうかを、各社に試してみてください。
観点7:納品後 — 運用・内製化・「卒業」の設計
最後の観点であり、長期的には最も効いてきます。失敗③(自社で触れない)を防げるかどうかがここで決まります。
開発会社にとって、保守運用を長く任され続けることは収益の安定を意味します。つまり、発注側が自走できるようになることは、受注側にとって短期的には利益にならないという構造が存在します。この構造を理解したうえで、どういうスタンスかを確認する価値があります。
確認したい質問は次のとおりです。
- ドキュメントとソースコードの権利は、最終的にどちらに帰属しますか
- 私たちの社内エンジニアが引き継ぐ場合、何が必要ですか
- 御社との契約を終了する場合、どう移行しますか
- 内製化を支援する契約メニューはありますか
4つ目に前向きに答えられるかどうかは、一つの試金石です。当社が内製化支援をフェーズとして持ち、「卒業」を設計に含めているのも同じ考え方によります。結果として2案件目以降の継続率は72%ですが(衣株式会社の受託開発事業実績)、これは離れられないから続いているのではなく、選び直した結果として続いているという意味だと捉えています。
提案段階で見抜ける、危険なサイン
7つの観点を質問にして各社に投げると、答え方に差が出ます。ここでは、注意して確認したほうがよいサインを挙げます。いずれもそれ単体で失格を意味するものではなく、追加で質問すべき合図として捉えてください。
「まずRFPをご用意ください」の一点張り
要件を固める工程を発注側の責任と考えている合図です。社内に要件定義ができる人がいれば問題ありません。いない場合、RFPを書くために別のコンサルティング費用が必要になることがあります。
提案書が機能一覧だけで構成されている
「ログイン機能」「管理画面」「CSV出力」と並ぶだけで、なぜその機能が必要なのかという事業上の理由が書かれていない場合、事業ではなく仕様を受け取っただけの可能性があります。事業目的の理解度は、提案書の前半部分に表れます。
体制図が「PM1名+パートナー数名」
実装を外部に委ねる前提の体制です。悪いとは限りませんが、観点2の質問(直接話せるか、稼働率は何%か)で具体性を確認してください。
初回相談で総額を即答する
要件が固まっていない段階での総額提示は、バッファを厚く積むか、スコープを狭く解釈しているかのどちらかです。「この見積りに含まれないものは何ですか」と必ず聞いてください。
「弊社にお任せいただければ大丈夫です」
安心感のある言葉ですが、裏を返せば発注側の関与を求めていないということです。関与しなければ、認識のズレを修正する機会も失われます。良い開発会社ほど、発注側に時間の確保を求めます。
他社批判が提案の中心にある
自社の価値を自社の言葉で説明できていない合図です。比較の話は事実ベースで足りるはずです。
検収基準の話を避ける
観点4で触れたとおり、ここが曖昧なまま契約すると、後の交渉は力関係で決まります。契約前に文書で合意できるかを確認してください。
発注前に、自社で準備すべき3つ
ここまでは開発会社を見る話でした。しかし実務では、発注側の準備不足がプロジェクトを難しくしているケースが少なくありません。要件が固まっている必要はありませんが、次の3つは事前に決めておく価値があります。
①意思決定者を1人に決める
最も重要です。開発中は「どちらの案で進めるか」という判断が毎週発生します。このとき決裁ルートが曖昧だと、判断のたびに社内調整が入り、進行が止まります。
必要なのは、その場で判断できる人を1人決めておくことです。全社的な合意が必要な論点だけを上位へ上げる形にすれば、大半の判断はその場で完結します。役職の高さより、事業の目的を理解していて、即断できることが重要です。
②毎週1時間を、確実に空ける
観点3で触れたとおり、短い周期で動くものを確認する進め方は、発注側の時間確保が前提になります。
この1時間は、進捗報告を聞く時間ではありません。実物を触り、違和感を言葉にする時間です。ここで出る「なんとなく使いにくい」という感想が、最も価値のあるフィードバックになります。逆にこの時間を確保できないなら、進め方そのものを見直したほうが誠実です。
③現場のヒアリング先を確保する
業務システムでは特に重要です。実際にその業務を毎日やっている人に話を聞けないと、机上の理解で設計することになります。
事前に、誰に何時間もらえるかの目処を立てておいてください。「現場が忙しいので後で」となった案件は、たいてい後になっても時間が取れず、結果として現場が使わないシステムが出来上がります。
選定プロセスの現実的な進め方
最後に、実際にどう進めるかです。
候補は2〜3社に絞る
5社も6社も比較すると、各社への説明コストだけで疲弊します。2〜3社に絞り、その代わり1社あたりの対話を深くするほうが、判断材料は多く得られます。
候補の集め方には、開発会社に直接問い合わせる方法と、マッチングサイトを利用する方法があります。発注ナビ、システム幹事、アイミツといったサービスは、条件を伝えると複数社を紹介してくれる仕組みで、候補を効率的に集められる点が利点です。一方、直接問い合わせる場合は、その会社の一次情報(サイトの書き方、実績の粒度、返信の速さ)を自分で確認できます。どちらが優れているという話ではなく、集める段階と見極める段階を分けて考えるとよいでしょう。紹介経由であっても、7つの観点を自分で確認する工程は省略できません。
同じ質問を、同じ順番で聞く
比較を成立させるには条件を揃える必要があります。7つの観点をそのまま質問リストにして、各社に同じ順番で聞いてください。回答の内容だけでなく、答えられなかった質問がどれかを記録すると、差がはっきり見えます。
小さく試してから、本契約に進む
いきなり大型の開発契約を結ぶ必要はありません。一般に、短期間・小額のフェーズを先に設けて、実際の仕事ぶりを見てから本開発へ進む形が取られます。1〜2週間の調査フェーズや、数週間のPoC(概念実証)がこれにあたります。
この期間で見るのは成果物だけではありません。質問の質、レスポンスの速さ、認識がズレたときの修正の早さといった、提案書からは読み取れない要素が確認できます。相性の悪さが分かった場合も、損失は小さく済みます。
決め手は「一番安い」ではなく「一番ズレが小さい」
見積り金額に差があるとき、その差は多くの場合、含まれているスコープの差です。安い見積りは、要件定義や運用移行が含まれていないだけかもしれません。「この見積りに含まれないものは何ですか」を全社に聞いて条件を揃えたうえで、初めて金額を比較してください。
まとめ
受託開発の会社選びは、7つの観点に集約できます。
- 上流 — 要件が固まる前から相談できるか
- 体制 — 実際に手を動かすのは誰か
- 進め方 — 動くものを最初に触れるのは何週間後か
- 契約 — 検収基準は契約前に文書で合意できるか
- 見積り — 一括か段階か。含まれないものは何か
- 実績 — 数値の粒度で語れるか。失敗も語れるか
- 納品後 — 内製化と「卒業」が設計に入っているか
そして、これら全ての前提として、自社側で意思決定者を決め、毎週1時間を確保し、現場のヒアリング先を用意すること。この3つが揃っていれば、どの会社を選んでも成功率は上がります。逆にこれが欠けていると、どんなに良い会社を選んでも難航します。
最も避けたいのは、金額と実績数だけで決めてしまうことです。この記事の質問リストを持って2〜3社と話せば、その差は必ず見えてきます。
ご相談について
比較検討の途中段階でも、まだ何から手をつけるべきか決まっていない段階でも構いません。RFPも、固まった要件も必要ありません。「この7つの観点で、自社は今どこが弱いか」という壁打ちだけでも有効です。お問い合わせフォームからご連絡いただければ、原則2営業日以内にご返信します。
