プロフェッショナルなテスト技術者になる方法

電気通信大学：西 康晴 先生インタビュー 第1回：プロフェッショナルなテスト技術者になる方法

日本のテスト業界の立役者である電気通信大学の西康晴先生にお話しを伺ってきました。

西先生は、電気通信大でテスト技法やソフトウェア工学を中心に研究・教育活動を行うとともに、産業界におけるテストや品質の問題にも積極的に関わり、日本のソフトウェア開発をよくするためにテストという切り口で果敢に挑戦されています。ソフトウェアテストシンポジウム(JaSST) など様々なテスト関係者コミュニティの立ち上げや世話役も引き受けられ、若手エンジニアの悩み相談を受け持つ頼もしいお兄さんという側面ももっています。

今回のインタビューでは、西先生から本音ベースで、日本のソフトウェア開発におけるテストや品質確保の現状と課題について、じっくりお聞きすることができました。

第一回は、これからテストエンジニアを目指す方々に向けてのアドバイスです。

テスト技術者の道を極めようとするならば、どのようなことを特に勉強しておくべきなのでしょうか。

基本的には、テストの技術、ソフトウェアエンジニアリングの技術、そして品質の技術 を広く学んでいくことになると思うんですけれども、何を勉強するかよりも、どういう考え方、視点で勉強するかが重要だと思っています。その時に3つあげるならば、「悪いこと」「良いこと」「悪いことを良くすること」この3つの視点で勉強することを整理していくのがよいと思います。

まず「悪いこと」についてですが、例えば、今プログラミングをやっているエンジニアであれば、「コーディング作法」とか「コーディング規約」というものがありますが、あれは間違えやすいようなコードのパターンが網羅されているものなんですね。それをただ単に作法や規約として身につけるのではなくて、「ああなるほど僕たちはこうして間違えるんだね」ということを認識しながら、理解しながら、身につけていくということです。

同じように、設計をやっている技術者であれば「アンチデザインパターン」のようなものをたくさん持っていると思いますが、そういうものを整理しながら身につけていくということですし、要求定義やマネジメントについても同じことが言えます。

そういう「悪いとは何か」ということを知った上で、「何故そうなってしまうのか」という視点で学んでいくということです。 例えば、設計とかコードのようなテクニカルなものでしたら、「人間はなぜそうやって考えてしまうのか」というような、心理的な、もしくは認知科学的な話に繋がっていきますよね。

そうした心の癖みたいなものを形式化した上で、それが自分たちの仕事の中でどういうふうに利用できるのかとか、気を付けなくてはいけないのかとか、パターン化しましょうということですね。

そうです。 そういう考え方をすると、ある技術のキーワードなりをきっかけにして、どんどん勉強することや技術を身につけることが拡がっていくと思います。たとえば認知科学で言うとアフォーダンスという概念がそうですし、羽生田さんがよく言及される身体性なんかも非常に似たような概念かと思います。

二つ目の「良いこと」というのは、例えばある人がヨーロッパの教会の大聖堂のようなところに行って「こういうアーキテクチャは日本人にはつくれない」と感心しながら言ったんですけれども、そういう「良いものを良いものとして認識する」こととか「良いとは何かということをちゃんと解る」ということです。それが解っていないと粗探しになってしまったりしかねないんです。

前向きな「こうすれば更に良くなるのに」というような提言と結びつかないといけないということですね。

例えば、テストの技術者に関して言えば「お客様に売れる製品は何か」とか「喜ばれる製品は何か」ということを考えるという話へ繋がります。

一種の目利きみたいなことと、テストという欠陥を発見することと、両方できる方が自分にとっても楽しいし、やりがいもあるということですね。

そうですね。 良いことからの逸脱が悪いことではないんですよ。開発者の方々はそう考えがちなんですが、悪いことは悪いことで一つの体系みたいなものがあって、良いことは良いことで一つの体系みたいなのがたぶんあって、両方あることを認識しなくてはいけないのがテストのエンジニアだと思います。 例えば、開発出身のテストエンジニアが陥りがちなんですけれども、開発の知識の裏返しがテストだという考え方をしていると、開発の確認しかできないので凝ったバグが見つからないということが起きます。 逆にバグを見つけることばっかりをやってきたテストエンジニアが、上流の要求のレビューとか企画会議に参加するようになると「ここの仕様はこういう使い方をお客さんがするからまずい」というような「まずい」ことを考えていくんですけども、それだと上流のエンジニアや企画の人たちから疎んじられるんです。そうではなくてお客さんの立場に立って、「お客さんが喜ぶのはこういう仕様なんじゃないか、こういう使い勝手なんじゃないか」ということをどんどん提案していくような方向に持っていかないと、「良さ」の評価ができないと思います。

3つ目は「悪いものを良いものに変えていく」ということですが、あまり現場で経験されたことのない方は「そんなことは誰でもできる、普通にできる」と思うんですけれども、実は非常に大変なことだったりします。

例えばテスト技術としてあまり論じられないけれども非常に重要なこととして、「バグレポートの書き方」というのがあります。バグレポートが高圧的だったりすると開発者は直さないんですよね。同じように会議の時に鬼の首でも取ったようにバグを指摘しても直してくれないです。

それから、現象だけを書いてしまっても直すきっかけが少なくて、現象を見た時の洞察を、それがちゃんと洞察にすぎないということを明示した上できちんと書いていく、心配事を書いていく、他のバグとの関連の可能性を書いていくということが大事であったりします。

他にも、不具合のランクをどうするかということがあって、不具合なのか不具合じゃないのかよくわからないものを、その時どっちに判定するかは難しい問題です。ワーニングという名前をつけたり、イシューという名前を付けたりしますけれども、そのつけ方というのは実は問題そのもののランクよりも、開発者がどのくらいバックログを抱えていて、そのバックログに対してこの不具合がどういう優先度にあるかというようなことを全部兼ね合いも含めて決めていかなくてはいけない。

そう意味で言うと要求に関しての全体像だとか、今担当しているコンポーネント部分がアーキテクチャ的にどういう位置づけにあって、このバグと他のコンポーネントの機能とがどういう依存関係をもっているか、というようなこともテスト技術者はわかっておかなくてはいけないということですね。

そうです。それを「直してもらいやすいようにするにはどう使っていけばいいのか」という視点で理解してないといけません。

それからテスト技術者の中にもいろいろいて、テストの設計をする技術者もいればテストの実施をする技術者もいます。テストの実施をする技術者に関してはオペレーターのような呼ばれ方をされて、もうそこに技術の介在する余地はないと思われがちなんですが、実はそんなことはなくて、たとえばタテのものをヨコにして置いておくだけでも効率が上がったり、そういうハードウェアの用語を使えば生産管理とか、ソフトの世界でアジャイルの人たちが良く取り入れていますけれども作業改善とか動作分析といいますけれども歩き方とか、手の動かし方ひとつにも工夫の余地がある。

例えば再インストール済みのクリーンOSばっかりインストールしてあるハードディスクを用意しておいて構成テストをがんがんやるとか、いろんなノウハウがあるんですよね。そういうところというのは改善された結果をただ上流にバックするのは簡単なんですけれども、自分の現場でどんどん工夫していかなくてはいけなくて、その工夫をどんどんできるような自分たちの仕事の環境の作り方とか雰囲気の作り方というのがとても重要になります。 それは例えば上流に関しても言えて、ダメな組織は「我々はテストで品質を上げています」良い組織もこう言います「テストで品質を上げています」。言っている言葉は同じでも意味は全然違っていて、悪い組織は上流でバグをガンガンつくりこんでテスト工程でバグを直して出荷します。これが彼らの言っている品質を上げるということです。

反対に、良い組織はテストを一生懸命やることでどうしてバグが作り込まれたんだろうという原因を上流にフィードバックして最初からバグを作らないような開発のやり方をします。設計のガイドラインを作ったり、レビューのチェックリストを作る、ということをするので、テストで直接バグが見つかっていないのに品質が上がっている。

この二つは物事を良くするやり方の極端な反対の進め方なんですけれど、どちらもテストで品質を良くしていこうとしています。本質的にものを良くしていくのはどういうことなのかというのは意外に難しい。

いろんなアプローチがあって、たとえばフランス料理はあまり良くない素材と流通があまりよろしくない環境があった時に、でもおいしい料理をつくりたいからソテーして、バターを使って果物のソースを使って臭みを消すような料理法をします。それはそれで料理をおいしくする考え方です。一方で、日本の和食のように刺身を切るときに細胞をつぶさないようにする、というようなことを考えるわけです。

全然考えていることが違う。片方はマシンガンとかバズーカ砲で戦争に勝つ感じ、もう片方は居合抜きでまったく無駄な動きをしない、これは物事をよくする極端な二つのやり方です。他にも色々ありますけれどもどのアプローチをとるかによって同じ良いことをやろうとしても、逆の結果が出ます。

ですので「悪いこと」と「良いこと」それから「悪いことを良いことにどう変えるか」この三つをきちんと考えていくと、実はソフトウェアエンジニアリングとかソフトウェアテスティングというある意味限定された勉強の領域ではなくて、普段の生活で気にすること、気が付いたことを自分の仕事に生かせるようになるんだと思います。

テストエンジニアになるときに、開発をやってからなるのが良いのか、最初からテストエンジニアだけでいけるのか、育成のパスを考えた時にどちらがよいのでしょうか?

素養としての開発技術はあった方がいいと思いますし、開発経験があるに越したことはありませんけれども、必須ではないと思います。

ただ、開発経験がない場合は「なんでこういうバグが起きているのか」という説明とか、「こういうアプリケーションは大よそこういうつくりをするんだ」という、つくれなくてもいいから話を聞いて理解できるとか、もしくはつくりが想像できるとか、そういうあたりの勉強は必要です。たとえばデータベースのコミットの仕組みとかがわからないと、データベース周りのテストは出来ませんから、そういう意味では開発の方面の知識は必要になりますけれども、ものをつくるという経験がかならずしも必須ではないです。ただものをつくる経験が少ない場合には、もののつくりを推測してイメージとして持てる能力は必要ですね。

良いテストエンジニアに話を聞くと、開発経験がなくても「大体こういうものはこういうつくりをしているから、大体このへんがおかしいんだよ」と言いますね。

実際の設計の仕組みではないかもしれないけれども、ブラックボックスが与えられたときに自分なりにその中の仕組みを想像した上でモデルを頭の中で組み立てる能力ということですよね。

そうです。

逆に開発経験があるという方の中には、詳細設計を与えられてその通りのコードを書く人たちもいるので、そういう開発経験であればあまり意味はないですよね。

もし学生時代に、ソフトウェアテスト以外のご専門を選ばれていたならばどのような領域を選んでいたと思いますか。

音楽のレコーディングエンジニアとか、DCのリミキサーとか、スポーツのコーチとか、、、

なんでそう思うのかというと、前面に立つよりも裏側で戦略とか組み立てを考える方が好きだからです。

それはテストエンジニアの仕事の立ち位置と何か関係するところはありますか?

関係するような気がします。たぶん僕はアーキテクトにはならないですね。

卒論のテーマがテストツールを作ることだったんですが、当時の僕は腕に自信があったので何も設計をせずにいきなり1万行のコードを書いていって、そうすると当然ありとあらゆる種類のバグが出てくるわけです。その時にロジャー・プレスマンの本を読みまして、「すごい！こういうことをやらなくてはいけないのか！...なるほど、自分には向いてない」と思ったんです。

というようにソフトウェアエンジニアとしてはヘボエンジニアだったんです。

逆にそういう道で今に至っているので、テストとか品質ということに関して、普通にアーキテクトになった人に比べて違う見え方がしているということでしょうか?

そうですね。

「とかなんとかいって、そんなにうまくできないでしょ」というような見方をしてますね。

なるべく現場サイドから見る(5ゲン主義※)というのは、そういうところから来てるのかもしれません。

※　現場・現物・現実・原理・原則

今でも現場に出向いて観察するのは好きですか?

はい、好きですね。工場とかに行くとわくわくしますね。

キャリアへの適性としてソフトウェアテストの領域には向き／不向きはありますか？

あるとすれば、どのようなものでしょうか？ 1つはいわゆる「つっこみ」特性ですね。テストエンジニアと会議をすると全体の議論に関係なく誤字とか脱字とかを突っ込んできます。彼らは。そういうところが気になって仕方がないんですね。

2つ目は「きっちり」ですね。ものごとを一から十まできっちりやらないと気がすまないということですね。部屋を丸く掃くのは嫌だという人ですね。

もうひとつは「あそびごころ」です。基本的にテストはしんどいですから、良いテストエンジニアは例えば100件テストをしなくてはいけないときに、それを「どう楽しんでやろうか」とか、「少しずらしたところもテストしてみよう」とかそういう取り組み方をしますね。

（次回に続く ）

株式会社豆蔵 取締役 プロフェッショナルフェロー　豆蔵ソフト工学ラボ所長　羽生田 栄一

コンテンツ提供: 株式会社豆蔵
本稿は「豆蔵ソフトウェア工学ラボ」に掲載された過去記事を転載しています。

西先生の最新インタビュー記事は近日中に公開予定です。