イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜 SaaSにおけるフロントエンドの技術戦略 | SaaS.tech #6 2023/02/22 ham

自己紹介 【略歴】 新卒でSIerとして就職 その後、Web系企業やスタートアップを経てファインディに参画 ファインディではFindy Team+のフロント&バックエンド開発を担当 React+Rails+GraphQL+AWSを使って開発しています 浜田 直人 (ham) ファインディ株式会社 @hamchance0215

Findy Team+とは？ https://findy-team.io GitHubやGitLab、Jiraなどエ ンジニア向けツールを解析す ることで、エンジニアリング組 織の生産性を可視化する サービスです。

プロダクトの歴史 2021/10 正式にローンチ 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート 2020年 α版リリース

プロダクトの歴史 2021/10 正式にローンチ 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート 2020年 α版リリース プロダクトの成長と共にエンジニアが増加 チーム開発の効率を上げるためアーキテクチャを変更中

ローンチ当時の状況 2021/10 正式にローンチ ● 不足している機能を新規開発し、顧客 価値を高めることに注力 ○ 少人数でガンガン新規開発！

ローンチ当時の状況 2021/10 正式にローンチ ● 不足している機能を新規開発し、顧客 価値を高めることに注力 ○ 少人数でガンガン新規開発！ ● 簡単に使えることを重視 イージーなアーキテクチャ

現在の状況 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート ● 新規開発に加えて、既存機能をブラッ シュアップ ○ 既存機能を触る機会が増える ● エンジニア増加。効率よくチーム開発 できることが重要 ○ コードリーディングしやすく、誰で も触れるコードが良い

現在の状況 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート ● 新規開発に加えて、既存機能をブラッ シュアップ ○ 既存機能を触る機会が増える ● エンジニア増加。効率よくチーム開発 できることが重要 ○ コードリーディングしやすく、誰で も触れるコードが良い 簡単に理解できることを重視 シンプルなアーキテクチャ

イージーからシンプルへ

イージーからシンプルへ

イージーなアーキテクチャ ・Filterに指定した条件のデータを表示す る画面 ・画面ごとにFilterの種類や数、表示する データが違う

イージーなアーキテクチャ const [filters, setFilters] = useState(); return (

Hoge画面

); 各画面にFilterがあるのでまとめて を作ろう

イージーなアーキテクチャ const [filters, setFilters] = useState(); return (

Hoge画面

); データ表示はを作ろう データ取得処理も内部に隠蔽すれば楽だな

イージーなアーキテクチャ const [filters, setFilters] = useState(); return (

Fuge画面

);

イージーなアーキテクチャ const [filters, setFilters] = useState(); return (

Fuge画面

); 簡単に使えることを重視 共通コンポーネントをぽんぽん置いていく だけで類似画面が量産できる！

イージーなアーキテクチャ const Filters = ({ setFilters, disableFilter1, disableFilter2, disableFilter3, … }) => { // いろいろなしょり … }); [props] 利用元の仕様を吸収する ため増加していく [処理] データ取得やレイアウトなど様々な責務を持ってい たり、利用元の様々なパターンに対応するため処理 が複雑に 一方、共通コンポーネント内は肥大化＆複雑化していく... [テスト] コンポーネント内に外部 APIやGlobal Store への接続が混在しているため、テストが大変 大量のMockが必要となる

● 簡単に使えることを重視 ○ 共通コンポーネントをぽんぽん置いていくだけで類似 画面が量産できる！ ○ 共通コンポーネント内が複雑になり、一定水準を超え ると簡単に使うことも難しくなる ● 責務が複数あり、処理が複雑になりやすい ○ キャッチアップが難しく、属人化が進む ○ テストが書きづらい イージーなアーキテクチャ

イージーからシンプルへ

シンプルなアーキテクチャ // 外部APIやGlobal Stateへの接続を集約 const {data, options1, …, } = useFacade(); return (

Hoge画面

// Filterは1つずつ配置 // 内部でデータ取得などはせずoptionsやeventは外から渡す // 取得したデータを渡し、DataTableは表示に専念 );

シンプルなアーキテクチャ // 外部APIやGlobal Stateへの接続を集約 const {data, options1, …, } = useFacade(); return (

Hoge画面

// Filterは1つずつ配置 // 内部でデータ取得はせずoptionsやeventはpropsで渡す // 取得したデータを渡し、DataTableは表示に専念 ); 関数の責務を明確にする 名前を見るだけでやっていることが想像できる のでコードリーディングが簡単 新しいメンバーがキャッチアップしやすい データ取得などを呼び出し元で行うため、イー ジーと比べて一手間必要になる (やることは明確)

シンプルなアーキテクチャ // 外部APIやGlobal Stateへの接続を集約 const {data, options1, …, } = useFacade(); return (

Hoge画面

// Filterは1つずつ配置 // 内部でデータ取得はせずoptionsやeventは外から渡す // 取得したデータを渡し、DataTableは表示に専念 ); 過度な共通化は行わない イージーよりコード量が増えるが、コン ポーネントが疎結合になり影響範囲が局 所化できて変更に強い

シンプルなアーキテクチャ const Filter = ({ selectedValue, options, onChange }) => { const {state, handleHoge} = useFilter(); return ( ); }); [props] 表示に必要なデータは内部で取得せ ず、propsで受け取る componentは表示に専念 component内部でstateや callbackなどが必要な場合、専 用の関数で管理 共通コンポーネント内も責務を分離してシンプルに！ [テスト] componentは外部接続などを行わないた め、テストやStrorybookが実装しやすい モック地獄からの解放

● 簡単に使えることより、簡単に理解できる(=シンプルな 実装)ことを重視 ● 責務を明確にすることで可読性UP ○ テストが書きやすい ● 過度な共通化をしない ○ コード量は増えるが変更に強い ● キャッチアップしやすく、新しいメンバーに優しい ○ チーム開発に向いている シンプルなアーキテクチャ

途中経過

アーキテクチャ変更の途中経過 12月から開始して現時点で半分ほど完了 一人当たりのプルリク作成数が増加中！！ 一人当たりの プルリク作成数 約1.5倍に！！ ※Findyではプルリク作成数 を開発生産性の1つの指標と して見ることが多い

イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜 ご清聴ありがとうございました