モブプログラミングもあくまで「問題解決の"手段"である」という話

公開:2020/11/07
更新:2020/11/07
4 min読了の目安(約3700字IDEAアイデア記事

はてなでやれって感じなんですが……
この記事が先日伸びてていろんな話がTwitterでも聞こえてきたので
私のモブプロの経験から感じたことを書き綴っておきます。

前提

2人だとペアプロだと思うので、
この記事では3人以上で取り組むことをモブプロとします。

私のモブプロ経験

私がこれまでに経験したモブプロは以下のような物でした。
ポイントは、いずれも目的をもち、問題を意識し、問題が解決できれば終了としたことです。


  • チームメンバに新しく人が数人入ってきた時のOJT
    • パワーレベリング(レベル上げ)が目的
    • ナビゲータとして一番詳しい自分(筆者)が参加。ドライバー(正確には後述するタイピスト)も行う。
    • 元記事の言葉を借りるなら「レクチャー」であったとも言える
    • 誰かが詰まるところはみんなも詰まる可能性がある
    • できないのは自分だけではない、みんなできないから安心して欲しいという想い
    • 一定のレベルまで全員が到達できたなら、スケジュールは終了

  • DXの刷新などでチームメンバが一斉に新しいことに取り組まないといけなくなったとき
    • これもパワーレベリング(レベル上げ)が目的
    • 参加者の誰かが知っていることに取り組むわけではない(最低限のマニュアルは作ってある)
    • 誰かが詰まるところはみんなも詰まる可能性がある
    • できないのは自分だけではない、みんなできないから安心して欲しいという想い
    • マニュアル配って読んどいてね、よりも実践を伴う方が定着が早い
    • 認知が広がればそれでスケジュールは終了

  • 社内の誰もがわからない、誰がやっても「つらい」作業のモブプロ
    • 人員の異動(含む退職)などで誰がやっても「つらい」作業
      • 誰も仕組みを知らないコードを改修しないといけなくなった、など
    • 参加者の誰かが知っていることに取り組むわけではない
    • 誰もが調べながらじゃないとできなくなってしまっている作業
    • 一人でとり組むのはつらい、でもモブなら「つらい」を分かち合える。学びも分かち合える。
    • 調べてドキュメント化しといたから読んどいてね、ではうまく引き継げないこともある
      • そしてまた誰かが「つらい」になるループ。そんなのは、もうたくさんだ!
      • 竜退治(技術負債との戦い)にはもう飽きた
    • 問題の解決が完了すれば、それでスケジュールは終わり
      • 次の「つらい」と一人で闘うかみんなで闘うかはまたその時その時相談

ドライバーとナビゲーター、タイピスト

モブプロにはいろんな手法がありますが、
私が参加したモブプロはいずれも「ドライバー」と言われる「今キーボードを触っている人」を
「タイピスト」としました。思考と指示を行うのは「ナビゲータ」ですね。

もちろん、別に言葉を変えることそのものに意味はないのですが、
「ドライバー」は「運転者」であり、その人も思考に参加するような印象をもちますが
「タイピスト」は「打ち込む人」であり、「聴く」と「手を動かす」に集中して作業してもらいます。

こうすることで、参加者の中で現在取り組んでいる問題に対しての理解が高い人が
「思考」に参加しない(できない)タイミングがくることで、
自ずとその時の「ナビゲータ」達でどうにか考える必要が発生し、「ナビゲータ」の成長を促します。

自分が一番デキるときに「タイピスト」を担当する順番のときはヤキモキすることもありますが、
「聴く」に集中することで「こういうところで詰まるのか」がわかる、というメリットを享受できます。
人間、「わかって」しまうと「わからない」が「わからない」になってしまうものです。

問題解決の"手段"である

前述しましたが、いずれのモブプロでも

いずれも目的をもち、問題を意識し、問題が解決できれば終了とした

をやっています。
これは私の持論ですが、モブプロはあくまで手段であり、問題としているものの「解決」が目標のはずです。

組織内のレベル差が「問題」なのであればそれを解決するのが目的。
「誰も知らない」くて「機能改修と闘うのがつらい」ので「機能改修できない」のであれば
「機能改修が完了すること」が目的のはずです。

その目標が達成できるかどうか、その手段としてモブプロが適していると判断したのなら実施すべきです。
問題を解決する方法として、マニュアル配布やタスクの割り振りなどでどうにかするのもそれぞれ手段。
PDCAでも、OODAでも何でもいいのですが、
今の「手段」が正しいのかどうかは常に意識して取り組みたい。
そのためにも、モブプロ1単位が終わった時には「ふりかえり」を毎回やりたいですね。

そして「手段」としてモブプロが適していなのではないか? という声には
常に真摯に向き合いたい。それでこそ「手段」としてのモブプロです。

誰もが陥りがちな「手段の目的化」

  • なんか流行ってるらしいからモブプロしてみよう
  • なんでうちの組織はモブプロ文化ないんだ? 取り入れよう!

みたいなモブプロをやる事そのものが目的になってしまっては
モブプロのメリットが享受できないのはいうまでもないですが、
最初は目的を持って始めた物であっても、週1スケジュール開催を複数回まわしてるうちに
「なんでこれやってるんだっけ?」となることは往々にしてよくある話だと思います。

本来、人間という生き物が3人以上集まって何かを行う、というのは非常に難しいことです。
三人四脚をやったことがある人ならわかるはずです。一歩前に進むことすら難しい。
難しいことをやるからこそ、やっただけで何かを成し遂げた様な気持ちになるのもしょうがないことです。

決起会や集会なども、繰り返し行っているうちに何のための会なのか?がわからなくなります。
飽きるほど言われているのに、陥ってしまうのが「手段の目的化」です。

だからこそ、「何でモブプロやってるんだっけ?」は常に考えて実施していきましょう。

モブプロが苦手でもいいじゃない

ここまで偉そうに書いてきましたが、
私も前述のモブプロの『社内の誰もがわからない、誰がやっても「つらい」作業のモブプロ』については
「申し訳ないが、私は一人で取り組んだ方が進みが早い。
 改修のケツがある以上、確かに私もつらいが今は一人でやらせてくれ」
と言ってモブプロから抜けたことがあります。

結局、これはこれでその時の「機能改修が完了すること」という目的は達成できましたし
実際に最速で改修を行えた自信はあります。

大事なのはそれを言い出せたこと、それを受け入れてくれる仲間がいたことです。
苦手なら苦手という。それを言い出すだけの心理的安全が組織で取れているか。
チームでの開発がほぼどこででも行われている今、
これができていないのならそこはモブプロで解決しようとしている問題以上の問題が発生しているように感じます。


ところで、はてブにありがちなブコメだな、と笑ってしまいましたが元記事のブコメにも

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

なんてのがありましたが、じゃあそれを風潮とかを待たずに自分で発信すればいいんですよね。
まぁ便所の落書きにマジレスする私も低能なんでこれ以上はやめておきますが。

それでもモブプロをやったことがないひとは1度はやってみて欲しい

モブプロには複数人で取り組むことによって解決できる事があります。
そして、複数人でやるからこその楽しさがあります。

問題を解決する、目的を達成する手段の一つとして選択し得るだけの価値がある物だと、私は感じています。
もし、やったことがないという人は勇気を持って言い出して、そしてやってみてください。
やり終わったら、どうだったか、効果はありそうか、嫌な人はいなかったか、ふりかえりしましょう。

もしこの記事をみて、モブプロやってみた!やってみたけどダメだった!みたいなことがあったら、
Twitterなどで教えてくれると、嬉しいです。