Workflow Analyzer

概要

このSkillは、ユーザーが提供する作業フローや業務手順の情報を基に、自動化可能な要素を分析・特定する。ユーザーとの対話を通じて作業の詳細を理解し、プラグイン化すべきスキルや作業の依存関係を明確にする。

責任範囲

このSkillは以下の範囲をカバーする:

• 作業フローや業務手順の収集
• 作業ステップの分解と詳細化
• 自動化可能な要素の特定と評価
• ワークフロースキルとコンベンションスキルの分類
• 推奨スキル構成の提案
• 作業フロー分析レポートの作成

ワークフロー

フェーズ1: フロー収集

ユーザーとの対話を通じて、作業フローや業務手順に関する情報を収集する。

実施内容:

1. 作業フローの概要を確認する
2. 作業の開始条件（トリガー）を特定する
3. 作業の終了条件（完了基準）を確認する
4. 作業に関わる人やシステムを把握する
5. 既存の手順書やドキュメントを確認する

質問例:

【作業フローの確認】
分析したい作業フローを教えてください。

1. 作業名: [作業の名称]
2. 目的: [この作業で達成したいこと]
3. 頻度: [どのくらいの頻度で実施するか]
4. 所要時間: [1回あたりの作業時間]
5. 担当者: [誰が実施するか]

良い例:

作業名: コードレビュー実施
目的: コード品質を確保し、バグやセキュリティ問題を早期発見する
頻度: プルリクエストごと（1日5〜10回）
所要時間: 1回あたり30分〜1時間
担当者: シニアエンジニア、テックリード

開始条件:
- プルリクエストが作成される
- CI/CDパイプラインが成功する

終了条件:
- レビューコメントが全て解決される
- 承認者が2名以上Approveする
- マージ可能な状態になる

悪い例:

作業名: レビュー
目的: 確認する
頻度: たまに
所要時間: 適当
担当者: 誰か

フェーズ2: ステップ分解

作業フローを具体的なステップに分解し、各ステップの詳細を明確にする。

実施内容:

1. 作業を順序通りのステップに分解する
2. 各ステップの入力と出力を定義する
3. ステップ間のデータ受け渡しを確認する
4. 条件分岐や繰り返しを特定する
5. 各ステップの判断基準やルールを明確にする
6. 各ステップで使用するテンプレートファイルやフォーマットを特定する

分解基準:

• 1ステップは1つの明確な目的を持つ
• ステップの粒度は適切である（細かすぎず、粗すぎず）
• ステップ間の依存関係が明確である
• 各ステップの完了条件が定義できる

良い例:

【コードレビュー実施フロー】

ステップ1: プルリクエスト確認
- 入力: プルリクエストURL
- 処理: PR内容、変更ファイル、コミットメッセージを確認
- 出力: レビュー対象の特定、優先度判断
- 判断基準: 変更規模、影響範囲、緊急度

ステップ2: 静的解析結果確認
- 入力: CI/CDパイプライン結果
- 処理: linter、型チェック、セキュリティスキャン結果を確認
- 出力: 自動検出された問題リスト
- 判断基準: エラーがゼロであること

ステップ3: コード品質チェック
- 入力: 変更されたコード
- 処理: コーディング規約、設計原則、ベストプラクティスに照らしてチェック
- 出力: 品質問題リスト、改善提案
- 判断基準: コーディング規約、SOLID原則、セキュリティガイドライン

ステップ4: テストカバレッジ確認
- 入力: テスト実行結果、カバレッジレポート
- 処理: テストの網羅性、テストの品質を確認
- 出力: テスト改善提案
- 判断基準: カバレッジ80%以上、エッジケースのテストが含まれる

ステップ5: レビューコメント作成
- 入力: 品質問題リスト、改善提案
- 処理: コメントの優先度付け、具体的な修正案の作成
- 出力: レビューコメント
- 判断基準: 建設的、具体的、実行可能

ステップ6: 承認判断
- 入力: 全てのチェック結果、レビューコメント
- 処理: 承認可否を判断
- 出力: Approve or Request Changes
- 判断基準: 重大な問題がゼロ、軽微な問題は許容範囲内

悪い例:

ステップ1: 確認する
ステップ2: チェックする
ステップ3: 終わり

フェーズ3: 自動化分析

各ステップを分析し、自動化可能性を評価する。

実施内容:

1. 各ステップの自動化可能性を評価する
2. 自動化の難易度を判定する
3. 自動化による効果を見積もる
4. 手作業が必要な部分を特定する
5. 自動化の優先順位を付ける

評価基準:

• 自動化可能性: 高/中/低
  • 高: 明確なルールがあり、判断が機械的
  • 中: ある程度のルールがあるが、一部判断が必要
  • 低: 人間の経験や直感が必要
• 自動化難易度: 容易/中程度/困難
  • 容易: 既存ツールやAPIで実現可能
  • 中程度: カスタム実装が必要だが実現可能
  • 困難: 技術的制約があり実現が難しい
• 自動化効果: 高/中/低
  • 高: 時間削減が大きい、ミス削減効果が高い
  • 中: 一定の効果がある
  • 低: 効果が限定的

良い例:

【自動化分析結果】

ステップ1: プルリクエスト確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 中
- 理由: GitHub APIで情報取得可能、基本的な分析は自動化できる
- 手作業部分: 優先度の最終判断（レビュー者の経験に基づく）

ステップ2: 静的解析結果確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 高
- 理由: CI/CD結果の取得と解析は完全自動化可能
- 手作業部分: なし

ステップ3: コード品質チェック
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 高
- 理由: コーディング規約チェックは自動化可能だが、設計原則の評価は難しい
- 手作業部分: アーキテクチャレビュー、設計の妥当性判断

ステップ4: テストカバレッジ確認
- 自動化可能性: 高
- 自動化難易度: 容易
- 自動化効果: 高
- 理由: カバレッジレポートの解析は完全自動化可能
- 手作業部分: テストの品質評価（テストが適切かどうか）

ステップ5: レビューコメント作成
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 中
- 理由: 定型的なコメントは自動生成可能、建設的なコメントは難しい
- 手作業部分: 具体的な修正提案、コンテキストに応じたアドバイス

ステップ6: 承認判断
- 自動化可能性: 中
- 自動化難易度: 中程度
- 自動化効果: 低
- 理由: ルールベースの判断は可能だが、最終承認は人間が行うべき
- 手作業部分: 最終的な承認判断

悪い例:

全部自動化できる

フェーズ4: スキル分類

自動化可能な要素をワークフロースキルとコンベンションスキルに分類する。

実施内容:

1. 作業手順をワークフロースキル候補として分類する
2. 規約やガイドラインをコンベンションスキル候補として分類する
3. 各スキルの責任範囲を定義する
4. スキル間の依存関係を整理する
5. 必要なテンプレートファイルと対応するスキルの関係を特定する
6. スキルの粒度を調整する

分類基準:

• ワークフロースキル: 具体的な作業手順を定義する
  • 入力、処理、出力が明確
  • ステップが順序立てられている
  • チェックリストや検証項目がある
• コンベンションスキル: 規約やガイドラインを定義する
  • ルールや基準が明確
  • 良い例/悪い例が示せる
  • チェックリストで検証可能

良い例:

【スキル分類結果】

ワークフロースキル候補:

1. pull-request-analyzer
   - 責任範囲: プルリクエストの内容を分析し、レビュー対象を特定する
   - 入力: プルリクエストURL
   - 出力: レビュー対象の特定、優先度判断、変更サマリー
   - 依存: なし

2. static-analysis-checker
   - 責任範囲: CI/CD静的解析結果を確認し、問題を抽出する
   - 入力: CI/CDパイプライン結果
   - 出力: 問題リスト、重要度分類
   - 依存: なし

3. code-quality-reviewer
   - 責任範囲: コード品質をチェックし、改善提案を作成する
   - 入力: 変更されたコード、コーディング規約
   - 出力: 品質問題リスト、改善提案
   - 依存: coding-conventions

4. test-coverage-analyzer
   - 責任範囲: テストカバレッジを確認し、テスト改善提案を作成する
   - 入力: テスト実行結果、カバレッジレポート
   - 出力: カバレッジ分析結果、テスト改善提案
   - 依存: なし

5. review-comment-generator
   - 責任範囲: レビューコメントを生成し、優先度付けを行う
   - 入力: 品質問題リスト、改善提案
   - 出力: レビューコメント
   - 依存: review-comment-guidelines

コンベンションスキル候補:

1. coding-conventions
   - 責任範囲: コーディング規約（命名規則、フォーマット、ベストプラクティス）を定義
   - カテゴリ: 命名規則、コードレイアウト、設計原則
   - 良い例/悪い例: あり

2. review-comment-guidelines
   - 責任範囲: レビューコメントのガイドライン（建設的、具体的、実行可能）を定義
   - カテゴリ: コメントの書き方、優先度付け、フィードバックの伝え方
   - 良い例/悪い例: あり

悪い例:

スキル: レビュー全部

フェーズ5: 推奨提示

分類結果を基に、推奨されるスキル構成をユーザーに提示する。

実施内容:

1. 推奨されるワークフロースキル構成を提示する
2. 推奨されるコンベンションスキル構成を提示する
3. スキルの実行順序を明示する
4. 実装の優先順位を提案する
5. 次のステップ（各スキルの詳細設計）を案内する

提示形式:

【推奨スキル構成】

ワークフロースキル (5個):
- pull-request-analyzer: プルリクエストの内容を分析し、レビュー対象を特定する
- static-analysis-checker: CI/CD静的解析結果を確認し、問題を抽出する
- code-quality-reviewer: コード品質をチェックし、改善提案を作成する
- test-coverage-analyzer: テストカバレッジを確認し、テスト改善提案を作成する
- review-comment-generator: レビューコメントを生成し、優先度付けを行う

コンベンションスキル (2個):
- coding-conventions: コーディング規約を定義
- review-comment-guidelines: レビューコメントのガイドラインを定義

【実行順序】

1. pull-request-analyzer (並列実行可能)
2. static-analysis-checker (並列実行可能)
3. code-quality-reviewer (coding-conventionsに依存)
4. test-coverage-analyzer (並列実行可能)
5. review-comment-generator (review-comment-guidelinesに依存)

【実装優先順位】

優先度1（必須）:
- coding-conventions
- pull-request-analyzer
- static-analysis-checker
- code-quality-reviewer

優先度2（推奨）:
- test-coverage-analyzer
- review-comment-guidelines
- review-comment-generator

【自動化効果見積もり】

現状: 1回あたり30分〜1時間（手作業）
自動化後: 1回あたり10分〜15分（自動+人間の最終判断）
削減効果: 約60%〜75%の時間削減

良い例:

推奨構成が明確で、各スキルの役割、実行順序、優先順位が説明されており、自動化効果も示されている。

悪い例:

スキルをいくつか作る

アウトプット

このスキルは以下を生成する:

• 自動化可能な要素リスト: 各ステップの自動化可能性評価（自動化可能性、難易度、効果）
• 推奨スキル構成: ワークフロースキルとコンベンションスキルの推奨構成
• テンプレートファイルリスト: 各ステップで使用するテンプレートファイルの一覧（配置先を含む）
• 作業フロー分析レポート: 作業フローの特徴、ボトルネック、自動化効果をまとめたドキュメント

想定されるエラーと対処法

エラー1: ステップ分解が粗すぎる

検出例:

ステップ1: レビューする
ステップ2: 終わり

対処法:

• 各ステップをさらに細かく分解する
• 1ステップは1つの明確な目的を持つようにする
• 入力と出力を明確にする

エラー2: 自動化可能性の評価が不明確

検出例:

自動化可能性: たぶんできる

対処法:

• 明確な評価基準（高/中/低）を使用する
• 評価の理由を具体的に記述する
• 手作業が必要な部分を明示する

エラー3: スキルの粒度が不適切

検出例:

スキルが大きすぎる、または小さすぎる。

対処法:

• 1スキルは1つの明確な責任を持つようにする
• スキルが大きすぎる場合は分割する
• スキルが小さすぎる場合は統合する
• スキル粒度規約に従う

ベストプラクティス

• 作業フローは実際の作業者にヒアリングして収集する
• ステップ分解は細かすぎず、粗すぎず適切な粒度にする
• 自動化分析は客観的な基準で評価する
• スキル分類は明確な基準に基づいて行う
• 推奨構成は実装の優先順位を明示する
• 自動化効果を定量的に示す（時間削減率など）

チェックリスト

フロー収集完了時

• 作業フローの概要が明確になっている
• 作業の開始条件（トリガー）が特定されている
• 作業の終了条件（完了基準）が確認されている
• 作業に関わる人やシステムが把握されている
• 既存の手順書やドキュメントが確認されている

ステップ分解完了時

• 作業が順序通りのステップに分解されている
• 各ステップの入力と出力が定義されている
• ステップ間のデータ受け渡しが確認されている
• 条件分岐や繰り返しが特定されている
• 各ステップの判断基準やルールが明確になっている
• 各ステップで使用するテンプレートファイルやフォーマットが特定されている
• ステップの粒度が適切である

自動化分析完了時

• 各ステップの自動化可能性が評価されている
• 自動化の難易度が判定されている
• 自動化による効果が見積もられている
• 手作業が必要な部分が特定されている
• 自動化の優先順位が付けられている
• 評価基準が明確である

スキル分類完了時

• ワークフロースキル候補が特定されている
• コンベンションスキル候補が特定されている
• 各スキルの責任範囲が定義されている
• スキル間の依存関係が整理されている
• 必要なテンプレートファイルと対応するスキルの関係が特定されている
• スキルの粒度が適切である

推奨提示完了時

• 推奨スキル構成が明確に提示されている
• スキルの実行順序が明示されている
• 実装の優先順位が提案されている
• 自動化効果が定量的に示されている
• 次のステップが案内されている
• ユーザーの承認を得ている

最終確認

• 自動化可能な要素リストが作成されている
• 推奨スキル構成が提示されている
• 作業フロー分析レポートが作成されている
• すべてのアウトプットが明確で理解しやすい
• ユーザーが次のステップに進める状態になっている