ユーザビリティの伝道：
折り返し地点で戦略を変えろ

矛盾して聞こえるかもしれないが、今の組織でユーザビリティを上手く伝道できていればいるほど、今後、戦略を変えざるを得なくなるだろう。お粗末なユーザビリティから脱して、まずまずのデザインをするようになるまでのアプローチと、“good”から“great”へ向かおうとするときに求められるアプローチは異なるものだ。

企業が成熟へと向かって成長の階段を上るとき、ユーザビリティは組織の中で広く受け入れられるようになり、開発プロセスにしっかりと組み込まれるようになる。ユーザの代弁者として社内で大きな声を出せるなら、あるいはユーザビリティを任されるマネージャという立場にあるのなら、段階を一段上るようにと会社をつつくことが重要な仕事の一つとなるはずだ。

初期の伝道： ユーザの代弁者からユーザビリティグループの確立へ

スタート地点： 社内には一人か二人、ユーザビリティを気にする者がいる程度。もちろん、ユーザビリティ活動が彼らのメインの仕事であるはずはない。本業のかたわら、ユーザテストを少し実施する程度の小規模な活動に終始しているのが典型である。

目指すゴール： マネージャ率いるユーザビリティグループを正式に組織し、ユーザビリティ活動を遂行する権利と予算を獲得する。

成長の初期段階、使えるリソースはほとんどなく、企業としてもユーザビリティに取り組んでいるとは本当の意味では言えない状態だ。ゴールまで半分をきったという頃には、専属のユーザビリティ専門家を2～3人雇用するくらいになっているのが通例。しかし、組織図にのらないような立場では、ユーザビリティを“一手に引き受けています”と公言できるほどではない。

このような状況では、ユーザ中心設計（UCD）のライフサイクルを十分にサポートすることは不可能で、立場もはっきりしないユーザビリティ専門家が、少ない人数で頑張ってみたところで、無駄な骨折りとなるだろう。一気に階段を駆け上がらせようとしても、それは無理な話だ。

この段階でとるべき戦略は次のようになる：

• ユーザビリティ手法。小規模で質の高いユーザテストを実施すること。フィールドスタディやベンチマーク調査といった高度な手法は気にしない。時間もお金も（そして、おそらくは専門性も）足りないのだから。
• ライフサイクルの段階。マネージャからプロジェクトへの参加要請があれば、どんなタイミングでも、ユーザビリティ活動を持ち込むこと。マネージャが、ユーザインターフェイスの問題に気付くのは、決まってプロジェクトも終盤にかかる頃だ。ユーザビリティ活動はできるだけ早く — 設計が始まる前に — 動き出した方が良いことは我々なら誰もが知っている。そうすれば、ユーザの声が、デザインの方向性を左右することだってあり得る。残念ながら、プロジェクトマネージャが熱心なユーザビリティ信者でもない限り、これは起こり得ない。組織がまだ成長の階段を上り始めてすぐの頃にあり得るケースではない。
• プロジェクトの選定。話を持ちかけてくれるプロジェクトならば何でも良い。ユーザビリティに出資しようという組織的な動きがなければ、出しゃばるわけにはいかない。たとえ、プロジェクトがあなたを必要とする可能性があり、それに気付いていないだけだとしても。ユーザビリティの視点から所見が欲しいと思っているマネージャに、期待通りのものを提供すれば、それが受け入れられる可能性は遥かに高くなる。
• 手順の成長。ユーザビリティラボを用意し、テストの被験者をリクルートする手順を整えたうえで、自分の専門領域で転用の利くテストタスクの標準化を行うこと。これらのインフラが整えば、短い準備期間で多くのテストを回すことができるようになるだろう。

初期の伝道で大切なのは、乏しいリソースを割り振る際に日和見主義を決め込むことだ。組織が本気になっていないうちは、推奨されるユーザビリティプロセスに従うことはできない。独り相撲をとるよりも、楽に勝つことを狙え。

幸いなことに、体系立ててユーザビリティに取り組んだことのない企業には、容易に結果を出せる仕事がたくさんあるはずだ。“おかしな”タイミングで“やっつけの”ユーザビリティ活動をしたとしても、ウェブサイトのユーザインターフェイスは最終的に100％以上（他のタイプのインターフェイスの場合よりも若干低い）改善されることになる。

その程度のユーザビリティ活動が、一旦、企業にビジネス上の勝利をもたらしたとなれば、経営側は、ユーザビリティグループに投資することに興味を持つはずだ。

終盤の伝道： ユーザビリティグループからユーザビリティ文化の確立へ

スタート地点： マネージャ率いるユーザビリティグループが正式に組織されており、ユーザビリティ活動を遂行する権利と予算がある。

目指すゴール： ユーザ中心設計に係る様々な活動を担う複数の専門家チームを有するユーザエクスペリエンス担当部門を立ち上げる。全ての開発プロジェクトがUCDプロセスにのっとって — ユーザエクスペリエンス担当部門が総括する形で — 動くように、会社が方針を打ち出すまでになる。

ユーザビリティグループが、ユーザエクスペリエンスデザインを根付かせるまでの力を持つ前に、ユーザビリティが、社内である程度“確立”してしまうのが一般的だ。ユーザビリティグループは、マネージャの要請に応じて、プロジェクトチームにユーザビリティの専門知識を提供するサービス組織かのように見られることも往々にしてある。この時点で、ユーザビリティグループが、推奨されるUCDプロセスを満たすのに必要なサービスを、全てのプロジェクトに対して提供できるほどに十分なリソースを蓄えていることは少ない。

企業の成長につれて、ユーザビリティに充てられるリソースは増えていく。しかし、まだ、優先順位を付けての対応が必要だ。前段階では、日和見的に優先順位をつけたが、ここまでくれば、もっと選択の余地があるはず。楽勝を追及するよりも、ユーザビリティで大勝を掴まなければならない。経営幹部に、目指すゴールへと向かう決心をさせるのに十分説得力のある勝ちを。

この段階でとるべき戦略は次のようになる：

• ユーザビリティ手法。出来の悪いデザインを一掃すべく、ユーザテストを繰り返し行うこと。一生こればかりになってしまうのではないかと不安を覚えるかもしれない。しかし、これまで以上に多くのリソースをつぎ込んで、新たな洞察を生み、デザインに新鮮な息吹を吹き込み、パラダイムシフトを引き起こすような突っ込んだ調査をすべきだ。フィールドスタディや競合製品調査のような上流工程での調査を実施してデザインの方向性を決めよう。ベンチマーク調査で、ユーザビリティ指標を集めてみよう。長期にわたってデータをとれば、ユーザビリティの投資対効果（ROI）を計ることもできる。
• ライフサイクルの段階。新規のプロジェクトには、早い段階からユーザビリティ活動を始めるよう迫ること。鍵となるプロジェクトなら、上流での、デザイン以前の調査（大きな勝ちに繋がる洞察を得て、プロジェクトを方向付けるために）にも、様々な角度から繰り返しテストを実施するためにも（単に不具合を修復するに留まらず、デザインに磨きをかけるために）、十分なリソースを確保するのだ。
• プロジェクトの選定。ユーザビリティをしっかりと向上させることで巨大な貨幣価値を実現し、上級経営幹部の目に留まるようなインパクトの高いプロジェクトに的を絞ること。少数でも、重要なプロジェクトに終始関わっているほうが、全てのプロジェクトに、土壇場で助け舟を出し、小さなインパクトを重ねていくよりもずっと良い。従業員名簿検索のような優れたイントラネットアプリケーションを自社用に改良して、組織の誰もが、毎日、ユーザビリティの威力を体験できるような実例を示してみても良い。
• 手順の成長。比較評価やフィールドスタディ、イタレイティブな取り組みを十分に経験したところで、わかってきたことを法則化し、自社製品のユーザインターフェイスデザインに関するユーザビリティガイドラインを書いてみることだ。公式に使えるUIデザイン標準規格を構築し、整備する。そうして整えられたガイドラインや規格は、ユーザビリティグループの実施する個々の調査という枠組を超えて、ユーザビリティの知見が意味をなすものとなるよう、てこ入れしてくれる。

終盤の伝道が目指すのは、ユーザビリティと開発を完全に統合することだ。そうして、デザイン以前に、ユーザビリティ活動でプロジェクトが動き出すのが当たり前となるような組織を作ること。組織には、ユーザビリティ文化が必要だ。マネージャは例外なく、UCDライフサイクルにおける基礎的な取り組みを理解すべきである — プロジェクトは、UCDのライフサイクルにのっとって進められるものと組織的に合意されているのだから。これが実現されるには、最後になってユーザテストをする程度ではなく、本格的なユーザビリティへの取り組みが付加価値をもたらしたという事例を、経営幹部がいくつか目にしなければならないのだ。

ユーザテストは安く実施できるうえに、実益も多い。成長過程にある組織の目を引くのは簡単だ。しかし、当たり前のようにユーザテストを実施するようになっても、それ以上の調査は避けられてしまう。この先へ進むには、100％の改良も、この先にある可能性と比べれば取るに足らないものであることを示さなければならない。1000％の改良をプロジェクトの結果として達成するには、手軽に実現される100％の改良以上の取り組みが望まれる。それをこそ、やらなければならない。インパクトの高いプロジェクトに的を絞って、大当たりを捕るのだ。

2005 年 3 月 28 日