zhongwei/gh-windschord-claude-skils-operations-design
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Initial commit

Browse Source
This commit is contained in:
Zhongwei Li
2025-11-30 09:06:28 +08:00
commit ebf56024dd
14 changed files with 11023 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
.claude-plugin/plugin.json Normal file
View File

@@ -0,0 +1,12 @@
{
"name": "operations-design",
"description": "運用設計コンサルタントとして、対象業界の最新トレンドを調査し、サービス仕様をヒアリングした上で、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた運用設計書を作成します。推論を避け、不明点は必ず質問し、一貫性を保つよう客観的にレビューします。",
"version": "0.0.0-2025.11.28",
"author": {
"name": "Winds Chord",
"email": "zhongweili@tubi.tv"
},
"skills": [
"./skills/operations-design"
]
}

3
README.md Normal file
View File

@@ -0,0 +1,3 @@
# operations-design
運用設計コンサルタントとして、対象業界の最新トレンドを調査し、サービス仕様をヒアリングした上で、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた運用設計書を作成します。推論を避け、不明点は必ず質問し、一貫性を保つよう客観的にレビューします。

84
plugin.lock.json Normal file
View File

@@ -0,0 +1,84 @@
{
"$schema": "internal://schemas/plugin.lock.v1.json",
"pluginId": "gh:windschord/claude_skils:operations-design",
"normalized": {
"repo": null,
"ref": "refs/tags/v20251128.0",
"commit": "08c699cdefe4511083e2723993e606a8c264fe70",
"treeHash": "1e68d87ac26da79ed31174aa4bb72860f3529c9e4af06fd97f9b386381ef7397",
"generatedAt": "2025-11-28T10:29:03.373792Z",
"toolVersion": "publish_plugins.py@0.2.0"
},
"origin": {
"remote": "git@github.com:zhongweili/42plugin-data.git",
"branch": "master",
"commit": "aa1497ed0949fd50e99e70d6324a29c5b34f9390",
"repoRoot": "/Users/zhongweili/projects/openmind/42plugin-data"
},
"manifest": {
"name": "operations-design",
"description": "運用設計コンサルタントとして、対象業界の最新トレンドを調査し、サービス仕様をヒアリングした上で、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた運用設計書を作成します。推論を避け、不明点は必ず質問し、一貫性を保つよう客観的にレビューします。"
},
"content": {
"files": [
{
"path": "README.md",
"sha256": "a3469741193a3886594cf5b4c8c50b3bf11bab500f19a19cae1e8ce163046443"
},
{
"path": ".claude-plugin/plugin.json",
"sha256": "447537608c48f2774ba1c62adb3ca90b8caa3ba351373c99bba4b99eeca8cfaf"
},
{
"path": "skills/operations-design/README.md",
"sha256": "0153996e2d7c903c0914ff9c3675c42b7b08f5a1e0319075ae51d8ef54a4aafc"
},
{
"path": "skills/operations-design/SKILL.md",
"sha256": "8978c1c9397b8eab86c3ec0fcef6a8c16d40f193cfa79ac36c61a2d55c51b059"
},
{
"path": "skills/operations-design/hearing_items/2-9_security_compliance.md",
"sha256": "ee5ba62d21249108a2e90e48491ca3e65de359766f2e1842d668ef6a07edc689"
},
{
"path": "skills/operations-design/references/industry_research_guide_ja.md",
"sha256": "2226b55d2baefe273134e193cfba967243cb93a3919499ee4c9db11c5a9ec69e"
},
{
"path": "skills/operations-design/references/operations_design_guide_ja.md",
"sha256": "34a28be441db824f7a10c2e224d405c2bf12995b0e434632b4ec650f7a9a6d38"
},
{
"path": "skills/operations-design/guides/conversation_logging.md",
"sha256": "5677fc44849ca24c23db01e1a832b8b8e118ce085b9e17cf10473a6c78a454ff"
},
{
"path": "skills/operations-design/assets/templates/operations_design_template_cloud_instance_ja.md",
"sha256": "00c12dc6c7cb3720c1c641cc93fb30660504f79b12396b6e1bcbde25e47a974b"
},
{
"path": "skills/operations-design/assets/templates/conversation_log_template_ja.md",
"sha256": "570ff222171d769901158461b4c392509ff863e5f40d4d48cdcedcf6fc2caea5"
},
{
"path": "skills/operations-design/assets/templates/operations_design_template_cloud_native_ja.md",
"sha256": "4be6a5bb72d482b6f03faecbf955060526883de80f0ce453ea2145cdcbd0931c"
},
{
"path": "skills/operations-design/assets/templates/operations_design_template_ja.md",
"sha256": "673738b091b0745463163c8fa36de4d472eff167efddfcede8f885f0f9a707db"
},
{
"path": "skills/operations-design/assets/templates/operations_design_template_onpremise_ja.md",
"sha256": "1a027a2618c213c1a8fbe9cb8616a0f2b4bfc227cb76e59dd6ae48147cb11e57"
}
],
"dirSha256": "1e68d87ac26da79ed31174aa4bb72860f3529c9e4af06fd97f9b386381ef7397"
},
"security": {
"scannedAt": null,
"scannerVersion": null,
"flags": []
}
}

282
skills/operations-design/README.md Normal file
View File

@@ -0,0 +1,282 @@
# 運用設計コンサルタントスキル
運用設計の専門コンサルタントとして、対象業界の最新トレンドを調査し、ITIL 4・SRE・DevOpsのベストプラクティスに基づいた実践的な運用設計書を作成するスキルです。
## 概要
このスキルは以下の機能を提供します：
- 対象業界の最新トレンドと技術動向の調査
- サービス仕様の体系的なヒアリング
- ITIL 4・SRE・DevOpsに基づいた運用設計
- 包括的な運用設計書の作成
- 設計内容の一貫性チェックと客観的レビュー
- 推論を避けた事実ベースの設計
## 主な特徴
### 1. AskUserQuestionツールによる確実な質問
**すべての質問はAskUserQuestionツールを使用して実施します：**
- 質問が必要な場合は必ずAskUserQuestionツールを使用
- 不明な点は積極的に質問
- 質問する時は常にAskUserQuestionツールを使って回答させる
- 選択肢にはそれぞれ、推奨度と理由を提示
- 推奨度は⭐の5段階評価（⭐⭐⭐⭐⭐：最も推奨、⭐：推奨しない）
### 2. 会話ログによるコンテキスト保持
**すべての会話内容をファイルに記録し、コンテキストを失わないようにします：**
- セッション開始時に会話ログファイルを自動作成
- ヒアリング内容、調査結果、決定事項をすべて記録
- 長期間のセッションでも情報を失わない
- 過去の議論をいつでも参照可能
- 設計の根拠と経緯を明確に追跡
### 3. 業界調査の必須化
運用設計を開始する前に、必ず対象業界の最新トレンドを調査します：
- 最新の業界動向
- 主要な技術トレンド
- セキュリティ・コンプライアンス要件
- 業界標準のSLO/SLA水準
### 4. 推論の禁止
推測や推論を避け、事実に基づいた設計を行います：
- 不明な点は必ずユーザーに質問
- 業界トレンドはWeb検索で調査
- 提供された情報のみを使用
- 「おそらく」「たぶん」などの曖昧な判断を排除
### 5. 体系的なヒアリング
サービス仕様を段階的かつ体系的に収集します：
- 既存ドキュメントの確認
- サービス基本情報の収集
- システム構成の把握
- 運用要件の明確化
### 6. 一貫性の客観的レビュー
設計書作成後、内容の一貫性を客観的にレビューします：
- SLO/SLI/SLAの整合性チェック
- 運用体制と作業内容の整合性確認
- 監視とインシデント対応の整合性確認
- 変更管理とリリース管理の整合性確認
## ディレクトリ構造
```
operations-design/
├── SKILL.md # スキル定義ファイル
├── README.md # このファイル
├── assets/
│ └── templates/
│ ├── operations_design_template_ja.md # 汎用運用設計書テンプレート
│ ├── operations_design_template_cloud_native_ja.md # クラウドネイティブ対応
│ ├── operations_design_template_cloud_instance_ja.md # クラウドインスタンス対応
│ ├── operations_design_template_onpremise_ja.md # オンプレミス対応
│ └── conversation_log_template_ja.md # 会話ログテンプレート
└── references/
├── operations_design_guide_ja.md # 運用設計の詳細ガイド
└── industry_research_guide_ja.md # 業界調査のガイドライン
```
**テンプレートの選択**:
インフラパターンに応じて、最適なテンプレートが自動選択されます：
- **クラウドネイティブ**: サーバレス、Kubernetes環境向け（責任共有モデル考慮）
- **クラウドインスタンス**: EC2/GCE/Azure VM等のIaaS向け（LAMP等）
- **オンプレミス**: 自社データセンター向け（リソース保有とスケーリングリードタイム考慮）
## 使用方法
### スキルの有効化
Claude Codeで以下のように依頼してください：
```
運用設計書を作成したい
```
または
```
運用設計を支援してほしい
```
### 基本的なワークフロー
1. **会話ログの初期化**
- セッション開始時に会話ログファイルを作成
- すべてのヒアリング内容を記録開始
2. **インフラパターンの選択**
- クラウドネイティブ/サーバレス/Kubernetes
- クラウドインスタンス/IaaS
- オンプレミス
- 適切なテンプレートの自動選択
3. **業界トレンド調査**
- 対象業界の最新動向をWeb検索で調査
- ITIL 4、SRE、DevOpsのベストプラクティスを確認
- 調査結果を会話ログに記録
4. **サービス仕様のヒアリング**
- 既存ドキュメントの確認
- サービス概要、技術構成、運用要件を収集
- 各質問と回答を会話ログに記録
5. **運用設計書の作成**
- 選択されたテンプレートに基づいて段階的に作成
- 各セクション完成後にユーザー確認
- 承認状況を会話ログに記録
6. **一貫性チェック**
- 全セクション完成後に矛盾をチェック
- 問題があれば修正提案
- チェック結果を会話ログに記録
7. **最終承認と完成**
- ユーザーの最終承認
- 運用設計書の保存
- 最終的な決定事項とサマリーを会話ログに記録
## 運用設計書のセクション
作成される運用設計書には以下のセクションが含まれます：
1. 概要（目的、対象範囲、前提条件、**インフラパターン特有の考慮事項**）
2. サービス概要
3. 運用方針と目標（SLO/SLI/**SLA**/エラーバジェット）
4. 運用体制
5. 運用スケジュール
6. 定常運用作業
7. 監視・通知
8. インシデント管理
9. 変更管理
10. リリース管理
12. バックアップ・リカバリ
13. セキュリティ運用
14. キャパシティ管理
15. コスト管理
16. 問題管理
17. ナレッジ管理
18. 継続的改善
19. 運用ツール
20. 付録
## リソース
### テンプレート
- `assets/templates/operations_design_template_ja.md`
- 包括的な運用設計書テンプレート
- 20セクション構成
- ITIL 4、SRE、DevOpsの要素を統合
- `assets/templates/conversation_log_template_ja.md`
- 会話ログテンプレート
- セッション情報、会話記録、サマリーセクション
- コンテキスト保持と決定事項追跡
### リファレンス
- `references/operations_design_guide_ja.md`
- ITIL 4フレームワークの詳細
- SREの原則とベストプラクティス
- DevOpsの実践
- SLO/SLI/SLAの設計ガイド
- 運用プロセスの詳細
- ツール選定のポイント
- コスト最適化手法
- `references/industry_research_guide_ja.md`
- 業界調査の目的と方法
- 業界別の調査ポイント
- 最新トレンドの把握方法
- 調査結果の活用方法
## 適用可能な業界
このスキルは以下の業界に対応しています：
- Webサービス/SaaS
- EC/マーケットプレイス
- 金融サービス（銀行、証券、保険、フィンテック）
- メディア/コンテンツ配信
- ヘルスケア
- ゲーム
- IoT/組み込み
- エンタープライズ（社内システム）
## 主な採用フレームワーク
### ITIL 4
- サービスバリューシステム（SVS）
- 34のプラクティス
- 継続的改善
- アジャイル・DevOpsとの統合
### SRE（Site Reliability Engineering）
- SLO/SLI/エラーバジェット
- 4つのゴールデンシグナル
- トイル削減
- ポストモーテム文化
### DevOps
- CI/CDパイプライン
- Infrastructure as Code
- Four Keys（DORA metrics）
- 自動化とコラボレーション
## ベストプラクティス
### 1. 段階的な作成
- 一度にすべてを作成しない
- 各セクション完成後にユーザー確認
- 承認を得てから次のセクションへ
### 2. 具体性と測定可能性
- 抽象的な表現を避ける
- 測定可能な数値目標を設定
- 「高速に」ではなく「500ms以内に」
### 3. 一貫性の確保
- セクション間の矛盾をチェック
- SLOと運用プロセスの整合性
- 全体としての実現可能性
### 4. 継続的な更新
- 運用開始後も定期的に見直し
- 最新トレンドの取り込み
- 実態との乖離を防ぐ
## ライセンス
このスキルはMITライセンスの下で提供されています。
## 貢献
改善提案やバグ報告は、GitHubのIssueまたはPull Requestでお願いします。
## 関連スキル
- `sdd-docs`: ソフトウェア設計ドキュメント作成スキル
- `incident-rca`: インシデント根本原因分析スキル
- `task-executor`: タスク実行スキル

1427
skills/operations-design/SKILL.md Normal file
View File

File diff suppressed because it is too large Load Diff

127
skills/operations-design/assets/templates/conversation_log_template_ja.md Normal file
View File

@@ -0,0 +1,127 @@
# 運用設計ヒアリング会話ログ
## セッション情報
| 項目 | 内容 |
|------|------|
| セッション開始日時 | [YYYY-MM-DD HH:MM] |
| セッション終了日時 | [YYYY-MM-DD HH:MM] |
| 対象サービス | [サービス名] |
| コンサルタント | Claude (運用設計コンサルタントスキル) |
| ユーザー | [ユーザー名/組織名] |
---
## 会話ログ
### [HH:MM] 業界トレンド調査
**コンサルタント**:
```
[質問内容]
```
**ユーザー回答**:
```
[回答内容]
```
**記録事項**:
- [重要なポイント]
- [決定事項]
- [次のアクション]
---
### [HH:MM] サービス仕様のヒアリング
**コンサルタント**:
```
[質問内容]
```
**ユーザー回答**:
```
[回答内容]
```
**記録事項**:
- [重要なポイント]
- [決定事項]
- [次のアクション]
---
### [HH:MM] 運用要件の確認
**コンサルタント**:
```
[質問内容]
```
**ユーザー回答**:
```
[回答内容]
```
**記録事項**:
- [重要なポイント]
- [決定事項]
- [次のアクション]
---
## 収集した情報のサマリー
### サービス基本情報
- サービス名: [名前]
- 目的: [目的]
- 対象ユーザー: [ユーザー層]
- 想定ユーザー数: [数値]
### システム構成
- アーキテクチャ: [概要]
- 技術スタック:
- フロントエンド: [技術]
- バックエンド: [技術]
- データベース: [技術]
- インフラ: [技術]
- 外部連携: [連携サービス]
### 運用要件
- 可用性目標: [%]
- サービス提供時間: [24/365等]
- パフォーマンス要件: [要件]
- セキュリティ要件: [要件]
- コンプライアンス要件: [要件]
### 業界トレンド調査結果
- 調査実施日: [YYYY-MM-DD]
- 対象業界: [業界名]
- 主要トレンド:
1. [トレンド1]: [概要]
2. [トレンド2]: [概要]
3. [トレンド3]: [概要]
### 決定事項
1. [決定事項1]
2. [決定事項2]
3. [決定事項3]
### 未確認事項・保留事項
1. [項目1]: [理由]
2. [項目2]: [理由]
---
## 次のステップ
- [ ] [タスク1]
- [ ] [タスク2]
- [ ] [タスク3]
---
## 備考
[その他のメモや補足情報]

1395
skills/operations-design/assets/templates/operations_design_template_cloud_instance_ja.md Normal file
View File

File diff suppressed because it is too large Load Diff

2223
skills/operations-design/assets/templates/operations_design_template_cloud_native_ja.md Normal file
View File

File diff suppressed because it is too large Load Diff

1354
skills/operations-design/assets/templates/operations_design_template_ja.md Normal file
View File

File diff suppressed because it is too large Load Diff

1414
skills/operations-design/assets/templates/operations_design_template_onpremise_ja.md Normal file
View File

File diff suppressed because it is too large Load Diff

167
skills/operations-design/guides/conversation_logging.md Normal file
View File

@@ -0,0 +1,167 @@
# 会話ログ管理ガイド
**【重要】すべてのユーザーとの会話は会話ログファイルに記録すること**
運用設計のコンサルティング過程で収集したすべての情報をファイルに記録し、コンテキストを失わないようにします。
## 会話ログの目的
1. **コンテキストの保持**
- ヒアリング内容を確実に記録
- 過去の会話内容をいつでも参照可能
- 長期間のセッションでも情報を失わない
2. **決定事項の追跡**
- ユーザーの選択と判断を記録
- 決定の理由と背景を保持
- 設計の根拠を明確化
3. **未確認事項の管理**
- 保留事項の追跡
- 後で確認すべき項目の管理
- 情報不足箇所の可視化
## 会話ログファイルの作成と管理
**ファイル名**: `[YYYY-MM-DD]-[サービス名]-conversation-log.md`
**保存場所**: 運用設計書と同じディレクトリ
**初期化タイミング**: 運用設計セッション開始時（業界トレンド調査の前）
**初期化手順**:
```
1. セッション開始時にWriteツールを使用して会話ログファイルを作成
2. assets/templates/conversation_log_template_ja.md をテンプレートとして使用
3. セッション情報（開始日時、対象サービス等）を記入
4. ユーザーに会話ログファイルの作成を通知
```
**初期化の例**:
```
コンサルタント: 運用設計セッションを開始します。
まず、会話ログファイルを作成しました：
`2025-11-17-ECサイト-conversation-log.md`
このファイルに、これからのすべての会話内容、収集した情報、
決定事項を記録していきます。
それでは、業界トレンド調査から開始させてください。
```
## 会話ログの記録タイミング
**以下のタイミングで必ず会話ログを更新すること**:
1. **業界トレンド調査後**
- 調査した内容をログに記録
- 主要なトレンドと調査結果を記載
2. **各ヒアリング質問の後**
- 質問内容と回答を記録
- 重要なポイントや決定事項を記載
- 次のアクションを記録
3. **各セクション完成後**
- セクション内容の承認状況を記録
- 修正要求や追加要望を記載
4. **一貫性チェック後**
- 発見した矛盾点を記録
- ユーザーの判断と対応を記載
5. **セッション終了時**
- 最終的な決定事項をまとめる
- 未確認事項・保留事項を整理
- 次のステップを記録
## 会話ログの更新方法
**Editツールを使用して更新する**:
```
1. 会話が発生したら、その内容を整理
2. Editツールで会話ログファイルの該当セクションを更新
3. タイムスタンプと内容を追加
4. 重要なポイント、決定事項、次のアクションを記録
```
**更新の例**:
```markdown
### [14:30] 可用性要件の確認
**コンサルタント**:
```
可用性目標について確認させてください：
A) 99.9%（月間ダウンタイム約43分） ⭐⭐⭐⭐
B) 99.95%（月間ダウンタイム約22分） ⭐⭐⭐⭐⭐
C) 99.99%（月間ダウンタイム約4分） ⭐⭐
どれを選択しますか？
```
**ユーザー回答**:
```
B) 99.95%を選択します。決済機能があるため、
より高い可用性が必要だと考えています。
```
**記録事項**:
- 可用性目標: 99.95%に決定
- 理由: 決済機能を含むため、高い可用性が必要
- 次のアクション: SLO設定に99.95%を反映
```
## 会話ログのサマリー更新
**セッション中、定期的にサマリーセクションを更新する**:
```markdown
## 収集した情報のサマリー
### サービス基本情報
- サービス名: ECショッピングサイト
- 目的: オンラインでの商品販売
- 対象ユーザー: 一般消費者（B2C）
- 想定ユーザー数: 月間10万人
### システム構成
- アーキテクチャ: マイクロサービス
- 技術スタック:
- フロントエンド: React
- バックエンド: Node.js
- データベース: PostgreSQL
- インフラ: AWS
### 運用要件
- 可用性目標: 99.95%
- サービス提供時間: 24/365
- パフォーマンス要件: P95レスポンス < 500ms
- セキュリティ要件: PCI DSS準拠
### 決定事項
1. 可用性目標を99.95%に設定
2. 24時間365日のオンコール体制を構築
3. AWS Auto Scalingを使用したスケーリング戦略
### 未確認事項・保留事項
1. バックアップのRPO目標: 後日確認
2. 災害対策のRTO目標: 次回セッションで決定
```
## 会話ログの活用
**設計書作成時の参照**:
- 会話ログの情報を基に運用設計書を作成
- 決定事項の根拠として会話ログを参照
- 不明点が出た場合は会話ログで過去の議論を確認
**一貫性チェック時の参照**:
- 会話ログの決定事項と設計書の整合性を確認
- 矛盾がある場合は会話ログで経緯を確認
- ユーザーに再確認が必要な場合は過去の議論を提示

234
skills/operations-design/hearing_items/2-9_security_compliance.md Normal file
View File

@@ -0,0 +1,234 @@
# セキュリティ・コンプライアンス要件ヒアリング
**【重要】DevSecOpsの実装に必要な情報。セキュリティ要件が不明確だとCI/CDに組み込むべきチェック項目が決まらない**
## ヒアリング実施方法
```
コンサルタント: （AskUserQuestionツールを使用）
セキュリティとコンプライアンスについて詳しく確認させてください。
DevSecOps実践のため、CI/CDパイプラインに組み込むセキュリティチェックを設計します。
```
## Q1: コンプライアンス要件
準拠すべき法規制や業界標準はありますか？
### A) 個人情報保護法・GDPR ⭐⭐⭐⭐⭐
- 個人情報を扱う
- GDPR準拠が必要（EU圏ユーザー対象）
- データ保持期間の制限あり
**推奨理由**: データ保護とプライバシー要件を満たす
**考慮事項**: データの暗号化、アクセスログ、削除機能が必須
### B) PCI DSS（クレジットカード情報） ⭐⭐⭐⭐
- クレジットカード情報を取り扱う
- PCI DSS準拠が必要
- 定期的なセキュリティ監査が必要
**推奨理由**: 決済セキュリティの業界標準
**考慮事項**: カード情報の非保持化、トークン化を推奨
### C) 医療系規制（HIPAA等） ⭐⭐⭐⭐
- 医療情報を取り扱う
- HIPAA等の医療系規制に準拠
**推奨理由**: 医療データ保護の必須要件
**考慮事項**: 厳格なアクセス制御、監査ログが必須
### D) 金融系規制（金融商品取引法等） ⭐⭐⭐⭐⭐
- 金融商品・サービスを提供
- 金融庁の規制に準拠
**推奨理由**: 金融サービスの法的要件
**考慮事項**: 高レベルのセキュリティと監査証跡が必須
### E) 特になし ⭐⭐⭐
- 特定の規制要件なし
- 一般的なセキュリティベストプラクティスのみ
**推奨理由**: 最小限のコンプライアンス負担
**考慮事項**: 将来の規制対応を考慮した設計を推奨
## Q2: 認証・認可要件
### 認証方式
- A) ID/パスワード（基本）
- B) 多要素認証（MFA）必須
- C) SSO（SAML/OAuth/OIDC）対応
- D) 生体認証対応
### セッション管理
- セッションタイムアウト: [XX]分
- 同時ログイン: 許可/禁止
- デバイス管理: 必要/不要
### パスワードポリシー
- 最小文字数: [XX]文字
- 複雑性要件: あり/なし
- 有効期限: [XX]日/無制限
- 履歴管理: 過去[XX]回分
## Q3: アクセス制御（認可）
### ロール設計
- ロール数: [XX]種類
- 主要ロール: [管理者/一般ユーザー/読み取り専用/等]
- ロールの詳細度: 粗い/細かい
### アクセス制御モデル
- A) RBAC（ロールベース）
- B) ABAC（属性ベース）
- C) リソースオーナーベース
- D) 組織階層ベース
## Q4: セキュリティ脅威への対応
以下の脅威について、対策の優先度を教えてください：
- SQLインジェクション: 対策必須/対策不要（理由: [XX]）
- XSS（クロスサイトスクリプティング）: 対策必須/対策不要
- CSRF（クロスサイトリクエストフォージェリ）: 対策必須/対策不要
- DDoS攻撃: 対策必須/対策不要
- 不正アクセス（総当たり攻撃）: 対策必須/対策不要
- APIの不正利用: 対策必須/対策不要
## Q5: データ保護要件
### 保存時の暗号化（Encryption at Rest）
- A) すべてのデータを暗号化 ⭐⭐⭐⭐⭐
- B) 機密データのみ暗号化 ⭐⭐⭐⭐
- C) 暗号化不要 ⭐⭐
### 通信時の暗号化（Encryption in Transit）
- A) すべての通信をTLS/HTTPS化 ⭐⭐⭐⭐⭐（必須）
- B) 外部通信のみTLS/HTTPS ⭐⭐⭐⭐
- C) 暗号化不要 ⭐（推奨しない）
### 鍵管理
- A) クラウドKMS使用（AWS KMS/GCP KMS等） ⭐⭐⭐⭐⭐
- B) 自社で鍵管理 ⭐⭐⭐
- C) ハードコード（推奨しない） ⭐
## Q6: 機密情報の管理方法
### 環境変数・シークレット管理
- A) AWS Secrets Manager / GCP Secret Manager ⭐⭐⭐⭐⭐
- B) HashiCorp Vault ⭐⭐⭐⭐
- C) Kubernetes Secrets ⭐⭐⭐
- D) 環境変数のみ ⭐⭐
- E) 設定ファイル（推奨しない） ⭐
### シークレットのローテーション
- ローテーション頻度: [XX]日ごと/月次/年次/不要
- 自動ローテーション: 必要/不要
## Q7: CI/CDセキュリティ要件
以下のチェックについて、導入の可否を教えてください：
### SAST（静的アプリケーションセキュリティテスト）
- 導入: 必須/推奨/不要
- ツール候補: SonarQube/Checkmarx/Snyk Code/等
- 失敗時の動作: ビルド失敗/警告のみ
### 依存関係の脆弱性スキャン
- 導入: 必須/推奨/不要
- ツール候補: Snyk/Dependabot/Trivy/等
- スキャン対象: すべての依存関係/直接依存のみ
- 失敗時の動作: ビルド失敗/警告のみ
### コンテナイメージスキャン
- 導入: 必須/推奨/不要
- ツール候補: Trivy/Clair/Anchore/等
- 重大度の閾値: Critical/High/Medium以上でビルド失敗
### DAST（動的アプリケーションセキュリティテスト）
- 導入: 必須/推奨/不要
- 実施タイミング: ステージング環境/本番前/定期実行
### シークレットスキャン（ハードコード検出）
- 導入: 必須/推奨/不要
- ツール候補: git-secrets/TruffleHog/Gitleaks/等
## Q8: 監査・ログ要件
### 記録対象
- ユーザーアクション: すべて/重要なもののみ
- システム変更: すべて/重要なもののみ
- データアクセス: すべて/機密データのみ
- 認証イベント: すべて/失敗のみ
### ログ保持期間
- 最低保持期間: [XX]ヶ月/[XX]年
- 法的要件による保持: あり（期間: [XX]）/なし
### ログの改ざん防止
- 必要/不要
- 手段: 署名/ブロックチェーン/イミュータブルストレージ
---
## ヒアリング終了メッセージ
```
ユーザー: [回答]
コンサルタント: ありがとうございます。
[Editツールで会話ログに記録]
セキュリティ要件を踏まえた、DevSecOpsパイプラインと運用設計を行います。
これでサービス仕様のヒアリングは完了しました。
次に、運用設計書の作成に進みます。
```
## 会話ログ記録フォーマット
```markdown
### [HH:MM] セキュリティ・コンプライアンス要件の詳細確認
**コンプライアンス要件**:
- 準拠法規: [GDPR/PCI DSS/HIPAA/金融規制/特になし]
- 業界標準: [リスト]
**認証・認可要件**:
- 認証方式: [ID・パスワード/MFA/SSO/生体認証]
- セッションタイムアウト: [XX]分
- パスワードポリシー: [詳細]
- ロール数: [XX]種類
- アクセス制御モデル: [RBAC/ABAC/その他]
**セキュリティ脅威対策**:
- SQLインジェクション: [対策必須/不要]
- XSS: [対策必須/不要]
- CSRF: [対策必須/不要]
- DDoS: [対策必須/不要]
- 総当たり攻撃: [対策必須/不要]
- API不正利用: [対策必須/不要]
**データ保護**:
- 保存時暗号化: [すべて/機密データのみ/不要]
- 通信暗号化: [すべてTLS/外部のみTLS]
- 鍵管理: [クラウドKMS/自社管理/ハードコード]
- シークレット管理: [Secrets Manager/Vault/K8s Secrets/環境変数]
- ローテーション頻度: [XX]日/月次/年次
**CI/CDセキュリティチェック**:
- SAST: [必須/推奨/不要]、ツール: [ツール名]
- 依存関係スキャン: [必須/推奨/不要]、ツール: [ツール名]
- コンテナスキャン: [必須/推奨/不要]、ツール: [ツール名]
- DAST: [必須/推奨/不要]、タイミング: [タイミング]
- シークレットスキャン: [必須/推奨/不要]、ツール: [ツール名]
**監査ログ要件**:
- 記録対象: [すべて/重要なもののみ]
- 保持期間: [XX]ヶ月/年
- 改ざん防止: [必要/不要]、手段: [手段]
**記録事項**:
- DevSecOpsパイプラインへの反映: [内容]
- セキュリティ運用への反映: [内容]
- 次のアクション: 運用設計書の作成開始
```

765
skills/operations-design/references/industry_research_guide_ja.md Normal file
View File

@@ -0,0 +1,765 @@
# 業界調査ガイドライン
このドキュメントは、運用設計を開始する前に実施する業界調査の方法とベストプラクティスをまとめています。
## 目次
1. [業界調査の目的](#業界調査の目的)
2. [調査の進め方](#調査の進め方)
3. [業界別の調査ポイント](#業界別の調査ポイント)
4. [最新トレンドの把握](#最新トレンドの把握)
5. [調査結果の活用](#調査結果の活用)
---
## 業界調査の目的
### なぜ業界調査が必要か
運用設計において業界調査は以下の理由で重要です：
1. **業界標準の把握**
- 同業他社のベンチマーク
- 業界で期待されるサービスレベル
- 一般的な運用プラクティス
2. **最新トレンドの取り込み**
- 新しい技術の活用
- モダンな運用手法の導入
- 競争優位性の確保
3. **規制・コンプライアンス要件の理解**
- 業界固有の法規制
- セキュリティ基準
- データ保護要件
4. **リスクの事前把握**
- 業界特有のリスク
- 過去の事例からの学び
- セキュリティ脅威の理解
### 調査のスコープ
**必須調査項目**:
- 業界の最新動向
- 主要な技術トレンド
- セキュリティ・コンプライアンス要件
- 一般的なSLO/SLA水準
**任意調査項目**（プロジェクトに応じて）:
- 競合分析
- ユーザー期待値
- コスト構造
- 運用組織体制
---
## 調査の進め方
### ステップ1: 業界分類の特定
まず、対象サービスがどの業界に属するかを明確にします。
**主要な業界分類**:
| 分類 | サブカテゴリ | 特徴 |
|------|--------------|------|
| **Webサービス/SaaS** | B2B SaaS, B2C SaaS, プラットフォーム | 高可用性、スケーラビリティ重視 |
| **EC/マーケットプレイス** | EC, マーケットプレイス, 決済サービス | トランザクション精度、PCI DSS |
| **金融サービス** | 銀行, 証券, 保険, フィンテック | 高セキュリティ、監査要件 |
| **メディア/コンテンツ** | 動画配信, 音楽配信, ニュース | 高トラフィック、CDN |
| **ヘルスケア** | 電子カルテ, 遠隔医療, 健康管理アプリ | HIPAA, 個人情報保護 |
| **ゲーム** | モバイルゲーム, オンラインゲーム | リアルタイム性、ピーク対策 |
| **IoT/組み込み** | スマートホーム, 産業IoT | エッジコンピューティング |
| **エンタープライズ** | 社内システム, ERP | 業務継続性、セキュリティ |
### ステップ2: Web検索の実施
**推奨検索クエリパターン**:
```
基本パターン:
"[業界名] 運用設計 最新トレンド"
"[業界名] IT運用 ベストプラクティス 最新"
"[サービスタイプ] SRE DevOps 事例"
英語での検索（より多くの情報）:
"[industry] operations design latest trends"
"[industry] IT operations best practices"
"[service type] SRE case study"
フレームワーク特化:
"ITIL 4 [業界名] 適用事例"
"SRE [業界名] 実践"
"DevOps [業界名] 導入"
セキュリティ・コンプライアンス:
"[業界名] セキュリティ 規制 最新"
"[業界名] コンプライアンス 要件"
"[industry] security compliance requirements"
```
**検索ソースの優先順位**:
1. **公式ドキュメント・標準規格**
- ITIL公式サイト
- SRE Workbook（Google）
- 業界団体の公式サイト
2. **技術ブログ・カンファレンス資料**
- 大手テック企業のエンジニアリングブログ
- SREcon, DevOpsDays等の資料
- Medium, Qiita, Zenn等の技術記事
3. **調査レポート・市場分析**
- Gartner
- IDC
- Forrester
4. **ニュースサイト**
- TechCrunch
- InfoQ
- DZone
### ステップ3: 情報の整理
調査した情報を以下のカテゴリで整理します：
#### 1. 業界トレンド
**整理フォーマット**:
```markdown
## [業界名]の最新トレンド
### トレンド1: [トレンド名]
- **概要**: [トレンドの説明]
- **背景**: [なぜこのトレンドが生まれたか]
- **主要技術**: [関連する技術・ツール]
- **採用企業**: [採用している企業例]
- **本サービスへの適用可能性**: [高/中/低]
- **適用する場合の方針**: [どのように適用するか]
- **参照URL**: [情報源]
```
**例**:
```markdown
### トレンド1: サーバーレスアーキテクチャの採用拡大
- **概要**: AWS Lambda, Google Cloud Functions等のサーバーレス
技術を活用し、インフラ管理の負荷を削減
- **背景**: 運用コスト削減とスケーラビリティの向上
- **主要技術**: AWS Lambda, API Gateway, DynamoDB
- **採用企業**: Netflix, Coca-Cola, Airbnb
- **本サービスへの適用可能性**: 中
（一部のバッチ処理やAPI機能で適用検討）
- **適用する場合の方針**:
- まずはバッチ処理から試験導入
- コールドスタート対策を検討
- コスト監視を徹底
- **参照URL**: https://...
```
#### 2. 技術スタック
**整理フォーマット**:
```markdown
## 推奨技術スタック
| カテゴリ | 推奨技術 | 理由 | 採用率 | 参照 |
|----------|----------|------|--------|------|
| インフラ | [技術名] | [理由] | [%] | [URL] |
| 監視 | [技術名] | [理由] | [%] | [URL] |
| CI/CD | [技術名] | [理由] | [%] | [URL] |
```
#### 3. SLO/SLA水準
**整理フォーマット**:
```markdown
## 業界標準のSLO/SLA
| メトリクス | 標準値 | トップレベル | 参照 |
|------------|--------|--------------|------|
| 可用性 | 99.9% | 99.99% | [URL] |
| レスポンスタイム（P95） | 500ms | 200ms | [URL] |
| エラーレート | 0.1% | 0.01% | [URL] |
```
#### 4. セキュリティ・コンプライアンス
**整理フォーマット**:
```markdown
## セキュリティ・コンプライアンス要件
### 適用法規制
- [法規制名1]: [概要と要件]
- [法規制名2]: [概要と要件]
### セキュリティ基準
- [基準名1]: [要求事項]
- [基準名2]: [要求事項]
### 必須対策
1. [対策1]
2. [対策2]
```
---
## 業界別の調査ポイント
### Webサービス/SaaS
**重点調査項目**:
1. **可用性とパフォーマンス**
- 業界標準: 99.9%以上
- レスポンスタイム: P95で500ms以下
- スケーラビリティ戦略
2. **マルチテナンシー**
- データ分離方式（DB分離 vs スキーマ分離 vs行レベル分離）
- テナント間の影響隔離
- リソース配分
3. **API設計**
- RESTful API vs GraphQL
- レート制限
- バージョニング戦略
4. **認証・認可**
- OAuth 2.0, OpenID Connect
- SSO対応
- MFA（多要素認証）
**推奨検索クエリ**:
```
"SaaS 可用性 ベストプラクティス"
"マルチテナント アーキテクチャ 設計"
"SaaS セキュリティ 最新"
"API design best practices"
```
**主要参照先**:
- [The Twelve-Factor App](https://12factor.net/)
- AWS SaaS Factory
- Microsoft SaaS Architecture Guide
### EC/マーケットプレイス
**重点調査項目**:
1. **トランザクション管理**
- ACID特性の保証
- 分散トランザクション
- 在庫管理の整合性
2. **決済セキュリティ**
- PCI DSS準拠
- トークン化
- 不正検知
3. **ピーク対策**
- セール時のトラフィック急増対策
- キューイングシステム
- キャッシュ戦略
4. **検索・レコメンデーション**
- 検索エンジン（Elasticsearch等）
- パーソナライゼーション
- リアルタイム在庫連携
**推奨検索クエリ**:
```
"EC サイト 運用設計"
"PCI DSS 対応 要件"
"EC ピーク対策 アーキテクチャ"
"マーケットプレイス スケーラビリティ"
```
**主要参照先**:
- PCI Security Standards Council
- Amazon Architecture Blog（Black Friday対策等）
- Shopify Engineering Blog
### 金融サービス
**重点調査項目**:
1. **規制対応**
- 金融商品取引法
- 銀行法
- 各国の金融規制（日本:金融庁、米国:SEC, FINRA等）
2. **高可用性**
- 99.99%以上の可用性
- ゼロダウンタイムデプロイ
- DR（災害復旧）対策
3. **セキュリティ**
- 暗号化（転送時、保管時）
- アクセス制御
- 監査ログ
4. **データ整合性**
- 二重引き落とし防止
- データ復旧手順
- バックアップ戦略
**推奨検索クエリ**:
```
"金融システム 可用性 要件"
"金融機関 セキュリティ ガイドライン"
"fintech 規制 コンプライアンス 最新"
"banking system architecture"
```
**主要参照先**:
- 金融情報システムセンター（FISC）
- 金融庁ガイドライン
- Basel Committee on Banking Supervision
### メディア/コンテンツ配信
**重点調査項目**:
1. **CDN戦略**
- グローバル配信
- エッジキャッシング
- DDoS対策
2. **動画配信**
- アダプティブビットレート
- トランスコーディング
- DRM（デジタル著作権管理）
3. **スケーラビリティ**
- バイラルコンテンツ対策
- ライブ配信のピーク対策
- オートスケーリング
4. **コンテンツ管理**
- メタデータ管理
- バージョン管理
- コンテンツ配信ワークフロー
**推奨検索クエリ**:
```
"動画配信 アーキテクチャ"
"CDN ベストプラクティス 最新"
"ライブストリーミング スケーラビリティ"
"content delivery network optimization"
```
**主要参照先**:
- Netflix Tech Blog
- YouTube Engineering Blog
- Cloudflare Blog
### ヘルスケア
**重点調査項目**:
1. **個人情報保護**
- HIPAA（米国）
- 個人情報保護法（日本）
- GDPR（EU）
2. **医療データ管理**
- HL7 FHIR標準
- 電子カルテ連携
- 医療画像管理（DICOM）
3. **可用性**
- 医療業務継続性
- 緊急時対応
- バックアップ・DR
4. **監査対応**
- アクセスログ
- 変更履歴
- 監査レポート
**推奨検索クエリ**:
```
"ヘルスケア システム セキュリティ"
"HIPAA 準拠 要件"
"電子カルテ 連携 標準"
"healthcare IT security latest"
```
**主要参照先**:
- HIPAA Journal
- HL7 International
- 厚生労働省「医療情報システムの安全管理に関するガイドライン」
### ゲーム
**重点調査項目**:
1. **リアルタイム性**
- 低レイテンシ（<100ms）
- リアルタイム同期
- チート対策
2. **スケーラビリティ**
- 同時接続数の急増対応
- ワールドサーバーのスケーリング
- マッチングシステム
3. **データ管理**
- プレイヤーデータの永続化
- セーブデータの整合性
- ランキングシステム
4. **運用**
- ライブオペレーション
- イベント運営
- ゲームバランス調整
**推奨検索クエリ**:
```
"オンラインゲーム サーバー アーキテクチャ"
"ゲーム 低レイテンシ 設計"
"multiplayer game server architecture"
"game backend scalability"
```
**主要参照先**:
- Unity Blog
- Epic Games Engineering
- PlayFab Documentation（Microsoft）
---
## 最新トレンドの把握
### 主要トレンド
#### 1. 生成AI/LLMの運用への統合
**トレンド概要**:
- ChatGPT、Claude等のLLMを活用した運用自動化
- インシデント対応の支援
- ドキュメント生成の自動化
**調査ポイント**:
- 業界での採用事例
- セキュリティ・プライバシー対策
- コスト管理
- プロンプトエンジニアリング
**検索クエリ**:
```
"AI 運用自動化 最新"
"LLM インシデント対応"
"generative AI operations"
"AI ops automation latest"
```
#### 2. クラウドネイティブアーキテクチャ
**トレンド概要**:
- Kubernetes採用の拡大
- サーバーレスアーキテクチャ
- マイクロサービス化
**調査ポイント**:
- コンテナオーケストレーション
- サービスメッシュ（Istio, Linkerd）
- オブザーバビリティ（OpenTelemetry）
**検索クエリ**:
```
"Kubernetes 運用 ベストプラクティス 最新"
"サーバーレス アーキテクチャ 事例"
"cloud native operations"
"service mesh adoption latest"
```
#### 3. Platform Engineering
**トレンド概要**:
- 開発者体験（DX）の向上
- セルフサービスプラットフォーム
- Internal Developer Portal
**調査ポイント**:
- プラットフォームチームの組織
- ツールチェーンの統合
- ゴールデンパスの定義
**検索クエリ**:
```
"プラットフォームエンジニアリング 最新"
"Internal Developer Portal"
"platform engineering best practices"
"developer experience latest"
```
#### 4. FinOps（クラウドコスト最適化）
**トレンド概要**:
- クラウドコストの可視化と最適化
- FinOpsプラクティスの確立
- コスト配分の明確化
**調査ポイント**:
- コスト最適化手法
- ツール（Kubecost, CloudHealth等）
- 組織体制
**検索クエリ**:
```
"FinOps ベストプラクティス 最新"
"クラウドコスト 最適化"
"cloud cost optimization latest"
"FinOps framework"
```
#### 5. セキュリティの強化
**トレンド概要**:
- ゼロトラストアーキテクチャ
- DevSecOpsの浸透
- SBOM（Software Bill of Materials）
**調査ポイント**:
- ゼロトラスト実装
- セキュリティの左シフト
- サプライチェーンセキュリティ
**検索クエリ**:
```
"ゼロトラスト アーキテクチャ 最新"
"DevSecOps 実践"
"zero trust implementation"
"software supply chain security latest"
```
#### 6. SRE/DevOpsの成熟
**トレンド概要**:
- SLO文化の浸透
- エラーバジェットの活用
- カオスエンジニアリング
**調査ポイント**:
- SRE組織の作り方
- オブザーバビリティの実践
- レジリエンス向上施策
**検索クエリ**:
```
"SRE 組織 最新"
"エラーバジェット 運用"
"observability best practices latest"
"chaos engineering adoption"
```
### 情報鮮度の確認
**最新情報の判定基準**:
1. **公開日の確認**
- 過去1年以内: 最新情報として信頼度高
- 過去2年以内: 比較的新しい、採用可
- 3年以上前: 古い可能性あり、他の情報源と照合
2. **更新履歴の確認**
- 定期的に更新されているドキュメントか
- 最終更新日が最近か
3. **バージョン情報の確認**
- ツール・フレームワークのバージョンが最新か
- EOL（サポート終了）が近くないか
**信頼性の評価**:
| ソース種別 | 信頼度 | 注意点 |
|------------|--------|--------|
| 公式ドキュメント | ⭐⭐⭐⭐⭐ | 最新バージョンを確認 |
| 大手企業の技術ブログ | ⭐⭐⭐⭐ | 企業規模と自社の差を考慮 |
| カンファレンス資料 | ⭐⭐⭐⭐ | 開催年を確認 |
| 個人ブログ | ⭐⭐⭐ | 複数ソースで裏取り |
| ニュース記事 | ⭐⭐ | 技術的詳細は別途確認 |
---
## 調査結果の活用
### 調査結果のドキュメント化
調査結果を運用設計書の「業界トレンド分析」セクションに反映します。
**記載形式**:
```markdown
## 3. 業界トレンド分析
### 3.1 業界の最新動向
**調査日**: [調査実施日]
**主要トレンド**:
1. **[トレンド1]**
- 概要: [説明]
- 本サービスへの影響: [影響分析]
- 対応方針: [対応内容]
- 参照: [URL]
2. **[トレンド2]**
- 概要: [説明]
- 本サービスへの影響: [影響分析]
- 対応方針: [対応内容]
- 参照: [URL]
### 3.2 採用フレームワーク・ベストプラクティス
**採用フレームワーク**:
- **ITIL 4**: [採用する実践項目]
- インシデント管理
- 変更管理
- ...
- **SRE**: [採用する原則・プラクティス]
- SLO/SLIの設定
- エラーバジェット
- ...
- **DevOps**: [採用するプラクティス]
- CI/CD
- Infrastructure as Code
- ...
**根拠**: [調査結果からの判断理由]
### 3.3 競合分析
| 競合サービス | 運用品質の特徴 | 本サービスとの差別化 | 参照 |
|--------------|----------------|----------------------|------|
| [サービス名] | [特徴] | [差別化ポイント] | [URL] |
```
### 調査結果の運用設計への反映
調査結果を以下のセクションに反映します：
1. **SLO/SLIの設定**
- 業界標準を参考に目標値を設定
- 競合との比較で差別化ポイントを決定
2. **技術スタックの選定**
- 業界トレンドの技術を優先検討
- 実績のある技術の採用
3. **セキュリティ・コンプライアンス**
- 業界固有の規制要件を反映
- 必須対策の実施
4. **運用プロセス**
- ベストプラクティスを参考にプロセス設計
- 業界標準との整合性確保
### ユーザーへの提案
調査結果を基に、ユーザーに推奨事項を提案します。
**提案フォーマット**:
```
[業界名]の最新トレンド調査結果に基づき、以下を提案します：
【推奨する対応】
1. [トレンド/技術名]の採用 ⭐⭐⭐⭐⭐
- 理由: [根拠]
- 効果: [期待される効果]
- リスク: [想定されるリスク]
- 実装難易度: [高/中/低]
2. [トレンド/技術名]の採用 ⭐⭐⭐⭐
- 理由: [根拠]
- 効果: [期待される効果]
- リスク: [想定されるリスク]
- 実装難易度: [高/中/低]
【検討が必要な項目】
1. [トレンド/技術名] ⭐⭐⭐
- 概要: [説明]
- メリット: [利点]
- デメリット: [欠点]
- 貴社の状況に照らして採用すべきか、ご意見をお聞かせください
【採用を推奨しない項目】
1. [トレンド/技術名] ⭐
- 理由: [不採用の理由]
これらの提案について、ご意見をお聞かせください。
```
### 継続的な調査
運用設計書作成後も、定期的に業界動向を調査します。
**調査頻度**:
| 調査内容 | 頻度 | 目的 |
|----------|------|------|
| 業界トレンド | 四半期 | 新しいトレンドのキャッチアップ |
| セキュリティ脅威 | 月次 | 新しい脅威への対策 |
| 規制変更 | 随時 | コンプライアンス維持 |
| ツール・技術の更新 | 月次 | 技術スタックの最新化 |
**調査結果の反映**:
- 運用設計書の更新
- 改善計画への組み込み
- ステークホルダーへの共有
---
## まとめ
業界調査は運用設計の成功に不可欠です。以下のポイントを押さえて調査を実施してください：
1. **体系的な調査**
- 業界分類の特定
- 網羅的な情報収集
- 信頼性の高いソースの活用
2. **最新情報の重視**
- 直近の情報を優先
- トレンドの把握
- 技術の進化への対応
3. **実践的な活用**
- 調査結果の運用設計への反映
- ユーザーへの明確な提案
- 継続的な情報更新
4. **推論の排除**
- 事実に基づく分析
- 情報源の明示
- 不明点はユーザーに確認
この調査ガイドラインに従って、高品質な運用設計を実現してください。

1536
skills/operations-design/references/operations_design_guide_ja.md Normal file
View File

File diff suppressed because it is too large Load Diff