Yutaのアメリカ職場奮闘記 #2 | Yuta、仕様書作成で戸惑う

「役割分担を守ることが大切だ」と学んだYutaは、アメリカでの職場で Business Analyst（BA）としての役割に専念しよう と決意しました。
今度はプログラムを書くことはやめ、仕様書の作成に全力を注ぐことにします。

しかし、ここでもYutaは 「日本での当たり前」と「アメリカでの当たり前」のギャップ に直面することになります。
日本では詳細で完璧な仕様書が評価されますが、アメリカでは「短く、簡潔であること」が求められるのです。

---

今回は、Yutaが 仕様書作成で戸惑いながらも少しずつアメリカの文化を理解していく姿を描くリーディング問題 に挑戦していただきます。

「あなたならどちらが働きやすいと思いますか？」
そんなことを考えながら読み進めてみてください。

あらすじ（全体）

Yuta（35歳） は日本でシステムエンジニアとして、仕様書作成もプログラムも自信を持って完璧に仕上げていた。
アメリカへ移住し、BA（Business Analyst）として勤務を開始。

しかし、

• プログラムを書こうとすると developer であるSteveから「俺らの仕事を奪う気か？」と注意され、仕事の境界がはっきり分かれていることに戸惑う。
• ユーザーから改修依頼を受け、仕様書作成に力を入れるが、日本の作り方との違いに戸惑う。
• テスト後、UAT環境へアップしたが動作せず、古いバージョン使用が原因だった。なぜそんな基本的な確認をしないのかと憤る。
• 色々フォローし、ようやくリリース。しかし評価されたのは Steve。Yuta は黙々と作業していたが、developer は常に周囲に進捗を伝え「見える努力」をしていたからだった。

Yuta は結果だけでなく「過程を見せること」が評価される文化を痛感する。

英文パッセージ

One day, Yuta received a system change request from a user. He decided to focus on making a clear and detailed specification document. Yuta thought, “I will forget about programming for now and do my best as a Business Analyst.”

In Japan, Yuta used to write long and detailed documents, explaining everything carefully. He believed that this would help developers understand the work easily. So, he started writing the document in the same way in America.

However, when Yuta showed the document to Steve, the developer, Steve looked confused and said, “This is too long. Can you make it shorter?” Yuta was surprised. In Japan, detailed documents were seen as good, but here, people wanted simple and short documents.

Yuta tried to make the document shorter, but he was worried that Steve might not understand all the details. Emily, another Business Analyst, told him, “Don’t worry, Yuta. If Steve has questions, he will ask you directly.”

Yuta felt a bit nervous, but he decided to try this new way. He realized that in America, communication during the process was more important than writing every detail in the document.

読解問題

1.What did Yuta decide to focus on after receiving the request?
A) Writing a clear specification document.
B) Writing a program by himself.
C) Teaching Steve about the system.
D) Talking with the user many times.

2.How did Steve react when he saw Yuta’s document?
A) He was happy to see the long document.
B) He asked Yuta to make it shorter.
C) He wanted Yuta to add more details.
D) He did not read the document.

3.What did Yuta realize at the end?
A) Details in documents are the most important.
B) It is better to write long documents.
C) Talking during the process is important.
D) He should write documents in Japanese.

学びポイント・Tips

Yutaはアメリカでの職場でプログラム作成を封印し、Business Analystとして仕様書作成に全力を注ぐことを決意しました。
しかし、日本で当たり前だった「長く詳細な仕様書」は、アメリカでは「長すぎる」と言われ、短く簡潔にまとめることが求められる現実に戸惑います。

最終的にYutaは、「文書で全てを伝えきることより、途中でコミュニケーションを取ることが大切」だと学びました。

---

💡 いかがでしたか？
あなたなら、仕様書を作成するとき 「詳細で完璧に作る」 のと 「簡潔に作って会話で補う」 のどちらを選びますか？

ぜひコメント欄であなたの意見を教えてください。

---

次回【場面3】では、ようやくテストが完了しUAT環境へアップデートしたYutaが、また新たなトラブルに直面します。
なぜかシステムが動かず、確認すると 「古いバージョンのままだった」という初歩的なミスが原因でした。

「なぜこんな基本的なことをチェックしないのか？」

そんな疑問を抱えるYutaが 次に学んだこととは何だったのか、一緒に学んでいきましょう。

👉 【次の記事】Yutaのアメリカ職場奮闘記 #3 | UAT環境で動かない理由とは？