経験者が語る、プログラマがテストエンジニアになるということ
こんにちは、第3バイオリンです。
先週は夏休みだったので実家に帰省しておりました。久々に両親や妹、実家で飼っている犬に会い、のんびりしてきました。
実家でもエンジニアライフは毎日欠かさずチェックしていましたが、森姫さんのコラムを読んでにゃん太郎さんのコラムにコメントしているうちに、改めて「プログラマがテストエンジニアに転向する」ということについて考えてみたくなりました。
誤解のないよう先に伝えておきますが、森姫さんのコラムに対する反論ではありません。ただ、テストエンジニアとして働いて1年経ったいま、自分にとってプログラマの経験が何だったのか、振り返ってみたくなったのです。
■評価部署への異動＝左遷？
過去のわたしのコラムを読んだことがある方はすでにご存じだと思いますが、わたしはもともと開発部署で働くプログラマでした。そして、心の調子を崩して開発部署から離れました。
心の調子を崩してから開発部署を離れるまでの約4カ月間、わたしは開発部署に所属したまま、当時携わっていたプロジェクトのドキュメント整備や成果物の構成管理といった補佐的な作業をしていました。
開発部署に所属しながら開発に携わらないというポジジョンは、当時のわたしにとっては中途半端なものでした。「プログラミングができないわたしの存在価値って何なの？」と真剣に悩みました。しかしそれは最初の1カ月くらいで、その後は「わたしには開発よりもむしろ補佐的な役割のほうが向いているのではないか」と思うようになってきました。
そんなとき、当時の部長がわたしを呼んでいいました。
「来期から評価部署を一新する。今後は開発の上流工程からテストエンジニアがかかわれるようにしたいと思っている。そのためには開発経験があって、開発の事情をある程度わかっている人が必要だ。そこで、第3バイオリンさんに異動してもらいたい」
その話を聞いたとき、最初は次のように思いました。
「これって見ようによっては左遷だよね。まあ、プログラミングができなくなった以上、開発部署にはいられないと思っていたし、仕方ないか」
しかし一方で、こんな考えも浮かびました。
「でも、わたしって開発の補佐的な業務の方が向いていそうだし、評価の方が合うかもしれない。この話、もしかしてチャンスかもしれない」
多少複雑な思いを抱えたまま、わたしは異動の話に合意しました。
■元プログラマであることは有利か不利か
こうして「元プログラマのテストエンジニア」として、わたしの新たなキャリアがスタートしました。実際にテストエンジニアとして働いてみて、元プログラマであることのメリットとデメリットについて考えてみました。
【メリット】
●開発チームに歩み寄ることができる
テストをしていると、開発チームに対して仕様書その他のドキュメントの書き方など、要望がいろいろ出てきます。また、わたしの部署はテスト業務のほかにも、開発業務の効率化を図るための活動をしており、さまざまな改善策を開発部署に提案しています。
しかし、そういった要望／提案はたいていの場合、開発側の作業を増やしたり、これまでのやり方を変えさせたりするものです。それが開発メンバーにとってテストエンジニアが想像する以上の負担になることもあるので、長い目で見れば、開発側のためになることでも簡単には受け入れてもらえないことがあります。
こういうときに開発の現場を知っていると、開発メンバーにとって何がどれだけ負担になるかがある程度は検討がつきます。だから、単に「ちゃんとやってよ！」というだけでなく、開発メンバーにとって負担が少ない方法を考えて提案することができます。
実際のところどれだけ歩み寄れているのかはわかりませんが、少なくとも歩み寄りたいという意思は伝わっているのではないかと思っています。
●ツールのスクリプトの作成・修正が早い
テストでは作業の効率化を図るためにツールを使うことがあります。その中には、自分でスクリプトを組んでツールに読み込ませて動かすタイプのものがあります。
プログラミング経験がないテストエンジニアの場合、スクリプト作成に手間取ったり、作成したスクリプトがうまく動かないときに何が原因かすぐにわからないことがあったりします。一方、プログラミング経験があるわたしはスクリプトに対する抵抗感がないのですぐに作成方法を覚えられます。また、ログを取ったりエラーメッセージを解析したりという作業に慣れているので、うまく動かないときもすぐに原因を特定してスクリプトを修正することができます。
【デメリット】
●開発の事情にほだされる
これは1つ目のメリットの裏返しですね。なまじ開発の事情を知っている分、「開発チームもいろいろ大変だし、無理な注文はできないな」と余計な意思が働いて、あまり強くいえないことがあります。
とはいえバグに関しては「このタイミングでバグを見つけたなんていいづらい……」と思っても強くいうようにしています。後で困るのは開発と評価の両方なのですから。
●過去の自分の嫌な部分を再認識してしまう
プログラマだったころ、わたしはテストを甘くみていました。はっきりいうと「誰でもできる仕事」だと思っていました。
テストエンジニアから仕様書の内容について意見されても「何でそこまで書かなくちゃいけないわけ？」と内心疎ましく思っていました。
しかしテストエンジニアになってから、立場が逆転しました。テストが誰にでもできる仕事でないことはわかりましたが、同時にテストに対して無理解な開発担当者とのバトルが始まりました。これが因果応報というやつでしょうか。まあ、普段からテストとテストエンジニアを大切に思っているプログラマであれば、こういうデメリットとは無縁ですよね。
■テストを知っていれば開発に役に立つ
わたしはプログラマとして挫折し、半分は自らの希望でテストエンジニアになりました。なので、開発からテストに異動して「不本意だ！」と思っている人にとっては、わたしの経験はあまり参考にならないかもしれません。
しかし、開発の経験があることは必ずテストに役立ちます。さらに、再び開発に戻るときにはテストの経験が絶対に生きてくると思います。
わたし自身、開発から評価に異動して良かったと思うことはプロジェクトの全体が見えるようになったということです。プロジェクトというものが、自分の工程だけでなくいろいろな人がかかわっていることを実感することができました。
しかし一方で、プロジェクトに直接的、間接的に携わるいろいろな人の思惑（俗にいう「大人の事情」を含む）が嫌でも目につくようになりました。これはテクニカルスキルではどうにもならない問題です。正直いって、立ち向かうのはキツイです。
でもそういう問題に向き合いながら、わたしは予備知識のない相手に自分の意見を伝えるためにはどういえばいいか、助けが必要なときには誰に何をいえばいいか学べたと思っています（もちろん、開発の現場でこういうことをきちんと学べる人もいると思います）。
わたしは、仮に今すぐ開発に戻ることになれば、少なくとも以前よりは上手く立ち回れると思っています。今のところ戻る意思はありませんが。
コメント
森姫
第3バイオリン様、はじめまして。森姫です。
プログラマ→テストエンジニアなコラムを以前書きましたが、
元会社での詳細をお話しすると
プログラマ→テストエンジニア→プログラマ→テストエンジニア
といったところです。2つの部署を行ったり来たりなんですよね（汗）
第3バイオリンさんがコラムにも書かれているとおり、開発よりの評価ができる人って言うのはとても重要なんですよね。
メリットもデメリットもよくわかります。
たしかに、あとの方で見つけたバグってすごくいいづらいし、
ロジックの観点から見れるテストというのはなかなかないので・・・。
開発VSテスト というのも体験しているので険悪になるのもわかります。
といっても文章だけで対決しているのですが(笑)
例：○○なバグがみつかりました。修正してください。VS ここでバグるのはありえない！！
今度開発に戻れたら。テストのことも考慮した
開発VSテスト
のようにならないようなプログラマになりたいです。
しばらくはテストエンジニアとしての貴重な体験をしようと思います。
これも勉強ですね。とてもいい勉強になると思います。
とても貴重なお言葉のコラムありがとうございました。
第3バイオリン
森姫さん
はじめまして。あずKさんよりご紹介賜りました（笑）第3バイオリンです。
コメントありがとうございます。
>元会社での詳細をお話しすると
>プログラマ→テストエンジニア→プログラマ→テストエンジニア
>といったところです。2つの部署を行ったり来たりなんですよね（汗）
またそれは大変ですね。
私よりも大変かも・・・わー、なんか偉そうなこと言っちゃったかも（大汗）
>第3バイオリンさんがコラムにも書かれているとおり、開発よりの評価ができる人
>って言うのはとても重要なんですよね。
開発に言われたことをするだけでなく、開発チームにテストのやり方を提言したり、そもそもバグのないプログラムを作るために助言したりするには、ある程度開発のことを知っていないと難しいと思います。
もちろん開発経験がなくても問題点に気が付く人もいますが、
開発経験のある人のほうが、問題の背景や、解決策にまで踏み込みやすいです。
>開発VSテスト というのも体験しているので険悪になるのもわかります。
どちらも「良いものを作りたい」という目的は同じはずなのに、
険悪になってしまうんですよね。なんでだろう？
>今度開発に戻れたら。テストのことも考慮した
>開発VSテスト
>のようにならないようなプログラマになりたいです。
森姫さんのように考えてくださる人が増えれば、開発とテストの関係ももっと良くなると思います。
今は思い通りにいかないことも多いと思いますが、エンジニアとして伸び盛りの時期に経験したことは絶対あとで身を助けてくれます。
お互い頑張っていきましょう。
ビガー
ビガーと申します。
森姫さんのコラムにもテストについて思うところを書いたのですが、少々失礼します。
エンジニアのスキルアップとしてのテストにおける最大のメリットは、リーディングしていける人材に近づいていけることだと思います。リーディングするには実装やテスト以外にもさまざまなスキルが必要(森姫さんのコラムにコメントしました)です。
リーディングできる人材は、市場価値が高く、このご時世でも自分の望んだ仕事を獲得できるチャンスを呼び込めます。そういった意味でもテストエンジニアをすることによる価値は、やり方次第の部分もありますが、高いと思いますね。
あずK
自分の名前が書かれていたので思わず投稿しました（笑）
自分は残念ながらテストエンジニアの経験はありませんが、
プログラマ→運用（業務が主体の）エンジニアへ転進した身として興味深く読ませて頂きました。
運用業務上でもちょっとしたマクロを組むと便利なことがあるので、
スクリプトの件は共感できました。
「大人の事情が見える」点も、そうですね・・・（苦笑）
ただ、自分の今の（部署での）仕事が運用主体とはいえ、
開発の部署で作ったシステムの運用ではなく
部署固有のWebサービスの運用がメインなので、
開発の部署と仕事上でのやり取りがあまり無いのが残念なところです。
もし、開発の部署で作ったシステムを運用するという話になると、
運用者の視点から、こうすべきだと開発者に指摘して
プロジェクトを進めたい（参加したい）という気持ちはあります。
恐らく対立はしてしまうのかもしれませんが…。
開発者には運用面からの視点って、あまり無いと思うので。
＃自分もプログラミング一辺倒のときは、運用の視点は無かったですから…。
そう考えると、エンジニアって、
開発ばかりではなくて、テストや運用や他のことなど色々と経験した方がいいですよね。
それぞれの立場（目線）でシステムを見られれば、その分、
いいシステムが作れると思うので。
インドリ
おはようございます第3バイオリンさん。
プログラマとテストエンジニアは両方体験しておくべき事だと思います。
テストをした事がないプログラマが書いたプログラムは、往々にしてバグが入り込む余地が多いです（攻撃的プログラミングとかを知らない）
また、プログラマの経験が無いテストエンジニアはより深いテストが出来ず最後の砦になっていません。
その点両方を経験していれば、バッファオーバーフローを検出したりも出来るかもしれません。
不景気の時はエンドユーザーの目も冷え込みますので、今後より一層バグとセキュリティに厳しい目が向けられると思います。
その中で必要とされているのは、両方を経験した人や両方の能力を持つ人だと私は考えております。
にゃん太郎
第3バイオリンさん、おはようございます。
前回はコラムにコメントありがとうございました。
私はシステム開発においてテスト工程は製造工程と切り離すべきだと思っていま
すし、コラムにもそのような事を書きました。コメント中に例えで書いたプロ野球
のピッチャーと同じで今は先発完投ではなく分業が理想だと思います。ただ、SEと
プログラマは再編してひとつにした方が良いとは考えていますが。
テストエンジニアが難しいと感じるのは「素人」の目と「玄人」の目の両方が必
要なところです。プログラムにもある程度精通していなくてはならないですし、素
人のようにめちゃくちゃやってみる事も必要です。だから世間で思われているイメ
ージよりは高度なポジションだと思います。
プログラマはその立ち位置からPMやSEなどからプログラムの品質が悪いと注意を
受けます。その上、テストエンジニアからバグを発見され報告されるともう自分自
身のやり場がなくなって「開発vsテスト」になってしまいがちです。
本来はこういうのは会社としてきちんと教育していくべき事でしょうが、理屈で
言っても･･･ですから第3バイオリンさんのようなプログラマ経験者がテストチーム
には不可欠になります。
今は小さなシステムでも内容はかなり複雑になっています。社会情勢も相まって
エンジニア自体がこれまでと同じ考えで作業をするには厳しい時代になってきまし
た。テストエンジニアは品質保証の要となるため、作業自体は製造工程と別でもコ
ミュニケーションは密にしてお互いが良いシステムをつくりあげるために協業して
行けるようにするためにも第3バイオリンさんには頑張って欲しいと思います。
第3バイオリン
ビガーさん
コメントありがとうございます。
>エンジニアのスキルアップとしてのテストにおける最大のメリットは、
>リーディングしていける人材に近づいていけることだと思います。
それは私も思います。
テストエンジニアをしていると、テスト対象物の仕様に関する造詣、
違う立場（開発者から一般ユーザーまで）の目線でものごとを見る力、
社内外の関係者との調整力など、エンジニアとしての総合力が求められます。
私自身もテストリーダーをしているので、この総合力がリーダーには必要不可欠であることがわかります。
今の私はまだまだ力不足ですが、この先もいろいろな仕事を乗り越えて、
総合力を付けていきたいです。
第3バイオリン
あずKさん
>自分の名前が書かれていたので思わず投稿しました（笑）
ありがとうございます。
（森姫さんのコラムのコメントを読んでない人には、何のことかわからないでしょうね）
>運用業務上でもちょっとしたマクロを組むと便利なことがあるので、
>スクリプトの件は共感できました。
評価に移ったときは「もうプログラミングをすることはないだろう」と思っていましたが、それに近いことは意外とやりますよね。
スクリプト以外にも、昔開発で関わっていたモジュールと機能が良く似たリリース物の評価を依頼されたりすると、「こんなところであの時身につけた知識が役に立つとは」と思うこともあります。
>「大人の事情が見える」点も、そうですね・・・（苦笑）
開発チームとその上長、自分の部署の上長、顧客etc...本当にいろいろな立場の人と関わりますからね。
ここまでいろいろな人と関わるポジションはあまりないですよね。
>運用者の視点から、こうすべきだと開発者に指摘して
>プロジェクトを進めたい（参加したい）という気持ちはあります。
今後はそういう活動が必要になると思います。
まだ表立って動いている企業は多くないでしょうし、動いているところも
すぐには結果が出せないと思いますが、開発から言われたことだけ
淡々とやる、というテストや運用ではもう通用しないと思います。
>そう考えると、エンジニアって、
>開発ばかりではなくて、テストや運用や他のことなど色々と経験した方がいいですよね。
>それぞれの立場（目線）でシステムを見られれば、その分、
>いいシステムが作れると思うので。
私の会社では、新人研修のときにテスト演習というのをやっているみたいです。
ただ、それも2～3年前からで、私のときにはありませんでした。
新人さんたちからは「テストの大切さがわかった」「設計・実装の段階からテストを意識したい」という感想があるそうです。配属後もその気持ちを忘れないでほしいです。
第3バイオリン
インドリさん
コメントありがとうございます。
>テストをした事がないプログラマが書いたプログラムは、往々にしてバグが入り込む余地が多いです
>（攻撃的プログラミングとかを知らない）
あずKさんへのコメントにも書きましたが、私の会社で開発希望の新人さんにテスト演習をさせると「設計・実装でバグを減らし、テストしやすい仕様書やソースコードを作るように注意したい」という感想がほとんどです（配属後もそれを忘れないでほしいところです）。
つまりそれまでは、テストのことなんて頭になくてただ「動けばいい」という気持ちでプログラムを作成していたといえます。これはちょっと怖いなと思いました。
（かくいう私はその「怖い状態」で配属されてしまったのですが）
>また、プログラマの経験が無いテストエンジニアはより深いテストが出来ず最後の砦になっていません。
新人から「ブラックボックステストとグレーボックステストの違いがわからない」と質問され、
私は「ソースコードの内容を知らなくても事前に境界値がわかればそこを狙える。それがグレーボックス」と回答しました。
プログラマの経験があれば仕様書から境界値など、バグが出そうなポイントが何となくわかります。
仕様書の行間を読む力でしょうか。
>不景気の時はエンドユーザーの目も冷え込みますので、今後より一層バグとセキュリティに厳しい目が向けられると思います。
私も品質に関しては今後ますますユーザーの目が厳しくなっていくと思っています。
もはやバグが出ないのが当たり前の世界ですからね。
第3バイオリン
にゃん太郎さん
こちらこそ、コメントありがとうございます。
>テストエンジニアが難しいと感じるのは「素人」の目と「玄人」の目の両方が
>必要なところです。
仕様書に書いてあることをテストするのはもちろんですが、
書いてないことをどうテストするかが難しいところです。
何せ「書いてないこと」なので「何も知らないユーザーだったらどう使うか」を想像しなくてはなりません。
その一方でテスト対象物の仕様はきちんと把握していないといけない・・・なんだか矛盾していますが両方できないといけません。本当に難しい！
>プログラマはその立ち位置からPMやSEなどからプログラムの品質が悪いと注意を
>受けます。その上、テストエンジニアからバグを発見され報告されるともう自分自
>身のやり場がなくなって「開発vsテスト」になってしまいがちです。
これは私も経験者なのでよくわかります（汗）。
「頼むからそんなに責めないでくれよ」と、追い詰められたような気分になってしまいます。
最近は私の会社でも新人研修でテストの演習をしています。
新人たちがテストの重要性と、決して開発者を責めるためのものではないことをわかってほしいと思います。
>今は小さなシステムでも内容はかなり複雑になっています。社会情勢も相まって
>エンジニア自体がこれまでと同じ考えで作業をするには厳しい時代になってきました。
インドリさんへのコメントにも書きましたが、品質に対するユーザーの意識は
どんどん高まっていると思います。
今後ますますテストエンジニアの役割は大きくなっていくと思っています。
明日のために、今できることを積み重ねていきたいです。
とものぶ
はじめまして、とものぶと申します。
自分は携帯電話のテストを担当しています
プログラマとしての経験はありませんが、テストチームで使うスクリプトやCGIなどを大量にプログラムしているお陰で、プログラマの皆さんの苦労をちょっとばかり味わっています。
開発VSテストの構図が生まれないようにするには、管理職も含めて関係者全員の意識改革が必要だと考えています。
「所詮、人間が作るものに完璧なモノはない」ので、バグが発生するのは避けようがないです。（無いほうがいいのは当然なので、減らす努力は当然必要ですよ）
なので、バグが混入したことをマイナス評価にしないで、逆にキチンと直したことをプラス評価にしてあげると、開発者も頑張ってバグを直してくれるんじゃないかと思っています。
バグ件数が多い場合は、別の理由があるのでそれとは切り離して評価して欲しいですね。
（設計ミスとか、プログラマのスキル不足とか、根本的なところのバグで結局同一問題だったとか）
また、テスト側も開発者を馬鹿にしたりしないで、「見つけちゃってすみません。今日も徹夜ですね(-人-)ごめんよおぉ」くらいの気持ちでいてあげるとバランスが良いのでは。。。
やはり、テストの経験があるとプログラムしている時にいろいろと注意するようになるので、プログラマの皆さんにも経験してもらいたいですね。
第3バイオリンさんも、いいテストエンジニアを目指してがんばってください。
第3バイオリン
とものぶさん
はじめまして、コメントありがとうございます。
>開発VSテストの構図が生まれないようにするには、管理職も含めて関係者全員の
>意識改革が必要だと考えています。
そうですね。
バグを出すこと自体は悪いことではありません。
肝心なのは見つかったバグをどう修正するか、次回以降で似たようなバグを出さないようにするにはどうすればいいかです。
開発者を責めるためにバグを見つけているわけではなく、良いものを作り出すためにやっているということを開発とテストの両方が意識することが大切だと思います。
>やはり、テストの経験があるとプログラムしている時にいろいろと注意するようになるので、
>プログラマの皆さんにも経験してもらいたいですね。
私も、一度はテストの作業がどういうものか（仕様書からチェックリストを起こしてテストするまで）経験してほしいと思っています。
（私の会社は研修でテストをやっていますが、そういうところはまだ少ないかも・・・）
>第3バイオリンさんも、いいテストエンジニアを目指してがんばってください。
ありがとうございます。
今は道半ばですが、必ず開発もテストも幸せにできるようなテストエンジニアになりたいです。