business-analysis

ビジネス分析標準

このスキルは、抽象的なビジネス目標と具体的な技術実装の間にある隔たりを埋めるための標準を定めます。

🧠 基本的な考え方と理念

重要

ドキュメントの保存場所：生成されたすべてのドキュメント（PRD、BRD、技術仕様書、ユーザーストーリーなど）は、プロジェクトルートの docs/ フォルダーに保存する必要があります。requirements/ や specifications/ など、ほかのフォルダーにドキュメントを作成しないでください。

1. まずギャップ分析を行う：解決策を提案する前に、制約のギャップを深く分析します。次の点を問いかけてください。「既存のどのような制約（レガシーコード、予算、スケジュール）が、新しい要件と衝突するか？」
2. 段階的に考える：複雑な論理フローでは、どのような場合でも、問題を段階ごとに分解します。推測せず、導き出してください。
3. まずビジュアルで示す：テキストは曖昧です。コードは実装の詳細です。図が真実です。
   • 不明な場合は、search_web を使って最新の Mermaid 構文や例を取得してください。内部の学習データに頼らないでください。
4. Obsidian に適した形式：ドキュメントはグラフで利用できる形式にします。
   • 内部参照には [[Wiki-links]] を使います。
   • 主要なトピックには**MOC（コンテンツマップ）**を作成します。
   • タグやエイリアスには YAML フロントマターを使います。
5. アジャイルの原則に忠実に：ユーザーストーリー（INVEST 基準）で記述します。受け入れ基準は Gherkin で定義します。
6. 複数の視点：要件を複数の観点から評価します。
   • 🎩 戦略的な視点：ROI、KPI、ロードマップに焦点を当てます（BRD）。
   • 🎩 プロダクトの視点：ユーザーエクスペリエンス、機能、フローに焦点を当てます（PRD／ユーザーストーリー）。
   • 🎩 技術的な視点：スキーマ、API、状態に焦点を当てます（技術仕様書）。

🚀 ワークフロー

1. 「全面的な刷新」ワークフロー（デフォルト）

新しい機能やシステムをユーザーから依頼された場合：

1. フェーズ 1：市場とドメインの調査
   • search_web を使って前提を検証します。
   • 例：「2026 年における最新の LMS 成績表の標準機能は何ですか？」
   • 例：「[Product X] の競合分析」。
2. フェーズ 2：要件の収集（質問票）
   • 単に「何が必要ですか？」と尋ねるだけではいけません。具体的な制約について質問します。
   • 範囲が広い場合は、requirements_questionnaire.md のパターンを使います。
3. フェーズ 3：ロジックとフローの分析
   • ハッピーパス、ネガティブパス、エッジケースを整理します。
4. フェーズ 4：図の作成
   • 調査：最新の Mermaid ドキュメント（State、Sequence、Class）を確認します。
   • 生成：フローを可視化する Mermaid 図を作成します。
   • 検証：利用可能な場合は scripts/verify_mermaid.py を実行するか、構文を注意深く確認します。
5. フェーズ 5：ドキュメント作成
   • references/templates/ を使って、適切な成果物（PRD、技術仕様書、ユーザーストーリー）を生成します。
   • リンク：関連する **MOC（コンテンツマップ）**を更新し、新しいドキュメントを追加します（例：docs/030-Specs/Specs-MOC.md）。

2. スキル間の連携

指揮役として、必要に応じて専門スキルと連携します。

• スキーマ／API が必要な場合：
  • 対応：「データベーススキーマについて、リードアーキテクトに相談する必要があります。」
  • シミュレーション：「リードアーキテクト代行として、次のスキーマを提案します……」
• UI／UX が必要な場合：
  • 対応：「ユーザーエクスペリエンスについて、デザイナーと調整する必要があります。」
  • シミュレーション：「UX の観点から、ここにローディング状態が必要です……」

📚 参考ライブラリ

テンプレート

テンプレート	パス	目的
PRD（機能要件）	templates/prd-functional.md	機能要件／非機能要件とユーザーフローを含む詳細なPRDです。完全な技術仕様が必要な場合に使用します
ユーザーストーリー（詳細）	templates/user-story-detailed.md	Gherkin構文、開発者向けメモ、API依存関係を含む詳細な形式です。開発チームへの引き継ぎに使用します
BRD	templates/brd.md	ビジネス要件定義書です。ステークホルダー分析、ROI、KPIを含みます。ビジネスケースが必要な大規模プロジェクトに使用します
ユースケース	templates/use-case.md	ユースケース仕様です。アクターのフロー、代替パス、例外を含みます。複雑なシステム分析に使用します
変更依頼	templates/change-request.md	変更依頼です。影響分析、工数見積もり、承認ワークフローを含みます。スコープ変更が依頼された場合に使用します

ドメイン知識

ドメイン	パス	主な対象
SaaS	references/domains/saas.md	サブスクリプション、マルチテナント、PLG
FinTech	references/domains/fintech.md	コンプライアンス、台帳、セキュリティ
社内ツール	references/domains/internal-tools.md	ワークフロー、効率性、統合
HealthTech	references/domains/healthtech.md	HIPAA、患者のアウトカム
Eコマース	references/domains/ecommerce.md	コンバージョン、在庫、フルフィルメント
EdTech	references/domains/education.md	学習成果、アクセシビリティ
ブロックチェーン／Web3	references/domains/blockchain-dapp.md	スマートコントラクト、ウォレット
飲食	references/domains/fnb.md	POS、注文、在庫
AI／ML製品	references/domains/ai-agent.md	精度、説明可能性
マーケットプレイス	references/domains/marketplace.md	流動性、信頼、紛争

ベストプラクティス

• 図表作成ガイド - 図を描く前にお読みください
• ギャップ分析チェックリスト

🛠️ ツールとスクリプト

• scripts/verify_mermaid.py：生成された図のコードの構文を検証します。

---

例：教育ドメイン（LMS）

「学生の成績簿」を依頼された場合：

1. 調査：「標準的な評価尺度 GPA 対パーセンテージ」を検索します。
2. 思考：順を追って考えます → 「教師が成績を入力 → システムが最大点数を検証 → システムが加重平均を計算 → 学生に通知が届く」。
3. 図：Teacher → UI → GradeService → Database を示すシーケンス図を作成します。
4. 仕様：grades テーブル（student_id、assignment_id、score、weight）を定義します。

---