2022/03/01

メルカリShopsにおける開発の進め方

Author:: OnoTakatoshi

, 2022/03/01

こんにちは！ソウゾウの Software Engineer の @takatoshiono です。連載：メルカリShops 開発の裏側 Vol.2 の11日目を担当させていただきます。

この記事ではメルカリShopsを開発するソフトウェアエンジニアが普段どのように開発を進めているのかを紹介します。みなさんがその様子を頭の中にイメージできるようになったら嬉しいです。

はじめに

ひとことで「開発」と言っても、その工程は企画、仕様策定、見積もり、タスク分解、実装、QAなど様々です。この記事では主に見積り〜実装までの工程について、ソフトウェアエンジニアの観点で個人的な考えも織り交ぜながら紹介していきます。

なお、進め方はもちろん1つではありません。チーム、個人、プロジェクトによっても変わってきますし、日々学びを得ながら改善していくものでもあります。ここで紹介するのは現時点でのスナップショットです。

メルカリShopsの開発を支える組織に記載があるように、ソウゾウの開発チームは現在3つに分かれています。ここで紹介するのは私が所属しているTeam Bの内容となります。

Product Org

ユーザーストーリーの分割と見積もり

まずは開発を通して実現したいことについて、ユーザーストーリー分割をします。

これはチームメンバー全員（Product Manager、Frontend、Backend、QAの各エンジニア、デザイナーなど）が参加するイベントです。議論のベースはProduct Managerと一部のエンジニアで作成しておくことが多いです。

ユーザーストーリーはユーザーに価値を提供するための作業単位になります。例えば以下のようなものです。

ショップ管理画面で今月の売上金を確認できる
売上履歴画面で今月以前の月別売上金を確認できる

分割の単位は難しいところですが、チームメンバーで対話をしながら決めています。また時間が経ってから「やっぱり大きいよね」となったら、その時に分割することもあります。

次に、分割したユーザーストーリーについて、実現するために必要になりそうなタスクや疑問点を書きます。そして議論を通して解像度を高めていきます。

最後にプランニングポーカーを使ってストーリーポイントを付けます。数字としては以下のような感じです。

1: すぐできる
3: 1日くらい
5: 2〜3日くらい
8: 1週間くらい
13: 2週間くらい

ここでも対話を通して数字を決めていきます。それほど神経質に決めるわけではなく、例えば「どちらか迷ったときはとりあえず大きい方にしておく」などとしています。

実際のところ、私は議論で積極的に発言するタイプではありませんが、自分一人では気づけない観点や考え方を知ることができるので「チームメンバー全員で取り組む」これらの作業は好きです。

また、この記事では詳しく紹介しませんが、開発内容によってはDesign Docを書くことも増えてきました。Design Docについて詳しく知りたい方はメルカリShopsでのDesign Docs運用についてをご参照ください。

スプリント

私が所属するチームではスクラムのスプリントを2週間単位で回しています。分割されたユーザーストーリーはスプリントに追加されてから実装に取り掛かります。

タスク分解

さて、ユーザーストーリーをスプリントに入れて取り掛かろうとした時、いきなり実装を始めるわけではありません。大抵の場合はいくつかのタスクに分解します。ここからの作業は担当する人がリードして動くことが多いです。個人的には以下のことを意識しています。

リリースまでの流れをイメージする

メルカリShopsはすでに多くのお客さまに使っていただいているサービスなので、作ったものをリリースするときには既存の機能を壊さないように注意する必要があります。そのため、最初にリリース戦略を頭に描いてみるということをしています。具体的には以下のようなことです。

段階的なリリースができるか？
データのマイグレーションは必要か？

これらを考えることで、作業の順番や開発ブランチの分け方を決めるときの判断材料にすることができると考えています。

また大きな変更を一度のリリースで行うよりも、小さいリリースに分けて行うほうが心理的なプレッシャーが少ないという点もあります。ただ、リリースをする際のQAテストなどの手間は増えてしまうのでデメリットもあると思います。

集まって話す場を作る

1つの機能は一人で担当することも、複数人で担当することもあります。

複数人で開発を進める場合、大抵はメンバー間で知識の偏りがある状態だと思います。そのため、最初に集まって話す場を作るのがいいと考えています。自分の場合、その際にやることとしては以下のような感じです。

あらためて全体像を確認する
次に着手するユーザーストーリーを眺める
ユーザーストーリーを実現するための具体的な実装を考える
タスクに分割する
担当を決める

ここでコンテキストを共有して、さらに具体的な作業単位のタスクに分割できると、その後の進め方がスムーズになる気がしています。また途中で担当メンバーが増えた場合には再度話す場を作るのがいいと思います。

タスクは見える化する

ソウゾウではJIRAを使ってプロジェクト管理をしているので、ユーザーストーリーと分割したタスクはJIRAのチケットにします。

個人的には「タスクが見える化している状態」というのがとても好きなので、なにか作業すべきこと / 考えるべきことなどが発生したら「とりあえずチケットを作る」のがいいと考えています。タスクの見える化のメリットはいくつかあると思っています。

やるべきことや問題が認識できる
朝会などの場でチームに共有できる
人にアサインできる

つまり、個人による気づきをアウトプットすることで、チーム全体のタスクとして捉えることができます。

実装

タスクの分割ができたら実装していきます。ソウゾウではGitHubを使ってコードを管理しています。mainブランチは基本的には常にリリース可能な状態になっていて、そこから自由に開発用のfeatureブランチを切って開発を進めるスタイルです。

コードを書く環境としては、大きくローカル環境とVisual Studio Code Remote Developmentを使用したリモート環境があります。私はBackendのコードを書く機会が多いのですが、リモート環境を好んで使っています。理由としては、

元々VS Codeを使っていた
ローカルマシンの負荷状況に影響を受けにくい
リモートのマシンスペックがいい

などです。この辺については以下の記事に記載がありますので、興味があれば参照してみてください。

メルカリShops の技術スタック、その後 | メルカリエンジニアリング

コードの変更はすべてプルリクエストを作成してコードレビューを行っています。ソウゾウのコードレビューではなるべく本質部分のレビューに集中して、細かい部分は実装者に任せるという文化があります。実際、社内の Notion にはCode Review Guidelineというページがあって、レビューを依頼する側と依頼される側、双方に期待することが記載されています。チラ見せすると以下のような感じです。

実際にはこの下にRecommended Expectations、Out of Expectationsと続きます。

もちろん、ここに記載されているExpectations以外のレビューを禁止するものではないので、基本的には気軽にコメントするようにしてますし、そうあるべきだと考えています。個人的には以下のように考えてコードレビューを行っています。

修正すべき点、確認すべき疑問点がある場合はコメントを書いてSubmitする。この時は他の細かいコメントはノイズになるので控える
上記が解決済みの場合、自分の意見や細かい指摘があればコメントを書いてApproveする。細かい部分は実装者に任せる

実装した内容を動かして確認するための環境としてはPull Request環境というものがあり、プルリクエストにラベルを付けることで簡単に作成することができます。以下の記事に詳しく解説されているので、興味があれば読んでみてください。

メルカリShops の CI/CD と Pull Request 環境 | メルカリエンジニアリング

さいごに

本記事では、メルカリShopsにおいて、ソフトウェアエンジニアがどのように開発を進めているかを紹介しました。

メルカリShopsは2021年7月にプレオープンしました。当時を振り返るとメンバーそれぞれが怒涛の勢いで開発をしていましたが、半年経ってチーム開発としての形が整ってきたように感じます。開発の進め方はその時の状況や学びによって少しずつアップデートされていくものだと思うので、この先も変化していくのだろうと予想しています。

ソウゾウではメンバーを大募集中です。メルカリShopsの開発やソウゾウに興味を持った方がいればぜひご応募お待ちしています。詳しくは以下のページをご覧ください。