ものづくり好きになる チームビルディング

ものづくり好きになる チームビルディング

Link
- 創業期に根付いたエンジニア至上主義|日経ビジネス/オレの愛したソニー
http://business.nikkeibp.co.jp/atcl/interview/16/031800001/061400016/?P=2&rt=nocnt

- マクドナルド理論|池谷裕二/ツイート
https://twitter.com/yuji_ikegaya/status/752804071157866496?ref_src=twsrc%5Etfw

A967476c5855d593710a9a580f6b2aed?s=128

Yuichi Maekawa

August 29, 2016
Tweet

Transcript

  1. ものづくり好きになる チームビルディング まえかわ ゆういち(@kaelaela)

  2. 飲み会でもアプリを触ってる場面

  3. 前川 裕一 • でAndroidエンジニア • Twitter: @kaelaela31 • Github: @kaelaela

    • 日本酒フリーク
  4. 今日の話 • こんな開発は嫌だ(肝試し) • 事前準備 • 今すぐ使えるKAIZEN Tips

  5. こんな開発は嫌だ

  6. MTGが葬式のよう (PMとかが形式的にお経を唱える)

  7. バグがリリースされても誰も気づかない(そ もそも全然触ってない)

  8. 運用や意思決定者と開発チームが まったく意思疎通できていない

  9. 情報共有が部分的で階層的

  10. そんな開発は嫌だ!!!

  11. なぜこうなるのか?

  12. ものづくりが好きじゃない

  13. ものづくりが好き ≠ エンジニア集団

  14. 技術者に偏ったチーム(考え)はよくない ・担当以外を自分の分野外というな  (技術の専門でありチームの専門でもある) ・最初の755は技術者の意見が強すぎた ・次のチームは意思決定の意見が強すぎた  → 少しずつバランスが取れてきた ・エンジニアだけが評価されても周りはおもしろくない  (逆も然り) 参考:Sony創業期に根付いたエンジニア至上主義の病理

    http://business.nikkeibp.co.jp/atcl/interview/16/031800001/061400016/?P=2&rt=nocnt
  15. ものづくりが好きじゃない人の考え方 • とにかくリリースして数字をあげたい • 納期=努力 • 効率化に無頓着 • いい開発とは何だろうかという話を真面目にできない •

    失敗を自分やチームのものではなく他人のせいにする
  16. ものづくりが好きな人の考え方 • 何度も行う煩わしいことは効率化 • 自分の能力でメンバーが抱えている問題を解決したい • 腹を割って「良い開発」への理想と現実を話せる • 自分の失敗を認め糧にし、チームの成長を促す

  17. ものづくりが好きになってほしい

  18. 何もせずにチームは変わらない このチームやべぇわー ◯◯とかないわー プロデューサーがどうだわー

  19. 事前準備(ここがすべて)

  20. チームの不吉な臭いに敏感になる ・自動化を警備する  → 2分でできるなら即対応 ・責任の押し付け合いを避ける(1 for * * for 1)

    ・コツコツ仕様書を整備する  →リビングドキュメントデッドを撲滅 ・意志の共有スピードチェック  →「あの人が知っている」では遅い
  21. 情報共有の現状はどうか調査 ・なんでも共有しろということではない ・開発や運用に関わる情報は絶対に早く伝えるべき  (明日から〜さんが異動になる。え?!?!) ・嘘でごまかすくらいなら正直に伝える  (〜さんはチームの方向性と合わなかったので異動した) ・異動は悪いことではないという認識を共有する  (かつ大きくではなく小さく変更していく) 開発を遅延させる情報共有のボトルネックを見つける

  22. 人を分析してみる ・色々な生き方があるのでその人にとって何が大事か聞く >仕事でしかコードをかかない >勉強会とかは別に積極的じゃない >とにかく給料をあげたい >コードを書くのが好き >売り上げが全て それでも大抵、人としていい人ばかり

  23. チームを分析してみる ・どんな人がチームに分布しているのかまとめる  → 〜さんは…さんと組ませると進みそうとかわかる >保守運用が得意 >新規開発でガツンとパワーでやりきれる >アイデア出しがうまい >アイデアがあればいつでも動き出せる

  24. 「味方をつける」 ・声の大きいエンジニアは一人だと厳しい  → 疲れ切った人たちからいなくなっていく ・意思決定が早く影響力のある人  → 伝える&変えるを繰り返す ・自分を応援してくれる人  → 会議や意見出しでそっと相互にサポート

  25. 自分なりのいい開発を考え「伝える」 ・これはあくまで755の話 ・自分なりのチームビルディングという方法論を抽象化 ・まとまってきたら少しずつ周りにαリリース ・共有、実行、確認観測、改善 ・長く関わっていることは大した意味はない ・明日きた人がすぐに活躍できる環境を作る ・エンジニア「だけ」が働きやすい環境は良くない

  26. 今すぐ使えるKAIZEN tips (読み飛ばしておk)

  27. 煮詰まる会議に「マクドナルド理論」 https://twitter.com/yuji_ikegaya/status/752804071157866496?ref_src=twsrc%5Etfw

  28. 心のともしび運動 ・自分が真っ先に手を動かすこと ・Slackに通知流すくらいの簡単なお仕事 ・「ドキュメントに追記しときました」 ・定期的にでも(飲み会でも)エモい自分の考えを伝える > 暗いと不平をいうよりも、       すすんで灯りをつけましょう ありがたい説法・法語まとめ  http://matome.naver.jp/odai/2125928751634759300

  29. 専門外では「バカ」になる ・こうしたらよいのでは?という普段の気づきを共有する ・「悪い部分をこうしてください」というのは❌   →「お前がやれよ」 ・できるならもちろん自分で。無理なら「バカ」になる 「よくわからないのですが、こういうものなんですか?」 ・解決策の議論を一から始める。いいえ、ゼロから。

  30. 定例棚卸定例 ・「その定例、本当に必要ですか?」が合言葉 ・なぜ定例なのか考える ・内容もルーチン化しているなら自動化の兆し ・朝の挨拶すらちょっと変えてみる ・いつもどおり=正常とは限らない

  31. サブリミナル「いい開発」記事

  32. Thx ;-)

  33. いらすとやさん、ありがとうございます (今回の素材は全ていらすとや)