Agent-almanac assess-form

install

source · Clone the upstream repo

git clone https://github.com/pjt222/agent-almanac

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/pjt222/agent-almanac "$T" && mkdir -p ~/.claude/skills && cp -r "$T/i18n/ja/skills/assess-form" ~/.claude/skills/pjt222-agent-almanac-assess-form-d0fb74 && rm -rf "$T"

manifest: i18n/ja/skills/assess-form/SKILL.md

source content

形態の評価

システムの現在の構造的形態 — アーキテクチャ、剛性、圧力ポイント、変化の容量 — を評価して、メタモルフォーシスを開始する前に変革準備度を判定する。

使用タイミング

重要なアーキテクチャ変更前に出発点を理解する時
システムが「行き詰まっている」が理由が不明な時
外部圧力（成長、市場の変化、技術的負債）が高まっているが対応が不確かな時
提案された変革が現在の形態で実行可能か評価する時
長期稼働システムの定期的な健全性チェック（年次形態評価）
```
adapt-architecture
```
を補完する — まず評価し、その後変革する

入力

必須: 評価するシステム（コードベース、組織、インフラストラクチャ、プロセス）
任意: 提案された変革の方向性（システムは何になる必要があるか？）
任意: 既知のペインポイントまたは圧力源
任意: 過去の変革試みとその結果
任意: 潜在的な変革のタイムホライズン
任意: 変革作業に利用可能なリソース

手順

ステップ1: 現在の形態のインベントリ

システムの構造要素を判断なしにカタログ化する — 評価する前に何が存在するかを理解する。

構造コンポーネントをマッピングする:
- モジュール: 個別の機能ユニット（サービス、チーム、パッケージ、部門）
- インターフェース: モジュールの接続方法（API、プロトコル、契約、レポートライン）
- データフロー: システム内の情報の流れ方
- 依存関係: 何が何に依存するか（直接、推移的、循環的）
- 荷重構造: 他のすべてが依存するコンポーネント
形態の年齢と履歴を文書化する:
- 各主要コンポーネントはいつ導入されたか？
- 最近変更されたコンポーネントと静的なままのコンポーネントは？
- 「地層」構造は何か（古いコア、新しい追加、最近のパッチ）？
形態の「骨格」vs「肉」を特定する:
- 骨格: 変更コストが極めて高い構造的決定（言語、データベース、デプロイモデル）
- 肉: より容易に変更可能な機能的決定（ビジネスロジック、UI、設定）

Structural Inventory Template:
┌──────────────┬──────────┬────────────┬───────────────────┬──────────┐
│ Component    │ Age      │ Last       │ Dependencies      │ Type     │
│              │          │ Modified   │ (in / out)        │          │
├──────────────┼──────────┼────────────┼───────────────────┼──────────┤
│ Auth service │ 3 years  │ 6 months   │ In: 12 / Out: 3  │ Skeleton │
│ Dashboard UI │ 1 year   │ 2 weeks    │ In: 2 / Out: 5   │ Flesh    │
│ Data pipeline│ 4 years  │ 1 year     │ In: 3 / Out: 8   │ Skeleton │
│ Config store │ 2 years  │ 3 months   │ In: 0 / Out: 15  │ Skeleton │
└──────────────┴──────────┴────────────┴───────────────────┴──────────┘

期待結果: コンポーネント、年齢、変更の新しさ、依存関係プロファイル、骨格または肉としての分類を示す完全な構造インベントリ。これは現在の形態の「レントゲン写真」である。

失敗時: インベントリが不完全な場合（コンポーネントが不明またはドキュメント化されていない）、それ自体が発見事項 — 形態には不透明性があり、変革リスクとなる。可能な範囲で文書化し、不明点をフラグ立てし、ギャップの発見を計画する。

ステップ2: 変革圧力のマッピング

システムを変化に向かって押す力と抵抗する力を特定する。

外部圧力（変化を要求する力）をカタログ化する:
- 成長圧力: 現在の形態では増加する負荷に対応できない
- 市場圧力: 競合他社やユーザーが現在の形態ではサポートできない機能を要求する
- 技術圧力: 基盤技術が陳腐化またはサポート終了に向かっている
- 規制圧力: 現在の形態が満たさないコンプライアンス要件
- 統合圧力: 現在の形態が設計されていないシステムと接続する必要がある
内部圧力（内部からの変化を要求する力）をカタログ化する:
- 技術的負債: 開発を遅らせる蓄積されたショートカット
- 知識集中: 重要な知識が少数の人に保持されている
- 士気圧力: 現在の形態に対するチームのフラストレーション
- 運用負担: 開発に充てるべきリソースを消費するメンテナンスコスト
抵抗力（変化に反対する力）をカタログ化する:
- 慣性: 既存の形態が「十分に」機能する
- 依存関係のロックイン: 現在の形態に依存するものが多すぎる
- 知識損失リスク: 変革が制度的知識を破壊する可能性がある
- コスト: 変革にはリターンが不確かな投資が必要
- 恐怖: 過去の変革試みが失敗した

期待結果: システムに作用する力の方向と大きさを示す圧力マップ。変革圧力が抵抗を大幅に上回る場合、変革が遅れている。抵抗が圧力を大幅に上回る場合、まず抵抗を減らさなければ変革は失敗する。

失敗時: 圧力マッピングがバランスの取れた結果を生む場合（強い圧力も強い抵抗もない）、システムは変革を必要としない可能性がある — または分析が表面的。より深く掘り下げる: ステークホルダーにインタビューし、特定のペインポイントを測定し、12-18ヶ月先を予測する。どの圧力が強まるか？

ステップ3: 構造的剛性の評価

現在の形態がどの程度柔軟か剛性か判定する — 曲がることができるか、壊れるか？

インターフェースの柔軟性をテストする:
- カスケード変更なしにモジュールを置換できるか？（疎結合 = 柔軟）
- インターフェースは明確に定義され安定しているか？（契約の明確さ = 柔軟）
- すべてが依存する「神モジュール」はいくつ存在するか？（集中 = 剛性）
データの柔軟性をテストする:
- データ移行は簡単か？（スキーマ進化ツール、バージョニング）
- データフォーマットは標準化されているか独自か？（独自 = 剛性）
- ビジネスロジックはデータ構造とどの程度絡み合っているか？（絡み合い = 剛性）
プロセスの柔軟性をテストする:
- チームは変更を迅速にシップできるか？（デプロイパイプラインの健全性）
- テストスイートは包括的か？（変更のためのセーフティネット）
- 「触れてはいけない」コンポーネントはいくつ存在するか？（禁止ゾーン = 剛性）
剛性スコアを計算する:

Rigidity Assessment:
┌──────────────────────┬─────┬──────────┬──────┬──────────────────────┐
│ Dimension            │ Low │ Moderate │ High │ Your Assessment      │
├──────────────────────┼─────┼──────────┼──────┼──────────────────────┤
│ Interface coupling   │ 1   │ 2        │ 3    │ ___                  │
│ God module count     │ 1   │ 2        │ 3    │ ___                  │
│ Data entanglement    │ 1   │ 2        │ 3    │ ___                  │
│ Deployment friction  │ 1   │ 2        │ 3    │ ___                  │
│ Test coverage gaps   │ 1   │ 2        │ 3    │ ___                  │
│ "Don't touch" zones  │ 1   │ 2        │ 3    │ ___                  │
├──────────────────────┼─────┴──────────┴──────┼──────────────────────┤
│ Total (max 18)       │ 6-9: flexible         │ ___                  │
│                      │ 10-13: moderate        │                      │
│                      │ 14-18: rigid           │                      │
└──────────────────────┴───────────────────────┴──────────────────────┘

期待結果: 変革が遭遇する構造的抵抗を定量化する剛性スコア。柔軟なシステム（6-9）は段階的に変革できる。剛性の高いシステム（14-18）は再構築の前に溶解が必要（

dissolve-form

を参照）。

失敗時: 剛性評価が決定的でない場合（中程度のスコアだが本当の問題がどこにあるか不明）、最高スコアの次元に焦点を当てる。システムは全体的に柔軟だが、変革をブロックする1つの極めて剛性の高いコンポーネントを持つ可能性がある。そのコンポーネントを特定して対処する。

ステップ4: 変化容量の推定

システム（とチーム）が変革を吸収し実行する能力を評価する。

利用可能な変革エネルギー:
- チーム容量の何パーセントを変革に割り当てられるか？
- 組織的サポート（予算、権限、忍耐）はあるか？
- 適切なスキルが利用可能か（アーキテクチャ、移行、テスト）？
変化吸収率:
- 不安定化せずにシステムは時間単位あたり何回の変更を吸収できるか？
- 重大な変更後の回復時間は？
- 段階的変革のためのステージング/カナリアメカニズムはあるか？
変革の経験:
- チームは以前に類似のシステムを成功裏に変革したことがあるか？
- 変革ツールとプラクティスは整っているか（フィーチャーフラグ、ストラングラーフィグ、ブルーグリーン）？
- チームのリスク許容度は？
変化容量を計算する:
- 高容量: 専任チーム、強力なツーリング、過去の経験、組織的サポート
- 中程度の容量: パートタイムの割り当て、一部のツーリング、限定的な経験
- 低容量: 専任リソースなし、ツーリングなし、経験なし、抵抗的な組織

期待結果: 現在のリソース、スキル、組織的サポートを考慮して、システム/チームが提案された変革を実行できるかを示す変化容量評価。

失敗時: 変化容量が低いが変革圧力が高い場合、最初の変革はシステムではなくチームの能力である。アーキテクチャの変革を試みる前に、ツーリング、トレーニング、組織的バイインに投資する。

ステップ5: 変革準備度の分類

圧力、剛性、容量の評価を準備度分類に統合する。

準備度マトリクスにシステムをプロットする:

Transformation Readiness Matrix:
┌─────────────────┬────────────────────────┬────────────────────────┐
│                  │ Low Rigidity           │ High Rigidity          │
├─────────────────┼────────────────────────┼────────────────────────┤
│ High Pressure   │ READY — Transform now  │ PREPARE — Reduce       │
│ + High Capacity │ using adapt-architecture│ rigidity first, then   │
│                 │                        │ use dissolve-form       │
├─────────────────┼────────────────────────┼────────────────────────┤
│ High Pressure   │ INVEST — Build capacity│ CRITICAL — Invest in   │
│ + Low Capacity  │ first, then transform  │ capacity AND reduce    │
│                 │                        │ rigidity before change │
├─────────────────┼────────────────────────┼────────────────────────┤
│ Low Pressure    │ OPTIONAL — Transform   │ DEFER — No urgency,    │
│ + Any Capacity  │ if strategic value is  │ monitor pressure and   │
│                 │ clear, otherwise defer │ reassess quarterly     │
└─────────────────┴────────────────────────┴────────────────────────┘

準備度分類を以下とともに文書化する:
- 分類ラベル（READY / PREPARE / INVEST / CRITICAL / OPTIONAL / DEFER）
- 各評価次元からの主要な発見事項
- 推奨される次のステップ
- 分類を変更する可能性のあるリスク要因
READYの場合:
```
adapt-architecture
```
に進む
PREPAREの場合: 剛性を低減するために
```
dissolve-form
```
に進む
INVESTの場合: 容量を構築し（トレーニング、ツーリング、組織的サポート）、再評価する
CRITICALの場合: 容量と剛性を同時に対処する（外部の支援が必要な場合がある）
OPTIONAL/DEFERの場合: 評価を文書化し、再評価日を設定する

期待結果: 具体的な次のステップを伴う明確で根拠ある変革準備度分類。この分類により、いつどのように変革するかについて情報に基づいた意思決定が可能になる。

失敗時: 分類が曖昧な場合（例: 中程度の圧力、中程度の剛性、中程度の容量）、PREPAREをデフォルトとする — 圧力を監視しながら段階的に剛性を低減する。これにより、最終的に完全な変革が必要かどうかにかかわらず、能力を構築しリスクを低減できる。

バリデーション

コンポーネント、年齢、依存関係、タイプを含む構造インベントリが完了している
変革圧力がマッピングされている（外部、内部、抵抗力）
全次元にわたって剛性スコアが計算されている
変化容量が評価されている（リソース、吸収率、経験）
根拠ある推論を伴う準備度分類が決定されている
分類に基づく次のステップが文書化されている
再評価日が設定されている（現在READYの場合でも）

よくある落とし穴

技術システムのみの評価: 変革準備度には組織的準備度が含まれる。技術的に柔軟だが組織的に剛性の高いチームのシステムは、やはり変革に失敗する
楽観的な容量見積もり: チームは通常の運用を維持しながらの変化容量を常に過大評価する。表明された容量の50%を現実的な見積もりとして使用する
抵抗力の無視: 変化の力のみをカタログ化する圧力マッピングは、変革を遅らせたり止めたりする抵抗を見落とす。抵抗は見かけよりも強いことが多い
評価の麻痺: 形態評価は数時間から数日で完了すべきであり、数週間ではない。時間がかかりすぎている場合、システムは完全に評価するには複雑すぎる — より高い抽象レベルで評価し、問題領域を掘り下げる
剛性と安定性の混同: 剛性の高いシステムは安定したシステムと同じではない。安定性は適切に設計された柔軟性から生まれる; 剛性は設計された柔軟性の欠如である