10歳の minne から、これから長く続くプロダクトを作るすべての人へ

Transcript

1. • minne の バックエンド開発を担当しています • 寝ること、もふもふしたもの、お寿司🍣が好き • ねこを飼うのが夢 • マイブームはオクラです • Twitter : @tsummichan

GMOペパボ株式会社 minne事業部 2 自己紹介 市岡 なつみ tsumichan • 2018年4月 新卒入社

2. minne 10周年！

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

3. が10年で感じ、学んだことを3つご紹介します

4 アジェンダ 1. 10年経ってつらいところ 2. 10年経ってよいところ 3. これから長く続くプロダクトを作るすべての人へ • minne

4. • 退会時にユーザーに紐づくお気に入りレコードを削除するが、お気に入りが多いとタイムアウトしてし まうのでユーザー体験に影響が出ている • お気に入りは user に対し has_many で紐付いていて、 dependent: delete_all が設定されている • お気に入り以外にもいろいろ削除しているが、必要最低限のもの以外は非同期処理化していく予定 1. シンプルにデータ量が増えて大変になった 10年経ってつらいところ

7 • 最近つらいのは検索サーバーへの同期と退会処理 • 検索サーバー(Elasticsearch)への作品情報を reindex するとタイムアウトするので、根気よくリトラ イしている • サーバーのスペックを上げたり並列度を上げるなどして対策する予定

5. やコミットメッセージに ”なぜそうしたのか”が書かれていない • GitHub から GitHub Enterprise へ移行した時に昔の issue, PR の画像などが一部消滅した • pull request やコミットメッセージに Why を書くようにチームで取り組み中 • 改修途中で力尽きたものがある • デザインの刷新時に、ユーザーの管理ページが /user にあったが新しく /account に作り、徐々に /account の方へ移行する予定だった • 一部機能はまだ /user に取り残されていて、 controller なども user と account の2つが存在して いる

8 2. 意図がわからない設計や命名がある 10年経ってつらいところ • 「このカラム消したいなあ…なんのために作ったんだっけ？」 「これなんでこういう仕組みになってるの？」→作られた当時にいた人が退職していて誰もわからない… • pull request

6. minne の作家のトップページは昔「ギャラリー」と呼ばれていたが今は「ショップ」になった • ユーザーに見えるオモテ部分はアップデートされていても、ソースコード（クラス名など）はまだそのままになって いる

9 2. 意図がわからない設計や命名がある 10年経ってつらいところ • プロダクトビジョンが変わったが、内部の設計や命名はそのままになっている • 昔はハンドメイド作品を売買するプラットフォームではなく、ハンドメイド作品を展示するサービスだっ た •

7. • 統一されていないアーキテクチャ・設計がある • これについては何もできていません … 😥アドバイスお待ちしています • deprecated なものが存在している • Ruby, Rails のバージョンアップに伴って deprecated になったメソッドや記法とか • Controller Spec, CoffeeScript とか • Rubocop を導入し、ボーイスカウトルールでできる範囲から徐々に書き換えているところ

10 3. 保守コストが高い 10年経ってつらいところ • 機能の数が多すぎて保守やメンテナンスの手が回らない • あまり使われてない機能も消さずに残されている • 利用率とメンテナンスコストを天秤にかけて、コストのほうが重ければ消していきたい

8. を使っていたりはするので、いつ動かなくなるかわからないと いう危険性はあり、それをどうするのかはこれからの課題 • アップデートを後回しにして溜めてはいけない（戒め） 10年経ってよいところ

12 1. 古すぎてどうしようもないみたいなライブラリなどは少ない※ • ※全く無いとは言っていない • ただただ先人たちがしっかりアップデートしたり保守を頑張ってくれたおかげ • 長い間メンテナンスされていない gem

9. • 今は各サービスごとにチームがあるわけではなく、1つのチームが複数のサービスを見ているので把握が 大変という声もある • これは組織や体制の話でもある 10年経ってよいところ

13 2. マイクロサービス化により改修やリリースによるデグレが少ない • 今は認証サービスとフロントエンドの一部がマイクロサービス化されている • 開発やリリースも同時進行できるので、どちらかの作業待ちが発生しなくなり、効率的に開発を進められ るようにもなった • これも先人のおかげ（感謝しかありません）

10. パフォーマンスチューニングもやるべきところがたくさんあってよい経験になる 10年経ってよいところ

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

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

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

12. minne では、過去に仕組みを変えることでユーザー体験を改善ができる機会があったけど、他にやるこ とがあってそこにコストをかけられず、妥協してしまったことがある • 「しっかり対応していればもっとユーザーが使いやすくできたかも」 • 規模が大きくなるほど仕組み変えるのが大変になるので、サービスの規模がそこまで大きくなくて、 作り変えるのを迷ってるひとがいたらやったほうがいい！！！ これから長く続くサービスを作るすべての人へ

18 プロダクトを作り直したり仕組みを変えたりしないといけなくなる日が必ず来る • プロダクトが大きくなると、その状態に合った仕組みにしないといけない • 今はイケてない作りでも、作った当時はそれが最良のやり方であったはずなので、「これイケてなさすぎ るだろ、誰が作ったんだよーw」とか言えない、言っちゃいけない… • 将来のためにも私達も常に最良のやり方で作ろう •