Posts

はじめに こんにちは。10X在籍2年目のソフトウェアエンジニアのJOJO(@joj0hq)です。現在はお客様が買い物をする際に利用するネットスーパーアプリの開発を主に担う売場チームで開発をしています。 この記事は10Xアドベントカレンダー2024の17日目の記事です。昨日はひさいちさん(@hisaichi5518)が「custom_lintでアーキテクチャのルールを作る」という記事を公開しているので、そちらもぜひご覧ください。 個人的10Xの推しポイント 運用をできるだけ仕組みに落とし込んで解決するところ。例えば、Google Meetでの会話内容を記録する仕組みとして、@google_meetをメンションすると自動的にGoogle MeetのURLが発行され、会話の記録を促す通知が送られる仕組みがあります。これにより、話し合いの内容が揮発せず、共有される環境が整っています。こんな仕組みが10Xには色々あります。 入社時の期待 このブログも前回の入社エントリ以来のめちゃくちゃ久しぶりの更新になってしまいましたが、日々、楽しく生きてます。前回の入社エントリから1年ちょっとが経とうとしてるので今の現在地点を入社当初の考えと比べて振り返ってみようと思います。 転職時の決め手は以下の3点でした。 事業：社会のインフラになると確信したネットスーパー領域のポテンシャルに対する期待 組織：長期的な視点で目の前の課題解決に向き合う組織 人：”WHY”にこだわる顧客志向を持ったプロフェッショナル集団 ざっくりまとめると、世の中に大きなインパクトを起こすと強く信じられる事業でお互いに刺激を与えられるメンバーとプロダクトの価値を高めることにフォーカスして目先の課題ではなく長期的なイシュー度の高い課題を解くために熱を注ぐことができることを期待していました。 やったことと考えていたこと それでは、実際にどんなことをやってきたのかをチームの変遷とともに話していきます。 お買い物チーム時代（2023/2~）：チーム組成とEpicの波 入社時、私は「お買い物チーム」に配属されました。当時の10Xでは、ドメインチーム体制の導入が進んでおり、チームがそれぞれ特定のドメインを担当する形に再編されつつありました。その中で「お買い物チーム」は、お買い物に関連するドメイン全般を担当するチームとして位置づけられ、ドメインチームの中でも非常に幅広い範囲をカバーする役割を担っていました。 このチームで私が取り組んだ内容を、ざっくりと以下に箇条書きでまとめてみます。 - WebアプリーケーションでのBOPIS（店舗受取販売）対応 - OTC医薬品販売の標準化対応 - モバイルアプリケーションのログ整備 - 商品ランキング新機能開発 - 売場タブのリファクタリング - 商品受取方法のリファクタリング - Brazeの導入 - Flutter メジャーバージョンアップデート etc.. 「お買い物チーム」は、ネットスーパーアプリのお買い物機能全般を担当しており、非常に多岐にわたる業務を抱えているチームです。一方で、新しく組成されたチームだったため、チームの基盤作りも同時進行で進めていきました。例えば、チーム内でのワーキングアグリーメントの導入や、スクラムセレモニーの改善に取り組み、チームとしての形を徐々に固めていきました。 また、現場の理解を深めるため、入社時には実際に店舗でスタッフの方々が行っているピックパック業務を体験しました。この経験を通じて業務フローの解像度を高め、ユーザー視点を積極的に取り入れる姿勢を意識していました。入社後はネットスーパーを週に1〜2回利用する“ヘビーユーザー”になったのも、自分がユーザー目線に立ってみることを大切にしたいという思いからです。 お買い物チームでは、サーバーサイドとクライアントサイドの開発をシームレスに行き来しており、私自身もクライアントサイドの開発に多く関わりました。特に、Flutterを使ったモバイルアプリの開発は初めての経験でしたが、チームメンバーと頻繁にペアプログラミングを行ったことで、スムーズに開発へ参加できました。この点は今でもチームメンバーに感謝しています。 特に印象に残っている施策は、商品ランキング機能の開発です。この機能を実現するためには、モバイルアプリ側の基盤となるコードのリファクタリングが必要でした。そのため、まずDesign Docを作成し、売場のカテゴリを切り替えるタブ構造のリファクタを実施。その後、他チームと連携しながら機能を実現しました。この施策は、アプリのUXや事業へのインパクトが大きく、私自身にとっても非常に学びの多い経験となりました。（特定のパートナーでは、アプリ起動後に初めて表示される売場がランキングになるなど、大きな変更も伴いました。） 当時の話は【エンジニアの部屋第3回】お買い物チーム（toC向けプロダクト開発メイン）の話を聞いてみた with @jojoでもしているので興味あればお聞きください！ 日々の開発で意識していたのは、「部分最適」ではなく「プロダクト全体の最適化」を目指すことです。当時、パートナーごとの個別機能が技術的負債となるケースが見られました。そのため、自分が取り組む内容がプロダクト全体にとって最適な選択であるかを常に考えながら開発にあたっていました。 売場チーム時代（2024/4~）：ボトムアップ施策と基盤固め お買い物チームから、新しく組成された「売場チーム」にアサインされました。この売場チームは、店舗運営に関わるドメインと、アプリ上の売場に関わるドメインを分割した結果、生まれたチームです。 このチームでの主な取り組みを、ざっくりと以下にまとめます。 - 視覚障害者の方のためのアクセサビリティ対応 - 店舗グループの全パートナー展開 - 商品一括非掲載機能開発 - デフォルト店舗の撲滅（リファクタリング） - モバイルアプリのリアーキテクチャ etc.. 視覚障害者の方のためのアクセサビリティの施策は売場チームが1つの施策にフォーカスして実施した施策で、アクセサビリティの対応後に、実際に視覚障害者の方からのユーザーヒアリングを実施した際に生の声で「こんなにアプリで読み上げるのはなかなかない！」というお言葉をもらえたときはエンジニア冥利に尽きるなと実感しました。 詳細はfutaboooさんがFlutterKaigiでも発表しているので興味がある方はぜひネットスーパーがスクリーンリーダーに対応した話 あるいはアクセシビリティ向上によるユーザー獲得も読んでみてください。 お買い物チーム時代から少しずつ浮き彫りになってきたモバイルアプリのアーキテクチャの課題を売場チームでも引き継ぎ、モバイルアプリのリアーキテクチャのためのADRの作って方針を言語化して固めたりもしていました。 ...

この記事は10X 創業 6 周年アドベントカレンダーの 14 日目の記事になります。 昨日は BizDev の寺崎さんが、「100 社以上の小売企業と面談して知った 5 つの発見」という記事を公開していますのでぜひ読んでみてくださいね。 はじめに 2023 年 2 月に 10X に入社した jojo です。 入社してエントリ書くぞと思っていたのですが時が経つのは早く、気づけば早 4 ヶ月が経ってしまいました（この企画がなければ、なかなか筆を取ることができなかったかもしれません笑）。 この記事は、かなり個人的な備忘録ですが興味を持ってくれた人に少しでもためになれば嬉しいです。今回は、私が 10X へ転職を決意した経緯と、この 4 ヶ月間で感じたことについて話していきます。 前職でやっていたことは？ 新卒で入社した前職では、メガベンチャーで BtoB マーケティング領域の新規事業部のエンジニアをしていました。 チームが小さく、一人ひとりが多くの役割を担う環境だったため、落ちているボールは全て拾うぞーという勢いで私は 4 年間でサーバーサイド（Golang）の開発に関わりつつ、フロントエンド（React・TypeScript）も触りながら iOS アプリのリニューアルなどを行ったり広くプロダクト開発に携わる機会がありました。（新卒 1 年目のぺーぺーにも機会を惜しみなくくれた環境に本当に感謝です。） また、PdM（プロダクトマネージャー）としての役割も任され、複数のステークホルダーと連携しながらプロダクトの仮説検証や施策推進を行いました。私が加入した当初は十数人規模だった事業部も、私が在籍している間に 50 人近くの組織に拡大して、事業は独立し、最終的には分社化するまで見届けました。 なぜ転職を？ 心理的安全が高く裁量もやりがいもある環境から移ることを考えたのは、結婚等を通して自分の人生を見つめ直して二十代最後の時間をどう使うかと考えたときにもう一段階ギアを上げることが求められるよりチャレンジングな環境に身を置くことが今の自分にとっては必要なんじゃないかと感じるようになっていったためです。 転職活動は初めてだったのでせっかくなら色んな人・業界の話を聞いてみたいと思い 30 社以上とカジュアル面談実施して広く話を聞きに行ってました。 各企業と話していて言語化された自分の価値観を Notion にまとめていきました。（一部抜粋） そんな中で固まった転職軸は以下の 3 つです。 世の中のシリアスでインパクトの大きな課題解決に取り組んでいること エンジニアが事業づくりにおける越境をすることが肯定される組織であること ユーザー志向で素早く開発プロセス・プロダクト改善のサイクルを回していること 新卒で勤めていた会社を選んだ最大の理由も、「テクノロジーで世の中のシリアスで大きな課題の解決に取り組んでいる」という観点でした。私はエンジニアとして技術そのものがもちろん好きですが、それ以上にその技術をどのように活用して課題解決に取り組むのか、どのような仮説を立てるのかに強い関心を持っています。 その上で、自分が作ったプロダクトがユーザーにとって真に価値あるものであると自信を持てるよう、絶えず改善を重ねられる組織に所属したいという思いが、多くの人々との対話を通じて明確になりました。（当時まとめていた Notion ページ抜粋） なぜ 10X に？ 10X への道のりは、たまたま遠方のサウナ（みんな大好き The Sauna）に行く道中で前職の先輩と「エンジニアもビズも関係なくイシューにこだわってプロダクト作ってる会社ありますかねー？」という何気ない会話をしたことがきっかけでした。 ...

はじめに zenn の記事の転載です。 これはGo Advent Calendar 2021の 6 日目の記事です。 DDD についてはエリック・エヴァンス先生や先人の鬼ほどわかりやすい書籍があるので、 こちらを読むことをおすすめします。（笑） ドメイン駆動設計 モデリング/実装ガイド ドメイン駆動設計 サンプルコード&FAQ ドメイン駆動設計入門 ボトムアップでわかる！ドメイン駆動設計の基本 なのでここでは、DDD を詳しく解説などはせずに、 Golang を使ってモデルでドメイン知識をどのようにソフトウェアに落とし込むのか、 簡単な具体例をあげて説明していきます。 ドメイン駆動設計(DDD)とは？ とはいっても、ドメイン駆動設計とはなんぞやをカンタンに説明しておきますね。 DDD Referenceでの定義を以下に記します。 Domain-Driven Design is an approach to the development of complex software in which we: Focus on the core domain. Explore models in a creative collaboration of domain practitioners and software practitioners. Speak a ubiquitous language within an explicitly bounded context. This three-point summary of DDD depends on the definition of the terms, which are defined in this booklet. 出典 URL：https://www.domainlanguage.com/ddd/reference/ ...

まず結論から zenn の記事の転載です。 Redux を理解する上では、この図解(引用元：Redux Application Data Flow)を理解できれば 90%は OK。 ユーザーの入力から、(ActionCreator が)Action(アクション)を作成する Store(状態を管理するところ)へ Action を Dispatch（送信）する Dispatch された Action を Reducer（状態を変更するところ）へ渡す Reducer が作成した新しい State を Store が保存する Store からデータを参照して View（画面）に描画する 「ここが間違ってる！」や「もっとこんな仕組みが使われてるよ！」等のツッコミがあれば、どしどし貰えると助かります！(そのために書いてるみたいなところも多いので！) Redux とは Reduxは、React が扱う UI の state(状態)を管理をするためのフレームワークです。 React では state の管理するデータフローにFluxを提案していますが、Redux は Flux の概念を拡張してより扱いやすく設計されています。 React 以外にも AngularJS や jQuery などと併用して使用することもできますが、React と使用するのがベターです。 Redux - GitHub Redux の 3 原則（Three Principles） Redux の基本設計は以下の 3 つの原則に基づいて設計されています。 順を追って見ていきましょう。 Single source of truth(ソースは１つだけ) この原則は以下のような要約できます。 ...

現状と課題 ビカクシダがおうちに 6 つほどいるのですが、 彼らは比較的育てやすい子たちなんですが、 本来は冬の無いような暖かい場所に生息しているので、 できれば 15-20 度くらいをなんとかキープしたい。 最近は、比較的暖かくなってきたが、私は郊外に住んでいるので下手すると 10 度切るくらいに寒いときもぼちぼちあるので、 なんとか彼らが住みやすいような環境を作りたい。 作ったもの とりあえず、部屋の温度をスマートハブで監視して、 15 度を切ったら自動的に暖房が ON になるようにして、22 度以上で暖房を OFF になるようにした。 （ぶっちゃけこれ、既存アプリのシーン設定だけでできんじゃね？） データを残すこと大事なんで！とりあえず可視化したかったので、やってみた。 ざっくり、ビカクシダが育ちやすそうな温度になっていることがわかる。 よかった。よかった。