UX Developer の人材運用の現実と求められる理想の運用方法 ならびに、それを実現する為の立ち振舞い その１

1. Designing
UX Development
よりよい UI / UX を提供する
組織と手法のデザイン
あるいは組織内戦略
KLab 株式会社 開発制作本部 第五開発制作部
VoQn http://voqn.github.com

2. What’s this ?
UI / UX ほげふが なる肩書きが
増えている昨今
そうした人材を必要とされる
気運が高まっているけれど
実際どうなのよ？ どう使うのが
本当にいいのよ？ という話

3. Agenda
• Ideal & Real - 理想と現実
• Where is “Experience” ? - それはそうと
• UX = System >>= Culture - そもそも
• Developer’s Sadness - これがつらい
• Positioning - こうあるべき
• Aiming for Victory - こうしたい
• How should it begin - どうすればよいか
• Homework - しゅくだい

4. Ideal & Real
• 「UI / UX の質を高めれば…」
• 売上が上がるわけではない
• 別の因子の方が大きく働く
• 「ターゲットにマッチしたマーケティング」
• 「ライバルの不在 / ライバルに対する優位」
• 「UI に対する慣れ」で時間的に解決されてしまう事も
• 工数が短縮されるわけではない
• 原理的に関係ない
• 的確なコンセプトワークで手戻りが減る→短縮はありうる
• 下手な運用次第では逆に時間がかかりうる

5. Ideal & Real
• 「UI / UX の専任がいれば…」
• タスクを一任できるわけではない
• タスクは複数の領域に跨ぎ、常に別の専門の協力が要る
• 一任できるタスクは「コンセプトワーク」くらい
• 分業が進むわけではない
• むしろ全てにおいて「兼任」になってしまう
• 常に「どっちつかず」を懸念される存在
• 「見通しの良い計画…」にはならない
• むしろ「レビューによる再考」上等スケジューリング
• 最後までリテイクを受け入れる覚悟が要る

6. Where is
“Experience” ?
Input
F I U C
Function Interface Output User Commune
Product / Service Interaction Society

7. Where is
“Experience” ?
Input
F I U C
Function Interface Output User Commune
Product / Service Interaction Society
User Interface
User Experience

8. UX = System >>= Culture
• ハードウェア、ソフトウェア問わず
• プロダクト / サービスを提供し
• ユーザー文化圏の中で利用され
• ユーザーが 体験・体感 するモノ
• だから UX Developer は全部やる
• ただ、「UX、UX」って呼んでても「体験、体験」って呼んでても、
曖昧すぎるし、ゲシュタルト崩壊するし、ぶっちゃけ「UXの専門家
です（ドヤ顔）」みたいな人、きらいだし信用できない

9. UX = System >>= Culture
• UX は設計しても再現性が「無い」
• 設計、設定したところでユーザーに
必ずに体験させられるものではない
(そりゃそうだ)
• 感じ方や使い方はユーザーの自由ゆえに
設計者は結局「あんなこといいな、できたらいいな」
のレベルを超えられない

10. Developer’s
Sadness
• UXの因子 「全部やれってか？」
• エンジニアリング - Program/System
• デザイニング - Concept/GUI/Layout
• スタイリング - Style/Image/Decoration
• マーケティング - Research/Promotion

11. Developer’s
Sadness
• 「わかったよ! 全部やればいいんでしょ!?」
• ディテールに深く手を入れるヒマなし
• 手付かずを埋めるだけで時間を食われる
• 忙殺されてそもそものUXを見直すヒマなし
• 気がついたら出来が悪いモノに
• これ、よく経験したし、黙ってやってると確実にこうなる

12. Developer’s
Sadness
• 「ディレクションに徹するから
細かいのは各自お願い」
• メンバー「口だけのウルセー目の上のタンコブだな…」
• 上司「皆は頑張ってたけど結局キミ何やってたの？」
• ここらへんの憂鬱はよくあるディレクターや
マネージャーの悲哀と同じ
• 実は UX Developer の一番正しい人材運用の仕方

13. Positioning
• UX 設計・開発はシングルコンバット
で出来る事じゃない
• 機能に関わる全てを以って初めて
「狙い通りに体験してくれるかも…」
というモノ
• つまり全部の面倒を見れる技能と知恵を
必要とするし、発揮できる状況が求められる

14. Positioning
• 「戦線に立つディレクター」
• 進行・調整のディレクションではない
• プロダクトの 出来 を専ら監査するディレクター
• いざとなったらそれぞれの前線に入れる
スキルと知識が必要
• しかしいつまでも前線にいたらいけない
• スタイリストは別要員にすべき

15. Aiming for Victory
• 「戦線に立つディレクター」として
運用してもらうために
• 何も言わず黙ってると
「エンジニアのタスクも投げられる便利なデザイナーさん」
として使い潰される
• 「ディレクター? 企画が兼任でいいだろ」になりがち
• 「人手が足りないから開発もデザインも出来る人をとりあえず
UXデザイナー ということで全部やらせました」
「エンジニアリングの都合もわかってくれるデザイナーに
全部つじつま合わせてもらいました」
が大抵の真相だったりする

16. Aiming for Victory
• まずは組織的に認められるように
• 利益を出して工期も短縮しちゃう
• ↑さっき売上に貢献しないとか
言ったじゃん！
• ↑工期の短縮に貢献しないとも
言ったじゃん！
• まぁ聞いてくださいよ

17. Aiming for Victory
• UX Developer をチームに入れて
• Design Principles (デザイン原理)
を定めさせる
• 徹底したコンセプトワークをさせる
• 一貫したコンセプトの元での
デザインワークやエンジニアリング
• マーケティングの精度向上や
手早いスタイリング、リテイクも
狙えないわけではないよね？
• 事業主にはここで納得していただく

18. Aiming for Victory
• UX Developer がチームにいることで
• メンバーが「いいゾ∼これ」って思ってくれるように
Developer が働く
• 上長も「面倒みる部分(質の高さとか)が減って嬉しい!」
と思ってもらえるように働く
• ディレクターが「進行の把握と計画調整だけになって
助かるわ∼」と楽になるように働く
• 生々しいハナシですね！！！

19. How should it begin?
• 普通にやってると
「開発もデザインもできちゃう便利屋」
にされてしまうことは前述した
• これまで UX Developer が居なかった場所では
仕事の分担 を分けてもらう必要がある
• 受け入れ態勢が出来てなかったり、
それ を期待されてない事多々あり
「いや、黙ってコードも書いてデザインもやれよ」って言われないように

20. How should it begin?
• (その1) ワーキングフローそのものを
UX Developer が改善させる
• 自分の職場を UX 設計・開発の対象として演習
• これ自体チームメンバーにとって、
UX 設計・開発をよく理解してもらう好機になる
• UX Developer にとっては良い練習にもなる
• チームの性格で馴染むワークフローが違うので
合ったやり方を見極めるのが重要

21. How should it begin?
• (その2) 企画が持ってる
プロダクトの「一番大事なこと」
を最大限に引き出す
• (たぶんしたことが無かったであろう)
Design Principles の設計
• これまでに無い程の骨太の
コンセプトワークをやってみせる
• デザイナーが楽を感じれたらしめたもの

22. Homework
• (1) 今の自分とチームの取り組み方を
UX開発対象として分析する
• ユーザーは自分を含めたチームメイト
• 仕事のゴールは何だったかの確認
• 今抱えている問題・課題は何か
自分らの問題を考察も解決もできずに
見知らぬユーザーのUXなんか考えられるわけないだろ
と自分に言い聞かせよう

23. Homework
• (2) 外部要因に依らない、宿題 (1) の
問題を改善するアイデアを出す
• 他所様の所為にしてれば楽だけど
一向に良くなったりせんよね
• 実際にプロダクト出した時に
「 他の所為 でUXが実現しませんでした」
とか情けない言い訳できないよね
実際の UX 開発も外部要因は考察と分析の対象であって、
設計自体は内部要因をどうするかしか出来ません
と自分に言い聞かせよう

24. Homework
• (3) 今抱えてる案件の
グランドコンセプトを
もう一度言語化する
• グランドコンセプトって案外やってるところ少ない
創業100年かつデザイナー専用スタジオ持ってる
超大手メーカーくらいしかやってないのでは
• 宿題（2）がこれだけで解決されることあり
実際の UX 開発もグランドコンセプトから
と自分に言い聞かせよう

25. Homework - Hint
• ヒアリングはすべての基本
• 因果関係の根を探れ
• 「様々な工夫」より「一つの突破口」
• シンプルであるほど強いと知ること
案外「お菓子食べながら雑談する時間をつくる」みたいな施策で
拍子抜けするくらい上手く行ってしまうことだってあるよ

26. Next
What learn for
UX Development
よりよい UX を提供するために
何を知るべきか
お楽しみに