大企業のR&D組織に「紙とペンの次」を授ける、前人未踏の挑戦──ストックマークのBizDevチームは未開の地に価値があるかを探究する「先遣隊」

中川「情報を集めて、考えて、アイデアや企画をアウトプットする」という一連の業務は、未開の業務なんですよね。おそらくどこの会社でも属人的だと思いますし、コンサルティング会社では一定の方法論もありますが、それを一般化して誰もが使えるようにしたことはありません。

中川生成AIという新しいテクノロジーを用いたアプローチでならブレイクスルーできるのではないかと思いますし、実現できれば社会的にも大きなインパクトがある。それが今、私が感じているこの仕事の面白さです。

田中「0→1」と「1→10」のフェーズを、すべて1人のBizDevが担うには荷が重いですし、それではスケールしにくいと思うんですよね。ですので、役割分担のために今の体制になっています。「BizDevはチーム戦」という考えです。

BizDevの役割を端的に表す言葉として僕がしっくりきているのは「先遣隊」です。未踏の地を開拓しようとするときに、真っ先にそこへ赴き、そこにお宝があるのか、すなわち本当に解くべき価値がある課題なのか、解ける見込みがあるのかを確認する。その上で、脈がありそうなら会社全体がそこへ進軍できるよう“地ならし”をする役割。そんな意味で、社内でもよく「先遣隊」という言葉を使っています。

渡邊以前はCSの立場で、今と同じように自発的にニーズ探しを進めていました。事業やプロダクトの未来を構想するのがそもそも好きなんです。

田中CSが向き合うべきは、とにかく目の前のお客様です。お客様の課題に向き合って、他でもなくそのお客様における最適解を探っていくのがCSのメインミッションです。

それに対して、PMMに求められる頭の使い方は少し違います。個別のお客様が向き合っている課題を抽象化して、「他のお客様も同じような課題があるのではないか」と視点を一段上げて、お客様も自社も成長するようなプロダクトの進化を考え続けることが必要です。

渡邊はCSにいたときから、「お客様の課題を抽象化してこのようにプロダクトに反映すれば、他の多くの企業にもメリットがある機能になるのではないか」というような内容の企画書をよくつくっていたんですよね。それを見て、PMMのポジションに誘った形です。

中川ストックマークのサービスは情報収集から分析、アウトプットまですべての作業を、より網羅的かつより緻密にしていくものなのですが、お客様の中でも明確な課題をお持ちでないことがほとんどです。「答え」がないのは当然で、「問い」すらないケースが多い。

その「問い」を言語化することが、私の仕事の大きな部分を占めます。

例えば会計システムであれば、やるべき業務プロセスは決まっていますから、お客様が「システムでこれができるようにしてほしい」という意思がある程度はっきりしています。

しかし、私たちのプロダクトを実際に使うユーザーの多くは、大企業の中のR&D組織の方たちです。「新規事業を企画する」「アイデアを出す」というという仕事には、確立された業務プロセスがありません。

お客様の中に「もう少し良い情報が取れるとよいのだけど……」というような、「問い」とも要望とも言えない“ふわっとした”ニーズがあったときに、「良い情報とはどういうものか」というところから一緒に考えて言語化していく。そして何を実現したいのかを明確にして、プロダクトに反映していく。そういう役割を担っています。

中川CSの場合は、「アプリのこの部分を使いやすくしてほしい」といった操作に関する要望をお客様から頂くことが多いと思います。お客様の中で「問い」がすでに言語化できていて、そこに対応していくことがCSの重要な役割です。

一方、言語化されていない「問い」、「お客様がそもそも何をしたいのか」をお客様と共に探り、考えるのがコンサルタントとしての役割だといえます。

田中一般的なSaaSのCSは、想定した業務に対して、想定した使い方ができる様になる支援をしていきます。言い過ぎかもしれませんが、お客様の業務にツールをフィットさせるのが従来のCS。

そうではなく、お客様の業務を変えることも含めてツールを改善する、新しい機能を追加していくことを考えるのがBizDevであり、コンサルタントとして中川が担っている役割です。その違いだと捉えた方がわかりやすいかもしれません。

渡邊これは僕らのプロダクトの強みでもあり、難しいところでもあるのですが、プロダクトがカバーする範囲が非常に広いがゆえに、「この課題を解決するのがこのプロダクト・機能です」というようにシンプルにわかりやすく説明するのがなかなか難しい。

それはお客様に対してもそうですが、社内のメンバーも同様で、共通理解が持てなくなってしまう。例えば営業チームが、抽象的な理解のままお客様のところに行っても、抽象的な説明しかできない。するとお客様は、具体的に何ができるのかわからなくて導入の意思決定はできなくなってしまう。

PMMの役割は、抽象度の高いサービスの価値を整理・整頓して、「説明可能なもの」にすること。私の中では、「売れる」ための社内外の“地ならし”をしている認識です。

田中だからこそ、コミュニケーションをしっかりとって情報連携していくことが非常に重要だと考えています。そうしないと意図が共有されず、良い発想も出てきませんから。

その点、渡邊は“コミュニケーションお化け”みたいな存在で、他の部門やチームの会話にどんどん入りこんで行きます。そこで気を遣ったら事業が前に進まない、そんなスタンスですね。こういう人が今のBizDevチームにいてくれるのはすごく嬉しい。

中川は、どちらかというと論理的に思考するタイプです。言語化において重要なのは、差を理解することです。ある事象を並べて、なぜ違いが生まれているのか、違うことによってどういう役割を果たせているのかという点に誰よりもこだわって向き合っているのが中川です。

タイプの異なるこの2人がいることで、今、BizDev組織は最適な状態になりつつあると感じています。この能力をさらに拡充することによって、ストックマークがビッグテックとの違う点、優位性を確立し、ストックマークのビジョンを本当に実現できるだろうと考えています。

田中私たちのプロダクトで「解決できている部分」と「まだ課題として残っている部分」について目線合わせしています。その上で、当面どの部分を取り上げて開発を進めていくのか、ビジネスサイドとの認識合わせをどのように行うのか、といったことを検討しています。

渡邊このシートには、主なユーザーである研究職の皆さんが日々の業務で直面している課題と、決裁者（管理者）の導入判断に関する課題、2つの立場で抱えている課題を詳細に書き出しています。我々がそれぞれお客様との接点を持つ中で、聞いてきた課題を書くイメージですね。

その上で、各課題に対して、すでに実現できている項目、部分的に対応できている項目、まだ対応できていない項目を特定しながら議論を進めています。

田中渡邊は、「どの課題を解決するとどれくらいのマーケットがつくれそうか」を想定し、それを実現するためにつくるべきソリューションやユーザー体験を考えて書き込んでいきます。それらを、今のストックマークの技術でどのようにつくっていくと最もスムーズに市場に受け入れられるのかを、この会議で考えます。

例えば、ある機能の完成版を出すのに年単位の開発期間が必要そうだ、となった場合、それでお客様を長期間お待たせするのは、SaaSのやり方としては不適当ですよね。事業成長との両立という観点も踏まえ、フェーズを区切って段階的に出して行くことをBizDevとして考えます。

この会議で方針が決まったことについては、渡邊からプロダクトマネージャー（PdM）に説明し、実際に開発を進めてもらう流れです。段階的開発の具体的な設計は基本的にPdMが考えるところですが、PMMと議論をしながら、「最初の体験として不十分だからここまではやってほしい」とか、逆に「ここまではフェーズ1としてはやり過ぎだから、対象とするターゲットを絞ってその人たちに確実に刺さるようにしたい」といった調整をしていくイメージです。

田中大きいものだと、『Anews』上に2024年6月にリリースした「社内情報検索」機能があります。それ以前までは、「一般に公開されている情報」の収集ツールという位置づけでやってきました。でも、それは僕らがとったポジションがそうだっただけで、お客様は「公開情報」を調べるときと「社内の非公開情報」を調べるときに、どうやら頭のモードをそんなには切り替えていないものなんですよね。

例えば、ある技術の情報を調べる際には、世の中に公開されている特許や論文を知りたいし、関連する社内の研究開発プロジェクトのことも合わせて知りたい。そうすると、いちいちツールを切り替えて探すのは非効率に感じる。

だから、それをワンストップで我々のツールの中で検索できたら、「良い情報を取りたい」という抽象的な問いに対して答えることができるのではないかと考えました。

特に最近はChatGPTのような対話型生成AIが企業にも浸透してきたので、「何か質問をしたらワンストップで全部まとめて答えてくれる」という体験は定着していくでしょう。そのことを踏まえても、あらためて社内情報を、公開情報の収集ツールにシームレスに接続していくべきだろうという判断です。

加えて、社内情報の検索に関しては、「エンタープライズサーチ（企業向け検索エンジン）」といった名称で市場のカテゴリがすでに確立しています。そうした市場のプレイヤーとの差別化をしながら進めていくことも重要になります。

同時期にいくつかのお客様からも「『Anews』の中でワンストップで情報を得たい」という具体的な要望があり、受け入れる素地もできつつあるということで、「社内情報検索」機能の実装に踏み切りました。

田中「最終的にこうなれば理想」というものがあっても、すぐに実現できるとは限りませんので、先ほど話したように段階的に開発を進めます。

また、お客様の期待を上げ過ぎないように、フェーズごとにメッセージも調整しています。「理想」の状態が1年後にはできるとしても、それをそのままフェーズ1の段階でお客様に伝えてしまうと、大言壮語に聞こえてしまい結局売れないということになります。

田中フェーズ1では「社内情報が検索できること」を最低保証するフェーズ。いわゆるMVPです。

フェーズ2は、社内外の情報をパーソナライズして検索・要約できることを目指しており、その準備をしているところです。DeepSeekやDeep Researchなどは誰が検索しても一定の出力になりますが、それを我々独自の蓄積データによってパーソナライズすることで、「こういうまとめが欲しかった」と言っていただけることを試す段階です。

フェーズ3の詳細は伏せますが、もう少し社外情報の対象をもう少し広げつつ、我々の独自性も出して行く方向で考えています。Copilotや自社RAGとは異なる体験を提供するAIエージェントになる予定です。この段階までの詳細なニーズは、まだ詳細には捉えられていません。お客様にソリューションの仮説を見ていただきながら、「そんなことできるの！？」という驚きの有無と日常業務での課題との接続を探りながら進めていきます。

田中ある検索ワードに対して、どのような企業や技術トピックが関連しているのかを可視化したものです。かつ、それらの情報を誰が見ているのかをつなげて表しているものが「ネットワークグラフ」です。

田中僕らのサービスはもともと情報収集ツールなので、社外の公開されたものにしろ、社内の情報にしろ、情報を集めることが使命です。でも、「社外にも社内にも発信されていない情報」というものもあるんですね。それは、人の中に知識や経験という形で存在している情報です。

ストックマークが対象としているような大企業では、傍目には近しい関係にあるように見えても「隣の部署は別の会社」と言えてしまうほど部門間に壁があったりします。そのような組織では、例えばある技術を種とした新規事業を考えるときに、「社内のAさんはこの技術分野に詳しい」ということがわかれば、その人に話を聞きに行くことができます。いわゆる「Know Who」の情報です。

「社内で誰かやったことがあるはず」「社内のどこかに詳しい人がいるはず」ということまではわかっても、その“誰か”がわからない、そういうケースは少なくありません。これまで、部署やチームなど組織上の枠組みにとらわれない社内人脈形成は、喫煙室（タバコ部屋）や飲み会などでの偶然の出会いに頼る部分も多々ありました。

でも、この「ネットワークグラフ」があれば、誰がどういう情報に関心を持っているのかが分かります。そのような社内人脈を、より意図的に生み出していきたいというニーズを言語化し、それに応えるべく開発しているのがこの機能です。

田中具体的に業務のどこで使うと仕事の仕方が変わるのか、アウトプットが変わるのかは、これから見ていくことになります。今、まさに“BizDev中”というステータスですね。

田中重要なことは「お客様の業務プロセスで本当に機能するのか、結果として価値を生むものなのか」を確かめること。これこそ、「先遣隊」の役目です。要望を受けたら、立ち止まって咀嚼し、ほかの要望との関係性や、その裏にある真の要望の種を探す、そんなスタンスでいます。

その過程で、渡邊が他のお客様にも聞いてみたり、中川が「本当に業務で使えるのか」を探索したりというように、ミッションが分かれていきます。

中川先ほどお見せした“ネタ帳”にも、その内容は書かれていて、議論の対象になっていきます。「ネットワークグラフ」が組織の中の誰の、どの課題に、どのように使えるか、という視点で議論を進めています。

私の方では、コンサルタントとしてお客様の支援に入っている中で得た知見に加えて、論理的に想定できることをベースに話をします。対して渡邊の方は、CS時代の知見や、実際にお客様に「ネットワークグラフ」を見ていただいて得た反応などを踏まえて議論する感じです。

田中先ほど話した週次会議とは別にリサーチチームとも定例で会議を行っていて、リサーチ側からは技術的にできるようになったことなどを持ち寄ってもらいます。

我々BizDevチームはそれを聞いて、「“ネタ帳”にあったあの課題を解決できそうだな」と頭を働かせるわけです。ものによっては「Aという課題に対して技術を当てる予定だけれども、Bの課題にも使えるんじゃないか」といった発見があることもあります。ニーズ・シーズマッチの場ですね。

そしてそこから、「お客様にも聞いてみよう」「本当にプロダクトにできそうかメンバーにも聞いてみよう」という感じで話が広がっていきます。

こうして話が広がるのも、“ネタ帳”としてMRD（Market Requirements Document）を準備できているから。ネタが少ないと、新しい技術を聞いても何に応用できるか気づけませんから。アンテナを立てる意味で、この3人で継続的に“ネタ”を増やし続け、認識を合わせられるようにしています。

田中研究組織とスタートアップがミックスされた組織なので、一般的なSaaSの会社とはひと味違います。IT・AI分野のディープテックスタートアップです。

コンサルタント経験者は、課題を解決する手段（ツールやシステム）に関しては自分で直接開発できないことも多く、自分の思い描いた戦略・構想が実現できない歯がゆさは結構あると思うんですよね。

でも、ストックマークに来てからはそうした歯がゆさはありませんし、むしろ「それ、できるんだ」と驚かされることが多いです。そういう面でBizDevをやるには非常にいい環境だなと思っています。

中川生成AIのプロジェクトでリサーチチームの人と話していたときに、「今、論文を書いているので、研究内容を元にして機能を改善します」と言われたことがありました。

生成AIの領域では世の中でまだ解決策が見つかっていない課題が結構あるので、その解決に向けてリサーチチームが取り組んでいるんですよね。我々はそれを実装していくという一番近い立ち位置にいるのはすごく面白いと思いますね。

産総研グループとのプロジェクトではリサーチチームから2人、生成AI担当とナレッジグラフという技術の担当者に入ってもらい一緒に動きました。研究者の知見をダイレクトにシステムに活かしていて、おそらく普通の会社ではできないなと実感しました。

渡邊お客様にどのような社外情報を取りたいかをヒアリングするとよく挙げられるものに、「競合情報」があります。ただ、「何をもって競合とするのか」の定義は意外と難しくて、僕らの間でしばらく悩んでいたんです。

でも、あるときリサーチと連携する会議を毎週していた中で、リサーチ側の方が「技術的にこういう処理をすると競合を特定できそうだ」という提案をしてきてくれたことがありました。僕ら3人は、「え、できるの？」となって（笑）。そういう感じは面白いと思っています。

渡邊たしかに難しいです。それは、私の理解もそうですが、CSチームも同様で。それでもお客様に説明しないといけないので、勉強会を開いたりして理解を深めるようにしています。

中川僕らも含めて、BizDevチームには自然言語処理に実務で関わった経験者って1人もいないんですよ。ですが、R&Dチームもその前提で私たちに説明してくれますので、それを楽しめるマインドさえあればキャッチアップできます。

中川自分は言語化が好きなんです。「良い情報とは何か」をどんどん掘り下げていくと、「研究テーマにおいてインパクトを与える情報」「売り上げにつながる情報」というように、言葉に落としていくことが面白い。言語化できると、小さい一歩かもしれないけれども、前進できるから。

「答え」どころか「問い」もない仕事はなかなか珍しいですよね。コンサルティングファームにいた頃は、「中期経営戦略を立てたい」「営業組織を改善したい」「システムを高度化して工数を下げたい」というような、ある程度の方向性を持った「問い」があり、その中でゴールに向かってさらに細かく「問い」を立てていく仕事でした。

それに対して今は、「そもそも何をすべきか」を考えるところから始まります。それが、プロダクトの機能をつくることなのか、改善なのか、それともお客様の業務側を支援するのかなど、あらゆる方向性があり得るんです。「問い」そのものの幅がすごく広い。今は、コンサルタントとして顧客支援するだけでなく、生成AIのプロジェクトに関わったり、マーケティングチームと一緒にセミナーを実施したりと、いろいろな人とつながってさまざまな仕事をしています。

渡邊面白さでもあり、難しいところでもあるんですが、お客様からの要望にしても、我々から出た問い、仮説にしても、やろうと思えば全部できるんですね。もちろん「技術的に今はまだできない」というものもありますが、R&Dチームもエンジニアチームもすごく“強い”ので、時間とリソースさえあれば「何でもできるな」と思える。

このチームでは、そういう無限の可能性の中で、何をやるかを自分たちで取捨選択して、プロダクトの形にして、試すことができます。もちろん課題が明確でない中で“当てに行く”わけですから、思った通りには行かなかった、仮説が違っていたということもあります。でも、それも含めて僕は今の仕事を面白いと思いますね。

顕在化した課題を解決するソリューションは、世の中に多々あると思います。僕らはどちらかというと、まだ見えていない課題を探しに行って、言語化し、それを解決するソリューションを提供している会社です。だから、僕らがどんどん成長していくと、いよいよ見えていない課題もなくなって、誰もがストレスなく仕事できる世の中になっているのではないかと思っています。