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

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

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

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

Analytics Engineerの吉田(id:syou6162)です。BigQueryを中心に10X社内のデータ管理の仕事をしています。 最近、データカタログの本格導入の準備を進めていて、それに向けた補助ツールとしてdbt-osmosisもゴリゴリと使い倒すようになってきました。その中で「10Xでの運用を考えるとこういうケースで困るし、前職までの経験を踏まえると解決できると他社でも役に立ちそう」「この挙動は普通にバグっぽいな...」というものがあったので、立て続けにPull Requestを送りました。ありがたいことに全部マージしてもらえましたが、せっかくなのでデータカタログの導入に向けてdbt-osmosisを採用した背景やどういったPull Requestを送ったか紹介します。 データカタログ導入の必要性 メタデータをいかに効率よく入力するか: dbt-osmosisの導入 取り込

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

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

はじめに こんにちは！yamakazu (@yamarkz) です。 近所の行きつけスーパーがサミットストアになったのですが、品揃えがとても良く、お店の雰囲気も明るくて、仕事終わりの買い物が最近の楽しみになってます 🥳 🛒🥗 さて今回は、開発方面のナレッジとして外部API連携の話を紹介します。非常にニッチな領域の話題ですが、わかる人にはわかるような内容です。 興味のある方はぜひ最後まで読んでみてください。 動機 新しく外部API連携の開発に着手するメンバーの助けになりたい、より良い外部API連携を実現したいという思いから、これまで開発を経験してきた中で理解した勘所を紹介します。 元々は社内向けに書き溜めておいたナレッジメモの内容ですが、特別社内に留めておく必要性もないので、せっかくならブログにしてしまおうと思い、ここで筆を取りました。 これは社内の同僚に向けた内容でありながら、似た境

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

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

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

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

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 をリリースして以降、