モブプログラミング始めてみます

はじめに

今回は、現在取り組んでいるプロジェクトチームにモブプログラミングを導入提案をしたく、「モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める」を読みましたので、モブプログラミングの初めての流れ、注意事項をまとめていきます。

いやー、↑いい本でした。１日でさくっと読めました。

モブプログラミング？みんなで集まって作業するだけでしょ程度の知識しかなかったのですが、ベストプラクティスと銘打つだけあってモブプロ導入の仕方、注意事項からやらなくなった時まで幅広く網羅されており勉強になりました。

モビングマシンは去年のマシンを使うようなことをしてはならない

作中の一文。我がマシンは5年選手です。。換えてほしいなぁ。。

モブプログラミングやりたいと思った背景

という訳で本題。現在所属しているプロジェクトではスクラムで開発を行っています。
スプリントレビューの度に1つもDoneにならないという状況が続く中、
PO(もはやSMとしての発言になっていますが笑)から

リソース効率より、フロー効率重視でやってみれば？

というコメントがありました。
当時の解決策として、

• 実装
• 単体テストコード
• 結合テストデータ作成
• 結合テストコード

と分担して進め、優先度高のストーリーをDoneにすることができました。
しかし、チームで仕事している感が出てこず、このフロー効率が本当に自分のやりたかったことなのかと悶々としていましたが、モブプログラミングやっていたら違った光景がみれるのでは、と先週の振り返りで提案してみました。

モブプログラミングって

極論すれば「チームでいっしょに働く」だけとのこと。(解説より)
自分の思い込みとほぼ合ってる？状態でした笑
本編では、

• 3人以上の人々が1台のコンピュータの前に座って協力しながら問題を解決していく
  • 複雑な問題解決には、ペアよりも複数人の方が効率が良い(ただし多すぎると効率が落ちる、5人まで)

とありました。

また、モブプログラミングを始めるにあたって、上層部から「みんなで一つの作業をやるって、コスパ悪いんじゃない？」という意見があるというのもごもっとも。
その場合、

• フロー効率重視により素早くリリースできる
• メンバーのスキルアップ
• メンバー全員でレビューすることになるためリリース後の欠陥が減る

ということ詳細に説明する。
また、あくまでこれは実験であることを強調するとよいと書かれています。(5回を目標に実践する)

※残念ながらモブプログラミングの成功を数値で計測することは難しいとのこと。
検討の価値があるものは以下と補足されていました。

• コンフリクト解決のための時間短縮
• メンバー学習度の上昇
• 欠陥の数の減少
• チームとして成果を共有する

リソース効率とフロー効率って

本書の高速道路の例えが分かりやすいです。

• リソース効率
  • 車が多く渋滞が発生、ノロノロ進んでいる状態で終わりが見えにくい
• フロー効率
  • 車の乗り入れ台数を制限することで、想定時速通りのスピードを出すことができる

リソース効率だと何が問題なのか。
それは特定のスキルが特に高い人、エキスパートが生まれること。
仮にそのメンバーが抜けたとき、または該当機能のタスクが増えたときにボトルネックになってしまう。

フロー効率は、チーム全員が幅広い知識を習得したゼネラリストとなる。
複数の人々が仕事を覚えれば、誰が抜けてもダメージが少ない。

モブプログラミングの流れ

大まかな実施の流れは以下の通りです。
この記事はモブの意義を説明するになってほしいところ。

• 準備：お膳立て(30分)
  • モブの意義を説明(10分)
  • モビングの役割分担の説明(8分)
  • モブで解決する問題の概要の説明(10分)
  • タイピストの順番決め(2分)
• 本体：モビングインターバル(90分程度)
  • 10分毎にタイピストを交代していく
  • モブ全員が協力して問題の解決のために努力する
• しめくくり：経験からの学習(20分)
  • うまくいったこと、うまくいかなかったことを挙げ、次回の改善方法を議論

実施している風景は動画でも公開されています。(https://markpearlcoza.github.io/MobProgrammingIntroduction/)
3分あたりでPOが様子見に来てますねぇ。1プロジェクトに複数のモブチームがいるみたいですね。メンバーも自由に行き来しています。

モブプログラミングの注意事項

ここからは箇条書きにしていきます。
これはやってみてブラッシュアップしていきたいところです。
差し当たって自チームに共有しようと思っていることですので、別チームだとまた違ったルールになってきそうですね。

• モブプログラミングセットを準備する
  • モビング用にマシン、ディスプレイ(もしくはプロジェクター)
    (筆者は60インチ4Kらしい。うらやましい)
  • モブタイマー
  • ホワイトボード
• 最初は2時間程度
  とにかく疲れるみたいです。まずは感触を掴むだけに止めたいところ。
• ポモドーロテクニックを取り入れる
  1ポモドーロは25分。その後5分の休憩を挟んで次スタートという手法みたいです。
• タイピストの仕事
  • プログラマーではないので、自分の思いでタイピングしないこと
  • その他のモブがしてくれと言ったことを取り入れて実装するスマートアシスト的な立場
  • モブを信頼し、自分では通常試さないことも躊躇せず試す
  • ショートカットキーや他の人のツールの活用法などを学習すること
• タイピスト以外キーボードを触ってはいけない
• メンバーに参加を強制しないこと
  強制したところで嫌いなものは好きにならない、ですな。
• 「マイクロ」コミットを行う
  タイピスト入れ替わりのときにコミットする、というのはいいですね。Gitなのであとでまとめられますし。
• 共感を忘れずに
  • アクティブリスニング(聞く姿勢)を取り入れる
  • 人ではなくコードを批判せよ
    • 人の意見に対し、「いや、そうじゃなくて・・・」を使わない
• 集団思考に陥らないようにするために
  • 発言しやすい空気を出しておく
  • 批判的精神を持ち続けることを奨励する
  • モビングの価値は、意見や考え方の多様性から生まれる
• やむを得ず席を外し、戻ってきた場合はモブの邪魔をしない
  • 状況を把握するにはできる限り早くタイピストになるほうがいい

モブプログラミング中に起こる問題点

• 手探りで進めていくような仕事のモビング
  どう実装してよいのやら、、という状況になったときですね。
  文中の気まずい沈黙のときが流れる。次の誰かが発言するのを全員で待っているというのは想像できすぎて笑えます。

「タイムボックス付きの研究」を取り入れるとのことです。

• 理解しなければならないことを明確にし、時間を区切って各メンバーそれぞれで調査をする

  • 調査のための時間はメンバー内で合意する
    • 誰かが解決策を見つける、または時間がくると集まって共有する
    • 自席に戻ることはしないほうがいい。集中を妨げられる

• 些細な仕事のモビング
  テストデータを前にならって作成する、とかの細々とした作業ですかね。
  当然ながらその間解散するということはせず、その場に留まり次の作業について議論を続ける等、やることがあります。

しめくくり(モブレトロスペクティブ)

モブレトロスペクティブは、チームとロスペクティブとは別物とのことです。
モブの方は、チームが成長したと皆が思えてきたのなら廃止することを選択してもいいと書いていました。

本書の振り返りは、シンキングハット(Six Thinking Hatsが元ネタ)が紹介されています。
本では絵付きで分かりやすく書いていました。(本でも絵は白黒なので色は文字で書いてます笑)

ホワイトボードに4つの欄を作り、付箋に思い思いに意見を書いて貼っていきます。
帽子を被る時間は限られていて、時間がすぎると帽子を脱いで次の帽子を被ります。
議論の最中で誰かが間違った色の帽子をかぶったときには、その人の話を遮り、議論を今の帽子の内容に戻すことが許されます。

• 1つ目：白：事実と数字：2分間
  • 抽象的ではなく具体的な数字で記載する
    • タイピストの交代間隔
    • エディタのフォント
    • 問題にどれだけの時間を使ったか
• 2つ目：黄色：肯定的感想：3分間
  • 一番うまく行ったことはなにか
  • 予想外に簡単だったのはなにか
  • セッションでいいと思ったことはなにか
• 3つ目：黒：批判的感想：3分間
• 4つ目：緑：問題解決：5分間
  • この段階では、アイデアを提案するだけなので、どんな提案も却下されない
• 最後に合意形成
  • 1つだけ決める
    • 1度に多くのことを変えるのは得策でない。徐々に適応していくことが大事

最後に

やはり文字だけで絵がないと寂しい感じが。。
なお、本書には他にもモビングを定着させるために、定着後の長期的な願望、と続きますが、我々のチームはまだそこまで至っていなので、本記事でやってみた内容を踏まえ次のアウトプットに活かしたいと思います。

あと、、文中の、「いや、そうじゃなくて・・・」という言葉は自分でもよく使っています。。
「そうだね、それに・・・」というように同意から入る言葉使いを心掛けていきたいこの頃です。