Yesマン卒業宣言!──海外プロジェクトで学んだ断る力

はじまりは「No」が言えない自分から

僕が海外に来て最初にぶつかった壁は、英語力でも技術力でもなく――「断る力」のなさだった。
今だから笑えるけど、当時は本当に深刻だったんだ。

日本でエンジニアをやっていた頃、プロジェクトの依頼や追加タスクを断ることはほとんどなかった。
理由はシンプル。断ったら相手に迷惑をかけるんじゃないか、評価が下がるんじゃないか、嫌われるんじゃないか。そんな不安ばかりが頭をぐるぐる回っていた。
それに日本の職場って、「無理でもなんとかしてやる」ことが美徳みたいな空気があるじゃない?
だから「はい、わかりました!」が口癖になっていた。

そのままのマインドで海外プロジェクトに飛び込んだ僕。
職場は多国籍チームで、英語が母国語じゃない人も多い。C# WPFでのUI設計や機能実装がメイン業務だったんだけど、最初はそれどころじゃなかった。
ミーティングで依頼が来るたび、僕は反射的に「Yes」と答えていた。
英語で長く説明する自信もなかったし、断る理由をうまく言えない自分が恥ずかしかった。


「Yes」の連続が招いた地獄のスケジュール

ある日、プロジェクトマネージャーから追加仕様の話が来た。
「ユーザーから新しいUI機能の要望があったんだ。優先度は高くないけど、今のスプリントで入れられる?」
本当なら、「今は別のタスクで手一杯だし、優先度低いなら次のスプリントでやるべき」と言うべき場面だった。

でも僕は反射的に「Yes, I can do it.」と答えてしまった。
理由は簡単。英語で「今は無理」と伝えるより、「Yes」で終わらせた方が楽だったからだ。

その瞬間、僕のToDoリストは爆発した。
既に進行中のバグ修正、デザインレビュー、コードリファクタリング……そこにUI機能追加が重なった。
スプリントの残り日数はわずか5日。
作業時間は連日深夜にまで及び、土日もノートPCとにらめっこ。
海外に来てまで、ブラックな働き方をしている自分に気づいて情けなくなった。


文化の違いに愕然

さらに追い打ちをかけたのは、同僚たちの反応だ。
ある日、隣のデスク(正確にはZoomの隣の画面)でインド出身のエンジニアが、マネージャーにこう言っているのを聞いた。
「That’s not possible in this sprint. Let’s prioritize it next time.」
マネージャーは「ああ、OK。じゃあ次でやろう」とあっさり引き下がった。

僕は心の中で叫んだ。「え、それでいいの!?」
日本の感覚だと、「できません」は禁句に近い言葉だと思っていた。
でも海外では、スケジュールやリソースの都合で断るのは当たり前。
むしろ無理に引き受けて品質を落とす方が、チームへの迷惑になるという文化だった。


無意識に自分を追い込む癖

僕が「No」を言えなかったのは、単なる英語力の問題じゃない。
長年の「Yes」文化が骨の髄まで染みついていた。
そのせいで、

  • 無理なスケジュールでも「なんとかなる」と思ってしまう
  • 断ったら自分の評価が下がると思い込む
  • 相手に嫌われるのが怖い
    という、完全に自己防衛型の思考に支配されていた。

そしてその結果、自分の時間、体力、精神力を全部すり減らすことになった。


小さなきっかけ

転機はある1on1ミーティングで訪れた。
マネージャーに「最近、疲れてるみたいだけど大丈夫?」と聞かれたとき、つい本音が漏れた。
「正直、タスクが多すぎて余裕がないです…」
するとマネージャーは驚いた顔で言った。
「なんで断わらなかったの? 無理って言ってくれたら調整できたのに。」

その瞬間、僕はハッとした。
「あ、断っていいんだ…」
まるで肩に乗っていた重りがひとつ外れたような感覚だった。

この出来事が、「No」を言う練習を始めるきっかけになった。
でも、ここから実際に“言えるようになる”までは、まだまだ試行錯誤の連続だった――。

断る力を鍛えるための試行錯誤

あの日、マネージャーに「なんで断わらなかったの?」と言われたときの衝撃は、今でもはっきり覚えている。
その一言は、僕にとって“文化の許可証”みたいなものだった。
日本では滅多にもらえない「断っていいよ」というサイン。
だけど、頭では理解しても、長年の習慣はそう簡単には変わらない。


断るのが怖い3つの理由を分解してみた

まず、自分がなぜ「No」を言えないのかを徹底的に分析した。
出てきたのは、この3つの恐怖だった。

  1. 評価が下がるかもしれない恐怖
    「タスクを断ったら“やる気がない”と思われるんじゃないか」という不安。
    特に海外では即戦力として採用されたわけで、期待を裏切るのが怖かった。
  2. 相手を失望させる恐怖
    相手が「頼りにならないやつだ」と思うんじゃないか。
    これは完全に日本的な“迷惑をかけたくない”マインドの延長。
  3. 英語で説明できない恐怖
    「今はできない理由」をスムーズに英語で説明できる自信がなかった。
    その場で言葉が詰まって沈黙になるぐらいなら、とりあえず“Yes”と言ってしまう。

この3つを紙に書き出して、「じゃあどうやって潰すか」を考えることにした。


スモールステップ戦略

いきなり重要な会議で「No」と言うのは、さすがにハードルが高い。
だから僕は、小さな断りから練習することにした。

1. チャットでの断りから始める

メールやTeamsチャットなら、時間をかけて文章を考えられる。
例えばこんなふうに書いた。

“I’d like to help, but I’m already committed to Task A. Can we schedule this for the next sprint?”
(手伝いたいのですが、すでにTask Aに取り組んでいます。次のスプリントに回せますか?)

ポイントは、ただ「No」と言うのではなく、代替案を添えること。
海外の職場では、この“代替案セット”が非常に好印象になる。

2. 小さなタスクで断る

影響が少ない案件や期限が緩いタスクで練習した。
たとえば、資料レビューの依頼に対してこう返す。

“I can’t do it today, but I can look at it tomorrow.”

これなら相手も「断られた」というより、「スケジュール調整してくれた」と受け取ってくれる。


「No」は英語ではポジティブに聞こえる場合がある

驚いたのは、英語で断っても、日本語ほど“冷たく”聞こえないことだ。
日本語の「できません」はバッサリ感が強いけど、英語のビジネス会話は柔らかい言い回しが多い。
例えば、

  • “Not this time.”(今回は無理です)
  • “I wish I could, but…”(できたらいいんだけど…)
  • “I’m afraid I can’t.”(申し訳ないけどできません)

こういう表現を覚えておくだけで、心理的ハードルがぐっと下がった。


最初の実戦

初めてミーティングで「No」を言ったのは、ある週のスプリントプランニングだった。
マネージャーが言った。
「新しい画面デザインを次のスプリントで作れる?」

いつもの僕なら「Yes」と即答していた。
でもその日は深呼吸して、こう言った。

“Given my current tasks, I don’t think I can deliver it within the sprint without compromising quality.”
(今のタスク状況だと、品質を落とさずにスプリント内で納品するのは難しいです)

一瞬、会議室(Zoom上)が静かになった。
心臓がバクバクして、「やっちゃったか…?」と思ったけど、マネージャーはあっさりこう返した。

“Fair enough. Let’s schedule it for the next sprint.”

その瞬間、胸の中の何かがほどけた。
「あ、これでいいんだ」
しかもチームメイトの一人が、チャットで“Good call”と送ってくれた。
むしろ尊敬されたような感覚すらあった。


断ることは「守ること」

この経験から学んだのは、断ることはただの拒否じゃないということ。

  • 自分の時間を守る
  • チーム全体の品質を守る
  • 無理な約束をしないことで信頼を守る

つまり「No」は自己防衛ではなく、チーム貢献の一部なんだ。

それに、断った後の時間の使い方も変わった。
無理なタスクが減った分、既存タスクの品質やレビューにもっと集中できた。
その結果、コードレビューでの指摘が減り、納品のバグ数も減った。
つまり“断ること”が、自分の評価をむしろ上げたわけだ。


周囲の反応の変化

面白いことに、僕が「No」を言うようになってから、周りの僕への頼み方も変わった。
前は「これできる?」とストレートに聞かれていたのが、
「今忙しいと思うけど、これお願いできそう?」
「もし今のタスク終わったら、これ見てくれる?」
と、相手が僕の状況を考慮してくれるようになった。

そして気づいた。
「No」を言える人は、Yesにも重みが出る
なんでもYesの人より、必要なときだけYesと言う人の方が信頼される。


次のステップへ

もちろん、まだ全てが順風満帆というわけじゃない。
特にクライアント相手に「No」を言う場面は、今でも緊張する。
でも、そのために僕は「事実+理由+代替案」という3ステップのフレームを作った。

例:

  1. 事実:I have 3 high-priority tasks this sprint.
  2. 理由:If I take on this as well, the quality might drop.
  3. 代替案:Can we schedule it for the next sprint?

この型があるだけで、「No」が怖くなくなった。

クライアントとの対決

「No」を言えるようになったとはいえ、相手が社内メンバーとクライアントでは重みがまったく違う。
社内なら、お互いの状況や制約をある程度理解しているけど、クライアントはそうじゃない。
相手はお金を払っている側だし、要求の優先度は基本的に“自分たちが一番”という前提で話してくる。

そしてその日、僕にとって最大の試練がやってきた。


追加仕様の嵐

プロジェクトは最終フェーズに差しかかり、C# WPFで作っていた業務アプリも大詰め。
テスト環境でのデバッグとUI調整に集中していたある日、クライアントからメールが届いた。

件名はシンプルに「Urgent Feature Request(緊急の機能追加依頼)」。
嫌な予感しかしない。

中身を開くと、要約すればこうだった。

  • ユーザーからのフィードバックで新しいフィルター機能を追加したい
  • 来週の納品までに実装してほしい
  • 仕様はざっくりだが、動く状態を見せてから詳細を詰めたい

完全に“スコープ爆弾”だ。
このタイミングで新機能なんて、テスト工程を圧迫するのは目に見えている。
本音は「今じゃないでしょ!」だったけど、以前の僕なら条件反射で“Yes”と言っていただろう。


社内での作戦会議

すぐにプロジェクトマネージャー(PM)と開発リーダーに連絡して、状況を共有した。
僕:「この追加は、スケジュール的にかなり厳しいと思います」
PM:「そうだね。でもクライアントは“ユーザーからの緊急要望”と言っている。どう返す?」

このとき、僕は自分の中で決めていた**「Noフレーム」**を思い出した。

  1. 事実
  2. 理由
  3. 代替案

これをベースに、クライアント向けの説明文を作ることにした。


メールでの第一防衛線

まずはメールで状況を整理して送った。

事実:The current sprint is fully allocated to testing and fixing high-priority bugs.
理由:If we add this feature now, it may delay the delivery date and compromise the quality of the release.
代替案:We suggest implementing this feature in the next release cycle, scheduled for two weeks after the current delivery.

日本語にすると、

現在のスプリントはテストと高優先度バグ修正で全てのリソースが割り当てられています。
この機能を今追加すると納期が遅れ、リリース品質を損なう可能性があります。
そこで、この機能は現行納品の2週間後の次回リリースに実装することを提案します。


クライアントからの反応

返事は意外と早く来た。
冒頭から「We understand your concern, but…(状況は理解しますが…)」と書かれていて、予想通り押してくる構え。

  • ユーザーの評価に関わる
  • 競合との差別化になる
  • 今やらないと機会損失になる

こちらの理屈は理解しつつも、「やっぱりやってほしい」というメッセージだった。


ミーティングでの直接交渉

結局、緊急ミーティングが設定された。
参加者はクライアントのPM、うちのPM、そして僕。
Zoomの画面越しに、相手の真剣な表情が映る。

クライアントPM:「この機能、どうしても今回入れられないですか?」
僕:「Technically, it’s possible. But it will significantly increase the risk of bugs in other parts of the system.」
(技術的には可能ですが、他の部分へのバグリスクが大きくなります)

ここで、あえて**“できません”ではなく、“できるけどリスクがある”**という言い方を選んだ。
完全拒否ではなく、リスクベースで話すことで相手に現実的な判断を促すためだ。

続けて、テスト工程のガントチャートとリソース割当表を画面共有しながら説明した。
「このタイミングで新機能を入れると、テスト項目が30%増えます。その分、既存機能のテスト時間が削られます」


相手を納得させた一言

議論は20分ほど続いたが、最後に僕がこう言ったとき、空気が変わった。

“If we rush this feature now and it causes issues, the user experience might actually get worse. I’d rather deliver a stable product first.”
(今この機能を急いで入れて不具合が出たら、ユーザー体験はむしろ悪くなります。まずは安定した製品を納品したいです)

クライアントのPMは少し考えてから、「I see your point. Let’s go with your suggestion.」
(言いたいことはわかりました。あなたの提案でいきましょう)と答えた。

その瞬間、心の中でガッツポーズをした。


「No」を言った後の信頼

驚いたのは、その後の関係性だ。
この件以降、クライアントは新しい要望を出すとき、必ず優先度と期限を明確にしてくれるようになった。
「これは今すぐ必要」「これは次のリリースでOK」と、最初から線引きができていた。

つまり、“断った”ことで逆に信頼が増したのだ。
あのとき安易に“Yes”を選んでいたら、納期遅延や品質低下で信頼を失っていたかもしれない。


海外での交渉の鉄則

今回の経験から、僕が学んだ海外での「No」の言い方の鉄則はこうだ。

  1. 事実を数字で示す
    感覚や主観ではなく、リソースや時間の具体的な数字を出すと説得力が増す。
  2. 完全拒否ではなく条件付き拒否にする
    “Never”ではなく、“Not now”や“After X weeks”にする。
  3. 相手のゴールを守る視点を見せる
    自分の都合ではなく、「ユーザー体験」や「品質」を守るための断りだと伝える。

断る力が変えた僕の働き方と人生観

クライアントに初めて「No」を言い切ったあの日から、僕の働き方は明らかに変わった。
以前の僕は、仕事の依頼が来た瞬間に“Yes”と反射的に答えてしまい、自分のスケジュールをどんどん圧迫していた。
結果的に、睡眠時間や休日まで削られ、納品の瞬間は達成感よりも疲労感のほうが強かった。

でも「No」を言えるようになってからは、不思議と余裕が生まれた。
いや、単に時間が空いたからじゃない。自分がやるべき仕事を、自分で選べるようになったことが大きい。


1. プロジェクトの見え方が変わった

以前は「降ってくるタスクをこなす」だけだったけど、今は全体の優先度やスケジュールを見ながら、自分がどこに時間を投資すべきかを考えるようになった。
「断る」という行為は、ただの拒否じゃなくて、タスクの選別と集中でもある。

例えば、C# WPFの画面改修タスクが2つ並んでいたら、どちらがユーザー体験に直結するのか、どちらが将来的な保守負担を減らすのかを考えて優先する。
そうすることで、プロジェクト全体の成果に貢献しつつ、自分の評価も上がっていった。


2. 精神的な消耗が減った

昔の僕は、「Yes」を言った瞬間からストレスが始まっていた。
「どうやってこのスケジュールに詰め込もう…」
「間に合わなかったらどうしよう…」
頭の中は常にそのことでいっぱいだった。

でも今は、無理な案件は事前に断っているから、納期ギリギリのプレッシャーが大幅に減った。
結果的に、夜中までコードを書くこともなくなり、休日にPCを開くことも減った。

その分、仕事以外の時間をちゃんと趣味や家族に使えるようになった。
海外に住んでいるのに、仕事ばかりでローカルの文化を楽しめなかった昔が、今では本当に惜しいと思う。


3. チーム内の立ち位置が変わった

「No」を言えるようになってから、チーム内での僕のポジションも変わった。
以前は「頼めばなんでもやってくれる人」だったけど、今は「優先度を見極めて動く人」として認識されている。

その結果、僕が「Yes」と言ったときの信頼度が上がった。
同僚やPMからも「君がそう言うなら、本当にやれるんだね」という信用がつく。
これは日本の職場でも通用するけど、海外だとより顕著だと感じる。


4. 「No」はキャリアを守る武器だった

最初は怖くてたまらなかった「No」だけど、今ではキャリアを守る大切な武器だと確信している。
なぜなら、海外の職場では**“やれること”よりも“やらないこと”の判断**が評価されるからだ。

  • やらないことで、品質を守る
  • やらないことで、納期を守る
  • やらないことで、チームの士気を守る

これは、ただがむしゃらに残業して「頑張ったね」と言われる日本的な評価とは真逆の価値観だ。


5. これから海外を目指すエンジニアへのアドバイス

僕の経験から、これから海外で働くエンジニアに伝えたいのはこの3つだ。

(1) 「No」を言う練習は日本にいるうちからやっておく

海外に来てから急にやろうとしても、長年の習慣はなかなか変わらない。
社内チャットやメールで、小さな断りから始めるといい。

(2) 断るときは「事実+理由+代替案」の型を使う

  • 事実:今どんな作業をしているか、数字やスケジュールで説明
  • 理由:なぜ今はできないのか、相手のゴールと結びつけて説明
  • 代替案:いつならできるのか、どんな方法なら可能かを提案

(3) 「No」は自分のためだけじゃなくチームのため

断ることで、自分もチームも長期的にパフォーマンスを維持できる。
海外ではこれは“責任感のある行動”として評価される。


「Yesマン」だった僕のその後

振り返ってみると、「Yesしか言えなかった頃の僕」は、表面的には“頑張っているエンジニア”だったけど、内面では常に消耗していた。
あのままだったら、確実に燃え尽きていたと思う。

今は、仕事を引き受けるかどうかを自分でコントロールできることで、むしろ成果が出やすくなった。
そして何より、「No」を言えるようになったことで、自分の時間とエネルギーを大切にできるようになった。


最後に

海外で働くというのは、ただ英語を使って仕事をすることじゃない。
価値観や働き方の違いを受け入れ、自分のやり方をアップデートしていくことだと思う。

僕にとって「No」を言えるようになったことは、その最初の大きな一歩だった。
もし今、「断ったら嫌われるかも」と悩んでいる人がいたら、こう言いたい。

「No」を言うことは、あなたの責任感を示すサインだ。
そして、それは海外でもっとも信頼されるスキルの一つだ。

コメント

タイトルとURLをコピーしました