オフショア開発のメリット・デメリット｜委託先国の動向と契約形態の選び方

海外赴任のあいだに、オフィスのテーブルを組み替えてもらったことがあります。

板の枚数、ねじの型番、どの板から先に入れるか。紙に書いて送ったら、そのとおりに組み上がった写真が届きました。ところが、天板と脚のあいだの間隔だけが、思っていたものと違います。

翌日、「もう少し詰めてほしい」と電話し、また写真が届く。まだ違う。3回目で、ようやく合いました。紙に書いたとおりのものは、1回で組み上がっています。書けなかった間隔だけが、電話3回ぶんかかりました。

ソフトウェアを海外の開発会社に発注して作ってもらう、オフショア開発を使う会社が増えてきました。国内で人を採用しても間に合わず、また、国内のエンジニアの品質を上回る先端技術の知見と単価の差も無視できないからです。

僕も、オフショア開発をやっていますが、最初はことごとく失敗しました。決めるべきことを全部書き切った設計書を渡し、そのとおりのものが上がってきたのに、そこから細かい直しが止まらなくなりました。いちばん小さかったのは、画面の余白の値を１箇所だけ書き換えるために、海外と1往復するというものでした。

先に一行だけ置きます。ここでいう往復とは、依頼を送り、返ってきた結果を確認するまでの一連のやり取りです。オフショア開発で効いてくるのは、時間あたりの単価ではなく、往復の回数です。 単価は契約で決まりますが、往復の回数は仕事の分け方で決まります。

この話に出てくる事業

大企業と僕の会社が組んで立ち上げた新規事業で、必要最小限の機能を備えた試作品（MVP）のひとつに、車の正規ディーラー（自動車メーカーが正式に認めた販売店）が使う、整備予約と入庫管理（車を工場へ受け入れる予定の管理）の画面があります。この画面を使うのはディーラーと工場で、僕の会社はそのシステムを開発する役割です。

受付のカウンターに立つのは、ディーラーの拠点あたり2名です。電話で「来週の土曜に車検をお願いしたい」とお客様に言われたら、その瞬間に、代車の空き、整備士の空き、部品の入荷を同時に見て、その場で日を決めます。整備士は8名。工場側で、その日に整備を受け入れる車の並びを見ています。

このシステムを、オフショア開発で作ることにしました。 国内の人手では、年度内にシステム開発が完了できる見込みがなかったからです。最初のリリース（利用者が使える状態にした版）を受付に置くところまでは、オフショア開発で進めました。そして、PoCを通じて、不満を抽出し、まとめて直す時が来ました。その直しに関する工程が、この話の舞台です。

今日は上記のPoC後の直し工程を通じて、オフショア開発に何を渡して、何を手元に残すか、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、設計書を書き切ってから発注した

オフショア開発とは

オフショア開発とは、ソフトウェアの開発を海外の企業や自社の海外拠点へ委託することです。設計・実装・テストといった工程の一部、あるいは全部を海外側が担当します。

国内の開発会社に発注する場合と違うのは、作業する人が別の国の、別の時間帯にいるという一点です。この一点から、後で出てくるメリットもデメリットも派生します。

オフショア開発の主な目的

目的は、大きく3つに分かれます。どれを主目的にするかで、委託先の選び方も契約形態も変わります。

• リソースの確保 — 国内で採用できない職種・人数を、短期間で揃える
• コストの最適化 — 同じ工数を、より低い単価で処理する
• 開発スピードの確保 — 人数を掛けて、並行して進める
• 事業拡大への柔軟性 — 需要に合わせて体制を増減できる

「コスト削減」だけを目的に置くと、判断を誤りやすくなります。単価は下がっても、後述する往復のぶんだけ時間が増えるためです。

なぜ今、オフショア開発が拡大しているのか

理由は4つに整理できます。

• 国内でIT人材の確保が難しくなっている
• 国内の人件費と開発費が上がっている
• 委託先国の技術力が上がっている
• 発注の手法が成熟し、進め方の型ができた

4つ目が効いています。かつては「やってみないと分からない」領域でしたが、契約形態も体制の作り方も型ができました。失敗の理由も共有されています。

オフショア開発の現状

かつては大企業が大規模開発をコスト目的で出す形が中心でしたが、いまは中小企業やスタートアップが、必要な工程だけを切り出して出す形が増えています。

目的も「安く作る」から「国内で採れない技術者を確保する」「体制を柔軟に増減する」へ移りました。この変化は、次に述べる委託先国の選び方にそのまま現れます。

主な委託先国

ベトナムが中心で、インド、フィリピン、中国、ミャンマー、バングラデシュなどが続きます。国によって、得意な領域と単価帯が違います。

国	特徴
ベトナム	日本語対応の層が厚く、対日案件の実績が最も多い。時差2時間
インド	技術者の絶対数が多く、高度な領域に強い。英語が前提。時差3.5時間
フィリピン	英語力が高い。BPOとの組み合わせが多い。時差1時間
中国	大規模開発の実績が長い。単価は上昇傾向。時差1時間
ミャンマー・バングラデシュ	単価が低い。日本語対応の層はこれから

委託先国の人気動向

ベトナムの一極集中が続いていますが、人件費の上昇にともなって、次の委託先を探す動きが出ています。ミャンマーやバングラデシュが候補に挙がるのは、この文脈です。

ただし、単価だけで移すと、日本語対応と実績の層が薄いぶんを自社で負担することになります。移す判断は、次の「選定基準の変化」とあわせて考える必要があります。

選定基準の変化

選ばれる理由が変わってきています。かつては単価の安さが決め手でしたが、各国の人件費が上がるにつれ、比重を増しているのは次の条件です。

• 日本語対応の厚み — ブリッジSEだけでなく、開発側にも読める人がいるか
• 技術者の定着率 — 人が入れ替わると、蓄積したノウハウが消える
• 時差の小ささ — 質問して回答が返るまでの時間に直結する
• 対日案件の実績 — 日本の商習慣（検収・仕様変更の扱い）に慣れているか

単価表だけで比べると、判断を誤ります。上の4つは見積書に金額として出てきませんが、後から必ず費用として現れます。

メリット1｜国内で採れない人材を確保できる

国内で募集しても集まらない職種を、まとまった人数で確保できます。人数を短期間で増減できるのも、採用と違う点です。プロジェクトの立ち上がりに合わせて増やし、収束に合わせて減らすことができます。

メリット2｜コストを抑えやすい

国によっては、国内の半分以下の単価で同等の工程を任せられます。ただし、下がるのは単価であって、総額ではありません。ブリッジSEの人件費、仕様を書き切る工数、確認の往復にかかる時間は別途かかります。

メリット3｜対応できる業務の幅が広がる

国内では手が回らない領域——たとえばテストの網羅、既存システムの保守、データ整備といった工程を、まとめて引き取ってもらえます。手が空くぶん、国内側は仕様を決める仕事に集中できます。

メリット4｜短納期を実現しやすい

人数を掛けて並行して進められるため、国内だけで組むより工期を詰められます。ただし、並行できるのは「独立して進められる単位に割れている場合」だけです。割れていない仕事に人数を掛けると、確認の往復が増えて逆に遅くなります。

デメリット1｜コミュニケーションのコストがかかる

言語の違いだけではありません。時差があるため、質問を送ってから回答が返るまでに日数がかかります。同じ内容の確認でも、隣の席なら1分、海外なら翌日になります。

これを「言語の問題」と読むと、対策を間違えます。通訳や翻訳ツールを入れても、往復にかかる日数は変わりません。この記事の後半は、そこの話です。

デメリット2｜進捗の管理が難しい

作業している様子が見えないため、問題が起きていることに気づくのが遅れます。週次の報告だけにすると、ずれに気づいたときには1週間ぶん進んでいます。動くものを短い間隔で見せてもらう取り決めが要ります。

デメリット3｜海外ならではのリスクがある

法制度、祝日、為替が国ごとに違います。祝日の見落としは、スケジュールに直接効きます。テトや旧正月のように1週間以上止まる時期がある国では、その前提で計画を組む必要があります。

デメリット4｜小規模では効果が出にくい

体制の立ち上げ、仕様の伝達、品質基準のすり合わせに固定費がかかります。短期・小規模の案件では、この固定費を回収できません。一定量の発注が続く見込みがあるかどうかが、判断の分かれ目になります。

デメリット5｜文化や国民性による認識の違いが出る

「できます」の意味が国によって違います。日本側が「期日までに完成させる」と読む返事が、「指示どおりにやる」という意味で返ってきていることがあります。

できたかどうかを言葉で確認せず、動くものか、数字で見るのが確実です。報告の頻度ではなく、報告の形式を決めます。

デメリット6｜要件仕様の理解が食い違う

同じ仕様書を読んでも、前提が共有されていないと別のものが上がってきます。日本の商習慣では省略される前提——たとえば「該当データが無いときは何も表示しない」——が、書かれていなければ書かれていないとおりに実装されます。

例外のときにどうなるかを、要件に書いてあるかどうかで差が出ます。

トラブルが起きる主な要因

起きるトラブルは、だいたい次のどれかに当てはまります。

要因	現れ方
仕様の解釈がずれる	書いたとおりのものが上がってくるが、意図と違う
品質基準が共有されていない	「動く」の水準が発注側と受注側で違う
確認の往復が多い	1つ直すたびに日数がかかり、全体が遅れる
担当者が入れ替わる	説明済みの前提が引き継がれない
発注側が決められない	質問が返ってきても回答できず、手が止まる

最後の1つは、発注側の問題です。オフショアの成否は委託先の力量だけで決まらず、「聞かれたことに、その日のうちに答えられる人が国内にいるか」で大きく変わります。

ブリッジSEの役割

日本側と現地側のあいだに立ち、仕様を翻訳し、確認を代行する役割です。言語の橋渡しだと理解されがちですが、実務上の価値は「往復の回数を減らすこと」にあります。

曖昧な指示をそのまま流さず、手前で確定させる。現地から上がってきた質問を、日本側に投げる前に自分で判断できる範囲は判断する。ここが機能しているかどうかで、同じ委託先でも進み方が変わります。

成功している発注の共通点

うまく回っている案件には、次の共通点があります。

• 目的が1つに絞られている — コスト削減とスピード確保を同時に狙っていない
• 小さく始めている — いきなり本体を渡さず、切り出せる工程から試している
• 渡す仕事の単位が決まっている — 画面単位か、機能単位か、原因単位かが定まっている
• 国内側に決められる人がいる — 質問にその日のうちに答えられる
• 同じチームを継続して使っている — 前提の説明をやり直さずに済む

逆に、うまくいっていない案件の多くは、委託先ではなく渡し方に原因があります。この記事の後半は、その渡し方を1箇所だけ変えた記録です。

オフショア開発を成功させるポイント

ポイント	具体的にやること
目的を1つに絞る	コスト削減とスピード確保を同時に狙わない。優先順位を先に決める
パートナー選定の精度を上げる	単価表ではなく、対日案件の実績・技術者の定着率・日本語対応の層で見る
コミュニケーションを設計する	頻度ではなく形式を決める。動くものを見る間隔と、質問の返答期限を決める
進捗と納期を数字で追う	「順調です」を受け取らない。完了した単位の数で見る
発注前の準備を入念に行う	仕様、テスト環境、判断できる担当者。この3つを揃えてから渡す

4つ目が抜けると、遅れの発覚が遅れます。報告の言葉ではなく、完了した単位の数で追ってください。

オフショア開発を発注するときの注意点

注意点	手を抜くと
要件定義を徹底する	例外のときの挙動が書かれておらず、そのぶんが手戻りになる
発注先の選定を、実績で確認する	対日案件の経験が無いと、検収や仕様変更の商習慣から説明が要る
セキュリティ対策を契約で決める	ソースコードと個人データの取り扱いが曖昧なまま作業が始まる
コミュニケーションの方法を工夫する	文章だけで往復し、1つの確認に何日もかかる
祝日と稼働日を先に確認する	旧正月などで1週間以上止まり、計画がずれる

セキュリティは、契約時に決めておく項目です。ソースコードの持ち出し可否、個人データを扱う範囲、作業環境と端末の条件、再委託の可否。国をまたぐと適用される法律も変わるので、着手後に決めようとすると止まります。

ニアショア開発との違い

	委託先	何が変わるか
オフショア	海外	単価が下がる。時差と距離で往復が増える
ニアショア	国内の地方	単価の下げ幅は小さい。往復が速い

この2つを分ける軸は、距離ではなく往復の回数です。仕様を書き切れる工程ならオフショアが効き、書き切れない工程ではニアショアの速さが効きます。（この見方が、この記事の後半の主題になります）

契約形態の選び方

請負契約とラボ契約のどちらかを選びます。

	向いているとき	仕様が変わったら
請負	作るものが確定している	追加見積もり
ラボ型	作りながら決める前提	確保した時間の使い方が変わる

ラボ型の詳細はラボ型開発とは？メリット・デメリットと請負との違いに整理しています。

AI時代に、オフショア開発の価値はどう変わるか

生成AIによって実装の速度が上がったことで、「人手を増やす」ことの価値は相対的に下がっています。一方で、仕様を確定させる工程、レビューする工程、判断する工程は残ります。

オフショアの役割は、量を引き受けることから、確定した仕様を確実に処理することへ移りつつあります。そうなると、「何を確定と見なすか」を決める力が、発注側にいっそう求められます。

オフショア開発のよくある質問

Q. オフショア開発の費用は、国内発注と比べてどのくらい違いますか。
単価では国内の半分程度になる国もありますが、総額は単価だけでは決まりません。ブリッジSEの人件費、仕様を書き切る工数、確認の往復にかかる時間を含めて比べる必要があります。

Q. どの国に頼むのがよいですか。
対日案件の実績と日本語対応の厚みで選ぶならベトナム、高度な技術領域で英語が使えるならインド、というのが一般的な目安です。単価表の順に選ぶと、後から差が出ます。

Q. 小規模でもオフショア開発は使えますか。
体制の立ち上げに固定費がかかるため、単発・小規模では回収できないことが多いです。継続して発注する見込みがあるかどうかで判断してください。

Q. 仕様書を細かく書けば、手戻りは防げますか。
防げる部分と、防げない部分があります。書き切れる項目は書けば減りますが、書けない項目は書いても減りません。この記事の後半は、その線引きの話です。

Q. ブリッジSEは必ず必要ですか。
現地に日本語で読み書きできる担当がいれば、専任を置かない形もあります。ただし「往復の手前で確定させる人」がどこかに要る点は変わりません。

オフショア開発の教科書に書いてあることは、はっきりしています。曖昧な仕様を渡さないこと。決めるべきことは先に決めておくこと。独立して進められる単位に割って渡すこと。 どれも、そのとおりだと思います。

だから、素直にやりました。ディーラーの受付担当者から出てきた不満を6件に整理し、その1件ずつがプログラムのどのファイルのどの行から来ているかを表にしました。

「代車の空きは、予約が確定した時点で押さえる」というような、迷いそうなディーラーからの要求仕様は全部そのタイミングで潰しています。詳細仕様を決めずに渡すものを1つも残さなかった結果、設計書は134行になりました。

そのうえで、6件の不満を、そのまま独立して進められる6件の作業に割りました。渡したのは作業の名前ではなく、触るファイル名と、そこで何をするかです。

上がってきたものは、仕様どおりでした。 6件の作業が全部、1日で返ってきています。予約一覧も、整備士側の一覧画面も、書いたとおりに動きました。

この日は、うまくいったと思っていました。

ここまでが、オフショア開発の教科書どおりの整理です。国を選び、ブリッジSEを立て、契約形態を合わせる。条件が揃えば、この形は機能します。

この記事の後半で扱うのは、条件が揃っていた案件の話です。単価表には出てこないところで、費用が動きました。

仕事の分け方から設計するオフショア開発の体制は、Global AI Lab（オフショア・ラボ型開発）のページに整理しています。何を渡して何を手元に残すか決めかねている場合は、こちらからご相談ください。

② そのとおりに上がってきたのに、直しが止まらなかった

翌日、拠点の受付カウンターで、実物の端末に入れて開きました。

ここから、直しが止まりませんでした。

その日のうちに入った直しは14件です。そのうち11件は設計書に書かれていないもので、実物を開いて初めて出ました。設計書に書けたことは1日で終わったのに、書けなかったことは、実物を開いたその日から出はじめました。

中身を書き出すと、次のようになります。「予約一覧の上端の余白をそろえてほしい」。「予約1件ぶんの枠の下の余白を12pxから24pxに」。「どちらか一方を選ぶ丸印で、選んでいないほうを白にしてほしい」。整備士側の一覧画面については、「実物で見ると余白が詰まって見える」という一言が返ってきました。

どれも、仕様どおりです。 設計書に、上端の余白をいくつにするとは書いていません。書いていないので、海外の開発会社が決めました。決めた値が、カウンターで見ると違っただけです。

ただ、実物を開いて初めて出た直しは、1回では終わりません。値を変え、実物に入れ、また開いて見る。見て決まるものは、見るたびに1往復ずつ増えていきます。

実物を開いたことが起点の直しは、最終的に16件になりました。1件につき最低1往復かかるので、海外とのやり取りが16回増えたということです。

③ 気づいたのは、直しの中身を行数で数えたときでした

回数だけなら、まだ「そういうものか」で終わったかもしれません。

引っかかったのは、1回の往復で何行動いたかを数えたときです。16件のうち、変更行数が少なかった4件は、4行、6行、8行、9行でした。挿入と削除を足した数です。

最初は、数え方を間違えたのかと思いました。設計書には134行を書いています。それに対して、往復1回で動いたコード（プログラムの記述）は4行です。

そこで、往復の回数と、1回あたりに動いた行数を並べ直しました。直しが小さくなっても、1件あたりの往復回数は減らず、1回の中身だけが小さくなっていきます。 大きい直しは最初の数件で終わり、あとは余白と色の値の調整だけが残ります。

ここで、渡し方ではなく、仕事の分け方が間違っていたのではないか、と思いはじめました。

④ 原因を1つに特定する

仕事の分け方がうまくいかなかった理由として思い当たることは、いくつもあります。設計書にどこまで細かく書くか、時差、言葉の壁、実物の端末を相手が持っていないこと。

ただ、原因を絞ると1つでした。

設計書に書けることを基準にして、仕事を分けたこと。

書けることは、全部書きました。画面の遷移（操作に応じて別の画面へ移る流れ）も、押したときに何が起きるかも、代車をいつ押さえるかも書けます。書けたものは、1回で終わっています。

一方で、文章に書けなかった仕様は、書面にできないままオフショア会社へ渡りました。 余白がいくつなら詰まって見えないか。丸印が白と灰色のどちらなら押せるように見えるか。カウンターで電話を持ったまま片手で操作したときに、指がどこに届くか。文章にした瞬間に、実物の前で確かめていたものとは別のものになるので、書けません。

つまり、文章に書けない仕様だけが、往復を生みます。そして僕は、その仕様を、海外の開発会社という、いちばん往復が高くつく場所に置きました。

⑤ 直したのは1箇所だけ

やったことは、余白を画面ごとに指定するのをやめただけです。

余白の値を、すべての画面が共通で見る1行にまとめて置きました。中身は4つの数字です。「上端24、かたまりとかたまりのあいだ24、見出しと中身のあいだ12、かたまりの中の要素どうし12」。この4つ以外の余白は、使わないと決めました。

決めたのは値ではなく、値を決める場所です。予約一覧も、代車の一覧も、整備士側の一覧画面も、余白は自分で持ちません。全部この1行を見に行きます。そして、この1行だけは、僕たちが手元で書き換えることにしました。

余白を使っている場所は18箇所ありますが、値を持っているのは、この1行だけです。カウンターで「詰まって見える」と言われたら、直すのも1行。往復1回で、3拠点の全画面が同時に動きます。

このときはまだ、名前のある考え方だとは知りませんでした。

⑥ あとで知った ── 分け方に、すでに名前がありました

しばらくして、『Team Topologies』というチームの組み方を扱った本を読み、手が止まりました。

そこでは、チームとチームのつなぎ方が、2つに分けて説明されています。ひとつは「working together for a defined period of time to discover new things」。期間を区切って一緒に手を動かし、まだ分かっていないことを見つけにいく形です。もうひとつは「one team provides and one team consumes something “as a Service”」。一方のチームが提供し、もう一方のチームが受け取るだけの形で、あいだの行き来はほとんど要りません。

つまり、探り合いが要るかどうかで、つなぎ方を変えるという話でした。余白の値は探り合いが必要な対象で、画面の遷移は必要のない対象です。僕が1行にまとめたのは、探り合いが必要な部分だけでした。まとめた結果、その部分だけが手元に戻り、探り合いが不要な部分は渡したままになっています。

拠点をまたぐ作業にかかる時間も、測られていました。Herbsleb と Mockus が、ソフトウェア工学の学術誌 IEEE Transactions on Software Engineering の29巻9号（2003年）に出した調査に、こうあります。「distributed work items appear to take about two and one-half times as long to complete as similar items where all the work is co-located」。拠点をまたいだ作業は、同じ場所で終わる作業の2.5倍の時間がかかる、と読めます。

しかも、遅くなる理由まで書いてありました。「distributed work items involve more people than comparable same-site work items」。拠点をまたぐと、同じ作業に関わる人数が増える、という説明です。同じ調査のアンケートには、自分の仕事について誰に連絡すればいいのかを探すのに時間を取られている、という設問も並んでいます。

余白を24にするために、誰に言えばいいのかを探す。その時間が、2.5倍の中身でした。

新しい理屈は、ひとつも要りませんでした。

⑦ 変えてみて、何が良くなって、何を失ったか

分け方を変えてから、手元で変わったことがあります。

余白と色に関する直しは、1回の往復で終わるようになりました。値が1箇所にあるので、カウンターで見て決め、その場で書き換えれば、3拠点の全画面が同時に変わります。海外の開発会社の手は、そのあいだ止まりません。

ただ、代償があります。3件書いておきます。

1件目。画面ごとの微調整ができなくなりました。 整備士側の一覧画面は、その日に入る車を横方向へ並べるので、本当は上端を24より詰めたいところです。それでも24にしています。4つの数字以外を使わないと決めたので、例外を作ると元に戻ります。

2件目。1行にまとめる作業そのものが、直しより大きくなりました。 余白を直すつもりが、余白を自前で持っていた場所を全部探して剥がす作業になっています。先に余白の値を1行にまとめていれば、払わずに済んだ手数でした。

3件目。手元の仕事が減りませんでした。 探り合いが要る部分を引き戻したので、その部分はずっとこちらに残ります。オフショア開発に出したのに、手が空くわけではない。空くのは、書けることを書き切ったぶんだけです。

⑧ 現場で分けるなら、この3つの問い

オフショア開発に何を渡して何を残すかを決めるとき、使っているのはこれだけです。

問い	はい	いいえ
文章だけで、合っているか判定できるか	渡してよい	手元に残す。 見て決まるものは往復になる
直しの中身が、数行で終わりそうか	渡す前に、値を1箇所へ集めておく	そのまま渡してよい。1往復で動く範囲が、もともと大きい
決める人が、実物の前に立っているか	手元に残す	渡してよい

いちばん効くのは、2つ目の「直しの中身が、数行で終わりそうか」です。直しが数行で終わるものは、渡す前に1箇所へ集めておく。 集めておけば、往復の回数はそのままでも、1回で動く範囲が全部になります。集めていないと、4行の直しに1往復を払い続けます。

逆に、文章だけで合否が決まるものは、迷わず渡してよいと思います。代車を押さえる順番も、車検の期限が近い車を上に出す規則も、書けば決まります。書けるものは、距離があっても値段が上がりません。

この見方は、扱っているものには依存しません。整備予約でも、経費精算でも、在庫の一覧でも、同じ形で使えます。

⑨ この分け方が効き続ける理由

翻訳の精度が上がっても、時差を埋める道具が増えても、この分け方は変わらないと考えています。

道具で短くなるのは、1回の往復にかかる時間だけだからです。往復の回数そのものは、変わりません。回数を決めているのは通信の速さではなく、「見ないと決まらないものが、いくつ残っているか」です。

そして、見ないと決まらないものは、文章がうまくなっても減りません。減らせるのは、それを海外の開発会社に置くかどうかの一点です。だから、賢い道具が増えるほど、先に効いてくるのは仕事の分け方になります。

このあたりの分け方を実際の開発に落とす話は、AIプロダクト開発のページに整理しています。オフショア開発に何を渡すか決めかねている工程があれば、こちらからご相談ください。

実家のテーブルは、いまも3回目の間隔のまま立っています。あの間隔が正解だったのかは、正直よく分かりません。

以上です。

オフショア開発のよくある質問

オフショア開発の費用は、国内発注と比べてどのくらい違いますか？

単価では国内の半分程度になる国もありますが、総額は単価だけでは決まりません。ブリッジSEの人件費、仕様を書き切る工数、確認の往復にかかる時間を含めて比べる必要があります。

オフショア開発は、どの国に頼むのがよいですか？

対日案件の実績と日本語対応の厚みで選ぶならベトナム、高度な技術領域で英語が使えるならインド、というのが目安です。かつては単価の安さが決め手でしたが、いまは日本語対応の厚み・技術者の定着率・時差の小ささ・対日案件の実績が比重を増しています。単価表の順に選ぶと、後から差が出ます。

小規模でもオフショア開発は使えますか？

体制の立ち上げ、仕様の伝達、品質基準のすり合わせに固定費がかかるため、単発・小規模では回収できないことが多いです。継続して発注する見込みがあるかどうかで判断してください。

オフショア開発とニアショア開発は何が違いますか？

オフショアは海外、ニアショアは国内の地方に委託します。オフショアは単価が下がる一方で、時差と距離のぶん往復が増えます。ニアショアは単価の下げ幅が小さい代わりに往復が速い。2つを分ける軸は距離ではなく、往復の回数です。

ブリッジSEは必ず必要ですか？

現地に日本語で読み書きできる担当がいれば、専任を置かない形もあります。ただし「往復の手前で確定させる人」がどこかに要る点は変わりません。ブリッジSEの実務上の価値は、言語の橋渡しよりも往復の回数を減らすことにあります。

オフショア開発では、何を任せるとよいですか？

文章だけで合っているかを判定できる仕事は、オフショア側へ渡せます。画面の遷移や、予約確定時に代車を押さえるといった規則は、仕様として書けば決められます。一方、実物を見ないと決まらない余白や色、操作感は手元に残します。探り合いが必要かどうかを基準に分けることが重要です。

オフショア開発で仕様書を書き切っても、なぜ手戻りが起きるのですか？

仕様書に書けることと、実物を見て初めて決まることがあるからです。記事の事例では、決めたことを134行の設計書にまとめ、分けた6件の作業は仕様どおりに1日で返ってきました。それでも実物の端末で開くと、余白や色、画面の詰まり方に関する修正が発生しました。書けなかった判断が距離の向こうにあると、確認のたびに往復が増えます。

オフショア開発のコミュニケーションコストを減らすにはどうすればよいですか？

数行で終わりそうな修正の値を、渡す前に一箇所へ集めます。記事では余白の値を4つの数字として1行にまとめ、その1行だけを手元で書き換える形にしました。余白を使う18箇所が同じ値を見るため、一度の変更で3拠点の全画面を同時に変えられます。小さな変更ごとに海外と往復する必要がなくなります。

オフショア開発では、単価と往復回数のどちらが重要ですか？

記事の主張では、効いてくるのは時間あたりの単価より往復の回数です。単価は契約で決まりますが、往復回数は仕事の分け方で決まります。実物を見て決める修正は、内容が数行でも確認のたびに一往復が必要です。そのため、見ないと決まらない仕事をどちら側に置くかが重要になります。

実物を見て決める作業を手元に残すデメリットはありますか？

画面ごとの微調整がしにくくなり、値を一箇所にまとめ直す作業も発生します。記事の事例では4つ以外の余白を使わないと決めたため、整備士側の画面だけを例外的に詰めることはできませんでした。また、探り合いが必要な部分を引き戻すので、その仕事は手元に残り続けます。オフショアへ発注しても、書けない部分まで手が空くわけではありません。

翻訳や時差対策の道具が進歩すれば、オフショア開発の往復は減りますか？

道具で短くできるのは、一往復にかかる時間です。往復回数は、見ないと決まらないものがいくつ距離の向こうに残っているかで決まります。文章がうまくなっても、余白や操作感のように実物を見て決める判断そのものはなくなりません。したがって、道具より先に仕事の分け方を設計する必要があります。