なぜエンジニアは「できない」と言えないのか? 発注失敗を招く「優しさ」と「諦め」の構造

なぜエンジニアは「できない」と言えないのか? 発注失敗を招く「優しさ」と「諦め」の構造

システム開発を依頼したら、期待と全く違うものが納品された。「できます」と言ったはずなのに、話が噛み合わずプロジェクトが炎上してしまった……それは、あなたとエンジニアとの間に横たわる、深刻なコミュニケーション・ロスが原因かもしれません。本記事では、住田賢司氏の著書『STOP!迷走DX デキる上司のためのITリテラシー改革』(幻冬舎メディアコンサルティング)より一部を抜粋・再編集して、なぜエンジニアは「できない」と言えないのか、その心理的背景とコミュニケーション・ロスを防ぐための上司のITリテラシーについて解説します。

ゴールドオンライン新書最新刊、Amazonにて好評発売中! 

『司法書士が全部教える 「一人一法人」時代の会社の作り方【基本編】』
加陽麻里布(著)+ゴールドオンライン (編集)

『富裕層が知っておきたい世界の税制【カリブ海、欧州編】』
矢内一好 (著)+ゴールドオンライン (編集)

『司法書士が全部教える 「一人一法人」時代の会社の作り方【実践編】』
加陽麻里布(著)+ゴールドオンライン (編集)

シリーズ既刊本も好評発売中 → 紹介ページはコチラ!

「できない」とは言えない空気

もう1つの側面として、「これはできません」と言うと「プロなのに?」とガッカリされてしまうのではないかという恐れや、「ぜひ実現してあげたい」という思いとの葛藤があります。システムのことを知らない発注者の中には、エンジニアが面食らうような非現実的な要望を言ってくる人もいます。「システムは何でもできる」という過大な期待から、悪気なく無理難題を言ってくるのです。

 

例えば、非エンジニアの人は「機能が多いほどシステムはできることが増えて便利になる」と考えがちです。それで、「この機能も欲しい、これも付けられますか?」と要望を出してきます。エンジニアにしてみると、「のこぎりとハサミと金づちを合体させて」と言っているようなものです。一石三鳥のように見えて、実際に使ってみると3つともまともに使えないことが分かっているので、エンジニアはやりたがりません。しかし、実際に合体したものを使ってみないと、非エンジニアの人はそのことに気付けないのです。結局、システムを一度つくってから「やっぱりこの機能は要らないね。システムを元に戻して」というふうになるパターンです。

 

非現実的な要望を言われたとき、無理なら無理だと言ってほしいと思うでしょう。最初はエンジニアも「いや、それは理論的に難しいです」などと言って要望を避けようとするのです。しかし、発注者からは「え、どうして?」ときょとんとされてしまいます。理由を説明しても伝わらなかったり、ITに関する用語の理解を間違っていたりで、結果として「よく分からない」と言われてしまいます。この時点で、最初に「できない」とエンジニアが言ったことは十中八九、忘れ去られています。

 

場合によっては、会議に営業担当が同席していることがあります。すると、営業担当は仕事を取りたいので、エンジニアに「できないなんて言わないで。工夫次第でできますよね?」と言ってきたりします。 エンジニアは言葉を濁すのですが、それを見ている発注者は「できないと言わないってことは、やっぱりできる方法があるのね!」といいように解釈してしまいがちです。

 

やがて会議も長くなってくると、みんな結論を急ぎたい心理が働き、発注者から「それで結局できるの? できないの?」と二択を迫られることになります。こうなると、その場の雰囲気やエンジニアとしてのプライドや優しさなどがない交ぜになり、多くのエンジニアは「(技術的には)できます」と答えざるを得ません。「できません」や「やりたくない」という本音はのみ込んでしまいます。

 

エンジニアの頭の中は「これ以上、説明しても分かってもらえない」という諦めや「とりあえずこの場を終わらせたい」という思いでいっぱいです。

 

こうして無理難題を受け入れてしまったエンジニアはどうするかというと、「形だけできたように見せてもこの発注者なら気付かない。なんとかこの難題をできた”ことにしよう」と考えて、表面的な体裁だけ整えて納品してしまうことになります。あるいは、途中までやりかけて、このプロジェクトから離脱してしまいます。

 

今回の事例も今話したような経緯があったのかもしれないと想像します。「1クリックにはできません」と言えればよかったかもしれませんが、いろいろなしがらみから、それができない場面が現実として多いのです。

コミュニケーションをサボらない

こうしたエンジニア側の心理を踏まえたうえで改めて選択肢を見てみると、選択肢Aは根本的な解決にならないことが分かります。エンジニアを代えたところで、次に担当になるエンジニアも似たり寄ったりかもしれません。

 

選択肢Bはエンジニアとのコミュニケーションを変えようとしている点で、より解決策に近いです。担当エンジニアのコミュニケーションの特性を理解して、伝え方の工夫ができればいいと思います。

 

コミュニケーションは相互の歩み寄りが大事ですから、発注者側が伝え方を配慮するだけでなく、エンジニア側もキレたり対話から逃げたりせずにコミュニケーションスキルを高めていく必要があります。

 

大事なのは、お互いに「これくらい言わなくても分かる」「どうせ言っても分からない」という甘えを取り去り、理解を合わせるためにIT用語における定義の共通化を進め、日頃からのコミュニケーションを欠かさず取り続けることです。

 

【関連記事】

■税務調査官「出身はどちらですか?」の真意…税務調査で“やり手の調査官”が聞いてくる「3つの質問」【税理士が解説】

 

■親が「総額3,000万円」を子・孫の口座にこっそり貯金…家族も知らないのに「税務署」には“バレる”ワケ【税理士が解説】

 

「銀行員の助言どおり、祖母から年100万円ずつ生前贈与を受けました」→税務調査官「これは贈与になりません」…否認されないための4つのポイント【税理士が解説】

 

STOP!迷走DX デキる上司のためのITリテラシー改革

STOP!迷走DX デキる上司のためのITリテラシー改革

住田 賢司

幻冬舎メディアコンサルティング

あなたの会社のDX――担当者に任せっぱなしになっていませんか? DXプロジェクトを監督すべき立場の経営者や部門責任者に向けた、正しい決裁をするために必要なIT知識と判断力の重要性をまとめた一冊! DXに悩む経営層・…

カインドネスシリーズを展開するハウスリンクホームの「資料請求」詳細はこちらです
川柳コンテストの詳細はコチラです アパート経営オンラインはこちらです。 富裕層のためのセミナー情報、詳細はこちらです 富裕層のための会員組織「カメハメハ倶楽部」の詳細はこちらです 不動産小口化商品の情報サイト「不動産小口化商品ナビ」はこちらです 特設サイト「社長・院長のためのDXナビ」はこちらです オリックス銀行が展開する不動産投資情報サイト「manabu不動産投資」はこちらです 一人でも多くの読者に学びの場を提供する情報サイト「話題の本.com」はこちらです THE GOLD ONLINEへの広告掲載について、詳細はこちらです

人気記事ランキング

  • デイリー
  • 週間
  • 月間

メルマガ会員登録者の
ご案内

メルマガ会員限定記事をお読みいただける他、新着記事の一覧をメールで配信。カメハメハ倶楽部主催の各種セミナー案内等、知的武装をし、行動するための情報を厳選してお届けします。

メルマガ登録