デキる人ほど、喋る。「エンジニア＝会話をしない」というイメージにちょっと物申します。

BASICS代表小畑です。
私たちのモットーは、クライアントのためにまっとうな仕事をすること。そのためにはコミュニケーションが重要です。しかし世間では「エンジニア＝会話をしなくてもよい仕事」というイメージもあるようで…今回はさまざまなクライアントやエンジニアと関わってきた僕が、そんなイメージに物申すために、ちょっと面倒くさく語らせていただきます。

エンジニアは本当に、会話をしなくてもよい仕事？

世間のイメージである「エンジニア＝プログラマー」が理由のひとつ

まず、なぜ世間で「エンジニア＝会話をしなくてもよい仕事」というイメージがあるのか。
僕は「エンジニアはプログラムを組む人」という印象が強いからだと考えています。
この仕事は企画・設計・プログラミング・テスト・運用と…さまざまな役割がありますが、エンジニアにあまり馴染みがない人にとっては、ひたすら手を動かすプログラマーこそがエンジニアのイメージに繋がったのかなと。そこから「プログラマー＝エンジニアは会話をしなくてもよい仕事」に着地した気がします。
あとは小中学校でのプログラミング必修化やスクールの普及によって、よりその印象が強くなったんじゃないですかね。

エンジニアの仕事は、会話なくして成り立ちません

ではBASICSのエンジニアはというと、クライアントの技術課題や要望抽出を行う上流工程がメイン。
まずは先方が欲しいシステムのイメージから目的、やりたいことなどの希望を聞きますが「そもそも実現が難しい」という事実に辿り着くこともありますし、潜在的な課題があらわになることも。これって会話を重ねないと出てこない要素なんですよね。
次に課題を抽出したら「どんなシステムを作るか」の詳細を固めます。
画像イメージや操作性、処理仕様などももちろんですが、言語やフレームワーク、セキュリティ対策やバックアップ設定など…この項目はどんなシステムでも合計で230項目以上決めないといけないんです。
項目をすり合わせていくごとに、本来のニーズに合った理想の開発に近づくため、クライアントとの会話は必須と言ってもいいでしょう。

ポジション問わず、会話は結構あります

上流工程に携わるエンジニアは長ければ1日8時間、クライアントや社内のエンジニアとほぼMTGで喋りっぱなしのことも。密度は違えどプログラマーも同じです。
僕が過去に関わったプログラマーは進捗報告や情報共有、不明点の相談など…テキストコミュニケーションをメインに1日30〜50回やり取りしているメンバーもいました。この回数を重ねてやっと「そのメンバーがどんな案件で、どう考えて行動しているのか」を把握できるレベルなので、対クライアントとなるとそれ以上の行動量が必要になるのかもしれませんね。

といっても「同じ会話量をこなせ！」というワケではありません（笑）
仕事を進めるには、たくさんのやりとりが必要になるので「エンジニア＝コミュニケーションが発生する仕事」ということがわかってもらえたかなと思います。
では次に「コミュニケーションが不足するとどうなるのか？」そんな事例をお伝えしましょう。

コミュニケーション不足ゆえのエラーは？

△半日以上、無駄な仕事をしていた

とある案件で、仕様が変わり作業自体を中断することに。
その旨をリモート中の業務委託の担当エンジニアにテキストで連絡をしたところ、半日以上音沙汰なし…。終礼時にやっと反応があり、半日間何をしていたのかを聞くと、止めてと指示を出していた案件をずっとやっていたとの返事が。僕からのアナウンスにすぐに反応していれば、半日はもっと違うことに時間を割けたのに…という無駄が発生してしまいました。

△クライアントに不信感を抱かせてしまった

協業先のA社と新サービスを展開するために、クライアントへテスト運用の協力を依頼した時です。
事前に専用フォームへの登録が必要だったため、該当メールをクライアントへ通知。しかしそのメールが『A社名義で通知される』ことを伝えておらず「知らないアドレスからメールが来たんですけど…」とクラアイントから協業先に問い合わせが…！そりゃいきなり知らない会社からメールが来たら驚きますよね？

すぐに私たちから謝罪をして事なきを得ましたが「○○という会社名でメールが届きます」と一言お伝えしていれば済んだ話。些細なことですが、最悪の場合、今後の付き合いに影響があったかもしれません。
「相手がどう思うか」を想像して、先回りした会話ができていれば防げたことでした。

エラーは「まあいいや」という身勝手な感情から起こりやすい

これらの原因を紐解くと、会話に必要性を感じず「まあいいや」という身勝手な感情から、エラーが発生していたことがわかりました。だから必要以上の会話を避けるし、特に先回りの声掛けもしようとしなかったんです。
特にBASICSでは、リモートという物理的に声を掛けられない状況だからこそ「今どんな行動をしているのか」を可視化したり、積極的に発言をする姿勢が求められます。でもそんな環境を逆手にとって、急用の会話すらシャットダウンしてしまうことは「仕事の邪魔をされたくない」という建前を理由にした職務怠慢とも捉えられる。この姿勢はエンジニア歴問わず、対象者がどれだけ「相手から指図されたくない」というプライドに邪魔されているかによりますね。

うっかりミスは誰でもあるもの。でも「相手を気遣わない姿勢」は自分の感情を優先して、クライアントのために仕事ができていない証拠です。だから「エンジニア＝会話をしなくてもよい仕事」と認識している方がいるなら、僕はそれは間違いだと断言します。

BASICSは、会話を大切にします

コミュニケーションにこそ「質」を追求したい

冒頭でもお伝えした通り、うちのモットーはクライアントのためにまっとうな仕事をすること。コミュニケーションを重視するからこそ、会話では質も大切にします。
納期や予算、人員などの現実的なラインを正しく見極めて、できないことはしっかりとクライアントへ意思表示する。これこそが健全なコミュニケーションを行う秘訣です。
僕たちが向き合うべきはクライアントの課題解決。相手に気に入られたい、嫌われたくないというプライドが邪魔をしてどんな案件でも「はい」と返答してしまうのはただの御用聞き。本当に課題解決に向き合っているなら、時には相手の要望をすべてひっくり返すこともあるんです。クライアントから信頼されるために、嫌われる勇気を持ってコミュニケーションがとれる。そんな人こそがBASICSにとっての優秀なエンジニアです。

BASICSで、まっとうな仕事をしよう

社内でも、そんなコミュニケーションは多く発生しています。ある課題についてAの回答が有力だと議論中にBASICSでは「いや、Bの方がいいでしょ」と忖度なく発言するメンバーばかり。時にぶつかり合ったとしても、それは正しい衝突。全員がクライアントの方を向いて仕事ができている証拠かなと思いますね。

…ちょっと面倒なことを語りましたが、やはりBASICSにとってコミュニケーションは最も大切にしたい要素です。面倒くさいと思われてもいいから、クライアントのために全力投球がしたい！そんな熱意がある方には、当社はやりがいたっぷりな環境を提供できますよ。
（しかし、その一方でテキストコミュニケーションにも限界があるなという考えも…（笑）リモートでもたくさん会話を増やせるように最近ではメタバースなども活用していますよ）

BASICSの価値観に共感してくれた方は、ぜひ一度カジュアル面談からお会いしましょう。ここまで読んでくださったあなたとお会いできることを楽しみにしています。