【ソフトウェア開発】【ソフトウェア品質】ユーザビリティ

昨今ではよくＵＩ／ＵＸなんて言われます。いやもう、そろそろ使い古されてきているような気もします。いつ頃から言われるようになったんでしたっけ？私はもうかれこれ３…４年くらいは耳にしているような気がするのですけど。開発に直接かかわらなくなった私でも聞くくらいなので、実際にはもっと前から言われていたのではないかと思います。

元はWeb開発などの世界で使われていたようですが、最近ではWebだけに関わらず、あちこちで耳にするようになりました。

ユーザーインターフェイス

UIは、ユーザーインターフェイスの略です。

「Interface：インターフェイス」は「境界面、接点」と訳します。つまり、UIは「人とモノ（主にデバイス）をつなぐ窓口のようなもの」だとイメージしやすいかもしれません。

『人との接点』…すなわち、

　目で見る
　耳で聞く
　鼻で嗅ぐ（…いやＩＴでは無さそう…）
　舌で味わう（うーん…ＩＴで以下略）

と言った、接点においてユーザーに余計な抵抗（ストレス）をなくすよう設計することが重要になってくると言うことです。

ちなみに、アプリケーション（プログラム）から見て、ユーザーの取り扱う「モノ」やそのデータ群をＵＩと言う扱いにされることがあります。たとえば、紙で書いたものや写真などをスキャナで取り込む場合は、紙（の中にあるデータ）をＵＩと呼ぶこともあります。

ユーザーエクスペリエンス

UXは、ユーザーエクスペリエンスの略です。

「Experience：エクスペリエンス」が「体験、経験」と訳せるように、UXは「人がモノやサービスに触れて得られる体験や経験」のことです。

たとえば、とあるWEBサイトを訪問したとします。サイトのUI（デザインやフォント、余白など）が見やすかったり、使いやすかったりしたら、どのように感じるでしょう？その感想や満足度のことだと考えてください。ユーザーが実際に体感した時の「使いやすさ」が求められています。

ユーザビリティはソフトウェア品質の１つ

私たち、Ｂ２Ｂ向けのＩＴシステムを開発するエンジニアは、Webだけに限らずいわゆる"プログラミング"のスキルや、性能などのパフォーマンスを重視しがちなだけに、よく疎かになるのが

　使用性（usability）

と呼ばれる要求品質についての観点です。

ユーザビリティ - Wikipedia

使用性は、昨今のソフトウェア、システム、アプリケーションにはとても重要な品質特性として扱われるようになりました。おそらくはスマートフォンの台頭によるものなのでしょうが、「より使いやすく」「より分かりやすく」に対して、ユーザー自体が貪欲に求めるようになってきたからだと思います。

使用性には、「理解性」「習得性」「運用性」「魅力性」「適合性」と言った副特性があります。

みなさんにわかりやすいところで言うと、スマートフォンのゲームアプリなどで、開始直後にはチュートリアルが行われるケースがありますよね。あれが、使用性のなかの「習得性」品質を体現した１つの手法でもあるのです。初めて扱うものにも、利用で困らないように"使い方"を学ばせることができるような製品になっているか？という品質特性ですね。

逆に、チュートリアルが無くても、視覚的にわかりやすく、説明もなしにすぐに理解できるようなＵＩになっていると、「理解性」品質が高いということになります。

製品の品質とは、「バグがあるかないか」という単純な評価基準ではないということを、私たちは理解しておかなくてはなりません。

デザインが良いか悪いかではない

かと言って、中途半端にデザインセンスなどがあったりすると、見た目ばかりに捉われて、実際に利用する人間をおいてけぼりにすることもよくあります。作っている側にしてみれば「ぇー…こんなにわかりやすいのに」と思うかもしれませんが、この考え方は完全にアウトです。

作ってる人は、コンセプトから使い方まであらかじめ頭の中で何度も反芻しているからこそ使えているだけであって、ユーザーにとって初見で全てが理解でき、使いやすいと思ってもらえるシステムを作るのは実に至難なことです。

そうした見た目だけにとらわれてデザインをしていると、忘れがちになるのが、この「使いやすさ」と言う観点です。

いくら"カッコいい"デザインでも、

　・独りよがり
　・ユーザーが迷子になってしまう
　・文字が小さくて読みづらい
　・必要な情報が探し出せない

などといった状態になってしまっていたとしたら、良いシステムとはいえません。どんなに能力の高い人であったとしても、それはただのプログラマーであって、クリエイティブさを売りとするエンジニアとしては失格です。

日頃作成している成果物の使用性は？

そしてこれらは完成された『システム』だけに言えることではありません。

　設計書を作成する
　プログラムにコメントを残す
　テストのエビデンスを残す、etc.

と言った「継承し、次に改造などのために引き継ぐ人のために」用意する中間成果物や作業１つ１つに対してさえも、同様のことが言えます（まぁ、こちらは品質特性「保守性」「移植性」に関する観点ですが）。

日頃の開発の中から

　読みやすい
　理解しやすい
　引き継ぎしやすい

といった、エンジニアのためのユーザビリティと言うものに対しても、気にすることのできないエンジニアは、ユーザーのためにユーザビリティ（使用性）を考え、検討することはできません。

さらには、そういった次の人のために"理解してもらえるような"中間成果物を、残さない、残したくない、残さなくて済むならそうしたい、と思っている人は、既にエンジニアとも呼べません。

如何なるソフトウェア、如何なるシステムであっても、必ずライフサイクルと言うものが存在します。

お客さまにとっても、システムやソフトウェアはその会社の『資産』です。
３０万を超えれば、それは立派な『固定資産』となるのです。そのため、必ず減価償却が求められますので、最低でも償却期間中はライフサイクル期間として、市場やビジネスモデルに合わせて、必ず保守・運用・カスタマイズなどを行っていかなければなりません（減価償却資産をきっちり管理し、国税庁への報告をしなかった場合、財務報告義務違反や脱税等となります）。

　作ったら作りっぱなし
　後のことは知ったことじゃない
　一生責任を持って面倒見る覚悟もない

と言う人が、次のエンジニアのためのユーザビリティを意識することなく、
中間成果物もロクに用意しなければ、そのソフトウェアまたはシステムは、

　必要最低限ギリギリの品質 or 駄作

となっていることでしょう。もちろん、お客さまにとってもライフサイクル期間を十分に運用できる保証とならないため、そこに不満を感じてしまうと、二度と仕事をくれなくなるかもしれません。

一過性の評価を得ることがあっても、中長期的に見れば必ずと言っていいほど顧客を失うことになっているはずです。作り手側の立場ばかりでなく、常に開発が終わった後の『使う側の立場』に立ってデザインや構成を見直しましょう。

もちろん、アート性やゲーム性を追求するWebサイトなどでは、「わかりにくさ」もひとつのコンセプトだったりする場合があります（「〇〇からの脱出」系Webサイトで、色々わかりやすかったら、目的と合致しないかもしれませんしね）。

どちらにしても、

　カッコいい ≠ 使いやすい

と言う現実もあるということを理解しておかなくてはなりません。もちろん、「カッコイイ」と「使いやすい」の両立ができればそれが一番ですが、それが難しいからこそ、エンジニアとは別に、デザイナーと言った職種も存在するわけです。

しかし、Ｂ２Ｂで開発するようなＩＴ企業ではなかなかそういったデザインを主とする部署や職制、役割がいません（Web専門の会社ならいるかもしれません）。ですので、エンジニア一人ひとりが、普段から意識して検討し、１つの品質として設計する必要があるのです。

たとえば、Webサイトの場合、利用者はネット初心者のネットサーファーでない限りは、目的があってWebサイトを訪れてきます。その目的のために、まず操作方法を身に付けなければならないようなWebサイトを、ユーザーは二度と利用したくないと思うでしょう。

クライアント企業によっては、そういったユーザビリティの認識に欠けているところもあるので、こちらから積極的にご相談や提案をしていく勇気も必要になります。言われたことを、言われたままに実現しているだけではダメなのです。

さらに、画面デザインは情報デザインでもあります。

ユーザーにとって「情報の見やすさ」だけでなく、「理解のしやすさ」「使いやすさ」なども想定したものでなくては、Ｂ２Ｂで開発されるシステムが本来目的としている

　業務／作業効率の向上

は果たせないでしょう。ただ機能的に要求を満たしたソフトウェアを作ればいい…というわけではないのです。ＩＴがInformation Technology（情報を取り扱う技術）である以上、使いやすさもデザインの重要な要素であることを忘れてはいけません。

ユーザーのニーズにマッチした情報を提供する

ユーザーがほしい情報を探し出せるのはもはや当然で、これからはユーザーが訪れるだけで、ユーザーが興味を持ちそうな情報を自動的に提供される仕組みが必要とされてきています。

たとえば、Amazonや楽天などのショッピングサイトで、ユーザーが何度も購入した商品のカテゴリ情報がトップページに自動的に表示されたり、ニュースサイトでユーザーの興味のある情報が自動的に表示されたりすることで、ユーザーは「このWebサイトは便利だ」と感じることでしょう（いや、「ウザい」と言う人も一定数いるでしょうけども）。

これには当然大量の蓄積されたデータとの連携が必要になってきます。こういった提案ができる技術・知識も、フロントに立つエンジニアには求められてきています。もちろん、技術ばかりが先行して使い勝手が悪くなってしまっては元も子もありません。

アクセシビリティの重要性

さらに、子供や高齢者障害者の方でも快適に使えるような「アクセシビリティ（近づきやすさ、利用しやすさ、アクセスのしやすさ）」も重要になります。見た目のわかりやすさだけでなく、実際にメンバー同士で操作してみて、使いやすさをチェックしていきましょう。

大企業や公共団体の使うシステムでは、そういった情報バリアフリーの問題は現実化していますので、たとえお客さまからの明確な要望がなくても、そういった点を意識したデザインがこれからは要求されると思って、身構えた方が良いでしょうし、お客さまから何も言ってこないようであれば、ここぞとばかりにこちらから提案した方が良いでしょう。

インパクトやもの珍しさだけで喜んでくれる時代はすでに終わっています。ただ要求された「機能」だけ実装されていればいい、なんて時代はそもそもありません。

インターネットが、テレビのように日常生活において当たり前になってしまった今、ユーザーが使いやすく居心地がいいと感じるシステムやソフトウェアだけが生き残っていくでしょう。

私たちエンジニアも、常にユーザーの顔を思い浮かべながら作業を進めましょう。もちろん、カッコよさなどのデザインセンスを追求することも忘れてはいけません。私も、センスはありませんが、日々「模倣」から始まり、吸収し、なんとか少しでも向上しようと日々精進しています。