状況依存（Context-Sensitive）のワナ

1998年2月16日

今回は、操作仕様を決めるに当たって設計者が陥りがちな、ソフトウェア設計における状況依存（Context-Sensitive）というパラダイムに潜むワナについて検討してみたいと思います。

状況依存と言ってもいろいろあるのですが、今回は「ポップアップメニュー」と「モードによる操作コントロール」について検討します。これら2つの方法は、本当にユーザーにとって利益があるようにデザインされているのでしょうか？

ワナ1：ポップアップメニュー

ポップアップメニューという言葉に聞き覚えがない人でも、「Windows95で右クリックすると出るメニュー」「MacOS8で採用されたコンテキストメニュー」と言えばお分かりになるかと思います。マウスポインタが指しているオブジェクトに合わせて、またはその時の操作モードに合わせて、その場で良く使うであろうコマンドがポップアップして表示されるというアレですね。専門的には状況依存メニューと呼びます。

ソフトウェアの設計者やインターフェースデザインをする人は「選択したオブジェクトに依存してメニューが表示できるわけだから、ユーザーにとって便利なことこの上ないはず」と考えます。したがって「いいよマニュアルなんか適当に書いてれば。操作すればわかる仕様だから」と仰せになる方もいます（苦笑）。

確かに、建前上ではそうです。

状況に合わせたポップアップメニューは、ここでは何をできるのかをユーザーにアクティブに示すことができる素晴らしいツールになります。状況依存よるポップアップで、ユーザーを正しい操作に誘導できるのですから、ユーザーの操作モデル形成に役立つこと請け合いですし、マニュアルにかかる負荷も少なくなることが予想できます。

でも、本当に使いやすいポップアップメニューに出会ったことがありますか？ 「コピー」と「貼り付け（ペースト）」だけしか使っていないということはありませんか？

バレンタインデーでもあるまいし、義理でついているポップアップメニューが多いような気がします。何でもつければよいという性質のものではないと思うのですが...。ちなみに一番どうしようもないと思ったのは、Windows95のフォルダ内で右クリックしたときです。フォルダや文書の新規作成（何とポップアップ内でサブメニューまである）まで入れて、どうしようというのでしょう。逆に、Adobe Photoshopのレイヤー移動ツールを使っているときにポップアップメニューを出すと、移動対象のレイヤーを切り換えられます。これはまさに状況依存メニューの理想を体現していると言えるでしょう。素晴らしいことこの上ありません。

やはりポップアップメニューの項目は、ユーザーがある状況で何を優先して行おうとするのかを十分に調査したうえで、項目をしぼりこんで提供すべきです。良いポップアップメニューの条件を、インターフェース設計の専門書のアドバイスも含めてまとめると次のようになります。

よほどのことがないかぎり、ポップアップメニューにサブメニューはつけない

ポップアップメニューの項目数は5～10個くらいまでとする（8個以内が望ましい）

ポップアップメニューからだけしかコントロールできない項目を置いてはならない（メニューバーからアクセスできない項目を置いてはならない）

項目名は簡潔で分かりやすく、そして単純なものを使用する

もちろんこれらはポップアップメニューの物理的な要件です。どの場面で何を提供するかが熟慮されていないポップアップメニューでは、ポップアップによる操作誘導は意味をなさないことを、ソフトウェアの設計者は忘れてはならないでしょう。

ワナ2：モードによる操作コントロール

モードと一言で言っても、インターフェース用語としてはモーダルとかモードレスとかを思い浮かべる方が多いかと思います。でも、ここではダイアログボックスをめぐるモードの話ではなく、操作や動作に関するモード（操作モード）のお話です。

操作モード、これは重要な問題です。何が重大かというと、ポップアップの重視は、まだ設計者にユーザーに対する配慮がある（ただし成功していない）のに対して、モードの押し売りはソフトウェアの内部構造をユーザーにそのまま押し付けるものだからです。「え、だってこのモードでは～できる、と言ったほうがわかりやすいでしょ」って、それは設計者の視点です。設計するときはその方がよいかも知れませんが、ユーザーに内部構造をそのまま押し付けないでください。

操作モードの何が問題なのでしょう？

マニュアル制作者の立場から考えると、操作する前にユーザーが「いま自分はどのモードにいるから、～しなければならない」と判断しなければならないことが、一番重大な問題でしょう。つまり、手順的に自分がどのモードにいるのかを、まず確認させなければならなくなります。とはいえ、

操作モードの存在をユーザーに理解させるような設計をしているか
自分がどの操作モードにいるのかが一目で理解できるか
どうすれば操作モードを切り換えることができるのかを一目で理解できるか

といった点がクリアできている操作モードを採用するぶんには、マニュアル制作者にとっては大歓迎です。簡単にマニュアルができるということは、操作仕様的に平易なことですから、ユーザーにとってはさらにメリットがあると言えるでしょう。

しかし、上記の条件を満たす操作モードはあまり多くないようです。

モードによってメニューが切り換わってしまうソフトウェアもあります。設計者はモードによってできることが異るのだからメニューを切り換えたほうがよいという主張をするかもしれませ。しかし、モードの切り換わりをユーザーに明確に認識できるという条件が満たされていないと、それは意味がないばかりでなく、かえってユーザーの混乱の元になります。マニュアル巻末の「トラブルシューティング」に「～できない」の説明として「～モードになっていますか？」という文章がでているものは、たいていモードの切り換えが上手くいっていないソフトウェアであることが多いです。ひどいものになるとモード内モードというモードの二重構造からなる操作仕様をユーザーに強いるものまでありますが、ここまで来ると論外ですね。ところでこういう例は、実はPCのソフトウェアよりも家電製品に多いのです。家電メーカーの設計者の方、他人事じゃないですよ（笑）

モードの切り換えが非常にうまくいっている例としては、グラフィック関連のソフトウェアに多いツールパレットとマウスポインタのツールアイコン化があげられるでしょう。「え？あれも操作モード？」と思われる方もいるかもしれませんが、あれは良くできた操作モードです。切り換えかたも明確だし、いま自分がどの操作モードにいるのかも明確です。

操作モードというのは、たいていプログラムの内部構造が、そのまま操作仕様として表出してしまったものが多いと思います。しかし操作モードと言っても、表現のしかたを工夫することでかえってわかりやすく、使いやすいインターフェースを構築できるものもありますし、逆にモードという制約自体がユーザーに有害な作用を及ぼすものもあります。ソフトウェア設計者ならびにインターフェース設計者は、この点についてもうすこし配慮して設計を行ってくれることを望みたいと思います。そうすればユーザーからの反響もよくなってサポートコストが減少しますし、マニュアルも簡単に制作できるので、マニュアルの制作コストも下がりますよ（笑）

いかがでしたか？

ポップアップと操作モード、それぞれを独立して取り扱ったほうが良かったかもしれませんが、状況依存に頼りがちな設計に対するクレームという面では本質的に同じかと思います。現場の設計者さんからのご意見、ご感想なども頂ければ幸いです。