チームを作るモブプログラミング 内側と外側から語る

チームを作るモブプログラミング　内側と外側から語る

自己紹介

アジャイルコーチ

• やっとむさん
• テスト駆動飲み会を2月26日 ​

  デンソーのエンジニア

• 及部さん
• モブプログラミングを教えにいってる
• シルバーバレッットクラスというチームをやっている
• ユーチューブとPODCASTを今日からはじめた
• モププロ講座を開設予定 ​

  モブプロの紹介

  ​

  モブプログラミング

• ハンダーインダストリー社の紹介
• エンジニアプラクティスだけでない
• 仕事を分担するより効率わるいと思われがち
• チームをブーストと仕事をドライブの２つ視点で説明 ​

  聞き方

• 興味があることだけ聞いてください
• ショートトークとクロストーク
• 質問と対面形式でやる ​

  モブプロ説明

  ​

  モブプロの本紹介

• モブプロのやり方を説明している本
• みんなが共感することから始める ​

  目的とゴールを定める

• 今われわれはなんのためにモブしているかをはっきりとする
• 新しい人の学習、来週のリリースか、ライブラリ共有か
• 今日はどこまでいくかのゴールまず定める ​

  進め方

• 目的はこれでいいですか？ではだめ。みんなで決める
• 進め方を表明する ​

  道具

• TODOリストを最初にあげておく
• 作業の区切りを確認する
• ドライバーがしゃべる（もくもくとコーディングしない） ​

  議論と実験のバランスを取る

• モブでは議論が大事
• リーダーが全部決めるはダメ
• 議論も大事だがためすのも大事
• 結論は出ていないが試すのが大事
• 最初は議論＜＜実験くらいの気持ちで、実験が大事 ​

  いいところ

• その場でフィードバックがもらえる
• ビルドパイプラインとおったか、画面確認等、その場でできる
• 品質、テスト、リファクタリングをその場でやることが有効
• 品質控除、楽しい、学びを得る ​

  その場でフィードバックを得る

• テストでなんかあってもその場で得ることができる
• モブ作業を終えたら振り返りをする
• よりよりプロダウトをめざす
• 障害物が出てくる ​

  個々の人のペースでやり取りする

• 復習する時間を設ける
• セッション後に一定時間を確保する ​

  クロストーク

  ​

  ネガティブな反応をされたときは

• まず二時間だけやってみないかと提案する
• チーム外部の人をまきこんでみる
• 外で体験した人の話を入れる ​

  とはいえ個人作業したいといわれたら

• 個人んでやるのはよい
• ただまずはモブをやってみてほしい
• この人は１人のがよいなどの発見がやるとわかる
• モブプロはやってみて体験できることがある
• ハンダーインダストリー社の動画紹介 ​

  チームをブーストするモブプロ

  チームの内側を強くする

  ​

  スキルトランスファーの話（知識移転）

• 経験値高い人がドライバーだとすごく進むが、意見交換しずらい
• 入ったばっか人がやる方が、ジャストインタイムできけるから
• 教育的なことを意識してやるが、意外とわかっていない人がほかにいるので、スキルを伝搬しやすい
• SECIモデル
• 暗黙知もまとめて伝える（形式知になっていないもの）
• コードの組み立て方、ツール、何をどうやってなぜつくったか、問題解決の方法などがこれにあたる ​

  モブとレビュー

• レビューおじさん問題
• スキルアップをするとコードを書く時間がへる
• モブだとこれが改善できるコードがかける ​

  レビューの目的の３分類

• ナレッッジ、品質、リファクタリング ​

  モブプロがカバーできること

• リアルタイムレビューができる
• チームの合意がとれている
• 忖度せずチームのベスト
• タイポするとすぐに指摘される
• 検査、学習、強化のうち、強化はあまりカバーできない
• カバーするために振り返りにちかいレビューをやる ​

  モブ弱み

• その場の熱が誤ったコード
• 局所最適に陥る ​

  レビューの弱み

• 忖度がうまれやすい ​

  中長期的な目線で捉える

• 初期はモブを多めにやってチーム文化を醸成
• うまくいけばソロ,ペアでやって、属人化は避ける ​

  質問

  喧嘩になりませんか

• 仲が悪いとそうなる
• 大事なのは議論は悪いことではない
• ちゃんと伝わる言葉で無駄な喧嘩になりそうな言葉は避ける。ふざけない ​

  わからないですっていえない

• スキル差が多い時は、一時間で休憩とって復習する時間をとる
• 自分の知識をうまく渡せる場所なので、みんなの成長を優先する ​

  仕事をドライブするモブプログラミング

  仕事をドライブするとは

• ソロワークよりも優れた成果が出せるモブ
• かいた行数とか実装工数で評価するとモブプロの良さがない
• 単縦な生産性だとモブの良さは測れない
• よりユーザのニーズをくんだ仕様ができたなどが、より成果のでるモブプロ
• 単純作業をモブでやっても効果は薄い
• 仕事の分担がすでにされた開発内容 ​

  モブに向いているケース

• スクラッチ開発で２ヶ月弱の工数
• メンバーがいるけどパートタイム
• モブが初めてだったり、チームの仕事が初めての場合
• ユーザがすぐそばで待機している状態がモブの良い形 ​

  仕事かチームか

• 詳しい人はナビゲータをするべきだが、仕事を意識すると、ドライバーをやったほうがよくなってしまう
• 仕事をドライブをするか、チームをブーストするか
• どっちによせるか
• 仕事をドライブをするー＞１人でやってるのと同じ
• チームをブーストするー＞研修 ​

  仕事をドライブするモブ

• 最初はどっちつかずになる
• モブプロが上手になると、両方を重視した最高に生産性が高い状態になる
• 最初は、GITの使い方の基本的な話になるが、モブを継続してチームをブーストすると、ハイレベルな設計士の話などに発展
• 能力と責任の２軸でバランスを取る
• 仕事が快適になると学びが低いので責任度合いをあげる
• 心理的安全性が必要ー＞言いたいことがいえる状況を作る
• タスクの不確実性、リソース不足があっては心理的安全性とはいえない ​

  質問２

  やっぱり仕事を分担するほうがよいのでは？

• 単純作業をやるならモブは不要
• 人数が多すぎるとモブは無駄になる
• 短期的にみると確かに非効率だが中期的に見る
• チームの成長を考える
• モブの成果とは何かをちゃんと定義するー＞できたプログラムの行数じゃない ​

  ほどよい学習状態とは？工夫することは

• チームが安定した状態がそんなにあるだろうか
• パッケージ互換性、仕様変更とかいろいろ安定しない要素はある
• なにか問題があったらモブで取り組む気持ちでいくと
• 実はトラブルが起きていることに気づく
• もしほんとうに問題ないなら、人工的に作る
• 外部から学びを得る機会をえる
• ラーニングセッションを取り入れる ​

  コーチ目線でモブが使えているチーム特徴とは？

• みんながしゃべる
• ドライバーをみんながやろうとする
• マネージャとかがほっといてくれているチームがモブをうまくできている ​

  最後に

• モブというかチームの話なんです ​

  モブプロの全体像

• チームの内側と外側を考える
• チームの内側と外側のバランスー＞タックマンモデル
• 大事なのはモブが難しいと思うかもしれないが、モブプロでなくてよい
• モブプロ＝チームワーク
• 大事なのは場面場面で最適な選択肢を行うこと
• チームワークとしてのモブプロを使ってほしい
• 一緒に行動することではなくて、自分たちで選択して、自分たちでやめたり、実施したりする
• 相互主観ー＞みんなで同じものをみて、お互いの見かたを共有するてこと？＜ーむずかしい