NOと言えないSEへ。20数年の現場経験で学んだ「無理」を伝える技術

2026年1月13日

「これ、明日までにやっといて」「仕様変更だけど、納期はそのままでお願い」

IT現場で、こうした無理な要求に直面したことがないエンジニアはいないでしょう。そして、多くの真面目なエンジニアほど、「自分が頑張ればなんとかなる」「ここで断ったら無能だと思われる」と考え、無理な要求を飲み込んでしまいます。

しかし、20数年間この業界で戦ってきた私から言わせれば、リソースを無視した「YES」は、自分自身だけでなく、プロジェクト全体を壊す「バグ」のようなものです。

今日は、私が数多くの炎上案件から学んだ、角を立てずに、かつ確実に自分とチームを守るための「断り方の技術」を共有します。

１．なぜエンジニアは「無理」と言えないのか

エンジニアが断れない理由は、その経験値によっていくつかのフェーズに分かれます。エンジニアが断れない理由は、単なる性格の問題だけではありません。

若手・中堅：知識不足と不安
- 「どのくらい大変か」の判断がつかず、断る根拠が持てない。
- 経験が浅いため、「断る＝やる気がない、能力が低い」と見なされることを極端に恐れてしまう。
- 【私の場合】
  - 私は元々、学歴も低く、大学には出ていますがレベルのかなり低い大学です。そのため、若手のころ、自分の能力には極端に自信がなく、断ることで、こいつ使えないと思われるのを無意識に怖がっていた節があります。
  - 加えて、努力すればなんとかなるというか、なんとかしなければならないと思っていたため、できないことでも一旦受けてしまう傾向にありました。
  - 結果的にどのくらい大変かわかっていないで受けてしまうので、後でトラブルになることも多々あった記憶があります。
ベテラン：完成図が見えてしまうがゆえの誤解
- 経験豊富なエンジニアほど、頭の中で「こうすれば動く」という最短経路の設計図（ハッピーパス）が瞬時に描けてしまいます。
- その結果、「技術的に可能（Possible）」であることを、「現実的に可能（Feasible）」であると錯覚し、リソース度外視で引き受けてしまうのです。
- 【私の場合】
  - 上記に書いたように、私も知っている技術でなんとかなるので、この現場でも大丈夫と思い込み、とりあえずで受けてしまうことがありました。
  - それでできたこともあるので、その成功体験が断るということをさせなうということもあります。ちゃんと周りのその職場での技術を知っているメンバーに相談しておけばよかったと今では思います。
  - メンバーに相談しなかったのは、自分の経験を過信していたことと、そんな簡単なことを聞いてはいけないのでは？という強さと自分のプライドがあったのだと思います。
共通：
- 真面目すぎる責任感
  - 「自分がなんとかしなければ」というプロ意識が、限界を超えた仕事を引き受けてしまう原因になります。
- 評価への不安
  - 「断る＝能力不足」という誤った図式が頭にあり、評価が下がることを恐れてしまいます。
- 【私の場合】
  - 受けてしまった以上は最後までやらないとという無駄なプロ意識はあったと思います。能力に自信がなかったことも影響して、このくらいは周りの人はできて当たり前のことだという思い込みもありました。
  - 結果的に周りができて自分だけができないということを恐れて、全部受けていたのだと思います。

しかし、エンジニアリングの本質は「気合」ではなく「予測可能性」です。不確実な「YES」は、プロとしての誠実さに欠ける行為だと再定義しましょう。

２．「気合」はエンジニアリングではない

エンジニアの現場では、しばしば「最後は気合でなんとかする」という精神論が美徳のように語られます。しかし、20数年の経験を経て私が確信しているのは、「気合」はエンジニアリングではないということです。

本来、エンジニアリングとは「予測可能な結果」を導き出すための技術です。「どれだけのリソースがあれば、どの程度の品質のものが、いつまでに完成するか」を計算し、制御することこそが私たちの仕事の本質です。

それに対して「気合」は、以下のような致命的な欠陥を持っています。

再現性がない
- 今日は徹夜できても、明日も同じパフォーマンスが出せる保証はありません。
- 【私の場合】
  - 連日の徹夜をこなせた時期もありますが、パフォーマンスが出せるわけではありませんでした。
  - 当たり前ですが、１日目より２日目、２日目より３日目とパフォーマンスは下がっていき、設計書の誤字が増え、通常時では漏らすことがない処理が抜けてしまったりと明らかにミスが増え、品質を下げた上に手戻りが多くなったことで余計に作業時間が増えてしまった経験があります。終わらせればいいというものではないのを痛感した経験です。
不確実性を隠蔽する
- 本来アラートを上げるべき設計ミスやリソース不足を「根性」で埋めてしまうと、根本的な問題が見えなくなります。
- 【私の場合】
  - とりあえず終わらせることを至上としてしまったため、そもそもの設計ミスをコーディングで誤魔化すことも多くなったことがあります。
  - リソース不足でやりきれないとわかっていることも、テストケースを減らすという蛮行に及んでなんとか終わらせたこともありました。品質を守るためのテストを自ら削る。それはもうエンジニアリングではなく、ただのギャンブルでした。
負の連鎖を生む
- 誰かが気合で解決してしまうと、周囲や上司は「次も同じ無理ができる」と誤解し、さらなる無理難題が常態化します。
- 【私の場合】
  - 無理して終わらせて、それで大きな問題にならなかった場合、外から見るとそれができるのだと判断されてしまいます。なんとか乗り切れたのだから、次もいけるよね！と判断されて、ひたすら辛い思いをし続ける現場にいたこともありました。
  - その結果、メンバーが限界を迎えて、離任ということになり、プロジェクトが破綻していくというのを目の当たりにしたこともありました。そもそも、根性でどうにかできるのにも、限界があるということを知った事例でした。

気合で乗り切った後に残ったのは、達成感ではなく、壊れたプロジェクトと疲弊した仲間だけでした。

リソースの限界を無視して突き進むのは、燃料計が空のままフルスロットルで走るようなものです。プロとして「これ以上はシステムの安定稼働（あるいはプロジェクトの完遂）が保証できない」という境界線を明確に引くこと。

それこそが、真の意味でのエンジニアリングだと私は考えます。

３．角を立てない「NO」の3ステップ

無理な要求が来たとき、いきなり「無理です」と突っぱねるのは得策ではありません。以下の3ステップで交渉を進めてみてください。

STEP

まずは「受容」し、事実を確認する

いきなり否定せず、まずは相手の要望を正確にヒアリングします。

「なるほど、〇〇という機能を、明日までに追加したいというご要望ですね。背景は理解しました」まずは相手の「やりたいこと」を100%受け止めるポーズを見せることで、敵対関係になるのを防ぎます。

ただ、できないことをできます！と受けるのとは違います。受け入れた上で、その場で次のステップのインパクトがイメージできなければ、検討しますと持ち帰りましょう。

過去、私はできないものはできない！といきなり否定するということを徹底的にやった時期があります。今考えれば若かったというか幼かったなと思いますが、その現場に対して不満が限界に達しており、依頼されること全てが無理難題だと勘違いしていたと今は思います。

そうではなく、一旦受け止めた後にできる、できないの判断をして、その結果を伝える方ができない場合でもいきなり否定するより何倍も印象がよかったと思います。

STEP

「インパクト」を可視化する

次に、その要求を飲んだ場合に起こる「副作用」を論理的に示します。

「現在のリソースでその機能を追加すると、テスト工程が○時間不足し、全体のバグ混入率が○%上がるリスクがあります」「今こちらに着手すると、優先度の高いプロジェクトBの納期が○日遅れますが、よろしいでしょうか？」感情ではなく、数値やスケジュール、品質への影響という「ファクト」で会話をするのがコツです。

これは単にできもしないことをできると言って、後で問題を起こすより、要求した方からしても建設的です。説得力を増すように数字でも答えるとより効果的です。

STEP

「代替案（トレードオフ）」を提示する

単に断るのではなく、相手に選択肢を渡します。

「明日までは物理的に不可能です。しかし、機能を絞って最小構成にするなら、明後日の午前中にはお出しできます」「今回の追加機能を優先する代わりに、来週予定していた〇〇のリリースを1週間後ろ倒しにしませんか？」「NO」で終わらせず、「これならできます」という「条件付きYES」を提示することで、建設的な協議に持ち込めます。

これは単に自分の方だけで責任を追うのを防ぐ効果もあります。忘れがちですが、依頼をしてきた方にも一定の責任があります。その点を意識して、代替案を出して、相手にも依頼した責任があることを意識させることも重要で、一緒に解決していくという姿勢が信頼になる場合もあります。