jojo

はじめに こんにちは。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）に行く道中で前職の先輩と「エンジニアもビズも関係なくイシューにこだわってプロダクト作ってる会社ありますかねー？」という何気ない会話をしたことがきっかけでした。 ...

今回つくるもの 今回作るのは静的な Web サイトです。 まさにこのサイトのようなブログのような複数のユーザーから動的な更新を想定しないサイトの場合は、静的なページで実装することで高速に読み込むことができるサイトを開発することができます。 ここでは、Firebase と Hugo をつかってさくっと実装していきます。 Hugo とは？ HUGO とは、一体何でしょうか。 HUGO の公式によると、 Hugo is one of the most popular open-source static site generators. With its amazing speed and flexibility, Hugo makes building websites fun again. つまり、HUGO とは静的な html を生成する事ができる静的サイトを生成するフレームワークです。 HUGO のメリット 静的なページなので高速 セキュリティ面でのリスクを減らすことができる Markdown 形式で記事を書くことができる 既存のテーマを使えばサイトの実装がかんたん 静的なページにすることでサイトの表示速度は高速になり、サーバサイドの処理が無い分セキュリティ的にもリスクを減らすことができます。 なんといってもこのフレームワークの魅力は Markdown 形式で書いた記事がそのまま公開できるという点です。 これは全エンジニアにとってはとてもありがたい利点ではないでしょうか！？ 逆に Markdown 記法になれていない方にとっては WordPress のような GUI 的にマークダウンできるフレームワークのほうが便利かもしれませんね。 HUGO のデメリット 記述が独特で学習コストがかかるところがある 既存のテーマを使用するとカスタマイズが面倒 動的に title タグや description を組み立てるのが面倒 基本的には、標準機能が充実しているのでプラグインを追加してなにかするといったことはほとんどありません。 ...

URL 埋め込みのセッション ID 概要 セッションが URI に埋め込まれることがある。 PHP,Java,ASP.NET などはサポートしている。 http://example.jp/mail/123?SESSIONID=XXXXXXX 課題点： Referer ヘッダを経由して、セッション ID が外部に漏洩する（Referer ヘッダとは） Referer ヘッダーにより、サーバーは人々がどこから訪問しに来たかを識別し、分析、ログ、キャッシュの最適化などに利用することができます。 対策： URL 埋め込みセッションそのものを禁止する 攻撃手法と影響 攻撃の流れ： スタートページ（別ページに遷移） 外部リンクが貼られたページ（パラメータに SESSIONID が付与されている） 外部のページ（referer ヘッダから SESSIONID を取得） 1.URL 埋め込みセッションを使えるするように設定ファイルを変更 2.外部サイトへのリンクがある or リンクを攻撃者が作成できる（メール、掲示板、ブログ、SNS でやられる） 影響： セッションハイジャックを同じ 脆弱性が生まれる原因 2000 年前後の「クッキー有害論」が生じたため -> アクセス履歴を追跡できるのってプライバシーの観点からどうよ？って問題に ドコモのガラケーのブラウザは過去にクッキー対応していなくその影響 —>今はクッキーに保存するほうが安全とされている？ 対策 セッション ID をクッキーにのみ保存してねとすれば OK セッション ID の固定化 概要 セッションハイジャックを起こす攻撃の中に、セッション ID を外部から強制するセッション ID の**固定化攻撃（Session Fixiation Attack）**がある。 攻撃の流れ： セッション ID を入手 ターゲットに奪ったセッション ID でのアクセスを強制 ターゲットが標的のアプリにログイン 攻撃者は強制したセッション ID を使ってターゲットのアプリにログイン ...

今回作るシンプルなインフラ設計 AWS でインフラ構築をする時は、毎回ブラウザからコンソールをぽちぽちするとセキュリティーグループやルートテーブルの設定に抜け漏れができてしまったりということが多く困っていました。 そのため、今回はコードを書いて実行するだけでインフラ環境を構築してくれるツール「Terraform」を使って構築の自動化をしていきます。 まず、完成図から見ていきましょう。 このように VPC に EC2 が乗っているだけのもっともシンプルな設計で作っていきます。 Terraform とは そもそも「Terraform」とは何かについて簡単に説明します。 Vagrant を開発しているHashiCorp 社が開発しているツールで公式 HP によると、 HashiCorp Terraform enables you to safely and predictably create, change, and improve infrastructure. It is an open source tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned. https://www.terraform.io/ つまり、Terraform とは安全かつ予測可能にインフラ設計を作成／変更／改善がコードとして扱うことができるオープンソースツールです。 これを使うことでコードからインフラ環境を構築でき、削除をコマンドひとつで簡単にできます。 ブラウザ構築を行う際にはコンソールからぽちぽち設定を行わなければいけないとの、立ち上げた環境を潰したい時もいちいちひとつずつ削除しなければいけないというデメリットがありますが Terraform を使うことでこれらの課題を解決してくれます。 一度設計したインフラ構造を使いまわすこともできるので、使いこなすことができるととても便利なツールです。 インフラ構築の手順 それでは、順を追って Terraform によるインフラ構築を行なっていきましょう。 ...