Upgrade to Pro — share decks privately, control downloads, hide ads and more …

マネーフォワードの Rails プロダクト群を支え、 同時にくっついてなかなか離してくれない共...

マネーフォワードの Rails プロダクト群を支え、 同時にくっついてなかなか離してくれない共有リソースとの向き合い方

- マネーフォワードを支える Rails プロダクト群のこれまで
- 共有リソースの課題
- 我々は共有リソースとどう向き合っているのか
- 有志での取り組み
- 専門チームでの取り組み
- 全社的な取り組み

についての資料です

Yusuke Furuhama

October 28, 2020
Tweet

Other Decks in Programming

Transcript

  1. 自己紹介 • GitHub: furuhama • 名前: 古濱 有佑(ふるはま ゆうすけ) •

    マネーフォワード ビジネスカンパニー クラウド横断本部 わり算グループ リーダー • マネーフォワードには新卒で入社して 3 年目 • 最近のプチ自慢: ISUCON 10 で Ruby を使ったチームで唯一本選に行きました • 最近の悲しいこと: ISUCON 10 本選で 最終結果が 0 点(失格)でした
  2. 所属組織についてもう少し • プロダクトの数が多い • ほとんどが Rails バックエンド • 誕生した時期は様々 •

    それゆえインフラ構成や共有リソース との関わり方も複数パターン存在す る (FY20 3Q 決算説明会資料より引用 )
  3. 今日話すこと • マネーフォワードを支える Rails プロダクト群のこれまで • 共有リソースの課題 • 我々は共有リソースとどう向き合っているのか ◦

    有志での取り組み ◦ 専門チームでの取り組み ◦ 全社的な取り組み • 補足: 目指したい世界のその先に見えている課題 (時間があれば)
  4. マネーフォワードを支える Rails プロダクト群のこれまで • ざっくり以下の流れで会社のプロダクトが増えていった ◦ 家計簿プロダクトができる ◦ 個人の確定申告ニーズに応えるために確定申告プロダクトができる ◦

    小規模法人向けの会計機能が確定申告プロダクトを拡張する形で追加される ◦ そこから toB のバックオフィス領域向けにいくつかプロダクトができていく
  5. マネーフォワードを支える Rails プロダクト群のこれまで • 大きく 2 つのリソースを共有している ◦ ライブラリ ◦

    DB • 共有度合いによって大きく 3 つのパターン ◦ どちらも共有(パターン①) ◦ DB の一部とライブラリのみ分離 (パター ン②) ◦ どちらも分離(パターン③)
  6. マネーフォワードを支える Rails プロダクト群のこれまで • パターン①がメインの時期があった • 以下のメリット ◦ 共有のライブラリがプロダクト提供のた めの汎用的な機能を吸収してくれてい

    る ◦ 共有の DB によってトランザクションや JOIN が利用可能 ◦ ActiveRecord の強みを活かしやすい • シリーズとして関連し合うプロダクトの開発に おいて 0->1 や 1->10 がスムーズに
  7. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • 有志での活動だとどうしても優先度が上がりきらないという問題があり、共有リソース分割のための専 門チームを組成 • それがわり算グループ • ライブラリと DB の解体を主眼に置いている

    • 例えば以下のようなことをやってきた ◦ ライフサイクルとコールバックを考えてモデルを持ち帰る ◦ まず更新を特定のプロダクトに集約してライブラリでは参照専用モデルにする ◦ ライブラリが提供する機能のオプショナル化 ◦ ライブラリアップデートの自治活動
  8. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • ライフサイクルとコールバックを考えてモデルを持ち 帰る ◦ create, update, delete それぞれのタイミング と実行されるコールバックを整理

    ◦ read をどのプロダクトで行っているのかを整 理 ◦ 実は create, update, delete のタイミングを read に間に合うようにずらして特定のプロダ クトに集約できるケースがあった (整理によっ て見えてきた)
  9. 我々は共有リソースとどう向き合っているのか(専門チームでの取り組み編) • ライブラリアップデートの自治活動 ◦ 共有ライブラリは gem の形式で提供している ◦ どうしてもプロダクト側でのアップデートが疎かに ◦

    その他にも主要ライブラリの脆弱性対応の進捗管理な どもしたかった ◦ バージョン一覧をさっと取れるようなコードを書いてみん なのお尻を叩いている
  10. 我々は共有リソースとどう向き合っているのか(全社での取り組み編) • ライブラリの機能や DB のテーブルの役割を 分解していくと、どうしてもプロダクト間で共有 したい箇所が出てくる ◦ 基盤サービスとして切り出して API

    の通 信経由での機能利用をする形に置き換 え ◦ 利用側の置き換えはすべてのプロダクト で行う必要がある ◦ Ruby の client であれば gem として実装 を提供 ◦ 全社的な取り組みとして推進
  11. 我々は共有リソースとどう向き合っているのか(全社での取り組み編) • 基盤サービスにはそれぞれ専門のチームがついて開発 /運用を行っている • 例えば以下のようなサービスをはじめ現在では 20 を越えるサービスができはじめている ◦ ユーザー管理/認証部分を担うサービス

    ◦ toB 向けの事業者管理を担うサービス ◦ ユーザーの金融機関情報の参照や更新を担うサービス ◦ toC/toB 向け課金を担うサービス ◦ メール配信を担うサービス ◦ PDF 生成を担うサービス ◦ etc • これらだけでなく特定のプロダクト内での機能を切り出したサービスもできはじめている (今回は省 略)
  12. 目指す世界とユーザーへの価値提供 • 紹介してきた取り組みがすべて結実してようやくこ の状態になれるか...???というところ ◦ とはいえあと 1 年くらいでだいぶ近づくので はと思っている •

    会社としてこういった内部的な改善ばかりやって いればいいわけではない ◦ ビジネス要件を折り込み、走りながら直して いるような状態
  13. 目指したい世界のその先に見えている課題 • まだまだ課題はある ◦ 通信によるデータの更新・参照がメインとなった世界での ▪ 整合性の担保 ▪ 最適なメッセージングの方法の模索 ◦

    プロダクト間のインフラ構成の差異を減らす ▪ プロダクトの誕生時期によって構成が異なり運用コストが増加 ◦ インフラ運用をプロダクト横断のチームが行っている ▪ プロダクト開発チームに運用を委譲しないとインフラ運用チームがボトルネックに ▪ そもそもスモールチームでのスムーズな開発には開発・運用のサイクルがチームで閉じて いることが不可欠 • 最終的には一貫して開発運用を行える、リソースを共有せず疎に繋がった自律的なチームの集合とし て会社が存在するような状態になるといいのかな、と個人的に考えている