はてなブックマーク

この記事は10X 新春ブログリレー 2026の1月22日分の記事です。 ドメインベースの開発体制から3年 10Xの開発チームがドメインベースの開発体制へ移行してから、約3年が経過しました。 product.10x.co.jp 改めて当時と比較してみると、認知負荷の増大やオーナーシップの欠如といった課題は大きく改善したと感じています。もちろん新たな課題や難しさもありますが、ドメインベースへの移行自体は、総じて進めてよかったなと言い切れる試みでした。 この記事では、そんなドメインベースの体制の「チームの境界」という点にフォーカスして体制移行時にどのように初期的な境界を決めたのか、そしてこの3年間でその境界をどう見直してきたのかについてお話をしてみようと思います。 初期的な境界の決め方 初期のチーム境界と担当ドメインは、以下のような手順で定義しました（実際には1〜4がスムーズに進んだというよりは

conftest は、Open Policy Agent (OPA) の Rego 言語を使って、構造化データ（YAML、JSON、Terraform、Dockerfile など）に対するポリシーテストを実行するCLIツールです。 よくあるユースケースとして、Kubernetes マニフェストや Terraform の設定ファイルに対して「コンテナは root で実行してはいけない」「すべてのリソースにタグが必要」といったルールの適用です。これらのルールを組織ポリシーとして定義して、それに適合しているかをconftestで検査できます。conftestをCIに組み込めば、PRに含まれた変更が問題ないかどうかを機械的にチェックできるというわけです。 これまでの10Xでも、Regoを書きconftestを使って検査してきていましたが、Rego言語のとっつきにくさ/学習コストの高さがネックでポリ

この記事は10X 新春ブログリレー 2026の1月5日分の記事です。 弊社が提供するネットスーパーのサービスは、モバイルアプリとWebはFlutterアプリ、バックエンドはDartのgRPCサーバーで実装されています。isomorphicではないですが、言語統一がされたフルスタック的な状態と言えると思います。 バックエンドでのDartはマイナーであり、それに伴って様々なデメリットもありました。それらを乗り越えたり飲み込んだりしながら、5年ほどサービスを運用してきましたが、これから先は方針を転換することに決めました。 この記事では、我々が何故フルスタックDartから方針転換することにしたのかと、今後のバックエンドの言語としてRustが有力になっている背景を説明します。 方針転換のきっかけは採用 バックエンドのDartでは様々な問題にぶつかってきましたが、どれも方針転換に踏み切るほどにはならず

10X の CX (Cool Experience) チームの @metalunk です！ この度、CX チームのバックエンドエンジニアの求人をはじめました。 バックエンドエンジニア（検索、推薦） / 株式会社10X このブログは当ポジションの魅力を紹介するための文章です。 その中で、CX チームがこれまで上げてきた成果、それらの成果を上げられた理由、いま抱えている問題、それを解決した先に目指していること、をお伝えできたらと思います。 CX チームとは CX (Cool Experience) チームは、検索、推薦、MLOps、数理最適化の技術的専門性を活かしてさまざまな領域の問題解決をする（Cool な Experience を提供する）チームです。 一見すると研究開発チームのように思えますが、実際は PoC に留まらず、本番にリリースして運用するところまで責任を持っています。（だから良

みなさんこんにちは、セキュリティチームの@sota1235です。 久々の会社ブログ投稿な気がしますが、今回は今までの記事とテイストを変えてセキュリティチームの成果にフォーカスしたいと思います。 背景から丁寧に書いていこうと思っているので前提パートが長いのですが、タイトルにある業務委託の方とどう協業するかという部分を真に理解してもらう上では大事な前提だと私は思ってるので、できればお付き合いください。 （でも忙しい人は読みたい部分だけ読むでもいいですよ、今ならLLMに要約させてもいいかもしれません） チームの成果とは たとえば 質と早さを上げるには 10Xのセキュリティチームの成果を最大化する チーム体制 早さと質を上げていくための取り組み 採用活動 チーム輪読会の実施 他チームとの連携 事業観点での優先順位づけ いろいろな取り組みをしていたが… 業務委託の方との協業 セキュリティ業務を外注す

お久しぶりです。SRE の @babarot です。2022年4月に書いた 10X に SRE Team ができるまでとこれから 以来、3年ぶり2度目の文章です。10X に SRE チームができてから3年以上が経ち、その間の活動や成果などについて沈黙しまくっていたのですが、振り返ると実に多くのことを達成してきました。最近は会社的にも嬉しいニュースがあり、これから更にやっていくぞ 🔥というフェーズに来ております。この3年間、黙々と頑張りすぎてアウトプットがなかなかできていなかったので、このブログ記事ではこれまでの SRE の取り組みを軽く紹介しつつ、今後はそれぞれのテーマに深ぼったネタを定期的に記事にして投稿してきます！まずは第1弾として2025年時点の 10X SRE の現状報告ブログをどうぞ。 10X インフラの歴史 宣言的なインフラ管理 インフラの構成管理 (Terraform) ワ

前回記事で書いたように、お届けチームの扱うシステム領域ではさまざまな非同期処理が行われています。 product.10x.co.jp この記事では 非同期処理の採用するモチベーション 非同期処理の実現方法 を書いています。 非同期処理の採用するモチベーション 「領域間をまたぐ」 「同期処理をミニマルにしたい」 実現するためのoverview publish side subscriber side メッセージによる非同期処理を本番導入するまでに 1. gRPCのリクエストハンドラ内でプログラム上、同期的にイベントハンドラを実行する 2. gRPCのリクエストハンドラ内でプログラム上、非同期でイベントハンドラを実行する 3. gRPCのリクエストハンドラ内ではイベントの永続化だけし、別プロセスでイベントハンドラを実行する サンキューEventarc 次回に続く 非同期処理の採用するモチベーシ

ソフトウェアエンジニアの金子（@naoty_k）です。 10Xでは、これまでネットスーパー事業者向けの管理画面（以下、管理画面v1）をNuxt.jsを使って開発・運用をおこなってきましたが、現在はReact Routerを用いた新しいアプリケーション（以下、管理画面v2）への移行を進めています。本記事では、なぜ移行することになったのか、どのように進めているのか、そして技術的な工夫とこれからの展望についてご紹介します。 移行の背景 これまで開発してきた管理画面v1はNuxt.jsをベースとしており、当時は迅速な開発に大きく貢献してくれていました。 しかし、数年の運用を経て将来的な拡張性やメンテナンス性に技術的な課題が生じ、フルスクラッチを検討していました。一方、10Xの他のプロダクトではReact + React Routerの構成が導入され始めていたため、新しい管理画面v2もReact R

10X のソフトウェアエンジニア @metalunk です。 このブログでは、10X が提供する小売チェーン向け EC プラットフォーム Stailer での検索改善について説明します。今回は特に “並び順” にフォーカスした内容です。 対象読者は主に検索エンジニアですが、「並び順改善の下準備が大事」の章以外は専門知識は出てこないため、検索以外を専門とするソフトウェアエンジニアのみなさんにも読んでいただけるはずです。 また、Stailer を使っている小売事業者の方も、使っていない小売事業者の方にも、ネットスーパーにおける検索機能はどう改善されているのか、なにが難しいのかをこの記事を通じて知ってもらえると嬉しいです。 本記事は8割 LLM が書きましたw みたいなものではなく、筆者が真心込めて手で書きました。 検索重要 検索改善の道のり 並び順改善の下準備が大事 Interleaving

はじめに 課題：情報不足による検索ヒット率の低さ 施策：LLMによる検索タグの自動生成と活用 なぜタグ生成か？ 設計 JANコード単位での生成と管理 タグデータの更新について タグ生成の品質とリスク プロジェクトの進め方 1. PoC：タグ自動生成の実現可能性と品質検証 2. インデキシングの実装 3. 商品検索ロジックの評価とプロンプトチューニング 4. 検索ロジックの修正と本番リリース 5. 本番リリース後の効果測定 おわりに はじめに こんにちは、10Xで検索推薦の機能・基盤の開発運用を担当している安達(id:kotaroooo0)です。 10Xでは小売チェーン向けECプラットフォームStailerにおいて、商品検索機能ではElasticsearchを利用しており、主にテキストマッチングによって検索を実現しています。 今回、LLMを活用して商品検索タグ(以下、タグ)を自動生成し、検索

先日、Flutter Tokyo #6 で同タイトルの発表をさせてもらいました。10分ほどの発表でしたが、割と良い反応をいただけたので、少し内容を補足してブログとしても公開します。 発表時のスライドは以下です。 前提 一般的に、モバイルアプリは自動テストしづらい箇所が多いと言われます。たしかに、画面から素朴に実装していくと、自動テストでは確認が難しくなりやすいです。そうなってしまうと、アプリを起動して手動で動作確認するしかなくなってしまいます。 一方で、設計やツールを適切に使えば、モバイルアプリであっても広範囲が自動テストで検証可能になります。手動での動作確認を完全になくすことはできませんが、手動テストへの依存度は下げられます。 手動テストへの依存度が下がると、検証時間の短縮、手戻りの抑制など、さまざまなメリットが得られます。また、手動テストにも良い影響を与え、手動テストでなければ確認でき

ネットスーパーで注文された商品が効率よく確実にお客さまのもとに届くためには、店舗でのピッキングやパッキング、配送といった業務が必要となります。この業務を支えるStailer上のアプリケーション開発を担っているのが、お届けチームです。 10x.co.jp お届けチームは昨年「イベント駆動アーキテクチャ」を導入する取り組みを行いました。イベント駆動アーキテクチャをどんな狙いで導入し、どんな成果が得られたのか。お届けチームの開発メンバーである鈴木さんに聞いてみました。 イベント駆動アーキテクチャ: イベント駆動アーキテクチャは、システム内で発生するイベントをトリガーにして処理を実行する設計パターン。コンポーネント同士が直接やり取りをせず、イベントを介して情報を共有するため、疎結合になり、スケーラビリティと柔軟性が高くなる。イベントはイベントバスやメッセージキューを通じて通知され、受け取ったコンポ

はじめに 10X ソフトウェアエンジニアの野々村です。元々アプリケーション開発者としてサーバーサイドを中心に仕事をしてきましたが、最近は協業する小売事業者様から受領したデータをネットスーパーに掲載できる状態へ加工する商品データパイプラインの開発に主に携わっています。 10x.co.jp 10XでもDevin AIを利用し始めて1ヶ月程度が経ったので、適用事例と展望について紹介します。 前提 Devin AI とは Cognition AI社によって提供されるAIエージェントSaaSです。2024年12月に一般利用が開始され、各所で導入事例が紹介されています。 devin.ai Devin AIの特性として、以下のようなタスクが得意とされています。 実装の検証が容易である 参考実装にアクセス可能である Devin AIと適用領域の特性のマッチング 10Xでは私が開発に携わる商品データパイプラ

既存のアーキテクチャの問題が見えると、アーキテクチャを変更して解決すると思います。 それ自体は素晴らしいことなのですが、変更が全体に浸透し切らず古いアーキテクチャと新しいアーキテクチャが混在したままになってしまうと、状況はさらに悪化します。そのため、アーキテクチャを変更する時には、「どうやって完遂するか」もセットで考えるべきでしょう。 10Xの現状は？ 混在しています。 自然と移行を完遂できる日は来なかったので、完遂する努力をしています。 完遂するための取り組み アーキテクチャの限界を漸進的に押し上げる取り組み で紹介した通り、10Xでは 以下の4ステップのサイクルを回してアーキテクチャを改善しようとしています。 欲しい特性を狙ってアーキテクチャ決定を積み重ねる ADRでアーキテクチャ決定の意図を明確にする linterでADRに辿り着けるようにする ADRへの違反状況を可視化して漸進的に

10xall.notion.site 10Xセキュリティチームの沢田(@swdyh)です。10Xアドベントカレンダー2024 の26日目の記事です。昨日は@yutatatatata さんの「商品データの裏側を覗く：意外に知らない商品IDの世界」という記事でした。自分も商品データに関する開発をしていた時期がけっこうあったので、奥が深くて面白いなと思って読みました。 先日、情報処理安全確保支援士の試験を受けたのですが、今日が結果の発表日でした。結果は不合格でした。JavaScriptのコードができてたり、画面を描く問題あったりして面白く解いてたはずだったんですが、午後の点数が57点で、あと1歩でした。またがんばります。 今日の記事では、セキュリティチームの日々の取り組みについて紹介したいと思います。 プロダクトの設計と実装レビュー 社内で書かれたDesign Docに一通りチームで目を通すよう

この記事は10Xアドベントカレンダー2024の18日目の記事になります。 昨日はJOJOさん(@joj0hq)が「10Xのエンジニアとして入社から2年目を振り返る」という記事を公開しているので、そちらもぜひご覧ください。 はじめに 取り組んだプロジェクト 類似商品検索の実装 新しい検索精度モニタリングの導入 トップ画面での推薦枠A/Bテスト アルゴリズム アーキテクチャ 検索系RPCのレイテンシ改善 ボトルネック 効果 Elasticsearchのバージョンアップ 課題 互換性の調査 リリース手順 バージョンアップによるパフォーマンス改善 これからの取り組み LLMの活用 リランキング おわりに はじめに こんにちは、10Xで検索推薦の機能・基盤の開発運用を担当している安達(id:kotaroooo0)です。 2024年1月に入社し、もうすぐ1年が経ちます。 今回はこの1年間を振り返り、印

こんにちは、10X プロダクトデザイナーの日比谷（@suuminbot）です。 現在10Xでは新規プロダクトを複数開発している真っ只中ですが、私もその一環でshadcn/uiとTailwind CSSを活用しつつ、SaaSのサービス画面（管理画面）用のコンポーネントライブラリをゼロから構築していました。 少し前に一通り最低限必要なコンポーネントをFigma・実装ともに作りきり、現在は実際にそのコンポーネントライブラリを使って自分自身が複数のプロダクトのUIを作ったり、開発が進んでいる様子を見ているところです。 このブログでは、今回取り組んだことや学びをご紹介していこうと思います。 新規構築の経緯 外部コンポーネントライブラリのあるある課題 自分たちのプロダクトに合った形のコンポーネントライブラリを、クイックに立ち上げたい 「クイックな立ち上げ」と「こだわり」を両立できるshadcn/ui

10X在籍8年目、取締役CTOのishkawaです。 この記事は10Xアドベントカレンダー2024の3日目の記事です。 メイン事業であるStailerは現在5年目です。 自分はプロダクト開発を統括する立場として、プロダクト戦略立てたり、開発プロセスの整備の旗振りをしたり、開発体制を調整したり、採用活動に奔走したりと、色々な取り組みをしてきました。そして今、何に注力しているかというと、コードの立て直しです。 なぜコードの立て直し？ プロダクトを5年くらい開発していると、開発速度は当初と比べて落ち着いてきます。その要因は色々あると思いますが、自分は「事業やプロダクトのフェーズの変化による規模や複雑度の変化」と「規模や複雑度に対する技術的な適応度」の2点に着目しました。 前者はプロダクトマネジメントのトピックです。Stailerでは、自分たちが持つ強み、組織の規模、得られる事業成果、運用にかかる

こんにちは、セキュリティチームの@sota1235です。 突然ですが、ソフトウェアエンジニアの皆さんに質問です。他者に漏らしてはいけないAPI keyやSSHのprivate keyを誤ってGitHubにpushしてしまったことはありますか？私はあります。*1 日々、スピード感を持ってものづくりに臨んでいく中で本当はcommitしてはいけないものを間違ってcommitしたり、それに気づかずにGitHubにpushしてしまうなんてことは人間がミスをする生き物である以上、誰にでも起きえる事故です。 今回はそんな事故を検知するのにtrufflehogを活用しているお話をします。 なお今回は事故を未然に予防する話には触れません。 github.com credentialsを誤ってGitHubにpushすることのリスク credentialsとは credentialsのあるべき管理方法 GitH

10X ソフトウェアエンジニアの @metalunk です。ネットスーパー、ネットドラッグストアのプラットフォームである Stailer 事業で、機械学習（ML）と検索を専門として働いています。 2024年4月からいま（2024年8月）までの5ヶ月間で6つの推薦機能をリリースできました。この成果を支えたのはチームと ML platform（機械学習の基盤システム）です。このブログではチームの取り組み、ML platform の機能、および具体的な成果についてご紹介します。 このブログは技術ブログの体ではありますが、さまざまな業界、職種の方に読んでいただくことを目指して執筆しました。 (3) 章, (5) 章だけは機械学習に取り組んでいる人向けの内容を含みますので興味のない方は読み飛ばしてもらって結構です（機械学習に取り組んでいなくても興味のある方はぜひ読んでください）が、それ以外は IT

こんにちは、セキュリティチームの@sota1235です。 セキュリティチームでは昨年の夏頃からGitHub上のセキュリティリスクを洗い出し、順に対応や改善を行っています。 そのうちの1つとして、昨年の秋ごろからGitHubのPersonal Access Tokenの取り扱いの改善を行ってきました。 具体的には以下の取り組みを行いました。 CI等で利用されているPersonal Access Tokenの利用廃止 OrganizationにおけるPersonal Access Token(classic)の利用禁止設定 今回はこの2つの取り組みについて、どのような課題設定を行い、どんな手順で完了したのかをお話しします。 以下のような課題感、疑問をお持ちの方に対する1つの回答になりうると思うので該当する方はぜひご一読ください🙏 GitHubにおけるPersonal Access Token

こんにちは、ソフトウェアエンジニアの@futaboooです。 先日スクリーンリーダーへ対応したプレスリリースを配信しました。今日はその裏側について紹介です。 10x.co.jp はじめに とあるパートナーのネットスーパーシステムをStailerへリプレイスして少しすると、お客様から「今まで使えていたのに使えなくなった！」という切実な声が届きました。この問い合わせを通じて、視覚障害者のお客様がスクリーンリーダーを使って買い物をしていたこと、そしてStailerがそのニーズに応えていないことに気づきました。 そこで、我々は視覚障害者のお客様へのヒアリングを開始し、どのような環境でアプリを使っているのか、使用しているデバイスやスクリーンリーダーソフトウェアの種類など、具体的な情報を収集しました。このプロセスを通じて、アプリがより多くの人々にとって使いやすいものになるための重要な改善点を発見しまし

はじめに 前提 背景と課題 対応方針 StailerのElasticsearchに関する特性 要件 スケールイン・アウトではなくスケールアップ・ダウン リソース負荷トリガーではなくスケジュールトリガー 設計 cloud-sdk-goでの処理 モニタリング おわりに はじめに こんにちは、検索エンジニアの安達(id:kotaroooo0)です。 10Xで検索基盤・検索機能の開発運用をしています。 最近は推薦システムの開発もちょっとやり始めました。 負荷に合わせてElasticsearch(ElasticCloud)をスケーリングする機能を作りコスト削減したので、その取り組みについて経緯と内容を紹介します。 前提 背景と課題 10Xでは小売チェーン向けECプラットフォームStailerにおいて、検索機能の開発運用にElasticsearchを利用してしています。 Elasticsearchクラ

データ基盤チームに所属しているデータエンジニアの吉田(id:syou6162)です。10X社内のデータマネジメントの仕事をしています。 最近、社内でディメンショナルモデリング勉強会を行なったですが、なぜ勉強会を行なったのか、どのように行なったのか、勉強会を行なった結果何が得られたかについてまとめます。 ディメンショナルモデリング勉強会開催の背景 勉強会の進め方やスコープ 勉強会の参加者 勉強会で学んだ内容 Four-Step Dimensional Design Process キーの設計について 複数スタースキーマを適切に利用し、ファントラップを避ける コンフォームドディメンション まとめ: 勉強会で得られたもの ディメンショナルモデリング勉強会開催の背景 前回のエントリにまとめた通り、10Xのデータマネジメントの課題の中でも「データウェアハウジングとビジネスインテリジェンス」は優先度が

データ基盤チームに所属しているデータエンジニアの吉田(id:syou6162)です。10X社内のデータマネジメントの仕事をしています。 10X社内では2022年10月にデータマネジメント成熟度アセスメントを実施していましたが、それから約一年半が経過し、データマネジメント上の課題が進捗 / 変化した箇所が出てきました。そこで、最近の成果を振り返りつつ今後のデータマネジメントの方針を改めて見直すため、データマネジメント成熟度アセスメントを再度行なうことにしました。本エントリではその内容についてまとめます。 前回のデータマネジメント成熟度アセスメントへの取り組み 今回のデータマネジメント成熟度アセスメントのやり方 成熟度アセスメントの実際の結果 前回実施時との差分が大きかった項目 データセキュリティ データ品質 メタデータ 優先度が高かったにも関わらずあまり進まなかった項目 まとめ 前回のデータ

こんにちは、セキュリティチームでソフトウェアエンジニアをしてる@sota1235です。 明けましておめでとうございます！本年も10X Product Blogを何卒よろしくお願いします。 さて、今回はセキュリティチームで今年の6月ごろから取り組んできたGitHub Dependabot Alertの削減についてお話しします。 サマリーとしては以下です。 今年の6月頃から取り組みを開始 初期はセキュリティチームで毎日トリアージ、泥臭くAlertの対応を行う 主要なRepositoryのAlertは一通り解消、一部は担当チームへの移譲等を行い継続的に維持できる状態へ 結果として半年間で500件弱のAlertをcloseし、残ってるAlertも対応方針が全て確定した状態になりました。 この数が多いか少ないかはソースコードの規模感にも依存するので言及しませんが、この記事では小さいリソースで取り組み

この記事は🎄10X プロダクトアドベントカレンダー2023の22日目の記事です。 21日目の昨日はaineさんによる「プロダクトマネージャーになった自分が大事にしていること」でした。 こんにちは。エンジニアリングマネージャーの坂本(kazu0620)です。 この記事では10XがStailerの開発に取り入れて来た仕組みやルールの中で、「もしも過去に帰れるならこれは早い段階で取り入れたい」と私個人が特に思ったものたちを紹介したいと思います。 過去に帰ることはできませんが、我々と同じようにプロダクト開発を行っている組織の方の参考になれば幸いです。 Stailer最初期の開発と現在 Stailerの開発が始まったは2019年末のことです。私が10Xに入社しStailerの開発に関わり始めた2020年3月の時点では、ソフトウェアエンジニアの数は6名でした。当時はプロダクトマネジメントはCTOであ

こんにちは。セキュリティチームでソフトウェアエンジニアをしてる@sota1235です。 この記事は10Xアドベントカレンダーの13日目の記事です。 www.notion.so 昨日の記事はSuzuki Ryotaさんのお届けチームでオーナーシップを持っていくぞでした！ 今回はGitHubの監査ログを定期的にexportし、保存する仕組みを作った話をします。 監査ログとは GitHubの監査ログ GitHubの監査ログは永久には保存されない 監査ログの出力方法 この記事の本題 監査ログ出力の仕組み ざっくり要件 技術選定 ログの保存場所 ログの取得処理 ログの取得・保存処理はGitHub Actionsで行う 全体像 1. BigQueryに最新データを取得しに行く 2. 監査ログを取得する 3. 監査ログを保存する 権限管理 監査ログに含まれるデータについて考える 具体的にどこに制限をつけ