HinodeLabo システム開発 QAテストチーム マネージャー宮本のご紹介

今回は、HinodeLabo社テストチーム マネージャーの宮本をご紹介致します。過去のテスト経験やHinodeLabo社で関わったことがあるプロジェクトのご紹介、テスト時に気をつけている点、オフショア開発チームの中で日本人テスターとして、どういう点に注意してベトナムチームに指示を出しているかなどを執筆したいと思います。

前職での経験やテスターになった背景

HinodeLaboにてテスターを勤めております、宮本と申します。よろしくお願いいたします。

まずテスターになった背景からお話させていただくと、実は、この業界に関わる以前に介護士という全く無関係の業種に勤めておりました。
介護という仕事も肉体労働というイメージが強い一方で、認知症という現在は不治の病である病状といざ直面してみると、本当に複雑なプロセスが絡み合うもので、介護用語で「傾聴」と呼ばれるような、ただ単純に要介護者の話を聞くだけでは落ち着かない状態になってしまったりと、受講や教科書に応じたテンプレート通りの行動だと意外なほどよい結果にならず、というよりかは「テンプレートやマニュアルがアップデートされていない」というのが介護業界の実情です。

とはいえ、業界全体としての伸び代は介護保険制度に依存するものですから早期の成長が期待できることもなく、身を置いていてこれ以上自身の成長となることはないかもしれない、と感じたのが転職のきっかけとなります。

それからは介護業界である程度過ごした自分がそこから離れ、なにかできることはないかと考えていたところ、趣味として幼少期から様々な「ゲーム」を遊んでいたことがデバッグ企業を発見する手がかりとなりました。
（ゲームが好きなので業界になにか携われないか探していた経緯もあります。）

テレビゲーム、などと呼称されることが多い所謂ビデオゲームですが、世間としては「経験等が自身のプラスにならない」「貧乏人や暇人の趣味」「頭が悪くなる」など、2021年を迎えた今でもマイナスイメージが払拭しきれていないのではないかな、という所感があります。

現在はコロナ禍ということもあり、不要不急の外出を控えるために実際にプレイされている方も増えてきているかと思いますが、子供の頃から将棋やチェスなどのボードゲームやカードゲーム、ゲーム業界の地位を確固たるものとしたファミコンからPS4、switch、果てやベトナムでも人気を誇る「league of legend」、steamやoriginなどのストアから販売されるPC専用の多種多様色とりどりのビデオゲームを遊んでいて、これを恥ずかしがらずに公言してでも確信を持って自分の大きな強みになったと言えることが一つだけあります。

それは、各ソフトウェアの仕様がすぐに把握できることです。

一見通常の企業であればマイナスイメージにすらなりうるこの経験は大手ゲームデバッグ企業の採用にも一役買い、初めて触るゲームやソフトウェアでも誰よりもいち早く仕様を理解してデバッグできること、またはその速度も同僚より大幅に優れていた点が評価され、一年ほどでデバッグリーダーになりその一年と半年後には更に3~5案件程度をまとめるリーダーへの昇格を持ちかけられるほどに成長することができました。

そこで培ったテストケースの作成経験、各種ソフトウェアの抑えるべき観点出し、類似ソフトウェアの不具合傾向などは大きな経験となり、いま現在もHinodeLaboにて活用することができています。

HinodeLabo社でのプロジェクトの進め方

HinodeLaboでは、社長でもあり今まさに本インタビューをいただいている水野さんからの正確かつ詳細なご教示、またご指示のもとベトナムチームより実装いただいた要件を把握し、作成いただいたテスト環境における実動作にて期待値が満たされているかを確認の上、ベトナムチームに結果を報告するようなフローにて実施しております。

ベトナムチームに修正指示などを出す上で注意している点としては、
「仕様、期待される結果を正確かつ詳細にどれだけわかりやすく伝えられるか」という点に尽きると考えています。
これはオフショアではなくとも起こりうる問題だとは思いますが、自社開発、自社デバッグではない場合、すべての仕様を正確に理解することは必須でありつつも現実問題として難しいのではないかとも思っています。

特に、オフショア開発では日本語の仕様書をベトナムのコミュニケーターが読み込むため、仕様の認識齟齬といったリスクは国内請負より発生しやすいと思っており、そういった場合に、どういった日本語で「企画意図はなにか」「どうなればよいか」を伝えることはオフショア開発ならではの課題でもあり、最も注意している点でもあります。

チケット管理ツールやSlackなどのチャットツール、第一線を走り続けるデバッグ企業含む各種IT企業でよく使われるようなツールがしっかりと導入されており、不具合があってもすばやく修正、また日本語で起票した不具合を正確に伝えて下さるベトナムの優秀なコミュニケーター、開発チームの影響も大きく、プロジェクトにおける各プロセスが非常に円滑に進んでいる印象です。

もちろん自身も含めヒューマンエラーが発生することもありますが、そういったイレギュラーに対しても優秀なエンジニア陣やマネジメントによって迅速な解決へと運ばれており、プロジェクトへの携わり方を学びながら着手させていただいています。

初めてオフショア開発チームでテストをしてみて、注意している点

先述の通り、やはり最も難しいと感じるのは言語面の課題でしょうか。
ベトナムチームのコミュニケーターは非常に優れていますが、翻訳元の日本語がわかりづらい、間違っているなどの場合翻訳がうまくいくはずもありません。

となると、どこまで伝わりやすく綺麗で砕けていない日本語を伝えられるかという面が重要になりますが、テスターと開発とのコミュニケーションは切っても切れないほど必要な部分となりますので、そういった面は強く意識しています。

実際のテストとしては、大まかにはデバッグ企業のように「テストケース」を作成するパターンと作成せずに自身の観点でテストを行う2つのパターンがあるかと考えていますが、どちらにしても「素人であること」を理念として第一に考えています。

テスターとしての必須技術として例えば「全ての観点を出してからテストを開始する」「要件を逆から（期待値から）順に考える」などがありますが、そういった部分ではなく何よりもまず素人として触ってみることで、実際に仕様のみで観点を出してからテストするより漏れが少なかったりします。

これはオフショア開発で、というよりかは以前の企業から留意している点にはなりますが、デバッグだけでも「最低でも実際の使用時間より10倍以上はデバッグが必要」とよく言われる状態でどこまで工数を削減するか、というのはデバッグ業界全体の課題であり、「どこまで工数を削減して正確かつ可能な限り最大の範囲でのテスト」を実行するかは上記の通り、実際にソフトウェアを触りたい人の目線に立つことが重要だと考えています。

また、これは初めてオフショア開発に携わってわかったことですが、日本人エンジニアと比較してオフショアではコストが低いことが大きなメリットと言われている昨今で、一般的なエンジニアとしての技術はもう既に十分以上にコストを超えた水準になっているのではないかと強く感じました。

そうなると、デバッガーとしてもいずれ自身の立場がオフショアのメンバーに奪われてしまう可能性も非現実的な話ではないと考え、日本人としての日本語能力や求められる技術などはより琢磨し、常々自身をご採用いただいている意味があるようにしたいと思っています。