どしろうと製作所:WebLog

どしろうと製作所のBlogバージョンです。
「どしろうと製作所」のHPの記載内容とはあまり関係無いです。
気が向いたときのみ更新します。
「なぜ重大な問題を見逃すのか? 間違いだらけの設計レビュー」でレビューの勉強会
関西ソフトウェアテストの勉強会(WARAI)で、「レビュー」の勉強会についてワークを含めて議論した際の内容です。勉強会内では著者の森崎先生に30分ほどSkype参加していただきました。(感謝です!)
そのSkypeディスカッション内での議論内容について紹介します。
■勉強会でのディスカッション内容のメモ

さて、最初に紹介した関西ソフトウェアテストの勉強会(WARAI)では、以下のような議論をしました。こちらも、コーヒー本での疑問点を解決するのに役立つかもしれませんので、簡単に紹介しておきます。

【背景】
該当の勉強会では、1章と2章を中心に勉強しましたので、議論範囲はそちらのみです。
なお、少々時間がたった段階で自分の記憶と解釈部分を頼りに記載しておりますので、細かい部分で想定が異なっている可能性がありますのでご了承ください。


【以下、質疑応答内容】
▼Q.コーヒー本は書籍として整理するためか「誤りの検出」に絞ったレビュー方法を記載しているようですが、「教育」や「情報共有」という目的もレビューにはあると考えますが…

△A.教育は別途行ったほうが効果的と考えています。レビューのやり方や考え方を教えるのであれば、レビュー終了後に居残り形式で個別に教えるほうが効果的です。情報共有は、バランス次第ですがレビューに混ぜてもらっても良いです。


▼Q.「リーダー」が「問題種別」を選定、「レビュー会議を取りまとめ」する人になっているのですが、その人が何でも出来る人である必要性が発生しませんか?

△A.元々は「問題種別」を選定する人と全体やレビュー会議をまとめる人は別の人にしていたのですが、書籍の都合上同一の「リーダー」という役割の表現にしてしまっております。必要技術が異なりますので、ロールとしては別の人が行っても良いです。


▼Q.P52「問題種別の選定」について、これがズレているとレビュー全体がダメになるのでは…?

△A.ポイントが完全にズレた「問題種別」を用いてレビューをした場合と、全く「問題種別」を出していない場合のレビューと同程度だろうと考えています。組織内のそれなりのエンジニアが考えた内容であれば効果が出るはずです。


▼Q.「問題種別」について、これを出すことが出来るのは成熟した組織では…?

△A.過去の不具合や指摘内容を知識として蓄積している場合や、ドメイン知識を持つ人が「問題種別」を出した方がより効果は出ますが、近いドメイン、部分で関連した「問題種別」を活用することでも効果は出るはずです。


▼Q.1つ前と近い質問ですが、「問題項目の選定」の検討を行うためには開発メンバーにスーパーマンがいる前提にならないですか?あと、ベテランや問題種別を選定できる人に問題種別を元にレビューしてもらうのは効果的でしょうか?

△A.その通りですが、組織には相対的にスーパーマンとなる人がいるはずですので、そのような人の知見を活用することになります。その「相対的なスーパーマン」の人には、自由にレビューしてもらった方が良いと考えますが、一部のレビューを他人に任せることで、スーパーマンな人が全体としてより効果的な指摘を出すことが出来ると考えております。

※あわせて議論した内容:相対的なスーパーマンは大抵忙しく、ボトルネックになると思われます。そのスーパーマンの知見の一部として「問題種別⇒シナリオ」を出して、「他の人が見る」ことにより、スーパーマンなベテランの方は自由に見てもらって意見を出してもらう…というコトができる…という意見も有りました。


▼Q.今回のワークでは知らないドメインに対して「問題種別の選定」を行いましたが、今回は「プロダクトが顧客に対して(賠償や損害が発生するような)迷惑をかける可能性」、「開発プロセスとして後工程で大きな手戻りに繋がるような項目」という方向から「問題種別」項目を辿って出すような案が出てきました。
 <参考図>
※クリックで大きな図へ
質問ねたー

△A.レビューの目的が「コスト効果を高める、重大な問題の検出」という点で考えると、その考え方で正しいです。


▼Q.「漏れ⇒曖昧⇒誤り」の順番で検出するとありましたが、文書を構成するという指摘は無いのですか?文書構成修正後にもう一度レビューをして指摘を行った方が効果的だったりしませんか?

△A.感覚的ですが、より価値が高いのは「文書構成を修正してもらう」よりも「指摘項目を出す」ことであると考えています。同じ人が時間をかけて文書を修正しても、時間をかけたわりに大きく改善しない可能性があることからの意見です。

※なお、背景としては、文書完成後の1発レビューで文書構成を修正するか?という条件となります。同一文書に対して、初期から小さくレビューを繰り返す場合には、前半で「文書構成を修正」する指摘は非常に効果が有ります。


▼Q.P64の「漏れ」の見つけ方が感覚的ではないでしょうか?「まずは対象を考えて、想像してから読むんだよ、そうしたら分かるだろ?」というスピリチュアルな雰囲気が有りました。

△A.「漏れ」を見つけるには、レビュー対象や該当文書に対する知識が無い方が効果があると考えております。想像から「こんな対象だろう」というイメージを行い、違う部分に「漏れ」がある可能性が含まれます。対象(開発対象もしくはレビュー対象の文書)を知らないフレッシュな状態が「漏れ」発見には効果があるという意見です。逆に、対象文書に対して理解が進むにつれて、「曖昧」や「誤り」を見つける作業が効果的になっていきます。
 

覚えている限りの内容は以上になります。

実際の現場での状況や経験をベースにした議論が非常に参考となった勉強会でした。
森崎先生、ありがとうございました!
| コミュニティ | 22:28 | comments(0) | - |









   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
+ SELECTED ENTRIES
+ RECENT COMMENTS
+ CATEGORIES
+ ARCHIVES
+ LINKS
+ PROFILE
+ OTHERS
このページの先頭へ