2017/05/29 DevLOVE関西 に参加してモブプログラミングを体験してきました。体験してみての感想などを簡単に書いていきます。なお、今回は東京から@PoohSunnyさんが駆けつけてくれ、モブプログラミングの説明と進行をしてくれました。
モブプログラミングとは？
全員が同じ時間に同じ場所で同じPCでコードを書く、ペアプロのチーム全員バージョンと考えれば良いとのことです。
どんな風にやったか？
1テーブル開発者5～7名に別れて2チームで実施しました。今回プロダクトオーナーはどちらのチームにも参加しませんでしたが、通常は開発者に加えてプロダクトオーナーも参加してモブプロを行うとのことでした。ドライバーとナビゲーターに関しては、以下の運用で進めていきました。
- ドライバーは7分で交代
- ドライバー以外は全員ナビゲーター
- ドライバーはナビゲーターの指示通りにコードを書く
その他に実装するにあたり
- 要件はプロダクトオーナーが1つずつ出す
- TDDで実装する
の２つの制約をかけて実施しました。今回は2.5時間という時間制約があったので、設計の合意にかかる時間を減らすためにこのようにされているとのことでした。
なお、モブプロをする時は、Mobsterというツールが便利とのことです。
できたもの
第一部と第二部に分かれて、「ローマ数字の計算」と「自動販売機」を実装しました。どちらのお題でも、途中「とりあえずテストを通す」ための実装に取り付かれ、保守性の低いコードになってしまいました。
あと、「自動販売機」のお題で、プロダクトオーナーからの要望は最低限満たしているものの、コーラの在庫は減るけれど、ビールの在庫は減らない、のような不思議な仕様となり、PoohSunnyさんからは、「当たり前品質とかあるじゃん」と突っ込まれました。
実装中に言われたこと＆全体のふりかえりで出た意見
実装中や最後のふりかえり、帰宅間際の会話を通して以下のような意見が出ました。
「わからない」ということも意思表示をすると良い
実装中にチーム全体で黙ってしまい、ドライバーが困ってしまう場面があったのですが、
その際に、黙るのではなく「わからない」ということを伝えるのが大事とのお話がありました。
モブプロのエバンジェリストのWoodyさんのチームでは、わからない時は両手を挙げてわからないという意思表示をするとのことです。みんながわからないということがわかれば、そこは飛ばして次に行こうかという選択もできるようになるとのことでした。
設計をせずにやったため、保守性の低いコードになってしまった
今回はなかったのですが、普段はホワイトボードも用意して議論しながらやるようです。そして、実装前の設計は、TDDだろうが、モブプロだろうが、ちゃんとやろうねということでまとまりました。
時間を気にしながら実装したので焦ってしまった
7分だとちょっと焦るし、10分だとちょっと間延びするようです。では、何分がいい？というのは、まだ見えていないとのこと。この辺りは、チームで話し合いながら自分達に合った時間を見つけていくのが大事かなと思います。
みんなで合意できたつもりができていない時もありそう
周りとのレベル差があり、自分だけがわかっていないような状況だと聞きづらい、というような意見もありました。これだと、みんなで合意したつもりでも実はわかっていない人がいて危ないねという話が出ました。
他にも
- たくさんの考えややり方が見れて勉強になる
- 疲れる
- 人数は5, 6人位がちょうど良さそう
- チームビルディングに使えそうだが、心理的安全がないため、危険な面もある
- チーム全体でコードが育っていったプロセスを共有できる
といった意見がありました。
所感
個人的に一番避けたいのは、「みんなで合意できたつもりができていない」だと感じました。
ペアプロだと、1対1のやりとりのため、わからないことがあった時は比較的聞きやすいのですが、モブプロで自分だけがわからないのかも、という時は声を挙げにくいのかなと思いました。そういったことを避けるためにも、まずはチームとして意見を言い合える環境（心理的安全な状態）を作ることが大切かなと思いました。それができると、「多くの考えが集まる」、「みんなでプロセスを共有できる」といった良さが活きてくるので、「難しいところを設計・実装する」場面や「チーム全体で知識を共有したい」場面に使えそうだなと感じました。