今日は、チーム全員が一緒に活動する、いわゆる「モブワーク」を紹介したいと思います👀

最近新しくチームに入社してくださった方が、前職で頻繁にやっていたようで、チームに輸入してきてくださいました〜👏(ありがたや)

モブワークとは

モブプログラミングが大元です。定義は引用しちゃいます。

    モブプログラミング(通称:モブプロ)は3人以上のエンジニアで1つのプログラムを書くことをいう。

    モブ(mob:群衆)が集まって行うモブプロは、3人以上のエンジニアが協力して1つのプログラムを完成させるが、全員がプログラムを書くというわけではない。1人1人に役割があって、それぞれの人がその役割を全うする。実際にコードを書くドライバー(タイピスト)と、コードを見ながら意見をするナビゲーターという2つの役割に分かれる。ドライバーとナビゲーターの役割は数十分といった一定時間で交代することがいいとされている。

ドライバーの役割:プログラウのコードを書く人。ナビゲーターの指示に従ってコードを書くが、改善の提案を行う。ドライバーは常に1人である。
ナビゲーターの役割:基本的にはナビゲーター同士で議論をしながらドライバーに対してどういったコードにするのか具体的に指示を出す人。ナビゲーターは複数人である。

モブプロとペアプロについて - Qiita 


単にデザインに関わる作業だけではなく、全てのタスクに対するアプローチにも使えます。
モブ(群衆で) + ワーク(仕事する)ってことですね。

最近は、以下のような場面でモブワークをしたのですが、チーム全体でモブワークの効力を強く体感することができました。

・デザイン修正のタスクを、デザイナー3名で
・エンジニアの実装時の仕様決めを、デザイナー・エンジニア計6名で
・ロードマップの検討を、チームの3名で

具体的に、なぜこんなやり方がいいんだ!もっと具体的に!!!論理的に説明しろ!!!
というマッチョなかたは、私が落とされた以下の2つの記事を読んでみてください。



ざっくりどんなやり方?

毎回完璧じゃないんですが、初めはデザインで行い以下のような流れを意識してました。
(慣れてくると、ぬるっと始まることの方が最近は多い)

----

1. 役割を決める
ドライバー

- 手を動かしてデザインを作る
- 課題をメンターに伝える
- テキストでメモするのではなく、何種類もビジュアルを作って目視で確認する

メンター
- 話しやすい雰囲気でいる
- なぜそのデザインなのか、理由を聞き理解した上でFBする
- 一方的な提案ではなく、一つのアイデアを出す
- ドライバーが作ったり、考える余裕を与える

----
2. 時間配分を決める
-
作るものが大きい場合、フェーズやページに分けて時間を区切る
- どんなに長くても 1h で 5分以上の休憩をする。(Yahoo! さんは15m~30mでやってた)

----
3. 共有事項を言語化する

以下の内容を共有することで、この時間の方向性を定める

- 何を作るか
- 現在どこまで進んでいるか?どのような段階か?
- 何を実現したいと思っているか?
- 制約条件(ビジネス・技術...)があるか
- 制作物の優先事項: 3つまで
例)
1.ビジネス的なゴールを達成できるか
2.伝えたいことが伝わっているか
3.見た目の美しさ...

----
4.モブ振り返りをする
何がうまくいきましたか?

集中: 気を逸らすものがなかったか
コミュニケーション: 良いペースで会話できたか
ペース: セッションがしんどいと感じた部分があったか
責任分担: 仕事をうまく分担できていたか
品質: 最終的な品質は高かったか


メリットってなんなのさ?

個人的に感じたメリットとして4点を紹介します。

1. レビューが不要になる

まず、最初から一緒に作業しているため、「えっと、この背景は...」というコンテクスト共有と、レビューが不要になります。特に、ドキュメントで背景を作成するのが大変なときや、忙しくて時間が取れない時ほど、モブワークめっちゃ楽!となります。

2. 発言数が増える

次に、モブワークでは普段あまり発言しない人も、会話を通じて意見を気軽に共有できるようになると感じました。チーム間のコミュニケーションが活発になり、皆がより意見を出しやすい雰囲気を作り出せる気がしています。

3. たくさんの脳みその使い方を知れる

加えて、モブワークは自分以外の考え方に触れる良い機会になります。「そんな考え方もあったのか!」と新たな視点を得ることができ、それが新たなアイデアや議論を生んだりします。

4. タスクのためのタスクが減る

そして最後に、モブワークを通じて、進捗報告然り、詳細なドキュメント化然り、レビューしてもらうためのコンテクスト共有然り...「タスクのためのタスク」が減少すると感じました。これが減ることで、本来の作業により集中でき、全体の生産性が上がるなぁと考えています。

モブの向き不向き

最後になりますが、もちろんタスクの性質によって、向き不向きがあると思っています。
以下の観点で、タスクの進め方を選ぶ必要がある気がします。

- 本来一緒に働いていれば削減できただろう、「待ち時間」をなくすためにモブをする
- 逆に、一緒に働いていても個人で作業した方が効率がいい(単純作業や調査)場合はソロワークが向いてる






いかがでしたでしょうか。
これからも、生産性爆上がりするために、モブワークをチーム活動に積極的に取り入れていきたいと思います。今日も一日、お疲れ様でしたーー!

ふるじゅん

その他参考URL

ペアデザイン・モブデザインを導入してみませんか?品質向上やプロジェクトの効率化 - Yahoo! JAPAN Tech Blog
https://techblog.yahoo.co.jp/entry/2022030230267417/

デザイナーもユーザーも幸せに。ペアデザインのすゝめ|tebiki ブログ
https://note.com/tebiki/n/n9aaaf20c1b88

オンライン上でも先輩デザイナーに気軽に相談できる「ペアデザイン」とは - Corporate Blog - ヤフー株式会社
https://about.yahoo.co.jp/info/blog/20220920/pairdesign.html

ペアリングセッションテンプレート
https://tuple.app/pair-programming-guide/template