成果物レビューにどんなイメージをお持ちでしょうか。
厳しい納期を前にして手戻りを生む可能性のあるレビュー工程は、作業者にとっても管理者にとっても嬉しいものではないかもしれません。
レビュアーにとっても、専念できるのならまだしも開発リーダーやユーザ企業の現場リーダーが他の膨大な業務を抱えながら実施するため、「全部は見切れない」「夜や休日返上してやってるのに」「正直作業者の品質がもうちょっとよかったら」といった声が聞こえてきます。
そんな成果物レビューですが、プロジェクト成功の鍵として、全体の作業工程を最適化するためにこそ、効果的に実施することを提案します。どの工程で誰が何を勝ち取るのかを共有しましょう。
成果物レビューとは
作成する成果物の妥当性を検証する作業です。
成果物の「作り手」と「作成を依頼した側」の双方もしくはどちらかが、「意図したとおり作られているか」という観点で成果物の中身を確認します。
工程別の成果物とレビューポイント
思い切ってシンプルに書くと下記の通りです。
- 要件定義：要件定義書に要求が漏れなく記載できていること
- 設計：設計書に要求を充足する機能が記載できていること
- 開発：ソースコードが設計書通りにできていること
- テスト：要件定義書、設計書の記載通りにシステムが動作すること
- 導入：システムの動作を含めた本番導入の基準を満たしていること
要求は機能も非機能も含んだり、設計や開発の標準を満たしていることなど細かい部分は割愛しています。
誰がレビューするか
限られたレビュアーだけでなく、役割分担があります。
- 担当者はチェックリストを元にセルフチェック
- 開発リーダーやレビュアーは内部レビュー
- ユーザ側は受入側の観点でレビュー
- 専門領域は第三者レビュー
- PMは全体的な視点でレビュー
終わりに
プロジェクト成功のためには、個々のレビューに責任を押し付け合うのではなく全体で「意図したこと」を「意図した通り」にできるよう作り上げることが重要です。教科書的な内容ではありますが、原点、基本に立ち返って進めていきたいところです。
100日チャレンジ54日目でした。
ゲーミフィケーション研究家usaboより
