3秒まとめ
-
この記事の目的
- みやっち氏作のAI PMワークフローの理解と社内プロジェクトへの応用可能性の探求
-
内容
- AI PMの概要とコンセプト
- 「aipm_v0」の説明
- 「オンライン定性調査プラットフォーム構築」における活用シミュレーション。8年前に企画してローンチしたサービス。
- 考察や応用事例。示唆が多いので解説。
-
期待される効果
- プロジェクト管理業務の効率化と質の向上
- AI AgentやDigital Twin、ドキュメンテーションワークフローへの応用
AI PMとは？
- AIを活用した、プロジェクトマネジメントの新しいアプローチです。
-
目的:
- プロジェクト計画の自動生成・最適化
- タスクの割り当てと進捗管理の支援
- リスク予測と早期警告
- コミュニケーションの円滑化
-
期待されるメリット:
- プロジェクトマネージャー（PM）の負担軽減
- 意思決定の迅速化と精度向上
- プロジェクト成功率の向上
知ったきっかけ
みやっち氏作「aipm_v0」の概要
- GitHub: miyatti777/aipm_v0
-
コンセプト (リポジトリのREADMEなどから引用・要約):
- 例: LLMを活用し、プロジェクトの初期構想からタスク分解、進捗管理までを支援するツール
-
主な機能 (同上):
- プロジェクト概要からのWBS生成
- タスクカードの自動作成
- 進捗報告の集約と分析
-
特徴 (同上):
- 特定のLLMに依存しない設計（想定されています）
- シンプルなインターフェース
aipm_v0のワークフロー
本家のREADMEが崩れていたので引用して整形。
┌──────────────────────────────┐ trigger（チャットコマンド）
│ 00_master_rules.mdc │◀───────────────────────┐
└─────────┬────────────────────┘ │
│call │
┌─────────▼────────────┐ 発散/収束も Draft 化 │
│ 01‑06_pmbok_*.mdc │──────────────────┐ │
│ 08_flow_assist.mdc │ create_draft │ │
└─────────┬────────────┘ │ │
│ │ │
▼ Draft (.md) │ │
Flow/YYYYMM/YYYY‑MM‑DD/─────────────┘ │
│ human review + "確定反映して" │
▼ │
Stock/programs/PROGRAM/projects/PROJECT/.. ← flow_to_stock_rules.mdc
もう少し簡略化すると以下。
要するに、事前に定義されたルールやテンプレートを使って一時的な文書（Draft）を生成し、人間がレビューした後に確定版（Stock）として保存するというワークフローです。
READMEを読んだのですが、いろいろな知見、理論が組み込まれています。すぐに理解するのは難しいのでサラッと読んで以下の実行例を見てみると雰囲気をつかめると思います。
ケーススタディ：社内プロジェクトへの適用
-
プロジェクトテーマ:
「オンラインで完結する定性調査プラットフォームの構築」 -
背景:
- 既存の定性調査プロセスにおける課題（時間、コスト、地理的制約など）
- オンライン化による効率化とリーチ拡大の期待
-
AI PM (aipm_v0) を使った実践:
- プロジェクトの起案 (aipm_v0へのインプット作成)
- AIによるタスク分解とスケジュール案の生成
- 生成された計画の評価と調整
- 開発管理のシミュレーション
ここ以降の流れで作ったドキュメント類はこちらにpushしてあります。こちらを見たほうがわかりやすいかも。
0. 初期設定
リポジトリをcloneし、初期セットアップスクリプトを実行します。
これは、メインとなるルールのダウンロードとサンプルとなるプロジェクトのダウンロードが行われます。
git clone git@github.com:miyatti777/aipm_v0.git
cd aipm_v0
./setup_workspace_simple.sh setup_config.sh
本来はこのあたりをカスタマイズする必要がありますが、今回はそのまま使用します。
以下のディレクトリ構成が作られました。
❯ tree .cursor/
.cursor/
└── rules
└── basic
├── 00_master_rules.mdc
├── 01_pmbok_initiating.mdc
├── 02_pmbok_discovery.mdc
├── 02_pmbok_research.mdc
├── 03_pmbok_planning.mdc
├── 04_pmbok_executing.mdc
├── 05_pmbok_monitoring.mdc
├── 06_pmbok_closing.mdc
├── 07_task_management.mdc
├── 08_pmbok_flow_assist.mdc
├── 09_pmbok_development.mdc
├── 90_rule_maintenance.mdc
├── pmbok_paths.mdc
└── templates
├── daily_tasks_template.md
├── meeting_minutes_template.md
└── weekly_review_template.md
❯ tree
.
├── Archived
│ └── projects
├── Flow
│ └── 202505
│ └── 2025-05-08
├── README.md
├── scripts
│ └── test.sh
├── setup_config.sh
├── setup_workspace_simple.sh
└── Stock
└── programs
├── 夕食作り
│ └── projects
│ └── カレー
│ ├── documents
│ │ ├── 1_initiating
│ │ │ └── project_charter.md
│ │ ├── 2_discovery
│ │ │ ├── persona.md
│ │ │ ├── problem_statement.md
│ │ │ └── solution_definition.md
│ │ ├── 3_planning
│ │ │ ├── backlog
│ │ │ │ ├── backlog.yaml
│ │ │ │ ├── epics.yaml
│ │ │ │ └── stories
│ │ │ │ └── US-001.md
│ │ │ ├── roadmap
│ │ │ │ └── product_roadmap.md
│ │ │ └── wbs.md
│ │ └── 4_executing
│ │ ├── daily_tasks
│ │ │ └── daily_tasks_2025-05-05.md
│ │ └── sprint_goals
│ │ └── sprint_goals_1.md
│ └── README.md
└── Common
└── Public
Cursor用のProject Ruleで書かれています。
Cursor要のProject Ruleとmdcの説明は以下を参照。
私はCursorを使用していないため、Clineで代用します。Clineもmdcで書かれたProject Ruleを理解してくれます。
LLMには、最近筆者が気に入っているGemini 2.5 Proを使用します。
Custom Instructionには、aipm_v0のREADMEにある手順に従い、以下の情報を入力しておきます。
#========================================================
# 0. ベースポリシー
#========================================================
! Always respond in 日本語
- 成果物はできるだけファイルとして出力（細かく分割）
- MCP やファイル閲覧など可能な作業は自律実行
- タスク依頼時は不足情報を確認し、自ら計画→ゴールまで進行
- 立てた計画はタスクリストとして提示
- 日付に関する処理をやるときは、必ずdate関数で正確な情報を確認
#========================================================
# 1. 必須ルールファイル参照（pre‑load）
#========================================================
required_rule_files:
- .cursor/rules/basic/
- .cursor/rules/basic/01_pmbok_initiating.mdc
- .cursor/rules/basic/03_pmbok_planning.mdc
- .cursor/rules/basic/04_pmbok_executing.mdc
- .cursor/rules/basic/02_pmbok_discovery.mdc
- .cursor/rules/basic/02_pmbok_research.mdc
- .cursor/rules/basic/pmbok_paths.mdc
- .cursor/rules/basic/06_pmbok_closing.mdc
- .cursor/rules/basic/90_rule_maintenance.mdc
- .cursor/rules/basic/09_pmbok_development.mdc
- .cursor/rules/basic/templates
- .cursor/rules/basic/templates/daily_tasks_template.md
- .cursor/rules/basic/templates/meeting_minutes_template.md
- .cursor/rules/basic/templates/weekly_review_template.md
- .cursor/rules/basic/00_master_rules.mdc
- .cursor/rules/basic/07_task_management.mdc
- .cursor/rules/basic/08_pmbok_flow_assist.mdc
- .cursor/rules/basic/05_pmbok_monitoring.mdc
1. 立ち上げ
これは、プロジェクトの初期設定に相当します。
READMEの指示通りに、プロジェクトのドキュメントを構築するためのコマンドを実行します。
最初にプロジェクト名を尋ねられるため、以下のように入力しました。 このプロジェクトは、筆者が所属する企業の創業時に考案したシステムの内容です。
オンラインで定性調査を行うプラットフォームサービスの構築
10年近く前に考案した内容ですが、企画立案からサービスローンチ、運用、機能開発まで一通り経験したサービスであるため、LLMの出力と実際の経験との差分を比較しながら評価しやすいと考え、これを選定しました。
次に、"プロジェクトの背景と目的" を尋ねられました。 背景を説明すると長くなるため、今回はGemini 2.5 Proに生成を依頼しました。
# 背景
1. **地理的・時間的制約の克服:**
* 従来の対面でのインタビューやグループ調査では、参加者が特定の場所に集まる必要があり、地理的な制約や移動に伴う時間的・経済的コストが発生していました。特に、広範囲な地域からの意見収集や、多忙な参加者へのアプローチが困難でした。
* オンライン化により、居住地に関わらず多様な参加者を集めることが可能になり、日程調整の柔軟性も向上します。
2. **コスト効率の改善:**
* 会場費、交通費、謝礼以外の運営コスト（人件費の一部など）を削減できる可能性があります。
* これにより、従来は予算的に難しかった小規模な調査や、頻繁な調査実施のハードルが下がります。
3. **多様な参加者へのアクセス:**
* ニッチなターゲット層や、特定の属性（例：子育て中の親、特定の疾患を持つ患者、地方在住者など）を持つ人々にも、オンラインであればリーチしやすくなります。
* 匿名性を確保しやすいオンライン環境は、デリケートなテーマに関してより率直な意見を引き出せる可能性も秘めています。
4. **デジタルトランスフォーメーション（DX）の流れ:**
* あらゆる業界でDXが加速しており、マーケティングリサーチの分野も例外ではありません。企業はより迅速かつ効率的なデータ収集・分析手法を求めています。
* オンラインツールを活用した業務効率化は、現代のビジネスにおける標準となりつつあります。
5. **新しい生活様式と働き方の定着:**
* 新型コロナウイルス感染症のパンデミック以降、オンラインコミュニケーションが一般化し、人々はオンラインでの活動に慣れ親しんでいます。
* リモートワークの普及などにより、オンラインでの調査参加への心理的な抵抗感も低減していると考えられます。
6. **テクノロジーの進化:**
* 高品質なビデオ会議システム、チャットツール、オンラインホワイトボード、AIを活用した文字起こしや感情分析ツールなどが登場し、オンラインでも質の高い定性調査を実施できる環境が整ってきました。
* これらの技術を活用することで、対面調査に近い、あるいはそれ以上の体験価値を提供できる可能性があります。
# 目的
1. **より多くの企業・組織に定性調査の機会を提供:**
* 地理的・時間的・コスト的な制約を軽減することで、これまで定性調査の実施をためらっていた企業や組織（特に中小企業やスタートアップ、地方の団体など）にも、その活用を促進します。
* これにより、顧客理解を深め、より的確な意思決定を行うためのインサイト獲得を支援します。
2. **調査プロセスの効率化と迅速化:**
* 参加者の募集・スクリーニング、インタビューやグループディスカッションの実施、記録・分析といった一連のプロセスをプラットフォーム上で一元管理できるようにし、調査担当者の負担を軽減します。
* 従来よりも短期間で調査を完了させ、スピーディーな意思決定に貢献することを目指します。
3. **質の高いインサイトの獲得支援:**
* 多様なバックグラウンドを持つ参加者からの、より本質的で深層心理に迫る意見を効率的に収集できる環境を提供します。
* 動画や音声、テキストデータだけでなく、チャットログ、画面共有、オンラインホワイトボード上の共同作業など、多様な形式のデータを収集・分析できる機能を提供し、より多角的な分析を可能にします。
4. **新しい調査手法の開拓と提供:**
* オンラインならではの特性を活かした新しい定性調査手法（例：非同期型インタビュー、オンラインエスノグラフィ、バーチャル空間でのグループディスカッションなど）を開発・提供し、定性調査の可能性を広げます。
* AIなどの最新技術を積極的に取り入れ、データ分析の高度化や効率化を図ります。
5. **ユーザーフレンドリーなプラットフォームの実現:**
* 調査依頼者、調査実施者（モデレーター）、調査参加者のそれぞれにとって、直感的で使いやすいインターフェースと体験を提供します。
* セキュリティとプライバシー保護にも万全を期し、安心して利用できる環境を構築します。
6. **定性調査市場における新たな価値創造:**
* 既存の調査手法の課題を解決し、オンラインの強みを最大限に活かすことで、定性調査市場において独自のポジションを確立し、新たな価値を提供することを目指します。
* 将来的には、収集された定性データのナレッジベース化や、他のデータとの連携による新たなインサイト創出なども視野に入れる可能性があります。
コアな部分や、課題の核心を突くような深みはまだ見られませんが、もっともらしい立派な文章を生成してくれます。スコープや表面的な内容は適切だと思われるため、このまま進めます。
次に、「含まれる範囲」についてです。
# 含まれる範囲
**１．機能的な範囲（プラットフォームで何ができるか）**
* **コア機能:**
* **オンラインインタビュー支援:** 1対1のデプスインタビューや、複数名でのグループインタビューを実施するためのビデオ通話、チャット、画面共有、録画・録音機能。
* **参加者管理:** 調査参加者の募集（外部連携含む）、スクリーニング、スケジュール調整、インセンティブ管理支援。
* **実査サポート:** インタビューガイドの表示、資料共有、オンラインホワイトボードなどの共同作業ツール。
* **データ管理・簡易分析支援:** 録画データの保存・共有、自動文字起こし（外部連携または内製）、発言内容のタグ付けやコメント付与といった簡易的なコーディング機能。
* **将来的/段階的に検討する機能:**
* より高度なテキストマイニングや感情分析機能。
* レポーティング支援機能（簡易レポート自動生成など）。
**２．対象ユーザーの範囲（誰が使うのか、誰を対象にするのか）**
* **主な利用企業・部門:**
* 新製品・サービス開発や既存事業の改善に取り組む企業のマーケティング部門、商品企画部門、UXリサーチャー。
* 顧客理解を深めたいスタートアップ企業。
* 広告代理店やコンサルティングファームのリサーチ部門。
* **調査参加者:**
* 初期は国内の一般消費者を主な対象とし、将来的には特定の属性（BtoB、専門職など）や海外の参加者への拡張も視野に入れます。
* リクルーティングは、クライアント保有リストの活用、提携パネル事業者との連携、SNSなどを通じた公募などを想定しています。
**３．サービス提供範囲（どこまでサポートするか）**
* **プラットフォーム提供:** 上記機能を有するSaaSとしてのプラットフォーム提供が基本となります。
* **サポート体制:**
* システムの利用方法に関するテクニカルサポート。
* 初期導入時のオンボーディング支援。
* **オプション/将来検討:**
* 調査設計のコンサルテーション。
* モデレーターやリクルーティング代行などの付加サービス（自社またはパートナー連携）。
* 多言語対応（現在は日本語を想定）。
**現時点でのスコープ外（何を含まないか）**
* オフラインでの会場手配や実査運営。
* 大規模な定量調査の実施・分析機能。
* 高度な専門知識を要する学術研究レベルの分析ツール（初期フェーズでは）。
**基本的な考え方**
まずは、オンラインでの定性調査を「手軽に」「効率的に」「質の高いインサイトを得られる形で」実施できるコアな機能群に絞り、利用者のフィードバックを得ながら段階的に機能拡充と対象範囲の拡大を図っていく方針です。特に、ユーザー自身が直感的に操作でき、調査の準備から実査、簡易的なデータ整理までをスムーズに行える点に注力いたします。
次に、「含まれない範囲」についてです。
# 含まれない範囲
**１．オフラインでの調査実施および関連業務全般**
* **会場手配・運営:** インタビューやグループディスカッションのための物理的な会場の予約、設営、当日の運営サポートなどは行いません。
* **調査員の派遣:** モデレーターや書記、受付スタッフなどを現地に派遣するサービスは提供いたしません。
* **郵送調査・訪問調査の管理:** 調査票の郵送、回収管理、または調査員が対象者の自宅や職場を訪問して行う調査のロジスティクス管理は範囲外です。
* *理由：私たちの強みはオンラインに特化しており、オフライン業務は専門外であるためです。*
**２．大規模な定量調査の機能**
* **アンケート配信システム:** 数百～数千人規模のアンケートを作成し、一斉に配信・回収・集計するような、いわゆる「定量調査」を主目的としたシステム機能は搭載していません。
* **高度な統計解析ツール:** 複雑な統計モデルを用いた分析や、多変量解析といった高度な統計処理機能は提供範囲外です。
* *理由：本プラットフォームは、数値データで捉えきれない「なぜそう思うのか」「どのような背景があるのか」といった質的な情報を深く掘り下げることに特化しているためです。*
**３．フルサービス型のリサーチプロジェクト代行**
* **総合的な調査企画・設計コンサルティング:** お客様の課題抽出から、最適な調査手法の選定、設問設計までを全て弊社が請け負う形のコンサルティングサービスは、プラットフォームの標準機能には含まれません。
* **リサーチ実査・分析・報告書作成の完全アウトソース:** モデレーション、対象者リクルーティング、データ分析、洞察の抽出、最終報告書の作成まで、調査プロジェクト全体を丸ごと代行するサービスは、現時点では提供しておりません。
* *理由：私たちは、お客様自身が主体的に、かつ効率的に定性調査を実施するための「ツール」と「環境」を提供することに主眼を置いています。ただし、操作サポートや一部オプション（例：提携モデレーターの紹介など）は検討可能です。*
**４．専門分野に特化した特殊な機能やサービス**
* **特定の学術研究用の高度な分析ツール:** 例えば、特定の心理学理論に基づいたコーディングシステムや、特定の生体計測データと連動するような専門性の高い分析機能は含みません。
* **法務・医療などの特定業界の厳格な規制に完全準拠した特殊機能:** 一般的なビジネス利用におけるセキュリティや個人情報保護には万全を期しますが、特定の業界（例：医療における治験データの超厳密な管理など）に特化した監査証跡機能や特殊なデータ形式への対応は、現時点では範囲外です。
* **翻訳・通訳サービス:** 多言語対応を将来的に検討する可能性はありますが、プラットフォーム利用における専門の翻訳者やリアルタイム通訳者の手配までは標準サービスに含みません。
* *理由：汎用性と使いやすさを重視し、まずは幅広いお客様にご利用いただけるオンライン定性調査のコア機能の充実に注力するためです。*
**５．プラットフォーム利用と直接関連しない業務サポート**
* **参加者のPC環境や通信トラブルへの個別詳細サポート:** プラットフォーム自体の不具合には対応しますが、調査参加者個人のデバイス設定やインターネット環境に起因する問題解決までを弊社が全面的にサポートするわけではありません（一般的なトラブルシューティングガイドの提供などは検討します）。
これらの範囲設定は、私たちが提供するオンライン定性調査プラットフォームの中核的価値にリソースを集中させ、お客様にとって真に有用なサービスを開発・提供していくためのものです。もちろん、市場のニーズや事業の進捗に応じて、将来的に範囲を見直す可能性はございます。
このあたりは、PMBOKに準拠した内容という印象です。チャット形式で入力できるため、PMBOKの知識がなくても手軽に進められます。
次に、ステークホルダーについて尋ねられました。これについては、スタートアップの雰囲気を出すために2名としました。
# ステークホルダー
「ご質問ありがとうございます。私たちは現在創業前であり、ビジネス担当とCTOの2名がコアメンバーとしてMVP開発を進めています。この状況における主要なステークホルダーは、以下の通りです。
**【コアチーム（事実上の社内ステークホルダー）】**
1. **創業者（私たち自身）:**
* **ビジネス担当（P&G出身）:**
* **役割:** プロダクトビジョン策定、事業戦略立案、顧客開発（ターゲット顧客の特定とヒアリング）、MVPの仮説検証、マーケティング戦略（初期）、資金調達準備（将来的に）、法務・会計などのバックオフィス基盤準備。
* **関心事:** PMF（プロダクトマーケットフィット）の達成、トラクション獲得、事業の持続可能性。
* **CTO（システム開発担当）：**
* **役割:** 技術戦略策定、MVPのアーキテクチャ設計・開発、技術選定、開発プロセスの構築、プロダクトの品質担保、スケーラビリティの考慮。
* **関心事:** 実現可能な技術によるMVPの迅速な構築、安定したプロダクト提供、将来の技術的負債の低減。
* **私たち2名の共通の関心事:**
* ユーザーの課題を解決する価値あるプロダクトの創出。
* 迅速な意思決定と実行によるアジャイルな開発。
* 限られたリソース（時間、資金、人的資本）の最適配分。
* 明確なコミュニケーションと信頼に基づく強力なパートナーシップ。
**【主要な社外ステークホルダー】**
1. **ターゲット顧客 / アーリーアダプター:**
* **対象例:** 私たちが初期に課題解決を目指す、オンライン定性調査に強いニーズを持つ企業担当者（マーケティング、UXリサーチ、新規事業開発など）や、新しいツールを積極的に試したいと考えているリサーチャー。
* **関わり方・重要性:** MVPの仮説検証とPMF達成のために最も重要な存在です。彼らの抱える「具体的な課題」や「既存の解決策への不満」を深くヒアリングし、MVPに対する率直なフィードバック（良い点、悪い点、改善要望）を得ることで、プロダクトを正しい方向に進化させます。デモ、試用、インタビューなどを通じて密接な関係を構築します。
2. **（潜在的な）調査参加者:**
* **対象例:** 上記のターゲット顧客が調査を行いたいと考える一般消費者や、特定の属性を持つ人々。
* **関わり方・重要性:** プラットフォームの価値を成立させるために不可欠な存在です。MVP段階では、どのようにしてこれらの参加者を集め、快適かつ信頼できる調査体験を提供できるかが課題となります。ターゲット顧客が実際に調査を実施できる状態を作るために、この層への配慮も必要です。
3. **メンター / アドバイザー:**
* **対象例:** スタートアップ経営経験者、リサーチ業界の専門家、P&Gや技術系のネットワークを通じて得られる経験豊富な方々、エンジェル投資家でメンタリングも行う方など。
* **関わり方・重要性:** 私たちの経験や知識を補完し、客観的な視点から事業戦略、プロダクト開発、市場アプローチなどについて貴重なアドバイスやフィードバックを提供してくれます。PMF達成への道のりを短縮し、致命的な間違いを避ける上で非常に重要です。積極的に探し、関係を構築すべき対象です。
4. **（必要に応じた）技術パートナー / 外部サービス提供者:**
* **対象例:** 特定のAPI（例: ビデオ会議、AI文字起こし）提供企業、クラウドサービスプロバイダー、フリーランスのデザイナーや専門家（短期的な協力が必要な場合）。
* **関わり方・重要性:** MVP開発を迅速かつ効率的に進めるために、自前で全て開発するのではなく、既存の優れた技術やサービスを適切に活用する場合の協力先です。
次に、予算に関する「スポンサー」についてです。
# スポンサー
実質的な意味でこのプロジェクトを支え、推進している「スポンサー」は、**私たち創業者自身**であると言えます。
具体的には、以下の側面で私たちがスポンサーの役割を担っています。
1. **資金的スポンサーとして：**
* プロジェクトに必要な初期費用は、私たち2名が自らの資金を出し合います。予算は100万円です。つまり、自分たちのアイデアと将来性に対して、自分たち自身が最初の投資家となっている状態です。
2. **リソース（時間・労力）提供者として：**
* 本業以外の貴重な余暇時間をこのプロジェクトの開発と準備に充てています。これは、金銭的な投資以上に重要な「時間」と「情熱」という資源を、プロジェクトの成功のために注ぎ込んでいることを意味します。
3. **ビジョンと推進力の源泉として：**
* このプラットフォームのアイデア、それが解決できる課題、そして目指すべきビジョンを最も強く信じ、実現に向けて情熱を持って取り組んでいるのは、私たち自身です。プロジェクトを前進させる原動力そのものです。
言い換えれば、現時点では、**私たち自身がこのプロジェクトの最大の支援者であり、すべてのリスクを負い、その成功に向けて全面的にコミットしている**という体制です。
この自己完結的なアプローチにより、外部の意思決定プロセスに左右されることなく、迅速かつ柔軟にMVP（Minimum Viable Product）の開発と仮説検証を進めることが可能になっています。
プロダクトの開発がうまくいけば、すぐに売上が見込めるので金銭的な初期投資は登記費用とバーチャルオフィスの月額費用のみで済みます。これにより、私たちのリスクは最小限に抑えられています。
その後、いくつかの細かい質問に回答していきます。
- プロジェクトの開始日と終了日を尋ねられたため、本日を開始日とし、6ヶ月後を終了日として設定しました。
- プロジェクトマネージャーは、Biz担当者としました。
- 予算は、金銭面で10万円とし、加えて筆者の余暇時間（自己投資のため0円として計上）としました。
これにより、プロジェクト憲章のドラフトが作成されました。
# プロジェクト憲章
**プロジェクト名**: オンラインで定性調査を行うプラットフォームサービスの構築
## 1. 背景と目的
# 背景
1. **地理的・時間的制約の克服:**
* 従来の対面でのインタビューやグループ調査では、参加者が特定の場所に集まる必要があり、地理的な制約や移動に伴う時間的・経済的コストが発生していました。特に、広範囲な地域からの意見収集や、多忙な参加者へのアプローチが困難でした。
* オンライン化により、居住地に関わらず多様な参加者を集めることが可能になり、日程調整の柔軟性も向上します。
2. **コスト効率の改善:**
* 会場費、交通費、謝礼以外の運営コスト（人件費の一部など）を削減できる可能性があります。
* これにより、従来は予算的に難しかった小規模な調査や、頻繁な調査実施のハードルが下がります。
3. **多様な参加者へのアクセス:**
* ニッチなターゲット層や、特定の属性（例：子育て中の親、特定の疾患を持つ患者、地方在住者など）を持つ人々にも、オンラインであればリーチしやすくなります。
* 匿名性を確保しやすいオンライン環境は、デリケートなテーマに関してより率直な意見を引き出せる可能性も秘めています。
4. **デジタルトランスフォーメーション（DX）の流れ:**
* あらゆる業界でDXが加速しており、マーケティングリサーチの分野も例外ではありません。企業はより迅速かつ効率的なデータ収集・分析手法を求めています。
* オンラインツールを活用した業務効率化は、現代のビジネスにおける標準となりつつあります。
5. **新しい生活様式と働き方の定着:**
* 新型コロナウイルス感染症のパンデミック以降、オンラインコミュニケーションが一般化し、人々はオンラインでの活動に慣れ親しんでいます。
* リモートワークの普及などにより、オンラインでの調査参加への心理的な抵抗感も低減していると考えられます。
6. **テクノロジーの進化:**
* 高品質なビデオ会議システム、チャットツール、オンラインホワイトボード、AIを活用した文字起こしや感情分析ツールなどが登場し、オンラインでも質の高い定性調査を実施できる環境が整ってきました。
* これらの技術を活用することで、対面調査に近い、あるいはそれ以上の体験価値を提供できる可能性があります。
# 目的
1. **より多くの企業・組織に定性調査の機会を提供:**
* 地理的・時間的・コスト的な制約を軽減することで、これまで定性調査の実施をためらっていた企業や組織（特に中小企業やスタートアップ、地方の団体など）にも、その活用を促進します。
* これにより、顧客理解を深め、より的確な意思決定を行うためのインサイト獲得を支援します。
2. **調査プロセスの効率化と迅速化:**
* 参加者の募集・スクリーニング、インタビューやグループディスカッションの実施、記録・分析といった一連のプロセスをプラットフォーム上で一元管理できるようにし、調査担当者の負担を軽減します。
* 従来よりも短期間で調査を完了させ、スピーディーな意思決定に貢献することを目指します。
3. **質の高いインサイトの獲得支援:**
* 多様なバックグラウンドを持つ参加者からの、より本質的で深層心理に迫る意見を効率的に収集できる環境を提供します。
* 動画や音声、テキストデータだけでなく、チャットログ、画面共有、オンラインホワイトボード上の共同作業など、多様な形式のデータを収集・分析できる機能を提供し、より多角的な分析を可能にします。
4. **新しい調査手法の開拓と提供:**
* オンラインならではの特性を活かした新しい定性調査手法（例：非同期型インタビュー、オンラインエスノグラフィ、バーチャル空間でのグループディスカッションなど）を開発・提供し、定性調査の可能性を広げます。
* AIなどの最新技術を積極的に取り入れ、データ分析の高度化や効率化を図ります。
5. **ユーザーフレンドリーなプラットフォームの実現:**
* 調査依頼者、調査実施者（モデレーター）、調査参加者のそれぞれにとって、直感的で使いやすいインターフェースと体験を提供します。
* セキュリティとプライバシー保護にも万全を期し、安心して利用できる環境を構築します。
6. **定性調査市場における新たな価値創造:**
* 既存の調査手法の課題を解決し、オンラインの強みを最大限に活かすことで、定性調査市場において独自のポジションを確立し、新たな価値を提供することを目指します。
* 将来的には、収集された定性データのナレッジベース化や、他のデータとの連携による新たなインサイト創出なども視野に入れる可能性があります。
## 2. スコープ
- **含む**: # 含まれる範囲
**１．機能的な範囲（プラットフォームで何ができるか）**
* **コア機能:**
* **オンラインインタビュー支援:** 1対1のデプスインタビューや、複数名でのグループインタビューを実施するためのビデオ通話、チャット、画面共有、録画・録音機能。
* **参加者管理:** 調査参加者の募集（外部連携含む）、スクリーニング、スケジュール調整、インセンティブ管理支援。
* **実査サポート:** インタビューガイドの表示、資料共有、オンラインホワイトボードなどの共同作業ツール。
* **データ管理・簡易分析支援:** 録画データの保存・共有、自動文字起こし（外部連携または内製）、発言内容のタグ付けやコメント付与といった簡易的なコーディング機能。
* **将来的/段階的に検討する機能:**
* より高度なテキストマイニングや感情分析機能。
* レポーティング支援機能（簡易レポート自動生成など）。
**２．対象ユーザーの範囲（誰が使うのか、誰を対象にするのか）**
* **主な利用企業・部門:**
* 新製品・サービス開発や既存事業の改善に取り組む企業のマーケティング部門、商品企画部門、UXリサーチャー。
* 顧客理解を深めたいスタートアップ企業。
* 広告代理店やコンサルティングファームのリサーチ部門。
* **調査参加者:**
* 初期は国内の一般消費者を主な対象とし、将来的には特定の属性（BtoB、専門職など）や海外の参加者への拡張も視野に入れます。
* リクルーティングは、クライアント保有リストの活用、提携パネル事業者との連携、SNSなどを通じた公募などを想定しています。
**３．サービス提供範囲（どこまでサポートするか）**
* **プラットフォーム提供:** 上記機能を有するSaaSとしてのプラットフォーム提供が基本となります。
* **サポート体制:**
* システムの利用方法に関するテクニカルサポート。
* 初期導入時のオンボーディング支援。
* **オプション/将来検討:**
* 調査設計のコンサルテーション。
* モデレーターやリクルーティング代行などの付加サービス（自社またはパートナー連携）。
* 多言語対応（現在は日本語を想定）。
**現時点でのスコープ外（何を含まないか）**
* オフラインでの会場手配や実査運営。
* 大規模な定量調査の実施・分析機能。
* 高度な専門知識を要する学術研究レベルの分析ツール（初期フェーズでは）。
**基本的な考え方**
まずは、オンラインでの定性調査を「手軽に」「効率的に」「質の高いインサイトを得られる形で」実施できるコアな機能群に絞り、利用者のフィードバックを得ながら段階的に機能拡充と対象範囲の拡大を図っていく方針です。特に、ユーザー自身が直感的に操作でき、調査の準備から実査、簡易的なデータ整理までをスムーズに行える点に注力いたします。
- **含まない**: # 含まれない範囲
**１．オフラインでの調査実施および関連業務全般**
* **会場手配・運営:** インタビューやグループディスカッションのための物理的な会場の予約、設営、当日の運営サポートなどは行いません。
* **調査員の派遣:** モデレーターや書記、受付スタッフなどを現地に派遣するサービスは提供いたしません。
* **郵送調査・訪問調査の管理:** 調査票の郵送、回収管理、または調査員が対象者の自宅や職場を訪問して行う調査のロジスティクス管理は範囲外です。
* *理由：私たちの強みはオンラインに特化しており、オフライン業務は専門外であるためです。*
**２．大規模な定量調査の機能**
* **アンケート配信システム:** 数百～数千人規模のアンケートを作成し、一斉に配信・回収・集計するような、いわゆる「定量調査」を主目的としたシステム機能は搭載していません。
* **高度な統計解析ツール:** 複雑な統計モデルを用いた分析や、多変量解析といった高度な統計処理機能は提供範囲外です。
* *理由：本プラットフォームは、数値データで捉えきれない「なぜそう思うのか」「どのような背景があるのか」といった質的な情報を深く掘り下げることに特化しているためです。*
**３．フルサービス型のリサーチプロジェクト代行**
* **総合的な調査企画・設計コンサルティング:** お客様の課題抽出から、最適な調査手法の選定、設問設計までを全て弊社が請け負う形のコンサルティングサービスは、プラットフォームの標準機能には含まれません。
* **リサーチ実査・分析・報告書作成の完全アウトソース:** モデレーション、対象者リクルーティング、データ分析、洞察の抽出、最終報告書の作成まで、調査プロジェクト全体を丸ごと代行するサービスは、現時点では提供しておりません。
* *理由：私たちは、お客様自身が主体的に、かつ効率的に定性調査を実施するための「ツール」と「環境」を提供することに主眼を置いています。ただし、操作サポートや一部オプション（例：提携モデレーターの紹介など）は検討可能です。*
**４．専門分野に特化した特殊な機能やサービス**
* **特定の学術研究用の高度な分析ツール:** 例えば、特定の心理学理論に基づいたコーディングシステムや、特定の生体計測データと連動するような専門性の高い分析機能は含みません。
* **法務・医療などの特定業界の厳格な規制に完全準拠した特殊機能:** 一般的なビジネス利用におけるセキュリティや個人情報保護には万全を期しますが、特定の業界（例：医療における治験データの超厳密な管理など）に特化した監査証跡機能や特殊なデータ形式への対応は、現時点では範囲外です。
* **翻訳・通訳サービス:** 多言語対応を将来的に検討する可能性はありますが、プラットフォーム利用における専門の翻訳者やリアルタイム通訳者の手配までは標準サービスに含みません。
* *理由：汎用性と使いやすさを重視し、まずは幅広いお客様にご利用いただけるオンライン定性調査のコア機能の充実に注力するためです。*
**５．プラットフォーム利用と直接関連しない業務サポート**
* **参加者のPC環境や通信トラブルへの個別詳細サポート:** プラットフォーム自体の不具合には対応しますが、調査参加者個人のデバイス設定やインターネット環境に起因する問題解決までを弊社が全面的にサポートするわけではありません（一般的なトラブルシューティングガイドの提供などは検討します）。
これらの範囲設定は、私たちが提供するオンライン定性調査プラットフォームの中核的価値にリソースを集中させ、お客様にとって真に有用なサービスを開発・提供していくためのものです。もちろん、市場のニーズや事業の進捗に応じて、将来的に範囲を見直す可能性はございます。
## 3. ステークホルダー
- **スポンサー**: # スポンサー
実質的な意味でこのプロジェクトを支え、推進している「スポンサー」は、**私たち創業者自身**であると言えます。
具体的には、以下の側面で私たちがスポンサーの役割を担っています。
1. **資金的スポンサーとして：**
* プロジェクトに必要な初期費用は、私たち2名が自らの資金を出し合います。予算は100万円です。つまり、自分たちのアイデアと将来性に対して、自分たち自身が最初の投資家となっている状態です。
2. **リソース（時間・労力）提供者として：**
* 本業以外の貴重な余暇時間をこのプロジェクトの開発と準備に充てています。これは、金銭的な投資以上に重要な「時間」と「情熱」という資源を、プロジェクトの成功のために注ぎ込んでいることを意味します。
3. **ビジョンと推進力の源泉として：**
* このプラットフォームのアイデア、それが解決できる課題、そして目指すべきビジョンを最も強く信じ、実現に向けて情熱を持って取り組んでいるのは、私たち自身です。プロジェクトを前進させる原動力そのものです。
言い換えれば、現時点では、**私たち自身がこのプロジェクトの最大の支援者であり、すべてのリスクを負い、その成功に向けて全面的にコミットしている**という体制です。
この自己完結的なアプローチにより、外部の意思決定プロセスに左右されることなく、迅速かつ柔軟にMVP（Minimum Viable Product）の開発と仮説検証を進めることが可能になっています。
プロダクトの開発がうまくいけば、すぐに売上が見込めるので金銭的な初期投資は登記費用とバーチャルオフィスの月額費用のみで済みます。これにより、私たちのリスクは最小限に抑えられています。
- **主要ステークホルダー**: # ステークホルダー
「ご質問ありがとうございます。私たちは現在創業前であり、ビジネス担当とCTOの2名がコアメンバーとしてMVP開発を進めています。この状況における主要なステークホルダーは、以下の通りです。
**【コアチーム（事実上の社内ステークホルダー）】**
1. **創業者（私たち自身）:**
* **ビジネス担当（P&G出身）:**
* **役割:** プロダクトビジョン策定、事業戦略立案、顧客開発（ターゲット顧客の特定とヒアリング）、MVPの仮説検証、マーケティング戦略（初期）、資金調達準備（将来的に）、法務・会計などのバックオフィス基盤準備。
* **関心事:** PMF（プロダクトマーケットフィット）の達成、トラクション獲得、事業の持続可能性。
* **CTO（システム開発担当）：**
* **役割:** 技術戦略策定、MVPのアーキテクチャ設計・開発、技術選定、開発プロセスの構築、プロダクトの品質担保、スケーラビリティの考慮。
* **関心事:** 実現可能な技術によるMVPの迅速な構築、安定したプロダクト提供、将来の技術的負債の低減。
* **私たち2名の共通の関心事:**
* ユーザーの課題を解決する価値あるプロダクトの創出。
* 迅速な意思決定と実行によるアジャイルな開発。
* 限られたリソース（時間、資金、人的資本）の最適配分。
* 明確なコミュニケーションと信頼に基づく強力なパートナーシップ。
**【主要な社外ステークホルダー】**
1. **ターゲット顧客 / アーリーアダプター:**
* **対象例:** 私たちが初期に課題解決を目指す、オンライン定性調査に強いニーズを持つ企業担当者（マーケティング、UXリサーチ、新規事業開発など）や、新しいツールを積極的に試したいと考えているリサーチャー。
* **関わり方・重要性:** MVPの仮説検証とPMF達成のために最も重要な存在です。彼らの抱える「具体的な課題」や「既存の解決策への不満」を深くヒアリングし、MVPに対する率直なフィードバック（良い点、悪い点、改善要望）を得ることで、プロダクトを正しい方向に進化させます。デモ、試用、インタビューなどを通じて密接な関係を構築します。
2. **（潜在的な）調査参加者:**
* **対象例:** 上記のターゲット顧客が調査を行いたいと考える一般消費者や、特定の属性を持つ人々。
* **関わり方・重要性:** プラットフォームの価値を成立させるために不可欠な存在です。MVP段階では、どのようにしてこれらの参加者を集め、快適かつ信頼できる調査体験を提供できるかが課題となります。ターゲット顧客が実際に調査を実施できる状態を作るために、この層への配慮も必要です。
3. **メンター / アドバイザー:**
* **対象例:** スタートアップ経営経験者、リサーチ業界の専門家、P&Gや技術系のネットワークを通じて得られる経験豊富な方々、エンジェル投資家でメンタリングも行う方など。
* **関わり方・重要性:** 私たちの経験や知識を補完し、客観的な視点から事業戦略、プロダクト開発、市場アプローチなどについて貴重なアドバイスやフィードバックを提供してくれます。PMF達成への道のりを短縮し、致命的な間違いを避ける上で非常に重要です。積極的に探し、関係を構築すべき対象です。
4. **（必要に応じた）技術パートナー / 外部サービス提供者:**
* **対象例:** 特定のAPI（例: ビデオ会議、AI文字起こし）提供企業、クラウドサービスプロバイダー、フリーランスのデザイナーや専門家（短期的な協力が必要な場合）。
* **関わり方・重要性:** MVP開発を迅速かつ効率的に進めるために、自前で全て開発するのではなく、既存の優れた技術やサービスを適切に活用する場合の協力先です。
## 4. 期間・予算
| 項目 | 値 |
|------|----|
| 開始 | 2025-05-09 |
| 終了 | 2025-11-09 |
| 予算 | 金銭的なところで10万円+余暇時間（自分の時間なので0円） 万円 |
## 5. 承認
| 役割 | 氏名 | 署名 | 日付 |
|------|------|------|------|
| スポンサー | 私たち創業者自身 | | |
これはドラフト版のため、Flowディレクトリ内で作成されます。続いて、指示通りに「確定して」と入力し、Stockディレクトリに移動させます。
ディレクトリ構成は以下のようになっています。緑の文字が今回作成されたものです。
移動が完了すると、元のdraftファイルは自動的に削除されました。
これで、プロジェクトの初期設定は完了です。
2. 発見
READMEの指示通りに、
仮説マップ
の作成を試みます。
質問とそれに対する回答は以下の通りです。
生成された仮説マップは以下の通りです。
次に、ペルソナを作成します。
生成されたペルソナは以下の通りです。
次に、市場規模予測を行います。
以下のように回答しました。
すると、Web検索を実行し、市場規模の精度を高めようとする動作が見られました。
MCP経由でWeb検索を実行しようとしていました。MCPの設定が手間だったため、Geminiに必要な情報を収集させました。
# 市場規模予測
* ご要望の数値、特に「推定数」「平均回数」「年間予算」といったものは、網羅的かつ正確な公式統計が存在しない場合が多く、調査レポートによっても数値が異なることがあります。
* 企業規模、業種、マーケティング戦略、調査の目的や内容によって、これらの数値は大きく変動します。
* 東南アジアは国によって市場環境や調査文化が大きく異なるため、地域全体を一般化することは非常に困難です。
以上の点を踏まえ、現時点（2025年5月9日）で得られた情報に基づいて回答します。
**1. 国内および東南アジアにおける、定性調査を実施している企業の推定数**
* **国内:**
* 「定性調査を実施している企業数」を直接示す、まとまった公的統計や広範な調査データを見つけることはできませんでした。
* 参考として、一般社団法人 日本マーケティング・リサーチ協会（JMRA）の正会員社数は2021年時点で100社強でしたが、これはリサーチ専門会社の一部であり、一般事業会社でリサーチを行う企業や非加盟の会社は含まれていません。
* 日本のマーケティングリサーチ市場全体の規模は、調査機関によって見解が異なりますが、年間2,000億円以上とする報告もあります。この市場規模から逆算して企業数を推定することも試みられますが、多くの仮定を置く必要があり、正確性は限定的です。
* **東南アジア:**
* 東南アジア全体での「定性調査を実施している企業数」に関する信頼できる推定数を見つけることは、国内以上に困難です。各国の経済発展状況、市場の成熟度、ビジネス慣習が大きく異なるためです。
* デジタル経済の成長は著しいものの、それが直接的に定性調査実施企業数にどう結びつくかのデータは限定的です。
**2. それらの企業が年間に実施する定性調査（インタビューやグループディスカッション）の平均回数**
* **国内・東南アジア共通:**
* 企業が年間に実施する定性調査の「平均回数」に関する信頼性の高い統計データは、国内外ともに見つけることができませんでした。
* これは、企業のマーケティング予算、製品開発サイクル、市場戦略、顧客理解への重視度など、多くの要因に左右されるため、一般化が非常に難しい指標です。
* 例えば、新製品開発が多い企業や、顧客中心主義を掲げる企業では実施頻度が高い傾向にあると考えられますが、全企業をならした平均値を出すのは困難です。
**3. 1回の調査あたりの平均的な費用（外部委託の場合など）**
* **国内:**
* 外部のリサーチ会社に委託する場合、調査手法や対象者の条件、調査規模（人数、地域など）、報告書の詳細度などによって費用は大きく変動します。
* いくつかの情報源によると、一般的な目安としては以下のような範囲が示されています（2024年頃の情報を含む）。
* **デプスインタビュー（1対1の深層面接）：** 1人あたり数万円～十数万円、1プロジェクトあたりでは10万円～40万円程度から。対象者のリクルーティング難易度や人数により変動。
* **グループインタビュー（フォーカスグループ）：** 1グループ（4～6名程度）あたり数十万円から。例えば、40万円～130万円程度。モデレーターのスキル、対象者のリクルーティング、会場費などを含む。
* **オンラインインタビュー：** オフラインに比べて会場費などが抑えられる場合がありますが、プラットフォーム利用料や対象者のリクルーティング費用は発生します。費用感としては、40万円～80万円程度という情報も見られますが、これも内容次第です。
* これらはあくまで目安であり、実際の見積もりは個別の調査設計によって大きく変わります。
* **東南アジア:**
* 東南アジアも国や都市によって物価水準や人件費が大きく異なるため、一概に平均費用を提示するのは困難です。
* 一般的に、シンガポールのような先進国は費用が高くなる傾向があり、その他の国では相対的に抑えられる可能性があります。
* リモート（オンライン）での定性調査は、従来の渡航を伴う調査に比べてコストを抑えられる可能性がありますが、現地のリクルーティング費用や通訳・翻訳費用、現地の文化や言語に精通したモデレーターの費用などが別途必要になる場合があります。
**4. オンライン調査ツールへの年間予算の推定額**
* **国内・東南アジア共通:**
* 企業が「オンライン調査ツール（定性調査プラットフォームや関連ソフトウェアを含む）」に特化してどれくらいの年間予算を組んでいるか、という直接的かつ具体的な統計データを見つけることはできませんでした。
* 企業のDX（デジタルトランスフォーメーション）投資やマーケティング関連ツールの予算の一部として組み込まれることが多いと考えられますが、その内訳は企業ごとに大きく異なります。
* 参考として、日本国内の「定性データ分析ソフトウェア市場」については、2020年に約5.5億米ドル、2028年には約8.7億米ドルに成長するという予測（Verified Market Research）がありますが、これは主に分析フェーズのソフトウェア市場であり、調査実施プラットフォーム全体を指すものではありません。
* 多くの企業では、必要に応じてプロジェクトベースでツール利用料を支払うケースや、年間契約でも他のマーケティングツールと一括で予算管理されているケースなどが考えられます。
**まとめ**
ご要望の数値について、ピンポイントでの正確な情報提供が難しく、大変申し訳ありません。
市場予測を行う上では、これらの一般的な傾向や入手可能な関連データ（市場規模、特定のソフトウェア市場の成長率など）を参考にしつつ、ご自身のサービスがターゲットとする顧客セグメントの特性や課題、支払い意欲などを個別にヒアリングや調査を通じて把握し、仮説を立てて検証していくことが重要になるかと存じます。
以下の市場規模予測が出力されました。
一部を抜粋して紹介します。
予測にはかなり幅があります。本来であれば、さらにイテレーションを重ねて精度を高める必要がありそうですが、今回は次へ進みます。
それにしても、これほどの内容を生成してくれるのは驚きです。
Discoveryフェーズはこのあたりで終え、次に進みます。
3. リサーチ
次に、顧客調査を試みます。
詳細なやり取りは長くなるため、ここでは省略します。
先ほどと同様に、ヒアリング項目に回答していきます。
4. 計画
いよいよ計画フェーズです。
どのような計画が出力されるか楽しみです。
以下の内容が出力されました。
期待していたよりもシンプルな内容でした。
# オンラインで定性調査を行うプラットフォームサービスの構築 - 作業分解構造図 (WBS)
**プロジェクト期間:** 2025/5/9 - 2025/11/9
**プロジェクトマネージャー:** Biz担当
**作成日:** 2025-05-09
**最終更新日:** 2025-05-09
## 1. プロジェクト概要
オンラインで定性調査を行うプラットフォームサービスを構築する。
## 2. 主要デリバラブル
- インフラ構築され、アプリケーションがデプロイされた状態で、SaaSとして使える状態になっている。
## 3. WBS階層
* **1. 機能A**
* 1.1 スキーマ構築
* 1.2 ビジネスロジック実装
* 1.3 UI実装
* 1.4 テストコード作成
* **2. 機能B**
* 2.1 スキーマ構築
* 2.2 ビジネスロジック実装
* 2.3 UI実装
* 2.4 テストコード作成
* **3. 機能C**
* 3.1 スキーマ構築
* 3.2 ビジネスロジック実装
* 3.3 UI実装
* 3.4 テストコード作成
* **4. インフラ構築**
* 4.1 環境選定・設計
* 4.2 環境構築
* 4.3 デプロイメントパイプライン構築
* 4.4 監視設定
* **5. 全体テスト**
* 5.1 結合テスト
* 5.2 システムテスト
* 5.3 受入テスト支援
* **6. プロジェクト管理**
* 6.1 進捗管理
* 6.2 課題管理
* 6.3 コミュニケーション
*(注: 上記は基本的な構造例です。実際の機能名やタスクはプロジェクトに応じて詳細化が必要です)*
## 4. リソース計画
- Biz担当: プロジェクト管理、要件定義、受入テスト
- CTO: 技術選定、アーキテクチャ設計、開発リード、インフラ構築
## 5. スケジュールサマリー
- 全体期間: 2025/5/9 - 2025/11/9 (約6ヶ月)
- 各機能・タスクのスケジュールは別途詳細化が必要。
## 6. 進捗状況
- 未着手
## 7. 注記
- 本WBSは初期ドラフトであり、プロジェクト進行に伴い更新される。
- 各タスクの担当者、工数見積もり、依存関係は別途定義する。
## 8. 更新履歴
- 2025-05-09: 初版作成
殆どの情報が欠落してしまったので、Geminiに作ってもらいました。
**1.0 プロジェクト管理**
1.1 プロジェクト計画策定
1.1.1 プロジェクトスコープ定義 (MVPスコープ含む)
1.1.2 スケジュール作成・マイルストーン設定
1.1.3 体制・役割分担定義
1.1.4 コミュニケーション計画
1.2 進捗管理
1.2.1 定例ミーティング実施
1.2.2 進捗報告書作成
1.2.3 課題管理表作成・更新
1.3 リスク管理
1.3.1 リスク洗い出しと評価
1.3.2 対応策検討・実施
1.4 品質管理
1.4.1 品質基準設定
1.4.2 レビュー体制構築・実施
1.5 予算管理 (該当する場合)
**2.0 企画・要件定義**
2.1 市場・競合調査分析 (再確認・ドキュメント化)
2.2 ターゲットユーザー定義・ペルソナ定義 (再確認・ドキュメント化)
2.3 提供価値・サービスコンセプト定義 (再確認・ドキュメント化)
2.4 ユースケース洗い出し・定義
2.5 機能要件定義
2.5.1 ユーザー管理機能（登録、ログイン、プロフィール等）
2.5.2 プロジェクト管理機能（作成、設定、ステータス管理等）
2.5.3 参加者管理機能（招待、同意取得、スケジュール調整支援等）
2.5.4 オンラインインタビュー実施機能（ビデオ/音声通話、チャット、画面共有、録画/録音制御等）
2.5.5 モデレーター支援機能（質問ガイド表示、タイムキーパー、メモ機能等）
2.5.6 データ管理機能（録画データ保存・一覧・再生、チャットログ保存等）
2.5.7 （MVP以降）文字起こし連携/機能
2.5.8 （MVP以降）簡易分析・共有機能
2.5.9 （SaaSの場合）プラン・決済管理機能
2.6 非機能要件定義
2.6.1 パフォーマンス・可用性
2.6.2 セキュリティ（データ保護、アクセス制御等）
2.6.3 UI/UX（ユーザビリティ、アクセシビリティ）
2.6.4 運用・保守性
2.7 要求仕様書作成・承認
**3.0 設計**
3.1 システムアーキテクチャ設計
3.1.1 全体構成図作成
3.1.2 技術選定（言語、フレームワーク、DB等）
3.2 UI/UX設計
3.2.1 情報設計・画面フロー設計
3.2.2 ワイヤーフレーム作成
3.2.3 プロトタイプ作成・検証
3.2.4 UIデザイン作成（デザイントークン、スタイルガイド含む）
3.3 データベース設計
3.3.1 ER図作成
3.3.2 テーブル定義書作成
3.4 API設計
3.4.1 APIエンドポイント定義
3.4.2 リクエスト/レスポンスフォーマット定義
3.5 セキュリティ設計
3.5.1 脅威分析・対策検討
3.5.2 データ暗号化・アクセス制御方式設計
3.6 インフラ設計 (クラウド利用前提)
3.6.1 ネットワーク構成設計
3.6.2 サーバー構成設計
3.6.3 監視・バックアップ設計
3.7 詳細設計書作成 (各機能・モジュールごと)
**4.0 開発**
4.1 開発環境構築
4.1.1 バージョン管理システム設定 (Git等)
4.1.2 CI/CD環境構築準備
4.1.3 各開発者ローカル環境構築
4.2 バックエンド開発
4.2.1 共通基盤開発（認証、API基盤等）
4.2.2 機能別モジュール開発 (2.5の機能要件に基づく)
4.2.2.1 ユーザー管理機能開発
4.2.2.2 プロジェクト管理機能開発
4.2.2.3 オンラインインタビューセッション管理開発
4.2.2.4 データ永続化処理開発
4.2.2.5 その他コア機能開発
4.2.3 API実装
4.2.4 （SaaSの場合）決済システム連携開発
4.3 フロントエンド開発
4.3.1 共通コンポーネント開発
4.3.2 各画面開発 (UIデザインに基づく)
4.3.2.1 ユーザー登録・ログイン画面
4.3.2.2 ダッシュボード画面
4.3.2.3 プロジェクト作成・管理画面
4.3.2.4 オンラインインタビュー画面
4.3.2.5 データ閲覧画面
4.3.2.6 その他画面開発
4.3.3 API連携処理実装
4.4 外部サービス連携開発 (必要な場合)
4.4.1 文字起こしサービス連携
4.4.2 その他分析ツール連携
**5.0 テスト**
5.1 テスト計画策定
5.1.1 テスト方針・範囲定義
5.1.2 テスト環境構築
5.2 単体テスト (開発と並行)
5.2.1 テストケース作成
5.2.2 テスト実施・不具合修正
5.3 結合テスト
5.3.1 テストシナリオ作成
5.3.2 テスト実施・不具合修正
5.4 システムテスト（総合テスト）
5.4.1 機能テスト（要求仕様書との整合性確認）
5.4.2 非機能テスト（パフォーマンス、セキュリティ、ユーザビリティ等）
5.4.3 テスト実施・不具合修正
5.5 受入テスト (UAT)
5.5.1 UATシナリオ作成 (ビジネス担当主体)
5.5.2 UAT実施・フィードバック収集
5.5.3 最終調整
5.6 テスト報告書作成
**6.0 リリース準備・デプロイ**
6.1 本番環境構築・設定
6.2 データ移行 (必要な場合)
6.3 リリース手順書作成
6.4 リハーサル実施
6.5 最終確認・承認
6.6 本番デプロイ作業
6.7 リリース後動作確認・モニタリング
**7.0 運用・保守 (初期フェーズ)**
7.1 サービス監視体制構築・ツール導入
7.2 障害対応フロー整備・訓練
7.3 ユーザーサポート体制準備
7.3.1 FAQ作成
7.3.2 問い合わせ窓口設置
7.4 定期メンテナンス計画
7.5 フィードバック収集・分析体制
7.6 セキュリティパッチ適用・アップデート対応
**8.0 ドキュメンテーション**
8.1 要件定義書 (2.7で作成)
8.2 設計書 (各種、3.0で作成)
8.3 ソースコード・APIドキュメント
8.4 テスト関連ドキュメント (5.0で作成)
8.5 運用マニュアル
8.6 ユーザーマニュアル (ヘルプドキュメント、FAQ)
**9.0 法務・規約関連**
9.1 利用規約作成
9.2 プライバシーポリシー作成
9.3 特定商取引法に基づく表記 (SaaSモデルの場合)
9.4 その他関連法規遵守確認
9.5 （必要な場合）外部専門家（弁護士等）レビュー
このような形で回答を進めました。
出力された内容は以下の通りです。
epic.yaml
# エピック定義
project_id: オンラインで定性調査を行うプラットフォームサービスの構築
epics:
- id: "E01"
title: "ユーザーとアクセス管理 (User & Access Management)"
description: "ユーザーが安全かつ適切にプラットフォームを利用するための基盤機能群。"
priority: "high"
status: "new"
- id: "E02"
title: "調査プロジェクトのライフサイクル管理 (Research Project Lifecycle Management)"
description: "定性調査プロジェクト全体を効率的に管理するための機能群。"
priority: "high"
status: "new"
- id: "E03"
title: "インタビュー参加者の獲得と管理 (Participant Recruitment & Management)"
description: "調査に適した参加者を見つけ、インタビュー実施までスムーズに管理するための機能群。"
priority: "medium"
status: "new"
- id: "E04"
title: "高度なオンラインインタビュー実行環境 (Advanced Online Interview Environment)"
description: "質の高いオンラインインタビュー（1on1、グループ）を実施するためのコア機能群。"
priority: "high"
status: "new"
- id: "E05"
title: "モデレーションとオブザベーション支援 (Moderation & Observation Support)"
description: "インタビューを円滑に進行し、観察者との連携を深めるための支援機能群。"
priority: "medium"
status: "new"
- id: "E06"
title: "インサイト抽出とデータ活用 (Insight Generation & Data Utilization)"
description: "収集した定性データを整理・分析し、価値あるインサイトを引き出すための機能群。"
priority: "medium"
status: "new"
- id: "E07"
title: "セキュリティとコンプライアンス (Security & Compliance)"
description: "ユーザーデータとプライバシーを保護し、法令遵守を担保するための機能群。"
priority: "high"
status: "new"
- id: "E08"
title: "サブスクリプションとアカウント請求 (Subscription & Account Billing) (※SaaSモデルの場合)"
description: "サービス利用料金の管理と請求処理を行うための機能群。"
priority: "low" # MVPでは優先度低めの可能性
status: "new"
backlog.yaml
# プロダクトバックログ定義
project_id: オンラインで定性調査を行うプラットフォームサービスの構築
name: "オンライン定性調査プラットフォーム バックログ"
description: |
その深い共感から生まれるインサイトが、より良い製品・サービス、ひいてはより良い社会を迅速に共創していく未来を実現する
product_vision: |
その深い共感から生まれるインサイトが、より良い製品・サービス、ひいてはより良い社会を迅速に共創していく未来を実現する
priority_criteria: |
開発効率。ユーザーストーリーを流すうえでの最初の方から。
もし、技術的難易度が高いところがあればそのPoC。例えば、インタビューツールのWebRTCを使った実装とか。
estimation_method: "Tシャツサイジング (XS, S, M, L, XL)"
wbs_relation: "IDで関連付け"
# バックログアイテム定義 (ユーザーストーリーは別ファイルで管理し、ここでは参照のみ、または主要なもののみ記載)
items:
# 例: エピックE01に紐づくユーザーストーリー
- id: "US-001"
title: "（例）新規ユーザーとしてアカウントを作成できる"
description: "初めてプラットフォームを利用するユーザーが、必要な情報を入力してアカウントを登録できるようにする。"
priority: "high"
type: "story"
estimate: "M" # Tシャツサイズで見積もり
epic_id: "E01"
acceptance_criteria:
- "メールアドレスとパスワードで登録できる"
- "登録後、確認メールが送信される"
- "確認メール内のリンクをクリックするとアカウントが有効化される"
dependencies: []
assignee: ""
status: "new"
wbs_id: "2.5.1, 4.2.2.1, 4.3.2.1" # 関連するWBS ID
# 他のユーザーストーリーやタスクをここに追加していく
# ...
より詳細なブレイクダウンを期待しましたが、そこまでは生成されませんでした。
そのため、Geminiに別途生成させました。
project_id: オンラインで定性調査を行うプラットフォームサービスの構築
name: "オンライン定性調査プラットフォーム バックログ"
description: |
あらゆる企業が、顧客一人ひとりの真実の声に、いつでも、どこからでも、深く耳を傾けられるようにする。
そして、その深い共感から生まれるインサイトが、より良い製品・サービス、
ひいてはより良い社会を迅速に共創していく未来を実現する。
product_vision: |
あらゆる企業が、顧客一人ひとりの真実の声に、いつでも、どこからでも、深く耳を傾けられるようにする。
そして、その深い共感から生まれるインサイトが、より良い製品・サービス、
ひいてはより良い社会を迅速に共創していく未来を実現する。
priority_criteria: |
開発効率。ユーザーストーリーを流すうえでの最初の方から。
もし、技術的難易度が高いところがあればそのPoC。例えば、インタビューツールのWebRTCを使った実装とか。
estimation_method: "Tシャツサイジング (XS, S, M, L, XL)"
wbs_relation: "IDで関連付け (各アイテムのwbs_id参照)"
items:
# 技術検証 (PoC) - 優先度基準に基づき最優先
- id: "TSK-E04-000"
title: "WebRTCを利用したリアルタイムビデオ・音声通話機能の技術検証 (PoC)"
description: "オンラインインタビュー機能のコアとなるWebRTCを用いたビデオ・音声通話について、実現可能性、パフォーマンス、必要なライブラリ/サービスを検証する。"
priority: "critical"
type: "task"
estimate: "L" # PoCは時間がかかる可能性あり
epic_id: "E04"
acceptance_criteria:
- "基本的な1対1のビデオ・音声通信がブラウザ間で確立できること"
- "遅延や品質について基本的な評価が行えること"
- "利用する技術スタック（ライブラリ、STUN/TURNサーバー等）の目処が立つこと"
- "主要ブラウザ（Chrome, Firefox, Safari）での動作互換性を確認する"
dependencies: []
assignee: "CTO" # 技術検証はCTO担当
status: "new"
wbs_id: "WBS-3.1, WBS-4.2.2.3" # WBSのアーキテクチャ設計や該当機能開発の前段階
# E01: ユーザーとアクセス管理
- id: "US-E01-001"
title: "新規ユーザーとしてメールアドレスとパスワードでアカウント登録できる"
description: "ユーザーはサービスを利用するために、メールアドレスとパスワードを使用して新しいアカウントを作成する。"
priority: "high"
type: "story"
estimate: "M"
epic_id: "E01"
acceptance_criteria:
- "有効なメールアドレス形式であること"
- "パスワードが指定された強度（例：8文字以上、英数記号混在など）を満たしていること"
- "登録ボタンをクリックすると、アカウントが作成待ち状態になる"
- "登録確認メールが指定のメールアドレスに送信される"
- "確認メール内のユニークなリンクをクリックすることでアカウントが有効化される"
dependencies: []
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.1, WBS-4.3.2.1"
- id: "US-E01-002"
title: "登録ユーザーとしてメールアドレスとパスワードでログインできる"
description: "既存のユーザーは、登録したメールアドレスとパスワードを使用してプラットフォームにログインする。"
priority: "high"
type: "story"
estimate: "S"
epic_id: "E01"
acceptance_criteria:
- "メールアドレスとパスワードの入力フィールドが表示される"
- "有効化されたアカウントの正しい認証情報でログインボタンをクリックすると、ダッシュボードにリダイレクトされる"
- "誤った認証情報や未有効化アカウントの場合は、適切なエラーメッセージが表示される"
dependencies: ["US-E01-001"]
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.1, WBS-4.3.2.1"
# E07: セキュリティとコンプライアンス (基本部分)
- id: "TSK-E07-001"
title: "ユーザーパスワードはハッシュ化してデータベースに保存する"
description: "セキュリティ強化のため、ユーザーが設定したパスワードは不可逆的なハッシュ関数（ソルト付き）を用いてハッシュ化し、そのハッシュ値をデータベースに保存する。"
priority: "high"
type: "task"
estimate: "S"
epic_id: "E07"
acceptance_criteria:
- "パスワード保存時に業界標準のハッシュアルゴリズム（例：bcrypt, Argon2）が使用されている"
- "各ユーザーごとに異なるソルトが使用されている"
- "元のパスワードがデータベースに平文で保存されていないことを確認するテストがある"
dependencies: ["US-E01-001"]
assignee: "CTO"
status: "new"
wbs_id: "WBS-3.5"
- id: "US-E07-002"
title: "ユーザーは利用規約とプライバシーポリシーに同意した上でサービスを利用開始できる"
description: "新規アカウント登録時または初回ログイン時に、ユーザーはサービスの利用規約およびプライバシーポリシーを確認し、同意する。"
priority: "high"
type: "story"
estimate: "S"
epic_id: "E07"
acceptance_criteria:
- "アカウント登録画面または初回ログイン画面に、利用規約とプライバシーポリシーへのリンクが表示される"
- "内容を確認するためのモーダルウィンドウまたは別ページで規約が表示できる"
- "同意チェックボックスが用意されており、チェックしないと登録/利用開始プロセスが完了しない"
- "ユーザーが同意した日時と規約のバージョンが記録される（将来の監査用）"
dependencies: ["US-E01-001"]
assignee: ""
status: "new"
wbs_id: "WBS-9.1, WBS-9.2"
# E02: 調査プロジェクトのライフサイクル管理 (MVP Core)
- id: "US-E02-001"
title: "ログインユーザーとして新しい調査プロジェクトを作成できる"
description: "ユーザーはプラットフォーム上で新しい定性調査プロジェクトを開始するために、プロジェクト名、調査目的などの基本情報を入力して作成する。"
priority: "high"
type: "story"
estimate: "M"
epic_id: "E02"
acceptance_criteria:
- "プロジェクト作成フォームから必須項目（例：プロジェクト名）と任意項目（例：調査目的、ターゲット属性メモ）を入力できる"
- "「作成」ボタンを押すと新しいプロジェクトが生成され、そのプロジェクトのダッシュボード/詳細ページに遷移する"
- "必須項目が入力されていない場合は、適切なエラーメッセージが表示され作成できない"
dependencies: ["US-E01-002"]
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.2, WBS-4.3.2.3"
- id: "US-E02-002"
title: "作成した調査プロジェクトの一覧をダッシュボードで確認できる"
description: "ユーザーはログイン後、自身が作成または参加している調査プロジェクトのリストをダッシュボードで確認し、各プロジェクトに簡単にアクセスできる。"
priority: "high"
type: "story"
estimate: "S"
epic_id: "E02"
acceptance_criteria:
- "ダッシュボードに、プロジェクト名、作成日（または最終更新日）、ステータス（MVPでは「進行中」など簡易的でも可）がリスト表示される"
- "リスト内の各プロジェクト名をクリックすると、該当プロジェクトの詳細ページ（インタビューセッション管理など）に遷移できる"
dependencies: ["US-E02-001"]
assignee: ""
status: "new"
wbs_id: "WBS-4.3.2.2"
# E04: 高度なオンラインインタビュー実行環境 (MVP Core)
- id: "US-E04-001"
title: "プロジェクトオーナーとしてオンラインインタンタビュールームを作成（予定）し、参加者用URLを発行できる"
description: "調査プロジェクトの責任者は、インタビュー実施のために専用のオンラインルームをスケジュール（MVPでは即時作成でも可）し、インタビュー参加者がアクセスするためのユニークなURLを取得する。"
priority: "high"
type: "story"
estimate: "M"
epic_id: "E04"
acceptance_criteria:
- "プロジェクト詳細画面から「新しいインタビューセッションを作成」オプションを選択できる"
- "セッション名（任意）などを設定すると、ユニークな参加者用招待URLが生成・表示される"
- "生成されたURLはクリップボードにコピーできる機能がある"
dependencies: ["US-E02-001", "TSK-E04-000"] # PoCによる技術的目処が前提
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.3, WBS-4.3.2.4"
- id: "US-E04-002"
title: "インタビュアーとしてルームに入室し、1対1のビデオ・音声通話を開始できる"
description: "インタビュアーは作成（予定）されたルームに入室し、マイク・カメラのテストを行った後、参加者の入室を待ってビデオ・音声によるインタビューを開始する。"
priority: "high"
type: "story"
estimate: "L" # WebRTC実装の主要部分
epic_id: "E04"
acceptance_criteria:
- "インタビュアー用のURLまたはプロジェクト内のリンクからルームに入室できる"
- "入室前にブラウザからマイクとカメラの使用許可を求められ、許可するとデバイスが有効になる"
- "自分のカメラ映像のプレビューとマイク入力レベルの確認ができる"
- "参加者が入室すると、その旨が通知され、通話相手（参加者）と映像・音声が双方向に通信できる状態になる"
dependencies: ["US-E04-001"]
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.3, WBS-4.3.2.4"
- id: "US-E04-003"
title: "インタビュアーとしてビデオ・音声通話を録画・録音できる（クライアントサイド録画も検討）"
description: "インタビュアーは、インタビュー中に通話内容（ビデオと音声）をプラットフォーム上に記録する。MVPではクライアントサイドでの録画も検討し、サーバー負荷を軽減する。"
priority: "high"
type: "story"
estimate: "M" # 録画機能
epic_id: "E04"
acceptance_criteria:
- "インタビュー画面に明確な「録画開始」「録画停止」ボタンがある"
- "録画開始時に参加者にも録画中であることが明確に通知される（法的・倫理的配慮）"
- "録画されたデータ（ビデオと音声）は、インタビュー終了後、プラットフォームの指定された場所にアップロード/保存される"
- "録画ファイルの形式は一般的なもの（例: webm, mp4）である"
dependencies: ["US-E04-002"]
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.3, WBS-4.2.2.4"
- id: "US-E04-004"
title: "インタビュー参加者として発行されたURLからルームに入室し、ビデオ・音声通話に参加できる"
description: "インタビューに招待された参加者は、提供されたURLを通じて簡単にインタビュールームに入室し、マイク・カメラを準備してインタビューに参加する。"
priority: "high"
type: "story"
estimate: "M"
epic_id: "E04"
acceptance_criteria:
- "招待URLにアクセスすると、シンプルなルーム入室画面が表示される"
- "ブラウザからマイクとカメラの使用許可を求められ、許可するとデバイスが有効になる"
- "自分のカメラ映像のプレビューとマイク入力レベルの確認ができる"
- "表示名（ニックネームなど）を入力して入室できる"
- "インタビュアーと映像・音声が双方向に通信できる状態になる"
dependencies: ["US-E04-001"] # インタビュアーによるルーム作成が前提
assignee: ""
status: "new"
wbs_id: "WBS-4.3.2.4"
# E06: インサイト抽出とデータ活用 (MVP Core - 録画データの確認)
- id: "US-E06-001"
title: "インタビュアーとして録画されたインタビュー動画をプラットフォーム上で再生できる"
description: "インタビュー実施後、インタビュアーはプラットフォームに保存された録画データ（ビデオ・音声）をストリーミング再生し、内容を振り返る。"
priority: "high"
type: "story"
estimate: "M"
epic_id: "E06"
acceptance_criteria:
- "プロジェクト詳細ページやインタビューセッション履歴から、録画された動画ファイルにアクセスできる"
- "動画ファイルを選択すると、埋め込みビデオプレーヤーで再生が開始される"
- "再生、一時停止、ミュート、音量調整、プログレスバーによるシークなどの基本的な再生コントロールが利用できる"
dependencies: ["US-E04-003"] # 録画機能が前提
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.4, WBS-4.3.2.5"
# E05: モデレーションとオブザベーション支援 (MVP Minimum - あれば嬉しい機能)
- id: "US-E05-001"
title: "インタビュアーとしてインタビュー中に簡易的なテキストメモを記録できる"
description: "インタビュアーは、オンラインインタビュー中に気付いた点や重要な発言などを、インタビュー画面内でテキストメモとして記録する。"
priority: "low" # MVPでは優先度低め。 Nice to have.
type: "story"
estimate: "S"
epic_id: "E05"
acceptance_criteria:
- "インタビュー画面に専用のメモ入力エリアがある"
- "入力したメモは自動的に保存される（または保存ボタンがある）"
- "記録したメモは、インタビュー終了後、録画データと関連付けて確認できる（MVPではセッションごとのテキストとして保存でも可）"
dependencies: ["US-E04-002"]
assignee: ""
status: "new"
wbs_id: "WBS-4.2.2.3, WBS-4.3.2.4" # インタビュー画面内の機能
この辺のアウトプットはすごいです。肌感と違うところがあるので、1つ前のステップのWBSでもっとつめて検証をするのが良さそうです。
まぁ、80点ぐらいなのでとりあえず先に進みます。
次に、ロードマップを作成します。
同様に、ヒアリング項目に回答していきます。
---
doc_targets: ['roadmap']
importance: 5
project_name: 'オンラインで定性調査を行うプラットフォームサービスの構築'
project_id: 'オンラインで定性調査を行うプラットフォームサービスの構築' # project_idは別途管理推奨
start_date: '2025-05-09'
end_date: '2025-11-09'
phases: '3' # 仮設定
---
# リリースロードマップ – オンラインで定性調査を行うプラットフォームサービスの構築
## 基本情報
**プロジェクト名**: オンラインで定性調査を行うプラットフォームサービスの構築
**作成日**: 2025/05/09
**バージョン**: v0.0.1
**作成者**: Biz担当
**最終更新日**: 2025-05-09
## 1. プロジェクト概要
オンラインで定性調査を行うプラットフォームサービスを構築する。
**プロジェクト期間**: 2025/05/09 - 2025/11/09（全体）
**MVPリリース期限**: 2025/11/09 (正式リリース目標)
### 1.1 主要目標
- プロトタイプ完成
- ステークホルダークライアントデモ (複数回)
- α版ローンチ
- β版ローンチ
- 正式リリース
### 1.2 成果物 (主要機能テーマ)
- クライアント向けダッシュボード
- パネル向け機能
- 管理者機能
- パネル募集機能
- インタビュー実施画面
## 2. 開発フェーズとマイルストーン (目標とリリース時期に基づく仮構成)
### フェーズ1: プロトタイプ開発と初期検証 (～2025/07/01)
**期間**: 2025/05/09 - 2025/07/01
**概要**: コア機能のプロトタイプ開発と内部・協力者による検証
#### 主要マイルストーン：
- M1: コア機能（インタビュー実施画面、基本認証）プロトタイプ完成 (2025/06中旬)
- M2: ステークホルダー/クライアントデモ① (2025/07/01)
#### 主要タスク：
- コア機能の技術検証(WebRTC等)
- 基本的なユーザー認証機能開発
- インタビュー画面プロトタイプ開発
- デモ準備
### フェーズ2: α版開発と限定テスト (～2025/09/01)
**期間**: 2025/07/02 - 2025/09/01
**概要**: 主要機能（クライアントダッシュボード、パネル管理基礎）を実装し、α版として限定ユーザーでテスト
#### 主要マイルストーン：
- M3: クライアント向けダッシュボード基本機能実装 (2025/07下旬)
- M4: α版ローンチ (2025/08/01)
- M5: ステークホルダー/クライアントデモ② (α版) (2025/08月中旬)
- M6: パネル管理機能基礎実装 (2025/08下旬)
- M7: β版開発開始 (2025/09/01)
#### 主要タスク：
- クライアントダッシュボード開発
- プロジェクト管理機能基礎開発
- α版テスト準備・実施・フィードバック収集
- パネル管理機能基礎開発
### フェーズ3: β版開発と公開テスト (～2025/11/09)
**期間**: 2025/09/02 - 2025/11/09
**概要**: 管理者機能、パネル募集連携などを追加し、β版として公開テスト、正式リリースへ
#### 主要マイルストーン：
- M8: 管理者機能実装 (2025/09下旬)
- M9: β版ローンチ (2025/10/01)
- M10: ステークホルダー/クライアントデモ③ (β版) (2025/10月中旬)
- M11: パネル募集機能連携 (2025/10下旬)
- M12: 正式リリース準備完了 (2025/11月初旬)
- M13: 正式リリース (2025/11/09)
#### 主要タスク：
- 管理者機能開発
- β版テスト準備・実施・フィードバック収集・改善
- パネル募集機能連携開発
- 課金システム連携 (SaaSの場合)
- 利用規約・プライバシーポリシー最終化
- 本番環境準備・デプロイ
## 3. 機能リリース計画 (テーマと時期に基づく仮構成)
### MVP1 (プロトタイプ - 2025/07/01 デモ目標)
- インタビュー実施画面 (コア機能: 1on1ビデオ通話、録画)
- ユーザー認証 (基本ログイン)
### MVP2 (α版 - 2025/08/01 ローンチ目標)
- クライアント向けダッシュボード (プロジェクト一覧、作成)
- パネル向け機能 (招待URLからの参加)
- (MVP1機能の改善)
### MVP3 (β版 - 2025/10/01 ローンチ目標)
- 管理者機能 (ユーザー管理基礎)
- パネル募集機能 (外部連携または簡易機能)
- (MVP2機能の改善)
### 正式リリース (2025/11/09 目標)
- β版からの改善
- 課金機能 (SaaSの場合)
- その他、優先度の高い機能
## 4. リソース計画
### 4.1 人的リソース
- Biz担当: プロジェクト管理、要件定義、顧客開発、テスト、ドキュメント作成
- CTO: 技術リード、アーキテクチャ設計、開発、インフラ管理、テスト
### 4.2 技術リソース
- (技術選定フェーズで決定)
### 4.3 予算計画
- 初期予算: 10万円 (登記費用、バーチャルオフィス等) + 創業者時間
- 開発ツール、クラウド費用等は別途見積もり
## 5. リスクと対策
- (別途リスク管理計画で詳細化)
- 例: WebRTC技術習得の遅延 → PoC早期実施、外部リソース検討
- 例: アーリーアダプター獲得の遅れ → ネットワーク活用、インセンティブ設計
- 例: 開発リソース不足 → スコープ調整、優先順位見直し
## 6. コミュニケーション計画
- 定例ミーティング: 週1回 (Biz担当、CTO)
- ステークホルダーデモ: 各マイルストーン達成時 (ターゲット顧客、メンター等)
- ツール: (Slack, Google Workspace等を想定)
## 7. リリース準備とバリデーション
- 各リリース前にテスト計画に基づき検証を実施
- デモとフィードバック収集を繰り返し、プロダクトを改善
## 8. 承認
| 役割 | 氏名 | 署名 | 日付 |
|------|------|------|------|
| プロジェクトマネージャー | Biz担当 | | |
| CTO | CTO | | |
| (メンター/アドバイザー) | (氏名) | | |
## 9. 更新履歴
| 日付 | 更新者 | 変更内容 |
|------|-------|---------|
| 2025/05/09 | Biz担当 | 初版作成 |
実現性は無視して、とりあえず締切とWBSの内容を詰め込んだ感じになります。
最初に定義したリソースは完全に無視されているというか、LLMがあるんだから一人でもできるよね。という前提で作ってくれている気がしますね。むしろ、トップダウンでこんな感じで切ってくれたほうがこれをどう実現するかを思考するようになるので良いかもです。
言い換えれば、テックリードの意見を全く聞かないでBizサイドでトップダウンでスケジュールを切った感じです。
5. 実行
次に、開発環境初期化 を行います。
これについては、テクノロジースタックの選定と、関連ドキュメントを簡易的に作成するのみでした。
次に、実行順序計画を作成させました。
素晴らしいことに、依存関係やビジネス価値を考慮した計画が作成されました。
次に、ユーザーストーリーの実装に移ります。
以下のようなIssueが起票されました。
ここまでくれば、あとはこの指示に従って実装を進めることになります。
本日のタスクを作成させます。
様々なファイルを参照し、WBSなどを確認した上で、以下の内容が作成されました。
作業が完了したと仮定し、タスクを更新して確定させます。
一連の作業を終えた後のディレクトリとファイルの状況です。
ここまで到達するのに時間は4時間ぐらいです。ほとんどLLMの出力待ちの時間です。出力まちの時間にこの記事を同時進行で書いていました。
番外編: プレゼン資料作成
プレゼン資料を作成もできるので作ってもらいました。
プロンプトはこんな感じです。
Marpで作ってくれます。
「投資家向けにもっと細かく作って」と指示したら25枚くらいのスライドを作ってくれました。
Marp(Markdown)で作られたファイルをPDFやPPTXにはコマンド一発で変換できます。
❯ npx @marp-team/marp-cli Flow/202505/2025-05-10/presentation_investor_modern_brown.md --pptx
[ INFO ] Converting 1 markdown...
[ INFO ] Flow/202505/2025-05-10/presentation_investor_modern_brown.md => Flow/202505/2025-05-10/presentation_investor_modern_brown.pptx
❯ npx @marp-team/marp-cli Flow/202505/2025-05-10/presentation_investor_modern_brown.md --pdf
[ INFO ] Converting 1 markdown...
[ INFO ] Flow/202505/2025-05-10/presentation_investor_modern_brown.md => Flow/202505/2025-05-10/presentation_investor_modern_brown.pdf
作ったプレゼン資料はこちらにpushしてあります。
生成された計画の評価と調整
-
評価ポイント:
- タスクの網羅性: 詳細な評価には熟読が必要ですが、概観した限りでは8割程度は網羅されていそうです。
- 依存関係の妥当性: 良好です。検討が煩雑になりがちな部分ですが、しっかりと作成されています。
- 見積もりの現実性: LLMに慣れていないエンジニアが普通にやると厳しいかもしれないけど、LLMを使ってレバレッジできればできると思います。
-
調整例:
- 例：LLMが出力したものに対して都度評価を行うことで、精度向上が期待できます。
考察
1. DifyとAI PM（ファイルベース管理）の比較
Difyでワークフローやエージェントを構築するのと同列で考えられる。
| カテゴリ | メトリック | Dify | AI PM (ファイルベース管理) |
|---|---|---|---|
| 構築 | 容易さ |
△ GUIで直感的に構築できるが、機能が多く学習コストはやや高め |
◯ テキストベースでシンプル、既存の知見を活かしやすい |
| バージョン管理 |
△ プラットフォーム依存（エクスポート機能はある） |
◎ Gitなどの既存のバージョン管理システムをそのまま利用可能 |
|
| カスタマイズの容易さ |
△ GUIの範囲内でのカスタマイズが主。コード埋め込み等も可能だが制約あり |
◎ プロンプト、スクリプト、設定ファイルなど、あらゆる要素を自由に編集可能 |
|
| 利用 | 容易さ |
◯ GUIで操作が統一されており、非エンジニアにも比較的優しい |
△ CUI操作やファイル編集が基本となるため、ある程度の慣れが必要 |
| カスタマイズの容易さ |
△ 利用者側でのUIカスタマイズは限定的 |
◯ 利用者が直接プロンプトや設定を調整しやすい |
＜表の補足＞
-
Dify:
- 構築の容易さ: GUIベースでワークフローを組めるため、プログラミング知識がなくても始めやすいです。ただし、ノードの種類や設定項目が多く、使いこなすにはある程度の学習が必要です。
- バージョン管理: Difyプラットフォーム内で変更履歴が管理される場合がありますが、Gitのように詳細なバージョン管理やブランチ運用は難しい場合があります。DSL（YAMLなど）でのエクスポート・インポート機能は存在します。
- カスタマイズの容易さ（構築）: 基本的にはDifyが提供するノードや機能の範囲でのカスタマイズとなります。カスタムツールとして外部APIを連携させたり、CodeノードでPython/Node.jsを記述したりすることも可能です。
- 利用の容易さ: Web UIを通じて実行できるため、エンドユーザーにとっては比較的簡単に利用できます。
- カスタマイズの容易さ（利用）: エンドユーザーがワークフローの内部構造を意識せずに利用できる反面、実行時の細かい挙動をユーザー自身が調整するのは難しい場合があります（事前に設定された変数入力程度）。
-
AI PM (ファイルベース管理):
- 構築の容易さ: テキストエディタとターミナルがあれば始められ、既存のシェルスクリプトやプログラミング言語の知識を活かせます。一方で、ワークフロー全体の設計や各コンポーネント間の連携は自前で考える必要があります。
- バージョン管理: プロンプト、設定ファイル、スクリプトなど、すべてがテキストファイルとして管理できるため、Gitなどの分散バージョン管理システムとの相性が非常に良いです。変更履歴の追跡、ブランチでの試行錯誤、チームでの共同編集などが容易です。
- カスタマイズの容易さ（構築）: プロンプトの内容、使用するLLMモデル、処理フロー、外部ツール連携など、あらゆる要素を自由に、かつ細かくカスタマイズできます。
- 利用の容易さ: 主にCUI（コマンドラインインターフェース）での操作や、設定ファイルを直接編集する必要があるため、GUIに慣れたユーザーにとっては敷居が高い場合があります。
- カスタマイズの容易さ（利用）: 利用者自身がプロンプトを微調整したり、設定値を変更したりすることで、挙動を柔軟に変えやすいです。
Difyより手触り感があるので、エンジニアにはフィットしそうです。なによりも一元管理できたりもするし、もう最高かなと思います。もし、ドキュメントをpublicに出したければsubmoduleで追加して、それを外部公開用のレポジトリにしちゃえばよいでしょうし。
しかも、アーキテクチャなら無料で行えます。LLMへの課金だけで終わる！
2. 応用ユースケース
PMなどのマネジメント業務をすごい雑にブレイクダウンするといかになると考えています。
マネジメント業務 = 理論 x 環境
そう考えるとマネジメント業務って、ピンキリで大量に存在するのでどのレベルでもこの設計を応用できると考えられます。
- 拡大して使う場合
- 会社経営
- 戦略コンサルティング
- 研究開発
- 銀行のシステム移行プロジェクト(青い銀行のシステム移管プロジェクトとかのドキュメントを食わせてみたい)
- 縮小して使う場合
- 調査票作成
- 既存の開発プロジェクトに入れる
- 機能開発のissue作成
- 見積書作成
- プレゼン資料作成
- Blog記事作成
3. LLMを使ったアセットの概念の提唱
aipm_v0の根幹にあるワークフローのモデルを図にすると以下。
このフローは、何ら新しい概念ではなは日常のオフィスワークと同じ考え方です
- ファイルキャビネット → 作業机：必要な書類をキャビネットから取り出して、作業机に広げる
- 作業机で編集：書類に赤ペンで修正を入れたり、内容を整理したりする
- 作業机 → ファイルキャビネット：完成した書類をきちんとフォルダに入れて保管する
LLMはこの「作業机」の役割を果たし、私たちのファイル資産を活用して編集作業をサポートしてくれます。この方法なら編集履歴も残せるため、チームでの作業にも最適です。
また、コンピュータのアーキテクチャと同じ考え方です。ストレージ（ハードディスク）からRAM（メモリ）にデータを読み込み、CPUで処理して、また保存するという流れそのものです。
- ファイルシステム（ストレージ） = プロジェクトの資産を保管する場所
- LLMの作業領域（メモリ） = 一時的に情報を展開し、加工する場所
- 人間の判断（CPU） = 内容を確認し、意思決定する処理装置
この単純でありながら強力なモデルが、何十年もの間コンピュータの基本設計として機能してきたように、LLMを活用したドキュメント非常に適していることがわかります。
4. 新たな作業方法の可能性
AI PMからの質問に対し、Geminiに回答を生成させていると、まるでAI同士が対話（A2A: AI to AI）しているような感覚でした。実際には間に人間（Human）が介在しているため、A2H2A（AI to Human to AI）といった構図です。
人間はコピペとクオリティチェック、問題が起きたときの介入といった作業に専念できました。
左画面にCline（AI PM）、右画面にCopilot（Gemini）という構成で作業を進めました。
まるで「Vibe PM」のような感覚
いわゆる「Vibe Coding」（AI補助のもとでコーディングする新たな開発スタイル）ならぬ「Vibe PM」とでも呼べる新しいプロジェクト管理の形が見えてきました。AIとの対話を通じて、プロジェクトの立ち上げから計画、実行までをスムーズに進められることで、従来のプロジェクト管理の概念が大きく変わりつつあります。
人間はビジョンと判断を提供し、AIが実務的なドキュメント作成や計画立案をサポートする—このコラボレーションが、これからのプロジェクト管理の標準になるかもしれません。
5. 構成はいたってシンプル
自分でも同じものを作りたいとなった時。難しそうに思うかもしれませんが、中身はとてもシンプル。ここまでシンプルにエッセンスを抽出して最低限の指示でこのようなモデルを作ったみやっち氏はすごいと思った。
aipm_v0の中身はこれだけ
中身の説明
- グランドルールのファイル
- 1つだけ
- 今回は1200行程度
- 知識のファイル
- PMBOKなどの理論に即したワークフローの定義軍
- テンプレ
- 知識のファイルからテンプレ性の高い部分だけ外に出した
mdcフォーマットで作る。
00_master_rules.mdcの抜粋。
--
description:
globs:
alwaysApply: true
---
path_reference: "basic/pmbok_paths.mdc"
master_triggers:
#-----
# プロジェクト初期化フェーズ
#-----
- trigger: "(プロジェクト初期化|プロジェクト開始|プロジェクト立ち上げ)"
priority: high
steps:
- name: "start_info_collection"
action: "call basic/01_pmbok_initiating.mdc => project_init_questions"
message: "プロジェクト初期化に必要な情報を収集します。以下の質問に回答してください。"
- name: "wait_user_responses"
action: "wait_for_all_answers"
message: "必要な回答が揃うまで先に進みません。"
- name: "confirm_project_creation"
action: "confirm"
message: "以下の内容でプロジェクトを初期化します：\n\nプログラム: {{program_id}}\nプロジェクト: {{project_id}}\n\nよろしいですか？"
- name: "create_program_dir"
action: "execute_shell"
command: "mkdir -p {{dirs.programs}}/{{program_id}}"
message: "プログラムディレクトリを作成します..."
- name: "create_project_dir"
action: "execute_shell"
command: "mkdir -p {{patterns.project_dir}}"
message: "プロジェクトディレクトリを作成します..."
- name: "create_document_dirs"
action: "execute_shell"
command: "mkdir -p {{patterns.doc_initiating}} {{patterns.doc_discovery}} {{patterns.doc_research}} {{patterns.doc_planning}} {{patterns.doc_executing}} {{patterns.doc_monitoring}} {{patterns.doc_closing}}"
message: "プロジェクト文書ディレクトリを作成します..."
- name: "create_readme"
action: "create_markdown_file"
path: "{{patterns.project_dir}}/README.md"
まとめと今後の展望
AI PMの可能性と意義
-
プロジェクト管理の変革
- AI PMは単なる自動化ツールではなく、プロジェクト管理の思考プロセスそのものを拡張する可能性を秘めています。特に
aipm_v0のようなファイルベースのアプローチは、既存の開発フローと親和性が高く、導入障壁が低いという利点があります。 - PMBOKに準拠した体系的なアプローチにより、大規模プロジェクトの立ち上げから実行までを一貫してサポートできることが実証されました。
- AI PMは単なる自動化ツールではなく、プロジェクト管理の思考プロセスそのものを拡張する可能性を秘めています。特に
-
多様なユースケース
- 今回のケーススタディで示したように、スタートアップの新規サービス構築のような複雑なプロジェクトに適用できます。
- さらに、会社経営や戦略コンサルティングといった大規模な領域から、調査票作成やissue作成といった小規模なタスクまで、スケーラブルに活用できる柔軟性を持っています。
「aipm_v0」の実践から得られた知見
-
良かった点
- Flow（ドラフト）とStock（確定版）というシンプルながら効果的なワークフローは、アイデアの発散と収束を自然に促進します。
- プロジェクト初期化のヒアリングプロセスは、主観に偏りがちな計画立案を客観的な視点で補完し、より堅牢なプロジェクト基盤の構築に貢献します。
- LLMとの対話を通じて、プロジェクト管理の理論と実践を学ぶ教育的側面も見出せました。
-
改善の余地
- 一部のステップで出力内容が大幅に欠落するケースが見られました。これはLLMの制約によるものですが、分割処理などの工夫で改善できる可能性があります。
- プロジェクトの規模や特性に応じて、生成するドキュメントをより柔軟に選択・カスタマイズできる仕組みがあると実用性が高まるでしょう。
- 複数のLLMを組み合わせた「A2A（AI to AI）」連携の自動化により、人間の介在をさらに減らせる可能性があります。
新たな働き方の展望
-
「Vibe PM」の可能性
- 今回の実験で垣間見えた「Vibe PM」とも呼べる新しいプロジェクト管理のスタイルは、AIと人間の協働による新たな働き方を示唆しています。
- 人間はビジョンと判断を提供し、AIが実務的なドキュメント作成や計画立案をサポートするという役割分担により、創造的な業務に集中できる環境が実現できるでしょう。
-
LLMを活用したアセット管理の普及
- ファイルシステム（ストレージ）、LLMの作業領域（メモリ）、人間の判断（CPU）という単純かつ強力なモデルは、今後のナレッジワークの基本設計として広く採用される可能性があります。
- このモデルはGitなどの既存のバージョン管理システムとの親和性も高く、チーム開発においても大きな価値を発揮するでしょう。
今後の発展方向
-
技術的な発展
- より大きなコンテキストウィンドウを持つLLMの登場により、複雑なプロジェクト全体を一度に把握・処理できるようになれば、AI PMの能力はさらに向上するでしょう。
- 専門分野に特化したファインチューニングモデルの開発により、特定の業界や領域に最適化されたAI PMツールが登場する可能性があります。
-
自動化と連携の拡張
- GitHub Actionsなどの自動化ツールと連携することで、AI PMの活用範囲が大きく広がります。例えば：
- 毎朝の定期実行により、プロジェクトの進捗状況を自動的に分析し、チームメンバーに今日のタスクリストをSlackやメールで配信
- コードリポジトリの変更を検知して、自動的にドキュメントの更新や課題の進捗状況の更新を提案
- スプリントの終了時に自動的に振り返りレポートを生成し、次のスプリント計画の素案を提示
- これらの自動化により、プロジェクト管理の多くの定型業務が効率化され、PMはより戦略的な意思決定に集中できるようになります。
- GitHub Actionsなどの自動化ツールと連携することで、AI PMの活用範囲が大きく広がります。例えば：
-
社会的な影響
- AI PMの普及により、これまでプロジェクト管理の専門知識を持たなかった個人や小規模チームでも、高品質なプロジェクト管理が可能になります。
- 一方で、プロジェクトマネージャーの役割は、AIとの協働を前提とした新たなスキルセットへと進化していくことが予想されます。
みやっち氏が開発したaipm_v0は、そのシンプルな構成ながらも強力な機能を持ち、LLMを活用したプロジェクト管理の新たな地平を切り開くものです。今後、このようなアプローチがさらに洗練され、様々な領域で活用されることで、知識労働の生産性と創造性が大きく向上することを期待しています。
このAI PMを作り込んでいけばこの状態になりそうだなと思いました。
Discussion