この記事について
モブプロをやってみたという記事はよく見るので、その前段階として「やり始める前に考えたこと、やったこと」をまとめ、これに則ってモブプロを始めてみようと考えています。
実際に始めてみたらまた別の記事を書くかもしれないです。
「モブプログラミング・ベストプラクティス」を参考にしています。
チームメンバー全員がこの本を読んだ上でモブプロしていきます。
1. なぜモブプロをやるかを決める
- リソース効率ではなくフロー効率をあげたい（詳しくは本を参照）
- 知識の偏り（属人化）の解消
- 全体の技術レベルの向上
- それぞれが知っていること、知らないこと、考えていることを知りたい（個人の暗黙知の共有）
2. チームをあらためて把握する
チームの状況、状態を知る
- 心理的安全性は高い
- 心理的安全性が高くなるまでのことはこちらに書きました
- スクラムっぽくやっているが、SBLが途中で変わることはよくある
- 緊急的な対応が多い（お問い合わせ、作業依頼、障害の対応）
チーム、チームメンバーの性質を知る
性格診断・ビッグ5
ビッグ5は無料診断がいくつかあるみようです。探してみてください
今回は簡易的な無料診断をしてみました。
（外交性はあまりモブプロにおいて大きな役割を果たさないらしい）
結果を見て、このチームにおいては次のようなことを注意してモブプロをしていこうと思っています。
- 協調性が高い
- 逆に言うと対立を恐れ、議論を避ける可能性がある。そのような状態が見えたら策を講じていく必要がある
- 開放性が高い
- どんどんやってこ！
- 真面目さが高いが、とても高い人がいる
- 全員が主体性を持って取り組みを続けられるように、バランスを取っていく
（診断に簡易的すぎるものを選んだのは少し後悔しています）
４Dシステム的な何か
（comming soon？）
3. どのようにやるか決める
参加メンバーを決める
バックエンドエンジニア4名。
いずれフロントエンドエンジニアやQAエンジニアなども含めることを検討。
周期を決める
まずは週1、2時間から。徐々に週1日にしていきたい。
（やってみてから考える）
タイムテーブルを決める
- 初回のみなんかやる
- 10分ごとにタイピストを交換する
- 交換する際に git push
歓迎行動を決める
- 全員で問題解決のために努力する
- 人ではなくコードを批判する
- HRTに則ったコミュニケーションを心がける
- 他のメンバーの意見を聞く、意見を避難しない
- 疑問に思ったことはきちんと質問する
あえてセオリーに反しようと考えていること
- 共通のIDEを使わない
- 現状全員違うものを使っているため、すぐには難しい。それぞれのIDEの使い方を見るのも参考になるのでは？と思っている
- 個室がない
- 半個室状態でやってみる