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の資格をもって，研修という形を取れる人がいれば，そのベンダに所属していなくても，臨時で講師をお願いしてトレーニングを開くことはできますし，いろいろなパターンに対応できるようにはなっています。なかなか難しいところですが，トレーニングベンダを増やすことに関しては，これから広報活動も行っていく必要がありますね。