ドメインモデルからUIデザインとページレイアウトを設計した話
この記事は SmartHR Advent Calendar 2019 21日目の記事です。
こんにちは。デザイナーの@tyoys00です。
初めてAdvent Calendarに参加します。これで私も立派なIT人材です。
UIデザインってなんだろう？
突然ですが、デザイナーのみなさんUIデザインしてますか？
してます？
では、UIデザインってなにをデザインすることなのでしょうか？ UIデザインってなんなのでしょう？
私は何もわかりません。デザイン、何もわからない…
私はこの1年上記のような「UIデザインとはなにを作っていることなのか？」ということばかり考えていた気がします。（そして、気づいたら年末になっていました…）。
結論から言うと、UIデザインとはデータベースやサーバーサイドで実装された構造とフロント側での視覚的な情報構造との対称性を設計することであるという考えに至っています。
この実装の構造と視覚的な情報構造との対称性を実現するには、ドメインモデルなどを参照しながらリバースエンジニアリングを行ってUIを設計すると良いのではないかと考えたので、今回は最近試したドメインモデルからUIとレイアウトを設計する方法についてお話ししていこうと思います。
リバースエンジニアリングとは？
まずは言葉の確認からです。
リバースエンジニアリングを調べるとwikipediaでは次のように定義されています。
リバースエンジニアリング（Reverse engineeringから。直訳すれば逆行工学という意味）とは、機械を分解したり、製品の動作を観察したり、ソフトウェアの動作を解析するなどして、製品の構造を分析し、そこから製造方法や動作原理、設計図などの仕様やソースコードなどを調査することを指す。
ソフトウェアの構造を分析して仕様やソースコードを調査することのようですね。
言うまでもないことですが、私たちデザイナーが開発に携わるデジタルプロダクトはソースコードの集合です。UIも実装されることでユーザーの目的を達成するためのインターフェイスとして初めて機能します。実装されなければそれは絵に描いた餅ですね。
ドメインモデルとは？
つづいて、ドメインモデル について調べるとみるとwikipediaでは次のように定義されています。
ドメインモデル（英: Domain model）は、システムに関わるさまざまな実体とそれらの関係を説明するシステムの概念モデルである。
（ドメインモデルの例）
「システムに関わるさまざま実体」と書かれていますが、ドメインモデルを参照する際にはこの実体という概念がとても重要だと思っています。
というのも、実体関連モデルでモデリングされる実体はコード上でクラスとして実装されます。クラスはOOUIなどの概念でよく出るオブジェクトと重なることが多いので、オブジェクトを特定する際にはドメインモデルのクラスから見つけ出すことができます。
ドメインモデル（実体関連モデル）から直接的にオブジェクトを捉えてリバースエンジニアリングができるのではないかと考えていたので実際に試してみました。
対象となる画面
今回対象とするのはSmartHRというプロダクトで書類のプレビューを表示するとある画面です。
（実際の画面から一部内容を変更しています）
この画面では、ユーザーが作成した書をPDFビューアで表示する領域と「その書類に紐づく情報のインプット領域とインプットされた内容を表示する領域が持たれています。
さらに、ユーザーのロールによって表示されるアクションが異なり、また書類のステータスによっても選択できるアクションが変化する設計になっています。
この画面では、書類オブジェクトに対して行える機能が追加されるごとにステータスが追加され画面上の条件分岐的な複雑さが増しているので一度整理するためにリバースエンジニアを試みることにしました。
リバースエンジニアリングしてみた
それでは、実際にどのようにリバースエンジニアリングしたかを見ていきましょう。
まずはドメインモデル を確認します。
（実際のer図はもっと複雑なので一部抜粋のうえ、適度に内容を変更しています）
ドメインモデルを確認するとDocumentというクラスを中心にさまざまなプロパティの受け渡しが行われていることがわかります。
Documentクラスは先ほどの書類のプレビューを表示していたページのキーオブジェクトとなります。
このDocumentクラスは他のクラスからいろいろな情報を継承しながらインスンスとして書類を生成するので、Documentクラスが潜在的に持ちえる情報をまずは一覧化して見ましょう。
表示される情報はわかりましたが、表示情報にはInputFormから入力してもらえる状態と入力された状態を持っているものがあるので、viewをInputViewとStaticViewに分類しておきます。ついでに、PDFを表示するViewerも分けておきましょう。
これで書類オブジェクトが潜在的に持つviewの全体が見えました。
さて、問題はこの書類オブジェクトはステータスによってViewと選択できるActionが異なることです。なので、StateとActionをマッピングに追加して関係性を明確にしていきます。
SateとActionを追加しました。
こうして見ると縦のラインでObjectのStateによってどのActionが選択できるのが明確になりましたね。あとはStateごとにView内でなにが表示されるのかを整理するだけです。
完成です。
Viewの領域内では「PDFView」「InputView」「StaticView」「ModalInputView」と分類しています。また、「InputView」と「ModalInputView」で入力した情報は「StaticView」で表示されるのでそれがわかるような図式をとっています。
UIとレイアウトのデザイン
最後にこの図を元にページレイアウトをしてみましょう。
今回はオブジェクトのシングルビューなので、書類オブジェクトが持っているViewとActionをレイアウトとして組み立てていきます。
「ModalInputView」は考慮する必要がないので「PDFView」「InputView」「StaticView」「Action」の領域を画面上に配置していけば自然と形になります。
レイアウトが出来上がりました。
冒頭であげたイメージ画面と構造が一致しているのがわかるかと思います。
このように実体関連モデルなどを確認してリバースモデリングを行うと複数のステータスを持った複雑な画面の整理などもロジカルに行うことができます。
【ポエム】デザインとエンジニアリングに境界はない
ここからはポエムです。
冒頭でも書きましたが、UIデザインとはデータベースやサーバーサイドで実装された構造とフロント側での視覚的な構造との対称性を設計することであるというのが私の考えです。
UIデザインなどを含むフロント側とサーバーサイド側との構造はそれぞれのメディアの違いによる差分はあれど、本質的には対称性を持って同じ地平でつながっているのではないかと考えています。
デザインとエンジニアリングの越境が叫ばれる昨今ですが、本質的に同じものであるのなら境界も最初からないはずです。
もし、そこに境界が生まれているとするならそれは扱っている言語の違いあるいは作業者の思い込みから来る仕事の縦割りによるものではないでしょうか。
デザイナーがドメインモデルを見ながら共通の言語として扱うなどして境界を意識することなく振る舞えば、同じプロダクトを作る仲間として自然なコミュニケーションが生まれるのではないかと考えています。
デザインとエンジニアリングがもっと溶け合っていけるようぜひ皆さんもリバースエンジニアリングを試してみてください。
それでは良いお年を。
追記（2019/12/23）
ちょっとだけ追記。
twitter上でこの記事に対する以下のようなツイートを見かけたので少し補足を書こうと思います。
対称性という言葉をどういう気持ちで使っておられるのかということ(平たく言えばUIデザインにおいてもバックエンドと同じドメインモデルを考えようよということ?)と、どうやってこの方法にたどり着いたのかというストーリーをさらに読んでみたいなと思いました。
— kakinouchi (@cdr_car) December 22, 2019
UIからデータベースの設計をするのは辛い目にあう事が多いです。でも、UIの事は忘れてはいけない。むしろ、データベースのテーブル設計からUIに対して働きかける事が出来そう。ここにフロントエンドが加わるのかな / “ドメインモデルからUIデザインとページレイアウトを行…” https://t.co/uRYcNaiLlA
— まつたろう@island (@kamonegi1977) December 23, 2019
（感想のコメントありがとうございます！）
ここで「対称性」という言葉を選んだのは、ドメインモデル に代表される「データモデルの構造」とフロント側の「視覚的な情報構造」との間に業務ドメインを概念化した「概念モデル」が存在しているという前提の考えによるところが大きいです。
（概念モデルを中心とした対称性のイメージ図）
現実にある何かしらのドメインを理解し構造化するには必ず抽象化する作業として概念モデルが存在するはずです。
この概念モデルからいったんブランチを切って「データモデル」と「UIモデル・情報構造」を設計し、あらためて突き合わせて行く過程で対称性を作り出していくことが重要だと考えています。
今回の事例は、すでにあるDBに対してテーブルの追加が必要になるような開発だったためドメインモデルを参照しつつ、今フロント側で考えているページレイアウトやUIの設計が妥当であるかを確認する作業であったと言えます。
なので、ドメインモデルからUIやレイアウトを設計するでも、デザインカンプ的なものから情報を読み取ってテーブルを設計するでもなく、概念モデルから出発しつつ双方向的に互いに働きかけることが理想です。
この辺の考え方はDDD（ドメイン駆動設計）などで語られる内容なのかもしれませんが、現時点での私はDDDを論じられるほど詳しくないのでより詳しい方がいらっしゃればぜひ学ばさせてもらいたいと思っています。
ちなみに最近では天重さん（@tenjuu99）の以下の記事などから多くを学ばさせていただきました。
あと、リバースエンジニアリングについては鈴木健一さん（@kenichisuzuki）の記事でも触れられていて本記事を書くにあたって参考にさせていただいています。
上記のように私自身まだまだ思考過程でたくさんの方から学ばさせてもらっている途中なので、これから多くの方と対話を交わしながら議論を深めて行きたいと思っています。
来年もどうぞよろしくお願いします。
この記事が気に入ったらサポートをしてみませんか？