JaSST'19 Niigata が長岡で開催されたので参加してきました。 お堅い空気のイベント久しぶりでした。
S1) 基調講演
レビューは静的なテストの１つであるという所はなるほどなぁと思いました。最近レビューしてても意味あるのかいまいち確信無いままやりがちだったのでちょっと気を引き締めることができました。
レビューの目的
人間は間違えるんです。でも間違いが少ないものを作らなければならないという明らかに矛盾した作業を強いられています。
レビューの前は、関係者の頭の中ではイメージが似てるんだけどちょっとずつ違う状態だったのを レビューが終わった時にイメージの認識合わせができていることがレビューの目的のひとつです。
「レビュー対象や背景を理解」し、その上で「問題点や認識違いの検出」を行い、関係者による認識を共有することをレビューでやっていることとのことでした。なるほど。
「あの人しか知らない」状況を減らすことが組織としてもあるべき姿ですね。
レビューのキキメを得るために
- 無駄なレビューをしない
- 出来るだけリアルタイムフィードバックに近づける
- 作ってからレビューして結果を反映のサイクルを短く
- レビュー対象は小さく、フィードバックを得やすいように
- 出来るだけリアルタイムフィードバックに近づける
- ぼんやりレビューをしない
- 人間特性を考慮してレビューのやり方を設計する
- A さんはこの観点で見て、B さんは別の観点で見て、的な感じ -> みんなが同じ観点で見ても指摘が重複するので意味が薄れるし、「他の人が見てるから自分がちょっとくらい手を抜いても良いだろう」と思ってしまいがち
- 人間特性を考慮してレビューのやり方を設計する
- レビューをやりっぱなしにしない
- 指摘したこと、それを反映したことを確認する
時間は大事なリソースです。何人かで寄ってたかってだらだらやってレビューした気になるよりも、集中して効果的なレビューができるようにしたいものです。
対象の質が悪いとレビューのパフォーマンスが落ちる
確かにその通りです。誤字脱字あるとそればっかりに目がいってしまって、本質的なレビューができません。レビュー開始基準を設けてそれを満たさないとレビューしないのは良いことかもしれません。
コードもそうで、意味不明な処理のまとまりとか可読性が悪いとレビューに時間がかかると言うかあんまり見たいとは思いませんからね。気をつけよう。
人間特性
レビューする側もされる側も人間なので、正論を投げ合うのと面倒だなと思うものです。不具合の指摘も「見つけたから直せ」だと正しくてもちょっと感情的になります。建設的にできれば良いですよね。
こんな感じで意識すると良さそうです。
- レビュアーが行うのはレビューイに対する支援
- 粗探しではなく、より良い成果物を作成する為に行う
- 可能な限り相手が受け取りやすいようにコメントする(やらされる -> 自分から進んでやるように)
- 断定的な物言いをしない
- お互いバックグラウンドが違う
- e.g. 「もしかすると XX かもしれないと私が感じたので確認してもらえます？」
- 手段よりも事実や目的にフォーカスする
S2) 事例紹介
いしばしさんの発表でした。重厚な SIer での取り組みをお話ししてくれました。
ソフトウェア信頼度成長曲線とか書いてましたけど、集計するのが大変でそれ専用の人がいないとツラくて、燃えてるプロジェクトに参画していると特に「こんな集計するよりもやることない？」とか思い出し胸が熱くなりました。
とは言え、プロジェクトの状況を客観的に計測する事は大事で、何を使うかはさておき、「うまくいってる」「ちょっとまずそう」「ヤバイ」がわかるようにしておくのは必要な気がしました。計測する為の情報を出したりこねくり回して数値化するのがツライんですけどね...
S3) 事例紹介
ウォーターセルの松井さんの発表で、レビューも組み込んだ開発フローをお話ししてくれました。
わかりみしかない発表で、この辺は組織自体を変えないと上手くいかないし、成功するかは組織による感じがするので銀の弾丸ではないとは思いますが、上手くまわれば多大な効果を発揮するやり方だと思います。
中でも
- 自分のことは棚に上げてレビューする
- 忖度しない
- わからないことは遠慮しないで聞く
- 指摘は具体的に
- ふわっとした指摘はお互い疲弊する
この辺りは頷くしかありませんでした。
ウォーターセルさんみたいに組織内で何でも言える空気って割と当たり前に考えてましたけど、そうでもない組織も多いんだろうな...。思ってるのは自分だけ、みたいにならないようにしよう。
フロントエンドの自動テストをどうやってるか聞きたかったけど、今回のお題(レビュー)とはちょっと離れてたので自重しました。いつか聞きたい。
まとめ
何となくやってた / 依頼してたレビューへの姿勢が少し正された気がします。 自分がどんなコメントをもらうか分析して不足している観点に気づいたり、他の人がどんなコメントしているか分析して自分が不足している観点に気づければ個人として成長できるかなーと思えた時間でした。計測してみよう。
QA 的な仕事をしてた時は、
- 現場もレビューやテストに対して関心を持ち、開発サイクルに組み込む
- みんな設計者であり開発者でもあり QA である
- QA の言う事を絶対に聞く
- 失敗の全ては QA が負う
- スケジュールが遅れそうでも QA が No と言ったらリリースできない
のどちらかでないとうまく回らない気がしていましたが、現場がちょっとずつ QA への意識を持っている感じがして良い流れだと思っています。お互いの立場だけから意見言っても「現実わかってんの？」と言われる事はわかりきってますからね。
レビューをした人が失敗に対して責任を持つのではなく、失敗した時のフォローを組織で行う空気にしていかないとこの辺りの文化はうまく回らないと思いました。QA が強すぎるとレビューも萎縮しちゃって受け身になっちゃいますよね。目的はレビューを通すことではなくて、作ったものをリリースして対価を頂くことですから、目的を履き違えちゃいけない。
今回参加して良かったです。関係者の皆様お疲れ様でした。
