モブプログラミングに向いてない私の話 - 誰かの役に立てばいいブログ

新型コロナウィルスの影響も長引いてますが、皆さま無事お過ごしでしょうか。私は幸い無事です。 日ごろチームでソフトウェア開発をしているのですが、近年社内ではペアプログラミングやモブプログラミングが流行しています。 私のいるチームでもここ二年ほどモブプログラミング（ないし類似のプラクティス）に取り組んできました。 モブプログラミングについて正確にどのようなものかは以下の記事などをご参照いただければと思います。 簡単にまとめると、要求分析やコーディング等幅広い開発作業を、同じ場所に集まったチームの共同作業でこなしていくというものです。 このご時世ですので、最近はオンラインのミーティングルームに集合する形式でしたけど。 www.agilealliance.org ここから先は、非常にパーソナルな、私に限定された体験になります。 どの人・チームにも適用できる話ではありません。ではありますが、どの人・

[ngsw]

できる人はそう考えるのだろうな、という想像をした / 別の見方をすると「優秀なその人を他の人が参考にできる機会である」とも考えた。その義務があるかはこれまた別の話ではある

[findup]

デキる人が一人でガーっと作るほうが早いはその通り。モブはあくまでチーム内の平準化なのでは。

[matsumoto_r]

めちゃくちゃわかる…似た現象は論文でもある。多分こういう話はこの手の立場の人がちゃんと客観的にそのプラクティスを評価してあげないとそれこそみんなは惰性でやることになるというのはありそう

[hazeblog]

わかる。モブプロやらなくなった / 弊社記事紹介されてる

[kuni-kuni]

あー、やっとモブを否定しても許される風潮になってきてよかった。あんなのただ仕事してるふりしたい人のためのクソ効率悪い儀式だよ。

[tdakak]

たまにみんなでわいわいするくらいが好き、いつもだとちょっと疲れる

[onk]

「流す」わかる。すべての時間がモブプロになると研鑽時間取れないのもわかる。

[jksy]

僕も集中できなくてイヤ

[shikiarai]

モブに参加してもらう人自体がそもそも成長欲がないと全部ベテランに丸投げしてしまうから駄目よ

[minamijoyo]

早く行きたいなら一人で行け、遠くへ行きたいならみんなで行け

[strawberryhunter]

ペアプログラミングでさえ非効率だと思うのに3人以上でやるのは狂気。実践している会社は人件費と生産性をきちんと計測しているのか気になる。

[roshi]

「レクチャー」をどうやられているのか気になる。

[ene0kcal]

モブでもペアでもデメリットはある。それを上手く扱えるようにするのが運用（方針）。

[pmint]

それで良いし、効果もあるのでは。そもそもモブなんだから自己主張しちゃダメじゃないの。まずはメンバー全員を「メンバーA」「メンバーB」のように呼ばないと。そのぶん責任が個人にのしかかることは無くなる。

[takatama]

アジャイル開発全般がそうなのだけれど、強い人が集まる前提のプラクティス

[raimon49]

品質についての妥協が生じるケースがあるのはわかる。圧倒的に経験値を持ってる人に何を期待するかという組織の方針に依るのだと思う。

[honma200]

上手くいった例だと新人教育の集合研修かな？それでもできる子の足は引っ張ったなー知識の曖昧な点を補強する目的はあったけど

[ryz310]

記事には禿同。とはいえ自分はモブプロは有用だと思っていて、自分のチームではプロジェクト初期の共通認識が必要なフェーズだけモブプロでやって、中盤以降はソロ開発＆レビューに移行しています。

[MtAsuka]

モブプロってそもそも週に1回とか短時間でやるものじゃないのか。ペア/モブプロは他人の仕事の進め方を学べるという意味で適度にやるのは効果的だけど、やりすぎると単にサボりの時間にしてしまう人が出てくるし。

[aceraceae]

モブもペアも嫌だな。なんだかんだいってソロ開発しかしたことないしそれしかできない気がする。モブなんかやったらもうめんどくさいから全力で周りに振って自分はたんぽぽ乗せしてるかもしれない。

[JUNKI_fugly]

この記事読んで感じたことのメモ https://zenn.dev/junki555/articles/ff97d7aa9f87d797d30c

[diveintounlimit]

軽く調べてみたけどこれチームの時間めちゃ奪うし基本無しかなと思った。全員参加の会議みたいな印象。

[ptpadan]

リモートなってからモブ、ペアでやることおおいけど、リモートモブ、ペアならよりよい実装を別で試したり思索できるから、うちだとワークしてる気がする。

[tpircs]

モブプロに限らず、自分が尊敬できて学べると思うメンバーが少ない職場で成長を望むのは難しい気がする。組織による向上を望むなら転職フラグ立ってるんじゃないかなぁ。

[noir_k]

ありがたい経験談。

[door-s-dev]

やった事ないけど、やりたいとも思わない。

[Shisama]

「流す」よくやってしまう。惰性モブもめちゃくちゃわかる。あとモブの人数も多いと何もしない人が発生しがち。意思決定が必要なタスクは必要な人だけでモブをする、それ以外のタスクは個人で進めるが良いと思う

[usagizmo]

VSCode Live Shareでみんなでガツガツ書いて、あとでGit差分見てコミットしてる。

[yug1224]

レベル差が大きいといつまで経っても仕事回せないんだよね。技を伝えて下限を引き上げるため、最初からレクチャーするためにペアやモブをやることが自分は多かった。高レベル同士ならPR上での議論で問題ないしね。

[PEEE]

わかる

[t-murachi]

ずっと仲良くだと馴れ合いになっちゃうからね。競争原理も必要 (そういう話じゃない?)

[yukiyan_w]

めちゃくちゃよくわかる。平準化が目的なんだろうけど、そうなるとデキる人がどんどんレクチャーに疲弊していくのもよくみる。

[aktkro]

こういう「メリデメあるから目的をハッキリさせて適宜導入するといい」的な話よくあるせど、なんでやる前に気づかないんだろうか。盲目的に手法を導入したがる人がいる組織だとそうなっちゃうのかな。

[iwashi86]

"それと、レビューがいい加減になる傾向もありました。モブ中に見ているはずだからと成果物をしっかり一から見直さずにマージする。 「皆が見ている」は存外「皆が見落としている」可能性を孕んでいます。"

[onesplat]

開発時間の全てをモブプロなんて頭おかしやろ。たま〜にやるからええんやで、ああいうのは

[public_key]

すごくわかる。モブプロってたまに人がたくさんいたほうが良い場面に対応するためにそれ以外のほとんどの時間も全振りする効率が悪いイメージ

[koogawa]

なるほどなぁ