全社課題の解決のために新規プロダクトを0→1で立ち上げたプロダクトマネージャー

今回は、BizteX株式会社のプロダクトマネージャーである大坪さん（@kazuhito_otsubo）にお話を伺いました。

大坪さんは、デザインや営業、エンジニア、PjM、CSと様々なロールを経験された後にプロダクトマネージャーになられ、全社課題の解決のために新規プロダクトを企画し0→1での立ち上げを経験されました。

働く上でのマイルール「Whyを深掘る / とりあえずやってみる / ドキュメンテーションを大事にする」や、プロダクトは人がつくるものであるから作り手のモチベーションが重要であること、PdMが必ず行う「考える」ことに気付きを与えるオススメの本など、これからPdMを目指す方・かけだしPdMの方の参考になるかと思いますので、ぜひ読んでみてください！

この記事は100人100色のプロダクトマネージャーのリアルを知るためのインタビュー記事「PdM Voice」の連載第16回目の記事です。

BizteXでRPAとiPaaSのプロダクトマネージャー

Q. まずはご自身の仕事について教えてください。

BizteX株式会社で、2つの業務自動化に関連したプロダクトのプロダクトマネージャーをしています。

1つ目は、BizteX cobitというRPA（ソフトウェアのロボットに操作を覚えさせてロボットに操作を代行させる）をクラウドで提供しているプロダクトです。

2つ目は、BizteX Connectという各種SaaSやシステムのAPIをGUIの操作で連携させて、業務やデータの自動連携をできるようにしているiPaaSのプロダクトです。

ミッションは「プロダクトの成功」= PMF → 世界観の実現

Q. 今の会社でのPdMのミッションを教えてください。

「プロダクトの成功」です。

プロダクトの成功とは、
中長期的には、BizteXのプロダクトが、業務自動化のプラットフォームとして、各社に入っている世界観を実現することです。

目の前では、BizteX ConnectをPMFさせることです。

今は、BizteX cobitを使っていただいているユーザーさんに対しての提案や導入においてはPMFしている状態と言えますが、それ以外の新しい領域をどんどん見つけていってPMFさせる必要があると思っています。

RPAやiPaaSは汎用的であるものの、特定の領域やカテゴリでそれを使って何ができるのか、ユーザーにどんなメリットがあるのか、業界や業種ごとに勝ちパターンやキーになるメッセージや数字などを見つけていって、機能として付加していく必要があると考えています。

その上で、どんどん新しい業界・業種・カテゴリを開拓していかないといけないので、次にどこの領域を狙っていくのかということを仮説・検証・実験・学習のサイクルを回す必要があり、開発組織だけではなく、マーケ・営業・CSを巻き込んでやっていくことが重要になります。

様々なロールの経験を活かしながら、業務領域を拡大中

Q. プロダクトマネジメントトライアングルを元に、具体的な業務範囲を教えてください。

一番重きを置いているのは、開発者と顧客を繋ぐ領域です。

エンジニアリングとデザイン、カスタマーサクセスを経験していて知見があるので、得意であり、実際やっているところです。
デザインを考えることや、ものによってはワイヤーも引きますし、ペーパープロトを作ってユーザーにヒアリングしたり、サポート対応をやっていたりします。

また、開発者とビジネスを繋ぐ領域もかなりやっています。

仕様策定に始まり、開発しているものを営業やCSがどういう風に使えるのかを伝えたり、逆に営業やCSに入っているユーザーの声を開発側へ展開できるような取り組みを行っています。
BizteX Connectは、コロナ禍前からほぼリモートで開発を進めていたのですが、エンジニアがオフィスに来られないと営業やCSのメンバーとのコミュニケーションが取りづらい状況があったので、その間を繋ぐような取り組みを行ったりしました。

一方で、顧客とビジネスを繋ぐ領域のマーケティングやビジネスディベロップメント、パートナーシップなどは、一部関わってはいますが、あまり現状はやれていない領域です。

というのも、今までは組織構造上の経緯があってやれてなかったのですが、一緒にやった方がいいと考えています。
これまではプロダクトの開発計画とマーケやセールスの戦略が独立していた状況があったのですが、大上段から一緒に作っていく必要があると認識を変えて取り組み始めており、リリース前の機能の仮説検証をマーケと連携して行い始めています。

組織的課題の解消を目的に0→1で新規プロダクトをリリース

Q. プロダクトマネージャーとして誇れる実績や取り組みはありますか？

BizteX cobitを社内で立ち上げてリリースするまでの、0→1の経験ができたことです。

組織が大きくなり従業員数が30人を越えたくらいの頃、プロダクトはBizteX cobit（RPA）のみだったのですが、その拡販フェーズで壁に直面しており、その対策について経営層と現場メンバー間の想いや考え方に違いが生じ、溝が生まれかけたことがありました。

この状態を全社的課題と捉え、改善するための取り組みとしてBizteX Connectの立ち上げを行いました。

具体的には、BizteX cobitは、RPAという性質上、画面や仕様の変更によって処理が失敗してしまうなど安定性の面で課題がありました。また、ユーザーが本来やりたいことをRPAのみで実現することが技術的に難しいといった課題もありました。

そこで、各システムのAPIの連携を橋渡しするような手法で業務自動化を行うことができないか？と考え、iPaaSのBizteX Connectを作る発想が生まれました。

BizteX cobitは、画面さえ操作できればなんでもできるが、ものによっては設定が難しかったり安定しなかったりという課題がある。
BizteX Connectは、安定性は高いが、APIがないシステムとは連携できない。

この2つを組み合わせて得意・不得意を補い合って使うことで、業務自動化においてユーザーのやりたいことを実現するための提供価値を上げられるのではないか？という戦略を提案しました。

この戦略によって、経営層と現場の目線が揃い始めたように思います。

提案内容が承認された後に、プロダクトのリリースに向けてはかなり大変だったので、「言わなきゃ良かったな〜」と思ったことはここだけの話です。笑

プロダクトの企画から社内のメンバーのツテを使ってユーザーにヒアリングをしつつ、α版を元にユーザーへの営業活動を行い、開発チームと話しながらどういう機能・デザインにするか、ファーストリリースはどこまでやるかなどを詰め、世間はGW休みの期間もテストしながらリリースまでこぎつけることができました。

Q. プロダクトの企画からリリースまでにおいて、一番大変だったことは何ですか？

どういうプロダクトにするかの全体像を作るところが大変でした。

プロダクト観点でいうと、抽象度が高い状態からどう製品に落としていくかの部分です。

画面の話であればなんとかイメージを付けていったりできるのですが、裏で何が動いて制限の仕様としてどういう部分が発生しそうか、それをファーストリリースまでにクリアすべきかどうかという点は、かなりエンジニアと突っ込んで話をする必要があり、用語の定義や概念モデルの設計など自分でFigmaで画面イメージを作ってそれをベースに話をしながらやりました。

ビジネス観点だと、どういう市場に向けて、どういうターゲットにするのかという、最初の領域を決めるのが難しかったです。

ある仮説を持ってユーザーにヒアリングを行った結果、課題はあるが、今考えているプロダクトでは単純に解決できそうになく、機能をもりもりにすれば解決できるが、ファーストリリースではできそうにないし、本質的に作りたいプロダクトになるんだっけ？という感じでした。
仮説検証を繰り返して、最初のユーザーはRPAを使っていただいているユーザーから徐々に展開していきつつ、他のプロダクトとの差別化のポイントにしていくということを決めたのですが、自分で決断することも、社内で承認を得ることも大変でした。

ちなみに、ユーザーヒアリングもプロダクトの企画も全て自分でやっていました。当時、プロダクトマネージャーのコミュニティも相談相手もいなかったので、どうするのが正解なのかも分からない状態でやっていて苦労しました。

マイルールは、Whyを深掘る / とりあえずやってみる / ドキュメンテーションを大事にする

Q. 行動指針や大切にしているマイルールはありますか？

3つあります。

1.Whyを深掘る

例えば、機能の要望が上がって来た時に、それがなぜ顧客にとって必要なのか、重要なのかということを突き詰めるようにしています。

それは、プロダクトの機能のみではなく、全ての課題や問題に対して、「本当に課題になっていることは何なのか？」「ユーザーにとって一番必要なものは何なのか？」ということを意識して、自分自身が腹落ちできて、他の人に共有できるレベルまで深堀るようにしています。

2.とりあえずやってみる

今まで、様々なロールを好む好まざるに関わらずとりあえずやってきたことも、ここに由来していますが、不確実なことはやってみないと分からないと思っています。

だからこそ、デザインをやっていた時から思っていたのですが、プロトタイプがとても大事だと考えています。
物を作る時は、絵を描いたり模型で大体の形を作ったりして、大きさや使おうとしているユースケースに合っているか、チームで作ろうとしているもののイメージが合っているかを検証します。

そのように、とりあえず形にしてみる、手を動かして物事を進めてみることが重要だと思っていて、考えて止まるよりはまずやってみることを大事にしています。

何かを作ると決めた時にも、ざっと画面がどんなふうになるのかを紙に書いたり、完璧じゃない状態でも社内のメンバーやユーザーに共有して、「これで良さそうか？」「イメージ合っているか？」と検証するようにします。
例えば、社内でミーティングする時は、「こういうものをやろうとしていて、この部分は決まっていないが、イメージはこんな感じ、提供できるメリットはこんな感じ。しかし、こういうところがまだクリアになっていないので、ユーザーにヒアリングできたり、ファクトを持っていたら出して欲しい。」と、とりあえずアウトプットするようにしています。

3.ドキュメンテーションを大事にする

コロナ禍でより重要度は増していますが、元々BizteXではリモートで開発を進めていたこともあり、オンラインや非同期のコミュニケーションで物事を進めていく上でドキュメンテーションを大事にするようになりました。

ミーティングのアジェンダや課題を明確にすること、議論するにあたって課題に対してどんな選択肢がありえるか、それらのプロコン（Pros/Cons）や理由などを明確にします。
また、意思決定をする上で、後で遡った時に意思決定の背景や理由を追えるようにしています。

自分がいなくなった時もそうですが、単純に忘れてしまった時やミーティングに参加できなかった人にも意思決定のプロセスが伝わり理解・納得できるように意識しています。

プロダクトに関わる人数が増えた時に、意思統一をしてチームで一つの物事に向かっていくことが難しいと感じたことがありました。
全員が同じ会議に出て同じプロセスを辿っていればそんなことはないと思うのですが、密室会議で決まった内容を知らないということは往々にしてあり、決定事項だけ読んでも理解・納得できないと思います。

だからこそ、上手くドキュメンテーションを行い意思決定のプロセスを残していったり、テキスト上でのコミュニケーションで齟齬が発生しないようにしたりと、文章を作ることに時間をかけながらやっています。

プロダクトは作り手の影響を強く受けるからこそ、モチベーションが大事

Q. いいチームをつくるために取り組まれていることはありますか？

みんながモチベーション高く働けるようにすることを気にしています。

プロダクトは、エンジニアだけでなく、経営層含めCS、営業、マーケ含めて組織のメンバーで作っていくものだと思っていて、作り手の影響を強く受けると思っているためです。

そのために、ロールとしてはマネージャーではなく、人のマネジメントも得意ではないのですが、部門間の情報連携促進を意識的に行っています。

人数が増えてきて、部署が営業部、CS部など役割で分かれてくると、部門と部門の間に落ちるタスクや部門間の情報の非対称性が強まったり、組織の対立構造が生まれてしまったり、プロダクトの方向性が揃わなかったりとしてきます。

そうならないように、部門間のタスクを拾いに行ったり、指摘をして情報の非対称性を埋められるようにと動き、組織の対立構造を未然に防ぐことや各メンバーのストレスに繋がらないように努めています。

BizteXの社員番号7番で入社して古株になってしまっていることもあり、CEOやCTOをはじめとした初期メンバーと最近入ってきているメンバーとの橋渡しの役割を担った方がいいんだろうと思って取り組んでいます。

質の高い企画のためには、質の高い一次情報が重要

Q. 質の高い企画をするために意識していることはありますか？

2つあります。

1.質の高い一次情報をどうやって取ってくるか、共有するか

ユーザーに自分でヒアリングをしたり、商談に同席したりするのですが、質の高い一次情報をどうやって得るのかということは意識しています。なるべく又聞きではなく、自身で直接得るようにしています。
また、その情報を鮮度の高いまま、他のステークホルダーにいかに受け渡すのかという点も意識しています。

内容を受けて僕が考える場合もありますし、チームに共有して受けた情報から何を生み出すかを考えることもありますが、最大限活かすために聞いてきた情報のみを伝えるのではなくその背景などを伝えたり、他で仕入れた関連する情報とも接続して、プロダクトの企画を行っています。

2.各種業界やテクノロジーの最新情報のキャッチアップ

色々なSaaSのプロダクトの最新情報を得て、実際に触るようにしています。

それが直接プロダクトに活きることもありますし、僕らの提供している業務自動化のプロダクトはそれ単体では成り立たず、連携する相手のサービスが必要となるため、その可能性としてどんなもの・機能・APIがあるのかを知っておくことは重要だったりします。

デザイン、営業、エンジニア、PjM、CSを経験した後にPdMに

Q. どのようなキャリアパスでPdMになったのでしょうか？

大学時代は家具や家電など物のデザインをするプロダクトデザインの専攻をしていたのですが、修士の研究で電子工作をする必要があり、そこでプログラミングをすることがありました。
その経験がきっかけとなり、新卒でエンタープライズ向けのERPを開発・販売するワークスアプリケーションズに入社し、営業やテクニカルサポート、開発、プロジェクトマネージャーなど様々なロールを経験しました。

その後、BizteXに入社したのですが、弊社の取締役 CTO Co-Founderである袖山はワークスアプリケーションズ時代の元上司であり、転職を考えているという話をした際に「BizteXに来ないか？」と声をかけてもらったことがきっかけでした。

BizteX cobitがリリースされて半年くらいの頃だったのですが、はじめはカスタマーサクセスの立ち上げとプロダクト開発を兼任していました。
だんだんと利用ユーザー数も増えていく中で、自分はカスタマーサクセスがメインになっていき、社内では開発メンバーも増えていました。

その後、機能要望も徐々に増えてきたので、スクラム開発で開発プロセスを回していきたいということになり、プロダクトオーナーを担うことになりました。ちなみに、自分がプロダクトオーナーを任された理由は、エンジニアとしてのバックグラウンドがあって技術の素養があり、カスタマーサクセスの経験からお客様やユーザーの解像度が高く、機能や要望の優先順位判断が適切にできるのではないかということでした。

スクラム開発のPOをやっていく中で、徐々に領域ややることが広がっていき、スクラム開発の優先順位を付けるだけでなく、全社課題の解消やプロダクトのロードマップを作ることなどを行うようになりました。

また、RPAのみではなく、新しく各システム間連携のAPIもカバーするところも自社でプロダクトを作ってやっていくべきではないか？と提案して、BizteX Connectのプロダクトの立ち上げを行いました。2019年の夏頃に企画して、2020年5月頃にリリースしたので、まだ1年経っていないような状況です。

BizteX cobitのプロダクトマネージャーを担当しながら、BizteX Connectの立ち上げを行ったため、2つのプロダクトを担当している状態となっています。

Q. 様々なロールを経験されたことは、プロダクトマネージャーを担う上で役に立ってますか？

結果的に様々なロールを経験することになり、気付いたらプロダクトマネージャーになっていたという状況なのですが、幅広く様々なロールを経験していたことで、各部門のステークホルダーとコミュニケーションを取る上で相手の視点に立つことができるので良かったと思っています。

例えば、営業を経験してなかったら、営業の課題や業務の進め方のイメージは簡単にできなかったと思います。

ちなみに、営業を経験することになったのは自分でも想定外の出来事でした。

新卒で入社したワークスアプリケーションズでは、研修の最後に希望部署のプレゼンを行って営業か開発かに分かれるのですが、開発を希望していたにも関わらず適性があると判断されて営業配属となってしまいました。
結果的に、営業はあまり上手くいかず、上司にも相談して開発側へ異動させてもらったという経緯があります。

PMの組織化を行い、第3・第4のプロダクトづくりに挑戦

Q. 今、挑戦していることはありますか？

現在、BizteX cobitとBizteX Connectのプロダクトマネージャーを担当していますが、1人で2つのプロダクトを担当している状態は良くないと思っており、プロダクトマネージャーを採用しようとしています。

その上で、プロダクトマネージャーの組織化に取り組み始めており、今後はその組織をまとめていくことにチャレンジしたいと考えています。

今後も第3・第4の業務自動化プロダクトをつくり、「業務自動化と言えばBizteX」という世界観を実現していきたいので、プロダクトを戦略上どういう領域で作っていくか、どういうデザインにしていくかなど、プロダクトマネージャーチームを作って全社のプロダクトマネジメントを担っていきたいと思っています。

PdMが必ず行う「考える」ことに気付きを与えるオススメの本

Q. かけだしPdMに向けて「まずはこの本を読むべし」というオススメの本はありますか？

プロダクトマネージャー色は少し薄いかもしれないですが、「考える練習をしよう」という本がおすすめです。

対象読者層は小学生くらいの絵本で、子供の頃から好きでめちゃくちゃ読んでいるのですが、大人になってから読んでも発見があっていい本です。

先入観にとらわれないようにするとか、普段自分が意識していない行動がどれくらいあるか、観察するとはどういうことかなど、簡単な文章で書かれているのですが、すごい示唆に富んでいます。

プロダクトマネージャーは色々なことを行うと思いますが、「考える」ことは必ず行うと思うので、どういうふうに考えたらいいかという点で参考になると思います。

かけだしPdMへ「器用貧乏な人こそ、PdMになるべき！」

Q. この記事を読んでいるかけだしPdMへ一言お願いします！

僕もたまたまプロダクトマネージャーのポジションになりましたが、器用貧乏な人こそプロダクトマネージャーになった方がいいと思っています。

様々なロールを経験をしてきて、例えば、エンジニアとしては社内にすごいエンジニアがいて「この人みたいにはなれない」と思いましたし、営業も、プロジェクトマネージャーも同じような思いがありました。
ある程度できるようにはなるのですが、「ここで勝っていくぞ」という領域が見つけづらいと思っていました。

そんな時に、たまたま縁があってプロダクトマネージャーになって、今までの自分のキャリアがこのロールで活かせられると感じました。
エンジニアリングやデザイン、ユーザーヒアリング、CS、新規提案、営業など、総合格闘技という表現がまさに合います。

大変ですが面白いと感じており、プロダクトマネージャーのロールを極めていきたいとキャリアのイメージもつくようになったので、そういう思いを感じている方にプロダクトマネージャーの道を勧めたいと思います。