executive-summary

エグゼクティブサマリー

Sherpy の計画成果物から、経営層向けのサマリー文書を生成します。技術的な知識を持たない関係者が、ビジネス上の課題、ソリューションのアプローチ、タイムライン、成功基準を明確に理解できるようにします。

使用方法

/executive-summary [base-directory]

ディレクトリが指定されていない場合は、カレントディレクトリに requirements/business-requirements.yaml があるかを確認して自動検出します。

見つからない場合は、ユーザーに「計画成果物はどこにありますか？」と尋ねます。

続行する前に、ユーザーがパスを指定するまで待ちます。

必須の成果物

このスキルは、標準の Sherpy フォルダー構造から次のファイルを自動検出します。

ファイル	場所	目的
business-requirements.yaml	requirements/	ビジネス上の課題、機能、成功指標
technical-requirements.yaml	requirements/	技術的な背景、リスク、依存関係
timeline.yaml	delivery/	デリバリーのタイムラインとマイルストーン

プロセス

ステップ 1：ベースディレクトリを決定し、必須の成果物をスキャンする

ディレクトリのパラメーターが指定されていない場合は、カレントディレクトリに requirements/business-requirements.yaml があるかを確認します。

• 見つかった場合は、カレントディレクトリを base_directory として使用します
• 見つからない場合は、「計画成果物はどこにありますか？」と尋ね、ユーザーの返答を待ちます

base_directory が決まったら、標準の場所に必須ファイルがあるかをスキャンします。ステータスを表示します。

## Executive Summary — Dependency Check

Scanning for required artifacts...

 ✓  requirements/business-requirements.yaml
 ✓  requirements/technical-requirements.yaml
 ✓  delivery/timeline.yaml

3 of 3 required files found.

凡例： ✓ 見つかりました · ✗ 見つかりません

ステップ 2：不足しているファイルに対処する

必須ファイルが不足している場合は、次のように尋ねます。

「必須ファイルが不足しています：timeline.yaml

選択肢：

1. 一部のデータで続行 — 利用可能な情報でサマリーを生成します（不足しているセクションには [Not Available] と表示されます）
2. 終了 — 先に不足している成果物を完成させます（/delivery-timeline を実行して timeline.yaml を生成してください）

どちらを選びますか？」

ユーザーの返答を待ちます。

• ユーザーが 1（続行） を選択した場合：利用可能なデータで処理を続け、不足しているセクションを明確に示します
• ユーザーが 2（終了） を選択した場合：実行するスキルを表示し、正常に終了します

ステップ 3：成果物を読み込み、解析する

利用可能なすべてのファイルを読み込み、次の情報を抽出します。

business-requirements.yaml から：

• プロジェクト名と説明
• ビジネス目標と問題の説明
• 対象ユーザーとペルソナ
• 主要な機能と能力
• 成功基準と KPI
• スコープと制約

technical-requirements.yaml から：

• ソリューションアーキテクチャの概要
• 技術的なリスクと依存関係
• 外部連携
• コンプライアンス要件とセキュリティ要件
• リソース要件（チーム、インフラストラクチャ）

timeline.yaml から（利用可能な場合）：

• マイルストーンのデリバリー日
• 本番環境へのデプロイ日
• プロジェクト全体の期間
• QA とレビューのフェーズ

ステップ 4：エグゼクティブサマリーを生成する

summaries/executive-summary.md を作成します。

出力文書には、ヘッダー（タイムスタンプ、プロジェクト名）、Business Problem（現状、ビジネスへの影響）、Solution Overview（アプローチ、メリット）、Key Features & Capabilities（カテゴリ別に分類）、Timeline & Milestones（日付付きの表）、Success Metrics（主要指標と副次指標）、Risks & Dependencies（リスクの表、外部依存関係、前提条件）、Resource Requirements（チーム、インフラストラクチャ、期間に関するコミットメント）、および Conclusion を含めます。

セクション構成、執筆ガイドライン、書式設定ルールを含む文書仕様の詳細は、references/output-spec.md を参照してください。

全体例は references/example.md を参照してください。

ステップ 5：不足しているデータに適切に対処する

必須ファイルが不足している場合は、明確なプレースホルダーを挿入します。

## Timeline & Milestones

[Not Available - `timeline.yaml` not found. Run `/delivery-timeline` to generate delivery timeline.]

**Estimated Duration:** [If milestones.yaml exists, sum milestone estimates]
**Target Completion:** TBD

一部のデータしかない場合は、次のようにします。

## Risks & Dependencies

### Technical Risks
[Not Available - detailed risk analysis requires `technical-requirements.yaml`]

### External Dependencies
- [List any dependencies mentioned in available documents]

ステップ 6：確認

サマリーを生成した後、次を表示します。

## Executive Summary Generated ✓

**Location:** summaries/executive-summary.md
**Size:** [file size]

Summary includes:
  ✓ Business problem statement
  ✓ Solution overview
  ✓ Key features & capabilities
  ✓ Timeline & milestones
  ✓ Success metrics
  ✓ Risks & dependencies
  ✓ Resource requirements

The summary is ready for stakeholder review and communication.

コンテンツ抽出ロジック

ビジネス上の課題セクション

ソース： business-requirements.yaml

以下のフィールドから抽出します。

• description または overview - 全体的な背景
• business_goals.primary_goal - 主なビジネス上の推進要因
• problem_statement - 明示的な課題の説明
• why または rationale - これが重要な理由

構成：

1. 現状 - 現在あるもの、うまく機能していない点
2. ビジネスへの影響 - 現状維持によるコスト、非効率性、リスク

執筆ガイドライン：

• 技術用語ではなく、ビジネス用語を使います
• 可能な場合は影響を数値化します（コスト、時間、影響を受けるユーザー数）
• 技術的な課題ではなく、ビジネス価値に焦点を当てます
• 具体的かつ明確に記述します

例：

「カスタマーサポートチームは現在、システムのリアルタイムなステータスを把握できず、複数のダッシュボードを手作業で確認する必要があるため、インシデント対応が遅れています。この分断により、MTTR は平均 45 分に達し、生産性の低下と顧客離れによって年間約 150,000 ドルの損失が発生しています。」

ソリューション概要セクション

ソース： business-requirements.yaml + technical-requirements.yaml

以下から抽出します。

• solution_overview または proposed_solution
• architecture.approach - 技術的なアプローチの概要（ビジネス用語に翻訳）
• key_capabilities - システムが実現すること

構成：

1. アプローチ - 構築するもの（非技術的な説明）
2. メリット - 課題をどのように解決するか

執筆ガイドライン：

• 技術的な概念をビジネス価値に置き換えます
• 実装方法ではなく、成果に焦点を当てます
• ソリューションが課題にどう対処するかを説明します
• 差別化要因や主な利点を強調します

例：

「システムの健全性に関する指標、アラート、インシデント履歴を 1 つのインターフェースに集約する、統合監視ダッシュボードを構築します。このソリューションにより、サポートチームは数分以内にインシデントを特定して対応できるようになり、MTTR を 70％削減し、顧客満足度を向上させます。」

主な機能セクション

ソース： business-requirements.yaml

以下から抽出します。

• functional_requirements - 具体的な機能
• features または capabilities - 機能の一覧
• user_stories - ユーザー向けの機能

分類：

• 関連する機能をまとめます
• ビジネスにわかりやすいカテゴリ名を使います
• 仕組みではなく、ユーザーができることに焦点を当てます

カテゴリの例：

• ユーザー管理
• データと分析
• インテグレーション
• 自動化
• レポート
• セキュリティとコンプライアンス

各機能の形式：

- **[Feature Name]** - [Business value / what it enables]

例：

### Monitoring & Alerting
- **Real-Time Status Dashboard** - View system health across all services at a glance
- **Smart Alert Routing** - Automatically notify the right team based on alert severity and service ownership
- **Historical Trends** - Identify patterns and predict potential issues before they impact users

タイムラインとマイルストーンセクション

ソース： timeline.yaml（優先）または milestones.yaml（代替）

timeline.yaml から：

• workback.project_start を抽出します
• workback.production_deploy を抽出します
• タイムラインからマイルストーンの日付を抽出します
• QA のラウンド数と所要期間を抽出します

milestones.yaml から（timeline が利用できない場合）：

• estimated_duration を合計して全体の所要期間を算出します
• マイルストーンの順序を一覧にします
• QA と PR の時間を含まない暫定値であることを明記します

表示方法：

• マイルストーンをわかりやすく示すため、表を使います
• 主要な納期を強調します
• 開発、QA、デプロイの各フェーズを示します
• ひと目で把握できる形式にします

成功指標セクション

ソース： business-requirements.yaml

以下から抽出します。

• success_criteria - 明示的な成功基準
• measurable_outcomes - 定量化可能な目標
• kpis または metrics - 追跡する指標

次のように分類します：

• 主要指標 - 達成必須の目標（多くの場合、ビジネス目標に関連）
• 副次指標 - 望ましい改善項目

形式：

- **[Metric Name]:** [Target value] - [What this measures and why it matters]

例：

### Primary Metrics
- **Mean Time to Resolution (MTTR):** < 15 minutes - Measures incident response speed and system reliability
- **Customer Satisfaction Score:** > 4.5/5.0 - Indicates user satisfaction with support response

リスクと依存関係セクション

ソース： technical-requirements.yaml

以下から抽出します。

• risks - 技術上およびプロジェクト上のリスク
• external_dependencies - サードパーティサービス、API、チーム
• constraints - 制約または要件
• assumptions - 真であると仮定していること

リスク表の列：

• リスク - 起こりうる問題を明確に説明します
• 影響 - 高／中／低の深刻度
• 軽減策 - 対応方法

依存関係の形式：

- **[Dependency Name]:** [What it provides, who owns it, current status]

例：

### External Dependencies
- **Stripe Payment API:** Payment processing service, owned by Finance team, production-ready
- **SendGrid Email Service:** Transactional emails, third-party SaaS, requires account setup (in progress)

リソース要件セクション

ソース： technical-requirements.yaml + business-requirements.yaml + timeline.yaml

以下から抽出します：

• 技術要件の resources セクション
• ビジネス要件の team または stakeholders
• キャパシティ計算のためのタイムライン期間

構成：

• チーム - 役割、人数、稼働時間
• インフラストラクチャ - 必要な主要技術リソース
• タイムラインのコミットメント - 全期間とキャパシティ

例：

### Team
- **Development Team:** 3 engineers (2 backend, 1 frontend), full-time for 8 weeks
- **QA/Testing:** 1 QA engineer, 2 weeks during QA phases
- **Product:** 0.5 FTE for requirements and acceptance
- **DevOps:** 0.25 FTE for infrastructure setup and deployment

### Infrastructure
- PostgreSQL database (AWS RDS)
- Redis cache cluster
- Kubernetes cluster (existing infrastructure)
- Estimated cloud costs: $500/month

エラー処理

ファイルが見つからない場合

必須ファイルが存在しない場合：

• まず標準の docs/ の場所を確認します
• 見つからない場合はルートディレクトリを確認します
• 確認した正確なパスを表示します
• そのファイルを生成する Sherpy スキルを提案します

無効な YAML

ファイルを解析できない場合：

• 明確な解析エラーを表示します
• ファイルパスと行番号を表示します
• ファイルの再生成を提案します

必須フィールドがない場合

想定されるフィールドがない場合：

• 「[未指定]」のプレースホルダーを使用します
• 利用可能なデータを使って処理を続行します
• 確認時に不足している情報を記載します

出力先

常に次の場所に出力します：{base_directory}/summaries/executive-summary.md

ディレクトリが存在しない場合は作成します：

mkdir -p {base_directory}/summaries

文体のガイドライン

トーン

• プロフェッショナルで明確
• 技術に詳しくない人にもわかりやすい表現
• ビジネス価値を重視
• リスクについて、自信を持ちつつ現実的に伝える

対象読者

• C レベルの経営幹部
• プロダクトマネージャー
• ビジネス関係者
• 技術に詳しくない意思決定者

避けること

• 説明のない専門用語
• 実装の詳細
• コードやコマンドへの言及
• 定義のない頭字語

含めること

• ビジネスへの影響と価値
• 明確なタイムラインとコミットメント
• 測定可能な成果
• リスクの認識と緩和策

Sherpy Flow との連携

このスキルは、/developer-summary の後、/sherpy-flow のステップ 10 の最後の部分として呼び出されるように設計されています。sherpy-flow から呼び出されると、base_directory がパラメーターとして渡されます。次のように動作します：

• すべての計画成果物が完成した後に実行します
• base_directory 内の整理されたフォルダー構造からファイルを自動検出します
• 任意のセクションがなくても失敗しません
• すべてのファイルがそろっている場合は、ユーザーとのやり取りなしで要約を生成します

例

完全なエグゼクティブサマリーのサンプルについては、references/example.md を参照してください。

関連スキル

• /developer-summary - 開発者向けの技術サマリーを生成します
• /sherpy-flow - 計画ワークフロー全体（最後にこのスキルを含みます）
• /business-requirements-interview - business-requirements.yaml を生成します
• /technical-requirements-interview - technical-requirements.yaml を生成します
• /delivery-timeline - timeline.yaml を生成します