セキュリティチームの輪読会についてご紹介

こんにちは、こんばんは、おやすみなさい。id:sota1235です。

この記事は10X 新春ブログリレー 2026の29日目の記事です。

新春というにはもう2月が目前に迫っている気もしますが細かいことは気にせず、今回は私が所属するセキュリティチームの取り組みである輪読会について緩く紹介しようと思います。

  • セキュリティチーム輪読会とは
  • なぜ輪読会をやるのか
    • きっかけ
    • 情報収集の時間軸
  • どうやってやってるのか
    • 輪読会のネタ出し
    • 細く長く無理なく、がテーマ
    • ガンガン脱線してもいい輪読会
    • どれくらい続いてるのか
  • 読んだコンテンツをいくつか紹介
    • GitHub Organizationの安全な運用とモニタリングに関するスライド(全44ページ)を無償公開しました
    • クレジットカード・セキュリティガイドライン【4.0版】
    • 基礎から学ぶコンテナセキュリティ
      • その他
  • 最後に
続きを読む

SRE×セキュリティ合同『技術改善キャンプ』で、Terraformレビューの一部をAIに任せられないか考えた話

10X SREの栗原です。
この記事は10X 新春ブログリレー 2026の1月28日分の記事です。

株式会社10Xでは、SREチームとセキュリティチームが合同で「技術改善キャンプ」を定期的に開催しています。 事業の優先度や日々の対応に押されがちな…でも大事なタスクへ、まとまった時間で取り組むためのイベントです。

本記事では、その取り組みの一例として、私が第6回(2026/1/26)で検討した「Terraformを管理するリポジトリのレビュー負荷をAIで減らせないか?」というテーマを紹介します。

なお、今回キャンプ内で実装(PoC作成)まで到達したわけではありません。検討と設計(Design Docの作成)までがスコープです。

続きを読む

イベント駆動な非同期処理を支える運用について紹介 (CQRS+ES conf 2026の補足)

この記事は、10X 新春ブログリレー 2026の記事です。


鈴木です。2026年1月に開催されたCQRS+ES Conference 2026にて「ネットスーパー事業におけるCQRS+ES的アプローチの取り組み紹介」というタイトルで登壇しました。 cqrs-es-con.jp

CQRS+ES conf 2026の当日は

  • Stailerにある注文を中心とした業務影響がある課題の共有
  • 共有した課題がCQRSとイベントソーシングにある要素でどう解決できるのか

この2点にフォーカスして話をさせていただきました。

当日使った資料はこちらです。

speakerdeck.com

また、1月中にイベントで話したことについて補足記事を1つ出しています。

product.10x.co.jp

引き続きイベント登壇に便乗して当日話きれなかった具体的な方法を紹介しようと思います。

続きを読む

10Xが求めるQAエンジニア像と10Xで得られる体験〜「なぜJSTQBの資格保有が必須ではなく推奨なの?」の回答〜

はじめに

品質管理チームのEMのブロッコリーです。

この記事は10X 新春ブログリレー 2026の1月25日分の記事です。

現在、品質管理チームではQA(Quality Assurance, 品質保証)エンジニアの募集をしています。

QAエンジニア / 株式会社10X

本記事では、今回の採用募集の背景と、応募資格に対する私たちの考えについて説明します。

目次

採用募集の背景

今回のQAエンジニアの募集は、10Xのネットスーパー事業のさらなる進化と、新規事業の立ち上げに向けて、品質保証体制を強化し、品質に関する知見や仕組みを組織全体に蓄積していくことを目的としています。

現在の10Xは、事業の変革期を迎えており、品質管理チームもその変化に貢献していきたいと考えています。

単にテストを実行するだけでなく、品質を担保するためのプロセスや文化を構築し、組織全体の品質レベル向上を目指せる方を求めています。

詳細については、カジュアル面談などでお気軽にご質問ください。

どんな人を求めているのか

採用ページに記載の応募資格と求める人物像を以下に転記します。

応募資格(必須)

  • テスト設計スキルが備わっていること
    • 案件や課題に対してモデリングを適用し、様々な視点からテスト対象を表現できる
    • 工数が限定される中で、より適切なテストケースを選択できる
    • 開発者をはじめとしたQAエンジニア以外にも納得してもらえるように、自分のテスト設計成果物を説明できる
  • 開発者との議論に参加し、その場で自らの考えを伝えられる
  • 複数のタスクがあった際に、テストマネジメントの考え方などを用いて、納得できる優先順位を付けてタスクの割り振りができる
  • テストに限定せず、チームの生産性や品質改善の提案・議論・実施ができる

応募資格(歓迎)

  • JSTQB Foundation Level の資格保有
    • テストレベルとテストプロセスをそれぞれ自分の言葉で説明できる
    • 各種テスト技法を理解し、実際の業務に適用できる
    • テストのモニタリングとコントロールについて理解し、実際の業務に適用できる
  • 開発チームの一員として、短いリリースサイクルの中でのQAを行なった経験
    • 受け入れ基準の策定を行なった経験
  • QAチームのリーダーとして、チームのマネジメントを行なった経験
    • メンバーの育成面でのマネジメント経験
    • QAチーム全体のテストマネジメント経験

求める人物像

  • 10Xのミッション、Stailer事業に共感いただける方
  • 周囲の人々を巻き込み主体的に行動できる方

「JSTQB Foundation Level の資格保有」を推奨にした理由

ソフトウェアテストに関する技術者資格認定として「JSTQB」が広く知られています。

JSTQBの中でもいくつかの資格があるのですが、その中の一番基礎となるJSTQB Foundation Level(以下、JSTQB FLと表記)を"応募資格(必須)"に入れたり、逆に応募資格に入れない求人を見かけます。しかし今回、我々は"応募資格(推奨)"としました。

理由は以下の通りです。

  • "応募資格(必須)"に入れなかった理由
    • 理由1. 知識の「保有」よりも「適用力」を重視したいから
    • 理由2. 10Xのフェーズに特化したスキルセットを定義したかったから
  • "応募資格(推奨)"に入れた理由
    • 共通言語として知っておいてもらえると、業務がスムーズにいくから

"応募資格(必須)"に入れなかった理由1. 知識の「保有」よりも「適用力」を重視したいから

過去の経験から、JSTQB FLの知識を実務の複雑なコンテキストに合わせて柔軟に応用し、成果を出している方は、資格の有無に関わらず多く存在します。

私たちは「用語を知っていること」そのものよりも、「知識を道具として使いこなし、現場の課題を解決する能力」をよりダイレクトに評価したいと考えました。そのため、資格の有無を必須条件とはせず、選考を通じてその「適用力」を確認させていただく形をとっています。

"応募資格(必須)"に入れなかった理由2. 10Xのフェーズに特化したスキルセットを定義したかったから

JSTQB FLは網羅的で優れた体系ですが、現在の10Xが直面している「爆速での事業立ち上げ」や「複雑なドメインのモデリング」においては、シラバスの範囲外の動き(例:仕様が固まる前からの越境的な議論など)が求められる場面も多くあります。

そこで、資格というパッケージに頼るのではなく、「今の10Xで高いパフォーマンスを発揮するために必要な要素」を一つひとつ言語化した結果、現在の「応募資格(必須)」の項目になりました。

"応募資格(推奨)"に入れた理由.共通言語として知っておいてもらえると、業務がスムーズにいくから

"応募資格(必須)"に入れなかったということは、JSTQBの資格は不要と考えているのでしょうか。いいえ、違います。JSTQBで語られている用語を用いることで、業務がスムーズに行くと考えています。

例えば、業界や組織によっては「デバッグ」という単語に「バグを見つける」という行為も含めており、「テスト」と同義語のように扱われることがあります。しかし、JSTQBの中では「テスト」と「デバッグ」という単語を使い分けて表現しています*1

このような時に、JSTQBの内容を共通言語として持っておくと、「テストとデバッグというのは違う意味で…」と説明する手間が省けます。そのため、"応募資格(推奨)"に入れています。

10Xが求めるQAエンジニア像

上記で「JSTQB FLの資格保有」を推奨に位置付けた理由を書きましたが、それではどんなことを応募資格(必須)としているのでしょうか。

私たちが特に重視するのは以下の2点です。

  • 強く求めていること1.テスト設計スキルと説明能力: テスト設計の知識・経験を最大限に活かし、その結果をQAエンジニア以外の関係者にも理解・納得してもらえるように説明できること。
  • 強く求めていること2.積極的な議論とコミュニケーション能力: 開発者やプロダクトマネージャー(PdM)など、異なる専門性を持つメンバーと積極的に議論し、より良いプロダクトづくりに貢献できること。

強く求めていること1.テスト設計スキルと説明能力

JSTQB FLで言及されている同値分割法、境界値分析、デシジョンテーブルテスト、状態遷移テストなどのテスト設計技法は重要です。しかし、単にこれらの知識を持つだけでなく、状況に応じて適切な技法を選択し、効果的に適用できる能力を求めています。

さらに、開発者やPdM、ビジネスサイドなど、異なる専門性や視点を持つステークホルダーに対しても、テストの意図を分かりやすく翻訳し、納得感のある合意形成を図る力を求めています。説明は目的ではなく、関係者全員が納得し、より良い品質保証に繋げるための手段であると考えています。

合意形成を図るためには、単に作成したテストケースを示すだけでなく、テスト設計技法を初めとしたモデリングを活用し、テストの全体像を視覚化することが重要です。以下のスライドはモデリングを活用した簡単な例です。

デシジョンテーブルを用いた削減結果の例(筆者の過去登壇スライドより)

なお、「テスト設計スキルと説明能力」には、抽象化と具体化の行き来がうまくできることも含まれます。「抽象的な物事に対して、自ら具体化して説明する」「具体的な物事から抽象的な要素を取り出す」といったことも求めています。

強く求めていること2:開発者やPdMなど、QAエンジニア以外の人と積極的に議論できること

自身のテスト設計や結果を一方的に説明するだけでなく、他のメンバーの意見や視点も尊重し、建設的な議論を通じてより良いプロダクトを目指せる方を求めています。QAエンジニアの視点だけでなく、開発者やPdMの視点も理解し、多角的な議論ができることが重要です。

この考え方は、求める人物像に記載している「周囲の人々を巻き込み主体的に行動できる方」という要素にも繋がっています。また、これは10X全体として大切にしている「働き方指針」にも共通する価値観です。

「働き方指針」の詳細については、CEOの矢本が自身のPodcastで語っていますので、そちらをお聞きください。

open.spotify.com

どんなことができると、さらに良いと考えているか

応募資格(必須)に加えて、以下のスキルや経験をお持ちの方を歓迎しています。

  • 歓迎していること1.短いリリースサイクルでのQA経験: スクラム開発などのアジャイル開発における品質保証活動の経験、特に実装前からのテスト活動(シフトレフト)の経験。
  • 歓迎していること2.QAチームやテストのマネジメント経験: QAチームのリーダー経験やメンバー育成経験だけでなく、プロジェクトにおけるテスト技術を活用したテストマネジメント経験。

歓迎していること1.短いリリースサイクルでのQA経験

10Xではスクラム開発を主体としており、短いサイクルでのリリースに対応できる品質保証活動が求められます。そのため、実装後のテスト活動だけでなく、要件定義や設計段階から品質保証に関わる「シフトレフト」なテスト活動の経験を重視しています。

シフトレフトなテスト活動は、以前から推進しており、今後さらに強化していく方針です。

10Xにおける目指すQAの姿とそうしたいワケ | 株式会社10X

この部分について詳しくは、2月3日に登壇するイベントの中でも語る予定です。気になる方は参加申し込みをお願いします!

bitkey.connpass.com

歓迎していること2.QAチームやテストのマネジメント経験

単にチームをまとめるリーダーシップだけでなく、プロジェクトの状況に応じて適切なテスト戦略を立て、リソースを効率的に活用するテストマネジメントの経験を求めています。限られた期間で最大限の品質を確保するために、テスト範囲を適切に判断したり、テスト設計手法を工夫したりする能力が重要です。

例えば、テストに充てられる期間に対して実施を考えていたテストの数が多かった場合の対処として、「テスト実施の人員を増やす」というリソースマネジメントだけでなく、適切なテスト内容の選定というテスト自体のマネジメントも必要です。

求めていることの根底

ここまで述べてきたように、私たちが最も重視しているのは、テスト設計技術です。テスト設計を品質保証活動の基盤となる重要な技術と捉え、それを様々な場面で応用し、プロダクト全体の品質向上に貢献できる方を求めています。

10Xに入社して得られる体験

10XにQAエンジニアとして入社した場合、以下のような経験や成長機会を得られます。

  • 入社して得られる体験1.開発チームの一員としての早期からの貢献: 開発の初期段階から品質向上に積極的に関与し、プロダクトの成長に貢献できます。
  • 入社して得られる体験2.経験豊富なメンバーとの協働: 私(ブロッコリー)や、シフトレフトを推進するこじしょーさんをはじめとする優秀なチームメンバーと共に、テストに関する深い知識やノウハウを追求できます。
  • 入社して得られる体験3.組織とプロダクトの進化への貢献: 変革期にある10Xにおいて、組織やプロダクトが進化していく過程に主体的に関わり、大きなインパクトを与えることができます。

入社して得られる体験1.開発チームの一員としての早期からの貢献

「強く求めていること2」で書いている通り、QAエンジニア以外の人との議論を求めています。要件定義や設計段階から開発チームに参加し、品質の視点から意見を発信することで、手戻りを防ぎ、より効率的に高品質なプロダクトを開発できます。

入社して得られる体験2.経験豊富なメンバーとの協働

品質管理チームには、多様な経験と専門性を持つメンバーが在籍しており、互いに協力しながらテスト技術や知識を深めることができます。

例えば、こじしょーさんがQAエンジニアを開発チームの一員へと変革してきた経緯については記事を書いています。

product.10x.co.jp

カジュアル面談や選考の過程で、10Xの品質管理チームのメンバーとも会話してもらえればと考えています。

入社して得られる体験3:組織やプロダクトの圧倒的な進化に向き合えることができる

現在、10Xはネットスーパー事業のさらなる成長に加え、新規事業として小売DXにも積極的に取り組んでいます。

新規事業に対してのスタンス

新規事業では、「創業して初めて作ったプロダクトと全く同じ手法で事業・プロダクトを作り込む」と、矢本は自身のPodcastで語っています。

新規事業について詳しくは、矢本のブログ記事をご覧ください。(特に「小売DXへの事業拡大」の部分に新規事業への想いを書いています)

note.com

新規事業の具体的な内容については、カジュアル面談などでお聞きいただければと思います。

既存のネットスーパー事業に対してのスタンス

既存のネットスーパー事業も変革期を迎えています。それに伴い、組織、プロダクト、プロセスなど様々な面で大きな変化が起こっています。もちろん大変ではありますが、その分、より刺激的な毎日になると思います。(私自身、刺激的な日々を過ごしています)

様々な変化が起こってはいますが、10Xでは引き続き小売業に向き合っていきます。先日公開した矢本のブログ記事「複利の経営」という記事を読んでいただければ、より長期的に小売業に向き合っていく姿勢が見えるかと思います。また同時に、品質に対して10Xがどう向き合っているかも、同記事を読むことで理解できるかと思います。

note.com

おわりに 〜転職活動は双方向のマッチング〜

この記事では、10XがQAエンジニアに求めること、そして入社して得られる体験について詳しく説明しました。

転職活動は、企業と求職者の双方が互いを理解し、最適なマッチングを目指すプロセスだと考えています。選考過程では、「求職者が10Xにマッチするかどうか」を我々が見極めていると同時に、「10Xでの働き方やメンバーが自分とマッチするかどうか」を求職者の皆さんが見極める場だと考えています。

カジュアル面談や面接を通じて、皆さんが「10Xという会社が自分に合うのか」「ここでどのように成長できるのか」をしっかりと見極めていただければ幸いです。

少しでも興味をお持ちいただけましたら、ぜひご応募ください。

QAエンジニア / 株式会社10X

また、応募の前にカジュアル面談をしたい場合は以下のページからカジュアル面談を申し込んでください。

応募前にカジュアル面談をご希望の方はこちらからお申し込みください。

小売のプロダクトに向き合う品質保証についてお話しませんか? | 株式会社10Xの採用募集 | YOUTRUST

皆さまからのご応募を心よりお待ちしております!

*1:詳しくは最新版のJSTQB FLシラバスをご覧ください。本記事執筆時点の最新版(Version 2023V4.0.J02)ですと、「1.1.2 テストとデバッグ」に記載があります

ソフトウェアエンジニアとして今 10X に入社する理由

この記事は、10X 新春ブログリレー 2026 の 1月24日の記事です。


2026年1月 にソフトウェアエンジニアとして入社した @omuomugin です。

入社してまだ1ヶ月も経っていませんが、早くも毎日が新しい発見と刺激に満ちています。
この記事では、私が 10X に入社を決めた理由と入社後に感じていることについて入社したての目線で書きたいと思います。

また、10X では絶賛ソフトウェアエンジニアの採用を強化しており、この記事を通して少しでも魅力が伝わればと思っています (カジュアル面談お待ちしています)。

open.talentio.com

入社を決めた理由

10X では、「小売業の未来を拓く」を ミッションに掲げて おり、Stailer ネットスーパー を初めとして小売業という誰しもが日常的に利用する事業領域と向き合っています。

自分の家族や友人が利用する可能性のあるプロダクトに関わることができる、この身近さに、まず何よりも高い魅力を感じました!

また、個人的にはソフトウェアプロダクトが溢れている現代において大きな社会的なインパクトを残すためには、深く関わっていくことは当然として、地に足をつけた上で長期に関わっていく必要もあると考えています。
その点、10X では経営チームの多くが10年コミットすることを発信しており、この覚悟に強く惹かれました。

参考:

特に2024年に行われた構造改革は、様々な苦悩があったことは想像に難くありませんが、私にとっては「深く、長く」小売業に向き合っていくという本気度を感じる出来事でした。
この決断力を見て、入社するという意思決定に至りました。

参考: 代表 矢本に聞いてみた! 「最近の10Xについて詳しく教えてください!」 | 株式会社10X

入社してみて感じること

ここからは入社してから特に印象に残っている面白さやチャレンジについて書いていきます!

  • 小売業特有の奥深さ
  • 広いドメインを少人数で担当する責任とインパクト
  • プラットフォームとしてのチャレンジ

小売業特有の奥深さ

ネットスーパーでは、通常のECサイトとは異なり注文した時点から最終的に請求される金額が変わるケースがあります。
例えば、お肉などはグラム売りをしているため、実際に店舗で計量するまで正確な金額が確定しません。
また欠品が発生した場合でも請求金額が変わってしまいます。
こういった特徴をシステムとして実現していく必要があります。

他にも店舗のバックヤードの大きさは当然店舗ごとに異なっています。
「Stailer」がシングルピッキングに対応し、店舗状況に合わせてトータルピッキングとの切り替えが可能に にもある通り、バックヤードが小さい店舗ではその店舗に合わせた業務の仕組みを提供する必要があります。

このように実際の物理的な世界に業務を提供するからこその制約、面白さ、奥深さが多く存在します!

広いドメインを少人数で担当する責任とインパクト

自分は「お取引チーム」という注文から配送まで広くドメインを担当するチームに配属されています。
実は「お取引チーム」に限らず、全てのチームが比較的広範なドメインを驚くほど少人数で担当しています。
ただし、それは1人1人が無理をして成り立っているわけではありません。
むしろ働く場所や働き方は柔軟で個々に委ねられています。

参考: “働き方指針”のリアルを語る座談会 〜フルリモートでも出社でも。10Xのエンジニアが実践する“最適な働き方”〜 | 株式会社10X

もちろんそれだけ責任やプレッシャーも感じますが、1人1人のインパクトもその分大きく、今の事業フェーズでも大きな活躍の機会が十分あると感じています!

プラットフォームとしてのチャレンジ

10X が提供している Stailer ネットスーパー はプラットフォームとなることを目指しています。
パートナー毎に個別開発をしていくのではなく、必要な機能を一般化、抽象化した上で汎用的にシステムとして実現することには多くの技術的なチャレンジがあります。

入社して日が浅い中でも「どう抽象化すべきか」の議論を目にする機会があり、全員が本気でプラットフォームとしての理想形を追求している姿勢に日々刺激を受けています!

おわりに

入社してまだ間もないですが、すでに「ここで長く挑戦したい」と感じています。
小売という誰しもが日常的に関わるドメインを一緒に「深く、長く」考え尽くしませんか!

open.talentio.com

open.talentio.com

複雑なKubernetes Manifestに立ち向かうためのHelm移行と運用の工夫

この記事は10X 新春ブログリレー 2026の1月23日分の記事になります。

SREチームのid:horimislimeです。今回はチームでこれまでに取り組んできたことの1つとして、弊社Stailerの機能提供に使っているKubernetesのmanifest改善について紹介します。

続きを読む

チーム境界をメンテナンスし続ける営み

この記事は10X 新春ブログリレー 2026の1月22日分の記事です。


ドメインベースの開発体制から3年

10Xの開発チームがドメインベースの開発体制へ移行してから、約3年が経過しました。

product.10x.co.jp

改めて当時と比較してみると、認知負荷の増大やオーナーシップの欠如といった課題は大きく改善したと感じています。もちろん新たな課題や難しさもありますが、ドメインベースへの移行自体は、総じて進めてよかったなと言い切れる試みでした。

この記事では、そんなドメインベースの体制の「チームの境界」という点にフォーカスして体制移行時にどのように初期的な境界を決めたのか、そしてこの3年間でその境界をどう見直してきたのかについてお話をしてみようと思います。

初期的な境界の決め方

初期のチーム境界と担当ドメインは、以下のような手順で定義しました(実際には1〜4がスムーズに進んだというよりは、何度か行き来しながら議論を繰り返して初期的な形に着地しました)。

続きを読む