1. ITトリオの日常
  2. モブプロって意味あるの?
2024-09-09 27:56

モブプロって意味あるの?

モブプロのやり方や失敗談、向いてるタスクについて話してみました

テキトーにやってみるのではなく、まずは一般的なベストプラクティスにのっとってやるのが大事そうですね〜

みなさんはモブプロやってますか?


▼▼▼ おたより待ってます!

番組の感想や話してほしいお題や質問など!

https://forms.gle/sqzWk2Yb79cMvFGg8


▼▼▼ X もよろしくです

ハッシュタグは #ITトリオ で!

https://twitter.com/TorioIt


▼▼▼ Webサイト

ITトリオの日常 公式HP


▼▼▼ 今週のジャンプ感想


ベガパンク、パンクレコーズが無事ならどうにでも復活できそうだな。

復活というか、各bodyはクラウドを利用したローカルファーストのアプリって感じか。

See Privacy Policy at https://art19.com/privacy and California Privacy Notice at https://art19.com/privacy#do-not-sell-my-info.

サマリー

モブプロの実施には、リスペクトと会話の活性が不可欠であり、成功するためには目的意識とタスクの選定が重要です。チームが持つメンタルモデルの均一化と知識の共有を目指し、効率的な作業のためのバランス感覚を保つことが求められています。モブプロは、チーム内での知識共有や学びの場として注目されています。このエピソードでは、モブプロとペアプロの違いや、それぞれの目的について詳細に解説されています。また、モブプログラミングの実践と知識共有の重要性が論じられています。さらに、効果的なタイピストの役割やフレキシブルなアプローチが強調されています。

モブプロの印象と課題
モブプロってやったことあります?
あるけど、ちょっとめんどくさい印象がありますね。
うーん、わかる。なんかね、モブプロ、めんどくさいもそうだし、
なんか、やったときにあんまり期待してこうかやられんかったな、みたいなことがすごいあるなって感じてて、
一方的に、もう本当に一人の人からずっと話し合ってるケースとか、
なんか、全然会話が弾まずに、なんかお見合いが始まっちゃうケースとか、
そういうケースとかが結構あったりしちゃって、ちょっとね、うまくいかんかったなっていう印象の方が強いかな、モブプロ。
まあ、確かに結構、モブプロはお互いのリスペクトを持っている状態とか、
その発信しやすさっていうのが土台にあるような手法にっぽいので、本読む限りね。
うーん。
まあ、そういうところがね、バランス取れてないと、意外と成立するのって難しいなと思ってて。
意外っていうか、もう明確に難しくないですか?
うーん。
ちゃんと考えてやったのに、意外じゃないなっていう感じ。
ああ、本当?
なんか、よくわからんけど、やってみようってやると失敗するなって。
確かにね、よくわからんと、みたいな目的意識がないとね。
だから、ちーずさんはそんなモブプロを最近やってるってことですか?
そうなんですよ。チームでモブプロをやっていて、まあ、メリットもうちのチームではあるなと思ってて、やってはいるんだけど、
なんか、どうするとよりうまくいくんかなっていうところは思ってます。
ちなみに、今のモブプロの状況を聞いてみたいんですけど、どれくらいの頻度で、どれくらいの時間モブプロをやってたりするんですか?
今はですね、だいたい週1ぐらい。
多分、本当はもっと頻度としては、週に2回くらい、2時間とってやりたいなっていう気持ちはありつつ、
あんまり時間が取れてなくて、週に1回あるかないか、みたいなくらいの頻度で、必ず2時間は確保している。
で、人数は3、4人。
で、内容としては、だいたい20分くらいはオンボード、今回モブプロで向き合うべき課題に対して、
その課題に対して一番詳しい人が、若干軽く説明した上で、モブを10分ごとに交換してやっていって、最後の10分は必ず振り返りに使っているっていう感じかな。
なるほど。
そんな感じの2時間やってる。
モブプロの目的
モブプロって、闇雲に全てをモブプロでやればいいっていうわけじゃないと思っていて。
そうね、それはすごい思う。
何のためにモブプロやってるのかとかは、ちょっと気になる。単純なコーディングの作業をモブプロやってるわけじゃないですよね。
そうね、さすがにね、モブプロをそもそもやるべきタスクか否かっていうところは、プランギングで精査した上で、
このタスクはみんなでモブでやったほうが良さそうだよねっていうところを決めているんだけど、その基準としては、一番は俗人化されている行動。
なるほど。
なんかもう、ここはこの文脈だったらこの人がやったほうがいいよねが、部分的に生まれていることがうちの課題で、
そういう部分のスキルをちゃんとトランスファーするために、秘伝のたれをみんなでちゃんと作り方を覚える的な意味合いも含めて、
その課題に一緒に向き合えるために、そのモブの場を作っている感じかな。
それってさ、俗人化してるってことは、その人がずっと発言しちゃうみたいな、ずっとその人が言ってってみたいな感じにならない?
それはならないならないようにというか、逆にその人の持ってない知見とかを、こういう視点でここを考えたほうがいいんじゃないみたいなアイディアを発散していって、
その人が持っている世界とは別の手段を取ったりすることができるところは、モブとしてはいい。
なんか結構さ、メンバー一人一人のスキルは結構高いの?高い印象を受ける?聞いてる感じはね。
どうかな、でもそれなりに高いというか、チームとしてバランス感が違えども、まだフロントにはそこまで精通してないけど、ある程度献血出てっていう人もいて、
どちらかというとチームの状態が健全であるというか、スキルが強い人の発言が強いみたいなことではなく、お互いの意見をバランス持って尊重し合ってリスペクトを持ってやっていくっていうのが一番大事だと思うんだよね。
そういうことか、まあじゃあその内容自体は、発言する内容自体はそんなに大事じゃないとか重要じゃなくて、なんかなんていうのかな、そういう空気感がまず大事みたいな。
まあ誰しもがなんだろう、多分そのお見合いするような状態だとモブプロって成り立たないと思ってて、
なんかモブプロをやる理由として、その一人一人の考え方とかもどんどんシェアされていって、メンタルモデルとかが統一されていくっていう、そういう世界観を目標にしているから、
誰かのメンタルモデルに真似るだけじゃなくて、それをうまく均衡化していく部分かなと思っていて、
なんかそういう賛同するというか、なんかその意見を一方的に言うみたいなことがあったときに、
多分うちのチームだと振り返りとしてそうならないように、1分以上喋らないとかそういうのルールを作るとかはやらないとは思うけど、
まああんまりモブプロをやる上で、一人がずっとガーって話すは、なんかベストではないなって思う。
みんなの中で、そういうのはやっぱり一人がずっと喋るのはやめようみたいな。
程よいバランス感覚みたいなのが、みんなのメンタルモデルってあるって感じなんだ。
そういう話をしたことはないけど、自分はなんだろう、モブプロをする上では、なんか言えないとか、あの人が絶対みたいな、
そういうのはなくしたいという思いがあってた上でやっているかな。
なるほど。なんかあれもこれも気になるみたいなケースってあると思うんだけど、場合によっては。
その時にずっと一人がバーって何個も何個も質問したみたいなことはない?
全然ない。
ないんだ、すごいな、それ。
チームがいいよね。
チームがね、たぶんモブプロをやれるときって、なんだっけ、タッグマン、なんだっけ、混沌期の状態でやると結構大変そうかなって思いつつ、
混沌期を乗り越えつつあるタイミングが一番ベストかなとは思う。
なんか確かに、なんか僕モブプロめんどくさそうだなって印象の裏には、なんかみんなで一緒にコードを書いても効率上がらないじゃんって思ってたんですけど、
それはそもそもなんかモブプロの目的とは違くて、話を聞いたり調べた感じからすると、
モブプロってそもそもなんか後かっていうとコードを書くこと自体よりかは、そういうことを通じて知識をチームで共有するっていう方が。
そうそうそうそう。
目的のメインで。
そっかそっかそっか。
だからなんか、コードを書く手段というよりかは、なんか勉強会のアシュみたいに捉えた方が、なんか認識整うのかなと思って、
そう考えてみると、確かに結構、共有する、知識の共有する、ドメイン知識を共有するっていう目的にとってはかなり良さそうだなと思って。
確かに全然そう考えてなかったわ。
だからもし、なんか全ての知識を全員が得た状態、いわゆるコードのメンタルモデルが揃っている状態でモブプロをやっても、
多分その費用対効果的な、なんだろう、時間対コードのアウトプット的な部分はあまり出せないと思ってて、
そうでなったら多分一人一人が各々コードを書いてタスクを進めていくべきかなと思ったけど、
さっき言った通り、混沌期の後ろ側、まだまだドメイン知識の伝播やそういうメンタルモデルが共有されていない状態じゃないタイミングで一番やるのがベストかなと思ってて、
かつ設計の土台はね、ある程度整っている方がいいなって。
個人的には思ってて、そういうタイミングで、いわゆる秘伝のタレであったりとか俗人化されているところとかをやると、
そういうスキトラ的な意味合いで結構価値が出るなっていうふうには私は思っている。
作業はね、価値がね、本当に。
作業で唯一価値を見つけるとしたら、「へー、そういうショートカットあったんだー。」ぐらい。
たまにあるな、それ。
へー、こういうふうに痴漢するんだー。
ぐらい。
だからまあ、時間で、いわゆる3人で集まって1つのタスクに向き合ってるわけだからさ、
それバラバラでやった方が早くねって、他の人が他のことやってた方が早くねっていう話になるからね。
で、あともう1つ思ってるときは、もうモブプロをやるっていうタスクは、
もうモブプロをやるっていうことに集中してガッとやった方が良くて、そのタイミングはちゃんと徹底的にモブプロでやった方がいいかなって思ってて。
で、モブプロをやる目的というか、やるからにはあまりコードレビューっていうフローがその後に発生しない。
みんなで認識を取って書いてるコードだよねっていうところから、コードレビューの手間を省けるんですよ。
それでさ、途中までさ、モブでやってて、次から誰かが書いてってやったら結果コードレビュー発生しちゃうんですよ。
意味ないんだよね。
その前提の知識とかみんなで考えたからわかるよねみたいなことはできるんだけど、
思った以上に時間は省けないので、
モブが価値があるタスクに対してモブプロを実施して、
そこでコードの知識の均等化とかメンタルモデルの共有とかをしていって、
それとコードレビューをする手間とかを削減していくっていう部分に関しては、
長期的に見て価値があるかなっていうふうに自分は思ってて。
一手段でもありつつ、全部モブプロでやったら破綻するなって思ってる。
向いてるタスクを思わず見極めないといけなくて、
全てをモブプロでやればいいってわけじゃないっていう。
前提としてね、正しくプランギングするというか、
プランギングの質も相当上げなきゃいけないなって思ってて。
場合によってはさ、一人がタスクを割り振るみたいなチームとかもあると思うんだけど、
そういう認識の状態で、人狩りが見えている世界でモブプロをすべき箇所ってわかんないと思うんだよ。
あと長くいる人ってこそ、どこの部分が秘伝の種でわかりづらいかとかってあんまり察知できないと思うから、
どちらかというとメンバーレベルの発信が必要かなと思ってて。
なるほど、面白い。
そういう部分もね、より健全なプランギングができている前提にあるから、
モブをやるタスクを見つけるのも難しいよなって思う。
モブプロの価値
毎週やってるわけじゃんね。毎週ってそんなに出てくるの?ポンポンポンポン。
今はあるね、全然。
そうなの?すごいな。
それも行動自体はあって、それに対する追加の編集とかで結構俗人化しているから、
このあたりのドメイン知識をみんなで共有しようみたいなのがほとんどって感じですか?
まずね、車歴が短い人もいる状態で、
で、ある程度成熟させてしまった行動があるから、
現状でだと、そういうロジックを書く部分に関してモブの価値が生まれているところはあるかなと思ってて、
それがある一定数1ヶ月とか、逆に車歴の短い人の考えとかって、
この凝り固まったプロジェクトでずっとやってる人たちはまだ伝授できてない?
その全職で得たこととかも伝授していくきっかけになるから、モブで。
そういう意味で、新しい考え方とか、
こうした方がいいんじゃないのを見つけることができるから、
現状、そういう意味合いで価値が生まれるタイミング、
どのタスクにおいても、めっちゃ作業みたいなのじゃなければ、
ある一定数考えてロジックを組む場所であれば、全て価値が出ると思っている。
ペアプロとの比較
本当にね、結構、私のこれ考えだけど、
モブをやるべきタイミングって相当ピンポイント。
価値が、いわゆる費用帯の価値が出るタイミングって結構ピンポイントかなとか思ったりもする。
けど、やったことない会社は、やってみると新しい発見があると思う。
で、そこから混沌期みたいなものを乗り越えたら、
多分長期的に見て、そのモブで時間かかった分をペイできるくらいの価値は生まれると思う。
いいな。
話を聞いたり調べたりして、自分もモブプロやってみたいなっていう感じになってきたんですけど、
今、どっかの会社に所属してるわけじゃないから。
マジこんな人がいねえ。
モブプロやれないわ。
2人とも今モブプロやれるような環境。
環境じゃない。
環境ですね。ではないね。
それやりたいんだな。マジで。
ITトリオ。
モブプロ、ペアプロって感じで、もう1個あると思うんですけど、
ペアプロの方はやってたりしてるんですか?
ペアプロは私はあんまり経験がないです。
そうなんですね。
逆に今やってるのはモブプロ。
確かに調べるまで分かってなかったんですけど、目的も結構違いそうな気がして。
ペアプロは文脈的には、
結構コードを書く、コードをマージするまでの時間を短くしようみたいなことで、
ペアプロやってる会社よく見かけるなと思っていて。
ペアプロはどっちかというと、レビューの時間が長くかかりすぎるんで、
それを減らすために、2人で一緒にコードを書いて、
その中で知識の共有もするし、レビューみたいなことも半分終わらせることによって、
出した変更がプロダクションに出るまでの時間を短縮したいっていう意味合いで、
やられることが多いのかなと思っていて。
たださっき話したようにモブプロはどっちかというと、
知識の共有とか勉強会的な側面に近い方が多くて、
ペアプロはもっとコードを書く、実務に対する利益を重視した方のアプローチかなと思っているんで、
ペアプロ、モブプロっていう感じで括られることはあるけれども、
そもそもそれぞれの手法の目的は違うんだなっていうことを知りました。
モブプロのルールと実践
勉強になりました。
私の言ってたモブプロの中にもそういう同じ目的もありつつ、
私が感じている一番大きな利益として感じている部分がそこって感じかな。
ペアプロは結構うまくいくイメージあるんだよな。
そうなんだ。そこ聞きたい。ペアプロがうまくいってモブがうまくいかない理由。
やっぱりさ、僕の場合はだけど、ペアプロの場合は関係値がある程度できてるし、
どういう人か知ってるし、自分がどういうことを学びたいかとか、
どういうことを目的としてその人にペアプロお願いするかって決めてるから、
多分目的がはっきりしてるのかな。ペアプロの方が。
だから目的通りに進めていけるから、
多分ペアプロの方が、あ、良かった。得られたものは得られたってなるんだけど、
モブプロは結構なんだろうな、とりあえずやってみようでやることが結構多くて、
多分そこのステッキがしっかりできてなかったのかもしれないね、ただただ。
自分からモブプロやってみようって言ったことはなくて、
周りがやってみようってなってやったことっていうのは大変なんだけど。
ああね。なんとなくやってみたいな。
周りの準備不足と。
そういうわけじゃないと思うけど、
俺がそういう目的をちゃんと理解せずに行っちゃったっていう可能性も十分あると思うんだけど、
そういうふうに思うことが多かったなって、モブプロに参加した時に。
確かにモブプロの目的みたいなところの、
それ自体のメンタルモデルの共有ももしかしたら大事かもしれないね。
モブの中でもこういう思いでモブプロやってるんだって異なる感覚でやり続けていると、
差異が生まれてしまう可能性はあるから。
お客さんになっちゃう可能性がある。お客さんと思ってはないけど自分が。
それってさ、モブプロやる中でコード書く人はちゃんと交代してやっている上でそういう状態になる?
交代してない。
やっぱそういうことだよね。
一応モブプロのルールとしては、モブとコードを書く人は10分ずつに交代していくっていうルールがあって、
多分それ故に成り立っているものがあるのかな。
分かんない。何かの方法論に乗っかってやってるんだけど、本に書いてあった。
そういうのあると思う、確かに。
それかもしれないね。多分コードが書く人がずっと支持されている感覚になるかもしれないから、
ちゃんと支持をずっとしている人みたいな感じにならずに交代していくことによって発言できる人が変わってくるから、
コード書く人が喋っちゃいけないわけじゃないんだけど、
基本的にはコード書く人はモブから支持されたことを書くみたいなところがメインになる。
そういうのあるかもな。
似たようなので言うと、モブプロではないけどモブプロっぽいなって思ったのは、
障害が起きたときに、障害が起きましたら、
あなたはこれ担当で、あなたはこれ担当で、みたいなのあるよね。
なんて言うんだっけあれ。
あるよね。
分かんないけど。
出てこない。
誰かが役割運動をする人がいれば、
うまくこうやってこうやってみたいな。
報告役と、マーケターとの連絡役と、障害細かく調べる人と、
障害範囲調べる人と、どこまでの障害が起きてるかみたいな。
うまく分かれれば、すごい綺麗にいくけど、
そういうのがちゃんと定まってないところだとさ、
一人が画面共有しながら、障害見てる画面をみんなが見て、
みんながそれぞれ調べるけど、結局一人過ぎる人がどんどん調べていって、
そうなんだって終わっちゃうみたいなケース。
お客さんみたいになっちゃうみたいなケースが結構あるんだけど。
そんな感じで、障害と近しい感じを感じたモブプロも、
ちゃんと設計とか、こういう風にやっていこうみたいな、
あの感じで決めておくと、もっといいものになるんだけど、
みたいな、思ったりした。
そういう意味では、モブプロをする上で、大事だなって思うことは、
一旦世の中にあるルールでやってみるが大事かなと思ってて、
多分それをやってみないと、なんとなくのモブプロ、
なんとなくの形でやるモブプロだと、そういうメリット、
いわゆる世の中的に言われている価値とかを、理解しづらいと思うんだよね。
だからそれは、なんかおすすめしたい。
みんなにももう一度モブプロをやる機会があるのであれば、
ちゃんと世に出ている本。
うわー、うちのチーム何でやってるんだっけ。
ちょっと本忘れちゃったんだけど。
そう、なんか私はちゃんと読めてないんだけど、
そのモブプロを伝授する人が一人、もうガッと読んでくれて、
なんかこのルールでやりますってやってくれてて、
うまく回っているかなっていうところがあるから、
そっちの方をおすすめするかな。
障害対応もね、たぶんそういう会社のルールであったりとか、
決めておくことが多いと思うから、
それにのっとるとうまく回るとかあるかもね。
あるかもね。
そのさ、モブプロのルールは、
たちぃーずがさっき言ってたのは、
10分ごとに各人交代するってことだと思うんですけど、
それ以外にも採用してるルールはあるんですか。
振り返りを必ずやる。
ほんとはね、やめたこともあるよ。
エディターとキーボードを同じものを使うとか、
ほんとはあるんだけど。
なるほど。
それ統一しなかったら逆にどうやって回していくんですか。
同じPCっていうかMac使うんですよね。
基本的なモブプロはそうなんだけど、
それによって各個人の開発速度が落ちてしまったので、
今は基本的にリモートでズームって画面共有複数できるんですよ。
それでもう終わったらプルしてみたいな。
コミットは一旦雑でコミットしていくっていう。
モブがコードを書く人が10分経ったら、
必ずコミットをするっていうルールもあるのね。
なるほどね。
一旦その後すべてリベースしてまとめてみたいな。
リベースじゃねえわ。
すべてリセットしてまとめて、
新しいコミットとして作るっていうのは置いといて、
一旦適当にコミットしてってっていうルールがあるから、
それで一回プッシュしちゃえば、
みんなプルして書いて、プルして書いてができるから、
そのようにやっている。
なるほど。
あと何かあるかな。ちょっと見てみよう。
基本的にはそういう交代のルールであったりとか、
そのモブの立ち位置的な部分とか、
モブプログラミングの実践
書いてある通りにやっているかな。
なるほどね。
そんなに複雑なルールがあるっていうわけではなくて。
そうだね。
そうだね。
言われているのは、
5回くらいは行おうっていうところと、
あと時間は2時間程度で切るとかかな。
モブのインターバルはタイマーを10分にしてセットして、
それを繰り返す。
で、レトロをやる。
うまくいったこと、いかなかったことを改善とか。
うん。
それは本に書いてある通りのことをやっているかな。
あとタイピストになる、いわゆるコードを書く人は1人だけで、
他の人がしてくれと言ったことを取り入れて実装する。
うんうん。
で、モブが言ったことを理解して、
分かんなかったら質問する。
で、してくれと言われたことは実装する。
で、そうだね。
多分これだね。
他のモブを信頼し、
自分では試さないアプローチも躊躇せず試すっていうところが、
なるほどね。
コードを書く人、タイピストを交代する価値。
それあるよな。
信頼大事だな。
他の人が言った意見に対してさ、
こっちのほうがいいんじゃないかって多分あると思うんだけど。
そう、あるよね。分かるよ。
どうなんのそれ。
そういう時は、さっき書いてあった通り、
その人が言ったものをまず書く、タイピストは。
書くんだ。
そう、書いてから、なんかどっかにね、書いてから、
そう、コードを書いていない状態で反対はしない。
コードで表現されてから初めて反論する。
なるほど。
面白い。
だからね、みんな書いてるんで、書いた後に、
これ違うんじゃないみたいな。
じゃあ一回受け入れはされるんだ。
そうそうそうそう。だから形にはね、なるからね。
なるほどなるほど。
あ、おもろいねそれ、確かに。
書いた後、ガッと消したこととかもあるし。
へー。
なんならコミット消したこともあるし。
あー、そうです。
うん。
まあでもそれがやっぱり、コードを書くこと次第っていうか、
知識の共有が目的なら、そういう行動も全然、
やってよしっていうことになるんですね。
うんうん。なるほどね。
確かにそれ、やっぱそれがなんか、
コードを書くこと次第が大事目的とか、
勘違いしちゃうと、その書いて消すっていうのを、
なんでそんなことやってるんだって捉えちゃいがちな気がするんですけど。
うんうん。
まあ、知識を共有したいんですっていう目的で捉えてみると、
もう全然それもどんどんやっていいんだなって。
そっかそっか。
捉え方ができますな。
効率集にはなっちゃダメなんだな、きっと。
たぶんね、そう。なんか、それこそ、
なんか、モブプロの中でも価値提供を早く行うっていうのはあるんだけど、
まあ短期的にはね、もう必ずベロシティはね、低下すると思うんですよ。
うーん。
だからその期間において、
もう1週間くらいで提供しなきゃいけないものをモブでやろうは、
たぶん違くて、
そのある一定数、
コースに余裕がなきゃいけないかなとは思ってて、
ただそのコースを取ったら長期的には、
時間を短くするみたいなところに貢献するから、
効率集は無関連。
後々効率集になってくださいって感じかな。
知識共有の意義
ってことやな。
なるほどなるほど。
めっちゃ勉強になりました。
いやー、僕も勉強になった。
でもそんな風に知識入れてやることって少ないよね。
ないね。
分かる分かる。
間違ったというか、
自分たちの知ってる方法でやっちゃおうみたいな話にはなるからね。
1回正しいスタイルでやってみようは、
なんかモブプロだけじゃなくて、
他の子と言うのも言えるかなって。
確かに確かに。
大事だね。
主張りっすなやっぱ。
思った、主張り。
主張り。
なんだったっけ主張りって、
主が捨てる、違う。
守る守る。
破る。
破る。
離れる。
守る破る。
離れる。
最初はルール曲がって。
やばいバカがバレる。
で、ちょっとずつルールを自分なりの改善とか変えてって破ってって、
最後そのルールが離れて、
オリジナルのやり方で試していくみたいな感じ。
最初から捨てちゃダメですね。
最初から捨てると何もやらしてない。
いろいろ聞けましたけれども、
モブプロの良さを認識できたということで、
良い回になったのではと思います。
いつかモブプロやりたいな。
そうですね。
僕も解析したくなったらやりたいな。
ぜひぜひ。
はい。
ということで、
この番組を気に入っていただけた方は、
Spotify、Apple Podcasts、YouTubeなどで番組フォローをお待ちしております。
レビューもぜひよろしくお願いします。
お便りも募集しています。
放送の概要欄にあるリンクからどしどし送ってください。
Xで感想をつぶやく場合は、
ハッシュタグITトリオでお願いします。
それではまた来週お会いしましょう。
ありがとうございました。
ありがとうございました。
27:56

コメント

スクロール