☑️
みんなで学ぶ！品質改善を加速する テスト設計と管理手法LT レポート
公開
2025-03-10
文章量
約3260字
Yard 編集部
Yardの編集部が、テック業界の最新トレンドや知見について発信します。
ソフトウェア開発の現場では、短いリリースサイクルを求められる一方で、品質の確保がますます重要なテーマになっています。本イベント「みんなで学ぶ！品質改善を加速する テスト設計と管理手法LT」は、4社のエンジニア・QAリーダーが実践する品質改善のリアルな手法やノウハウを共有する内容でした。
2025年1月29日夜、オンラインで開催された本イベントは、以下の4つのLT（Lightning Talk）を中心に展開。各社が抱える開発上の課題やテストの最前線が明らかになり、多くの参加者からは「すぐにでも取り入れたい」「なるほど、こうやってチームで品質を担保するのか」といった声が上がりました。
LT① DevOpsに向けたテスト方針（イオンスマートテクノロジー / 白江 大輔 氏）
最初に登壇したのは、イオンスマートテクノロジーの白江さん。同社はイオングループ内に向けたデジタル施策を進めており、会員基盤やデータ基盤など巨大な仕組みを抱えながら、「安定稼働」と「新技術の導入」を両立させることが至上命題だといいます。
テスト自動化で追求するDevOps
- イオングループの会員IDが1日で80万件を超えて登録されることもあり、少しの障害が大きなインパクトにつながる
- サービスを止めないためのDevOpsを推進する中で、QAの職域からは自動テストによる早期検知を重視
- UIテスト（E2E的な自動化）とAPIレベルのテスト（チェンジトラッキングやデグレ防止）を2本立てで構築
具体的なポイント
- UIテストには「MagicPod」を導入し、リリース後のイグニッションテストとして活用
- APIテストはデイリーのヘルスチェックとして運用し、本番の実データやシナリオを継続的に検証
- 自動化に向けた学習や保守コストの問題はあるものの、クーポンなど基幹サービスが増える中でリスクを最小化する効果が大きい
「膨大なトラフィックと業務要件を抱えるイオングループを支える基盤が、テスト自動化によってスケールし続ける」というのが印象的なLTでした。
LT② 動作確認やテストで漏れがちな観点3選（ファインディ / 戸田 千隼 氏）
ファインディの戸田さんは、テックリードとして**「不具合を発生させない」よりも「不具合を早期に発見し、即座に修正できる」**体制の重要性を強調。そのうえで、しばしば見落としがちなテスト観点として3つを紹介しました。
見落としがちな3つの視点
- 人名・日付・金額のミスは絶対に避ける
- 軽微なずれでもビジネスや信用に大きく響く
- メールや印刷物など後から修正ができないケースでは、指差し確認を徹底して誤りを減らす
- 本当にデータベースが更新されているか
- 画面に「更新しました」と出ていても実は失敗している可能性がある
- 変更後に再読み込みして結果をチェックする、いわゆる再表示テストが欠かせない
- 日時チェックをフロントエンドだけに頼らない
- 端末の時刻設定を操作すると公開前の情報が閲覧できるリスクがある
- サーバサイドの時刻を参照するなどの対策が必須
「どんなに高度なテストフレームワークを導入しても、結局はヒューマンエラーやシンプルな指差し確認を怠ったせいで問題が発生するケースは多い」というリアルな事例が、多くの共感を集めていました。
LT③ みんなで品質担保するための開発プロセス（フリー / 本多 顕成 氏）
フリー株式会社の本多さんは**「開発とQAを分断しない」**アプローチを実践することで、テスト工程に依存しすぎない品質担保を実現していると説明。開発スピードを2倍にするための体制づくりが背景にあるそうです。
各工程で適切な品質保証を
- 従来、企画→設計→実装→システムテストという直線的なプロセスだった
- 後工程で不具合が見つかると修正コストが膨大になる
- 企画・要件定義段階からQAが入って、曖昧さを排除する仕組みを導入
要求要件一覧とミニポチ会
- 要求要件一覧: 企画（PRD）と詳細設計（Design Doc）のあいだに、要求と要件を明確に洗い出すドキュメントを作成
- それをQA・エンジニア・PM・デザイナー等が共通認識としてレビューし、「これならテスト可能だよね」という状態にしてから開発へ
- 開発完了後、本格的なテスト開始前に「ミニポチ会」を開催し、ストーリーごとに短時間で実装確認を行う
結果として、後工程で発覚するバグが減り、リードタイムが13％圧縮されたというデータも出ているとのこと。「品質担保はQAの仕事」という従来型の認識を脱却し、全員参加で不具合を減らしていく姿勢が大変興味深いLTでした。
LT④ リスクベースドテストの実践効果 〜実行テストケース数を劇的に削減！（Gunosy / 興梠 直子 氏）
最後に登壇したGunosyの興梠さんは、スマートフォンアプリのQAとしてリスクベースドテストの導入を進め、大幅にテスト工数を削減しながら品質を落とさずに済んだ実践事例を紹介しました。
リスクベースドテストの背景
- 会期テスト（既存機能の回帰テスト）の件数が機能増加に伴い肥大化
- 「テスト工数が高止まりし、リリースごとに負荷が厳しくなる」といった課題があった
- そこで、不具合発生時の影響度 × 使用頻度の評価を組み合わせて、テストケースにリスクレベルを設定
具体的な取り組み
- リスクレベルS / A / Bなどを定義し、Sに該当するケースは必ず実施、AとBは状況によって選抜
- 対象端末数もティア1・ティア2・ティア3のように分け、全端末で全ケースを繰り返さずに、端末の優先順位を考慮したうえでケースを配分
- 結果、Androidでは実行テストケース数が40〜50％削減され、品質低下もなかった
しかも運用しながら見直しサイクルを回し、「ユーザー行動やサービス戦略によってリスクレベルを修正」するのが肝だとのこと。テスト自動化とあわせて活用すれば、さらに開発チーム全体のリソースを有効活用できると考えられます。
イベントを終えて —— テスト設計がもたらす未来
4つのLTを通じて見えてきたのは、「テスト」と「品質保証」はチーム全体で取り組むものという共通認識です。大規模システムでも、段階的に自動化やリスク指向テストを導入すれば、リリースサイクルが短くても十分に品質を確保できる可能性があることが証明されました。
さらなる品質改善への展望
- 品質担保はQAだけの仕事じゃない
- フリー社の例のように、企画・設計・実装フェーズからみんなで品質を意識することで後戻りを減らす
- 自動化＋人間の指差し確認
- 戸田さんが指摘したように、最終的な確認で人が担う役割を明確化するとミスを最小化できる
- リスクベースドテストで重点を絞る
- 機能・端末・重要度を仕分けし、必要十分なテストを効率よく行うのがカギ
- DevOpsとの連動
- スパイク状の開発であっても継続的にテストを回し、デグレを防ぐ
現場のリアルな事例から得られる学びは大きく、参加者からは「さっそく来週の定例で試してみたい」「リスク評価の仕方が具体的にイメージできた」といった声が続々届きました。
品質はどうしても開発の“最後”に考えられがちですが、今回の登壇者は皆「早く気づけば安く修正できる」ことを証明していました。逆に言えば、“不具合を隠して本番へ直行”は“最悪の手段”にほかならないわけです。
今後ますます短期リリースや高品質が求められる中、今日のような知見を互いにシェアし合い、さらに強固で柔軟なテストプロセスを確立していくことが、多くの開発チームの鍵となるでしょう。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
