個人的な経験と偏見に基づくエンジニアによくみられる傾向とうまく付き合うための対策の考察 / bunsekiigai

個人的な経験と偏見に基づくエンジニアによくみられる傾向とうまく付き合うための対策の考察しんゆう＠データ分析とインテリジェンス 2019/07/29 「データ分析」だけれども「分析以外」の話を考える会

本日の資料は https://speakerdeck.com/shinu/bunsekiigai に公開済みです。ブログ・Twitterからもリンクがありますスライドは公開してあります

• データを扱う人は何かとエンジニアと関わることとになるが、エンジニアとして働いたことがない人がエンジニアをきちんと理解することは難しい、というか多分無理 • なので違う考え方をする人達という前提で、どうコミュニケーションを取ったらいいかを考える必要がある • そこで自分がこうやってきた、という話をまとめてみた（なお、全部がうまくいったわけではない）
前置き

本日の話の流れ

本日の流れは以下の通り • 前置き • 自己紹介 • エンジニアといえば・・・ • エンジニアによくみられる傾向と対策本日の話の流れ

自己紹介

HN：しんゆう仕事：データアナリストを名乗る何でも屋最近全然分析してない「データ分析とインテリジェンス」を書いてる人ブログ：https://analytics-and-intelligence.net/ Note ：https://note.mu/shinu Twitter：@data_analyst_ 自己紹介

エンジニアといえば・・・

エンジニアといえば世間では • 気難しく偏屈でコミュニケーションがとりづらいエンジニアといえば・・・

エンジニアといえば世間では • 気難しく偏屈でコミュニケーションがとりづらい • 技術のことばかりでビジネスを知らないエンジニアといえば・・・

エンジニアといえば世間では • 気難しく偏屈でコミュニケーションがとりづらい • 技術のことばかりでビジネスを知らない • なんて言われがちエンジニアといえば・・・

エンジニアといえば世間では • 気難しく偏屈でコミュニケーションがとりづらい • 技術のことばかりでビジネスを知らない • なんて言われがちだが、これは大体において声が大きく人数が多い非エンジニアからの一方的な見方なのでは？エンジニアといえば・・・

エンジニアといえば、エンジニアだからではない

エンジニアといえば、 • 違う背景を持つ人とはコミュニケーションがとりづらいエンジニアだからではない

エンジニアといえば、 • 違う背景を持つ人とはコミュニケーションがとりづらい • 自分の仕事の知識ばかりで他の人の仕事を知らないエンジニアだからではない

エンジニアといえば、 • 違う背景を持つ人とはコミュニケーションがとりづらい • 自分の仕事の知識ばかりで他の人の仕事を知らない • と見ればみんなさほど変わらないので、エンジニアだからと特別視しないで同じように付き合えばよいエンジニアだからではない

• もちろん職種によって特徴はあるので、エンジニア特有な点について、その傾向と対策を考えてみる • 個人的な経験と偏見に基づくものであることに注意とはいえ・・・

エンジニアによくみられる傾向と対策

エンジニアによくみられる傾向とその対策 • 最初からしっかりと作りたがる • 細かいところまでいちいち聞いてくる • 使うことより作ることに興味を持つ • システム的に問題ないか、しか気にしない •
技術者の論理を最優先にするエンジニアによくみられる傾向と対策

最初からしっかりと作りたがる • 「6割作ってあとは使いながら直していく」をなかなか許容してくれない • エンジニアが「大変な手間がかかる」と言っているからとすぐに引き下がったり、自分に都合が良いからと要求だけしたりはよくない最初からしっかりと作りたがる

最初からしっかりと作りたがる • コストや手間もあるので総合的に考える必要があるので、なぜそれができないのかを聞いてみる • 毎回面倒な設定をしなければいけないなど、本当に手間がかかりすぎて現実的でないこともあれば、エンジニアではなく使う側が対応することで解決することもある最初からしっかりと作りたがる

細かいところまでいちいち聞いてくる • エンジニアが話のあいまいさを許容してくれないのは最終的に人ではなくコンピュータをプログラミングを使って相手にするから • コンピュータは指示したことは間違いなく行う一方で指示していないことはやらないし、意図したことと間違えていても自動で修正したり実行前に指摘したりしない細かいところまでいちいち聞いてくる

細かいところまでいちいち聞いてくる • なので何がしたいのか、最終的にどうあってほしいのかを正確に伝える必要がある • 伝えていないことが達成されなくてもそれは依頼する側の責任。なので聞いてくれる人はむしろ非常にありがたい • 細かく聞いてくるのはあとで文句を言われないようにという予防であることも
細かいところまでいちいち聞いてくる

細かいところまでいちいち聞いてくる • 言われたことしかやらないのが悪いのではなく、間違えたことを言うのが悪い • とはいえ間違えていたり足りないと思うところがあったら指摘はしてほしい • が、指摘してくれないことを恨むのは筋違い細かいところまでいちいち聞いてくる

使うことより作ることに興味を持つ • 作ることはやり方などに口を出さずにお任せしてやってもらうのがよい • が、一度作ってしまうとなかなか修正してくれないので、開発する前の設計から積極的に関わっておきたい • こちらの都合で仕様変更が必要な場合は誠心誠意お願いする
使うことより作ることに興味を持つ

システム的に問題ないか、しか気にしない • 知らない間に新しいテーブルができたり既存のカラムの内容が変わったりするがエラーが出ないとそのままになる • 情報の共有は常に依頼しても（なぜか）なかなかやってくれないので何が起きているかの監視は必要 • どうにもならない場合は早めに部署としての苦情を言うシステム的に問題ないかしか気にしない

技術者の論理を最優先にする • 技術的に正しいかどうかで見るのは当然で、エンジニアが技術の論理を後回しにされても困る • ビジネス側は使えるかどうかどうかだけを見るからお互いがお互いの主張だけをするともめる技術者の論理を最優先にする

技術者の論理を最優先にする • 最終的にはエンジニアに動いてもらう必要がある • どうしてそれが必要なのかをきちんと伝える • それでもだめなら個人の問題ではなく、会社としてどう優先順位をつけるか、という問題として扱ってもらう技術者の論理を最優先にする

まとめ

• エンジニアだからコミュニケーションができない、というのはかなり偏見であり話せばわかる人は多い • 個人で解決しない場合は部署や会社の問題としてどうするべきかを提起すること • 個人の相性もあるのでどうしようもない時には最低限の礼儀を持って適度なお付き合いでいいまとめ

• 1人ですべてできないので仕事を分担しているのだからむやみに対立しても得することは何もない • お互いがお互いに違いがあることを理解した上でコミュニケーションが必要 • ということを理解している側からまずは歩み寄るしかないのではまとめ

ご清聴ありがとうございましたしんゆう＠データ分析とインテリジェンス https://analytics-and-intelligence.net/ Twitter：@data_analyst_

個人的な経験と偏見に基づくエンジニアによくみられる傾向とうまく付き合うための対策の考察 / b...