Mob Programming体験会 with Chris Lucianというイベントに参加してきました。
Chrisさんは最近のモブプロブームの発端となっている(という認識)Hunter Industries社の方で、Regional Scrum Gathering Tokyo 2019の基調講演に登壇された方です。モブプロを実際に長年実践されているされているお話を聞ける機会はなかなかない!ということで勢い勇んで参加してまいりました。
モブプロに関する紹介と、Regional Scrum Gathering Tokyo 2019(以下RSGT)の"Learning to Experiment"というタイトルの講演をこちらの会でも再演いただきました。
その中で、参考になった点、心に残った点をご紹介したいと思います。
Hunter Industriesの具体的な事例
Hunter Industriesでは約30人のエンジニアがおり、それが以下のような体制になっているそうです。
- 体制
- 全員で30人のエンジニア
- 4Teamに分かれている
- 2つのTeamは1Mob、1つのTeamは2Mobで合計6Mobある
- 1Mobあたりの人数は4±1人
- Mobの中では作業を分担することは基本的にしないが、こちらの動画のようなソロワークは必要に応じて柔軟に行う
- Mobごとに技術スタックはハード、ソフトなどバラバラ
- あまり学習や貢献ができていないと感じたら、自由に違うMobに移動して良い
- 文化を守るために、月に3人以上新規雇用しないようにする
と言ったことが紹介されていました。
ただ、技術スタックが違うこともありMobを移ると貢献するまでコストがかかるので、実際そこまで頻繁に起きるわけではないとも言っていました。
また、Scrumではなく、シンプルなカンバンを使用した開発体制で、カンバンは4つのチームがそれぞれ持っているとのことです。ただ、Srcumの概念は部分的に取り入れられており、POというRoleやレトロスペクティブと言ったことは実施しているそうです。
モブプロの目的は何か
モブプロの目的について質問したところ、以下の答えが返ってきました。
- ソフトウェア品質向上
- 属人化の排除
- 短期:気兼ねなく休暇を取りやすい、とっても仕事が滞りなく回る
- 長期:離任してもプロジェクトから知識がなくならない
- クロスファンクショナルトレーニング
モブプロを行う上で、形だけ取り入れると迷子になりがちなので、こう言った目的を言語化するのは重要ですね。
モブプロのRole
モブプロを活性化するための複数のロールが紹介されています。
モブプロがうまくいってないならこのロールを試してみるといいよ、といったニュアンスで紹介されていました。
Level1
- Navigator
- Driver
- Mobber
私がもともと知っていたモブプロのパターンでは「一人がDriver、あとは全員Navigator」というものでしたが、それに対してMobberというものが定義されていました。
Mobberというのはそれぞれが思ったことを思った通りに発信する人、それをとりまとめて実際に行うことを決めてDriverに伝えるのがNavigatorということでした。
Mobberを取り入れて見てわかったこと
午後にモブプロを実際に体験する機会があったのですが、最初はDriver/Navigatorのみのパターンでやっていたところチームが打ち解けていなかったこともあり一部の人に発言が偏りがちでした。そこでMobberとNavigatorを区別したところ、Navigatorが必然的に話す機会が増え、それをローテートすることで全員が発言する機会が増え、議論が活発になりました。
議論が活性化してからはMobberとNavigatorの区別は曖昧になりましたが、活性化を目的とするのであればそれもよし、とすることはできそうです。
モブプロを初めて体験するときや、チームの発言にばらつきがあるとき、議論の取りまとめが必要な時などに行うプラクティスとして覚えておいて損はなさそうです。
Level2,3
そのほかにもLevel2, 3としてRoleが定義されていましたが、これはもう少し時間をかけて少しずつ噛み砕いていこうと思います。
毎日1時間のlearning sessions
個人的に衝撃だったのが、「チームのインプットの時間を毎日固定で1時間、金曜日は2時間以上確保」 しているということでした。
その時間の中で、CodeKataやCoding Dojoのコンテンツを毎日行ったり、試して見たい技術をシェアしたりするとのことです。
前者はコンテンツ的にメンバーの汎用的なスキルレベルの底上げだと思われます。後者の例としてFlywayが挙げられていましたが、本番導入したい技術を仕事の時間内でチームにシェアして検証する狙いがあるそうです。
コンセプトとしてはGoogleの「20%ルール」に近い、実験のための投資時間ということです。Googleの20%ルール運用の実態は「成果は求められる上であとは本人の努力」という側面はあると聞いたことがありますが、それに比べて毎日固定で時間を儲けるというのは仕組みとして確立されているので、より実効性があるよいプラクティスだと感じました。
非常に高いゴール(Lofty Goal)
エンジニア組織全体で、非常に高いゴールを示し、それに向けて改善を続けることが重要と紹介されていました。そこでは、以下の4トピックについてのゴール(ビジョンのようなもの)が示されていました。
- Working Agreements(goal)
- How do we interact? (どのように協働するか?)
- How do we code ? (どのようにコードを書くか?)
- How do we do business? (どのようにビジネスに貢献するか?)
- how do we innovate? (どのようにイノベーションを生み出すか?)
これらのゴールを満たすために、継続的に実験し、継続的に改善をしている、ということです。改善の目的や方向性を意思統一するためにも、こう言った目的を設定することは重要ですね。
継続的レトロスペクティブ
チームとしてのレトロスペクティブは週に1回あり、Mob単位でのレトロはMobをしながら継続的に行うそうです。
頻度はMobごとによるが、45分ぐらいに1回することが多いとのこと。
その他受け止めきれなかった話
「No Estimation(見積もりしない)」はRSGTでも結構話題になっていたようですが、あまり深く理解を掘り下げられませんでした。
また、リーンスタートアップの話、7つの無駄の話が前提知識のような形で繰り返し触れられていました。この辺り結構常識的な扱いになっているような感じなので、改めて勉強してみようと思いました。
「継続的改善と継続的実験」の姿勢
Hunter Industriesでのモブプロのような作業の進め方をする発端は、緊急対応でした。そこから、その進め方が平常時にも適用できることに気づき、徐々にやり方を変えてきたとのことです。
ここでとても示唆を含んだメッセージがありました。
緊急事態は触媒である
(The emergency is the catalyst)
でも、
どうして大事故が起こるまでやらないの?
(Why wait for hell to break loose?)
大事故が起きてやり方を変えられるのであれば、平常時にも変えられないはずがないではないか。そして平常時なら、安全に計画をしながら実験ができるはずではないか。だからラインを止めて安全に実験しよう(stop the line & safety to experiment)ということでした。
そうして継続的な改善を目指し、継続的に実験を目指して行く体制が、Learning Sessionなどのやり方に生かされているようでした。
色々なプラクティスを紹介いただきましたが、モブプロという何か特別なことをやっているというよりも、 スタンダードなAgileやXPの様々なプラクティスを着実に実施されており、その中で生まれた一つの進め方としてモブプロがある、と言った印象を受けました。
おそらく、 モブプロというやり方自体をそのまま真似ても同じようには成果は出ない でしょう。もっとも重要なのは個別の事例ではなく、 継続的な改善のために積極的に実験する姿勢であり、それこそ自分たちに取り入れたいものだと感じました。
謝辞
実際に長年実践されている方にお話を聞き、色々質問させていただくという本当にありがたい機会でした。当日の運営も場所だけでなく、飲み物、フルーツなどまで丁寧にご準備いただき本当に心配りを感じました。
本当い良い機会をどうもありがとうございました!!
【2021/10/30新刊】
DDD解説書の新刊を執筆しました。 重要トピック「モデリング」「集約」「テスト」について詳細に解説し、その他のトピックでは頻出の質問への回答と具体的なサンプルコードをふんだんに盛り込みました。現場で実践して、困っていることがある方はぜひこちらもご覧ください。