マネーフォワードのエンジニアリング進化論
- Shota Kurodaさん/VPoE
マネーフォワード
- 2012年設立
- 2400人
- エンジニアは4割
- 60以上のプロダクト
- エンジニアの40%異常が外国籍
エンジニアリングの進化の歴史
- スタートアップ期
- 充電期
- 拡大期
- 中小から中堅向けのサービス進出
- 個々のプロダクトの拡大
- エンジニアのグローバル採用開始
- 大規模プロダクトのマイクロサービス化
- 爆発的にプロダクト数がのびた
- 再編期
2ヶ月かかるDBアップグレード検証を最大2週間に短縮した自作Go製CLIツール「Platinum」を紹介する
- VTRyo(Inaba Ryo)さん/SRE
Dbエンジンの変更
- DBエンジンの変更
- pt-upgradeでチェックしてる
- 異なる2バージョンの互換性をチェックしレポートを出す
- レポートを得るまでに2ヶ月かかった
- ハードル
- 社内制約
- 本番環境のデータをprodのAWSの外に出してはいけない
- prodに検証環境を作らないといけない
- 準備の手間
- general.logの準備
- 実行中の手間
- 実行してほしくないクエリを地道に除外
- 社内制約
- 自前でツールを作った
横断組織として考える共通DBの課題解決 〜 桃園の誓いアーキテクチャ 〜
- 4geru(Koichi Uchinishi)さん/Backend Engineer
- https://speakerdeck.com/4geru/addressing-shared-database-challenges-as-cross-team-peach-garden-oath-architecture
桃園の誓いアーキテクチャ
- DBを共有しサービスが止まるときは皆一緒というアーキテクチャ
- 規模が小さい頃は効率的に開発できていた
- 規模が大きくなってSlowQueryで障害にもつながっていた
- 脱却
- 共通DBではなくサービスDBを使うように移行していく
- 特定テーブルを分離して別DBに分離させて段階的に
- 共通DBではなくサービスDBを使うように移行していく
Rubyにおける並行処理
- Edric(Pham Vuong Trieu)さん/Backend Engineer
Rubyで並行処理
- 並行処理ははやいけどコストがかかる
- CPU/メモリ
- 子プロセスを作っての実行は効率がよくない
- Paralleというgem
- Process/Thread/Fiber/Reactor
Money Forward UIの紹介
- Taiga Kiyokawaさん/Frontend Engineer
- https://speakerdeck.com/taigakiyokawa/introducing-money-forward-ui
Money Forward UI
- マネーフォーワードクラウド向けのUI
- 30を超えるプロダクト
- デザインから実装にかかる時間を短縮
- 見た目や振る舞いの差分を発生させない
- プロダクト間の連携が多いので大切
- 一貫性のあるアクセシブルなUI部品
- GitHubPackagesで4つのnpmパッケージを展開
- mfui-components
- nfui-icons
- mfui-design-tokens
- ドキュメンテーション
グローバルなソフトウェアテスト組織における課題と戦略
- Shun Tsunodaさん/QA Engineer
マネーフォーワードのQA
- 日本/ベトナム/インドにQAの組織
- 日本語のみの情報は共通情報とはできない
- テスト用語は難しいのものが多いからなおさら
- ISTQB
- ソフトウェアテストの国際認定
- 用語を定義してるページもある
- ISO/IEC/IEEE 29119
- ソフトウェアテストの標準
- 2021年の改訂版が最新
- スタンダードは抽象的なものが多い
- カスタマイズして取り入れていく必要がある
- テスト計画
- スケジュールだけじゃない
- 達成すべきテストの目標
- スコープ/リスクなど
- テストプロセス
- 計画/分析/設計/実装/実行/完了
- ユーザストーリー
- テスト条件
- 何をテストするのか
- 抽象的なレベルと具体的なレベル
- ツリー構造にできる
- 下位に行くほど具体的
- テストモデル
- モデルを作成してパラメータ設計などをする
- テストケース
通知基盤におけるKafka活用事例
- Ayumi Tamaiさん/Backend Engineer
通知基盤でのKafkaの利用
- マネーフォーワードクラウドシリーズそれぞれで通知がある
- 通知設定を個別に行うのはUX的にいまいち
- 通知基盤で一元管理
- Kafka
マネーフォワードにおけるデータ戦略
- Kazuhito Nomuraさん/CDAO
マネーフォーワードのデータ
- 膨大な重要データを持っている
- DataSource, DataLake, Analysis/Modeling, Application
- 一箇所にデータが集まってること
- 使いたい時に使えるように
- 生成AIの新しいサービスを柔軟に使えるように
- いろんなのがどんどん出てくるので
- 運用基盤が整ってること
- 本番で使う時にちゃんと動かせるように
- 学習可能なトランザクションデータの蓄積
- ログのフィードバックループ
MEet Flutter Add-to-App: Unlocking Our Productivity
- Ichiro Hirataさん/iOS App Engineer
Flutter
- Flutter
- アプリ開発の課題
- Flutter導入
Donut + SegFormer ~ Donut で位置を推定する
- mozz(MORI Masakazu)さん/ML Engineer
AI-OCP
Passkey Autofill に賭けるマネーフォワード ID
- nov(Nov Matake)さん/Backend Engineer
パスキー
- 一番多く使われてるのがパスワード:80%
- 強力あなパスワードを使い回さずに使えばパスワードも強い
- 自動生成だとパスワードルールに引っかかることもあって面倒
- どこかのサイトがパスワードを漏らすと使い回してるサイトにログインされてしまう
- 生体情報などで認証すると公開鍵が作らて送られる
- パスキーはパスワードマネージャーに保護されている
- 複数プラットフォーム間の問題
- Passkey Autofill
- どのユーザでログインするかサジェストしてくれる
- パスワード使ったかパスキー使ったか意識せずログインできる
- ログインの体験はよくなる
- 登録の体験
- アカウント登録後にパスキー登録を促す
- 6,7割が登録を押してくれる
- タッチIDの登録が出てやってくれるのは半分くらい
- こういうの出したくない
- Passkey Auto Upgrade
- パスワードマネージャーでパスワードででログインした時に勝手にパスキーを作る
- いつの間にかパスキー使うようになってる
- 結局最初はパスワード登録しないといけない
マネーフォワードが取り組む グローバルテックカンパニーへの挑戦
- Tuck(Takuya Nakade)さん/CTO
グローバル化
- サービスの成長はグローバル化したのが大きい
- 海外の拠点と上下関係になるようなことはしたくなかった
- リージョナル・イコーリティ
- 現在CTOはインド在住
