日時：2014/02/28 (金) 19:30 - 21:30
URL：
http://devlove.doorkeeper.jp/events/8856
場所：マンサード代官山 1F Theatre CYBIRD
講師：坂田 一倫氏
概要：Lean UX の現場。アジャイルはUXの夢を見るか？
LeanUXで扱うのは、デザイナーと開発者が上手くチームとして働けるための原則やマインドセットです。それは、アジャイル開発とUXデザインが組み合うための最初の一歩と言えるでしょう。果して、LeanUXが現場にもたらすものは何か。皆さんで考えてみましょう。
場所は、超奇麗なシアター。CYBIRDさんにお邪魔しました。
講演スライドもいち早く公開されています。早い！！
Designing Culture with Lean UX
-ルールではなく文化をつくる-
感想
Lean UXの書籍を早速買って読みたくなってしまった。UXのことだと思っていたが、それだけではなく、文化の醸成のことが書かれているという。ルールではなく、文化を育てるのだと。自分の周りを振り返ってみると、顧客に真の価値を提供するよりも、単なる成果物を生成するということに価値観が置かれている。なのでスゴく耳が痛い。頭では分かるのだが、周りの価値観に流され、自分もその中の１人となってしまっている。実際に行動に移せていないのは、分かっていないのと同じこと。アイデアを発想することに意味はなく実現することに価値があるという、本日の講演に出てきた話題と同じだ。
ドラッカーのMBO(目的管理)の話が出てきた。先月読んだ「
目標管理の教科書」にもでてきたことに通じるものがある。ただ、MBOの後ろにself-controlが付き、自己統制が必要である。つまりアジャイルで言うところの自己組織化で、内発的動機付けを重視するということだ。組織・チームで成果を出すためには、変化の激しい世の中の中では、トップダウンによる官僚的なプロセス管理では追いつくことができない。そのために、市場の状況に合わせて、フィードバックループを回し、学習から成果を出していく仕組みと、それと同時に、顧客に一番近い現場で意思決定を行えるようにする必要がある。これは、ドラッカーの言う21世紀のプロフェッショナルの働き方だろう。今週読んだ、「
アグリゲーター」にも同じことが書かれていた。
「目標管理の教科書」に関しては過去にこんなの書きました。
http://araratakeshi.blogspot.jp/2014/01/blog-post_3703.html
また、文化の醸成のために、可視化を至る所で行い、透明性を維持するというのは、まさしくそう思った。
ホワイトボードや廊下でも構わないので、各KPIや数値目標などを表示しておくことで、何か安心感や応援したくなる気持ちを醸成させる。これが組織の壁を打破するため、越境の第一歩だと思う。
講演の中での下記は、スゴく響いた。
「無駄をなくすことが目的ではない。目指すはリーンボディ。無駄のない筋肉質。結果として無駄が省ける。目的は無駄を省くことではない。」
日本人は得てしてプロセスを磨くことに注力してしまう。零戦の甲板の裏がピッカピカに磨かれていて、スピードなどの性能が格段に優れていることに、かつ、日本人のエンジニア力の高さに、米国のエンジニアは驚愕したという。それと同時に、このような部分最適化では、絶対に戦争に勝てるはずもないと思ったという。
我々は盲目的に部分最適を目指してしまうDNAを持っているのかもしれない。しかし目指すのは、無駄のない筋肉体質の肉体である。この言葉と、ダイエットの例えは分かりやすかった。無理なダイエットでは、確かに長続きはしない。リーンの全体最適化を常に考え、そもそもユーザーの抱えている問題を解決することに重点を置くようにしたい。
私自身、日々、社内で文化の育成に力を入れている。周りからはKPIや数値で計測することがカンタンではないので、そこを求められる。しかし、気にしてばかりいると一向に進まない。できることを一歩ずつ、前進することを心がけ、多方面にご迷惑や協力を依頼し、色々な企画やイベントを社内で開催していくしかない。活性化している気がするが、それは自分が過去と比較した結果であって、他のメンバーはそれほど感じていないのかもしれない。ここのギャップは、計測しようがないなぁ。それでも、自分の信じる方法で前進するしかないのだろう。
そんな勇気を貰った講演でした。本当にありがとうございました。
文字お越しをつらつらと
19:40 - 20:20 「Designing Culture〜文化をデザインする」坂田 一倫氏
ハッシュタグは、書籍等に関わらず、日本のLeanUXに関係することは、#LeanUXja
ルールではなく文化をつくる
組織文化をつくる
そこに左右されない文化を作ろう
お客さんに優れた製品を提供したい。UXの視点から双方に関連した考え方
2014.1.22 O'Reillyから発売された
こめた思い
日々、ニュースが来る。
IT業界の変化は恐ろしいほど速い。
2013年を振り返るった絵にまとめている。PS4、XBOX
企業価値が2倍や半分。すごく特徴的な年だったのでは。
流れが速いからこそ、流行にまどわされず、本質を。
サービスを提供している会社はどうあるべきか。
これを込めた。
実現している企業はあるのか？ある。
米国 Yahoo！メリッサ・メイヤー。驚きの変革を見せる
物理的に場を一緒にいることが良い。
ヒンシュクをかったけど、在宅勤務を止めた。
ノマドワークがはやっているさなかで打ち出した。
三人よれば文殊の知恵。協力的になることで素晴らしいアイデアが生まれる。
アイデアを組み合わせることで、より良いものになる。
文化のデザイン。ノマドから協業によって、創造性より協業性をとった。
株価74％あがった。
離職率も減った。
LeanUXと親和性がある。
企業の本質は、そもそも文化である。
マインドセットとは、文化のデザインにもなる。
ドラッカーにも通じるものがある
ドラッカー：MBO(目的管理)で人々の生産性を上げる
この本の中で提示されている手法は、企業の課題、気づいていない課題を表面か。それを答えに導いてくれる本である。本来のものづくりに焦点をあてられる。
LeanUX Thinking
代表的なものを4つ
1.どのようにつくるか、ではなく、どのようなものをつくるか？
2.問題解決。そもそもユーザーの抱えている問題を解決することに意味がある。
3.「足の引っ張り合い」から「助け合い」文化の醸成へ
4.中間生成物主体の文化からの脱却。
1.どのようにつくるか、ではなく、どのようなものをつくるか？
文化をつくるのと一緒。ルールを作るかではなくね。夢を実現するためにどのような文化にしなくてはいけないかってことにフォーカスしている。
どうやってUXするのか
HCD:10年以上も前に提唱された。
Human Centered Design: Research->Concept->design->develop
評価を繰り替えして回していく
これは、ISOでも定義されて型にはまっている。普及されている。でも沿おうとするとリサーチしないといけないって、そしてプロセスに従おうというプレッシャがかかる。本末転倒。
アイデア：市場でリサーチして、コンセプトをつくって。。。ゼロベースのアイデア発想ではない。
着実に実現されないと、アイデアには価値がない。実現されて価値がある。どうやって実現するかに意味がある。
HCD IN LEAN UX
Concept->Research->design->develop
リサーチとコンセプトが逆になった。
スタートがアイデア。それを実現するためにどうすればいいか。なのでアイデアの実現性が高まる。
自由な発想から創発的なことが可能になる。
2.問題解決。そもそもユーザーの抱えている問題を解決することに意味がある。
「問題解決よりも、問題の発見と定義」に重きを置く。
問題解決を優先してしまうと、問題とその定義の質が間違っていたら無駄になる。
定義された問題、発見された問題の質が高かった。成功する要素。
歴史を振り返る。
人間中心設計はハードウェア業界から始まった。
Why:Business ここでLean Startup
What:Development アジャイル開発。親和性の高い領域でものづくりを
How:Usabilityユーザビリティの根底にはったHCDを取り入れた。ユーザビリティを改善するために取り入れられた。
問題解決というのは、開発やデザイナと一緒にやっていたけど、そもそも解決したいのはなんだっけ？なぜ作るのか？
3.「足の引っ張り合い」から「助け合い」文化の醸成へ
デザイナとエンジニアで仕様書と違う等のイザコザがあり、その状況に遭遇していた。協調性を維持すること。透明性を維持する。
打ち明かす。これを一目でわかるようにする。
メンバーの１人一人、自分の領域の殻にこもって生産性をあげるように作業することが多い。一番の贅沢はチームが一体のなって作ること。
組織の断片化、分節化が原因なのでは。橋渡しとしてのドキュメント。お互いが孤立してコミュニケーションしている。メールとドキュメントでね。
目標が課されるので、サービスの目標を達成するより、部署目標を優先させてしまっている。
アジャイル要素
ペアリングやアイデアの幅を広げ、質を上げる努力が必要。中抜きでチーム間のフィードバックが速くなる。質を上げることを可能にする
4.中間生成物主体の文化からの脱却。
ドキュメント等の文化を止めよう。
Dave McClure
Customer don't care about your solution, they care about their problems.
「顧客はどんなサービスを提供しようと関係ない、顧客自身の課題しかみていない。」
何のために作るのか、という観点を持とう。ドキュメントではなく、お客様のソリューションに関連するものを作っていく。
結果として無駄がなくなっていく。
Lean
無駄をなくすことが目的ではない。
目指すはリーンボディ。無駄のない筋肉質。
結果として無駄が省ける。目的は無駄を省くことではない。
中間生成物のドキュメントを省く。
ドキュメントなどの位置づけが変わる
ガイダンスのためではなく、記録するための資料として位置づける。
脱却は、なくすではなく、位置づけを返るってこと。
ユーザーからしたらどんな文化があろうが、製品があろうが関係ない
サービスというのはインターフェース。コミュニケーションをデザインすること。
顧客とチームの人のコミュニケーション手段である。
何を作るのではなく
最終的なメッセージ
LeanUXマインドで部署間の壁を壊し、新たな文化を築いていきましょう。
マインドセットって何で必要なの？
企業は運用改善や効率をあげようとする。部署間の連携やコミュニケーションが少なくなっていく。
部署間の壁を4つのマインドセットで改善していく。
LeanStartup成長のエンジン
LeanUX学びのエンジン
ユーザからの学び
チームからの学び
学びの軸を設定する。どういう観点で学ぶ。
CPS Hypothesis
Customer: Who has the Problem?
顧客は存在するのか？
Problem: what is the pain point?
お客さんが抱えている課題は実在するか？
きづいているか
Solution:what is your solution?
対象のサービスやプロダクトは問題を解決できるか
これを学ぶことによって、改善し、共通の目的に向かっていく。
共通言語ができコミュニケーションができる。
方法論
Solution:LeanCanvas
Customer:ペルソナ ニーズや不満点
Problem:ストーリーボード 6up sketches シーンの一コマ
どうやってお客様の課題を解決しているのか？
想像と違うのであれば、検証すればよい。実験を促すためのエンジン。サービスとしての確度があがっていく。1回で終わるものではない。項目の前提を洗い出して、成長させる。
これはあくまでもスタート。それぞれテンプレートがある。部署が関係なくビジネスの特徴で、これらのS、C、Pで書いてもらう。前提を聞いてみると、確かめたいという衝動に掻かれる。
ユーザーの声が会社を動かす。ドキュメントではない。
Lean UX in Practice
作ることを目的ではなく、
何をつくるんでしたっけ？
学びが重要。
リリースは実験するもの。
学びを促すための仮説を構築する。
ビルドを先にするものではない。無駄をなくすことを目的にしていないのと一緒。
職種や歳、国籍は関係ない。
ピッチにて、こういう経験をした、この課題がある。これをみんなで考えていく。
2日でできるのに、企業で3ヶ月かかるのがばかばかしくなる。プロトタイプはこの感覚でつくる。
最終的な問い。週末やハッカソンでやっている。本来のものづくりってこうだよね。
コミュニティで本来のものづくりを追求していく。
マインドセットやツールを手に取って、前提の洗い出しをやってみて、文化を築いていければいいのではないでしょうか？
20:20 - 21:00 オープンディスカッション
質問 納期が短く決まっていた。いつまで仮説検証を繰り返すのかが難しかった。向いている、向いていないProjectがあるか?
ユーザーと接点がなくても学べる。つくることと出すことの期日が決まっているのであれば、そもそも、誰が作るのかが決まっていれば。検証を効率的に行うために、3つの指標をキッチリ設計する。
学びをビルドした後に持っていくということをオススメする。
質問 Leanで進めていく。KPIのどこに引っかかる。説得が難しいという気がする。感想や考えを教えて？
KPIが定められていて、定めていても、別の方法でってこと？このKPIを上げることが決まっていて。Leanで担保できるか?
部分的になると思う。上げていきたい対象が何個かあると思う。
そのキッカケがあると思う。どのコマがそれにあたるのか、そのシーンにあたるのか、そのために3つの軸をもって検証する。
サービスの理解とそこのニーズにフィットしていることの確認が必要。KPIは事業視点の言葉。ユーザー視点の言葉に変えていくと必然的にLeanのようになる。
質問 新規サービスをローンチした。ブレストが大好きだったけど、みんなの意見の無難なところ集めになってしまっている。8人くらいでした。
ファシリテーションが大事。バランスチームという発想。3人で一チーム。関係者はいっぱいいる。アイデアを3つであらわす。
ビジネス
デザイン
開発
この3つでバランスチーム。この3人でブレスト。自由度があったとしても、2時間はやってられない。時間制御でアイデアの質があがる。10個書いて、2つに分ける。いるといらないに。隣の人が破る。アイデアが生み出しやすくなる。納期や市場などもあるので、3人が一番思うものを意思決定する。トップダウンで意思決定もあるだろう。使う人やユーザーの誰に響くのか、その仮説を確かめていく。違うアイデアになるかもしれない。そのためにピボット。アイデアのピボット。短時間で実施する。
質問 捨てたアイデアの行き先は？
その時点では捨ててしまう。愛着があると改善はできない。たたみ方を仕方をしらないと成功しない。捨てるって、腹を括ると次のアイデアが生まれやすくなる。
質問 どんな時にLean思考にであったのか？
LeanStartupに出会ってから。起業法だと思っていた。無関係だなぁ。エリックが日本に来た時に、親近感を持った。HCDやUXの人が一緒に登壇していた。
スタートアップは時間や資金が限られている。彼らは限られているこそ、価値をユーザーに理解してもらうためにユーザーエクスペリエンスデザインが重要なんだ。
リーン思考を学んでいこうと思った。
質問 ドキュメントをリアルタイムではなく、記録のため。実際の現場で、どのタイミングで記録に残しているのか？
ドキュメントは一番最後。リリースする直前。QAの期間。一番最後の行程。
質問 ドキュメントの記録の期間は確保しているのか？
開発やデザイナはやる暇がないので、マネジャ達がやっていた。いなければリリースした後。ベストは直前。
質問 LeanでMVP。適したビジュアルのデザインのコツは？
デザインの方法になるが、デベロッパーと一緒に作ってしまう。ツールによって変わると思う。口頭でフィードバックしながら設計。二人三脚でやっていく。
全体的なデザインのトーンを揃えるにはCPSを検証する際、3つの軸、仮説が揃った時点、ターゲット、利用シーンが共有できたときに、
ムードボード：デザインの方針を作成したり、ブランド方針を決めたりして、それをMVPに入れて、印象調査をする。
質問 Lean UX 開発者には有用。逆にデザイナやユーザーリサーチャーには、時間も取れない。ドキュメントも書かれない。発揮できることが少ない。脅威を感じている。うまくやっていくには、どうしたらよいか？
デザイナからすると、日本と海外でスキルセットが違う。日本はビジュアルデザイン。米国はインタラクションまで含まれる。
米国では、デザイン以外のスキルセットがあるので活躍する場が増えている。
日本では、そのマインドセットが一番大事で、一度、デベロッパーと席を近くにしてコミュニケーション大事。途中成果物を見せて、一緒に考えるなどの働きかけが重要。
3つの仮説を検証するときにユーザーリサーチャーは活躍できる。課題の聞き方は価値を発揮するだろう。誘導尋問にならないテクニックはつかって、直面する課題を発見できるだろう。
ドキュメントは伝えるためにある。評価してきた段階でチームでリサーチしたインサイトを伝えるようなことをすれば、ドキュメントがなくても、やって成果を伝えられると思う。
質問 文化を根付かせる時の障壁と、施策を教えて？
2つの方法。アプローチ。
政治と実践プラクティス
1.政治：役職や社長。意思決定社を動かす情報を与える。
上は時間がない。接点は持っていると思うので、ユーザーとの設定をビデオで流す。忙しいので、お客様が利用しているシーンを見たことがない。声や表情を見る機会がない。
組織を動かす原動力はユーザーの声。
プロジェクトルームに、記録や写真を壁中に貼る。人が歩くと気になる。1個1個見て、気にしてもらう。PostITで書いてもらう。他の部署の人も意見をくれる。
2.実践プラクティス：小さなチームでやり始める。ものづくりは他部署との連携が絶対必要になる。同じ共感を持ってもらう。たとえどの部署でも同じ課題意識で動けるような文化を作っていく。
質問 間違えてもいいんだよって言っても、最初に間違えるというハードルが高い。こんなことをやっていていいのかの雰囲気の打開方法？
間違いを許容する文化を作るには、他の方のものを提示して、恊働的にやっているということ。自分１人ではなく。
みんなを巻き込んでやるのが大事。思い込み」が良い言葉で、正しい、間違いは関係ない。これを書くことで、改めて確かめてみる。そして確認して新しい発見をする。
共通認識を持てる。1回でもできれば成功だと思う。学んだことを反映しているかは、個人によるが、やったことを見てみて、定期的に見たりする。働きかけをしてみる。
思い込みを排除してみんなでやっていくことを醸し出す。
実験：構築
仮説：要件
学び：検証
言葉を変えるだけでハードルが下がる。空気を作りやすい。
質問 リーンで進めるなかで、世に出すために、検証ばかり繰り返してばかりいる。最小限で世に出してしまう。どっちも課題がでてくる。どっちが良いか？
出して、検証することが良いと思っている。直面するMVPの設定がカギを握る。ミニマムだすのは良くないと思っている。ランディングページを出しても原因が分からない。
MVPをペラ1ではなく、商品を見れるようにして、買うという仮ボタンをつくった。
そこまでをMVPにした、仮説を作った。その答えば出してみて直ぐ分かった。仮説の精度と答えを導きだす道や、そのためのMVPなのかという設計をきちんとする。
バイアブル：実用可能性。ユーザーが作っていけるという判断ができるもの。
動画は強い。使うイメージがある。次に何をしたらいいか、次のアクションをさせて上げる。見た後に何をするかを提示してあげる。
使ってみたい、課題が楽になるのかなぁ。次のステップが明示されていないと使われない。
興味の先を提示して上げる。サインアップをしてより、ソーシャルで接点を作る。
ダミー購入ボタンでコミュニケーションするのも大事。
もし、公開NGのことなどありましたら連絡ください。修正します。誰となく。
.jpg)
