|
渡辺
|
大西さん、よろしくお願いします。
|
|
|
|
大西
|
渡辺さん、今日はいつもと違って知的な雰囲気をかもしだされていますね。(笑）
こちらこそ、よろしくお願いします。
|
|
|
|
渡辺
|
実はちょこっと無理してます(^^;。本題本題と。えぇ〜大西さんと言えば、陽気なテストスペシャリストのイメージがありますが、キャリアとしてはどんな道を歩み、現在に至っているのでしょうか？
|
|
|
|
大西
|
「陽気な．．．」と言っていただけると私としては本当に嬉しいです。
何故かテスト屋に対して、重箱の隅ばかりをつつく「陰気」な職業というイメージを抱かれる方が結構おられますから。そんな世の中の印象を変えるべく、歌って踊れるテスト屋さんを目指している．．．ってそんな分けは無いのですが。 （ゴホンゴホン）
|
|
|
|
|
さて、私のキャリアのお話でしたよね。私自身のキャリアを説明するときによく使うのは、「ソフトウェア開発のゆりかごと墓場だけ」やってきたという例えですね。
|
|
|
|
|
|
SESSAME定例会後のピザパーティ風景
いちばん左の丸顔でスーツを着ている人が大西さん
|
某国内電機メーカ系列の会社で、プロセス制御システムのシステムテスト担当としてエンジニアのキャリアをスタートしました。いわゆる「ひんしょう：品質保証」に該当する部門です。その後転職しまして、某外資系通信機器メーカでも、しばらく交換機周りのシステムテストをやってました。これがいわゆる「墓場」ですね。
なぜこんな物騒な言い方をするかというと、出荷前品質が悪ければ、それこそエンジニアの死屍累々なフェーズだからです。
なんだかんだで一昔と言われるくらいの期間、テストをやったんですね。そろそろ自分自身違うことをやりたいな、と思いまして、当時の上司にお願いしてクライアントから来た要求をとりまとめる部署に異動しました。これが「ゆりかご」に当たる、要求定義のフェーズです。
途中プロマネ部門との組織統合があったため、多少プロマネとはどんなものか程度は知ることができましたね。その後、某氏に誘われ現職に就き、ソフトウェアテスティングやプロセス改善などでクライアントを支援するタイプのコンサルテーションをやるようになって、現在に至る。
ざっとですが、こんな感じですね。
|
|
|
|
渡辺
|
なるほど。交換機のキャリアが墓場側だったなんて、元:交換屋としては悲しいけど。
暗くなるので話を変えます。現在の活動ですが、2004/1月に開催されたソフトウェアテストシンポジウム2004で、テストライブってやったじゃないですか。私は不参加でレポートとかも読んでないのですが、これっていったい何をやっってきたんですか？
|
|
|
|
＜テスティングマッチ＞
|
|
|
|
大西
|
悲しまないで下さい。でも、デジタル交換機自体がソフトスイッチに置き換わっていってますから、我ながら言いえて妙かも。何てことを言ったらダメですね。テストのフェーズとしては、墓場なんかじゃなくて、ソフトウェア開発の「花道」になることを望んでいます。
次に今回のJaSSTのお話しをしますが、渡辺さんご都合が悪くて来れなかったんでしたよね。次回は是非とも参加してくださいませ。
|
|
|
|
|
まずソフトウェアテストシンポジウム：JaSST'04の概要からですが、主催のソフトウェアテスト技術者交流会：TEFのサイトを見ていただければと思います。
私が担当したテストライブは、その名の通り、ソフトウェアテストをライブでやろうという企画です。実はこの企画、もともとはセサミアンでもある某シーラカンス総統閣下による、「ライブ感がほしいなぁ」という一言がきっかけだったんです。
JaSST実行委員会の中で、企画として面白い！ということで実施することになった旨を、シーラカンス氏に伝えると「さて，我シーラカンスはライブ感を囁いたかもしれないが，まさかほんとにやるとは思っていませんでした．まあ，いいか．」というお返事ではありましたが。（笑）
シーラカンス氏には、こういったいきさつがありましたので、ライブ当日は開発チームの親玉、つまり総統閣下として解説をしていただきました。お陰さまで、ライブをかなり盛り上げていただけて司会進行を担当した私としてもかなり助けられました。
|
|
|
|
|
いきさつは、そんなところなのですが、ライブの内容をお話ししますね。
「テスティングマッチ」と名付けた45分間という短時間でのプログラムだったのですが、テストの腕っこき3人衆が、それぞれテストケースを作ってきて、テスト対象のバグを15分間でどれだけ見つけられるかというものです。
テストの腕っこき3人衆は、国内メーカ、外資系メーカ、第3者検証会社にお願いしましてテストのエキスパートに出演して頂きました。
テスト対象は、SESSAMEが教材として開発した「鹿威しシミュレータ」にバグを仕込んだものです。埋め込まれたバグの半分以上をテスト側が見つければテストチームの勝ち、そうでなければエラーシーディングでバグを仕込んだセサミアン開発チームの勝ちとしましたので、「テスティングマッチ」と銘打ったわけです。
当日のライブ時間の都合上、事前にテストチームには仕様を伝えておき、これをベースにテスト設計をしてもらいました。ですから、テストチームが実物の鹿威しシミュレータを触ったのはライブ当日だったんです。それでも、流石プロのテスト屋さんたちで、半分近いバグをたった15分で見つけてくれましたよ。
|
|
|
|
|
ライブの模様は、3人にノートPCに搭載したシミュレータを1台ずつ割り当てて、テストの模様をプロジェクタで写しながら私が実況で伝え、シーラカンス総統が随時解説を入れるという感じで100人以上の聴衆にお伝えしました。
テスト側がバグを見つけると、「ぴんぽ〜ん」と音がする、「○」の札があがるスイッチを押してもらい内容を説明してもらいます。その内容を開発側が、実際のバグかどうかを判定し、バグであれば「お見事！」となるわけです。
お陰さまでかなり盛り上がりまして、次回のJaSSTでもライブ企画をできればなぁと思っています。
|
|
|
|
＜テストプロセス＞
|
|
|
|
渡辺
|
次回のJaSSTを楽しみしています。テストライブみたいに実装されたもの(JaSSTはSimulation!?)のテストでなく、もっと上流からテスト屋さんって絡みますよね？
最近はUMLも普及してきたし、RUPとかXPみたいなプロセスも流行っているみたいですが、これら最近の動向とテストって関係深そうな気がします。昔からのウォーターフォールモデルでのテストと、最近のテストって違ったりするのですかね？
基本は一緒だと思うけど。
|
|
|
|
大西
|
開発アプローチが異なれど、私もテストの基本は一緒だと認識しています。
UMLをベースにしたOOでのモデリングだろうが、構造化手法によるモデリングだろうが、モデルという抽象化された情報から、テスト項目を抽出するアプローチって、基本が変る分けではないですから。
テスト設計する立場としては、システムの振る舞いについて、ある断面を表現したに過ぎない、１つのモデルを信じきっちゃうのは、テスト屋さんとしては怠惰だと思いますよ。
まぁ、できればモデルも複数の断面から表現されたものがあると良いのですが、モデルが揃いきるというのは現実ではなかなかありませんよね。
そこで、テスト設計する時には、モデルだけではなく、文章による仕様や過去のテスト項目、他には不具合情報などといったテスト対象のコンテキストをフルに活用しなくてはならないと思いますよ。
|
|
|
|
|
RUPやXPを初めとするアジャイルな開発モデルについては、ウォータフォールの基本が分っていない組織が飛びついたとしても、結局上手くいくことはないんじゃないかなぁと、考えています。
この点については、「基本から学ぶテストプロセス管理」(日経BP社)というTEFで監訳した書籍の後書きでも触れましたのでちょっと引用させてもらいますね。
「．．．開発組織やそこに属するエンジニアたちのソフトウェア開発に対する成熟度により、抱える悩みは千差万別だ。開発プロセスひとつとっても、ウォータフォール型、スパイラル型、いきあたりばったり型など１つの業種／業界内で開発規模が同程度であったとしても、定まったものはない。（中略）
武道や芸事では「型」が重んじられる。アート（技術）に関わる世界では、基本形を修得して初めて応用に進むことができる。この当たり前の事実は、ソフトウェア開発においても通用するだろうと思う」
|
|
|
|
＜テストでワクワク＞
|
|
|
|
渡辺
|
おっしゃるル通りです。武道の"型"っていい表現ですね。
個人的な悩みと言うか見解なんですが、テストは重要だと認識しているつもりなんだけど、実際には...
テストベンチ構築やテスト設計だけの作業を経験したことあるのですが、なんだがワクワクしなかったんですよ。何かいい方法というか、モチベーションの持ち方など、アドバイスありませんか？
|
|
|
|
大西
|
どうしてテストでワクワクしなかったんだと思いますか？
|
|
|
|
渡辺
|
うむぅ〜。ぶっちゃけ、設計とか開発という主人公でなくって、テスト屋さんって脇役とか裏方って偏見があるのかもしれない。勘違いしているのはわかっているけど、実際に作る人が一番的なイメージがあって、その作ったモノに対してダメ出しするって行為が何とも...
「このバグを見つけられなかったのは時間が無かったからだ!!...」って、作る側としては言い訳したい訳で。「バグを憎んで人を憎まず」って言われて来たけど、設計者としては自分(〜自信。〜の作った)の不具合って訳で。
|
|
|
|
大西
|
なるほど。渡辺さんが持たれているイメージは分るような気がします。
今のお話を聞いて、現役のテスト屋だった時に抱いていたジレンマを思い出しました。どういったものかを少しお話しさせてください。
|
|
|
|
|
テストでいくら自分が頑張って不具合を叩き出したとしても、改修するのは開発部隊ですし、別にソースコードに自分の名前が残るわけでもありません。また、ソフトウェアそのものを作っているわけではありませんでしたから、「開発者」でも無さそうですしプログラミングスキルが無くても、テストはできそうなので、スキルをそんなに問わなくても良いような気がしていました。
こういった背景があるため、開発者がテスト担当を一段下のエンジニアとして見てしまうという構図が出来上がるんだと思います。これは、日本に限ったことでは無いらしくて、私がアメリカの開発現場へ行ったときにも、妙にテスト部隊は開発部隊に遠慮していましたね。何となくラボ（システム開発専用の部屋）の雰囲気が、開発部隊の作業優先という感じだったからです。
私はといえば、そんな空気に怯むことなく、次期リリースに向けて開発中の機能の作成状況をチェックしたり、不具合改修担当の開発者と、改修方針について遠慮なくディスカッションをしましたけど。「日本のテスト屋をなめるなよ」という気概を持って、彼等とやりとりをしていたわけです。
|
|
|
|
|
どうしてテスト担当の私がこういった気概を持てたかというと、テスト屋のスキルは実はユニーク（独自のもの）だということをキャリアを通して、身をもって知ることができたからなんです。
実装に関わる開発者は全体仕様の一部しか知りませんし、俯瞰的な視点で、第3者が実装する機能のつながりを見ることが不得意だったり、システムとしての部分最適は考えられても、全体最適を検討することに、あまり興味がなかったりします。
一方、アーキテクトは全体最適は考えるのですが、実物の制約や、エンド・ユーザーの運用を考えた、最適化が本当にできる人っていうのは、私の経験からは少ないという印象を持っています。
テスト担当がシステム全体を見渡せるだけのスキルを身に着ければ、こういった領域をカバーすることができるんですよね。このためテスト屋さんとして、プロフェッショナルなスキルを身に着けるには、テスト技法だけでは足りなくて、テスト対象へのドメインスキルや、エンド･ユーザーの運用面も知らなくてはならないということになります。
|
|
|
|
|
次に、開発者としてのテストへの取り組みが後ろ向きになりがちだということに対してですが、コーディングが完了してからテスト項目を作っているようだと、ネガティブなものになるのは止むを得ないと思います。
最近はTDD（Test Driven Development)のテストファーストで提唱されている、テストケースを先に作ってから、コーディングするというスタイルがトレンドになってきています。こういった、アプローチをきちんとすれば、要件として在る程度明らかな、主たる正常機能だけではなく、例外処理や異常ケースについて、コーディング前にしっかり開発者自らが熟考できるわけです。
テストケースという形に仕様を論理的にブレークダウンすることで、仕様のモレなども事前に見つけることができますし、テストケースが通る、つまり検証が容易な形での実装につながります。検証が容易ということは、言い換えるとデバッグしやすく、保守も容易なコードになるはずなんです。コーディングを今以上に充実させるためにも、テストに積極的に取り組んでもらえればと思います。絶対に損はしませんから。(笑)
|
|
|
|
＜テスト本＞
|
|
|
|
渡辺
|
なるほど納得。
話を変え文献紹介コーナー。文献ポインタ集には反映済みだと思いますが、テスト関係のお勧め本を教えてくださいな。できれば、これから確実にテスト作業ができるようになりたいエントリーレベルのエンジニア向けと、テストのスペシャリスト向け。さらに中間のミドルレベルも教えて欲しいな。
|
|
|
|
大西
|
エントリーレベル向けでは、Myersの「ソフトウェア・テストの技法」(近代科学社)やKanerらの「基本から学ぶソフトウェアテスト」(日経BP社)の2冊をお薦めします。
Myersは、1970年代に書かれたものですが、今だにその基本は通じるものがあります。「基本から〜」は、その名の通り、テスト実務における基本的なノウハウが記されていますので、現場でも役に立つでしょう。
テストのスペシャリスト向けには、テスト技法を理論的にも学べるものとして、バイザー博士の「ソフトウェアテスト技法」(日経BP社)が読み応えがあると思います。
ミドルレベルの方には、テストフェーズのプロセスに着目したTim koomenらの「テストプロセス改善」(構造計画研究所)や、Elfriede
Dustinらの「自動ソフトウェアテスト」(ピアソン・エデュケーション)がテストツールを効果的かつ計画的に開発プロセスに組み入れてテストをする上で、大いに参考となるでしょう。
|
|
|
|
渡辺
|
最近発売された「基本から学ぶテストプロセス管理」(日経BP社)は大西さんが監訳者として参加していますよね？
これはどんなヒト向け？ これってソフトだけでなく、システム全体を対象にしたモノに思われ、これまでのソフトウェアのテスト本と少々、毛色が違うイメージに感じましたが。
|
|
|
|
大西
|
仰るとおり、これまでのテスト関連書籍からはユニークな書籍だと思います。というのも、ソフトウェア／ハードウェアテストに関わらず「テストをマネジメントする」という観点で解説できているからだと思います。
また、テストのコンサルという筆者のキャリアを活かした、実践的な内容となっています。一例としては、2章「テストプラン」では、テストプランの記載内容を持論を解説したうえでIEEE-829標準との相違を説明し、他のコンサルタントの例をも紹介しています。この様なアプローチは他にもみられ、模範解答を示すだけにとどまっていないところが本書の売りですね。
テストマネジメントの実践書ですので、テスト専任であるなしに関わらず、ソフトウェアテスティングに関わる組織のリーダを目指している方、もちろんテストフェーズのマネジメントを行なっている方々も対象となります。ですから、プロジェクトマネジャーや開発部門の管理者の方にも是非手にとってもらいたいですね。
|
|
|
|
渡辺
|
最後に、今後の組込みソフト業界やエンジニアに一言お願いします。
|
|
|
|
大西
|
世界から見た日本の組み込み機器といえば、軽薄短小であるにも関わらず、精緻で高性能、かつ高品質という一般的なイメージが、いまだに保たれていると思います。こういった良い印象は、この先、組み込みシステムにおけるソフトウェアの重要度が、今まで以上に増していったとしても維持できると信じています。
そのための重要なファクターが、テストスキルの底上げだと考えています。底上げといっているのは、基本的なテスト技法を学んだり、その機会がないエンジニアがまだまだ多いからです。このため、テストってなんだか面倒くさそう、だとか、つまらなさそうとか、誰でもできるやりがいのない作業といったネガティブなイメージを払拭できずにいます。
|
|
|
|
|
私としては、まずはテストの楽しさや、奥深さ、やりがいなんかを、日々のコンサルテーションやSESSAMEをはじめとするコミュニティ活動などで、少しでも多くのエンジニアに伝えていくことで、そんなイメージを前向きなものに変えていきたいと思っています。
|
|
|
|
渡辺
|
インタビューは以上です。ありがとうございました。これからも一緒に楽しみながらがんばりましょうね。
|
