こんにちは！セーフィーでQAエンジニアをしている福山です。 「シフトレフト」という言葉を本気で実践しようとしたとき、私は思わぬ落とし穴にハマりました。 それは、上流工程に出ていくほど 「品質の言葉」だけでは仲間になれず、むしろ“後から検証しに来るブレーキ役”に見えてしまう ことがある、ということです。 この記事では、一般社団法人UXインテリジェンス協会が提供するUX検定の学習を通じてデザイナーとの「共通言語」を少しずつ獲得し、上流での対話が回り始めた経験を共有します。 🎯 この記事は以下のような方に向けた内容です シフトレフト推進で、他部署との対話が噛み合わないと感じるQAエンジニ

こんにちは、LIFULLでシニアエンジニア兼エンジニアマネージャーをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにて、マネジメントを担当しています。 最近のお気に入りはSupabaseです。 今回は、私たちが1年半にわたって磨き上げてきたGitHub完結型リリースフロー「Beezy」が、ついに弊社の一番メインのLIFULL HOME'Sシステム群に採用されたという大きなマイルストーンを迎えたことをご報告します。 これまでの歩み 🐝 「Beezy」という名前に込めた想い 名前の由来 なぜハチなのか なぜEasyなのか Beezyが目指すもの なぜメインシステム群への採用が重要なのか 本質的な課題は「スケールの壁」 Beezyが目指す3つの柱 1. 集約化：すべての情報をGitHubに 2. 自動化：人間の判断に頼らないしくみ 3. 加速化：価値をより早くユーザーへ Beezyの主要機能 承認フロー Issue駆動開発 リリースチェック 自動リリース リリース依存関係管理 Hotfixフロー 自動バージョンアップ 導入までの険しい道のり 最初の壁：既存フローへの愛着と不安 第二の壁：既存運用を損なわないための工夫 リリースカンバン機能の実装 リリース履歴ダッシュボードの作成 JIRAとの連携維持 第三の壁：技術的な課題の山積 1. 複数リポジトリ間の依存関係 2. 多様なリポジトリ形態への対応 3. 導入方法の簡略化 4. パフォーマンスの最適化 第四の壁：組織的な合意形成 ステークホルダーの多様性 合意形成のプロセス 1年半の成長の軌跡 フェーズ1：言語化とシステム化（最初の3ヵ月） フェーズ2：流通チームでの実証と汎用化（次の3ヵ月） フェーズ3：流通チーム以外への展開（次の6ヵ月） フェーズ4：メインシステム群への導入準備（次の6ヵ月） フェーズ5：メインシステム群への導入完了（現在） 導入を成功させた5つの要因 1. スモールスタートと段階的な展開 2. 早い段階での汎用化とリポジトリ分離 3. 複数マーケットでのテストマーケティング 4. 既存の運用を尊重する姿勢 5. 丁寧なサポート体制 組織全体への波及効果 開発者の声 今後の展望 さらなる進化に向けて まとめ これまでの歩み 私たちのリリースフロー改革の取り組みは、これまでに2回ブログで紹介してきました。 1本目の記事では、リリースフローをGitHubに集約し、自動化を図った初期の取り組みについてお伝えしました。 www.LIFULL.blog 2本目の記事では、その後の進化として、Chrome拡張機能の開発や自動リリース機能の実装など、さらなる改善について紹介しました。 www.LIFULL.blog そして今回、1年半のスモールスタートでの検証を経て、ついに弊社の一番メインのシステム群への採用が決定しました。 今回は導入までの行ってきたことを紹介させていただきます。 🐝 「Beezy」という名前に込めた想い 本格的な展開を前に、私たちはこのリリースフローシステムに「Beezy」という名前を付けました。 名前の由来 Beezy（ビージー）は、 Bee（ハチ）とEasy（楽）を組み合わせた造語 です。 なぜハチなのか ハチは自然界で 最も効率的で組織的な生き物 の一つです。巣の中では、それぞれのハチが明確な役割を持ち、無駄のない動きで協働しています。女王蜂、働き蜂、それぞれが自分の責務を果たすことで、巣全体が機能します。 このリリースフローも同じです。エンジニア、CodeOwner、G長（グループ長。開発チームの責任者）、PJ承認者（プロジェクト単位でリリース可否を判断する役割で、主に企画担当者が担う）、リリーサー（本番環境へのデプロイを実行する担当者）、企画担当者、デザイナー。 それぞれが自分の役割を果たし、GitHub上で一つの「巣」として機能します。 リポジトリごとにリリースに必要なactionsを適用していくことで、最終的に完璧なリリースパッケージが完成する。まさにハチの巣の構造そのものです。 また、ハチは 「集約」の象徴 でもあります。花から花粉を集め、一つの巣に集約し、蜂蜜という価値を生み出す。私たちも、 JIRAやSlack、Googleスプレッドシートに散らばっていた情報をGitHubという一つの巣に集約し、価値創造を加速させる基盤 を作りました。 なぜEasyなのか このリリースフローの最大の成果は、 「楽になった」 ことです。 リードタイムが最大60%短縮された という数字以上に、 承認者やリリーサーの心理的負担が劇的に軽減 されました。情報を探し回る手間、手作業でのチェック、見落としへの不安。これらがGitHub Actionsによる自動チェックで解消され、 人間は本当に必要な判断だけに集中できる ようになりました。 「Easy」は単なる「簡単」ではなく、 「気楽に、安心して」リリースできる状態 を意味しています。 Beezyが目指すもの Beezyは、 ハチのように効率的で組織的でありながら、誰もが気楽にリリースできる世界 を目指しています。 将来的にはリリーサーすら不要になる完全自動化を見据えながらも、今この瞬間、 チーム全員がリリースを「重荷」ではなく「日常」として扱えるようになること 。それがBeezyの願いです。 Busy（忙しい）ではなく、Beezy（ハチのように効率的で楽）なリリースを。 なぜメインシステム群への採用が重要なのか 本質的な課題は「スケールの壁」 私たちがBeezyを開発した当初、まずは小規模なシステムでスモールスタートを切りました。これは正しい判断でした。新しいしくみを導入する際には、リスクを最小化しながら検証を重ねることが重要だからです。 しかし、本質的な課題は「メインシステム群でこそ顕在化する」ということを、私たちは理解していました。 リリース頻度の高さ : メインシステムは日々多くの機能追加や改善が行われ、リリース頻度が圧倒的に高い 関係者の多さ : 開発者、企画担当者、デザイナー、リリーサーなど、多くのステークホルダーが関わる 承認プロセスの複雑さ : ビジネスへの影響が大きいため、承認プロセスも慎重にならざるを得ない 情報の分散 : JIRAとGitHubを行き来する手間、Slackでの確認など、情報が分散している つまり、メインシステム群でこそ、Beezyの真価が問われるのです。 Beezyが目指す3つの柱 Beezyの開発において、私たちが一貫して追求してきたのは以下の3つです。 1. 集約化：すべての情報をGitHubに 従来の課題 : リリースチケットはJIRA コードレビューはGitHub 承認依頼はSlack リリース履歴は別のツール 情報が分散していると、承認者やリリーサーは必要な情報を探すだけで多くの時間を費やしてしまいます。 Beezyのアプローチ : リリースに関わるすべての情報をGitHubのPRとIssueに集約 PR作成時に自動的に関連Issueが作成され、必要なタスクがすべて可視化 リリースカンバン機能により、GitHub上で進捗管理が完結 リリース履歴ダッシュボードで、過去のリリースも追跡可能 Before After 2. 自動化：人間の判断に頼らないしくみ 従来の課題 : 承認者は手動でチェックリストを確認 リリーサーは目視でリリース可否を判断 リリース忘れは人間の記憶に依存 Beezyのアプローチ : GitHub Actionsによる自動チェック 必要な承認がそろっているかを自動検証 リリース可能な条件を満たしたPRを自動検出 リリース忘れを防ぐ自動通知システム 自動リリース機能により、条件が整い次第リリーサーの介入なしでリリース 3. 加速化：価値をより早くユーザーへ 従来の課題 : リリースまでのリードタイムが長い 週2回程度のリリース頻度 承認からリリースまで数日かかることも Beezyのアプローチ : リードタイム中央値を最大60%短縮 1日2回のリリースが可能に 承認からリリースまで数時間に短縮 Beezyの主要機能 Beezyは、30以上のGitHub Actionsで構成された包括的なリリースフローシステムです。主要な機能を紹介します。 承認フロー LIFULLでは、本番環境へのリリース前に「G長承認（開発チーム責任者による技術的な承認）」と「PJ承認（企画担当者によるプロジェクト観点でのリリース可否判断）」という2段階の承認プロセスを設けています。これをGitHub上で完結させます。 G長承認・PJ承認のGitHub完結化 : PRのコメントで /G長承認OK 、 /PJ承認OK と書くだけで承認完了 適切な権限を持つ人のみが承認可能（GitHubチームで管理） Chrome拡張機能により、ボタン一つで承認コメントを投稿 自動承認スキップ : ドキュメントのみの変更など、プロダクトに影響のないファイルのみの変更は自動的に skip-release-check ラベルを付与 .dockerignore または .releasecheckignore でスキップ対象を定義可能 Issue駆動開発 SubIssueによるタスク管理 : PR作成時に、Epic IssueとSubIssueが自動生成 開発チェックシート、テスト仕様書、デザインチェックなど、必要なタスクを自動で分解 SubIssueの完了状況がPR上に進捗バーとして表示 すべてのSubIssueが完了すると、自動的に subissue-close ラベルを付与 リリースチェック ステージング確認・本番確認の自動化 : リリースPR上でチェックボックスをクリックするだけで確認完了 確認忘れを防ぐ自動通知機能 定時実行により、未確認のリリースを検出してSlack通知 自動リリース 条件が整い次第、自動的にリリース : ステージング確認・本番確認が完了したPRを自動検出 Googleカレンダーと連携してリリース可能日を判定 指定されたスケジュールで自動実行 リリース依存関係のチェックにより、順序を守ったリリースを実現 リリース依存関係管理 マイクロサービス間の依存関係を自動制御 : 設定ファイルで依存関係を定義 依存先のリリースが完了するまで、後続のリリースを自動的にブロック システム障害を防ぐための安全装置 Hotfixフロー 緊急リリースにも対応 : 通常のリリースフローとは別の、簡略化されたHotfixフロー Hotfix後のreverse merge PR（本番ブランチからdevelopへのPR）は自動承認 緊急時の対応をスムーズに 自動バージョンアップ メンテナンスの自動化 : Beezyのバージョンアップ時に、自動的にPRを作成 各リポジトリでの手動更新作業が不要 常に最新の機能とバグフィックスを利用可能 Beezy Flow 導入までの険しい道のり 最初の壁：既存フローへの愛着と不安 メインシステム群への導入を提案した際、最初に直面したのは「既存フローへの愛着」と「新しいフローへの不安」でした。 既存フローの強み : 長年の運用で培われた安定性 チーム全員が慣れ親しんだ手順 JIRAを中心とした統一的な管理 問題発生時の対応パターンが確立されている これらはけっして軽視できるものではありません。私たちは、この既存フローの良さを理解したうえで、Beezyを提案する必要がありました。 チームからの懸念 : 「GitHubに移行して、本当に大丈夫なのか？」 「企画担当者やデザイナーがGitHubを使えるようになるのか？」 「今までのリリース履歴はどうなるのか？」 「リリースカンバンでの進捗管理はどうするのか？」 「移行期間中、二重運用になって逆に負荷が増えるのでは？」 これらの懸念は、すべて正当なものでした。そして、私たちはこれらの懸念に一つ一つ真摯に向き合う必要がありました。 第二の壁：既存運用を損なわないための工夫 Beezyの開発で最も時間をかけたのが、「既存の運用を損なわない」ための機能開発でした。 リリースカンバン機能の実装 既存の運用 : JIRAのカンバンボードで、リリース予定のチケットを管理し、進捗を可視化していました。これは、リリーサーや企画担当者にとって、リリース状況を一目で把握できる重要なツールでした。 Beezyでの実現 : GitHub Projectsを活用したリリースカンバンの実装 PRの状態に応じて自動的にカードが移動 ラベルによる視覚的なステータス表示 フィルタリング機能により、特定の条件のPRのみを表示 試行錯誤の過程 : 最初は、GitHub Projectsの標準機能だけで実現しようとしましたが、既存のJIRAカンバンとの操作感の違いが大きく、ユーザーからの抵抗がありました。そこで、GitHub Actionsを使って、JIRAに近い操作感を実現するための自動化を追加しました。 リリース履歴ダッシュボードの作成 既存の運用 : 過去のリリース履歴を追跡し、「いつ、何がリリースされたか」を確認できることは、障害発生時の原因特定や、機能のリリース時期の確認に不可欠でした。 Beezyでの実現 : マージされたリリースPRの一覧表示 リリース日時、リリース内容、担当者などの情報を集約 検索・フィルタリング機能 各リリースに含まれる変更の詳細へのリンク 試行錯誤の過程 : 当初は、GitHubのリリース機能を使おうとしましたが、私たちの運用フローとは合いませんでした。そこで、GitHub APIを活用して、独自のダッシュボードを構築しました。これにより、既存の運用で必要だった情報をすべて提供できるようになりました。 JIRAとの連携維持 既存の運用 : すべてのプロジェクトがGitHubに移行できるわけではなく、一部のチームはJIRAでの管理を継続する必要がありました。 Beezyでの実現 : JIRAチケットとGitHub PRの相互リンク JIRAチケットの状態をGitHub上でも確認可能 段階的な移行をサポート これらの工夫により、「既存の運用を損なわない」という約束を守ることができました。 第三の壁：技術的な課題の山積 既存運用への配慮と並行して、技術的な課題にも取り組む必要がありました。 1. 複数リポジトリ間の依存関係 メインシステム群は、複数のマイクロサービスで構成されており、リリース順序に依存関係があります。 課題 : A→B→Cの順でリリースしなければならない場合、順序が逆転するとシステム障害につながります。 試行錯誤 : 最初は手動でのチェックを考えましたが、それでは自動化の意味がない 次に、依存関係を設定ファイルに記述する方式を試しましたが、メンテナンスが煩雑 最終的に、リリースブロック機能（release_block）を実装し、依存先のリリースが完了するまで後続のリリースを自動的にブロックするしくみを構築 実装のポイント : 依存関係を設定ファイルで定義することで、自動的にリリース順序を制御できるようになりました。 2. 多様なリポジトリ形態への対応 メインシステム群には、モノリス、マイクロサービス、フロントエンド/バックエンド分離など、多様な構成のリポジトリが存在します。 課題 : すべてのリポジトリ形態で同じ操作感を実現する必要がある。 試行錯誤 : 最初は個別にワークフローを作成していましたが、メンテナンス性が悪化 共通化を進めすぎると、柔軟性が失われる バランスを取るために、設定ファイルベースのアプローチを採用 実装のポイント : release_actions.config.yaml という設定ファイルを導入し、リポジトリごとに必要な機能を選択できるようにしました。 workflows : # G長承認とPJ承認をGitHub上で行う - id : approval_on_github enabled : true # 自動リリース機能 - id : auto_release enabled : true # Issue駆動開発 - id : issue_driven_development enabled : true inputs : ORGANIZATION : lifull REPOSITORY : your-repository-name PRODUCTION_BRANCH : main # その他、リポジトリごとの設定 この設定ファイルを用意した後、 renovate_actions ワークフローを実行することで、必要なワークフローファイルが自動生成されます。これにより、導入の手間を大幅に削減できました。 3. 導入方法の簡略化 課題 : 当初、対話形式のCLIツールを開発しましたが、以下の問題が発生しました： ローカル環境でのセットアップが必要 Node.jsのバージョン依存 チーム全員が同じ手順を踏む必要がある 試行錯誤 : CLIツールは便利でしたが、導入のハードルが高いという問題がありました。そこで、より簡単な方法を模索しました。 最終的な解決策 : release_actions.config.yaml と renovate_actions ワークフローを組み合わせた方式に変更しました。 導入手順 : テンプレートから release_actions.config.yaml と release_actions_renovate_actions.yaml をコピー release_actions.config.yaml を編集して、必要な機能を有効化 GitHubのActions画面から renovate_actions ワークフローを手動実行 自動的にPRが作成され、必要なワークフローファイルがすべて生成される この方式により、ローカル環境のセットアップが不要になり、導入のハードルが大幅に下がりました。 4. パフォーマンスの最適化 メインシステム群では、1日に数十件のPRが作成されることもあります。 課題 : GitHub Actionsの実行回数が増えると、コストとパフォーマンスの問題が発生します。 試行錯誤 : 不要なワークフローの実行を減らすためのフィルタリング キャッシュの活用 並列実行の最適化 実装のポイント : 変更されたファイルに応じてワークフローをスキップするしくみを導入しました。これにより、ドキュメントのみの変更では、重いチェック処理をスキップできるようになりました。 第四の壁：組織的な合意形成 技術的な課題以上に難しかったのが、組織的な合意形成でした。 ステークホルダーの多様性 開発者 : 新しいツールへの学習コスト、既存の開発フローの変更 企画担当者 : GitHubアカウントの作成、新しい承認フローへの適応 リリーサー : 役割の変化への不安、新しいツールの習得 マネジメント層 : 移行リスクへの懸念、投資対効果の検証 合意形成のプロセス 1. 小規模チームでの実証（3ヵ月） : 協力的なチームで実証実験を実施 週次で振り返りを行い、問題点を洗い出し フィードバックをもとに機能改善 2. 成果の可視化（6ヵ月） : リードタイムやリリース頻度の改善を数値で示す 開発者、企画担当者、リリーサーそれぞれの声を収集 定量的・定性的な成果をレポートにまとめる 3. 段階的な展開計画の策定（3ヵ月） : 一気に移行するのではなく、段階的な計画を提示 リスクの高いシステムは後回しにする 移行期間中のサポート体制を明確化 4. 充実したサポート体制の構築（継続） : 詳細なドキュメントの整備 ハンズオンセッションの定期開催 Slackチャンネル(リリースフローに関するすべての窓口)でのリアルタイムサポート Chrome拡張機能による操作の簡略化 特に重要だったのは、「既存の運用を尊重する」という姿勢を明確に示すことでした。リリースカンバンやリリース履歴ダッシュボードの実装は、この姿勢を具体的な形で示すものでした。 1年半の成長の軌跡 Beezyの開発は、決して一直線ではありませんでした。多くの失敗と学びを経て、現在の形にいたっています。 タイムライン フェーズ1：言語化とシステム化（最初の3ヵ月） 目標 : 現在のリリースフローの構成要素を言語化し、システム化する 取り組み : このフェーズでは、とにかく既存のリリースフローを徹底的に分解し、理解することに注力しました。 既存のリリースフローの各ステップを洗い出し それぞれのステップの目的と必要性を言語化 一つのリポジトリを対象に、大量のワークフローを作成 少しずつ検証を進めながら、システム化の可能性を探る 直面した課題 : 暗黙知として存在していたルールの発見 「なぜこの手順が必要なのか」を理解すること GitHub Actionsでどこまで実現できるかの見極め ワークフローの数が増えすぎて管理が煩雑に 学んだこと : リリースフローは想像以上に複雑で、多くの暗黙知が存在する すべてを一度に自動化しようとすると失敗する 小さく検証を重ねることの重要性 ワークフローの整理と構造化の必要性 この3ヵ月は、地味で泥臭い作業の連続でした。しかし、この期間に得た理解が、その後の開発の基盤となりました。 フェーズ2：流通チームでの実証と汎用化（次の3ヵ月） 目標 : 実際のチームで使ってもらい、汎用化する 取り組み : 私の所属する流通チームの企画担当者とエンジニアに説明し、マイクロサービスの1リポジトリで導入させてもらうことを握りました。 流通チームの企画担当者とエンジニアへの説明会を実施 マイクロサービスの1リポジトリで導入 実際に使ってもらいながら、フィードバックを収集 機能開発とユーザビリティ改善を並行して実施 汎用化への挑戦 : このタイミングで、ほかの流通リポジトリにも導入するつもりだったので、まずは今の1リポジトリに作ったワークフローをcomposite actionsとして汎用化することに全力を尽くしました。 個別のワークフローをcomposite actionsに分解 共通部分と個別部分を明確に分離 設定ファイルによるカスタマイズのしくみを構築 composite actions用の専用リポジトリを作成し、移設 この専用リポジトリの作成が、後の展開において非常に重要な役割を果たすことになります。 他の流通リポジトリへの展開 : 汎用化ができ次第、ほかの流通リポジトリでも検証を開始し、効果を検証しました。 直面した課題 : 企画担当者のGitHub習熟度のばらつき リポジトリごとの微妙な運用の違い composite actionsの設計の難しさ ドキュメントの不足 学んだこと : 実際のユーザーからのフィードバックの価値は計りしれない 汎用化は想像以上に難しい 「使いやすさ」は技術的な正しさとは別の次元 ドキュメントとサポート体制の重要性 早い段階での汎用化とリポジトリ分離が、後の展開を容易にする この期間で、Beezyは「動くもの」から「使えるもの」へと進化しました。 フェーズ3：流通チーム以外への展開（次の6ヵ月） 目標 : 流通以外のチームでも使ってもらい、効果を確固たるものにする 取り組み : 機能改善も行いながら、マイクロサービスを運用しているほかのチームに、流通での結果をもとに導入の相談を持ちかけました。 流通チームでの成果をレポートにまとめる ほかのチームへのプレゼンテーションと導入相談 導入サポートを丁寧に実施 実際に使ってもらってアンケートを実施 改善の数字を確固たるものに テストマーケティングの効果 : 社内のさまざまなチームで先にテストマーケティングさせてもらっていたことが、後のメインリポジトリ導入において非常に大きな意味を持つことになります。 成果の可視化 : リリース頻度の向上 リードタイムの短縮 リリーサーの作業時間の削減 開発者、企画担当者、リリーサーそれぞれの満足度 直面した課題 : チームごとの運用の違いへの対応 「流通でうまくいったから」だけでは説得力が不足 導入サポートの負荷 機能改善と導入サポートの両立 学んだこと : 数字で示すことの重要性 定量的な成果だけでなく、定性的な声も重要 導入サポートは想像以上に時間がかかる 異なるチームでの成功事例が説得力を生む 複数のマーケットでの実績が、組織全体への認知度を高める この期間で、Beezyは「流通チームのツール」から「複数チームで使えるツール」へと進化しました。そして、メインシステム群への導入に向けた確信を得ることができました。 フェーズ4：メインシステム群への導入準備（次の6ヵ月） 目標 : LIFULL HOME'Sのメインリポジトリ群への導入を実現する 取り組み : いよいよLIFULL HOME'Sのメインリポジトリ群への導入相談と調整を開始しました。 組織的な調整 : ものづくり全体への導入相談 予算の確保 ステークホルダーとの合意形成 移行計画の策定 認知度の高さが後押し : いろんなマーケットで先にテストマーケティングさせてもらっていたので、いざメインリポジトリに導入するとなった時にも、多くの関係者はBeezyについて知ってくれていました。これは非常に大きなアドバンテージでした。 「あのリリースフローのことね」という認識がすでにあった 成功事例を知っている人が多かった 「使ったことがある」という人が組織内に点在していた 新しいツールへの抵抗感が大幅に軽減された 課題解決への注力 : とにかく課題解決に時間を費やして粛々と準備を進めました。 リリースカンバン機能の実装 リリース履歴ダッシュボードの作成 JIRAとの連携維持 複数リポジトリ間の依存関係管理 パフォーマンスの最適化 運用上の問題への対策 : 運用上の問題が発生しないように、ドキュメントの充実と告知もしっかり行いました。 詳細なドキュメントの整備 企画担当者向けガイドの作成 ハンズオンセッションの実施 Slackチャンネルでのサポート体制の構築 Chrome拡張機能の開発 直面した課題 : メインシステム群特有の複雑さ 既存フローへの愛着と新しいフローへの不安 多様なステークホルダーとの調整 移行リスクへの懸念 学んだこと : 大規模な変更には、技術以上に組織的な調整が重要 既存の運用を尊重する姿勢を示すことの重要性 丁寧な準備が成功の鍵 予算確保には明確な効果の提示が必要 事前の認知度が、導入のハードルを大きく下げる この期間は、技術的な開発よりも、組織的な調整と準備に多くの時間を費やしました。しかし、この準備があったからこそ、スムーズな導入が実現できました。 フェーズ5：メインシステム群への導入完了（現在） 目標 : メインシステム群への導入を完了させる 取り組み : 準備が整い、いよいよメインシステム群への導入を開始しました。 段階的な導入計画の実行 リアルタイムでのサポート 問題発生時の迅速な対応 継続的なフィードバックの収集と改善 成果 : そして今、メインリポジトリへの導入が完了しました。 品質の向上 : 人的ミスの完全排除 リリース品質の安定化 直面した課題 : 導入初期の混乱 予期しないエッジケース ユーザーの習慣を変えることの難しさ 学んだこと : 1年半の準備があっても、導入時には予期しない問題が発生する リアルタイムでのサポート体制の重要性 継続的な改善の必要性 成功は一つのマイルストーンであり、ゴールではない 導入を成功させた5つの要因 1年半の道のりを振り返ると、メインシステム群への導入を成功させた要因は、以下の5つだと考えています。 1. スモールスタートと段階的な展開 一気に大規模な変更を行うのではなく、小さく始めて段階的に展開したことが成功の鍵でした。 最初の3ヵ月: 1リポジトリでの検証 次の3ヵ月: 流通チーム内での展開 次の6ヵ月: 流通チーム以外への展開 次の6ヵ月: メインシステム群への導入準備 各段階で学びを得て、次の段階に活かすことができました。 2. 早い段階での汎用化とリポジトリ分離 フェーズ2の段階で、composite actions用の専用リポジトリを作成し、ワークフローを移設したことが、後の展開を大きく容易にしました。 メリット : 複数のリポジトリで同じアクションを使える バージョン管理が容易 機能追加や修正が一ヵ所で完結 導入リポジトリ側のメンテナンスコストが低い この判断により、ほかのチームへの展開やメインシステム群への導入が、スムーズに進みました。 3. 複数マーケットでのテストマーケティング いろんなマーケット（チーム）で先にテストマーケティングさせてもらっていたことが、メインリポジトリ導入において非常に大きな意味を持ちました。 効果 : 組織内での認知度が高まった 「使ったことがある」という人が点在していた 成功事例を知っている人が多かった 新しいツールへの抵抗感が大幅に軽減された いざメインリポジトリに導入するとなった時にも、多くの関係者はBeezyについて知ってくれていました。これは、説明コストを大幅に削減し、導入のハードルを下げる大きな要因となりました。 4. 既存の運用を尊重する姿勢 新しいシステムを導入する際、既存の運用を否定するのではなく、尊重する姿勢を貫きました。 リリースカンバン機能の実装 リリース履歴ダッシュボードの作成 JIRAとの連携維持 これらの機能は、技術的には必須ではありませんでしたが、ユーザーの信頼を得るために不可欠でした。 5. 丁寧なサポート体制 技術的に優れたシステムでも、サポートがなければ使われません。 詳細なドキュメント 企画担当者向けガイド ハンズオンセッション Slackチャンネルでのリアルタイムサポート Chrome拡張機能 特に、企画担当者向けガイドとChrome拡張機能は、技術者以外のユーザーにとって大きな助けとなりました。 組織全体への波及効果 メインシステム群での成功は、組織全体に波及効果をもたらしています。 ほかのチームへの展開 : 成功事例を見たほかのチームからも導入希望が相次いでいる ベストプラクティスの共有 : Slackチャンネルを通じた知見の共有 継続的な改善 : ユーザーフィードバックをもとにした機能追加や改善 開発者の声 開発者からの声 : 「ボタン一つで承認が終わるなんて！」 「タスクの進捗が自動で更新されるから楽」 「リリース忘れがなくなった」 「リリーサーを待つ必要がなくなった！」 企画担当者からの声 : 「GitHubは難しいと思っていたけど、ガイドがあるから安心」 「Chrome拡張機能のおかげで、承認が簡単になった」 「リリース状況が一目で分かるようになった」 リリーサーからの声 : 「定型作業から解放されて、より重要な仕事に集中できる」 「自動リリース機能のおかげで、リリース日の緊張感が減った」 「リリース履歴ダッシュボードで、過去のリリースも簡単に追跡できる」 今後の展望 さらなる進化に向けて メインシステム群への採用は、ゴールではなくマイルストーンです。私たちは今後も、以下の方向性で進化を続けていきます。 1. より多くのチームへの展開 : 全社的な展開 グループ会社も含んだLIFULLグループ全体への導入 2. 機能の継続的な改善 : ユーザーフィードバックをもとにした改善 新しい技術の導入 パフォーマンスの最適化 3. Developer Experienceのさらなる向上 : より直感的なUI/UX ドキュメントの充実 サポート体制の強化 まとめ 1年半のスモールスタートを経て、ついにメインシステム群への採用を実現できたことは、私たちにとって大きな達成感をもたらしています。 しかし、それ以上に重要なのは、この取り組みを通じて得られた「組織の変化」です。 技術者が創造的な仕事に集中できる環境 心理的安全性の向上 チームの幸福度の向上 これらは、単なる効率化では得られない、本質的な価値です。 私たちは「価値創造を加速させ続ける」ことをビジョンの一部に掲げています。今回のメインシステム群への採用は、そのビジョンに向けた大きな一歩だと確信しています。 「仕方がない」と思っているポイントこそ、変化の余地があるかもしれません。開発フローにおけるそれぞれの構成要素をあらためて見直し、最低要件を確認してみることで思わぬ改善の糸口が見つかる可能性があります。 今後も一歩ずつ改善を積み上げることで、リリースのさらなる加速化につなげていければと思います。 最後に、LIFULL ではともに挑戦し成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 https://hrmos.co/pages/LIFULL/jobs/010 https://hrmos.co/pages/LIFULL/jobs/010-9998

テスト管理は、テストケースを実行して結果を記録するだけの作業ではありません。 テストの目的や範囲を決め、設計・実行・不具合管理・進捗報告・終了判定までを一連の流れとして管理し、リリース判断に必要な情報を整理する活動です。 現場ではテスト終盤になって未実行ケースが大量に残ったり、不具合の重要度や優先度が整理されないままリリース判定を迎えたりすることがあります。 こうした状況を防ぐには、テスト開始前の計画、実行中の進捗管理、不具合の可視化、終了時の報告までを仕組み化しておくことが重要です。 そこで今回はテスト管理の基本的な考え方から、テスト計画、テスト分析・設計、テストケース準備、テスト実行、不具合管理、終了判定・報告までの実務フローを解説します。 あわせて、テスト計画書で決めるべき項目、進捗管理で見るべき指標、不具合管理のポイント、失敗を防ぐチェックリストも紹介します。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テスト管理ツール11製品の完全比較はこちら▼ 【2026年最新】テスト管理ツール11製品の徹底比較！【脱Excel】 テスト管理とは？実務で管理すべき範囲を整理する テスト管理の目的 テスト管理とは、テスト計画からテスト報告までの流れが、当初の目的やスケジュールに沿って進んでいるかを確認し、進捗・品質・リスクを見える状態にする活動です。 JSTQBでも、テストマネジメントの役割はテストプロセス、テストチーム、テスト活動のリーダーシップに責任を持ち、主にテスト計画、テストモニタリングとコントロール、テスト完了に重点を置くとされています。 実務では、単にテストケースの消化数を見るだけでは不十分です。 テスト目的・範囲、テスト観点、ケース数、工数、環境、データ、体制、進捗、不具合、終了基準、品質評価、結果報告までをまとめて管理します。 特にリリース前は、PMや開発責任者が判断できるよう、未実行ケース、重大不具合、残リスクを根拠として整理することが重要です。 テスト対象そのものだけでなく、組織、リスク、テストウェア、不具合も管理対象に含めることで、属人的な進め方を防ぎやすくなります。 テスト管理で扱う主な項目 テスト管理で扱う項目は、テストの目的や範囲だけではありません。 どの要件をどの観点で確認するのか、どのテストケースを誰がいつ実行するのか、必要な環境やデータは準備できているのか、不具合が出た場合に誰がどの基準で優先度を判断するのかまでを整理します。 JSTQBでは、テスト計画の作業成果物にテスト計画書、スケジュール、リスク情報、開始基準、終了基準などが含まれ、テスト実行の成果物にはテスト結果記録や欠陥レポートが含まれると整理されています。 つまり、テスト管理は「進捗表を更新する作業」ではなく、テスト活動全体の状態を説明できるようにするための仕組みです。 テスト目的、範囲、観点、ケース、環境、体制、不具合、終了基準、報告の流れをあらかじめ決めておくことで、担当者が変わっても同じ判断ができる状態に近づきます。 テスト管理とテスト実行の違い テスト実行は、テストケースに沿って操作し、期待結果と実結果を比較して、OK・NG・保留などの結果を記録する作業です。 一方、テスト管理は、テスト全体が目的通りに進んでいるかを監視し、遅延や品質リスクが見つかった場合に調整する活動です。 JSTQBでも、テストをする役割は主にテスト分析、設計、実装、実行に重点を置く一方、テストマネジメントの役割は計画、モニタリングとコントロール、完了に重点を置くとされています。 そのためテスト管理には実行担当者だけでなく、テストリーダー、QAリーダー、PMも関与します。 現場では「何件実行したか」だけでなく、「残っている未実行ケースにどれだけリスクがあるか」「NGや保留がリリース判断に影響するか」まで見て、関係者が判断できる形に整えることが求められます。 テスト管理の実務フロー 計画から終了作業までの進め方 1. テスト計画を立てる 最初に行うべきことは、テストの目的、対象範囲、対象外範囲を明確にすることです。 機能の正確性を重視するのか、性能、セキュリティ、互換性、業務シナリオを重視するのかによって、設計すべきテスト観点や工数は変わります。 ISO/IEC/IEEE 29119-2:2021では、テスト管理に関わるプロセスとして、テスト戦略と計画、テストモニタリングとコントロール、テスト完了が示されています。 テスト計画では、スコープ、リスク、体制、スケジュール、環境、開始基準・終了基準などを整理し、以降のモニタリングや完了判断の基準を作ります。 テスト計画では、スコープ、網羅性、優先度、入場基準、退場基準、終了基準、進捗確認方法、不具合対応のタイミング、カバレッジ管理方法を決めます。 ここが曖昧なままだと、テスト終盤に「どこまで確認すれば終わりなのか」が判断できなくなります。 初めてテストリーダーを担当する場合ほど、目的と範囲を計画書に落とし込み、PMや開発側と合意してから進めることが重要です。 2. テスト分析・設計を行う テスト計画の次は、要件定義書、仕様書、画面設計書、API仕様書、ユーザーストーリーなどのテストベースを確認し、テスト条件やテスト観点を洗い出します。 ISTQBでは、テストの目的として、要件や設計などの作業成果物を評価すること、欠陥を見つけること、テスト対象に必要なカバレッジを確保することなどが挙げられています。 実務では、すべての機能を同じ深さで確認するのではなく、リスクの高い機能、利用頻度の高い機能、障害発生時の影響が大きい機能を優先します。 たとえば決済、ログイン、権限、外部連携、データ更新処理は、軽微な画面文言よりも優先度が高くなりやすい領域です。 境界値分析、同値分割、デシジョンテーブル、状態遷移などのテスト技法を使い、必要なパターンを過不足なく設計します。 あわせて、テスト環境、前提条件、外部サービスの利用可否もこの段階で確認しておくと、実行開始後の手戻りを減らせます。 3. テストケース・テストデータを準備する テストケースは、担当者によって結果がぶれないように、手順、入力値、期待結果、前提条件を具体的に記載します。 「正常に動くこと」ではなく、「どの画面で、どの値を入力し、どの表示やデータ更新を確認するのか」まで書くことが大切です。 正常系、異常系、境界値、権限差分、業務シナリオを整理し、必要なテストデータ、アカウント、権限、外部連携条件も準備します。 自動化に向く繰り返し確認や回帰テストがある場合は、テストスクリプトの作成も検討します。 ただし、自動化は目的ではなく、確認品質と効率を上げるための手段です。 まずは手動で確認すべき観点と、繰り返し実行したい観点を分けると判断しやすくなります。 JSTQBでは、テスト設計や実装の成果物としてテストケース、テストチャーター、カバレッジアイテム、テストデータ、テスト環境などが整理されています。 4. テスト実行と証跡取得を行う テスト実行では、テストケースに沿って操作し、期待結果と実結果を比較します。 結果はOK、NG、保留、対象外などのステータスで記録し、期待値と異なる結果が出た場合は、不具合報告や原因調査につなげます。 重要なのは、成功した結果だけでなく、失敗、保留、対象外の理由も記録に残すことです。 後からリリース判定を行う際、「なぜ未確認なのか」「どの条件でNGになったのか」が説明できなければ、品質判断の根拠が弱くなります。 証跡としては、画面キャプチャ、操作ログ、APIレスポンス、出力ファイル、DB更新結果などを残します。 特に再現条件が複雑な不具合では、実行環境、アカウント、データ条件、発生時刻を記録しておくと、開発側の調査が進めやすくなります。 テスト結果は、期待値に合ったかどうかに関係なく残すことで、進捗管理、不具合管理、報告書作成の土台になります。 5. 終了判定・報告・振り返りを行う テストの終盤では、全テストケースの消化状況、未実行ケース、NGケース、保留ケース、未解決不具合、重大不具合、残課題を整理します。 そのうえで、計画時に定義した終了基準を満たしているかを確認します。 ISO/IEC/IEEE 29119-2でも、テスト管理プロセスにはテスト完了が含まれ、計画やモニタリングと並ぶ管理活動として扱われています。 テスト結果報告書では、単なる件数一覧ではなく、リリース判断に必要な情報をまとめます。 たとえば、テストケース消化率、重要機能の確認状況、未解決不具合の重要度と優先度、回帰テストの実施状況、残リスク、関係者への確認事項を整理します。 終了後は、テストケース、不具合傾向、環境トラブル、見積り差分、改善点をナレッジとして残します。 終了作業を省略せず、次回の計画や設計に活用できる形で資産化することが、再現性のあるテスト管理につながります。 テスト計画書で決めるべき項目｜属人化を防ぐ準備のやり方 テスト計画書が必要な理由 テスト計画書は、テスト範囲の抜け漏れを防ぎ、役割分担や判断基準を関係者で共有するための土台です。 計画書がないまま進めると、担当者ごとの判断に依存しやすくなり、テストケースの重複、対象外機能の混入、優先度の不一致、スケジュール遅延時の混乱が起こりやすくなります。 JSTQBでも、テストマネジメントはテストプロセス、チーム、活動のリーダーシップに責任を持つとされており、計画、モニタリング、完了を中心に活動します。 計画書には、テストの目的、範囲、前提条件、制約条件、観点、優先度、非機能要件、テスト方式、入力成果物、出力成果物、体制、承認者、スケジュール、環境、データ、不具合管理ルール、入場基準、退場基準、トレーサビリティを記載します。 これらを事前に決めることで、PM、開発者、テスターの認識をそろえやすくなります。 テスト目的・範囲の決め方 テスト目的を決める際は、何を確認できれば品質上の安心材料になるのかを明確にします。 機能の正確性を重視するのか、性能、セキュリティ、ユーザビリティ、業務継続性を重視するのかによって、必要なテスト観点は変わります。 対象機能と対象外機能を明確にし、重要度、利用頻度、障害影響度で優先順位を付けます。 範囲が曖昧なままだと、実行中に「この機能も見るべきではないか」という後戻りが発生しやすくなります。 また、要件とテストケースの対応関係を追えるようにしておくことも重要です。 JSTQBでは、テストベースとテストウェアの間のトレーサビリティを確立・維持することが、効果的なモニタリングとコントロールに重要とされています。 目的、範囲、優先度、トレーサビリティを計画時に固めることで、テスト実行中の判断が属人的になりにくくなります。 環境・ツール・スケジュールの決め方 テスト環境は、本番に近い条件をどこまで再現できるかを確認します。 OS、ブラウザ、端末、ミドルウェア、外部連携、権限、データ量などが本番と大きく異なる場合、テスト結果の信頼性に影響します。 テストデータについては、誰が、いつまでに、どの形式で、どの権限のデータを準備するのかを決めます。個人情報や機密情報を使う場合は、マスキングや利用ルールも必要です。 ツール面では、テスト管理ツール、課題管理ツール、チャット、ドキュメント管理場所を整理します。 ケース数が少ない場合はExcelでも運用できますが、複数人で同時に実行する場合や不具合件数が多い場合は、リアルタイムに進捗と不具合を確認できるツールの活用が有効です。 スケジュールは、設計、レビュー、環境準備、データ準備、実行、再テスト、報告の期間とマイルストーンを分けて定義します。 リスク・体制・成果物の決め方 テスト計画では、想定外の不具合、環境準備の遅れ、仕様変更、担当者不足、外部連携先の停止、テストデータ不足などのリスクを洗い出します。 リスクを事前に見える化しておくと、遅延や品質低下が起きたときに、スケジュール変更、要員追加、テスト範囲の見直し、優先度変更などを判断しやすくなります。 ISTQBの高度テストマネジメント領域でも、リスクベースドテストや品質リスクの識別、評価、軽減が扱われています。 体制面では、テスト設計者、実行者、レビュー担当、承認者、開発側窓口、PMとの報告経路を決めます。 成果物としては、テスト計画書、テスト仕様書、テストケース、不具合報告書、進捗レポート、テスト結果報告書を定義します。 リスク、体制、成果物を事前に決めることで、関係者が同じゴールを見ながらテストを進めやすくなります。 テスト実行中の進捗管理と不具合管理のやり方 進捗管理で見るべき指標 テスト実行中は、総テストケース数、実行済み件数、未実行件数、OK件数、NG件数、保留件数、対象外件数を日次で確認します。 さらに、ケース数ベースの消化率だけでなく、工数ベースの消化率、遅延日数、残工数も見ることが重要です。 1ケースあたりの実行時間がほぼ同じであれば件数ベースでも判断しやすいですが、複雑な業務シナリオや外部連携テストが含まれる場合、件数だけでは実態を見誤る可能性があります。 ケース数ベースの進捗は「消化ケース数÷総ケース数」、工数ベースの進捗は「消化済みケースの予定工数÷全ケースの予定工数」で見ます。 たとえば、簡単な画面確認を多く消化していても、重いシナリオテストが残っていれば、実質的な進捗は遅れている可能性があります。 ISO/IEC/IEEE 29119-2では、テストの測定結果を関係者へ伝達する活動もテストモニタリングとコントロールの一部として整理されています。 NG・保留ケースの扱い方 NGケースや保留ケースは、単純に未完了として数えるだけでは不十分です。 NGケースは、不具合修正にかかる日数、修正後の再テスト時間、関連機能への影響確認を見込む必要があります。 保留ケースは、仕様確認待ち、環境待ち、データ待ち、外部連携待ちなど、保留理由ごとに解消予定日と実行予定を決めます。 特に注意したいのは、消化率が高く見えても、NGや保留が多ければリリース判断には使いにくいという点です。 OKになるまでの残作業量を確認し、計画との差異を見て、スケジュール変更、要員追加、テストケースの優先度変更を検討します。 JSTQBでは、テストモニタリングとコントロールの成果物にテスト進捗レポートやコントロールのための指示文書が含まれると整理されています。 進捗管理は「予定通りか」を見るだけでなく、「予定通りに戻すには何を変えるべきか」を判断するために行います。 不具合管理で見るべき項目 不具合管理では、不具合件数だけでなく、重要度、優先度、発生機能、発生環境、発生原因、対応ステータス、クローズ状況、再現性、改修予定日、再テスト結果を管理します。 不具合票には、発生手順、期待結果、実結果、再現条件、証跡、環境情報を具体的に記録します。 これにより、開発側が調査しやすくなり、QA側も再テストの条件を揃えやすくなります。 重要度は利用者やシステムに与える影響の大きさ、優先度はどの不具合から先に対応するかの順番です。 たとえば、影響は大きいが特定条件でしか発生しない不具合と、影響は中程度でも多くの利用者が踏む不具合では、対応順が変わることがあります。 重要度・優先度の高い不具合が未クローズの場合、リリース判断に大きく影響します。不具合情報は、単なる修正依頼ではなく、リリース可否やテスト範囲見直しの判断材料として扱います。 不具合傾向を分析する 不具合は1件ずつ対応するだけでなく、傾向を見ることで品質リスクを把握できます。 機能別、テスト観点別、環境別、原因別、重要度別に件数を集計し、どこに不具合が集中しているかを確認します。 特定機能に不具合が集中している場合は、仕様理解の不足、設計の複雑さ、実装品質、テスト観点の不足が隠れている可能性があります。 また、計画値と実績値の差分も確認します。 想定より不具合が多い場合は、追加テスト、仕様再確認、回帰テスト範囲の拡大を検討します。 反対に不具合が極端に少ない場合も、テスト観点やケースの妥当性を確認する必要があります。 テスト管理の目的は、件数をきれいにまとめることではなく、品質上の懸念を早めに発見し、関係者が対策を取れる状態にすることです。 ISO/IEC/IEEE 29119-2でも、モニタリングは進捗やカバレッジの把握に使われるプロセスとして整理されています。 テスト管理を成功させる実務ポイントと失敗を防ぐチェックリスト テスト管理者とPMの役割を分ける テスト管理者は、進捗、不具合、品質状況、残リスクを収集し、現場の事実を見える形に整理します。 一方、PMはその情報をもとに、スケジュール変更、要員追加、リリース判断、追加対策を決めます。 テスト管理者がすべてを判断しようとすると負荷が集中し、PMが詳細を把握しないままだと判断が遅れます。 役割を分けたうえで、テスト管理者は「何が起きているか」「どの判断が必要か」「選択肢ごとのリスクは何か」を伝えることが重要です。 JSTQBでも、テストマネジメントの実施方法は状況によって異なり、アジャイルでは一部をチームが担当し、複数チームにまたがる場合はテストマネージャーが担うことがあるとされています。 実務では、進捗や不具合情報をもとに、現状維持、スケジュール変更、テストケース追加、範囲見直し、リリース延期などを検討できる報告に整えることが求められます。 リリース判断に必要な情報を整理する リリース判断では、テストケース消化率だけでなく、未実行ケースの内容、未解決不具合の件数、重要度、優先度、重大不具合の有無、回帰テストの実施状況、テスト範囲の不足、残リスク、関係者への確認事項を整理します。 特に、未実行ケースが残っている場合は、件数ではなく「どの重要機能が未確認なのか」を示す必要があります。 不具合についても、総件数だけでは判断できません。重大度の高い不具合が残っているのか、回避策があるのか、修正予定日はいつか、再テストが完了しているのかを確認します。 ISO/IEC/IEEE 29119-2では、テスト管理プロセスがプロジェクトレベル、システムテスト、受け入れテスト、性能テスト、ユーザビリティテストなど、さまざまなレベルやタイプに適用できるとされています。 そのため、リリース判断では、対象プロジェクトで重視する品質特性に合わせて、判断材料を整えることが重要です。 よくある失敗と対策 テスト管理でよくある失敗は、目的と範囲が曖昧なまま始めることです。 この場合、計画段階で対象、対象外、優先度を明確にします。次に、テストケースの粒度がばらつく失敗があります。 これは、手順、期待結果、前提条件の書き方を統一することで防ぎやすくなります。進捗を件数だけで判断する失敗も多く、工数ベースの進捗やNG・保留の残対応を見る必要があります。 不具合の優先度が決まらない場合は、重要度と優先度の定義を事前に共有します。 終了作業を省略すると、次回以降に同じ問題を繰り返しやすくなるため、テストケース、不具合傾向、改善点を残すことが大切です。 添付プロンプトでも、未実行ケースの大量残りや不具合優先度の未整理を避け、テスト計画、進捗管理、不具合管理、報告の流れを理解したいニーズが示されています。 実務で使えるチェックリスト 実務では、テスト開始前に確認すべき項目をチェックリスト化しておくと、抜け漏れを防ぎやすくなります。 確認すべき内容は、以下のとおりです。 ・テスト目的が明確か ・テスト範囲と対象外範囲が定義されているか ・テスト観点が要件と紐づいているか ・テストケースに手順と期待結果が書かれているか ・テスト環境とデータが準備済みか ・進捗管理の更新ルールが決まっているか ・不具合の起票ルールが決まっているか ・重要度・優先度の基準が共有されているか ・終了基準が定義されているか ・テスト結果報告のフォーマットが決まっているか このチェックリストは、テストリーダーだけで使うのではなく、PM、開発リーダー、テスターと共有しておくと効果的です。 開始前に合意しておけば、実行中に判断が割れたときも、計画や基準に戻って話し合えます。 属人的な判断を減らし、テスト状況を数値と根拠で説明するための基盤になります。 テスト管理ツールを活用する場面 テスト管理ツールは、テストケース数が多い場合、複数人で実行する場合、不具合件数が多い場合、リアルタイムに進捗を見たい場合、テストケースと不具合を紐づけたい場合、レポート作成を効率化したい場合に有効です。 Excelでも小規模な管理は可能ですが、同時更新、履歴管理、権限管理、テストケースと不具合の関連付け、ダッシュボード化に限界が出ることがあります。 テスト実行状況や不具合情報は日々変化するため、最新状態をすぐ確認できる仕組みがあると、報告の属人化を防ぎやすくなります。 JSTQBでも、テストウェアにはテスト計画書、テストケース、テストデータ、テスト結果記録、欠陥レポート、テスト完了レポートなど多くの成果物が含まれると整理されています。 ツールは導入するだけでは効果が出ません。 ステータス定義、更新頻度、起票ルール、レビュー担当、レポート項目を決めて運用することで、進捗・品質・リスクを継続的に見える化できます。 まとめ テスト管理を円滑に進めるには、計画・設計・実行・不具合管理・報告を分断せず、一連の実務フローとして整理することが重要です。 テスト開始前には、目的、範囲、対象外範囲、体制、スケジュール、環境、データ、入場基準・退場基準を明確にし、関係者間で合意しておく必要があります。 テスト実行中は、ケース数ベースの消化率だけでなく、工数ベースの進捗、NG・保留ケースの残対応、不具合の重要度・優先度、未解決課題を確認します。 特にリリース判断では「何件実行したか」だけではなく、「重要機能が確認済みか」「重大不具合が残っていないか」「残リスクを関係者が把握しているか」が問われます。 また、テスト終了時には、テスト結果報告書を作成し、未実行ケース、未解決不具合、回帰テストの状況、残課題、次回への改善点を整理します。 テストケースや不具合傾向をナレッジとして残すことで、次回以降のテスト計画や品質改善にも活用できます。 テスト管理は、属人的な判断を減らし、進捗・品質・リスクを根拠にもとづいて説明するための活動です。 計画段階で基準を決め、実行中は状況を可視化し、終了時には判断材料を整理することで、リリース直前の混乱や手戻りを防ぎやすくなります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）