ユーザビリティとアーキテクチャ
これは、前回のエントリ Developer Usability(2008-06-25 - ソフトウェアスペシャリストへの道)の続きである。このエントリでは、実際にソフトウェアを利用するエンドユーザにとっての使いやすさ(End User Usability)は、アーキテクチャで制御することはできないのではないか。というのが私の結論だった。
この疑問に対して、次の本を引っ張りだして確認してみたところ、「ある意味」明確な解が述べられていたので紹介しよう。
- 作者: Len Bass,Rick Kazman,Paul Clements,前田卓雄,加藤滋郎,吉野圭一,佐々木明博,新田修一
- 出版社/メーカー: 日刊工業新聞社
- 発売日: 2005/10
- メディア: 単行本
- 購入: 1人 クリック: 33回
- この商品を含むブログ (13件) を見る
4.2 アーキテクチャと品質特性
使いやすさには、アーキテクチャ的な側面と、非アーキテクチャ的な側面が必要である。非アーキテクチャ的な側面には、ユーザインタフェースをわかりやすく、そして使いやすくすることが含まれる。ラジオボタンや、チェックボックスを提供するべきか。どのような画面レイアウトが最もわかりやすいのか。どのような書体が最も見やすいのか。これらの詳細は、エンドユーザに対して大きな問題となるし、使いやすさには影響を与えるものではあるが、それらはアーキテクチャに関するものではなく、設計の詳細に関するものである。しかし、ユーザに対して、操作をキャンセルする機能、操作を元に戻す機能、あるいは以前に入力されたデータを再利用する機能をユーザに提供するかどうかは、アーキテクチャに関する問題である。それらの要求の実現には、多くの要素の協調が必要である。
この節は「アーキテクチャと品質特性」と題されているが、品質特性とはいわゆる非機能要件のことである。アーキテクチャ的と非アーキテクチャ的とは、それぞれ非機能的と機能的と読み替えても良いだろう。*1
つまり、ユーザビリティ(使いやすさ)に関してはアーキテクチャで制御できるものとできないものがあるという。なるほど。僕は、これらを二者択一しようと考えて悩んでいたのだが、そもそも「あいまい」というかキッチリ線を引くことができないという。そうなると、僕の出した結論もあながち間違いではないらしい。
この本も購入してから結構時間が経つのだが、今までリファレンス程度にしか読んでいなかった。実はこの章も読んだつもりだったのだが、全然頭に入っていないことが判明した。うーん。。。
また、僕の中で「アーキテクチャ」というものの定義を明確にでないことも明らかになった。いろんな言い回しを駆使して説明できないことはないのだが、これという自信を持って説明ができない。もちろん「アーキテクチャ」とはソフトウェアアーキテクチャを指すのだが、この用語にはいろいろな定義がなされているため、自分の言葉で説明するとどうなるのかを今後のエントリのネタにしてみようと思う。