プログラマが知るべき97のこと/正しい使い方を簡単に、誤った使い方を困難に

提供:Wikisource

インタフェース仕様を決定する作業は、ソフトウェア開発プロジェクトには必ず必要です。「インタフェース」には、抽象度の高いもの(ユーザインタフェース)もあれば、低いもの(関数インタフェース)も、その中間のもの(クラスインタフェース、ライブラリインタフェースなど)もあります。つまり、システムとユーザの間のインタフェースもあれば、プログラマとAPIの間のインタフェースもあり、関数とクラスの間のインタフェースなどもあるわけです。いずれにしろ、その設計が重要であることには変わりありません。設計が良ければインタフェースは使いやすくなり、生産性は向上することになるでしょう。反対に設計が悪ければ、インタフェースがストレスやミスの原因になります。

良いインタフェースとは次の2つの条件を満たすインタフェースのことです。

正しく使用する方が操作ミスをするより簡単: インタフェースの設計が良ければ、ユーザは、ほぽ間違いなく正しく使用できます。それは、正しい使い方が「一番易しい使い方」になっているからです。GUIの場合なら、正しいアイコンやボタン、メニュー項目が、正しくないものより簡単に見つけられます。どれが正しいのかが一目でわかるようになっているのです。APIの場合なら、どのパラメータにもほぼ間違いなく正しい値を渡せます。一番「自然な値」が正しい値なのですぐにわかるのです。正しく使用することが簡単であれば、物事はすべてスムーズに進みます。

誤った使い方をすることが困難: 優れたインタフェースというのは、使う人間がどういう間違いをしそうか、あらかじめ予期した作りになっているものです。そして、そういう誤りが起きにくいよう対策を講じであります。たとえばGUIなら、そのコンテキストで実行しても無意味なコマンドは、自動的に使用不能になる(あるいは、なくなる)ようになっています。APIの場合なら、引数をどの順序で指定しても同じ結果になるように したりします。それによって「指定順序を間違える」という問題自体が発生しないようにしているのです。

簡単に正しく使え、ミスをしにくいインタフェースを作るには、「作る前に使ってみる」という方法が有効です。たとえばGUIなら「モツクアップ」を作ってみましょう。ホワイトボードに描いてもいいし、インデックスカードを机の上に並べてみてもいいでしょう。要するにコードを書く前にそれでシミュレーションしてみるわけです。APIの場合なら、そのAPIの関数を宣言する前に、呼び出しのコードを書いてみましょう。それらの方法を使って、通常あり得そうなユースケースの一つ一つについて、インタフェースがどう機能すべきかを事前に検証します。実際に使用する際にはどういうアイコンやボタンをクリックすることになるか。どういう引数を渡すことになるか。使いやすいインタフェースの特徴は「自然であること」です。「自然である」というのは、「常にその状況で一番しやすいことをしていれば、自動的に正しい使い方になる」という意味です。そういうインタフェースを作ろうとすれば、作り手がユーザの視点で物を見る必要があります(作る前に使ってみるという手法は、その意味で非常に有利です)。

使い方を間違えにくいインタフェースを作るには2つの方法が有効です。1つは、ユーザがしそうな間違いを事前に予測し、それを防止する策を講じることです。もう1つは、リリース後の早い時期に実際にインタフェースがどのように誤用されるかを観察し、改良を加えることです。誤用を防ぐ最良の方法は、そもそもその誤用を不可能にしてしまうことでしょう。観察の結果、ユーザが取り消し不可能な操作を何度も取り消そうとしているとわかった場合には、その操作を取り消し可能にすべきです。APIに誤った値が渡されることが多いとわかれば、できる限り、実際によく渡されている値を正しいものとして扱えるような改良をしましょう。

何より重要なのは、インタフェースが存在するのはユーザの利便のためであり、開発側の利便のためではないということです。それを忘れてはなりません。