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

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

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

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

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

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

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万行程度プロダクト説明

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

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

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

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

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

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

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

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

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

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

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

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

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. コンポーネントおばけ

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

デザイン / 開発のすれちがいシーンデザイナー：「入居契約一覧画面のデザイン作りました」「実装お願いします！」開発者：「ありがとうございます！実装します！」「実装終わったら確認おねがいします！」

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

おわりに

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

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

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

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

More Decks by 株式会社ビットキー / Bitkey Inc.

Other Decks in Technology

Featured

Transcript