2018年12月10日

UIについて-概要


初めての方はこちらを「はじめに

今回から何回かに分けてUIについて述べてみたいと思います。
私自身はUI部分についての検討、開発はCUI時代から始まって今日のGUIに至るまで何度もありますが、UIの専門家という訳ではありません。それでも世の中で目にする製品を見ていると、自分の取り組んで来た考え方が参考になるところもあるのではないかとも思えます。このブログでは個別の技術領域はあまり扱うつもりは無いのですが、今回はそんな思いでUIを取り上げてみたいと思います。
今回は全体について概要を述べます。

UIの位置づけ


まず最初にUIがソフトウェア全体の中でどのような位置づけなのかを明らかにしてみたいと思います。
UIとはそもそもUser Interfaceですから、文字通りユーザーとのインターフェースという事になります。インターフェースというのはもはや日本語化している感はありますが、英語の意味合いを語源から探れば、interはinternetなどと同様に「間」、faceは「面」ですからinterfaceは「(何かと何かの)間の面」という意味になります。もう少し日本語らしく言うならば「何かと何かの接する部分」という感じでしょうか。

interface部分を少し掘り下げましたが、これはソフトウェアの構成要素としてのinterface(I/F)の意味合いが分かり易くなるからです。私の場合I/F部分を設計する時は以下の様に必ず独立して設計します。
53N038_001.jpg
仮にソフトウェアが本来提供する機能の集まりを「本体」だとするならば、その機能を外部にどの様に届けるかという口が「I/F」という事になります。I/F部分は言うなれば「本体と外部の間」または「本体と外部の接する部分」と言えます。つまりI/F部分は本質的ではなく外部に対して仲立ちをする役割しかありません。上の図にある様に繋がる先がAならばA用の口が必要ですし、BならばB用の口が必要です。外部と繋がるという事は例えるならば外国人と会話をする様なものです。アメリカ人と会話をするならば仲立ちとして日本語と英語を通訳できる人が必要ですし、中国人と会話をするならば日本語と中国語を通訳できる人が必要です。通訳者がI/F部分にあたり、相手(外部)に応じた通訳(I/F)が必要という訳です。

それではUser Interfaceとは何でしょうか?
字義通りに捉えるならば以下の様な位置づけになります。
53N038_002.jpg
コマンドライン用の引数やアプリケーション用のAPI等の機械(ソフトウェア)向けの繋ぎと同列で、人(ユーザー)向けに本体の機能を提供する口という位置づけです。

この話を最初にしたのは、本体とI/Fをごちゃ混ぜに考える人が多いからです。ここの概念が確立していない為に本体の仕様を考える際にI/Fに引きずられて決めてしまったり、作りの上でも本体とI/Fを分離せずにまぜこぜに設計してしまったりします。
こうなると大変です。I/F部分は外部の事情によって幾らでも変わりますし、また変えなければなりません。その度に本来関係の無い本体自身を修正しなければならなくなります。やがてはコードを維持しきれずにバージョンアップを諦めるか作り直すかの選択をする事になります。
なのでUIを論じる前に、本体とは独立していて関係の無いものだという事を明確にしておきたかったのです。
※本体自身がUIというソフトウェアはあります

UIに特有の要素は何か


さて、ようやくUIそのものの話に入ります。
UIという繋ぎ(I/F)を考える時にAPIなど他の機械向けのI/F部分を考えるのと何か違う部分があるのでしょうか?
人間を相手にするので当然違う部分はありますが「全然違うという訳では無い」というのが私の考えです。むしろ捉え方を変えればかなり共通していると考えています。

まず、根本的に違う部分は、普通のプログラムは機能の集合体と言えますがUIの場合はそれだけではなく
    UI=機能+アート
であろうという事です。
アートというのは「かっこいい!」みたいな機能の良し悪しとは直接的には関係の無い要素で、デザイン的な感性の部分です。一般的にはデザインと言われる内容かもしれませんが、デザインという言葉は色々な意味で使われるので、ここではアートとしました。
このアート部分に関してはまさしく人間の感性に依存する部分なので、さすがに関数の仕様を検討する様な訳にはいきません。これはもうその道のプロに担当してもらうしかなく、ここでは論ずる事はできません。しかし企業向けにしろ個人向けにしろ多くのソフトウェアではアートの要素が必須となる事はあまりないのではないでしょうか。「A社のシステムは一万人処理でき、B社のシステムは五千人しか処理できないが、かっこいいからB社のシステムにしよう」などという事はあり得ません。
なのでここでは「アートという要素がある」という話に留めて先に進みたいと思います。

機能


それでは次にUIにおける機能とはなんでしょうか?
本体の機能ではなくUI自身の機能という事です。これはI/Fのところでも述べた様に
    本体の機能を提供する事
    「人間用」の形式とする事
と言えます。
一番目はI/Fとしては当たり前の事ですので、UI特有の部分は二番目の「人間用」というところになります。つまりUIを検討しようとしたらば人間の特性を理解していなければならないという事です。人間はどのようなI(認識)/O(操作)の形式なのかという事です。本来そういう特性を理解していない限り「人間用」の形式というのは難しいという事になります。
これは先程の通訳の例えで考えれば当たり前の事です。中国人と会話をしようとしたら通訳(I/F)は当然中国語が分かっていなければなりません。人間とのI/Fでは当然人間が分かっていなければならない訳です。
こういった内容は人間工学の範疇かと思うので、全て人間工学によって学術的な結論を出してもらえると良いのだとは思います。なかなか現状そこまでは行かないとは思いますが。

性能


それでは機能に対して性能とはなんでしょうか?
勿論普通にプログラム的な性能の要素はありますね。画面を表示するスピードみたいなものは純粋にUIを司るプログラム部分の性能ですね。
それ以外はないでしょうか?
今一度I/Fの役割に立ち返って考えてみます。
I/F部分というのは外部が本体の機能を実行する仲立ちですね。例えばアプリケーションがAPIを通じて本体からファイルの一覧を取得しようとした場合、実際にディレクトリからファイルの一覧を取得する処理は本体の処理であって、この時かかる時間は本体の性能という事になりますね。もし本体が10msかかったとして、API経由で呼び出した時にはトータルで11msかかっていたとしたら、差引1msがI/F部分(API)の性能という事になりますね。
至極単純な話ですね。

では外部がユーザーだった場合に同様に考えるとどうなるでしょうか?
つまり先程と同じ言い回しをするならば「ユーザーがメニューなどを通じて本体からファイルの一覧を取得しようとした場合」という事になります。
この場合、同じ様に考えるならばユーザーが「ファイルの一覧を取得しよう」と考えた時から色々操作して実際に取得できた時までがトータルの時間という事になります。従ってそのトータルの時間から本体の時間を差し引いた時間がI/F部分(UI)の性能という事になります。
これはソフトウェアがAPI経由で本体を実行する話とは全く違っていて様々な要素が関係してきます。例えばメニューの数や配置などによって単純にオペレーションの回数が変わります。更にメニューの構成が分かり易いかどうかによっても大きく変わります。もしどこに機能があるか分からなくて探しているうちに5分経ったとしたらI/F部分で5分-10ms=4分59.9秒かかったという事になります。
この様に考えると実はUIの性能というのは単純なプログラムの性能ではなく、ユーザーにとっての認識や操作のし易さとかなり近いのではないでしょうか。少なくとも使い勝手の大きな指標となりそうです。

次回はUIの「機能」部分について、より詳細に見て行きたいと思います。

機能

シリーズ


1.UIについて-概要
2.UIについて-機能
3.UIについて-性能・前編
4.UIについて-性能・後編

一覧


メニュー


記事を広める



posted by 善 at 18:19 | Comment(0) | 仕様 | このブログの読者になる | 更新情報をチェックする
スポンサーリンク
この記事へのコメント
コメントを書く
お名前:

メールアドレス:

ホームページアドレス:

コメント:

※ブログオーナーが承認したコメントのみ表示されます。