ポスト
はじめに
2022年もあっという間に1ヶ月経ち、年度末に向けて忙しくなりますね。
リモートワークが広まる中、随時の転職入社に加えて4月には新卒の入社を控え、チームビルディングに不安を感じている方もいるかもしれません。
月に何度か出社して顔を合わせたり、朝会やチームの定例ミーティングとしてWEB会議をしたり、オンライン飲み会したりとさまざまな施策がありますが、より身近で日常的な"レビュー"に焦点を当ててみてはいかがでしょうか。
本記事では、レビューの効果や具体的な方法を紹介します。
レビューとはなにか
レビューは英語の"review"のカタカナ語で、その語源は"re（もう一度）+ view（見る）"です。
ECサイトやグルメサイトの『評価』として目にすることも多いですが、今回は『見直し』や『チェック』としてのレビューを扱います。
なぜレビューをするのか
レビューにはいくつかの効果があります。
品質を担保するためのレビューであれば、いずれ自動化されてレビュワーは要らなくなるかもしれませんが、そうなるまではまだ暫く時間がかかりそうです。
どうせ人の手でやるのであれば、付加価値として他の効果も意識してみてはいかがでしょうか。
品質的効果
レビュー対象物に対する効果として、誤りや改善点を検知・対応することによる品質向上が挙げられます。
作成者自身でも内容を見直すとは思いますが、検知できる要素には限度があります。
客観的な目線で見直してもらうことで、自身では気付き難い箇所に指摘をもらえることもあるでしょう。
心理的効果
レビュイー（レビューを受ける側）とレビュワー（レビューを行う側）双方に対する効果として、業務的安心と心理的安全性の醸成が挙げられます。
ここで言う業務的安心はレビューによって品質を担保し・担保されることによって得られる安心感を指しています。
レビューの完了はすなわち一つの作業の完了であり、終えられた・終えてくれたことをレビュイーとレビュワーが認識するための作業でもあります。
また、仮にレビューを通していない状態で完璧な内容だったとしても、一人で作業を行うことにはリスクやストレスが伴います。
レビューを通すことによって、レビュイーとレビュワーで責任や心理的負荷を分担することもできます。
次に、心理的安全性とは『組織の中で自分の考えや気持ちを誰に対してでも安心して発言できる状態』のことです。
『組織』や『誰に対してでも』はスコープとしては大きすぎますが、レビュワーは指摘することを通じて、レビュイーは指摘へのリアクションを通して、自身の考えや気持ちをやり取りすることでチーム内での心理的安全性を育むことができます。
学習的効果
同じくレビュイーとレビュワー双方に対する効果として、レビューを通じて自分にはない視点や表現に触れることで、気付きを得られることが挙げられます。
技術的な内容であったり、表現的な内容であったり、当事者によって表現や気付きの内容は異なります。
さまざまな人とレビューし合うことによって視野をより広げることができるのではないでしょうか。
誰がレビューをするのか
ではレビューは誰が行えば良いのでしょうか。
答えはシンプルです。
依頼された作業は依頼者がレビューを行い、そうでない場合はレビューして欲しい人へレビューを依頼すれば良いです。
先述の効果には先輩後輩も上司部下も自チーム他チームもなく、レビューができない人はいないです。
なにをレビューするのか
では一体なにをレビューすれば良いのでしょうか。
こちらの答えもシンプルです。
レビューの対象は『レビューして欲しいもの』です。
SE（システムエンジニア）にとって身近なレビュー対象は設計書や議事録などのドキュメントとソースコードでしょうが、対象を限定する必要はありません。
プレゼン資料や送信前のメール文など、自信がないものやより良くしたいものなど、なんでもためらわずにレビューを依頼しましょう。
どのようにレビューするか
ここからはレビュー、フィードバックの方法とそのメリット・デメリットを紹介します。
口頭
こちらは対面やWEB会議などでレビュー、フィードバックする方法です。
- メリット
- レビュイーとレビュワーがお互いの反応と対象物を同時に見ながらレビューできる
- デメリット
- テキストとして指摘内容が残らない
- その場でレビュイーがメモを取る場合でも、指摘内容の漏れや認識齟齬などのリスクがある
テキスト（レビュー対象物外）
こちらはレビュー対象物とは離れた場所、例えばチャットやメールでフィードバックする方法です。
- メリット
- フィードバック内容がテキストとして残る
- デメリット
- 指摘・反映箇所を探すコストがかかる
デメリットについて補足します。
上図のように指摘箇所もテキストで表現せざるを得ないうえに、レビュー対象物の行や列が変わる可能性もあるため、レビュイーもレビュワーも指摘とそれを反映した箇所を探すコストがかかります。
テキスト（レビュー対象物内・ローカル）
こちらはフィードバック内容をレビュー対象となるファイルに直接記載し、やりとりする方法です。
だれでも一度は吹き出し型の図形を使ったことがあるのではないでしょうか。
- 想定されるレビュー対象の形式
- Excel、PowerPointなど
- メリット
- 学習コストがほとんどなく、直感的に指摘し共有することができる
- デメリット
- ローカルにファイルが複製され管理コストがかかる（レビュー前、レビュー後、レビュー反映後…）
- 差分の確認にコストがかかる
テキスト（レビュー対象物内・クラウド）
こちらはクラウド上のファイル自体にフィードバック内容を加え、やりとりする方法です。
- 想定されるレビュー対象の形式
- Googleスプレッドシート、Googleドキュメントなど
- メリット
- 指摘と差分を視覚化し管理する仕組みがあること
- デメリット
- セキュリティ上の都合でクラウドにアップロードできないなどの制限によって採用できない場合があり得る
メリットについて補足します。
例えばGoogleドキュメントにはコメントや提案の機能があり、前者は指摘や質問・確認に便利です。
また、後者はレビュワーの考えを直接ドキュメント上に示すことができます。
レビュワー自身で考えて対応して欲しい内容はコメント、軽微な修正や大筋を示した方が良い場合は提案と言った具合に使い分けることができます。
以下にコメントの使い方を例示します。
続いて提案の使い方を例示します。
更にバージョン管理について説明します。
Git
最後に紹介するのは、SEにオススメなGitを使った方法です。
普段ソース管理としてプルリクエスト/マージリクエストを利用してコードレビューをしているかと思いますので、使い方は省略しますが、ソースコード以外のドキュメントもテキスト形式で作成しておけば、Gitの機能を最大限活用することができます。
- 想定されるレビュー対象の形式
- テキスト形式のファイル
- メリット
- 指摘と差分が視覚化できる
- 一連のレビュー作業がプルリクエスト/マージリクエストとして記録に残る
- 開発と同じフローでドキュメントの作成、管理ができる
- デメリット
- 多少の学習コストがかかる
こちらの方法は手順以上に、いかにチーム内でメリットを共有・共感し、ドキュメントをテキスト形式で作成するかがポイントになります。
例えば設計書をMarkdownで作成したり、PowerPointの代わりにreveal.jsでスライドを作成したり、そもそもExcelを使う必要があるドキュメントなのか再考したり等、アプローチはさまざまです。
おわりに
いかがだったでしょうか。
レビューの効果を再認識していただき、是非メリットとデメリットを考慮して最適なレビュー方法を見つけていただければ幸いです。
