CLOSE

Product Managerはチーム作りに取り組むべき(全1記事)

組織の財産となるのは、価値観と文化が浸透したチーム プロダクトマネージャーは組織を動かす触媒となれ 

2018年7月7日、株式会社フリークアウト にて「プロダクトオーナー祭り 2018 Summer ~プロダクトマネジメントが世界をツナぐ~」が開催されました。IT関連企業に所属するソフトウェア開発のプロダクトマネージャーやプロダクトオーナーを中心に、それぞれが携わるプロダクトの価値や、マネージャーとしての体験談など、幅広い観点からライトニングトークが繰り広げられました。本記事では、株式会社ヴァル研究所 事業統括本部 プロデューサーの篠原徳隆氏によるLT「Product Managerはチーム作りに取り組むべき」の模様をお送りします。

みなさんのチームは「最高」ですか?

篠原徳隆氏:よろしくお願いします。では始めさせていただきたいと思います。ヴァル研究所の篠原と申します。

開発、営業、企画をやってきて、新規事業部を任されています。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駆動」

基本は「情報共有」と「共通理解」だと思っているので、「なんでこれをするんだっけ?」「どんな背景からどんなジャッジをやったっけ?」ということを、みんなで把握しておいてもらう。伝わるまでやるというのはもちろん大事なんですが、一緒にやることでそのへんの時間をどんどん省略していきたいと思ったんですね。

なにをやったかというと、「Fact集め・Fact駆動」をやりました。(スライドを指して)これ、実際のカンバンなんですが、ちょっとこのボードの説明をすると、左側のレーンはファクトで、黄色い付箋がユーザーからの問い合わせ内容とか、お客様のところで言われた内容とか、サポートして気付いたこととかです。ログやデータから見たことや、実際に操作しているユーザーの観察結果などを書いています。

ちょっと写真が見づらいんですが、桃色が不具合です。1枚白く隠してあるところは実は青色なんですが、完全なビジネス要求です。実際は僕が出すことが多いんですが、アライアンスや案件といったものです。緑色にはメンバーがしたいことを書いています。

朝会とか夕会とか、KPT(ケプト)のタイミングでファクトも挙げてこれを書いておきます。この中でわかったファクトを、PM・POで検討して、隣りのレーンで上から順に「なにやろうか」「なにが効果的か」「なにがビジネス価値あるか」という話をして決めていきます。

「I」ではなく「We」で語れるようにしたい

次に、そこに挙がったものを、PM・POが「Idea」と「How」で、「どうやればいいんだろうね」「どういう期待値なんだろうね」と考えます。そのときに、関係するいろんなメンバーに相談して、いろいろなアイデアをブラッシュアップしていきます。

その上で、じゃあ「これをやる」と決めたら「なにをすれば良いか」というところまで考えるんですが、少し大きなものであればMVPキャンパスというものがあるので、そこに書いてそれをレビューをすると。機能改善とかであれば、プロダクトバックログアイテムレベルにして、付箋に落として書いておく。これを開発チームなり当該チームにレビューをして、リファインメントをしていくということをやっています。

リファインメントで手戻りがあれば当然戻して再検討しますし、うまくいけばPBIに積んでいくし、必要があればユーザーインタビューとかプロトタイプで検証する、というかたちでサイクルにはめています。

「ファクトを全員で共有することで、『I』ではなく『We』で語れるようにしたい」ということから、こういう取り組みをしてまいりました。

育ったチームが組織の財産となる

一応チームの考え方として、私の理想があります。チームの数だけさまざまな特長があるので、同じチームはないと思っています。

ちょっとネタに走るんですが(笑)、『銀英伝(銀河英雄伝説)』で例えると、様々な提督たちがいて、いろんなカラーがあると思うんですね。その提督のカラーは艦隊のカラーにもなっていると思います。各チームがフィーチャーやフィードバックを、チームのカラー(特長)に合うものを率先して対応していったり、同じもの(フィーチャー)を複数のチームで共有し、その能力に合ったチームで対応していったり。個人ではなくチームで対応していくというのが理想かなと思っています。

場合によっては「フィーチャーで大きな案件がある、これ絶対取りたい」と思ったらそこにシフトさせて、対応チームも変えながらやっていくというのが、会社として、組織としての強さにつながっていくのではないかと思っています。

だからこそ、チームを育てていくというのは組織の財産になるということをお話ししたいし、僕もそうしていきたいと思っています。

プロダクトマネージャーは、チームを動かす触媒となれ

最後に、プロダクトマネージャーはよく「ビジョンを示しなさい」とか「ロードマップを示しなさい」と言われるんですが、チームを動かす触媒でなければいけないと思います。

別にスクラムマスターみたいになれという話をしているわけではなく、組織全体を動かすような触媒にならなければいけないのではないかなと考えています。

チームを大事にして、簡単に壊してはいけません。壊すのは一瞬でできます。まさに先週、僕が異動させられたみたいに、自分だけ蚊帳の外に置かれるなんてことはよくあるパターンなんですが(笑)。逆にPMがどこかへ散ってしまっても、チームが残っていれば組織として財産になると思いますし、プロダクトにとっても非常に有効なことだと思っています。

プロダクトもチームも育てましょう、みんなが仕事を楽しめるように。ご清聴ありがとうございました。

(会場拍手)

続きを読むには会員登録
(無料)が必要です。

会員登録していただくと、すべての記事が制限なく閲覧でき、
著者フォローや記事の保存機能など、便利な機能がご利用いただけます。

無料会員登録

会員の方はこちら

関連タグ:

この記事のスピーカー

同じログの記事

コミュニティ情報

Brand Topics

Brand Topics

  • “退職者が出た時の会社の対応”を従業員は見ている 離職防止策の前に見つめ直したい、部下との向き合い方

人気の記事

新着イベント

ログミーBusinessに
記事掲載しませんか?

イベント・インタビュー・対談 etc.

“編集しない編集”で、
スピーカーの「意図をそのまま」お届け!