10X の検索を 10x したい

いやー、まいったね。

入社して三ヶ月が経ちました @metalunk です。この三ヶ月は検索インフラの改善に取り組み、検索速度 10x, インフラコスト 80% 減の成果が出ました。この記事では検索インフラ改善でやったことを説明します。

ところで、検索インフラの改善ができるということは、先人たちが検索機能を作り、PMF してサービスが利用されるようになったおかげです。感謝して改善しましょう。

2021年12月の Stailer の検索

10X は開発不要でネットスーパーアプリを立ち上げられるシステムである Stailer を開発しております。Stailer での購入のうち 35% が検索経由で行われており、検索はとても重要な機能です。

しかし、2021年12月、増加するリクエストによるサーバー負荷の増大、速度の低下に悩まされておりました。一時的にサーバーを増やし、スケールアウトをすることで対処をしていました。

問題の調査

Stailer の検索は Elasticsearch を使って実装されており、インフラに Elastic Cloud を利用しています。インフラ Metrics を Grafana で分析し、次の問題点がわかりました。

  • ピークタイムの CPU usage が高いこと
  • 平均 Response time が遅いこと

Response time は 95 percentile よりも average の方が大きいことから、ボトルネックになっているクエリがあると予想しました。

ボトルネックのクエリを発見するために Slow log を出力しました。Elasticsearch で Slow log を出力するには、warn, info, debug, trace それぞれの閾値を設定し、さらにどの閾値までログを出力するかを設定します。 https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-slowlog.html

次に、Elastic Cloud の画面をポチポチし、分析用 Elasticsearch にログを流す設定をします。これで分析用の Elasticsearch を向いている Kibana からログ解析ができるようになりました。

調査の結果、ボトルネックになっていそうなクエリを発見し、Kibana の Dev Tools の Search Profiler を使ってクエリの解析をしました。

Search Profiler ではこんな感じに、内部的にどんな Lucene クエリが発行され、どれくらい時間がかかっているのか調査できます。モザイクを不必要に多めにしているのは、隠されると見たくなる人間の真理を利用し、カジュアル面談に誘導するためです。Twitter で声かけてください。

long -> keyword で検索速度 10x

Elasticsearch には mapping という機能があり、 field ごとに type を指定できます。type は document から自動で推測してもらうこともできますが、Stailer では mapping を明示的に指定してあります。

問題のクエリを Search Profiler で眺めていると、ある long 型の field による絞り込みで Lucene の PointInSetQuery を発行しており、とても遅いことに気づきました。詳しい Lucene の実装を知らないので想像になりますが、long 型の field を検索したかったら木構造を使うとして O(logN) ほどかかるでしょう。

そこで、サーバーサイドの実装を読んでその field の使われ方を見てみると、enum 的な使われ方をしていることがわかりました。enum のようなデータは keyword 型にすることで、 Inverted index が生成され、検索時に O(1) で絞り込めます。計算量で大きな改善が見込めます。

実験環境で type を変更して Search Profiler で確認すると、クエリ単体で 283x 高速化することがわかりました。リリースしましょう!

新しい mapping を作り、適用のために Reindex を実行し、デプロイした結果、検索速度が 10x しました👏

さらに、CPU usage も 68% 減少しました👏

ちなみに、10x と書いたときは10倍のことで、10X と書いたときは会社のことなんです。

Deployment 引っ越しで費用を 80% 削減

さて、サーバー負荷と Response time には平穏が訪れましたが、スケールアウトしたままなので、お金はどんどん消えていきます。

Stailer の Elasticsearch の Instance type は I/O optimized という、大きな Storage を抱えたものを使っていました。しかし、Stailer の特性は、データ容量がそれほど多くなく、検索が多い、CPU heavy なアプリケーションです。CPU optimized instance に切り替えた場合の試算をしてみると、費用を 80% 削減できることがわかりました。直近の支払い金額が削減できるだけでなく、将来的にお客さまが増え、スケールアウトするときにも安く済みます。

わかりやすく例えると、毎日100個以上の小包をできるだけ速く配送したいんだけれど、これまではたくさんのハイエースを買って並列に配送していました。これからは少ない台数の速いバイクで配送します。バイク便です。

しかし、Instance type は途中で切り替えることができないため、新たに CPU optimized を設定した Deployment を作って引っ越す必要があります。さらに、データを失わず、無停止で引っ越しを完了したいです。

引っ越し計画の概要はこうです。

  1. Elasticsearch の更新をすべて PubSub 経由にする
  2. 新しい Deployment を作り index をコピーする
  3. Double write (両 Deployment への書き込み) 開始
  4. 新しい Deployment に参照を切り替える
  5. Double write 停止
  6. 古い Deployment を削除する

詳しく説明します。

1. Deployment の更新をすべて PubSub 経由にする

これまでは Firestore の元データに変更があったら、Cloud Firestore triggers から直接 Elasticsearch を更新していました。

それをこう変更します。Firestore の元データに更新があったら Cloud Firestore triggers が PubSub topic に publish する。それを worker が subscribe して Elasticsearch を更新する。

間に PubSub を挟むことで、複数の Subscription を生やして Double write ができるようになりました。さらに、耐障害性も向上します。

2. 新しい Deployment を作り index をコピーする

当初は、Elastic Cloud が提供している Restore from snapshot 機能を使って index をコピーしようとしましたが、動きませんでした。理由はいまだ不明で、現在も Elastic 社に調査してもらっています。

そういうわけで、代わりに Reindex from remote 機能を使ったツールを作ることにしました。ツールが行うことは、新しい Deployment に index を作り、mapping 等の設定をし、稼働中の Deployment から Reindex を実行することです。

3. Double write 開始

2つめの Subscription を生やし、それを subscribe して新しい Elasticsearch を更新する2つめの worker を動かせばふたつの Deployment を更新し続けられます。

あとは、安心なタイミングで参照を切り替え、後片付けをするだけです。

結果

無事故で作業が完了し、新しい Deployment の CPU optimized instance で検索機能を提供できる状態になりました。

これによって、費用を 80% 削減できました👏

これからやること

検索速度の改善や、インフラ負荷対策は楽しく、改善点は無くならないので永遠にできます。しかし、わたしたちの目的は、よい検索機能をお客さまに提供することであることを忘れてはなりません。

1月から3月まで取り組んだことで、インフラ負荷がひと段落し、速度も十分速い状態になり、費用も抑えることができました。

そしてついに、4月からは検索精度の改善を始めます。

CTR とゼロマッチ率を KPI とし、Dashboard を作りました。それらを改善する施策を 4, 5, 6月で実施する予定です。やっと精度改善できる状態になり、お客さま体験を改善できることにワクワクしています!

最後に

10X で Stailer の検索改善を一緒にやってくれる人を募集しております!

この記事のとおり、Stailer では検索改善を始め、やることがたくさんあります。エキサイティングな事業領域で、経験豊富でナイスなチームメンバーたちと、このサイズのスタートアップで一緒に働けることは素晴らしいです。

ソフトウェアエンジニア(検索)

そういえば、わたしは元々、機械学習で推薦機能を作るために入社したんでした。しかし、推薦の前にまずは検索、検索のためにまずはインフラということで検索インフラの改善をしておりました。

検索精度の改善に取り組み、採用もできた暁には、ついに推薦に取り組みたいと思っています。一緒に ML に取り組んでくれる人も募集中です!

ソフトウェアエンジニア(機械学習)

10X に SRE Team ができるまでとこれから

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 をリリースして以降、複数の国内大手企業で導入され、小売企業の DX 推進を支えてきました。これまでは「事業計画期」「事業立上期」の側面が大きく、サービスをローンチしてパートナーとの実績を積み上げ、Stailer としての方向性を確かめながら歩みを進めていたフェーズでした。

これからは「事業成長期」となりつつあります。 いまある Stailer をより確固たるプラットフォームとしての地位を確立させ事業を成長させていくフェーズです。そこで求められるのは開発だけではない「信頼性の確保」という目線です。今後、開発スピードにおいて、たとえ2歩下がることがあっても安心して3歩前にすすめるような提案・施策を展開していきます。

これまでの 10X では SRE チームはなく、開発メンバーでインフラを見れる人が開発・運用をしていました。Stailer ではインフラ基盤に GKE を採用しています(アーキテクチャについては @wapa5pow のブログも参照)。Kubernetes やその周りのエコシステムを効果的に活用し運用するには専任のメンバーがいたほうが良いことに加えて、10X では Stailer の成長によってパートナー企業や店舗数のもあり、二足のわらじでインフラを見れるような規模ではなくなってきていました。ましてやスケールだけではなく "Reliability" 観点でのインフラ投資も求められてきており、より一層 SRE としてチームを成立させることが急務となっていました。

1人目 SRE として僕が入社したタイミングでこれまでインフラを見ていたメンバーと一緒に SRE チームを作りました。SRE チームでは目下、次のことに取り組んでいます。

  • モニタリング基盤の Datadog 化
  • スケーラブルな Kubernetes Cluster のデザイン
  • スケーラブルな Kubernetes manifest management のデザイン
  • Incident response の型化とワークフローの整理
  • インフラリソースの Terraform 化
  • デプロイの高速化、リリースフローの刷新
  • Team development
  • ...

「Terraform の導入」などは事業のフェーズが変わったのを知るのにわかりやすい issue かと思います。Infrastructure as Code は「事業立上期」には必要のないことですが、今後よりスケールさせていくためには必要になってくることです。10X SRE チームでは、このようにこれから事業やインフラのスケールに必要なものもガンガン進めていきます。

まだできたばかりのチームです。最近、SRE チームで1年ロードマップを作成し、今後1年間 Stailer の成長を "Reliability" 観点でどのようにサポートしていくか、また、SRE チーム自体をどうスケールさせていくかをチームで定義しました (一部抜粋のみ。ロードマップのタイムラインは省略)。

1 year Roadmap (タイムラインは省略)

10X SRE ではスタートアップの成長期を支えることが好きな方、インフラ・チームの両面をスケールさせるのが好きな方を募集しています。JD も作成したのでぜひご覧ください。連絡をお待ちしております!

SRE(Site Reliability Engineer) / 株式会社10X

1人目のSETが話す10XのQAの今と今後

はじめまして。 2022年4月に1人目のSETとして入社するtarappoです。

以前、10XにおけるQAエンジニア/SETの募集記事として次のようなブログ記事を公開しました。

ここからの変化として1人目のSETである私の入社が決まりました。 しかし私1人の入社で募集が終了というわけではなく、10XではまだまだQAエンジニア/SETを必要としています。

一緒に動いてくれる人を強く募集している状態です。

そこで本稿では、10XにおけるQAエンジニア/SETに興味を持ってもらえるように次について書いていきます。

  • 現在の10XのQAの状況
  • 入社が決まってからまずおこなったこと
  • 10Xとして目指す姿
  • 今おこなっていること
  • どのような人を求めているか

まず最初に現在の10XのQAの状況について説明をします。

その状況をふまえて、まず私が最初におこなったことがなにか。 10Xとして目指す姿と、それに向かって私が今おこなっていることについて説明をします。

そして最後に10Xではどのような人を求めているかについて説明したいと思います。

現在の10XのQAの状況

現在の10Xにおけるリリースまでの流れをテストというフェーズに注目して簡略化して書くと次のようなプロセスになっています。 ただし、現状リリースするものすべてがこのプロセスにしたがっているわけではありません。

現状のプロセス例

今はこの図にあるように開発後にテスト(手動テスト)をおこなうフェーズがあり、このテストが終わったらリリースをしています。 このテストの箇所は、以前と異なり社内のメンバーではなくて第三者検証会社の方がおこなっています。

第三者検証会社の方が入ってくれたことで以前と比べて、リリース前にバグが一定見つかりリリース後の品質はよくなったといえます。

しかし、この手動検証をおこなうテストのフェーズで解決すべき課題がいろいろとあります。 たとえば、テストのプロセスが整備しきれていなかったり、不具合の可視化もできていません。 そのため改善サイクルをまわせているとはいえません。

また、現時点ではこのフェーズでテストをおこなうぐらいになっており、他のフェーズにおいて初期品質を上げるといった活動はできていません。

現状としては次のような状況になっているといえます。

  • テストフェーズでのQC(Quality Control)のみに頼っている
    • しかしすべてのリリースをコントロールできているわけではない
    • テストの結果をもとに何かしらの改善活動が進んでいるほどではない
  • QA(Quality Assurance)についてのコミットがほぼできていない
  • 全体的にどのような状況になっているかの分析ができていない

この状況のまま進んでいくと今はまだそこまで表面化していないものの、たとえば次のようなことが問題になってくると考えられます。 むしろ一部においては問題になってきているといえるかもしれませんが、可視化ができていないため定性的な判断しかできないという状況です。

  • リリース前のテストがメインとなっており、バグの発見が本来みつけられるべきフェーズより遅くなってしまう
    • 仕様作成時点や開発時点でみつけられたかもしれないバグがリリース前のテストでみつかっているかもしれない
  • リリース前のテストが徐々に肥大化して、テストフェーズがボトルネックになる
    • 結果としてリリース前のテストでおこなえる範囲がさらに狭くなるかもしれない
  • テストフェーズに依存してしまい初期品質が徐々に悪くなってくる

これらの課題を対処するために、テストのフェーズに関わる人員をとりあえず増やしてリリース前のテストを人海戦術でおこなうようにするというのがとれる姿の1つです。

しかし、そのような場当たり的な対応だと一定期間は一部の課題において有効になるかもしれませんが、将来的に違う課題をうみます。

そこで、10Xにおいてはどのように進めていくかについて考えました。 次に入社が決まってからおこなったことについて説明をしていきます。

入社が決まってからおこなったこと

入社が決まってから週に数日だけ業務委託として働いています。 その業務委託の期間にどのようなことをおこなったかについて、説明をしたいと思います。

10Xの選考には「トライアル」というのがあります。 かんたんに説明すると、社内の情報にアクセスができる状態にしてもらった上で、10Xの業務の中でインパクトのあるイシューに対して取り組みをおこなってみるというものです。 トライアルについては次のブログに書かれているので読んでみてもらえればと思います。

私はトライアルで、「プロジェクトの品質」や「開発生産性」についての現状を把握するためにSWEのメンバーやその当時検証に携わっていたメンバー(PdMやCSの方)からいろいろと話を聞きました。

今の状態(プロセス、自動テスト、検証にまつわるいろいろな情報)を聞いた上でおこなうべき課題をリストアップして、なにもしないことによる今後考えられるリスクや取り組む場合の優先順位とその理由をまとめました。

なので、業務委託で仕事を進めていく中で最初はトライアル時点でまとめたことをもとに進めようと思っていましたし、実際少しだけ着手をしました。

しかし「10XにおけるQA体制がいろいろと整っていないという状態」と「そこまで手を動かす時間が私にない」という制約の中でリストアップした課題を進めるのは、10Xにおける変化のスピードに対してついていけずに、私自身がボトルネックとなります。

そこで、わたしが最初におこなったことは「今後の土台作り」としてのQA体制の構築のための準備でした。 その準備をおこない、少しずつ土台を整えていくことに注力をしました。

QA体制の構築のための準備と最初の一歩目

QA体制を構築するために、まず自分たちがどのような姿を目指すかといった最初のゴールが重要です。 そして、その目指している姿にするためにリードしていくQAに関わる職種の人たちの採用や体制づくりが重要となってきます。

そこで、まず「10XにおけるQAはどのような姿を目指すか」について考えました。

目指している姿をかんたんに説明すると次のような姿です。

  • (1)リリースの前のテストフェーズに頼るのではなくてさまざまなフェーズでテストができている
  • (2)QAに関わる職種のメンバーだけでなく品質をつくりあげていくのは「全員」であるというスタイル

これにより次を達成したいと思っています。

「より早い段階で問題をみつけフィードバックをして、より早い段階で解決できる」

そこで次にこの姿を目指すにあたってどのように進めていくかについて次を1つ1つ考えました。

  • どのような状態になっているのがゴールに近づいているといえるか
    • その状態になるためにはどのようなことをおこなう必要があるか
  • 進めていくにあたってどのようなQA体制が必要になるか
    • その中でどのようなメンバーが求められるか

つまり「10Xではどういう姿を目指していて」「そのためには何をおこなう必要があって」「それを進めるためにはどういった人が必要か」をまとめました。

これらのまとめた情報を、10Xのメンバーにも共有して協力してもらいました。 その中で、いろいろな方とカジュアル面談などもおこないました。

その結果もあり、今回1人目のQAエンジニアの採用が決まりました。 しかし10Xが目指す姿を達成するにはまだまだQAエンジニア/SETが必要です。

次に私が今おこなっていることや今後の展望を説明して、そのような中でどのような方を現時点で求めるかについて説明したいと思います。

今おこなっていること

上述したようにまず最初に「今後のQA体制のための土台づくり」をすすめました。

今は新たなメンバーが入ってきたときにバリューを発揮できるようにそれ以外のことも少しずつですが進めています。 主に次の3つのことをすすめています。

  • (1)データの可視化と分析
  • (2)テストのプロセス改善
  • (3)10Xメンバーのソフトウェア品質・テストに関する知識の向上

この3つについて次にかんたんに説明していきます。

1つ目は「データの可視化と分析」

さまざまなデータを可視化し分析できるようにして、改善サイクルをまわせるようにすることは重要です。 まずデータの可視化ができるように整備するところからになりますが、最初のターゲットとしてバグチケットに対して可視化を進めています。

現在、バグチケットはテストフェーズに限らずみつけた時点で起票しているもののその情報を活用できる状態にはなっていません。 そこでバグチケットに記入するべき内容の整理や起票後のフローを整えたりと少しずつ進めています。

2つ目は「テストのプロセス改善」

当然ですが、今もリリースはし続けています。 目指している姿に進めつつも、守るべきところは守る必要があります。

上述したようにテストのプロセスはまだ整備しきれていない状況です。 そこで、現状のプロセスをドキュメントに起こしつつやるべきアクションを1つ1つリストアップして優先順位をつけています。

3つ目は「10Xメンバーのソフトウェア品質・テストに関する知識の向上」

目指すべき姿は全員で品質を作り込んでいくというのがあります。 そのために、10Xのメンバー全員が「ソフトウェア品質やソフトウェアテスト」にたいして知識をもっていることが望ましいです。

そこで、まず現状を把握するために10Xのメンバーに「ソフトウェア品質・ソフトウェアテスト」に関するアンケートを実施しました。 この結果をふまえて、社内勉強会などを予定しており準備を進めています。

この数ヶ月の間、QAに関わっていろいろと学んだ10Xのメンバーが数名います。 その方たちの姿を見て、私はこの目指す姿を達成できると思っています。

参考までに次の資料を見てもらえればと思います。

上述したことはまだ終わってませんし、それ以外にもまだまだやるべきことは多いです。 このような状況の中で「どのような人を求めているか」について次で説明したいと思います。

どのような人を求めているか

目指す姿を達成するために、なにをおこなう必要があるかを現状を把握しながら1つ1つやるべきことを進めていきます。 そのためには次のような人を求めています。

  • 目指す姿に対しての課題とそれに向けてのアプローチを周りを巻き込みながら推進できる
  • プロダクトに向き合ってリリースを支える」にはどうすればよいかを考えられる
  • 今のフェーズでなにをするべきかを自ら考えて動くことができる

また、今目指している姿が10Xとして最終的な姿ではあるとは思っていません。 さらにその先を一緒に考えることができればと思っています。

JDの更新をしました

今回、現状を踏まえた上でJDの更新をおこないました。 上記以外のスキル面など他のことについてはJDに記載しています。

今、公開しているJDは次の「QAエンジニア」と「SET」の2種類になります。

2種類に分けていますが、まだ立ち上げフェーズであるためそれぞれが得意としているスキルを活かしつつ、他のこともおこなえる範囲でおこなっていくこともあります。 そういうこともあり上記のJDには細かく明記してない箇所もありますが「テスト戦略、テスト観点、テスト設計」などを得意とする方も強く求めています。

おわりに

10XのQAの現状や今後についてかんたんに説明しました。 ここまで読んで10XのQAエンジニア/SETに興味を持っていただけたら嬉しいです。

また、今回書いた内容は執筆時点での状況になります。 10Xは日々変化しているので、現時点での状況をもっと詳しく聞きたいという場合は次からカジュアル面談に応募してもらえればと思います。 ぜひ、上記のような話(もちろんそれ以外でも)で盛り上がれればと思います。

是非、一緒に10Xをさらに伸ばしていきましょう。 応募をお待ちしています。

最近の10Xプロダクトチームのあれこれをまとめた資料を公開します

こんにちは、10Xデザイナーの日比谷すみれ(@suuminbot)です。

この度、10Xプロダクト部門に特化した紹介資料を公開することになりました!

転職先を探している・10Xチョット気になっている…そんなプロダクト開発に携わるすべての方に、少しでも10Xプロダクト部門のことをお伝えできればと思い作成しました。
ぜひご覧ください!

10Xプロダクト部門紹介資料

10Xプロダクト部門 紹介資料(新しいタブで開く)

この資料でお伝えしたいこと

今回、次の3点のことをお伝えしたいと思いこの資料を作成しました。

1. 挑戦している課題、提供しているサービスの具体的なイメージを持てる

10Xというと、献立推薦アプリ「タベリー」(※サービス終了)やネットスーパーのアプリを提供している会社というイメージをお持ちの方が多いと思います。

また、「Stailer」って名前は聞いたことあるけど具体的にどんな事業・プロダクトなのかはよくわからない、というのも実際によく伺います。

f:id:suuminbot:20220314103830p:plain

事業概要

サービスイン当初は「ネットスーパーのモバイルUX」にフォーカスしていたStailerですが、実は2021年からStailerは大きく進化。

ネットスーパー運営に必要なすべてのシステムをプラットフォームとして提供しています。じゃぁ具体的に提供しているプロダクトってどんなもの?ユーザーは誰?といったことをご説明しています。

2. 組織・チーム体制に関して具体的なイメージを持てる

f:id:suuminbot:20220314103840p:plain

組織体制

f:id:suuminbot:20220314103850p:plain

チームでの取り組み

2020年末時点では15名だった社員数も、2022年3月現在では55名と大きく拡大しました。

こういった組織人員的な拡大と事業の拡大を背景に、2021年秋〜冬にかけて大幅な組織体制の変更がありました。

組織体制の変更については代表の矢本のブログや、つい先日10Xブログでも矢本とCTO石川の対談ポッドキャストを文字起こしした記事が公開されました。

中にいるいちメンバーからしてもこの改善は大きく、より「チーム」を意識してミッションに集中できる体制になったと感じています。

今回の資料ではこの変更についてもお伝えしたく、いくつかのページでご紹介しています。

3. 中の人の雰囲気が伝わる

f:id:suuminbot:20220314103902p:plain

チーム・メンバー紹介

カジュアル面談で頻繁に「実際雰囲気どんな感じですか」「近づき難いイメージありますが実際はどうですか?」というお言葉をいただきます。。(私も入社前は同様のイメージを持っていました…!)

実際はそんなこともなく、落ち着いていて優しい人が多いのですが、テキストだとなかなか伝えづらい…!

とはいえ少しでも中の人の雰囲気が伝わるといいなと思ってメンバー紹介ページや、10Xの好きなところをヒアリングしたページを追加しました。

最後に

今回作成した資料が、10Xに興味を持ってくださっている方のお役に少しでも立てば幸いです!

また、随時内容は更新していく予定ですので、最近10Xどうなのかしら?と思った際はまたこの資料を見てもらえると嬉しいです。

10Xではプロダクト開発に関するあらゆるポジションを募集しています!
10Xのこともっと詳しく知りたい・中の人に話を聞いてみたい!と思っていただけた場合は、是非お気軽にお知らせください。

▼ Meetyでカジュアル面談を常時受け付けています!

meety.net

▼ 定期的にオープンオフィス(会社説明会)を実施しています。最近はオンライン開催です◎

docs.google.com

▼ 10X会社全体の採用情報はこちらのページでご覧いただけます 🤝 募集中のポジションにつきましてもこちらからご覧ください!

jobs.10x.co.jp

10XはWomen Developers Summitにオンライン支援スポンサーとして協賛します

こんにちは!10X CCOの中澤(@riccha)です。

10Xは、2021年11月17日に開催される「Women Developers Summit(デブサミウーマン)」にオンライン支援スポンサーとして協賛しました。

event.shoeisha.jp

「Women Developers Summit」は、翔泳社のCodeZine編集部が主催するITエンジニア向けカンファレンス「Developers Summit」からスピンオフした、女性ITエンジニアが主役のカンファレンスです。今年が初回の開催となります。

10Xからは今回、登壇者はいませんが、スポンサーという形でタイムテーブルにバナーを掲載させていただきました。

f:id:dev10x:20211116100412p:plain (リンク先の女性メンバー紹介ページ Women Careers@10X もぜひご覧ください!)

さて、10Xのソフトウェアエンジニアは現在14名ですが、まだ女性メンバーはいません。 ※10Xはソフトウェアエンジニアを絶賛募集しています!!!

そんな中、なぜ今回スポンサーとして支援するに至ったのかをお話させてください。

10XのD&I Policy

10Xではミッション・バリューと同等に重要な価値観としてDiversity & Inclusion Policyを定めています。

それは、私たちがミッションに掲げる長期的に世の中に非連続(10x)な価値を生みだすためには、多様な価値観・経験・能力を持ったメンバーが集まり、背中を合わせてそれぞれの能力を発揮することが必須だと考えているからです。

また、10Xが提供するStailerは、ネットスーパーやドラッグストアECを通じて、日本中の誰かの家庭を支えるプロダクトです。

さまざまな環境にいるお客様の生活をより便利に変えていくには、多様な視点を持ったメンバーがプロダクトに関わることが重要だと捉えています。

エンジニア採用の現状

10Xの現状を率直にお伝えすると、全社の女性比率は約20%。中でもソフトウェアエンジニアにおいては女性が0%という現状があります。(※もともとエンジニアのバックグラウンドで、現在プロダクトマネージャーとして活躍しているメンバーは1名います)

f:id:dev10x:20211116101146p:plain Women Careers@10X より

現在ソフトウェアエンジニアのメンバーは、社員の紹介(リファラル)か、10Xの発信情報をみて直接応募いただいた方がほとんどです。

しかし、カジュアル面談等で多くの方とお話させていただく中でも、女性比率が非常に少なく、生活に根ざしたStailerというプロダクトの面白さや、家庭・プライベートを大切にしながらでも働きやすい10Xの環境、サポートの充実などの面白さなどをまだまだ伝えられていないという課題感を強く持っています。

また、IT業界での女性エンジニアの割合は約20%と言われており、そもそも日本のIT業界におけるジェンダーギャップには大きな課題があります。

これは社会構造的な問題でもあり、「女性にも入社してほしいけれど、市場にいないんだよね...」と言い続けることは問題の解決にはなりません。

中長期的な視点でも、アクションをしつづけることが、自社にはもちろん、スタートアップ市場にとっても重要だと考えています。

10Xは40人弱と、まだまだ小さいスタートアップです。私たちができることはわずかではありますが、自社に限らず女性のエンジニアやプロダクトに関わるメンバーが増えていくこと、中の人が仕事や職場、キャリアについて発信することは、未来に向けてとても重要だと考え、今回のカンファレンスの趣旨に賛同し協賛させていただきました。

11/17はデブサミウーマンで!

前置きが長くなりましたが、今回のWomen Deveropers Summit(デブサミウーマン)では、プロダクト開発やそのプロセス、登壇者の方のキャリアについてなどたくさんのセッションが予定されています!

視聴には事前申し込みが必要となりますので、興味をもった方はぜひご登録ください。

(ちなみに、デブサミウーマンの参加・視聴は性別問わず誰でも可能です!女性限定じゃないですよ〜!)

https://event.shoeisha.jp/devsumi/20211117

今回、10Xから登壇するメンバーはいませんが、12:15~13:10のオンライン交流会の時間には私も参加させていただきます。もし、10Xに興味のある方がいらっしゃればぜひお話させてください!

また、10Xとしては来年以降はメンバー登壇に応募できる状態にしていきたいですし、そうすべきだと強く思っています。 「ちょっと話しを聞いてみたいかも」「家庭を支えるプロダクトに興味あるかも」と思われた方は、ぜひオープンオフィスやカジュアル面談でお話できると嬉しいです!

オンラインオープンオフィス

docs.google.com

15分オンライン面談(Meety)

meety.net

それでは、当日をお楽しみに!

入社して1ヶ月のデザイナーが感じた10Xの3つの魅力

こんにちは!2021年の10月にデザイナーとして入社したmaasaです。

10Xに入社して1ヶ月が経過しました。入社してみて感じた3つの魅力について書きたいと思います。

こんな人に読んで欲しいと思っています。

  • 10Xのデザイン業務に興味のある方
  • 育児中の10X社員の働き方に興味のある方

生活から切り離せない分野の課題に真剣に挑んでいる

採用を受ける前から10Xのことは知っていました。 芯が通ってしっかりしていて、すごいメンツが揃っている会社、矢本さんのtweetから育児をしながら働く人たちへのフォローが手厚そうなイメージがあってすごい良さそう、と思っていました。

自分の理想の働き方の話をすると、仕事と趣味の境界線を限りなく無くしていきたいと思っています。

また、子供ができてからは次のような項目も理想の働き方として追加されました。

  • 働きやすさ
  • 自分のライフスタイルに沿った事業領域

私には2歳と4歳の子供がいます。 子供が小さいと、いつ子供が熱を出して保育園に行けなくなったりするかわからないし、家に子供がいると仕事のことだけ考える時間が減ってしまいます。

例えば、好きなことを仕事にしたり、生活から切り離せない分野のことを仕事にするとオフの時間も仕事の領域に関わっていられるので、仕事に関することをインプットすることが日常の一部になります。 こういう感覚で仕事をするとインプットのハードルを下げることができて気楽で良いなと思っています。

また、普段から実店舗のスーパーやネットスーパーを使っていて、日用品や生鮮食品を買う行為自体に日頃からストレスを感じていたので、Stailerのサービス領域に関しては共感しかありませんでした。

複雑なイシューに真剣に向き合うことができる環境

バックヤードで現場視察する図

入社してすぐ、お客様向けアプリ、スタッフアプリの細かな改善をしながらプロダクトのキャッチアップをしました。

Stailer」はBtoBtoCサービスであり、パートナー企業ごとに仕様が最適化されているのでキャッチアップするのがなかなか大変だと感じました。

ですが、入社してすぐに店舗に視察に行く機会を設けてもらい、バックヤードでのオペレーションフローを一通り視察させてもらうことができたので、スタッフ向けのオペレーションに関してはキャッチアップしやすいと感じました。

こうした環境が整えられているのも10Xならではだと思います。

実際に店舗では研修中のスタッフの方の後ろについて店内を回りました。

まず、基本的な操作に関しては悩まずに操作できていたのでアプリの設計自体に感心しました。それでも、後ろについて歩くだけで課題はいくつか発見できたのでまだまだデザイナーの介入の余地はありそうだと感じています。

直近は新機能開発が多いので出来ていないですが、落ち着いたらまとまった時間をとってスタッフの方向けにインタビューをしたり、エスノグラフィ等を実施してUX向上のための取り組みをしていきたいと思っています。

10Xでのデザイナーとしての仕事の面白さは - 複雑なイシューに真剣に向き合うことができる - 現場観察を重視する文化 - 各領域のプロフェッショナルとの協業 といった点にあると感じています。

「店舗スタッフ」「配送スタッフ」「お客様」と向きあうユーザーが複数いる上に、パートナーごとに業態が異なったり、都内や地方に住むユーザーでそれぞれコンテキストがバラバラ、といった点で取り組むイシューはとても複雑です。

これらを紐解いてプラットフォーム化することに面白さがあると思います。

また、「現場観察したい」と思ったタイミングで店舗に行けるところも社内の文化として良いところだと感じています。

何より、デザイナー以外も当たり前のように現場に赴き課題を把握することが文化として根付いているのは10Xの強みだと思っています。

複雑性の高い課題に向き合っているわけですが、各領域のプロフェッショナルが集まっていて、適切な領域のプロフェッショナルな人たちと協力して課題解決に取り組むことができるのでとても心強いです。

こういった自分の業務の先には、【半径1m以内の誰かを幸せにすることができる未来がある】と信じることができるのもやりがいに感じます。

家族や自身に何かあった時に安心して働くことができる環境・制度

「育児をしながら10Xで働けそうか?」この問いに関しては入社前に一番に感じていた不安でした。

入社前は「子供との時間も大事にしながら働きやすさを追求とかぬるいこと言えないんじゃないか」といった印象を抱いていたのですが、入社してそのイメージは変わりました。

週に1度ほど出社をしているのですが、17時にはスパっと業務を切り上げ帰宅する社員が女性問わず男性でもいたり、slackのattendanceチャンネルでは保育園の参観のために半休をとったり、パートナーの病院の付き添いのため中抜けしたりと、堂々と家族と向き合うことを公言し、それを後押しするやさしい空気感が醸成されているように感じました。

slack投稿一部抜粋

10Xの社員は何事にも真剣に向き合い、やるときはやるといったオンオフのメリハリがしっかりしている印象を抱いています。

会社としては人事制度「10X Benefits」を制定していて、入社時から有給が付与されるなど、安心して働ける環境が用意されています。

10Xの男性社員の育休取得率は100%で、働きながら育児をすることに対する共感が得やすい空気感というのはこういうところから来ているのだと思っています。

私自身も17:30には業務を切り上げ、子供を迎えにいきご飯を作り、家族で食卓を囲むという日常が送れています。

育児も仕事も全力で向き合いたい方にとっては最高の環境が用意されているのではないでしょうか。

【まとめ】 入社して感じた10Xの3つの魅力

  • 生活から切り離せない分野の課題に真剣に挑んでいる
  • 複雑なイシューに真剣に向き合うことができる環境
  • 家族や自身に何かあった時に安心して働くことができる環境・制度

この3点が、私が入社して1ヶ月で感じた10Xの魅力です。 最後に、10Xで働くことに少しでも興味を持っていただいた方はぜひ、エントリーお願いします!

10Xではデザイナーだけではなく複数の職種において絶賛採用中です!

詳しくは10Xの採用サイトをご確認ください!

10XはDroidKaigi 2021にサポーターとして協賛します! & 社員が登壇します!

こんにちは!10X Software Engineerの岡野(@operandoOS)です。

2021年10月19日(火) - 21日(木)に開催されるDroidKaigi2021にて、10Xはサポーターとして協賛します。 また、本記事を書いている 私(岡野)が登壇するので、そのことについて紹介させていただきます。

droidkaigi.jp

お話するセッションについて

まずは私がお話させていただくセッションの紹介です。 Day03となる10月21日(木)の16:00より 「できる!Android Framework Code Reading」というタイトルでお話します。

このセッションでは、そもそも「Android Frameworkってなに?」というところから、実際にFrameworkのコードをどのように読んでいくかなどをお話します。 具体的な内部構造の話よりも、「どのようにAndroid Frameworkのコードを読んで内部構造を調べるのか」をメインとして扱います。 Androidの面白さの一つでもあるソースコードを読んでAndroidがどのように動いているのか内部構造を理解する上で、参考になるセッションになればと思っています。

当日セッションを視聴していただき、聞いてみたい質問や深堀りして聞いてみたいテーマなどがありましたら、セッション終了後オフィスアワーの時間が用意されておりますので、ぜひそちらに参加して聞いていただけると嬉しいです。

スポンサーについて

今回 10Xでは初めてとなるスポンサー協賛を行うことになりました。 サポーターとしてDroidKaigiを応援しています!

10Xは、「10xを創る」ミッションのもと、スーパーマーケットやドラッグストアなどの小売チェーンがECを立ち上げるためのプラットフォーム「Stailer(ステイラー)」を提供しています。StailerはフロントエンドはFlutter、サーバーサイドはDart、また基盤としてGCPなどを利用しておりますが、これらは多くの技術コミュニティに支えられて発展してきたものです。

私たちも、身の丈にあう形で技術コミュニティへの貢献を行っていきたいと考えており、今回はサポーターという形で協賛させていただきました。

今後も、10Xの事業と親和性の高い技術や、私たちのポリシーに沿ったコミュニティ活動への支援を行っていきたいと考えています。

おわりに

当日はオンライン開催ではありますが、何かしらの形で参加者の皆様と交流できることを楽しみにしています!

それでは、当日をお楽しみに!

おしらせ

10Xではソフトウェアエンジニアを募集しています。 元々Androidアプリ開発をメインとしていたエンジニアが、10XではFlutterを使うことでiOSも開発も行ったり、サーバーサイドの開発も行ったりと色んな技術分野で活躍しています。 10X Product Blogを読んで少しでも10Xが気になった方はぜひ定期的に開催しているオープンオフィスやカジュアル面談などでお話できると嬉しいです!

docs.google.com