チーム積み重ね
公 開版
2014/01/31 帰社日@ 万葉

@tatsuoSakurai
@tatsuoSakurai
櫻井 達生
株式会社 万葉 所属
Railsエンジニア
チームの
日々の工夫
1. 生煮えプルリ
2. Wiki
3. カンバン・朝会・
ふりかえり
4. その他
1. 生煮えプルリ
生煮えプルリ
途中でプルリ
(pull request)

方向性の確認
タスクの確認
生煮えプルリ後は

リベース?
リベースしたり
マージしたり
別プルリしたり
慣れてくると
作業のはじめにPR
git commit -m "Start pull request" —allow-empty とか

タスクを書いて潰していく
タスクはレビュアーにとっても良い材料
Wiki
開発

リリースノート
新しく実装された機能を

つい使いたくなるような

人にやさしい文章で書かれたもの
一覧はタイムラインでダイジェスト
詳細はリンク先
Rails Wayをまだ理解してない
人にも使いやすい
レビュー待ちサマリー
実装できた機能を毎週お客さんに動作
確認してもらってやりとりするもの
チケットじゃないザックリ感が
よい感じ
用語集


ユビキタス言語(fromDDD本)
会話でブレがあったら即更新
地味だけど超有効(何度も見返すし)
用語集のないプロジェクトは失敗すると言
い伝えがあるらしい…
コード規約


こういう時どう書く?っていうのが出
たらwikifyしておく

統一性を保ちつつ、多様性も許容する
※ 規約があるからこう書くではない
ところで…

Wikiのメンテって
誰がする?
チーム
使いにくいと思った人が
よりよく更新していく
より better にしていく
Wikiの鮮度
=
チームの効率
カンバン
朝会
ふりかえり
カンバン
!

今週なにしたらいいか
今週のチームを俯瞰できる
手書き・アナログ・単純なのがいい
アダ名とかでアイスブレイク

独自に安心ライン、防衛ライン…などアグレッシブに更新してる
防衛ライン:
終わってないとアカンタスクを並べる

安心ライン:
終わってると安心タスクを並べる
朝会
!

今日やることの共有
気になることの共有
あいさつ
今日の一言でアイスブレイク
ふりかえり
!

一番重要かなあ〜
良いこと気になることをチームで共有
喜びが増える、不安が減る
ふりかえり
!

Problem から Try へ
不安や不満を前向きにとらえてみる
チームでアイデアを出して解決していく
プライベートな KPT でアイスブレイク
たとえば
!

P: ふりかえりが長い
-> T:時間を1時間に設定
-> T:開始前にアジェンダ共有
-> T:開始前に◯時に終了予定と宣言
たとえば
!

P: 部屋が乾燥してツライ
-> T:日報でよかった加湿器共有
-> T:前から気になってたし買おう
-> T:3日で3台導入
たとえば
!

P: 今日どれくらいがんばればいい?
-> T:出せる数字で出してみる
-> T:グラフにしてみる
-> T:他のチームに聞いてみる
たとえば
!

P: コードが、コードが〜
-> T:地道に隙をみてリファクタ
-> T:やさぐれ過ぎない
-> T:カッとなることを推奨する
活きた話はなかな
か本にはない
(でもきっかけはある)
同業者、コミュニティで相談してみる
そこでの取り組みを真似してみる
その他
気をつけていること
たのしく開発しよう
たのしいと効率がいい
もっと開発ができる
一番重視していること

チームがドライブし
ていること
ドライブした状態をキープすること
4-5人は作業しながら
いける
5-6人だと調整役がい
るのがよさそう
自分じゃないとできな
いことをやる
自分じゃないとできな
いことを減らす
の繰り返し
チームのリズム
早めのレビュー
メンバーが動きやすいようにサポート
「レビューします」って
リンク貼ってからレビューすると
他の人もついレビューしてしまう
メンバーが気になっていることはなる
べく早く解決する
気になっていることをすぐに言いやす
い雰囲気を作る
メンバーのキャラを把握していく
チームをチームで
ドライブしていく
自分でやりすぎない
きっかけを作る
役割をもちまわる
チームで責任をもつ
spec落ちたらチームで対応
落としたやつが直せではなく
落とした状態でpushしたチームの責任
実装者が直すのが早いことが多い
諦めずにお客さん
も巻き込んでいく
グイグイいく
言葉
言葉には

ベクトルがある
◯◯したい
プログラマには

期待に答えたい

欲がある
◯◯したいな〜

あるといいな〜
◯◯作って

みました!
いいな〜だけでなく

自分でちょっと

やってみる
そうすることで流れができる
一番貴重な資源は
モチベーション
それを維持することはとても重要
言葉使い
どうして言葉使いが

大事なのか
人と人とのAPI
人間は

言葉で理解する

部分が9割
(たぶんね)
相手はどうしたい?
自分はどうしたい?
上手に伝えられる
ようになると、

効率がよくなる。
プログラミング
コードの質が重要
(※必要とは違う)
人間
 言葉の質が重要
  (人の間と書きますね^^;)
ケンカの原因
「言い方が気に食わない」
というのが9割(たぶん)
言葉(言い方)は
とても大事
チームの雰囲気を
よく保つ
萎縮させない
MPを減らさせない
安心感を出す
前半でちょいちょい

アイスブレイク入れて
ますが、

これは超重要で、割り
とまじめふざけてます
^^(好きでやってますけどね
親しき仲にも

礼儀あり
親しき仲にも

リスペクトあり
コミュニティでよ
く会う人にもお仕
事では敬語でさん
付け
年齢問わず子供でもさんづけだったり
します
否定しない
押し付けない
提案してもらう
(どうしたいですか?)
否定の後乗りはしない

「あれは良くない
と思ってた」
-> 後から言うのはいくらでもできるの
で、リアルタイムで言ってもらう
真正面から打ち返すと相手も凹むから、
ちょっと斜め下くらいからの言い方と
か日頃のキャラとか信用貯金とか

重要ですよ
相手の気持ちを考える
相手の立場に立つ
よく聞く言葉だけど重要
カッコつけすぎない

でもカッコはつける
できることをやる

できることを増やす
リーダーの資質と
して一つだけあげ
るとしたら?
->「明るいこと」
野中郁次郎先生いわく、


リーダーに相談に行っ
て暗くなって帰って
きてどうする。
https://twitter.com/hiranabe/status/299668596639035392
たのしく開発しよう
たのしいと効率がいい
もっと開発ができる
たのしいは目的じゃない
結果というか状態?

度合い?
アジャイルは名詞じゃ
ない。アジャイルは形
容詞で、身軽に行動す
るってことなんだ
—DaveThomas
"Agility" is degree
—Kakutani Shintaro
“アジャイルさ" とは
プロセスがどれだけ

いきいきしているかを
示す度合いである。
—Kakutani Shintaro
アジャイルさ
=
たのしさ
たのしいとは、
状況である。
関わる人が気持ち良く動ける

効率の良い状態を維持した状況である。
なんかフツウ
それがいいんです
フツウのことを

フツウにやっていく
フツウを増やす
フツウは文脈によって
変わる
チームで文脈を作って
いけたらいいなあ
Upcoming SlideShare
Loading in...5
×

20140131 万葉帰社日発表 チーム積み重ね 公開版

29,693

Published on

1月の万葉帰社日で発表した資料です。
主に今のチームでの工夫など...

Published in: Technology
3 Comments
73 Likes
Statistics
Notes
No Downloads
Views
Total Views
29,693
On Slideshare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
38
Comments
3
Likes
73
Embeds 0
No embeds

No notes for slide

20140131 万葉帰社日発表 チーム積み重ね 公開版

  1. 1. チーム積み重ね 公 開版 2014/01/31 帰社日@ 万葉 @tatsuoSakurai
  2. 2. @tatsuoSakurai 櫻井 達生 株式会社 万葉 所属 Railsエンジニア
  3. 3. チームの 日々の工夫
  4. 4. 1. 生煮えプルリ 2. Wiki 3. カンバン・朝会・ ふりかえり 4. その他
  5. 5. 1. 生煮えプルリ
  6. 6. 生煮えプルリ 途中でプルリ (pull request) 方向性の確認 タスクの確認
  7. 7. 生煮えプルリ後は
 リベース?
  8. 8. リベースしたり マージしたり 別プルリしたり
  9. 9. 慣れてくると 作業のはじめにPR git commit -m "Start pull request" —allow-empty とか タスクを書いて潰していく タスクはレビュアーにとっても良い材料
  10. 10. Wiki
  11. 11. 開発
 リリースノート 新しく実装された機能を
 つい使いたくなるような
 人にやさしい文章で書かれたもの
  12. 12. 一覧はタイムラインでダイジェスト 詳細はリンク先
  13. 13. Rails Wayをまだ理解してない 人にも使いやすい
  14. 14. レビュー待ちサマリー 実装できた機能を毎週お客さんに動作 確認してもらってやりとりするもの
  15. 15. チケットじゃないザックリ感が よい感じ
  16. 16. 用語集 
 ユビキタス言語(fromDDD本) 会話でブレがあったら即更新 地味だけど超有効(何度も見返すし) 用語集のないプロジェクトは失敗すると言 い伝えがあるらしい…
  17. 17. コード規約 
 こういう時どう書く?っていうのが出 たらwikifyしておく 統一性を保ちつつ、多様性も許容する ※ 規約があるからこう書くではない
  18. 18. ところで…
 Wikiのメンテって 誰がする?
  19. 19. チーム
  20. 20. 使いにくいと思った人が よりよく更新していく より better にしていく
  21. 21. Wikiの鮮度 = チームの効率
  22. 22. カンバン 朝会 ふりかえり
  23. 23. カンバン ! 今週なにしたらいいか 今週のチームを俯瞰できる 手書き・アナログ・単純なのがいい アダ名とかでアイスブレイク
 独自に安心ライン、防衛ライン…などアグレッシブに更新してる
  24. 24. 防衛ライン: 終わってないとアカンタスクを並べる 安心ライン: 終わってると安心タスクを並べる
  25. 25. 朝会 ! 今日やることの共有 気になることの共有 あいさつ 今日の一言でアイスブレイク
  26. 26. ふりかえり ! 一番重要かなあ〜 良いこと気になることをチームで共有 喜びが増える、不安が減る
  27. 27. ふりかえり ! Problem から Try へ 不安や不満を前向きにとらえてみる チームでアイデアを出して解決していく プライベートな KPT でアイスブレイク
  28. 28. たとえば ! P: ふりかえりが長い -> T:時間を1時間に設定 -> T:開始前にアジェンダ共有 -> T:開始前に◯時に終了予定と宣言
  29. 29. たとえば ! P: 部屋が乾燥してツライ -> T:日報でよかった加湿器共有 -> T:前から気になってたし買おう -> T:3日で3台導入
  30. 30. たとえば ! P: 今日どれくらいがんばればいい? -> T:出せる数字で出してみる -> T:グラフにしてみる -> T:他のチームに聞いてみる
  31. 31. たとえば ! P: コードが、コードが〜 -> T:地道に隙をみてリファクタ -> T:やさぐれ過ぎない -> T:カッとなることを推奨する
  32. 32. 活きた話はなかな か本にはない (でもきっかけはある) 同業者、コミュニティで相談してみる そこでの取り組みを真似してみる
  33. 33. その他 気をつけていること
  34. 34. たのしく開発しよう たのしいと効率がいい もっと開発ができる
  35. 35. 一番重視していること チームがドライブし ていること ドライブした状態をキープすること
  36. 36. 4-5人は作業しながら いける 5-6人だと調整役がい るのがよさそう
  37. 37. 自分じゃないとできな いことをやる 自分じゃないとできな いことを減らす の繰り返し
  38. 38. チームのリズム 早めのレビュー メンバーが動きやすいようにサポート
  39. 39. 「レビューします」って リンク貼ってからレビューすると 他の人もついレビューしてしまう
  40. 40. メンバーが気になっていることはなる べく早く解決する 気になっていることをすぐに言いやす い雰囲気を作る メンバーのキャラを把握していく
  41. 41. チームをチームで ドライブしていく 自分でやりすぎない きっかけを作る 役割をもちまわる
  42. 42. チームで責任をもつ spec落ちたらチームで対応 落としたやつが直せではなく 落とした状態でpushしたチームの責任 実装者が直すのが早いことが多い
  43. 43. 諦めずにお客さん も巻き込んでいく グイグイいく
  44. 44. 言葉
  45. 45. 言葉には
 ベクトルがある
  46. 46. ◯◯したい
  47. 47. プログラマには
 期待に答えたい
 欲がある
  48. 48. ◯◯したいな〜
 あるといいな〜
  49. 49. ◯◯作って
 みました!
  50. 50. いいな〜だけでなく
 自分でちょっと
 やってみる そうすることで流れができる
  51. 51. 一番貴重な資源は モチベーション それを維持することはとても重要
  52. 52. 言葉使い
  53. 53. どうして言葉使いが
 大事なのか
  54. 54. 人と人とのAPI
  55. 55. 人間は
 言葉で理解する
 部分が9割 (たぶんね)
  56. 56. 相手はどうしたい? 自分はどうしたい?
  57. 57. 上手に伝えられる ようになると、
 効率がよくなる。
  58. 58. プログラミング コードの質が重要 (※必要とは違う)
  59. 59. 人間  言葉の質が重要   (人の間と書きますね^^;)
  60. 60. ケンカの原因 「言い方が気に食わない」 というのが9割(たぶん)
  61. 61. 言葉(言い方)は とても大事
  62. 62. チームの雰囲気を よく保つ
  63. 63. 萎縮させない MPを減らさせない 安心感を出す
  64. 64. 前半でちょいちょい
 アイスブレイク入れて ますが、
 これは超重要で、割り とまじめふざけてます ^^(好きでやってますけどね
  65. 65. 親しき仲にも
 礼儀あり
  66. 66. 親しき仲にも
 リスペクトあり
  67. 67. コミュニティでよ く会う人にもお仕 事では敬語でさん 付け 年齢問わず子供でもさんづけだったり します
  68. 68. 否定しない 押し付けない 提案してもらう (どうしたいですか?)
  69. 69. 否定の後乗りはしない 「あれは良くない と思ってた」 -> 後から言うのはいくらでもできるの で、リアルタイムで言ってもらう
  70. 70. 真正面から打ち返すと相手も凹むから、 ちょっと斜め下くらいからの言い方と か日頃のキャラとか信用貯金とか
 重要ですよ
  71. 71. 相手の気持ちを考える 相手の立場に立つ よく聞く言葉だけど重要
  72. 72. カッコつけすぎない
 でもカッコはつける
  73. 73. できることをやる
 できることを増やす
  74. 74. リーダーの資質と して一つだけあげ るとしたら? ->「明るいこと」
  75. 75. 野中郁次郎先生いわく、
 リーダーに相談に行っ て暗くなって帰って きてどうする。 https://twitter.com/hiranabe/status/299668596639035392
  76. 76. たのしく開発しよう たのしいと効率がいい もっと開発ができる
  77. 77. たのしいは目的じゃない 結果というか状態?
 度合い?
  78. 78. アジャイルは名詞じゃ ない。アジャイルは形 容詞で、身軽に行動す るってことなんだ —DaveThomas
  79. 79. "Agility" is degree —Kakutani Shintaro
  80. 80. “アジャイルさ" とは プロセスがどれだけ
 いきいきしているかを 示す度合いである。 —Kakutani Shintaro
  81. 81. アジャイルさ = たのしさ
  82. 82. たのしいとは、 状況である。 関わる人が気持ち良く動ける
 効率の良い状態を維持した状況である。
  83. 83. なんかフツウ それがいいんです
  84. 84. フツウのことを
 フツウにやっていく フツウを増やす
  85. 85. フツウは文脈によって 変わる チームで文脈を作って いけたらいいなあ
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×