フロントエンドエンジニアが変える現場のモデリング意識/modeling-awareness-changed-by-front-end-engineers

by uggds

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

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）