採用・組織

要件定義は日本と海外で何が違うのか。契約構造から生まれる差

要件定義のやり方が日本と海外で違うと言われます。ただ、それは仕事の丁寧さの差ではなく、誰が何を担う契約になっているかという構造の差です。この記事では、その構造から違いを説明します。

違いは契約構造から生まれる

最初に押さえるべき前提があります。日本ではITの担い手の多くがベンダー側に所属し、欧米ではユーザー企業側に多く所属するという違いです。

この差が、要件定義のあり方を決めています。

ユーザー企業に技術者がいる場合、業務要件と技術要件を同じ組織の中で詰められます。仕様が変わっても、社内の調整で済みます。

ベンダーに委託する場合、要件は契約の対象になります。何を作るかを事前に文書で確定し、そこから外れるものは追加費用の議論になります。

つまり、日本の要件定義が詳細で厳格なのは、それが契約の根拠だからです。丁寧さの問題ではなく、必要に迫られた構造です。

日本型の特徴

日本の要件定義には、いくつかの共通した特徴があります。

• 事前に確定させる／着手前に仕様を固め、文書化する
• 網羅性を重視する／例外処理や異常系まで書き出す
• 合意の記録を残す／議事録と承認印。後の解釈違いを防ぐため
• ベンダーが主導する／ユーザー側に技術者が少ないため、聞き取って整理する役割を担う

この方式には明確な強みがあります。品質の均質性が高く、大規模で長期のシステムを安定して作れます。金融や公共のシステムで実績を重ねてきたのは、この方式です。

海外型の特徴

一方、欧米型として語られる進め方には別の特徴があります。

要件は変わる前提で始まる。最初にすべてを決めきらず、動くものを見ながら詰めていきます。

ユーザー側に決める人がいる。プロダクトの責任者が社内におり、その場で判断します。持ち帰りが少なくなります。

文書より対話。詳細な仕様書ではなく、目的と優先順位を共有し、細部は実装しながら決めます。

ただし、これは「文書を書かない」という意味ではありません。決めたことは記録されます。違うのは、着手前にどこまで確定させるかという範囲です。

よくある誤解

この違いについて、実務でよく見られる誤解を3つ挙げます。

「海外はアジャイル、日本はウォーターフォール」。実際には、海外でも規制産業や大規模インフラではウォーターフォール型が使われます。逆に日本のスタートアップは反復型で進めています。国の違いではなく、案件の性質の違いです。

「日本の要件定義は無駄が多い」。委託構造のもとでは、事前確定は合理的です。無駄に見えるのは、その方式が合わない案件に適用されている場合です。

「海外はドキュメントを作らない」。むしろ設計判断の記録や意思決定の経緯は、きちんと残されることが多くあります。

戸惑いが生じる場面

日本の技術者が海外案件に関わるとき、あるいはその逆で、摩擦が起きやすい場面があります。

「決めてください」が通じない。ユーザー側に決定権者がいる前提で聞くと、日本側では「持ち帰って検討します」となります。逆に海外案件で持ち帰りを繰り返すと、進行が遅いと受け取られます。

仕様変更の扱い。変更を前提とする側と、変更を契約の逸脱と捉える側では、同じ事象への反応が正反対になります。

完成の定義。「動くこと」を完成とするか、「仕様書どおりであること」を完成とするか。ここがずれると、検収で揉めます。

いずれも、事前に合意しておけば防げます。問題は、暗黙の前提として意識されていないことです。

両者の間で働くときに

実務的な指針を挙げます。

• 決定権の所在を最初に確認する／誰が、いつまでに、何を決めるのかを明文化する
• 完成の定義を先に合意する／何をもって終わりとするかを、着手前に書く
• 変更の扱いを決めておく／どこまでが範囲内で、どこからが追加なのか
• 記録は残す／方式にかかわらず、決めた理由を書き残す。人が入れ替わっても伝わる

4つ目は、どちらの方式でも共通して価値があります。「なぜそう決めたか」が残っていない設計は、数年後に誰も触れなくなります。

この差は縮まるのか

最後に、今後の見通しについて書いておきます。

日本でも内製化に取り組む企業が増えています。ユーザー企業に技術者が増えれば、契約に縛られない進め方が可能になります。構造が変われば、要件定義のやり方も変わります。

一方で、経済産業省の調査が示すようにIT人材の不足は続いており、すべての企業が内製化できるわけではありません。委託構造が残る限り、事前確定型の要件定義も残ります。

現実的には、両方の方式を使い分けられる人材の価値が上がると考えられます。案件の性質に応じて方式を選び、関係者に説明できる人です。どちらが優れているかを論じるより、実務としては有用な立ち位置です。

文書の書き方の違い

同じ要件定義書でも、書かれる内容の重点が異なります。

日本型で厚くなるのは、網羅性です。正常系だけでなく、例外処理、異常系、想定される全パターンを列挙します。あとで「書いていない」と言われないための備えでもあります。

海外型で厚くなるのは、目的と背景です。なぜこの機能が必要か、誰のどんな課題を解くのかを先に書きます。詳細は実装しながら決める前提のため、判断の基準を共有することに重点が置かれます。

どちらが優れているというより、後から読む人が違うのだと考えると理解しやすくなります。前者は検収する人が読み、後者は実装する人が読みます。

両方の要素を持つ文書が理想ですが、分量が増えれば読まれなくなります。誰に向けて書くのかを決めることが、現実的な妥協点です。

オフショア開発で起きること

日本企業が海外の開発会社に委託する場合、この違いが直接問題になります。

最も多い摩擦は、指示の解釈です。日本側が「常識的に考えて当然」と思う仕様が、書かれていないために実装されません。悪意ではなく、前提が共有されていないだけです。

次に多いのは、報告のタイミングです。問題が起きたときに、解決策を用意してから報告する文化と、起きた時点で共有する文化があります。前者では、発覚が遅れます。

対応としては、次が有効です。

• 暗黙の前提を書き出す／自分たちの当たり前を明文化する作業。国内案件でも役立つ
• 動くものを早く見る／文書での合意より、画面を見たほうが誤解が早く見つかる
• 質問しやすい状態を作る／質問が来ない状態は、理解されている証拠ではない

3つ目が最も見落とされます。質問が少ないプロジェクトほど、後半で大きな手戻りが起きます。