みなさん、こんにちは。
「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”うれっしー（うれしのあや）”です。
今回は「レビューとは？」がテーマです。
「〇〇レビューと名前がついていなくても、それはレビュー！って捉えて活動していきましょう」
と言いたい、少し視野を広めていただきたい記事になります。
＜ソフトウェアレビューをエンジニアリングっぽく語ってみる 記事一覧＞※クリックで開きます
レビューとは何か？
さてさて、レビューとはいったい何でしょうか？
まずは気楽に、字面（じづら）として意味をとらえてみましょう。
「レビュー（Review）」は、「re（再び）」+「view（見る）」が合成した形になっています。
このままの意味「再び見る」のであれば、日常生活がレビューだらけです。
朝出かける時の「携帯持った、財布持った、鍵持った！」も、もう十分レビューなわけです。
次に言葉として、辞書的な意味合いを見ていきましょう。
Googleさんに聞いてみると、「Review（レビュー）には、「批評する」「復習する」「再考する」などの意味があります。 」と教えてくれました。
例えば今回のような記事を読んでいると
- この記事のここはいいけど、あの部分はもう少しよく書けたはず
- あのポイントは覚えておきたいから、もう一度チェックしておこう
- ちょっと引っかかった言葉があるので、別の記事も調べてみよう
なんてことがあるでしょう。
たしかに、一目見ただけではなく、今一度記事を見たり頭の中で思い起こしたりして、批評も復習も再考もしています。
というわけで、これらが「レビュー」なわけです。
それは辞書ひっくり返しただけじゃないか、エンジニアリングではなく日常の話だよね、開発で役立つことが知りたいんだよ！というあなた、ここから開発っぽくなりますのでご安心ください。
開発現場における「狭義のレビュー」と「広義のレビュー」
多くの開発現場では、コードレビューや工程移行判定のレビュー、出荷判定のレビューなど、エンジニアリングとして開発プロセスの中で形が定義されていると思います。
指摘事項について合意ができるまでさらに議論したり、疑問については関係者に説明ができるような回答を用意したり、To-doリストを残して管理したりもしているでしょう。
つまり多くの方は「レビュー」と言えば、このような公式に規定されているレビューを思い浮かべるのではないでしょうか。
これらを我々は「狭義のレビュー」と捉えています。
一方、規定されているレビュー以外で、設計書やコードを読んだり、プロセスを策定したり改善したりする際も、気になったことを同じチームのエンジニアに相談に乗ってもらったり、上司に聞いてコメントをもらったりすることが多いと思います。
我々はこれらを「広義のレビュー」として捉えています。
つまり、開発やテスト、プロセスにまつわる相談も「レビュー」に入れているわけです。
「広義のレビュー」として捉えた方が、規定のレビューだけではカバーできない、今まで見えてなかったものが見えてくると思っているからです。
コードや設計書などの成果物を理解するために、
- わからないことを聞いて、わかるようになる
- この部分は、そもそもどうなっていたのか？と確認する
- もっとこうした方が分かりやすいのではないか？と改善案を考える
- 公式レビューの準備のために、事前に合意をとっておく、有識者だけで仮の結論を出しておく
このような行為を複数人で実施しているのであれば、ピアレビューと言えるのではないかと考えているわけです。
他にも、
- エンジニアの頭の中にあるけど、うまく成果物に表現できていないことを引き出す
- 規定されたレビューの範囲内で多くの項目があり、網羅しているつもりだが、リリース後に問題が起こったので、確認項目を見直してみる
- 有識者が直接関係しない部分にも参加が必要になっていて時間がもったいないため、レビュー自体の手順やプロセスを効率化する
これらもエンジニアリング行為であり、テクニックと同等のものを行使する必要がありますので、「レビュー」と捉えています。
にしさんがよく言っていた「テクい」話の方で、「会議術」（一般的な会議を回す技術）ではない方です。
レビューはテストとは違って動かないもの・ことも対象に入ってきますので、テストとは異なる技術が必要になることは明確でしょう。
必要な技術の中身については今後の連載の中に出てきますので、お楽しみに。
「広義のレビュー」の効果
「狭義のレビュー」の重要性は書くまでもありませんが、でき上がった後の成果物に頼ると現場の負担が大きくなりがちです。
特にレビューでお悩みの方は、公式レビューよりも前の気軽な相談や確認会を増やす＝レビューをシフトレフトすると、コストをあまりかけずに製品やサービスを一歩でも改善できると思います。
加えて、レビューの役割分担も普段とは少しずらしたり別の視点にしてみたりすると、みんなの知恵や日常とは異なる良いところも見えてきそうです。
いろんな人の知恵を集めてちゃんと使えるようになると、さらに進化した、強い組織になっていくことにも繋がるはずです。
まとめ
「〇〇レビューと名前がついていなくても、それはレビュー！って捉えて活動していきましょう」
レビューを「狭義のレビュー」で捉えるよりも、「広義のレビュー」として考えてみた方が、手戻りが少なくちょっと気楽になる未来が見えてくるのではと思います。
この連載で書くのはあくまで例にはなりますが、それぞれの現場でどのようにあてはめてみると良いかを、まずはゆる目に検討されてみてください。
「広義のレビュー」の検討が、少しでも皆さまの良い製品・サービスにつながることを願っております。
この記事を担当したメンバー
うれっしー（うれしのあや／@ureshino66）
大規模ソフトウェアの品質管理を22年ほど経て、最近の活動は、ASTERのバグシェルジュとSReEE(スリー)「ソフトウェアレビューをエンジニアリングっぽく捉える会：Software Review Engineering Explorers」。
https://www.softwarequasol.com/
