コロプラ・ベアーズ 面白いものを作りたい仲間が集まるベアーズ

コロプラのエンジニアブログ Vol.3【リモートモブプログラミング】
TEAM

コロプラのエンジニアブログ Vol.3【リモートモブプログラミング】

D.K

2019年11月中途入社 サーバーサイドエンジニア

K.S

2020年1月中途入社 サーバーサイドエンジニア

S.C

2020年2月中途入社 サーバーサイドエンジニア

【リモートモブプログラミング】

新型コロナウィルスの影響により、リモートワークに移行した方も多いのではないでしょうか?
慣れない環境のためか、以下のような悩みを耳にするようになりました。

◆ エンジニア間でのコミュニケーション不足
◆ アウトプットが思うように出ない
◆ 新規にジョインした方々のフォローがしづらい

と書きましたが......実は、我々3名はコロプラに入社して間もないメンバーです。その中で4月から在宅勤務になりましたので、本来でしたら上記の悩みを持つはずでした。ただ、我々にはある事情(後述します)があってモブプロにいち早く取り組んでいたこともあり、今回のリモートモブプログラミング(以下 リモートモブプロ)の導入は比較的スムーズに行われました。そして現在、この試みを取り入れたことにより、これらの課題にある程度柔軟に対応できていると思っています。

そこで、我々のチームにおいてのリモートモブプロのやり方の一部をご紹介させていただきます。

LCEチームとは

全社を横断して新規タイトルの負荷対策を担当しているチーム(Launch Coordination Engineers TEAM)で、社内ライブラリのメンテナンスなどもやっています。現在は直近リリース予定タイトルの負荷試験に向けて、負荷計測用ツールの作成やサーバーアプリケーションのチューニングを行っています。

モブプロとは

モブプログラミングはチーム全体で同じタスクを同時に作業する開発手法で、実際に手を動かす人(ドライバー)1人に対して、作業を支持する人(ナビゲーター)が複数人で実施します。ナレッジシェア、コミュニケーション促進、レビュー品質向上に効果があると期待されて採用されることが多いようです。

コロプラのモブプロの歩み

はじまり

コロプラではもともとモブプロやペアプロといった文化はあまり盛んではありません。
そんな中で我々がモブプロを始めたきっかけは、ベテランエンジニア1人と社歴の浅い我々3人のチームで、ベテランエンジニアがチームを離れることになったという切実な事情からでした。ベテランエンジニアからのナレッジシェアをなるべく短期間で我々3人に行う必要があり、なにか良い方法はないかということで始めたのがモブプロでした。
当時はまだ新型コロナウィルスによる影響が国内で本格化する前だったので、物理的なオフィス内でのオフラインモブプロです。

モブプロ導入

モブプロに対して特に知見のあるメンバーがいたわけではないのではじめはみんな手探りでしたが、社内ライブラリの機能追加や新規プロジェクトのコードリーディングといった内容にモブプロで取り組んでみました。
基本的には世間一般で言われているモブプロのベストプラクティスを参考にしながら、自分たちに合うやり方を模索して調整していくという形で進めました。

引き継ぎを兼ねたナレッジシェアを主な目的として始めたこともあって、導入はうまくいったと思います。数回やった頃には、モブプロで開発したほうがスムーズにいくなと思えるぐらいには、チーム内でモブプロの意識ができていったかなと思います。

リモートモブプロへ

そんな折に弊社でもスーパーフリーアドレス制度が導入され、ほとんどのエンジニアがリモートワークに移行することになりました。あとは、やってみると意外とリモート環境でも問題なくできるなという感覚でした。

リモートモブプロの普及を目指して

ちょうど2020年度新卒入社の方々が入社・配属されるタイミングでもあり、研修の一環としてリモートモブプロに参加してもらうことになりました。
今年の新卒の方々は入社直後から基本的にリモートワークという業務的な難易度の高い状態となっており、リモートモブプロを体験することでコミュニケーション的な意味での参考になれば......という狙いの取り組みでした。
具体的には実際に業務で我々が機能を実装するモブプロに、モブの1メンバーとして新卒の方とそのメンターの方に一緒に参加してもらいました。
普段自分たちだけでやるモブプロとは違う視点でのフィードバックや、「自分たちのチームでも導入してみたいです」という声もいただけました。

モブプロのやり方、実践例

それでは、我々が実際にどのようにモブプロを行っているかをご紹介します。

モブプロ

まずはオフラインのモブプロについて調べ、基本的なところからはじめました。

基本的なやりかた

◆ PCは各自のものを使い、Gitのブランチにコミットすることで交代する
 ∟ 作業途中でもコミットして作業ブランチへプッシュして、次の人がプルするだけなのでそれほどロスはないだろうと各自のPCでやることにしました。
◆ ドライバーの交代は20〜30分前後でキリのいいところまで
 ∟ あくまで目安としていたので1回が1時間超になることも起きていました。
◆ 交代ごとに5-10分の休憩をとる
◆ 全体の時間は2-3時間(超える場合もあるが、その分疲労感は大きい)
 ∟ 昼の休憩後から開始して19時頃までやるときもありましたがさすがに全員クタクタでした...。
◆ 導入直後で慣れていないため、毎回のモブプロ後に振り返りを行い、次のモブプロで改善を重ねていきました。

改善してきたポイント

ドライバーが自走して実装をどんどんしていってしまう時がありました。モブがついていけないことも発生したため、ドライバーはモブの指示に従うことを意識し、何をするか明確でなければモブに何をするか確認するようにしました。

リモートモブプロ

リモートワークでモブプロを継続して行うために、以下のようなやり方を追加で取り入れました。

毎日モブプロの時間を取る

我々がチームとしてリモートワークに移行する上で最初に決めたのは、基本は毎日モブプロの時間を取ろうということでした。
モブプロに慣れてきていたとはいえ、開催することの心理的ハードルは少なからずあったからというのが理由の一つです。毎日午後の頭から2時間ほどの時間をモブプロの定例枠として定めました。今考えるとこれは結果的にとても良い方針だったと思っています。

Slackコールの画面共有を利用

コミュニケーションツールについては、我々はSlackのビデオチャットを利用することが多いです。
社内の通常のミーティング等ではGoogle Meetを主に利用していますが、Slackのビデオチャットは画面共有時に他のメンバーが画面に書き込みができるという機能が、モブプロだと非常に便利でした。

交代と休憩をよりしっかり意識する

交代時間をよりきちんと計り、多少キリが悪くてもコミットして交代していくことを意識しました。リモートモブプロはその時間中全員がずっと集中して取り組むため、とても疲れます。また、自分以外のメンバーの様子がオフラインモブプロと比較して把握しづらいということもあり、交代の都度休憩するか確認していくようになりました。

議論だけをずっと続けない

モブプロ中は様々なところで議論がおきます。オフラインであればホワイトボードなどに書き出して議論する方法がやりやすいですが、リモートだとそれができないので、口頭でずっと話し続けるようなことが増えました。なので、とりあえずでも良いので、できるだけコードを書くことを意識し、書いたコードをベースにさらに議論を深堀りしていくのが良いのかなと感じています。

実際にやっている様子です

みんなで画面に書き込んでいます。

engineer_blog_vol3_800_495_1.png
engineer_blog_vol3_800_495_2.png

まとめ(メリット & デメリット)

ナレッジシェアが早く進む

チームやプロジェクトへの参画時に、ドキュメントベースでキャッチアップするよりも早く、実践的な知識が身につきます。コーディングルールなど独自の決め事も、コードレビューで指摘し合うより直接的に学ぶことが可能です。便利なツールやショートカットなどの知見が自然に集まるのも嬉しいポイントです。

コードレビューより質が高めやすい

「処理をどのクラスに持たせるか」や「変数名とかメソッド名の命名」など、ハイコンテクストな議論をローコストかつリアルタイムでできるため、通常のコードレビューではやりづらい指摘がしやすく、品質が高められます。
また、大きめの仕様変更でもコンテクストがしっかり共有できているのでアグレッシブに対応しやすいです。

疎遠になりがちなエンジニア間のコミュニケーションが盛んになる

従来どおり出勤していたときと同等か、それ以上にコミュニケーションが盛んに行われていると思います。ちょっとした待ち時間(ビルドやロードの待ち時間)は気軽に雑談をしています。また、チャットだけでは話しづらい開発の議論や設計の話などを口頭でできたりと従来と遜色ないコミュニケーションが取れていると感じています。

絵を描きながら話すのが難しい

コロプラのオフィスには「立ちミーティングスペース」という立ったまま打ち合わせができる机があちこちにあって、設計の議論等はそこに集まって机の上のホワイトボードに図を書きながら行っていました。
engineer_blog_vol3_800_166.jpg
リモートワークでは手書きの共同編集ツールを使って行うことになりますが、物理的なペンとホワイトボードのような使い勝手のものはまだ見つかっていません。Web版のGoogle Jamboardを使ってみたりしましたが、マウスやタッチパッドでは操作や細かい修正が難しくフィットしませんでした。また、作図ツールやUML作成言語で代替できないか検討しましたが、やはりホワイトボードとはそもそもの用途が違うこともあり、これといった解決には至っていません。まだ改善の余地はあると思うので引き続き色々検証していくつもりです。

在宅ワークの環境によっては苦労する点も

ネットワーク環境によってはドライバーの画面共有の映像品質が著しく落ちてしまい、どういうコードが書かれているかわからないことがあります。また、長時間に渡り音声/画面共有をONにして作業することになりますので、在宅ワークにおいて、タイミングによっては聞かれたくない音声や映像があると思います。こればかりは仕方ないことですので、チーム全員で可能な限り柔軟に対応するよう心がけています。

解決する方法として、具体的には以下のようなものがあるかと思います。
◆ バーチャル背景を使って生活感を出さないようにする
◆ 使用しているツールや設定を変えてみる
◆ 一時的に音声/画面共有をOFFにする or ドライバーを交代する
◆ 家の中でモブプロができそうな場所に移動してもらう
などなど。
今のところご家族含めた協力もあって、リモートモブプロの実施が難しい状況には陥っておりません。とってもありがたいです。

最後に

リモートワークがまだ続く方も多いと思います。
ナレッジシェア、レビュー、コミュニケーションに課題を感じているチームがありましたら、リモートモブプロを一度試してみるのも良いのではないでしょうか?