[事務所TOP] [コラム一覧へ]

ポイント:レビューを行う視点、要件確定レビュー、曖昧の排除、デザインレビュー、基本仕様の展開、コードレビュー、ソースコードの検査

レビューを行う際の3つのポイント(1)〜視点〜


レビューを行う際の3つのポイントとは

ビューをうまく行うために考えるべきポイントは3つあると考えています。 これはレビュー研修の最初に必ず話ことで、一つは「視点」、一つは「技法」、一つは「意識」です。 コラムを三回に分けて、それぞれを考えてみたいと思います。

最初は、レビューを行う「視点」について考えてみます。 「視点」とは、プロジェクトや設計、コードそのものにある「よくある落とし穴」を見つけるポイントのことです。 レビューを行う際に、どんなところに落とし穴があるのかが分かると早期のリスクの発見、対策の合意に至ることができます。

要件確定、設計(デザイン)、コードでのレビューを例に「視点」を考えてみます。

要件確定レビューの観点

「顧客の要望からイメージされる世界」から、それを「システムを使って実現する世界」へイメージを変換させる作業である要件確定は大変難しい作業です。 いわゆる失敗プロジェクトの原因は要件確定の不十分、認識違いであることが多いと言われています。極力、解釈の余地のある曖昧な定義は排除するように要件確定レビューを行う必要があります。

  • 対象外、移行不要といった判断の理由が明確であるか?
  • 過剰要件は排除できているか?
  • システム完成後の実現利用機能の整合性の再確認はできているか?
  • 要件そのものより、その要件の背景は認識されているか?
  • その要件により実現すること、断念したことが認識されているか?
  • 未決・ペンディング要件の確認は明確になっているか?
  • 稼働後人間系作業負担内容の確認と承認はできているか?
  • セキュリティ対応内容とレベルは認識されているか?
  • 運用・性能の設計内容は明確になってるか?
  • 障害時のリカバリー設計内容は明確になっているか?
  • デザインレビューの観点

    デザインレビューは、そのソフトウェアに直接関与した設計の内容に対して他の設計者や他の部門の関係者がレビューすることです。 デザインレビューは「外部設計時のレビュー」と「内部設計時のレビュー」があります。

    外部設計時のレビュー

    外部設計時のレビューは要件確定で決められた基本仕様が適切に展開されているか、機能が適切な単位で実現されているかが主なレビューのポイントになります。 また「システム利用局面での問題発生時の対応機能は?」や「想定外の条件が他にはないか?」等の「視点」の漏れは複数の知識や経験が役立ち、レビューが有効となる場面です。

  • 基本仕様が適切に、正確に展開されているか?
  • 機能に過不足がないか?
  • 外部インターフェイスの完全性は確認されているか?
  • 入出力項目の過不足はないか?
  • システム運用上の問題がないか?
  • 異常系、限界値の考慮(想定外の条件が他にないか?)
  • テーブル/ファイルレイアウトに矛盾はないか?
  • システム構成図、処理概要など標準的記載事項に漏れはないか?
  • 内部設計時のレビュー

    プログラムの構造が適切に展開されていること、機能仕様で記載された実現度合いの確認がレビューポイントとなります。 特にエラー処理や障害時対策,およびタイミングに関する処理に考慮の漏れがないか、性能問題を引き起こすような設計になっていないかという点は発見が困難であるため、十分に時間をかけて確認する必要があります。

  • 機能の漏れ、曖昧さはないか?
  • 機能の正しい実行ができることが確認されているか?
  • インターフェイスの完全性が確認されているか?
  • モジュール構成、分割の妥当性は確認されているか?
  • 必要に応じて既存モジュールの利用はされいいるか?
  • 処理タイミングに矛盾はないか?
  • エラー処理、障害時対策が十分検討されているか?
  • コードレビュー

    ソフトウェア開発工程で見過ごされた誤りを検出・修正するためにソースコードの体系的な検査(査読)を行うことです。 ソフトウェア品質を高めると同時に開発スキルの向上を図ることができます。 プログラミング言語にも依存しますが、標準的な「観点」をメモしておきます。

  • データ参照(未設定の変数、添え字の限界)に関してのミスはないか?
  • データ定義(未宣言の変数,異なる型での参照)に関してのミスはないか?
  • 計算(0割、オーバフロー、アンダフロー)に関してのミスはないか?
  • 比較(矛盾する変数同士の比較)に関してのミスはないか?
  • 制御(無限ループ、ループ中断の妥当性、フラグ追加の影響が不明瞭)に関してのミスはないか?
  • インタフェース(パラメータ引数の数、参照されていない変数)に関してのミスはないか?
  • 戻り値(NULL、SPACE、または異常値)に関してのミスはないか?
  • 機能の漏れ、曖昧さはないか?
  • 「視点」に関しては、チェックリストに合わせて、まだまだ書きたいレビュー場面があるので切り口を変えながら情報提供したいと思います。

    関連コラム
    レビュー技法におけるチェックリストの役割 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日 宿澤直正


    [事務所TOP] [コラム一覧へ]

    Copyright (C) 2015 宿澤経営情報事務所