エンジニアリングとは何かという定義については、これといって決まったものはなく、人によって、または状況によっていろいろな定義があります。その中で、最近私が良いなと思った定義は「エンジニアリングは、インプットと手法が同じであれば同じアウトプットが得られることを価値とするもの」という定義です。この定義を基準に考えると、広い意味でのデザインは、その逆ということになるでしょうか。

ウェブの開発においては、デザイナーとエンジニアといった分担がされることがありますが、上記定義から言うと、エンジニアの仕事＝エンジニアリング、デザイナーの仕事＝デザインではありません。エンジニアに任される仕事の中にもエンジニアリング要素をもつ作業と、デザイン要素をもつ作業があります。これはデザイナーの仕事についても同様です。

例えば、テストケースの洗い出し作業について考えると、対象サイトとテスト計画が同じであれば、いつ、だれが行っても同じテストケースとなることが求められます。また、画面設計についてはデザイン的な要素も強いですが、ボタンの配置を統一するなど、ガイドラインで賄えるような部分に関してはエンジニアリングと言えるでしょう。

more…

DESIGN IT! magazine 2008 vol.1の上野さんの記事を読んで、改めてコンセプトを最初に規定することの大切さを感じたのでメモ。

上野さんの「IT設計の新潮流」という記事では、以下のようなことが書かれています。

一般的な要件定義フェーズでは、議論を重ねるうちに、どんどんと盛り込む機能が増えていく。あったら便利だろうと思われる昨日のアイデアが次々と出てきて、要件に追加されていく。「便利だ＝機能が多い」という価値観を否定するのは難しく、要件が膨らんでいく流れに真っ向から抗う者は少ない。機能を増やすことは簡単だが、減らすことは難しい。

by DESIGN IT! magazine 2008 vol.1 p.069

発注側のお客様も受注側の開発者も両者とも、ビジネス戦略をサイトコンセプトとして落としこめていない状態で開発していると、機能の増加を抑える理由がほとんど無い状態で突き進まなければいけなくなってしまいます。すると、最終的には、使われない機能が沢山あるけれど、よく使われる機能の使い勝手が悪いというサイトができてしまいます。

機能が少なくなり、UIがシンプルになれば、工数が減り、金額と開発期間が減るはずです。これは発注側のお客様にとってはハッピーなことのはずです。それなのになぜ機能を増やしたがるのか考えると「機能を増やさないとやりたいことが実現されないのではないか」「機能を増やせば便利になるのではないか」という思考が働いているからだと思います。それが全部間違っているとは言いませんが、何かしらの根拠を持って「これで良い」ということを伝えられれば、そのような不安を拭い去ることができるのではないでしょうか。

その時に、一つの武器になるのがサイトコンセプトです。

more…

最近あまり時間が取れないこともあり、便利なJavaScriptの紹介記事が多くなってしまっているので、自分なりの見解を書いておこうと思います。

JavaScirptを使って視覚的に効果のある演出を行ったり、ユーザビリティを向上させるということに対しては、どちらかと言うと肯定的な考えを持っています。
一方、ブラウザ依存があることや、Webの操作に慣れていない人・ハンディを持つ方などには敷居が高くなるということも、充分に理解しなければいけないと思っています。
便利だから何でも使うというのではなく、何かしらのポリシーを持った上で効果的に使わないと意味が無いものになってしまいます。

最終的な判断基準としては、

• そのシステムの対象ユーザーとして想定されるペルソナはどんな人か？
• この機能が使えない（または代替手段を使わざるを得ない）場合に、どれくらいのロスが発生するか？

というようなことを考える必要がありますが、とりあえずの判断材料として、次のどちらかを満たす場合には検討の余地があるのではないかと思います。

• JavaScriptがOFFでも機能自体は使えるが、ONだとより便利で使いやすくなる
• JavaScriptを使わない場合と比べて、飛躍的にユーザビリティの高いUIを提供できる

more…

「フランチャイズオーナーになりたい」でも触れましたが、情報をしっかりとメンテナンスするということは、大切だけどとても難しいことです。

先日の「地方自治体Webサイトのユーザビリティ評価（引越し部門）2007 結果報告会」で受賞されていた地方自治体さんでも、リンク切れが問題になったりとか、情報の整合性を課題に挙げている方もいらっしゃいました。

そのように考えていくと、公演で篠原さんが管理画面のユーザビリティについて触れていたのも分かります。「どうせ管理者が使うページだし」ということで、お客様自身も「使えればよい」というような考え方をする場合が多いですが、管理画面のユーザビリティを向上させることが、結果的に、フロント画面のユーザビリティの向上にもつながるといえます。

また、自分が日常的に悩んでいる情報の整合性の問題といえば、仕様書の整合性があります。機能的には変わっていないのに、言葉が変わった為にいくつものドキュメントを修正しなければいけないなんてこともよくあります。

もし、仕様書作成ツールが高機能で、情報の整合性を自動的にとってくれれば、いくつもの場所を修正するなんていうことに無駄に時間を消費せずに、仕様書の持つ潜在的な（システム化されたときの）ユーザビリティの向上のために時間を割けるかもしれません。

more…

UCDを行う場合、仮説検証プロセスを回すことになりますが、事前にペルソナの作成やプロトタイプへのユーザビリティテストを行うこと、つまり事前の仮説・検証にコストをかけることに対し、

「そんなことをやってどれくらい効果が出るのか。効果を説明できるのか。」

と言われるということを良く聞きます。
（お客様からだったり、上司からだったり、メンバーからだったり。）

でも、その一方で、何の疑問も持たずにシステム性能については事前に仮説・検証を行ってたりします。

例えば、

システムの検証がしっかり行われていなかったためにレスポンスが遅くなり、ユーザーの使い勝手が悪くなる

ということに対しては、敏感なのに対し、

ユーザーの検証がしっかり行われていなかったために機能の提供方法を誤り、ユーザーの使い勝手が悪くなる

ということに対しては、非常に鈍感です。

どちらもユーザーの満足感を下げる要因であるのに。

more…

■よくある（？）例
システム開発を行っているとこんなことがよく起こらないでしょうか？

• 方法が複数ありどちらを選べばよいか判断できない
• 開発メンバーの中で実現方法に対して意見が割れる
• 良く検討して作ったものをユーザーや顧客に「使いづらい」と言われる
• 細かいグラフィックデザインの指摘や修正ばかりで全体を見てもらえない

などなど

このような事が起こる原因の一つに、「多くの場合、自分も顧客もユーザーではない」ということが挙げられます。
頭では「ユーザーが使いやすいように」とか「ユーザーにとって便利なように」と分かってはいても、いざ考えるときには、「ユーザー」が「自分」に置き換わってしまっていませんか？
しかし、それは仕方ないことなのです。なぜなら、いくら頑張ったところで（悲しいですけど）結局自分はユーザーではないからです。

ではどうすればよいかと言うと「ユーザーに登場してもらう」のが一番です。

そう、その登場してもらい方こそが「ペルソナ」なのです。

more…

「ガイドラインアプローチ（ユーザビリティの守）とは？」では、あらかじめ定めたガイドラインを遵守することによって、最低限のユーザビリティを確保するというアプローチ方法について説明しました。

例えば、「リンクにはアンダーラインをつける」のような細かい部分に関しては、あらかじめ決めておいたガイドラインに則ることが非常に大切ですが、大きな部分になればなるほどあらかじめ決めておけないような事柄が増えてきます。

また、ガイドライン方式であらかじめスパッと決めてしまうと、良い意味でも悪い意味でも一般的なものになってしまいます。

この一般的ということがいい方向に働けばいいのですが、ユーザビリティはユーザーやその利用状況、目的などによって変わるものですから、逆にそれがユーザビリティの低下を招いてしまう可能性もあります。

ガイドラインアプローチでは、本当に最適なのか？ということについて何も裏づけが無いというところが弱みです。

そこで必要になってくるのが、検証や評価というアプローチです。これを当サイトではユーザビリティの破と呼んでいます。

more…

ウェブユーザビリティを向上させるために技術者ができることの一つは、UIを実現できる術をできるだけ多く知っておくことだと思います。

サイト製作の際に、こういうことをやりたいと考えたり、言われたりしたとしても、実際に実現できる術を知らないと、「ウェブではそんなことできない」と、その時点で却下してしまうことが多くないでしょうか？

できないと思ったことでも何年も実験と検討をくりかえし、なんとか実現したというのが、製造業などの武勇伝としてTVなどでドキュメンタリー化されることがよくありますが、そういう、できるまでやってみるという努力がウェブ業界では足りないのではないかなと思います。

more…

ISOにおけるユーザビリティの定義については 「ユーザビリティとは？」で説明しました。

しかし、実際にはユーザビリティという言葉は色々な意味で使われており、混乱してしまうことがあります。
そんなときに、ユーザビリティの３つの水準について理解しておくと、理解の助けになります。

ユーザビリティの３つの水準については、黒須教授のUser Engineering Lectureのコラム「 ユーザビリティという概念の三つの水準」にて詳しく説明されていますが、ここではその３つの水準について、まとめてみたいと思います。

more…

私がユーザビリティについて勉強を行っていく中で、理解が進むにつれて、ユーザビリティそのものや他の用語との関係などについての考え方が変化していきました。

参考になるか分かりませんが、私の場合の理解の深まり方を恥ずかしながら公開させていただきます。

more…