業務システムのユーザビリティ

世間では、ユーザビリティといえば、プロダクトのUIやWebサイトに関連した話題ばかりが取り上げられます。しかし、ユーザビリティを改善することで最も効果が得られやすく、かつ、実はユーザビリティの改善のための作業を行いやすいのが、業務システムの分野だろうと僕は感じています。

ユーザビリティの改善によって、

  • システムの利用効率を上げる
  • 利用のわかりにくさや利用の仕方の誤認を要因とする誤操作や誤入力を減らす
  • エンドユーザーが利用時に不満を感じるところを削減してシステム利用に対する精神的負担を軽減する

などが実現できれば、業務全体の効率や、システムを用いて行う情報の入力率を高めて、開発するシステムに期待する効果をあげやすくなると思います。ほかの場面ではその拡大使用を懐疑的な目で見ていいのではないかと思われる、いわゆるテイラーシステムもこと業務という本来それが用いられはじめた場面においては依然として有効なんだろうと思います。

業務システムのユーザビリティと業務効率・データの入力率

元々、仕事で使われる業務システムなどは、エンドユーザーが喜んで使うものでは決してなく、使わずに済めば越したことはないし、業務上、どうしても使う必要があるのなら、可能な限り、簡単にスムーズにその作業を終えたいと感じる類いのものです。

もし入力の作業が著しく面倒なシステムであれば、最低限必要なものだけ入れて、本来は入力すべきものを入力せずに誤魔化してしまうこともあるでしょうし、誤操作による間違った入力やあいまいな理解によって生じる意図しない情報の選択や入力なども起こりえます。そうなると、システム開発時に期待したデータの入力率やデータの精度は得られず、高いお金を払って導入したシステムが期待したほどの効果を得られないなんてことは本当によく耳にする話です。

ユーザビリティを向上するために使われる人間中心設計プロセスの考え方を導入して、使えるシステムに近づけられるなら、業務システムの開発を委託するクライアント側も、開発を行うSIerなどシステム開発者の側も喜ばしいことだと思うのですが、どうなのでしょう？

実際には、最初に書いたとおりで、あんまり業務システムのユーザビリティの向上のために具体的に何かしたって話は聞かないですよね。
これには僕たちのようなユーザビリティに関わる仕事をしてる人間がちゃんと伝えていなかったっていうこともあるでしょう。そう感じたので、このエントリーを書いてみたわけです。

じゃあ、具体的にどのような方法で業務システムのユーザビリティは向上することが可能なのでしょう？

システム開発に人間中心設計プロセスをあてはめる

もう1つ、業務システムにユーザビリティ向上のデザインプロセスを導入したほうがいいと思うのは、いわゆる人間中心設計プロセスと呼ばれるISO13407のデザインプロセスが、本来システム開発にこそ相性がよいと思うからです。

ISO13407の人間中心設計プロセスというのは、こういうものです。



システム開発に即して考えると、それぞれの工程は以下のように理解できるでしょう。

  1. 人間中心設計の必要性の特定：システムを開発することでどのような変化を実現したいかという開発目的、あるいは、その実現のためにはどんなシステムが必要なのかのヴィジョンを描く。
  2. 利用の状況の把握と明示：現状、開発目的に相当する業務で用いられているシステムあるいは業務のしくみは具体的にエンドユーザーによってどのような方法・状況で行われているかを把握する。
  3. ユーザーと組織の要求事項の明示：現行の業務システム・フローはエンドユーザーにどのような不満や非効率な作業を強いているか、また、それによってどの程度の業務効率に悪い影響が出ており、それを組織はどのレベルまで改善したいか。また、具体的な業務プロセス上、影響が大きいのはどの工程なのかを分析する。
  4. 設計による解決案の作成：分析によって導かれた具体的なエンドユーザーの不満や非効率、業務プロセス上の問題点を解決するためのシステム案・UIデザイン案を作成する。
  5. 要求事項に対する設計の評価：作成したUIデザイン案、システム案を実際の業務にあてはめた場合、期待する効果が得られそうか、あるいは、新たなデザインがこれまでにない別の問題を生じることはないかを検証する。

これだけ見ると従来のシステム開発の流れとそれほど大きな違いはないと感じられるのではないかと思います。「利用の状況の把握と明示」から「ユーザーと組織の要求事項の明示」の流れなどは、エンドユーザーへのヒアリングや現行システムの分析などを通じて行われる業務分析や要件定義の流れと大きく違うものではないでしょう。

さらにいえば、要求開発などの上流工程を重視した開発プロセスや、アジャイル的なシステム開発とは特に相性がよいだろうと思います。

人間は間違いを犯すもの。間違うものだと思ってデザインしなくてはいけない

ただ、人間中心設計が従来のシステム開発と異なるのは、このデザインプロセスにおいて用いる手法やその手法を用いる際の「人間」というものの捉え方の違いでしょう。

まず、人間中心設計は基本的に「人間は間違いを犯すもの」という捉え方をします。間違いやすい傾向があるなら間違える想定をしたデザインをしないといけないと考えます。人間の誤解やミスなどを想定せずにデザインして間違いが起こったら、それは間違える人間が悪いのではなく、それに配慮していないデザイン・システムが悪いと考えます。

理解／誤解は状況・コンテキストのなかに埋め込まれている

ルールに従って行動するには、ルールを正しく理解する必要がありますが、ルールを正しく理解させること自体、容易ではありません。それはルールを正しく理解する気がないからではなく、理解しようとするからこそ、間違えた理解をしてしまう場合だってあるのです。

ユーザビリティにおいては状況・コンテキストというものを重視しますが、それはユーザーの理解（誤解も含めて）というものは、ある固定化されてあるものをそのまま、どんな状況下においても、そのまま受け止めるという形で行われるのではなく、その状況およびある環境下におけるコンテキストとともに受け入れられるからです。

おかしなかけ算を解いてしまう小学生

これについては、川床靖子さんが『学習のエスノグラフィー』でおもしろい例を出しています。
日本とタンザニアの小学生を対象にした実験なのですが、算数の問題を何問か出して、そのなかにおかしな問題を混ぜておいて、それを小学生がおかしいと指摘するか、おかしいと思わずにそのまま説いてしまうのかという実験です。

具体的に、おかしな質問とはどういうものかというと、以下のようなものです。

  1. マンゴが4個、オレンジが7個あります。かけるといくつでしょう。
  2. 体重6kgの小学生が8人います。全員で何kgでしょう。
  3. 5ピース入りのペパーミントを9個買いました。何シリングになるでしょう。

1.の問題はナンセンスな問題です。2.の問題は非現実的な数値の問題。3.は条件不備の問題です。
出題時の条件によっても、日本とタンザニアでも異なるのですが（詳しくは本を読んでください）、基本的には3.の条件不備の問題におかしさを指摘する生徒がいるくらいで、ほとんどの生徒が1.や2.の問題に関してはおかしさを指摘せずに普通にかけ算してしまうそうです。

ただ、2.の問題にある「体重6kgの小学生っている？」って聞けば、そんなのいるわけないと笑うそうです。それでも、そう訊いたあとにおなじ問題を出してもやはり、おかしいとは指摘せずに問題を解いてしまう。その理由を聞くと「おかしいとは思ったけど、算数の問題だからそういうのもありかな」というのだそうです。

つまり、通常のコンテキストではおかしいと感じることが、算数の問題というコンテキストではおかしいと思わなくなるということです。

ビジネスには日常と異なるコンテキストが複数ある

このように人間の理解というのは、あることが正しいか間違っているかがあらかじめ決まっているのではなく、コンテキストに応じて正しいか間違っているかも決まるケースがあるのです。ビジネスのコンテキストなどは特に日常のコンテキストとは大きく異なる場合が多々ありますし、1つの組織内のルールでも異なるコンテキストでは違う理解をしなくてはならないような言葉の使い方や業務手順なども少なくありません。

川床靖子さんは『学習のエスノグラフィー』のなかで、リテラシーとは単に読み書き能力を示す言葉ではないとしています。たとえば、契約書や請求書を理解するには単に読み書き能力があればよいわけではなく、契約書を読んだり、請求書の内容を理解するための「契約」「請求」というビジネスのコンテキストのリテラシーも同様に必要であるという例を出しています。

リテラシーとは、ある文書が埋め込まれている実践に参加することによって、あるいは、ある現実の社会的関係の中でその一部を占めることによって形成されるのである。
川床靖子『学習のエスノグラフィー』

まさにユーザーの「利用の状況の把握と明示」という工程においても、このような意味で、あるデータが「埋め込まれている実践に参加する」あるいは「現実の社会的関係（特定の組織における現場）の中でその一部を占めること」でデータがいかに情報化されるかという形成の場面に立ち会うことが必要とされるのです。

ユーザーの業務をそのコンテキストともに把握しなければ、ユーザーがどんな状況で、どのような理解をしたうえで、業務を具体的にどのような行動でデータを情報として処理しているかというところまではみえてきません。そこまで把握しなければあるデータを入力・選択させるために、どのような記述により入力・選択の指示を行えばよいか、どのような表現やふるまいを設計することで、ユーザーの誤解やミスを軽減できるかを把握することはできないでしょう。

状況・コンテキストを含めた観察、分析の必要性

こうした状況・コンテキストをひっくるめたユーザーの「利用の状況の把握と明示」のために、人間中心設計プロセスでは観察を主体とした「ユーザー調査」を行います。いわゆる現場においてユーザーの仕事における行動を観察・追体験させてもらうことでユーザーの業務を理解するエスノグラフィ（民族誌学）的な方法での調査です。エンドユーザーが仕事をしている場面に、新人がOJTするように弟子入りしてエンドユーザーの業務を理解するのです。

また、「ユーザーと組織の要求事項」において調査した内容を構造的に分析するためには、「5つのワークモデル」を用いた行動分析を行います。これも単にエンドユーザーの業務フローや利用するデータを把握するだけでなく、そうした業務が行われる組織の文化やルールがどういったものか、業務を行ううえで影響を与える人にはどんな人がいて、どのように業務が受け渡されるのか、また実際に業務が行われる才の物理的な環境や使用されるメモ書きや電話などでの連絡があるのかという状況・コンテキストも明らかにするための、構造分析です。

こうした手法を用いた作業プロセスを踏むからこそ、システムのユーザビリティの向上が実現できるのです。

データを情報に変換しなければ情報システムにはならない

これまでのシステム開発って多かれ少なかれ、データ・オリエンテッドなところがあると思うんです。ただ、データは単独では情報にはなりえません。データを情報化するには、やはり、それを扱う人間やそれが利用される状況・コンテキストと同時に見ないとデータが情報になることはないと思います。とうぜん、情報システムなわけだから、データをそのままデータのまま扱っているようでは、それが人間にとって有益なものにはなりえないと思うんですね。

実はここが従来の業務システム開発ですこし足りなかった部分なのかなと思います。
業務システムの開発にたずさわれている方、ぜひ一度、システムのユーザビリティということを考えてみてはいかがでしょうか。

　

関連エントリー

この記事へのコメント

コメントを書く

この記事へのトラックバック