エンタープライズにおける画面設計_開発のコツ.pdf

Transcript

1. FutureCon 2022 エンタープライズにおける画面設計・開発のコツ
2. エンタープライズにおける画面設計・開発のコツ Future Tech Conference 2022 Summer Shoko Kashiwagi Copyright ©2022 by Future Corporation
3. 柏木 祥子（Shoko Kashiwagi） 出身：熊本 経歴：神戸大学国際文化学部 卒 2017年9月Future入社（6年目） 所属：1~4年目 アパレル系プロジェクト【React】 5年目 EC系プロジェクト【Ruby on Rails】 Now!→ 新人研修リーダー 趣味：ピアノ、コーヒー、Netflix
4. Agenda 本セッションの目的とゴール 基幹システムとそうでないシステムの 画面開発における共通点、違い Ⅰ.共通点 Ⅱ.違い 画面設計・開発において考慮が漏れがちな ポイントとその対策 Ⅰ.設計 Ⅱ.開発 さいごに 01 02 03 05 04 Reactでの開発について Ⅰ.Reactを使うメリット Ⅱ.ハマりどころと教訓 Copyright ©2022 by Future Corporation
5. Agenda 本セッションの目的とゴール 基幹システムとそうでないシステムの 画面開発における共通点、違い Ⅰ.共通点 Ⅱ.違い 画面設計・開発において考慮が漏れがちな ポイントとその対策 Ⅰ.設計 Ⅱ.開発 さいごに 01 02 03 05 04 Reactでの開発について Ⅰ.Reactを使うメリット Ⅱ.ハマりどころと教訓 Copyright ©2022 by Future Corporation
6. 01 本セッションの目的とゴール 対象 エンタープライズの画面設計、開発に初めて触れる人 目的 エンタープライズの画面開発において柏木が大事だと思うポイントを伝える ゴール 画面の設計や開発の際にこのセッションの内容を思い出し、ヒントにしていただく お話ししないこと Reactの具体的な機能の紹介、実装方法 Copyright ©2022 by Future Corporation
7. Agenda 本セッションの目的とゴール 基幹システムとそうでないシステムの 画面開発における共通点、違い Ⅰ.共通点 Ⅱ.違い 画面設計・開発において考慮が漏れがちな ポイントとその対策 Ⅰ.設計 Ⅱ.開発 さいごに 01 02 03 05 04 Reactでの開発について Ⅰ.Reactを使うメリット Ⅱ.ハマりどころと教訓 Copyright ©2022 by Future Corporation
8. 企業が自分たちのビジネスを行うために必須となる業務で 使用するシステムのことを指します。 商品の販売業務や在庫管理、会計などさまざまな業務に使用する 重要なデータを扱うため、正確性や情報の鮮度がクリティカルに求められます。 ※「そうでないシステム」とは、私が携わったような、特定の業務領域を対象とする 比較的規模の小さいシステムを想定しています。 「基幹システム」とは Copyright ©2022 by Future Corporation
9. 02 基幹システムとそうでないシステムの画面開発における共通点、違い Ⅰ. 共通点 Copyright ©2022 by Future Corporation ◼ せっかく作っても、業務で使われなかったら意味がない ◼ 「どうやって使うか」が自分たちも腹落ちしていないままだと顧客との認識がどんどんずれる ◼ 業務で使うという前提があるので、見た目より機能が重視されるように感じる 顧客が本当にほしい機能になっているか ◼ 業務によっては大量のデータを扱う場面が日常的にある ◼ 非機能要件はたくさんあるが、とくに1日にどのくらいのデータをどの頻度で扱うか、 それに耐える動きになっているかは画面開発でも必要 ◼ これを全然考えずに作ってボリュームテストして気付くと手戻りとして大きい 機能で扱うデータ量×早さが求められるレベルに達しているか 顧客の業務改革に必要な変更であるかという視点で、以下の観点を大事にしていると感じます
10. 業務をシステムに 落とし込むまで データの密度 Copyright ©2022 by Future Corporation 基幹系システム（刷新） そうでないシステム（構築） ◼ すでに行われている業務があり、 そこを新しく変更し、データに表す ◼ 「本当にその業務、データがこの場面で必要か？」 の目線がなければ、今やっていることの 二の舞になってしまう ◼ 領域の異なる業務でも密につながっている → データとデータのつながりが密である → 1機能の影響範囲が大きい ◼ 設計、開発時に考慮すべき影響範囲が 比較的大きいと感じる → データパターンの網羅性が重要 業務をシステムに落とし込むまで、またデータの密度が両者で大きく異なる点だと感じています ◼ これまで手作業で行っていた業務を システムで実現する ◼ 実際に機能を使われるところをより具体的に イメージしながら進める必要がある ◼ 特定の業務領域のユーザーを対象とする → データ間のつながりが 基幹システムほど密ではない ◼ 業務が決まりきっていないため、 システムを使ううちに新しいデータも必要になる → 1つのデータ種の拡張性が重要 02 基幹システムとそうでないシステムの画面開発における共通点、違い Ⅱ. 違い
11. Agenda 本セッションの目的とゴール 基幹システムとそうでないシステムの 画面開発における共通点、違い Ⅰ.共通点 Ⅱ.違い 画面設計・開発において考慮が漏れがちな ポイントとその対策 Ⅰ.設計 Ⅱ.開発 さいごに 01 02 03 05 04 Reactでの開発について Ⅰ.Reactを使うメリット Ⅱ.ハマりどころと教訓 Copyright ©2022 by Future Corporation
12. Copyright ©2022 by Future Corporation システムが扱う業務領域に関わらず、 イレギュラーをどう扱うか、という考慮が抜けがちになっていました 03画面設計・開発において考慮が漏れがちなポイントとその対策 Ⅰ. 設計 画面に表示するメッセージの表示文言 ダイアログやアラートなど、何らかの操作に対する反応の部分 同時更新したときの挙動 先勝ち/後勝ちのいずれか、また、API/画面どのようにハンドリングするか 認証・認可の制御 この権限は想定通りの挙動となるが、この権限だとうまくいかない、など いずれも開発時に「決められていなかった！」と気付く
13. 画面に表示する メッセージの表示文言 同時更新したときの 挙動 認証・認可の制御 Copyright ©2022 by Future Corporation いずれの場合も、実際に使う場面やその業務の頻度を想定して すり合わせを行うことが大切だと思います 03画面設計・開発において考慮が漏れがちなポイントとその対策 Ⅰ. 設計 困った出来事の例 対策 ◼ 場合によってユーザーにとってほしいアクションが 変わるが、パターンを詳細に決め切れておらず、 開発時に確認を行うことになってしまった ◼ 同時に更新してしまった場合どのような挙動と なるべきかを考慮できておらず、内部で 検討する際テーブル設計まで再検討 機能を使用する場面や頻度を想定して ユーザーと仕様のすり合わせを行う ◼ このエラーが出たらこういうメッセージにする、という パターンを機能ごとに定義する ◼ 同時編集が多発するため一度APIで 最新のデータを問い合わせる ◼ 担当する画面のどの要素単位で制御を かけるべきか、誰が何をできるべきかを、 画面イメージをもとにすり合わせる など、、 ◼ 誰がどこまでできるべきか、という要件を 詳細に詰めずに開発に入ってしまったため、 後から権限制御を入れる際にリファクタリングが 必要になってしまう
14. データのイレギュラーパターン 決まったデータで開発していると表示崩れが発生する、など ページング時の挙動 大量データの検索の際、初期表示は想定通りだが、次だとパラメータがうまく渡せていなかった、など APIのHTTPエラーのハンドリング ハンドリングが機能ごとにばらばらになってしまう エラーハンドリングの方針 データ的にイレギュラー＝業務としてもイレギュラー の前提が保証されているか？ Copyright ©2022 by Future Corporation ここまで考慮していればよかった、と後悔してきたポイントはこちらです 03画面設計・開発において考慮が漏れがちなポイントとその対策 Ⅱ. 開発 いずれもテスト時に「考慮していなかった！」と気付く
15. Copyright ©2022 by Future Corporation データの イレギュラーパターン ページング時の挙動 困った出来事の例 対策 ◼ 開発時に業務で主に見るデータのみを加工した テストデータを使用していたため、文字列の長さや 表記が特殊なデータだと画面表示が崩れてしまう ◼ 開発時に少量のテストデータで開発していたため、 大量データがある場合のページングやスクロール時 実装漏れがあることに気付くのが遅れた ◼ 開発前に単体テストのケースを洗い出しておき、 開発時に考慮すべきチェックリストとして使う。 ◼ 大量のデータを使って開発を行う。 ◼ テスト自動化を行い、ページングの挙動を 確認観点として設ける。 APIのHTTPエラーの ハンドリング エラーハンドリングの 方針 ◼ 複数機能を複数人で同時に開発しており、 エラー時の挙動は同じであるにもかかわらず、 エラー表示用の類似したダイアログが複数できた ◼ データとして異常系だと考えてエラー表示を検討 していたが、業務的には発生しうるパターンなので 処理できるようにする必要があった ◼ 共通コンポーネントとして誰かが先に着手する。 ◼ インプット/アウトプットの形だけすり合わせを行い、 統合しやすいように開発を進める ◼ 設計時のデータパターンの洗い出し漏れがあれば、 違和感に気付いた時点ですり合わせを行う。 イレギュラーパターンへのアンテナを張ることと、気付いたときに周りを巻き込むことは 画面開発に限らず大事なことだと感じます 03画面設計・開発において考慮が漏れがちなポイントとその対策 Ⅱ. 開発
16. Agenda 本セッションの目的とゴール 基幹システムとそうでないシステムの 画面開発における共通点、違い Ⅰ.共通点 Ⅱ.違い 画面設計・開発において考慮が漏れがちな ポイントとその対策 Ⅰ.設計 Ⅱ.開発 さいごに 01 02 03 05 04 Reactでの開発について Ⅰ.Reactを使うメリット Ⅱ.ハマりどころと教訓 Copyright ©2022 by Future Corporation
17. Copyright ©2022 by Future Corporation ライブラリを組み合わせれば、 コンポーネントを量産し、 それっぽい画面を作ることが簡単にできる。 画面で本当にやりたいことや 機能の実現に頭を使うことに集中できる。 形になるまでが早い データ操作だけでなく、 要素の活性、非活性の制御や 色のコントロールまでなどの見た目まで Javascriptで扱うことができる。 やりたいことが柔軟にできる コミュニティが活発であるため、 自分でヒントを探しやすい。 自分がハマったことは誰かもハマっている。 情報を見つけやすい これまでReactを数年触ってみて特に下記が強みだなと感じています 04 Reactでの開発 Ⅰ. Reactを使うメリット
18. Copyright ©2022 by Future Corporation データ数、データ種は多くなると思って構える 画面のレンダリング負荷が致命的な欠点になることもあるが、後からデータの持ち方を変更するのは大変 コンポーネントは再利用する 再利用しやすい＝コンポーネントの粒度×どこまで呼び出し元に依存しないか 必要な時に必要な処理を適切に行う 各ライフサイクルのメソッドは使いこなせた者勝ち 自分が開発して苦労した、また頭に入れておくべきだったポイントは3つあります 04 Reactでの開発 Ⅱ. ハマりどころと教訓
19. データ数、データ種は 多くなると思って構える コンポーネントは 再利用する 必要な時に 必要な処理を 適切に行う Copyright ©2022 by Future Corporation ハマった出来事 対策 ◼ データが増えたことで画面のレンダリング負荷が 高まり、ユーザーから「遅すぎる」と問い合わせ ◼ 子コンポーネント（データ増幅部分）から 親のonChange()メソッドを呼び出していた ◼ 共通コンポーネントとしてダイアログを作ったが、 機能ごとに操作や表示したいデータが変わり、 Stateの渡し方が複雑になってしまった ◼ 類似したダイアログがたくさんできてしまった ◼ useEffect()の中でAPIを実行し取得した値を Stateに初期値として設定したいが、できない ◼ useEffect()の条件をセットし、条件によって API実行。Stateの更新タイミングを統一 自分が開発して苦労した、また頭に入れておくべきだったポイントは3つあります 04 Reactでの開発 Ⅱ. ハマりどころと教訓 ◼ フロントで持つデータ構造はメンテしやすい、 かつシンプルなものにする ◼ 粒度を分けて共通コンポーネント群を作成する 例:ダイアログ > ヘッダー/フッター > ボタン ◼ 業務要件と関わるところはどうしても呼び出し元、 先に依存するため、切り離して考える ◼ 無理やりやっているな、と感じるときは うまく使いこなせていない/より快適な方法がある ◼ そう感じたら、公式ドキュメントに立ち返る
20. データ数、データ種は 多くなると思って構える コンポーネントは 再利用する 必要な時に 必要な処理を 適切に行う Copyright ©2022 by Future Corporation ハマった出来事 ユーザーにとって嬉しいこと ◼ データが増えたことで画面のレンダリング負荷が 高まり、ユーザーから「遅すぎる」と問い合わせ ◼ 子コンポーネント（データ増幅部分）から 親のonChange()メソッドを呼び出していた ◼ 共通コンポーネントとしてダイアログを作ったが、 機能ごとに操作や表示したいデータが変わり、 Stateの渡し方が複雑になってしまった ◼ 類似したダイアログがたくさんできてしまった ◼ useEffect()の中でAPIを実行し取得した値を Stateに初期値として設定したいが、できない ◼ useEffect()の条件をセットし、条件によって API実行。Stateの更新タイミングを統一 これができるようになると何が嬉しいかというと・・ 04 Reactでの開発 Ⅱ. ハマりどころと教訓 ◼ フロントで持つデータ構造はメンテしやすい、 かつシンプルなものにする ◼ 粒度を分けて共通コンポーネント群を作成する 例:ダイアログ > ヘッダー/フッター > ボタン ◼ 業務要件と関わるところはどうしても呼び出し元、 先に依存するため、切り離して考える ◼ 無理やりやっているな、と感じるときは うまく使いこなせていない/より快適な方法がある ◼ そう感じたら、公式ドキュメントに立ち返る 速度を気にせずストレスフリーに 画面を操作できる 変更がしやすいので、 機能追加が簡単にできる 開発スピードが上がるので システムが出来上がるのも早い
21. データ数、データ種は 多くなると思って構える コンポーネントは 再利用する 必要な時に 必要な処理を 適切に行う Copyright ©2022 by Future Corporation ハマった出来事 教訓 ◼ データが増えたことで画面のレンダリング負荷が 高まり、ユーザーから「遅すぎる」と問い合わせ ◼ 子コンポーネント（データ増幅部分）から 親のonChange()メソッドを呼び出していた ◼ 共通コンポーネントとしてダイアログを作ったが、 機能ごとに操作や表示したいデータが変わり、 Stateの渡し方が複雑になってしまった ◼ 類似したダイアログがたくさんできてしまった ◼ useEffect()の中でAPIを実行し取得した値を Stateに初期値として設定したいが、できない ◼ useEffect()の条件をセットし、条件によって API実行。Stateの更新タイミングを統一 変更を加えやすい状態にしておくことが、ユーザーのやりたいことの実現につながると思います 04 Reactでの開発 Ⅱ. ハマりどころと教訓 ◼ フロントで持つデータ構造はメンテしやすい、 かつシンプルなものにする ◼ 粒度を分けて共通コンポーネント群を作成する 例:ダイアログ > ヘッダー/フッター > ボタン ◼ 業務要件と関わるところはどうしても呼び出し元、 先に依存するため、切り離して考える ◼ 無理やりやっているな、と感じるときは うまく使いこなせていない/より快適な方法がある ◼ そう感じたら、公式ドキュメントに立ち返る システムをツールとして ユーザーの業務を変えていく ▼ システムを使ってやりたいことも どんどん変わる ▼ 新しい要望から 本当にやりたいことを汲み取り 迅速にシステムに反映するために 変更しやすい状態を維持し続ける ために考えることが大切
22. Agenda 本セッションの目的とゴール 基幹システムとそうでないシステムの 画面開発における共通点、違い Ⅰ.共通点 Ⅱ.違い 画面設計・開発において考慮が漏れがちな ポイントとその対策 Ⅰ.設計 Ⅱ.開発 さいごに 01 02 03 05 04 Reactでの開発について Ⅰ.Reactを使うメリット Ⅱ.ハマりどころと教訓 Copyright ©2022 by Future Corporation
23. さいごに 技術をただ使うだけでなく、なぜその技術が必要なのかをキャッチアップすることが大切 これによってお客さんは何が嬉しいのか？業務とつなげて理解すれば使う幅が広がると思います。 システムの画面はユーザーが一番触れるところ。 作るまでに業務要件をどれほど正確に汲み取れるかで使いやすさが変わってくる 顧客がやりたいことが本当に実現できるようにするためには、 その業務はそもそも必要なのか？→XXのケースの時ZZという業務が必要、 だからこの画面でこの操作が必要、というように 自分の中で腹落ちしながら進めていく事が大事ではないかと思います。 Copyright ©2022 by Future Corporation これまでフロントエンドの設計、開発に関わってきて 大事だなと思うポイントを2つ挙げさせていただきます
24. Thank you for listening! Copyright ©2022 by Future Corporation