レビューしてるのに品質が低い理由

レビュー。

評論、批評とも意訳されるそれは、ソフトウェア開発においておそらくもっとも重要で、もっとも責任重大な業務じゃないかと思うんです。

もちろん、実際に作ってる人たちも大事ですよ。

ですけど、作り手は作る側の立場だからこそどうしても様々なバイアスによって引き起こされる「思い込み」が品質上の邪魔をします。残念ながら、まったく思い込みをしない人と言うのは、度が過ぎるほど論理で固められていておよそ人らしい感情を持っていない人かもしれません。

いや、訓練次第で大幅に向上させることはできるんですけども。

レビュー自身の品質って意外とこだわられていない

ソフトウェア開発業界におけるレビューと言うと、一般的には「インスペクション」を採用するべきと言われていますが、実際に使われているプロジェクトに参加したことは…20年以上関わってきましたけど２回だけです。

どんなにまじめに実施しているところでも、「チームレビュー」。大抵は「ピアデスク」「アドホック」形式のレビューが採られていると思います。

まぁ、形式は何でもいいんです。

要するに、本質的に求められているのは「品質を一定に保つこと」なので、その目的さえ果たせていれば何をどうしても文句を言われる筋合いではないでしょう。

けれども、本当に品質を保てているのでしょうか。

レビューの品質が高いなら、のちのテスト工程で「仕様検討漏れ」「仕様不理解」「設計漏れ」「設計誤り」等の不良や欠陥は出てこないはずです。ですが、実際には不良の２～３割がこうした上流工程で作りこまれた不良で、しかも大幅にスケジュールやコストに大打撃を与えるケースが殆どなのです。

もし、お読みになっている方にエンジニアの方がいらっしゃったら、そうした経験はないでしょうか。

そう、レビュー自身の品質が悪いのです。

作りこむ際に、ある程度の不良や欠陥が混入しているのは仕方がありません。人間が不完全な生き物である以上、完璧に作りこむことは不可能です。しかも、作った本人では「思い込み」や「先入観」のせいで不良や欠陥を見つけ出すのは難しいからこそ、第三者がレビューをする仕組みが採られているのではないでしょうか。

けれども、レビューの品質が低いのでは話になりません。

信用して任されているのに、問題を発見できない…そういった開発現場は数多く存在していることと思います。

ソフトウェア開発には、いくつかの段階的なプロセス（=工程）があります。これはウォーターフォールでもアジャイルでも、その他の開発モデルであっても必ずあります。

どんなソフトウェア開発モデルでも、おおざっぱにいえば

　仕様確定→設計→製造→テスト

の流れになりますが、その中で随所に設けられる「レビュー」というマイルストーンは、

　『そのタイミングでいったん品質面の区切りをつけて、
　　安心して次のプロセス（工程）に進もう』

というために設けられるものでした。考え方はウォーターフォールのそれに近いくせに、アジャイルでもプロトタイピングでも、スパイラルでもほぼすべての開発モデルで採用されているすごい仕組みなのです。

なんかこう…戦争する敵対国同士なのに「旨いものは旨い」は世界共通なんだなぁ…ってのと似てる気がするのは私だけでしょうか。

にもかかわらず、レビューを実施しても品質面の区切りがつけられず、その工程で発見すべき不良が発見されず、次工程以降で発見されてしまっているのです。

レビューの品質が悪い理由は大別すると３つ。

　・不良や欠陥で重要視すべきポイントが定まらない
　・レビューの目的が理解されていない
　・個人のエゴを持ち込む人がいる

です。

不良や欠陥で重要視すべきポイント

私は、不良を解決するうえで最も重要なポイントは「不良の大きさ」や「影響範囲の広さ」、「改修規模」等ではないと思っています。それらは単に「スケジュール」や「コスト」に影響を与えるだけのマネジメント上の重要課題です。

「品質」という視点、特に成果物そのものではなく開発プロセスの「品質」という視点から見たときの本当に重要なポイントは

　「発見すべき工程」と「発見された工程」のギャップ

だと考えています。

「発見すべき工程」＝「発見工程」

発見すべき時に発見できた場合、それはチェック機構が正しく機能していると言うことです。もしも、チェックリスト等などをしっかり作っているのであれば、その工程のあいだ、他の機能等をチェックする際にも、同じ品質レベルでチェックされますので、確実に保証できると言えます。

「発見すべき工程」＞「発見工程」

発見すべき時が次工程以降であったものをたまたま運よく発見してしまった場合、一言でいえば「ま、いっか」です。不良としてカウントしてもいいでしょうし、せずに申し送り事項として次工程で作りこまないよう進めればいいと思います。

「発見すべき工程」＜「発見工程」

問題は、発見すべき時に発見できず、次工程以降で発見してしまった場合です。この場合、前工程までのどこかで、チェック機構に穴があったと言うことです。もしそれがレビューであれば、レビューが杜撰だったと言うことです。こうなってくると、その工程すべての成果物に対して不信感が出てきます。

もちろん、よほどの理由がない限り「すべてを見直す」ことはしませんが、観点の絞り込み方如何によっては、品質が向上できない可能性もあるため、慎重にことを運ばなければなりません。

レビューの目的

レビューの目的が正しく理解されていないがために、レビューが杜撰になってしまうというのは決して珍しくありません。

既に書いてしまいましたが、レビューの目的は

　『そのタイミングでいったん品質面の区切りをつけて、
　　安心して次のプロセス（工程）に進もう』

というものです。基本的にはウォーターフォールと同じ思想の上で使われるものです。まさか「レビューで担保する品質は、50%もあれば十分♪」と言って進めるエンジニアやマネージャーはいないと思います。

では、どうすればレビューでそこまでの成果物の品質を100%、あるいは100%と思えるレベルにすることができるでしょうか。

ここで最も怖いのが

　有識者

の存在です。

と言っても、有識者が悪いわけではありません。有識者の方が圧倒的にパフォーマンスはいいわけですし、作成者よりは品質も高まるでしょうから、採用したくなるのもわかります。

しかし、有識者を用いさえすれば、レビューは確実に目的を果たせるのでしょうか？

多くのプロジェクトでは、有識者がレビューするというだけで、なぜか品質が確実に保証されることになっています（…という建前で、実際には「じゃあ、他に誰が適任なんだ？」と思ってるから有識者を充てているだけ）。

むしろこれが問題で、

　「有識者がレビューするから」という言い訳が使えるから、
　有識者の知識・経験則頼みで非常に属人的なレビューになっている

ことが、レビューの品質を下げる最大の要因になっているのです。

有識者といえど、成果物のどこを見て、どう判断するかはちゃんとアルゴリズムになっています。いるはずです。それに各成果物の「様式」や「ルール」が決まっていれば、その通りに記載されているかは新人やバイトでも確認できます。

また、インプットの何を引用して成果物（アウトプット）を作成するべきなのかしっかりと決められていれば、決められる様式になっていれば、有識者の記憶や経験則、感覚、センスと言ったあいまいなものに頼る必要はありません。

　「有識者は品質向上はできても、品質保証にはなりえない」
　「論理的で再現性の高い仕組みによって証明しない限り、それは保証足りえない」

これが私が長年培ってきた経験に基づく結論です。

個人のエゴを持ち込む人はレビュアーに向かない

レビューの観点やチェックポイントは、論理的でなくてはなりません。

　・作成者に指摘する際
　・ユーザーに問題ないことを報告する際

その根拠が明確で、かつ聞く側が納得できるような理由でない限り、それは指摘とは言えないからです。

私自身、ユーザーにレビューいただくときに最も苦労するのがこの部分です。あるユーザー企業の担当者様は、正当な評価であることの根拠を述べると、こんなことを言い出しました。

　「うーん…なぁんか品保的なんだよねぇ」

「どうしろと？」品保的という言葉が、なぜかものすごくディスられているように聞こえるのですが、よくよくかみ砕いてみると品質面の証明中でしたので、あ・え・て褒められているものと解釈して先に進めたことがあります。

もちろん、その担当者様はずっと渋られていました。
他にも

　「そうじゃない、なんか違う」

としかおっしゃられない方がいたり、

　「もうちょっとこう、いい感じに」

とおっしゃられる方もいました。

もちろん、相手が必ずしもＩＴリテラシーをお持ちの方とは限りませんので、スケジュールの許す限り試行錯誤しながら相手の言いたいことを読み取って対応させていただきます。

けれども、中には"マウントをとりたいだけ"で難癖をつける方もいらっしゃったりすることもあります。まぁそういう人は一目でわかるので、だいたいその人の上司とか苦手にしてそうな人もお呼びしてハラスメント的なことはさせません（ステークホルダーマネジメントの基本です）。

兎にも角にも、レビューにエゴは禁物です。

もちろん、有識者であるがゆえの先入観や非論理的な観点もダメです。そうした対応は必ずチェック観点の「後出しじゃんけん」を生み出し、作りこみ不良の低減を防げなくなるばかりでなく、有識者ごとに品質ポイントがあって全体品質の統一感・安定感を損なうことにもつながりかねません。

レビューこそ、超論理的であるべきなのだと私は考えます。

その結果、私は

　「戦略的品質マネジメントモデル」

を考案しました（戦術レベルで解決するのではなく…と言う意味ですが、名前が適切かどうかは色々とまぁ…どうなんでしょう）。

とかっこよく言ってみせたところで、特段何かすごいことをするわけではありません。ひょっとしたら当たり前のことを、当たり前にやるだけのことかもしれません。

けれども、どこのプロジェクトでもまず見かけないのでモデル化しました。それは

　「すべての成果物、すべての作成内容に対して
　　あらかじめチェックリストを作る」

です。まぁ具体的には色々な手法やエッセンスまで、事細かにマニュアル化しているのですが、あまり詳細に話すと長くなりすぎるため置いておくとして、エッセンスだけかいつまんで言うと、プロジェクト活動の仕組み（様式、標準、基準、手順、ルール等）を構築する中で、各作業を始める前に、すべての成果物の、すべての項目を確認します。

設計書１枚とっても、ヘッダー／フッター、印刷範囲から、項目一つひとつまで。テスト用のチェックリストについても同様です。

…無理だと思いますか？

そんなことはありません。全ての成果物の様式が決まっていて、それらが有機的に情報の連携がなされていれば１日１工程分くらいのチェックリストは作成可能です。手分けして作れば１週間もかかりません。

あらかじめチェックリストを作ることの意味

このチェックリストを作成する過程で、有識者の観点を取り込むのは有効でしょう。有識者の目線で他のレビュアーにも同じように確認してもらえるからです。

チェックリストを作成すると

　①チェックリストの書かれた品質は確実に保証される
　　レビュアー一人ひとりの品質にブレがなくなります。

　②チェックした記録が残り、抜け漏れがなくなる
　　「レビューしたはず」「積み残しはないはず」がなくなります。

　③レビュアーを必ずしも有識者に頼る必要がなくなる
　　チェックリスト作成自体に有識者を含めれば、
　　チェック自体は誰でも可能になります（低コストな担当でも）。

さらに、このチェックリストをあらかじめ作成しておくことで

　③作成者たちは、どこに気を付けて作成すればいいか把握できる
　　答え合わせの解答用紙を先にカンニングできると言うことです。
　　社会人の仕事は、学生のテストと違って、カンニングし放題です。
　　これを利用しない手はありません。

　④作りこみ品質が向上すれば、いざレビューの指摘が減る
　　これが最大の恩恵です。
　　「レビュー指摘件数が減る＝手戻りコストが減る」
　　ということです。

どのようなソフトウェア開発モデルであれ、「人」に依存しすぎない、しっかりとした土台が確立されていれば、圧倒的にコストやスケジュールの負担を軽減できます。

私は、過去にこの方法で、大手ベンダーが掲げる品質基準値（不良発生件数）を大幅に下げました。具体的にいうと、1/10以下に抑えています。

そりゃそうですよね。

あらかじめ「こことここは、こんな観点でチェックするぞー」とふれ回っているわけですから、作成者たちは意識的に製造するし、レビュー前のセルフチェックで不良をつぶしてきてくれているので圧倒的に減るのは当然です。

そしてそういった活動が定着すれば、定量的品質管理において用いる基準値がいかに役に立たないかも自ずとわかってくるようになるでしょう。

また、チェックリストにない観点を見つけた場合は即座にチェックリストに追加し、周知するので「指摘される」と言うことさえ再発しなくなります。

よく、品質とコストは比例関係にあると勘違いされるマネージャーがいますが、きちんとコントロールすればそんなことにはなりません。むしろ、品質を向上すればするほど、コストは最適化されるようになっているのです。