プロダクトマネジメント

「プロダクトマネジメントのすべて」の違和感が何かが一部分かったので整理。
https://www.shoeisha.co.jp/book/article/detail/309
プロダクトマネージャーというとき、少なくとも狭義では販売はしないが、販売行為やマーケティングってマネジメント対象ではないんだっけ、プロダクトのマネジメントってなんだっけ、と思ったのがきっかけ。
プロダクトを成立させるとき、私のような人間は、まずタスクや"やるべきこと"があって、それが最終的に達成されることでプロダクトが成立すると考える。ところが、上記のリンクでは、タスクややるべきことというよりも、メンバーが先立つ形で、あるいはかなり具体的に職責の定まったロールに対応する職責のメンバーの定義みたいにチームが定義されている。ここが、私の理解の形とは違うし、実際の科学的機序（？）みたいな事ともちょっと違うと思われて、違和感なんだな。
プロダクトマネージャーには人事権がない、という事もあって、与えられたチームでプロダクトのマネジメントをする人、というのは正しいといえば正しいが、プロダクトの力学・構造みたいな事ではないので、その辺に違和感があるということだな。

役割というのは、やるべきことをどう捌くか？という設計なのであって、まずやるべきことがあって、それに対してどうチームを設計するか/されているかというのを考えてほしい。これが天下りだと、実務に寄りすぎているという感じがする。めちゃくちゃ失礼な言い方をすれば、上から降ってきたことをやる、みたいな。そのレベル感で読むには親近感があってよいが、私には違和感として感じられる。（この書き方が必ずしも悪いということではなくて、単に私の違和感の正体ということ）

※もちろん、プロジェクトみたいに明確な終わりがあるという事ではないので、"最終的"といっても何かの最後があるという事ではなくて、継続的にやるべきことをこなし続ける事にはなる。

この本ではプロダクトチームのデザインこそがプロダクトマネージャーの本質的な仕事であると主張しているように見える部分もあるから、それであればこそ...

• まずプロダクトの全貌をチームメンバーと切り離して書く
• タスクややるべきこととしてはかくかくしかじかの物があると書く
• 一般的な事例として、ロールで分けて設計した例を示す

みたいな方が（わたしは）いいな

役割には正解はないんだけど、役割以前のやるべきことには正解というか実際にやらないといけない事/やった方がよい事としての"正解"はある。
その中で、どういう力点をおくかというのが、ロール定義・メンバー定義で、設計という事になると思うけど。

プロダクトマネージャーが究極的にやるべきことは

• プロダクトチーム≒プロダクトが開発される仕組みの構築（制度/仕組みとして）
  • （前提として）プロダクトの目的の定義
  • 目的の達成にも構築にも時間をかけて状況を変化させていく必要があるので、その変化の組み立て（戦略）
• その仕組の維持（制度にメンバーをあて、理想的な役割をメンバーが継続的に果たせるようにする）
  • やるべきことが明確な上での遂行
  • 具体的なチーム構築の実践
• その仕組が意図する機能を実現できているかの確認、意図通りでない場合の改善（理想像自体の改善を含む）
  • 仮説検証
  • やるべきこと自体を明らかにしていく意味での遂行

といった感じなんだろうな。
仕組みが実現されれば、"結果的に"プロダクトは"成長"するようになる。具体的に遂行することは、プロダクトマネージャーがやっても良い場合もあるが、基本的には他のメンバー（のロール）が遂行するという

（実装をする立場では成果としてのプロダクトを直接変更できそうに思えてしまうが）成果としてのプロダクトは直接的に変更可能な変数ではなくて、それを作り上げる仕組みの方を管理すべき変数として扱う、ということ。

ところで、事業がプロダクトを内包するかプロダクトに外包されるか、というのは結構難しい。
私（たち）の場合、一つのプログラムを複数の企業に提供して、その企業の中で事業として成立させるという事をやっているが、このプログラムをプロダクトと思う時、

• 私たちが直接提供するサービスとしては、このプログラムは私たちの事業の中に内包される
• 関係各企業の事業がサービスによって成立しているという意味では事業が部分的にサービスによって定義されている（部分的に外包されている、ただしもちろんサービスの外で成立している事業もある）

みたいな事がある。（事業責任者とプロダクトマネージャーの位置づけで考えたこと）

プロダクトマネージャーに必要なスキルも、チーム定義まわりと同じ違和感だな。
つまり、根本的に必要なのは「○○力」ではなくて「○○を遂行すること」である。まあ、「○○を遂行することができる力」を「○○力」と呼んでいる、と言われればそれはそうだけど。説明というか理解の順序というか、機序として。

必ずしもプロダクトマネジメントではないが...

• サッカー選手には役割がある
• サッカー選手は野球をするためのロールではない
• サッカー選手は審判をするためのロールではない（練習や遊びなどを除く、試合当日において）
• サッカー選手には戦略的なポジションがあるが、ポジションの境界でチームが損をしないよう、ある種の越権的/明確に線引きされていない行動を自分の判断で取る
  • 例）ディフェンダーでもシュートが決まるタイミングではシュートする

つまり、明確にやらないことと、いざとなればやる必要があることとがあり、それらの線引きが必要になる。

スポーツ漫画を読んでいると、こういうのって言葉で整理された概念として説明はされていなくて、ただ当たり前の概念として触れている。かつ、だいたいの場合において、雑用みたいなこともきちんとこなしたり、チームの勝利に必要なことはなんでもやるというのが道徳的に推奨されていて、私はそれを常識だと思っていた気がするが、実際には常識という事ではない。
その意識を合わせる事が必要になる。

「プロダクトマネジメントのすべて」に関しては、とりあえず謎の決めつけというか、根拠のない/すぐに微妙な反例が浮かぶタイプの断定があるので、それも違和感があった。そうした違和感を除いて、ただ事実だけをうまく汲み取ると、知識の整理はできる...かな？

つまり、もう少しサイエンス/ロジカルに間違っていない感じの教科書が欲しいということだな。
経験的事実の羅列は、個々の事象は正しいかもしれないが、それを踏まえた推論とか説明の仕方がロジカルでないとどうしても違和感が出てしまう。単に方法を身につけるだけであれば、アンラーンというか論理的破綻みたいな事は無視した方がはやいが...

私がどういうスタンスでプロダクトマネジメントと向き合うか、という事も決めないといけないな。
私は作業も好きだが、必ずしも作業ができないといけないという事ではなく、本質的には「思ったことが実現できればそれでいい」というところではある。
ただ、「思ったこと」を正確に伝えるのがかなり難しくて、それでコードを書いたりPoCしたりという手段で伝えることになり、それでも伝わりきらなくて最後まで自分で作らざるを得ない、みたいな事になっているように思う。思いついたことを実現する時、説明して実現するのが大変で、説明せずに実現しちゃう。とにかく実現するという事に興味があるので。

という事なんだろうな。数学の時からそうではあるが、実現できると思ったことが確かに実現できる事を示す、という事が私が一番本質的に好きなこと。その「実現」にはいろんなレイヤーでの難しさがあって、なんだかんだ最初から最後までやらないと示せないという事がある。
かつ、その後の維持も難しい場合があるので、維持もできるという事を示したくなる。
まあ、それは縛りゲー宣言とかで2021/1には既に思っていた事ではあるが、いまだに単純効率の意味で逆転する目処が立っていないので、とにかくその目処をどうやって立てていくか。
もっと実際の作業から引いてもより良い物が得られるという確信が得られる、というのがいつか。
いくつかのパターンはあって、最終的に磨き上げる作業みたいなのが必要な場合は、多分私がやるよりも良い成果が得られるものがある。

「できる事を示す」

• まだ形がないものについて、できる事を示す
• 難しいものについて、できる事を示す
• 実際に成立する状態にするという意味で、できる事を示す