この記事はモブプロ Advent Calendar 2017 12/11の記事の続きです。
できれば昨日の記事を読んでから読んでみて下さい。
11月から１ヶ月ほど、初モブで効果を体感し、是非継続しよーとなって、１日平均１時間くらい、コツコツ１ヶ月ほどやってきている。最近、普段離れて働いてるメンバーが一堂に会する機会もあったので振り返りをしてみた。その結果を書いてみる。
What's Mob Programming
これは私が下手に説明するよりは、是非@TAKAKING22さんの記事やスライドを見て欲しい。彼とそのチームは、私の知るかぎりもはやモブしかやっていない、（多少語弊はあるが）それだけで食ってるジャパンモブ界のパイオニアだ。私（達）は多分に彼らの影響を受けていて、蒙武神様と呼んで崇めているとかいないとか
12/23発売のWEB+DB PRESS Vol.102にも記事が載るそうですよ。楽しみ
あとこれはおさえておきたい
仕事を複数人に分けるのは効率的である、という根拠はどこにあるのか？
この一文は我々の凝り固まった偏見にドロップキック 衝撃的である
MS牛尾さんより愛をこめて
Summary
昨日から再掲になるが、我々は、私含め3人が東京、2人が福岡常勤のリモートチームで、担当プロダクトは、社内向け業務ツール、ウェブアプリやライブラリなど10数個あり、全員で1つのプロダクトの開発というわけではなく、各自のスペシャリティを鑑みて担当を決めている。手が足りないときはサポートするスタイルだ。スクラムで２週間のイテレーションを回しているが、下のボードのように、タスクも各自にアサインされている。
ただ、その中でこのチケットはちょっと難しそうだからサポートして欲しい。じゃぁモブでやろうか。みたいなノリである。
Principal
簡単なルールは下記の通り
- 1-2時間/日 各ローカル毎に実施
- 1-2時間/週 リモート接続して、全員でやる
- 2人のときはペアプロ
- 他のタスク優先OK トイレとか退席OK 気乗りしない時は逃げてOK
- MTGは入れない方がいいけど誘われたらOK 個人作業はできるだけ別の時間でできるよう調整
- Git flowは変えない（将来的には変えたい）、コードレビューは基本2人以上の承認が必要だが、3人以上でMobすれば顔パス
- 何か気づいたこととか思うことあれば共有メモに書いていく
Retrospective
で、1ヶ月やってみてまたKEPTで振り返ってみた
Keep
- 生産性は高いと思う
- 複数人の頭を使って問題を解決できる
- 毎回新しい知見を得られる
- 適切な人数
- 3人がベスト（1ドライバー、2ナビゲーター)
- ファシリテーターは特に必要ない
- 仕様がガチガチに決まってれば個人タスクか少ないメンバーでもいい
- スクラッチでやるときは多めがいい
- もし2人（ペアプロ）だと、、
- 心理的なストレスがありそう
- 3人以上だとだいぶ軽減される
- 効果的ではない
- 心理的なストレスがありそう
- もし人数が最適だとして、どれくらいの時間やるのがいいのか？
- 1時間/日
- 自分のタスクに費やせる時間とのバランス
- 自分の生産性はmobの方が高い
- 他のタスクがなければ全部Mobでもいい
- 自分のタスクに費やせる時間とのバランス
- 1時間/日
- 手戻りがない
- レビューがない
- 双方にメリット
- 仕様書やドキュメンテーションでも適応できるのか？できそう
- １つのプロダクトだと全Mobでもいいかも
- 会議室やプライベート空間が理想
- 周りにうるさくないかな。と気を使ってしまう
- 周りの音とか動きが気になる
Problem
- 生産性が高いかがわからない
- 人数が増えた場合、効果やメリットが線形的に増えるのか疑問 限界点が3人くらいじゃない
- スキルセットによってもかなり変わる
- 皆の時間を使うことに対してなんとなく罪悪感
- スプリントで回してるから、タスクが各自にアサインされていて、全員で1つのチケットを というのは少しやりづらい
- リモートだと若干タイムラグが気になることがある
Try
- １つのプロダクトだと全モブでもいいかも
- イテレーション２週のうち最初の１週を全モブでやってみる？
- ドキュメンテーションでもTRY
- 他のチームを巻き込む
- 福岡はそもそも2人だから、目の前に座ってる別の部署の人とか、、
- カファエテリアでモビング
- いい椅子
- おいしいコーヒー
- リラックス
- このレポートを共有
- 別のチームへ
- 部会で
- 公式 tech blog
- 定量評価
- ストーリーポイント？
- 1つのプロダクトに集中できればわかりやすい
- バグ出現率
Conclusion
その他感じたこと
心理的安全
私にとって一番大きかったのはコードレビューの心理的・物理的ハードルが下がったこと。自分がレビュワー、レビューイ、いずれのケースにおいても、準備とか変な心構えとかが必要ない。忖度も必要ない。皆が常に承認しあっている。幸せなことだ。
API実装時の破壊力
はそこまで無かったｗ そもそも、我々はモブでAPIを実装するケースが少ない。というのは仕様（インターフェース）が明確になってるケースが多いのと、前例（コピペ元）がそこらに散らばっているから相談すべきことが意外と少ないような気もする。
というよりは、テキストベースな実装は皆で画面共有してやる際の見た目のインパクトにかける というところかもしれない、、
UI実装時の破壊力
これはもうモブの破壊力が抜群に高い。最も限りなく正解に近い。
何より我々はデザイナーでは無く、フロントエンジニアでもなく、Reactのスキルに至っては全員経験３ヶ月未満の完全ポテンシャル採用試用期間中だ。
フロントの実装においては猫の手も借りたいハンドハンガー。しかし、３人寄ればなんとやらで、５人寄れば革命的で、そしてUIというのは多分に皆の意見を集約したほうがいいものができる。何より楽しい。まさに動くソフトウェアがそこにある。「動いた！」を共有できて楽園ベイベー。
Future Plan
色々試してみてまた日々改善しながらやっていくのだが、今後やってみたいこと
パラモブ
2PC、2モニターでフロントとAPIを同時実装する。幸いチームの人数は5人いる。1人をフリーマンにするか、3人のNavigatorに対し2人のドライバーがパラレルに手を動かすのか、、方法はわからないが混乱しそうで楽しそうだｗ
モブ固め打ち
スプリントの前半を全モブ、後半は適度に個人タスク。
これはもはやハッカソンに近い。楽しいに違いないが毎日やる体力はないかもｗ
コラボ
他チームのモブに参加する。全然関係ない人を巻き込む。
評価
定量評価したいね なんてTRYもあったけど、それよりもproductive vs. effective ということについて考えていきたい。
これはモブに限らずだ。そもそも自分たちがどちらを目指したいのか、そのためにモビングや他のメソッドをどう選択していくのかを常に模索し続ける必要がある。
というわけで2日に渡り私達のチームの事例を紹介しました。また色々と試して、より日常的にやっていくか、はたまたスーパーモビングメソッドを編み出すのか！？ 楽しみながらやっていきたいと思います。