こんにちは、Software Engineerの@sota1235です。最近の趣味はギター練習です。 今回は私が所属するセキュリティチームで新たにソフトウェアエンジニアを募集し始めた話をします。 採用目的が全開みたいなタイトルになっていますが、伝えたいことは「セキュリティエンジニアだけでなくソフトウェアエンジニアをセキュリティチームで募集するに至った」背景です。 10Xのセキュリティチームが組成されてから1年半でどのような変化があり、どんな課題を解決するためにこの意思決定に至ったのか。なぜソフトウェアエンジニアが必要なのか。 スタートアップにおいてプロダクトのセキュリティ品質を担保するための体制をどう組み立てていくかの一例として参考になれば幸いです。 目次 目次 ソフトウェアエンジニア(Product Security Ops)とは なぜソフトウェアエンジニアの募集をするのか 1. 現在の

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

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

はじめに こんにちは！お会計チームの yamakazu (@yamarkz) です。 10Xでは4月から新しい期が始まるため、最近はバタバタしています。新しい組織や取り組みが始まってきていて、今年度はこれまでとはまた違った大きな変化が生まれそうで楽しみです。 さてそんな今回は期の変わり目ということもあり、 節目として「Stailerの開発を支える取り組み」を紹介します。 取り組みはプロダクトの規模や性質、組織構造、願望によって変わる唯一無二の存在で、各社様々な工夫を凝らして、より良い開発体験を追求していると思います。 自分たちもその時々の状況に合わせて、最適なやり方に変えて開発してきました。 今後も取り組み自体は変わっていくと思いますが、2023春時点での取り組み状況 (仕組み / ルール / 文化 / ツール) をスナップショットとして取り上げみようと思います。 はじめに 前提 取り組み

はじめに こんにちは！モジュール開発部のyamakazu (@yamarkz) です。 10Xではテストコードの標準化を目指して、テストコード規約 (Test Coding Standards) を整備してきました。この記事では数ある規約の中でも、実際に活用して効果が大きかったものをいくつか取り上げて紹介します。 テストコードの品質に課題を持っている方や、コーディング規約の整備に関心を寄せる方の参考になれれば幸いです。 ChatGPT 要約 ChatGPTに内容の要約をお願いしました。この記事で述べられている内容は以下の通りです。 テストコードに規約を設ける目的は、「テストの資産性を高めることで、プロダクトの発展性と事業の継続可能性を守るため」である。テストコード規約は、ボトムアップで開発組織全体が守る基準を明確にし、良質なテストを書くために設ける。この規約ではGroup, Arrange

はじめに こんにちは！ モジュール開発部の yamakazu (@yamarkz) です。 チームのサイドプロジェクトでLint Ruleの整備を進めてきており、メインプロジェクトを進める傍ら、隙間時間を捻出してはLint Ruleを作っています。 興味本位で始めたLint Rule作りだったのですが、これが思っていた以上に面白く、面白さにハマった勢いで1ヶ月で20以上のLint Ruleを作っていました。 今回はそんな勢いを持って整備を進めていたLint Rule整備の話を取り上げて、そもそもなぜLint Rule整備を始めているのか？Lint Ruleで何を解決したいのか？どういったLint Ruleを作っているのか？を紹介します。 目次 はじめに 目次 話の全体整理 なぜLintを活用していくのか 状況1. プロダクトと組織の拡大 (未知の増加) : 状況2. 多様な表現での実装 (

はじめに こんにちは！ モジュール開発部の yamakazu (@yamarkz) です。 あけましておめでとうございます。2023年もよろしくお願いします。 本記事が新年最初のプロダクトブログになるのですが、何を書こうかとても迷いました。笑 抱負的な何かが無難だと思いつつ、1年先のことまでは見通すことができない。10Xはドラスティックに事業や組織が変わるので、中長期な目線で1つのテーマを説くのは難しいなと。そう色々と考える中で、ちょうど足元で成果が出始めている具体の取り組みを紹介したい！というモチベーションが生まれてきました。 なので今回は、半年先までの将来的な抱負の意図を交えながら、直近の取り組みで手応えを感じ始めている、アーキテクチャ改善のプラクティスを紹介しようと思います。 具体的にはタイトルにもある”適応度関数”と呼ばれるプラクティスで、巷では概念としては認識されているものの、ま

どうも @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 の移行 組織の話 未来

こんにちは。 品質管理部のtarappoです。 品質管理部！？と思った方もいるかもしれないので補足をしておきます。 2022年10月から10Xはマトリクス組織を採用し、品質管理部が誕生しました。 詳しくは次のCulture Deckとブログ記事をご覧ください。 今までQuality Teamとして活動してきた私たちは、現在品質管理部に所属して私が部長をつとめています。 とはいえ、今回の記事ではその品質管理部がうまれるまえの話ですし、QAチームという表現で書いていきます。 今回本記事で紹介するのは、QAチームが主催したバグバッシュもとい「ドラゴン探しの旅」について話したいと思います。 バグバッシュは各社でもおこなわれているかと思いますが、次のようなものです。 いろいろな職種の方が、日常的な業務から離れて対象となるプロダクトに対して 「バグ」をみつけることを考えながら触ります。 いろいろな視点

はじめに こんにちは！yamakazu (@yamarkz) です。 10月から下期も始まり、10X社内は色々と変化が生まれ始めました。大きくは組織のアーキテクチャが刷新され、実務検証(ここから半年がProof of Concepts期間)が始まったところが大きいです。 yamotty.tokyo アーキテクティングの重要性を所属組織の構造変化という観点から経験知として学ぶ機会に遭遇できているのは貴重で、新たに加わる変化 (評価制度や目標設定など) でどのように組織が変化するのかは個人的にも関心があり、良い/悪い含めて前向きに学んでいきたいです。 さて今回はそんなアーキテクティング方面の話として、ソフトウェアアーキテクチャ分野で提唱されている アーキテクチャ特性 と呼ばれる概念と、それに対する10Xでの取り組みを紹介します。 ソフトウェアアーキテクチャに関心のある方は既に知っている概念かも

「アーキテクチャ特性の導入と手応え - 10X Product Blog」の記事を補完する内容です。 10Xにおける「アーキテクチャ特性」という概念に対する解釈を定義しています。 これは元々社内向けに書かれたドキュメントでした。社内ドキュメントをそのまま転記する形で記載しています。 概念の出自は「ソフトウェアアーキテクチャの基礎」です。 ここでの内容が、アーキテクチャ特性への理解の足がかりになれれば幸いです。 アーキテクチャ特性とは なぜアーキテクチャ特性が必要なのか 備えるべきアーキテクチャ特性とは 1. 設計に対する考慮事項が要求仕様として明らかなもの (明示的) 2. 設計の構造的な側面に影響を与えるもの (暗黙的) 3. ソフトウェアの成功に不可欠 or 重要なもの アーキテクチャ特性の見極め ドメイン特性 (ドメイン由来) 明示特性 (要件由来) 暗黙特性 (システム由来) 見極

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

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

こんにちは。 Software Engineerのsota1235です。 この夏、パフォーマンスチューニングに思いを馳せるエンジニア達を熱狂させる素晴らしいイベントISUCON12が開催されました。 10Xは、このISUCON12をスポンサーとして協賛しました。 今回は10XがなぜISUCONをスポンサーしたのか、という真面目な話から弊社より参加したチームがいかに砕け散ったのかまで総括してお伝えできればと思います。 なぜISUCONをスポンサーしたのか 理由は2つあります。 1. 10Xの提供するStailerのスケールが10xしつつあるから Stailerは契約企業（パートナー）にECサイト・アプリケーションを垂直立ち上げするのに必要なすべてのシステムを提供するサービスです。 このサービスが0 → 1のサービス立ち上げ期から1 → 100のサービス成長期へと差し掛かり、エンジニアリングチ

こんにちは。 QAチームのtarappoです。 今までの10XにおけるQAチームの話については次のブログで紹介したとおりです。 現在、QAチームは少しずつ大きくなってきていて、おこなっていることも以前よりは広がってきています。 しかし、まだおこないたいことに対してできていることは少ないです。 そこで、さらにQAチームを拡大するために求人職種を追加＆更新しました。 その中身だけではわからないところもあるかと思うので本記事では、補足も含めて説明をしていきます。 10Xで目指しているQAの姿 上述したブログでも記載していますが、現時点における「10XにおけるQAはどのような姿を目指すか」については次のような感じです。 （1）リリースの前のテストフェーズに頼るのではなくてさまざまなフェーズでテストができている （2）QAに関わる職種のメンバーだけでなく品質を担保していくのは「全員」であるというスタ

10Xの石田(@wapa5pow)です。10Xでは全社でオフサイトを3ヶ月に一回開いています。 全社オフサイトというのはこんな感じで会社のメンバー全員が集まりワイワイして仲良くなってより事業を伸ばしましょうというイベントです。 今回、全社オフサイトとは別にStailerを開発する(コードを書く)メンバーを対象とした開発オフサイトを開きました。 この記事ではなぜ今回新たに開発オフサイトを始めたのかと、どのように準備したかを紹介します。 開発オフサイトを行う事によって解決したかったこと 10Xの作っているチェーンストアECの垂直立ち上げプラットフォームであるStailerの事業が順調に伸びていることもあり開発メンバーも増えています。 上図にあるようにソフトウェアエンジニアは20名ほどいます。創業当時は数名で机を向き合わせて開発していましたがコロナ禍ということもありリモートで開発しています。なか

今 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日や数週間といった短期間で実施します。 良かった点 会社と候補者の双方から様々な面のフィットが確認できるのが、トライアルの良いところでした。例えば、

はじめに Growth&SuccessでStailerのデータウェアハウスの開発をしています@kazk1018です。この記事では、先日社内で開催した「Data Vault勉強会」を基にData Vaultについて簡単に紹介するとともに、10Xでどのように利用しているかを紹介したいと思います！ Data Vaultについて 「Data Vault」はエンタープライズデータウェアハウス(EDW)を構築するためのモデリング手法です。最初に提案されたのは2000年なので20年以上の歴史があり、2013年には「Data Vault 2.0」が提案され、非構造データへの対応やより実践的なプラクティスなどが追加されました。*1 Data Vaultではデータウェアハウスを構築する全体の流れから、各レイヤーで用いるスキーマの設計まで幅広い範囲のアプローチや手法が提案されています。中でもHub、Link、S