ユーザー体験ではすべての作業が平等に作られているのではありません。自分が関わりを持っている作業を刺激的だと考えましょう。プロトタイプ作りやUIのデザイン、洗練されたプロダクトのアップグレード、そして概して「新しいこと」に関するものはすべて刺激的な作業になる資格を持っています。
メンテナンス作業はあまりうまくいかない傾向にあります。作家Kurt Vonnegut氏の言葉に「人間の特質の欠点として、誰もがモノを作りたがるが、メンテナンスはしたがらない」というものがあります。
ユーザー体験の文脈で言えば、誰もがデザインとデプロイをしたがるが誰もユーザビリティメンテナンスをしたがらない、ということになります。メンテナンスと聞くと決して魅力的ではないものの、メンテナンスはユーザビリティにとって非常に重要な側面でもあるのです。
ユーザビリティメンテナンスとは
ご推測のとおり、ユーザビリティメンテナンスには、プロダクトやサイト、サービスのユーザビリティのメンテナンスという専門的な領域に焦点が当てられています。残念ながらこの専門分野はまったく存在していません。あるとしてもあちらこちらに分散しています。
ユーザビリティメンテナンスの活動は、こちらでユーザーテスト、あちらで技術サポート会議というように、互いに独立したいくつかの作業に分散しています。しかし、ユーザビリティメンテナンスは単独の分野としては推論の域を出ません。
一般的に「ユーザビリティメンテナンス」という言葉自体はデザインや開発についての話し合いではあまり使われてはいません。その言葉からは定性調査や定量調査を連続的におこなうような漠然とした印象を受けますが、それ以上具体的なことはわかりません。
国際標準化機構（ISO）はメンテナンスをユーザビリティの副次的定義として認めています。次のような説明があります。「メンテナンス作業が効果的かつ効率的で満足のいく形でおこなわれるかという点で、ユーザビリティとメンテナンスには関連性がある」
この定義はやや言葉足らずです。ユーザビリティメンテナンスという独立した領域ではなく、ユーザビリティがメンテナンスに関係しているのはソフトウェアのメンテナンスを可能にすることだけのように見ているからです。この考え方はそれほど驚くべきものではないとしても問題はあります。
ソフトウェアメンテナンスのパラダイム
ソフトウェアメンテナンスには明確な定義のもとで決まった役割が確立されています。実際に、デプロイ後の運用費と活動の70%以上をソフトウェアメンテナンスが占めています。
奇妙なことにソフトウェアメンテナンスは定番作業のひとつと認知されています。多分どのような活動がおこなわれるかについてもある程度知られています。バグフィックス、セキュリティパッチ、リファクタリング、機能や互換性の改善などのメンテナンス作業とその役割は最初に調べなくてもおおまかに認識している人がたくさんいます。
確かに、現場でのこのシンプルな認識は重要な意味を持ちます。Googleで「software maintenance（ソフトウェアメンテナンス）」を検索すると2,110,000件の結果が得られます。求人サイトIndeedでの検索結果は15,200件です。ソフトウェアメンテナンスは日常の作業工程の中で記録と定義がされて深く根付いた領域なのです。
ユーザビリティメンテナンスはそのような人気はありません。「usability maintenance（ユーザビリティメンテナンス）」をGoogleで検索した結果11,000件、またはIndeedの検索結果1,480件と比べてください。ほとんどの人にとって、ユーザビリティメンテナンスという言葉を具体的な作業や職業に結びつけるには、ある程度のレベルの調査が必要になるでしょう。
このことによって、ユーザビリティメンテナンスが日常的におこなわれている明快な仕事のひとつとして認識されていないのはなぜなのか、という疑問が生まれます。
デプロイ後の小休止
ユーザビリティの観点からはメンテナンスはデプロイの興奮と喧騒のあとの遠い景色へと消え入りがちです。2011年の研究によると、デプロイ後にユーザビリティは小休止のような状態になります。調査対象となったユーザビリティの専門家の87%がデザインフェーズにいつも関与している一方で、デプロイ後のフェーズに直接関わっているのは50%でしかないことが報告されました。しかも70%がほかのプロダクトや既存プロダクトの時期バージョンにすぐさまとりかかっていました。
こういった調査はユーザビリティメンテナンスがおろそかにされていることを反映しています。ローンチが成功するとユーザビリティの役割が先細りすることがとても多いです。プロダクト、サービス、Webサイトがしっかり稼働している。うまくいった。では次に何をするか？ デプロイ後のユーザビリティメンテナンスをするかわりに、次のプロダクトやリリースに関心が移りがちです。サイクルのペースが速いのでユーザビリティメンテナンスがそれ自体ひとつの分野として登場する余地はあまりありません。
絶え間ない変更
この業界の文化は「技術革新」にとらわれています。最新のクールなものに関する盛り上がりはメンテナンス全般の軽視につながり、平凡な「メンテナンス担当」を敬遠しがちです。このことはすべてプロダクト開発とユーザー体験の世界にあてはまります。
ユーザーが遭遇するプロダクト変更は容赦ないペースです。際限ないアップデートの繰り返し、四半期ごとのリリース、新製品のローンチなどによってメンテナンスよりも構築の方が絶えず求められます。UXの（表面上の）派手さや名誉は技術革新の中にあって、その後のメンテナンスにはありません。
ところで、このリリースサイクルがユーザビリティに恩恵をもたらさないというのはフェアではないでしょう。クールな新しいインターフェイスへの変更や機能の拡張が結果的にユーザビリティを向上するということはよくあります。問題は、専門的なユーザビリティメンテナンスが見落とされ、ぼんやりとした「技術革新」という衣に注意をそらされた中でこういった変更がおこなわれがちだということです。
さらに、ひっきりなしにリリースされることにはマイナス面があります。ソフトウェアに過剰な機能が搭載され、デザインが使い捨てられ、ユーザーの不満が高まるといったことはすべて共通して、デプロイに次ぐデプロイに追い立てられて生じる副作用です。次から次へとピカピカの新しいもの、つまり派手な新機能を作り出すレースです。このレースは着実なユーザビリティメンテナンスを置き去りにします。
ユーザビリティメンテナンスの必要性
ユーザビリティメンテナンスなしでこれまでやってきました。では、なぜ必要なのでしょうか。実のところメンテナンスと修理はほとんどの技術革新よりも日々の生活に影響を及ぼすということです。実際、「技術的大停滞」のまっただ中では、技術革新は、かつての技術的大躍進のようにはうまくもいっておらず、世界を揺るがしたりもしません。
その代わり、ユーザビリティを継続的に改善することでユーザーへのプラスの影響が保証されます。これによって小さな傷を何回も繰り返してユーザーをうんざりさせることが避けられ、楽しい体験を長期にわたって提供できます。
Parmit Chilana氏は「ユーザビリティの分野ではユーザビリティメンテナンスに関心を向ける必要がある」と書いています。重要な点は、このメンテナンスはソフトウェアやプロダクトのメンテナンスとは別のものであるということです。コードの正確さといった要素に焦点をあてるのではなく、もっぱらユーザーをサポートすることに特化し、デプロイ後のユーザー体験を継続的に改善することに重点を置いています。
UXの熟練者にはこの種の継続的なユーザーサポートを支持する人が多いでしょう。ユーザーにとっては当然のことであり、プロダクト提供者の名声のためには必要なことなので理解できます。しかし、ユーザビリティメンテナンスのために積極的に時間を割いたり検討したりする企業はほとんどありません。
現在の「ユーザビリティメンテナンス」の例
現在のユーザビリティメンテナンスは散発的になりがちです。ブランド企業はオンボーディングプロセスやチェックアウトのページなどのコンバージョン領域でユーザビリティのテストをおこなうでしょう。大きなリリースの際にユーザーテストを完了するかもしれません。または、競争相手に打ち勝つための戦略の一部として外部の企業にユーザビリティ調査を依頼するかもしれません。
デプロイ後におこなう計画的で首尾一貫した密度の濃いユーザビリティメンテナンスは平凡で魅力がなく、あまり一般的ではありません。継続的なユーザーテストもしばしば提唱されますが採用されることはまれです。しかし、この日々の裏方的作業がユーザーを深く理解し、ユーザーからずっと続けて評価されるために役立つのです。
ソフトウェアのメンテナンスはおこなわれています。悪いコードはリファクタリングされます。ではなぜ、ユーザビリティに対してそれと同じ考え方をしないのでしょうか？
まとめ
技術革新に心を奪われた世界でメンテナンスは軽んじられています。確かにメンテナンスは新しいものを次々に作り出すことほどにはまったく魅力的ではありません。しかし、エンドユーザーにとっては、少なくとも同じく重要なのです。
ユーザビリティメンテナンスはプロダクトの技術革新の敵ではありません。しばしば競争相手となるまさにその技術革新を静かに献身的にサポートしているのです。
ユーザビリティメンテナンスもプロジェクトの仲間に加えてみてはどうでしょう。
