Automotive SPICE：問題の本質を解くシリーズ ～レビュー編～
そのレビュー、本当に品質を上げていますか？
1. はじめに
Automotive SPICEのアセスメントを実施していると、レビューに関するさまざまな状況を目にします。
もちろんレビュー計画は存在します、レビュー記録も残されています、会議の開催履歴もあります。
一見すると、レビューは適切に実施されているように見えます。
しかし、その活動が本当に品質向上に貢献しているかというと、疑問を感じるケースが少なくありません。
例えば次のような状況です。
・100ページ以上ある設計書のレビュー時間が15分
・レビュー参加者が作成者と承認者の2名のみ
・指摘件数がゼロ、あるいは1件程度
・指摘内容が誤字脱字や表記ゆれのみ
・レビュー会議で初めて成果物を開いている
・レビュー結果は毎回「問題なし」
皆さんのプロジェクトではいかがでしょうか。
もし、このようなレビューが日常的に行われているのであれば、一度立ち止まって考えてみる必要があります。
果たして、そのレビューは本当に品質を確認できているのでしょうか。
レビューとは、本来、成果物に潜む問題を早期に発見し、後工程への流出を防ぐための重要な品質保証活動です。
にもかかわらず、レビューが単なる「実施記録を残すためのイベント」になってしまうと、品質向上効果はほとんど期待できません。
今回は、Automotive SPICE対応でよく見られるレビューの形骸化について考えてみたいと思います。
2. よくある形骸化したレビュー
アセスメントの現場では、レビュー活動に関して次のような状況を見かけます。
レビュー時間が極端に短い
レビュー対象が数十ページから百ページを超えるにもかかわらず、レビュー時間が15分から30分程度しか確保されていないケースがあります。
もちろん成果物の内容や成熟度によって必要な時間は異なります。
しかし、内容を理解し品質を確認し議論するためには一定の時間が必要です。
短時間で終了するレビューが必ずしも悪いわけではありません。
問題なのは、「短時間で終わることが目的になっている」ケースです。
実際には十分な確認が行われていないにもかかわらず、「レビュー完了」という結果だけが残されてしまいます。
レビュアーが少ない
レビュー参加者が作成者と承認者の2名のみというケースも少なくありません。
もちろん成果物の内容によっては少人数レビューが適切な場合もあります。
しかし、以下のような多面的な視点が必要な成果物に対して、参加者が少なすぎる場合は注意が必要です。
・要求を理解している人
・設計を理解している人
・テスト観点を持つ人
・安全要求を理解している人
レビューの価値は、作成者自身では気付けない問題を発見することにあります。
同じ視点しか存在しないレビューでは、検出できる問題にも限界があります。
指摘件数が極端に少ない
レビュー件数が少ないことを品質が高い証拠と考える組織があります。
しかし、これは必ずしも正しくありません。
むしろ、以下のような理由で問題が見つかっていない可能性があります。
・レビュー観点が曖昧
・事前準備が行われていない
・発言しにくい雰囲気がある
特にレビューで発言することが否定的に受け止められる組織では、問題があっても指摘されないことがあります。
ゼロ件という結果だけを見て安心するのではなく、「本当に確認した結果なのか」を考える必要があります。
指摘内容が品質につながっていない
レビュー記録を見ると、以下のような指摘ばかりが記載されていることがあります。
・フォントサイズ
・体裁
・誤字脱字
・表記ゆれ
もちろんこれらも必要です。
しかし、本来レビューで重点的に確認すべきものは別にあります。
例えば、以下のようなことなどです。
・要求との整合性
・設計妥当性
・例外処理
・異常系動作
・安全要求への対応
・テスト可能性
レビューが体裁確認だけで終わっているならば、本質的な品質問題は見逃されているかもしれません。
3. なぜレビューは形骸化するのか
では、なぜこのような状況が発生するのでしょうか。
最も大きな理由は、「レビューを行う目的」が変わってしまうことです。
本来の目的は、「成果物の品質向上」です。
しかしプロジェクトが忙しくなるにつれて、以下のような意識が強くなります。
・レビュー記録を残さなければならない
・監査で指摘されたくない
・Automotive SPICE対応でエビデンスが必要
・スケジュールに遅れたくない
すると次第に、「品質を確認する」よりも、「レビューを実施したことにする」ことが重要になります。
この瞬間からレビューは形骸化を始めます。
さらに悪いことに、レビューの効果は見えにくいという特徴があります。
例えばレビューの場で、以下のようなことが指摘された場合、これらは「レビューで発見された問題」として記録に残ります。
・要求の解釈ミス
・設計漏れ
・インターフェースの不整合
・異常系の考慮不足
一方で、本当に大きな価値を持つのは、それらの問題が製品やシステムに組み込まれる前に取り除かれることです。
例えば、設計レビューで通信異常時の処理漏れが発見され修正されたとします。
もしその問題が見逃されていたら、以下のようなことがおきるかもしれません。
・ソースコードにも誤った内容が実装される
・テストで不具合として検出される
・修正のために設計まで戻る
・スケジュール遅延が発生する
さらに最悪の場合、市場出荷後に障害として発生する可能性もあります。
しかし、その問題はレビュー段階で修正されたため、実際の不具合にはなりませんでした。
つまり、「レビューで指摘された内容は見える」が、「レビューによって将来発生するはずだった不具合を防いだ効果は見えない」のです。
レビューの価値は、指摘件数だけでは測れません。
「もしレビューをしていなかったら発生していたかもしれない問題を、どれだけ未然に防げたか」にあります。
ところが、この効果は数字として表れにくいため、「レビューに時間をかけても成果がよく分からない」という考えが生まれやすくなります。
結果として、以下のような方向へ進んでしまいます。
・レビュー時間を削る
・参加人数を減らす
・事前準備を省略する
・指摘分析を行わない
短期的には効率化したように見えますが、実際には後工程でより大きな手戻りを発生させるリスクを高めているだけなのです。
4. 本来レビューで達成すべきこと
レビューの目的は、成果物の品質を評価し、そこに含まれる問題やリスクをできるだけ早い段階で発見することです。
成果物が後工程へ進んでから問題が発覚すると、大きな手戻りが発生します。
例えば要求仕様の誤りや設計上の考慮漏れは、設計レビューの段階で発見できれば数時間から数日の修正で済むかもしれません。しかし実装後や結合テストで発覚した場合には、設計の見直し、プログラム修正、テストのやり直しなど、多くの工数が必要になります。
さらに市場出荷後に発覚すれば、顧客対応や信頼低下など、開発工数だけでは測れない影響を及ぼすこともあります。
レビューは、このような後工程での手戻りや品質問題を未然に防ぐための重要な品質保証活動です。
またレビューには、単に問題を探すだけでなく、以下のような役割もあります。
・成果物の内容が妥当であることを確認する
・関係者間で認識を合わせる
・次工程へ進めてよい状態であることを判断する
したがって重要なのは、「レビューを実施したかどうか」ではありません。
重要なのは、「レビューによって成果物の品質をどの程度高められたか」、「レビューによって品質リスクをどれだけ低減できたか」です。
レビュー記録が残っていても、品質向上につながっていなければ、そのレビューは本来の目的を達成しているとは言えません。
レビューは会議ではありません。
品質を確認し、品質を高めるための活動です。
では、そのレビューを品質向上活動として機能させるためには、何が必要なのでしょうか。
5. レビューを品質向上活動として機能させるために
レビューの形骸化を防ぐためには、「レビューを実施した」という事実だけではなく、品質向上につながる仕組みとして運用することが重要です。
レビューは単発のイベントではありません。
レビューを計画し、実施し、その結果を分析し、次の改善につなげていくことで初めて品質保証活動として機能します。
ここでは、レビューを価値のある活動にするためのポイントを紹介します。
レビューはプロジェクト開始時に計画する
レビューは成果物が完成してから慌てて開催するものではありません。
本来はプロジェクト計画の段階で、品質確保のための活動として組み込んでおくべきものです。
例えば以下のような内容をあらかじめ決めておきます。
・どの成果物をレビュー対象とするか
・いつレビューを実施するか
・誰が参加するか
・どの観点を確認するか
・どの状態になればレビュー完了とするか
これらが明確になっていないと、開発が忙しくなった際に真っ先にレビュー時間が削られてしまいます。
また、「設計書ができたので明日レビューしましょう」といった場当たり的な進め方では、十分な準備ができず、効果的なレビューは期待できません。
レビューは品質確保活動であり、スケジュールの余り時間で実施するイベントではないのです。
レビュー会議は議論の場であり、閲覧の場ではない
レビューが形骸化する組織では、「レビュー会議で初めて成果物を開く」という光景をよく見かけます。
このような状態では、会議時間の大半が資料の読み合わせになってしまい、本当に議論すべき内容に時間を使うことができません。
効果的なレビューでは、以下のような流れになります。
・レビュアーが事前に成果物を確認する
・気になった点を整理する
・レビュー会議で認識合わせや議論を行う
つまりレビュー会議は、「成果物を読む場」ではなく、「問題点について議論する場」であるべきです。
事前レビューが十分に実施されるだけでも、レビューの質は大きく向上します。
品質保証グループがレビュー品質を監視する
レビュー品質を維持するためには、品質保証グループの関与も重要です。
プロジェクト任せにしてしまうと、納期や工数の制約からレビュー活動が後回しになりやすくなります。
品質保証グループは、レビューそのものを実施するというより、「レビューが適切に運用されているかを監視する立場」として機能します。
例えば、以下のようなことを定期的に確認します。
・レビュー計画が作成されているか
・必須成果物がレビュー対象になっているか
・規定された参加者が参加しているか
・レビュー記録が残されているか
・指摘事項が適切に是正されているか
また、レビューを実施したという事実だけでなく、その内容にも目を向ける必要があります。
例えば、以下のような状況が続いているのであれば、レビューが本来の目的を果たしていない可能性があります。
・毎回15分で終了している
・指摘件数が極端に少ない
・誤字脱字しか指摘されていない
品質保証グループは、そのような兆候を早期に発見し、改善を促す役割を担います。
レビュー結果は組織改善の重要な情報源である
レビューは実施して終わりではありません。
むしろ本当に重要なのは、レビューで発見された問題から組織の弱点を読み取ることです。
例えばレビュー指摘を分析すると、以下のような傾向が見えてくることがあります。
・要求仕様の理解不足
・設計ルールの不徹底
・トレーサビリティ不足
・異常系検討不足
・安全要求の理解不足
もし同じような指摘が繰り返し発生しているのであれば、それは個人のミスではなく、組織的な課題かもしれません。
レビューデータを蓄積し、以下の分析することで、教育やプロセス改善につなげることができます。
・どの工程で問題が混入したのか
・なぜその問題が発生したのか
・なぜ見逃されたのか
指摘件数よりも指摘内容を見る
レビュー結果を評価する際に、「何件指摘が出たか」だけに注目する組織があります。
しかし件数だけではレビューの良し悪しは判断できません。
10件の誤字脱字を見つけたレビューよりも、
1件の重大な要求漏れを発見したレビューの方が価値が高い場合もあります。
以下のようなことが重要です。
・どのような問題が見つかったか
・品質リスクをどの程度低減できたか
・再発防止につながる知見が得られたか
レビューを品質向上活動として活用するためには、件数ではなく内容に着目する視点が欠かせません。
レビューを改善活動の起点にする
レビューで発見された問題を修正して終わるだけでは、同じ問題が繰り返し発生します。
例えば、以下のような問題があつた場合は、仕組みそのものを改善する必要があります。
・要求記述ルールが曖昧だった
・設計テンプレートが不十分だった
・レビュー観点が不足していた
また、レビューで得られた知見は、以下のようなことに活用できます。
・プロセス改善
・標準類の見直し
・チェックリストの改善
・教育内容の見直し
このような継続的改善が行われることで、レビューは単なる確認作業ではなく、組織の品質向上を支える活動へと発展していきます。
6. まとめ
Automotive SPICEはレビュー記録の存在を求めているわけではありません。
品質を作り込む仕組みが機能していることを求めています。
もし、以下のようなことが当たり前になっているのであれば、一度立ち止まって考えてみてください。
・極端に短いレビュー
・少人数レビュー
・指摘ゼロのレビュー
・体裁確認だけのレビュー
そのレビューは、品質向上活動でしょうか。
それとも、レビューを実施したという証拠を作るための活動になっていないでしょうか。
レビューはプロジェクトの負担ではなく、品質を守るための最も重要な投資の一つなのです。
（佐藤 崇）