2012年11月15日木曜日

【チラシの裏】今日の送別会の帰り道に思ったこと



2007年の4月、社会人になって初めての給料をもらった週末、電車がなくなる時間まで飲み、そして歩いて帰った。

サラリーマンとして稼いだお金でお酒を飲んだというささやかな満足感とか、これから始まる社会人としての人生に対する晴れやかな気持ちであるとか、今日飲んだ同期の仲間達とずっとやっていきたいという希望とか、自分の世代が今以上に会社を盛り上げていくのだという野望とか、一生懸命勉強して優れたシステムを作るのだという向上心とか、いろいろな気持ちを抱えてワクワクしながら歩いた。社会人として成長していく自分のことを思うと、明日のことを考えるのが楽しくて仕方がなかった。

そして、本日付で私は会社を辞めた。明日から別の会社に勤めることになる。

昔の常駐先の職場の先輩が送別してくれることとなり、普段いかない場所で飲み、自転車に載っておらず、飲んでばかりだったので締めのラーメンが必要 …など、いろいろな条件が重なり、たまたま5年半前と同じ道を歩いて帰ることになった。

キラキラした何かを抱えていたあの日の自分と、その会社を辞めたという半ば冷めた気持ちを抱えている今の自分が同じ道を歩くという偶然に驚きながら、当時のことを思い出したり、今の自分に重ねてみたりしながら帰った。

やりたいことを貫き通すために会社を飛び出したのだという覚悟や、新しく迎えてくれる仲間の期待に応えることへのプレッシャーなど、今の自分には向き合わなければいけないものがあって、だから当時のような純粋で晴れやかな気持ちで歩くことはできなかった。でも、それは、自分が当時より少しは成長していることの証なのだと思った。


今までお世話になった会社の皆様、ありがとうございました。そしてこれからお世話になる会社の皆様、宜しくお願い致します。

2012年11月11日日曜日

『第4回テックヒルズ UI,UXの衝撃 ~ユーザーを魅了するプロダクトの裏側~』ノート


2012/11/07に開催された『第4回テックヒルズ UI,UXの衝撃 ~ユーザーを魅了するプロダクトの裏側~』のノートです。



◆酒井洋平氏 「開発者のためのUXデザイン」

◇UI/UXって?
・UXって?
 →ユーザエクスペリエンスの略
・UIって?
 →ユーザインターフェースの略
・なんでUI/UXで一括りなのか?
 →この状況は不思議
・ネットでも専門家がいろいろ書いている
 →でも、皆「ん?」という状態なのではないか?と思う

◇↑のあたりを整理する
・UXはユーザからみた主観的な経験
・UIはユーザの主観的経験を支えるための接点となるいろいろな道具
 →券売機、ATM、自販機など。

◇人(UX) ←→ UI ←→ システム
・人に属するものがUX
・↑を支えてシステムとつながっているのがUI
・これが同時に語られるのはどういうことかということ。
 →大事なポイント
・旧来、デザイナーはUIを大事に考えてきた
 →いまはUXについても考えないといけない
 →→それはUIがUXを支えているから
 →→→そこまで考えざるをえない状況になっている
 →だからUI/UXという表現になってきている

◇ユーザの主観的経験なのでデザインできるのか?
・個人の内面的なものだからできないと思われるが…
・そうではなく、ある主観的経験が想起されることを企図した設計と考える
 →多くの場合はビジネスとしてやるもの
・ユーザに"価値がある主観的経験"を想起させること企図した設計
 →"個人的には"それがUXデザインだと思っている
・この辺りは議論になっている
 →ウェブ上
 →各種専門家など
 →UX白書
 →→UX白書をググってご覧ください

◇ユーザって誰? ユーザにとっての価値は何?
・この辺りをいま課題に感じている
 →ユーザって誰?どこにいる?
・見つけてきたユーザにとっての価値を真剣に考える
 →それをやらないとUXはできない
・今までのウェブでは数打てばあたるというところがあった
 →この辺は肌感覚でやっている人も多いのでは?
・どうやって見つけるか?
 →難しい

◇価値発見プロセス
1. 計測
2. 気付き
3. ベンチマーキングと観察
4. 脳内でプロトタイピング
5. ストーリーテリングで価値を訴える
 →このような活動をとおして新しい価値をもたらそうとしている

◇UXデザインをサマライズする
・あるUXの価値(ユーザにとっての価値)がある
 →それをどう発見するか?
 →どう実現するか?
 →→これがポイント
・具体的な価値が見つかったときにどうするか
 →部門横断的に価値に向けて動かないといけない。
 →→マーケティング・プランニング・デザイン・エンジニアリングなど…
 →UXの専門家がいるだけではどうにもならない
 →→全社的に理解してやっていかないといけない

◇展望
・マーケティングやプランニングなどの領域でもUXデザインと同じ考えを別の言葉で使ったりするのではないか
 →同じような活動が行われたり
 →同じことを別の言葉で指していたり
 →→そういうことが多い
・UXデザインの周辺ではその辺が整理されて全体統合的な流れが出てくるのでは
 →それが活発な企業から成功事例が出るのかなー


◆橋本建吾氏 「UI/UXについて 〜LINEの場合〜」

◇UX design ≠ UI design
・全然違うもの

◇理解を深めるために
・Janice Fracerの写真


 →食器や食材がバラバラの状態
 →→この状態だとどうすることもできない
 →→これをプロダクト、機能リストして考える
 →これをスプーンで統合する
 →→スプーンはインタフェース
 →→カップにシリアル
 →→ミルク
 →→スプーンで朝食
・これはUXとしては原始的なもの
 →でも結果として空腹が満たされる
・もう少し上層的な考え方
 →牛乳の量をコントロールしてシリアルの質感を変える
 →砂糖やジャムで味を変える
 →→こういうのもUXのアプローチだと思う
・自分でもチョイスしてみる
 →日本食
 →木の橋
 →漆の器
 →陶器
 →→ユーザの感じるものがずいぶん違う
 →→同じ結果でも与える印象はずいぶん違う
・材料や素材のチョイスで結果が変わる
 →このチョイスがUIデザイナーの役割

◇UXとは? UIとは?
・UXはユーザの感受であり体験
・UIは感受性を生み出す入り口、窓

◇NHN UX Designプロセス
1. simple
・NHNに入ってまず上長に言われたこと
 →半年くらい言われ続けた
・なぜUIにシンプルさが必要なのか?
 →様々なものが双方向的になっているから
 →→ユーザが参加するインターネット、という構造の出現
・ブログメディアの発展
 →素人の人でも情報が流通できる
 →→不特定多数の人間が情報を流通
 →非専門家による情報の供給
 →→シンプルなインタフェースが必要になる
 →→→誰でも使えるようなもの
・この考えはビジネスのデザインにも影響する
 →そういうデザインの方が強い
 →→0.5秒で持って帰ってもらえるようなもの
 →シンプルにUIを構築すると同時に、シンプルにバナー・広告も考える
 →→そちらの方がよい

2. Quick and Fast
・まず昔の一般的なワークフローについて考える
 →plan →> design -> develop
 →→ウォーターフォール的なワークフロー
 →工期が読みやすくて進行に有利
 →→でもプロジェクトのロールバックには弱い
・今やっている方法
 →UXがリサーチ
 →UIキャッチアップしてプロトタイプ
 →1回では終わらせずループをクルクルまわす
 →あるUIが完成したら開発にまわす
 →ここでもUXの方でデザインやインタラクション、ニーズへの満足度を検知
 →足りない場合は開発に戻す
 →これを半日とか一日単位でぐるぐる回す
・比較
 →ウォーターフォールはプランが無いと動けない
 →後者は起点がどこでもよい
 →→どこからでも回せる
 →→→クイックな開発・意思決定ができる

3. 意匠
・身の回りにあるもの
 →材質とか色など、ポイントを持ってものを選んでいるはず
・スマートフォン
 →→液晶などが進化していて非常に品質の高い表現ができるようになっている
 →毎日使うスマホのアプリにそこまで気を配っている人がどれだけいるのか?
 →(作り手も)あまり心血を注いでいないような気がする
・最近はUIコンポーネントがライブラリ・共有化されている
 →パーツを組み合わせればある程度のサービスができるということ
・差別化を図るには?
 →意匠を追及し、UXを高めていかないといけない
 →→特にUIデザイナが取り組まないといけない、という課題
 →→「ノイズを取り除く」
・流れや空気感を壊さないようなデザイン
 →画面上の情報のボリュームよりも
 →→そういうところにデザイナもコミットしないといけなくなってきている
 →→→「かんなをかける」と表現している
・「かんなをかける」
 →ざらざらした四角い木
 →→かんなをかけるとなめらかで気持ち良い質感になる
 →→→それはUIデザイナがやらないといけないこと
 →→→→そのためにはプロトタイプデザインを重ねていくしかない
・かんなをかけたUIはそれがごく当たり前のように見える
 →その当たり前に気付くか否かが重要
 →→だからプロトタイプを作り日々デザインする
・見た目や使い勝手に磨きをかける
 →そうすることで気持ちいいUXデザインができる

◇まとめ
・UIデザイナの選択の連続がユーザ体験を様々に彩る
 →一つ一つの選択の与える影響が大きい
 →→選択することに、より注視する
・使う人の立場、状況を踏まえデザインをシンプルに
 →シンプルにするのは怖い
 →→そこを踏み込んでいくことほどのUXのアプローチはない
・プロトタイプデザインを繰り替えす
 →そうすることで品質のでこぼこをなくす



◆坪田朋氏 「アジャイル開発におけるUX」

◇UI/UXについて
・UIって単語はイメージしやすい
 →議論の中で出てきても腹落ちする
 →でもUXは違う
 →→議論するときだいたい着地しない
・UXの定義をUX白書から引いてみた
 →「UXという分野は、システムの利用(あるいはシステムとの出会い)を通じて人々が持つ経験について…」
 →→なんど読んでも腑に落ちない
 →うまく言語化できないと思ってしまう
・UXという言葉が1人歩きしている
 →多くの概念を包括している
 →1つの定義で言い表せなくなっている?
 →→この言葉を使って議論することは危険?
・でもUXの意味を考えた
 →システムの利用を通じて人々が持つ体験
・UXって?
 →フレームはある
 →→タイムスパン
 →表すための要素もある
 →→ハニカム構造
 →自分で学んではき出していかないと身につかない

◇UXデザイナーとは
・自分はどう思っているか
 →イケてるプロダクトを作りたいと思っている
・ユーザーの立場を中心に考える
 →ユーザ価値のためにどうプロダクトを作ればよいかを考える
 →様々な方法論を組み合わせて課題・要求を解決する

◇イライラUIが生まれる理由
・最終的なプロダクトアウトはUI
 →なんでイケてないUIが出来あがるか
・ユーザニーズの不理解や市場の勉強不足
 →UXデザインで重要になってくる
・コミュニケーション不足やチューニング不足
 →UXデザインの後に出てくる
・これらがないと、イケていないUIデザインになる

◇Denaでの開発プロセス
1. リサーチ
2. 要件定義、UI開発
3. テストリサーチ
4. リリース
・これをループ
 →UXデザイナはこの全ての責任者だと思っている
 →→何をやるかを決めてチームを回すところまで

◇リサーチでなにをやっているか
・定量調査
 →アンケートを使って、数値化・グラフなどで表現したものを分析
 →→主観が入るところを定量化して明確に
 →→→いろいろな軸で切り取る
 →キャッチコピー・サービスの機能名・コア機能のニーズ・イラスト・キャラクターなど
・定性調査
 →定量調査で終えないものを追う
 →→実際に使ったときにボトルネックになっているものとか
 →→→スマホでゲームしているときの視線の動きなど
 →競合サービスに対しても使い、ヒアリングする
・競合調査
 →何が刺さっているかなどを切り出す
 →→ターゲットユーザー
 →→プロモーションマーケティング
 →→デザイン
 →→→設計
 →→→グラフィック

◇調査した後はUI開発
・要件定義やUI開発をする
 →要件定義は、何が課題で何をするかを決める
・まずはストーリー
 →それからUI設計
 →→ペーパープロトタイピングやワイヤフレームワーク
 →→→課題をどうUIで解決できているかを見る
 →使いやすさを考えるために実機でモックを作る
 →→HTMLやcssで再現
・違和感を感じた部分は何度も作り直す
 →必要かどうか迷った機能は落とす
 →→迷うような機能をユーザは使わない
・UIが決まったらGUI
 →どういうグラフィックにするかをデザイナと決める
 →→複数パターンを作る
 →→→チームやアンケートで採用する案を決める

◇リリーステスト
・プロダクトを始めて触る人が直感的に分かるようにしたい
 →ユーザに見てもらう
 →→テキストやアイコンなどの直感的な判断に関わるところを見てもらう
 →作っている側は慣れるので冷静に判断できない

◇リリース
・本当に受け入れられてアクティビティが向上しているかを見る
 →A/Bテストなど
 →→乱数・特定地域やセグメントなどで分ける

◇まとめ
・UI設計で重要なこと
 →徹底的な分析
 →→定量/定性
 →プロトタイピング
 →→実際に作る前
 →→→巻き戻りのコストを下げるため
 →→UIを決めてからGUI
 →ユーザーテストの実施と繰り返し
 →→盲目的になってしまったところを解決する

◇スクラム開発
・数年前から欧米で流行っているアジャイル開発の手法
 →上記のやり方をどう回すか?というところでスクラムを使っている
 →欧米では採用が多い

◇現場に求められていることは
・スピード
・スピード
・スピード
 →ウェブ開発では重要

◇高いスピードと品質を求められる
・マネジメントの期待する要求でスピードを出す
 →出した後は数字を求められる
・品質をスピードを達成しないといけない
 →スクラムだと品質とスピードが出せる

◇スクラムによる開発プロセスの最適化
・優先度・目的の可視化
・役割の明確化
・コミュニケーションコスト減

◇スクラムフレームワーク
・ストーリー
 →プロダクトバックログ
 →スプリントバックログ
・ミーティング
 →スプリント計画
 →朝会
 →振り返りとレビュー
・役割
 →プロダクトオーナー
 →スクラムマスター
 →チーム
・誰が何をやっているか、意思決定者が誰か、が明確化されている

◇スクラムについて
・ストーリーの書き方
「<サービス>においては、<目的>をしたい。なぜならば<将来の対象>は<現在の対象>に比べて<統計的事実>だからだ」
・スプリントは2週間
 →最初の月曜がプランニング
 →最後の金曜日がレビュー
・スクラムチーム
 →各人が専門(意思決定権)を持っている
 →→意思決定者が明確なので、コミュニケーションコストが減る
・チーム
 →UXデザイナ・リサーチ・エンジニア・UIデザイナなどに分けている
・スクラムではスクラムチームがまとめる
 →ディレクター制だとディレクターに集中してしまう
・チーム外のステークホルダーにはレビューで見せる
 →それを次のスプリントで改善する

◇ディレクション工程のシステム化
・Excelで線表を引く時間すらもったいない
 →ガントチャートはやめて朝会
 →アナログのタスクボード
 →→みんな自分で管理
・ミーティングは全員たってやる
 →タスク管理ツールはシンプルに
 →→タスクボード
・UIデザイン
 →パワポでワイヤーフレームから、チームでホワイトボードへ
 →→決まればデベロッパとGUIの人へ
・偉い人からの差し込み
 →基本的にはブロック
 →→レビューにまわして「次にやりましょう」

◇専門性について
・浅く広くではない
 →スペシャリストが作り、決める
・コンセプト・優先順位を明文化することでチームは自走する
・スペシャリスト同士のコミュニケーションに特化する
 →コミュニケ-ションコストを減らす

◇まとめ
・企画者は1人
 →事業管理している人
・サービスデザインはエンジニアやクリエイターの領域
 →彼らが作るのが一番早い
・UI設計はリサーチとテストがとても大事
・UXを考えないUIは時代遅れなのでは
 →リリースして終わりではない
 →→リリース後の効果分析を徹底的に行う
 →→→次に何をするかを決める






CROOZ株式会社様, 酒井洋平様, 橋本建吾様, 坪田朋様, アカデミーヒルズ様、ありがとうございました。