プロダクトマネージャーに商売センスが必要な理由と磨き方

こんにちは。エンジニアリンググループ プロダクト支援チームでPdMをしている中村です。この記事はエムスリー Advent Calendar 2025の19日目の記事です。 18日目は山本さんの「Google Cloud コンテナイメージの脆弱性スキャンを自作 OSS で運用する」でした。

画像はGeminiで生成しました。

はじめに

PdMにとって、担当プロダクトをいかに成長させるかは永遠のテーマであり、最も頭を悩ませる部分ではないでしょうか。私も日々、試行錯誤しながらプロダクトを成長させるための課題解決や新しいアイデアを考えています。そのような中で、CPO山崎に相談すると、議論の核心としてしばしば「商売センス」というキーワードが登場します。 また、社内のPdMが集まるPdM定例でも、商売センスというキーワードは頻繁に話題に上ります。

「プロダクトマネジメント」と「商売センス」。 一見すると距離がありそうなこの2つの言葉ですが、実は切っても切り離せない、PdMにとって非常に重要なスキルだと感じています。特にエムスリー社内で定義されているレベル3のPdM*1を目指すうえでは不可欠なスキルです。

今回は、なぜPdMにとって商売センスがそれほどまでに重要なのか、そしてそのセンスはどうすれば磨くことができるのかについて、私なりの考えと学びを共有します。

*1:ここでは、年間利益 50~100 億を作れるレベルのPdMを指します。詳しくは次の記事をご参照ください。

www.m3tech.blog

Google Cloud コンテナイメージの脆弱性スキャンを自作 OSS で運用する

こんにちは、AI・機械学習チームの山本（@hiro_o918）です。 この記事はエムスリー Advent Calendar 2025 18 日目の記事になります。 17 日目は北川さんの「わたしの Language Server にはパーサーが２種類あんねん」でした。

はじめに

皆さんは脆弱性の検知と対応をどのように行っていますか？

エムスリーでは脆弱性管理ツールを導入することで、コンテナイメージやパッケージの脆弱性スキャンを自動化し、検知された脆弱性への対応をチーム全体で協力して行っています。 しかし、次の記事にもあるように AI チームでは次々にプロダクトを立ち上げているため、スキャン対象の管理など運用コストが増大してしまう課題がありました。

そこで今回は、Google Cloud の Artifact Registry に組み込まれたスキャン機能の利点を最大限に活用し、さらに自作の OSS ツールで運用することで、運用コストを抑えつつ効率的に脆弱性管理と修正プロセスを進められるようになった話を紹介します*1。

*1:ところで、以前まで Google Container Registry と呼ばれていたサービスは 2025 年 3 月 18 日をもって廃止となり、Artifact Registry に統合されました

わたしのLanguage Serverにはパーサーが２種類あんねん

AI・機械学習チームの北川です。 この記事はエムスリー Advent Calendar 2025の17日目の記事です。 16日目は須藤さんのAIに正しく分析してもらうためのテーブル設計戦略でした。

猫も２種類に増えました。猫もそれぞれ性格が違ってそれぞれの良さがありますよねー

はじめに

以前、BigQuery用のLanguage Server(bqls)を自作した話を書きました。 このbqlsは、GoogleのzetasqlをベースにしたBigQuery専用のLSPで、Web UIでは遅く感じていた補完をNeovimなどのエディタで快適に使えるようにしたものです。

github.com

zetasqlの強みは、SQLをパースするだけでなく、カラムの型情報なども一緒に提供してくれる点にあります。 しかし、運用していく中で大きな課題が見えてきました。 それは、SQLにバグがあるとパースできないという点です。

LSPで補完などのリクエストが来る時、たいていそのコードは「壊れています」。 例えば補完を出したいタイミングはユーザーがコードを書いている途中です。 つまり文法的には壊れた状態であることがほとんどです。 前回のブログでは漸次的修正という手法でこの問題に対処しましたが、それでも限界がありました。

この記事では、そんな課題を解決するために導入したtree-sitterと、zetasqlとの適材適所な使い分けについて紹介します。

AIに正しく分析してもらうためのテーブル設計戦略

この記事はエムスリー Advent Calendar 2025 16日目の記事です。

こんにちは、AI・機械学習チームの須藤です。

現在は、BigQuery上のデータを自然言語で分析できる社内向けプロダクトを開発しています。本記事では、AIに正しくデータを分析してもらうために工夫したテーブル設計戦略について紹介します。

実用 Algebraic Effects and Handlers ~本番環境で OCaml を利用するために~

記事のイメージ画像を gemini に生成させたもの

本記事はエムスリー Advent Calendar 2025 15 日目の記事です。

OCaml が好きです。

元々好きでしたが、バージョン 5 からはマルチコア対応が入り、更に好きな要素が増えました。

それは前回も紹介した Algebraic Effects and Handlers という新機能です。

新しい機能はそれだけで心躍るものですが、使い方が十分周知されていないのも事実です。

「なんでもできる」と前回紹介した通り、今回はこのなんでもできる機能が実用的な機能であることを見ていきます。

「継続」は力なり - 継続を知り、Promiseの限界を超え、Effect Systemへ

本記事は、M3 Advent Calendar 2025 14日目の記事です。

はじめまして。エンジニアグループ、コンシューマーチームの松本と申します。

今回は、「継続 - Continuation」の本質を理解し、Promiseやasync/awaitでは解決できない課題を明らかにした上で、それを乗り越えるEffect Systemについて解説します。

アジャイル開発で準備した五目並べAI対戦イベントが盛り上がった話

こんにちは。エムスリーのAI・機械学習チームの高田です。 このブログはエムスリー Advent Calendar 2025 13 日目の記事です。

AI・機械学習チームはメンバーが福岡から北海道まで、様々な地域のメンバーから構成されています。そこで、チームビルディングデーと称して、オフラインの交流も四半期に一度のペースでチーム全員で集まって様々なイベントを開催しています。

今年の3月に機械学習コンペを開催した際のレポートもテックブログで紹介しているので、ぜひご覧ください。 www.m3tech.blog

このブログでは、2025年10月31日に開催した「五目並べAIチーム最強決定戦」について、チームビルディングイベントの当日の様子と、当日の進行のためにアジャイル的に開発を進めた舞台裏をお話します。

TL;DR

• AI・機械学習チームのチームビルディングイベントとして「五目並べAI対戦」を開催したよ
• 当日は4チームが2時間でAIを実装し、トーナメント形式で対戦。会場は盛り上がり、各チームが自然と協力体制を築いていたよ
• 当日までの準備として、アジャイル的に「まず動くもの」を作り、段階的に機能を積み重ねていく開発は良いアプローチだったよ

はじめに - なぜ五目並べAI対戦なのか

チームビルディングイベントというメンバー間のコミュニケーションを促すコンテンツとして「ゲームAI対戦」を企画しました。

• 自然な協力体制: 2時間という制限時間の中で、チームメンバーが自然と役割分担し協力する
• 技術的な議論が活発に: 探索アルゴリズムや評価関数など、普段とは違う技術トピックで盛り上がる
• 勝敗がある楽しさ: 「勝ちたい」という気持ちが自然とチームの一体感を生む

ゲームの題材としては、シンプルながらも戦略性や実装の難易度が1日のイベントとしては適度な「五目並べ」を採用しました。 五目並べには禁じ手というルール（置けない位置に石を置くと即失格）があるものの、複雑すぎず、ルールを考慮した実装に取り組むには丁度よい題材のボードゲームだったためです。