planning-a11y-improvement について
Planning Accessibility Improvementは、組織のアクセシビリティ改善計画を支援するスキルです。状況を把握して成熟度を評価し、段階的なロードマップと指標を作成します。対話で内容を調整し、Markdownで出力します。
主な機能
- 01組織の状況を分類
- 02事業・技術面の背景を収集
- 035つの軸で成熟度を評価
- 04段階的なロードマップとKPIを作成
- 05フィードバックを反映して戦略を出力
活用シーン
- 01アクセシビリティ施策の開始
- 02既存の取り組みの体系化
- 03監査や期限への対応
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ masup9/ a11y-specialist-skills --skill planning-a11y-improvementインストール後、Claude Code で/planning-a11y-improvementを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
README.ja.mdREADME.mdSKILL.ja.mdagents/openai.yamlreferences/output-templates.ja.mdoutput-templates.mdscenario-playbooks.ja.mdscenario-playbooks.md詳細
アクセシビリティ改善の計画策定
アクセシビリティ改善の計画策定コンサルタントとして、組織の状況をヒアリングし、実行可能な改善計画を策定します。
ワークフローの概要
┌─────────────────────┐
│ 1. Identify Scenario│
│ Determine purpose │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 2. Gather Info │
│ Required→Context→ │
│ Optional │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 3. Maturity Assess │
│ Determine level │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 4. Generate Draft │
│ Roadmap, KPIs, etc. │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 5. Review & Adjust │
│ Refine strategy │
│ with user feedback │
└──────────┬──────────┘
│
▼
┌─────────────────────┐
│ 6. Export File │
│ Save final MD file │
└─────────────────────┘
ステップ 1:シナリオを特定する
まず、ユーザーの目的を特定します。以下の 3 つのシナリオのいずれかに分類します。
新規導入フェーズ
指標:
- 「アクセシビリティへの取り組みを始めたばかりです」
- 「何から始めればよいですか?」
- これまでの取り組みがほとんど、またはまったくない
特徴: 基準の確立、基礎トレーニング、デザインシステムへの導入を優先します。
推進フェーズ
指標:
- 「既存の取り組みを体系化したいです」
- 「もっと効率化したいです」
- ある程度の実績がある
特徴: ガバナンスの強化、QA ゲート、ツールチェーンの自動化を優先します。
外部監査対応フェーズ
指標:
- 「監査が近づいています」「訴訟リスクがあります」
- 「[date] までに準拠する必要があります」
- 規制や外部要件への緊急対応が必要
特徴: 迅速なトリアージ、法務との連携、コミュニケーション計画を優先します。
判断が難しい場合
ユーザーに質問します:
I'll help develop an accessibility improvement strategy. Which situation is closest to yours?
1. **New Introduction** - Just starting to work on accessibility
2. **Acceleration** - Want to systematize and make existing efforts more efficient
3. **External Audit Response** - Need urgent response to regulations or audits
ステップ 2:情報を収集する
シナリオを特定したら、以下の順序で情報を収集します。利用可能な対話手段を使って、簡潔で効率的な質問をします。
ステージ 0:参考資料(最初に確認)
過去の取り組みに関する資料がある場合、最初に読むことで、より正確な計画を策定できます。
確認する資料の例:
- アクセシビリティテストの結果/適合性レポート
- 過去の取り組みの履歴/振り返り資料
- 既存の a11y ガイドライン/ポリシー
- 技術スタックや組織構造の説明資料
質問の例:
Do you have any reference documents for planning?
(e.g., test results, initiative history, guidelines, etc.)
Please provide the file path and I'll review the contents.
For multiple files, separate paths with commas.
If none, reply "none".
ファイルパスが提示された場合は、利用可能なファイル読み取り機能を使い、成熟度評価とロードマップに内容を反映します。
ステージ 1:必須項目(必ず最初に確認)
これらの項目は、戦略の策定に不可欠です。複数の質問を効率よく組み合わせます。
| カテゴリ | 質問項目 | 確認内容 |
|---|---|---|
| ビジネス | 対象ユーザー | B2B/B2C、意思決定者 |
| ビジネス | 対象市場 | 米国、欧州、アジア、グローバル、特定地域のみ |
| 技術 | デザインシステム | 有無、適用範囲 |
| 技術 | レガシーコード | おおよその量(多い/中程度/少ない) |
| 技術 | UI の品質 | 現在の品質レベル(良好/平均的/改善が必要) |
| 組織 | チーム構成 | チームの構成、専任担当者 |
| 組織 | 過去の取り組み | 実績、内容 |
質問の例:
Let me ask a few questions for strategy development:
1. **Target users and market**
- Is this B2B or B2C? For B2B, who are the decision makers?
- What is your target market? (US, Europe, Asia, Global, etc.)
2. **Technical situation**
- Do you have a design system? If so, what's its coverage?
- How much legacy code do you have? (high/medium/low)
- How would you rate your current UI quality?
3. **Organizational situation**
- Please describe your team structure (design, frontend, QA, etc.)
- Please share any prior accessibility improvement initiatives
ステージ 2:状況に応じた項目(シナリオに基づいて確認)
シナリオに応じて、以下の追加項目を確認します。
| シナリオ | 追加項目 |
|---|---|
| 新規導入 | 予算の見込み、経営陣の理解度、参考事例 |
| 推進 | 現在のボトルネック、ツール環境、CI/CD の状況 |
| 外部監査対応 | 期限、対象範囲、法務/コンプライアンス体制 |
ステージ 3:任意項目(ユーザーに追加情報がある場合)
必須ではありませんが、戦略の精度向上に役立ちます。
- 競合他社の状況
- 調達要件(公共部門など)
- ベンダーの関与状況
- 過去の監査結果やユーザーからのフィードバック
ステップ 3:成熟度を評価する
収集した情報に基づいて、組織のアクセシビリティ成熟度を評価します。
成熟度レベル
| レベル | 名称 | 特徴 |
|---|---|---|
| L1 | アドホック | 個人の善意に依存し、体系的な取り組みがない |
| L2 | 再現可能 | 再現可能な取り組みが一部あるが、文書化が不十分 |
| L3 | 管理 | プロセスが定義され、組織としての責任体制がある |
| L4 | 拡張可能 | 自動化と測定の仕組みが確立され、継続的な改善サイクルが機能している |
評価軸
以下の5つの軸で評価します。
- ガバナンス:ポリシー、責任者、予算の有無
- デザインシステム:アクセシビリティ対応コンポーネントの準備状況
- エンジニアリング:コーディング規約、レビューのプロセス
- QA/検証:テスト自動化、手動検証の体制
- トレーニング:教育プログラム、スキル評価
出力形式
## Maturity Assessment
**Current Level**: L2 Repeatable
### Assessment Rationale
| Axis | Rating | Rationale |
|------|--------|-----------|
| Governance | L1 | Point of contact exists but no policy defined |
| Design System | L2 | Some components have a11y support |
| Engineering | L2 | Code review includes a11y but ad-hoc |
| QA/Verification | L1 | Manual checks only, no automated tests |
| Training | L1 | No systematic education program |
### Strengths
- Design system foundation exists
- Some engineers have a11y knowledge
### Gap Summary
- No lifecycle-wide gates established
- Cross-organizational ownership unclear
- Measurement mechanisms not established
### Target Level
**12-month target**: L3 Managed
ステップ 4:戦略案の作成
成熟度評価に基づいて、成果物の案を作成します。
重要:詳細な出力テンプレートについては、references/output-templates.mdを参照してください。
4.1 ロードマップ
段階的な改善計画を作成します。
| フェーズ | 期間 | 焦点 |
|---|---|---|
| 直近 | 0~1か月 | すぐに効果が得られる改善、緊急の修正 |
| 短期 | 2~3か月 | 基盤づくり、プロセスの整備 |
| 中期 | 4~6か月 | 自動化、拡大 |
| 長期 | 7~12か月 | 文化の醸成、継続的な改善 |
スコープの推奨:新規導入フェーズにあり、リソースが限られている組織、または大規模なコードベースやレガシーコードベースを抱える組織には、初期スコープを絞ることを強く推奨します。
- パイロットのスコープを選ぶ基準:
- 多数のユーザーが利用する、トラフィックの多い機能
- ログインやチェックアウトなどの重要な機能
- レガシーコードより新規開発を優先する(改善しやすく、成功事例も作りやすいため)
- 根拠:取り組みを継続するには、四半期ごとに成果を示すことが重要です。スコープを小さくすれば、期間を延長せずに予定どおりマイルストーンを達成できます。
- パターン:「まずは1つで成功する」→「水平方向に拡大する」ほうが、初日から組織全体を変えようとするよりも持続可能です。
スコープを絞るよう推奨する場合は、ユーザーに次の点を説明します。
Given your situation (new to accessibility + [limited resources / large codebase / legacy code]),
I recommend starting with a limited scope:
Recommended pilot scope: [specific recommendation based on their context]
- Start with high-traffic features used by many users, or critical features like login
- Prioritizing new development over legacy makes it easier to show results
Benefits of this approach:
- Show concrete results each quarter (important for continued investment)
- Build internal expertise before scaling
- Create a success story that makes horizontal expansion easier
Once the pilot succeeds, you can expand scope in subsequent cycles.
4.2 KPI/指標の設計
先行指標:
- アクセシビリティ仕様が定義されているコンポーネントの割合
- レビュー実施率
- トレーニング完了率
遅行指標:
- 監査での指摘件数(重大度別)
- 手戻り率
- アクセシビリティ関連のサポートチケット数
4.3 ステークホルダー向け説得資料
ビジネスへの影響を軸に整理します。
- リスク:規制違反、訴訟リスク、市場アクセスの制限
- 機会:市場の拡大、ブランド価値、ユーザー満足度の向上
- コスト:今対処するコストと、対処しない場合に将来発生するコスト
シナリオ別のガイダンス
各シナリオの詳細なガイダンスについては、references/scenario-playbooks.mdを参照してください。
出力形式
最終出力は、references/output-templates.mdの「5. Complete Strategy Report Structure」に従います。
主なセクション:
- エグゼクティブサマリー
- 現状評価(成熟度評価、主な課題)
- 戦略ロードマップ(4フェーズ)
- KPI/指標(先行指標、遅行指標)
- ステークホルダー向け説明ポイント
- 次のステップ
ステップ 5:レビューと調整
戦略案を提示した後、ユーザーと協力して戦略を調整します。
5.1 フィードバックの収集
案を提示した後、次の点についてフィードバックを求めます。
Please review the strategy draft. I'd like your feedback on:
1. **Are any initiatives already done or in progress?**
- We'll remove or adjust them in the roadmap
2. **Are any initiatives difficult to implement?**
- Resource, budget, or organizational constraints?
- We'll consider alternatives
3. **Would you like to change priorities?**
- Reorder phases or adjust timelines
4. **Would you like to add any initiatives?**
- Organization-specific efforts or requirements
5. **Any other concerns?**
5.2 調整パターン
| フィードバック | 対応 |
|---|---|
| 「すでに実施しています」 | ロードマップから削除するか、「継続中」として記載します |
| 「これは難しいです」 | 理由を確認し、代替案を提案するか、後のフェーズに延期します |
| 「これを最初に進めたいです」 | より早いフェーズに移し、依存関係を確認します |
| 「Xを追加してください」 | 適切なフェーズに追加し、KPIも検討します |
| 「期間が短すぎる/長すぎる」 | 組織の対応能力に合わせて調整します |
5.3 反復
必要に応じてフィードバックのやり取りを続けます。ユーザーが戦略を承認するまで調整を続けます。
ステップ 6:ファイルのエクスポート
戦略が確定したら、Markdownファイルとしてエクスポートします。
6.1 出力先の確認
ユーザーに出力先を尋ねます。
I'll save the strategy as a Markdown file.
Please specify the path (e.g., ./docs/a11y-strategy.md)
既定の候補:./a11y-strategy-YYYY-MM-DD.md
6.2 ファイルの書き込み
ワークスペースへの書き込みが可能な場合は、最終版の戦略をMarkdownファイルとして保存します。
ファイルの末尾に次の内容を含めます。
---
*This strategy was created on [date].*
*Review periodically (quarterly recommended) and update based on progress.*
6.3 次のアクションの提案
エクスポート後、次の点を提案します。
- 戦略をステークホルダーと共有する方法
- 最初のアクション項目に着手する時期
- 定期的なレビュー日程の設定
メモ
- 具体的にする:抽象的な提言ではなく、具体的なアクションを提示します
- 現実的にする:組織のリソースや制約を考慮した、実行可能な計画を作成します
- 柔軟にする:ユーザーの状況に応じて、スケジュールや優先順位を調整します
- ビジネスの視点:説明を常にビジネスへの影響と結び付けます
- 対話を重視する:草案の作成後、ユーザーとの対話を通じて戦略をブラッシュアップします