初めまして、にゃまと言います。
本記事はモブプログラミングAdvent Calender2019 23日目の投稿になります（1日遅れましたすみません🙇‍♂️）。
https://qiita.com/advent-calendar/2019/mobprogramming

私は今年の5月から新しいチームにジョインし、それから今までモブプロによる開発を続けてきています。
この記事では、自チームにおけるモブプロのやり方について話そうと思います。

弊チームのモブのやり方

弊チームはすべての開発をモブプロで行っています。1日の流れはこんな感じ。

時間	内容
10:00 ~ 10:30	カンバンをみて今日やることと進め方を整理
10:30 ~ 12:00	モブを1~2セッション実施 (50min/session)
12:00 ~ 12:15	昼会、チーム全体で今やっていることを共有
12:15 ~ 13:15	お昼休憩
13:15 ~ 19:00	モブを4~6セッション実施 (50min/session)

バックログやスプリントレビュー、振り返りは週に1回入れて調整しています。
開発で行き詰まったとき、方針転換が必要になったときは、セッションを中断して議論を開始します。案を出し合い、出尽くしたところで一つに決めます。開発メンバーだけで結論を出せないときは、悩み過ぎずプロダクトオーナーや利害関係者に相談して決断します。これを実現するために、スプリント計画の際はバックログアイテムの完了の定義とともに、悩んだとき誰にどうやって相談したら良いかまで確認します。
ジョインした頃は家に帰るとすぐベットに入って寝てしまうほど疲れ切ってしまいましたが、最近はこの開発にも慣れて帰宅後にリングフィットアドベンチャーをプレイできるほどになりました。

これは内定者アルバイトを迎え入れたときのモブの風景です。新しいメンバーがジョインしても変わらず、アプリケーション構成を議論しながら開発をしています。私たちのメンバーは共有PCを活用して1台のPCで開発をしているので、新メンバーがジョインしても環境セットアップの必要がないのです！
画面脇に黄色の付箋が貼られていますが、ここには不定期に行われる振り返りで決めたモブでのTryを書き留めています。画像中の指示棒も、この振り返りであげられた「（ナビゲーターが）何を指摘しているのかわかりにくい」というProblemに対する「指示棒を買う」というTryで購入したものです。こう言った些細な業務改善をみんなでこなせることもモブの醍醐味なのかもしれません。

ここからは、モブプロのよかったこと、改善したいことを話していきたいと思います。

よかったこと

5月にジョインしてからの半年を振り返ると、何よりも開発が楽しいです。自身の得意な領域は強みを生かしてメンバーをリードしていけば良いです。知らない領域・苦手な領域は他メンバーから学べます。他にも次のようなことを感じました。

タスクを完了させるまでの時間が早い

より正確にいうと、ユーザに価値を届けるまでの時間が短い、いわゆるフロー効率が高いです。
基本みんなでコードを書いているので、レビューを必要としません。コードを知る関係者は全員その場にいるので、わからないことがあってもすぐその場で確認できます（裏を返せば、誰もわからないことは失われた知識になります…）。このように一人で開発していると発生する非同期的なコミュニケーションを排除できるので、その分タスクを短い時間でこなすことができます。
また、多角的な視点で課題に望むことができることもタスクを早く完了させることに寄与しています。課題にぶち当たったとき、一人で解決しようとするとその人のスキルセットによった課題解決になりがちですが、複数人のときは複数のアイディアを複合した無駄のない課題解決ができることもあります。

失敗を共有できる

モブプロをしていても、ときにはバグを埋め込んでしまったり、障害を起こしてしまうことがあります。これ自体は避けようがありませんが、モブプロではその失敗からみんなで学ぶことができます。全員が同じ失敗をしているので、次同じようなタスクに直面しても同じ失敗をする確率が少なくなります。また、メンバーが入れ替わったとしても全員が同じ失敗を共有しているので、失敗経験を失うリスクも少なくできます。

課題に感じていること

私たちのモブプロはよく機能していると感じていますが、課題となる点もいくつかあります。いちばんの問題は開発完了からリリースまでの時間が長いことです。私たちのCD (Continuous Deploy) は古くから利用されていることもあって、開発完了からリリース完了までに30分かかってしまいます。この間私たちの手を完全に止めてしまい、次のタスクへ着手する足かせとなっています。
私たちはこの課題に対して、できるところから少しずつ改善を行っています。とはいえ、古くから運用されているCDなので、改善の見通しが立つときも立たないときもあります。見通しが立つか立たないかで、私たちは次のようなアプローチをとります。

改善の見通しが立つとき

見通しのたった部分をタスクに切り出します。複数ある場合は、開発体験が悪く、かつ短時間で解決できることから優先度を高くします。このタスクを、他の開発タスクと優先度を擦り合わせてから着手します。
開発体験が悪いかどうかは、開発メンバーによる主観で判断しています。

改善の見通しが立たないとき

あらかじめ調査タスクを設定します。調査タスクには時間の区切りを入れます。調査タスクに着手したら、設定された時間内で、改善の見通しを立ててタスクに切り出す作業を行います。切り出すことに成功したら、見通しが立った時と同様、他の開発タスクと優先度を擦り合わせてから着手をします。

おわりに

振り返ってみると、自分にとってはコミュニケーションコストやコンテキストスイッチに対するストレスが大きく改善されたように思えます。正直もっと多くの恩恵を受けているように感じますが、言語化できていないので今回はここまで。
私たちのやり方が、ビジネスの成功まで繋がるよう今後もモブプロを改善していきます！