ひとりソーイング・ビーごっこで辛くないレビューライフ

はるにゃん

2021年12月19日 00:00

ひとつ、人の世の生き血をすすり。
ふたつ、不埒な悪行三昧。
みっつ、醜い浮世のバグを、退治てくれよう。石油王。

この記事はソフトウェアテストのAdvent Calendar2021の19日目です。

こんなレビューになっていませんか？

レビュアー「Monkey Magicですか。私はホーリー&ブライトが好きですね。」

レビュイー「え？モンマジならAround The Worldじゃないんですか？」

レビュアー「ハァ〜〜〜〜〜………(クソデカため息)(他のQAと顔を見合わせあきれ返り、ドキュメント類を畳んでゴミ箱に入れ休憩のジェスチャーを取る)レビューは以上です」

これではいけませんね。

レビューにおける問題点

ソフトウェアテストのバイブル、みんな大好きJSTQBの「1.5 テストの心理学」によるとこんな感じ。

要件のレビュー、およびユーザーストーリーの洗練をするセッションなど、
静的テスト中に欠陥を見つけることや、
動的テスト実行中に故障を見つけることは、
プロダクトおよびプロダクトの開発担当者に対する非難と解釈されることがある。
確証バイアスと呼ばれる人の心理の要素は、持っている信念に合わない情報を受け入れがたくする。
例えば、開発担当者は、
コードは正しいという思い込みがあるので、確証バイアスにより、
コードが正しくないということを受け入れがたい。
確証バイアスに加えて、
他の認知バイアスがテストからの情報の理解または受け入れを困難にする場合がある。
さらに、テストからの情報は悪いニュースを含んでいることが多く、
悪いニュースをもたらす人は非難される傾向がある。
───『ISTQBテスト技術者資格制度Foundation Level シラバス日本語版 Version 2018V3.1.J03』より引用

確かにレビューは欠陥を見つけることが仕事ではあるのだけれど、
「間違い指摘反射」という言葉がある通り、人は間違いに目が行きがちになってしまう傾向がある。

開発担当者に対する非難と解釈されることがある。

これを減らすにはどうしたら良いか？

私はこの問題について真に驚くべき解決法を発見したが、ここに記すには余白が狭すぎる・・・ことはないので紹介します。

ソーイング・ビーとは

ソーイング・ビー（The Great British Sewing Bee[注釈 1]）は、イギリスのソーイング（裁縫）コンテスト番組。ラブ・プロダクション製作、BBC Two（シーズン6からはBBC One）放送。

イギリスで大人気の料理コンテスト番組『ブリティッシュベイクオフ』(The Great British Bake Off)のスピンオフ番組であり、同じ番組フォーマットを使用しているやで。

2013年にスタートし、現在シーズン7まで放送中。フランスやノルウェーなど欧米8カ国ではローカライズ版が放映されているねんて。

引用元:Wiki

https://ja.m.wikipedia.org/wiki/%E3%82%BD%E3%83%BC%E3%82%A4%E3%83%B3%E3%82%B0%E3%83%BB%E3%83%93%E3%83%BC

ソーイング・ビーにおけるレビューのやり方

①成果物の服全体を見て、まずは褒める(ことが多い)

②細かいところを見て指摘項目があれば指摘する。（次につながるような指摘）

ソーイングビーにおけるレビューのいいところは、
①他の参加者を下げて指摘することはない
②その人らしさを大切にする
ところにある。

例）「〇〇さんはできているのに君はできていないね」「こんな柄悪趣味だ」等は言わない

ただし、他の人と共通してできていないところは指摘する。同じように、他の人と共通してできているところも褒める。

例）「◯◯さんの時にも指摘したけれども」「◯◯さんも素晴らしかったけれど、こちらも甲乙つけ難い」とかは言う

ソーイング・ビーにおける役割分割

ソーイングビー

パトリック・ディゴリー(左)
イケメンテイラー。服の規定(柄合わせ、プリーツの幅、左右の襟の対称性)を主に担当する。油断するとプリーツの幅を定規で測りはじめる。

エズメ・ヤング(右)
服のデザインを主に担当する。お茶目。リボンは大きいのが好き。作った服が博物館に常設展示されている。

ジョー
司会者。フォローが上手い。詳しくは本編を見てほしい。

チームにおけるレビューのやり方

主に新入社員向けのプログラムレビューが多い。（そもそもレビュー文化がなかったので自分のできる範囲から始めている部分もあり。）

新入社員数名と、新入社員の教育チーム全員で新入社員の成果物（プログラム）をプロジェクターに映すなりデスクに集まってレビューを行う。

手順は以下の通り。

①動作を確認し、空文字やNULL入力で問題ないことを確認する

②できているところ、工夫がみられるところ、とりあえず一個は褒める

③「気になったところは…」「～をするともっと良くなりそう」という接頭語や接尾語を使い指摘する

実例:1〜10まで計算するシステムのコードレビュー

今回のプログラミング規定は以下の通りとする。

・クラス名の最初の文字は大文字にする
・変数名の最初の文字は小文字にする
・変数名は役割がわかりやすいように命名する
・繰り返しはfor又はwhileを利用する
・字下げはtabでおこなう。

システムの要件は以下の通り。

・メインメソッドをもつJavaクラス「Calc」を作成する
・Calcクラスに1~10までの計算をおこなうprivateなmethodを作成し、画面に表示させる。
・methodの引数は問わないが、変更に強いものが望ましい。

レビュー1:アルゴリズムが思いつかなかったソース

public class Calc {
    public static void main(String[] args) {
        keisan();
    }
    
    private void keisan() {
        System.out.println(55);
    }
}

コメント:

基本的な要件は満たしている。クラス名の最初は大文字になっているし、字下げも綺麗だ。

ただ、1〜10までを足した結果がダイレクトに書いてあるね。アルゴリズムが思いつかなかったのかな？

そういう時は、誰かに助けを求めてみるのもいいね。

メソッド名が日本語なの、可愛い！

細かいようだけれど、keisanは計算を担うmethodだから、表示まで行なうとmethodの役割を少しオーバーしてしまうように感じるね。

さっきも言ったけれど基本的な要件は満たしている。今後が楽しみだ。

レビュー2:お手本通りのソース

public class Calc {
  public static void main(String[] args) {
        System.out.println(this.keisanSum(10));
    }
    
    // 引数の値までの合計を計算する
    private keisanSum(int num) {
        int result = 0;   
      for (int i = 0; i <= num; i++) {
          result += i;
      }
     return result;
  }
}

コメント:

実によくできている、お手本通りのコードだと思う。要件を満たしているし、変化にも強い。

メソッドの名前にSumを入れることで、何の計算なのか分かりやすくなっているのも良い。

ただ残念なのが、字下げが整っていないね。折角コメントが書いてあるのに、これでは保守しにくいソースになってしまうのが惜しい。

あと気になるのはループの始まりが0からになっているところだね。1からじゃないかな？

全体的に、基本に忠実で工夫も見られる。とても考えられているコードだと思う。

レビュー3:褒めたいソース

public class Calc {
    public static void main(String[] args) {
        System.out.println(this.calcSum(10));
    }
    
    // 引数の値までの合計を計算する
    private calcSum(int num) {
        return num * ( num + 1 ) / 2;
    }
}

コメント:

目の付け所がすごくいいね。クラス名、メソッド名、字下げもきちんとできている。これなら変更にも強いし読みやすいね。

ここまでできているなら贅沢を言いたくなってしまうが、calcSumの引数が-2だと結果が-1になるのかな？

もちろん、これは要件に含まれていないから何の問題もない。

本当によくできていると思う。申し分ないセンスだ。

効果

①前向きで丁寧な言葉を意識するようになる

例）
脳内強気わい「コピペする能力ばっかり鍛えてんじゃねぇぞダボが」
脳内ゴリラわい「違う！パトリックはそんなこと言わない！」
レビューわい「自分で調べて必要な情報を選べるのは素晴らしいと思います。ただ、アルゴリズムを聞かれて答えられないのでは、今後の保守に影響してしまいますので、次からはアルゴリズムの理解にも気を配って欲しいです。」

②相手に”既にできているところ”を明確にすることで次もできるようになる

プログラムだと「字下げが綺麗にできている」「変数名・処理名が分かりやすい」「コメントが付いているからわかりやすい」、
ドキュメントだと「段落が綺麗に分かれている」「適切に改行や余白が使われていて読みやすい」「色遣いがいい」「フォントが可愛い」‥

褒められているところは他の人も意識するようになる。不思議と、指摘されているところにも意識が向きやすくなる。

③「この人は安全な人だ」という立ち位置が作れる

”できるところは褒めてくれる人”という立ち位置が実際一番おいしい。

ただ、毎度褒めるから始めるのではなく、3回目くらいからは指摘から入るようにする。1回目が大事なのである。

まとめ

いかがでしたか？

レビューするときは

①できているところを明確に褒める

②その人の考え方(コード)を尊重したレビューにする

③他アゲ・他サゲをしない

ってことで、ソーイング・ビーを観て実践してみてはいかがでしょうか。私はやってます。

簡単に図示すると以下の感じ。

指摘ばかりでぴえん。

できているところをあえて言うことで、指摘を前向きに捉えられるようになる(かもしれない)。

最後に

本日うちの娘が5歳になりました。ありがとう世界。

そんなわけで明日は、猫野郎ことちゅ〜るヤスハルさんです。私の次の人いっつも大物すぎません？

おあとがよろしいようで。

参考

■ ソーイング・ビー

NHK公式

アマプラ見放題もあります。（字幕版だけど言ってることはほぼ同じだと思います）

https://www.amazon.co.jp/gp/video/detail/B08KBLCK1L/ref=atv_dp_share_cu_r

■ JSTQBシラバス

■ 煉獄さん式子育て

よく似た事例。心を燃やせ。

12/23 追記

nemorine様に当記事をご紹介に預かりました。謝謝茄子。

大好評発売中の、実践ソフトウェアエンジニアリングにも同じようなレビューの話があるようです。買わなきゃ(使命感

この記事が気に入ったらサポートをしてみませんか？