こんにちは、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の導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

アプリ開発の現場において、リリース後にユーザーから予期せぬ不具合報告が相次ぎ、対応に追われる経験はないでしょうか。 原因を振り返ると、テスト設計の不十分さや、ユーザー視点での検証不足に気づかされることも少なくありません。 アプリテストの本来の役割は、単にバグを見つけることだけではなく、プロダクトが提供すべき価値を保証し、ユーザー体験を最大化することにあります。 しかしWebとモバイルでの検証観点の違いや、膨大なテスト項目の優先順位付け、さらには自動化の判断基準など、実務レベルで品質を安定させるには多くの壁が存在します。 今回はアプリ開発のリーダー候補として品質改善に取り組むエンジニアに向けて、テストの種類や具体的な進め方、そして効率化のベストプラクティスを詳しく解説します。 属人化を排除し、チーム全体で高品質なアプリを継続的にリリースできる体制を構築するためのステップを一緒に見ていきましょう。 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",}) ▼アプリ開発の基本について知りたい方はこちら▼ アプリ開発とは？種類・流れ・必要スキル・費用感まで初心者向けにわかりやすく解説 アプリテストとは？なぜ必要なのか アプリテストの目的は「不具合発見」だけではない アプリテストの主要な目的として、まず挙げられるのが品質保証です。 これは、単にプログラム上のバグを見つけることにとどまらず、プロダクトが仕様を満たし、本来提供すべき価値を正しく届けられているかを確認する一連のプロセスを指します。 開発の初期段階からテストを組み込むことで、リリース直前や運用開始後に重大な欠陥が発覚する事態を防ぎ、結果として修正コストの増大を抑制することができます。 また、ユーザー体験の向上も欠かせない視点です。 操作のしやすさや応答速度といったストレスのない利用環境を担保することで、ユーザーの離脱を防ぎ、信頼性の高いサービスとしての地位を確立できます。 さらに、多種多様な環境で正しく動作するかを確かめる互換性の確認や、外部攻撃から情報を守るためのセキュリティリスクの低減も、現代のアプリ開発においては必須の項目です。 不具合報告が相次ぐような状況を改善するには、これらの要素を網羅的に捉え、単なる動作確認を超えた品質管理の体制を構築することが重要となります。 Webアプリとモバイルアプリでテスト観点が変わる理由 開発対象がWebアプリかモバイルアプリかによって、重点を置くべきテスト観点は大きく異なります。 Webアプリの場合は、ChromeやSafariといったブラウザの種類やバージョンの違いによる挙動の変化が中心となりますが、モバイルアプリの場合は考慮すべき変数が飛躍的に増加します。 まずiOSとAndroidというOSの違いだけでなく、各メーカーが独自にカスタマイズした端末特有の依存関係が品質に強く影響します。 画面サイズや解像度のバリエーションも豊富なため、レイアウト崩れが起きていないかを詳細に確認しなければなりません。 さらに、モバイル特有の挙動であるプッシュ通知の受信、位置情報の利用許可、あるいは他のアプリへの切り替えに伴う中断と再開といったシナリオも検証の対象となります。 屋外での利用を想定した不安定な通信環境下での動作や、バッテリー消費の激しさなども、ユーザー満足度に直結する重要な要素です。 こうしたモバイルならではの物理的な制約や利用環境をシミュレートすることで、現場で発生しがちな「特定の条件下でだけ発生する不具合」を未然に防ぎ、再現性の高い品質基準を設けることが可能になります。 手動テストと自動テストの違い テストを効率化し、チーム全体の生産性を高めるためには、手動テストと自動テストの特性を理解して使い分けることが求められます。 手動テストは、人間が実際にアプリを操作して直感的に違和感を探る手法であり、特に新規機能のユーザーインターフェースや操作感の評価に向いています。 仕様が頻繁に変更される開発初期や、探索的な視点が必要な場面では、人の判断力による柔軟な対応が最大の武器となります。 一方で自動テストは、回帰テストのように何度も繰り返される定型的な検証において真価を発揮します。 プログラムによって高速かつ正確にテストを実行できるため、深夜や休日など時間を問わずに品質チェックを回し続けることが可能です。 これにより、人的ミスによる確認漏れを排除し、チームがより高度な設計や改善に注力できる環境を整えられます。 属人化を解消し、誰が実行しても同じ結果が得られる体制を構築するためには、まずは安定した機能から順次自動化を取り入れ、手動テストと組み合わせたハイブリッドな運用を推進するのがベストプラクティスです。 アプリテストの主な種類一覧 開発工程ごとのテストの種類 アプリ開発において品質を担保するためには、開発の流れに沿って段階的にテストを実施することが基本です。 まず行われるのが単体テスト（ユニットテスト）です。これはプログラムを構成する最小単位である関数やクラスが、設計通りに動作するかを確認する工程です。 不具合を早期に発見することで、後続工程での手戻りを最小限に抑える効果があります。 次に、個別のモジュールを組み合わせて正しくデータが受け渡されるかを検証するのが結合テスト（統合テスト）です。 複数の機能が連携した際に発生する矛盾や予期せぬ挙動を洗い出します。 さらに、アプリ全体を本番に近い環境で動かし、システム全体の要件を満たしているかを確認するのがシステムテスト（総合テスト）です。 ここでは性能や負荷といった側面も検証対象となります。 最後に、最終的な利用者が実際に操作を行い、ビジネス上の要件や使い勝手が満たされているかを判断するのが受け入れテスト（UAT）です。 エンジニア視点だけでなくユーザー目線での検証を徹底することで、リリース後の「期待していたものと違う」というミスマッチを防ぎます。 これらの工程を積み重ねることが、チーム全体の開発プロセスを標準化し、再現性の高い品質管理を実現するための第一歩となります。 観点別に見るテストの種類 機能が正しく動作するかを確認する機能テストは基本ですが、高品質なアプリをリリースするためには多角的な観点からの検証が欠かせません。 例えばUIテストでは、ボタンの配置や画面遷移が直感的に操作できるか、デザイン崩れがないかを確認します。 また、現代のアプリ開発において欠かせないAPIテストでは、バックエンドとの通信が正しく行われ、正確なデータが返却されるかを検証します。 さらに大量のアクセスがあった際に応答速度が低下しないかを見るパフォーマンステストや、脆弱性を突いた攻撃から情報を守るためのセキュリティテストも、信頼されるアプリ作りには必須です。 モバイルアプリ特有の課題である端末やOSごとの動作差分を確認する互換性テスト、そしてユーザーが迷わず目的を達成できるかを評価するユーザビリティテストも重要です。 これらのテストを網羅することで、特定の環境でしか発生しない不具合や、使い勝手の悪さに起因するユーザー離脱を未然に防ぐことができます。 リーダー候補としてプロジェクトを統括する際には、どのテストにリソースを割くべきかを論理的に判断し、効率的な検証計画を立てることが求められます。 初心者が混同しやすいテストの違い 現場で混乱を招きやすいのが、似たような名称や役割を持つテストの境界線です。 まず単体テストと結合テストの違いは、検証の範囲にあります。 単体テストはロジックの正しさを個別に確認するものですが、結合テストはそれらを繋ぎ合わせたときの「インターフェース」の不整合を見つけるものです。 また、システムテストとE2Eテストも混同されがちです。 システムテストはシステム全体が仕様通りかを検証するのに対し、E2Eテストはユーザーの最初から最後までの一連の操作（フロー）を網羅することに重点を置きます。 さらに、UIテストと受け入れテストの違いも明確にする必要があります。 UIテストは見た目や操作の挙動を確認する技術的な側面が強いですが、受け入れテストはビジネス要件を満たしているかという目的の達成に主眼を置きます。 そして、機能テストと非機能テストの違いも重要です。 機能テストは「何ができるか」を確認し、非機能テストはパフォーマンや安全性といった「どのように動作するか（品質特性）」を評価します。 これらの違いを正しく理解し、チーム内で定義を統一することは、属人化を排除し、スムーズなコミュニケーションを促進するために不可欠です。 明確な基準を設けることで、メンバー全員が同じ品質目標に向かって動けるようになり、結果としてリリース後のトラブルを大幅に削減することが可能になります。 アプリテストのやり方｜実務で迷わない進め方 1. テスト対象と目的を明確にする 効率的なテストを実施するためには、まず「どの機能を何のために確認するのか」を定義することが不可欠です。 限られたリソースの中で全ての機能を網羅的に検証するのは現実的ではないため、ビジネスへの影響度が高い重要機能や、過去に不具合が頻発した障害影響の大きい領域から優先順位をつけます。 この段階でコア機能の安定性を最優先にする方針をチーム内で共有しておけば、リリースの直前になって致命的な不具合に直面するリスクを大幅に軽減できます。 また、検証項目を洗い出す際に「自動化する対象」と「しない対象」を切り分けることも重要です。 例えば、頻繁に繰り返し実行される基本機能の確認は自動化の候補となりますが、UIの微細な調整や新機能の使い勝手といった人間による感覚的な評価が必要な項目は、手動テストとして残すべきです。 このように目的を明確化し、リソースの配分を論理的に決定することで、属人化を防ぎ、チーム全体が納得感を持って作業を進められる土台が整います。 2. テスト観点を洗い出す テストの漏れを防ぎ、ユーザー視点での品質を確保するためには、多角的な観点からの洗い出しが欠かせません。 まず基本となるのは、仕様通りに正しく動くことを確認する正常系です。 しかし、実際の現場で不具合の引き金となるのは、想定外の操作を検証する異常系や、仕様の閾値となる境界値の確認不足である場合がほとんどです。 最小値や最大値、あるいはその前後の値を入力した際に予期せぬ挙動をしないか、徹底的に確認する必要があります。 さらに入力値のバリエーションやユーザー権限ごとの動作、状態遷移の整合性も重要な観点です。 特にモバイルアプリにおいては、電波の遮断といった通信エラーや、操作中の着信による中断など、スマホ特有の挙動が品質に直結します。 こうしたイレギュラーな状況をあらかじめリストアップしておくことで、現場の問題に対する不安を解消し、誰が担当しても一定の品質を保てる再現性のある検証が可能になります。 3. テストケースを作成する テストケースの作成では、一貫性と客観性が求められます。 原則として「1つのケースに対して、期待される結果は1つ」という構成を徹底し、合否判定に迷いが生じないようにします。 操作手順、入力値、そして期待される具体的な結果を明確に記述することで、経験の浅いメンバーでも正確にテストを遂行できる環境を作ります。 手順が曖昧だと再現性が失われ、後の不具合調査で混乱を招く原因になるため注意が必要です。 また検証に必要となるテストデータや実行環境は、本番環境と切り離して事前に準備しておきます。特定のユーザー状態や決済履歴が必要な場合、テストが始まってから用意していては効率が大幅に低下します。 あらかじめ必要な条件を整理し、クリーンな環境で検証を行えるように準備を整えることで、テスト工程そのものの品質が向上します。 こうした標準化されたプロセスを導入することが、将来的にプロジェクト全体を統括するリーダーとしての信頼にもつながります。 4. 実行・記録・不具合管理を行う テストの実行フェーズでは、単に結果を記録するだけでなく、不具合が発生した際の「再現条件」を詳細に残すことが極めて重要です。 どのような手順で、どのような環境下で、どのような入力を行った際に問題が起きたのかを正確に記述することで、開発エンジニアの調査コストを劇的に下げることができます。 スクリーンショットやログを併記する運用をチーム内で徹底すれば、不具合報告の精度が上がり、修正のスピード感も向上します。 修正が完了した後は、該当箇所が正しく直っているかを確認する再テストに加え、その修正が他の機能に悪影響を及ぼしていないかを確認する影響範囲の検証（回帰確認）が不可欠です。 一つの修正が別の場所で新たなバグを生む「デグレード」は、リリース後のトラブルの大きな要因となります。 記録を確実に残し、修正から確認までのプロセスを管理ツールなどで可視化することで、品質改善の進捗を客観的に把握できるようになります。 5. 回帰防止のために自動化を組み込む 継続的なリリースを行いながら品質を維持するためには、再テストの負担を軽減するための自動化が鍵となります。 特にバージョンアップのたびに繰り返し実行される基本的なシナリオは、自動テストの格好の候補です。 自動化を始める際は、期待結果がイエス・ノーで明確に定義できるものや、ビジネスインパクトが大きいコア機能から着手するのが成功のコツです。 ただし、全てのテストを自動化しようとすると、かえってメンテナンスコストが増大し、開発の足を引っ張る恐れがあります。 常に費用対効果を見極め、変更が頻繁な画面周りなどはあえて自動化を避けるといった柔軟な判断も必要です。 自動テストをCI/CD（継続的インテグレーション／継続的デリバリー）のパイプラインに組み込むことで、不具合の早期発見を仕組み化し、障害対応に追われる日々から脱却して、より価値の高い開発に時間を割ける体制を目指します。 モバイルアプリテストで必ず押さえたいチェック項目 1. インストール・起動・更新まわりのテスト アプリがユーザーの端末に無事に届き、正しく動き出すまでのプロセスは、第一印象を左右する極めて重要な工程です。 まず各プラットフォームのストアから正常にインストールできるかを確認し、ホーム画面に表示されるアイコンが指定通りのデザインで、ぼやけや欠けがないかを確認します。 起動時間については、ユーザーがストレスを感じない許容範囲内に収まっているかを実機で計測することが不可欠です。 特に現場でトラブルになりやすいのが、アプリアップデート時の挙動です。 新バージョンへ更新した際に、これまでの設定値やログイン状態、保存済みのデータが意図せず消去されることなく保持されるかを徹底して検証します。 またアンインストールを実行した後に、不要なキャッシュファイルや一時データが端末内に残ってストレージを圧迫し続けないかも確認ポイントです。 これらの項目を網羅することで、利用開始直後の離脱を防ぎ、信頼性の高いサービス提供が可能になります。 2. 画面操作・UIのテスト ユーザーが直接触れるUIの検証では、論理的な設計通りの動作と、視覚的な正確さの両面からチェックを行います。 ボタンの反応やメニュー遷移が仕様通りであることはもちろん、多種多様なアスペクト比の端末でレイアウト崩れが起きていないかを細かく見ていきます。 フォントの種類やサイズ、色のコントラスト、さらには誤字脱字といった細部まで確認を怠らないことが、プロダクト全体の質感を高める鍵となります。 モバイル特有の観点として、端末の縦横回転を切り替えた際に表示が崩れたり、入力内容がリセットされたりしないかの確認も欠かせません。 入力欄のバリデーションについては、空欄送信の防止、最大文字数制限、絵文字や記号などの特殊文字の扱い、日付や数値のフォーマット指定が適切に機能するかを一つずつ検証します。 こうした泥臭い確認の積み重ねが、リリース後の不具合報告を半減させる着実な一歩となります。 3. 通信・端末・利用環境のテスト モバイルアプリは常に安定した通信環境で使われるとは限りません。 そのため、電波が極端に弱い場所や、Wi-Fiとモバイル通信が切り替わるタイミングなど、通信が不安定な状況下でもアプリがフリーズせずに適切なエラーメッセージを表示するかを検証します。 通信エラーが発生した際のハンドリングが不十分だと、ユーザーに「壊れている」という印象を与えてしまうため、タイムアウト処理などの確認は必須です。 また、Android端末に代表される多種多様な端末差・OS差への対応も大きな課題です。 特定のメーカーやバージョンでのみ発生する表示崩れや動作不良がないか、実機やシミュレーターを駆使して互換性を確認します。 さらに、カメラや写真ライブラリへのアクセス、プッシュ通知といったデバイス固有の機能との連携がスムーズか、権限の許可・拒否設定が正しく反映されるかについても、利用環境をシミュレートしながら漏れなくチェックします。 4. 中断・再開・バックグラウンド時のテスト スマートフォンの利用シーンでは、アプリ操作中に着信やアラーム、他アプリからの通知によって操作が中断されることが日常的に起こります。 このような割り込みが発生した際でも、アプリが異常終了することなく、再開時に入力途中の内容や遷移状態が保持されているかを確認します。 バックグラウンドから復帰した瞬間に画面が真っ白になったり、データが初期化されたりする不具合は、ユーザー満足度を著しく低下させる要因です。 加えて、端末が低電力モードに入っている場合や、メモリなどのリソースが不足している低スペック端末での挙動も検証対象に含めます。 システムによってプロセスが強制終了された後の復帰プロセスが正しく設計されているかを確認することで、予期せぬクラッシュを未然に防ぎます。 こうした「動いて当たり前」の挙動を保証することが、現場のエンジニアが抱える不安を解消し、安定した運用体制を築くための土台となります。 5. 見落としやすい非機能テスト 機能が正しく動くだけでは、真に品質の高いアプリとは言えません。 性能面では、長時間利用した際のメモリリークの有無や、画面遷移のレスポンス速度といったパフォーマンスを評価します。 セキュリティ面では、重要な情報の暗号化や不必要なログの出力がないかを確認し、リスクを最小限に抑えます。 これらはリリース後に問題化すると修正コストが膨大になるため、設計段階からの意識が求められます。 また最新OSだけでなく旧バージョンとの互換性や、アプリがクラッシュせずに動き続ける安定性も重要です。 そして最後に、初めて触るユーザーでも迷わず操作できるかというユーザビリティの観点から全体を見直します。 エンジニア視点では見落としがちなこれらの非機能要件をプロセスに組み込むことで、属人化を排除した再現性のある開発体制が整います。 結果としてチーム全体の評価が高まり、テックリードやマネージャーへのキャリアアップを支える確固たる実績につながります。 アプリテストを効率化するコツと自動化の始め方 自動化に向いているテスト・向いていないテスト テスト自動化を成功させる鍵は、リソースを投入すべき対象を正しく見極めることにあります。 自動化に最も適しているのは、リリースのたびに繰り返し実行される定型的なテストや、入力値に対して期待される結果が論理的に明確なテストです。 一方で、使い心地やデザインの微細なニュアンスといった感覚的な評価が求められるUI/UXの検証は自動化には向きません。 また仕様が頻繁に変更される開発初期の機能も、スクリプトの修正コストが膨らむため、手動で柔軟に対応するほうが効率的です。 まずはコードレベルの正しさを保証する単体テストや、外部システムとの連携を確認するAPIテスト、そしてアプリの核となる主要フローの回帰テストから着手するのが定石です。 これらを自動化することで、人的ミスを防ぎながら高速に品質をチェックできる体制が整います。 現場のエンジニアが抱える「修正によるデグレード」への不安を払拭し、論理的な裏付けを持って開発を進めるための第一歩となります。 自動テスト導入の基本ステップ 自動テストを導入する際は、闇雲にコードを書くのではなく、段階的なプロセスを踏むことが重要です。 最初のステップは自動化対象の識別です。 頻度や重要度を軸に、どのテストを自動化すれば最大の効果が得られるかを判断します。 次に、検証に必要なテストデータの準備とテストケースの整理を行います。 手順や期待結果が曖昧なままでは自動化は失敗するため、誰が見ても明快な形にドキュメント化しておく必要があります。 続いて、プロジェクトの特性に合ったツールを選定し、開発フローに組み込むためのCI/CD連携を進めます。 一度構築して終わりではなく、アプリの進化に合わせてスクリプトを更新し続ける継続運用とメンテナンスの仕組み作りも欠かせません。 この一連の流れを標準化することで、属人化を排除し、チーム全体で品質を底上げできる再現性の高い開発基盤が構築されます。 ツール選定で見るべきポイント ツール選定においては、単なる機能比較だけでなく、実務での運用負荷を考慮することが不可欠です。 まずWebアプリだけでなくiOSやAndroidといったモバイル環境への対応状況を確認します。 さらに、チームの技術スタックに応じて、スクリプトを書くプログラミング型か、非エンジニアでも扱いやすいノーコード・ローコード型かを選択します。 リーダー候補としては、自分だけでなくチーム全員が使いこなせる「共有のしやすさ」も重要な評価基準となります。 また、既存のCI/CD環境との連携のしやすさや、テストコードの保守性が高いかどうかも見極めるべきポイントです。 メンテナンスに時間が取られすぎて開発が停滞しては本末転倒なため、将来的な拡張性を含めて論理的に比較検討します。 適切なツールを導入し、品質管理を仕組み化することは、プロジェクト全体を統括するマネージャーとしての視点を養う絶好の機会にもなります。 手動テストだけで終わらせない運用体制 テストを「リリース前の一時的な作業」として終わらせず、継続的な改善サイクルに組み込むことが品質向上の極意です。 不具合が発生した際には、その傾向を蓄積・分析し、テスト観点そのものをアップデートし続ける文化を醸成します。 なぜそのバグが漏れたのかを振り返り、新たな検証項目として追加することで、次回リリースでの不具合発生率を確実に下げることができます。 さらに、テストケースや知見を個人の頭の中に留めず、チームの共通資産としてドキュメント化・共有する仕組みを作ります。 これにより、特定の担当者がいないと検証が進まないといった属人化を防ぎ、常に一定の品質を保てる体制へと進化します。 トラブル対応に追われる現状を脱却し、ユーザー満足度の向上に直結する価値の高い開発に時間を投資できるよう、組織としての品質意識を高めていくことが求められます。 まとめ 高品質なアプリを安定してリリースし続けるためには、開発工程ごとに適切なテストを配置し、漏れのない検証観点を持つことが不可欠です。 単体テストから受け入れテストまでの流れを標準化し、モバイル特有の「中断・再開」や「通信環境」といったユーザー視点の項目を網羅することで、リリース後の致命的な不具合は大幅に抑制できます。 また、手動テストの柔軟性と自動テストの継続性を賢く組み合わせることは、チームの生産性を向上させるだけでなく、エンジニアがより価値の高い開発業務に集中できる環境作りにも直結します。 今回ご紹介したプロセスやチェックリストを実務に適用し、不具合の傾向を蓄積してテスト設計をアップデートし続けてみてください。 品質改善の実績は、チームからの信頼獲得や、将来的にテックリードやマネージャーとしてプロジェクトを統括するための強力な武器となるはずです。 まずは次回のリリースに向けて、優先度の高い機能のテスト設計から見直してみることをおすすめします。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）