モブプロのやり方
この記事ではモブプログラミング（以下モブプロ）を効果的にやるための方法を解説します。
モブプロのコンセプトは、チームでコミュニケーションをして問題を解決するです。
大変さは人数分の一。楽しさは人数倍
モブプロをやる理由については、モブプロのススメという別の記事に分けて書いています。
モブプロは、決まった一つのやり方だけではありません。色々なやり方もありますが、全部を解説しようとすると読む側も大変だと思うので、ここではモブとタイピストパターンという一つだけを紹介します。
わかりづらいところなどがあればカジュアルに質問してみてください！
この記事は、僕が書いて社員の協力でブラッシュアップした、株式会社マツリカの社内ドキュメントをベースにしています。リモートワークで実際にモブプロをやって得た知見も込められています。
モブプロは誰のためのもの？
モブプログラミングは、プログラマのためだけのものではなくて、デザイナー、QA、PM/POなど、開発チーム全員のためのものです。
・ デザインの話、仕様決めの話をみんなで行えて、齟齬が発生しづらい
・ QAから見ると、プログラマがどういうふうに設計・実装したのか、わかりやすい
・ プログラマからQAに伝えるべきことも伝わりやすい
モブプログラミングはできる人のためのものではなくて、モブプロ参加者全員が納得感を得るためのものなので、少しでもわからないことがあったら、流れを止めてでも質問攻めにするほうがお互いに得るものが大きいでしょう。
カジュアルに質問してもいい空気を作っていこう
あと、モブプロが合わない人、好きじゃない人もいるので、そういった人が強制参加になるのは望ましくありません。参加するも自由、参加しないも自由です。
まずモブプロの進め方について合意を取りましょう
最初にモブプロについて合意をとっておきましょう（グランドルール）。
「モブプロとはこうだ」という認識や、何を重要視するかは人によって異なります。
・ このモブプロの目的なにか?教育か実装か?
・ 各自の役割を確認する
・ 進め方
毎回やる必要はないですが、初めてのモブプロ、初参加者がいる場合は確認しておきましょう。
また、事前準備として、タスク管理のチケットがある場合、そのURLを告知しておくと、参加者が予めチケットを確認できるので、よりスムーズに開始できるでしょう。
モブとタイピスト パターン
モブプロの代表的なパターンのひとつ、モブとタイピストという2つの役割のあるパターンを実際に解説します。
時間制で持ち回りのタイピスト1人と、その他全員がモブになります
他にもパターンはいくつかありますが、モブプロというコンセプトを理解しやすく、初めてに最適なため、このパターンを紹介します。このパターンは、モブプロアンチパターンを回避しやすいようになっています。
他の詳しいパターンを知りたい場合は末尾のリンク集などを参考にしてみてください。
モブ
モブの役割は、モブで相談をして実装内容を決めて、次に述べるタイピストに伝えることです。モブはタイピスト以外で、モブプログラミングに参加している全員です。
モブがモブプログラミングの主役です。
繰り返しになりますが、モブ全員で相談をしてタイピストに作業内容を指示します。
このときの指示は「46行目に、const hoge = () => 'hoge' を追加する」のように、具体的な内容です。「46行目に、こんすと ほげ いこーる かっこかっこ いこーるだいなり シングルクォートで囲ったほげ を追加する」とかでしょうか。
JS/TS慣れしてるメンバーであれば「46行目、こんすと ほげ いこーるで、引数なしラムダで文字列ほげを返す」だけで伝わるかもしれません。
もちろん口頭で指示をするため、どうしても伝わりにくいとか、省略したいとかはありますが、タイピストが悩まないように工夫をして伝えてみてください。
このとき VSCode の IntelliSense のように強力な補完機能があるとやりやすいです。
モブは発言し、開発に貢献する役割です。発言をしましょう。紳士的に相談をしましょう。コミュニケーションがなくなるともうモブプロのコンセプトを満たせません。
何かしら成果が出たときには、過剰なくらい喜び、お互いを褒め称えたほうがいいでしょう。常に「いいね！」と喜び合うと、楽しくモブプロできるでしょう。
タイピスト
タイピストの役割はキーボードに文字を打ち込む（タイピングをする）だけです。つまりタイピストとはエディタ・IDEを操作し、キーボードに文字を打ち込む人のことです。
タイピストはタイピングできれば誰でも可能です。むしろ、慣れていない人がタイピストをするほうが得られるものは多いでしょう。
モブとタイピストが別れている理由は、モブプログラミングのコンセプトが、モブ同士が話し合ってプログラムを作るためですが、話し合いをしていてもプログラマなら自分で打ち込んで主導したくなる生き物です。それを防ぐためにこのような役割分担をします。
そういった話し合いを促すために、タイピストは、明らかに自分が考えるものと違う、たとえば typo やバグりそうなものであったとしても、極力モブに言われたとおりに打ち込みましょう。
繰り返しになりますが、モブが話し合いをしてみんなでプログラムを作り上げるためです。
ただし、指示が不明瞭な場合は、もちろん遠慮なく質問をしましょう。少しでも分からないこと、解釈しづらいこと、理解できないことがあれば質問をしましょう。
つまりタイピストがやるべきことは2つです。
・ モブの指示に従って文字を入力する（タイピストはモブが発言した内容以外を入力してはいけません）
・ 指示に対して、より明確にするために質問をする（分からない、不明瞭な指示には必ず、分からないと言いましょう。指示された内容を理解するのも役割です。理解できないときは理解できるようになるまで質問すべきです）
もし自分がタイピストをしているときに納得できない指示があったり、自分の考えと異なる方針で進みそうなときは、そこでタイピストを交代してもらうか、次に自分がモブになったときにそれを提案しましょう。
よくあるモブプロのアンチパターンは、タイピストが主導権を握ってしまうケースです。これはタイピストが考えてプログラムを作り、モブが黙ってしまうような状況です。こうなってくるとモブプロというコンセプトが成立しなくなります。
モブプロの重要な原則
モブプロというコンセプトを実現するために大切な原則を以下に述べます。
タイピストは持ち回りで
10分〜15分程度でタイピストを交代しましょう。なるべく短い周期で交代するのが望ましいです。同じ人がずっとタイピストを続けるとタイピストがつまらなくなる、あるいはモブの話し合いが固定化されてしまうことがあります。
交代を短くするためには、VSCode LiveShare などを活用するといいでしょう。
リモートでやる場合は、タイピストが画面共有をしておくといいでしょう。
HRT（謙虚・尊敬・信頼）の原則
相手を否定・非難してはいけません。HRTは、謙虚・尊敬・信頼を意味する略語です。お互いHRTの原則で仲良くやりましょう。
モブという場は、モブ全員で作り上げるものです。
意見が別れたときは
コードを打ち込んでみて確認できることなら、まず簡単そうなアイデアから試してみるといいかもしれません。
それでもやはり意見が分かれそうであれば、HRTの原則を忘れずに話し合ってみましょう。
話し合いの基本はソースコードに対して行いましょう
モブの話し合いは空中戦にならないようにしましょう。ここでいう空中戦とはまだ存在をしていないコードのことです。
基本的にはモブの話し合いはすでにテキストエディタに打ち込まれているコードに対して行うべきです。モブで設計が必要な場合は同様に、テキストエディタやUMLツールなどに打ち込んだものに対してであるべきです。
これはなぜか？というと、個人の脳内にあるものは、他の人とズレが生じる可能性が高いためです。
テキストエディタ・IDE・UMLツールのように、実際に形式化されたものを題材にしたほうが、お互いの認識のズレがなくなります。
打ち込んでミスをしても誰も困ることはありません。空中戦をしてしまってコミュニケーションにミスをするよりは、打ち込んでミスをしましょう。
ソースコード以外をメモできる場所を用意しておくと便利です。ソース上にコメントアウトでもいいですし、別のテキストファイル・Markdownなどを開いておいてもいいでしょう。
休憩を必ずいれましょう
どれくらい入れるべきかはモブ参加者によって違いますが、モブプロは非常に疲れやすいので定期的な休憩を入れましょう。最初は1時間に1回、10〜15分などで試してみて、合わなければ変えていけばよいでしょう。
休憩をいれることによって、交代の時間を短くしても疲れが出にくいです。
ふりかえり
簡単でもいいので、なるべくふりかえりをしたほうがいいでしょう。
たとえば、モブプロが終わったあと「今日どうでしたか？」「楽しかった！」くらいでもかまいません。
モブプロ自体が新しい手法であるため、慣れている人、知見もまだまだ少ない世界です。「合う・合わない」「やりやすいかどうか」などをあぶり出したいところです。
そのため、ふりかえりにより、率直な感想を述べ合うのが望ましいでしょう。
意外に思うかもしれませんが、分かりづらい、やりづらい、追いかけづらい、ストレスである、ふりかえりや感想が何もでてこないのはなぜか?というような感想は、とても役に立つ、重要なヒントです。
どうせならみんなで楽しくコミュニケーションしたいものです。
慣れてきたらしっかりふりかえりをしてみたほうが、より効果がでるでしょう。
参考:
入退場は基本的には自由です
途中で入ったり抜けたりするのは自由です。カジュアルに参加してみていいと思います。その場合、入った、抜けるなどを伝えるほうがスムーズになります。
内職をしないようにしましょう
特にリモートだと内職しがちですが、モブに参加するときはモブに集中しましょう。
聞き専をしたい人は最初に聞き専でということを明示したほうがいいでしょう。（聞き専で入ること自体はもちろんありだと思います！）
聞き専になるか、モブプロに参加するかは、最初に明示したほうがいいでしょう。
それを防ぐ意味でも、交代の時間は短いほうが良いかもしれません。
継続的にモブプロをするなら、過程を残す
一回で終わらないモブプロをする場合、途中参加しやすいようにするために、モブプロの過程をチケットやその他ドキュメントシステムに残しましょう。
途中参加する人はチケットなどを読みつつ、わからないことがあったら質問してみてください。
コツ
ここからはモブプロのコツです。
やることをメモしておく
複雑なチケットをやる場合、そのチケットに、モブプロでやる内容をメモしておくとスムーズになります。
・ "src/components/organisms/Hoge/views/index.tsx" のコンポーネントの引数に "hoge" を追加する
・ "hoge" を、128行目あたりにある "Title > Link > Dotdotdot" に追加する
・ コンポーネントの引数を追加してエラーにならないように "../types.ts" の "Props" 定義を変更する
・ コンポーネントの呼び出し元をたどって "hoge" の初期化を行う
などです。これは複雑度によりますが、大まかな方針だけでもあるとスムーズさが違います。
このメモの作成自体もモブプロの一貫としてやるといいでしょう。
たとえば、あるチケットについて、やる内容を考える、調査するところからモブプロとしてスタートするのです。チケットでの仕様確認と、改修ポイントの確認などを一通りやって、その結果メモをチケットに残します。
タイピストのときに意見があったら
タイピストの項目にも書きましたが、タイピストをしているときに、ん？と思ったら交代してモブに回るといいでしょう。モブとタイピストパターンでは、タイピストは意図を理解するための質問はできても、指示内容を変える発言をしません。そこでタイピストを誰か他の人に変わってもらうのです。
タイピストからモブに変わったタイミングに限らずですが、誰かが過去の実装について意見を言い出した場合は、きちんとモブ全員でそれを聞きましょう。
くれぐれも 「それはもう終わったことだから」という様に流すのは厳禁 です。
それでは単なる言論封殺になってしまいます。HRTにも反しているため、意見は必ず聞き、必要があれば実装して試すようにしましょう。
この事例が頻出する場合は、チームや課題にモブとタイピストパターンが合っていないかもしれません。他のパターンも検討してみてください。
全員で考えても分からないことがでてきたとき
全員で考えても分からないことがでてきたときは、時間制限付き（10分とか）で、各自でぐぐったり調べたりするといいでしょう。必ず時間制限を設けて、その時間がすぎたらその時点でわかっていることを共有しましょう。
さらにまだ分からないことがある場合は、また同じくらいの時間制限を付けてもう一回調べ直してみましょう。
ここでのポイントは、ハマらないために必ず時間制限をつけることです。
別の方法として、今いるモブ以外、外から応援を読んできてもいいでしょう。
スピードに注意しよう
慣れてる人と慣れてない人では理解速度が異なります。一番不慣れな人が理解できる速度が望ましいでしょう。
リモートモブプログラミングをしているときなんかはとくにそうですが、ソースコード間の移動に、特に差が出やすいです。
慣れてるひとは、ソースコード名や行番号を意識的に発言すること、そこに飛ぶ理由を逐次発言するほうが望ましいです。
定期的に、みんながついてこれてるか確認するといいでしょう。
わかったことをドキュメントとして残す
JSDocのようなソースコード内ドキュメントを残すといいでしょう。このときの基準は、VSCodeで変数やクラスなどにマウスカーソルをホバーしたときに、そのドキュメントが表示されるかどうか？です。
ボーイスカウトルール
ボーイスカウトルールでやっていくと、少しずつソースが綺麗になっていくはずです。
commit するときは、checkout したときより、少しだけ綺麗にする
向いてない作業
誰がやっても同じ結果になるような作業はモブプロには向いていません。
向いてない人
モブプロに向いてない人、やりたくない人も、間違いなくいます。
自分が書いたコードにアイデンティティを持つタイプの人、職人肌の人は向いていません。達成感も人によっては得られにくいかもしれません。
楽しくモブプロをするためにも、参加は自由であるべきです。HRTを忘れないようにしましょう。
応用
もっとモブプログラミングをやってみたくなったら、ぜひとも応用編に進んでみましょう。
プログラミング以外にも応用できます
モブプログラミングは、プログラミング以外にも応用できます。モビング・モブワークと呼ばれるものは、プログラミング以外を含めたものです。
・ デザイン
・ トラブルシューティング
・ メールを読む
・ サポート
・ チュートリアル
など、様々な事例に応用可能です。
もともと、モブプロを実践的に導入し始めた本家である Hunters industires 社では、トラブルシューティングをモブでやったことから、モビングの有用性に気づいて、少しずつモブプロをやりはじめたらしいです。この会社では最初のうちは一つの島で導入していたのが、その後には複数のモブ島を作って、全社的に取り入れているそうです。
モブプロにおける役割のパターンはいくつかある
このドキュメントでは、モブとタイピストによるモブプロについて書きましたが、他のパターンもあります。モブプログラミングへの習熟度、プロダクト自体への習熟度や、個々人の技量・性質によって、やりやすいパターン、効率的なパターンは異なるでしょう。
読んだほうがいいオススメ資料
・ モブプロの聖地 Hunter Industries で学んだこと - kawaguti’s diary
・ モブプロの聖地 Hunter Industriees で学んだこと 〜 複数モブ編 - kawaguti’s diary
・ モブプロにやりづらさを感じて改善した話 - Sansan Builders Box
・ 「モブプログラミング・ベストプラクティス」読んだのでモブプロの魅力と始め方をまとめる
・ Hunter Industriesの方のモブプロ体験会で教わった、本場のモブプロプラクティス - little hands' lab
・ Mob Programming Startup Manual #MobProgramming #モブプロ
さらにモブプロについて理解を深めるために
・ モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める | マーク・パール, 長尾 高弘, 及部 敬雄 | 工学 | Kindleストア | Amazon
この記事が気に入ったらサポートをしてみませんか？