オフショア開発の進め方｜見積りから納品まで

01はじめに｜この記事でわかること

要点：この記事では、見積り依頼から納品までを9つのステップに分け、それぞれの段階で発注側が何を決めるかをご説明します。そもそもの仕組みからご確認でしたら、先にオフショア開発の基本をお読みください。

「気づいたら話が進んでいて、いま何を決める場面なのかわからない」。オフショア開発を初めて検討される方から、よくいただくお声です。

ネット上には「進め方8ステップ」といった記事がたくさんあります。ただ、そこに並んでいるのは開発側の作業の順番です。発注する側が知りたいのは、自分がいつ何を決めればいいのかのほうではないでしょうか。

そこでこの記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、実際に案件を動かしてきた立場から進め方を整理します。読み終えるころには「来週の打ち合わせで何を決めればいいか」が言えるようになります。

次の動画では、オフショア開発でつまずきやすい点が短くまとまっています。あわせてご覧ください。

02国内発注と決定的に違う3つの点

要点：「察してもらえない」「その場で聞き直せない」「途中で人が替わる」の3点です。どれも進め方そのものを変えるほどの違いになります。委託先の国による差はオフショア開発の国別比較にまとめました。

国内の開発会社なら、仕様書に書き忘れがあっても「たぶんこういう意図だろう」と補ってもらえます。この暗黙の補完が、海外の開発チームでは働きません。悪意ではなく、前提の共有がないからです。

進め方に影響する違いは、次の3つに整理できます。

• 書いていないことは作られません。国内なら口頭で補える部分も、文章にしないと伝わりません。仕様書の粒度を一段細かくする必要があります。
• 聞き直しに半日かかります。時差が2時間でも、質問と回答の往復は1日1回が現実です。まとめて聞ける形に整理しておくと進みが変わります。
• 担当者が入れ替わります。海外の開発現場は人の動きが速く、半年で顔ぶれが変わることもあります。決めた内容が文章で残っていないと、そのたびに戻ります。

つまり、国内発注より前倒しで決める作業が増えます。この記事の順番も、その前提で組んでいます。

03見積り依頼から納品までの標準スケジュール

要点：500万〜3,000万円規模の案件で、見積り依頼から納品まで20週前後が目安です。うち最初の4週は、開発が1行も始まらない準備と比較の期間になります。Webシステム開発でも、この配分は大きく変わりません。

下の表は、当社が受けた案件を時系列に並べ直したものです。開発規模によって伸び縮みしますが、順番と比率はおおむね共通しています。

目を引くのは、遅れやすい時期が開発中ではない点ではないでしょうか。社内準備・要件定義・テストという、発注側が動く場面に集中しています。

04見積りを取る前に決める3つのこと

要点：完成の条件、社内の窓口、機能の優先順位の3つです。この3つが決まっていれば、要件定義が固まっていなくても見積りは取れます。書き方はRFPの書き方が参考になります。

1. 完成の条件を1行で書く。「受注入力の時間が半分になる」のように、達成できたかどうかが判定できる形にします。「便利になる」では判定できません。
2. 社内の窓口を1人に決める。複数人が別々に指示を出すと、開発側は最後に届いた指示で作ります。決裁の代理も含めて1人に寄せてください。
3. 機能に順位をつける。「なくても運用できる機能」を先に洗い出します。予算や納期が厳しくなったとき、この順位表がそのまま判断材料になります。

3つとも、A4で1枚に収まる分量です。完璧を目指す必要はありません。むしろ要件定義まで踏み込むと、社内で止まって時間だけが過ぎます。詳しくは要件定義の進め方をご覧ください。

05工程別の工数と、発注側が動く量

要点：開発側の工数は実装工程に集中しますが、発注側の稼働は要件定義と検収に集中します。両者の山はずれています。この形を知っておくと、社内の人繰りが立てやすくなります。

下の表は、開発側の工数比率と、そのとき発注側にどれだけ手が必要かを並べたものです。棒は開発側の工数比率を表しています。

開発が最も忙しい時期に、発注側はいちばん暇になります。この谷で気を抜くと、テストの山で足りなくなります。

実装の8週間は、発注側の出番がほとんどありません。ここで担当者を別の仕事に完全に振り替えてしまうと、テストの時期に戻ってこられなくなります。谷のあいだにテストの段取りを済ませておくのが安全です。

06見積りの取り方と、比べ方

要点：3社に同じ資料を渡し、同じ形式で出してもらってください。総額だけを並べても比較にはなりません。金額の前提が違えば、安い見積りほど後から増えます。相場観はオフショア開発の費用相場でご確認ください。

見積書が届いたら、金額より先に次の4点を見てください。

• 工程がどこまで含まれているか。要件定義が別料金の会社と、込みの会社があります。ここが違うと総額は簡単に2割ずれます。
• 誰の工数が何人月入っているか。ブリッジSE、開発者、テスターの内訳が見えない見積書は、あとで人が足されがちです。
• テストの範囲。単体テストまでか、結合まで見るかで作業量が変わります。書かれていなければ確認してください。
• 納品物の一覧。ソースコードだけか、設計書や手順書も付くか。運用を自社で引き取るなら、ここが効いてきます。

比べる作業そのものの進め方は、システム開発の見積もりの見方とオフショア開発会社の選び方で詳しく解説しています。

07工程ごとの契約形態の使い分け

要点：契約は1本にまとめず、工程で分けるのが基本です。仕様が動く要件定義は準委任、固まった実装は請負。この分け方は情報処理推進機構（IPA）のモデル契約でも示されている考え方です。

「全部まとめて請負で」と決めてしまうと、要件定義の段階で仕様を確定させる必要が出ます。まだ決まっていないものを決めた前提で契約するため、あとで変更が入るたびに追加費用の話になります。

継続して機能を足していく前提なら、実装以降をラボ型に切り替える形もよく使われます。違いはラボ型開発と請負・準委任の比較にまとめました。

08開発中の進め方｜見るべきは進捗率ではありません

要点：報告書の進捗率ではなく、2週ごとに動く画面を見てください。数字は主観が入りますが、動くものは嘘をつきません。窓口の役割はブリッジSEの役割で解説しています。

「進捗80%」という報告が3週続く。オフショア開発でよく聞く話です。残り20%に手直しが隠れていて、そこから納期が動きはじめます。

防ぐ方法は単純です。開発中の進め方を、次の3つに固定してください。

• 2週ごとに動く画面を見る。完成していなくて構いません。触れる状態のものを見せてもらいます。
• 質問はまとめて1日1回返す。時差があるぶん、こちらの返信の速さがそのまま進み方になります。返す時間を決めておくと滞りません。
• 決めたことは必ず文章に残す。会議の口頭合意は、担当者が替わった時点で消えます。議事録を相手にも確認してもらってください。

やりとりの具体的な工夫はオフショア開発のコミュニケーション対策、品質を保つ仕組みは品質は管理体制で決まるにまとめています。

09遅れは、どの時期に仕込まれるか

要点：遅れが表面化するのはテストの時期ですが、原因の多くは要件定義かそれ以前で生まれています。表面化した時期を叩いても直りません。実例はオフショア開発の失敗事例にまとめました。

8割前後が、要件定義かそれより前で生まれています。国内でも同じ傾向はありますが、オフショア開発では暗黙の補完が働かないぶん、そのまま表に出ます。実装中に人を足しても、原因が前にある以上は戻りません。

10検収と納品｜受け取る前に確認する5項目

要点：合格の基準、実データでの動作、納品物の一覧、権利の移転、メンテナンスの条件の5つです。検収書に押印すると、そのあとで見つかった不具合の扱いが変わります。順番を飛ばさないでください。

1. 合格の基準に沿って確認する。要件定義のときに決めた基準を、そのまま確認表として使います。その場で新しい基準を作ると、話がまとまりません。
2. 実際の業務データで動かす。サンプルデータでは通っても、件数や文字種が変わると止まることがあります。本番に近いデータで試してください。
3. 納品物の一覧をそろえる。ソースコード、設計書、テスト結果、運用手順書。契約時の一覧と突き合わせます。
4. 著作権の移転を確認する。移転の範囲と時期が契約書に書かれているかを見ます。書かれていないと、改修時に相手の許諾が要る場合があります。
5. メンテナンスの窓口と費用を決めておく。納品後に誰へ連絡するのか。ここを決めずに終わると、不具合が出たときに動けません。

なお請負契約では、引き渡された成果物が契約の内容に合っていない場合、注文者はその事実を知ったときから1年以内に通知する必要があります（民法第637条）。検収は形式ではなく、この期間の起点になる手続きです。

11進め方でつまずく3つの場面

要点：社内調整で見積り依頼が止まる、要件定義の判断が持ち帰りになる、テスト要員が確保できない。この3つが代表的です。いずれも予定表に書き込んでおけば避けられます。

• 見積り依頼が社内で止まる。「もう少し固めてから」と言っているうちに数か月経ちます。固めるための情報は、見積りを取る過程でしか手に入りません。
• 要件定義の場で決められない。持ち帰って翌週に回すと、そのぶん全体が1週間ずれます。決裁権のある方に同席いただくのがいちばん早い解決です。
• テストの人手が足りない。実際に業務で使う方に触ってもらう必要があります。繁忙期と重なると詰みますので、着手時に日程を押さえてください。

12発注から納品までの9ステップ

要点：ここまでの内容を、実行できる順番に並べ直しました。上から順に進めれば、初めての発注でも20週前後で納品まで届きます。体制の中身はベトナムオフショア開発でご確認いただけます。

1. 完成の条件を1行で書く。判定できる形にします。ここが全工程の基準になります。
2. 社内の窓口を1人に決める。決裁の代理も含めて寄せます。
3. 機能に順位をつける。なくても運用できる機能を先に洗い出します。
4. 3社に同じ資料で見積りを依頼する。資料が違うと、金額の差が何の差かわかりません。
5. 開発チーム側の担当者と話す。営業担当だけでなく、実際に作る側と30分でも話します。
6. 工程を分けて契約する。要件定義は準委任、実装は請負を基本にします。
7. 要件定義に決裁者が同席する。その場で決められる状態を作ります。
8. 2週ごとに動く画面を確認する。報告書の進捗率ではなく、触れるものを見ます。
9. 合格の基準と実データで検収する。納品物と権利の移転もあわせて確認します。

初めての場合は、1〜2か月で終わる小さな範囲から試すのが安全です。進め方そのものを一度通してから、本番の規模に広げてください。

13まとめ｜進め方は「決める順番」で決まります

要点：オフショア開発の進め方でつまずく原因は、ほとんどが発注側の未決事項です。完成の条件・窓口・優先順位の3つを先に決めてから、オフショア開発の委託先を探してください。

見積りを取る前の準備に1週間かければ、そのあとの19週が静かに進みます。逆に準備を飛ばした案件は、テストの時期にまとめて跳ね返ってきます。

特別な知識は要りません。完成したと言える条件を1行で書けるかどうか。まずはそこから始めてみてください。

14よくある質問

要点：進め方についてよくいただくご質問をまとめました。委託先の選び方が気になる場合は、オフショア開発会社の選び方もあわせてご覧ください。

1. 要件定義が固まっていなくても見積りは取れますか

取れます。完成の条件、窓口、機能の優先順位の3つが決まっていれば、概算の見積りは出せます。むしろ要件定義まで自社で固めようとすると、社内で止まって時間だけが過ぎます。

2. 最短でどのくらいの期間が必要ですか

小規模なもので8〜12週、500万〜3,000万円規模で20週前後が目安です。短くしたい場合は機能を削るのが確実で、工程を飛ばす方法は結局あとで戻ります。

3. 現地に行く必要はありますか

必須ではありません。日本人窓口のある会社であれば、すべてオンラインで完結します。長期のラボ型で関係を深めたい場合に、訪問を検討される方が多い印象です。

4. 途中で仕様を変えたくなったらどうしますか

変更の受け付け方を、契約時に決めておいてください。準委任なら次の週の作業に組み込めますし、請負なら追加見積りになります。契約形態によって扱いが変わります。

5. 納品後のメンテナンスも同じ会社に頼むべきですか

作った会社に頼むほうが速く安く済みます。ただし設計書と手順書を納品物に含めておけば、別の会社へ引き継ぐことも可能です。契約時に納品物の一覧を確認してください。