みなさんこんにちは。
「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”きたのしろくま”です。
次の話題は「#5レビューの終わり方～レビュー評価・ふりかえり」です。
前回うれっしーさんが書いてくれた「#1レビューとは？」の次に#5・・・かなり飛んだテーマではありますが、準備できた順に投稿していくと宣言して始めた連載ですのでご容赦ください。
（すべてのテーマ投稿が出揃った際にこの連載の価値がわかるはず・・・です）
今回のテーマは少し長くなりますので2回に分けてお伝えします。
今回は「#5レビューの終わり方～レビュー評価・ふりかえり(1/2)」です。
レビューのよりよい終わり方を一緒に考える機会になるとうれしいです。ではスタートです！
＜ソフトウェアレビューをエンジニアリングっぽく語ってみる 記事一覧＞※クリックで開きます
レビューってどうしたら終わる？
みなさんのレビューはどうなれば終了しますか？
例えば、
・予定していた時間が来たら終了～まだ途中だけど、残りの内容でこれまでの指摘と同様の箇所があれば同じように直しておいてね（ハート）
・レビューアから指摘事項が出揃ったら／それを作成者に伝えたら終了
・声の大きな人が「終わり」と言ったら終了
・正式なレビュー記録が承認されたら終了（QMS的）
など、いろいろありそうです。
これは「レビューの終了基準」の話題ですが、（「開始基準」と同様）特に決まりがないまま、いや「慣習になっている暗黙のやり方」に従って運営している、という状態が意外と多い気がしています。
”やりっぱなしレビュー”の影響
先ほど示した4例ですが、どれをとっても「レビュー計画」や「レビューの実施方法」「レビュー結果」の良し悪しをふりかえらず、集まった人たちでレビュー指摘さえ出せば、あるいはそれを申し渡したら終わり、という状態になっている可能性があります。
この状態を「やりっぱなしレビュー」と呼ぶことにします。
やりっぱなしレビューがもたらす主な影響は以下の通りです。
・レビューに費やす工数や時間が最小限で済むので、実務に早めに戻ることができる。（これは良い影響）
・レビューで新たな経験や気づきを獲得した特定の個人にのみ、その分の学習効果が得られる。
しかし、あくまでも個人の話であり、かつレビュー能力の向上は非常に小さく、組織としてのレビュー能力向上には長い年月が必要になる。
※有識者がいないとレビュー結果が伴わない状態はこのように作られる
・（一度のレビューで各自が獲得するノウハウはそう多くはないため）次回以降のレビューでも同じような結果になることを繰り返す可能性が高い。
例1：検出すべき欠陥や不備を見逃しがちなレビューになっているチームは、以降も同様に見逃す結果になりやすい。
例2：集合レビュー時に話題が横道に逸れてもそのまま放置される（ムダな時間、工数が多くなる）運営になっているチームは、以降も同じ状態になりやすい。
以上のように、メリットよりもデメリットが目立つのが実態だと思います。
さらに、業務やプロジェクトのメンバーは、自分が割り当てられているタスクを遅延なく進めることでさえも簡単ではなく、多忙な中で依頼されたレビューを何とかして行っている場合も多いと推察します。
多忙な中、何とかやりくりしてレビューを実施しているのに、その効果が実感できないと、レビューに対するモチベーションが低下し、前向きにレビューが実施できなくなってしまいます。
このような「やりっぱなしレビューの悪影響や負の連鎖」はどのように打開すればよいでしょうか？
打開策1：レビュー実施直後のふりかえり実践
レビューを実施した直後に今回のレビュー全般をふりかえり、次（今後）のレビューでどのように進めるとより良い結果が出せるのかを明確にするのが打開策の一つ目です。
ふりかえりを実施するときの大事なポイントの一つは「ふりかえりの対象活動を小さくする」そして「終了直後に実施する」ことです。
小さい活動の終了直後にふりかえりを実施することで、対象活動（今回はレビュー）で発生した「継続すべきよい事項」や「見直すべき事項」が記憶のかなたに消えてしまうリスクを軽減し、何が起きたのか、その結果どうなったのかを思い出すための余計な時間を最小化します。（図1-【B】）
よく、プロジェクト終了後にプロジェクトふりかえりを実施しているケースを目にしますが、数か月～数年の期間で運営してきた内容を一度に一気に思い出すことを暗に求めることになります。1日経過すると7割程度の記憶がなくなる、数日前の食事の内容ですら思い出すのに苦労するのが人間ですから、数か月前、半年前の記憶はほんのささやかな断片でしかありません。必要なことをしっかり思い出して共有するには余計な時間と手間をかける必要がありますが、それでも実際には思い出せずに終わることのほうが多くなります。
この方法だと、時間も工数も大きくなる割に効果的な結果が得られる可能性はとても低くなってしまいます。（図1-【A】）
レビュー実施直後にふりかえりを行うことで、短い時間と工数で次（以降）のレビューで実践すべき事項を確実に導出することができるわけです。
さらに慣れてくると、ふりかえり時に各自がふりかえって結果を書き出す（そのために時間をかける）のではなく、レビュー計画立案や準備、各自のレビュー実施、集合レビュー時などの各段階で気づいたことや見直すべき事項（ふりかえり結果）を共有場所に書きだしながら進めることができるようになります。その結果、ふりかえり時にはすでに書き出された各自の結果を確認・共有するところからスタートするため、ふりかえりにかかる時間・工数が小さくできます。これを、リアルタイムふりかえり、と呼んでいます。（図1-【C】）
個人的な経験則ですが、この形式で運営できるようになると、ふりかえりにかかる時間は最短で5分程度、長くても15分程度で済み、次のレビューで実践する具体的な内容を確定することができます。
ふりかえりを実施するときのもう一つの大事なポイントは「関係者で観点を共有して実施する」ことです。
ソフトウェアレビューは一般的に“成果物”に対するレビューですが、ふりかえりは“活動”を対象としたレビューです。
突然「何かあれば指摘してください」と言われると、何となくぼんやり実施することになり、必要な結果が得られる可能性が低くなってしまいます。
関係者が今回のレビュー計画～終了までに体験したことの中には、磨けば光る財宝級の情報が含まれていることがあります。それをしっかり抽出・言語化するために「観点」を活用します。
下記はレビューふりかえりの観点例です。
[全体共通]
- ナイスプレー（自薦他薦問わず）、個人的に獲得した気づき、あとから準備不足や仕損じが判明したこと、など
[レビュープランと準備]
- レビュー目的、確認すべき観点は適切であったか
- レビュー目的、観点等に必要なレビューアを割り当てていたか
- レビュー対象成果物の難易度や重要性・規模、作業者のスキル等からふさわしいレビュータイプを選択できたか ・レビュー実施に必要なインフラ（各種様式、結果格納場所の確保と周知、集合レビュー時の会議室やオンライン会議の準備など）は遅滞なく準備できていたか
[集合レビュー]
- 集中して建設的に議論し結論が導けたか
- 全員参画できたか／全員から発言・意見・コメントが提示されたか
- 司会のファシリテーションは適切であったか
[レビュー結果]
- 特定の観点による確認の欠落、不足が危惧されることはないか
- 指摘件数や指摘内容から想定されるリスクや問題点はないか
ふりかえり時に各自が観点に沿ってふりかえり結果を1件1葉で書きだし、全員で共有してまとめていきます。とある一人の気づきや考えを関係者の気づきや考えに変えられる、共有されるのがふりかえりの大事な期待効果です。ふりかえりを通じて次のレビュー時にチームとして継続して実践すること、見直して実践方法を変えることを具体化します。
なお、ふりかえり観点は固定化するモノではありません。
個別のレビューの目的やチームや関係者の習熟度、実践レベル等に応じて内容を見直す必要があります。
このように「やりっぱなしレビュー」によるいつも同じような結果しか得られない状態から、レビューを実施するたびに個々人の体験やノウハウをチームのノウハウに変えてレビューのパフォーマンスを段階的に変えていく基盤にすることができます。
・・・ちょっと長くなりました。
まだ途中ではありますが以上で「#5レビューの終わり方～レビュー評価・ふりかえり(1/2)」は終了です。
この続きは次回「#5レビューの終わり方～レビュー評価・ふりかえり(2/2)」でお伝えします。
お楽しみに。
この記事を担当したメンバー
きたのしろくま（安達 賢二／@kitanosirokuma）
自律・自己組織化を促進する価値共創プログラムSaPIDをベースに三方よしとなる新しい価値を一緒に考えて創る「共創ファシリテーター」として活動中。
https://www.softwarequasol.com/
