本投稿では、私がリードする「AI製品開発チーム」で実施した読書会について、その運営方法と内容を紹介します。
今回の読書会で対象にした書籍は、
【INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント】
https://www.amazon.co.jp/dp/B0814STTHV/
です。
日本語では「熱狂させる製品を生み出すプロダクトマネジメント」と訳されていますが、英語では
How to Create Tech Products Customers Love
です。
愛される製品の作り方ですね。
プロダクトマネジメントがテーマです。
原著はAmazon.comで370レビューの評価4.6という、プロダクトマネジメントの定番書籍です。
日本語版も、とても良くできていて、翻訳も丁寧です。
日本でも、もっとプロダクトマネジメントやプロダクトマネージャー（PdM）が定番化されてくれば、さらに注目を浴びる書籍だと思います。
私がリードする「AI製品開発チーム」のメンバは、技術（とくにAI・ディープラーニング）は強いですが、
メンバには今後さらに、
お客様がお金を払ってでも、愛し利用してくださるプロダクトを創る！
そして、私たちはSIerのAI製品開発チームなので、弊社の営業社員の方々にとって
こんな製品があれば、きっとあのお客様の役に立てる、ぜひあのお客様に紹介したい！
と、自社の営業社員が愛し、お客様に紹介したくなる製品。。。
そんな製品を創るべく、プロダクトマネジメントの意識を高め、
そのための知識を身につけてもらいたく、本書を選定しました。
本記事では、
●読書会の運営方法
●実施した感想
●メンバが気に入った箇所
を紹介します。
読書会の運営方法
開催時期
2020年4月後半から5月中旬。
COVID-19の影響により、全員自宅からのテレワーク状態の時期に開催しました。
開催周期
開催は週に1回、毎週木曜日の13:00から14:00の1時間としました。
全部で5回の開催にしました。
全5回の分け方
第1回：chap1～chap8
第2回：chap9～chap21
第3回：chap22～chap37
第4回：chap38～chap57
第5回：chap58～chap67
だいたい、毎週50~100ページを範囲としました。
参加メンバ数
今回は時間の都合のついた6名（私含む）で実施
当日までの準備
読書会参加のメンバは、次回の開催範囲を読み、自分が気に入った箇所を2つ選択します。
そして、皆で共有しているファイルに、
・気に入った箇所2つとその文言
そして、
・なぜその箇所を選んだのか？自分の業務とどう関わりがあるのか？自分が気に入った理由
を書いてもらいました。といっても簡単に2-3行程度です。
当日の運営
読書会は、Teamsでオンライン開催しました。
当日の運営は、初回は私が実施し、
2回目以降は今後リーダーになっていってもらいたい2名に、毎週交互に実施してもらいました。
運営者は、皆が記入した「気に入った箇所2つとその理由」を画面共有します。
画面に表示されている内容を書いた人は、
自分が気に入った箇所を読み上げ、そしてなぜこの箇所を挙げたのか、
自分のこれまでの仕事や今後の想い、普段から思っていることなどを語ってもらいました。
メモ書きでは2-3行の記載ですが、それをもう少し詳しく話してもらう感じです。
そして、他の参加者はその箇所や挙げた理由に対して、自由に思ったことや自分の体験などを追加し、
話しを膨らませる
という流れです。
これを、5人分やって、私は最後にちょろっとだけ話して1時間という感じです。
実施した感想
参加メンバの各自、思い想いの感想はあると思いますが、私は
-
みなが気にいった箇所がバラけて、バラけたのは各自の異なる案件・開発経験などから来ており、多様な意見が聞けて楽しかった
-
逆に多くのメンバが気に入った重要箇所などは、「皆が自分たちは何を大切にしたいと思っているのか？」という、非言語化情報が明確に表出した箇所であり、学びになった
-
実際にリーダーやPdMに近いことをやる人だけでなく、そのフォロワーとなるメンバも参加した読書会であった。プロダクトマネジメントを共有しながら学んだことで、メンバが円滑にリーダーをフォローし、リーダーも円滑に開発をリードしやすい土台ができたように思う
-
読書会がちょうど、大きめの開発案件をやり切った後だったので、その振り返りを深めることもできた
書籍1冊の読書会やっただけで、プロダクトマネジメントなんて全然無理ですが、
私も含め、皆で1歩前に進めたことが良かったなと思います。
何と言いますか・・・
私たちはまだまだプロダクトマネジメントのゴールと言えるレベルにはいないけれども、
ゴールのある方向へ、皆で同じ1歩踏み出せた感覚です。
メンバが気に入った箇所の紹介
最後にメンバの皆がピックアップした箇所を紹介します。
といっても、
6人×5回×2か所
の合計60か所が挙がったので、そこから抜粋です。
chap.1_優れた製品の背後にあるもの
“私の信念であり、本書の中心となっている考えがある。
優れた製品の背後には必ず、製品開発チームを率いて技術と設計を組み合わせ、
顧客が抱える本当の課題を、ビジネスのニーズに合った形で解決する人間がいる、ということだ。
その人は普段表には出ないが、絶え間なく仕事をしている。
こうした人々は通常、プロダクトマネジャーという肩書を持っている。”
chap.4_成長期企業
“最初の製品ニーズに合うように作られた技術インフラは、しばしば能力の限界に達する。
あなたはエンジニアと顔を合わせるたびに、「技術的負債」という言葉を聞くようになる。”
chap.5_成長期企業
“リーダーも往々にして製品開発チームから革新的なアイデアが出せれないことにいらだちを募らせる。
そして、しばしば企業買収に走ったり、独立した「イノベーションセンター」を設立して、
保護された環境で新たなビジネスを生み出そうとしたりする。
だが、こうしたことがリーダーの切望するイノベーションにつながることはほとんどない”
chap.6_製品開発が失敗する根本的原因の５
“デザインの役割にも同じことが言える。プロセスの中でデザインの真の価値を取り入れるのが遅すぎる。
そして、おこなわれていることのほとんどが、私たちが「豚に口紅」モデルと呼んでいるものだ。
すでにダメージを受けているのに、ガラクタにペンキを塗ろうとしているだけなのだ。
UXデザイナーはこれが間違っていることを知っているが、できる限り見栄え良く、首尾一貫しているように見せようとする。”
chap.7_リーンとアジャイルを超えて
“優れた開発チームは期待する結果を得るために、毎週いくつもの製品のアイデアをテストするのが普通だ。
週に10から20、あるいはそれ以上である。"
chap.7_包括的な原則3
“大切なのは機能を実装することではなく、問題を解決することである。”
chap.8_継続的な製品発見と市場投入
“製品開発チームは常に並行して2つのことに取り組んでいる。
1つは、作る必要のある製品を発見すること。これは基本的にプロダクトマネジャーとデザイナーが日々取り組んでいる。
もう1つは、エンジニアが高品質な製品を市場に投入することである。”
chap.9_開発チームがある場所
”もしあなたが1か所にまとまった製品開発チームのメンバーだったことがあるなら、私の言っていることが分かるはずだ。
そうでなくても、製品開発チームでの仕事のやり方を知れば、チームが一緒に座り、一緒にランチを食べ、互いの個人的関係を築いたときに生まれる独特なエネルギーがあることがわかるだろう。”
chap.10_プロダクトマネジャーとプロダクトオーナー
"製品企業においてプロダクトマネジャーが同時にプロダクトオーナーであることが欠かせない。
もしこれから役割を2人の人間に分ければ、よくあるありきたりな問題がいくつか生じる。
最も典型的なのは、ビジネスと顧客に対する新しい価値を革新し、絶えず創造する能力が開発チームから失われることである。
特に製品企業では、プロダクトマネージャーが追加的に責任を持てば、優れたプロダクトオーナーの判断できるようになる。"
chap.10_冒頭の後半
”本当のことを言うと、プロダクトマネジャーは会社のなかで、最も才能のある人材の1人であるべきだ。
もしプロダクトマネジャーに、技術に関する高度な知識やビジネスの手腕、主要な幹部との信頼関係、顧客に関する深い知識、製品に対する情熱、製品開発チームへの敬意がなかったりすれば、間違いなく失敗する。”
chap.23_ロードマップに代わるもの（P. 137, P.138）
”製品開発チームは、ビジネスにおける脈絡をつかんでいなければならない。
つまり、企業がどこへ向かっているを確実に把握し、大きな目標に対して自分のチームがどのように貢献するのが望ましいのかを理解しなければならないのだ。
すべての製品開発チームが、自分たちの仕事が大きな組織全体にどんなふうに貢献しているか、また、企業が今、チームに集中してほしいことは何なのかを理解することが重要である。”
chapter24_製品ビジョンと製品戦略
”うまくいけば、製品ビジョンは最も効果的な人材募集ツールの１つになるし、チームのメンバーが毎日働きに来る動機づけにもなる。
有能なエンジニアは刺激的なビジョンに引き寄せられる。
何か意味のあることに取り組みたいからだ。”
chap.25_製品ビジョンの原則_その2
”解決策ではなく問題に恋をする”
chap.25_製品ビジョンの原則_その5
”製品ビジョンは人の心を揺さぶらなければならない”
chap.33_製品発見の原則_その6
”アイデアの妥当性は実際のユーザーや顧客で立証しなければならない。
製品開発において最も陥りやすいワナの1つは、製品に対する顧客の反応を予測できると思い込んでしまうことである。
それは顧客調査や経験に基づいて出した判断かもしれないが、今日ではよくわかっているように、どんな場合でも、実際のユーザーや顧客でアイデアの妥当性を検証しなければならない。
これは、本物の製品を開発するために時間や費用を費やす前におこなう必要がある。あとではいけない。”
chap.34_発見のテクニックの概要_発見のフレーミングテクニック
”自分たちが集中すべきビジネスの目標と、顧客のために解決しようとしている具体的な問題、その問題をどのユーザーや顧客のために解決しようとしているのか、そして何を持って成功というのかについて合意を形成する必要がある。
これらは、製品開発チームの目標（Objective）と主要な結果（Key results）に直接結びつかなければならない。”
chap46_実現可能性プロトタイプのテクニック
”私の経験では、1つの実現可能実現可能性プロトタイプをビルドするのに必要な時間は1日から2日が普通である。ただし、機械学習技術を使ったアプローチというような、新しい主要技術を検討している場合は、実現可能性プロトタイプのビルドにはビルドにはもっと時間がかかる可能性が高い”
COLUMN_分析の役割
“私の経験では、過去の製品開発で最も悪い結果をもたらしたのは部外者の意見への依存である。
発言した人の地位が組織の中で高ければ高いほど、その意見は重視されがちだ。
現在は、データは意見に勝るという精神のもと、私たちが意見を持つのは、テストの実行、データの収集、そのデータを使って私たちの判断を裏付けるときぐらいである。
データがすべてではないし、私たちはデータの奴隷ではないのだが、現在、最も優秀な製品開発チームには、テスト結果の情報に基づいて判断をしている例が無数に見られる。”
chap.61_ステークホルダーを管理する_「成功のための戦略」
“通常、企業はプロジェクトにそのミーティングで、プロダクトマネージャーが、作ろうとしているものについてのプレゼンテーションをパワーポイントを使っておこなうという。
これに2つの深刻な（キャリアの障害になりうる）問題がある。
第1に、事業実現性のテストにプレゼンテーションを使うのは、悪名高いひどい方法だ。理由は、あまりにも曖昧なことである。
・・・
それに対して、高忠実度のユーザープロトタイプは理想的だ。”
chap.64_良い製品開発チーム/悪い製品開発チーム
“良い開発チームがひらめきや製品のアイデアを得るのは、自分たちのビジョンや目標からであり、顧客が苦労している様子を見ることや、自分たちの製品を使うことで顧客が生み出すデータを分析すること、実際の問題を解決するために常に新しいテクノロジーを適用しようとすることからである。
悪い開発チームは販売部門や顧客から要望を集める。“
chap.64_良い製品開発チーム/悪い製品開発チーム
”良い開発チームは自分たちの製品がどんなふうに使われているかを知るために製品を計装し、データに基づいて調整する。
悪い開発チームは、分析と報告は、あればいいが、なくてもかまわないと考えている。”
chap.65_イノベーションが失われる最大の理由
“私たちにとってこのうえなくありがたいことに、顧客はいつも満たされていない。
顧客自身が満足していると言い、売れ行きが順調なときですら不満を持っている。
自覚がなかったとしても、顧客は何かがもっと良くならないかと願っている。
だからこそ、私たちは顧客を喜ばせたいという欲求に駆られて、顧客のために新しいものを生み出すのだ”
chap.66_スピードが失われる最大の理由
“同じ場所にいて、長続きする開発チームの不在。
開発チームがいくちかの場所に分散指定て、さらに悪いことにエンジニアリングを外注している場合は、イノベーションの機会が激減する上に、仕事のスピードが大きく損なわれるだろう”
chap.67_強い製品開発文化を作る
”いずれにせよ、私があなたやあなたの開発チームにしてほしいのは、イノベーションと実行力の両面から自分自身を見直し、あなたが、チームや企業として、どの位置に行きたいのか、どの位置に行く必要があると考えているのかを自分に問いかけることである。”
まとめ
以上、読書会の運営方法と内容の紹介でした。
参考になるものがあれば幸いです。
また読書会以外に、私たちのチームの働き方を以下の記事で紹介しています。
以上、ご一読いただき、誠にありがとうございました。
【免責】本記事は著者の意見/発信であり、著者が属する企業等の公式見解ではございません