ざっくり解説 → "Practical Lessons from my Experience in Product"
こちらの「プロダクトマネジメントに関する教訓」の記事がPM界隈で少し話題になってます。
これに関して、とある日に会社のメンバーから
というおねだりをもらいました。英語苦手なのに…
というわけで、せっかくだから解読した結果をここにまとめます。そのまま翻訳するのは許可が必要な気がするので、あくまで自分の解釈と意見を書く形にしました。（間違ってたらごめんなさい）
1.MVPはユーザーセグメントを絞って作るべし
1.Being Minimalistic- Identify a target user base don’t be greedy for every possible user segment. Segments are not just demographics but can be a mobile user, a desktop user, a college student or just people in a specific timezone. Minimalism is not just on user selection, try developing MVP and extend the minimalism to day to day work. Do your homework right.
これはこの図を見るだけで十分な気もしますが、全てのリーチ可能なユーザーセグメントをターゲットにするMVPを作ると多機能になり、結局"Functional"な部分の検証しかできなくなります。ターゲットとするユーザーセグメントを絞り、その中で本質的に検証すべきことを検証できる必要最低限のMVPを作るべきということです。
元記事より引用
続きを読む
プロジェクトマネジメントとは「基準を作ること」である
久津（@Nunerm）です。
今回はプロダクトマネジメント（以下PdM）ではなくプロジェクトマネジメント（以下PjM）の話を書きます。
PjMにおいて大事なのは「基準を作ること」だという話です。
余談：PdMとPjM
いきなり余談ですが、よく「プロダクトマネジメントとプロジェクトマネジメントは違う」という話をよく聞きます。（違いについてはこちらの超わかりやすい記事にお任せします。）
元々プロジェクトマネージャーをやり、その後プロダクトマネージャーにシフトした自分としては、PdMとPjMの「どちらか」ではなく、両方できる人が強いと思ってます。PjMはプロジェクトのリスクを減らし効率的に進めるための武器なので、プロダクトマネージャーにとってはプロダクトが達成したい世界への最善の道筋を見つけることに役立ちます。逆にPdMの視点を持っているプロジェクトマネージャーは、事業戦略や優先度を把握しているのでステークホルダーとの調整などで役立ちます。
ただし自分がどっちを主軸にしているのかは明確にしておかなくてはいけません。例えば、「リスクが高いけどプロダクトの成長に大きく寄与する施策」の実行可否を検討している場合、PjMの立場だとリスクヘッジを重視するので、成長度合いを下げてでも失敗しない方法を選ぶ力学が働きますが、PdMの立場だとプロダクトの成長第一なので、成長度合いを最大限にするべくチャレンジする力学が働きます。
これを一人の人格がやってしまうと中途半端な成果しか出なくなりますし、周りのメンバーから見ると「いつも判断軸がぶれている」と思われてしまいます。なのでPdMとPjMを完全に別の人間がやり、双方にチェックし合う関係ができるのが理想ですが、組織の都合上難しい場合は、片方の役割を主軸とし、あくまで補助としてもう片方の知識を活用する意識が必要だと思います。
続きを読む
UX DAYS TOKYO 2019 カンファレンスレポート（ユーザーオンボーディング・行動経済学）
4/5（金）にUX DAYS TOKYO 2019のカンファレンスに参加してきました。本イベントは、海外の一流のスピーカーがUXをテーマとした講演やワークショップを行う、年１回のイベントです。
というわけで、個人的に面白かった２つの講演をざっとレポートします。
※まるで自分の主張のように書いてますが、講演内容を要約しただけですのであしからず。
継続的ユーザーオンボーディング by Krystal Higgins
Googleの「シニアユーザーエクスペリエンスデザイナー」の肩書を持つKrystal Higgins氏より、サービスにおけるユーザーオンボーディングのゴールとプロセスについての講演です。
３行でまとめると…
- ユーザーオンボーディングは"first run"を支援するものではなく、長期間にわたって定着してもらうための取り組みである
- カスタマージャーニーに合わせてオンボーディングをデザインする
- 様々なオンボーディング施策は行いつつも「まとまり感」を保つ
続きを読む
案件の優先度付けの基準を明確にする（狩野モデルのススメ） 〜NewsPicksアカデミア 及川ゼミより〜
久津（@Nunerm）です。
前回記事に引き続き、今回もNewsPicksアカデミアの及川ゼミの講義や懇親会からの学びをアウトプットします。
今回はプロダクトマネジメントにおける「優先度付け（プライオリタイゼーション/トリアージ）」についてです。
PMにとっての優先度付けとは
個人的には優先度付けはPMにとって最も重要な役割の１つだと思っています。
以前も別の記事で紹介しましたが、メルペイのPMの丹野さんがProduct Manager Conference 2018にて「PMの役割」を以下のように説明しています。
この「①事業目標を達成する打ち手を導き」の中に「優先度付け」が含まれていると思っています。
事業目標を達成するための案はステークホルダから様々なものが出てきます。例えばBtoCサービスの事業目標が「売上を昨対比で２倍」だとしたら、セールスは「新機能を作ろう」と言い、マーケターは「キャンペーンを打とう」と言い、UXデザイナーは「CV導線を改善しよう」と言い、エンジニアは「リニューアルしよう」と言います。
優秀なメンバーであれば恐らくどれも事業目標達成に寄与するはずです。なので極端な話、全部やればよいのです。
ところが現実はヒト・モノ・カネは有限です。全部できるはずがありません。よってPMが様々な観点から打ち手の優先度を決める必要があります。
その観点にはスコープ、コスト、工数、効果などいくつかの種類があります。そして各観点を整理してステークホルダーと事前にクライテリア（基準）を定めておくことで、優先度の合意がスムーズに進むようにしておく必要があります。クライテリアで役に立つアイテムとして、インセプションデッキのトレードオフスライダーが挙げられます。
ただしこれだけ準備しても揉める時は揉めます。その場合には「最終的にPMが決める」という状態を作っておくことが重要です。及川さんが講義の中で「民主主義からは良いプロダクトは生まれない。 必要なのは強い意志とそれを支える信頼。」という名言も出ました。つまり予め決めた基準でも判断できないことは、最もプロダクトに関して信頼を得ていて意志の強い（はずの）PMが決める、という文化を構築することが求められます。
とはいえ揉めないに越したことはありません。そこで、ここからは最も揉めやすい「品質」についてクライテリア（基準）を決めるためのアプローチを解説します。
狩野モデルを使って「品質」を分解する
狩野モデルとは、1980年代に東京理科大学教授であった狩野紀昭氏によって提唱された、マーケティングや品質管理に関するモデルです。
このモデルでは品質を３種類に分けて定義しています。
魅力品質
充足されていれば満足を引き起こすが、不充足であっても仕方ないと受け取られる品質要素。（自動車の例：「車内にWi-Fiが搭載されている」「先進ドライバー支援機能」）
一元的品質
充足されていれば満足を引き起こし、不充足であれば不満を引き起こす品質要素。（自動車の例：「燃費」「インテリア」）
当たり前品質
充足されていても当たり前と受け取られるが、不充足であれば不満を引き起こす品質要素。（自動車の例：「アクセルを踏めば進む」「エンジンがかかる」）
（余談）
日本のプロダクト開発現場において「品質」というとバグの少なさやパフォーマンス（非機能要件）などを意味することが多いので、上記でいうと「当たり前品質」「一元的品質」が該当するかと思います。魅力品質は「新機能」とか「付加価値」とか呼ばれてますね。
狩野モデルを使って優先度付けプロセスを可視化する
PMは案件の優先度をつける際に、
①各案件がどの品質に寄与するものなのか
②その品質は現状どれくらいの充足度なのか
の２点を見極めた上で優先度を決める必要があります。
いくつか例を挙げます。
「当たり前品質に寄与するが既に十分に充足している」案件
自動車の例で言えば、「エンジンのかかりをスムーズにする」といった感じですかね。一部のエンジンマニアには刺さるかもしれませんが、全体に及ぼす効果は小さいとみなせます。
「魅力品質に寄与するが現状全く充足していない」案件
自動車の例で言えば、「過去に類を見ない革新的な機能を作る」です。上の図に書かれているように、「充足していない＝顧客が求めていない」と予想されるのであれば、顧客の満足度は上がらないことが予想されるので優先度を下げるべきです。ただし「充足していない＝顕在ニーズを満たせていない or 顧客が潜在ニーズに気付いていない」と予想されるのであれば、イノベーションを起こせるチャンスがあるため、優先度を上げるべきと考えられます。ここの見極めはPMの腕の見せ所です。
「一元的品質に寄与するが既に十分に充足している」案件
自動車の例で言えば、「燃費を高めまくる」です。高燃費であればあるほど顧客満足度は上がると思われますが、ある程度のところから費用対効果が悪くなります。10km/Lを20km/Lに改善するのよりも、50km/Lを60km/Lに改善する方が圧倒的にコストが高いはずです。よってROIの観点から優先度を決める必要があります。ただし、コストをかけて突き抜けた品質を実現した際には、それが魅力品質に化ける可能性もありますので、チャンスと思えば優先度を上げて投資する選択肢もあると思います。
またこのモデルを使う際に注意すべきことがあります。それは「品質の定義は時代と主に変わる」ということです。
もともと魅力品質だったものは、技術の進化や競合の追随によって当たり前品質に変わります。例えばプリウスを代表とするハイブリッド車は10年ほど前は魅力品質でしたが、今では当たり前品質になっています。さらに電気自動車という新たな魅力品質も生まれています。
さらにいうと、20年ほど前は魅力品質だったカーナビ搭載車は、今はスマホの台頭によりもはや不要品質になってしまっています。
変化の激しいWeb業界においては、より短いスパンで魅力品質から当たり前品質 / 不要品質にシフトしていきます。その流れも俯瞰しつつPMは優先度を決める必要があります。よってマーケティングの視点も求められるのです。
改めてPMが狩野モデルを使って優先度付けをする際のポイントを箇条書きにします。
- 案件がどの品質に相当するのか、市場の動きを見ながら分類する
- 当たり前品質に分類されたものは、現状の充足度を見極めて、どこまでの充足が必要かを基に優先度を決める
- 一元的品質に分類されたものは、現状の充足度を見極めて、ROIの観点から優先度を決める
- 魅力品質に分類されたものは、顧客に本当に価値を与えているかの観点で優先度を決める
そしてステークホルダと案件優先度を合意するためのクライテリア（基準）にするために、この狩野モデルを使った優先度付けプロセスを組織内に展開して共通認識にしておくことが必要になります。
おわりに
優先度付けはPMにとって最も大変な役割でもありますが、醍醐味でもあります。この大変な役割をしっかり担い、ビシッと合理的に整理しステークホルダの合意を得ることができて、初めて「信頼されるPM」になることができると個人的には思っています。逆に多くの人の意見を聞きすぎて決められないPMはいつまでたっても信頼されません。
最近読んだ「君主論（まんがで読破）」の中でも、リーダーに求められるの素質の１つに判断力（決断力）があるという記述がありました。狩野モデルという武器を使いながらPMとしての判断力（決断力）を鍛えていきます。
「君主論 (まんがで読破) 」を読んだが、現代の企業や組織におけるリーダーに求められる要素も多く勉強になる。
— 久津佑介(HisatsuYusuke)🔥プロダクトマネージャー (@Nunerm) March 4, 2019
ざっくりまとめると「ビジョン・判断力・行動力・人を見る力があれば、人を惹きつけて組織を率いることができる」ということ。https://t.co/x583gWG8eu
ムハマド・ユヌスの偉業に学ぶPMとしての姿勢
久津（@Nunerm）です。
ムハマド・ユヌスと言う人物をご存知でしょうか。
バングラディシュの経済学者で、マイクロクレジット（＝貧困層に無担保で少額の資金を貸し出す貸金業）を行うグラミン銀行を創設したことで多くの貧困者を救い、2006年にはノーベル平和賞を受賞された方です。
この方の自伝を読んだのですが、バングラディシュに存在する「貧困」という問題を解決に導くプロセスや姿勢が、PM（プロダクトマネージャー）である自分にとっても非常に参考になるものだったのでこの記事でまとめます。
- 本当の問題を見つけるために現場を見にいく
- 曖昧な定義を具体化して分析可能にする
- 常識を疑い、データで意思決定する
- 新しい市場に投下する際にはローカライズを行う
続きを読む
RSGT2019に行ってないけどレポートをする
久津（@Nunerm）です。
1/9から3日間Regional Scrum Gathering Tokyo 2019が行われました。
参加してません(｀・ω・´)
けどTwitterの"#RSGT2019"タグで流れてくるツイートが面白そうだったので、スライドやツイートを勝手に見てレポートします。もちろん全部は無理なので一部だけ。
Regional Scrum Gathering Tokyo 2019 - 運用中のモバイルゲーム開発チームに、並行バージョン開発を導入してみた | ConfEngine - Conference Platform
EMFMファンにはおなじみのゆのんさん。
チーム人数が増えてきた時に「人数の割にはパフォーマンスが出ていない」という悩みはあるあるですね。"１＋１＜２"になりがちなのがチームというもの。そこで並行バージョン開発を導入してパフォーマンスを向上させたお話です。
うちの組織でも一回これと似たようなことを試してみたんですが、マネジメントが下手くそだったのでv.1.0.0チームとv.1.1.0チームのコミュニケーション量が減ってしまいました。例えばv.1.0.0が盛り上がってマネージャーがそっちにかかりっきりになってしまうと、v.1.0.0チームが放ったらかしにされてモチベーションが下がってしまったことがありました。
ゆのんさんのスライドのこのスプリントの組み立て方（つまりはLeSSっぽいスタイル）が有効なのかな。ここは詳しく聞いてみたい。
Regional Scrum Gathering Tokyo 2019 - ちゃんとやってるのになんかうまくいかないスクラムからの脱出 | ConfEngine - Conference Platform
とにかく絵が可愛い…
まだまだ自分はスクラム初心者で自分のチームも「なんちゃってスクラム」ですが、確実に最初はうまくいかないと思っています。うまくいくイメージが湧かないので。そんな時にこのスライドを参考にしたい。
この「コードレビューにかかる時間が読めない」のは自分のところも同じ。レビューイ・レビュアの組み合わせ、レビュー対象のコードの種類などでいつも時間がバラバラになるんですよね。そこへの打ち手として、全員の知識交換をして「チームとして納得するコードにする」というアプローチ。既にメンバー数人から「書き方がイケてないところがあるから書き直したい」と言われている現状では、この打ち手は有効かもしれない。
「スクラムを現実の上で回す」という表現は好きだな。決してチームのパフォーマンスを過大評価しているわけではないけど、スクラムに限らず開発のプロセスでは「想定」が入り込んでしまいがちです。現実を１つずつ可視化していって想定を排除していくことで、無駄やリスクの少ない開発ができますね。これは肝に命じておこう。ホワイトボードに貼っておこうかな。
Regional Scrum Gathering Tokyo 2019 - 行動分析学に基づくScrumの導入 | ConfEngine - Conference Platform
これは面白い！けどスライドだけでは十分に理解できない…！
スクラムがうまく機能しないので何かの「行動」を改善したい時に、その行動が引き起こす後続事象に着目するというアプローチということですかね。
後続事象がその行動に対して「好子」なのか「嫌子」なのか、つまりその行動を繰り返したくなるのかやめたくなるのかを把握し、そこをデザインし直すことで行動自体を改善するということ。
これは現場で聞きたかったなあ…
Regional Scrum Gathering Tokyo 2019 - プロダクトの「負債」を「機能」と呼び直すために ーA/Bテストを用いた"価値"の定量化ー / Fact based decision making | ConfEngine - Conference Platform
これは刺さる内容だ…！
表面上の数字だけで機能を「負債」と定義してしまって、特に深掘りもせずに切り捨ててしまい、気づいたら売上やユーザー数などの指標が悪化しているパターン。ありがちですね。
このスライドの例で言えば、キャリア決済の存在と売上・CVとの間の因果関係がテーマになってますが、この因果関係をアクションログなどから求めることは、相当データ分析に秀でた人材がいない限り難しいと思います。
では因果関係を明らかにできない時にどうするか？ありがちなのは「思考停止」すること、つまり表面上の数字だけで「たぶんこういう結果になるだろう」という思い込んで意思決定してしまうことでしょう。そっちの方が圧倒的に楽なので。
それをこの発表の例ではしっかり労力をかけてA/Bテストで因果関係を明らかにしました。いやー素晴らしい。この姿勢は見習います！
Regional Scrum Gathering Tokyo 2019 - そのときサーバントリーダーはどう振る舞うか | ConfEngine - Conference Platform
「サーバントリーダー」って何と無くイメージは湧くものの、具体的に何をクリアできればサーバントリーダーなのかモヤモヤしてたので、このスライドはいいヒントになりそう。
特にこのページが刺さりました。
メンバーが楽しく仕事をしてパフォーマンスが上がっていれば「ああ、俺良いサーバントリーダーだな」とか勘違いしてしまいがちなところで、改めてこの４つの観点で自問自答すると穴が見つかるはずです。特に「立場を超えた本音を聞けている気がしない」と「信頼されるだけのOutputを見せられているか不安」はまさに自分もそう思いました。
「傾聴」「共感」「癒し」「納得」の観点で本当に自分がサーバーントリーダーに慣れているのかは常々自分を客観視します。
以上、「RSGT2019に行ってないけどレポート」でした。
もちろん実際に参加する方が学びは多いはずだけど、こうやってスライドだけで学ぼうとする作業も大変だけどその分頭をフル回転させる必要があるので、色々気づきがありました。
とは言え来年のRSGT2020は絶対参加します！
