｢なるはやで｣を使った先に過酷な残業が待ち受ける…職場で使用厳禁の"危険フレーズ"と言い換え例

部署間のすれ違いをなくすには何をすればいいか。14年間残業ゼロを徹底するアクシア代表の米村歩さんは「仕事の現場で使われる『なるはやでお願い』といった言葉は、人によって受け取り方が大きく異なるため、認識がズレ、後々の手戻りや炎上を引き起こす。こうした曖昧さを排除するためには、タスクの『期限』と『状態』を明確にする必要がある」という――。
※本稿は、米村歩『「技術的には可能です」はなぜ伝わらないのか エンジニアのコミュニケーションの教科書』（KADOKAWA）の一部を再編集したものです。
■ 条件のない「可能」は約束ではない
先の記事で、エンジニアが口にする「技術的には可能です」という言葉が、実は「条件付きであればできる」という限定的な意味であることを解説しました。
しかし、現場ではこの言葉が「やってもらえる約束」として一人歩きし、プロジェクトを炎上させる原因になっています。
本書でも、金曜の夕方に顧客から「月曜朝までにサクッと直せますよね？」と無茶な依頼を受けた営業が、「大丈夫です！」と安請け合いしてしまい、後に炎上するエピソードがマンガで描かれています。一部を紹介します。
■営業と開発の溝を深める「情報の非対称性」
なぜ、こんなにも営業と開発はすれ違うのでしょうか。その根本原因のひとつが「情報の非対称性」です。
営業は顧客と直接対話し、どんな背景や政治的事情があるのかという「一次情報」を多く持っています。
しかし、開発現場に伝わるのはその一部に過ぎず、「なぜその機能が今必要なのか」という重要な説明が抜け落ちることもしばしばです。逆に開発エンジニアは、実装の難易度や技術的リスクをよく知っています。
しかし、それを営業が十分に理解する機会は少なく、顧客に説明できる言葉に変換されないこともあります。営業は「顧客の声を無視するな」と言い、開発は「技術的な問題を無視するな」と言います。
どちらも自分の立場で主張するだけで、相手の声に耳を傾けず、言葉のキャッチボールが成立していない状態です。この「見えている情報の違い」が、両者の溝を決定的に深くしてしまいます。
■互いのリスペクト不足が不信と対立を増幅
情報の非対称性に加えて、現場の空気を決定的に悪化させるのが「リスペクトの欠如」です。営業から見れば、「すぐに無理と言う開発」は、顧客に寄り添わず協力的でないように映ります。
常に顧客の矢面に立っている営業としては、顧客の要望を全部突き返していてはビジネスが成り立たないことを理解しています。
開発の事情を知らないがゆえに、「こんなの簡単でしょ？　何でできないの？」といった発言をしてしまうこともあります。
一方、開発エンジニアから見れば、「無茶な条件の仕事を取ってくる営業」はとても理不尽に見えます。現場の意見を聞くこともなく顧客と勝手に約束してきて、その責任と負担だけを開発に押し付ける営業には、怒りの感情が湧いてくることもあるでしょう。顧客の矢面に立つ営業の立場を理解せず、「そんなの無理ですよ」と簡単に突っぱねてしまいます。
お互いの立場を理解せず、相手を辟易する気持ちが増幅されていく。ビジネスの現場で「営業と開発は仲が悪い」と言われやすい背景には、相手の立場を想像し、お互いをリスペクトする姿勢が欠けている状態が根底にあるのです。
■静かに起動する「安請け合い時限爆弾」
条件が曖昧なまな、営業が「安請け合い」したプロジェクトは、「時限爆弾」のようなものです。この爆弾の恐ろしいところは、起動音も出さずに、一定の時間差をおいてから多大な被害をもたらす点です。
表面上の言葉は「できます」「頑張ります」と前向きで協力的でも、納期・スコープ（範囲）・予算といった明確な合意が欠如したまま進めば、その代償は必ずどこかで清算されなければなりません。
そして、その清算の多くは、現場のエンジニアの過酷な残業や、システムの品質低下という形で静かに行われます。爆発の音がしないため、営業も顧客も「プロジェクトは順調に前に進んでいる」と錯覚してしまいますが、開発現場の疲弊は確実に蓄積されているのです。
■「曖昧さ」を徹底的に排除する
では、この「安請け合い時限爆弾」の起動を防ぐためにはどうすればよいのでしょうか。その確実な解決策は、コミュニケーションから「曖昧さを排除する」ことです。
開発現場には、「なるはやでお願い」「良い感じで仕上げて」「しっかりテストして」といった言葉があふれています。しかし、これらは解釈が人によってバラバラになる「情報ゼロ」に等しい危険なフレーズです。
例えば、「なるはや」が今日中なのか今週中なのか、「しっかり」が単体テストなのか結合テストまで含むのか、人によって受け取り方は大きく異なります。この認識のズレが、後々の手戻りや炎上を引き起こします。
こうした曖昧さを排除するためには、タスクの「期限」と「状態」を明確にする必要があります。期限については「なるはや」ではなく「金曜の18時までに」、状態については「良い感じで」ではなく「レスポンスを1秒以内に」「テストを全件実行して」と、個人の解釈の余地が生じない具体的な条件で定義するのです。
もし、営業や顧客から状態が曖昧なまま「週明けまでに対応お願いできる？」と要求されたら、エンジニアは決して安請け合いしてはいけません。
自ら「対応とはどの状態までですか？　形だけ動けばいいですか？　テストまで含めますか？」と質問をし、グレーな部分を明確化しましょう。
曖昧な言葉をそのまま流せば、必ず後で修正や残業という重いコストを払うことになります。逆に、最初に条件を具体化し、認識のズレをなくしておけば、その後の仕事は驚くほどスムーズに進みます。
曖昧な「技術的には可能です」に逃げるのではなく、互いの前提を言葉にして明確な合意を作ること。それこそが、プロジェクトを時限爆弾から救う第一歩なのです。

----------

米村 歩（よねむら・すすむ）

アクシア代表取締役社長

1979年埼玉県生まれ。青山学院大学卒業後、システム開発会社に入社。その後フリーランスの期間を経てアクシアを設立。設立当初、残業過多の勤務体制から、2012年を境に「残業ゼロ」を断行し現在も継続中。2017年には「ホワイト企業アワード」労働時間削減部門で大賞受賞。「エンジニアが幸せになれる会社とは？」をテーマに、IT企業経営に関する情報をSNSで発信している。著書に『完全残業ゼロの働き方改革』（プチ・レトル）がある。

----------

（アクシア代表取締役社長 米村 歩）