プロダクトマネージャー向け野良ダッシュボードの活用方法

はじめに

10X在籍4年目、プロダクトマネージャーの@ysk_urです。 この記事は10Xアドベントカレンダー2024の12日目の記事です。

プロダクトマネージャーとして、機能をリリースした直後（翌日）や、企画案を検討しているときなどに直接データをいじって確認したくなる瞬間が多々あります。 データ基盤チームが提供している公式のダッシュボードだけでは見えない視点を補い素早く意思決定に活かすため、最近は「野良ダッシュボード」を量産するようになりました。

この記事では、具体的な取り組みとその成果についてご紹介します。

なぜ野良ダッシュボードを作ったのか？

10Xには既にデータ基盤チームが提供する素晴らしい公式ダッシュボードがあります。ただ、それでは追えない先行指標や、プロダクトマネージャーとして独自の視点で見たいデータがあり、自分で手を動かして作ることにしました。

また、データ基盤チームとは定期的にプロダクト分析の定例を設けており、ストックされた分析レポートも増えてきてQueryを書くための学習コストが下がっていることもあり、自分でやるのも大変じゃない状況になっていました。

特に以下のような理由から、自分で作っちゃうかと思って始めました。

1. 先行指標へのアクセス
   • 遅行指標中心の公式ダッシュボードでは捉えきれない、機能導入直後の動向や改善箇所を把握したい。
2. 個別機能の評価
   • 私自身の関与する領域が増え、視点が広がったことで、改めて特定機能にフォーカスして評価する必要性が高まった。
3. クイックな確認の必要性
   • 素早い意思決定を求められる場面で、自分の視点に合わせた即応的なデータ確認が求められた。
4. 新しい仮説の検証
   • 仮説を立てた際に、事前に必要なデータを素早く抽出し、検証プロセスを効率化したかった。

どうやって野良ダッシュボードを作ったのか？

使っているツールはもっぱらLooker stuidoかGoogle スプレッドシートです。野良なので捨ててもいいや、くらいの気持ちで作ってます。抽出したデータを加工してグラフにするなどのExcelとかスプシ操作が得意な人はスプレッドシートでもいいんじゃないかなと思います。

Looker Studioは、10Xでデータエンジニアをしている吉田さんが使い方を説明してくれたおかげで虜になりました。たくさん詰め込むとちょっと遅くなるけど便利です。社内ではこのブログよりもっと色々教えてくれました。

10Xではデータ基盤チームがmartを整備してくれているので比較的分析は容易になっています。

ただ今回はログのテーブルにQueryを投げることが多かったので、過去の分析レポートで蓄積されたQuery等を流用して作成していきました。

作ったダッシュボードの一部紹介

1.特に役に立ったものたち

顧客体験系

• 検索機能の利用状況
  • 検索クエリの数、成功率、クリック率の可視化。
• 推薦機能の効果測定
  • 表示された推薦商品のクリック率、購入率のトラッキング。
  • 商品詳細、レジ前推薦、欠品時の類似商品、関連カテゴリ、関連キーワードなどかなり多くの推薦機能が導入済み。

関連キーワード・関連カテゴリ

代わりの商品

生産性・店舗分類系

• 店舗分類のダッシュボード
  • 満便率、ピックパック速度、作業時間比率などの実績値を一定の基準を決めと比較し、良し悪しを判断できる状況とし、課題ごとに店舗を分類。
  • 発散していた改善アイデアを指標ごとに分類し、課題ごとに分類した店舗数に対して大通りに効くアイデアなのかを判断可能とした。

    

    店舗分類

2.ちょっと役に立ったものたち

ABテストモニタリング

• 推薦機能のABテスト結果
  • テストグループごとのクリック率や購入率を比較し、機能改善の評価を実施。
  • このモニタリング方法は、他のプロダクトマネージャーが丸パクリして利用中。
  • デイリーの変動を見ても最終的な評価の場合はサンプル数の観点とかで違う方法を取るケースもあるのでこのモニタリングは雰囲気を掴む程度のもの。

    

    ABテストモニタリング

新機能モニタリング

• 領収書どのくらい発行されてるのか？
• 欠品商品の推薦利用状況はどのくらいか？
• 関連カテゴリ、関連キーワードはどのくらい利用されているのか？ etc

具体的に役に立った事例

欠品商品の推薦機能のダッシュボードについての紹介です。 ネットスーパーの顧客体験向上を目指し、欠品商品に対して代わりとなる商品を推薦する機能を開発しました。この機能は「お気に入り商品」や「いつも買う商品」で欠品が発生した際、代替候補を提示する仕組みです。

今期は商品探索の行き止まりを消すための機能開発を複数進めていたのでその中の1つです。1つ1つは小さいインパクトですが合計で5~6個ほど新機能を提供したのでトータルの体験として以前より商品を探す体験がスムーズになったかなと想像してます。

「商品探索の行き止まり」とは、商品リストの最下部に達した時だったり、商品が欠品している場合などを指します。

評価と結果

ダッシュボードで分析を進めた結果、利用率は想定より低いことが判明しました。あまり使われていないことの仮説としては下記のようなものです。

• 欠品そのものが少ないため、推薦機能が使われる機会が少ない。
• 「ナスの代わりは？」のように代替品が存在しない商品もある。

この分析から、現時点ではアルゴリズム改善には積極的なリソースを割かない判断をしました。さらに、初期のアルゴリズムは他で導入済みのものを流用していたため、低コストで機能提供できたのもポイントです。

得られた学び

この取り組みを通じて、次のような重要なインサイトが得られました。

• 欠品時の「行き止まり体験」を一定程度解消できた。
• ネットスーパーの特性上、代替が効かない商品もありそれはアルゴリズムでは解消が不可能。
• 機能の利用率や影響を定量的に捉え、改善や廃止を含めた柔軟な意思決定が可能になった。

新機能を出したけど何もされないまま放置みたいなことはたまにあると思いますが、今回は意思を持って現時点では積極的な改善をしない結論を出しています。

さいごに

自由にダッシュボードを作ってみたのですが、プロダクトマネージャーとしては2つの視点で野良ダッシュボードの価値を説明できるなと思っています。

1. そもそもどのくらい使われているのか？を知ることからはじめること自体に価値がある
   • 客観的指標を元に大通りかどうかを認識することで改善のコストを下げる（やらない判断が容易になる）
2. アイデアを評価するための客観的な基準の策定からはじめる
   • 大きなテーマに対して直接的な改善アイデアが出たり、逆にかなり細かい点に対して改善アイデアが出たりするとその期待効果が判断つかない場合がある
   • 一定の定義で作った分類を用いることで、全体の何%に該当するアイデアなのかを評価できる

なお、野良ダッシュボードをもとに公式のダッシュボードへの追加検討の相談も進んでいます。また、プロダクトマネージャーが書くQueryは心配な側面もあるのでそのあたりはデータアナリストやデータ作ってる開発チームの人に相談するようにしました。

是非皆さんも野良ダッシュボード作ってみるところからはじめてみてはどうでしょうか。QueryはLLMに相談すると良いですよ。 あと、このブログもLLMに相談して70%くらい書いてもらいました。

明日は、ソントプさんの記事です、お楽しみに！

アーキテクチャの限界を漸進的に押し上げる取り組み

10X在籍8年目、取締役CTOのishkawaです。

この記事は10Xアドベントカレンダー2024の3日目の記事です。

---

メイン事業であるStailerは現在5年目です。

自分はプロダクト開発を統括する立場として、プロダクト戦略立てたり、開発プロセスの整備の旗振りをしたり、開発体制を調整したり、採用活動に奔走したりと、色々な取り組みをしてきました。そして今、何に注力しているかというと、コードの立て直しです。

なぜコードの立て直し？

プロダクトを5年くらい開発していると、開発速度は当初と比べて落ち着いてきます。その要因は色々あると思いますが、自分は「事業やプロダクトのフェーズの変化による規模や複雑度の変化」と「規模や複雑度に対する技術的な適応度」の2点に着目しました。

前者はプロダクトマネジメントのトピックです。Stailerでは、自分たちが持つ強み、組織の規模、得られる事業成果、運用にかかるコストなどを考えて、自分たちは何をやって何をやらないのかという指針を策定してきました。すべてが想定通りになった訳ではないですが、パートナー企業のネットスーパー/ネットドラッグ事業の成長を支えつつ、10Xとしても十分に開発と運用ができる形にできたと思います。

後者はエンジニアリングのトピックです。事業やプロダクトのフェーズの変化に伴って、システムの規模や複雑度が変化します。10Xの開発組織でもこの変化に対処する取り組みは続けており、この1-2年は保守性を最重要なものとして掲げ続けていますが、十分に追いついているとは言い切れない状況です。規模や複雑度に追いついていないというのは、技術的な要因によって開発を速くできていない、運用を楽にできていないといった状況を見て、そのように捉えています。

翻って経営の帽子で考えると、ネットスーパー/ネットドラッグ事業はもっと早く成長させたいし、新規領域への投資も拡げたいという状況です。その実現に向けて最初に対処しなければならないのが技術的課題なので、それに取り組み始めたという訳です。

後になってから壁に当たるのは何故か

最初は速くて後から遅くなったという状況ですが、これは後から入ったコードが特に悪いという訳ではなく、ある程度の規模や複雑度に達すると遅くならざるを得ない構造に最初からなっていたと分かりました。つまり、アーキテクチャが劣化したのではなく、アーキテクチャの限界に達したということです。

最初からもっと上手くやれたら良かったと思いますし、限界の到達を遅らせる余地はあったと思い当たる節はいくつもあるのですが、今のプロダクトは今の実装で社会に価値を生み出しています。悔やむだけではアーキテクチャが改善されることもないので、これからの規模や複雑度を見据えて、どうやってなりたい状態に近づけるかを今は考えています。

アーキテクチャの限界を漸進的に押し上げる

以下の手順を繰り返して、やっていこうとしています。

• 欲しい特性を狙ってアーキテクチャ決定を積み重ねる: 現状のStailerの開発には規定が少なく、自由度が高い状態にある。組織にとって望ましい特性がこのまま自然発生する訳もないので、今の組織に必要な特性は何か特定し、その特性を得られそうなアーキテクチャ決定を積み重ねる。
• ADRでアーキテクチャ決定の意図を明確にする: アーキテクチャ決定は意図を持ってなされるが、その意図が正しく認識されないと、決定自体が無視されたり、不健全な形でバイパスされることがある。とはいえ、当該のアーキテクチャ決定を理解しなければならないタイミングは人によって異なるので、誰もがその決定を追えるようにするためにADR(Architecture Decision Record)を残す。
• linterでADRに辿り着けるようにする: ADRがあったとしても、メンバーがその存在に気付けなければ意味がない。適切なタイミングでメンバーが気付けるようにするため、ADRの決定に反するコードを検知するlinterをADRとセットで実装する。
• ADRへの違反状況を可視化して漸進的に適応度を上げる: ADR + linterの作成時に、すべての既存コードをアーキテクチャ決定に沿わせることは難しいので、当初は違反箇所をlintの対象から除外することを許容する。lintの除外数はADRへの適応度を表すので、それを可視化して漸進的に適応度を上げていって、最終的に得たかった特性が広く得られるようにする。

linterによる検知はエディタ上では、以下のスクリーンショットのようになります。

「データレイヤーをUIレイヤーに依存させない」という決定への違反を検知してエディタ上のエラーとし、具体的に何が違反なのか、違反をどのように解消して欲しいかを表示しています。ルール名のところをクリックするとADRが表示され、どういう背景で「データレイヤーをUIレイヤーに依存させない」という決定をしたのか知ることができます。

この仕組みはDartのcustom_lintを使っていて、以下のように簡単に実現できます。

class NoUiLayerImportFromDataLayer extends DartLintRule {
  static const _code = LintCode(
      name: 'no_ui_layer_import_from_data_layer',
      problemMessage: 'データレイヤーからUIレイヤーのファイルはインポートできません。',
      errorSeverity: ErrorSeverity.ERROR,
      url: 'https://example.com/path/to/adr');

  @override
  List<String> get filesToAnalyze => const ['/**/data/**.dart'];

  @override
  void run(
    CustomLintResolver resolver,
    ErrorReporter reporter,
    CustomLintContext context,
  ) {
    context.registry.addImportDirective((node) {
      final uri = node.uri.stringValue;
      if (uri != null && uri.contains('/ui/')) {
        reporter.reportErrorForNode(code, node);
      }
    });
  }
}

平凡な決定も浸透させて価値を高める

アーキテクチャ決定という大層な雰囲気ですが、実際には平凡なものです。例えば、「レイヤーAはレイヤーBに依存させない」とか、「Xという責務はレイヤーAに位置付ける」とか、「レイヤーBのオブジェクトはimmutableでなければならない」とか、そういうものです。

1つ1つが平凡な決定であっても、ある程度以上の規模のコードベースではそれが浸透していることが大きな価値になります。自分自身、これを体感し始めたという段階ではありますが、浸透が進めばもっと上手く開発やテストができるようになりそうだという期待感もあります。

意気込み

今あらためてエンジニアリングにコミットすることで、会社がネットスーパー/ネットドラッグ事業をより早く成長させ、新規領域への投資も拡げられる状態を作りたいと意気込んでいます。

10Xではソフトウェアエンジニアも募集しているので、面白そうだなと思った方は、ぜひ採用ページもご覧ください。カジュアル面談のURLも用意したので、まずは話を聞いてみたいという方はそちらもどうぞ。

• 採用ページ: https://open.talentio.com/r/1/c/10x/pages/97170
• カジュアル面談: https://calendar.app.google/z7AfzeyfradAYXci7

---

明日はビジネス本部の鈴木さんが記事を公開する予定です。お楽しみに！

10Xのプロダクトデザインの近況と、プロダクトデザイナー募集のお知らせ

10X プロダクトデザイナーの日比谷（ @suuminbot ）です。

10Xではしばらくプロダクトデザイナーの新規募集をクローズしていましたが、この度新たにプロダクトデザイナーを募集することになりました！

しばらく外部発信できていなかったこともあり、この記事では最近のStailer、そして10Xでのデザインの近況についてまとめようと思います。

TL;DR

• Stailerのプロダクト開発はフェーズが変わり、新たなイシューを探索できるようになった
• Stailerの「価値の源泉」の1つはやはりUXにある
• 実は新規プロダクトも複数開発している
• デザイナーの専門性を持って「良いUX」を作るためのプロセスをリードする方を募集する
• 少しでも興味がある・もっと詳細を知りたい方はカジュアル面談しましょう！

…ということで興味がある方はぜひこのあともご覧ください！

プロダクトビジョンとプロダクト指針の作成

こんにちは、10Xでプロダクトマネージャーをしている@ysk_urです。社内のみんなの頭の中ではだいたい同じものを見ていたと思うのですが、改めてプロダクトビジョンとプロダクト指針を作成した話を今回は書こうと思います。

個人的には、「直接の顧客はtoBだけどtoCの生活をより便利に」、「ネットスーパーの歴史的経緯からの制約の設定」、「継続的なアップデートが必要」などのポイントが気に入ってます。

プロダクトビジョンとプロダクト指針作成の背景

会社の活動サイクルが全社戦略によりフォーカスして活動を行う形に変化したことに合わせて、戦略と紐づけた形で「プロダクトの目指すべき姿」を明確に定義する必要があると感じました。
また、過去の取り組みを振り返ると今回改めて書いたプロダクトビジョン達成のための活動自体は行われていましたが、中長期で十分に達成できるかという視点が弱いという課題もありました。
プロダクトビジョンを明確にすることで、社員がプロダクトの方向性を理解し、集中して取り組める環境を作りたいという狙いです。ロードマップが単なる施策リストになってしまわないように、また、社員がビジョンに基づいて自主的に動き出せるよう、以下のようなポイントを意識しました。

• 方向性の明示：「どこを目指しているのか」を明らかにすることで、社員が戦略を理解し、やらされ感を持たないようにしたい。
• 予見できる機会への準備：市場の機会が到来した際に迅速に対応できるよう、ビジョンを基盤に考えを整理し、準備を整える。
• ユニークな存在意義の提示：単なる事業利益や時価総額の達成ではなく、「なぜ私たちが小売業界に向き合い、ネットスーパー/ネットドラッグストアを支援するのか」という意義を共有し、社員のモチベーションを高めたい。

こうした背景から、社内で既にあった考えやドキュメントをベースに、CTOとプロダクト本部付のメンバーで議論を重ね、具体的なビジョンを作成していきました。

プロダクトビジョン・プロダクト指針の作成プロセス

プロダクトビジョンの作成は、社内で既にあった考えやドキュメントをベースにスタートしました。

議論の中では、顧客は誰なのか？最終的に実現したい世の中はどういったものなのか？などで議論が白熱しました。また、ネットスーパーの歴史的経緯や市場環境から、プラットフォームとして取り組むことの意義などが議論され、結果として制約が改めて言語化されていきました。

プロダクトビジョン策定における議論の広がりや複雑さを振り返ると、BtoBtoCビジネスの難しさを表していると思います。直接の顧客は小売企業ではあるが、実現したいことは人々の日常の買い物を便利にすることであり、間接的に実現したいことを達成する必要があります。10Xのコーポレートサイトにでかでかと載っている「1人の難題を巨大な市場から解く。」をまさに取り組んでいるなと改めて実感しました。

また、プロダクトビジョンを達成するためには、Stailerが多くのパートナーを迎え入れてもソフトウェアが健全な状態を維持し、開発速度を落としたり、必要以上の保守運用コストをかけてはいけないことも改めて見えてきました。 そういった経緯から、プロダクトビジョンだけでなく、プロダクト指針も作成することになりました。

複数回の議論を踏まえ、最終的に以下のプロダクトビジョンとプロダクト指針を策定しました。最終的にプロダクトビジョンとプロダクト指針という構造に整理されていますが、ここも紆余曲折がありこの形に着地してます。構造から入るとうまくいかなかったと思うので必要な要素を構造化した形になります。

実際に作成したプロダクトビジョンとプロダクト方針の一部

一部抜粋して記載しています。詳細や全体像を知りたい方はぜひお声がけください。

プロダクトビジョン

「小売企業がネットスーパーやドラッグストア事業を持続的に運営できる手段を提供し、人々の日常の買い物を便利にする。」

補足

プロダクト指針

プロダクトビジョンを実現するために、以下のプロダクト指針を定義しました。中長期でStailerの価値を高めていくための制約になります。実装方法以外にも提供価値も定義していますが、ここでは実装方法の制約の一部を紹介します。

プロダクトが提供する価値

お客様

• オンラインならではの利便性: 店舗への移動や運搬からの解放、検索や推薦による効率的な購買など、オンライン前提ならではの利便性を強化する。

小売企業

• 正確で効率的な業務遂行: オペレーションのミスや非効率が生じにくい業務支援ツールを提供し、NS/NDgSの運営にかかるコストを抑制する。

実装方法の制約

プロダクトの機能

• 全企業共通の仕様: 機能の仕様は汎用的に設計し、すべての小売企業のNS/NDgSで共通の実装をする。
• カスタマイズは小売企業側で完結: サービスの設定、特定の機能の有効化といったカスタマイズは、管理画面を通じて小売企業側で完結して行えるようにする。

システム連携

• 事業運営に必要なシステム連携の完備 : 小売企業のシステムが必要とする連携のインターフェースを揃えており、小売企業がシステムを適合させ次第、事業を開始できる。
• 企業個別の実装の分離: ビジネス上の都合によって企業個別の実装を作らざるを得ない場合、プラットフォームの実装には混ぜ込まずに分離する。

プロダクトビジョンの社内反応と今後の課題

プロダクトビジョン策定後、社内で共有を行った結果として戦略として掲げて進めている施策が複数あります。 特に実装方法の制約に関してはPMFフェーズを超えてスケールを目指す上では重要な取り組みとなっており、現在の実装を見直し改善に向けた取り組みが実際に進んでいます。 Stailerはプロダクトの機能が非常に多いのですが、カスタマイズや設定等が必要な機能を適宜小売企業側で完結できる形に実装が進んでます。

実現方法を変えることでのメリットとデメリットはプロダクト本部のメンバーだけでなくビジネス本部のメンバーにも十分に理解してもらい、中長期でプロダクトビジョン達成に一定の目線があってる状態を作ることができています。

一方でまだまだ社員全体への浸透は十分とはいえない状況だと思っています。ベースとなるものがあったのもあり、作成プロセスに多くのメンバーを巻き込んだわけではなかったり、言語として洗練されていないことで浸透が弱いと思っています。より浸透を図るための取り組みが今後の課題と感じています。

また、1年前に同じ状態のアウトプットが作れたと言うと高い確率で違うものになったと思います。事業を進める中で得られる知見の反映も必要なので、今後も継続的なアップデートを前提としています。

trufflehogを活用したGitHub Organizationのcredentialsスキャン

こんにちは、セキュリティチームの@sota1235です。

突然ですが、ソフトウェアエンジニアの皆さんに質問です。他者に漏らしてはいけないAPI keyやSSHのprivate keyを誤ってGitHubにpushしてしまったことはありますか？私はあります。*1

日々、スピード感を持ってものづくりに臨んでいく中で本当はcommitしてはいけないものを間違ってcommitしたり、それに気づかずにGitHubにpushしてしまうなんてことは人間がミスをする生き物である以上、誰にでも起きえる事故です。

今回はそんな事故を検知するのにtrufflehogを活用しているお話をします。

なお今回は事故を未然に予防する話には触れません。

github.com

*1:かなり昔の話ですし、もちろんrevoke済みです

10X の推薦を作るチームと ML platform

10X ソフトウェアエンジニアの @metalunk です。ネットスーパー、ネットドラッグストアのプラットフォームである Stailer 事業で、機械学習（ML）と検索を専門として働いています。

2024年4月からいま（2024年8月）までの5ヶ月間で6つの推薦機能をリリースできました。この成果を支えたのはチームと ML platform（機械学習の基盤システム）です。このブログではチームの取り組み、ML platform の機能、および具体的な成果についてご紹介します。

このブログは技術ブログの体ではありますが、さまざまな業界、職種の方に読んでいただくことを目指して執筆しました。

(3) 章, (5) 章だけは機械学習に取り組んでいる人向けの内容を含みますので興味のない方は読み飛ばしてもらって結構です（機械学習に取り組んでいなくても興味のある方はぜひ読んでください）が、それ以外は IT 業界のみならず小売業界の方にも読んでいただけると思います。

(1) 5ヶ月間の成果

はじめに、この5ヶ月間で上げた成果を列挙します（つかみです。詳しくは (4) 章で取り上げます）

1. レジ前推薦でパーソナライズモデルをリリースし、レジ前推薦の売り上げ 10x（カート追加率 3.2x, カート追加点数 2x, 単価 1.6x）
2. 関連商品推薦のあたらしいモデルをリリースし、カート追加率 3x
3. セレンディピティの高い、一緒にどうぞ推薦をリリース
4. 次の検索キーワード推薦のリリース
5. 人気順をリリースし、もっともカート追加率が高い並び順に
6. 代替商品推薦のリリース

これで推薦枠は、レジ前推薦、ランキング、商品詳細、次の検索キーワード推薦、代替商品推薦の5箇所になりました。

そして、これらの成果は、2024年4月に始動したお客さま体験チームによって生み出されました。

GitHubで扱うPersonal access tokenの利用方法をセキュアにする

こんにちは、セキュリティチームの@sota1235です。

セキュリティチームでは昨年の夏頃からGitHub上のセキュリティリスクを洗い出し、順に対応や改善を行っています。

そのうちの1つとして、昨年の秋ごろからGitHubのPersonal Access Tokenの取り扱いの改善を行ってきました。

具体的には以下の取り組みを行いました。

• CI等で利用されているPersonal Access Tokenの利用廃止
• OrganizationにおけるPersonal Access Token(classic)の利用禁止設定

今回はこの2つの取り組みについて、どのような課題設定を行い、どんな手順で完了したのかをお話しします。

以下のような課題感、疑問をお持ちの方に対する1つの回答になりうると思うので該当する方はぜひご一読ください🙏

• GitHubにおけるPersonal Access Tokenとどう付き合うべきかの解像度が低い
• Personal Access Tokenにまつわるセキュリティ上の対策が知りたい