2024.10.21
お互い疑心暗鬼になりがちな、経営企画と事業部の壁 組織に「分断」が生まれる要因と打開策
Product Managerはチーム作りに取り組むべき(全1記事)
リンクをコピー
記事をブックマーク
篠原徳隆氏:よろしくお願いします。では始めさせていただきたいと思います。ヴァル研究所の篠原と申します。
開発、営業、企画をやってきて、新規事業部を任されています。0→1が主戦場で、(2018年)7月から異動になり、Mobility-as-a-Serviceと言われている「MaaS」を担当することになりました。もしこのあたりに興味があれば、あとで声をかけていただければと思います。
直前まで僕が手掛けていたプロダクトに、「RODEM」というサービスがあります。完全な新規事業です。僕らはナビゲーションの会社で、簡単に言うとGoogleカレンダーやOutlookといったカレンダーに、訪問先の企業名を入れるだけで、そこまでの移動経路を勝手に作る、というサービスを作っていました。
本日のテーマ「Product Managerはチーム作りに取り組むべき」ですが、みなさんのチームは、イケていますか? みなさんのチームは、自慢したくなるチームですかね。みなさんのチーム、最高ですか?
もしこのように言えるんだったら、今日の僕の話って、もう聞かなくてもいい感じです(笑)。今日はこのあと、「なぜチーム作りが必要なのか」についてお話ししたいんです。
ちょうど1年前に、POStudyで「Product ManagerとProduct Ownerの役割の違い」についてお話しさせていただきました。プロダクトマネージャーは、セールス、ビジネス、エンジニアリングといったさまざまな要素があって、やることが多すぎるというお話です。
プロダクトマネージャーがすべてを見るのは無理があります。実行するのはなおさら無理です。だからPMとPOで見るところを分けていきましょう、というお話をしたんです。いま僕はプロダクトマネージャーの役割として「チーム」にフォーカスすべきではないかと、強く考えています。
プロダクトは、ゴールが決まっているものならともかく、成長過程で不確実なものがけっこう多いんですね。決まったものを決まったとおりに作るのであれば、プロジェクトマネジメントの観点でわりといけるんですが、プロダクトはそうはいかない。そういう不確実なものをプロダクトマネージャーが全部コントロールするのは、そもそも無理があるかなと。
仮に、プロダクトマネージャーがそこに追随しようとしても、いろんなものをインプットをしながら変化に対応していくのは、かなり難易度が高いと思っています。
新規事業サービスのコンテキストでお話しすると、「チームの文化作り」を並走していかなければならないかなと思っています。プロダクトの初期戦略は、圧倒的な質、尖った価値とか魅力的品質を磨くところにあるんですが、そういう過程の中で「誰のせい」とか「これ良くなかったじゃないか」とか、他人ごとのような扱いをしていると、プロダクトの成長はそもそもうまくいかないんですね。
そもそもミッションを達成するのって個人でしたっけ? プロダクトマネージャーがやるものでしたっけ? そういうわけでもないですよね。僕はチームでしか大きな結果を達成できないと思っているんです。
しかも、個人の能力=チームの能力ではないと思います。5人集まったら5人分の力が発揮できるというのは、僕は相当良いチームだと思っています。
なので、不確実性に対して、各自が持つ知識と経験といったスキルを集合知として向き合って進んでいかなければならないのではないかと考えています。その様なメンバーが集まったチームは、多様性があると思うんですね。
そういうもの(チーム)がいろいろなアイデアなどを出してくれるチームになっていくんじゃないか、そういう過程の中で自発的に動くように変わっていくのではないかと思っています。そういう組織にならないと、色々なものに対処はできないのではないかと考えています。
ただし、人はユニークな存在なので、合う・合わないが必ずあります(笑)。なので、人を集めるのも迎え入れるのも、非常に大変だというのを実感しています。
しかも能力の高い人が入ったからといって、必ずチームがうまくいくかというと、そうでもありません。それは、その人が悪いとか、僕らが悪いという問題でもないんですね。合う・合わないは当然ある話なので。いろいろな理由の中から、チームに迎え入れるというのはなかなか簡単にいかないと感じています。
そこで「プロダクトマネージャーはなにをするべきか?」というと、「チームを価値観と文化で動かす」というところに集約されます。ただ、言うは易く行うは難しで、まさに「なにを言っているかわかんない」という話になりがちです。
価値観と文化は、言葉に表すのが難しいと思うんですね。「あなたのチームの文化はなんですか?」と言われても、答えにくいと思うんです。こういうものは、積み重ねていくしかないです。積み重ねた結果として表れているものが、こういうもの(文化)なんだろうと僕は思っています。
実際に、僕がどんなことをしたかというのを、1つお話ししたいと思います。本当はもっと話すつもりだったんですが、時間を計ったらけっこうかかってしまったので、1つだけお話ししたいと思います。
知っている方はいっぱいいらっしゃると思うんですが、GoogleのRe:workの中でチームが成果を残すために必要な5つの要素として、「心理的安全性」「信頼性」「構造と明瞭さ」「仕事の意味」「仕事のインパクト」というのがあります。
その中で今回は、この「構造と明瞭さ」と「仕事の意味」にフォーカスして、どんなことをしたかというお話をします。
基本は「情報共有」と「共通理解」だと思っているので、「なんでこれをするんだっけ?」「どんな背景からどんなジャッジをやったっけ?」ということを、みんなで把握しておいてもらう。伝わるまでやるというのはもちろん大事なんですが、一緒にやることでそのへんの時間をどんどん省略していきたいと思ったんですね。
なにをやったかというと、「Fact集め・Fact駆動」をやりました。(スライドを指して)これ、実際のカンバンなんですが、ちょっとこのボードの説明をすると、左側のレーンはファクトで、黄色い付箋がユーザーからの問い合わせ内容とか、お客様のところで言われた内容とか、サポートして気付いたこととかです。ログやデータから見たことや、実際に操作しているユーザーの観察結果などを書いています。
ちょっと写真が見づらいんですが、桃色が不具合です。1枚白く隠してあるところは実は青色なんですが、完全なビジネス要求です。実際は僕が出すことが多いんですが、アライアンスや案件といったものです。緑色にはメンバーがしたいことを書いています。
朝会とか夕会とか、KPT(ケプト)のタイミングでファクトも挙げてこれを書いておきます。この中でわかったファクトを、PM・POで検討して、隣りのレーンで上から順に「なにやろうか」「なにが効果的か」「なにがビジネス価値あるか」という話をして決めていきます。
次に、そこに挙がったものを、PM・POが「Idea」と「How」で、「どうやればいいんだろうね」「どういう期待値なんだろうね」と考えます。そのときに、関係するいろんなメンバーに相談して、いろいろなアイデアをブラッシュアップしていきます。
その上で、じゃあ「これをやる」と決めたら「なにをすれば良いか」というところまで考えるんですが、少し大きなものであればMVPキャンパスというものがあるので、そこに書いてそれをレビューをすると。機能改善とかであれば、プロダクトバックログアイテムレベルにして、付箋に落として書いておく。これを開発チームなり当該チームにレビューをして、リファインメントをしていくということをやっています。
リファインメントで手戻りがあれば当然戻して再検討しますし、うまくいけばPBIに積んでいくし、必要があればユーザーインタビューとかプロトタイプで検証する、というかたちでサイクルにはめています。
「ファクトを全員で共有することで、『I』ではなく『We』で語れるようにしたい」ということから、こういう取り組みをしてまいりました。
一応チームの考え方として、私の理想があります。チームの数だけさまざまな特長があるので、同じチームはないと思っています。
ちょっとネタに走るんですが(笑)、『銀英伝(銀河英雄伝説)』で例えると、様々な提督たちがいて、いろんなカラーがあると思うんですね。その提督のカラーは艦隊のカラーにもなっていると思います。各チームがフィーチャーやフィードバックを、チームのカラー(特長)に合うものを率先して対応していったり、同じもの(フィーチャー)を複数のチームで共有し、その能力に合ったチームで対応していったり。個人ではなくチームで対応していくというのが理想かなと思っています。
場合によっては「フィーチャーで大きな案件がある、これ絶対取りたい」と思ったらそこにシフトさせて、対応チームも変えながらやっていくというのが、会社として、組織としての強さにつながっていくのではないかと思っています。
だからこそ、チームを育てていくというのは組織の財産になるということをお話ししたいし、僕もそうしていきたいと思っています。
最後に、プロダクトマネージャーはよく「ビジョンを示しなさい」とか「ロードマップを示しなさい」と言われるんですが、チームを動かす触媒でなければいけないと思います。
別にスクラムマスターみたいになれという話をしているわけではなく、組織全体を動かすような触媒にならなければいけないのではないかなと考えています。
チームを大事にして、簡単に壊してはいけません。壊すのは一瞬でできます。まさに先週、僕が異動させられたみたいに、自分だけ蚊帳の外に置かれるなんてことはよくあるパターンなんですが(笑)。逆にPMがどこかへ散ってしまっても、チームが残っていれば組織として財産になると思いますし、プロダクトにとっても非常に有効なことだと思っています。
プロダクトもチームも育てましょう、みんなが仕事を楽しめるように。ご清聴ありがとうございました。
(会場拍手)
2024.11.13
週3日働いて年収2,000万稼ぐ元印刷屋のおじさん 好きなことだけして楽に稼ぐ3つのパターン
2024.11.21
40代〜50代の管理職が「部下を承認する」のに苦戦するわけ 職場での「傷つき」をこじらせた世代に必要なこと
2024.11.20
成果が目立つ「攻めのタイプ」ばかり採用しがちな職場 「優秀な人材」を求める人がスルーしているもの
2024.11.20
「元エースの管理職」が若手営業を育てる時に陥りがちな罠 順調なチーム・苦戦するチームの違いから見る、育成のポイント
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.11.19
がんばっているのに伸び悩む営業・成果を出す営業の違い 『無敗営業』著者が教える、つい陥りがちな「思い込み」の罠
2024.11.18
20名の会社でGoogleの採用を真似するのはもったいない 人手不足の時代における「脱能力主義」のヒント
2024.11.11
自分の「本質的な才能」が見つかる一番簡単な質問 他者から「すごい」と思われても意外と気づかないのが才能
2024.11.13
“退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方
2024.11.11
「退職代行」を使われた管理職の本音と葛藤 メディアで話題、利用者が右肩上がり…企業が置かれている現状とは