こんにちは。
ピクトリンク事業部開発部 開発2課 に所属しています松本です🐹
とあるレトロスペクティブ*1で、モブプロ*2に上手く参加できていない旨の付箋を残した際に、書籍『モブプログラミング・ベストプラクティス』を紹介していただきました。
読んでみて、そもそも間違って解釈していたこともあったし、またそれを改善するためのTRYを改めて自分の中で考えることができたので、今回はその内容をまとめてみたいと思います！
はじめに📚
現在私が所属しているチームでは、実装は基本ペアプロまたはモブプロで行っています。
ペアプロ・モブプロの割合で言うと、(私の場合は)8~9割がペアプロです。
いやいや、ほとんどモブプロやってないじゃん！
そうなんです。機会で言うとすごく少ないんです。
スプリントに乗っているタスクと、アサインするメンバーによって
たまにモブプロの機会が訪れるのです。
加えて、チーム内にはフルリモートのメンバーが居るし、それ以外のメンバーも1ヶ月のうち5割はリモートで作業を行うため、オンラインでのモビング*3が前提となります。
上記を踏まえて、モブプロをする際に私自身が「難しいな〜」と感じていた部分と照らし合わせながら、参考になった章をピックアップして紹介します。
2章 2.3.2 タイピストの仕事
タイピストは、プログラマーではない。(中略)
タイピストになったときには、頭でなく手にならなければならない。
と記載されていて印象的でした。
私が思っていたよりも、手を動かすことそのものがタイピストの役割だったからです。
- 自分の方法に基づく実装は行わず、モブからの指示をしっかりと理解し、コードの形に実装すること
- タイピストの交代に備えて、コードを理解していること
- モブの指示から求めるものが汲み取れない場合は、理解できるまで質問すること
自分がタイピストになった時、質問＆理解しながら実装を行う中で、実装の提案まで行う余裕が無く、「あぁー😖💦」と落ち込んでしまうことが多かったのですが
逆にタイピストは提案しない方がセオリーなのか...と読んでいて少し安心する部分もありました。(ペアプロにおけるドライバーと混同してしまっていた部分かも)
2章 2.4 モビングインターバル
モビングインターバルとは、ひとりがタイピストを務める短い時間のことを指します。
この章で、個人的に意識したいと感じたのは以下の1文でした。
タイピストは、その時点でしていることを「終わらせたい」と思うものだが、その気持ちはぐっと抑えるようにしよう。
これ、モビングを日常的にやっていないチームでは意外と難しいと思うんです...！
全員が共通認識を持っていないといけないし。
以前モビングを行った際に、キリが悪かったりメンバーの出入りがあったりで数時間タイピストが固定されてしまったことがあります。
その時私はモブだったのですが、他のモブの意見を聞いて頷くだけの時間を多く過ごしてしまいました。私のモブプロへの苦手意識が生まれたのもこの時だったと記憶しています。
現在、実装時の時間管理はポモドーロ・テクニック*4を採用しています。
通常数分(この書籍では10分)でタイピストを交代するとありますが、チームでモブプロを行う割合的にも、モビング独自の時間管理ルールを定着させることはハードルが高いのかな、と感じます。
これを踏まえて、現チーム内で私ができるTRYは、『25分のタイマーが鳴ったら、キリが悪くてもタイピストの交代を行う→モビングが実際に始まる前に、メンバーにもお願いする』でしょうか。
3章 モビングと人
プログラムだけでなく人間も大事であるということ、メンバー同士が理解・協力し合いながら仕事ができるようにメンバーを導く方法について記載されています。
モビングに限らず、チームで仕事をしていく上でも参考にできそうだったのでピックアップしました。
- 共感すること。メンバー同士で目線を揃え、対立的にならない。親近感を育てる
- 協調的なマインドセットの獲得
- 「個人」では無く「グループ/チーム」に重点を置く
- コミュニケーションをとって、してもらったことには感謝を伝える
- 集団思考*5に陥らない
- 対立的にならない環境を育てて、心理的安全性を高める
- 発言が少ないメンバーが最初に意見や選択を述べる
モビングの価値は、意見や考え方の多様性から生まれる。モビングの利点をフルに引き出すためには、集団思考に陥らないようにすることがきわめて大切だ。
アウトプットへの苦手意識がありましたが、この章を読むことで自分が発信することでモビングの価値をより良いものにすることができる(...かもしれない！😳)と考えられるようになりました。あまり気負わず発言していきたいです。
6章 6.3 モブに誰を参加させるべきか
モブメンバーの原則
モブのメンバーになって自分が役に立っていると感じるようなら、モブのメンバーでいる意味がある。そうでなければ、役に立つようにするか、別の方法で価値を追加すべきだ
- 役に立っているか または 学習できているか を考える
- どちらでもなければ、モブから去る
「原則」とあるように、この考えをベースに今後モビングに参加したいと思いました。
まずは『理解していないまま居座らない。→モブで参加中に分からないことがあれば、リストにまとめておいて後で質問する』をTRY。
今ぼんやりと「役に立てていない(特にモブの時)」と感じるのは、モビングに対して積極的に参加する意識が足りていないことからくるものだと思うので、その点も変えていきたいです。意識改革！
7章 7.4.2 出入りする時の中断
- 特定のメンバーが議論をリードしている場合、そのメンバーは自分が中座しても議論が回る状態になるまでモブに留まる
- 上記以外の場合、戻り時間の目処を伝えて中座する
- モブに戻ってきた時、中座していた時間の作業内容などを聞かない
- モビングのフローを断ち切らないため
- できるだけ早くタイピストになって、そこで何をやっていたか流れを読み取る
黙ってモブに戻り、できる限り早くタイピストになるようにした方がよい。タイピストになれば、ほかのメンバーたちが次のステップを目指すに至った流れがつかめる。
とありますが、これって1時間以上のMTGで抜けた場合にも言えるのでしょうか？
長時間抜ける場合は、モブに復帰しないという選択肢も出てくるのかな...🤔
今まで結構、戻った時に今何中なのか説明してもらっていましたが
ぬるっと復帰すべきなんですね。ここは改善できそうです。
TRYは、『復帰した時に説明してもらわない→長時間中座した場合など、どうしても聞きたいことがあればポモドーロの切れ目などにする』ですかね。
まとめ✏️
本書では、オフラインでのモビングをベースに書かれており、こういったベストプラクティスに忠実なガチモビングも、いつか機会があればやってみたいなーと感じました。面白そう。
管理職・知識が浅い開発メンバー・エキスパートそれぞれの立場からモビングにおける役割やアプローチの仕方が書かれており、チーム内のどのメンバーでも読みやすいのではないかと感じました。
現体制を崩さないまま、自分が苦手攻略のためにできることを考えたので細々としたTRYになってしまいましたが、ぼんやり悩んでいていたことを少しずつでも改善することで、自分の成長に繋げていきたいです💪
それでは私は、次のハッピーモビングチャンスを最前待機したいと思います！
