成功する実践的モブプログラミング

26720 ワード
mob idea テキストリンク

※Qiitaで書いた記事を移動したものです。なお JTF2020 で発表したときのスライドは https://speakerdeck.com/erukiti/mob-programming-practice です。

モブプログラミング（以下モブプロ）とは、複数人で一つの成果物（プログラムコード）を生み出すという、チーム作業のテクニックです。似たテクニックにペアプログラミングがありますが、モブプロは3人以上（4〜5人を推奨）でやるものであり、また、目的や効果も全く違うものです。

モブプロのコンセプトは、チームでコミュニケーションをして問題を解決するというチーム戦 です。これ最重要なので、あとで何回も登場します！

この記事には「成功する実践的モブプログラミング」というタイトルを付けています。ここでいう成功の定義は、モブプロが実際に効率よく実践できることとします。モブプロに関する記事・情報は「イベントでお試ししてみた」とかが多い傾向があるため、ここでは実践にフォーカスしてあることを強調しています。

筆者が経験する限りでは「お試し」でするモブプロと、本物の課題をモブプロで解決するのでは、参加した感覚、感想、得られるありがたみへの実感が全く違います。お試しモブプロを無駄とまでは言いませんが、全く別物だとすら感じます。

モブプロは、レガシーコードを抱えているようなチームでは凄まじいまでに効果を発揮します。レガシーコードにありがちな属人性の解決ができ、ソースコード変更への恐怖やソースコード考古学と戦う不毛さを、チームメンバーで分かち合うことができるためです。

もちろん、レガシーじゃないプロジェクトでもモブプロは有用です。

この記事は具体的に開発で実践して得られたフィードバックとノウハウが濃縮されたものです。

もともとはモブプロをやるという文化がなかった弊社、株式会社マツリカに、モブプロを導入するための社内ドキュメントを僕が書いて、社員の協力でブラッシュアップしたものです。

一度Noteに記事としてまとめたんですが、Noteは階層構造がなくフラットなため、ノウハウを全部書くには向いてないのと、そのときからノウハウがさらに溜まったので、改めて書き直して大幅増量にして、記事を書き直しています。

スペシャルサンクス: さん、 さんと、モブプロ参加者諸氏（ここでは名前は割愛します）

なお弊社はもともとリモートワーク中心であり、なおかつコロナによる緊急事態宣言の期間中だったのもあり、今回のモブプロもすべてリモートで行われました。

ツールとしては、Slack通話と、Jira チケットと、GitHub や VSCode + LiveShare などが使われています。

なぜモブプロ？

普通の働き方では、個人がタスクをこなすことで、結果チームとしての作業が進みます。

それに対してモブプロでは、チームが問題そのものと戦うチーム戦を行います。

大変さは人数分の一。楽しさは人数倍

モブプロでは複数人で一つの成果物を作るため、効率が悪いようにみえますが、これは効率をどのレベルで捉えるか？という尺度の問題があります。

「効率が悪いようにみえる」の効率は、より正確には「リソース効率が悪い」と言います。ある一人の作業者が時間をどれだけ有効に使って作業ができるか？つまり、個人の時間をリソースとみなしたときの効率です。

ペアプロやモブプロにおける効率は、リソース効率とは異なる視座、個々人ではなくチームで考えるべきです。つまり、チーム全体の成果物を生み出す効率を考慮しなければいけないため、これを「フロー効率」と呼びます。

参考: リソース効率

弊社で実施した結果

弊社でやった案件では人数均等割で算出した時間を元に計測した結果、ソロプログラミングに対してコストが90%に削減できました。初めてのモブプロとしては十分な成果だと考えられます。

そもそも、うまくハマったモブプロは参加者全員が楽しくコミュニケーションできて、すごく良いです。みんなが持ってた疑問も解消されます。

特に良かった点をいくつか挙げると

  • ベンチャーで5年レベルで開発されているプロダクトの考古学という、本来であればつらみになる要素を、つらさを感じずにみんなで共有できた
    • 属人性を少しでも解消できた
  • React 未経験者に「React ってこんな感じなんだ」と理解してもらえた
  • 一人だと確実にハマりそうな要素を、ハマることなく乗り越えられた
  • ふりかえりで楽しかったという感想が多く、しかも日を追うごとに増えた

という感じで、メンバーが皆楽しくプログラミングできました。

つまり、

  • 参加者が、技術的知見、プロダクトの暗黙的知見など様々な知見を得たこと
  • 品質向上
  • レビュー簡略化
  • ストレスフリーだったこと
  • その案件にまつわる様々な資料が残ったこと

という効能も加味すると、大いにプラスだという結果になりました。

感想

最初のうちは2時間くらいでもヘトヘトになるんですが、何回かやると慣れてきて、4時間弱くらいやっても疲れがあまりないくらいにはなりました。

また冒頭にも書いたとおり、モブプロは、ペアプロとは全く性質の異なるものだという結論に至りました。

プログラミングにおいてコミュニケーションコストの占める割合は大きい

フロー効率が上がる最大の理由は、コミュニケーションが効率化されることにあります。もともとプログラミングにおいて、コミュニケーションが少なくない割合を占めます。

  • 要求・要件・仕様の確認
    • やりたいこと
    • デザイン
    • 細かい挙動
    • データの持ち方
  • 改修であれば、改修元コードについての確認
    • 技術的負債が溜まっていれば、特にこの工程は無視できないほどの重さになります
    • 聞けば一発で分かることも、知らないまま調べだすと時間が無駄に浪費されます
  • QA・テスター視点での、改修の影響範囲や、テストをすべき項目の確認

モブプロは、チームのコミュニケーションでプログラミングを行うため、ソロでプログラミングするのに比べてコミュケーションロスが激減します。

もちろんこれは成果物・作業及び作業者の性質によって異なります。誰がやっても同じになるような単純作業のように、コミュニケーションの余地がない場合、フロー効率がリソース効率を上回ることはありません。

コミュニケーションコストの改善ができる

ここまで述べた通り、プログラミング開発ではコミュニケーションコストとの戦いです。

昔から様々なところで語られている通り、人をいっぱい投入すればプロダクト開発効率化やクォリティ向上するわけではありません。むしろ人が増えればコミュニケーションコストの増大により効率とクォリティは悪化しがちです。

コミュニケーションコストは一般的に人数に累乗で比例して増えると言われています。

モブプログラミングではコミュニケーションをしながら行うため、コミュニケーションコストが圧倒的に改善できます。

さらなるコミュニケーション改善のためには

モブプロは、コードが書けなくても問題解決に助言さえできれば、誰でも参加できます。

デザイナーやPM/PO、QA・テスターなど、開発者以外も参加することで、仕様の齟齬を防ぎ、手戻りをなくすることもできます。

コミュニケーション欲求を満たせる

リモートワークやなんやかんやで、コミュニケーションに飢えてる人が増えてる今の時代だからこそ、コミュニケーションができるモブプロはオススメです。

緊急事態宣言が解除されたといっても、コロナのワクチンが完成して認可されたわけではありません。今後も第二波や再度の緊急事態宣言など予想されますし、リモートワークを継続している会社も多いことでしょう。

属人性の解決

一般的にプログラミングの工程では調査が多くを占めるとされていますが、属人性の度合いと、アーキテクチャによって比率は変わります。

ベンチャーのプロダクトなどは、スピード優先や限られたリソースで開発するため属人性が高まる傾向が強く、プロダクトの開発期間が長くなればなるほど調査タスクの比率は高めになります。5年前に書かれたすでに辞めた社員のコードをいじることも珍しくはありません。

大会社でも理由は違ったとしても、属人性の高いプロダクトを度々見かけるはずです。

「当たり前」という単語が飛び交っているチームや、全員の言葉が曖昧だったりバラバラに感じるチームは特に属人性の度合いに関しては真面目に検討・検証したほうがいいでしょう。

モブプロでは、この属人性を部分的にでも解決できるという、大きな利点があります。もちろん、一回のモブプロで解決できる属人性の度合いはたかが知れていますし、誰も資料を残さなければ属人性の根本的な解決にはなりません。

ドキュメントを残せばいいのでは？

では、ドキュメントを残せば属人性を解決できるのでは？と考えるかもしれません。

これはドキュメントをどういうものと捉えるか次第です。

ガッチリした仕様書とかExcelドキュメントみたいなものは、よほど大企業でないと維持できるものではありません。人件費という名のメンテナンスコストを支払い続けて、常に適切なメンテナンスをしなければ実情と違う明らかな罠、ただの負債になってしまうからです。

少なくともベンチャーのように速度が必須な会社には、そういったカッチリしたドキュメントはそぐいません。そもそも現代では大会社においても速度が重要です。

モブプロでは、形式知だけでなく、暗黙知も得られるという大きなメリットがありますし、モブプロをやりながらドキュメントを少しずつ残していくことも可能です。

このとき残すべきドキュメントは仕様書という形ではなく、より粒度の小さいものです。

JavaDoc, JSDocやYARDのススメ

JavaDoc, JSDoc, YARD などと呼ばれるコード内ドキュメントの類いは、IDE支援が効くことと、ソースコードとの距離が近くメンテナスしやすいため、絶対に残すべきドキュメントです。

/** ほーげデータ */
type Hoge = {
  /** ほーげをフガるための文字列。IDとして使う */
  fuga: string

  /** ピヨる数字。0ピヨから100ピヨまでを指定可能 */
  piyo: number
}

/**
 * Hogeを分解する
 * @param hoge ほーげデータ
 * @param level 解析レベル。1が最大で、3が最小
 * @returns フガれるようにしたデータ
 */
function parseHoge(hoge: Hoge, level: 1|2|3): ParsedHoge {
  ....
}

たとえば、このコメントがあるだけで、parseHogeを参照している箇所で、マウスホバーをすると、「Hogeを分解する」という説明が表示されます。このコード例はTypeScriptなため、VSCodeを使えば、補完や情報の表示によりDX（開発者体験）の高いプログラミングが可能になります。

クラス、構造体、オブジェクト型、そういったもののプロパティの説明、関数・メソッドの引数や戻り値の説明は絶対に残すべき重要なものです。

RubyやJavaScriptのような、動的型付け言語であっても

/**
 * Hogeを分解する
 * @param {Hoge} hoge - ほーげデータ
 * @param {1|2|3} level - 解析レベル。1が最大で、3が最小
 * @returns ParsedHoge - フガれるようにしたデータ
*/
function parseHoge(hoge, level) {
  ...
}

というようなコメントを残すことで、静的型付け言語に近い情報を残せるでしょう。このとき、ドキュメントと中身が乖離していると、バグの温床になりますが、適切にメンテナンスされている限りは、バグの発生を抑え、開発効率を向上させます。

JavaScriptのコードでも適切なJSDocを書けば型アノテーションが可能です。たとえばこの例の parseHoge を TypeScript のコードから読み込んだ場合は、parseHoge の第一引数と第二引数が型チェックされます。第一引数であればHoge以外を入れようとするとエラーになりますし、第二引数なら1 2 3 以外のものを入れられません。

どうしても、プロジェクトでJavaScriptを書かなければいけない場合は、JSDocに型情報を残しましょう。

残すべきドキュメントの判断基準としては、VSCodeなどIDE/エディタで適切に情報が表示・補完されるか？を採用するといいでしょう。

レビューコストの低減

モブプロは、プログラミングをしながら、同時にコードレビューも済ませています。参加人数分のレビューアがいるという豪華なコードレビューです。

そのあと、コードレビューをもう一度するにしても、すでに理解したコードをレビューしなおすだけでしょうから、コードレビューの負荷はゼロか、圧倒的低減されているでしょう。クオリティを優先するなら、コードレビューするときはいったん休憩や日付を挟むことで脳をリセットした状態で再度、抜けがないか？を確認してもいいかもしれません。

参加者の習熟度の向上

モブプログラミングでは、コードの書き方、ライブラリの使い方、言語の書き方、エディタ・IDEの使い方、バグの追いかけ方など、ノウハウが行き来します。そのため、参加メンバーの習熟度が驚くほど向上できるため、参加すればするほど、その後のリソース効率もフロー効率も向上します。

オンボーディングに役立つ

当然ですが、新人のオンボーディング（チームへの定着化）にも役立ちます。

ハマりづらくなる

一人でタスクをこなしているとハマることがあります。特に集中力の高い人が調査系タスクをするととくにハマってしまう傾向があります。

モブプロでは、いくつかの理由によりハマる可能性は圧倒的に低くなります。

  • 複数人いるため、誰かしらが知識や知恵、あるいは検索ワードなどを持っている
  • 一人で考えると思い込みにハマりやすいがそれがなくなる
    • もちろん全員で思い込みにハマることもありますが、一人よりは確率として低い

つまり、知識量と視点の多さが鍵です。多角的に検討されたソースコードの品質は、一人が書いたコードよりも期待できるはずです。

個人 vs タスクの意識を、チーム vs 問題に変える

エンジニアがやるべきことは問題の解決（新規機能開発なども含めた広い概念）です。

そのため、個人がタスクと立ち向かうことは問題解決においては本質的ではありません。チームで問題を解決できればそれが望ましいはずです。モブプロはチームで問題を解決するためのテクニックなので、それに慣れることでメンバーの意識も変わるでしょう。（変えなければ、モブプロの効率は良くならないというのもあります）

まとめ

モブプロを成功させると、コミュニケーション効率とフロー効率が上がります。メンバーの教育効果、暗黙知の解消などの効果もあります。

特に長期的に見て得るものも多いでしょう。

初めてのモブプロを成功させるノウハウ

ここからがこの記事の本編です。

モブプロは誰のためのもの？

モブプログラミングは、プログラマのためだけのものではなくて、デザイナー、QA・テスター、PM/POなど、開発チーム全員のためのものです。

・ デザインの話、仕様決めの話をみんなで行えて、齟齬が発生しづらい
・ QA・テスターから見ると、プログラマがどういうふうに設計・実装したのか、わかりやすい

ここまでは繰り返しになりますが、重要なことなので書きました。

モブプロは、できる人のためのものではなくて、モブプロ参加者全員が納得感や知見を得ることが重要です。「モブがコミュニケーションすることで一つの創作物を作り上げる」というコンセプトを思い出してください。このとき誰か一人でも、うまくついていけていない人がいれば、それはコンセプトが破綻しはじめている合図です。

そのため、少しでもわからないことがあったら、流れを止めてでも質問攻めにするほうが、モブ全員のためになります。基本的には一番理解が浅い人のペースで進行するのが望ましいです。

カジュアルに質問してもいい空気を作っていこう。質問できる空気が一番大切

あと、モブプロが合わない人、好きじゃない人もいるので、そういった人が強制参加になるのは望ましくありません。参加するも自由、参加しないも自由にすべきです。

モブプロを主催する人は特にそういった空気感を意図的に作っていきましょう。賛同できるメンバーも、それに積極的に乗っかっていきましょう。じつはこれはモブプロを成功させるためには、とても大切なことです。

まずモブプロの進め方について合意を取りましょう

最初にモブプロについて説明と合意をしておきましょう。

「モブプロとはこうだ」という認識や、何を重要視するかは人によって異なります。

  • 目的はなにか？教育か実装か？
    • 本気でチームの開発効率を向上させたいのか？
  • 各自の役割を確認する
  • 進め方

毎回やる必要はないですが、初めてのモブプロ、初参加者がいる場合は確認しておきましょう。

また、事前準備として、タスク管理のチケットがある場合、そのURLを告知しておくと、参加者が予めチケットを確認できるので、よりスムーズに開始できるでしょう。

モブとタイピスト パターン

モブプロの代表的なパターンのひとつ、「モブ」と「タイピスト」という2つの役割のあるパターンを実際に解説します。

時間制で持ち回りの「タイピスト」1人と、その他全員「モブ」に別れます。

モブプロには他にもパターンはいくつかありますが、モブプロというコンセプトを理解しやすく、初めに最適なため、このパターンを紹介します。

また、このパターンはモブプロアンチパターンを回避しやすいようになっています。他の詳しいパターンを知りたい場合は末尾のリンク集などを参考にしてみてください。

モブ

モブの役割は、モブで相談をして実装内容を決めて、次に述べるタイピストに伝えることです。前述の通り、モブはタイピスト以外の全員です。

モブの話し合いがモブプロのメインです。

繰り返しになりますが、モブ全員で相談をしてタイピストに作業内容を指示します。

このときの指示は「46行目に、const hoge = () => 'hoge' を追加する」のように、具体的な内容です。「46行目に、こんすと ほげ いこーる かっこかっこ いこーるだいなり シングルクォートで囲ったほげ を追加する」とかでしょうか。

このとき VSCode の IntelliSense のように強力な補完機能があると、とても楽でしょう。

JS/TS慣れしてるメンバーであれば「46行目、こんすと ほげ いこーるで、引数なしラムダで文字列ほげを返す」だけで伝わるかもしれませんし、場合によっては、「128行目から135行目を関数として、80行目あたりに括りだす」くらいの指示で伝わるかもしれません。

口頭で指示をするため、どうしても伝わりにくいとか、省略したいとかはありますが、タイピストが悩まないように工夫してあげてください。この工夫の工程そのものも、メンバー全員にとって大切なことです。

モブは発言し、開発に貢献する役割です。発言をしましょう。紳士的に相談をしましょう。コミュニケーションがなくなるともうモブプロのコンセプトを満たせません。

何かしら成果が出たときには、過剰なくらい喜び、お互いを褒め称えたほうがいいでしょう。常に「いいね！」と喜び合うと、楽しくモブプロできるでしょう。「いえーい！」とかテンションを上げていったり、拍手を入れると気持ちよくできるでしょう。

タイピスト

タイピストの役割はキーボードに文字を打ち込む（タイピングをする）だけです。つまりタイピストとは、エディタ・IDEを操作し、キーボードに文字を打ち込む人のことです。

タイピストはタイピングできれば誰でも可能です。プログラミングが分からない人なら、タイピストの方がやりやすいかもしれません。モブは会話によって問題解決への貢献をする役割ですが、タイピストならキーさえ打てれば誰でも可能ですし、他の人の知恵で、自分がよくわかってないジャンルにチャレンジできる絶好のチャンスです。

モブとタイピストが別れている理由は、先程から何回か書いてる通り、モブプログラミングのコンセプトがモブ同士が話し合ってプログラムを作るためですが、話し合いをしていてもプログラマなら自分で打ち込んで主導したくなる生き物です。

それを防ぐためにこのような役割分担をします。

そういった話し合いを促すため、タイピストは、明らかに自分が考えるものと違う、たとえば typo やバグりそうなものであったとしても、極力モブを信頼して言われたとおりに打ち込んでください。

基本的に、タイピストは指示されていないことを打ち込んではいけません。

繰り返しになりますが、モブの話し合いにより、みんなでプログラムを作り上げるためです。

ただし、指示が不明瞭な場合は、もちろん遠慮なく質問をしましょう。少しでも分からないこと、解釈しづらいこと、理解できないことがあれば質問をしましょう。タイピストがモブと行うコミュニケーションも、モブプロにおいてとても大切なものです。

つまりタイピストがやるべきことは2つです。

  • モブの指示に従って文字を入力する
    • タイピストはモブが発言した内容以外を入力してはいけません
  • 指示に対して、より明確にするための質問をする
    • 分からない、不明瞭な指示には必ず、分からないと言いましょう
    • 指示された内容を理解するのも役割です。理解できないときは理解できるようになるまで質問すべきです

もし自分がタイピストをしているときに納得できない指示があったり、自分の考えと異なる方針で進みそうなときは、そこでタイピストを交代してもらうか、次に自分がモブになったときにそれを提案しましょう。

ほんとうにとてもよく見かける、最も多いアンチパターンは、タイピストが主導権を握ってしまうケースです。タイピストが考えてプログラムを作りモブが黙ってしまうような状況です。この場合の構図は、タイピストがソロ作業をしているところに、モブがなんとなく助言をしたり内職をするというものです。

これではモブプロというコンセプトが成立しなくなります。

何よりもこの状態では誰も楽しくないことになりがちです。もし、モブプロをやってもあまり効果がない、楽しくないということであれば、アンチパターンに引っかかってる可能性が高いでしょう。

そのためこの記事においては、モブとタイピストパターンで、タイピストはタイピングのみをするという、制約について強調をしています。

勿論モブプロには、ここで説明する以外のパターンもありますが、はじめはここまでで書いたやり方をオススメします。

モブプロにおいて絶対に守るべき大切な原則

モブプロというコンセプトを実現するために大切な原則を以下に述べます。

HRT（謙虚・尊敬・信頼）の原則

相手を否定・非難してはいけません。HRTは、謙虚・尊敬・信頼を意味する略語です。お互いHRTの原則を持ち、気持ちよくコミュニケーションしましょう。

これを守らない人がいると、モブプロはバトルの場になってしまい、チーム戦どころではなく、チームの中での諍いになってしまいます。

モブという場はモブ全員で作り上げるものです。

そのため、HRTを忘れないようにしましょう。

どんな下らないと感じられる質問もアイデアも否定されない空気感が重要です。

意見が別れたときは

そうはいっても意見が分かれることもあります。

コードを打ち込んでみて確認できることなら、まず簡単そうなものを実際に打ち込んで、コードをベースにして議論をしてみましょう。

意見が分かれそうであっても、HRTの原則を忘れずに話し合ってみましょう。

フォーマットは機械任せにしよう

インデントや書き方、そういったもので、意見が別れてしまうのは、自動フォーマッタが普及した現代においては、とてもつまらなく非生産的です。

JavaScript/TypeScript であれば prettier を導入しましょう（2020年においてはそれがベストプラクティスです）。それぞれの言語ごとに言語レベルのフォーマッタがあります。

インデントの仕方などといったものは、モブプロの心理的安全性を損ないやすいため、人手ではなく機械で自動フォーマットできるようにしましょう。

JavaScript/TypeScriptに限らず、現代のプログラミング環境には、必ずそういったものがあるはずです。

フォーマッタや linter のルールに悩んだときは？

なるべくシンプルなものを採用しましょう。ルールに凝っても仕方ありません。たいていは自転車置場議論にしかなりません。正直、サイコロを降って出た目で決めてもいいくらいどうでもいいものです。

一部のルールはとても効果的ですが、大半の書式やlintの細かい設定は生産性の向上には寄与しません。

ここで重要なことは、設定ファイルが書かれていて、人間が無駄なことを考えずにそのルールに任せられる事そのものに意味があるからです。

たとえばJavaScript/TypeScriptであれば、prettierが導入されていれば、そのルールそのものはどうでもいいです。prettierに自動フォーマットさせられることに意味があるのです。linterの多くのルールも同様です。

自転車置き場議論を回避するためのルール決めで自転車置場議論をしてしまうと本末転倒です。なるべくルールはシンプルにしましょう。

話し合いは、画面上にあるもの（ソースコード、設計図など）に対して行いましょう

モブの話し合いは空中戦にならないようにしましょう。ここでいう空中戦とはまだ存在をしていないコード、画面に書かれていないことです。

基本的にはモブの話し合いはすでにテキストエディタに打ち込まれているコードに対して行うべきです。モブで設計が必要な場合は同様に、テキストエディタやUMLツールなどに打ち込んだものに対してであるべきです。

これはなぜか？というと、個人の脳内にあるものは他の人とズレが生じる可能性が高いためです。ズレ、すれ違いが生じると、モブプロ体験はとても悪いモノになりがちです。

テキストエディタ・IDE・UMLツールのように、実際に形式化されたものを題材にしたほうがお互いの認識のズレがなくなります。

打ち込んでミスをしても誰も困ることはありません。空中戦をしてしまってコミュニケーションにミスをするよりは、打ち込んでミスをしましょう。

ソースコード以外をメモできる場所を用意しておくと便利です。ソース上にコメントアウトでもいいですし、別のテキストファイル・Markdownなどを開いておいてもいいでしょう。

タイピストは持ち回りで

10分〜15分程度でタイピストを交代しましょう。なるべく短い周期で交代するのが望ましいです。同じ人がずっとタイピストを続けるとタイピストがつまらなくなる、あるいはモブの話し合いが固定化されてしまうことがあります。順番はテキトウでもいいです。

できる限り全員がタイピストをしたほうがいいですが、どうしてもやりたくない人や聞き専の人がいればタイピストを免除してもいいでしょう。安心してモブプロに参加できることの方が大切です。

交代を短くするためには、VSCode LiveShare などを活用するといいでしょう。

リモートでやる場合は、タイピストが画面共有をするのが望ましいです。

休憩を必ずいれましょう

どれくらい入れるべきかはモブ参加者によって違いますが、モブプロは非常に疲れやすいので定期的な休憩を入れましょう。最初は1時間に1回、10〜15分などで試してみて、合わなければ変えていけばよいでしょう。

休憩をいれることによって、交代の時間を短くしても疲れが出にくいです。

ふりかえり

簡単でもいいので、極力ふりかえりをしましょう。

たとえば、モブプロが終わったあと「今日どうでしたか？」「楽しかった！」くらいでもかまいません。

モブプロ自体が新しい手法であるため、慣れている人、知見もまだまだ少ない世界です。「合う・合わない」「やりやすいかどうか」などをあぶり出したいところです。

そのため、ふりかえりにより、率直な感想を述べ合うのが望ましいでしょう。

意外に思うかもしれませんが、分かりづらい、やりづらい、追いかけづらい、ストレスである、ふりかえりや感想が何もでてこないのはなぜか?というような感想は、とても役に立つ、重要なヒントです。

特に、メンバーの中に「今やってることがよくわかってないけど進んじゃってるから仕方ない」「速度に追いつけていない」という人が出てくると、その人の楽しさが損なわれますし、モブプロをやる価値が激減してしまいます。

どうせならみんなで楽しくコミュニケーションしたいものです。

慣れてきたらしっかりふりかえりをしてみたほうが、より効果がでるでしょう。

参考: https://hurikaeri.booth.pm/items/1309148

入退場は基本的には自由にしておくほうがいい

途中で入ったり抜けたりするのは自由ということにしておくほうがいいでしょう。カジュアルに参加してみていいと思います。その場合、入った、抜けるなどを伝えるほうがスムーズになります。

内職をしないようにしましょう

特にリモートだと内職しがちですが、モブに参加するときはモブに集中しましょう。内職をしてしまう人は参加すべきではありません。

筆者達は、聞き専で入ること自体はありだと考えています。ただし、聞き専をする人は最初に明示したほうがいいでしょう。

また、内職を防ぐためにも、交代の時間は短いほうが良いかもしれません。

過程を残す

一回で終わらないモブプロをする場合、途中参加しやすいようにするために、モブプロの過程をチケットやその他ドキュメントシステムに残しましょう。リアルタイムで全てを残す必要はありませんが、次につながる程度には残しておくと有益です。

途中参加する人はチケットなどを読みつつ、わからないことがあったら質問してみてください。

タイピストのときに意見があったら

タイピストの項目にも書きましたが、タイピストをしているときに、ん？と思ったら交代してモブに回るといいでしょう。モブとタイピストパターンでは、タイピストは意図を理解するための質問はできても、指示内容を変える発言をしません。そこでタイピストを誰か他の人に変わってもらうのです。

タイピストからモブに変わったタイミングに限らずですが、誰かが過去の実装について意見を言い出した場合は、きちんとモブ全員でそれを聞きましょう。

くれぐれも 「それはもう終わったことだから」という様に流すのは厳禁です。それでは単なる言論封殺になってしまいます。HRTにも反しているため、意見は必ず聞き、必要があれば実装して試すようにしましょう。

この事例が頻出する場合は、チームや課題に、モブとタイピストパターンが合っていないかもしれません。他のパターンも検討してみてください。

モブプロを成立させるためのコツ

ここからは、絶対守らないといけない原則ではないですが、コツとして知っておくと良いことをまとめておきます。

やることをメモしておく

複雑なチケットをやる場合、そのチケットに、モブプロでやる内容をメモしておくとスムーズになります。

  • src/components/organisms/Hoge/views/index.tsx のコンポーネントの引数に hoge を追加する
  • hoge を、128行目あたりにある Title > Link > Dotdotdot に追加する
  • コンポーネントの引数を追加してエラーにならないように ../types.ts の Props 定義を変更する
  • コンポーネントの呼び出し元をたどって hoge の初期化を行う

などです。これは複雑度によりますが、大まかな方針だけでもあるとスムーズさが違います。

モブプロをやりはじめるときに、このメモの作成からスタートするといいでしょう。たとえば、あるチケットについて、やる内容を考える、調査するところからモブプロとしてスタートするのです。チケットでの仕様確認と、改修ポイントの確認などを一通りやって、その結果メモをチケットに残します。

途中で気になったことは、やっぱりメモしましょう

いま書いているコードとは違う部分で気になることが登場したら、メモを残しましょう。当然のことながらいま書いてるコードに集中すべきですが、あとで忘れそうなことがモブの会話で登場することはよくあります。

メモさえ残していけば、あとでなんとかなるはずです。

集中するために小さなタスクに分解してみよう

うまくいってるなら意識する必要はありませんが、細かいタスクに分割すると集中しやすくなります。状況に応じて、タスク分割も心がけましょう。

全員で考えても分からないことがでてきたとき

全員で考えても分からないことがでてきたときは、時間制限付き（10分とか）で、各自でぐぐったり調べたりするといいでしょう。必ず時間制限を設けて、その時間がすぎたらその時点でわかっていることを共有しましょう。

さらにまだ分からないことがある場合は、また同じくらいの時間制限を付けてもう一回調べ直してみましょう。

ここでのポイントは、ハマらないために必ず時間制限をつけることです。

外から応援を呼ぼう

別の有効な方法としては、外から応援を読んでくるというのもあります。誰か問題について知ってそうな人や、思わぬアイデアを出してくれそうな人に来てもらうのです。

スピードに注意しよう

慣れている人と慣れていない人では理解速度が異なります。一番不慣れな人が理解できる速度が望ましいでしょう。

リモートモブプログラミングをしているときなんかはとくにそうですが、ソースコード間の移動に、特に差が出やすいです。

慣れてるひとは、ソースコード名や行番号を意識的に発言すること、そこに飛ぶ理由を逐次発言するほうが望ましいです。

定期的に、みんながついてこれてるか確認するといいでしょう。

モブプロを連続してやれる時間

慣れてない人がいる環境で毎日モブプロするとかだったら、たぶん一日1時間か2時間が限界だと思います。本気で疲れるのと、惰性になりそうなので。

訓練されたチームでも4時間とかじゃないかなー。

ボーイスカウトルール

ボーイスカウトルールでやっていくと、少しずつソースが綺麗になっていくはずです。

commit するときは、checkout したときより、少しだけ綺麗にする

既存のコードにドキュメンテーション（JavaDoc,JSDoc,YARDなど）を追加するというのも、とてもいいアイデアです。ぜひ少しずつソースを綺麗にしていきましょう。

学習効果を無駄にしないために

モブプロの聖地 Hunter Industries 社は業務内に「学習時間」を1〜2時間設けているようです。これはすごく理にかなっていると思っていて、モブプロで新たな知見を得られる度合いはとても高いですが、その日のうちに自分の中にきっちり取り込まないと、せっかくの知見も定着しません。

さて、ここでいう学習は、言語やフレームワークなど汎用的な知識にはとどまりません。プロジェクトの暗黙知というのもあります。それらの記憶がフレッシュなうちに、ドキュメンテーションをしておくというのも大切です。

  • 新しく知ったやり方を実際に試してみる
  • 新しく知ったやり方について公開ブログや社内ドキュメントにまとめる
  • 暗黙知を何かしらの形式知に変える
    • 社内ドキュメントや、ソース内ドキュメントなど
    • Slack/Teams などコミュニケーションツールで、新しく知ったことについて発言する

多くの会社では業務内で「学習時間」を設けることは難しいでしょう。でも、周り巡って、フロー効率もリソース効率も向上するはずです。

言語やフレームワークの知識であっても、プロダクト固有のバッドノウハウなんてものもあります。学習時間 + アウトプットにより、チームのフロー効率のさらなる向上につなげることも可能でしょう。

フルフレックスだったり、裁量労働だったりする会社では、裁量において学習時間も設けられるはずです（それができないのであれば、そもそもその裁量労働は違法です）。

もっとも学習時間を義務化してもうまくいかないケースもあるかもしれないので、そこはチームメンバーの性質を見極めた上でやっていきましょう。チームや個々人の性質に合わせて運用することが大切です。

達人はファシリテーションを心がけよう

達人がすべて答えを言ってしまうとそれはもうモブプロではなく、ただのソロ作業に、見学者がいるだけの別のなにかになってしまいます。

慣れている人は、自分なりの答えがわかっていてもうまくファシリテーションすることでモブの議論を促しましょう。

もちろん、絶対に外すべきではないポイントのようなモノに関してはちゃんというべきです。

参加者のレベルや対象コードに対する理解度や、各自の性格などに合わせて、適切なレベル感で議論をファシリテーションすることが、達人には求められます。

それが達人にとって負担になりすぎるようなチームであれば、モブプロは向いていないかもしれません。

モブプロは過程も重要

モブがタイピストに効率よく、うまく意図を伝えられるようになる、モブ同士の話が向上するなど、モブプロの過程で得られるものは多くあります。

  • 伝えようとする努力
  • 問題をみんなで解決しようとする努力
  • みんなで場を作り上げようとする努力

などが積み重なっていきます。

向いてない作業

誰がやっても同じ結果になるような作業はモブプロには向いていません。

向いてない人

モブプロに向いてない人や、そもそもやりたくない人も、間違いなくいます。

自分が書いたコードにアイデンティティを持つタイプの人、職人肌の人は向いていません。達成感も人によっては得られにくいかもしれません。

楽しくモブプロをするためにも、参加は自由であるべきです。HRTを忘れないようにしましょう。

応用

もっとモブプログラミングをやってみたくなったら、ぜひとも応用編に進んでみましょう。

プログラミング以外にも応用できます

モブプログラミングは、プログラミング以外にも応用できます。モブワークなどと呼ばれています。

など、あらゆる事例に応用可能です。

そもそも、モブプロを実践的に導入し始めた本家である Hunters industires 社では、モブプロからスタートしたわけではないらしいです。

トラブルシューティングをモブでやったことから、モブワークの有用性に気づいて、少しずつモブプロをやりはじめたらしいです。この会社では最初のうちは一つの島で導入していたのが、その後には複数のモブ島を作って、全社的に取り入れているそうです。

トラブルシューティングをモブワークしよう

Hunter Indusries 社にならって、トラブルシューティングをモブでやってみましょう。トラブルシューティングは、大きなプレッシャーによって失敗するケースがあります。

個人に責任を押し付けるのではなく、チームでトラブルを解決しましょう。

全員が冷静になりトラブル対応ができるはずです。

このとき参考にすべきは Google SRE でいうポストモーテムです。トラブルの原因について、人を責める必要はありません。トラブルがなぜ起こったのか？冷静に淡々と分析し、次にトラブルが発生しない仕組みを考えればいいのです。

モブで環境構築をしよう

新しい開発者がチームに入って開発環境を構築するとして、たいていハマりやすく、かつ楽しくない作業になりがちです。チームが残した手順書が常に最新の正確なものであるとはかぎりません。よくある問題は、バージョン違いなどです。

そこで、環境構築をモブワークしましょう。

  • 環境差異がなくなる
  • チームへのオンボーディングがスムーズになる
  • 環境構築は、無駄にハマりやすいが、それがなくなる
  • チームとしては、環境構築手順の見直しもできる

など効果満載です。

そもそも環境構築自体は何も生み出しません。みんなで分かち合うことで、価値を生み出すためのステップに入りやすくすることが大切です。

オンラインでブレストをしよう

会社とは別件で筆者たちは、先日、Muralというツールを利用したモブワークを行いました。Muralは、多人数リアルタイムで、付箋を中心としたホワイトボードアプリ（コラボレーションツール）です。ブレストに向いています。そのときの様子はgipotalキックオフミーティングを開催した｜KANE｜noteに書かれています。

Muralはレスポンスもよく、やっていて楽しい、とても良いサービスです。ただ一つの難点は、現バージョン（2020/6/7）では日本語のexportは事実上うまくいかない、文字化けするという問題があるため、exportしたい場合はスクショを使うなどしなければいけません。

このとき感じたこととしては、やはりモブワークをする場合、必ずこのようなコラボレーションツールを使うべきです。これはモブプロの原則にある空中戦をしないためです。Mural以外にも探せば色々なオンラインコラボレーションツールがあります。

可能であれば、毎日モブの時間を設けましょう。

モブプロに効果があると感じ始めて、チームの合意が取れれば、毎日モブワークの時間を設けるといいでしょう。たとえば、毎日二時間とかです。

可能であれば、どれかの案件をモブのみでやってみましょう

程々に仕様が複雑な案件を、実際にモブプロだけでやってみましょう。

タスク管理をしている場合、タスクオーナーをモブという事にしてもいいかもしれません。

モブプロにおける役割のパターンはいくつかある

このドキュメントでは、モブとタイピストによるモブプロについて書きましたが、他のパターンもあります。モブプログラミングへの習熟度、プロダクト自体への習熟度や、個々人の技量・性質によって、やりやすいパターン、効率的なパターンは異なるでしょう。

何回かモブプロを体験して手応えを感じだしたら、ぜひ他のパターンを含めた、モブプロの知見を積極的に集めてみてください。

まとめ

モブプロは、チームでコミュニケーションをして問題を解決するというチーム戦 です。

モブプロと言いつつ「誰かが主導して他の人が少しだけ喋る」みたいなケースはモブプロとしては最も典型的な失敗事例であり、DX（開発者体験）の悪化により、モブプロ参加者が微妙な気持ちになってその後が続かなくなります。モブ全員のコミュニケーションによって問題を解決するという、コアコンセプトに立ち返ってください。

この記事は、どうやればモブのコミュニケーションを活性化させられるか？というノウハウを詰め込んだものです。

また、他の人の知見やツッコミなどがあれば随時受け付けています。

読んだほうがいいオススメ資料

だいたい、川口さんのブログを読めば事足りる気がしなくもないです。

MicronautでOpenAPIを使う方法
自然言語処理の形態素解析について調べたまとめ