こんにちは、ユビーでプロダクト開発エンジニアをしている Sosuke Suzuki です。
最近、チームのエンジニア間の連携がいい感じだなーと思ったので、その要因の一つであるモブプログラミングについて、実践したことを紹介します。
はじめに
最近、私の所属するチームでは、データベース、バックエンド、そしてフロントエンドにも大きな変更を加える必要がある、規模の大きなプロジェクトに取り組んでいました（そして、今も同じチームで別の大きなプロジェクトに取り組んでいます！）。
そのプロジェクトの具体的な内容を書くことはできませんが、大雑把に事情を説明します。
数年前に設計されたいくつかのテーブルがあり、それは当時からずっとユビーのビジネスにとって重要でした。しかしそれらのテーブルは、この数年の間に複雑になったビジネス要件には耐えられなくなっていました。
このままではビジネスの機会を毀損することになります。それでは困るので、現状を整理した上で、可能な限り未来に渡って耐えられるようにテーブルを再設計します。当然、それに伴ってバックエンドやフロントエンドにも大規模な修正が必要になります。
モブプログラミングの良し悪し
私のチームにはエンジニアが4人います。私を含め全員、フロントエンドもバックエンドも実装します。
大きなプロジェクトを進める上で、この4人のエンジニアがよく連携して実装することが重要だと考え、モブプログラミング(以下モブプロ)を導入することにしました。
モブプロは、良い点も知られていますが、悪い点も知られています。たとえば、メルカリの モブプログラミングを導入し、チーム一丸となってタスクに取り組むようになった話 では、知識の共有やチームの一体感の向上などの良い効果が説明されています。一方でサイボウズの ymmt さんの モブプログラミングに向いてない私の話 では、モブプロを行うことで逆に生産性が下がってしまった事例が紹介されています。
これらの記事で取り上げられている効果や事例は、両方とも私の感覚と一致します。
テーブル設計とGraphQLスキーマを中心にモブプロを行う
私たちの今回のプロジェクトにおいては、全ての実装をモブプロで行うのではなく、データベースのテーブルとGraphQLのスキーマを書く作業を中心にモブプロを行いました。
これらの箇所を中心としてモブプロを行ったのは、以下の理由からです。
- 一度実装まで進んでしまったら後戻りがしにくいため
- 複数のリポジトリに関係するインタフェースであり影響範囲が広いため
- アプリケーションの実装と比べて寿命が長く、その設計意図がチームメンバー間で共有されていることが重要であるため
これは、私達にとって上手く機能しました。
データベースの新しいテーブル設計は、チームのエンジニアのうち1人が考案しましたが、このモブプロを通して、その設計意図が他の3人のエンジニアにも浸透していきました。
GraphQLスキーマの設計については、お互いの得意領域を補完し合う効果がありました。チームの4人のエンジニアには、それぞれ得意な領域と不得意な領域があります。バックエンドが得意な人もいれば、フロントエンドが得意な人もいます。みんなで話しながら設計することで、バックエンドとフロントエンドの事情がそれぞれ尊重されたGraphQLスキーマになりました。
モブプロを実施する箇所を限定することによって、生産性を下げることなく、モブプロの良さを活かすことができました。
実装については同期レビューで見る
ちなみに、アプリケーションの実装コードについては30分から60分の間 Google Meet に集まって同期でレビューする会を実施しています。実装全体をモブプロで行うのではなく、成果物を同期で説明しながらレビューを行うようにしています。
こちらも、私たちにとっては良く機能しています。モブプロによる生産性の低下を心配する必要がなく、ほどよく知識が共有でき、チームの一体感も向上します。
おわりに
この記事では、私たちのプロジェクトにおいて、テーブルとGraphQLスキーマの設計を中心にモブプロを行うことで、生産性を下げることなくモブプロの良さを発揮できた事例を紹介しました。
もちろん、これとは違ったやり方で上手く機能しているモブプロもあると思いますし、逆に同じようなことをして上手くいかないこともあると思います。
どちらにしても、この記事が最終的に、読んでくれた人の生産性を改善するきっかけになれば幸いです。
Discussion