Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

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

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

Yuichi Maekawa

August 29, 2016
Tweet

More Decks by Yuichi Maekawa

Other Decks in Business

Transcript

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

    View Slide

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

    View Slide

  3. 前川 裕一
    ● でAndroidエンジニア
    ● Twitter: @kaelaela31
    ● Github: @kaelaela
    ● 日本酒フリーク

    View Slide

  4. 今日の話
    ● こんな開発は嫌だ(肝試し)
    ● 事前準備
    ● 今すぐ使えるKAIZEN Tips

    View Slide

  5. こんな開発は嫌だ

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  11. なぜこうなるのか?

    View Slide

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

    View Slide

  13. ものづくりが好き

    エンジニア集団

    View Slide

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

    View Slide

  15. ものづくりが好きじゃない人の考え方
    ● とにかくリリースして数字をあげたい
    ● 納期=努力
    ● 効率化に無頓着
    ● いい開発とは何だろうかという話を真面目にできない
    ● 失敗を自分やチームのものではなく他人のせいにする

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  20. チームの不吉な臭いに敏感になる
    ・自動化を警備する
     → 2分でできるなら即対応
    ・責任の押し付け合いを避ける(1 for * * for 1)
    ・コツコツ仕様書を整備する
     →リビングドキュメントデッドを撲滅
    ・意志の共有スピードチェック
     →「あの人が知っている」では遅い

    View Slide

  21. 情報共有の現状はどうか調査
    ・なんでも共有しろということではない
    ・開発や運用に関わる情報は絶対に早く伝えるべき
     (明日から〜さんが異動になる。え?!?!)
    ・嘘でごまかすくらいなら正直に伝える
     (〜さんはチームの方向性と合わなかったので異動した)
    ・異動は悪いことではないという認識を共有する
     (かつ大きくではなく小さく変更していく)
    開発を遅延させる情報共有のボトルネックを見つける

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  32. Thx ;-)

    View Slide

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

    View Slide