ソフトウェア開発におけるレビューの目的は？｜レビューにおける大事な考え方

皆さんは仕事で作成した資料やソースなどを「レビュー」してもらったことはありますでしょうか。

１ 再調査。再検討。 ２ 批評記事。文芸・芸能などに関する評論。論評。また、評論雑誌。「ブックレビュー」

出典：レビューの意味 – goo国語辞書

「レビュー」を辞書で調べると「評論」や「批評」という意味の言葉のようですが、ソフトウェア開発における「レビュー」とは一体なんなのでしょうか。レビューをやる意味とかって考えたことってありますか？（★の数をつけるやつじゃないよ！）

そう。当たり前すぎてあいまいねこは思考停止してました。全く今までレビューの意味なんて考えたことがなかったんです。

最近、若手メンバーのレビューをする機会が爆増した為、整理も兼ねて改めて考えてみることにしました。まとめるついでに共有もさせて下さい。

※レビューアーになる前の若手社員は、レビューの考えを学ぶ前にまず勉強しておくべきことが沢山あります。是非▼の記事を参考にして下さい！

入社前や新入社員であれば▼

【記事】【未経験者】SIer入社前（配属前）に「やっておけばよかった」と後悔したこと

何から頑張ればいいかわからないならまず資格を取れ！

【記事】IT資格は若手のうちにとるべし！若手だからこそ得られるメリットあり！

レビューの目的について

早々に核心的な部分から書いていきますが、レビューの目的は「後工程での手戻り工数を減らすこと」ではないでしょうか。

ウォーターフォール型開発の場合、要件定義・設計・実装・テストと進み、最後にシステムリリースを行います。

基本、設計に入った場合は要件定義（前の工程）に戻ることはしません。また、各フェーズでレビューを行い、問題がないことを担保した上で次工程へ進むのがセオリーです。

仮にテスト後のユーザー教育中などにトラブルが発生した場合、手戻り工数はとてつもなく大きいものになります。

それぞれの作業間でもレビューは行いますので、相当な工数がかかってくることがわかるでしょう。また、修正するのも大変なことを理解してほしい…。お願い。

上の例で、

なんてしていたとしたら、「1時間程度の苦労で済んだのに…！！」と後悔しそうですね。

そう！個人としても組織としても、その後悔をしない為にも「レビュー」は絶対に必要なのです。

4つのフェーズで効果のあるレビューを！

レビューにはフェーズがあります。いつも意識していないと結構フェーズ移行があいまいだったり、戻ってみたり進んでみたりとレビューの効率が悪くなるので、レビュー目的である「工数削減」の目的を達成する為にも、ここで一旦整理。

フェーズ１：前準備

とレビューアーが言われてからの話です。

レビュー依頼があった際、「OKー。じゃあ今すぐやろうかー」ってしてないですよね？

「え、普通じゃない？むしろ仕事早くてよくね？」と考えている場合は、一度これからの話を見てみて下さい。（ただ、人によって得意な方法などは違うかとは思いますので参考程度で）

前準備はレビューの一番初めの工程であり、ある意味レビューの「肝」であると言えます。

準備がどれだけできているかによって「レビューの良し悪しが全て決まる！」そういっても過言ではないでしょう。（結構忘れられがちな工程ですが…）

まず、忘れてはいけないことがあります。

準備が必要なのは担当者だけではない。レビューアーこそ必要である。

担当者の場合、

• ドキュメントの整理
• レビューでの説明の流れを確認
• 場所の確保
• レビューアーへの通知　etc…

様々な準備があることは皆さんも理解があるでしょう。

しかし、いざレビューアー側になった時、「レビューに向けての準備」と言われて「何をすればいいんだ？」ってなりませんでしたか？

そんなに難しいことを言うつもりもありませんし、人によっては当たり前の話かもしれませんが、以下にまとめます。

（１）シナリオ（流れ）を決めておく

レビュー観点が明確になっていることが前提ですが、どういう流れでチェックを行っていくかを事前に決めておきます。

主な流れとしては▼をベースとします。

事前にチェックする流れを決めておくことで「長時間化」「話の脱線」などを防ぐことに繋がります。

行き当たりばったりなレビューの場合、

• 「思いつき」で問題を指摘し始めてしまいレビューが脱線しやすい
• レビュー時間が前半部分に偏りがち
• 長時間化した時に疲れてしまって後半のチェックが雑になる

などなど。よくあるケースにハマりがちなのですので、シナリオはちゃんと考えましょう！！

（２）レビュー対象を事前に確認しておく

可能は範囲でドキュメントは打ち合わせ前には確認しておくこと。

打ち合わせが始まってから、

なんてことになったら、ただの時間の無駄ですよね？

レビューを行う場合、「日程調整」「場所取り」などを行った上で「打ち合わせ場所へ移動」して実施しますので、実施前のコストは決してゼロではありません。

「作るべきドキュメントが足りてない」「規定フォーマットで作ってない」などのあからさまな担当者の誤りや不足をを打ち合わせ開始前に気づく範囲でチェックしておきましょう。

打ち合わせ前から既にレビューは始まってる！！そう思って下さい。

レビューの目的は「工数を減らす」ことにあります。ここでも当然適用されますので。

（３）チェック対象の範囲を検討する

レビューは、1機能単位で実施したりする場合が多そうですが、単位はもっと分割してもよいかと思います。（何時間かかろうがやり切る！みたいにやりがちでは？）

特に規模感の大きい機能の場合などでは、「1回目のレビューでインタフェースを」「2回目でその他の部分」をレビューするなど、その時の打ち合わせにおけるチェック範囲を明確にしておくべきです。

初めから範囲がわかっていれば、担当者側もレビューアー側もペース配分を感覚的にも認識しやすいですし、シナリオを決める時と同様で「長時間化」「話の脱線」防止に繋がるようになります。

（４）いつ実施するかを検討する

打ち合わせの前に準備する必要があるので、「今すぐ！」はないかと思いますが、判断基準として「他の作業との兼ね合い」が重要になります。

• レビューアー自身の作業状況
• 担当者の作業状況
• レビュー対象の優先度
• 他機能との関連度

などを検討した上で、いつレビューを実施するか検討して下さい。

私は「担当者が手隙にならないか」「他機能との関連度・優先度」「自身の作業状況」の順番で優先度を決めてます。

ただ、会社のルールや状況に応じてになりますので臨機応変さは求められてしまいますが…。

フェーズ２：問題検出

問題があるかどうかを見つけるフェーズです。「フェーズ２+フェーズ３」が一般的な「レビュー」イメージかと思います。

重要な考え方1：人間関係を持ち込んではいけない

レビュー対象のドキュメントを作成しているのが「誰であっても検出レベルを変えてはいけない」です。

例えば、

言語道断。あり得ない。

先輩や上司であっても、若手と同じレベル感で問題を検出していくべきです。

ここでいう「検出」は、「問題を見つける」ことではなく「問題を見つけて指摘点とする」ことを指します。

先輩だから。この後輩面倒そうだから。そんな理由で指摘事項として挙げられないのであれば、レビューの意味はないです。

どんな相手であっても問題検出のレベルを変えない！それは守りましょう。

重要な考え方２： ： 作成者気分でレビューしない

レビューしていて思ったことはないですか？

私もやりがちなのですが絶対にレビューアーが修正しないこと。

確かに早いかもしれませんが、▼の理由で止めたほうがよいです。

• 担当者の成長機会を損失する
• レビューアーが最後は直してくれると深層心理で思ってしまう（雑になりがち）
• レビューアーの問題検出時間が単純に減る

ここまで言えばOKですよね。

その作業だけで言えば早いかもしれませんが全体を見れば損失しかないので、「自分が修正すればいいやー」という気持ちでレビューしないこと。

重要な考え方３：複数の観点を同時にチェックしない

レビューを行う場合、観点書などを確認しながら行うかと思います。（あまりに小規模案件だと観点書がない！という案件は見たことがありますが…）

そのレビュー観点書にしたがってチェックしていきますが、「解放処理が定義されていること」「誤字脱字がないこと」などの複数の観点を同時に進めない方が良いです。

同時に進めた場合、他の観点に気を取られて重要な観点を見落とす可能性があります。

これは感覚的にもわかる方が多いかと思います。注意深く見ているつもりでも結構見落とします。

特に誤字脱字などは、細かい部分まで見ないと気が付かないこともあって、こちらに集中しすぎてしまうと、大事な処理漏れなどの大きい部分を見失うケースが少なくありません。

この場合、まず「解放処理が抜けていないか」の観点だけで全体をチェックし、次に「誤字脱字」のチェックを行う方が良いです。（場合によってはレビュータイミングを分割してもよい）

重要な考え方４： 時間配分を意識する

時間配分を考えない場合にやりがちなことは「終盤戦で息切れする」です。

ドキュメントの序盤、レビューアーも気合を入れて問題検出に当たりますが、力を入れすぎてしまい序盤で既に１時間が経過している…。なんてことは結構あるように思います。

そうすると大抵の場合、後半になってくると疲れが出てきてます。

もう終盤戦では担当者もレビューアーもヘロヘロ。集中もできていない状態なので問題検出もボロボロ。ダメパターンです。

フェーズ１の前準備段階で時間配分を決めているようであれば、「息切れ」も少ないかとは思いますが、物事には例外はつきものです。

例外が発生した場合も含めてどうするか決めておければ最高ですね！！

もし、想定よりも時間が掛かりそうな部分が発生しそうであれば、日程調整して別途レビューし直した方が効率も確実性も高いです。（もちろん確認事項などは準備した上で）

時間配分を守りながら進めていきましょう！

フェーズ３：問題指摘

フェーズ2で検出した問題を担当者に指摘していくフェーズです。

重要な考え方１：人格否定にならないようにする

当たり前の話ではありますが、指摘回数が増えてくるとレビューアーも段々とイライラしてきてしまい、つい言ってしまう…。というケースもあるようです。

だからと言って、人格否定までいってしまうと単なる「パワハラ」「言葉の暴力」です。

「人格否定」とは具体的にどういった発言かも記載しておきます。

• 「なんでこんなこともできないの？」
• 「何回言われれば気が済むの？」
• 「基本中の基本なのに本当に知らないんですか？」
• 「その性格直した方がいいよ」
• 「これだから〇〇はダメなんだよ」

要はマイナスイメージのある言葉で否定したり、言う必要のない余計な発言をすると「アウトー」って感じですかね。

例は露骨に嫌な感じを出してますが、何度も何度も執拗に修正させる行為も「パワハラ」に該当しますので注意して下さい。

あくまで「品質向上の為の指摘」を行って「担当者にも納得感」を与える指摘を行って下さい。

重要な考え方２： 時間的要因による”意図的”な見逃しをなくす努力をする

「今指摘したら帰りが何時になるかわからない」などの時間的な理由で意図的に見逃してしまう場合があります。

確かにレビューが深夜まで続いてしまい、担当者もレビューアーも疲弊していると正しい判断ができなくなり、「ここの指摘は別にいっか」となってしまうのも致し方ないでしょう。

ただし、意図的な見逃しはレビューアーとしての責任を放棄したことと同義です。絶対にやめましょう。

前準備の徹底と時間配分の考慮がしっかりされていれば、そもそも疲れている深夜に打ち合わせをやるような計画にはならないのではないでしょうか。

そうなってしまっているようなら、シナリオや計画から見直してみて下さい。

重要な考え方３： 指摘だけでなく良い点のフィードバックも行うようにする

人間、悪い部分だけを叩かれていると気持ちが落ち込みます。

落ち込んだ状態で良いパフォーマンスを発揮できる人間は少ないでしょう。

レビューアーは、可能な限り担当者達に気持ちよく作業してもらえるように努力すべきです。

その為にも、指摘だけでなく良かった点も同時にフィードバックして挙げてください。

打ち合わせの場に担当が複数人いる場合は効果も倍増します。褒められている人を見ると「そうやるといいのか！」と勝手に学んでくれる人もいますし、褒められた本人についても、「いい評価を得た」というチーム内の共通認識が確立されて、モチベーションが上がりやすくなります。

フェーズ４：修正とフォロー

指摘したポイントを担当者に修正してもらい、レビュアーはそのフォローをします。

指摘したら「はい終わり！次っ！」じゃダメですよ？

重要な考え方１：指摘内容を理解しているか確認する

1時間も打ち合わせをしていれば、最初の方の記憶が曖昧になったりするものです。（その為にメモを取ったりするんですが）

せっかく問題を検出・指摘しても忘れてしまってはどうしようもありませんので、確認・記録用として問題指摘一覧はレビュー中に作成しておきましょう。

打ち合わせの最後に、その一覧をベースに担当者が内容を説明できれば、指摘内容を理解していると判断して良いかと思います。

お互いの認識に相違がないか確認することはとても大事なことです。

重要な考え方２：同じレビュー観点でのチェックを繰り返しすぎない

人は一回確認しただけでは心配になる方が多いかと思いますし、実際に漏れが発生する可能性は十分にあります。

そもそも「レビューをちゃんとすればドキュメントが完璧になる！」なんて思わない方がいいです。

人間誰でも失敗はするものなので、抜け漏れが絶対に発生しないレビューなんてあり得ないと言い切って差し支えないです。

それを理解していないと、心配になって同じ観点で何回もレビューしたりするわけです。

正直工数の無駄使いですね。執拗にやる意味はないです。

問題指摘一覧でピックアップしなかった点についてはサラッと流す程度にして、ちょっと見て気づけたら儲けもの！！ぐらいの感覚でないと精神的に参ってしまいますよ？

重要な考え方３：再発防止策を検討する

検出・指摘された問題は、なぜ発生したのかは可能な限り追求しましょう。

「担当者を攻め立てろ！」というわけではないです。

あくまでロジカルに「レビューアーが忙しすぎて時間が取れていなかった」というようなイメージで問題抽出をして、再度同じことが起きないようにして欲しいです。

そして、問題点をチーム全体に共有し、全員で改善案を出すようにして下さい。

1on1の打ち合わせの時にこれをやってもいいのですが、絶対にチームメンバーに内容を周知しましょう。

良いチームというものは、良い共通認識を持っているものですので。

そして、フェーズ１のシナリオ作成に改善案を適用していくことで、より良いレビューの流れになっていくかと思います。

再発を防止していけると、「後工程で発生する可能性のあるリスクを先に潰して工数を減らす」というレビューの目的を達成することに近づけるのではないでしょうか。

さいごに

まとめはしたものの、細かい部分でまだまだ書けそうな部分はありそうな感じので、また別の機会に詳細などを書いていくとします。

レビューは「承認」することが目的になりがちです。（承認の側面を持つことは否定しませんが）

しかし、あくまでもレビューの目的は「後工程で発生する可能性のあるリスクを先に潰して工数を減らす」ことです。

あなたやあなたの会社で行われている「レビュー」について、本来の目的に沿ったものになっているか、今一度考えてみてはいかがでしょうか。

ついでに…

数年前に会社にあった▼の本を昼休みに読んだものが、設計レビューの考えの基本になったように思います。

その為、上でまとめてみた内容にもかなり近しいというかほぼ似たようなことが書いてありますので、是非参考にしてもらえればと。