ユーザーエクスペリエンス（UX）という言葉をよく耳にするようになりましたが
UXってそもそも何だかわかりますか？
私はよくわかりません！

そんなUXを、エンジニア目線で噛み砕いてみたいと思います

目的

UXとは何者か
エンジニアとしてどう向き合えば良いのか
問題と対策

対象者

主にエンジニア

UXってアレだろ・・・UXだろ？　な人
UXを調べると目眩がする人
UXのUXは良くないと思う人
UXと聞くとズンドコベロンチョを思い出す人

注意

私はただのエンジニアです
よくある「UXとは」よりも一歩引いて外側から考えます
いろいろ喧嘩売ってるように見えますが、そんなつもりはないです（震え声）

要約

適当な要約

いろいろな経緯があり、UXのスコープは超広範となりました
そのため、UXという概念は実践で安易に使えるようなものではありません
UXの1機能レベルで見ると、有用なものもそこそこありますが、再定義されたものが多いです
UXには炎上因子が含まれているので、取り扱いには十分注意してください
UXという単語は誤解を招きますし、意味としてはほとんどトートロジーです。できればエンジニアは積極的に使わないようにしましょう
「UX」が出てきたら、まずは企画層のことなのか要件定義以降のことなのかを分けましょう
~~Fuckin UX~~

理解できないものに、どうアプローチするか

※飛ばしてもいいです

いつも開発でやってるような方法を取ろうと思います
「何か理解できないクラスや仕様に向き合う」ときのアプローチです

この図はエンジニアが普段開発でやってることを項目にしただけです

こんな感じです

経緯

どういう経緯でそのクラスが作られ、編集されたか
目的や要件は何だったのか
例えば、commit logを見るなど

属性

それは何なのか
super classやフォルダ構成などから調べる

認識

他のメンバーはそのクラスをなんだと思っているか聞いてみる

使い手

他の主なクラス使用者はどういう理解や意図で捉えてるのか聞いてみる

目的（ゴール）

自分の目的を考える
例えば、チケットや一つのタスクと考えると分かりやすいです

問題

目的に対して、その複雑なクラスや仕様がどうブロック要因となっているのか考える
（もし問題じゃなければ、そんなの放置しておけばいいですから）

協調

既に使っている使用者と足並みをそろえる
足並みを揃えないとスコープがわからなくなって非常に危険ですから

利用する

わからないクラスでも、とりあえずどうにかおっかなびっくり使ってみる
とりあえず使えるところだけ使う

UXが理解できないことを理解する

UXが理解できない理由とは？

UIって分かりやすいですよね
何を、どこに、どういう形で、どういうふうに配置するのが効果的か
UIってこんな感じじゃないでしょうか
定式化できそうですし、硬い頭でも理解できます

しかし「UXが」と聞くと未だに「うわ、何か曖昧なこと言い出したぞ」という印象を持ちます
ひょっとしたら私だけかも？　と思って調べてみたら、ちょくちょく似た意見の人を見つけることができました
ただ、この業界では知らないことでも知ってる風を装わなきゃならないことが往々にしてありますし
知らない人はわざわざ「知らない」と情報発信することが少ないので、実際に皆がどう思ってるかは見えません

私が理解できない理由

定義とスコープが曖昧だからです
「UXが大事なのは分かった。でUXって何？どこまでUX？どう使うの？」という感じです

こういう時はWikipedia先生に聞きましょう

Wikipedia - ユーザーエクスペリエンス

デジタル機器/システムに対するユーザーの見方に影響を与えるようなアーキテクチャやインタラクションモデルの生成に関する手法である。「製品とユーザーのインタラクションのあらゆる面、すなわちどのように気づかれ、学ばれ、使われるのか」をその適用範囲とする。
ユーザーエクスペリエンス（UXと略記されることが多い）は、ISO 9241-210[2]において「製品、システム、サービスを使用した、および／または、使用を予期したことに起因する人の知覚（認知）や反応」と定義されており[3]、ユーザーがある製品やシステムを使ったときに得られる経験や満足など全体を指す用語である。
2010年に専門家（研究者・実務家）30名がユーザーエクスペリエンスの核となる概念について議論し、その成果を『ユーザーエクスペリエンス (UX) 白書』として発表した[4]。その中で、 (1) ユーザーエクスペリエンスは「現象としてのUX」「研究分野としてのUX」「実践としてのUX」という3つの視点から捉えられるということ、 (2) ユーザーエクスペリエンスは対象とする期間の違いによって「予期的UX」「一時的UX」「エピソード的UX」「累積的UX」の4種類に分類できるということ、 (3) ユーザーエクスペリエンスに影響を与える要素は「文脈」「ユーザー」「システム」の主に3つのカテゴリに分類できるということが指摘されている。

吐きそう。
頭がいい人ならこれを理解できるんでしょうか。
　
　
こういう時は英語版Wikipedia先生です
Wikipedia - User experience

User experience (UX) refers to a person's entire experience using a particular product, system or service.

これならちょっとは分かります
つまり「プロダクトに対する使用者の経験全部」ってことですね
でも、それってプロダクトの価値全てじゃ？
　
　
いつもお世話になってるような、分かりやすく丁寧に用語解説してくれるWebサイトも読んでみます
しかし狐に化かされたような気分にしかなりませんでした
　
　
UX白書はまだ若干分かりやすいです
日本語訳を公開されてる方がいらっしゃいましたので紹介します

本家：http://www.allaboutux.org/
http://site.hcdvalue.org/docs
http://www.slideshare.net/hcdvalue/ux20111015
http://albatrosary.hateblo.jp/entry/2015/01/11/133405
https://docs.google.com/viewer?a=v&pid=sites&srcid=ZGVmYXVsdGRvbWFpbnxoY2R2YWx1ZXxneDo2NWIxZTQwMTdjYTU1YTNm

でもちょっと待って下さい

2010年に専門家（研究者・実務家）30名がユーザーエクスペリエンスの核となる概念について議論し

専門家がUXとは何かを議論しなきゃならない状況って何なんでしょうか

そもそもUXは学問だった（経緯）

調べていくと、ビル・バクストンというカナダの学者さんにたどり着きます（提唱者？）
彼はその後マイクロソフトに入ったらしいのですが、どういうことを考えていたかはこの記事と動画を見ると何となくわかります
http://builder.japan.zdnet.com/blog/10514743/2010/04/08/entry_27038919/

2010年といえばiPhone4が発売された頃でしょうか
実際は2000年より前に既にUXみたいな概念があったらしいので、そう考えるとすごいですね
何が言いたいかのかも何となくわかります
たぶん、UIだけじゃないよ、その周辺も含め大事だよ、みたいなことですよね？
「ITにおけるデザイン」というのが徐々に固まっていく過程で「それじゃ足りない」と提唱したくなるのも分かります
（WindowsXPでそこら辺を考え始めたそうです）
　
しかし今のUXはそのコアとなるものに、色んな物がおまけとしてくっついています
2010年時点でのUXの定義を集めたリストがこちらです
http://www.allaboutux.org/ux-definitions
聖書のほうがまだ分かりやすいです
　
そこら辺の「定義広すぎてまずない？」議論ははるか昔にあったらしく、英語版Wikipediaにも書かれていました
Wikipedia - User experience（再登場）

In an interview in 2007, Norman discusses the widespread use of the term "user experience" and its imprecise meaning as a consequence thereof.[6]

Several developments affected the rise of interest in the user experience

Recent advances in mobile, ubiquitous, social, and tangible computing technologies have moved human-computer interaction into practically all areas of human activity. This has led to a shift away from usability engineering to a much richer scope of user experience, where users' feelings, motivations, and values are given as much, if not more, attention than efficiency, effectiveness and basic subjective satisfaction (i.e. the three traditional usability metrics[7]).[8]
In website design, it was important to combine the interests of different stakeholders: marketing, branding, visual design, and usability. Marketing and branding people needed to enter the interactive world where usability was important. Usability people needed to take marketing, branding, and aesthetic needs into account when designing websites. User experience provided a platform to cover the interests of all stakeholders: making web sites easy to use, valuable, and effective for visitors. This is why several early user experience publications focus on website user experience.[9][10][11][12]

元になったUX Week 2008でのお話
http://adaptivepath.org/ideas/e000862/

Since then the term has spread widely, so much so that it is starting to lose it's meaning.

~~やだ英語難しい~~
適当に意訳すると

Q.何か定義広くなりすぎて、意味を失いかけてない？
A.最近ITが社会にいろんな形で浸透しちゃって、必要なものが多岐に及んでしまった
　利害関係者の言うことを聞いて必要な物を全部詰め込んだらこうなった、~~俺は要件に従ったまでだ、俺は悪くない~~

実際に見てみる（認識）

では実際にどのくらい広いか見てみましょう

UXは広大

Dan Saffer氏というUXの偉い人が2013年頃（？）に描いた図だそうです
※赤文字の日本語は私が分かる範囲で入れてます

この赤い線がUXです
UIもIAも全部UXです

※それぞれの要素をゴリ押し解説しようとしましたが、それぞれが曖昧で非常に難しいので諦めました。頑張って調べれば雰囲気はわかると思います

広いだけではない、深い（構造的）

UX界では常識となっているこちらの図ですが

ソース：THE ELEMENTS OF USER EXPERIENCE
http://www.jjg.net/elements/
和訳したのはこちら
http://itpro.nikkeibp.co.jp/article/COLUMN/20070703/276582/

コンセプトから情報設計、実際のVisualDesignまで全部がUXだと言っています
簡単言えば、企画、要件定義、外部設計、デザインの実装、全てがUXです

深いだけではない、時間軸で変化する

（UX白書より）

リリース前から、リリース後までUXが変化していくと言っています

それだけではない、UXを生み出す組織も重要だ

チームビルディングや開発フローにまで手を伸ばしています
~~何でも出来過ぎてもはやTOKIO~~

UXはデザインであり、ビジネスであり、ソフトウェアであり、学問であり、研究であり、現象であり、実践であり・・・

他の例も見てみましょう

ユーザーエクスペリエンス・ハニカム
http://www.designit.jp/archives/2006/04/post_128.html
ユーザーエクスペリエンスのベン図
http://www.helloerik.com/treatise-on-user-experience-design-part-1
ユーザー・エクスペリエンスプラミッド（成熟度モデル）
http://uxpamagazine.org/ux-maturity-model/
ユニバーサルWindowsプラットフォームユーザーエクスペリエンスガイドライン
https://msdn.microsoft.com/ja-jp/mt634411.aspx

うーん疲れました、後はこのスライド見てください
https://www.slideshare.net/Hienadz.Drahun/visual-definitions-of-ux-restored-75706843
　
概念としては非常に抽象的で、唐突にTIPSレベルの具体例が出てきます
具体的な例は確かに重要なものが多いですが、概念に紐付けられません
なんかもう私の頭では言語化できません
~~敢えて言うなら偽科学に近いです、水素水みたいな~~

つまりUXの要件って

デザインそのものとか、顧客満足（CS）に非常に似ています

UXって理解できますか？　の問を
CSって理解できますか？　とか
デザインって理解できますか？　に置きかえるとどうでしょうか

UXって大事だよね！　を
CSって大事だよね！　とか
デザインって大事だよね！　に置き換えてみてもおもしろいです

何でこんなことになったのかの分析（属性）

UXという概念のユーザーエクスペリエンスが悪いということは何となく分かりましたが
何でこんなことになったんでしょうかね
アレに似てますね、スパゲッティコード・・・( ﾟдﾟ)ﾊｯ!

クラスの肥大化に似ている

経緯をおさらいするとこうです

１．UXという大事な概念つくった
２．要求に応えるように、概念にいろいろいれていった
３．概念が肥大化した
４．やべー

これってダメダメなクラス設計をした時に似てませんか？
たとえば、BaseModel、StringHelper、ViewManager
こういう曖昧な意味のクラスを作ると、特にチーム開発ではいつの間にかクラスが肥大化して
やがて技術的負債になっていきます

ちなみに似た概念
Blob（人喰いアメーバ）（死語？）
https://thinkit.co.jp/article/929/1?page=0%2C1
ゴッドオブジェクト、神クラス
https://en.wikipedia.org/wiki/God_object

言葉の意味爆発

（もはや言語学の領分ですが）
実は似たような現象は言葉の世界でも起きています
特にカタカナ語などの新語で顕著ですが
誤用されている言葉にも似たことが言えます

例）コミット、情けは人のためならず、さわり
例）正反対の意味になる誤用：http://anond.hatelabo.jp/20160805112841

発生要因はこんな感じだと思います

その概念が重要である
イマイチそれを表す言葉が他にない
字面に誤解される要因がある
言葉の意味をまだ曖昧に理解しているコミュニティで使われている（若者など）

そういった現象を私は勝手に言葉の意味爆発と読んでます
（”多義語”は違うんですよね。学術用語がないか調べましたがみつかりませんでした）

開発で言えばこうです

新しいメソッド作りたいけど（重要）
良いクラスやファイルがないよー（言葉がない）
っていうか似たメソッドが全部HogeManagerに入ってるし（字面の問題）
まあたぶんここに入れときゃいいだろー（曖昧な理解）

UXへの対処　→　肥大化クラスへの対処

この仮説から多くのことが分かります
つまり、UXという言葉への対処は、肥大化によるスパゲッティコードへの対処に似ているのではないかということです
ですがUXという言葉は既に本稼働しているので安易にリファクタできません

じゃあ一つしかないですね

( ˘ω˘).。o（見なかったことにしよう）

参考例：「プログラマー」「システムエンジニア」という用語

実は、似たような対処は既に皆行っているのではないかと思います
「プログラマー」、「システムエンジニア」という用語が昔は一般的でした
それより前には「コーダー」という言葉もありました

しかし最近は「エンジニア」が多く使われます（概念のラベル変更）
その理由は実際調べようがないのですが、私は言葉をリファクタリング＆そっ閉じをしたのだと思っています（言葉の意味破綻による死語化）

なぜなら、プログラマーはコーディングだけするのか、それ以外をするのか不明確ですし
システムエンジニアは設計以外のコーディングするのか、マネジメントまでやるのか不明確になってしまいました
それに特にWeb業界ではやる仕事が多岐に及びます

ならいっそエンジニアと呼んでしまおうというのは理にかなっています
（エンジニアリング＝工学です　→　Wikipedia - 工学）

例えば
iOSエンジニア、swiftエンジニア、Androidエンジニア　という言葉がよく使われていて
iOSプログラマー、swiftプログラマー、Androidプログラマー　という言葉はあまり見かけません（Google調べ）
比較的歴史のあるJavaですら、もうJavaエンジニアの方がヒット数が多いです（Google調べ）

ちなみに海外でも似たことは起きていて、結局「developer」という用語が定着したようですね。iOS developerとか。エンジニアはもう少し理屈・アカデミック寄りでしょうか？

改めてUXを考える（経緯）

話を戻しましょう
もちろんあくまで推測ですが、こんな経緯ではないでしょうか

昔々、いいものを作りたくて悶々としてたデザイン界隈の人たちが居ました
彼らは「UIだけじゃない、その周辺がないといいものができない」と考えました
他にいい概念が無かったので
良い物を作るための言葉「ユーザーエクスペリエンス」を作りました
今やってる仕事の方法論と、成功してるプロダクトの乖離に疑問があった人たちが飛びつきました

成功したプロダクトの方法論を解析して、UXという概念の中に再定義しました
いろんな分野にある「ユーザーにとっていいものを作る方法」を持ってきて、UXという概念の中に再定義しました
ユーザーに関わらないもの以外の全てはUXに関する手法ということになりました（まさに人喰いアメーバ）
結果、ドメインが絞られず意味が爆発し、よくわからないものになりました

よくわからないものの「成功のために必要な何か」を求める人達が、UXというものを見つけました
なんとUXクラスの中には、必要っぽいモノがいっぱい定義されているのです
やった！これで勝つる！

というわけで私も皆さんに倣ってダサダサなベン図を書いてみました

開発フローとも照らしあわせてみました

もはや「大事なもの」のトートロジーなんですが
全メソッドを1クラスに詰め込んだようなこの設計のヤバさ、伝わりますかね・・・

UX問題に対処する

UXをそっ閉じできない状況があります

エンジニア「うわ、なんじゃUXって、
　　　　　　言語設計したやつドメインとかもっと考えろよ。
　　　　　　リファクタもできないし、こんなの放置だろ」
UXの使い手「UX使いたいんですけど」
エンジニア「ﾋｴｯ」

なので、頑張って~~糞コードと~~向き合わなければなりません

エンジニアにとっての問題（目的・問題）

UX問題はエンジニアに最も実害が出るリスクがあると思います

最大の問題：不確実性を爆発させる火種

普段何気なくやっていると思いますが
エンジニアというものは企画層が描いた夢物語を動くものに落としこみ完成させるという作業をしています
ふわっふわの要件を、現実的な振る舞いに落とし込んでいき
最後はコンパイラ様という頭の硬い方にプログラムで指示しなければならない中間管理職みたいな仕事で
つまり不確実性を減らす作業です

対してUXの多くの手法はクオリティを上げるためアイディアの模索をする手法で
つまり不確実性を一旦上げる作業です

上図で言えば、UXは

情報収集タスクを重くする
案を増やす
分析、選択タスクを重くする

ことに該当します
これらはもちろんいいものを作るために必要な行為ですが
クオリティと作業量はトレードオフなので作業量は増えますし、それぞれの案を吟味し収束させるための力量が必要になってきます
（ステークホルダーが多いほど難易度は増します）

しかしUXでは作業量のコントロールの話は担保されません
また、デザイン層という認識をされているので、企画フェーズと（旧来の）デザインフェーズが一緒くたで捉えられる可能性があります

もしそうなった場合、エンジニアは

仕様がいつまでも固まらない（しかも企画・デザイン双方で）
曖昧なまま要件が提示される

というリスクを抱えることでしょう

その他の問題

上記は炎上リスクの問題ですが
UXとエンジニアには、もう２つ論点があると思います

開発への支障

最近UIデザイナーではなく、UI/UXデザイナーやUXデザイナーというのが登場したので
UI仕様書がUI/UX仕様書になるかもしれません
その時に自分がUXを理解できないなら非常に問題です

具体化できない
仕様書が読めないかもしれない（UX語、意図、意味）
デザイナーの言ってることが理解できなくなるかもしれない
知らないうちにUXバグが発生するかもしれない（非機能要件が増える）

より良いものを作る際の支障

エンジニアでも、ユーザーにとっていい物を作りたいというマインドはあるはずですが
そんな時立ちはだかるのがUXという概念です
今UXについて語られる問題はここが一番大きいでしょう

いいモノにするための方法論にUXがあるらしいが、UXが理解できない
UX手法を取り入れたいが、何が良いのか悪いのか理解できない
UXデザイナーと話をするが、いろいろ理解できない
ふわっとは分かるけど、それをどう実装まで落とし込むかわからない

問題への対処：UXの使い手を理解する（使い手・協調）

大きく分けると２パターンです

良い物作りたい人
デザイナー

それぞれ考えていきましょう

良い物作りたい人たち界隈

こちらは結構簡単です

「UX」を持ち出してくる人たちとしてはこんな感じではないでしょうか

良い物ガチで作りたい人たち（例：起業家）
良い物作りたい人たちを支援したり炊きつける人たち（例：コンサル）
良い物作りたいけど作れず悩んでる人たち（例：企画・PO・クライアント）

彼らのやってることは基本的に昔と変わってないと思います

誰かが成功する（世界規模で）
方法が一般化されコンサルが売る（意識高いブログなどで流行る）
参考にした書籍が出る
毒された人や、まっとうに学んだ人がちらほら出てくる
PMが頑張って仕様に落としこむ
（練度が低いと、タスクを振られたエンジニアが困る）

最近は「これからはデザインが重要なんだ！」と言い始めている方が世界的に増えてる気がしますが
放っておいてもリスクとしては以前と変わらないと思っています

商品開発と言う意味では昔から多くの手法がありますし
UXのほとんどはそれらを再定義したものです

また、彼らは基本的に企画層（要件定義以前）に居るので
このフェーズの不確実性が高いは今に始まったことではありません
彼らとの対話の方法も今までと大差ないと思います

良い物作れない状態の人たち

とはいえ、少し以前より熱量が高いと感じるのは
スマホ登場以降のITプロダクト開発が明らかに難化したためかもしれません
Webのように静的情報を扱うわけではないので、勝ちパターンがいつまで経っても出て来ず
なのに一部の有名企業はグングン伸び、世界経済は徐々に回復し、IT業界に金が流れ・・・
と、世界中の悶々とした人たちが手探りで勝ちパターンの模索をしていると思います
（逆にWeb1.0時代が簡単だったのかもしれません、SNS、スマホ、ビッグデータ、O2O、IoT、AI...とにかく難しいです）

IT系デザイナー業界の問題

より問題が大きいのはデザイナー＋UXです
UXの震源地がIT系デザイナーなので、デザイナーがUXを使うのは当たり前ですが
それにしても最近流行ってますよね
何故なんでしょうか

※ここからは更に推論が多くなります（検証しようがないです）

理由を深掘りしていった結果、幾つかの仮説に辿り着きました

エンジニアに比べ待遇が良くない問題（上流工程へのモチベーション）
デザインの設計フェーズに名前がついていない問題
デザイナーへの参入障壁の低さ（デザイナー間の差別化がしづらい）
ポートフォリオの重要性（いいモノが作れないとキャリアに響く）
ソフトウェアに比べ歴史が若く、規模が小さい（標準化が追いついていない）
一向にいいモノが作れない

古いですが的当なソース、ググるといっぱい出てきます
図解・どっちが勝ち組？ウェブデザイナーVSデベロッパー編
 うわっ、日本のWebデザイナーの年収、低すぎ…？

例えるならば、IT系デザイナーの現状は「エンジニアの職種がプログラマーしかない」みたいな状況だと思います
キャリアパスが整備されていなく、35歳定年説みたいな状態になってしまいます
そういった中での産物が「UI/UXデザイナー」なのではないでしょうか

UI/UXデザイナー（使い手・協調）

ここまで読んでくださった方なら「UI/UXデザイナー」の単語が面白いと気づいてくれると思います

デザイン⊃UX⊃UI

なので、単語としてどうかと思います
ではUI/UXデザイナーとは何を言い表したいのかと考えた時、上記の仮説から勝手に推測するとここじゃないでしょうか

もちろん、企画層もやりたいデザイナーも見受けられます
（特にUXデザイナーと宣言している方）
しかし大多数はこの緑色の領域を指しているのでは？と考えています

デザイナー＋UXへの対処を２パターンに分ける

だいぶ仮説が多くて怪しくなってきましたが
もしUI/UXデザイナーの多くが特に気にしているのが要件定義〜外部設計層のデザインだとすると
話を要件定義前と要件定義以後に分けることができ、これが重要になると思います

UXの手法がデザイナーにより企画層で用いられた場合
UXの手法がデザイナーにより要件定義～外部設計層で用いられた場合

もちろんUI/UXデザイナーの中にもUXの名の下、両者を混同している事が多いでしょうが
そこを切り分けることに異論はないのではないかと思います

UXの手法がデザイナーにより企画層で用いられた場合

UI/UXデザイナーの、企画層に対するモチベーションが高まった時
あくまでフェーズを切り分けた上で、どう対処するかです

これは当たり前に対処すればいいと思います

ちゃんと収束させましょうね
開発フェーズに入ってからのちゃぶ台返しはほどほどにね
理詰めで議論しようね
ちゃんと予算とスケジュールとって計画的に実行しましょうね

UXの手法がデザイナーにより要件定義～外部設計層で用いられた場合

この層を主に取り仕切るのはディレクター・PM・PO・プロデューサー・スクラムマスターなどと呼ばれる人たちです（Controller）
彼らが取り仕切る領域と、UXが気にしている領域はこのような差があります

この緑の領域でクオリティアップ（＝不確実性増）の施策を打つのであれば
その他の領域にも作業量増加という影響が出ることを覚悟しなければなりません

そこで提案ですが、どれだけ凄いUXデザイナーが現れてもControllerとなる人を逃がさないことをオススメします
Controllerはエンジニアと同じくらいに不確実性を下げることが仕事なので、UXを使う際はバランサーとして重要になってきます
Controllerをデザイナーがやったり、エンジニアがやったりはできなくはないですが非常に厳しい戦いになるはずです
（特にバランス感がある人がいいです。Controllerが「もっとクオリティ上げるんだ！」と暴走したら余計にこじれます）

「いや普通に考えたらController不在とかありえないだろ」と思うでしょうか？
凄腕UXデザイナーが現れた時、どこからどこまで担保するのかわかるでしょうか
（余談ですが、UXをバリバリ取り入れているデザイン会社でも、プロデューサーは別途用意しているのを聞いたことがあります）

なお、緑色の領域に引きづられたとき、特にフィジビリティスタディが漏れがちになるはずです
そういう意味で、UXが飛び交う会議にはエンジニアが積極的に関わっていく必要が出てくるでしょう

※デザインの要件定義〜外部設計

ちなみにデザインの要件定義〜外部設計は、例えば導線や画面設計のようなものが入ってくると思います
これらは全専門領域の理解と調整が発生するため、未だにディレクターなどが片手間でやっているケースも多いです
全ての設計の基礎になる非常に重要なタスクですが、誰がやるのかイマイチ決まっていなくなぜか工数も多く取られないケースが多いため
この領域の専門家が増えることは喜ばしいことですが
大変な作業なことは違いないので注意が必要です
（エンジニアからマサカリ飛んできますしね！　しかも意外と評価もされないんですよね）

「良い物作りたい人」と「UXデザイナー」の悪魔的コラボ（問題）

もう一つ気をつけることがあります

両者がそれぞれの領域で非常に有能だとしても
話してるレベル（抽象度）が違うと話がぐちゃぐちゃになります
そこで必死になるのはもちろん実装するエンジニアです

例
https://www.youtube.com/watch?v=BKorP55Aqvg
解説：http://nlab.itmedia.co.jp/nl/articles/1404/07/news118.html
~~翻訳機能便利ですね~~

もちろん今までは様々な理由で両者は分断されていましたが
それがUXという言葉で繋がってしまいました

企画層「デザインに興味出てきた」
デザイナ「企画層に興味出てきた」

こうなると、上の動画よりさらにこんがらがります
もちろん両者が２領域でプロフェッショナルならいいんですが

「UX」が現れたらやることリスト

UXというワードに引きづられず、話を具体化しましょう
簡単に言えば「それは不確実性を上げるもの？下げるもの？　模索すること？前にすすめること？」の明確化です
　

話をまとめられそうな人をアサイン（PM・PMO・チームリーダー等）
そのプロジェクトにおける何の問題を解消するための、どういう方法論の導入なのかの議論
その問題は本当に問題なのかの議論
その方法論は本当に解決するのかの議論
誰が何を担保するのか
どのフェーズで何をするか切り分け

なおダメそうなら

UXを利用する

ここまで色々言ってきましたが
UXが全く無価値というわけでもないと思います

どうやったら使いこなせるか考えてみます

その前に、自分の仕事にクオリティアップはどれだけ重要か

QCDはトレードオフします
安易な「品質は高いべき論」はただの品質過剰になりかねません

まずは自分の仕事でほんとにUXによるクオリティアップが必要かを考えることをオススメします

不確実性を下げる、狭義のデザイン領域のUX

そんなこともうやってるよ！　と言われそうですが
まずはUIやIAあたりの領域において、既にナレッジ化されている知識を集めるといいと思います
そういったものは、アイディアの取捨選択に役に立ちます
不確実性を減らす上にデザインもよくなるはずです

これはUIですが、例えばこういうのです
https://goodui.org/

アプリで言えば、AppleやGoogleが出しているガイドラインがそれに含まれます（上の例で出てきたWindowsのUXガイドラインもそれに該当しますね）
また、他のサービスを観察しまくるというのも手だと思います

これだけならエンジニアでもできるし、した方がいいレベルですよね

本格的に手を出すならアジャイル必須？

UX手法をまともに運用するとどう考えてもコストが高いです
そういうリスクをコントロールするには小さく開発し小さくリリースすることが必要不可欠になると思います
（いわゆるリーン・スクラム・DevOpsあたり）

とは言え本格的なアジャイルの導入はそれだけでハイリスクです
もしそれができないなら副案として二次開発からUX手法を導入するというのがあると思います
「なるはやで作りきってから考えようよ」と主張すると上手くことが運ぶのではないでしょうか
ただしこの手法では企画層のUXは中々変更できなくなるので、「狭義のデザインで不確実性を上げるUX手法」にしか使えないと思います

もちろんモックフェーズで使うと企画層のUXにまで手を入れられますが
コストは増えるので、コントロールは慎重さが求められそうです
（短サイクルでモックフェーズを繰り返しやれば、徐々にアジャイルに近づいていきますね）

UXを入り口に、より詳細な領域へ

繰り返しますが、UXは色んな所から手法を集めています
よくよく調べたら「それマーケティングのアレでしょ？」とか「経営戦略論で大昔からあるやつじゃん」みたいなこともあります
なので気になった手法の元ネタを辿っていけば、自分の知りたかった手法郡に出会えるかもしれません

その他

これからどうなるUX

最近、UX戦略、リーンUXのような○○UXがどんどん登場しています
喩えるなら巨大なクラスの拡張です
やばいです

UI/UXデザイナーには優しくしたい

業界設計がカオスですから

UX＋日本＝ヤバイ

UXという概念は本場アメリカでもまだまだ発展途上だと思います
なのにアジャイル導入もまだな日本に輸入するのは、悲劇を多く生むのではないでしょうか
（情報発信しているような極一部の超優秀な方々を除きます）

よそはよそ、うちはうちでゼロベースで考えたいですね

企画層のUXの移植元？

この領域は意外と昔からあるんですよね
しかもすごく深く歴史があるので
本気でやるならそっちをまず勉強したほうが早いのではと思ってます
あとは、創作界隈、ゲーム界隈にもヒントが非常に多いです

キーワード

商品開発
サービスデザイン（これもデザインだぁ）・サービス設計
顧客開発
マーケティング・営業・企画
経営学・MBA

（もっとある気がする）

旧来の概念に足りないものは

グロースハック
リーン

あたりに集約されつつあると思います
いずれにしても生半可に手を出せる領域じゃないですが

顧客志向、UX、人間中心デザインなどの罠

どういうわけかシステムやサービスになると「もっとユーザーの声を」という流れになりがちですが
ユーザーの中に正解は無く、あくまでユーザーは選択するだけという罠があります

これについては多くの方が既に言及していますし、創作界隈では誰でも知っていることですが
エンジニアなどがUXなどの概念に浅く触れてしまうとそれに気づかず深みにハマるケースが出てきます
その場合は「読者にこびたら売れる漫画が書けるのか」のような自問自答が必要かもしれません
良い物への道は険しいですね

UXの登場でデザイナーの待遇はやはり上がっているらしい（2016/08/22追記）

興味深い記事があったので紹介します
変わり始めたデザイナーの仕事内容と給与

こういうのが世間に認知されると、更にUXデザイナー志望者が増え
UXに接する機会は増えるでしょうね

おわりに

お疲れ様でした

我ながら難解かつ長文になってしまい、伝わるのか・本当に正しいのか、甚だ疑問ですが
似たように危機感を抱いている方の思考材料にでもなれば幸いです

目的

対象者

注意

要約