諦めのテストエンジニア
先だって、テスト界隈の方とディスカッションをする機会があった。その方は、所謂テストエンジニア、なのだそうだ。テスト工程のプロセスデザインについて関心があるのだという。
ご相談といか、お話をされたいということなので、まずは何に関心を持たれてお声がけをいただいたかを伺う。人は関心事があるとき、話すだけで自己解決することもある。兎にも角にも、お話を聴く。
ディスカッションをしたいのは、テストエンジニアにプロセスデザインを学ぶ機会を設けたいのだそうだ。なぜなら、テストに関わるテストエンジニア、テストオペレータはプロジェクトの度に、毎回、要件の整理、開発の工程を延ばされ、テストに残される時間がほとんどないため、半ば諦めで仕事をしている、だという。
圧縮される期間でできることは限られる。できることしかできない。でも、やらなければならない。こうした現実の中で仕事をしている。だから、外を見ようとする余裕もない。
もともと、テストエンジニアは開発の中でできないエンジニアに作業をさせていた歴史的経緯があったから、開発エンジニアからも下に見られている、という。
そうなのだろうか。
最近、テスト専門会社が上場したり、テストの自動化などでテストエンジニア界隈は、自分にとってとても必要性の高いエンジニアだと思っていた。ところが、お話を伺うとそうでもないようだ。
自分の認識と伺っていて思ったことは、多分、両方の面があるのだろうと。最新のテスト技術を駆使してテスト自動化に取り組むエンジニアもいれば、従来の開発のしわ寄せで四苦八苦しているテストエンジニアもいるということなのだろう。
こうした悩みの理由の一つに、工程を分断し過ぎてエンジニアが単機能工と化しているのではないか、と思うのだがどうだろうか。
開発エンジニアも然りである。仕様は降りてくるものだ、と口を開けて待っているエンジニアも仕様が出てくるの待ち、削りに削られた工程の突貫工事のような仕事をしているのと何も変わらないのではないだろうか。
聴きながら、頭の中では何を期待しているかを考える。
ただ、間違っても正論は期待されていない。正論を持ち出すと話は一瞬で終わってしまうだろう。
人は話したいとき、まずは聞いてほしいものだ。その上で、何かヒント程度のものが得られたら嬉しいのである。
下に見られていることも、ひどいスケジュールでテストをすることも実際の現場であるのだろう。ただ、全員がそうではない。ただ、現状はテストエンジニアがいなければソフトウェアはリリースされないにも関わらず、パワーバランスがおかしい現場があるということである。
あと、結果的にテスト工程に閉じこもっているのでプロジェクトの情報を把握しきれていないという見方もできる。
- 単機能工と化している
- パワーバランスがおかしい
- プロジェクト情報を把握しきれていない
伝えたことは、この3点である。これをブレークスルーする切り口が見つけられれば、少しは環境を変えられるのではないか、と。
何か気づいたような表情をして、一礼された。
