ラフールに入社してモブプロを導入したお話

はじめまして、最近入社しましたlafool_kです！

早速本題に入ります:point_up:
モブプロ活動を開始して一ヶ月が経とうとしているので、振り返ってみたいと思います！

以下の観点でご参考いただけるように振り返ってみました。

- モブプロの提案から実施までの流れ
- モブプロの効果
- モブプロの実際のようす

# モブプロとは

**全員で１つの作業をする開発方法です。**

参考記事：

https://engineering.mercari.com/blog/entry/20211130-52e6d96087/

全員で1つの作業をしたら効率落ちるのでは...?と思われるかもしれません！
こちらに関しては、**フロー効率性とリソース効率性**という考え方があります:thinking:

以下の記事でわかりやすく解説されています！

https://www.slideshare.net/slideshow/xpjug/79824686#1

:::note info
**モブプログラミング**(モブプロ)は、ソフトウェア開発におけるコラボレーション手法の一つで、一つのコンピュータをチーム全員で共有して、全員が一緒に一つのタスクに取り組む方法を指します。これは、アジャイル開発の文化やプラクティスと深く関連しています。(ChatGPTより)
:::

作業にあたり、二つの役割に分かれます。
- コードを書く人
- コードを書く人に操作や実装方針などの指示を出す人

そして全員が実装方針を考えてコードを書けるように、コードを書く人を10~15分サイクルで交代していきます。


:::note info
**役割の分担**
チームメンバーは以下の役割を持つことがありますが、役割は定期的に交代します:

ドライバー（Driver）: 実際にキーボードを操作する人。指示に従ってコードを書くが、自分の判断では行動しない。

ナビゲーター（Navigator）: ドライバーに具体的な指示を出す人。問題の解決方法を議論しながら導く。

オブザーバー（Observers）: 他のチームメンバー。提案を行ったり、議論に参加したりする。

**タイムボックスの設定**
役割交代のために一定時間（例: 10〜15分）をタイムボックスとして設定します。

**コラボレーション**
全員が意見を出し合い、課題を解決するための最良の方法を模索します。ドライバーはそれに基づいてコードを実装します。
(ChatGPTより)
:::


# モブプロを提案するまで

〜ドキドキ〜

私<font color="Red">**「お疲れ様です！これまでにモブプロで作業されたことはありますか？
こちらの作業ですが、よろしければモブプロで少し取り組んでみたいです！」**
</font>

「やったことないですが問題ないです！」
「やることに異論はありません！」

私「（よし、早速準備に取りかかるぞ）」


## 提案を考えた理由
最近入社した私は、<font color="Red">**システムの仕様理解や開発文化をキャッチアップしやすい環境づくり**</font>の一環として、モブプロの提案を考えていました。また、コミュニケーションの機会を増やして質問や相談をしやすい環境にもしたかったためです。


## 提案するまでの己との戦い

>一つのコンピュータをチーム全員で共有して、全員が一緒に一つのタスクに取り組む方法

モブプロは時間を拘束してしまうデメリットがあります。
入社したばかりの私が提案して良いのかな？とも思いましたし、中にはまだ話したことのない方もいらしたので少し悩みましたが、思い切って提案してみました💪（皆さん快く受け入れてくださり感謝です:sunny:）


## 提案する上で準備したこと

### 作業環境

- VSCodeのLive Share
- 開発用ブランチ
- Google Meet

![スクリーンショット 2024-11-22 18.42.03.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3941230/534b8a9f-bea3-03ad-ad24-5c2fd35bd92e.png)

:::note info
Live Shareを利用すると一人の環境を複数人で共同編集することができます！
Live Shareを利用しなくても、Zoomのリモートコントロール機能などでも代用できます。
:::


### 進め方

・**題材**：テストの実装

・**開催頻度**：週2回

・**開催時間**：2h/回

・**参加人数**：3~4名

・**タイムテーブル**：下表

|時間|作業内容| 
|:--:|:--:|
|14:00|準備（招待リンク発行、前回の振り返り、今日やることの確認）|
|14:10|モブ(15分/回 * 4回)|
|15:10|休憩|
|15:15|モブ(15分/回 * 2回)|
|15:45|片付け（変更箇所の確認、コミットなど）|
|15:50|振り返り|
|16:00|解散|

<br>


### メリット/デメリットの説明


**メリット**
- 個人vsタスクからチームvsタスクになる
- 作業が属人化しない
- 知識を共有できる
- リアルタイムでコミュニケーションを取りながら作業できる
- レビューのリードタイムを減らせる

**デメリット**
- 簡単なタスクだと非効率的
- 参加者の予定調整が必要
- 細かい指示の出し方と受け取り方が難しい
- 熟練者が一方的に発言して終わらないように注意


### 提案する気持ち


:fire::fire::fire::fire::fire:


# 導入してみて

## Keep
・みんなで考えている感が良かった
・メソッドや仕様の読み合わせが理解の助けになるので良かった 
・コミュニケーション面でやりにくさはなかった 
・一人でやっていると気づかないことも気づけたので良かった
・仕様を理解している人でないと網羅できないテストケースを把握できて良かった 
・楽しかった
・実装した経緯を知らないと難しい箇所だったので、仕様伝達の意味を兼てモブプロなどの場は必要だと感じた
・複雑なファイルだとモブプロはありがたい
・リファクタリング方針について話し合いながら実装できた

## Problem
・仕様や条件が複雑で難しずぎると、テストコードを書くまでに時間がかかることもある
・さらっと流せるような箇所であればもう少しペースをあげたい！
・どのファイルのどの箇所を開いているか分からないときがあった

## Try
・不定期開催でなく、定期開催にしたい
・個人作業で詰まっている箇所、実装に自信がない箇所を題材にすると良さそう 
・リファクタリング方針が思い浮かんだので、今後実装してみたい
・タイピストには画面共有してもらい、モブが見ているファイルの指示を出す


# モブプロの効果

定量的な成果

- 仕様が難しいメソッド：**1~2つ**のテストケースを実装(1回あたり)
- 仕様が簡単なメソッド：**2~3つ**のテストケースを実装(1回あたり)

定性的な成果

- 個人作業している際にモブプロで学んだ仕様が役立った:sunny:
- コードレビュー文化について知ることができた:sunny:
- モブプロ導入前と比べて会話量が増えた:sunny:



# モブプロの実際のようす

私「今日はここから作業を始めましょう！まずはメソッドの読み合わせからですね。引数と返り値はこうで...」

メンバー1「この条件のとき分岐に入ると...なるほど」

メンバー2「:blush:」

私「テストケースを洗い出しましょうか、かくかくしかじか」

メンバー1「うしうしまるまる」

私「ではテストデータを作っていきましょうかね。　まずこれとこれが必要で〜」

メンバー2「はい！カタカタカタ...」

メンバー1「一度テスト通してみますか」

私「エラーでましたね...ここにこれが必要ですかね」

メンバー2「カタカタカタ...」

...


[参考:タイムテーブル](#進め方)


# 最後に
個人としても、チームとしても成長できるようにモブプロは継続していきたいです。
定期的に活動を振り返って、モブプロによる効果を可視化してみたいですね。