イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜

Transcript

1. イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜 SaaSにおけるフロントエンドの技術戦略 | SaaS.tech #6 2023/02/22 ham
2. 自己紹介 【略歴】 新卒でSIerとして就職 その後、Web系企業やスタートアップを経てファインディに参画 ファインディではFindy Team+のフロント&バックエンド開発を担当 React+Rails+GraphQL+AWSを使って開発しています 浜田 直人 (ham) ファインディ株式会社 @hamchance0215
3. Findy Team+とは？ https://findy-team.io GitHubやGitLab、Jiraなどエ ンジニア向けツールを解析す ることで、エンジニアリング組 織の生産性を可視化する サービスです。
4. プロダクトの歴史 2021/10 正式にローンチ 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート 2020年 α版リリース
5. プロダクトの歴史 2021/10 正式にローンチ 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート 2020年 α版リリース プロダクトの成長と共にエンジニアが増加 チーム開発の効率を上げるためアーキテクチャを変更中
6. ローンチ当時の状況 2021/10 正式にローンチ • 不足している機能を新規開発し、顧客 価値を高めることに注力 ◦ 少人数でガンガン新規開発！
7. ローンチ当時の状況 2021/10 正式にローンチ • 不足している機能を新規開発し、顧客 価値を高めることに注力 ◦ 少人数でガンガン新規開発！ • 簡単に使えることを重視 イージーなアーキテクチャ
8. 現在の状況 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート • 新規開発に加えて、既存機能をブラッ シュアップ ◦ 既存機能を触る機会が増える • エンジニア増加。効率よくチーム開発 できることが重要 ◦ コードリーディングしやすく、誰で も触れるコードが良い
9. 現在の状況 2022/10 Team+へ進化 生産性の可視化・向上に加え、エンジニ ア組織の「開発者体験」「改善文化」「採 用」を一貫してサポート • 新規開発に加えて、既存機能をブラッ シュアップ ◦ 既存機能を触る機会が増える • エンジニア増加。効率よくチーム開発 できることが重要 ◦ コードリーディングしやすく、誰で も触れるコードが良い 簡単に理解できることを重視 シンプルなアーキテクチャ
10. イージーからシンプルへ
11. イージーからシンプルへ
12. イージーなアーキテクチャ ・Filterに指定した条件のデータを表示す る画面 ・画面ごとにFilterの種類や数、表示する データが違う
13. イージーなアーキテクチャ const [filters, setFilters] = useState(); return ( <Layout> <h1>Hoge画面</h1> <Filters setFilters={setFilters} /> <div> Hogeなデータが表示されます </div> <DataTable type={hoge} filters={filters} /> </Layout> ); 各画面にFilterがあるのでまとめて <Filters />を作ろう
14. イージーなアーキテクチャ const [filters, setFilters] = useState(); return ( <Layout> <h1>Hoge画面</h1> <Filters setFilters={setFilters} /> <div> Hogeなデータが表示されます </div> <DataTable type={hoge} filters={filters} /> </Layout> ); データ表示は<DataTable />を作ろう データ取得処理も内部に隠蔽すれば楽だな
15. イージーなアーキテクチャ const [filters, setFilters] = useState(); return ( <Layout> <h1>Fuge画面</h1> <Filters setFilters={setFilters} disabledFilter3={true} /> <div> Fugeなデータが表示されます </div> <DataTable type={fuga} filters={filters} /> </Layout> );
16. イージーなアーキテクチャ const [filters, setFilters] = useState(); return ( <Layout> <h1>Fuge画面</h1> <Filters setFilters={setFilters} disabledFilter3={true} /> <div> Fugeなデータが表示されます </div> <DataTable type={fuga} filters={filters} /> </Layout> ); 簡単に使えることを重視 共通コンポーネントをぽんぽん置いていく だけで類似画面が量産できる！
17. イージーなアーキテクチャ const Filters = ({ setFilters, disableFilter1, disableFilter2, disableFilter3, … }) => { // いろいろなしょり … }); [props] 利用元の仕様を吸収する ため増加していく [処理] データ取得やレイアウトなど様々な責務を持ってい たり、利用元の様々なパターンに対応するため処理 が複雑に 一方、共通コンポーネント内は肥大化＆複雑化していく... [テスト] コンポーネント内に外部 APIやGlobal Store への接続が混在しているため、テストが大変 大量のMockが必要となる
18. • 簡単に使えることを重視 ◦ 共通コンポーネントをぽんぽん置いていくだけで類似 画面が量産できる！ ◦ 共通コンポーネント内が複雑になり、一定水準を超え ると簡単に使うことも難しくなる • 責務が複数あり、処理が複雑になりやすい ◦ キャッチアップが難しく、属人化が進む ◦ テストが書きづらい イージーなアーキテクチャ
19. イージーからシンプルへ
20. シンプルなアーキテクチャ // 外部APIやGlobal Stateへの接続を集約 const {data, options1, …, } = useFacade(); return ( <Layout> <h1>Hoge画面</h1> // Filterは1つずつ配置 // 内部でデータ取得などはせずoptionsやeventは外から渡す <Filter options={options1} onChange={onChange1}/> <Filter options={options2} onChange={onChange2}/> <Filter options={options3} onChange={onChange3}/> <div> Hogeなデータが表示されます </div> // 取得したデータを渡し、DataTableは表示に専念 <DataTable data={data} /> </Layout> );
21. シンプルなアーキテクチャ // 外部APIやGlobal Stateへの接続を集約 const {data, options1, …, } = useFacade(); return ( <Layout> <h1>Hoge画面</h1> // Filterは1つずつ配置 // 内部でデータ取得はせずoptionsやeventはpropsで渡す <Filter options={options1} onChange={onChange1}/> <Filter options={options2} onChange={onChange2}/> <Filter options={options3} onChange={onChange3}/> <div> Hogeなデータが表示されます </div> // 取得したデータを渡し、DataTableは表示に専念 <DataTable data={data} /> </Layout> ); 関数の責務を明確にする 名前を見るだけでやっていることが想像できる のでコードリーディングが簡単 新しいメンバーがキャッチアップしやすい データ取得などを呼び出し元で行うため、イー ジーと比べて一手間必要になる (やることは明確)
22. シンプルなアーキテクチャ // 外部APIやGlobal Stateへの接続を集約 const {data, options1, …, } = useFacade(); return ( <Layout> <h1>Hoge画面</h1> // Filterは1つずつ配置 // 内部でデータ取得はせずoptionsやeventは外から渡す <Filter options={options1} onChange={onChange1}/> <Filter options={options2} onChange={onChange2}/> <Filter options={options3} onChange={onChange3}/> <div> Hogeなデータが表示されます </div> // 取得したデータを渡し、DataTableは表示に専念 <DataTable data={data} /> </Layout> ); 過度な共通化は行わない イージーよりコード量が増えるが、コン ポーネントが疎結合になり影響範囲が局 所化できて変更に強い
23. シンプルなアーキテクチャ const Filter = ({ selectedValue, options, onChange }) => { const {state, handleHoge} = useFilter(); return ( <Select options={options} value={selectedValue} onChange={onChange} onHoge={handleHoge} /> ); }); [props] 表示に必要なデータは内部で取得せ ず、propsで受け取る componentは表示に専念 component内部でstateや callbackなどが必要な場合、専 用の関数で管理 共通コンポーネント内も責務を分離してシンプルに！ [テスト] componentは外部接続などを行わないた め、テストやStrorybookが実装しやすい モック地獄からの解放
24. • 簡単に使えることより、簡単に理解できる(=シンプルな 実装)ことを重視 • 責務を明確にすることで可読性UP ◦ テストが書きやすい • 過度な共通化をしない ◦ コード量は増えるが変更に強い • キャッチアップしやすく、新しいメンバーに優しい ◦ チーム開発に向いている シンプルなアーキテクチャ
25. 途中経過
26. アーキテクチャ変更の途中経過 12月から開始して現時点で半分ほど完了 一人当たりのプルリク作成数が増加中！！ 一人当たりの プルリク作成数 約1.5倍に！！ ※Findyではプルリク作成数 を開発生産性の1つの指標と して見ることが多い
27. イージーからシンプルへ 〜プロダクトの成長に合わせたアーキテクチャの変更〜 ご清聴ありがとうございました