#june29jp

書籍「Inspired: 顧客の心を捉える製品の創り方」 - 29%の純情な感情で言及したやつ、1週間くらい前に読み終わっていた。Kindle で気になったところをハイライトしながら読んで、最終的に64ヶ所をハイライトしていたので、その中からいくつかピックアップしてここに貼って、一言ずつだけ添えて、それを読書記録としよう。

ソフトウェア製品の開発を左右する要素はまだ他にもあるけれど、すべては、いいチームを作ることから始まると確信している。

いいソフトウェアはいいチームからしか生じない。まずは、自分がいいチームメンバーとして振る舞えるようにがんばるところから。がんばるぞ。

デザイナーというのは、製品開発のうんと早い段階、つまり、プロダクトマネージャーがターゲットとなる市場を把握してソリューションを考えている段階から参加してこそ、その真価を発揮できるのだ。

同意。デザイナさまのこと、めっちょ頼りにしている。身のまわりにおいても、デザイナさまは頼りになる人が多い。

製品化すべきものを正しく選ぶことは、会社が行う意思決定の中でもいちばん重要なものなのである。

これな…… そしていちばん難しいのでは、とも思う。

この業界では、製品開発においては、製品要求を定義することと製品をデザインすることは連続的で予測可能で計画的なフェーズである、という考え方がかなり根強く浸透している。これは、製品を作る企業では、時として、最も抜け出すのが難しい思考パターンの 1つとなっている。でも、みんなこれを克服しなくちゃならない。製品を作る会社ならば、新製品を発明するプロセスとは基本的に創造的なものである、という事実を受け入れる必要がある。それはサイエンスというよりもアートなのだ。

「サイエンスというよりもアートなのだ」と言われて思い出すのは書籍「ウェブオペレーション」ですね。

ウェブオペレーションは技芸であり、科学ではない。正規の学校教育・資格・標準は (少なくとも今はまだ) ない。我々のやっていることは、学習にも習得にも時間がかかり、その後も自分自身のスタイルを模索しなければならない代物である。「正しい方法」はどこにも存在しない。そこにあるのは、(とりあえず今は) うまくいくという事実と、次はもっと良くするという覚悟だけだ。

となると、我々はエンジニアリングの他に、アートと技芸も駆使して生き抜いていかなければならない…！本当に勝ちたいと思ったら覚悟が要求される。

そして、第三に、社員の多くは、本当はそうではないのに、自分のことを製品のターゲットであるユーザーに近い存在と考えている (あるいは、ターゲットユーザーのことを実際以上に理解しているつもりになっている)。

あっ、はい…

製品開発チームがいちばんよくやってしまう間違いとしては、自分たちを顧客と混同するというのも挙げられる。私がとにかくペルソナを気に入っているのは、よくありがちなこの問題に光を当てるのに役立つからだ。

あっ、はい……

そもそもぼくは「自分がひとりのユーザとして愛用しているサービスの開発に従事したい」と思って今の現場に飛び込んでいるから、これちょっとどうやって受け止めたものか悩んでいることを白状しておきます。…とはいえ、弊ビスを利用してくれている人々の様子を見てみると、メインのターゲットは自分とはぜんぜん違う生活をしている人たちだ、ということはこの3ヶ月間でだんだんと理解できてきたので、とにかく「混同していないか？」という問いかけは頻繁に行っていこうと思った。

「ぼくはこう思ったッス」は明確にそのように示して、それを「ユーザはこう思ってるッス」に拡大解釈しないように気をつける。主語を大きくしない。

個人向けのサイトを設計するときに、開発プロセスのかなり遅い段階 (ベータ版の公開や正式版の発売の時期) まで、実際のターゲットユーザーにきちんとサイトを見てもらっていない、といったことになりがちである。でも、これはかなりまずい。

あっ、はい…

現実にはユーザーはだれなのかを理解しているか？ ユーザーは製品をどんなふうに使っているのか？ ユーザーは製品をどうやって使うかを理解できているか？ ユーザーはどこでつまずいているのか？ なぜユーザーはこの製品を使うのか？ ユーザーは製品のどこが気に入っているのか？ ユーザーが製品にあればいいと思っていることや、変えてほしいと思っていることは何か？

がんばるぞ…！

時として、ユーザーについての思い込みや固定概念をもとにペルソナを創るだけで、現実のユーザーと話す時間も取らず、ペルソナとして設定された人々が実際に世の中に存在するのかを確かめないチームもいる。これには何度も驚かされてきた。

これは今まさに乗り越えようとしている問題。お話する時間を持つぞ。

とにかく、プロダクトマネージャーとしていちばん大切な仕事を 1つだけ挙げるとすれば、おそらくそれは、製品のアイデアを実際のユーザーといっしょにテストすることである。

ほむほむ。

たいていの会社は、人手も資金も限られている。でも、それであきらめてはいけない。現実のユーザーでアイデアを試すことは、絶対にやらなければだめだ。最初にも言ったが、プロダクトマネージャーの仕事としては、まず間違いなく最重要任務なのだから。

やるぞ。

プロダクトマネージャーの第一の任務は、価値のある、使いやすい、実現可能な製品のアイデアを見つけ出すことである。そういうものを見つけ出したという確証が得られるまでは、開発を始めても意味がないのだ。

闇雲に開発を始めてしまわないように。

自分用の補足

ところで、ぼくは別に「プロダクトマネージャー」という肩書きがあるわけでもなくて、上記に引用した文章たちの中でも何度も何度も語られている「プロダクトマネージャーは、これをやれ！」というの、ぜんぶ自分がやらなきゃいけないとは思っていない。プロダクトマネージャーというのはチームの中の特定の誰か、というよりはチーム内に求められる役割で、チーム全体でプロダクトマネージャーという役割に期待される振る舞いをカバーできていると望ましい、と捉えている。誰もそういう振る舞いを持っていないとまずいことになりそう、誰もそういう振る舞いを持っていないとソフトウェア開発が虚空に向かう、という捉え方をしている。

なので、まずはぼく自身もチームメンバーのひとりとして、プロダクトマネージャーという役割についての理解を深め、身に付けられそうな考え方や振る舞いについては体得して、貢献的に動いていきたい。そんな気持ち。

次は何を得ようか

ちょうど自分が読み終えたころに id:ninjinkun さんのInspired: 顧客の心を捉える製品の創り方を読んだ - ninjinkun's diaryというエントリが話題になっていて、そちらに登場している別の書籍も手に取ってみようかな、と思っている。弊社 CTO のお姿も見えるやんけ…。

「実装のフェーズ」であれば、これまでやってきた経験もあるので、これをやってこれをやってこれをやれば完成、みたいなロードマップを頭の中にスムーズに描けるし、ざっくりどれくらいの手数や時間を要するか、という感覚値も持てるのだけれど、プロダクトマネージャー業みたいなやつ、自分の中に確固たるものがないので、まるで土地勘のない場所を移動するときのようで、地図を見ながらじゃないと歩けそうにもない。しばしば道に迷う。目的地に着くのがいつごろになるのかも把握しづらい。これは知識を身に付けつつ経験を積むしかないですかね…！いろいろと試してみては思うようにはいかなくて、悩んで、まわりに相談して、というのを繰り返すフェーズがしばらく続きそう。泥にまみれろよ。

次に自分はどんな問題にぶちあたるだろうか、ということもわかっていないので、次にどの書籍に手を出すかも決めかねている！ユーザーストーリーマッピングはよさそう。

謝辞

社内の勉強会でこの書籍を扱っているので、自分ひとりで読むだけじゃなく、感想を持ち寄ったり、みなさんの現場ではどうですか〜みたいな議論をできる場があって、ものすごく感謝しています。ありがとうございます。次は、他の書籍についても読んで話して、ってのをやりたいですね。