ベンダー評価の多くは、整った提案書と選別された参考実績に頼るために失敗します。本記事では、言語、AI活用、技術的な深さ、プロセスの透明性、チームの安定性、文化的な相性、契約の明確性という7つの基準を扱います。それぞれについて、確認すべき問い・検証方法・レッドフラグを整理します。
目次
- 標準的なベンダー評価がうまくいかない理由
- 7つの評価基準とは何か
- 7つの基準、確認すべき問い、レッドフラグ
- 実際の評価の場でこの基準をどう使うか
- ベンダー評価でよくある4つの誤り
- この基準だけでは不十分な場合
- よくあるご質問
標準的なベンダー評価がうまくいかない理由
多くのオフショア開発ベンダー評価は、国内ベンダーを評価するのと同じ方法をそのまま当てはめています。提案書を読み、参考実績に電話し、価格を比較する、というものです。この方法は3つの点で機能しません。
提案書はマーケティング資料であり、証拠ではありません。 優秀な営業チームがいれば、どの会社でも見栄えの良い提案書は作れます。本当に重要なのは契約締結後に何が起きるかであり、契約前の資料ではありません。
参考実績への電話はあらかじめ選別されています。 ベンダーが自ら提示する参考実績は、最も満足度の高いクライアントであることがほとんどです。ベンダーが自ら提示しなかった参考実績を求めることにこそ意味があります。
価格比較は本当の総コストを見落とします。 単価の安いベンダーでも、手戻りや管理工数の増加、要件の誤解によるコストを含めると、結果的に高くつくことがあります。これらは最初の見積もりには表れません。
以下の7つの基準は、標準的な評価で見落とされがちな部分を可視化するために設計されています。
7つの評価基準とは何か
7つの評価基準とは、提案書の内容をそのまま信じるのではなく、受託開発パートナーの実際の能力を検証するための構造化された質問セットです。
各基準は3つの要素から成ります。確認すべき問い、その回答を検証する方法（聞くだけでなく証拠を求めること）、そして基準を満たしていないことを示すレッドフラグの3つです。
単に能力の有無を◯×で確認する通常のチェックリストと異なり、この基準は評価者に検証を求めます。ここが最も重要な違いです。すべての質問に正しく答えられても、その回答を裏付ける証拠がなければ、その基準は満たされていないことになります。
7つの基準、確認すべき問い、レッドフラグ
基準1．言語 鵜呑みにせず検証する
問い：プロダクトを実際に作るチームは、あなたの言語で直接コミュニケーションできますか。それとも「対応可能」とは、翻訳役の担当者が1人いるという意味に過ぎませんか。
検証方法：営業チームではなく、実際にプロジェクトを担当するエンジニアとの技術的なやり取りを依頼してください。直近の技術的な意思決定について、なぜその選択をしたのか、他の選択肢がなぜ却下されたのかを本人に説明してもらいます。
レッドフラグ：「対応できる担当者がいます」という回答（翻訳層であり、直接対話ではありません）。技術的な質問がすべて営業窓口を経由しないと回答が返ってこない状態です。
基準2．AI活用能力 一部の習慣か、チーム標準か
問い：AIの活用は一部のエンジニアの個人的な習慣にとどまっていますか。それともチーム全体の標準的な運用として組み込まれていますか。
検証方法：使用している具体的なAIツールを尋ねてください。「AIを使っています」という抽象的な回答ではなく、テスト自動化やコードレビューにAIをどう組み込んでいるか、具体例を求めます。
レッドフラグ：「ドキュメント作成にChatGPTを使っています」という回答のみで、テストや設計への活用について具体的な説明がない状態です。一部のエンジニアだけが使っており、チーム標準になっていません。
基準3．技術アーキテクチャの深さ 考えられるか、実装するだけか
問い：チームにはアーキテクチャの判断を下せるシニアエンジニアがいますか。それとも、指示されたことをそのまま実装するだけの人材しかいませんか。
検証方法：実際の技術課題を1つ提示し、トレードオフを含む2〜3の異なるアプローチを提案してもらいます。これまでで最も難しかったアーキテクチャ判断について、どの選択肢を検討し、何を却下したかを尋ねます。
レッドフラグ：提案される解決策が常にこちらの初期仕様と完全に一致し、反論や代替案が一切出てきません。
基準4．プロセスの透明性 実態が見えるか
問い：品質や進捗に問題が生じたとき、それが危機になる前に把握できますか。
検証方法：スプリントの目標が未達だった場合に具体的に何をするかを尋ねます。過去のプロジェクトの実際のふりかえり記録（匿名化されたもので構いません）を見せてもらいます。
レッドフラグ：「週次で報告しています」という回答のみで、具体的な指標やふりかえりの仕組みへの言及がありません。
基準5．チームの安定性 実際に誰が担当し続けるか
問い：あなたのプロジェクトを担当するチームは、半年後、1年後も同じメンバーのままですか。
検証方法：継続中の長期案件における平均在籍期間を尋ねます（会社全体の平均ではなく）。エンジニアがプロジェクトを離れる際の引き継ぎが文書化されているかを確認します。
レッドフラグ：在籍期間についての回答が曖昧です。引き継ぎの仕組みが文書化されておらず、知識が個人の頭の中にしか存在しません。
基準6．文化的な相性 パートナーか、単なる受注者か
問い：チームは問題を積極的に報告し、改善案を提案してきますか。それとも指示を待つだけですか。
検証方法：クライアントの技術方針に同意しなかった経験と、そのときどう対応したかを尋ねます。割り当てられた範囲外の問題を発見したときにどう動くかを尋ねます。
レッドフラグ：クライアントに一度も意見したことがないと答えます。成功の定義が「期限通りの納品」のみで、事業成果への言及がありません。
基準7．契約の明確性 リスク分担は公平か
問い：何かがうまくいかなかったとき、契約条件は実効性があり、双方にとって公平ですか。
検証方法：知的財産の帰属がどう定められているかを具体的に尋ねます。マイルストーンごとの支払い方式を受け入れる意思があるかを確認します。要件の誤解に起因する手戻りコストの負担について、契約上どう定めているかを尋ねます。
レッドフラグ：知的財産の帰属が曖昧、または追加費用が必要です。マイルストーン払いの相談にどの段階でも一切応じません。リスクがすべて発注側に偏っています。
実際の評価の場でこの基準をどう使うか
この基準が最も効果を発揮するのは、実際にプロジェクトを担当する人との1回の直接対話の台本として使う場合です。営業チームに送るアンケートとしてではありません。
推奨する順序は、基準1（言語）と基準3（技術的な深さ）から始めることです。この2つは、対話の最初の15〜20分で提案書と実態のギャップを最も早く浮かび上がらせます。この2つで明確なレッドフラグが見られた場合、残り5つに進まず評価を早めに終えても構いません。
回答はその場で書き留めてください。後から記憶に頼るのではなく、対話中に記録することが重要です。複数のベンダーを同時期に比較すると、時間を空けて個別に評価するよりも違いに気づきやすくなります。
ベンダー評価でよくある4つの誤り
営業担当者としか話さず、実際のエンジニアに会わない。 結果として、すべての回答がマーケティングのフィルターを通過したものになり、実際に作業するチームの能力を反映しません。回避策として、最初の打ち合わせに担当エンジニアの同席を評価の条件としてください。
最安値を決め手にしてしまう。 結果として、手戻りや管理工数の増加を見落とし、これらは多くの場合、当初の価格差を上回ります。回避策として、価格を比較する前に基準7（契約の明確性）を使って隠れたコストリスクを見積もってください。
問いを投げるだけで、証拠を求めない。 結果として、それらしく聞こえるが検証できない回答を受け取ることになります。回避策として、各基準の「検証方法」を必ず問いとセットで実施し、問いだけで終わらせないでください。
一度評価して終わり、その後追跡しない。 結果として、評価時には良い印象だったベンダーが数ヶ月後に維持できなくなることがあります。回避策として、基準4（プロセスの透明性）と基準5（チームの安定性）を、選定時だけでなくプロジェクト期間中の定期確認にも組み込んでください。
この基準だけでは不十分な場合
7つの評価基準は弱いベンダーを見分けるのに役立ちますが、事前に知っておくべき3つの限界があります。
実際の法的レビューの代わりにはなりません。 基準7は契約について正しい問いを立てる助けになります。ただし、準拠法・裁判管轄・業界固有のコンプライアンス要件について弁護士がレビューすることの代わりにはなりません。
未経験の業界における能力までは測れません。 7つの基準すべてで良い評価を得たベンダーでも、あなたの業界（医療・金融・製造業など固有の規制がある分野）での実績が一度もない場合があります。一般的な能力から推測するのではなく、その業界における具体的な事例を求めてください。
数時間で結論を出す必要がある意思決定には向きません。 この基準が実際の価値を発揮するには、担当チームとの45〜60分の直接対話が最低限必要です。そのための時間が取れない場合、この基準は本来の効果を発揮できません。
よくあるご質問
1回の打ち合わせで7つすべてを確認する必要がありますか。 必須ではありません。基準1と3から始めてください。どちらかで明確なレッドフラグが見られた場合は、そこで評価を終えても構いません。両方とも問題がなければ、同じ場、または次回の打ち合わせで残りを確認します。
エンジニアの同席を断られ、PMのみが対応する場合、悪い兆候ですか。 基準1に照らせば、はい、注意すべきレッドフラグです。それだけで即座に除外する必要はありませんが、理由を率直に尋ね、慎重に検討したうえで判断することをお勧めします。
この基準はオフショアだけでなく、国内ベンダーにも適用できますか。 できます。7つの基準はベンダーの所在地に依存しません。「提案書は立派だが実態は違う」という問題は、国内ベンダーでもオフショアベンダーでも同様に起こり得ます。
1〜2の基準を満たさないが、他の基準は非常に良い場合はどう判断すべきですか。 基準7（リスクがすべて発注側に偏っている）における重大なレッドフラグを除き、単独の基準で自動的に除外すべきものはありません。全体を総合的に判断しつつ、そのプロジェクト固有の最大リスクに最も関係する基準を優先してください。
ベンダー選定のどの段階でこの基準を使うべきですか。 初回の提案書レビューで候補を2〜3社に絞り込んだ後です。最終的な直接面談のラウンドでこの基準を使ってください。提案書を読むだけの初期選考より時間がかかるため、最初の絞り込みには向きません。
まとめ
- 標準的なベンダー評価（提案書・参考実績・価格）は、提案書がマーケティング資料であること、参考実績が選別されていること、価格比較が総コストを見落とすことという3点で失敗しがちです。
- 7つの評価基準は、問いだけでなく検証を求めます。各基準には問い・検証方法・レッドフラグがセットになっています。
- この基準は法的レビューの代わりにはならず、業界固有の能力までは測れず、実際の直接対話の時間があって初めて価値を発揮します。
受託開発パートナーの選定を進めておられる方で、この基準を実際の対話で試してみたい場合は、VAONの無料相談にお申し込みください。私たちも、まだできていない部分を含め、この7つの基準に沿ってお答えいたします。
