Merpay Tech Fest 2021は、事業との関わりから技術への興味を深め、プロダクトやサービスを支えるエンジニアリングを知れるお祭りで、2021年7月26日（月）からの5日間、開催しました。セッションでは、事業を支える組織・技術・課題などへの試行錯誤やアプローチを紹介していきました。
この記事は、「Merpay Tech Fest 2021 Product Ownerとしての開発の進め方」の書き起こしです。
森脇聖太氏：皆さん、こんにちは。それでは「Merpay Tech Fest 2021 Product Ownerとしての開発の進め方」のプレゼンテーションを進めていきたいと思います。発表者は、株式会社メルペイでAndroidエンジニアをしています、森脇聖太と申します。
では、軽く自己紹介ですが、改めまして株式会社メルペイでAndroidエンジニアをしています、森脇聖太と申します。経歴としては、ウェブフロントエンドや、iOSアプリ開発を経て2012年頃、ちょうどAndroid4.4が出るか出ないかぐらいの頃からAndroidアプリの開発を始めています。前職はヤフー株式会社で、おもに「Yahoo！JAPAN」トップアプリの開発や、PayPayの決済サービス立ち上げを経験しました。2020年に株式会社メルペイに入社して、そこからいくつかの機能開発を担当させていただいたのですが、現在は、おもにメルペイスマート払いのTech Leadとして機能開発を担当しています。
はじめに、今回お話しする内容を軽く説明させていただきます。今日お話しする内容は、メルペイスマート払いの機能開発において、Androidチームがどのように開発を進めているかを話させていただきます。Androidの技術的な話ではなく、どちらかというとチームマネジメントのような話になるかと思います。
まず、メルペイスマート払いとは何なのか？ということを軽くご説明させていただきます。メルペイスマート払いとは、今月の購入代金を翌月にまとめて精算できるサービスです。メルカリでのお買い物や、メルカリ以外のウェブサービスのネットでのお買い物とか、コンビニなどメルペイが使える全国のお店での支払いにご利用いただけます。また、通常は翌月に一括でご精算いただいているのですが、任意で購入代金の精算を月々に分けることができる定額払いもご利用いただけます。
こちらのメルペイスマート払いを、普段どういうふうに開発しているのかということについてご説明させていただきます。
役職の構成としては、PMとデザイナー、エンジニア、QA、おもにこの4つの役職の構成になっています。エンジニアは、バックエンドエンジニアとクライアントのiOS、Androidエンジニアというふうに分かれているという感じです。普段の開発は、2週間のsprint開発で行っていて、課題管理にはJiraを利用しています。また、複数の施策を同時並行で開発することが多くて、Androidは時期にもよるのですが、3名～5名の複数のエンジニアで開発することが多いです。
今回は、複数の施策を同時並行で開発するという点と、複数のエンジニアで開発するという点についてどういう課題があったのか、また、その課題をどういうふうに解決したのかというところをお話したいと思います。
まず、Androidチームがどういうふうな課題を抱えていたのかということをご説明させていただきます。まず、時期によって各エンジニアのタスク量にばらつきがあるという問題がありました。ある時期は一部のエンジニアの方だけが忙しいけれども、一部のエンジニアはそこまで忙しくないといったことだったり、それが逆転して違う時期だとまた違う人がすごく忙しくて、もう一方で別の人はそんなに忙しくないみたいな、そういうことがよく起きているかなという印象でした。次に、実装の担当者の知識が属人化しているということがあって、この部分の施策を進めようとなったときに、ここはこの人にお願いしよう、この人が詳しいのでここをお願いしようと。その結果、それによってタスクの偏りが生じて、先ほど話したようなタスク量にばらつきがあるという問題も起こっていました。あと、仕様の属人化、知識の属人化等によって仕様の認識違いが発生することがあって、ほかの人が実装している部分の仕様をほかのエンジニアが把握してないということがよく起こっていました。
これがなぜ起こっていたのかというと、そもそも1つのチケットの粒度が大きすぎるという問題であったり、その大きすぎるチケットに対して1～2名のエンジニアの担当者をアサインするというような体制になっていたこと。また、全体の仕様と各チケットの内容をチーム内で共有するという文化が不十分だった点があったのかなと思っています。
これらを解決するために何をやったのかというと、Tech Leadとして技術的な選択をリードするのに加えて、Product Ownerが持つ成果物への責任というか振る舞いの一部も取り込んでいって今回はアプローチをしました。実際に取り組んだ内容は3つで、チケットを細かく分割すること、分割したチケットをエンジニア全員にレビューすること、分割したチケットをチームで分担して実装することをやりました。
まず、チケットを細かく分割するということですが、1つの施策に対して1つの開発チケット、仕様の概要がチケットに箇条書き、詳細な仕様は別ドキュメントにまとめられているという状況だったものを、こちらのように1つの施策に対して複数の開発チケット、1つのチケットがアプリの1つの振る舞いを表して、詳細な仕様は別ドキュメントにまとめられているというような状態にしました。
例えば、メルペイスマート払いの履歴詳細画面をつくる場合だと、取引内容のアイコンとタイトルが表示される、取引内容の詳細が表示される、定額払いの設定へ進むボタンが表示される、定額払いの設定へ進むボタンを押すと次の画面に遷移するというようなチケットを作成して開発を進めていきました。
次は、Sprint Planningのあとに分割したチケットの内容をエンジニア全員でレビューする時間を設けました。ここで仕様の理解をエンジニア全員が深めつつ、もし仕様漏れだったり、チケットの過不足があればそこで確認をしたり、加えて、もし分割したチケットの粒度が大きすぎる場合には、さらにそこでチケットを分割したりということをやりました。
最後に、分割したチケットをチーム全員で分担して実装するということを進めていました。はじめに話したような、施策単位でエンジニアが1人ついて担当するという感じではなくて、細かく切ったチケット単位で実装担当者を決めて進めるというような内容でやっていきました。チケットの内容はレビュー会で全員が把握しているので、誰でも対応ができるという状態を目指していました。また、進捗などの状況を見て柔軟にリソースの配分も調整することができるのと、僕が理想としていたのは、休みたいときに休めるという状況がとても理想だなと思っていたのでこのように進めていました。
実際やってみてどうだったかというと、QAで発生するバグの発生率が低下して、ほかのチームと比べても高い水準を維持していたかなと思っています。追加でタスクが発生したときも柔軟に対応しやすくなったというのと、エンジニアからも開発しやすくなったという声をいただいています。また、最初はAndroidチームだけで始めた内容だったのですが、今はiOSチームだったり、ほかのチームでも徐々に広まってきています。
今回話した内容は、既存の組織構造を大きく変えることなく小さい範囲からスモールスタートで進めることができる内容なので、もし普段の開発で課題を感じられている方がいれば、ぜひ取り組んでいってほしいです。
短いですが、以上になります。ご清聴ありがとうございました。
