概要
「デザイン・要件・設計をつなぐモデリング」に参加しました。 感想について記述します。
modeling-how-to-learn.connpass.com
感想
サービスデザイナー・ソフトウェアエンジニアの樋口さんの、デザイナー観点からのモデリングでした。
自分は、エンジニアなので、参加しても発表内容がわからないのではないかと不安でした。 しかし、デザイナー観点にかたよった話ではなく、デザイナーの観点からでもエンジニアや顧客との言葉の不一致が存在し、それを解決するための対話をおこなうことでモデリングをおこなっていく、という内容でした。 これはドメイン駆動設計（以下、DDD）、ICONIX、RDRA が解決しようとしている内容とまったく同じで、共感を持ちながら発表を聞きました。
様々な現場で使われているメソッド（フレームワーク？）も紹介され、一部の内容になるほどと思いながら聞いていました。 それに加えて、「提案->モデリングの現場をオープンにする」ために、以下のことが実践されていました。 ドメイン駆動設計がおこなう、全員の関心が一致して合意をとれるようにする環境づくりに通じており、これも共感しました。
- サービスの創出・改善からエンジニアもデザイナーに参加する
- サービスに関わる者全員がモデルを介して会話をする環境をつくる
最後に解決策として以下が提案されていました。非常に共感性が高い内容でした。 現職で、DDD のファシリテーターを目指しています。「組織全体でモデリングに理解を得る」は意識していましたが、「何事もモデリングとは発散と収束のイテレーション」は意識できていませんでした。 エンジニアリングがメインだと無意識に発散してしまうことが多かったので、とても良い気づきを得ることができました。
内容
# 導入 勉強会の概要、目的について # 開発現場でのサービスデザインとモデリ- デザイナーのモデリング ## 目次 - サービスデザインの定義と役割 - サービスデザインのモデリングメソッド - 開発現場でのデザイン - まとめ ## サービスデザインの定義と役割 課題感 デザインの現場でモデリングしても開発の現場とコラボレーションしない どっちもやるパターンは困らないが、どっちかをやるだと困ることが多い 解決方法 サービスデザイン視点でのモデリングを開発の現場にマージする デザイナーの視点 - ユーザの特性とニーズ - ビジネスの価値・構造 - サービスをどう最適に届けるか User と Businee の重なるところ、提供する価値とニーズが一致しているか 企業とサービスと顧客の関係 サービスにはバックヤード（企業によるサービスの業務）とフロントヤード（顧客とサービスの接点）がいる サービスデザイン Service Design サービスデザインでは顧客、業務、ビジネスの三者を均等に共感を持つ必要がある 発見->定義->設計->開発->提供 サービス-ステイクホルダーや組織・情報が相互作用・相互依存する-複雑になる 複雑な事象への理解・分析・対話-モデルを共通言語にする-最適解 顧客、業務、ビジネス とサービスデザイナーが対話する ## メソッド サービスブループリント ビジネス・サービスに関係する全てのステイクホルダー（利害関係者）のタスクと連携を可視化。フロントヤード・バックヤードの課題抽出や最適化に活用する RDRA の最初の段階と違い リーンキャンバス ビジネスモデルキャンバスにリーン要素を加えたメソッド。ビジネスの構造を 9 つの項目で整理することで理解や句ぢきをつくる 行動プルソナ 利用者のデモグラフィックでーたや感情だけを抽象化するのではなく、利用者の行動を定義することで行動パターンから利用者像や課題やニーズを抽出する 行動ペルソナは仮説だけじゃなく定量・訂正データから組み立て・検証すると確実 メンタルモデルギャップ分析 利用者のタスクをグループ化し、ユーザのメンタルモデルに対してサービスのコンテンツや機能提供にギャップがないかを調べる タスクは仮説を立ててインタビューし、発話録から抽出するとよい デザインスプリント サービスデザインスプリントをベースに Google Ventures 短期間のスプリントを繰り返してサービスに関して学、プロッタイプでテストまで進める サービスの価値やユーザのニーズを明確化しメンバーで共有するフレームワーク OOUI（オブジェクト指向 UI） ユーザが持つサービスに対するメンタルモデルなどをモデリングして画面やナビゲーション、コンポーネントを設計・実装する方法 ## 開発現場でのサービスデザイン ソフトウェア開発でのモデル駆動要件定義やモデル駆動設計と組み合わせてみてはどうか? RDRA レイヤーと組み合わせてみる システム価値 システム外部環境 システム境界 システム RDRA は以下の問いの答える構造 ->サービスデザインと構造が近い - 誰が何のためにこのシステムを使うのか？ - システム化対象の業務はどういうものか？ - etc 提案->モデリングの現場をオープンにする - サービスの創出・改善からエンジニアもデザイナーに参加する - サービスに関わる者全員がモデルを介して会話をする環境をつくる 課題 組織的分断でモデルがマージしていかない 解決案 - 組織全体でモデリングに理解を得る - 何事もモデリングとは発散と収束のイテレーション - それを促すファシリテーターを目指す まとめ - 開発とデザインの現場をモデルで会話 - サービスデザインを開発の場に持ち込み、最適なシステム・アプリケーションの提供へ - 分業化による組織的分断よりモデル駆動な分業で生産性向上を啓蒙
