子供に勉強を教えててわからない時、ググって答え探しちゃいます。
学校の先生は、答えも解き方も知っているから教えられるんですよね。
では、仕事で部下が作った資料をレビューする時、どうしてますか？
答えわかってますか。わからなければ答え探してますか。答えも解き方も知らないのにレビューできるはずはないのです。
システム開発で行う設計書など成果物のレビューは、品質を担保するための基本的な手段で、このレビューを組み込んでいないプロジェクトはないと思います。このレビューにも様々な種類がありますが、実施することが当たり前すぎて本来の目的を果たしていない、あるいは実施すること自体が目的化してしまっている場合があります。品質問題が勃発しているプロジェクトでは、対策としてレビュー強化をうたうことがありますが、そもそもレビュー自体の品質を評価しなければ、いくらレビュー時間を増やしたところで改善はされません。今回は、レビューにおける課題と効果的かつ効率的に品質を上げる方法について紹介します。
かんたんイラスト（記事を読む時間のない人へ）
レビューの種類
レビューの目的は、誰かが作成した成果物を別の視点でチェックして品質を上げることです。設計書、プログラムコード、テスト仕様書などは作成者の経験とスキルに依存して作られており、時には抜け、漏れ、誤りが発生しています。これをレビューにより補って品質向上につなげます。レビューにはいくつか方法があり、プロジェクトの規模や期間、ITエンジニアのスキルレベルなどに応じて、必要なレビューを取り入れるべきです。
・自己レビュー(セルフレビュー)
自分が作った成果物に対し、作成者自身でチェックを行う方法です。
・クロスレビュー(ピアレビュー)
同じ立場の別の人が行うレビュー方法です。設計チームに担当者が複数人いる場合、担当者同士で他人の作った設計書をチェックします。
・リーダーレビュー
チームメンバーが作成した成果物をチームリーダーがレビューする方法です。チームリーダーが作成したものをプロジェクトマネージャーがレビューすることもあります。
・チーム横断レビュー
複数チームにチェックをしてもらう方法です。仕様変更の影響調査など複数チームに関係がある場合に行います。
・オールレビュー
プロジェクトメンバー全員に確認してもらう方法です。レビューというより幅広く意見を求める場合に実施します。様々な指摘を得られる一方で、放置される可能性もあります。
・クライアントレビュー
成果物は、最終的にクライアントの承認を経て完成となります。そのために、クライアントのレビューは必須です。
・外部監査
外部から専門家を招き、客観的なレビューを行う方法です。セキュリティ専門会社の脆弱性診断や製品ベンダーによるコンフィグレビューなどがあります。
意味のないレビューとは
レビューをしたから品質が上がるとは言い切れません。レビューをする人や方法によっては、時間だけとられ品質は上がらないという無駄な行為になっている可能性があります。酷いと、契約や計画時の品質指標として定めたレビュー時間を稼ぐために実施している場合もあり、まったく馬鹿げた話です。レビューを一言でいうと答え合わせです。つまり、答えを知らないで実施しているレビューは意味のないもので、品質が上がらないにもかかわらず時間を無駄に取るためプロジェクトにとっては悪でしかありません。炎上プロジェクトの品質向上策でレビュー強化をうたっても、もともと意味のないレビューに時間を増やしたところでプロジェクトの状況はよくならないだけでなく、余計に時間を取られてむしろ逆効果です。では、意味のないレビューとは具体的にどういったものでしょうか。
・目的を理解していない
レビューの種類によって目的が違いますし、レビューする人の役割も異なります。目的と役割を理解していないで実施されるレビューは意味がない、あるいは無駄に時間を使っている可能性があります。例えば、自己レビューは、自分の経験やスキル以上のことを出せるはずはないので、あくまでケアレスミスの排除です。クロスレビューは、レベルの底上げです。同じ設計者でも人によってスキルや知識にばらつきがあり、そのばらつきを組み合わせることで山谷の山の高さに品質レベルを合わせことが目的なので、レベルの山谷に差がなければ意味はありませんし、低い山の人が高い山の人のレビューをしても意味はありません。リーダーレビュー以上のレビューの目的は、体制図上の守備範囲に視点を広げてチェックすることです。リーダーはいち担当者とは見ている範囲が違うので、広い範囲で見ることで、領域間やチーム間のいわゆるポテンヒット的な漏れを排除します。リーダーたるもの経験もスキルも担当者より優れているため、当然、その観点での指摘も期待はします。また、官公庁のシステム開発だと、日本語の文章、用語や言い回しの統一も求められるので、そのチェックだけをする役割でレビューを入れたりもします。
要するに、レビューの種類によってレビューする人がどういう観点で何を求められているか理解していることが重要です。なんとなくレビューしている場合は、たいてい意味がないものになっています。
・レビューする人のスキル不足
レビューする人の技量による問題です。繰り返しになりますが、答えを知らなければレビューはできません。その答えは、どこから得られるかというと、これまでの経験や蓄積してきた知識とスキルです。設計書やテスト仕様書などスキル依存度の高い成果物レビューは、技量の高い人がレビューをするべきです。立場が上だからという理由で技量の低い人が時間をかけてレビューしても重要なポイントに気づけませんし、指摘すら出来ず、はっきり言って意味はありません。このケースが見受けられるのは、マルチベンダの体制でプライムや中間層のベンダーが実質管理だけをしている場合です。実質的な開発ベンダーのエンジニアの方がはるかに技量が高いため、この管理者によるレビューは意味のない場合が多いです。中身ではなく体裁のチェックなど役割を明確にしていればよいですが、無理して本質的な指摘を絞りだそうとしても時間の無駄でしかありません。
レビューの問題点
意味のないレビューがどういうものか理解して頂けたと思いますが、レビューを意味のあるものにしようとすると問題が起こりがちです。レビュー強化は、多くのプロジェクトで簡単に使われる品質対策ですが、進捗や体制に関係してくる厄介な問題でもあるのです。
・レビュー集中
スキル不足を打開するため技量のある人にレビューをお願いすると、その人にレビューが集中してしまいます。スキルが高い人の負荷を平準化するためには、実作業の割り当てを減らすか、レビューに軸足をおいてもらうかを考える必要があり、品質と生産量(進捗)のバランスで悩みます。何も考えずにレビューを増やすと、結果として、時間切れでレビューが甘くなるか、自身の実作業の品質を落とすか、あるいはその両方となります。単純にスキルの高い人を追加投入すれば良いのですが、長いプロジェクトの場合、いくらスキルが高くても新参者が即座にレビューで活躍できるか疑問であり、難しい選択を迫られます。
・レビューボトルネック
一つ目と類似しますが、リーダーレビューやスキル者によるレビューは、複数の作成者が作った成果物を一人で見るため溜まりがちです。このレビューを終えていないと次の作業に入れない場合、レビューが停滞すると進捗に遅れが生じます。遅延を避けるためにレビューはまだでも先の作業を進めてしまうと、その後に手戻りが発生する可能性があります。レビュー強化として、いくつものレビューを重ねる対策を安易に取ると、結果としてレビューがボトルネックとなって進捗遅延や手戻りを引き起こすことになってしまいます。どの成果物にどういうレビューを入れるか、進捗と品質のバランスを考えて設定することが求められます。
・下剋上による崩壊
レビューする人がスキル不足の場合に起こりがちな問題です。知識やスキルの無い人がチームリーダーをやっている、管理のみの立場でリーダーやプロジェクトマネージャーがいる場合、もはや本質的な中身のレビューは期待できません。にもかかわらずレビューが設定されている場合、開発担当者がレビューを意味のないものと感じて、悪い場合には突き上げを食らうような状況となり、役割が崩壊します。リーダーは体制図上に名前があるだけで、実態は、開発ベンダーとクライアントとで直接やり取りをするようになると、無秩序なプロジェクトになってしまいます。クライアントは管理ベンダーにしっかりとした管理を求め、管理ベンダーはなんとかしようとレビューを強化するものの、開発ベンダーは管理ベンダーの技量の低さに不満を持つ、といった皆が違ったストレスを感じながら進めることになります。こうなるとプロジェクトの一体感は皆無となり、最悪の場合、情報共有すらまともに取れず、行く末は炎上です。
レビュー品質を上げる方法
学校の先生は答えを知っているから教えられるのと同じようにレビューする人も答えを知っていないといけません。問題集には答えとともに解き方の解説が載っているように、レビューにも拠り所となる答えを導くための考え方が必要です。一部のスキルフルなエンジニアに頼るとレビューが集中してしまうという問題を引き起こしかねないので、プロジェクト全体としてレビューを効果的かつ効率的にするための方策がとても重要となります。
・レビューチェックリスト
自己レビュー、クロスレビュー、リーダーレビューくらいまでは、レビュー観点とその理由を記載したレビューチェックリストを事前に用意して、レビュー時にそれを活用することがおすすめです。これにより、レビューする人のスキル不足を補えますし、特定の優秀なエンジニアにレビューが集中することも避けられます。各工程が始まる前に、優秀なエンジニアと全チームリーダー、プロジェクトマネージャーも交えて、このレビューチェックリストを作っておくことが大切です。さらに、定期的に記載内容を見直す運用方法を定めて陳腐化させないことも必要です。
・網羅的に抽出する考え方の整備
システム開発においては、設計でもテストでも網羅性が大切です。
特に総合テストのテストケース抽出は、知識と経験、スキルも必要な難度の高い作業です。総合テスト後のユーザー受入試験で障害が発覚すると本番リリースまでの期間が短いため、致命的な状況になってしまいます。そのため総合テストケースはとても重要となりますが、網羅的に抽出する考え方を理解していない人がテスト仕様書を作成し、レビューする人もその考え方を知らないためにケースが足りないという状況のプロジェクトが多くあります。網羅的に抽出する方法の一例としては、インプット観点とアウトプット観点の連続性と組み合わせによる方法があります。このような網羅的に抽出する考え方を、システムの構造や機能要件を熟知した主要なプロジェクトメンバーやリーダー、業務に精通したクライアントも含めて出来るだけ多くの目を通して事前に作り上げることが重要です。この考え方を元に抽出した観点リストを作成しておくと、本番化以降の障害対応や運用保守作業でも活用できるのでお薦めです。
・レビューに頼らず機械的に実施
総合テストでは網羅性も必要ですが、これまでのテスト工程で行ったテストと同じことをやっても意味はあまりないので、効率を考えて間引きをする必要もあります。ただし効率性を追求した結果、漏れが発生しては本末転倒です。そのため、機能や場面によっては多少非効率でも、特定のケースは必ずテストを実施するというのもひとつの手です。例えば、正常系で最も業務量が多いケースは、どんなささいな改修やリグレッションにおいても必ず行う基本ケースとして定義しておくのです。そうすれば、網羅的にケースを抽出する作業も慎重に間引く作業もレビュー自体も不要となるため、準備期間を含めると効率的となる場合もあります。
まとめ
レビューは、成果物を作ることに比べたら優先度が下がるため、状況や内容によっては疎かになることも理解はできますが、その結果、品質が悪くなったり、手戻りが発生したりする可能性があります。抜け、漏れ、誤りを前段で出来るだけ潰すためのレビューですが、やみくもに実施すれば良いということでもありません。目的を理解して、効率的に実施することを考えなければならず、メンバーの負荷や進捗とのバランスを取りつつ、最適なレビュープロセスを定義するのはプロジェクトマネージャーの重要な仕事です。
効率的なシステム開発や、あらゆる技術を利用したDX化はアタラキシアディーエックス株式会社までご相談ください！
