「レビュー」をもっとうまくやってみる - DevLOVE関西#93
DevLOVE関西主催の勉強会にまたまた参加してみました。というわけで遅くなりましたが書き起こしを。
個人的なメモかつだいぶ忘れてしまっている内容なので変なところも多々あると思いますがご了承ください。
シナリオレビューの紹介
登壇者:森崎修司(@smorisaki)
名古屋大学 大学院情報科学研究科 准教授
レビューの効果
テストのタイミングで確認して修正するとなると遅い
なのでレビューのタイミングで確認したほうがもちろんいいよね
ただし…
テストの工数が削減できるという観点のレビューでないと意味ない
じゃあどういうレビュー内容がテストの工数を削減できるのか?
レビューのアンチパターン
- 一部だけしか見ない
インデントはスペース4つで統一してください。とか - 人格攻撃
こんなのもわからないなんてエンジニアとしてどうなんですか?とか - 説明会とか進行がおかしい
ではこれから説明会レビュー会を始めます。お手元の資料を…とか
ではどうしたらいいか
レビューの準備
レビューの準備に必要なことは、レビュー前に適切な目的を設定し合意しておくということ
具体的には「問題種別の抽出する」と「検出シナリオを決めておく」(後述)
これらをみんなで合意することが一番大事!
レビューによる問題の検出
事前に設定した問題種別に沿って検出する
→どこをどうチェックしたかは予めチェックリストを作ることで明らかにしておく
レビュー技法
Defect-based reading Perspective-based reading
Defect-based readingとは
漏れ・曖昧・誤りの3つの観点でレビューを実施する技法
ちなみに漏れ(一番難しい)
漏れ
検討漏れ
→そもそも検討ができていない場合がある
あなたにとっての「常識」とは?
→使う人にとっての常識を定義する
ドキュメントを読んでしまうと先入観が入ってしまう
→ドキュメントを読む前にソフトウェアのあるべき姿を想像して望む曖昧
読み手にとって複数の解釈ができてしまうものは、読み手の想定や定義が必要となる誤り
外部や内部で定義されたドキュメントやコードの不整合が原因であることが多い
Perspective-based reading
そもそもテスターはテストを実施できるのか?
のようににテスター・発注者・利用部門・プログラマそれぞれの立場で考えてレビューを実施する技法
シナリオレビュー
レビューの目的を共通認識として持つ
レビューの効果に応じて濃淡をつける
指摘は網羅性を確認する
(この辺駆け足だったのでメモできず…)
ワークショップ
その1
http://www.miyazaki-ac.jp/?action=cabinet_action_main_download&block_id=100&room_id=1&cabinet_id=1&file_id=1140&upload_id=3180
これをレビューして問題になりそうな箇所を5つ挙げて下さい。
問題種別の設定方法
トップダウンの例
「グローバルで使われる案件ワークフローシステム」について考えてみる
→どこが一番価値のある品質か
→システムが停止しては困る
→大容量ファイルを処理できる
→日次処理に影響が出ないようにする
↓
システムの停止の際に原因が分かるようにするとか
大容量ファイルは処理時間がどれくらい掛かるかとか複数アクセスされた場合どうなるかとか
↓
つまりレビューで何を見るべきか、また何が大事かはそのシステムにとっての価値で決める
それを決めるのがシナリオである
ワークショップ
その2
http://www.city.matsusaka.mie.jp/www/contents/1340350276686/files/120188-3.pdf
このシステムにとっての価値を順位が高いものから5つ挙げて下さい。
まとめ
ワークショップは3人1組でやったのですが、その1ではレビューの観点がバラバラだったのが、その2では価値順位も含め、かなり近しい観点にまとまりました。
その価値順位に対してお互いが合意してからレビューをすれば、かなりいいレビューとなりそうです。
あとレビュー本すごく良さそうでした。
なぜ重大な問題を見逃すのか?間違いだらけの設計レビュー改訂版(日経BP Next ICT選書)
- 作者: 森崎修司
- 出版社/メーカー: 日経BP社
- 発売日: 2015/10/06
- メディア: Kindle版
- この商品を含むブログを見る