
2025.02.28
「経営者がAIに興奮しているかがポイント」 DeNA南場会長が語る、10人でユニコーンを作る時代とは
リンクをコピー
記事をブックマーク
小城久美子氏:では後半の「プロダクトマネジメントをエンジニアが推進する」というところで、3つの話をしようかと思っています。
まず1つ目が「『他職種のゴール』を知って手を差し伸べる」という方法での推進の仕方です。(スライドを示して)さて、これもなかなか辛いスライドになりますが、私の過去の失敗からやってしまったことをスライドに起こしています。
相手の仕事を知らないと、例えばビジネスの人がどういうことをしているかを知らないと、急に「ダッシュボードを作ってください」と言われても、すぐに批判者になっちゃうんですよね。「あの人たちはこっちが忙しいのも知らずにあれもこれもって言ってくる」みたいなことになってしまいます。
相手のことを理解できていないと、代替案みたいなのも出せないし、相手のことがわからないからどうしても批判的なことを言う以外に何もできなくなってしまうことがあると思っています。それは「わからないから」ですが、これが広がれば広がるほど、お互いに分裂みたいなことが起きてしまうんですよね。
それが起きないためにはどうすればいいかというのは、相手のゴールを知ることだと思っています。相手が言っていることが良いことか悪いことかみたいなところを批判するんじゃなくて、他職種の人はどうしてそのゴールを目指しているのか。そのゴールは、自分が思っているプロダクトの1本の意思決定の軸と一緒だろうか。
もし一緒だったら、そのHowは違うかもしれないけれど、「エンジニアとして別のHowでもっと良くできる方法があるかもしれない」みたいなことを考えられるようになりますよね。
なので、他職種の人がどういうことをしたいのかというHowのところだけじゃなくて、ぜひWhyのところにまで興味を持って話せると、エンジニアもプロダクトマネジメントを推進できるようになるんじゃないかと思います。
(スライドを示して)もう1つは「『プロダクトチーム』として議論に参加する」と書きました。先ほど話したとおり、プロダクトマネジメントはプロダクトマネージャーだけがするんじゃなくて、チームみんなでやりましょうということです。プロダクトマネジメントの成果物はだいたいロードマップに現れるんです。
ロードマップの中では、「どんな状態を目指したい」みたいなものがあって「その状態って数字でいうとこうだよね」みたいなのが定義されていて、「そのために機能はこうあるべきだよね」という(ことを書く)ような作り方になっているはずです。
もしかしたらロードマップ上ではそれが表されていないかもしれないんですが、ロードマップを作っている人に聞くと、「どの状態か」みたいなものがたぶん出てくると思います。まず初めの一歩としては、目指す状態、「こんな状態を作りたい」「この指標を上げたい」というのに対して、「今作っている機能はエンジニア目線で作ったとしても同じような仕様書になるだろうか」「他にこんなやり方があるんじゃないか」みたいなところの提案をするのが、一番小さな参加の仕方かなと思います。
「目指す状態、直近の目指す状態に対してエンジニアとして何ができるだろう」みたいなところを、プロダクトチームとして議論に参加する。少しそれに慣れてきたら、ロードマップを作るような全体化にも入っていけるんじゃないかと思います。
最後です。(スライドを示して)先ほどは「『プロダクトチーム』として議論に参加する」と書いていましたが、(今度は)「『エンジニア』として議論に参加する」と書きました。
はじめに見たUX、Tech、ビジネスという、「プロダクトマネージャーはここだよ」というスライドですが、それぞれの円がどんどん離れていかないように、それぞれの円をどんどん重ねていくことが、プロダクトとして良い意思決定をするために大事だと思っています。
なので、プロダクトマネージャーだけが中心にいるんじゃなくて、TechとUXの重なりの部分はTechとUXの人でも進めちゃえばいいと思うんですよ。「『ここでこういうことがあるといいよね』というものをロードマップに入れましょう」とプロダクトマネージャーと議論するといいと思います。
ここはTechとビジネスで話せばいいと思います。具体的には、例えばダッシュボード1つ作るにしても、そのためにどういうデータ設計がいいかみたいなこと、ビジネスの人が何を求めているのかを、エンジニアから歩み寄って話していけるとすごく喜ばれると思います。
UXのところ、例えばCSみたいなところで、「Techの力を使うと、Techたちでこういうことができるようになるよ」みたいな話をどんどんしていって、エンジニアが離れていかない。近いところにいればいるほど、すごく効率が良いプロダクト開発ができるんじゃないかなと思っています。
長くなりましたが、私の発表は以上になるので、最後にまとめだけを話そうと思っています。
(スライドを示して)「プロダクトマネジメント」といった時に、この4つの階層でプロダクトを捉えてくださいねという話をしました。このWhatやHowは良さの定義が違うと「全部良い」となってしまって、それがコンタミ(コンタミネーション)すると良くないものが生まれてしまうので、ちゃんとFitというところをしっかり通して整合していきましょう。
先ほど「FitとRefineというのは関係する概念ですね」みたいなものをZoomのチャットでもらっていましたが、まさにそのとおりだと思っています。「このFitをより強くするためにRefineをする」みたいな考え方もしてもらえるとうれしいなと思っています。
そして、プロダクトというのはHowのところやWhatのところだけじゃなくて、Coreから含めて最終的にどんな世界観を作りたいのかというのをUIまでに反映させていく。仮説の連鎖をしっかりと見据えて考えてもらえるとうれしいなと思っています。
そのためにはプロダクトマネージャーという専門職の人だけがプロダクトマネジメントをするのではなくて、エンジニアの方、デザイナーの方、ビジネスの方、みんなでプロダクトマネジメントをするチームになってほしいと思います。
それを誰かが一歩を踏み出すのを待つという姿勢ではなくて、エンジニアの方からゴリゴリ、ガリガリと「こういうふうにプロダクトマネジメントをしていこう!」と言ってもらえると、私はPMとしてすごく幸せだなと思うし、過去の自分がモヤモヤとしていたところもそういう動きがもしできていたらもうちょっと楽しく開発できていたんじゃないかなと反省しています。
というところで、今日の私の発表は以上としたいと思います。私は@ozyozyoというアカウントでプロダクトマネジメント系の発信をしているので、もしよければフォローなどよろしくお願いします。今日は金曜日の夜に参加いただき、ありがとうございました。
2025.02.27
「頭のいい人」がやらない行動7選 職場でできる人に見られる、「心の知能指数」を高めるポイント
2025.02.25
仕事ができる人は「2分ルール」で動く 今すぐできる“シゴデキ”しぐさ10選
2025.02.25
チームの士気を下げる「難しいですね」が口癖の人 職場で評価される人の言い換え方
2025.02.26
フリーターから年収1億近く…『移動する人はうまくいく』著者の人生遍歴 そこそこ良い会社に就職するより経済的に成功する考え方
2025.02.21
日本の職場にありがちな「指示待ち部下が多い」問題 ドイツのマネージャーに学ぶ、自律型組織のヒント
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.27
成功する・しないの差は「時間」と「場所」の違いだけ 『移動する人はうまくいく』著者が語る、仕事も住む場所もどんどん変えるメリット
2025.02.20
部下からミスの報告が上がった時の反応の仕方 逆効果になる上司の対応と心がけたい3つのポイント
2025.02.26
トランプ政権で逆風になる可能性の高い業界 レオス藤野氏が語る、日本の株式市場への影響とビジネスチャンス
2025.02.20
残業せずに結果を出すドイツ人の働き方 日本の3倍休んで成果は1.5倍のタスク管理と会議術