ランサーズでは自己学習の場として毎朝1時間程のもくもく会を開催しています。
もくもく会を開催しようと思ったきっかけは、こちらで紹介しています。
以下は今週の取り組みになります。
今週のもくもく会
谷
UXデザインの教科書を読んでいました。
ユーザビリティとは
- ユーザビリティは日本語では「使いやすさ」と言い換えられることが多いが、正確な訳語は「使用性」
- その製品の機能をユーザーが発揮させる為、どれほど容易に製品の操作を行えるかを表す用語
- ユーザーが使いやすいと感じる度合いではない
- サービスの品質を表す言葉であり、あくまでサービス側の概念
- UXの質を左右する要因としてユーザビリティがあり、サービスのユーザビリティが良ければ、ユーザー側のUXが良いものになる可能性が高い
ユーザビリティの定義
- UXやHCDの分野でほぼ標準的な定義となっているものが ISO 9241-11 による定義
- ISO 9241-11では、ユーザビリティを次のように定義
- 「ある製品が、指定された利用者によって、指定された利用の状況下で、指定された目標を達成するために用いられる際の有効さ、効率、および満足度の度合い」
- 以下のような主観的評価によって測定できる
- ユーザー作業の有効さ → 目標を達成する上での正確さと完全さ
- 効率 → 目標を達成する際に、正確さと完全さに費やした資源
- 満足度 → 不快さのないこと、及び製品仕様に対しての肯定的な態度
- UXは主観、ユーザビリティは客観なものであるのに、満足度は主観評価なので違和感がある
- 満足度の定義では「不快さのないこと、及び製品仕様に対しての肯定的な態度」となっていて、サービスに対する総合的な満足度とは異なった確度で、ごく限定的な主観評価を扱っている為
- これは現在、ユーザビリティの品質を測定する物理的な測定機がないことと関係している
- その為、人間を測定機と見立て、利用文脈を特定したうえで、実際に使用してもらい、その作業成績によって代用するアイデアが9241−11の考え方
ユーザビリティと利用品質
- ユーザビリティは、利用の結果による品質評価であることから「利用品質」と呼ばれることがある
- 現在、ユーザビリティには9241-11とは異なる定義も存在し、有力なものの一つに ISO/IEC 25010がある。
- このモデルでは、システム品質を「利用品質モデル」「製品品質モデル」「データ品質モデル」の大きく3つに分けている。
- ユーザビリティは、製品品質モデルに含まれる
- 9241-11では、ユーザビリティと利用品質は同等と捉えていたが、25010では、ユーザビリティをより客観的で主にインタラクションに関する範囲での品質としてとらえ、製品を利用する際の品質と分けている点が特徴
- ユーザビリティに関しては、モデルでは製品品質、利用品質を分けて入るものの表裏一体のものだということ
適切度認識性とユーザインタフェース快美性
適切度認識性
- 製品またはシステムが利用者のニーズに適切であるかどうかを利用者が認識できる度合い
- ドキュメント、チュートリアル、webサイトの情報提供まで含んだもの
ユーザインターフェース快美性
- ユーザインタフェースが利用者にとって楽しく、満足の行く対話を可能性にする度合い
- UIデザインの品質に踏み込み、「楽しさ」を指標に含んでいる点がこれまでにない特徴
目標達成とユーザービリティの考え方
- ISO 9241-11 および ISO/IEC 25010によるユーザビリティの定義は、いずれも「目標を達成」する際の有効さ、効率、満足度であるとしている
- 目標達成というユーザの行為を扱うのがポイント
- 人間の行動には、意識的行動と無意識的行動がある
- ユーザビリティは意識的行動において、ユーザーが目標とする状態を得る為に、サービスによって支援される目標達成の度合いであると考えることが出来る
- サービスのユーザビリティは、複数ユーザーの有効さ、効率、満足度を集計し、総合的に分析することで、定量的に評価できる
目標の階層性
- ユーザーの目標とは「ユーザーが意図した結果」を指す
- サービスを使うという視点だけに囚われてしまうと、機能を使うことがユーザーの目標のように感じてしまうが、サービスを使うこと自体は目標を達成するための手段であるはず
- ユーザーの目標には階層性がある(以下のようなイメージ)
目標:子供と一緒の時間を楽しみたい → 手段:子供と一緒に海までドライブする
↓
目標:子供と一緒に海までドライブしたい → 手段:車で海までスムーズに移動する
↓
目標:車で海までスムーズに移動したい → 手段:体験の良いカーナビを利用する
・・・
- ユーザビリティを計測するにしても、ユーザーの目標を適切なレベルで理解することが重要
目標達成におけるユーザーの指向性と満足感
- ユーザーとサービスの関わりの中には、必ずしも目標達成だけが目的でない場合もある。
- 例えば、居心地の良いベッドで寝るという行為は、寝るという目標の達成よりもそのプロセスの心地よさを重視していることになる
- デザインが気に入った腕時計を時間を知るという目標達成とは関係なく眺めるという行動を取ることもある
- HCDの研究を開拓してきた黒須氏は、ユーザの目標達成行動の種類3つに分類した
- 目標指向的行動 → 目標達成がメイン
- プロセス指向的行動 → 目標達成の過程がメイン
- 状態指向的行動 → 目標達成行動ではなく、純粋にその状態にあるということがメイン
- それぞれの行動に関して結びつく感情は
- 目標指向的行動では「満足感」
- プロセス指向的行動では「楽しさ」
- 状態指向的行動では「心地よさ」
人間中心デザイン(HCD)プロセスについて
- 人間中心デザイン(Human Centered Design:HCD)プロセスはUXデザインを実践するためのプロセスとして活用されるデザイン理論
- 特定のデザイン対象分野に限定されず、あらゆるものに当てはめられるプロセス
- UXデザイン = HCDではないが、HCDプロセスに沿ってUXデザインを行う理由はいくつかある
- HCDプロセスが示す開発アプローチの実施が、ユーザー観点からの手戻りや失敗を極力防げるから
- 多様な背景やスキルを持つ開発メンバーの基準となると同時に、同じ目標を持つ為の基盤となるから
- サービスはユーザーの為に存在する為、開発もビジネスもユーザーや顧客の為にあるべきだが、どんなユーザーなのか、何を求めている顧客なのか、開発メンバー間で共有の理解がないまま開発が行われることが少なくない
- HCDプロセスは、ユーザーが求めていることを明確にし、開発に関わる誰もが目標にする基盤として機能する
- HCDは、造り手がユーザーのことを理解するという二次的理解を前提としたデザイン
- HCDプロセスでは、ユーザーを理解して開発する過程を定義してるが、どれほど深くユーザーを理解できたとしても制作したものがユーザーの求めるものとあっていないものになってしまうことはある
- その様な自体を避ける為に、直接ユーザーに確認すれば良い。
- ユーザー自身に確認できないときもユーザーを調査した時に把握したユーザーの体験価値や本質的ニーズに立ち戻って確認する
- これを常に確認しないと、知らず知らずにユーザーが求めているものから離れていってしまう
- その為、HCDプロセスでは、ユーザーの体験価値や本質的ニーズを常に確認し、問題があれば修正するといった反復修正が必ず含まれる
ISO 9241-210が示すHCDプロセス
- ISO 9241-210 の正式なタイトルは「人間工学 – インタラクティブシステム人間中心設計」
- HCDの具体的とりくみ
- 人間中心設計プロセスの計画 ↓
- 利用状況の把握と明示
- ユーザーの要求事項の明示
- ユーザーの要求事項を満たす設計による解決案の作成
- 要求事項に対する設計の評価 ※1〜4を繰り返し ↓ 設計された解決案がユーザーの要求事項を満たす
4に至った段階で、1〜3の中で必要なフェーズに立ち返る
- PDCAと基本的には同じだが、PDCAのチェックは当事者の振り返りを意味することがあり、HCDのプロセス評価はあくまでユーザーによる評価、または、ユーザーを念頭に置いた評価
HCDの6原則
- 設計がユーザー、タスク、環境の明確な理解に基づいている
- ユーザーが設計と開発全体を通じて参加している
- 設計がユーザー中心の評価により実施され、洗練されている
- プロセスを繰り返している
- 設計がユーザエクスペリエンス全体に取り組んでいる
- 設計チームが学術的なスキルと視点を取り組んでいる
- 理想的には、ユーザの利用文脈を把握するところから始める
- 利用文脈が異なればユーザビリティや製品評価は大きく異なる
- ユーザーには直接参加してもらった方が良いものの予算などの関係で参加してもらえない場合、ユーザーの利用文脈を把握し、ユーザーの立場で評価することが必要
- プロセスを繰り返すことが原則 → 繰り返す前提の開発計画が必要
- HCDプロセスを適用する目的は良いUXを実現すること、想定されるUXの全体を対象とした開発でなければ、良いUXの実現はそもそも難しい
- HCDのプロセスの目的を端的に言い表すと、ユーザー要求に適合したUXの実現
- 実際の現場では、ユーザー要求事項が技術やビジネス都合で実現されなくなってしまうことが多い
- 9241-210では、こういったトレードオフが発生する場合、UXの質を落とさない、あるいは、高める為に必要なの解決策を導き出すために有効なのは、多様な専門分野のメンバーの参画である
磯野
- デザインのお勉強
- いろんなサイトを見てみたけど、心が折れそう
- みんなデザインが上手すぎ
- 谷さんお薦めサイト
- 絵の才能とか昔からなかったし、しゃーないかという気持ち
- 社内のデザイナーたちに、デザインする時どういう思考をしてるのか聞きたい
- いろんなサイトを見てみたけど、心が折れそう
- Laravel(API) x Vueの環境構築をする
- LaravelとVueで環境分けるの良さげ
- 1つのディレクトリで両方管理すると結構煩雑になりがち
- 単一責任はやはり良い。。
- Docker作るのめんどくさすぎたので、ローカルPHP, MySQL, Nodeで完結
- LaravelとVueで環境分けるの良さげ
- MentaのTailwindCSSバージョンアップ
- 公式ドキュメント様様
- 今v1なので、早くv3にしたい所存
- キーボードはHHKBがいいぞ
- エンジニアなら無刻印だよな!(少数派)
- 雪モデル素敵
太田
- 最近はAdobe Premiere Proを使った動画編集のお勉強してます
- もともとAviUtlを使ったMAD動画作成は少しやってた
- 最近勉強中
- オーディオエフェクト
- ビデオエフェクト
- ビデオトランザクション
成田
- 待望の「プロダクトマネージャーのしごと」が発売されたので読み始めました(まだ1章)
- これからプロダクトマネジメントを目指す人へ伝えたい責任3つが意外だった
- メンバーのベストを引き出す
- 直接利害関係のない、自チーム以外の人と一緒に働く
- 曖昧さに立ち向かう
- 自分はPdMだけでなくPMも一緒にやるタイプであるため、当たり前と思ってみていたが、PdMだけの職責で働いている人はこの感覚をまだ持ててない人は多そうだし、構造的にそうしてしまっているんだろうなと気付かされた。
- 良いプロダクトマネージャー、悪いプロダクトマネージャーの話がおもろかった
今週の報告は以上です。
週毎に取り組みを掲載していきますので、ご期待下さいませ。