2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
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.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.10
職場であえて「不機嫌」を出したほうがいいタイプ NOと言えない人のための人間関係をラクにするヒント
2024.12.12
会議で発言しやすくなる「心理的安全性」を高めるには ファシリテーションがうまい人の3つの条件
2024.12.06
嫌いな相手の行動が気になって仕方ない… 臨床心理士が教える、人間関係のストレスを軽くする知恵
PR | 2024.11.26
なぜ電話営業はなくならない?その要因は「属人化」 通話内容をデータ化するZoomのクラウドサービス活用術
2024.12.11
大企業への転職前に感じた、「なんか違うかも」の違和感の正体 「親が喜ぶ」「モテそう」ではない、自分の判断基準を持つカギ
PR | 2024.11.22
「闇雲なAI導入」から脱却せよ Zoom・パーソル・THE GUILD幹部が語る、従業員と顧客体験を高めるAI戦略の要諦