こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。
会の概要
天野さん家永さん木下さんのアジャイルコーチお三方が、視聴者から寄せられた悩みに対して色々と答えていく会です。
今日のテーマは、「ペア・モブ作業のはじめかたは？」でした。
会の様子
ペアプロ・モブプロの解説
の記事をもとにしながら、ペア作業とモブ作業の説明を聞いていきました。
家永さんは、ペア・モブワークによって信頼関係がチームで構築されていくところが非常に好きだということで、まさに当日も木下さんにメール送信のペアワークをしてきたということでした。
ペアワーク・モブワークの具体的なやり方(オンライン)
VS Codeのプラグインを使ったり、一つの画面をみんなで確認する(Zoomの画面共有など)ことが多いそうです。
家永さん的には、まだその仕事に慣れていない人が問題解決までの過程を見ることができるのでおすすめしているそうですが、長期的にこのやり方を続けてしまうと、特定の人のみに経験が偏ってしまうため、注意が必要だということでした。
なお、練度が高くなってきたチームでは、タブの使用方法や画面配置のベストプラクティスが確立されていたのを見たことがあるというお話も出ていました。
ペアワーク・モブワークの具体的なやり方(オンサイト)
キーボードやマウスは一台にしておくことが前提で、baby stepでゴールを達成したときにはハイタッチやバンザイで盛り上がるようにしているというお話がありました。
また、やや細かい話ですが、キーボードを真ん中に一つ置くと変な姿勢でタイピングする必要に迫られるため、非推奨だそうです。
ペアワーク・モブワークの具体的なやり方(共通)
また、ペアワーク・モブワークを行うときは、テストを活用して共通ゴールを定義するようにするとよいというお話もありました。
ペアワーク・モブワークをするために説得
まず、そもそも許可を求める必要がないものなので、そこに許可や説得が必要だったりする状況自体がおかしいということです。
説得が必要になっている状況は、スプリントゴールが未達だったりとペアワーク・モブワーク自体というよりはチームのパフォーマンス全体に不満を持っている場合が多いという話が出ていました。
他にも、ペアワーク・モブワークという言葉ではなくレビューという言葉に言い換えてみたりすることもあるというお話がありました。
ペアワーク・モブワークで陥る罠
まず、問題がぶつかった時に、うーんってなった後に別々に作業や調査を開始してしまうことがあるそうです。
問題解決のための調査こそ一緒にやるべきだと木下さんは考えているそうで、そういうときは「独り言をいいながら調査するように」とアドバイスするそうです。
また、先輩が後輩に「え、こんなのもわからないの？」と言ってしまって萎縮させないように注意してほしいというお話も出ていました。
会全体を通した感想
職場に恵まれていたこともあり、「ペア・モブ作業やろうよ！」で始める意外の発想をこれまで持ったことがなかったので、より細かいステップでペアワーク・モブワークを進める引き出しが増えてよかったです。
ペアワーク/モブワークの禁止を命じられた経験をベースにしたアドバイスは、特に刺さりました。
