【レポ】フロントエンドにおける情報設計とDDD 座談会

2016年8月17日

株式会社chatboxエンジニアのショウノです。
先月開催されました「フロントエンドにおける情報設計とDDD座談会」についてのレポートです。

0. DDDとは
1. セッション内容
2. 座談会
3. さいごに

という構成になっていますが、少し長くなりますので、気になるところなどをかいつまんで読むのがいいかと思います。

0. DDDとは

 

複雑なドメインの設計はモデルベースで行うべき
大半のソフトウェアプロジェクトではシステムを実装するための特定の技術ではなくドメインそのものとドメインのロジックに焦点を置くべき

 

という「ドメイン駆動設計」というシステム開発の複雑さをシンプルにする設計思想らしいです。

業務アプリケーションでは一般的に「プレゼンテーション層」「ドメイン層」「データソース層」の3層に分けることができ、DDDで重要な「ドメイン層」とはユーザーの行う業務に直接的に関わる”実際にどんなことをするのか”というロジックを書く部分 みたいな感じです。
DDDとはユーザーがどんなことをするのか(ドメイン)というところを中心にシステムを開発していく という考えとなります。

参考サイト

ネスケラボさん、有限会社 システム設計 増田亨さんのスライドを参考にさせて頂きました!

1-1. DDD(ドメイン駆動設計)って何だろう?/きの子 (@aa7th) さん

ドメインって?

「ドメイン」を考えるときに大事なのが 開発者側ではなくユーザー側に立って考える ということ。

例えば「モンスターを捕まえて育てるゲーム」なら

  • モンスターを捕獲する
  • 戦って敵の陣地を奪える

といったことはドメインであり、

  • AR技術によってカメラに写った風景に合成される

ということは技術者側で考えることなのでドメインではないだろう、とのこと。

DDDで大事なユビキタス言語

上述の「モンスターのゲーム」を例にあげると

  • プレイヤー or トレーナー
  • 陣地 or ジム
  • 捕獲 or ゲット

というように似たような意味の言葉が考えられます。
ですが、サービス内で 同じ意味なのに違う言葉が使える「表記ゆれ」 が起こると作る側にもユーザー側にも混乱を招いてしまうことになりかねません。
そこで、 一つの言葉は同じ意味、一つの意味は同じ言葉 となるよう統一した言語「ユビキタス言語」を使うことが重要となるそうです。

DDD = 「言葉通りにプログラミングコードを落としこむ」

きの子さんの考えるDDDのポイントは ユーザー目線での思考と実際のコードを一致させる ということだそう。

DDDを採用すると変更に強くなる

 

モデルとコードが一致してないというねじれを防ぐ
途中参加のメンバーとも意識を統一しやすい

 

ねじれがあると「どこにコードが書いてあるのか」を探すだけでも時間がとられますが、DDDを採用すると「人間の思考に沿ったコード」になるので変更に強くなるらしい。
(とはいえモデルとコードを統一するのは簡単ではない)

1-2. フロントエンドはDDDの夢を見るか/yukieen(ゆきーん)さん

ゆきーんさんはご本人が関わったプロジェクトとCSS・javascriptについてお話されていました。
プロジェクトの概要は

  • コンシューマ向け転職支援サービス
  • 事業会社からの受託
  • エンジニアは大体リモート

だったそうです。

開発体制

最初はフロントはクライアントさんが作ると聞いていたそうですが、途中からフロントも作ることになったらしく
このことを予測せず作っていたためにドメインモデルのズレがでてくるようになったそうで

  • 支離滅裂なhtml
  • 「BEMってなに?」というcss
  • 他の人が触るのがこわいJS

というコードが出来上がってしまったらしいです。

反省点

  • サーバーサイド側のドメインモデルは間違ってなかった
  • ただ、フロント側にもドメインモデルは必要だった
  • 先に作っておけば早くフィードバックがかえってくる

開発体制(仕切り直し)

デザイナーさんが1人加わり、開発し直すことに。

改善内容の例

  • 名前を画面に表示する時に姓名分ける必要はないので、合わせてサーバー側も修正
  • プロフィール情報にTOEIC、TOEFLを含むことに初めは違和感を感じていたが、スキルシートのような形で用いられることが判明し納得

気付いたこと

  • htmlとサーバー側のコードを無理に合わせる必要はない
  • Modelの名前を適切に使用するとデザイナーさんにも内容が伝わりやすい
  • 動的に確認できるものをつくるとデザイナーさんに喜ばれる

CSSの難しさ

ドメインと違って横断的に考えないといけないので難しい(基本的に継承ベース、詳細度も難しい)

CSS設計のドメインについて考えてみると・・・

  • OOCSS

Structure:横断的
Skin:ドメインっぽいかも

  • SMACSS

Base、Layout、Moduleがドメインっぽいかも

フロント側とサーバー側で名前を統一してるほうがいい

  • ただし両者は担当者が違う事が多いのでコミュニケーションスキルが必要となる

理想と違う現実

  • CSSはいったん走りだすと、大規模リファクタリングが難しい。
  • 下手にスタイルをいじると破綻したりもする

おまけ

  • 中央寄せすごい大変

JavaScript

  • ドメインの登録状態を画面に表示する場合はサーバーサイドとの連携が大事
  • フェードイン、フェードアウトのような局所的なところはそこまで連携は必要なさそう

まとめ

 

フロントエンドにはフロントエンドのドメインモデルがある
HTMLに関しては「ドメインモデル構造 = アウトライン構造」という考え方ベースでよさそう
CSSはアウトライン構造と別にするべき

 

1-3. 情報アーキテクチャ(情報設計)/山下さん

情報設計(IA)についてのお話。
IAという言葉には下の2つの意味があるそうです。

  • 情報アーキテクチャ
  • インフォメーションアーキテクト

前者は「表現技術、学術」を指し、後者は「情報アーキテクチャを先行してる人」を指します。

IAで大事なこと

「わかりやすい」ようにするということ。

「わかりやすい」=「分かれる」 ということであり、情報を分別するのがポイントとなる。
「今日からはじめる情報設計」が情報設計の入門書としておすすめだそうです。

コンテンツの構成

目的 ▶ 要件 ▶ 情報設計 ▶ 骨格 ▶ 視覚デザイン

情報設計のエッセンス

1. 把握する

混乱を見極め、整理する。
混乱する主な要因は次の3つ。

 

情報過多
情報不足
不適切

 

これらを防ぐために使える整理の手段には次のようなものがある。

 

カテゴリ
アルファベット順
時間別
位置情報(駅構内図とか)
連続量(ランキングとか)

 

2. 意図作り

「◯◯という空気をつくる」のが大切。
次のようなものを意識することで「空気をつくる」ことができたりする。

 

語調を変える(送信/送るとか)
同義語の中から適切な選択をする(自動車/車/乗用車)

 

また、 メンタルモデル も意図づくりに大きく影響する。
メンタルモデルとは 物事の見方に影響を与える固定観念や暗黙の前提 を指す。
(色から国旗を連想するなど)

3. 構造化する

 

並列(少ない情報で有効):シーケンシャル(順序で変化する情報)
階層(大量の情報で有効):ハイパーテキスト(ぜんぜん違う情報間での行き来が可能)

 

といった構造パターンは理解しておくこと、そして分類基準を決めることが重要となる。
ただし国によって分類基準は違うことも抑えておくこと。

情報設計の使命

  • 難しさに立ち向かう
  • 適切な意図をつくりあげる

「分かりやすい」は当たり前であり、賞賛されることはない
でも 分かりやすいってすばらしい

2. 座談会

座談会の内容については本当にたくさんの話題が出たので完全な箇条書きです。
お許し下さい。

ドメインエキスパート = 業務内容に精通している人

開発者側が歩み寄るのが大事。

ユビキタス言語はルールではない

ユビキタス言語を作ったあとにお客様との認識のズレを確認したりして摺合せするのが大事。
いくらユビキタス言語として「ウインチ(例)」という言葉を使うと決めても、工場のおじさん達が普段「まきまき」とよんでいるなら伝わらないよねという話。

ユビキタス言語を翻訳デキる人は必ずいるか?

共通でユビキタス言語を使うようにしても他の言葉を使うお客様は一定数いたりする。
なので、それでも理解できるユビキタス言語翻訳者は必ず必要になってくる。

ユビキタス言語のルールをどうやってきめるか

結構政治ゲームじゃないか?
(開発をしたい企業基準とか・・・。)

DDDがちゃんとされている時のメリット

途中から入った人にも理解しやすい。
(コードが素直なので変更しやすい、名前なども混乱しない)

「プロジェクト」というのがどこまでを指すのか、も大事

リリースするまでか、など。
無理にDDDを取り入れようとすると学習コストがかかり、現場によっては難しいことも。

DDDと情報設計は同じか?

DDDは開発者にとってのわかりやすさであり、情報設計は使う人にとってのわかりやすさである。
対象者は違うが、手法は似てる。

お客様の「要望はない」は本当?

開発側が提示すれば「そういうこともできるんだ」という認識になり、要望が上がってくることもある。そういう提案などは喜んでもらえたりする。

クライアントさんに見てもらうことで失敗がすぐに見つかることもある

言語化できていない、というのはDDDに限ったことではない

「言語化」すると話が早く進むこともあるので心がけるべき。
お客さんの言語を汲み取ることが重要である。

できるだけ業務フローから整理するのが大切

それが本来のSIerでは?
発注が来た時点でそのシステムはすでにダメな状態であり、システムがダメということは現場もダメ。

フェーズを分割しすぎたら良くない気がする

業務の定義がちゃんと終わってるところはめったに無い。
でもSIerが上流に入るのはなかなか難しい。

フィードバック作業が長すぎるのは良くなさそう

DDDとは結局何なのか?

コードを綺麗にすること。
(コードスキルはそれなりに必要)

DDDや情報設計を目で簡単に伝えれるものはあるか?

動くものを実際に作るのもアリだが、紙に描くだけでも案外良い。
あまり要望がはっきりしてないクライアントには簡単なワイヤーモックを仕上げて提出してしまうと良い。
項目を考えるのも大事だが、作りながら進めるほうが先が見えてきたり「ちゃんと進んでいるんだな」をいう印象も与える。
逆に見た目が出来すぎていると過剰に期待されることもあるので、モックではテストデータを用いる等の工夫をするのが良い。

DDDはjava以外の言語でも使えるのか?

DDDを使うと可読性は上がるが、型のない言語(JSなど)では厳しい。

さいごに

上手に取り入れられると制作側もお客様側も幸せになれそうなDDD。
現場での経験が全然足りていない私にはわからない単語も出てきて少し難しく感じたものの、
先輩方の話を聞くことができる貴重な時間となりました。

いくら本で勉強したりしても、実際の現場では
「ユビキタス言語をきちんと使えば大丈夫だ!」
「各担当者が(サーバー側、フロント側など)各々ちゃんとしてたら大丈夫だ!」
なんてことはありえないので、学んだことを頭の片隅にいれつつ各担当者間やお客様側・制作制作でのズレが最小限になるようにコミュニケーションを取ることが大事なのかなぁ・・・と思いました。