アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣 Venkat Subramaniam and Andy Hunt

長い長い前置き

とあるスマホ向けアプリがある。そのアプリ、いま流行りのゲーミィフィケーションを取り入れた写真シェア系アプリで、悪くない出来だとは思う。

……まぁ、同じ部署の人が企画したアプリなんだけどね。
その企画者が、ユーザ数が伸びないという事を話していた。まぁ、そうだろうと思う。だって、同僚の僕ですら、(義理としてでも)使ってないのだから。

何故新規ユーザが伸びないのか

アプリ自体は面白いと思う。ただし、もっと多くのユーザがつかないと、写真シェア系のアプリは真価を発揮しないともおもう。だって、シェア系の面白さって、自分が知らないいろんな素敵な写真がみれることでしょ(それは猫画像かもしれないけれども）？　と僕はおもってる。

さて、何故ユーザがつかないのか？ もしくは、何故僕が使っていないのか。
僕が使っていない=インストールしたくなかった理由は、ティザーサイトに情報が全くなく、しかもダサかったからだ。

アプリの名前と、App Storeへのリンク、人物のシルエットから構成された絵が書いてあるだけのサイトを 見て、わざわざアプリをインストールしたくなるだろうか。

ティザーサイトをどうにかするべきだ、と、企画者に伝えたら、「アップロードされた写真を掲載できるようにする」との回答をいただいた。
……が、そういう意味ではない 。

ティザーサイトに載せるべき事

ティザーサイトに必要なのは、「そのアプリを使う事でどういう体験ができるか」を掲載する事だ。
ユーザの動きに沿った説明を、簡潔に、しかし、ビジュアルも交えて、そのアプリを使っているシーンを、もしくはそのアプリの世界観の中にいるユーザ自身の姿を、ユーザが想像できるようなコンテンツを設ける必要がある。
そうしないと、素姓のわからない、謎アプリを、自分のスマホに入れようなんて絶対に思わない。

そして、ティザーサイトを一目見て、アプリをインストールせずに離脱したユーザは、二度と戻ってこないのだ。

このアプリの失敗は、人目にもっとも触れるであろう、プレスリリースを打ったときにティザーサイトがものすごくプアーだった点だ。

え？　instagramは？ とか他の有名アプリの例を引き合いにだす人がいるかもしれないけれども、ああいうところは、すでにtwitterやfacebookを通して、その素敵な世界を多くのユーザが体験しているから大丈夫。あと、自らブログとかで積極的にユーザ体験を出してるしね。
嫁コレのページなんかは、ユーザ体験を一生懸命伝えようとしている。（ダサいけど……）

確定申告のすすめ

そういえば、同じ人から「確定申告したらいくらかお金がもどってくるよ」という内容で、確定申告のすすめをうけた。

勧めの内容としては、確定申告すれば、こういうメリットがあってこんくらいおかねがかえってくるよ！ Webで書類が簡単につくれるよ！ と、まぁ、 こんな感じ。

その後、twitterで「具体的な方法を教えてください」と言ったら、「 具体的？画面見ながら教えることは出来るけど、それでよければいくらでもｗ」と、回答を得た。
いや、そういう意味じゃなくて。。。

ユーザにとって何が価値ある情報なのか

僕は、確定申告すればいくらかお金が戻ってくることは知ってるし、webで手続きが出来て、パソリが必要なことや、自治体の電子証明？的なものが必要という事も知っている。 MacOS Lionでは申告できないことも。etc etc

……お気づきかと思うが、いろんな情報がごちゃごちゃに、混じってしまっていて、てんでばらばらな妄想が頭の中に広がっているのだ。

なのでここで僕がしりたかった具体的な方法っていうのは、上司が答えてくれた「 ここに行けば今すぐ申告書作れるよ。 http://t.co/iYRzhQPF 」っていう情報だった。
その後、オススメしてきた人から「 あ、そもそもどこから申請すればいいかって事ね…。そこはググって欲しかったｗ」と、言われた。

「勧める」という行為のゴール

確かに、普段からググれカスとのたまう自分のググりが甘かったのは反省すべき点。断片的な情報がありすぎて、ググる事を怠っていた。

でも、ここでは自分の不備を棚にあげて相手の不備を責めてみたい（笑）

他人へ何かを勧めるという行為のゴールは、勧めた人が自己満足することではない。勧めたことを、勧められた人が実践、実行する事だ。
この場合は、僕が確定申告のを行う事がゴール。

ここでググれは、サービスとしてありえない。顧客(=僕)はそう言われた時点で、その勧めには従わないだろう。なぜなら面倒くさいからだ。

顧客に何かを勧める場合は、顧客が何を知りたいのか、 何が欲しいのかを知り、そこに至るように誘導しなければいけない。途中で顧客に調べ物をさせたりしちゃダメだ。顧客はきっと、wikipediaを読む事に熱中して、確定申告などやらないまま終わる。

まぁ、職場での雑談だから、そこまでは求められてないけどね（笑）
あくまで例 です。

……ここまでが、前置き。

なんでこんな事を書いたかというと、アジャイルプラクティスに顧客を嘲笑うテクニカルサポートの話がのっていたからだ

アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣

24. ユーザの声に耳を傾ける　という項。
ちょっと引用する。

　アンディは大企業にいた頃、ハイエンドのUNIXワークステーション向けのソフトウェアを開発していた。setup.exeやpkgaddコマンドだけでインストールできるような環境じゃない。ファイルをいくつもコピーして、ワークステーションごとに設定を変更しなければならなかった。
　アンディやチームのみんなは、まさか顧客がそれで困ってるとは露よども思っていなかった。ところがある日、アンディがテクニカルサポートの横を通りかかると、サポートエンジニアが大笑いしながら電話で顧客の相手をしていた。「あー、それはですねえ、バグじゃないんです。お客様も他のみなさんと同じ勘違いをされてらっしゃいますねえ」彼だけがこんな態度を取っていたいたわけじゃなかった。テクニカルサポート全体が、哀れな何も知らない迷える顧客を笑い者にしていたんだ。

(中略)

インストールマニュアルには確かにこれに関する説明が書いてある。しかし、８割の顧客がその説明を見落としていた。そして拉致があかなくなったので、何とかしてもらおうとテクニカルサポートに電話をしたら、見事にバカにされたというわけだ。

このくだりを読んで、前述の話を思い出したのです。
で、ここからの教訓は、どんなにバカバカしく思えたとしても、ユーザの声に耳を傾けるべし。クレームの背後に潜む真の問題が目を向けられるようになる。
というものでした。

アジャイルプラクティス

アジャイルプラクティスは、アジャイル開発を行う上で重要なTIPSを大量に掲載している。
実際の現場での経験を例にとり、どうすればいいのか、どうするのがアジャイルなのかを書いてある本。
細かく、いろいろな事例が書いてあるので、困ったときに辞書的に見返せる。仕事場の机の上に置いておきたい一冊。

アジャイルは生き方

この本を読んでいると、アジャイルというのは開発の仕方ではなくて、生き方なんだな、という思いが強くなる。
人との接し方や、状況との接し方。そういった、なんというか、生きる基本みたいな点からアジャイルにしていくことができるんだなという印象をうける。
その先にプログラミングや開発技法がある感じなんだけれども、考えてみると、プログラマ/エンジニアってのも生き方だ。

アジャイルなプラクティス、やり方、技法っていうのは、確かに有るんだけれども、最終的に行き着くのはアジャイルな生き方なのかな、と思った。