MOBプログラミングの基礎
こんにちは、mossanです。今回はMOBプログラミングについて紹介したいと思います。こちらすでにノートや禅に記事が上がってますので、それをもとに紹介していきたいと思います。
こちらの記事ですが、書籍Code is the wisdom of the cloudというMOBプロの本の読書メモ的な内容を記事にしたものです。
一般的な読書メモとは違って、読書している時に出てきた用語であったりだとか、その時学んだ概念であったりだとか、またその読んだ内容から新たに生じた疑問点、そういったものを随時チャットGPTに投げて、その結果をもとに構成しています。
ですので、書籍の内容そのままというわけではありませんが、書籍で得られるような知見は同様に得られるというような内容になっています。
また、チャットGPTの結果を使ってはいますが、内容的におかしい箇所に関しては手動で修正、もしくは場合によって削除もしています。
では、内容の方に行きたいと思います。
そもそもMob Programmingとは何なのかというところなんですけれども、知っている方も多いと思いますが、複数のチームメンバー、下りには3名以上が同時にプログラミングするというようなイメージのものです。
例としては、1人だけドライバーというコードを書く人がいて、残りの人は全員ナビゲーター、もしくはモブというふうにも言ったりしますという形になります。
ナビゲーターがこういうふうにコードを書いたらいいんじゃないのだとか、そういった意見を出しながら、それをドライバーが実装していくという流れになります。
ポイントとしては、みんなで同時に同じ画面を見ながら、同じ時間共有して問題に対して解決するコードを組み上げていくという中でですね、
近い概念でペアプログラミングというものがありますが、あれが2人でやるのに対してMob Programmingが3人以上というところが大きな違いになっています。
もうプログラミングの特徴ですが、先ほど言ったように3人以上の集団作業であり、同時に同じコンピューターで作業しますよと。
あと先ほどドライバーが1人と言いましたが、これも決まった時間で順次入れ替わっていきますので、ローテーションでドライバーを書いていきます。
またコーディングしながら即時、あでもないこうでもないとナビゲーターから指示が入ってくるという感じになってくる。
そうすることでリアルタイムにどんどんどんどん良くなってくるという感じですね。
またコーディングをやっている様自体をみんなで共有するので、コーディングの時のある種のチップスというか、
ショートカットキーでこういうのを使えるようだとか、こういう風にするともっといいよみたいな、そういった知識も共有できたりします。
またコードに対するドメインの知識的なものも共有できるかもしれません。
あと全員が同時に改善を行うということによって、コードの品質が上がりやすいということがあるらしいです。
私もそんなやったことないんでよくわかんないですが。
あと同時にみんなで同じ空間をシェアして行うというところで学習がより促進されるというところはあるかと思います。
他のメンバーから新人メンバーで与えたとか、そうじゃなくてもメンバー間での学習促進はあるかと思います。
モブプログラミングの流れ
先ほどペアプログラミングの人数増やした版みたいなもんだよっていうようなところは言いましたが、
マークダウンのテーブルをそのままこのモートに貼っちゃってるんで、テキストが大きいわからないことになってますが、
ZENの方の記事ではテーブルがあるので、そちらの方を見ていきたいと思います。
違いですが、先ほど言ったようにペアプログラミングが2人なのに対して3人以上でやりますよと、基本的には同じような感じなのですが、
このテーブルでは特に書かれてはいませんが、ペアプログラミングの場合だと意見がバッティングすると、
そこでぶつかってなかなか収束しないというところがあるんですが、モブプログラミングの方が3人以上なので、
ひとりの意見が極端に強くなりすぎることが比較的起こらずにトラブルになりにくいというのがあると書籍の方では書かれていました。
これもケースバイケースだと思いますが、では実際のプログラミングの進め方の流れを見ていきたいと思います。
モブプログラミングは大きく3つのステージに分かれています。
トータルでここら辺も実際にやるケース次第ですが、標準的には2時間ぐらいが目安だというふうに書かれていました。
ここではその標準的な時間をベースに大体の時間を書いています。
まず最初に20分から30分ぐらいかけて下準備を行います。
ジャミとしては、まずモブプログラミング自体に慣れていないような場合は、そもそもモブプログラミングとは何なのかということであったりだとか、
あとはそれぞれのロール、ナビゲーターやドライバーがどういった役割でどういうことに注意すべきかみたいなところを紹介してあげる必要があるかと思います。
これら当然何回もやっているような場合は省略は可能だと思います。
続いて行うのが今回のモブプログラミングにおいてどういった問題を解こうとしているのかというところを背景であったりだとか、どういったところを解いてるんだよみたいなところを紹介します。
この2つがメインであって、最後にどういう順番でタイピストを行うのかという順序決めを行います。
モブプログラミングの実践
この例自体はそこまで重要ではないので、じゃんけんないなんないですぐに決めてもらえればと思います。
これが3つあるステージのうちの1つ目のステージと準備のステージになります。
2つ目のステージが一番でかくて実際にモビングプログラミングを行うステージです。
このモビング大体1時間半ぐらい全体の中の7割ぐらいを割り当てて、目安としては10分ぐらいで切り替えていくというような感じになります。
基本的にはずっとコーディングして、時間が経ったら次のドライバーに変わって、ひたすら繰り返していくという感じですね。
なのでそこまで特殊なことはしていません。ひたすらコーディングいるかあるかという感じです。
それが残り20分になるまで続けていくという感じですね。
最後残りの20分で今回のモビングに対して振り返りを行います。
ここの振り返りの手法に関しては、一般的なアジャイルの振り返りのブラックディスを使ってもいいっぽいですかね。
書籍の方でもいわゆる帽子を変えるみたいなやつありますけれども、開いたのを使って振り返りを行っていました。
お好みの振り返り手法を使っていただいて、何かうまくいったことだとか、いかなかったことだとか、次どういうふうに修正しようかみたいなところを決めるって感じで、
そこら辺は各環境において最適なものを選んでいただければいいかなというふうに思います。
これがですね、Mobile Learningの3つのステージです。
ナビゲーターとドライバーの役割
これらをトータルで2時間ぐらいで行うという感じですね。
続いて明確なコミュニケーションと書いてますが、わかんないことがあったら、もしくは曖昧だなと思ったらすぐに質問するようにしましょう。
曖昧な内容をその前にしておいてしまうと、バグを仕込んでしまったりする恐れがありますので、随時今何をやっているのか、どういう指示を出されているのかを明確にするようにしましょう。
続いては特にエキスパートの人に気をつけてほしいところではありますが、速度をいい感じに頼もしましょうというところですね。
結構慣れた人だとバンバンタイミングしがちですけれども、他の人が今コードエディター上でどういうことが起こっているのかを追従できるように、
それこそやっていることを自分で話しながらコーディングしたいだとか、あとは特殊なショートカットキーとかを使うときはそれについても説明をするなども重要ですし、
そのように他の人たちを置いてきぼいにしないように気をつけた方がいいかと思います。
また読みやすいコードを書きましょうというのは当然なので、そうしましょうというところですし、
あと切り替えの時ですね、これはここにはちょっと書かれてはいませんけれども、時間が来たんだけどもあと少しで書けそうだからってついつい書きたくなるんですけれども、
そこはもう時間をきっちりと切り上げて次の人にすぐに書いてもらうようにしてください。
あとツールや環境に関してはみんなが同じツールにおよびセッティングに慣れておく、
そこら辺について事前に合意をしておいてセットアップしておくというところが重要になってきます。
なのでこのエディターで一般的にはデフォートの設定を使うというふうになると思うんですけれども、
そういうふうにしておくことによって、このタイピストが変わった時にこのツール慣れてないんですってのがちょっと避けられるようにした方がいいかと思います。
あと細かいところではありますが、行番号とかを表示しておくことで指示を出しやすくしておくとかも基本のことなのでそれはやっといていただければと思います。
続けてナビゲーターの方が気をつけるべきことを共有したいと思います。
まず明確な指示ですね。コーディングするにあたって何を実装したらいいのかわからないような指示はやめてほうがいいので、
それこそこの何行目にどういうふうなコードを書いてっていうのを明確に指示すると。
特に行番号を指示する場合には相対的に今カーソルがあるところから下行を下がってとかじゃなくて、
何行目っていう絶対値の行番号で指定してあげることが重要になります。
カーソルは常に動くので相対的な内容だと理解ができなかったりします。
あと書く内容についても明確に何を書くのかというところを指示してあげるのが重要かと思います。
あとは積極的なコミュニケーションですが、これは当然ナビゲーターが全然しゃべらないと話にならないので積極的に
指示があったりだとか場合によっては質問も含めて投げていくというのが重要になるかと思います。
あとドライバーのペースを尊重するというところで、先ほどエキスパートが急ぎすぎるというところがありましたが、
ドライバーの方も習熟度はバラバラだったりするので、その人のペースで書けるようにあまり急かしすぎたりしないようにしてあげた方がいいかと思います。
続きまして、解く問題についてちょっと話していきたいとおもいます。
向いている問題
モブプログラミングではあるんですが、向いてる問題と向いてない問題というのがありまして、そこらへんをちょっと雰囲気つかんでもらいたいなというふうに思います。
まずモブプログラミングが向いている問題ですが、ある程度複雑な問題は結構モブプログラミングが向いてるんじゃないかなというふうに思います。
いわゆる3人ヨーダーはモンジューの中枝じゃないですけれども、複数人の頭脳を使って一人だとちょっと時間かかってしまうような問題に対しても、
モブプログラミングであれば解決策を出せるというところはあるのかもしれません。
あとコードの品質を上げるというところで、リファクタリングだとかそこの辺をみんなで一緒にやるっていうのもある意味ありつやありかなというふうには思います。
特にこれは側向いているような場合だとリファクタリングにおいてのどういうふうに直すのが適切かというところの合意が取れてないようなケースですね。
すでにどういうふうにリファクタリングした方がいいですよみたいなところがもうルールかもしくは文化が築き上がっているようなところであればまあいい。
わざわざモブプログラミングする必要はないと思うんですが、
そこがまだできてないような組織でおいてはこういった用途にモブプログラミングでこういうふうに直した方がいいんじゃないのっていうのをああでもないこうでもないといってみんなで最適解を求めるっていうのは手がともいます。
あとここには書かれていませんが、いわゆるコード型というかリードコード的な問題ですね。
ああいった特定の小さい問題をみんなで解くっていうのも結構向いている問題というふうな感じで挙げられていました。
特に練習とかではそういうリードコードとかの問題を解くのがおすすめらしいです。
逆にモブプログラミングが向いてない問題としてはまあ単調の問題ですね。
まあ誰でもこれやりやすぐ解けるでしょうみたいなやつをまあ複数の頭脳を使ってやる必要はないですからそういった問題に関してはわざわざやる必要はないかなと。
また複数人で集まってもすぐには答えが出ないような極度に専門的な問題もちょっと向いてないと思われます。
まあそういった場合にはちょっとあのこの後の説でどういうふうにすればいいかというところは後で話します。
ちょっとその前にまた時間が結構限られているような場合ですね。
まあリリース前直前のところで明日までリリースしなきゃいけないみたいな時にやるのはまあそっちを向いている時もあるのかもしれませんが、
まあそういうふうにあまり時間のないときは特定のデバッグとかは向いているのかもしれませんがそうじゃない場合は適応しない方がいいかなというふうに思います。
で先ほどの極度に専門的な問題、要は数に答えが出ないような問題に対する対処策として実際にこちら小説の方でも書かれてた対策案としまして、
この場合だとこの1の研究時間ってやつですね。この緊急時間を設けるっていうのがですね一つ対策の案かと思います。
これどういったものかと言いますと一旦ちょっとMOVプログラミング、一つのコンピューターでみんなで作業するという前提でしたがそれをちょっと解除しまして各人が自分個人個人でこの今抱えている問題をどうやって解決すればいいかってのをそれぞれ調べます。
調べてそれで何か糸消しとかが見つかったら随時メンバー間に共有しつつ、何か解けそうってなったらみんなで解いていくという感じですね。
そういった感じの個人個人で調べる緊急時間というのを設けるというのはありかと思います。
それ以外にもGPT的には専門家に聞いたりだとか、一旦ちょっと落ち着こうって感じで置いた時間を空けたりだとか、
もしくはその仮説自体を問い直したとか、いろんなそういったアプローチが提案されてて確かにそうだなというような内容でしたので紹介しておきたいと思います。
MOVプログラミングにおける人間関係の重要性
続きましてMOVプログラミングにおける人間関係の重要さというところを紹介したいと思います。
MOVプログラミングはみんなで一緒にやるので、当然人間関係が良くないとうまく機能しないというのは想像できるかと思いますが、実際そうです。
そういう意味ではこのMOVプログラミングを効率的に行えるチーム状態ってどういう状態なのっていうのをここにいくつか挙げています。
まず一つ目が尊重と信頼というところで、互いに必要が引っ迫とし合いましょうねというところで、あとはオープンなコミュニケーションというところですね。
この1-2ですね、あとその3-2プラスの3強調性、3-2-4の共感というところ、ここの1-4でほぼほぼ心理的安全性高いよっていう風に言ってもいいかと思いますが、そういった状態が好ましいっていうのが言えるかと思います。
またですね、Win-Winの思考っていうのも重要だと思われますね。
互いに寄与するのを良しとするっていう状態があるべきかと思います。
そんな感じなのがまず良い状態ですよっていう話なんですが、プログラミングにおける人間関係において結構ハマりがちなトラップと言いますか、良くない状態として挙げられていたのが集団思考、グループシンクというものがあります。
これどういったものかと言いますと、心理的安全性が単純に低いと言ってもいいかと思いますが、そういうのが抜度を逸れて何か言いたいことが言えないというよりは、気を使って言えないっていうのが入ってくるのかなというふうに思いますけれどもですね。
そういったちょっと自分の意見を表明するのをためらうような状況、そういったものがグループシンクという状況かと思われます。
こういうグループシンクに陥らないためには、結局やっぱり先ほど言った心理的安全性を確保するため、確保するためにはどうすればいいのかっていうのはなかなか難しいんですが、
一般的に良しとされている、そういういろんなプラクティスだとか文化形成だとかを、もしくはチームビューティング的なものだとかを行う必要があるというような感じかと思います。
続きまして、まだ人間関係のところ続いてまして、MOBプログラミングにおいてメンバーの個性、強みとか弱みですね、そういったものが結構重要ですよっていうようなところが書かれていました。
ここでいう強み弱みっていうのは、いわゆるストレングスファインダーとかの性格分析的なもので出てくるようなやつのことを指しています。
MOBプログラミングでは、こういった各個人の特性を生かすように工夫をすることで、MOBプログラミングの効率が上がりますよということが書かれていました。
具体的には各人の強みを生かしてあげましょう、逆に弱みを保管してあげましょうだとかですね、そういったところを書いていました。
続きまして、今度はメンバーが新たに入ってくるとき、オンボーディング時ですね、そういったときの注意事項がいくらか書かれています。
ここらへんは多分チームビーディングのプラクティスに結構近いかなというところではあるんですが、練習とかトライアルをやってみると。
また結局ですね、新しく入ってきて、早く馴染んでもらうというところが重要になってきますので、
心理的安全性が確保できるような工夫が重要になってくるんじゃないかなと、この最後に書かれていますが、
結局やっぱり一般的なチームビーディングのノウハウがそのまま生きてくるというところからと思います。
MOBプログラミングのアンチパターン
一旦人間関係のところを終わりまして、ノブプログラミングのアンチパターンというところで、
書籍中で3パターンほど紹介されてましたが、ここでは一つだけのパターンを紹介したいと思います。
具体的にはノブプログラミングを行う人とどういった人の組み合わせがアンチパターンになりがちだよっていうようなところ。
必ずしもなるとは限りないんですけども、ここではエキスパートの人とビギナーの人の組み合わせの場合にダメなケースに陥りがちだよっていうところが紹介されていました。
これは先ほどエキスパートの人がコーディングで暴走してガリガリすんじゃうとかいう話をしましたが、まさにあれを懸念しているというところですね。
そういった感じでまず理解のヤップがありますよっていうところと、あと進行速度が違いますよってところと、あとはですね、
例えばナビゲーターに1人だけエキスパートはいて他は新人っていうふうになった場合に、エキスパートの人の意見がどうしても通ってしまうっていうのはあるかと思います。
そういった意思決定がアンバランスな感じになってしまうっていうのは起きがちかなというふうに思います。
これに対する改善策として、書籍中に述べられたものとして、エキスパートの人をタイピストにするのはやめましょうとナビゲーターに徹してもらいましょうっていうところが挙げられていました。
そうすることでさっき言ったタイピング暴走するっていうのを防ぎるということですね。
ただこの場合ナビゲーターに徹すると先ほど言ったこのコーディングの意見がこのエキスパートに集中するんじゃないかっていう懸念はあるんですが、
そこに関しての補足とか誘拐説明は特にはされてませんでしたね。
あとはですね、その新人の人がちゃんと理解するまでは進めないっていうようなスタイルを貫くっていうのも重要だよみたいなことが書いていたりしました。
そこら辺の7例で出てきた用語としてですね、ストロングスタイドモービングというのがあるらしくて、そちらは用語的に面白かったので紹介させていただきたいと思います。
正直ちょっとこの用語あんまり理解してないんですが、通常のプログラミングよりも結構厳格なスタイルのプログラミングということなのかなというところで、
思考がなければ手を動かさないっていうような感じで、ナビゲーターだなかさせてタイピングするとかいうのを一切許さないみたいな、そういうスタイルのものかなというふうに思います。
そういったのがあるらしいですってところですね。
リソース効率とフロー効率
ここら辺はちょっと面白いんで紹介させていただきました。
このストロングスタイルのプログラミングをやることで、このコーディングする内容が明確に言語化されることで、
ビギナーであろうがエキスパートであろうが、全員が共通の認識を得るというところにつながるのかなとなんとなく想像しています。
細かいことは知らないんで、もしかしたら間違ってるかもしれませんが。
続きまして、もうプログラミングのこちらの本で何度も出てきた用語として、リソース効率とフロー効率という言葉を紹介したいと思います。
ここのリソース効率とフロー効率ですが、リソース効率はこのリソース、プログラミング開発においてはその作業する社員というかプログラマーの開発者が手を動かしているかというイメージですね。
一方でフロー効率というのは、この機能であったりだとか、プロダクトがどれだけ早くリリースされるかというところの効率を指します。
一般的にリソース効率の方に集中しがちなんですが、もうプログラミングではフロー効率を重視します。
なので必ずしもリソース効率が高くなくても良いと。
それだから複数人で同時にプログラミングすると。
なので、ナビゲーターの人以外はある意味手を動かしていないので、リソースが浮いている状態と言えなくもないわけですね。
それなんですけれども、それでも結果的には早く機能がリリースされるというところで、フロー効率が改善するという意味で、このもうプログラミングにおいてはフロー効率が改善するわけです。
このフロー効率ですが、書籍中で高速道路に例えられていて、これが面白かったので紹介したいと思います。
ここでは高速道路にどれだけ車が存在しているかが、リソースがどれだけ使われているかという意味で、
車がどれだけ早く進んでいるかが、フローがどれだけ機能や製品がどれだけ早くリリースされているかというそういうイメージだと思ってください。
リソース効率が良い状態というのは、ある意味高速道路中に車がギュギュギュギュと詰まっている状態になります。
アジャイル開発とリーンシンキング
ですので高速道路のリソースはフルフルで使われている。
ただ車がそれだけ詰まってしまうと、車は早く動くことができません。
ある意味渋滞状態になってしまうわけですね。
ですので時間が過ぎても、なかなか機能がリリースされないという形になります。
一方でフロー効率が良い状態では、高速道路上にあまり車はありません。
ただ各車はビンビン飛ばして、早く目的の状態、つまりリリース状態に向かうことができるというわけですね。
なのでプログラミングでは、この後者のフロー効率の状態を目指しますよという形になります。
続きまして、このフロー効率のところとアジャイル、特にそのリーンシンキング。
リーンシンキングの中でも、看板とかで使われているワーキングプロジェクトWIPとの関係を話したいと思います。
先ほどフロー効率を高めますよというところで、要はリソースはフルフルでは使えませんという話をしました。
ここら辺の話に近いのが、いわゆる看板とかで作業していて、
その作業員にワーキングプロジェクト、それもまさにリソースを一定以下の利用率に抑えることによって、
タスクを切り替えるコンデキストスイッチのロスを削減して、結果的にその作業の効率を上げるという話でしたので、
まさにそれがこのフロー効率を高めるというところと同じになるわけですね。
ここまで長くやってきましたが、モブプログラミングについての話でした。
記事の最後の方ではですね、まあ書籍中に紹介されていた学習における5ステップみたいなやつでして、
初級者から達人までのステップ5ステップありますよと。
でこの書籍で書いてある内容は、まあ小級者からだいたい中級者ぐらいまでですかねの内容であって、
モブプログラミング入門
むしろ達人の部分はちょっと対象外ですよみたいなことを考えてたので、
それでこのドレフェスモデルっていうのが気になったので掲載してます。
ただあまり直接的にかかってくる内容ではないので、ここでは簡単に紹介するにとどめたいと思います。
そんなわけでモブプログラミング入門でした。
私自身あまりモブプログラミングやったことないんですが、
プロジェクトの形態であったりだとか、特に問題であったりでよっては結構使えるのかなという気もしますので、
なんか興味のある方であれば、この本、このCode with a Moza Cloudでなくてもいいかと思いますので、
ちょっと学んでみるといいかもしれません。
以上モブプログラミング入門でした。
