6.3 ユーザーとの関係を管理する一 169 ソフトウェア工ンジニアはユーザーと直接やり取りをせすに「ユーザーは何 もわかっていない」と考えている。「話すのめんどくさいし、マトモに相手する のは無理ですよなどと言ったりする」。何もユーザー全員に愛を注げと言ってい るわけではない。ユーサーは自分の意見を聞いてほしいだけだ。無意味な提案 や根拠のない不満を言ってきても、そのことを認知することが重要である。議 論や開発のプロセスに参加してもらえれば、ユーザーはそれだけ忠実で幸福に なっていく。ユーザーの意見に同意する必要はなく、ただ耳を傾ければいい。 ソーシャルメディアの時代の到来で、ユーザーを集団ではなく人間として扱う ことが重要だということがわかってきた。ユーザーは、顔のない会社には関心 がない。 HRT のある会社なら好きになってくれるはすだ。 もう 1 っ簡単な ( ちょっとだけ非科学的な ) グラフを見てほしい。これを使っ てユーザーとの関係を構築する重要性について説明したい。時間が経過すると 増加 ユーザー 複雑さ 時間 - → 図 6-10 プロダクトのユーザー数を計測する

ー 6 章ユーザーも人間 170 ソフトウェアはユーザーを獲得する。もちろんプロダクトを「改善」しているの で、複雑さも増えてくる。 こで問題なのは、ユーザーが増加すると一般人の割合が増えて、技術能力 の平均レベルが下がるということだ。このことを複雑さと一緒に考えてみよう。 つまり、ユーザーの失望という深刻な課題に遭遇することになるわけだ。 ユーザーが失望するとそれだけ苦情も増える。怒ったユーザーも増える。ソ フトウェア開発者とのオープンなコミュニケーションも必要になる。 技術能力の平均 増加 時間 - → 図 6-11 ユーサーの満足度を時間軸で計測する 失望 ユーザー 複雑さ 多くの会社では、プログラマとユーザーの間に壁を作っている。苦情の電話 をたらい回しにしたり、「ヘルプチケット」として保存したものを、ソフトウェア を開発していない人が対応したりする。プログラマに届くまでにいくつもの壁

6.4 ユーザーのことを忘れない一 177 はハードなコンピュータサイエンスをやってるところだが、祝日や記念日の 「 doodle 」ではユーザーを驚かせている。何かの記念日をイメージした小さな アートワークにすぎないが、それが大量のフィードバックやオフィスでの立ち 舌につながっている。 恐怖がユーザーを刺激することもある。もちろんユーモアがある前提だ。 ソーシャルネットワークを開始した会社が、新規ユーザーに画像をアップし てもらおうと考えた。そして、まだ画像をアップしていないユーザーに怒りの ディック・チェイニーの画像を表示することにした。すると、一斉に画像が アップロードされ始めたのだ ! ちょっとした喜びやユーモアを ( うまく ) 取り入れることで、ユーザーのこと を考えていることや、関係性を大切にしていることが伝わるのである。 一三ロ 6.4 ユーザーのことを忘れない 本章では、さまざまなアイデアを紹介した。最後にポケットに入るように 3 つのコンセプトにまとめよう。 マーケティング ソフトウェアがどのように見られるかに気を配ろう。それによって、 ソフト ウェアを使ってもらえるかどうかが決まる。 ユーサビリティ ソフトウェアが簡単に試用できなかったら、遅かったら、使いにくかった ら、アクセスできなかったら、ユーザーは立ち去ってしまうだろう。 顧客サービス ューザーとの長期的な関係構築が、 ソフトウェアの進化やユーザーの定着 に影響を与える。 プログラマの仕事には中断がいつばいだ。 コードレビュー ュ レ 設

6.3 ユーザーとの関係を管理する一 171 がある。プログラマに危険な暴徒を近づけないようにして ( コーディングの邪魔 にならないようにして ) いるかのようだ。こうして、ユーザーは会社に無視され ていると感じるようになる。そして、開発者はユーザーから引き離されてしま ューザーの意見は直接聞いたほうがいい。パプリックなバグ管理ツールを用 意して、苦情があればそこに書き込んでもらうのだ。そして、直接返信するの である。ユーザーがお互いに助け合えるメーリングリストを作るという方法も ある。プロダクトをオープンソースにできるのであれば、それでもいいだろう。 ューザーを「人間」として扱えば、それだけプロダクトのことを信頼してくれる し、苦情や不満も減っていく。こちらの想定していない ( 素晴らしい ) 方法でプ ロダクトを使用している人を探してみよう。ソフトウェアの使用方法は、ユー ザーに直接聞くしかない。賢い使い方やワクワクするような使い方をしている はすだ。 6.3 見下さない ューザーとやり取りをしたくないのは、ユーザーのことをバカだと思っている からである。ユーザーはソフトウェアを開発できない。したがって「ユーザーは バカ」である。そう思っているんでしょ ? ユーザーとやり取りをするときに重 要なのは、絶対に相手を見下さないということだ。コンピュータを扱う能力が 高ければ、一般的知能が優れているわけではない。頭のいい人であっても、コ ンピュータを単なる道具として使う人は多い。デバッグしたり科学的手法で問 題を調査したりすることに関心はないのである。たとえば、車の分解や修理が できる人は多くないだろう。ユーザーのことをバカだと思うのは、トランスミッ ションの修理や問題の診断ができない君のことを自動車工がバカだと思うのと 一緒だ。車はプラックポックスになっている。君は運転するだけだ。多くの人 にとってコンピュータ ( や君のソフトウェア ) はプラックポックスである。ユー

168 ー 6 章ユーザーも人間 どのようにやり取りをすればいいのだろう ? 信じられないかもしれないが、多くのユーザーは君の会社やチームと関係を 築きたいと思っている。ソフトウェアに満足したユーザーは、これから何が起 きるかを知りたいと思っている。怒ったユーザーは文句を言う場所を求めてい る。それなのにプログラマは、ソフトウェアを壁越しにユーザーに放り投げる だけで、こうしたフィードバックに耳を傾けない。 顧客サービスという言葉もマーケティングと同じように否定的な意味合いを 持っている。「顧客サービス」の仕事と言えば、コーヒーショップのバリスタや、 サポートセンターで機械的な対応をする人たちを思い浮かべるだろう。実際の 顧客サーヒ、スは魂が吸い取られるような仕事ではないし、能力の劣った人たち がやる仕事でもない。ユーザーとの関係について考える哲学的な仕事だ。ソ フトウェアチームとしては、外部の不満に対応するだけでなく、積極的に顧客 サービスに関わっていく必要がある。 hjLISerL» 図 6-9 ユーザーは話を聞いてもらいたいだけなのだ

156 ー 6 章ユーザーも人間 古くさいと思うかもしれないが、 Google の社員は複数のプロジェクトでこの 格言を実践することで、プロジェクトの成否を判断しているのである。 Google の大きなプレイクスルーとなったのは、検索広告の効果測定を始め たことだろう。ユーザーが広告をクリックすれば、それはユーザーにとって役 に立つものである。ユーザーが広告をクリックしなければ、それはユーザーに とって邪魔で役に立たないものである。役に立たない広告はシステムから削除 して、広告主にフィードバックを送って広告を改善してもらう。積極的に収益 源を拒否しているわけだから、短期的には逆効果のように思えた。しかし、 ( 広 告主よりも ) 検索者に注目すれば、長期的には Google の検索広告システムの有 用性 ( と利用 ) が劇的に高まるのである。 ユーザーに集中するための重要な方法について説明しよう。 最も大事なこと : ューザーの技術的能力を考えよう。 6.2.1 観客を選ぶ 君の飼って いる金魚 図 6-3 ソフトウェアの想定するユーザー ドナルド・ クヌース

とた 6.3 ユーザーとの関係を管理する一 167 こがソフトウェア工ンジニアの目指す目標となる。これこそがソフト ウェアユーザビリティの意味するところだからだ。 ただし、複雑さを隠しすぎてユーザーを不自由にしてはいけない。複雑さを 隠すには巧妙に抽象化する必要がある。したがって、プログラマとしては抽象 化が「漏れる」可能性を想定しておかなければいけない。プラウザが 404 工ラー を表示したときは、抽象化が漏れている。幻想が破壊された瞬間だ。このよう なときはパニックになってはいけない。抽象化は漏れやすいものだ。うまく手 の内をノヾラすような仕組みを用意しよう。最適なのはプログラマ向けに API を 提供することだ。あるいは、上級ューザー向けに「エキスパートモード」を用意 して、抽象化をバイバスできるオプションや選択肢を提供するのもいいだろう。 インターフェイスを柔軟にするだけでなく、インターフェイスを回避する方 法も必要だ。ユーザーのデータにはアクセスできるようにすべきだ。 Fi レは、 GoogIe プロダクトにおける「データの解放」に熱心に取り組んできた。ユーザー が自分のデータを工クスポートできるというのは当然のことである。インター フェイスがどんなにエレガントであっても、ソフトウェアはユーザーをロックし てはいけない。データを解放して、ユーザーが好きに扱えるようにしなければ、 公正に竸争しているとは言えない。ユーザーがソフトウェアを使うのは使いた いからであって、身動きが取れないからという理由で使うことがあってはいけ ない。データを解放すれば、ユーザーの信頼を得ることができる。それが ( あと でまた説明するが ) 最も大切なリソースだ。 63 ユーザーとの関係を管理する とりあえす第一印象はよくなったとしよう。いいスタートだ。使い始めても らえれば、きっと満足してもらえるし、使いやすいこともわかってもらえる。そ の後の数か月間は何が必要になるだろう ? ソフトウェアを毎日使っている人と す ァーサー・ C ・クラークの 3 つ目の法則を見よ。

164 ー 6 章ユーザーも人間 0 、 0 図 6-7 何だこのプロダクトは ? 6.2.6 怠けない 怠惰の罠には気を付けよう。怠惰は作業の自動化につながるので、プログラ マの美徳だと言う人もいる。しかし、怠惰のせいでユーザーを不便にするコー ドを書いてしまう可能性もある。ユーザーにとって使いやすいソフトウェアは、 プログラマにとって作るのが面倒なこともある。コードを書く側の都合ではな 怠惰の古典的な例は、ユーザーに多くのオプションを与えることだ。 1990 年 わすにやるべきだ。 く、ユーザーに集中しよう。コードを書くのが大変になったとしても、愚痴を言

ー 6 章ユーザーも人間 ツールとの格闘・制作トラブルの対応・バグのトリアージ。そうなると、ソフ ヮ 8 べては自分に返ってくる。 ユーザーはソフトウェアの成功に欠かせない血液だ。自分でやったことは、す ているか、何を体験しているかに注目することが、長期的に重要なことになる。 するためである。ユーザーがプロダクトについて何を考えているか、何を言っ ない。チームのためではない。会社のためではない。ユーザーの生活を豊かに トウェアを書く理由を簡単に忘れてしまう。そのソフトウェアは君のためでは

ー 6 章ユーザーも人間 162 ながっているのである。図 6 のグラフのように ザーエンゲージメントは増えなくなる。 レイテンシー 増加 時間→ 図 6-6 ユーザーエンゲージメントの変化 レイテンシーが上がるとユー アクティブ ユーザー GoogIe であった本当の話。ある日、エンジニアリングチームが Google マッ プの大幅なレイテンシーの改善を行った。事前に告知もしなかったし、プログ にも書かなかった。秘密裏にこっそりとローンチしたのである。すると最初の 数日間で利用のアクティビティグラフが大幅に ( しかも継続的に ) 向上した。心 理状態の大きな変化が起きたのだ ! ウエプアプリケーションの場合は、小さなレイテンシーの改善も重要だ。た とえば、メイン画面の読み込みに 750 ミリ秒かかっていたとしよう。悪くない 数字だ。でも、不満に思うユーザーはいる。これが 250 ミリ秒に短縮できたら、 その 0.5 秒が全体として大きな違いになる。たとえば、 100 万人のユーザーが 1