RAKUS Developers Blog | ラクス エンジニアブログ

株式会社ラクスのITエンジニアによる技術ブログです。

モブプログラミングのすゝめ

私の所属する開発チームで行ったモブプログラミングの様子についてご紹介します。

これからモブプログラミングしようかと考えているが、

  • ハードル高いなぁと感じているチームリーダーの方
  • チームに対してモブプログラミグを提案したいと思っているいちメンバーの方  

こんな方に一読いただいて、文字だらけで恐縮ですが、イメージが湧いて参考になると幸いです。

きっかけ


巷で噂のモブプログラミング=通称モブプロ

お隣の開発チームがやっていて、うちのチームもやらないといけない空気感に腹をくくる所から始まりました。 きっかけがやや不純ですが、チーム内で商材の知識と商材の実装経験の差が課題だった(商材特有の癖とか)のもありました。 モブプロをチームで体験してみるという目的をもち、巷でメリットと言われてることは本当なのか、身をもって確かめてみることにしました。

準備


やるからには、生半可なことをしてはいけません。 何事も準備で9割は決まると言われています。お隣のチームがモブプロを行った時の反省点や、いくつかモブプロに関するブログを読んで準備をしました。

参考までに

https://takaking22.com/2018/mob-advent/

https://qiita.com/TAKAKING22/items/31e027dfb6ea8b1a8d69

https://speakerdeck.com/oohira/why-mob-programming

準備内容

  1. モブプロやります!!宣言

    チームメンバーに対して、そして周りに対して。言った以上、やらないわけにはいきません。

  2. モブプロの素材を用意  

    メリットと言われてる、暗黙知の共有や実装しながらコードレビューが出来るなど、すぐに活かせそうということで、通常の機能開発で試すことにした。 例えモブプロがうまくいかなくても、メンバーとその機能の関連するコードについて試行錯誤したことは無駄にはならないだろうという考え。

  3. 使い捨て出来るようにあらかじめモブプロ用のbranchを用意しておく。細かい所ですが、お隣のチームの反省点より。  

  4. 機能のどの部分を作るかを決めておく  初回は難しい箇所を選ばないことがベター。処理フロー図とかがあればより初回のハードルが下がる。

  5. 初回の役割を決めておく  ドライバー、ナビゲーター、ファシリテーター(タイムキーパー)

  6. ナビゲータの調査用PCを用意 ドライバーのみPCというパターンが多いが、各自好きなタイミングでコードの調査ができるようにあえて用意

  7. ディスプレイがあるもしくはプロジェクターを使える会議室 2時間予約(1時間半はモブプロ、残りの30分は振り返り)

Let's モブプロ


開始ものの数分後、やるべき事の認識を合わせてる途中に仕様の曖昧な部分が発覚。

少し考え始めましたが、他部署との調整が必要なことがわかったので、曖昧な部分はモブプロ後に確認し、確実に仕様が決まっている箇所から実装を進めることにしました。

気づけば20分経過。。。

まだ1行もコードを書いていない。

これは、、まずい、そんな空気になりました。

「ここで課題見つかって良かったよね~」

とポジティブな発言で乗り切れるチームでよかったです。

最初こそロスはしたものの、その後気づけば1時間経過。

目的としていた箇所の大枠は実装し終え、挙動の確認ができている状態に。

最初の20分が嘘のようで、アウトプットを出すことができた。

<その1時間のまとめ>

  • 機能の過去の経緯や背景
  • 共通メソッドの選び方のレクチャー、考え方、暗黙知の共有
  • どういうロジックにするのか、各々案を出す

こんなことを話しながら、気づいたら全員で楽しんでいました。普段、個々でもくもくと実装していると決してできない体験ができた。

初回のモブプロを終えて


どうやら、巷での噂はホントっぽい。

<よかったこと・気づき>

  • 暗黙知の共有はできる
  • 他の人がどの様に考えているかの勉強になった(ベテランのエンジニア同士のモブプロをしたため)
  • 特にエラーの切り分け方とか、若手のメンバーに見せたい内容だった
  • 1人で悩まずに済む
  • 慣れたり、題材によってはコードレビューまで出来そうという前向きな感想も出た
  • 実際にやってみてモブプロに対する不安感、抵抗感が一気にさがった(メンバーも私自身も)
  • またモブプロやりたいと思える会だった
  • 意見交換ができて、充実していた
  • ドライバーは変えなかったが、その場の状況次第で決めればいいと思った
    • 絶対にこうしなければならないということに縛られない方がよい
    • 目的が達成できるなら手段は臨機応変
  • 参考ブログをみると、ナビゲーターの発言の仕方の注意点があったりしたが、そこに困ることはなかった
    • チームで協力する際のメンバーの一面を見ることができた、人の意見に耳を傾けること、無下に案を却下したりしない相手に対してのリスペクト、気遣いができる所を改めていいなぁと思いました
  • 初回に難しい箇所を選ばなかったのは吉
    • ドライバー(役割)を強要しない(初回は止むを得ず強要しました、ごめんなさい。一度体験すると抵抗はなくなってました)

<課題感>

  • 点でみるとコストをかけすぎな様に見える
    • 手戻りでやり直すコストを抑えられるなら初期投資としてトータルで元はとれるのでは
  • 準備する負担はややかかる
    • 今回1人でやった準備をメンバーで分担すれば負担は軽減できる。が、現状では定期開催、週1回とかは現実的ではない
  • ドライバーは普段使い慣れてないノートPCでやや使いにくかった  

<今後の展望>

  • レビューまで終わらせたい
  • 若手を巻き込んでやってみたい
  • 定期開催したい  

まとめ


新しい取り組みを実際に「やってみる」、踏み出す一歩は勇気が要りますが、ダメでもともとと思えば(とはいえ、本気で成功させるための準備を決して怠ってはなりません)、 チャレンジすることのハードルは下がるのかもしれません。もちろん、良い面ばかりでもなく課題があるのは事実なので、濁すことも、隠すこともしていません。

その上で一度、騙されたと思ってモブプロをご賞味ください。 得られるものがあると思います。

追伸


先日、今後の展望の

  • レビューまで終わらせたい
  • 若手を巻き込んでやってみたい

この2点にチャレンジしてみました。

レビューはなかなか遠いですが、難易度をあげても

何をやるか。

を明確にして準備をしていれば実装の大枠はアウトプットできることがわかりました。

若手(新卒2年目)を2人巻き込んで参加してもらい、

  • ツールの使い方
  • 1人で悩まなくてもいい
  • 気をつけるべきことをその場で共有できる

この辺りにモブプロの良さを感じてくれていました。

Copyright © RAKUS Co., Ltd. All rights reserved.