コラムカテゴリー：プロジェクトマネジメント
先日、営業支援システムの追加機能リリースが完了し、プロジェクトメンバで振り返りを実施しました。振り返りの中で多く挙がったのは、レビューに関することでした。その一例は以下のとおりです。
- レビュアが多忙でレビューをしてもらう時間がなかった。
- レビュアとして何をレビューすべきか分からなかった。
- レビュー後の成果物の責任はレビュアになるから、担当者としてはレビュアに責任もってレビューしてもらいたかった。
1は「レビューを工数としてスケジュールに組み込む」、2は「レビューシナリオを作成する」などの対策があります。しかし、3の内容を聞いた瞬間、それはレビューではなく承認だと思いました。あなたがプロジェクトマネージャを担当する場合、どのようなレビューをさせたいでしょうか。
レビューの目的
弊社コラム「レビューの質を高める3つのポイント」では、レビューの目的を「後続行程で問題が発生した際の手戻りを減らす為に、早い段階で問題を検出すること」と定義しています。
また、ISO9000では、レビューを「設定された目標を達成するための対象の適切性、妥当性又は有効性を見出すための活動」、と定義しています。
ISOの定義も取り入れ、改めてレビューの目的を端的に言うと、「成果物の妥当性・有効性を担保するため」かつ「後続工程での手戻りを減らすため」と表現できます。
例えば、システム開発において、要件定義書のレビューが形式的な承認作業だった場合どうなるでしょうか。
プロジェクトの3要素であるQCD（※）の品質（Q）に着目すると、発注者が提示した要件の抜け漏れなどの不具合は、発注者が実施する受入テストで明らかになります。
システムの軽微な不具合として対処できず、最悪の場合はシステムの作り直しになることもあります。
このような事態に陥った場合、当然ながら納期（D）は延期になり、追加コスト（C）が発生します。
- ※ QCD
- Quality（品質）、Cost（コスト）、Delivery（納期）の頭文字をつなげた略語。
（例）要件定義書をレビューするポイント
それでは、このような事態を防ぐために、要件定義書をどのようにレビューするべきでしょうか。その2つのポイントをお伝えします。
1. 工程ごとに目的を明確化する
前述のとおり、レビューの目的は「成果物の妥当性・有効性を担保するため」かつ「後続工程での手戻りを減らすため」です。
例えば、設定する目的は以下が考えられます。
- 発注者が提示した要件の抜け漏れを検出する
- 発注者が提示した性能・拡張性などの非機能要件の抜け漏れを検出する
- 性能要件の曖昧さを検出する
プロジェクトでレビューの目的を定義しレビュアと共有することで、レビュアのレビューに対する認識がプロジェクトマネージャと一致し、効果的なレビューとなります。
2. 1の目的を達成するためのレビューシナリオやチェックシートを作成する
レビューで不具合を検出する具体的な方法として、レビューシナリオを作成することを推奨します。シナリオとは、どこをどのようにレビューするかを明文化したものです。
以下がシナリオの具体例です。
- 要件定義書に記載されている機能に漏れがないか業務フローと比較する
- 非機能要求グレード（※）を参考にし、要件定義書に記載されている性能・拡張性などの非機能要件に漏れがないか確認する
- 要件定義書に記載されている性能について、「現状通り」のように曖昧でないか確認する
- ※ 非機能要求グレード
- 情報処理推進機構が公表している非機能要件を整理するためのツール
参考： https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html
作成したシナリオに従いレビューすることで、単なる承認にならず、漏れ・曖昧さ・誤りを検出できるレビューとなります。
効果的なレビューを
ベンダーからの納品物について、形式的な承認をするのではなく、問題を早期に発見できるように、本コラムや「レビューの質を高める3つのポイント」を参考にして、効果的なレビューを実践してください。
2019年05月20日 (月)
青山システムコンサルティング株式会社
