React開発における失敗事例と学び〜実例3選とともに〜

Transcript

1. Copyright © 2023 Bitkey Inc. All right reserved.
   React開発における失敗事例と学び
   〜実例3選とともに〜
   株式会社ビットキー　佐藤 拓人　2023/03/28
   

   View Slide

2. 2
   Copyright © 2023 Bitkey Inc. All right reserved.
   自己紹介
   佐藤 拓人
   Sato Takuto
   2015.04
   2019.05
   2020.01
   大学(建築学専攻)卒業後、
   株式会社ワークスアプリケーションズに入社
   会計システムのソフトウェア開発を担当
   特に財務会計の仕訳関連
   ビットキーへ参画
   ECサイトの開発 / 保守、社内システムの開発
   TaKuTyの開発
   今のHome事業の前身となるResidenceチームに配属
   bitlockを扱う管理画面やバックエンド、appの開発に
   従事
   Now Homeプロダクトの技術責任者
   複雑な事象を読み解いて構造化し、抽象化 / 汎用化で
   きるように設計し、低コストで多くの価値をだせる開
   発をすることを好む
   

   View Slide

3. 3
   Copyright © 2023 Bitkey Inc. All right reserved.
   実際に私が経験した以下の失敗事例についてお話します
   1. コンポーネントの肥大化...
   2. デザイン × 実装 プロセスの改善
   3. レンダリング超過
   私が経験した事例の多くは先人たちの知恵で回避できるものも多いです
   そしてその知恵は書籍 にも記載されています
   (『TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発』)
   実際に開発をするときに起こしうる失敗事例を事前に認識しておくことで
   同様の事例の回避ならびに知識をより有効に使う助けになるかと思い
   今回はいくつかの失敗事例 / 原因 / 解決方法を紹介したいと思います
   1. はじめに
   今日のはなし
   

   View Slide

4. 4
   Copyright © 2023 Bitkey Inc. All right reserved.
   Outline
   1. はじめに
   2. プロダクトの状況
   3. 失敗談と解決方法
   3-1. コンポーネントおばけ
   3-2. デザイン / 開発 のすれちがい
   3-3. 絶対レンダリングするマン
   4. おわりに
   

   View Slide

5. 5
   Copyright © 2023 Bitkey Inc. All right reserved.
   2. プロダクトの状況
   

   View Slide

6. 6
   Copyright © 2023 Bitkey Inc. All right reserved.
   ■ 概要
   賃貸管理会社向けの管理画面 (web) の開発
   ■ 技術
   フロントエンド：React × Typescript
   バックエンド：Node.js × Typescript
   ※1エンジニアがフロント / バックエンド両方実装
   ■ 変遷
   < 2019-2020年 >
   ・少人精鋭で属人的に開発
   ・デザインは一部画面のみで、各開発が適宜実装
   ・React / Typescriptの開発経験者ゼロ
   < 2021-2023年 >
   ・徐々にメンバー増え、業務委託と一緒に開発
   ・デザイナーも増え、デザイン->実装のプロセスに
   2. プロダクトの状況
   < 2023.01時点 >
   ・社内エンジニア4-5人 + 業務委託
   ・プロダクト規模は、以下の通り
   　　→　テーブル：400程度
   　　→　API：500〜1000程度
   　　→　ソース：100万行程度
   プロダクト説明
   

   View Slide

7. 7
   Copyright © 2023 Bitkey Inc. All right reserved.
   ■ 概要
   賃貸管理会社向けの管理画面 (web) の開発
   ■ 技術
   フロントエンド：React × Typescript
   バックエンド：Node.js × Typescript
   ※1エンジニアがフロント / バックエンド両方実装
   ■ 変遷
   < 2019-2020年 >
   ・少人精鋭で属人的に開発
   ・デザインは一部画面のみで、各開発が適宜実装
   ・React / Typescriptの開発経験者ゼロ
   < 2021-2023年 >
   ・徐々にメンバー増え、業務委託と一緒に開発
   ・デザイナーも増え、デザイン->実装のプロセスに
   2. プロダクトの状況
   < 2023.01時点 >
   ・社内エンジニア4-5人 + 業務委託
   ・プロダクト規模は、以下の通り
   　　→　テーブル：400程度
   　　→　API：500〜1000程度
   　　→　ソース：100万行程度
   プロダクト説明
   ビジネスの成長とともにプロダクトも大きくなり
   同時に人も増え始める
   プロダクトが大きくなり機能が増え、
   開発に携わる人が増えてたことで、
   いくつかの問題が顕在化し始める....
   

   View Slide

8. 8
   Copyright © 2023 Bitkey Inc. All right reserved.
   ■ 概要
   賃貸管理会社向けの管理画面 (web) の開発
   ■ 技術
   フロントエンド：React × Typescript
   バックエンド：Node.js × Typescript
   ※1エンジニアがフロント / バックエンド両方実装
   ■ 変遷
   < 2019-2020年 >
   ・少人精鋭で属人的に開発
   ・デザインは一部画面のみで、各開発が適宜実装
   ・React / Typescriptの開発経験者ゼロ
   < 2021-2023年 >
   ・徐々にメンバー増え、業務委託と一緒に開発
   ・デザイナーも増え、デザイン->実装のプロセスに
   2. プロダクトの状況
   < 2023.01時点 >
   ・社内エンジニア4-5人 + 業務委託
   ・プロダクト規模は、以下の通り
   　　→　テーブル：400程度
   　　→　API：500〜1000程度
   　　→　ソース：100万行程度
   プロダクト説明
   本発表では
   私たちが出会った失敗事例を題材に
   原因分析と解決方法を紹介します！
   

   View Slide

9. 9
   Copyright © 2023 Bitkey Inc. All right reserved.
   3. 失敗談と解決方法
   3-1. コンポーネントおばけ
   3-2. デザイン / 開発 のすれちがい
   3-3. 絶対レンダリングするマン
   

   View Slide

10. 10
    Copyright © 2023 Bitkey Inc. All right reserved.
    3. 失敗談と解決方法
    3-1. コンポーネントおばけ
    3-2. デザイン / 開発 のすれちがい
    3-3. 絶対レンダリングするマン
    

    View Slide

11. 11
    Copyright © 2023 Bitkey Inc. All right reserved.
    3-1. コンポーネントおばけ
    シーン
    少人数で開発していたが
    プロダクトも大きくなったので
    人を増やして複数人で開発できるように！
    【Before】
    【After】
    

    View Slide

12. 12
    Copyright © 2023 Bitkey Inc. All right reserved.
    開発者B：「デバイス一覧の画面を作りたい」
    開発者C：「一覧画面つくるならまるっとコンポーネ
    ントとして共通化してあるよ」
    開発者B：「やったー！早速使ってみよう！」
    開発者B：「今回の一覧画面は他の一覧画面とちょっと
    違くて右上にCSV登録のボタンが必要なんだよな...」
    開発者C：「共通のコンポーネントにオプションを追
    加して対応しよう！これで更に共通化ができたぞ！」
    シーン
    3-1. コンポーネントおばけ
    

    View Slide

13. 13
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    開発者D：「既にある入居者一覧の画面なんだけど、今
    入居中の人が一覧に表示されている場合だけ、右上に退
    去登録のボタンを出したいな！」
    開発者D：「よし共通コンポーネントを修正しよう！取
    得したデータからボタンの表示有無をチェックする関数
    を渡してボタンの表示を制御できるようにしよう！」
    3-1. コンポーネントおばけ
    

    View Slide

14. 14
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    開発者C：「デバイス一覧で項目ごとのソートが必要です！」
    開発者A：
    「共通コンポーネントにソート機能を追加しよう！」
    「.....あれ？？」
    「コンポーネントが肥大化していて修正つらいな...」
    3-1. コンポーネントおばけ
    

    View Slide

15. 15
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    ユーザー：
    「入居者一覧で退去登録ボタンが表示されませ
    ん...」
    開発者A：
    「やってしまった...」
    「デバイス一覧で修正したソート機能の影
    響だ...」
    開発者D：
    「特に入居者一覧での修正はしていないのですが...」
    3-1. コンポーネントおばけ
    

    View Slide

16. 16
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    ユーザー：
    「入居者一覧で退去登録ボタンが表示されませ
    ん...」
    開発者A：
    「やってしまった...」
    「デバイス一覧で修正したソート機能の影
    響だ...」
    開発者D：
    「特に入居者一覧での修正はしていないのですが...」
    3. コンポーネントおばけ
    コンポーネントおばけ
    

    View Slide

17. 17
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. 共通コンポーネントが肥大化しすぎて意図しない部分に影響がでてしまった
    a. 肥大化すると関連性の低い機能が「密結合」＝「影響を受けやすい状態」になりがち
    b. 「密結合」になると、意図しない不具合を誘発してしまう
    2. 機能修正時は低コストで実現可能なため既存のコンポーネントに追加修正しがち
    a. コンポーネントを分割とか考えずに簡単な追加修正で済ましてしまうシーンが多かった
    b. No1の共通コンポーネントの肥大化を助長してしまう
    原因
    3-1. コンポーネントおばけ
    

    View Slide

18. 18
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. 多くの機能が密結合となることのリスクの認識が甘かった
    a. プロダクトが複雑になってくればなるほど重要！
    2. コンポーネントが適切に分割された状態の維持が難しい / コストが高い
    a. 開発に携わる人が多ければ多いほど難しくなる
    b. 分割の方針が異なっていると各所で歪みがでてより扱いづらくなってしまう
    課題
    3-1. コンポーネントおばけ
    

    View Slide

19. 19
    Copyright © 2023 Bitkey Inc. All right reserved.
    解決方法①
    保守性の高い状態とするために 高凝集 / 低結合 の観点を理解する
    - 高凝集 / 低結合とは？
    - 凝集度：特定の責務に特化/集中している程度の指標 (高いほうが好ましいとされる)
    - 結合度：機能が分割 / 整理されているかを示す指標 (低いほうが好ましいとされる)
    - 書籍では？
    - 4章 コンポーネント開発 > 4.1 Atomic Design によるコンポーネント設計
    - 4.1.1 Presentational Component と Container Component
    3-1. コンポーネントおばけ
    

    View Slide

20. 20
    Copyright © 2023 Bitkey Inc. All right reserved.
    解決方法②
    コンポーネントの粒度のルール（Atomic Designなど）を定める
    - Atomic Designとは？
    - 分割の粒度や振る舞いについて複数人間で合意を得やすくするための指標
    - Atoms / Molecules / Organisms / Templates / Pages の5つに大きく分割する指標
    - 書籍では？
    - 4章 コンポーネント開発 > 4.1 Atomic Design によるコンポーネント設計 で概要記載
    - 6章 アプリケーション開発2〜実装〜 に具体的な実装例が記載
    3-1. コンポーネントおばけ
    

    View Slide

21. 21
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. 適切に分解されている状態を維持できることが重要
    a. React の強みの一つは、コンポーネント化して再利用性を高めることです
    b. ただし「なんでも共通化すればよい」というわけではありません、適切な分割が必要です
    c. 適切な分割の観点として「高凝集・低結合」が役に立ちます
    2. 複数人で開発する場合、同じ方針で開発を進めるためにも”ルール”が必要
    a. 複数人で開発すると認識が容易にずれてしまいます
    b. コンポーネントが適切に分割された状態を維持するためには、何かしらのルールが必要です
    c. Atomic Designなど一般的に知られているルールは新しく入ったメンバーも馴染みやすいです
    まなび
    3-1. コンポーネントおばけ
    

    View Slide

22. 22
    Copyright © 2023 Bitkey Inc. All right reserved.
    3. 失敗談と解決方法
    3-1. コンポーネントおばけ
    3-2. デザイン / 開発 のすれちがい
    3-3. 絶対レンダリングするマン
    

    View Slide

23. 23
    Copyright © 2023 Bitkey Inc. All right reserved.
    3-2. デザイン / 開発 のすれちがい
    シーン
    デザイナー：
    「入居契約一覧画面のデザイン作りました」
    「実装お願いします！」
    開発者：
    「ありがとうございます！実装します！」
    「実装終わったら確認おねがいします！」
    

    View Slide

24. 24
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    3-2. デザイン / 開発 のすれちがい
    〜 開発完了予定日2日前 〜
    開発者：
    「ふぅ！画面実装終わりました！」
    「確認お願いします！」
    デザイナー：
    「確認します！」
    「...すいません...入居者契約一覧のCSVダウンロードのボ
    タンが目立ちすぎるので色とサイズ調整お願いします」
    開発者：
    「承知です！修正します！」
    

    View Slide

25. 25
    Copyright © 2023 Bitkey Inc. All right reserved.
    〜 開発完了予定日前日 〜
    開発者：
    「よし！修正終わりました！(どや)」
    デザイナー：
    「.......。あの入居者一覧の退去予定登録ボタンの色とサイ
    ズも変更されているんすが...」
    「CSVダウンロードのボタンは例外的な対応の際に必要な
    機能なので、他のボタンと色とサイズを分けたいです...」
    開発者：
    「同じレイアウトのボタンだったので同じコンポーネント
    で実装してしまっている..」
    「別のコンポーネントに分けて実装し直すか...」
    シーン
    3-2. デザイン / 開発 のすれちがい
    

    View Slide

26. 26
    Copyright © 2023 Bitkey Inc. All right reserved.
    〜 開発完了予定日前日 〜
    開発者：
    「よし！修正終わりました！(どや)」
    デザイナー：
    「.......。あの入居者一覧の退去予定登録ボタンの色とサイ
    ズも変更されているんすが...」
    「CSVダウンロードのボタンは例外的な対応の際に必要な
    機能なので、他のボタンと色とサイズを分けたいです...」
    開発者：
    「同じレイアウトのボタンだったので同じコンポーネント
    で実装してしまっている..」
    「別のコンポーネントに分けて実装し直すか...」
    シーン
    3-2. デザイン / 開発 のすれちがい
    想定外の手戻りが完了予定日前日に発覚
    開発完了予定を厳守できず
    他チームにも迷惑をかけてしまうことに...
    

    View Slide

27. 27
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. デザイン時の要素の整理と、コンポーネント実装時の単位が異なっていた
    a. デザイナー目線での修正対象と開発者目線での修正対象が異なる可能性がある
    b. 予期せぬ手戻りが発生したり、実装を大きく修正する必要があるかもしれない
    2. 開発完了間近で手戻りが発生し、チーム内外含めて調整が難しくなってしまった
    a. 早期に検知できれば対応をうてる場合もあるが後期になるほど対応難易度があがる
    b. 検知が後期になるほど既に実装した部分の修正も必要となるかもしれない
    原因
    3-2. デザイン / 開発 のすれちがい
    

    View Slide

28. 28
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. デザインだけ見ても、デザイナーが行った要素の整理はわかない
    a. デザイナー / 開発者 間で整理に乖離があるとその後追加コストが発生するかもしれない
    2. 実装開始してからFB可能な状態となるまでのリードタイムが長い
    a. 長くなるほど不確実性が残り、また修正コストが大きくなるリスクをはらんでいる
    課題
    3-2. デザイン / 開発 のすれちがい
    

    View Slide

29. 29
    Copyright © 2023 Bitkey Inc. All right reserved.
    解決方法
    Storybook でコンポーネントを一覧化。早期FBを可能にする
    - Storybookとは？
    - UIコンポーネント開発向けの支援ツールで見た目や振る舞いを確認できる
    - デザイナーも開発中にUIコンポーネントの確認を容易にできるツール
    - 書籍では？
    - 4章 コンポーネント開発 > 4.3 Storybookを 使ったコンポーネント管理
    - 基本的な使い方を網羅
    3-2. デザイン / 開発 のすれちがい
    

    View Slide

30. 30
    Copyright © 2023 Bitkey Inc. All right reserved.
    解決方法
    Storybook でコンポーネントを一覧化。早期FBを可能にする
    - 早期FBを可能にすると....
    3-2. デザイン / 開発 のすれちがい
    

    View Slide

31. 31
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. Storybook はコンポーネントベースの開発を促進するための強力なツール
    a. コンポーネントの見た目振る舞いを容易に確認できる有用なツール
    b. 特にデザイナーなどエンジニア以外のメンバーも容易に確認できる点で価値が高い
    c. 早期FBを可能とすることで、より安定した開発の実現に寄与する
    2. デザイナーともコンポーネントについて共通の認識をもつことが重要
    a. 認識合わせた上で実装することでデザインの変更に伴う修正を最小限に抑えることが可能
    まなび
    3-2. デザイン / 開発 のすれちがい
    

    View Slide

32. 32
    Copyright © 2023 Bitkey Inc. All right reserved.
    3. 失敗談と解決方法
    3-1. コンポーネントおばけ
    3-2. デザイン / 開発 のすれちがい
    3-3. 絶対レンダリングするマン
    

    View Slide

33. 33
    Copyright © 2023 Bitkey Inc. All right reserved.
    3-3. 絶対レンダリングするマン
    シーン
    開発者A：
    「よし！開発するからテストデータを作るぞ！」
    「画面開いてタイトルを入力っと....」
    「....！？」
    「入力したテキストの画面への反映がめっちゃ遅くて、
    もっさりしている.......！？」
    「3ヶ月前はそんなことなかったのに...」
    「以前より登録可能な項目が増えているから、なにかの修
    正が影響しているのかな...」
    

    View Slide

34. 34
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    3-3. 絶対レンダリングするマン
    開発者A：
    「しょうがない...デバックしてみるか....」
    「....！？」
    「入力値を変更する度に、関係ないところもやたらとレン
    ダリング処理が実行されている....」
    「これが悪さをしていいそうだ...」
    

    View Slide

35. 35
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    3-3. 絶対レンダリングするマン
    〜3ヶ月前〜
    開発者B：
    「登録可能な項目を追加するぞ！とりあえず新しくコン
    ポーネント作って、stateも追加して...」
    〜2ヶ月前〜
    開発者C：
    「登録可能な項目を追加するぞ！とりあえず新しくコン
    ポーネント作って、stateも追加して...」
    〜1ヶ月前〜
    開発者D：
    「登録可能な項目を追加するぞ！とりあえず新しくコン
    ポーネント作って、stateも追加して...」
    

    View Slide

36. 36
    Copyright © 2023 Bitkey Inc. All right reserved.
    シーン
    3-3. 絶対レンダリングするマン
    〜3ヶ月前〜
    開発者B：
    「登録可能な項目を追加するぞ！とりあえず新しくコン
    ポーネント作って、stateも追加して...」
    〜2ヶ月前〜
    開発者C：
    「登録可能な項目を追加するぞ！とりあえず新しくコン
    ポーネント作って、stateも追加して...」
    〜1ヶ月前〜
    開発者D：
    「登録可能な項目を追加するぞ！とりあえず新しくコン
    ポーネント作って、stateも追加して...」
    常に実行される過剰なレンダリング
    ユーザーが体験の低下へ...
    

    View Slide

37. 37
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. レンダリングの最適化ができていなかった
    a. 複雑なstateやuseEffectを乱用されていた
    b. useMemo / useCallback などを活用しきれていない
    2. コンポーネントの構成が複雑化してしまっていた
    a. state管理がどのように実現されているかの把握が困難
    b. レンダリングの最適化の難易度が高くなってしまっていた
    原因
    3-3. 絶対レンダリングするマン
    

    View Slide

38. 38
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. React Hooksの特性を適切に活かした実装となっていなかった
    a. プロダクトが複雑になってくると挙動に影響がでやすい
    2. コンポーネントの構成が複雑でレンダリングの最適化が困難な状態となってしまっていた
    a. プロダクトが複雑 & 携わる人の増加によって誘発しやすくなっていた
    課題
    3-3. 絶対レンダリングするマン
    

    View Slide

39. 39
    Copyright © 2023 Bitkey Inc. All right reserved.
    解決方法①
    React Hooks の特性を理解してレンダリングを最適化する
    - React Hooksとは？
    - 関数コンポーネントの中で状態やライフサイクルを扱うための機能
    - 状態の変化に応じたレンダリングや再計算を制御することができる
    - 書籍では？
    - 3章 React/Next.jsの基礎 > 3.5 React Hooks (フック)
    - useState / useMemo / useEffect など各種Hooksの特性と使いどころが網羅
    3-3. 絶対レンダリングするマン
    

    View Slide

40. 40
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. 各種 React Hooksの特性 / 違い / 使い所 を理解するのは重要
    a. 動作する機能を実装するだけであれば深く理解せずとも実装は可能
    b. 機能が複雑になると歪が蓄積されユーザー体験に影響がではじめる
    2. 適切にコンポーネントが分解されている状態を維持できることはここでも重要
    a. コンポーネントの分割の仕方やコンポーネントの責務(どのstateに依存しているか)も重要
    b. コンポーネントが不必要に複雑で不釣り合いな責務を有している場合に問題となりやすい
    まなび
    3-3. 絶対レンダリングするマン
    

    View Slide

41. 41
    Copyright © 2023 Bitkey Inc. All right reserved.
    4. おわりに
    

    View Slide

42. 42
    Copyright © 2023 Bitkey Inc. All right reserved.
    1. コンポーネントおばけ
    a. 適切に分解されている状態を維持できることが重要
    b. 複数人で開発する場合、同じ方針で開発を進めるためにも”ルール”が必要
    2. デザイン / 開発 のすれちがい
    a. Storybook はコンポーネントベースの開発を促進するための強力なツール
    b. デザイナーともコンポーネントについて共通の認識をもつことが重要
    3. 絶対レンダリングするマン
    a. 各種 React Hooksの特性 / 違い / 使い所 を理解するのは重要
    b. 適切にコンポーネントが分解されている状態を維持できることはここでも重要
    まとめ
    4. おわりに
    

    View Slide

43. 43
    Copyright © 2023 Bitkey Inc. All right reserved.
    さいごに
    書籍には、私が経験したその他の失敗経験を回避するための知見が詰まっています
    どんな課題を解決するための知識/テクニックなのかを
    具体的にイメージすることで、より効果的に学習できると思っています
    私がお話した例はほんの一例に過ぎませんが、
    少しでも開発をする上でなにかしらの助けとなれば幸いです
    『TypeScriptとReact/Next.jsでつくる実践Webアプリケーション開発』
    まだ読んでない方はぜひ！
    4. おわりに
    

    View Slide

44. 44
    End of File
    Copyright © 2023 Bitkey Inc. All right reserved.
    

    View Slide