Stockmark 採用ポータル/Unit紹介/Opendata チームのご紹介
page icon
Stockmark 採用ポータル/Unit紹介/Opendata チームのご紹介

Opendata チームのご紹介

世界中のビジネスデータを再構成しユーザーにインサイトを届ける

StockmarkのOpendata Unitについてご紹介します

🆕News

ハルシネーションを大幅抑止し専門的な質問にも正確な回答が可能な生成AI　ストックマーク 1,000億パラメータ規模の独自LLMを公開

💁プロダクト

サービス紹介

🗣
ストックマークのサービスは、日英中の3.5万サイトもの膨大な情報網から、自然言語処理を活用して、ニュース/ IR / 特許 / 論文 / 社内資料を解析し、最適な形で情報をお届けし、次世代のイノベーション創出＆アイデア創出の仕組みを提供し、新しくビジネスチャンスを発掘する支援を行っております。
Anews
ナレッジマネジメントSaaS
日々生まれる膨大な情報やニュースから、あなたの知るべきことを届け、組織の壁を越えて共有を可能に。事業を創るアイディアの種を見つけることができる、ナレッジシェア推進サービスです。
Astrategy
市場分析SaaS
国内外約3万5千サイトの膨大な情報から、AIが組織や業務に合わせて必要な情報を構造化し、新規事業開発や製品開発に必要な示唆を得られる市場調査サービスです。
 

導入実績

 

🎥Anewsのデモ動画（1分49秒）

Anewsのプロダクトデモ動画がありますので、こちらからご覧ください！

👨‍👨‍👧‍👦 組織

Opendataチームのご紹介

私たちストックマーク及びOpendata Unitが目指すのは、Web上のあらゆるビジネス情報を再整理し、ビジネスシーンでのデータ活用業務を自然言語処理AIで総置換することです。そのために、世界中のニュース、企業情報、論文、特許などをWebから収集、抽出、加工して顧客に提供し、企業の製品化・事業化を加速させられるような「オープンデータリサーチサービス」を開発しています。

Opendataチームの取り組み

💁‍♂️
  1. 数万オーダーのWebサイトから汎用的に新着情報を収集、抽出するWebクローラー全般の開発と運用
  1. HTMLやPDFからコンテンツを抽出するMLアプリケーションのプロトタイプ開発
  1. FaaS/CaaSによる分散処理のパフォーマンスチューニングと監視設計
  1. MLワークフローとデータプラットフォームの設計/運用

クローリングの仕組み

 
Stockmarkのプロダクトは、日々発生する膨大なビジネス記事(10万件以上)を常にクローリングし続けています。クローリング対象のURL群を起点として、短期間でURL群を巡回して記事を収集します。収集した記事は、必要なデータのみを取得するため、構造を解析し・余分な情報を削除します。大量の記事に対して、これらの処理を、短期間・低コストで実現するためにAWS Lambdaを利用したスケーラブルなアーキテクチャで実装しています。
ストックマークのアーキテクチャを動画にしました！
 
 

技術情報の拡充

 

ニュース／論文／特許情報などを抽出、配信するためのデータパイプラインを構築

 
 
 

今後のデータ拡充戦略

課題

①Webクローラーの劣化

②コンテンツ抽出のノイズが多い

③Web以外のデータソース拡充

💻技術スタック

💫
開発環境 [開発言語] Python
[コンテナ] Docker
[IaC] Terraform
[クラウド] AWS, GCP

💼ストックマークの働き方

ビジョンである顧客価値経営（カスタマーセントリック）を体現するために、個人の最大の権限を移譲し、自律分散型、そしてアジリティの高い組織へと進化しています。
 
🌈 働き方概要
制度名概要
【働き方】フレックスタイム制フレックスタイム制（コアタイム10:00-14:00）で自由に働くことができます。
【働き方】フルリモートフルリモート可能。関東圏外にお住まいの方も大歓迎です。
【働き方】副業OK副業として他社のプロジェクトに参画することができます。
【手当】リモートワーク準備一時金入社時にリモートワークを行うため必要な機材・備品の購入に充てて頂く手当です（入社時：50,000円）
【手当】顧客と向き合う手当顧客と向き合うために必要な書籍・備品・PC周辺機器購入のほか、セミナー受講費、コワーキングスペース利用費、有料記事購読費用、自己研鑽のための会食費用などに充てて頂くことを目的とした定額手当です。（年間240,000円）
リファラル採用インセンティブ社員紹介経由での採用決定で紹介者にインセンティブが発生します

募集要項

 
現在募集している職種は以下のとおりです。
 

🧑‍🤝‍🧑参考記事

 
Opendata TeamのインタビューやTech Blogをご紹介します！
 
［NEW］価値検証を高速化するために開発チームで意識していること（2023 / 7 / 3）
価値検証を高速化するために開発チームで意識していること
はじめに どのスタートアップ企業でも、プロダクトリリースサイクルの高速化・最適化を心がけているかと思います。本記事では、ストックマークのプロダクトであるAnewsの新機能（論文配信）を例にとって、ストックマークの開発の実際について紹介いたします。 本記事から学べる点は大きく3点です。 高速な価値提供を実現するために意識すべきこと フロー効率の極大化によりユーザー価値へつなげる方法 中期目線で開発速度を保つ方法 それでは、それぞれ個別に1つ見ていきましょう。 高速な価値提供を実現するために意識すべきこと どんなプロダクトであっても、実装しようとしている機能は、何らかの方法で検証してみるまで顧客にとって必要なものか分かりません。本記事のテーマである論文配信機能についても同様ですが、少なくともユーザーインタビューなどの仮説検証で一定のニーズは確認できていました。 ニーズまでは確認できているので、実際にミニマムな機能を提供することで、仮説検証を進めます。ミニマムといっても、開発着手時点で実装可能な候補がたくさんあります。その候補の中から、いかに何も作らずに仮説検証できるか、そのために仮説検証対象を削ぎ落としていくのが重要です。 今回はその実現のために、”最新データの追従” を最初は盛り込まずに検証する、というアプローチを取りました。こう書くと簡単なように見えますが、機能追加先のプロダクトであるAnewsは、毎日最新の情報を提供するプロダクトであるため、最新情報が届かないことはユーザーにとって違和感があるかもしれません。しかし、まずユーザーに価値があるかどうか判断するために、最新データを常に追従を当初から実装しないという意思決定をしています。（さらにいえば、最新データをどの程度の頻度で取得・更新すべきか、も検証する必要があります） 論文データを取得する方法もいくつかありますが、今回は SemanticScholarに決定しました。SemanticScholarは検索による科学文献のデータ提供および、APIにより2億件以上の論文を含む科学文献のデータを無料で取得可能な機能を提供しています。こちらの決定要因も、まず仮説検証が迅速にできることを重要視した点にあります。 このように、高速な価値提供を実現するために徹底的に価値の本質を見極めることを重視しています。 なお、SemanticScholar には公開されているスキーマが存在しません。今回調査した情報は弊社公開Notionページにまとめておりますので、参考にご活用ください。 フロー効率の極大化によりユーザー価値へつなげる方法 論文配信の提供を始めると実際にユーザーの行動ログやユーザーのフィードバックが集まり始めます。まず、当初の狙い通り、実際に論文が読まれることがまず検証できました。さらに利用ログを確認していると面白いことが1つ分かってきました。 それは、わずかしかない日本語の論文が想定されるより優先して読まれているということです。SemanticScholar は日本語の論文に注力しているわけではないため、全論文量の2%程度しか日本語論文が含まれていません。その日本語論文が読まれやすいことがわかったわけです。 この知見をもとに、日本語論文の強化を検討しはじめます。今回は、国立情報学研究所が提供する CiNii について、CEOの林がコメントしたのをきっかけに、CiNiiのデータ取り込み・論文提供まで1ヶ月弱で実現しました。 この裏側で意図していたのがフロー効率重視の考えです。本機能の価値が高いと判断したため、他の機能開発のし掛かりを並行して進めるのではなくむしろ止めて、国内論文の拡充に集中して開発を進めました。 ちなみに、こちらの機能提供により、論文の閲覧数が5倍以上に増加しており高いニーズがあったことが確認できています。 論文閲覧数のグラフ 中期目線で開発速度を保つ方法 ある程度の開発経験のあるエンジニアであれば、よほど大きな機能でない限り、1人で作り切ってしまった方が早いことがあります。今回の論文配信機能の開発裏側では、まさに開発メンバー1人で実装を進めていました。 一方で、1人で開発を進めていると中長期的に見て開発速度が落ちていくリスクがあります。たとえば、開発メンバーが体調不良になった場合、そのメンバーが回復するまでに開発が止まりかねません。 そこで、論文配信の機能が継続的に提供されるとわかった段階で、徐々にプロダクト開発に携わるメンバーを増やすように進めてきました。具体的には、新しい機能については、別の開発メンバーと共同で開発するようにします。 そのため、別の開発メンバーが参加しやすいように、「背景」を重点的にドキュメントに起こしておきます。機能や処理に関してであれば、ソースコードから一定理解できます。一方で、その実装に至っている背景については、コメントに手厚く書いておかない限りソースコードからは読み取れません。ドキュメントに背景を残しておくと、長期的に開発速度が落ちにくくなります また、今回の実装では全体のインフラ構成も複雑であったため、事前に鳥瞰図を準備しておきました。2023/6時点の設計・実装はやや異なりますが、当時準備していたものを参考までに掲載いたします。 当時のインフラ構成 これらの準備によって、途中から開発に参加する場合であってもスムースに入れたようです。 まとめ 本記事では、ストックマークの開発で意識していることを重点的に紹介しました。ユーザーに価値をいかに早く届けられるか、そして中期目線で開発速度を落とさないための取り組みを紹介しました。 本記事では技術的な詳細はそこまで触れておりませんが、 もしご興味あれば是非カジュアル面談でお話させてください。こちらより気軽にお問い合わせください！
https://tech.stockmark.co.jp/blog/what-dev-teams-have-in-mind/
【記事まとめ】ストックマークでエンジニアとして働く魅力10選！
ビジネスに必要な情報を世界中から集めるクローリングの仕組みと今後の課題

📚その他関連資料

もしよろしければこちらもご覧ください！

Stockmark　採用ポータル

採用に関する情報がほぼ全て入っています！
 

Stockmark YouTubeチャンネル

CEO林やCTO有馬 インタビュー動画、オープン社内報などを公開しています！
 
 

ストックマーク　テックブログ
エンジニアチームの技術ブログです！

Xでポスト