入社2年目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も用意したので、まずは話を聞いてみたいという方はそちらもどうぞ。

• 採用ページ: https://open.talentio.com/r/1/c/10x/pages/97170
• カジュアル面談: https://calendar.app.google/z7AfzeyfradAYXci7

---

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

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

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

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

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

TL;DR

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

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

プロダクトビジョンとプロダクト指針の作成

こんにちは、10Xでプロダクトマネージャーをしている@ysk_urです。社内のみんなの頭の中ではだいたい同じものを見ていたと思うのですが、改めてプロダクトビジョンとプロダクト指針を作成した話を今回は書こうと思います。

個人的には、「直接の顧客はtoBだけどtoCの生活をより便利に」、「ネットスーパーの歴史的経緯からの制約の設定」、「継続的なアップデートが必要」などのポイントが気に入ってます。

プロダクトビジョンとプロダクト指針作成の背景

会社の活動サイクルが全社戦略によりフォーカスして活動を行う形に変化したことに合わせて、戦略と紐づけた形で「プロダクトの目指すべき姿」を明確に定義する必要があると感じました。
また、過去の取り組みを振り返ると今回改めて書いたプロダクトビジョン達成のための活動自体は行われていましたが、中長期で十分に達成できるかという視点が弱いという課題もありました。
プロダクトビジョンを明確にすることで、社員がプロダクトの方向性を理解し、集中して取り組める環境を作りたいという狙いです。ロードマップが単なる施策リストになってしまわないように、また、社員がビジョンに基づいて自主的に動き出せるよう、以下のようなポイントを意識しました。

• 方向性の明示：「どこを目指しているのか」を明らかにすることで、社員が戦略を理解し、やらされ感を持たないようにしたい。
• 予見できる機会への準備：市場の機会が到来した際に迅速に対応できるよう、ビジョンを基盤に考えを整理し、準備を整える。
• ユニークな存在意義の提示：単なる事業利益や時価総額の達成ではなく、「なぜ私たちが小売業界に向き合い、ネットスーパー/ネットドラッグストアを支援するのか」という意義を共有し、社員のモチベーションを高めたい。

こうした背景から、社内で既にあった考えやドキュメントをベースに、CTOとプロダクト本部付のメンバーで議論を重ね、具体的なビジョンを作成していきました。

プロダクトビジョン・プロダクト指針の作成プロセス

プロダクトビジョンの作成は、社内で既にあった考えやドキュメントをベースにスタートしました。

議論の中では、顧客は誰なのか？最終的に実現したい世の中はどういったものなのか？などで議論が白熱しました。また、ネットスーパーの歴史的経緯や市場環境から、プラットフォームとして取り組むことの意義などが議論され、結果として制約が改めて言語化されていきました。

プロダクトビジョン策定における議論の広がりや複雑さを振り返ると、BtoBtoCビジネスの難しさを表していると思います。直接の顧客は小売企業ではあるが、実現したいことは人々の日常の買い物を便利にすることであり、間接的に実現したいことを達成する必要があります。10Xのコーポレートサイトにでかでかと載っている「1人の難題を巨大な市場から解く。」をまさに取り組んでいるなと改めて実感しました。

また、プロダクトビジョンを達成するためには、Stailerが多くのパートナーを迎え入れてもソフトウェアが健全な状態を維持し、開発速度を落としたり、必要以上の保守運用コストをかけてはいけないことも改めて見えてきました。 そういった経緯から、プロダクトビジョンだけでなく、プロダクト指針も作成することになりました。

複数回の議論を踏まえ、最終的に以下のプロダクトビジョンとプロダクト指針を策定しました。最終的にプロダクトビジョンとプロダクト指針という構造に整理されていますが、ここも紆余曲折がありこの形に着地してます。構造から入るとうまくいかなかったと思うので必要な要素を構造化した形になります。

実際に作成したプロダクトビジョンとプロダクト方針の一部

一部抜粋して記載しています。詳細や全体像を知りたい方はぜひお声がけください。

プロダクトビジョン

「小売企業がネットスーパーやドラッグストア事業を持続的に運営できる手段を提供し、人々の日常の買い物を便利にする。」

補足

プロダクト指針

プロダクトビジョンを実現するために、以下のプロダクト指針を定義しました。中長期でStailerの価値を高めていくための制約になります。実装方法以外にも提供価値も定義していますが、ここでは実装方法の制約の一部を紹介します。

プロダクトが提供する価値

お客様

• オンラインならではの利便性: 店舗への移動や運搬からの解放、検索や推薦による効率的な購買など、オンライン前提ならではの利便性を強化する。

小売企業

• 正確で効率的な業務遂行: オペレーションのミスや非効率が生じにくい業務支援ツールを提供し、NS/NDgSの運営にかかるコストを抑制する。

実装方法の制約

プロダクトの機能

• 全企業共通の仕様: 機能の仕様は汎用的に設計し、すべての小売企業のNS/NDgSで共通の実装をする。
• カスタマイズは小売企業側で完結: サービスの設定、特定の機能の有効化といったカスタマイズは、管理画面を通じて小売企業側で完結して行えるようにする。

システム連携

• 事業運営に必要なシステム連携の完備 : 小売企業のシステムが必要とする連携のインターフェースを揃えており、小売企業がシステムを適合させ次第、事業を開始できる。
• 企業個別の実装の分離: ビジネス上の都合によって企業個別の実装を作らざるを得ない場合、プラットフォームの実装には混ぜ込まずに分離する。

プロダクトビジョンの社内反応と今後の課題

プロダクトビジョン策定後、社内で共有を行った結果として戦略として掲げて進めている施策が複数あります。 特に実装方法の制約に関してはPMFフェーズを超えてスケールを目指す上では重要な取り組みとなっており、現在の実装を見直し改善に向けた取り組みが実際に進んでいます。 Stailerはプロダクトの機能が非常に多いのですが、カスタマイズや設定等が必要な機能を適宜小売企業側で完結できる形に実装が進んでます。

実現方法を変えることでのメリットとデメリットはプロダクト本部のメンバーだけでなくビジネス本部のメンバーにも十分に理解してもらい、中長期でプロダクトビジョン達成に一定の目線があってる状態を作ることができています。

一方でまだまだ社員全体への浸透は十分とはいえない状況だと思っています。ベースとなるものがあったのもあり、作成プロセスに多くのメンバーを巻き込んだわけではなかったり、言語として洗練されていないことで浸透が弱いと思っています。より浸透を図るための取り組みが今後の課題と感じています。

また、1年前に同じ状態のアウトプットが作れたと言うと高い確率で違うものになったと思います。事業を進める中で得られる知見の反映も必要なので、今後も継続的なアップデートを前提としています。

trufflehogを活用したGitHub Organizationのcredentialsスキャン

こんにちは、セキュリティチームの@sota1235です。

突然ですが、ソフトウェアエンジニアの皆さんに質問です。他者に漏らしてはいけないAPI keyやSSHのprivate keyを誤ってGitHubにpushしてしまったことはありますか？私はあります。*1

日々、スピード感を持ってものづくりに臨んでいく中で本当はcommitしてはいけないものを間違ってcommitしたり、それに気づかずにGitHubにpushしてしまうなんてことは人間がミスをする生き物である以上、誰にでも起きえる事故です。

今回はそんな事故を検知するのにtrufflehogを活用しているお話をします。

なお今回は事故を未然に予防する話には触れません。

github.com

*1:かなり昔の話ですし、もちろんrevoke済みです

10X の推薦を作るチームと ML platform

10X ソフトウェアエンジニアの @metalunk です。ネットスーパー、ネットドラッグストアのプラットフォームである Stailer 事業で、機械学習（ML）と検索を専門として働いています。

2024年4月からいま（2024年8月）までの5ヶ月間で6つの推薦機能をリリースできました。この成果を支えたのはチームと ML platform（機械学習の基盤システム）です。このブログではチームの取り組み、ML platform の機能、および具体的な成果についてご紹介します。

このブログは技術ブログの体ではありますが、さまざまな業界、職種の方に読んでいただくことを目指して執筆しました。

(3) 章, (5) 章だけは機械学習に取り組んでいる人向けの内容を含みますので興味のない方は読み飛ばしてもらって結構です（機械学習に取り組んでいなくても興味のある方はぜひ読んでください）が、それ以外は IT 業界のみならず小売業界の方にも読んでいただけると思います。

(1) 5ヶ月間の成果

はじめに、この5ヶ月間で上げた成果を列挙します（つかみです。詳しくは (4) 章で取り上げます）

1. レジ前推薦でパーソナライズモデルをリリースし、レジ前推薦の売り上げ 10x（カート追加率 3.2x, カート追加点数 2x, 単価 1.6x）
2. 関連商品推薦のあたらしいモデルをリリースし、カート追加率 3x
3. セレンディピティの高い、一緒にどうぞ推薦をリリース
4. 次の検索キーワード推薦のリリース
5. 人気順をリリースし、もっともカート追加率が高い並び順に
6. 代替商品推薦のリリース

これで推薦枠は、レジ前推薦、ランキング、商品詳細、次の検索キーワード推薦、代替商品推薦の5箇所になりました。

そして、これらの成果は、2024年4月に始動したお客さま体験チームによって生み出されました。