モブ○○の期待できる効果と逆効果

じゃあどうすればよかったのところで、本当は、モブが機能を増やしたり複雑にしようとするところを止める人が必要だった、ということなんでしょうねぇ。 / “だんだん開発スピードが遅くなっていくのをどうやってとめたら良かったんだろう…” https://t.co/ldbxDhP3zS

モブプログラミングについてのリツイートが割と反応があって、ちょっとモブプログラミングについて思うことをつらつらと書き綴ってみようと。日曜だし、まったりと。

ポジショントークすると、モブプログラミングのようなモブ○○はやる機会をたくさん作った方が良いと思っている派です。何が良いと思っているかというと、育成の機会が作れるから。

過去のエントリで書いているように、特に、トラブル時のレポートの作成などは特定のメンバ、つまりアーキテクトやSEリーダに偏るものです。

どうしても中堅より若いメンバは学ぶ機会が皆無で、いざ必要となったとき経験がなくて右往左往するのでそうしたケースを回避するための学習の機会として推しています。

モブデザイン（今作った言葉）は。上流工程でのデザインや結合試験や総合試験などの試験仕様の制約などを上流工程で検討することはメンバ間での言葉の統一やデザインの背景を共有するためにとても効果のあるツールになります。

モブデザインでは言葉の意味や適用範囲を参加するメンバで共有し、その場でデザインに織り込まれていくので個々のメンバが言葉に接するより誤謬が明らかに減ります。これはぐるりと回って、言葉を理解するためのコミュニケーションコストに効いてきます。

技術移転のためというのは、若手や中堅のメンバの技術レベルを上げるためのモブプログラミングやモブ仕様デザインは効果のあるモブではないかと思うのです。

考え方は前述の経験の場のモブと同じですが、目的は技術レベルを引き上げるための知識、技術を知り、身につけさせるためのモブ。

これにはチームとしてどこのラインを下限とするか、チームの目標を可視化することが必要で、それに未達なメンバを他のメンバがモブの形態で支えるということが必要と思うのです。

難しいのは、引き上げ対象のメンバの心理的な負担でしょうか。得てして、対峙する構図ができてしまいがちですがそれを牽制する役割もモブで支えるメンバに明確に伝えなければ効果は得られないでしょう。

一方、やっても意味、効果のないモブもあります。それが冒頭のケース。モブは良い意味での群衆にならなくては意味がありません。モブなのに黙っていたらモブにさえなれません。

モブ○○でのモブは同じようにタイピングするメンバに対して、タイピングするメンバに知識や考えを伝えるのが役割なのですから。そうすると、批判めいたことを発言するメンバに対しても周りから伝え方をフィードバックする必要もあるでしょう。

一日のモブ○○の最後には、そうしたフィードバックの場を設けると良いです。