アプリケーションの「使いやすさ」は、そのアプリケーションの使われ方、導入効果を左右します。導入効果を高める、アプリケーション開発の過程で、機能だけでなく「使いやすさ」を作り込み、かつ、一般利用者による評価をうけることが重要であると考えます。
インターネットで公開されているWEBページと違って、企業内の業務アプリケーションは、仕事で使われるのでたとえ少々使いにくくてもユーザーに使ってもらえます。使いやすい、使いにくいの指標の設定は簡単ではないため、使いやすさの実現を全面に出して、それを目標とすることはあまりないように思います。
しかし、グループウェアと呼ばれ、企業内の情報共有を目的とするアプリケーションには、掲示板やノウハウ集など、使わないでも仕事が済ませられるものもあります。
また、使わずにおれないアプリケーション、例えば、交通費精算、受注報告書、週報などの場合でも、いつそれを使うかが、どのように使うかユーザーの裁量の余地の大きいものがあります。
グループウェア、その上で構築されるアプリケーションの大目的には、
１）業務の効率化、コスト削減
２）業務、意志決定のスピードアップ
３）ペーパーレスの実現
４）部門をこえた情報共有による集合知の実現、強化
のようなことがありますが、
使いにくいアプリケーションと使いやすいアプリケーションでは、これらの大目的の達成度が大きく異なってくるのではないでしょうか、
使いにくい場合、
例えば交通費精算、受注登録、稟議など、入力が面倒でその作成・申請が遅れがちで、期限のぎりぎりまでそれが申請されないということになります。また、入力内容にも間違いが発生しがちで、再申請などが多くなりがちです。
申請が集中すると、システム負荷が大きくなり、より強力なサーバ＾が必要となり、それを処理する業務担当は、時間外勤務なども発生することもあるでしょう。コスト削減効果が小さくなります。
よりはやく経費状況、受注状況を把握したい、意志決定をはやくしたいというスピードアップ効果も弱くなります。
たまに使うようなアプリケーションでは、そうやってそのアプリケーションにたどりつけるかわからなかったり、使い方がよくわからなかったりするため、マニュアル印刷で使い方を確認する人が多く出てきます。あるいは、自分の申請内容の確認にも手間がかかるのであれあば、申請内容を都度印刷する人も出てきます。ペーパーレス効果が薄くなります。
ノウハウ集、提案書データベースなども、アクセスが難しいと、それを見る人、情報を登録できる人が少なくなり、登録の手間がかかれば、登録も少なく、登録内容も薄く最小限で付加価値の小さいものになりやすくなります。
情報登録数、情報の被利用度にインセンティブをもうけても、結果として、積極的な情報登録は実現されず、その利用も少なく、集合知の実現効果は、小さくなります。
使いやすい場合、
各種申請書類の作成が手軽におこなわれ、したがって、利用は集中せず、
わかりすいので入力間違い、再申請も少なくなり、
申請から承認、バックエンドシステムへの反映もはやくなり、
マニュアルの印刷が減り、
情報利用が増え、情報登録も盛んになり、
などが期待できます。
アプリケーションの利用者は、多くの仕事をかかえている中で、個々のアプリーションを使うわけですから、必要なとき、それに迅速にアクセスして、そこで効率的に参照・入力できるようにアプリケーション単体、アプリケーション群、ポータルが作成されることが求められます。
これを実現するには、個々のアプリケーションの特性として、「操作の手間が小さい」こと、各場面で必要に応じてコンテクチャルなヘルプ、説明を得られること、画面で要領よく情報が得られ、ごちゃごちゃしていないことなどが望まれます。
また、アプリケーション群としても、操作性・表示の統一性、個々のアプリケーションへのナビゲーションの簡易化をはかる必要があると思います。
使いやすさは、利用者によるアプリケーション評価です。使いやすさについて、一般利用者によるチェック・感想を受けることがもっとも明快な確認方法と思われます。しかし、協力を得て、率直な感想をもらっても、そこでどう対応できるか、難しいところがあります。私自身、これまでの開発プロジェクトを振り返っても、アプリケーション開発の途中で一般利用者による評価を受けたことはありませんでした。システム部門、アプリケーションの主管部門の業務関係者、開発者間での検討・評価だけでプロジェクトがすすみ、開発スケジュール・予定コスト内での機能の実現、使えることが第一になり、アプリケーションが実際に一般利用者によって使われる際の使いやすさが大きな関心事になることはなかったように思います。
ノーツのアプリケーションに限定した話ではないのですが、おそらく、いったん、開発プロジェクトが始まってしまうと、システム化やアプリケーション構築のそもそもの大目的は棚上げされて、何を作るか、どのように作るかに関心が移ります。要件定義に対応した総合テスト、基本設計に対応したシステムテストはプロジェクト内ですが、システム企画に対応したシステム評価は、プロジェクトの外です。そして、システムがいったん導入されると、多くの場合、システムを直すよりシステムに慣れろということになりがちです。
基盤であるノーツのレベルでも、10年くらい前は、評判も悪くはなかったと思うのですが、いつからか、使いにくいといわれることが多くなったように思います。ノーツ以外のシステムも変化が進み、WEBシステムの操作性、表示が改善されてきた中で、十年一日で使い続けられたノーツ、作り続けてきたノーツアプリケーションが使いにくいと評価されるようになってきたのは必然です。それがシステム効果を落とすことになっているとしたら、見過ごせません。
使いやすさは、アプリケーション（群）の特性と、利用者の期待、知識、関心、ITリテラシー、利用状況の間で決まります。
どんな特性を作り込みテストするか、一般利用者によるチェックをどう受けるか、引き続き、使いやすさの実現に向けて整理していきたいと思います。