業務システムにも使いやすいUIを。モダンフロントエンドの技術選定

Transcript

1. 業務システムにも使いやすいUIを。モ ダンフロントエンドの技術選定 ＠hiramatsutaku 株式会社カケハシ 2021/10/05 AI在庫管理（新規事業）の設計勘所 https://connpass.com/event/223220/

2. 自己紹介 • 平松拓 • 京都在住、33歳、娘👭 • 趣味 ◦ サッカー、山登り、コードを書くこと •

   職種 ◦ ソフトウェアエンジニア ▪ フロントエンドメイン • 経歴 ◦ 新卒で株式会社フリークアウト ◦ いくつかの新規事業に従事 ◦ 2020/6〜 株式会社カケハシ

3. Agenda

4. Agenda • 技術選定にあたって意識したこと • Musubi AI在庫管理フロントエンドの技術スタック • 振り返り

5. Agenda • 技術選定にあたって意識したこと • Musubi AI在庫管理フロントエンドの技術スタック • 振り返り

6. 技術選定にあたって意識したこと

7. 技術選定にあたって意識したこと • 0 → 1 フェーズであるということ

8. 技術選定にあたって意識したこと • 0 → 1 フェーズであるということ

9. 0 → 1 フェーズであること • いかに早くリリースできるか ◦ ユーザに使ってもらって、フィードバックをもらわないと気づけないことは絶対にある ▪ （カケハシのバリューに無知の知というのがある）

   • 変更に対して柔軟に対応できるか ◦ 手探りな状況から始めるので、最初から完璧な仕様を決められない ◦ フィードバックループを高速に回す必要がある ◦ 既存の設計が足枷となって変更コストが増えたり、そこに固執したりすると MVP 達成までの距離が遠くなる • ユーザやプロダクトに向き合う時間をできるだけ多くする ◦ やることは無限にある ◦ MVP（Minimum Viable Product）達成前のフェーズでは、ユーザやプロダクトに向き合うことが圧倒的に重要 技術選定にあたって意識したこと

10. Agenda • 技術選定にあたって意識したこと • Musubi AI在庫管理のフロントエンドの技術スタック • 振り返り、学び

11. Musubi AI在庫管理フロントエンドの 技術スタック

12. Musubi AI在庫管理フロントエンドの技術スタック • まずバックエンドの一部も含めた全体構成を紹介します

13. None

14. Amplify Console で SPA を配信

15. バックエンドは AppSync

16. Musubi AI在庫管理フロントエンドの技術スタック • Amplify Console • TypeScript • React •

    Next.js • Apollo Client • Chakra UI • Recoil • LaunchDarkly • Sentry • GitHub Actions • ESLint • Prettier • Jest • React Testing Library • Storybook • reg-suit • Mabl • etc.

17. Hosting − Amplify Console • SPA の Hosting に Amplify

    Console を利用 • GitHub 連携 ◦ Pull Request 単位で一意の URL にデプロイしてくれる ◦ 最近 Pull Request にコメントがつくようになった 😄 • Basic 認証も一瞬で設定できる • monorepo にも対応しており、以下を一つの amplify.yml で管理 ◦ Musubi AI在庫管理 ◦ 社内管理コンソール • 󰢏 ◦ 爆速でフロントエンドのインフラ環境、 CI/CD パイプラインを構築できた Musubi AI在庫管理フロントエンドの技術スタック https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/welcome.html

18. Hosting − Amplify Console Musubi AI在庫管理フロントエンドの技術スタック AWS のブログに取り上げてもらいました https://aws.amazon.com/jp/blogs/startup/casestudy_kakehashi/

19. React Framework − Next.js • そもそも何故 React ？？ ◦ 社内では

    Augular と React の採用実績があったが、担当メンバ（僕）のスキルセット的に、 React の方が早くプロダクトを作ることができたから • 当初 Next.js を使わず webpack config を書いていた ◦ もっとユーザに向き合うべきと考えた • Next.js のルーティングを利用したかった • 現状は SPA で十分なので SSR はしていない • 󰢏 ◦ 属人性の排除 ◦ ビルド、パフォーマンス面の最適化 Musubi AI在庫管理フロントエンドの技術スタック https://nextjs.org/

20. GraphQL Client − Apollo Client • そもそもなんで GraphQL？ ◦ Schemaファーストにフロントエンド、バックエンドを並行して開発したかった

    ◦ 画面の仕様がまだ固まっていなかった ◦ GraphQL Code Generator と合わせて使うとより強力 ◦ TypeScript との相性も抜群 • GraphQL Client としてはデファクト • Apollo Client cache の仕組みが良い ◦ Redux と一緒によく使われる normalizr の役割を担ってくれる ◦ API レスポンスデータを正規化して効率的に cache • 󰢏 ◦ API レスポンスデータの状態管理を低コストで実現 ◦ 型安全な API クライアントを自動生成 Musubi AI在庫管理フロントエンドの技術スタック https://www.apollographql.com/docs/react/

21. State management − React.useState / Recoil • コンポーネントに閉じた状態管理には React.useState を利用

    • グローバルな状態管理には Recoil を利用 • 一部若干複雑な画面の状態管理にも Recoil を利用 • 状態管理周りのディレクトリ構成、テスト方針などは、別途 Tech Blog で後日紹介します 📝 Musubi AI在庫管理フロントエンドの技術スタック https://kakehashi-dev.hatenablog.com/

22. React Component Library − Chakra UI • フロントエンド開発は正社員1人（僕）と業務委託メンバ1人なので、できるだけ楽をしたい • アプリケーションで使うコンポーネントが一式が揃っている

    • テーマでカスタマイズが容易 • TypeScript との相性も良い • styled-system ベース（個人的に styled-system の思想が好みだった） Musubi AI在庫管理フロントエンドの技術スタック https://chakra-ui.com/

23. Feature Flag − LaunchDarkly • Feature Flag の管理に LaunchDarkly を利用

    • まだリリースできない機能を Feature Flag で隠して細かくリリースしていく • 特定の顧客のみでテストしたいケースなど • Feature Flag の状態管理は、Terraform で実施 Musubi AI在庫管理フロントエンドの技術スタック https://launchdarkly.com/

24. Agenda • 技術選定にあたって意識したこと • Musubi AI在庫管理のフロントエンドの技術スタック • 振り返り

25. 振り返り

26. 振り返り • 0 → 1 の技術選定については概ね成功なの？ • で、使いやすい UI を提供できたの？

27. 振り返り • 0 → 1 の技術選定については概ね成功なの？ • で、使いやすい UI を提供できたの？

28. 0 → 1 の技術選定については概ね成功なの？ • 技術選定にあたって意識したことベースに振り返る ◦ ＞いかに早くリリースできるか ◦ ＞変更に対して柔軟に対応できるか

    ◦ ＞ユーザやプロダクトに向き合う時間をできるだけ多くする 振り返り

29. 0 → 1 の技術選定については概ね成功なの？ ＞いかに早くリリースできるか • 結果 ◦ AI在庫管理はバックエンドの開発が重かったのでなんとも言えないが、フロントエンドは先行 してユーザビリティテスト版をリリースできた

    ◦ 本リリース後もほぼ毎日デプロイできている • 技術選定によりうまくいった点 ◦ Apollo Server の Mocking の機能を利用して手軽に Mock API を立てることができた ◦ LaunchDarkly を使うことで、Feature Flag 管理を簡易化でき、リリース粒度の詳細化、ビック バンリリースの回避ができた 振り返り

30. 0 → 1 の技術選定については概ね成功なの？ ＞変更に対して柔軟に対応できるか • 結果 ◦ 画面の仕様変更がそれなりに発生した（体験設計、情報設計からやり直した画面が半分以上） が、変更コスト

    を最小限に抑えることができた ◦ 毎日デプロイして機能追加、改善を行えている • 技術選定がうまくいった点 ◦ GraphQL スキーマを Resource 志向で設計していたため、フロントから投げる Query の修正 のみで対応できることが多かった ◦ GraphQL の Collocation の考えに沿って、React コンポーネントと GraphQL Query or Fragment を同居させることで、コンポーネント単位での画面を作り直したりしやすくなった 振り返り

31. 0 → 1 の技術選定については概ね成功なの？ ＞ユーザやプロダクトに向き合う時間をできるだけ多くする • 結果 ◦ 計測は難しい、、 🤔（良い計測方法があれば、、）

    ◦ 以下は個人的な感覚 ▪ PO、デザイナ、社内の薬剤師メンバ、機械学習エンジニア、バックエンドエンジニア皆と、プロダクトについてディスカッ ションする時間は惜しみなく取ることができた • 技術選定によりうまくいった点 ◦ Next.js、Chakra UI を用いることで、効率的に開発を行うことができた ◦ GraphQL Code Generator によって、フロントエンドと AppSync を接続部分が効率的に、型 安全にノンストレスな開発体験で実装することができた 振り返り

32. 振り返り • 0 → 1 の技術選定については概ね成功なの？ • で、使いやすい UI を提供できたの？

33. で、使いやすい UI を提供できたの？ 絶賛やっていき 💪 しているところ。日々改善しているがまだまだもっとよくできる。 そのために、、、、 振り返り

34. あなたの力が必要です 🙏 少しでも興味を持った方は カジュアル面談させてもらえると 嬉しいです！ 🙏

35. End