QConでのIBM細川氏の品質管理と欠陥工学のセッションのまとめ

十級呪物disktnk @disktnk

QConでのIBM細川氏の品質管理と欠陥工学のセッションのまとめを、テキトーにつぶやく。やり方に関する賛否はともかく、高い品質を保つという視点は常に意識しないと死が待っているので、ちゃんと証跡を残すという意味でぐだぐだと。 #qualityandtest

十級呪物disktnk @disktnk

「ちゃんとしたレビューとやっているか」という時の"ちゃんと"とはどういう意味なのか。そもそも"ちゃんとした"レビューで何が得られるのか、を考える。得られるものの大半は疲労感と、大量のバグ？ じゃあバグがいっぱい見つかったらそこで完了なのか。 #qualityandtest

十級呪物disktnk @disktnk

レビューで欠陥(バグ、間違い)を見逃しやすい観点を考える。1. 頭の中で間違った文章を勝手に補足してしまう。例えば、「みさなん、おはようごさいます」という文章があった時、間違いがあっても読めてしまう。この脳の補完機能をオフにしないとならない。 #qualityandtest

十級呪物disktnk @disktnk

2. 1つ目の欠陥が見つかった時点で満足してしまう。実際のレビューでは、見つけた個数が増える度に満足度が増してきてしまう。例えばあるドキュメントをレビューする時、最初のページからレビューする理由はないのに、最初から読み合わせする例は多い。 #qualityandtest

十級呪物disktnk @disktnk

3. 2の逆で、全部が欠陥に見えてしまうケース。ある一部分がものすごい欠陥だらけだった場合などは、他の(簡単な)部分でも必要以上に慎重になり、疲労感が増す。 4. 声に出さない。例えばコメント分を声に出して読み上げるだけでいろいろ発見できる。 #qualityandtest

十級呪物disktnk @disktnk

5. 自分の経験により欠陥を補完してしまう。これは1.に似ている。例えば日本語の簡単なミスであればあまり気づかないのに、英語になるとスペルミスをよく発見できたりする。この経験をよい方向に活かそうとすることは、みんなやっていると思う。 #qualityandtest

十級呪物disktnk @disktnk

6. 時間制限などのプレッシャー。レビュー時間というのは大体が限られていて、レビュー時間をレビュー対象のソースコードの行数で割ると、大体がなかなかシビアな時間になる。また「絶対にミスするな」みたいな心理的プレッシャーを与えるのもよくない。 #qualityandtest

十級呪物disktnk @disktnk

次に、なぜ一般的にレビューに無駄な疲労感が漂い、どこかでレビューをめんどくさがるのか。1. レビュー計画をたてるのが面倒。開発工数や開発計画の見積もりに比べて、レビュー工数を見積りはあいまいな場合が多い。 #qualityandtest

十級呪物disktnk @disktnk

とはいうものの、レビューに対するノウハウはどこも持っていて、ようはその手法に納得感があるかどうか。QA計画を立てる手法の一つにFear Based Inspection(FBI)というのがある。懸念ベースからのレビュー。FBIってカッコいいね。 #qualityandtest

十級呪物disktnk @disktnk

レビュー工数の見積もりに関連してレビューをいつするのかというのも論点の1つ。2時間に1回のレビューを挟んだ例に比べて、15分に1回のレビューを挟んだ方が、品質が2.8倍になったらしい。この場合の品質って？って思ったけど、詳しい説明はなかったと思う。 #qualityandtest

十級呪物disktnk @disktnk

15分に1回とかはさておき、はじめのうちにできるレビューはとことん最初からやっておいた方がいい。というのは、多くの場合終盤になってスケジュールがギリギリになり、レビューする時間なんてないから。どうせやるならできる内からやっておいた方がよい。 #qualityandtest

十級呪物disktnk @disktnk

レビューを嫌う理由2として、レビューで欠陥を見逃す理由にもあったけど、心理的プレッシャー。例えば、レビュイーは「批判されたくない」と思うのは当たり前なので、そういう雰囲気を作らないのもレビュワーの大切な役割。実はそういう人的ミスは多い。 #qualityandtest

十級呪物disktnk @disktnk

では、なぜレビューが必要とされるのか。そもそも、「レビューで品質が上がる」というのは大嘘。そんなこと言っている人がいたら信用しない方がいいby細川氏。レビューで見つかるのは悪いところのみ。レビューによって見つかった欠陥を改善することで品質が上がる。 #qualityandtest

十級呪物disktnk @disktnk

ペアプロやTDDを完全に行った場合のコストと、100%インスペクションレビューを行った場合のコストは同等という研究がある。ペアプロ＋TDDを完璧に行うのと、インスペクションレビューを計画立ててやるのと、どちらがいいかはあなた次第。 #qualityandtest

十級呪物disktnk @disktnk

どうでもいいけど、インスペクションって文書型レビューって思ってたけど、正確には「成果物を実際に動作させずに行う検証」って意味だったんですね。＞ インスペクション - Wikipedia http://bit.ly/gTie5F

十級呪物disktnk @disktnk

レビューに必要な理由は、安全性の向上。重大なトラブル(過激な例だと人が死ぬ)は突然やってくるのではなく、起源や環境→人的過失→不安全な行動・状態→…とドミノ倒しで発生する。そこで「不安全な行動・状態」というドミノを取り除く手段としてレビューを行う。 #qualityandtest

十級呪物disktnk @disktnk

参考。別にかの有名な1:29:300の法則はセッション内には出てこなかったけど。 ＞ ハインリッヒの法則 - Wikipedia http://bit.ly/f7oUP4

十級呪物disktnk @disktnk

また管理という視点での「品質検査」として、レビューが必要の場合も。要件定義・設計・開発・UT・IT・STという有名なV字モデルも、関連会社や外注が混ざってくると、そのフェーズ毎に検収があり、そこにレビューが必要なる。 #qualityandtest

十級呪物disktnk @disktnk

ちなみに、このV字モデルのフェーズ毎に発注＆受注が発生する様子を、「点線V字モデル」と細川氏は読んでいた。資料(http://qcontokyo.com/pdf/ibm_nobuhirohosokawa.pdf )にもそう書いてあるけど、オリジナルらしい。