Chatwork Creator's Note

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

ビジネスチャット「Chatwork」のエンジニアとデザイナーのブログです。

読者になる

オブジェクトとかモデル、ドメインについてのデザイナーの解釈

突然寒いですね。まだ衣替えを終えていない、プロダクトデザイン部の守谷(emi moriya (@emim) | Twitter)です。

この記事は、Chatwork Advent Calendar 2021の12/20の記事です。ほかのスタッフの記事と合わせて、どうぞご覧ください。

qiita.com

さて本日のお題目は「オブジェクト、モデル、ドメイン」です。普段、アクセシビリティの話ばかり書いている私ですが、たまには設計の視点から。

デザイナー向けに、エンジニアに開催してもらった勉強会の成果(まとめ)を、デザイナー目線で紐解いていきます。

オブジェクトとは、モデルとは、ドメインとは

結論から言うと、オブジェクトを利用したドメインモデリングとはつまりUX設計行為だ、と捉えるとデザイナー的には腑に落ちました。

ただ単に、それだけの話でした。

と、まとめてしまうと余りに雑なため、順を追って理解の端を紐解きます。

モデルへの興味について

昨今、私のデザインに関する興味範囲でとくに耳につくようになっているものの、結局「なんもわからん」となっていた*1ことのひとつがモデルです。

デザイナーのための設計概念がまとめられた『オブジェクト指向UIデザイン』という書籍で紹介されているOOUIも、それ自体がモデル設計の話*2です。OOUIに向き合おうとすると次に、OOUIで扱われるオブジェクトとは何か?という疑問が上がってきます*3

個人的な話でいうと、Web黎明期にFlash(ActionScript)に少し触れていた身としては、オブジェクト指向という言葉とオブジェクトの雑な概念自体は、その頃に学んだ気でいました。しかし、いざOOUIに則って設計しようとしても「オブジェクト」をふわふわと不安定に定義してしまっていたり、雰囲気で定義された「オブジェクト」を使ったモデリングは早いうちに破綻する、などの問題点が出てくる気配を感じました。

「オブジェクト」とはどうあるべきか?と、デザイナー間で共通認識を確立しようとしても「そもそも言語化できない」状態にもありました。私は「説明できないようなものは、何も理解できていない」と考えるため、改めて学ぶ必要があると思い至ったのが、最初の動機です。

開発体制の補足としてお伝えすると、Chatworkでは以前よりDDD(ドメイン駆動設計)に沿った設計・開発が行われてきました。

ドメインを軸とした弊開発チームの特長とも言えるDDDの一端まで触れた上で、更にOOUIのモデル概念をデザインに取り入れることができたら、よりよいUI設計ができるのではないか。オブジェクトやモデル、更にドメインを深く理解できたら、プログラムともより親和性の高いUIを作り出せるのではないか。

また、ほかのスタッフたちの記事をご覧になって勘付いている方もいるかもしれませんが、弊社には設計ツヨツヨのエンジニアもいる!餅は餅屋、詳しい人に説明してもらったらいいじゃないか!

ということで早速、心当たりのあるエンジニアに相談に上がったのが初動でした。

勉強会の企画と開催

「DDDと言えば」という感じでエンジニア界隈での有名人かとじゅんさんが弊社にはいます(身内の人ながら、この記事ではニックネーム記載及び、敬称略さずで失礼します)。

同じ組織に所属しながら、デザインはフロントエンドより更に表層の領域。一方DDDが実行されているのは(現時点では)バックエンドの更にコア。飲み会などでは仲良く会話する機会も多々ありましたが、業務で同席することはほとんどありません。

専門家がいるのになんと勿体ない!

そこで、今現在私の抱える「理解しきっていない」のモヤモヤの話と、どうせならデザイナー全員に向けた勉強会をできないか、という打診をしてみました。

かとじゅんさんに話しを聞くと、もともと「エンジニアのインターンに向けても同じような講座をしているから、少しアレンジをすればすぐにできるかも」とか「もっとこういう機会があってもいいと思ってた」という言葉をもらえました。

この時点でのデザイナー側の問題点としては

  • 「オブジェクト」をきちんと把握できていないため、実装や詳細デザインのタイミングで手戻りが発生することがある
  • エンジニアと「モデル」の話をすべきかもしれないが、そもそも理解ができていない(気がする)
  • DDDに於いては「ドメイン」の理解が重要だとは思うが、そこをデザイナー全員が把握できているわけではない

こういったものを右脳派でも「わかる」内容に落として勉強会をして欲しい、という要望を伝えました。

まずはキッカケを作り、入口の把握ができた上で更に興味が出てきた場合には、おかわり勉強会(あるいはワークショップ)を開催する前提での実施となりました。

開催内容と「勘違い」の把握

勉強会で利用したスライドは、既に公開されています。

speakerdeck.com

今回は、OOUIを引用しながら、ユーザの関心とドメインモデルにどういう関係性があるのか、それがデザインにどう関係するのか、をテーマにしているので、デザイナーでも理解しやすい資料となっています。口頭ベースで補足の入る前提の資料のため、詳細まで把握はできないかもしれませんが、スライドだけ見ても理解の一端にはなると思いますので是非ご覧ください。

我々の(主に私の)疑問への理解

得られた知見をまとめると、以下のようになります。

  • オブジェクトとは、動作可能なプログラミング要素でもあり、ユーザーの関心の対象でもある
    • 「関心ごと」であるため、そこには優先度が存在し、整理を行えるものである
  • オブジェクトとユーザの情報空間の接点をUIが担う(OOUIでいうところのプレゼンテーション)
  • 目的に沿って問題を解く考え方やルールがモデルであり、オブジェクトにそれを反映するのがモデリング
    • オブジェクトとモデルが一致していると、感覚的に操作可能となる(ex:自転車の構造はオブジェクトとモデルが合致するため、ユーザーは自分の身体のように操作可能)
  • 視点(ドメイン)により問題・モデルは変わる:解決させることがドメインモデル

個人的な一番の受講前後での認識とのズレは、「モデリングとはER図を作ること(=デザイナーには超ハード)」と思っていたことでした。

一通り講座を聞いた上での把握では、冒頭で挙げた通り「モデリングとはUX設計である」という解に辿り着きました。

デザイナーが、とか、エンジニアが、ではなく、あらゆる職域の人たち混合で 「Chatworkの場合のビジネスにおける問題点の解決方法を探り、目的に沿った考え方や仕様を定義していく」ことがドメインモデリングだ 、という理解を得られました。

また弊社では「エンジニアがモデルを作っている」というイメージがあるが、デザイナーが会話できるシーンはあるか?という問いに「どういうプロダクトにしたいのか?を考えるタイミングがまさにその時で、関係者間で共通言語で会話できるようにすることもモデリング(決して特殊なプログラミング用語ではない)」という回答も得られました。

誰かだけが、あるいはどこかの部署・職能だけのものではなく、関係者全員で解を探すことがモデリングであることが把握できたので、今後の開発においても「自分以外の意見を参考にする」ということの意義が、今まで以上に重要であると理解できた気がします。

満足度調査

ところで、この勉強会の満足度を事後アンケートで収集しました。あえて超マイナスの回答欄も散りばめましたが、概ねポジティブな結果です(記名制であることも起因しているかもしれませんが)。

勉強会の理解度と満足度に関するアンケート結果グラフ(概ね良好の結果が出ている)

記入式回答欄では

  • モデル=怖いが払拭されてよかったです。 あと、図とかじゃないということに気付けたのがよかったです。
  • モデルの理解がまだ自信がない(粒度/広さ間違ってそう)です。。
  • こうした『理論』の実践について次はお話ししてみたい。
  • デザイナーが書くモデル図(ユーザーフロー/CJM等)とエンジニアが書くモデル図の比較とかすると面白そう。

というような答えが返ってきています。

斯くして、我々は “完璧に理解した*4” に移行できたと思われます。

今回プロダクトデザイン部に於いて、別の職域の人に呼びかけ自分達の理解を深める講座をしてもらう、という前例を作ることができました。Chatworkには「各職種の尖ったプロフェッショナルが集まっている」という点で、デザイナーであっても恩恵を享受できる立場にあります。来年以降もまた、新たな知を得られるように職能(場合によっては企業)を超えた勉強会を開催できれば、と考えています。

最後に、現在弊社ではこのように一緒にデザインの知見を広めたいデザイナーさん及び、その道のプロの方を絶賛募集中です。今回のような取り組みが気になった方は、Wantedlyなどご覧ください。

アドベントカレンダーはまだ続きます。24日には他のデザイナーによる記事も公開されますのでお楽しみに!

recruit.chatwork.com

*1:「なんもわからん」について、勉強会の蛇足としてダニング=クルーガー効果という物を教えてもらいました。この時点で私の言う「なんもわからん」は文字通りですが、ダニング=クルーガー効果では、ある事象に対し「舐めるように把握ができる」と次に一度「完璧に理解した」という勘違いが来て、その後深堀りすればするほどにまた「なんもわからん」に到達し、最終的に「ちょっとわかる」へと移行するそうです。認知バイアスによる知の歪みを表す現象とのこと。

*2:「インターフェースは、ソフトウェアデザインの構造的基盤であるオブジェクトモデルを反映したものであり、内部のデータモデルは、ユーザーのメンタルモデルを反映したもの」と冒頭で説明されています。

*3:書籍の中や関連セミナーなどでも「オブジェクトを正しく定義できている」が前提となっており、具体的な定義方法や理解までは噛み砕かれていないような印象を持っています。そのため「オブジェクト」の定義がズレている場合は?などまでは想像が及ばない状態でした。

*4:あくまで、ダニング=クルーガー効果に於ける「完璧に理解した」です。