この記事を書くにあたっての動機
モブプロがどういうものか、詳しい導入事例などは他の方々が色々発表してくれています。
しかしモブプロをガッツリ導入した話が多いので、既存チームの中で実際にこの形で始めるのは難しい。
また、モブプロが常に正解の方法ではないとも説明されています。
じゃあ、正解のケースとそうではないケースの境目はどこにあるのかを個人的な考えではありますが、まとめてみたいと思いました。
- モブプロ価値の考察
- モブプロを実験してみる方法
について書いています。
モブプロの価値の整理
牛尾さんの記事の項目で言うと以下になります
- 心理的に安全
- 楽しい
- 暗黙知を共有できる
- 詳細な管理が不要になる
- 問題 vs 私たち
一つずつ考察したいと思います
心理的に安全
モブの状態ではコミュニケーション量が圧倒的に増えるので、心理的安全は作りやすくなるのは事実でしょう。
しかし、仲が悪い状態や意見が合わない状態も表面化します。これは違う方法で解決が求められます。
これはモブに限らず最大パフォーマンスのチームを作るときに必要なことなので、ここでは多くは語りません。
しかし、メンバーについては今までのチーム作りより気をつける必要がありそうです。
楽しい
かなり主観的な話なので言及は避けます。
私個人としてはソロでフロー状態に入ってコーディングをするのもとても大好きで楽しいからです。
しかし、モブプロは違う楽しさがあるのは事実だと思います。
暗黙知を共有できる
個人の暗黙知を集合的な暗黙知へ置き換えれます。
コードなどで結果を見るだけではわからないニュアンスなどの認識を同時に持つことが出来ます。
またビジネス仕様の詳細やなぜこの実装にしたのか？という部分も共通認識を持てます。
SECIモデルでの集合的形式知をスキップしている状態のように思えます。
詳細な管理が不要になる
コードにおける管理はほとんど不要になるイメージは付きやすいと思います。
情報として貯めることが出来ないため、新メンバーJOINのときの情報が足りない。
モブでケアの前提。個人的には効率的とは思えないところを感じます。
ドキュメンテーションなどはうまくモブプロの作業と分けて考える必要がありそうです。
集合的形式知をスキップしている部分について、チームのメンバーが不安定なときは現実解として何らかのケアを考えておいた方が良さそうに思いました。
ドキュメント管理については実際にモブプロ長期運用している方に質問してみたいかもしれません。
問題 vs 私たち
モブプロはフロー効率の最大化に適していると考えます。
基本的に１つの問題を全員で倒すという形だからです。
実際のタイムボックスは可変であり、外部環境にかなり影響されるため、どちらが正解は無いと思います。
考察まとめの図
最初の項目で紹介されたこちらの記事にこの表があります。
「スクラム、モブプロ、アジャイルエンタープライズ -小さなチームと大きな組織-」という講演をしてきた #CEDEC2018
生産量と生産性の違いが重要ということになります。
だって生産量はソロプログラミングで分担した方が多いのですから。
生産性？
近年、OUTPUT(生産量) より OUTCOME (生産成果) が重要だと言われるようになりました。
(翻訳が微妙だったらツッコミください)
つまり単純な量ではなく、最終的な成果に繋がる質も考慮された量だと言うことと解釈しています。
- システム品質
- 中長期の開発やメンテナンスにおけるノウハウの共有
- 最初に定義した設計に従う実装ではなく、最終成果にフォーカスした実装
なのかなぁと考えました。
これらにビジネスにおける最短リリースがどれほどの価値を生むかを掛け算したバランスと考えました。
これは最早、感覚値でしか言えないのかなと思います。
ビジネス領域とシステム領域の両方で理解が深い人がコントロールする開発マネージャが判断するか、そのタレントがいない場合は常にモブの状態で判断するのが良いのでしょうか。最早メンバー次第なのかもしれません。
モブプロの価値の出やすい項目
ちょっと脇にそれて生産性の話になってしまいましたが、まとめるのが難しそうなので
考察の最後にモブプロの効果的なタイミングについて考えました。
個人的には以下のようなケースでモブプロが最も効果を発揮するかと考えました。
もちろん、長期でモブプロを続けたら別の効果が表面化しますが、以下のケースではどんな場合でも費用対効果でモブプロのメリットを大きく受けられると考えました。
- 暗黙知となりやすい技術項目
- 様々な機能を開発を追加するとき必要な基盤となるコアな部分
- コードだけで表現できない業務的な意図を多く含む部分
- スキルレベル差が大きなメンタリング的な思考トランスファー
- 既存コードの知識をシェアしながら追加機能を実装するとき
このようなときにピンポイントにモブプロを活用するというのが最初の現実解としてちょうどいいかもしれません。
モブプロを実験する
やっとタイトルの実験に来ました！前振りが長くてすみません！ｗ
いきなりモブプロをチームに導入することは難しいです。
なぜなら誰もやったことが無いわけで、どう思うか、どう進むかが分からない。
それならば１度実験してみるのが１番でしょう。
その後にチームでふりかえりを行って導入するべきかどうかを再度検討してみれば良いのです。
チームの同意があれば、実験は何度やっても構いません。
リスクを小さなサイズにして試してみるのが良いです。
モブプロを実験するための準備
0.実験方針
モブプロの実験は１日体験とします。
平日午後の3−４時間くらいでやってみると良いかと思います。
あくまで体験であり、実験です。
時間は短すぎてもモブで人を切り替われないですし、丸一日は長くて、初めてだと集中力が続かないと思います。
1.テーマ決め
モブプロの価値の整理の項目で整理した価値の出やすい項目に合うテーマを探すのが良いと思います。
体験なので前提のビジネスシステムの基礎部分はシェアできている状態からスタートすると早く実装を開始できます。
あくまで共有するのは基礎で良く、詳細部分は話をしながら確認してコーディングしましょう。
- 暗黙知となりやすい技術項目
- 様々な機能を開発を追加するとき必要な基盤となるコアな部分
- コードだけで表現できない業務的な意図を多く含む部分
- スキルレベル差が大きなメンタリング的な思考トランスファー
- 既存コードの知識をシェアしながら追加機能を実装するとき
このテーマしだいでモブプロの満足度は大きく変わります。
この実験をリードするときには注意深くテーマを決める必要があります。
2.作業スイッチの仕方
キーバインドやエディタなどエンジニアそれぞれにこだわりがあります。
ソースコードの共有方法などについて決めておきましょう。
私がモブプロを実験したときにはgitに当日のモブ用のブランチを作り、エラーなども許容していました。
(本来のコードの場合、エラーがないことはもちろん、テストケースが実装されていて、レビューが通っていなければマージできません)
ドライバーがスイッチするときにはマージして、pullするところから作業を交代していました。
もっと良い方法がある人はコメント欄などでお待ちしています！
3.環境
どこかの会議室などを借り切り、外部の影響を受けずにワイワイ出来る環境を作ります
大きなディスプレイを１台
メンバ全員がディスプレイを囲んで、ディスプレイのコードが見える距離で座れるスペース
長時間座りやすい椅子
すぐに絵を書いて話し合いが出来るようにホワイトボード
メモ書きを共有するための付箋
など
を用意しましょう。 (他に必要そうなものがあったらコメント下さい！)
特にワイワイ出来る環境が重要です。
実験では外部の邪魔が入らない環境を作ります。
本格的なモブプロでは、ワイワイできれば興味を持って集まってくる人も仲間なので、その場合はこの限りではないと思います。
4.メンバー
実験をやってみたいと手を上げた人だけでやっていいと思います。
恣意的に選ぶと実験に対する不信感が増してしまうので公募しましょう。
あまり少なすぎず多くなりすぎない人数である必要がります。MAXでも8人。適正値は3-5人くらいかと思います。
テーマ決めのときもそうでしたが、実験の場合は時間が少ないので近いシステムを開発しているエンジニアに限定して、業務理解への時間を減らします。
これは実験チームと言う新しいチームなので、既存のチームのボーダーに依存しすぎる必要はありません。
モブプロの体験の本編
最初にテーマと意図の共有をします
モブプロ開始！
- 休憩を適宜取りましょう
- どんどん発言しましょう
- 議論が平行線で進まなくなったら休憩してお菓子を食べましょう
- 型はありません。フレキシブルに全員であらゆることを決めましょう
- 今回は実験なので、基本的に途中でモブを抜けないようにしましょう
- 途中で抜ける必要があって、再参加した場合にはモブの邪魔にならないように、しばらく様子見て状況を観察してから参加します
モブプロ体験のふりかえり
すでにそれぞれが感じたモブプロに対する感想を持っています
全ての意見が参考になるので、否定はせず、多くを引き出しましょう
次の展開としてモブプロを活用するかしないかも話し合えると良いでしょう
出来れば、その結果をWebの記事でまとめてもらえると嬉しいですｗ
この記事を読んで試してみた方はコメント欄にどんどん貼ったり、この記事へのリンクをくれると、僕もそれを見ることが出来て嬉しいですｗ
実験という考え
アジャイルを拡張するモダンアジャイルの考えで高速に実験&学習するというものがあります。
また、Management3.0の考えの中にも「成功と失敗」というものがあり、そこで使えるプラクティスとしてセレブレーショングリッドがあります。
いつもやっていることは失敗しません。何かを始めるときは失敗はつきものです。しかし、いつもやっていることはチームの学習を促進することは出来ません。
その中で実験という形で様々なことをすることこそが学習を最も促進させます。
強いチームを作るためには学習を継続的に行わなければなりません。
その中で実験は必要不可欠です。
実験という形は失敗を許容できる小さいサイズで行い、成功したときに、ノウハウとして正式導入すればいいのです。
これからも様々なことを実験できるチームを作っていきましょう！
最後まで読んで頂きありがとうございました
この記事が良かったと思った人はいいねくれると、次の記事を書くモチベーションになるのでよろしくお願いしますｗ