Product Manager・プロダクトマネージャーの企業における役割など
プロダクトマネージャーとして幾年にもわたり複数の企業で経験を積んできた友人から教わった「プロダクトマネージャーとはなんぞや」的な話を、備忘録としてまとめる。
（プロダクトマネージャーの定義は企業によって若干異なるため、あくまでも友人の経験に基づいた話となる。）
プロダクトマネージャーとは
プロダクトマネージャーはマーケットに対してどのような戦略でどういったプロダクトを世の中に展開し、成功させるのかを最初から最後まで見届ける役割である。
その中の最重要タスクとは課題(Problem)に対する解決策(Solution)を常に考えることである。
課題の定義付け
そもそも課題が何なのかを特定する必要がある。そこでProduct Discoveryフェーズで課題の特定を行う。
課題の特定は各ステークホルダーとの打ち合わせを通して精緻化していく。
課題がある程度特定できた後に重要なのは、データに基づいた当該課題のバリデーション（検証）だ。
バリデーションはUXチームなどによるユーザーインタビューや市場調査などを通して、「その課題は本当に課題なのか？」を証明・確認するプロセスである。これを行わないとそもそも意味のないプロダクトに着手してしまうため重要。
また、ユーザーインタビューを通してUser Journeyの明確化も行う。
課題を特定し、バリデーションが終わることで課題の定義付けが完了する。
ユーザーストーリーの作成
課題の定義後、リサーチに基づきユーザーストーリーを書き出すことで、ビジネス要件定義を行う。ユーザーストーリーとは課題に対する解決策を文章化したものだ。ユーザーストーリーの書き方としては下記を含むと良い：
As a （誰：ペルソナ）I want to（機能：何がしたい）so that（付加価値）
企業によってはこれをまとめたものがPRD（Product Requirement Document）とも呼ばれているが、友人曰くPRDだとWaterfall過ぎて開発が遅いことから推薦しないとのこと。
ユーザーストーリーをグループ化するとEpicとなる。ユーザーストーリーは各機能で、Epicとは機能の集まりで実際の解決策となるものである。
例として、Instagramストーリーを挙げると、「写真のアップロード」、「フィルター」、「文字入力」、「タグ付け」、「閉じる」などは全てユーザーストーリーであり、それを一つにまとめた「Instagramストーリー」はEpicである。
このユーザーストーリーをどのように書き出すかというと、ミーティングなどを通して「誰が使うのか？（ペルソナ）」「実現可能か？」、「スペック・デザインは？」、「サクセスクライテリア（成功の定義）は？」などといった質問に答えていき明確化していく。すべてのユーザーストーリーを書き出した後に、Epicとしてまとめていく。
デザイン
また、ユーザーストーリーのデザインはWireframeというものを作成していく必要がある（いわゆるMock upというもの）。これはBalsamicなどのソフトを使うと良いらしい。
Vertical Slicing
ユーザーストーリーを書いていくにあたって、重要な考え方としてVertical Slicingというものがある。Vertical Slicingとはユーザーストーリーを書く際にFront end、Back end、Dataという三つの軸のすべてを網羅できていないといけないという考え方である。
また各ストーリーはエンジニアチームが2週間のスプリントで完遂できるものであるよう意識しないといけない。
反対にHorizontal Slicingというものがあり、これは熟練のPdMでも頻繁に陥る考え方である。こちらは先ほどの3軸のうち一つだけ定義または深堀してしまうパターン。
スコープ
ユーザーストーリー及びEpicのスコープが何かをインタビューやミーティングを通して認識を合わせる、定義していくことを意識する。スコープ外になるものは何か？を考える。
例外の取り扱い
ユーザーストーリーを書く際にExceptions（例外）はどうに扱うか考えておくことも重要。例外の場合、ユーザーに何を見せるべきか？エラーはどう対応するべきか？
作業量の推定
ユーザーストーリーを書きあげたが、どれくらい時間と工数がかかるのか？
一般的には日数を用いることが多いと思うが、PdMが多く経験するであろうアジャイル開発ではStory Pointsというものを使われることが経験上多いと友人はいう。
Story Points手法とは、0.5から13までのFibonacci数列に基づいた数字・点数を各ユーザーストーリーに振り当てていくプロセスである。大きい数字ほどより複雑・工数の掛かる度合いを表している。
イメージとしては、0.5~2が「簡単」、5~8が「普通」、9~13が「難しい」といった具合で、全てのユーザーストーリーが互いに比べてどれくらいの難易度なのかを決めていく。例えば「2」のユーザーストーリーは「1」のものより二倍時間と努力が掛かると考える。チームによるが、13もしくは21よりも大きい場合、ユーザーストーリーの細分化を検討する。
この点数をベースに、エンジニアチームがスプリント（約2週間程度の開発期間）毎にいくつのユーザーストーリー（点数）をカバーできるか計算する。この計算はスクラムマスターが行う。ここで算出する点数というのがAverage Velocityと呼ばれる、いわゆるチームの開発スピードだ。（大体30～40が目安）
ユーザーストーリーの優先順位付け
ユーザーストーリーを書き終え、Epicとしてカテゴライズし、作業の工数を計算したのち、どれから着手すべきなのかを明確にする必要がある。
優先順位付けの手法はいろいろあるが、その一つがMoSCoWという手法だ。
Must Have: 初回リリース時に含むべき機能
Should Have: マストではないが、重要な機能
Could Have: あれば便利で付加価値を生むが、優先されるべきではない機能
Won't Have: リリースには含む必要がない機能
実際に開発に着手していくにつれ、フィードバックが各方面から上がってくるはずなので、それに基づき優先順位を再定義する必要があることもある。
また、優先順位付けとともに重要なのはMVP（Minimum Viable Product）の定義付けだ。MVPはあくまでも考えている解決策が定義した課題を本当に解決できるのかを安く、簡単に、検証するため。
ロードマップの策定
着手する機能やMVPの定義が終わったら、これを時系列に並べることでロードマップを作成する。ロードマップはGanttチャートやWBSのような詳細なものではなく、ハイレベルにいつ何が起こるのかを取りまとめたものでよい。数字ではなく、いつ何が起きる予定なのかだけ明確にわかるのが重要。
その他
ロードマップを作成したら開発着手なのだが、他にも細かい点を書き留めておきたいのでここでまとめておく。
まずPdMとして重要なのはエンジニアとUXチームが仕事を遂行するのに必要なものをすべて準備することである（主にユーザーストーリーとその優先順が多いと理解）。技術的な話や課題は各スペシャリストやチームが担当するべきである。
アドバイスとして、チームごとに仲の良い人を一人作っておくことだと友人は言う。それによりコミュニケーションの円滑化が見込める。
Technical Debt
一点気を付けたいところとしてTechnical Debtがある。Technical Debtとは開発の最中、問題などが発生したため、ベストではない手法、または応急処置的な理由により何かを作成してしまい、後々に修復や取り換え作業が必要なものだ。どのチーム・企業でも発生するものであり、一定数は許容できるが、これをため込みすぎると新機能の開発などに手が回らなくなり、結果として大きな損害を生んでしまいかねない（実際筆者が受けた某大手日系企業のPdM面接では、実際にTechnical Debtが多すぎることで、新機能開発ができていないというのがうかがえた）。
対応策としてはそもそもユーザーストーリーをしっかり書くなどがあるが、起きてしまった場合スプリント毎にTechnical Debtを直す枠を一定数設けることで、少しづつ改善していくことが最善（全体の2～3割程度の時間が目安）。
その他フレームワークなど
CRUD手法
PdMとして評価されるには適度にユーザーストーリーを実現させつつ、大きなものも定期的に展開するのがベスト。これを行うにはしっかりユーザーストーリー及びEpicのサイズを正しく定義することであり、その手法としてCRUDというものがある。CRUDとは全ての機能が、そのEpicで何が：作成されるのか(Create)、見るだけなのか(Read)、更新されるのか(Update)、削除されるのか(Delete)。Epicで上記4つのうち1つあてはまらないものがあれば、それはカバーできていないシナリオがあるかもしれないという確認になる。
わかりにくいので例でいうと、先ほどのInstagramストーリーだ。Instagramストーリーを作成する部分においてだと：
「写真・動画を投稿する」→Create
「フィルターライブラリを見る」→Read
「タグ付けする」→Update
「ストーリー投稿をやめる」→Delete
仮に「ストーリー投稿をやめる」というシナリオを考えていなければDeleteに該当する部分が欠如しており、UXは悪化するだろう。このように描くシナリオを簡単に確認する手法としてCRUDがある。
INVEST手法
ユーザーストーリー作成のガイドラインとなる手法。
Independent：他の機能として独立して行える機能か
Negotioable：他人が見て違うユーザーストーリーを提案できるような内容か
Value：付加価値を提供するか
Estimatable：エンジニアがStory Pointなどでしっかり作業の目途がつけれるものか
Small：大き過ぎないか
Testable：しっかり機能しているか確認できるか
Definition of Ready
ユーザーストーリー、解決策、デザイン、作業量、の定義ができていること。
Definition of Done
機能・プロダクトが完了したか最終確認するためのテスト・チェックリスト。大抵はエンジニアが担う業務。
Burndown Chart
PdMが作成する必要はないが、読めないといけない。リリース時期がいつ頃になるか明確にするためのチャート（用途としてはGanttチャートに似ている）。スクラムマスターと一緒になり、ステークホルダーへのコミュニケーションツールとして使用する。