エンジニアからPdMに転身した理由
——はじめに、大野さんがいまMNTSQでどのような役割を担っているのか教えてください。
大野：
私は2022年11月に入社して、PdMとして契約管理プロダクトや外部連携機能などを担当してきました。
最近では個別の機能開発だけでなく、よりプロダクト全体の業務設計にも領域を広げています。またチームマネージャーとしても、メンバーのマネジメントや課題解決の相談に乗ったりする役割も担っています。
——大野さんのキャリアのスタートはエンジニアだったそうですね。
大野：
はい、キャリアの最初は客先常駐のエンジニアでした。新卒で入社して最初に担当したのは、農業用ドローンが農薬を自動散布するシステムの開発です。その次はゼネコンのIT子会社で、親会社が使うシステムの開発や要件定義などを経験しました。
2社目も客先常駐のエンジニアとして、アーティストのチケット発行システムのリプレイスなど、多様な現場を経験しましたね。
その後、3社目に入社した歯科医院向けのSaaSプロダクトを提供する企業で、そこではじめてエンジニアからPdMに転身することになったんです。当時はまだ会社にPdMという職種がない会社だったので、社長と直接壁打ちしながら、新規事業のアイデアを出したり、既存プロダクトをどうスケールさせていくか戦略を練ったりする日々に、これまでにない面白さを感じていました。
——エンジニアからPdMに転身された、きっかけや理由は何だったのでしょうか？
大野：
エンジニアとして働く中で、自分は純粋に技術を突き詰めるタイプではないと感じていたんです。技術でトップを目指すよりも、むしろ人とのコミュニケーションやマネジメントで価値を発揮する方が得意ではないかなと。
そんなとき、前職の社長からたまたま「PdM」という職種があることを教えてもらって。調べてみると、ビジネスやものづくりのまさに起点から関われる。「これはプロジェクトマネジメントよりも面白そうだ」と感じて、PdMになることを決めました。
人の「もっと楽したい」をどこまで織り込めるか
——大野さんは、元々、人の業務を効率化することに強い関心があったそうですね。
大野：
そうですね。エンジニアって、基本的にみんな面倒くさがりなんですよ（笑）。
とにかく非効率なことは効率化したいと思うので、すぐに「この面倒な作業、コードで自動化できないか」って、真っ先に考えちゃうんです。
だから、自分の仕事の効率化はもちろん、お客様が「この仕事が大変で…」と話しているのを聞くと、「こうすれば自動化できるのに」と、自然に考えて提案していましたね。
——PdMになられたいまも、「人の業務を効率化する」という点は変わらず意識されていますか？
大野：
もちろん意識はしてますが、視点は少し変わったかもしれません。
以前は、単純に「この人の仕事が楽になればいい」という個別最適の視点でした。ただいまは、「ユーザーが実際に使うシーンで、本当にベストな体験を提供できているか」という、より本質的な視点を意識するようになりました。
というのも、システムを使えば業務が効率化されるのは当然ですが、人は慣れてくると「もっと楽したい」という欲求が自然に生まれてくるものです。その欲求を先読みし、どこまでプロダクトの初期構想に織り込めるか。そうしたより俯瞰的な視点からプロダクト開発に向き合うようになったと思います。
AIありきの発想は危ない。「人の面倒な作業をなくす」から考える
——MNTSQのプロダクト開発における、AIの捉え方についても伺いたいです。大野さんとしてはAIの進化をどのように捉えているのでしょうか。
大野：
これまで複雑なロジックを組まないと不可能だった処理を、AIが一足飛びに実現してくれる。これは紛れもなく大きな進化です。
ただ、重要なのは「AIだから使う」という技術起点の発想に陥らないことです。
まず「自分たちのシステムで、業務がしっかりと回る」という揺ぎない土台があること。そのうえで、「この業務フローの中の、この部分を一足飛びに進められれば、ユーザーはもっと楽になる」という明確な課題があって、初めてAIという選択肢が出てくる。これが、あるべき姿だと考えています。
たとえばMNTSQが提供するAI契約書解析機能も、元々は「アップロード→人が目で見て手入力」という業務フローがありました。この「手入力」という“面倒”をなくすために、「ではAIを使おう」となるわけです。AIを使って高い精度で情報を抽出できれば、人はそれを最終チェックするだけでよくなりますよね。
このように、あくまで「人の面倒な作業をなくす」という課題解決の視点から逆算して考えることが、何より大切だと思います。
——今後、AIをどのように活用してプロダクトを進化させていきたいですか。
大野：
まず、多くの競合他社が提供している機能、つまり業界のスタンダードとなりつつある機能は、当然私たちも最低限提供する必要があります。そこでお客さんをがっかりさせるわけにはいきませんから。
またいま、お客様の注目は「蓄積したデータをAIでどう活用できるか」という点に集まっているので、「データを貯めることには、ちゃんと意味があるんだ」と実感してもらえる機能は、スピード感を持って作っていきたいです。
でも、それ以上にこだわりたいのは、やっぱりユーザー視点の体験設計ですね。
いまのプロダクトは、本当に法務の方のオペレーションに最適化されているのか？年に数回しか使わない事業部の方にとって、本当に使いやすいのか？ そうした一人ひとりの業務に密着した体験を追求したうえでの、本質的な改善をどんどん進めていきたいと思っています。
——大野さんはユーザー会に参加されたり、CS（カスタマーサクセス）とお客様先に同行したりと、顧客との対話の機会を非常に多く持たれている印象です。それはなぜでしょうか？
大野：
その理由はシンプルで、「答えは現場にしかない」と考えているからです。
結局、僕らが社内の会議室でどれだけ「ユーザーはきっとこう使うはずだ」「この機能があれば喜ぶに違いない」と議論を尽くしても、それはただの仮説でしかない。
実際にプロダクトを使っているお客様、そして彼らと日々向き合っているCSやセールスに話を聞くこと。それが、真の答えにたどり着くための、最も効率的で、最速の近道なんです。
——そうして得た現場の声は、どのように開発へ反映させているのでしょうか。
大野：
まず基本姿勢として、どんな意見も一度すべて受け止めることを大切にしています。たとえ内心で「少し違うかもしれない」と感じたとしても、お客様の環境で起きているのは紛れもない「事実」。それを否定することから始めるべきではない、と考えています。
そのうえで、現場で得た小さな気づきや改善のヒントは、開発チームに「そういえば、この間の打ち合わせでこんな話があってさ」というように、雑談のように話すようにしています。そうすると、開発チームから「それ、早くやろうよ」と話が進展することも少なくありません。最も早かったケースでは、僕がぽろっと口にした改善案が1〜2日で実装され、その週のうちにリリースされたこともあります。
一方で、大きな変更に関しては、より慎重なプロセスを踏みます。SaaSである以上、特定の一社だけが持つ独自運用に合わせた機能開発はできません。なぜなら、その変更が他のお客様にとっては、かえって使いにくくなってしまう可能性があるからです。
そこで重要になるのが、お客様の声から「最大公約数」を見つけ出すことです。なるべく多くの声に丁寧に耳を傾け、業界や企業規模が違っても、大多数のユーザーにとって価値のある共通項は何かを見極め、それを機能に落とし込んでいく。
少し特殊な運用をしている方には別の方法で工夫をお願いしつつも、大多数の「普通に使っている人」がプロダクトの進化にスムーズに乗れるようにする。それが私たちの目指す体験です。
——実際にお客様に会いに行ってお話を聞いた時の、反応はいかがですか？
大野：
皆さん、とても温かく受け入れてくださり、本当に助けられています。
たとえば以前、あるユーザー会の後で訪問したお客様との出来事が、特に印象に残っています。雑談の中で私が法務出身ではないと話したところ、なんと次回の訪問時に、法務の専門家でなくても分かるような資料をわざわざ準備してくださっていたのです。
お金を払ってサービスを使っている側が、ベンダーのためにここまで丁寧に対応してくださる。これは単なるベンダーと顧客の関係ではなく、プロダクトを共に創る「共創関係」が築けている証だと感じ、胸が熱くなりました。
——最後に、今後の展望についてメッセージをお願いします。
大野：
そうですね。これまでは「こういうことを聞きたい」という目的が生まれてからお客様を紹介してもらう形でしたが、これからはもっと日常的に接点を持ちたい。そして、「そういえば大野さん、この間言いたかったんだよ」と、自然発生的に情報交換ができるような関係性をお客様と築いていきたいですね。
以前いた会社では、PdMの社用携帯にユーザーさんから直接電話がかかってきて、そのまま要望を聞くシーンもありました。それくらい何でも言い合える信頼関係こそが、プロダクトを強くすると信じています。
それにPdMのスケジュールなんて、本来はユーザーヒアリングで顧客との対話で埋まっているのが当たり前だと思うんです。
そうした点でも、これからも積極的に現場に足を運び、ユーザーとの対話を通じて、プロダクトをもっともっと便利に、そして愛されるものに進化させていきたいですね。
