ASPICE レベル2とは何か
ASPICEはプロセス成熟度を6段階(CL0〜CL5)で区分します。その中でCL1からCL2への移行が実務において最も大きな飛躍です。ASPICE能力レベルの詳細説明で全体の体系をご確認いただけます。
CL1(実行)は「やるべきことをやる」というレベルです。成果物は出ますが、なぜそうしたのか、次回も同じ品質が保証されるのかは分かりません。
CL2(管理)は「計画し、モニタリングし、調整する」というレベルです。プロセスが体系的に計画され、進捗状況が追跡され、成果物が定義された基準に従って管理されます。要求事項からコード、テストまでのトレーサビリティ(Traceability)を確保することが核心です。
現在、グローバルの主要OEMはSOW(Statement of Work)やRFI(Request for Information)でサプライヤーにASPICE CL2以上を要求することが標準となっています。安全関連ソフトウェアにはCL3を要求するケースも増加しています。
評価対象の主要プロセス領域
ASPICE評価で扱うプロセス領域は大きく4つのグループに分かれます。
SYS(システムエンジニアリング)
- システム要求事項分析:顧客/ステークホルダー要求事項からシステム要求事項を導出
- システムアーキテクチャ設計:システム構造とインターフェースの定義
- システム統合:サブシステムを統合し検証
- システム検証:システムが要求事項を充足しているか最終確認
SWE(ソフトウェアエンジニアリング) — V-Modelの核心
- SWE.1: ソフトウェア要求事項分析
- SWE.2: ソフトウェアアーキテクチャ設計
- SWE.3: ソフトウェア詳細設計および実装
- SWE.4: ソフトウェアユニット検証
- SWE.5: ソフトウェア統合および統合テスト
- SWE.6: ソフトウェア適格性テスト
SUP(支援プロセス)
- 品質保証:成果物とプロセスの品質確認
- 構成管理:コード、文書、ビルドのバージョン管理
- 問題解決:イシューの追跡と解決
- 変更管理:変更要求の体系的な処理
MAN(管理プロセス)
- プロジェクト管理:日程、リソース、リスク管理
- リスク管理:プロジェクトリスクの識別と緩和
ASPICE 4.0では、ハードウェアエンジニアリング(HWE.1〜HWE.4)とマシンラーニングエンジニアリング(MLE.1〜MLE.4)プロセスが追加されました。
12ヶ月達成ロードマップ
ASPICE CL2達成のための現実的な12ヶ月ロードマップです。
1〜2ヶ月目:教育と意識改革
全チームメンバーを対象にASPICE教育を実施します。ASPICEとは何か、なぜ必要なのか、CL2が求めるものは何かを全員が理解する必要があります。同時に経営層の支援を確保します。ASPICE対応は組織レベルの投資であるため、リーダーシップなしでは進められません。
2〜3ヶ月目:ギャップ分析
現在の開発プロセスをASPICE要求事項と比較し、ギャップを特定します。どのプロセスが既に実施されており、どの部分が不足しているかを定量的に把握します。この結果に基づいて改善計画を策定します。
3〜5ヶ月目:プロセス定義
プロセス記述書、テンプレート、チェックリストを開発します。各プロセス領域ごとに何をすべきか、どのような成果物が必要かを明確に定義します。これまで暗黙的に実施していた活動を文書化することが核心です。
4〜6ヶ月目:ツール選定と構築
ALM(Application Lifecycle Management)ツール、構成管理ツール、トレーサビリティマトリクス管理ツールを選定し設定します。ツールはプロセスを支援する手段であり、目的ではありません。組織規模に合った適切なレベルを選択します。
5〜8ヶ月目:パイロットプロジェクト
1つのプロジェクトを選定し、定義されたプロセスを全面適用します。実際に適用しながらプロセスの実効性を検証し、発見された問題点を修正します。この段階が最も重要です。
8〜10ヶ月目:内部監査
事前評価(Pre-assessment)を実施し、公式評価への準備状態を確認します。不適合事項を特定し改善します。可能であれば外部コンサルタントによる事前レビューを受けることが効果的です。
10〜11ヶ月目:全社展開
パイロットで検証されたプロセスを他のプロジェクトに拡大適用します。
11〜12ヶ月目:外部評価
intacs認定のASPICE評価者による公式評価を受けます。
上記のスケジュールは新規プロジェクトに適用する場合です。既存プロジェクトのリバースエンジニアリングが必要な場合は18〜24ヶ月が現実的なタイムラインです。
成功の3つの核心要素
ASPICE CL2達成に成功した組織の共通点は、3つの要素のバランスです。
プロセス(Process): トレーサブルで一貫した開発システム。要求事項からテストまで、誰が何をなぜ行ったか追跡できる必要があります。しかし、過度なプロセスはかえって生産性を低下させます。
人材(People): プロセスの価値を理解し、自発的に参加する文化。「評価のための形式的な文書作成」ではなく、「より良いソフトウェアを作るための方法」として受け入れる必要があります。
ツール(Tools): プロセスを効率的に支援する自動化システム。トレーサビリティマトリクス、構成管理、テスト自動化はツールなしでは実質的に不可能です。
これら3つの要素はバランスが核心です。ツールがいくら優れていても人が使わなければ無用の長物であり、プロセスがいくら精緻でもそれを支えるツールがなければ非効率的です。
よくある失敗と注意事項
ASPICE CL2の準備において、多くの組織が繰り返す失敗があります。
過度な文書化: CL2は「適切な」文書を求めるのであり、「大量の」文書を求めるのではありません。形式的に分厚い文書を量産するよりも、実質的に価値のある成果物に集中すべきです。
経営層の支援不足: 現場エンジニアだけが忙しく、経営層が関心を持っていない状況が最も危険です。ASPICEは組織レベルの変革であるため、初期に経営層のバイイン(buy-in)を必ず確保する必要があります。
ツールの過剰導入: あまりにも多くのツールを導入するとかえって混乱が増します。組織規模とプロジェクトの複雑さに合ったツールを選択することが重要です。
短期成果への執着: 「評価さえ通ればよい」というアプローチは長期的に失敗します。形式的な準備でCL2を取得しても、次のプロジェクトで同じレベルを維持できません。実質的なプロセス改善に集中すべきです。
トレーサビリティ管理の不備: 要求事項→設計→コード→テスト間のトレーサビリティはCL2の最も重要な核心です。これができなければ他がどれほど良くてもCL2の取得は困難です。テストケース自動生成を活用すれば、検証段階のトレーサビリティ確保を大幅に効率化できます。
評価(Assessment)プロセス
ASPICE公式評価は以下の手順で進行されます。
評価準備: 評価範囲(どのプロセス領域、どのプロジェクト)を定義し、intacs認定評価者を選定します。必要な文書と成果物を整理します。
評価実施: 評価者がプロジェクトチームメンバーにインタビューし、文書をレビューし、実際のプロセスがどのように実施されているかを観察します。通常3〜5日を要します。
評価採点: 各プロセス領域ごとに能力レベル(CL0〜CL5)が付与されます。各BP(Base Practice)の達成度がN(未達成)、P(部分達成)、L(大部分達成)、F(完全達成)で評価されます。
評価者資格: 公式ASPICE評価は必ずintacs(International Assessor Certification Scheme)認定を受けた評価者のみが実施できます。内部の事前評価は資格制限なく実施可能です。
評価後: 不適合事項が発見された場合、改善計画を策定し、改善の進捗を追跡します。再評価の日程を協議します。
PopcornSARとともにASPICE CL2を達成する
ASPICE CL2の核心であるトレーサビリティ確保と検証の効率化をPopcornSARのPARVISが支援します。
- PARVIS-Spec: 要求事項分析を自動化し、システム-ソフトウェア要求事項間の双方向トレーサビリティを確保します。SWE.1プロセスの主要成果物を効率的に生成します。
- PARVIS-Coder: MISRA Cなどのコーディング規則を自動的に適用し、SWE.3(詳細設計および実装)のコーディング標準遵守を保証します。
- PARVIS-Verify: AIベースのテストケース自動生成により、SWE.4〜SWE.6検証段階の工数を3〜4倍削減します。要求事項-テスト間のトレーサビリティも自動的に確保されます。
また、ASPICEコンサルティングサービスを通じて、ギャップ分析、プロセス定義、事前評価、外部評価準備まで全工程を支援します。
PARVIS製品ページで詳細をご確認いただくか、お問い合わせからご相談をお寄せください。
よくある質問
ASPICE レベル2の達成にはどのくらいかかりますか?+
ASPICE認証は必須ですか?+
CL1とCL2の最大の違いは何ですか?+
少人数チーム(5〜10名)でもASPICE CL2を達成できますか?+
関連記事
ASPICE 4.0 vs 3.1 — 何が変わり、どう移行するか
ASPICE 3.1から4.0への主要変更点、構造的な違い、マイグレーションロードマップを実務の観点から比較分析します。
2026-02-22自動車ソフトウェアのCI/CD — Web開発とは異なる課題
自動車ソフトウェア開発にCI/CDを適用する際の実践的な課題と解決策を解説します。安全認証、ツールチェーン管理、ASPICE 4.0対応まで。
2026-03-09ASPICE vs ISO 26262 — 何が違い、両方必要か?
ASPICEとISO 26262の違いを一目で比較。適用範囲、目的、成果物の違いと実務での同時対応戦略。
2026-02-26