オフショア開発の進め方

こんにちは。ベトナムオフショア開発協会運営事務局です。

オフショア開発会社を数社まで絞り込み、各社から提案書と見積書を受け取ったものの、どこを選べばよいか決めきれない。開発責任者にとって、これは珍しくない悩みです。

見積総額や人月単価は数字で並べられます。しかし、ある会社の見積もりにはBrSEやテスト担当が含まれ、別の会社では開発者だけが計上されているかもしれません。要件整理、環境構築、コードレビュー、リリース支援なども、各社で「含む」「別途」「発注側が担当」と前提が異なります。

この状態で金額だけを比べると、安く見える提案を選んだ後に、日本側の作業や追加費用が増える可能性があります。必要なのは、提案書の書式をそろえることではなく、各社が何を前提に、どこまで責任を持つのかを同じ土俵に乗せることです。

本記事では、候補となるオフショア開発会社3社前後を比較する場面を想定し、見積条件をそろえる5つのポイントを解説します。

本記事の要点

見積比較では、総額を並べる前に「業務範囲と成果物」「体制と役割」「品質管理と受入条件」「日本側に必要な作業」「追加費用と変更対応」の5つを同じ条件でそろえることが重要です。価格差の理由が見えると、社内で委託先の選定理由を説明しやすくなります。

なぜ見積金額だけでは比較できないのか

複数社の提案を比較するとき、まず目に入るのは総額、単価、人数、期間です。ただし、これらの数字は前提が同じでなければ比較できません。

たとえば「5人月」という記載があっても、PMやBrSEを含む5人月なのか、開発者だけで5人月なのかによって意味が変わります。「テスト込み」と書かれていても、単体テストだけなのか、結合テストやテスト設計まで含むのかは分かりません。保守費用も、問い合わせ対応だけなのか、不具合修正や定例報告まで含むのかで大きく異なります。

さらに、提案会社ごとに得意な進め方があります。要件が固まった後の実装を得意とする会社もあれば、要件整理から支援する会社もあります。どちらが優れているかではなく、自社が求める役割と提案内容が合っているかを見なければなりません。

社内決裁では「一番安かったから」だけでは説明が不十分です。価格差の理由、候補会社ごとのリスク、日本側に必要な体制まで整理し、「この条件では、この会社が最も適している」と説明できる状態をつくる必要があります。

見積もりを比較しにくくする最大の原因は、各社に渡した情報が同じでも、解釈や見積範囲が同じとは限らないことです。IPAの要件定義に関する資料でも、RFPに記載がない内容は見積もりに含まれにくく、抽象的な表現は受け手によって解釈が変わるため、見積精度が下がると説明されています。比較可能な提案を受け取るには、発注側が実現したいことと回答してほしい項目を明確に示す必要があります。

もう一つの原因は、見積金額の中に「見えにくい作業」があることです。仕様確認の会議、質問管理、設計レビュー、品質報告、受入支援、仕様変更時の再見積もりなどは、プロジェクト運営には欠かせません。しかし、会社によって標準サービスに含まれる範囲が違います。

したがって、見積比較では、金額を採点する前に前提条件を確認する工程が必要です。

01委託する業務範囲と成果物をそろえる

最初に確認したいのは、どの工程を誰が担当するかです。要件整理、基本設計、詳細設計、実装、単体テスト、結合テスト、リリース、運用保守を並べ、各社の担当範囲を明記します。

「開発一式」「テスト込み」といった表現だけでは比較できません。工程ごとに、作業内容と成果物を確認してください。たとえばテストであれば、テスト計画、テストケース作成、実施、不具合管理、再テスト、結果報告のどこまでを含むかを確認します。

要件が十分に固まっていない場合は、確定見積もりのように扱わないことも重要です。現時点の概算、前提条件、見積もりから除外した事項、再見積もりのタイミングを各社に示してもらいます。分からない部分を無理に同じ金額へ寄せるのではなく、不確実性を見える形にする方が、後の判断に役立ちます。

比較表には、最低限「対象工程」「主な成果物」「対象外」「前提条件」の欄を設けると整理しやすくなります。

02人数ではなく、体制と役割をそろえる

次に、提案されている人数の内訳を確認します。開発者4名という提案と、開発者3名にBrSE1名という提案は、同じ4名でも役割が違います。

確認したいのは、PM、BrSE、テックリーダー、開発者、QA・テスターなどの役割、専任・兼任の別、想定稼働率、契約後の実務窓口です。営業段階で説明した担当者と、開始後に日常対応する担当者が同じとは限りません。可能であれば、実際に参加予定のPMやBrSEとの面談も比較プロセスに含めます。

また、欠員や交代が生じた場合の補充方針、引き継ぎ期間、追加費用の有無も確認しておきたい項目です。単価が安くても、体制維持の考え方が曖昧であれば、継続案件ではリスクになります。

VOCの既存記事でも、社内稟議では費用とスケジュールだけでなく、責任者、日常的な窓口、品質確認の流れを体制図で示すことが重要だと整理しています。見積比較の段階でも、各社の体制を同じ役割区分で並べると、違いを説明しやすくなります。

03品質管理と受入条件をそろえる

品質について「高品質です」「レビューを行います」と説明されても、それだけでは比較できません。誰が、何を、どのタイミングで確認するのかまで具体化します。

確認項目としては、設計レビューとコードレビューの担当者、テスト工程、障害管理方法、品質報告の内容、受入条件、不具合修正の扱いが挙げられます。非機能要件についても、性能、セキュリティ、可用性、バックアップ、ログなど、案件に必要な項目をどこまで見積もりに含めたかを確認します。

特に注意したいのは、各社が異なる品質水準を想定しているケースです。一方は本番運用を前提としたテストを見込み、もう一方は最低限の動作確認だけを見込んでいれば、価格差が出るのは当然です。価格を評価する前に、想定する完成条件をそろえる必要があります。

受入条件が未確定の場合は、契約前にすべてを決め切るのではなく、「いつ、誰が、どの資料をもとに決定するか」を合意しておきます。

04日本側に必要な作業と工数をそろえる

見積書に表れにくいものとして、日本側の関与工数があります。

要件や優先順位の判断、質問への回答、定例会、成果物レビュー、受入テスト、社内調整、環境・アカウント準備などは、開発会社へ委託しても日本側に残ります。ただし、開発会社の支援範囲によって、日本側の負荷は変わります。

各社には「日本側で必要となる役割」「週当たりの想定工数」「回答が必要な事項」「判断が遅れた場合の影響」を聞いてください。日本側のPMが週に数時間関与すればよい提案と、要件整理や進捗管理を日常的に行う必要がある提案では、総コストが異なります。

ここでいう総コストは、外注費に自社の人件費を機械的に足せばよいという意味ではありません。候補会社ごとに、どの作業が自社へ残るのかを把握し、現実的に運営できるかを確認することが目的です。

05追加費用と変更対応の前提をそろえる

開発中には、仕様変更や追加要望が発生します。重要なのは、変更をゼロにすることではなく、変更時の判断手順を比較しておくことです。

確認したいのは、変更要求の受付方法、影響調査を行う担当者、再見積もりの条件、納期への反映方法、承認者です。仕様変更以外にも、環境構築、クラウド利用料、有料ツール、翻訳、出張、メンバー交代、時間外対応などが別料金になるかを確認します。

経済産業省の情報システム・モデル取引・契約書でも、契約、変更管理手続、役割分担を明確にする必要性が示されています。初期見積もりだけでなく、条件が変わったときの扱いまで比較することが、予算超過や認識違いを防ぐうえで重要です。

比較表では、「見積金額」の隣に「追加費用となる条件」と「変更時の手続」を設けます。最安値を探すのではなく、費用が変動する条件を把握するための欄です。

仮想例で見る:総額だけでは誤る比較

今回は現場当事者から提供された実例がないため、特定の企業や案件の経験として紹介できる事例はありません。そこで、比較時に起こり得る状況を仮想例として整理します。

ある開発責任者が、同じWebシステムの追加開発についてA社、B社、C社から見積もりを取得したとします。総額はA社が最も安く、C社が最も高い結果でした。

比較観点 A社 B社 C社
見積の印象 最も安い 中間 最も高い
主な範囲 実装+単体テスト BrSE込み PM・BrSE・QA込み
対象外になりやすいもの 要件整理、BrSE、結合テスト テストケース作成、受入支援 (含む範囲が広い)
日本側に残りやすい作業 上流〜テスト管理 テスト設計・受入 相対的に少ない

この3社を総額だけで順位付けするとA社が第一候補になります。一方、自社に要件整理やテスト管理を担う余力がない場合、A社を選ぶと、日本側の負荷や追加発注が増える可能性があります。反対に、自社で上流工程と品質管理を担える場合は、A社の限定された役割が合理的かもしれません。

この仮想例が示すのは、「高い会社がよい」「安い会社が危険」ということではありません。各社が担当する範囲と、自社に残る仕事をそろえて初めて、価格の意味を判断できるということです。

比較を進めるときの注意点

比較条件をそろえる際は、各社に同じ質問を送り、回答を記録してください。口頭で確認した内容も議事録や質問回答表に残します。未回答の項目を担当者の推測で埋めると、比較表の見た目だけが整い、判断を誤る原因になります。

また、すべてを点数化すれば自動的に正解が出るわけではありません。まず、満たさなければ候補から外す必須条件を決めます。そのうえで、価格、体制、品質、コミュニケーション、実績などの評価項目に、自社の課題に応じた重みを付けます。

たとえば、初めてオフショア開発を利用し、日本側の管理経験が少ない企業では、単価よりも要件整理支援やBrSEの力量を重視する考え方があります。一方、仕様が明確で、日本側に十分なPM・QA体制がある場合は、実装力や供給力を重視できます。

最終的には、「なぜこの会社を選ぶのか」だけでなく、「選ばなかった会社との差は何か」「残る懸念を契約後にどう管理するか」まで一文で説明できる状態を目指してください。

まとめ

オフショア開発会社3社を比較するとき、最初に行うべきことは、見積総額を並べることではありません。

委託する業務範囲と成果物、体制と役割、品質管理と受入条件、日本側に必要な作業、追加費用と変更対応。この5つを同じ項目で確認することで、各社の価格差が何から生じているのかが見えやすくなります。

条件をそろえた後は、各社が実際に安定した開発体制を運営できるかを見極める段階です。コミュニケーション体制、要件整理の進め方、PM・BrSEの力量、品質管理、立ち上げ支援などは、提案書の金額だけでは判断できません。