成果物レビュー(チェック会議)がうまくいかない6つの理由
エンジニアの方：
成果物を作成後、内容に問題がないかを成果物レビューの場で他者にチェックしてもらっているけど、イマイチ品質が上がらない。レビューの仕方が悪いのかなぁ。
効率的にレビューをする方法を知りたいよぉ。
開発業務をしていて、いろいろな成果物を作りますが、ここで必ずになるのが成果物に対するレビュー。
エンジニアにとって、開発の成果物に問題があると、製品不具合であったり、場合によっては訴訟にもなりかねないため、確実な成果物のチェックが必要です。
成果物レビュー。作られた成果物を、会議形式で他人の目でチェックすると言う、本来は素晴らしいものだが、やり方によってはとても苦痛な時間になってしまうこともあります。
では、レビューがうまくいかない理由は何でしょうか。
そこで、今回はなぜ効率的にレビューがやれていないかについて解説致します。
これまで要求分析からテストまで、すべての開発工程の成果物の作成、及びチェック経験あり。
成果物レビュー(チェック会議)がうまくいかない6つの理由
結論を先にいうと、下記となります。
- 勝手に日時を決めるから
- レビュー計画が甘いから
- チェック観点が明確になっていないから
- セルフチェックした状態でレビューに臨んでいないから
- 事前にレビュー対象物を参加者に送付していないから
- 1回のレビュー時間が長すぎるから
以下で一つずつ解説していきます。
勝手に日時を決めるから
レビューをする日付を決める際、レビューイ、つまりはその成果物を作った人が自分の都合で勝手に会議の設定をすることがよくあります。
これでは参加する側はたまったもんじゃありません。
なぜなら、いうまでもなく、人には予定があるからです。
たとえば以下のような日時の決め方です。
- 事前確認なしで定時後にレビュー開催
- 当日の数時間後にレビュー開催
別にそれ自体は良いのですが、参加者の確認も取らずに、自分の都合だけで定時後に設定するのはいかがなもんでしょうか。
人によっては、定時後なのでプライベートの予定もあります。
それが何の連絡もなしにいきなりつぶれると、
- さっさと終わらせよう
- ちょっといじめてやろうかな
こんな感じで、参加者に殺意を抱かれてしまい、結果としてよいレビューとならない恐れがあります。
例えば、朝の10時にレビュー開催通知を出し、「13時から行います」みたいなのです。
このようなレビューの開催の仕方では、やはり参加者に殺意を抱かれてしまい、結果としてよいレビューとならない恐れがあります。
これまで書いた通り、勝手な開催や、急な開催は、参加者によく思われないので、レビューを開催する際は、参加者全員に時間の都合聞いた日で設定すべきです。
レビュー計画が甘いから
Outlookの会議通知などで、レビュー案内が来るのはいいが、自分の作った成果物のチェックにどれだけの時間がかかりそうかを見積もらず、ただ単に、
”とりあえず3回分くらいレビュー設定しとくか”みたいなノリの人がいます。
これでは困ります。
なぜなら、3回で終わらなかった場合の心のダメージがでかいし、みんなもより1日のために時間をとられてしまうからです。
なので、レビューイとしては、自分が作った成果物について、1回のレビューでどこまでをレビューし、次のレビューでどこまでレビューするのかと言うのを予め見積もるべきです。
なぜなら、それ以上やると、参加者の集中力が切れ、レビューの質が落ちるからです。
なので、1回のレビューは、最大でも2時間に留めましょう。
これはこれで仕方ないのですが、やはりそれでも2時間を超えるとレビューの質が落ちますので、レビュー時間はそれ以上にしないに越したことはありません。
チェック観点が明確になっていないから
レビューを開催する際は、レビューチェックリストのような、「レビューでどのような観点でチェックするか」の指標をもつようにしましょう。
なぜなら、そのような指標がないと、レビューの場が、参加者の単なる思い付きの指摘の場となってしまうからです。
- このあと急ぎの仕事があるから、さっさとレビューが終わるように、あまり指摘はしないようにしよう
- 下手に指摘すると、その修正確認をしないといけないのでやめておこう
- きょうは体調が悪いからあまりチェックしないようにしよう。きっと他の参加者がきちんとみてくれているよね
こんな感じで、いい加減なレビューとなることで、せっかくレビューをしても、成果物の品質が思ったよりあがらない恐れがあります。
なので、レビュー対象の成果物事に、レビュー観点のチェックリストが必要なのです。
確かにそうなる恐れがありますが、それでも、チェックリストがあることで、「最低限の品質」を保つことは可能なので、やはりレビューの際には、成果物事にチェックリストがあることがのぞましいのではないでしょうか。
セルフチェックした状態でこないから
いくらレビューで他人のチェックがあるとは言え、ある程度の状態に持ってこないまま、単に
”とりあえずつくりました”
的なレベルでレビューの場にもってこられても非常に困ってしまいます。
なぜなら、セルフチェックされていないということは、「だれもチェックしていない」成果物を他者がレビューすることになるので、レビュー自体の質もとても悪くなってしまうからです。
というか、自分でチェックをろくにしないまま、
「チェックしてください。よろしく」
と、言うこと自体がおかしいですよね。
- テスト仕様作成者は新人
- セルフチェックが甘かった
- 何度もチェック⇔やり直しが発生
- やり直しが多すぎて、とあるテストパターンが漏れ、見事にその部分でバグ発生
このように、やはりセルフチェックが甘いと、さすがにレビューでもすべてのミスを拾いきれない恐れがあるのです。
なので、レビューイの役目としては、最低限セルフチェックをした上でレビューに臨むべきです。
事前にレビュー対象物を送付しないから
レビューを開催するのはいいが、開催案内だけ出して、レビューの場でいざレビュー対象の成果物をお披露する輩がいます。
これでもレビューの質が下がってしまいます。
なぜなら、レビュー対象物を、レビューの場で所見では、満足に内容を理解した上で指摘するのが難しいからです。
また、その場で所見で、細かいところまでまともにその場で見ていたら、レビューの時間なんていくらあっても足りません。
なので、レビューの役目としては、自分が作成した成果物をレビュー前、せめて半日間位までにはレビュー参加者全員にメール等で事前配布すべきだと思います。
そうすれば、参加者は、事前に自分なりの粒度で成果物をチェックすることができるからです。
一回のレビュー時間が長すぎるから
あまりレビューをしたくないと言うのはわかりますが、1回のレビュー時間は、最大でも2時間を目安にしましょう。
なぜなら、1回のレビューを3時間も4時間も行ってしまっては、参加する側もとても疲れてしまい、これにより、レビューの質が落ちてしまうからです。
また、人が集中して会議に参加できるのはせいぜい2時間位かと。
なので、1回のレビューは2時間以内として、それ以上になる場合は時間をずらすとか、次の日にするとか、そういうことが必要だと思います。
なので、上にも書いたようなレビューの計画がとても重要になると感じています。
レビューの質を高め、手戻りのない開発をしよう
これまで、レビューがうまくいかない原因を解説しましたが、これらを気をつけることで、レビューの質を高め、手戻りのない開発をしましょう。
なぜなら、言うまでもなく、レビューの質が落ちると開発の手戻りが発生し、余計に費用、時間がかかってしまうからです。
なぜなら、
- 開催する側：自分の作った成果物にいろいろ言われるから
- 参加する側：細かくチェックし、いい指摘をあげるのが大変だから
なので、海嶺する側、参加する側、どちらもシンドイのはわかるのですが、それを理由にレビューを疎かにしてしまうと、
「流出不具合」
この恐れがあります。
もし、流出不具合が発生したらどうなるでしょう。
考えるだけでぞっとしますよね。
なので、レビューはシンドイですが、レビューの場でしっかりと指摘をすることで、後戻りのない高品質な製品、サービスを作り上げる必要があります。
と、いうことで有意義なレビューをしましょう
小難しいことを抜きにすると、
流出不具合で、釣りあげられるくらいなら、きちんとしたレビューをやることで品質あげましょう。
これだけです。
なので、よいレビューをし、製品、サービスの品質を上げていきましょう。
今回は以上です。