変化の激しいエンジニアの世界で、どうすれば成長し続けられるのか。そのヒントを、飲食店向け予約台帳アプリを手がける「トレタ」の増井雄一郎さんが解説します。今回のテーマは「エンジニアと非エンジニアのコミュニケーション」です。
エンジニアはクセのある人間ばかりで、会話が噛み合わない……。そう感じている非エンジニアの読者は少なくないかもしれません。しかし、そのクセには一定の傾向があり、「どんな価値観を重視しているか」は共通している部分があると、増井さんは言います。
そこで今回は、非エンジニアとエンジニアの距離を縮めることを目的に、エンジニア目線で「エンジニアが困る仕事の頼み方」や「エンジニア独特のコミュニケーション文化」について語ってもらいました。
「エンジニアの特徴を把握して『彼らにはそういう文化があるんだ』と認識してもらえると、普段からのコミュニケーションが取りやすくなるかと思います」と増井さん（左）は言います
「できます」＝「やります」ではない
エンジニアと非エンジニアで大きく文化が異なるポイントは、いくつかあると思います。真っ先に思い当たるのは、「言葉のニュアンスの違い」です。
たとえば、皆さんは「コレできますか？」と聞いて、相手が「できます」と返答があった時に、どんな解釈をしますか。文脈にもよるとは思いますが、おそらく少なくない人が「できる＝わりと短い時間ですぐに対応できる」と捉えるのではないでしょうか。また、人によっては「できる＝今から対応する」という“了解の返事”だと認識することもありますよね。
エンジニアが「できます」と答える時は、それは「技術的に実現が可能か」という意味で「できます＝可能です」と言っている場合がほとんどです。つまり「今すぐ１人で解決できる」ケースでも、「今すぐは対応できないけど、１週間後から数人がかりで３カ月ほどかければできる」ケースでも、「できます」と言うんです。もちろん、「引き受けます」というニュアンスは含んでいません。
こうした言葉の認識の違いから、「頼んだのにやってくれていない」「こっちは頼まれた覚えがない」といった問題が起こるケースはよく見かけますね。「もしコレを今からお願いするとしたら、どれくらいの時間がかかりますか？」「そしたら、今から◯日までにやってもらえますか？」と具体的に聞くことが、リスクヘッジにつながると思います。（それを避けるためにエンジニア側が、「技術的には可能です」と言うこともあります。）
「動かなくなった」と言われても、エンジニアは動けない
今の話とつながるのですが、「仕事の頼み方」も大きく違うポイントなのかなと。エンジニアからすると、仕事の依頼については「要件定義」をハッキリしてほしいんですよね。「こういうものを作りたい」「こういう問題を解決したい」というゴールが明確でないと、最終的なアウトプットがズレてしまうことは、往々にしてあります。
弊社でもリリースして間もない頃は、「要件定義のあいまいさ」からたびたび問題が起こっていました。よくあったのが「これが動かなくなったから直してくれ」という依頼です。
たとえば「車が動かなくなった」と言うと、さまざまなシチュエーションが考えられます。「そもそもエンジンがかからない」場合と、「アクセルを踏んでも走らない」場合では、修理する場所が大きく異なってきますよね。これは、プログラミングでも同様です。「どういう根拠で動かないと感じたのか」「どんな動作をした時に動かなくなったのか」がわからないと、対処のしようがないんですよね。逐一そのヒアリングに時間がかかるのは、エンジニアにとっても非エンジニアにとっても、大きなストレスになり得ます。
そこで弊社では、エンジニアへ依頼する際の要件定義を明確にするべく、「開発リクエストフォーム」を設置しています。これは、エンジニアへ何かをお願いする時に書いてもらう“依頼書”ですね。僕らが必要だと思っている情報を事前に詳しく記入してもらうことで、「要件定義のあいまいさ」から起きる問題は、グッと少なくなりました。キャプチャで内容はお見せできますから、ぜひ参考にしてみてください。
トレタが導入している開発リクエストフォーム。Googleドキュメントのフォーム機能を使っている
サイトやアプリの修正、簡単そうなのは見た目だけ
エンジニアへの依頼の際に、非エンジニアの皆さんに念頭に置いてほしいことがあります。それは「サイトやアプリの見た目上では簡単に見える変更でも、実際はとても難しい場合がある」ということです。
ジェンガって、上の方で引き抜いたり積んだりするのは簡単ですが、下の方を引き抜いたり足したりするのは難しいですよね。プログラミングも似たようなもので、「下の方をいじったら全部が崩れちゃう」みたいなケースがよく起こるんです。
たとえば、「お問い合わせフォームに新しい項目を追加してください」って依頼があったとします。付け足せばいいだけなら、簡単そうに思えますよね。けれども、実際はそんなに単純ではないこともあります。投稿された情報をメール転送するシステムや、データの集計プログラムがフォームと連携していたら、それらも変更しなくちゃいけない。それらを変更するとしたらあれもこれも……と、数珠つなぎで修正が必要になってしまう可能性があります。
さらに言えば、「その変更でいじるのは上か下か」というのは、プログラミングの中身を見なければわかりません。だから、クライアントから求められた修正が“簡単そうに見えた”からと言って、その場で安請け合いは絶対にしないでくださいね（笑）。
サイトやアプリの修正はジェンガと似ていると増井さん（photo by antony_mayfield）
「この修正の工数はどれくらいかかりますか？」と聞かれることも多々ありますが、正直に言うと、正確な見積もりを出すのはほぼ不可能に近いです。「変更にかかる具体的な作業量」については、実際に手を入れてみないとわからないんですよ。だから、「やってみて崩れなかったら30分で終わるけど、崩れたら1週間以上かかる」といった言い方になってしまう。
プログラミング上に仕様が文章で丁寧に記録されている場合は、それを読めば正確に工数を見積もれるケースもあります。ただ、その仕様を読み解くコストもかなり重いので、「リスクの調査で3日かかったけど、作業自体は数時間で終わった」なんてことも日常茶飯事ですね。
急用以外は、チャットでお願いします
あくまで傾向ですが、エンジニアは直接話したり電話をしたりなどの「同期コミュニケーション」をあまり好みません。僕もそうで、たとえ社内で目の前に座っている人が相手だとしても、急用でなければ基本的にチャットなどの「非同期コミュニケーション」にしてほしいと思っています。
「近くにいてもチャットがいいの？」と不思議に感じる方もいるかと思いますが、同期コミュニケーションは時間を拘束されるし、その場での返答を余儀なくされるものですよね。作業に集中している時に、急ぎじゃないふわっとした相談をされたりするのは、かなりストレスフルなんです。チャットなら「すぐ返すか、10分後に返すか」って、こちらに選択の余地があるので、精神的に負荷が軽減されます。
ただし、相手がムッとしそうなことを言わなきゃいけない時は、同期コミュニケーションにするべき。非同期コミュニケーションでは、感情を正確に伝えられないからです。僕も仕事上で「話がこじれてきそうだな」と感じたら、すぐに相手と直接話すようにしています。チャットでケンカをするとロクなことにならないですからね（笑）
エンジニアは“モヒカン族”が多い？
今までの話をトータルすると、エンジニアは多かれ少なかれ「モヒカン族」の要素を持っている人種だと、まとめられるのかもしれません。モヒカン族というのはネットスラングで、「情緒的なやり取りより情報の交換を重視する」「社交辞令は抜かして端的に論点を述べることが望ましいと考える」といった特徴を持つ人々のことを指します。僕も結構なモヒカン族ですが、エンジニア以外と話す時には、あまり端的に伝えすぎないようにしています。
モヒカン族の傾向があるエンジニアは、とにかく生産性の高いコミュニケーションに重きを置くので、指摘や意見の仕方が率直です。非エンジニアの人たちからすると「言い方がキツい、容赦ない」と感じるかもしれません。ただ、こちらからすればまったく悪意はなくて。悪意がないから問題ない……なんてことはない、ともわかっていますが（笑）。それでもなお、「馴れ合いや気遣いはいらない、正面から言葉で殴りあおうぜ」と考えているエンジニアは多いですから、語気の強さについてはあまり気にしないでくださいね。
非エンジニアの皆さんからすると、「エンジニアはクセのある人間ばかり」という印象を抱いている方は少なくないでしょう。しかし、そのクセには一定の傾向があり、「どんな価値観を重視しているか」は共通している部分があります。もちろん、僕らからの歩み寄りも必要なのですが、いかんせんエンジニアにはコミュニケーション下手な人間も多いです。エンジニアの特徴を把握して「彼らにはそういう文化があるんだ」と認識してもらえると、普段からのコミュニケーションが取りやすくなるかと思います。
（聞き手：西山武志）