4. プロセス参照モデルおよびプロセス実施指標（レベル 1）
4.2. 供給プロセス群 (SPL)
4.2.1. SPL.1 サプライヤー入札
プロセスID SPL.1
プロセス名 サプライヤー入札
プロセス目的 サプライヤー入札プロセスの目的は、顧客からの引き合いおよび提案依 頼書（RFP）に対応するための窓口を確立し、提案書を準備し、提出 し、関連する契約／合意を確立するまでの業務を確認することである。
プロセス成果 このプロセスを適切に実装した場合の成果は、以下のとおりである。
1) 情報伝達窓口が、顧客からの引き合いおよび提案依頼書に対応するた めに確立され、維持されている。
2) 提案書を提出するか否かを決定するために、提案依頼書が定義された 基準に従って評価されている。
3) 予備調査または実現可能性調査の必要性が決定されている。
4) 適切な要員が、提案作業を実施するために識別されている。
5) サプライヤーからの提案書が、顧客依頼に対応するために準備されて いる。
6) 合意について正式確認が実施されている。
基本プラクティス SPL.1.BP1: 情報伝達窓口の確立 顧客からの引き合いまたは提案依頼書 に対応するために、情報伝達窓口を確立し、維持する。[成果 1]
SPL.1.BP2: 顧客からの引き合いの審査 契約が妥当であることを確認す
るために、リーダーとなる適切な要員を迅速に識別して、顧客からの引 き合いを審査する。[成果 1]
SPL.1.BP3: 顧客への提案に対する評価基準の確立 提案書を提出するか
否かを適切な基準に従って決定するために、評価基準を確立する。[成果 2]
SPL.1.BP4: 顧客の提案依頼書の評価 提案依頼書を適切な基準に従って
評価する。[成果 2]
SPL.1.BP5: 予備調査の必要性の決定 入手可能な要件に基づいて確定見
積りを作成できるように、予備調査の必要性を決定する。[成果 3]
© VDA Quality Management Center 38
SPL.1.BP6: 要員の識別および指名 業務に対して適切な能力を持つ要員
を識別し、指名する。[成果 4]
SPL.1.BP7: サプライヤー提案回答書の準備 顧客依頼に対応するため
に、サプライヤー提案回答書を準備する。[成果 5]
SPL.1.BP8: 合意確認の確立 顧客およびサプライヤーの利害を守るため
に、正式に合意を確認する。[成果 6]
備考 1: コミットメントは書面で合意し、証拠にすべきである。権限のある署 名者のみが契約に対してコミットできるようにすべきである。
アウトプット 作業成果物
02-01 コミットメント／合意文書 → [成果6]
08-12 プロジェクト計画書 → [成果4]
12-04 サプライヤー提案回答書 → [成果5]
13-04 情報伝達記録 → [成果1,6]
13-15 提案レビュー記録 → [成果3,4]
13-19 レビュー記録 → [成果2]
4.2.2. SPL.2 製品リリース
プロセスID SPL.2
プロセス名 製品リリース
プロセス目的 製品リリースプロセスの目的は、対象顧客への製品のリリースを制御す ることである。
プロセス成果 このプロセスを適切に実装した場合の成果は、以下のとおりである。
1) 製品リリースの内容が決定されている。
2) リリース製品が構成された品目から組み立てられている。
3) リリース文書が定義され、生成されている。
4) リリースの納入の仕組みおよび媒体が決定されている。
5) リリースが定義された基準に基づいて承認されている。
6) 対象顧客へ製品リリースが可能である。
7) リリースの確認（書）が得られている。
基本プラクティス SPL.2.BP1: リリースの機能的な内容の定義 各リリースに含むべき機能 を識別したリリース計画を確立する。[成果 1, 3]
備考 1: この計画は、識別した機能に影響を与える各アプリケーションパラ メーターが、どのリリースで有効となるかを示すべきである。
SPL.2.BP2: リリース成果物の定義 リリース対象成果物を定義する。[成
果 1]
備考 2: リリース対象成果物には、プログラミングツールを含むことがある
（記載がある場合）。自動車業界用語において、「リリース」は、サンプル A、B、C等を指すことがある。
© VDA Quality Management Center 39
SPL.2.BP3: 製品リリースの分類および番号体系の確立 製品リリースの
分類および番号体系を、リリースの用途および期待事項に基づいて確立 する。 [成果 2]
備考3: リリース番号には、以下を含む。
主要リリース番号
フィーチャーリリース番号
不具合修正番号
アルファまたはベータリリース
アルファまたはベータリリースとしての反復回数
SPL.2.BP4: ビルド作業およびビルド環境の定義 一貫性のあるビルドプ
ロセスを確立し、維持する。[成果 2]
備考 4: すべての関係者は、指定した一貫性のあるビルド環境を使用すべきで ある。
SPL.2.BP5: 構成された品目からのリリース製品のビルド リリースは、
完整性を確保するために構成された品目からビルドを実施する。[成果 2]
備考 5: 該当する場合、リリース前にソフトウェアリリースを正しいハード ウェアリビジョン上にプログラムすべきである。
SPL2.BP6: リリース製品に対するサポートの種類、サービスレベル、お
よび期間の伝達 リリース製品に対するサポートの種類、サービスレベ ル、および期間を識別し、伝達する。[成果 3]
SPL.2.BP7: リリース用の納入媒体の種類の決定 製品の納入媒体の種類
を、顧客ニーズに従って決定する。[成果 4]
備考 6: 納入媒体の種類には、中間媒体（適切な媒体に格納して顧客へ納入す る）、直接媒体（パッケージの一部としてファームウェアで納入する等）、
または両方の混在がある。リリース製品は、サーバー上に置いて電子的に納 入することもある。また、リリース製品は納入前に複製の作成が必要な場合 もある。
SPL.2.BP8: リリース媒体に対するパッケージの識別 各種媒体に対する
パッケージを識別する。[成果 4]
備考 7: ある種の媒体に対するパッケージは、物理的または電子的保護を必要 とする（例：特定の暗号化技法）。
SPL.2.BP9: 製品リリース文書／リリースノートの定義および生成 リ
リースを支援するためのすべての文書が生成され、レビューされ、承認 され、利用可能であることを確実にする。[成果 3]
SPL.2.BP10: 納入前に製品リリース承認の確保 製品リリースに対する基
準をリリース前に満足させる。[成果 5]
SPL.2.BP11: 一貫性の確保 ソフトウェアリリース番号、紙ラベル、およ
びEPROMラベル（該当する場合）との間の一貫性を確保する。[成果 5]
SPL.2.BP12: リリースノートの提供リリースの主要な特性を詳細化した
情報によって、リリースを裏付ける。[成果 6]
© VDA Quality Management Center 40
備考 8: リリースノートには、序文、環境要件、インストール手順、製品起 動、新規フィーチャーの識別、ならびに不具合解決、既知の不具合、および 回避策の一覧を含む。
SPL.2.BP13: 対象顧客へのリリース製品の納入 受領確認を以って、製品
を対象顧客へ納入する。[成果 6, 7]
備考 9: 受領確認は、手渡し、電子的手段、郵送、電話、または配送サービス 業者を通じて行う。
備考10: 一般的に、SUP.8 構成管理プロセスが、これらのプラクティスを支援
する。
アウトプット 作業成果物
08-16 リリース計画書 → [成果1,3]
11-03製品リリース情報 → [成果1,3,4,6]
11-04 製品リリースパッケージ → [成果2,3,6]
11-07 暫定的解決策 → [成果6]
13-06 納入記録 → [成果6,7]
13-13 製品リリース承認記録 → [成果5]
15-03 構成ステータス報告書 → [成果2]
18-06 製品リリース基準 → [成果5,7]