--- name: saas-spec-document description: SaaSサービス向けのサービス仕様書を作成します。運用設計書や要件定義書をインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠したサービス仕様書を生成します。ガイドライン準拠の7カテゴリ（可用性、信頼性、データ管理、セキュリティ、サポート、拡張性、コンプライアンス）に加え、サービス概要・料金・責任分界を含む全10セクションを網羅します。 --- # SaaSサービス仕様書作成スキル SaaSサービス向けのサービス仕様書を作成するスキルです。運用設計書や要件定義書などの既存ドキュメントをインプットとして活用し、経済産業省「SaaS向けSLAガイドライン」に準拠した包括的なサービス仕様書を生成します。 ## 概要 このスキルは以下の機能を提供します： - 運用設計書からのSLO/SLI、監視項目、インシデント対応情報の抽出 - 要件定義書からの非機能要件、セキュリティ要件の抽出 - 経済産業省ガイドラインに準拠したサービス仕様書の作成 - ガイドライン準拠の7カテゴリ＋追加3セクション（サービス概要、料金・課金、責任分界）の計10セクションを網羅 - 不足情報のヒアリングと補完 - 一貫性チェックと客観的レビュー ## このスキルを使用する場面 以下の状況でこのスキルを有効にしてください： ### サービス仕様書の新規作成時 - 新規SaaSサービスのサービス仕様書が必要な場合 - 既存サービスのサービス仕様書を整備したい場合 - 顧客向けSLA文書を作成したい場合 ### 既存ドキュメントからの変換時 - 運用設計書からサービス仕様書を作成したい場合 - 要件定義書からサービス仕様書を作成したい場合 - 複数のドキュメントを統合してサービス仕様書にまとめたい場合 ### 更新・改訂時 - サービス仕様書の内容を更新したい場合 - SLA条件を変更したい場合 - 新機能追加に伴う仕様書の改訂が必要な場合 ## 基本的な使い方 ### サービス仕様書作成の開始 「サービス仕様書を作成したい」「SLA文書を作成してほしい」などと依頼されたら： 1. **インプットドキュメントの確認** - 運用設計書の有無と内容確認 - 要件定義書の有無と内容確認 - その他の関連ドキュメントの確認 2. **基本情報のヒアリング** - サービス名と概要 - 対象顧客と提供形態 - 料金プランの構成 3. **カテゴリ別の情報収集・抽出** - 可用性要件 - 信頼性要件 - データ管理要件 - セキュリティ要件 - サポート体制 - 拡張性・API仕様 - コンプライアンス要件 4. **サービス仕様書の作成** - テンプレートに基づいて段階的に作成 - 各セクションについてユーザーに確認 - 不明点は必ず質問 5. **一貫性チェックとレビュー** - 運用設計書との整合性確認 - 要件定義書との整合性確認 - SLA条件の実現可能性確認 ## インプットドキュメントの活用 ### 運用設計書からの抽出項目 運用設計書が提供された場合、以下の項目を抽出してサービス仕様書に反映します： | 運用設計書のセクション | サービス仕様書への反映先 | |----------------------|------------------------| | SLO/SLI定義 | 3. 信頼性 - サービスレベル目標 | | SLA定義 | 2. 可用性 - サービス稼働率 | | 監視項目 | 3. 信頼性 - サービスレベル指標 | | インシデント管理 | 3. 信頼性 - 障害時の対応時間 | | バックアップ設計 | 4. データ管理 - バックアップ | | DR設計 | 2. 可用性 - ディザスタリカバリ | | セキュリティ運用 | 5. セキュリティ | | 変更管理・リリース管理 | 2. 可用性 - アップグレード方針 | | 運用体制 | 6. サポート - サポート体制 | ### 要件定義書からの抽出項目 要件定義書が提供された場合、以下の項目を抽出してサービス仕様書に反映します： | 要件定義書のセクション | サービス仕様書への反映先 | |----------------------|------------------------| | 非機能要件（可用性） | 2. 可用性 | | 非機能要件（性能） | 3. 信頼性 - SLO | | 非機能要件（セキュリティ） | 5. セキュリティ | | 非機能要件（拡張性） | 7. 拡張性 | | ユーザーストーリー | 1. サービス概要 - 主要なユースケース | | 機能要件 | 1. サービス概要 - サービスの機能 | ## ワークフロー ### 基本的な作業フロー ```text 1. インプットドキュメントの確認 - 運用設計書の読み込み - 要件定義書の読み込み - 抽出可能な情報の特定 ↓ 2. 基本情報のヒアリング - サービス概要 - 対象顧客 - 料金プラン ↓ 3. カテゴリ別情報の収集 - インプットからの抽出 - 不足情報のヒアリング ↓ 4. サービス仕様書の段階的作成 - 各セクション作成 - ユーザー確認 - 修正・承認 ↓ 5. 一貫性チェック - インプットとの整合性 - セクション間の整合性 ↓ 6. 最終レビューと承認 - 全体確認 - 最終承認 - ドキュメント完成 ``` ### 詳細な実行手順 #### ステップ1: インプットドキュメントの確認 ```text コンサルタント: サービス仕様書を作成するために、既存のドキュメントを確認させてください。 以下のドキュメントはお持ちですか？ A) 運用設計書 - SLO/SLI、監視項目、インシデント対応等の情報を抽出できます B) 要件定義書 - 非機能要件、セキュリティ要件等の情報を抽出できます C) その他の仕様書 - システム設計書、セキュリティポリシー等 お持ちのドキュメントを共有していただけますか？ または、ファイルパスを教えてください。 ユーザー: [回答またはファイル共有] ``` **ドキュメント読み込み時の処理**: 運用設計書が提供された場合： ```text コンサルタント: 運用設計書を確認しました。以下の情報を抽出できます： 【抽出可能な情報】 ✅ SLO定義: 可用性99.9%、レスポンスタイム500ms以下 ✅ 監視項目: [項目リスト] ✅ インシデント対応時間: P1=15分、P2=30分... ✅ バックアップ: 日次フル、6時間毎差分、30日保持 ✅ DR構成: [構成内容] これらの情報をサービス仕様書に反映してよろしいですか？ ``` #### ステップ2: 基本情報のヒアリング ```text コンサルタント: （AskUserQuestionツールを使用） サービスの基本情報を確認させてください。 Q1: サービス名を教えてください Q2: サービスの提供形態はどれですか？ A) **マルチテナント型** ⭐⭐⭐⭐⭐ - 複数顧客が共有インフラを利用 - コスト効率が高い 推奨理由: SaaSの標準的な形態 考慮事項: テナント分離のセキュリティ説明が必要 B) **シングルテナント型** ⭐⭐⭐⭐ - 顧客ごとに専用環境を提供 - カスタマイズ性が高い 推奨理由: Enterprise向けで高セキュリティ 考慮事項: コストが高くなる傾向 C) **ハイブリッド型** ⭐⭐⭐ - プランにより選択可能 推奨理由: 柔軟な提供形態 考慮事項: 両方の仕様書記載が必要 ユーザー: [回答] ``` #### ステップ3: カテゴリ別情報の収集 **3-1. 可用性（Availability）** ```text コンサルタント: 可用性に関する情報を確認します。 [運用設計書から抽出した場合] 運用設計書から以下の情報を抽出しました： - サービス稼働率目標: 99.9% - 計画メンテナンス: 毎週日曜02:00-06:00 この内容でサービス仕様書に記載してよろしいですか？ 変更が必要な場合は教えてください。 [情報がない場合] サービス稼働率（SLA）について確認させてください。 A) **99.9%** ⭐⭐⭐⭐⭐ - 月間ダウンタイム: 約43分 - 一般的なSaaSの標準 B) **99.95%** ⭐⭐⭐⭐ - 月間ダウンタイム: 約22分 - ミッションクリティカルなサービス向け C) **99.99%** ⭐⭐⭐ - 月間ダウンタイム: 約4分 - 金融・医療等の高可用性要求向け - コストと運用負荷が大幅に増加 どれを選択しますか？ ``` **3-2. セキュリティ（Security）** ```text コンサルタント: セキュリティに関する情報を確認します。 [要件定義書から抽出した場合] 要件定義書から以下のセキュリティ要件を抽出しました： - 認証: SSO対応、MFA必須 - 暗号化: TLS 1.3、AES-256 - アクセス制御: RBAC 追加で確認させてください。 Q1: 取得済みのセキュリティ認証はありますか？ - ISO/IEC 27001 - ISO/IEC 27017 - SOC 2 Type II - CSマーク - その他 Q2: データ保存場所について A) 日本国内のみ ⭐⭐⭐⭐⭐ B) 日本国内優先（海外バックアップ可）⭐⭐⭐⭐ C) グローバル（顧客が選択可能）⭐⭐⭐ ``` **3-3. サポート（Support）** ```text コンサルタント: サポート体制について確認します。 Q1: サポート時間はどのように設定しますか？ A) **24時間365日対応** ⭐⭐⭐⭐⭐ - 全時間帯でサポート対応 推奨理由: グローバルサービス、ミッションクリティカル向け 考慮事項: 運用コストが高い B) **平日営業時間（9:00-18:00 JST）** ⭐⭐⭐⭐ - 営業時間内のみ対応 - 緊急時は別途対応 推奨理由: 一般的なB2B SaaS向け 考慮事項: 緊急対応の定義が必要 C) **プラン別対応** ⭐⭐⭐⭐ - Basic: 平日営業時間 - Enterprise: 24/365 推奨理由: 柔軟な料金体系 考慮事項: プラン別の詳細定義が必要 ``` #### ステップ4: サービス仕様書の段階的作成 各カテゴリの情報収集後、サービス仕様書を段階的に作成します。 ```text コンサルタント: 収集した情報を基に、サービス仕様書の「2. 可用性」セクションを作成しました。 [作成した内容を提示] 内容を確認していただけますか？ - 承認して次のセクションに進む - 修正が必要 ユーザー: [回答] ``` #### ステップ5: 一貫性チェック ```text コンサルタント: サービス仕様書の全セクションが完成しました。 一貫性チェックを実施します。 【一貫性チェック結果】 ✅ 整合性が確認できた項目: 1. SLA 99.9%に対して、運用設計書のSLOと整合 2. バックアップRPO 6時間は運用設計書の設定と一致 3. インシデント対応時間はサポートSLAと整合 ⚠️ 確認が必要な項目: 1. DR構成のRTO 4時間とSLA可用性99.9%の整合性 → 月間43分のダウンタイム許容に対して、DR発動時の 4時間復旧は許容範囲か確認が必要です 2. セキュリティ認証「ISO 27001」は取得済みとのことですが、 有効期限を確認させてください これらの点について確認させてください。 ``` ## 経済産業省ガイドライン準拠 ### SaaS向けSLAガイドライン（2008年） 本スキルは経済産業省「SaaS向けSLAガイドライン」に準拠し、以下の7カテゴリをカバーします（加えてサービス概要、料金・課金、責任分界の3セクションを追加）： 1. **可用性（Availability）** - サービス時間 - 計画停止予定通知 - サービス提供終了時の事前通知 - 突然のサービス提供停止に対する対処 - サービス稼働率 - ディザスタリカバリ - 重大障害時の代替手段 - アップグレード方針 2. **信頼性（Reliability）** - サービスレベル目標（SLO） - サービスレベル指標（SLI） - エラーバジェット - 障害時の対応時間 3. **データ管理（Data Management）** - データの取り扱い - バックアップ - データ復旧目標（RTO/RPO） - データ暗号化 - 解約時のデータ取り扱い 4. **セキュリティ（Security）** - セキュリティ認証・認定 - 通信セキュリティ - 認証・認可 - マルチテナントセキュリティ - 脆弱性管理 - セキュリティインシデント対応 5. **サポート（Support）** - サポート体制 - サポートチャネル - サポート対応レベル - セルフサービス 6. **拡張性（Scalability）** - カスタマイズ性 - 外部接続性（API） - API制限 - リソース上限 7. **コンプライアンス（Compliance）** - 法令遵守 - 監査対応 - 監査ログ - データ所在地 ## 原則とガイドライン ### 1. 推論の禁止 このスキルは推測や推論を避け、事実に基づいた仕様書を作成します： **実施すること**: - インプットドキュメントから正確に情報を抽出 - 不明な点はユーザーに確認 - 具体的な数値と条件を記載 **実施しないこと**: - 「おそらく〜だろう」と推測する - インプットにない情報を勝手に補完する - 曖昧な表現でごまかす ### 2. インプット優先の原則 運用設計書や要件定義書が提供された場合： 1. まずインプットから情報を抽出 2. 抽出した情報をユーザーに確認 3. 承認を得てからサービス仕様書に反映 4. 不足情報のみヒアリングで補完 ### 3. 段階的な作成と確認 サービス仕様書は以下の順序で段階的に作成： 1. **サービス概要** → ユーザー確認 2. **可用性** → ユーザー確認 3. **信頼性** → ユーザー確認 4. **データ管理** → ユーザー確認 5. **セキュリティ** → ユーザー確認 6. **サポート** → ユーザー確認 7. **拡張性** → ユーザー確認 8. **コンプライアンス** → ユーザー確認 9. **料金・課金** → ユーザー確認 10. **責任分界** → ユーザー確認 11. **一貫性チェック** → 最終承認 ### 4. 具体性と測定可能性 すべてのSLA項目は具体的かつ測定可能な形で記載： **良い例**: - 可用性: 99.9%（月間ダウンタイム43分以内） - レスポンスタイム: P95で500ms以下 - 初回応答時間: 緊急は1時間以内、通常は4時間以内 **悪い例**: - 可用性: 高い可用性を維持 - レスポンスタイム: 十分な速度で応答 - 初回応答時間: 迅速に対応 ## リソース ### assets/templates/ - `service_specification_template_ja.md`: SaaSサービス仕様書テンプレート ### 関連ガイドライン - 経済産業省「SaaS向けSLAガイドライン」(2008年) - 経済産業省「クラウドサービスレベルのチェックリスト」(2010年) - 総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン」(2021年) ## 制約事項 ### 実施しないこと 1. **推測や推論** - インプットにない情報の補完 - 曖昧な条件の勝手な解釈 2. **一方的な進行** - ユーザー確認なしの次セクション移行 - 重要な決定の独断 3. **非現実的なSLA設定** - 運用設計書と整合しないSLA - 実現不可能な目標値 ### 情報不足時の対応 以下の場合は作業を進めず、ユーザーに確認： 1. **インプットドキュメントが不完全** - 「運用設計書の〜セクションが不足しています。確認させてください」 2. **SLA条件が未定義** - 「可用性目標が未定義です。以下から選択していただけますか？」 3. **矛盾する情報** - 「運用設計書と要件定義書で〜が矛盾しています。どちらが正しいか確認させてください」 ## 今後の拡張 このスキルは将来的に以下の機能を追加予定です： - 多言語対応（英語版テンプレート） - 業界別テンプレート（金融、医療、教育等） - SLA自動計算機能 - コンプライアンスチェックリスト自動生成 - 顧客向け公開版の自動生成