freee 技術の日 2023 カンファレンス参加レポート

2023/04/15 Freee 株式会社さんのオフィスで開催されたカンファレンスにリアル参加してきました。この記事ではカンファレンスの内容、気になったこと等をなるべくさくっとまとめます。

※本記事の内容は個人的に取ったメモに基づいており誤りが含まれます、詳細/正確な内容はアーカイブ等 ご確認ください

イベント概要

フロントエンド、アクセシビリティ、CI、などのFreee内で用いている技術のセッションや講演が幅広く盛りだくさんでした。参加者数はConnpassによると300名ほどとのことでした。

Connpass

アーカイブ

https://www.youtube.com/watch?v=GC4reBbHMIM
https://www.youtube.com/watch?v=erTWrDBLgIw
https://www.youtube.com/watch?v=zdLrij6ryU0

見てきたセッションや講演内容

freee finance labの歩み モダンでフルサイクルな金融プロダクト開発

freeeカード Unlimitedの周辺技術についての話。

• サービス構成
  • インフラ: Amazon EKS
    • Terraform
    • Helm
  • API: Go言語
  • BFF: Rails(既存資産活用)
  • フロントエンド: React
  • その他: マイクロサービス構成
• マイクロサービスの理由
  • リアルタイム処理
  • 高い可用性
  • DDDのコンテキスト/関心事分離
    • 分けることで各エンジニアが知るべき範囲を小さくする
    • モジュール化で開発規模をスケールしやすくする
    • (他プロダクト等との)マイクロサービスの再利用
• 開発手法について
  • 初期: LeSS(ラージスケールスクラム)
    • コミュニケーションコストが高かった
  • 現在: Scrum of Scrums(スクラムオブスクラム)
    • 各スクラムチームの独立化を進めることができた
    • サイロ化(属人化)を防げた
• ブランチ運用・QAについて
  • 初期: git-flow
    • 機能ごとにブランチを切り適切なタイミングでdevelopにマージ
    • リリース順を変えたいときにコンフリクト祭りが発生
    • リリースと別のタイミングでQAをしたいときにうまい方法が無い
  • 現在: トランクベース
    • フィーチャートグルシステムを内製
      • yamlを書いて 各機能の公開/非公開を切り替えられるように
    • 随時マージできることでコンフリクトを防ぐ
    • ブランチの回転を早くすることでリリースまでのリードタイムを短縮
• SRE業務の中央集権化(ボトルネック化)
  • 各プロダクトごとにSRE担当を決めて開発チームだけでできるように
  • SREと開発で相互留学を行い 素早く対応できるように

法人向け銀行振り込みサービスの話

• マイクロサービス化
  • メリット
    • 決済が分かれていることで障害を減らせた
    • 独立した開発ができた
    • コンテキスト境界のメリットを感じられた
    • ドメイン設計が最初に十分練られることで見通しが良い
  • デメリット
    • インフラコスト
    • サービスを跨いだ処理を追いかけることが難しい
• サービス(物理的)レベルでなく モジュールレベルの分離という選択もある
  • あとから設計を変えやすい
  • Linterで依存方向を強制し 参照レイヤーを制限するという方法がある

脅威分析はじめました

脆弱性や脅威から守るため、プロダクトの構成や機能をベースに洗い出しを進めているというお話。

• 現状の課題
  • Devsecopsを目指す上で 各チームでの脅威とすべきものの認識がバラバラ
    • → この認識を揃えるため現状の分析を行う
• 行っている分析の手順
  • プロダクトの特徴を知る
  • システムの全体像を知る (図を書き出しどんな攻撃が想定できるか書き出す)
  • STRIDEに基づいた分類
  • 脅威を特定/評価/レビューする

freee会計からマイクロサービスを切り出すのに4年かかりました

元々モノリスだった会計システムをマイクロサービスに切り出したというお話。

• なぜマイクロサービスにすることに?
  • 他のアプリケーションで同じ処理を使いたくなったから
• マイクロサービスに使ったもの
  • Golang
  • gRPC
• 分けていく上での戦略
  • 通常の業務の25%ほどを使い分けた
  • 動かしつつ置き換える / 出来上がってから完全に置き換える
    • 既存ロジックを少しずつ新しいマイクロサービスに作り直した
  • 最初の段階ではDBは共有、負荷対策・シャーディングのためDBも分けて 分離が完了した
  • Railsの暗黙的なJOINを切り離すのが大変だった
• まとめ
  • 切り出しはできる
  • DBを完全に切り出さずサービスだけをまず分けて あとから完全に分けることができる
  • マイクロサービス化は すぐに効果が見えるものではないが今後に効いてくる

Webアプリケーションアクセシビリティ著者の会社での取り組みは実際どんな感じ?

Webアプリケーションアクセシビリティという本の筆者の方々の対談

• 最初は何から手を付けた?
  • 技術改善活動 勉強会の一部として社内啓発
  • 全社向けに勉強会
  • アクセシビリティとは何か を語る
• どんなチームで対応したか?
  • デザインシステムの一部
  • アクセシビリティ専門チーム
  • プログラマ有志からチーム化 途中からデザインチームとともに
• アクセシビリティが必要な人との関わり
  • 障がいを持つ方を実際に雇って社内でテストしてもらう
  • 外部団体に事例ヒアリング
  • 使用感をインタビューする(今後の課題)
• 今後の課題
  • WCAG 2.0(Web Content Accessibility Guidelines)を読もう
  • 触る段階にたどり着けていない人にどう対応するか検討する
  • 現状の向上でなくアクセシビリティを前提とした機能を用意する
  • 専門チームがすることでなくデザインやエンジニアリングの一部であることを周知していく
  • 届ける相手を具現化する / より接触機会を増やす
  • アクセシビリティの必要性を訴え市場を作っていく

freeeのwebとモバイルでのテスト自動化の取り組み

• なぜテストを自動化する必要があるか?
  • 開発のリリース速度へ 品質を追従させる
    • リリース速度の犠牲に品質を下げない
    • リリース速度と品質の両方を高くするため
• Webのテスト
  • すべてのテストにPASSでリリース可能になる
• モバイルのテスト
  • 月2定期リリース
  • Webのリリース時に同時にテストが行われる
    • Web側の更新とアプリの更新タイミングが異なりレスポンスが噛み合わなくなることがあるため
• Webテストとモバイルテスト
  • 普通にやると書き方に違いが出る / 異なる書き方になる
  • どちらかがコケたとき もう片方のエラー原因を別チームに依頼することになる
    • → 開発をスケールしやすくするため 内製ツールを作成、両方同じ書き方に揃えた
• 今後
  • テストカバレッジを上げる
  • 機能単位でテスト可能にする

freee会計のデプロイフローの現状とこれから

• 利用中のデプロイツール
  • ArgoCD
    • gitリポジトリのマニフェストをもとにしたKubernetes用CDツール
  • github actions
    • SPA(アセット)ビルド
    • build & ECR push
    • imageタグ作成 + PR作成
  • perfect sutekaku
    • デプロイを補助する内製WebUIツール(Firebase)
• prefect sutekakuの機能
  • PR作成
    • 1クリックでPR作成
      • develop->staging
      • staging->main
      • Slackでデプロイ対象のPR作成者に通知
  • Slack通知
    • ステージング確認リスト
    • 確認催促
    • 完了通知
• Canaryリリース
  • Kubernetesの機能で 最初の30分は5%分だけリクエストが流れる仕様
• 今後の課題
  • 4keysで生産性を測る
    • デプロイ頻度
    • リードタイム
    • サービス復旧の所要時間
    • 変更失敗率
  • 新プロダクト用の汎用設定
  • プロダクト毎の差異をなくす

仕事がしやすくなる社内発信のすすめ

• よくないこと
  • 方針を共有しないこと
    • あとでツッコミ多数
    • 更に直しても書き方がそもそも違う等ツッコミ多数
    • 手戻り+時間がない
    • 負のループ
      • → とにかく共有する
• Will can must フレームワークを元に共有する
  • やりたいこと
  • できること
  • やるべきこと
  • (できないこと)
    • 継続的に自己を伝える
    • 人は知っている人にお願いをする
• どうやって共有するか
  • Slackに書く
  • 知見を社内外問わず書く
  • なんでも書く
  • 自己開示できる相手を見つける
• あがる成果
  • スケジュール通りに物事が進みやすくなる
  • アウトプットが増える
  • 知見が集まる
  • 評価に近づく
    • 発信することで得られるものは多い
    • 発信に見合う仕事が得られる

ChatGPTなど大規模言語モデルの活用方法や影響について

ai-lab freeeにおける AIの活用検討の話

• 活用案
  • 業務効率化
    • コーディング
      • Github copilot
      • ChatGPT
        • → 開発者全員利用可能に
  • プロダクトでの活用
    • 税理士AI
    • ヘルプデスクAI
    • プラットフォームでの活用
• 検討中のアイデア
  • ユーザーがシームレスに使うことができるようにする
    • ユーザーのしたいことをしやすくする
    • 情報をユーザー/システム/税理士でうまく受け渡す
• 検討中の技術
  • VectorDB (llamaindex)
    • DBにデータの意味を保存し 記憶を保持する
  • Agent (langchain)
    • 複数のタスクを相互作用させる
• デモ
  • チャットからAPIを操作する

会計フロントエンドのTypeScript化

2013年からある10年ものの最も古いサービスをTypeScriptに移行する話

• 現状の技術構成
  • 言語: JavaScript+Flow
  • UI: React+Rails+jQuery+eco+ReactiveJS
  • Style: SASS
  • State: backbone + flux-hooks
    • とても混ざっていてキャッチアップが難しく危険
• 移行対象システム
  • JS6000ファイル
    • 社内ツールを作りCoffeeScriptをTypeScriptにしたもの
• 移行方法
  • ツールを作りツールで変換する
    • メリット: ラク
    • デメリット: 型が不完全 / FW統一不可 / 負債のまま残る
  • 手動で変換する
    • メリット: 型安全 / ロジックがきれいになる
    • デメリット: 圧倒的に時間がかかる
      • ビジネス的に厳しい
• 選んだ移行方法
  • 開発を進めつつ 少しずつTSに移行 古いFWを一掃する
• どれぐらいの見込みか
  • 3年

感想・まとめ

他社さんの手法を知ることができ、とても参考になりました。モダンなデプロイフロー、ブランチ運用等は自分の業務でも活かせそうです。また、技術的負債に対する戦いはどこの企業でもあることを実感しました。今回が初めてのテックカンファレンス参加でしたが、とても楽しい時間を過ごすことができました。次回も機会があればぜひ参加したいと思います。

蛇足

• はじめてこういうレポート書いたので、ものすごく疲れました。箇条書きだけなら文字起こししてChatGPTにやらせればいいし、イマイチな内容だったかもしれない...
• 誘ってくれた友人に感謝。
• この文章は Poe/Sage とChatGPTに校正してもらい執筆しました。