Inspired日本語版

第24章 ユーザーにやさしい緩やかなバージョン移行
ユーザーに苦痛を与えないために

「ユーザーに苦痛を与える」というのは、製品のユーザーに対してユーザーが歓迎しない変更をリリースすることで、意図せずに (だといいのだけれど) 無用な負担をユーザーにかけてしまうことだ。ユーザー全員が製品の変更を歓迎してくれるわけではないとは信じたくないかもしれないが、それが現実である。ユーザーがそう感じる理由はいくつかある。



• 変更について何も知らされていなかったので、面喰らっている。しかも、不意を突かれても大丈夫な状態ではなかった。
• 今は変更を理解して対応する時間の余裕がなく、しかも、変更するまでの間、古いバージョンを使い続けられるような手当がされていない。

• 新しいバージョンがちゃんと機能しない。
• 新しいバージョンに以前のバージョンとの互換性がない (データへのアクセスなど)。
• 新しいバージョンは機能するけれども、別に新しくした意味がない。

• これまでやった変更だけで、もう、うんざり。
• 前のバージョンを前提にして作業手順や操作のパターンを組み立ててしまっていたので、新しいバージョンに合わせてまた作り直さなければならない。

なぜユーザーに苦痛を与えてしまうのか？
まず、いちばんに挙げられるのは、変更すること自体が問題だということだ。一般的に、ユーザーは変更を歓迎しない。確かに、ユーザーは、よくできたソフトウェアを使いたいと思っているし、新しい機能も要求する。でも、多くの人々は、すでにできていることをやるために、時間を使って別のやり方を学びたいなどとは思っていない。

これは何とも困ったことだ。私たちの多くは、新しいやり方を生み出すことでビジネスをしているからだ。製品開発チームには、製品をみんながもっと使いたくなるようなものにして、新しい機能をユーザーや顧客に届けるために、立ち止まることなく頑張ってもらっている。人々のニーズは変化し、技術も変わり、市場も変わる。だから、ソフトウェアもそれに合わせて変わらなければならない。

ユーザーの苦痛を解決する方法は、変更を避けることではなく、賢いやり方で変更を展開することだ。

製品のバージョン1.0 を開発するときに楽しいのは、ユーザーとまっさらの状態からスタートできることだ。確かに、ターゲットするユーザーは、すでに市場に出回っている他の製品やサービスに影響される部分もあるけれど、全体としては、古いバージョンとの互換性とか、ユーザーに操作方法を勉強し直してもらう、といったことはあまり心配しなくて済む。でも、私たちのほとんどは、既存の製品やサービスのアップデートや新しいバージョンへのアップグレードで飯を食っている。

以前であれば、ソフトウェア会社は、もっと安易に、互換性の低い無茶苦茶なアップデートを出すことができただろう。ユーザーは、もしそうされても、文句は言うだろうけれど、世界中に散らばるユーザー予備軍に影響を与えるとか、その製品を市場から追いやってしまうなんてことは、まずできなかった。でも、インターネットが普及して、ユーザーの製品レビュー (いい評価も悪い評価も) が巷に溢れる今日この頃では、まずいものをリリースしたまま問題をさっさと修正しないでいると、深刻なユーザー離れが起こると肝に銘じておかなければならない。

大規模な一般消費者向けインターネットサービスの場合、状況はもっともっと深刻になる。こうしたウェブサイトでは、ソフトウェアのアップデートをはじめとして、そこでの一挙手一投足がユーザーに与える影響を考慮しなければならない。私は、たくさんのユーザーに対して、賢明なやり方で、慎重に製品のアップデートをリリースするプロセスを、「緩やかなバージョン移行」と呼んでいる。

変更が引き起こす混乱を最小限にするという趣旨で、製品に対する変更を緩やかに展開するのに役立つ手法をいくつ紹介しよう。

第一に、ニュースレター、オンラインでの教育プログラム、チュートリアルといった手段を通じて、変更の内容を前もってユーザーに知らせるためにできることは何でもやっておこう。でも、多くのユーザーは、こういう通知を読むだけの時間もなければ、読む気もないので、この方法だけではたかが知れている。

第二に、もし製品の新しいバージョンが正しく動くかどうかに少しでも疑問があるなら (信頼性に問題があるのか、拡張性なのか、パフォーマンスなのかを問わず)、品質保証のためにふだんの倍の努力が必要だ。そうでないと、後からアップデートを回収する羽目になって、ユーザーの不安をただただ煽ることになるだろう。

第三に、大規模な変更の場合は、旧バージョンとの併用や段階的な導入といった緩やかな移行を進めることによって、変更のリスクを抑えることが重要だ。

これを実現できるやり方としては、製品の新しいバージョンを古いバージョンと並行して使えるようにしておいて、ユーザーに対しては、時間のあるときに新しいバージョンを試すことができるオプションを用意するのがいい。新しいバージョンを試したユーザーが望めば、新しい方をデフォルトに設定できるようにもしておこう。ユーザーの大部分が新バージョンに移行して、うまく動作しているという確信が持てた時点で、新バージョンをデフォルトとするといい。このとき、すぐに新バージョンの変更を理解するだけの時間がないユーザーのために、一定の期間、古いバージョンを使い続けられるようにしておく。この人たちには、古いバージョンのサポートをいつ打ち切るかについて、しっかり告知しておこう。大勢のユーザーを抱える大口の顧客や大きなユーザーコミュニティを抱えるサービスの場合、このプロセスには何ヶ月もかかることを忘れないように。一方、同時に複数のバージョンをサポートすることは楽ではないので、開発部門や運用部門から文句が出ることも覚悟しておこう。

緩やかに移行する別のやり方としては、地域別に変更を導入することも考えられる。まず、新しいバージョンを特定の国か国内の特定の地域だけで展開して、そこから、展開する国や地域を広げていく。その他にも、変更を段階的に導入するやり方もある。変更を小さな単位に分けて、時間をかけて少しずつ導入していくのだ。

ただ、どういうやり方でも、肝心なのは、製品の変更が引き起こす混乱というものにできる限り気を配ることだ。ユーザーに対しては、時間がある時にどこが変わったかを学べる機会を提供して、とにかく、変更によって起こるかもしれない困難や問題の影響を最小限に抑えるように努力しよう。

ユーザーがその製品やサービスが気に入ってくれているなら、彼らから当てにできる善意は十分蓄積されているだろう。でも、そういう善意の貯金は、どうしても必要な時のためにとっておこう。無理なバージョン移行でユーザーに苦痛を与えることで、その貯金を無駄使いしてはいけない。