ピアレビューについて
List
間違ったレビューの仕方
ほとんどすべてのソフトウェア開発の現場では、不適切なレビューが行われています。“不適切”というのは、レビューとしての効果を上げないだけでなく、不適切であるが故の副作用も生じていることを意味しています。以下に、その“不適切”な状態を幾つか取り上げます。
例えば、
１）事前に配付していないし、事前にレビューアのペースでチェックしていない成果物の欠陥を探す行為というのは、もともと「検証プロセス」の役割です。そこでは、設計などの「変換プロセス」の欠陥によって成果物に入り込んだ「間違い」（成果物欠陥）を、レビューやテストというプロセスによって見つけるのです。しかしながら、成果物の欠陥を発見するためのレビューとはいっても、現実にはレビューアの資質と経験によって発見できる成果物欠陥が異なることは避けられません。だからこそ、レビューアに応じて分担範囲を分ける方法も有効になるのです。また、成果物欠陥を発見にするに至るメカニズム（思考経路）もレビューアの経験や思考のパターンによって異なることは避けられません。このような状況を考えた時、成果物のレビューは、事前に配付された状態でレビューアのペースで行うことがもっとも効果的なのです。
レビュー対象の成果物をレビューの場で配付した場合、通常は作成者によって“朗読”したり説明しながらレビュー作業が進むことになります。しかしながら、CMMが推奨するレビュー技法の一つである「ソフトウェアの構造化ウォークスルー」（著者：Ｅ・ヨードン）では作成者による説明を避けることを進めていますが、その最大の理由は、その場にいるレビューアが説明に納得または洗脳されるからです。検証プロセスは、各自の「推論エンジン」をフル回転させる必要があります。それまで見た範囲での記述との矛盾や欠落などに気付くには、そのつど立ち止まって、後ろに戻ったり先に飛んでみたり、他の資料と照合したりする必要があるのです。今、手にしている成果物は初めて目にするものであったり、作成者が前で説明しているようでは、推論エンジンが働かず、検証プロセスとしてのレビューは機能しないのです。
２）レビューに耐える成果物が書かれていない
もちろん、事前に配付された成果物がレビューアのペースで読むことができなければなりません。勝手に使われた用語の意味も分からない状態では、事前に読むことができませんし、文書の構成が悪いと、どこに何が書かれているのか迷うことになります。したがって、レビューの効果を上げるには、レビュー技術の改善とは別に、成果物の構成や書き方も改善する必要があります。
３）指摘は欠陥だけで肯定意見を出していない
何よりも、レビューの間違いは成果物に潜む欠陥の指摘だけに終止していることです。もちろん、成果物欠陥の指摘はレビューの主要な目的です。しかしながら、成果物欠陥の発見だけに終止することで、レビューアの目は「否定眼」に偏ってしまい、人の成果物から優れた箇所を見い出す「肯定眼」を手に入れることができなくなるのです。いや、すでに日本中の現場（組織）で、この「肯定眼」は失われたのではないかと危惧していますし、私自身、過去においてその現実を目撃しています。
そこにいる人が全員「否定眼」で覆われた組織の中では「能動」で動くきっかけを見い出すことは容易ではありません。いや、はっきりと困難と言ってもよいぐらいです。そのような組織の中では、レビューで指摘される箇所を減らしたいという思う人はいても、結果として指摘が少なかったかどうかしか評価されません。極端なケースでは“指摘件数のノルマ”が課せられているケースもあり、これでは逆に指摘されないような工夫を妨げる可能性すらでてきます。当然、書き方を工夫したところを評価されませんので、何かを工夫しようという思考にはならないのです。それに、ちょっと工夫したぐらいでは、すぐには結果に繋がるとはかぎりません。特にデータの取り方が「合計件数」しか収集されていないと、効果を判断することは難しくなります。
こういう組織文化の中で、多くのエンジニアは「工夫」する楽しさを失っているのです。にもかかわらず、そのような文化が染み渡った状態のままで「CMM」を導入しようというのです。「能動」で動く楽しさを知らない組織にとって、CMMは負担にしかならない可能性があるのです。もちろん、CMMの取り組みの中で「能動」の楽しさに気付くことはありますが、はたしてそのように誘導できるコンサルタントはどれだけいるでしょうか。
４）チームの連帯がとれていない
事前に配付された成果物をレビューアの持ち時間の中で事前に目を通すかどうかは、レビューアの自主的判断であり「能動的行為」に依存することになります。いわゆる「For the Team」という連帯意識が必要です。でも、チームのメンバー間の意識がばらばらになってしまえば、そうした連帯は成立しません。多くの組織では、形の上では「チーム」になっていますが、単に“組織されただけ”の集まりであって、一つのゴールに対する連帯の意識が失われていることの方が多いように思います。このような風土（雰囲気）の中では、まともなレビューは望めません。
このように、多くの組織ではレビューの取り組みを間違えていることが多いのです。
（レビューにおける問題については、拙著「ＳＥの仕事を楽しくしよう」（４章６節）で、もう少し詳しく触れていますので、そちらを参照して下さい）
いきなり“ピアレビュー”は難しい
成果物の欠陥を探すレビューは個人ではできません（少なくとも困難です）。チームまたは組織の支援が必要です。当然ですが、いわゆるCMM的な組織のプロセスレベルが低い状況では、個人がバラバラの状態でチームや組織の支援という認識が低く、成果物のレビューはうまく機能しないことが多いのです。逆にレビューが機能していない状況のままでは、組織能力としてのプロセスレベルを引き上げることは困難なのです。つまりここで“矛盾”するというか、“鶏と卵”の関係が存在するのです。
ところがレビューがうまくできていないということで、「プロセス改善」の取り組みの中で、いきなり「ピアレビュー」に取り組もうとするケースが少なくありません。でも、レビューが上手くできない原因には、チームのメンバーのレビューのための時間の確保の問題や、読みやすい成果物が書けるかどうかの問題、レビュー技術の未熟さなど沢山あります。そのような原因を無視して、いきなり「ピアレビュー」に取り組もうとしても、時間の問題や成果物の問題が解決していなければ、レビューの効果は上がりません。レビューに投入する工数が負担になってくる危険もあります。
レビューが省かれる、あるいは適切な形で実施されない原因に、「事前にスケジュールに組み込まれていないから」ということもあります。つまり、レビューの工数が最初に確保されていないから、その場になってレビューに投入する工数が割けなくなり、レビューが省かれる、というのです。確かにそれも一理あります。では、プロジェクトの最初にレビューの工数を「天引き」しておけば、この問題は解決したでしょうか。
各自が分担する作業の見積もりもサイズに基づいていないし、そのことが原因して「遅れ率」が５０％を超える状況で、「天引き」されていた工数は予定通りレビューに当てることができるでしょうか。そもそも、そのような組織がレビューに耐える中間成果物を作れるのでしょうか。
このように、“望ましいレビュー”が実施できるようになるには、幾つもの前提条件が満たされる必要があるのです。従って、そのような状況を満たす取り組みをしながら、その条件が満たされるようになるまでは、“望ましいレビュー”を目指しつつも、現状で割ける工数の中でレビューの精度を上げる“工夫”をすることが大事です。その「工夫」の中に、“望ましいレビュー”に繋がる仕掛けを少しずつ組み込むことです。そうすることで、前提条件が整ったときには“望ましいレビュー”が可能となるのです。
“レビュー”が原因か？
プロジェクトで発生したバグなどの「原因プロセス」の分析結果を見ると、「レビュープロセス」に原因を求めているケースをよく目にします。
・仕様モレが多く発生した原因は、要求仕様に対するレビューが足りなかった
・データ構造の設計が不適切だったのは、設計のレビューを行わなかったから
・関連する変更箇所を漏らしたのは、ソースコードでのレビューを行わなかったから
というように、レビューに何らかの原因があるという認識です。でも、本当に「レビュープロセス」に原因があるのでしょうか。レビューが実施できたはずなのに実施しなかったのと、レビューがうまく実施できる状況になかったのとは、原因が違います。実施しなかったのであれば、なぜ実施しなかったのかというところにさかのぼる必要があります。たとえば、もともと組織にはレビューの習慣がなく、その時点では誰も言い出さなず、なんとなくそのタイミングを逸したのであれば、次回は、スケジュールの中に明記するとか、レビューを世話する人を確保すれば、改善される可能性があります。その前に、レビューについてのトレーニングが必要かもしれません。
また、マネージャーやプロジェクトのリーダーがレビューに対する理解がなくコーディング作業を急がしたためにレビューが実施できなかったのであれば、彼等に対してレビューの認識を持ってもらうためのセミナーやトレーニングを受けてもらう必要があります。レビューで発見できた可能性のあるバグを集計してみるの見極めができるかもしれません。
一方、レビューがうまく実施できる状況ではなかったというときも、なぜ実施できなかったのかを探る必要があります。作業の進捗が遅れ気味で、レビューで他の人の成果物をチェックする時間が不足したことで、欠陥を見つけきれなかったのであれば、レビューの問題ではなく、サイズ見積もりに基づいたスケジューリングの仕方を修得する方が効果的かもしれません。レビューそのものはできているのですから。
あるいは、事前に配付せずに当日配付の状態で実施したために、欠陥を見つけきれなかったのであれば、次回から事前配付に切り替えたり、回覧式にする方法もあります。ただし、この場合は事前配付したとしても、各自のスケジュールの中で事前にチェックする工数が確保できなければなりませんので、別の原因に繋がっていくかも知れません。
また、事前配付されたものの、表現や構成が分かりにくく事前に読むことが捗らなかったことがチェックモレに繋がっていると言うのであれば、それらの成果物の構成や書き方について、どのような構成が読みやすいのか検討する必要があります。
大事なことは、その状況の中でどうすればレビューの効果が上がるのか、それにはどのような方法があるのか、ということを組織の中で議論することです。「できる／できない」とか「実施すべき」といった「１か０」かの選択では効果は上がりません。
“良心の発露”を誘う
レビューは、関係者が“能動”で動くことで効果が発揮されるプロセスです。自分の持ち時間を割いて、メンバーの成果物に潜む欠陥を見つけることに協力するのですから、受け身でレビューしても効果は出ないのです。そのかわり、能動で動くことでいろいろな“楽しさ”も味わうことができます。
また、レビューは“チーム”で行うプロセスです。“個人”では機能しません。チームのメンバーが協力することで、欠陥を早期に発見してバグとして残る件数を減らして、チームとしてプロジェクトのゴールを達成するためのプロセスです。レビューの対象となる成果物は、ガイドラインに沿っているとはいっても作成者の個性が出てきますので、それぞれのメンバーの性格なども見えてきます。人によっては、同じような間違いをくり返すことがあります。
その間違いや手抜かりが、個人の性格に起因するようなケースは、なかなか改善されないものです。レビューは個人を責めるのではなく、個人の弱点をチームでカバーすることが大事です。したがって、成果物を事前にチェックする場合も、その作成者の性格や能力を考慮して間違えやすい箇所を注意してチェックすることで、より一層の効果がでるのです。
レビューアの方も能動で協力することが前提ですが、それぞれの事情がありますので事前にチェックする予定（責任）の範囲をカバーしきれないこともあります。そのよう場合でも、「責任を果たしていない」と責めることは間違いです。少しでも見てくれたことに感謝してください。チーム全体でこうした気持ちでレビューに取り組まないと、レビューは形骸化してレビュー本来の効果が失われます。
例えば、今日の午後の１時からレビューが予定されているのですが、前日に配付された成果物をチェックできていないために、昼食をそくさくと済ませて席に戻って急いで目を通す姿を何十回と目撃してきました。そのような対応では、目に付くところを“広く、浅く”チェックされるだけです。せいぜい「３０分」しか見ていないのですが、全体をチェックしてきたように見せ掛けてごまかそうという心理が働いているのです。そして午後のレビューの席では、最初に発言するのです。当人は、レビューアとしての責任を果たしたつもりかも知れませんが、これでは事前チェックの効果は上がりません。
どうしてこういう見せ掛けの行動になるかというと、
・事前のチェックが「義務」になっているため、そこに能動で動く余地が生まれない
・チームの他のメンバーも見ているので、というところに甘えがある
ことが背景にあると考えられます。まさに、マネージメントとして能動を誘っていないことの影響（副作用）なのです。もし、昼休みのの３０分しかチェックする時間がなかったのであれば、約束の範囲にこだわらず、範囲を限定してでも３０分でしっかりチェックすることの方が大事です。そして、レビューの場で、チェックできていない範囲を明らかにしておくことです。もちろん、レビューとしてはこうした状況でも感謝し許容すべきです。ここで、「罰」を与えるようなことは愚策中の愚策です。３０分でも、そして範囲は限られたかもしれませんが、そこはきちんと見てくれたのです。このレビューアには“能動の種”は残っているのです。「罰」を与えれば、この種は腐ります。
事前のチェック範囲が不十分でも感謝することで、このレビューアは、今回、不十分だった範囲をカバーするために、後で自分の時間を使ってチェックする“動機”を失わずに済むのです。レビューは今日だったとしても、その成果物のチェックはまだ間に合います。何かの空き時間を使って、彼はチェックできなかった範囲をチェックしてくれる可能性があるのです。私はこれを「良心の発露」と呼びます。こうして後でチェックしてくれたときは、最大限に感謝します。これこを「能動」で動いた証なのです。
人には「良心」があります。必ず持っています。普段は“受け身”や“義務”の中で表面に出てこないとしても、今回は事前のチェックが行き届かなかったという思いが、このレビューアの「良心」を動かすことがあるのです。そしてこの「良心」こそ、「能動」を引き出すのです。後で不足していた範囲をチェックするという行動こそが“能動”の結果なのです。レビューの運営次第で、組織の中で「良心」に素直に反応する人を増やし、能動で動くことの楽しさ、喜びを組織の中で共有することができるのです。
決定するスキルの修得の機会
レビューの場では、明らかに間違っているという「欠陥の指摘」と、“こうした方がよい”というような「提案」が出されます。実際問題としては、要求仕様のレビューでは欠陥が中心になると思われますが、設計書のレビューでは、設計方法について提案も混じってきます。「現時点の要求仕様では、この設計方針でも対応できると思いますが、将来的にこの仕様が変化する余地を考えると、別の設計方法を取り入れておいた方がよい」という形の提案がでてくるわけです。もちろん、要求仕様にも「提案」はあります。
欠陥と認定されたケースでは訂正することが求められますが、提案という場合は、その提案を受け入れるかどうか、あるいは受け入れるとすればどのように受け入れるか、ということは、担当者自身の決定に任せるべきです。
しかしながら、日本でのレビューの運営を見ていると、この種の提案を取り入れることの決定もそのレビューの場で判断されてしまいます。通常は、提案を採用する方向に決められてしまいます。そこにはその範囲を受け持つ担当者の判断や決定は問われていません。間違った提案ではない以上、つまり“正義の提案”である以上、提案を実現することが求められるのです。それに提案者の方が経験者であることも多く、そのことも“実現すべき”という決定になる要素です。
提案が要求仕様書のレビューで出される時は、通常は工数的にも余裕がありますので何とか対応できるのですが、設計書のレビューで出される提案の場合は、その提案を受け入れるとデータ構造はもちろん、大幅な設計変更になってしまい、担当者に課せられた工数の範囲では間に合わないことも起きるのです。それでも、“実現すべき”と決定されてしまったために必死に対応するのですが、工数的な圧迫から、対応が雑になってバグを招き入れる可能性が高くなるのです。
このような時は、提案に対してそれを取り入れるかどうかは担当者に判断させてみることです。その判断で求められることは、納期の約束を満たすということと、提案者に対する誠意の両方を満たさなければなりません。納期が遅れたのは提案を全面的に受け入れたため、ということになると、提案者は、彼には二度と提案しなくなる可能性があります。したがって、“現実的な判断”が求められると同時に、提案者に対する誠意もみせなければならないのです。
現実には、提案に対して１００％実現すると言う決定はレビューの場でおこなわれているために、それによって納期に影響する可能性があることは暗黙の了解ができていることがあります。もちろん、納期を遅らせない“努力”はします。そしてその努力を見せることで納期をオーバーしても許されることが多いのです。
しかしながら、担当者が決定するとなると、そのような甘えは許されません。そしていい加減な決定をしたのでは、二度とこうした提案をもらえなくなります。別の言い方をすれば、チームのメンバーとして受け入れてもらえなくなるかもしれないのです。残された時間の中では、提案を１００％取り入れることはできないとしても、その提案が確かに近い将来に有効になる可能性が高いと判断できるのであれば、データ構造に余裕を持たせたり、データ構造の中に事前に項目を設けておくことも可能です。また、データ構造を隠ぺいするようなI/Fにしておくことも可能です。何らかの形で“中間案”を考えることが大事なのです。
こうして、提案に対して決めたことは、次回のレビューの場などを使って、提案者に説明することが大事です。これが「Accountability」なのです。提案をもらったことで知識や気付きの範囲が広がったことに感謝しつつ、提案者に迷惑が及ばないように必死に考えたことを説明するのです。この時の対応によって、彼は提案者だけでなくチームのメンバーから信頼されるようになるのです。
「決定する」ことは難しいことです。たとえば、
・工数やコストがオーバーしないか
・約束の期限に間に合うか
・この他の提案と合わせても期限オーバーしないか
・この機能に関連するもので近い将来に想定される変化とはどのようなものか
・他の機能に悪影響を及ぼさないか
・品質に問題は出ないか
・提案してくれた人の信頼を失うことはないか
など、いろんな要素を同時に満たさなければならないからです。でも、若い時からこうした「決定する」ことに慣れておくことは非常に重要です。もちろん、一人で悩む必要はなく、リーダーや提案者に相談しながら判断し決定すればよいのです。レビューの中でこうした“決定する”機会と“説明する”機会を作ることができるのですが、ほとんどの組織では、このような「機会」を手に入れていません。今、日本の組織の最大級の問題は、“決定できる人”がいなくなったことです。組織の中で重要な立場に就いている人も、過去においてまともな“決定”をしたことがない人も少なくないはずです。それは、こうしたレビューの場を使って「決定する機会」を作らなかったことが大きく影響しているのです。