この記事は hacomono advent calendar 2024 の21日目の記事です
こんにちは。開発本部 UX 部の yasu です。
最近はクロストレーナーという効率的に有酸素運動（全身運動）ができるマシンにハマっていて、ジムで Netflix を見ながら楽しくカロリー消費に励んでいます。
直近では海外ドラマ「プリズンブレイク」全シーズンと日本の「六本木クラス」を見ました。
はじめに
この記事では、UX 部と CTO 室リアーキテクチャ＆イネーブルメント部が主体となって進めていた、フロントエンド（Nuxt で書かれたコンポーネント）のテストコード実装に関するスキルトランスファー（スキトラ）をモブプロによってどのように進めたのか、それによって得られた効果などをご紹介します。
この記事がスキトラの手段の一つとして、参考になれば幸いです。
モブプロとは？
モブプロ自体の解説は既に分かりやすく解説されているページが他のサイトに沢山あるので、この記事では詳しい説明は割愛しますが、今回モブプロを実施するにあたって参考にした『モブプログラミング・ベストプラクティス』から引用して概要をご紹介します。
モブプログラミングとは、3人以上の人々が1台のコンピューターの前に座って協力しながら問題を解決していくことだ。分散知識の考え方をプログラミングに活かしたものである。
分散知識とは、人間の集団が持っている問題解決に役立てられる知識の総体のことだ。モブプログラミングはそれらの人々を集め、1台のコンピューターの前に座らせるのである。
hacomono はフルリモートの会社なので、実際には「1台のコンピューターの前に座って」実施していた訳ではなく、一人（タイピスト）の画面をリモートで共有してオンライン形式で実施していました。
したがって、同じ場所に集まってはいませんでしたが、リアルで集まっているときと同じように直ぐに質問や相談ができるよう、なるべく音声は常時オンにしてもらい、質問や相談がしやすい雰囲気づくりを心がけていました。
モブプロで何を実施したのか？
今回、私たちが主導して行なったモブプロの内容としては、タイトルにも記載したとおりフロントエンド（Nuxt で書かれたコンポーネント）のテストコード実装です。
モブプロの目的としては、そのテストコードを書くための知見を他部署に伝播（スキトラ）して、他部署のエンジニアもテストコードが書ける状態にすることでした。
なぜ、このタイミングでスキトラが始まったのかについては、前日に投稿された記事『テストコード追加とリファクタリングでhacomonoのフロントエンド実装と仲良くなる』に書かれている、テストコード追加の背景に理由があります。
なぜモブプロ？
モブプロ以外のスキトラの手段として、ペアプロとレクチャーも比較検討しました。
大前提として、コンポーネントのテストコード実装はそれほど単純で簡単なものではないことが、我々の共通認識としてありました。
したがって、一回説明を聞いただけでは直ぐにテストコードが実装できるようにはならないことが明白であったことと、エンジニアによってフロントエンドに対するレベル感や理解度などが異なることもあり、他部署のエンジニアと同じ目線で実装を進めてみて、特に理解が足らない部分、つまづきやすそうな部分などを探る必要があると判断しました。
また、スキトラする側の我々も当時はまだそこまでフロントエンドのテストコードに精通していた訳ではなく、ドキュメント（ガイドライン）も整備されておらず、テストコードの実装方針も手探りな部分があったことから、我々も学習していく余地がありました。
そのような状況下における初手として、一番実施コストは高いものの、スキトラする側の我々も学習ができるモブプロを選択しました。
モブプロをどのように実施したか？
モブプロを効率的に進めるため、事前に役割を定義し、スキトラ対象者の人たちに準備しておいて欲しいことなどを伝え、時間は1.5~2.0時間（1時間で5分ほどの休憩を挟む）を目安に予定を確保してもらいました。
モブプロの題材としては、スキトラ対象の人（タイピスト）が所属するチームで関心が高く、直ぐにでもテストを書いておきたいコンポーネントを選定しました。
役割
一般的なモブプロにおける役割は「タイピスト」とそれ以外の「モブ」の2つに分かれていますが、今回実施したスキトラ用のモブプロではモブをさらに分解して「ナビゲーター」と「見学者」に分けて以下のような分担としました。
- タイピスト（1人）
- ナビゲーターの指示を受けて手を動かす。指示の意図などが分からなければ積極的に質問をする
- ナビゲーター（2~3人）
- タイピストに対して指示を出し、タイピストや見学者からの質問に答える。メインのナビゲーターは必ず事前に予習を行い、滞りなく進行できる状態にしておく
- 見学者（1人以上）
- タイピスト同様に質問したり、気になったことなどについて相談を行う。主にタイピストと同じチームの人たちを想定
タイピストの役割は同じセッション内で頻繁に交代するやり方もありますが、まずはスキトラ対象のチーム内で誰か一人が集中して学習して欲しかった（モブプロ実施後、得られた知見をその人が所属するチーム内で横展開してもらえるようにするのが狙いだった）のと、リモートの性質上、交代するタイミングでコードベースを更新するのにどうしてもタイムラグが発生することから、同じセッションではタイピストは1人に絞る形で実施しました。
事前準備
モブプロの目的周知を含め、スキトラ対象の人たちにお願いする事前準備やモブプロ当日の進め方などをドキュメント（Notion）にまとめて共有します。
事前準備のお願いは単純に箇条書きで書くのではなく、チェックボックス形式にして、当日までにちゃんと準備されているかどうかが分かるようにしました。
当日の進め方
まずはタイピストに画面（ウィンドウ全体）を共有してもらい、ブラウザ上でテスト対象のコンポーネントの見た目と振る舞いを説明してもらって、コンポーネントの概要をつかみます。
次に、コンポーネントのコードも確認しつつ、テストケースを洗い出していきます。
このテストケースの洗い出し時点で、コンポーネントの抱える責務が多すぎて、テストを書くことが難しく感じ、本来は設計から見直した方が良いかも…という話にも発展することがありました。
テストコードの書きにくさは設計の黄色信号であることを認識してもらいつつ、コンポーネントの責務を嫌でも意識することになるテストコード実装のメリットが実感してもらえたと思っています。
テストケースの洗い出しが終わった後は、ナビゲーターの指示に従ってタイピストが実装を進めていきます。時間内に実装が全て終わらない場合は次回に持ち越すか、タイピストが残りの実装を完成させて Pull Request の作成まで行ってもらいました。
振り返り
セッションの最後、15分くらいかけて振り返りをしていました。
振り返りをしているのは、コストをかけていることもあるので、定量的な実績やポジティブな感想をあげてもらってモブプロの成果を明らかにしたかった狙いもあるのですが、ネガティブな感想に対して打ち手を考え、モブプロのやり方を改善していって、目的を達成しやすいようにしていくというのが大きな理由です。
モブプロの効果は？
タイピスト側（見学者含む）、ナビゲーターそれぞれにとって、以下のようなモブプロならではの効果（利点）がありました。
- タイピスト側
- 指示通りに手を動かせば良いので、心理的負担が少なく進められた
- 知識があまり無い状態でも進められた
- VSCode や GitHub Copilot の使い方など、暗黙知になりがちな細かいところのノウハウも知れた
- テストコード以外の部分でも、コンポーネント設計や実装について学びを得られた
- ナビゲーター
- 実装方針についてその場で議論ができ、効率的に認識を揃えることができた
- タイピストや見学者たちがどんなことを知らなくて、どんなところにつまづきやすいのかが知れた
- つまづきやすそうな箇所については、テストコードガイドラインに追記
- ナビゲーターが一人に依存せず、誤った情報を提供するリスクを抑えられた
- 後から依頼されるコードレビューについて、モブプロでテストケースの洗い出しから一緒に行っていたのでレビューコストが低かった
あとは共通して、それまで顔合わせをしたことがなかった（フルリモートの会社なので）他部署のエンジニアと交流する場にもなったので、開発組織全体を一つの大きなチームと見なすとチームビルディングにもなっていたのではないかと思います。
おわりに
あくまで、モブプロは問題解決の手段の一つであって、この記事を通じてモブプロを全面的に推したかった訳でもなく、hacomono でも常にモブプロを優先して開発を行なっている訳ではありません。
実際、フロントエンドのテストコードのスキトラについては、テストコードに対する成熟度が最初と比較して現在は高くなり、ガイドラインも充実し、実績（参考になるコード）も増えてきたことから、今ではペアプロによるスキトラを行ったり、同期的なサポートを行わなくてもテストコードを書いてもらえる状態になりました。
その時のチームの状況などに合わせて常に最適な手段を検討し、問題解決に臨んでいきたいと考えています。
株式会社hacomonoでは一緒に働く仲間を募集しています。
エンジニア採用サイトや採用ウィッシュリストもぜひご覧ください！
