モブプロ始めました（真冬）。
[イノベーター：経緯とか]
2017年の6月頭くらいに、社内SNSでモブプロに関する投稿を見た。
多分シェアされていたのがこの記事だったと思う。
自販機を作る中で、対応して欲しいと言われる要望がどんどん増えていく様は、実際の開発現場での事例をイメージしやすいので、実プロダクト以外でモブプロのテーマにするのに良さそう。
ともかく、上の記事を見て、モブプロをやりたいと思ったので、とりあえず社内SNSに書き込んでは見た。
すると同じように思っていた同僚（全然違う部署、当時は面識なし）から返信がもらえた。ので、いいじゃんこのままやっちゃえ、と思っていた。一応、自販機を作る課題でやるとして、追加仕様をどうする？とチャットで5分くらいやり取りはしたものの、面識がないのが災いしたのか、お互い仕事が忙しいのを言い訳にしていたのか、夏の暑さにやられたのか、6月以降目立った進展はなかった。
とはいえ、モブプロのことは頭の片隅にあって、なんとなくやりたいな、と思っていたある冬の日、何気なく手に取った雑誌の特集記事がモブプロだった。
しかも「はじめての」とある。
これは買うしかない。
読むしかない。
そういうわけで、買って、読んだ。
そうこうしているうちに、Podcastでもモブプロの話題が目につくようになった。
同じくらいに、Speaker Deckで特集記事の著者である及部さんの記事を見つけて、それらも読んだ。
あ、これはやるしかないな、と言う気分が高まってきたのと、なんとか今のチームでモブプロをできそうな雰囲気もあったので、とりあえず初めてみることにした。
[種をまく：準備段階]
初めてみるとは言っても、こっそり初めてこっそり終わっても面白くないので、色々と予防線を貼ったというか、準備をした。
内容としてはこんな感じ。
そもそもチームメンバーには1月頭くらい前からモブプロやるぞ、と伝えていた。
中にはペアプロの存在を知っていて、ある程度は何をやるのかイメージできていそうなメンバーもいた。
一方で、ペアプロも全く知らないメンバーもいた。なので、雑誌記事、ポッドキャスト、スライドシェアなどを参考にしながら、モブプロはこんないいことがある、それを自分は達成したいんだということを伝え、「失敗から学んで強いチームになる」という方向性を揃えるために、資料を作ってLTして、実戦に至った。
やるぞ、と伝えてからそこそこ時間がかかったのは、その間に大きな締め切りがあって、LT資料を作る余裕もモブプロをやる気力もなかったという事もあるし、チームメンバーに自発的にモブプロについて調べて興味を持って欲しいとも思ったからだ（結局興味を持って調べたかどうかは確認していない）。
今になって振り返って見ると、このあたりの行動は『Fearless Change』のパターンに当てはまってるものが多くある。
Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン
- 作者: Mary Lynn Manns,Linda Rising,川口恭伸,木村卓央,高江洲睦,高橋一貴,中込大祐,安井力,山口鉄平,角征典
- 出版社/メーカー: 丸善出版
- 発売日: 2014/01/30
- メディア: 単行本（ソフトカバー）
- この商品を含むブログ (16件) を見る
実戦投入できたかな、と思えるのがざっとこの辺り。
[やってみる：実戦投入]
LTを済ませて、チームメンバーの動機付けも十分にできた（と判断した）ので、場所を抑えて実際にモブプロをやってみることにした。
テーマとして選んだのは、先月のリリース内容について見つかった軽微なバグから始めることにした。該当のバグについての記憶も新しいし、多分1時間くらいで実装からテストまでを完了できるだろうと見積もったからだ。
用意したノートパソコンのネットワークが繋がらないなどのトラブルに見舞われたが、おやつを用意した事もあってか、全体としては和やかに終えることができた。
流れとしては以下の通り。
- 準備（15分）
- モブプロ（75分）
- 振り返り・後片付け（30分）
モブプロ開始が若干遅い時間だったことや、スペースの予約の都合もあったので、あまり長くはできなかったのが残念。初回なので、あまり負担にならないように、という意図もあったので、今回はよしとする。
この部分のFearlessポイントは
- 小さな成功
- 何か食べながら
- やってみる
あたり。
[ふりかえりの時間：学んで、強くなる]
「失敗から学んで強いチームになる」を目標にしているので、失敗から学ぶべくモブプロの最後に振り返りを実施した。
<Keep>
- 楽しい。チームの結束強化された
- 一人で調べて案件やるより明らかに速く仕上がった（3倍以上。当社比。）
- 他のメンバーの書いたコード見る機会なかったが、保守対応できそうな自信がついた
- なんとなくライブラリの使い方分かってたつもりだったが、すぐに利用例だしてもらえてよかった
- 自分だけが分かる変数名、クラス名じゃダメ、他の人も分かりやすい命名にしたいと思った
前提として、新しい製品機能を、新しいチーム（自分以外新人ばかり）で作っているというのがある。そのため、ある程度開発経験のある開発者ならなんでもないと思えるようなポイントでも、彼らにとっては学びとなったようだ。
次は、実際に保守対応をしたり、より意図が伝わりやすい命名のコードを書いたり、学んだことをガンガン実戦投入して行って欲しいと思う。
<PROBLEM>
- 案件の実装が終わらなかった
- ドライバの環境他の人のPCだとやりづらい（ブラウザ、IDE）
- ドライバしゃべらなすぎ、ナビゲータ（自分）がしゃべりすぎ
- ドライバやれなかったのでつまらなかった
- Teletype for Atomを使わなかった
- 「やったー」をやれなかった
- おやつはチョコレート系じゃない方がいいかも
ドライバの環境については慣れている環境でモブプロできるように、色々と越えるべき壁がある。
つまらなかったという感想は、時間の制約もあったとはいえ謝らざるをえない。次回のモブプロで優先的にドライバをやってもらうこととする。
楽天の事例で紹介されている、小さな成功を祝う「やったー」をできなかったのが痛かった。微妙に実装が終わりきらなかったこと、気恥ずかしさに負けてしまったことが要因と考えられる。次回はこれを確実にやりたい。
Teletypeは、WEB+DB PRESSでも紹介されていたので知っていたのだが、AtomはJavaの開発向きではないのでは？と思ったので今回は外した。そのうち試してみて、Javaでも使えそうだったら、あるいはJavaScriptで開発する案件でちょうどいいのがあれば、使ってみたい。
Teletypeが使えるなら、他のチームの有識者が参加したいと言ってくれているのでできれば積極的に取り入れていきたいところ。
と言うわけで、ここでのFearlessポイントは、
- ふりかえりの時間
- 感謝を伝える
- 次のアクション
のあたりだろうか。
[まとめ]
『Fearless Change』で紹介されている、組織変革の序盤の活動に関わるパターンをある程度実戦投入できた。
↓の記事で掲げた「リーダーとしての実戦投入力を高める」の一環として、まずはこの一ヶ月は順調な滑り出しと言えるだろう。
とはいえまだまだ始まったばかりだし、たった1回のモブプロでめちゃくちゃ強いチームになるなんてことはあるわけがない。
来週以降も継続していく。 すでに社内のミーティングスペースは確保した。
