案件の優先度付けの基準を明確にする（狩野モデルのススメ） 〜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は絶対参加します！
PMは技術力やドメイン知識をどこまで持つべきなのか 〜NewsPicksアカデミア 及川ゼミより〜
久津（@Nunerm）です。
「日本のPMといえば？」という問いに高確率で名前が出てくるであろう人といえば。
及川卓也さんですね。
この度その及川さんから「プロダクトマネジメントの極意」を伝授いただける機会に恵まれました。NewsPickアカデミアのゼミです。
決して安くない受講料のゼミの30人の枠に対して60人の応募があったそうで、日本でもプロダクトマネジメントを学ぶ必要性に迫られている人が増えてきているんですね。
というわけで、この記事では初日の講義での学びである
「PMは技術力やドメイン知識をどこまで持つべきなのか」
の考察を書きます。
PMは技術力やドメインに詳しくあるべき？
PMの役割には色々な定義がありますが、メルペイの丹野さんの言葉を借りると以下のようになります。
このうち①を実現するためには、PMがその事業が属するドメイン（領域）を理解する必要があります。事業目標は通常そのドメインに存在するカスタマー、クライアントなどの全てのステークホルダーの課題や心理を理解し、かつ外部環境（景気、競合、規制など）をしっかり把握した上で立てられます。
事業目標自体はPMではなくCEOや別の人が決めることが多いと思いますが、その背景や狙い、本質をしっかりPMが理解しないと「事業目標を達成する打ち手」を導くことはできません。よってPMがドメイン知識を持つことが求められるのです。これがPMが"miniCEO"と呼ばれる所以でもあります。
pixivの清水さんのpmconf2018 の発表でも、特定ドメインのプロフェッショナルになることによるメリットが語られています。
続きを読む
プロダクトマネージャーは「組織の視力」を把握しよう
久津（@Nunerm）です。リクルートでPM/EMをやってます。
この記事は、Product Manager Advent Calendar 2018の23日目のエントリーです。
今回は「プロダクトマネージャーは『組織の視力』を把握するべきだ」という考えを書きます。
今いる環境でPMに何が求められるのか？
「プロダクトマネージャーの役割とは何か？」
これはPM界隈では常に問われる疑問です。
PMに求められるスキルや考え方は多岐に渡っていて、実際に活躍されているPMの方々が持っている武器も様々です。（エンジニア出身の人、マーケター出身の人、デザイナー出身の人…）
また組織やマーケットによっても求められる動きや成果は変わります。
プロダクトマネージャーカンファレンス2018で登壇されたのBaiduのPMのChenさんという方のプレゼンでも「アメリカと中国で求められるPMのスキルが違う」というお話がありました。アメリカはニーズがある程度一様化しているため、そのニーズを技術力で解決できるPMが求められる。中国ではニーズが極端に多様化しているため、解決されていない新たなニーズを探すことができるPMが求められるとのことでした。
つまり。
「プロダクトマネージャーの役割とは何か？」
に対する答えは、いくらでもあると思うのです。
大事なのは、自分の武器を認識し、かつ今いる組織でPMに何が求められるのかを理解した上で、目指すべきPMの姿をしっかり定義することです。
では「今いる組織でPMに何が求められるのか？」はどうやって知ることができるのでしょうか？
私は「組織の視力」を把握することでヒントを得られると思っています。
続きを読む
ボロボロのチームを立て直したエンジニアリングマネージャーのお話
久津（@Nunerm）です。リクルートでPM/EMをやってます。
この記事はEngineering Manager vol.2 Advent Calendar 2018の15日目の記事です。
普段このブログではプロダクトマネージャーに関する記事を書いていますが、エンジニアリングマネージャーも担っているので、この記事ではEM人格で語ります。
さて、エンジニアリングマネジメントにまつわるエピソードには様々なものがあります。ゼロからチームを作り上げた話、初めてEMになって試行錯誤した話、新しいやり方を装着しようとして失敗した話などなど…
今回は私は「ボロボロのチームを立て直した話」を書きます。このシチュエーションと似た経験をされた方がどれくらいいるのかわからないですが、何かしらヒントを得ていただけたら幸いです。
※なおこの話はリクルートの話ではありません。とある別の企業での話ですのあしからず。
- 序章：ボロボロのチームにジョイン
- 第一章：外部環境を整える
- 1-1.改革の宣言・ブランディング
- 1-2.意思決定プロセスの整備
- 1-3.技術的負債の可視化と解消によるメリットの説明
- 第二章：内部環境を整える
- 2-1.メンバーへの信頼を示す
- 2-2.チームビジョンの再定義
- 2-3.多様な内発的動機と向き合ってくすぐる
- 2-4.心理的安全性の担保
- 第三章：自ら成長できるチームへの変貌
- 3-1.チームのカオスエンジニアリング
- 3-2.階段を刻み、踊り場で遊ばせる
- 終章：１年後…
続きを読む
