BaHo Advent Calendar 2020 14 日目担当の BaHo 猫 です。
今日で 12 月も 2 週間が経過しました。 約半月です。 せめて 12 月は何かをやって終わりたいと思っているそこのあなた、あと 0.5 か月しか残ってないですよ。
モブプログラミングとは
モブプログラミングは、1 人の画面を動かす人(ドライバー)と複数人の(手を動かさずに考える人)ナビゲーターというロールに分かれて同じタスクを一緒にこなす開発手法です。
モブプロは何が良いのか
まず、あなたが開発をする時にはどのような仕草をするか考えてみてください。 自身の既存知識では達成できない課題が現れたときはどうするでしょうか。 多くの人は、ドキュメントやコードを読んで課題を理解するところから始めると思います。 モブプログラミングでは同じ課題に取り組む人が複数人いるため、このような場合に調査行動の並列数が増えます。 当たり前ですが。 もちろん参加者の中に既存知識として解決策を会得している人がいれば、調査というプロセスを省略することが可能です。
モブプログラミングの利点はこれだけではありません。
例えばリファクタリング。 複数人が記述されているコードを監視しているため、開発段階ですでに複数人のレビュー相当のものが実施されています。 これによりコードの品質が担保されたり、メンバーにコードの承認者がいれば承認工程も省略することが可能です。
例えばオンボーディング 入社直後の新人とペアプログラミング、なんてオンボーディングを聞いたことがあるかもしれませんが、モブプログラミングも例にもれず同様の利点を享受できます。
モブプログラミングの現実
では実際、モブプログラミングではどのような問題が発生するのでしょうか。
モブプログラミングの元祖、Hunter Industriesでは、より良いモブを実践するために必要なロールを提唱しています。
https://github.com/willemlarsen/mobprogrammingrpg/blob/master/Mob%20Gallery.pdf
詳しいことは解説しませんが、ロールが増えるほどモブが習熟し活性化するという話をしています。
図の通りに行けば、モブを最大限活性化させるには最低 7 人のメンバーが必要です。 7 人でモブを結成したとすると、1 タスク当たりにかなりの人的リソースを掛けることになります。 また、Hunter Industries はロールやメンバーを増やした際にモブの文化が壊れないように 1 か月あたりの新規メンバー数を制限しています。 このことから、複数人の新規メンバー採用を考えているチームでモブをオンボーディングに利用する、という利点が失われます。 また、モブの文化を浸透させて最大限モブを活用するためには相当な時間と労力が必要になると考えられます。 (実際、Hunter Industries が入社制限を設けていることからも文化の醸造や維持が難しいことが伺える。)
では、モブ当たりの人数を減らしてみてはどうかという話になる。 モブの人数を少なくすると、必然的に利用できるロールが少なくなる。 3 人モブの場合、レベル 1 が 2 人とレベル 2 が 1 人、もしくはレベル 1 が 3 人のチーム構成になる。
ロールが少ない場合、より高度な役割を選択できないのでモブ内で明確な役割が持てないという問題が発生する。 レベルの低いロールは相対的に専門性が低く(もちろん、仕事のレベルが低いというわけではない)、モブ内でどのような立場にいてチームに貢献したかという対外的な評価指標を失うことにつながる。 「対外的な評価よりも実際何をやったかでは」と言いたい人がいるのもわかるが、実際に長期間そのような環境でモブを実施している人が自己承認できなくなってしまう場面をよく目にした。
つながると、つよい
今回は、モブプログラミングはモブチームが文化的に完成していればとても強い開発能力を生む一方で、中途半端な形で実施をしているととてもつらいという話でした。
TAKAKING22 さんという方のモブチームは、チームごと転職活動をする等、とてもチーム文化を大事にしていることが伺えます。
チームファーストな開発体験を求めている人にはぜひ実践してもらいたい手法であると同時に、コスト削減といった安易な名目で採用するのはやめておけ、という言葉でこの記事を示させて頂きます。