浅野先生 挨拶
情報デザインフォーラムは、
コミュニケーション研究会、サービスデザイン研究会、
WebUX研究会と分かれている。
坂田一倫 Lean UX の CPS仮説検証モデル
▼UPHILL OF HCD/UXD
1993年 ドナルド・ノーマンが自信の役割をユーザエクスペリエンス・アーキテクトと命名
2001年 Agile Manifestoが策定
2002年 JJGがThe Elements of User Experienceを発表
2007年 初代iPhoneが発売
2010年 ISO 9241-210が策定
2011年 THE LEAN STARTUPが発売
2013年 LEAN UXが発売
▼1. BUILD FOR EXPERENCE
THE BIGGEST LIE IN SOFTWARE DEVELOPMENT IS PHASE2.
・目的思考の醸成
何の為につくるのか？
目先の作業や手段にとらわれないプロダクトやサービス開発における
「問い」を繰り返す。
・科学性の強化
実験の結果はどうであったか？
結果の科学的な根拠が求められ、結果の信憑性や
妥当性を検証するための仮説構築が習慣化される。
失敗する確立は高い。
何回か繰り返せば成功する確立は上がる。
▼MINIMUM VIABLE PRODUCT
MVP（＝最小限の実用性が担保されているプロダクト）という実験装置
HOW TO BUILD A MINIMUM VIABLE PRODUCT
▼RISE OF C-P-S FIT V
LEARN-MEASURE-BUILD
C-P-S
・CUSTOMER
顧客は存在するか？
・PROBLEM
顧客が抱えている問題は実在するか？またそれに気づいているか？
・SOLUTION
対象のプロダクトやサービスは問題を解決できるか？
▼C-P-S EMBEDDED FRAMEI:WORK
CPSの要素が組み込まれたフレームワーク
・JAVELIN BOARD
・EXPERIENCE CANVAS
・VALUE PROPOSITION CANVAS
▼2.ASSUMPTION GENERATES EARLY VALIDATION
心理的変化２：前提となる思い込みや仮説は早期実証を促すためのエンジンである。
誤りの追求
どこまでが思い込みなのか？
プロダクトやサービス開発の前提となる様々な前提条件や情報に対する本質を追求する。
実証と未実証の理解促進
実証されているファクト（事実）はどれか？
前述の思い込みに加えてファクトやアイディアの内、
実証 / 未実証の仮説を導く。
▼GET OUT OF THE BUILDING [GOOB]
ユーザーを知ったつもりでいる状態を早期に打開及び実証するための方法論
▼GOOBを実践するにあたって
・議論や設計に費やす時間を最小限に抑え、CPSの軸に従ってMVPで実験する。
・定期的に顧客と直接接する機会を半強制的に設ける
・特定の顧客セグメントに限定せず、複数のセグメントを対象に顧客発見・顧客検証を行う。
・正しいものをつくるために顧客が必要だと思うプロダクトやサービスを早期に発見する。
▼LEARNING IS WHAT DRIVES THE TEAM FORWARD
CPS仮説検証サイクルはプロダクトやサービスの改善を促す学びのエンジン
プロダクトやサービスが改善されることは成果であり、
目的はどんなプロダクトやサービスをつくればいいのかを学ぶためである。
「我々は顧客開発をしているんだ」
▼TRADITIONAL UX DESIGN CYCLE
▼LEAN UX DESIGN CYCLE
仮説の実証から得られる学びによって発展するLEAN UXサイクル
▼まとめ：LEAN UXにおける2つの誤解
誤解1.先ずは早くつくってリリースすればいいい。
つくって「おしまい」ではない。続きはPhase 2 で、という話ではない。
そもそも必要ないかもしれない。構想の構造化・意味性の付与が求められる。
誤解2.先ずは（とりあえず）リサーチからはじめればいい。
CPSの軸に従って思い込みや仮説が整理されていれば、
ものありきでも不確実性が高い状況下にて効果的かつ迅速な実証が可能になる。
アウトサイドイン、インサイドアウト双方のアプローチと相互作用を理解する。
▼LEAN UX AS A WAY OF BEING, NOT AS WAY OF DOING.
LEAN UXはやり方ではなく、在り方である。
馬田隆明 Design Sprint 概要
▼自己紹介
Microsoft ベンチャーズ
▼Design Sprint
※Google Ventures
▼Case Study:Design Sprint with Google Ventures
デザインスプリントを実施して効果を上げたスタートアップの例
・Blue Bottle Coffee
Webサイトの売上２倍
・Pocket
最初のユーザーが最初のアイテムを保存するか
+58%の向上
・CustomMade
エンゲージメント +300%
▼Desing Sprintとはなんであるのか
悪いアイデアからスタートすることが実際し、ローンチする。
ことがよくよくある現場
▼Why Startups Fail
スタートアップの失敗の理由は「製品が悪かったから」ではないことが多い
※スタートアップは18ヶ月で資金調達をしている。
※狂っているアイデア
（悪いように見えて実は良いアイデア）
本当に良いアイデアなのかどうか検証する必要がある。
▼Design Sprintの特徴
1.既存の手法（HCD,UXD）
2.パッケージ化
3.締め切り
5日間のプロセス
4.個人とチーム
個人のアイデアを重視している。
チームでブレストすると民主主義的なアイデアになってしまう、
個人で考えてチームで合意する。
5.顧客
顧客で検証する。
▼Learn
DesignSprintでは顧客を通して学習する。
▼Get Out of the Buildingのところは共通
顧客発見
▼Prepare 0日目
・締め切りを決めること
・５人ぐらいのインタビュアーの確保
▼Understarted 1日目
成果物はユーザーストーリーマッピング
Day 1 Process
・360ライトニングトーク
・競合調査
・顧客インタビュー
・Stake Holder Map
・学びや洞察の要約
・ユーザーストーリー
・デザイン原則決定
・解決したい問題の決定
▼Day2: Process
・問題を分けて選ぶ
・マインドマップ
・Crazy8s
・Big idea Story board
・Silent Critique
・minCritique
・SuperVote
・デザイン批評（必要があれば）
▼Day3 Process
・意見のコンフリクトを探す
・bestshot / battle royalを決める
・前提とテストの方法を決める
・詳細なユーザーストーリーを描く
▼Day4 Outcomes: Prototyope
ユーザーに触ってフィードバックをもらえるプロトタイプ
・Day4 Process
・作業分担を決める
・AssetLibraryを作る
・各自作業を行う
・Lightning Critiqueを行う
・OutsiderReviewを行う
・細部をチェックする
Day5 Outcome:Scoreboard
・Day5 process
・キークエスチョンをリスト化する
・観察ルームをセットアップする
・AVテストを行う
・役割分担を決める
・インタビューを行う(BR案すべて)
・振り返りミーティングを毎回行う
・次のスプリントの検討をする
▼Desin Sprintのその後
・Googleさんもやってるんでやりましょう！
だがGoogleさんのように上手くいかない
やった後に見えてくる課題
1)問題設定が難しい
顧客理解の不足
・課題に直結するデータを取る仕組みがない
・顧客との会話が足りない
適切な仮説立案の難しさ
・そもそも課題がわかっていない
・マジックナンバーもわかっていない
・課題を明らかにするプロセスがない
・適切なサイズの課題に区切れない
2)インタビューが難しい
インタビュイーを集めるのが難しい
・顧客に常時会っていない
・顔の見える常連顧客がいない
インタビューそのものが難しい
・インタビューの機会が足りない
・手法についてお互いのフィードバックをする文化がない。
（インタビューはぜひ２人でやって欲しい）
３)組織への定着が難しい
やりっぱなしで終わる
・プロセスに関する課題をチームで共有できていない
（プロダクトは失敗するのではなく、成功しないだけ）
・リードする人がいない
Design Sprintが成功しない
・期待値の設定ができていない
（1回の成果物の合意や、2,3回するのを前提した期待値）
・デザイナーの出番？
▼理想論に留まらず、方法論もLeanにデザインしていく
Lean Startupを進める我々がLean Startup的である
・とにかく一度Minimumでやってから学ぶ
・チームの課題や状況、文化に会わせた導入から始める
・Design Sprintの型に囚われず、使えるところを使うつもりで
デザインすること
・問題を提起して、問題を解決する
・デザインしたことを感じさせないような方法で
ポスター発表
「サービス開発を取り巻く様々な「つくる」を考える」
モデレータ：山岸氏
・ものを作る為に学習が必要であることが両者で共通していた。
・物作りのサイクルと学びのためのサイクルが似ていた。
・筋トレのように強制的にインストール出来る方法だと捉えた。
山岸氏：フレームワークのLeanUX,DesignSprintをどう捉えて、
それを学びとしてどう捉えているか？
坂田氏：サービスに関わっている人であればみんな表現者であると思う、
表現者であることを自覚したときに、サービスの輪郭をどう捉えるかが、
Lean UXのC-P-Sのモデル
筋トレのようにドライブする力は必要。
そのためには各手法のフレームワークがどうやって作られているか知る必要がある。
でないと成功と失敗の判断ができない。
馬田氏：フレームワークはものの取り方の一つ。言葉もフレームワーク。
ものの見方はベストプラクティスの集まり。
ツールを使うと世界の見え方が変わる。
フレームワークを知っていると共通理解が生まれる。
山岸氏：実験の道具であるC-P-Sは可視化されてないと使えないのではないか。
（文化の可視化、あらゆるものが可視化できるのでは）
可視化するプロセスで何ができるか
坂田氏：可視化は便利な言葉。
可視化は手段、可視化は構造化、情報デザイン。
読み手の意図を読み取って情報を設計する。
（アンダースタンディング、ファインダビリティ、アクセシビリティ）
可視化の裏にあるのが構造化
グラフィックレコーディングも議事録も構造化しているもの。
馬田氏：スタートアップでの可視化と言う点で話すと、
構造化されすぎていて何かそこから逃れていくものが重要
坂田氏：IAサミットのセッションで面白いものがあった、
マーサさんのセッションで認知心理学視点から情報設計を行う。
ユーザーの第一印象は１秒で決まる。
情報は言語化しなさい、そしてユーザーニーズにマッチしているか考える。
情報の特性とユーザーの特性のマッチングが情報設計の醍醐味。
馬田氏：視覚だけでないものがでてくるなかでどういったものに気をつけていけばいいか。
坂田氏：IoT全部してしまえばいいわけではない。
可視化することがゴールになっているが、意味性が伴っていない。
Iot＝可視化が先行してしまっていて、どういった文脈で求められているか、
何を繫げればいいのか考えられていない。
山岸氏：可視化することに囚われすぎている、
これからは5感を使って使用するデバイスが情報デザインとして大事になってくる。
テキスト可視化することで色々な伝え方・捉え方が出来るようになる。
構造化されいるがゆえの弊害があるのでは。
それを情報デザインの文脈でどう乗り越えていくのか考えたい。
坂田氏：構造化されていると思考がかたよるデメリットがある、
情報が意味をなすことの一つとしてテキスタイルというものがあり、
それによって情報の質や感度が変わっていく、
馬田氏：構造化されている利点は早くできるから。
弊害はプロセスはいずれ疲弊してしまう、
疲弊にどうやって気づけるのかがポイントで、
そのために外部からDesign Sprintを導入したりすることも必要。
山岸氏：自分自身をアップデートするということは環境などによってなすものだが、
作るために情報デザインとした場合はピュアに考えることができるが、
マインドセットを作る為などにはどうやって組織として壁を乗り越えていくのは、
どうすればいいのか？道具をどう使っていけばいいのか？
失敗と成功についてお聞かせください。
坂田氏：成功するまでやり続ける、失敗を恐れない。
究極は失敗を設定しない。
コンセントでは自分達でコンセントスプリントを作った。
一発勝負のものではない、プロセスは続いていくんだよということを明示する。
馬田氏：プロジェクトマネージャーなどがどう思うのかによって、
成功か失敗か決まってしまう。
人によるということが良い意味でも悪い意味でも捉えられる。
山岸氏：期待値をどうコントロールしていますか。
坂田氏：プロセスの期待値はいわない。
引き出しを多く持っておくことが大事。
山岸氏：ものを作るという文脈でどう学び直していくか、どうコミットしていくのか？
坂田氏：IDEOのクリエイティブ・マインドセット 想像力・好奇心・勇気が目覚める驚異の思考法をおススメします。
（〆が日常をプロトタイプしていきましょう。）
情報デザインフォーラムメンバーのLT
■山崎和彦（千葉工大）
「つくる」を「つくる」と学び
▼最近の山崎研究室はなっとらんと企業に起こられたので、
テーマを「バカになる」として合宿をした。
「バカになる」ということで鹿沼にツアーにいった。
▼アンパンマンのテーマから
「愛と勇気だけが友達だ」と考えて、
勇気をテーマとして箱根湯本ホテルで合宿を行った。
▼バカになるフレームワーク（SXDスタジオ）
▼山崎先生自身がプラットフォームをつくるために、
自分のスタジオを作った。
▼HCDの専門家を広めるための活動をはじめた。
▼情報デザインフォーラムをNPO化して活動を活発にする。
▼熱中小学校プロジェクトを活動を開始した。
■原田泰（公立はこだて未来大）
つくるをつくる
・つくるをつくる×持続性
つくり続けるをつくる
つくるをつくり続ける
つくり続けるをつくり続ける。
ユーザーセンタードいいつつ、
デザイナーがいない世界になってしまっている
フレームワークをどうやって捉えるかによって、
枠組みが変わってくる。
人々の営みのなかに自然にデザインが発生してくるような活動。
■小池星多（東京都市大）
デザインしないデザイン
東京都市大
→普通の学生がデザインを学ぶ。
コミュニティデザイン
情報の可視化
ソーシャルロボット
▼何しているの？
・デザイナーは何か作っていると思っているが・・・
・何か意図してデザイン
▼ユーザーをつなげる
バス路線図のデザイン
▼問題を可視化して実行につなげる
多摩市でコミュニティバスを走らせる活動
▼ユーザーが自分の生活を変える敷居を下げる
▼デザインしているようでしていない
■木村博之（TUBE GRAPHICS ）
つくる「ひと」をつくる
インフォグラフィックスはデザインだけの狭いものではないなぁ。
SEさん向けのインフォグラフィックス本を日経BP社から発売。
SEさんに会わせてパワーポイントで作成した。
もしかしたら
Graphicacy = infographics?
４つめのリテラシー？
→三井物産「サス学」アカデミーとして、小学生を対象に、
ワークショップを行った。
■脇阪善則（楽天）
「つくる」を「つくる」
▼デザインの基礎体力づくり
東北芸術工科大学での事例
2013年度はカスタマージャーニーマップとペーパープロトタイプを行ったが、
進捗などに差があった。
2014年はユーザーシナリオ、トランジション型プロトタイピング（Prott）
テーマを時間割アプリとして、
アプリを分析してもらう時間を取った。
アプリを分析し、
アイデアを考えて、ワイヤーフレーム、ストーリーを作り、
Prottを使ってプレゼンまで行った。
▼スプリント
・一度でベストタイムは出ない
・日々の鍛錬が大事
・何度も繰り返す
クロージング
浅野智（HCD-Net）
情報デザインフォーラムのメンバーは、
書き換えを行っている。
情報というものはインプットするということではない、
アウトプットすること。
例：水泳の息継ぎは水を吐くことで行っている。
手法やプロセスは大切だが、
必殺技を捨てないと成長しない。
（例：武道）
次の第17回情報デザインフォーラムは9月22日（祝火）
コメント