続 いいテストエンジニアになるには ―テストエンジニアの三大美徳― 前編
こんにちは。SHIFTにて社内メンバーの能力開発をしている、タカハシです。
前回は「教師は五者たれ」にかけて、テストエンジニアの五者論を述べてみました。読んでいただいた方、ありがとうございます。
五者（学者・役者・医者・易者・芸者）を兼ね備えた人間力を磨きましょう、とまとめさせてもらいましたが、「あるべき姿」や「心構え」に近いようなものでした。
今回はもう少し、実際の業務に近づけて話をしようと思います。
ということで、「続 いいテストエンジニアになるには」です。
さて、プログラマーの世界ではあまりにも有名なラリー・ウォールのプログラマーの三大美徳をご存じの方も多いのではないでしょうか？優れたプログラマーの特性、どう行動すべきかを逆説的な言葉で明確に表しています。
これをテストエンジニアの世界に当てはめてみます。
ではまず、プログラマーの三大美徳ではどう言われているのかを見てみましょう。
プログラマーの三大美徳とは
Three Virtues
According to Larry Wall, the original author of the Perl programming language, there are three great virtues of a programmer; Laziness, Impatience and Hubris
1. Laziness: The quality that makes you go to great effort to reduce overall energy expenditure. It makes you write labor-saving programs that other people will find useful and document what you wrote so you don't have to answer so many questions about it.
2. Impatience: The anger you feel when the computer is being lazy. This makes you write programs that don't just react to your needs, but actually anticipate them. Or at least pretend to.
3. Hubris: The quality that makes you write (and maintain) programs that other people won't want to say bad things about.
怠惰(Laziness)
怠惰という言葉自体は、「なまけもの」のようにネガティブにとられることがありますが、そうではありません。
そもそもプログラム自体が定型的な作業をコンピューターに任せることでもありますが、全体での労力を下げるためにプログラムを書こう、ということです。それは自分のためだけでなく、多くの人たちの負荷を下げることにつながります。
楽ができるように、いいプログラムを作る労力を惜しまない、ということですね。
また、自分が作ったものを他の人が使う際、（面倒だから）質問が来ないよう、マニュアルなどのドキュメントを残すことも大切です。
短気(Impatience)
短気、これもあまりポジティブにはとられない言葉ですね。でもそうではありません。
せっかくプログラムを作っても、それが遅かったり使い物にならなくなったりしたらイライラしてしまいます。そのため短気な人は、そのような不快な状況にならないように先回りをし、起こりうる問題を想定したプログラムを書く、またはそのように努力します。
また、短気な人は仕様変更が嫌いです。仕様変更が起きないようにする、もしくは、仕様変更にも容易に対応できるように前もって仕込みをしておきます。
傲慢(Hubris)
一般的には謙虚さが美徳のように言われますが、それとは対極した言葉です。
「おれってサイコー」。つまり、自分の作ったプログラムが完璧なものだという絶対な自信を持つことです。プライドが高く傲慢なので、ほかの人に文句をつけさせない、人に見られても恥ずかしくない簡潔で美しいプログラムを作ります。もちろん、そのプログラムを使う人は快適に使え、最高のパフォーマンスを得ることができます。
この３つが並ぶと、知らない人が見れば、もはや悪口にしか聞こえないのですが、プログラマーの世界では目指すべき姿であり、賛辞です。
では、（いい）テストエンジニアとしてはこれをどう解釈し、テストの世界ではどう振る舞うべきか。具体的に考えていきましょう。
怠惰
人は誰でも、同じことは何度もやりたくないですよね。
（そうでもない、という人もいるかもなので、それは後述します。）
特にソフトウェアテストはもともとが「めんどくさいもの」と、とらえられがちです。
なにしろ、自分が作ったものは完璧だと思っている（傲慢な）のが、いいプログラマーですから。テストなんてしたくない。
でも、人はミスする生き物ですので、テストはしましょう。
でもでも、テストはめんどくさいので、効率よくやりたい。
もっと簡単に言えば、手を抜きたい。
例えばテスト設計。
いいものはパク、、、流用しましょう。
毎回、空のフォーマット持ってきて、いちから作っていたら大変です。
・案件内で過去作られたもの
・よく使うパターン
・イケてる先輩設計者が作ったもの
など、それらを流用することで、効率化はもちろん、実績があるものを使うことになるので高品質にもつながります。
最初から高品質なものを使うことでも、やはり全体の労力を下げられます。プログラムで共通部品を使うようなものですね。いいものはどんどん使いましょう。
（案件ごとにフォーマットが違ったり、案件内でも途中からフォーマットやルールが途中で変更になったりする場合もあるので注意です。）
また、ほかの人が流用しやすいように作りましょう。標準化やパターン化ですね。横展開ともいうでしょうか。案件内、部署内、会社内、様々な範囲がありますが、みんなが楽できるように常に意識しましょう。
自分ができることはあたり前で、誰でも出来るような仕組みを作れる人が、一流です。
例えばテスト実行。
テスト実行はそもそも、テスト設計書通りにコツコツ真面目にやるしかないし、それができる人がテストに向いているんじゃない？怠惰なんてもっての外でしょ？
一見その通りですが、果たしてそうでしょうか。
もちろん、「コツコツ真面目に」というのは大切な資質ですが、だからと言って効率よくやろうとする必要が無いわけではありません。
テスト実行をしていると、同じ操作が何度も出てくることがあります。
何度もログインする。
繰り返し同じ商品を買う。。
ひたすら壁をたたき続ける。。。
上から順に実行すると、何度もログインログアウトを繰り返すことになり、めんどくさい。「なんだよ、さっきもやったじゃん(怒)」ですね。
じゃあどうするか。急がば回れ、です。
テスト設計書を開いて、おもむろに上から順番に着手していませんか？
最初にざっと設計書を見て、全体像を掴み、どういう順番で実行したら効率が良いかを考えましょう。
順番を変えることによって一度にまとめてできるところがあるかもしれませんし、先にあっちをやらないとこっちが出来ないかもしれません。
※ただし、そもそも設計者が実行順も考慮した設計をしてくれていることや、一見回り道のようでもその順番に意味がある場合もあるので、順番を変えていいかは必ず確認しましょう。
エビデンス取得も比較的単調な作業です。
どうやったら効率よくできるのか。
ツールを使ったり、フォーマットをあらかじめ用意したり、少しでも手番を減らすことを考えましょう。また、案件内でルールや形式を統一しておくことも全体の効率化につながります。そういった、結果的に全体の効率化につながることにも労力を使いましょう。
ちなみに、
同じことを繰り返すことが苦にならない、むしろ喜びを感じる人もいます。
それは、その人が特異なのではなく、同じこと（のように見えるもの）の中でも楽しみを見つけたり、小さな改善を行い続けたりすることができるからだと思います。
全く同じことを繰り返しているのではなく、漸進しているのですね。
また同じ作業かよ、つまんねーな。
と思っていい仕事ができるでしょうか？生産性が上がる人がいるでしょうか？
また同じ作業か！よし、今度は前より上手くor早くやるぞ！！
と思えたらきっとよくなるでしょう。
風林火山で有名な戦国武将も、こう言っています。
一生懸命だと知恵が出る、中途半端だと愚痴が出る、いい加減だと言い訳が出る
――武田信玄
一生懸命、楽をしましょう。
さて、長くなってきましたので今回はこの辺にして、「短気」と「傲慢」は次回にします。
――――――――――――――――――――――――――――――――――
執筆者プロフィール：髙橋 朋裕
SIerにてSEとして、主に民間企業向けのシステム開発やパッケージソフト開発を経験した後、2019年にSHIFTに入社。
SHIFTでは、SHIFTグループ社員の人材育成を担う能力開発部門に従事している。主に社員の受入教育を担当しており、年間1000人の新卒・中途社員研修を一手に引き受けている。
お問合せはお気軽に
https://service.shiftinc.jp/contact/
SHIFTについて（コーポレートサイト）
https://www.shiftinc.jp/
SHIFTのサービスについて（サービスサイト）
https://service.shiftinc.jp/
SHIFTの導入事例
https://service.shiftinc.jp/case/
お役立ち資料はこちら
https://service.shiftinc.jp/resources/
SHIFTの採用情報はこちら
https://recruit.shiftinc.jp/career/