こんにちは。創造開発部兼ものづくり推進部の武田です。
すっかり春も終わり初夏の兆しで梅雨入りしてと、前回の更新からだいぶ日が空いてしまいました。

今日は最近プロジェクトで試行錯誤している最中の、モブプログラミングの取り組みについてご紹介します。

まだまだ絶賛試行中ですが少しずつ見えてきたものがあるので、モブプログラミング（もしくはモブワーク）に取り組んで、私が感じた誤解や向き合い方についての話をします。

モブ{プログラミング,ワーク}って?

「挫折した人にも読んでほしい」日本の第一人者に聞く、「モブプログラミング」の魅力とは？ - エンジニアtype | 転職type より引用します。

3名から5名程度のエンジニアが1つのモニター、1つのPCを共有して行う開発手法。具体的には実際にコードを打ち込む「ドライバー」役が1人、それ以外は指示を出す「ナビゲーター」役となり、意見を交わしながら開発に取り組む。ドライバーは数十分おきに交代し、モブプロへの途中参加も途中退出も自由。もし作業中に問題が生じれば、その都度話し合って解決するため、手戻りが少なく、短時間でプログラミング品質の向上が見込める。

…良さそうじゃないですか? 直近プロジェクトでチームにおける学習とはということをよく考えており、実際にやってみようと思ったわけです。先日弊社に楽天株式会社から及部敬雄さんをお招きして、モブプログラミングについて勉強会を開催しましたのでそちらの資料もぜひ参照ください。

• 小さなチーム、大きな仕事を実装するモブプログラミング

実はわたしはこの勉強会には参加しておりません。資料と当日の話をチームメンバーから共有してもらったのみで、事前情報はあまり持ち合わせず特別ノウハウを体系的に学んだわけではないというのをご承知おきください。

まずはやってみるフェーズ

• What: やること
• • テストアフターとなったユニットテストのコード追加
  • jest を使ったテストコード
  • • ※ jest 経験者はメンバーのうち2名しかいない
• Who: メンバー全員（9人）
• • ドライバーを２名として任意のタイミングで交代
  • ほかは全員ナビゲータ
• When: 1.5時間
• Where: 会議室
• How: VSCode LiveShare でコードシェアし全員端末を開いている状態

これだけ決めて最低3回はやってみようと決めていました。時間が短かったりメンバーが多かったりするのは、この人数・時間でどういった感覚なのかをまずは確かめるためです。やってみないことには何も分かりません。

この段階ではノウハウが全くないので、まずはやること事前に決めたり準備したりメインのファシリテーターを私がやったりなど、個人が場を整える準備をしてから臨んでいます。3回目で私はファシリテートを辞める、というアクションなども加えてやってみました。

初回〜3回目:やってみて感じた課題

「終わった後に進捗や成果が気になってしまう」

ToDo リストを粗方でも先に作ってからやった方が進捗の見える化ができて、消化している感が醸成されて良さそう
何となくだけど本日のゴールを決めながやると良さそう

以上のような感想がありました。ゴールを決めるのはもちろんなんですが、どうしても終わった後に今日の成果が気になったり、タスクが完了しきれなかったことが心残りになったりします。この人数を招集してこの成果か…という具合で心理的負担はあって、どうしてもコスト高と最初感じてしまいました。

「首が痛い」

対面式で椅子が並んだ会議室でやったため、全員モニターを見ようとすると横を向くことになるので首を痛める、ということが分かりました。外的な環境がめちゃくちゃ大事そうです。

「わからないことを質問していいのか迷う」

質問すると作業が止まっちゃうから申し訳ない気持ちになるという意見がありました。それだけではなく、1.5時間 10人近いメンバーでやってるとほとんど言葉がないメンバーも出てきます。

「ドライバーの役割問題」

ドライバーやっていても話したくなってくる, 一定時間話さないのは辛い
ドライバーが進めてしまうことが往々にしてあるので徹底したほうが良さそう

上記のような感想もありました。これについてはルールを徹底し過ぎたのとそもそも誤解があったようです。ドライバーは質問するが自ら進めずナビゲーターの指示通り一字一コードをタイプするような誤解を持って取り組んでしまっていました。

「踏みまくったバッドプラクティス」

人数が多いことで話が発散してドライバーが混乱する
テストケース名のような日本語の問題で bikeshed discussion になりがち
適宜休憩取らないとコミュニケーションが多いのでかなり疲れる

上記のような感想からわかるように、結構悪い部分を踏んでいったなと3回目を終えたあたりで感じていました。

改善フェーズ: 4回目以降、現時点の取り組み

上記を踏まえて改善していきます。なお1回目からモブワーク後にすぐ感想・意見を募りました（今も終わったらすぐ振り返ります）。高速で回して高速でフィードバックし高速で次に反映させます。こういう試しながらやるスタイルはダラダラやるとメリットがわからず頓挫するので、高速で良くしていく方法が良いです。

• What: やること
• • 画面への動線追加
  • Cookie を使った振る舞い追加
  • レコメンド機能実装のためのサードパーティスクリプト組み込み
  • 前回よりバラエティにとんだタスクで多種多様
• Who: 3,4人
• When: 3時間
• • 25分, 5分休憩のポモドーロテクニックを利用
  • 集中していようが絶対に区切る
  • その都度ドライバーを交代する
• Where: 疲れないフリースペース
• How: 基本的に全員個人の業務端末は閉じる、ドライバーだけが端末を触っている状態

初回からどう変わったか

改善によって得られたものは大きかったのですが、これはあくまで私たちのチームの所感によるところが大きいです。前回から比較して課題と感じたものがどうなったかといいますと、

「終わった後に進捗や成果が気になってしまう」

極力気にしなくなりました。こういうものだろう、と。人数が9人から3,4人に少なくなったことで心理的負担が減ったのもあります。チームで集まってからタスクを洗い出しして取り掛かる、といった具合で進めており、これは回数を重ねるごとにメンバーでやりきれる範囲が見えてきたり見積もりの精度も上がるのだろうなと思っています。

「首が痛い」

フリースペースに大きめのディスプレイをおいて全員がそれを正面から見れる環境を重視しました。モブする環境が本当にめちゃくちゃ大事です。あと休憩中に立ちあがって伸びをする、立ち話しをするなど身体を恣意的に動かしたりしています。9人からモブするチームを分けたのもあり、別のチームのモブの様子を覗きに行ったりもしました。

「わからないことを質問していいのか迷う」

こちらについても人数を減らすことが功を奏して自然な会話の中で誰も話さない、ということはないように感じます。なお、出入り自由としてあまり今活躍の場はなさそうだ・必要に応じて参加するね、と感じたらすぐ離れて良いとしています。

「ドライバーの役割問題」

一旦ルールは忘れてやりやすいようにやってみました。ドライバーも自ら書けるものは書きますし、変数の宣言でわざわざ誰かの "c o n s t" という言葉を待ってる必要はありません。変数名はどうするの？ キャメルケースだよね、など質問しつつ会話しながらそれをコード化する役割がドライバーという感じです。

初回からさらによくなっていること

「モブ中に Slack やよそ見をしていない」

集中力が圧倒的に違います。**ドライバー以外は意図的に端末を閉じた状態で（むしろ持ってこないでよい）全員ディスプレイを見て同じ作業に没頭するのでモブが終わるとぐったりするほど集中しています。**なので、ペース配分なども考えていった方がいいのだろうなと感じています。

"一人で作業しているのとは別のエネルギーを使っている気がする" という感想があり、もしかしたら一人でコードを書く際には使わない会話のエネルギーも使ってるので、総合すると一人より疲れが大きいように感じます。

1日のモブでコミット・プルリクエスト作成（実際には合意を得ているのでレビューしませんが）まで行くと達成感・満足感が高いです。

「何でも聞く・話す」

とにかく質問する・作業中に話す習慣がついているように感じます。この粒度だったら新しいクラス作って import する？ この className を付ける時ってマルチクラスになるけどどのセレクタ最初に書いてるの？ みたいな話が自然と流れてきます。

これってプルリクエストで指摘されると面倒くさいやつですよね。タイムラグがあるため、プルリクエストが上がってレビュアが指摘コメントをした後にレビュイーの fix commit までおそらく長いと3日くらいかかりそうです。メンバーの合意がその場で取れてコードレビューが不要となるのは時間が相当短縮されているのではないでしょうか。

「途中の休憩がかなり息抜きになる」

5分の休憩時に、海外ドラマの話になってモブと同じくブラウザで調べてみんなで情報を見たり、お菓子食べながら談笑したり、モブ中の休憩もほとんどモブしているような状態がかなり良いです。メリハリはもちろんつけるべきで、タイマーをつけてアラームでしっかり動けると良さそうです。

「これが暗黙知の共有、という気付き」

属人化したタスクによって引き継ぎされないケースだとか、ドキュメントがどこにあるかわからず着手できないケース、といったような事態の歯止めに成り得るなとモブをするたびに感じます。上記でも触れたようなプルリクエスト上で指摘されがちな「自然とこうなっているコードスタイル」はじめ、属人化しているタスク・ルールってどのプロジェクトにもあると思ってまして、暗黙知とされているものが多ければ多いほど人から引き剥がすのに有効かなと感じます。

今後は監視ツールの見方や使い方、一人しか触らない可能性のある CI の設定・YAML、引き剥がせるものからどんどんモブでこなしていきたいと感じています。

そして何より及部さんの資料にある通り、コミュニケーションの問題を一気に片付けられることが大きな利点ではないかなと感じています。

まとめ

雑にまとめてしまうと、人には人のモブワーク、なんですが雑すぎるので私が感じているモブプログラミングの今のところのベターな方法としては、

• まずは短時間で、細かい集中時間で、小さなチームで
• リラックスできる体勢を保てる環境で
• ドライバー以外は端末を開かない

そして一番大事なのはメンバーを思いやる気持ちや敬意、より良い場にしようというチームの意識なのかなと。

本日は以上です。

※オリジナル記事はこちら
https://ceblog.mediba.jp/post/184870366542/%E3%83%A2%E3%83%96%E3%83%97%E3%83%AD%E3%82%B0%E3%83%A9%E3%83%9F%E3%83%B3%E3%82%B0%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F