こんにちは id:yoichi22 です。この記事は モブプログラミング Advent Calendar 2018 - Qiita 11日目の記事です！昨日10日目は matsuoshi さんの「自分がモブプログラミングを導入したときの話 - モノラルログ」でした。
モブプログラミングではチーム全員で同じ課題に取り組みますが、それが効果的に機能する「チーム全員」とは何なのか、実際にやってみてうまくいった例とうまく行かなかった例をもとに考えたら、互いの期待がすり合わされ、うまく形成された「チーム」の全員だったという話をします。
(1) モブプロを体験する回
デブサミでモブプロを体験してきた人が、楽しくて学びがあったので試しにやってみようと言い出して、普段一緒に仕事をしているチームのみんなで、業務で使うツールの開発を題材にしてやってみました。目的が体験だったので、時間が来たら交代、ナビゲーターはどんどん発言してドライバーを動かすということを意識してやりました。小さな前進の度にみんなで「やったー！」と大きな声で喜び、ドライバーをどんどん交代しながらリズムよく心地よく開発できました。その場ではツールは完成まで行かずに時間切れになったものの、その場に集まった全員でモブプロを体験するという目的は十分に達成できました。
(2) ツールの開発を進める回
次は、モブプロ体験の回で作りかけたツールの開発を進めようと、「やりたい人は参加してね」と呼びかけて、再び時間をとってモブプロ会を開催しました。集まったのは初回から少し減ったけどだいたい同じメンバーで、初回はいい感じだったのでうまくいくと期待して見ていたのですが、ツールの開発は少し前に進んだものの終わらず、ドライバーがキーボードを握り続けてしまったり、ただ見てるだけで発言しない人が居たりと、メンバーの動きがうまくかみ合っていない感じがしました。
ツールの開発を進めるというその場の共通の目的はありましたが、それぞれが参加した動機は
- モブプロの効果が発揮されるか見たい
- ツールを完成させてさっさと使えるようにしたい
- 使ってる技術のこと少し知ってるので貢献したい
- 開発中に現れる技術を学びたい
といろいろだったようです。初回はみんなで体験しようというので全員の意識統一ができていたのが、この回はあちこちを向いていたのがうまく行かなかった一つの要素かもしれないと思いました。
ただ人が集まればモブプロがいい効果を生むわけではないという気付きを得たものの、どうやるとうまくやれるのかというのはまだこの時点ではよくわからない状態でした。
(3) マネージャーが暇なときに立ち寄り、立ち去っていく回
みんなを集めてやる会とは別に、普段ペアプロで開発してるところにマネージャーが立ち寄って加わり、また立ち去っていくという事がありました。この話は以下の記事でも少し触れてます。
ペアプロの素朴な延長なのでモブプロと言っていいのか分かりませんが、この時は３人でひとつの課題に取り組みました。参加者の動機は
- 会議ばかりでコード書いてないので書きたい
- 別の視点からの意見を取り入れてより良いコードにしたい
- もう一人シニアエンジニアが加わることで学びを増やしたい
とまちまちでしたが、このときは元々の計画（週次の計画で、２人でやる想定で見積もっていた）よりも早く機能を完成でき、よく言われているフロー効率の向上というモブプロの効果が得られました。
何が違うの？
うまくいったケース、うまくいかなかったケースを経験して、集まってプログラミングするだけで勝手にうまくいくというものではないことを実感しました。その差は何だったのでしょうか？
１つ目と２つ目の事例では集まったメンバーはほぼ同じだったのに明暗が分かれていました。1つ目の事例ではモブプロの体験それ自体が参加者全員の共通目的でありそれに集中できていました。２つ目の事例では開発を前に進めるというざっくりとした共通目的はあったものの、それぞれの参加動機はばらばらでした。しかし３つ目の事例では、参加者の動機はばらばらだったにも関わらずモブプロがよい効果を生みました。
何が違うのかなーと考えていたときに、以前参加したDevLove関西のイベントで、及部さんがされていたチーミングの話を思い出しました。
モブプロがうまくいった３つ目の事例では、マネージャーからは何故一緒にやりたいのか（コード書きたいから混ぜて！）の話があり、ペアからは互いにメリットありそうだし入れてあげてもいいよ（若干上から目線）ということでチームを組んだので、３人の間でどういう動機で参加しているのか、何を期待していいのかのすり合わせが少しできており、チームとして課題に向き合えていました。１つ目の事例の場合も、体験するという一つの目的が強く打ち出されていたので、それに沿って各自が貢献するという意識合わせができていたと思います。一方でモブプロがうまくいかなかった２つ目の事例では、ばらばらの目的を持っているというのは後でわかったことで、その場ではそれぞれがどういう目的を持って集まっているのかと、まわりからどういう行動を期待をされているかのすり合わせができておらず、お互いの距離が遠いまま、ただ集まっただけの状態でことを進めてしまったという印象があります。ちょっと人数多めだったので、すり合わせの時間を取るのを躊躇してしまったのかもしれません。
普段のプロダクトの開発では、動きがかみ合っていないなと思ったら立ち止まって会話して意識を合わせたり、半年に一度くらいのペースでドラッカー風エクササイズをやってメンバ間の期待値のすり合わせをしています。今回モブプロの適用先としては、プロダクトよりは小さい単位で、プロダクト開発チームの一部のメンバで開発するということをトライしました。このとき、対象とするスコープと集まったメンバは部分集合ではあるものの別物なので、そこに集まった人でチーム形成ができているかを改めて気にしておくのがよさそうです。
まとめ
数回試しただけの経験から導き出したポイントが合っているか全然わかってないですが、うまくいくモブプロの単位の「チーム全員」は、ただの人の集まりではなく、互いの期待がすり合わされうまく形成された「チーム」の全員であり、すり合わせさえできていれば参加する理由はばらばらでも構わないという考えに至りました。期待値をすり合わせた上で作業することが悪い方向に行く気はしないので、そのことを気に留めてまた時々モブプロをやっていこうと思います。みんなの動きがかみ合ったチームで何かを生み出すのは楽しいよ！
