オフショア開発会社の選び方完全ガイド2025｜失敗しないパートナー選定の50のチェックポイント【RFPテンプレート付き】

「オフショア開発会社が多すぎて、どこを選べば良いかわからない」「見積もりを比較しても、何を基準に判断すれば良いのか」「失敗したくないが、何をチェックすれば良いのか」

ベトナムだけでも1,000社以上のオフショア開発会社が存在する中、適切なパートナーを選ぶことは、プロジェクト成功の最も重要な要素です。情報処理推進機構（IPA）の「オフショア開発実態調査2024」によると、プロジェクトの成否の67%はパートナー選定の段階で決まると報告されています。

しかし、多くの企業が「価格の安さ」や「営業担当の印象」といった表面的な要素で判断してしまい、プロジェクト開始後に深刻な問題に直面しています。適切な評価基準がないまま発注先を決めてしまうと、コミュニケーション問題、品質問題、納期遅延など、取り返しのつかない事態を招きかねません。

本記事では、100社以上のオフショア開発プロジェクトの成功事例と失敗事例を分析し、実務で即使える50の具体的チェックポイントを提供します。さらに、提案依頼書（RFP）のテンプレート、参照先企業へのヒアリング質問集、定量評価のためのスコアリングシートなど、実践的なツールも完備。

この記事を読めば、あなたのプロジェクトに最適なオフショア開発会社を、自信を持って選定できるようになります。

この記事で分かること：

• 選定プロセスの全体像（5つのステップ）
• 段階別の具体的チェックポイント50項目
• 実際に使えるRFP（提案依頼書）テンプレート
• 参照先企業へのヒアリング質問集20問
• 定量評価のためのスコアリングシート
• 契約前に確認すべき10の重要ポイント
• 失敗事例から学ぶ教訓

---

1. オフショア開発会社選定の全体プロセス

適切なパートナー選定には、体系的なプロセスが不可欠です。以下の5段階のプロセスを踏むことで、失敗のリスクを最小限に抑えることができます。

選定プロセスの全体像

フェーズ1：準備段階（1-2週間）

• 自社要件の明確化
• 選定基準の設定
• RFP（提案依頼書）の作成
• 候補企業のリストアップ

フェーズ2：初期スクリーニング（1週間）

• 公開情報の収集
• 基本要件の確認
• 候補企業の絞り込み（10社→5社程度）

フェーズ3：提案依頼と評価（2-3週間）

• RFPの送付
• 提案書の受領
• 提案内容の評価
• 候補の絞り込み（5社→3社程度）

フェーズ4：詳細評価（2-3週間）

• 対面またはオンライン面談
• 可能であれば現地訪問
• 参照先企業へのヒアリング
• 最終候補の選定（3社→1-2社）

フェーズ5：最終判断と契約（1-2週間）

• トライアルプロジェクトの実施（推奨）
• 契約条件の交渉
• 契約締結

総所要期間：7-11週間

情報サービス産業協会（JISA）の「オフショア開発ベストプラクティス2024」では、適切な選定プロセスに最低2ヶ月を確保することを推奨しています。急いで選定すると、後々大きな問題に直面するリスクが高まります。

出典：JISA オフショア開発ベストプラクティス

選定における3つの重要原則

原則1：価格だけで判断しない

最も安い見積もりを提示した会社が、必ずしも最適とは限りません。IPAの調査によると、「最安値で選定した企業」のプロジェクト失敗率は、「総合評価で選定した企業」の2.3倍に達しています。

価格は重要な要素ですが、品質、コミュニケーション能力、技術力、実績などを総合的に評価する必要があります。

原則2：複数社を比較する

最低でも3社、できれば5社以上から提案を受けることを推奨します。1社だけでは、提案内容や価格が適正かどうか判断できません。

原則3：段階的に絞り込む

初めから1社に決めるのではなく、段階的に候補を絞り込むプロセスが重要です。各段階で評価基準を明確にし、客観的に判断してください。

選定に関わるべきメンバー

オフショア開発会社の選定は、以下のメンバーで構成される選定委員会で行うことを推奨します。

必須メンバー：

• プロジェクトオーナー（意思決定者）
• 技術責任者（CTO、技術部長等）
• プロジェクトマネージャー（予定者）

推奨メンバー：

• 法務担当者（契約書チェック）
• 財務担当者（予算・支払い条件）
• 実際の開発リーダー（技術的評価）

多角的な視点で評価することで、より適切な判断が可能になります。

---

2. 【準備段階】自社要件の明確化とRFP作成

パートナー選定の成否は、準備段階で8割決まると言っても過言ではありません。自社の要件を明確にし、それを適切にRFPとして文書化することが、適切なパートナーを見つける第一歩です。

自社要件の明確化

オフショア開発会社に何を求めるのか、以下の項目を明確にしてください。

プロジェクト要件：

• プロジェクトの目的・背景
• 開発するシステムの概要
• 主要機能（箇条書きで10-20項目）
• 想定する技術スタック
• 非機能要件（性能、セキュリティ、可用性等）
• 開発期間（希望納期）
• 予算の上限

体制要件：

• 必要なチーム規模（人数）
• 必要なスキルレベル（シニア何名、ミドル何名等）
• プロジェクト管理体制（PMの配置等）
• コミュニケーション要件（日本語レベル、ブリッジSEの有無）

品質要件：

• 品質基準（ISO等の認証の有無）
• テスト方針（テストカバレッジの目標等）
• ドキュメント要件
• コードレビューの方法

契約要件：

• 契約形態（請負 or ラボ型）
• 支払い条件
• 著作権の帰属
• 秘密保持契約（NDA）
• 保証期間・保証内容

RFP（提案依頼書）テンプレート

以下は、実際に使用できるRFPのテンプレートです。自社の状況に合わせてカスタマイズしてください。

---

【RFPテンプレート】

提案依頼書（Request for Proposal）

発行日： 20XX年XX月XX日
提案期限： 20XX年XX月XX日
発行者： 株式会社〇〇〇〇 システム開発部

1. プロジェクト概要

1.1 背景・目的
（プロジェクトの背景、なぜこのシステムが必要なのかを記載）

1.2 システム概要
（開発するシステムの概要を記載）

1.3 主要機能

• 機能1：（詳細）
• 機能2：（詳細）
• 機能3：（詳細）
• …

2. 技術要件

2.1 技術スタック

• フロントエンド：React（希望）
• バックエンド：Ruby on Rails（希望）
• データベース：PostgreSQL
• インフラ：AWS

2.2 非機能要件

• 同時接続ユーザー数：1,000人
• レスポンスタイム：2秒以内
• 可用性：99.9%以上
• セキュリティ：ISO27001相当

3. プロジェクト要件

3.1 スケジュール

• 開発期間：20XX年XX月 ～ 20XX年XX月（X ヶ月）
• 主要マイルストーン：

– 要件定義完了：20XX年XX月
– 設計完了：20XX年XX月
– 開発完了：20XX年XX月
– テスト完了：20XX年XX月
– 本番リリース：20XX年XX月

3.2 体制

• 想定チーム規模：X-X名
• 必要な役割：

– プロジェクトマネージャー：1名
– シニアエンジニア：X名
– ミドルエンジニア：X名
– ジュニアエンジニア：X名
– ブリッジSE：1名（日本語ビジネスレベル必須）

4. 提案依頼事項

貴社には、以下の項目について提案をお願いします。

4.1 開発体制

• チーム構成（役割、人数、スキルレベル）
• 各メンバーの経歴・実績
• プロジェクト管理体制
• コミュニケーション方法

4.2 開発手法

• 開発プロセス（ウォーターフォール、アジャイル等）
• 品質管理手法
• テスト方針
• ドキュメント作成方針

4.3 スケジュール

• 詳細スケジュール（WBS）
• 主要マイルストーン
• リスク要因と対策

4.4 費用

• 見積もり総額
• 内訳（役割別、フェーズ別）
• 支払い条件の提案
• 追加費用が発生する条件

4.5 品質保証

• 品質保証の方針
• 保証期間・保証内容
• 不具合対応のフロー

4.6 実績

• 類似プロジェクトの実績（3件以上）
• 参照先企業の連絡先（2社以上）

5. 評価基準

提案は以下の基準で評価します。

• 技術力・実績：30点
• 開発体制・品質管理：25点
• コミュニケーション能力：20点
• 費用：15点
• スケジュールの実現性：10点

6. 提案書提出要領

6.1 提出期限
20XX年XX月XX日 17:00まで

6.2 提出方法
メール送付：proposal@example.com

6.3 提出形式
PDF形式、ファイル名：「提案書_貴社名_20XXMMDD.pdf」

6.4 問い合わせ先
担当：〇〇部 〇〇
電話：03-XXXX-XXXX
メール：contact@example.com

7. 選定スケジュール

• 提案書提出期限：20XX年XX月XX日
• 一次選考結果通知：20XX年XX月XX日
• プレゼンテーション・面談：20XX年XX月XX日-XX日
• 最終選考結果通知：20XX年XX月XX日
• 契約締結：20XX年XX月XX日

8. 秘密保持

本RFPに記載の情報は機密情報として取り扱い、提案目的以外に使用しないでください。提案の採否に関わらず、本RFPおよび関連資料は返却または破棄してください。

---

以上

---

RFP作成のポイント

明確さ：
曖昧な表現を避け、具体的に記載してください。「高品質」ではなく「ISO9001認証取得済み」、「豊富な実績」ではなく「類似プロジェクト3件以上」といった具合です。

現実性：
予算やスケジュールは、現実的な範囲で設定してください。非現実的な条件では、適切な提案を得られません。

評価基準の明示：
どのような基準で評価するのかを明示することで、各社が重点を置くべきポイントが明確になり、比較しやすい提案を受けられます。

柔軟性：
すべてを固定せず、提案の余地を残してください。「希望」「推奨」といった表現を使い、代替案の提示も歓迎する姿勢を示します。

---

3. 【候補選定】初期スクリーニングの15のチェックポイント

RFPを送付する前に、公開情報や初期問い合わせで候補企業を絞り込みます。ここでは、最低限クリアすべき15のチェックポイントを紹介します。

基本情報の確認（5項目）

□ チェック1：会社の設立年数

• 推奨：5年以上
• 理由：オフショア開発業界は競争が激しく、質の低い企業は淘汰されます。5年以上の実績がある企業は、一定の信頼性があります。

□ チェック2：従業員数

• 推奨：自社プロジェクトの2倍以上
• 理由：急な人員増強や、メンバー変更への対応力を確保するため。10名のチームが必要なら、最低20名以上の企業を選びましょう。

□ チェック3：日本企業との取引実績

• 必須：10社以上
• 理由：日本企業特有の商習慣や品質基準を理解しているかの指標。実績が少ない企業は、文化的な齟齬が生じやすいです。

□ チェック4：財務状況

• 確認項目：直近3年の売上推移、利益率
• 理由：プロジェクト途中で倒産するリスクを避けるため。可能であれば、財務諸表の開示を求めてください。

□ チェック5：オフィスの所在地

• 確認項目：オフィスの住所、規模
• 理由：実態のない企業や、小規模すぎる企業を排除するため。可能であれば、Googleマップのストリートビューで確認してください。

技術力の確認（5項目）

□ チェック6：対応可能な技術スタック

• 確認項目：自社プロジェクトで使用する技術の経験
• 理由：実績のない技術スタックでは、品質やスピードに問題が生じやすいです。

□ チェック7：類似プロジェクトの実績

• 必須：3件以上
• 理由：業界やシステムの種類によって、必要な知識やノウハウが異なります。類似プロジェクトの実績は、成功の可能性を大きく高めます。

□ チェック8：技術者の平均経験年数

• 推奨：3年以上
• 理由：経験の浅いエンジニアばかりでは、品質や生産性に問題が生じます。

□ チェック9：技術ブログやGitHubの活動

• 確認項目：技術情報の発信、OSSへの貢献
• 理由：技術力の高い企業は、積極的に情報発信しています。これは技術力の間接的な指標になります。

□ チェック10：認証・資格の取得状況

• 推奨：ISO9001（品質管理）、ISO27001（情報セキュリティ）
• 理由：第三者機関による認証は、一定の品質管理体制があることの証明です。

コミュニケーション能力の確認（5項目）

□ チェック11：日本語対応可能な人材

• 必須：ブリッジSE（日本語ビジネスレベル）の在籍
• 理由：コミュニケーションの質が、プロジェクト成否を大きく左右します。

□ チェック12：日本拠点の有無

• 推奨：日本に営業拠点または代表者がいる
• 理由：トラブル発生時の対応がスムーズになります。また、日本市場へのコミットメントの高さの指標にもなります。

□ チェック13：コミュニケーションツールの対応

• 確認項目：Slack、Teams、Zoom等の使用経験
• 理由：自社で使用しているツールに対応できることは、スムーズな協業の前提条件です。

□ チェック14：時差への対応

• 確認項目：日本の営業時間帯での対応可否
• 理由：ベトナムと日本の時差は2時間と小さいですが、緊急時の対応体制は確認しておく必要があります。

□ チェック15：初期問い合わせへの対応

• 評価項目：返信の速さ、内容の適切さ、日本語の質
• 理由：初期問い合わせへの対応は、その企業のコミュニケーション能力を測る最初の機会です。返信が遅い、内容が不適切、日本語が不自然、といった企業は避けるべきです。

初期スクリーニングの実施方法

ステップ1：候補企業のリストアップ（10-15社）

以下の方法で候補企業を探します。

• Google検索（「ベトナム オフショア開発」等）
• 業界団体のディレクトリ（VINASA等）
• 知人・取引先からの紹介
• オフショア開発の比較サイト

ステップ2：公開情報の収集

各社のWebサイト、会社案内資料から、上記15項目の情報を収集します。

ステップ3：初期問い合わせ

簡単な問い合わせメールを送り、対応を評価します。

問い合わせメール例：

件名：システム開発のご相談

株式会社〇〇〇〇 ご担当者様

初めてご連絡いたします。 株式会社△△△△の□□と申します。

現在、弊社では【システムの種類】の開発を検討しており、 オフショア開発のパートナーを探しております。

つきましては、以下の情報をご提供いただけますでしょうか。

会社案内資料
【該当する技術スタック】での開発実績
参考見積もり（概算で結構です）
開発期間：X ヶ月
チーム規模：X名程度
お忙しいところ恐縮ですが、 XX月XX日までにご返信いただけますと幸いです。

よろしくお願いいたします。

株式会社△△△△ □□部 □□ 電話：03-XXXX-XXXX メール：xxx@example.com

ステップ4：スクリーニング結果の集計

15項目のチェックリストを使って、各社を評価します。

評価基準：

• 15項目中12項目以上クリア：RFP送付候補
• 9-11項目クリア：条件付きで候補
• 8項目以下：候補から除外

ステップ5：候補の絞り込み

10-15社から、5社程度に絞り込みます。

---

4. 【提案評価】提案書評価の20のチェックポイント

RFPへの提案書を受領したら、以下の20項目で詳細に評価します。

提案内容の妥当性（7項目）

□ チェック16：要件の理解度

• 評価方法：RFPの要件を正確に理解しているか
• 確認ポイント：提案書に、要件の要約や解釈が記載されているか
• 評価基準：

– 優：要件を正確に理解し、さらに深掘りした提案がある
– 良：要件を正確に理解している
– 可：要件の理解に一部不足がある
– 不可：要件を誤解している

□ チェック17：技術的アプローチの適切さ

• 評価方法：提案された技術スタックや開発手法が適切か
• 確認ポイント：技術選定の理由が明記されているか
• 評価基準：

– 優：技術選定の理由が明確で、代替案も提示されている
– 良：技術選定が適切
– 可：技術選定に一部疑問がある
– 不可：不適切な技術が提案されている

□ チェック18：リスクの認識と対策

• 評価方法：プロジェクトのリスクを適切に認識し、対策を提示しているか
• 確認ポイント：リスク一覧と対策が記載されているか
• 評価基準：

– 優：5つ以上のリスクと具体的な対策を提示
– 良：3-4つのリスクと対策を提示
– 可：1-2つのリスクのみ
– 不可：リスクへの言及がない

□ チェック19：スケジュールの実現性

• 評価方法：提案されたスケジュールが現実的か
• 確認ポイント：WBS（作業分解構造）が詳細に記載されているか
• 評価基準：

– 優：詳細なWBSと、余裕を持ったスケジュール
– 良：適切なスケジュール
– 可：やや楽観的なスケジュール
– 不可：明らかに非現実的なスケジュール

□ チェック20：品質管理の具体性

• 評価方法：品質管理の方法が具体的に記載されているか
• 確認ポイント：テスト計画、レビュー体制、品質基準が明記されているか
• 評価基準：

– 優：詳細な品質管理計画と具体的な数値目標
– 良：標準的な品質管理計画
– 可：品質管理への言及が簡潔
– 不可：品質管理への言及がない

□ チェック21：コミュニケーション計画

• 評価方法：コミュニケーションの方法が具体的に記載されているか
• 確認ポイント：定期会議の頻度、報告方法、使用ツールが明記されているか
• 評価基準：

– 優：詳細なコミュニケーション計画と、問題発生時のエスカレーションフローが明確
– 良：標準的なコミュニケーション計画
– 可：コミュニケーションへの言及が簡潔
– 不可：コミュニケーションへの言及がない

□ チェック22：付加価値の提案

• 評価方法：RFPの要求を超える付加価値の提案があるか
• 確認ポイント：改善提案、コスト削減案、品質向上策などが提示されているか
• 評価基準：

– 優：複数の付加価値提案がある
– 良：1-2の付加価値提案がある
– 可：RFPの要求のみ
– 不可：RFPの要求を下回る

チーム体制の評価（6項目）

□ チェック23：チーム構成の適切さ

• 評価方法：提案されたチーム構成が適切か
• 確認ポイント：役割、人数、スキルレベルのバランス
• 評価基準：

– 優：シニア20-30%、ミドル40-50%、ジュニア20-30%の適切なバランス
– 良：概ね適切なバランス
– 可：ジュニアがやや多い、またはシニアが少ない
– 不可：明らかに不適切な構成

□ チェック24：メンバーの経歴

• 評価方法：各メンバーの経歴が詳細に記載されているか
• 確認ポイント：経験年数、過去のプロジェクト、保有スキル
• 評価基準：

– 優：全メンバーの詳細な経歴（職務経歴書レベル）
– 良：主要メンバーの経歴
– 可：簡単な経歴のみ
– 不可：経歴の記載がない

□ チェック25：ブリッジSEの能力

• 評価方法：ブリッジSEの日本語能力と技術力
• 確認ポイント：日本語能力試験のレベル、技術経験
• 評価基準：

– 優：JLPT N1レベル + 技術的な議論が可能
– 良：JLPT N2レベル + 基本的な技術理解
– 可：JLPT N3レベル
– 不可：JLPT N4以下

□ チェック26：PMの経験

• 評価方法：PMの経験が十分か
• 確認ポイント：PM経験年数、類似プロジェクトの実績
• 評価基準：

– 優：PM経験5年以上 + 類似プロジェクト3件以上
– 良：PM経験3年以上 + 類似プロジェクト1件以上
– 可：PM経験1年以上
– 不可：PM経験が不十分

□ チェック27：専任体制の保証

• 評価方法：チームメンバーが専任か
• 確認ポイント：専任率（100%、80%等）の明記
• 評価基準：

– 優：全員100%専任
– 良：主要メンバーは100%専任
– 可：80%程度の稼働率
– 不可：専任の保証がない

□ チェック28：バックアップ体制

• 評価方法：メンバー変更時の対応が明記されているか
• 確認ポイント：バックアップメンバーの有無、引き継ぎ方法
• 評価基準：

– 優：バックアップメンバーが明記され、引き継ぎ計画がある
– 良：バックアップ体制への言及がある
– 可：簡単な言及のみ
– 不可：バックアップ体制への言及がない

費用の評価（4項目）

□ チェック29：見積もりの詳細度

• 評価方法：見積もりが詳細に記載されているか
• 確認ポイント：役割別、フェーズ別の内訳
• 評価基準：

– 優：役割別、フェーズ別、作業項目別の詳細内訳
– 良：役割別、フェーズ別の内訳
– 可：大まかな内訳のみ
– 不可：総額のみで内訳がない

□ チェック30：費用の妥当性

• 評価方法：提示された費用が相場と比較して適切か
• 確認ポイント：前回記事の相場表と比較
• 評価基準：

– 優：相場の±10%以内で、内容に見合っている
– 良：相場の±20%以内
– 可：相場より20-30%高いまたは安い
– 不可：相場から大きく乖離

□ チェック31：追加費用の条件

• 評価方法：追加費用が発生する条件が明記されているか
• 確認ポイント：仕様変更、スコープ追加時の単価
• 評価基準：

– 優：詳細な条件と単価が明記
– 良：基本的な条件が明記
– 可：簡単な言及のみ
– 不可：追加費用への言及がない

□ チェック32：支払い条件

• 評価方法：支払い条件が適切か
• 確認ポイント：支払いタイミング、方法
• 評価基準：

– 優：標準的な支払い条件（契約時30-40%、中間30-40%、納品時20-30%）
– 良：やや前払いが多い（契約時50%等）
– 可：前払い60%以上
– 不可：前払い100%

実績の評価（3項目）

□ チェック33：類似プロジェクトの実績

• 評価方法：類似プロジェクトの実績が十分か
• 確認ポイント：プロジェクト概要、規模、期間、成果
• 評価基準：

– 優：詳細な実績が3件以上
– 良：実績が2件以上
– 可：実績が1件
– 不可：類似実績がない

□ チェック34：参照先企業の提示

• 評価方法：参照先企業の連絡先が提示されているか
• 確認ポイント：企業名、担当者名、連絡先
• 評価基準：

– 優：2社以上の詳細な連絡先
– 良：1社の連絡先
– 可：企業名のみ
– 不可：参照先の提示がない

□ チェック35：失敗事例とその対策

• 評価方法：過去の失敗事例と、そこから学んだ教訓が記載されているか
• 確認ポイント：失敗の原因分析、改善策
• 評価基準：

– 優：失敗事例と詳細な改善策が記載
– 良：失敗への言及と簡単な対策
– 可：成功事例のみ
– 不可：実績への言及が不十分

提案書評価のスコアリング

各項目を4段階（優:3点、良:2点、可:1点、不可:0点）で評価し、合計点で比較します。

満点：60点

評価基準：

• 50点以上：優良候補（次のステップへ）
• 40-49点：標準候補（次のステップへ）
• 30-39点：条件付き候補（懸念点を確認）
• 29点以下：候補から除外

---

5. 【詳細評価】面談・訪問での15のチェックポイント

提案書評価で絞り込んだ3社程度と、対面またはオンラインで面談を行います。可能であれば、現地オフィスの訪問も推奨します。

面談での確認事項（10項目）

□ チェック36：コミュニケーション能力の実際

• 評価方法：面談での日本語コミュニケーション能力
• 確認ポイント：

– 質問の意図を正確に理解できるか
– 技術的な議論が可能か
– 回答が明確か

• 評価方法：実際に技術的な質問をして反応を見る

□ チェック37：技術的な深掘り

• 評価方法：提案内容について、技術的に深掘りした質問をする
• 確認ポイント：

– アーキテクチャの詳細を説明できるか
– 技術選定の理由を明確に説明できるか
– 代替案を提示できるか

質問例：

• 「なぜこのフレームワークを選んだのですか？」
• 「パフォーマンス要件をどのように満たしますか？」
• 「セキュリティ対策の具体的な方法は？」

□ チェック38：過去のトラブル対応

• 評価方法：過去のプロジェクトでのトラブル事例と対応を聞く
• 確認ポイント：

– トラブルを隠さず正直に話すか
– 原因分析が適切か
– 対策が具体的か

質問例：

• 「過去のプロジェクトで最も困難だった問題は何ですか？」
• 「それをどのように解決しましたか？」
• 「その経験から何を学びましたか？」

□ チェック39：プロジェクト管理の具体性

• 評価方法：プロジェクト管理の具体的な方法を聞く
• 確認ポイント：

– 使用するツール（Jira、Redmine等）
– 進捗報告の方法と頻度
– 問題発生時のエスカレーションフロー

□ チェック40：品質管理の実際

• 評価方法：品質管理の具体的な方法を聞く
• 確認ポイント：

– コードレビューの方法
– テストの種類とカバレッジ目標
– 品質指標（バグ密度等）の設定

□ チェック41：文化的な理解

• 評価方法：日本のビジネス文化への理解度
• 確認ポイント：

– 報連相の重要性を理解しているか
– 暗黙の期待値を明文化する重要性を理解しているか
– 日本の商習慣（稟議、検収等）を理解しているか

□ チェック42：柔軟性と対応力

• 評価方法：仕様変更や追加要求への対応姿勢
• 確認ポイント：

– 変更を前向きに受け入れる姿勢があるか
– 変更管理のプロセスが明確か
– 追加費用の算定方法が合理的か

□ チェック43：長期的な関係構築の意思

• 評価方法：単発プロジェクトではなく、長期的なパートナーシップを望んでいるか
• 確認ポイント：

– 保守・運用への対応意欲
– 継続的な改善提案の姿勢
– ラボ型契約への対応可否

□ チェック44：経営陣の関与

• 評価方法：経営陣がプロジェクトにどの程度関与するか
• 確認ポイント：

– 経営陣との面談が可能か
– 経営陣のコミットメントの強さ
– トラブル時の経営陣の対応

□ チェック45：化学反応（相性）

• 評価方法：チームとの相性、信頼できそうか
• 確認ポイント：

– 誠実さ、正直さを感じるか
– 一緒に働きたいと思えるか
– 価値観が合いそうか

※これは定量化できませんが、非常に重要な要素です。

現地訪問での確認事項（5項目）

可能であれば、現地オフィスを訪問することを強く推奨します。オンラインでは見えない多くの情報が得られます。

□ チェック46：オフィス環境

• 確認ポイント：

– オフィスの規模、清潔さ
– 開発環境（PC、モニター、ネットワーク等）
– セキュリティ対策（入退室管理等）
– 働いているエンジニアの様子

□ チェック47：チームの雰囲気

• 確認ポイント：

– エンジニア同士のコミュニケーション
– 活気があるか、士気は高いか
– 離職率の実態（エンジニアに直接聞く）

□ チェック48：実際の開発現場

• 確認ポイント：

– 実際の開発プロセスを見せてもらう
– 使用しているツール、環境
– ドキュメントの管理方法
– コードレビューの実際

□ チェック49：バックアップ体制の実態

• 確認ポイント：

– 提案書に記載されたバックアップメンバーが実在するか
– 他のプロジェクトの状況（余力があるか）

□ チェック50：経営陣との面談

• 確認ポイント：

– 経営陣のビジョン、価値観
– 日本市場へのコミットメント
– 人材育成への投資
– 会社の成長戦略

---

6. 参照先企業へのヒアリング完全ガイド

候補企業から提示された参照先企業に、実際にヒアリングを行うことは非常に重要です。以下の20の質問を参考に、詳細な情報を収集してください。

ヒアリング質問リスト（20問）

プロジェクト全般（5問）

プロジェクトは予定通り完了しましたか？

– 完了したか、遅延があったか
– 遅延があった場合、その理由と対応

当初の見積もりと最終的な費用に差はありましたか？

– 予算内に収まったか
– 追加費用が発生した場合、その理由

プロジェクトの満足度を10点満点で評価すると？

– 総合的な満足度
– 満足/不満足の理由

最も良かった点は何ですか？

– 技術力、コミュニケーション、柔軟性等

最も改善してほしい点は何ですか？

– 具体的な改善要望

コミュニケーション（5問）

コミュニケーションはスムーズでしたか？

– 言語の壁はあったか
– 意思疎通の問題はあったか

ブリッジSEの能力はどうでしたか？

– 日本語能力
– 技術的な理解力
– 調整能力

定期的な報告は適切でしたか？

– 報告の頻度、内容
– 問題の早期発見・報告

時差による問題はありましたか？

– 緊急時の対応
– 会議の設定

トラブル発生時の対応はどうでしたか？

– 対応の速さ
– 解決の質

技術力・品質（5問）

技術力は期待通りでしたか？

– 提案された技術の適切さ
– 実装の品質

品質は満足できるレベルでしたか？

– バグの発生率
– テストの充実度

コードの品質はどうでしたか？

– 可読性、保守性
– ドキュメントの充実度

技術的な提案はありましたか？

– 改善提案の有無
– 提案の質

最新技術への対応はどうでしたか？

– 技術のキャッチアップ
– 新しい技術への挑戦

プロジェクト管理（5問）

プロジェクト管理は適切でしたか？

– 進捗管理の方法
– リスク管理

仕様変更への対応はどうでしたか？

– 柔軟性
– 追加費用の妥当性

チーム体制は適切でしたか？

– メンバーのスキルレベル
– 人数の適切さ

メンバーの変更はありましたか？

– 変更の有無と頻度
– 引き継ぎの質

また同じ会社に依頼したいですか？

– 再発注の意思
– 推薦できるか

ヒアリングの実施方法

依頼方法：

候補企業に、参照先企業への紹介を依頼します。

紹介依頼メール例：

〇〇様

お世話になっております。 株式会社△△の□□です。

提案書をありがとうございました。 つきましては、参照先企業へのヒアリングをお願いしたく存じます。

以下の2社にご紹介いただけますでしょうか。

【類似プロジェクトの実績企業】
【最近完了したプロジェクトの企業】
ヒアリング内容は、プロジェクトの進行状況、コミュニケーション、 技術力、満足度等についてです。

ご協力のほど、よろしくお願いいたします。

ヒアリング方法：

• 電話またはオンライン会議（30-60分）
• 事前に質問リストを送付
• 記録を取る（許可を得て録音も可）

ヒアリング時の注意点：

• 率直な意見を聞くため、候補企業の担当者は同席させない
• 肯定的な意見だけでなく、改善点も必ず聞く
• 具体的なエピソードを聞く（抽象的な評価だけでは不十分）

---

7. 定量評価とスコアリング方法

ここまでの評価を総合し、定量的にスコアリングして最終判断を行います。

総合評価シート

評価項目	配点	A社	B社	C社
技術力・実績	30点
– 類似プロジェクト実績	10点
– 技術スタックの経験	10点
– 技術者のスキルレベル	10点
開発体制・品質管理	25点
– チーム構成の適切さ	8点
– PMの能力	7点
– 品質管理体制	10点
コミュニケーション能力	20点
– ブリッジSEの能力	10点
– 日本語対応力	5点
– コミュニケーション計画	5点
費用	15点
– 費用の妥当性	10点
– 見積もりの詳細度	5点
スケジュールの実現性	10点
– スケジュールの妥当性	5点
– リスク管理	5点
合計	100点
参照先評価（加点）	+10点
面談での印象（加点）	+10点
総合計	120点

評価基準の詳細

技術力・実績（30点）：

類似プロジェクト実績（10点）：

• 10点：3件以上の詳細な実績
• 7点：2件の実績
• 4点：1件の実績
• 0点：実績なし

技術スタックの経験（10点）：

• 10点：該当技術で5年以上の経験
• 7点：該当技術で3年以上の経験
• 4点：該当技術で1年以上の経験
• 0点：経験が不十分

技術者のスキルレベル（10点）：

• 10点：シニア30%以上、平均経験5年以上
• 7点：シニア20%以上、平均経験3年以上
• 4点：平均経験2年以上
• 0点：経験が不十分

開発体制・品質管理（25点）：

チーム構成の適切さ（8点）：

• 8点：最適なバランス、専任保証
• 6点：適切なバランス
• 3点：やや不安がある
• 0点：不適切

PMの能力（7点）：

• 7点：PM経験5年以上、類似PJ 3件以上
• 5点：PM経験3年以上、類似PJ 1件以上
• 2点：PM経験1年以上
• 0点：経験不十分

品質管理体制（10点）：

• 10点：ISO認証、詳細な品質管理計画
• 7点：標準的な品質管理体制
• 3点：品質管理への言及が簡潔
• 0点：品質管理体制が不明確

コミュニケーション能力（20点）：

ブリッジSEの能力（10点）：

• 10点：JLPT N1 + 技術的議論可能
• 7点：JLPT N2 + 基本的技術理解
• 4点：JLPT N3
• 0点：JLPT N4以下

日本語対応力（5点）：

• 5点：複数名が日本語対応可能
• 3点：ブリッジSEのみ対応可能
• 1点：日本語対応が限定的
• 0点：日本語対応が不十分

コミュニケーション計画（5点）：

• 5点：詳細な計画、複数チャネル
• 3点：標準的な計画
• 1点：簡潔な計画
• 0点：計画が不明確

費用（15点）：

費用の妥当性（10点）：

• 10点：相場±10%以内、内容に見合う
• 7点：相場±20%以内
• 3点：相場から20-30%乖離
• 0点：相場から大きく乖離

見積もりの詳細度（5点）：

• 5点：詳細な内訳（役割別、フェーズ別、項目別）
• 3点：役割別、フェーズ別の内訳
• 1点：大まかな内訳
• 0点：総額のみ

スケジュールの実現性（10点）：

スケジュールの妥当性（5点）：

• 5点：詳細なWBS、余裕あり
• 3点：適切なスケジュール
• 1点：やや楽観的
• 0点：非現実的

リスク管理（5点）：

• 5点：5つ以上のリスクと具体的対策
• 3点：3-4つのリスクと対策
• 1点：1-2つのリスク
• 0点：リスクへの言及なし

加点項目：

参照先評価（+10点）：

• 参照先企業からの評価が非常に高い場合に加点
• 10点：強く推薦される
• 5点：推薦される
• 0点：普通

面談での印象（+10点）：

• 面談での総合的な印象
• 10点：非常に信頼できる、相性が良い
• 5点：信頼できる
• 0点：普通

最終判断の基準

総合得点による判断：

• 90点以上：優良候補（強く推奨）
• 75-89点：良好候補（推奨）
• 60-74点：標準候補（条件付きで推奨）
• 59点以下：再検討推奨

重要な注意点：

得点だけで機械的に判断せず、以下の点も考慮してください。

• 特定の項目で0点がある場合は、総合点が高くても慎重に判断
• 「面談での印象」「参照先評価」など、定性的な要素も重視
• 複数の評価者の意見を総合する

---

8. 契約前の最終確認10項目

最終候補を1-2社に絞り込んだら、契約前に以下の10項目を必ず確認してください。

□ 最終確認1：契約形態の明確化

• 請負契約かラボ型契約か
• 契約期間
• 更新条件

□ 最終確認2：成果物の定義

• 納品物の詳細リスト
• 著作権の帰属
• ソースコードの権利

□ 最終確認3：支払い条件

• 支払いスケジュール
• 支払い方法（銀行振込、為替等）
• 前払い比率

□ 最終確認4：仕様変更の取り扱い

• 変更管理プロセス
• 追加費用の算定方法
• 変更可能な範囲

□ 最終確認5：品質保証

• 保証期間（通常3-6ヶ月）
• 保証範囲
• 不具合対応のSLA（Service Level Agreement）

□ 最終確認6：納期遅延時の対応

• 遅延時のペナルティ
• 遅延の定義
• 免責事項

□ 最終確認7：秘密保持契約（NDA）

• NDAの締結
• 秘密情報の範囲
• 保持期間

□ 最終確認8：契約解除条件

• 中途解約の条件
• 解約時の清算方法
• 違約金

□ 最終確認9：紛争解決

• 準拠法
• 管轄裁判所
• 仲裁の有無

□ 最終確認10：保険

• 賠償責任保険の加入状況
• 保険金額
• 補償範囲

契約書のチェックポイント

契約書は必ず法務担当者にレビューしてもらってください。特に以下の点に注意が必要です。

要注意条項：

• 著作権が開発会社に帰属する条項
• 一方的に不利な損害賠償条項
• 曖昧な成果物の定義
• 非現実的な納期設定
• 過度な前払い条件

推奨条項：

• 段階的な支払い条件
• 明確な検収基準
• 合理的な保証期間
• 適切な損害賠償の上限設定

トライアルプロジェクトの実施

可能であれば、本契約の前に小規模なトライアルプロジェクトを実施することを強く推奨します。

トライアルプロジェクトの設計：

• 期間：1-2ヶ月
• 規模：小規模（予算100-300万円程度）
• 内容：本プロジェクトの一部機能、またはプロトタイプ
• 目的：技術力、コミュニケーション、プロジェクト管理能力の実地検証

トライアルでの評価ポイント：

• 技術的な成果物の品質
• コミュニケーションのスムーズさ
• スケジュール遵守
• 問題発生時の対応
• チームとの相性

トライアルで問題があれば、本契約を見送ることも選択肢です。小規模な投資で大きなリスクを回避できます。

---

9. 失敗事例から学ぶ5つの教訓

実際の失敗事例から、パートナー選定で避けるべきポイントを学びましょう。

失敗事例1：価格だけで選定した結果

状況：

• 5社から見積もりを取得し、最安値の企業を選定
• 他社より40%安い見積もりに魅力を感じた
• 実績や体制の確認が不十分だった

結果：

• アサインされたエンジニアのスキルが低く、品質問題が多発
• 納期が3ヶ月遅延
• 追加の修正費用で、結局他社と同等以上のコストに

教訓：

• 極端に安い見積もりには必ず理由がある
• 総合評価で判断する重要性
• 「安物買いの銭失い」を避ける

失敗事例2：ブリッジSEの能力を過信

状況：

• 提案時のブリッジSEの日本語が流暢だった
• 技術的な質問にも答えられたため、安心した
• 実際のプロジェクトでは別のブリッジSEがアサインされた

結果：

• 実際のブリッジSEの日本語能力が不十分
• 技術的な理解も浅く、誤った翻訳が頻発
• コミュニケーションコストが想定の3倍に

教訓：

• 提案時と実際のメンバーが同一か確認する
• ブリッジSEの変更を禁止する条項を契約書に入れる
• バックアップのブリッジSEの能力も確認する

失敗事例3：参照先ヒアリングを省略

状況：

• 時間がなく、参照先へのヒアリングを省略
• 提案書の実績リストを信頼した
• Webサイトの情報だけで判断した

結果：

• 実際は実績が誇張されていた
• 類似プロジェクトの経験が不足していた
• プロジェクト途中で深刻な技術的問題が発覚

教訓：

• 参照先ヒアリングは必須
• 実績の裏付けを取る
• 時間がなくても最低限の確認は行う

失敗事例4：契約書の詳細を確認しなかった

状況：

• 契約書を法務担当に回さず、営業担当が判断
• 細かい条項を読まずに署名
• 「標準的な契約書」という説明を信じた

結果：

• 著作権が開発会社に帰属する条項があった
• 仕様変更時の追加費用が想定の2倍
• 契約解除が困難な条項があった

教訓：

• 契約書は必ず法務担当がレビュー
• すべての条項を理解してから署名
• 不明点は必ず確認する

失敗事例5：現地訪問を省略

状況：

• コスト削減のため、現地訪問を省略
• オンライン面談だけで判断
• Webサイトの写真を信頼した

結果：

• 実際のオフィスは小規模で設備が不十分
• 提案書に記載されたメンバーの一部が実在しなかった
• 開発環境が想定より劣悪だった

教訓：

• 可能な限り現地訪問を実施
• 実態を自分の目で確認する
• オンラインだけでは見えない情報がある

---

10. よくある質問（FAQ）

Q1: オフショア開発会社の選定にどれくらいの期間が必要ですか？

A: 適切な選定には、最低2ヶ月、推奨は3ヶ月です。急いで選定すると、後々大きな問題に直面するリスクが高まります。以下のスケジュールを参考にしてください。

• 準備段階：1-2週間
• 初期スクリーニング：1週間
• 提案依頼と評価：2-3週間
• 詳細評価：2-3週間
• 最終判断：1-2週間
• トライアル（推奨）：1-2ヶ月

Q2: 何社から見積もりを取得すべきですか？

A: 最低3社、推奨は5社です。1-2社だけでは、提案内容や価格が適正かどうか判断できません。ただし、10社以上になると評価の負担が大きくなるため、初期スクリーニングで5社程度に絞り込むことを推奨します。

Q3: 現地訪問は必須ですか？

A: 必須ではありませんが、強く推奨します。特に大規模プロジェクトや長期契約の場合は、必ず訪問してください。オンラインでは見えない多くの情報（オフィス環境、チームの雰囲気、実際の開発現場等）が得られます。

訪問が困難な場合は、以下の代替策を検討してください。

• 詳細なオンライン面談（複数回）
• ビデオによるオフィスツアー
• 第三者による訪問レポート
• トライアルプロジェクトでの実地検証

Q4: ブリッジSEの重要性はどれくらいですか？

A: 非常に重要です。IPAの調査によると、プロジェクト成功の要因の中で、「優秀なブリッジSEの存在」が上位3位に入っています。ブリッジSEの能力が不足していると、以下の問題が発生します。

• 要件の誤解による手戻り
• コミュニケーションコストの増大
• 品質問題の見落とし
• チーム間の信頼関係の悪化

ブリッジSEの評価には、特に時間をかけてください。

Q5: トライアルプロジェクトは必要ですか？

A: 大規模プロジェクトや長期契約の場合は、強く推奨します。小規模な投資（100-300万円）で、以下のリスクを大幅に低減できます。

• 技術力の不足
• コミュニケーション問題
• プロジェクト管理能力の不足
• チームとの相性

トライアルで問題が発覚した場合、本契約を見送ることができます。これは、大規模プロジェクトの失敗（数千万円～億単位の損失）を回避するための保険です。

Q6: 参照先企業へのヒアリングで、何を最も重視すべきですか？

A: 以下の3点を最も重視してください。

「また同じ会社に依頼したいですか？」

– この質問への回答が、総合的な満足度を最もよく表します。

「最も改善してほしい点は何ですか？」

– 肯定的な意見だけでなく、改善点を聞くことで、その企業の弱点が見えてきます。

「トラブル発生時の対応はどうでしたか？」

– トラブルのない開発はありません。重要なのは、トラブルへの対応力です。

Q7: 契約形態（請負 vs ラボ型）はどう選べば良いですか？

A: プロジェクトの特性によって選択してください。

請負型が適しているケース：

• 要件が明確で変更が少ない
• 短期間（6ヶ月未満）
• 成果物ベースで評価したい
• 責任の所在を明確にしたい

ラボ型が適しているケース：

• 要件が流動的で変更が多い
• 長期間（12ヶ月以上）
• 継続的な開発が必要
• 柔軟な対応を重視

初めてのオフショア開発では、請負型でスタートし、信頼関係が構築できたらラボ型に移行するのも良い戦略です。

Q8: 見積もりに大きな差がある場合、どう判断すれば良いですか？

A: まず、見積もりの詳細な内訳を確認してください。以下の点をチェックします。

• チーム構成（人数、スキルレベル）
• 作業範囲（どこまでが含まれるか）
• 品質管理の方法
• リスク予備費の有無

安い見積もりには、必ず理由があります。

• 経験の浅いエンジニアを配置
• 作業範囲が限定的
• 品質管理が不十分
• リスク予備費が含まれていない

極端に安い見積もり（相場の-30%以上）は、避けることを推奨します。

Q9: オフショア開発会社との契約で、最も注意すべき条項は？

A: 以下の3つの条項に特に注意してください。

著作権の帰属

– 成果物の著作権が自社に帰属することを明記
– 「納品時に著作権が移転する」と明記

損害賠償の範囲と上限

– 無制限の損害賠償は避ける
– 合理的な上限（契約金額の50-100%等）を設定

契約解除の条件

– 重大な契約違反時の解除権を確保
– 解除時の清算方法を明記

これらの条項は、必ず法務担当者にレビューしてもらってください。

Q10: 選定に失敗したと感じた場合、どうすれば良いですか？

A: プロジェクト開始後に問題が発覚した場合、以下のステップで対応してください。

ステップ1：問題の明確化

• 具体的に何が問題なのかを明確にする
• 証拠（メール、議事録等）を収集

ステップ2：開発会社との協議

• 問題を率直に伝える
• 改善策を協議する
• 期限を設定する

ステップ3：改善の評価

• 設定した期限で改善されたか評価
• 改善されない場合は、次のステップへ

ステップ4：契約解除の検討

• 契約書の解除条項を確認
• 法務担当、弁護士に相談
• 損失を最小限に抑える方法を検討

ステップ5：代替パートナーの確保

• 並行して、代替パートナーを探す
• スムーズな移行計画を立てる

重要なのは、問題を早期に発見し、早期に対応することです。「もう少し様子を見よう」と先延ばしにすると、損失が拡大します。

---

まとめ：適切なパートナー選定がプロジェクト成功の鍵

オフショア開発会社の選定は、プロジェクト成功の最も重要な要素です。本記事で紹介した50のチェックポイントと体系的なプロセスを活用することで、適切なパートナーを見つけることができます。

重要なポイントの再確認：

1. 十分な時間をかける：
適切な選定には最低2ヶ月、推奨は3ヶ月必要です。急いで選定すると、後々大きな問題に直面します。

2. 価格だけで判断しない：
最安値の企業が最適とは限りません。技術力、コミュニケーション能力、実績などを総合的に評価してください。

3. 体系的なプロセスを踏む：
準備→スクリーニング→提案評価→詳細評価→最終判断という段階的なプロセスが重要です。

4. 参照先ヒアリングは必須：
提案書や面談だけでは見えない情報が、参照先ヒアリングで得られます。

5. 可能な限り現地訪問を：
オンラインでは見えない多くの情報が、現地訪問で得られます。

6. トライアルプロジェクトを活用：
小規模な投資で、大きなリスクを回避できます。

7. 契約書は法務担当がレビュー：
契約書の細部が、後々のトラブルを左右します。

8. 定量評価と定性評価の両方を：
スコアリングシートによる定量評価と、面談での定性評価を組み合わせてください。

次のステップ：

本記事のチェックリストをダウンロード

自社の要件を明確化

RFPを作成

候補企業のリストアップ

体系的な選定プロセスの開始

適切なパートナーを選定することで、オフショア開発のメリットを最大限に活用し、プロジェクトを成功に導くことができます。本記事の情報を活用して、あなたのプロジェクトに最適なパートナーを見つけてください。