『お仕事はテストエンジニア⁉』出版 / テストエンジニア職に開発知識は不要なのか？
「お仕事はテストエンジニア!?」。エブリスタでは勤め人で特集を組んでくださいました。多くの方に読んでいただき感謝してもしきれないほどです。
この度Kindle本とペーパーバック(物理本)の出版を行いました。もしご興味ある方がおられましたら手に取っていただけましたら幸甚です。Kindle unlimitedにも登録しております。
概要は現代版の異世界転生無双ものです。GitHubも通じない部署で個人開発で培った知識と経験で、状況を整理・推理していく開発現場ストーリーです。
乙女ゲームの個人開発で生計を立てていた早乙女美月。
だが個人開発で食っていくことに限界を感じていた。
意を決して就活、お祈りの荒らしをくぐり抜けようやく開発者に…と思ったらテストエンジニア！？
聞いたこともない職種に回されてしまった美月。
配属された部署はGitHubさえ通じない世界（部署）だった！
乙女ゲー開発の知識と経験を活かし無双がはじまる！
「え、リリース明日！？」
不愛想な同僚、パワハラ上司、入社初日に終電逃し！
異色のITシステム開発現場の生々しい大奮闘ストーリー！
（ライトノベル）
目次
第一話『乙女ゲー開発者、テストエンジニアになる』
第二話『テストエンジニアってなに?』
第三話『入社初日から人間関係構築に失敗しました』
第四話『仕様書が雑じゃない?』
第五話『仕様漏れじゃない?』
第六話『テスト項目書が雑じゃない?』
第七話『それって隠蔽じゃない?』
第八話『グッバイ終電』
第九話『リリース当日に致命的なバグじゃない?』
第十話『エピローグ』
エブリスタで書いていただいた概要も掲載します。
乙女ゲーム沼に浸かった果てに、自分でゲームを作りたくなり、副業で個人開発をしていた早乙女美月。一念発起して会社を辞めて3年、限界を感じた美月は就活を始め、IT企業に採用が決まる。しかし彼女に与えられた仕事は開発者ではなく、テストエンジニアという未知の職種だった。そこで待っていたのはゆるふわ系の先輩と愛想の悪い猫系男子に、やる気の無い責任者。プログラムの端々が気になるが、その知識は必要無いと言われ……。現場を立て直すお仕事奮闘劇！
私の経験がベースとなっているライトノベル
このライトノベルは私の経験を多分に含めて書いています。私も個人開発をしていました。その後開発職に就こうとしたところ、当時人手不足だったテスター職になったという本文そのままの経験です。テストエンジニア、デバッガーといったソフトウェアテストを行う職、もしくはQAやQAエンジニアと呼ばれている品質保証（テスト含む）を行う職です。
自社開発アプリやゲームといくつかの現場を回りましたが、そこで開発やインフラ知識を持った方が極めて少ないと感じておりました。ライトノベルに書いたように、仕様通り動くか確認するために手を動かす要員、または人海戦術でのテスト要員として雇われた色合いを強く感じておりました。そこにおいて開発やインフラ知識を持った私は浮いていました。狙ってバグを出すことも多かったので尊敬されることもあれば、事実のみ伝えろと怒られることもありました。推測を挟むと開発側に誤ったバイアスを与えてしまう可能性があるためです。このような私の経験をライトノベルとして彩り執筆いたしました。
テストエンジニア職に開発知識は不要なのか？
ブラックボックステスト（中身を見ないで入力と出力でテスト）なので、そういった細かい知識はなくても大丈夫と言われることも多いです。つまり一般的にテストエンジニアまたはテスターと言った場合はシステムテスト（システム全体と結合し終わったあとの通しでのテスト）の領域で活動する人を指すように考えられます。
私の捉え方はライトノベルの序盤で主人公が考えた通りの開発プロセス全般のテストに携わるエンジニアかと思っていました。つまり全体を通して単体(ユニット)テストの戦略、結合テストの戦略、システムテストの戦略を立て、それらを技術を行使し効果的に効率的に行うエンジニアという捉え方です。このような捉え方をした場合は開発知識やインフラ知識は開発エンジニア同等に必要となるでしょう。それら知識が現在不要というのであれば先に述べた通りシステムテストエンジニアという考え方になるように思えます。
システムテストエンジニアとします。システムテストを考える際に、テスト観点を出す活動があります。どういったことやどういったパターンでテストをするのかを出す活動です。
言ってしまうと、内部の詳細や使っている技術の特性を知っている開発エンジニアのほうが詳細なテスト観点が出せます。この際に言われるのがユーザー観点という言葉ですが、開発者がユーザーの使い方にまつわる観点が持てないかというとそんなことはありません。言い換えるとテストエンジニアが出すテスト観点に加えて内部からの観点を出すことができます。こうなってしまうとテストエンジニアのスペシャリティとは何かということになってしまいます。テスト観点を出すときはどれだけ引き出しを持っているかが重要となります。テストエンジニアにその引き出しの数が求められるのであれば、開発知識やインフラ知識もあったほうがよいと考えることが妥当です。
私が考える(理想とする)テストエンジニア
これまでのような話があると、次はテスト技法の話が出てくるかと思われます。もちろんユニットテストに1から100まで並べてテストは書きません。同値分割法です。最大値、最小値やnullのテストは真っ先に思い浮かぶでしょう。境界値分析です。パターンを出すためにはデシジョンテーブル(決定表)を使うことだってあります。こうなってくるといよいよもってテストエンジニアのスペシャリティは何かと考えてしまいます。
私が考えるテストエンジニアは先に述べた通り、開発プロセス全体のテストについて戦略を立て、開発プロセス全体のテストを技術を用いて最適化するエンジニアです。開発プロセス全体のテスト活動を主導するエンジニアであり職能です。システムテストだけではなくです。フロントサイドエンジニアはフロントでのスペシャリティ、サーバーサイドエンジニアはサーバーでのスペシャリティ、並列してテストエンジニアはテストでのスペシャリティです。
今のところ続編の執筆予定はありませんが、もし今後書くとしたら上記で述べたような考えに基づいたお話になりそうです。