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

29e4aa4e265e478995df09ca52d62103?s=47 ShinU
July 29, 2019
1.2k

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

作成者 :しんゆう@データ分析とインテリジェンス
ブログ :https://analytics-and-intelligence.net/
Twitter:https://twitter.com/data_analyst_

29e4aa4e265e478995df09ca52d62103?s=128

ShinU

July 29, 2019
Tweet

Transcript

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

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

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

    前置き
  4. 本日の話の流れ

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

  6. 自己紹介

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

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

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

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

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

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

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

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

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

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

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

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

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

    技術者の論理を最優先にする エンジニアによくみられる傾向と対策
  20. 最初からしっかりと作りたがる • 「6割作ってあとは使いながら直していく」をなかなか許容 してくれない • エンジニアが「大変な手間がかかる」と言っているからと すぐに引き下がったり、自分に都合が良いからと要求だけ したりはよくない 最初からしっかりと作りたがる

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

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

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

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

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

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

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

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

  29. まとめ

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

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

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