UXploration

バリュー・プロポジションを言語化してみよう！

2019-08-29T15:30:16+09:00

この記事では、プロダクトやサービスの提供価値を言葉でシンプルに説明する方法をご紹介します。

プロダクトやサービスを開発している中で、聞かれるとちょっとドキッとしてしまう質問があります。

そのプロダクトの価値ってなんですか？

なぜドキッとしてしまうかと言うと、どのような言葉で説明すれば納得がいく回答になるのか、戸惑ってしまうためです。

プロダクトやサービスは何かしらのユーザーないしは社会の問題を解決しています。解決しているからこそ、存続していると思っています。そのため、プロダクトやサービスの価値はなんですか？という問いに対する回答には、どんな人の、どのような課題を解決しているのかが明確に具現化されていなければ、自身を持って答えることができずにモヤモヤが残ってしまいます。

そもそもなぜ具現化する必要があるのか？

ぼくが好きな言葉のひとつに以下があります。

Customers don't care about your solution. They care about their problems.（ユーザーはソリューションに興味はない。ユーザーが興味があるのは、自分自身がどのような問題を抱えているからである。）

米サンフランシスコで多くのスタートアップのアクセラレータープログラムを提供している 500 Startups の Dave McClure 氏の言葉です。

ソリューションはなんであれ、ユーザーはプロダクトを利用するきっかけとして、自身が抱える問題が解決されるのか否かを気にしています。そのため、どのようなソリューションでも、どんな問題を解決してくれるのかが具現化されていないと、ユーザーとの距離が遠ざかってしまって、つくることだけに注力してしまいがちです。それはチームにとってもよくありません。

結果としてリスクが膨らみ続け、ユーザーに使わなくなったり、改善に向けて検討を開始する際にプロダクトやサービスの存在価値を問う場面に直面してしまって、あたふたして逆戻りしてしまいます。ぼくも以前、その状況に陥ったことがありました。「解決したいこと」よりも「開発したいこと」が先行してしまい、開発して満足してしまうケースです。

どのように言語化すべきか？

具現化するためには、まず言語化する必要があります。言葉で表すことができなければ、もちろん伝達することはできませんよね。

そんな居心地の悪さから打破するためには、プロダクトやサービスの提供価値の言語化が効果的です。それも、対象の価値が一目でわかるようにすることです。

プロジェクトチームでバリュー・プロポジション・ステートメントのアイディアを考えている様子。後ろでカメラに向けに笑っているのはぼくと Pivotal Labs のもう1人の PM です（笑）

そこで今回ご紹介したいのは、Pivotal Labs でプロダクトやサービスの提供価値を言語化する手段の一つとして用いられているバリュー・プロポジション・ステートメントです。以下がそのフォーマットです。

〜は（ペルソナ）
〜のとき（コンテキスト）
〜ができていないだろう。（課題）

この〜は（ソリューションまたは機能）
〜とは違い（競合またはいまの解決策）
〜をすることによって（提供価値）
〜は（ペルソナ）
〜できる。（ユーザーが得られるアウトカム）

イメージしやすいように、例を挙げてみます。

電車の新しい乗り換え案内アプリを開発していると過程して、ペルソナの名前はタカシさんとします。ユーザーリサーチで特定した、ビジネスにとってもユーザーにとっても優先度が高く、解決すべき問題にアプローチするための提供価値を、バリュー・プロポジション・ステートメントにあてはめてみると以下のようになります。

タカシさんは
目的地（駅）に向かうために電車に乗るとき
ちゃんと時刻通りに電車が動いているかどうかを必要なときに把握できていないだろう。

このプロダクトは
（競合のプロダクト名）とは違い
正確かつ最新の運行情報を提供することによって
タカシさんは
どの電車を利用すればよいか自信をもって選ぶことができる。

実際のプロジェクトではコンテキストや課題をもっと具体的に記載していますが、提供価値をこのようにステートメントとして言語化することによって、冒頭の質問をされたときに、チーム全員が自信をもって回答することができるようになりました。

つくったあとはどうするべきか？

バリュー・プロポジション・ステートメントのいいところは、以下がひとまとまりで表現されていることです。

誰が、どんなときに、どのような問題に直面しているのか
他と比較して、なぜこのプロダクトでなければ解決できないのか
プロダクトの価値を届けることで、ユーザーが得られることはなにか

そして、このプロダクトでなければいけない理由をビジネスとユーザーの双方から捉えることで、北極星を見失わずに済みます。

バリュー・プロポジション・ステートメントはつくっただけで満足するのではなく、常に振り返ることが大切です。時間の経過と共にユーザーもマーケットも変わっていくため、様々な調査を進めながら変化に合わせて柔軟に更新し続けていく必要があります。

そのためには継続的にユーザー調査を実施することをお勧めします。プロダクトマネージャー、プロダクトデザイナー、エンジニアなどメンバー全員で優先度が高いと判断したユーザーの課題を解決するための価値が反映されているか、がポイントになります。

もしお時間がある方はぜひやって見てください😆 そして、やってみた感想などをコメントなどでフィードバックしていただけると嬉しいです。

*Originally published at https://link.medium.com/f2M5wdzAxZ on Aug 15, 2018. Pivotal Labs Tokyo の公式ブログに掲載した記事の転載です。

Q思考と UX デザインーー正しい答えよりも正しい問いを

2016-07-12T17:30:02+09:00

ハウツーが豊富な実用書ばかりを手に取るくらいなら、『Q思考』という書籍を推奨します。もともと当ブログでも何度も言及しているとおり、首題となる人間中心設計や UX デザインと呼ばれている手法体系は「問題解決」に重きを置きがちです。問題を解決するための手段として徐々に普及していますが、正しくモノをつくろうとする（正しい答えを求めようとする）意識が先行してしまうが故に、正しいモノの追求（正しい問いの追求）という本質が抜けてしまっているように思えて仕方がありません。

Q思考――シンプルな問いで本質をつかむ思考法

作者: ウォーレン・バーガー,鈴木立哉
出版社/メーカー: ダイヤモンド社
発売日: 2016/06/24
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

人はなぜ答えを求めたがるのか？

(image courtesy of shutterstock)

Q思考の文脈に照らし合わせて言うならば、旧式での決まりきった方法やアプローチが幅を利かせているが故に、人は問いに時間を割くことを忘れ、答えこそが問題を解決し、我々を前進させ、改善の道を示してくれるという思い込みが生まれてしまいます。ではなぜ人は答えを求めたがるのでしょうか？本書ではその理由を以下のように説明しています。

問いを探ることは権威に刃向かうことになるという思考が働きやすい
確率された既存の仕組みやプロセスを混乱させるという脅威が働きやすい
なぜその答えを求めているのか、問いに向き合う時間が不足しがち
効率重視の思考が働き、物事を考える視点が「モノをつくる」視点に偏っている
教育上、問いよりも答えを重んじるように教えられてきた
失敗への恐怖心が問いを探る思考や行動を阻んでいる

ほとんどの学校では生徒たちは質問よりも答えを重んじるよう教えられており、しかも大半の問題について正しい答えは「一つだけ」だと言われることが多いため、「答え」というものが世界のどこかにあって「発見される」、あるいは「偶然見つかる」「調べられる」「獲得される」「購入される」「手渡される」のを待っている、と私たちが考えてしまうようになるのも不思議ではない。

過去のエントリー「二輪駆動の人間中心設計」でも述べましたが、モノをつくるという観点から物事を考えてしまっては確率された人間中心設計のプロセスや手法で予め定められた手順を重視してしまうあまりにプロセスのツールやドキュメントなどのアウトプットに重点に置いてしまう傾向にあります。しかし、本来のモノづくりはユーザーにとって価値のある製品やサービスをつくり、提供することです。

そのためには本書でも述べている通り、

「モノをつくる」という観点から「問いを探る」という観点で物事を考える
製品やサービスは「具現化された問い」であるという思考に転換する

必要があります。

正しい問いは何をもたらすのか？

(image courtesy of shutterstock)

Q思考の著者は問いを「知性のエンジン」と称し、モノづくりを問いを探るための実験に次ぐ実験とと捉えるべきであると謳っています。これはモノづくりにおけるグッズ・ドミナント・ロジックからサービス・ドミナント・ロジックへのパラダイムシフトにも通ずる理論であり、製品やサービスを生産して顧客に届ける、というアウトプット単位のグッズ中心の考え方から製品やサービスはあくまでも顧客とサービス提供者間のインタラクションを実現するための手段であり、互いの問いを解決していくための価値交換を中心としたサービスエコシステムの構築という考え方への転換の必要性を意味します。

また、本書ではイノベーションの公式を以下に定めています。

基本の公式は「Ｑ（問い）＋Ａ（アクション）＝Ｉ（イノベーション）」だ。同時に「Ｑ－Ａ＝Ｐ（フィロソフィー）」となる。

アクション、つまり実行や問題解決のみではイノベーションは生まれません。「イノベーションを起こせ」というアクション主体の考え方では正しいモノへと導くことが難しくなり、間違った使えるモノが生まれてしまいます。そのための回避策としてクエスチョン、つまり正しい問い、問題発見や問題定義を疎かにしてはなりません。

組織のトップにいる人たちはなぜ出世できたのだろうか。それは「答えを出すのがうまかったから」だ。「一方でそれは、問いを生み出した経験はあまりないことを意味しています」。

正しくモノをつくるよりも、正しいモノをつくる

正しくモノをつくるよりも、正しいモノをつくるー著者が常に頭の片隅に置いている信念です。

問題解決としての人間中心設計、UX デザインは語り尽くされました。ケーススタディも検索すれば大量にヒットします。しかし、ケーススタディに代表される手本に頼ってしまっては問いを拒絶してしまう思考に陥りやすくなるので注意が必要です。「現代は質問の黄金時代」とQ思考の著者は話します。オンラインのソースから答えがすぐに手に入る時代だからこそ、投げかけるべき正しい問いや解決すべき正しい問いはなんなのか、に時間を割くべきなのではないでしょうか。

答えからは距離を置き、問いの中に居続けること。

最後に、本書では問いを効果的に探るための問いかけの方法も紹介されていますのでオススメです。

UX戦略とはなにか？

2016-06-16T15:12:41+09:00

結論から言うと、UX戦略は概念であり、手法ではありません。UX戦略とは UX デザインの3つの対象領域であるビジネス、プロダクト、そしてユーザーすべてを対象範囲として UX デザインの活動に含めることを指す概念だと著者は考えています。

以降はその思想に至った背景と、UX戦略を理解するために著者が整理した枠組みをご紹介します。読者のみなさまにとって、少しでもお役に立てれば幸いです。また、この記事がきっかけとなって UX戦略に関するディスコースがこれまで以上に活発になることを願って。

背景となる思想

UX戦略を語る上で、以下の2人のキーパーソンは欠かせません。

Paul Bryan（ポール・ブライアン：以下、ポール）
Jamie Levy（ジェイミー・レビィ：以下、ジェイミー）

ポールは UX戦略に特化した世界初のカンファレンス「UX STRAT」の発起人として2012年より活動しているコンサルタントです。著者も在籍していた UX戦略に関する専用グループー現在は活動休止中ーを LinkedIn 上で立ち上げ、概念としてまだ確率していなかった UX戦略に関するディスコースを活動の中心としていたグループで、「UX STRAT」の開催も当グループの強い要望によって実現されました。

いまでは北米やヨーロッパ全土でカンファレンスやワークショップが開催されるほどその活動範囲を広げつつある UX STRAT ですが、開催当初は実に様々な論争が繰り広げられていました。取り上げられた論点は後述しますが、UX STRAT の公式サイトを見ていただけるとお分かりいただけますが、UX 戦略を巡って実に様々な言論が存在しています。

もう1人は日本語版が先日オライリー・ジャパンより出版された「UX Strategy」の著者であるジェイミーです。ジェイミーは本書で、UX戦略は北極星ではないと言及しています。

UX戦略 ―ユーザー体験から考えるプロダクト作り

作者: Jaime Levy,安藤幸央,長尾高弘
出版社/メーカー: オライリージャパン
発売日: 2016/05/25
メディア: 単行本（ソフトカバー）
この商品を含むブログを見る

彼女は UX戦略をビジネス戦略と UX デザインの交差点に位置する概念として定義し、活動としての UX デザインを戦略設計の一部として行うためのアプローチを本書で紹介しています。そしてこのアプローチこそ、いま現在のビジネス戦略と UX デザインを取り巻く環境と関係性を理解するために必要だと考えます。

UX戦略を理解するためのフレームワーク

次に UX戦略を著者なりに理解するために参考にしたフレームワークをご紹介します。まず1つは「UX デザインの教科書」の著者である安藤先生が紹介されていた、実践としての UX デザインの要素とその関係性を示した図です。

（出展：安藤研究室ノート: 『UXデザインの教科書』の詳細内容（第2報））

上記の図では UX デザインを取り巻くビジネス戦略含む前述の UX デザインの3つの対象領域と実践内容、そしてそれを支える理論がわかりやすく解説されています。

UXデザインの教科書

作者: 安藤昌也
出版社/メーカー: 丸善出版
発売日: 2016/06/01
メディア: 単行本
この商品を含むブログを見る

もう1つのフレームワークは「Product/Market Fit（プロダクト・マーケット・フィット）」です。プロダクト・マーケット・フィットとは、最適なマーケットに位置し、そのマーケットを満足させられる最適な製品を保っている状態のことを指します。もともとはネットスケープの共同創業者である Marc Andressen（マーク・アンドリーセン）によって提唱され、後に Steve Blank（スティーブ・ブランク）によって世に広まった概念です。

このフレームワークを活用することによって、UX戦略の後に言及するパターンごとの優先事項を示すことができると考えています。

（出展：Business Model versus Business Plan | Steve Blank）

著者はこれに Execution（エグゼキューション）、つまり実行性の軸を加え「Product/Market/Execution Fit（プロダクト・マーケット・エグゼキューション・フィット）」という枠組みで UX戦略とは何かを考えてみました。最適なマーケットに対し、そのマーケットを満足させられる最適な製品を構想しても実行性がなければその戦略は無価値に等しく、前述のビジネス、プロダクト、そしてユーザー間のバランスを保つことが難しくなります。

以上の2つのフレームワークに加えて、UX デザインの活動領域の変化に伴う UX と戦略の意味的変化を考慮する必要があります。

UX戦略の意味的変化

UX デザインの普及と発展に伴い、その対象領域（ビジネス/プロダクト/ユーザー）の関係性は変化していきます。そのため、UX STRAT でも UX戦略を語る上で主要な論点として掲げられていたのは、以下の3つです。

UX AND Strategy?（UX デザインと戦略という関係性なのか？）
UX IN Strategy?（戦略の一部として UX デザインが位置付けられているのか？）
UX FOR Strategy?（戦略立案と実行のための UX デザインなのか？）

「UX Strategy」という単語の意味を文脈から推測すると以上の3つが考えられ、捉え方によって UX戦略そのものの理解に齟齬が生じてしまう恐れがあります。それは決して悪いことではなく、UX STRAT のプレゼンテーションが多岐に及んでいる背景には以上の言論が存在するためです。

まとめ：UX 戦略とはなにか？

以上の

UX デザインの要素とその関係性
プロダクト・マーケット・エグゼキューション・フィット
UX 戦略という単語が示す意味

をまとめると UX戦略を理解するための枠組みは以下の通りに整理できるのではないかと考えています。

UXデザインと戦略の関係性は、計3つのパターンに分類されるのではないかと考えています。UX STRAT で議論されている内容や書籍「UX戦略」のジェイミーが取り上げている概念は「UX IN Strategy（戦略の一部としての UX デザインの位置付け）」から「UX FOR Strategy（戦略立案と実行のための UX デザインの位置付け」へのパラダイムシフトを主軸としています。

その背景にはジェイミーの著書でも言及されている通り、これまで対立関係にあったビジネス戦略・プロダクト戦略と UX デザインをシームレスに統合することでよりマーケットに適した、ユーザーに愛される製品を開発、提供することへの必要性が増してきたためです。「UXデザインの教科書」でも UX デザインにおけるコンセプトメイクの重要性について解説されています。

結果、UX デザインと戦略という対立関係から戦略の一部として UX デザインが位置付けられ、さらには昨今のアジャイル開発や Lean UX などエグゼキューション（実行性）を高めながら製品とユーザー、マーケットの適応性を検証する、正に一体となった UX デザインが問われはじめています。それこそが、UX戦略が本来意味するところだと考えます。

続きは（すでに満席ですが）今週末に開催される「UXデザインの教科書」出版記念イベントでディスカッションできればと思っています。

ビジネスや社会に貢献する UX デザインの価値とは？

2016-06-11T15:35:35+09:00

本日6月11日に HCD-Net が主催する毎年恒例の「HCD-Net フォーラム 2016」が開催されました。どれも大変興味深いセッションばかりでしたが、著者がモデレータを担当させていただいたセッション「ビジネス、社会に貢献するHCD」では13名もの方に人間中心設計、ないしは UX デザインがどのようにビジネスや社会に貢献しているのか？をテーマにライトニングトーク形式で発表いただきました。

ウェブサイトにおける人間中心設計、UXデザインの応用例から地域の課題解決のためのサービスデザイン事例など話題は実に様々でしたが、発表いただいた内容から着想を得て、人間中心設計 / UX デザインがどのようにビジネスや社会に貢献しているのかを説明するための枠組みを考えてみました。

人間中心設計 / UX デザインの価値定義

人間中心設計 / UX デザインはビジネスや社会に十分に貢献できる、または貢献していると考えています。では、どのように貢献しているのでしょうか？今回発表いただいた内容はその証明にもなると思いますが、人間中心設計 / UX デザインは以下の軸でビジネスや社会に貢献していると捉えることができます。

OUTCOME（成果としての人間中心設計 / UX デザイン）
PROCESS（プロセス、過程としての人間中心設計 / UXデザイン）

加えて、ビジネスや社会への貢献を大きく分けて

内的効果（組織やステークホルダーに影響を及ぼすもの）
外的効果（顧客やユーザーに影響を及ぼすもの）

の2つに分類することができます。以上の軸を枠組みとしてまとめると、人間中心設計 / UX デザインは以下の観点からビジネスや社会に貢献していると言い切れるのではないでしょうか。

A: 成果として組織やステークホルダーにもたらされる効果

定性的な側面が強い人間中心設計や UX デザインの価値を証明するために用いられることが最も多い領域です。人間中心設計 / UX デザインの本質が問題解決であるが故に結果としてユーザビリティ（利用性）が向上し、エラー回数が減ることによってユーザーの目的到達率が向上しやすくなります。つまり、組織にとって収益の向上が見込まれ、かつユーザーからの問い合わせ数が低下する傾向にあるため、主に人的コストの削減も期待されます。

B: 成果として顧客やユーザーにもたらされる効果

(A) に影響し、対象組織ないしはサービスに対するユーザーのエンゲージメントが向上し、ブランド認知度の向上が期待できます。当セッションでも紹介がありましたが、昨今では NPS（Net Promoter Score）を活用した顧客満足度調査を経営指標とする企業も増えてきており、(A) の結果として顧客やユーザーにどのような定性的な変化が起きているのかを証明する手法も増えてきています。

C: 過程として顧客やユーザーにもたらされる効果

まだ馴染みのない領域かもしれませんが、社会を対象とした人間中心設計 / UX デザインにおいては顧客やユーザーと共に共創する参加型デザインも主流になりつつあります。

過去のエントリー「組織とサービスデザインーサービスを起点とした2つのユーザー体験を考える」でも触れましたが、Airbnb では (B) の延長としてサービスのファンが Airbnb の創造活動に参加しやすい環境を構築しています。結果、ファンから従業員に転身するユーザーがいるほど、顧客ロイヤリティーを高め、従業員として雇用することを最終目的として様々な取り組みをされている企業、組織もいます。

D: 過程として組織やステークホルダーにもたらされる効果

言わずもがな、人間中心設計 / UX デザインは単身で完結するものではありません。複数のステークホルダーを共通言語を用いて巻き込むことによって、意思疎通や合意形成を円滑に進めやすくなります。結果としてコミュニケーションコストが削減され、かつ各種成果物がナレッジとして組織に蓄積されることで組織内横展開が容易となり、教育や育成の側面においても貢献している、あるいは貢献できると言えます。

まとめ

既にお気付きの方がいるかもしれませんが、人間中心設計 / UX デザインがビジネスや社会に貢献できる4つ（A, B, C, D）の領域は互いに連鎖関係にあります。つまり、価値の循環が生まれる、ということです。最も語られることが多い (A) の背景には (D) が介在し、結果として (B) 、(C) へと連鎖していきます。

ここでお伝えしたいことは、(A) だけで語ってはいけないということです。著者は過去に、人間中心設計 / UX デザインの価値を証明するために収益への貢献度を苦手な数式を用いて算出しましたが、ボード陣に受け入れられたものの人間中心設計 / UX デザインそのものの本質的価値の証明が疎かになっていました。

よい結果が得られたのであればその他サービス、事業に横展開せよー人間中心設計または UX デザインというプロセスそのものを装着すれば期待される (A) の成果が得られるという期待だけが各事業に膨らみました。

もちろん、同じ「もの」を導入したからといって同様の結果が得られるとは限りません。にも関わらず、機械的な導入だけが進み、人間中心設計や UX デザインの過程で重要となる (C) や (D) への理解が得られずにいました。それでは本末転倒です。経営観点から考えてみても、よりよい収益上の成果が得られるのであれば手段は問わない、という思考に陥りやすくなります。

考えを改めなければならないのは、人間中心設計や UX デザインは様々な観点でビジネスや社会に貢献できるということであり、現状を把握した上で組織や社会に導入するにあたって最も効果が期待される領域を見定め、確実に装着し、価値の循環を回していくことなのではないでしょうか。

二輪駆動の人間中心設計

2016-05-31T19:02:12+09:00

人間中心設計プロセスの「2つの誤解」

先ずは以下の図をご覧ください。これは、著者が評議員を務める人間中心設計推進機構が自社の公式サイトで掲載している人間中心設計（Human Centered Design：HCD）のプロセス図です。「人間中心設計プロセス」と画像検索すると類似する画像が沢山ヒットしますが、多くは以下のような図ないしは円形の図で示されていることが多いです。

（出典：HCDのプロセスと手法）

国際規格として1999年に発効されて以来、この図は17年もの間、ユーザー中心・ユーザー視点で自社製品やサービスを構築、実現するための手段としてさまざまな研究論文やプレゼンテーションなどに流用されてきました。

が、17年も経過するとさまざまな変化が訪れます。もともとはユーザビリティ強化の一環としてハードウェア業界の発展に伴い普及してきた人間中心設計ですが、逆もありきでソフトウェア業界でも同様の手法が用いられるようになりました。著者がソフトウェア業界に身を置いているため、ソフトウェアにおけるモノづくりの視点が前提となっていることをご理解いただきたいのですが、この人間中心設計のプロセス図には「2つ誤解」が生じてしまいます。以下は、これまでの著者の経験と、様々なイベントなどで参加者との貴重な意見交換の場で得られた知見に基づくものです。

ひとつは、最上段の工程を開始地点として進めなければならないという誤解です。
もうひとつは、人間中心設計のプロセスはリニアに進めなければならないという誤解です。

誤解その1：最上段の工程を開発地点として進めなければならない

本来、人間中心設計に開始地点などは存在しません。人間中心設計のプロセスを大きく分けてユーザーの要求事項を探求する「問題定義（構想：主に頭を動かすステージ）」と、設計による解決策を提供する「問題解決（実現：主に手を動かすステージ）」と分類した場合、必ずしも問題定義からはじめればならない、というわけではありません。

なぜか？問題を定義する以前に、先ずは正しい問題、またはユーザーの潜在的なニーズを確実に抽出するための手段として製品やサービスをつくる、といった思想への価値転換が発生しているためです。この背景には外的要因と内的要因がそれぞれ関係していると考えています。

外的要因：同様の製品やサービスの数が爆発的に増えたことで顧客の要求水準を追い越してしまい、コモディティ市場への対応策として潜在的なニーズの発掘と競合優位性を保つためのスピードが求められるようになった。
内的要因：スマートデバイスの普及によってデザイナーとエンジニア双方の活動領域が拡張し、重なり合うことで設計・開発速度が向上し、自社製品やサービスの早期検証が可能になった。

また、既存サービスを運営している場合は現在解決している（と思われる）課題は健在か？正しい解決手段を提供できているか？を検証するために評価から開始する方が人間中心設計プロセスは比較的導入しやすいはずです。ところが、先ずは現状のユーザーの利用状況を調査・把握するところからはじめましょう、と流れに従ったプロセス導入をしてしまいがちです。

誤解その2：人間中心設計のプロセスはリニアに進めなければならない

プロセスと聞くとどうしても手順や過程をイメージしてしまいます。確かに、どのような手順で、どういう過程で調査・設計・開発したのかが明確な方が理解が進みやすいと思います。ところが、昨今のアジャイル開発やリーンUXの発展は従来のモノづくりへのアンチテーゼとして生まれているということを留意しなければなりません。

従来のモノづくり、もとい人間中心設計のプロセスや手法は予め定められた手順を重視するあまりにプロセスやツール、ドキュメントや計画などに重点を置いてしまう傾向にありました。しかし、本来の（ソフトウェア業界における）モノづくりはユーザーにとって価値のある製品やサービスをつくり、提供することです。アジャイル開発やリーンUXはこれまでの偏りがちだった価値観の転換を促す概念として誕生し、本来の目的に回帰しようというシグナルであると捉えることができます。

アジャイル開発やリーンUXの本質は、人間中心設計です。リーンスタートアップを提唱したエリック・リース氏もデザイン思考の発展に寄与したIDEO代表のティム・ブラウン氏との対話で、そのように明かしています。

アジャイル開発とリーンUXーこのブログで何度も言及していますが、共通するキーワードとして

組織のサイロを超えた職種・職能横断のクロスファンクショナルなチーム編成
問題発見と問題解決をパラレルかつ短期間で進める取り組み

などが挙げられます。

二輪駆動の人間中心設計とは？

以上を踏まえ、人間中心設計のプロセス図にはアップデートが必要だと考えます。乗り物に例えると、従来の人間中心設計のプロセスは一輪車のようで（製品やサービスの）方向転換にはあまり向いておらず、速度も限られてしまいます。そして今回、著者がアップデートした人間中心設計プロセスは自転車のような両輪駆動でこれまで以上に方向展開（リーンUXの言葉を借りるとピボット）が容易となり、比較的全体の速度も向上します。これを「二輪駆動の人間中心設計」と呼んでいます。

上記図は2015年2月に無料動画オンライン学習サイト「schoo」で授業をさせていただいた内容より抜粋した図です。詳しく知りたい方はぜひ受講していただきたいのですが、ポイントは以下のとおりです：

開始地点と終着地点は設けずに目的別（＝問題定義、問題解決）に永続的に取り組む
問題定義と問題解決を行き来する
必要であれば問題定義を繰り返す、問題解決を繰り返す

自転車の二輪のように双方の目的を見失わずに「誰の問題を解決しようとしているのか？」「どのように解決しようとしているのか？」を繰り返しながら双方の「解」の精度を向上させることが、この「二輪駆動の人間中心設計」の狙いです。

一見、リニアのように進めているようにも見えますが、ユーザー調査と並行して全体のサイトマップや詳細設計を見直し、プロトタイプした製品やサービスをその場で検証し、利用シナリオをジャーニーマップにまとめ、詳細設計に活用するといった取り組みを実施した例です。

もちろん、この「二輪駆動の人間中心設計」こそが正しい、というわけではありません。あくまでも一例として、これからも人間中心設計のプロセス図は見直しが必要と思いますし、今回のような言論がもっと増えて行くことが真の人間中心設計の普及に貢献するのではないかと考えています。

UX デザインに求められる「3つの目」

2016-04-21T18:47:43+09:00

* 当記事は UX Milk に寄稿させていただいた記事の転載です。

「3つの目」とは？

言い古された言葉ではありますが、みなさんは物事を捉えるための「３つの目」を聞いたことはありますでしょうか？

獲物を見つけるかの如く、全体を俯瞰する「鳥の目」
近づいて様々な角度から細部を見る「虫の目」
全体の流れを掴む「魚の目」

物事を捉えるときには特定の視点に偏るのではなく、複眼で捉えることで物事の真理を理解することができると言われています。わかりやすく言えば：

マクロな視点
ミクロな視点
トレンドを把握する視点

と区別することができます。ネットで検索をすれば経営者やリーダーに求められる条件の１つとして語られることが多い「３つの目」ですが、私は UX デザインにこそ応用すべきであると考えます。

UX デザインにおける「3つの目」とは？

昨月、大阪にて開催された HCD-Net サロンにて私は「サービスデザインの骨格と視点」というタイトルでサービスデザインへのパラダイムシフトに伴う視点の変移についてお話させていただきました。当日発表させていただいたスライドはこちらよりご覧いただけます。

その際に、サービスそのものを俯瞰して捉えるための手段として事例と共にサービスブループリントをご紹介しました。既にご存知の方は多くいらっしゃると思いますが、サービスブループリントとは対象のサービスを１）エンドユーザー視点のフロントステージおけるユーザー体験と、２）サービス提供者視点のバックステージにおけるユーザー体験とで分けて可視化するツールです。

エンドユーザー観点で語られることが多い UX デザインですが、冒頭で述べた「鳥の目」でサービスそのものを捉えると、サービスとはエンドユーザーとサービス提供者間のインタラクションの連続性によって成立するコミュニケーションであると理解することができます。また、その中で我々が関わることが多いウェブサイトやアプリの設計やデザインはエンドユーザーとサービス提供者をつなぐ接点の一部であり、「虫の目」が活きる領域です。

最後に、前述のバックステージおけるユーザー体験、すなわちサービス提供者視点でサービスを捉えなければ実行性がありません。サービス構想を可能にするためのオペレーションや組織構造などをデザインの対象に含めるためには、正に水面下からサービスを捉える「魚の目」が求められます。

まとめると、UX デザインにおける「３つ目」は以下のようにまとめることができます：

鳥の目：サービス全体のジャーニーや接点を俯瞰して捉える
虫の目：ひとつひとつの接点を担う細部のタッチポイントを捉える
魚の目：サービス提供者のバックステージにおける流れを捉える

なぜ、UX デザインにも「3つの目」が必要か？

UX デザインは主にウェブ業界で語られることが多く、その対象もウェブサイトやアプリに閉じてしまいがちです。

本来であれば、今回ご紹介したサービスブループリントに従ってユーザーの体験を可視化してみると、デザインの対象はウェブサイトやアプリに閉じないべきなのです。虫の目だけでサービスを捉え、デザインの対象を限定してしまっては自分が知らない問題に直面することはなく、虫の目からしか見えない問題のみが解決の対象となってしまいます。

当たり前ですが、自分の知らない問題は解決できません。UX デザインを問題解決として定義するのであれば、本来解決すべき問題とはなにかを継続的に探る必要があります。そのためには全体を俯瞰して見る鳥の目や、サービスの裏の流れを捉える魚の目を養うことが求められます。ただ、昨今の UX デザインに関するイベントや勉強会の多くは「虫の目」留まりになっているのではないかと危惧しています。今回ご紹介した「UX デザインにおける３つの目」はどれも必要であり、ひとつでも欠けてしまうとそれぞれの良さが失われてしまいます。

言い古された「３つの目」ですが、UX デザインにも応用することによって、これまで以上に本質的理解が進むのではないでしょうか。

sprmario.hatenablog.jp

サービスデザインの骨格と視点

2016-03-20T21:40:46+09:00

当記事は2016年3月4日に大阪にて開催された第61回HCD-Netサロンでお話させていただいた内容のフォローアップになります。

はじめに

今回のプレゼンテーションでは「デザインを捉えるスケールの拡張」をキーワードに、サービスデザイン特有の視点とは何か？からサービスデザインを紐解いていきました。

これまでのデザインは例えるならば「虫の目」に限定された解釈がなされたことが多かったと思いますが、サービスデザイン時代においては：

スケールアウトしてサービスを捉える「鷹の目」
サービスを支えるバックステージをもデザインの対象に含める「魚の目」

の視点が求められます。それをわかりやすく解説している例として「Powers of Ten」があります。

これまでのUXデザインとは何が異なるのか？

サービスそのものの定義やサービスデザインの定義は過去のエントリーで何度も言及しているため割愛しますが、これまでのUXデザインと異なる点は2つあります。

デザイン対象のスケール変動：人間中心思想への原点回帰
ユーザー接点の拡張：コミュニケーションのデザイン

デザイン対象のスケール変動

Before: これまではペルソナに代表されるような特定のユーザーのみを対象とした分析やアプローチが中心であったが故に、ユーザーの検討行動や意思決定行動に関与するその他ユーザー、ないしはステークホルダーを配慮しきれていませんでした。

After: 真のユーザーを見極めるため、かつユーザーのコンテキストを把握するためユーザーを取り囲むステークホルダーの把握やユーザーの理想体験の実現に向けた基盤を整備するためのオペレーションをも対象とした分析やアプローチが求められるようになりました。

これは結果として、ユーザー中心設計から本来の思想である人間中心設計への原点回帰を意味しているのではないでしょうか？

ユーザー接点の拡張

Before: サービスが保有する個別の接点またはタッチポイントのみに限定したチャネル戦略（例：シングルチャネル、マルチチャネル）やユーザー体現に留まっていました。

After: あらゆる接点またはタッチポイントを統合することで個別の接点に依存しないチャネル戦略（例：クロスチャネル、オムニチャネル）やユーザー体験の実現が求められるようになりました。

その背景にあるのは、ユーザーはその瞬間に置かれている状態によって利用可能チャネルを自身で取捨選択し、行動するようになってきたからです。

その期待に応えられない状態、それはチャネルを横断しても一気通貫のユーザー体験モデルが構築されていなければ断片的な体験をもたらすようになり、利用に至らず離脱に直結しやすくなります。

モノシステムからエコシステムへのパラダイムシフトを見極める

これまでの話から、UXデザインからサービスデザインへのパラダイムシフトの1つの特徴として、独立したタッチポイントに限定したユーザー体験からの脱却を意味し、テレビやPC、雑誌や店舗などサービスが保有するタッチポイントを統合したシステムとして捉えることが挙げられます。

例え複数のタッチポイントを形成できていたとしても独立した価値/生態に留まってしまうケースは多くあります。ここで言うエコシステムとは文字通り、ユーザーとサービス提供者の相互作用の生気によって創造・構成される「システム」のことを指します。あらゆるタッチポイントが統合した価値として創造され、フロントステージにおけるユーザーとバックステージにおけるサービス提供者間の連続した、または継続したコミュニケーションが成立している状態を指します。

サービスを利用する断片の側面だけを視るのではなく、ユーザー体験を支えるバックステージのプロセスやシステムをも視野に入れ、メタ視点で整合性を図るプロセスこそがサービスデザインなのです。

サービスをシステムとして捉えなければ、知らない問題に直面することはありません。そして自分の知らない問題は解決できません。目に見えないものを「見える化」すること、そしてサービスに関わる人々の想いを結び、届けることで無視されることはなくなるのではないでしょうか。

People ignore design that ignores people.2
人々を無視したデザインは、人々から無視される。

- Frank Chimero

事例などは割愛していますが下記参考資料よりご覧になることができます。

2015年アーカイヴ

2015-12-27T19:25:19+09:00

登壇イベント

2015年1月10日「HCD-Net 教育セミナー「第7回サービスデザイン方法論フォローアップ講習会」：組織とサービスデザイン―サービスを基点とした2つのユーザー体験を考える
（フォローアップ記事／スライド）
2015年1月16日「Lean Startup Update!! 2015（リーンスタートアップをアップデートする会）」：Lean UX Quest in Tokyo
（フォローアップ記事／スライド）
2015年1月27日「Design dot noom」：サービスのグローバライゼーションとローカライゼーション
2015年2月5日「schoo」：優れたUXを実現するための人間中心デザインとは？
（フォローアップ記事／スライド）
2015年2月28日「産業技術大学院大学「人間中心デザイン」」：HCD導入設計論
（フォローアップ記事／スライド）
2015年4月11日「LEAN UX Japan Conference 2015」
2015年4月29日「第16回情報デザインフォーラム」：LEAN UX デザインにおける CPS 仮説検証モデル
（スライド）
2015年5月31日「HCD-Net フォーラム2015」：人間中心設計の表と裏
2015年7月11日「UXシンポジウム沖縄2015」：伝わる仕組みとサービスデザイン
（スライド）
2015年7月18日「Tech in Asia」：Story is Strength
（レポート）
2015年7月31日「UX Sketch Vol.2」：事業計画に求められる2つの「プロペラ」
（フォローアップ記事／スライド）
2015年8月22日「NIKKO 20 years アイディア CAMP」：伝わるしくみを考える
2015年9月8日「UX Jam #2」：Empathic Design 共感力を取戻し、そして育み、発揮する
（フォローアップ記事／スライド）
2015年11月22日「UX Japan Forum 2015」：Silent Minority サイレントマイノリティ
（フォローアップ記事／スライド）

インタビュー／掲載記事

【インタビュー】Mediumが生み出す新たな価値「ストーリー」とは？
【インタビュー】Twitter創業者が繰り出す、Mediumというアンチテーゼ
ユーザーは“嘘”をつく声にならない本音を探るための5つのステップ
「ユーザーをわかったつもり症候群」からどう抜け出すか勝つサービスを作るために必要なこと
株式会社リクルートテクノロジーズ坂田一倫さん
【インタビュー】UXって結局何なんですか？大学生が専門家に聞いてみた

【インタビュー】UXって結局何なんですか？大学生が専門家に聞いてみた

UX デザイナーを目指している君へ

2015-12-25T13:02:01+09:00

はじめに

当記事はUX デザイナーを志している、主に学生に向けたメッセージです。
当記事は「UX Tokyo Advent Calendar」の25日目の投稿です。

(magro via Compfight cc)

UX デザインに関わる仕事に就くことを志した日をいまでも覚えています。それは、UX の提唱者であるドナルド・ノーマン博士が母校で行った基調講演に参加したことがきっかけでした。思い返せば、世の中のプロダクトやサービスをよりよいものにしたいという想いが非常に強かったことを覚えています。ユーザー不在の組織や社会にイノベーションを起こす思想こそ、日本のものづくり文化の再建に貢献するだろうと確信しました。しかし、いざ日本企業に勤めればそこは全くの別世界。UX という言葉が流通し、バズワード化してきたこの頃は誤った理解が先行し、他者を上手く説得するための材料として用いられていました。

但し、これだけで僕は諦めませんでした。そしてあなたも諦めるべきではありません。

すべてのはじまり

当時、UX デザイナーという職種はこの世にありませんでした。ビジュアルデザイナー見習いであった僕は大手IT企業で商品のバナー制作や特集ページの制作に没頭し、如何に人の目を惹き付けるか、限りある空間の中で創造性を発揮することに喜びを感じていました。ところが、配置されるバナーや特集ページはコトの一部でしかなく、ユーザーのコンテキストに合わせた設計を考慮しなければ利用してもらえない以前に、気づいてさえもらえない。それでも自分が担当したデザインが世に出ることへの喜びが勝り、しばらくはビジュアルデザイナーとしてのキャリアを積んでいました。

ところが冒頭の、ユーザー不在の組織を改革するまでの道のりは遠い遠いものでした。

ユーザーとの接点を担うビジュアルデザイナーという職種でも実際のユーザーとの距離は遠いこと
一人で作業することが多かったこと
評価は数字でしか現れず、実際の声としてフィードバックされなかったこと
デザインの良し悪しがその人の感性によって定められたこと
つまりは俗人的であったこと
他のところに手をつけようにも組織のサイロ化が著しく、組織の壁を越えた思ったようなコミュニケーションが取れなかったこと

デザイナーというキャリアを選んだ自分の判断を疑いました。そこで僕は情報設計（IA）に関心を抱き、表層のデザイン以前にその背景となる情報構造や導線設計までをデザインの対象に含めなければその後のビジュアルデザインが良いものにならない。意味がないと考えました。そして、いわゆるウェブディレクターのポジションに就きました。

変化の訪れ

開発との距離が以前よりも近くなり、かつプロジェクトのスコープも、スキームもこれまで以上に肥大化し、複雑化しました。プロジェクトのそもそもの問題提起の確度が不明なまま進行するも、第三者であるユーザーの声をユーザーテストやインタビューの実施結果から届けることで軌道修正を何度も図ってきました。

すべてを実現できなかった不甲斐無さは残るも、ユーザー不在の環境からの脱却の足がかりとなりました。また、この時には自信の経験を世に発信することで、何が足りていないのか？を自問自答してきました。結果、僕は一人ではないことへの安心感を得ることができました。その時の話がきっかけとなり、同じ不を抱えていた人たちで集い、自主的に勉強会や読書会を開催するコミュニティを発足しました。それが、いまの UX Tokyo の母体です。

話を少し戻します。

情報設計に特化した取り組みをしていたものの、対象サービスのバリュープロポジションやサービスオペレーションを見直さないことには文字どおりのユーザー体験の抜本的な改善が行えないことに疑問を抱き、新規事業開発やサービスのリニューアルといったプロジェクトを中心に担当するようになりました。これまで以上の規模、そして責任の重さに応えるべく、HCD-Net が定める人間中心設計専門家や、社会人向けの人間中心デザインを体系的に学べるプログラムに参加し、改めて自分が取り組んできた実経験を見直し、体系化していきました。自分がやってきたことに間違いはない、そう思えました。

そして丁度その頃には西海岸から UX デザイナーという職種が海を渡って届き、会社の名刺にも肩書きとして「UX デザイナー」と記載することを認められました。

伝えたいこと

「UX デザイナーはどんな仕事をしているの？」とよく聞かれることはあります。様々な記事で解説はしているものの、この質問こそイテレーションを繰り返し、UX デザイナーとしての自分を見直すための指標であると考えています。

人が想いを伝えるための「モノ」と、場所や時間などの「コト」を作り、それに対するフィードバックを得てまた「モノ」と「コト」を改善していく、それ全体がUXデザインです。伝えたつもりになってしまわないことが一番大事で、そうならないための「伝わる仕組み」を考えることがUXデザインなのです。ー「【インタビュー】UXって結局何なんですか？大学生が専門家に聞いてみた | UX MILK」

もし、既にここに書かれている事態に直面しているのであれば、それは決して恥じることではありません。最も大事なことは、一人でいないこと。外に出てみましょう。コミュニティに出向いて、同じ職種の人の話を聞き、新しい知識を得て自身のことについても話してみましょう。UX デザインは綺麗に一言でまとめられるほどの簡単ではありませんし、僕はまとめるものではないと考えています。そうやって、UX デザインは浸透し、進化してきました。

UX デザイナーになりたいという夢を、例え小さなことでも折り曲げる必要はありません。我々は、あなたのような、純粋にユーザーのためを想い、ユーザーのためによりよい体験を実現し、これまで以上に住みやすい社会をつくりあげることに意欲がある人を求めています。リーンスタートアップやデザイン思考、デザインスプリントなど、UX デザインを取り巻くように実に様々な手法体系が発表されていますが、難しく考える必要はありません。その根底にあるのは、ユーザー中心の設計理論です。

(via MagicBands & Admission Cards | Walt Disney World Resort)

ディズニーランドが新たに発表したマジックバンドのように、これまで以上に感動体験を生み出す仕組みが続々と世の中に誕生しています。この時代に生き、UX デザイナーという職種に就けることにもっと喜びを感じるべきです。

UX デザイナーになるために必要な3つのこと

最後に、当記事を読まれてUX デザイナーを志そうと決心した読者の方へ、UX デザイナーになるために必要な3つのことを自身の経験からご紹介します：

自ら様々な体験をすること：ユーザーになりきることは不可能です。つまり、ユーザーとどれほど近い立場になれるか、近しい経験をしているか、が自身のものさしとして今後必要になってきます。
正解はユーザーしかわからないこと：いくら第三者であるユーザーのためと思っていても、実際にユーザーが触れるまで正解はわかりません。エゴに押し切られないように注意しましょう。
ユーザーと共創すること：ユーザーとの対立構造を緩和すべく、ユーザーを「（サービスを提供する）相手」として見なさないようにしましょう。共にサービスをつくるパートナーとして接しましょう。

子供が将来なりたい職業に、UX デザイナーが挙げられるその日まで。メリークリスマス。

坂田一倫

サイレント・ニーズを探る5つのステップー #UXJapan Forum 2015

2015-12-05T17:33:38+09:00

はじめに

当記事は11月22日（日）に開催された「UX Japan Forum 2015」でお話させていただいた内容のフォローアップ記事です。

当フォーラムのテーマは「サイレント・ニーズを探る」と題され、各セッションではプロダクトやサービスを構築する上でエンドユーサーないしいはカスタマーの隠れたニーズを抽出し、その後のサービス開発に応用するための方法や具体的なケーススタディについて語られました。

著者のセッションでは「サイレント・マイノリティ」と題し、以下2つのトピックについて解説をしました。

ユーザーの声なき声（＝サイレント）に耳を傾けるには？
ユーザーの声なき声を少数派（＝マイノリティ）に留めないための仕組みは？

また、今回のセッションでは著者が担当しているプロジェクトで正にこれから試みようとしている仕組みづくりと、今年半年かけて受講した、IDEO が主催するオンラインスクールへの参加から得られたインサイトを交えてご紹介していく予定です。

なぜ、ユーザーの「声」なき「声」なのか？

ユーザーの声を聞こうーユーザエクスペリエンス・デザインやデザイン思考の普及に伴い、この言葉をよく耳にするようになりました。

ユーザーが不在の状態からの脱却を目指し、ユーザーの声を取り入れる活動が活発になってきていますが、一方でユーザーの「声」を聞く活動には実に様々な思惑や目的が存在します。

ユーザーの声に耳を傾ける行為、手段が目的化してしまい結果として「ユーザーを知ったつもり」症候群に陥ってしまうケースです。ユーザーの声は確かにチームやサービスを前進させる強力なトリガーとなりますが、声を実現しても改善に直結せず、利用に至らないことも結果として少なくはありません。

「あの時、ユーザーはXXが欲しいと話していたのに、いざ実装してサービスに装着してみたら利用されなかった」なんて経験をしたことがある人は少なくはないと思います。

それもそのはず。その時々のコンテキストによってユーザー自身が抱える課題は変動し、解決手段もその時の判断に委ねられているため予測はできません。未来を訪ねる質問はNG、と言われる背景にはこのような過ちが存在します。

つまり、

ユーザーの声に答えれば、ユーザーは満足するという前提が間違っている。
傾けるべきはユーザーの「声」ではなくユーザーの体験、ユーザーの声なき「声」なのです。

当イベントでではその重要性を理解すべく、プチワークショップを開催しました。それは、3人1組のチームを形成し、出題者を1人決めこれからお見せする質問を「声無し」で表現するというクイズ形式のものです。残された人は回答者として出題者が出題する質問を回答します。

当てることがこのワークショップの目的ではありません。同じ質問を出題する人でもサイレントでコミュニケーションしなければならないため、ボディランゲージを通じた表現のパターンは実に人によって様々です。

つまり、その人の特性を理解するには声だけではなく声なき声に注意を払う必要があります。そして注意を払うということは相手に対する関心を抱くということです。

「声なき声に耳を傾けることが無関心への最大の武器。」ー Shannon Galpin

ユーザーの声なき「声」には、ユーザーの実際の「声」以上の価値があるのです。

サイレント・ニーズを探る5つのステップ

セッションの後半では冒頭でお伝えした IDEO が主催するオンラインスクールで学んだサイレント・ニーズを探るための5つのステップをご紹介します。

1. Observing（観察をする）

インタビュー実施前やエスノグラィ調査などで先ずはユーザーを観察します。観察せよ、と言ってもただ眺めているだけでは大事なインサイトを逃してしまう可能性があるため、先ずは以下のポイントを抑えることが重要です。

その人の行動に影響を与えている因子はなにか？
例）持ち歩いている荷物、服装、など
その人の周囲の環境への適応方法はなにか？
例）周囲の観察、第三者へのコンタクト、など
一番気にしていることはなにか？
例）気温、周囲からの反応、など
目立ったボディランゲージやジェスチャーはなにか？
例）ろくろを回す、腕組み、など
癖はあるか？
例）髪型をいじる、貧乏ゆすりをする、など

2. Analyzing（初期仮設分析）

対象のユーザーとのファーストコンタクト（インタビューなど）ではまず相手が自身が関わるプロダクトやサービスにおいてどの利用ステージに位置付けられるユーザーなのか（アーリーアダプター、アーリーマジョリティなど）を見極めます。

基本デモグラは？
例）年齢、性別、家族構成など
行動特性は？
例）初心者、熟練者など
その人のモチベーションはどこから生まれるのか？
例）金銭的インセンティブ、など

初期段階で対象のユーザーのポジショニングを設定することで、その後の質問を変えていきます。

3. Interviewing（インタビュー）

質問構成については参考文献が世にたくさん存在しているので深くは追求しませんが、相手をより深く探求すために注意すべきポイントをご紹介します。

オープンな質問を聞くこと（はい、いいえ、の質問は避けること）
「実際に見せてもらえますか？」と訪ねること
質問内容は広く浅く、から深く狭くへ
その人との信頼関係を構築すること
ギャップに注意すること

最後のギャップとはなにを指すのか？「実際に見せてもらえますか？」と訪ねる際に、その人の人間性がわかるスマホの画面やカバンの中身を実際に見せてもらうことで、声からは見えてこない本当の、その人らしさが垣間見れます。

例えば就活を控えているこの学生の場合。実に優秀そうな学生ですがボイスケア用品を常に持ち歩いているようで、就職を考えていないことがわかりました。尋ねてみると、声優さんになりたいそう。これが、インタビュー（声）からは見えてこない、ギャップです。結果としてその後の質問が深く狭くなります。

4. Immersing Empathy（共感に浸る）

インタビューや観察後は実際に自分に体験してみることが大切です。ユーザーを知ったつもり症候群からの脱却には追想体験が有効です。

視点を変える
自身にハンディキャップを与える
DIY
アナログな体験をする

例えば、高齢者を対象としたインタビューではメガネにグリスを塗るなど、視界の狭さを実感することで、その人の行動に影響を与えている因子に気づくことができると共に更なるアイディアの発展が見込めます。

5. Sharing Insights（洞察の共有）

チームメンバーやその他メンバーに結果を展開する時に注意すべきこと：

個別のデータ（個票）を収集する
統合と分散を繰り返し意味を見出す
洞察を加える
視点を展開する（ストーリーテリング）

重要なのは、冒頭のワークショップでもお伝えしたようにモチベーションを与え関心を抱かせることです。そのためには、ただユーザーの声を記録したメモを展開するだけではなく、カバンの中身やその人の特徴的な行動などその人の人となりがわかる要素を追加し、文字通りの「ユーザー視点」を構成します。

まとめ

ユーザーの声なき声に耳を傾けるためのサイレント・ニーズを探る5つのプロセスをご紹介しました。ユーザーの声を周囲に届ける際、発話録など実際にユーザーが口にした言葉をエビデンスとして残しておくことは決して間違いではありませんが、それだけでは周囲を巻き込むことは困難です。

料理されている様子をずっと見ていると、その料理を食べたらどんな味だろうか？と思うがあまり食べたい気持ちになるように、プロセスを見せることがやがて共感を生みます。

ユーザーの声なき声は、プロセスを見せることでしか証明できません。ただし、これはユーザーに定期的に会っていることが前提となります。

みなさんに質問です。

ユーザーを知ったつもりでいませんか？ユーザーを知ったつもり症候群に陥ってはいませんか？ユーザーのためにつくることと、ユーザー視点は異なります。

著者も、ユーザーの声なき声を少数派（＝マイノリティ）に留めないための仕組みづくりを始めています。それは、月に1回、ユーザーと会話する機会を半強制的に設け、メンバーから質問したい、または会話しないアジェンダを募集し、取りまとめを行うオペレーションを設計し、定期運用を始めています。

実際にカスタマージャーニーマップのような共通の「ものさし」を作成し、定期モニタリングを兼ねたアップデートを月単位で行っています。ユーザーニーズが多様化し、変動が激しい今日だからこそ、作ったままで終わりにしないことが大切です。

実際にここから生まれた施策が多数生まれ、ユーザーへの共感が組織的に強化され始めてきました。まだまだチャレンジはあるものの、これまで以上にユーザーと向かうことが求められていることは確かです。

なぜなら、UX における協業優位性は、同じ業界の誰よりもユーザーのことを理解できているかで決まるからです。

そのためには先ず、我々自身がサイレントになっていてはNGです。さあ、ユーザーを探しに行きましょう！

Silent Minority（サイレント・マイノリティ） from Kazumichi (Mario) Sakata

このエントリーは「UX Tokyo Advent Calendar 2015」の5日目の投稿です。

Empathy：いま、デザインに求めらていれるエンパシーとは？

2015-09-26T19:49:37+09:00

当記事は9月8日に開催された「UX Jam #2」でお話させていただいた内容を参考にしています。

UXデザインの仕事の本質は、日々進化するツールやフレームワークを使いこなすことではなく、ユーザーへのエンパシーを高められるよう、日頃からいろいろな体験をしておくこと。そしてそんな体験をシェアし合う場が求められている、というお話でした！

ー【イベントレポ】ゆるく学ぶUXイベント UX JAM #2 | UX MILK

Empathy とは？

Empathy（エンパシー：共感力）に着眼点を置いた理由は、エンパシーこそが我々デザイナーが他の職種と差別化できる唯一の要素である、と考えているからです。

この思想に至った背景には、約2年前に参加した国際カンファレンスでの出来事があります。その日、参加者数名と一緒に懇親会を兼ねた夕食を食べに都内のレストランに足を運んだ時のことです。ファーストドリンクが運ばれるまでの開いている時間に突然隣に座っていた女性がテーブルに敷かれている紙のテーブルクロスに手持ちのペンで絵を描き始めました。

「何を描いているのですか？」そう尋ねると彼女はこう答えました。「想像に任せるよ。」確信が持てなかった著者はその隣に「こういうことですか？」と尋ねながら絵コンテのように次の一コマを絵で描いて見せました。「そういう捉え方もあるね」と目の前に座っていた男性が更にその続きの絵を無言で描き始めました。次にその男性の隣に座っていた人にペンが託され、紙芝居のように次々とコマが増えていきました。

言葉や文化、人種はそれぞれ異なるも、言葉を交わさずに絵だけでひとつのストーリーが完成しました。これがエンパシーだ、とみんなで実感した瞬間でもありました。

描かれている絵からひとつひとつの要素を抽出し、時間軸を加えて前後の文脈を保ちながら登場人物の感情や体験を設計する。これは正にユーザーエクスペリエンス・デザインそのものではないでしょうか。

描かれている絵の登場人物が置かれている状況や心境を自分ごとのように理解し、把握する力が共感力であり、いまデザインに求められている力だと考えています。

なぜ、Empathy なのか？

手前味噌ですが、登壇させていただくイベントや参加させていただくイベントの多くは、手法／プロセス／ツールのハウツーや事例などのノウハウに話題が偏ってしまっています。決してマイナスではありませんが、IT 技術の発展に伴い、これまでと比べてハウツーやノウハウなどの知識はネットで簡単に入手できるようになりました。

また、ツールや技法を習得できたとしても、良いアイディアの創出には直結しないと痛感しています。良いアイディアが創出される確率は上がるかもしれませんが、同時に「個人／個性」としての介在価値が発揮されにくくなります。

アイディアを、「洞察や分析を通じて見つかる問題に対してさまざまな観点から得られる発見や気づきを加えて発想し、具現化されるもの」として捉えると、アイディアの質は「発見や気づきを得るための観点」に依存すると言えます。

そしてこの観点を養うためには、自分自分がさまざまな体験をすることで自分ごととして対象の体験を設計するためのユーザー視点を担保しなければなりません。

これが、エンパシー（共感力）が求められている理由です。

ペルソナを作成したとしても、その属性や立場から遠い人にとっては理解が進まず、施策検討の段階でも表面的なニーズの抽出に留まってしまい、前述のアイディアの質が乏しくなってしまいます。もちろん、完全にその人になりきることは不可能であるため、昨今では「Empathy Map」など共感を促すための着眼点や方法論が議論されています。

著者の提案としては、ハウツーやノウハウの議論に時間を費やしすぎずに日頃からさまざまな体験をし、体験した素晴らしい出来事を共有する場をもっと増やしていきませんか？

当日使用した資料は下記からご覧いただけます。

事業計画・推進に求められる2つのプロペラ〜Balanced Team & Product Stewardship〜

2015-08-03T19:33:52+09:00

先日、Media Technology Lab が主催するイベント「UX Sketch Vol.2」にて事業計画に求められる2つのプロペラと題し、サービス設計に向けたヒトづくりに求められる2つの思想ーBalanced Team と Product Stewardshipーについて事例と共にお話してきました。当記事はその内容のサマリーになります。

なぜヒトづくりか？

これまでさまざまな UX 関連のイベントやセミナーに登壇・参加させていたきましたが、議論されている大半の話題は：

如何にして品質の良い「モノ」をつくるか
どのように「モノ」をつくるべきか
どのように「コト」を設計すべきか

といった、モノやコトに特化している内容でした。しかしながら、当ブログでも何度もご紹介しているサービス・デザインへのパラダイム・シフトを背景に、モノによって構成されるコトを届けるヒトそのものの体験を考えなければなりません。

言うなれば、UX デザインを実行・遂行するための UX デザインを考えていかなければなりません。

なぜなら、どんなに魅力的でテクニカルな話題を取り上げたとしても、導入する際には必ずと言っていいほど、ヒトの問題に直面するからです。

これからは、これまでのモノやコトに踏まえて、これまでにあまり議論されてこなかったヒトにより特化したダイアログを始めていくべきではないでしょうか？

ここで言うヒトづくりとはなにか？

当記事で言及するヒトづくりには教育の概念は含まれていません。どちらかといえば、サービス設計を遂行する際の複数人が関わる実行スキームや体系構築のことを指します。そして今回のテーマである2つ思想こそが、そのヒントになると考えています。

Balanced Team

Balanced Team（バランス・チーム）とは、

事業責任者／プロダクトマネージャー
介在価値：意思決定を適切なヒトに促す
UX デザイナー／デザイナー
介在価値：顧客課題を特定し、優先度を見極める
デベロッパー
介在価値：顧客への成果を継続的にモニタリングする

の3つの「個」によって形成されるチームのことを指す、サービスづくりに必要なヒトのバランスの最適解を図るコンセプトです。

役職だけ聞くと当たり前かもしれませんが、ここでは役割についても触れていきます。米国では Balanced Team をテーマとしたコミュニティが存在し、それぞれの役割について活発な議論がなされています。当ブログでは細かくは言及しませんが、詳細は当日使用した資料をご参考ください。

Balanced Team and Product Stewardship〜事業計画に求められる2つの「プロペラ」〜 from Kazumichi Mario Sakata

人数が多い場合でも Balanced Team 内の役割を遂行する人員は各1名づつが理想です。すべての情報を集約し、サービスをマネジメントしていくためのリーダーシップを担う人員で形成されているチームとなります。責任者の集まり、ではなくそれぞれがリーダーシップを発揮し、発言する体制を整えることで課題への素早い対応が可能になります。

Product Stewardship

2つ目のプロペラである Product Stewardship（プロダクト・スチュワードシップ）とはアジャイル開発から生まれた思想であり、前述の Balanced Team に加え、サービス・エコシステムを形成するステークホルダー、そしてサービスを利用するユーザーのバランスを最適解を図るための考え方です。

ステークホルダー：
外部パートナー含むサービス運営者全員が、ユーザーとのタッチポイントを形成していることへの当事者意識を持つ。
ユーザー：
ユーザー中心、ではなくユーザーと一緒にサービスを構築していくユーザードリブンな関係性を構築する。
バランスチーム：
自社組織とほか2人の「ヒト」との接点を担い、ニーズを抽出すると共にサービスに反映・展開する。

事業計画フェーズでは主要なステークホルダーを交えながらビジネスモデル等の評価をユーザー視点で行い、事前に克服すべき課題を抽出すると同時にサービスの提供価値や KPI を定めることが求められます。また、顧客とのタッチポイントを担う各人の役割を明確にすることでコトを体現するための基盤を構築することができます。

ユーザー中心ではなく、ユーザードリブンというお話をしました。これが意味することとしては、ユーザーとのヒアリングを定期的に実施し、前述のシナリオ評価を客観的に行いユーザーと共創していく姿勢です。結果としてサービスにおける対ユーザーのコミュニケーションプランや UX 戦略を策定することで構想だけに留めずに、実行に移すための足がかりを掴むことができます。

まとめ

冒頭でも記述しましたが、テクニカルな話をいくら広げようとも直面する課題は常に同じであると考えます。それは今回のテーマでもある「ヒト」に関する問題です。

どのようにモノをつくればいいのか、どのようなコトを実現すればいいのか、のみで会話するだけではなく、それらモノやコトコトを実現するためにどのようなヒトがどのように関わっていければいいか、文字通りユーザーだけではなく組織内外におけるヒトの UX デザインをもっと追求していくべきです。

事業を、ないしはサービスを計画し、推進していく我々が UX デザインを語る上で今後時間を割かなければならないのは、我々が介在することで生み出される価値、つまり介在価値の最大化を図るための実行スキームと関与するヒトの役割及び体系を考えることです。

「素晴らしい体験は、素晴らしい組織からしか生まれない」をモットーに著者も現職では実行スキームと体系の構築に少なくとも1ヶ月を費やすようにしています。

今回ご紹介した2つの思想がみなさんのサービスや事業、組織を前進させるためのプロペラとして機能することを願って。

関連記事：

<a href="http://sprmario.hatenablog.jp/entry/organizational_servicedesign" data-mce-href="http://sprmario.hatenablog.jp/entry/organizational_servicedesign">組織とサービスデザインーサービスを基点とした2つのユーザー体験を考える - UXploration</a>

<a href="http://sprmario.hatenablog.jp/entry/hcd_as_official_language" data-mce-href="http://sprmario.hatenablog.jp/entry/hcd_as_official_language">HCD導入設計論ー公用語としての人間中心デザイン - UXploration</a>

組織の新しいカタチ「Holacracy（ホラクラシー）」 - UXploration

「思い込み」でサービスをつくることは必ずしも悪いわけではない

2015-04-18T13:13:39+09:00

但し、

「思い込み」であることを自覚すること
「思い込み」は実証されるべきであること

が前提として成立すると思っています。

サービス開発における2つのアプローチ

弊社コンセントのラボにも掲載されている「カスタマージャーニーマップのパターン」でも解説していますが、カスタマージャーニーマップ、つまりは顧客の体験や感覚を可視化するサービスデザインの手法のひとつとして企業が組織として顧客視点／ユーザー視点を維持し、サービス開発を支援するツールには2つの視点が存在します。

一つ目の軸は、Inside-out/Outside-inの視点。
Inside/Outsideとは事業者からの視点として、「自社事業の観点から＝Inside-out」と、「自社事業の外側の観点＝Outside-in」となる。ここではサービス事業者の観点となるから、Outside-inは、サービス利用者の観点となる。

自社事業観点のCJMとは、「サービスがどのように利用されるか」を示したものとなる。
CJMの特徴として、顧客の体験や感情などが記されることがあるが、Inside-out型のCJMでは、そのサービスでも顧客はどう感じているのかを把握することができる。ーカスタマージャーニーマップのパターン | ラボ | 株式会社コンセント

よってサービス開発はインサイドアウト（Inside-out）またはアウトサイトイン（Outside-in）のいずれかから始まると考えることができます。

多くの場合は前者で進行することが多いのではないでしょうか。著者が担当している新サービス開発支援プロジェクトでも多くがインサイドアウトのアプローチを実践しています。ところが、自社事業の観点からサービスを開発するもアウト（顧客）との Problem-Solution Fit（課題と解決策のマッチング）が成立しなければ意味がありません。後ほど詳しく述べたいと思います。

後者はオープンイノベーションとして位置付けられているプロジェクトに多く見られます。IDEO が展開している IDEO.org もその一例です。国内では NEC やパナソニックが関連特許を無償化し、アウトサイドインのアプローチを推進しています。

デザインとアート：アウトサイドインとインサイドアウト

デザイン的活動を「問題解決」と表現することがあります。顧客が潜在的に抱えている課題を特定し、解決手段を模索する行為は問題解決そのものであり、デザイン思考のルーツもロジカルシンキングに習っていると言われています。

問いを見つけることと問いに応えることがデザインの役割であるならば、アートは問いを問うことであると考えます。一見対極にあるように見える両者ですが、必ずしもそうではありません。デザインはもはや現代社会における決定的な差別化要因ではないと話すジョン・マエダ氏はデザインとアートの関係性を以下のように捉えています。

デザイナーが生み出すのが「解決策（答え）」であるのに対し、アーティストが生み出すのは「問いかけ」である。（中略）いま彼らー顧客ーが求めているのは、自分の価値観を思い出させてくれるような方法ーーつまり、この世界のなかでどのように生きることが出来るか、どう生きるつもりか、どう生きるべきかという価値観を思い出させてくれるものである。ージョン・マエダの考える「デザインを超えるもの」 « WIRED.jp

当ブログでも何度も言及している人間中心設計（Human Centered Design）ないしはユーザエクスペリエンス・デザインは「解決策（答え）」を導くアウトサイドインのアプローチ／設計思想です。

ところが、それだけでは差別化が図りにくく、誰もが同じ答えに辿り着いてしまう可能性があり、納得が行く解決策（答え）に至らないケースが多々あります。エンドユーザーからの価値や洞察の抽出には限界があり、答えにつながるエッセンスをすべて彼らに委ねることはほぼ不可能です。車が無かった時代に要求事項を探っても、車の開発に直結する解決策は導くことはできません。

著者が担当するプロジェクトでもイノベーティブなアイディやないしは製品の開発支援を求めるクライアントが多く、アウトサイドイン「のみ」のデザイン・アプローチでは期待に100％応えることが難しい場合があります。一方で、思い込みや仮説から立案された新規事業の開発支援では、未実証の項目が多いもインサイドアウト、問いを問うアートの設計思想に従って進めることができます。

これまでは著者含め多くのユーザエクスペリエンス・デザイナーは未実証項目ドリブンでコトが進むことに違和感を覚え、反抗する姿勢を見せていました。思い込みだけで設計や開発を進めることに嫌気が差し、ユーザー調査などのリサーチありきでやるべきである、先ずはユーザーに聞いてみましょう、などどいったブレーキをかけていました。

アウトサイドイン型である Problem-Solution Fit（課題と解決策のマッチング）のアプローチを批判しているわけではなく、イノベーションを促進し、差別化を図っていく上では製品開発よりも顧客開発が有効です。プロダクトやサービスは、何をつくるべきかを教えてくれるものでなければなりません。プロダクトやサービスは、そのためのひとつの手段であり、デザインもひとつの手段だと考えています。

アーティスト的思考のスペキュレーティブ・デザイン

スペキュレーティブ・デザインとは、空論の、未来のシナリオをデザインするための考え方です。既存の価値や信念、態度を疑い、様々な代替の可能性を提示するためのコンセプトとして注目を浴びています。

Speculative Everything: Design, Fiction, and Social Dreaming

作者: Anthony Dunne,Fiona Raby
出版社/メーカー: The MIT Press
発売日: 2013/12/06
メディア: Kindle版
この商品を含むブログを見る

例えば、スマートフォンなしの生活は考えられないと思いますが、逆に保持することで大切な喜びをもたらしてくれているでしょうか？そもそもスマートフォンにはどんな価値が存在し、その価値はどのようにして取り戻せられるのかを考え、思想や思い込みを作品としてないしは製品として提示する。正に問いを問うアーティストのような発想がスペキュレーティブ・デザインと言われています。

問いかけは思い込みがあってこそ成立すると思っています。もっと言えば思い込みがなければ未来のシナリオをデザインすることができないのではないでしょうか。アップルのスティーブ・ジョブスはデザインの心得を大切にしていたことで有名ですが、その斬新な発想と彼なりのビジョン、思い込みはアーティストそのものでした。

アウトサイドインのデザインアプローチが Problem-Solution Fit（課題と解決策のマッチング）であるならば、インサイドアウト型であるスペキュレーティブ・デザインのアプローチは Vison-Customer Fit（ビジョンと顧客のマッチング）と言えるかもしれません。

結果、これからのデザイナーにはアーティストとしての要素が求められているのではないでしょうか。

まとめ

冒頭に戻りますが、思い込みがでサービスをつくることは必ずしも悪いわけではありません。インサイドアウトのアプローチですべてのサービスがつくられるべき、というわけではありません。

一番のリスクは思い込みだと自覚せず、ファクト（事実）として錯覚してしまうことです。そして、例え自覚していても実証せずに思い込みのままで終わってしまうことです。

実証には事前であれ事後であれ、アウトサイドイン（Problem-Solution Fit）のアプローチを採用すべきであり、著者含むユーザエクスペリエンス設計業務を担当する人は思い込みが発生した時点で「待った！」のブレーキをかけずに実現を構想に落とすための手段を考えるべきだと思います。「待った！」と思い立つこともひとつの思い込みであるという自覚が必要です。

思い込みはなにか？
ファクト（事実）はどれか？
アイディアはなにか？

この軸で情報を整理し、製品を介した顧客の価値創出という名の顧客開発をどのように進めていくべきか？

これが今正に求められているデザインの役割なのではないでしょうか。

LEAN UX Japan Conference 2015〜LEAN UXが拓く未来〜

2015-03-12T13:06:07+09:00

書籍「Lean UXーリーン思考によるユーザエクスペリエンス・デザイン」を基点に LEAN UX を実践・普及させることを目的とした有志による団体 Lean UX Circle の活動開始から約半年が経過しました。

活動中はファシリテーター制度を導入し、参画している企業担当者が自身でミートアップを企画し、イベントを開催する取り組みを月に1回の頻度で開催してきました。また、2014年冬からはワーキンググループ形式で複数の企業担当者を集めたコラボレーションを主体としたツールや方法論の制作・開発などを行ってきました。

そして2015年4月11日ではその集大成となる Lean UX Circle 主催の国内カンファレンス「LEAN UX Japan Conference 2015〜LEAN UXが拓く未来〜」を開催します。

日程：4月11日（土）
時間：13:30〜19:00（懇親会：19:00〜21:00）
会場：リクルートアカデミーホール
申し込み・プログラム：公式サイトをご覧ください

書籍「Lean UXーリーン思考によるユーザエクスペリエンス・デザイン」が刊行されてから1年以上が経過し、当ブログでも以前ご紹介したように様々な企業による取り組みがなされてきました。

本カンファレンスではこの1年間の各社による取り組み例をご紹介すると共に、組織への導入にあたっての課題解決に向けたヒント、並びに LEAN UX を取り囲むように誕生した、グロースハックやデザインスプリントのコンセプトをご紹介しながら、改めてLEAN UX の思想とその価値を参加者のみなさんと一緒に再発見・拡大していきたいと考えています。

400名以上の方が参加された昨年の LEAN UX 刊行記念セミナーとは異なり、今年は LEAN UX のオントロジーに主軸を置いたプレゼンテーションないしはディスカッションを主体としています。

開催背景と想い

LEAN UX はやり方ではなく、あり方です。手前味噌ですが、書籍が刊行されてから多くの企業様にお声がけいただき、ワークショップやプレゼンテーション、パイロット・プロジェクトをご一緒させていただいたと共に、様々なイベントで参加者の方々と意見交換をさせていただきました。

実に多かった意見として、

構想に時間が要され、開発や実装との連動が難しく優先度が下がってしまう
効果が見えにくい

などがありました。

LEAN UX は、他で言及されているようなデザインスプリントなどの手法とは異なり、マインドセットやコンセプトであると考えています。

それは、エンドユーザーにとって正しいプロダクトやサービスをつくることを念頭に置いた、組織における共創の文化を再確認・浸透させるための考え方であり、本来の組織としてあるべき姿を提示してくれる指針でもあります。

Lean Startup のルーツであるリーン生産方式は、無駄を省くことを徹底していましたが、誰にとっての無駄なのかを取り違えてしまうとスピードのみが重視され、かつ短期における結果を求める姿勢が強まってしまうことが背景としてあります。この「誰にとっての無駄なのか」を正すためにユーザー視点を取り入れた LEAN UX の思想が必要だと考えています。

そのため、短期間で効果を期待するものではありあせんし、一度の実践では本質な価値が見出だせない可能性があります。

だからこそ LEAN UX の思想や価値を再確認し、再び探求していく必要性があるのではないかと考え、Lean UX Circle として本カンファレンスを開催する運びとなりました。

継続する努力

パレートの法則ではありませんが、Bloomberg の調査によると新規事業やスタートアップが18ヶ月で成功する確率は20％と言われています。ポイントは、18ヶ月という調査ながらも設けた期間が1年以上であることと、20％という数字です。

一時的な結果として捉えた場合に、20％という数値は低いですが、成功する確率を高める方法は継続だと考えます。もちろん、そのためにはプロダクトやサービスに込められた想いが大切であり、かつ継続するためのエンジンとなる軸を設ける必要があります。

答え合わせをするために無暗に回答を続けるのではなく、正しい答えを導きやすくするための仮説の設定と間違った理由を探るための視点を養うことができれば、数少ない回答で正解することができます。LEAN UX で度々ご紹介している CPS仮説検証モデルが、それに値します。

話を少し戻すと、成功する確率を高めるためには一定の継続が求められます。ミドリムシビジネスで成功を収めているユーグレナ社長の出雲充氏が提唱する実にシンプルな理論に納得が行きます。

例えば、「１回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99％は失敗する状況です。ではその状況であきらめずに２回挑戦した時の確率はどうなるか。２回とも失敗する確率は99％×99％＝98.01％です。つまり、成功確率は約２％（1.99%）となり、１％成功確率が上がります。３回、４回、５回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が１%の出来事は459回繰り返せば、失敗する可能性が１%」になるんです。

ー失敗率99%のミドリムシ事業を成功させた男の"シンプルな法則" ｜ Biz/Zine

失敗する確率が20％であろうと1%であろうと、数値のみで姿勢を変えるのではなく、継続して成功する確率を上げる努力と継続を支援するために LEAN UX があります。本カンファレンスでは大企業からスタートアップまで組織の規模や役職を問わず、LEAN UX の継続的な実践と実現をテーマとした様々な方のプレゼンテーションやディスカッションを行います。

最後に

LEAN UX では構想のイメージが先行してしまいますが、書籍でも言及されているようにスタッガードスプリントの代替ソリューションとなるようなスプリントをはじめとする、構想から実現までを捉えた組織としての取り組み全体を視野に入れており、正しくモノをつくるためではなく、正しいモノをつくるための組織文化の醸成が価値に値します。

前後の工程を通じて同じ仕組みやプロセスを導入していないことを問題視するのではなく、同じ思想（想い）を用いてプロダクトやサービス開発に取り組めているかを考えるべきです。

結果として手法やプロセスも、以前ブログでもご紹介した人間中心設計の共通言語化に通じますが、組織ごとに異なるはずです。昨今話題のデザインスプリントも、Google Ventures が自身の組織ないしは自身がパートナーとして参画している組織形態に最適化するように設計されているがために、そのまま仕組みとして己の組織に導入することは創造性に欠けています。

このようなプロセスや手法の登場に伴い、組織への導入が騒がれると導入後の評価はプロダクトやサービスではなくプロセスや手法を軸に判断されてしまう恐れがあり、ユーザー視点が欠けてしまいます。

仕組み化は組織の状況にあわせて行われるべきだと考えます。そのような事態から打開すべく、本カンファレンスでは LEAN UX という思想をご紹介しながらものづくりや組織におけるやり方ではなく、本来のあり方を模索できればと考えています。

ぜひ、ご参加ください。

リーンスタートアップのリフレーミング：Frame-Build-Measure-Learn（構成-構築-計測-学習）

2015-03-07T22:32:07+09:00

まえがき

当記事はアメリカに拠点を置くアジャイル開発を支援するエージェンシー Ralley Software のチーフテクノロジストである Zach Nies氏の記事を許可の元、翻訳・再編した文章です*1。

<a href="https://www.rallydev.com/community/agile/frame-build-measure-learn-knowledge-and-innovation-uncertain-world" data-mce-href="https://www.rallydev.com/community/agile/frame-build-measure-learn-knowledge-and-innovation-uncertain-world">Frame, Build, Measure, Learn: Knowledge and Innovation in an Uncertain World | Rally Software Community</a>

日本でもソフトウェア業界をはじめ、関心が集まっている Lean Startup（リーン・スタートアップ）。無駄を徹底的に省くことに目が奪われがちですが、語源となったと言われている Lean Body（リーン・ボディ：引き締まった身体）を目指すためのダイエットに同じく、無駄がなくなることは結果であり、成果ではありません。リーン・スタートアップは正しいモノが生み出されることを成果とする、または正しいモノが生み出されるまでを支援する手法体系であり、正しくモノをつくるための方法論ではないと考えます。

"A company following the lean methodology is like a well-trained body - almost nothing but muscle. It can be large, like a bodybuilder, but only because it needs all those resources (muscles) to build the product customers want & need." ー The Lean Startup Circle Wiki / Misconceptions about Lean Startup

そんな中、原稿の記事を拝見し、リーン・スタートアップを主題としたものづくりにおける様々な現象の Framing（構成）と Unframing（分解）を繰り返し、意味性を追加する彼のメタ的視点に感銘を受け、翻訳を通じて読者のみなさまにご紹介をしようと思い立ちました。Product-Solution Fit という表現がありますが、その実現と効果的な検証のためには当記事も紹介されている Testing-Modeling Fit が必要不可欠だと確信しました。

その真髄は、結果の判断のみで「失敗した」と思考停止する状態を避けるための継続を促すフレームワークです。目先の利益や結果に捕らわれてしまい、失敗したから次の方法論へ…という悪循環に陥りやすい状態から脱却するためには、繰り返し実験をする、繰り返し努力をすることが重要だと考えます。

失敗するであろうと世間から言われてきたミドリムシ事業を発展させ、成功を収めている株式会社ユーグレナ― 代表取締役出雲充氏の言葉がそれを物語っています。

『例えば、「１回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99％は失敗する状況です。ではその状況であきらめずに２回挑戦した時の確率はどうなるか。２回とも失敗する確率は99％×99％＝98.01％です。つまり、成功確率は約２％（1.99%）となり、１％成功確率が上がります。３回、４回、５回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が１%の出来事は459回繰り返せば、失敗する可能性が１%」になるんです。』

ー失敗率99%のミドリムシ事業を成功させた男の"シンプルな法則" ｜ Biz/Zine

これまで当ブログでご紹介してきた CPS仮説検証モデルを基軸に、繰り返しの実験をより生産的に実施するための「Frame-Build-Measure-Learn（構成-構築-計測-学習）」、ぜひご参考ください。

はじめに

著書『リーン・スタートアップ』で Eric Ries氏は Build-Measure-Learn（構築-計測-学習）のフィードバックループを提唱し、不確実性が高い状況下におけるものづくりの指針をアップデートしました。このフィードバックループの目的は前提となる思い込みやリスク、未開拓領域を知識に変え、不確実性が高い状況下でもチームやメンバーが効率的に前に進むためのイノベーティブな方法論として紹介されています。フィードバックループにおける最も大切な要因は学び（学習）や発見です。つまり、仮説となる思い込みや前提が実証あるいは検証されるまでの期間をどれだけ短縮しかつ無駄を省き、次に繋げるために有効活用できるのか、ということです。

言うのは易く行うは難し、という言葉があるようにこのような説明にはジレンマが生じます。 Build-Measure-Learn（構築-計測-学習）のフィードバックループを順番通りに着手し、学習の手前である実証や検証を目的とした実験の段階に突入すると多くの人がどのように実験をすればいいのかわからず、得られた結果が例え想定外であったとしても何を学びとすればいいのか確信が持てず、不確かな状況が続くことがあります。

但し、これは良い傾向にあると考えています。想定外の事情に直面することは正に実験の醍醐味であり、想定内の事情が起こった現象の背景や意図が理解できない状態よりも発見や収穫は多いはずです。設計や構築により多くの時間を費やすことに慣れている環境下では、学習期間に多くを費やすことに意味性を見出すことは難しいかもしれませんが、不確実性が高ければ高いほど、言葉を変えれば実証されていない要素が多ければ多いほど、このフィードバックループは有効だと考えています。

((c) Ralley Software Development Corp.)

現時点で「フィードバックループの重要性は理解した、または理解している。では具体的にどのように実験や実証を通じて学びや知識を得れば良いのだろうか？」という疑問を抱いている方がいらっしゃると思います。ここで私が提案したいのは、フィードバックループのBuild-Measure-Learn（構築-計測-学習）には最も大事なステップである Frame（構成）が抜けているということです。私が提案する、「Frame-Build-Measure-Learn（構成-構築-計測-学習）」によって、今後実施される実験や実証をより効果的に消化することができると考えています。

Frame（構成）

新しく提唱したステップである Frame（構成）には2つの側面があります。課題の構成と実験の構成です。この2つのアプローチによって、以降の Build-Measure-Learn（構築-計測-学習）はより活きていきます。

課題の構成

実証や検証のためにモノをつくる前に、先ずはどのような学びを得たいのか、あるいはどのような課題を解決したいのか、という構成から始める必要があります。Build-Measure-Learn（構築-計測-学習）こそ Build（構築）からプロセスはスタートしていますが、思考順序は逆を進みます。 Learn-Measure-Build（学習-計測-構築）となり、仮説を軸とした学びや発見を得るためには、どのような実験を行えば、またはどのような計測をすれば対象の仮説が実証されるのかを先ずは考え、そのためのプロダクトやサービスを構築する、という手順です。

この構想そのものが Frame（構成）です。先ず始めに対象のユーザーに対して共感力を強め、顧客開発と共に顧客発見や理解を促進するような実験を検討していきます。昨今ではジャーニーマップなど優れた手法が紹介されているので、仮説ベースで可視化をし、ユーザーへの共感を強めていく準備を事前に進めることができます。アプローチすべき正しい課題や仮説を設定するためには、ユーザーへの共感こそが全てです。

実験の構成

では次に実験を構成するための手順をご紹介します。

背景：なぜそのような実験を試みようと思いましたか？なにを学び、そしてなぜ学びたいと思いましたか？これらの質問に対する回答を記載してみましょう。慣れない作業かもしれませんが、書くことによって学びや発見の可能性が更に広がります。
仮説：簡単にでも良いので、これから実施する実験への期待を考えてみてください。この場合の仮説とは、実験の想定結果です。科学実験と同じく、仮説が不在では実験後の結果の善し悪しの判断がつきづらくなってしまいます。
実験方法：考えられる実験方法や要素を洗い出してみてください。手順も詳細に書いてみましょう。これが最も重要です。後に言及する「Experiement Report（実験シート）」に従って各要素を書き出してみましょう。あわせて、実験の妨げや影響要因となるような可変要素も同時に把握することで、仮説の設定が容易になります。
期待する計測結果：定性及び定量の側面から実験を通じて仮説が実証・検証されたことを判断するための指標を書き出してみましょう。定量情報は「WHO（誰が）・ WHAT（なにを、なにが）・WHEN（いつ）」を明確にすることができ、定性情報はその背景にある「HOW（どのように）・WHY（なぜ）」を理解することができるため、双方の実験を推奨しています。

上記に記載の手順に従って各要素の洗い出しを進めることで、実験の最中に直面する想定外の現象に対しても冷静に検証を進めることが可能になります。人間の脳は検証の場において、目の前で発生する現象に対して疑いもなく期待していた結果だったと都合良く解釈してしまう癖があるようです。実験終了後にも必ず当シートを参考に確実に実験を振り返るように心掛け、失われかけた学びを取り戻すようにしましょう。課題と実験の Frame（構成）によって、その後の学びの質は決まります。

Build（構築）

Experiment Report in Lean Startup（リーン・スタートアップにおける実験用レポート） from Kazumichi Mario Sakata

仮説を軸とした学びや発見を得るためには、どのような実験を実行すれば対象の仮説が実証されるのかを先ずは考える…と前述しましたが、構築の対象となるプロダクトやサービスの目的は学習や発見の達成のためとして位置付けることができると思います。そのためには以下の3つのポイントを抑えておくと良いかもしれません。

1. 実験方法を考える

実験の構成が終わったら、次はデザインを施し、構築し、実際に運用するステージへと移っていきます。実験は細かければアジャイル開発に習って実験を細分化し、頻度を上げて実施してみましょう。但し、忘れてはならないのはすべての実験はひとつのプロダクトやサービスに紐付いていることです。得られた結果や学びを前に、正しい情報や必要とするデータに目が行くようにしましょう。実験終了後には次にすべきことが自然と明確になっている必要があります。もし不明確なのであれば実験方法から、ないしは仮説の設定から再考することを推奨します。

2. 実験の場をつくる

実験が大掛かりに、かつ複雑にならないように気をつけましょう。MVP という言葉があるように、可能な限り小さな単位で実験を計画・実行することで仮説が実証・検証しやすい環境をつくりだし、学びや発見を見失わないように心掛けます。対象となるプロダクトやサービスも同様に、小さくする必要があります。著者の推奨は、ペーパープロトタイプやランディングページです。どちらかで大半の仮説を実証・検証することができると思います。

3. 実験を行う

対象が整い、開始する準備ができたらいよいよ実験です。実験という言葉からはある程度の労力や準備が必要のように思えてしまうかもしれませんが、実際はユーザーインタビュー程度の負荷で実施できるサイズにまで最小化することを推奨しています。言わずもがな、一番の理想は最小の実験で最大の成果（学びや発見）を得ることです。

Measure（計測）

実験を行い、十分なデータや情報は揃いましたでしょうか？ここからは結果を計測するステージに入っていきます。実験の方法を考え、実験する際に事前にまとめた実験そのものの背景や仮説に立ち戻り、仮説を実証・検証する際に重要となる要素を事前に整理しておきましょう。

実験の場では実際にどのようなことが置きましたか？結果からはどのように仮説を評価することができますか？得られた結果は仮説を実証・検証するにあたって十分でしたか？ここでのポイントは、先ほどの実験シートにまとめた事前に期待していた結果と事後に発生した結果の差分を、可能であれば定量・定性の双方の側面から比較することです。

最後に、定量・定性データを整理し、最終的にどのような現象が発生したのかをチームメンバーに理解していただくために、ストーリーテリングの要領でストーリーにまとめて学びや発見を形式知化できるように工夫しましょう。もちろん、すべての結果を参照し、レポート形式にする必要はありません。サービスとして、ないしはプロダクトとして最も大きな収穫に関するデータや情報のみに絞り、やがてチーム全体の学びへと発展し、次のステップへ自然につながるような流れを生み出すようにしましょう。

Learn（学習）

Frame-Build-Measure-Learn（構成-構築-計測-学習）の最後のステップで期待される効果は、更なる実験の構想が浮かび上がること、ないしは次のステップに進むためのアクションが自然と明確になることです。実験の前にまとめた仮説と期待していた結果を実際の結果と照らし合わせてみましょう。なにが起こりましたか？時間やリソースを学びや発見のために費やしたのですから、得られた学びや発見は何でしたか？その学びや発見は、次に向けてどのように活かされるべきですか？次のステップはなにからはじめますか？

Experiment Sheet（実験シート）に戻り、上記内容と結果をまとめてチームメンバーに共有しましょう。これは、次のステップ、学びを得るために費やされたコスト、結果から得られた洞察などを含みます。実際の実験結果よりも、記載した洞察や学びのほうが価値がある場合が多いためです。

最後に、学んだことや得られたことを透明性を維持してチームに浸透させるかのように振る舞うように心掛けてください。オフィス内のワークスペース周辺に関連資料や写真などを貼ってみましょう。難しければ共有スペースにでも配置し、他者がいつでも閲覧できるように工夫してアクセシビリティを担保してみてください。結果としてそれぞれの立場から得られた学びや発見を独自で解釈し、自信の業務に活かすことができますし、予想もしていない第三者からの助言や追加の学びを共有してくれる空気を創りだすことができます。学びが多ければ多いほど、良いプロダクトやサービスは生まれます。

もちろん、チームメンバーと共同で実験を進めることが理想です。もし、実験から得られた学びや発見をサービスやプロダクトに最大限活かしたいのであれば、構築や計測をする前に実験と課題の構成をしましょう。そのための、Frame-Build-Measure-Learn（構成-構築-計測-学習）です。スピードも去ることながら、不確実性が更に高まりつつある昨今、我々のこの先の未来はこの思考回路に委ねられているのではないでしょうか。

*1:This article is copyrighted by Rally Software Development Corp. Used with permission.

HCD導入設計論ー公用語としての人間中心デザイン

2015-03-01T18:53:45+09:00

産業技術大学院大学の履修証明プログラム「人間中心デザイン」の受講から早やいもので3年が経過しました。昨年は開講されなかったものの、2014年度はシラバスが大幅にリニューアルされ、過去最大となる30名を越える5期生の方々が受講されています。

本プログラムは、「高いユーザビリティ、よりよいユーザー体験（UX）を提供するものづくり」を実践するための、人間中心デザイン（HCD）の諸理論並びに関連分野の知識の習得と、企画・デザインを行う具体的な手法及び技法の習得を目的としている。

ー産業技術大学院大学『人間中心デザイン』全体シラバス

2014年度は以下の3つのユニットによって構成されています。

デザインリテラシー編（入門、解析、発想法など）
方法論編（調査、評価、サービスデザインなど）
応用演習（総合演習）

昨日2月28日（土）には最終回となる応用演習の「HCD導入設計論」が開催され、人間中心デザインの卒業生として過去の受講生の方々と一緒に、自身の経験から人間中心デザインにおける組織への導入に関する話題提供をさせていただました。

本講義は、本履修証明プログラムの全体での学びの振返りを狙ったものである。人間中心デザインを各企業において普及・促進する方法を考えるとともに、受講者が今後どのように企業内で学んだ手法等を活用していくべきかについて議論する。

ー産業技術大学院大学『人間中心デザイン』全体シラバス

人間中心デザインとスター・ウォーズ

人間中心デザイン（HCD）ないしはユーザエクスペリエンス（UX）の導入についてはこれまで UX Tokyo や Shibuya UX 主催で開催したイベントやディスカッションの場でも話題は尽きず、今後も半永久的に議論される内容だと考えています。今回は「HCD導入設計論」と題した集中討議の場が設けられたこともあり、本セッションでは著者の七年間の経験で取り組んできた人間中心デザインと常にあった葛藤を、ジョージ・ルーカス監督が手掛けたSFシリーズ「スター・ウォーズ」の文脈に従ってご紹介しました。

なぜスター・ウォーズなのか？

著者の個人的な好み…でもありますが、銀河系の自由と正義の守護者として一人前のジェダイ戦士を目指すルークに助言を呈するマスター・ヨーダの思想は、人間中心デザインの導入にあたって学ぶべきことが実に多くあります。

例えば、ジェダイと対立する銀河系の悪と恐怖の信奉者であるシスとの長期戦争において、正しいと思っていることを遂行するも自身の力不足に挫折し、「信じられない…」と苛立ちを隠せないルークに対してマスター・ヨーダはこのように語りかけます。

That is why you fail.

（それが失敗する理由だ。）

ースター・ウォーズエピソード5「帝国の逆襲」より

人間中心デザインを導入しようとするあまりに正しくモノをつくろうとする力、ないしは強制力が働いてしまい、上手く行かなかった状況下で最も陥りやすい場面です。自身がルールブックであり、自分ではそれが正しいことだと考えている一方で、どこか煮え切らない。裏側にある否があることを知っていても認められない自己正当化、エゴのいたずらです。

著者も同様の経験がありますが、信じられない…と目の前の現象を受け入れられない状態から脱却するには、人間中心デザインに習ってことを進めることよりも、本来あるべき正しいモノをつくるための思想やアプローチを探求・追求することで必然的に対象の組織体系にフィットした人間中心デザインが生まれてきます。

もうひとつ、マスター・ヨーダは力（勢力）が第一である巨大な帝国国家シスとの戦いの中でルークにこのような言葉を投げかけます。

To answer the power with power, the Jedi way is not. In this war, a danger there is of losing who we are.

（力に力で応えようとするな。この戦いで最も危険なのは、己が誰であるかを見失うことである。）

ースター・ウォーズエピソード1「ファントム・メナス」より

人間中心デザインを導入しようと働きかけることの目的や必要性が理解できなければ、自身の活動に対して意味性を見出すことができず、加えて前述した自己正当化の圧力が増幅し、強制「力」に頼ってしまう可能性があります。このままでは、アナキンのように我を見失ってしまいます。

人間中心デザインの最も大切なステップ

にて紹介されている人間中心デザイン（HCD）を参照する際に、実践に直結する以下の4つのステージについ目が奪われがちです。

ところが、著者が最も大切にしているポイントは上記の4つではなく、その前後に位置付けられる以下の2つです。

人間中心設計の必要性の特定
システムが特定のユーザー及び組織の要求事項を満足

本来、人間中心的思考の開始ポイント（問題意識）は「（1）人間中心設計の必要性の特定」から始めるべきです。その際に、

必要とされている状態とはどのような状態か？
必要性を見極めるポイントとはなにか？

を念頭に入れる必要があります。また、本来の思考着地ポイント（目的意識）は「（2）システムが特定のユーザー及び組織の要求事項を満足」であるべきです。

組織における要求事項とはなにか？
組織における満足とはなにか？

必要性が特定できなければ導入する意味や目的が不明瞭のまま、なんでHCDって必要なの？と突き詰められて終わってしまいます。

ー WebUX研究会×ShibuyaUXの共同HCDワークショップ - UXploration

本セッションでは著者の経験を交えながら、主に上記ポイントを考察するための学びをご紹介させていただきました。

人間中心デザインないしは自身を必要とされている状態を探り、必要性を見極めるためには例えそれがデザインとは作業工程的に遠く離れている場所でも、それはデザインとは無関係である…という心理的距離を離さないことが大切だと考えます。ユーザーとの接点を担うからこそ「主体者」として、デザインを導く立場として振る舞うことで人間中心デザインの可能性を狭めないようにすることが大切です。

組織における要求事項や満足するポイントを探る上では、UX Maturity Model（UX成熟度モデル）でも言及されているように、対象組織の成熟度を把握し、相手の理解できる言葉で伝える工夫が求められます。また、エンドユーザー「だけ」を対象とせず、人間中心デザインに込められている「人間」の本来の意味を理解し、優れたユーザー体験を実現するための手段として、組織の成熟度を高め自走できる環境を促す意味でももう一人のユーザー（ステークホルダーやサービスプロバイダー）の体験も考慮する必要があると考えます。

まとめ

最後に、人間中心デザインは「言語」です。当たり前ですが、言葉は交わすために存在します。但し、それぞれが異なる言葉を交わしていては、ユーザーへはもちろん、組織内の人間にも想いは伝わりません。

伝えることと伝わることは別です。伝えることは手段であり、結果として伝わっているかどうかは評価しなければわかりません。伝えたことで満足してしまっては双方のコミュニケーションは成立しません。最も重要なのは、伝わることです。

ー優れたUXを実現するための人間中心デザインとは？ - UXploration

著者がこの記事を日本語で書いている理由は、言わずもがな、日本の読者の方に読んでいただきたいためであり、そのための手段として公用語（日本語）を採用しています。人間中心デザインは、組織における公用語として機能すべきと考えています。

組織では、必要なノウハウや大切にすべき価値観などの多くは言葉で伝わっていきます。役職や職種が多様化する組織では共通の定義と意味で理解し合うことが出来る言語が必要があり、第三者であるユーザーの想いが組み込まれている人間中心デザインこそ、その役割を果たすことができます。

ただ、本セッションのように人間中心デザインの導入に責任感を感じ、前述したルークのような状態に直面してしまっては意味がありません。導入には目的や必要性が前提として存在している必要があります。公用語は手段でしかなく、導入による効用は、導入する目的を軸に考えなければなりません。

そのため、人間中心デザインの効用は導入に至った背景や目的ごとに異なるはずです。言葉を変えれば、組織ごとに公用語は異なるはずです。

人間中心デザインの公用語化によって工数の削減に成功した、打ち合わせの時間が劇的に改善された、などの成功を収めたケースを見かけますが、同様の効果や目的を期待して導入に走ることは公用語の特性を考えると、本質的ではないように思えます。そのためには、一人一人が自分自身の中で人間中心デザインを公用語としてどのように捉え、確立させ、どのように社会や組織に役立てていくべきなのかを考えていかなければなりません。

フォースを操る、ジェダイ戦士のように。

A Jedi uses the Force for knowledge and defense, never for attack.

（ジェダイ戦士はフォースを攻撃のためではなく、自身の知恵や防御のために使うのだ。）

ースター・ウォーズエピソード3「シスの復讐」より

ぼくと人間中心設計の七年間戦争 from Kazumichi Mario Sakata

ぼくと人間中心設計の七年間戦争

この場をお借りして、お声がけいただいた安藤先生、ご参加いただいた受講生のみなさまに感謝申し上げます。ありがとうございました。

組織の新しいカタチ「Holacracy（ホラクラシー）」

2015-02-18T22:49:31+09:00

ブログを移転しました。新しいページに自動で切り替わります。3秒お待ち下さい。

----

突然ですが、Holacracy（ホラクラシー）という言葉を耳にしたことはありますでしょうか？

日本ではまだ参考文献が少ないためご存知の方は少ないかもしれませんが、サービスデザインないしは組織デザインのための学習の一環として調査し、まとめてみました。

Wikipedia によると、ホラクラシーとは従来のようにトップダウンのヒエラルキーによって意思決定がなされるのではなく、組織全体に権限を分散させ意思決定させることで、自走する組織を保つための社会技術または組織のガバナンス・マネジメント方法*1と定義されています。

企業、NPO問わず今ではアメリカを始めフランスやドイツ、オーストラリア、イギリスで導入実績があるとのことですが、有名なところでは Airbnb、Zappos、Medium が導入例として紹介されることが多く、日本でも一部記事によって紹介されています。

「ホラクラシーの下では意思決定機能が組織全体に広げられ、人々は役職ではなく役割を与えられる。伝統的な組織では、目標や目的、さらにタスクまでもが上から個々の担当者に流れていくものだ。我々のやり方では、マネージャーというのは基本的に世話役に過ぎない。マネージャーは、作業担当者の障害を取り除くために存在しているんだ」

ーAirbnbの「マネジメントしない」マネジメント方法とは：前編 | ReadWrite Japan

「このホラクラシー、元はと言えばソフトウェア会社で開発のために考えられた、昔ながらの上から下に命令を下す形態を、「自律したサークル」のようなものに置き換えた形です。理論的には、このシステムを導入することにより、社員は会社の経営に関してより発言権を持つようになります。根本的には、ホラクラシーは、「人」中心ではなく、「やらなければならない仕事」を中心に、会社を組織するのが目的です。その結果、社員には肩書きが必要なくなったのです。社員は、明確な目的を持っていくつかの職務を担当します。1つのチームや部署で働くのではなく、大抵は複数のチームの一員として、それぞれの場所で特定の役割を果たします。」

ー「すべての階級を廃止」米Zappos社が導入した組織管理システム「ホラクラシー」は成功するか？｜ライフハッカー［日本版］

なぜ、ホラクラシーなのか？

ホラクラシーの浸透によって、組織が本来どのように構造化されるべきか、どのように意思決定がなされるべきか、どのようなガバナンスレベルが行き届くべきかを改めて見直し、変化を受け入れる組織へシフトするきっかけが生まれると考えています。

いまではグーグルやマイクロソフトのような巨大企業で働く従業員も、企業が益々組織的になっていくことに嫌気が差し、スタートアップに転職するケースが増えていると聞きます。

(c) HolacracyOne, LLC

簡単にまとめると、ホラクラシーには4つの特徴があると言われています。

柔軟な組織
効率的な組織運営
役割の明確化
主体性の強化

ホラクラシーの歴史

2007年に Ternary Software とうソフトウェア会社の創設者である Brian Robertson 氏がまとめた公文書*2によって浸透したと言われており、元々の語源は1967年に Arthur Koestler 氏の著書「The Ghost in the Machine」で提唱されたホラーキー（holarchy）から来ており、ギリシャ語の holos（Whole / 全体）が由来となっている。ホラーキーは独立独行でありながらも全体の一部であるという認識のもと、全体を司る一部でありながらも独立した一部である、という双方の機能を保持していることを意味します。

ホラクラシーはイテレーティブ（反復）な組織運営や適応プロセス、自律組織などのキーワードで説明することができますが、その根底にはアジャイル開発やリーン生産方式の思想が根付いています。

ホラクラシーの主要原則

前述した Robertson氏がまとめた公文書は今では彼が所属する HolacracyOne の公文書として発表されておりますが、ここでホラクラシーの原則をいくつかご紹介したいと思います。

活発化する役割

ホラクラシーにおける組織構造の積み木となるのが、役割です。ホラクラシーには役割と、その役割を更に活発化させるための「エナジャイザー」の存在が不可欠であり、自身の言葉でキャパシティやポテンシャル、機能すべき役割や期待できる結果を表現できるように促さなければなりません。まるで上下がない、団体スポーツにおけるポジションのようです。

役割は、肩書きや職種のことではありません。ひとりが複数の役割を担うことも可能になるということです。参考までに、HolacracyOne の組織構造をこちらの公式サイトよりご覧ください。

(c) HolacracyOne, LLC

インタラクティブに各円型組織を閲覧できるようになっています。小さいひとつひとつの円が人です。詳細を確認すると、役割と決定権限がある内容の一覧等が組織内で明確になっていることが分かります。再度言及しますが、役割であり、肩書きや職種ではありません。そのため、複数の役割を保持している方が複数名か存在するものの、役割上の重複が見られないことが特徴です。

円型の構造

ホラクラシーにおける組織構造は、バラエティに富んだ役割が円型に集合して構成させる自律組織です。ひとりひとりが創造し、実行に移し、評価するためのプロセスを常に保てるようにしなければなりません。円型の組織では自身で組織運営に向けた会議を実施し、役割を新たに設け、メンバーを選発するなどの取り組みを自己責任のもと遂行っします。円型の組織ではひとりひとりの役割のリンクが重要です。

ガバナンス（統治）の強化

円型組織は複数存在する場合もあります。それぞれに生まれる円型組織では独自で定義すべき組織運営のためのガバナンスを周囲の役割や方針に従って定めていく必要があります。ホラクラシーではすべての円型組織を統合した意思決定の方法論を用いることで、多種多様なインプットをそれぞれの円型組織から自動でかつ効率的に入手できるようになります。

オペレーションプロセス

ホラクラシーにおける組織運営では、様々なオペレーション上のニーズに応えるべくそれぞれの円型組織のメンバーが自身の役割を果たすために効率的に、かつ協働的に運用されるべきです。そのため、会議においても意思決定権がひとりひとりに分散されているため、会議が効率的に開催されることが特徴として挙げられます。

(c) iStockphoto

ホラクラシーは未発達？

但し、ホラクラシーはいいことばかりではないようです。

昨年に独自のマネージメントやリーダシップ論を提唱している Steve Denning氏を発端とした反論*3も生まれてきています。そのひとつに、アジャイル開発やリーン生産方式をモチーフにしているホラクラシーモデルには顧客視点が不足していると指摘しています。

すでにホラクラシーを導入している有名企業のひとつに Zappos 社などがありますが、Zappos 社は創設時よりすでに顧客中心の組織であったが故に成功していると考え、顧客中心の発想が根付いていない組織には専属部隊の欠如により不向きなのではないか、と加えています。

あくまでもひとつの反論ですが、ホラクラシーの商標登録をしている HolocracyOne ではそれぞれの指摘に対する意思をブログで表明しています。また、既に導入している企業と連携することにより、未だ歴史が浅いホロクラシーの更なる進展を目指しているようです。

従来のマネジメント体系であるヒエラルキーとは異なり、ホラクラシーは市場変化が激しいIT特有のマネジメント体系かもしれませんが、引き続きウォッチしていきたいと思います。

組織とサービスデザインーサービスを基点とした2つのユーザー体験を考える - UXploration

ブログを移転しました：

*1:Holacracy - Wikipedia, the free encyclopedia

*2:Robertson, Brian (June 2007). "Evolving Organization". Integral Leadership Review 7 (3).

*3:Making Sense Of Zappos And Holacracy - Forbes

優れたUXを実現するための人間中心デザインとは？

2015-02-06T17:24:58+09:00

当記事は、2015年2月5日に無料動画のオンライン学習サイト - schoo WEB-campus（スクー）にて開催した授業「優れたUXを実現するための人間中心デザインとは？」のフォローアップになります。

当日の授業の内容は schoo の下記ウェブサイトよりご覧いただけます（会員登録が必要です）。

&amp;amp;amp;amp;lt;a href="https://schoo.jp/class/1682" data-mce-href="https://schoo.jp/class/1682"&amp;amp;amp;amp;gt;優れたUXを実現するための人間中心デザインとは？坂田一倫先生 - 無料動画学習｜schoo（スクー）&amp;amp;amp;amp;lt;/a&amp;amp;amp;amp;gt;

はじめに

当企画は schoo と弊社コンセントとの合同企画で「社会に求められる価値あるデザイナーとは？」というテーマのもと、著者含むコンセントのアートディレクターの佐藤とサービスデザイナーの大崎の3名でそれぞれの立場から1人づつ授業を開催してきました。

最終回となる今回は、以下のポイントを軸に人間中心デザインを題材としたモノづくりからコトづくりへの発想転換を背景に、いま社会に求められるデザイナー像を探っていきました。

① 美大卒だけがデザイナーとしての価値を発揮するとは限らない。

初回と前回の授業を担当した2人とは異なり、著者は美大を卒業しておらず特にビジュアルデザインにおける専門知識はほぼゼロに等しい状態でした。

但し、だからこそ「見える」デザインよりも「見えない」デザインを重視したアプローチやマインドセットを強化する姿勢を保つことができ、デザインをする立場からデザインを導く立場で振る舞うデザイナーとしての必要性を理解することができたと共に、デザイナーの新たな価値創出の場を見出すことができました。

結果として美大を卒業した方のみがデザイナーになれるという固定観念を取り払い、より多彩な専門家をデザインという土台に招き入れることができるのではないかと考えています。

② 正しくモノをつくろうとするのではなく、正しいモノをつくろう。

今回の題材となっている人間中心デザインというアプローチはあくまでも手段であり、目的ではありません。

人間中心デザインの根底にある思想や目的を理解することで、正しくモノをつくろうとする力よりも正しいモノをつくろうという力が働きやすくなります。

人間中心デザインは、正しいモノをつくるための「ものさし」として以降、解説していきます。

人間中心デザイン的思考回路

著者の社会人経験はIT企業のビジュアルデザイナー（見習い）からスタートしました。様々なウェブサイト上で露出される特定商品のバナー制作やその先のランディングページである特集ページのデザインやコーディングを担当していた時期です。

当時は Photoshop や Illustrator などの専用のソフトウェアを使い分け、限られた空間（サイズ、露出枠など）内で作業をすることに喜びを感じていましたが、少しづつ、ランディングページへの導線設計やランディングページそのものの設計範囲までを含めたコンテンツや機能設計に関心を持ち、ウェブディレクター職へと移りました。ウェブディレクター時代は制作の進行管理やサイトの簡単な情報アーキテクチャなどを担当しておりましたが、サービスそのものを抜本的に改善したいという想いが強まり、

「どのように」つくるか？から「なにを」つくるか？そして「なぜ」つくる必要があるのか？

と問い質すようになったことがきっかけでサービスデザイン領域からモノづくりに関わっていけるようなポジションに身を置くようになりました。

本当にユーザーから必要とされている、または正しいモノをつくるためには先ず誰のために、なぜつくるのか？を明確にしなければならない。

これは、ユーザーとの接点を担っているデザイナーだからこそ課題意識として認識できるのではないでしょうか？

この思想に辿り着いたのは学生時代に専攻していたユニバーサルデザインの提唱者であるドナルド・ノーマン博士の著書「誰のためのデザイン？」で言及された「ユーザー中心設計」との出会いでした。

「誰のためのデザイン？」が出版された1980年代以降、エンジニアリング領域からもヒューマンセントリックなモノづくりの重要性が主張されはじめ、1999年にISO 国際規格として「人間中心設計」が制定されました。

すべての人が使いやすく、という考え方は非合理的です。誰にとっても使いやすいプロダクトやサービスを目指せば、誰にとっても使いにくいモノになってしまう。

ユーザーの立場からも誰のためのプロダクトやサービスなのかが理解できず、自分ごと化できずに終わってしまう恐れがあります。だからこその人間中心デザイン改め人間中心設計なのです。

花とデザインと伝わる仕組み

「デザインとは、相手に花束を渡すようなものだ。」

ー中西元男（PAOSグループ代表）

著者が学生時代に大変お世話になった、師匠の言葉です。人間中心設計はここで言う花束の届け方、つまりは「伝わるしくみ」を考える行為・プロセスそのものです。

「伝わるしくみ」を考えることは日常的に誰もが無意識に行っている行為です。例えば大切な方や友人にプレゼントを渡すシーンを想像してみてください。

まず初めに、相手に伝えたい想いがあるはずです。例：ありがとう、ごめんなさい、付き合ってください、等
(1) の想いを表現するために用いられるのがプレゼント（モノ）です。ここであなたは想いがより相手に伝わるためのプレゼントを、相手の性格や特徴を踏まえて選んでいることと思います。
プレゼントが揃いましたら、想いを伝えるための方法を考えるはずです。いつ、どこで、どのように渡せば想いは伝わるのか、伝わるためのしくみをあなたは考えているはずです。
相手は受け取ったプレゼント（＝想いを表す記号的役割を果たす）からあなたの想いを解読し、結果はどうであれ応えるはずです。
あなたは相手の反応を待って、自分が用意したプレゼントはもちろん、伝えるためのしくみが正しかったか、伝わっていたかを評価し、次に活かそうとするはずです。

人間中心設計も全く同じ思考手順で進みます。

伝わるしくみを考える上で大事なポイントは2つあります。

伝えることと伝わることは別です。伝えることは手段であり、結果として伝わっているかどうかは評価しなければわかりません。伝えたことで満足してしまっては双方のコミュニケーションは成立しません。最も重要なのは、伝わることです。

相手に、ユーザーに、伝わったつもりではいませんか？

誰が、いつ、どこで、なにを、どうしたら伝わるのか？そもそもなぜ伝える必要があるのか？伝わるしくみを考える際のこれらのポイントは、お気づきの方もいるかもしれませんが「5W1H」と称される問題発見と問題解決と同じ思考のフレームワークを採用しています。

結論、人間中心設計の本質は問題発見と問題解決であると言えます。

人間中心設計は問題の解決策を探るだけではなく、解決したいそもそもの問題を探る行為・プロセスなのです。

結果として、人間中心設計を通じて問題発見力・問題解決力を養うことがができます。

ここでは8つのステップで解説していきました。

問題発見：

データ分析
データ分析には3つの意図があります。過去からパータンを探る、いまを知る、未来を予測する。
ファクト抽出
ユーザーを知るための情報を抽出していきます。不足があれば、定性調査等で補います。
ユーザー定義
ユーザーが実在するかのように非言語情報として可視化し、周囲のイメージ強化を図ります。
シナリオ定義
時間軸でユーザーの生活を把握します。問題が多く発生している箇所を解決することが本質的な問題発見・解決に至るとは限りません。

問題解決：

解決案作成
問題とその原因を特定後、5W1Hに習ってユーザーに伝える解決する方法を模索していきます。
構造定義
データやデバイス、ウェブサイトが全体の構造としてどのように調和していくべきなのかを考えます。
詳細設計
解決する方法を軸に、想いを伝えるための表現手段を考えます。
評価
事前・事後問わずユーザーに正しく伝わり、問題の解決に至ったかを検証します。

幸せの「ものさし」

言わずもがな、そもそもものさしとは長さを測るためにあります。

なぜ人々はものさしを用いるのか。

当たり前のことではありますが、ものさしを使わずに対象を見ただけでは長さの判断においてばらつきや歪みが生じ、不都合が生じてしまう恐れがあるためです。

デザインにも同じようなことが言えます。

チーム内で同じものさしで物事や事情を測らなければ、ばらつぎが生じ、確信をもって判断ができなくなってしまいます。そしてこの人間中心設計は、チーム共通のものさしとして機能します。

前述した、誰によって、いつ、どこで、どのように、そしてなぜ対象のプロダクトやサービスが使われているのか？を発見し、問題を特定することで以降の問題解決でも同様に、誰に、いつ、どこで、なにを、どうやって伝える（提供する）のか、そもそもなぜか、を共通の目盛として考えていきます。

人間中心設計はプロセスである、と説明しましたが必ずしもスタート地点がどの場合においても一緒とは限りません。場合によっては評価からはじめることもありますし、特に新規事業の場合は事前のデータなどがないため、仮説としてユーザーを定義したりします。

ポイントは、問題発見と問題解決で目的を明確に区別することで人間中心設計で陥りやすい手段の目的化から逃れることができます。

人間中心設計を参考にすることで、定量・定性の両方の側面から様々なプラスの効果を得ることができます。

資料に記載の数値的な結果と同様の効果を補償することはできませんが、ひとつ言えることは失敗はしません。チーム内で共通のものさしを設けることができれば、「正しいモノ」が測れるようになりチーム、そして組織を成功へと導いてくれます。

著者が過去に担当したサービスも、サイトリニューアルを通じてコンバージョン率がリニューアル後3ヶ月で平均54.2％（昨対比）も改善し、事業に大きく貢献しましたが、何よりも嬉しかったのはリニューアル後に事業の各スタッフがリニューアル中に定めたユーザーやシナリオが正しかったかを継続的に検証を進めていることでした。

人間中心設計の価値は定性的な側面による効果が大きく、対象の事業も同様の効果が見られた故だと考えています。

チームメンバー全員が主体的にモノづくりに関わっていけた。
ターゲットユーザーが共通言語として成立していた。
ものさしとして機能し、機能開発の優先順位が明確になった。
リリース後も継続的な改善を促すことができた。
全体スケジュールやコストを平均20〜25％短縮することができた。

上記図のように、人間中心設計は無限かつ自動車のエンジンのように前輪と後輪で役割を明確化し、組織の中で稼働し続ける必要があります。

「人間中心と言うからには、私は本当に人の幸せを考えらているのか、常に考えるようにしている。」

ー中埜博（東京環境構造センター代表）

プロダクトやサービスは、ユーザーにとってその先にある目的やゴールを達成するためのひとつの通過点に過ぎません。

だからこそ、その先にあるユーザーの姿をも視野に入れ、自社のプロダクトやサービスがその人の幸せに向けてどのような役割を果たしているのか、を理解する必要があります。

人間中心設計または伝わるしくみを考えることは、想いを伝える先にいる相手の幸せを考えることだと思います。

そのためのものさしを、設けてみませんか？

まとめ

人間中心設計という名前こそ専門的な印象を受けますが、前述した「伝わるしくみ」に置き換えて考えることができれば、明日からでも実践することができます。

例えば、料理を食べさせてあげるときやメールをするとき、仕事場でプレゼンをするときなど、相手がいてこそ成立する日常のコミュニケーションに遭遇することがあれば、ぜひ、伝わるしくみの要領で想いを的確に相手に伝え、伝わるためのしくみづくりやコトづくりを意識してみてください。

そのように身の回りの日常から意識し、創造的に活動をすることでデザイナーでなくともデザイナー的思考のもと、人間本来誰しもが持っている創造力を取り戻し、そして育み、発揮することができます。

デザイナーには、「伝わるしくみ」のような無形の概念や言葉を形にできる、ないしは表現できる大きな強みがあります。

だからこそ、冒頭の正しいモノへと周囲を導くことができると信じています。

社会に求められるデザイナーとは？というテーマで人間中心設計という行為やプロセスを軸にデザイナーのあるべき姿や担うべき役割を述べさせていただきましたが、社会から一方的に求められるだけではなく「求めてもらえる」ようなデザイナーを目指すことが結果としてデザイナーの価値創出に繋がるのではないでしょうか？

schoo x CONCENT「優れたUXを実現するための人間中心デザインとは？」 from Kazumichi Mario Sakata

おしらせ

いかがでしたでしょうか？

schoo と弊社コンセントとの合同企画で「社会に求められる価値あるデザイナーとは？」というテーマのもと計3回に渡り授業を開催してきましたが、みなさんからお寄せいただく質問や疑問にすべてお答えできなかったことが悔みです。

そこで来る2月25日（水）にクリエイティブスペース「amu」にて afterschoo、デザイナーのための放課後と題し、授業を担当した3名によるトークセッションとみなさまとのディスカッションの場を設けさせていただきました。

下記より申し込みいただけます。

&amp;lt;a href="http://afterschoo.peatix.com/" data-mce-href="http://afterschoo.peatix.com/"&amp;gt;CONCENT DESIGNERS’ AFTERSCHOO&amp;lt;/a&amp;gt;

ご都合が会いましたらぜひ、お気軽にご参加ください。オフラインでもお会いしましょう。

Lean UX Quest in Tokyo at Lean Startup Update!! 2015

2015-01-17T12:37:22+09:00

書籍『Lean UXーリーン思考によるユーザエクスペリエンス・デザイン』が刊行されて1年が経過しました。年明け1月に刊行されたこともあり、2014年を Lean UX と共に盛り上げていけるよう公私共に様々な冒険（クエスト）という名の活動を繰り広げてきました。Lean UX Quest と題し、これまでの取り組みを振り返ってみたいと思います。

尚、当記事は昨日開催された Lean Startup Update!! でお話させていただいた内容を基にしています。

STORY 1: PUBLIC

大変嬉しい事に、刊行直後には Lean UX の第一人者である Janice Fraser氏が来日し「Lean Startup マスターワークショップ」と題した1日ワークショップを実施しました。Janice氏は「Get Out of the Building!」思想をとても大切にされており、当日のワークショップも大半の時間を外で過ごすチームもいました。

仮想のサービスの立ち上げに際して事前にチーム内でリストを洗い出し、解消するための実験を介した顧客開発・顧客理解を主とし、得られた学びをチーム及びワークショップ参加者全員に共有することで実験の大切さ、学びの大切さを教えてくれました。

&lt;a href="http://sprmario.hatenablog.jp/entry/2014/02/27/Lean_Startup_%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%83%E3%83%97" data-mce-href="http://sprmario.hatenablog.jp/entry/2014/02/27/Lean_Startup_%E3%83%9E%E3%82%B9%E3%82%BF%E3%83%BC%E3%83%AF%E3%83%BC%E3%82%AF%E3%82%B7%E3%83%A7%E3%83%83%E3%83%97"&gt;Lean Startup マスターワークショップ - UXploration&lt;/a&gt;

更にその3ヶ月後には『Lean UX』の著者である Jeff Gothelf氏が来日しました。Janice氏同様に1日ワークショップ形式で行われましたが、Jeff氏は仮説ステートメントの作成に重きを置き、より科学的な実験を行うためのフレームワークや方法を伝授してくれました。

We believe [This feature（機能）] for [this persona（ペルソナ）] will achieve [these outcomes（得られる効果）] by measuring [metrics/KPI（主要な指標/KPI）]

当日の内容はグラフィックレーコンディングとしても記録されているので、ぜひご覧になってみてください。

&lt;a href="http://sprmario.hatenablog.jp/entry/leanuxtokyo" data-mce-href="http://sprmario.hatenablog.jp/entry/leanuxtokyo"&gt;Lean UX Tokyo ー実践型 Lean UX ワークショップ - UXploration&lt;/a&gt;

2014年3月6日にはGREEにて出版記念イベント『Lean UX が拓く最適なデザイン』を開催しました。企業規模や事業形態を問わず、3名のゲストスピーカーをお招きし最適なデザインを実現する際に求められるデザイニング・カルチャーの重要性やそのカルチャーをつくる上でのポイントを Lean UX を基点にディスカッションを行いました。

当日はなんと400名を越える方にご参加いただき、大成功に終わりました。ご参加いただいたみなさま、ありがとうございました。

<a href="http://engineer.typemag.jp/article/leanux" data-mce-href="http://engineer.typemag.jp/article/leanux">「Lean UXとは組織文化をデザインすること」監訳者が明かす、UXデザインの本質 - エンジニアtype</a>

STORY 2: PRIVATE

Janice Fraser氏と Jeff Gothelf氏。このお二人に来日していただけたことはとても貴重な機会であり、多くの学びを得ることが出来ました。「考える」と「つくる」。それぞれに重きを置いたお二人のワーク内容を参考に、2014年下期では計6社にお邪魔してプライベートなワークショップやパイロットプロジェクトをご一緒させていただきました。

特に印象的であったのは Yahoo! JAPAN 様でのワークショップでした。一部のカンパニーの約半数の社員、約300名を対象としたワークショップを計17回に別けて実施し、Lean UX の社内浸透を担当の方と一緒に検討を進めてきました。様々な方から貴重なご意見等をいただくことができ、本書に習い様々な試行錯誤を繰り返して行きました。

ワークショップでは Lean Analytics でも言及されている CPS 仮説検証モデルに従い、担当されているサービスの顧客情報やサービスの要素を書き出していただくことで、実証するための軸設定を主としました。

思い浮かべている顧客は本当に実在するのか？
対象の顧客が抱えている問題は実在するのか？
その問題に対して対象のサービスは解決に繋がっているのか？

などの思い込みを排除し、実証に繋げることが目的です。ワークでは前述した Janice氏や Jeff氏の教えを参考にプロトペルソナやシックスアップスケッチ*1を取り入れ、Lean Startup に UX のエッセンスを加えた文字通り Lean UX の実践に務めました。

リーンキャンバスなどを用いて関係者間の認識を統一するためには、情報の非言語（ノンバーバル）表現が有効です。例えば30代主婦をサービスのターゲット・セグメントとした場合でも、ひとりひとりが思い浮かべる30代主婦は異なるはずです。どこに住んでいるのか？子供はいるのか？子供とどのような生活をおくっているのか？自分時間をどのように有効活用しているか？など言語的情報では分かり得ない情報をよりフォーカスすることで発見することができ、共通言語化すると共に言語表現では見えてこない潜在的欲求を探求することができると考えています。

ワークショップにおける最終的なゴールは実際の現場に応用し、即実行できる状態をつくりあげることでした。そのために CPS の軸に従った実証を進めるための MVP の設計や検証方法を指定の時間軸に従って整理していきました。この場合は2日、2週間、2ヶ月という制限を設けることによってアイディアの散乱を防ぐことを念頭に置きました。

最後にワークショップ以外にも実際に新規サービスの現場に応用すべく共同でパイロットプロジェクトを進めている企業様もいます。まだ実験中ですので半年後には良いご報告ができるのではないかと個人的には思っています。

なぜ Lean UX なのか？

著者が Lean UX を推奨する理由は大きく別けて4つあります。

どのようにつくるかではなく、どのようなものをつくるかにフォーカスしたマインドセットを養うことができる。
問題解決よりも問題の発見と定義に重きを置くことでサービス価値の最大化に貢献できる。問題解決（サービス）の質は、定義している問題の質と比例していると考えています。
透明性を維持し、共創文化を醸成する。本来のモノづくりはどうあるべきなのか？Lean UX を実践することによってその問いの重要性に気付かされます。
ユーザーのみならず、メンバーからの学びを大切にする。人数の分だけ学びは存在すると考えます。

STORY 3: LEAN UX CIRCLE

Lean UX は組織文化をデザインすることと等しいと考えます。そのため、組織への浸透は容易ではありません。共創を組織内だけに留めず、社会全体の共創を促す場として本書『Lean UX』を基点に Lean UX を浸透・実践・普及させるための有志による団体「Lean UX Circle」を2014年夏に立ち上げました。

今では88名のメンバーが在籍し、Lean UX に関する様々な問題を解決する場として月1の頻度でクローズドな環境下で活動をしています。

Lean UX Circle の活動も Lean Startup / Lean UX の要領で改善を重ねてきました。参加されているメンバーの解決したい問題を軸に集まったメンバーで発想・創造を繰り返し、アイディアをテストした結果を月1の活動で共有することで、学びを促進する Build-Measure-Learn（Think-Make-Check）を体現しています。

活動開始から約半年が経過し、2015年3月の最終報告会に向けて追い込み期間に突入しています。以降の活動については未定ですが、2015年も冒険は続けます。ご興味がある方がいらっしゃればお気軽にご連絡ください。

正しくモノをつくろうとするのではなく、正しいモノをつくろう。

Lean UX Quest in Tokyo from Kazumichi Mario Sakata

最後に、他の登壇者のプレゼンテーションも非常に刺激的な内容でしたのでご紹介します。

TOCから俯瞰するリーンスタートアップ（河合太郎氏）
LEANSTARTUPの現場 #leanstartup（黒田樹氏）
Lean Analytics at Lean Startup Update!! 2015（角征典氏）
実録！現場におけるLeanStartupの実践（冨山香織氏）
人間と話す: Lean Customer Development (Lean Startup Update 2015)（馬田隆明氏）

Lean UX 関連記事：

*1:プロトペルソナ並びにシックスアップスケッチの概要はテンプレートはこちらをご参考ください。

組織とサービスデザインーサービスを基点とした2つのユーザー体験を考える

2015-01-12T20:13:40+09:00

はじめに

当記事は、2015年1月10日にヤフー株式会社にて開催された HCD-Net 教育セミナー「第7回サービスデザイン方法論フォローアップ講習会」でお話させていただいた内容の描き下ろしです。

尚、当日の内容は静岡の常葉大学未来デザイン研究会の学生の皆様によるグラフィックレコーディングとしても記録されています（ありがとうございます）。

((c) 第7回サービスデザイン方法論 - コンバル！)

当日の資料は Slideshare よりご覧いただけます。

サービスとサービスデザインのイデオロギー

「サービスデザイン」という言葉が最初に使われたのは1990年代初頭にドイツのKöln International School of Designで開始された「サービスデザイン教育プログラム」と言われています。以降、2004年に Service Design Network が設立され、サービスデザインに纏わる様々な議論がなされてきました。定義は実に様々ですが、はじめに「サービスデザイン」と「サービス」について、認識を揃えた上で進めていきたいと思います。

サービスデザインとは、顧客と対象サービスの背景に存在するサービス提供者が関わる接点全体を、デザインの対象として捉え、その最適化を図るアプローチと考えています。つまり、接点を介して相互作用する顧客とサービス提供者間の「コミュニケーションデザイン」とも言い替えることができます。

以前に航空会社におけるサービスについて分析したサービスブループリントを当ブログでご紹介しましたが、例えばスーツケースなどを荷物を集荷し、機内に運んでいる地上スタッフとは直接的なコミュニケーションは発生していませんが、間接的に対象の航空会社のサービスを司る一部として顧客として「サービスを受けている」ことになります。飛行機の離陸準備が整う、つまりは荷物が機内に積まれてたことを意味します。一部の航空会社では荷物の集荷状態をトラッキングできるサービスを提供し、直接的なコミュニケーションを実現しているケースもあります。

サービスにおけるコミュニケーションは、サービスを受ける側と提供者側とのインタラクションの連続性によって成立します。そのため、一部でもコミュニケーション上のトラブルが発生してしまうと、対象のブランドないしはサービスへの受ける側からの総合的な評価が下がってしまうことがあります。

なぜなら、提供者側の視点からコミュニケーションは1対N（不特定多数）の形態をとっていることに対し、サービスを受ける側は1対1の視点でインタラクションを継続しています。顧客満足度アンケートに「◯◯のサービスはいかがでしたか？」に似た質問項目をよく見かけますが、回答する際にサービスを1人の人格にあてはめて総合評価している感覚です。

前述したコミュニケーション上のトラブルは深刻な課題です。一昨年に発生した某ホテル・レストランのメニュー表示と異なった食材を使用していたことに関する事件で、その原因は部門間における情報伝達の仕組みや作業過程に不備があったことを明かしました。このようなトラブルはやがて表面化し、顧客の見える範囲となって露出してしまう恐れがあります。1対Nと1対1、この視点の違いこそコミュニケーション上のトラブルが発生してしまう要因なのではないかと考えています。

サービスデザインを上記のように定義すると、サービスとは顧客とサービス提供者の相互作用の生起によって創造・構成される社会システムと考えます。これは、事業や製品をすべて「サービス」として捉えるサービス・ドミナント・ロジックという視座をもとにしています。日本におけるサービスには教育・研究、医療・保険・介護、流通、事業向けサービスなどが分野として存在しますが、すべてに共通しているサービスの特性は、以下の3つに分類することができるのではないでしょうか。

無形性 (Intangible)：物として触ることができない
同時性 (Simultaneous)：生産と消費が同時に発生する
異質性 (Heterogeneous)：人によって価値が異なる

つまり、サービスは一人一人の顧客との間に存在する、組織の無形資産であることを意味します。サービスを組織の無形資産とするのであれば、その無形資産を有効活用するアプローチがサービスデザインだと考えています。

フロントステージとバックステージのエクスペリエンス・デザイン

ここからはサービスの登場人物であるサービスの受け手側となる顧客とサービス提供者という2つの視点から、サービスデザインを解説する上でよく言及されるフロントステージとバックステージ、それぞれの体験をデザインするためのアプローチについて考えてみたいと思います。

昨年に開催された、Facebook の開発者会議「f8」にて、同社CEOのマーク・ザッカーバーグ氏による基調講演が大変参考になりました。

サービスを使うためだけに人々が存在しているかのように”ユーザー”と呼ぶのはごう慢に等しく、ヒューマンセントリックなサービスを構築するために、まずは人々がそれぞれ生活や好みを持つ存在であることを認識する必要がある。ーFacebook Home: People First, Mobile Best (Video) - Forbes

People FirstーFacebook が f8 で掲げたキーワードです。ここから学べきことは、サービスを受ける側の「人」に対してどのように組織としてコミュニケーションしていくべきかを考える大切さ、だと思います。サービスを提供する「人」にも目を向け、双方の視点から俯瞰的かつ具体的に自社のサービスを捉え、正に人間中心設計的思想で考えていく必要があります。

話を少し戻します。フロントステージとバックステージにおける体験は、飲食店に例えると以下のように整理することができます。

フロントステージにおける体験：CX（Customer Experience）
CXは入店から退店までの来店者における一連の体験のことを指します。
バックステージにおけるUX：EX（Employee Experience）
EX は注文の受付から厨房で料理を完成させるまでの一連の体験のことを指します。

サービスデザインの対象となるそれぞれの代表的な要素に、カスタマージャーニー、タッチポイント、製品、オペレーションなどがあります。

UX（ユーザエクスペリエンス）の「ユーザー」はエンドユーザーやカスタマーを指しているケースが多く、ユーザー視点で如何にサービスの接点を構築していくかということが議論されてきましたが、実現にはその背景に存在するもうひとりの「ユーザー」であるサービス提供者及びその組織に目を向ける必要があります。ユーザーとのコミュニケーションが阻害されている課題として

いまユーザーや現場で何が起きているか把握できない
その原因が特定できない
施策の効果を予測することができない

などが存在し、組織内のサイロや情報伝達・情報取得手段の希薄、職責の不明などが影響しているのではないでしょうか。打開するためにはフロントステージのみならず、バックステージにおける体験も視野に入れて検討していく必要があります。

正に人間中心設計です。これまで主にフロントステージを対象に行われてきた同様のアプローチを、もう一つのユーザー、バックステージのエクスペリエンスデザインの一環として適応することで相乗効果が期待できます。

事実、後にご紹介する著者が関わっているプロジェクトの多くは、結果としてバックステージ上のコミュニケーションデザインに分類され、直面する上記3つの課題解決に向けたシステム開発やユーザー体験の設計、ガバナンス方針の改善などのアプローチを検討してきました。

ケーススタディ

これまでの言及にあるサービスデザインの2つの視点、フロントステージのみならずバックステージにおける体験のデザインは容易ではありませんでした。プロジェクトは1年以上を要し、多くのステークホルダーと関わるため長期戦となりました。

詳細には記載できませんが、某AV家電メーカーでは前述のオペレーションに該当するプロダクション・ライン（ワークフロー）の改善を担当させていただきました。職種や債務の定義、中間生成物の整理から意思決定プロセスの最適化までを進め、「らしさ」の体現を検討していきました。

もうひとつはオフィス機器メーカーにて組織の文化を形成するガイドラインなどの公式ドキュメントの整備を進めました。全社共通のブランドメッセージを体現すべく、ウェブを始めとする海外支社を含む全社のタッチポイントの構築に伴う方針を明文化し、バックステージ間のオペレーションの再編成を含む、エンドユーザーとのコミュニケーションプランに相当する内容を検討しました。

目を海外に向けると、バックステージにおける体験のデザインの重要性が伝わってきます。

GE は全従業員30万人の共通目的意識を養うためにクラウド、BYOD、ビッグデータ、そしてコラボレーションを活用した Colab を導入し、主要な製品の生産性の向上に専念しています。

最近話題の Airbnb では「One Airbnb」をブランドコンセプトに掲げ、全従業員のエンゲージメントを向上させるために存在する専属部隊が採用活動の改善から労働環境の整備に力を入れ、従業員ひとりひとりのサービスへのコミットメント率を高める施策をとっています。結果、88％の従業員が Airbnb の職場を友人が知人に推奨したいという評価結果となり、顧客ロイヤリティーを高め従業員として雇用することを最終目的として様々な取り組みをされています。

まとめ

なぜサービスデザインなのか？

著者の私見ですが、ユーザエクスペリエンスデザインを実践する際に、残念ながらエンドユーザーのみの施策に留まってしまっているケースを多く経験してきました。しかし、サービス・ドミナント・ロジックの観点からサービスのあるべき姿を捉えると、これからはサービス提供者側（バックステージ）のエクスペリエンスの改善にも注力し、議論を更に深めていくべきだと考えています。結果としてエンドユーザーの立場におけるユーザエクスペリエンス価値向上に貢献できるのではないでしょうか。

素晴らしい体験は、素晴らしい組織からしか生まれないと思っています。

但し、組織そのものをデザインすることは容易ではありませんし、それを担う役職でなければ実現は困難です。しかし、当ブログでも何度もご紹介している米 Yahoo! CEO のマリッサ・メイヤー氏のようにサービスデザイン的思想のもと、経営改革を推し進めている企業もいます。

ヤフーでのわたしの役職は、製品のデザインではなく、組織のデザインをするということ、戦略のデザインをすること、ヤフーで働くとはどういうことなのかをデザインすることだと考えています。もちろんデザインも大切ですが、あくまでデザインは一部でなくてはなりません。すべてのプロセスの一部でなくてはいけないと思います。ーマリッサ・メイヤー

CXO でなくとも、同志を募り、様々な角度からアプローチを図り、既成事実を積み上げることができればサービスデザインを組織に浸透させるための説得力を上げることができるのではないでしょうか。そのためには、情報の発信こそすべての出発点だと考えます。結果として周囲を巻き込みまたは巻き込まれ実現に向けて進むことができると考えています。

この記事も、そのために書きました。この文章が、サービスデザイン固有の領域に関するディスコースの活性化に僅かながらも貢献できることを願って。

組織とサービスデザインーサービスを基点とした2つのユーザー体験を考える from Kazumichi Mario Sakata

Concent × schoo－優れたUXを実現するための人間中心デザインとは？

2014-12-28T17:12:43+09:00

オンライン学習サイト「schoo（スクー）」にて、「社会に求められているデザイナーとは？」をテーマにした弊社コンセントとのコラボ企画の全3回連続授業の内、第3回目となる「優れたUXを実現するための人間中心デザインとは？」を担当させていただくことになりました。

<a href="https://schoo.jp/class/1682" data-mce-href="https://schoo.jp/class/1682">優れたUXを実現するための人間中心デザインとは？坂田一倫先生 - 無料動画学習｜schoo（スクー）</a>

第1回「デザイン領域の拡張に伴うデザイナーとしての役割とは？」
（2015年1月22日（木）放送）
第2回「サービスデザイン時代のデザイナーのあり方とは？」
（2015年1月29日（木）放送）
第3回「優れたUXを実現するための人間中心デザインとは？」
（2015年2月5日（木）放送）

schoo（スクー）とは？

12万人が登録するオンライン上の学校です。WEBデザイナー学部、グローバルビジネスパーソン学部、スタートアップ学部の3つの学部にて構成され、今回の企画は約1万人の学部生が学んでいるWEBデザイナー学部の授業の一環として生放送されます。

メールアドレスまたは Facebook でサービスに登録することができ、生放送はすべて無料で配信されています。希望の授業の詳細ページにて「受けたい」ボタンを押下すると授業前にリマインドメールが届き受講することができます。

著者も過去に幾つかの生放送授業を聴講させていただきましたが、毎日のように開催されており、隙間時間にイヤホンで聴きながら作業をすることも可能なため効率的に学習することができます。聞き逃した授業でも録画形式でアーカイブされるため大変便利です。

UX忘年会と題し、BEENOS 山本さん、Yahoo! JAPAN 瀧さん、iemo 鞍立さんと12月上旬に行った授業も録画で配信されています。こちらもぜひご覧ください。

&lt;a href="https://schoo.jp/class/1610/" data-mce-href="https://schoo.jp/class/1610/"&gt;UX忘年会今活躍中のデザイナーが語るこれからのデザイナーの価値坂田一倫先生 - 無料動画学習｜schoo（スクー）&lt;/a&gt;
UX忘年会今活躍中のデザイナーが語るこれからのデザイナーの価値 - 無料動画学習｜schoo（スクー）

優れたUXを実現するための人間中心デザインとは？

当ブログでも何度も言及している人間中心設計（Human Centered Design）ですが、学術的な印象を持たれる場合が大変多く、組織への導入やデザイナーとしての自身のスキルアップに繋げていくための足掛かりを見出すことが難しいとの声をよく耳にします。

(c) HCD-Net

当授業ではWEBデザイナー及びWEBデザイナーを目指している方を対象に、上記懸念の解消に直結するヒントをご提供できればと想い、モノからコトへの発想転換を基点に、「伝わる仕組み」としての人間中心設計の概要や導入事例、期待される効果などをわかりやすく解説する予定です。

「伝わる仕組み」については先日の記事「サンタクロースに学ぶUXデザイン」でも言及しましたが、「どうやって」「なにを」つくるか？よりもそもそも「なぜ」つくる必要があるのか？そして「誰のために」つくり、その魅力や価値を「どのように」伝えていくべきなのか？正に伝わる仕組みをそのものを考えることが人間中心デザインなのではないかと考えています。

相手はどのようなプレゼントを欲しているのか？どのようなプレゼントを届ければ喜ぶのか？どのように届ければ喜ぶのか？このプレゼントがもし、あなたが担当するプロダクトやサービスだったら？ーサンタクロースに学ぶUXデザイン - UXploration

90分の長丁場ですが、人間中心設計またはUXデザインに関する様々な疑問や質問をみんなで共有し、互いに理解を深めていければと思っています。どうぞよろしくお願いします。

人間中心設計の基礎 - UXploration
人間中心設計の基礎 - UXploration

サンタクロースに学ぶUXデザイン - UXploration
サンタクロースに学ぶUXデザイン - UXploration

サンタクロースに学ぶUXデザイン

2014-12-25T21:54:38+09:00

当記事は、著者が幼少期の大半を過ごした米国での実体験を基に再現したクリスマス・ストーリー*1です。殆どが著者による推測によって書かれた文章ですが、いま思えば、サンタクロースこそ優れたユーザエクスペリエンス・デザイナーなのではないでしょうか？

( (c) Some rights reserved )

この時期になると、著者が住んでいた市では町中が綺麗なイルミネーションに覆われていました。小学校の近くではご近所さん同士が協力し、一帯がひとつのアート作品として輝いていました。それを学校帰りの母の迎え車の中で妹と3人でドライブしながら毎年鑑賞していたことは、いまでも忘れられません。

ショッピングモール型の商業施設では必ずと言っていいほどイベントスペースには4階建てに相当する高さのクリスマスツリーが飾られ、クリスマスイヴが近くになるにつれ、決められた時間になんとサンタクロースが登場します。

子供たちへのインタビュー

( (c) Some rights reserved )

順番待ちをしていると、子供たちが次々とサンタクロースの両膝に座り、記念撮影をするとともにサンタクロースとの会話を楽しんでいる様子が伺えます。順番が来るまで、著者は欲しいものを一生懸命考えていました。

出番です。妹と2人でサンタクロースに歩み寄ると満面の笑みで私たち兄妹を抱きかかえるかのように暖かく包んでくれました。写真撮影に没頭する両親を横目に、サンタクロースから幾つかの質問が投げかけられます。

お名前はなんていうの？
何歳かな？
将来はなにになりたいの？
今年はどんな年だったかな？
どんなことに挑戦したの？
最後の質問だよ、欲しいプレゼントはあるかい？

著者は、当時流行っていたおもちゃが欲しい、と強く伝えました。笑いながらサンタクロースは「考えておくよ」とニッコリと笑い、私たち兄妹はサンタクロースに手を振りながら、その場を後にしました。

クリスマスプレゼントの準備

( (c) Some rights reserved )

クリスマスまであと数日。サンタクロースはきっと今頃、私たち兄妹のことを思い浮かべながらプレゼントを準備してくれているに違いない、と夢を抱きながらカウントダウンをしていました。

タクソノミーの作成

( (c) Some rights reserved )

サンタクロースはきっと忙しいはずです。全世界の子供たちにプレゼントを渡すのですから。子供たちの数だけプレゼントはあるー今頃サンタクロースはきっとプレゼントが混在しないために、インベントリー（リスト）を基にひとつひとつのプレゼントにタグを付けて整理しているに違いない。クリスマス当日に、より簡単にプレゼントを袋から取り出しやすくするために。

そのタグには子供の名前と年齢、国と住んでいる場所、プレゼントの中身が記載されているはずです。

シナリオ設計とシミュレーション

( (c) Some rights reserved )

サンタクロースはどうやってプレゼントを私たち兄妹の枕元に届けるのだろう？家の形はもちろんそれぞれの家庭で異なり、同じようにプレゼントが届けられるのだろうか？

サンタクロースはきっとプレゼントの最善の届け方を考えてくれているに違いない。そして、シミュレーションしているに違いない。私たち兄妹は、サンタクロースが無事に家の中に入れるよう、クリスマスイヴにはカーテンを少しばかり明け、迷わないためにサンタクロースのための道をつくりました。

クリスマスプレゼントを届ける

( (c) Some rights reserved )

サンタクロースはきっと来てくれる。でもいつ来てくれるのだろう？私たち兄妹は眠い目を擦りながら、「ありがとう」を伝えるべく、サンタクロースが来るまでベッドで待ち続けました。迷子になっていないかな？不安に思いながらも私たち兄妹は睡魔に負け、眠りにつきました。

クリスマス当日のサプライズ

( (c) Some rights reserved )

朝起きてみると、枕元にプレゼントがありました。いつ届けに来てくれたのだろうか。きっと、私たち兄妹がいつ頃眠りにつくのかわかっていたのだろう。プレゼントを急いで開けてみると中身は欲しかったおもちゃではなく、当時の夢だったサッカー選手になることをサンタクロースは知っていたからなのか、かっこいいサッカーのスパイクシューズが入っていました。

予想外だったプレゼントだけに、いまでもその体験は忘れられません。いま欲しいものではなく、そのときの著者にとって必要となるプレゼントを考え、届けてくれたサンタクロース。きっと、著者の反応を遠くの世界から見守っていてくれたことだと思います。

まとめ

これはあくまでも著者の推測によるものですが、いま思えばサンタクロースは優れたユーザエクスペリエンス・デザイナーだったと考えています。

子供たち1人1人の意見に耳を傾ける（著者の実体験では直接だが、手紙などによる間接コミュニケーションも存在）
その子の特徴を的確に把握し、本当に必要とされるプレゼントを考える
子供たちへのプレゼントを準備する
子供たちにプレゼントを確実に届けるためのシナリオを練る
最善の方法でプレゼントを子供たちに届ける
クリスマス当日に子供たちの反応を見守る

これは、人間中心設計（Human Centered Design）ないしはUX（ユーザエクスペリエンス）デザインの実践とほぼ同類なのではないでしょうか？

( (c) Some rights reserved )

ユーザーインタビューからシナリオ設計、施策検討までを手掛けているサンタクロースは正に優れたユーザエクスペリエンス・デザイナーだと思っています。そして何よりも、子供たち（HCD / UXデザインの文脈ではユーザー）の笑顔と幸せを思うその熱意と優しさは、著者としても学ぶべきことが大変多いと考えています。UXデザイナーは皆、サンタクロースであるべきです。

相手はどのようなプレゼントを欲しているのか？どのようなプレゼントを届ければ喜ぶのか？どのように届ければ喜ぶのか？このプレゼントがもし、あなたが担当するプロダクトやサービスだったら？これもまた、サンタクロースからのプレゼント（？）なのかもしれません。

すべての子供たちへ…メリークリスマス。

なお、この文章は UX Tokyo Advent Calendar 2014 への寄稿記事です。

UX Lessons Learned from Santa Claus
UX Lessons Learned from Santa Claus — Medium

<a href="http://sprmario.hatenablog.jp/entry/2013/06/28/%E4%BA%BA%E9%96%93%E4%B8%AD%E5%BF%83%E8%A8%AD%E8%A8%88%E3%81%AE%E5%9F%BA%E7%A4%8E_" data-mce-href="http://sprmario.hatenablog.jp/entry/2013/06/28/%E4%BA%BA%E9%96%93%E4%B8%AD%E5%BF%83%E8%A8%AD%E8%A8%88%E3%81%AE%E5%9F%BA%E7%A4%8E_">人間中心設計の基礎 - UXploration</a>
人間中心設計の基礎 - UXploration

「誰のためのデザイン？」よりも「何のためのデザイン？」 - UXploration
「誰のためのデザイン？」よりも「何のためのデザイン？」 - UXploration

*1:6マスのストーリーボードは LeanUX の記事でもご紹介した 6up Sketches を採用しています。

ExperienceFellow - カスタマージャーニーマップの自動生成ツール

2014-12-19T14:22:26+09:00

ExperienceFellow（エクスペリエンスフェロー）というオンライン・ツールをご存知でしょうか？

THIS IS SERVICE DESIGN THINKING の著者 Marc Stickdorn氏と Jakob Schneider氏が共同で立ち上げたサービスで、一言で言えば「カスタマージャーニーマップの自動生成を可能にしてくれるツール」です（カスタマージャーニーマップとは？については「ユーザーエクスペリエンス・ジャーニーマップ」をご参考ください）。

ExperienceFellow とは？

ExperienceFellow が掲げているコンセプト「Research customer experience」が示す通り、被験者のエクスペリエンス（体験）を記録し、ジャーニーマップとして可視化するだけではなくチーム内でジャーニーマップを起点にコメントや洞察を登録・評価することができるサービスデザインのためのツールです。

ExperienceFellow の使い方

ExperienceFellow の使い方を説明します。

依頼者側がデスクトップのサイト上にプロジェクトを登録する。
被験者側がモバイル・アプリケーション上でプロジェクトに参加する。
被験者側がモバイル・アプリケーション上でエクスペリエンス（体験）を登録する。
依頼者側がデスクトップのサイト上でプロジェクトを終了する。
依頼者側のデスクトップのサイト上に反映された被験者の入力データを評価・考察する。
依頼者側が登録されたデータをジャーニーマップとして出力する。

ステップ1：依頼者側がデスクトップのサイト上にプロジェクトを登録する

先ず、依頼者側がプロジェクトと関係するメンバーをデスクトップのサイト上に登録します。

尚、当サービスが未だβ版ということもあり2014年12月度の利用料は無料となっています。今回は、僕のプライベート旅行で試験的に使用したデータを元に再現しています。

ステップ2：被験者側がモバイル・アプリケーション上でプロジェクトに参加する

プロジェクトが登録されると、今度は調査の対象となる被験者に情報を入力してもらうためのアクセスコードを QR コード形式で提供します。被験者は事前にインストールが必要な ExperienceFellow のモバイル・アプリケーション経由（2014.12.19時点では iOS のみ）で QR コードを読み取り、プロジェクトに参加します。

ExperienceFellow のアプリケーション内、被験者のモバイルデバイスにプロジェクトが登録されました。上記のキャプチャは既に使用済みのデータであるため幾つのデータが登録済みか、プロジェクトごとに表示されます。

ステップ3：被験者側がモバイル・アプリケーション上で体験を登録する。

プロジェクト登録後よりすぐに体験の入力を開始することができます。ここでは「NEW TOUCHPOINT」としていますが、「NEW EXPERIENCE」とラベルを編集することができ、被験者に取って自身の体験またはジャーニーの入力しやすさを考慮して依頼者側で選択できるようになっています。

タッチポイントごとの登録（＝NEW TOUCHPOINT）は被験者にとってサービス提供者側とのインタラクションを意識させなければいけないため、よりニュートラルな情報を得たいのであれば日記のような感覚で入力を促すことができる体験ごとの登録（＝NEW EXPERIENCE）が良いかもしれません。

入力画面は至ってシンプルです。体験した出来事を一行で記入し、5段階評価でその時の感情を選択します。

加えて、メモやその時の体験を記録するための写真やビデオなどのメディアファイルを添付することもできます。LOCATION（位置）機能はモバイル・アプリケーションのGPS機能がアクティベートされている場合のみ、位置情報が付与されます。

登録後には定期的に登録データを依頼者側のデスクトップサイト上に送るために同期する必要があります。

ステップ4：依頼者側がデスクトップのサイト上でプロジェクトを終了する。

プロジェクトの終了は依頼者側がデスクトップサイト上のダッシュボードで宣言することができます。

入力されたデータがダッシュボードに集約され、被験者ごとにデータを閲覧することができます。ダッシュボードでは総データ数、感情の平均スコア、簡易ジャーニーマップがサムネイルとして表示されます。

ステップ5：依頼者側のデスクトップのサイト上に反映された被験者の入力データを評価・考察する。

被験者ごとのデータを選択すると、入力したデータが時間軸で表示されます。

当画面では登録されたデータ（画像・ビデオ含む）を閲覧することができると共に、各データごとにタグやコメントを付与することができます。

例えばこの場合は感情の平均スコアがマイナスポイントとなっている時間帯は空港という場所に依存している可能性が高かったため、「Airport」というタグを付与しています。また、考えられる原因や改善点もあわせてコメントとして登録しています。

ステップ6：依頼者側が登録されたデータをジャーニーマップとして出力する。

以上の考察と評価は必要であれば行います。ExperienceFellow には常時 PDF へのエキスポート機能が搭載されており、被験者の入力データを基に可視化されたジャーニーマップを自動的に生成し、被験者ごとの出力やプロジェクトごとの出力が可能となっています。

まとめ

前述しましたが、ExperienceFellow は被験者のエクスペリエンス（体験）を記録し、ジャーニーマップとして可視化するだけではなくチーム内でジャーニーマップを起点にコメントや洞察を登録・評価することができるサービスデザインツールです。

なぜ、僕が ExperienceFellow に目を向けたのか？ExperienceFellow は以下の点で優れています。

時間的・物理的制限から開放される、リモート・エスノグラフィーが可能
ユーザー（被験者）の生データを直接ジャーニーマップに反映することが可能
ユーザーに負荷をかけず、コンテキストを破壊することなく日記感覚で入力を促すことが可能
リモート環境下でも複数のプロジェクトメンバー間のコラボレーションが可能

尚、今回はセルフ・エスノグラフィの要領で自身の旅行体験を軸に依頼者側・被験者側の当サービスにおける検証を行ってきましたが、改めて、ユーザーセントリックに普段から行っているサービスデザイン業務における調査の信憑性や妥当性を証明することの大切さを学びました。

最後に、2014年12月一杯までは利用が無料です。試験的に、依頼者側としての参加となりますが ExperienceFellow を体験してみたいという方がいらっしゃれば、ぜひ下記「通勤体験の改善」プロジェクトにお気軽にご参加ください。

モバイル・アプリケーションは下記よりダウンロードが可能です。前述しましたが、現時点では iOS のみの提供となっています。

ExperienceFellow

mohemian
ビジネス
無料

&lt;a href="http://sprmario.hatenablog.jp/entry/20110908/1315492018" data-mce-href="http://sprmario.hatenablog.jp/entry/20110908/1315492018"&gt; User Experience Journey Map - ユーザーエクスペリエンス・ジャーニーマップ - UXploration&lt;/a&gt;
User Experience Journey Map - ユーザーエクスペリエンス・ジャーニーマップ - UXploration

&lt;a href="http://sprmario.hatenablog.jp/entry/2013/08/05/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E2%80%95%E7%84%A1%E5%BD%A2%E3%82%92%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%99%E3%82%8B" data-mce-href="http://sprmario.hatenablog.jp/entry/2013/08/05/%E3%82%B5%E3%83%BC%E3%83%93%E3%82%B9%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E2%80%95%E7%84%A1%E5%BD%A2%E3%82%92%E3%83%87%E3%82%B6%E3%82%A4%E3%83%B3%E3%81%99%E3%82%8B"&gt;サービスデザイン―無形をデザインする - UXploration&lt;/a&gt;
サービスデザイン―無形をデザインする - UXploration

Lean Startup Update - 2015年1月16日開催

2014-12-18T14:30:26+09:00

2015年1月16日（金）に開催される「Lean Startup Update」に僭越ながら登壇させていただくことになりました。

日時：2015年1月16日（金）19:00〜22:00
定員：100人
参加費：無料
会場：日本マイクロソフト株式会社 31F セミナールーム A
公式ハッシュタグ：#LeanStartup
URL：https://atnd.org/events/60368

プログラム：

Lean Startup（河合太郎）
リーンスタートアップ導入の現場（黒田樹）
Lean UX Quest in Tokyo（坂田一倫）
Lean Analytics（角征典）
絶対に行き詰まるリーンスタートアップの始め方（冨山香織）
Lean Customer Development – 「この製品が欲しいですか」と聞いてはいけない（馬田隆明）

2011年に発売された書籍「The Lean Startup」以降、著者である Eric Ries氏がシリーズエディターを務める THE LEAN SERIES より「Running Lean」「Lean UX」「Lean Analytics」「UX for Lean Startups」「Lean Customer Development」「Lean Enterprise」「Lean Branding」など数々の関連書籍が刊行されるようになりました。

米国では毎年年末に The Lean Startup Conference が Eric Ries氏主催のもとシリコンバレーにて5日間に渡り開催され、企業 / NPO / 自治体問わず多くのアントレプレナーをアメリカ全土から収集し THE LEAN SERIS の方法論に関する最新の知見の披露、成功例や失敗談の意見交換そして議論が行われ、リーンスタートアップの方法論は毎年進歩を続けています。

"We consider startups to include any new product or service facing conditions of extreme uncertainty–which means that our customers include not just two people in a garage in Silicon Valley, but also established companies in all sectors, non-profit organizations, government agencies, and educators." ー The Lean Startup Conference

僕が監訳を務めさせていただいた「Lean UX」に至っては、ニューヨークを起点に Lean UX NYC が The Lean Startup Conference 同様に毎年開催され、独自の議論がなされているほどです。過去に参加した当イベントの記録は「Agile UX New York City 2012（※ Lean UX NYCの前身）」をご覧ください。

そして今回、この THE LEAN SERIES の監訳や翻訳に関わった方々やリーンスタートアップを推進している方々で集まり、日本でもリーンスタートアップ・ムーブメントをアップデートする試みを来年より開始する運びとなりました。

Lean UX からは Lean UX Quest in Tokyo と題し、2014年1月22日の刊行以降の活動と、Lean UX Circle を始めとする団体活動のアップデートを予定しています。

<a href="https://atnd.org/events/60368" data-mce-href="https://atnd.org/events/60368">Lean Startup Update!! 2015 (リーンスタートアップをアップデートする会) : ATND</a>
募集は atnd より行ってますので、ご興味ある方はぜひご参加ください。会場でお会いしましょう。

<a href="http://sprmario.hatenablog.jp/entry/20120227/1330343863" data-mce-href="http://sprmario.hatenablog.jp/entry/20120227/1330343863"> Agile UX New York City 2012 - The Premier Agile & LeanUX Conference - UXploration</a>
Agile UX New York City 2012 - The Premier Agile & LeanUX Conference - UXploration

<a href="http://sprmario.hatenablog.jp/entry/2014/03/01/Designing_Culture_with_Lean_UX%E3%80%9C%E3%83%AB%E3%83%BC%E3%83%AB%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E6%96%87%E5%8C%96%E3%82%92%E3%81%A4%E3%81%8F%E3%82%8B%E3%80%9C" data-mce-href="http://sprmario.hatenablog.jp/entry/2014/03/01/Designing_Culture_with_Lean_UX%E3%80%9C%E3%83%AB%E3%83%BC%E3%83%AB%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F%E6%96%87%E5%8C%96%E3%82%92%E3%81%A4%E3%81%8F%E3%82%8B%E3%80%9C">Designing Culture with Lean UX〜ルールではなく文化をつくる〜 - UXploration</a>
Designing Culture with Lean UX〜ルールではなく文化をつくる〜 - UXploration

エンタープライズ情報アーキテクチャ

2014-07-12T12:29:42+09:00

EIA（エンタープライズ情報アーキテクチャ）とは「企業・組織（エンタープライズ）の全体俯瞰によるウェブの最適化を行うIA（情報アーキテクチャ）」です。

個々のサイトの情報設計ではなく、企業や組織が保有するウェブサイトや CMS、イントラネットなどを含めたシステムをまとめた全体像を取り扱うことが特徴です。

((c) EIA as Brand Strategy)

また、企業や組織全体のウェブに関わる業務や情報資産を俯瞰することで、個別部署ごとではなく、企業全体の「全体最適化」を行うことを目的としています。EIA が取り扱う問題は、主にウェブにおけるガバナンスや企業・組織が保有する情報資産の有効活用（共通情報の共有、効率的運用方針の策定、重複投資排除によるコスト削減）です。

EIA と「伝わるしくみ」

ぼくが所属するコンセントは「伝わるしくみ」をデザインする会社です。

最も重要なのは「伝わること」。
その単純で絶対的な目的のためには、同じく単純な3つのステップが必要です。

ー 伝わるしくみとは：伝える手法の探求から、伝わるためのしくみの共有へ | ラボ | 株式会社コンセント

コンセントが考える EIA は、企業や組織が保有する情報資産を如何にしてユーザーに届けるか/伝えるか、正にその橋渡しとなる「しくみ」を設計・構築します。

この場合のユーザーは「エンドユーザー」のみならず、「社内ユーザー」も含まれます。ウェブサイトを運用する企業や組織内のコミュニケーションにおいて部門ごとのサイトが整っていなければ、統一したブランドイメージを保つことはできません。加えて部署ごとのサイトの回遊がコントロールされていなければブランドへの信頼が下がってしまいます。そのためには社内ユーザー間のコミュニケーションデザインも視野に含めなければなりません。

((c) 伝わるしくみとは：伝える手法の探求から、伝わるためのしくみの共有へ)

社内そして社外における「伝わるしくみ」を考え、共有することで全体最適化の推進によってブランド価値が向上するだけではなく重複投資が回避され、新たな機会創出へと繋がります。また、同時にエンドユーザーのストレスが軽減され、情報取得の効率が向上することで優れたユーザーエクスペリエンスを実現することができます。EIA は、情報に関わるすべての人々の「伝わるしくみ」を考えていくための方法論なのです。

(EIA は情報に関わるすべての人々の「伝わるしくみ」を考えていくための方法論)

まとめ

当ブログの過去の記事でも言及しましたが、実行性の高いプランニングと実行にうつすための企業や組織内での立ち振る舞い方。このふたつがなされない限り、サービスデザインをはじめとする当初の構想は絵に描いた餅に終始してしまいます。

EIA はサービスそのものを構造的に捉え、抽象度の高い戦略または構想を情報アーキテクチャの観点からサービスのモデル化を推進することで、ウェブのみならずサービスそのものに具体性を与えることが可能になります。

コンセントではどのように EIA プロジェクトを推進しているのか。詳しくはコンセントの広報用ウェブマガジン「サストコ」の EIA 特集をご覧ください。

実例で学ぶ「伝わる」デザイン

作者: 川崎　紀弘,アレフ・ゼロ
出版社/メーカー: グラフィック社
発売日: 2011/04/08
メディア: 単行本
クリック: 1回
この商品を含むブログを見る

エンタープライズ・アーキテクチャ

作者: IBMビジネスコンサルティングサービスIT戦略グループ
出版社/メーカー: 日経BP社
発売日: 2004/01/08
メディア: 単行本
購入: 1人クリック: 2回
この商品を含むブログ (2件) を見る

Design dot BEENOS 始動

2014-07-09T19:20:28+09:00

BEENOS という「Startup Studio」をテーマにした、日本をはじめ、北米・インド・トルコなど7カ国80社以上に投資し、ウェブにおけるエンジニアリング・デザイン・マーケティング・マネジメント・データ解析に関する支援や育成プログラムを実施している会社のデザインチームと共同で、新企画をはじめました。

その名も「Design dot BEENOS」です。主催者のひとりである山本郁也氏は言います。

若いデザイナーが堂々と胸を張って生きることができるWeb業界をつくりたい、Design dot BEENOSはそんな気持ちでやっています。もう少し言うと、デザイナーの言論空間を確立したい、デザイナーのディスコースを強化したいということです。
— Fumiya Yamamoto (@fumya) 2014, 6月 28

特にスタートアップ業界に至ってはデザイナーの人口が少なく、加えて肩身の狭い思いをし、本来であればビジネスと密接に関わるが故にデザイナーとしての価値の発揮に最も適している環境にも関わらず、多くの悩みや課題を抱えているのではないかと思うことがあります。

海を渡れば、そこは歴史上で最も多くのデザイナー達が意味あるインパクトを生むためにスタートアップへと転身し、Etsy や Pinterest、Square や Airbnb といった今話題のスタートアップの創業者ないしは共同創業者として活躍しています。

彼らのように、デザイナーはセルフプロデュース力が高く存在感を示せるものの、特に日本においては社会的にまだ本当の価値が見出されていないのではないでしょうか？日本のデザイナーは世界的にみてもレベルは決して劣っていないのですが、業務範囲が制限されることでその可能性が引き出せずにいます。

結果としてデザイナーとしての労働対価に見合わない仕事のみを担当するようになってしまい、デザイナーないしはデザインそのものの存在感が薄れてしまいます。

デザインコミュニティの形成と、その先の未来をより良くしたいという BEENOS のビジョンに共感し、主催者のひとりとして定期的にウェブ業界に身を置くデザイナーの方をゲストとしてお招きし、デザイナーの存在意義やその価値について再確認する場（イベント）を開催していく予定です。やがてはウェブ業界に留まらず、様々なひとの「Design dot (You)」を引き出せればと考えています。

「UX Japan Forum 2014」を開催します

2014-07-05T14:09:36+09:00

全国各地の UX コミュニティーが集結する真夏の HCD/UXD イベント「UX Japan Forum 2014」が7月20日（日）に開催されます。

モノやサービス、情報が溢れかえっている時代において、あらゆる業種や業界で HCD/UXD の重要性が語られています。個人の経験や一企業の取り組みだけでは、なかなか知見を積み重ねることは難しく、HCD/UXD を社内ないしは社会で推進する上で様々な課題に直面することが多々あります。

同じような取り組みが実際多くの企業または人たちの間で行われていると思います。ただし問題は、似たようなことが行われていたとしても必ずしも体系的ではないために途中で挫折してしまったり、実践者の我流で行われていたために、他の人には理解できずに社内で広がらなくなっていたと思います。

UX Japan Forum 2014 では、そんな現在の日本国内における HCD/UXD のこれまでとこれからについて、暗黙知を形式知化にして共有化を進めるために参加者のみなさんと語り、追求していきたいと、日本の各地で HCD/UXD を学び、推進している有志が集まり企画しました。第1回となる今回は、「栄 UX」が運営主体となり、愛知県は名古屋市で開催されます。

ぼくもその内の1人として、東京を中心に活動しているインターネット・メディア企業でユーザエクスペリエンス設計業務を担当する人が集うコミュニティー「Shibuya UX」、そして次代のより良いデジタルインフラ構築に貢献する知のネットワークを構築し活性化することをミッションに掲げ、活動している「UX Tokyo」の主宰者として関わらせていただいています。

当日には「ユーザエクスペリエンス・デザインの破壊と再生」と題したセッションを担当します。同じく UX Tokyo の山本郁也氏と共に Web 業界における HCD/UXD の既成概念を打ち破り、本当のユーザエクスペリエンスを考える場合に今後求められるであろう視点やスキル、マインドセットについてサービスデザイン事例を基に参加者のみなさんと一緒に考えていきたいと思います。

ほかにも HCD-Net 理事／千葉工大の山崎教授をお招きし、「UX思考」をテーマとした話題提供をいただきます。イベント当日では全国各地から集まる UX コミュニティーの代表者や参加者のみなさんとの交流を通じて日本全土における HCD/UXD への共通理解を構築していければと考えています。

日時：2014年7月20日（日）
会場：トライデントコンピュータ専門学校（愛知県名古屋市）
参加枠：100名
参加費：3,000円（当日支払い）
主催：UX Japan Forum 2014 運営委員会
後援：NPO法人人間中心設計推進機構（HCD-Net）
協賛：株式会社アクアリング、学校法人河合塾学園トライデントコンピュータ専門学校、株式会社イークリエイト

ぜひ、奮ってご参加ください。

Code for Namie ー「考える」と「つくる」

2014-06-29T23:29:51+09:00

東日本大震災による東京電力福島第一原発力発電所事故の影響により今尚全町避難が続く福島県浪江町。今年度に全町民に対してタブレット端末を配布する事業を予定している浪江町の支援の一環として開催された、浪江町住民のタブレット活用を考えるハッカソン「Code for Namie（浪江町 ✕ Code for Japan）」が今週末に開催されました。

((c) Code for Namie)

ふるさとである浪江町を離れ、物理的にバラバラになってしまった地域の絆を再生するために、タブレット端末をどう使えるか。情報格差が著しい浪江町の町民に対してどのような情報や機能を提供すべきなのか。

Code for Namie ではこれまで僕が携わってきたハッカソンとは異なり、計6回のアイディアソンを開催し、のべ420名が参加し、創りだされた770ものアイディアを16種類に分類し、内７つのアイディアを今週末に開催されたハッカソンで形にしていきました。通常はアイディアソン / ハッカソンそれぞれ1回づつ開催されることが多いため、驚きました。

アイデア説明＿140626 from Code for Japan

その昔、アインシュタインは言いました。

"If I had only one hour to save the world, I would spend fifty-five minutes defining the problem, and only five minutes finding the solution."

（もし、地球が滅びそうな状況になって助かる方法を考えるのに1時間あるとしたら、私は最初の55分で問題を理解し、問題がどういったものであるかを適切に定義することに費やすだろう。そして残りの5分で、その答えを考えるだろう。）

今回のハッカソンも、その通りだと言えます。

それだけではありません。自治体が発行している浪江町の住民意識調査の報告書や避難状況をはじめとする、タブレット事業の導入に向けた江町の現状と課題を、浪江町役場の方々のご協力により事前インプットとして参加者に提供されました。

((c) Code for Namie)

また、どんな人が、どんな生活を送っているのか？被災前と比較してどのように生活が変わったのか？どのようなことに困っているのか？こういった事柄に具体的イメージを持つために仮想ユーザーであるペルソナが、実データを基に成形されています。

((c) Code for Namie)

浪江町タブレット利用者像 from Code for Japan

そして、浪江町をはじめとるす福島の復興に関する話題が会ごとに提供され、繰り返し開催されるアイディアソンのアウトプットの質の向上に寄与しています。7つに絞られたアイディアは、ハッカソン最終日に実際に町民の方々の前でタブレット端末内で動くアプリケーションとしてデモンストレーションを行い、最も票を集めたアイディアはその後、民間企業と連携し今年度中に製品化され、配布されます。ぼくはメンターのひとりとして、アイディアの具現化を支援させていただきました。

((c) Code for Namie)

利用者との交流

Code for Namie では実際にアプリケーションを利用する立場となる町民の方々による審査が設けられたことが素晴らしいと思いました。その後、デモンストレーションを終えた各チームのテーブルを周り、アプリケーションをタッチ＆トライして実際の利用イメージを持っていただくような時間も設けられていましたが、アプリケーションの良し悪しを最終評価するのは利用者なのです。

((c) Code for Namie)

被災者が抱える課題の解決に向けたアイディアが優れていると自身で思っていても、答えは利用者のみが知っています。利用者との交流はもちろん、フィードバックがなければ自己満足で終わってしまいます。そのような事態を回避するためにも、全国各地で開催されているすべてのアイディアソン / ハッカソンはつくる側の人間と、つかう側の人間の距離をもっと縮めていくべきです。

何のためのアイディアソン / ハッカソンなのか？いまいちど問いなおす必要があるのではないでしょうか。

伝える＆伝わる仕組みづくり

イベント最後の総括でもお話させていただきましたが、ぼくは参加者のみなさんと、その素晴らしいアイディア（アプリケーション）の魅力を確実に利用者に伝えるための仕組みづくりを未熟ながらも支援させていただきました。

((c) Code for Namie)

デモンストレーションでは町民の方々にそのアプリケーションの魅力をちゃんと伝えることができましたでしょうか？また、ちゃんと伝わっていましたでしょうか？実装した機能に対してではなく、そのものの価値について共感していただけたでしょうか？

いくらアイディアや具現化されたアプリケーションが優れていても、その魅力が利用者に伝わっていなければ全く意味がありません。

どのように伝えるべきか？どうしたら伝わるのか？伝わる仕組みを考えることは決して簡単なことではありませんが、日常のコミュニケーションから意識可能な内容です。

まとめ

アイディアソンでアイディアを生み出し、ハッカソンで創る。すっかりと定着してしまったこの構図について疑問が残ります。開発プロセスを単純にまとめると「考える」と「つくる」に別けることができますが、昨今のアジャイル開発や、当ブログでも何度も解説している LeanUX などの浸透に伴い、「考える」と「つくる」距離は除々に縮まってきています。双方の境目がなくなってきている、と言い換えることができるかもしれません。前述のアインシュタインの言葉のとおり、「考える」ためには「つくる」必要があり、「つくる」ためには「考える」必要があります。

((c) Peter Morville)

つまり、現代のアイディアソン / ハッカソンは同一の作業内で完結させるべきではないでしょうか。時間的制約はあるものの、「考える」を専門とする参加者と「つくる」を専門とする参加者を別けることで、創りだされたアイディアの裏にある背景が引き継がれにくいといった事態に陥りやすくなります。

また、今回のハッカソンでも事前に選定されたアイディアそのものがソリューションを限定してしまうような示唆が含まれているものがありました。アイディアソン / ハッカソンにも LeanUX マインドを浸透させるべく、引き続きいち参加者としてもハッカソンイベントに足を運びたいと思います。

最後に、こんな僕をメンターとしてお招きいただいた運営スタッフのみなさま、ありがとうございました！

#UXTokyo Jam 2014 -Breaking New Ground of UX in Tokyo-

2014-06-27T11:58:28+09:00

発足から約3年間、主宰者のひとりとして携わってきた UX Tokyo で初となる大規模イベント「UX Tokyo Jam 2014」を開催致します。「次代のより良いデジタルインフラ構築に貢献する知のネットワークを構築・活性化します」というメッセージと共に、Facebook グループを軸とした勉強会や読書会などを定期的に開催してきました。

IT業界の流れはとてつもなく早いもので、当時は30～40名規模の団体でしたがいまとなっては約1,400名と驚くようなスピードで「ユーザーエクスペリエンス」に関心のある方々が集まるようになりました。この「ユーザーエクスペリエンス（＝UX）」という言葉と共に成長してきた UX Tokyo ですが、UX 戦略という言葉にも代表されるように「ユーザーエクスペリエンス（＝UX）」は新しいステージを迎えようとしています。だからこそ今、「ユーザーエクスペリエンス（＝UX）」を捉え直す必要があるのではないでしょうか。

そのための対話の場を、「ユーザーエクスペリエンス（＝UX）」と共に成長・拡大してきた UX Tokyo が用意させていただきました。次代のより良いデジタルインフラ構築のために、私たちで UX の新しい土台をつくりましょう。当イベントのテーマである「Breaking New Ground of UX in Tokyo」にはそのような意味を込めました。「ユーザーエクスペリエンス（＝UX）」という言葉が、ただ消費され、使い古されるだけの言葉にならないように。

新しい「ユーザーエクスペリエンス（＝UX）」の幕開けを、日本から。

UX Tokyo Jam 2014
-Breaking New Ground of UX in Tokyo-

日程：7月26日（土）
時間：12:45～21:00
会場：グリー株式会社 9F（東京都港区六本木6-10-1 六本木ヒルズ森タワー）
主催：UX Tokyo
後援：グリー株式会社
スペシャルサポーター：OFFICE DE YASAI
参加チケット：2,000円

12:45～13:15 受付
13:20～13:30 挨拶
13:30～14:15 オープニングキーノート
14:15～18:00 パラレルセッション
18:15～19:00 クロージングキーノート
19:00～21:00 懇親会

オープニングキーノート
前田俊幸（ユーザーリサーチャー / UX Tokyo 主宰）

セッションA-1：Empathy in UX Design
村越悟（グリー株式会社 UXデザイナー）
水野太（UXデザイナー / インフォメーションアーキテクト）
モデレーター：坂田一倫（株式会社コンセントユーザーエクスペリエンスアーキテクト）

セッションB-1：UXデザインのためのマテリアリズム
江口晋太朗（編集者 / ジャーナリスト）
山本郁也（BEENOS 戦略ディレクター）

セッションA-2：Experience Design Out of Screen:これからのエクスペリンスデザイナーの生きる道
児玉哲彦（株式会社アトモスデザイン代表 / デザイナー）

セッションB-2：UX StudyとしてのFeasibility Study
新明智（株式会社ココナラ取締役）

セッションA-3：UXから「生きたUX」へー論から「実践UX」へSHIFTしよう
大隈広郷（デザイン思考研究所☆FUTURES PLACE 代表）

セッションB-3：UX戦略を考えるための本質的ユーザー理解
井登友一（株式会社インフォバーン執行役員京都支社長）

クロージングキーノート
長谷川敦士（株式会社コンセント代表 / インフォメーションアーキテクト）

人間中心設計（HCD）におけるマネジメント

2014-06-02T18:49:31+09:00

HCD（UXD）の価値は、実践を通じて証明しなければならないと思っています。そのためには、戦略など上位にある構想（＝無形）を見える化（＝有形）し、具体性を与えることで実践に直結するように心掛ける必要があります。

現状課題（＝As-Is）からビジョン創造（＝To-Be）への展開方法や発想方法についてはこれまでの HCD（UXD）の文脈で多く語られてきました。カスタマージャーニーマップをはじめとするコラボレーティブデザインなど、周囲のステークホルダーをも巻き込んだ共創活動が除々に活発化していくも、意思決定後の計画を他者に任せるも文脈が全く共有されていなかったり、実行性を考慮しない故に当初の構想とはかけ離れたアウトプットになってしまう事態に陥りがちです。

((c) pennstatenews via Compfight cc)

それだけではもちろん価値創出には繋がりませんし、自己満足状態になってしまっては意味がありません。いくらアイディアが素晴らしくても、エグゼキューション（実行）されなければそのアイディアも無価値に終わってしまいます。

はじめに

先日参加した HCD フォーラム内のチュートリアルで、ソシオメディアの篠原さんが担当されたセッション「HCD におけるマネジメント」はその名の通り、HCD（UXD）の組織化を広義／狭義におけるマネジメント観点から先の課題解決に繋がるヒントを多くご紹介いただきました。

イノベーションを導く手法として、ユーザエクスペリエンス・デザイン（UXD）やデザイン思考などに注目が集まっています。しかし、これらの知見やスキルの習得だけでは、組織の目的達成までには至りません。専門性のマスターに加え、各種手法をメソッドとして企業全体やプロジェクトの中に組織化・制度化（Institutionalization）すること、推進のためのリーダーシップ開発や人材育成を行うこと、一連の活動をメトリクスとして管理・運用することなど、「マネジメント」の諸要素こそが重要となります。本チュートリアルでは、「HCDにおけるマネジメント」を遂行するための諸条件とその具体的な実践方法について解説します。

ー HCD-Net | HCD-Netフォーラム2014 チュートリアル

セッションの冒頭では HCD（UXD）が求められている背景として競争化・グローバル化における経営戦略的観点から1960年代まで遡り、製品を基軸とした戦略的製造体系から体験に重きを置いたエクスペリエンス戦略ありきの製造体系への以降をご紹介いただきました。当ブログでも何度か言及しているコトからモノへのデザイン、製品からサービスへのシフトによって、HCD（UXD）への重要性が社会的に除々に認識されはじめています。スマートグリッド構想やスマートハウスなど、日常生活におけるインフラのスマート化が発展し、特定の分野だけでは完結しない、分野を横断したユーザー起点のサービスが提供されるようになりました。

((c) T.Shinohara)

理解を示す一方で、経営戦略的観点からの HCD（UXD）のマネジメント体系が組織内に確立されていなれば冒頭の普及活動は一向に進展しません。HCD（UXD）におけるマネジメントは

「プロジェクト」における HCD のマネジメント（＝プロジェクト・マネジメント）
「企業経営」における HCD のマネジメント（＝経営・マネジメント）

の2つに分類することができると篠原さんは言います。

プロジェクト・マネジメント：HCD（UXD）の推進組織・チーム・諸活動を管理・運営・推進すること
経営・マネジメント：HCD（UXD）の価値を理解して、HCD（UXD）を経営・組織に導入・定着させること

加えて、組織のヒエラルキー（例：経営層、事業部長、部門長など）と専門用語群のヒエラルキー（例：思想、メソッド、手法など）を軸に組織内に HCD（UXD）を普及させるためのフレームワークの枠組みを紹介していただきました。

経営・マネジメント
HCD 基礎力
HCD 活用力
プロジェクトマネジメント

当ブログでは「HCD 基礎力」と「HCD 活用力」に触れていきたいと思います。

HCD 基礎力

ISO で定義されている「人間中心設計（HCD）」は上記で言う思想に該当します。次に各種手法（ツール）の習得です。ペルソナやシナリオなどの代表的なツールに加え、世の中には実に様々な HCD（UXD）を実践する手法が存在します。

((c) Human-Centered Design Toolkit | IDEO)

忘れてはならないのは、手法はあくまでも点に過ぎないということです。HCD（UXD）の基礎力を司る、最も重要な要素は上記にもリストアップされているような各種手法のメソッド化です。

メソッド化とは、属人性が排除され、ゴールまでの手順が明確になっている道筋とも言い換えることができます。手法を学び、メソッドを学ぶ。またはメソッドを学び、手法を学ぶ。鶏卵論のようにも思われるかもしれませんが、ルールがわからないと最適なフォーメーションが組めないように、アジャイルやリーン生産方式など既存のメソッドを理解することで各種 HCD（UXD）のツールを臨機応変に繋げることができます。結果として組織内の文脈を壊さずに HCD（UXD）のマインドセットや取り組みを推進できるのではないでしょうか。

メソッド化されていないと人に伝わらないことも事実です。いくら対象の手法が目新しく、優れていたとしてもメソッド化されていなければ形式知化されずに暗黙知でしか成り立たない場合が増えてきていしまいます。それでは、組織全体への普及は困難です。

HCD 活用力

組織全体への普及を目的とした場合には多くのステークホルダーが関係してきます。そのためには参加している、または関係しているすべてのステークホルダーを対象とした課題抽出や未来創造ワークショップの実施が必要不可欠になってきます。そのために求められるスキルとして、「ファシリテーション」が挙げられていました。

((c) chrisbb@prodigy.net via Compfight cc)

ワークに限らず、プロジェクトでも積極的にファシリテーションを遂行すべきです。当ブログ記事「デザイナーとエンジニアのこれまでとこれから：D/E問題を考える」でも言及しましたが、特にデザイナーに至っては「デザインをする立場」から「デザインを導く立場へ」とマインドを切り替えてファシリテーションすべきだと考えています。

HCD（UXD）の本質は問題解決です。昨今よく耳にするデザインシンキングも元を正せば問題解決型のロジカルシンキングのエッセンスを取り入れています。つまり、HCD（UXD）には必ず目的があり、デザインすることそのものに意味を見出すのではなく、意味があってこその HCD（UXD）であることを理解する必要があります。ロジカルシンキングは、HCD（UXD）の手法やメソッドを論理的に活用し、前段となる理論を構築する際に必要となる、最低限の基礎スキルだと僕は考えます。

時代は「デザイン・シンキング（デザイン思考）」がポピュラーとなっているけれど、結局は「ロジカル・シンキング（論理・論点思考）」なしに成立はしないと思う。
— Mario K. Sakata (@mariosakata) 2012, 5月 23

最後に

デザインをする立場からデザインを導く立場として、我々は時としてプロジェクトマネージャーとして立ち振る舞わなければなりません。プロジェクトチームの編成はもちろん、構想から設計、設計から実装、実装から評価、そして運用までの一連のプロセスに自身の身を置き、プロジェクトを完遂することではじめて、HCD（UXD）の重要性を実証できます。

((c) The Rise of the Planet Apes)

結果としてリーダーシップが養われ、経営戦略的観点から HCD（UXD）を導入するために必要な計画や人材配置、費用対効果にまでコミットする機会が増えるようになり、ユーザー中心のサービス開発が企業内文化として根付いている状態が創り出せるのだと僕は思います。

UXploration

バリュー・プロポジションを言語化してみよう！

そもそもなぜ具現化する必要があるのか？

どのように言語化すべきか？

つくったあとはどうするべきか？

Q思考と UX デザインーー正しい答えよりも正しい問いを

人はなぜ答えを求めたがるのか？

正しい問いは何をもたらすのか？

正しくモノをつくるよりも、正しいモノをつくる

関連エントリー：

UX戦略とはなにか？

背景となる思想

UX戦略を理解するためのフレームワーク

UX戦略の意味的変化

まとめ：UX 戦略とはなにか？

関連エントリー：

ビジネスや社会に貢献する UX デザインの価値とは？

人間中心設計 / UX デザインの価値定義

A: 成果として組織やステークホルダーにもたらされる効果

B: 成果として顧客やユーザーにもたらされる効果

C: 過程として顧客やユーザーにもたらされる効果

D: 過程として組織やステークホルダーにもたらされる効果

まとめ

関連エントリー：

二輪駆動の人間中心設計

人間中心設計プロセスの「2つの誤解」

誤解その1：最上段の工程を開発地点として進めなければならない

誤解その2：人間中心設計のプロセスはリニアに進めなければならない

二輪駆動の人間中心設計とは？

関連エントリー：

UX デザインに求められる「3つの目」

サービスデザインの骨格と視点

はじめに

これまでのUXデザインとは何が異なるのか？

デザイン対象のスケール変動

ユーザー接点の拡張

モノシステムからエコシステムへのパラダイムシフトを見極める

関連資料：

2015年アーカイヴ

登壇イベント

インタビュー／掲載記事

UX デザイナーを目指している君へ

はじめに

すべてのはじまり

変化の訪れ

伝えたいこと

UX デザイナーになるために必要な3つのこと

関連記事：

サイレント・ニーズを探る5つのステップ ー #UXJapan Forum 2015

はじめに

なぜ、ユーザーの「声」なき「声」なのか？

サイレント・ニーズを探る5つのステップ

1. Observing（観察をする）

2. Analyzing（初期仮設分析）

3. Interviewing（インタビュー）

4. Immersing Empathy（共感に浸る）

5. Sharing Insights（洞察の共有）

まとめ

関連記事：

Empathy：いま、デザインに求めらていれるエンパシーとは？

Empathy とは？

なぜ、Empathy なのか？

関連資料：

事業計画・推進に求められる2つのプロペラ〜Balanced Team & Product Stewardship〜

「思い込み」でサービスをつくることは必ずしも悪いわけではない

LEAN UX Japan Conference 2015〜LEAN UXが拓く未来〜

開催背景と想い

継続する努力

最後に

関連記事：

リーンスタートアップのリフレーミング：Frame-Build-Measure-Learn（構成-構築-計測-学習）

まえがき

はじめに

Frame（構成）

課題の構成

実験の構成

Build（構築）

1. 実験方法を考える

2. 実験の場をつくる

3. 実験を行う

サイレント・ニーズを探る5つのステップー #UXJapan Forum 2015