はじめに
こんにちは、計測システム部SREブロックの@TAKAyuki_atkwskです。普段はZOZOMATやZOZOGLASS、ZOZOMETRYなどの身体計測サービスの開発・運用に携わっています。
最近公開されたZOZOMETRYですが、正式ローンチに至るまでにチーム間のサイロ化によるデリバリー速度の低下という課題が見えてきました。そこで、モブプログラミング（モブプロ）を通してチーム間のコラボレーションを促進し、課題の解決を試みている事例をご紹介します。
目次
背景・課題
私の所属する計測システム部では以下の組織図の通り、SRE、バックエンド、フロントエンド、研究開発の4つのチームが存在しています1。さらに、複数のプロジェクトが並行して進むことが多く、一人がプロジェクトを兼任することもあります。
（ZOZOエンジニア向け会社説明資料より引用）
各チームは役割によって責務が分けられていますが、SREチームとバックエンドチームの間で領域が重なる部分や依存する部分を進める際に上手くいかないことがありました。例えば、私たちはアプリケーションのソースコードとCloudFormationテンプレートをそれぞれ別のリポジトリで管理しています。前者はバックエンドチームが管理し、後者はSREチームが管理しています。ここで、バックエンドのメンバーがちょっとしたAWSリソースの追加や修正する場合にSREのメンバーに依頼する状況となっていました。また、逆のパターンでSREのメンバーからバックエンドのメンバーにちょっとしたソースコードの修正を依頼することもありました。
これらの出来事は、各チームが責務通りに作業しているとも捉えられますが、メンバー自身が作業したいにもかかわらずお作法や考え方が分からないために依頼した方が速そうという判断が一因になっていました。依頼することで結果的に作業待ちが発生し、ちょっと試して確認したいだけなのに時間が掛かってしまうことがありました。
冒頭で書いた「サイロ化によるデリバリー速度の低下という課題」の一例を取り上げました。サイロと言うには大げさかもしれませんが、両チーム間で実装・設計方針が揃っておらず大きな手戻りが発生したこともあり、コミュニケーションとコラボレーションの不足が要因としてあったと考えられます。
モブプロを試してみる
チーム間のコミュニケーションとコラボレーションを促進するための方策の1つとして私たちはモブプロを実施することにしました。実はSREチーム内では以前からモブプロを取り入れていたので私自身は経験がありました。SREチームのモブプロでは、なかなか取り組めなかった運用改善系のタスクを複数人で一気に取り組むことや、メンバーの技術力の底上げや新規参画者に対するナレッジの共有を目的にしていました。これらについてはある程度効果が出ていました。
ただ、チームをまたいだモブプロの経験はほとんど無かったため、まずは特定のプロジェクトもしくはある程度の機能で試したいと考えました。その頃、ZOZOMETRYではクローズドローンチ期間を設けていくつかの企業にサービスを提供していました。この運用の中で、頻度は低いものの開発者がSQLを実行する必要のある作業が顕在化してきました。この一部はスクリプト化されていますが、手動でSQLを実行するのは属人性が高く人為的なミスの起きやすいものとなっています。そこで、権限を持つメンバーなら誰でも安全に作業できるよう、管理画面を作ることになりました。
さらに、メンバーと話して以下のことからモブプロの題材として管理画面が適していそうだと判断しました。
- 緊急性の高い要件が発生しにくい
- 並行するプロジェクトがある中で着実にタスクを進めたい
- 複数のチームで協調して作業する必要がある
これでチームをまたいだモブプロを試していく準備が整いました。
私たちのモブプロのやり方
管理画面はいくつかのコンポーネントに別れていて、大まかにはフロントエンド、バックエンド（API）、これらを動かす基盤（AWSやKubernetesリソース）となります。コラボレーションを意識してAWSやKubernetesリソースの作成やCI/CDの整備、認証などの機能開発を中心にモブプロを行いました。
参加メンバーはSREメンバー1名（私）、バックエンドメンバー2〜3名、フロントエンドメンバー1名です。各メンバーはリモートワークしているので、以下のように音声と画面を共有しながら作業します。
- SlackのhuddleもしくはGoogle Meetで音声・映像を同期、画面共有
- Visual Studio CodeのLive Shareでソースコードを共有
- コミットにCo-authored-byトレーラーを付けてモブプロ参加者を共同作成者とする
モブプロは1回1時間の枠で週2回のペースで実施しています。この後の「改善点」のセクションで触れますが、複数のプロジェクトに参画しているメンバーもいるためなかなか空いている時間が見つけられず、このような時間枠としています。
事前準備
モブプロの事前準備として取り組むテーマとオーナーを決めておきます。実際に「オーナー」と呼ぶことはありませんが、説明のため便宜的にそう呼ぶことにします。オーナーはテーマ、ゴール、具体的にやること、参考資料などを社内ドキュメントツールとして利用するコンフルエンスに簡単にまとめておきます。内容の例を以下に示します。
## テーマ - ZOZOMETRY管理画面 フロントエンドのCI整備 ## ゴール - ECRリポジトリとIAM Roleが存在すること - GitHub ActionsワークフローでWebサーバーのイメージがビルドされ、ECRリポジトリにpushされていること ## 前回のおさらい - 前回のモブプロまとめページのリンク - 前回作成したプルリクエストのリンク ## やること - ECRリポジトリとIAM Roleの作成 - 作業するGitHubリポジトリ名: xxx - ECRリポジトリの名前: xxx - IAM Role: 既存のIAMRoleXxxを参考にする - GitHub Actionsワークフローの作成 - 作業するGitHubリポジトリ名: xxx - mainブランチへのマージ（push）をトリガーにする - 注意事項 - xxx - yyy - 別リポジトリの参考になるワークフローのリンク
このように作業についてまとめておくことで、メンバーには効率的に共有できて認識も揃いやすくなると考えています。あまり時間を確保できない中でメンバーの理解を深めることにおいて、私たちなりの工夫したポイントになります。
モブプロの流れ
ここからはモブプロ1回分の流れを説明します。
まず、冒頭の5〜10分でオーナーが先ほど紹介した事前準備のコンフルエンスを使い、今回のテーマ、ゴール、前回のおさらい、今回やることを共有し、参加メンバーの認識を揃えておきます。
このあと40分程度を実装の時間に費やします。一般的なモブプロと同様にタイピストとモブに分かれて作業を進めていきます。その日のゴールによっては慣れていないメンバーがタイピストになるようオーナーが調整することもあります。
最後の5分でふりかえりを行い、良かった点と改善できそうな点をメンバーで話し合います。以上がモブプロ1回分の流れとなります。
モブプロの実施スタイルはチームによって細かい部分が異なるので、社内の他のチームの事例も参考にしてみてください。
モブプロをやってみて
モブプロ内でのふりかえりの他に、SREとバックエンド互いの領域に対する習熟度についてのアンケートを実施しました。これらの内容を元にモブプロの効果について述べていきます。
モブプロに参加したメンバーの感想をいくつか紹介します。
- 互いの守備範囲の技術スタックの理解につながっていると思います
- Kubernetesの操作やインフラリソースの作成などで出来ることが増えたことが一番のグッドポイントでした！
- （管理画面の認証における）SSO設計についてみんなで話すのが楽しかったです
まず、お互いの領域に対する技術的な理解が増したというような感想が寄せられました。また、以下のアンケート回答結果においてもできることが増えているのが分かります。A-1からB-7までの項目はお互いの領域における作業に対応しており、Aがつくものはバックエンドメンバーに対して、BがつくものはSREメンバーに対する質問です。2例えば、「Kubernetesリポジトリでリソースの追加や修正を環境に応じて実施できる」「ローカル環境でAPIサーバーを起動できる」といった質問です。
それから、2つ目の感想を残してくれたバックエンドメンバーは、モブプロ開始後に別のプロジェクトでKubernetesリソースの作成や変更のプルリクエストを出していました。これは、背景・課題の部分で述べた、ちょっとした修正でも依頼して作業待ちになってしまうことへの解消に繋がると考えています。
また、私にとっては不慣れな領域でも参加メンバーの知識を組み合わせながら実装できて達成感を得られましたし、実装中に質問されることで自分自身の理解しきれていない部分が改めて分かり学びになりました。
さらに、このモブプロの様子を聞いた他のメンバーが別の組み合わせでモブプロやモブ作業を実施するようになり、コラボレーションの輪が広がったと感じました。また、障害対応の場面で、互いにシステムの解像度が高まったことやメンバーの得意を知れたことで以前よりも協力できるようになりました。
改善点
概ねうまく実施できていますが、改善したいこともあります。それは、モブプロの時間の長さについてです。現在は1回の枠は1時間で週に2回実施しています。しかし、1回あたりの時間枠が短いことで、あともう少しで実装しきれたのに時間切れ、リズムが出てきて盛り上がってきたところで時間切れ、となることがあります。ですので、今後は1回あたり2時間程度3の時間枠を用意できるようにしたいと考えています。
まとめ
本記事ではモブプロを通してチーム間のコラボレーションを促進させた事例を紹介しました。どの組織にもあてはまるものではありませんが、チーム間でコミュニケーションを改善したい、協力体制を築いていきたいと検討している方がいれば、ぜひ参考にしてみてください。今後もモブプロをきっかけとしてメンバーや他のチームとコラボレーションして、ZOZOMETRYを始めとしたサービスを改善していきたいと考えています。
また、この記事以外にもZOZOMETRYに関する記事を連載しておりますので、興味のある方はぜひご覧ください。
ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。
- この記事を書いている2024年9月末時点↩
- A-4、A-5、B-7の質問はモブプロ実施後に行ったアンケートで追加されたものです。↩
- 『モブプログラミング・ベストプラクティス ソフトウェアの品質と生産性をチームで高める』（2.4モビングインターバル）にはモビングセッションと呼ばれる、人々が1つのグループとしてモビングする継続的な時間は通常数時間に及ぶと書かれています。↩
