右脳系エンジニアのブログ

エンジニアとしての生き方のプロトタイピング、新しい社会のプロトタイプづくりをしています。

InfoTalk#38 に参加してきました。

ソフトウェアテスト

InfoTalkに参加してきたので、遅ばせながらレポートを。

InfoTalk - 産業技術大学院大学
http://pk.aiit.ac.jp/index.php?InfoTalk


IBMの細川さんによる講演でした。

実際にレビューの実践などをしていただいたのですが、
そのあたりの情報を無闇矢鱈と書くのはよろしく無いので、
自分の感想や調べたことがベースになります。

欠陥を先送りにしないためのレビュー

レビューの重要性は「欠陥を先送りにしないために問題を発見すること」です。

例えば要件定義段階における定義の誤りや明快さの欠如は、
コーディングにおけるミスにつながります。

こうした問題の原因を早い段階で「発見することが出来る」のがレビューだと
いうような趣旨だったと思います。

あと、細川さんお気に入りのフレーズっぽいので紹介しておきますが
「品質は上流から作り込むと言われていますが、あれは嘘です」
ということを過去の講演も含めよくおっしゃっています。

もともとは「上流だけやっていればOKという意味ではなく、上流で起きた問題は上流で、あとのそれぞれのフェーズで起きた問題はそれぞれのフェーズで対処すべし」というような趣旨の内容が、翻訳される過程で誤解を生みやすい表現に変わってしまったということらしいです。

品質にまつわる統計的な調査結果

講演では、さまざまな統計調査のデータを紹介してくださっていました。

注文中で中身まで見れていないんですが、
Scott W. ambler氏
Wheller David氏
の研究結果などを引用していました。
どこかから引っ張ってこれるかなぁーとか思ってたんですが、
そんな単純なものでもなかったため、名前だけの紹介とさせてください。

そうい様々なデータを紹介してもらった中で、ソースが不確定ですが印象に残ったデータを紹介していきます。

COQとCMM

Cost Of Quality（COQ）とは
ざっくりいうと「品質が高くない製品をつくるときにかかる費用ではない費用」を指します。
具体的には

  • 要件定義
  • テスト
  • コードの修正
  • 再テスト
  • 修正にともなう運用の変更

などがこれにふくまれます。
(参考：Cost Of Quality (COQ) - ASQ - Learn About Quality - Overview
http://asq.org/learn-about-quality/cost-of-quality/overview/overview.html)

これと、成熟度モデルのCMMのレベルを照らし合わせると、以下のような結果になるそうです。
CMM1の場合：Production Costのうち20%がCoQ
CMM5の場合：Production Costのうち2.5%がCoQ
（要出典）

何が興味深いかというと、COQにしっかり準備してコストをかけているはずのCMM5のほうが、
CMM1よりもはるかにCOQの比率が少ないということです。
要するに、CMM5のようにきっちりとプロセスを定義しながらそれぞれのフェーズで
しっかりと欠陥を取り除いていくほうが、結果的にははるかに効率的だということです。

44%は手戻りコスト

上と同じようなことを述べる情報として、44%は手戻りであるというデータも示してくださりました。
たぶんこれがWheller David氏の文献からの内容だったように思うのですが、
うまく見つけられませんでした。

リリース後の欠陥修正はコスト比率でコーディング中の100倍

これも要出典ですが、
リリース後に発覚した欠陥の対応にかかるコストは、
コーディング中に発覚した場合の100倍になるそうです。

これって非常に面白いなと思ったのは、実際はこんな単純ではないですが、
日給1万円の社員が1日のコストをかけて1個コーディング中にバグをより多く見つけて修正したら、
100万円も貢献してるとも言えるんじゃないかとか思った点です。

不具合対応にかなりのコストをかけてしまっている現状ですが、こうした取り組みが行なっていけば
不具合対応コストは劇的に減少するかも、とかいう期待を抱かせる面白い情報だと思います。

その他紹介されたキーワード

  • fault-prone モジュール予測：欠陥の多いモジュールを特定する技法
  • hemletの法則：欠陥が発生する「兆候」によってサンプリングする方法（検索しても出てこない・・・）

ソフトウェアテスト技術者のキャリア

多くの人は「テスト技法屋さん」になってしまうということを指摘した上で、

  • メトリクス屋さん
  • プロセス屋さん
  • 欠陥屋さん

というキャリアもあるよーという紹介をしていました。

個人的には後輩たちにこの世界のキャリアを説明する上でとても興味深い分類だと思いましたので、
これについても紹介させていただきます。

実際、技法だけで解決できることって本当に少ないですしね。

まとめ 講演を踏まえて

講演を聞いて私が思ったのは、情報を見える化するって本当に大事なことだなぁと思いました。
これまできっちりプロセス踏んだほうがコストは小さいよ！と言われても
割とピンと来ない部分がありましたが、20%が2.5%になるよ！と言われるとあぁそうか！となるなぁと。

それだけじゃなくて、日々のテストであるとか欠陥も可視化することは
やっぱり重要だし、品質に対する取り組みはむしろそれがほとんどすべてといってもいいくらいじゃないか
とも思いました。

個人的には細川さんの話ってとても面白いなと思います。
特に全体のプロセスを俯瞰して最適な解を求めるような抽象レイヤーにいる人は
とても面白いと思うのではないかと思います。