
2025.02.12
職員一人あたり52時間の残業削減に成功 kintone導入がもたらした富士吉田市の自治体DX“変革”ハウツー
リンクをコピー
記事をブックマーク
小城久美子氏:では後半の「プロダクトマネジメントをエンジニアが推進する」というところで、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.06
すかいらーく創業者が、社長を辞めて75歳で再起業したわけ “あえて長居させるコーヒー店”の経営に込めるこだわり
PR | 2025.02.07
プロジェクトマネージャーは「無理ゲーを攻略するプレイヤー」 仕事を任せられない管理職のためのマネジメントの秘訣
2025.02.06
落合陽一氏や松尾豊氏の研究は社会に届いているか? ひろゆき氏が語るアカデミアの課題と展望
2025.02.05
「納得しないと動けない部下」を変える3つのステップとは マネージャーの悩みを解消する会話のテクニック
2025.01.07
1月から始めたい「日記」を書く習慣 ビジネスパーソンにおすすめな3つの理由
2025.02.10
A4用紙を持ち歩いて殴り書きでアウトプット コクヨのワークスタイルコンサルタントが語る、2種類のメモ術
2025.02.05
エンジニアとして成功するための秘訣とは? ひろゆき氏が語る、自由な働き方を叶えるアプリ開発とキャリア戦略
2025.02.04
日本企業にありがちな「生産性の低さ」の原因 メーカーの「ちょっとした改善」で勝負が決まる仕組みの落とし穴
2025.02.03
「昔は富豪的プログラミングなんてできなかった」 21歳で「2ちゃんねる」を生んだひろゆき氏が語る開発の裏側
PR | 2025.02.04
能登半島地震で自宅は全壊、「これでどうやってDXするねん」 被災したサイボウズ社員と支援者らが語る災害支援のノウハウ
新人の報連相スキルはマネージメントで引きあげろ!~管理職の「他責思考」を排除~
2025.01.29 - 2025.01.29
【手放すTALK LIVE#45】人と組織のポテンシャルが継承されるソース原理 ~人と組織のポテンシャルが花開く「ソース原理」とは~
2024.12.09 - 2024.12.09
『これで採用はうまくいく』著者が語る、今こそ採用担当に届けたい「口説く」力のすべて
2024.11.29 - 2024.11.29
【著者来館】『成果を上げるプレイングマネジャーは「これ」をやらない』出版記念イベント!
2025.01.10 - 2025.01.10
片付けパパ対談【特別編】 整理術×行動術×メモ術で、仕事も人生も自在にデザイン!
2024.12.16 - 2024.12.16