ISO 26262のレビュー

はじめに

自動車の機能安全規格ISO 26262には、安全ライフサイクル(safety life cycle)の検証(verification)の一環としてレビュー(review)が存在します。この記事では、そのレビューについて詳しく説明します。
ISO 26262は、自動車の電子・電気システムの安全性に関する国際規格です。この規格は、車両の機能安全を確保するためのプロセスと要求を定義しており、その中での検証は重要な活動となっています。具体的には、検証はシステムやコンポーネントの設計が要件を満たしていることを確認するための活動です。レビューは、その検証プロセスの中で行われる手法の一つです。ISO 26262が特筆すべきは、検証（verification）の中に技術的またはプロジェクト独自要件についてのレビューと規格要求遵守の確認活動を組み込んでいる点です。
ISO 26262におけるレビューは、システムやコンポーネントの設計、ドキュメント、コード、テストケースなど、安全ライフサイクルの各プロセスで作成される成果物の顕在または潜在している問題やリスクを特定し、それらに対処して安全性を向上させることです。品質（一般的な安全も含む）については、ISO 9001のデザインレビューで行われますが、同時に行っても問題ありません。デザインレビュー（DR）という表現は、品質に関するレビューとしてのみ受け取られる恐れがあるため、ISO 26262では、規格が要求する成果物に対するレビューとして「verification review」が使用されています。

以下の説明で用いる用語です。
レビューア：レビューを行う人物またはチーム
レビューィ：レビューされる人物、一般には作業成果物を作成した人物またはチーム

レビューの前に

成果物の作成

レビュー対象となる要件仕様書、設計仕様書、コード（コーディングルール）、テストケース仕様書、安全（ハザード）分析報告書などフォーマットとガイドを定め、それに基づいて成果物を作成することが重要です。
要件、仕様、テストケース、ハザードについてはIDを付与して管理します。IDがないと、レビュー指摘を記載する際にそのドキュメントのページ数や行数で指摘を特定するのに時間がかかってしまいます。また、後に述べるトレーサビリティの確保にもIDは役立ちます。

レビュー計画の立案

検証については、事前に検証計画書を作成しなければなりませんが、レビューについても同じです。誰が（例：成果物の入力を作成した人物、成果物を利用する人物、品質管理を行う人物、安全管理を行う人物、検証、テストを行う人物が適任です）、いつ、何のために（例：品質、安全の担保）、何（例：レビュー範囲と確認対象）を行うのかを明確にします。成果物が未完成のままレビューを行うと、レビューアに再度レビューを依頼することになるため、絶対に避けねばなりません。
入力と条件は何で、どのような手順で成果物を作成したかの情報が必要になります。とりわけ技術レビューを行う際には、その技術に精通している者をレビューアとして選ぶ必要があります。そうしないと、成果物の内容に関する適切な指摘を得ることが難しくなります。ただし、誤字脱字やフォントの違い、図の表題、その他フォーマットに関する指摘は得られるかもしれません。

レビューのながれ

準備

対面でレビュー会を行う場合には遅くとも前日から2、3日前に成果物を配布する必要があります。なぜなら、対面レビューで文書を一つ一つ読み上げて確認すると、膨大な時間がかかるためです。対面でレビューするのではなく、レビューアに事前レビューをお願いするとよいです。

レビュー会

対面レビューでは成果物の作成者とレビューアの双方が参加する確認会を行うことをおすすめします。
レビュー指摘に対しては、誰がいつまでにどのように対応するのかを明確にします。それらのフォローアップはプロジェクトマネージャが行います。指摘事項に対応しない限り、成果物は完成しません。また、安全に関連する問題については、安全管理者（Safety Manager）が取り扱います。レビュー結果については議事録を書きます。

照査、承認

指摘事項が解消されたあと、照査をプロジェクトマネージャに承認をプロジェクト責任者にお願いします（プロジェクトにより照査、承認者は異なります）。このとき、レビュー結果が問題がない根拠を承認者に事前に伝えることが大切です。承認者は何をもって承認してよいのか判断できないためです。

注

レビューは次のプロセスに移行してよいかのゲートになるため、細心の注意を払って行う必要があります。レビューがいい加減であると、何度も手戻りが発生する恐れがあります。

レビューの主要ポイント

要件レビュー：

設計の初期段階から、要件が検討され、要求事項が適切に記述されているかどうかを確認します。要件は主語と述語を明確にし、単文で表現します。これにより、対象（システム）の機能が明確になり、また安全要件も明確にし、設計の入力が整備されます。

デザインレビュー：

システムやコンポーネントのデザインが、安全要件や顧客要求に基づく機能、性能要件を満たしているかを評価します。これにより、設計が実装可能であり、安全要件と機能要求を満たしていることが確認されます。

コードレビュー：

ソフトウェアコンポーネントのコードが、品質基準や安全要件を満たしているかどうかを評価します。コードの品質向上とバグの特定が主な目的です。

テストケースレビュー：

テストケースが適切に設計され、システムの機能、動作、性能、および安全要件を満たすかどうかを確認します。これにより、システムの正確な動作と安全性が確認されます。

ハザード分析レビュー：

システムのハザード分析やリスク評価の結果が適切であるかどうかを確認します。安全要件を洗い出すために非常に重要なステップです。

レビュープロセスは、専門家や関係者が成果物を審査し、議論し、コメントや改善提案を提供することで行われます。これにより、機能、性能、安全性に関連する問題を早期に発見し、品質を向上させることができます。
ISO 26262におけるレビューは、自動車の電子システムの安全性を確保するために不可欠な活動であり、プロセス全体の重要な一部です。
次に、レビュープロセスを効率化し、同時に漏れを防ぐためのいくつかの方法を示します。

レビューの効率化方法

自動化ツールの活用：

レビュープロセスの一部を自動化することで、繰り返しのタスクや標準的なチェックを効率化できます。コード静的解析ツールやテストカバレッジツール、トレーサビリティツールなどを使用して、それぞれコーディング規則、テスト網羅率、要件と設計仕様、テスト仕様の紐づけをもとに抜け漏れがないかを確認できます。

成果物のテンプレートとガイドライン：

レビュー対象成果物のテンプレートやガイドラインを作成し、参照することで、レビューアーが確認すべきポイントを明確に理解できます。これにより、漏れを減少させることができます。

チェックリストの使用：

レビューアーやチームメンバーが使用するためのチェックリストを作成し、それを基にレビューを行うことで、漏れを防ぐことができます。チェックリストには、検証すべき項目や特定の基準が含まれています。

専門家の関与：

専門家をレビュープロセスに参加させることで、その専門知識を活用して問題を早期に発見し、解決する支援ができます。専門家の洞察は品質向上に大きく貢献します。

ピアレビュー：

2人以上のレビューアーを交えて相互にチェックを行うことで、漏れや誤りを減少させることができます。異なる視点からの評価は、問題の洗い出しに役立ちます。

リモートツールの利用：

チームが地理的に離れている場合、オンラインコラボレーションツールを使用してリモートでレビューを行うことができます。コメントや指摘をオンラインで共有し、迅速なフィードバックを得ることができます。

トレーニングと意識向上：

レビューアーや関係者に対して、効果的なレビュー手法やプロセスに関するトレーニングを行うことで、より効率的かつ効果的なレビューが可能になります。

これらの方法を組み合わせることで、レビュープロセスを効率化し、同時に漏れを最小限に抑えることができます。

おわりに

著者の経験では、レビューには予想以上の工数がかかります。１回では終わらないことが多いため、２回、予備で３回目の対面レビューをスケジュールインすることが必要だと思います。ただし、３回も４回もレビューするのは異常であり、成果物の完成度が低いとかレビューアが事前に成果物に目を通していないことにも一因があるため、両者の意識向上が求められます。
著者は、人によるレビューには限界があり、問題をゼロにすることは難しいと考えています。問題とリスクの関係から安全に及ぼす影響をいつも考えてレビューし、リスクを最小限にすることが大切であると思います。
近い将来、生成AIによるレビューも可能になるかもしれません。生成AIはガイドやルールに基づいて分析するのは得意と考えられるからです。