IT業界で未経験から始められる業務

専門的なスキルが求められるイメージが強いIT業界。実際にその通りであることも確かなんですが、誰でも初めから高いスキルを持っている訳ではありません。

今回は、そんな「IT業界に興味があるけどスキルには自信がない」という未経験者でも始められる業務についてお話しします。

テスター = 学びながら役立てる、そして非常に重要な業務

テスターという仕事について、皆さん一度くらいは聞いたことがあると思います。想像しやすいのはゲームのテスターでしょうか。

例えば、延々と壁や岩などにぶつかりながらキャラクターを動かして、すり抜けてしまうオブジェクトがないか確かめたり、細かなサブイベントまで網羅して全てのイベントが仕様通りに行われるか確かめたり……、簡単に言うと「バグを見つける人」がテスターです。

もちろんゲームに限らずWebサービスの開発現場においても、「バグを見つける」テスターは重要な業務です。具体的な業務内容は、

  • 開発中のWebサービスの設計書・仕様書を読み込み、全体像を理解すること
  • 仕様書に沿って作られた機能(プログラム)が期待した通りに動作するかを確認すること
  • 予期せぬ動作(バグ)を見つけた時に、どのような操作で発生したのか(再現手順)を報告すること

このような大きく3つの要素で構成されます。そしてこの3つこそが、未経験者がテスターに携わる最大のメリットでもあります。

開発中のWebサービスについて理解しよう

いきなりテストを始める前に、まずは資料に目を通してみましょう。設計書・仕様書・定義書など、開発には様々な資料が必ず存在します。最初に資料に目を通してこれからテストを行うWebサービスについて、ざっくりでいいので考えてみましょう。

利用するユーザーは誰なのか?そのWebサービスを通してどんなメリットが得られるのか?

詳細な動作の仕組みよりも先に、これから検証を始めるWebサービスに託された大きな目的を想像してみてください。

仕様書には細かく「こうしたらこうなる」といった点の要素が網羅されていますが、Webサービス全体を通しての目的を掴んでいると、そうした点と点が繋がって、全体の一部であるそれぞれの仕様の意図を理解する助けとなります。

次に、どのような画面があるのか?各要素のつながりはどうなっているのか?など、完璧でなくていいので大まかな全体像を見てみましょう。

開発の規模にもよりますが、開発の現場はチームでの仕事であることが多いです。当然、開発者も一人で全てを担当している訳ではなく、またテスターも一人で全てをテストする訳ではありません。

Webサービスを人体で例えると、開発チームはAさんが頭を担当して、Bさんは身体、Cさんが心臓を担当といったようにパーツごとの担当が決まっています。テスターも同様に、Aチームが頭を、Bチームは身体、Cチームで心臓をテストするという風に担当が分かれて各要素を検証していきます。

しかし実際には、頭の命令で手足が動いたり、心臓の状態が頭や手足に影響を及ぼしたり、と各部位は密接に関連しています。自分の直接の担当箇所以外も理解しておくことが、円滑なテストを進める秘訣になってくるのです。

仕様書に沿って操作してみよう

今から扱うWebサービスはこういうものなんだな〜とイメージが掴めたところで、実際に手を動かしていきます。
テスターはコードを書く訳ではありませんので、仕様書の指示に従って簡単なPC操作さえできれば誰でも可能な作業です。

例えば、「テキストボックスに全角文字を入力→全角文字が入力できる」と指示があれば、実際に指定されたテキストボックスに全角の文字が入力可能なのか検証する、といった具合です。

ここで素直に入力ができればOKなのですが、試してみると全角文字が入力できないかもしれません。あるいは、テキストボックス自体が表示されなかったり、入力はできるけど半角英数文字しか入力できなかったということもあるかもしれません。

そのようなバグを見つけたら、そうなった「手順」をしっかりと記録しましょう。その「手順」を辿れば何度やっても、誰がやっても同じ事象が発生するという確証が得られればベストです。

このとき重要なのが、バグが発生する「原因」まで突き止める必要はないということです。テスターはバグを「見つける」ことが役目であって、原因を探りそれを取り除く改修を行うのは開発者の役目です。ですから未経験者で専門知識がなくとも、安心して取り組める業務なのです。

とはいえ、テキストボックスの例とは違って項目によっていくつかの前提条件を満たした検証を求められることもありますし、専門知識は必要ありませんが仕様について理解する努力は必要です。分からない時には相談するなど、一定のコミュニケーション能力も必要となってくるでしょう。

テスターに取って大切なのは、バグを「見つける」ことと、それがバグであると認識できる正しい「仕様理解」なのです。

バグを見つけたら報告しよう

さて、バグを見つけて再現性も確認できたら、該当箇所を担当する開発者へ報告をして一連の流れが終わります。報告の際に意識したいことは、

  • 客観的な事実のみを書く
  • 正確な再現手順を書く

上記の2点です。誰が読んでも等しく共通の理解ができるように、なるべく主観的な要素を排除して客観的な事実のみを記述するには慣れが必要ですが、IT業界に関わらず活かせるスキルです。

「テキストボックスに全角文字が入力できない」「テキストボックスに仕様書の指示通りに入力してみたが文字が打てなかった」

極端な例ですが、前者を読んでの解釈は一通りしかなく、後者の場合だと読み手によっては解釈のブレが起こり得ることは伝わるでしょうか?

もう少し掘り下げると、後者だと仕様書の指示通りにとありますが、読み手には仕様書のどこの指示でどんな内容なのか分かりません。より細かく見ると、文字という表現も全角半角英数記号など何の文字種を指すのかなど、汲み取ることもできますが正確性に不安が残ってしまいます。

簡潔に事実のみを伝えることを意識していきましょう。

網羅するまで繰り返す

バグの報告を終えたら次の箇所をテストして、バグが見つかれば手順を記録し、担当の開発者へ報告を行う……という作業を全ての項目を網羅するまで繰り返していきます。

当然、報告したバグは担当開発者より改修が行われますので、改修の結果が期待値通りの動作になったかの再テストをすることも必要です。多くの場合、改修の際には開発者が原因と実施した対策をコメントとして残しますので、ここでもテスターは経験値を積むことができます。

具体的にどんなコードが書かれているかまで理解する必要はありませんが、仕組みとして様々なバグの原因と対策を知っておくと、プログラミングの学習を始めるタイミングでも大きなアドバンテージになるでしょう。

また、テストを続けるうちに複数の箇所で同じようなバグに出会うこともあります。初めはただ「上手くいかないからバグだな」としか思えなかった事象にも、「きっとこういう仕組みになっていて期待通りに動かないんだな」と一段階上の認識を持ち、業務の最中にも成長を実感できる機会があります。

少しでも興味を持った方はハコブネへ

いかがでしたでしょうか?未経験者のハードルが高いと思われがちなIT業界ですが、テスターのように未経験から学びつつ役立てる業務も存在します。弊社ではSESも行っており、テスター業務に携わるチャンスも多くあります。もし、少しでも興味を持ってくださったら「採用情報」のページをぜひご覧ください。私たちはあなたが仲間に加わってくれる日を、楽しみにお待ちしています。