読者です 読者をやめる 読者になる 読者になる

∑考=人 〜プロメテウス〜

そして今日も考える。

レビューってそんなんでいいんですか

システム開発の世界では、設計書などの品質を高める場合に”レビュー”が行われる。なか形式ばった名前が付けられていたり、種類もウォークスルーレビューとかインスペックションとか目的に応じた形態はあるけれど、やることとしては作成者とは別の誰かに確認してもらうことに過ぎない。たぶん、どんな仕事であれ、自分が何かを作成したら、上司や先輩などに確認してもらうのが一般的であろう。

 

で、このレビューという仕事だが、私が思うに最も危険な仕事である。というのも、レビューとは本来成果物の品質を向上・改善したり、欠陥があれば是正するための仕事だが、標準的な業務として組み込まれていることによって、本来の目的や意味を失い、形骸化してしまっていることが多いからだ。

 

通常、設計書のレビューなどを行う時は、レビュー時に何を確認するのか?を明確にしなければならない。特に、複数の人がレビューを実施する場合は、人によって言うことが全然違う、という状態を避けるため、なるべく具体的にレビューを実施する前に認識を合わせておく必要がある。そして、どういった観点で確認するのか?をまとめたチェックリストのようなものを作成するのが開発標準とされている。

 

とは言え、実際の現場はというと、こういったレビュー時チェックリストというものが明確に定められていないケースが多い。多くの人が、「確か先輩はこういう指摘をしていたよな…」というのを経験と共に蓄積し、自分の中にチェック観点を蓄えることでレビューをしているのではないかと思う。なので、当然、能力や経験によるチェックの厳格さに差が表れたりしてしまう。

 

さらに、いくら経験豊富だからと言って完璧なレビューを実施できるわけでもない。そもそもシステムの設計の正しさを担保するには様々な観点(機能性、保守性、移植性)から正当性を判断しなければならないし、プログラムロジックの矛盾にも気づけなければならないからだ。

 

本質的にはレビュー完了は開発の次工程へのGoサインが降りたことを意味するので、もしレビューで欠陥を見抜けなかった場合は、試験工程になって重大なバグとなって顕在化するリスクが高い。バグは見つけるのが遅いほど、プロジェクトの進捗にもたらすインパクトもデカくなるので、レビューでどれだけ欠陥を指摘できるか、というのは極めて重要なのである。

 

レビューがいかに重要か。これについては共通理解があると私は信じているのだが、だからと言ってそこに多くの稼働を割くことがプロジェクトとして考慮されているかというと、これまた考慮されていないケースの方が多い。だからこそ、レビューの準備が不完全なまま、なんちゃってレビューを実施することになるのである。

 

そもそも、ある成果物を作る場合には必ず、作成フェーズとRv(レビュー)フェーズに別れる。報告書の作成なんかでも同じだろう。まず、担当者が報告書を作成し(作成フェーズ)、その報告書の内容が問題ないかを上司なり先輩なりに確認してもらう(Rvフェーズ)。

 

ここで注意しなければならないのは、担当者が作成したらそれで完成、ではないことだ。個人の成果物は組織として見た時には50点くらいの品質しかない。だからできれば複数の人に確認してもらって、70点、80点と高めていき、最終的に組織として100点に近い成果物が完成するのである。

 

ただ、残念なことにこのような意識を持っている人は非常に少ない。レビュアー(成果物をチェックする人)は作成者がちゃんと作ってくれているはずだと思い込み、レビューイ(成果物をチェックされる人、作成者)は間違っていたらレビュアーが指摘してくれるはずだと信じる。

 

このため、最終的にバグとして顕在化した場合にもどこに責任の所在があるのかがわかりづらく、しばしば誰も反省しない、ということになる。実際にはどちらも悪く、各々が反省しなければならないのだけれど。

 

また、レビューという行為は作成に比べるとチョロまかすことが比較的容易な仕事である点も危険度を上げる要因になっている。

 

例えば、設計書を30ページ執筆しなければならない場合、品質の是非に関わらず一定以上の作業量が発生する。もちろん、高い品質の成果物を作るためには多くの時間がかかるだろうが、品質を下げたとしても、30ページ分という目に見える形として残さなければならないので、それなりに作業時間が必要となる。

 

これに対し、完成した設計書が正しいかをチェックする仕事は、作業品質を落とすことで、作業時間を調整しやすい。極端な話、一切チェックせずとも「問題ありませんでした」と一言言えば、とりあえず作業完了扱いにすることができてしまうのだ。時間調整が利きやすいため、ファクトベースで綿密な計画が立てられることもなければ、執筆作業のバッファとして使われることも少なくない。

 

そして、そういう開発の進め方しかしてこなかった人達で構成されていると、変えるのが非常に難しい。あまり良くないやり方でそれなりの成功をしている(ように見える)ので、改善しようという気にならないのだ。でも、冷静に過去の開発を俯瞰すれば、レビューのやり方に起因して試験工程で想定外の業務が大量に発生していることを踏まえると、これはやり方として明らかに間違っていると言えるのではないだろうか。