Inspired: 顧客の心を捉える製品の創り方を読んだ
プロダクトマネージャーの職能+ユーザー体験設計の本です(と解釈しています)。
最近Rebuild: 98: Superhumans Wanted (Naoya Ito)やエンジニアからみた良いプロダクトマネージャとは? - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blogで話題のプロダクトマネージャーに興味があって、関連しそうな本を読みたいと言っていたら、知人がこの本を紹介してくれました。
Netscapeなどでプログラマーをしていたバックグラウンドを持ち、eBayなど複数の会社でプロダクトマネージャをしていた経験を持つ著者がプロダクトマネージャーの職能について語る本で、以下のような内用が含まれています。
- プロダクトマネージャーとは何か
- どうやって他の職種と連携して働くか
- どうやって製品を見つけ出すか
- どうやってユーザー体験を作っていくか
自分にとっては、ユーザー体験をデザインするのはプロダクトマネージャーの責任であるというのを明確に定義しているところが読んで一番良かったところでした。そのためにインタラクションデザイナーと二人三脚でプロトタイプを作ったり、ユーザーテストを実施したりと様々な手法が紹介され、プロダクトマネージャーはそれを牽引する役割であると書かれています。今まで自分が興味を持っていたゴールダイレクテッドデザインやデザイン思考というのは、プロダクトマネージャの仕事だったようです。
以下、線を引いた部分の引用です。
ダメな製品が無駄に世に送り出されるいちばんの原因は、ほとんどの場合、会社の中でプロダクトマネージャーの役割が明確にされていないことと、プロダクトマネージャーとなる人に対する教育が不十分なことにある。
覚えておいてほしい。価値のある、使いやすい、実現可能な製品として作られるべき何かをプロダクトマネージャーから与えられなければ、どんなにエンジニアリング部門が優秀でも意味はない、ということを。
身につまされる…。
長い時間をかけて 1つの領域に精通してしまうと、プロダクトマネジメントのもう 1つのワナに落ちてしまうことがある。それは、自分がターゲットである顧客を代弁する人間で、実際以上に自分がターゲットである顧客に近い存在だと思い込むようになるのだ。
ユーザー目線と自分目線を混同しないようにするのは、自分で使いながら作っていると難しいことが多いです(何度もはまった罠)。
デザイナーというのは、製品開発のうんと早い段階、つまり、プロダクトマネージャーがターゲットとなる市場を把握してソリューションを考えている段階から参加してこそ、その真価を発揮できるのだ。
これはデザイナーではない自分もよく思うことです。最初からデザイナーが関わってくれないと心細い…。しかしデザイナーがプロダクトマネージャーの場合は一人で良いのだろうか。
世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法【委託】 - 達人出版会を読み終えたところだったので、プロダクトマネージャーの理解が深まって良い本でした*1。
余談ですが、英語版は2008年の出版で、翻訳は2015年、しかもなぜかKindle版のみ(そして1200円!)という謎の本です。おそらく訳者の方々がどうしても出したかったとか、思い入れが強い本なのではないかと想像しています。
- 作者: マーティケイガン
- 出版社/メーカー: 株式会社 マーレアッズーロ
- 発売日: 2015/02/07
- メディア: Kindle版
- この商品を含むブログ (1件) を見る
8/3追記
どうも最初は2012年にiOSアプリとして出ていたようです。最近になってKindle化されたんですね。
Inspired 日本語版 発売! | Inspired日本語版
8/3追記
プロダクトマネージャの話、これ読むのがいいと思う 『ドキュメント トヨタの製品開発: トヨタ主査制度の戦略,開発,制覇の記録』 http://t.co/o6UkPwqjE2
— あんちぽちゃん (@kentaro) 2015年8月2日
プロダクトマネージャのおすすめ本募集してます
— ninjinkun (@ninjinkun) 2015年8月2日
この酒井さんの本はプロダクトマネージャーについて知りたい人が読むと良いかも。 / “トヨタに学ぶ 「滅びる組織」「伸びる組織」 売れ続ける秘密は「SHUSA」にあり! | Forbes JAPAN(フォーブス ジャパン)” http://t.co/9XiawlveKy
— あんちぽちゃん (@kentaro) 2015年8月3日
8/3追記
弊社Fablicの社長 @shota もおすすめとのことです。社内チャットから転載。
ninjinkunがレビュー上げてた下記の本、自分も前に読んだんですが、非エンジニアにとってはまず用語の理解、 プロダクトマネージャー(PO)、プロジェクトマネージャー(PM)の違いなど、開発する側と対等に話すための前提知識が 詰まってたので、僕もおすすめです。 特に非エンジニア職の方。
12/1追記
弊社の人事も最近読んだようで、「開発のことが理解できて良かった」とのことです。確かに人事の人にもおすすめかもです。
*1:他にも、このInspiredを薦めてくれた知人が紹介してくれた、HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか の「良い製品マネジャー、悪い製品マネジャー」という章も良かったです
■
4月にDroidKaigiで発表してから、しばらくアウトプットを減らしてのんびりしていた。充電期間というと聞こえは良いけれど、実態としてはぼうっとしていただけである。
自分はこういう意識が高いとき、低いときを一年の中でサイクルとして繰り返している気がする。
意識が高いときは
- 勉強会で発表する
- GitHubでモジュールを作る
- ブログを書く
- 定期的にランニングをする
- 週末は食事を作り置きする
など、もろもろの活動ができる。
今回のように意識が低いときは
- 何もしない、ぼうっとする
- 漫画を大量に買う
- ゲームの時間が増える
- 今回は丁度スプラトゥーンが出たのでな…
- 飲酒が増える
- 太る
など、あんまり生産的とは言えない、でも楽しい生活になる。
常に意識が高いモードは疲れるので、一年の半分くらいは意識が低いモードで暮らしている。体重が増えて鏡を見るのが辛くなってくると、またランニングを始めるなどしてモードが切り替わっていく。
そろそろまた勉強会等にも顔を出して行こうと思います。
誰のためのデザイン?増補・改訂版を読んだ
自分が最初に元の誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)(初版はPOETと呼ばれている*1 )を読んだのは十数年前でした。4月に出たこの改訂版を読み返してみて、改めて感銘を受けました(そして内容をほとんど忘れていたのに気づきました)。
内容としては、エモーショナル・デザイン―微笑を誘うモノたちのために 、複雑さと共に暮らす―デザインの挑戦など後の書籍で検討された内容が盛り込まれて、ノーマン著作の集大成になっています。
自分がこの改訂版で注目しているのは、「6章デザイン思考」の追加です。
6章デザイン思考
正しい問題を発見するのがデザインである として、そのための手段としてデザイン思考が解説されます。
具体的にフレームワークとして取り上げられている人間中心デザインプロセスを見てみると、
観察→アイデア創出→プロトタイピング→テスト→観察…
というサイクルになっており、他のデザイン思考関連書籍でもお馴染みのものです。
今こういったデザイン思考のためのフレームワークは、Web業界やアプリ業界でもリーン・スタートアップ関連やDesignSprintなどを通じて広まりつつあると感じています(手前味噌ですが、自分が所属しているFablicもデザイン思考が企業文化になっている会社です)。
おそらくこうした業界への浸透の背景もあって、入門書である本書にもデザイン思考の章が追加されたのだと思います*2*3(個人的にはIDEOの本よりこっちの方が読みやすい…)。この章の追加により、POET版の「いい話だったけど、どう活かしたら良いんだろう?」という読後感が払拭されており、より実践的な本になっていると感じます。
最後の参考図書にはAbout Faceなどの書籍等が多数上げられており、デザイン思考へのポインタとしても有用です。
おわりに
改訂を機会に読み返した本書ですが、POET版の良い部分は残しつつ、デザイン思考や企業での実践に言及することでさらに進化していました。
POETを読んだときの自分は学生だったので、「テクノロジーが使いにくいのは人間のせいではなく、デザインが悪いのだ」という発想そのものに感銘を覚えました。
そして今、プログラマーとして社会に出た自分には「テクノロジーに関わる人間全員がデザインを実践することでものは確実に良くなる。そしてそれは楽しい仕事だ」というメッセージがストレートに刺さってきて、そうした自分の変化も再読の面白さの一つでした。
自分はこの本をこの先何度も読み返すと思います。今回25年ぶりの改訂で、また次の25年間も耐えられるようになったとのことなので、次に読むときはどんな風に読めるのか楽しみです。
私が確実に予想できるのは、人間の心理学の原則は変わらず残るということ、つまり、心理学、人の認知、情動、行為、世界とのインタラクションに基礎をおいた、本書に述べるデザインの原則は変わらずに残ると言うことである
誰のためのデザイン? 増補・改訂版 ―認知科学者のデザイン原論
- 作者: D.A.ノーマン,岡本明,安村通晃,伊賀聡一郎,野島久雄
- 出版社/メーカー: 新曜社
- 発売日: 2015/04/23
- メディア: 単行本
- この商品を含むブログ (1件) を見る
*1:書名The Psychorosy of Everyday Thingsの略
*2:IDEOなどデザイン思考を牽引する組織はノーマンの影響を強く受けているらしく、POETでまかれた種がデザイン思考として結実し広まったと解釈することもできそうです
*3:自分はこの章を98年のインビジブルコンピュータ―PCから情報アプライアンスへで提案された企業でのデザイン実践と読み比べて、前著での提案が今ではこうやって企業で実践されるようになったのだなーと勝手に盛り上がっていました
双眼鏡
ごくたまにコンサートを見に行くのだけど、毎回安いチケットしか買わないので、遠くからしか見られなかった。もう少し楽器の弾き方とか顔とか見たいと思ったので、Amazonで売ってた一番安い双眼鏡を買ってみたところ、すごく楽しめるようになった。手元も表情も見えるし、自分用のテレビカメラを持っているような気分。たった2000円でここまで楽しみ方が変わるとは思わなかった。おそらく観劇が好きな人とか、その筋の人には常識だと思われる。
NASHICA 双眼鏡 SPIRIT 10×21 CR-IR-W ポロプリズム式 10倍 21口径 シルバー 10×21CR-IR-S
- 出版社/メーカー: ナシカ
- メディア: Camera
- 購入: 5人 クリック: 38回
- この商品を含むブログ (2件) を見る
スマートフォンアプリでリアクティブプログラミングをしているが、Promiseとデータバインディングとして使っている
このところ、複数の人からリアクティブプログラミング(RP)ってつまり何なんですかと聞かれることがあった。そのたびに非同期データストリームが…みたいな説明をしていたのだが、たいてい双方納得した感じにはならなくて、まあ難しいっすね…という感じで終わってしまっていた。
iOSとAndroidでの用途
自分は理論より実践からしか考えられないタイプなので、もっと現場寄りの説明ができないか常々考えていた。そこで自分がiOSとAndroidアプリを実装する際に使っているReactiveCocoaとRxJavaの用途を考えてみたところ
の2つがメインだった。
この2つはRPライブラリを入れなくても実装できる。JavaScriptならそれぞれに独立した良いライブラリがあり*1、両方ともそこそこ普及している概念だと思う。
クライアントサイドで使うRPについての自分の理解は、この2つの概念と他の用途(イベントと時間、高階関数など)を包括した大統一理論というか、スーパーセットだというものだ。両方を1つのライブラリで実装しようとするとRPの形がしっくりくるし、なるほどストリームって必要だよねというのも感覚では理解できるようになった。
しかしやはり概念として大きすぎる気がするし、実際の仕事では使っていない機能も多い。選択肢がある場合は、小さくて普及しているものを採用した方が、現場の負荷も少なくて良いのではないかと思う。パラダイムの違うもの、怖いし。
プラットフォーム事情
ではなんで自分がRPというスーパーセットお化けを使っているかというと、スマートフォンアプリでPromiseとデータバインディングを実装するために最も完成度が高いライブラリがRPライブラリだったからという消極的な理由である。
iOSではPromiseKitなどのPromise系ライブラリは割とあるし使われていると思う。データバインディングのライブラリもあるのだが、自分の感想ではReactiveCoocaのデータバインディングが一番使いやすかった。
Androidでもライブラリは色々あるが、データバインディングもPromiseも広く使われている実装がないというのが自分の理解。RxJavaがAndroidでも人気なのは、Promiseの良い実装がないからではないかと自分は考えている。
おわりに
RPは大統一理論なので、Promiseとデータバインディングを両方実現できる上に、両方を繋いで!複雑なAPIコールとViewへの反映をObservableで接続!ということもできる。キメると実装者としては大変気持ちが良い。しかしたいていの場合そこまでやる必要は無いし、キマったコードはRPに慣れていない同僚を困らせる。
なので色々できるけど、今のところ自分はPromiseとデータバインディングをやるための便利なライブラリだよという説明を採用しているし、仕事でもその範疇の中で使っている。
RPのパラダイムがもっと普及して、RPで全部を考えるニュータイプが多勢を占めるようになるとこの状況も変わると思うので、それはそれで楽しみである*2。
補足
- サーバーサイドでの用途に言及すると混乱に拍車がかかるし、自分はやっていないので省いた
- プラットフォームでRxをサポートしている.netの方から見ると事情は全く違うだろうと思う
- これもよく聞かれるし、自分も前は間違えていたのだけど、React.jsはデータバインディングなどの概念での共通点はあるけど、リアクティブプログラミングの実装ではないという理解
- 多様なリアクティブプログラミングの世界を覗き見たければReactive Pornがとても参考になる