Google Cloud IAM一時付与システムを「作らなかった」話

SRE

この記事は10Xアドベントカレンダー2024の21日目の記事になります。 昨日はBizdevの勝谷さんが「 全国のスーパーマーケットを回る10XのBizdevが出張で出会った美味しかったもの3選 | Notion 」の記事を公開しています。

はじめに

こんにちは、10X在籍3年目のSREの栗原です。 今回は、以前に検討していたGoogle Cloud IAMの一時付与システムについて、その設計思想と最終的に「作らなかった」理由についてお話ししたいと思います。

作ろうとした理由と、作らなかった理由

弊社では、Google CloudのIAM管理をTerraformで一元管理しています。TerraformはIaCとして優秀なツールですが、開発者が一時的に権限を必要とする場合、TerraformのPR作成、レビュー、マージというプロセスを経る必要があり、その体験は必ずしも良いとは言えませんでした。また、作業後に権限を削除をしなければ、そのまま権限が残り続けてしまうというセキュリティリスクも孕んでいます。

これらの課題を解決するため、一時的なIAM付与を自動化するシステムを検討していました。しかし、Google Cloud PAM（Privileged Access Management）の登場により、これらの課題は全て解決できると判断し、自作のシステム開発は見送ることとなりました。今回は、その供養として検討していたシステムの設計思想について共有させてください。

システム構成

今回検討していたシステムは、以下の図のような構成を想定していました。

API Server

API Serverは、クライアント（Slack botなど）からのリクエストを受け付け、IAMの一時付与を処理する中心となるコンポーネントです。APIリクエストには、以下のパラメータが含まれます。

  • 依頼者のメールアドレス
  • 付与したいIAMロール
  • 付与期間

API Serverでは、以下の処理を行います。

  1. メールアドレスのドメイン確認: リクエストの送信元が、許可されたドメインからのものであるかを確認します。
  2. JWT (JSON Web Token) の生成: ペイロードに、メールアドレス、付与するロール、付与期間を含むJWTを生成します。
  3. JWS (JSON Web Signature) の生成: Cloud KMSでJWTに署名を行い、JWSを生成します。
  4. 承認用URLの生成: JWSを含む承認用URLをクライアントに返します。

承認フロー

  1. クライアントは、API Serverから受け取った承認用URLを承認者に伝えます。
  2. 承認者は、承認用URLにブラウザでアクセスします。
  3. Cloud IAPによって、承認者のGoogleアカウントでのログインが必須となります。
  4. API Serverは、JWSの署名検証を行い、 その後JWSの有効期限を確認します。Cloud IAPから提供されるリクエストヘッダーに含まれるメールアドレスが、承認者リストに含まれているかを確認します。
  5. 検証が成功した場合、IAMを一時的に付与します。

IAMの付与には、IAM conditionを用います。これにより、指定された期間のみ有効なIAMを付与することが可能になります。

こだわりポイント

このシステムを設計する上で、特に重視したこだわりポイントは以下の3点です。

データベースレス

このシステムには、データベースが存在しません。データベースのメンテナンスやアップデートによる苦労を避けたかったこと、システムをシンプルに保ちたかったことが理由です。データベースレスでも、JWSを活用することで、システムとして破綻することなく、要件を満たしています。

JWSの利用

このようなIAM一時付与システムは、攻撃者にとって格好の標的となりえます。そのため、セキュリティを確保することは非常に重要です。このシステムでは、改ざん検知のためにJWS (JSON Web Signature) を採用しました。JWSによる署名検証を行うことで、リクエストの改ざんを検知し、不正な権限付与を防ぐことが可能です。これにより、外部からの攻撃に対する堅牢性を高め、システム全体の安全性を担保します。

承認フローの導入

IAMの一時付与には、承認フローが不可欠です。このシステムでは、承認フローを実装するために、Cloud IAP (Identity-Aware Proxy) を活用しました。これにより、承認者は自身のGoogleアカウントで認証を行うことができ、API Server側で複雑な承認ロジックを実装する必要がなくなります。さらに、発行される承認用URLには、有効期限（exp claim）を5分に設定しています。そのため、承認者が意図的に承認を行わない場合は、5分経過するとURLが無効となり、IAM付与が行われない仕組みとなっています。これにより、承認フローをシンプルかつ安全に実現しています。

Google PAMの導入と現状

今回、IAM一時付与システムを自作する代わりにGoogle Cloud PAMを導入し、最近その利用を開始しました。Terraformで google_privileged_access_manager_entitlement を定義し、利用者は必要なEntitlementsを選択して申請する仕組みを構築しています。まだ使い始めたばかりで、Entitlementsの種類は少ないですが、利用者のニーズに合わせて順次拡充していく予定です。

まとめ

今回は、Google Cloud IAMの一時付与システムを開発しようとして、最終的に開発を見送った経緯についてお話ししました。Google Cloud PAMの登場は非常に大きかったですが、その過程で考えたシステムの設計思想は、今後のシステム開発にも活かしていけると考えています。

検索エンジニアとして入社して1年でやったこと

検索 推薦

この記事は10Xアドベントカレンダー2024の18日目の記事になります。 昨日はJOJOさん(@joj0hq)が「10Xのエンジニアとして入社から2年目を振り返る」という記事を公開しているので、そちらもぜひご覧ください。

はじめに

こんにちは、10Xで検索推薦の機能・基盤の開発運用を担当している安達(id:kotaroooo0)です。 2024年1月に入社し、もうすぐ1年が経ちます。 今回はこの1年間を振り返り、印象的だったプロジェクトをいくつか紹介します。

取り組んだプロジェクト

自分がリードしたプロジェクトをいくつか紹介します。 今回紹介する以外にもElasticCloudのオートスケーラー開発について以前書いたので参照しておきます。

product.10x.co.jp

類似商品検索の実装

商品詳細ページで、関連商品として類似商品を表示するようにしました。

商品詳細画面

Elasticsearchのmore like thisクエリで実装しました。

他の選択肢としては、ベクトル検索もありましたが工数、Elasticsearchへの負荷、技術的不確実性が高く、まずはmore like thisクエリで実装することにしました。

ただし、セマンティックな検索ができないという課題もあるため、今後改善していきたいです。

新しい検索精度モニタリングの導入

nDCGを活用してランキング精度をモニタリングできるようにしました。 これにより、既存のモニタリング項目（ゼロマッチ率、検索ごとのカート追加率、ヒット件数）に加えて、ランキングの精度も可視化できるようになりました。

これまで、検索改善は主にRecall（検索結果の網羅性）を向上させるフェーズでしたが、今後はPrecision（検索結果の精度）向上に注力していく必要があります。 これに伴い、ルールベースのリランキングやLearning to Rankを導入するためにランキング精度がモニタリングできる必要がありました。

BigQueryでキーワードごとのカート追加率を集計し関連スコアとし、nDCGを計算しました。 Looker Studioでダッシュボードとして利用し、可視化しました。

トップ画面での推薦枠A/Bテスト

推薦にも新しくチャレンジしてみました。

アプリのトップ画面に推薦枠A/Bテストを実施しました。 レジ前推薦でパーソナライズを導入し大きな効果がでたため、サービスの入り口であるトップ画面で推薦を提供することで平均注文額や平均カゴ点数の増加を期待しました。

トップ画面

アルゴリズム

ユーザーベース協調フィルタリングを採用しました。 ユーザーの購入履歴を元にユーザー間の類似度を計算しました。 ネットスーパーでは、繰り返し何度も同じ野菜、卵、牛乳等を買い続けるケースが多く、かつ注文点数が多いです。 そのため、単純に協調フィルタリングすると、どのユーザーにも人気商品を提案することになる問題がありました。

そこで、人気商品はそのユーザーの特徴量として扱わないようにしてユーザー間類似度を計算しました。 どれだけの人気商品を除外するかは、推薦結果が人気順に近づくのとユーザー間類似度の精度が落ちることのトレードオフです。 ここのパラメータはデモを実施することにより定性的な評価で決定しました。

アーキテクチャ

要件として、推論頻度を日次にしました。 ユーザーの購入履歴を元に推論結果が変化するアルゴリズムであり、ユーザーの購入は1日1回以内であることがほとんどのためです。

そのため、stailer-ml-pipelinesというVertex AI Pipelinesベースのパイプラインで日次でユーザーベース協調フィルタリングの推論をして、Firestoreに保存しておきます。 それをstailer-recommenderという推薦APIでServingします。

アーキテクチャ図

A/Bテストの結果は、ネットスーパーさんごとに異なり、他の商品枠との兼ね合いで推薦枠が効果を発揮する場合もあれば、そうでない場合もありました。 そのため、現在はプラットフォーム全体で推薦枠の表示を一律停止しています。 しかし、なぜ結果が異なるのかについて仮説を立てたり、トップ画面で特に効果的な枠について知見を得たりする良い機会となりました。

検索系RPCのレイテンシ改善

検索系RPCのレイテンシ(90パーセンタイル)をモニタリングしていましたが、基準を満たさず、アラートが頻発している状態でした。 このRPCはFirestoreとElasticsearchに複数回リクエストを送る構造になっており、どこがボトルネックなのかがすぐには特定できませんでした。

分散トレーシングを活用し、レスポンスタイムが遅いリクエストを数十件調査した結果、以下の2つが主な原因であることが分かりました。

ボトルネック

1. Firestoreへforループでのアクセス

Firestoreへのアクセスが原因で遅くなっている箇所を発見しました。 調査したところ、他チームが既に修正済みのコードが存在していたため、それを取り込むことで解決しました。 Firestoreのデータ構造を変更し、以前は複数回のクエリが必要だったものを、1クエリで取得可能な形に改善していました。

2. Elasticsearchのprefixクエリ

Elasticsearchへのクエリで、次のような空文字を指定したprefixクエリが発行されている箇所を発見しました。

{
    "prefix": {
        "hoge": ""
    }
}

この問題は、実際に生成されたクエリをKibanaのSearch Profilerでプロファイリングすることで特定しました。 期待外のクエリが発行されており、それがボトルネックになっていました。

対応策として、空文字の場合はprefixクエリを除外するように修正しました。

効果

対応の結果、対象の3つのRPCすべてでレスポンスタイムが改善し、アラートが発生しなくなりました。 それぞれの対応策リリース時にレスポンスタイムが期待以上に縮まってくれました。

レイテンシ(90パーセンタイル)

対応自体は比較的シンプルなものでしたが、、多角的な原因分析と対応策を列挙して比較したりとリアルISUCONできる貴重な機会でした。

Elasticsearchのバージョンアップ

Elasticsearch 7系から8系にメジャーバージョンアップしました。

課題

  • 7系ではElasticsearch単体ではベクトル検索できない
    • Vertex AI Matching Engineと組み合わせれば実現可能だが構成が複雑になる
      • Elasticsearchでフィルタ → Vertex AI Matching Engineでベクトル検索というフローはメンテナンス性が低い
      • Elasticsearchのみでベクトル検索ができれば、Elasticsearchのみで検索が完結し嬉しい
  • いずれ9系がリリースされるとEOLになる

互換性の調査

以下の項目について互換性を確認しました。

  • プラグイン: 形態素解析辞書や類義語辞書、ICUなど使用中のプラグインが新バージョンで動作するか確認。
  • Elasticsearchクライアント: アプリケーションが利用するクライアントライブラリの互換性をチェック。
  • 設定ファイル: mapping.json や settings.json の互換性を確認。
  • 利用機能: 非推奨(deprecated)となる機能や仕様変更をリリースノートで確認。KibanaのUpgrade Assistant機能を使ってダブルチェック。

リリース手順

Blue-Greenデプロイを採用して、本番環境でのリリースを進めました。

1. 新クラスタの作成

Elasticsearch 8系を使用した新クラスタをElasticCloudで構築。

2. 新クラスタへデータ更新導線連携

新旧クラスタに対してデータ更新をダブルライトで行い、データの一貫性を確保。 データ更新リクエストはPub/Subにキューイングされる仕組みです。 キューを処理するWorkerはKubernetes上で動いており、新クラスタ用にWorkerを新しいDeploymentとして起動し、旧クラスタ用Workerと並行して動作させれば簡単にダブルライトできるアーキテクチャになっています。

3. 検索導線の向き先切り替え

検索リクエストの向き先を旧クラスタから新クラスタに変更。 旧クラスタは障害時の切り戻しに備えて1週間程度保持。 障害が発生する可能性が高いのはここであり、切り戻し手順をリハしておきました。

4. 旧クラスタの除却

新クラスタの安定稼働を確認後、旧クラスタとそれに伴うダブルライトを除却。

バージョンアップによるパフォーマンス改善

機能面を目的にバージョンアップしましたが、非機能面でもパフォーマンスが大きく改善されました。

  • CPU利用率: バージョンアップにより半分程度に(StailerのElasticsearchはCPU bound)
  • 検索rpcのレイテンシ: 90パーセンタイルが半分程度に

これからの取り組み

LLMの活用

現在、検索機能へのLLMの活用を検討しています。 まずは、商品への自動タグ付けができないか検証しています。

例えば、「ヤッホーブルーイング よなよなエール 350ml」という商品があった時に、「クラフトビール」と検索してヒットさせたいです。 現状では、タグ付けは手動で行うか、同義語（シノニム）を登録することで対応しています。 これでは、気づかないとタグ付けやシノニム登録でできないし、追加する工数もかかります。

そこで、LLMを活用した自動タグ付けで、これらの課題を解決できないか検証しています。 GeminiやOpenAIのAPIの精度が向上しコストが低下してきているため、大量の商品でも効率的にタグ付けできる可能性が高まっています。

リランキング

これまでの Stailer の検索改善では、主に Recall を向上することに取り組んできました。 その結果、「検索結果の並び順は最適ではないかもしれないし、関係性の低い商品も含まれているが、欲しい商品は見つかる」という状態に近づけました。 次は、「関係性の低い商品は下位に、欲しい商品は上位に表示される」という状態を目指していきます。

将来的にはLearning to Rankに取り組みたいですが、まずはルールベースによる簡易的なリランキングに取り組んでいます。 これは、少ない工数でできるだけでなく、ルールベースによるリランキングをするためのプロセスがLearning to Rankにも生き、ステップを踏むことが無駄になるわけではないからです。

例えば、特徴量の分析や継続的な分析のためのオフライン/オンライン評価(デモ環境や精度モニタリング、インターリービングテスト)の仕組みなどはそのまま活用できます。

おわりに

この記事では、2024年の1年間を振り返り、自分が取り組んだ印象に残っているプロジェクトの概要を紹介しました。 これまでよくやっていた検索基盤の仕事だけでなく、推薦にも挑戦でき充実した1年でした。

明日は橋原さんの記事です！お楽しみに！

「スピード」と「こだわり」を両立したい！shadcn/uiとTailwind CSSを活用したゼロからのコンポーネントライブラリ構築

こんにちは、10X プロダクトデザイナーの日比谷（@suuminbot）です。

現在10Xでは新規プロダクトを複数開発している真っ只中ですが、私もその一環でshadcn/uiとTailwind CSSを活用しつつ、SaaSのサービス画面（管理画面）用のコンポーネントライブラリをゼロから構築していました。

少し前に一通り最低限必要なコンポーネントをFigma・実装ともに作りきり、現在は実際にそのコンポーネントライブラリを使って自分自身が複数のプロダクトのUIを作ったり、開発が進んでいる様子を見ているところです。

このブログでは、今回取り組んだことや学びをご紹介していこうと思います。

新規構築の経緯

10Xの主力事業であるStailerのサービス画面（小売企業の方々が利用する管理画面）はNuxt.jsとBulma(Vuefy)で作られています。今回の新規プロダクト開発にあたっては、@kitakさんが中心となりTypescript・Remixベースでの開発に移行することとなり、併せてコンポーネントライブラリも新しく構築する運びとなりました。

外部コンポーネントライブラリのあるある課題

これまでのStailerや、自分自身が過去携わってきたプロダクトでも、特にデスクトップ利用を想定した業務用Webアプリケーションは外部のコンポーネントライブラリを利用することがありますが、立ち上げそのものはクイックに済むものの、その後の運用で大きな課題を感じることが多かったです。

  • 用意されているコンポーネントライブラリ・デザイントークンだと不十分
    • 種類が足りない、見た目を変えたい等
  • コードとFigmaの一致を保つのが大変
  • コンポーネントの粒度が使いづらい
  • 何はいじれて何はいじれないのかよく分からない

自分たちのプロダクトに合った形のコンポーネントライブラリを、クイックに立ち上げたい

yamottyさんのブログにあるように、10Xでは現在小売企業の変革を推し進めるため、複数のプロダクトを開発しようとしています。（いわゆる"コンパウンドスタートアップ"なのか？）

そんな我々が過去の学びを活かしつつ今回の新規コンポーネントライブラリの構築で実現したいことは次の4つにありました。

  1. コンポーネントライブラリの構築そのものに時間をかけない
  2. こだわりたいコンポーネントは自分たちのサービスに合わせた形で作成・改修する
  3. デザインと実装の見た目と構造を一致させる
  4. 迷いなくデザイン・実装できる

「クイックな立ち上げ」と「こだわり」を両立できるshadcn/ui

他にもいくつかの選択肢がありましたが、今回我々はshadcn/uiを使ったコンポーネントライブラリを構築することとしました。

shadcn/uiは次のような特徴を持ったライブラリです。

  • 好きなコンポーネントだけを導入できるコンポーネントライブラリ
    • 従来のUIライブラリはフルパッケージのインストールを必要としますが、shadcn/uiは開発者が個別のコンポーネントをプロジェクトに直接コピー＆ペーストできます
  • 柔軟にカスタマイズ可能
    • コンポーネントのコードはプロジェクトの中にコピー&ペーストして使うため、要件にあわせてスタイルや機能を柔軟にカスタマイズできます
  • ミニマムで使い勝手の良いデザイン
    • shadcn/uiそのもののデザインがシンプル・ミニマムでそのままでも十分使いやすいです
  • Tailwind・Radix UIをベースとした実装

ここからは、実際に取り組んだことをご紹介します。

1. Figmaでのセットアップ

まず最初にFigma側でコンポーネントを作っていくための基盤を整えつつ、ゴリゴリと我々に必要なコンポーネントを洗っていきました。

1-1. TailwindのclassをwrapするSemantic Tokenを用意する

shadcn/uiはTailwindを採用しているので、必然的に我々もTailwindを利用することになります。Tailwindは「ユーティリティファースト」を掲げており、次のようなユーティリティなclass設計を採用しています。

.text-slate-950 .text-2xl

こういったユーティリティベースな命名は汎用的ではあるものの、複数人のメンバーでデザイン・開発するにあたってはどこに何をどう使えばいいのかブレる原因となってしまうため、一部の要素については自社オリジナルの定義を使うことにしました。

現在自社オリジナルの定義を使っているのは、経験上特に利用回数が多くブレやすいタイポグラフィと色に関する指定です。*1

特にタイポグラフィでは、見出しと本文とで当てたいline-heightも異なるため、それらをまとめて指定しておくためにもカスタム定義をつけておくのは重要だと感じました。

1-2. Figmaにshadcn/uiのコンポーネントを起こしつつ、こだわりたいコンポーネントに調整・追加していく

shadcn/uiには公開されているFigmaライブラリが複数ありますが、多くのコンポーネントを自分たちで調整したり、新しく追加したりしたかったため、必要なコンポーネントのデザインをすべて自分で起こすことを選択しました。

まずボタンやフォーム系の基本的なコンポーネントを作った後、直近必要な画面のデザインを作り、その画面を作る過程で必要になった汎用パーツをライブラリ側に作り…の繰り返しで、一連の作業の中でこれが一番時間がかかったと思います。

現行のデザインシステムの反省点を踏まえて、特に汎用的で広く使うコンポーネントについては

  • サイズ設定
  • 色設定
  • サブ要素の表示オプションの追加

など、柔軟性高く利用できるようにしました。

1-3. 実装とFigmaの一致を追求する

Buttonコンポーネントのプロパティの例

すべてのコンポーネントでFigmaとコードの一致を追求しました。

一致させたいのは次のような項目です。

  • 見た目そのもの
  • コンポーネント名
  • プロパティ名

とても地道な取り組みですが、デザイナ・開発双方にとって恩恵が大きいと感じています。

  • 開発視点:
    • 開発（とQA）時の迷いが減る
    • 実装後の手戻りが減る
  • デザイナー視点:
    • コンポーネント設計にエンジニアからのFBを受けられる
    • より実装に近い形でプロトタイプによるUI検証を実施できる

2. コードのセットアップ

作ったコンポーネントのデザインにあわせてごりごりコンポーネントの実装（マークアップ）を進めました。

まずは追加したいコンポーネントをshadcn/uiからインストールしてきます。

npx shadcn@latest add button

このままカスタムすることがなければこれでもうコンポーネントが完成です！とんでもなく楽ですね…！

例えば上記のようなコンポーネントは、色やフォントの指定を独自のものに置き換えただけで、後はすべてshadcn/uiのまま使っています。

3. コンポーネントライブラリの構築にデザイナもコミットするための、ワークフローの取り組み

今回の一連の取り組みで最もこれまでのやり方と異なったのは、デザイナーもコードを書いてコンポーネントを作っていくという点です。

まずFigmaでデザインをし、それをマークアップし、ブラウザで触ってみて確かめ、違うなというところをFigmaに反映する…といった感じで、デザインと実装をスピーディーに行き来するのは立ち上げ期においてとても重要だと感じています。*2

そういったワークフローに関するその他のtryについてもご紹介します。

Storybookの導入

コンポーネントカタログとしてStorybookを導入しました。（SWEの@sinamon129さんがしゅっと導入してくれました🥹）

実際の画面を作らずとも、バリエーションごとにコンポーネントの表示やインタラクションをデザイナーが確認しながら実装調整をすることができるようになりました。

デザイナーが実際の画面を開発するとなるとまた少しハードルが上がりますが、コンポーネント単位での実装をより気軽に行えるようにしてくれたのでとっても感謝しています。

コンポーネントへのフィードバックをもらう

コンポーネントそのものへのフィードバックをお願いしたり、アプリケーション側を実装してみての使いづらい点を気軽に出してもらっています。

いつもフィードバックをくれたり、相談にのってくれる@ryo_ryoo_ryoooさん、@kitakさん、@sinamon129さんには感謝しかありません。

FigmaのDevモードの導入

VariablesにTailwindの値を入れているので、脳内での値変換も不要

これまで社内ではFigmaのDevモードを導入していなかったのですが、Figma側でコンポーネントのプロパティを実装と揃えたり、Tailwindの値を指定して作っているなら、それをエンジニアにもより簡単にキャッチアップしてもらいたい！と思いDevモードの導入を決めました。

コンポーネントのplaygroundもそうですが、そもそものデザイン指定の値がとっても見やすくなり、デザイナー・エンジニア間のコミュニケーションは相当にやりやすくなったと感じます。

現在社内でDevモードを使っているエンジニアは直近頻繁にフロントエンド開発をする方のみですが、アンケートを実施したところエンジニアさんからの意見もとても好評でした。

  • もうDevモードがない状態には戻れません
  • あった方がとても効率がいいので引き続き使いたいです🥺

（社内アンケートの自由記述からの抜粋）

作りながらデザインパターンとデザイン原則も決めていく

コンポーネントライブラリをサクッと立ち上げられたおかげで、自分自身も早い段階で新規開発する複数のプロダクトのUXやUIを組み立てていく業務に集中することができました。

その過程で、デザインパターンとデザイン原則の定義も進めることができ、複数プロダクトをまたいでの体験の一貫性や、気をつけるべきことを認識できています。

作りながら定義していっているデザインパターン

結論: 現時点ではとても良い！

技術的背景からこれまであったデザインシステムが使えず、ゼロからコンポーネントライブラリをスピーディーに構築せなばならない…となると、当初は「本当にできるのかな…？」ときっとエンジニアさんも不安に思われた部分が多々あったと思います。

蓋を開けてみると、技術選定のためのトライアルも含め2ヶ月ほど*3で一通りの構築を実現でき、実際に利用してプロダクトをゴリゴリ作っていくフェーズに入ることができるようになりました。また、当社に合った形のコンポーネントライブラリが構築できたなと感じています。

これから更に開発・運用が進みまた課題が出てくるとは思いますが、「一貫性を担保しつつスピーディーに画面構築ができるコンポーネントライブラリ」のため、今後も継続的に改善していけたらと思います。

10Xではプロダクトデザイナーを募集しています

現在マルチプロダクト化を推し進めている真っ只中で、デザイナーとして挑戦できることが多々あります！フルタイム2人目のプロダクトデザイナーとして一緒にやっていきたいという方を募集しています💥（コードが書けなくてもOKだし、書いていきたいという方もWelcomeです！）

  • 選考に興味がある
  • 転職するかは分からないけど詳細聞きたい
  • デザインシステム・コンポーネントライブラリのことについて話したい

…そんな方は是非お気軽にユートラもしくはXのDMから話しかけてください！

youtrust.jp

*1:shadow, border-radius についてはそのままTailwindの値を利用しています。

*2:社内にフロントエンド領域にフォーカスできる方が在籍していたら別かもしれませんが、弊社の場合スタートアップで一人が様々な領域に越境することが求められるというのも大きいなーと

*3:2ヶ月これだけやってたのではなく、新規プロダクトのUIデザインやその他の業務もやっていた

入社2年目QAの濃厚な日々

QA

はじめに

こんにちは。
10X 在籍2年目のソントプ（@sontob8802）です。品質管理チームの一員としてQA業務に従事しています。

この記事は10Xアドベントカレンダー2024の13日目の記事になります。
昨日はUraさんが、プロダクトマネージャー向け野良ダッシュボードの活用方法という記事を公開しています。

個人的10Xの推しポイント

今年のアドベントカレンダーの共通テーマが「在職エントリー」となっているのでまずは10Xの推しポイントを紹介したいと思います。
弊社のSlackチャンネルには『all_cheers』というチャンネルが存在してまして、些細なことでも社員同士お互いのことをSlackで褒め合っています。
例えば

  • 「先日の○○の件、助けていただいてありがとうございました！」
  • 「○○で困っていたところシュッと対応してくださって感謝です」

などなど。
そういったポジティブな文化が根付いているのが個人的10Xの推しポイントですね！

これはどんな記事なの？

ソントプが10Xに入社してからの1年3ヶ月とちょっとを振り返る形で、10XにおいてQAとしてどんな成果を上げかつ何を学んで身に付けてきたのかをお伝えしていきます。

また10XやStailerには興味あるけどHPとかだとイマイチ見えてこない「QAがどんな仕事してるのか」「開発とどんな関わり方をしているのか」などについても触れているので気になってる方々はぜひ読んでみてください。

10Xは現在ドメインチーム制となっており、Stailerを大きく3つの領域に分けてそれぞれのチームで開発とQAを行っています。

ソントプは10Xの中ではまだまだ社歴も経験も浅いのですが、ドメインチーム制になってからQAの中で全チームを渡り歩いたのは（おそらく）私だけしかいないので（おそらく）私にしか書けないであろう各チームの特色やQAとしてやってきたことを書きつらねています。

入社してからのざっくりとした経歴

  • 2023年09月　入社後、お届けチームに配属
  • 2024年04月　諸事情あり休職
  • 2024年07月　3Dセキュア対応（一時的に無所属）
  • 2024年08月　売場 / お客様体験 / お会計チームに配属
  • 2024年11月　店舗 / 商品データチームに異動　〜現在に至る

各チームの特色とQAとしてやってきたこと

経歴を見てもらえると分かりますが1年ちょっとで全ドメインチーム（＋α）を制覇しています。目まぐるしく環境が変わりながらも何とか食らいついてやってきました。そこでの成果というか個人的に学んだことや身に付いたかな〜といった事を順を追って振り返っていきます。

お届けチーム

お届けチームって何してるの？

お届けチームでは主にスーパーやドラッグストアで働いているスタッフさん（店員さん）向けのアプリの保守運用 / 管理を行っています。弊社内ではそのまま「スタッフアプリ」と呼んでいるのですが、ネット注文が入った商品を売場からピッキングしたり、配送に向けてパッキングしたりするために使用するアプリとなっています。

お届けチームでQAとして何してきたの？

チームに配属されて少し慣れてきてからピッキング機能を大改造する長期案件を担当することになりました。

この長期案件が個人的にはなかなかハードというか、とにかく影響範囲が広いのなんの…　その案件において開発実装と並行してのテスト設計を試みたのですが、テスト分析で既存機能の棚卸しを担当エンジニアと一緒に行ってもテスト分析だけで1ヶ月ほど費やす結果となりました😵‍💫　そこからさらにテスト設計していく中で新たに出てきた疑問点についても話を詰めていったりしたことで、ここでも1ヶ月ほど時間を費やしてしまいました。

ここまでテスト設計に時間がかかった経験はあまりなく割とヒーヒー言いながら何とか業務を進めていた感じです。当時の私としては最速で業務を進めていたのですが、躓く箇所も多くどうにも思うような早さを発揮できませんでした。普通に私の作業スピードが原因で遅延してしまい、いろんな人たちに迷惑かけました😭

時間が経過するほどいたたまれない気持ちが募っていき精神的にもきつかったのですが、丁寧めにテスト設計を進めていたことと疑問点をすぐにエンジニアに聞けるチームの空気感もあり、何気なく質問したところからインシデントの発見に繋がったこともあったので時間をかけて取り組んだ事自体は無駄ではなかったなと思えました（時間かけすぎて遅延するのはもちろんダメですが）この『リリース前に未然にインシデントを検出できた』ことがこの長期案件での私の最大の成果だと思っています。

お届けチームでQAとして何を学んだの？

またお届けチームは1週間Sprintで作業を進めているのですが、この長期案件の影響範囲がなかなか広くテスト分析からテスト実施を終えるまでにトータルで4ヶ月を越えてしまいました。まわりが1週間でサクサクとチケットを片付けていくのを横目に置いてけぼり食らいながらもほぼやり切ったことで一種の自信に繋がったといいますか、メンタルが鍛えられた部分があります。具体的には『案件によって求められるペースは異なるからその見極めが必要』であることと『まわりのペースに引き摺られない』ということを意識しながら作業することの大事さを再認識させられました。

ここまでがお届けチームでの出来事です。この後3ヶ月の休職を挟んでチーム外の大型案件に合流することになります。

3Dセキュア対応

3Dセキュア対応って何したの？

（めちゃめちゃざっくりとした説明になりますが）3Dセキュア（もといクレジットカードの本人認証サービス）においてクレジットカード・セキュリティガイドラインが改訂されたため弊社Stailerでも3Dセキュア2.0の導入が必須となりました。このため元々のクレジットカード決済処理に機能追加を行うことになったためそのテストも行うこととなりました。

3Dセキュア対応でQAとして何してきたの？

休職明けということもあり最初からではなく途中参加の案件となります。すでに他のメンバーがテスト設計を終えテスト実施にも着手している状態から、QAとしての感覚を取り戻すことも兼ねてテスター的な立ち位置でテスト実施から合流しました。

割り振られたテストケースをひたすら実施していくという内容でしたが、3ヶ月空いたことでStailerの基礎的な仕様が頭からすっぽり抜け落ちている状態からのスタートだったためややスロースタート気味でした。ただ、ひたすらテスト実施に専念できる環境は休職明けの身にはそこまでの負担がなくて良かったです。

なので（テスト実施だけではありますが）QA業務の感を取り戻すことができたことがこの案件での成果かなと思います。

3Dセキュア対応でQAとして何を学んだの？

当時はQA歴9年目（現在は10年目）ですが、直接お金に関わる機能のテストをしたのはこの案件が初めてでした。テスト実施を通してお金まわりの「失敗できないピリピリした（もちろんいい意味で）空気」に少しでも触れられたのは1QAとして経験値を上げられて良かったと思います。

テスト設計段階から着手していればもっと経験値を上げられたとは思いますが、諸事情あり厳しい状況だったため致し方ないですね。

ここまでが3Dセキュア対応での出来事です。この後はテストがひと段落したこともありお届けとは違うチームに配属されることになります。

売場 / お客様体験 / お会計チーム

売場 / お客様体験 / お会計チームって何してるの？

この長ったらしいチーム名はなんぞや？？？と思う方も多いでしょう。

今現在のドメインチーム体制になる前はもう少し細かく領域が分かれていましたが、近い領域をなるべくまとめて新しくチームを作った結果上記のようなチームが出来上がったというわけです。

つまり元は「売場チーム」「お客様体験チーム」「お会計チーム」と分かれていたものが領域が近いこととQAの作業量等を加味した結果がっちゃんこすることになり、かつ良い感じのネーミングが出来なかったのでそのままチーム名もがっちゃんこしたままになっている、という訳です（ちなみに開発チームは別々のままQAチームだけがっちゃんこした状態になっています）

前置きが長くなりましたが、このチームでは主にネット注文をするユーザー（お客様）向けのアプリの保守運用 / 管理を行っています。弊社内ではそのまま「お客様アプリ」と呼んでいるのですが、アプリにログインするところから始まり、実店舗と同様に売場から商品をカートに入れ配達や店舗受け取りの時間を指定し商品を受け取るために使用するアプリとなっています。

売場 / お客様体験 / お会計チームでQAとして何してきたの？

基本的には売場案件の対応をしつつ、状況の応じてお客様体験 / お会計のヘルプに入るといった具合に業務に従事していました。

売場 / お客様体験 / お会計それぞれに窓口となるメンバーがいるのですが、私はそのメンバーの下で作業を振ってもらってとにかくこなしていく、というポジションにいました。

箇条書きになりますが具体的に何をしてきたかと言いますと、

  • 導入も兼ねたリグレッションテスト
  • 定期リリース対応
  • 細々した案件のテスト設計→テスト実施

体感的な割合としては7:3くらいでテスト設計よりもテスト実施の方が多かったです。QA歴9年目にして（あれ、テスターに逆戻りしてないか？🤔）と内心思いつつも大事じゃないテストなんてないのでとにかく愚直にテストしてました。テスト設計も全くやらなかった訳ではないので休職明けの練習みたいな感じで取り組めたのは良かったなと思っています。

なので（テスト設計含めた）QA業務の感を取り戻すことができたことがこのチームでの成果かなと思います。

売場 / お客様体験 / お会計チームでQAとして何を学んだの？

当時はQA歴9年目（現在は10年目）でしたが（2回目）ひたすらテスト実施をこなすというある意味初心にかえれたこと、それから自分なりのテスト設計方法を思い出せたことは一つの収穫でもありました。

また他のメンバーの仕事に向き合う姿勢を見ていく内に知らず知らず受け身になってたことに気付いたことで「ここままではいかん！！」となり、そこから積極的に動くためにはどうしたら良いかと（社会人十何年目にして再度）いろいろ思考錯誤を始めました。

ここまでが売場 / お客様体験 / お会計チームでの出来事です。この後また別のチームに配属されることになります。

店舗 / 商品データチーム

店舗 / 商品データチームって何してるの？

Stailerにはアプリだけではなく管理画面と呼ばれるWebシステムも存在します。

この管理画面ではアプリ上で操作できないことが操作可能なため、例えば

  • お客様アプリ上ではできない締め時間の過ぎてしまった注文をキャンセルできる
  • スタッフアプリ上ではできない誤ってピッキング済みにしてしまった商品のステータスを戻す

といったことが可能です。

また新規店舗の登録 / 編集や商品の登録など、店舗登録〜開店までの一連の操作も管理画面で行なっておりその他諸々を含めた機能の保守運用 / 管理を行うのが店舗チームの役割となっています。

また商品データはこれからQAが始まる領域になるので今のところは（少なくとも1メンバーの私は）特に何もしてない状態です。これからのお楽しみですね！

店舗 / 商品データチームでQAとして何してきたの？

まず最初にQAオンボーディングを実施していただくことになりました。具体的に何をしたかと言いますと、今後店舗チームで管理画面のテストをしていく上で知っておくべき必要最低限の知識を身に付けるための操作練習です。提携しているスーパー / ドラッグストア向けのガイドを参考にしてとにかく手を動かしていました。不明点・疑問点があればすぐに質問できるチームの空気感にも助けられなんとか一通りの操作を経験できました。

QAオンボーディングの次はペアで中長期案件のテスト設計に着手することになりました。10X歴が長くドメインの知識も豊富なメンバーとペアを組んで、開発実装と並行して仕様書のキャッチアップとテスト分析から入ることになりました。今まさにこの案件の対応をしている最中なのですが日に日にQAとして成長できているなぁと感じています。

正直まだ1人では開発実装と並行してのテスト設計は荷が重いですし、ドメインの知識も乏しいのでキャッチアップしていても漏れがあったりします。そのためテスト計画やテスト戦略を立てるところまでは出来なかったのですが、可能な限り隅々まで仕様書に目を通していたことでやり取りがストップしたままの要件を発見　→　開発に共有しPdMも巻き込んで仕様とデザインを固めるところまで作業を進めるきっかけを作ることが出来ました。開発実装中およびテスト分析段階で滞留していた要件を拾うことが出来かつ要件を固めるところまで話を進められたことが、店舗 / 商品データチームに異動してきてからの最初の成果と言えます。

年明けまでこの案件の作業は続きますが、引き続き1QAとして学べるところは学び吸収できるところは吸収して少しでも成長しながら、少しでもなんらかの成果を残していけたらと思います。

また、中長期案件のテスト設計が前倒しで進んでいるので合間に空いた時間には小さめの案件を1人で担当する予定です（執筆時点ではまだ未定）

店舗 / 商品データチームでQAとして何を学んだの？

スロースターターな私には領域の基礎知識を身につけるための「導入体制（ここではQAオンボーディング）」が不可欠なのだと改めて再確認できました。チームに入って動くようになるにあたり、マストで知っておかなければいけない部分をピックアップしてレクチャー＆フォローしてくださったのはすごくありがたかったです。

また開発実装前あるいは並行してテスト設計していくに当たって具体的にどう動けばいいのかイメージを掴むことが出来たのも大きく学べた点でもあります。（SES時代含め）今までも開発実装途中でテスト設計をすることはありましたが、なんかしっくりこない、なんかモヤモヤした感じがありずっと自分の中で引っ掛かっていました。開発実装後のテスト設計の経験はそれなりにあったのですが、開発実装中からのテスト設計の経験はあまりなく具体的に実装後のテスト設計とどこがどう違うのか？　どのタイミングで何をすれば良いのか？　といった部分が明確に見えていませんでした。

それがペアでテスト設計を進めていくにつれて、今まで身につけたテスト設計との違いやどんな進め方をしていけば良いのかといった部分が鮮明になってきて自分の中にストンと入ってきた感覚がありました。上流からテスト設計してどう開発エンジニアと関わっていけばいいのか、今までフワフワしていた部分が噛み合った感じがしたんです。

そこらへんを具体的に言語化するレベルにまではなってはいないのですが感覚レベルでは色々なものを掴みかけている段階なので、このままこのチームでもっともっとQAとして成長していきたいですし出来ると確信しています。

おわりに

今年の9月半ばでQA歴10年目に突入しました。SESとして（良くも悪くも）様々な現場を渡り歩いてきた末に現在は10Xに辿り着きました。

入社してからの1年3ヶ月とちょっとを振り返ってみて色々やってきたなぁ〜と感慨深い気持ちになっております。まさに濃厚！この1年ちょっとを通してこうギュッと凝縮してStailerの基礎知識を叩き込まれたような感覚と「自分QAとしてまだまだだなぁ〜」と現実を思い知らされた感覚があります。今後はこの知見と成長意欲をうまく活かしてQAとしてチームに会社に貢献していけるように精進していきたいと思います。

また言語化してみて、入社してから経験したことを全然アウトプットしてなかったんだなぁとも思いました。思い出すのに苦労した部分もありますし、文章として書き出してみて文量がえぐいことになってしまった＆書くのにも時間がかかり過ぎてしまったので定期的なアウトプットは大事だなと痛感しました。

このブログが10XでのQAの働き方に興味がある方にとって参考になれば幸いです。

 

10Xではメンバーを募集しています！採用ページもぜひご覧ください。
明日はSuzukiRyotaさんが記事を公開する予定です。お楽しみに！

プロダクトマネージャー向け野良ダッシュボードの活用方法

はじめに

10X在籍4年目、プロダクトマネージャーの@ysk_urです。 この記事は10Xアドベントカレンダー2024の12日目の記事です。

プロダクトマネージャーとして、機能をリリースした直後（翌日）や、企画案を検討しているときなどに直接データをいじって確認したくなる瞬間が多々あります。 データ基盤チームが提供している公式のダッシュボードだけでは見えない視点を補い素早く意思決定に活かすため、最近は「野良ダッシュボード」を量産するようになりました。

この記事では、具体的な取り組みとその成果についてご紹介します。

なぜ野良ダッシュボードを作ったのか？

10Xには既にデータ基盤チームが提供する素晴らしい公式ダッシュボードがあります。ただ、それでは追えない先行指標や、プロダクトマネージャーとして独自の視点で見たいデータがあり、自分で手を動かして作ることにしました。

また、データ基盤チームとは定期的にプロダクト分析の定例を設けており、ストックされた分析レポートも増えてきてQueryを書くための学習コストが下がっていることもあり、自分でやるのも大変じゃない状況になっていました。

特に以下のような理由から、自分で作っちゃうかと思って始めました。

  1. 先行指標へのアクセス
    • 遅行指標中心の公式ダッシュボードでは捉えきれない、機能導入直後の動向や改善箇所を把握したい。
  2. 個別機能の評価
    • 私自身の関与する領域が増え、視点が広がったことで、改めて特定機能にフォーカスして評価する必要性が高まった。
  3. クイックな確認の必要性
    • 素早い意思決定を求められる場面で、自分の視点に合わせた即応的なデータ確認が求められた。
  4. 新しい仮説の検証
    • 仮説を立てた際に、事前に必要なデータを素早く抽出し、検証プロセスを効率化したかった。

どうやって野良ダッシュボードを作ったのか？

使っているツールはもっぱらLooker stuidoかGoogle スプレッドシートです。野良なので捨ててもいいや、くらいの気持ちで作ってます。抽出したデータを加工してグラフにするなどのExcelとかスプシ操作が得意な人はスプレッドシートでもいいんじゃないかなと思います。

Looker Studioは、10Xでデータエンジニアをしている吉田さんが使い方を説明してくれたおかげで虜になりました。たくさん詰め込むとちょっと遅くなるけど便利です。社内ではこのブログよりもっと色々教えてくれました。

10Xではデータ基盤チームがmartを整備してくれているので比較的分析は容易になっています。

ただ今回はログのテーブルにQueryを投げることが多かったので、過去の分析レポートで蓄積されたQuery等を流用して作成していきました。

作ったダッシュボードの一部紹介

1.特に役に立ったものたち

顧客体験系

  • 検索機能の利用状況
    • 検索クエリの数、成功率、クリック率の可視化。
  • 推薦機能の効果測定
    • 表示された推薦商品のクリック率、購入率のトラッキング。
    • 商品詳細、レジ前推薦、欠品時の類似商品、関連カテゴリ、関連キーワードなどかなり多くの推薦機能が導入済み。

関連キーワード・関連カテゴリ
代わりの商品

生産性・店舗分類系

  • 店舗分類のダッシュボード
    • 満便率、ピックパック速度、作業時間比率などの実績値を一定の基準を決めと比較し、良し悪しを判断できる状況とし、課題ごとに店舗を分類。
    • 発散していた改善アイデアを指標ごとに分類し、課題ごとに分類した店舗数に対して大通りに効くアイデアなのかを判断可能とした。
      店舗分類

2.ちょっと役に立ったものたち

ABテストモニタリング

  • 推薦機能のABテスト結果
    • テストグループごとのクリック率や購入率を比較し、機能改善の評価を実施。
    • このモニタリング方法は、他のプロダクトマネージャーが丸パクリして利用中。
    • デイリーの変動を見ても最終的な評価の場合はサンプル数の観点とかで違う方法を取るケースもあるのでこのモニタリングは雰囲気を掴む程度のもの。
      ABテストモニタリング

新機能モニタリング

  • 領収書どのくらい発行されてるのか？
  • 欠品商品の推薦利用状況はどのくらいか？
  • 関連カテゴリ、関連キーワードはどのくらい利用されているのか？ etc

具体的に役に立った事例

欠品商品の推薦機能のダッシュボードについての紹介です。 ネットスーパーの顧客体験向上を目指し、欠品商品に対して代わりとなる商品を推薦する機能を開発しました。この機能は「お気に入り商品」や「いつも買う商品」で欠品が発生した際、代替候補を提示する仕組みです。

今期は商品探索の行き止まりを消すための機能開発を複数進めていたのでその中の1つです。1つ1つは小さいインパクトですが合計で5~6個ほど新機能を提供したのでトータルの体験として以前より商品を探す体験がスムーズになったかなと想像してます。

「商品探索の行き止まり」とは、商品リストの最下部に達した時だったり、商品が欠品している場合などを指します。

評価と結果

ダッシュボードで分析を進めた結果、利用率は想定より低いことが判明しました。あまり使われていないことの仮説としては下記のようなものです。

  • 欠品そのものが少ないため、推薦機能が使われる機会が少ない。
  • 「ナスの代わりは？」のように代替品が存在しない商品もある。

この分析から、現時点ではアルゴリズム改善には積極的なリソースを割かない判断をしました。さらに、初期のアルゴリズムは他で導入済みのものを流用していたため、低コストで機能提供できたのもポイントです。

得られた学び

この取り組みを通じて、次のような重要なインサイトが得られました。

  • 欠品時の「行き止まり体験」を一定程度解消できた。
  • ネットスーパーの特性上、代替が効かない商品もありそれはアルゴリズムでは解消が不可能。
  • 機能の利用率や影響を定量的に捉え、改善や廃止を含めた柔軟な意思決定が可能になった。

新機能を出したけど何もされないまま放置みたいなことはたまにあると思いますが、今回は意思を持って現時点では積極的な改善をしない結論を出しています。

さいごに

自由にダッシュボードを作ってみたのですが、プロダクトマネージャーとしては2つの視点で野良ダッシュボードの価値を説明できるなと思っています。

  1. そもそもどのくらい使われているのか？を知ることからはじめること自体に価値がある
    • 客観的指標を元に大通りかどうかを認識することで改善のコストを下げる（やらない判断が容易になる）
  2. アイデアを評価するための客観的な基準の策定からはじめる
    • 大きなテーマに対して直接的な改善アイデアが出たり、逆にかなり細かい点に対して改善アイデアが出たりするとその期待効果が判断つかない場合がある
    • 一定の定義で作った分類を用いることで、全体の何%に該当するアイデアなのかを評価できる

なお、野良ダッシュボードをもとに公式のダッシュボードへの追加検討の相談も進んでいます。また、プロダクトマネージャーが書くQueryは心配な側面もあるのでそのあたりはデータアナリストやデータ作ってる開発チームの人に相談するようにしました。

是非皆さんも野良ダッシュボード作ってみるところからはじめてみてはどうでしょうか。QueryはLLMに相談すると良いですよ。 あと、このブログもLLMに相談して70%くらい書いてもらいました。

明日は、ソントプさんの記事です、お楽しみに！

アーキテクチャの限界を漸進的に押し上げる取り組み

開発 アーキテクチャ

10X在籍8年目、取締役CTOのishkawaです。

この記事は10Xアドベントカレンダー2024の3日目の記事です。

メイン事業であるStailerは現在5年目です。

自分はプロダクト開発を統括する立場として、プロダクト戦略立てたり、開発プロセスの整備の旗振りをしたり、開発体制を調整したり、採用活動に奔走したりと、色々な取り組みをしてきました。そして今、何に注力しているかというと、コードの立て直しです。

なぜコードの立て直し？

プロダクトを5年くらい開発していると、開発速度は当初と比べて落ち着いてきます。その要因は色々あると思いますが、自分は「事業やプロダクトのフェーズの変化による規模や複雑度の変化」と「規模や複雑度に対する技術的な適応度」の2点に着目しました。

前者はプロダクトマネジメントのトピックです。Stailerでは、自分たちが持つ強み、組織の規模、得られる事業成果、運用にかかるコストなどを考えて、自分たちは何をやって何をやらないのかという指針を策定してきました。すべてが想定通りになった訳ではないですが、パートナー企業のネットスーパー/ネットドラッグ事業の成長を支えつつ、10Xとしても十分に開発と運用ができる形にできたと思います。

後者はエンジニアリングのトピックです。事業やプロダクトのフェーズの変化に伴って、システムの規模や複雑度が変化します。10Xの開発組織でもこの変化に対処する取り組みは続けており、この1-2年は保守性を最重要なものとして掲げ続けていますが、十分に追いついているとは言い切れない状況です。規模や複雑度に追いついていないというのは、技術的な要因によって開発を速くできていない、運用を楽にできていないといった状況を見て、そのように捉えています。

翻って経営の帽子で考えると、ネットスーパー/ネットドラッグ事業はもっと早く成長させたいし、新規領域への投資も拡げたいという状況です。その実現に向けて最初に対処しなければならないのが技術的課題なので、それに取り組み始めたという訳です。

後になってから壁に当たるのは何故か

最初は速くて後から遅くなったという状況ですが、これは後から入ったコードが特に悪いという訳ではなく、ある程度の規模や複雑度に達すると遅くならざるを得ない構造に最初からなっていたと分かりました。つまり、アーキテクチャが劣化したのではなく、アーキテクチャの限界に達したということです。

最初からもっと上手くやれたら良かったと思いますし、限界の到達を遅らせる余地はあったと思い当たる節はいくつもあるのですが、今のプロダクトは今の実装で社会に価値を生み出しています。悔やむだけではアーキテクチャが改善されることもないので、これからの規模や複雑度を見据えて、どうやってなりたい状態に近づけるかを今は考えています。

アーキテクチャの限界を漸進的に押し上げる

以下の手順を繰り返して、やっていこうとしています。

  • 欲しい特性を狙ってアーキテクチャ決定を積み重ねる: 現状のStailerの開発には規定が少なく、自由度が高い状態にある。組織にとって望ましい特性がこのまま自然発生する訳もないので、今の組織に必要な特性は何か特定し、その特性を得られそうなアーキテクチャ決定を積み重ねる。
  • ADRでアーキテクチャ決定の意図を明確にする: アーキテクチャ決定は意図を持ってなされるが、その意図が正しく認識されないと、決定自体が無視されたり、不健全な形でバイパスされることがある。とはいえ、当該のアーキテクチャ決定を理解しなければならないタイミングは人によって異なるので、誰もがその決定を追えるようにするためにADR(Architecture Decision Record)を残す。
  • linterでADRに辿り着けるようにする: ADRがあったとしても、メンバーがその存在に気付けなければ意味がない。適切なタイミングでメンバーが気付けるようにするため、ADRの決定に反するコードを検知するlinterをADRとセットで実装する。
  • ADRへの違反状況を可視化して漸進的に適応度を上げる: ADR + linterの作成時に、すべての既存コードをアーキテクチャ決定に沿わせることは難しいので、当初は違反箇所をlintの対象から除外することを許容する。lintの除外数はADRへの適応度を表すので、それを可視化して漸進的に適応度を上げていって、最終的に得たかった特性が広く得られるようにする。

linterによる検知はエディタ上では、以下のスクリーンショットのようになります。

「データレイヤーをUIレイヤーに依存させない」という決定への違反を検知してエディタ上のエラーとし、具体的に何が違反なのか、違反をどのように解消して欲しいかを表示しています。ルール名のところをクリックするとADRが表示され、どういう背景で「データレイヤーをUIレイヤーに依存させない」という決定をしたのか知ることができます。

この仕組みはDartのcustom_lintを使っていて、以下のように簡単に実現できます。

class NoUiLayerImportFromDataLayer extends DartLintRule {
  static const _code = LintCode(
      name: 'no_ui_layer_import_from_data_layer',
      problemMessage: 'データレイヤーからUIレイヤーのファイルはインポートできません。',
      errorSeverity: ErrorSeverity.ERROR,
      url: 'https://example.com/path/to/adr');

  @override
  List<String> get filesToAnalyze => const ['/**/data/**.dart'];

  @override
  void run(
    CustomLintResolver resolver,
    ErrorReporter reporter,
    CustomLintContext context,
  ) {
    context.registry.addImportDirective((node) {
      final uri = node.uri.stringValue;
      if (uri != null && uri.contains('/ui/')) {
        reporter.reportErrorForNode(code, node);
      }
    });
  }
}

平凡な決定も浸透させて価値を高める

アーキテクチャ決定という大層な雰囲気ですが、実際には平凡なものです。例えば、「レイヤーAはレイヤーBに依存させない」とか、「Xという責務はレイヤーAに位置付ける」とか、「レイヤーBのオブジェクトはimmutableでなければならない」とか、そういうものです。

1つ1つが平凡な決定であっても、ある程度以上の規模のコードベースではそれが浸透していることが大きな価値になります。自分自身、これを体感し始めたという段階ではありますが、浸透が進めばもっと上手く開発やテストができるようになりそうだという期待感もあります。

意気込み

今あらためてエンジニアリングにコミットすることで、会社がネットスーパー/ネットドラッグ事業をより早く成長させ、新規領域への投資も拡げられる状態を作りたいと意気込んでいます。

10Xではソフトウェアエンジニアも募集しているので、面白そうだなと思った方は、ぜひ採用ページもご覧ください。カジュアル面談のURLも用意したので、まずは話を聞いてみたいという方はそちらもどうぞ。

明日はビジネス本部の鈴木さんが記事を公開する予定です。お楽しみに！

10Xのプロダクトデザインの近況と、プロダクトデザイナー募集のお知らせ

Design

10X プロダクトデザイナーの日比谷（ @suuminbot ）です。

10Xではしばらくプロダクトデザイナーの新規募集をクローズしていましたが、この度新たにプロダクトデザイナーを募集することになりました！

しばらく外部発信できていなかったこともあり、この記事では最近のStailer、そして10Xでのデザインの近況についてまとめようと思います。

TL;DR

  • Stailerのプロダクト開発はフェーズが変わり、新たなイシューを探索できるようになった
  • Stailerの「価値の源泉」の1つはやはりUXにある
  • 実は新規プロダクトも複数開発している
  • デザイナーの専門性を持って「良いUX」を作るためのプロセスをリードする方を募集する
  • 少しでも興味がある・もっと詳細を知りたい方はカジュアル面談しましょう！

…ということで興味がある方はぜひこのあともご覧ください！

続きを読む