ノート: デザイン

ラベル デザイン の投稿を表示しています。すべての投稿を表示

2013年6月2日日曜日

【読書】【メモ】This is Service Design Thinking その1

This is Service Design Thinkingを読んだメモと50ページ目くらいまでのまとめ。

◇ざっくり読んだ感想
サービスデザインの定義には"学際的なもの"と書いてあって、たしかに多彩な観点からサービスデザインに関する記述がなされているのだけど…　「それ本当にサービスデザインに必要？」みたいなものも混ざりこんでいるような気がする。

例えば、この本には経営学の辺りの話題も幾つか出ていて（マーケティング、オペレーションズマネジメント、あと経営戦略）、たしかに読んでいて示唆はあるのけど、これらがサービスデザインのプロセスや考え方に対してどう関わり貢献するのか、という辺りの記述があまりない。

これは別にサービスデザインに経営学が関係ないとか言いたいわけではなくて、「同じ経営学でも、そこの領域ではなくない？」という。

『組織の文化や既に提供しているサービスを踏まえてサービスデザインをしなければいけない』みたいな記述がこの本の中盤には繰り返しでてきて、これは明らかに経営学の観点から語れる領域なのだけど、そうであればマーケや経営戦略の人ではなくて、組織論について語れる人を連れてこないとしっくりこないというか…

--What is service design?--

◆サービスデザインの定義
・様々な学問領域から方法論やツールを集めた学際的なもの
・だから明確に言葉で定義できるものではない

◆五つの原則

サービスデザインの定義はないけど、求められる考え方を示すことはできる

・ユーザ中心 : 顧客の視点からサービスを見る
・共創 : デザインプロセスにステークホルダーも巻き込む
・流れがある : 相互に関係のあるもの同士の流れであるように見せる
・形に残る : 無形のサービスは物理的な何かで見えるようにする
・全体的 : サービスを取り巻く全ての環境を考慮に入れる

■ユーザ中心
・サービスは提供者と享受者のインタラクションで生み出されるもの
・享受者はそれぞれが違う経験や価値観を持っている
　→それぞれを理解しようとすることからサービスデザインは始まる
・チームも同じ
　→それぞれの知識を持ち寄ってサービスデザインするのが成功には必須
　→→だからユーザ中心を共通のサービスの言語にする

■共創
・サービスのプロセスに関わる（様々な領域の）人を集めることが重要
・サービスをデザインする人は考えるのではなく場を作りアイデアを評価する
　→ツールは適宜選ぶ
・共創は、顧客やサービスを実施する人達と行う
・ロイヤリティやエンゲージメントのためには、顧客を巻き込むことが重要

■流れがある
・サービスの持っているリズムは顧客に何かしら印象を与える
・顧客とサービスの接点
　→人と人
　→人と機械
　→機械と機械
・サービスのステップ
　→サービス提供前
　→サービス中
　→サービス提供後
・ワクワクするような印象を常に抱いてもらう
　→ストレスを与えること無しに
・プロトタイプを作る
　→サービス享受者がどう感じるのかを繰り返しテストする

■形に残る
・サービスは見えないところでひっそりと提供されていたりする（ハウスキープなど））
　→形にすることで、サービスのことを印象付けてもらうことができる
　→→ロイヤリティや推薦に繋がる可能性がある
・いつもそうすれば良いとは限らない
　→サービスの流れやタッチポイントの中でやるのが良い

■全体的
・顧客は（意識していないかもしれないが）サービスを五感で感じる
・幅広いコンテキストからサービスのプロセスを見ること
・顧客の体験を素晴らしいものにしていくためには繰り返し改善することが必要
　→現状の代替となるタッチポイントややり方を常に持っておくこと
・サービスジャーニーでステークホルダーが持つ印象を示しておくことが重要
　→企業の文化、価値観、組織構造、プロセスがサービスデザインには重要

◆マーケティングとサービスデザイン

・同じ課題に対しての出発点やアプローチが違う
　→マーケティングは共創のために顧客との関係を築く仕組み
　→デザインはステークホルダーを中心に据えて、彼らと共創する仕組み
・サービスデザインの中心
　→人・もの・組織の間にある価値
　→それらの間にあるべき関係性

2013年5月22日水曜日

【読書】システム設計の謎を解く強いSEになるための、機能設計/入出力設計の極意

モニターということで、ソフトバンククリエイティブ様より御本を贈って頂きました。ありがとうございます。

まだ隅々までは目を通しきれてはいないのですが、いま読んでいて思ったことなど書いておきたいと思います。

■はじめに

この本の最後の章には次のような記述があります。

・本書は共通・文書化などを取り上げているため、「ウォーターフォール」型開発に関する書籍だととらえられてしまうのではないかという危惧を抱いています。

・本書ではあえて設計や文書化の方法に多くの説明を行っています。これは、「設計要素を知っていて文書や記述を削る」のは適切な行為だと思いますが、「設計要素があることを知らずに文書や記述を削る」のは品質やプロジェクトの遂行に対してマイナスの要素をもたらすと考えているからです。

・アジャイル開発では「設計はしない」「設計書は書かない」ととらえているとしたら、それは誤解です。アジャイル開発においても当然設計は行います。

この本自体は、要求から始めて段階的に設計を詳細化していくというスタイルで記述されており、一見するとウォーターフォールなソフトウェア開発における上流工程のエンジニアリングについて書いてあるように見えます。

しかし、先ほど引用した文章に書いてあるとおり、著者の意図は『この本に書いてある順番どおりに設計プロセスを進めて欲しい』ではなくて、あくまで『各種設計フェーズにおける検討事項や設計する際のポイントについて理解してもらいたい』なのです。

ここを押さえて読むのと押さえないで読むのとでは、だいぶ受ける印象が違うと思います。

※なお、3つ目の引用では、アジャイルと設計・ドキュメンテーションの関係について触れているのですが、この点はとても大事だと思います。大事なことなので繰り返し書きますが、アジャイルなソフトウェア開発でも設計はするし、必要なだけのドキュメントは書きます。

■感想

システム設計についてこれから始める人にとってはいろいろ便利な本なのかなーと思いました。

タイトルにあるとおり、この本はシステム設計についての本なので、システムを構築するにあたっての知見がいろいろと詰めてあります。例えば、要件定義から設計の間にやるべきこととして、次のような作業を上げています。

●全体設計
・システム境界図
・システム俯瞰図
・サブシステム連携概要

●アーキテクチャ方針
・オンラインアプリケーション方針
・帳票出力方式
・ジョブ管理・実行方針

●標準設計
・文書テンプレート
・記述粒度・ガイドライン
・設計基準

●共通設計
・画面共通
・帳票共通
・バッチ共通
・DB共通
・メッセージ共通

割とがっつりと検討してますよね。で、この"がっつり"という点が個人的には重要だと思っています。

例えば、システム設計について経験したことが無い人がその辺りの知識を自主的に学ぼうと思った場合を考えます。個人的にちょっとしたツールなどを作るときに、設計などやってみて知見をためるというのは1つの優れたやり方ではあるのですが…　こと設計については話がやや異なると思っていて、それは"ちょっとしたツール"という規模だと、上述したような質・量で事前の検討はしないと思うからです（してもあまりメリットを実感できないと思います）。つまり、そこから学ぶことができるはあくまで"ちょっとしたツール"の規模の複雑さと、それに応じた設計までにしかならないということです。

あるいは、自主的に学ぶのではなく実際にシステムを作るときに失敗などを経験し、そこから学ぶのもよいのですが、現場で失敗するのはいろいろとおいしくないし、それよりは先人の知恵から学んだ方が良いわけで、そういう意味でこの本は便利だなーと思いました。

で、この本を読む時、成果物として定義してあるドキュメントの書き方からそのまま覚えていくという、ストレートな学び方もありだと思うのですが、ここまでかっちりしたドキュメントが必要となる現場はともかく、そうでない現場にいる人であれば、もう少しエコに読み進めていくのが良いとも思います。

システムの構築を行う際にその設計が求められる理由や、その設計を行うことによってどのようなリスクを事前に考慮できるのかなど、そういった観点に立って読んでいくと良いということです。

また、粒度や方針・整合性といった、一貫性のある設計をするのであれば否応なしに意識せざるをえない観点について、繰り返し記述が入っているのも良いと思いました。そういうのは大事です。

設計における一貫性を検討しない（設計思想がない）まま実装を始めてしまうと、やはり当然というか、コードからは設計レベルにおける意図が見えてこないような成果物ができてしまうだけなので…　やはりそういうソースは保守していくのも面倒だし…

■最後に

この本はオブジェクト指向やドメイン駆動なアーキテクティング・デザインについての本ではないと断ってあるのですが、OODやDDDから始める場合だってオブジェクトを永続化するのに使うのは大体の場合DBなわけで、そうであるならI/Oやトランザクションについて検討するのはやはり重要なわけです（この本に書いてあるような事柄を検討しないまま実装するとだいたい後で酷い目に会います）。

この本は、そういう意味でも"開いた"内容になっているので、この本に書いてあることがズバリ当てはまるような業務系のSEだけではなく、広い意味で設計に関わっていくような人はまず押さえておくとよいのかなーと思いました。

個人的には、手元においてハンドブックみたいに使おうかなーと思っています。

2012年10月20日土曜日

【建設予定地】『Rakuten Technology Conference 2012 - Design Thinking By Jeff Patton』ノート

2012/10/20に開催されたRakuten Technology Conference 2012での、Jeff Patton氏の講演『Design Thinking』のノートです。

※開催一ヵ月後を目処に公開致します。

2012年9月28日金曜日

『Experience Vision のはじめかた』ノート

2012/09/26に開催された『Experience Vision のはじめかた』のノートです。

DevLoveは今日で93回目とのこと。あと7回で大台です！

◆山崎和彦様 - 自己紹介

　◇経歴

　　・京都工芸繊維大学で工業デザインを専攻

　　・クリナップからIBMへ

　　・IBMでは工業デザインからソフトウェアのインタフェースデザインへ。ユーザエクスペリエンスデザインセンターを作った。

　　・その後はコンサルティングとして、UCDやUXを伝える活動

　　・そして千葉工業大学へ

　IBM時代にアメリカ人の同僚が言っていた。「アメリカでは家に帰ってから勉強している。大学も単位辺り2万円でとれて、5年かけてMBAが取れたりする、向こうでは余暇としてそういう生き方ができる」

　そういう生き方に興味を持って、神戸芸術工科大学・東京大学で手法を学び、現場で実践していった。いまも商品戦略ウェブ戦略パッケージングなどもやっている。

　◇執筆活動

　　やり方をまとめることの大事さを思い、本も書いた。

　　・使いやすさのためのデザイン

　　・情報デザインの教科書

　　　→この分野を学ぶための教科書として作った。

　　・プロダクトデザイン

　　　→教えることが先生毎に違って、どうなの？と思って出した。工業デザインって、どこでも聞くけど、教科書がない。僕らが始めて作ったという自信ができた。

　本として出版することで手法や考え方を使ってもらう。

　自分が学んで経験したことを使ってもらえることで、社会に役に立ったと言う実感がある。

　今日もその延長にある。

◆エクスペリエンスビジョンについて - どういったものか

　◇エクスペリエンスビジョンについて

　　・ビジョン提案手法のフレームワークである

　　・新しいビジョン・サービスを構築するために役立つという視点から作った

　　・ユーザの本質的体験から見た、ユーザがもっと喜ぶような新たな体験を与えるため、本質的な価値と展望を探ることが目的

　　・本質的欲求からはじめ、上位の価値やサービスを考える

　　・エクスペリエンスビジョンのプロセスを全部使わなくても、全体像がつかめるようなテンプレートがある

　◇エクスペリエンスビジョンの歴史

　　・エクスペリエンスビジョンは5年かけて作った

　　・ワークショップや合宿で実証していったら5年かかった

　　・いい手法はどんどん取り入れていきたかったから5年かかった

　　・世の中にあるものは使い、無いものは考え出した

　◇エクスペリエンスビジョン本について

　　・エクスペリエンスビジョンで使用するテンプレートはダウンロード可能

　　・本を持っていなくても落とせる

　　・エビ本には、エクスペリエンスビジョンの適用事例・教育事例・ワークショップ事例も書いてある。

　◇既存の手法をどんどん取り入れたことについて

　　・手法を考えた人は、それを使えば世の中を変えるような書き方をしてしまう。でもそれは嘘

　　・手法は一部分でしかない

　　・いろんな手法を上手く使いこなす。エクスペリエンス・ビジョンにはそういう役割を持たせている。

◆エクスペリエンスビジョンについて - 関連領域との関わり

　◇ビジネスとエクスペリエンスビジョン

　　・エクスペリエンスビジョンにはビジネスの観点もある

　　・ユーザとビジネスの両方を見ている

　　・モノを売っている人がどうやってサービスに転換していくか？など

　◇HCDとエクスペリエンスビジョン

　　・エクスペリエンスビジョンでは勿論HCDを使っている

　　・エクスペリエンスビジョンはユーザの価値に基づいて企画やエンジニアが提案するアプローチを取っている

　　・今までのHCDはユーザのニーズを受けるものだった

　　・今までのHCDは問題解決に寄っていた

　　・欧米のHCDの使い方やデザイン思考のアプローチを見ると、HCDはイノベーションの源泉としても使える

　　・HCDには問題解決と提案型の2つの使い方があり、それはプロジェクトに応じて使い分ければよい

　◇シナリオとエクスペリエンスビジョン

　　・構造化シナリオを取り入れていることはエクスペリエンスビジョンの特徴

　　・シナリオができればユーザの本質的価値を評価できる

　　・シナリオを使えば、きちんとしたウェブサイトなどを作ることなく価値を調査することができる

　　・戦略的にやるときはバリューシナリオまでやるけど、日々のプロジェクトはインタラクションシナリオで留めたりとか　…そういう使い方もできる

　　・ユーザ視点->プロトタイプ、ビジネス視点->ビジネスモデル、の形でシナリオの視覚化ができる

◆バリュー（本質的な価値）について

　◇エクスペリエンスビジョンでは

　　・構造化シナリオ手法を使い、段階的に明らかにしていく。

　　・フレームワーク上では、上半分をユーザ・下半分をビジネス。それを真ん中のシナリオでつないでいる。

　◇バリューなどの上位概念について取り組むということ

　　・これが曖昧だったりレベルが低かったりすると、いいアイデアが埋もれる

　　・そういうことはすごくある

　　・戦略作りはすごく大事

　　・プロダクトを作って、じゃあ2年~3後はどうするのか？ということが書いてない企画がほとんど。

　　・半年後の製品をただ考えるのと、ユーザの慣れも考慮したうえで2年～3年後のことを考えるのでは全然違う

　　・企画書は自分のウェブサイトや製品のことしか書いてない。戦略は戦略部門の話で別、となってしまう

　　・そういう中では新しいことをやるのは難しい

　　・新しいことには投資もリスクもある。それは単体の投資では回収できないことが多い

　　　→だから、上のレベルで目標設定することが重要

◆ユーザについて

　◇ユーザの本質的価値を知るためには

　　・提供価値分析やKA法という手法がある

　　・目の前の事象に対して、ユーザの価値や心の声を見つけ出していく

　　・潜在ニーズはフォトエッセイや行動観察で明らかにする

　　・顕在ニーズは日記や質問

　◇ユーザ設定

　　・ビジネスを考えるのであればステークホルダーも必要

　　・ステークホルダー = ビジネスに影響を与える人

　　・優先順位をつけて、具体的な対象ユーザを明確にする

◆シナリオについて

　◇シナリオとは？

　　・シナリオはモノとヒトの関係を表すことができる

　　・仕様書にはモノのことしか書いてない

　　・シナリオは日本語が読めれば分かる

　　・仕様書は専門家が見ないと分からない

　　・シナリオを介せばエンジニアとデザイナーが互いにコミュニケーションできる

　◇構造化シナリオについて

　　・シナリオを階層化していることがポイント。

　　・バリューシナリオ（ユーザの価値 / なぜ？）

　　　→バリューシナリオ：新規性・魅力がポイント

　　　→ユーザ・ビジネスにとっての価値

　　　→ユーザにとっての本質的欲求がビジネス提供者の提供方針がベースになる

　　・アクティビティシナリオ（ユーザの行動 / 何を？）

　　　→バリューシナリオの1シーン

　　　→ユーザの活動の全体が分かるように描く

　　　→ペルソナはこの段階ではっきりしている必要がある

　　　→有用性・便利さがポイント

　　・インタラクションシナリオ（ユーザの操作 / どうやって？）

　　　→効率・全体としての使いやすさがポイント

　　　→アクティビティシナリオの1タスク

　　　→具体的なモノ、その使い方を書いていく。

　　アクティビティシナリオとインタラクションシナリオの違いについて。アクティビティは人の行動なのでモノははっきりしていない。逆に、インタラクションはモノがはっきりしている。例えば、朝気持ちよく起きるのはアクティビティで、それを照明器具でやるというのがインタラクション。

　◇シナリオの評価方法

　　・ユーザの側面からの評価方法（代表的なもの）

　　　→魅力性・新規性・有効性・効率性。

　　　→魅力と新規は満足度に関係する

　　　→有効と効率は便利さに関係する

　　　→どれを評価するのかはプロジェクトの段階で変わる。例えばバリューの段階なら効率性より魅力性や新規性を見る。

　　・ビジネスの側面からの評価方法

　　　→戦略性・事業性・市場性・実現可能性・社会性

　　　→例えば、最初のバリューの段階で戦略を評価し、アクティビティで市場性を見て、操作で実現可能性を見る

　　　→3年後の話を考える時に操作性の話をするのは違う

◆エクスペリエンスビジョン・情報デザインに関して出てきた話

　◇問題解決と提案

　　・問題解決のプロジェクトは必要だけど、それだけじゃダメ

　　・新しいものやこれまでなかったものを考えるためにはユーザの本質に立ち返って、エンジニアからユーザに提案することが必要

　　・ただ提案するだけではなくて、ユーザの立場から提案することが重要

　　・ユーザの価値に基づいてビジョンを考えると新しいものが見える

　◇企画提案書について

　　・技術・実現可能性がポイント

　　・総合的なビジネス企画を立案する

　　・製品やサービスに対するユーザ要求仕様をまとめる

　　・ユーザ視点から見た仕様の根拠を書く

　　・うれしい体験 - 「HCDから見たポイント」「差別化・新規性・魅力」を書く

　◇本質的な価値の見つけ方

　　・本質的な価値を見つけるのは難しい

　　・バリューシナリオを作って共感度を見ていくのがよい方法だと思っている

　　・シナリオ作りならお金がかからないので、そこを評価して価値を見つけていけばいい

　　・何もないところからブレストしても仕方がない

　　・砂金取りと同じで数を打たないと駄目。

　　・新しいものはどこにあるかわからないので、広くユーザにアプローチすることが大事

　　・そのためにはできるだけ簡単な形で聞く方がよい

　　・シナリオは完全なプロトタイプよりも量が作れる

　　・シナリオなら「こんなものも？」という、プロトタイプでは（費用と優先順位的の兼ね合いで）試せないようなものについても調査ができる

◆もう少し周辺の話

　◇ゲームチェンジについて

　　・同じ土俵で戦うと安くて効率のよいところには勝てないというのがある

　　・そういうとき、欧米ではゲームチェンジを使う

　　・アメリカは自分達でルールをどんどん作っている

　　・改良だけで日本がやっていくのは今後難しいのではないか

　　・目の前の問題を解決するのではなくて、ユーザに本当に必要なものを長い目で見て戦略を立てることが大切なのではないか

　　「新しい目覚まし時計をデザインして？」と言われると、既知の固定された記憶の中でデザインしてしまう。そうではなく「朝、気持ちよく起きることができる体験をデザインして？」とすると、1つ上のレベルで考えることができ、もっと自由な提案ができる。チェンジゲームというのはそういうこと。

　◇スケッチとプロトタイプの違い

　　・散策的にアイデアを作るのがスケッチ

　　・検証的なものがプロトタイプ

　◇新しいサービスの確かめ方

　　・イベントを1回だけやる。ユーザにとってうれしいかどうかはそれだけで判断できる

　◇アクティングアウトの使い方

　　・いろいろある。実際に設計者が使ってみるとか。

　◇クイック＆ダーティ

　　・クイック＆ダーティに実験することがすごく大事

　◇構造化シナリオはウォーターフォールっぽくない

　　・アジャイルとシナリオは近い

　　・どこまで深くやるか？という違いだけの話。

　　・アジャイルはソフトウェアまで作るが、（エクスペリエンスビジョンでは）クイックにシナリオ・プロトタイプを作って済ませる

　　・クイックに作るのが大事

　◇心配していること

　　googleが自動運転の車を街で走らせ、実証的に走り方をプロトタイピングしている。日本は法律上そういうことが絶対にできないと言われている。iRobotもろうそくが倒れたら火事になるからできなかった。そういう日本人の潔癖さが、機会を遠ざけていることを心配している。

　◇異文化

　　アメリカでは、新しい発想をするためには異文化の人がいないという認識をする人が多い。技術者・マーケティングの人・デザイナー　…そういう人が混ざることで新しいものができるという発想が大事だと思う。

山崎和彦様, DevLove様, ありがとうございました。

2012年7月2日月曜日

『スタートアップデザイナーズナイト - パネルディスカッション』ノート

2012/07/02に開催された『スタートアップデザイナーズナイト』のパネルディスカッション部分のノートです。質疑応答だけを抜粋しました。あと誰が何を話したかというところで確信がないので、回答者の名前は書いていません。

◆パネルディスカッション

コンセプトメイキングから入ることが多いと思う。そして、同時進行をいくつも走らせているかと思うが、気をつけることや抑えていかないといけないことは？

・デザイン・サービスを作るときに、トップやチームがやりたいと思っていることがある

　→どうもって生きたいのか、どういう世界を作りたいのか？

　→どう具現化するかとか、それをどう落とすか？

・ただ単にデザインを作って終わりではない

　→思いや世界観を具現化をしたい

・ヒアリングではすり合わせを行う

　→ひとつの言葉の意味の確認をする

・言葉の意味をすり合わせることを大事にしている

　→（相手が）ふわっとした言葉を使う場合、こちらから見せて「これは（あなたの言う）かわいいですか？」とか提示する

もともとデザインをはじめたきっかけは？

また、始めたころの勉強方法は？

デザイン始めたきっかけ

・まず紙媒体から入った

　→絵起こしのプロセスなどを学んだ

　→DesignRulesという本を教えてもらった

　→→テクニックベースで基本的なことが入った本

　→→→色彩とか文字の大きさの及ぼす影響や、要素にまとまりを持たせるためには？など

　→→→→これが基点になっている

・デザインは人の目に触れるというところではじめた

・webをやりたい、表側の人間になりたいというところでデザイナになった

・デザイナのリンク集とか、関連している雑誌のレイアウトを真似して作るというのをひたすらやった

・真似に真似を重ねて今のスタイルになっている

・とりあえず見まくった

・デザイナではないが、たくさん勉強をした

　→本は買わなかった

　→いいデザイナと仕事し、やり方・デザインの仕方をひたすら見た

　→→「なんでこうしたのだろう？」「このバランス絶妙」というのを見て勉強した

・案件によってパートナーがいて、それぞれ得意・不得意や特性がある

　→案件やデザインの方向を見て振り分けている

コミュニケーションで苦労している点は？

・デザイナにテイストを話するとき

　→経営者やクライアントの想定しているテイスト

　→→それをデザイナにどこまできちんと伝えられるか？

・最初は苦労した。

　→それは噛み砕いて伝えないといけない

　→→ぜんぜん違うといわれて修正とかしていていた

　→→→日々試行錯誤だった

・気をつけていることはたった一つ「デザインとコーダの意思」

　→ちょっとでもずれていると最終的なデザインがずれる

・コーダにはデータを渡すだけではなく意思を説明するようになる

　→そうしないと全く別のものになったり、細かい部分が全部変わってきてしまう

・そういうものはチームで全てすり合わせる

　→外部の人の場合はいつもより気をつけて伝える

・運用段階でチームと何をするのかは、ぶれないようにしておく

　→目的意識がずれてしまうとUIやテーブル設計、仕様に影響を与えてしまう

みなさんコンセプトメイキングから入っている感じだが、製作過程や完成までの流れはどうなっているのか？

・コンセプトメイキングのテクニックはいっぱいある

　→チームによって向いているものがある

・会議の場所を変えてものごとを考えるとか

　→箱根にいって温泉につかりながらとか

　→→そういう限定的な空間で時間をつめてンセプトメイキングを行う

・形にするところでは、先行するサービスやイケてるUIからペーパープロトタイピング
　→そうやって人が使う動線を定義

・それから、エンジニアが設計、デザイナがデザインを行う

・コンセプト自体には全く意味がない

・ウェブサイトでコンセプトを伝えるのって非常に難しい

　→車はかっこいいとかそういうもので買う。細かいスペックなどでは買わない

　→でも、そのようなものをウェブで伝えるのは難しい

・何を伝えたいかをクライアントから聞く

　→そこからどうみせたらいいかを決める

・「こういう案件で、こういうクライアントで」と説明するとき気をつけていること

　→自分がワクワクするかどうか

　→→デザイナはどんなデザインでもできるが、想像性とかが出るように説明しないといけない

　→→パートナーにも「このままじゃ面白くないとけど、こうすると…」とか

　→→→そこまで作っていかずに、中途半端に人に渡してもいいものはできない。

・ワクワクできるものを提供できるように気をつけている

受託でやっているというが、リリース後も改善で入っている？

・そういう形でやろうと思う

・自分がやった分は最後まで

　→ボタンの大きさとか細かいところまでやる

デザインってゴールがないけど、テストをどうしている？

・自分の直感次第

　→「悪いから何かを変えないと」というところでは自分の直感しかない

　→クライアントと話あったりして変える

　→→ダメならまた変える

・"対ユーザ"と"対クライアント"で見ている位置が違う

　→ちょこちょこアップデートを繰り返してユーザを飽きさせないのが重要

・ユーザを妄想するのは難しい

　→でも効果検証すると強い

　→仮説を立てデータを見て、その按配でどんどん改善を重ねる

改善のところとかどうですか？

・スタートアップは公開したあとの方が重要

　→ボタンの配置や色使いとかで数字がすごく変わる

・リリース後に数字を作るのがデザインの役割

　→「データとしてこういう数字がでていて、ここが悪いからこうしたら？」とか

　→ただ修正しようではない

・声や数字を参考にしてデザイナと作る

数字の取り方は？

大手はABテストを細かくやっていると思うが、スタートアップは？

・google Analyticsとかは使う

　→もっと本質的な見方は別にあると思う

　→→勉強中

・ボタンの検証は難しい

　→みんな目立つように作ると思うが、目立たないことが原因ではない

　→周りのレイアウトがボタンを隠している可能性もある

　→→そこまでの流れが悪ければどれだけ目立ってもダメ

・数字を取るのは難しい

　→twitterなどの反応を見るしかない

・うちもgoogle Analytics

　→細かいところ、テキストのネガポジ分析はできてない

・テキスト差し替えによるコンバージョン検証は毎日のようにやっている

　→一時間ごととかで数字を出している

・Closed Betaで意見が集まって面白かった

自分自身のやり方もそうだが、そもそもデザインの知識がなくてやっている人も多いと思う。

そういうときの課題は？

・ウェブ未経験だけどこうしたい、こういう技術を使いたい、という人はけっこう多い

　→それはそれでいいと思う

　→分からないから私に声がかかる

・そのもやっとしたものを形にするのが私の仕事

・スタートアップは好奇心旺盛でやりたいことが多すぎる

　→多いのは良い

　→それとユーザが欲するものの中間を捜す

・やってみたいというのは現実に戻すと可能性が小さくなるものが多い

　→ユーザ目線でどうなるかをひたすらアドバイスする

　→釘が出すぎる前にアドバイスするのが自分の仕事だと思っている

・やりたいことをなるべくそぎ落とさせる

　→基盤ができてからやりたいことを追加させる

　→100あったら50に落とし、75でストップさせる

・やるのは大変

　→だけど、それを実現したり他の方法を提案するのが仕事

ユーザ系とプラン系で別れると思うが、その辺は？

・ディレクターと話すときはバイアスがかからないように

　→いかに自分達を客観的に見るかを注意するように

・改善案を盛り込むとき、方向があっているかどうかをよく確認

　→声は聞いても、染まりきらないように

・バイアスがかかっていない状態で答えを見出すところに重点を置く

デザイナーとかコーダは自分で探すのか？

・縁があって出会った人や紹介してもらった人と仕事をすることが多い

　→昔からデザインをお願いするならこの人、という人が何人かいる

・自分に合うかどうかもある

　→それぞれ個性や得意なテイストがあると思う

　→それをどれだけ引き伸ばせるか、というのは重要

日本と海外のスタートアップのデザインが似てきていると思うが、情報集めや真似するときのスタンスは？

・どうしたらローカライズできるかという視点でサービスを見る

　→基本的には文化が違うエリア

・海外の人は写真をものすごく上げるのが好き

　→いい写真があればすぐ撮り、すぐ上げたい

・向こうでやりたいなら向こうの文化にあわせてスタートアップをすべき

　→日本人的な感性相手にやるときは、日本人にあった切り口にしないといけない

・アプリは似ていると思う

→webはまだまだ似つかない。

→似ていると思っているのは我々まで

・サービスを使うのが一般ユーザだと考えるとそこまでは踏み出せない

→海外のデザインを入れると違和感を感じるユーザが多い

・モバイルのUIならぜんぜん取り入れてもよい

→そこで浸透して最後にwebならよい

・見たときに感じるものが日本と海外では違う

　→海外ではcoolが好まれる

　→女性向けだとかわいいを意識する必要がある

　→→でもそれは海外には伝わらない。

・デザインを見せたとき、かわいいと思ってもらえるような感覚を大事に

　→数字には出しにくいが…

・海外のデザインは好きだけど、日本では違うかなという気が

デザインセンスの磨き方。どういうサイトでインスピレーションをもらっているか？

・ファッション雑誌を見ているのが多い

　→海外のデザインや海外のweb award

・日本向けに作るときはファッション雑誌を参考に

　→日本は青文字系とか赤文字系とか細分化しているのが独特

　→それは紙面にも現れていて、受けるポイントが違う

・若い子はファッショントレンドをwebに感じる人も多いと思う

　→最近のファッション雑誌を見て、トレンドを参考に

・デザインセンスという言葉が好きじゃない

　→自分がセンスがいいとも思わない

・何がいいと思うのかの定義づけも難しい

　→みんな違う

・綺麗とされるウェブサイトには共通していることがある

　→それは違和感がないということ

　→→違和感を消していくとウェブサイトにピタっとはまる瞬間がある

・センスを磨くのは難しい

・横に対してそろっているとか、そういうものの組み合わせがサイトをまとめてくれる要因のひとつだと思う

・ウェブサイトを作るにあたって気をつけること

　→余白をどれだけとってつくるか

　→あとは写真のクオリティには注意

　→フォントのサイズ。フォントサイズは比例するように

　→→フォントがくずれると違和感しかない

　→→三つのフォントサイズで作るようにしている

・いろんなウェブサイトを見て、水準を上げていく

　→違和感を感じるスキルが優れていれば、綺麗といわれるウェブサイトにたどり着く

・感覚を正すことだと思う

　→センスという言葉は好きじゃない

・上のデザイナさんには引き出しを増やせといわれる

　→それをいかに一般的な感性に当てはめるか？

・トレンドとか日常的に触れているものをストックすることが重要

サービスを作るにあたって、自分自身のデザイナとしての役割をどう考えているか？

・受託という言葉のイメージ

　→クライアントとデザイナが対等ではないと思われがち

　→→みんな並列でやるという意気込みでやるべき

・デザイナやエンジニアの提案も面白いことが多い

　→ぜんぜん違う見方の意見がでてきて、それが面白かったり、ブレイクポイントになったりする

・これからクリエイターの価値がどんどん上がっていくと思う

　→彼らの価値を発揮できるようにしたい

　→だから今のスタンスをとっているというのもある

・「なんかかっこいい」とか「いいな」というのを研ぎ澄まして仕事にいかしていくというのが面白い

・デザイナとしての役割はクライアントの声を聞いて形をするということ

　→ユーザに何も考えずに記憶させることが役割

・クライアントの要望や考えは最低限の要素

　→それをいかにユーザに記憶させるかが勝負

・二面性がある

　→自分対ユーザ

　→→デザイナとしてユーザにどれだけ楽しんでもらえるか

　→対チーム

　→→無言実行

　→→"チームのモチベーションを高めるためにチームが喜んでくれそうなことを無言で実行することをデザイナーは求められる"というのがある

・世界への没入感を出すのがデザイナーの役割

　→コンパスを組み立てるのが役割

2012年5月6日日曜日

『第9回情報デザインフォーラム - 情報デザインのワークショップ』ノート

2012/05/04に開催された第9回情報デザインフォーラムのノートです。素晴らしい講演がたくさんあった。だからその講演内容を的確にまとめてみよう…！　と考えていたのですが、見返すとノートの半分は私の感想でした。

なお、当フォーラムのテーマは『情報デザインのワークショップ』であり、8人の講演者による発表と学生によるパネルディスカッションがありました。パネルディスカッションはただただ見いってしまったので、ノートはありません。

◆オープニング

情報デザインのワークショップという本を作るために資料を持ち寄って集まったら、その資料の内容がよくて、だったら発表しようじゃないか　…という流れで今日があります。という話でした。ハイスキルな人同士が集まっているからこそ成り立つ、この頂上決戦的な流れは好きです。

◆第一部　大学でのワークショップ

◇山崎和彦氏 - 『情報デザインのワークショップ・プロジェクトと体験ワークショップ事例』

体験という言葉とワークショップとの関係性についての話がメインでした。たしかに、参加者が体験をとおして『学び』を得るという、ワークショップが持っている特性を語るのであれば、『体験』が持つ意味や価値について論じるのは重要なことだと思いました。特に印象に残ったのは「ワークショップを誰とするか？」という話です。割とあっさりと触れただけだったのですが、このくだりを聞いて、私が持っているワークショップという概念についての認識は飛躍的に広がりました。　…というよりは、自分の体験によって植えつけられたワークショップという概念についての認識が矯正されたというか。人と人のコミュニケーションを通して作り上げていくものがワークショップである、というあたりまえの点について自分の中で勝手に枷を作っていたのだな、と反省することしきりでした。

以下、メモ。

・ワークショップは知識を得る場所ではなく、作り上げて本当の学びの楽しさに目覚めるためのもの。

・ワークショップでは『体験』することが重要。つまり、ワークショップ自体のデザインが重要になる。

・ワークショップにおける体験の分類

自分が体験
チームと一緒に体験
ユーザの体験をする　…　デザインのワークショップでは重要

・ワークショップを誰とするか

デザイナ同士
デザイナ・ユーザ間

・体験とワークショップの関係

体験を観察するワークショップ　…　相手を理解する
体験から発想するワークショップ　…　アイデアを広げる
体験を視覚化するワークショップ　…　個人的な作業を共有・評価し広げる
体験とビジネスを考えるワークショップ　
体験と社会環境を考えるワークショップ

・ワークショップの目的

学ぶ楽しさ・自主的な学び
発想の拡大・視点の広さ
共有・合意形成
相手の理解促進

◇原田　泰氏 - 『インフォグラフィックスを通して学ぶコンテンツ・デザイン』

図や絵は言葉と同じであるという価値観を持っているということをおっしゃており、実際にスライドの中で使われているインフォグラフィックスを見ると、ポテンシャルが高い表現技法なんだな、と興味を惹かれました。

インフォグラフィックスの制作工程

コンテンツ・デザインはメッセージを自分の言葉で表現し人に伝えるものである。
インフォグラフィックスの利点は『人に伝えることができる』『次の工程で再利用できる』ということ。
このような教育を行なう意図

インフォグラフィックスの視覚言語としての表現力と可能性を目の当たりして、モホリ・ナギのフォトモンタージュ作品やその造形理論をおさらいし直したいなー、とか思いました。

◇上平崇仁氏 - 『デザインワークショップの故きを温ねて新しきを知る試み』→『昔の事例を再解釈して新しいデザインワークショップをやってみた』

過去の人達が作ったり実践したデザイン性の高い作品・授業・ワークショップを元にして、ワークショップを作成しているという話をしていました。そして、ワークショップを作り実践する中で浮き上がってくるものを指して「過去の事例から変わらない大事さが見える」ということを言っていました。時代を越えて普遍な大事なものがあるよね？　ということです。また、過去のワークショップに学ぶことについて「そうしないと先人の実践が埋もれたままになってしまう」といった趣旨の話をしていたことも印象的でした。

そのほかにも、ワークショップやその周辺の概念についての見解を述べていたのですが、この点についても関心することしきりでした。一方的に教えるというやり方のデメリットの話から、これを裏返す形でワークショップを選択することの理由を導き出したりしており、私は見事に説得されました。

以下、メモ。

何故ワークショップか？　『人は言えば聞き、聞けば理解する』わけではないから。
学びは、知識をためるものではなく、社会的に構成されるべきもの。
教えることにはデメリットがある。教わる側に固定観念ができ、それによって思考停止してしまう。だから、教えるより自分で学ぶ（ワークショップの）方がよい。
ワークショップのツールに重要なこと。道具になっていて、参加者がお互い確認ができるというオープン性があること
ワークショップには限界がある。参加することでやった気になるが、自信には繋がらない。また、ワークショップ中毒者というものが存在しており、彼らは週末温泉に行くかのごとくワークショップを利用している。

・ワークショップの構成要素

身体
協働
創造
共有
プロセス重視

・ワークショップのポイント

先生はいない
客ではいられない
はじめから答えがあるわけでない
頭とからだが動く
交流と笑いがある

・ワークショップの切り口

明確に切り分けできないが、次の2つがある。

ワークショップを通して何かをデザインする
デザイン手法や考え方をワークショップで学ぶ

・まとめ

デザインにおいてワークショップと実践は同等
過去の事例から変わらない大事さが見える

◇安藤昌也氏 - 『写真を使った価値マップによるサービスアイディア発想』

サービスデザインの領域がだんだんと拡大しているという話と、ワークショップに適用する概念として『AT-ONE』というものがあるという話をしていました。で、後者の『AT-ONE』についてUXをする人が陥りがちな点と、重視すべき概念について話をしており、なるほどなーと思いました。

以下、メモ。

・サービスデザイン領域の拡大

『ニーズの充足』自体を価値とし、それを提供
『欲求の実現』体験した人が感じることを価値とし、それを提供
『意識→参画→価値』価値ではなく機会を提供

・AT-ONE

Actor　登場人物を広く
TouchPoints　どうつなぐか
Offering　何を提供しているか
Needs　本来満たすべきニーズは何か
Experience

・AT-ONEのポイント

Offeringが重要。
Offeringを正しく導けば、正しいActorやTouchPointsを導くことができる。
UXはNeeds, Experienceを考えがち。

◆第二部　社会人のためのワークショップ

◇木村博之氏 - 『インフォグラフィックスは自分で考え行動させるためのキッカケデザイン』

インフォグラフィックスやコミュニケーションの手段に留まらずプロダクトへ適用範囲を広げているという話が大きかったです。デザインが求められる領域がどんどん広がっているというか、デザインに対するリテラシが大きくなっているのだな、という話です。個人的には、デザインに予算を投下できないようなプロジェクトでも、それなりのデザインを持っていることは大前提になるのではないか？　という気がしています。私はそちらの方がいいので、情報デザインやユーザエクスペリエンスという技術が、世界にあまねく浸透し広がってくれることを本当に期待しています。また、ワークショップに参加することについて述べた際に「自分で考え行動するためのきっかけでしかない」と言い切っていたのが非常によかったです。

以下、メモ。

・フレーミング・リフレーミングが重要

・インフォグラフィックスの作成手順

（だいたいこんな感じだったような…）

伝えたいことを決める
データを集める
伝えたいことを再考する
表現を考える
情報を絞り込む
レイアウトを考える

◇小路晃嗣氏 - 『組織におけるワークショップの目的とその運営のためのポイント』

組織とワークショップという、私にとってピンポイントかつ即効性があるという非常に気になる講演でした。内容も期待を上回る素晴らしい内容だったのですが、全体としてメモがぜんぜん追いついていかなったという…　非常に残念です。「もっと大事な情報がたくさんあったような気がするのだけど…」と、ノートを見返す度に思います。スライドが公開されることを祈るばかりです。また、『ワークショップ開催のポイント』の箇所のスライドで、皆がカメラを取り出して撮影しまくっていたのは非常に印象的でした。私も確固たる決意を持って撮影に望めばよかったと思います。

・ワークショップの開催は継続して行なうことが大事、というのが結論。

・ワークショップには縦割りの組織の中で機会がないような人々が会う、というメリットがある。

・会社では費用対効果が求められる

・ワークショップ開催のポイント

儲けること前面に
責任と範囲を明確に
継続できるように
収支バランスを図る
税で社会に貢献する

・ワークショップ開催の合理的な側面

マニュアル化して誰でもわかる（開催できる）ように
レビューと改善を行なう

・ワークショップ開催の俗人的な側面

メソッドやガイダンスとして余白に表現する
人間力によるOJTを行なう

◇脇阪善則氏 - 『UX TOKYOとワークショップ - サード・プレイスとしての機能と役割』

『ユーザエクスペリエンスのためのストーリーテリング』の翻訳者です。非常にためになる本で、たびたびお世話になっております。今回は『UX TOKYO』を基点として、ワークショップの機能と役割について述べていました。特に印象に残ったのは、ワークショップを開催・洗練させていく中から非常に具体的な成果物を作り出す、という展望に関する話です。私にも計画的にものを見る視野が欲しいと思いました。

以下、メモ。

・ワークショップとは

本の学びを実践する場
実践の場
インプットした知見を消化してアウトプットする場
新しいことに挑戦する場

・ワークショップを通して経験の蓄積ができる

実施
デザイン発想
フレームワーク化
技術仕様化

◇浅野　智氏 - 『企業にHCDを根付かせるワークショップとその開発』

『何かを教える』ということと『教えるということについて責任を持つ』という点について、非常に印象を受けました。私の持っている価値観に「『何をすればいいか？』よりも『何故そうしようと考えるのか？』という、その人の持っている行動原理や価値観に触れたり想像できることが非常に重要である」　…こんなものがあるのですが、この講演はこの点について強く働きかけるものでした（あくまで私の印象です）。また、講演内容には実用的な内容も多々含まれており、学びがたくさんありました。

なお、特に強く印象に残ったのは、HCDを教えるためには7回のワークショップが必要ということと、この点については絶対に譲れないというものでした。つまり、「3回でやってくれませんか？」というお誘いがあっても、HCDを教えるためには7回のワークショップが必要なため、断固として無理、という話です。『断る』『譲らない』という行動や価値観について、私にはここまでの力強さがありません。だから印象に残りました。

また、ワークショップの構成についての考え方も参考になりました。

概論について講義し、以降の学びのメンタルモデルを形成する（これは絶対必要）。
全体像がわかるワークショップを行なう。
以降は個別のテーマについてワークショップ。結果がでやすいものから行なう。

その他、メモしたポイント

ワークショップは楽しいことが大事。
ワークショップを作る時はただ思いついたものではなく、もっと長いスパンで教えているようなものを落とし込む。
ワークショップでの学びが根付くところとそうでないところがある。社内に強力な推進者がいるところなら根付くが、トップダウンでやっても定着しない。

後援者の皆様, パネルディスカッション発表者の皆様, 主催者の皆様, ありがとうございました。

『第9回情報デザインフォーラム - 情報デザインのワークショップ』感想

2012/05/04に開催された第9回情報デザインフォーラムの感想です。情報デザインのワークショップというテーマについて、8人の講演者による発表と学生によるパネルディスカッションがありました。以下はフォーラムに参加した感想です。

あと、『情報デザインの教室』は買っておこうと思いました。

◇情報デザイン及びUXの価値が高くなっている

山崎氏が体験とビジネスを結びつけることについて述べていらっしゃいました。木村氏はインフォグラフィックスがコミュニケーションの手段にとどまらず、プロダクトの領域に進出しているという話をなさっていました。浅野氏は「PCをすっとばしてスマホを手にするユーザが増えており、彼らは利用するコンテキストに合わないプロダクトをわざわざ使おうとしない」という話をなさっていました。

また、元IDEOのElle Lunaさんが来日した際におっしゃっていた話の中に「市場の評価におけるデザインの割合が大きくなっている」というのがありました。「そんなところにまでデザインの概念とその重要性が広まっているのか」という印象とともに深く印象に残ったのですが、前述したようにこのフォーラムの中でもデザインの価値が繰り返し取り上げられており、デザインという概念がビジネスのさまざまな領域に織り込まれ始めているのだということを改めて認識しました。

◇人間中心設計とワークショップは親和性が高い

ざっくりとした言い方になりますが、協働するという点において、これらは非常に似ていますよね？　互いの（前向きな）コミュニケーションをとおして成果物を制作するというプロセスは同じなわけです。それから、（けっこう大事なことなのですが）成果物を評価する基準も何か似ているような気がします。

私がメインとしている業務系のソフトウェア開発の場合、利用者とプロダクトの所有者と開発者の利害は著しく一致しないという問題があり、求められるコミュニケーションのベクトルがワークショップのそれとは違うのです。予算と納期と品質と機能があって、それぞれについて三者間での落としどころをひたすら探すというか　…そういう観点から見ると、情報デザインとワークショップの親和性の高さは羨ましいです。

◇ワークショップの開催目的をはっきりとさせることが重要

ワークショップをとおして考え方を学ぶ、という話であればワークショップはそれ自体が目的となります。他方、ワークショップをとおして何か有意義な成果物が作りたい、という話であればワークショップはあくまで手段ということになります。前者であればワークショップの参加者に求められるのは参画する意識と必要最低限の予備知識ですが、後者であれば参画する意識よりはきちんとしたアウトプットを出せるだけのスキルが重要になるでしょう。ワークショップを開催するにあたって、これらの区別を行わないということはあまりないでしょうが、もししなければ散漫になってしまうのかな？　と思いました。

◇主催者・参加者それぞれがワークショップについての学びを持ち帰ることが重要

ここでいう学びは『ワークショップについての学び』です。

ワークショップ自体はそこそこの歴史があるものであり、学びの手法として強く根付いているものだと思います。そういう意味では、ワークショップというものはなかなかに語りつくされており、それが何であるかという議論も一通り出尽くしているのかな、とも思います。

一方で、このフォーラムの講演でもワークショップにおける体験や経験が未分化のまま語られることがあったりして、まだまだ発展途上で未知の領域が沢山あり、だからこそワークショップについて学ぶことが重要なのかな、と思いました。

ワークショップに参加したけど「あまり発言できなかったし、得るものが余りなかったな～」という経験や、ワークショップを主催したけど「みんなピンと来ない顔をしていたし、ディスカッションも盛り上がってなかったな～」という経験など、こういったものをうまく整理してくれるような概念やプラクティスが揃ってきてくれるといいと思います。

◇ワークショップはあくまで学習の一手段であり、銀の弾丸ではない

ワークショップが何であるかという話や、ワークショップの持つ特性、ワークショップの持つポテンシャルなど、いろいろな観点からワークショップについて語られていました。そういったメリットについての話の総体として、ワークショップは座学を超える学習の手段なのだな、という感覚を抱きました。他方、ワークショップが持つ中毒性を温泉に例えて警告を発している方もいました。また、ワークショップを通して学んでも、それが定着しない組織がある、という発言もありました。で、良いところと悪いところをまとめると、ワークショップが有益であることは間違いないが、それは適切な使い方があってこそなのだと思いました（当たり前のことですよね）。

また、ワークショップは協働という形態を取るので学びを共有することは必須です。なので個々人が学びを深堀りする必要があるテーマの場合や、学びに個人差が生じやすいようなテーマの場合、ワークショップは逆に弱いのかな？　とも思いました。

後援者の皆様, パネルディスカッション発表者の皆様, 主催者の皆様, ありがとうございました。

2012年4月7日土曜日

『 IDEOディレクターElle Luna氏とOneSheetの創業者Brenden Mulligan氏による「Startup Strategy」』ノート

2012/04/04に開催された『 IDEOディレクターElle Luna氏とOneSheetの創業者Brenden Mulligan氏による「Startup Strategy」』のノート。

これはElle Lunaさんのプレゼンテーション。

※管理人のヒアリングスキル及びあくまで意訳であることには留意してください。

◆Elle Luna 『How you can think like a designer To make difference in your startup』

- 『デザイナーのように考え、スタートアップを差別化する方法』

◇はじめに

今日お話するのは、本当に具体的なことです。

IDEOを辞めスタートアップの会社に入ったときくらいから、ずっと考え続けてきたことです。

スタートアップにあたり、デザイナーのように考えるには？　ということについて話します。テンションがあがってしまいます。

◇何故デザイナーのように考えるのか？

スタートアップの際、なぜデザイナーのように考えなければいけないのか？と思っている人もいますよね。

あくまで私見ですが、スタートアップをデザインすることは必要不可欠だからです。

それはrethinkすることであり、（デザインがなければ）会社の評価はそれだけ小さくなってしまうからです。

だから話すのです。デザインは本当に重要です。

◇何故デザインなのか？

自分のビジネスが将来どうなるかなんで誰にもわかりません。スタートアップも、何がどうなるかはわかりません。

最善策の代わりとして、『試してみる』ことができます。

あなたはマーケットにフィットする箇所を、スタートアップの中から見つけようとします。ファウンダは、開始してみるまでそのサービスがどこに向かって進んでいるのかは分からないものなのです。

たくさんの曖昧さがあります。たくさんの知らないことがあります。デザインが素晴らしいのは、それが曖昧さを許容する為の非常に偉大なプロセスであるからです。プロセスがあれば、どこに向かっているのかわかります。

1. Start with people - 人から始める

最初のステップは『人から始める』。ブレインストーミングやイケそうなアイデアの実現方法に時間を費やす代わりに、そうするのです。ブレインストーミングから始めてしまうことには本当に問題があります。外の世界に触れないままで明確化できる、という人はそう多くないのです。

では、本当の課題はどこにあるのでしょうか？　課題は生身の人間のところにあります。日々、あなたの周りの人達は問題を抱えています。あなたは助ける必要があります。

※ここでSquare創業者が引き合いに出される。彼は、人を良く観察し、カードでの買い物には沢山のプロセスが介在していることに気づいた。そして、そのプロセスって本当に必要なのか？　となった。

人から始めるにあたって、次の三つの質問を自分に問いかけましょう。

・人々が抱える日々の本当の課題をどのように観察できていますか？

・あなたのプロダクトを（多少手間があったとしても）ユーザが使おうとするモチベーションは何ですか？

・あなたのプロダクトの中でstep1. step2. …のような（こまごまとした）操作をユーザにさせているものは何？

2. Stop talking, start making - 話すより作る

スタートアップのアイデアは聞きたくありません。私は見たいのです。ポストイットでも構いません。できあがった何かが見たいのです。

それがあれば、皆とより早いタイミングで、より実りのある話ができるのです。

もう1つポイントがあります。よいアイデアというのは思いを巡らせているときには出てこないということです。考えることは素晴らしいことですし、よいアイデアを持っているというのもわかります。

しかし、実際にアイデアを掴む為には、作らないといけないのです。

分かりますか？　作り、試行する、ということを始めなければいけないのです。

さて、私が大好きな、作ることの力やどうやって全く作り変えてしまうかに関するIDEOでの話をします。

※鼻の美容整形に使用する器具の製作事例を紹介

もう作り始めることができますね。

・プロトタイプから何を学ぼうとしていますか？

・学びたいことを迅速かつ多量に得る為に、どうすればよいですか？

・チームは、明日からでも大まかなプロトタイプを手早く作ってみせることができます

3. Prepare to throw away a lot of work - たくさんの仕事を捨てる為の心構えをする

頭にあるものを実体に落とし込むため、手早くプロトタイプを作ります。つまり、沢山の物ができあがるということです。

これでもかというくらいの山を見たこともあります。

あなたは思考を重ね、沢山のアイデアを目に見える形にします。沢山の物を作り、そして、いつかは放ってしまう必要があります。

さて、よりよくするために沢山の成果物を捨てて見せたインスタグラムという企業の話をしましょう。

彼らが最初に始めたのはBurbnというサービスでした。150人向けのベータテストを行ない、ファウンダはユーザの行動を観察しました。

なんと、ユーザは写真をアップロードしようとしていたのです。Burbnに写真のアップロードする機能はなかったにも関わらず、です。

ユーザは写真を他のサーバにアップロードし、そのURLを貼り付けることで写真をやり取りしたのです。なんでこんなイカれたことをやっているのでしょうか？

ユーザは超カッコいい写真をシェアしたかったのです。

ここで彼らは気がついたのです。「写真をシェアするというのはこんなに面倒なのか。たかが写真のアップロードをする為だけに、Burbn外のサービスで幾手間もかけないといけないなんて…」

彼らは考えたのです。「なんで、何を差し置いても（写真をシェアする機能を）提供していなかったのか？　みんながカッコいい写真をシェアしたいなら、それが彼らのニーズじゃないか？」

そして彼らは6週間でインスタグラムを作りました。6週間ですよ！

なんでこんな短期間でできたかというと　…Burbnのインフラストラクチャがあったからです。Burbnは非常に複雑なアプリケーションでした。だからBurbnをリビルドするのではなく、Burbnから使えそうなものを取り出して作りあげたのです。

Burbnは非常に複雑でしたが、全て捨てました。最良の部分だけを取り出し、この絞り込まれたシンプルなプロダクト（インスタグラム）ができたのです。

たくさんの人に親しまれている、それがインスタグラムです。

なので、できあがったものを捨ててしまう心構えはしておきましょう。

ここで、3つの質問があります。

・あなたは作ったものを捨てられますか？

・捨てるときに直面する困難とは？

→それが他の部分と結合してしまっているときです。

・ユーザエクスペリエンスをシンプルにする為に切り捨てられる余計な機能はなんですか？

4. Spend as much time as possible talking to people who don't start startups - スタートアップをしていない人と時間が許す限り話す

時間はできるだけスタートアップをやってない人達と話す為に使いましょう。

我々にとって、こういう場所（このイベント）に来て会話をしたり、どこかのスタートアップにいっては友達と話をしたり、スタートアップの輪とつるむのは容易いことです。なので、サンフランシスコには20代の企業家がデザインしたアプリケーションが氾濫することとなります。私だったらもっとよくすることができる、というものばかりです。

ある企業の話をしたいと思います。シリコンバレーでは無いものとされていた人達にフォーカスし、世界のどのスタートアップからも差別化した企業です。すぐに注目され、急成長したシリコンバレーのスタートアップです。

Pinterestです。Pinterestというのは仮想のピンボードです。気に入ったものをピンして、シェアすることができます。ユーザーは気に入った画像をピンできます。

デザインは綺麗かつ非常にスマートな作りで、パワフルなプロダクトです。ただ、疑問があります「これが誰かを引き付けるのでしょうか？」

ヒントはサンフランシスコにいる男性ではないということです。　…母親です。 Pinterest はたくさんの母親を引き付けているのです。500万人の母親に愛されています。ここには典型的なサンフランシスコのギークはいません。

Pinterestは女性駆動です。西海岸でも東海岸でもなく、アメリカ中部から中西部に住んでいる女性です。

彼女達はレシピをピンします。夕飯を何にするか考えたいのです。手芸のアイデアもピンします。休暇など、子供達に着せる服用のものです。

あとはかわいい子猫の写真をピンしています^^。

このPinterestの基本的な点こそが、Pinterestを怪物たらしめているのです。

Pinterestのユーザ層はいわゆるシリコンバレーのそれとは違います。

彼女達はTechCrunchを知りません。（逆説的になりますが）だから、 Pinterest はシリコンバレーの外で見出されたのです。

ではどうやって手付かずの巨大なユーザ市場を見つけるのでしょうか？

彼らには男性以外をターゲットにするということと、デモグラを使うことへの才能がありました。

だから、信じられないくらいの巨大な市場を見つけることができたのです。

あなたに必要なのは次のものです。

・スタートアップの外の世界で、誰と話していますか？

・自分が推測していることに取り組んでいますか？

・インスピレーションの為に、文化や流行あるいはそれに近い体験をどのくらいしていますか？

・あなたの市場に対し、デザインをすることができますか？

アプリケーションを次から次へと作る際、デザインは信じられないくらいの競争優位になります。友人とコラボレーションし、始めましょう。

5. Humanize your story - 自身の物語を人間味のあるものにする

最後のステップは、あなたの物語を人間味のあるものにするということです。

作業を終え、スケッチを終え、ピザをこれでもかと食べ終える頃、ユーザーの全ての困難と向き合いたいという欲求がでてきます。

言いたいのは、彼らはそんな困難を求めていないということです。

広告なのですが、このビデオを見てください。

これはカナダのイヌヴィク(Inuvik)という小さな町のビデオです。この町では1年のうち1ヵ月、日が昇らないのです。

トロピカーナは10万ルーメンの明かりでこの小さな町を照らしました。

人はあなたが作ったものから、何かを経験します。

人はあなたがこの世界へもたらしたものに興味を惹かれます。

人は特徴を友人やチームへ話そうとします。

人は製品に隠れた力を、余すことなく友人へ話そうとします。

何を感じたかを覚えているのです。だからあなたの作ったものを愛するのです。

人を射抜く為に最初にできて最高の方法は、人に調和し寄り添うことです。

なぜならデザインは人々を射抜き、人々に入りこんでいくものだからです。

どうやってユーザを通じ自分の物語を人間味のあるものにするかについての素晴らしいビデオを見せたいと思います。

Tropicana - Soleil

ありがとう。

－－－－

以上です。

Elle Luna様、Brenden Mulligan様、Open Network Lab様、お疲れ様でした。

2012年3月22日木曜日

AgileUX NYC 2012 Redux in Tokyo - パネル・ディスカッション

2012/03/14に行われた『AgileUX NYC 2012 Redux in Tokyo』のノート。これは後半のパネル・ディスカッション分。なんだか刺激的でいいですよね？

パネリスト

・和波俊久氏 / LeanStartupJapan

・樽本徹也氏 / 利用品質ラボ

・川口恭伸氏 / アギレルゴ・コンサルティング

・坂田一倫氏 / 楽天

◆自己紹介

◇樽本氏

・開発がどんどんアジャイルになってきている。

・開発がウォーターフォールだからUXやＵＣＤもウォーターフォールになっていた。開発がアジャイルになったらUXやＵＣＤもアジャイルをやらざるを得ない。

・UXからアジャイルを仕掛けているわけではない。

・アジャイルに巻き込まれると今までのやりかたが通用しなくなる。その日は日本でも近い。

・UXをやっている人は早くアジャイルを勉強した方がいい。

◇和波氏

・スタートアップとアジャイルには決定的な違いがある。アジャイルはプロジェクトに適用するものなので絶対に終わりがあるが、スタートアップは絶対に終わらない。
・中身の動かし方は基本的に一緒で、非常に親和性が高い。

・リーン・アジャイル・顧客開発それぞれの源流をまとめたのがリーンスタートアップである。
・顧客開発を先にしないと駄目、というウォーターフォールへのアンチテーゼが元々のリーンスター・トアップ。ここには開発は全く含まれていない。
・Eric Riesはリーンスターアップに開発プロセスを追加した。

スタートアップ側からすると、どうやって終わらせていくか？というところに興味がある。

◆パネル・ディスカッション

◇UX（デザイナー）の悩みとリーンスタートアップ

坂田　「社内でもアジャイル勢が増えている。自分はデザインだが、デベロッパの方でも勉強会が頻繁に行われていて、デザインがいなくてもできるのではないか？という風になってきている。カードソートやストーリーマッピング、そういう手法がどんどんできるようになっている。で、スクラムマスターとかプロダクトマネージャーさえいれば、そこからイテレーションやスプリント・顧客の開発の方法を立てるといったことは回していけるという認識がある。さっきの話と繋がるのだが、つまり、デベロッパとビジネスだけでもプロジェクトが周ってしまうということ。たしかにそちらの方が早い。

我々みたいにブラックボックスでぶっこむと「金も時間もかかるじゃん」ということで、結果的に（周りが）離れていってしまう、という危機感がある。我々も今回のようなセッション等を設けて「アジャイルエクスペリエンスデザインという本の中にも、UXという手法が取り入れられているんですよ」といいったことなど「実は普段からこういうのをやっていたんです」っていうのを、どんどん打ち明かしていく必要がある。

最近ではユーザビリティテストというプロジェクトに被験者を1週間に1回呼び、そこにステークホルダーとエンジニアを呼んで、さっきのペアインタビューに近いのだけど、やって、精度を高めていくという。ことをじょじょにやり始めている」

川口　「聞く限りでは、デザイン（UX）とデベロッパが分かれていますよね。ビジネスというのは何をやっているんですか？」

坂田　「さっきの話でいうと、要件を作っている。ウォーターフォール型っていうのがまだあって、要件を出して、というところをやっている。技術的なフィーザビリティーっていうのを、デベロッパが検証して、デザインに落とすと」

川口　「ビジネス・デベロッパ・UXの3つがあると　…もう少し頑張ったらリーンスタートアップじゃないですか」

坂口　「リーンスタートアップに話を戻せば、このの構造はたしかに理想。プロダクトストアドシップを考えたときに、ビジネスデベロップメントという舞台と、カスタマーデベロップメントという舞台と、デベロッパという舞台と、三つの舞台があると提唱した人物がいて、まさにその通りの図になっている。　…が、うまくいっていないというのが現実である」

樽本　「なんで3つに分けているのか？　一緒に勤務はしていなのか？　プロジェクト毎には？」

坂田　「プロジェクト毎になっているが、入るステージがそれぞれの担当で違うというのが現実」

樽本　「各々3人ずつくらい引っこ抜いてきて、7-8人のチームを組んで、プロジェクトを回すっていうのが一番いいような気がするが？　同時にやればリーンUX。本当のアジャイルUXになる」

川口　「ちょっとしたことって感じですよね」

樽本　「うん。ちょっとしたこと。やれるじゃないですか」

川口　「でも、そんなことはないと思います（笑）」

樽本　「だから分かれてるからおかしいだけで、坂田氏はもともとUXですけど　…今はこのプロジェクトのチームメンバーです。あなたはデベロッパだけれども、今回はここのチームメンバーです。で、あなたはビジネスだけど、でもこのプロジェクトはここにいてくださいと。で、全員でヨーイドンでスタートする。ユーザリサーチから全員でやると。で、開発の終わりまでビジネスも全部付き合う　…という風にやると、いま海外でやろうとしていることになります。

日本ではそこが違って、それぞれドキュメントを渡したりとかですね。1つのチームになってしまえば、お互いにハッピーに仕事ができると思うんですけどね。それは駄目なんですか？」

◇アジャイルと決算

和波　「中身のやり方って、どんどん進化させて時代のスピードにあわせていくべきだとは当然思うんですけど　…実は先週、僕の方も大企業で、リーンスタートアップは採用できるのかみたいな勉強会をやってきたんですね。その中で、すごく心に響いた、ここを乗り換えなければ駄目なんだというのがあったんです。

株式会社である以上、決算を迎えなければいけないと。

で、決算を迎えるということは、動かしたプロセスに対して、何らかの定量的な結果を報告しなければいけない、というのがあるんです。サービスを開発しているときに、じゃあそれってどうやって定量的に図るんですかっていう、まさにブラックボックスの中で何やってるんだっていうのを、どこかのタイミングでは必ず定量報告をしなければいけないという。そこはつらそうだなーと思いましたね。
そこを乗り越えられるような、何か報告の仕組みのようなものができると、もしかしたら導入が楽になるのかな、という感じでしたね」

川口　「逆に、決算に紐付いた予算という仕組みが実は歪みを生むという　…その、ビジネスに合ってない決算期だったりすると、歪みを生むので。

もう1つのムーブメントとしてはアジャイルの方で言われている、Beyond Budgetting Round Table (BBRT)っていう。2003年くらいなんですけど、予算を撤廃してしまった会社というのが世の中にはあるらしいと。決算は当然でるんだけど、それは結果だと。だから年間の予算をたてるなんて
全然当たらないじゃん、みたいな。ただしマイクロな計測はものすごくやって、さっきの　…経営のダッシュボードを常に更新することで、経営の健全性は保てるんだから、予算いらないんじゃね？　というムーブメントがあるらしいという」

樽本　「それはアジャイルなの？　完全に？」

川口　「アジャイルには寄せているけど、アジャイルが発信ではないらしいです。予算を作るのを止めよう　…超える、みたいな。」

樽本　「これはいいね」

和波　「その点スタートアップの場合、すごくわかりやすい。レベニューあげるか、次のラウンドでお金を作るか、どちらか適えないと死んでしまうという。単純に非常にわかりやすい、と。バーンレートといって、いかに資金（お金）を使わないで先まで生き延びるか、その間に顧客を掴むか、という。いかにバーンレートを先延ばしにしている間にイノベーションを起こすか、という戦いなので」

坂田　「すいません。このままずっと話をしていると質問に答えられないので…　1つくらい行きましょうか」

◆質疑応答

坂田　「『顧客開発のためのPDCAについてなんですけど　…何かインプットがあれば共有いただきたいです。特に顧客セグメントの仮説立案のtipsやスケーラビリティを意識した検証方法などありましたら、お願いします』といったところです。多分、リーンとか意識しやすいと思うんですけど」

和波　「リーンスタートアップを実際に薦めてみると、デモグラとかジオグラとか関係なくなっていって、とにかく課題にセグメントしていく以外にないと思ってるんですけど　…そういうことですかね？」

川口　「あと、今回の資料にはでませんでしたけど、37SignalsっていうRuby On Railsで有名な会社が出している『小さなチーム、大きな仕事』。ユーザとペルソナをがーってデータで集めるよりは、自分がペルソナになるのが一番早いって、自分が使いたいと思うものからまず仮説を立脚するっていうのが早い、みたいなことが書いてありました」

坂田　「あと、去年、Janice FrasierさんというLuxrのファウンダの1人が日本にこられたときに、リーンワークショップというイベントがありまして、そこでやられていた方法というのが、正にペルソナを作って検証していくという方法でした」

◇インタビューは強力

坂田　「…（Janice Frasierさんリーンワークショップは、）ずっと6時間くらいやっていたんですけど、そこでやられていた方法というのが、「自分が使ってもらいたいサービスを1つ考えてください」そして「そのサービスを使うであろうセグメントをプラグマティックペルソナで4つの枠にざっとでいいので書いてください」と。で、そのユーザーが本当にいるかどうかというセグメントの検証のために、インタビューをしにいってくださいという。

で、その、さっきのLane Hallayのペアインタビューでもあったんですけど、それでペルソナをどんどん進化させていって、本当に我々がこれ使ってほしいユーザ・セグメントっているんでしたっけ？　っていうところからそもそも入るっていう。

そのペルソナの内容があっているかあっていないか　…というか、本当に実在するか否かっていう考えではなく、そのセグメントって本当にいるんですか？っていうところから入っていくのがポイントでした」

川口　「ペアインタビューのときに、今日はちょっとスライド乗ってないんですけど、実はLane HallayとJeff Pattonが2人でインタビューをした写真とかが出てて、僕的にはすごいウキウキして見てたんですけど、あのー、やはり、開発者でないとわからないアイデア・解決・問題もある。で、UXの人だけでインタビューするっていうのは、やっぱりその方が早いんですね。それを持って帰ってきて、その場で、後でトークするという方が解決が早いんで、やっぱり壁があると巻けですね。

で、アジャイルの人達ってすごくて、もともとアジャイルの考え方の一つが完璧なドキュメントを求めない、っていうんですけど、それは何故かというと、求めない変わりに、人と人が話してコミュニケーションするという、っていうのを重要視していて、その方が100倍早いって言っていて、そちら側にみんな吸い寄せられてる感じはしますね。どちらが偉いという話ではないんですけど。そういうことはすごいいいアイデアだと思います」

樽本　「インタビューはUXの専門家でなくてもできるんですよ。Contextual Inquiry（コンテキスト調査法）っていって。ちょっとやり方を教えて挙げれば、開発者、自分でもできちゃうんですよね。それでね　…多少インタビューのテクニックがひどかろうと、だいたいデータはとれるんです。一番大事なのは、できればインタビューを全員で聞くのが一番いいんです。

誰がインタビューしても構わないけど、他の関係者も全員そのインタビューを聞くと。そうすると、いろんなところでアイデアが出てくるンですよ、製品のアイデアが。で、勿論、全てのセッションにチーム全員を同席させるっていうのは、これかなりのコストになってくるので、時間の都合もつかなくなるのでね。

いまよくやるのが、録音するか、それかもう、その場で、みんなブラインドタッチできるしょ？　入力しちゃうんですよね。テキストをばーっと。適当に。で、その速記録をみんなに渡して、あとその、録音とセットにして、イントラネットかなんかにあげといて、そしてみんな自由に見られるようにしてあげると。で、そのインタビューの記録を読んで、そのインタビューの様子をビデオや音声で聞いて、で、ブレインストーミングをやるんです。そうするとぼっこぼこアイデアが出てくる。エンジニアの方から」

◇リーンとリリース

川口　「この中でユーザーテスティングとか、…開発に関しても、アジャイル以前のウォーターフォールを目指していたときは、どちらかっていうと、科学的な根拠、大数の法則だったり、5人調査しないとそれは知見にならないとか、考え方から、もっと少ない人数でいいじゃんと。アイデアが得られるなら、少ない人数でもどんどんと定期的にやっていこうよ、という流れがあります」

樽本　「そうですね、アジャイルUXとかアジャイルUCD、リーンUX、それはもう全てその考え方ですね。精度よりもまずアウトプットを出してしまう。データの精度をあげるよりはまずアウトプットを出して、それを早くユーザで検証すると。

とにかくアイデアの数勝負なんですよ。どんなに素晴らしい調査データがあったからって、アイデアでなきゃしょうがないじゃない。それでアイデアなんて、どの瞬間にでるかわからないんだから、
1人の話を聞いてる頭の5分でアイデアがでたら、それで充分役に立つわけだから。それで必ず成功するわけではないけども、でもアイデアを出すことがまず大事で、そのアイデアを紙のまま置いてたって、そのユーザには仕えないんだから。

早くコードにして、動く形にしてユーザに見せて、試してもらって、それでそれがうけるかどうか。それ検証した方が早いじゃないですか」

川口　「アウトプットからアウトカムっていうのが正にそれで、アウトプットっていうのは精度の高い、すごく品質の高いもの。でも品質が高くたって、使われないなら意味ないじゃんって」

樽本　「そういうこと」

川口　「その無駄を減らして、リーンにしようということなんですね」

◇結果が全て。データを集めるより作る

樽本　「結果が全てなんですよね。今は。どんな立派な調査やったって、製品売れなきゃしょうがないでしょ？って。だからリーンスタートアップなんですよ。製品作るところをスティーブ・プランクも書いているし、マーティン・ケイラーも全部書いているんだけど、製品みんなで一生懸命作ったってね、売れなかったらどうするんだって。売れなかったらあなたの苦労全部無駄になるでしょう、って。だったら作りながら売ったらどうか、って。売れるものちゃんと考えながら作ったらどう、って。それがリーンスタートアップの考え方ですよね？

だから製品開発に対して顧客開発って言葉を使っているんです。今までは製品開発が終わってから、営業するって言っていた。それじゃ間に合わないっていう。その製品もしかしたら間違っているかもしれないよって。お客さん欲しいと思ってないかもしれないよって。だから作りながら売ったらどうって。そしたら、売れるかどうかすぐわかるからって。売れなかったらピボットしちゃえって。

だからデータ集めるより作れって。早くコード書いた方がいいんだって」

和波　「最初からそのつもりでいるっていうのがいいですよね。そうすればいいんですよね。ユートリ（ユーザーストーリ）とかも最初から、何か学びに行くんだって言う気持ちがちゃんとセットされていると、どんな人でもちゃんとインタビューできているという。そういうことですよね。

◇AgileUXはどんどん進化している

樽本　「そのとおりです。もうね、インタビューなんて誰でもできる。Contextual Inquiryなんて、エンジニアに教えればどんどんできるようになる。どんどん教えてるよ。だから、UXの人これから大変ですよ。開発者がみんなUXの技術見につけちゃうから。

さっき坂田さんが言っていたよね？　彼らだけでできるんじゃないか？　って。できるようになってきてるんですよ。UXだけじゃ食っていけないはずです。絶対に」

川口　「すごいですよ。その話。僕がリアルに感じるのは、AgileUXの最初の頃って、UXの部署、専門家の人達と開発の専門家の人達をどうやって組み合わせるかっていうところで、最初はパラレルトラックアプローチっていうのが割と言われていたんです。

どうやってやるかっていうとスプリント・イテレーションで期をあわせてクロスに、ユーザ調査の成果がでたら、それは次のスプリントで開発にわたって、開発が終わったら次のスプリントでユーザのテストをする　…UXチームに渡すと。

これを組み合わせると、こう、メッシュ上に仕事を受け渡して、仕事がうまく一緒にできるよ、と。これが頭書言われていたパラレルトラックアプローチなんですけど、今回のAgileUXのカンファレンス、誰もパラレルトラックアプローチって言ってないんですよ。

みんな言っているのはチームの中にどうやってUXが入るのかというのと、UXの人達がどうやってプログラムを学ぶか、とか。どうやってビジネスラウンドと一緒にやっていくかっていう話をしていて、もう、全然くっつき具合がだいぶ進んできたな、という感じがします。この三年くらいでだいぶ変化がでてきた気がします」

◇コアユーザ・エヴァンジェリストユーザを掴まえる

坂田　「話は戻るんですけど、さっきのユーザーインタビューで出ていたジャニスさんのリーンワークショップの中にヒントといいますか、1つこうやったらいいんじゃない？　というのがあったんです。

インタビューのときに、ペルソナっていうセグメントって本当に実在するのか、という検証をするっていうのがあったんですけど、あわせてコアユーザーかどうかを見極めなさいっていうアドバイスを頂いて　…まさにリーンだと思うんですよね。本当にこのサービスを使ってくれるという、需要があるのだろうか？　というところを、質問を通してコアになるかなりえないかを発見していく。で、コアになるっていうフラグを立てたら、その人が本当に使うであろうサービスの領域を定めて。

多分それがMVPだと思うんです。なんでかというと、ピボットするというのは、ビジネスモデルを変えるという話に関わるんですけど、極端な話、全部変えたら元も子もない。どこまでを変えるかというところが、おそらく質問として上がってくると思うんですよ。ピボットをどこまですればいいんだ？　という話は僕自身も（考える必要が）あると思うんです。ピボットする軸の振り幅っていうのを見極める必要があって。

それは、先ほどのコアユーザが逃げないような、引き続き使ってもらえるような、最低限の自分たちのコアとなるもので、それを見極めなさいっていうのがありましたね」

和波　「すごいわかりますね。あの、間違った人にインタビューしていると、すごく悲しい気持ちになってくるんです。本当に、この人の話は、あと何分聞こうがたぶん意味はない、というのが途中でわかる瞬間があったりすると悲しくなるんですよ。スティーブ・プランクはエヴァンジェリストユーザというものを見つけなさいということを行っているんですよね。で、その人達は、とにかくそのサービスって言うのを早く世に生まれて欲しいと、心から切に願っている人達。で、そういう人達が必ずいますという話があるんです。

ちょっと、具体例なんですけど、僕の場合は事業開発の支援というところをやっているので、スタートアップの人達ってものすごく世の中に対して新しいバリューを提供しようか、というのを頑張っているんですね。

でも、僕から見ると、そのサービスが本当に拡大するか否かって、例えば、BtoBのビジネスとかだと、企業さんがそれを採用する障壁っていうものをどんどん下げてあげる。そうすると、すーって採用できたりするんだけど、その機能を一向に開発しようとしないんですね。だから『たしかにあったら面白いなーと思うんだけど、うちの会社には馴染まんなー』と思ったら絶対採用しない、みたいなところが気づかないんですよね。ずーっと気づかないまま。

だから、そういうインタビュー繰り返しちゃうと、何を作れば採用障壁が下がるんだ、というインタビューをしなければいけないということに気づかぬまま、ずっとお金を浪費していくっていう、そんなパターンがあったりするんですね」

川口「最近、カンファレンスのインタビューで増えていたのが『あなたはこのカンファレンスを他の人に薦めたいですか』って質問で、これ正にエヴァンジェリストユーザがどれだけ付くか、ファンになってくれるか、っていうのを探している。すごく増えましたよね、最近。これ（AgileUX NYC 2012）のインタビューもありましたよね？」

坂田「はい」

川口「勧めたいですか？っていう」

坂田「そうですね。ぜひ薦めたいですって（答えました）」

川口「エヴァンジェリストユーザが1人掴まる（笑）」

和波俊久様、樽本徹也様、川口恭伸様、坂田一倫様、お疲れ様でした。

2012年3月16日金曜日

AgileUX NYC 2012 Redux in Tokyo - AgileUX NYC ハイライト

2012/03/14に行われた『AgileUX NYC 2012 Redux in Tokyo』のノート。これは前半のAgileUX NYレポート分。非常に濃かったです。

◆Eric Burd

◇same problem statement

1. アジャイルやリーンはテクノロジやデザインというチームにフォーカスを当てがち。

2. だが、HRやマーケティング・セールスなどの関係部署にもアプローチする。

3. 全社的にみて共通の課題はなんだったかということを重視し、定義する。

◇ステークホルダーをどう巻き込むか？

1. ステークホルダーは忙しいのでなかなかプロジェクトに巻き込めない。

2. ランチはあるので、このランチ時間を借りる。

3. ユーザを呼んでその一時間でセッションをする。

4. これを週一で行ない、ユーザのフォローをしている。

◇スモールウィンを探す

・小さな成功を社内に探し、成功させ、エッセンスを社内に確立する。

・どこまでいったらこれサクシードだよねっていうのを見極めて探す。

・顧客やらビジネスプロジェクトやら、どこから導き出されたものかって言うのを整理する。

◆Phin Barnes

◇investing in design

デザインに投資するという、インベスターによる話。

・社内に導入するには、果たして私達にできるのだろうかというハードルや壁がある。

・アジャイルという言葉になじみがある人達にそういう壁がある。

・スキルセットではなくマインドセット。

・デザインはカスタマーデベロップメント（顧客開発）という原点をリードする立場にならないといけない。

・じゃあ組織を動かすものってなんだろう？定性データ？定量データ？

・データを見据えるだけではなくて、どのようなインサイトが組織内に成果をもたらし動かすのかっていうのを考えていく必要がある。

・（単なる）成果をもたらすものとしてではなく、持続的な文化として発信していく。

・リーンスタートアップでいうところの、カスタマーディスカバリー・バリデーション・クリエーション・ビルディングっていうのを回していくというのを我々の作業に落とすと、課題定義・スケッチ・プロトタイプ・ソリューションの改善・最適なソリューションの開発っていうのを回していく。そういったことを推奨していた。

　　※ Phin Barnes の発表について、坂田氏が気になった点

　　　共通課題をどう見せていくかというのでダッシュボードが採用されていた。
　　　・数字は継続的にアップデートされていて、全社員で見れるようになっている。
　　　・ダッシュボード化 = tamgible（触れるようになっている）
　　　・この数字をカスタマーデベロップメントサイクルで改善していく
　　　・↑が結果的に１つの文化になっていく。

◇定量データは、もはや遅れている

・我々はデザインドリブンの会社であり、もはや遅い。全然響かないし新しくない。

・次は、定性的な要素を加え、コンテキストを導入することが人を動かす力になるのではないか？

※アジャイルではダッシュボードが流行っている。リーンスタートアップでも最後のメトリクスが重要視されていて、定性定量も含めてインフォグラフィックスのような一枚絵、しかも自動で更新されるものをみなで見て判断を下す。そういう文化である。

◆Josh Seiden

◇要件を仮説に置き換える

1. アジャイルやリーンのコンセプトを社内に導入するにはそもそも要件という考え方じゃ駄目。

2. 要件は断固たるもので、いくら我々がUCDプロセスとか回したとしても変えることは不可能or困難。

3. 仮説はもちろん仮説なので正しくない。検証していく必要がある。

4. これにより不確実性がエッセンスとして取り込まれる。

5. それゆえにテストしたり学ぶ姿勢をチーム全体が保ってくれる、という力がある。

◇要件について

1. ビジネス責任者のこれがやりたい、というニーズはそのまま要件として認識される。

2. それを元に作業する人達は、その背景にあるユーザやマーケットニーズを知るすべが無い。

3. 要件ではビジネス側が要件を考えて、それを開発やデザイナが作るという風になる。

4. フェーズが完全に切り分けられてしまうが、それはウォーターフォールではないか？

◇ケーススタディ - アプリのインストーラー

1. 我々の顧客は無料で提供されているインストーラに価値を見出すのではないか？という仮説。

2. 具体的に何を造ればいいかを頭に浮かべる。

3. それをいくつかのsub-hypothesisにブレイクダウン。

4. テストを早く回せる感じのミニシナリオを作る。

5. インストールのプロセスが早ければ、顧客は無料のアプリをダウンロードするのでは？となる。

6. 仮説は検証するため、mbpで最小限にこれを達成する方法を考える。

7. インストーラをサポートするような画面や機能が必要なのではないか？となる。

8. 結果として、最初の要件とは全然違っている。

※mbp - minimum variable product。リーンスタートアップの概念。

◆Lane Halley

もともとデザイナー。どうやったらアジャイルと一緒にやれるのか？を考えてきた人。

デザインの立場になってアジャイルやリーンスタートアップをとらえてみた、という話。

◇デザインのアプローチが変わってきている

・デザインをチーム全体の責任にする必要がある。

・デザインというロールが変わってきている。

・部署や役割という垣根を越えたデザインが必要 = cross functional pairingを使う。

・デザイナーはプロジェクトのファシリテーターになるのではないか？

・デザインしているプロダクトやサービスの担当・責任を任せることができるチーム（プロダクトオーナーチーム）を作る。

◇cross functional pairing

1. デザイナ（特にフロント・ミドルエンドと呼ばれる場所のエンジニア）とペアで開発の人が実際に一緒になって作っていく。

2. 結果的に、クイックにビジュアルにすぐに形になる。

3. で、協力的・持続してcontinueousというのが可能になった。

※crossやコラボレーションがキーワード。

※ステージの最初からペアで行うなら、チーム体制を意識する必要がある。

◇インタビュー法

・early provisional persona - 本当に影も形も無いような、雑な仮説ベースを作る。

そういうセグメントがいるのでしたっか？というのをインタビューする。

・pair interviewing - インタビューはデザイナーだけではなく全員でやる。

・mutliple note takers - 1人に任せてノートを取らせない。あらゆる視点からノートをとり、気づきをシェアするという、

UXだけじゃなくてデベロッパも一緒にやる。同じ cross function paring の人もいれる。

◇プロダクトオーナーチームとcross functional paring は彼女達が作った仕組みに密接に関連している

1. プロダクトサービスの担当とコアのUXの人達と、開発者はアーキテクトくらいしか入っていない。

2. そのチームが製品全体を設計している。

3. デザインの骨格共通のデザインの部分も設計している。

4. ↑のフェーズが終わったら、各モジュールを作る。

l※デザインのコアをやった人がそのまま降りて、チーム（開発者）の横にいるようなペアを組む。

※ペアプログラミングはアジャイルでは良く言われるが、ここは、開発者同士ではなくてデザイナとやるという新しいやり方でやっている。

◆Anders Ramsay

アジャイルが良くするものは何かを突き詰めたものは、UXRagbyという表現になるのではないか。

◇リレー

1. トラディショナルな開発式、WaterFall。

2. 一人一人が走って、次の人にバトンを渡してじゃあどうぞって感じで、ハンドオーバーをしている。

◇ラグビー

1. 数人単位でボールを追いかけていて、トライをして、またトライを狙いにいくみたいな感じで連続したプレイを続けるスポーツ。

2. まさにアジャイルってそれなんじゃないか？と。

3. ラグビーのパスは言ったりきたりするが、まさにチームでもそう。

4. ペーパープロトから開発、というプロセスもバックアンドフォースのパスといった感じで、やっていくべきでは。

◆Jennifer Gergen

仕事をするためにプログラミングを自分で学んだということで拍手喝さいを浴びていた。

アジャイルUXをUXあるいはデザイナー側から対面している人。

◇デザイナーとプログラミング

・全部のプログラムを組めるようなスキルがあるわけではない。

・自分が少しプログラムを組めることで、会話がすごく円滑になる。

・ものすごく早くアウトプットが出る。

◇開発とデザイナのクロスファンクショナルペアリングをどうやってやっていくべきか

・イテレーションは機能とかページの開発には優れている。

・イテレーションは影響範囲が測定しづらい大きなデザインの変更には向いていないのでは？

・策としてAToMICデザイン（asset to markUp iterate colaboration）を提案する。

◆まとめ

◇UX/UXデザインはどう振舞うべきか -> demystifyする

1. 現在のUXデザインは、中で何が行われているかわからないブラックボックス状態である。

2. チームメンバーUXデザインってマジックみたいだよね、と考えている。

3. デザインは一筋縄ではいかない。いろいろ考えながら一本の縄を歩いているような状態。

4. だからこそ、ブラックボックス状態では納めない。

5. 頻繁に成果物を見せながら学んだことをプラスアルファしてシェアしていく必要がある。

◇共通言語で話す

・医者のように、他人が理解できる言葉で話すということを推奨。

◇要件と仮説

・要件は仮説になるべき。

・デザインは仮説を検証する実験になるべき。

・成果物は実験の結果。

◇その他

・UXにはメンタルシフトが必要。

・我々が日々していることを、スキルセットではなくマインドセットへのメンタルシフトを通して現場レベルに落とし、実行していく時代なのではないか？

◆補足

話の中に出てきたけど、放り込む場所が無かったものをここに記載。

◇アウトプット（成果物）とアウトカム（結果）の違い

・アウトプットはできたもの。

・アウトカムはそれを使ってユーザが何を得たか。

◇Jennifer Gergenがプログラムを学んだという件について

・デザイナーがプログラミングを学んでいるということに対して需要が高まってきている。

・デザイナーがプログラミングにシフトしつつある。

◇デザイナーは開発から招待されているが、デザイナーは彼らを招待していないのではないか？

・プロセスやコンセプトを理解して一緒に作業しよう、という風に招待をしていないので、コラボレーションが難しくなっているのではないか？

坂田一倫様、川口恭伸様、お疲れ様でした。

登録: 投稿 (Atom)