レビューの意味について品質の観点から考察する
レビューを行う目的とは何でしょうか？
ほとんどのプロジェクトでレビューを行っていると思います。しかし効果的に行われているか、自身を持って言えますか？
管理人は自信がありませんでした。そこでレビューについて考察していきたいと思います。
レビューの意味
レビューとは何をすることなのでしょうか？ e-Wordsの説明がわかりやすいので引用します。
システム開発において、作成された仕様書やコードなどの成果物を開発者とは別の人が詳細に調べ、仕様や要求を満たす内容になっているか、誤りや不具合が無いか、資源の浪費や不必要な冗長さ、極端な低性能などの問題が無いかなどについて開発者にフィードバックする工程をレビューという。
レビューの目的
次にレビューの目的を整理しましょう。どちらかというと成果物に対するレビューを指します。
PMBOKでも至る所でレビューという言葉が使われています。
- 成果物の欠陥を発見する
- 成果物の改良
- ナレッジの共有
- 教育効果
成果物の欠陥を発見する
最大の目的は、成果物の欠陥を早期に発見することです。
欠陥を早期に発見することで、次工程以降での欠陥修正に関する工数を下げることが一番の目的です。
成果物の改良
レビューアが有識者（専門家）であれば、設計者（レビューイ）が設計した内容についてのアドバイスを受けられます。
アドバイスとは、間違いではないが「こうすればよりよい内容になる」などの指摘をしてもらうことです。
そうすることで、冗長的な処理の解消や、設計をシンプルにして保守性の向上を図るなど、成果物をよりよいものへと改善することも期待されます。
- レビューア：レビューをする人（例：設計書の欠陥を指摘する人）
- レビューイ：レビューされる人（例：設計書を作成した設計者）
ナレッジの共有
クロスレビューなどでは、双方の設計者が違うサブシステムの設計書をレビューすることで、情報やノウハウなどのナレッジを共有できます。
こうすることで、他の問題・欠陥の発見に役立てることが期待できますよね。
教育効果
さきほどの「成果物の改良」に含まれますが、設計者が未熟である場合、有識者（専門家）からの指摘を得ることで、設計スキルの向上が見込まれます。
設計者のスキルが向上すれば、プロジェクトとしても生産性の向上や品質の向上が期待できますね。
成果物V字モデルとレビューの関係
成果物V字モデルのイメージ
みなさんも良く見かける成果物作成のV字モデルの図があります。成果物作成の大きなプロセスは次の通りと考えてみるとわかりやすいでしょう。
上図から次のよう分類できます。ご自身の組織で使用している用語と多少違うかもしれませんが、おおむねイメージは一緒かと思います。
- 要件定義 → 要求分析
- 設計工程 → 基本設計、機能設計、詳細設計
- 製造工程 → コーディング（製造工程に単体テストも含むかは微妙・・）
- テスト工程 → 単体テスト、結合テスト、システムテスト
- 受け入れ → 受け入れテスト
品質の観点で考えると
品質といった観点で考えると、次のことが言えるでしょう。
- 要件定義、設計工程、製造工程 → 品質の作りこみ
- テスト工程 → 品質の検証
ここで、品質の作り込みについて説明します。
品質の作りこみ
設計から製造にかけて、品質の作りこみを行います。具体的には次のようなことです。
- 顧客要件と一致するよう設計すること。
- 設計した内容どおりに製造すること。
品質の検証
テスト工程では、設計～製造工程で、作りこんだ品質の検証を行います。次のようなことを指します。
- 設計したとおりに製造されているかということを検証すること。（単体テスト）
- 顧客要件を満たした設計がされているかを検証すること（結合テスト、システムテスト）
各工程の比重
各工程に対する比重は、品質の作りこみに大きな比重をかけたほうがよい結果が得られます。
一般的に言われていますが、品質の検証（テスト工程）で品質を上げるのは、とても厳しいことです。
品質の作りこみを怠ると
いくつかの例を挙げてみます。
設計～製造工程での障害対処の工数を1とすると、テスト工程で発見して対処する場合、10倍程度の工数が必要です。本稼動後に発見されて対処する場合は、100倍以上の工数がかかる、というものです。
具体的な工数はプロジェクトにより違いがありますがが、管理人の感覚でも、それくらいの差はあると感じています。
設計工程ならば仕様書の修正とレビューに1hとしましょう。
製造工程だと、次のような作業が発生すると想定して約10h程度でしょうか。
- 設計書修正 ＋ プログラム改修 ＋ PT仕様書修正 ＋ 再テスト
これがテスト工程（IT、ST）になると、どうなるでしょうか？ 次の通り影響が大きくなっていくことがおわかりだと思います。
- 製造工程やり直し ＋ IT・ST仕様書修正 ＋ IT・ST再テスト ＋ 他サブシステムへの影響確認 ＋ 構成管理 ＋ ・・・・
10倍の工数という法則であれば、100h程度かかるということです。ちょっと大げさですかね。
しかし本稼動後に発見されると、大変です。欠陥の種類によっては、損害賠償問題になることもあります。
これらのことから、いかに「品質を高める努力」をすべきかがおわかりになると思います。
そして早い段階、とくに上流である設計工程で欠陥を除去することが重要です。
そのため品質を作りこむ方に比重を置いて進めたほうが効率はよいのです。
品質作りこみに必要なもの
品質の作りこみが重要であることはわかりましたが、どのようにして作りこんでいけばよいのでしょうか？
これは古くて新しい、かつ、プロジェクトで当たり前のように行われているものです。レビューです。
レビューの重要性
さきほどの例で「設計工程で欠陥を除去することが低コストで品質を担保できること」を説明しました。設計工程であれば、修正量が極小ですむことと、影響範囲が少ないためです。
どのようにして欠陥を除去するかということですが、その方法として一般的なものが成果物に対するレビューです。
いい事尽くめのように思えてきますが、実はやり方しだいでは効果をあげられません。
どのプロジェクトでもレビューは行っているでしょうし、工程の完了判定などでもレビュー記録などを確認していることと思いますが、なぜテスト工程以降での障害・欠陥が発生してしまうのでしょうか？
それはレビューが効果的に実施されていないためです。
効果的ではないレビューの例
効果的でないレビューの例を挙げてみます。
- 形式的におこなっている
- 時間がないという理由で実施していない
- レビューの仕方がわからない
- 非効率なのでやめた
形式的におこなっている
これは体裁を取り繕うために、あたかも実施したように見せかけることです。
指摘事項もどうでもいいような軽微な結果を残して、指摘率はそれなりに見えるというものです。これでは本質的な欠陥が検出されずに次工程に進んでしまいます。
時間がないという理由で実施していない
短納期プロジェクトで設計工程の期間が短いため、レビューに当てる時間を取っていないというケースもあります。
とりあえず仕上げるだけ仕上げて、問題点は次工程で考えるという、先送りのパターンもありますね。これは先の工程で問題が炸裂（さくれつ）します。
レビューの仕方がわからない
レビューをする側も受ける側も「レビューの効率的なやり方がわからない」というケースもありました。役割分担がアンマッチだったりします。
プロジェクトマネージャもよくわからず、指導もできないケースもありました。
非効率なのでやめた
ひとつのレビューに時間がかかりすぎて進まないからやめてしまうというパターンです。
これはレビューア（レビューする人）が、個人攻撃したり、些細な体裁ミスをネチネチ指摘したり、本質から外れた指摘を延々としているケースが当てはまります。
これでは非効率で、レビューの本来の目的が達成できません。
効率的なレビューの方法
効率的なレビューの方法ですが、上記で説明した効率が悪い方法の逆をすればよいでしょう。すなわち次のような内容です。
- レビューの目的をプロジェクトで定義し、プロジェクトメンバーに周知徹底する。
- レビュー技法に習熟し、効率のよいレビューを推進する。
- プロジェクトマネージャがレビューに関して指導できるレベルに
レビューを効率的に行う方法については、書籍がたくさん出版されるくらい、難しいテーマです。
本記事ではレビュー技法については語らないことにします。なぜなら管理人も手探りの状態で進めているからです。
時期が来たら、ブログに投稿したいと考えています。
まとめ
効率のよいレビューを行うことは、非常に難しいことです。
管理人のプロジェクトも先ほど挙げた効率の悪いレビューをひたすら繰り返していました。結果としてテスト工程で問題が噴出してしまい、火消しに時間もコストも取られた経験があります。
しかし「喉元過ぎれば熱さ忘れる」ではありませんが、レビューの本質的な意味をわからないまま、プロジェクトを進めていても、同じことを繰り返してしまいがちです。
しかしPMBOKで品質の作り込みに関して学んだのであれば、骨の髄まで染み込んでいることでしょう。
この学んだ知識を実務に生かして、PMPを取得したプロジェクトマネージャは一味違うと言われるようになりませんか？