EmptyPage.jp > Translations > どうしてフリー・ソフトウェアのユーザビリティはアレなのか

どうしてフリー・ソフトウェアのユーザビリティはアレなのか

Why Free Software usability tends to suck

2005年12月25日

Matthew Thomas さんの2002年4月13日のブログエントリ、“Why Free Software usability tends to suck” の日本語訳です(現在はリンク切れになってますが、Internet Archive でアーカイブが読めます)。僕はこれを Joel on Software の 「5つの世界」で(正確には書籍のほうを読んで)知りました。このエントリはいろいろと論争を巻き起こした有名なもののようですが、どうやら当時の日本ではあんまり言及されてなかったみたいなので(≒ Google で見つからなかったってことですけど)、いまさらながら日本語にしてみました。

お知らせ: Matthew Thomas さんは 2008 年に、この記事の続編ともいえる、“Why Free Software has poor usability, and how to improve it” という記事を書いています。この新しい記事も「オープンソースのソフトが使いにくい理由とその対策」として翻訳を公開しております。よろしければご参照ください。

どうしてフリー・ソフトウェアのユーザビリティはアレなのか

私は IBM 出身のある人と、フリー・ソフトウェアがすぐれたヒューマン・インターフェースを獲得することが可能かどうかずっと議論をしてきた。

理論的には、それは可能だと思う。しかし現実的にとなると、オープンソース・プロジェクトのほとんどすべてが、同時にボランティア・プロジェクトでもあって、そしてこのボランティアに頼っているということが、開発を必然的にインターフェース・デザインをアレなものに導いているように思われた。その理由は多種多様なものになるので、これはそのうち長文の、読むに値するようなエッセイにしたい。しかしとりあえず、ここにその概要を書いておこう。

  1. 報酬が得られるプロジェクトと比べると、インターフェース・デザイナーの熱心なボランティアというのはずっとレアだ。そういう人があったとしても、(不肖わたくし同様)まったくの素人だったりする。

  2. 帰結その1: そうなると、インターフェースのデザインは、そのことについてまるで無知であるにもかかわらず、プロジェクトの貢献者たちで手がけることになる。そういった経緯でひとたび複数のデザイナーが生まれてしまうと、外見から詳細にいたる数々の不統一が発生する。インターフェース・デザインの質というのは、デザイナーの数には反比例するものだ。

  3. 帰結その2: 献身的なインターフェース・デザイナーがいたとしても、かれらは仕事であずかっているほどの敬意は払ってもらえない。というのはかれらはまさに献身的なデザイナーなのであって、かれらのサジェスチョンを実装するパッチを書いてくれるわけじゃないからだ。

  4. ハッカーたちの多くは、マイクロソフトやアップルがそうしているからにはいいデザインなんだろうと考えてしまいがちだが、これはそうとも限らない。これらの企業のデザインを模倣して、ボランティアのプロジェクトが連中のミスまで繰り返してしまっているようでは、プロプライエタリの競合を超えるデザインは望むべくもない。

  5. ボランティアというのは、かれらが面白そうだと思ったもの、つまりたいていは自分で使おうというものをハックする。かれらはハッカーで、パワーユーザーだ。だからインターフェースのデザインは複雑になりすぎ、ほとんどの人には扱えないものになってしまう。

  6. この議論は援用できる。インターフェースを改善するこまかい改善――ウィンドウが開いたときにコントロールにフォーカスを当てるとか、エラーメッセージを有用で読みやすく改善するといったこと――は、エキサイティングでやりがいを感じるような作業ではないから、そういったものは緩慢にしか改善されない(されたとしてもわずか)。

  7. 商用プロジェクトと同様、ボランティアのプロジェクトでもデザインのことでもめるときがある。報酬を得るための仕事であれば、デザインで賛同しかねるところがあってもそれを承服する動機はある。しかし入れ込んだボランティアとなると、メンテナは問題の箇所をユーザー設定を加えることで解決する傾向がある。そうすることで、見返りとして参加者たちから貢献し続けてもらえるようにするのだ。こうして大量の、不明瞭で、くだらない設定項目が生まれ、一般ユーザーをひどい混乱に陥れることになる。そのうえ、こうしたことはテストの量を肥大させて完全性を損ねる結果を招くので、みんなが損をする。

  8. 同じ理由――報酬が存在しないということ――から、多くの貢献者が、プロジェクトのインターフェースに自分の栄光を刻み付けた15ピクセルほどの土地をほしがることになる。本来なら隠れているべきであるような機能がチェックボックスやらメニューアイテムやらにあったりするのは、そのことを物語っている。

  9. 早期のリリース、頻繁なリリースはインターフェースに深刻な弊害をもたらす。機能が不完全で、バクっぽかったり遅かったりすると、人びとはその不完全さに慣れてしまったり、そのバグっぽい挙動や遅い動作をごまかせるよう設定を変更したりする。それでその機能が完成すると、その完成度に文句をつけたり、それまでの設定のまま使おうとする。同様に、誰かが能率の悪いデザインをすると、人びとはその能率のまずさに慣れてしまって、それが使いやすく変わったときに文句を言うようになる。結果として、ユーザー設定の項目がさらに追加されることになって、インターフェースはさらにひどいものになってしまう。

使いやすい製品を出荷しなければいけないという商業的なプレッシャー下にある企業から強い影響力を行使されるプロジェクト(Netscape、Eazel、Ximian など)では、結果としてインターフェースが改善されることが期待できる。しかしこうしたプロジェクトで正反対のことがおこっている場合もある。これはひとつにはその企業に知性と不屈さを兼ね備えたデザイナーを雇うだけのキャパがなかったか、あるいはインターフェースから、最大限の(ユーザーの満足ではなく)収益を得ようというビジネスモデルをとってたりすることが原因になっているんじゃないかと思う。

この翻訳の更新履歴

誤字や言い回しの訂正などの小さな変更はここに掲載していなくても随時行っています。

2005-12-25
公開。