IVIA（IT検証産業協会：IT Verification Industry Association）は、よりよいIT検証サービスを目指して、関連企業や関連するシステム、製品開発を行っている企業、個人が集い、情報交換を行う場として2005年に設立されました。IVIAでは「IT検証技術者認定試験」（⁠IVEC：IT Verification Engineer Certification）という認定試験を年2回のペースで実施しており、同試験の合格者は、ソフトウェアテスト技術者として業界でも高い評価を受けています。

といっても、業界の動向に詳しくない方は、IVIAといってもピンと来ない方も多いかもしれません。そこで、IVIAの教育・研修部会で精力的に活動されている（⁠株⁠）ベリサーブの佐々木方規さんに、IVIAの設立意義とその役割についてお話を伺いました。

「ソフトウェアテストの技術革新」を起こしたい

私たちはテストを専門にやるベンダの集団で、テストをずっとやってきたのですが、テスト技術が20年前から大きく発展してないんじゃないかと思うんです。たとえば、ソフトウェア開発でいうウォーターフォールからオブジェクト指向に変わってきたとか、構造化プログラミングが入ってきたといったものは、テストではほとんどないですよね。技法的には、直交表をベースにしたような技法とか、設計をベースにした技法というのは少しずつ出てきているのですが、革新的なものは今のところないのではないかと思います。

私は、技術の革新というのは「技術の積み重ね」の先にあると思っています。開発の場合、開発が進んでいく中で、問題になった部分の研究開発がどんどん進んで、解決されていったのですが、テストの場合はいろんな立場の人がさまざまな形で携わるので、1つのテスト技術で革新化されてきたことは少ない。それはテスト技術の蓄積がなかったのが原因ではなかったかと思います。ここにIVIA設立の意義があります。

つまり、テストのやり方のスキルを作り、蓄積していくことで、新たな技術革新をそこから見出そうと思っているんです。バラバラなスキルでバラバラの人たちがテストをやっても技術の蓄積になりませんし、革新にも結びつきません。さまざまな人が標準的なテスト技術を使って、それに技術蓄積がされたものが加わっていかなければいけません。そのためにスキルをベースにした資格が必要で、その資格を認められた人間がやったテストの結果を修正しながら技術革新に持っていきたい。そんな思いがIVIAと、その資格であるIVECを作った原点になっています。

IVIAの考え方は実務系に近いといえます。たとえば、現在のところIVECはレベル4（テスト設計、実行）までしか作っていません。実務レベルのところです。この上にテスト管理というレイヤがあり、そして一番高いレイヤはテストのコンサルティングやテストを新しく生み出すような研究開発を行う人材もとらえようとしています。下位のエントリレイヤから上がってきた人たちが、上位レイヤからテスト全体を眺めてみて、新しい技術革新をできるようにならないかと考えて組み立てています。

不具合は現場で起こっている？！

また実務的というのは、最も基礎的なレイヤを重視することでもあります。IT業界、SIの話で「新人はまずテストをやれ」というのがありますよね（笑⁠）⁠。まだ開発のスキルがないのでテストに回す、という考え方もあると思いますが、IVIAで私たちが考えているのは、ここが一番基礎で、大切なところと位置付けているんです。

それはつまり「テストを実行する」というフェーズなんですね。一般的には、テストオペレータというと、現場で機械のボタンを押したりしている人たちで、置き換えが効くだろうという位置づけです。ですが、実はそこが一番テストでは大切だと思っているんです。というのは、そこで発見されることが非常に多いのです。どんな方に伺っても同じ答えだと思いますが、テスト設計で不具合を見つけることはたぶん難しい。テスト設計に従ってテスト実行をしたところでオペレータが不具合に気づくのです。テストケースを設定したところで見つかることも少なく、ケースと違うところで不具合現象を見つけることが多いです。

だからテストの一番ベースとなる「問題を見つけるところ⁠」⁠、ここをやっておかないと、うまいテスト設計もできないと考えているのです。IVECのシラバスではそのあたりを考慮して、テスト実行者のスキルや顔を考えながらテスト設計をしなさい、ということが書いてあるんですね。これは、自分たちがテスト設計をした意図が、ちゃんとテスト実行する人に伝わるような設計をしなさいということなんです。たとえば、オペレーションをざっと書いているだけじゃなくて、このテストケースは何を見つけるために書いたのか、何のためにやってるオペレーションかをわかるようにテストケースを書きなさいということです。

これは、設計にオペレーションしか書いていないと、オペレーション上の不具合しか見つからないので、それ以外の部分の不具合も見つけたいという意図もあります。こうした設計をするためには、テストオペレーションがどのように行われているのかをテスト設計者がわかっていなければならないのです。それで、IVECは実際にエントリレベルのテストオペレーションをちゃんとやった人間が上位のテスト設計をする、という思想で作られています。

最初このレベルを決めるときも、かなり騒動があったんです（笑⁠）⁠。たとえばスキルの高い、経験年数も長い人間が、今さらテスト実行の試験を受けなければならないのかという話もありました。でも、ぜったいにこの試験は「テスト実行」ベースを知っている上でやる必要があるので、上位層の設計者も必ず下位層のレベル相当の試験は受けるということになっています。

このあたりはかなり想いが入って、それが実現化されている部分でもあるのですが。

実務トレーニングとは？

また、IVECの大きな特徴に、知識試験とともに「トレーニング、実務」という項目があって、これはトレーニングを受けた上で認定されたところが合否判定するというものです。もちろんそこも、下位層から受けていかなければいけないことになっています。

エントリーレベルでは、実際に不具合入りのテストアプリケーションを実行させて、不具合を見つけてもらいます。時間内に不具合を見つけることも重要ですが、見つけた後の報告も大切です。問題を見つけたら報告させます。報告書の内容が合格レベルに達しているかどうかを判断します。上位レベルはテストの設計モデルを実技練習をしながら行います。

トレーニングコースといいながらも、研修をするのではなくて、あくまで実力を測るものです。たとえばエントリーの一番下のL1だと、コースは1日しかありません。なので、教育しているわけじゃなくて、コースの中で与えている課題をクリアしているかどうかを判定するのです。最初「実務テスト」という名前でスタートしたのですが、それを文字通りやろうとすると非常に難しいことがわかって、「⁠トレーニング」という名前に変えました。

IVIAは認定する側なので、1日で判定すると言いましたが、教育機関側は、たとえば1週間とってトレーニングしてもらっても構いません。エントリーレベルの実務をこなす実力があると認められれば、合格にしてもらって構いません。それは教育機関のほうにおまかせしています。今はまだありませんが、1週間でトレーニングして実務レベルの合格まで到達させるコースを作っていただいてもいいんです。

トレーニングを行うベンダの認定は、申請していただいたベンダさんの教育カリキュラムがIVECのシラバスに合っているかを審査して、あとは講師の方を資格委員会で面接して判定します。審査に合格してからも、トレーニング実施中の監視ルールなどで規定しています。ちゃんと運営されているか、そして受講者の方にIVIA指定のアンケートをとって、その中に問題がないかをIVIAでチェックします。「⁠カリキュラムがシラバスと違う」といった内容がないかということですね。

ただ、何かハードルを持っているわけではありません。たとえばIVECの資格をもって、研修という形を取れる人がいれば、そのベンダに所属していなくても、臨時で講師をお願いしてトレーニングを開くことはできますし、いろいろなパターンに対応できるようにはなっています。なかなか難しいところですが、トレーニングベンダを増やすことに関しては、これから広報活動も行っていく必要がありますね。

実務重視による技術革新へ

IVECのもう一つのポイントは、テストの資格試験として他の資格試験と棲み分けされていることと、目的に合わせて資格を選んでいただける点ですね。いっぱい資格試験が出てくると、受ける側が迷ってしまうので、資格の目的や資格による効果をちゃんとアナウンスする必要があると思っています。

IVECが他と違うのは、やはり実務重視という点です。先ほど挙げた実務トレーニングもそうですし、受験者にも違いがあります。たとえば、テストエンジニアの認定資格としてJSTQBがありますが、JSTQBを受ける方には開発系のエンジニアの方もおられますし、QAのエンジニアも、そしてテストエンジニアもいらっしゃいます。学術関係者も入っています。IVIAはどちらかというと、実務でテストという業務を担当しなければいけない人が対象です。テストエンジニアもいますし、企業内でテストを担当している人もいると思います。

そしてIVIAでは、スキル認定によって技能的な面が安定してきたところでアウトプットすることも考えています。IVIAとしての技術評価とか技術革新が、IVECの資格を取った方たちの力によってできないか、と思っているところです。

技法があって、それを「使えるスキル」に変えていくのが重要です。知識というのは得ることができますし、与えることもできます。スキルというのはまず実施しなければ身につきませんし、スキルがないと実現しないことが多いのです。スキルをもった人たちによって業務が進んでいく中で、たくさんある課題がどうクリアされていくか、というのが革新です。紙の上での問題ではなく、実際に起きている問題に対してどうしていくかが引き出せると思っています。

たとえば実務的な要望として「何とかコストを下げてほしい」というのがあります。アカデミックなところでは、無限のテストケースが想定される場合、ソフトウェアエンジニアリングによって解決しようとしますが、実務的なところでは、そんなにお金をかけていられません。その状況で一番有効なやり方はなにか、あるコストの中で行うにはどこから選ぶんだ、というリアルな話なんです。

そういった状況から要求が出てくるものです。今のテストエンジニアっていうのは頭の中だけで設計している人がすごく多いんです。仕様書を読んで、そのままテストケースに書き起こしてしまうので、中間のドキュメントがあまりないのです。だから、後からそれを見てみると、何をやっているのかわからないんです。なんでこのテストをしたのか、なぜこのテストケースを作ったのか、というのがないのです。それは「スキル依存」の世界なんですね。「⁠スキル」の伝承はあっても「技術」の伝承がないんです。

この「技術」を伝えるためにいろいろなやり方が考えられています。仕様書からテストケースを作るのであれば、まずどんなテスト項目を抽出したのか。このとき、たとえば鈴木三紀夫さんのように「三色ボールペンで読む仕様書」とか、いまだとマインドマップのような形で抽象化して、そのテスト観点を絞り出しましょう、というやり方があります。これをいろいろな技術者がある一定のレベルで行おうとすると、やり方をエンジニアリングしてやらなければならないんです。

だから、まず仕様書を読んだら、仕様書に対してテストの観点を洗い出します。テストの観点の洗い出し方は、ツリー法もあればマインドマップのような方法もありますが、これをちゃんと体系化してあげて、そのドキュメントを残すことを定義しなければなりません。その定義をしたうえで、テストをやった「足あと」を残して、その足あとを分析していくことが必要になってくると強く思っています。

そのときには、実力がちゃんと計られた技術者が責任をもって見ないと、足あとがバラバラになってきますし、あとから見てまったくわからない状態になってしまうんです。一部のデキル人たちだけがずっとやってるという世界になってしまうのです。

技術の公開なくして進化なし

技術という面で、会社の機密事項や、具体的なところが外に出せないという話もありますが、それは乱暴な言い方をすると、機密とかいった言葉で濁しているだけで（笑⁠）⁠、ちゃんと技術として確立できていないから話ができないだけじゃないかと思います。

たしかに製品の内容など機密として扱わなくてはならないことはいっぱいあります。ですが、私はベリサーブという会社にいる立場でIVIAに関わっていますが、ベリサーブでやっているテストのやり方やテストの考え方はすべて公開しています。なぜかといえば、テストというものは、テスト自体がブラックボックスになると困るわけです。実際にどんなテストをやっているのかを明確に伝えておかないと、テストに通ったと言っても、誰も信用してくれないでしょう？

だから、どんなテストをやっているのかを聞かれたら、そのテストの中身、やり方に関しては公開しなければいけないと思っているのです。それは私たちのノウハウでも知識でもないのです。テストをやった結果の技術的経験、アウトプットの実績こそが私たちの蓄積になっていくので、いくら机上で「こんな良いものがあります」と言っても我々はまったく評価しません。「⁠それを使ってテストをしたらこれだけ成果が出た、次の技術革新をするためのデータがとれた」ということを大切だと考えます。それでまた新しいことをやって、課題を見つけて、クリアしていくことができるのです。テストに関しては「これをやれば何でも解決します」といった特効薬のようなものはないと思っています。地道にやっていくしかないので、そこに何か秘密にしなければならない特殊なものがあるとは思えませんね。

ただ、もちろんお客様の製品やお客様自身の情報に関しては外に出すのはNGにしています。それを出さなくてもテスト技術に関する話はできると思うんです。要するに、言い換えることができれば良いのです。テストの解説を求められたときには、直接受けた話をしなくても、同じシチュエーションを仮想的に作って、その場合ということで説明します。そこで仮想モデルを、どのようにうまく作れるかということもあると思いますね。

IVECのシラバスの一番最初のところに、「⁠製品の特性を分析して、その特徴に合わせたテスト設計をします」という形になっています。また試験では「あるプロダクトにおいて」といった形で、より細分化した個々の事例について仮想の問題にして出されることもあります。

シラバスは、本当にいろいろな技術者が集まって、各フレームで「こういうときにはどんな検討をするんだ」というのを喧々囂々とやりながら作ったものですし、これからも発展していく途上にあるものなんです。そんな中で、今現実的にテストをする際に、自分たちはなにをやったのか？というのを出して、出したものがあまり具体的だと使いにくいので、少し抽象的にしています。

あと、IVIAのシラバスには、テスト技術者以外の方は違和感を感じるような細かい項目もあります。たとえば「テスト準備をする」という項目がありますが、テストの場合、最初からテストが止まってしまう、というケースがあるんです。だから、「⁠テストエントリーの前日までのどこかで必ず動作確認をする」という項目が入れてあるんです。単に機械を用意するだけではなく、ちゃんとパワーオンして、テストできる環境になるところまで確実に前日までに確認しておきなさいと（笑⁠）⁠。

よくトラブルがあるんです。マシンが来て、テストしてくださいというときに「電源入りません」と（笑⁠）⁠。そうすると、テストで待機している人間が10人、20人いるのに、今日は仕事がありませんということになってしまうんです。これはコストに関わってきます。それを避けるための「テストを止めないためのノウハウ」といったものが、シラバスには入っているんです。

夢は「Qualified JAPAN」

長年「テスト技術者はつぶしが効かない」と言われてきました。テスト技術者は開発に簡単に移行できない。キャリアチェンジという形では、なかなかテスト技術者というスペシャリティを保つことができませんでしたね。

そんなメンタリティがずっと頭にあったので、それなら徹底的にスペシャリティを鍛えて専門家を目指した方が良いと思いました。であれば、テストのスペシャリストとしてやっていく人がいなければいけないし、逆にスペシャリストとしてずっとご飯を食べていかなければならないので、それだけの環境を作っていかなければいけないと思いました。

技術が人に依存するだけではなく、テストが業界になることで、テスト専門の技術者が活躍できるフィールドを作っていくこと、またそこで発展していかなければと思ったのです。

そのためには、よく言われる「新人、腰掛け」がテストするのではなく、スペシャリティをもつエンジニアが、テストの専門家であるというモチベーションとポリシーをもってやるというのはすごく大切なことだなと思っています。

そのための資格です。だから、資格自体も盛り上げていかなければいけない。せっかく資格を取ったのだから、その資格を持っていることに意味をもたせてあげたい。そのためには、テスト技術者がどういう本音を持っているか、ほかの技術者とテスト技術者の視点がどう違うかということをどんどんアピールしていきたいと思っています。

欧米を見ても、テスト技術者の地位はまだまだだと思います。僕は逆にソフトウェアテストという技術が日本で確立されて、海外にも広められないかと思っています。つまり、日本で生産はしなくて良いんです。生産拠点は中国でもインドでもいい。でも、検査をしているのは日本の技術で、日本が検査監督をしてやっていると。ソフトウェアテストの技術として日本がブランドとなって「Certificated JAPAN」「⁠Qualified JAPAN」といった形で確立できたらいいなと思います。

そうなったら、楽して食えるかなと（笑⁠）⁠。あくせく働くよりは、楽して食っていきたいですからね。エンジニアは「楽するために苦労する」んですよね（笑⁠）⁠。

お話を聞く1時間あまり、ほとんどしゃべりっぱなしだった佐々木さん。テストエンジニアが「楽して食っていける」世界を作る─そんな熱意をもった人たちが作り上げたIVIAとIVEC、これからの活動も目が離せません。

IVIA 「IT検証産業協会」

URL：http://www.ivia.or.jp/

プロフィール

佐々木方規（ささきまさき）

1985年株式会社CSKに入社後、テスト業務に従事しながら検証のノウハウを学ぶ。現在は、株式会社ベリサーブでテストに関する技術開発・人材育成に取り組んでいます。IPAソフトウェア・エンジニアリング・センターやJSTQB、IT検証産業協会（IVIA）では教育・研修部会の主査として活躍中。