Google の UX担当２名が来日して、DesignIT!で講演するそうです。
AgileUCDjaでもブース出展して交流させていただく予定です。
- 開催日時：2009年11月18日(水) 9:30〜18:35
- 開催場所：ベルサール汐留（2Fホール）
- http://www.designit.jp/archives/cat74/
- 基調講演: 立ち込める暗雲 − Web サービスとクラウドコンピューティングにおける課題をかんがみる
- http://www.designit.jp/archives/2009/10/keynote1.html
- Donal Mountain (google)
- Braden Kowitz (google)
参加報告
いやー楽しかったです。ブースにご来訪の皆様、ありがとうございました。一緒に作業してくださった樽本さん、荒川さんに感謝いたします。
ブース
- 多摩美の吉橋先生と、すこし IDEOとかの話をした。発表とCritiqueの仕組みは、デザインの業界ではわりと昔から普通にやっていたのだけれど、言語化できてなかったと。IDEOはそれを言語化し、かつマーケティングがうまいので、すごいな(悔しいな)、という感じらしい。
- 名古屋大学の長尾確先生に AgileUCD を説明しながら、すこし整理できた気がする。「Agileって何ですか？」というすごく初歩的な質問をしてくれつつ、米国/日本のクラウドの話(DesignITのテーマ)もしつつ、という多彩な話題で意見交換でき、とても勉強になった。
- 長尾研究室はわりとフィジカルコンピューティングに力を入れているみたいで、ビデオ照会が楽しそうだった。日本のメディアラボ、という感じ。
- 大学の研究室の打ち合わせでもファシリテーション重要だよね、という話 - 長尾のブログ2.0: 会議革命、その後（後編） http://bit.ly/3dhs6L
- 東京工科大学の人たちは、八王子の地域コミュニティの代表者同士がお互いに情報を交換できるコミュニティオブコミュニティ的なWebサイトを作っていた。勉強会勉強会で、地域コミュニティはIT/非ITの垣根が低くて、盛り上がっているという話があったので、それをお伝えした。
カンファレンス
- Google UXチーム に所属している Donal と Braden の基調講演は、クラウドのよさをアピールしつつ、課題となるデータ保持やネットが切れているときの挙動、開発環境など、UXに関する部分はフロンティアがいくつかある、という話
- Microsoft 鈴木さんのセッションは、Azureの話。ちょうどPDCで商用サービス開始が正式発表された日でもあるので、最新の話だったみたい。PDCの内容は、Silverlightが誇る素晴らしい画質のビデオが公開されているとのこと。
- 住友信託銀行の小吉さんのセッションは、実は今回一番感動したセッション。
- もともと銀行窓口業務をやっていて、複数のツールを組み合わせて使わなければならない現状に、「なんでこうなっているんだろう」と疑問をもっていた
- ユーザビリティに着目した窓口新システムを作るための、インタビューが来て、「私がやらなければ」と思い、作る側にまわることになった(システム開発のことは全く知らないけど、勇気を持って飛び込んだ)。
- 開発手法は、プロトタイピング + ウォーターフォールと定義していた
- 現場の意見を聞き出したり、人が集まる会議で実際に使ってもらって、開発者が後ろで観察したり。ユーザビリティの手法をソシオメディア社からコンサルしてもらって、やった。
- 現場のスムーズな移行も気を使って行った。
- １つの業務フローの例では、 3画面が1画面になり、入力が1/3になり、180秒が30秒に短縮されたとのこと。
- 経営向けのアピールも行っていて、「現場の声」+「ユーザビリティ」を組み合わせてアピールすることで、システムの必然性と有用さをアピールした。
- 企画担当と、開発担当は同席で作業を進めた。
- 感想
- なにより、小吉さんのパッションに感動した。涙でた。
- 「問題をいたいほどよく知っている人」が、熱意を持って改善のために努力するということ。
- こういう人がいると、プロジェクトはうまくいくと固く信じている。言葉は悪いが「熱意ある共犯者」と定義したい。
- UCDとアジャイルのメソッドを取り込むことで、開発者にも現場にも納得感の高いシステムづくりができたようだ
- 企画者も開発者も悩みは多かったとのこと。いや、それは正常な悩みだと思う！あなたが悩むことで、他の多くの人の悩みが取り除かれる。それがシステムづくりってものじゃなかろうか。
= DesignIT Conf 2009 =
* 篠原さん
* Google の公式コメントではない
* Donal Mountain & Braden Cowitz
* 1. The Cloud is Always Available
* ブラウザ１つで仕事ができる - 過去にはできなかった
* 2. The Cloud is Safe
* 電話やノートパソコンをなくしたり、写真をなくしたり
* ローカルコピーを１つだけもっている頃とは違う
* 3. The Cloud is Collaborative
* 共同作業する場
* FAXは紙を送っているので根本は変化していない
* Google Docs はリアルタイムに変更できる
* Challenges Ahead - この先に進んでいこう
* いろいろな課題がある
* いろいろな作業が手元のパソコンで行われている
* 製品やサービスのクラウド化をとどめているかを認識し、
* Donal: UXのリサーチャ。ユーザと対話して、理解する立場。ニーズ、製品の利用方法の調査
* Braden: デザイナー。プロトタイピング、ストーリーテリング
* サンフランシスコに住んでいる
* 様々な答えはもっていないので、シリコンバレーの人たちに聞いた話をレポート
* Googleの見解ではなく、UXのプロの意見をまとめたもの
* 1. Always Available
* 世界の貧困に立ち向かう非営利団体: 世界中で通信したい。
* ガーナでクラウドのもつ問題に直面
* インターネットがつながらない、不安定
* ネットの復旧を待たずに作業したい
* 回線速度は東京の 1/400
* 僻地に回線をひくのは高価
* Microsoft Outlook: ネットにつながっていなくてもメール作成できる
* 送受信するときだけつながればよい
* => クラウドもこれができないといけない
* Presantations
* このプレゼンはクラウドにおいてある
* サービスの突然の停止
* => Works Offline
* 現在でも作ることはできるが、ちょっと難しい。
* Building Offline Apps
* ブラウザの中にデータを置き、定期的に外と通信して同期
* 根本的に機能が違うので、作るのが大変。開発環境も物足りない
* Better Offlines in Browser
* Chrome, FireFox, Safari, IE
* オフラインで稼働するウェブ
* Gmailのオフラインを作ったときは、オフラインでできることを伝えるのがUIデザインのチャレンジ
* これから多くの人が直面するUXの課題
* サービスの停止だけでなく、データの紛失
* Apple の HyperCard
* 素晴らしかったが、販売サポートの停止
* => アプリは手元にあるしデータもあるからそんなに問題はなかった
* クラウドの場合
* magnolia: ブックマーク共有
* システム障害(バックアップから復旧できず)でデータ紛失
* サービス自体がなくなった
* => クラウドのアプリがなくなっても、ユーザからアクセスできる状況をつくること
* Data Portability
* データの所有権をユーザがもつこと
* アプリケーション間で持ち歩けること
* Download your data
* データをダウンロードするアプリケーションがある
* ユーザに選択肢を与えるAPIを提供
* Switching apps
* iPhoto -> Adobe Lightroom
* HDD上にあるので簡単
* Picasa -> Flickr
* どうしたらいい？？
* => オープンなAPIがあるので、情報の移行ができる
* ユーザに選択肢を与え、満足感につながる
* 2. Safe
* HDDで手元に置くのは安心だけど
* パソコンは盗まれる
* コーヒーをこぼす
* => データの紛失は常にリアルにあり得る
* 長期のプロジェクトでは手元に置くのはよくない
* 銀行とお金と同じ
* 昔は、金貨は手元に置くものであり、預けるのは変だった
* 現在のクラウドの状況。手元にある方が安心感が
* 紙幣になり、口座残高になった
* こういう風に、だんだんと人はクラウドを信用するようになる
* => これは、信頼の問題 It's all about Trust
* 障害
* Gmail: 100分のサービス中断
* ホワイトハウスのメールが一日停止
* => たくさんの人がサービス中断が起きないように努力している
* 今後10年を考えれば、起こりうる問題
* 業界はどうすればいい？
* 他の業界に学ぶ
* British Airways Flight 38
* エンジン停止 => 空港になんとかたどり着いた。しかし、300m離れていたら民家
* それでも僕たちは同じような飛行機で東京に飛ぶ
* 命をかけて信頼している
* それはなぜ？
* 航空業界は事故に関する情報を一般公開している
* 自動車を運転するより 7倍安全
* 情報の公開が信頼を生む
* Transparancy
* クラウドベースのアプリケーションは各社から"ダッシュボード"を提供して状態が分かるように
* Learning from mistakes
* 間違いから学ぶ
* フライトレコーダやボイスレコーダの情報が残っている
* 墜落事故を分析する人が多くの情報を持ち帰る
* BA38: 燃料タンクの凍結による問題だった
* => 業界は解決策をとる
* クラウドも情報を共有することで、業界全体を安全にする
* パスワード
* 紛失すると何も動かせない => HDDが壊れたのと同じ
* 盗まれる => ノートパソコンを盗まれたのと同じ
* 事件: Twitter 内部資料の漏洩
* 内部資料がインターネットに漏洩し、報道に
* 事件: Palin 元副大統領候補のメール漏洩
* Phishing
* セキュアなアカウント
* 特定のアカウントの正式な使用者があくせすでき、
* そうでない人はアクセスできないように
* Solutions for Company
* ハードウェアのワンタイムパスワードキー
* => 一般人向けには難しい
* Solutions for Everywhere
* 今後の課題
* 3. Collaboration
* 新しいコラボレーションの形
* Google Apps
* Google以外にもとてもたくさんある
* クラウドでアプリケーションを作るには最高の時代
* Authoring : コンテンツを作り出す
* Google Docs
* 文章作成だけでもクラウドにするのは難しい(フォント、印刷)
* なぜ難しいか？ => ブラウザはそのために設計されていない
* オフラインでコンテンツを作成し、アップロードするという形が多いが、ここ数年でWebブラウザ上でコンテンツを作成するということが主流になる
* Webブラウザは年々速くなり、機能を盛り込んできている
* オンラインで写真加工とかができるようになるだろう
* Webは共有が楽
* URLで共有できる
* 共有は一方で複雑かも
* 間違って個人情報を共有してしまう
* Sharing Controls: 共有のコントロール
* これは課題
* みんなでよくしよう！
= 住友信託 =
* プロトタイピング + ウォーターフォール
* 現状の分析
* システムが分断
* フロント応対のクオリティも低下しかねない
* 営業店統合フロンとシステム
* 営業支援システムでたまったノウハウを
* セールス - 事務処理 - 一連顧客対応フロー
* セールスと事務の分断の解消
* 従業員の効率化と、顧客満足度向上
* 一次フェーズの例
* 照会業務
* 3つのシステムで3回の口座番号入力が必要だった。
* 18画面、120秒
* 営業支援システムは前日の情報しかない
* 勘定系システムは最新のものがあるが ...
* => 20秒に短縮
* 1回の入力、一画面
* ユーザビリティへの取り組み
* これまで明確に取り入れたことはなかった
* 業務フロー標準、画面設計標準がない
* ユーザ要件定義者がバラバラのままシステムが開発されてきた
* 営業店の担当は、異なる画面、複数の業務フローをもつ、複数のシステムを使わなければならなかった。
* => "ユーザビリティの高いシステムを" 一貫した方針で作成する必要性
* 成功の鍵
* 現場の声をシステムに正しく反映させる
* 声にならない声をききとる
* 経営層に現場の声を「わかりやすく」伝える
* リリース時の現場の混乱を少なくする
* 成功の鍵1: 現場の声をシステムに正しく反映させる
* 営業店にヒアリング
* 問題意識の高いテンポを選定
* <= ここで小山さんはヒアリングされる側だったが、作る側に回ろうと決意
* ２度のプロトタイピング(予備検討時、要件定義時)
* 共通イメージを持ち、要求を反映させながら進める
* 店舗のリーダーが集まる会議で実際に操作してもらう
* メンバーは後ろで観察して、ユーザが気付かないポイントも抽出
* 例: 検索画面
* たくさんの条件を入れられるようにしていたため複雑化
* => 1画面で検索結果まで見られるようにした。
* => 使い勝手、操作性を重視してシステムを実現
* 成功の鍵2: 経営層に現場の声を「わかりやすく」伝える
* このシステムは現場がとても必要だということを伝える。
* そのためには、困っている人が伝える。
* ただ単に経営層に「ユーザビリティが大切だ」といっても伝わりづらい
* 現場の声とユーザビリティを結びつけることで、経営層に伝わる
* 経営層「わくわくするね」「現場の声がよくわかったよ」
* 進捗会議がスムーズに進んだ
* 成功の鍵3: リリース時の現場の混乱を少なくする
* 各種集合会議でプロジェクトの進捗を報告
* 各営業店のキーマンを集め、でも画面で操作をしながら便利さを体感できる講習を実施
* 店部にデモ用PCを送り、講習を受けたものが周りに指導
* => 拍子抜けするほどスムーズなリリース
* 取り組んだこと
* 店部ヒアリングに開発担当者も参加し、直接店部の声を聞いた
* 要件定義フェーズでは、業務/開発が机を並べて双方の理解を含めた
* 朝会、夕会で情報交換、進捗を共有した。
* 「伝えたいことが伝わらない」などの問題はたくさんあった
* プロジェクトのメンバーがどんどん会話すること。
* 大事な局面ではあって話をする。認識をあわせる。
* １つ１つ乗り越えてきた。
* プロジェクト参加者の一人一人が力を発揮した
* 開発現場でのUIへの取り組み
* 使いづらいものを作ろうと思っている開発者はいない
* なぜ
* ユーザビリティの導入
* ソシオメディア社の協力
* ヒューリスティック評価
* ユーザビリティテスト
* ユーザビリティガイドライン
* UI標準ディスカッション(全５回)
* 体制
* 200画面を超える
* オフショア、基盤開発を含め、5チームに分かれていた
* <= ユーザビリティを高めるために、UI担当という専門担当者は、開発側/ユーザ側でそれぞれ一名置いた
* 設計フェーズ
* UI標準の検討と策定
* 少人数で作業
* それまでの経験になるべく作用されないように少人数
* 店部ヒアリングの結果をまとめる
* UI標準書の策定
* <= 照会窓口を作り、フィードバックを得て、標準書の修正を繰り返した
* 開発担当者に意識を浸透させる
* 製造フェーズ
* UI部品と実装ガイドの提供
* UI部品とは・・・
* UI標準に従ってスタイルや振る舞いの統一した入力や出力等の機能を部品化したもの
* Flex/AIRでの開発
* 求められるユーザビリティを実現
* Webアプリでは求められるユーザビリティを実現できない
* 検討の結果 AIRになった
* テストフェーズ
* テストフェーズで発覚した問題点
* 設計書記載内容と、実際の振る舞いのギャップ
* 開発チームごとに振る舞いが異なっている
* 画面を横並びに見ると設計書では分からなかった差異が発覚
* 対策: テストの追加とテスト内容の充実
* サンプリングテスト
* 同じ担当者が代表的な画面についてテストを実施
* UI標準書の記述にようを実現しているか
* 同じ担当者が行うことで標準にそっているかを検証
* フリー打鍵テスト
* 外部設計担当者が自由に打鍵を実施
* 設計時の要件が満たされた上で、振る舞いがUI標準にしたがっているか
* 操作の組み合わせによるケース
* 業務要件として意識的にUI標準尾例外と、した操作について確認
* => 毎日不具合が積み上がっていき、寝られない日々が続く
* 標準からの妥協や、機能の変更もあった
* ユーザ／開発ともに「ユーザビリティの高いものを作ろう」という意識で一致していた
* 日付入力
* 業務要件により、全て和暦表示
* 11/18 => H21/11/18
* 11.18 => H21/11/18
* 2009/11/18 => H21/11/18
* ユーザがこれまで経験してきたシステムの入力の仕方がそのままつかえる
* <= 利用手引き参照の回数を減らす
* 入力完了してからエラー表示ではなく、入力時点でエラーをはじく
* 必要なキー以外は入力を無視
* 数値入力
* マイナスを入れると赤字
* 自動的に３桁カンマ区切り
* 整数部、少数部の最大桁制限
* 日付表示
* 西暦表示のツールチップテキストで、西暦を表示する
* 和暦と西暦のシステムが混在しているため
* <= ユーザからの強い要望で作られた
* 店名表示
* 店名表示のツールチップテキストで、店番を表示する
* <= 新しく入った行員をサポートし、本来の事務に集中させる
* 悩みに悩んだ機能がたくさん入っている
* ユーザの声
* 便利で使いやすい
* 「めっちゃべんりです」
* 見たい情報がすぐわかる
* バラバラだった情報が１つにまとまり、一回の操作で確認できる
* 問い合わせに素早く回答ができ、お客様に喜ばれた
* 提案、セールスがしやすい
* レスポンスが早く、ストレスがない
* 担当者も一人のユーザとして使ってみた: ちょー便利。課題も見つかる
* 今後の展開
* システムの定着推進
* 隔週で、便利な使い方をニュース配信
* 定期的に営業店に説明にまわる
* 今後の
* オペレーションまで一連操作可能
* セールス用画面追加
* 他システムとの連携
* 業務プロセス改革へ
