ポイント:レビューを行う視点、要件確定レビュー、曖昧の排除、デザインレビュー、基本仕様の展開、コードレビュー、ソースコードの検査
ビューをうまく行うために考えるべきポイントは3つあると考えています。 これはレビュー研修の最初に必ず話ことで、一つは「視点」、一つは「技法」、一つは「意識」です。 コラムを三回に分けて、それぞれを考えてみたいと思います。
最初は、レビューを行う「視点」について考えてみます。 「視点」とは、プロジェクトや設計、コードそのものにある「よくある落とし穴」を見つけるポイントのことです。 レビューを行う際に、どんなところに落とし穴があるのかが分かると早期のリスクの発見、対策の合意に至ることができます。
要件確定、設計(デザイン)、コードでのレビューを例に「視点」を考えてみます。
「顧客の要望からイメージされる世界」から、それを「システムを使って実現する世界」へイメージを変換させる作業である要件確定は大変難しい作業です。 いわゆる失敗プロジェクトの原因は要件確定の不十分、認識違いであることが多いと言われています。極力、解釈の余地のある曖昧な定義は排除するように要件確定レビューを行う必要があります。
デザインレビューは、そのソフトウェアに直接関与した設計の内容に対して他の設計者や他の部門の関係者がレビューすることです。 デザインレビューは「外部設計時のレビュー」と「内部設計時のレビュー」があります。
外部設計時のレビューは要件確定で決められた基本仕様が適切に展開されているか、機能が適切な単位で実現されているかが主なレビューのポイントになります。 また「システム利用局面での問題発生時の対応機能は?」や「想定外の条件が他にはないか?」等の「視点」の漏れは複数の知識や経験が役立ち、レビューが有効となる場面です。
プログラムの構造が適切に展開されていること、機能仕様で記載された実現度合いの確認がレビューポイントとなります。 特にエラー処理や障害時対策,およびタイミングに関する処理に考慮の漏れがないか、性能問題を引き起こすような設計になっていないかという点は発見が困難であるため、十分に時間をかけて確認する必要があります。
ソフトウェア開発工程で見過ごされた誤りを検出・修正するためにソースコードの体系的な検査(査読)を行うことです。 ソフトウェア品質を高めると同時に開発スキルの向上を図ることができます。 プログラミング言語にも依存しますが、標準的な「観点」をメモしておきます。
「視点」に関しては、チェックリストに合わせて、まだまだ書きたいレビュー場面があるので切り口を変えながら情報提供したいと思います。
関連コラム
レビュー技法におけるチェックリストの役割 2015年11月01日記述
レビューを行う際の3つのポイント(4)〜意識(後編)〜 2015年06月01日記述
レビューを行う際の3つのポイント(3)〜意識(前編)〜 2015年04月01日記述
レビューを行う際の3つのポイント(2)〜技法〜 2015年03月02日記述
レビューを行う際の3つのポイント(1)〜視点〜 2015年02月02日記述
レビューミーティングでやってはいけない五つのこと(後編) 2014年02月17日記述
レビューミーティングでやってはいけない五つのこと(前編) 2014年02月10日記述
ITプロジェクトでの怖いもの〜担当者の抱え込みと放りっぱなし 2013年09月30日記述
レビュー技法のメリット・問題点(後編) 2013年09月23日記述
レビュー技法のメリット・問題点(前編) 2013年09月17日記述
なぜレビュー技法の種類を知るとよいのか 2012年11月15日記述
レビューが実施されない理由(後編) 2007年10月22日記述
レビューが実施されない理由(前編) 2007年10月08日記述
レビューの基礎知識 2007年10月01日記述
レビューが必要とされる理由 2007年05月14日記述
関連提供サービス
セミナー「システム開発におけるレビュー技法」
2015年02月02日 宿澤直正 記
Copyright (C) 2015 宿澤経営情報事務所