-
akiyama924
- 5540
- 23
- 2
- 13
-
- いいね！13
あきやま🍠
@akiyama924
本日午前中のSQiP研究会特別講義は日本アイ・ビー・エム株式会社の原佑貴子さんです。はらゆきさんの愛称の方が有名でしょうか。講義タイトルは「レビューを失敗させるコツ」です。
2016-01-15 09:54:55
あきやま🍠
@akiyama924
原さん「2004年から第三者品質検証組織（QIチーム）に所属してインスペクションなどしております。 今日は中央線遅延の影響か？まだもと上司の細川が来ておりませんので大いにdisっていきたいと思います。www
2016-01-15 10:09:18
あきやま🍠
@akiyama924
原さん「レビューをすると品質が上がると思われるかた挙手をお願いします。けっこういらっしゃいますね。 でもレビューをしただけでは問題点を指摘出来るだけです。
2016-01-15 10:11:54
あきやま🍠
@akiyama924
原さん「ギルブ（Tom Gilb）が『IBMでは利益に繋がらない手法は消えていくよね。レビューは40年も続いているよ。レビューをやれば儲かるということです』と言っていました。そうかーと思いました。
2016-01-15 10:18:13
あきやま🍠
@akiyama924
原さん「レビューアの個人プレチェックの過程で気が付いた誤字などの細かい指摘についてはレビュー会の前に相手に直接伝えて直してもらえばよい。 レビュー会では議論が必要な重要な欠陥についてディスカッションするとよい。
2016-01-15 10:23:26
あきやま🍠
@akiyama924
原さん「状況や目的に応じて色々なレビュー手法があります。フォーマル・インスペクション、2パーソン・インスペクション、Nフォールド・レビュー、ウォークスルー、パスアラウンドなどなど。 状況や目的に応じて選択手法、実施時期、実施人数、検証項目、後続活動を適切に変えていきましょう。
2016-01-15 10:30:48
あきやま🍠
@akiyama924
原さん「レビュー会は4人以下がよい。レビュー会では作成者がレビュー対象を説明してはならない！ Reader 役割の人が記述を解釈して自分の言葉で言い換えて説明する。 それによって作成者の意図と合っているか確認できる。
2016-01-15 10:34:28
あきやま🍠
@akiyama924
原さん「レビュー会では、欠陥を検出する事のみに集中すること。 何故欠陥を作り込んだのかや、欠陥にどう対処するかはレビュー会では議論しない。
2016-01-15 10:36:50
あきやま🍠
@akiyama924
原さん「バグの種類の傾向は組織によって変わります。教育の違いの結果かもしれません。 もし同じ傾向の欠陥が三度現れたら『そろそろ学習しましょうよ』と指摘します。仏の顔も三度です。
2016-01-15 10:41:45
あきやま🍠
@akiyama924
原さん「中国語では日本語と以上・以下の意味が違う落とし穴があります。その値を含むかどうかです。 そういう落とし穴を知っておきましょう。
2016-01-15 10:45:13
あきやま🍠
@akiyama924
原さん「仕様書やソースコードのコメントにある、『暫定、対応、とりあえず、一旦、保留、別途、検討、はず、かも、苦肉、姑息』といったNGワードを自動的に拾い上げるツールを作っています。 NG ワードが書いてあることが悪いのでは無く、その情報を拾い上げる事が大切です。
2016-01-15 10:51:00
あきやま🍠
@akiyama924
原さん「最後に一度だけドカンと大きくレビューをするよりも、何度も小まめに中間レビューをしたほうがよい。最初は抵抗がありましたがやれば良さを、納得してもらえます。 最終レビューはもちろん必要です。
2016-01-15 10:54:55
あきやま🍠
@akiyama924
原さんが、IBMのQI方法を説明しています。 手元の資料に入っていませんので、つだりません。 興味のある方は直接はらゆきさんに聞いてみましょう。
2016-01-15 11:11:40
あきやま🍠
@akiyama924
原さん「レビューをやりっ放しにしないことが重要です。 レビューで気が付いたことを記録して記憶に残してください。 そして別のレビュー会のときに『あの時こういうことがあったから今回の似たところに同じ欠陥があるかもしれないよなあ』とレビューの経験・気づきを使い回せるように。
2016-01-15 11:18:13
あきやま🍠
@akiyama924
原さん「バグに偏りがあることをフォールトプローンといいます。レビュー対象の二割のところに、欠陥数の八割が偏在するという調査結果もあります。
2016-01-15 11:22:28
あきやま🍠
@akiyama924
原さん「そうすれば、ソースコードがたくさんある場合に、それぞれのソースコードがベン図のどこに当てはまるのか調べることでソースコードの状況がどうなっているかの仮説を立てることができる。
2016-01-15 11:29:49
あきやま🍠
@akiyama924
原さん「『AまたはBでない』という文は2つの解釈ができます。 A or (not B) not ( A or B) です。 この辺のレビューまでは自動化を考えられますね。 自動化を出来る欠陥のタイプが増えれば人間は保守性や堅牢性などの自動化が困難な欠陥の検出に集中できます。
2016-01-15 11:42:35
あきやま🍠
@akiyama924
原さん「IBMの研究所では、欠陥を自動検出するツールを開発し、使い方のノウハウ指導と共に販売しております。ご興味のある人はそちらにお問い合わせください。 ツールが対応するチェックルールは日々成長中です。 私もこういうの出来るようになりませんか？と研究所にご相談しています。
2016-01-15 11:51:49