おひさしぶりです。シュフティ デザイナーの仲島です。
コロナの影響で、時差勤務からのフルリモートになってバタバタしていて、毎日少しずつかけていたnoteの習慣がとまってしまってました😥
やっとリモートにも慣れてきたので、またこれから書いていきます🙌

今回は、そんな全員リモートという状況で、さらに初めてチーム全員でのモブデザプロ（しかも練習とかではなくガチのリリースストーリー）をやりました。
※デザインもライブデザインしながらなのでモブデザプロですｗ

実際に全員で作ったもの

▼仕事登録画面に追加されるフォーム機能を作成しました

▼もとになったPBI（プロダクトバックログアイテム）はこちら

このユーザーストーリーをもとに、
上記目的・課題を解決し、さらに1週間でリリースできる機能をモブデザプロで要件定義から作っていきました。

実は、このストーリーに取り掛かる際にひとつ想定外のことがありました。
それが全員リモートという状況です。
リファインメント時もコロナの影響下ではありましたが、リモート勤務メンバーは一部でした。
このストーリーをやるときには会社全体で原則リモート勤務になり、全員でモブプロも初めて＆全員リモートでというマッチョな取り組みとなりました。

どうやったか

役割構成はこちら
・デザイナー兼ディレクター1名
・フロントエンドチーム2名
・バックエンドチーム2名

【事前準備1】取り掛かる日程を決める
【事前準備2】前日くらいにデザイナー兼ディレクターが当日の流れをざっくり作る&周知
▼ざっくり作った本当にざっくりな流れ
1. Figmaでデザインしながら要件＆仕様決め20min
2. バックエンドチーム実装スタート 1h
3. フロントエンド＆デザイナーでモック作り1h
4. フロントエンド＆バックエンドでつなぎこみ実装30min
使用するビデオ通話はハングアウトミーティング
【当日1】デザインしながら要件＆仕様決め
【当日2】フロントルームとバックエンドルームに分かれて実装
※1名がドライバーとなり、もう1名は補助やテストケース作成を担当
【当日3】テスト作成＆テストケース準備＆フロント・バック連携確認
【当日4】動作テストからは各自の作業へ

と箇条書きにするとこんな感じで進めていきましたが、まあ当日はこんなにさらっとはいきませんでした(；´∀｀)

▼ハングアウトで画面共有の図
要件定義のときはデザイナが、その後はフロントエンドとバックエンドのドライバー役のメンバーが画面共有して、会話しながら作業していきました。

よかったこと

以下ふりかえりで出たチームメンバーの感想です。

全員（フロント・バック・デザイナー）での要件・仕様決め
リアルタイムでデザイナ・フロントエンド・バックエンドの人たちで会話しながら進められるので、仕様検討などをしながらコーディング、懸念点の相談などが行えたので効率はすごくよかった。

会話しながらの作業
全員リモートで業務しているという形式上、常に会話しながら進められるため適度なアイスブレイクを挟むことができた。

逆に通話つないでても実装集中できた
各々の作業に集中している間は古い言い方するとさぎょいぷみたいな感じで、喋ってないといけないみたいな圧はそんなに感じなかった。
※もしかしたらこれは人によるかもしれません。そして慣れで解決することでもありそう。

同時に行っていることにより疑問も同時に解決できる
このパラメータの項目名どうする？みたいな細かい統制的な話も同時並行で進められる(他の作業の止めさせてしまうのではないかという不安は無い)ので安心して質問ができる。

気になったこと

ドライバーはやはり緊張する
画面共有でコーディング風景を垂れ流していたが、見られる側はやっぱりちょっと見られてる特有の緊張感がある。
普段どおりのコーディングが出来るようになるまではやっぱり慣れが必要そう。

時間が限られるため、どうしても後から考慮漏れは出る
・全員が顔突き合わせられる時間
・リリースに持っていくためのスケジュール
で考えると、全員で要件定義や仕様検討をしているとはいえ、時間が短いため懸念点などは作業してから初めて発覚することも多かった。
そうすると、実装時の作業量増加や、テスト→修正の往復が増えて、予定のスケジュールよりも時間がオーバーしてしまった。

スケジュール問題
シュフティでは1週間スプリントのためただでさえ実装時間が短めです。
さらに、スクラムイベント、別件のMTG、別ストーリーの作業がはいってきます。
そう考えると、実質全員でモブプロできる時間というのが限られていました。
今回は5ポイントのストーリーでさらに考慮ポイントが多い対応箇所だったため、（リリースにのせるため）エンジニア陣は当日21時くらいまで残業をしてがんばってくれました。
スケジュール自体をどうにかすることは現実的でないため、もしまたやるなら見積もりの軽めのストーリーがよさそう。

非ドライバーの手持ち無沙汰問題
モブプロで見る側の人は若干手持ち無沙汰になる・・・？
VSCode Live Shareの導入なども検討して、見る・作るを分担せずに参加者みんなでコーディングする環境を整えればもっと効率があがりそう。
ここはモブプロそのものの理解や、慣れやツールで非ドライバーもリアルタイムコードレビューを担えれば問題なかったりなどはありそう。

私（デザイナー）個人の所感

全員での要件定義は普段の取り組みにも良さそうと思いました。
その良さは、文字通り全員いるというところです。
普段だと開発に関わる人のみがそのストーリーについて考えますが、全員でやることで多角的な意見が集めやすいです。
要件定義や仕様検討などまさに多角的な視点が必要な場合に、全員の意義が発揮されていると思いました。

人の作業をみるのが好きなひとにはたまらない
私は人の作業みるの好きなんですよね。
なので手持ち無沙汰感とかは全く無くとても楽しかったです。
ただ、効率主義な人はきっとモブプロってモヤモヤするんだろうなぁとは思いました。
そういう人をドライバーに据えるとか特性にあわせて配置できれば問題ないのかな。

そもそも集中タイプにはあわないかも
1人で作業したいタイプ、隣でがやがやされるのが苦手なタイプだと、そもそもみんなで作るのが向かなそうですね。
チームでやることなので、特性にあわせて取り入れるほうが個人的にはいいのかなと思いました。

デザイン+フロントはモブデザプロの相性よさそう
（先述したメンバーの特性の部分もあるかもしれないですが）その場でもう少しUIこうしたいとかをリクエストしながら同時にコーディングしてもらえるのがとてもよかったです。
エラーハンドリングなどの地味な部分も、普段だと意外と手戻り多かったりするのですが、その場で「こうしましょう」と話し合ってから反映してもらえるので効率的にも感じました。

まとめ

・全員リモートでもモブデザプロはなんとかできる！
・特性にあった配置を考慮するとよさそう
・対応するストーリーの見積もりに気をつけよう
・慣れもありそうなので、懲りずにチャレンジできるとよい