お久しぶりです。SRE の @babarot です。2022年4月に書いた 10X に SRE Team ができるまでとこれから 以来、3年ぶり2度目の文章です。10X に SRE チームができてから3年以上が経ち、その間の活動や成果などについて沈黙しまくっていたのですが、振り返ると実に多くのことを達成してきました。最近は会社的にも嬉しいニュースがあり、これから更にやっていくぞ 🔥というフェーズに来ております。この3年間、黙々と頑張りすぎてアウトプットがなかなかできていなかったので、このブログ記事ではこれまでの SRE の取り組みを軽く紹介しつつ、今後はそれぞれのテーマに深ぼったネタを定期的に記事にして投稿してきます！まずは第1弾として2025年時点の 10X SRE の現状報告ブログをどうぞ。
続きを読む
前回記事で書いたように、お届けチームの扱うシステム領域ではさまざまな非同期処理が行われています。
この記事では
を書いています。
主には次の2つのような目的がある箇所で非同期処理を行なっています。
非同期処理を積極的に採用するにあたり、同期処理とのトレードオフや監視すべきメトリクス等、運用する際のポイントはいくつかありますが、これらは後続の記事で詳しく解説する予定です。
まず前提として「ピックパック」「お客様注文」「配達」のような領域を見出したとします。 その領域を「お客様の注文内容に応じてピックパックが指示される」「ピックパックで商品を品切れにしたら、お客様との取り引き中の商品を品切れにより、お届け数を減らす」というようなケースで「領域間をまたぐ」としています。
領域をまたぐ際にはサービスが目指す方向性と相談し、狙って領域同士を疎結合にするメリットがあれば非同期処理を採用しています。
とくにカスケード障害がさけられるメリットの大きい箇所は進んで非同期処理にしています。
「同期処理をミニマルにしたい」ケースだと、
ようなケースがあります。
予定に追加では同期的にしても意味的には問題ないですが、ピックのAPIはとにかく素早くレスポンスを返したいので、クライアントアプリから呼び出されるRPCではピックのみ行い、パック予定への追加は非同期にしています。
RPCではパッキング用のデータは不要で、ピッキング用のデータは読み込み/書き込みで済みます。
など、下準備があって非同期処理を実現できます。 おかげでピックのRPCは低いレイテンシを保てています。
サマリというのは主にFirestoreでデータ集計をするには都度クエリを実行では実現が難しく、事前に集計しておきたいケースです。 イベント駆動による非同期処理導入前ではRPCをハンドリングしたプロセス上でバックグラウンド処理を実行していました。 サマリというだけあり、データ操作の競合も多いのとサーバが停止するとサマリされないケースもありました。 単一プロセス内での非同期処理からシステム単位での非同期処理になったことで確実に処理することを可能にしました。
こういったイベント駆動な非同期処理はFirestoreとEventarc、Cloud Runの組み合わせで実現されています。
https://cloud.google.com/eventarc/docs/run/route-trigger-cloud-firestore?
EventarcによってFirestoreの書き込みをトリガーをにして、ドキュメントを非同期メッセージとしてCloud Runに送りつけていますが、EventarcはCloud Pub/Subで成り立っています。 なので、監視やリトライ設定はCloud Pub/Subへの設定で行なっています。
またCloud Pub/SubのSubscriptionはPush Subscriptionで作られるので、Cloud RunへはプレーンなhttpリクエストとしてCloudEventsの形式にそって送られます。 簡単なメトリクス確認はCloud Run用のダッシュボードで賄えます。
一文で流れを書いてみると、「Firestoreに書き込んだドキュメントが、非同期メッセージとしてCloud Pub/SubにPushされ、CloudEventsの形式でCloud Runへhttpリクエストで送信されます」のようになります。
シンプルにFirestoreへ書き込みます。 非同期メッセージとして扱われるので基本的にCreateのみ起きるようにしています。 場合によってはDeleteをトリガーにしますが、非同期メッセージをイベントとして扱う際はCreateです。 また、非同期メッセージとして扱うドキュメントはイミュータブルなモノとして扱いためUpdateをしないようにしています。 イベントして扱う場合には発行時間を必ずペイロードに含める、イベントが起きた操作を追跡可能にする識別子を含めるなど一定型にはめて、イベントの発生を非同期メッセージで表せるようにしています。
http requestのbodyがCloudEvents の形式にそっていることを前提にしています。 subscriberにFirestoreのドキュメントを受けとることを前提にサーバを実装できる小さなライブラリを用意してます。 そのライブラリではpublishした際に付与する一意性のある識別子を利用してメッセージを重複して処理しないように制御したり、メッセージを順序正しく処理できるようなユーティリティも実装しています。 なので実装側はシンプルに処理したいイベントと処理そのものをペアでコードが書けるようになっています。
今回説明した非同期処理は機能実装の最初のデプロイ時から利用していた訳ではありません。 大雑把に以下3ステップで本番環境での実現しました。
この段階ではこの記事で説明している「非同期を導入するメリット」を受けられないわけです。
とはいえリクエスト数が多くなかったり、リクエストのパターンによって問題なく動作します。
ここでのミソは将来非同期処理を導入していこうと画策することでイベントを処理するイベントハンドラで実装することです。
イベントハンドラと呼び出し側でイベント以外を共有しないことで、イベントハンドラの実行場所が変わっても同じロジックがそのまま動きます。
この段階は3. への準備段階です。 事前にイベント（メッセージ）の流量が本番同等で実行し続けられるか検証はしていましたが、3. の導入はどんなリスクがあるのか未知数でした。
そこでfeature flagを利用して2. と3. の切り替え（切り戻し）は即時でできるようにしました。 findy-tools.io
2, 3の並走している場合、二重処理が問題になるならイベントハンドラ側の仕組みで二重処理は抑制されます。
結果的に3の仕組みに問題がなかったので切り戻しをすることはありませんでした。
この段階に来ると記事内で紹介しているようにFirestoreへの永続化をトリガーにEventarc経由でCloud Runによりイベントハンドラが実行されます。 2ではプログラム上非同期であるものの、システム的には同期的にイベントハンドラが実行されていました。 それが3ではシステム的にも非同期になります。 なのでイベントを発生させるロジックからは完全に後続の処理を気にすることはなくなります。
メッセージによる非同期処理を実現するのために参考としているのはアウトボックスパターンです。
https://microservices.io/patterns/data/transactional-outbox.html
FirestoreがEventarcを利用することでドキュメントの書き込みをトリガーをするのが容易で非常に助かったところでした。 MessageRelay実現のためにクラウド側の仕組みのトリガーによってやり取りできるのはデータベースをポーリングするより運用しているうえで手間や気にすることが少なくありがたいです。 サンキューEventarc!
次回も引き続きお届けチームによるイベント駆動設計への取り組みを紹介していきます。
お届けチームでは絶賛エンジニアを募集中です。カジュアル面談もwelcomeです。 ご応募お待ちしております。
ソフトウェアエンジニアの金子（@naoty_k）です。
10Xでは、これまでネットスーパー事業者向けの管理画面（以下、管理画面v1）をNuxt.jsを使って開発・運用をおこなってきましたが、現在はReact Routerを用いた新しいアプリケーション（以下、管理画面v2）への移行を進めています。本記事では、なぜ移行することになったのか、どのように進めているのか、そして技術的な工夫とこれからの展望についてご紹介します。
これまで開発してきた管理画面v1はNuxt.jsをベースとしており、当時は迅速な開発に大きく貢献してくれていました。
しかし、数年の運用を経て将来的な拡張性やメンテナンス性に技術的な課題が生じ、フルスクラッチを検討していました。一方、10Xの他のプロダクトではReact + React Routerの構成が導入され始めていたため、新しい管理画面v2もReact Routerベースでフルスクラッチする判断に至りました。
管理画面v1の全画面を一気にv2に移行するのは現実的に不可能なため、画面単位での段階的な移行を計画しました。
まず、v1からv2への移行の技術的な制約や課題を明らかにするため、プロトタイプを実装し、認証方式の検証やgRPCサーバーとの通信などの課題を明らかにしていきました。Design Docを書き、SREチームやセキュリティチームなどを巻き込みながら技術的な意思決定を重ね、管理画面v2のアーキテクチャを設計していきました。
現在は共通して必要となる認証やバックエンドとの通信部分、レイアウトなどの実装を終え、比較的影響が少ない一部のCRUDを含む機能群をv2に移行しました。
管理画面v2ではv1から引き続き認証基盤としてFirebase Authenticationを使っているのですが、v1とv2の間でログイン状態をシームレスに共有するための工夫が必要になりました。具体的には、Firebase Authentication SDKがIndexedDBに永続化した認証情報をService Workerで読み取りIDトークンを取得してv2へのリクエストヘッダーに付与するようにしました。
バックエンドのgRPCサーバーは管理画面v1と同じものを引き続き利用しているため、フロントエンドでの工夫のみで認証状態を引き継げるようになりました。
管理画面v2への移行にあたって、アプリケーション本体だけでなく共通で利用するコンポーネントライブラリやgRPCクライアントを含めたモノレポ構成に移行しました。
といった複数のパッケージをpnpm workspaceを使い、1つのリポジトリで管理しています。これによって、依存関係の明確化や変更の一括管理が行えるように開発効率が改善しました。
なお、新しいデザインシステムについてはこちらの記事で紹介されています。
管理画面v2への移行は現在進行形で進んでいますが、画面の数も多く、単純な作業だけでもかなりのボリュームがあります。
そこで現在は、DevinなどのAIエージェントを活用して、コード資産をもとに画面の実装を自動化できないかという検証も始まっています。これが成功すれば、手作業の工数を減らしつつ、移行スピードを大きく上げられる可能性があります。
また、社内では月次でフロントエンド勉強会を開催するようになり、Reactや周辺技術などをテーマに情報共有や議論を行っています。技術的にキャッチアップしやすく、仲間と成長できる環境づくりも進めています。
10Xでは、モダンなWebフロントエンド技術を活用してプロダクトの価値や開発体験を高めていく仲間を募集しています。ご興味のある方は、ぜひお気軽にご連絡ください！
10X のソフトウェアエンジニア @metalunk です。
このブログでは、10X が提供する小売チェーン向け EC プラットフォーム Stailer での検索改善について説明します。今回は特に “並び順” にフォーカスした内容です。
対象読者は主に検索エンジニアですが、「並び順改善の下準備が大事」の章以外は専門知識は出てこないため、検索以外を専門とするソフトウェアエンジニアのみなさんにも読んでいただけるはずです。
また、Stailer を使っている小売事業者の方も、使っていない小売事業者の方にも、ネットスーパーにおける検索機能はどう改善されているのか、なにが難しいのかをこの記事を通じて知ってもらえると嬉しいです。
本記事は8割 LLM が書きましたw みたいなものではなく、筆者が真心込めて手で書きました。
続きを読む
こんにちは、10Xで検索推薦の機能・基盤の開発運用を担当している安達( 今回、LLMを活用して商品検索タグ(以下、タグ)を自動生成し、検索対象に加えることでRecallを改善しました。
本記事では、その取り組みの背景、具体的な施策、設計、評価、そして得られた成果についてご紹介します。 Stailerでは、商品データに含まれるテキスト情報が限定的であるために、ユーザーが検索しても意図する商品がヒットしないケースがありました。 例えば、ユーザーが「メイク落とし」と検索しても、商品名やカテゴリ名、商品説明文に「メイク落とし」という文言が含まれていないクレンジングオイルの商品はヒットしませんでした。
特に商品説明文自体が存在しない商品も多く、全体的に検索に利用できるテキスト情報が不足している状況でした。 この問題に対しては、小売事業者様が管理画面から手動で商品に検索キーワード(同義語や関連語)を紐付ける機能を提供していました。
しかし、対象となる商品数が膨大であることや、キーワード選定・入力の手間から、この機能は十分に活用されているとは言えず、手動運用によるカバーには限界がありました。 また、10X内部でもElasticsearchに類義語辞書を登録することで継続的にRecall向上に取り組んでいますが、こちらも手動でのメンテナンスが必要であり網羅性には限界がありました。 これらの課題に対し、商品名とカテゴリ情報をインプットとして、LLMにタグを自動生成させるアプローチを採用しました。
生成したタグをElasticsearchの商品データに追加し、検索対象とすることで、ユーザーが入力するであろう多様な検索キーワードに対応し、Recallの向上を目指しました。 ベクトル検索やシノニムの自動生成など他のアプローチも検討しましたが、まずは既存のテキスト検索の仕組みを大きく変更せず、低コストかつ迅速にRecallを改善する手段として、LLMによるタグ生成が有効と判断しました。 また、ネットスーパーの検索特性として、ユーザーは欲しい商品が比較的明確であり、商品名やカテゴリ名を表す短いキーワード(例: 「牛乳」, 「パン」, 「シャンプー」)での検索が多い傾向があります。
このような検索行動に対しては、関連キーワードをタグとして補強するアプローチが効果的ではないかと考えました。 タグ生成からElasticsearchへの反映までの処理フローは、以下のようになっています。 このフローは、大きく以下の2つの独立したプロセスで構成されています。 それぞれの実行タイミングが異なるため、生成されたタグが実際に検索結果に反映されるまでに最大1日のタイムラグが発生する構成となっています。 Stailerは複数の小売事業者様がそれぞれ複数の店舗を運営しており、同じ商品(同一JANコード)でも在庫を持つ店舗ごとに個別のElasticsearchドキュメントが存在します。
全てのドキュメントに対してLLMでタグ生成を行うと、APIコストと処理時間が膨大になります。 そこで、JANコード単位でタグを生成・管理し、Elasticsearchへのインデックス時にJANコードをキーとして各ドキュメントにタグ情報を付与する方式を採用しました。
これにより、LLMのAPIコール数を商品数(JANコード数)に抑えることができました。 更新頻度：バッチ更新 vs リアルタイム更新 結論: バッチ更新を採用。タグは検索体験を補強するものであり、必須データではありません。
新商品へのタグ付与遅延による影響は限定的と判断し、実装・運用のシンプルさを優先しました。 更新方法：全件洗い替え vs 差分更新 結論: 差分更新を採用。APIコスト、処理時間の抑制のため、差分検出ロジックの実装コストは許容できると判断しました。 LLMが生成するタグの品質は100%正確ではありません。
不適切なタグが検索結果に悪影響を与えるリスクを考慮し、以下の設計にしました。 LLMによるタグ生成が実用に足るか、コスト・処理時間はどの程度かを見極めるため、以下の検証を行いました。 モデル、プロンプト 今回のタスクは短いテキスト生成であり、 検証で十分な精度が期待できなければ別モデルも検証しようと思いましたが、 タグを生成する基盤 LLM APIを直接叩く方式も検討しましたが、既存のデータ処理基盤であるBigQueryとの親和性、運用負荷を考慮し、BigQuery MLの 結果として、BigQueryの タグ生成パイプライン(VertexAI Pipelinesで日次実行) indexing worker 生成されたタグを検索対象に含めた新しい検索ロジックを評価し、問題があればプロンプトやロジックを修正するサイクルを回しました。 評価 タグ追加によるRecall向上（ヒット件数増加、ゼロマッチ率減少）を期待し、評価を行いました。 定性評価 定量評価 プロンプトチューニング デモをしていると、タグの品質にばらつきが見られ、いくつかの具体的な課題が見つかりました。
例えば、冷凍でない「うどん」に対して「冷凍うどん」という誤った温度帯を示すタグが付与されたり、商品の実態とは異なるサイズ（例: 「大容量」）やブランド名が生成されたりするケースがありました。 また、商品の「味・成分」(例: 「無添加」「グルテンフリー」)や「用途・対象」(例: 「赤ちゃん用」)に関するタグが誤って生成されることはリスクが高いと判断しました。
これらの情報が不正確だと、ユーザーに誤解を与え、購買体験や安全性を損なう恐れがあるためです。 このリスクを低減し、より安全で関連性の高いタグを生成するため、プロンプトに具体的な制約ルールを盛り込みました。
試行錯誤を経て、最終的に以下のプロンプトを作成しました。 評価とチューニングを経て、品質に問題がないと判断できた段階で、生成されたタグを検索対象フィールドに加えるロジック修正を行い、本番環境へリリースしました。 今回は、開発期間やリソースの制約からABテストやインターリービングは実施せず、リリース前後の主要KPIを比較することで効果を測定しました。 結果 本記事では、商品情報の不足による検索Recallの低さという課題に対し、LLMを活用して検索タグを自動生成し、既存のElasticsearchベースの検索システムに組み込むことで改善を図った事例を紹介しました。
設計段階でのトレードオフの考慮や、LLM生成物の品質担保、評価方法などが、同様の課題に取り組む方々の参考になれば幸いです。 今回はLLM活用の第一歩として、まずは既存の仕組みと連携しながら検索のヒット率を改善しましたが、LLMにはお客様の買い物体験を大きく進化させる可能性があると考えています。 例えば、ネットスーパー特有の課題として、一度の買い物で多くの商品をカートに入れる手間が挙げられます。
RAGのような技術を取り入れれば、「今週の献立に必要な食材をまとめて提案し、ワンタップでカートに追加できる」といった、新しい買い物体験を提供できる可能性があります。
このようなユーザーの課題解決に繋がるLLMの活用についても、今後挑戦していきたいです。
はじめに
id:kotaroooo0)です。
10Xでは小売チェーン向けECプラットフォームStailerにおいて、商品検索機能ではElasticsearchを利用しており、主にテキストマッチングによって検索を実現しています。課題：情報不足による検索ヒット率の低さ
施策：LLMによる検索タグの自動生成と活用
なぜタグ生成か？
設計
JANコード単位での生成と管理
タグデータの更新について
No
Option
Pros
Cons
1
バッチ更新
既存のMLパイプライン基盤を利用でき実装がシンプル
新商品が登録されてからタグが付与されるまでにタイムラグが発生する(最大1日)
2
リアルタイム更新
新商品登録後、即座にタグが付与される
イベントドリブンな新しいアーキテクチャの構築・運用コストが必要
No
Option
Pros
Cons
1
全件洗い替え
LLMモデルやプロンプト改善の恩恵を常に受けられる。常に最新の状態で上書きするため、差分管理ロジックが不要。
LLM APIコストの増大: 変更がない商品に対しても毎回APIコールが発生し、非効率。また、処理時間が長くなる。
2
差分更新
LLM APIコストの最適化: 新規商品や商品情報が更新されたもののみを対象にタグ生成を行う。また、処理時間も短くなる。
どの商品に対して再生成が必要かを判断する差分検出ロジックが必要になる
タグ生成の品質とリスク
プロジェクトの進め方
1. PoC：タグ自動生成の実現可能性と品質検証
gemini-1.5-pro と gemini-2.0-flash
gemini-2.0-flashで十分な品質のタグが生成でき、かつコストと処理速度の点で優位性があると判断し採用しました。
gemini-2.0-flashでは15万JANコードに対して、$6程度で想定以上に安価でした。gemini-2.0-flashがコストパフォーマンスが優れており今回は試しませんでした。ML.GENERATE_TEXT 関数の利用を第一候補としました。
ML.GENERATE_TEXT は、既存のパイプラインへの統合も容易であると判断し、採用することにしました。2. インデキシングの実装
ML.GENERATE_TEXTを用いてタグを生成。
3. 商品検索ロジックの評価とプロンプトチューニング
Instacartのようなネットスーパーの商品検索精度改善を担当しています。
商品検索のRecallを向上させるために、次の商品に関連するキーワードを生成してください。
【商品情報】
商品名: {product_name}, カテゴリ名: {category_names},
【キーワード生成ルール】
1. 商品名やカテゴリ名に含まれる単語、または部分一致する単語は生成しない。
2. 次のような誤解を招く可能性のある属性を示すキーワードは生成しない。
- 温度帯: 冷凍, 冷蔵, チルド, 常温
- 味・成分: 無糖, 加糖, 低糖質, グルテンフリー, オーガニック, 無添加
- サイズ・量: 大容量, 業務用, 小分け, 一人前, ファミリーサイズ
- ブランド・地域: 北海道産, 沖縄産, 国産, 地域限定, 直輸入
- 用途・対象: 赤ちゃん用, 幼児向け, ペット用
3. 商品に関連性が高く、かつ一般的に検索される可能性のある単語を優先する。
4. 料理・用途・関連カテゴリを考慮したキーワードを生成する。
【出力ルール】
- 出力は生成されたキーワードのみで構成し、スペースなしのカンマ区切りで出力する。
- 生成するキーワードの数は、関連性が高い順に最大3つに制限する。
4. 検索ロジックの修正と本番リリース
5. 本番リリース後の効果測定
おわりに
10X ソフトウェアエンジニアの鈴木です。 これからしばらく「お届けチーム取組紹介」と題して「イベント駆動アーキテクチャ」につながることを複数の記事に渡ってお伝えしていきます。 product.10x.co.jp
お届けチームでは、 「ピックパック」というお客様から承った内容を元に、商品を売り場や在庫置き場からとってきて（ピック）、箱詰め（パック）する業務領域（以下ピックパック）のシステムを疎結合化することで、技術的な課題を解決することを目指してきました。
社内では「モジュール化」という言葉を使用して取り組んできましたが、これは「ピックパック領域のコードをお客様へ対面するためのコードと疎結合にする取り組み」でした。本記事では、この取り組みの概要を紹介します。技術的な詳細については、後続の記事で解説します。
取り組み前のシステムでは、Orderクラス（as 1 Firestoreドキュメント）に、注文に関するあらゆる領域のロジックとデータ永続化処理が集中していました。具体的には、お客様の注文内容、ポイント処理、クーポン処理などのお客様との契約に関する情報から、ピックパック業務の状態、配達の状態など、注文処理全体に関わる情報が含まれていました。
このような設計は、単一のプロダクトで注文受付から配達完了までを管理できるという利点がある一方で、システムが密結合になり、機能の拡張や修正が困難になるという課題がありました。
主な課題は以下の3点です。
とくにお届けチームのプロダクト改善はピックパックに関わることが現在多く、コードや構造改善の恩恵が得やすいということで改善の実施に踏み出しました。
これらの課題を解決するために、以下の取り組みを実施しました。
これらの取り組みに伴い、以下の2つのデータ連携が必要になりました。
これらのデータ連携を、業務上の意味を持つ「イベント」としてモデル化し、イベント駆動型の非同期処理コンポーネントを導入することで実現しました。 また、ピックパックの進捗状況をリアルタイムに集計するために、イベントをトリガーとして集計処理を実行する仕組みも導入しました。
これらの改善により、Orderとピックパックの間の影響関係がインターフェースを通じて明確になり、「実はXXXにも影響があった」という予期せぬ影響を減らすことができました。
ロック競合についてはピックの操作はPickingというある1注文の1商品ごとにあるデータへの操作になったので、最終的にOrderドキュメントへのデータ連携処理が残るものの、バックグラウンドで非同期に処理されるためスタッフの業務への影響はほとんどなくなりました。
カスケード障害のリスクも、データとコードの分離、および非同期処理の導入によって大幅に低減しました。ピックパック処理にバグがあった場合でも、ピックパック業務が開始されるまでの間に修正できれば、お客様やスタッフに影響が出るのを防ぐことができるようになりました。これは、改善前はピックパック処理のバグが注文受付自体を妨げる可能性があったことと比較すると、大きな改善です。
本記事では、ピックパック領域の疎結合化に関する取り組みの概要と、その効果について説明しました。技術的な詳細については、後続の記事で詳しく解説する予定です。
読者になるボタンを押すと後続の記事が公開されたときに通知を受けとれるのでおすすめです。
先日、Flutter Tokyo #6 で同タイトルの発表をさせてもらいました。10分ほどの発表でしたが、割と良い反応をいただけたので、少し内容を補足してブログとしても公開します。
発表時のスライドは以下です。
一般的に、モバイルアプリは自動テストしづらい箇所が多いと言われます。たしかに、画面から素朴に実装していくと、自動テストでは確認が難しくなりやすいです。そうなってしまうと、アプリを起動して手動で動作確認するしかなくなってしまいます。
一方で、設計やツールを適切に使えば、モバイルアプリであっても広範囲が自動テストで検証可能になります。手動での動作確認を完全になくすことはできませんが、手動テストへの依存度は下げられます。
手動テストへの依存度が下がると、検証時間の短縮、手戻りの抑制など、さまざまなメリットが得られます。また、手動テストにも良い影響を与え、手動テストでなければ確認できないことに集中できるようになります。
テストしづらさは、以下の2つに分解できます。
原因は色々と考えられますが、最もよくある原因はテスト対象の役割が大きすぎることだと思います。モバイルアプリではデータとUIの両方を制御する必要がありますが、両者の役割が混在すると状況はより厄介になります。また、役割が大きくなると記述するテストケースも網羅しづらくなり、抜け漏れが出てテストの価値が下がりやすくなります。
役割を混ぜないこと(特にデータの制御とUIの制御)、役割を大きくしないことを守れば、あとは場所ごとに適切な手段を使えば十分テスト可能となります。
例としてGitHub APIでリポジトリ検索をして、結果を表示する画面を考えます。
この画面はそれほど複雑ではありませんが、それでも一気にすべてをテストするのは得策ではありません。役割の種類を混ぜないこと、役割を大きくしすぎないことを守りながらクラスの境界を設計し、それぞれをテストしていきます。
数ある責務分割の中でもトップクラスで効果的なのは、データとUIの関係を疎にすることです。これを守ると、先に挙げた「テストしづらさ」の要因の1つである「テストする条件の再現が難しい」は解消しやすくなります。
依存関係の向きは常にUI → データなので、データとUIの関係を疎にするには、データ側のロジックの詳細がUI側に漏れないように設計します。今回の例ではデータ側はGitHubと通信を行い、レスポンスのステータスコードを確認し、JSONをパースし、データが想定通りか検証する、といった処理が必要ですが、この一連の内部処理の制御にはUIは関わらないようにします。
具体的な実装としては、データ側は以下のようなインターフェースを提供します。
UI側の視点で見れば、データ側に入力を渡せば結果が得られる状態になっています。一連の内部処理について立ち入ることはできず、結果だけを受け取るようになっています。
出力を適切にレイアウトに反映するには、内部処理の中で何が起きたか知る必要がある場合もあります。そういった場合に備えて、データ側では実行結果に適切な情報を含めるようにします。上記の例では、検索の失敗時にGitHubExceptionをスローすることになっていますが、この例外に適切な情報が含まれていれば、UI側は利用者と適切にコミュニケーションができます。
データとUIの関係が疎になると、UIの役割は「データに入力を渡して、出力をレイアウトに反映するだけ」というシンプルなものになります。これはコード上にもあらわれ、実際にwidgetの実装は以下のようになります。
なお、ここではRiverpodを使っており、前掲のデータ側のインターフェースを呼び出すproviderを以下のように定義しています。
ここでもう1つ重要なのは、UIが依存するデータ側の実装が差し替え可能になっているということです。Riverpodにはproviderを差し替えるoverrideという機能があり、データ側の出力を任意のものに変えられます。これによって、先に挙げた「テストしづらさ」の要因の1つである「テストする条件の再現が難しい」は解消されるという訳です。
UIの役割は「データに入力を渡して、出力をレイアウトに反映するだけ」というシンプルなものになりました。テストでもこの役割を検証します。
「テストしづらさ」の要因として「テストする条件の再現が難しい」「結果の検証が難しい」の2つを挙げていましたが、これまで説明していなかった「結果の検証が難しい」は、UIのテストにおいてはgolden testを使って解消します。
実際のテストケースに入る前に、テストする条件が再現されるwidgetを返す関数を準備します。テストする条件のデータの出力を渡して、providerをorverrideしてwidgetを返します。
ここまで来れば、あとは条件ごとにテストケースを書くだけです。以下のテストコードは、データ側がリポジトリのリストを正常に返した時に、その結果がUIに正しく反映されるか検証しています。
左側の画像はテストに使用するgolden fileです。右側のテストコードを書いて、flutter testを--update-goldensオプションをつけて実行すれば生成されます。実装中はgolden fileが想定通りになるまで修正と再生成を繰り返します。一度完了したら、以降はテストのリファレンスとして使用します。
通信が失敗した場合のテストケースも同様に書けます。今度はresultにFuture.error(GitHubException.connectionFailed()を渡して、通信が失敗した場合を再現しています。
このように「テストしづらさ」の「テストする条件の再現が難しい」と「結果の検証が難しい」をそれぞれ解決すれば、UIのテストも簡単に書くことができます。このような形で開発を進めていけば、アプリを起動して動作確認する必要性は自然と下がっていきます。
視点を品質と生産性に移すと、以下のことが言えます。
手動テストでは再現が難しい条件も、今回の形なら簡単に再現できます。
例えば、GitHubで障害が発生して500エラーを返した時にUIがどうなるかは、手動では再現が難しいです。しかし、今回の形であれば_createWidget()のresultにGitHubException.unsuccessfulResponse(statusCode: 500)を渡せばそれが再現できます。
あらゆる条件の再現が簡単になり、自動テストが実装されるということは、実行コストが大幅に圧縮され、その条件の検証が行われる機会が増えるということになります。それが、最終的には品質の底上げに繋がります。
UIのgolden testは、描画結果のスクリーンショットを使って検証しているため、widgetの内部実装には依存していません。そのため、widgetの内部実装を大幅に変えたとしても、テストコードを変える必要はなく、リファクタリング耐性があると言えます。
検証内容を変えない限りはテストコードを固定できるため、その分内部実装は柔軟に変更しやすくなり、結果として変更を早く終えられるようになります。
今回のテストはFlutterのwidget testであり、これは非常に高速です。実装の仕方にもよりますが、今回のような形であれば10件くらいのテストケースも実行は1秒ほどで終わります。
また、Flutterにはhot reloadがありますが、これと比べてもメリットがあります。今回の形では、再現が難しい条件や、テキスト入力などのUIの操作が必要な条件などであっても、確認と修正のサイクルの速度はあまり影響を受けません。
テストの実行速度が速いため、手元でもCI上でも全件の実行が現実的になります。これにより、アプリの大通りでないケースについても、常に検証を行うことができます。
最終的に手動テストが不可欠であることに変わりはありません。なぜなら、今回の形のテストは結合した状態でテストしている訳ではないため、結合に起因した不具合や、使い勝手という観点の検証ができないためです。しかし、それでも自動テストは手動テストの負担を下げたり、稀にしかテストされないマイナーケースも含めた全体の品質の底上げに役立ちます。
例えば、レイアウト崩れを早期発見するgolden testがあれば、レイアウト崩れによる手戻りの頻度は大幅に抑えられ、開発担当者とテスト担当者が手戻り対応に割く時間を抑えることができます。
今回はUIのテストを中心に説明しましたが、アプリを起動せずに開発を進めるにはデータ側のテストも同様に重要です。また、UIに関しても画面遷移のテストや、分析ログのテストなど、まだまだテストすべきものがあります。
これらについては、また別の機会に解説したいと思います。
10Xではソフトウェアエンジニアを募集しています(特にバックエンド)。
今回はモバイルアプリのテストの話を書きましたが、役割の分解のところはバックエンドでのテストにも通ずるものです。こういった考え方で開発をより上手くやっていきたいという方に是非来ていただきたいです。
興味があれば、ぜひ会社紹介をご覧ください！
