4月に行われたAndroidエンジニアのお祭り、DroidKaigiの第2回が2016年の2/18、2/19開催予定で、現在発表を絶賛募集中です。自分は今回もスタッフとしてお手伝いさせて頂いています。
自分は前回発表したのですが、その後「資料見ました」と言ってくださった方が入社したので、直接のコンバージョンかはわからないですが、採用実績も1あります。
また、初心者向けセッションも要望が多いので、そういった発表もお待ちしています。2016年にAndoidを始めるのに一番近道な方法まとめ とか、とても喜ばれそうです。
技術を深掘りしたい方、裾野を広げたい方、採用に繋げたい方、DroidKaigiはあなたの発表をお待ちしています！
実は既に今日#2があるのだけど、#1に参加して感想を書いていなかったので、メモを引っぱり出して書く。
Qiita::TeamのIncrements社が主催の情報共有ツールお悩みNight #1に参加してきた。他社の事例とかを聞いてみたかったので。
ワークショップのファシリテーターを任されていたので、聞き役に回って少し突っ込みを入れる役をやった（その割に結構喋ってしまった）。
他社の話を聞いてみて、FablicはQiita::TeamやSlackをそこそこうまく使っている方なのかもしれないと思った（事例）。日報をGoogle+に移したのも、自分は当時あんまりよく思っていなかったけど、結果的にはその後濃いエントリが増えて正解だったと思う。
他社の抱える悩みとしては以下のものがある感じだった。
イベントの設計も面白くて、事前にイベント用のQiita::Teamが作成されて全員の自己紹介とリアルなお悩みの募集が行われた。この募集されたお悩みがワークショップのお題になっていて、よくデザインされたイベントだなと感心した。
今後も継続して行われるとのことなので、興味がある人は参加してみると面白いかもしれません。
コンサートに行ったのだけど、途中から誰か入ってきたなと思ったら皇后の人で、さすがにびっくりした。周りの人たちも「ほう…」という感じで目を細めながら拍手していた。
会社でホワイトボードを使ってカンバン形式でタスク管理をしているのだけど*1、ホワイトボードと付箋の組み合わせが好きなので家でも使っている。
貼っているのは読んでいる本とブログのネタ、あとはたまに進める自分のプロジェクト。週末に途中まで何かやって忘れることが多いのでそれを管理するのと、一度にたくさんのことを始めないように制御する役割がある。また、Doneに一個でも移せたら、その週はなんかがんばったという感じが出る。
実はこれはドアである。
吸着タイプのホワイトボードをドア（木製）に貼って使っていて、とても調子が良い。コクヨの技術はすごい。
コクヨ ホワイトボード ピタボ 吸着シートタイプ 無地 FB-P152W
*1:Pivotal Tracker、Trello、HuBoardと来て今はアナログに落ち着いている。個人的には手を動かして付箋に字を書く作業が好き
Rebuild: 98で紹介されていたので、英語だけどがんばって読んでみた。Inspiredと同じ方向性のプロダクトマネジメント本。違う人が同じ事柄について書いているという印象。しかし少しずつ違う視点が入っていて、プロダクトマネージャーの役割が立体的に見えるという意味で両方読む価値はあると思う（もう読んでしまったのでこう言うしかない）。
英語はかなり平易。使われている語彙がだいぶ簡単なので、他の英語の本に比べて読みやすいと感じる。それでも自分はちまちま読んで一ヶ月くらいかかった。
話題が割と新しめ。Google Buzzと写真共有アプリのColor（懐かしい！）が失敗した話が導入部分。
またInspiredに比べてスタートアップの文脈が強かったり、初期のビジネス的成功という点に重点が置かれている気がする。
以下、自分が線を引いた部分とコメント。引用の下の日本語は拙訳。
余談だけど今まで読んだPM本、だいたいPMの定義から入る傾向にある。
The only thing that matters is getting to product/market fit. Product/market fit means being in a good market with a product that can satisfy that market.
最も大事な事柄は、製品/市場フィットに達することだ。製品/市場フィットとは、その市場を満足させることができる製品を伴う、良い市場という意味だ。
The product manager’s mission is to achieve business success by meeting user needs through the continuous planning and execution of digital product solutions.
プロダクトマネージャーのミッションとは、デジタルプロダクトソリューションの継続的な計画と実行を通してユーザーのニーズを満たし、ビジネスを成功させることである。
It is vastly easier to identify market problems and solve them with technology than it is to find buyers for your existing technology.
手持ちの技術を買う人を探すのに比べれば、問題がある市場を探して技術で解決するする方が遥かに易しい。
First, they need to have their heads in the clouds. PMs need to be leaders who can look into the future and think strategically. They need to be able to develop a vision for where a product should go — and they need to be able to communicate that vision effectively. Further, PMs need to show their teams how they plan to get to that vision. And I do mean show — through sketches, prototypes, storyboards, or whatever it takes to get the message across.
まず、彼らは頭を雲の中に突っこむ必要がある。PMは未来を見通して戦略的に考えるリーダーである必要がある。製品はどこに向かうべきなのかというビジョンを生み出す必要がある。そしてそのビジョンを効果的に伝える必要がある。さらに、PMはビジョンを達成するためにどう計画を立てるかチームに示す必要がある。スケッチ、プロトタイプ、ストーリーボード、メッセージを行き渡らせる方法なら何でも使って。
Good PMs are also able to remain flexible and change course when needed, perhaps when there is a big shift in market needs or expectations, or a great business opportunity presents itself.
良いPMは、必要なときには、そして恐らく特に市場ニーズや期待、偉大なビジネスの機会が存在するときには、柔軟さを保持したまま進路を変更することができる。
Consensus cultures often produce watered down, unexciting products.
合意の文化はしばしば骨抜きの、ありきたりな製品を生み出す。
It was a passing comment and I didn’t really think much of it at the time, but since then I keep going back to that conversation, and the importance of fairness in the product management profession. All the characteristics I just talked about are great, but above all, fairness is the one that a PM simply cannot do without.
これは口をついて出てた言葉で、そのときは深く考えていなかった。しかし私はそのときの会話と、プロダクトマネジメント職においての公平さの重要性に立ち戻り続けている。私が語ってきた全ての特徴は素晴らしい。しかし公平さこそ、PMがこれ抜きには何もできないものだ。
また製品は以下の3つのニーズを満たさなければならないとして話が進む。
この中でTechinal needsの中には技術的負債なども含まれて居る。PMにとっては技術的負債もマネジメント対象である。
So, user needs research is always the first place to look for how the product can make money.
ユーザーニーズのリサーチは、製品がどのようにお金を生み出すかを探し出す際に、常に出発点となる。
AARRRみたいなやつ
It won’t always be easy, but every UCD project should be measurable in terms of its impact on the business; tying it to one of the three ‘A’s is a good structured way of anchoring all design changes in business goals and, ultimately, revenue.
いつも簡単ではないけれど、すべてのUCD(User Centered Design）プロジェクトはビジネスのインパクトとして計測できるものであるべきだ。三つのAはデザインの変更がビジネスのゴール、つまるところレベニューに結びつけるための構造化された良い手法である。
I always think about error handling as the bastard child of user experience design. No one thinks about it until it’s too late, and then they try to sweep it under the rug.
私は常々エラーハンドリングはユーザー体験デザインの庶子であると考えている。手遅れになるまで誰もエラーについては考えず、そのときには敷物の下に追いやろうとする。
The prototype is often the part of the spec that’s most referenced by developers, since it’s the most useful.
プロトタイプは一番実用的なので、よく開発者から最も参照される仕様のひとつになる。
個人的にはエンジニアとデザイナーのコミュニケーションにも触れているのが面白かった。
The main issue is that designers and developers approach their respective crafts from very different perspectives. Design is about composition — how to put hundreds of tiny elements together so that the whole makes sense. Development is about deconstruction — how to break down the whole into pieces that can be implemented effectively.
問題は、デザイナーと開発者がそれぞれ違った観点でもの作りにアプローチしているということだ。デザインとは構成すること、つまり数百の小さな要素を集めて理解しやすいように組み立てることである。開発は脱構築すること、つまり効率良く実装できる要素に分解することである。
Research triangulation — also known as mixed method research — is a helpful methodology to keep in mind here.
混合研究法として知られるリサーチの三角測量は、ここで覚えてくと助けになる手法だ。
という話から、以下の3つの手法をそれぞれ補完的に使うという話が語られる。
A/B testing shouldn’t be used on its own to make decisions — it should always be used in conjunction with other research methods, both qualitative (such as usability testing and ethnography) and quantitative (such as desirability studies).
A/Bテストはそれ自身を決定に使ってはならない。質的（ユーザビリティテストやエスノグラフィーのような）と量的（望ましさの調査のような）両方を含む他のリサーチ手法と組み合わせて使うべきである。
Since every research and testing method comes with its own limitations, a combination of methods is the only way to get the full picture and make the right decisions.
全てのリサーチとテストの手法はそれぞれ限界が伴うので、全体像を把握し、正しい決断を行うためには複数手法を組み合わせて使うことが唯一の道である。
最初にも書いたけれど、プロダクトマネージャーの役割が立体的に見えるという意味で良い本だと思う。ぜひ日本語版も出て欲しい。まだ誰も手を付けていないなら翻訳か監訳かやりたいという気持ちがあるのだけど、どういう手順で進めれば良いのかわからない（出版社を通して翻訳権を取得する必要がある？）。どなたかその辺りの知見やツテなどあれば教えて頂けるとありがたいです。
Making It Right: Product Management For A Startup World (English Edition)
これまで聞いた中で最も僕の中のプロダクトマネージャー像に近い - Making It Right: Product Management For A Startup World を読んだ - ninjinkun's diary http://t.co/R5TBTmTJNO
— takejune (@takejune) 2015年10月13日
同僚から指摘をもらって、この本は0→1の事業立ち上げフェーズにフォーカスしている本だと思うようになった。Inspiredはどちらかというと1→100の成長フェーズの話が中心に思える。立ち上げ期と成長期ではプロダクトマネージャーの役割は違った物になりそうである。
Inspired: 顧客の心を捉える製品の創り方を読み返していて、「第7章: プロダクトマネージャーを管理する」の一節
エンジニアリング部門というのは、基本的に、正しい製品を作ることではなく、製品を正しく作ることに専念することになっているからだ。
というところが引っかかったので、思うところを書いてみる。ちなみに「第5章: プロダクトマネジメントとエンジニアリング（実装）」にも「正しい製品を作るのか、それとも、製品を正しく作るのか」というタイトルの章がある。
エンジニアは製品をリリースする責任があるので、不確定要素を減らして正しいスケジュールでリリースすることにモチベーションがある。このために、開発が進むほどにエンジニアは保守的になっていく。企画段階では和気藹々とブレストしてアイデアを出していても、最後のリリース前にはしぶい顔で実装を拒んだりする。
エンジニアとしてこの動きは自然だと思うし、正しく作られていない製品をリリースすることは結果的にユーザー体験を損なうので、職業上必要な振る舞いでもある（そして製品を「正しく」作るのはとても難しい）。
この場合に「正しい製品」の方を引き受けて開発チームを引っ張るのがプロダクトマネージャの仕事で、「正しく作る」方のエンジニアとバランスを取ることが必要、というのが本書（特に5章）の趣旨である*1。
しかしここで自分が気になるのは、プロダクトマネージャーがエンジニアも兼ねていて、実装もしている場合はどうするのかということだ。というのは今の自分がそういう立場だからなのだけど、所謂プレイングマネージャがこのバランスをどう取るのかということに関心がある。
突然自分語りになるけれど、自分が意識しているのは以下のことである（意識しているだけで、できていると言うつもりはないです…）。
私がエンジニアとして働き始めたころに学んだ教訓は、客観的な判断は、コードの１行目を書くまでしかできないということだった。その後のすべての決断は感情的になる。
Hard Things 「第3章 直感を信じる」より
自分もコードを書き始めると思考がどんどん保守的な方に向くという経験を何度もしたので、このバイアスをできるだけ把握したいと常々思っている。実装期間には気分転換に散歩に行ったり、ランニングをしたりして冷静に振り返る時間を設けたりしているけど、うまく行っているかはよくわからない。
そういった経緯から、実装に入る前の調査、ブレスト、ユーザーインタビュー、ペーパープロトタイピングといった段階を重視するようになった（要するにデザイン思考的なメソッドを勉強した）。自分は例えプロトタイプでもコードを書いてしまうとバイアスが入ってしまう方なので、コードを書かない助走期間というのをできるだけ確保するようにしている*2。
自分からお願いして、事業責任者と毎週の1 on 1ミーティングを設定して、そこで意見を求めるようにしている。特に自分が今取り組んでいることをペンディングして別のことやるという判断をするときは、大抵1 on 1がきっかけになっている。要するに自分のマネジメントを手伝ってもらっているのだけど、実装に入っている段階ではこの時間が大変ありがたい。
自分はエンジニアが「正しい製品」を作ることは可能だと信じているけれど、実装者が両立させるのが難しい仕事であるのは事実だと思う。
プレイングマネージャーに固執しているわけではないけれど、正しい製品を作りたいし、コードを書くのも楽しいし、両方うまいことやりたいという、シンプルな（そしてたぶん欲張りな）欲求を持っている。
ここまで書いてきて何だけど、もちろん実装を通して着想が得られることはよくあると思う。しかしそのときにそれが「正しい製品」のためのものなのかを判断できるのか。今まで書いたコードを捨てる決断を自分でできるのか。そう考え出すと、やはり一度実装を始めると自分でフェーズを巻き戻すのは難しいように思う。
この文章を社内で見てもらったところ、エンジニアの先輩から同じようなことを感じてきたという意見を頂いた。先輩はプロダクトマネジメントと実装を両方やるときは、日や週を分けて対応するようにしているとのこと。
そうした意見から、このバイアスとの戦いはエンジニアがプロダクトマネージャーになるための成長痛なのかもしれないと思うようになった。バイアスとうまく付き合う方法を見つけた人が、コードを書くプロダクトマネージャーとして残っていくのだろうか。
プロダクトマネージャーの職能+ユーザー体験設計の本です（と解釈しています）。
最近Rebuild: 98: Superhumans Wanted (Naoya Ito)やエンジニアからみた良いプロダクトマネージャとは？ - サンフランシスコではたらくソフトウェアエンジニア - Higepon’s blogで話題のプロダクトマネージャーに興味があって、関連しそうな本を読みたいと言っていたら、知人がこの本を紹介してくれました。
Netscapeなどでプログラマーをしていたバックグラウンドを持ち、eBayなど複数の会社でプロダクトマネージャをしていた経験を持つ著者がプロダクトマネージャーの職能について語る本で、以下のような内用が含まれています。
自分にとっては、ユーザー体験をデザインするのはプロダクトマネージャーの責任であるというのを明確に定義しているところが読んで一番良かったところでした。そのためにインタラクションデザイナーと二人三脚でプロトタイプを作ったり、ユーザーテストを実施したりと様々な手法が紹介され、プロダクトマネージャーはそれを牽引する役割であると書かれています。今まで自分が興味を持っていたゴールダイレクテッドデザインやデザイン思考というのは、プロダクトマネージャの仕事だったようです。
以下、線を引いた部分の引用です。
ダメな製品が無駄に世に送り出されるいちばんの原因は、ほとんどの場合、会社の中でプロダクトマネージャーの役割が明確にされていないことと、プロダクトマネージャーとなる人に対する教育が不十分なことにある。
覚えておいてほしい。価値のある、使いやすい、実現可能な製品として作られるべき何かをプロダクトマネージャーから与えられなければ、どんなにエンジニアリング部門が優秀でも意味はない、ということを。
身につまされる…。
長い時間をかけて 1つの領域に精通してしまうと、プロダクトマネジメントのもう 1つのワナに落ちてしまうことがある。それは、自分がターゲットである顧客を代弁する人間で、実際以上に自分がターゲットである顧客に近い存在だと思い込むようになるのだ。
ユーザー目線と自分目線を混同しないようにするのは、自分で使いながら作っていると難しいことが多いです（何度もはまった罠）。
デザイナーというのは、製品開発のうんと早い段階、つまり、プロダクトマネージャーがターゲットとなる市場を把握してソリューションを考えている段階から参加してこそ、その真価を発揮できるのだ。
これはデザイナーではない自分もよく思うことです。最初からデザイナーが関わってくれないと心細い…。しかしデザイナーがプロダクトマネージャーの場合は一人で良いのだろうか。
世界で闘うプロダクトマネジャーになるための本 トップIT企業のPMとして就職する方法【委託】 - 達人出版会を読み終えたところだったので、プロダクトマネージャーの理解が深まって良い本でした*1。
余談ですが、英語版は2008年の出版で、翻訳は2015年、しかもなぜかKindle版のみ（そして1200円！）という謎の本です。おそらく訳者の方々がどうしても出したかったとか、思い入れが強い本なのではないかと想像しています。
どうも最初は2012年にiOSアプリとして出ていたようです。最近になってKindle化されたんですね。
Inspired 日本語版 発売! | Inspired日本語版
プロダクトマネージャの話、これ読むのがいいと思う 『ドキュメント トヨタの製品開発: トヨタ主査制度の戦略,開発,制覇の記録』 http://t.co/o6UkPwqjE2
— あんちぽちゃん (@kentaro) 2015年8月2日
プロダクトマネージャのおすすめ本募集してます
— ninjinkun (@ninjinkun) 2015年8月2日
この酒井さんの本はプロダクトマネージャーについて知りたい人が読むと良いかも。 / “トヨタに学ぶ 「滅びる組織」「伸びる組織」 売れ続ける秘密は「SHUSA」にあり！ | Forbes JAPAN（フォーブス ジャパン）” http://t.co/9XiawlveKy
— あんちぽちゃん (@kentaro) 2015年8月3日
弊社Fablicの社長 @shota もおすすめとのことです。社内チャットから転載。
ninjinkunがレビュー上げてた下記の本、自分も前に読んだんですが、非エンジニアにとってはまず用語の理解、 プロダクトマネージャー(PO)、プロジェクトマネージャー(PM)の違いなど、開発する側と対等に話すための前提知識が 詰まってたので、僕もおすすめです。 特に非エンジニア職の方。
弊社の人事も最近読んだようで、「開発のことが理解できて良かった」とのことです。確かに人事の人にもおすすめかもです。
*1:他にも、このInspiredを薦めてくれた知人が紹介してくれた、HARD THINGS 答えがない難問と困難にきみはどう立ち向かうか
4月にDroidKaigiで発表してから、しばらくアウトプットを減らしてのんびりしていた。充電期間というと聞こえは良いけれど、実態としてはぼうっとしていただけである。
自分はこういう意識が高いとき、低いときを一年の中でサイクルとして繰り返している気がする。
意識が高いときは
など、もろもろの活動ができる。
今回のように意識が低いときは
など、あんまり生産的とは言えない、でも楽しい生活になる。
常に意識が高いモードは疲れるので、一年の半分くらいは意識が低いモードで暮らしている。体重が増えて鏡を見るのが辛くなってくると、またランニングを始めるなどしてモードが切り替わっていく。
そろそろまた勉強会等にも顔を出して行こうと思います。
自分が最初に元の誰のためのデザイン?―認知科学者のデザイン原論 (新曜社認知科学選書)（初版はPOETと呼ばれている*1 ）を読んだのは十数年前でした。4月に出たこの改訂版を読み返してみて、改めて感銘を受けました（そして内容をほとんど忘れていたのに気づきました）。
内容としては、エモーショナル・デザイン―微笑を誘うモノたちのために 、複雑さと共に暮らす―デザインの挑戦など後の書籍で検討された内容が盛り込まれて、ノーマン著作の集大成になっています。
自分がこの改訂版で注目しているのは、「6章デザイン思考」の追加です。
正しい問題を発見するのがデザインである として、そのための手段としてデザイン思考が解説されます。
具体的にフレームワークとして取り上げられている人間中心デザインプロセスを見てみると、
観察→アイデア創出→プロトタイピング→テスト→観察…
というサイクルになっており、他のデザイン思考関連書籍でもお馴染みのものです。
今こういったデザイン思考のためのフレームワークは、Web業界やアプリ業界でもリーン･スタートアップ関連やDesignSprintなどを通じて広まりつつあると感じています（手前味噌ですが、自分が所属しているFablicもデザイン思考が企業文化になっている会社です）。
おそらくこうした業界への浸透の背景もあって、入門書である本書にもデザイン思考の章が追加されたのだと思います*2*3（個人的にはIDEOの本よりこっちの方が読みやすい…）。この章の追加により、POET版の「いい話だったけど、どう活かしたら良いんだろう？」という読後感が払拭されており、より実践的な本になっていると感じます。
最後の参考図書にはAbout Faceなどの書籍等が多数上げられており、デザイン思考へのポインタとしても有用です。
改訂を機会に読み返した本書ですが、POET版の良い部分は残しつつ、デザイン思考や企業での実践に言及することでさらに進化していました。
POETを読んだときの自分は学生だったので、「テクノロジーが使いにくいのは人間のせいではなく、デザインが悪いのだ」という発想そのものに感銘を覚えました。
そして今、プログラマーとして社会に出た自分には「テクノロジーに関わる人間全員がデザインを実践することでものは確実に良くなる。そしてそれは楽しい仕事だ」というメッセージがストレートに刺さってきて、そうした自分の変化も再読の面白さの一つでした。
自分はこの本をこの先何度も読み返すと思います。今回25年ぶりの改訂で、また次の25年間も耐えられるようになったとのことなので、次に読むときはどんな風に読めるのか楽しみです。
私が確実に予想できるのは、人間の心理学の原則は変わらず残るということ、つまり、心理学、人の認知、情動、行為、世界とのインタラクションに基礎をおいた、本書に述べるデザインの原則は変わらずに残ると言うことである
誰のためのデザイン？ 増補・改訂版 ―認知科学者のデザイン原論
*1:書名The Psychorosy of Everyday Thingsの略
*2:IDEOなどデザイン思考を牽引する組織はノーマンの影響を強く受けているらしく、POETでまかれた種がデザイン思考として結実し広まったと解釈することもできそうです
*3:自分はこの章を98年のインビジブルコンピュータ―PCから情報アプライアンスへで提案された企業でのデザイン実践と読み比べて、前著での提案が今ではこうやって企業で実践されるようになったのだなーと勝手に盛り上がっていました
