Tweet
Tweet

Slide 1

Slide 1 text

フロントエンドエンジニアが 変える現場のモデリング意識 2022/7/6 UGA @現場から学ぶモデル駆動の設計 デザイン・フロントエンドのモデリング事情

Slide 2

Slide 2 text

自己紹介 宇賀神 誠也（UGA @uggds） • 前職はSIer@TISでサーバーサイドメインのエンジニア • フロントエンドエンジニアに転身と同時に独立、 フリーランスで受託開発６年目 • 兼業で、現在スタートアップのCTOとしても活動中 スタートアップの方 受託開発で参画している方（数十人の中の１人） CTO CEO

Slide 3

Slide 3 text

人数が多いと意思決定はより難しい 受託開発で参画している方 さらに自分はパートナーという立場 権限もないし（責任もない）ボトムアップでやっていくしかない

Slide 4

Slide 4 text

本日の話 そんな立場でありながら 現場になかったモデリング意識を持ってもらおうと活動をした話 モデル

Slide 5

Slide 5 text

広義のDDDかも？ ”That is the goal of domain-driven design.” - 「Domain Modeling Made Functional」 Kindle版 p23

Slide 6

Slide 6 text

フロントエンドって画面表示するだけでは？ という誤解 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった 画面にはユーザーの関心事が複雑に存在している 「表示するだけ」では語れない要素が多い

Slide 7

Slide 7 text

フロントエンドって画面表示するだけでは？ という誤解 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった 画面にはユーザーの関心事が複雑に存在している

Slide 8

Slide 8 text

フロントエンドが解決したいユーザーの関心事 1. ユーザーが想定した表示をする 2. ユーザーが目的のものを見つけることができる 3. ユーザーが想定した操作ができる 4. ユーザーが想定した状態遷移をする $MJDLNF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 Ϣʔβʔ

Slide 9

Slide 9 text

$MJDLNF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 従来は UI設計だけだった 1. ユーザーが想定した表示をする 2. ユーザーが目的のものを見つけることができる 3. ユーザーが想定した操作ができる 4. ユーザーが想定した状態遷移をする Ϣʔβʔ フロントエンドが解決したいユーザーの関心事

Slide 10

Slide 10 text

$MJDLNF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 JSライブラリの進化で ロジックがかけるようになり 状態遷移も含めて フロントエンドの関心事になった 1. ユーザーが想定した表示をする 2. ユーザーが目的のものを見つけることができる 3. ユーザーが想定した操作ができる 4. ユーザーが想定した状態遷移をする Ϣʔβʔ フロントエンドが解決したいユーザーの関心事

Slide 11

Slide 11 text

$MJDLNF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 Ϣʔβʔ フロントエンドが解決したいユーザーの関心事 サーバー API 例えばSPAなどではバックエンドが表示を補完するため だけに存在するような場合もあり フロントエンドが解決する領域が広く複雑になった => UI設計だけでなくソフトウェア設計が必要

Slide 12

Slide 12 text

フロントエンドって画面表示するだけでは？ という誤解 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった 画面にはユーザーの関心事が複雑に存在している

Slide 13

Slide 13 text

使用するライブラリによる画面設計への影響 $MJDLNF 想定した表示 目的のものを 見つける 想定した操作 想定した遷移 ソフトウェア設計 => ReactやVueといったライブラリ UI設計の部分はライブラリの 仕様や思想の影響をうける Ϣʔβʔ

Slide 14

Slide 14 text

コンポーネント指向のUI開発 コンポーネントという単位でUIを組み立てる手法 JS HTML JS JS JS JS CSS HTML CSS JS HTML CSS JS 従来の方法 ライブラリ利用

Slide 15

Slide 15 text

コンポーネント指向のメリット 高凝集・疎結合な単位でUIをコンポーネント分割しておくと メンテナンスコストが下げられる そのためコンポーネントはフロントエンドにとって重要なモデリング対象 ページA コンポーネント ページB

Slide 16

Slide 16 text

コンポーネント分割の注意点 どの粒度でも コンポーネント分割できるが 「見た目の粒度」で分割すると失敗する Atomic Design Atomic Designという有名な分割手法 があり、画面を５つの粒度で分割する 概念があるが 何を原子？分子？有機体？にするか など解釈がまちまち かえってコミュニケーションコストが 高くなったり、無駄なものを作る可能 性がある

Slide 17

Slide 17 text

「見た目の粒度」だけの分割は失敗する Atomic Design だけではうまくいかず やめる現場が増えてきた印象 「見た目の粒度」だけではないコンポーネント分割が重要！

Slide 18

Slide 18 text

「見た目の粒度」以外に意味をつける GUI的に関心のある 単一要素 GUI的に関心のある 複数要素 ドメインモデル こちらが意図した 箇所に誘導する ユーザが求める情報 をページにまとめる 原子 分子 有機体 テンプレート ページ サービスや業務に関心を持たない GUI要素のまとまり （リンク、ボタン、フォーム） サービスや業務に関心を持つ ドメイン要素のまとまり ちゃんと意味づけをすれば Atomic Design でもやれる

Slide 19

Slide 19 text

「見た目の粒度」以外に意味をつける GUI的に関心のある 単一要素 GUI的に関心のある 複数要素 ドメインモデル こちらが意図した 箇所に誘導する ユーザが求める情報 をページにまとめる サービスや業務に関心を持たない GUI要素のまとまり （リンク、ボタン、フォーム） サービスや業務に関心を持つ ドメイン要素のまとまり そしたらもう Atomic Design じゃなくて良くない？ GUI モデル ページ レイアウト

Slide 20

Slide 20 text

Atomic Designを使わないコンポーネント分割の話 本日座談会でいらっしゃる樋口さんが 2019年 WEB+DB PRESS VOL.112 で書かれている コンポーネント設計とほぼ同じ考え

Slide 21

Slide 21 text

フロントエンドエンジニアもモデリングする サービスや業務に関心を持たない GUI要素のまとまり （リンク、ボタン、フォーム） サービスや業務に関心を持つ ドメイン要素のまとまり モデル サービスや業務

Slide 22

Slide 22 text

ここまでのおさらい 最近のフロントエンドは • ソフトウェア設計も必要になった • 利用するライブラリによってはコンポーネント指向で開発するようになった • コンポーネントのモデリングが開発の肝になる モデル

Slide 23

Slide 23 text

ドメインエキスパートとデザイナーとの協業問題 フロントエンドはドメインエキスパートとデザイナーの成果物がインプット になるが、彼らの関心事が ページの見た目 であることが多い そもそもモデリングしないでUI設計を行なっている場合があり 開発が思うように進まないという問題がある ϑϩϯτΤϯυΤϯδχΞ σβΠφʔ υϝΠϯΤΩεύʔτ モデル

Slide 24

Slide 24 text

本題 モデル このような現場でモデリング意識を持ってもらうために活動した話

Slide 25

Slide 25 text

登場人物 ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ

Slide 26

Slide 26 text

活動その１：フロントエンドの開発を改善する ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ

Slide 27

Slide 27 text

そのサイトは１０年以上前から存在していて着任時は超レガシーだった • 静的ソースはGitなどのバージョン管理されておらず、ZIPファイルにして サーバーサイドに渡す • JSPにロジックがぐちゃぐちゃあって読みづらい • ボタン等は『画像』で種類がたくさんある 着任時のサイトは超レガシーだった https://www.webcreatorbox.com/tech/css-sprite 例）イメージ図 ਃ͠ࠐΉʢແྉʣ ਃ͠ࠐΉ ແྉ 申し込む（無料） ＞

Slide 28

Slide 28 text

JSPの中身の例※再現コード

Slide 29

Slide 29 text

このような状態でページ単位で開発がされていた 施策ごとにページがつくられたり修正される ϓϥϯφʔ σβΠφʔ '& ϓϥϯφʔ σβΠφʔ '& ϖʔδ" ϖʔδ#

Slide 30

Slide 30 text

ಉ͡Α͏ʹݟ͑Δ͕ɺ࣮૷͸ڞ௨Խ͞Ε͍ͯͳ͍ϖʔδ͕ྔ࢈͞ΕΔ 全部 に 修正したい プランナー FE ・1つ１つページの実装を 慎重に修正しないといけない ・仕様変更あったらやりなおしか？ ・作業漏れが起こりそう ・作業漏れがあったら我々の責任？ この状態で 従来のページ単位の開発の問題点

Slide 31

Slide 31 text

フロントエンド内の改善に尽力 • GitとCI/CDの導入 • ボタン等をHTMLとCSSでマークアップ • コンポーネント指向ライブラリの導入 • コンポーネント一覧化サービス（Storybook）の導入 このようなレガシーからモダンにする活動を５年かけて行なった

Slide 32

Slide 32 text

プランナー FE フロントエンドの開発効率が向上した バージョン管理で安心に、 コンポーネント指向で 変更が容易になった！ 全部 に 修正したい

Slide 33

Slide 33 text

活動その１：フロントエンドの開発を改善する ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR

Slide 34

Slide 34 text

活動その２：デザイナーを巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR

Slide 35

Slide 35 text

次の問題点 デザイナーはページ単位で納品 FEはそれを見てコンポーネント分割している σβΠφʔ ϑϩϯτΤϯυ ϓϩμΫτ σβΠϯ

Slide 36

Slide 36 text

コンポーネント増える問題 たとえば、 アコーディオンコンポーネント がたくさんできてしまう問題 • デザイン上の意図がある？ • あることを知らずに作った？ • なぜこの色？ などのコミニュケーションが多い

Slide 37

Slide 37 text

デザイナーにコンポーネント指向を理解してもらう

Slide 38

Slide 38 text

デザイナーとの共通言語を探す とわいえ先述した『コンポーネント指向』を エンジニア目線で説明してもデザイナーに馴染まない そこでデザイナー側のトレンドワードでもあった デザインシステム というものに注目して会話することにした

Slide 39

Slide 39 text

デザインシステムとは？ デザインを考えるとき これを追加すべきか？の ①意思決定をスムーズにする ʁ コンポーネントを整理して ②開発効率を良くする デザインに一貫性を持たせ ③ユーザー体験を良くする デザインシステムは以下の３つを解決する仕組み

Slide 40

Slide 40 text

デザインシステム本 何か実践ガイド的なものが欲しかったときに 以下の翻訳本が出版されたので、この本を拠り所にした

Slide 41

Slide 41 text

デザインシステム本に書かれていたこと ①そのプロダクトの目的と価値は何か？ Webサイトの対象ユーザーとその目的、ニーズ、動機を理解しよう！ ②デザインで解決したい課題は何か？ デザインで何を解決しようとしているのかを明らかにしよう！ ③デザイン原則 「らしさ」を表す指針となるシンプルなフレーズを定義しょう！ ④どうやって機能パターンを切り出すか 目的達成に向けて、主にどのような行動をユーザーに促したいかを 考え、どの粒度でパターンを分割をするか。 ⑤どうやって認知パターンを切り出すか 誰にどのように認知して欲しいかについて考える。 （華やかで洗練されたもの？、真面目な雰囲気？） さらに、それを実現する手段についても考える （手書き風？イラスト？写真？白黒？） ⑥共通言語とデザインパターンの共有方法 上記で考えた機能パターンと認知パターンをどうやって、チーム で共有するか

Slide 42

Slide 42 text

デザインシステム本に書かれていたこと ①そのプロダクトの目的と価値は何か？ Webサイトの対象ユーザーとその目的、ニーズ、動機を理解しよう！ ②デザインで解決したい課題は何か？ デザインで何を解決しようとしているのかを明らかにしよう！ ③デザイン原則 「らしさ」を表す指針となるシンプルなフレーズを定義しょう！ ④どうやって機能パターンを切り出すか 目的達成に向けて、主にどのような行動をユーザーに促したいかを 考え、どの粒度でパターンを分割をするか。 ⑤どうやって認知パターンを切り出すか 誰にどのように認知して欲しいかについて考える。 （華やかで洗練されたもの？、真面目な雰囲気？） さらに、それを実現する手段についても考える （手書き風？イラスト？写真？白黒？） ⑥共通言語とデザインパターンの共有方法 上記で考えた機能パターンと認知パターンをどうやって、チーム で共有するか エンジニアが読んでも面白く、 デザインシステムとシステム設計は通じるところがある！ と感じた

Slide 43

Slide 43 text

デザインシステム本の輪読会 この本のノウハウを デザイナーと フロントエンドエンジニアで共有したく 輪読会を開催 (2018年冬)

Slide 44

Slide 44 text

活動の成果 活動の成果として、 • デザインシステム本をベースにサイトの問題が議論できた • 週１でデザインシステム会を発足して、フロントエンドエンジニアと デザイナーが案件に対してあーだこーだ言いあってる場ができた • とりあえずモデルを共有することの重要性の目線はあったはず

Slide 45

Slide 45 text

活動その２：デザイナーを巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR CLEAR？

Slide 46

Slide 46 text

活動その２：デザイナーを巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR

Slide 47

Slide 47 text

それでもまだデザイナーと モデルが一致しない＼(^o^)／

Slide 48

Slide 48 text

しばらくしてまた、 アコーディオンが増えていく状態 しばらくはモデルが一致していい感じだった

Slide 49

Slide 49 text

なぜ？

Slide 50

Slide 50 text

原因 ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR

Slide 51

Slide 51 text

紙媒体出身のデザイナー ポスターなどの媒体で特有の知識をもつデザイナー キャンバス全体から細部をデザインしていくので UI部品から組み上げていくというプロセスはパラダイムシフトに近く コンポーネント指向は理解はできるが苦戦するとのこと 原因 • あのとき輪読会したデザイナーが全員離任した（啓蒙活動のやり直し） • 新任デザイナーが紙媒体、LP制作出身の人（自己紹介で言われた） ただ、啓蒙活動はやったハウがあるので彼らに対しては粘り強くもう一度説明すれば良い

Slide 52

Slide 52 text

プランナー側の問題 • 競合他社がこういうことをやっているから既存コンポーネントを再利用 ではなく、独自に「こうしたい」という主張が強い場合がある • 自分の受け持った案件のページを最適化したいと思っている つまり、デザイナーがわかってくれていてもデザインできない ϓϥϯφʔ σβΠφʔ ΤϯδχΞ

Slide 53

Slide 53 text

活動その３：プランナーも巻き込む ϑϩϯτΤϯυΤϯδχΞ ϓϥϯφʔ ʢυϝΠϯΤΩεύʔτʣ σβΠφʔ CLEAR

Slide 54

Slide 54 text

私のお気持ち DDDなどにもあるように 関係者全員でモデルを共有することが重要なのはわかっていたが デザイナーと一致させていればフロントエンド的には大丈夫かと思っていた やはりこの領域でも ビジネスサイドとの目線の一致が必要だった

Slide 55

Slide 55 text

思い出されるClean Architectureの一節 ビジネスマネージャは「構造」の重要性を評価できない。で も、そのために開発者が雇われている。 開発者には、機能の緊急性よりもアーキテクチャの重要性を強 く主張する責任がある。 「闘争」になるが、物事は常にこうして成し遂げられる。 優れた開発チームは企業にとって最善と思えるものを求めて 闘争する。それはマネージャーも同じだ。常に闘争する。 - Clean Architecture p45 アーキテクチャの戦い 闘争しないとダメか、、と感じた

Slide 56

Slide 56 text

フロントエンドエンジニアが介在して「闘う」 プランナー「構造化=自由にデザインできないもの」 ↓ プランナー「自由にデザインする=エンジニアの生産性が低下する」 結果的にプロジェクトが推進しないと理解してもらう ϓϥϯφʔ σβΠφʔ ΤϯδχΞ

Slide 57

Slide 57 text

闘争のシナリオ 1. あの頃のレガシーの状態から今の開発効率になるまでに行ってきた改善活動の話をする 2. パートナーという立場にもかかわらず、チームの生産性のために改善してきたことを伝え 味方だと思ってもらう 3. 今もまだこのチームのために改善したいことがあるが、今回ばかりは皆さんの協力なしに は解決できそうにないので、ぜひご協力を！といって拍手喝采 4. みんなの考えが変わって、めでたしめでたし 彼らは開発効率を気にしていないわけではないのでその手の話は聞いてくれそう それを汲んだシナリオを作った

Slide 58

Slide 58 text

やったこと 「〇〇サイト流、爆速フロントエンド開発」という大袈裟なタイトルにし、 FEの改善活動の歴史と思いを全７回に渡って説明

Slide 59

Slide 59 text

スライドの一部

Slide 60

Slide 60 text

スライドの一部 ○○ ○○

Slide 61

Slide 61 text

スライドの一部 プランナー

Slide 62

Slide 62 text

スライドの一部 プランナー

Slide 63

Slide 63 text

スライドの一部 プランナー

Slide 64

Slide 64 text

スライドの一部 プランナー

Slide 65

Slide 65 text

スライドの一部 ○○

Slide 66

Slide 66 text

スライドの一部

Slide 67

Slide 67 text

第一回の反応 全７回のプレゼン終了後、アンケートを実施 シナリオ通り拍手喝采

Slide 68

Slide 68 text

結果 全７回のプレゼン終了後、アンケートを実施 デザイナーとプランナーとFE合わせて13名 関係者全員が前向きな回答をしてくれた

Slide 69

Slide 69 text

アンケートの一部紹介 過去からどういった経緯で今の流れになっているのか、わかりやすく理解できました！ コンポーネント指向の考え方に関しては知っていても、施策単体で考えていた。 結果、UIなどについてもデザイナー、FEの方に都度確認を取る必要があって、 コミュニケーションが余計にかかっていたと再認識した。 ドメインモデルについては関係者の話し合いの中でドキュメントなりを残していいく必要がある と感じた。 再利用したい気持ちはあったが、意図的にそういう動きをしていたか？と言われるとしていな かった。今後は意識した上で、新規デザインを作る際は理由付けを明確にするべきだなと考えて おります。 〇〇案件では、これを全く理解していないくて色々ご迷惑をおかけしましたmm

Slide 70

Slide 70 text

視座が一致してきた感 プランナー 『結局、プロダクトの価値や原則が明文化されていなければ サイトらしさのデザインなんかできないよね』 Þ DDDのコアドメインやデザインシステム本の話 Þ もっと上のロールの人にアプローチする動きも生まれ チームとしてモデリングをやっていくぞ！という雰囲気になった プランナー 『デザインシステム本輪読会したい！』

Slide 71

Slide 71 text

まとめ

Slide 72

Slide 72 text

フロントエンドのモデリング事情 • フロントエンドにもソフトウェア設計が必要になった • コンポーネント指向で設計をするようになった • コンポーネントのモデリングが開発の肝 画面は表示するだけじゃない 設計にはドメインエキスパートだけでなく デザイナーもモデリングに巻き込む必要がある

Slide 73

Slide 73 text

変えた現場のモデリング意識について • デザイナーに対しては『デザインシステム』というのを共通言語にしたら 会話がスムーズになった • プランナーに対しては、開発効率の観点から非エンジニアでもわかるよう に説明したら思った以上にみんなの意識が変わってくれた

Slide 74

Slide 74 text

めでたし、めでたし UGA（@uggds）