オフショア開発のトライアルは1名・1か月から【2026年版】5つの評価軸と無料トライアルの落とし穴

「いきなり年間契約は怖いので、まず小さく試したい」——オフショア開発の検討を進めている方から、こうしたご相談をよく受けます。提案書は各社きれいに整っている、面談の受け答えも悪くない。それでも、海外のチームと本当に仕事が回るのかは、動かしてみるまで分からない。この感覚は正しいと考えています。

結論から言うと、オフショア開発はいきなり大型契約を結ばず、1名・1か月・PoCの小さな範囲から始めてください。ただし、ただ「試す」だけでは判断材料になりません。対象タスクを独立して検収できる範囲に切り出し、コード品質、レビュー指摘への反応、報告の粒度、日本語や英語の通じ方、見積もり精度という5つの軸を評価シートにして、合格ラインを開始前に決めておく。ここまで設計して初めて、トライアルは本契約の判断に使えます。

逆に、評価基準を決めずに始めると「まあ悪くなかった」という印象論で終わります。これが最ももったいない結果です。1か月と数十万円を投じたのに、社内には何の判断材料も残らず、結局は単価の安さで決めてしまう。評価基準を決めずに始めるのは、失敗のもとです。

本記事では、トライアルを3つの型(実力検証型・PoC型・無料トライアル型)に分けたうえで、対象タスクの切り出し方、期間と費用の目安、5つの評価軸と評価シートの作り方、そして無料トライアルのエース投入をはじめとする落とし穴3つと本契約への移行条件を、この順で解説します。評価シートはそのまま社内の稟議資料に転用できる形で示します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社では、無料トライアルではなく1名・1か月の有償スモールスタートをお勧めしています。その理由も含めて、最後までお読みいただければ、自社の案件でどう検証を設計すればよいかが決まるはずです。

オフショア開発は小さく始める——いきなり大型契約をしない理由と、トライアルの3類型

オフショア開発の会社選びは、資料請求と比較表で候補を3社まで絞るところまでは、誰でも同じ手順で進められます。問題はその先です。設立年も拠点も実績件数も似た3社が並んだとき、何を根拠に1社を選ぶのか。ここで多くの企業が単価の安さで決め、後から品質とコミュニケーションで苦労します。トライアル、つまり小さく試してから決めるという選択肢は、この最後の一歩のためにあります。

提案書と面談で分かるのは「語れること」まで——一緒に働けるかは動かしてみないと見えない

提案書と面談で確認できるのは、その会社が自社について何を語れるかまでです。窓口の日本語の水準、近い実績を3件挙げられるか、見積もりに管理工数が計上されているか。これらは面談で判定できますし、判定すべきです。詳しい確認項目は「オフショア開発 会社」の記事にまとめています。

ただし、実際に一緒に働けるかどうかは別の話です。仕様の抜けに気づいて質問が飛んでくるか、指摘した不具合が何日で直るか、進捗の報告が指示されなくても上がってくるか。この3つは、面談でいくら聞いても「できます」としか返ってきません。動かしてみて初めて見えるのが実情です。

そしてこの3つは、小さな範囲でも2〜3週間あればはっきり現れます。だからこそ、本番案件の前に小さく発注して実力を測る方法に意味があります。

トライアルの3類型(実力検証型・PoC型・無料トライアル型)——目的が違えば設計も評価も変わる

ここで注意していただきたいのが、「トライアル」という一語が3つの別物を指している点です。相談の場でも、発注側と開発会社側が違う型を思い浮かべたまま話が進み、終わってから期待外れになる場面をよく見ます。まず型を決めてください。

実力検証型とPoC型は、同じ1か月でも見るものが違います。PoCは「作れるか」への答えを出すもので、開発会社の日常の仕事ぶりまでは測りません。逆に実力検証型は、成果物の派手さより、やり取りの質に注目します。両方を確かめたい場合は、同じ案件で走らせても構いませんが、評価シートは分けてください。

無料トライアル型については、業界に実在する提供形態です。ISBは自社サイトで、ラボ型オフショア開発の初月20%OFFを先着5社限定とするキャンペーンを公表しています。シスラボは自社のプレスリリースで一部無料トライアルを打ち出し、JVBは自社サイトで1か月からのお試しラボ型を実施可能と公表しています。無料かどうかより、「誰が担当し、本契約でその人が続くのか」のほうが、判断には重要です。この点は後ほど落とし穴として詳しく扱います。

1名・1か月・PoCで検証する——意思決定のリスクを数十万円に置き換える

小さく始める最大の理由は、意思決定のリスクを金額に換算して小さくできることです。ベトナムオフショア開発で実務3年相当のエンジニアを1名、1か月確保保する費用は、当社の公開単価で1,500USD(約22.5万円・1USD=150円換算目安)です。日本人PMをフロントに置く最小構成でも月額約80万円からになります。一方、年間契約でチームを組めば、数千万円規模の判断になります。

社内の決裁で考えると、この差は決定的です。数千万円の判断には経営会議が要りますが、数十万円から100万円程度の検証であれば、部門の裁量で始められる企業が多いはずです。しかも検証の結果は、そのまま次の稟議の根拠になります。

当社でも、最初から大きな体制で始めた案件はほとんどありません。介護記録SaaSの「CareViewer」は、日本語対応のブリッジSE1名とフルスタックエンジニア2名という小さな体制で始め、週次で優先順位を判断しながら継続開発に移った案件です。お客様からは「想像以上にエンジニアのレベルが高い」という評価をいただきましたが、それも動かしてみた結果として出てきた言葉でした。

では、何を、どのくらいの期間で、どう測ればよいのか。次章で設計の手順を具体的に見ていきます。

トライアルの設計——対象タスクの切り出し方、期間と費用の目安、5つの評価軸と評価シート

トライアルの成否は、開発が始まる前に決まります。何を渡すか、どのくらいの期間で区切るか、何を見て合否とするか。この3点を決めずに「とりあえず1か月お願いします」と始めると、終わったあとに残るのは感想だけです。ここでは、そのまま社内の検証計画書に転用できる形で設計の手順を示します。

対象タスクの切り出し方——入出力が明確で単独で検収できる範囲を渡す

最も多い失敗が、本体と密結合した機能を渡してしまうことです。既存システムの中核に絡む機能を切り出すと、仕様の説明だけで工数が膨らみ、測っているのは開発会社の実力ではなく自社の説明の巧拙になります。私が相談を受けるなかでも、独立性の低い機能を切り出した検証は、ほぼ例外なく判断材料が得られないまま終わっています。

切り出す範囲は、入出力が明確で単独で検収できるものを選んでください。

当社の実績で言えば、決済アプリ(Stripe連携・二要素認証・ウォレット・PDF出力)や求人プラットフォーム、AIチャットボットのように、機能単位で区切りやすい領域はトライアルに向きます。逆に、要件がこれから固まる新規事業の構想段階は、実力検証よりもPoC型で設計したほうが目的に合います。

期間と費用の目安——1名・1か月で区切る。テトと祝日の織り込み方

当社は、1名・1か月を基本の区切りとしてお勧めしています。短すぎると立ち上げだけで終わり、長すぎると判断が遅れて機会を失うためです。金額は、検証が空振りに終わっても事業計画が揺らがない範囲に収めてください。実務3年相当のエンジニア1名であれば、当社の公開単価で1か月1,500USD(約22.5万円・1USD=150円換算目安)です。

費用の考え方は単純です。ベトナムオフショア開発の当社公開単価は、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年目安・ブリッジSEで3,000USDです(いずれも1人月、円表記は1USD=150円での換算目安)。実力検証型なら1名1か月で20万円台、日本人PMをフロントに置く最小構成でも2〜3人月で月額約80万円からになります。PoC専門の株式会社デュナミスが自社サイトで初回スコープ50万円〜を公開していること(2026年9月21日確認)と比べても、検証にかけられる金額としては現実的な範囲に収まります。

見落とされやすいのが休暇の影響です。ベトナムの祝日は2026年で年12日(労働法112条の法定は11日で、2026年からベトナム文化の日が加わります)で日本より少ないのですが、旧正月のテト休暇はまとまって取得され、2026年は2月14日から22日までが予定されています。この時期を挟むトライアルは、稼働日が実質2週間を切ることがあります。期間を日数ではなく稼働日で合意しておくと、後から揉めません。時差は2時間で、日本の営業時間と6時間以上重なるため、当日中の往復は問題なくできます。

5つの評価軸(コード品質・レビュー指摘への反応・報告の粒度・言語の通じ方・見積もり精度)

ここが本記事の中心です。トライアルで見るべきは、成果物が動いたかどうかだけではありません。本番でも同じ形で現れる5つの要素を、意識的に観察してください。

このうち、発注側が最も軽視しがちなのが「レビュー指摘への反応」と「報告の粒度」です。成果物の出来は、経験年数が上がればある程度そろいます。一方、指摘への反応と報告の習慣は会社の文化に根ざしており、本契約後も変わりません。当社が品質の柱として、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を仕組みにしているのも、個人の力量ではなく手順で品質を担保するためです。

言語については、日本語と英語のどちらで回すかを先に決めてください。ブリッジSEや日本人PMが入る体制なら日本語で完結しますが、エンジニアのみの体制なら英語または翻訳を介したやり取りになります。詳しくは「オフショア開発 英語」の記事で扱っています。

評価シートの作り方——5軸×5点の25点満点、合格ライン18点、必須項目を先に決める

5つの軸をそれぞれ5点で採点し、25点満点にしてください。当社が相談の場でお勧めしている合格ラインは18点です。全体で7割強という水準で、どこかに弱点があっても他で補える会社は通り、全体的に平凡な会社は落ちます。

あわせて、点数とは別に「必須項目」を2つか3つ決めます。たとえば「遅れの報告が期限より前に来ること」「同じ指摘の再発が2回以上ないこと」は、合計点が高くても満たさなければ不合格にする、という運用です。総合点だけで判断すると、致命的な弱点が平均に埋もれます。

採点は開始前に印刷して、週次の定例のたびに埋めてください。終了後にまとめて思い出しながら書くと、最後の週の印象に引きずられます。この評価シートは、そのまま社内の稟議資料に添付できます。「試してみて良さそうだった」ではなく「25点中21点、必須項目は2件とも充足」と書ける状態にしておくことが、検証に数十万円を投じる意味です。

トライアルの落とし穴3つと、本契約への移行条件——当社の始め方

設計の型が決まったところで、実際に起きる失敗を先にお伝えします。トライアル自体は良い判断なのに、設計を誤って「判断できないまま1か月を使った」という結末になる例が少なくありません。落とし穴は大きく3つです。

落とし穴3つ(無料トライアルのエース投入、対象タスクの大きさ、評価基準を決めずに始める)

3つのうち、金額の話ではないのに最も影響が大きいのが1番です。無料であること自体が悪いわけではありません。問題は、無料枠に出てくる人財と、本契約後にアサインされる人財が同じである保証がないことです。ここを確認せずに無料トライアルの結果で決めるのは、要注意です。

確認する質問は1つで足ります。「今回担当された方は、本契約でもこのプロジェクトに入りますか。入らない場合、実際に入る方と契約前に面談させてください」。この問いに具体的に答えられない会社は、その時点で判断材料が出せていません。

本契約への移行条件——合格ライン、成果物の権利、不合格時の扱いを開始前に書面化する

トライアルを始める前に、次の4点を合意して文書に残してください。口頭の合意で済ませると、終了時に双方の記憶が食い違います。

• 合格ラインと評価軸:5軸25点の採点表と合格点、必須項目。開発会社にも事前に共有します。評価される側が基準を知っているのは、公平さの担保であり、手抜きにはなりません
• 成果物の権利と引き渡し:トライアルで作ったコードの著作権が誰に帰属し、不合格の場合に引き渡されるのか。詳しくは「知的財産 帰属」の記事で扱っています
• 不合格時の扱い:本契約に進まない場合の清算方法と、その旨をいつまでに通知するか。先に決めておけば、断ることは気まずい交渉ではなく普通の手続きになります
• 本契約の条件:合格した場合の単価、体制、開始時期、最低契約期間。ここが未定のままだと、良い結果が出ても交渉が振り出しに戻ります

当社の始め方——1名から・最短2週間・契約前面談・増員約1週間・1か月単位のリプレイスメント

当社は無料トライアルを提供していません。無料枠のために一時的な体制を組むより、実際に担当する人財を最初から入れたほうが、お客様の判断材料として正確だと考えているためです。代わりに、1名・1か月の有償スモールスタートをお勧めしています。

この条件が成り立つのは、グループの人材紹介事業が持つ2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインしており、協力会社を経由する仲介マージンが発生しないためです。1名からの小さな契約でも体制を組めるのは、この構造によります。

一方で、正直に申し上げると、トライアルが向かない案件もあります。要件が確定していて納期が決まっている単発の開発は、検証に1か月使う余裕がないはずです。その場合は請負契約で仕様を固めて発注したほうが早く、当社でもそう申し上げています。ラボ型と請負のどちらを選ぶかは「ラボ型開発」の記事で整理しました。自社の案件は、検証してから決めるだけの時間がある案件でしょうか。

オフショア開発のトライアルでよくある質問

トライアルについて、相談の場で繰り返しお受けする質問を5つにまとめました。開発会社への質問リストとしてもお使いください。

Q1. オフショア開発に無料トライアルはありますか?

あります。初月20%OFFのようなキャンペーンや、一部機能を無償で実装する形が実在します。ただし無料枠に出た人財が本契約でも担当する保証はないため、「今回の担当者が本契約でも入るか」を必ず確認してください。当社は無料トライアルを提供せず、1名・1か月の有償スモールスタートをお勧めしています。

Q2. 期間と費用はどのくらいが目安ですか?

当社は1名・1か月を基本の区切りとしてお勧めしています。金額は、検証が空振りに終わっても事業計画が揺らがない範囲に収めてください。実務3年相当のエンジニア1名であれば、当社の公開単価で1か月1,500USD(約22.5万円・1USD=150円換算目安)です。ベトナムのテト休暇(2026年は2月14日〜22日)を挟む場合は、日数ではなく稼働日で合意してください。

Q3. 何人で始めるのがよいですか?

実力検証が目的なら1名で十分です。人数を増やすと、測っているのが個人の力量なのかチームの運用なのか分からなくなります。日本語でのやり取りを確かめたい場合は、日本人PMまたはブリッジSEを加えた2名構成にしてください。当社は1名から契約でき、増員は約1週間です。

Q4. 結果が悪かった場合、断れますか?

断れます。開始前に合格ラインと、不合格時の清算方法・通知期限を書面で合意しておけば、断ることは普通の手続きになります。曖昧なまま始めると気まずさが生まれるので、断る前提の条件を先に決めておくほうが双方にとって健全です。

Q5. PoCと開発会社の実力検証は同時にできますか?

できますが、評価シートは分けてください。PoCは「作れるか」を、実力検証は「一緒に働けるか」を見るもので、判断材料が別だからです。同時に走らせる場合は、PoCの納品物を動くプロトタイプ・検証レポート・本開発の見積もりの3点とし、実力検証は5軸25点で採点するという二重の設計。

まとめ: 小さく始めて、5軸で測る——トライアルは「お試し」ではなく意思決定の道具

オフショア開発は、いきなり大型契約を結ばず、1名・1か月・PoCの小さな範囲から始めてください。提案書と面談で分かるのは、その会社が何を語れるかまでです。仕様の質問がどれだけ的確に飛んでくるか、指摘した不具合が何日で直るか、報告が指示なしに上がってくるか。この3つは動かしてみて初めて見えますが、小さな範囲でも2〜3週間あれば現れます。

設計の要点は3つです。第一に、入出力が明確で単独で検収できる範囲を切り出すこと。管理画面の一機能、外部サービスとの連携、既存画面の作り替えが向き、本体と密結合した機能は避けます。第二に、期間は1名・1か月で区切り、金額は検証が空振りに終わっても事業計画が揺らがない範囲に収めること。第三に、コード品質、レビュー指摘への反応、報告の粒度、日本語や英語の通じ方、見積もり精度の5軸を5点ずつ採点し、25点満点・合格ライン18点と必須項目を開始前に決めることです。落とし穴は、無料トライアルのエース投入、対象タスクが小さすぎる/大きすぎる、評価基準を決めずに始めるの3つでした。

当社は無料トライアルを提供せず、1名・1か月の有償スモールスタートをお勧めしています。実際に担当する人財を契約前の候補者面談でご覧いただき、最短2週間で開始、増員は約1週間、縮小と交代は1か月単位で調整できます。オフショア開発の全体像はオフショア開発の進め方、会社選定の確認項目はオフショア開発会社の選び方もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どの範囲をどう切り出して検証すればよいかの設計と、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。