こんにちは！ 開発部長の箕輪です。
この記事はロコガイド Advent Calendar18日目です。
みなさんモブプログラミングやってますか？ ロコガイドではこれまで取り入れたことがなく、今回オンボーディングで初めて活用したので、その内容をご紹介します。
なぜモブプロをやろうとしたのか
ロコガイドは今年の３月からリモートワーク中心で開発を行ってきました。オンボーディングについてもオンラインでおこなっており、その中で課題を感じることがありました。大きな課題のひとつとして開発現場固有のナレッジの習得が難しいという問題がありました。例えば、
- コーディングルール
- ビジネスロジックなどのドメイン知識
- エンジニア以外とのコミュニケーションのとり方
- 技術設計で落とし込むべき内容やレベル感
- コードレビューのお作法
- 自動テストの書き方やテストでのカバー範囲
- デプロイルール
など、ここに挙げたものだけでもごく一部で、実際にはもっと多くのナレッジが必要となります。各種ドキュメントを読み進めてもらいながら徐々に覚えていってもらうということは、よくあると思いますが、
- 直接手を動かさないので、身につきづらい
- 読み進めていく中で浮かんだ疑問をその場で聞けない、解消されないので効率が悪い
- 大量のドキュメントをひたすら読む、孤独、つらい...
- 読み終えた後、どの程度理解できているかを周囲がわからない、本人も自信がない
のようなマイナス面が起きる可能性が高いと感じていました。特にリモート環境ではこの問題が顕著になると思ったため、なにかしら手を打つ必要がありました。 そこで今回リモートでのモブプログラミングを試したところ、一定の成果を得られたので、事例として紹介したいと思います。
リモートでのモブプロ環境について
Google Meet
まずベースとなるビデオ会議ツールは、社内のミーティングで主にGoogle Meetを利用しているので、こちらをそのまま利用しました。ドライバー側の画面共有をしながら進める形としました。
VSCode LiveShare
こちらを使うことで同時編集が可能になります。参加者それぞれのカーソルの位置が表示されるため、誰がどのファイルを見ているか、プログラム内のどの行を指しているかが、リアルタイムでわかるようになります。動作スピードも気にならず、今後オンラインでモブプロする際には必須ツールとなりそうです。
Google Document
モブプロは共同作業となるため、お互いの目線を揃えながら進めることが重要です。また作業は長時間に渡るため、つねに現在地を確認しながら進めていくことが必要になります。そのため、作業リストや気をつけるべき点を細かくメモしていきながら、繰り返し見返しつつ行っていきました。手の空いているナビゲーターが書記を担当すると効率的でおすすめです。ドキュメントは最終的に後から見返したり、参加していなかったメンバーにも共有することができる点もメリットです。
モブプロで取り扱った案件について
今回はトクバイの社内スタッフ向けツールの改善案件をモブプロで行いました。
- 影響範囲が社内に閉じており、考慮すべき点が少なく肩肘はらずにできるため、はじめてのモブプロ題材として取り扱いやすい
- 案件サイズ、改善内容共に、一連の開発サイクルを学べるのに適切
- 技術設計、データベースのスキーマ設計/変更、一連の画面の開発
が主な理由です。
Let's モブプログラミング
前提
3名(ドライバー1名、ナビゲーター2名)で行いました。新メンバーがドライバーとなり、社内で開発経験の長いエキスパート２名がナビゲーターという形で進めていきました。当日は周囲にも声をかけ、自由に視聴ができるようにしました。物理的なスペースの制約もなく、いつでも出入り可能なため、ここは明確にオンラインのメリットを感じました。
最終的にモブプロにかけた時間は、午前中の約２時間程度を２回、後日30分の振り返りKPTが1回となりました。比較的時間が短いのは、事前にドライバーとナビゲーターで技術設計を済ませており、共通理解ができていたためです。
モブプロ１日目
作業リストの作成
事前に作業リストを持ち込むといったこともできましたが、今回の目的がオンボーディングということもあり、モブプロ内でリストアップを行いました。作業リストはできるだけ細かく、例えば「〇〇モデルの実装」といったコーディング内容だけでなく、「〇〇の動作確認」というチェック項目や、機能実装後を見据えた「オペレーションの依頼&情報共有」というものまでリストアップしていきました。ここで挙げたリストはモブプロの範囲外のものも含まれているので、それは別途対応としています。
エキスパートだったらどう進めていくかをトレースしながら書き出すことで、新メンバーにとっては一種の疑似体験が得られます。そこにはドキュメント化されづらい部分、例えばどのような部署が関連しているのか、担当は誰か、開発以外で気をつけるべきポイント、効率的に進めていくためのステップなど、多くの有用な情報が含まれています。
実装
じっくり作業工程の認識を揃えたあとは実装です。初日はデータベースのスキーマ設計/変更を中心におこないました。今回追加となるテーブル定義ファイルを作成し、開発用のデータベースにテーブル作成を行い、対となるモデルの実装までをおこないました。初日ということもあり慣れておらず、たまに詰まることもありましたが、なんとか最後まで実装しきることができました。
モブプロ２日目
２日目はビジネスロジックの実装と、対となる自動テスト(RSpec)を実装しました。1日目と同様に作業リストを眺めたり追記したりして認識を揃えてからモブプロを開始しました。慣れたこともあり、詰まることもなくスムーズに進めることができました。
モブプロをやってみて
初めての取り組みでしたが、多くの手応えを感じることができました。以下、順に紹介していきます。
言語化しにくい部分の伝達・共有ができる
考えるべきポイントに何があって、それをどう進めていくか、またそこにはどんな理由があるのかのような、エキスパートならではの経験や視点を会話しながら作業することで、今後の開発にも有用なナレッジの共有ができました。細かくは自動テストを書くときに気をつけているポイントであったり、カバレッジの考え方など、深いレベルでの共有ができ、自走力が高まったと思っています。またモブプロ中に交わされた議論は共通の情報として蓄積されるので、次に同じようなシーンがあった場合「あのときの〜」として、今後の意思疎通にも役立つと考えています。
リアルタイムでレビューができる
通常の開発であれば実装担当とレビュー担当はそれぞれ別の作業をしているため、どうしてもリードタイムが発生しますが、モブプロにおいては双方の役割を持つメンバーが一堂に会することで、その場で一連の作業を終えることができました。またドライバーの心情的にもその場で承認がもらえるので、安心して進めることができるのも、入社したばかりで慣れていない新メンバーには特に有効でした。
リファクタリングが活発で快適になる
一堂に会することでその場でのリファクタリングも快適になります。ロコガイドではGitHub上でコードレビューを行っていますが、テキストによる非同期コミュニケーションのため、うまく意図が伝わらないことが起きたりします。みんなちゃんと伝わるよう意識していますが、その分書く内容に時間がかかったり、それでも伝わらなくて何度か往復するようなシーンも見られます。モブプロでは会話による同期的なコミュニケーションとなるため、このやきもきするような気持ちがなくなり、快適にリファクタリングすることができます。
開発に役立つ知見の相互共有促進
普段開発者同士、これまで身につけてきた開発スタイルを共有する場は、なかなか少ないのではないでしょうか。このときはドライバーとナビゲーター双方で、自分はこうしているというような開発スタイルの共有が自然とおこなわれました。具体的には、Rspec実行など開発中何度も繰り返し使うコマンドのalias化であったり、変数を一括リネームする際のエディタ操作、エディタのコード補完プラグインなど、今後の開発に活かせる知見共有の場としても有効になりました。
最後に
参加メンバー、特に新メンバーにとっては好評価でした。最後に振り返りを行ったので、いくつか生の声を紹介して終わりたいと思います。
よかったこと
- 実装だけに閉じずに一連の開発プロセスまでやったのは良かった
- 条件分岐を減らすための構造化をみんなで考えられるのはいい
- 命名など意外と悩みがちなところをすぐに決められる
- アプリケーションの歴史的背景を知れた
- いろいろ受け渡し&受け取りできてよかった
- VScode LiveShareで詰まった時に代理入力してもらえるの良かった
改善したいこと
- ネットワーク環境のせいでLiveShareのセッションがたまに切れて再接続に時間がかかった
- 録画忘れ...(オンライン開催の場合は録画することをおすすめします)
- やっぱり終わったあとの疲れ感がある
- 休憩とるべし
いかがだったでしょうか。 ぜひみなさんのモブプロ事例なども教えていたただけるとうれしいです。
明日はITシステム部の鈴木による、Pマークの認定を自力で受けた記事です。お楽しみください！
