この記事について

この記事は SUPER STUDIO Advent Calendar 2023 の13日目の記事です。

まずは自己紹介

はじめまして、みんなからは「わったん」と呼ばれています。
株式会社 SUPER STUDIO でコーポレートエンジニアリングユニットで主に社内ツールの開発を担当しています。
エンジニア歴は１年半程？で、この会社がファーストキャリアです。
QA → プロダクト開発 → 社内ツール開発と社内を渡り歩いています。

この記事の前提

今回は、チームでのモブプロと一人でソロプロをそれぞれやって、感じたことをつらつらと書いていこうと思います。
初めてテックブログを書くので、温かい目で見てください。

現在のチームメンバー構成や、開発の環境は下記の様な感じ

メンバー構成

リーダー
- 飲酒おばけ
- パワーリフティングもできる
- 開発もできる
- なんか色々すごい人
メンバー１
- 同い年
- エンジニア歴は筆者とだいたい一緒くらい
- 絶賛一緒に Ruby と Rails 修行中
メンバー２
- 元々は総務のお仕事をずっとしていた
- 最近コーポレートエンジニアリングユニットに異動してきた
- エンジニア歴はまだ数ヶ月
- 絶賛一緒に修行中その２
わったん
- 自己紹介でほとんど書いたので割愛

開発の環境

言語
- Ruby と Ruby on Rails
エディタ
- VS Code
モブプロの時の環境とか
- 毎週火曜日の16:00~18:00に集まっています
- VS Code の Live Share を使ってコードを見ながら、Google Meet で通話を繋いでます
- その日やりたいことは前もって Slack のリマインダーにスレッドで記入していく方式

本題

長くなりましたが、本題に入ります。
それぞれの良いと感じた・あまり良いと感じなかったことについて書いていこうと思います。
まずはモブプロでそれぞれ感じたこと。

モブプロをしていて良いと感じたこと

その場で第三者のフィードバックや意見をすぐにもらえるのが良すぎる

モブプロの一番の利点と言っても過言ではないと思います。
まだ経験が浅い人は、自分以外の人がどうやって考えてコーディングや開発を行っているかを見聞きすることで、様々な知見が広がると思います。
経験が長い人でも、必然的に教えるタイミングが多くなると思うので、自身の理解にもつながるんじゃないかな〜と思いました。
実際、筆者も教える側になることが少し増えてきましたが、人に教えることで自身の理解が深まったと感じる箇所がいくつもありました。

レビューにかかる時間を削減できる

その場でみんなでレビューをしながらコーディングをしている状態なので、PR を出すときにはほぼ完成に近い状態になっています。
レビューをする際に見なくてはいけない観点がだいぶ減るので、必要な箇所にだけ注力してレビューすることができるので品質も上がる気がします。

モブプロをしていてあまり良いと感じなかったこと

工数はめちゃめちゃかかっちゃう

単純計算で毎週参加人数*2時間です。
毎週確実に２時間拘束されてしまうため、有意義なものにならない場合はかなり無駄になってしまいます。
参加は必須ではないので、タスクに追われているときは不参加にしたり、裏で別作業をしている人などもいますが、せっかくやるならみんなが有意義な時間にしたいですよね。
予め、どういったことをやる・やりたいのか、何で困っているのか、などを宣言しておくことである程度の内容を予想して望むことができるので、少しはマシになるのかなと思います。

キャッチアップに時間がかかることがある

これはコードレビューでもあることだと思います。
ですがモブプロは実装途中のものを一緒に作ることも多いので、どこまで実装できていて、ここから何をしなきゃいけないのかを説明するところから始まります。
ここのキャッチアップにかかるコストは、PR レビューの時よりも多くなると感じました。
予め、WIP 状態の PR を draft で出してもらって共有してもらい、コメントで何が障害になっているかなどを書いてもらえれば、ここのコストは減るのかなと思います。

次はソロプロ
モブプロをやった上で比較して感じたことを書いていきます。

ソロプロをしていて良いと感じたとこ

一人でじっくり考えて実装を進められる

一人で開発やる利点はこれでしょう。
誰かにヤンヤヤンヤ言われながらコード書くよりは、一人で集中したいって人もいるでしょうし。
詰まってないなら一人で実装進めちゃうほうが楽ですしね。

差し込みタスクがあっても対応しやすい

モブプロ中でも対応はできますが、タイピスト（ドライバー）の人が対応しなくてはいけない場合、全体が中断になるためちょっと大変です。
一人でやっているときは、途中で中断して別のタスクをやり放題なので、ここのフットワークの軽さは間違いなく分があります。
（とはいえ、集中しにくくなるというデメリットもありますが…）

ソロプロをしていて良くないなと感じたとこ

その場でのフィードバックがないので、Slack などで連絡を取らないといけない

モブプロのいいところが、そのままこちらの弱いところですね。
やっぱり、複数人で口頭でやり取りしながら開発が進められるのはでかいです。
迷ったときにすぐ回答が聞けないとか、PR レビューのタイミングで大きい差し戻しが発生するとか、結構あるな〜と。

考えが凝り固まる

他の人の実装の"結果"は PR で見ることができますが、過程は見れません。
ソロでしかやっていない場合は、自分以外の人のテクニックを盗みにくくなるのかなと思ってます。
コードを書く上で、過程も大事だと筆者は思っているので、「あ、こういう実装の進め方もあるのか」みたいな気づきとかが得にくくなるのは、良くないな〜と思いました。

まとめ

モブプロとソロプロで、それぞれ感じたことを自分なりに2つずつ出してみました。
「どちらが優れている」というわけではないですが、それぞれにメリデメがあり、実装規模によって使い分けるべきだなと改めて感じました。
10分で終わる小規模な修正を、メンバー集めてモブプロでやる意味はほぼないでしょうし（新規メンバーとか向けに、ハンズオン的にやるのはむしろ効果的だと思います）
逆に、すごく大きな実装をず〜っと一人で抱えて進めるのも、レビューの段階で数千行・数十ファイルの差分を見るのも、正直実装者・レビュアーともにしんどいですし。。。
でも、それぞれのいいところを理解しておけば、もっと実装のサイクルを早く回すこともできると思います。

筆者もまだまだいろんなことを勉強中なので、モブプロとソロプロそれぞれの特性を理解しながら、今後もプログラミングを楽しんでいきたいと思います！