技術が分からない発注側でもできる外注先の見極め方（最低限の質問集）

なぜ「見極め」が難しいのか：発注側がハマる典型パターン

開発を外注する場面で、発注側に技術が分からないのは珍しくありません。問題は、分からないこと自体ではなく、分からないまま意思決定しなければならない状況にあります。相見積もりを取っても、提案書に書かれているのは専門用語や「できます」の連続で、何を根拠に判断すればよいかが見えにくい。結果として「一番安い」「一番早い」「話しやすい」だけで選び、後から炎上するのがよくある流れです。

よくある失敗は大きく3つです。1つ目は、要件が曖昧なまま開発を始めてしまい、途中で「想定と違う」が連発して追加費用が膨らむケース。2つ目は、スケジュールが楽観的すぎて遅延し、社内の関係者調整も含めて疲弊するケース。3つ目は、納品後の運用・保守が置き去りになり、担当者が替わった瞬間に触れなくなるケースです。

ここで重要なのは、発注側が技術者にならなくても、外注先の「考え方」「進め方」「リスクの捉え方」は質問で見抜けるという点です。この記事は、専門知識がない状態でも、外注先（開発会社・制作会社・フリーランスを含む）を見極めるための最低限の質問集を、実務の判断に落とし込んで整理します。

見極めの前に決める「発注側の軸」：これがないと良い会社でも失敗する

外注先の良し悪し以前に、発注側が「何を成功とするか」を言語化できていないと、どれだけ腕の良いチームでも期待値がズレます。最初に固めたいのは、技術仕様ではなくビジネス側の軸です。具体的には「目的」「対象ユーザー」「いつまでに」「どこまでやるか（範囲）」「予算」「運用体制」の6点です。

例えば「業務効率化システムが欲しい」という依頼でも、目的が「残業削減」なのか「入力ミス削減」なのかで最適解は変わります。対象ユーザーが現場スタッフ中心なら、操作性が最優先で、機能を絞る判断も必要です。逆に管理者中心なら、権限管理やログ設計が肝になります。外注先を選ぶ前に、社内で最低限の意思決定を済ませることが、後のトラブルを大幅に減らします。

また、「どこまで外注し、どこから社内がやるか」も重要です。要件定義から丸投げしたいのか、仕様は社内で決めるのか。運用保守や改善開発まで継続して頼みたいのか。ここが曖昧だと、提案の前提がバラバラになり比較不能になります。提案依頼（RFP）の形式は凝っていなくて構いませんが、少なくとも以下は文章にしてください。

• 背景（なぜ今やるのか）
• 現状の業務フローと課題（ざっくりでOK）
• やりたいこと（必須・できれば・不要に分ける）
• 期限・予算感・社内の決裁プロセス
• 既存システムや利用ツール（Excel、kintone、基幹など）

この準備があるだけで、外注先の提案品質が上がり、見極めの質問も通りやすくなります。

最低限の質問集：提案・見積もり段階で聞くべきこと（回答の見方付き）

ここからが本題です。技術が分からなくても、外注先の力量は「質問への答え方」で判断できます。ポイントは、結論→理由→リスク→代替案の順に説明できるかどうか。以下の質問を、提案依頼時や初回打ち合わせでそのまま使ってください。

目的と要件の確認に関する質問

• 「この案件の目的は何だと理解していますか？」
  良い回答：残業削減、入力ミス削減など目的を具体に言い、KPI候補まで触れる。
  注意：機能の話しか出ない（「予約機能を作ります」など）。
• 「必須要件と、後回しにできる要件をどう整理しますか？」
  良い回答：優先度付けの方法（MoSCoW等）や、MVP（最小構成）で段階導入する提案。
  注意：全部やりましょう、の一択。
• 「要件が曖昧な部分は、どうやって決めていきますか？」
  良い回答：ヒアリング、画面モック、業務フロー整理、プロトタイプで合意形成する流れ。
  注意：作りながら決めましょう（追加費用の話がない）。

見積もりの透明性に関する質問

• 「見積もりの内訳を、工程ごとに説明できますか？」
  良い回答：要件定義、設計、実装、テスト、PM、運用引継ぎなどが分かれている。
  注意：一式見積もりのみで根拠が弱い。
• 「見積もりが増える条件は何ですか？逆に増えない範囲は？」
  良い回答：変更管理（追加要望の扱い）を明確化し、例を挙げて説明。
  注意：やってみないと分からない、の連発。
• 「相見積もりで価格差が出た場合、何が原因になりやすいですか？」
  良い回答：品質、体制、テスト範囲、運用対応、セキュリティなど比較観点を提示。
  注意：他社を貶すだけで自社の前提を語らない。

進行管理・品質に関する質問

• 「スケジュール遅延が起きやすいポイントと、予防策は？」
  良い回答：要件確定の遅れ、レビュー滞留、外部連携の不確実性等を挙げ、バッファ設計を説明。
  注意：遅れません、と断言する。
• 「品質は何で担保しますか？テストは誰が何をしますか？」
  良い回答：テスト計画、レビュー、受入テスト（UAT）支援、品質基準を説明。
  注意：テストはします、以上がない。
• 「仕様変更はどう管理しますか？」
  良い回答：変更申請→影響範囲→見積→合意→実施、のプロセスがある。
  注意：柔軟に対応します（運用がない）。

運用・保守・引継ぎに関する質問

• 「リリース後の保守はどういうメニューですか？」
  良い回答：監視、障害対応SLA、軽微改修、問い合わせ窓口、月次レポート等が明確。
  注意：納品して終わり、または曖昧。
• 「ドキュメントは何を残しますか？誰が読める粒度ですか？」
  良い回答：運用手順、画面仕様、データ項目、権限、障害時手順など。非エンジニア向けも用意。
  注意：コードがあるから大丈夫、の発想。
• 「担当者が変わっても運用できるように、何をしますか？」
  良い回答：引継ぎ会、操作教育、FAQ、権限設計、ログの見方まで提案。
  注意：属人的な前提。

これらの質問に対し、良い外注先ほど「分かりやすい言葉」で、リスクも含めて説明します。逆に、質問を嫌がる、論点をずらす、結論が出ない場合は要注意です。

「技術が分からない」発注側でもチェックできる成果物とプロセス

外注先の実力は、コードの巧拙だけでなく、途中で出てくる成果物（ドキュメントやデモ）に表れます。発注側は技術レビューができなくても、合意形成の材料が揃っているかを確認できます。以下は、プロジェクトで最低限出てくるべきものです（規模により簡略化は可）。

• 要件の整理資料（要望を「決定事項」と「未決事項」に分けている）
• 業務フロー図（現状とToBe、どこが改善されるかが見える）
• 画面イメージ（ワイヤーフレーム・モック・プロトタイプ）
• スコープ（やること/やらないことが書かれている）
• 受入条件（何ができたらOKか、確認方法は何か）

特に重要なのが受入条件です。「ログインできる」「CSVを出せる」といった機能要件だけでなく、「月末処理が30分で終わる」「入力エラーがこの画面で検知される」など、業務に落ちる条件があると揉めにくくなります。受入条件がない開発は、完成の定義がない開発になりがちです。

また、コミュニケーション設計も品質に直結します。週次定例の有無、議事録の提供、課題管理（Backlogやスプレッドシートでも可）、決裁者の参加頻度などを最初に決めましょう。発注側が忙しいほど「丸投げしたい」となりますが、意思決定だけは発注側が行う必要があります。外注先に任せるのは実装であって、事業判断そのものではありません。

危ない外注先のサイン：安さや営業トークよりも重視すべきこと

見極めで迷ったときは、危険サインを知っておくと判断が早くなります。以下は、過去の炎上案件で頻出のパターンです。1つでも即NGとは限りませんが、複数当てはまる場合は慎重に。

• 質問に対して「できます」だけで、前提・制約・代替案が出ない
• 要件が固まっていないのに、固定価格・短納期を強く押す
• 見積もりにPM（進行管理）の工数がほぼ入っていない
• 担当者が変わりやすい体制で、引継ぎ方法の説明がない
• セキュリティや権限、ログなど「運用の現実」の話をしない
• 「一式」で安く見せ、後から追加で回収する前提になっている

価格についても補足します。安いこと自体が悪ではありません。ただし開発は、要件定義・設計・テスト・運用設計を削るほど短期的に安く見えます。そして削った部分のツケは、リリース後の不具合・手戻り・運用崩壊として戻ってきます。“作る費用”だけでなく“使い続ける費用”を含めて比較すると、適正な選択がしやすくなります。

さらに、発注側の心理として「自分が詳しくないから強く言えない」という遠慮が起きがちです。しかし、質問することは失礼ではありません。良い外注先ほど、むしろ質問が増えるほどプロジェクトが成功に近づくことを知っています。質問に耐えられない相手は、運用中の問い合わせにも耐えられない可能性が高いと考えてください。

初回打ち合わせでそのまま使える「質問テンプレ」と進め方

最後に、面談の場で使いやすいよう、質問を「順番」に落としたテンプレを提示します。打ち合わせ60分を想定し、発注側が主導しやすい流れにしています。議事録は必ず残し、口頭の合意を放置しないことがポイントです。

1. 背景と目的の確認：「この案件の目的は何だと理解していますか？優先順位はどうなりますか？」
2. スコープの確認：「今回“やらないこと”は何を想定しますか？段階リリースにできますか？」
3. 進め方の確認：「要件が曖昧な部分はどう決めますか？どのタイミングで何を見せてもらえますか？」
4. 体制の確認：「誰がPMで、誰が実装担当ですか？窓口は誰で、連絡手段は？」
5. 見積もりの確認：「工程ごとの内訳と、増減する条件を教えてください」
6. リスクの確認：「遅延・品質・セキュリティで想定されるリスクは？予防策は？」
7. 運用の確認：「リリース後の保守・障害対応・改善はどうなりますか？ドキュメントは何を残しますか？」
8. 次アクション：「こちらが用意すべき情報は？次回までに決めることは？」

このテンプレの狙いは、外注先の「説明力」「構造化能力」「リスク感度」を引き出すことです。特に、次回までに発注側が用意すべき情報（例：現行業務の例外パターン、帳票サンプル、権限区分、データの持ち方、関係者一覧など）を具体に言える会社は、プロジェクトの現実を理解しています。

もし複数社で迷ったら、「同じ質問」を同じ順番で投げ、回答を並べて比較してください。比較表を作ると、価格差の理由や、提案の成熟度が見えます。技術が分からない発注側でも、判断は十分可能です。

まとめ

技術が分からない発注側でも、外注先の見極めは可能です。ポイントは、コードの中身を読むことではなく、目的の理解・進め方・見積もりの透明性・リスクの説明・運用までの設計を質問で確かめることです。

• 発注前に「目的・期限・範囲・予算・運用体制」を社内で言語化する
• 提案段階で「目的の理解」「内訳」「増額条件」「品質担保」「運用」を質問する
• 受入条件や成果物（フロー・モック・スコープ）が揃うプロセスを選ぶ
• 「できます」だけの回答、楽観的すぎる納期、運用軽視は危険サイン

外注は、選定で8割が決まります。もし「何から整理すれば良いか分からない」「相見積もりの見方に自信がない」「要件定義から伴走してほしい」といった状況であれば、第三者視点での要件整理や提案比較の支援も有効です。自社の状況に合わせて、無理のない進め方を選んでください。