アジャイルテストの 4象限で考える プロダクト開発の品質への向き合い方 2024/ 12 / 07 Ubie株式会社 永野峻輔 (@glassmonkey) テスト自動化カンファレンス 2024

2 自己紹介 2 私信 先月入籍しました 永野峻輔 (@glassmonekey) 所属 2024/02 ~ Ubie株式会社 Product Platform パーソナライズ基盤 Tech Lead 趣味 個人開発, ゲーム, 読書 https://php-play.dev

3 今日の目的 アジャイルテストの4象限を基軸とした実践的なテスト戦略を紹介し、 参加者の皆様がプロダクト開発における品質向上に取り組むためのヒントの提供 ※ 具体的なツールの使い方やテストの書き方といったhowの話はスコープ外です 3

4 会社紹介

5 Mission 5 テクノロジーで人々を適切な医療に案内する

6 Ubie実施の患者サーベイ （2022年2月実施、N=4,462、対象：直近3ヶ月に症状発症経験のある人） 生活者の行動 医療従事者の行動 発症・自覚 受診検討 受診 診断 直近3ヶ月に何かしらの発症があった人を 100とした時 100 66 48 38 - 62% マッチング不全 発症・自覚から適切な診断に至るのは、ごく一部です

7 他にも症状認知から治療までのペイシェントジャーニーには、さまざまな課題が潜んでいます 症状認知 情報収集 受診 診断 治療 想定行動 • 痛みや違和感を伴う症状を 自覚する • 健康診断などの数値が悪化 しており、背景の病気の可 能性があることを自覚する • Webで症状や思い当たる疾 患名で検索する • 家族や友人に相談する • 近隣のクリニックを受診する • クリニックの紹介で病院を受 診する • 医師から診断を受け、治療 法を聞く • 治療に期間を要するものや 選択肢があるものは治療方 針をすりあわせる • 処方された薬を服薬する • 定期的に医療機関にかかり 検査を受ける • 入院する 落とし穴 × 我慢できる痛みを放置する × 根拠ない情報を過信する × 行くべき医療機関を間違える × 適切な診断がされない × 服薬や定期検査を怠る × 症状を上手く伝えられない × 自分にあった治療法がわからな い × 忙しくて放置する × 副作用に苦しむ ファクト 体調不良者の約4割は、「医療機関に行く べき症状かわからない」（*1） 患者の約2割は「症状を上手く伝えられな い」と悩んでいる（*1） 希少疾患は発症から診断まで 平均2年、最大40年かかる（*2） 体調不良者の約1割は Webの情報を見て行動を決める（*1） 治療を受けた患者の約 4割は「症状が改善せず、 治療や薬が適切か不安」と感じている （*1） 患者の約2割は「症状改善後通院・服薬を止めて いいのか分からない」と悩んでいる（*1） *1 Ubieによるインターネット調査・2021年（n=400） *2 日本製薬工業協会 希少疾患 患者さんの困りごとに関する調査

日本の高い医療技術×テクノロジーから生まれた問診エンジン（ AI）とプラットフォーム 8 創業者の思いから 生まれ独自のプラット フォームにより磨かれた 問診エンジン - 50名以上の医師監修のもと、 国内外5万本の医学論文を元に 作られた問診エンジン - 1800以上の医療機関からの フィードバックにより 問診エンジンの精度を向上 問診エンジンをコア技術に据えたプラットフォーム 問診エンジン 月間1200万人以上の生活者が利用 メガファーマの約8割が活用 15,000件以上の医療機関と連携 生活者向け 医療機関向け 製薬企業向け

9 2020年のサービス提供開始以来、多くの方の適切な医療へのアクセスを支援しています 月間利用者数 1200万人 提携医療機関数 1万5000以上 累計利用回数 1億 8000 万回以上 対応する症状 3500以上 ユビーを利用した後 実際に受診した人数（推計） 1838万人 対応する病名 1100以上 ユビーを利用したうち 「受診してよかった」 91.1% アカウント登録数 500万人

10 アジャイルテストの4象限とは?

11 アジャイルテストの 4象限、その前に 昨今のWebプロダクト開発は複雑化してきています。 ● モバイル端末の普及 (web アプリ と ネイティブアプリの共存） ● クラウドネイティブ ● AI技術の躍進 ● IoT …etc 11

12 品質と向き合うためのテストも複雑化 ● ユニットテスト ● 結合テスト ● e2eテスト ● シナリオテスト ● パフォーマンステスト ● 回帰テスト などなど 12

13 アジャイルテストの 4象限 ● テストの分類技術 /ビジネス , チーム支援 /プロダクト批評の 2軸で表現されたもの 13 第四象限 非機能要件に対するテスト ツールによって実施 第二象限 機能要件に関するテスト 手動・自動で実施 第一象限 コードレベルのテスト 自動で実施 第三象限 探索的テスト 手動で実施 技術 ビジネス チーム 支援 プロダクト 批評

14 第一象限　(コードレベルのテスト ) 開発者が日常的に意識するようなテスト 例) 関数Xの期待は〇〇である ● 単体テスト ● 結合テスト (サイズ小さめ ) ● コンポーネントテスト ● 静的解析 など 第四象限 非機能要件に対するテスト ツールによって実施 第二象限 機能要件に関するテスト 手動・自動で実施 第一象限 コードレベルのテスト 自動で実施 第三象限 探索的テスト 手動で実施 技術 ビジネス チーム 支援 プロダクト批 評

15 第二象限 (機能要件に関するテスト ) 手動と自動で表現されるようなテスト群。機能テストとも呼ばれる。 例) 　ログインしている初回ユーザーが問診フローを完了する ● 受け入れテスト ● 結合テスト (サイズ大きめ ) ● シナリオテスト など 15 第四象限 非機能要件に対するテスト ツールによって実施 第二象限 機能要件に関するテスト 手動・自動で実施 第一象限 コードレベルのテスト 自動で実施 第三象限 探索的テスト 手動で実施 技術 ビジネス チーム 支援 プロダクト批 評

16 第三象限 (探索的なテスト） 主に手動テストによって行われる 例) 新機能は一部ユーザーに提供して反応を伺う ● ユーザー受け入れテスト ● シナリオテスト ● A/Bテスト など 16 16 第四象限 非機能要件に対するテスト ツールによって実施 第二象限 機能要件に関するテスト 手動・自動で実施 第一象限 コードレベルのテスト 自動で実施 第三象限 探索的テスト 手動で実施 技術 ビジネス チーム 支援 プロダクト批 評

17 第四象限 (非機能要件に関するテスト ) 非機能と呼ばれることが多いテスト群。ツールによって行われる 例) 90%tileでRPS 〇〇 を達成する ● パフォーマンステスト ● セキュリティテスト など 17 17 第四象限 非機能要件に対するテスト ツールによって実施 第二象限 機能要件に関するテスト 手動・自動で実施 第一象限 コードレベルのテスト 自動で実施 第三象限 探索的テスト 手動で実施 技術 ビジネス チーム 支援 プロダクト批 評

18 アジャイルテストの 4象限からの学び テストと一言でいっても様々な種類がある。 銀の弾丸はない。取り組み方も千差万別がある 18

19 実践

日本の高い医療技術×テクノロジーから生まれた問診エンジン（ AI）とプラットフォーム 20 創業者の思いから 生まれ独自のプラット フォームにより磨かれた 問診エンジン - 50名以上の医師監修のもと、 国内外5万本の医学論文を元に 作られた問診エンジン - 1800以上の医療機関からの フィードバックにより 問診エンジンの精度を向上 問診エンジンをコア技術に据えたプラットフォーム 問診エンジン 月間1200万人以上の生活者が利用 メガファーマの約8割が活用 15,000件以上の医療機関と連携 生活者向け 医療機関向け 製薬企業向け

21 プロダクトを通して ユーザーの ペイシェントジャーニーの 実態を把握、認識できる ペイシェントジャーニー上 の課題を解決する ソリューションの共創 ペイシェントジャーニー上 のユーザーの 行動・ニーズ把握 ペイシェントジャーニー上の 課題を持つユーザーに 適切なタイミングで 適切な情報を提供できる 製薬企業 ユーザー 患者/生活者 医師 プロダクト間の連携の好循環

22 プロダクト間の好循環を加速させるためには ● プロダクト間の連携をなめらかにする必要がある ● データの正規化・標準化をしていく必要がある。 ● 個人によりそった最適な体験を提供する必要がある

23 パーソナライズ基盤爆誕

24 パーソナライズ基盤とは ● 特定プロダクトの内部的機能をマイクロサービスとして切り出したもの ● 汎用的に他のプロダクトから使いやすい I/Fを提供する。（特にユーザーのセグメンテーションなど） ● 簡易的な内製の CDP(Contents Deliery Platform）のようなもの ● 2024年12月時点で開発中です

25 パーソナライズ基盤と私達 チームメンバー ● プロダクトマネージャー : 1名 ● テックリード兼プロダクト開発エンジニア : 1名 (私） ● プロダクト開発エンジニア : 4名 ● デザイナー兼プロダクト開発エンジニア : 1名 ● QAエンジニア兼 スクラムマスター : 1名

26 パーソナライズ基盤が抱えてた課題 ● コアドメインなため仕様が複雑 ○ 2020年リリースのプロダクトがベース ● 製薬事業にクリティカルなので重厚なテストが必要 ● 実装言語の変化 ○ kotlin -> Go (参考: Ubie は Go と Node.js の会社になります ) ● ステークホルダーとして巻き込むチームが多い ● 在籍年数が比較的若いメンバーが多め (私は今年 2月入社なので 1年弱） ○ Goの実務経験があるメンバーがほぼいない などなど

27 クネビンフレームワーク 問題を分類するフレームワーク 混沌 単純 煩雑 複雑

28 パーソナライズ基盤とクネビンフレームワーク 変数が複合的であり、一気通貫で説明することが難しい -> 複雑 混沌 単純 煩雑 複雑

29 複雑性と向き合う

30 複雑性に向き合うためのコンセプト ● 目線を揃える ○ 語彙を揃える ○ 言語化の徹底 ● 間違いは起きるもの前提で考える ○ 間違いに早く気付けるように ○ 経験主義の徹底 ● 仕様は変更可能である ○ 仕様を育てる ○ 複雑すぎる仕様は捨てる ● 孤立しない ○ ステークホルダー (分かりて )と一緒に仕事を進める 30

31 主な取り組んだこと ● リスクストーミング ● 品質特性の定義 ● テスト中心設計 …etc 31 他にも有意義なプラクティスがあるので おすすめです

32 リスクストーミングとは ソフトウェア開発に関わる人たちで、開発におけるリスクを特定する手法 以下のようなリスクを炙り出していくことを目指している ● 人材: チームの人数やスキル、協力体制、リーダーシップの適切さ、トレーニ ングの必要性、将来的な人材確保の可能性、運用・サポートチームのスキ ル、主要メンバーの離脱リスクなど。 ● プロセス : 作業方法の理解、プロセスの文書化、期待される成果物、予算の 充実、外部イベントの影響（事業変更、合併、法律の変化など）。 ● テクノロジー : 提案されたアーキテクチャの品質特性の達成可能性、技術の 機能性、安定性など。

33 リスクストーミングの実施 どこがリスクと考えている点を各々が言語化 赤：優先度高 黄：優先度中 青：優先度低 オペレーションフローが 実現できない 表示が崩れる 表示が重い 基盤システムの影響で 他サービスが動かなくなる 指定したユーザーセグメントと 異なるユーザーに マッチしてしまう データ移行で データが欠損する

34 品質特性とは プロダクトが満たすべき品質の特性のこと 非機能要件と呼ばれることもあるが、機能的側面を併せ持つのでチームでは品質特性という語彙で統一した 34

35 品質特性の定義例 ● 90%tileの利用者に対して〇〇 ms以内にレスポンスを返却する ○ 現状の状況を有識者にヒアリングをして決定 ● XX rpsをさばけるようにする ○ CMがあったときのピークタイムを参考にして決定 ● 要配慮個人情報が想定していないところにログとして出力しないか ○ 全社的なデータ領域が定義済みなので仕組みに乗ることで解決 35

36 目線を揃える 定量目標に落とし込む

37 テスト中心設計

38 テスト計画を中心に設計・リリース計画をたてた 38 ● 語彙を揃えるところからスタート ● 設計で分離する観点も主にテスト観点を中心に設計をした ○ 場合によっては変更することもあった。 ○ テストダブルどうする ?とか ○ 例）インフラ層とアダプター層の分離 ● プロダクト開発エンジニアと QAエンジニアの分担も進められるよう にした Notionで言語化するところからスタートした

39 アジャイルテストの 4象限と分担 39 ● 第一象限はプロダクト開発エンジニアが実施 ● 第二象限は QAエンジニアが主導 ● 第三象限は skip (既存機能の置き換えなので） ● 第四象限はプロダクト開発エンジニアが主導 第四象限 非機能要件に対するテスト ツールによって実施 第二象限 機能要件に関するテスト 手動・自動で実施 第一象限 コードレベルのテスト 自動で実施 第三象限 探索的テスト 手動で実施 技術 ビジネス チーム 支援 プロダクト批 評

40 第一象限について取り組んだこと ● レイヤーごとにテスト観点を言語化していった ● モデルケースの実装をテックリード主体で作っていった ○ 他メンバーもコピペで追従できるようにスケールを意識していった ● Pull Request単位で基本的にテストは書く・書きやすくできるようにした ○ 書きにくいときは相談にのったりとか ○ 設計を見直すことも 40

41 第二象限について ● QAエンジニアが主導でシナリオ整備をしていった ● N=1なパターンを厚めにした。 ● リリーストグルを使った制御の導入 ○ コードベースとしては常にアップストリーム上で動くように ● データ移行を事前に行うことでリグレッションテストを実施できるように 41

42 第四象限について取り組んだこと ● オブザーバビリティの整備 ○ いわゆる Open Telemetryの計装をいれる ○ 誰が見ても改善に取り組めるようにした。 ● 繰り返し実行できる仕組みの整備 ○ ダミーデータを大量に作るスクリプト用意したり ○ ツールには k6を用いて実行スクリプトを Github管理できるように 42

43 結果

44 良かった点 ● テストを書くことが当たり前になってきた。 ○ 品質対してのシフトレフトが一定できるようになってきた ○ メンバーが増えてもジョイン翌日には自身を持ってリリースできるような体制になった。 ● QAエンジニアとプロダクト開発エンジニアで一緒に品質に向き合えるようになってきた ○ パフォーマンス観点はプロダクト開発エンジニア主導 ○ 複雑な手動テストが必要なものは QAエンジニアが主導 ● ステークホルダーへのコミュニケーションがとても楽になった ○ 仕様レビューとしてテストコードに対してステークホルダーのレビューをお願いしたり ○ メンバーに不慣れな言語のテストコードをレビューしてもらうとかも 44

45 反省点 ● 複雑な仕様に対してのシフトレフトがやりきれなかった。 　　　-> QAエンジニアとして設計していたテストケースをユニットテストに輸入したり -> シナリオから予期せぬパターンが潜んでたことがあった (race conditionなど） ● テスト基盤が貧弱 ○ 特にフロントエンドテストの課題が増えてきた ○ 関数のユニットテスト + e2eでわりきって作っていたが漏れるパターンが増えてきた -> コンポーネントに対するテストをできるように整備中 ● テストの網羅性の担保 ○ テストケースを QAエンジニアの手腕に依存する場面が散見した ○ 生成AIなどを用いてシナリオ作成を効率化するなど余地はありそう 45

46 まとめ

47 まとめ ● 課題が発生したら焦らず分類してみよう ○ 複雑系も FBループを回していけばなんとかなるはず ● 語彙を揃えて、経験主義で向き合えば素人集団がプロ集団に変化していく ○ 目線を揃えることが大事。ずれたら対話しよう。新たな気づきがある。 ○ とにかく FBループを回すことが大事 ● テストは自動にこだわらず人が介在する余地も重要である ○ テストすれば品質を満たせるわけではない。 ○ そのためには自動化するべきところは自動化しよう ○ 明確なテストは AI時代だからこそ特に大事。 47

48 宣伝 仲間になろう