Home

Welcome to the MobProgammingPatterns wiki!

ここではモブプログラミングがうまくいっているセッションやチーム、組織を見て、パターンを発見していきます。

パターン

パターン、パターンになりそうな気がするもの、パターンと呼べるかわからないけれどよく見かけるものごとを書いていきます。

とりあえずフォーマットにはこだわっていません。このページにもりもり書いてもいいし、別ページにしてもいいし。

• 全速前進！
  • モブプログラミングで仕事を進めていると、設計判断や意志決定をその場で下していく。どんな機能を作るか、どれから作るか、ビジネスロジックはどうか、どういうUIにするか、いつデプロイするかなど、次々に、その場でおこなわれていく。
• 全員集合！
  • 逆に言えば、チームが全速前進！で驀進したければ、その場で意志決定できる必要がある。意志決定する人がモブとしてその場に参加していれば、一番いい。仕様を決める人、UIの人、インフラの人、ビジネス判断をする人、すべてモブだ。
• みなが一つのために
  • すなわちモブプログラミングとは、一つのものを作るため、貢献する人がすべて集まっている場だ。もの作りを進めるための場を作って、そしてもの作りをする。
  • 場そのものも流動的なものになる。他の人がいたほうがよければ呼んでくればいいし、あまり貢献できない人は出ていけばいい。「全員集合！」の全員とは、そうなると、「たまたまそこでやろうとしていることを進めるのに十分な全員」くらいの意味合いになってくる。
• チーモブルディング
  • 新しいチームを結成したとき、モブプログラミングの形式はチームビルディングに寄与する。初めて顔を合わせるメンバーがお互いを知ったり、協力の仕方を学んだり、最初の成果を全員で出すまでが非常に早くなる。同様に新メンバーの立ち上げの役にも立つ。
• 始まりのパターン
  • モブがどうやって始まるのか、いつモブを始めるのか、いくつかのパターンがある。
  • なんでもモブ
    • シンプルに、すべての仕事をモブプログラミングで進める。あるいは、始業時間になったらとりあえずモブが集まる。
  • 難問モブ
    • 難しい問題や複雑な箇所にいどむとき、モブが集まる。新機能や大規模な変更の最初に、全員で問題を把握し方向性を決めるときであったり、深刻な障害を調査するときであったり、設計判断をスパイクしながら下すときであったりする。
  • モチベモブ
    • 心が折れる作業、刺身タンポポ的な作業、ひとりではやる気が出せないような作業に、モブで立ち向かう。事務作業とか。辛いときこそみんなで支え合おう。
• 交代のパターン
  • モブプログラミングではキーボードを握るドライバーが1人、残りは全員ナビゲーターとなる。誰がドライバーをやってもよいし、交代してもよい。交代についてはいくつかパターンがありそう。
  • 俺にやらせろ
    • ここは自分がやりたいと言って、ドライバーになる。得意だからかもしれないし、逆にあまり詳しくないからかもしれない。単に飽きたからかもしれない。
  • 15分交代
    • タイマーやmobsterのようなツールを使って、一定時間でドライバーを交代する。モブプログラミングに慣れていないチームが交代の感覚をつかむために使うこともある。
  • 俺はもうダメだ
    • ドライバーから、誰か他の人に交代してもらう。疲れたからか、飽きたからか。
  • 仕事の切れ目
    • やっている作業が変わるタイミングで、ドライバーも変える。一通りできたときや、実装とテストを切り替えるときなど。
  • 追い風から学ぶ
    • やろうとしていることに自分が一番ヘタクソだと思ったら、ドライバーになる絶好のチャンス。あなた1人では進めないかもしれないが、周りのナビゲーターが持っている「あなたが持っていない知識や技術」を使って前に進んでいける。ドライバーは進んでいる中で学ぶことを意識しよう。ドライバーがブレーキを踏む時はドライバーが学ぶ時だ。「ちょっと待って。なんでここで右に曲がるの？まっすぐの方が近道じゃない？」「この先はこの時間から交通規制がかかるから渋滞する。」
• モブっぽい設計
  • ブランチがいらなくなる
  • 1人で把握しきれなくても、全員で把握できればいいので、許容できる設計の複雑性や単位(ファイルの大きさとか)が変わってくる
• 好きスキル
  • モブプログラミングで仕事を進めるには、自力でもの作りをできるスキルがメンバーには必要。進めるスキルも必要なら、その場で学んでいくスキルも。
• フルタイムモブプロ
  • もの作りの時間を基本すべてモブプログラミングでやる。
• モブアウト
  • モブに参加しているのが辛い気分になったら、参加しなくてよい。楽しくない、感情的になりすぎる、落ち着かない、など理由は何でも構わない。貢献できないなら、いなくてよい。貢献できるようになったらまた戻ってくる。
• 休憩時間
  • モブプログラミングセッションは疲労が激しいので、1日にできる時間は限られるし、休憩時間の取り方も考えた方がよい。
• エキスパートジョイン
  • メンバーの知識やスキル不足でスタックしている時、その分野のエキスパート・リードエンジニアを召喚（ジョイン）することで、その文脈での提案・貢献があり、プロジェクトが一気に加速し、メンバー全員が同時に成長する。
• 小さなお祝い
  • サンプルコードが動いた、書いたテストコードが失敗することを確認できた、重複してたコードがきれいになった、などなど、小さなステップを通過するたびに(拍手やガッツポーズで)小さくお祝いすると、楽しさがアップするみたい。
• 甘いものは正義
  • 集中力を持続し続けると脳みそが早々に疲労するので、脳内エネルギー源を確保するためのブドウ糖補給が必要になる。そのために簡単に口にできるチョコレートやビスケットなどがあると楽しくセッションを続けられる。休憩時間や小さなお祝いパターンとも連動させると正義力が増す。
• マネージャーも一緒
  • マネージャーが様子を見に来たり、評価目線でやって来た時に、モブプログラミングに巻き込んでしまう。集中力や価値やメンバーの生産性・貢献などをリアルに体験してもらう。マネージャー自信も貢献できていること・いないことに対して、積極的に発言ができるようになる心理的安全の場がどういうものかの理解も深まる。
• ファシリテータ
  • 第三者の視点からモブプログラミングの状態を把握し、時にアドバイスを与え、時に状況をかき回して流れを変えたりする人物。モブプログラミングに慣れていないチームがその感覚を掴むために召喚することもある。
  • TODOリストを書いて、トラックしてくれる場合もある。
• 教習所教官
  • セッションにおいて育成することに高い比重がある場合、もっともスキルの高いメンバーはナビゲーター役だけで振る舞い、ドライバーを担当しない。他のメンバーがドライバーを担当することで、ナビゲータースキルを一気に学べ、成功体験を積むことが可能。仮免許路上教習のメタファがイメージしやすい。
• 師弟制度・逆師弟制度（ギルド制度・逆ギルド制度）
  • シニアエンジニアがジュニアエンジニアを育てることも重要な役割だ。と同時にジュニアの新しい知見やライフハックをシニアエンジニアに教えることもできる。シニアエンジニアはこれまでの方法論の固定概念を打破できないこともある。一緒にモブプログラミングをすることで、キーバインドや新たなクラウドサービスなど、時短可能なノウハウを若手の方が持っていたりする。新たな発見をお互いに見つけることができる。
• モブワーク
  • プログラミング以外の仕事にもモブプログラミングのメリットを活用し、非エンジニアリング部門においても実施可能。作業分担や承認フローなどを削減できリードタイムの短縮に効果があり、さらにはメンバーの育成にも力を発揮する。
• 手順書アレルギー
  • 手順書を読みながらオペレーション業務や仕事をマスターするのは、かなりつらい。モブワークで一緒に体験することで手順書に書かれていない行間やWhyなども聞けてマスターできてしまう。
• TODOリスト
• コードが進む、動くようになる
• 議論が長引いたら、とりあえず動かす
  • 書けてなかったら、議論を立ち止まる
• ゴールイメージを揃える
• どちらかひとつ
  • モブワークをチームで始めてみた
  • その状況で、スキルの高い人がどんどん書いてしまってついていけないので、他のメンバーが横で見てるだけの人になってしまう。
  • そこで、書くか、考えるか、のどちらかひとつにする。
    • ドライバーは考えながら書かない。書くなら考えずに、ナビゲーターから指示されたことを書く。考えるなら、書かずにナビゲーターになって、考えを伝える。
  • その結果、考えたことを言葉にしてドライバーに伝えることで、何をどういう風に考えて書いているのかを、全員が理解することができる。
• いっぽんみち
  • モブワークを始めたいと思っている
  • その状況で、複数のタスクをチームで同時に進めており、モブワークにすることができないでいる。
  • そこで、複数のタスクを一列に並べて、優先度の高いものから終わらせていくことにする。
  • その結果、モブワークで全員で前から順番にひとつずつ倒していけるようになる。

直接見てないけれど、どこかにありそうな気がするものたち…

• パートタイムモブプロ
• 困ったときのモブプロ
• 合わない人検出装置

物語

ここには、実際に遭遇した出来事、具体的な経験談、実例として聞いた話などをあげていきます。

• 楽天のチームで聞いた話によれば、ドキュメント作成だったり、社内の書類だったりも、モブで作ることがあるそうだ。
• Jon Jorgensenさんから聞いたこと (AgileJapan2017のモブプログラミングの動画にもらったコメントから...手違いで削除しちゃった...orz)
  • 任意で参加される方は参加される時点ですでに「適材」で、始まる時は「潮時」で、起きる事はすべて必然な結果です。終わる時は終わるべくして終わるのです。
  • 移動の掟：「自分が学べない時、話に貢献できないとき、楽しめない時は退場」
• Mob Programming Val参加者の1人が、実際にモブ作業を業務で実施してるというので話を聞いた。
  • スプリント計画会議のあとに、バックエンドチームがモブで要件決め&モック作成してフロントエンドチームに渡す。フロントエンドとバックエンドが別チームで、つなぎこみの部分で想定していた仕様と異なり出戻りが発生していたのがこれを始めてからほとんどなくなった。

編集上の注意

• 誰が何を書いてもいいことにします
• Wikiの趣旨から外れる内容は、削除したり変更されたりするかもしれません
• 編集自由にするとSPAMされると聞くので、コラボレータになりたい人は連絡ください(どこかのタイミングでコラボレータのみ編集可にするかもしれません)
• 誰も書かないと寂しいので、ぜひなんかください！

どう書いたらいいの？

とりあえず、こんな方向性でどうでしょう。

1. なにかパターン(になりそうなもの)を思いついたら、このページ(Home)にパターン名と簡単な説明を書く。
2. パターンについて詳しく書きたくなったら、パターン名(日本語)のページを新規に作って、そこに書く。Homeからリンクする。
3. 詳しく書けなかったら、「～というのを思いついたんだけど、コメントください」とか書いておく。

貢献者

• やっとむ(最初に作った人) tsutomu.yasui@gmail.com https://www.facebook.com/yattom https://twitter.com/yattom/ https://www.linkedin.com/in/yattom/
• あらい(コラボレータ) https://www.facebook.com/araratakeshi https://twitter.com/araratakeshi/
• nobiinu-and
• satoryu
• hmaruyama
• bufferings https://twitter.com/bufferings