レビューの目的は承認ではない!

コラムカテゴリー:

先日、営業支援システムの追加機能リリースが完了し、プロジェクトメンバで振り返りを実施しました。振り返りの中で多く挙がったのは、レビューに関することでした。その一例は以下のとおりです。

1. レビュアが多忙でレビューをしてもらう時間がなかった。
2. レビュアとして何をレビューすべきか分からなかった。
3. レビュー後の成果物の責任はレビュアになるから、担当者としてはレビュアに責任もってレビューしてもらいたかった。

1は「レビューを工数としてスケジュールに組み込む」、2は「レビューシナリオを作成する」などの対策があります。しかし、3の内容を聞いた瞬間、それはレビューではなく承認だと思いました。あなたがプロジェクトマネージャを担当する場合、どのようなレビューをさせたいでしょうか。

弊社コラム「レビューの質を高める3つのポイント」では、レビューの目的を「後続行程で問題が発生した際の手戻りを減らす為に、早い段階で問題を検出すること」と定義しています。
また、ISO9000では、レビューを「設定された目標を達成するための対象の適切性、妥当性又は有効性を見出すための活動」、と定義しています。
ISOの定義も取り入れ、改めてレビューの目的を端的に言うと、「成果物の妥当性・有効性を担保するため」かつ「後続工程での手戻りを減らすため」と表現できます。

例えば、システム開発において、要件定義書のレビューが形式的な承認作業だった場合どうなるでしょうか。
プロジェクトの3要素であるQCD(※)の品質(Q)に着目すると、発注者が提示した要件の抜け漏れなどの不具合は、発注者が実施する受入テストで明らかになります。
システムの軽微な不具合として対処できず、最悪の場合はシステムの作り直しになることもあります。
このような事態に陥った場合、当然ながら納期(D)は延期になり、追加コスト(C)が発生します。
※Quality(品質)、Cost(コスト)、Delivery(納期)の頭文字をつなげた略語。

それでは、このような事態を防ぐために、要件定義書をどのようにレビューするべきでしょうか。その2つのポイントをお伝えします。

1. 工程ごとに目的を明確化する
前述のとおり、レビューの目的は「成果物の妥当性・有効性を担保するため」かつ「後続工程での手戻りを減らすため」です。
例えば、設定する目的は以下が考えられます。

  ・発注者が提示した要件の抜け漏れを検出する
  ・発注者が提示した性能・拡張性などの非機能要件の抜け漏れを検出する
  ・性能要件の曖昧さを検出する

プロジェクトでレビューの目的を定義しレビュアと共有することで、レビュアのレビューに対する認識がプロジェクトマネージャと一致し、効果的なレビューとなります。

2. 1の目的を達成するためのレビューシナリオやチェックシートを作成する
レビューで不具合を検出する具体的な方法として、レビューシナリオを作成することを推奨します。シナリオとは、どこをどのようにレビューするかを明文化したものです。
以下がシナリオの具体例です。

  ・要件定義書に記載されている機能に漏れがないか業務フローと比較する
  ・非機能要求グレード(※)を参考にし、要件定義書に記載されている性能・拡張性などの非機能要件に漏れがないか確認する
  ・要件定義書に記載されている性能について、「現状通り」のように曖昧でないか確認する

  ※情報処理推進機構が公表している非機能要件を整理するためのツール

作成したシナリオに従いレビューすることで、単なる承認にならず、漏れ・曖昧さ・誤りを検出できるレビューとなります。

 

ベンダーからの納品物について、形式的な承認をするのではなく、問題を早期に発見できるように、本コラムや「レビューの質を高める3つのポイント」を参考にして、効果的なレビューを実践してください。

2019年05月20日 (月)

青山システムコンサルティング株式会社

久保田一樹