UXploration

Explore the art of UX persuasion

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

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

f:id:separate-ks:20150312125005j:plain

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

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

f:id:separate-ks:20150312125110j:plain

日程: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回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99%は失敗する状況です。ではその状況であきらめずに2回挑戦した時の確率はどうなるか。2回とも失敗する確率は99%×99%=98.01%です。つまり、成功確率は約2%(1.99%)となり、1%成功確率が上がります。3回、4回、5回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が1%の出来事は459回繰り返せば、失敗する可能性が1%」になるんです。

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

 

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

最後に

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

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

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

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

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

ぜひ、ご参加ください。

関連記事: 

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

まえがき

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

日本でもソフトウェア業界をはじめ、関心が集まっている 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回目の挑戦での成功確率が1パーセント」という状況があったとします。つまり99%は失敗する状況です。ではその状況であきらめずに2回挑戦した時の確率はどうなるか。2回とも失敗する確率は99%×99%=98.01%です。つまり、成功確率は約2%(1.99%)となり、1%成功確率が上がります。3回、4回、5回と続ければ4.9%。100回やれば63%。そして、459回やれば、最初と数字が逆になります。「一度やってうまくいく可能性が1%の出来事は459回繰り返せば、失敗する可能性が1%」になるんです。

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

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

f:id:separate-ks:20150227173049p:plain

はじめに

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

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

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

f:id:separate-ks:20150227173453p:plain

((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(構築)

仮説を軸とした学びや発見を得るためには、どのような実験を実行すれば対象の仮説が実証されるのかを先ずは考える…と前述しましたが、構築の対象となるプロダクトやサービスの目的は学習や発見の達成のためとして位置付けることができると思います。そのためには以下の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導入設計論ー公用語としての人間中心デザイン

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

f:id:separate-ks:20150301181620p:plain

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

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

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

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

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

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

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

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

f:id:separate-ks:20150301184115j:plain

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

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

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

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

That is why you fail.

(それが失敗する理由だ。)

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

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

f:id:separate-ks:20150301184015j:plain

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

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

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つのステージについ目が奪われがちです。

 

f:id:separate-ks:20150301182829j:plain

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

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

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

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

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

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

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

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

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

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

f:id:separate-ks:20150301183216j:plain

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

まとめ

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

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

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

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

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

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

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

f:id:separate-ks:20150301183757j:plain

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

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

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

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

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

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

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

関連記事:

This work is licensed under a Creative Commons Attribution 4.0 International License.
Others, like quotes and images belong to its original authors.