f:id:mt_nile:20211110170905p:plain こんにちは。みらい翻訳のプラットフォーム部のthorです。

今回は、ここ半年ほどリモートワーク環境でのオンラインでモブ・プログラミング(モブプロ)を続けてみた結果についてご紹介したいと思います。

筆者自身はモブプロのメリットについては懐疑的だったのですが、実施してみて以下のようなメリットを実感する事ができました。

プログラミングと同時にレビューが行われるので、レビュー指摘によって大幅な修正が起きて手戻りが発生する事がないので、早く終わる。
常にみんなで話し合うので「三人寄れば文殊の知恵」が出てくる状態になり、成果物の品質が高い。
新しい技術を導入したプログラミングは、複数人で一緒にでやった方が初心者がやりがちなバグの修正や問題の解決が早く終わるので、短期間で技術導入が可能になる。
リリースまでのリードタイムが短くなり、工数の増加はそれ程でもなかった。
重要だが緊急でないために後回しにされる課題を強制的に進める事ができる。

それでは、どのようなきっかけで始まり、どのように進めていったのかを解説します。

はじめたきっかけ

実は「モブプロをやるぞ」と明確な意思決定をして始めた訳ではありません。幣部では、業務時間の20%は、プロダクト・マネージャー等のステークホルダー全員に対して重要性・緊急性について合意を得やすいビジネス的な要件ではなく、エンジニアであるからこそ見えてくる重要な事に使いましょうと言う方針があります。その枠内で、自動テストの充実や技術的負債の返済、新メンバー向けのドキュメントの整備、新たなツール導入による開発の効率化等のカイゼン活動をする事になっています。

このカイゼン活動は、週に1度ミーティングを開いてメンバー毎の分担内容を決定し、その後は各自が普段の業務の合間を見つけて活動し、次の週のミーティング時に進捗を報告していくスタイルで行っていました。しかし、このやり方では重要であっても緊急性が低くなりがちなカイゼン活動は、普段の業務で忙しくなると活動時間が取れなくなってしまいがちでした。このため、ミーティングでの前週の進捗の報告は「〇〇の件で時間がとれず、進捗はありませんでした。」となりがちでした。

これではなかなか上手く行かないねという結論になり、ミーティングの時間を方針の決定や進捗の確認の時間ではなく、カイゼン活動をみんなで集まって作業する時間に変更し、実作業時間を確保するようにしました。

最初のモブプロ

まず最初に改善したい課題として、古参のメンバーなら知っているがドキュメント化されてなかったり、更新されていない作業手順等が存在がありました。これが、新しく参加したメンバーの作業開始時のつまづきの原因の一つとなっています。(弊社はここ1年程でエンジニアの人数が2倍ほどに増員しており、この課題の解決の重要性は高まっています。)

手始めとして、手順書等のドキュメントの整備をチームの全員が一緒になって進める事にしました。(手順書のメンテナンスなのでプログラミングではありませんが) この時は、Slackの画面共有を使って、メンバーの一人がエディタを開いてその画面を共有し、通話しながら手順書の充実をさせていきました。

このようなやり方は、作業時間 × 参加人数の工数がかかってコスト高になりそうに見えます。ですが、ドキュメントを更新する場合は一般的に、

最初にどのような内容を新規記述・更新すべきかについて、メンバーが集まって検討会を開いて、作業内容を決定する。
決定内容に基づいて、担当する事になったメンバーがドキュメントを作成・更新する。
作成・更新内容を他のメンバーがレビューする。
担当者がレビューの指摘事項を反映する。

と言う流れになると思います。

チームの全員で作業をすると、3.と4. の作業は省略できます。また、作成・更新作業中に1.で出てきた内容以外にも記載すべき点について気付き易くなり、ドキュメントの品質も上がりました。省略できる作業工数を考えると実際の工数の増加はそれ程多くなく、品質向上を考えるとコスト増は許容できるものになりました。

2番目のモブプロ

メンバー全員が集まって作業した方が、重要だが緊急性の低い課題に取り組むには良いと言う気付きを得ました。そこで、開発作業の効率化のための開発環境の充実もモブプロ形式で進める事にしました。

弊社のSaaSサービスである、Miri Translator ® のメイン機能であるファイル翻訳ではAWS Lambdaを使用しています。Lamba関数をAWS クラウドにデプロイする前に、ローカルPCで気軽に動かしてみたいという事がよくありました。そこで、LocalStackというクラウドサービスのエミュレータを使って、各自のPCで動作確認できるようにしようという事になりました。

LocalStackについての情報は少なく試行錯誤をしながらの導入となりました。この時は、メンバーの一人がPCの画面をSlackで共有しながら、LocalStackの環境の設定や実行を行い(この作業を行う人をタイピストやドライバーと呼びます)、みんな(モブやナビゲーターと呼びます)で実行結果を確認しながら作業を進めていきました。タイピストが設定や実行をしている間に、モブは次の作業の調査したりして準備を行います。また、エラーが発生した場合は全員で一斉に原因調査を行いました。

新しいツールの導入を一人で試行錯誤をする場合は、以下のような作業を繰り返す事になります。

最初の設定内容や手順を調査する。
設定作業を行い、実行してみる。
エラーが発生したら原因や修正方法の調査をする
修正して実行して確認する。
上手く修正できていない場合は3.に戻る。
修正できた場合は、次の設定や手順の調査をし、2.に戻る。

モブプロの場合は、一人が設定や修正の作業をしてコマンドを実行している間に、他のメンバーが次の作業の調査をしているので進みが速くなります。また、エラーが発生した場合は、多人数で調査して、その中で一番速く解決策を見つけたメンバーがかけた時間で問題が解決するため、エラーの調査・修正のために半日潰れてしまうような事はありませんでした。

このような新しい技術やツールを導入する時にモブプロの形式で行うと、複数人で作業するため工数はかかってしまうのですが、リードタイムは短くなる事が明らかになりました。この事は『モブプログラミング・ベストプラクティスソフトウェアの品質と生産性をチームで高める』にも、フロー重視の考え方として紹介されています。

現在のモブプロ

このようにモブプロは短期間での新技術の導入にも有効である事が明らかになったので、現在では実際のサービスに新技術を導入する場合でもモブプロの形式で進めるようになり始めています。ファイル翻訳機能の処理制御にAWS Step Functionsを導入しようとしているのですが、その開発もモブプロの形式で進めています。

この開発では、

オフラインのモブプログラミングで使われるホワイトボードの代わりに、Miroを使ってアーキテクチャの設計を行う
大まかな設計を行った後に、JetBrains社のCode With Meの共同編集機能を使って、モブプログラミングをしながらプロトタイプを作成して技術的検証を行う
実装方法や技術的な制約や懸念点の調査をして、リスクや対応方法が明らかになった後で実装を開始する

ようにしています。

Miroのどこまでも全方位にスクロールできるボードは、ホワイトボードに近い感覚で使えるのでホワイトボードの代替として十分に使えるものでした。AWSのアイコン・セットが使ってシステムの全体像を簡単に描けるのが便利でした。また、一覧性はホワイトボードに劣るのですが、後で会議室を使う人のために消しておくとか、消す前に写真に残すとかの作業がないのも嬉しい点でした。

Code With MeやVisual Studio CodeのLive Shareを使った共同編集では、タイピストが、オフラインでのモブプロよりも素早く交代できます。しばらくコードを書いていないなと思った瞬間に「私がコードを書きますね」と気軽に言えるのは良い経験でした。

新規の開発では、最初にコードを書いた人によってクラスの責務の分割等の詳細設計が決まってしまい、後のコード・レビューの段階では設計の変更等は言いづらいと言う事がよくあります。モブプロではコードを書きながら全員でレビューしている状態になります。その為、「ここはこう言う設計にしておいた方が後々困る事は少なくなるだろう」との意見が出たり、設計に意見があるメンバーがいれば、その人が意見を述べながらその場でコードをリファクタリングしたりできました。その結果、コードの品質は全員の良い部分を合わせたレベルのものになったと思います。また副次的な収穫として、意見の交換をしながらメンバー同士でこれまでの仕事の経験やノウハウを共有できた事がありました。

モブプロを実施する時の注意点

ここまで述べてきたようなメリットがオンラインでのモブプロにはありましたが、以下のような注意点もあります。

モブプロをやっている間はほとんど喋りっぱなしなので、家庭環境によっては家族が静かにしないといけないとかもあるので、家族に負担がかかるかもしれません。
メンバーが共通で使いたいと思える共同編集ができるIDEがない場合は、エディタ戦争ならぬIDE戦争が始まるかも…
人によっては一人で黙々と作業したいと思う事もあるので、向き不向きがあるかもしれません。
モブプロは意外と疲れます。こまめに休憩を取るようにしましょう。前掲の書籍では、30分に一度は短い休みを入れ、1時間半以上のモブプロをした場合は、コーヒーを飲んだり、足のストレッチをするために15分の休憩を取る事が勧められています。
単純な実装作業が多くある(似たようなAPIがいくつもあるとかの)場合は、モブプロで全員が同じコードに向かうよりも、作業分担を割り振った方が効率が良くなると思います。
このような場合は、メンバーがoViceに集まってはいるけど、オンラインでのもくもく会のような形で進めています。何か疑問点があれば直ぐに誰かに質問できるようにし、複数の担当者で共通化した方が良さそうな処理が見つかったら共通化の実装をモブプロしたりしています。