モブって最高の開発方法やん。めっちゃ楽しいやん！

2019年7月10日 17:46

この記事では現在私が所属するチームで行っているモブでの開発の形をお伝えし、個人開発時代に存在していた課題、そして現在に至るまでのプロセスでどのように課題を解決できたかをお伝えできればと思います。
関西ではスクラムやモブを実施している事例をあまり見ないので、これから取り組もうとしている関西圏の良いベンチマークになればとも思います。

私は RiseUP のモアコンチームでエンジニアをしている上園と申します。
モアコンタクト、通称モアコンは国内最大規模のカラーコンタクト EC サイトで、利用者の80%以上を10代後半〜30代前半の女性が占めるサービスとなっています。

いまは"ほぼ100%"モブで開発してます

モブで使ってる基本装備
PC: MacBook Pro (Retina, 15-inch, Late 2013)
Keyboard: Magic Keyboard US
Display: DMM.make 55インチ4Kディスプレイ
Other: Magic Trackpad

3年前までは社内受託で開発していたのですが、そこからスクラムを導入し、現在はほぼ全ての開発をモブで行うようになっています。

チーム配置はモブでの開発を中心に添えて、コの字型にしています。

Dev, PO そして Designer との距離が近いことで、開発中にでてきた疑問をすぐに話すことができ、そこからデザインを含めた改善にすぐに繋げられるようになったので、とても効率的に開発を進められるようになりました。

この形に落ち着くまでに5回ほど席変えや配置変えを繰り返し、個人作業とモブの往来が頻繁に起きたとしても、コミュニケーションが取りやすい形として現在のコの字型に落ち着きました。

ちなみに現在は Dev の個人作業というものはほとんどなく、ほぼ全ての作業をモブで行うようになっています。

例えばSlackでの会話はモブ用のアカウントを作り、そこでコミュニケーションを取るようにしています。

開発の流れはこんな感じ

開発に入る時は、まずツイスタールーレットでタイピストを決定します。ルーレットに指された人が1人目のタイピストとなり、その後は時計回り順にタイピストを交代していきます。なぜツイスターなのかというと、たまたま会社に余ってたからです。(どんな会社やねん)

いまは10分ごとにタイピストとその他のモブが交代する形式をとっており、だいたい1インターバルは Dev 4人× 2週くらいの時間としており、そこで休憩を挟むようにしています。(大学1講義分くらいは集中して頑張れる)

モブを開始した当初は1人のタイピストのキリが良いタイミングまでタイピストを続けたまま開発をしていました。しかし、正直お昼休み明けや夕方は睡魔との戦いに臨んでいる日もあったため、記憶が曖昧な時間帯もあり、こっそりコミットログを確認した日もありました。

モブプログラミング・ベストプラクティス

この本に出会ったことで10分交代制を導入し、その結果、劇的にメンバーが集中力をキープし続けられるようになったことで、現在は10分交代制をとっています。

この書籍はほんとにおすすめで、モブに初めてとりかかる人だけでなく、経験のある方も改めて勉強になることが多く書かれているので、共通認識を作る上でチーム開発の必読書だと思います。

モアコンチームでは内容を esa にまとめ、内容共有しています。

10分たったら強制終了

タイマーは Just Focusを使っており、タイピストが変わるごとに10分タイマーを起動します。1分前になると通知音で知らせてくれ、10分が経過した段階で画面がクローズし入力ができなくなるので、強制的に次のタイピストに交代することとしています。

やっぱりお菓子大事。 551 大事。

モブに取り組む上で、メンバーそれぞれのやり方を受け入れる心のバッファが必要なので、お菓子があるとリラックスした状態でコーディングに臨むことができ、安堵感が全く違うのでおすすめです。

そして関西人にとって 551は心の拠り所です。

551 がないとき

551 がないので、全く力が入っていません。
モブを考えることさえできていません。

551 があるとき

かなり捗ってますね。これも 551 のおかげです。

社内受託時代にあった課題

現在はモアコンチームとして、Dev, PO, ScrumMaster, Designer が同じチーム、近くの配置で働けていますが、3年前は Biz と Dev はそれぞれ違う事業部に所属しており、席も離れていたため完全に依頼ベースで開発していました。その時には「こんな機能作って誰が使うねん」や「ほんま Biz 側は開発のこと分かってないわ」みたいな発言が散見されており、Dev の中でも隣のエンジニアが何をしているのかさえ分からない状態でした。

そんな環境なので、リリース後の機能が良いプロダクト作りに貢献できているかも計測できておらず、手戻りもよく発生していました。

スクラム導入によるチームの醸成

Dev の中でもこんなやり方じゃ良いもの作れない、という意見もあり、どうやらアジャイル開発にしたら良さそう、スクラムってのがあるらしい。くらいの感覚でスクラムの導入が決まりました。

アジャイルサムライ

まずはアジャイルサムライを全員で読み、書いてあることをつまみ食いではじめました。が、楽しくなるどころか、より Dev が苦しくなり、このタイミングでギルドワークスの中村さんにコーチをお願いすることになりました。

グループからチームへ -タックマンモデル-

はじめは名だけチームで、コーチからチームとグループの違いをレクチャーしていただき、メンバー間の認識の差を埋めることから始まりました。

引用: http://heart-quake.com/article.php?p=396

メンバーごとに得意なこと、仕事に対する価値観、メンバー間で期待していることや、自分の地雷などを共有し、人となりの理解を進めました。

人となりが分かるようになり、言いたいことが言える環境が整ってきた結果、思いの丈や不満を打ち明けるメンバーも中から出てくるようになり、ふりかえりやリファインメント時に衝突も起きる混乱期に突入していきました。

自分たちのプロダクトをどうしていきたいのか、チームとしてどうなっていきたいかを繰り返し話し合い、機能期へ移行した後、チームメンバーの入れ替わり等もあり、現在は混乱期から統一期へ再び移行している段階です。

モブをしていると顕著に関係値の変化による効率の違いを感じることができます。またリファインメント時にもPBIに関する Why, What, How を納得感をもって議論することができるようになりました。
そのため、チーム間の関係値を構築した上でモブを実施することをおすすめします。Dev のみでモブを導入することでも、一定の効果を実感できるかもしれませんが、PO を含めることでさらに洗練させることができます。

コーチ導入後のチームの変化に関しては、詳細を記事にしていただきましたので、そちらも良ければご覧ください。

導入時と現在のモブの変化

こちらが導入時のモブの様子です。

ディスプレイを机の横に置いており、共有用の PC もありませんでした。タイピストが変わるごとに個人PCを Apple TV に繋ぎ直していたため、シームレスに交代することができず集中力が途切れやすくなっていました。
ディスプレイの表示確認のために首も痛くなってましたね。

そしてこちらが現在です。

全員が同一方向を向いてコーディングするようになったため、コーディングに必要な情報に集中することができるようになりました。PC も同じものを全員で使うようになったため、タイピスト交代時のスイッチングコストは以前と比較して低下し、集中力を保ったままタイピストを交代できるようになりました。首も痛くなくなり、整体代の節約に繋がりました。経済的ですね。

モブ最高だけど最強ではないかも

個人開発からモブへ移行し、メンバー間のプロダクトに対する理解度も同一レベル化してき、コードレビューや情報共有の時間も短縮され、ベロシティも格段に上がりました。リリーススピードも早くなりました。しかし、最近はモブゆえの開発の”重さ”を感じるようになり、モノリシックな Dev になってきている実感があります。そのため、モブでの知見をいかしつつ、Dev をマイクロサービス化していくことへチャレンジしようとしています。

モブに適している開発、ペアに適している開発を見極められるチームへさらに改善を続けていきたいです。