こんにちは。SHIFTにて社内メンバーの能力開発をしている、タカハシです。

前回は「続 いいテストエンジニアになるには」の前編として、プログラマーの三大美徳（怠惰、短気、傲慢）にかけたテストエンジニアの三大美徳の内、「怠惰」について述べました。

なまけものなので、楽をするために一生懸命考えましょう、ということですね。

後編では、「短気」と「傲慢」について述べてみましょう。

短気

誰しもが振り回されるのは嫌です。
自分のペースで進められない時ほど、イラッとすることはありません。

「お、乗ってきたぞ」というときに限って、何か起きます。

ではどうするか？
先回りしましょう。


例えばテスト設計。

設計作業をしていると、少なからず疑問点や不明点が出てきます。インプットとしている資料に必要なことが書かれていなかったり、書かれていても曖昧だったり、不整合があったり、そもそもまだ作り途中だったり。。。

そうなると手が止まり、思うように進まないことにイライラが溜まってきます。でも、イライラしてもいいことはありません。

イライラする →作業品質が落ちる →ミスによる手直しが発生する →生産性下がる →ますますイライラする。

悪循環です。それを防ぐためには、不明点を先に押さえておきましょう。

行き当たりばったりではなく、明確にしておかなければならないことを先に見極め、作業指示者や顧客なりに質問しましょう。

質問する際も、いつまでにどんな回答が欲しいのか、そこを明確にしておかないと、欲しい回答が必要な時までに来ず、結局解消しないので注意です。

また、プログラマーも一緒ですが、仕様変更はめんどくさいものです。仕様変更にともないテスト設計がやり直しになるのには耐えられません。

そうならないように先回りをし、仕様変更につながりそうな仕様の不備やあいまいな点は先に顧客に指摘し、テスト設計前に修正してもらうよう動きましょう。

あとになるほど影響が大きくなるので、先に潰すのが鉄則です。そしてそれは、私たちの精神衛生の向上だけでなく、顧客価値の向上にもつながるでしょう。


例えば、テスト実行。

テスト実行も同じで、思うように進められないことが一番イライラします。

テスト設計書の不備、
テスト環境の不備、、
テストデータの不備、、、

これらによって手が止まってしまっては、テンポよく作業ができませんし、何より手空きが発生してしまうかもしれません。こちらの準備はできているのにやることが無い。これはとても切ないものです。

また、手空きでも工数が発生してしまいますよね。やはりこれも、お客様からいただくお金をドブに捨てるようなものです。

手が止まるというのは、価値を生まない時間を発生させることになります。手が止まるだけでも嫌なのに、ましてや、やり直しなんてもってのほかです。これほどムダかつモチベーションを下げるものはありません。

テスト設計書は揃っているか、不備は無いか、
テスト環境は整っているか、不備は無いか、、
テストデータは揃っているか、不備は無いか、、、

挙げればキリがありませんが、効率の良い仕事は準備で決まると言っても過言ではないでしょう。誰かがお膳立てしてくれるのを待っていても仕方ありません。自分から動く、自分から確認しましょう。

「段取り８分の、仕事２分」です。

準備にしっかり時間をかけることが、全体の仕事の効率化につながります。

傲慢

自分のアウトプットには絶対の自信を持ちましょう。そもそも、自信のないアウトプットなんて、顧客は望んでいませんし、見たくありません！よく考えると、当たり前のことです。

例えば、テスト設計。

実行者や顧客から突っ込まれない、完璧な設計書を作るよう心掛けましょう。なぜこのテスト内容なのか、これで必要十分なのか、そして美しいのか。

人の目につく際には、きちんとレビューをしましょう。もちろんセルフレビューも、です。そのアウトプットに責任を持つのは、その人自身です。

そして、必ず自分の言葉で説明できることが大切です。
「怠惰」で話したように、標準化することは大事です。

でも、その意味や目的も分からずにパクリ、「標準がこうなってるんで」とか「前の案件ではこうでした」とか「○○さんがこうやってたんで」と言ってしまうのは最悪です。流用してくるだけなら、その仕事をするのは「あなた」である必要が無いのです。誰でもいい、機械にでもやらせておけばいい。

そうではなく、「あなた」だから出来る最高のアウトプットを作りましょう。

また、必ずしも自身で内容の説明を出来るケースばかりではありませんので、アウトプットだけでも第三者が理解できる、そして質問する必要が無いように意図や本質が分かるような設計書を書きましょう。そのために具体的であり、かつ、誤解を生まないように簡潔に書く、ということを常に意識しましょう。

※育成の観点等から、あえて質問ポイントを残しておいて質問対応から気づきを与える、というテクニックもあるので、これも一概には言えませんが。


例えば、テスト実行。

テスト実行での主なアウトプットと言えば、

①テスト結果（OK／NG）
②エビデンス
③起票（チケットや障害・課題報告も同義）

①は言わずもがなです。
これが間違っては元も子もないので、テスト設計に書かれている内容に即しているのか、場合によっては設計者の意図も読み取りながら、確実に登録しましょう。

②エビデンスも重要です。
取得方法（ツール等）や粒度（エラーだけか正常系もか等）は様々ですが、誰が見ても分かる、説明不要なエビデンスを取ることを心がけましょう。

・必要な範囲が含まれている、かつ、余分なところが無い
・操作の流れが分かる
・（エラーであれば）どこがどうNGなのかが分かる

などが満たされているか、確認しましょう。なにしろ、エビデンス（証拠）ですから。中途半端では意味がありませんし、取り直すようなことがあれば、それこそムダです。

③起票もエビデンスとほぼ同様です。
書式や記述内容は様々ですが、誰が読んでも分かる、説明不要な起票を心がけましょう。

起票した後に、「これどういうこと？」と聞かれるのは面倒ですし、聞かれればまだいいものの、顧客や開発者が誤解してしまい、意図したものとは異なる修正をしてしまっては自分だけではなくプロジェクト全体でもムダな作業となってしまいます。それは避けなければいけません。

そのために、やはりここでも「具体的かつ簡潔」に記述することが肝要です。誰が読んでも文句のつけようのない、完璧な起票を目指しましょう。

まとめ

こうしてみると、「怠惰・短気・傲慢」という三大美徳は、なにもプログラマーに限定したものではなく、エンジニアとして、ひいては、その他多くの業務においても当てはまるものだと思います。

楽になるように考え、先回りをし、自分にしかできない最高のものを作ることを常に心掛けましょう。そして、それを誰しもができるような仕組みにすることが、より大切です。

ともすれば人は、自分の作業領域、自分しかできないことを守っておきたくなります。でも、それを誰でもできるようにすることが最高峰です。

そうすれば、あなたはより高い次元、次のステップに進めるわけですから。三つの美徳を意識し、いいアウトプットを作っていきましょう。

ちなみに余談（妄想？）ですが、テストエンジニアが一番楽をするためには、つまり究極には、テストなんてしない世界、テストエンジニアなんていらない世界、これが理想だと思っています。

だってテストしなくていいんですから。それが一番楽。
早くその世界を作って、みんなで違うことしましょう(笑)

さて、"五"者説、"三"大美徳ときたので次も数字に絡めて、テストエンジニア論を述べたいと思います。

次回、 いいテストエンジニアになるには三部作 完結編！？
数字は何で、どう展開していくのか！？お楽しみに。

なんだかんだ言いましたが、勤勉で、忍耐があり、謙虚な人ですね、と言われたい、今日この頃です。

――――――――――――――――――――――――――――――――――

お問合せはお気軽に
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/