Developer Usability
In contrast to common belief, architecture is not only about functional requirements and operational qualities. It is also about usability. A system that meets all requirements but is not usable, is of no value for its users. As an example: I owned Rio and Creative MP3 players which provided an incredible amount of features, but lacked usability. After a while I switched to Apple IPods which have less features and are significantly more expensive but offer a great user experience.
- 意訳
アーキテクチャは、なにも機能要件や運用上の品質だけではない。ユーザビリティもアーキテクチャである。すべての要求を満たしたシステムであっても、使いにくいシステムはそれを利用するユーザにとってなんの価値もない。例えば、私の持っているRIOとCreativeのMP3プレーヤーは、かなりすぐれた機能を含むが、ユーザビリティが欠落している。対して、AppleのiPodは、機能は少ない上、明らかに高価だが、すぐれたユーザエクスペリエンスを提供する。
この引用だけでは文脈が伝わらないが、ここでのユーザビリティはUIに限ったものではなく、APIなども含んでいる。確かに、使う立場に立ったもの作りは基本としてわすれてはならないし、いつも心がけているつもりだが、ちょっと疑問に思ったことがあるので書いておく。
僕は仕事でよくアプリケーションアーキテクチャ構築の支援をするのだが、例えばフレームワークを作った場合、ユーザにあたるのはその「フレームワークを使ってアプリケーションを開発する人」である。なので、ユーザビリティというのは、実装手順がシンプルでわかりやすい、とか、エラーハンドリングのような横断的な関心事はできるだけ意識しなくてよいといったことになるのだろうか。また、アプリケーションを開発する人にとってのユーザは「アプリケーションを利用する人(エンドユーザ)」となるため、ユーザビリティ＝UIの使いやすさ というのがピンとくる。
では、アーキテクチャにとってのユーザビリティとは何だろうか。Stalさんの言うとおり、ユーザビリティもアーキテクチャの要素であることはわかっているつもりだが、よく考えると「あれ？」と思った。例えば、エンドユーザに対するユーザビリティ(UIの使いやすさ)の向上を目指したとしても、アーキテクチャでがんばれることは、リッチなWebのUIを実現するためにAjaxを取り入れたりすることぐらいなのかもしれない。つまり、いくらよくできたアーキテクチャであっても、エンドユーザが利用しやすいUIを実現できるわけではない。言い換えれば、アーキテクチャとUIの使い勝手は直交しているのだろうか！というのが今日の発見だった。
本題にもある「Developer Usability」は文字通り、開発者に取ってのユーザビリティなのでアーキテクチャで十分サポートできる範囲だが、「End User Usability」は、アーキテクチャによって直接的に良くなったり、悪くなったりするものでもないということだ。
