開発からリリースまで「自動で流れる」チケット管理

こんにちは、kickflow QAチームの川村です。

「開発チームからQAへの依頼がSlackで埋もれてしまう」「チケットのステータス管理が煩雑で、今どの段階にあるかわかりにくい」といった課題を抱えていませんか？

本記事では、kickflowのQAチームがAsanaとSlackを連携させて構築したチケット管理ワークフローをご紹介します。
開発からリリースまで、情報が自然と流れる仕組みを実現しています。

背景：なぜAsana・Slack連携を構築したのか
ツール連携の全体像
各フェーズの詳細
Zapierによる自動化の全体像
- Slackリストの進捗管理
AIの活用ポイント
- 1. テスト設計（ホワイトボックス観点）
- 2. ケースレビュー
導入の成果
まとめ

背景：なぜAsana・Slack連携を構築したのか

kickflowはフルリモート・フルフレックスの企業です。
メンバーが異なる時間帯に働くことも多いため、タスクの依頼を非同期で行える仕組みが必要です。
また、非同期コミュニケーションでは一度依頼が漏れると拾いにくいため、漏れない仕組みづくりも重要でした。

以前は以下のような課題がありました。

依頼の見落とし：SlackでのQA依頼が他のメッセージに埋もれてしまう
ステータスの不透明さ：チケットが今どの段階にあるか確認に手間がかかる
手動作業の多さ：ステータス変更のたびに関係者への連絡が必要

これらの課題を解決するため、AsanaとSlackを中心としたツール連携を構築しました。
連携の中継役としてZapierを活用し、インフラ管理なしで複数ツール間の自動化を実現しています。

ツール連携の全体像

まず、チケット対応の全体フローを図で示します。

flowchart TB
    subgraph Dev["開発フェーズ"]
        D1[👨‍💻開発者: 機能実装]
        D2[👨‍💻開発者: PR作成・Asanaタスク紐付け]
        D3[👨‍💻開発者: QA requiredラベル付与]
        D4[🔄自動: GitHub→Asana PR is openコメント]
        D5[🔄自動: Zapier→Asana ブランチ名コメント]
    end

    subgraph Request["QA依頼フェーズ"]
        A1[👨‍💻開発者: Asana QAステータスに変更]
        S1[🔄自動: Asanaルール→Slack通知]
        S2[🔄自動: Zapier→Slackリスト追加]
    end

    subgraph Design["テスト設計フェーズ"]
        T1[🕵️QA: Slackリアクション→AIテスト設計起動]
        T2[🤖AI: テスト観点生成<br>（ホワイトボックス観点）]
        T3[🤖AI: GitHub テスト項目書Issue作成]
        T4[🕵️QA: 観点追加<br>（ブラックボックス観点）]
        T5[🕵️QA: Slackリスト設計完了]
    end

    subgraph Review["レビューフェーズ"]
        R1[🕵️QA: 内部レビュー依頼]
        R2[🕵️レビュワー: Slackリアクション→AIレビュー起動]
        R2b[🤖AI: GitHub Issueにレビュー観点コメント]
        R3[🕵️レビュワー: フィードバック]
        R4[🕵️QA: 修正]
        R5[🕵️QA: Slackリスト内部レビュー完了]
        R6[🕵️QA: 開発者レビュー依頼]
        R7[🕵️QA: Slackリスト開発者レビュー完了]
    end

    subgraph Exec["テスト実施フェーズ"]
        E1[🕵️QA: テスト項目書に従って実施]
        E2{結果判定}
        E3[🕵️QA: Asana Bugチケット起票]
        E4[👨‍💻開発者: 修正→QA中]
        E5[🕵️QA: 修正確認]
        E6[全項目Pass & バグ修正確認完了]
        E7[🕵️QA: Asana QA完了に変更]
        E7b[🔄自動: Zapier→Slackリスト QA完了]
        E8[🕵️QA: QA Doneリアクション]
        E9[🔄自動: Zapier→GitHub PRラベル更新]
    end

    subgraph Release["リリースフェーズ"]
        L1[👨‍💻開発者: 夕会でPRをマージ]
        L2[🔄自動: GitHub→Asana ~mergedコメント]
        L3[🔄自動: Zapier→Asana リリース準備中]
        L4[🔄自動: Zapier→Slackリスト完了]
        L5[🔄自動: 統合ブランチ→Sandboxデプロイ]
        L6[🔄自動: E2E・APIテスト実行]
        L7{テスト結果}
        L8[👨‍💻開発者: リリース]
        L9[👨‍💻開発者: リバート or 修正]
        L10[👨‍💻開発者: Asana完了に移動]
    end

    D1 --> D2 --> D3 --> D4 --> D5
    D5 --> A1
    A1 --> S1 --> S2
    S2 --> T1 --> T2 --> T3 --> T4 --> T5
    T5 --> R1 --> R2 --> R2b --> R3 --> R4
    R4 --> R5 --> R6 --> R7
    R7 --> E1 --> E2
    E2 -->|Fail| E3 --> E4 --> E5 -.-> E1
    E2 -->|Pass| E6 --> E7 --> E7b --> E8 --> E9
    E9 --> L1 --> L2 --> L3 --> L4
    L4 --> L5 --> L6 --> L7
    L7 -->|Pass| L8 --> L10
    L7 -->|Fail| L9 -.-> L8

このフローでは、以下のツールが連携しています。

ツール	役割
Asana	チケット管理・ステータス管理
Slack	通知・コミュニケーション・自動化トリガー
Slackリスト	QAチケットの進捗可視化
GitHub	ソースコード管理・PRラベル管理・テスト項目書Issue
Zapier	ツール間連携の中継
AI（Devin等）	テスト設計・ケースレビューの支援

各フェーズの詳細

1. 開発フェーズ

開発者は機能実装後、以下の操作を行います。

PR作成時にAsanaタスクを紐付け：PRの説明欄にAsanaタスクのリンクを記載
QA requiredラベルを付与：手動QAが必要なPRにラベルを付ける
PR Open時の自動連携：
- GitHubとAsanaの連携により、Asanaに以下のようなコメントが自動追加 fix: 〇〇の不具合を修正 is open: https://github.com/hoge/fuga/pull/XXXXX
- このコメントをZapierが検知し、PRのブランチ名をAsanaにコメント

【開発者の操作】
1. PRの説明欄にAsanaタスクのリンクを記載
2. QA requiredラベルを付与
→ 以降はZapierが自動でブランチ名をAsanaにコメント

ブランチ名がAsanaに記録されることで、QAエンジニアがテスト環境へのデプロイ時に対象ブランチをすぐに特定できます。

2. QA依頼フェーズ

開発者がAsanaでチケットを「QA」ステータスに変更すると、以下が自動実行されます。

Asanaのルール機能：SlackのQAチャンネルに通知
Zapier：ステータス変更を検知し、Slackワークフローを起動→Slackリストにタスクを追加

【自動化の流れ】
Asana: QAステータスに変更
    ↓
Asana Rule: Slackチャンネルに通知
    ↓
Zapier: Slackワークフロー起動
    ↓
Slackリストにタスク追加

QA担当者はSlack通知でQA依頼を認知し、Slackリストで担当チケットを確認できます。

3. テスト設計フェーズ

テスト設計はAIと人間のハイブリッドで行います。

AIによるテスト設計（ホワイトボックス観点）

QA担当者がSlackの通知メッセージにAIテスト設計起動用のリアクションを付ける
AIがPRの差分やコードを分析し、テスト観点を生成
生成完了後、GitHubにテスト項目書のIssueが作成され、Slackに通知

【AI設計の流れ】
Slackメッセージにリアクション
    ↓
AIがコード差分を分析
    ↓
テスト観点を生成（ホワイトボックス観点）
    ↓
GitHubにテスト項目書Issueを作成
    ↓
Slackに完了通知

人間によるテスト観点追加（ブラックボックス観点）

AIが生成した観点をベースに、QAエンジニアが以下の観点を追加します。

既存のテスト項目書を参照した項目の追加
仕様書に記載の観点
ユーザー視点での観点
その他必要な観点

設計が完了したら、Slackリストのステータスを設計完了に更新します。

4. レビューフェーズ

テスト設計のレビューは2段階で行います。
依頼はすべて、最初のQA依頼があったSlackメッセージのスレッドで行います。

内部レビュー

QAチームの内部レビューを依頼
レビュワーがSlackメッセージにAIケースレビュー起動用のリアクションを付ける
AIがGitHubのテスト項目書Issueにレビュー観点をコメント
AIによる観点とレビュワーによる観点を考慮し、設計者にフィードバック
設計者が修正
再度レビュワーに依頼し、承認されたら内部レビュー完了

開発者レビュー

開発者にケースレビューを依頼
指摘があればケースを修正
承認されたらテスト項目書の作成完了→開発者レビュー完了

【レビューの流れ】
内部レビュー依頼（Slackスレッド）
    ↓
レビュワー: AIレビュー起動（Slackリアクション）
    ↓
AI: GitHub Issueにレビュー観点コメント
    ↓
レビュワー: AI観点 + 自身の観点でフィードバック
    ↓
設計者: 修正
    ↓
Slackリスト: 内部レビュー完了
    ↓
開発者レビュー依頼（Slackスレッド）
    ↓
フィードバック・修正
    ↓
Slackリスト: 開発者レビュー完了

5. テスト実施フェーズ

完成したテスト項目書に従ってテストを実施します。

コミュニケーション

開発者への問い合わせやブロッカーになりうる不具合があれば、最初のQA依頼があったSlackメッセージのスレッドで連絡します。
これにより、1つのチケットに関するやり取りが1つのスレッドに集約されます。

不具合検知時

AsanaのBugプロジェクトにチケットを起票（改善提案も同様）
開発者が元の開発ブランチからfeatureブランチを切って修正
修正完了後、バグチケットがQA中になりSlack通知が来る
QA担当者が修正確認を実施

QA完了

以下の条件を満たしたら実施完了です。

全てのテスト項目の実施が完了
リリースブロッカーになるバグの修正確認が全て完了

完了したら：

AsanaのチケットをQA完了ステータスに変更
Zapier + Slackワークフローにより、Slackリストも自動でQA完了に更新
最初のQA依頼メッセージに「QA Done」リアクションを付ける
ZapierがリアクションをGitHub PRのラベルを更新（QA required → QA Done）

6. リリースフェーズ

マージからリリース準備

夕会でQA DoneラベルのついたPRをリリースブランチへマージ
マージされるとGitHub→Asana連携で、Asanaに「PR hogehoge is merged」コメントが自動追加
Zapierがこのコメントを検知し、Asanaのステータスをリリース準備中に変更
リリース準備中になると、Zapier→Slackワークフロー連携でSlackリストから対象の項目を完了にする

これにより、Slackリストには常に「対応中のチケット」のみが表示され、クリーンな状態が保たれます。

自動テストの実行

夕会で統合ブランチにマージされると、統合ブランチが自動でSandbox環境にデプロイ
その晩から早朝にかけてE2EテストとAPIテストがSandbox環境で自動実行

翌朝の確認

翌朝、担当QAエンジニアがE2Eテストの結果を確認
不具合を検知した場合：
- エラー事象が記載されたSlackメッセージにSlackリアクションを付ける
- AIによる原因調査jobが起動し、今回の統合ブランチのどのPR・チケットが要因かを調査
- QAが調査結果を元にAsanaにバグチケットを起票する
- 開発者に確認依頼する

リリース

問題なし：開発者がリリースを実行
問題あり：リバートまたは修正してからリリース
リリース完了後：リリース担当の開発者がAsanaのチケットをリリース準備中から完了に移動

Zapierによる自動化の全体像

ツール間の連携にはZapierを活用しています。
Zapierを選んだ理由は、インフラ管理が不要で、Asana・Slack・GitHubといった主要ツールを簡単に中継できるためです。

現在、QA業務に関連するZapは18個稼働しています。
代表的なものを紹介します。

Zap名	トリガー	アクション
Github PRのブランチ名通知	Asana: 「is open」コメント検知	Githubからブランチ名を取得し、Asanaにブランチ名をコメント
Slackリスト自動追加	Asana: QA中ステータス	Slackワークフロー→リスト追加
SlackリストQA完了更新	Asana: QA完了ステータス	Slackワークフロー→リストQA完了
PRラベル自動更新	Slack: QA Doneリアクション	GitHub: ラベル変更
リリース準備中自動変更	Asana: 「~merged」コメント検知	Asana: ステータスをリリース準備中に変更
Slackリスト自動完了	Asana: リリース準備中ステータス	Slackワークフロー→リスト完了

Slackリストの進捗管理

Slackリストには以下のステータス列があり、QAの各フェーズを可視化しています。

テスト設計
内部レビュー
開発レビュー
テスト実施
QA完了

リリース準備中になると自動で完了するため、リストには常に対応中のチケットのみが表示されます。

AIの活用ポイント

本ワークフローでは、AIを2つのポイントで活用しています。

1. テスト設計（ホワイトボックス観点）

AIがPRのコード差分を分析し、テスト観点を自動生成します。
コードの変更箇所に基づいた観点（ホワイトボックス）を効率的に洗い出せます。

2. ケースレビュー

レビュワーがAIによるケースレビューを起動し、観点の抜け漏れをチェックします。
AIの観点と人間の観点を組み合わせることで、レビューの質を向上させています。

【AI活用の考え方】
AI: ホワイトボックス観点（コード差分ベース）
人間: ブラックボックス観点（仕様・ユーザー視点ベース）
→ ハイブリッドで網羅性を確保

導入の成果

この連携を導入したことで、以下の成果が得られました。

1. QA依頼の見落としゼロ

Slack通知とSlackリストにより、QA依頼を見落とすことがなくなりました。
フルリモート・フルフレックス環境でも、非同期でQA依頼が確実に伝わる仕組みが実現しています。

2. ステータスの可視化

Slackリストの進捗管理により、チケットの状態が一目でわかるようになりました。
「今どの段階？」という確認のやり取りが不要になり、各自が都合のよいタイミングで状況を把握できます。

3. コミュニケーションの集約

1つのチケットに関するやり取りがSlackの1スレッドに集約されるため、情報が散逸しません。
後から経緯を追いやすく、引き継ぎもスムーズです。

4. 手動作業の削減

Zapierによる自動化で、ステータス変更に伴う通知やラベル更新が自動化されました。
開発者はPRにAsanaリンクを貼るだけで、その後のフローが自動で進みます。

5. Slackリストの自動クリーンアップ

リリース準備中になると自動でSlackリストから完了するため、常に「今対応すべきチケット」だけが表示されます。

まとめ

AsanaとSlackを中心としたツール連携により、開発からリリースまでシームレスなワークフローを実現しました。

Asana：チケット管理とステータス管理の中心
Slack：通知・コミュニケーション・自動化のハブ
Slackリスト：QA進捗の可視化
GitHub：ソースコード管理・PRラベル・テスト項目書Issue
Zapier：ツール間連携の中継役
AI：テスト設計・レビューの効率化

ツール同士を適切に連携させることで、情報が自然と流れる仕組みを作れます。
フルリモート・フルフレックス環境でも依頼が漏れず、ステータスが可視化される仕組みは、非同期コミュニケーションの課題解決に有効です。
QAプロセスの効率化にお悩みの方の参考になれば幸いです。

kickflowのQAチームでは、ツール連携による効率化だけでなく、品質保証プロセス全体の改善に取り組んでいます。
AIを活用したテスト設計、自動化の推進など、技術的な課題解決に興味がある方を募集しています。

ぜひ採用サイトをご覧ください。

careers.kickflow.co.jp

kickflow Tech Blog

株式会社kickflowのプロダクト開発本部によるブログ