1 10歳のminneから、これから長く続く プロダクトを作るすべての人へ tsumichan(市岡 なつみ) / GMO PEPABO inc. 2022.07.26 iCARE Dev Meetup #34

GMOペパボ株式会社 minne事業部 2 自己紹介 市岡 なつみ tsumichan ● 2018年4月 新卒入社 ● minne の バックエンド開発を担当しています ● 寝ること、もふもふしたもの、お寿司🍣が好き ● ねこを飼うのが夢 ● マイブームはオクラです ● Twitter : @tsummichan

minneは2022年1月に10周年を迎えました🎉 minneは、ハンドメイド作品を「買いたい人」と「売りたい 人」をつなぐハンドメイドマーケットです。 2012年1月よりサービス開始し、 2022年1月17日に10周年を迎えました。 これからも「ものづくりの総合プラットフォーム」として、 多くの方がものづくりを通して表現できる場となれるよ う、成長していきます！🚀 画像：https://minne.com/feature/anniversary/10th 3 minne 10周年！

4 アジェンダ 1. 10年経ってつらいところ 2. 10年経ってよいところ 3. これから長く続くプロダクトを作るすべての人へ • minne が10年で感じ、学んだことを3つご紹介します

5 10年経ってつらいところ

6 • ユーザー、作品、注文などいろいろなデータがある • 83万人の作家・ブランド（出品者）がそれぞれ作品を作成、公開しているので作品数がすごくたくさん ある • 複数の作家・ブランドの作品を一度で決済できるが、注文レコードは作家・ブランドに紐づく • つまり1回の決済で作家A、作家B、作家Cから購入できるので、注文レコードは3件できる • フォロー、お気に入りは無制限にできる • SNSっぽく使うユーザーがいて、数万件のお気に入りを持つユーザーもいる 1. シンプルにデータ量が増えて大変になった 10年経ってつらいところ

7 • 最近つらいのは検索サーバーへの同期と退会処理 • 検索サーバー(Elasticsearch)への作品情報を reindex するとタイムアウトするので、根気よくリトラ イしている • サーバーのスペックを上げたり並列度を上げるなどして対策する予定 • 退会時にユーザーに紐づくお気に入りレコードを削除するが、お気に入りが多いとタイムアウトしてし まうのでユーザー体験に影響が出ている • お気に入りは user に対し has_many で紐付いていて、 dependent: delete_all が設定されている • お気に入り以外にもいろいろ削除しているが、必要最低限のもの以外は非同期処理化していく予定 1. シンプルにデータ量が増えて大変になった 10年経ってつらいところ

8 2. 意図がわからない設計や命名がある 10年経ってつらいところ • 「このカラム消したいなあ…なんのために作ったんだっけ？」 「これなんでこういう仕組みになってるの？」→作られた当時にいた人が退職していて誰もわからない… • pull request やコミットメッセージに ”なぜそうしたのか”が書かれていない • GitHub から GitHub Enterprise へ移行した時に昔の issue, PR の画像などが一部消滅した • pull request やコミットメッセージに Why を書くようにチームで取り組み中 • 改修途中で力尽きたものがある • デザインの刷新時に、ユーザーの管理ページが /user にあったが新しく /account に作り、徐々に /account の方へ移行する予定だった • 一部機能はまだ /user に取り残されていて、 controller なども user と account の2つが存在して いる

9 2. 意図がわからない設計や命名がある 10年経ってつらいところ • プロダクトビジョンが変わったが、内部の設計や命名はそのままになっている • 昔はハンドメイド作品を売買するプラットフォームではなく、ハンドメイド作品を展示するサービスだっ た • minne の作家のトップページは昔「ギャラリー」と呼ばれていたが今は「ショップ」になった • ユーザーに見えるオモテ部分はアップデートされていても、ソースコード（クラス名など）はまだそのままになって いる

10 3. 保守コストが高い 10年経ってつらいところ • 機能の数が多すぎて保守やメンテナンスの手が回らない • あまり使われてない機能も消さずに残されている • 利用率とメンテナンスコストを天秤にかけて、コストのほうが重ければ消していきたい • 統一されていないアーキテクチャ・設計がある • これについては何もできていません … 😥アドバイスお待ちしています • deprecated なものが存在している • Ruby, Rails のバージョンアップに伴って deprecated になったメソッドや記法とか • Controller Spec, CoffeeScript とか • Rubocop を導入し、ボーイスカウトルールでできる範囲から徐々に書き換えているところ

11 10年経ってよいところ

12 1. 古すぎてどうしようもないみたいなライブラリなどは少ない※ • ※全く無いとは言っていない • ただただ先人たちがしっかりアップデートしたり保守を頑張ってくれたおかげ • 長い間メンテナンスされていない gem を使っていたりはするので、いつ動かなくなるかわからないと いう危険性はあり、それをどうするのかはこれからの課題 • アップデートを後回しにして溜めてはいけない（戒め） 10年経ってよいところ

13 2. マイクロサービス化により改修やリリースによるデグレが少ない • 今は認証サービスとフロントエンドの一部がマイクロサービス化されている • 開発やリリースも同時進行できるので、どちらかの作業待ちが発生しなくなり、効率的に開発を進められ るようにもなった • これも先人のおかげ（感謝しかありません） • 今は各サービスごとにチームがあるわけではなく、1つのチームが複数のサービスを見ているので把握が 大変という声もある • これは組織や体制の話でもある 10年経ってよいところ

14 3. 規模の大きいサービスの開発ならではの経験が得られる • 新しい機能を作る時に、常にパフォーマンスや負荷を考えた設計をしないといけない • 急いでるからとりあえず動けばいい、は通用しない • 今は操作するデータ量が少ない機能でも、将来データ量が増えたときのことを考えて設計する癖がつく • パフォーマンスチューニングもやるべきところがたくさんあってよい経験になる 10年経ってよいところ

15 これから長く続くサービスを作る すべての人へ

16 拡張性を考えた開発をするのは大切 • 今は2種類のパラメータでも、今後3種類、4種類…と増えていくかもしれない • 先を見通した設計をすることで将来つらくならない！ • 作るその時点での要件だけがすべてではなく、その機能をどう使われてほしいのかや今後どう発展させ ていきたいのかをプロダクトオーナーと相談しながら設計したほうが先を見通した設計にできる これから長く続くサービスを作るすべての人へ

17 データ量が増えることは本質的にはつらいことではない • プロダクトが成長したり長く続くと必ずデータ量が増える • DBサーバーのスペックを上げる、将来データが増えても耐えうる設計にする、などデータ量が増えるた びにそれに対応していればあまりつらくならない（はず） • minneではユーザーや注文のレコードがたくさんあるが、その注文の売上によって生活が豊かになった 人がたくさんいるということであり、世の中に影響を与えた証、影響を与えた量でもある これから長く続くサービスを作るすべての人へ

18 プロダクトを作り直したり仕組みを変えたりしないといけなくなる日が必ず来る • プロダクトが大きくなると、その状態に合った仕組みにしないといけない • 今はイケてない作りでも、作った当時はそれが最良のやり方であったはずなので、「これイケてなさすぎ るだろ、誰が作ったんだよーw」とか言えない、言っちゃいけない… • 将来のためにも私達も常に最良のやり方で作ろう • minne では、過去に仕組みを変えることでユーザー体験を改善ができる機会があったけど、他にやるこ とがあってそこにコストをかけられず、妥協してしまったことがある • 「しっかり対応していればもっとユーザーが使いやすくできたかも」 • 規模が大きくなるほど仕組み変えるのが大変になるので、サービスの規模がそこまで大きくなくて、 作り変えるのを迷ってるひとがいたらやったほうがいい！！！ これから長く続くサービスを作るすべての人へ

19 さいごに

20 レガシーなプロダクトが良くないとか 新しい技術を使っているからえらい/すごいというより、 より売上を生み出してユーザーに価値を届けることのほうが プロダクトとしては重要なので、 長く価値を届け続けられるプロダクトを作っていきましょう さいごに