【AI活用】Backlogの新機能「課題一括登録」でプロジェクト計画を自動作成する方法

Backlog用タスク生成プロンプトのテンプレート

役割設定

あなたは、経験豊富なプロジェクトマネージャー兼システムアーキテクト・エンジニアである。

最重要指示

プロジェクトの「現実的なスケジュール作成」と、それに伴う「マイルストーンの適切な調整」を最優先事項とし、提案すること。バッファは考慮しない。

基本指示

以下の指示とプロジェクト情報に基づき、AIの思考プロセスサマリーと具体的なタスクリストを出力せよ。思考プロセスサマリーとタスクの詳細はMarkdown形式で記述すること。
–

出力形式

AIの思考プロセスサマリー（Markdown形式）

プロジェクト理解と前提設定のポイント

プロジェクト概要の主要な理解点。
スケジュール・工数妥当性評価と前提工数。
チーム総キャパシティの試算（メンバー構成、期間、休日、稼働率を考慮）。
ユーザー提供工数見込みとキャパシティの比較、および実現可能性に関する主要な懸念事項（もしあれば）。
本計画の前提となる「実質総工数（時間単位）」の提案値とその根拠の要点。
不明瞭点と対応方針の要点（例：確認タスクの必要性など）。
設定した主要な前提条件（提案実質総工数、スコープ調整の可能性など）。

WBS設計とタスクブレイクダウン方針のポイント

主要なWBS構成（トップレベルのフェーズや成果物）。
タスク分割の基本方針（粒度：1日～数日程度）。
リスク管理の組み込み方針（主要リスク特定と対応策の概要、リスク管理関連タスクの計画）。

工数見積もりとスケジュール策定のポイント

各タスク工数見積もりの基本的な考え方（提案実質総工数内での配分）。
タスク依存関係考慮とスケジュール構築のポイント。クリティカルパスの意識。
担当者割り当ての基本方針（スキル、負荷分散）。
現実的なスケジュール構築のための調整点と、それに伴うマイルストーン調整案の要点（バッファ考慮なし）。
その他、課題作成にあたっての特記事項や判断基準の要点。

タスクリスト（タイトル）

タスクリスト作成の基本方針

以下のプロジェクトマネジメント手法の原則を各タスクに適用し、具体的かつ実行可能なタスクをリストアップすること。

WBS (Work Breakdown Structure) の概念の導入：プロジェクトや機能を管理可能な階層構造に分解しタスクを洗い出す。

プロジェクトフェーズの考慮： 一般的な開発ライフサイクルやプロジェクト概要記載のフェーズを意識してタスクをグループ化・順序化する。

INVEST原則の適用：各タスクが独立し、交渉可能で、価値があり、見積もり可能で、小さく、テスト可能であること。

SPIDRの考え方の適用：大きなタスクはINVEST原則（特に「Small」）を満たすよう適切に分割する。

網羅性の確保：特に以下の種類のタスクが漏れなく含まれること（計画・準備、要件定義、設計、実装、テスト、ドキュメント、マーケティング・通知、リリース準備、リリース後、インフラ、レビュー・承認、プロジェクト管理、リスク管理に関するタスクを網羅する）。

工数見積もり：各タスクの『予定時間』を、1時間単位で現実的に見積もること（1タスクあたり1日～数日程度）。

担当者割り当て：メンバーのスキルや役割、負荷を考慮して割り当てること。

日付設定のルール：『予定時間』8時間を1営業日目安とし、週末・休日を避け、依存関係を考慮し、プロジェクト期間内に収まる現実的な日付を設定すること（バッファ考慮なし）。

タスクは”詳細”の項目を複数行にわたって詳細に記述できるように、表形式でなく各タスクごとに見出しを設定しMarkdown形式で出力すること。

タスク作成要件

件名：タスク内容を具体的かつ簡潔に記述すること。プレフィックスは不要。
詳細：以下のようなフォーマットで各タスクの目的、具体的な作業内容、受け入れ基準（可能であれば）、考慮事項、参照資料、関連リスク情報などを記述すること。
“`
### 目的: ～
### 作業内容: ～
### 受け入れ基準: ～
### 参照資料: ～
### リスク・考慮事項: ～
“`
種別：原則として「タスク」とする。必要に応じてより具体的に設定すること。

担当者：適切な担当者を1名設定すること。

開始日：2025-03-31の形式。各タスクの「予定時間」、タスク間の大まかな依存関係、プロジェクト全体の期間を考慮し、週末（土日）を非稼働日として現実的な日付を設定すること。

期限日：2025-03-31の形式。上記「開始日」と同様の考慮事項に基づき、各タスクの「予定時間」に応じた現実的な完了日を設定すること。タスクは複数日にまたがってよい。

予定時間：各タスクの規模に応じた適切な時間（例: 4h, 8h, 16h）を見積もり、その数値のみ（例: 4, 8, 16）を設定すること。

実績時間：すべて空欄とすること。

カテゴリー：（任意）機能単位や作業種別で分類すること。

バージョン: すべて空欄とすること。

マイルストーン：プロジェクトのフェーズや主要リリースポイントに合わせて設定すること。AIがスケジュール調整を行った場合は、調整後のマイルストーン日程を反映させること。

優先度：タスクの重要度に応じて「高」「中」「低」で設定すること。基本は「中」とし、クリティカルパス上やセキュリティ関連は「高」とする。

日付設定に関する特記事項

「予定時間」8時間を1営業日として換算の目安とすること（例: 16時間なら2営業日、24時間なら3営業日）。

開始日および期限日が週末（土日）にならないよう調整すること。

タスクの依存関係（例: 設計後にデザイン、デザイン後に開発など）を考慮し、全体のスケジュールがプロジェクト期限内に収まるようにすること。
–

プロジェクト情報

プロジェクトの概要
当社提供のSaaSは、企業内のチームでタスクやファイル、スケジュールを安全かつスムーズに共有・管理できるクラウド型業務支援ツールである。多くの顧客が情報管理に高いセキュリティ要件を求めており、特にアクセス制御や認証まわりの信頼性が導入判断に大きな影響を与えている。

従来はメールアドレス＋パスワードによるログイン機構を採用していたが、大企業を中心に「二要素認証（2FA）への対応」「セッション管理ポリシーの強化」が求められてきた。これを受け、本プロジェクトではセキュリティ強化に直結する認証まわりの機能を総合的に刷新する。

主なスコープ

二要素認証（2FA）機能の追加：ログイン時にSMSまたは認証アプリ（TOTP準拠）によるコード入力を求めるオプションを導入する。サーバーサイド（Go）で認証コードの生成・検証、外部SMS基盤（Twilio予定）連携、ユーザーごとの設定保持を実装。クライアント（Next.js/React）では設定画面やオンボーディングUIを新設する。

セッション管理の強化：セッションの有効期間、IPアドレス制限、デバイスごとのログイン履歴表示・手動失効などを実装する。CookieとJWTベースの構成を維持し、刷新されたセッションミドルウェアを採用。「他端末からのログアウト」などのUX改善も行う。

セキュリティポリシー管理機能：管理者が2FA必須化やセッション期限をチーム単位で設定できる管理画面機能を追加する。

デザインと利用誘導：Figmaでのプロトタイピングとユーザーテストを経て、設定画面やログインフローを改善する。導線・文言・エラー表示も設計し、導入体験を向上させる。

マーケティングおよび通知施策：背景と使い方を伝えるブログ記事2本を公開し、既存ユーザにメール通知を2回実施（SendGrid）。FAQやサポート連携も整備する。

インフラ対応：外部連携やミドルウェア導入のため、Staging環境を強化し、監視ルール（Datadog/Slack）を見直す。構成はTerraform（IaC）で管理する。

期間・工数・体制：

期間：2025年7月1日開始、2025年11月1日正式リリース。

工数見込み：合計20人月前後。

体制：開発メンバー2名（フルスタック）、インフラ担当1名、デザイナー1名。

進行：2週間ごとのスプリント制。

フェーズ計画：

フェーズ1：要件定義・仕様策定（1スプリント）
フェーズ2：設計・実装（4スプリント）
フェーズ3：結合テスト・脆弱性試験（1スプリント）
フェーズ4：マーケ施策準備・本番環境への切替（1スプリント）

プロジェクトの意義：

本機能追加により、セキュリティ要件を理由に導入を見送っていた企業への展開が可能になり、新規契約率の向上と解約率の低下が期待される。既存顧客の安心感向上、利用継続率の改善、問い合わせ件数の削減にもつながる。本件は、SaaSの信頼性をプロダクト価値として打ち出す戦略的投資である。

主な担当者とスキル：

林：PdM
江口：インフラ担当エンジニア
佐藤：フロントエンド担当エンジニア
中原：サーバサイド担当エンジニア
麻生：サーバサイド担当エンジニア
飯田：デザイナー
–

最終指示

上記全ての指示を反映し、最初に思考プロセスサマリー、次にタスクリストを出力せよ。

AIによる思考プロセスサマリー（出力例抜粋）

プロジェクト理解
SaaSの信頼性と市場競争力を向上させるための戦略的なセキュリティ強化であり、事業目標に直結する重要施策と位置づけています。

前提設定
計画工数と現実的な稼働時間には約3人月のギャップがあるため、リリース日厳守にはスコープの柔軟な調整を必須の前提とします。

WBS設計
プロジェクトを主要フェーズで階層化し、タスクを数日で完了する単位に分解しました。品質担保のためレビュー工程を必須としています。

スケジュール策定
バックエンド実装を核とするクリティカルパスを意識し、スプリント単位ではなく成果物ベースの現実的なマイルストーンを再設定しました。

リスク管理
最大リスクである「工数不足による遅延」には進捗監視とスコープ調整で対応し、「セキュリティリスク」には脆弱性診断を計画に組み込みます。

AIによるタスクリスト（出力例抜粋）

• プロジェクトキックオフミーティング
• 開発・テスト・Staging環境のセットアップと確認
• 2FA機能（SMS/TOTP）の要件定義
• [技術検証] 外部SMS送信API（Twilio）のPoC
• [インフラ] TerraformによるStaging環境の強化
• 結合テスト計画書の作成
• ユーザー向けヘルプ・FAQコンテンツの作成
• リリース手順書の作成とレビュー
• …（以下、プロジェクト全体で数十のタスク）

プロンプト例

上記で生成したタスクリストをCSVフォーマットで出力せよ。

【重要】一括登録前の最終確認

課題の一括登録は非常に強力な機能ですが、一度に多くの課題が作成されるため、本番のプロジェクトに適用する前に、必ずテスト用のプロジェクトでリハーサルを行うことを強く推奨します。

生成されたCSVファイルの内容が、Backlog上で意図した通りに登録されるか（例えば、ガントチャートの日付や担当者の割り当てなど）を事前に検証することで、手戻りを防ぎ、よりスムーズにプロジェクトをスタートできます。