やらなイカ?

たぶん、iOS/Androidアプリの開発・テスト関係。

リモートワークでコミュニケーションが足りないなら、モブプロすればいいじゃない

リモートワークが急激に広まる中、その利点とともに、チームのコミュニケーションが不足しがちという不安も聞こえてきます。 その対策としての、リモートモブプログラミングのススメです。

普段の職場へのモブプログラミングの導入には色々と障壁もありますが*1、急なリモートシフトの混乱に乗じてを円滑に進める施策のひとつとして試してみる価値はあるのではないでしょうか。

モブプログラミングとは

まず、モブプログラミング(以下モブプロ)について。知ってる方は飛ばしてください。

モブプロとは、プログラミングを

  • 同じ仕事を
  • 同じ時間に
  • 同じ場所で
  • 同じコンピューターで

行なうことです。

コンピューターを操作するタイピスト*2は交代制で、その場の全員で目の前の問題解決に取り組みます。 ナビゲーターは決してオブザーバーや傍観者ではなく、それぞれ考え、検索し、話し合い、決定します。むしろタイピストは入力するだけなので、言語やドメイン知識があまりないメンバーでもこなせます。

なお、モブ「プログラミング」と銘打たれてはいますが、プログラミングに限らず様々な作業をモブで行なう事例も聞いています*3
また、普段プログラミングを主としていないテストエンジニアやプランナーがプログラマのモブに混ざって知識を共有しつつ作業を進める事例も聞きます。

より詳しく、また、うまく始めるためのコツなど、次のスライドをぜひ参照してください。

speakerdeck.com

実際にやってみて実感しているのは以下のような点です。

  • 暗黙知暗黙知のまま共有できる情報量
  • 知識は、必要なときにタイムリーにインプットするほうが吸収できる
  • プログラミングでは調査の時間がそれなりにあるが、それを手分けできる(もしくは誰かが知っている)ので意外と効率は悪くない
  • 探索的なコードリーディングでも、迷子になりにくい
  • 従来、PRレビューで指摘したりしなかったりすることを、ストレスなくコードに反映できる

リモートモププログラミング

モブプロの定義のうち「同じ場所で」をオンラインで実現するのがリモートモブプロです。

リモートで行なうメリットとして、オンサイトにおける以下の問題が解消します。

  • オフィスに場所がない(会議室が空いていない、自席でやると近所迷惑、大きいモニタが無い)
  • メンバー間でキーボードやエディタの差異があり「同じコンピューターで」コードを書くストレス

以下、自分の体験と、Remote Mob Programming | How we do Remote Mob Programming. および How Remote Mob Programming Is Working for Me を加味したおすすめのセットアップを紹介します。

画面共有

開発環境は参加者個々のものを使い、ビデオ会議システムの画面共有 (screen sharing) 機能でタイピストの画面を全員にシェアします。

いくつか試した範囲では、Zoom Proアカウントがあれば*4Zoomが最もおすすめできますが、Google HangoutsやDiscordでも代用可能です。

ポイントは、

  • 上に挙げたサービスでは、画面共有はビデオ会議セッションのオーナーに限らず任意の参加者が開始できます。ビデオ会議セッションは1つを維持したままで大丈夫です
  • ウィンドウ単位での共有でなく、ディスプレイ1つを指定して共有すべきです。ビルド・実行などでエディタとは別ウィンドウを使用する際に、その内容もモブに対してシェアするためです
  • VSCode Live Shareなど、IDEのコラボレーション機能は(現時点では)モブプロには不向きです。表示するエディタタブおよびスクロール位置を共有できないため、みんなバラバラの箇所を見てしまい、また各自好きに編集できるため、モブとしてディスカッションするのを放棄して個々のアイデアでコードを書いてしまいがち
  • Zoomのリモートコントロール (remote control) 機能を使って1台のコンピューターの操作権をタイピストに渡す方法もありますが、ラグがコーディングの妨げになるため推奨しません。ラグが気にならない作業でなら検討の余地はありそうです

また、モブプロでは参加者すべてが仕事に集中し、貢献することを求めます。特にリモートでは内職しないように、 Remote Mob Programming | How we do Remote Mob Programming. では常に全員のカメラをonにすることを推奨されています。
しかし、慣れているチームや少人数であれば、帯域を節約するためにもカメラoffでも問題ないでしょう。その代わり、マイクは全員常にミュートにせず、相づちは声に出すよう心がけます。

タイピストの交代契機

Remote Mob Programming | How we do Remote Mob Programming. では10分インターバルを提案されています。

慣れてくれば時間制でなく、キリの良いところやタスクボードを用意して短時間で終わるチケットに区切っていく方法でも良いのですが、はじめは時間制が安心です。 休憩タイミングの設定も「n巡したら休憩」と決めやすくなります*5

オンサイトと違いタイピスト交代のコストがかかりますので、いずれにせよ時間は長めに設定するのが良さそうです。

Gitリポジトリによる受け渡し

Remote Mob Programming | How we do Remote Mob Programming. では、タイピストの交代ごとにWIPコミットをGitのリモートリポジトリ(モブセッションのブランチ)にpushし、次のタイピストがpullして続きの作業を行なう方法が紹介されています。

また、その操作をすばやく行なうためのコマンドラインツール mob が公開されています。これはGo言語製のコマンドラインツールで、次のように使用します。

$ mob start 10

これでブランチmob-sessionが作られ、その中でコードを書いていきます。"10"は交代までの時間指定(分)で、通知とデフォルトではsayコマンドの音声で交代を教えてくれます(macOSの場合)。

時間が来たら、

$ mob next

で作業状態をコミット(コミットメッセージはmob next [ci-skip])、pushしてくれます。

次のタイピストは自分のコンソールで

$ mob start 10

を実行すると、ブランチmob-sessionをpullしてくれるので続きの作業ができます。これを繰り返して進めていきます。

一連の作業が終わったら、

$ mob done

でブランチの作業内容がスカッシュされます*6。 適切なメッセージを付けてコミット、pushすることで完了です。

なお、mobコマンドの利用にあたっては、いくつか注意点があります。

  • リモートブランチ名は環境変数で設定します。1つのリポジトリで複数モブが作業する場合、モブごとに設定しましょう
  • リモートブランチをupstreamに設定しておく必要があります
  • mob done 実行時点でリモートブランチが消えてしまうのでオペレーション注意
  • mob start コマンドに share オプションを追加することでZoomの画面共有を開始(切り替え)できますが*7、あらかじめ以下の設定が必要です
    • Zoom > 設定 > キーボードショートカットを開き、「画面共有の開始/停止」の「グローバルショートカットを有効化」チェックボックスをonにします
    • macOS Catalinaの場合、スクリプトからの操作に制限がかかっています。システム環境設定 > セキュリティとプライバシー > "プライバシー"タブ > "アクセシビリティ" を開き、「下のアプリケーションにコンピュータの制御を許可」に /usr/bin/osascript を追加します*8。ただし、悪意のあるスクリプトによる操作も受け入れてしまう設定のため注意が必要です (4/6追記)

mobコマンドを使わない場合でも、交代をスムーズに行なうため「交代時のコミットメッセージにはこだわらない」「後でスカッシュする」等、ルール化しておくとよいでしょう。

[5/18追記] mobコマンドをIntelliJ pluginに移植したものをリリースしました。IntelliJ IDEsユーザの方はぜひ使ってみてください! plugins.jetbrains.com

マイク

環境音やエコーを防ぐため、外付けのマイクの使用を推奨します。指向性のあるコンデンサマイク(数千円のもので十分)で自分の声のみ拾うようにするだけで、ハウリングやタイプ音がなくなります。

私が使っているのはこれ

もしくは、スピーカーでなくヘッドホンを使用するだけでもハウリングは防げます。 ノイズフィルタリングしてくれるソフトウェアもありますが*9、音声品質はストレスの無いモブプロのために重要ですので、ハードウェアで何らかの対策をしておくことをおすすめします。

ホワイトボード

設計についてディスカッションする際は、オンラインで共有できるホワイトボードがあると便利です。 我々もまだ選定中なのですが、Miroは評判もよいですし、タスクボードやテキスト入力もできてこれひとつあれば大丈夫そうな感触です。

miro.com

描くだけであれば、ZoomやMicrosoft Teamsのホワイトボード機能や、Google JamboardやMagicalDrawといった選択肢もあります。 プログラマーは、ペンタブレットや液晶タブレットよりiPadAndroidタブレット端末の所有率が高いと思いますので、iOS/Android対応しているサービスがよいでしょう。

gsuite.google.co.jp

draw.kuku.lu

タスクボードは、GitHub ProjectsやGitKraken Glo Boardsなどの選択肢もあります。

GitKrakenの利用はぜひこちらから! www.gitkraken.com

まとめ

もちろんモブプロは万能ではなく、分担作業が向いているものもたくさんあります。しかし、全くやらないのはもったいないことだと思うので、今この状況を好機だと思って、試してみてはいかがでしょうか。

モブプロ自体、チームによって様々なやり方がありますが、最初は少々やりにくさを感じても今回紹介したようなテンプレートに沿ってやってみることをおすすめします。

参考資料

speakerdeck.com

speakerdeck.com

takaking22.com

(4/4追記) piyolog.hatenadiary.jp

*1:上司の説得(生産性が下がるのではないか等)、会議室が空いていない、自席でやると近所迷惑、大きいモニタが無い、キーボードやエディタの差異など

*2:ペアプロにおける「ドライバー」ですが、モブでは「タイピスト」のほうがふさわしいと思うのでこの表現で

*3:「モブワーク」「モブデザイン」「モブテスティング」などで検索してみてください。ただし万能ではなく、作業によって向き不向きはあります

*4:Proアカウント以上でないと40分制限があります

*5:意識的に休憩を入れないと、つい連続でやってしまって疲労困憊します(しました)

*6:この時点でリモートブランチも削除されますので注意!

*7:macOSLinuxのみ

*8:あらかじめFinderの 移動 > フォルダへ移動 で /usr/bin に移動し、サイドバーにドラッグ&ドロップして追加しておくことで指定可能になります

*9:https://krisp.ai/ など