なぜアメリカの一流エンジニアは15〜16時に帰るのか。資本主義の最前線で生き抜く「仕事をゲームと割り切る」マインド

NEW! 2026.06.01 働き方

近年は「休み方」をテーマにした啓蒙本がブームになっている。「休むことで生産性を上げる」「世界の一流はこう休んでいる」といったメソッドを目にする機会は多い。

だが同時に、「それはアメリカのビッグテックで、周囲の理解や優秀な仲間に恵まれているからできる理想論では？」「日本で同じように実行できるわけがない」と感じることはないだろうか。

『世界の一流が休むためにやっていること』（朝日新聞出版）の著者であり、現在は米シアトルのテック企業でシニア・プロダクト・マネージャーとして活躍する福原たまねぎさんも、かつてはそうした「休めない日本の現場」で絶望していた一人だ。

福原さんのキャリアは渋谷のITベンチャーから始まった。会社に寝泊まりすることは日常茶飯事で、外資系IT企業の日本オフィス時代も朝7時から深夜0時まで働くなど、「泥臭く過酷な現場」を経験してきたと言う。

「休めない日本の組織」において、一流の休み方は本当に実行可能なのか。福原さんに話を聞いた。

福原たまねぎさん（@fukutamanegi）

外資系IT米国本社のシニア・プロダクト・マネージャー。ワシントン大学MBAメンター（キャリア・アドバイザー）。大学卒業後、渋谷のベンチャー企業を経て、2016年、外資系IT 企業の日本支社に入社。webプロデューサー、プロダクト・マネージャーを務め、22年、米国本社に転籍。テクノロジーの現場から働き方、思考法、文化の違いなどを観察し、その成果をnoteで発表している。25年に投稿した「'仕事のできるエンジニアしかいらない'という怖い世界」が「note創作大賞2025」に入選し、話題になった

仕事と自分の間に明確な境界線を設ける
「たかが仕事」と割り切るから、ハイパフォーマンスを出せる
仕事を減らせるかどうかは、手を付ける前に9割決まる
一番やるべきことに全集中し、後は一旦忘れる
引継ぎ書には「目的」と「方針」さえ書けばいい
事前準備を徹底し、本気で休みを取りに行く

仕事と自分の間に明確な境界線を設ける

ーーアメリカのビジネスパーソンは、実は物凄くハードに働いていると聞いたことがあります。実際のところ、どうなのでしょうか？

確かに金融業界など、一部の業界では一日中働き詰めているようなところもありますね。馬車馬のようにハードに働く人が多い印象です。

ただ少なくとも、僕がいるビッグテックをはじめとするテック業界では、16時〜17時以降も働く文化はあまりありません。極端なケースだと、午前中に仕事を終わらせて、午後はビジネススクールに通うような人もちらほら見かけます。

日本と比べて始業時間が少し早いというのはありますが、残業している人はまず見たことがありませんね。

ーーテック業界の人たちが早く帰れるのは、世界中から集まった「天才」だからですか？根本的な処理スピードが違うみたいな……。

僕もアメリカに行くまではそう思っていました。でも、実際にこちらで働いてみると、頭の良さや技術力に日米でそこまで大きな差は感じません。

もちろんイーロン・マスクのような天才はいますが、それはごく一部。99％の人たちは、日本の優秀なエンジニアと能力的に大きく変わらないんです。

ーー能力に差がないとすれば、なぜ早く帰れるのでしょうか？

仕事に対する「マインドセット」の違いですね。

日本では、無心になって仕事と同化すること、いわゆる「当事者意識を高く持って自分を捧げること」が美徳とされがちですよね。しかしアメリカでは、むしろ仕事と自分を意図的に切り離しています。

イメージとしては、仕事を「RPG」のように捉えている感覚に近いです。ゲームの中の役割を会社で真剣に演じるけれど、夕方になれば「はい、セーブ」と電源を切り、本来の自分の生活に戻っていく。

仕事はあくまで「生きるためのリソース（お金）を得る手段」として、クールに受け止めている方が多い印象です。

「たかが仕事」と割り切るから、ハイパフォーマンスを出せる

ーーでも、そこまでドライに割り切ってしまうと、仕事への責任感やモチベーションが下がってしまいませんか？

それが逆なんです。「仕事＝自分」と同一視してしまうと、仕事でネガティブな評価を受けた時に、自分という存在そのものを否定されたようなショックを受けますよね。その結果、メンタルを病んで休職してしまう人を日本で何人も見てきました。

ですが、仕事をゲームと割り切れば、失敗してもそれは「ゲームでの敗北」であり、人生の敗北ではありません。この自己防衛の線引きがあるからこそ、過度に気を落としたりイライラしたりせず、常に高いモチベーションとパフォーマンスを保てるんです。

それにアメリカのテック企業は、大規模なレイオフが日常的に起こるシビアな環境です。僕自身、昨日まで切磋琢磨していた同僚が急に解雇されるのを目の当たりにし、「仕事にアイデンティティーを置きすぎる」ことの危険性を痛感しました。

そんな資本主義の最前線で生き延びるためには、「たかが仕事」と距離を保って自分を守らなければやっていけないのです。

ーーいくらマインドを変えても、現実問題として目の前に山積みの仕事があったら定時では帰れませんよね。

その通りですね。仕事が終わらなければ、当然帰れません。

実は、日本とアメリカで決定的に違うもう一つの要素が、「タスクの量」なんです。日本はタスクが多いから定時で帰れない、アメリカはタスクが少ないから帰れる。身も蓋もないですが、本当にこれだけの話なんですよ。

では、なぜアメリカの現場はタスクが少ないのか。それは「仕事を減らす力」がずば抜けて高いからです。

「仕事と自分を切り離す」マインドセットがあるからこそ、不要なタスクを断ることに過剰な罪悪感を持ちません。決して、魔法のようなスピードで膨大なタスクを処理しているわけではないんです。

仕事を減らせるかどうかは、手を付ける前に9割決まる

ーー「仕事を減らす力」とは、具体的にどういうことなのでしょうか。

一言で言えば、手を動かす前の段階で「そのタスクが本当に効果をもたらすのか」を徹底的に吟味し、やるべきことを極限まで絞り込む力のことです。

日本では、上司からの依頼に対して「黙って素早く手を動かす」ことが美徳とされがちですよね。しかし、それでは「そもそもやるべきか？」を問うことができないまま進んでしまい、結果的に効果の薄い、誰も喜ばない仕事が積み上がっていきます。

私自身、日本にいた頃は「必須のタスク」も「なんとなく用意しないと怒られそうなタスク」も一緒くたにして、よく精査せずに手をつけてしまっていました。

ですがアメリカでは、プロジェクトを始める前から「なぜやるのか？」「ビジネスインパクトはどれくらいか？」をとことん吟味し、やるかやらないかの見極めにものすごく時間をかけます。

プロジェクト開始前に実行可否について議論するアメリカのビジネスパーソンのイメージ

ーー効果を吟味するのは大事だと思いますが、「やらない判断」を了承してもらうのは大変じゃないですか？

「やりたくないです」「意味がないと思います」と感情的に言えば、日本でもアメリカでも普通にアウトです。上司を説得することはできません。だからこそ、角を立てずに仕事をポジティブに捨てるために「書く」ことを徹底しています。

例えば、実際に私が経験した事例をご紹介します。ある時、1年かけて他部署と連携して作った新機能が、逆にお客様からの問い合わせを増やしてしまう問題が起きました。

私は最初「1年もかけたのだから工数をかけてでも直すべきだ」と思っていたのですが、マネージャーに言われて、考えられる全てのオプションの「メリット（定性的な価値）」「デメリット」「工数」「ビジネスインパクト（定量的な価値）」をドキュメントに書き出してみたんです。

すると自分でも驚いたことに、「工数がかかる割にリターンが少なく、デメリットが多い」という現実がデータとしてはっきり可視化されました。これを開発トップに見せたところ、たった5分で「工数の割に効果が薄いなら、やめよう」と機能の廃止が決まりました。

このように、可視化されたデータを見て「これは手間の割にリターンが少ないな」と納得すれば、ポジティブに「やめる合意」ができます。

オンライン決済プラットフォームで有名なStripeなどの企業がライティング文化（口頭で済まさず徹底的に文章化する文化）を極めて重視しているのも、思考を「外部化」して意思決定をドライブするためなんですよ。

一番やるべきことに全集中し、後は一旦忘れる

ーー「本当に成果が出る仕事」を見極めた後は、どのように進めていくのでしょうか。

仕事をさらに細かく分解して、「やるべきこと」を徹底的に減らしていきます。ここで重要になるのが「P0（Priority 0 ＝ないと成り立たないもの）」と「P1（Priority 1＝あればなお良いもの）」という考え方です。

P0（Priority 0 ／ピー・ゼロ）

最優先、即時対応が必須のもの。これを完了しないとサービスが成り立たないなど、致命的な問題が生じるタスク。
（例）決済ができない、ログイン不可能などの問題解決

P1（Priority 1 ／ピー・ワン）

価値や成長に大きく関わるが、緊急度は低く、なくても一応成り立つもの。
（例）あると便利な機能の開発、直感的なデザインへの修正

これは主にプロダクト開発の現場で、タスクの優先度を明確にする言葉として広く使われています。アメリカではエンジニアやプロダクトマネージャーに限らず、デザイナー、ファイナンス、営業やマーケティングの担当者まで、日常的にこの言葉を使って議論しているんですよ。

そしてここでのポイントは、最初の段階ではP0だけに全集中し、P1は一旦完全に忘れるということです。

ーーいくら優先順位が低いとはいえ、それはちょっと難しくないですか？

私もアメリカに来て驚いたのですが、皆、本当にP1の仕事をどんどん忘れて後回しにしていくんです。というのも、この「P0／P1」はいわゆる日本の「優先順位付け」とは決定的に異なる部分があります。

通常、タスクに優先順位を付けたら、それぞれに「いつまでにやるか」という期限を設定しますよね。そして、優先順位の高い順にすべてのタスクを並べ、「いつ全部完了するか」の見通しを立てると思います。

ですが「P0／P1」の考え方では、本当に大事なタスク（P0）だけをスケジュールに組み入れ、P1はそもそもプランに入れません。私たちは無意識に「P0もP1も最後までやらなければいけないタスク」と思い込みがちですが、P1はあくまで「余裕があればやる」という位置付けなんです。

引継ぎ書には「目的」と「方針」さえ書けばいい

ーータスクを減らし、P0に絞って効率よく仕事を進めたとしても、実際に「休みを取る」となるとまた別のハードルがあるように感じます。

「休みを取りにくい」と感じる気持ちはよく分かります。人に迷惑をかけるかもしれないし、自分の仕事を誰かにお願いすること自体に、心理的な負担を感じるものですよね。

ただ現実として、アメリカのテック企業の一流エンジニアたちは、プロジェクトの途中でも当たり前のように休みを取ります。しかも、1〜3週間は平気で休むんですよ。

渡米した当初は私も「よくこれだけ人が抜けても仕事が回るな」と不思議に思っていました。そこで、エンジニアたちが休む前の行動をつぶさに観察してみたんです。すると、彼らは「自分がいなくなっても回る仕組み」を「書く」ことで生み出していることに気付きました。

ーーどのようなことを書いていたのですか？

進行中のプロジェクトの「ざっくり企画書」と、やるべきタスクの「達成条件」の二つです。

まず「ざっくり企画書」ですが、これは「このプロジェクトをやる意味」と「どういう方針で進めるのか」だけを書きます。細かいタスクや、それを実行する手順までは書きません。プロジェクトの大まかな全体像や構造、そしてそれがそうなっている理由や目的を概要的に記せばOKです。

この企画書を書き出す上で重要なのは、プロジェクトの途中ではなく、スタート時点で徹底的に記しておくことです。

元マイクロソフトの伝説的エンジニアである中島聡さん（@snakajima）は著書の中で「ロケットスタート時間術」を説いていますが、まさにそんな感じでシアトルの一流エンジニアたちはスタート時点で全力で資料をまとめておくんですよ。また可能であれば、関係するチームメンバー全員で内容をチェックできるとより安心ですね。

そして「達成条件」については、文字通り、タスクごとに「何を達成したら完了とみなすか」を事前に書き起こします。プロダクト開発では「アクセプタンス・クライテリア」と呼ばれる手法で、世界中で広く使われているものです。

ーー達成条件だけですか？日本だと「休むなら詳細な手順書を残さないと無責任だ」と言われそうです。

日本人は、手順書を作るのがとても上手ですよね。「●●さんの引継ぎ書がすごい！」といった話もたまに聞きます。しかし、「詳細な引継ぎ書を作らないと休めない」という状態は、あまり現実的ではありません。

それに、細かく書きすぎることの弊害もある。手法にとらわれて非効率化したり、「ここに書かれていないケースはどうするのか？」という問い合わせが無限に発生したりする恐れもありますからね。

例えば「新規APIのエラー解消」というタスクを引き継ぐとします。日本的な手順書だと「Aのライブラリを使って、ここのクラスをこうリファクタリングして……」と具体的な実装手順まで指示してしまいがちです。

しかし、それでは引き継いだ人が新しい創造性を発揮できません。なので、「特定の条件下で発生する500エラーを解消する」「レスポンスタイムを〇〇ms以内に収める」という達成条件だけを定義します。

そうすれば、引き継いだ人は自身の経験やスキルを活かして、もっとシンプルでモダンな解決策を提案してくれるかもしれません。あえて「ざっくり」書くことは、相手の創造性を促し、結果的に仕事が早く済む可能性を高めることにもつながります。