みんなでワイワイしたくなったのでモブワーク体験会を開いてみた

アドベントカレンダー

スキルアップ

新岡崚

2024年12月20日

この記事は「BEMALab アドベントカレンダー 2024」20日目の記事です。

はじめに

メンバーズの新岡です！

2019年の入社以降、バックエンドのエンジニアをしていたのですが2024年の5月にスクラムマスターにロールチェンジした初心者マークスクラムマスターです。

ところでみなさん、モブプログラミング・モブワークってご存知ですか？
エンジニアの方ならもしかしたら聞いたことがあるかもしれませんね。
ChatGPTくんにまずはモブプログラミングとは何者かを聞いてみましょう。

モブプログラミングとは、複数のプログラマーが一つのコンピュータを使って共同でソフトウェアを開発する手法のことです。
このアプローチでは、1人の「ドライバー」が実際にコードを書き、他のメンバーは「ナビゲーター」としてアイデアやフィードバックを提供します。
参加者は役割を交代しながら進めることが一般的です。  

モブプログラミングの主な利点には以下のようなものがあります： 

 1. **知識の共有**: チーム全員がコードや問題解決の過程を共有するため、全員が同じ理解を持つことができます。
 2. **高い品質**: 複数の視点からのレビューが即座に行われるため、バグや問題を早期に発見しやすくなります。
 3. **生産性の向上**: 複数人での作業により、アイデアの発展が早くなることがあります。
 4. **チームビルディング**: メンバー間のコミュニケーションが促進され、チームワークが強化されます。 

 モブプログラミングは、アジャイル開発手法の一環として広まっており、特にチーム全体の協力を重視する環境で効果を発揮します。
 (ChatGPTの回答をもとに不正確と捉えられる箇所を加筆修正)

とのことです。

- 複数のプログラマーが1つのコンピュータを使って共同で開発する
- プログラマーが役割を交代しながら進めていく
　　　 - 実際にコードを書く人=ドライバー
　　　 - 他のメンバー=ナビゲーター

なんてところが肝ですかね。
合わせてモブワークについても聞いてみます。

モブワークとは、モブプログラミングの概念を拡張したもので、特定のタスクやプロジェクトに対して複数の人が一緒に協力して作業を行うスタイルを指します。
モブプログラミングが主にソフトウェア開発に特化しているのに対し、モブワークはさまざまな分野や業種に適用可能です。

モブワークの特長には以下のようなものがあります：

1. コラボレーション: チームメンバーがリアルタイムで意見を出し合いながら、共同で問題解決やアイデアの創出を行います。
2. 知識の共有: 各メンバーが持つ異なる専門知識や視点が交わることで、より豊かな成果物が生まれる可能性があります。
3. 迅速なフィードバック: 複数人が同時に作業することで、即座にフィードバックを受け取り、改善を図ることができます。
4. チームビルディング: 一緒に作業をすることで、メンバー間の信頼関係が強まります。

モブワークは、特に複雑なプロジェクトや新しいアイデアを開発する際に有効です。
参加者が積極的に意見を出し合うことで、クリエイティブなソリューションを生み出す助けとなります。

(ChatGPTの回答をもとに不正確と捉えられる箇所を加筆修正)

モブプログラミングを、プログラミング以外にも適用しようとしたものと読めますね。
今回はそんなモブワーク(モブプログラミング)を体感してもらう体験会を作った経験をまとめてみようと思います。

モブワーク体験会を実施した背景

現在、メンバーズでは社内の技術研修を通していくつかのプロダクトが開発・運用されています。今回の記事を発信している当サイト(BEMA Lab)もその一つ(運用いただいている皆さんありがとう！)。

ただ、技術研修としての開発・運用をしていると、開発者がクライアントワークに移るタイミングがどうしても発生してしまいます(もちろん喜ばしいことです)。それにより、各プロダクトのドメイン知識、設計背景などの知識を持ち合わせている人が誰もいない状況などが起きてしまうのが課題でした。

そんな課題の解消に向けて、社内のプロダクト間でメンバーをコンスタントにローテーションする方法をとることにしました。これにより、誰かが開発から離れても他の人がプロダクトへのナレッジを持っている可能性を高める効果を期待しています。そして、その開発の中でスクラムの開発サイクルの体感をより高頻度にしてもらうために、フラクタルスプリント*1*2 を導入しました。
この、フラクタルスプリントでの開発の進め方の一つとしてモブワークの「知識の共有」「迅速なフィードバック」を活かそうと考えました。(なお、フラクタルスプリントに関する記事は未来の自分がきっと書いてくれます。頑張れ自分。任せたぞ。)

とはいえ、モブワーク自体がどういったものかを知ってもらう必要があるぞ！ということで今回の体験会を準備しました。

モブワーク体験会を設計する上で考慮したこと

こんな背景のもとでモブワークを伝えようと考えた時に、どう伝えるのがいいかを考えて思い浮かんだのが学生時代に参加したTDDyyχのテスト駆動開発の体感ワークでした。詳しくは公式のサイト *3 をご覧いただきたいのですが、体感を通しての実感と複数人でわいわいコミュニケーションをとりながら進めたことの2軸で理解が深まったのを今でも覚えています。
この時の体験をもとに、モブワークを伝えるのであれば、座学よりは体感してもらうことにウェイトをおこうと決めました。

体験会の設計

実際に体験をしてもらう上で、技術研修に来る方が全員モブプログラミング・モブワークを知っているとは限らないので座学はもちろん0にはしません。モブプログラミングにはどんな役割があるのか、実際にはどんな進め方をするのかを少し触れます。

ここは長くならないよう、10分程度で話し終える内容に整えました。その中で、チームの中のグラウンドルールとしてこの体験会の中で目的を達成したことを祝う合言葉を決めてもらうようにしました。例に挙げた内容がダメというよりは自分たちで選んだというプロセスをもたせることを目的としています。
この部分を中心に今回の体験会の資料は@TAKAKING22さんのMob Programming Startup Manual*4 を参考にさせていただきました。

体験の中では、モブプログラミングをしてもらうことにしました。(コアの体験対象を技術研修メンバーとしているため、コードは簡単には書けるという前提)

簡単な問題を実装していく流れの中でモブプログラミングを活用します。
体験ツールとしては、cyber-dojo *5 を使うことにしました。このツールは環境構築の手間をかけずに色々な言語の中から選ぶことができます。
このツールを選んだ背景は、大きく2つあります。過去に自分がテスト駆動開発体験会でこのツールを利用したことがあることが一つと、オンライン・リモートでも実施ができる部分から選びました。
弊社はリモートでの業務が前提のため、モブワークをするとしてもパソコンを交換しながら使えない制約があります。そのため、オンライン会議ツール(meetなど)の画面共有をドライバーがすることで物理的に交換はせず交換した体で進める形を取りました。

このモブプログラミングを行うにあたって、スクラムでいうプロダクトバックログを作成するフェーズを挟むことにしました。これはフラクタルスプリントで最短30分単位のスプリントでタスクを進めてもらうことを考えていたため、より小さな単位で実装することの感覚を掴んでもらう体験のためにこうしています。

こんな流れを経て実際にモブプログラミングを体感してもらうようにしています。
ドライバー、ナビゲーターをそれぞれ体感してもらえるように、短時間で交代を繰り返すようにしています。そのサイクルを繰り返すことで、全てのバックログアイテムの完了を目指します。スクラムでいう、スプリントのサイクルを考えて設計しましたが、時間の制約上ふりかえりなどのイベントが実施できないことがわかりました。そのため、スプリントとは異なるサイクルという単位にしました。

誰がどんな役割か、どんなバックログアイテムを進めるかをまとめています。

こんな流れを作った上で実際にモブワークを体験してもらいました。

実施してみてのふりかえり

今回作った体験会をこの記事公開までに2回実施しました。
各回を個人的に大好きなYWTを使ったふりかえりで振り返ってみます。
1回目

やったこと(Yattakoto)
- モブプログラミングの体験を最初にやってもらった
- 自分が作った内容で体験会を実施できた

わかったこと(Wakattakoto)
- コードが他の人と同期されるタイミングはテストを実行したタイミング
- この回で使う言語と関わるプロダクトで使う言語は一致しない
  - 体験用セッションは事前準備ができない
- 課題と作業スペースが離れてるとつらそう
- 説明の流れとして黙読で準備していた時には見えなかった難しい部分が見つかった

次やること(Tsugiyarukoto)
- 説明の流れを見直す
- 課題は作業スペースの横にも参照用で置いておく
- cyber-dojoのセッション準備もワーク内で実施する

これに従って説明の流れを変えるとともに、ワーク内で実際の体験の流れを見直して2回目に臨みました。
2回目のふりかえりはこんな感じ

やったこと
- オフィスから実施
- 4人チーム(1チームで実施可能なマックス人数と思っている人数で開催)

わかったこと
- 分解の仕方からチームによって個性が出る
  - 入力のバリデーションチェックも含めているチームで興味深かった
- 説明増やしたけど進行という観点ではちょうどよかった
  - 人数増えた影響で結構時間は使った(90分間で間10分休憩)
- アイスブレイクで使ったことがある、慣れている言語の質問にフレームワークの解答がそこそこある

次やること
- 人数の上限を3人で調整する
- バリデーションチェックは仕様として必要か明言する
- アイスブレイクで書いてもらいたい言語の説明もう少し明瞭に話す

実際に体感してもらって

実際に参加いただいた方から感想をもらいました。

- 1人で悩む時間がなくなるので、課題に迫られる感じが無くて良い。
- 他の開発者でもコード変更し易いよう、見やすいコードを書こうという意識を持てた。
- スプリントごとのタスクの定義の仕方にコツが必要だ考えました。
- 一人ではない安心感がありつつも、時間制限には焦るので感情の移り変りが忙しかったです
(原文)

プロセスだけでなく、開発の体験を伴ったことで、コーディングに対する意識を持ってもらえたのは嬉しい誤算でした！
複数人だからこその特徴もつかんでもらえてよかったと思います。

そんな中で

> 4人いると、話す機会を失う場面もあるので、2,3人での開発が理想だと感じた。

という感想は結構進行の立場としても感じたところと学びの両方がありました。
ふりかえりにも上げましたが、思ったよりパツパツだし2,3人で体験会も調整してあげるのがいいなという学びを得ました。

最後に

体験会(ワークショップ)作成はこれまでしたことがなく、参加者として参加したいろいろな会が裏側で練られているのを実感する機会となりました。
まだまだこれからブラッシュアップしていく必要がありそうな荒削りな体験会ですが、今後もいろいろな方に体験していただいて、体験会自体と自分のブラッシュアップをしていきたいと思っています。あと、TDDyyχにも久しぶりに参加したいな〜！！！