「10年超えRails開発の振り返りと未来-持続可能な開発の具体策」感想
８/1に開催された、10年超えRails開発の振り返りと未来 - 持続可能な開発の具体策という技術イベントに参加しました。
登壇されたのはnote、食べログ、マネーフォワード、STORESという有名サービスの開発に深く携わる方々で、LTとトークセッションをしてくださいました。
10年以上にわたる開発の中で見えてきた貴重なお話を聞くことができましたので、感想を書いてみます。
※LTタイトルごとに見出しを振ってますが、トークセッションで言及された内容も少し含んでいます。
noteの10年もののメディア機能統一計画
noteは「B=MAT（行動=動機×実行能力×きっかけ）」の考え方に則り、ユーザー行動を誘引する施策をエンジニア自身が多く行ってきたそうです。
そのおかげでnoteは人気サービスになったわけですが、プロダクト開発をどんどん進めていった結果、現在は「プロダクト上の課題の多さ」（実装の複雑さ的な意味だと思います）に問題がシフトしてきているとのことでした。
特に、カテゴリページ、特殊ページ、ホーム画面など、通常の記事ページとは異なる「コンテンツが主なページ」とその基盤も増えてきたものの、10年の間に基盤が乱立され、かつ一部のページは手動運用前提となっていて更新にデプロイが必要となるなどの辛さがあるようです。
こうした点の改善のため、noteでは「MediaKit」というフレームワークを開発し、note内の既存コンテンツをnote内外に提供しやすくする仕組みを実現したそうです。結果、管理画面からの操作だけでノーデプロイでページを更新できるようになったとのことでした。
発表内ではMediaKitの詳細な説明がありました。Query, Exrtractor, Section, Layoutという４階層から構成されていて、既存コンテンツの取得から画面上のレイアウトまでサーバーサイドで生成できるという仕組みのようで、この階層分けが綺麗で参考になりそうと感じました！
食べログのモジュラモノリス化戦略
食べログは従来マイクロサービス化を進めていましたが、2019年を境にシステムの分割はあくまで手段に過ぎないと再認識し、いまは現状課題の可視化や分析を行い、PoCとPDCAを繰り返すというスタイルに切り替えているというお話でした。
失敗談として、かつてレストランや口コミといった主要機能を切り出そうと試みたものの、依存関係が複雑だったり、主要機能全てのトラフィックをさばけるインフラを用意することができず、結果として同一ドメインの機能が異なるシステムに分かれ、せっかく分離したのに同時デプロイが必要になったり、共有DBのメンテナンスが煩雑なるなどの問題が発生してしまったそうです。辛い・・・。
こうした反省を生かし、現在はまず変更容易性と変更安全性を高めた上で、モノリスのレポジトリを小さく速く改善するという取り組みをしており、マイクロサービス化については現在保留しているとこのことでした。
具体的には、それまでビジネスロジックがDBや外部APIに直接依存していたのを分離したり、ドメイン境界の明確化、コアドメイン→非コアドメイン方向の依存の排除などを行っているそうです。
また、過渡期が辛いだけの開発だと開発チームに受け入れられず成功しづらいので、早期に大きなアウトカムを享受できるよう、インパクトが大きく横断的な課題を最初に解決してから、コアドメインのモジュラモノリス化を進めるという戦略をとったそうです。
複雑なものが整理されていく流れをわかりやすく説明していただけてとても参考になりました！意思決定のプロトコルみたいなところまで見せていただけたのもありがたかったです！
システムを脳に収める技術(公開版)
「自分たちのシステムがどうなっているか？」という問いに対して、パッと浮かぶイメージがあって、それがみんなで共有されている必要があって、そのためにはいい感じの図が必要だというお話でした。
マネーフォワードという巨大なアプリケーションの開発生産性向上に取り組む際、どこから手をつけるべきか検討するため過去資料を調査したものの、細かすぎたりプロダクト寄りすぎたりと、ちょうどいい図がなかったそうです。とてもよくわかる話です・・・・。
そこで「時間のない上司」や「昨日入社したメンバー」などにも伝わるような図をイメージして新たな資料を作成されたそうです。この時、一枚の図だけではなく、そのコンテキストを説明したり補足する文章が必ず必要で、さらにC4 modelのように複数の詳細レベルの図を用意することが重要ということでした。
個人的には4つのLTの中でこのお話が一番共感できる内容でした！やっぱりWEBアプリ開発にはいい感じの図が必要なんだ・・・！
継続的にRailsアプリを開発する上で早めにやっておきたいこと
STORESの開発で色々な穴に落ちてきた反省から、どんなRailsアプリにも共通するであろう、「早めにやっておくと複利で効いてくること５選」として、以下を挙げられていました。
- 継続的bundle update
- 継続的RuboCopメンテ
- seed整備
- コードカバレッジのレポート整備
- DHHルーティング
どれも納得感がありつつ、つい後回しにされがちなものばかりと感じます。STORESではCIフローの中に組み込むなどしてできるだけ自動化しているようです。
また、DHHルーティングの効用として「REST APIにおけるリソースについて意識を向けられ、より良い設計を促すきっかけになる」とされてて、ほんとにそう！と思いました。
全体を通して
現実のサービス、しかも有名なサービスの開発の中で見えてきた、とても貴重なお話を聞くことができました！
また、やはり持続可能な開発に銀の弾丸はなく、都度課題とその解決方法を見出していくしかないんだなと感じました。
Discussion