【読書感想】ユーザー中心組織論
UXについてもっと深く学んでみたいなと思いkindleを探していたところこの本に出会いました。
UXについてのアプローチやフレームワークについて学べるのはもちろん、組織としてどうユーザーに向き合うべきかが書かれている本でとても良い本でした！
読みやすい文体で1日で読むことができました。
チームでどうユーザーに向き合うべきかわからない、チームがうまく機能しておらず悩んでいる、UX手法について学んでみたい方におすすめな本です。
チーム崩壊で悩んだことがある私にとっても共感する部分が多くかなり刺さる本でした。
良い本だったので備忘録としても活用したく印象に残った章をまとめましたので是非ご覧ください！
2章 ユーザー価値
この章ではユーザーにとっての価値について詳しく書かれており、ユーザー視点に立つにはどうしたら良いかや実践的なインタビューやフレームワークについて書かれていました。
意味的価値について
ユーザーの価値には「意味的価値」と「機能的価値」の二つがあります。
ここではカメラを例にしてみます。
「機能的価値」は例えばカメラに例えてみると、画質や望遠機能などカメラが持つそのものの機能を向上させることを意味します。
「機能的価値」は一部のマニアックなユーザーには需要があるものの、それ以外のライトなユーザーのとってはあまり価値を感じるものではありません。
「意味的価値」は昔のカメラ付きケータイなどがそれにあたります。
画質も荒いしサイズも小さいけれど、撮影した写真をリアルタイムで他の人に送れることは、ユーザーにとって自分が撮った写真を手軽に多くの人に見てほしいというインサイトを満たしており「意味的価値」をもたらしました。
ユーザーの視点に立つことが「意味的価値」を見出す最初の一歩だと感じました。
ユーザーインタビューなどで欲しい機能や今不便に感じていることなどは出てきますが、ユーザー自身がインサイトに気づいていることはほぼないと思うので、インタビューなどを通じてユーザー課題を抽象化し、どんな意味的価値があればいいのか考えることが大切と感じました。
「OODA」というフレームワークについて
ユーザーのインサイトを導き出すのはとても難しいことです。
そんな時に少しずつユーザー視点を手に入れる方法が紹介されていました。
OODA（ウーダ）ループという手法です。
・観察（あるがままのデータを収集する）
・状況判断（データをもとに考え状況を仮設する）
・意思決定（仮説をもとに実際に行動する計画を立てる）
・実行（決定した計画を実行し同時に観察する）
事業会社など制作現場では同じようなことを自然と業務に組み込んでいるように思います。
ユーザーリサーチをする→仮設を立てる（ユーザーが抱える課題はこんな機能で解決ができるのではないか）→仮設をもとにラフデザインを制作する→試作したものを実際にユーザーに使ってもらいFBを得るなどです。
ユーザー視点は共感からはじまる
共感と同情の違いが書かれていたのが印象的でした。
この二つは似ているようで以下の違いがあります。
本の中にこんな話がありました。
交通事故の被害者を支援するためのサイトを作っていた時に「笑顔の写真をメインビジュアルに使うのが良い」という仮設をもっていたものの、実際に交通事故にあった被害者で重症を負った方の意見は「こんなサイトに相談に行こうと思わない」でした。
著者の方は車同士で少し接触した経験があり、その時に友人に「たいしたことはないよ」と笑顔で慰められて安心した経験からそのビジュアルがいいと思っていました。
実際被害に遭った人が求めていたのは笑顔で微笑む人物ではなく「自分と同じ状況の人がたくさんいる」ことを表現したグラフィックでした。
深刻な事故にあったユーザーが欲しいのは無関係な誰かの慰めではなく同じ経験を持つ相談相手でした。
このエピソードは共感と同情の違いがわかりやすいエピソードだと感じました。
相手の立場に立って「交通事故にあった時にどんな考え/気持ちだったんだろう？」と観察したり聞いてみてその考えを俯瞰で見ることが共感です。
一方で同情は交通事故にあった人の気持ちをわかった気になり「わかる、私も似たような経験があるからこんな気持ちなんだろうな」と経験したことがないことを自分の経験で補うことが同情です。
とても似ていますがわからないことを穴埋めするのではなく、ユーザーに寄り添いながら気持ちや行動を理解する姿勢が大切だと感じました。
人間の性質としてわからないことを自分の体験で穴埋めして気持ちを想像するということがあるそうです。
インタビューなどで事実と自分の考えが混合することはよくあると思うので注意が必要だと感じました。
ユーザーインタビューについて
インタビューのスタートは知りたい問いを立ててみるところからです。
例「なぜユーザーは写真を撮るのか」
問いを立てるポイントはわからないことに気づくことです。
次に問いを知るためのインタビュー項目を考える。
「なぜユーザーは写真を撮るのか」という問いであれば以下の質問を挙げることができます。
最近写真を撮ったのはいつですか？
その時なぜ写真を撮ろうと思ったのですか？
その時撮った写真は何に使いましたか？
一番心に残っている写真は何ですか？
なぜその写真が心に残っていますか？
その写真はどこに保管していますか？
聞きたいことをあらゆる角度からたくさん考えることがコツです。
聞いてみた後は結果を振り返ります。
ユーザーが実際に言ったこと（事実）
「最近のカメラは高機能で使い方を覚えるのが大変」
その上で自分達が感じたこと（推測）
「ユーザーはきれいな写真を撮りたいが手間はかけたくないのでは」
事実と推測をすり替えないように注意することが必要です。
バイアスがかかりいつの間にか事実と推測が混同し失敗するのはよくあるパターンです。
3章 共創する組織
役割中心の共創は難しいことやいわゆる組織の縦軸横軸てきなことが書かれていました。
レストランの例えがあり、それがわかりやすいと感じました。
最初コックが一人の時は自分が思う最高のレストランを自分の思った通りに作り出すことができます。
しかし厨房やウエイトレス、ソムリエなどを雇って役割ができると、ユーザーに価値を提供するという目的を忘れ、みんなその役割を研ぎ澄ますことに集中するようになります。
厨房やウエイトレス、ソムリエは他の人がどんなことをしているのか知らないし関心がありません。
これを共創とは言いません。
共創するための5つの要素について書かれていました。
これらをユーザー中心という共通目的に合わせると組織やチームでベクトルが揃っていきます。
4章 モノづくりのビジョン
「エレベーターピッチ」というフレームワーク
エレベーターピッチというフレームワークが紹介されていました。
これはエレベーターに乗るほど短時間で相手に伝える手法のことです。
最近ではものづくりの現場で目線を合わせるために活用されているようです。
横軸で動くプロジェクトなどで、最初の目線合わせに活用したらとてもよさそうと感じました。
エンジニアやデザイナー、経営側など役割が違うと視点や意見や大切にしていることが違うことはよくあることで自分自身でも多々経験があります。
それでデザイナーが作ったプロトタイプなどを披露してみると、思っていたものと違う、、というのはよくあることです。
短い時間でできるため取り入れていくと良いと思いました。
「プロトペルソナ」というフレームワーク
エレベーターピッチは簡易的な手法なのでそれを補うためこの手法が紹介されていました。
「プロトペルソナ」というフレームワークです。
これはユーザー調査ができない時に活用する簡易的なペルソナのことです。
プロジェクトの初期などによく利用されます。
あくまで想像的であり確かなデータに基づいていないことを理解するのが必要です。
最初から完璧なエレベーターピッチやペルソナが揃っていることが必要ではなく、だんだんと解像度を上げていき視点が揃うことが必要と感じました。
5章 ビジネスとの統合
「リーンキャンパス」というフレームワークが紹介されていました。
この本ではさまざまなフレームワークが紹介されていましたが個人的にはこれが一番理解が難しかったです😱
これはモノとビジネスの関係を整理することで「ユーザーの課題解決とビジネスの成長がどう関係しているか」を明らかにできるフレームワークになっています。
また、リーンキャンバスはビジネスモデルをユーザー視点が中心になるようにまとめた図です。
リーンキャンバスについてはさらに詳しく説明しているサイトがあったので私も徐々に勉強していきたいです。
7章 学習するサイクル
ここでは「デザインスプリント」というフレームワークが紹介されていました。
プロトタイプを決まった時間で行うサイクルのことで、最近だと制作の現場でよく取り入れられていると思います。
機能ごとに短いスパンで開発していくアジャイル開発やスクラム開発など最近はよく聞きますがそれに近いと思います。
これは開発現場で新たなサービスを公開する際のリスク軽減のために行われています。
このデザインスプリントが全てのプロジェクトにFITするかと言ったらそうでない場合も多そうです。
ウォーターフォール型の方が適しているPJももちろんあると思いますが、まだ何を作るか決まっていない場合やユーザーにとっての価値がまだ不明瞭な場合などに使えるフレームワークかなと思いました。
私の会社はウォーターフォール型のPJが多かったのでこのフレームワークも経験してみたいところではあります、、！
8章 カルチャーを築く
この章を読んだ時、先日YouTubeをみていた時に出会った言葉を思い出しました。
カルチャーは、長年の歴史の中で社員たちの間で層のように脈々と受け継がれたモノだから簡単にはなくならない
会社選びの時にもカルチャーがフィットしているかはかなり重要と思います。
良い習慣が根づけば社員の行動は良い方向に行くし、逆に悪い習慣が根づけば簡単に組織は崩壊してしまいます。
私は組織崩壊を経験したことがあり、カルチャーの話はすごく納得できました。
私の経験をお話しすると、1年の間に制作のチームメンバーがどんどん退職し、残ったメンバーの雰囲気が悪くなり、メンバーの間で他責や無関心な習慣が生まれました。
誰も結果や進捗にこだわらなくなり、会話がなくなり、そのチームからは何も良いアイデアは生まれなくなりました。
本書には良い組織のサイクルについて書かれています。
悪い組織のサイクルについても書かれています。
私のチームは半分以上のメンバーの退職というネガティブなイベントによって、まさに悪い組織サイクルが生まれてしまっていました。
組織の関係性の質が深刻であればビジョンやビジネスよりも先にカルチャーの改善に注力する必要があるとあります。
チームが機能不全に陥るプロセスが以下のように書かれていました。
一度崩壊したチームは簡単には修復せず難しい部分はありますが、こうならないよう事前に食い止める行動をすることが大切なように思います。
また会社自体が組織の崩壊に対して問題意識を持つことが大切と感じます。
9章 小さく行動をはじめる
組織の成長フェーズのモデルを心理学者タックマン氏は以下の4段階で説明しています。
「形成期」
「混乱期」
「統一期」
「機能期」
組織が今どのあたりにいるのかで振る舞いを変えることが重要と感じます。
もし「形成期」ならメンバーを知ることに注力する/「統一期」にいるなら目標設定やドキュメント化などに注力するなどですね💭
制作現場では少人数のチームや会社が多いので、一人がチームに及ぼす影響はとても大きいはずです。
自分もチームの一員であると認識し、行動を意識することが重要と感じました。
10章 共創ムーブメント
良いカルチャーや良いチームワークを最初は少数からどんどん広げて組織に浸透させることが大切です。
組織でのムーブメントを拡大するには自分達の活動を発信することが大切です。
ここではそんな良い習慣を浸透させるためにストーリーテリングが重要と書かれています。
最近はウォンテッドリーやnoteなどでもチームでの取り組みが発信されることが多くなりましたが、採用などでも有効なのはもちろん、チーム内でも取り組みを気軽にシェアし良いムーブに賛同してくれる人をどんどん集めることが大切と感じました！
著者の方の体験談もこのように記載されていました。
ユーザーに価値を届けたいと思っていた著者はさまざまな手法をチーム内に取り入れる取り組みをしておりそんな中ある同僚からユーザー中心なデザイン手法を組織に浸透させたいと相談されすぐに手を貸したのだそう。
それからは社内のチャットにUX勉強会のグループを作ったりし、良い手法が生まれ始めどんどんメンバーが増えたのだそう。
最初に習慣を全体に浸透させるのは勇気がいるし難しいものですが、最初は隣のだれかに声をかけてみて小さく取り組み始め、徐々に全体に浸透させるような取り組みができると良いなと感じました。
まとめ
UX手法の具体的なフレームワークから、ユーザー中心の組織づくりの話まで幅広い観点で「UX」について書かれている本でした。
UXを学び始めの自分にとっても読みやすく、簡単に取り入れられるフレームワークもいくつか紹介されていたので業務でも取り入れてみたいと感じました。
また、6月から転職で新たな職場にいく自分にとって「ひとり」がチームに与える影響はとても大きいのだと感じました。
新メンバーだからといって受け身にならず早いうちからチームの一員だと自覚して行動していけたらいいなと感じました💭
この記事が気に入ったらサポートをしてみませんか？