オフショア開発の要件定義｜認識ズレを防ぐ書き方

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

要点： この記事は、オフショア開発の要件定義を「会議を増やす」ではなく「文書を直す」側から整理します。曖昧な言葉、書き忘れやすい前提、受入条件の書き方、レビューの進め方を順に並べます。

「仕様書は渡しました。それでも上がってきた画面が思っていたものと違うんです」。オフショア開発のご相談で、最も多く聞くお話です。

2000年創業のWeb制作・システム開発会社ZenWeb Japanでは、ベトナムオフショア開発のご相談で、まず要件定義書そのものを読ませていただきます。進め方を変えるより、文書を直すほうが早いためです。

基本の進め方は要件定義とは？システム開発で失敗しない進め方にまとめました。ここではその先、海外のチームが読んでも一通りにしか読めない書き方に絞ります。

要件定義の進め方そのものは、次の動画がわかりやすい下地になります。

02認識ズレは伝え方ではなく書き方で起きます

要点： ズレが生まれる場所は、会議の回数ではなく文書の中です。日本語の要件定義書は、読み手が業務の前提を補いながら読む前提で書かれています。その前提を共有していない相手が読むと、書いてあるとおりに作られます。

国内の開発会社に依頼すると、書かれていない部分は「たぶんこうだろう」で埋まります。同じ商習慣、同じ帳票、同じ締め日を知っているためです。この補完が効くうちは、要件定義書の粗さは表に出ません。

ベトナムのチームには、その前提がありません。書かれていないことは作らず、二通りに読める文は片方に決めて作ります。実際に起きるズレは、次の3つです。

• 書いていないから作られなかった。 締め日をまたぐ処理や退職者データの扱いなど、当たり前すぎて落とした部分です。
• 二通りに読める文があった。 「承認後に担当者へ通知する」の手段がメールか画面内かで、実装が変わります。
• 優先順位が伝わらなかった。 全部が同じ重みで書かれていると、時間が足りないときに落とす機能を相手が選びます。

対策は打ち合わせを増やすことではなく、文書から解釈の余地を減らすことです。ブリッジSEの仕事も、訳すことより解釈の余地を先に見つけることにあります。

03要件定義書に残りやすい曖昧な言葉

要点： 「適宜」「必要に応じて」「等」「原則として」の4語は、要件定義書に最も残りやすい表現です。どれも判断を読み手に預ける言葉で、翻訳しても曖昧さが残ります。書く段階で、条件と数値に置き換えてください。

次の表は、点検でよく見つかる表現と書き換え方です。読むぶんには自然でも、実装する人には指示になっていない言葉です。

とくに危ないのは「従来どおり」です。国内の開発会社なら現行システムを見に行けますが、オフショア開発にその手段はありません。書かれていない「従来」は存在しないのと同じです。

04曖昧な表現別｜実装後に書き直しになった割合

要点： 要件定義書に残った曖昧な表現のうち、書き直しにつながりやすいのは「従来どおり」と「適宜・必要に応じて」です。出現の多さと書き直しの多さは一致しません。数の少ない表現ほど、当たったときの影響が大きくなります。

注目していただきたいのは、いちばん下の行です。「従来どおり」は出現こそ22%と少ないのに、書き直しになった割合は57%と突出しています。他の表現は局所の修正で済みますが、この言葉はオフショア開発の前提そのものにかかわるためです。

05書き落としやすい前提を洗い出す4つの視点

要点： 書き落とされる前提は、業務の当たり前・例外処理・権限と承認・締めと帳票の4つに集まります。質問の形で棚卸しすると、机上でも抜けの半分は見つかります。相手に聞かれてから答える形にしないことが大切です。

書かれないのは、社内で説明する必要がないほど当たり前になっていることです。次の4つの視点で、自分に質問してみてください。

• 業務の当たり前。 「使うのは誰か」「1日に何回か」「場所は事務所か現場か」。利用者像が抜けると、画面が的外れになります。
• 例外とイレギュラー。 「入力を間違えたらどこまで戻せるか」「途中で担当者が変わったら」。慣れた人ほど無意識に処理するので、落とされます。
• 権限と承認。 「誰が見てよく、誰が見てはいけないか」「承認は何段階か」「代理承認はあるか」。あとから足すと構造ごと直します。
• 締めと帳票。 「月末をまたぐ処理はどう扱うか」「帳票は誰が誰に出すか」。商習慣が濃く出る部分で、海外のチームには推測できません。

この棚卸しは、依頼先を選ぶ前に済ませると効果が大きくなります。書き出した内容は、そのまま提案依頼書に流用できるためです。書き方はシステム開発会社への依頼で失敗しないRFPの書き方にまとめました。

最初から完璧に書く必要はありません。ただし書けなかった項目は「未定」と明記してください。空欄は「該当なし」と読まれますが、「未定」なら質問が返ってきます。

06機能要件は画面単位で書くと崩れません

要点： 機能要件は、機能名の一覧ではなく画面単位で書くと崩れにくくなります。1画面につき、目的・表示項目・できる操作・遷移先・エラー時の動きの5点を埋めてください。この5点がそろえば、質問なしで実装に入れます。

「受注管理機能」とだけ書かれていると、読む人によって想像する画面が変わります。画面という単位に落とせば、その余地は一気に減ります。

1. この画面の目的。 誰が何のために開くのかを1文で。書けない画面は、そもそも要らない可能性があります。
2. 表示する項目。 項目名・型・桁数・必須かどうかを表にします。別紙の項目定義表にすると管理が楽です。
3. できる操作。 登録・更新・削除・検索・出力のうち、どれを許すか。書いていない操作は作られません。
4. 操作後の遷移先。 保存後に一覧へ戻るのか、同じ画面にとどまるのか。あとから直すと影響が広がります。
5. エラー時の動き。 必須項目が空のとき、重複したとき、通信が切れたとき。ここが抜けると、テストの段階でまとめて返ってきます。

並びと構成をあわせて示すなら、簡単なワイヤーフレームを添えるのが早道です。作り方はワイヤーフレームとは？作り方と制作の流れで紹介しています。手描きの一枚でも、文章より正確に伝わります。

07記載の粒度別｜仕様確認の往復回数

要点： 要件定義書の粒度が細かいほど、開発中の仕様確認は減ります。画面単位に項目定義表を添えた案件では1機能あたり平均1.2往復、文章での説明だけなら6.8往復でした。往復1回につき、時差で丸1日が失われます。

棒の長さの差が、そのまま日数の差になります。1機能で5往復の差なら、機能が30あるプロジェクトで150日分の待ち時間が生まれます。要件定義書を1週間ぶん厚くするほうが安く付きます。

往復は体制でも減らせます。ラボ型開発のように同じメンバーが続けて入る形なら、2回目以降は前提の説明が要りません。

08非機能要件はIPAの分類に沿って埋めます

要点： 非機能要件は自力で項目を考えず、IPAが公開している非機能要求グレードの分類を借りると抜けが減ります。可用性・性能・運用・移行性・セキュリティ・システム環境の6カテゴリを順に埋める形が実務的です。

非機能要件は「何ができるか」ではなく「どれくらいの品質で動くか」を決める部分です。空白のまま進むと、動いてはいるが遅い、誰でも見られる、という状態になります。

分類は自分で考える必要がありません。IPA（情報処理推進機構）が非機能要求グレードとして無償で公開しています。項目表をそのまま持ってきて自社の値を入れるだけでも機能します。オフショア開発でとくに効果的なのは次の3つです。

• 性能の測定条件。 「3秒以内」では足りません。何件のデータで、何人が同時に使う状態かまで書きます。テスト環境と本番環境の差もここで決まります。
• セキュリティと接続元。 海外拠点から本番環境につなぐのか、開発環境だけなのか。契約とも連動するので、早めに決めてください。
• 運用とメンテナンスの体制。 障害が出たとき、日本時間の何時までに一次回答が返るのか。時差があるぶん、国内案件より具体的に書きます。

2つ目は、開発中のデータの扱いまで含めてオフショア開発のセキュリティ対策と情報管理で整理しました。要件定義と並行して決めれば、あとから環境を作り直さずに済みます。

09受入条件はテストできる文に直します

要点： 受入条件は「どうなっていれば合格か」を、第三者が実際に試せる文で書きます。操作の手順・入力する値・期待する結果の3点がそろえば、検収の場で議論になりません。品質を形容詞で書くと、もめます。

要件定義書の最後に置かれ、いちばん軽く扱われるのが受入条件です。ところがオフショア開発では、ここが検収を決めます。

右側の書き方には共通点があります。誰が読んでも同じ手順で試せて、合否が割れないことです。手間はかかりますが、そのまま相手のテスト仕様書になるので全体では時間が減ります。

受入条件と検収は契約の条項ともつながります。オフショア開発の契約とNDA｜知的財産の扱いもご覧ください。検収の期間と基準を契約側にも書けば、判断に迷いません。

10受入条件の書き方別｜検収の一発合格率

要点： 受入条件に操作手順まで書いた案件では、検収の一発合格率が84%でした。記載がなければ22%まで下がり、検収に21日かかっています。差し戻しの理由は不具合ではなく、完了の判断がつかないことでした。

いちばん下の行が示すのは、品質の低さではありません。合格の線がなければ、良いものが上がってきても判断できないということです。差し戻しの多くは、こちら側の準備不足です。品質と管理体制の関係はオフショア開発の品質は低い？管理体制で決まるにまとめました。

11図と表を増やすと翻訳で崩れません

要点： 図と表は翻訳の影響をほとんど受けません。文章で説明していた条件分岐や項目定義を図表に移すだけで、読み違いは減ります。とくに画面遷移図・業務フロー図・項目定義表・状態遷移表の4つが効きます。

長い日本語の文は、訳した時点で語順も係り受けも変わります。表のマス目や矢印は、言語が変わっても意味が変わりません。文章を減らして図表を増やすことが、翻訳への一番の備えです。

• 画面遷移図。 どの画面からどこへ移るかを矢印で示します。戻る操作を書き忘れないでください。
• 業務フロー図。 誰が何をするかを縦のレーンで分けます。承認と差し戻しの流れが、これだけで伝わります。
• 項目定義表。 項目名・型・桁数・必須・初期値・入力チェックの6列で作ります。文章にすると、どこかが抜けます。
• 状態遷移表。 受注が「仮」「確定」「出荷済」と変わる業務では、どの状態からどの状態へ移れるかを表にします。

もう一つ効くのが画面の下書きを1枚添えることです。清書は要りません。項目の並びと見出しの位置がわかるだけで質問が減ります。ワイヤーフレームの作り方もご覧ください。

12レビューは読み合わせではなく説明させます

要点： 要件定義書のレビューは、こちらが読み上げる形では意味がありません。相手に説明してもらい、ずれた部分を見つけます。「わかりましたか」と聞いて「はい」と返る確認では、何も確認できていません。

読み合わせは、こちらの理解を確かめる場にしかなりません。相手が読み違えていても、うなずくだけで終わります。順番を逆にします。

1. 相手に説明してもらう。 画面ごとに「何ができると理解しましたか」と聞きます。ずれは、その場の言葉に表れます。
2. 例外のケースを投げる。 「入力の途中で通信が切れたら、どうなりますか」。想定外の質問への答え方に、書き漏らした前提が出ます。
3. 決まったことを1枚に残す。 決めた内容をその日のうちに追記します。議事録に置いたままだと、差が開きます。

3番目が最も抜けやすい部分です。決めた内容が反映されないまま進むと、どちらが正かわからなくなります。正は常に要件定義書と決めてください。日々のやり取りはオフショア開発のコミュニケーション対策5つに、着手から納品までの流れはオフショア開発の進め方にまとめました。

13要件定義にかけた期間別｜後工程の手直し

要点： 要件定義に開発全体の10〜15%の期間をかけた案件で、後工程の手直しがいちばん小さくなりました。15%を超えると改善は頭打ちです。かけるほど良いわけではなく、効く範囲は決まっています。

10〜15%と15%以上の行を比べてください。手直しの差は1ポイント、遅れの差は1日です。15%を超えたぶんの時間は、ほとんど成果に変わっていません。長引くときは精度ではなく、決められずに止まっている場合が多いためです。

発生工程が上から下へ動く点も見どころです。要件定義が薄いと受入テストまで問題が残り、そこで直すと最も高くつきます。費用の考え方はシステム開発の見積もりの見方にまとめました。

14要件定義書に入れる項目の一覧

要点： 要件定義書には、目的・業務の流れ・機能要件・非機能要件・データ・外部連携・移行・体制・受入条件・用語集の10項目を入れます。国内案件との違いは、用語集と前提条件を独立させる点にあります。

項目そのものは国内案件の要件定義と変わりません。ただし2つだけ、必ず足していただきたいものがあります。

最後の用語集が、国内案件との最大の違いです。「与信」「掛け率」「先入先出」は、辞書を引いても業務での使われ方までは出てきません。10語ほど定義を添えるだけで、質問がはっきり減ります。

15まとめ｜書く順番

要点： 目的を決め、業務の流れを描き、画面に落とし、非機能要件を埋め、受入条件を書き、曖昧語を消してからレビューする。この順で進めれば、前の工程に戻る作業がほとんどなくなります。

オフショア開発の要件定義を書く順番

ここまでの内容を、手を動かす順番に並べました。

1. 目的と背景を1ページで書く。 迷ったとき、ここに戻れば決まります。
2. 業務の流れを図にする。 現在と導入後を分けて描きます。文章より先に図から入ります。
3. 画面に落とす。 1画面につき、目的・項目・操作・遷移先・エラー時の5点を埋めます。
4. 非機能要件を埋める。 IPAの非機能要求グレードを借りて、測れる形にします。
5. 受入条件を書く。 操作手順・入力値・期待する結果の3点で合格の線を引きます。
6. 曖昧語を消す。 「適宜」「等」「従来どおり」を検索し、条件と数値に置き換えます。
7. 相手に説明させてレビューする。 ずれを見つけ、当日中に追記します。

飛ばされやすいのは5番目と6番目です。成果物が増えないため後回しにされますが、手直しを減らす効果はこの2つが最も大きい部分です。

体制ごとの向き不向きはベトナムオフショア開発のサービスページに、はじめての委託ならオフショア開発の失敗事例と対策もあわせてご覧ください。

16よくある質問

要点： オフショア開発の要件定義について、ご相談の場でよくいただく質問をまとめました。書く担当者、英訳の要否、仕様変更の扱いなど、着手前に決めたい点を並べました。

1. 要件定義書は自社で書く必要がありますか

業務の中身を書けるのは発注する側だけです。目的・業務の流れ・受入条件は自社で書いてください。画面設計や非機能要件は開発会社と一緒に埋める形で問題ありません。ZenWeb Japanでは日本人SEが同席し、聞き取りながら文書に起こす形も承っています。

2. 要件定義書は英語やベトナム語に訳す必要がありますか

ブリッジSEが入る体制なら、日本語のままで問題ありません。訳す工程で意味が変わるほうがリスクです。ただし用語集と項目定義表に対訳を付けると、現地の実装者が直接参照できて確認が減ります。

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

請負契約なら追加の見積りと工期の調整が必要です。ラボ型なら次のスプリントで吸収できます。変更が多いと見込まれるなら、契約形態の段階で選び分けてください。

4. 要件定義だけを先に依頼することはできますか

可能です。要件定義だけを準委任契約で進め、その成果物で開発を見積もる形は珍しくありません。ZenWeb Japanの料金は案件ごとの見積り制で、要件定義のみのご依頼も承っています。

5. 要件定義書はどれくらいの分量になりますか

画面が20前後の業務システムで、本文と別紙をあわせて50〜100ページが目安です。ただし枚数より、画面ごとの5点と受入条件が埋まっているかを見てください。薄くても埋まっていれば、開発は止まりません。