Asana セクションルール

📢 2025年改訂版
スクラム開発体制への移行に伴い、セクションルールを全面改訂しました。メインプロジェクトとスクラムプロジェクトの2つに分かれています。

🔄

変更の背景

スクラム開発体制への移行理由と改善ポイント

📋

メインプロジェクト

要件定義からスクラム選抜までの10セクション

🏃

スクラムプロジェクト

スプリント単位での開発・リリース管理

📊

遷移フロー

プロジェクト間のセクション遷移の全体像

セクションルール変更の背景

⚠️ 重要な変更
2025年より、スクラム開発体制に移行しました。これに伴い、タスク管理のセクションルールが大きく変更されています。

移行の理由

従来の開発フローでは以下の課題がありました:

課題	詳細	影響
リリースタイミングのバラつき	タスクごとに個別にリリースされるため、リリース管理が煩雑化	高
進捗の属人化	各エンジニアが複数タスクを抱え、進捗が見えにくい状況	中
コンフリクトリスク	並行開発による競合が頻発し、手戻りが発生	高

✅ 改善効果
スクラム開発への移行により、スプリント単位での計画的な開発とチーム全体での進捗可視化を実現します。

メインプロジェクト（要件定義〜スクラム選抜まで）

メインプロジェクトでは、タスクの起票から要件定義、見積もり、スクラム選抜までを管理します。

1. AI要件定義

AI自動実行

AIが要件定義を自動実行中のセクションです。Claude CodeのAI駆動開発により、Asanaタスクから自動で要件定義書が生成されます。

2. 要件定義PR待ち

エンジニア/上長

要件定義書のPRがGitHubに作成され、レビュー待ちの状態です。レビュアーはPR上でコメント・承認を実施します。

3. 見積もり・設計書作成

エンジニアボール

Claude AIを使用して設計書作成と工数算出を行うセクションです。

4. 依頼検討中

依頼者ボール

見積もりをもとに、費用対効果を確認いただき、問題なければ着手依頼をエンジニアチームに出してください。

5. 依頼確定済み

エンジニアボール

スクラム選抜の待機状態です。次のスプリント計画時に、優先度と工数を考慮してスクラムプロジェクトに選抜されます。

自動化フロー詳細

エンジニアが以下の手順で作業を行うと、自動でセクション移動・PR作成・Slack通知まで一気通貫で実行されます。

自動処理	内容
PR作成	設計書のPRをGitHubに作成し、上長をレビュアーに指定
Asanaコメント	PRリンク付きでコメントを追加
Slack通知	スレッド形式で上長にメンション付き通知
セクション移動	自動でセクション移動

承認ルールの詳細

承認について

10H以上の工数がかかるタスクは古屋敷さんの承認が必要です
10H以上の場合は承認を取得してください
10H以下のタスクは設計書承認が完了していれば着手可能です

ケース	アクション
依頼する場合	コメントにて「着手お願いします。」
承認が必要な場合	承認取得後、承認を取得した旨を追加しコメントで着手依頼

その他のセクション

✅

6. スクラム選抜中

エンジニアボール

スクラムプロジェクトで開発中のタスクです。実際の構築・テスト・リリースはスクラムプロジェクト（スプリント単位）で管理されます。

🎉

7. 完了

タスクが完了し、本番環境にリリース済みの状態です。対応の必要はありません。

🗑️

8. ゴミ箱

削除予定のタスクです。

🔮

9. 展望

将来的に検討・実装を予定しているタスクです。来期以降の計画や長期的なアイデアを管理します。

⏸️

10. 保留

何らかの理由で保留となっているタスクです。長期滞留により開発凍結となったタスクもこちらで管理します。

プロジェクト間のセクション遷移フロー

メインプロジェクトとスクラムプロジェクト間のタスク遷移を視覚的に示します。

【メインプロジェクト】

要件定義 → 見積もり → 依頼確定

↓

5. 依頼確定済み

スクラム選抜の待機状態

↓

(スプリント計画時に選抜)

優先度と工数を考慮してタスク選抜

↓

6. スクラム選抜中 ← 【スクラムプロジェクト】で管理

開発・テスト・リリースをスプリント単位で実施

↓

(スプリント完了後)

本番リリース完了

↓

7. 完了

タスク完了・本番環境リリース済み

スクラムプロジェクト（スプリント単位）

スクラムプロジェクトでは、メインプロジェクトから選抜されたタスクの開発〜リリースまでを管理します。

スプリント（通常1〜2週間）ごとに計画・実行・リリースを繰り返します。

💡 スプリント方式
1〜2週間単位で計画・実行・リリースを繰り返すアジャイル開発手法です。チーム全体で進捗を可視化し、定期的にリリースすることで品質と速度を両立します。

スクラムプロジェクトのセクション

セクション	担当	概要	ステータス
1. スクラム選抜済み（待機）	エンジニア	メインプロジェクトから引き渡された、スプリントで開発予定のタスク	待機
2. 構築中	エンジニア	AI/エンジニアが実装を進めている状態	進行中
3. 構築物のPR	エンジニア	実装が完了し、コードレビュー中の状態	レビュー
4. テスト環境確認中	依頼者	テスト環境にデプロイ済みで、依頼者による動作確認待ち	確認待ち
5. テスト環境確認済み・リリース待機	エンジニア	テスト環境での確認が完了し、本番リリース日を待っている状態	待機
6. 本番リリース済み	依頼者	本番環境にリリースが完了している状態	完了
7. リリース不可・持ち越し	エンジニア	何らかの理由でスプリント内にリリースできなかったタスク	持ち越し
8. エラー・緊急タスク対応が来なかった場合に消化予定	エンジニア	緊急タスクやエラー対応が発生しなかった場合に着手する予備タスク	予備

テスト環境確認の詳細手順

確認事項

構築物に認識の相違がないか確認してください
テストの実施方法は担当者のコメントを確認してください
テストで問題なければ、確認完了しテスト完了の旨をコメントしてください

⚠️ 注意
相違がある場合は構築中セクションに戻します。

持ち越しの主な理由

実装が予定より遅延
テスト環境での問題が解決しない
依頼者の確認が完了しない
外部要因（API変更、他システムの影響など）

予備タスクの運用ルール

// 予備タスクの運用フロー
if (緊急タスクが発生しない && リソースに余裕がある) {
    予備タスクセクションから優先度順に着手();
} else if (緊急タスクが発生) {
    予備タスクは次スプリントに繰り越し();
}

✅ メリット
予備タスクを用意することで、スプリント期間を最大限活用し、計画外の空き時間も効率的に消化できます。

📝 Quick Checklist

メインプロジェクトでやること

✅ AI要件定義が自動で完了することを確認
✅ 要件定義PRをレビュー・承認
✅ 設計書作成・工数見積もりを実施
✅ 10H以上のタスクは承認を取得
✅ 依頼確定後は依頼確定済みセクションに移動

スクラムプロジェクトでやること

✅ スプリント計画でタスクを選抜
✅ 構築 → PR → テスト環境確認のフローを遵守
✅ テスト環境で依頼者確認を必ず実施
✅ スプリント最終日に一括リリース
✅ リリース不可の場合は次スプリントに持ち越し

よくあるミス

ミス	正しい対応
10H以上のタスクを承認なしで進める	必ず古屋敷さんの承認を取得してから着手依頼
テスト環境確認をスキップ	必ず依頼者による動作確認を実施
個別にリリースしてしまう	スプリント最終日に一括リリース
相違があってもそのまま進める	相違がある場合は構築中に戻す