Retty Tech Blog

実名口コミグルメサービスRettyのエンジニアによるTech Blogです。プロダクト開発にまつわるナレッジをアウトプットして、世の中がHappyになっていくようなコンテンツを発信します。

大人数で一斉に実装したら開発期間は短くできるのか?

この記事は Retty Part1 Advent Calendar 2021 の 23 日目の記事です。

adventar.org

こんにちは、ウルトラマンが大好きな3歳児に光線の打つ動作をレクチャーされている鈴木です。 Web開発チームでバックエンドエンジニアをしております。
今年の8月にリニューアルしたRettyのユーザー詳細ページの開発過程の取り組みについて学びを共有します。

ユーザー詳細ページとは?

Rettyアプリのユーザーさんの詳しい情報が書かれているページ(ex:https://user.retty.me/1/)です。Before→Afterでだいぶ変わりました!

f:id:rettydev:20211222173519p:plain Before f:id:rettydev:20211223110035j:plain After

ある程度の口コミ投稿数があれば、自分の食事の傾向がわかるアイコン「好きラベル」がつきます!とっても可愛いデザインなので是非オススメのお店の口コミを投稿してみてください(^^)

なぜリニューアルしたの?

  • ユーザー詳細ページはモノリスで昔々に作られた歴史のあるページで、トンマナもページコンポーネントも現在のものと合っていない。
  • どんな人がおすすめしているのか一目で分かりやすくするために好きラベルを含む情報設計の見直しを行うことにした。
  • ロジックも歴史が積もり積もって読みづらく、新たな施策をする際にコードリーディング/背景理解などに時間がかかってしまうため、マイクロサービス版のRettyで作り直そうという方針となった。

※マイクロサービスへの移行・システム構成に関してはこちら

作り直すにあたっての課題

マイクロサービスで作り直すことは開発側の要望であり、企画・ビジネスの要望に応えるには多くのエンジニアを巻き込み、短期集中で一気に開発を進めたいという事情がありました。

RettyにはUserHappyという行動規範があり、新たな価値をできる限り早く届けていき、ユーザーさんにHappyになってもらえるように動く為に、できる限りリリースまでの時間を短縮していく必要があります。 もともとマイクロサービスへの移行は少数精鋭で進めていましたが、人数を増やす事で時間を短縮できないか。また、どの程度短縮可能なのかという点を見極めるにも、今回のリニューアルは大人数で取り組むことにしました。

大人数のメリット・デメリット

メリット

単純に開発人数が増えれば着手できる箇所が増えるので上手く行けば時間短縮につながる。

デメリット

大人数にすることによって、認識の相違や手戻りは発生しがちなので工夫が必要。

開発体制

  • エンジニア:17名(LeSSの体制で、3チームの合計人数)
  • プランナー
  • デザイナー

開発の結果

当初の予定では1ヶ月半を見込んでいましたが、1ヶ月半でリニューアルできた&インシデントなし✨を達成することができました。 とはいえ、開発過程では課題もあり、実装の流れや進め方など工夫して進める必要がありました。

実装の流れ・検証

実装

以下の実装順で進めていきました。

f:id:rettydev:20211223210903p:plain
この中でProtocol Buffersのスキーマ定義(≒gRPCのスキーマ定義、以降protoと表記)を一番初めにしているのですが、データ構造をエンジニア間で目線を揃えることを目的としています。 合わせてフロントエンドでのデータ構造と合うよう並行してGraphQLのスキーマも議論しました。
proto/GraphQLのスキーマが決まっていないと手戻りが発生し、コミュニケーションの増加+実装コストの増加が起こり得ます。 スキーマを先に決める事で、認識を早期に合わせ、リリースまでの速度アップにつながったと思います。

検証

全ての機能が出来てからプランナー含めて検証してもらうのではなく、出来た機能から検証してもらい、メンバーの半数は検証で判明したバグなどの対応・もう半数は残りの機能の実装を進めていました。

苦労したこと

リリースまですんなりいったわけではなく、問題も発生しました。

問題
各所進められてはいたものの、どのサービスがどこまでできていていつ終わるのかが連携取れず何を繋ぎ込めるのか、どの機能が終わっているのかが分からなくなってしまい、スムーズに動けずスピードを上げづらい状態に。

対応
各チームでバックログから優先順位の高いものを取って進めるうちに全体像が見えなくなっていた事が原因だった為、旗振り役を立てて定期的な状況の整理を行うようにしていきました。

  • ブロッキングがある中で進められるものの共有と現状の整理と認識のすり合わせ

    f:id:rettydev:20211223121859p:plain

  • バックエンドとフロントエンドで繋ぎ込みができる場所などを図と文章で共有

    f:id:rettydev:20211223170033p:plainf:id:rettydev:20211223110035j:plain

この開発で得られた成果

この開発を通して、モノリスから移行していくにあたり、この規模と人数であれば1~2ヶ月以内にリリースできるという実績ができました。 今まではマイクロサービスへの移行をしていくのにコスト面でどれくらいかかるのかが不明瞭だった為、移行の施策を行うスピード自体が出しにくかったのですが、ビジネスとエンジニアリング間で企画を通しやすくなりました。

この開発での学び

  • 先にgRPCやGraphQLのスキーマを決定することで、整合性を保ちつつ最低限のコミュニケーションで進められるのはとても良い流れだった。
  • この規模の実装の場合は全体の動き/認識のすり合わせを行う旗振り役を最初に立てていく事で全体像を共有しながらよりスムーズに進められそう。

終わりに

人数が多ければ早く出せるのか?というチャレンジをして行った今回のリニューアル。思えば怒涛のように日が過ぎていき、反省点もたくさんあるものでした。今回開発の流れメインの内容になりましたが、一人一人が実装だけに集中するのではなく、「この方がUserHappyなのでは?」といった視点で実装していたのが、Rettyらしいなぁ〜ととても嬉しく思っていました。 今後も「人から探すオススメのお店」というところがより分かりやすくなるように、どんどん開発をしながら、2022年も食を楽しんでいきたいと思います!!!

f:id:rettydev:20211222164018p:plain