フロントエンドエンジニアが変える現場のモデリング意識/modeling-awareness-changed-by-front-end-engineers

Transcript

1. フロントエンドエンジニアが 変える現場のモデリング意識 2022/7/6 UGA @現場から学ぶモデル駆動の設計 デザイン・フロントエンドのモデリング事情
2. 自己紹介 宇賀神 誠也（UGA @uggds） • 前職はSIer@TISでサーバーサイドメインのエンジニア • フロントエンドエンジニアに転身と同時に独立、 フリーランスで受託開発６年目 • 兼業で、現在スタートアップのCTOとしても活動中 スタートアップの方 受託開発で参画している方（数十人の中の１人） CTO CEO
3. 人数が多いと意思決定はより難しい 受託開発で参画している方 さらに自分はパートナーという立場 権限もないし（責任もない）ボトムアップでやっていくしかない
4. 本日の話 そんな立場でありながら 現場になかったモデリング意識を持ってもらおうと活動をした話 モデル
5. 広義のDDDかも？ ”That is the goal of domain-driven design.” - 「Domain Modeling Made Functional」 Kindle版 p23
6. フロントエンドって画面表示するだけでは？ という誤解 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった 画面にはユーザーの関心事が複雑に存在している 「表示するだけ」では語れない要素が多い
7. フロントエンドって画面表示するだけでは？ という誤解 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった 画面にはユーザーの関心事が複雑に存在している
8. フロントエンドが解決したいユーザーの関心事 1. ユーザーが想定した表示をする 2. ユーザーが目的のものを見つけることができる 3. ユーザーが想定した操作ができる 4. ユーザーが想定した状態遷移をする $MJDL
   NF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 Ϣʔβʔ
9. $MJDL
   NF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 従来は UI設計だけだった 1. ユーザーが想定した表示をする 2. ユーザーが目的のものを見つけることができる 3. ユーザーが想定した操作ができる 4. ユーザーが想定した状態遷移をする Ϣʔβʔ フロントエンドが解決したいユーザーの関心事
10. $MJDL
    NF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 JSライブラリの進化で ロジックがかけるようになり 状態遷移も含めて フロントエンドの関心事になった 1. ユーザーが想定した表示をする 2. ユーザーが目的のものを見つけることができる 3. ユーザーが想定した操作ができる 4. ユーザーが想定した状態遷移をする Ϣʔβʔ フロントエンドが解決したいユーザーの関心事
11. $MJDL
    NF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 Ϣʔβʔ フロントエンドが解決したいユーザーの関心事 サーバー API 例えばSPAなどではバックエンドが表示を補完するため だけに存在するような場合もあり フロントエンドが解決する領域が広く複雑になった => UI設計だけでなくソフトウェア設計が必要
12. フロントエンドって画面表示するだけでは？ という誤解 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった 画面にはユーザーの関心事が複雑に存在している
13. 使用するライブラリによる画面設計への影響 $MJDL
    NF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 ソフトウェア設計 => ReactやVueといったライブラリ UI設計の部分はライブラリの 仕様や思想の影響をうける Ϣʔβʔ
14. コンポーネント指向のUI開発 コンポーネントという単位でUIを組み立てる手法 JS HTML JS JS JS JS CSS HTML CSS JS HTML CSS JS 従来の方法 ライブラリ利用
15. コンポーネント指向のメリット 高凝集・疎結合な単位でUIをコンポーネント分割しておくと メンテナンスコストが下げられる そのためコンポーネントはフロントエンドにとって重要なモデリング対象 ページA コンポーネント ページB
16. コンポーネント分割の注意点 どの粒度でも コンポーネント分割できるが 「見た目の粒度」で分割すると失敗する Atomic Design Atomic Designという有名な分割手法 があり、画面を５つの粒度で分割する 概念があるが 何を原子？分子？有機体？にするか など解釈がまちまち かえってコミュニケーションコストが 高くなったり、無駄なものを作る可能 性がある
17. 「見た目の粒度」だけの分割は失敗する Atomic Design だけではうまくいかず やめる現場が増えてきた印象 「見た目の粒度」だけではないコンポーネント分割が重要！
18. 「見た目の粒度」以外に意味をつける GUI的に関心のある 単一要素 GUI的に関心のある 複数要素 ドメインモデル こちらが意図した 箇所に誘導する ユーザが求める情報 をページにまとめる 原子 分子 有機体 テンプレート ページ サービスや業務に関心を持たない GUI要素のまとまり （リンク、ボタン、フォーム） サービスや業務に関心を持つ ドメイン要素のまとまり ちゃんと意味づけをすれば Atomic Design でもやれる
19. 「見た目の粒度」以外に意味をつける GUI的に関心のある 単一要素 GUI的に関心のある 複数要素 ドメインモデル こちらが意図した 箇所に誘導する ユーザが求める情報 をページにまとめる サービスや業務に関心を持たない GUI要素のまとまり （リンク、ボタン、フォーム） サービスや業務に関心を持つ ドメイン要素のまとまり そしたらもう Atomic Design じゃなくて良くない？ GUI モデル ページ レイアウト
20. Atomic Designを使わないコンポーネント分割の話 本日座談会でいらっしゃる樋口さんが 2019年 WEB+DB PRESS VOL.112 で書かれている コンポーネント設計とほぼ同じ考え
21. フロントエンドエンジニアもモデリングする サービスや業務に関心を持たない GUI要素のまとまり （リンク、ボタン、フォーム） サービスや業務に関心を持つ ドメイン要素のまとまり モデル サービスや業務
22. ここまでのおさらい 最近のフロントエンドは • ソフトウェア設計も必要になった • 利用するライブラリによってはコンポーネント指向で開発するようになった • コンポーネントのモデリングが開発の肝になる モデル
23. ドメインエキスパートとデザイナーとの協業問題 フロントエンドはドメインエキスパートとデザイナーの成果物がインプット になるが、彼らの関心事が ページの見た目 であることが多い そもそもモデリングしないでUI設計を行なっている場合があり 開発が思うように進まないという問題がある ϑϩϯτΤϯυΤϯδχΞ σβΠφʔ υϝΠϯΤΩεύʔτ モデル
24. 本題 モデル このような現場でモデリング意識を持ってもらうために活動した話
25. 登場人物 ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ
26. 活動その１：フロントエンドの開発を改善する ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ
27. そのサイトは１０年以上前から存在していて着任時は超レガシーだった • 静的ソースはGitなどのバージョン管理されておらず、ZIPファイルにして サーバーサイドに渡す • JSPにロジックがぐちゃぐちゃあって読みづらい • ボタン等は『画像』で種類がたくさんある 着任時のサイトは超レガシーだった https://www.webcreatorbox.com/tech/css-sprite 例）イメージ図 ਃ͠ࠐΉʢແྉʣ ਃ͠ࠐΉ ແྉ 申し込む（無料） ＞
28. JSPの中身の例※再現コード
29. このような状態でページ単位で開発がされていた 施策ごとにページがつくられたり修正される ϓϥϯφʔ σβΠφʔ '& ϓϥϯφʔ σβΠφʔ '& ϖʔδ" ϖʔδ#
30. ಉ͡Α͏ʹݟ͑Δ͕ɺ࣮૷͸ڞ௨Խ͞Ε͍ͯͳ͍ϖʔδ͕ྔ࢈͞ΕΔ 全部 に 修正したい プランナー FE ・1つ１つページの実装を 慎重に修正しないといけない ・仕様変更あったらやりなおしか？ ・作業漏れが起こりそう ・作業漏れがあったら我々の責任？ この状態で 従来のページ単位の開発の問題点
31. フロントエンド内の改善に尽力 • GitとCI/CDの導入 • ボタン等をHTMLとCSSでマークアップ • コンポーネント指向ライブラリの導入 • コンポーネント一覧化サービス（Storybook）の導入 このようなレガシーからモダンにする活動を５年かけて行なった
32. プランナー FE フロントエンドの開発効率が向上した バージョン管理で安心に、 コンポーネント指向で 変更が容易になった！ 全部 に 修正したい
33. 活動その１：フロントエンドの開発を改善する ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR
34. 活動その２：デザイナーを巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR
35. 次の問題点 デザイナーはページ単位で納品 FEはそれを見てコンポーネント分割している σβΠφʔ ϑϩϯτΤϯυ ϓϩμΫτ σβΠϯ
36. コンポーネント増える問題 たとえば、 アコーディオンコンポーネント がたくさんできてしまう問題 • デザイン上の意図がある？ • あることを知らずに作った？ • なぜこの色？ などのコミニュケーションが多い
37. デザイナーにコンポーネント指向を理解してもらう
38. デザイナーとの共通言語を探す とわいえ先述した『コンポーネント指向』を エンジニア目線で説明してもデザイナーに馴染まない そこでデザイナー側のトレンドワードでもあった デザインシステム というものに注目して会話することにした
39. デザインシステムとは？ デザインを考えるとき これを追加すべきか？の ①意思決定をスムーズにする ʁ コンポーネントを整理して ②開発効率を良くする デザインに一貫性を持たせ ③ユーザー体験を良くする デザインシステムは以下の３つを解決する仕組み
40. デザインシステム本 何か実践ガイド的なものが欲しかったときに 以下の翻訳本が出版されたので、この本を拠り所にした
41. デザインシステム本に書かれていたこと ①そのプロダクトの目的と価値は何か？ Webサイトの対象ユーザーとその目的、ニーズ、動機を理解しよう！ ②デザインで解決したい課題は何か？ デザインで何を解決しようとしているのかを明らかにしよう！ ③デザイン原則 「らしさ」を表す指針となるシンプルなフレーズを定義しょう！ ④どうやって機能パターンを切り出すか 目的達成に向けて、主にどのような行動をユーザーに促したいかを 考え、どの粒度でパターンを分割をするか。 ⑤どうやって認知パターンを切り出すか 誰にどのように認知して欲しいかについて考える。 （華やかで洗練されたもの？、真面目な雰囲気？） さらに、それを実現する手段についても考える （手書き風？イラスト？写真？白黒？） ⑥共通言語とデザインパターンの共有方法 上記で考えた機能パターンと認知パターンをどうやって、チーム で共有するか
42. デザインシステム本に書かれていたこと ①そのプロダクトの目的と価値は何か？ Webサイトの対象ユーザーとその目的、ニーズ、動機を理解しよう！ ②デザインで解決したい課題は何か？ デザインで何を解決しようとしているのかを明らかにしよう！ ③デザイン原則 「らしさ」を表す指針となるシンプルなフレーズを定義しょう！ ④どうやって機能パターンを切り出すか 目的達成に向けて、主にどのような行動をユーザーに促したいかを 考え、どの粒度でパターンを分割をするか。 ⑤どうやって認知パターンを切り出すか 誰にどのように認知して欲しいかについて考える。 （華やかで洗練されたもの？、真面目な雰囲気？） さらに、それを実現する手段についても考える （手書き風？イラスト？写真？白黒？） ⑥共通言語とデザインパターンの共有方法 上記で考えた機能パターンと認知パターンをどうやって、チーム で共有するか エンジニアが読んでも面白く、 デザインシステムとシステム設計は通じるところがある！ と感じた
43. デザインシステム本の輪読会 この本のノウハウを デザイナーと フロントエンドエンジニアで共有したく 輪読会を開催 (2018年冬)
44. 活動の成果 活動の成果として、 • デザインシステム本をベースにサイトの問題が議論できた • 週１でデザインシステム会を発足して、フロントエンドエンジニアと デザイナーが案件に対してあーだこーだ言いあってる場ができた • とりあえずモデルを共有することの重要性の目線はあったはず
45. 活動その２：デザイナーを巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR CLEAR？
46. 活動その２：デザイナーを巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR
47. それでもまだデザイナーと モデルが一致しない＼(^o^)／
48. しばらくしてまた、 アコーディオンが増えていく状態 しばらくはモデルが一致していい感じだった
49. なぜ？
50. 原因 ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR
51. 紙媒体出身のデザイナー ポスターなどの媒体で特有の知識をもつデザイナー キャンバス全体から細部をデザインしていくので UI部品から組み上げていくというプロセスはパラダイムシフトに近く コンポーネント指向は理解はできるが苦戦するとのこと 原因 • あのとき輪読会したデザイナーが全員離任した（啓蒙活動のやり直し） • 新任デザイナーが紙媒体、LP制作出身の人（自己紹介で言われた） ただ、啓蒙活動はやったハウがあるので彼らに対しては粘り強くもう一度説明すれば良い
52. プランナー側の問題 • 競合他社がこういうことをやっているから既存コンポーネントを再利用 ではなく、独自に「こうしたい」という主張が強い場合がある • 自分の受け持った案件のページを最適化したいと思っている つまり、デザイナーがわかってくれていてもデザインできない ϓϥϯφʔ σβΠφʔ ΤϯδχΞ
53. 活動その３：プランナーも巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR
54. 私のお気持ち DDDなどにもあるように 関係者全員でモデルを共有することが重要なのはわかっていたが デザイナーと一致させていればフロントエンド的には大丈夫かと思っていた やはりこの領域でも ビジネスサイドとの目線の一致が必要だった
55. 思い出されるClean Architectureの一節 ビジネスマネージャは「構造」の重要性を評価できない。で も、そのために開発者が雇われている。 開発者には、機能の緊急性よりもアーキテクチャの重要性を強 く主張する責任がある。 「闘争」になるが、物事は常にこうして成し遂げられる。 優れた開発チームは企業にとって最善と思えるものを求めて 闘争する。それはマネージャーも同じだ。常に闘争する。 - Clean Architecture p45 アーキテクチャの戦い 闘争しないとダメか、、と感じた
56. フロントエンドエンジニアが介在して「闘う」 プランナー「構造化=自由にデザインできないもの」 ↓ プランナー「自由にデザインする=エンジニアの生産性が低下する」 結果的にプロジェクトが推進しないと理解してもらう ϓϥϯφʔ σβΠφʔ ΤϯδχΞ
57. 闘争のシナリオ 1. あの頃のレガシーの状態から今の開発効率になるまでに行ってきた改善活動の話をする 2. パートナーという立場にもかかわらず、チームの生産性のために改善してきたことを伝え 味方だと思ってもらう 3. 今もまだこのチームのために改善したいことがあるが、今回ばかりは皆さんの協力なしに は解決できそうにないので、ぜひご協力を！といって拍手喝采 4. みんなの考えが変わって、めでたしめでたし 彼らは開発効率を気にしていないわけではないのでその手の話は聞いてくれそう それを汲んだシナリオを作った
58. やったこと 「〇〇サイト流、爆速フロントエンド開発」という大袈裟なタイトルにし、 FEの改善活動の歴史と思いを全７回に渡って説明
59. スライドの一部
60. スライドの一部 ◦◦ ◦◦
61. スライドの一部 プランナー
62. スライドの一部 プランナー
63. スライドの一部 プランナー
64. スライドの一部 プランナー
65. スライドの一部 ◦◦
66. スライドの一部
67. 第一回の反応 全７回のプレゼン終了後、アンケートを実施 シナリオ通り拍手喝采
68. 結果 全７回のプレゼン終了後、アンケートを実施 デザイナーとプランナーとFE合わせて13名 関係者全員が前向きな回答をしてくれた
69. アンケートの一部紹介 過去からどういった経緯で今の流れになっているのか、わかりやすく理解できました！ コンポーネント指向の考え方に関しては知っていても、施策単体で考えていた。 結果、UIなどについてもデザイナー、FEの方に都度確認を取る必要があって、 コミュニケーションが余計にかかっていたと再認識した。 ドメインモデルについては関係者の話し合いの中でドキュメントなりを残していいく必要がある と感じた。 再利用したい気持ちはあったが、意図的にそういう動きをしていたか？と言われるとしていな かった。今後は意識した上で、新規デザインを作る際は理由付けを明確にするべきだなと考えて おります。 〇〇案件では、これを全く理解していないくて色々ご迷惑をおかけしましたmm
70. 視座が一致してきた感 プランナー 『結局、プロダクトの価値や原則が明文化されていなければ サイトらしさのデザインなんかできないよね』 Þ DDDのコアドメインやデザインシステム本の話 Þ もっと上のロールの人にアプローチする動きも生まれ チームとしてモデリングをやっていくぞ！という雰囲気になった プランナー 『デザインシステム本輪読会したい！』
71. まとめ
72. フロントエンドのモデリング事情 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった • コンポーネントのモデリングが開発の肝 画面は表示するだけじゃない 設計にはドメインエキスパートだけでなく デザイナーもモデリングに巻き込む必要がある
73. 変えた現場のモデリング意識について • デザイナーに対しては『デザインシステム』というのを共通言語にしたら 会話がスムーズになった • プランナーに対しては、開発効率の観点から非エンジニアでもわかるよう に説明したら思った以上にみんなの意識が変わってくれた
74. めでたし、めでたし UGA（@uggds）