decomposition-reconstruction

分解と再構築

ワークフロー

このチェックリストをコピーして、進捗を記録してください。

Decomposition & Reconstruction Progress:
- [ ] Step 1: Define the system and goal
- [ ] Step 2: Decompose into components and relationships
- [ ] Step 3: Analyze component properties and interactions
- [ ] Step 4: Reconstruct for insight or optimization
- [ ] Step 5: Validate and deliver recommendations

Step 1：システムと目標を定義する

ユーザーに、システム（何を分析するのか）、現在の問題または目標（何を改善、理解、再設計する必要があるのか）、境界（対象範囲と対象外の範囲）、成功基準（「より良い」状態とはどのようなものか）を説明してもらいます。境界を明確にすると、分解が際限なく続くのを防げます。確認用の質問については、スコープ設定の質問を参照してください。

Step 2：コンポーネントと関係性に分解する

意味のある単位にこれ以上分割できない、最小単位の部分にシステムを分解します。関係性（依存関係、データフロー、制御フロー、時間的な順序）を特定します。システムの種類に応じて、分解戦略を選択します。体系的なプロセスについては、分解戦略とresources/template.mdを参照してください。

Step 3：コンポーネントの特性と相互作用を分析する

各コンポーネントについて、主要な特性（コスト、時間、複雑さ、信頼性など）を特定します。相互作用（どのコンポーネントがどのコンポーネントに依存しているか）を整理します。クリティカルパス、ボトルネック、脆弱な箇所を特定します。複雑な分析については、依存関係のマッピングとクリティカルパスの手法に関するresources/methodology.mdを参照してください。

Step 4：洞察または最適化のために再構築する

目標に応じて、次のいずれかを行います。（a）重要なコンポーネント（ボトルネック、単一障害点、最もコストに影響する要因）を特定する。（b）構成を再設計する（順序変更、並列化、削除、コンポーネントの統合）。（c）簡素化する（不要なコンポーネントを削除する）。一般的なアプローチについては、再構築パターンを参照してください。

Step 5：検証し、推奨事項を提示する

resources/evaluators/rubric_decomposition_reconstruction.jsonを使って自己評価します（最低スコア ≥ 3.5）。コンポーネントの明確な内訳、分析結果（ボトルネック、依存関係）、期待される効果を含む実行可能な推奨事項を記載したdecomposition-reconstruction.mdを提示します。

スコープ設定の質問

システムを定義するには：

• 分析対象のシステムは何ですか？（具体的に：「ウェブサイト」ではなく「チェックアウトのフロー」）
• どこから始まり、どこで終わりますか？（境界）
• 対象範囲と対象外の範囲は何ですか？（分解が際限なく続くのを防ぎます）

目標を明確にするには：

• どのような問題を解決しますか？（パフォーマンスの低下、高コスト、複雑さ、信頼性の低さ）
• 成功とはどのような状態ですか？（具体的な目標：「レイテンシを <500ms に短縮する」「コストを30％削減する」）
• 最適化、理解、再設計のどれを目指しますか？

制約を把握するには：

• 変更できないものは何ですか？（レガシーシステム、予算の上限、規制要件）
• どのくらいの期間を想定していますか？（すぐに得られる成果と長期的な再設計）
• ステークホルダーは誰ですか？（エンジニアリング、ビジネス、顧客）

分解戦略

システムの種類に応じて選択します。

機能分解

対象： ビジネスプロセス、ソフトウェア機能、ワークフロー アプローチ： 機能またはタスクごとに分解します 例： E コマースのチェックアウト → 商品を閲覧 | カートに追加 | 配送先を入力 | 支払い | 確認

構造分解

対象： アーキテクチャ、組織、物理システム アプローチ： コンポーネントまたはモジュールごとに分解します 例： ウェブアプリ → フロントエンド（React）| API（Node.js）| データベース（PostgreSQL）| キャッシュ（Redis）

データフロー分解

対象： パイプライン、ETL プロセス、情報システム アプローチ： データ変換ごとに分解します 例： 分析パイプライン → 生イベントを取り込む | クリーンアップして検証する | メトリクスを集計する | データウェアハウスに保存する | ダッシュボードで可視化する

時間的分解

対象： 段階的に進むプロセス、タイムライン、ユーザージャーニー アプローチ： 時間または順序ごとに分解します 例： 顧客オンボーディング → 1日目：登録 | 2～7日目：チュートリアル | 8～30日目：初めて価値を実感する | 31日目以降：定着

コスト／リソースの分解

使用する場面： 予算分析、リソース配分、最適化 アプローチ： コストセンターまたはリソースの種類ごとに分解します 例： AWS の請求額 → コンピューティング（$5K） | ストレージ（$2K） | データ転送（$1K） | その他（$500）

深さの指針： さらに分解しても有用な洞察や実行可能な機会が得られなくなった時点で、分解を止めます。

コンポーネント間の関係の種類

分解した後、関係をマッピングします。

1. 依存関係（A が B を必要とする）：

• API サービスはデータベースに依存します
• フロントエンドは API に依存します
• 重要な理由：連鎖的な障害を特定し、変更の影響を把握するため

2. データフロー（A が B にデータを送る）：

• ユーザー入力 → 検証 → データベース → API レスポンス
• 重要な理由：情報を追跡し、変換のボトルネックを見つけるため

3. 制御フロー（A が B をトリガーする）：

• ボタンのクリックがフォーム送信をトリガーします
• 支払いの成功が注文のフルフィルメントをトリガーします
• 重要な理由：実行経路を理解し、競合状態を特定するため

4. 時系列の順序（時間的に A が B より先）：

• 認証は認可より先に行います
• デプロイの前にコンパイルします
• 重要な理由：順序付けや、並列化の機会を見つけるため

5. リソースの共有（A と B が C を取り合う）：

• 複数のサービスがデータベース接続プールを共有します
• チームが予算を共有します
• 重要な理由：競合やリソースの制約を特定するため

再構築のパターン

パターン 1：ボトルネックの特定

目的： システムのスループットや速度を制限する要因を見つけます アプローチ： コンポーネントの特性（時間、コスト、容量）を測定し、クリティカルパスまたは最も大きな値を特定します 例： リクエスト時間の 80% を DB クエリが占める → まず DB クエリを最適化します

パターン 2：簡素化

目的： 不要な部分を取り除いて複雑さを軽減します アプローチ： 各コンポーネントが必要かどうかを検討し、冗長な部分や価値の低い部分を取り除きます 例： ワークフローに 5 つの承認ステップがあり、そのうち 3 つが冗長 → 3 つのステップを削除します

パターン 3：順序の変更

目的： 順序を変えて効率を高めます アプローチ： 依存関係を特定し、依存しないタスクを前倒しするか、並列で実行します 例： テストをビルドと逐次実行する代わりに並列実行する → CI 時間を短縮します

パターン 4：並列化

目的： 作業を同時に行い、スループットを高めます アプローチ： 互いに独立したコンポーネントを見つけ、同時に実行します 例： ユーザーデータと商品データを逐次取得する代わりに並列取得する → レイテンシを半分にします

パターン 5：置き換え

目的： 性能の低いコンポーネントを、より優れた代替手段に置き換えます アプローチ： 性能の低いコンポーネントを特定し、代替手段を見つけます 例： 同期 API 呼び出しを非同期メッセージキューに置き換える → 信頼性を高めます

パターン 6：統合

目的： 類似するコンポーネントをまとめてオーバーヘッドを減らします アプローチ： 冗長または重複するコンポーネントを見つけて統合します 例： 類似した処理を行う 3 つのマイクロサービスを 1 つに統合する → 運用オーバーヘッドを減らします

パターン 7：モジュール化

目的： 関心事を分離して保守性を高めます アプローチ： 密結合したコンポーネントを特定し、明確なインターフェースで分離します 例： モノリスから認証ロジックを別のサービスに切り出す → 個別のスケーリングを可能にします

このスキルを使用しない場合

次の場合は、分解と再構築を行いません。

• システムがすでに単純な場合（明らかなコンポーネントが 3～5 個で、複雑な相互作用がない）
• 問題がシステム構造に関するものではない場合（設計上の問題ではなく、純粋に実行上の問題）
• 創造性やアイデア出しが必要な場合（分析ではない場合）。その場合はブレインストーミングを使用します
• システムへの理解が不十分な場合（分解ではなく、まず調査や情報収集が必要）
• 変更が不可能な場合（分析結果に基づいて行動できないなら、分析する意味がない）

代わりに使用するもの：

• 単純なシステム → 直接分析または観察
• 実行上の問題 → プロジェクト管理、プロセス改善
• アイデアが必要 → ブレインストーミング、デザイン思考
• 不明なシステム → 発見のためのインタビュー、調査
• 変更できないもの → 回避策の計画、制約下での最適化

ドメイン別の一般的なパターン

ソフトウェアアーキテクチャ：

• 分解：モジュール、サービス、レイヤー、データストア
• 再構成の目的：マイクロサービスへの移行、パフォーマンスの最適化、結合度の低減

ビジネスプロセス：

• 分解：ステップ、判断ポイント、引き継ぎ、承認
• 再構成の目的：サイクルタイムの短縮、自動化の機会の特定、無駄の排除

問題解決：

• 分解：サブ問題、依存関係、不明点、制約
• 再構成の目的：タスクの順序付け、阻害要因の特定、並行して進められる作業の発見

コスト最適化：

• 分解：コストセンター、明細項目、リソース使用量
• 再構成の目的：最大のコスト要因の特定、すぐに実施できる改善策の発見

ユーザーエクスペリエンス：

• 分解：ユーザージャーニーの段階、インタラクション、課題点
• 再構成の目的：フローの簡素化、障壁の除去、コンバージョンの改善

システムの信頼性：

• 分解：コンポーネント、障害モード、依存関係
• 再構成の目的：単一障害点の特定、レジリエンスの向上

クイックリファレンス

プロセス：

1. システムと目標を定義する → 範囲を設定する
2. 分解する → コンポーネントと関係性に分ける
3. 分析する → 特性を測定し、インタラクションをマッピングする
4. 再構成する → 最適化、簡素化、または再設計する
5. 検証する → 評価基準に照らして確認し、提案を提示する

分解戦略：

• 機能別（タスク別）、構造別（コンポーネント別）、データフロー、時間別、コスト／リソース別

再構成パターン：

• ボトルネックの特定、簡素化、順序の変更、並列化、置換、統合、モジュール化

リソース：

• resources/template.md - テンプレートを使用した構造化された分解プロセス
• resources/methodology.md - 高度な手法（依存関係グラフ、クリティカルパス分析、階層的分解）
• resources/evaluators/rubric_decomposition_reconstruction.json - 品質チェックリスト

成果物： コンポーネントの内訳、分析、提案をまとめた decomposition-reconstruction.md