テストという破壊的な作業の建設的なやり方：ソフトウェアテスト・エンジニアの本音（4）（1/3 ページ）

1月24日、25日の2日間にわたって、ソフトウェアテストシンポジウムとしては3回目となるJaSST'05を、盛況の中無事終えることができました。今年も、2日間で延べ900人に上るテストに興味を持つ幅広い層の技術者に参加していただき、感慨もひとしおです。そこでこれから2回にわたり、本シンポジウムに関連した話題をお届けします。

[大西建児，株式会社豆蔵]

　今回は「Five Trends Affecting Testing」というテーマで基調講演（「ソフトウェア・テストに影響を及ぼす5つのトレンド （＠ITNews）」）をしてくださった、テストの世界でご活躍中の独立コンサルタントであるレックス・ブラック（Rex Black）氏と実行委員会との懇談の様子をお伝えしましょう。

　ブラック氏は誠実そうな外見にたがわず非常にまじめな方で、実行委員会の質問にも1つ1つ丁寧に、そしてじっくりと答えてくれました。このインタビューを通して、なぜ氏が緻密でかつ分かりやすいテスト管理の大著［*1］を書き上げることができたか、理解できたように思います。懇談はテーマを絞ったものではなく、出席した各実行委員が日ごろテスト分野で疑問に思っていることをブラック氏にお伺いするスタイルで実施しました。

---

［*1］

▼「基本から学ぶテストプロセス管理」、日経BP社、テスト技術者交流会 監訳

▼「ソフトウェアテスト12の必勝プロセス」、日経BP社、テスト技術者交流会（大野晋） 監訳

---

　なお、この懇談会の司会を本記事取りまとめ担当の大西が、記録を鈴木（三）が実施しました。特に、鈴木（三）氏には大変なテープ起こしから作業をしていただきました。その労に感謝したいと思います。

テスト本の執筆の裏話

レックス・ブラック氏

大西　Rexさん、このたびはJaSST'05の基調講演のために来日くださり、ありがとうございます。この懇談会では、まずRexさんから、2冊にわたるテスト管理の本を書かれた際の裏話や、苦労話、はたまた面白い話などありましたらお聞きかせいただけないでしょうか。

Rex Black（以下Black）　苦労というほどのことは、そんなにありませんでした。ほとんどの場合、自由に何でも書いてよい立場にあったからです。クライアントからはNDA（Nondisclosure Agreement＝守秘義務契約）上の制約こそありましたが、開発の人たちが体験したことを書いてよいとの承諾を得ることができましたから。もちろん、プロジェクトが明示的に分からないように日付を変えたり名前を変えたりはしています。また、ケーススタディでは不適切と思われる表現は変えています。皆さんも経験があると思いますが、プロジェクトを進めていくとエキサイトすることもあります。そういった感情的な発言などには手を入れましたが、経験をベースにしたものに変わりありません。

　本を書くうえで大変だったのは、なかなか時間が取れないことでした。空いている時間を探すのが本当に大変でした。ボリュームのある本ですから、トーン（文体）や考え方の一貫性を保つのが大変でした。書きたいテーマは頭の中に浮かび上がるのですが、そのときに、たまたま書いている章とマッチしないこともあるわけです。そのようなときは、メモを取っておいて後の章に入れるといったこともしました。後でメモを読み直すと前の章に入れておくべきだったと気付くこともありました。かなり反復的な作業が必要で、多くの修正を行いました。新しい本の場合（「ソフトウェアテスト12の必勝プロセス」）それぞれの章が密接に関連しているために修正作業も大掛かりで手間が掛かりました。

Jamal（ケーススタディの登場人物：テストマネージャ）の人物像

大西　新しい本のお話が出ましたので、監訳をされた大野さんから何か著者にお聞きしたいことがございましたら、ご質問ください。

大野　日本語訳をしながら感じたことは、ケーススタディがとても分かりやすいということでした。テスト・マネジメントの流れをつかみ切れていないエンジニアはたくさんいます。マネジメントを知ることができないエンジニアにとって、本書はとてもためになる本だと確信を深めつつ翻訳作業を行いました。先ほど、Rexさんもおっしゃっていましたが、日本語の中でもスタイルを貫くのは大変でした。私としては、日本のRex Blackになって、まとめ上げたつもりです。

一同　（笑）

大野　そこで、1つ教えてください。ケーススタディに出てくるテストマネージャのJamalについて（読者は）どのような人物像を描けばよいのでしょうか。

Black　特定の人物像というものではなく、どんな人でも感情移入しやすいようにと考えました。彼の国籍、人種などを特に意識して読む必要はないように気を付けたつもりです。Jamalが経験したことを自らの経験に照らし合わせて、テストマネージャの仕事というものを感じ取ってもらいたいと思います。

リスク分析

湯本　私からはRexさんの最初の本である「基本から学ぶソフトウェアテストプロセス管理」に書かれていたリスク分析についてお尋ねします。この本ではリスク分析のやり方が、2つ挙げられていました。FMEA［*2］とそれを簡略したやり方です。日本のテスト現場ではFMEAを使うのは極めて難しいと思っています。アメリカではリスク分析をどのように行っているのでしょうか？ FMEAと簡略版とどちらを使っているのでしょうか？

---

［*2］　FMEA （Failure Modes and Effects Analysis）：不具合モード影響解析のこと。一般的には故障モード影響解析とされることが多いが、翻訳本では意図的に不具合モードと訳している

---

Black　私が初めてリスク分析について学んだ手法がFMEAでした。とはいえ、FMEAは複雑ですし手間の掛かる手法です。初めてリスク分析を実施する場合には、簡略版の方法をお勧めします。リスク分析のやり方に慣れた後でFMEAを適用してください。最初からFMEAに取り組むというのは、歩き方を学ぶ前に自転車の乗り方を学ぶのと同じようなものですから。私自身も何度もFMEAの自転車から転げ落ちる経験をしています。

リーンソフトウェア開発

和田　開発手法の話題に移ってきたようですので、その流れで質問させてください。現在、私は「リーン（無駄のない）ソフトウェア開発」というものに注目しているのですが、実際にアメリカのソフトウェア開発の現場で、この手法は一般的になっているのでしょうか？

Black　リーンという意味が「安くて急いでやる」という意味でしたら一般的ですね。プロジェクト運営における近道を選んだつもりでも、長期的に見ればダメージになることを認識していない企業が世界的に見ても多いでしょう。不具合対応という点について例を挙げましょう。私が実施したすべてのアセスメントからもいえるのですが、欠陥のために費やすコストというのは、組織によって3倍から4倍、システムテストにおいては、実に35倍も開くことがあるのです。一度、定量的にこの現実を理解できれば、プロジェクトの中で手っ取り早い解決法だからといっても、結果として手抜きをすることになるのであれば、かえって高くつくことが認識できるはずですから、より慎重に判断するようになるでしょう。