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_