リモート・モブプログラミングという働き方

こんにちは!kintone開発チームの太田 (@kigh) です。 この記事では、自分のチームで2年以上続けているリモート・モブプログラミング(以下「リモート・モブ」)について、 進め方の具体例や所感、実際にやる上でのTipsを紹介したいと思います。

リモートワークが急速に普及する中、リモート・モブは働き方の選択肢の一つとして存在感を増してきていると思います。 この記事から少しでも参考になる点が見つかれば幸いです。

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

この記事では、テレビ会議システムなどのツールを使いつつ、物理的に離れたチームでモブプログラミングをすることをリモート・モブと呼びます。

現在、kintoneの新機能開発メンバーは6拠点のオフィスに分散し、また多くのメンバーがカジュアルに在宅勤務を活用するリモートチームとなっています。 また2018年から2年以上、全ての設計・実装タスクを原則モブプログラミングで行っています。 チームメンバーは同じ場所にいるわけではないので、よくイメージされるような一つのPCを囲んでのモブプログラミングはできません。 そのためテレビ会議システムを使い、画面共有機能も活用して開発を進めています。

kintoneチームに限らず、サイボウズでは少なくとも10以上のチームがリモート・モブで開発を進めています。

自分のチームでのやり方

リモート・モブの一例として、自分のチーム(東京2名・大阪2名の4人チーム)でのやり方を紹介したいと思います。

まずイメージしやすいよう、スクリーンショットで作業の様子を紹介します*1。 このように、IDEを画面共有しつつ、議論しながら実装を進めます。 ふりかえりなども同様に、議事録などを画面共有しながらやっています。

リモート・モブ作業中のスクリーンショット。IDEのウィンドウが大きく画面共有され、その脇に各メンバーの顔のカメラ映像が並んでいる
リモート・モブ作業中のスクリーンショット

より具体的な進め方は以下の通りです:

  • テレビ会議に接続してデイリースクラム開始→終わったらその流れでモブプロ開始
  • 基本は全ての作業をモブで進める
    • 適宜ドライバー(=テレビ会議で画面共有して、キーボードをタイプする人)を交代する
      • 場合によるが、最短7分ローテーションで
      • コードが中途半端でも気にせずコミット、後で整理する
    • ただし調査や定型的タスクなど、個人単位でやった方が効率が良いと判断した場合は、再開時間を決めて、一時的にモブを解散することも
  • ミーティング・勉強会などチーム外での仕事がある人は、自由に離脱・合流してよい
    • 1〜2人抜けても、残った人でモブは続行する
  • 疲れたら休憩を取る
  • チーム外の人と相談が必要になったら、随時テレビ会議に接続し、モブに加わってもらう
    • 常時モブをしているのは実装エンジニアだが、試験設計はテストエンジニアと、仕様やスコープ調整などはプロダクトオーナーと、文言検討はライターと一緒に、など
  • 16時になったらデイリーふりかえりをして、以降は自由時間
    • 個人で勉強したり、メンバーに質問したり、細々した仕事を片付けたりなど自由に
    • 新しい試みやチャレンジは個人単位で始めることも多いので、この自由時間も重要

なお、サイボウズ社内でもチームによって色んな文化があり、リモート・モブのやり方も異なっています。 また、同じチーム内でもやり方は随時変化しています。 そのため、ここで紹介したのはあくまで一例です。

リモート・モブに思うこと

2年以上リモート・モブをする中で、メリット・デメリットどちらもわかってきました。 今の所、私たちにとってはメリットが上回っており、「常に一箇所に集まれるわけではないチームにとって、もっとも良い働き方なのでは」と感じています。 ここではメリット・デメリットを中心に、リモート・モブに関する自分の所感をまとめたいと思います*2

良いところ

拠点間および在宅メンバーとの情報格差を最小化できる

これが今の所、一番良い点だと思っています。 ある程度の規模のプロダクトの開発をチームで進める上で情報格差は敵です。 悪いことに、リモートチームではどうしても、情報格差が生まれる確率は高まります(特に多数派の拠点・場所がある場合)。

例えば「最近決まった〇〇の設計について、他の人は知っているけど、自分は知らない...」という状況を想像してみてください。 直近の作業の遅れにつながることはもちろんですが、それ以上に、仕事に対するモチベーション低下、さらにはキャリアに対する不安にまで発展することもあるのではないでしょうか。

リモート・モブは、物理的な場所・属人化に伴うサイロという2つの壁を超えて情報格差を減らすことができる方法です。 自身の経験でも、個人作業からリモート・モブへ移行したことで、情報格差やそれに伴う不安が劇的に改善しました。

新メンバーの受け入れに強い

新しいメンバーにはチームへのオンボーディングをして、スムーズにジョインしてもらうことが重要ですが、 リモートチームの場合、その負荷が特定のメンバーに集中したり、あるいはうまく進められなかったりすることがあります。 リモート・モブなら、仮想的に場を共有していることが助けになります。

これは最近の実話なのですが、自分が勤務する大阪オフィスに新たに中途メンバーが入社してくれて、チームメンバーが自分1人から3人に増えました。 このような場合、もしリモート・モブ体制がなければ、新メンバーのガイダンスや教育のために、自分がしばらく休まず出社することが必要でした。 しかし今回、新メンバーには最低限のガイダンスをした後はモブに加わってもらうことで、新メンバーが周りの人に相談しやすい状態を自然と作ることができました。 結果、自分がやむなく休みを取った場合でも、何も問題は起きませんでした。

弱いところ

一方で、物理的に場所を共有していないために「ここは弱いな」という点もあります。

抽象的な議論がしづらい

プログラミングもそうですが、その前の要求の整理や設計などの段階で特に感じることです。 具体的には、「対面で話せばもっとすぐ伝わるのに!」とか「クラス図などをホワイトボードに手書きしたいが出来ない!」といったケースです。

対面よりも伝えづらい、というのはどこまでも付いて回る話ではありますが、議論する相手との信頼関係やコンテキスト共有を高めることで改善できる部分はあります。

また、ホワイトボードについてはツールでの改善が可能です。私たちの場合、電子ホワイトボードなどの導入にはまだ至っていませんが、プレゼンツールで描いた図やテキストエディタを画面共有することで案外なんとかなっています。

チームビルディングの速度が遅い

作業中は常にテレビ会議でつながっているとは言え、拠点が別だとランチや飲み会などはもちろん一緒に行けません。 また実際に顔を合わせて喋っていないため、心理的な距離感も縮まりづらい傾向はあると思います。

これには、意識的に雑談の時間を作ったり、出張して実際に会うことなどがとても効果的で、実際にそのような機会を作るよう心がけています。

過去の悩み

少し余談になりますが、コミュニケーションの円滑さという面で、やはり「テレビ会議は対面に敵わない」という実感は正直言ってあります。 そのため、「頑張ってリモートチームを作り上げなくても、拠点ごとに独立した体制を作った方が良いのでは・・・」と悩んだことが何度かありました。

しかし、昨今の在宅勤務の広まりから、リモートチームとして開発できることはほぼ必須になってきていると思います。 実際に最近、新型コロナウイルスの影響で、メンバーの大半が在宅勤務を選択していますが、プロダクト開発は混乱なく続けることができています。 こうした経験から、拠点が複数に分かれているかどうかによらず、リモートチーム前提で良いチーム体制を作ることは重要で、その一つの解がリモート・モブである、と自信を持って思えるようになりました。

リモート・モブTips集

記事の最後では、私たちがふりかえり等を経て辿り着いたTipsのうち、自分が気に入っているものをいくつか紹介しようと思います。

コミュニケーションの快適さ(ツール)にこだわる

通常のモブと比べたリモート・モブの弱点は、コミュニケーション帯域の狭さです。 経験のある方もおられるかもしれませんが、複数人でテレビ会議を使ってうまく議論するのは単純にスキルが必要で、ある程度時間をかけて上手になっていきます。 もしテレビ会議で会話がスムーズにできないと、ツールのせいでうまくいかないのか、自分たちのスキルのせいでうまくいかないのかが切り分けられません。 なので、ツールにこだわる価値はあると思っています。

実体験としては、あるツールを使ってリモート・モブをしていると、声を発してから相手に伝わるまでのラグが数秒に達することがありました。 その結果、発話の衝突がしばしば起きて、話がしづらい状況となりました。 細かい話のようですが、テレビ会議だと音声がコミュニケーションのほぼ全てなので、そこがギクシャクするのは結構厳しい状態です。 結果的に、ラグが短くなる別ツールに乗り換えて解消しました。当たり前品質大事。

カメラ表示をオンにする

メンバーがシャイでなければ、カメラを用意して顔を見えるようにすると良いです(もちろん見せない自由も尊重します)。 自分が話しているときに、頷きなどのリアクションが見えるか見えないかは、思ったよりも心理的な安心感が違います。 あとは、顔が見えるとより親近感も増しますね。

意識的に休憩する

普通のモブプロよりもリモート・モブの方が、休憩を忘れがちになりました。 他のメンバーが疲れていても気づきづらいからかもしれません。

休憩しないと視野が狭くなって、普段なら気づける解法にも気づけなかったりします(これは個人作業でも同じはず)。 肩も凝るし、強い気持ちで休憩を取るのが良いです。休憩タイミングをルールで決めるのも良いです。

抜けていた人が戻ってきても「一旦共有しますね〜」をやらない

ミーティングなどで離脱していた人が戻ってきたとき、親切心からその間の進捗を共有することがあります。 ですが、意外に共有しなくてもなんとかなることが多いです(少し作業を見ていたり、メモがあればそれを見るだけで十分キャッチアップできる)。 むしろ離脱・合流を気にせずモブの流れを維持する方が、離脱していた人も気を遣わないというか、快適に作業を進められました。 もちろん新メンバーがいる場合など、特定のメンバーが置いてけぼりになっていないか、質問しやすい雰囲気かなどは常に気をつけています。

「モブプロ宣言」を作ってみる

ちょっと変な標題ですが、要は「何のためにリモート・モブをやっているのか」を言語化してみる、ということです。

自分のチームでは、モブプロをしばらく続けていると、「ずっとモブプロやっていて良いのか?」といった意見がメンバーから湧き上がってきました。 これを議論するには、モブプロをやる目的がメンバー間で共有されている必要がありますが、最近までその言語化はしてきませんでした。

そこで、有志メンバーでワークショップをして、「モブプロ宣言」として言語化してみました。その成果物がこちらです:

【kintone開発チーム・モブプロ宣言】
私たちkintone開発チームは、 
 1. チームメンバー間での知識共有・学習の機会を増やす
 2. フロー効率を優先し優先順位の高いPBIから完了する
 3. 必要なときに様々な職能の人にすぐ議論に加わってもらう
 4. リモート・在宅開発体制でも問題なく開発を行う
 5. 会議・休暇・兼務などで抜ける人がいてもチームとしてスムーズに作業を進める
ことによって
 学習・品質・属人化防止・働きやすさ・楽しさ・安心感
というメリットが得られるため、モブプログラミングを実践している。

一度言語化してみることで、自分たちの仕事のやり方への納得感が増した感じがしますし、気づいていなかったメリットに気づくこともできました (例えば自分は「楽しさ」という軸は意識していませんでしたが、言われてみれば確かに、と思わされました)。 逆に、ここに当てはまらないようなタスクであればモブでやらなくても良いよね、という話もできるようになりました。

おわりに

私たちは、仕事時間の多くをリモート・モブで回しています。 そのためリモート・モブは、個々のタスクの結果だけでなく、モチベーションや個人のキャリアにまで、幅広い影響があると感じています。 少し大げさに言えば、リモート・モブは一つのプラクティスである以上に、働き方そのものに思えます。 このやり方がずっとベストかもちろんわからず、常に考え続ける必要はありますが、現時点では多くのメリットがある働き方だと思い実践しています。

この記事が何かの参考になれば幸いです。それでは、Happy remote mob-programming!!

*1:ちょうど、この記事を執筆している2月27日付で、一部拠点は原則在宅勤務とする弊社プレスリリースが出ました。このスクリーンショットは、その社内向け通達が出る数時間前に撮影したものです。

*2:ここでは「リモート」と「モブ」の両方を前提とした事項に絞って書きます。単にモブと個人作業とを比較したメリット・デメリットなども含めると、長くなりすぎてしまうためです。