新卒エンジニアがフルリモートで知識を吸収するためにモブプロを取り入れてみた話

Yahoo!広告でフロントエンドエンジニアをしている舟木です。

2020年度に新卒で入社し、チームに配属されてからチームのメンバーとはほぼ直接顔を合わせることがなく業務を進めてきました。フルリモートの環境でできるだけ先輩社員からの知識を吸収するためにモブプログラミングの導入をチームに提案し、実践しています。
モブプロは新卒メンバーのみならず、チーム全体で知識を共有、冗長化できる手法だと感じています。フルリモート下で「強いチーム」作りに悩んでいる人にオススメしたい手法です。私たちのチームでモブプロを取り入れるまでの流れ、モブプロを取り入れたことによる変化をご紹介します。

モブプロを導入した背景

2020年度にコロナ禍の中、新卒で入社し、研修からチーム配属までフルリモートで行われました。チームに配属されてからは先輩社員のサポートを受けつつ業務を進めていました。一方で以下のような課題を感じていました。

• 近くにいたらできそうな、ちょっとした質問がしづらい
• 先輩社員の姿を見て間接的に学ぶことができない
• コミュニケーション量が少ない

これらの課題を解決できる方法がないか調べていく中で、「モブプログラミング」略して「モブプロ」にたどり着きました。モブプロでは複数人でコミュニケーションを取りながら実装を進められ、知識をチーム全体で共有できるところに魅力を感じました。自分だけでなくチームとして強くなるために有効な方法だと感じました。

私たちのチームでは、モブプロを導入する前は「開発タスクは個人で開発→チーム内でPullRequestレビュー」するという開発フローでしたが、導入後は「一部の開発タスクをモブプロで開発→モブプロに参加したメンバーがPullRequestレビュー」するというフローに変わりました。

モブプロは一つの開発タスクに対してチーム全員が取り組むため、短期的には開発効率が落ちてしまうことがあり、導入にはハードルが高かったですが、

• 会社、チームとして働き方が変わる中で、新しい取り組みをどんどん試してみようという風潮があった
• 後述するモブプロ導入までの準備をしっかりした
• まずは一部の開発をモブプロで行うことにした（半月に1回2時間）

こともあって導入、継続できています。

モブプロはメンバーがナレッジを獲得し、チームビルディングをするのに効果的

モブプロではメンバーが

• 1人のタイピスト
• 複数人のモブ

に分かれて開発タスクに取り組んでいきます。モブが実装について議論したうえで、実装をタイピストに指示します。タイピストはモブが指示した実装を忠実にコードに落とし込んでいきます。指示内容が理解できないときは理解できるまで質問します。タイピストは時間を区切って（5〜10分）交代します。

モブプロの導入で

• メンバー全員が知識（プログラムの記法、ドメイン知識）を共有
• 開発タスクをひとごとにせずチームの問題として取り組む姿勢
• コミュニケーションの活性化によるチームビルディングの強化

をフルリモートであっても進められました。特に「わからないことがわからない」状態を防ぐのに最適でした。モブの立場で議論に参加していることで自然と知識やノウハウが共有され、その過程で質問が生まれ、新たな課題を見つけることにもつながりました。フルリモートの状況では個人でタスクを進める時間が多くなっており、他のメンバーが進めているタスクが見えにくくなっていました。しかし、モブプロで進めるタスクはチーム全体で進められ、メンバー全員が理解している状態を作り出せました。

どのようにモブプロをチームに導入したのか

私がモブプロの導入をチームで進めるにあたって、

• なぜモブプロなのかをチームへプレゼン
• フルリモートでモブプロを実施するためのツール選定
• モブプロを行うペースの検討

の3点を実施しました。

1つ目のモブプロについてのプレゼンでは、モブプロの意義、モブプロの具体的な進め方をメンバーに説明して理解してもらうことを意識しました。

1番目の「レビュー効率を上げる」は、レビュワーがモブプロに参加することによってPullRequestの内容を理解した状態でレビューすることができ、レビュー時間の短縮や品質の向上につながることを表しています。

最後の「フロー効率の最大化」はモブプロのメリットとして書籍やウェブサイトなどさまざまなところで挙げられています。モブプロでひとつの機能を複数人で開発することにより、メンバーが全員共通の知識を持つことができ、チームとして短期間でリリースできます。フロー効率の対義語であるリソース効率が高い場合、メンバーそれぞれに得意な開発タスクが与えられ、リソース（人）の無駄がありません。モブプロでフロー効率を最大化した場合、短期的にはリソースが空いてしまうこともあり、無駄が多いように見えるため、モブプロは時間の無駄だよねとならないようにやる意味や理由などをチームメンバーに説明しました。

2時間のモブプロの流れもプレゼンしました。特に最後の振り返りは試行錯誤を繰り返しながらモブプロを改善していくうえで大事なセクションであることを強調しました。毎回振り返りを行い、次回のモブプロの改善に役立てています。

モブプロではモブとタイピストがそれぞれの役割を守ることが大事です。タイピストが自分勝手に実装を始めてしまうとモブは見ているだけになってしまいモブプロの効果が薄れてしまいます。プレゼンでは、モブが議論しながらタイピストに指示を出す、タイピストはモブの指示を忠実に守って実装することを説明しました。

2つ目、フルリモートでモブプロを進めるにあたって次のツールを利用しました。

• コード共有 （Visual Studio Live Share（外部サイト））
  チーム内ではメンバーそれぞれ使っているエディタが異なり、統一したエディタを使うのに抵抗があるかと思いましたが、タイピストのエディタを画面共有して、タイピストの交代時に毎回GitにPushする方法と比べると手間もかからないため採用しました。アプリをインストールせずにブラウザからエディタを利用できたり、モブがタイピストにカーソルで実装場所を指示もでき利便性が高いと好評です。

• オンラインタイマー （CHRONOGRAPH（外部サイト））
  タイピストの交代時間をお知らせするために使っています。オフラインのモブプロであればキッチンタイマーを置いておけば良いのでしょうが、フルリモートだとメンバー全員が残り時間を把握するのが難しいため、オンラインで残り時間を共有できるタイマーを使っています。次にタイピストになる人がタイマー操作を担当しています。

• オンラインホワイトボード （Miro（外部サイト）)
  振り返りで、途中からモブプロに参加したときに話についていくのが大変という意見があったので最近導入をはじめました。モブプロの中で文章として残しておきたいメモや議論内容があったときに使えると考えています。議論が白熱するとメモすら忘れてしまうので有効活用されるようにしていきたいです。

• タイピストシャッフル用Slackbot
  私たちのチームではタイピストの順番はモブプロが始まるタイミングで決めていますが、ランダムで順番を決めてくれるSlackbotを作って利用しています。

3つ目、モブプロを始めるにあたってすべての開発タスクをモブプロに置き換えるのではなく、半月に1回、2時間のペースでモブプロを取り入れてチームの負担が少なくなるようにしています。開発タスクは2時間で完結できるようなものを選定していますが、2時間で終わらないような大きめの開発タスクは開催頻度を増やしています。

実際にモブプロで進めた実装のご紹介

Yahoo!広告の動画広告には、ユーザの回線環境などが悪く動画が再生できないと判断したときに、静止画のサムネイル（代替画像）を出す機能がついています。

動画広告のプレーヤーは拡張機能という仕組みを利用して動画再生、停止のコントローラ機能や、フルスクリーン機能、代替画像を出すための機能を追加しています。

動画ではなく代替画像が出る場合、コントローラやフルスクリーンの機能は必要ではなくなるため無効になるのが正常です。しかし今まで代替画像が表示されているときもフルスクリーンの機能が残っていました。HTML内部にフルスクリーンの要素が残っているだけで表示には影響がなかったのですが、不必要な要素が残っているため改良することになりました。

今までコントローラについては代替画像の拡張機能が有効になっているときには、コントローラを無効にするための拡張機能の利用で無効化していました。代替画像の拡張機能の関数が呼び出されたタイミングで、コントローラの関数を無効化する処理を入れていました。

モブプロでは、

1. フルスクリーンもコントローラと同様に無効化するための拡張機能を追加する
2. 代替画像の拡張機能が読み込まれるときにフルスクリーンの拡張機能を無効化する
3. 代替画像の関数が実行されたときにフルスクリーンの関数を無効化する

案が挙がっていましたが、必要以上に拡張機能を増やすとJavaScriptファイルの容量の肥大化につながることや、拡張機能が読み込まれる順番が不確実なことを考慮すると、3番目の方法が良いという話になりました。コントローラも同じような処理を代替画像の拡張機能内に入れられ、今まであった無効にするための拡張機能が削減できました。複数の実装案のメリット、デメリットについて議論しながらメンバーが納得して実装に取り組むことができたのはモブプロならではの効果でした。

自分一人で開発を進めていた場合、2番目のアイデアを中心に考えて、最初の読み込み順を考慮する部分で長時間詰まっていたと思います。2時間のモブプロでスマートな方針を決めて実装できました。モブプロのなかで各拡張機能が存在する経緯、読み込み順についてもメンバー内で共有でき、知識の冗長化につながった開発タスクでした。

メンバーからのフィードバック

モブプロを実施するごとにチームのメンバーにはアンケートでフィードバックをお願いしていました。結果は以下の通りです。

各評価項目の設問
充実度: モブプロは普段の業務と比べて充実していましたか
効率性: 業務効率は上がりましたか（2時間は有用な時間でしたか）
一体感: チームとして一体感を得られましたか
リラックス度: モブプロをやることにプレッシャー、コミュニケーション面でストレスを感じませんでしたか

評価点
2: とてもプラス
1: 少しプラス
0: 変化なし
-1: 少しマイナス
-2: とてもマイナス

モブプロは短期的には効率が下がってしまうこともあり、効率性の評価点は全体的に低めでした。一方で一体感は全体的に高い評価点で、開発タスクをチーム一体で進めることや、チームビルディングの寄与にモブプロが良い影響を与えていると感じました。充実度やリラックス度は取り組む開発タスクの内容やモブプロの進め方で大きく変動しました。
第4回のモブプロではチームメンバーがあまり普段触れないコードを対象にしていたため、コード理解のためにモブプロ中に輪読会を取り入れてみました。事前の予告なく輪読会を始めたこともあって、コードの理解は深まりましたが事前に周知してからやるべきだったと思います。
第5回のモブプロは充実度、効率性、リラックス度ともに下がっていました。2時間で終わるような開発タスクで無かったことや、難易度が高く議論やトライアルアンドエラーの多さが原因だと思います。難易度が高い開発タスクはモブプロを始める前に内容をしっかり共有しておく、2時間で完結できなさそうな開発タスクは分割して進められるようにしておくことが大切だと感じました。

モブプロを始めて変化したこと

チームでモブプロの取り組みを始めて数カ月たちましたが、始める前と比較してチーム内で良い変化がありました。

• 雑談、気軽な相談が以前より増加

チームで定期的に開催される朝会のあとに、「ゆるいZoom部屋」が設けられるようになり、ちょっとした雑談や相談事をリモートであってもしやすくなりました。

• メンバーで強い分野を持つ人が見えてきた

AさんはJavaScriptの文法に詳しい、Bさんは広告配信システムの仕組みに詳しいなど、モブプロで議論をしていくなかでお互いの得意分野が見えてきました。私たちのチームではモブプロではなく個人で進める開発タスクも持っていますが、わからない、相談したいことがあったときにあの人に聞いてみよう！　となることが増えました。

• 弱い部分に気づき、補完しあえるようになった

モブとしてタイピストに指示を出すとき、どのように記述すれば良いのかすぐに出てこないことがありました。普段だったらササッと検索して済ませてしまいそうですが、自分の知識が不足している部分を自覚することができました。また他のモブが知識を持っていれば、知識が不足している部分を質問したりして、補完できるようになりました。

今後もモブプロの取り組みは続けていきたいですが、モブプロで進めるべき開発タスク、個人で進めるべき開発タスクを分けていくことは今後の課題だと感じています。チーム全員が知識を持つことができるように、新しいメンバーがチームにジョインしたときや、新しい技術を取り入れるときにモブプロで基礎的な開発タスクに取り組んでいきたいです。

おわりに

モブプロの導入によって、フルリモートの環境においても、ちょっとした質問がしやすくなりました。モブとして議論に参加していると、疑問に感じたことをその場で解決でき、オフィスで先輩社員が隣にいながら業務をこなしているのに近い感覚で作業することができました。また先輩社員同士が議論している様子を見て新たな気付きを得られ、違う物事の見方を知ることができました。モブプロをきっかけに普段のコミュニケーション量が増えているのも良い傾向だと感じています。

リモートワーク中心の業務において、モブプロはメンバーがナレッジ獲得し、チーム全体のビルディングをするのに効果的でした。新しくチームにジョインした読者のかたで知識をリアル環境と同じように吸収していきたい、チームに早くなじみたいときにはモブプロを1つの選択肢にするのも良いのではないでしょうか。