Upgrade to Pro — share decks privately, control downloads, hide ads and more …

モデルを中心にデザイン(設計)すること

 モデルを中心にデザイン(設計)すること

かとじゅん
PRO

November 29, 2021
Tweet

More Decks by かとじゅん

Other Decks in Design

Transcript

  1. モデルを中心に
    デザイン(設計)すること
    かとじゅん( )
    2021/11/29
    デザイナー向け社内勉強会
    @j5ik2o
    1

    View Slide

  2. 自己紹介
    Chatwork社 テックリード
    @j5ik2o
    2

    View Slide

  3. 今日のテーマ
    何を手がかりにシステムを
    デザイン(設計)するのか
    3

    View Slide

  4. タッチパネル式の券売機
    出典:オブジェクト指向UIデザイン
    4

    View Slide

  5. タスク VS オブジェクト
    何を目当てにしてデザインするのか
    タスク=やること、オブジェクト=関心の対象、どちらが先か
    タスク中心よりオブジェクト中心であることが求められる
    出典:オブジェクト指向UIデザイン
    登録する
    確認する
    修正する
    削除する
    感想⽂を書く
    リストにしてみる
    出版社別に並べてみる
    My Books
    タスク中心の設計




    ➡各画面へ
    オブジェクト中心の設計
    検索キーワード
    Scala関数型デザイン&プログラミング
    実践Rustプログラミング⼊⾨
    エリック・エヴァンスのドメイン駆動設計
    オブジェクト指向存在論⼊⾨
    技術とは何だろうか-三つの講演
    My Books

    タイトル エリック・エヴァンスのドメイン駆動設計
    著者 エリック・エヴァンス
    出版社
    出版⽇
    感想⽂
    Book
    5

    View Slide

  6. FYI: オブジェクトとは
    オブジェクトとは概念のこと(イミフ?)
    オブジェクトは「世界」だとか「論理空間」だと言っている
    に等しい。つまり全部を表しているので意味が分からないと
    なりやすい
    まずは「ある関心の対象」という程度の理解でよい
    6

    View Slide

  7. オブジェクトを中心に設計する
    出典:オブジェクト指向UIデザイン
    タスク
    タスク
    タスク
    オブジェクト
    タスク
    タスク
    タスク
    オブジェクト
    7

    View Slide

  8. UIはユーザとオブジェクトを
    接続する情報空間
    オブジェクト指向設計では、ユーザが持っている関心対象につい
    ての構造的概念=メンタルモデルをコンピュータの中で模式的に
    再現する。
    Chatworkの場合は、ユーザがメッセージという概念を持ってい
    るなら、その概念のままプログラム中に情報単位として再現す
    る。これが「オブジェクト」です。
    出典:オブジェクト指向UIデザイン
    8

    View Slide

  9. ユーザにおけるオブジェクトの価値
    ユーザーはインターフェースを、それを描く元となるデータとビ
    ジネスの世界についてのモデルとの間に経路を作るために使用す

    適切に設計されたプログラムは、データモデルにおいてうまく情
    報モデルをとらえるし、少なくてもそのようにしているという幻
    想を与える
    そういうことをソフトウェアができるならば、ユーザーはコンピ
    ューターのメモリが、自分の記憶の延長であるように感じる
    出典:
    より
    出典:オブジェクト指向UIデザイン
    トリグヴェ・リーンスカウク、ジェームズ・コプリエン
    「DCIアーキテクチャ」
    9

    View Slide

  10. ソフトウェアデザインのレイヤー
    出典:オブジェクト指向UIデザイン
    ユーザが目にするGUIはオブ
    ジェクトを反映したものであ
    り、内部のデータモデルはユ
    ーザのメンタルモデルを反映
    したものになる
    優れたUIは人と一体化する
    人が箸(UI)を自在に操って
    食べ物(オブジェクト)を口
    へと運ぶ
    人がヴァイオリン(UI)を自
    在に操って自在に音(オブ
    ジェクト)を操る
    プレゼンテーション
    インタラクション
    モデル
    10

    View Slide

  11. ソフトウェアデザインの構成要素
    出典:オブジェクト指向UIデザイン
    プレゼンテーション
    インタラクション
    モデル
    モデル
    ソフトウェアデザインの基盤となる層で、
    デザイン全体の60%を占めると言われてい

    インタラクション
    ソフトウェアデザインの構造と機能に関する層で、モデルとプレゼ
    ンテーションを繋ぐ仕組み
    プレゼンテーション
    ソフトウェアデザインの表層で、インタラクションのメカニズムを
    様々なUI表現によってユーザに示す
    11

    View Slide

  12. モデルとは何か?
    オブジェクトと関係は?
    モデルは、問題や課題を解決する考え方
    オブジェクトは、モデルを反映した実装
    12

    View Slide

  13. FYI: 具体例としてのMVC
    考案者 トリグヴェ氏曰く、「モデルは知識の表層です」とした
    MVCの目的は、人間であるユーザーのメンタルモデルとコンピ
    ュータの中にあるデジタルなモデルとの間にあるギャップを埋め
    ること
    理念的なMVCのソリューションは、ユーザーがドメインの情報
    を直接的に視認して操作しているという幻想を支える
    13

    View Slide

  14. モデルとデザイン(1/2)
    本来はあるべき形のUIを最優先に検討するべき、その裏の構造
    はプレゼンテーションとメンタルモデルの間の整合を取るための
    ものにすぎない
    デザインの目的は形である
    とはいえ、構造的な根拠がないとソフトウェアとしてインタラク
    ティブな表現ができない。プレゼンテーションやインタラクショ
    ンの表現の妥当性はモデルがないと検証できない
    その形を検証する必要がある
    この両面の視点でいったりきたりしなければならない
    14

    View Slide

  15. FYI: ダイナブック構想とモデル
    出典:
    「あらゆる年齢の「子供たち」のためのパーソナ
    ルコンピュータ」にてダイナブックという構想=
    ダイナブック構想を考案した アラン・ケイ曰く
    特に若年の子供においてはそうですが、知識は
    一連の操作モデル として保持されます。
    それぞれのモデルはアドホックで、他のモデル
    と論理的に一貫している必要はありません(そ
    れらは本質的にアルゴリズムやストラテジであ
    って、論理的公理や述語、定理ではない)。


    論理が使用されるようになるのは発達段階のずっと後半 で、そ
    の段階でも論理を超えたストラテジが取られ続けます。
    https://swikis.ddo.jp/abee/74
    15

    View Slide

  16. モデルとデザイン(2/2)
    「論理が使用されるようになる」とは記号操作のこと。その前に
    「動作的」「映像的」な操作モデルが構築されるとしている。
    16

    View Slide

  17. モデルとは何か?
    オブジェクトと関係は?
    モデルは、問題や課題を解決する考え方
    オブジェクトは、モデルを反映した実装
    17

    View Slide

  18. モデルの例
    おもちゃの車
    現実の車から「走らせて遊
    ぶ」という概念だけを抜き
    出して表現
    メルカトル図法
    極の面積は大きくなるが角
    度が正しい
    航海士のための地図


    18

    View Slide

  19. 目当てのモデル=ドメインモデル
    出典:『エリック・エヴァンスのドメイン駆動設計』
    モデルにはいろいろなものがある。
    プレゼンテーションのモデル
    データベースのモデル
    ここでいうモデルとは、お目当てのモデ
    ル、問題領域(ドメイン)のモデルであるド
    メインモデルのこと
    ドメインモデルとは
    人間が扱う意味のある概念。問題や課題を解決する考え方の
    こと
    現実世界の仕組みを説明するための簡素化された表現
    現実世界の事象は複雑なので、人間の限られた認知能力で扱
    えるように、重要ではない部分を削ぎ落としシンプルにする
    19

    View Slide

  20. ドメインモデルの例
    チャットルーム 
    メンバー同士でメッセージを交換できるコミュニケーション
    の場
    チャットルームには管理者が最低1名以上必要
    管理者
    コンタクトを持つ、ユーザーをメンバーとしてチャットルー
    ムに追加/削除できる
    メンバーを管理者に昇格できる(降格もできる)
    メンバー
    メンバーは参加するチャットルームでメッセージを投稿/編
    集/削除できる
    これはCHATWORKのドメインモデルだが
    他のサービスだと異なる形になる
    20

    View Slide

  21. モデルを反映したオブジェクトを
    実装する
    ソフトウェア開発において、問題や課題を解く考え方=モデルを
    「オブジェクト」(ソフトウェア部品)として反映する設計スタイ
    ルが利用される。代表格はドメイン駆動設計(DDD)
    モデルを反映したオブジェクトのイメージ
    21

    View Slide

  22. オブジェクトは静的とは限らない
    22

    View Slide

  23. モデルはプロジェクト活動も支える
    開発初期は簡単でも追加要件
    などによりソフトウェアが複雑
    になった場合は、頼れるドメイ
    ンモデルがないと複雑さに圧倒
    されてしまう
    意思疎通のコアにドメインモ
    デルを使う。プロジェクト全体
    に浸透させる。会話、ドキュメ
    ント、図、アーキテクチャ、コ
    ードにも。そしてUI/UXにも
    ドメインモデル
    ドキュメント
    アーキテクチャ
    会話
    コード

    UI/UX
    23

    View Slide

  24. FYI: 皮むき機 VS ナイフ
    ユーザの要求に合わせようとするとモーダルになりがち。新たな道
    具の存在が要求のあり方を変えてしまう。
    デザインにユーザー側が合わせられるように、デザインを無為な形
    に保つこと。在るが儘の目当てを模式化してユーザーに送り戻す。
    OOUIにはそういった基本的な考え方がある。
    出典:オブジェクト指向UIデザイン
    皮むき機は抽象度が低い
    (モーダル)



    ナイフは抽象度が高い
    (モードレス)
    24

    View Slide

  25. まとめ
    デザインの究極の目的は形であるが、モデルが不在では使えるも
    のになるか検証できない
    形とモデルの両面で追究してくいく必要がある。特に価値を生み
    出す動くソフトウェアとの親和性を考えるとモデルを中心にした
    設計は効果的
    形 ー モデル ー オブジェクト の関係性を、プロダクトチーム全
    体の活動にしていく必要がある
    25

    View Slide

  26. 終わり
    26

    View Slide