自動車関連ソフトウェアにおけるAutomotiveSPICEの適用拡大

自動車関連ソフトウェアにおけるAutomotiveSPICEの適用拡大
2.1　プロセス定義の作成ソフトウェア製作業務の開発プロセス（ENG5～ENG7）について、入力文書/出力文書、作業フロー、作業別の目的、作業概要、作業の実施条件、作業担当とその役割を図1のとおりソフトウェア製作業務の形式で開発プロセスとして定義した。2.2　規程の作成プロセス定義とアセスメントモデルを照らし合わせ、開発プロセス以外でプロジェクトの運営に必要なプロセスの抽出を行った。管理プロセス群からはプロジェクト管理（MAN3）とリスク管理（MAN5）、支援プロセス群からは品質保証（SUP1）、構成管理（SUP8）と問題解決管理（SUP9）、取得プロセス群からはサプライヤー監視（ACQ4）をそれぞれ抽出した。そしてそれぞれのプロセスにおける出力文書の様式を立案し試使用を繰り返して様式を確定した。また、この様式の活用を順守するために必要な規程も併せて表1のとおり、部内の標準プロセスとして制定した。
１．活動の概要
姫路事業所開発部の事業内容は、三菱電機（株）姫路製作所向けを中心とした「故障診断装置」、「試験機・ツール」、「ECU（Electronic Control Unit）S/W開発」である。これらは、開発部の基幹事業のビジネスユニット（課組織）として位置付けられている。近年、電子制御、安全運転システム、ネットワーク化など自動車の高機能化により、それらを実現する車載システムやECUが複雑化し、車載ソフトウェアの開発規模が増大している。一方で開発期間の更なる短縮も求められており、事業を安定的に拡大するには、製品開発の円滑化と製品品質を確保することが極めて重要なものになっている。これらの対応のために、開発部では、2015年度に欧州の自動車メーカーを中心とした業界団体が定めたAutomotive SPICEのアセスメントモデルを導入した。最初にプロセス定義の作成を行い、次にそれに必要な規程を整備してソフトウェア製作の標準プロセスの構築を行った。そして「故障診断装置」のビジネスユニットをモデル部門としてレベル2を取得した。その後、標準プロセスの部内展開を行い、「ECU S/W開発」のビジネスユニットでレベル2を取得した。さらにSEPG（Software EngineeringProcess Group）が主体となり、組織で標準プロセスが実行できるように規程の整備を行い、「故障診断装置」のビジネスユニットでレベル3の認証を取得した。本稿では、AutomotiveSPICEのアセスメントモデルの導入方法とレベル2、レベル3の認証取得に関する活動内容を紹介する。
２．AutomotiveSPICEのアセスメントモデルの導入
アセスメントモデル導入前の開発部では、ソフトウェア製作の開発プロセスのプロセスフローを規程化し、それぞれのプロセスにおける細部の運用は、各ビジネスユニットに一任してソフトウェア製作業務を遂行していた。また、開発プロセスの改善施策の一つとして、本社ソフトウェア生産技術・人材開発部ソフトウェア生産技術課（以下、ソ生技）によるAutomotiveSPICEの簡易アセスメントを受審して、評定結果の弱みに対する対策を行っていた。この対策はビジネスユニットの内部改善活動として実施していたため、部内の標準プロセスの構築に至っていなかった。そのため、アセスメントモデルの導入に際し、現状のソフトウェア製作業務を文書化することから始めた。自動車関連ソフトウェアにおけるAutomotiveSPICEの適用拡大姫路事業所　開発部奥藤 直樹、八木 伸二、黒川 俊樹一般論文［INPUT/OUTPUT］INPUT OUTPUT要求仕様書SW仕様書資料A プログラム仕様書［作業フロー・作業別の目的・作業概要・作業の実施条件・作業担当とその役割］目的ソフトウェア仕様・構造設計のために実施する。実施条件必ず実施する。作業概要個別実施条件担当者・役割INPUT OUTPUT必ず実施する開発担当目的ソフトウェア仕様を詳細化し、プログラム仕様設計を実施する。実施条件必ず実施する。作業概要個別実施条件担当者・役割INPUT OUTPUT必ず実施する開発担当SW仕様書モジュールの分割を行い、処理内容を記載する。要求仕様書資料ASW仕様書プログラム仕様書作業A作業B追加・変更となるソフトウェア仕様を記載する。要求仕様書資料A図１．プロセス定義54自動車関連ソフトウェアにおけるAutomotiveSPICEの適用拡大を行った。（2）標準プロセスの理解度の相互確認公式アセスメントの受審1ヵ月前からは、受審者全員で全規程類の読み合わせを行った。そして標準プロセスの理解度の相互確認と問答形式でインタビューの回答内容のすり合わせを行い、公式アセスメントに備えた。3.3　レベル2の認証取得2016年3月に「故障診断装置」のビジネスユニットで公式アセスメントを受審し、表2のとおり受審した全9プロセスでレベル2を取得した。４．レベル2の部内展開活動次に「ECU S/W開発」のビジネスユニットでレベル2の認証取得を目指した。2017年7月に簡易アセスメントを受審したものの、表3のとおり、レベル2を満足する結果ではなかった。この結果からレベル2の認証取得に向け、「故障診断装置」と「ECU S/W開発」のビジネスユニットで開発プロセスが異なるエンジニアリングプロセス（ENG5、ENG6）の対策が必要である（SUP9は実施管理が「F」であり、対象外とした）と判断し、課題を抽出して対策に取り組んだ。３．レベル2の適用部内への標準プロセスの定着を図りながら、レベル2の適用への体制は、モデル部門の「故障診断装置」のビジネスユニットから、課長、プロジェクトリーダーと開発担当のキーマン5名、品質保証部門からは、品質保証統括者、SEPGとSQA（Software Quality Assurance）を担う専任者を1名配置して、レベル2の認証取得に取り組んだ。3.1　標準プロセス履行の点検モデル部門とSQAが、公式アセスメントの受審までの8ヵ月間、10件の主要工事（2～5百万円のプロジェクト）を対象に標準プロセスの試行と点検を繰り返し実施して標準プロセス適用の浸透を図った。また、公式アセスメントの受審2ヵ月前には、完了したプロジェクトの成果物に対して、品質保証部門がレビューアを担い、公式アセスメントを想定して点検した。3.2　公式アセスメントのインタビュー対策公式アセスメントの受審2ヵ月前には、公式アセスメントの受審者は、AutomotiveSPICEを理解の上、標準プロセスを問題なく遂行できるレベルに到達していた。しかし受審者の半数は初めてインタビューを経験するため、インタビュー時により的確に返答できるように、次の2つの対策を行った。（1）アセスメントモデルと標準プロセスの適合アセスメントモデルのベースプラクティス（BP）に出現する専門的な表現を、標準プロセスの作業名や作業内容に置き換えて解釈できる表現にすることを目的に、ソ生技によるAutomotiveSPICEの講習会を受講した。講習会は受審する全9プロセスを対象に1プロセスあたり約2時間行われた。また、講習会の内容をビデオに収め、受審者は公式アセスメントの直前まで何度もビデオを視聴して、アセスメントモデルと標準プロセスの適合の復習プロセス群規程類様式類共通・プロジェクト資料管理フォルダに関する規程・プロジェクト資料番号規程－エンジニアリングENG5 SW設計・ソフトウェアの設計・製作・試験に関する規程・ソフトウェア製作プロセスガイド・ソフトウェア製作手順書・プログラム仕様書・品質確認シート(開発前・開発)・品質確認シート(評価)・レビュー報告書ENG6 SW構築ENG7 SW統合テスト管理MAN3 プロジェクト管理プロジェクト管理規程・プロジェクト計画書・詳細スケジュールシートMAN5 リスク管理リスク管理規程・リスク管理表支援SUP1 品質保証品質保証活動規程・品質保証活動報告書SUP8 構成管理構成管理規程・構成管理表SUP9 問題解決管理課題・障害管理規程・課題管理表・障害管理表取得ACQ4 サプライヤ監視外注管理規程・見積依頼書・納入品一覧・外注用レビュー報告書・プロジェクト進捗報告書表１．2015年に制定した規則と様式の一覧2016年3月公式アセスメント（L2）の評定結果PA1.1 PA2.1 PA2.2 評定結果ENG5 SW設計F L L レベル2ENG6 SW構築F L L レベル2ENG7 SW統合テストF L L レベル2MAN3 プロジェクト管理F L L レベル2MAN5 リスク管理F F L レベル2ACQ4 サプライヤ監視F F L レベル2SUP1 品質保証F F L レベル2SUP8 構成管理F F L レベル2SUP9 問題解決管理F F L レベル2F︓完全に満足している86% - 100% PA1.1　レベル1L︓大部分満足している51% - 85% PA2.1　実施管理　　PA2.2　成果物管理エンジニアリング管理支援プロセス群2017年7月簡易アセスメント（L2）の評定結果PA1.1 PA2.1 PA2.2 評定結果ENG5 SW設計P P L レベル0ENG6 SW構築P L L レベル0ENG7 SW統合テスト－ － － －MAN3 プロジェクト管理L L F レベル1MAN5 リスク管理L L F レベル1ACQ4 サプライヤ監視F F L レベル2SUP1 品質保証F L L レベル2SUP8 構成管理L L L レベル1SUP9 問題解決管理P F L レベル0F︓完全に満足している86% - 100% PA1.1　レベル1L︓大部分満足している51% - 85% PA2.1　実施管理　　PA2.2　成果物管理P︓部分的に満足している16% - 50%プロセス群エンジニアリング管理支援表２．2016年3月公式アセスメントの評定結果表３．2017年7月簡易アセスメントの評定結果55自動車関連ソフトウェアにおけるAutomotiveSPICEの適用拡大（3）様式とプログラムの管理規程の明確化ソフトウェア仕様書、プログラム仕様書に記載する項目、内容が粗く、ばらついていた。また、プログラムの管理はファイル更新時のファイル名称の付け方に規程化されたものがなく担当者任せになっていた。この対策としてソフトウェア仕様書、プログラム仕様書の様式を定め、記載項目を統一した。また、プログラムの管理は、ファイル名称の付け方を規程化し、管理は図4のように管理ツールを使用して、プログラムの変更・追加ごとにリビジョンを格納するフォルダ（Tags）に内容を追加し、管理しやすくした。4.2　「ECU S/W開発」のレベル2の認証取得2018年11月に「ECU S/W開発」のビジネスユニットで公式アセスメントを受審し、表4のとおり受審した全9プロセスでレベル2を取得した。4.1　課題の抽出と対策の実施簡易アセスメントの結果から、標準プロセスを「ECU S/W開発」のビジネスユニットに適用したことで発生した問題から課題を抽出し、その対策を実施した。対策は、標準プロセスから逸脱しないようにした。（1）ソフトウェア要求の明確化受審部門は三菱電機（株）姫路製作所の様々な部門から業務を請け負っているが、依頼元部門により仕様書の記載内容や粒度が異なり、要求が曖昧で齟齬が発生するケースがあった。この対策としてソフトウェア仕様書に記載する項目を定め、図2のように様式化した。また、このソフトウェア仕様書を依頼元部門からの入力文書として使用し、依頼元部門とレビューを行い要求を明確化することで齟齬をなくした。（2）仕様書とソースコードの双方向トレースの成立「ソフトウェア仕様書⇔プログラム仕様書」、「プログラム仕様書⇔ソースコード」のそれぞれの双方向トレースが取れない状況であったため、仕様変更が発生したとき、影響範囲が特定しにくい構成となっていた。この対策として「ソフトウェア仕様書⇔プログラム仕様書」は、トレーサビリティが管理できるシートで双方向のトレースを取るようにした。「プログラム仕様書⇔ソースコード」は、プログラム仕様書に追加・変更する関数名まで詳細に記載した。また、ソースコードは、図3のとおりトレースできるよう関数の変更経歴欄にプログラム仕様書番号等を記載するようにした。これにより仕様変更が発生した際、双方向のトレースが取れ影響範囲の確認が容易になった。ソースコードプログラム仕様書図３．ソースコードの関数の変更経歴欄図２．ソフトウェア仕様書の様式6/tags/F****_MCR_M**ログメッセージ：★開発工程完了時ログメッセージ：納品物8/tags/F****_MCR_***9/tags/F****_MCRログメッセージ：***-***-*-CR-*ログメッセージ：ベースS/Wログメッセージ：★プロジェクト計画工程完了時3/tags/F*******4/tags/F****_MCR_M001/trunk725ソースコードの管理フォルダtags：リビジョンを格納するフォルダ図４．プログラム管理構成図56自動車関連ソフトウェアにおけるAutomotiveSPICEの適用拡大本規程を運用して、部内間の垣根を越えた最適なプロジェクトメンバー選定が可能になった。（2）プロセス相関に関する規程規程を改定する際に、関連するプロセスの抽出手順を明文化した規程がなかった。そのため、規程を改定した場合に影響があるプロセスを確認する手順と各プロセスの相関関係をプロセス相関に関する規程として新たに制定した。さらにプロセスごとに全プロセスに対する関連性と入力文書/出力文書を記載し、図6のとおりプロセス相関図を作成した。本規程により、SEPGが規程を改定する際に関連するプロセスを漏れなく抽出できるようになった。また、部門標準プロセスに関して、プロジェクトの新規メンバーへの教育や関係者への説明に活用可能となった。５．レベル3の認証取得活動「故障診断装置」と「ECU S/W開発」のビジネスユニットでレベル2の認証取得したことにより、更なるレベルアップに向け、「故障診断装置」のビジネスユニットでレベル3の認証取得を目指した。5.1　課題の抽出と対策の実施レベル3を取得するために、レベル2に対して何が課題であるか不明であったため、ソ生技と共にレベル3の取得に必要な課題を洗い出した。その結果、レベル3としては、標準プロセスを組織で実行できる規程が不足しており、SEPGによる規程の整備が不可欠であることがわかった。レベル3に必要な規程を新たに表5のとおり整備した。また、作成するに当たり、現在の業務内容をベースに規程化することで、実務に大きな変化が生じない方針とした。特に、新規に取り組みから実施した要員計画に関する規程、プロセス相関に関する規程、プロセス改善活動規程の活動内容について次に示す。（1）要員計画に関する規程プロジェクト体制の構築では、開発内容に応じた技術を持ったプロジェクトメンバーを選定している。この手順を明文化した規程がなかったため、プロジェクトメンバーの選定基準と選定するための実施手順を要員計画に関する規程として新たに制定した。さらに開発部の業務に沿って、役割（プロジェクトリーダー、PCアプリケーション開発担当、評価担当、SEPG、SQA）ごとに業務範囲、責任と権限を定義した要員マップを図5のとおり作成した。また、開発部で運用している技術マップを活用し、役割ごとの必要技術とその教育のためのトレーニングの定義を追加した。開発部　開発第○課　20XX年度　ソフトウェア要員マップ役割部門での役割名称標準役割レベル時期レベル時期レベル時期レベル時期レベル時期レベル時期プロジェクトリーダープロジェクト管理者詳細設計者コーダー単体テスト担当者評価担当ソフトウェアテスト担当者ＳＥＰＧ ＳＥＰＧＳＱＡ ＳＱＡPCアプリケーション開発担当／アダプタ開発担当目標 現状レベル目標現状レベル現状レベル目標現状レベル目標 現状レベル目標現状レベル目標氏名A氏名B氏名Ｃ氏名Ｆ氏名Ｄ氏名Ｅレベル内容ＩＴＳＳレベル５ 社内において、プロフェッショナルとして自他共に経験と実績を有すると認められるレベル５～相当レベル４ 社内において、プロフェッショナルとして求められる経験の知識化とその応用（後進育成）ができるレベル４相当レベル３ 要求された作業がすべて独力でできるレベル３相当レベル２ 要求された作業について、その一部を独力でできるレベル２相当レベル１ 要求された作業について、指導を受けて遂行することができるレベル１相当図５．要員マップ2018年11月公式アセスメント（L2）の評定結果PA1.1 PA2.1 PA2.2 評定結果ENG5 SW設計F L L レベル2ENG6 SW構築F L L レベル2ENG7 SW統合テストF L L レベル2MAN3 プロジェクト管理F L F レベル2MAN5 リスク管理F F F レベル2ACQ4 サプライヤ監視F F L レベル2SUP1 品質保証F F F レベル2SUP8 構成管理F L L レベル2SUP9 問題解決管理F F F レベル2F︓完全に満足している86% - 100% PA1.1　レベル1L︓大部分満足している51% - 85% PA2.1　実施管理　　PA2.2　成果物管理支援プロセス群エンジニアリング管理表４．2018年11月公式アセスメントの評定結果プロセス群規程類様式類・要員計画に関する規程・MCJQ-7108-A_YYYY年度要員MAP_開発部開○課・ソフトウェア製作環境管理規程・MCJQ-7108-A_YYYY年度技術MAP_開発部開○課　ソフトウェア製作環境管理シート・工事反省会シート・プロセス相関に関する規程　プロセス相関図・プロセス改善活動規程　プロセス改善管理シート・工事反省会規程共通表５．2018年に制定した規程と様式の一覧1.プロセス名外注管理（ACQ4）2.関係する作業(1)ソフトウェア設計デザインレビュー（DR）(2)プログラム設計DR1.プロセス名課題・障害管理（SUP9）2.関係する作業(1)ソフトウェア設計デザインレビュー（DR）(2)プログラム設計DR1.プロセス名ソフトウェア構築（ENG6）2.関係する作業(1)単体試験設計(2)コーディング(3)単体試験1.プロセス名組合せ試験（ENG7）2.関係する作業(1)組合せ試験設計(2)組合せ試験1.プロセス名ソフトウェア設計・プログラム設計（ENG5）2.成果物ソフトウェア仕様書、プログラム仕様書、品質確認シート（開発前工程）3.規程名ソフトウェアの設計・製作・試験に関する規程（MCJQ-7301）1.プロセス名プロジェクト管理（MAN3）2.関係する作業(1)製品記録の決定(2)開発ドキュメント様式の決定1.プロセス名品質保証活動（SUP1）2.関係する作業(1)プロダクト品質の確認1.作業名ソフトウェア設計デザインレビュー（DR）2.いつ、どこで開発前工程3.何を（I/Fになる資料名）障害管理表4.何を（I/Fになる情報）DR指摘事項1.作業名プログラム設計デザインレビュー（DR）2.いつ、どこで開発前工程3.何を（I/Fになる資料名）障害管理表4.何を（I/Fになる情報）DR指摘事項1.作業名単体試験設計2.いつ、どこで開発前工程3.何を（I/Fになる資料名）①品質確認シート（開発前工程）②プログラム仕様書4.何を（I/Fになる情報）ソフトウェア仕様、プログラム仕様1.作業名コーディング2.いつ、どこで開発工程3.何を（I/Fになる資料名）①品質確認シート（開発前工程）②プログラム仕様書4.何を（I/Fになる情報）1.作業名単体試験2.いつ、どこで開発工程3.何を（I/Fになる資料名）①品質確認シート（開発前工程）②プログラム仕様書4.何を（I/Fになる情報）単体試験仕様1.作業名組合せ試験設計2.いつ、どこで開発前工程3.何を（I/Fになる資料名）①顧客要求仕様書②品質確認シート（開発前工程）4.何を（I/Fになる情報）①顧客要求仕様書顧客要求②品質確認シート（開発前工程）ソフトウェア仕様1.作業名組合せ試験2.いつ、どこで評価工程3.何を（I/Fになる資料名）品質確認シート（評価工程）4.何を（I/Fになる情報）試験項目、試験手順1.作業名プロダクト品質の確認2.いつ、どこで開発前工程の移行審査時に行う品質保証活動3.何を（I/Fになる資料名）①プロジェクト計画書②品質確認シート（開発前工程）4.何を（I/Fになる情報）①プロジェクト計画書開発項目一覧の照査のサイン②品質確認シート（開発前工程）照査、検認のサイン1.作業名ソフトウェア設計デザインレビュー2.いつ、どこで開発前工程3.何を（I/Fになる資料名）品質確認シート（開発前工程）4.何を（I/Fになる情報）ソフトウェア仕様1.作業名プログラム設計デザインレビュー2.いつ、どこで開発前工程3.何を（I/Fになる資料名）品質確認シート（開発前工程）4.何を（I/Fになる情報）プログラム仕様1.作業名製品記録の決定2.いつ、どこでプロジェクト計画工程3.何を（I/Fになる資料名）プロジェクト計画書4.何を（I/Fになる情報）製品記録の種類1.作業名開発ドキュメント様式の決定2.いつ、どこでプロジェクト計画工程3.何を（I/Fになる資料名）プロジェクト計画書4.何を（I/Fになる情報）開発ドキュメントの様式番号1.プロセス名構成管理（SUP8）2.関係する作業(1)版管理1.作業名版管理2.いつ、どこで開発前工程3.何を（I/Fになる資料名）①プロジェクト計画書の開発項目一覧②品質確認シート③プログラム仕様書4.何を（I/Fになる情報）①プロジェクト計画書の開発項目一覧No.、改訂副番②品質確認シート品質確認シートの資料番号③プログラム仕様書番号図６．プロセス相関図57自動車関連ソフトウェアにおけるAutomotiveSPICEの適用拡大（3）プロセス改善活動規程プロセスの改善要望は、プロジェクトリーダーがSEPGに対して実施している。この手順を明文化した規程がなかったため、プロセス改善の仕組みと実施手順をプロセス改善活動規程として新たに制定した。また、運用中の工事反省会シートのデータを活用することで、新たな作業を増やさずに、プロセス改善に結びつくデータを収集する仕組みとした。さらにその収集データを活用し、プロセス改善を実施するためのプロセス改善管理シートを制定した。本規程を運用することで、SEPGが半期ごとにプロセス改善を実施するPDCAサイクルの実施手順を確立したことは、プロセスをさらに改善する上で大きなメリットである。5.2　「故障診断装置」のレベル3の認証取得2019年3月に、「故障診断装置」のビジネスユニットで公式アセスメントを受審し、表6のとおり受審した全9プロセスでレベル3を取得した。６．今後の展開今後、ソフトウェア品質の維持と向上を目指し、レベル3プロセスを部内に定着させるため、次の取り組みを実施する。（1）プロセス改善活動によるプロセス品質の向上（2）ツール適用によるプロセス運用の効率化（3）プロセスの教育による人材育成７．むすび本活動は、最終目標をレベル3の取得とせず、まず標準プロセスの作成と「故障診断装置」のビジネスユニットでレベル2の取得を目指した。さらに標準プロセスを「ECU S/W開発」のビジネスユニットへ展開して、部内のレベルアップに取り組んだ。そして、「試験機・ツール」のビジネスユニットへ標準プロセスが浸透した段階でレベル3の取得に取り組んだ。振り返れば、これまでの活動は、一歩ずつ成果を積み上げてプロセス改善を進めたことがレベル3の取得に繋がったと言える。また、本活動を通じて標準プロセスが確立できたことで、品質も向上している。最後に、本活動を支援いただいたソ生技を始め、関係者各位に深く感謝申し上げる。2019年3月公式アセスメント（L3）の評定結果PA1.1 PA2.1 PA2.2 PA3.1 PA3.2 評定結果ENG5 SW設計F F F L F レベル3ENG6 SW構築F F F L F レベル3ENG7 SW統合テストF F F L F レベル3MAN3 プロジェクト管理F F F L F レベル3MAN5 リスク管理F F F L F レベル3ACQ4 サプライヤ監視F F F L F レベル3SUP1 品質保証F F F L L レベル3SUP8 構成管理F F F L F レベル3SUP9 問題解決管理F F F L F レベル3F︓完全に満足している86% - 100% PA1.1　レベル1L︓大部分満足している51% - 85% PA2.1　実施管理 　　PA2.2　成果物管理PA3.1　プロセス定義　PA3.2　プロセス展開プロセス群エンジニアリング管理支援表６．2019年3月公式アセスメントの評定結果執筆者紹介奥藤　直樹 オクトウ　ナオキ1990年入社。主にソフトウェア開発を伴うプロジェクトの品質保証活動に従事。現在、姫路事業所開発部。品証統括を兼務。八木　伸二 ヤギ　シンジ1988年入社。主に故障診断装置のソフトウェア開発業務に従事。現在、姫路事業所開発部開発第1課。黒川　俊樹 クロカワ　トシキ1988年入社。主にECUのソフトウェア開発業務に従事。現在、姫路事業所開発部開発第5課。