freee 技術の日 2024に参加してきた (前夜祭)
TL;DR
- freee 技術の日 2024 に参加してきた
- 前夜祭と (あとで) 本祭のセッションの感想を適当に、雑に、さくっと
- 去年と比べて tech な内容はやや減ったが、その分 Product Manager (PdM) とか Engineering Manager (EM) とか Product Designer (PD) とかそういうロールの人がいっぱい出てきて新鮮だった
はじめに
とある縁があって「freee 技術の日 2024」に、去年に引き続き参加してきました！
オフラインコンテンツも楽しいものがいっぱいあったのですが、とりあえず聞いてきたせっしょんとその感想を適当に、あったかいうちに、雑に。
本祭は freee 技術の日 2024に参加してきた (本祭) です。
去年のは freee 技術の日 に参加してきた です。
Day1 (前夜祭)
去年と違い、今年は前夜祭があり、ちょっと長めの LT がいっぱい、お酒飲みながら、みたいな感じの日が前夜祭として開かれました。
ID連携基盤のマイクロサービス移行プラクティス
- 認証認可基盤エンジニア てらら さん
認証認可大好物なのでとりあえずこちら聞いてきました。
- freee がとあるタイミングからプロダクトの「種類」をめっちゃ増やすようになるとともに、認証認可の仕組み、というかプロダクトごとの実装もいろいろ増えてきてしまっている
- んじゃ共通認証機能的なもの作ろうぜ、って話
- んで、そのあとじゃあもともとの monolith から切り出していかなきゃいけないよね、しんどそう
- ストラングラー フィグ パターンを使って徐々に変更していってる (ref. ストラングラー フィグ パターン)
- メリット・デメリット比較したうえで社内ライブラリを開発している
- 時間配分が（ｒｙ
認証や招待と日々向き合う基盤PdMが考えていること・取り組んでいること
- プロダクトマネージャー 佐々木 慎平 (shimpei) さん
ちょっと似てるけど違う、アカウント基盤みたいな話。
- アカウントライフサイクル的な話、freee を始めていただくところから、より便利に使う、そしてやめる、まで
- プロダクトの数がかなり多い (たしか 50 個くらいだったか)
- 共通認証画面的なさむしんぐを作っている
- 「基盤チーム」としていろんなプロダクトにインパクトを出していきたい
freeeのプロダクト品質は俺が守る！開発スピードをあげながら品質を担保するための施策
- 統合基盤デザインシステム デザイナー むろ (muro) さん
体調不良だそうで、代打で ymrl さん。
今見なおしたら YouTube のチャット欄にリアルタイムでいらっしゃったｗ
- アクセシビリティがスピードを阻害する要因になってしまっている、、
- QA の中で a11y (accessibility) に関するチェックを入れている、プロダクトの開発サイクル上、タイミングとしてはかなり後ろの方になってしまっていた
- それでも a11y 起因の issue の数は確実に減っていっている、えらい
- a11y のチェックをデザインの時点で巻き込む、シフトレフト、問題点を早期に見つける
more better と思ったところ
たぶん accessibility の観点で英語を併記してるんだろうが、ちょっと場所が適当すぎる気がした (個人の意見ね) のと、じゃあ字幕は？みたいなのはちょっと思いました、海外からの人も来てるんとちゃうん？という
なかなか成立しないStorytelling、ってかStorytellingって何？
- プロダクトデザイナー vii さん
ちょっとなんか独自の世界観って感じでちょっとコメントがしづらいｗ
なんとなく言いたいことは分かるんだけど、なんかうまく言語化できないというか、受け取り手側にも技術がいる感じだった。。。
OpenSearch SIEMのためのSOAR
- セキュリティエンジニア WaTTson さん
- エンジニア imariku さん
大きなステージの方、ASOBIBA の方に移って SIEM の話。
WaTTson さんの方が若手らしいんだが imariku さんをゴリゴリにあおって進んでいくのが面白かったｗ
- Product Security Incident Response Team (PSIRT) の方からきました
- WAF とか IDS/IPS みたいなインフラセキュリティエンジニアっぽい話、実家のような安心感
- S3 にいろんなログを放り込むので、それを Lambda で OpenSearch に放り込んでいい感じにやる
- ログが多すぎて人間には見切れないので Security Orchestration, Automation and Response (SOAR) で自動化
- そのための Slack bot、SIEM 次郎、ってのがある、
し○じろうとは関係ない - 機械学習を使っていい感じによろしくやりたい、開発中
more better と思ったところ
なんかもうちょい先進的な話が聞けると思ったかなー、という率直な感想。。SOAR なら hunting から remediation までやってくれるとか。。。Security Copilot とかあるじゃんあーいうのさー、みたいな。
超複雑なドメインが絡むプロダクトにどう向き合っていくか
- 公認会計士/税理士 プロダクトマネージャー 高木 悟 さん
公認会計士で税理士で PdM、すごい経歴の方。
- 会計とか法律とかなんか難しそうじゃん、超複雑なドメインじゃん
- でも実際には法制度・計算自体の理解、っていう正解のあるドメインと、ユーザー業務の理解みたいな正解のないというかそれぞれのドメインの 2 種類がある
- ピュア PM とドメイン スペシャリストっていう分類を考えた、よさそう
- ドメインが複雑だからこそ、プロダクトの競争力が高い、参入障壁が高い、やり切れるならメリットになりうる
- 同じような境遇の方への応援メッセージ「複雑なドメインが絡む開発を楽しんで、よいプロダクトを作っていきましょう！」
なんか難しい話、苦労するよね、って話なんだけど前向きなメッセージでいい印象だった！
進化していくシステムアーキテクチャ
- システムアーキテクト 宇佐美 ゆう さん
米国でスタートアップ 3 社くらい経験してきた方らしい、すごい。
- freee の歴史、2012～2013 年くらいから (ref. 「経理いらず」のクラウド会計 元グーグル社員が起業)
- 簡単な LB - Backend App - database みたいなシンプル構成から container を使った micro-service へのアーキテクチャへの変遷
- とそれにあたっての課題、どう解決していくか、アーキテクチャの観点から
- 簡単な LB - Backend App - database みたいなシンプル構成から container を使った micro-service へのアーキテクチャへの変遷
- Sweee ちゃんがスライドの各所にいるんだけど悩んでる顔がかわいい
- 依存関係をシンプルにするために pub/sub を入れる、リアルタイム性があまり求められない前提
- サービス間連携ガイドラインの原則・実装例を定義している
- 連携先のサービスが常に正常に動作することを前提としない、どっかの o'reilly に書いてあった気がする、chaos engineering だったか
- API 経由もしくはイベント経由で連携する、AWS のあれみたいな
- ドメインサービスのガイドラインとして free-bootstrap を定義しているらしい、どっかに OSS になってるのかは分からん
まとめ
というかもはや感想。。
人材の豊富さを感じさせられたというか、PdM って言ってるのか PM なのかちょっと分からんけど、業務知識を持ってるメンバーがこれだけそろっていること、その価値ってすごいなーと思いました。
いろんな業界、経歴のメンバーがさまざまそろってくると、それだけでユーザーのペインポイントを理解しやすくなる、そのためのボキャブラリーをそろえられる、そのうちビジネス コンサルとかできるんじゃあないっすかね。
Discussion