EmptyPage.jp > Translations > オープンソースのソフトが使いにくい理由とその対策
Matthew Paul Thomas さんの、“Why Free Software has poor usability, and how to improve it” の日本語訳です。
2008年8月7日公開
私がはじめてこの記事の草稿を書いたのは 6 年前のことだったが、その時には “Why Free Software usability tends to suck” という題が付いていた（訳注、拙訳「どうしてフリー・ソフトウェアのユーザビリティはアレなのか」）。当時と比べれば、アプリケーションにしろオペレーティングシステムにしろ、オープンソースの製品のユーザビリティは、よいものではずいぶんとよくなったように思う。とはいえ、それは大部分がこつこつとした改善の積み重ねだとか、プロジェクトやディストリビューターどうしのゆるい競争の結果もたらされたもので、デザインのプロセスにおける主要な問題は、そのほとんどが依然として改善されないまま残されている。
こうした問題のほとんどはボランティア・ベースのソフトウェア一般に見られることで、なにもオープンソースのものに限られた話ではない。趣味で公開されているようなオープンでないプログラムでも同じようなことが原因となって使い勝手が損なわれていることは多い。しかし貢献してくれる人手を得るのにいちばん手軽なのは、そのプログラムをオープンソースにしてしまうことだ。何千人という人々がオープンソース・ソフトウェアの開発には雇われてはいるけれども、開発者のほとんどはボランティアで参加しているのである。そういうわけで、ボランティア・ベースのソフトウェアで見られるユーザビリティの問題は、オープンソースにおいていっそう顕著になるのだ。
――このことが最初のふたつの問題を解く鍵になる。
その 1、インセンティブがない。プロプライエタリのソフトウェア・ベンダーはふつうみんなが使いたいと思うような製品を作って、それで金を稼ぐ。このことはソフトを使いやすいものにしようという強いインセンティブとなる。（これには例外もある。マイクロソフト、アップル、アドビのソフトウェアなどは、出来が悪くなってもネットワーク効果で市場を独占し続ける。しかしほとんどの場合にはあてはまることだ。）
しかしながら、ボランティアのプロジェクトではインセンティブはきわめて弱いものとなる。ユーザーの数に応じて開発者たちの懐が潤うようなこともないし、そもそも誰でも再配布できるようなソフトウェアであればユーザーの数など数えようがない。ほかのインセンティブはある。転職先でアピールになるとか、メジャーな OS に取り込まれるかもしれないとかだ。しかしこういったことはむしろ二次的なことである。
対策： もっと強力なインセンティブを確立させればいい。たとえば年間のオープンソース・デザイン大賞を公表して、いいデザインをした開発者たちの労に報いることなどが考えられる。ディストリビューターはどれだけのユーザーがどのプログラムを使っているのかについての統計をとって、それがどのように推移しているかを公開することもできる。とくにユーザビリティを改善させた人に人々が報酬を払えるようなシステムを作るのもいい。また、バージョン管理システムのブランチを分けることで、より迅速な競争を促すようにすることもできる。ディストリビューターが、どのアプリケーションを採用するのかというだけではなく、そのアプリケーションのどのブランチを採用するかを、ユーザビリティの点から評価できるようにするのである。
その 2、デザイナーがいない。演奏家は、同時に優れた作曲家である場合もあるが、そうでない場合がほとんどだ。プログラマであると同時に優れたデザイナーである人もいるにはいるが、やはりまた多くはないのである。プログラミングと対人インターフェースのデザインは、別の技術であって、どちらにも長けているという人はめったにいないのだ。だから、ソフトウェアに専任のデザイナーがいるということは重要なのだが、これを実践しているオープンソースのプロジェクトはほとんどない。ユーザビリティの専門家を雇っているオープンソース・プロジェクトがないわけではない。Mozilla, Sun, Red Hat, Canonical など。しかし多くはないし、実力があってボランティアで協力してくれるデザイナーとなると探すだけでも難しい。
対策： プログラマと、ボランティアのデザイナーに向けて、簡単にアクセスできる教習素材を提供し、デザイン能力の底上げを図る。プログラマとユーザビリティ専門家が協力できるコミュニティを育成する。そしてオープンソースのプロジェクトに、リード・プログラマ、リード・インターフェース・デザイナー、ヘルプ編集者、QA エンジニアを置くように奨励する。これらは別々の人が受け持つようにする。
――それにしても、そもそもどうしてボランティアのデザイナーが不足しているのか？ これが第三の問題である。
その 3、デザインについての提案が歓迎されない。オープンソース・ソフトウェアの世界は長い間、「コードで示せ」という健全な伝統を保ってきた。ところが使い勝手のことを指摘する段になると、この伝統は形を変えて、「パッチまだー？」と言うだけになってしまう。ほとんどのデザイナーはプログラマではないのだから、これは有益ではない。それに、ではユーザビリティの専門家はどうすれば手を貸せるのかが、これではよくわからない。
対策： ユーザビリティの専門家がプロジェクトに参加できるようにするためのプロセスを確立する。たとえば、リード・デザイナーがプロジェクトのデザインの仕様書をウェブサイトに掲載して、ウェブログや Wiki、メーリング・リストでフィードバックを募る。デザイナーはデザインについての意見を（見当違いのこともあるにせよ）紳士的に述べることができるようになる。プロジェクトのメンテナは、項目を追加していくだけのバグ・トラッカーの代わりに、項目を編集できるイシュー・トラッカーをセットアップしてもいい。改善案が提出、議論しやすくなるし、バグ・レポートと同じようにデザイン案に対しても実装の優先順位を付けることができるようになる。
――プログラマたちがユーザビリティについての提案を、ほかの技術的なバグ報告とは別個に扱うのはどういうわけなのだろうか？
その 4、ユーザビリティ測定の難しさ。ソフトウェアの品質については、簡単・正確に計測できるようなものもある。プログラムが走るとして、起動はどれだけ速いか、実行速度はどれくらいか、技術的に正しい実装をしているかといったようなことだ。
しかしこうしたことは、測定しにくいがいっそう重要な品質については、ごく一部しか明らかにしてくれない。ソフトウェアが役に立つか、反応は敏速か、期待通りの動きをするか、どれくらいの割合のユーザーが使いこなせたか、使うのにどれくらい時間がかかったか、目的を達成した時の満足度はどうか、といったようなことを忘れてはならない。
こうした人間に関係する品質については、ユーザー・テストによってわかることも多い。しかしこれを行うには数時間、あるいは数日にわたる時間をボランティアの人々に割いてもらう必要がある。またユーザー・テストはふつう粒度の荒いもので、大局的な問題を洗い出すためのものなのだが、これはデザイナーにしてみれば、細かい問題を解くことに慣れてきたプログラマたちを説得する証拠として使いにくいという問題もある。それにたとえ問題が認識されたとしても、解決はデザインによってなされるものであるから、そのデザインもまたテストされなければならないのである。
ユーザー・テストを頻繁に行わないと、ボランティアのプロジェクトはプロジェクトのメーリング・リストに参加するような熱心なユーザーたちの主観的なフィードバックに頼ることになる。しかしかれらの意見は時として自分たち自身の実際の使い方をもうまく代弁できていないことがある。まして一般的なユーザーの実態とは比べるべくもない。
対策： ボランティアの人々にも現実的な、小規模のユーザー・テスト技術を創出する。スクリーンのキャプチャに録画機能など、そのほかテストを実行しやすくなるようなソフトウェアを開発するのだ。開発者たちには、ユーザーの意見よりはユーザー・テストの結果のほうを信頼するように求める。さらに、デザイン・ガイドラインを執筆して、ユーザー・テストが感知しないような小さな問題についての助言を載せるようにする。
――専任のデザイナーの不足については、オープンソース・プロジェクトの三つの文化的な問題に起因している。
その 5、デザインの前にコードを書く。ソフトウェアは、コードを書く前に簡単なデザインを行うだけでも、たいへんに使いやすくなるものである。必要なインターフェースや機能が、データモデルからアルゴリズム、処理の実行順序、スレッド分割の必要性、データをディスクに保存する際のフォーマット、さらにはプログラム全体で提供する機能の有無にまで影響を与える可能性があるからだ。しかしワイヤフレームとかプロトタイピングとかいうのは退屈そうだ。だからプログラマはいきなりコードを書き始める。インターフェースのことは後回しにして。
しかし書きあげたコードの量に比例して、デザイン上の問題は修正しにくくなっていく。するとプログラマはますますその現実から目を背けるようになる。あるいは、そもそもそんな問題は存在しないんだと思い込んだりする。そうしてバージョン 1.0 をリリースした後にようやくインターフェースを修正したりすると、既存のユーザーは使い方を一から覚え直さなければならない。かれらはイライラを募らせ、競合製品に目が行くようになるわけである。
対策： 新しいプロジェクトや機能を開発するプログラマには、デザイナーも付けるようにする。オープンソースの世界に「デザイン・ファースト、コード・セカンド」の文化を確立させよう。
その 6、船頭が多い。専任のデザイナーがいないと、その方面の知識の有無などそっちのけにして、多くのメンバーがインターフェースのデザインに参与するようになる。そして複数のデザイナーの存在は、大局から詳細に至るまでの数々の不統一を呼び起こす。インターフェース・デザインの質は、デザイナーの数には反比例するものなのだ。
対策： プロジェクトには一人のリード・ヒューマン・インターフェース・デザイナーを置き、その人物がほかの人たちからの提案をさばくようにして、どれを実装するかをプログラマともに決定するようにする。またデザインの詳しい仕様書やガイドラインを用意すれば、プログラマの陥りがちなデザイン上の失敗を防ぐのに役立つだろう。
その 7、他人の後を追う。自分たち自身の確固としたデザインがないせいで、多くの開発者たちがマイクロソフトやアップルのしたデザインが適切なのだろうと思い込んでしまっている。そういう場合もあるが、そうでない場合もあるのだ。これらのデザインを模倣することで、オープンソースの開発者は連中のミスまで繰り返してしまい、プロプライエタリの競合をいつまでたっても追い抜くことができないでいる。
対策： 賞の創設や発表を通じて、革新的なデザインの創造を奨励する。デザイン・ガイドラインは、成功したデザイン上の試みの成果を反映して、より適切な内容にアップデートする。
――ユーザビリティの低さには、専任のデザイナーがいないことから来るものとはまた別の理由も存在する。これらを解決するのはよりいっそう難しい。
その 8、自分の面倒は自分で見る主義。ボランティアの開発者たちは、自分たちが感心のあるプロジェクトや仕様に参加する。つまり、自分たちが使うつもりでソフトウェアを開発するのだ。ソフトウェアの開発者になるということは、そのソフトウェアのパワーユーザーになることに等しい。だから一般向けのソフトウェアはあまりにマニアックで複雑なものになってしまう。また初心者や非技術者の人たちに必要な機能について――ペアレンタル・コントロールや、セットアップ・アシスタント、競合製品からの乗り換え支援機能など――はおろそかにされるか、いつまでたっても実装されない。
対策： シンプルを信条とする文化を打ち立てる。抑制のきいたデザインを称揚し、複雑なデザインは嗤うべきものとする考えだ。そしてボランティアのプログラマには、知人や家族に自分たちのソフトウェアを使ってもらうようにする。そうすれば、自分たち以外の人々が直面する問題を修正する助けになるだろう。
その 9、些細な不具合は放置。こつこつと小さな修正をしてプログラムのインターフェースを改善させる作業はエキサイティングともやりがいのある仕事とも言い難い。小さな修正とは、起動時にウィンドウのサイズや位置を調節するとか、ウィンドウを開いた時にデフォルトのコントロールにフォーカスを合わせるとか、エラー・メッセージをより適切で役に立つような文章にするとか、プログレス・バーの表示をより実態に即したものにするといったようなことだ。こうしたことがエキサイティングでなくやりがいも感じないからという理由から、何年も放置されたままになっている。するとユーザーはデザインについてよくない印象を受け、ひいてはユーザビリティの専門家たちのプロジェクトに参加する意欲を奪っている。
対策： バグ修正のスケジュールを立てたら、その修正にどれくらいかかるかを考えてみよう。インターフェースに関する小さな修正は、簡単なものであればそれよりもすぐに終わるかもしれない。インターフェースのデザイナーにもスケジューリングに参加してもらうようにして、ユーザビリティの問題が「ただの UI 上の問題だから」という理由だけで軽視されないようにする。
その 10、オプションにして事を穏便に済ませる。複数の開発者がいるソフトウェア・プロジェクトであれば、デザイン上の問題で意見が衝突することも往々にしてある。これが雇われてやっているというのであれば、デザインに不満があったとしてもそのまま仕事を続けることだろう。しかしボランティアでやっているとなると、プロジェクトのメンテナは問題となっている部分の振る舞いについて設定項目を追加することで開発者たちの機嫌を損ねないようにしてしまいがちだ。こうして、たくさんの意味不明でどうでもいいような設定項目が生まれて、一般ユーザーを混乱に陥れるのである。また、このことはテストすべき項目を増大させ、徹底したテストを不可能なものにしてしまうため、ユーザー全体の迷惑にもなっている。
対策： 決断力のあるプロジェクトのメンテナとシンプル志向の文化を導入する。バージョン管理システム上でブランチを作るのも対策にはなるかもしれない。ソフトウェアの、その人なりのデザインで作られたバージョンを管理しやすくなるからだ。
その 11、ピクセル恩賞制度。メジャーなアプリケーションにボランティアの開発者が新機能を追加するとき、追加したことがわかるようようになってほしいと思うのはもっともなことだ。インターフェースのそこを指さして、「俺がやったんだぜ」と言うわけである。しかし時としてこれがインターフェースとしては不必要なオプションやメニュー項目の形をとって現れることがある。逆に、ややこしくてわかりづらい機能を削除したところ、それを最初に実装した開発者が怒り出した、ということもある。
対策： 別の表彰の場を設ける。ウェブログや、貢献者への謝辞などだ。コードの変更が対人インターフェース的にはどのような影響があるかについて評価するようにする。インターフェース全体を、「これ、こうなっている必然性ある？」という意識でレビューするのだ。
その 12、「広帯域のデザイン」対「狭帯域のウェブ」。ボランティア・ベースのソフトウェア・プロジェクトの開発はたいていが分散した状態で行われており、開発者たちは住んでる街、あるいは国までも異にしている。だからプロジェクトの意思疎通はプレーン・テキストが基本だ。電子メール、インスタント・メッセンジャー、IRC、バグ追跡システム、いずれにおいてもそうなっている。しかしインターフェースのデザインはより多元的なもので、レイアウトだとか、ある要素の動きであるとか、そうした要素の全体としての構成などを扱うものだ。
開発者たちがみなひとつの部屋にいるのであれば、デザインについてホワイトボードや、ペーパー・プロトタイピング、話し言葉やジェスチャーを使って議論ができる。しかしインターネットでは、それは望めないことが多い。議論は進むのが遅く、誤解も生じやすい。
対策： 開発に VoIP、ビデオ・チャット、仮想ホワイトボードやスケッチ・アプリ、ネット上でデザインについてのアイデアをより伝えやすくするようなアニメーション・ソフトウェアを導入する。そして開発者たちはできるだけ実際に集まって話し合いの場を持つようにする。
――最後に、オープンソース特有の問題がある。
その 13、早期のリリース、頻繁なリリース（動かないけど）。よくいう「早期のリリース、頻繁なリリース」というやつは、デザインを改善する余地を狭めてしまう。リリース前のバージョンでおかしな動きをしていたとすると、テスターはその挙動に慣れてしまうので、後になってその挙動が変更された時に、たとえそれが明らかな改善であっても文句を言うようになる。このことはプログラマにインターフェースを改善させることへのためらいを引き起こし、インターフェースにおかしな設定項目が付くようなことにもつながる。
対策： 開発のできるだけ初期の段階でデザイン上の仕様を公開する。そうすれば、テスターも最終的にはどうなっているべきなのかがわかるようになる。
その 14、汎用品の凡庸さ。オープンソースのハッカーたちはコードの再利用を重んじる。だからかれらはコードについて、それが機能を提供する関数として動くように書くべきだと言っている。そうすれば、ほかのプログラマが、実際に人間がそれを使う際の（場合によっては複数の）「フロント・エンド」を、書けるようになるからだ。システムはどのレイヤーにおいても、必要に応じて他の実装と交換可能になっているべきだという考えである。
これは長期的に見ればよいことである。特定のシステムに依存してしまうことがないからだ。しかし同時に、実装と密接に連携することを妨げるので、ユーザビリティの低下をもたらすことにもなる。ユーザビリティを念頭に置いていないレイヤー間を結ぶインターフェースの場合にはとくにこれが著しい。
例を挙げよう。ターミナル上のコマンドはふつう、処理がどのくらい進んでいるか、またあとどれくらいかかるかといったような情報は提供しない。それがターミナルでの伝統的な振る舞いだからだが、グラフィカルなソフトウェアでは、進捗状況のフィードバックは必須である。グラフィカルなユーティリティが、たんにターミナルのコマンドの「フロント・エンド」に過ぎないと思って開発されていると、こうしたフィードバックは実現がきわめて困難なのだ。
対策： はじめにグラフィカル・インターフェースの例からデザインする。そうすれば、その実現に必要な下位の実装についてあらかじめ把握しておくことができる。
その 15、コミュニティ間の境界。コンピュータでなにをするにしても、ふつうは別々の開発チームによって書かれた複数のソフトウェアに依存することになる。たとえばこのウェブページを誰かに見せるために印刷したとする。このタスクに関わってくるのはウェブ・ブラウザだけではない。レイアウト・エンジンに、ウィンドウ・マネージャ、インターフェースのツールキット、無数のライブラリ、描画のサブシステム、印刷のサブシステム、プリンタ・ドライバ、ファイルシステム、カーネル等々。これらの実装が、すべて別々のチームによって開発されているわけである。
これらの開発チーム同士はふつうお互いに頻繁に交流があるわけではない。またプロプライエタリの競合とは違って、そのほとんどがリリース・サイクルも異にしている。これはユーザビリティの改善を難しくしている。改善がシステムの複数の領域にまたがったものであるような場合、その実現に時間がかかってしまう。
対策： オープンソース・システムのベンダーはこうしたクロス・コンポーネントの問題を調整できるはずだ。ソフトウェアのコンポーネント全体に関与している従業員がいるとすればの話だが。またレイヤーを異にするソフトウェアのボランティア開発者たちは、そのために協議の場を設けることもできる。
問題点は以上だ。長くなってしまったが、わたしはどれも乗り越えることができると思っている。これから数か月かけて、わたしはこれらの解決策の実例についてや、自分自身はオープンソースの成功にどうしたら貢献できるのかについて、議論していきたいと思う（訳注、著者のブログで、ということでしょう）。
誤字や言い回しの訂正などの小さな変更はここに掲載していなくても随時行っています。