# 初めに（動機）
プロダクト会に一人に参加することがあり以下のような不安を感じていたため。
- 機能の追加でなく、改善するタスクを行う際にどの方法が適切か判断できずに躊躇してしまう
- タスクの優先順位が決めれない
プロダクトの管理する人の、考えや仕事内容を理解すればこの問題が解決するのではと思いプロダクトマネジメントについて書かれている本を読んだ。（本当はおすすめされただけです）
説明する内容
- プロダクトマネージャーと言われる役割の人が求められていること
- 1.1 役割
- 1.2 プロダクトの成功について
- 1.3 求めらること、必要な仕事
- 1.4 まとめ
- プロダクトについて
- 2.1 プロダクトの4階層
- 2.2 階層からわかる読み取れるタスクの優先度
- 2.3 考慮しないといけないタスク
- まとめ
※ 内容は、主に書籍「プロダクトマネジメントのすベて」について書かれていることである。
# 1.プロダクトマネージャーと言われる役割の人が求められていること
# 1.1 役割
プロダクトマネージャーの仕事は、一言で言うとプロダクトの成功させること。
# 1.2 プロダクトの成功について
プロダクトを成功させるには、3 つ要素が必要になる。
- ビジョンの実現(プロダクトを通して実現したい世界)
- ユーザーに価値を提供
- 事業収益を上げようとしている
各要素は、それぞれ実現しようと行動する時にトレードオフの関係にあるのでバランスを取る必要がある。
例 : 事業集積を上げようとし、広告をサイトに貼りまくる(事業収益を優先して、ユーザー価値を犠牲) -> ユーザーに関心がある広告を貼る (事業収益とユーザー価値のバランスをとっている)
# 1.3 求めらることと、必要な仕事
プロダクトに関わるあらゆるプロセス(ビジョンの構築、戦略立案、開発,UX)の意識決定に責任を持つ。
関わる領域が広い（ビジネス（収益性）、ユーザー体験（UX）、実現可能性（テクノロジー））
責任も持つことは、今ない専門性を得るために専門性があるメンバーを探す or 自分が専門性を見つけること なのでプロダクトに対する興味・情熱が求められる。
# 1.4 まとめ
プロダクトに関わる人も意思決定に責任こそ持たないが、プロダクトマネージャーのようなプロダクトへの興味・気持ちを持つべきだと感じた。
プロダクトマネージャーの考えを理解し（プロダクトのミッションやビジョン）、プロダクトを成長させると言う意識を持つことで、各レベルでプロダクトとしての方向性にブレがなくプロダクトへの成功に近づくことができる。
# 2. プロダクトについて
プロダクト作る際には、どういう価値を提供したいとか、誰が使うのか、ユーザーが困っていることを考えるプロセスがあるはず。
ただ、残念なことにそれが正しいのかどうかは検証して見ないと分からず全ては仮説となる。
それらの仮説が互いに連鎖している。（仮説が前提の条件になっている） 仮説の関係性を整理しておかないと、一貫性のないプロダクトになってしまう。
# 2.1 プロダクトの4階層
仮説の連鎖を可視化するための、4階層の分割
- core
- ビジョン・ミッション 全ての仮説の元で核となる、一番抽象度が高い あまり具体的にならずに、共感してもらえるようなもの（狭めすぎると、軌道修正ができない）
- 事業戦略 事業戦略では、プロダクトに設けている制限を明確に（具体的な収益、プロダクトの領域は決まっているか。）
- why
- 「誰」の「何」を解決したいか（ユーザー目線） ユーザーが価値を感じるか ビジョンとミッションが満たされるか
- なぜ自社が行うのか（プロダクト目線） 内部環境（自社の強み,弱み） 外部環境(ポジティブなものとネガティブなも両方)
- what
- ユーザー体験の設計 ユーザーの目的が達成されること、達成までの使い勝手
- ロードマップ
- ビジネスモデル
- how
- どのように実現する タスクとして積むときは、ユーザーストーリとそれが満たされているかの条件を明確に示すと良い
これはプロダクト全体レベルだけでなく、機能の単位でも言える。 ある問題がある時に、それへの解決策は仮説であるので検証しないと結果が分からない。
# 2.2 各階層からわかるタスクの優先度
第3層(what)からわかる優先度
この時点では、ビジョン実現するために何で、誰の何を解決するかが決まっている。 ビジョンの実現のために行動表となるロードマップを作成する。 ただいきなりビジョンの実現を達成するのは難しいため、段階を踏んでゴールに進めるようにするのがいい。
フェージング
一度に全ての機能を実装するのではなく、段階的に実装していく。
- プロダクトレベル 途中のゴールとなるマイルストーン(チェックポイント)を設定する
- 機能レベル mvp(minimun viable product) 実用最低限の機能を提供する
段階的にやることで、経過通りに進めるか変更するか検討できる。 もし思ったほどの効果があがらなかった時にダメージが少なくて済む。
マイルストーンは適宜更新される可能性がある。（別で優先度が高いタスクが発生） マイルストーン（どういう順序）、mvp(必要最低限)の認識のずれがあると重要なタスクの優先度が変わってしまう。
# 考慮しないといけないタスク
- 技術的負債を解消するタスク 技術的負債の解消については、負債たまることへの影響（開発速度の低下、保守コスト）についてプロダクトマネージャーと話し行動表に含めてもらうようにする。
- セキュリティーの強化
# 3. まとめ
機能追加・新規プロダクトの追加は仮説を元に（リリース前に検証できるものがある）実装して検証される。
プロダクトに関わる人間がプロダクトマネージャーのように熱意を持ってこのことを理解していれば躊躇せずにチャレンジできるようになる。
また、ビジョン実現するために何で、誰の何を解決するかを理解していれば必要でない機能についてはやらないと意見することもできる。
タスク間の優先度については、提示されているロードマップ・マイルストーンを認識し段階的に進めていくことを認識すれば重要なタスクの優先度が下がることはない。