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

Transcript

1. モデルを中心に デザイン(設計)すること かとじゅん( ) 2021/11/29 デザイナー向け社内勉強会 @j5ik2o 1
2. 自己紹介 Chatwork社 テックリード @j5ik2o 2
3. 今日のテーマ 何を手がかりにシステムを デザイン(設計)するのか 3
4. タッチパネル式の券売機 出典:オブジェクト指向UIデザイン 4
5. タスク VS オブジェクト 何を目当てにしてデザインするのか タスク＝やること、オブジェクト＝関心の対象、どちらが先か タスク中心よりオブジェクト中心であることが求められる 出典:オブジェクト指向UIデザイン 登録する 確認する 修正する 削除する 感想⽂を書く リストにしてみる 出版社別に並べてみる My Books タスク中心の設計 ➡各画面へ オブジェクト中心の設計 検索キーワード Scala関数型デザイン＆プログラミング 実践Rustプログラミング⼊⾨ エリック・エヴァンスのドメイン駆動設計 オブジェクト指向存在論⼊⾨ 技術とは何だろうか-三つの講演 My Books ↓ タイトル エリック・エヴァンスのドメイン駆動設計 著者 エリック・エヴァンス 出版社 出版⽇ 感想⽂ Book 5
6. FYI: オブジェクトとは オブジェクトとは概念のこと(イミフ？) オブジェクトは「世界」だとか「論理空間」だと言っている に等しい。つまり全部を表しているので意味が分からないと なりやすい まずは「ある関心の対象」という程度の理解でよい 6
7. オブジェクトを中心に設計する 出典:オブジェクト指向UIデザイン タスク タスク タスク オブジェクト タスク タスク タスク オブジェクト 7
8. UIはユーザとオブジェクトを 接続する情報空間 オブジェクト指向設計では、ユーザが持っている関心対象につい ての構造的概念＝メンタルモデルをコンピュータの中で模式的に 再現する。 Chatworkの場合は、ユーザがメッセージという概念を持ってい るなら、その概念のままプログラム中に情報単位として再現す る。これが「オブジェクト」です。 出典:オブジェクト指向UIデザイン 8
9. ユーザにおけるオブジェクトの価値 ユーザーはインターフェースを、それを描く元となるデータとビ ジネスの世界についてのモデルとの間に経路を作るために使用す る 適切に設計されたプログラムは、データモデルにおいてうまく情 報モデルをとらえるし、少なくてもそのようにしているという幻 想を与える そういうことをソフトウェアができるならば、ユーザーはコンピ ューターのメモリが、自分の記憶の延長であるように感じる 出典: より 出典:オブジェクト指向UIデザイン トリグヴェ・リーンスカウク、ジェームズ・コプリエン 「DCIアーキテクチャ」 9
10. ソフトウェアデザインのレイヤー 出典:オブジェクト指向UIデザイン ユーザが目にするGUIはオブ ジェクトを反映したものであ り、内部のデータモデルはユ ーザのメンタルモデルを反映 したものになる 優れたUIは人と一体化する 人が箸(UI)を自在に操って 食べ物(オブジェクト)を口 へと運ぶ 人がヴァイオリン(UI)を自 在に操って自在に音(オブ ジェクト)を操る プレゼンテーション インタラクション モデル 10
11. ソフトウェアデザインの構成要素 出典:オブジェクト指向UIデザイン プレゼンテーション インタラクション モデル モデル ソフトウェアデザインの基盤となる層で、 デザイン全体の60%を占めると言われてい る インタラクション ソフトウェアデザインの構造と機能に関する層で、モデルとプレゼ ンテーションを繋ぐ仕組み プレゼンテーション ソフトウェアデザインの表層で、インタラクションのメカニズムを 様々なUI表現によってユーザに示す 11
12. モデルとは何か？ オブジェクトと関係は？ モデルは、問題や課題を解決する考え方 オブジェクトは、モデルを反映した実装 12
13. FYI: 具体例としてのMVC 考案者 トリグヴェ氏曰く、「モデルは知識の表層です」とした MVCの目的は、人間であるユーザーのメンタルモデルとコンピ ュータの中にあるデジタルなモデルとの間にあるギャップを埋め ること 理念的なMVCのソリューションは、ユーザーがドメインの情報 を直接的に視認して操作しているという幻想を支える 13
14. モデルとデザイン(1/2) 本来はあるべき形のUIを最優先に検討するべき、その裏の構造 はプレゼンテーションとメンタルモデルの間の整合を取るための ものにすぎない デザインの目的は形である とはいえ、構造的な根拠がないとソフトウェアとしてインタラク ティブな表現ができない。プレゼンテーションやインタラクショ ンの表現の妥当性はモデルがないと検証できない その形を検証する必要がある この両面の視点でいったりきたりしなければならない 14
15. FYI: ダイナブック構想とモデル 出典: 「あらゆる年齢の「子供たち」のためのパーソナ ルコンピュータ」にてダイナブックという構想= ダイナブック構想を考案した アラン・ケイ曰く 特に若年の子供においてはそうですが、知識は 一連の操作モデル として保持されます。 それぞれのモデルはアドホックで、他のモデル と論理的に一貫している必要はありません（そ れらは本質的にアルゴリズムやストラテジであ って、論理的公理や述語、定理ではない）。 論理が使用されるようになるのは発達段階のずっと後半 で、そ の段階でも論理を超えたストラテジが取られ続けます。 https://swikis.ddo.jp/abee/74 15
16. モデルとデザイン(2/2) 「論理が使用されるようになる」とは記号操作のこと。その前に 「動作的」「映像的」な操作モデルが構築されるとしている。 16
17. モデルとは何か？ オブジェクトと関係は？ モデルは、問題や課題を解決する考え方 オブジェクトは、モデルを反映した実装 17
18. モデルの例 おもちゃの車 現実の車から「走らせて遊 ぶ」という概念だけを抜き 出して表現 メルカトル図法 極の面積は大きくなるが角 度が正しい 航海士のための地図 18
19. 目当てのモデル＝ドメインモデル 出典:『エリック・エヴァンスのドメイン駆動設計』 モデルにはいろいろなものがある。 プレゼンテーションのモデル データベースのモデル ここでいうモデルとは、お目当てのモデ ル、問題領域(ドメイン)のモデルであるド メインモデルのこと ドメインモデルとは 人間が扱う意味のある概念。問題や課題を解決する考え方の こと 現実世界の仕組みを説明するための簡素化された表現 現実世界の事象は複雑なので、人間の限られた認知能力で扱 えるように、重要ではない部分を削ぎ落としシンプルにする 19
20. ドメインモデルの例 チャットルーム　 メンバー同士でメッセージを交換できるコミュニケーション の場 チャットルームには管理者が最低1名以上必要 管理者 コンタクトを持つ、ユーザーをメンバーとしてチャットルー ムに追加/削除できる メンバーを管理者に昇格できる(降格もできる) メンバー メンバーは参加するチャットルームでメッセージを投稿/編 集/削除できる これはCHATWORKのドメインモデルだが 他のサービスだと異なる形になる 20
21. モデルを反映したオブジェクトを 実装する ソフトウェア開発において、問題や課題を解く考え方＝モデルを 「オブジェクト」(ソフトウェア部品)として反映する設計スタイ ルが利用される。代表格はドメイン駆動設計(DDD) モデルを反映したオブジェクトのイメージ 21
22. オブジェクトは静的とは限らない 22
23. モデルはプロジェクト活動も支える 開発初期は簡単でも追加要件 などによりソフトウェアが複雑 になった場合は、頼れるドメイ ンモデルがないと複雑さに圧倒 されてしまう 意思疎通のコアにドメインモ デルを使う。プロジェクト全体 に浸透させる。会話、ドキュメ ント、図、アーキテクチャ、コ ードにも。そしてUI/UXにも ドメインモデル ドキュメント アーキテクチャ 会話 コード 図 UI/UX 23
24. FYI: 皮むき機 VS ナイフ ユーザの要求に合わせようとするとモーダルになりがち。新たな道 具の存在が要求のあり方を変えてしまう。 デザインにユーザー側が合わせられるように、デザインを無為な形 に保つこと。在るが儘の目当てを模式化してユーザーに送り戻す。 OOUIにはそういった基本的な考え方がある。 出典:オブジェクト指向UIデザイン 皮むき機は抽象度が低い (モーダル) ナイフは抽象度が高い (モードレス) 24
25. まとめ デザインの究極の目的は形であるが、モデルが不在では使えるも のになるか検証できない 形とモデルの両面で追究してくいく必要がある。特に価値を生み 出す動くソフトウェアとの親和性を考えるとモデルを中心にした 設計は効果的 形 ー モデル ー オブジェクト の関係性を、プロダクトチーム全 体の活動にしていく必要がある 25
26. 終わり 26