初めての本当の意味でのチーム開発 / pmjp 2016-12-03

by yuma iwasaki

Slide 1

Slide 1 text

初めての本当の意味でのチーム開発

Slide 2

Slide 2 text

自己紹介 @suthio_ 株式会社Speee ネイティブ広告の配信システムを作っている

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

agenda 一年間やってきたこと開発開始リリース後メンバー追加いいチームとは？なぜチームが必要なのかいいチームとはいいチームを作るために

Slide 5

Slide 5 text

一年間やってきたこと

Slide 6

Slide 6 text

今年1 月、新規事業の開発リーダーを任された

Slide 7

Slide 7 text

当時の自分の状況エンジニアとして、自分よりもメンバーの方がエンジニアリング能力が高い状態（Scala 、Golang をメインに開発しているのに自分の得意言語は Ruby ）今までチームのことなんか考えたことないし、自分が頑張って開発してなんとかしてきた個人技の組み合わせがチームだと思っていて、チーム開発とかスクラムとかでうまくいくとか全然信じていない

Slide 8

Slide 8 text

結局どういうことか結局、自分が一番のプレイヤーのプロジェクトしかやったことがないマネジメントとかチーム開発を一切学んでこなかったそもそもそういったことを考えたこともなかった

Slide 9

Slide 9 text

そんな中

Slide 10

Slide 10 text

開発リーダーを任せられた

Slide 11

Slide 11 text

その時の状況エンジニア4 名（僕を含む）、PO 1 名 1 月開発開始要件ふわっとしてるなのに構想という名の夢が存在なぜか3 月にリリースすることが決まっている

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

チーム状況リリースを終えて疲弊している属人性が高く、○○ さんが居ないと修正できないという状況日々、積み上がっていくIssue

Slide 18

Slide 18 text

非常に良くない状況

Slide 19

Slide 19 text

今までだったら自分が頑張ることで大体は解決できていた

Slide 20

Slide 20 text

自分が頑張ることで解決できる部分が少なく、わからない部分も多かった。

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

チーム運営についての提案も出てきたタスクをポイントで見積ろうイテレーションで区切ろうユーザーストーリーを作ろう

Slide 32

Slide 32 text

結果的にスクラムっぽくなった

Slide 33

Slide 33 text

5 月からはプロジェクトとして、スクラムをやっていると言うようになった

Slide 34

Slide 34 text

メンバー追加

Slide 35

Slide 35 text

メンバー追加今まではほぼ初期メンバーのみで開発をしていたので、技術的負債の経緯や今後の動きについて、共通認識が取れていた新規メンバーと共通認識をとったり、背景を説明する必要が出てきたそれまでは初期のメンバーのみだったら問題なかったが追加で入ったことで背景理解がないまま意見を言うことが多々あった。（プラスの意味でもマイナスの意味でも）その頃、僕はチームメンバーが目指すべき方向性が揃ってない感を感じていた。

Slide 36

Slide 36 text

今までは作った経緯とかが共有されている状態だったけど、共有されてなく、システムの詳細知識がない人が入ってきたため、方向性が揃ってなかった。

Slide 37

Slide 37 text

その時、タスクの粒度がバラバラになっていることに気づいたため、いいタスクとはなにかということを定義することにした。

Slide 38

Slide 38 text

いいタスクとはなんだろう？

Slide 39

Slide 39 text

考えてみたけど決まらなかった

Slide 40

Slide 40 text

逆に悪いタスクについて考えてみた

Slide 41

Slide 41 text

悪いタスクとは？やることが不明確誰がやるか不明確やることが多い、タスクが大きいタスクが小さすぎる期限、優先度がわからない工数が見積もりずらい複数人の対応が必要

Slide 42

Slide 42 text

悪いタスクとは？目的がわからない関連するタスクがわからない関連するタスクの担当者がわからない進捗がわからない完了の定義が不明完了した後の対応がわからない

Slide 43

Slide 43 text

この悪いタスクじゃないタスクをいいタスクと定義することにした

Slide 44

Slide 44 text

新しいメンバーには適切細かい粒度のタスクを渡して、チームに慣れてもらうことで、方向性がすりあっていった

Slide 45

Slide 45 text

このプロダクトの開発を通して本当のチーム開発というものを初めて学んだ

Slide 46

Slide 46 text

いいチームとはなにか？

Slide 47

Slide 47 text

なぜチームというものが必要なのか

Slide 48

Slide 48 text

なぜプロダクトを作るのかなんらかの課題を解決するため。プロダクトを成功させるためにプロダクトを作っていると言っても過言ではない。プロダクトを成功に必要な課題解決は個人一人だけでは実現が困難なものが非常に多い。 ※ なにを作ればいいということがわかっていたとしても。

Slide 49

Slide 49 text

なぜチームというものが必要なのか個人では実現することが困難なものに対して、複数人で分担することによって、解決する可能性が上がるためとはいえ、ただ複数人を集めただけじゃ本当の意味でのチームではないチームでやることのメリットもあるけど、デメリットも当然あるので、メリットを最大限活かせる方が良い

Slide 50

Slide 50 text

いいチームとは

Slide 51

Slide 51 text

いいチームとはチームが向かうべき方向性がはっきりしていて、チームメンバーも方向性を理解しているチームメンバーが積極的に意見を言える状態であることチーム全員が適切に責任を持てているチームがステークホルダーから信頼されている継続的に素早く改善が行えていること

Slide 52

Slide 52 text

向かうべき方向性の統一チームの向かうべき方向性を合わせることがすごく重要どんな機能を作って欲しいか伝えるよりも、どういう体験をユーザーに与えたいかを伝える

Slide 53

Slide 53 text

ファシリテーション MTG 時に議論を拡散させすぎない。答えを言わずに自分達で気づいてもらえるようにする決定事項など大事なことは何度でも繰り返し言うようにする

Slide 54

Slide 54 text

チームメンバーにどうやって動いてもらうか人間は得をする方、損をしない方に動く ○○ をすると得をするものという状態にしてから、得だということを認識させる。また、やらないと損という状態をどんどん作っていく。どんどん巻き込ませて、責任を与えていく。意見が言いやすい環境を作る意見を言ってもマイナスならない状態を作る場を用意する

Slide 55

Slide 55 text

ステークホルダーとのやり取り対立する形は良くない技術ではなく、結果どうなるかということベースで話す重要事項については何度も相手がわかるように確認自分も相手がやりたいことについてきちんと理解する

Slide 56

Slide 56 text

素早く改善必ず開発を止めるタイミングを作る（振り返り、その他MTG 等）積極的に意見を求め、少しずつでもいいので改善

Slide 57

Slide 57 text

その他やっておくと良いこと焼肉ランチ飲みに行く

Slide 58

Slide 58 text

焼肉ランチ新しいメンバーを迎える際は焼肉ランチに行くこれを儀式と言っている同じ網の上で肉を焼くという行為がなんかいい感じするなにより、おいしい

Slide 59

Slide 59 text

焼肉みやび https://tabelog.com/tokyo/A1307/A130702/130958 90/

Slide 60

Slide 60 text

飲みに行く相手のことがわかり、距離が近くなるこだわりポイントがわかるその人の折れる部分、折れない部分がわかる

Slide 61

Slide 61 text

チームとは結局は人の集まり相手のことを知って自分のことを知ってもらって相手と自分にとって一番いい方法を探す