金曜夕方の｢サクッと直せますよね?｣にどう答えるか…14年残業ゼロの社長が繰り出す"秀逸な返答フレーズ"
※本稿は、米村歩『「技術的には可能です」はなぜ伝わらないのか エンジニアのコミュニケーションの教科書』（KADOKAWA）の一部を再編集したものです。
■「技術的には可能ですが……」の真意
ITシステムやソフトウェア開発の現場において、エンジニアであれば誰もが一度は耳にし、あるいは自ら口にしたことがある有名なフレーズがあります。
それが「技術的には可能です」という言葉です。
エンジニアと関わりのある営業や企画、ディレクターなどの非エンジニア職にとっても、なじみ深い言葉でしょう。何か新しい機能の追加や仕様の変更を相談した際、エンジニアから「技術的には可能ですが……」と返ってくる。このとき、非エンジニアの多くは「お、できるんだな」とホッと胸を撫で下ろしてしまいます。
しかし、ここに大きな落とし穴があります。実は、この「技術的には可能です」という言葉の裏には、さまざまな意味が隠されているのです。
・技術的には可能です（でも自分の技術力では無理です）
・技術的には可能です（でもめちゃくちゃ時間かかるよ）
・技術的には可能です（でも作っても意味なくない？）
これらはほんの一例ですが、エンジニアの頭の中には必ずといっていいほど、声に出していない「カッコ書き」の条件が存在しています。これを知った非エンジニアは、「最初からカッコの中身も言うべきだ」と憤るかもしれません。ではなぜ、エンジニアは肝心な条件を隠し、この言葉を多用してしまうのでしょうか。
その背景には、過去の苦い経験から生み出された「自己防衛」の心理があります。
たとえば、顧客や営業から「こういうことできる？」と聞かれ、純粋に技術的な観点から「できますよ」と答えたとします。すると、「じゃあ明日までにやっておいて」と無茶なスケジュールを要求されたり、いざ蓋を開けてみたら問題山積みで期日に間に合わず、「あのときできるって言ったよね？」と理不尽に詰め寄られたりする……。
こうした苦い経験が積み重なると、エンジニアは不用意な断言を避けるようになります。相手との間に心理的なクッションを置き、自分の身を守るための便利なバリア、それが「技術的には可能です」の正体なのです。
■「サクッと直せますよね？」からの大炎上
この言葉が引き起こす「すれ違い」は、時にプロジェクト全体を巻き込む大炎上へと発展します。本書のマンガで描かれているエピソードを一部ご紹介します。
いかがでしたでしょうか。
「無理です」と言って場の空気を悪くしたくないエンジニアの弱木が、絞り出すように発したのが、「技術的には可能です」という一言でした。
そして週明けの月曜日。システムは期待通りに動かず、顧客から「可能だって言いましたよね？ まだ動かないんですけど」と詰められます。弱木は「い、いえ……技術的には可能なんですが、その時間と確認が……」と弁明しますが、後の祭り。エンジニアが正論を放ったつもりが、見事にすれ違い、現場は炎上してしまったのです。
■なぜ同じ「可能」でここまで食い違うのか
なぜこのような悲劇が起こるのでしょうか。それは、ひとつの「可能」という言葉が、それぞれの立場でまったく違う意味に解釈されているからです。
エンジニアにとっての「技術的には可能です」は、あくまで「技術の可否」についての返答です。追加工数や優先順位の入れ替え、納期や費用といった前提が整えば実装できる、という限定つきの意味に過ぎません。
しかし、その言葉が営業の耳に届いた瞬間、「やってもらえる約束」へと変換されます。さらに顧客の耳には、「月曜の朝までに完了する」という「契約上のYes」として着地してしまうのです。
根本的な原因は、立場によって「優先する軸」が異なることにあります。エンジニアは安全性や保守性といった「技術の軸」や「リスクの軸」で判断しますが、経営層や営業は、売上や投資対効果といった「価値の軸」や、納期の「時間の軸」を優先します。
「技術的には可能」という言葉は、技術やリスクの軸に立てば正しいですが、価値や時間の観点が度外視されているのです。
これらのねじれは、後になって残業や品質低下、手戻りといった形で一気に精算を迫ってきます。本書ではこれを「安請け合い時限爆弾」と呼んでいます。条件が欠落した「可能」は、爆発の起動スイッチなのです。
■二択の罠から抜け出す「条件付きYes」
では、エンジニアはどう答えればよかったのでしょうか。
「できますか？ できませんか？」と二択で迫られたとき、エンジニアは板挟みになります。即答すれば条件が欠落した約束になり、後で徹夜する羽目になります。
かといって「できません」と突っぱねれば、非協力的だとみなされ、営業や顧客との関係に角が立ちます。だからこそ「技術的には可能です」という玉虫色の逃げ道を選んでしまうのです。
このジレンマを打ち破るのが、「条件付きYes」という伝え方です。「条件付きYes」とは、YesともNoともつかない曖昧な返答を避け、先に端的に結論を述べたうえで、「Yes, if……（この条件が整えば可能）」や「No, unless……（この条件がなければ不可能）」と条件を明示する手法です。
先ほどのマンガの例で言えば、エンジニアは次のように答えるべきでした。「対応は可能ですが、テスト環境のデータが今日中に揃うことと、画面調整は後回しにすることが前提になります。その条件で合意いただけますか？」
このように、Yes自体は言いつつも、納期や品質、優先順位などの前提を明確にするのです。これが「条件付きYes」です。条件を明らかにしないまま曖昧に「はい」と答えてしまうと、後々の火種になります。逆に、守れる範囲を明らかにして合意すれば、お互いの信頼は少しずつ積み上がっていきます。
「技術的には可能です」と言いたくなった瞬間。それは言い訳に逃げるためではなく、どうすれば可能にできるか」「どんな条件ならYesになるか」に思考を変換する絶好のチャンスです。その言葉をただの防衛線にするのではなく、条件を探す入り口として活用してほしいと思います。
----------
米村 歩（よねむら・すすむ）
アクシア代表取締役社長
1979年埼玉県生まれ。青山学院大学卒業後、システム開発会社に入社。その後フリーランスの期間を経てアクシアを設立。設立当初、残業過多の勤務体制から、2012年を境に「残業ゼロ」を断行し現在も継続中。2017年には「ホワイト企業アワード」労働時間削減部門で大賞受賞。「エンジニアが幸せになれる会社とは？」をテーマに、IT企業経営に関する情報をSNSで発信している。著書に『完全残業ゼロの働き方改革』（プチ・レトル）がある。
----------
（アクシア代表取締役社長 米村 歩）
