ホーム » ソフトウェア品質 » イベント » 【JaSST13Tokyoメモ】 「過失に着目した欠陥のモデリング~バグ分析はなぜうまく行かないのか?~」

【JaSST13Tokyoメモ】 「過失に着目した欠陥のモデリング~バグ分析はなぜうまく行かないのか?~」

だいぶ遅くなってしまい、かなり時期を外した感がありますが、
2013年1月30日~31日に行われたJaSST13Tokyoのセッションに参加した際のメモをまとめてみました。

当日の講演資料は以下のサイトで公開しているようです。
http://jasst.jp/symposium/jasst13tokyo/pdf/C4.pdf

不具合分析

不具合分析は多くの組織で行なわれているが、効果が出ていないのではないか。 近年、ソフトウェア開発は大規模化、複雑化している。

  • 一人ですべてを把握できない
  • 全て範囲をテストできない
  • 複雑度の増加
  • 組み合わせ数の爆発

そういった中で、バグとどのように立ち向かう、または扱っていく必要があるか。

「ワナ」

「ワナ」にはまることを繰り返さないようにするために、モデル化が必要

  • 「開発者が埋め込んでしまう「ワナ」→開発プロセスで何があったのか?
  • 品質担当者が見逃してしまう「ワナ」→テスト工程で何があったのか?

なぜ不具合分析がうまくいかない理由

バグ分析の失敗要因

  • バグ分析の目的が明確でない
  • バグ票に必要な情報がない
  • 事実認識が甘すぎる
  • なぜなぜ分析で論理の飛躍がある
  • 失敗事例が共有されていない

なぜなぜ分析がなぜ失敗するのか?

  • 分析することにどんな意味があるか理解していない。 (なぜ、なぜなぜ分析はなぜ5回なのか?4回や6回でない理由は?)
  • なぜなぜ分析結果を受け取る人の喜びそうな分析結果にしてしまう

なぜなぜ分析ではなく、なになに分析を行なう。

  • 「なぜなぜ分析」と「なになに分析」の違い
    •  なぜなぜ分析:人の責任と現象を同時に追求
    •  なになに分析:人と現象を分離させている
  • 「なになに」は、現象そのものに好奇心があることの強調する

バグの話をしていると暗い雰囲気になる

  • 暗くなるように分析している限り良い方向にはならない
  • ニュアンスが大きい

バグは資産

バグは、組織にとって資産である。

  • 同じバグは、他のプロジェクトなどで再現できない
  • バグは、保存し、共有し、語りつぐべき資産である
  • ワクワクして獲得するものである

アンチパターン

分析におけるアンチパターン

  • 現象と原因がごっちゃになっている
  • 「うっかり」、「きちんとできない」 etc その時何があったか、を分析していない
  • 決め付け、犯人探しになっている 他人ごとだったり、根本解決にならない
  • 「設計の問題」 設計でどんな問題が起きているか踏み込んで考える必要がある
  • テスト漏れ 何がどう漏れたのか? テスト網羅はどんな状態であったのか?

対策におけるアンチパターン

  • チェックリストに項目追加
  • 全体会議で周知する 継続した周知は無理。異動してきた人や新人の対応はどうするのか?
  • 教育や研修 誰に対して、どのような教育をすべきなのかを考える必要がある。
  • 文化の醸成、属人性の排除、適した人をメンバに追加 そもそも、コントロールできるか?

QA部門について

QAが指摘できる内容は少ない。指摘のレベルも深刻なものは多くない。

  • 品質技術が高いとはどういうことか?
  • どのようなQAならリスペクトされるのか?

QA部門が上のことを考える必要がある。 技術のウデとしてどうるべきか

対策編

どのようなバグを減らしたいのか。 →バグ分析の目的の共有、合意、優先順位付け 事実をヒアリングでとらえる 原因追求は、なぜなぜ分析 対策は、なになに分析 自責と他責は分けて考え、多くの仮説を作る 視点を変えていく →バグによってかえる バグの水平展開(同僚や製品グループへ) →必ずしも全社単位でなくても良い なぜなぜ分析 →なぜの間の「線の意味」を考える 「なぜ」でないことがある 本来、「原因→結果」となるが、「なぜ」でないとループしてしまう うまくできていないところはループする →「結果→原因」になっていないから 「欠陥がどいう経緯で作られたか?」を考える。

  • 思考の過程に「過失」があった
  • ソフトの欠陥は、必ず人間の副産物
  • 「人間がどう思考をミスったか?」「バグが入り込む余地があったか?」
  • 欠陥とバグ(過失)をセットで。

ソフトウェアの故障モード

  • バグの入りやすさ、誤りの入りやすさ

「だれでも間違える」という認識が重要

  • 「優れたエンジニアでも吸い込まれるようにまちがえてしまうのはなぜか?」を考える
  • 「不具合はだれでも起きた」ということを合意する。 どんなに気をつけていてもミスしてしまうような ワナがある。
  • そのワナを明らかにする ために「なになに分析」を行なう。
  • 間違えた人を、「ワナのありかを提供してくれるありがたい人」として扱えるようにする必要がある。
  • 全員がワナに共感することが必要
  • だれでも間違えるところを一緒に探しに行こう、という姿勢が大事。
  • 個人による誤りではなく、人間一般のあやまりをさあす。
  • 欠陥は過失 →誰々の過失、ではない。 →そこにいる人全員が共感してあたかう必要がある
  • ワナを公開しないと対策にならない
  • バグを前提とした社会 →バグが有ることを受け入れない
  • 憎むべきは「誤った人」ではなく、「バグそのもの」
  • バグが生まれる経緯の過失を公開する →落とし穴にはまらないようにする
  • バグの種類と、どう誤るのかをセットで覚える パターンとして自分たちに蓄積していく バグそのものをシェアする。
  • どのように吸い込まれるかを覚える

欠陥モデル

欠陥モデルは、欠陥知識の移転と理解が早くなる。モデル(絵)でバグの状態を伝える →欠陥知識を伝えることが難しくなっているところをわかりやすく伝える。

  • 誘発因子(ワナ)
  • 過失因子(引っかかる人間の要素)
  • 増幅因子(拡大した理由)
  • 欠陥
  • 表出現象

誘発因子をレビューやテストで引っ掛ける努力をする

過失因子で共感しやすくする

抽象度をあげると多くの範囲で伝えられる
→自分たちで抽象度をきめて移転の範囲をきめる

ご参考

プロジェクトファーブル http://aster.or.jp/business.html#fabre

原さんの「なになに」はもう一度お聞きしたい・・・(ぼそ

広告

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中