今回は、1月号「Automotive SPICEにおけるプロセスの解釈について (ソフトウェア統合および統合テスト)」に続いて、問題解決管理プロセスにおいてアセスメントで弱みとなりやすい「問題の緊急解決」について取り上げていきます。
問題解決管理プロセスには、「問題解決管理戦略の策定」と「緊急解決策の権限の付与」についての基本プラクティスがあります。緊急解決戦略を含む問題解決管理戦略を定義し、その戦略に基づいて問題を迅速に解決するための権限を取得するという関係になります。問題が発生した場合、通常は決められた一連の活動を行い解決に取り組みますが、迅速な解決が求められる問題が発生することもあるわけです。例えば、あるサンプルリリース後に顧客側の活動に支障をきたす致命的なソフトウェア不具合が見つかり早期に解決して欲しいと求められた場合などです。そのような緊急性の高い問題に直面した時に通常よりも迅速な問題解決を行うために緊急解決の仕組みを予め設けておくべきということになります。
では、皆さんはどのような仕組みを定義しますか。実際のアセスメントにおいて見かけた1つの事例をご紹介いたします。
・問題の緊急解決時のワークフロー
・問題の緊急性の判断基準
・緊急解決時における対策の決定権限の付与先
・権限が付与された担当者により決定した暫定対策内容に従った問題の解決
上記のようなルールや基準があれば適切に対応できるように思えますが、注意すべき事があります。緊急解決は、問題を解決する中で本来行われるべき作業の一部を省略することにより迅速に解決するものです。例えば、暫定対策として設計書は修正せずにソースコードを修正し動作確認をした上で顧客にソフトウェアをリリースするなどに相当します。しかし、ここには1つの落とし穴があります。それは、本来行われるべき設計書の修正が行われていないということです。一部の作業を一時的に省略し品質を下げることによって期日を優先して問題を解決しています。つまり、上記の場合はその下げた品質に対する開発リスクを補完する活動が不足しています。設計書が修正されないまま開発が進めばソースコードとの不整合が発生したままとなり、出所の分からない機能が後に生まれてしまう原因にもなりえます。
そのため、問題の緊急解決には、暫定対策に加えて、暫定対策により一時的に下げた品質を補完するための恒久対策の内容を含めた考慮が必要になります。したがって、上記の例では、恒久対策として設計書を修正する計画を立てておき対策が完了するまで管理することが必要であったと言えます。
今回の記事はプロセスモデルをヒントに仕組み作りを行う場合には、モデルに書かれていることが網羅できていれば良いのではなくその文面の意図を正しく理解した上で定義することが大切だと思いご紹介させていただきました。
また、弊社では、Automotive SPICEに含まれるプロセスを対象に実施担当者およびプロジェクトの管理の視点を中心に必要な活動や作業成果物の観点を習得いただくためのトレーニングを実施しております。アセスメントで見かけた事例なども織り交ぜながらお話をさせて頂いております。詳細につきましてはWeb(https://biz3.co.jp/publictraining_category/automotivespiceengineer)にて案内をさせて頂いておりますので、興味がある方は是非ご受講をご検討頂ければ幸いです。
2023/3/1 山下 祐太朗