オフショア開発の仕様書の書き方【2026年版】種類別の粒度・伝わる7原則・悪い例→良い例

「オフショアに出すなら仕様書を細かく書けと言われるが、どこまで書けばよいのか」——海外チームへの発注を控えた方から、こうした相談をよく受けます。日本語で書いた仕様書が伝わるのか、要件定義書と設計書のどちらまで自社で書くのか、そもそも仕様書がない既存システムを頼めるのか。国内のSIerに口頭と議事録で頼んできた方ほど、最初の仕様書で立ち止まります。

結論から言うと、オフショアに渡す仕様書は国内向けより「一段細かく、一段機械的に」書く必要があります。ただし、発注側がすべての仕様書を書ききる必要はありません。発注側が担うのは「何を作りたいか」と優先順位の言語化で、基本設計以降は日本人PM/BrSEを含む開発会社側が巻き取れます。種類ごとに粒度と担当を決め、7つの原則で曖昧さを消し、チケット化とレビューで運用する。これが仕様のずれを防ぐ条件です。

海外チームには日本の暗黙の了解が通用せず、時差2時間の非同期では確認の1往復が翌日になり、翻訳を挟むと日本語の曖昧さがそのまま「仕様バグ」になります。だからこそ原則は機械的に適用できるものでなければならず、同時に「発注側に残る仕事」を正直に線引きしておく必要があります。

本記事では、オフショアに渡す仕様書6種類の役割と必要な粒度、海外チームに伝わる仕様書の7原則と悪い例→良い例の対比表、チケット化・レビュー・変更管理・仕様書がない案件の引き継ぎといった運用と当社の体制、よくある質問の順に解説します。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。仕様がずれた相談に共通するのは、たった2つです。この記事を読み終えるころには、自社が書くべき仕様書の範囲と、明日から直せる書き方が分かるはずです。

オフショアに渡す仕様書の種類と役割——要件定義書からテスト仕様まで、「オフショアで必要な粒度」と担当

「仕様書」と一口に言っても、要件定義書から テスト仕様書まで役割の違う書類が6種類あります。オフショア開発で最初に決めるべきなのは「どれを誰が、どの粒度で書くか」です。上位の解説記事(Sun Asterisk、オルグローラボ)でも、要求仕様書は依頼者側、機能仕様書や外部仕様書は開発会社側が主に作成するとされています。まずは6種類の役割と担当、オフショアで必要な粒度を一覧で押さえてください。

仕様書6種類の一覧表(役割・担当・オフショアで必要な粒度・なくても始められるか)

表の右2列を見ると、発注側が「書かないと始まらない」のは要件定義書だけです。残りの5種類は、要件定義書・ワイヤー・受入基準の3つが揃っていれば、開発会社側が起こせます。逆に言えば、この3つが曖昧なまま「あとは任せる」と渡すのが失敗のもとです。

仕様書と設計書の違い——仕様書は「完成形」、設計書は「作り方」

仕様書と設計書はよく混同されますが、役割は明確に違います。仕様書は「どんな機能を、どう動くものとして作るか」という完成形を定めた書類で、設計書は「その完成形をどの技術・構成・処理で実現するか」という作り方を定めた書類です。家づくりに例えるなら、仕様書は間取りと設備の希望書、設計書は図面と施工手順書にあたります。

オフショアで発注側が押さえるべきなのは、この違いを踏まえた線引きです。完成形(要件定義書・画面のワイヤー・受入基準)は発注側が決め、作り方(基本設計・詳細設計・API仕様)は開発会社側が決めて発注側がレビューする。「設計書 オフショア」で検索している方の多くは「設計書まで自社で書くのか」を心配していますが、書く必要はありません。読んでレビューできれば十分です。

なぜ国内より一段細かく書くのか——暗黙の了解・時差2時間の非同期・翻訳で生まれる「仕様バグ」

同じ仕様書でも、海外チームに渡すときは国内向けより一段細かく書く必要があります。理由は3つです。1つ目は、日本の暗黙の了解が通用しないこと。「ユーザー名は適切にバリデーションする」と書けば、日本人エンジニアは全角・半角の制限や文字数、禁止文字を暗黙に考慮しますが、海外チームには「適切」の中身が分かりません。

2つ目は、時差です。ベトナムと日本の時差は2時間と小さいものの、非同期のやり取りでは質問の1往復が翌日にずれ込みます。仕様書の抜けを口頭で埋める前提だと、抜けの数だけ日数が失われます。3つ目は翻訳です。日本語の仕様書をベトナム語や英語に翻訳する工程で、日本語特有の遠回しな表現や主語の省略が誤訳になり、「仕様バグ」と呼ばれる不具合になります。当社でも、日本語の原文が曖昧なまま翻訳された箇所で手戻りが起きた例を繰り返し見ています。白書2025年版でベトナムがオフショア先のシェア43%と首位になった今、この3つはベトナム向けの仕様書で最も多い失敗要因だと私は見ています。

要件定義の責任は発注側にある——IPAのガイドが言う「ユーザの役目」

もう1つ、線引きの根拠として押さえておきたいのが公的なガイドです。IPA(情報処理推進機構)の「ユーザのための要件定義ガイド 第2版」(2019年12月発行)は、システムの要件を定義する責任は、そのシステムを使ってビジネスに貢献する役目を負うユーザ(発注側)にあると述べ、システム開発の遅延の過半は要件定義の失敗にあると言われる、と指摘しています。

つまり、要件定義書だけは外注できません。開発会社のPMが整理やドラフト作成を支援することはできますが、「何を作りたいか」「何を優先するか」を決めるのは発注側です。次章では、その要件定義書を含むすべての仕様書で、海外チームに伝わる書き方の7原則を悪い例と良い例で整理します。

海外チームに伝わる仕様書の7原則——悪い例→良い例の対比表

海外チームに伝わる仕様書の書き方は、突き詰めると「解釈の余地を消す」ことに尽きます。私が約100社の相談で見てきた「仕様がずれた」案件に共通するのは、「『適切に』『必要に応じて』で書かれた仕様書をそのまま渡した」「例外系と受入基準を書かず、正常系だけで完成と判断された」の2つでした。ここでは、解釈の余地を消す原則を7つに整理し、悪い例と良い例を対比表にしました。自社の仕様書を左の列と照らし合わせてみてください。

7原則と悪い例/良い例の対比表

7つの原則に共通するのは、海外チームの日本語力や察する力に依存しない、という点です。原則1〜3は「書き方」、4〜5は「抜けを防ぐ型」、6〜7は「完成と言葉の定義」にあたります。順に補足します。

原則1〜3: 曖昧語を消す、主語と数値を入れる、文章より図と表

原則1の曖昧語は、機械的に検索して消せます。「適切に」「必要に応じて」「〜など」「基本的に」「柔軟に」「分かりやすく」の6語を仕様書から検索し、出てきた箇所を条件と数値に置き換えてください。Shineosの自己レビューチェックリストでも、曖昧な表現の有無が「明確性」の確認項目に置かれています。

原則2の主語と数値は、5W1Hで書くと自然に入ります。「誰が(管理者が)」「いつ(一覧を開いたとき)」「何を(在庫数を)」「どう判定し(閾値以下なら)」「どう見せるか(行を黄色に)」。たとえば在庫警告で「閾値以下なら警告を出す」とだけ書き、閾値が商品カテゴリごとに違うことを仕様書に落とさないと、実装が終わってから食い違いが発覚し、リリース直前の手戻りになります。数値のない条件は、海外チームが「常識」で埋めた瞬間にずれます。

原則3の図と表は、翻訳に強いという利点もあります。業務フロー図・画面遷移図・ER図・状態の一覧表は、言語をまたいでも解釈がぶれません。文章で3段落書くより、図1枚と表1つのほうが正確に伝わり、翻訳の工数も減ります。

原則4〜5: 画面遷移とワイヤーで「見た目」を固定する、例外系を正常系と同じ量だけ書く

原則4は、画面に関わる仕様を文章で書かないことです。「検索画面と詳細画面を作る」と書かれても、ボタンの位置も項目の並びも決まりません。画面遷移図でつながりを、Figmaなどのワイヤーで配置を、要素一覧で必須・文字数・エラー文言を固定します。ワイヤーは発注側が手描きでも構いません。配置の意図が伝われば、清書は開発会社側でできます。

原則5は、私が最も強調したい原則です。仕様書の多くは正常系(うまくいく流れ)しか書かれていません。しかし不具合は例外系で起きます。該当0件、通信エラー、境界値(0件・1件・1,000件超)、二重送信、権限のないユーザーのアクセス。これらの挙動を正常系と同じ分量で書いておけば、テスト仕様書もそのまま起こせます。「例外系は開発会社が考えてくれる」という期待は要注意です。考えてくれた結果が、あなたの想定と同じとは限りません。

原則6〜7: 受入基準で「完成」を定義する、用語集で表記ゆれと日本固有の概念を潰す

原則6の受入基準は、「この条件をすべて満たせば完成」というリストです。機能ごとに3〜5項目、テストで確認できる粒度で書きます。受入基準があると、開発会社側はテスト仕様書を起こせ、発注側は納品時に同じリストで検収できます。「完成」の定義が双方で一致していないことが、「できたと言われたが想定と違う」の正体です。

原則7の用語集は、地味ですが効果が大きい原則です。「顧客」「取引先」「クライアント」のような表記ゆれを1語に統一し、年末調整や元号、印鑑のような日本固有の概念には3行の説明を付けます。用語集は1枚で済み、翻訳者とエンジニアの両方が参照できます。7原則に沿って仕様書を1日見直す工数は、手戻り1回で確実に回収できる。これが約100社を見てきた私の教訓です。

仕様書を運用する——チケット化・レビュー・変更管理・仕様書がない案件の引き継ぎと、当社の体制

仕様書は書いて渡して終わりではありません。オフショア開発で仕様がずれる原因の半分は「書き方」ですが、残りの半分は「運用」です。仕様は変わるものなので、変更を管理する仕組みがないと、仕様書は最初の1か月で実装と食い違います。ここでは、チケット化・レビュー・変更管理・仕様書がない案件の引き継ぎの4つについて、発注側がやることと開発会社側がやることを分けて表にしました。当社の体制も右列に示します。

運用の表(発注側がやること/開発会社側がやること/当社の体制)

表を見ると分かるとおり、発注側に残るのは「優先順位の判断」「作りたいものとの一致確認」「変更の理由」「直したい点」の4つで、いずれも「何を作りたいか」の言語化です。それ以外は開発会社側の体制で担えます。

チケット化とレビュー: 1機能1チケット、完了条件付き、「この仕様書だけで実装できるか」

チケット化の原則は、1機能1チケットと、各チケットに完了条件を付けることです。仕様書をそのまま渡すと、エンジニアはどこから手を付け、どこで完了かを自分で判断することになります。GitHub IssuesやBacklog、Jiraで「ユーザー登録画面」「登録API」「登録のテスト」のように分解し、前章の原則6で書いた受入基準をそのまま完了条件に貼れば、進捗も検収も同じ単位で管理できます。

レビューは3段階が現実的です。書いた本人の自己レビュー(曖昧語の検索・数値の有無・例外系の有無)、実装者の視点でのピアレビュー、PMによるビジネス要件との整合の承認。基準は「この仕様書だけで、質問せずに実装できるか」の1点です。Shineosも自社の運用として、この3段階をチェックリストで回し、レビュー指摘数や手戻り工数を指標として追っていると公表しています。当社では、日本人PMの設計レビュー、Gitプルリクエストによるコードレビュー、リリース前ダブルチェックの3点を単価に含めており、仕様書のレビューと実装のレビューを同じPMが見ることで、仕様と実装の食い違いを早い段階で拾っています。

仕様書がない案件の引き継ぎ: 現行システムの画面とコードから仕様を起こし、チケットで進める

「仕様書がないシステムをオフショアに頼めるのか」という相談は、実際によく受けます。答えは「頼める。ただし、最初の1か月程度は仕様を起こす期間になる」です。手順は、現行システムの画面とソースコード、運用手順、発注側が把握している「直したい点」を提供してもらい、開発会社側が画面とコードから機能一覧・画面遷移図・データ構造を起こし(リバースエンジニアリング)、課題リストとチケットに整理してから改修に入る、という流れです。

この期間を省いて「とりあえず直して」と始めると、直した箇所が別の機能を壊し、原因の特定に時間を取られます。仕様を起こす期間を先に確保するほうが、結果として早く安く済むのが実情です。発注側に残る仕事は「直したい点」と優先順位の言語化で、仕様書を書く必要はありません。「オフショア開発 進め方」の記事で、発注から運用までの全体の流れを整理していますので、あわせてご覧ください。

当社の体制: 日本人PM/BrSEが日本語の要件を仕様に翻訳する——ただし「何を作りたいか」の言語化は発注側の仕事

当社では、日本人PM/BrSEをフロントに置くパターンAを推奨しています。発注側は要件と優先順位を日本語で伝えればよく、要件定義書を書ききれなくても、PMがヒアリングして要件定義書のドラフト・画面仕様・チケットに翻訳します。2,000名以上のIT人財データベースには日本語N1〜N2相当のエンジニアが含まれており、翻訳で意味が落ちる工程を短くできます。介護記録SaaS「CareViewer」の開発では、発注側が週次の定例で要件と優先順位を判断し、日本語BrSE1名が仕様に翻訳してフルスタックエンジニア2名に渡す体制で、従来の半分以下のコストで継続開発が回っています。お客様からは「想像以上にエンジニアのレベルが高い」という声をいただいています。

ただし、正直にお伝えしなければならないことがあります。「何を作りたいか」「何を優先するか」の言語化だけは、発注側にしかできません。PMが翻訳できるのは、発注側の頭の中にある要件であって、決まっていない要件ではないからです。要件と優先順位を判断する担当を1名置ける案件は向きますが、「全部おまかせで良いものを」という案件は向きません。日本人PMフロント+エンジニア2〜3人月で月額約80万円〜(実務3年目安1,500USD、約22.5万円。1USD=150円換算目安)という構成が、仕様の翻訳を体制で担う最小単位です。あなたの案件では、「何を作りたいか」を日本語で語れる担当がいるでしょうか。それが揃っていれば、仕様書は書ききれなくても始められます。

オフショア開発の仕様書でよくある質問

オフショアに渡す仕様書について、相談の場で繰り返し聞かれる質問を5つにまとめました。発注前の社内整理にもお使いください。

Q1. 仕様書は日本語で書いてよいですか?

日本人PMやBrSEがチームにいる体制なら日本語で構いません。重要なのは言語より曖昧さで、「適切に」「必要に応じて」を条件と数値に置き換えた日本語の仕様書のほうが、曖昧な英語の仕様書より正確に伝わります。エンジニアのみの体制(パターンB)で頼む場合は、英語化と用語集の整備を発注側が担う必要があります。

Q2. 設計書はどちらが書きますか?

基本設計書・詳細設計書・API仕様書は開発会社側が書きます。発注側は要件定義書とワイヤー、受入基準を用意し、基本設計書の画面遷移図とER図をレビューしてください。設計書を自社で書く必要はありません。

Q3. 仕様書がない既存システムの改修も頼めますか?

頼めます。現行システムの画面とソースコード、運用手順、直したい点を提供いただき、開発会社側が機能一覧と画面遷移図を起こしてからチケット化します。最初の1か月程度は仕様を起こす期間として見込んでください。

Q4. 要件定義から外注できますか?

要件定義書のドラフト作成やヒアリングは支援できますが、「何を作りたいか」「何を優先するか」を決める責任は発注側に残ります。IPAの「ユーザのための要件定義ガイド 第2版」も、要件を定義する責任はユーザ側にあるとしています。判断する担当を1名置くことが条件です。

Q5. 仕様変更はどう管理すればよいですか?

変更したい内容と理由を日本語で伝え、開発会社側が変更履歴(バージョン・日付・内容)と影響するチケットを更新し、工数と期日への影響を提示する、という流れが基本です。当社では日本人PMが影響範囲を見積もり、選択肢を日本語で提示します。変更そのものより、変更を記録せずに口頭で済ませることが手戻りの原因。

まとめ: 言語化は発注側、翻訳は開発会社側——種類ごとの粒度と7原則、運用で仕様のずれを防ぐ

オフショアに渡す仕様書は6種類(要件定義書・基本設計書・詳細設計書・画面仕様書・API仕様書・テスト仕様書)ありますが、発注側が書かないと始まらないのは要件定義書だけです。残りは要件定義書・ワイヤー・受入基準の3つが揃っていれば開発会社側が起こせます。海外チームには暗黙の了解が通用せず、時差2時間の非同期と翻訳の工程で日本語の曖昧さが仕様バグになるため、国内向けより一段細かく、一段機械的に書く必要があります。

伝わる仕様書の7原則は、曖昧語の排除、主語と数値、図と表、画面遷移とワイヤー、例外系、受入基準、用語集です。いずれも海外チームの日本語力や察する力に依存しない原則で、「適切に」「必要に応じて」の6語を検索して消す、例外系を正常系と同じ量だけ書く、といった形で明日から適用できます。書いた後は、1機能1チケットと完了条件、3段階レビュー、変更履歴の運用で守ります。仕様書がない既存システムも、現行の画面とコードから仕様を起こす期間を1か月程度確保すれば引き継げます。

当社は日本人PM/BrSEをフロントに置き、発注側が日本語で伝えた要件と優先順位を要件定義書のドラフト・画面仕様・チケットに翻訳し、設計レビュー・Gitプルリクエスト・リリース前ダブルチェックで仕様と実装の食い違いを拾います。ただし「何を作りたいか」の言語化は発注側の仕事で、判断する担当を1名置けることが条件です。発注から運用までの全体像はオフショア開発の進め方、日本人PMの役割はオフショア開発の日本人PMもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、必要な仕様書の範囲と体制、概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。