はてなブックマーク

こんにちは！経営企画の仕事をしているudonです。1年半前の見習いQA以来、2度目の文章です。今回は10X社内の会議のルールを整理し、そして全社員の未来のカレンダー予定を一旦全部消す、通称「ビッグバン」の第一回を実施したのでその背景や内容について書きます。 (イメージ) 10Xでは社内におけるコミュニケーションを大きく「同期」「非同期」に分けています。同期は会議や突発的な電話など同じ場にいることが前提であるコミュニケーションを指し、Slackなど非同期は必ずしも同じ時間での往復を前提としない文章やドキュメントによるコミュニケーションを指します。入った当初は「ドウキ・・？ヒドウキ？？」とドキドキしてた私ですが、2年も経つと慣れてしまいました。慣れって怖いですね。 話が長いという皆様の期待を裏切ることなく、タイトルにもなっているビッグバン(会議の全削除)の話にいくまで5,000文字嵩んでしまっ

障害プロセスを改善してきた話 こんにちは。Reliability & Securityチームに所属するSoftware Engineerの@sota1235です。 今回は10X内における障害対応プロセスの改善をご紹介します。 今が完成系ではなく道半ばではありますがこの半年 ~ 1年で大きく進化したので同じくらいのフェーズの会社で困ってる方がいたら参考にしてみてください！ ちなみに私ごとですが去年の5/26にこんな投稿をしてたのでやっと伏線を回収する形となります(※ ドヤ顔ではありません)。 目次 こんな感じで紹介していきます。 目次 障害対応プロセスの改善に踏み切った背景 課題1. 障害の報告フォーマットが統一されていない 課題2. 障害報のクオリティの差異が大きく後から振り返りが難しい 課題3. 障害対応者が特定の人に偏る 第一の改善 改善1. 障害報告書のフォーマット更新 改善2. S

この記事は 10X アドベントカレンダー2023 という企画の1日目（12/1）の記事です。 こんにちは、10Xでソフトウェアエンジニアをしている 岡野（@operandoOS）です。 今回 10Xで3回目となるアドベントカレンダー企画の1日目をありがたく担当させていただきます💪 目次 目次 10X アドベントカレンダー2023ってなに？ さてさて、本題へ CIは絶対に速い方がいい CIを高速化するテクニックの紹介 キャッシュの利用 マシン性能の調整 ジョブの並列実行とテスト分割 最適なテスト分割 ジョブの実行順序・依存関係の最適化 不要なジョブ・ステップを削除する テストコードの実行速度を上げる 紹介したテクニックを活用した10XでのCI高速化事例 アプリのビルド時間の大幅短縮に成功！！ APIのテスト実行時間の大幅短縮に成功！！ CIを高速化するために日々取り組んでいること CI/C

Analytics Engineerの吉田(id:syou6162)です。BigQueryを中心に10X社内のデータ関連の管理をしています。10Xに入社してそろそろ一年になろうかとしていますが、データ基盤を適切に管理 / 運用するためにSQLによる監視を少しずつ取り入れています。この記事では、具体的にどのようなSQLを書いて監視しているのか紹介したいと思います。 なお、SQLを使ったデータ基盤の監視自体については私の前職のTech Blogで詳細に書いていますので、そちらを参照してください。 SQLを使った監視でデータ基盤の品質を向上させる - MonotaRO Tech Blog データ管理に役立つメタデータに関する勉強会を社内外で開催しました - MonotaRO Tech Blog 本エントリはこれをベースに「dbtをフルに活用している10Xの環境向けに入れた監視」や「BigQuer

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

いやー、まいったね。 入社して三ヶ月が経ちました @metalunk です。この三ヶ月は検索インフラの改善に取り組み、検索速度 10x, インフラコスト 80% 減の成果が出ました。この記事では検索インフラ改善でやったことを説明します。 ところで、検索インフラの改善ができるということは、先人たちが検索機能を作り、PMF してサービスが利用されるようになったおかげです。感謝して改善しましょう。 2021年12月の Stailer の検索 10X は開発不要でネットスーパーアプリを立ち上げられるシステムである Stailer を開発しております。Stailer での購入のうち 35% が検索経由で行われており、検索はとても重要な機能です。 しかし、2021年12月、増加するリクエストによるサーバー負荷の増大、速度の低下に悩まされておりました。一時的にサーバーを増やし、スケールアウトをすることで

Google Cloud上のアプリケーションからGitHub APIにアクセスするとき、PATあるいはGitHub AppのInstallation Access Tokenが必要となります。しかしPATはユーザに紐付くため管理が厄介ですし、Appを作れば秘密鍵の管理について考えなければなりません。 この記事では、すでに運用しているOcto STSとGoogle CloudのOIDC ID Tokenを組み合わせることで、新たなGitHub Appを作らずにGitHub APIへのアクセスを実現した事例を紹介します。10XではOcto STSを使ったToken運用の改善で紹介したように、GitHub Actions上での社内の様々なユースケースでGitHub AppのInstallation Access Token（以下GitHub App Token）の発行にOcto STSを活用して

CTOのishkawaです。 10Xでは全職種の選考プロセスにトライアルを設定していましたが、ソフトウェアエンジニアに関してはトライアルによる選考を終了し、新たな選考プロセスを導入することにしました。本稿では、創業以来続けてきたトライアルをやめて、選考プロセスをアップデートしていくことに決めた背景を紹介します。 トライアルとは トライアルとは実際に10Xの仕事に取り組んでもらいます。大まかな流れは次の通りです。 会社の情報をインプットし、取り組むイシューの候補を考える。 社員へのヒアリングやディスカッションを通じて、取り組むイシューを決める。 イシューの解決に向けたアクションプランを策定し、可能な範囲で進める。 成果を発表する。 トライアルは1日や数週間といった短期間で実施します。 良かった点 会社と候補者の双方から様々な面のフィットが確認できるのが、トライアルの良いところでした。例えば、

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

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

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

どうも @metalunk です． コスパ，大事ですよね？コストをある値以下に抑えたとき，どれだけパフォーマンスを発揮できるか，という話です． 10X で最初の機械学習プロダクトを作るにあたり，コスパを意識して MLOps 基盤を作ったので，それの紹介をします． Stailer における ML の重要性 レジ前推薦 作りたかったもの アーキテクチャ Training pipeline の選択 Python function-based component vs Own container component Serving 用データストア CI (Continuous Integration) CD (Continuous Delivery) Monitoring リポジトリ構成 認証 Vertex ML Metadata stailer-suggest-batch の移行 組織の話 未来

10Xでは、GitHub Actionsのセキュリティ改善を段階的に進めてきました。もともとPAT（Personal Access Token）を使っていたところをGitHub App Tokenに移行し、さらにOcto STSを使ったToken運用の改善にも取り組んでいます。 そうした中で、まだGitHub Secretsに残っていたものがありました。Terraform用のGitHub Appの秘密鍵です。このAppに付与される権限が徐々に膨らんでいく中で、秘密鍵の保管方法がセキュリティ上無視できない課題になってきていました。この記事では、その課題と、秘密鍵をGitHub Secretsから追い出してGoogle Cloud KMSに閉じ込めるというアプローチについて書きます。 秘密鍵をGitHub Secretsに保存するということ GitHub Appのトークンを発行するには、秘密鍵

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

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

CTOのishkawaです。 10Xの開発チームは、4月1日からドメインベースの開発体制に移行しました。 ここで言うドメインとは、注文やピックパックや配達などの業務領域を指す言葉です。ドメインベースの開発体制に移行するということは、開発チームの分割単位をドメインにして、各ドメインを担当する開発チームが決まっている状態にするということです。 組織移行の背景 これまでは、開発チームの分割単位をパートナー企業としてきました。各パートナー企業を担当する開発が決まっているため、パートナー企業の目線でプロダクトの未熟な面があっても迅速に対応できますし、それによって事業機会を掴めたケースもありました。 一方で、プロダクトを開発運用する中で以下の課題も出てきました。 認知コストの増大: Stailerは多様なドメインを抱えるプロダクトなので、すべてのドメインを理解するのは至難の業です。一方で、パートナー企

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

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

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

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

はい、こんちゃーす(eyden)、Stailerのプロダクト責任者の矢本です。この記事はCEO/創業者という立場ではなく、一人のプロダクトに関わる人間として書いています。この記事の焦点はStailerのエンドユーザーでもある、お客様の”買い物体験”です。 早速ですがこの記事の結論をお伝えします。 スーパーでの買い物体験は多量の”意思決定”で構成されています Stailerはお店の買い物体験を補完するプロダクトです ネットスーパーの買い物体験を支えるのは”検索”と”推薦”という技術です つまり、検索エンジニアや、推薦を支えるMLエンジニア、推薦のアルゴリズムを作る Data Scientist、MLをプロダクト価値に落とし込んでいくテクニカルプロダクトマネージャー、これらを多数の制約からプロダクトデザインへ落とし込むデザイナーも強く募集しています。ここまででピンと来た方は10XのMLエンジニ

今 Q もお疲れさまでした！10X の @metalunk です． 3ヶ月前に 10X の検索を 10x したい というブログを書きました．その記事にあるとおり，1-3月で検索インフラの改善を実施し，検索速度 10x, インフラコスト 80% 削減という成果をあげました．そして，直近の3ヶ月では検索精度の改善に取り組みました．この記事では今 Q にリリースした機能と，それぞれの効果を説明します． 長い記事になったので飛ばし飛ばし読んでください． どんな Q だったか KPI の変化 Zero match rate Conversion rate リリースした機能 検索キーワードサジェスト システム概要 評価 カテゴリフィルタ 並び順の改善 評価 bigram 解説 評価 シノニム辞書を Search time に展開 解説 イベントログからシノニムルールの生成 解説 改善の背景 KPI D

SRE Team の @babarot です。今年1月に入社してからおよそ 3 ヶ月が経ちました。 この度、株式会社10X (以下、10X) は、2022年5月14日、15日に開催される SRE NEXT 2022 に、SILVER スポンサーとして参加します。実は 10X では今年1月に SRE Team が発足しました。これまで開発において求められていたことに新たに "Reliability" という観点が加わり、それが今後強く必要になってくるためです。このタイミングに合わせて、10X に SRE Team ができるまでとチームのこれからについて紹介します。 現在、10X では開発不要でネットスーパーアプリを立ち上げられるシステムである Stailer を開発し、バックエンドとそれにつなげるアプリ (iOS と Android) を提供しています。 Stailer をリリースして以降、

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

こんにちは、こんばんは、おやすみなさい。id:sota1235です。 私は組織図上、セキュリティチームに所属しています。 ですが次の記事でも言及しているとおりここ1年弱の間はCorpIT業務も担っています。 10x.co.jp 本日はCorpIT業務を引き継ぎ、改善していく過程で取り組んだ「業務で利用しているSaaSやWebサービスを把握」について紹介します。 課題 引き継いだタイミングの状況 何があるかわからない さまざまな課題 CorpIT観点 セキュリティ観点 管理方法の課題 どう課題に立ち向かうか どのように取り組んだか ToBeを考える サービス管理台帳的なものの存在は必須 管理台帳に相応しいのはSaaS管理SaaSでもスプレッドシートでもなさそう いったん、目指すところ: Notionでサービス管理台帳を作ろう まずは箱を作る プロパティセクションを使う 管理するための情報の記

こんにちは。 Software Engineerのsota1235です。 今回は10Xのセキュリティチームこれまでとこれからについてお話ししようと思います。 隠していたわけではないのですが、 採用資料や対外発表等で特にアピールもしておらず、結果的にステルス活動みたいになっていたので本邦初公開の内容ばかりです。 この記事では 10XおよびStailerにおけるセキュリティの重要性 セキュリティ観点で見る今までの10XとIssue なぜセキュリティチームを作るという判断をしたのか 今までどんな取り組みをしてきたのか 等々をお伝えできればと思っています。 10XおよびStailerにおけるセキュリティの重要性 10Xの提供するStailerはいわゆるB to B to Cのサービスです。 to Cは商品を求めてアプリやWebサイトを訪れるお客さまに対してセキュリティ観点で次の価値を提供する必要が

GitHubのユーザーをTerraformで管理しているときの問題点 GitHubの組織メンバーやリポジトリのアクセス権限をTerraformで管理すると、誰がどのリポジトリにアクセスできるかがコードとして可視化され、変更にはPRとレビューが必要になります。手作業でポチポチ設定するよりも安全で、監査もしやすくなります。 10Xでもこの方針でGitHub管理用のTerraformモジュールを作り、GitHubリソースをコード管理しています。 module "repository" { source = "github-management-module" name = "repository-name" access = { users = [ { name = "alice", permission = "push" }, { name = "bob", permission = "pus