2024.10.01
自社の社内情報を未来の“ゴミ”にしないための備え 「情報量が多すぎる」時代がもたらす課題とは?
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.10.29
5〜10万円の低単価案件の受注をやめたら労働生産性が劇的に向上 相見積もり案件には提案書を出さないことで見えた“意外な効果”
2024.10.24
パワポ資料の「手戻り」が多すぎる問題の解消法 資料作成のプロが語る、修正の無限ループから抜け出す4つのコツ
2024.10.28
スキル重視の採用を続けた結果、早期離職が増え社員が1人に… 下半期の退職者ゼロを達成した「関係の質」向上の取り組み
2024.10.22
気づかぬうちに評価を下げる「ダメな口癖」3選 デキる人はやっている、上司の指摘に対する上手な返し方
2024.10.24
リスクを取らない人が多い日本は、むしろ稼ぐチャンス? 日本のGDP4位転落の今、個人に必要なマインドとは
2024.10.23
「初任給40万円時代」が、比較的早いうちにやってくる? これから淘汰される会社・生き残る会社の分かれ目
2024.10.23
「どうしてもあなたから買いたい」と言われる営業になるには 『無敗営業』著者が教える、納得感を高める商談の進め方
2024.10.28
“力を抜くこと”がリーダーにとって重要な理由 「人間の達人」タモリさんから学んだ自然体の大切さ
2024.10.29
「テスラの何がすごいのか」がわからない学生たち 起業率2年連続日本一の大学で「Appleのフレームワーク」を教えるわけ
2024.10.30
職場にいる「困った部下」への対処法 上司・部下間で生まれる“常識のズレ”を解消するには