実現したいこと
フルリモートなスクラムチーム(5人)でモブプログラミングを行うにあたり、
ストレスなく開発ができる環境を構築したい。
リモートで作業するにあたり作業用のPCの性能が足りないと感じること(作業効率のボトルネックになる)が増えてきたので、PC(主にCPU)の負荷も考慮する。
今回は「slackで音声通話を行なっている前提で、画面共有をどうするか」を考えてみた。
目についたものをいくつか試してみたので、簡単な導入方法やざっくりした使い心地などメモ
普段(非リモート)の開発環境
主な開発言語: Java, Go, HTML
IDE: IntelliJ Idea
Editor: VSCode
*インフラとしてAWSを利用
試したもの
Slack: ビデオチャット
有料な分、総じて使いやすいが、人数が多くなるとそれなりに重くなる
-
きっかけ
元々Slackでチームのコミュニケーションをとっており、モブプロを始めるにあたってまずはslackの通話(画面共有モード)で初めてみることに。
(Slackのビデオモードはworkspaceが有料プランである必要があります) -
導入
Workspaceを作成し、適当なchannelで通話を開始。
誰か1人が画面共有を行う。 -
メリット
-
音声通話と画面共有を1つのアプリにまとめられる
前提としてSlackを利用していたので1つのアプリで画面共有までまとめられるのは他の方法にないメリット -
ペン機能が直感的でドライバーに伝えやすい
いくつかのビデオチャットアプリにあるペン機能が思っていたより使いやすかった。
ドライバーの画面を見ながら"N行目の〜"と指示するよりペンを使って"ここの〜"と言った方が伝えやすい
ネットワークの問題で画面が乱れてエディタの行数が読めなくなることもしばしばあるので、オンラインだと特に強く感じた。 -
どんな画面でも共有できる
モブ中にローカル実行したWebアプリをブラウザから動確するなど、エディタ以外の画面をドライバに共有して欲しい時がしばしばあり、その際に特別な操作を必要としないのは楽で良い。
-
-
デメリット
-
人数が増えるとCPUを食ってくる
モブ(通話)に参加している人数が増えてくると、画面共有をしているドライバはもちろん、画面を見ているナビゲータのPCも結構発熱する。
その後時間が経つにつれて音声や映像にラグが生まれてしまう。
例として、Intellij IdeaでJavaプロジェクトをデバック実行している画面を5人で共有した場合
MacBookPro13(2018)/ Intel Core i5 Dual/ RAM 16GBで限界を感じるレベルだった
メリットで挙げたペン機能の分ひとり増えるコストが大きいのかもしれない。 -
画面共有するディスプレイによってはペンがズレる
Slackの画面共有はディスプレイ1枚全体を共有するタイプだが、共有するディスプレイの解像度によってはナビゲータが描いたペンの軌跡がドライバの画面のズレた場所に表示されることがある。
ズレが大きい場合、逆にドライバが混乱してしまう。
-
IntelliJ Idea: Code with me
導入は楽、追加料金はないが、同時編集には向かない
-
きっかけ
元々チーム共通でintelliJを使っておりバージョン更新(2020.2.1)からローカルのIntelliJ上のファイルを他のユーザと共有・編集できるプラグイン"Code with me"が正式公開されたので -
導入
IntelliJ Ideaを導入する部分は割愛
Code with meの導入は公式のドキュメント
もしくは導入〜使い方までまとめている以下記事を参考
【Code With Me】Jetbrains IDEで始めるコード共有でペアプロ生活
プラグインからCode with meを探してinstallしたらOK
誰か一人がホストとなって招待URLを作成し、ゲストがURLからホストのローカル環境に入るところは後述のVSCodeの Live Shareと同じイメージ -
メリット
-
ナビゲータも書き込める
画面共有と違って1つのIDEにメンバ全員が参加するので、全員がコードを編集可能
ドライバとは別の場所/ファイルを見にいくこともできる
ナビゲータが直接コードをいじるのは、モブプロ的には賛否ありますが... -
PCへの負荷が少ない
画面をキャプチャ→配信しないのでほぼ普段の開発時の負荷でモブプロ環境が実現できた
負荷が小さい分ビデオチャットにありがちな配信のラグがほぼないのが良い -
ローテ毎に共有画面を切り替える必要がない
ホストPCを固定するとドライバが交代しても、共有画面や設定を変更する必要がなく、スムーズに交代できる
チームメンバーのPC性能差が大きい場合は、性能が高いPCをホストにすることで、メンバ全員の作業環境をホストPCに合わせられる
-
-
デメリット
-
ペンないよね
画面を共有していないので、「ペン機能で見て欲しいところをマークする」は当然できない
Code with meに参加しているユーザの各カーソルは色で識別され、ユーザ名も表示されるのですが、ペンと比べると視認性が悪い。 ドライバの画面に表示されていなければそもそも見えないので使い辛い -
ドライバの画面が見えない
各人がコードのどこを見ているかは、基本的にカーソルで判別するしかない
特にドライバの見ている画面が見えないのはナビゲータをしていて結構辛かった
普段(オフライン時)からモブプロを行なっていて、行数指定でナビする文化があればそこまで問題ではないのかも -
同時編集するとconfrictする可能性あり
参加者全員が編集できる反面、何かの拍子にconfrictすることが度々あった
色々試してみたが、結局「ドライバ以外は書き込まない」に落ち着いた
(その結果code with meは不採用に)
-
ペンないよね
VSCode: Live Share
VSCodeで完結する内容なら有力
-
きっかけ
普段のチーム開発ではなく、研修などの短期間イベントで利用
有料SlackWorkspaceなし、IDEなしの環境で、エディタとして多数派(だと思っている)VSCodeを利用予定だったので -
導入
基本的に下記記事を参考に。 Code with meと同じくプラグインを入れてホストが招待URLを発行するだけ
Visual Studio Live Shareで始める快適なエンジニア間コミュニケーション -
メリット
多くのメリット/デメリットはCode with meと同じ- イベントで強い
- localhostのshare機能
-
導入めっちゃ楽
-
共有もURLのみで良いので1Dayなどのイベントで強い
-
terminalの共有もできるの強い(localhostのshare機能)
その他
上記以外で軽めに触ってみたもの、メリデメをしっかり書けるわけではないので
こんなのもあるよ程度に
-
Mac: sshでトンネルして画面共有
Macの標準機能である画面共有機能を用いてホストPCにメンバ全員が乗り込む
公式記事
ただし全てのMacが同一ネットワーク上にいる必要があるので、ホストPCがssh用のポートを解放し、
ゲストはssh接続した上で画面共有を行う
sshの設定だけで必要なツールもなく、エディタ以外も共有できるので作業の幅は広そう -
AWS Cloud9
AWSが提供しているクラウドIDE環境 公式記事
詳しくまとめられている記事
とりあえず触ってみた感触はローカル環境と遜色なく感じたが、
今あるローカル環境を捨ててAWS上に再構築するのが辛くて断念
料金もそこまで高くないので、今後新しいプロジェクトで1から環境構築するなら選択肢となる(はず)
まとめ
上記の通りでチームで色々触ってみた結果、最終的にSlackのビデオチャットに戻ってきています
なんだかんだでペン機能から離れられなかったのが理由の大半
(同じペン機能のあるビデオ会議ツールはZoomはじめ他にもあるのですが、元々使っていたSlackを選択しています)
今後も良さそうなツールがあれば試そうと思いますし、
何かベストプラクティスをお持ちの方がいればぜひ共有頂きたいとも。