10X 開発オフサイトはじめました

10Xの石田(@wapa5pow)です。10Xでは全社でオフサイトを3ヶ月に一回開いています。 全社オフサイトというのはこんな感じで会社のメンバー全員が集まりワイワイして仲良くなってより事業を伸ばしましょうというイベントです。 今回、全社オフサイトとは別にStailerを開発する(コードを書く)メンバーを対象とした開発オフサイトを開きました。

この記事ではなぜ今回新たに開発オフサイトを始めたのかと、どのように準備したかを紹介します。

開発オフサイトを行う事によって解決したかったこと

10Xの作っているチェーンストアECの垂直立ち上げプラットフォームであるStailerの事業が順調に伸びていることもあり開発メンバーも増えています。

上図にあるようにソフトウェアエンジニアは20名ほどいます。創業当時は数名で机を向き合わせて開発していましたがコロナ禍ということもありリモートで開発しています。なかなか直接話せる機会がない中で開発オフサイトを実施することにより以下の目的を立てました。

開発メンバー同士がお互い相談し合ったり疑問を共有しあえる環境だとStailerのような複雑性が高いプロダクトの開発がうまくいきやすい。現在メンバーが増えてきて部署をまたいだ交流がないので横のつながりができにくくこれからもメンバーが増えることを考えると横の繋がりを定期的に保つ仕組みが必要。全体オフサイトとは別に開発オフサイトで以下を達成する。

  • 普段業務で関わらないメンバーとの親交を深める
  • 開発チームとしてStailerの未来をイメージする

実際に開発オフサイトを行うにあたり協力者を募集したらメンバーが集まってくれたので、コンテンツごとに担当を分けて作成することにしました。

チームビルディングで仲良くなって、トークタイムでいままでの成果を共有し、未来を考える会でStailerをより良くする事を考えるという流れを意識しました。

コンテンツ紹介

どのようなコンテンツかは各自担当したメンバーに紹介してもらいます。

チームビルディング (@futabooo担当)

オフサイトコンテンツ1つ目は「チームビルディング」ということで、紙ヒコーキワークショップをやりました!

紙ヒコーキワークショップとは、いくつかのルールのもとで工夫をしながらチーム対抗の紙ヒコーキを飛ばすゲームです。Scrumの基本の流れを体験できるので、研修などでよく行われます。読者の中にも経験したことがある方もいるかも知れません。

全体の流れとしては下記を1セットとして4セットやります。

  • 設計・計画:1分
    • どうやって作るかを設計する
    • いくつ飛ばせるか見積りする
  • 実装・テスト:3分
    • ルールのもと紙ヒコーキを作って飛ばす
  • ふりかえり:2分
    • やってみてわかったことや次にやる時に改善することを話す

ルールは下記です。

  • A4用紙の1/4サイズの紙から1機を作ります
  • 紙ヒコーキの先端は尖っていてはいけません
  • 出来上がった紙ヒコーキは飛行場で試験します
  • 飛行場で飛ばすのに成功した紙ヒコーキの数がスコアです
  • 3m以上飛んだら成功です
  • 1機につき1度しか飛ばせません
  • 1人で連続して折ってはいけません、一度折ったら他の人に渡します
  • スプリント終了時の仕掛品はすべて破棄しなければなりません

4セットやった結果がこちらです。

1セット目(SP1)はどこのチームも実績が0となり、誰もが知ってる紙ヒコーキづくりと言っても最初の見積りの達成確率が低いことが如実にあらわれました。

3セット目(SP3)の実績がどのチームも大幅に向上していますが、これは3セット目だけ3m以上飛んだら成功以外のルールのうち1つを無くすことができるようにした時です。制約(ボトルネック)を取り除くとスピードが上がることを体験してもらいました。

4セット終わった後には床に紙ヒコーキが散乱するほど白熱したワークショップとなりました。

ワークショップの最後にはまとめとしてよい(強い)チームとは何か、なんのためにそんなチームになるのかをメッセージとして残して終わりました。

トークタイム (LT) (@yamarkz担当)

オフサイトコンテンツ2つ目は「トークタイム〜〜 🧑‍🏫」という名目で、メンバーから6本のLTを話してもらいました!

6本のLTは事前に"聞きたい!"という投票を行なって、チーム内で関心の高いトピックと、リードメンバーの独断と偏見 (熱意が高い or 面白そうなテーマ) で選びました。

LTとして8~10分という時間で話してもらう予定でしたが、どのトークも非常にレベルが高く、今度はもう少し長めに時間を取りたいな〜と思っています。そんな素敵なトーク内容で使われた資料を公開します。(※ 一部社内に閉じた話題でもあるため抜粋)


1. マスターインポータを開発する

ishidaさん(@wapa5pow)によるStailerのマスターインポータの話。

膨大な在庫データをいかに効率的に取り込めるように開発するかという切り口で、マスターデータ運用を楽にする工夫を話してもらいました。

データ規模が大きく、そして要件が複雑になればなるほど開発難易度が10xする領域なので、具体的な運用の工夫話が面白かったです。

2. パフォーマンス改善 事始め

kitakさん(@kitak)には直近取り組んでもらっていたパフォーマンス改善の話。

直近Stailerで成果が出た例を取り上げて、何を行なったのか、取り組みをどう進めたのかを話してもらいました。

仮説に対する確からしさを検証から明らかになった事実から証明していく過程が、10Xらしさそのものだなと思いました。

3. 検索改善の弟です.検索改善のすべてをお話しします

metalunkさん(@metalunk)からは検索改善における検索技術の話。

タイトル通りに「すべて」をLTで話すのは無理なのでw 検索とは?という話をしてもらいました。

とにかく話がわかりやすかった。難しそうな内容を平穏に話すのがとても上手い。(※ 本人にも直接感想を伝えてます)

加えて、Good Morning Talkという社内のトーク会でもより詳細検索の話をしてもらいました。

4. 仕様書を10本以上書いて気づいたこと

オフサイトメンバーを代表(@yamarkz)して、直近仕様書を整備した中で気づいたことを振り返った話。

直近は開発で要求された仕様書を17本ほど書き、そこで得られた気づきを振り返って紹介しました。

仕様書システムはまだまだ模索中ですが、チームとしてより良い開発プロセスにしていけたらと思っています。

5. 最近入社してわかったこと、よかったこと、わるかったこと

teshiさん(@teshi)からは最近入社されたメンバーを代表した話。

率直に思ったことや取り組んだことを話してもらいました。

アオダイのアイコンですが座右の名は「お客様に価値を届けるオアダイ」で、自分も何か〇〇 or Die...というテキストを持ちたい。

6. Reliability を各チームが自律的にコントロールできる Platform of Platform 像と組織体制

babarotさん(@b4b4r07)にはTeamとReliabilityについての話。

チームを起点として組織とプロダクトへの取り組みを今後どうしていきたいのかを話してもらいました。

「自分達はこうあるべき」が明瞭に示されていて非常にワクワクしました。


以上がトークタイムでのコンテンツでした!!

皆機会が来るとなれば、気合を入れて準備してくれて非常に良い時間でした。感謝 ✨

未来を考える会 (@operandoOS担当)

オフサイトコンテンツ3つ目は「未来を考える会」というタイトルで、事前に決めたテーマについてディスカッションするコンテンツにしました。

OSTのグラウンド・ルールを利用したディスカッション設計

ディスカッションのテーマ決めや当日の進め方はOST(オープン・スペース・テクノロジー)というワークショップ手法で利用されるグラウンド・ルールを一部取り入れ、メンバーが主体的にディスカッションできる場作りを心がけました。一例としてテーマ間の移動が自由なグラウンド・ルールを取り入れることで、より自身が貢献できるテーマに参加する働きかけを行いました。

OSTについては「人と組織の「アイデア実行力」を高める ― OST(オープン・スペース・テクノロジー)実践ガイド」という本がとても参考になったので、気になる方は読んでみてください。

オフサイトでディスカッションしたテーマ

当日ディスカッションするテーマの選定は、事前に各自が議論したいことをNotoinに記載してもらい、メンバーの「議論したい!」投票数が多いテーマから選びました。

オフサイト当日 未来を考える会で実際にディスカッションされたテーマは以下になります。

  • ドキュメントから実装までをスムーズな流れでいけるようにする方法を考える
  • 仕様書システムの未来を考える
  • Stailerのセキュリティ機能の未来を考える
  • システム全体に対してどういう構造でチームがオーナーシップを持って開発・運用をするか

ちなみに、「テーマ同士をマージしてディスカッションしてもOK」というグラウンド・ルールを作ったことで、「ドキュメントから実装までをスムーズな流れでいけるようにする方法を考える」と「仕様書システムの未来を考える」は一緒のグループでディスカッションすることになりました。

ディスカッションは3つのグループに分かれてホワイトボードや付箋などを使用しながら行われました。ディスカッション時間は45分と短くなってしまいましたが、各テーマとてもいい議論ができました。

ディスカッションが終わったら最後 各テーマごとに議論したことのまとめ + Next Actionをまとめてもらいました。オフサイトだけでディスカッションが止まってしまうともったいないので「まとめたものを利用して継続的にディスカッションを行ったり、実際の業務に活かしてください!」という締めの言葉で未来を考える会は終了しました。

やってみて

再度石田(@wapa5pow)です。

メンバーと久しぶりに一緒にわいわいできてやって非常によかったと感じています。

トークタイム (LT) や未来を考える会はコンテンツが充実しすぎていて、もっとゆっくり聞きたいとの意見がありました。別途切り出して開発共有会として8月から開始する予定です。そこでは未来の組織のあり方、QAのあり方、開発のあり方など未来はこうあるべきだなどの未来図の話から、機能の実装の話などゆったりコンテンツが聞ける会にできたらなと思っています。

これから開発オフサイト始めるために

以下に今回学んだ、これから開発オフサイトを始めたい人のための情報を載せておきます。

  • 会社外でオフサイトをやる場合は場所を確保するためinstabaseを利用しました。
  • 事前の準備時間と、終了時間がオーバーするかもしれないので前後余裕をもって場所を予約したほうがいいです。
  • オフサイト場所にお菓子やお水をもっていきました。(メンバーからはちょっと高いお菓子があるとテンションがあがるとの報告がありました)。ゴミは持ち帰る必要があったので飲料は各自もってきてもらいお水は緊急時のために用意しておきました。
  • マスタスライドを用意してそこにコンテンツを載せてプロジェクタに1つのPCでつなぐと進行しやすいです。そのPCでMeetで画面録画しながら録画しておくとこれなかった人にもコンテンツを共有できます。
  • 部屋は広いほうがいいです。人数ぴったりよりもやや広い部屋を用意します。
  • 集合写真など思い出の写真を取ったほうがいいです。(オフサイトが終わってから写真を撮っていないことに気づきましたorz..)
  • グループで雑談できる余白があったほうがいいので休憩時間も適度にとったほうがいいです。
  • 1人で企画するより協力してくれるメンバーを募って行ったのでとてもやりやすかったです。コンテンツを考えるという気の重い作業を分担できそれぞれのコンテンツがより高いクオリティになりました。

それではよい開発オフサイトを〜。

10X の検索を 10x したい パートII

今 Q もお疲れさまでした!10X の @metalunk です.

3ヶ月前に 10X の検索を 10x したい というブログを書きました.その記事にあるとおり,1-3月で検索インフラの改善を実施し,検索速度 10x, インフラコスト 80% 削減という成果をあげました.そして,直近の3ヶ月では検索精度の改善に取り組みました.この記事では今 Q にリリースした機能と,それぞれの効果を説明します.

長い記事になったので飛ばし飛ばし読んでください.

  • どんな Q だったか
    • KPI の変化
      • Zero match rate
      • Conversion rate
  • リリースした機能
    • 検索キーワードサジェスト
      • システム概要
      • 評価
  • カテゴリフィルタ
  • 並び順の改善
    • 評価
  • bigram
    • 解説
    • 評価
  • シノニム辞書を Search time に展開
    • 解説
  • イベントログからシノニムルールの生成
    • 解説
  • 改善の背景
    • KPI Dashboard, クエリグループ Dashboard の準備
    • 検索結果を local で試せる状態にした
  • おわりに

どんな Q だったか

  • 検索インフラの大きな問題が前 Q で解決し,精度改善に取り組み始めた
  • 精度改善の準備をし,新しい検索エンジニアが入ってきたときに,すぐに精度改善に取り組める状態になった
  • 作戦リストを作り,インパクトの大きいものから順番に取り組むことで検索精度が着実に改善した

KPI の変化

検索の KPI は Zero match rate と Conversion rate の二つです.

Zero match rate

Zero match rate は,全検索のうち結果が0件であった検索の割合です.ゼロマッチを減らすには検索精度を改善することと,品揃えを拡充すること(セレクション)の両輪が重要です.

3ヶ月前と比較し,18.8% のゼロマッチを削減することができました!👏👏👏

3ヶ月間の Zero match rate の変化

Conversion rate

Conversion rate は全検索のうちカート追加が発生した検索の割合です.ネットスーパーの特性上,商品詳細ページに行かずに一覧ページから直接カート追加することが多いため,CTR (Click through rate) ではなくカート追加の Conversion rate を採用しています.

3ヶ月前と比較し 2.3% 改善しました.Zero match rate を下げる施策を優先したため,大幅な改善はできませんでした.

続きを読む

ソフトウェアエンジニアの選考プロセスをアップデートしました

CTOのishkawaです。

10Xでは全職種の選考プロセスにトライアルを設定していましたが、ソフトウェアエンジニアに関してはトライアルによる選考を終了し、新たな選考プロセスを導入することにしました。本稿では、創業以来続けてきたトライアルをやめて、選考プロセスをアップデートしていくことに決めた背景を紹介します。

トライアルとは

トライアルとは実際に10Xの仕事に取り組んでもらいます。大まかな流れは次の通りです。

  1. 会社の情報をインプットし、取り組むイシューの候補を考える。
  2. 社員へのヒアリングやディスカッションを通じて、取り組むイシューを決める。
  3. イシューの解決に向けたアクションプランを策定し、可能な範囲で進める。
  4. 成果を発表する。

トライアルは1日や数週間といった短期間で実施します。

良かった点

会社と候補者の双方から様々な面のフィットが確認できるのが、トライアルの良いところでした。例えば、候補者の方が会社に入った時に成果を出していけるか、仕事をする上で大事にする価値観は合っているか、事業や開発の機会が候補者のキャリアの方向性と合っているか、といった観点の確認ができます。

また、トライアルは候補者の方に会社のことを知っていただく機会としても機能していました。トライアルに取り組む中で事業の理解が進んだり、解くべきイシューが見えてきたりして、入社後に自分がどのように活躍できるのかイメージしていただけるようでした。

課題となった点

素晴らしく良い点もあったトライアルですが、課題もありました。

まず、最大の課題となったのは候補者の方に大きな負担がかかる点です。多くの候補者の方には本業や他社の選考があり、10Xのトライアルにまとまった時間を割くのは簡単なことではありません。この負担により、選考を辞退されることもありました。10Xに強い関心を持って転職活動のエネルギーを10Xに集中させてくれるという嬉しいケースもありましたが、候補者層が選考時にそのような判断ができる人に限定されてしまうとのは、やはり大きな課題でした。

他の課題の1つには、トライアルの評価の再現性の確保が難しい点がありました。トライアルのお題は「今の会社やプロダクトやシステムの状況をインプットし、最も大きく成果を出せるイシューを発見して解決に向けた動きをしてほしい」という抽象度の高いものでした。課題がオープンな分、候補者の方が力を強く発揮できるケースもあれば、限られた時間の中で上手く課題を見つけられないケースもありました。また、事業の進捗に伴って、そもそもどんなレバーが存在するのか、どのレバーを引くとどのような影響があるのか、理解が難しくなってきていた側面もありました。

その他、トライアルで成果を出すには問題発見と解決のスキルが重視され、技術的なスキルを見づらいなどの課題もありました。これは単にすべてをトライアルでやろうとするから課題になるのであり、他に技術的スキルを確認しやすいプロセスがあれば良さそうでした。

アップデートの方針

これまでに挙げてきた課題の解決のため、選考プロセスをアップデートすることに決めました。アップデートの大方針は「トライアルのエッセンスを残しながら課題を解決する」でした。検討の結果、導入されたのはコーディング試験とディスカッション面接です。選考プロセスの内容はポジションによって若干異なるのですが、詳細は下記URLにまとまっています。

10X ソフトウェアエンジニア選考ガイド

コーディング試験に関しては、当初は個人的にはそこまで必要かな?という印象だったのですが、純粋にコーディングスキルを再現性高く確認できることで、候補者の方も評価者もコーディングに関しては自信を持って次のプロセスに進めるというメリットがありました。

ディスカッション面接はややトライアルの側面を引き継いでいるものなのですが、時間は1時間に限定されおり、取り組む課題も実務のサブセットのような粒度に抑えられています。こちらは問題発見やコラボレーションの力が再現性高く確認できるものとなっています。

選考プロセスの今後

今回は選考プロセスに課題を感じて、アップデートをかけました。アップデートによる効果は実感できているものの、新たな課題が見つかっているのも事実です。アップデート後の選考プロセスもまだまだ完璧ではありませんし、課題に真面目に向き合い続け、更に良いものにしていこうと考えています。

Podcastの公開収録で細かく話します!

今回の選考プロセスのアップデートについて、Podcastの公開収録で細かく話す予定です。ここに書き切れなかったことも話しますし、質問にも答えたいと思いますので、興味があれば是非ご参加ください。

7月7日(木)の12:00-13:00に実施予定で、下記から参加登録できます。

10x.connpass.com

ランチのお供に是非!

社内で「Data Vault勉強会」を開催しました

はじめに

Growth&SuccessでStailerのデータウェアハウスの開発をしています@kazk1018です。この記事では、先日社内で開催した「Data Vault勉強会」を基にData Vaultについて簡単に紹介するとともに、10Xでどのように利用しているかを紹介したいと思います!

Data Vaultについて

「Data Vault」はエンタープライズデータウェアハウス(EDW)を構築するためのモデリング手法です。最初に提案されたのは2000年なので20年以上の歴史があり、2013年には「Data Vault 2.0」が提案され、非構造データへの対応やより実践的なプラクティスなどが追加されました。*1

Data Vaultではデータウェアハウスを構築する全体の流れから、各レイヤーで用いるスキーマの設計まで幅広い範囲のアプローチや手法が提案されています。中でもHub、Link、Satelliteという3つのデータモデルから構成されるRaw VaultやBusiness Vaultは非常に柔軟性の高い設計を実現させています。

ここではData Vaultの詳細については割愛し、次にData Vaultの特徴を説明した後、10Xでどのように利用しているかについて紹介したいと思います。簡単な概要を知りたいという方は以下の資料を参考にしてください。

dbtとBigQueryで始めるData Vault入門

Data Vaultの特徴

Data Vaultには次のような利点があると言われています。

  • Agileなデータウェアハウスの構築が可能である
  • Scalabilityが高い
  • 複数のデータソースに対応することが簡単に行える
  • 生データから履歴ありで保存されていること
  • 監査性がある

特にこれまでのデータウェアハウスのモデリング手法である3NFやDimensional Modeling*2と比べて、柔軟性が高く、両者の良いところをうまく取り入れているという印象があります。Dimensional ModelingはData Vaultを理解する上でも、実際に利用する上でも有益な知識が多いので、先に学んでおくことをおすすめします。

上記で紹介した多くの利点もありますが、以下のような欠点もあります。

  • 従来のモデリング手法よりもJOINが多い
  • Data Vaultのスキーマは分析に向いていない

特に二つ目については、Data Vaultを紹介している本やWebページにはDimensional Modelingで利用されるFactやDimensionのテーブルを最終的に作成しているものがほとんどです。10XでもデータウェアハウスからFactやDimensionを作成して利用者に公開する形を取っています。

Why Data Vault?

Stailerのデータウェアハウスを構築するに当たって特に課題となりそうだった点は次の通りです。

  • ビジネスの変化や検証を進めるためにビジネスロジックやシステムの仕様変更に対してどのように対応するか

    我々はスタートアップ企業であり、Stailerもこれから多方面に事業を拡大していく中でデータウェアハウスにも多くの変更が求められることが想定されます。Data Vaultの特徴であるAgileにデータウェアハウスの構築を進められる、かつScalabilityがあることはこのような状況に非常に向いているといえます。

  • 外部のシステムから受け取ったデータをダッシュボードなどに利用する際にどのようにして追加するか

    小売事業者側のシステムはサプライチェーン全体を複数のシステムで運用している傾向にあり、事業者毎にも異なるシステムを利用しているため、複数のソースシステムからのデータの取り込みを想定する必要がありました。一般的に既存のデータウェアハウスに新たなデータソースを追加することは既存のデータに対しても変更を加える必要が出てしまうことが問題となりますが、Data Vaultではこのような処理にも柔軟に対応することできます。

dbtとBigQueryによる実装

10XではデータウェアハウスとしてBigQueryを利用しており、データレイクからデータマートのトランスフォーメーションをdbtを用いて構築しています。詳しい内容は以下のスライドやリンクを参考にしてください。

スライドへのリンク

また、Data Vaultを開発する上での特徴として、スキーマの仕様が標準化されており、開発時にテンプレートSQLを用いることで効率化できるという点があります。この特徴をdbtにうまく取り込んでいるのがdbtvaultというdbtのpackageです。このツールを用いることでHub、Link、SatelliteやBusiness Vaultのテーブルを簡単に作成することが可能になります。

Data Vault勉強会

Data Vaultの欠点として、多くの概念が体系的にまとまっている分、開発や利用する際に多くの知識を学ぶ必要があるのですが、日本語の情報が不足していることは否めません。そこで少しでもData Vaultについて社内での理解を深めてもらうために勉強会を開催しました。データウェアハウスという本来データの利用者が触れる機会の少ない部分であるにも関わらず、日頃データ分析を行っている人からアプリ開発をしているエンジニア、BizDevの方まで多くの方に参加いただけました。

さいごに

この記事では、DWHを構築するモデリング手法である「Data Vault」を紹介し、データの民主化として社内向けに勉強会を開催した話を書きました。

今回紹介した「Data Vault」を利用したDWHの構築後は、データ利用者向けのデータマートを構築したり、データカタログを整備したり、更に多くのデータを取り込めるようなデータパイプラインの構築を進める予定です。

最後に10Xではデータウェアハウスを構築したり、データの民主化を促進するアナリティクスエンジニアを募集しています!

アナリティクスエンジニア

ご興味のある方はぜひご応募お待ちしております!

「1人目SETとして入社して2ヶ月の間におこなったこと」(増刊号)

こんにちは。

入社後初のブログになります。 10X SETのtarappoです。

6/16(木)にQA Test Talk Vol.1を主催しました。

この勉強会で「1人目SETとして入社して2か月の間におこなったこと」というタイトルで登壇しました。

そのときの資料は次になります。

この資料では書ききれなかったことも多いので、本記事では上記の資料を補足しながら、入社してから2か月の間におこなったことをまとめていきます。

入社前におこなっていたこと

入社前に業務委託という形で関わっていました。 その間におこなっていたことについては次のブログ記事に書いています。

その間におこなっていたこととしては、 かんたんに説明すると次のように目指すゴールを考えて、それに向かって進めていけるように整えだしたというものです。

  • 「10XにおけるQAはどのような姿を目指すか」について考えて文章化
  • その姿を元に「どのようなメンバーが必要か」を考えて採用活動
    • JDを更新したり、カジュアル面談をいろいろとおこないました

目指す姿に向かうには、今がどういった状態なのかというのが分からないと進むことはむずかしいです。 そこで、今後新たなメンバーが入ってきたときに動きやすくするためにも、現状を把握しやすくなるように次を進めだしていました。

  • (1)データの可視化と分析のための準備
  • (2)テストのプロセスの把握と改善に向けた準備

次に入社後の現在のQAチーム体制や、2か月の間におこなってことについて説明をしていきます。

現在の10XのQAチーム体制

入社してから2か月たった現在(2022/06)における10XのQAチーム体制は次図のとおりです。

2022/06時点での10XのQAチーム体制

私が入社する前から第三者検証会社の方にプロダクトの検証を担当してもらっています。 そこから、4月にSETである私が入社して6月に1人目のQAエンジニアが入社しました。

職種としては、SETやQAエンジニアとして入社しています。 しかし、現時点では「今、10XのQAはなにをするべきか」を考えた上で、その中で取り組むべき複数のイシューからプライオリティを考えた上でタスクを進めています。

そのためSETが主にとりくむと想像されるような「自動テストの実装」や「CI/CDサービス周りの改善」といったものはこの2か月の間ではおこなっていません。

上記の内容については一定現在の状況をチェックはした上で、それを「今」おこなうべきかを考えて他のイシューのプライオリティが高いと判断しています。

そこで、どのようなイシューがあるのか、それについてこの2か月の間にどのように取り組んだのかについて次に説明をしていきます。

まずなにをおこなったか

まず「10XにおけるQAの未来像」にむかうにあたってなにをするべきかを考えていきました。

そこで「現状把握」のために次を進めていきました。

  • 現状のドキュメントを元にした関係者へのヒアリング
    • このドキュメントが実体とあっているのかどうかなど
  • ヒアリング結果を元にしてドキュメントの更新

この「現状把握」を進めていく中で「曖昧になっていること」や「おこなったほうがよいがおこなえていないこと」などいろいろな課題が見つかりました。 これらの課題をリスト化するだけでなく、入社前におこなっていた「データの可視化と分析」と「テストのプロセスの把握と改善」の残タスクにおいても課題としてリストに入れました。

また、上記とは別に社内でふりかえりの際などにまとめられていたQA周りに関する課題についてのドキュメントがいくつかありました。 そこで、これらの課題をすべてマージした一覧を用意して重複しているものや解決しているものなどは削除し整理しました。

この一覧をグルーピングし、どういった傾向の課題が多いかといった判断をしていきました。 そして、この課題の中から今期(4月〜6月)におこなうことして次をすすめることに決めました。

  • 検証プロセス

    • (1)検証プロセスの改善
    • (2)不具合分析の実施
  • 検証内容

    • (3)検証コスト最適化のためのテスタビリティ向上
    • (4)検証にかかっているコストの可視化

QAというのはなにをおこなうものなのか、またQAチームはなにをおこなおうと思っているのかというのはなかなか分かってもらえないことがあります。 そこで、次も進めていくこととしました。

  • (5)QAチームの認知度の向上

また、上記以外にも今期の取り組む内容として次も設定しています。 これらについては登壇時点ではあまり進められていなかったため、登壇時には特に紹介をしませんでした*1

  • (6)ソフトウェアテストの全社へのナレッジ向上
  • (7)本番障害に関する情報の活用

この7つの取り組みについては(1)が終わったら(3)をやるといった関係ではなく、内容によっては連携しているものもあります。 そのため並行しながら進めていきました。

おこなうのを決めた際の方針

上述した今期の取り組みをおこなうと決めた理由としては、次が前提にあります。

限られた時間の中で本当に大事なことにフォーカスしていくために、そのフォーカスすべきものがなにかを定量的に分かるようにする

そこで、次をおこなえるようにするというのがありました。

  • 現状をわかりやすくする(計測と可視化)
    • 例)
      • 検証時にみつかった不具合の傾向
      • 検証にかかっているコスト
  • 得られた情報から改善サイクルをまわせるようにする

実際におこなった次のことについて順に説明していきます。

  • 検証プロセス
  • 検証内容
  • QAチームの認知度の向上

検証プロセスに関すること

検証プロセスに関することとしては次の2点をすすめました。

  • 検証プロセスの改善
  • 不具合分析の実施

これらをすすめる上で、検証プロセスがどのように変化していったかについて次に説明をしていきます。 プロセスは次のように入社から2か月の間に4回変化していっています。

  • (1)入社前
  • (2)入社初期
  • (3)入社1〜2か月後
  • (4)いま

これは決まっていなかったことを決めていったり、見えてなかったことを見えるようにしていった感じになります。

(1)入社前

Phase1

  • 利用ツール:GitHub Project
  • Issue Templateを使って次のIssueを作成
    • QAチケット
      • QAチケットは検証を依頼する人が起票をし、検証対象の情報(仕様へのリンクやリリース予定日など)が記載されたもの
    • バグチケット

この時点での課題として次のようなものがありました(これらは課題の一部です)。

  • QAチケット関係
    • 一部において記載する情報が不足している
    • 一部において起票タイミングが遅い
    • closeの条件が「全テストケースの実施完了」になっており、その時点でバグチケットがまだ残っていることもある
  • バグチケット関係
    • 不具合分析をするには記載されている情報が不足している
    • 情報の多くは本文にかかれているため、今の形のまま分析しようとする場合はテンプレート化や独自フィールドの追加など対応がいろいろと必要になる
    • 全体的な不具合の傾向が分かりづらい
  • QAチームのスケジュールやタスクの進捗がよくわからない

上記の課題はGitHub APIを使ったりして解決できるものはありますし、プロセスを整えることで一定解決できるものもあります。

これらの対応について考えている際に、他チームがJIRAを利用する流れがちょうどありました。 JIRAを活用することで、上記の課題を一定解決できることが分かっていたため、JIRAへの移行をおこなうこととしました。

(2)入社初期

Phase2

JIRAの移行にあたっては、次を実施しました。

  • 入力内容の整備
    • バグチケットの分析をできるように入力内容のフォーマット整備
    • どのような値をいれるべきかをQAチケット、バグチケットともに整備しドキュメント化
  • 利用の仕方の整備
    • バグチケットのフロー決めとワークフローの設定
    • QAチケットのフロー決めとワークフローの設定
      • QAチケットのサブタスクとしてQAチームのタスクを登録
  • 可視化
    • タスクの状態を見えるようにしたQAチーム用のKANBANの用意
    • 現在のバグチケットの状況が分かるJIRAダッシュボードの用意

またプロセス面として図の「青色」の箇所として次を追加しています。

  • QAチケットの完了判断のステップを追加
    • バグチケットが残っている場合、そのバグが残っていて問題ないかをQAチームが判断した上で関係者と方針について合意する
  • 一部において「QA必要」「QA不要」の判断をしてPRにラベルを追加
    • QA不要の際のみラベルに追加し、あとからチェックできるようにした

上記の内容はすべてドキュメント化した上で、関係者に共有しています。

JIRAへの移行に伴いデータがたまれば、「不具合分析」ができるようになりました。 データをためるには一定の期間が必要ということもあり、このJIRA移行は実施できるタイミングになってすぐにおこなっていきました*2

(3)入社1〜2か月後

Phase3

JIRAへの移行をおこなってから、1か月ちょっとたったタイミングである程度のバグチケットが溜まりました。 そこで、不具合分析を実施しました。

不具合分析では、次を実施しました。

  • 全バグチケットの確認
    • JIRAにはGitHubのPRへのリンクもあるため(JIRAのプラグインの機能)、それを活用しコードのチェックもおこないました
  • 今後の不具合分析で追加して取得すべきデータがあるかの確認
    • 既存バグが一定ありそうだということでそのためのフィールドをバグチケットに追加

結果として、今回の不具合分析では次の3種類の不具合が全体の約65%と多いことがわかりました。

  • (1)仕様に関するもの
  • (2)コーディングミス
  • (3)他のバグチケットとの重複

(2)においてはユニットテストで担保できるものはあまりなく、UIテストをおこなえばみつかったかもしれないというものが一定ある程度でした。 そこでまずは(1)と(3)に対しての改善施策を実施することとしました。

(3)においては現状こういうことが起きているという共有とJIRAのダッシュボードを改善して、よりバグチケットを見やすくしました。

(1)においては、仕様策定段階からQAチームが関われるようにする方向で関係者と相談した上で進めていくこととしました。 これに関しては、必要性を社内のメンバーに伝えた上で即座に動けているところが弊社の強みの1つだなとも思っています。

(4)いま

Phase4

(3)で説明したように、早い段階からQAチームが仕様レビューに加わることをためしています。 かかわったレビューにおいて、現時点でもいくつかの仕様考慮漏れを見つけています。

まだ未実施ですが、上図の緑色にある「ふりかえり」も実施する予定になっています。 これにおいては、すべてのQAチケットについておこなうのではなく、バグ起票が多いなど特定のケースにおいてのみおこなう予定です。

このようにプロセス面を改善しつつ、検証内容についても改善するためにしてきたことについて次に説明をしていきます。

検証内容に関すること

検証内容に関することとしては次の2点をすすめました。

  • 検証コスト最適化のためのテスタビリティ向上
  • 検証にかかっているコストの可視化

これらについて説明をする前に、現状おこなっている検証について次にかんたんに説明をします。

現状おこなっている検証

今はリリース前に「システムテスト」を手動でおこなっています。

なお、現状把握のために現時点でおこなっているシステムテストの内容などについては関係者にヒアリングをした上でドキュメントにまとめていきました。

リリースされるものとしては、プラットフォームという特性もあり「機能追加・改修」と「新しいパートナーのローンチ」というものがあります。 これらはそれぞれおこなうべき検証の内容も異なってきます。 これについては次のブログにあるようにすでに一定まとめてくれていたのがありました。

現状をまとめていく中で、次のような課題があることもわかっています(これらは一部です)。

  • (1)利用している検証端末が実ユーザーの利用実態を考慮していない
  • (2)システムテスト以外のテストがおこなえていない

(1)においては、整備を進めているところです。

(2)においては現時点の状況では他のテストをおこなえる余裕がないため、手が出せていないというのがあります。 しかし、今後いろいろとおこなっていく必要があるため、どのようなテストが必要であるかについてまとめているところです。 また、他のテストもおこなえるようにするためについて後述するようなことを進めだしています。

次にこの2か月の間にすすめた2点について説明をしていきます。

検証コスト最適化のためのテスタビリティ向上

上述したように現時点ではリリース前の「システムテスト」をおこなっていますが、それ以外はあまりおこなえていない状況です。

テスト実行時間を減らすための対策として「とりあえずE2Eテストとよばれるような自動テストを導入して手動テストを減らす」というアプローチは現時点ではとっていません。

E2Eテストを導入するかにあたっては、そもそもとして次を事前に考えました。

  • 現在の手動テストで担保していることがE2Eテストで担保可能かどうか
  • 導入した場合において自動テストのメンテナンスコストがどの程度になりえるか

これについては、最初に調査をした時点ではE2Eテストを導入をする「だけ」のコストは低いが、運用を続けるコストを払うことは厳しいと判断しています*3。 ただし、将来的にはE2Eテスト(も含めたさまざまな自動テスト)も適切に利用できることは必要と認識しており、そのための準備は進めています。

まずは、今のプロダクトにおいてそもそも「検証しづらい箇所」としてどういったものがあるかというのを把握し、リストアップすることとしました。 たとえば、次のような課題があります(これは一部です)。

  • 一定時間をまたないと次のステップに進めないケースがある
  • QAチームでは実施できない確認項目がある
  • 開発環境 = 検証環境であり環境が独立して存在していない
    • QAチーム以外もさわるためデータが想定外になっていることがある
    • 開発などほかのメンバーの作業とのバッティングが発生する

リストアップしたものを対応していくことで、プロダクトの検証のしやすさを向上させる方向で進めています。 これは「手動テスト」に対する効果だけでなく、E2Eテストを運用する際にもプラスになります。

検証にかかっているコストの可視化

検証にかけている工数を可視化することをおこないました。 可視化できるようにすることで次ができるようになります。

  • なにかしらの施策によっての効果が見えやすい
  • どこに時間がかかっているかがわかりやすい

これを実現するために、次をおこないました。

  • QAチームのタスクはQAチケットのサブタスクとして登録
    • このサブタスクには見積もり時間と実施時間を入力

データは溜まってきているため、現在はこのチケットにある情報を可視化する準備をすすめています。

QAチームの認知度向上

最後に「QAチームの認知度向上」としてなにをおこなっているかについて説明をします。 QAというのはどういったものなのか、そもそもQAに関わる職種の方がどういったことをするかというのは把握されていないケースはよくあります。

入社後に行なったアンケートや、私が今行っている全社員の方との1on1により分かったこととして

  • QAチームと関わったことがない人がいる
  • 前職含めQAチームと一緒に仕事をしたことがない人がいる
  • QAチームがおこなっていることを知らない人がいる

そこから、まずは次の2点を実施しています。

  • (1)QA週報をNotionに記載
    • 毎週金曜に社内の#generalチャンネルに投下
  • (2)全社員との1on1(中)
    • まずは私を認知してもらう

これにより、最近ではいろいろと相談も増えてきています。 また、これらをおこなうことで次につなげることもできると考えています。

-(6)ソフトウェアテストの全社へのナレッジ向上

おわりに

上述したようなことをこの2か月の間におこなってきました。 しかし「10XにおけるQAの未来像」に向けて考えるとまだまだやるべきことは多いです。

10XのプロダクトであるStailerというプラットフォームの品質を育てていくのは非常にむずかしく、やりがいのあることだと思います。

ぜひとも、10XにおけるQAの未来像に向けて一緒に進んでくれる仲間を募集しています。

興味のある方は是非次のJDから応募してくれると嬉しいです。

また、実際に話してみたいという方は是非次からお願いします。

みなさまの応募をお待ちしています!

*1:登壇したときから少したった今はこれらについても一定進められている状態です

*2:入社後、すぐにすすめたタスクです

*3:なお現時点ではサーバサイドはテストコードが一定あるためフォーカスすべきはクライアントサイドのほうといえます

E-Groceryにおけるカード決済処理の難しさと設計戦略

はじめに

こんにちは!yamakazu (@yamarkz) です。プロダクトブログへの登場は昨年ぶりになりました。

さて、6月は欧州サッカーのシーズンオフになりますが、対してインターナショナルマッチ(国際Aマッチ)が行われる月なので、代表ファンとしてはワイワイ!な月です。今年は冬のW杯も楽しみですね。

という趣味の小話は最初だけにして、今回はStailerで向き合っているカード決済の難しさと、その難しさに対応するために選択した設計戦略を紹介していこうと思います。

今10Xが賭けているE-Groceryという領域はまだまだニッチで、開発知見がほとんど出回っていないのが現状です。決済に関しては海外含めてGoogle検索でもほとんど確認できませんでした。(ex: instacart, Target)

本記事が、E-Groceryの様な複雑なドメインで決済処理を実装する際の参考になれれば嬉しいです。

なぜ、E-Groceryの決済は難しいのか

早速結論から述べると、E-Groceryの決済が難しい理由は、サービス体験の品質として譲れない機能性を担保するために、不確実性を受け入れなければいけないからです。

これはドメインの特徴として、機能性と不確実性がトレードオフという関係性にあり。片方を取ったら片方を捨てる。機能性を追求するなら、ソフトウェアは不確実で複雑な要件に応えるということです。

このトレードオフは一般的な対比でもあるかもしれませんが、E-Groceryにおいてはその特徴が顕著に現れるものであることを、ここで明言しておきます。

多種多様な商品のまとめ買い体験を提供する

E-Groceryは多種多様な商品を一度にまとめて注文し、注文後の変更余地を残しながら最終的な商品の有無を確定、準備できた商品をお客様に届けて初めて価値提供できるものです。

商品をネットで買って自宅で受け取るという意味ではECと同じですが、その過程が特殊であるため、意図的にE-Grocery (ex: ネットスーパー, ネットドラッグストア) という表現を選択しています。ECという概念の部分集合がE-Groceryというイメージです。Quick Commerceと対比されたりもしますが、これもまた別の部分集合です。

特殊なドメインであることを念頭に置いて、その過程で何が起きるのか、起きた場合に決済周辺ではどういった対応を行うのかをStailerを題材に整理していきます。

前提

  1. Stailerは決済代行業者と提携し、決済処理を委譲しています
  2. Stailerは複数の決済代行業者と連携しています
  3. Stailerは2022/06時点でモノリシックアーキテクチャを選択しています
  4. 一般的なオーソリ(与信)やキャプチャー(売上請求)といった決済手順に則ります

注文過程に存在する不確実性の整理

注文過程と不確実性の整理

Stailerの注文過程とそこで起きうるイベント(= 不確実性)を簡易的な図にまとめると↑になります。各イベントシーンで提供される機能はどういった価値があるのか。その裏側で必要となる決済対応が何なのかを1つずつ取り上げます。

決済確定までの時差

まず最も特徴的なのが時差です。

E-Groceryのサービスは確定までの時間が長く、またその過程で生まれる不確実性も多いです。

注文から決済確定までに時差があること自体は実は一般的で、Amazonや他のECでも一定時間を経て決済確定を行なっていたりします。

この時差を設ける理由の大半が、最終的な物理在庫の確定と配達業務完了を最終的な決済確定タイミングとして、注文後の”もしも”の在庫準備不可や配達不備による例外に対応できる様にするためです。(参考)

Stailerでもそういった側面で時差を設けたりしていますが、それ以上に多くの理由が存在します。それが以下で取り上げる機能性を担保するためです。

機能性を担保するために時差を生み出していますが、これによりシステム観点では都度発生する変化に対応し、決済代行側とのデータ整合性を保つことが求められます。

決済では、

  • 決済ではオーソリを取ってから、キャプチャーを取るまでに時間差を設ける
  • 注文作成の過程ではキャプチャーを取らない
  • オーソリ額は変わる可能性があり、キャプチャーはお客様の手元に商品が届けられたことの確実性が高い確率で証明できる状況で実施する

注文変更による金額変動

締め切りまで注文変更ができる

Stailerには注文変更が機能として存在します。

現代のECはAmazonに代表されるように1タップで注文、即配達という世界から考えると ”注文を変更する” という感覚自体が異質に感じるかもしれません。

注文作成後、指定時間までであれば何度も注文内容を変更でき、「やっぱり追加して買いたい」や「家にあったからやっぱり買うのやめよう」といった「やっぱり」な購買体験を提供します。これは1度の注文で多量の商品を扱うことや、その大半が食料品であるために過不足が調整しやすくあって欲しいという要望からです。

実店舗でも商品をカゴから売り場に戻す行為は推奨されていませんが、禁止されていません。

決済では、

  • 決済では注文変更が起きた場合、オーソリ(与信)を取り直す
  • ただし、内容が変わっても支払い金額が変わらない場合は、取り直さない
  • オーソリが何らかの理由で取れなかった場合、注文変更自体を取り消す

配達/受け取り日時変更による金額変動

配達/受け取り日時変更によって金額が変わる例

Stailerには配達と受け取り日時を選択する機能が存在します。

いつでも自由に届く/受け取れるわけではなく、一定の時間制約が設けられています。これは扱う商品が生鮮食品が中心で時間管理がシビアであることが主な理由です。

注文作成後でも指定時間までであれば何度も希望日時に変えることができ、「やっぱり遅い時間に受け取りたい」や「やっぱり次の日の午前中でいいや」という、これまた「やっぱり」な買い方を提供します。

日時変更によって商品金額が変わるケースがあります。時間で金額が変わるの…??? と思われる方もいるかもしれません。

ネット上の食料雑貨店といえど、実店舗と運営自体は同じであることがほとんどなので、セール価格も店舗と同じサイクルで反映されます

例えば、4/15にセールで148円だった商品が4/16には178円になるといったことが起こります。その際に支払い金額が変わります。

決済では、

  • 決済では配達/受け取り日時変更が起きた場合、オーソリ(与信)を取り直す
  • ただし、日時を変更しても金額が変わらない場合は、取り直さない
  • オーソリが何らかの理由で取れなかった場合、日時変更自体を取り消す

注文のキャンセル

指定時間まで注文のキャンセルが可能

Stailerでは注文後の変更可能な時間までであれば、キャンセルすることができます。

ECでキャンセルした経験がある方は少ないのではないでしょうか。一般的な感覚ではECは注文完了後にキャンセル余地を残していないケースが多いです。

E-Groceryならではの1度に注文する商品の多さから調整しやすくする配慮や、受け取り時間の指定という制約に対する代替としての配慮である意図が強いです。

決済では、

  • 決済では注文キャンセルが起きた場合、オーソリを取り消す
  • オーソリはお客様の決済利用可能枠を一時的に抑えることであり、キャンセルしない場合お客様の決済利用可能枠を圧迫してしまう

品切れによる金額変動

品切れの発生により注文金額が変動する

Stailerには品切れという概念があります。言葉の通り注文自体は受け付けたが、実際には商品を準備できなかったということです。

これはECとしてはかなり特殊な不確実性で、ほとんど発生し得ないと考えられていますが、E-Groceryという領域に絞るとその遭遇頻度は一般ECよりも体感で10xほどになります。

その理由は店舗型に限ってですが、実店舗と物理在庫を共有しているため、時間帯やお客様の購買頻度によっては先に売り場から商品がなくなってしまうからです。

つまりは在庫数管理はしているものの、それ自体が購入を確実に補償するものではないのです。もちろんそうではなく、E-Grocery専用の在庫管理ができれば理想ですが、それでは現状は採算性が合わない、確実に補償するオペレーションを組みきれていないというのが現状です。

品切れになった商品はキャンセルと同等の扱いで注文内容から商品単体で取り消されます。

決済では、

  • 決済では品切れが起きた場合、オーソリを取り直さない
  • 品切れは金額が下振れる現象であり、与信枠が不足する現象ではないから

代替品選択による金額変動

希望する方に代替品を提供する

先の品切れへの補填として、代替品を選択して提供することがあります。

例えば、牛乳Aが売り切れていた場合、牛乳Bを選択して届けるということです。これは実店舗でも行われる行為で、いつも買ってるアレがなかった時に、その代わりを選んで購入すると思います。これをStailerでは代替品選択という機能で実現されています。

品切れ商品に対して代替品が選択されても、お客さまへの支払い金額は下振れることはありますが、上振れることはありません。150円の商品が品切れにになり、170円の商品を代替品として選んだ場合、150円の支払いのまま決済に進みます。これは商品の準備ができなかったことがお客様都合の問題ではなく、店舗の問題だからです。

決済では、

  • 決済では代替品選択が起きた場合、オーソリを取り直さない
  • 代替品選択は金額が下振れる or 同額に収まる現象であり、与信枠が不足する現象ではないから

割引(ポイント利用 / クーポン利用)による金額変動

ポイント利用によって割り引かれる

大半の小売企業ではお客さまへのエンゲージメントを高めるために、一定の利用頻度に対して割引を効かせることがあります。その際たる例がポイント利用とクーポン利用です。

ポイントは中期での割引還元、クーポンは短期での割引還元という位置づけです。どちらも支払い金額に割引を効かせることができます。

決済では、

  • 注文作成でポイントやクーポン利用によって支払い金額が0円になった場合、オーソリを取らない。1円以上である場合はオーソリを取る
  • 注文変更でポイントやクーポン利用によって支払い金額が0円になった場合、オーソリを取っていればオーソリをキャンセル。元々取っていない(0 → 0)場合はオーソリを取らない

支払い金額0円のケースを想定するとかなり複雑になってきました... 🤨

カード種別 (デビットカード) による二重引き落とし対策

カード決済にはクレジットカードの他にデビットカードが使われる可能性があります。

デビットカードとは、口座から即時引き落とされるカードのことです。(参考)

デビッドカードであるかどうかはカード番号から識別できないため、デビッドカードというケースもあり得ることを想定して実装する必要があります。

デビットカードの場合、オーソリを取った時点で口座引き落としがなされます。この仕様は、何度も注文変更を行うとその都度指定額が口座から引き落とされることになり(一時的な二重引き落とし)、お客さまにとって都合が悪くなります。ちなみに、変更のオーソリを取る前の額は後ほど返金されます。

決済では、

  • 決済ではお客様の口座残高を圧迫させないため、金額が上振れた場合にのみオーソリを取り直す
  • 金額が下振れた場合は支払い可能枠が保証されているため、オーソリを取り直さない
  • デビットカードでキャプチャーを取るタイミングに生まれた差額は、後日返金される

ここまでのオーソリ取る/取らない/取り消すがどの場合に選択されるのかを整理したのが以下の図です。

分岐地獄 🤯

以上がStailerにおける、注文過程に存在する不確実性の整理でした。

各機能性が何を狙いに存在するのか、それらを決済の視点で捉えた時にどういった考慮で期待の振る舞いを定義しているのかを理解いただけたのではないでしょうか?

この内容を踏まえて、さらに踏み込んで実装上選択した設計判断を次に紹介します。


Stailerで選択した設計戦略

ここでの設計戦略とは、機能性, 信頼性, 効率性といった、守りたいソフトウェアの品質特性を得るために選択された、論理整合性が担保された設計判断(技術意思決定)の集合のことです。

1. 非同期処理化

Stailerでは決済処理の一部を非同期処理化しています。非同期処理を選択することで、障害やデータの不整合が発生した場合に、同期処理に比べてリカバリーがしやすくなります。

具体的には、キャプチャーを取る処理は定時実行のバッチ処理になっています。

配達完了処理(同期処理)でキャプチャーを取った場合でも機能性は満たせるかもしれませんが、お客さまに商品を届けた後に何らかの問題が発生して返品や返金の対応が発生する可能性があります。そういった不確実なケースへの備えとしても、非同期処理でキャプチャーを取った方が信頼性や効率性を守りやすくなります。

もし処理の同期性が仕様として求められていない (= 犠牲にしても問題ない) のであれば、非同期処理を選択するのが良いでしょう。

2. 支払い方法の再選択可能性を諦める

注文後は支払い方法を変更することができない

Stailerでは機能性を諦める選択もしています。注文後に支払い方法を変更することができません。

純粋に機能性を追求するなら、支払い方法を注文後に変更できると嬉しいと思います。 しかし、その機能性を担保することで対応しなければいけない不確実性の方が大きいと判断し、また支払い方法を変更することで救われるお客様の母数を想定すると、機能価値が低いという結論に至り、注文後は変更不可という仕様にしています。

3. 各社決済代行のAPIに存在する仕様差分を吸収する層を設ける

これはStailerという複数の決済代行業者と連携する仕組みである場合の話なので、かなり特殊なケースです。

Stailerではパートナーの希望に応じた決済代行業者と連携して決済機能を提供しています。決済としての機能は同じなのですが、I/Fが違うことはもちろん、小さな仕様差異が生まれてしまうのは避けられず。そういった差分をなるべく意識しなくて良いように共通のI/Fで体裁を整える考慮がなされています。

具体的にはAPIクライアントは完全に独自の実装、PaymentServiceクラスから共通のI/Fを踏襲、PaymentTransactionServiceクラスで振る舞いの仕様差異吸収と複雑な制御を行う構成になっています。

4. リコンサイルで異常がないか検知する or 検知できる状態をつくる

決済の仕組みは外部の決済代行サービスを利用して実現しています。Stailer自体はモノリスであるものの、外部サービスに依存すると分散システム的な考慮が必要になってきます。

特に気をつけなければいけないのがデータの整合性です。データに差異があることをどのように検知するか、検知した場合どう対処するか (= どちらの何のデータを正と見做して修正するか) まで考慮して設計が必要です。

これに関しては定時実行で期待通りに決済の処理が行われているかを確認するバッチ処理や、リカバリーツールを用意して異常検知とリカバリー対応を行える体裁を整えています。

5. オーソリを取り直さないケースを持つ

Stailerではオーソリを取り直さないケースを持っています。

クレジットカードだけであれば、都度取り直しても良いと思いますが、デビットカードではお客様の口座残高を圧迫してしまいます。これを避けるためにも一部のケースでオーソリを取り直さないという判断をしました。

取り直さないのは支払い予定金額が元の金額よりも下振れた場合のみで、上振れた場合は取り直しています。でなければお客さまに支払い能力がないにも関わらず、注文を受けてしまうという可能性があるからです。これにより、一定の口座金額利用圧迫の負荷を低減しています。

6. ドキュメンテーションで有事の際に共通認識を持てる様にする

いかに複雑で認知負荷が高く、把握が難しいかを理解いただけたかと思います。

複雑な構造でも長くメンテナンスしていく覚悟が必要です。少しでも楽にできるようにドキュメントも拡充を進めてきました。全てを言葉で説明するよりも図を使って、整理した方がわかりやすくなるからです。

ドキュメントではシーケンスフロー、状態遷移、シナリオケースを記載して決済制御を整理し、有事の際や追加変更を加える際にエンジニア、PdM、BizDevが素早く現状理解ができる様に工夫しています。

まとめ

長くなりましたが、ここまで触れてきた内容を端的にまとめると次のような内容でした。

  1. E-Groceryの決済は不確実性が多く存在するドメインである
  2. Stailerでは多様な設計判断を駆使して対応してきた
  3. 総じて不確実な変数とその組み合わせをどう捌くか、開発者としての腕が問われる

最後に

Stailerを例にとってE-Groceryにおける複雑な決済仕様を紹介してきました。

書き始めてみれば思っていた以上に重厚な内容になってしまい、決済がいかに複雑で奥深い領域であるかを改めて実感させられました。 (ps: 書き初めの頃はもっと軽く収まると思っていた…)

これも見方を変えれば、複雑であるが故に技術者としての腕が問われる領域であり、複雑さを受け入れてでも機能性を追求しなければE-Groceryという領域のプロダクトは価値を生み出せないということでしょう。

本記事を読んで、決済機能の技術意思決定がより良いものになっていただけたら幸いです。

Stailerもまだまだ発展途上で、解かなければいけない課題がたくさんあります。

少しでも興味を持っていただいた方はカジュアルな面談にぜひ応募してみてください。

meety.net

元コンサル、コーポレート部門の人間が10Xで2か月QAやって学んだこと

はじめに

それは、昨年の瀬のこと。12月24日夕刻。やれ七面鳥だ、やれケーキだ、やれネットスーパーだと世が浮かれている頃、私もご多分に漏れずKFCや波乱万丈のカーネルサンダースの半生に思いを馳せながら、久しぶりにオフィスに出社して仕事のラップアップをしていた。

「・・はい、今目の前にいますよ」右前方の席でWeb会議をしているプロダクトマネージャーのA氏の声が聞こえる。そのときオフィスにいたのは私を含めて3名。私の左斜め後方にはBizDevのエースB氏がWeb会議をしているところだった。

コーポレート部門所属の私を挟んだA→Bの外角高めのスライダーであると判断し、きちんと意識をチキンに戻す。そのとき、スッコココと、Slackの通知が鳴る。代表からの「@udon、今トゥゲザーしましょう*1」というメッセージだった。 QAの人手が足りてないという話と、今目の前にある仕事はいったん棚上げでQAにダイブして欲しいという依頼だった。 QAってQuestion &Answerではないやつですよね.. という愚問はグッと堪えて、「君にしか頼めないんだ」という言葉を胸に、そうかな〜そういうもんかな〜とホイホイ踊り、2つ返事で引き受けたのだった。

以下は、奥深いQAの世界に非エンジニア、元コンサルのコーポレート部門の人間が2か月間ダイブ、コシを入れて取り組んでみて学んだことを徒然に記したものである。

改めて自己紹介

新卒でL.E.K.という欧州系のコンサルでM&A戦略等に関わった後、丸亀製麺を運営するトリドールでうどんの海外展開や米国の海鮮丼チェーンの買収などをやっていました。 店舗のキッチンに立ってオペレーション改善もやりました。その後政府系PEファンドを挟み、昨年10月に10Xに入社しました。 30年uemuraとして生きてきましたが、最近は諸事情によりudonとして生きています。

10Xには、Corporate Strategyという、いわゆるコーポレート部門の経営企画(経企)に近い機能をもつ部署の一人目として入社しました。 エクセル弾いて予実管理や事業計画、ということもやりますが、そもそも事業をきちんと理解していないと血の通った事業計画も戦略も立てられないし、組織に課題が合ったとて常に人的リソースが潤沢にあるわけではないということも重なり、期間を区切ってさまざまな現場に行って問題解決にも取り組む機会に恵まれました。 入社直後に次の記事にあるようなスーパーのバックヤードで箱詰めするところから始まり、その後はCS部門の立ち上げのサポート、そして今回のQAへのダイブと繋がっています。

背景

10Xには、4月から待望の1人目のSET(Software Engineer in Test)のメンバーが入り、 1人目QAエンジニアも6月に入社予定となりました。 それまでは、QA専任のメンバーはおらず、PdM、SWE、BizDev、CSといったさまざまな職種のメンバーが協力しながら取り組んでいる状況でした。

私が関わり始めた当時は、第三者検証会社の方々の協力を頂きながら、QAという機能を独立した活動として定義しましたが、社内で専任の人はいないという状況でした。 品質保証・テストのプロフェッショナルである第三者検証会社の方々の手を借りることはできますが、基本はPdM陣がプロダクト開発と兼任しながらQAの部分も見ていました。

その中で、複数の小売パートナー様のローンチというのが平行して走る中で、本業のプロダクト開発も佳境に入り、いよいよこれは回らないぞ・・!ということで社内で暇そうな、スーパーの現場でプロダクトを使った経験のおかげでキャッチアップが早そうな私に白羽の矢(矢の元は代表)が立ったという状況でした。 結果的にではありますが、最初にスーパーの現場でスタッフ向けアプリを浴びるように使っていたことが役立ったように思います。

取り組んだこと

最初入った時には、QAとかソフトウェアテストというものへの解像度がゼロだったこともあり、「なんかQAやばそう」くらいの認識でしたが、振り返って2か月間で取り組んだことは主に下記です。

  • 各パートナー向けのローンチ(計4社)に向けてのQAのスケジュールの管理
  • 10X社内の開発チームと第三者検証会社の方々とのコミュニケーションの間をとる
  • 自身のQAについての理解向上、及び社内への共有

2か月取り組む中で、自身のQA分野への理解は深まりましたが、(どの分野もそうかもしれませんが..)やればやるほど深いなあという感触で、まだまだ浅いなと感じます。 それでも、スケジュール管理というのは脳内のキャパシティを結構とられるもので、そこを外部化して、概観と基礎の理解をベースに担ったことの意味は一定あったのかなと思います。

苦労した点(非エンジニアからすると何が難しいか)

テストの呼称がさまざまであり、かつ定義にブレがある

ここが一番苦労した点かもしれません。 新しい分野・領域に飛び込む際にまず私がすることが、単語帳を作ることです。 外国語の習得も似たところがありますが、新しい分野だと、そこでは当然のように使われている用語(多くはアルファベットやカタカナ)なのかがわからない。 専門書とか業界記事を読んでて目が進まないのは、多くは自分が知らない単語に対して自身の脳が拒否反応を示していることの累積だと思っています。

QAの分野に入った際も、「QA とは」とググるところから始め、薦められた教科書を読みました。

最初の壁は、「テストレベル」「テストタイプ」という、テストの種別を分類するための2軸でした。 これらのうち、前者は比較的本やネット上の記事での定義が揃っている一方、後者はさまざまな呼称があり、混乱した記憶があります。 たとえば「機能テスト」という言葉は、次にの記事に詳しく書いてありますが、テストレベルでもありテストタイプの話でもあるので、混合して使われると、結構困ります

特にはじめの方は、自分がまだ知らないものと、業界でもやや定義にブレがあるものの差分がよくわからないので、ざっくり理解する→書いてみる→専門家(社内や外部の専門家)に聞いてみるというプロセスを回してました。

プロセスの例

スケジュール管理自体は、ある意味、やることをタスクベースで書き出してそれを社内外のリソース鑑みて、あとは日付で追っていけば回るという側面もありますが、社内外の専門家の意見を聞きながら自身の中でQAの全体像と各種テストの立ち位置(たとえば今取り組んでいることはQAのうちの最後の砦のQC(Quality Control)部分であり、その中でも特にシステムテストの中の〇〇テストをやっている)ということがわかってから、スケジュール管理の肝である見通しとか、リスクといった部分が分かるようになってきた感覚があります。

また、同時に、前述のようにテストタイプについては各社によって呼称がバラバラであることもあって、ある意味「決めの問題だ」ということを専門家からも聞くことがあって、社内でQAという用語の使われ方を一定モニタリングした上で(例 Slackで「QA」という単語で自身に通知がいくようにする)、現状10Xで行われているテストはこれがあって、それぞれこのように呼んで、GitHubやNotion上ではこのように命名しましょうといったことを整理していきました。

社内でのテストの呼称の例(現時点)

エンジニア、(第三者検証会社の)品質保証エンジニア、BizDevチームで、QAというふわっという言葉の中で何を指しているかというのは微妙な違いがあることがあり、リリースまで◯日と1日1日を刻んで取り組んでいる日々の中では、その微妙な違いが爆弾となることがあります。そうした差分に気づいた時に、問題提起をするという動きもしていました。

私も毎度ズバッと「XXとYYに違いがあり、これはZZです」といえたらいいけれど、初めはそうもいかないこともあったので、とりあえず自分をダシに、「今ってXXの部分のYYテストのZZの項目についての話で自分の認識合ってます?」と初歩的な質問をすることで、8割の人にとっては「当たり前」かもしれないけど2割の人にとっては怪しかったかもという部分を潰す動きをしていたこともあったように思います。

QAにはじめて取り組む方(特に非エンジニア)へのアドバイス

  • 上記でも挙げた教科書はわかりやすかったのでお勧めです
  • 言葉の定義でブレがありそうだったら、早いところ仮置で定義してみて、周り(BizDevであれエンジニアであれ)壁打ちをしてて、社内の認識の統一を図っていくのがいいと思います
  • 言葉の定義を定めていくにあたって、まずは社内でどのように使われているか?を調査するには、Slackの通知にその用語の登録をしておくのが便利です

プロダクト開発のプロセスがよくわかってない

私はコンサル、事業会社(外食)、PEファンドを経て10Xに入りました。テクノロジーという分野は常々興味ある分野であったし、ガジェットについても結構こだわる派であったので、「IT」というものはむしろ得意と思っていました。

一方、今回QAという、開発に近い領域に関わらせてもらう中で、改めて自分がソフトウェアというものがどうやって作られていて、どう出荷(リリース)されるかの流れについて無知だったなあということをひしひしと感じました。 自分が何気なく使っているアプリの裏側で、サーバーとクライアントという概念があったり、個別の小売パートナーへの開発がプラットフォーム上の他の挙動に影響を及ぼしうるということであったり、「イシュー」という単語がコンサルと開発どちらもよく使われるが用法が違ったり、等々

QAというひとつの切り口ではありますが、次の記事でも書かれているように、QAとは出荷前の最後の砦として存在しているものでなく、本来は開発プロセス全体に関わるものであるのです。

非エンジニアの自分にとっては、こうした機会でその片鱗を見ることができたのは非常に貴重な機会でしたし、本業である事業戦略を作っていくとか、あとは小売パートナーと提携をしていく中で、こういった解像度が高まったのは非常にありがたかったと感じます。

余談ですが、私がいた外食企業でも確かにQA/品質保証という部署はあり、そのカバー範囲は、調理前の原料や提供前の料理の最終チェックということだけでなく、それを未然に防ぐための手洗い励行だったり、調理のプロセスや器具へのフィードバックだったり、広範なものだったなと思います(なお品質保証部長と1週間US出張しての学びは、「手洗いメッチャ大事」)。

非エンジニアで開発について知りたい方へのアドバイス

  • 私のように非エンジニアだけど開発について知りたい!と思っている人は、何らかの手段でそのプロセスの一端に関わるのがいいと思います。エンジニアに「開発について教えて!!」と言っても困ってしまうし、そもそも自分としても何が知りたいかワカランというケースも多いと思います
  • はいQAやって!というケースも珍しいと思いますが、テストケースの実行の手伝いをするとか、たとえばアプリアップデートのリリース文書いてみるとか。なにか切り口をみつけて実務で関わると、その一端から見えてくる世界があると思います

「どこまでやったらいいか」の判断が難しい

これは、永遠のテーマな気もします。QAの海をすこし回遊していた私が、未経験の人と話すときに初めに伝えるのは、「QA*という活動を経なくてもソフトウェアの出荷自体はできる」ということだったりします。

なんとなく、私を含めビジネスやコーポレート出自の人間の視点では、最後リリースするまでにQAとして「OK」を出してほしい、黒か白か、というイメージを持ちやすいかもしれません。しかし、すべてのパターンをテストしてパスできましたということを証明するのは現実的に無理です。実際には「ほぼ白」というラインを決めて、OKを出していくことになります。 「どこまでやるか」の決定には主観も入りますので、そういう意味では、「良くできているので何もしないでOK」と決めるのであれば、QA*をしなくても出荷(リリース)はできるということになります。

しかし、当然ながら、バグのない完璧なソフトウェアというのは(おそらく)存在しないので、「ほぼ白」がどこなのか?を判断していくことになります。 なので、「QAやります」の言葉の裏には、そこの「ほぼ白」を定義するという、サイエンスよりはアートに近い世界が存在します。社内でも、社外でも、ここの理解度を高めることが、より平和な世界につながる気がします。

お客様と対面する営業や事業開発の視点では、お客様に「品質担保しっかりやってよ」とか「御社として問題ないようにしてほしい」ということをいわれると、「QAというプロセスをきちんと回す」ことが解決策と考えるのは自然なことだと思います。 ただ、その課題解決に向けた社内の過程は、人を+◯人入れれば良いとか、あと◯シナリオを回す、というサイエンスで切れるものだけでなく、「ほぼ白」のラインを定義するというアートがあります。

ですから、お客様に対して満足のいくプロダクトを出すということは、そうした定義を踏まえた上で、営業や事業開発という、お客様に対面するメンバーが、そうした側面を理解した上で、何を示せば目の前のお客様は納得してくれるか?を因数分解して説明を尽くすということが肝要だと考えます。 特に、10Xは一義的には小売パートナーを相手にするB2B2C企業であり、表側のアプリケーションを作るだけでなくネットスーパーのオペレーションを実現するインフラを提供していますから、完全なるB2C企業と比べても求められる水準も高いと認識しています。

同様の文脈で、「2週間確保していたこのテストを1週間でできないか?」に対する答えはテストする項目や観点を減らせば良いので「できる」ことが多いですが、その分不具合が発生するリスクがあがるということになります。 たいていの場合、スタートアップでは時間に余裕があってテストに時間をかけられる状況より、リリースまであと◯日、と切羽詰まっている状況のほうが多いでしょうから、時間の制約がある中でどれだけ品質担保のレベルを上げられるか?ということが肝になります。

開発の現場に触れはしましたが、実際に開発をしていたわけではないので、この「どこまで良いか?」という判断を私の方でするのは難しく、かつ関わっていたエンジニアやPdMにそこを判断してもらうリソースの制約もあります。 なので、もう少し少ないシナリオ数(=テスト時間)で同程度の品質を担保できたのでは?と思う場面はありましたが、安全に振って多めにやっていたいなという所感はあり、ここは私としては難しさを感じた点でした。

QAに接点を持つことになったすべての方へのアドバイス

  • QAの分野はすべてのパターンをテストする、真っ白を証明するということが難しい一方、締切がある領域だと認識をすること。それゆえ、どこかで線を引かなくてはいけないが、その取組はサイエンスよりアートに近い部分があることを理解した上で、期間を定めて(1−2週間とか)さまざまな人と話すのがいいと思います
  • 大上段の方針は経営レイヤーで決めるという前提のもとですが、細かい部分では、プロダクトを開発するエンジニア、お客様と対面している営業/事業開発職のメンバーからなるべくいろいろな意見をヒアリングする。それを通して、どこに理解のギャップがあって、ここで折り合えそうだというポイントをみつけて提案していく。初めから器用には難しいかもしれませんが、提案を通して議論のたたきを作ることができれば、事業を前に進める一助につながるのでないかと思います

QAはなぜ大切か?

社内で、「QAは大切ですか?」という質問に対してNOと答えるメンバーはおそらくいないと思います。 それでも、10Xを含めQAが課題として上がるのは、それが開発スピードと開発費用とのトレードオフとなる場面があるから。 時間とお金というリソースが無限にあれば、どのプロダクトに対しても品質担保ができますが、基本的にはそのどちらにも制約を抱えているスタートアップという世界において、折り合いをつけていくことになります。

これは上述したSETメンバーからの受け売りですが、バグの検出は、要件定義や設計段階での検出と比較して、リリース後の発見では数百倍になるリスクがあります。

早期検出は大事

私を含めQAの経験がないメンバーからすると、QA=QC(リリース前の最後の砦)というイメージが強い気がします。 時間とお金というリリースの制約がある上で、いかにリリース前に最適なQAプロセスを作れるかを考えよう、という考えに到れるのはおそらく大きな一歩ですが、QAの本来の役割に立ち返ると、これだけでは不十分です。 実際にはそれを設計やその前の段階から未然に防ぐための仕組みづくりが重要となります。

それが作られると、良きプロダクトを、適正なコストで、早く届けることでき、法人のお客様、及びその先のエンドユーザーがハッピーになる。その実現の鍵がQAだと私は考えています。

2か月やってみたその後

  • 無事に4社に向けたプロダクトのリリースができた!
  • 1人目のSETメンバーが入り、2人目のメンバーも決まった!(参考: 1人目のSETが話す10XのQAの今と今後
  • 社内のQAの用語とプロセスについての認識の統一が進んだ!
  • 分野を横断して色々やってみていいんじゃないかという雰囲気が出た!(気がする)

コンサルとQAの共通項

最後に少しだけ、あえて共通する部分があればということで書いてみました。 結構コンサルの人とか性質としては向いているのかもしれないと個人的には思いました。

なお、「コンサル」と「QA」はともに、その言葉が指すところは広範なのですが、ここでは人ではなく業務の中の要素における相似について、あくまで私の経験を元にした所感を書きます。

言葉の定義が大切

コンサルの人々は結構言葉にうるさい人種だと思います。 それは、必ずしも自分がクライアントほどに詳細を知らない分野において、構造化をして洞察を出していく必要があるためです。 その構造化、そしてロジックを作っていくために、土台がグラつくとあとが積み上がりませんから、ひとつひとつの言葉について定義をしています。 過去に私が働いたアメリカ人の上司は、「How to work with me」というスライドを1枚持っていて、自分が使う言語や性質について定義をしていました(これはtoo much)。

上記に記載したように、現状QAの業務の中で使われるテストの種別であったり、ひとつひとつの業務については、会社によって呼称が違う部分もあります。 なので、そうした言葉の感度を持って、自身のいる組織における最適な定義をしてそれをベースに業務を組み立てていくということの重要性の高さという意味で、共通する点があるなと感じました。

綿密なプロジェクトマネジメント

QA、特に最後の砦のQCにおいて、結構1日1日を刻むプロジェクトマネジメントというか、スケジュール管理が行われているなと感じました。 コンサルは人月商売なので、どの職位の人を何週間(or 何日)張るかでフィーが決まります。そのため、決まった期間(たとえば3か月)においてかなり詳細にスケジュールを組み、稼働を管理します。コンサルの費用は主に人件費なので、そのコントロールのために、やや炎上しかけている案件とかだと、結構週次単位で人が入ったり出たりということもあり、文字通り1日1日を刻んで生きていた記憶があります。

私が関わったQAの業務は主にリリース前のQCのプロセスでしたから、リリース日は決まっており、そこに向けて必要かつ最適な量の品質担保(=テスト)を実行するのが命題でした。 わからないなりにですが、誰が何をしていて、何日かかりそうで、どのタスクとタスクに因果関係があり、どのタスクは締め切りに柔軟性があるかを把握して1日1日のスケジュールに落としていくというプロセスは、コンサルで1日1日を刻みながらスケジュール組んでいたものと似たものがあるなと感じました。

最後に

私はコンサルで、色々な業界や国に突っ込まれてなんとかキャッチアップして生き抜くということをちょくちょくやってきたので、こうして新しい分野に飛び込むことは好きだし、ある程度慣れがありました*2

それでも、その分野を理解し説明するだけでなく、自分が担い手になるのは新鮮な経験でした。

QAという分野の概観を理解する前から、重要なパートだろうなという予想はあったので、なにかとヒヤヒヤしましたが、こうした重要なパートを任せてくれるところは10Xの良いところだと思います。「新参者だから」とか「専門家でないから」といって遠慮せず、とりあえず主体的にやってみる(「Take Ownership」)ことが大事だなと感じました。

とはいえ、最初の頃は知らないものは知らないし、わからないことはわからないので沢山質問をしていました。 その点では、10Xはさまざまな専門家が集まってきていて、皆知見や知識のシェアに惜しみがないというか、優しいなと感じます。 今回の2か月の中で、本やネットの記事といった二次情報は大いに参考になりましたが、やはり社内のメンバーに教えてもらったことは大きいです。

それは新しい分野に飛び込む機会が沢山あるということでもあると思いますし、それをサポートする体制というか、マインドの人が10Xには多いと思います。 As One Teamというバリューが浸透しているなと感じた一面です。 「IT系の会社で数年働いたけど、そんなにソフトウェアのことはわからない」というビジネス側の人を何人も見てきたので、BizDevとかSWEとかコーポレートとか、職種の違いはありますが、皆ごっちゃになって一緒にコトに向かっている10Xという環境は面白いなと思います。

QAという分野は勿論、さまざまな職種で仲間を募集しています。ぜひ一緒に働きましょう!

*1:社内でのミーティングの一時的な呼称。以降、そこまで浸透しなかった

*2:昔高飛込をやってて日本で8番でした