仙台ソフトウェアテスト勉強会のブログ -4ページ目

仙台ソフトウェアテスト勉強会のブログ

2012年から立ち上げた仙台ソフトウェアテスト勉強会のことなどを綴っていきます。

2014年3月の仙台ソフトウェアテスト勉強会は、『楽しいレビュー、うれしいレビュー』を実施しました。
レビューって実施したほうがいいということは分かっていても、雰囲気が重苦しい中で実施したり、誤記の指摘だけしかせずに後でバグが見つかることもありますよね。


今回は『地方で活躍している人と交流しよう!#1』ということで、特別ゲストとして北の塾長こと小楠さとみさんが北海道からSIGのファシリテーターとして参加してくれました。

※SIG(Special Interest Group) :Special Interest Groupとは、「特定の興味ある事柄について、その道の専門家の考えを聞いたり、メンバー同士が互いに知識や情報を交換する場」のことである。


ちなみに小楠さんがお土産に持ってきてくれたもりもとの『ゆきむしスフレ』が大好評でした!
人数より多かったはずのゆきむしスフレが初雪のようにスッと消えていました(笑
https://morimoto-shinya.jp/yukimushi/yukimushisouffle/



まずは小楠さんから自己紹介と今回の進め方の簡単な説明をしてもらいました。
もともと小楠さんの会社でもレビューが上手くいってなかったらしいですが、一つひとつ地道に改善を重ねて、今では『レビューが楽しい!』と言えるようになったそうです。
どれくらいのエンジニア方が自分たちの現場のレビューは楽しい!って言えるでしょうか?ほんとに極わずかだと思います。


小楠さんの紹介の後、今回は2グループに分れて、それぞれ現場のノウハウを出し合っていきます。まずは最初に参加者同士の自己紹介を兼ねて、それぞれがレビューで困っていることを出していきます。悩みのうちいくつかをピックアップして紹介します。
正直どれもあるあるではないでしょうか?


・そもそもレビューをする文化がない
・責任感がなく、誰かやってくれると思っている
・知識のある人だけが多く指摘をする
・レビューでの指摘事項がそのまま放置される
・ドキュメントのレビューが面倒くさい
・細微な指摘だけで、レビューをした気になっている
・個人攻撃になる
・セルフレビューチェックリストの形骸化
・指摘ばかりで落ち込むことが多い
・間違ったことを指摘しているのでは?と不安になる
・レビューイの費用対効果が不明
・レビューするときの観点が広げられない
・大量の設計書をどうレビューするか
・ジャイアンはだめだ


ということで、今度はこれらの問題点について、解決策となるような意見を出していきます。両方のグループで色々な解決策が出ていました。
時間を結構取ったつもりなのですが、かなりワイワイと盛り上がり、時間が足りなくなりましたね。



今回の勉強会のSIGというスタイルのいいところは、自分たちの現場の問題点を明確にして、自分たちが解決策を出すというところです。有名な方の講演を聞いて『すげーーー!』となることはありますが、実はよく考えてみると、その手法の適応範囲だったり制限だったりが、自分たちの現場に合わないこともあると思います。その点、今回のSIGはお互いが同じ立ち位置で色々なことを気軽に聞けるので、自分たちの現場に適応しやすい事例が多くでてくると感じました。


こちらも一部を紹介します。


【問題点】
責任感がなく、誰かやってくれると思っている
【解決策】
ある観点の知見者を一人に絞ることで、その人に責任感を持たせる
参加者を多くしすぎない(6人以下)



【問題点】
ドキュメントのレビューが面倒くさい
【解決策】
2割くらいでレビューする。
大きいときはアウトラインレビューをする。
レビュー対象物の量を減らす。(テキストデータ化してクラスタ分析)
レビュー前にできる人に相談しておく。
レビュー前に図などを使用し、説明してもらう
レビューして欲しいところは細かく説明する。
単体テスト完了レビューは温泉で実施する。



【問題点】
指摘ばかりで落ち込むことが多い
【解決策】
レビュー時には問題点のみならず、イイネ!という点についても記述する。
議事録に良い点も書く



【問題点】
レビューするときの観点が広げられない
【解決策】
何回かレビューする
チェックリストを作る
過去の失敗例
人によって見るところを変える
ステークホルダー分析で関係者を洗い出す
2回目で罠を探す



【問題点】
ジャイアンはだめだ
【解決策】
人は責めない
完全否定はしない
指摘するときは代案を提示する
レビュー時のルールを決めておく
本質ではない指摘は、前向きに検討するといってやらない
レビュー資料の物量攻撃で時間をかけてレビューしてもらわないようにする
レビューアからレビューイに立場を変える
間違ってたらごめんなさい


最後に両方のチームを見比べて、色々な意見が出ているなぁ~と感じて今回のソフトウェアテスト勉強会は終了しました。





個人的には悪いところだけではなく、良いところを承認し、イイネをつけるレビューは理想だなぁと思いました。これからは少し心がけて議事録に書いていこうと思いました!(・∀・)イイネ!!


勉強会の中で紹介した森崎先生の『間違いだらけの設計レビュー』が今回の話に近いと思いますので、リンクを載せておきます。ちなみにこれとってもお勧めの本なのですが、ソフトウェアの『設計』のレビューの本ではなく、ドキュメントレビューの話なので、そこだけお間違えないように(笑


なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー/日経BP社

¥3,024
Amazon.co.jp