DevLOVE エンジニアがデザインに関われること 2018-02-14（水）19:15 - 21:30

1. コラボレーティブデザインを実践する
エンジニアは何を考えているのか?
DevLOVE エンジニアがデザインに関われること

2. 角銅 浩平
株式会社メンバーズ
デザインエンジニア
HCD-Net認定 人間中心設計専門家
UXデザイン、エンジニアリング、データ分析と、UXアプローチで
アジャイル開発を実践するデザインエンジニア。 人間中心設計に
基づいた行動観察・分析によるUXデザインとプロトタイピングに
よる検証を一貫して行なう。
かくどう こうへい
自己紹介

3. デザインエンジニアになるきっかけ
• きっかけは2000年ごろに「誰のためのデザイ
ン」に出会ったこと
• アフォーダンス理論を活かして使いやすいシステムが
作れるのではないかと思うようになった。
• 使いにくいものに敏感にw
• えきねっと、ラーメン屋の券売機、図書館の検索
システム、etc

4. デザインエンジニアになるきっかけ
• 2002年、新サービス開発のためにフィールド
ワークをした
• コンテキスチュアル・インクワイアリー、5モデ
ル。
• データ分析のツールなので、分析作業をしている
人の作業を観察して、質問したりすることをやっ
た。

5. デザインエンジニアになるきっかけ
分析者 情報システム部門
軸を変えて色々な角度で分析し
たい
その分析なら、これらのデータが
あれば大丈夫だな
データ分析のツール開発で、自由に軸を変えながら分析したい分析者を想定してい
たが、実際にコンテキスチュアル・インクワイヤリーで観察してみると…

6. デザインエンジニアになるきっかけ
分析者 情報システム部門
このデータだと粒度が合わないし、
うまく繋げられない…
情シスに依頼しないと。時間かか
るのは仕方ないか…
どう分析するのか分からないか
ら、とりあえずデータをそのまま
渡そう
また依頼くるでしょ
実はそれ以前のデータ加工でひっかかっている。さらにデータ加工する人も違って
いて、データを加工してもらうのに1週間とか。データがなければ分析はできる訳が
ない。

7. 聞いただけで分かったつもりになるのが
いかに危険か分かった
ユーザーは割と「仕方ない」で
済ませてしまうので要注意

8. というように、やりたいことをやっていった結果
デザインエンジニアになっていた

9. チームの話

10. コラボレーティブデザインについて
• みんなでやるデザイン。デザイン
スタジオとも言われる
• 個人的には、全員でやることで意
識合わせができるのがいい。
• もともとはデザインとエンジニア
リングは分化していなかったのだ
から、よくある揺り戻しが起きて
いる印象。
デザイナーA
ディレクター
デザイナーB
プランナー

11. コラボレーティブデザインについて
課題の定義と制約の明確化
個別のアイディアの創出
プレゼンテーションと批評
イテレーションと洗練
チーム全体でのアイディアの創出

12. チームについて
UXを共通言語として、ビジネス、デザイン、エンジニアリングの視点を持ち寄るのが
理想。
最初から全員参加
Business
DesignEngineering
User Experience
お互いに越境

13. 2Weeks 1Week
体験設計・プロトタイピング
ユーザー評価
3週間のスプリントでプロトタイピングと検証を繰り返していく形に変わっていった。
チームについて

14. チームについて
「何をつくるか考える」のではなく「考えるために作る」
プロトタイピングを繰り返してゴールに向かうことを得意とする
チームに

15. 本題

16. 今日話すこと
「エンジニアから関わるデザイン」というテーマで自分が
伝えたいことってなんだろうと考えた

17. 最近はツールやプロセスなどの情報は
色々得られるようになった

18. なので今日伝えたいのはマインドセット
ツールやプロセスの話を期待していた人、
すみません。あとで直接聞いてください

19. デザインエンジニアのマインドセット
自分の中に
答えはない
クリエイ
ティブに
自信を持つ
カタチ
にして
考える
帽子を
かぶり
分ける
覚悟を
決めて
名乗る
最後のはマインドセットと言えないですが、
最初のきっかけとして

20. 自分の中に
答えはない
クリエイティ
ブに
自信を持つ
カタチ
にして
考える
帽子を
かぶり
分ける
覚悟を
決めて
名乗る

21. 自分の中に答えはない
• ユーザー視点に立つって相当難しい
• 18歳の女子の気持ちになれますか?
• どうしても自分基準で考えがち。
• 機能と価値は別なもの
• 想定した通りに使っていなかったり、違うところに価値を感じている
ことは多い。

22. 自分の中に答えはない
価値の感じかたは人によって違うため、ユーザーに体験して
もらって初めて価値が判断できる

23. 同じ機能でもユーザーが違えば価値が違う。つまりモノに価値があるのではない
自分の中に答えはない
透明であること
不気味、ケミカル
不思議、すっきり
歯に色が着かない

24. 結局、テストしてみないと分からない。
最初は本格的にやらなくても大丈夫。5人で充分という話もある。
(※ユーザビリティ調査の話なので少し違いますが)
そして、やったほうがいいに決まってる。やらなければ得られる洞察も0。
5人のユーザーでテストすれば十分な理由
自分の中に答えはない

25. 自分は何も知らないことを前提にする
ユーザーリサーチがないプロジェクトは
ありえないです

26. 自分の中に
答えはない
クリエイティ
ブに
自信を持つ
カタチ
にして
考える
帽子を
かぶり
分ける
覚悟を
決めて
名乗る

27. クリエイティブに自信を持つ
• 自分の周りにデザインに苦手意識を持っている人が多かった
• デザインの大部分はロジックできていることを知る
• メソッドやツールを持つ。デザインはロジックがある。
• ロジックでいけるならエンジニア脳でもいける
• インタラクションデザインなどは作れるエンジニアのほうが
考えやすい

28. クリエイティブに自信を持つ
• Material Designからがおすすめ
• 細かいところまで整理されていて分か
りやすいと思う。
• 動きまで定義されているので、曖昧な
ところが少ないのでエンジニア向き。

29. クリエイティブに自信を持つ
• 苦手意識があるのは知らないから
• 普段からの情報収集の範囲をデザイン
関連まで広げる。
• PintarestとかBehance
• もっとやる気があるなら
• 好きなWebサイトやアプリのワイヤーフ
レームを手書きするのを続けると意図
が分かってくる。

30. デザインもロジックの積み重ねであることを知る
IAやインタラクションデザインなど役割を
持てることからやってみるのがおすすめ

31. 自分の中に
答えはない
クリエイティ
ブに
自信を持つ
カタチ
にして
考える
帽子を
かぶり
分ける
覚悟を
決めて
名乗る

32. カタチにして考える
• 形にすることの威力を知る
• 最小限の労力でプロトタイプをつくる
意識を持つ。
• カタチにできるのはエンジニア、
デザイナーの武器
• 使っているところを見る経験を

33. 先にふるまいとインターフェースを考えてテストコード
を書くので、設計品質を改善させる効果がある
この時点で何をどうやって検証するかハッキリさせる
プロトタイピングで検証するときは、テストファーストと考え
かたは一緒で、先にどう検証するかを決める。
カタチにして考える

34. 新規メディアの検証を支援したときのケース
検証：メディアのコンテンツを求めているのは具体的にはどうい
う人なのか具体化していく
正しいコンテンツさえ用意できればリサーチできる
プロトタイプは記事を切り貼りして作った紙芝居で十分として、
システムは何も作らなくて済んだ
仮説で想定できるユーザー像を決めて評価。違うなら掘り
下げるのではなく、別なユーザーに変えて探していくように
した
プロトタイプ・実装
ユーザー評価
カタチにして考える

35. 日常的に利用する使っていて楽しく感じるアプリ開発のケース
検証：日常の問題をスムーズに解決できているかに加えて、
使っていて楽しくなるか
メインの画面は細かな操作感まで作りこまないと
検証できないので、メインの画面とそこまでの動
線を最優先にした
メインの動線について、表現や動き、手触りの良さなどの楽
しさを作り込めばリサーチできる
プロトタイプ・実装
ユーザーに実際に操作してもらって評価。シナリ
オを用意して触ってもらい、それを観察する形で
検証した
ユーザー評価
カタチにして考える

36. カタチにして考える
• プロトタイピングはアジャイル開発
との相性がいい
• 変わっていきやすいので、スクラムの
プロダクトバックログがいい。
• ユーザーストーリーマッピングで繋ぐ。
• MVP(Minimum Viable Product)の考えかたも上手
くはまる。

37. 最小限のコストで作って試すことを前提にすると
とりあえず進むことはできる
仮説ができたら、体験できるようにするこ
とを最短で目指そう

38. 自分の中に
答えはない
クリエイティ
ブに
自信を持つ
カタチ
にして
考える
帽子を
かぶり
分ける
覚悟を
決めて
名乗る

39. 帽子をかぶり分ける
シックス・ハット法とは、6つの視点の帽子のい
ずれか1つを被った状態でテーマについて考える
発想法。
■赤 直感的に考える（感情・直感）
■白 客観的に考える（事実・情報）
■青 肯定的に考える（メリット）
■黒 否定的に考える（デメリット）
■黄 創造的に考える（アイデア）
■緑 管理的に考える（手順・プロセス）
Challenge Future - Future Book to Edward de Bono by McGeddon / CC by 2.0

40. 帽子をかぶり分ける
• デザインとエンジニアリングで頭を切り替える
• 一人のなかで切り替えできれば最速。
• 理想に近づくために違う視点からアイデアを出していく。
• 余談ですが、デザイナーとエンジニアが同じ方向を向くためには、
ユーザーの方を向くのがいい。

41. ひとりの中に複数の観点を持つことで、トレードオフの判断ができる。実は重要度と
コストで葛藤している場合が多かったりする。
UXデザイナーとしての自
分
エンジニアとしての自
分
この誘導がないとユーザが
目的を達成できないから重要!
ここにアニメーションを実現する
には、コストが結構かかるけど
大丈夫か?
帽子をかぶり分ける

42. 帽子をかぶり分ける
拡散のときはデザイナー的、収束のときはエンジニア的なイメージで、繰り返しな
がらプロトタイプとコンセプトの両方を改善していくことが重要
Discover
発見
Define
定義
Develop
開発
Deliver
実現
拡散 収束 拡散 収束

43. 意識してデザイン脳とエンジニア脳を切り換える
自分の中で、「面倒くさい」と感じたら要
注意です

44. 自分の中に
答えはない
クリエイティ
ブに
自信を持つ
カタチ
にして
考える
帽子を
かぶり
分ける
覚悟を
決めて
名乗る

45. 覚悟を決めて名乗る
• 複合職は範囲が分かりにくい。なにができたらデザインエンジニアと
かはない
• 名前を付けることで、周りからそう認識されるようになる
• 例えば職業の例ではないけど、Ajaxも名前が付いたことで認識されて広がった。
• そういう情報、そういう仕事が入ってくるようになる。
• 自分はなにものなのかを自己で認識できる
• 何をやりたかったのか分からなくなりにくい。迷わなくなる。

46. ともかく名乗ってみることから始めよう
はじめは勇気がいりますが、頑張ればなん
とかなります

47. デザインエンジニアのマインドセット
自分の中に
答えはない
クリエイ
ティブに
自信を持つ
カタチ
にして
考える
帽子を
かぶり
分ける
覚悟を
決めて
名乗る

48. おわりに
UXデザインに取りくんでいる仲間が増えてくれると嬉しいですし、UXデザインを
取り込んだプロジェクトが増えて、世の中に「うれしい体験」が増えるといいと
思っています。
今回、デザインエンジニアのマインドセットをお話をしましたが、どんな職場なの
かとか、どんなツール、プロセスを使っているのか興味がある人もいるかと思い
ます。そういう人は是非お声がけください。

49. UX白書
http://site.hcd
value.org/docs
プロトタイピング実践ガ
イド スマホアプリの効率
的なデザイン手法
ペーパープロトタイピング
最適なユーザインタフェー
スを効率よくデザインする
UXデザインの教科書 人間中心設計入門
(HCDライブラリー)
ストーリーマッピング
をはじめよう
エクスペリエンス・ビジョ
ン: ユーザーを見つめてう
れしい体験を企画するビ
ジョン提案型デザイン手法
Lean UX ―リーン思
考によるユーザエクス
ペリエンス・デザイン
UXデザイン 入門
プロトタイピング
人間中心設計
ストーリーマッピング
インタビュー
マーケティング/商品企
画のための ユーザーイ
ンタビューの教科書
KJ法
発想法―創造性
開発のために
参考資料(※学校の授業用にまとめたものなので入門編です)