8月26日（金）に溜池山王の三菱総合研究所にて行われた、
「業務システムのユーザービリティ向上セミナー」に参加してきました。
■08月26日（金）
■業務システムのユーザービリティ向上セミナー
■株式会社三菱総合研究所 ４階 大会議室ＣＤ
いつも思うのは、
ユーザビリティのセミナーにくると、
そのサイトの地図ページのユーザービリティが悪い事に気づいてしまう、
場所がわからない、
本当なら駅から直結で来れるはずなのに、
道順もわからず、地上からiPhoneの地図をたよりに目的地へ。
会社の地図を作るひとは、
必ずフィールドワークをしましょう。
係の人が、
「前の方へ！」と言うので、
遠慮なく、最前列にて聴講。
業務システムとユーザービリティ-システム企画・開発者が知っておくべき3つのポイント
千葉工大 安藤昌也 准教授
■自己紹介
・コンサルタントとしてー「ユーザーを理解し、翻訳する仕事」
・産業技術大学院大学 履修証明「人間中心デザイン」
■ユーザービリティ（usability）
業務システムでユーザービリティを確保するために何がすればいいのか、
具体例を出しながら、説明します。
■あなたのユーザービリティの認識は？
・操作画面をわかりやすいように配置すればいいんでしょ？
・とりあえずユーザビリティテストをやっておけばいいんでしょ？
・お客様の言う通りに作っていればまず問題ないんでしょ？
→今日はこのレベルから脱出していただきたい。
■ユーザビリティとは？
・ユーザビリティ→「利用品質」としての使いやすさ
→ISO9241-11にて定義されている。
ある利用状況（Context of use）の下での利用における
・有効さ（effectiveness）
・効率のよさ（efficiency）
・満足度（satisfaction）
※システムのユーザビリティは「利用品質」に置き換えることができる。
※物の特性
※利用状況のなかには、物理的環境や目標・ゴールも概念に含まれる。
※イライラしない。satisfaction（充足度）と訳した方が意味が近い。
■利用状況とユーザビリティ
・普段は何の問題がなくても、ユーザ自身の変化や利用状況の変化によって
突然使いにくくなることがある。
例：指を折ってしまったら、箸が使いにくくなる。
キャリーバックを持っているときは階段が使いにくい。
※”ある状況”における「有効さ・効率のよさ・満足度」が大事。
利用状況が正しく定義されていなければ、ユーザビリティも正しく測定できない。
（ここがなかなかできないから、色々問題になってくる）
■ゴール達成モデルとユーザビリティ
・銀行の窓口でお金を振り込んだ場合。
→紙に必要な情報を書いて、窓口に出すだけ。
↓
・ATMで振り込んだ場合。
→窓口に比べて、ステップが多く、振込はできたけど、疲れてしまう。
（満足度は低い）
■ユーザービリティと人間中心設計
・人間中心設計は、ユーザービリティを実現するために必要な活動を、
システム設計プロセスに組み込む「戦略」
▼ユーザビリティを実現するためには・・・
・利用状況をあらかじめ定義する。
・ユーザーが「使いやすい」と感じる画面デザインを考える
・ユーザビリティが実現できるかをテストする。
・もしテストで問題があったら、修正する手順を考える。
↓
場当たり的にはできない・・・・
そこであらかじめ設計プロセスに組み込んでおけば、
より効率的にユーザービリティを高めることができる。
※ユーザービリティを高めるためには、人間中心設計というプロセスを取り入れるのが良い。
■人間中心設計プロセス ISO9241-210による
・利用状況の理解と明示
・ユーザの要求事項の明示
・ユーザの要求事項を満たす、設計による解決策の作成
・要求事項に対する設計の評価
■電子政府ユーザービリティガイドライン
・ユーザビリティは企画、設計・開発、運用、評価という、開発プロセス全体で実施する。
・ガイドラインでは、特に企画段階でユーザビリティを設計しておくことの重要性から、
極めて詳細は企画の手順を示している。
PDF:http://www.kantei.go.jp/jp/singi/it2/guide/security/kaisai_h21/dai37/h210701gl.pdf
■ISO9241-210:ISO13407の改訂
2010年に改訂した。
・HDCのプロセス
・UXについて定義した。
■ISO9241-210：ユーザエクスペリエンスへの転換
ISO9241-210では、HCDの原則としてユーザエクスペリエンス（UX）の実現を挙げ、
「ユーザビリティの実現」からさらに進化した。
「人間中心設計の目的は、設計プロセス全般にわたてUXを考慮することにより、
よいUXを実現することである」
ユーザーエクスペリエンス（UX）
製品やシステム、サービスの利用、および/もしくは予想された使い方によってもたらされる
人々の知覚と反応。
※わかりにくいが簡単。
■UXとユーザビリティ
今までは、「ユーザーを品質測定機として満足度を測っていた」が、
今回の改定で、「使う人が使いやすいか、使い続けたいか」なども考慮しないといけないと、
はっきりした。
■システム企画・開発者が知っておくべき３つのポイント
■ポイント理解のためのエピソード
ある通信系の企業が、担当者が手作業でやっていたことを、
システムが自動で一気に解決する画期的なシステムを構築した。
↓
しかしほとんど使われてない。
↓
現場で調査したところ、
陥りがちな３つのポイントが開発プロセスで欠落していた。
原因１ ユーザーの業務や意識への理解が不十分
→担当者がそのシステム自体を信頼できなかった・・・
システムが自動化したものをわざわざチェックしていた、
システムは使っていたが、全然便利になっていない・・・
原因２ 要件定義の段階でユーザーを見ていない。
→新機能の技術的実現が優先され、現在の業務はシステム部が作成した
資料に基づいて作られた。
原因３ そもそもユーザビリティテストを実施していない
→総合運転試験は実施されていたが、ユーザビリティテストが開発プロセスのなかで、
実施されていなかった。
▼業務システム開発で陥りがちな誤りへの３つの指摘
(1)開発するシステムの本当のユーザーは誰なのか？
(2)ユーザビリティテストをやればいいと言うものではない。
(3)業務のユーザビリティとシステムのユーザビリティは違う。
▼開発するシステムの本当のユーザーは誰なのか？
→実際のユーザーは現場の人なのに、
開発の場合は「Sier → 情報システム部」で行われることが多く、
情報システム部の人間は「真のユーザー」のことを理解できていない。
人は道具を補うだけの柔軟性を持っている、
どんなに悪いシステムでも工夫して使いこなしてしまう、
その工夫や知識は、現場のユーザーを理解しないとわからない。
現場の人は、毎日の業務でやっているので、無意識でやっていることが多い、
だからまる一日、現場で調査をする必要がある。
→エスノグラフィックアプローチ
Sierの開発部は情報システム部を「お客さん→ユーザー」と思っている場合がある。
※お客さんと読んだ時点であやしいかも・・・
※真のユーザーには情シスも含まれる。
▼ユーザビリティテストをやればいいと言うものではない。
システム開発の場合、ユーザーテストは開発の終盤で行われることが多く、
人間中心設計のプロセスに沿っていない場合が多い。
・ユーザービリティテストは最後に行うものではない。
・ユーザービリティテストをする前には、「ユーザーの要求事項」が調査できているか？
▼業務のユーザービリティとシステムのユーザービリティは違う。
システムのユーザビリティは「業務のユーザビリティ」の中にある。
→システムの使い勝手は、ユーザーとその業務を良く理解できていなければ
作り込むことはでいない。
業務システムの場合、「利用状況」のなかに「文化や権限・意識」などの
ハイコンテキストのものが含まれる場合がある。
■望ましい業務システムとは
・要件定義の前にフィールドワークを実施し、真のユーザーの業務の利用状況を十分把握し、
ユーザー要件を明確にしておく。
・開発の早い段階でユーザーに参加してもらい、修正を繰り返しながら開発をしていく
（手戻りではないです。）
・人間中心設計プロセスの考え方を共有し、”繰り返し設計”を含んだプロジェクト計画を
立てる。
■UX発想のシステム開発に向けて
▼システム開発による価値創造
ビジネスのサービス化により、ユーザがシステムといかに良い関係を築けるかが、
提供価値になりつつある。
（システムへの信頼度が増した。仕事のやる気が高まった。
使い方を工夫するようになった。）
▼使いやすいシステムからありがたいシステムへ。
システム開発の評価軸を変えることで、全く新しいソリューションサービスを提供できる
チャンスは大きい。
●使いやすいシステム = ユーザビリティ
・あくまでも機能提供が前提。だから、発注担当者が顧客。
・評価の指標は、機能の有効さ、利用の効率。
●ありがたいシステム = ユーザエクスペリエンス
・「あっ、これいいな」と感情を重視。”真のユーザ”が顧客。
・評価指標は、システムの信頼感、利用意欲、工夫意欲。
→ユーザの”意欲向上”は、顧客企業の創造性の向上を促す重要な提供価値
意欲が高まると、システムへの不満が低下する効果もある。
■本日のまとめ
・業務システムのユーザビリティを実現するためには、人間中心設計は手段である。
・業務システムのユーザビリティを高め、信頼感を与えるためには、開発の初期段階で、
真のユーザーの業務理解とユーザー要件の獲得に力を入れるべきである。
・システム開発の提供価値は、機能の実現だけでなく、ユーザの利用意欲や変革意識など、
UXがもたらす新しいビジネス価値へとパラダイムシフトしつつある。
より高いUXの実現に向けて、チャレンジしてほしい。
■質疑応答
Q.ユーザーテストの実施がやはり難しい。
（実際に動くものがないと・・・）
A.ペーパープロトタイピングとアクティングアウトをやりましょう。
Q.熟練度の違いをどうシステムに反映させるか？
A.ヒントになるのはインタビュー
熟達度を言語化するのは難しいので、
熟達者から未熟者へ教えることで、
熟達の歴史やポイントなどを言語化する。
事例から見るユーザビリティ向上に向けた取組み―超上流から運用開始後の評価まで
三菱総合研究所 人間・生活研究本部 大橋毅夫 主任研究員
■はじめに?業務システムにおける開発要件の一般的な特徴
・力の入れかたが違う。
・デザインを通じて、企業らしさを伝えることができる。
・新入社員を育てる目的もある。
・ユーザが参加することの意義が大きい。
■業務システムのユーザビリティ向上のためのアプローチ
▼ターゲットユーザーを”洗い出す”
ターゲットユーザーを洗い出すのは簡単だが、
そのユーザーがどうシステムを使うのかを、調査するのが重要。
●現場ニーズをリクワイヤメントに変換する！
・現場の声を聞く必要がある。
・フィールドワークで行動観察する必要がある。
※思いを言葉にする。のが難しい。
→フィールドワークの必要性
●ユーザニーズの把握例?日記法（１）
・比較的簡単に実施できる利用状況の把握方法。
▼計画や設計段階でも”評価する”
1. 従来のシステムへの基本的な姿勢と新システムへの期待の把握。
2. 早めの可視化による現実感と安心感の醸成
●計画や設計段階での評価例
・ペーパープロトタイピング
・ラピッドプロトタイピング
・モックアップ
・グループインタビュー/アンケート(主観評価)
・ヒューリスティック評価（エキスパート評価）
・オズの魔法使い（画面遷移の評価）
※批判をしてもらいたいわけではない。
▼開発プロセスにユーザビリティ評価の”仕組みを組み込む”
・開発の計画立案や予算確保の段階から、ユーザビリティ評価のプロセスを考えておく。
■３つの品質でユーザビリティを高める
内部品質
外部品質
利用品質
■外部品質/内部品質のチェック
ISOで決められていて、実物がなくても品質のチェックが出来るようになっている。
■ユーザビリティを考慮したシステム開発導入効果の明示
社内の説得材料になれば・・
■終わりに?これからのユーザービリティは「長期的使用感」
・手に取る前から使ってみたくなる。
・使い込むほどに馴染む
・自分とともに成長・進化する。
・所有していたことすら満足感を与える。
ユーザビリティ評価手法UxDuxのご紹介
三菱総合研究所 情報技術研究センター 飯尾淳 主席研究員
■ユーザービリティ評価手法UxDuxのご紹介
▼情報システムにおける「合成の誤謬」
会社のシステム開発で陥りがちなワナ。
→合成の誤謬：小さな問題解決を図った結果、全体では悪い結果になってしまうこと。
▼時代はユーザービリティからUXへ。
クルマの例
→高級車と一般車では、操作性や機能は同じだが、”所有欲や運転の楽しさ”が違う。
▼ユーザビリティの優劣がもたらすビジネス遂行上のリスクとベネフィット
例：ジェイコム株大量誤発注事件
▼使いにくいシステムが生まれる原因
・システムの発注者と利用者が異なる。
・投資効果を評価できないからユーザビリティ向上に投資できない
▼インシデント分析に見るユーザビリティの影響
・ある業務システムに関するインシデントを分析
社内事務処理ミスがダントツで多い
→ユーザビリティ向上で解決できる。リスクヘッジに有効。
▼UxDux
・チェックシートベースのシステム評価手法
・7分類108個の項目
・項目が多いので、Lite版も作ってます。
全体質疑
Q.UXの主観的なものをどうやって対応すればいいのか？バラバラじゃないの？
A.一般論として。意欲が作用する。（自分の能力の自己認識。知識）
バラバラなものを多数決などでまとめるだけではダメ、
どんな人がどんな評価をしたか調査することも必要。
Q.インタビューでどこまでヒアリングすればいいのか？
A.フィールドワークをする理由は、全部をやることではなく、
何が一番大事なのか、最大公約数を見つけ出す。
何が一番大事か確認するため調査する。
Q.3つの利用品質の利用品質の満足度を図る方法の実例があれば。
A.満足度の部分だけを取り上げて図ったりはしていない、
ユーザーがどうゆう言葉で評価しているか注目している。
後記
全体的に安藤先生の講義がメインで、
三菱総合研究所のお2人の講義が実例紹介だったのですが、
あまりにも時間が短く、詳細は具体例までは聞くことができませんでした。
（守秘義務上の問題もあるかと思いますが）
私は業務システム担当者じゃないので、
満足しましたが、
実際の担当者さんだと、
もうちょっと詳細に聞きたかったでしょうね。
コメント