更新日：
1. ガイドラインの実際
本講座の第1回ではガイドラインアプローチのマネジメントについて概説したが、これを受けて今回からは、ガイドラインの実際の内容について解説を行う。今回は、『操作や表示の一貫性』についてである。操作や表示が一貫しているとは、一つの考え方がユーザインタフェース（User Interface 以下UI）のデザイン全体に貫かれており、また操作手順や作法が統制され、一つひとつの機能を選択する操作の間に整合性が確保されている状態を意味する。つまりある操作の場面で得た操作の知識を他の操作の場面に適用できることになる。一口に一貫性と言っても様々なレベルがあり、上位には考え方を貫く理念、下位には一つひとつのボタンのデザイン表現や文言の統一感などがある。これらに秩序を持たせることで、分かりやすいUIが生まれるのである。これを一貫性と呼んでいる。
さてまず、どのような視点で一貫性を考えれば良いかについて考察してみよう。通常、ガイドラインは、固有の組み込みシステムに依存しない形で開発する。つまり開発に先立ち、あらかじめ指針を決めておく、ということである。どのような『使いやすさ』（多様な意味を含んでいるが）を顧客に提供するのか。そもそも自分達が考える『ユーザビリティの高いUI』とはどんなものなのか。このような基本的な立場を明らかにした上で、ユーザビリティ活動の成果や知識を一般化し記述したものがガイドラインである。その意味では、まず、『自らが考える良いUIとは』という基本的な考え方を理念として明確にしておくことが大事である。ここでは仮に次のようなものを理念とする。この理念に即して操作や表示の一貫性を考えて行こうということである。
我々が提供するUIは、ユーザがより自然で分かりやすく快適に目的を達成するための作業環境である。我々はユーザの利用の状況を尊重し、これに適合したUIを提供する。
ここで言う『作業環境』とは、様々な機能を使いこなしながら目的を達成するための作業空間であり操作を行う環境である。ユーザが意思をシステムへ伝達するその方法や、システムの動作過程とその結果のユーザへの通知方法など、ユーザとシステムの間の相互作用（Interaction）を意味し、『利用の状況の尊重』とは組み込みシステムの利用空間や利用上の習慣、約束事、またあるいはユーザの心理状態をも考慮することを意味する。一貫性という意味ではまずこのような理念が一貫しており、自社の組み込みシステム開発の全般に渡り浸透させていくことが重要である。ここにガイドラインの役割があるわけだ。この問題は今回の主題からは外れるが、プロセスマネジメントの役割として重要なので、最後にふたたび言及する。
今回の、『操作や表示の一貫性』の解説は、次の3つの視点を中心に行う。まず3つの視点を簡単に説明し、以後、具体的な事例と共に解説を加える。
ユーザビリティの基本原則との関係： 一貫性とは何か。ISOでは一貫性についてどういう立場を取っているか。また一貫性を持つことの意義や効果など。
操作方法および表示の一貫性の具体的事例： 操作方法に関して操作全体を体系的に捕らえつつ、機能の構造や実際の操作フロー、操作にかかわる用語（例；機能名称など）などについて言及する。表示に関しては、グラフィカルユーザインタフェース（Graphical User Interface 以下、GUI）としてのデザインのあり方や、操作に応じて視覚的にフィードバックされるUI要素について述べる。
一貫性を確保するためのツール： スタイルガイドや画像ファイルのライブラリーのあり方など。ガイドラインを正しく運用する必要性についても言及する。
2. ユーザビリティの基本原則との関係
第1回で言及されたような公なガイドラインの中で一貫性にかかわるものは次の2つである。（注；ISO9241-10（JIS Z 8520人間工学−視覚表示装置を用いるオフィス作業−対話の原則）を参照のこと）
2-1. 『ユーザの期待への適合』との関係について
ここではまず、ユーザが想定する利用の仕方に即して、システム全体が作られることが大事であることが述べられている。一義的にはシステムのあり方そのものを述べている。しかし同時に必要となるのは、一つの典型的な操作方法を標準化し、他の操作に応用していくことが有効だ、ということである。例えば一つの機能を設定し利用するフローと、次に他の似たような機能を設定し利用するフローが違っていては、機能毎に設定方法を考えなくてはならなくなる。事前に想定した操作と実際に作られた操作の間での攻防 − 思い違いとか意外な反応などを克服して操作を完遂するまでの認知的な葛藤 − という意味ではまずシステムのあり方が大事であるが、その段階で習得した『操作の仕方』は、他の操作にも応用できることが望ましい。そうすることで予想と実体のズレが少なくなり、ひいてはスムーズに操作できるようになる。これは次の原則『学習への適合性』にも通じるものである。図1を見ていただきたい。
図1：機能コンフリクト時のシステム動作の違い
図1は機能が背反する時のシステム動作の違いを述べたものである。機能が背反するとは、2つの機能を同時に設定できないということであり、たとえばプリンターでカセット給紙と手差し給紙は同時に選択できない、というような場合である。この場合、カセット給紙を選択したところで手差し給紙の選択ボタンを非表示にするか、自由に手差し給紙を選び直すことができ、その代わりに最初のカセット給紙の選択を自動的に取り消す、というような動作である。このような2つの動作が無秩序に混在しているとユーザに混乱を生じさせる。Aは最初の設定がキャンセルされたことが分かりにくいため、期待した効果が得られないということにもなりかねない。ひいては、システムへの不信感が芽生え、最悪の場合は操作が続行できないような状況も生じる。Bはフィードバックなどが煩雑となりユーザに難しいシステムであるという印象を与えてしまう懸念がある。いずれにしても慎重な選択が必要なわけだが、基本的なシステム動作は、ユーザ操作へ与える影響も十分考慮しつつ決定されなければならないことには変わりない。
2-2. 『学習への適合性』との関係について
第1回ではデジタルカメラの例を述べているが、使いながら操作を覚えるというのはごく自然なことである。好むと好まざるとにかかわらず、ユーザは学習するわけであるが、このスピードをより早くするためには、操作が一貫したモデルにより作られているかどうかが重要なカギとなる。一つの操作方法のイメージを他の操作に応用できるということは、予想に沿った流れで操作が進むということであり、心理的な負担が少なくて済む。学習という面からも、操作方法をパターン化して意識できるため、そのパターンが少ない分だけ学習も早いということになる。つまり学習への適合性とは、学習できる仕掛けと操作のパターン化という2 つの側面で考える必要があることを示している。
3. 操作方法および表示の一貫性の具体的事例
3-1. 操作方法の一貫性
3-1-1. サービス構造の一貫性
ここで問題となるのは機能の集合体としてのサービスの構造についてである。機能の集合体とは、仮に「メール｣という主機能の中には一般的なメールの送受信機能ばかりでなく、同報送信機能や携帯電話に転送する機能、登録した宛先を自動的に未着信とする機能など、様々な機能を含んでいる。ここではこのような「メール」という機能の集合体を、個々の機能と区別するために「サービス」と呼称しており、この「サービス」の中に機能が抽象的にどう分かりやすく構造化されているのか、ということを問題にするわけである。言うまでも無く操作の手順は、システム動作とも密接にかかわるものである。そしてこのシステム動作はサービス構造をも規定するものである。操作手順そのものがシステムの都合に左右される、というわけである。ユーザ視点を欠いたシステムではユーザが意図しない操作をユーザに強いることも多々ある。そのような場合は、ユーザビリティを改善するために基本設計に手をつけなければならず、設計変更に多大な労力がかかることになる。そういう意味からも組み込みシステムでは、基本設計の段階から『使いやすさ』をどう設計に反映するかを考慮しなければならない。さて操作の一貫性という観点からこの課題を考えると、まず組み込みシステム内にサービスをどう組み立て全体を構成するかに着目すべきである。これは『サービス構造の一貫性』と捉えることができる。図2を見ていただきたい。
図2：サービスアーキテクチャーの例
これはサービス構造の一例であるが、Aはサービスを配置するメニュー画面というものが存在し、そこで全てのサービスが選択できる。機能は全て画面内で選択でき、構造が簡素で迷いは少ないが階層が深くなる。これに対してBはサービスを直接ボタンで選択するタイプである。階層はAよりも浅くなるが、操作パネルのボタンが多くなりどちらかといえば煩雑な印象を与える。またサービスが増えれば操作パネルも変更する必要がでてくる。初期状態へ戻る方法が分かりにくくなるという懸念もある。先の「メール」サービスに関する別の例では、携帯電話では「メール」と「アドレス帳」は個々に独立した別のサービスとして位置づけられているが、PCの中では「アドレス帳」は「メール」の一機能として提供されている。PCのアプリケーションソフトウェアで、携帯電話方式の「メール」サービスと従来から一般的に存在する「メール」サービスがあった場合、ソフトウェアの移行に支障が出ることが予想される。現在は幸いそのようなことが無い代わりに、ソフトウェアを移行するたびに「アドレス帳」データのインポートを行わなければならない。これは「アドレス帳」が「メール」サービスに依存した作りになっているからである。製品間でサービス構造の作りに違いがあるとサービスの利用方法が2種類存在することになり、使い分けが必要となる。組み込みシステムの場合は、「サービス構造の一貫性」が最も上位の検討対象となる。
3-1-2. 画面遷移の一貫性
通常、画面操作を主体としたUIは、所定の選択を行いながら逐次的に画面を遷移し操作を完遂することになる。この場合画面の遷移は『操作の階層』を構成する。操作フローとは、とりもなおさずこの階層間の移動のことである。階層を縦横（注；階層が深くなることを縦、他の階層にジャンプすることを横としている）に移動しながら（つまり遷移しながら）処理方法を確定していくわけだが、この移動方法についての基本ルールが一貫していないと具合が悪い。図3はある組み込みシステムの画面遷移の一部であるが、遷移の方法がボタン操作とイベントで図示してある。このように操作フロー全体を機能毎やイベント毎に組み立てると操作方法が一貫しているかどうかが直ぐ分かる。このような『画面遷移図』は、組み込みシステム開発の中で必ず作成し、適切な操作フローを担保するようにしたいものである。図4を見ていただきたい。これは画面遷移のモデルとして、階層間の移動をルール化したものである。操作方法の一貫性を確保していくことで、多様な構造ながらも分かりやすい操作の体系ができあがるのである。
図3：組込みシステムの画面遷移図（操作フロー）
図4：画面遷移モデル（例：階層移動のガイドライン）
3-1-3. レイアウトの一貫性
操作部位やボタンのレイアウトも操作方法に含まれるものだが、動的な画面遷移と異なり静的な秩序を作り出すものがレイアウトの一貫性である。ガイドラインとしては基本原則に近い抽象的なレベルから操作ボタンとアイコンやテキスト領域の位置関係、画面遷移にかかわるコマンドボタン（例；[戻る]、[操作取消し]、など）は各画面共通に右端へ配置する等々、画面のレイアウトを決定づける具体的なレベルまで幅広く存在する。図5には一例として配置の基本原則が述べてある。基本的な操作のフローと等しい − つまり目的を選んで処理を選ぶという流れに整合する − 相対的な向きに、左から右へ、あるいは上から下へ配置する。画面内の機能を配置する場合も、操作頻度が高いとか先に操作して欲しいものは左手に配置し、順に右手方向に視線が移動するように配す。このような原則は図5で用いた操作パネルのみならず、画面内のボタン配置などにも応用できる。後述する表示の一貫性の解説用として用意した図であるが、図6と図7を見ていただきたい。通常テキスト位置はボタンの上になることが多いが、アプリケーションUIのラジオボタンとのレイアウトの一貫性を考慮し、ボタンを左、テキストを右に配置した例である。
図5：配置の基本原則
3-1-4. ことばの一貫性
UIの中で使用される操作にかかわることばとしては、機能名称や部位名称などのUI用語と、システム状態などを伝達するインストラクションメッセージやエラーメッセージなどがある。UIで使用されることばは操作の手掛かりとして重要なものである。機能名称にしても、単に機能の意味を伝達するという役割だけではなく、操作を動機付ける言い回しとして表現を工夫することも重要である。重ねて、その製品を開発する企業の文化や伝統的な言い回しや、テクニカルコミュニケーター協会
が2004 年に発行した「外来語（カタカナ）表記ガイドライン長音符号編」でも述べられている末尾の長音表記（例；「プリンタ｣と｢プリンター｣、等）などの問題もあり、一貫した良いことばというものは一朝一夕には解決できない問題である。したがって現実的には似て非なることばや判別しにくい言い回しができてしまうことになる。まさにことばの揺れの問題である。 1995年からオフィス機器メーカー4社が共同研究を行っているCRXプロジェクトのUI デザインガイドライン（第4版は2005年発行）では、初期値に戻す機能名称を「リセット」と提唱しているが、そもそも1990年代初頭には、少なくても「リセット」「オールクリアー」「モードクリアー｣の3種類が存在していた。CRXプロジェクト内の研究を経て「リセット」に一本化されたわけであるが、ことばの一貫性を確保するためにはこのような関連企業による共同研究や、業界レベルの調整が必要になる。
ユーザの操作経験や操作への知識に応じて『分かる言葉』は違うので、設計者の思いだけで言葉を決めることは大変危険である。極力、ユーザが日常使用することば使いに近い表現でデザインされ統一されることが望ましい。ユーザが持つ言葉の世界からはみ出さないことが重要である。このような過程を経て、ことばが統一され一貫性が確保されるべきであると考える。
3-2. 表示の一貫性
3-2-1. 押下動作と視覚的なフィードバック
表示方法、とりわけ、いわゆるGUIにおいては、色やアイコンなど画面全体にグラフィカルなデザインが施される。ここで操作情報の表示という意味では、操作部位であるボタンとその押下に対する視覚的なフィードバック表現がある。このデザインそのものについては、第3回で詳しく述べられると思うので、ここではボタン押下という操作に着目しつつ一貫性のあり方について述べることとする。
ボタンは実際の操作対象として、そのサイズやボタン間隔などは上腕や指先の動作および寸法などに配慮されるべきであるが、表示状態としてもまた、押下前の状態（オフ状態）、押下時の表現（プレス状態）、押下後の状態（オン状態）および操作不能であることを認知させるための表現（ディセイブル状態）の4種類を持つような配色の計画が求められる（図7）。なお、図7は無彩色4色の場合のボタン状態を示している。一貫性という意味では、白黒とカラーなど異なるディスプレイ間での調和も必要となる例である。
図7：ボタン状態表示の基本原則(2)
3-2-2. 表示色のカラーパレット
表示色はGUIデザインの観点から独自性なども追及されるが、色数には制限があることも認識されるべきである。パーソナルコンピュータなど何万色も再現可能な環境であればかなり自由に色が使用できるが、一般に組み込みシステムでは、無彩色系の多値色（図7では白、黒、淡いグレー、濃いグレーの4色）から 256色カラーまでが採用される。図8は256色カラーの場合のカラーパレットを示している。組み込みシステムの概念も昨今、拡張性（Scalability）が重視されつつあり、拡張可能なシステムを目指して、あらかじめWeb環境やアプリケーションソフトウェアとの連携を考慮する場合がある。拡張性を考慮した表示色の一貫性のためには、Webセーフカラー（注；Web上で正しく表示されるカラー）である216色と、Windows OSの基本8色は確保しようとすると、残りの32色が独自に使用できる色ということになる。逆に言えば32色を越える色数を独自に設定してしまうと、表示の一貫性は確保できないということである。
図8：ボタンのカラーパレット
3-3. イレギュラーな操作への対処
システム制御上の都合や制限などにより操作方法に一貫性が保てない場合はイレギュラーな操作となり、ユーザの戸惑いや操作ミスが誘発される懸念がある。不用意にイレギュラーな操作を放置すると、予想に反した画面遷移やフィードバックなどにより、操作に不安を感じ最悪の場合は操作の続行が困難となる場合があるため、予防的な処置を講ずることが必要となる。制限などの内容が予め分かっている場合は、確認アラートやインストラクションメッセージなどで制限が生じたことを告知することがある。ただしアラートが多用されるUIも作り込みのレベルに不信感を与えるので注意が必要である。図9はインストラクションメッセージの場合における表示ルールの例である。組み込みシステムのUIはインストラクションメッセージの表示エリアを予め固定し、一貫したルールで秩序のある表示を行うことで、制限や異常を適宜伝達し操作ミスなどを回避することができる。
図9：インストラクションメッセージの表示ルール
また制限の種類や規模により対応策も一様ではないため、確認アラートとのトレードオフやインストラクションメッセージが適当なものかどうかについては、対策の導入前後にユーザビリティ評価を実施し、妥当な対策かどうかをチェックすべきである。評価を通じて対策を検証することで、イレギュラーな操作も一定の秩序の下に納めた安心感の高いシステムとすることができる。
なお、アラートやインストラクションメッセージについては、第3回『ユーザへのフィードバック』、および第4回『見えるシステム、分かりやすいシステム』で詳しく言及する。
4. 一貫性を確保するためのツール
4-1. ガイドラインの体系化
第1回でも述べられている通り、一貫性の観点で組み込みシステムへ実施案を展開するためのツールとしては、ガイドライン文書の発行ばかりでなく、より詳細な設計デザイン手法を記述した「スタイルガイド」や「デザインテンプレート集」などを用意することが考えられる。特にGUIデザインについては「スタイルガイド」が有効であり、図6や図7のようなボタンやアイコン、ダイアログボックスなどUIを構成する部品のレベルでの詳細なデザインスタイルを記述する。 UI部品のメニューのようなもので、設計者やデザイナーはここからデザインの雛形を読み取るようにする。ただし、あまり詳細に書きすぎるとページ数も膨大になり、開発コストがかさむだけでなく、利用もしづらい。オフィス複合機の場合で、概ね100ページ前後を目安にすると良い。
またGUIの部品（注；ボタン、アイコンなどの画像ファイル）は関係者がアクセスできる共有フォルダーなどに格納し、再利用やデザインの流用ができるようライブラリー化すると良い。これによりさらに一貫したデザイン管理が可能となる。いわばデータベース化であるが、GUI部品はオフィス複合機程度の中規模なものでも3000ファイル程度になることもあるため、全体を俯瞰し整合をチェックする意味からもライブラリー化は有効である。
操作方法については、共通のプラットフォームにより開発が行われる組み込みシステムに対して、基本となる画面遷移フローを標準化することを提案する。個々の機能に依存した詳細な操作の規定までは難しいにしても、詳細検討に雛形を提供するようなガイド的なものは開発可能であろう。また使用する用語やメッセージについてもデータの一括管理を行うことが有効である。特に用語は一度決めた後は継続的に使用することが望ましいので、対象となる機能の内容や決定した背景も含めて、情報を整理し保存する。こうすることで、後の改訂や変更が適切に行えるのである。
これらガイドライン及びツール類を『ガイドライン体系』として一括管理し、開発関係者間で共有できるような仕組みとして構築してはどうか（図10）。ガイドラインを、人間中心設計を進めるための直接的なツールであると位置づけるならば、この管理運営のプロセスは、間接的な支援システムとして位置づけられるものである。また一貫性の確保については共通部品やガイドラインを作ればそれで良いというものではなく、作ったものを組み込みシステムの実開発の中に如何にうまく導入し、効果的効率的に活用していくかが重要となる。この意味では、ガイドライン体系の管理運営に加えて、次に言及する『インタフェースの整合化活動』を含め、プロセス面での取組みが大切となる。
図10：ガイドラインの体系
4-2. 同種のシステム間でのインタフェースの整合化活動
昨今のスピードを重視した開発プロセスの中では、コンカレント開発が盛んに行われている。製品仕様の確定を待たずに開発着手し、トライアンドエラーで設計変更しながらやっとの思いで納期に間に合わせる、というような状況が垣間見える。ガイドラインも同様で、開発着手前に完成した形で閲覧できるような姿はまず無いと思った方が良い。第1回でも述べられているが、ガイドラインは開発と共に成長するものである（注；開発の成果からのフォードバックというかたちで図10に記述されている）。その意味で、成果をフィードバックさせる場が必要となる。実際にはガイドラインの開発者自らが設計レビューや技術検討会などの場に参画し、何をフィードバックさせるかを判断するわけである。同時に、ガイドラインの既存部分との整合という観点からもインタフェース開発への助言や勧告も行うわけである。ガイドラインを基にした判断や整合化活動の中での活用のしかたについては、第5回で詳しく解説する。
4-3. 組み込みシステムのシームレス開発に向けて
システムの利用という側面に目を向けると、組み込みシステムと言ってもネットワークの存在は無視できない。前述した通り、アプリケーションやWeb環境との連携や認証システムなどインタフェースの共通化が必要になるとも考えられる。システムそのものをスケーラブルなものにする必要があるというわけだ。操作や表示の一貫性も、このような利用環境を想定にしたつくりにしておく方が良い。具体的には、モバイル端末から、複合機やプリンターを経由して、ネットワークサーバー内のデータを閲覧する、などが考えられる。この場合、個人認証をどう行うかなど技術的な問題と共に、認証のためのインタフェースのあり方など、シームレスな環境下で一貫した作法が求められるところである。
5. まとめ
操作方法や表示の一貫性は多義にわたり、サービス構造のような抽象的なものからボタンのデザインなどかなり具体的なものまで含まれる。ただこれらは、自社内の開発の仕組みに大きく左右されるため、そういうものと無関係にただガイドラインだけを記述してもうまくいかない。使われないガイドラインというものも多々存在することも事実である。やはり既存の開発戦略や開発の仕組みに即したガイドラインを開発することが大切である。内容の記述だけでなくガイドライン活用のプロセスや改訂管理など、マネジメントの強い意思が、その運用には不可欠である。逆に言えば、ガイドライン開発を主管する担当部門のマネジメントの関与なくしては、操作方法や表示の一貫性の確保はあり得ないとも言えるであろう。
（第2回・おわり）
