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のサービス領域に関しては共感しかありませんでした。

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

f:id:i_maasa:20211105213618p:plain
バックヤードで現場視察する図

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

f:id:i_maasa:20211105213825j:plain

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

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

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

f:id:i_maasa:20211105213737p:plain
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

10xな成長を支える一人目QA/SETを「いま」募集しています!!

はじめに

こんにちは!ソフトウェアエンジニアの yamakazu (@yamarkz) です。

タイトルにもあるように、10XではQA/SETのメンバーを絶賛募集しています!

今回はその募集の背景に踏み込みながら、どういった立ち回りを期待しているのか、どういった機会を提供したいのか、そして "今"だからこそ10Xを選んできて欲しい...!! という中の人の胸の内を紹介させてください。

本記事を読んで10XのQAやSETのポジションに少しでも興味を持っていただけると嬉しいです 🤲

speakerdeck.com

(会社や事業の紹介はカルチャーデックに譲ります)

10XのQA/SETのリアル

いきなりですが、10Xは今非常にカオスな状況です。🌪

毎日予知していなかった問題が足元で生まれ、それになんとか対処しながら中期で達成すべき目標に向かってチームで大きな課題に取り組んでいます。

カオスではあるものの社内の雰囲気は前向きで、「世に必要とされているものを作れている」「解決しなければいけない難しい課題にトライできている」という手応えを日々感じています。🚀

f:id:yamarkz:20211012190447p:plain
(お問い合わせの数が10xしそうだという見立てが立てられている、カオスな状況)

現在QAのポジションにメンバーはいません。手動テストを中心としたQA業務はプロダクトマネージャーやカスタマーサクセスのメンバーを中心に行っています。

メンバー各々がこれまで培ってきた経験値でプロダクトの品質をカバーしている状況で、「このやり方ってもっと改善できるよな」「もっとテストの負荷を仕組みで減らしていきたいな」と思いつつ、そこに飛躍的な変化を加えられないもどかしさを感じてます。

ソフトウェアテスト方面の話でいくと、サーバーのテストコードは8割ほど正常系をカバーしていますが、クライアントのテストコードはほぼありません。(!)

テストの実行環境などは一通り揃えていますが、クライアントはテストコード拡充に追いつけていない状況で、手動テストで機能品質の多くを担保しています。

パートナーが増えていく状況の中、クライアントであれどテストコードを整備しない状況にはもうすぐ限界に来るだろうと予想しており、今すぐにでも整備を進めたい気持ちです。

10Xの実態を赤裸々にお伝えすると、こういう感じです。🤭

目の前のカオスな状況に奮闘しながら、QA/SETの業務をメンバーの経験値でカバーしている状態で、プロダクトを成長させてきました。 しかし、自分たちが目指している理想状態とは程遠く、こういった状況を良いものに変えていきたいと思っています。

QA/SETのメンバーに期待したいこと

先の状況を踏まえて、本格的にQA/SETをお任せできるメンバーが必要 という危機感が強くなってきました。これはプロダクトチーム全員の総意です…!

QA/SETというポジションで募集を始めるにあたって、先にチーム内で認識を揃えるために「どういった動きを期待したいか?」という問いでワークショップを行ったりもしました。

f:id:yamarkz:20211012145529p:plain
(社内ドキュメントの一部を抜粋)

色々と意見や考えが出た中で、最終的には1.リードすること 2.見極めること この2つを新しいメンバーに期待したいという結論になりました。

現状、その領域のプロではないメンバーの中で至った結論なので、アマの一方的な希望になっているかもしれませんが、それでも今の難しい状況に向き合っているメンバーの中で、こんな役割をお任せできれば、チームのスループットが劇的にあがるはずだと確信しています。

この2つを満たした立ち回り、アウトプットであれば、具体のHowは問いません。

これは人によって色々なバリューの出し方があると思うので、バリューの基準だけを明確にして、それ以外は問わず、個人に任せたい(ぜひ、創意工夫してほしい...!)という願いからです。

10Xが提供できる/したい機会とフィールド

期待したいことを先に書きましたが、対して10Xが提供できる/したい機会ももちろんあります。入社/採用はお互いに渡せるもの、得たいものが一致しなければいけないものです。一方的に力を貸して欲しいと言うつもりはなく、むしろ10Xが提供できる機会は思う存分に得てもらいたいなと思っています。🤝

toC / toB 両方のお客様に向き合える機会

StailerはtoCとtoBのプロダクトで構成されているので、両方のお客様に向きあった課題解決の機会があります。toCは食品・日用品ECアプリ、toBは店舗の業務をサポートするアプリがメインで、それぞれに求められる品質水準やテストケースが異なるため、多様な機会を提供できます。

また、FlutterやFlutter for Web、Server Dartといったエッジの効いた技術選択 (参考) をしていたり、現場に躊躇なく足を運んでみたりする文化の中で働けるのも魅力かもしれません。

f:id:yamarkz:20211012185730p:plain
(現場に何度も足を運んでプロダクト検証を行う)

スクラッチで10xな品質保証文化と仕組みの構築とチームビルドの機会

QA/SETどちらも1人目という立ち位置になるので、組織に品質保証文化や仕組みを0から作っていくことになります。これは非常に大変ですが、0から作れる機会自体が少ないと思うので貴重な経験になるかと思います。

入社したらマルっとお願いしますと言うつもりは全くなく、文化と仕組みづくりは組織全体で一丸となって作り上げたいという強い思いがあるので、ぜひ一緒に作っていきたいです。💪 🔥

自律した個人と背中を合わせて気持ちよく働ける機会

事業やプロダクトも大事ですが、一番は一緒に働くメンバーが大事だと個人的には思っています。10Xには自律したメンバーが揃っており、背中を合わせて気持ちよく働けることを保証します。(自信100%)

product.10x.co.jp

(トライアル文化について)

組織文化や今の状況にマッチして働けるか不安に思うこともあるかもしれませんが、10Xには "トライアル" という選考ステップがあり、候補者の方に10Xという環境を試してもらう場を用意しています。

これは社内のドキュメントやソースコード、Slackの日常会話、という大体の社内情報にアクセスしていただいて、活躍できるイメージを互いにすり合わせる機会になるので、違和感なく働けることを確認した上で意思決定できます。

Day1からどんなに立ち回りになるの?

QAポジションであれば、リリース予定の新規機能の手動テストとそのテスト設計から入ってもらうことになりそうです。

まずは足元のテスト業務を進めてもらいながら、仕様やサービス構造の理解を深めてもらい、徐々に仕様調整部分でのレビューや社内のガイドライン整備などに入って、プロダクト全体のプロセス改善に踏み込んでいって欲しいです。

最終的にはプロダクトマネージャーやカスタマーサクセスのメンバーと協力しながら、テスト業務の推進をお任せすることになると思います。

SETポジションも、足元のユニットテストの拡充やインテグレーションテストの整備からスタートすることになると思います。

それ以外にも運用環境の整備 (CI/通知/計測) から始めてもらってもいいですし、新規開発でクリティカルなシーンがあれば、そこのヘルプに入ってもらうかもしれません。

いずれのポジションも、いきなり高いレベルのアウトプットを求める様なことはなく、キャッチアップを重ねながら徐々に個人のスペシャリティを発揮してもらいたいです。

最終的には逆算性の高いアウトプット、先の状態見据えて「今こうしておいた方が安全です」という予防線を敷く立ち回りをしてもらえると最高です。👍

"今" だからこそ楽しめること

CTOのishkawaさんも言っている様に、えらい波がきてるので "いま" 入社することをオススメしたいです。🏄‍♂️

いつか機会があれば〜ではなく「今が1番ですよ」と言わせてください!

1人目、2人目というポジションは敷居が高く感じられるかもしれませんが、リードすることにトライしてみたい気概と、良い仕組みでプロダクトを支えたいという熱量があれば十分楽しめる環境だと思います。

10Xはまだ30名強の規模であるため、与えられる影響の幅がとても広いです。成長によって受ける変化ももちろんですが、与える変化も大きく楽しめるはずです。

f:id:yamarkz:20211012150908p:plain
(新メンバーの非連続な提案とアウトプットが素晴らしかった時の図)

「もっとこうした方が良いと思う」というフィードバックや、「こうしませんか?」という提案もウェルカムです。

「それは10xなアイディアだ!」となれば、わいわい!とみんなが自然と巻き込まれてグイグイ話が進んでいく文化があるので、アイディア出しから気兼ねなく行えると思います。ぜひQA/SETの専門性で、Stailerをもう一段階上のステージに引き上げてください。🔥

最後に

ここまで読んでいただきありがとうございました。🙏

10XのQA/SETポジションのイメージが読む前よりも膨らんでいただけたら、嬉しいです。

10xな成長を支えていけるQAとTest codeをプロダクトに実装していきましょう!

QA/SETポジションでの応募お待ちしてます。

open.talentio.com

open.talentio.com

Stailerのサーバーアプリケーションで採用しているDartパッケージ

はじめに

こんにちは!ソフトウェアエンジニアの yamakazu (@yamarkz) です。

ネットスーパーを日常使いしていますが、スーパーに並ぶ商品の季節感が好きで週に1度は店舗に足を運びたくなってしまい、結局リアル店舗の利用は外せないという生活をしています。

さて、前回は開発文化の話を取り上げて紹介しましたが、今回はより技術寄りな話としてStailerのサーバーアプリケーションで採用しているDartパッケージを紹介します。

類似のトピックとしてアーキテクチャなどは石田さん (@wapa5pow) がリリース直後に紹介してくれていますが、Stailerで使われている具体的なパッケージなどはまだ紹介していませんでした。

StailerのサーバーはDartで書かれており、世間的にもあまり例がない技術選定がされています。(以下参考)

type.jp

採用例が少ないDartという技術選択の中で得た知見をベースに、どういったパッケージを使っているのか?どういったパッケージがおすすめなのか?という問いに答えていこうと思います。

本記事を読んで、Dartでサーバーアプリケーションを開発することに少しでも興味を持っていただければ嬉しいです。😄

パブリックパッケージ

※ ⭐️ の数はパッケージの良さを個人的な推し度で表したもの

. gRPC with Protobuf (⭐️⭐️⭐️)

pub.dev

StailerのWeb APIではgRPCが採用されています。

Protocol Buffersでスキーマを定義し、クライアントとサーバーでインターフェースを共有して、リクエストとレスポンス処理を行うという一般的な使い方です。

10Xではタベリーの頃からgRPCを採用しており慣れていたのと、REST APIにしなければいけない制約もなかったので、引き続きgRPCを採用したと聞きました。

Dartの公式ではHTTP ServerにはShelfというパッケージが推奨されています。 個人的にはShelfを使ってみたい気持ちもありますが、gRPCの生産性やパフォーマンスの高さが優れている面を評価すると、実務ではgRPC優勢かな〜という気持ちです。

. retry (⭐️⭐️⭐️)

pub.dev

リトライ処理にはretryを採用しています。

Stailerは単体でもサービス立ち上げが可能ですが、一部パートナーのAPIを利用して機能を実現している箇所があり、そういったシーンで活用されています。

APIリクエストは大半が成功しますが、稀になんらかの予期せぬ理由で失敗することがあります。 イレギュラーなケースに遭遇してもリトライでカバーできる状態を作り、機能の完全性を担保することは運用で楽をする上で不可欠です。

httpの標準の機能でもあるので、それだけでよければそっちを使っていたりもします。

. clock (⭐️⭐️⭐️⭐️⭐️)

pub.dev

"時間"をシステムで扱うのは難しいですが、clockを使えば扱いやすくなります。

clockは現在時刻の概念を簡単に扱えるようにしてくれるパッケージで、活用するとテスタビリティが向上します。

    test('error if delivery date has not been reached', () async {
      await withClock(Clock.fixed(DateTime(2021, 09, 28, 13, 30)), () async {
         // Written test code
      });
    });

(withClockで特定の日時で処理を実行する例)

特定の時間順序に依存したテストを書きたい場合は、clockを用いて時間操作を容易にしておき、指定時間に処理を実行することを想定したテストコードを記述すると良いです。

主にdailyのバッチ処理系のテストコードで活躍してくれる欠かせない存在です。

. euc (⭐️⭐️⭐️)

pub.dev

Shift-JISのファイルを扱うためにeucを採用しています。

Stailerはパートナーから膨大な量のデータを連携しています。共有されるファイルにはShift-JISが採用されているケースもあり、Shift-JISも扱えるようにするためには文字コードの変換が必要で、そこで利用するのがこのパッケージです。

大抵のことはカバーしてくれるので重宝しているのですが、1つだけ惜しいところがstream処理過程でconvertする機能が未対応です。 ここは自前で列分割を行うパッチ処理を挟んで対応していたりします。

. sync (⭐️⭐️⭐️)

pub.dev

並行処理を行うために採用しています。

syncはGo言語にあるパッケージの思想をDartで表現したもので、インターフェースなどは同じです。StailerではこのsyncパッケージをラップしてConcurrentクラスという表現を作り、並行処理を行なっています。

syncによって1店舗あたり2~3万件ある商品データを350店舗分決まった時間内に同期することができるようになります。スケーリングの観点では絶対外せないパッケージです。

[余談] Null Safety化を進めるために沢田さん(@swdyh)がシュッとPRを送ってくれてたりします 🙏

. collection (⭐️⭐️⭐️⭐️)

pub.dev

複雑な配列操作を行う際にはcollectionを使うのがおすすめです。

firstWhereOrNullwhereNotNull でNullを上手く扱った処理を書いたり、 UnmodifiableListView で配列操作に制約を加えたりもできて安全に便利な配列操作が実現できます。使わない選択肢がないくらい便利です。

. sentry (⭐️⭐️⭐️)

pub.dev

エラーログのトラッキングではSentryを使っています。

サーバーはログが膨大なので、Sentry経由で問題のログに早期に気づくことができた方が運用的には良いです。

Flutter 用には sentry_flutter があるようですが、StailerのClientでは採用していません。

. dartis (⭐️⭐️)

pub.dev

DartisはRedisを扱うDartクライアントで、シンプルなデータキャッシュとして使用しています。

主にパフォーマンス改善で活用しており、売り場で表示されるカテゴリーデータなどは更新頻度が低いためキャッシュを効かせてレスポンス速度を向上させています。

深い使い方をしていないのと、メンテナンス性が高くなさそうなので推しポイントは低いです。

. uuid (⭐️⭐️⭐️)

pub.dev

採用してます。RFC準拠で何も文句がありません。

. html (⭐️⭐️⭐️)

pub.dev

HTMLを楽に扱う時にはhtmlが良いです。

Stailerではパートナーが運営するネットスーパーのサイトをクローリングして商品データを集めるケースがあり、その場合にhtmlは活躍します。

趣味のクローラーを作ってちょっとした情報収集〜といったユースケースにも使えそうです。

プライベートパッケージ

Stailerで使っている自前のパッケージです。

. Firestore

Stailerの永続データストアにはCloud Firestoreが採用されています。

FirestoreのパッケージはPub.devでもいくつか確認できますが、そのほとんどがFlutter SDKを前提に作られており、Pure Dartではないです。

サーバーでも使えるかもしれませんが、使う中で下手に気を使うよりも、自分たちの前提にあったものを使うほうが中長期的に良いという考えから、自前でパッケージが作られました。

f:id:yamarkz:20210927220629p:plain
CTOのishkawaさん謹製のPure Dartなパッケージ

機能は公式で提示されているものを凡そカバーしており、最近だとSelect field機能が試験開発されています。

また、通信で利用されているデータのシリアライズとデシリアライズのパッケージをmirrorからjson_serializableに書き換えなども行なっており、パフォーマンスが大きく改善されたりしました。

f:id:yamarkz:20210927225316p:plain
readのパフォーマンスが10x✨

. Firebase Auth

Firebase AuthもFirestoreの話と同じく、for Flutterなパッケージは存在しますが、サーバーで利用する(Pure Dart)ものは今のところありません。

サーバーを介して認証を行えるようにするために、Firebase Authのパッケージも自前で作られました。

プラットフォームとして扱える様にいくつかカスタマイズを加えていたりもします。

. BigQuery

BigQueryもDartのパッケージが存在しないため、自前で対応しています。 パッケージがないから採用を見送る... の意思決定はなかったです。(BigQuery最高!!)

StailerではBigQueryをフル活用して膨大な在庫データを扱っており、システム基盤としては欠かせない存在です。 (データの話は奥が深く、また別で取り上げられると思うのでお楽しみに!)

f:id:yamarkz:20210927221056p:plain
オーソドックスなクエリの実行

売り場に表示される商品データは、Raw Data → Storage → dbt → BigQuery → Firestoreという変遷を辿って実現しており、BigQueryのパッケージはこの中の BigQuery -> Firestoreのステップで主に使われています。

変わった使い方はしておらず、googleapisにあるBigQuery APIをラップして作られています。

. 決済処理系

Stailerは決済で外部ベンダーのAPIを利用しており、扱う処理はパッケージに切り出されています。

決済系は公式がライブラリ提供してくれているところもありそうですが、基本はWeb APIのみの提供になるので、それをDartの世界で扱いやすくするためにパッケージにしています。

. パートナー連携系

パートナー連携は連携ごとにAPI操作を行うパッケージを作っています。(決済処理系と同様)

機能をサーバーの各処理(API or Batch or Worker)で使い回すのと、"パートナー連携"という文脈で処理をまとめた方がわかりやすいです。

連携系のAPIはそれ自体はアトミックな操作にしておき、サービスクラスを挟んで各々の文脈で使いやすい形に変えたり、エラーハンドリングを加えたりしています。

言葉だけだと伝えづらいのですが、API Request → Service → Partner Client → Partner APIという流れの中でPartner APIを呼び出しやすくするためにClientをパッケージに切り出すということです。

まとめ

  • パブリックパッケージを程よく取り入れるが、基本は薄く使う。
  • プライベートパッケージは主にミドルウェア方面で自作している。
  • 必要であればコントリビュートやパッチを当てて使う。

最後に

Stailerのサーバー開発で採用されているパッケージを紹介してきました。 どんな雰囲気で開発されているのか、少しイメージが膨らんだのではないでしょうか?

端的に言えば、パブリックパッケージを薄く採用しながら、ミドルウェア周りのパッケージを自作し、必要であれば適宜パッチを加えるという感じです。

Dartはまだまだマイナーですが、言語機能自体は素朴で読みやすいのでおすすめです。Server Dartも可能性は0ではないので、ぜひトライしてみてください!🎯

宣伝

10Xではソフトウェアエンジニアを募集しています。本記事を読んで少しでも気になった方はぜひ声をかけてください。Dartを駆使して一緒に小売のデジタル化を進めましょう!🔥

定期的にオープンオフィスを開催しています。会社のことから仕事のこと、パートナーとの関わり方など、ざっくばらんにメンバーが話をしているのでぜひご参加ください。

docs.google.com

10Xのカルチャードリブン開発を支える選考プロセス『トライアル』の紹介

こんにちは。ソフトウェアエンジニアの村岡(@_tapih)です。

私が入社して約3ヶ月が経ちましたが、入社前後のギャップが一切なく、もう何年も働いているような不思議な感覚で日々働いています。 これは弊社が採用で行っているトライアルという仕組みがうまくワークしているからだと感じています。 この記事では弊社の選考プロセスで実施しているトライアルの概要と実際に私がトライアルで行ったことを紹介します。

なお、弊社はSWE/Product Manager/Designer/QA/SET/SREを絶賛募集中です(Dartを使ったことがなくてもOKです!)。この記事が弊社に興味がある方々の参考になれば幸いです。😄

※ 本記事で紹介するトライアルに関する内容は、取り組む課題に個人差があること、今後内容が大きく変わる可能性があることの2点にあらかじめご注意ください。

トライアルとは

トライアルとは、事前に「インパクトあるイシュー」を挙げてもらい、実際に働く機会を設けてそれに取り組んでもらうことで10X Valuesにフィットすることを相互確認する採用プロセスです。

候補者はNDAを結んだ上で弊社の社内情報に事前にアクセスし、あるテーマに対するイシューとそのイシューに対してどう取り組んでいくかを準備します。 その後、1日〜数日かけて事前に決めた課題に取り組み、最後は取り組んだ課題の成果を発表してもらいます。

候補者によってテーマに細かい違いはありますが、プロダクト開発に関わる職種で共通する点として「いかにStailerを10x成長させるか?」という視点を含んでいます。 イシューの選定の際には、短い時間でも「候補者の強みが最大限発揮できる」ようなものに取り組んでもらうことが重要で、決して「タスクの完了」を目的とはしないことで、 何かしらの10xから逆算した貢献ができるイメージを共有できることを目指します。

面接はどの会社も採用しているであろう選考プロセスの代表的な手段ですが、短時間の面接で自社のカルチャーへのフィットを見ることは非常に難しいのではないでしょうか。 一方で、「実際に働く」というプロセスはカルチャーフィットがリアルに感じられ、これを確認するための非常に明快な手段であると考えます。 また、候補者の側は、会社の内情を事前に実体験として知ることができるので、入社前後でのギャップを抑えることができます。 このように、選考を受ける側と提供する側の両者に対して、納得感のある結論を安定して出せることがトライアルのメリットです。

採用プロセスや評価グレードについてはCulture Deckに説明があるので、興味のある方はご一読ください。😄

speakerdeck.com

...といろいろ書きましたが、これだけではイメージが湧きづらいと思うので、後ほど具体例として私がトライアルで行ったことを紹介したいと思います。

トライアルがプロダクトに与える影響

10X Valuesに関しての個人的な解釈は以下の通りです。いずれも抽象的ではありますが、プロダクトを作り上げていく上で必要な要素が全てここに凝縮されていると考えています。

  • 10xから逆算する: プロダクトとの向き合い方
  • 自律する: 自分との向き合い方
  • 背中を合わせる: 他人との向き合い方

したがって、これが体現できること=10xするプロダクトを作ることに繋がり、採用の段階からこのカルチャーに対するフィットを入念に確認することがそのままダイレクトにプロダクトの質につながってくると考えています。

過去のトライアルで取り組まれた内容

弊社が開発するStailerはスーパーマーケット、ドラッグストアなどの小売チェーンがECを立ち上げるためのプラットフォームです。 このプロダクトに対し、過去には以下のような内容でトライアルが実施されました。人によって期間はまちまちですが、そこそこ大きめの粒度で設計から実装までを行っていることが伺えると思います。

  • (SWE) 商品タイトルに含まれる商品詳細の自動抽出とタイトルの再生成の実装(1週間のトライアル)
  • (SWE)「ついで買い」機能のUI及びAPIの設計・実装とリピート購入の傾向分析とロジック提案
  • (Designer) 注文〜受け取りまでの体験設計とUI作成、ユーザビリティテストの実施(約3週間の間、実際のPJで稼働)
  • (Product Manager) 商品検索改善のための全体設計の提案
  • (Growth) パートナーから受領した商品データをStailerに取り込むフローの汎用化方針の設計・実装

私がトライアルで取り組んだこと

さて、トライアルに関するイメージをより明確にするため、ここから私のトライアルについてご紹介したいと思います。

私は「とあるネットスーパーを10x成長させるには?」というテーマに対してネットスーパー利用客がほしいと思った商品にうまくアクセスできていないペインの解消というタイトルで商品検索改善に取り組みました。

1. 採用エントリーからトライアルまでのタイムライン

エントリーからトライアルまで約1ヶ月半程度の時間がありました。 事前に何をやるのかを社員との面談を経て決定した上で、トライアル当日に実際に出社して成果を発表しました。 1回目の面接の前と事前準備にそれぞれ半日程度まとまった時間を使って稼働して、あとは平日夜の時間をちょこちょこ使って準備を進めました。 子育てで時間が確保できるか心配なところがありましたが、比較的ゆったり目のスケジュールで調整し、無理なく進めることができました。

2/17 HPからエントリー
2/22 トライアルについての面談(1回目)
2/24 NDA締結
3/8  トライアルについての面談(2回目)
3/9~ 事前準備
3/31 1dayトライアル
2. 課題設定に至るまで

どのようなペインがあるのかを把握するため、まず始めに一ユーザ目線でStailerが提供するネットスーパーを利用してみました。 そこで、多種多様な品目を扱うネットスーパーにおいて検索機能が非常に重要な機能であるにも関わらず、検索結果が「しっくりこない」と感じることが多いことに気づきました。 続いて、この「しっくりこない」感覚を深堀りするために社内のドキュメントを読み、在庫の問題・検索の問題・商品の見せ方といった点にその原因があると整理しました。

ペインに対する施策の整理
(ペインに対する施策の整理)

現在の事業の状況を踏まえると、中でも商品検索の改善にフォーカスするのがベストと考え、続けて検索改善の全体像の検討に取り掛かりました。 ここで考慮が必要だった点としては、タイトル・説明文・カテゴリ名といった各商品のデータが十分に整備されていない、という問題がありました。 実際にどのような検索ができているか・できていないかを試しながら、限られたデータをいかに有効活用するか、検索クエリのサジェストを用意するなど検索体験の全体設計でカバーできないか、といった観点から検討を進めました。 私はトライアルまで検索改善の経験がなく、ましてやElasticsearchを利用したこともなかったため、このプロセスは非常に苦労しました。

各情報の使い方の整理改善案の全体像
(改善案の全体像)

3. トライアル当日

私が示した検索改善のゴールイメージと現状のElasticsearchの設定を踏まえ、改善の一手段としての「Ngramを利用した単語のアナライズ」と、 改善の計測のための「Ranking Evaluation APIのデモ」の2点にトライアル当日に取り組むことを決めました。 検索の改善は継続的な取り組みが必要な息の長いタスクだと思いますが、その一端をトライアルという短い時間で表現したいというのもこの決定の理由の一つでした。

この記事では具体的な方法論には触れませんが、以下のドキュメントを参考にしました。

www.elastic.co www.elastic.co

余談ですが、トライアル前日にElasticsearchのローカル開発環境を動かそうとしたところサクッと動かせないことに気づき、非常にドキドキして当日にトライアルに向かいました。 結局動いたのは当日の昼過ぎ(!)でしたが、実際にメンバと交流しながら作業をして、最後にデモをして無事終了となりました。

トライアルを通じて事業に対する理解が一気に深まったことを感じました。 また、Howに至るまでのプロセスを評価していただき、かつそういったフィードバックを直接いただいたことでカルチャーフィットを相互に確認できている実感がありました。 シンプルに「トライアルっていいな...」と思いながら帰路についたことをよく覚えています。

今後に向けて

ここまでトライアルの長所ばかりをご紹介しましたが、組織が拡大するにつれて以下のような問題が顕在化してきました。

  • トライアルを行うための弊社側の環境整備(権限等)のコスト増加
  • 社内資産の拡大による候補者側のキャッチアップコストの増加

しかし、社内的にはトライアルという採用プロセスを大事にしていきたいというコンセンサスがあり、今後もよりよいトライアルを行えるように仕組みを整備していきます。

さいごに

この記事では、弊社のプロダクトの質を下支えするトライアルという選考プロセスについて私の実例を踏まえてご紹介しました。

弊社の社員はよく「強そう」「怖そう」と言われている印象があります(笑)が、トライアルで見られるのは「強さ」というよりかはいかに真剣にプロダクトに向き合えるかという点に尽きると思います。 私自身も働きながら、一番大切なのは熱意だな、と日々痛感しています。また、課題はチャレンジングでしたが、フィードバックが柔らかい社員ばかりだと入社してからも再認識しました。

怖くない10X!ということで、本記事を読んでいただきさらに10Xの話を聞いてみたい!と思った方は、定期的に開催しているオープンオフィスへのご参加お待ちしてます!😄 また、カジュアルに10Xのプロダクト開発について聞いてみたい方は本記事を書いた 村岡(@_tapih)のTwitter DMでもご連絡をお待ちしてます!

docs.google.com

10Xのコードレビュー方針と導入までの流れ

はじめに

こんにちは! 10Xで始まったプロダクトブログで初めて筆を取りました、ソフトウェアエンジニアの 山口 (@yamarkz) です。

最寄りのスーパーはライフで、必ずはちみつヨーグルトを買ってます。(おいしいのでオススメ 😋)

自身の初回ということで何を書くか迷いましたが、もうすぐ10Xに加わって1年ということもあり、入社時に驚いたことの1つである 10Xのコードレビュー文化 について紹介しようと思います。

10Xのプロダクトチームがどんなスタイルで開発を進めているのか、その一端を知ってもらえたら嬉しいです。

1. もともとコードレビューする文化がなかった

いきなり否定から入ってしまうのですが、自分が入社した2020年9月の頃は、プロダクトチーム内でコードをレビューする文化がありませんでした。( !! )

正確には全くないというわけではなく、クリティカルな部分の実装や実装者がレビューを希望した場合にのみ実施されており、それ以外は行わず各々がPR (Pull Request) をマージし、リリースしていました。

f:id:yamarkz:20210824094545p:plain
(依頼した方が良さそうな時に、依頼する)

最初この状況を見た時は戸惑いがあり、「すごいな...」と声を漏らして驚いたことを覚えています。自分は10X以前ではコードレビューをゆるくも厳しくも必ず行う世界を見てきたので、初見のギャップが大きかったのかもしれません。

希望して実施されるレビューは大方針が間違っていないかや、クリティカルな箇所のロジックが仕様に沿っているかを確認する程度で、よくある細かな表現に対する指摘などはなく、実装は個々人に大きく委ねられていました。

それでも特段開発に支障が出ることもなく、ほど良い品質で素早く機能をリリースするサイクルが回っていたので、レビューの必要性自体あまり感じない状況だったなと、今振り返ると思います。

これには大前提として、当時からシニアなメンバーが揃っていたのとリリース初期で複雑性が低かったという背景もありました。

2. 1年半で4パートナーのリリース、高まる複雑性

f:id:yamarkz:20210824094618p:plain
(2021/08時点で導入されているパートナー)

Stailerがリリースされてからおおよそ1年半で4パートナーのプロダクトをリリースしてきました。 これが早いか遅いかは主観による所ですが、個人的には極めて早いスピードで進んできたと思っています。

このスピードを実現できたのは、開発言語をDartに統一するという技術戦略や、Stailerをプラットフォームとして事業展開する(≒ 抽象化でレバレッジをかける)といったプロダクト戦略によるところが大きいのはもちろん、先の文化も少なからず寄与しています。

コードレビューを強制しなくても良い感じに開発が進む文化は、自律した個々人の集合によって実現されていました。この文化は見方を変えれば、「開発におけるメンバー間の依存関係が疎である」とも言えます。

疎というのは、メンバー間での情報共有が少なくとも自律的に物事が進められる組織状態のことで。これは仮に10人のメンバーがいた場合、並列して10個の開発が進んだりします。各メンバーは常に業務時間の8割以上を開発に投下でき、非常に生産性の高い状態です。

開発スピードはチームとしての頑張りもありますが、それ以上に戦略と文化によってもたらされる部分が大きいのではないかと思っています。

これまで開発を順調に進めてきましたが、それでもやはり規模が大きくなるにつれてプロダクトの複雑性が高まることは避けられません。

複雑性に対処するために仕様の理解や調整に時間を要することも徐々に増えてきました。

Stailerはマルチテナントで運営されており、共通の実装で複数サービスの展開を行なっています。コードで見れば、6~7割程度は抽象実装でカバーできていますが、残りの3割近くは断片実装が必要になります。

この断片実装周りの仕様が分岐点になり、「Aパートナーには機能提供するが、Bパートナーにはしない」「Aパートナーでは制約付きで提供し、Bパートナーは制約がないが若干表現を変えて提供する」といった複雑な状況が生まれていました。

これらは後々統一した抽象実装に昇華させたりもしますが、直近の断片実装は避けられない状況で、ある程度の複雑性を許容して進めていかなければいけません。

そういった中で開発を進めていくと、仕様の考慮漏れであったり、変更による想定外の副作用などが生まれてしまい、実装者だけで実装の安全性や完全性をカバーすることの限界が見えてきました。

今後支障をきたし始めることがわかってきたタイミングで、コードレビュー必須化の話題が挙がり、導入の検討が始まります。

3. コードレビューの導入を始める

f:id:yamarkz:20210824104808p:plain
(コードレビューを入れるという話の発端)

前段の状況が生まれ始めたことをきっかけに、コードレビューの必須化検討が始まりました。

導入の段取りはCTOのishkawaさんがコードレビュー運用方針のタタキ台をつくって、そこにメンバーのフィードバックを当てて実運用に乗せていく流れです。

運用を始める背景、最低限守りたいライン、運用手順などがドキュメントに起こされました。

これは外に公開しても問題ないという確認を得られたので、10Xのコードレビュー運用ガイドの一部を紹介します。

f:id:yamarkz:20210824094926p:plain
(プロダクトチームのコードレビューガイド)

このコードレビューの方針に沿った形でPRを作った場合、実装方針とその表現の確認に重きが置かれます。具体例として、直近自分が作ったPRは以下の様な表現をしています。

f:id:yamarkz:20210824094945p:plain
(レビューガイドに沿ったPRの例)

課題を解決するHowの候補として取れる選択肢は何があるのか。その中で何を選択したのか。その結果、どういった表現になるのか。表現に対して考慮の不足や副作用の懸念がないか。という一連の方針、実装の大上段をレビューしてもらいます。

WhyやWhatはissueに記載してある場合や、口頭で合意を取っているケースがほとんどなので、PRにはHowのみを記載します。

[余談] これまで運用をしてきた中で「こりゃ便利だな〜」と感じている仕組みとして、Slackにレビュー依頼のメンションを飛ばす仕組みがあります。

f:id:yamarkz:20210824095007p:plain
(Slackに送られるレビュー依頼通知)

この仕組みがあると画像のようにSlackにメンションで通知が来るので、レビューを忘れることことがなくなり便利です。すぐに設定しましょう。

👉 公式ドキュメントに設定方法が紹介されています。

4. 導入後の変化

というわけで、10Xでもコードレビューが必須になりました。🚓 👮‍♀️ 🚨

ルールを変えるということは、結果として何かしらの変化が起きます。 起きた変化を得られたもの失ったもので整理すると次のようになりました。

<得られたもの>

  • 仕様の考慮漏れや変更による副作用でのバグが減った。
  • メンバー間で仕様の共有知を醸成できる様になった。
  • 仕様変更の認識と理解を得る機会になった。
  • 中期を意識したより良い実装表現を見つける機会になった。

<失ったもの>

  • リリースまでの短期的な速度が低下した。
  • レビューで個人の稼働時間を消費するようになった。
  • レビューによる認知負荷が個人にかかるようになった。

導入タイミングとしてはベストで、投資対効果が十分に見合う仕組みになったと感じています。

後から気づいたことで、レビューの機会が「仕様変更の認識と理解を得る機会になること」は新しい発見でした。

急速に複雑化していくStailerの場合、仕様変更に後追いで気づくよりも、レビューの機会を通じて変更が入ることを頭の片隅に入れておけるのはキャッチアップの機会にもなり、良い体験です。

5. 今後の展望

運用によって良い効果が得られている一方で、まだまだ改善の余地があります。 具体的には、レビューの基準をより精密にすることや、実装以前の段階での設計レビューを設けるなどです。より良い形を模索しながら、10Xらしい開発文化を作っていきたいです。

ちょうど先週開催されたProductチームが話すオープンオフィスでは今後のStailerの方針が社外向けにも話されました。

f:id:yamarkz:20210824101534p:plain
(オープンオフィスで紹介されたStailerの開発方針)

Stailerはこれからの1年~3年でプラットフォームとしての拡大基盤の整備、および信頼性と安全性の向上に力を注いでいきます。

コードレビューの導入は、これから達成していくことの最初の一歩目とも言える出来事だったと思いました。

さいごに

10Xのコードレビュー文化について、これまでの過去を振り返りながら、現在の状況、そして今後やりたいことまでを紹介してきました。

コードレビューを強制しない状況から、徐々に実施する流れに進んできていますが、そこには明確な背景や合理的な理由があってやり方を変えてきたというのが、今回の記事で紹介したかったポイントです。弊社の例がコードレビューの導入や改善を検討している方の参考になれたら嬉しいです。

自身の1本目だったので下手なことは書けないなと思い、気合を入れて書いてしまいましたw 今後はゆるい記事も交えながら、10Xのナレッジを公開していけたらと思っています。😄

おしらせ

10XはFlutter/Server Dartという邪道のような技術を選択しながら、店舗のデジタル化という小売の王道になるであろう事業の立ち上げにトライしています。🔥

難しい問題がたくさんありますが、自律した仲間と背中を合わせて10xな価値をつくるのはとても楽しいですよ!

定期的に開催しているオープンオフィスでは、普段の開発の裏話なども聞けるので、興味あればぜひご参加ください。

docs.google.com