ソフトウェア開発において、レビューは品質確保においてとても重要なものです。しかしながら、実際の開発現場では疎かになってしまっていることが往々にしてあります。今一度レビューの重要性について理解しましょう。
【広告】
レビューとは
レビューは各工程で作成された成果物が要件を満たしたものであることを確認するための行為です。レビューにより品質状況を把握して、次工程へ進んでよいかを見極めます。
レビューをすることにより、成果物の正しさを組織へ証明し、間違いを修正することができます。また、レビューされる人の育成をする場としても有効です。
なお、成果物の正しさを証明するという事は、作成者が証明しやすいように作る必要があります。それによって、成果物の理解性や保守性が向上し生産性が良くなります。
レビューの観点
レビュー対象物は、文体、仕様、構造の三つの観点からレビューを行います。
文体
書式や形式についてレビューします。ドキュメント規約などに基づいて正しく記述されているかどうかを確認します。
仕様
前工程で定義された要件や機能をレビューします。前工程で定義された外部・内部要件が当工程の成果物に漏れなく、余分なく反映されていることを確認します。
構造
開始・終了処理、正常・異常処理などの対称性や、同様な処理についても同じような構造で記述されているかを確認します。
また、組織独自に過去の事例から、必要な観点があれば追加して確認を行います。
レビューの種類
レビューの種類を効果のある順序で紹介します。
(1)自己レビュー
作成者自身がレビューを行います。本人のスキルアップ、ケアレスミスの修正を目的とします。自己レビューで9割がたのケアレスミスを減らすことができます。
(2)ピアレビュー
プロジェクトチーム内など、同じような立場の人たちでレビューを行います。これにより、思い込みや間違いを修正できます。
(3)対面レビュー
ベテランと若手、上司と部下など、レビューを受ける人とレビューアーが対面してレビューを行います。レビューを受ける側のスキルアップ、別の視点からの指摘を受けることができます。
(4)会議レビュー
関係者を集めて、会議形式のレビューを行います。複数の目で見た多様な観点でのレビューになり、コミュニケーション、教育の場となる。しかし、工数が多くかかったり、参加者のスケジュール調整が難しいという欠点もある。
(5)回覧レビュー
レビュー対象物を回覧してレビューしてもらう。回覧で回ってきた人は、自分の作業より優先度が下なので、ろくに見ないケースが多いので、あまり当てにならない方法で効果は薄い。
レビューの実施
レビューは随時行う方法と、一括で行なう方法があります。
随時レビュー
各工程の途中で随時実施して、問題点の早期発見と手戻りの削減を目的として行います。
一括レビュー
工程の最後に実施し、次工程へ進めるかどうかを見極め、成果物を凍結します。
レビュー結果の記録と品質管理
レビューを実施したら、必ず結果の記録を行います。
レビューの実施時間、指摘事項の内容、件数などを記録してください。こうして記録した内容は、プロジェクトの品質改善のための貴重なデータとなります。
品質管理部門では、プロジェクトの規模とレビュー実施時間、指摘事項件数などから、プロジェクトの健全性を評価することができます。具体的には、プロジェクトの規模とレビュー実施時間に対して、指摘件数が多すぎる、少なすぎるといった所で一次判定を行い、内容を精査するトリガーとする場合があります。
最後に
品質管理をしていて特に目につくのは、不具合の原因を作りこんだ工程が、要件定義や設計段階だという事が多いことです。また、その原因として多いのがレビュー不足です。プロジェクトの上流工程での不具合は大きなインパクトのある不具合を発生させます。
時代の流れとして短納期の開発が求められ、常に時間に追われる開発者の気持ちも分かりますし、また、自分の作成した成果物に自信があるのは大いに結構です。しかし、レビューを疎かにしたことによって後で飛んでもない時間ロスを招いているケースが多く目立ちます。ぜひとも計画段階でレビュー工数をきちんとスケジュールに明記して、レビューをしっかりとするようにしましょう。
こちらの記事も合わせてお読みください。
ヒューマンエラーを防止するためのなぜなぜ分析のについても、合わせてお読みください
以上、「ソフトウェア開発で失敗を繰り返さないためのレビュー技術」でした。
【広告】
