わかった気になるモブプログラミング いも 1

モブプログラミングとは？ その前に、ペアプロについて話さないといけない 2

ペアプロ(ペアプログラミング)とは ⼆⼈で協⼒してコードを書く ドライバーとナビゲーターに役割を分ける ドライバーがコードを書き、ナビゲーターがサポート 適時休憩を挟み役割を交代する 3

モブプロ(モブプログラミング)とは 3⼈以上で⾏うプログラミング コードを書く⼈(ドライバー)以外はナビゲーターとなる モブだったりナビゲーターだったり⾔い⽅はばらけてるかも ドライバーとナビゲーターの役割はペアプロと⼀緒 適時休憩を挟み役割を交代する 4

モブプロの効能 属⼈性の排除 チームとしての練度向上 リードタイムの向上 5

モブプロの効能 属⼈性の排除 ← チームとしての練度向上 リードタイムの向上 6

属⼈性は分担作業で起こりうる この部分はAさんがやったから・・ 実際に携わってないのだから本当にAさん以外わからない可能性はある 得意領域はあっても完全に任せるのは⾟いことになる モブプロは全員でコードを書いていくので、全く知らない部分を排除できる 7

モブプロの効能 属⼈性の排除 チームとしての練度向上 ← リードタイムの向上 8

プロダクトの情報を共有できているチームは良い動きができる。 何故これを作ったのか？ どうやって作ったのか？ どんな問題が発⽣したか？ どんな学びがあったか？ これ以外にも、成果物だけを⾒ても理解しにくい暗黙知が存在していることは多い。 9

暗黙知は過程に存在する ⾔語化しにくい気づき、改善 それぞれが持っている知識、強み これらを全員が体験できるような場が重要 10

imoがモブプロで実際に体験したもの 「実はこういう経緯で作られていて〜」という裏情報を教えてもらう 実装の影響範囲の洗い出しに⼀役買った ちょっと改修すれば動くデバッグ機能を教えてもらう VisualStudioの便利機能を教えてもらう Windowsのスクリーンショットのショートカットを教える どうテスト書いてくかという考え⽅を教える 相⼿のコードを読むときの⼿順を知る ⼤⼩様々だが、作る過程を知らないと気づかない部分が多かった 11

モブプロの効能 属⼈性の排除 チームとしての練度向上 リードタイムの向上 ← 12

Q.モブプログラミングって効率いいの？ A.なんの効率のことでしょうか 13

効率とはなんなのか リソース効率性 フロー効率性 14

リソース効率とフロー効率の話 複数の仕事がある場合に、どう⾏動するか？ それぞれ15⼈⽇かかる機能A,B,Cがあったとする。 並⾏か？ -----------------------> 時間軸 AAAAA AAAAA AAAAA BBBBB BBBBB BBBBB CCCCC CCCCC CCCCC 集中か？ -----------------------> 時間軸 AAAAA BBBBB CCCCC AAAAA BBBBB CCCCC AAAAA BBBBB CCCCC 15

並⾏して⾏う(リソース効率性を求める)場合 複数の機能を同時に進めるパターン -----------------------> 時間軸 AAAAA AAAAA AAAAA BBBBB BBBBB BBBBB CCCCC CCCCC CCCCC ↑の場合だと、どこかの作業が⽌まってもすぐに別機能にリソースを割ける。つまり「リソースの稼働率」が ⾼い(全員に常に仕事がある) しかし、機能開発に着⼿してからリリースされるまでが遅くなる。つまり「リードタイム」が⻑い。 リソース稼働率が⾼いことを「リソース効率性が良い」と判断できる 16

集中して⾏う(フロー効率性を求める)場合 1機能ずつ確実に潰していくパターン -----------------------> 時間軸 AAAAA BBBBB CCCCC AAAAA BBBBB CCCCC AAAAA BBBBB CCCCC 機能開発に着⼿してからリリースされるまでが早くなる。つまり「リードタイム」が短い。 しかし、全員だと⼀時的でもやることがなくなる⼈は発⽣しがち。つまり「リソースの稼働率」が下がる リードタイムが短いことを「フロー効率性が良い」と判断できる 17

私たちはどちらを求めているのか？ 作るものの正解が決まっているなら、リソース効率性を求める⽅がよい リリースすれば確実に成功であるから 作るものの正解が決まってないなら、フロー効率性を求める⽅がよい 早く提供してフィードバックを得て学ぶ必要があるから 学びから正解に近づいていかなければならない ゴールを⾒て話し合いましょう 18

分担作業は同期が必要 作業時間＋悩んだときの質問 質問へのレスポンスタイムはまちまち コードレビュー レビュータイミングでレビュアーは内容を理解する 朝会、報告会etc... チームメンバーの状況を理解するフェーズが必ず必要になる。 同期が遅いとここで⼿戻りなども割と起きうる 19

モブプロは常に同期する 全員でやっているので常に状況は把握している 報告会での「○○やってます」はみんな知っている 悩んだときはナビゲーターが隣にいる みんなで書いたコードなのでレビューしやすい これらのおかげでやるべきことにフォーカスを当てられる。よってリードタイムが短くなる 20

Q.モブプログラミングって効率いいの？ A.フロー効率性を⾼めます 21

やり⽅(1例) 時間は60min やることとゴールを先に決める 「機能Aを実装する」など タスクが切られているなら⼀番わかりやすい コード部分を参加者全員が観れるようにする Zoomで共有 or VS Live Share ドライバーを決める 22

モブプロ開始 TODOリストを作る 何をするのかという認識を合わせる 段階踏んで完了できるようにした⽅が議論が発散しない TODOリストをこなしていく どうやってこなすか話し合う 決まったらドライバーが書く これをTODOが終わるまでループ 15min~20minくらいでドライバーを交代 MobStarというモブプロ⽤のタイマーアプリ使うのもいいかも https://kakakakakku.hatenablog.com/entry/2018/07/01/170255 23

話し合い 基本的には細かいルールはない 変数名はこれがいいんじゃないか？とかこういうオブジェクトの持ち⽅だとか何でも話してほし い 今やるべきことからフォーカスが外れないように注意 議論の発散は起こりがち 議論の結果⼤きめなやるべきことが増えたら、基本的にはTODOリストの最後尾に追加し ましょう ドライバーは話が決まってからコードを書くこと いいの思いついてすぐ書きたくなる気持ちはよくわかる 思いついたやつをまず⾔葉にしてみんなに話しましょう 24

TDDとモブプロの組み合わせ TODOリストがそのままテストケースになりやすい 完了したかどうかはテストが通ればよい なのでレッド -> グリーン -> リファクタのサイクルで1つのTODOを倒せるといい感じ 25

みんなでクエストやってる感じでやりましょう 動き⽅は常に「問題 vs 私たち」 オンゲでギルドでボス倒すとかそういうイメージ 問題をみんなでボコボコにする 倒したときは、みんなで喜びましょう 26

上⼿くいくのか！ やってみないと分からない 常に⼈とコミュニケーションを取るような働き⽅になる 個⼈の性格、相⼿との関係性はモロに出る 普段コミュニケーション取れてない状態で始めるのは多分つらい 疲労感はすごい みんなで作るのは楽しい でも、やってみないとわからないのは間違いない 逐次フィードバックと改善を回していきましょう 27

おわり 28

参考 モブプログラミングという働き⽅ #DevLOVE https://speakerdeck.com/takaking22/mobupuroguramingutoiudong-kifang-number- devlove XP祭り2019 実践！モブプログラミング！！~導⼊編~/How to install mob programming to your organization https://speakerdeck.com/martin_lover/how-to-install-mob-programming-to-your- organization XP祭り2019 実践！モブプログラミング！！~躍進編~/Mob Programming in Practice https://speakerdeck.com/martin_lover/mob-programming-in-practice 明⽇からできる働き⽅改⾰「モブプログラミング」 WHOLE TEAM APPROACH / mobprogramming as work style reform https://speakerdeck.com/takaking22/mobprogramming-as-work-style-reform 29