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

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

本日の話の流れ

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

自己紹介

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

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

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

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

Slide 29

Slide 29 text

まとめ

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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