テストにおけるヒューマンリソースの効率性

最近悩みがあります。

それはテストにおける人の管理についてです。

狼を撃つ銀の弾丸がないのは、ソフトウェアテストにおいても同じです。

でも、”テストを実施する”という作業自体には、プログラマほど専門知識がなくてもこなすことはできることは事実です。（意味のある、効率の良いテストを実施できるか否かは別にして、、、）

テストに関して経験の浅い組織では、「テストなんて誰でもできるでしょ」と安易に考えがちですが、

それはテストを設計したり、管理したりする人の負担を無視した危険な発想です。

そして"狼を..."の話に戻りますが、やっぱりそれなりの経験があるひとをアサインし、効率の良い配置で、コミュニケーションを十分にとりながら進行していくことで、初めて意味のあるテストができるようになります。

前置きが長くなりましたが、用は「それなりの経験があるひとをアサインし、効率の良い配置」という部分が悩ましい点なんですね。

当然テストを管理する人間だけでなく、テストを実行するためのリソースは必要です。ではテスト実施のための専任担当者がいたとして、テストが終わった後に、彼らは何をすればいいのでしょうか？

ソフトウェアや開発の勉強？ テストの上流プロセスの勉強？

ともかく人数が多すぎると、あぶれてしまうんですね。。。。

今の時代、品質にそれほどお金を掛ける余裕はない組織が多いと思います。そんな状況でテスト担当がいっぱいいても、単にコスト部門と見なされる可能性が高いです。

すぐに思いつく対策はいくつもありません。

１．より効率的なテストを実施するために勉強する時間が必要であると上層部を納得させる

２．単発で仕事してくれる派遣会社に頼る

３．努力と根性を武器に最少人数で乗り切る

４．ほかの部署から人を借りる

一番最悪なのは3番でしょう。離職率が跳ね上がり、それに反比例して品質は下落します。

品質の重要性を意識している会社なら、1番の選択肢もありえるのではないでしょうか？

2番は結局管理のコストがかかりますね。

４番は表面上は金のかからない方法ですが、そもそもテストに関してネガティブな先入観を持ってる人が多い組織では、どの部署も人を出すことを渋るでしょう。

4番が良い気がしますが、プロセスをスムーズにまわすためには、啓蒙活動を通して正しいソフトウェアテストの知識を広めてからでないと、うまくいかない気がします。

どれも一長一短ですね。

20

JSTQB カンファレンス in 2010

JSTQB カンファレンス in 2010
http://jstqb.jp/event/conference2010.html

10月14日開催です。

Rex Blackさんいらっしゃるみたいですが、同氏のチュートリアルは大人気で、発表後すぐに締め切ってしまいました。

セッションには参加する予定なので、そのうちまとめなど書こうと思います。

ソフトウェアテストメトリクス

最近ソフトウェアメトリクス収集に関するQAガイドラインを作ったので、
その内容を少しだけ書こうと思います。

 「計測できないものは制御できない」とは、著名なソフトウェア工学者トム・デマルコさんの言葉です。
 メトリクスとは指標を意味し、ソフトウェアメトリクスとは「ソフトウェア開発プロセス全般に亘って、定性的な情報を数値化して計測管理すること」を指します。

品質管理はプロセス管理であるという原則に従って、QAプロセスもある程度数値化して管理
するとこが重要だと考えます。たとえば何か問題が発生したとき、数値化して管理していないと上層部に対する報告も主観的であいまいなものになり、本来のQAの目的である「リスク管理」が正しく実施できなくなってしまいます。またメトリクスをほかの部署に対するマーケティングに利用したり、上層部対する予算確保の根拠などにも利用できます。

このメトリクスを決めるにあたって、注意するべきポイントがあります。

1. メトリクスの評価対象はあくまでプロセスそのものであり、個人の業務評価に使用してはならない
2. 収集の目的を明確にしなければならない
3. メトリクス用データ収集作業が、実務を阻害してはならない

まず１番に関して補足すると、特にマネジメント層にある人は部下の業務評価の材料としてメトリクスを利用しようと考える傾向があるのではないかと思います。しかしこれは大きな間違いで、そんなことをしたら、部下は積極的にメトリクス導入に賛成せず、また正直にデータを集計したりもしないでしょう。メトリスクの収集はあくまでプロセスの管理・向上を目標としていることを明確にすることが大切です。
２番はあえて言及するほどことではないかもしれませんが、メトリクスの収集にあたってはその指標をどんな目的で使うのかを共通認識として持つことが大事です。データの意味や目的がはっきりしていないと、それを有効に使うことはできません。
３番も非常に重要で、メトリクス収集は通常業務の妨げにならないように、その仕組みを体系化し、簡単に繰り返し実行できるようにすることが求められます。つまり最初から欲張って完璧なデータを収集しようとせずに、簡単に実践できて結果が見えやすい指標から試すことが大事です。

ここまでが、ソフトウェアテストメトリクス導入のおおまかな指針です。実際にどのような値を収集するかは、その会社のビジネスモデル、開発プロセス、品質管理方針などによって千差万別だと思います。一般的な指標としては、DRE（欠陥除去率）やTCE（バグの総数に占めるテストケース貢献率）などがあります。


それぞれの指標をどのように収集・活用していくかに関しては、また後日書きたいと思います。

60

上司から与えられたミッションに対して、その有効性や意義に疑問を感じた場合

プレジデント 5.17号から。

上司から与えられたミッションに対して、その有効性や意義に疑問を感じた場合、QAマネージャーはどうすればいいのでしょうか？

選択肢はいろいろあると思いますが、最も重要なことは、まわりの状況をよく観察しその命令の背景を探ることです。

命令の内容が一見無計画で場当たり的に見えても、実際に調べてみると、その裏には、ステークホルダー（主に経営者、投資家、親会社など）の意向や政治的な妥協が潜んでいる可能性もあります。そのような場合に、「この計画は欠陥だらけで会社にとっても不利益にしかならない」などど声を張り上げても、まったく無意味です。

批判した本人は会社やユーザーを第一に考えて、論理的、道義的に意義を唱えたつもりでも、他人にとっては単なる戦略に対する批判者ぐらいの印象しか持ってもらえないでしょう。命令した本人でさえも、問題を分った上で自覚的にやっている場合もあります。

批判を繰り返していると、次第に周りから疎まれてしまいます。私も一度このような状況に陥ったことがあります。

大事なことは「合理的な理由を論理的に主張したとしても、それが会社（上司）の意図と合わなければ会社組織の中では何の価値も生まない」ということを理解することです。息苦しいですね、、、、

もちろんいざという時は、戦うことも必要でしょう。でも、負け戦をやるのは賢い方法ではありません。

とは言っても、無理難題を全て引き受けていたら、自分も部下も潰れてしまいます。そうならないためにできることは４つあります。

１．直属の上司または同僚に命令の背景に関して相談すること
２．自分はどの程度裁量を持てるのか確認すること
３．責任の範囲を明確にすること
４．リスクに関して事前に言及しておくこと

１に関しては、やはり命令の背景を知ることで、その本質が見えてくる場合があるためです。知ってみると実は命令そのものは重要ではなく、単なる政治的理由でやるということが決まっただけのケースもあります。つまり、単に実行すればいいだけでその内容までは問わない、というようなまったく無意味なケースもあるということです。

このような場合に、正面きって批判することは体力のムダでしょう。会社にとっても不利益にしかならないので、いかにコストを抑えて"やったことにするか"を真剣に考えましょう。


２と３は命令を遂行するにあたって、自分の責任はどこにあるのか、またどの程度裁量を発揮できるのかを明確にすることで、後々の"被害"を最小限に留めることができます。責任＞裁量の関係になっていないか、またそうなっていれば、具体的に何が必要なのか事前にはっきりさせておきましょう。いくら無茶な命令だったとしても、それを実現するために現実的に解決しなければならない問題があれば、上司も協力してくれるはずです。

４は欠陥だらけの計画が破綻した場合を想定して、事前に「こんな可能性がありますよ」と上司に伝えておくことです。これを行うことによって、仮にプロジェクトが失敗した場合でも、自分はこの可能性に関して言及していたと言い訳をすることができます。ズルい方法ですが、組織の失敗を個人の責任にさせないために、事前に準備しておくことは重要です。


トップのリーダシップが欠如した組織は往々にして、このように理不尽な状況になりがちです。
しばらく様子を見てまったく改善しないようであれば、履歴書を書き始めたほうが賢明かもしれません。

76

本 「僕が２ちゃんねるを捨てた理由」

今更ですが「僕が２ちゃんねるを捨てた理由」という、元２Ch管理人ひろゆき氏の本を読みました。

2009年6月が初版だから、約1年前ですね。

内容の前半は著者が自分の考えについて口述した内容を、ライターが文書にまとめたもので、後半はひろゆき氏と著名人（？）による対談です。

最初の10ページぐらいで、タイトルの問いに対する回答が得られます＾＾
もっともらしいアンケート結果が最初に出てきますが、完全に釣りです。wwww

要するに、2ch管理人として自分がやるべきことがなくなったから、シンガポールの会社に有償で譲りましたということでした。
 
後半はあの電波少年のTプロデューサーらとの対談です。
話の内容とはそれるけど、「十五ヶ国の少女をあつめて、無人島で共同生活させる」 という
電波の例企画は、今考えるとすごい企画だとあらためて感じました。

アメリカでは未だにサバイバーが続いているみたいだから、Lost＋サバイバー＋マルチカントリーなんて企画を本気でやったら、爆発的に売れる事は間違いないですね。。。
 もっとも人種差別の問題やらなんやらがあるから、実現は難しそうですが、、、

もしかして日本の番組を参考にして、既に準備しててもおかしくないです。 これはまったくの想像ですが。


ともかく対談の中で、ひろゆき氏もTさんも海外を強く意識してることがよくわかりました。


サマリですが、正直まとめられません＾＾；
そもそも一つのテーマについて論じている本ではないので、結論的なものは無かったです。（本人もあとがきに書いていました）

全体を通して感じたのは、『ひろゆき氏は日本企業には早すぎる』ということでしょうか、、、
考え方が超合理的で、本人にはそのつもりがなくても、彼に間違えを指摘された人は、自分を否定された気分になることでしょう。日本企業でこれをやったら、一ヶ月と持たない気がします。


私が今までいた会社でも、やはり合理性よりも「和」が重要だという雰囲気がありました。
ひろゆき氏はアメリカにも留学されてるし、経済も勉強しているようなので、そういった経験も影響しているはずです。私自身海外での経験があったからこそ、合理的な考え方をするようになりました。
でも、日本企業において「合理性はトップダウンで推進されるべきで、一兵卒が合理性を口に出すなどおこがましい」という雰囲気があるように思います。


とはいえ条件が揃えば、合理性よりも協調性を重視した方が上手くいく場合もある、と最近考えるようになりました。

とりとめが無くなってしまいましたが、、、

いろいろな意味で、ゆろゆき氏はトップに立つべき人間なんだと思います。
数年前から露出が多くなったのも、将来を考えたマーケティング活動の一環だと勝手に解釈してます。私と同じで出たがりの性格にも見えないですし、、、

60

品質問題により特損5億円

 ニュースクリップです。

ACCESSの10年１月期、純利益41％減　ソフト不具合で対策費計上

　携帯電話用ソフトウエア開発のＡＣＣＥＳＳが15日発表した2010年１月期の連結決算は、純利益が前の期比41％減の４億9300万円だった。為替差損がなくなり経常利益は増えたものの、ソフトに不具合が見つかり対策費用として５億2500万円を特別損失に計上したことが響いた。http://www.nikkei.co.jp/news/tento/20100316ATGD1502515032010.html

株式会社ACCESS　[東証マザーズ]情報・通信業

 IR情報も見てみたのですが、モバイル向けPJがうまくいかなかったようです。

責任を取って社長報酬－50％×3ヶ月、役員が30％×3ヶ月とありました。
やはり資本が入っていると、責任の重さが違いますね。。。

うちの会社もこれぐらい真剣になってくれたら嬉しいです。


実際問題として、品質と出荷スピードを天秤にかけた場合、
どちらを優先するか判断することは非常に難しいです。

当然ビジネスが成り立つことが大前提なので、スピードを無視することは出来ないし、
一方でどこまで品質を犠牲にするかも考える必要があります。

ひとつ提案するとすれば、品質管理チームを作って出荷前の製品の品質を、
ある程度把握できるようにすることが大事です。

バグ管理ツールとテストプロセス管理ツールも利用したほうがよいでしょう。
レポート作成をExcelでやっていると、それ自体にコストがかかりすぎます。

次に「品質を上げるにはコストがかかる」ということを意識して、
リスクベースのテストを実施することが必要です。
闇雲にテストしても意味無いですからね、、、


一度出荷を見送った製品を担当することになったQAは、
相当なプレッシャーが掛かることでしょう。

一番やってはいけないのは、完璧にテストを実施しようとすることです。
やったらQAチームのメンバが何人か倒れます。

必ず、リスクとコストを上層部に説明した上で、経営判断にもとづいてPJを進行するべきです。

35

日米でのテストエンジニア（TE）の定義の違い

JASST１０の講演での話題からピックアップ。

クロージングセッションは、Johanna Rothman さん、誉田 直美 （日本電気）さん、飯泉 紀子 （日立ハイテクノロジーズ）さんによる、来場者の質問に答える形式のディスカッションパネルでした。

そこでテストエンジニア（TE）に関して、いまいち話がかみ合わない場面があって、司会の 吉澤 智美さんが交通整理なさってました。

詳しい質問の内容は忘れましたが、ようはテスト担当者の役割と呼び名が日米では違うようです。

日本のTE＝テスター、テストする人、専門知識はほとんど無いアルバイトさん。プログラム書ける人も中にはいる。
アメリカのTE＝プログラマーと同レベルの専門的な教育を受けたテスト技術者。当然プログラム書ける。

話がかみ合わない訳ですね、、、、
結論として、日本ではテスト担当者の専門性が認知されてないってことなんだと思います。

もっと勉強して状況を変えていきたいですね。

15

ソフトウェア・テストのソーシングサービス? SIM.ONE [シモン]

ソフトウェアテストに関する面白いビジネスを見つけたので転載します。

本サービスは、不特定多数のユーザーがインターネット経由でWebサイトやソフトウェアのバグを調べて報告するもので、企業はユーザーからのバグの報告に対して報酬を支払います。
『シモン』では、テストしたいソフトウェアを登録するユーザーを「カスタマー」、ソフトウェアのテストを行うユーザーを「テスター」と呼び、両者はインターネットを利用して、テスト仕様の確認やバグの報告、作業報酬の受け渡しなどを行います。http://www.atpress.ne.jp/view/13689

一言で説明すると「人海戦術的なテストを代行します」という会社みたいです。

テスターは登録制で報酬は完全出来高制で、バグ1件あたりの単価が決まっているようです＾＾

カオスな状態になりそうで心配ですね、、、

今後の展開を見守りたいです。

15 

ソフトウェアテストシンポジウム JASST 10 Tokyo

先日目黒の雅叙園で行われた「ソフトウェアテストシンポジウム JASST 10 Tokyo」に参加してきました。
HP： http://jasst.jp/archives/jasst10e.html

基調講演はJohanna Rothmanさんによる、「Successful Software Management」というテーマでした。

マネージャーとして必要なスキルなどに関する講演で、部下と会話する時間を持つ、個性を生かしたチームを作るなど、部下を一人の人間として尊重することがソフトウェアの品質に影響するという内容でした。アメリカプレゼンでは特有のStatisticsがあり、Reuse（成果物の再利用やナレッジの蓄積？）によって、プロセス全体のコストが300%削減できるそうです。

いくつかのセッションを受けました。印象が強かったものだけ書きます。

・西教授 ほか　『テストのスキル標準』
ITSSのソフトウェアテストに関する派生バージョンを準備しており、
来年の1月に正式発表予定とのことでした。
上記内容とは直接関係ないですが、西教授がセッションの中でよく使っていたティア（tier）という単語が印象てきでした。
Tierは教授が作った独自の言葉で、テスト会社のレベルのことらしいです。
Tier1～4まであり、１が最も高く4が一番低いそうです。
ご自身が昔勤務されていた会社は、Tier2レベルだと仰ってました。

・NEC 誉田 直美さんによる招待講演
NEC中国オフショア開発チームで、2年間に渡る品質向上PJのプロマネをされた方の講演でした。
以下のような内容でした。
品質管理はプロセス管理。PDCAサイクルが品質を向上させる。
コストや生産性を優先すれば品質は下がる。しかし、品質を優先すれば結果的にコストも下がり生産性も上がる。品質中心の組織文化をトップが理解して推進することが重要。それをしない限り品質は維持できないし、フィールドバグ（本番バグ）も永遠に収束しない。


シンポジウム全体としてはとても盛況で、一部のセッションでは席が足りず、立ち見している方もいました。
年々品質管理に対する関心が高まっていることを感じます。でもやはりまだ日本ではQAやTEの社会的地位は低いままで、その専門性が十分に認知されていないということも再確認できました。
ソフトウェアの品質管理に携わる一人としては、正直やるせない気持ちも ありますが、
自分の専門性を磨くことで、品質管理担当の地位向上に貢献できたらいいと思いました。

ちなみに今回のシンポジウムでは、有料の情報交換会にも参加しました。
ビッフェ形式で2時間飲み放題が付き、テーブル単位でクイズなどの企画がありました。
参加者に関しては営業の方が5割ぐらいで、その他個人で参加されている方は3割程度しかいないようでした。（私のテーブルだけなので、他の場所はもしかしたら違ったのかもしれません）

普段は社外との関りが殆どないので、いろいろな方とお話ができたこの２日間は、とても貴重でした。

来年もぜひ参加したいですね。

30

「愚者は」 でぐぐってみると

最近、職場で自分が無意識に「情報共有」「情報共有」と連呼していることに気が付きました。

実際、情報共有って大事だと思います。

ステップアップのためのソフトウエアテスト実践ガイド　という本にも、こんな引用がありました。

愚者は経験に学び、賢者は歴史に学ぶ  - オットー・フォン・ビスマルク

つまりは、個人が実際に経験することよりは他人の経験（歴史）から学ぶ方が賢いやりかただ、ということなんです。

昔の人はほんとに頭いいですね。　まさしくその通りだなと感心しました。

もちろん実際に経験しなければ理解できないことは、世の中にたくさんあります。
しかし一方で、直接経験しなくても先人の知恵があれば十分に理解できたり、応用が効くことも同じぐらいたくさんあります。

松下幸之助さんの書いた「道をひらく」という本にもこんなことが書いてありました。

人間とはえらいものである。（中略）しかしそのえらい人間も、産まれおちたままに放っておいて、人間としての何の導きも与えなかったなら、やっぱり野獣に等しい暮らししかできないかもしれない。どんなに優れた賢者でも、やはり父母や先輩の教えを受けることで賢者になりえるのである。

ここでは教育の重要性について語っているのですが、私の個人的な解釈では、人間は歴史を積み重ね、それを子孫に伝えていったからこそここまで発展できたのではないかと思いました。

つまり「情報共有する」ということは、自分の知識や経験を他人と共有することであり、その活動を通じで物事を教えたり教わったりすれば、自分が経験した以上の成果を得ることができる　っていうことなんだと思います。

会社でも「情報共有」を円滑に行うため、地道な草の根活動を1年以上続けてきました。
最近になってやっと積極的に情報共有してくれる雰囲気になってきました。

でもやっぱり、自分の作ったものを他人に見せたがらない人はいるので、気長に説得しようと考えてます。

40

ブログ開始

はじめまして。ブログ開設しました。
仕事で得た知識のアウトプットとして、またソフトウェアの品質管理に関する備忘録として、いろいろな情報を記録していこうと思います。

こんな内容を中心に書くつもりです。

• ソフトウェアテストや品質管理について
• 開発プロセスについて
• 各種ツールについて
• 読書感想文など

週一ぐらいのペースで、ゆっくり更新していければいいなと思っています。