組織の話、の前に定義しておきたい概念
書籍 「プロダクトマネジメント ― ビルドトラップを避け顧客に価値を届ける」 から要約 (この本とても面白いのでおすすめ)
https://www.amazon.co.jp/dp/4873119251/
プロダクト
価値を運ぶもの。我々はプロダクトを通じて、顧客が実現したい価値を届けます。その対価としてビジネスとしての価値を受け取ります。
サービス
プロダクトとは異なり、価値を届けるために人手を介在する物をサービスと定義します。
例えば、メルカリはアプリはプロダクトですが、全体としては人手を介在しなければ成り立たないサービスであると言えます。
ネットフリックスは、問い合わせなどの一部を除けばほぼプロダクトと言えます（コンテンツ制作を無視した場合)
プロジェクト
作業のかたまりの事をいいます。ある目的を達成するために具体的な期日や予算、アウトプットが設けられています。
プロジェクトは完了する事が目標であり、その後のことについてはまた別のプロジェクトとして発足します。
(私の考えている)肩書きと役割
CEO
ビジョンを示す。リソースの配分を決める。(優れたCEOは)適切な権限移譲をすることで組織を拡大する。
CTO
CEOの示したビジョンを達成するために、必要な技術的基盤を作ったり、拡張可能な設計を先んじて行ったり、チームに新しい技術の開拓を促していく人。
優れたアーキテクト。未来志向。技術志向。
VP of Engineering
エンジニアリング組織のスループットを最大化する人。技術に詳しいが、それはあくまでチームの成果を継続的に拡大していくためのもの。
チームビルディング、採用、コーチング、(エンジニアチームの)リソース配分を決める。
PdM (プロダクトマネージャ)
プロダクトの価値を最大化することに責任を持つ。何をリリースすべきかにコミットする。
リリースの期限や品質などスコープについて要望はできるが指示はできない（そこはPjMの責任)
「リリースしたものから何を得たか？ (顧客と何を価値交換したのか？)」にフォーカスする。
マーケットリサーチやユーザーインタビュー、リリース判断に重きをおく。
PjM (プロジェクトマネージャ)
リリースするもののQCDS (クオリティ、コスト、デリバリ、スコープ) について責任を持つ。PjMはプロジェクトの達成を最優先するため、部署間での調整がメインの仕事になりがち。
プロジェクトを乗り切ったら終わりという考えなので鬼PjMが主導するとメンバーに燃え尽き症候群が起こりがち。(別の視点から見ると、そうでもなければやっていけない状況に追い込んでいるのはPdMやCEOだったりする？)
EM (エンジニアリングマネージャ)
PjMからなされる要求を解釈し、開発チームが要求に対しどこまでコミットできるかを判断する人。
状況に応じてリソースの配分も行う。基本的にはVPoEと同じ役割で、範囲を狭くした人。
TL (テックリード)
開発チーム内で技術的な方向性について、判断に大きな影響を持つ人。どこまで責任をコミットするかはその時々による。
人のマネジメントはテックリードの役割ではない。
で、私は何を思っているか
PdMが必要、開発チームが自己組織化できていればPjMは不要
- 何をリリースすべきかを正しく判断できなければ、プロダクトは価値を生まない
- 非常に難しい仕事だと思うのでそこにフルコミットする人がいてほしい
- いるんなら、もっと全力で開発チームにそれをフィードバックして欲しい
- 開発チームは自分たちが作るものに責任を持つべき
- 「いつまでに作って欲しい」という要求に八方美人をしてはいけない
- 逆に、自分たちがコミットした期限は死守する
- そういう関係でありたい。が、現実は厳しい...
何が現実を厳しくさせているのか？
-
プロダクトとして「今これが一番大事」というコンセンサスが取れていないから
- みんな自分の仕事が一番大事だと思ってる
- 結果、押しつけあいが起こってませんか？
- あれやってください、これやってください、これも大事...何が一番大事？？
- リソースは有限
- 前にチームメンバーと話したこと 「放置したPRはどんどん腐る」
-
本当に今やらなければならないことは何か？が分かっていれば、それを一個ずつ流せばいい
- トヨタ生産方式
- ↑にインスパイアされたのがリーンスタートアップ
価値とはなんだろう
- それが分からなくて色んな現場を彷徨っている（今も分かってない）
- 自分は本当はPdM向きなのかもしれない
- でもやっぱ作ってるの好きなんだよなあ。もっと納得しながらものづくりをやっていきたいんだと思う。