🤌
みんなで学ぶ！品質改善を加速する テスト設計と管理手法LT レポート
公開
2025-04-03
更新
2025-04-03
文章量
約2987字
2025年1月29日、「みんなで学ぶ！品質改善を加速する テスト設計と管理手法LT」というイベントがオンラインで開催されました。各社におけるテスト観点やQA組織の取り組みが熱く語られ、実践的な知見が豊富に詰まったLTが連続。どの発表も、品質の担保と開発スピードの両立を目指す上で、すぐに取り入れたくなるアイデアが満載でした。本レポートでは、4名の登壇内容と、その中で印象的だったポイントをまとめます。
イベント概要
当日は4名の登壇者が、それぞれの会社やプロダクトで実践しているテスト設計・管理手法について、具体的な事例とともに発表しました。以下が、登壇者と発表タイトルです。
LT①：イオンスマートテクノロジー株式会社 白江大輔さん 「DevOpsに向けたテスト方針」
LT②：ファインディ株式会社 戸田千隼さん 「動作確認やテストで漏れがちな観点3選」
LT③：フリー株式会社 本多顕成さん 「みんなで品質担保するための開発プロセス」
LT④：株式会社Gunosy 興梠直子さん 「リスクベースドテストの実践効果 〜実行テストケース数を劇的に削減！」
最後にはテスト管理ツールの事例紹介として、テクマトリックス株式会社の中田さんから「TestRail」の機能と活用イメージが紹介されました。
LT①：「DevOpsに向けたテスト方針」
取り組みの背景
イオンのDX推進を担うイオンスマートテクノロジーでは、グループ全体で展開される大規模サービスの品質をどのように支えるかが重要なテーマです。そこでは、DevOps文化を社内で確立させるために、自動テストを中核とする新たなQAプロセスづくりを進めているとのこと。圧倒的に多いトランザクション数や、実行が長引くバッチ処理など、“大規模かつ負荷が高い”環境ならではのQA体制が求められていました。
自動テスト導入のポイント
E2Eテスト：UIを含む全体的な検証が重要視され、ツールとしてはMagic Podなどを導入。リリース直前のイグニッションテストとして機能。
APIレベルの自動化：日次のヘルスチェックを想定し、APIテストを自動実行。「機能改修の影響範囲チェックにも有効」と強調されていました。
成果と展望
自動テストの浸透によって、テスター自身のテスト設計スキルやドキュメント整備が進んだ例が紹介されました。今後は、非機能面（例：バッチ処理のオペレーション負荷やパフォーマンス）にも踏み込んだ品質評価を継続しながら、DevOpsが掲げる高速かつ安全なリリースサイクルを実現していく、とのことです。
LT②：「動作確認やテストで漏れがちな観点3選」
大枠の姿勢
続いてファインディの戸田さんは「バグそのものを悪とするのではなく、バグを気づかずリリースしてしまうことこそが本質的な問題」という視点を提示。とにかく「はやく気づき、すぐ直す」ことが肝要だと強調しました。
漏れがちな観点3選
人名・日時・金額のように絶対間違えられない情報 1円や1日のズレですら致命的な不具合となる可能性があるため、画面表示や通知メール等を指差し確認することが基本中の基本。
“実際に更新されたか”までのチェック 更新ボタンを押して「保存しました」の表示が出ても、本当にDBが書き変わったかが確認できていないケースは多い。画面リロード後や再表示で正しく変更されているかをセットで検証。
日時チェックの仕組みがフロント依存になっていないか フロントの端末時刻を基準に公開日時を判断すると、端末の時刻を変えれば内容が閲覧できてしまうなどのリスクがある。重要性の高い機能であれば、サーバーサイドの時刻を利用すべき。
まとめ
テスト管理やプロセス以前に、“人間が見落としがちな確認観点を徹底して潰す”大切さを戸田さんは説きました。極端に言えば、最低限「人名や日時のずれは許容されない」といった基本を押さえれば、不幸なバグは大幅に減らせるとのことです。
LT③：「みんなで品質担保するための開発プロセス」
新たな開発プロセス構築の背景
フリー株式会社の本多さんからは、開発リリースがさらに増大していく中でどのように品質を保ち続けるか、その仕組みを作る取り組みが紹介されました。新機能やサービスに着手する際、従来の後工程（システムテスト）依存の品質保証では、修正コストが膨張する恐れがあったのです。
具体的アプローチ
要件定義段階でのレビュー強化 要求要件一覧として、要求・要件・異常系・副作用などを一元管理する資料を作成。QAだけでなく、PMやエンジニアも参加するレビューを通して、後工程での不具合を未然に防ぐ。
ミニポチ会 実装完了したストーリーをテスト工程に渡す前に、15～20分程度で「要件どおりか？」を確認する場を設け、不具合を早期に発見・修正。
みんなで品質担保 QAが一方的に担うのでなく、PM・エンジニア・UXなど全員が品質視点を持つことを徹底。これによってリードタイム短縮と品質向上の両立を目指す。
成果と今後
既に複数チームでの試験運用を進めており、実リリース時のバグや後戻りが減っているとのこと。今後はフリー全社へ展開し、さらなる開発速度の向上と品質確保を両立する狙いがあるそうです。
LT④：「リスクベースドテストの実践効果 〜実行テストケース数を劇的に削減！」
課題と狙い
Gunosyの興梠さんからは、会期テストのテストケースが機能追加のたびに膨れ上がるという問題を、リスクベースドテストによって解決した事例が紹介されました。低リスク領域に時間を使わず、高リスク領域にフォーカスすることで、品質を落とさずに総テスト時間を縮める手法です。
リスクレベル付け & 端末優先度設定
テストケース単位でリスクレベル（S/A/Bなど）を設定 影響度×使用頻度のマトリクスで決定し、リスクが高い領域のみ毎回実施、低い領域はSDKアップデートなど特定条件時のみ実施。
端末にもティア分けを適用 OSバージョンや画面サイズごとに複数端末を用意せず、優先度の高い端末を中心に片方では半分のケース、もう片方ではもう半分、と分散して行う。
効果
Androidで40〜50%、iOSで20〜25%の実施テストケース削減を達成。
品質に悪影響はなく、リリース後のバグも増加していない。
今後はリスクレベルの定期的な見直しが課題となる。
全体を踏まえた感想
4つの事例はいずれも、 「全工程をQAだけに任せない」 姿勢が印象的でした。つまり、企画・設計で要件をしっかり固める仕掛けづくり、バックエンドやフロントのチームと早い段階で不具合を発見するためのミーティング、リスク評価や観点の洗い出しを通じて“本当にテストすべき箇所”を冷静に選ぶなど、開発チーム全員が品質担保に当事者意識を持つことが鍵になっています。
また、クラウド移行やDevOps導入を契機に、自動化をフル活用する例も少なくありません。大規模なトランザクションや複雑な業務要件でも、人間が見落としがちなポイントは指差し確認で徹底しつつ、自動テストが可能な箇所は積極的に仕組み化し、チーム全体のリリース速度を上げる──そのための各社のノウハウや試行錯誤は、まさに「みんなで学ぶ！」のタイトルにふさわしい学びの多い時間でした。
Yardでは、テック領域に特化したスポット相談サービスを提供しています。
興味がある方は、初回の無料スポット相談をお申し込みください。
また、資料請求やお問い合わせもお待ちしております。テック領域の知見を獲得し、事業成長を一緒に実現していきましょう。
