[レポート] A-3 プロジェクトを成功させる異能のコラボレーションの重要性 – プロダクトマネージャーカンファレンス2022 #pmconf2022

2022年11月02日(水)、プロダクトマネジメントに携わる人たちが共に学び、切磋琢磨するイベント『プロダクトマネージャーカンファレンス2022』がオンライン形式で開催されました。

当エントリでは、ブレイクアウトセッション『プロジェクトを成功させる異能のコラボレーションの重要性』の参加(視聴)レポートをお届けします。

目次

• セッション概要
• セッションレポート
• まとめ

　

セッション概要

セッション概要は以下の通りです。

• タイムテーブル丨プロダクトマネージャーカンファレンス 2022
  • A-3 プロジェクトを成功させる異能のコラボレーションの重要性丨SESSION 講演内容丨プロダクトマネージャーカンファレンス 2022

　

セッションレポート

企業紹介・自己紹介

• 企業紹介：株式会社Sun Asterisk
  • スタートアップから大企業まで様々なフェーズの企業と400以上のプロダクトや事業共創を支援
  • 成功するプロダクトの共通点を、エンジニア／デザイナー／ビジネスサイドの三視点からご紹介
  • ビジョン：誰もが価値創造に夢中になれる世界
  • ミッション：本気で課題に挑む人たちと事業を通して社会にポジティブなアップデートを仕掛けていくこと
  • 提唱するDXの2つの要素
    • デジタイゼーション(業務プロセスのデジタル化)
    • デジタライゼーション(事業のデジタル化)
  • 強み：デジタルクリエイティブスタジオの機能
    • 多様なバックグラウンドを持つプロフェショナルが多数在籍
    • 豊富な実績から蓄積された事業創造に必要な手法・ノウハウ
• 自己紹介
  • 金子穂積氏：Creative & Engineering / CTOs
  • 井上一鷹氏：Busines Promotion Office / Designer
  • 南慶隆氏：Busines Promotion Office / Unit Manager
    • 書籍を出しました：異能の掛け算　新規事業のサイエンス | 井上一鷹, Sun Asterisk |本 | 通販 | Amazon

BTCとは

• 3つの視点と2つの問い
  • 3つの視点：これらの先に新しいビジネスがある
    • B(Business)：どのように継続するのか
    • T(Technology)：どのように実現するのか
    • C(Creative)：どのように価値を提供するのか
  • 2つの問い
    • どう解像度を上げるか？(Sun*ならどこからでも入れる)
    • どう未来を引き寄せるか？(最短距離を走れるから短く出来る)
• 新規事業の成立条件 / 9年で400件超の新規事業を考えるだけでなく作るところをやっているので研究が出来、ノウハウがある。
  • 右脳的な確信「確かにそれは欲しがられるに違いない」
    • (1).課題の共感 → 顧客価値(コンセプト)の構築[主題＝顧客]
    • (2).価値の渇望 → 顧客価値(コンセプト)の構築[主題＝顧客]
  • 左脳的な確証「しかも事業として魅力があり、勝てそう。収益性も見込める」
    • (3).市場性 → 顧客価値(コンセプト)の構築[主題＝顧客]
    • (4).競争優位性 → 競争戦略の構築[主題＝事業]
    • (5).収益性 → 収益モデルの構築[主題＝事業]
  • VALUE DESIGGN SYNTAX
    • リーンキャンバスが近い。進化させたもの
    • ストーリーで語ることが大切。人を巻き込む力が必要。ストーリー自体が人を焚きつけるものでなければならない。
    • 的確に「どこが足りないか」を見極め、対応するメンバーを当てていく。
• 0→10を創るBTCチーム

プロダクトマネージャーの役割とは？

• ビジネス／UX／テクノロジーの3つの交差領域であるとも言われ、これらの領域に基づいてプロダクトの舵取りをしていくことがプロダクト成功への近道となる
  • プロダクトマネジメントのすべて 事業戦略・IT開発・UXデザイン・マーケティングからチーム・組織運営まで | 及川 卓也, 曽根原 春樹, 小城 久美子 |本 | 通販 | Amazon
• プロダクトマネージャ(PM)とプロダクトマネージャ(PdM)との違い
  • プロジェクトマネージャ(PM)
    • [ゴール] プロジェクトの成功
    • [役割] プロジェクトの計画、進行管理、実行
    • [特徴] プロジェクトを「いつまでに作るか(when)」「どうやって作るか(how)」を考え、チームを束ねる
  • プロダクトマネージャー(PdM)
    • [ゴール] プロジェクトの成長
    • [役割] サービスの開発からセールスの戦略立案、実行、意思決定
    • [特徴] プロダクトの「何を作るか(what)」「なぜ作るのか(why)」から考えていく
• PM/PdMとBTCの違いとは？
  • PM/PdMは個人
  • BTCはチーム

トークディスカッション

Q.なぜ中央集権では難しい？誰も中心的な人がいなくても大丈夫？

• 中心的なメンバーは必要。トータルでPdMを責任者として置くのは大変
• 難しさでいくと格段に難易度は上がっている。プロダクトを見なければいけない領域は格段に広がっている
• プロダクトを群として見た時に、マネージャーが視野を広げて見ていくのは理想的ではあるがかなりしんどい
  • PdMの人はそこに対してスーパーマン的な対応をしていかなければ？というふうに捉える人も多い
• よくある話
  • このRFPで見積もってください → 見積に必要な情報が全く足りない
  • MVPは終わっているので要件定義からお願いします → MVPで何を検証したのか不明
  • 要件定義は終わっているので詳細設計から開発お願いします → 要件定義になっていない
• Sun*が提唱する価値創造型の手法・プロセス
  • デザイン・シンキング(Ideate)
  • リーンスタートアップ(Prototype)
  • アジャイル(DevOps)
• マネージャを補佐しつつ、変化していくプロダクトに対応していくために、専門職チームが権限移譲された状態でプロダクトを成長させていく、という部分を念頭に置いた体制作りがポイントとなるのでは
• 道のりは長い。これらをPdMが全て見ていくというのは大変　
• フェーズごとに「(B/T/Cの)どの脳みそが活躍していくのか」。これは変容していくもの
  • ここに1人のオーナーを置くことの怖さは感じる。事業会社の中で新規事業をやっていた身としては0-1,1-10ではなく「10-100」の世界が基本にある。PdMをおいて「誰が意思決定をするか」を固定してしまったが故に"思考が止まる"という感覚を持ったことが結構あった。
  • 0-1,1-10の際に「ヒエラルキー構造」を想起するようなチームビルディングをしないほうがいいのでは。
  • これはメリット・デメリットある
  • 置くにしてもテンポラリとすべき
• 元も子もない話になるが、PMを取りまとめている立場からすると、究極の役割としては「最終的には自分の役割が要らなくなること」だと思っている。プロフェッショナルなメンバー達が有機的に動いてくれてれば、PM的な人間も要らなくなる。
• B(Business)が一番重要だと思えるタイミングはどこ？
  • サービスの性質によっても変わるし、あるべきとは離れたところを言ってしまう形にはなるが、企業の中で意思決定をするときに、意思決定を行う際に何がメリット・デメリットであるかを整理して議論をしていくとか、事業を作るときに大事なステークホルダーと「何をギブアンドテイクするのか」という話をするときにB(Business)の部分が出張っていかなければならないのかな、とは思う。目に見えて「Businessがやらなければならないこと」がある。
• ソフトバンク様の事例(DX推進、新規事業開発支援)についてはBusinessの視点もそうだし、クリエイティブな視点でも重要な部分があった。そこのお話を伺いたい。
  • 明確にクライアント側の方で「新規事業立ち上げ」という局面を迎えたときにBusiness中心のチームでまず立ち上げた。
  • 実際の具体的なサービスを作っていかないといけない、となったときに前進しないフェーズに差し掛かってしまった。
  • 視点としてクリエイティブ目線、ユーザーを中心に据えて価値を出すにはどうすれば良いか、を考えた。
  • 「足りてないね」という診断のもとクリエイティブ脳の面でサポートを行った。
  • ビジュアライズ、視覚化を行っていくことによって「このビジネス行けるよね」という感覚的な部分で確信を持ってもらえた。そういう意味では「効能」はあったのかなと思っている。

Q.フェーズごとにどんなプロジェクトマネジメントをするのか？フェーズの切り方も難しいと思うのですが...

• Sun*の場合、前述したような大まかなフェーズ(の切り方)はあると思うが、「フェーズの切り方」はBusinessの段階ではどういう風に意識しているか？
  • Businessだけでは決められない。
  • BTCそれぞれのメンバーが集まって「このタイミングは集まって意思決定をしなければならないのか」「このタイミングは離れて各職能で走っていれば良いのか」という共通見解を予め作っておくのが良い。
  • 一般論で言えば「お客様の価値」のレイヤーは絶対に全員で握っておくべき。これの仮説がどう検証されたか、検証結果を振り返る。価値レイヤーの部分は皆がIssueを認識した上で次のマイルストーンを決める。これを繰り返すのがほぼ全てだなと。
  • ビジネスの場合、ドメインセレクション的な「どこの分野・戦場で戦うのか」というのを先に決めなければならない。一ヶ月で一旦これを決めよう。次またこの件で集まろうよ、というのをやる。
  • Sun*はその辺り試行錯誤して研磨していく、という機能を持った会社だと思っている。そのためには全員が認識するための「世界地図」を持って話さないといけないよね、というのはある。
  • 色々なメガネ・目線をいれなければならないと思っている。B/T/Cが「(ここは自分達の担当だからそれ以外の)他は出ないよ」みたいなことは無い。リンゴを見るときに可視光線で見るのか、赤外線で見るのか、サーモグラフィで見るとかそういう感じ。なるべくレンズやフィルターを持っておくのがポジティブだし、どこのボリュームが多いとか少ないとかの不満も出ないような気がする
  • そういう部分こそまさに「チーム」なのかな、という気はする。結局PdM一人だけが頑張ると辛いと思うので、PdMが居たとしてもチームが機能しないと、チームが動かないといけないのかなとは思っている
    • 日産カーレンタルソリューション様の事例：顧客のプロダクトオーナー様のサポートから始めた。最終的にはみんながチームとして全てが上手く動かないと辛いのかなと思う。チーム全体として見た場合に、PdMの求められる部分・アクションはフェーズや局面によっても色々変わってくるものだと思う。
  • 実際にサービスがリリースされた後、チームが有機的に動いている事でPdMをそこにアサインし上手くいく、というのは多く見ている。大事なのはその前。ローンチ前までは本当に色々なことを皆で考えないといけないのでチームとして取り組むのは重要だと思う。

Q.途中からプロジェクトに参加する場合、まず何から確認するか？分からないことだらけの時は何をすれば良いか？

• 逆に、Techの人から見たポイントはどうか。こういうところを詰めておくべき、とか。
  • 実現可能性や本当の工数を意識していない「夢物語」なものを作り上げるようなものがあった際、「いやいやそれは出来ないですよ」と言いながら棚卸しさせてもらう事がある
  • BusinessとかCreativeのところに踏み込みながら巻き戻させてもらう、みたいなことはよくある。
  • 上記のようなことにならないために、最初の段階、デザインシンキングの段階から一緒に話させてもらいつつ「技術的な観点からだとこうすれば早く立ち上げられますよ」というのをアイデアとして出すことがある
• BTCが三角形のレーダーチャートだとしたときに、フェーズを切りすぎて最初Businessを伸ばして次にTech、次にCreative...みたいな感じでやろうとするとまじで大体ぐちゃってなる。3つの割合はリアルタイムにやらないとお互いにとって最大の面積は得られない。
  • この部分の差分を埋めるコストもゼロではない、というのが理解されていない。

Q.チームの組み方はどのようにやるのか？必要なメンバーが分からないことも多い...

• このプロダクトはどういう性質のものがあるのか分からない、というのがまずはあると思う
• 明確に、最初のプロジェクトオーナー的な人がB/T/Cの人なのか、というのがあると分かりやすいのかもしれない
• 結局のところ、そのプロジェクトがBTCのどの起点なのか、というのはスペシャリストにしか分からない部分。
• 最初の段階でBTCそれぞれのプロフェッショナルが集まってディスカッション出来ると良い。
• 現状のプロダクトやサービスの起点としてn1(一人の顧客)に対しての具体的な価値が証明されている、その価値を「皆が欲しい価値」にどう昇華させるか。
  • 生の声、課題感があるという確信は得ているんだけれども、それがどれくらいサービスとしてスケールするものなのか、投資対効果としてどれくらい回収出来るものなのか、算段が全く付けられないという状況になったときに他のプロフェッショナルの頭脳を借りることがある。
• 全体の比率を考えると、やはりBusiness起点のものが多い？
  • 元々はBusiness起点が多いとは思う。
  • これは本当に良くないことだと思うのだが、基本的に事業会社はBusiness起点の人が偉くなっていくことが多い。
  • 左脳的な理屈で意思決定をする人たちが事業として起案されている。左脳がしっかり埋まっているんだけれども右脳の方、直感ベースで考える方が弱い。BusinessとCreativeってモノを見る時の解像度が違う。ミクロをしっかり見る人と、マクロを見て「これは投資に耐えうるのか」という視点ばかりに目が行く人、自分達の中にBusinessもCreativeも居るんだけど、特化した人に任せていくとお互いにミクロとマクロを任し切ることが出来る。自分が守っているところに深く深く入っていける。これが補完的でいることの意味なのかなと。
• MVPについて：「MVPってなんだろう？」という会話を良くする。MVP開発の定義について聞きたい。
  • MVPを作る時って一番最小の価値を決める、選択と集中の中でも「1個目は何？」を決めるところ。
  • Businessの視点で言うとこれ、Creativeの視点で言うとこれ、Techの観点で言うとこれ、っていうのをちゃんと綱引きしないといけないよね、というところ
  • 何を以ってそれを議論していくのか、お互いが変な忖度をせずに収束させるためにはどうすれば良いのか、そういう部分を考える会話。
  • この部分は深遠だなと思う。まだ100%の答えは出ていない。

まとめ

• フェーズごとのメンバー(構成の)見極めをするのに、全ての(BTCの)観点で能力の組み合わせを把握していないと分からない。
• 社内では「スーパーマンにならなくてもいい」とは言っている
  • 「なりたい」人はトライするのは重要
  • なる過程で色々な人と出会う必要があるので、チームで上手く回すようなところをまずは目指す
  • そういうチームに巡り合うことが重要なのでは。
• スーパーマンじゃないとPdMになれないのでは、というよりも、プロダクトチームで最大限サポートできる仕組みがある方が絶対に確度が上がるし、チャレンジ出来る回数も上がる。
• スーパーマンになれたとしても、次世代のマネジメントのスタイルは「任せる人が上手な人のほうが、何かに特化して新しいものを生み出せる」というのが確かな気がしている
  • 任せるためにはお互いを知らなければならない。出来るところを出来ないところを知るべき
• 最終亭にアジャイルのところまで行くと進行に問題は無いのかなとも思うが、プロジェクトの最初のスタート地点というのはPdMの仕事量が多すぎて本当にスーパーマンでないと出来ない。そこから進んでいく過程で徐々にスーパーマン(的活動を求められる)要素が減ってくる感じ。
• 0-1の最初のところであればチームをなるべく集めて進めていった方が、PdMよりPMに徹した方が楽になるのでは。

　

まとめ

という訳で、プロダクトマネージャーカンファレンス2022のセッション『プロジェクトを成功させる異能のコラボレーションの重要性』の視聴レポートでした。

• プロダクトマネージャーカンファレンス 2022 の記事一覧 | DevelopersIO