![【第4回】[#5]レビューの終わり方～レビュー評価・ふりかえり（2/2）｜ソフトウェアレビューをエンジニアリングっぽく語ってみる](https://sqripts.com/wp-content/uploads/2025/01/SReEE_thumb_00-1024x538.png)
みなさんこんにちは。
「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”きたのしろくま”です。
前回に引き続き、「#5レビューの終わり方～レビュー評価・ふりかえり(2/2)」をお伝えします。
＜ソフトウェアレビューをエンジニアリングっぽく語ってみる 記事一覧＞※クリックで開きます
打開策2：レビュー指摘事項の分類／評価の実施
打開策1と同様、レビュー終了直後に、レビューにより検出された指摘事項をいくつかの視点で分類し、評価します。
分類／評価の方法にはいろいろありますが、ここでは2つの事例（視点）を紹介します。
1つ目の視点は、このフェーズで作り込まれた欠陥・不備なのか、他のフェーズで作り込まれたものなのかの分類です。理想的なのは、このフェーズで作り込まれた欠陥・不備を同じフェーズのレビューで見つけ出すことです。（図2の上）これが実現できなければ、プロジェクトが混乱する原因となってしまいます。（図2の下）
よって、他のフェーズで作り込まれた欠陥・不備があれば、作り込まれたフェーズのレビューを見直す必要があることに気づきます。
2つ目の視点は、レビュー目的の達成度と指摘事項の効果です。
レビューの“効果”を何で示すのかについてもいろいろ考えられますが、今回はその一例として「仮に今回のレビューでこの欠陥・不備を見逃した場合、あとでどの程度悪い影響が出るものかの度合い」をご紹介します。
あとになって発生する悪い影響を正確に把握することはできない場合も多いので、下記のように進めます。
- 少なくとも自分たちの開発の進め方から想定すると、この欠陥・不備はこの先どのフェーズで見つかる可能性が高いか、見つかった時の対処にどのくらい期間、工数を費やして対処することになるのかを（ザックリでもOK）見積もります。その際にプランニングポーカーを使うなどの工夫が可能です。
- 見積結果を活用して3つの枠：効果大、効果中、効果小に割り振ってマッピングします。
- さらに、それぞれの指摘事項がどのような観点にあたるのか？を明らかにして、効果大中小の観点分布を把握します。（以上、図3）
- 以上の結果を見ながら、どの観点の指摘事項がどの程度見つかったのか？や、効果大・中・小の指摘数、観点の偏りはないか？、今回のレビュー目的は達成できたといえるのか？、レビューにおける費用対効果はいかほどか？、等を分析、評価します。（図4）
最初は効果大、中、小をどのように分けたらよいのか、それぞれの指摘事項がどのような観点（意味がある）と言えるのか、などメンバーの認識が合わずに難航するかもしれませんが、議論を重ねて一度出来上がるとそれを再利用しながら短い時間で分類／評価を進められるようになります。
完成したレビュー指摘の効果分類図に表現された内容が、対象となるソフトウェアの品質に対するチームの価値観を表すことになります。これがマネジメント、開発メンバー、QAメンバーの共通の価値観になり、あらゆるタスクを進める上で注視して開発を進められるようになっていきます。それがさまざまな役割のメンバーが相互に協力して同じ目的達成を目指すうえで協調関係を築く土台になります。
ここで間違ってほしくないのは、完成した図が大事なだけではなく、それを創りあげる過程＝チームメンバーによる対話や議論がなにより重要である点です。そして、一度完成したら終わりではなく、さまざまなレビューやテストの結果を同様に分類／評価しながら何度も見直し、更新していくことが本質である点です。
なお、この打開策2は打開策1：「レビューふりかえり」の前に実施し、その結果を踏まえてふりかえることをおススメします。
この組合せにすることで、レビューの実施過程＋実施結果の両面を解像度高くふりかえることが可能になるため効果的です。
おわりに
～忙しくてそんなことしている時間はないよ、と言っていた当時の私に
以上の提案をすると「レビュー終了直後に指摘事項を分類/評価したり、ふりかえりを実施するなんて、、、忙しいからそんな時間はないよ。」という声をよく聞きます。
私も当時はそう思っていた一人なので、この先は当時の私に伝える／問いかける内容です。
当時のしろくまさんへ
どうしてそんなに毎日忙しいのか、現状で自分が何にどのくらい時間を割かれているのかちゃんと把握しているかな？例えば、計画された作業を実施したものの、あとで仕損じていたことがわかり、作業をやり直したり、成果物を手直ししたりする工数って作業全体の中にどのくらいあるんだろう？
それを把握することも大事なふりかえりの一種なんだけど、それも忙しいからできないって言うかもしれないね。
自分（たち）の作業や成果物をふりかえって、仕事の仕方をもっとより良く変えない、良くないところを直さないから、いつまで経っても仕損じて手戻り（再作業や非効率状態）が減らず、その結果忙しさが解消されない、さらに忙しいのを言い訳に本当に必要な作業を端折ったりしてまた手戻りを増やしている、なんてことはないかな？
実は、忙しいからふりかえりなんてできない、のではなく、ふりかえらないから忙しくなってしまう、ということなんじゃないのかな？
「忙しい」が結局は現状維持・現状肯定のための言い訳にならないように、そして意図せず自らの成長を阻害することにならないように、しろくまさんの今後の健闘を祈ります。疑問点などあれば遠慮なく教えてね。他者のせいにしていても解決しないからさ。一緒によりよい世界を自ら創り上げていこう！
この記事を担当したメンバー
きたのしろくま（安達 賢二／@kitanosirokuma）
自律・自己組織化を促進する価値共創プログラムSaPIDをベースに三方よしとなる新しい価値を一緒に考えて創る「共創ファシリテーター」として活動中。
https://www.softwarequasol.com/
