海外エンジニアがプログラミング特に仕様書作成でつまづいたこと

「理想と現実のギャップ。海外での“仕様書”文化ショック」

はじめに

「よし、海外でもやっていける！」
そう思ったのは、実は日本で数年間、ITエンジニアとして経験を積んだ後のことだった。特にC# WPFでのアプリケーション設計開発にはそこそこ自信があったし、「設計」「実装」「テスト」といった開発フローにも慣れていた。日本では当たり前にやってきた「詳細設計書」や「画面遷移図」、「データフロー図」なんかも、もう何十回も書いてきた。

そんな中、僕は意を決して、某ヨーロッパのIT企業に転職。現地の言葉はまだまだだったけど、プロジェクトはグローバル案件で公用語は英語。それなら何とかなるだろうと思っていた。

だけど、最初のプロジェクトにアサインされて、真っ先にぶち当たった壁が「仕様書文化の違い」だった。

---

「えっ、これが仕様書？」最初のカルチャーショック

プロジェクト初日。プロジェクトマネージャーが僕に渡してきたドキュメントは、Wordで3ページ程度のシンプルなもので、タイトルは「Functional Overview」。
内容はというと、

• 画面のざっくりしたイメージ図（手書きっぽい）
• 想定するユーザーアクションのリスト
• システムが返すべきレスポンスのざっくりとした説明

…以上。

「…え？これだけ？」
思わず心の中で叫んだ。

日本でやってきたあの詳細設計書、クラス図、シーケンス図、データベースER図、画面項目定義書、バリデーション仕様、エラーメッセージ一覧…。そんなものはどこにもない。

プロジェクトマネージャーに「もっと詳細な設計書はどこ？」と聞くと、
「ないよ、これで作り始めるから」
と、サラッと笑顔で言われた。

その瞬間、僕の頭の中で「警告アラート音」が鳴り響いた。

---

頭の中の「日本式プロセス」が邪魔をする

ここで問題だったのは、僕自身の「思考の癖」だった。

日本で何年も経験してきた開発スタイルは、いわゆる「ウォーターフォール型」。
「まずは要件定義、次に外部設計、内部設計、詳細設計、それからコーディング、単体テスト、結合テスト、総合テスト…」という流れ。

仕様書はその中でも特に重要な「絶対ルールブック」。
ドキュメントで全てを明文化しないと、設計レビューで怒られるし、後工程で「設計漏れ」として大問題になる。

だから僕の頭の中では、
「仕様が曖昧なまま開発を始めるなんてあり得ない！」
「詳細設計なしで進めたらバグ地獄になるに決まってる！」
「まずは設計書を書いて、それをレビューしてもらわないと…」
という思考がグルグル回っていた。

でも、現地メンバーはそんな僕の動揺には気づかない様子で、どんどん話を進めていく。

---

「とりあえず動くものを作ってから決めよう」文化

さらに追い打ちをかけたのが、次の一言。

「とりあえず動くプロトタイプ作ってくれる？」

プロジェクトマネージャーがそう言ったとき、僕は一瞬フリーズした。

「え、まだ画面レイアウトも決まってないし、エラーメッセージもないし、データベース設計も曖昧なのに…？」
でも周りのメンバーたちは「それが普通」という顔をしている。

この瞬間、僕は気づいてしまった。

「あ、ここは“作りながら決める文化”なんだ…」

そう、ここで求められているのは「アジャイル的なスピード感」と「コミュニケーション重視の仕様決定プロセス」。
細かい仕様はその都度ミーティングで話しながら、都度ソースコード側で反映していく。
変更があったらその場で対応。ドキュメントは後追いで、最悪なくてもOK。

完全に日本の「事前にすべて決めてから動く文化」とは真逆だった。

---

「自分が今まで信じていた正しさ」が崩れる瞬間

このときの感情は、正直に言えば「恐怖」だった。

「このまま仕様がブレブレのまま進んで、リリース直前に大炎上するんじゃないか？」
「誰も詳細設計を気にしないこのチームで、自分がちゃんと成果を出せるんだろうか？」
「言葉も文化も違う環境で、どうやって食らいついていけばいいんだろう？」

僕の中にあった「日本式エンジニアとしての成功パターン」は、一瞬で崩れ去った。

でも、この壁こそが、僕にとって最初の「海外エンジニア文化ショック」の始まりだった。

「試行錯誤のはじまり。自分流の“翻訳作業”」

「このままじゃダメだ…でもどうすればいい？」

最初のカルチャーショックを受けた翌日、僕はオフィスの自分のデスクで一人、頭を抱えていた。

朝のデイリースクラムでは、PMから「今日中にプロトタイプのログイン画面だけ動かしてほしい」とさらっと言われた。でも、その「ログイン画面の仕様」は、あのざっくりした「Functional Overview」に書かれているたった数行のテキストだけ。

「ユーザーがユーザー名とパスワードを入力できる画面を作る。ログインボタンを押すと、認証APIを叩いて、成功ならダッシュボードに遷移。失敗ならエラー表示。」

それだけ。

「バリデーションルールは？
エラー時のメッセージは？
入力最大文字数は？
パスワードの制約は？
UIのデザインガイドラインは？」

次から次へと疑問が湧いてくる。

日本なら、この時点で詳細設計レビュー用のExcelシートを開いて、全部の項目を仕様として書き出して、レビュー依頼をかけていた。でもここでは、誰もそれを求めていない。誰もそんなもの見たがっていない。

「このまま動くものだけ作って、後から『ここ違う』『そこ違う』ってなるんじゃ…？」

そんな不安でいっぱいだった。

---

「仕様の“行間”を読み取れ！」という現地流

でも、ただ悩んでいる時間はない。

僕はひとまずチームメンバーに聞くことにした。

隣の席にいたローカルのシニアエンジニアに「この画面、バリデーションルールとかどうする？」って聞いてみた。

すると、返ってきた答えがこれ。

「まずは当たり前の範囲で作ってみて。必要なら後で変えればいいから。」

…当たり前って、どこまでが当たり前なの！？
頭の中でそう突っ込みながら、さらに突っ込んで聞く。

「じゃあ、パスワードの文字数制限とかは？」
「まぁ、今どきは8文字以上とかでいいんじゃない？」
「エラーメッセージのフォーマットは？」
「ユーザーが理解できればOK。」

こんなやりとりをしながら、僕はようやく気づき始めた。

「彼らは、“仕様”を事前に全部ドキュメントに落とす文化じゃないんだ」

• 仕様は最低限だけ。
• 詳細はその場で口頭で決める。
• 後から変更があったらその都度直す。
• みんなの頭の中には「暗黙の共通認識」があって、そこから外れたら指摘が入る。

その「暗黙の共通認識」に僕がまだ馴染めてないだけ。

---

「日本式詳細設計書」を勝手に作り始める作戦

でも、だからといって完全にノープランでコーディングするのは、僕の性格的に無理だった。

そこで僕がとったのが、「自分用のミニ仕様書を勝手に作る」作戦。

具体的には、以下のような流れにした。

1. 現地のざっくり仕様をまず受け取る
   → 3ページのFunctional Overviewをしっかり読み込む。
2. 気になる仕様抜けは全部Notionにメモする
   → 「入力最大文字数」「バリデーションルール」「エラーメッセージ例」「UIコンポーネント選定方針」など、自分が日本で慣れていた観点で、勝手にQ&Aリストを作成。
3. 作りながら、都度Slackで確認を取る
   → 実装中に「これでいい？」と思ったタイミングで必ずメンション付きで質問。「実装→確認→実装→確認」のループ。
4. 完成後、自分用の“詳細版機能仕様”をチームにこっそり残す
   → コードと一緒にNotionにまとめておいて、もしレビューや改修が必要になった時に活用。

これによって、少なくとも自分の中では「安心材料」ができた。

---

「口頭仕様」をキャッチアップするスキルが必要

それでも難しかったのは、ミーティングのスピード感だった。

特にデイリースクラムやスプリントプランニングのとき。

英語ネイティブ同士がガンガンしゃべるスピードについていくのが、まずキツい。さらに、その会話の中で次々と「その場で仕様が変わる」。

• 「あ、そのフィールド、やっぱり削除で」
• 「バリデーション？今朝決まったけど、API側でやることにしたから」
• 「UIはマテリアルデザイン準拠でって話、先週したよね？」

僕が日本でやっていたような「事前にすべて書面化して合意」というプロセスは、存在しない。

代わりに必要だったのは、

• 「会話の中で仕様変更をリアルタイムでキャッチする力」
• 「不明点は即質問する勇気」
• 「仕様が変わってもすぐ心を切り替える柔軟性」

このあたりは、正直最初の1ヶ月はかなり苦しんだ。

「また仕様が変わったのかよ！」
「どこまでが確定で、どこからが暫定なのか分からん…」
「このペースでドキュメント追いつくわけない…」

そう何度も心の中で毒づきながらも、毎日Slack、Teams、Notion、Figma、Jiraを行ったり来たりして、必死で追いかけた。

---

少しずつ見えてきた「アジャイルの本質」

ただ、そんな日々が2週間くらい続いたころ、少しずつ「このスタイルの良さ」も分かってきた。

例えばある日、実際にプロトタイプ版のログイン画面が完成して、PMと一緒にレビューしているとき。

「ここ、ラベルのテキストもう少し優しくしようか」
「このローディングアニメーション、もっとシンプルな方がいいかも」
「パスワードフィールド、ショーボタン付けたらユーザー喜ぶよ」

こんな会話が、その場で次々と決まり、次のスプリントですぐ反映された。

日本だったらこれ全部、設計変更依頼書を書いて、上司レビューして、承認フロー通して…ってなってたはず。でもここでは、「良いと思ったら即変更」。

ユーザー目線で、最終成果物の品質をどんどん上げていく文化。

このとき、僕の中で少しだけ「心の壁」が溶けた気がした。

「仕様変更地獄、そして“認識のズレ”による大炎上」

やっと慣れてきたと思った矢先に…

自分用のミニ仕様書を作りながら、Slackやデイリースクラムでこまめに質問して、なんとか「海外仕様書文化」に少しずつ適応できてきた頃。

ちょっとずつだけど、「ああ、この会社はこういう進め方をするんだな」と思える瞬間も増えてきた。

特に、プロトタイプを作ってからフィードバックを受けて修正していくスタイルは、慣れると楽しかった。
「動くものがどんどん形になっていく感覚」は、ウォーターフォール時代の「半年後にやっと動作確認」みたいな開発とは全然違うスピード感だった。

「意外と、このやり方も悪くないかも。」

そんなふうに思い始めていた、まさにそのとき――

「仕様変更地獄」が始まった。

---

週1レベルで変わる「要件」

ある日、PMがSlackにこう書き込んできた。

「By the way, we’ve decided to support SSO login too. Can you add that to the login screen?」

…ちょっと待って。
SSO対応って、そんなに軽く言っていいものなの？

日本で言うなら、「ログイン画面に突然Googleアカウントログインを追加する」くらいの話だ。APIも違えば、UIも変わる。認証フローだって変更になる。

当然、僕はすぐに「じゃあ、仕様書は？」と聞く。

返ってきた答えは、

「Just check the API doc and talk to the backend guy.」

…まじか。

---

「言った」「聞いてない」の泥仕合

ここからが本当の地獄だった。

SSO対応を進めていたら、さらに次の週にはこう言われた。

「Actually, marketing team wants to change the login flow. First, users will land on a landing page, then choose between email login and SSO.」

「え、また仕様変わったの？」
「このフロー変更、いつ決まったの？」
「先週の水曜日のマーケ会議で話してたよ？」

でもその会議、僕呼ばれてないんだけど…。

PM曰く、「口頭で伝えたつもりだった」「Slackで書いてたつもりだった」らしい。でも、Slackのタイムラインは他のプロジェクト通知で埋もれていて、僕には届いてなかった。

ここでついに起きたのが、**「言った言わない問題」**だった。

---

リリース直前に大爆発

その後も怒涛のように細かい仕様変更が続く。

• 「ログイン失敗時は、もう一回試すボタンを追加して」
• 「エラーメッセージ、もっとユーザーフレンドリーにして」
• 「UIは今風にもっとフラットデザインに寄せて」
• 「パスワードポリシー、やっぱり変更で」

しかも、全部「設計書上ではどこにも記載がない」まま、口頭とSlackとFigma上で進んでいく。

で、いよいよ迎えたリリース直前の週。

ステークホルダー向けのレビュー会議が開かれた。

その場で、プロダクトオーナーが言い出した。

「え、これ、まだSSOログイン未対応なの？」
「マーケページへの遷移ないじゃん？」
「このエラーメッセージ、誰がこれでOK出したの？」

会議の空気が一瞬にして凍りつく。

「これは誰の責任？」
「誰がレビューした？」
「誰が仕様変更を伝えてなかった？」

名前が出たのは…そう、僕だった。

「仕様理解してないまま開発進めたんじゃないか？」
「なんで仕様変更をキャッチできてないの？」
「開発者としてのコミュニケーションが足りないんじゃない？」

正直、泣きそうだった。

「いやいや、ドキュメントもないし、口頭だけで進んでたのに…」
「むしろ、こっちはずっと確認し続けてたし…」
「言った言わないが多すぎるんだよ！」

心の中では叫んでいた。でも、現実にはそれが通じるわけもない。

---

「文化的期待値ズレ」という見えない罠

この時はじめて痛感した。

「ドキュメントがない前提の文化」で働くなら、
「自分でそれをカバーするための行動」をとらないと、
“外国人エンジニア”として真っ先に責められる立場になる。

日本式ウォーターフォール文化に慣れすぎていた僕は、
「決まった仕様をもとに、正確にコーディングする」
という職人スタイルの意識が強すぎた。

でも、ここで求められていたのは、全く逆のスキル。

• 「曖昧な状況下で、自分からどんどん確認に行くこと」
• 「会話やチャットの中で小さな変更点を見逃さないこと」
• 「明文化されていない内容も、自分でまとめて周囲に共有すること」
• 「場合によっては、自分が“非公式の仕様書作成係”になること」

しかもそれを、「自分から積極的に」「自発的に」「誰にも言われなくても」やらないと、“仕事ができないエンジニア”というレッテルを貼られる。

このとき、僕は本気で自分のやり方を変えなきゃと思った。

---

自分が変わらないと生き残れない

会議の翌日、僕は思い切ってPMに言った。

「これ以上、口頭だけで進めるのは無理です。
僕が非効率になるし、誤解も増えます。
これからは、僕が全仕様変更点をNotionでまとめます。
変更があったら、必ずそこに記録してもらえませんか？」

PMはちょっと驚いた顔をしていたけど、
「That’s a good idea. Go ahead.」
と、あっさり承諾。

それから僕は、毎日朝一で「仕様変更サマリー」をNotionにまとめて、
Slackに「昨日の変更点アップデートしました。要確認」と投稿することにした。

「“仕様がない”環境で生き残るために。僕が選んだ３つの戦略」

「二度とあの炎上は繰り返さない」と決めた日

あのステークホルダー向けレビュー会議の大炎上事件から数日後。

正直、しばらくは落ち込んでいた。

「なんで自分だけ責められなきゃいけないんだろう」
「そもそも、この環境が悪いんじゃないか？」
「日本だったら、こんな進め方あり得ないのに…」

そんなふうに思っていた。でも、冷静になって一つ気づいた。

「たとえ環境が違っても、責任が発生するのは“アウトプットを出すエンジニア側”」

どんなに仕様が曖昧でも、文化が違っても、
最終的に動くものを作るのは自分。

「これはもう、環境のせいにしても意味がない。
自分がこの環境で生き残れる方法を探すしかない。」

そう腹をくくった。

---

戦略①：「非公式プロダクトオーナー」になる

最初に決めたのは、「自分が誰よりも仕様に詳しくなること」。

日本では「プロダクトオーナー」と言えば、要件定義担当者とかビジネス側の人間。でも、この会社にはそんなポジションが明確には存在しない。
ある意味、みんながフラットで、誰もが「なんとなく決める」状態だった。

なら、僕が「非公式PO」になろう。

具体的にはこうした。

• 全ての仕様変更をNotionで時系列に記録
  → 「いつ」「誰が」「どのミーティングで」「どんな理由で」仕様を変えたかをログ化。
• 毎日のスタンドアップ後に“仕様変更サマリー”をSlackに投稿
  → 「昨日の会話で決まったこと」や「仕様不明点」をチーム全体に共有。
• JiraチケットのAcceptance Criteria（受け入れ条件）を自分で追記
  → もともとはガラガラだったチケットに、必要最低限の動作条件を書くようにした。

これを続けたことで、チーム内でも次第にこう言われるようになった。

「仕様でわからないことがあったら、とりあえずHiroに聞こう。」

---

戦略②：「会話の“暗黙仕様”を見逃さない癖付け」

次に取り組んだのが、**「ミーティング中の微妙な一言も拾い上げる力」**を鍛えること。

最初の頃は、ネイティブの早口英語や冗談混じりの会話に埋もれて、重要な仕様変更の話を聞き逃していた。

それを防ぐために始めたのがこの３つ。

1. ミーティング中は必ず画面録画＆メモ
   → 会議後に必ず聞き直して、不明点はSlackで即質問。
2. 「それ、仕様変更ですよね？」と明確に口に出す
   → 会話の流れで決まったことも、必ず最後に確認フレーズを入れる。

例：「So, just to confirm, we’re now removing the password length restriction, right?」

3. 仕様変更が出た瞬間にNotionへ追記
   → ミーティング終了後ではなく、「その場で」Notionに打ち込む。

これを続けていくうちに、次第に「Hiroはちゃんと仕様をトラッキングしてくれる人」という信頼が生まれてきた。

---

戦略③：「ミニ仕様書文化」をチームに植え付ける

最終的には、「自分だけが頑張っても限界がある」と悟った。

だから、次のステップとしてやったのが、チーム全体のドキュメント意識を少しずつ変えること。

完全に日本式のウォーターフォールドキュメント文化に戻すのは不可能。でも、最低限の「ライトウェイトドキュメント文化」なら作れるかもしれない。

具体的には、こんなアクションを起こした。

1. 「1ページ仕様書」ルールを提案
   → 新しい機能ごとに、必ずConfluenceかNotionに「1ページでいいから仕様まとめ」を作るルールを提案。
2. 「Doneの定義」に“仕様確認済み”を追加
   → Jiraの「Definition of Done」に「仕様がNotionまたはConfluenceに反映されていること」を追加。
3. ふわっとした会話が出た瞬間、「今の仕様変更、ドキュメント化しますね」と宣言
   → 口頭文化のまま終わらせない。

最初はチームから「また日本人が書類文化を持ち込もうとしてるよw」みたいに茶化された。でも、2〜3回これを繰り返すと、意外とみんなも「その方が助かるね」と受け入れ始めた。

「そういえば最近、認識ズレ少なくなってない？」
「Hiroがまとめてくれてるから、めちゃ楽だわ」
そんな言葉が聞こえてきたときは、本当に嬉しかった。

---

得た教訓：「正しさ」より「成果」を出すマインドセット

この経験を通して、僕が一番学んだのはこれ。

「どの文化が正しいか」を議論するよりも、
「今いる環境で、どう成果を出すか」を考えたほうがいい。

日本式の「完璧な仕様書文化」には、それはそれで良さがある。
でも、海外の「スピード重視・会話駆動・アジャイル文化」にも、別の良さがある。

重要なのは、「どちらが正しいか」ではなく、
「どちらに今、自分が身を置いているのか」、そして
「その中でどうすれば自分もチームも成功できるか」。

僕はこの体験を通じて、単なる「コードが書ける人」から、
**「仕様曖昧環境でも自分から状況を動かせるエンジニア」**に少しだけ成長できたと思う。

---

今、同じ悩みを抱えている人へ

もしあなたがこれから海外で働こうとしていて、
「仕様書がないと仕事できない！」
「ドキュメントが曖昧すぎて怖い！」
「文化の違いでミスをしてしまいそう…」

そんな不安があるなら、ぜひ伝えたい。

その気持ち、めちゃくちゃ分かります。僕も同じでした。

でも、大丈夫。

大切なのは、

• 小さくても自分から行動を変えること
• 曖昧なら、まずは自分で明文化すること
• 言われたことを待つだけじゃなく、こちらから確認を取りに行くこと

そして何より、「自分がどうしたらチームを楽にできるか」を常に考えること。

それさえできれば、どんな文化でも必ず生き残れる。

むしろ、「日本式の細かさ」と「海外式のスピード感」の両方を身につけたエンジニアは、
どこに行っても重宝されるから。

僕は今、そう信じて毎日働いています。

---

最後に：この経験が今の自分の強みになった

今振り返ると、あの「仕様書がなくてパニクってた日々」こそが、
僕が「グローバルエンジニア」として成長できた最大のターニングポイントだった。

次のプロジェクトでも、また違う国のチーム、違うやり方にぶつかるかもしれない。

でももう、怖くない。

なぜなら、僕はもう知っているから。

「文化が違っても、成果は出せる。」

それが、この経験から得た一番大きな学びだった。