こんにちは！フィードフォースで EC Booster というプロダクトを作っている @sukechannnn です。
この記事は Feedforce Advent Calendar 2020 の 11日目の記事です。
昨日は kogai さんの 趣味の本屋を始めました でした。実際に自分でECサイトを立ち上げて運営するのって、言うは易く行うは難しですよね。すごいです。
さて、内容に入っていきます。
EC Booster チームではメイン開発をモブプログラミングで行っています！
EC Booster はEC事業者様の集客を支援するサービスで、主に Google ショッピング広告を扱っています。また、今年１１月にフリープランをリリースし、より多くのEC担当者様をご支援できるよう機能開発を進めています。
アプリケーションの構成は、フロントエンドが React + Flow (TypeScript 移行中)、サーバーサイドが Ruby on Rails で、API が GraphQL です。また、データフィード広告を扱う関係上、Ruby で書かれたバッチ処理がたくさん動いています。広告領域はなかなかに複雑で、深いドメイン知識が必要です。
そんなプロダクトですが、現在はモブプログラミング（以下モブプロ）で全員がフロントエンド/バックエンドの垣根なく開発をしています。モブプロを導入した当初は試行錯誤の連続でしたが、最近はとても良い感じです。そして、気づいたらチームそのものが成長してきた...と感じています。
この記事では、僕ら開発チームがどのようにモブプロの課題を乗り越え、モブプロの利点を生かして開発できるようになったのかを共有できればと思います。少し長いですが、お付き合いください 🙏
RSGT でモブプロを知る
僕がモブプログラミングという概念を知ったきっかけは Regional Scrum Gathering Tokyo 2018 というスクラム開発を題材にしたカンファレンスでした。
モブプロは、ドライバーというコードを書く人が１人、それ以外のナビゲーターと呼ばれる複数の人で行います。ナビゲーターはドライバーに対して、実装する内容を指示します。ドライバーは支持された内容をコードに書いていく、という感じです。ドライバーは適宜交代していきます。
RSGT で発表を聞いた時は、話している内容には説得力があり楽しそうだったものの、「それぞれ個人で開発した方が集中できて進捗も出るんじゃないかなぁ」と半信半疑でした。まさか自分がモブプロをやることになるとは、この時は思ってもいませんでした。
時は流れ〜開発チームのメンバーが入れ替わることに
それから２年くらい経ち、今年の４月に EC Booster 開発チームのメンバーが入れ替わることになりました。デザイナー含め８人いた開発メンバーは僕含め４人になり、そのうち２人（当時フロントエンド担当）は入社して日が浅いという状況でした。その時リーダー的な役割を果たせと谷垣さん（この記事の右側の髪の長い人）に言い渡された僕は、どうしようかなと考え始めました。
- プロダクトの複雑なドメインをお二人にもしっかりキャッチアップして欲しい
- 広告運用やデータフィードなどのドメイン知識があった方が、主体的に開発できると思ったため
- バッチ処理が多いアプリケーションなので、どういう処理をしているかを把握してもらった方がフロントエンドの開発をするにも役立ちそう
- フロントエンドだけじゃなくてバックエンドも開発してもらいたいな（彼らも意欲的だった）
その時ちょうど、コロナで出社できない日常がスタートし、会社で直に話ができなくなってしまいました。
そうだ、モブプロしよう！
そこで思い出したのがモブプロです。以下のような理由から、オフィスで話ができないならずっとZoomを繋いでいればいいのでは？と思い、提案してみました。
- 都度 zoom を繋ぐのだと、どうしても会話するハードルが上がってしまう
- ドメインの説明は、直接話せば５分で伝えられることが文字だと３０分かかる、みたいなことが多い
- 相手が理解してそうか？をリアクションから読み取ることで、補足説明できる（文字だとそれが分からない）
- 以前にも少しモブプロを試していたが、リモートワークとの親和性が高そうだった
上記を説明したら、開発メンバーのみんなも「せやな」と同意してくれたので、やってみることになりました。
モブプロを始めたら情報の非対称性がなくなっていった
最初は小さな改修をしながらドメイン知識をキャッチアップ
最初は大きな開発ではなく、小さな改修を繰り返しながらドメイン知識のキャッチアップを進めていきました。
ドメイン知識が詰まってるのが主にバックエンド（というかバッチ処理）だったので、最初はバックエンドの改修から始めました。キャッチアップして欲しい人にドライバーをお願いし、ナビゲーターが解説しながらコードを書いてもらう感じです。やってみると、実際に手を動かしてもらいながら説明できたので、口頭で説明するよりも知識が染み込んで行く感覚がありました。日々の運用作業も皆に担当してもらい、よく発生するアラートや必要な対応を、裏側の事情も含めて理解してもらうのに役立てました。
ただ、その時はバックエンド担当⇢フロントエンド担当に教える感じが続いてしまいました。
アプリケーションの全部を全員で開発しよう！
しばらくやってみて、フロントエンド担当にバックエンドをやってもらうなら、バックエンド担当もフロントエンドやらなあかんやろ、ということでバックエンドとフロントエンドの垣根をなくしました。それにより、フロントエンド担当⇢バックエンド担当の説明も生まれ、お互いの話すバランスがちょうど良い感じになり、双方向のコミュニケーションになりました。
その結果、ドメイン知識だけでなく、技術的にも情報の非対称性が減っていきました。今では技術的な課題をフロントエンド/バックエンド横断で全員が把握してるので、議論がとてもスムーズです。
メインの開発もモブプロでやってみることに
最初はドメイン知識のキャッチアップがある程度できたら非同期な開発に戻ろうと思っていましたが、モブプロが予想以上に良かったので新機能のメイン開発も引き続きモブプロでやってみることにしました。その時は、以下の２つを利点と感じていました。
- "何をどう作るか" という議論がノータイムでできることの価値が思ったより高かった（コンテキストの共有がしやすい）
- プランニングでは話しきれない、実際のコードを元にした議論がしやすかった
その当時に実装しようとしていたのが冒頭で紹介した「フリープラン」という完全に新規の開発だったので、メンバー間の認識を合わせることが特に重要でした。それに加え、モブプロでも開発スピードが思っていたより落ちなかったのも導入を後押ししてくれました。
モブプロは良いことずくめ！に感じたが...
こうしてモブプロでのメイン開発がスタートしました。めっちゃええやん！と思って始めたモブプロでしたが、やっていく中でいくつか課題も見えてきました。
- めちゃくちゃ疲れる（最初は「これは本当に毎日続けられるのか？」と途方に暮れるレベルで疲れた）
- ずっと Zoom 繋いでるけど何を話そう...
- 開発の進み具合が良くない
- 議論を進める人に偏りが出る
- 個人で集中して調査したり開発したりする時間も必要では？
特に課題だったのは、思っていたより "疲れる" ということでした。そのせいで一時期は開発スピードが落ち、朝起きるのがつらい状態になってしまいました...。このままではアカン！ということで、これらの課題を解決するために、色々な工夫をしてきました。
モブプロを上手くやるための工夫
- ① 休憩する
- ② 雑談する
- ③ なるべく毎日同じ時間モブプロする
- ④ その日やることを朝会で話し合う
- ⑤ 個人タスクを用意する
- ⑥ プランニングと開発キックオフ
- ⑦ 自分から話さない人にも明示的に意見を聞く
これらの工夫を繰り返した結果、モブプロが上手くできるようになっただけでなく、チームそのものが成長していきました。
それぞれ詳しく説明していきます。
工夫① - 休憩する
休憩するって当たり前のことなんですが、集中してしまうと忘れがちになるし、モブプロをやり始めた最初はみんな探り探りなので「休憩しましょう」とか気軽に言いにくい部分もあったように思います。
そのため、まずは休憩する習慣を付けるために、あえて Zoom の無料プランを使って "40分で強制的に休憩" するようにしました。ポモドーロテクニックとか色々ありますが、これが一番確実でした。本当に強制的に切れるので、タイミングによっては笑いが起きて、和やかな雰囲気が副次的に醸成されていきました。
最近は zoom の有料プランを使ってますが、"適度に休憩を取る" という習慣が根付いているので、適当なタイミングで誰かが休憩入れてくれます。休憩が上手になったので、今は明確なルールは定めてません。ガッと60分やりたい時もあれば、30分で区切りが良い時もありますからね。それでも以前より格段に疲れなくなりました。
工夫② - 雑談する
一見すると業務に関係のないような雑談もして良いよ！という雰囲気作りに務めました。特別 "雑談の時間" を作っているわけではなく、突発的な雑談を盛り上げるイメージです。これには、発言のハードルを徹底的に下げて、ちょっとした懸念やアイディアをポンと出せるようなチームにしたいという思いがありました。また、単に "話す" ことで疲れないようにしたいなとも思っていました。
結果、チームメンバーがお互いのことを知るきっかけになり、それぞれの考え方や得手不得手を把握した上で議論ができるようになってきました。時には、エンジニアリングと全く関係ない雑談から実装のアイディアが浮かんだりして面白いです。
開発メンバーが打ち解けている様子
エビチリ🍤 をきっかけに、モブプロが解散するとエビのリアクションが飛び交うようになりました。良いですね。
工夫③ - なるべく毎日同じ時間モブプロする
以前は、金曜日にまとめてプランニングを行っていたので、モブプロできるのが週４日でした。１日の中で５時間モブプロをやる日と、全くやらない日が混在してる状態です。集中して作業する時間をまとめて確保するためにそうしていたのですが、モブプロは長時間やるとめちゃくちゃ疲れるんですよね。逆に言うと、クリアな脳なら短時間でもめちゃくちゃ進捗します。
ということで、なるべく同じ時間で毎日モブプロした方が良いことが分かったので、プランニングを他の日に移動して、最低２時間はモブプロの時間を確保するようにしました。今では無理なく週の最後まで開発をすることができています。
また、上記の工夫により毎日の進捗が安定するようになったので、プロジェクトマネージメントの難易度がぐっと下がりました。この半年間、ほぼ事前の見積もり通りに開発が進んでいるのは自分でもびっくりです（ガントチャートで記録してます）。
余談 - モブプロではレビューが要らない
モブプロを始めてから、以前よりも見積もりが正確になっていることに気づきました。これには "モブプロではレビューがほとんど不要" という特性も関係しているように思います。
- 非同期な開発だと「開発⇢レビュー⇢ (修正⇢レビュー) * n回⇢リリース」だったので、
(修正⇢レビュー) * n回の部分も見積もる必要があったが難しかった - モブプロだと「開発⇢リリース」と単純なので、正確に見積もりやすい
やってみて分かったことですが、モブプロだと本当にレビューが最低限で済みます。実装の時点で複数人の目が入ってますからね。今のところ大きなバグもありませんし、これに関しては "コストが下がった" と言って良いでしょう。
工夫④ - その日やることを朝会で話し合う
朝会は元々、開発メンバーがそれぞれ「昨日やったこと/今日やること」を報告するという、アジャイル開発ではオーソドックスなやり方でした。非同期な開発では、それぞれやってることが違うので報告し合う必要があったのですが、具体的な内容までは分からないので朝会で何か議論が発生することは稀でした。
モブプロでは、昨日やったことは全員が知っているので、個々人が別々に報告する必要がありません。とはいえ昨日やったことの確認はしたいので、日替わりで１人がやったことを振り返り、その後に今日やることを話し合う感じにしてます。
この、"今日やることを話し合う" 時間がとても良くて、昨日の実装の不安な点を話し合ったり（寝て起きると人は閃く）、これから実装するアプリケーションの設計を話し合ったりと、お互いの認識を同期する場になっています。毎日ちょっとしたプランニングをしてる感じですね。
特に話すことがない日でも、すぐに区切るのではなく積極的に雑談するようにしてます。雑談することでそれぞれの体調や気持ち的な浮き沈みもなんとなく分かり、今日のモブプロの進め方とかどこまでやるかを確認できます。あと、単純に雑談は楽しいので、その日１日頑張ろう！という気持ちになります。
工夫⑤ - 個人タスクを用意する
モブプロが中心ではあるものの、個人で開発した方が効率的なことも多々ありますよね。
- 新しい技術の調査
- リファクタリング
- ある程度形になった後の細かい機能/テストの追加
- ライブラリーのアップデート
- etc...
これらは明示的に "個人タスク" と切り出して、個人をアサインして進めるようにしています。当たり前ですが、個人タスクをやる時間は設けていて、良い息抜きになってるみたいです。
何を個人タスクにするかは、モブプロの中で話し合ってサッと決まってしまうことが多いです。個人タスクをやってて詰まってしまった時にはいつでも聞いて良いし、場合によってはモブプロに戻ることもあります。
また、実装していて「気になるから調べてたらできちゃった」みたいな事もエンジニアならあると思うんですが、そういう時は共有してもらった上でマージしちゃいます。ガチガチにモブプロじゃないとダメ！というルールにしているわけではなく、きちんとコンテキストが共有できているなら良いのです。
工夫⑥ - プランニングと開発キックオフ
以前は週次のプランニングは重たい行事でした。来週やることがよく分からないまま、各自で実装をしていたからです。プランニングでしっかり決めないと...というプレッシャーが、チーム全体の空気を重くしていたように思います。
今では、朝会 + モブプロにより毎日やることを確認しているので、開発タスクについて週次のプランニングで話し合うことがかなり減りました。今はビジネスサイドへの進捗状況の共有と、メインタスク以外に発生する細かいタスクについて相談することが主になっています。
代わり...というわけではないのですが、月曜の朝に "プチプランニング" と称して、その週に何をどこまで開発するか確認する場を設けています。その後にチーム全体のミーティングがあるので、プチプランニングで話したことを共有し、チーム全体での認識を合わせるようにしています。
そして、大きな開発を始める前には "開発キックオフ" を開催するようになりました。UI/UXデザインとアプリケーション設計の大まかな叩き台を僕が用意しておき、それを元に具体的な実装について話し合うミーティングです。これは１日で終わることもあるし、数日かかることもあります。今開発している機能の開発キックオフは数日かかりましたが、とても良い感じのアーキテクチャになりました。具体的な設計まで行えたので見通しが良く、楽しく開発を進めることができています。
工夫⑦ - 自分から話さない人にも明示的に意見を聞く
最後に、これは個人的に意識していたことですが、自分から話さない人にも積極的に意見を聞くようにしてました。
モブプロを始めた当初は議論を進める人に偏りが出やすかったのですが、改めて意見を聞いてみると、頭の中で別の意見を持ってることも多かったのです。"話さない == 意見がない" ではないんですよね。
なので、雑談を通じて話しやすい雰囲気を作るのとセットで、積極的に全員の意見を明示的に聞くようにしていました。その結果、見落としていた懸念点に気づけたり、実は不要な実装だったことに気づけたりして、実利を得ることができました。
最近は、特に僕が聞かなくてもみんな意見を言ってくれますし、大丈夫なときは「大丈夫です」って明示的に言ってくれます（リアクションだいじ）。意見を求める側も、気になる時は全員の意見を明示的に聞く流れができてきました。すごく良いことだなと思っています。
モブプロを上手くやるための工夫を繰り返していたら開発チームそのものが成長した
こんな感じで、モブプロを上手くやるための工夫を繰り返してしたら、チームそのものが良い感じになり、大きく成長することができました。
モブプロの何が良かったのでしょうか。僕は、チームメンバー全員が "自分が考えていること/実際にやったこと" を共有することの大切さを理解し、積極的に共有できる状態になったこと、なのかなと思っています。
以前は喋る前に緊張してめちゃくちゃ準備してたメンバーが、今は頭の中にあるものをそのまま話してくれるようになりました。特に取り繕うこともなく、自然とです。
最近では、今後のやりたいことや構想をチームメンバーと話すと、それぞれで良いやり方や設計を考えてモブプロに持ち寄ってくれます。モブプロで各自が考えたことを元に話し合う時間がとても楽しくて、結果としてめっちゃ良いアーキテクチャが生まれています。
今ならモブプロでなくても、非同期で開発を進めることもできると思います。実際に、開発する内容によっては、メイン開発であっても非同期で実装することもあります。それでも今、メイン開発をモブプロで進めているのは、このままモブプロで行くか？を改めて全員で確認し、その方が良いと皆が明示的に選んでいるからです。
全員がコンテキストを共有した状態で考え工夫することで、チームとして成長できたのかなと思っています。ここまで大変なこともありましたが、諦めずに続けてきて良かった！
一緒に工夫しながら開発してくれているメンバーには感謝しかありません。これからもよろしくお願いします！！！
明日は daido1976 の「好きな動画の話」です！お楽しみに！（ちなみに僕が好きなユーチューバーは かねこ さんです。）
