見出し画像

新卒・第二新卒必読!IT業界未経験者がプロジェクトで成果を生み出すためのインプットと3つの戦術


はじめに


皆さん、はじめまして。
2024年1月に株式会社SHIFTに入社したQAエンジニアの野田と申します。
私は文系大学卒で非IT企業に新卒入社後、やる気だけを引っ提げて、知識ゼロ・技術ゼロの状態でこの業界に未経験転職しました。
転職当初は苦悩を感じながらも、現在はSHIFTアジャイルサービス部にて、日々試行錯誤しながら楽しく仕事をしています!

本記事は、"業界未経験者がプロジェクトで成果を生み出すためのインプットと3つの戦術"と銘打たせていただきました。
読者としては、前述の私のように第二新卒でIT業界に飛び込んできたSHIFT社員・SHIFTに就職志望の学生を想定していますが、弊社に興味を持っていただいている方にも是非読んでいただいきたい内容となっています!

社内資格のトップガンについても、私なりに嚙み砕いてまとめましたので、この記事を参考にスタートダッシュを決めていただき、その勢いで"スキ"を押していただけると幸いです!!

本記事構成の概略としては、以下になります。

  • 転機となった絶望のミーティング

  • たどり着いたインプットと3つの戦術

  • その結果どのようになったか

失われゆく自信、未知への抵抗感


未経験からのIT転職後、1か月が過ぎた頃です。
慣れない中でも、それを受け入れつつ漂うように仕事をしていた矢先、ある出来事が起こりました。
それが契機となり、自分のやるべきことについて本気で考えるようになったのです。

絶望のミーティング ~危機感を持つべき瞬間~

とあるミーティングに参加した時、大変なことが起きました。

  • 言葉の意味が分からない

  • 最終的にどこに向かっているのかが分からない

  • やるべきことは理解したが、やり方が分からない

「...?」

「??????」

とにかく、分からないことが多すぎたのです。

とりあえず、多すぎる不明点の中から重要そうな事柄に絞って質問してみましたが、いただいた回答についても理解をすることができませんでした。詰みました。
しかもこの時、私以外の新規参画メンバーは、皆晴れやかな表情で自分のすべきことを理解しているようでした(私の目にはそのように映りました)。

・・・

厳しいって。

まさに緊急事態です。
正直、かなりの危機感・焦りを感じていたことを覚えています。
このミーティングの内容を理解できていないのは自分だけではないか、という焦りから完全に自信を失くしてしまいました。
"分からないことは恥ずかしいことではない"という認識はあったため、質問することで挽回しようとしましたが、「回答内容すら理解ができなかった="分からない状態"からの挽回方法が分からなかった」ため、未知に対する抵抗感が芽生え始めてしまいました。

"分からない"ということが分かった

いきなり古代ギリシアの哲学者みたいなことを言って恐縮ですが、上記のミーティングで、まさに自分の無知を改めて認識しました。そもそも土台になる基礎部分についての知識や思考が全く足りていなかったのです。
繰り返しますが、私個人的には"分からないことは恥ずかしいことではない"と思っていますし、それを恐れていては成長はできないと考えています。
しかし、前述の通り基礎部分のリテラシーが低すぎると、分からないことが多すぎて、分からないことに対する抵抗感が生まれてしまいます。 この状態から脱却するために以下の3軸を目標に置き、取り急ぎ勉強を始めました。

  • プロジェクトの進め方を理解する

  • コミュニケーション力を向上させる

  • QA業務に直接関連する基礎知識を会得する

※QAとは「Quality Assurance」の略で、品質保証のことです。
 本文でのQA業務とは、品質保証のためのテストと評価活動のことを指しています。

仕事が楽しくなるための初動のインプット


勉強の方法については、読書と資格勉強をメインに行いました。

書籍によるインプット

もともとあまり読書をしない人間だったのですが、最近は約2週間に1冊のペースで業務に役立ちそうな本を読んでいます。

私が読んだ本の中から抜粋したおすすめを2冊、本記事で紹介させていただきます。
なお、これらの本については、QAに携わる人以外にもおすすめの内容となっています。

PMBOK対応 童話でわかるプロジェクトマネジメント

「プロジェクトマネジメント?なんかかっこいいな??」の状態の初心者にとって、専門用語や複雑な手法を理解するのは難しいです(以前の私です )。
しかしこの本は童話という親しみやすい形式を用いることで、自然に学びを深めることができます。

例えば、プロジェクトの目標設定や計画立案、リスク管理、進捗管理など、プロジェクトの各フェーズを童話のキャラクターたちの冒険に例えて説明しています。これにより、抽象的な概念が具体的なイメージとして頭に入りやすくなります。

また、PMBOK(プロジェクトマネジメント知識体系ガイド)に準拠しているため、実務に直結する知識も得られます!
新卒・二卒の若手でも読みやすく、勉強になる1冊です。

頭のいい人が話す前に考えていること

この本は、コミュニケーションスキルを向上させるための実践的なアドバイスが詰まった書籍です。
話す前に何を考えるべきか、どのように考えるべきかを具体的に示しており、初学者でもすぐに実践できる内容が多く含まれています。

例えば、話の目的を明確にすること、相手の立場や感情を考慮すること、論理的な構成を意識することなど、効果的なコミュニケーションのための基本原則がわかりやすく解説されています。
また、実際のビジネスシーンや日常生活での具体例を交えながら説明しているため、理論だけでなく実践的なスキルも身につけることができます。

コミュニケーションスキルを鍛えたい人にとって、非常に有益な一冊です。


資格の取得によるインプット

併せて、土台となる基礎知識を固めようと思い立ち、資格の勉強に取り組みました。
結果的に、最初の半年で目標としていたものについて取得することができました。
私がSHIFTに入社した後の半年間で取り組み合格した資格とそれらのおすすめポイントは下記の通りです。

JSTQB Foundation Level

SHIFT入社5か月目にJSTQB Foundation Levelに合格しました。
※JSTQB(Japan Software Testing Qualifications Board)は、日本におけるソフトウェアテストの資格認定機関です。国際的なISTQB(International Software Testing Qualifications Board)の日本支部として、ソフトウェアテストの知識とスキルを評価し、認定資格を提供しています。

ブラックボックステストとホワイトボックステストの違い・V字モデル・境界値分析・レビュー手法etc...
テストに必要な基礎を幅広く学ぶことができるので、この資格を取得することで業務に対する解像度が上がります。

勉強方法としては、「テス友」というアプリを活用しました。このアプリは、JSTQBの試験対策に特化しており、模擬問題が豊富に揃っています。通勤時間やちょっとした空き時間に手軽に学習できるので、非常に効率的に勉強を進めることができました。

もちろん成果を出すためには業務についての本質を理解する=解像度を上げることの他に+αで自分自身のアウトプットの質を高めていくことが必要です。
この作業は何のために実施しているのか?というプロジェクトにおける自分自身の現在地を理解するための基礎知識として、まず第一にこちらの資格取得にチャレンジしてみることをおすすめします。

トップガン

SHIFT入社6か月目に、社内資格のトップガン10テスト設計・トップガン12アジャイルに合格しました。 ※以下、トップガン=TGと記載
両方とも、特に未経験でQAエンジニアとして現場に入る人にかなりおすすめの資格です。
おすすめする理由は、以下3点です。

①テスト設計に加えて、Excel・PowerPoint・生成AIの3種の神器の使い方を学べる

正直これはかなりありがたかったです。ちなみに3種の神器という呼称はたった今、私が命名しました。
SHIFTはソフトウェアの品質保証に強みを持つ会社なので、ソフトウェアテストについて充実した学習環境があるのは想像に難くないですが、ありがたいことに、Excel・PowerPoint・生成AIといったどこに行っても必携のスキルを身に着けるサポート環境が入社直後から整っています(トレセン・TG等)。

TG10では、表題の通り3種の神器について学習・理解度の確認ができるので、基礎力の確認や底上げといった目的ではQA以外の業務にかかわる人にもおすすめです。

②アジャイルの概念を理解して、日々の業務の進め方を身に着けることができる

異業種から転職してきた私にとって立ちはだかった壁のうちの1つが"仕事(プロジェクト)の進め方"でした。
そもそもプロジェクトってなんやねん!といった声が聞こえてきそうなので、プロジェクトについて端的に説明すると、プロジェクト=特定の目標を達成するために計画され、一定の期間内に完了する一連の活動や作業の集合体です。

入社後、多くの場合はPMではなく作業者として、プロジェクトを構成する各タスクをこなす業務に就きます。
前述の通り、プロジェクトは一定の期間内に完了することが求められ、もちろんプロジェクトに付随する各タスクにも期限が設定され、それらは厳格に管理されます(計画通りに進まないことが積み重なった状態を、所謂"炎上"といいます。ファイヤー!)。

アジャイル開発という方法論のうちの1つにスクラムというフレームワークがありますが、これは個人もしくはチームがタスクを管理する上でとても有用です。
スクラムについての詳しい内容自体は本記事では割愛しますが、プロジェクトメンバーとしてタスクを推進する上で役に立つスクラムの考え方をTG12アジャイルで学ぶことができます。

私自身、学んだこと全てを現場において実践できているわけではないですが、学ぶ前と後では仕事のやり方が変わり、出せるアウトプットも徐々に変わってきました。もちろんこのブログの執筆も自分なりにスクラムの考え方を応用しながら行っています。

③ヒトログにバッジがつく、かっこいい(ド主観)

TGに合格すると、社内検索システムのヒトログ上にバッジが表示されます。
これがかっこいいんですよね、ぜひTG取得しましょう!!

うん、イケてる。(確信)
...というのは半分本音で半分冗談ですが、真に価値があると私が考えるのは、社員が誰でも参照できる媒体上に、定量的なスキル情報を掲載できることです。

社歴の浅い新入社員にとって、自分のことをアピールすることはとても重要です。
かといって、「Excel得意です!」「テスト設計できます!」といったアピールでは"それぞれ何をどのくらいできるのか"といったことが分からないですし、上長に対して「僕のスーパーエクセレントなVBAを今からお見せします。刮目せよ。Are you ready?」と息巻き、Excelシートを領域展開したところで、残念ながら皆さん忙しいので見てもらえる可能性は低いでしょう(度胸を買われてなにかしら良い結果に転ぶ可能性はありますが)。

SHIFT社内で広く認知されているTGを取得することで、TG科目の各分野についてのある一定の知識とスキル(何をどのくらいできるのか)を示すことができ、自分の可能性を広げることができます。もちろん、資格を取得しているだけでは意味はなく、勉強の過程で得た知識・技術を使いこなすことが重要ですが、自分に自信をつけるといった意味でも小さなゴール地点としてTGの取得を目指してみることをおすすめします。

3つの戦術


インプットをひと通り終えた私は、業務に関連する知識以外にもいくつか重要な考え方を得ました。
アウトプットとして、そこで得たものをかみ砕き、自分なりに3つの戦術を立てて仕事を進めることにしました。
完全に我流ですが、フムフム・・・と思っていただけたらぜひご活用いただけると嬉しいです!

  • 其の壱 成果物の進捗は即共有(しつこいくらいに)・即作成

  • 其の弐 アクティブリスニング

  • 其の参 自分の強み・弱みを理解して、業務に取り組む

其の壱 成果物の進捗は即共有(しつこいくらいに)・即作成

これが正直一番大切だと個人的には感じてます。
この戦術は攻・守の2つの側面で効果的な戦術です。

【攻】早期にレビューをしてもらうことで、最終成果物の質を上げることができる

経験の少ないうちは特にコレあると思います。
何かを作るとき、自分ひとりでやっていると方向性がずれてきたり、作り込みの過不足が出てきたりします。
8割ほど出来上がった状態でレビューをしてもらった場合、方向性がずれていたりした場合に手戻りは大きくなります。修正するのも大変ですし、そもそも8割作る時点でかなり時間を使っているはずなので、修正にかけられる時間は少ないです。
さっさと作ってサクッと確認してもらうくらいの気持ちで臨むことが、最終的な質を上げる上で重要かなと思います。

【守】依頼者の期待と不安をコントロールできる

作業を依頼した人は、大抵は以下のような期待と不安を持っていると私は考えています。

【期待】

  • (どんな出来栄えになっているだろう。ワクワク)

【不安】

  • (ちゃんと期日通りにできるかな。。)

  • (目的はちゃんと理解できているのかな。。)

これらは、時間が経てば経つほど大きくなっていきます。

端的に言うと、「焦(じ)らすと期待が高まる」ということです。

一方、「時間をかければ、必ずしもかけた時間に比例して成果物の質が上がる訳ではない」ことも念頭に置く必要があります。
ちなみに私の実体験だと、1回もレビューをしない場合の質と期待の関係は以下のグラフのような感じだと思っています。

成果物の質と依頼者の期待の関係性(筆者作成)

肌感覚ですが、期待は経過時間に比例して大きくなっていくのに対して、成果物の質は後半に煮詰まって伸びていかないんですよね。
このグラフの場合だと、依頼を受けてから5日目までに一旦依頼者に見てもらって、アドバイス等をもらった方がよいです。
そうすることでお互いの認識が合い、

  • 作業者側は6日目以降の成果物の質が上がり

  • 依頼者側は6日目以降の期待が過度に高まることはなくなり

最終的に、成果物の質と依頼者の期待の乖離が少なくなります。
"仕事ができる"という評価はこの乖離の少なさに起因するのではないのかな、と最近感じています。

依頼者の不安に関しては、想像の通りです。進捗状況を共有することで予実について認識できるので、作業の粒度に応じて適切な頻度で自ら共有をすることが重要です。
普段からしっかりと共有ができるような関係性を作るという意味ではコミュニケーションが重要ですが、これについては戦術其の弐に関連する部分なので、後述します。

其の弐 アクティブリスニング

アクティブリスニングとは、相手の話をただ聞くだけでなく、積極的に理解しようとする姿勢を持つことを指します。聞き馴染みのある類義語として「傾聴」がありますが、アクティブリスニングはさらに一歩進んで、相手の意図や感情を深く理解し、適切なフィードバックを行うことを目指します。
要するに、「話の本質を理解して主体的に内容を把握する」ための手法ですね。

アクティブリスニングには、いくつか構成要素があリますが「これはすぐにでも使えるぞ!」ということで、私が取り入れて実践したものは以下の3つです。

  • 相手の話を遮らない

  • オープンクエスチョンを使う

  • 要約して確認する


相手の話を遮らない

相手が話している最中に口を挟まず、最後まで話を聞くことが基本です!
仕事以外でも大切な姿勢ですね。
これにより、相手は自分の意見や感情を十分に表現できると感じ、信頼関係が築かれます。例えば、ミーティング中にメンバーが意見を述べている際、途中で口を挟まずに最後まで聞くことで、相手の考えをしっかりと理解することができます。

これに関しては意識するだけでできることなので、今からでもすぐに実践することが可能です。

オープンクエスチョンを使う

「どう思いますか?」や「具体的にはどういうことですか?」といったオープンクエスチョンを使うことで、相手の考えや感情をさらに引き出すことができます。
単なるクローズドクエスチョンよりも、私はこちらを使うことを意識してコミュニケーションをとっていました。
オープンクエスチョンを意識することで、相手は自分の意見をより詳しく説明する機会を得ることができます。

例えば、テストの設計方法について議論している際に、「この方法についてどう思いますか?」と質問することで、他メンバーの意見を引き出しやすくなり、双方向のコミュニケーションを活性化させることができます。

ただし、オープンクエスチョンを使う際には注意が必要です。
あまりにもオープンすぎると逆に意見が出にくい傾向があるのです。
うまく相手の考えを引き出す工夫と組み合わせることで、真価を最大限に発揮するといえます。

後述する"要約して確認する"と併せて使うことで、相手の意図をより正確に理解し、効果的なコミュニケーションが可能になります。


要約して確認する

相手の話を要約して「つまり、こういうことですね?」と確認することで、相手の意図を正確に理解しているかどうかを確認できます。これにより、誤解を防ぎ、相手との認識のズレを減らすことができます。

私が意識して実践していたのは、「抽象⇔具体の入れ替え」です。
抽象的なものについては具体化し・具体的なものについては抽象(一般)化して確認する、ということです。

【抽象→具体の例】
抽象的な話:「ユーザーエクスペリエンスを向上させることが重要です。」

具体的な確認:「つまり、ウェブサイトの読み込み速度を改善し、ナビゲーションを直感的にするということでしょうか?」

【具体→抽象の例】
具体的な話:「ログイン機能のテストでは、正しいユーザー名とパスワードを入力した場合に正常にログインできること、間違ったユーザー名やパスワードを入力した場合にエラーメッセージが表示されることを確認します。」

抽象的な確認:「つまり、今回のテスト設計では、ログイン画面における全ての機能が正しく動作することを確認する必要があるということでしょうか?」

粒度を変えて確認をすることで、本質的な理解ができているかの確認にもなりますし、QAエンジニアであればテスト観点の抜け漏れ等にも気が付きやすくなります。


其の参 自分の強み・弱みを理解して、業務に取り組む

当たり前といえば当たり前ですが、自分の強みを活かしてその部分にフォーカスして仕事をした方が成果は出やすいです。

私の場合、0→1の発想力や傾聴力には自信を持っていたので、案出しやファシリテーションの際は積極的に前に出ていました。
一方で、論理的思考力や枝葉を広げることはあまり自信がなく、他のチームメンバーに助言をもらったり得意な方にフォローをお願いすることで、仕事を進めていました(今書いていて思ったのですが、私は恐らく右脳型ですね)。

まず、自分の強み・弱みを理解し、どの場面でどのように価値を出せるのかを明確に知っておくことが重要です。「強みを活かし、弱みは改善する」という心構えで取り組んできました。

戦術の結果


上記の戦術を実践した結果、仕事が楽しくなりました。少しずつですが、成果を出せるようになった訳です。
具体的には、以前と比べて以下のような変化がありました。

  • 期待との差異が少なくなり、成果物に対しての評価が上がった

  • チームメンバーとのコミュニケーションが良好になり、仕事が進めやすくなった

  • 自分の強みについて業務でアピールできたため、自信につながった

  • やりたい仕事を任せてもらえるようになった

本記事では"戦術"と表現しましたが、所謂"型"を持って仕事に臨むと、再現性のある結果として横展開や振り返りがしやすいです。

この記事が、皆さんの型を見つける際の参考になれば幸いです。

終わりに


ここまで記事を読んでいただき、ありがとうございました。

今回は、私の経験を基にインプット方法と3つの戦術について紹介しましたが、いかがだったでしょうか?
私自身、過去の苦い経験から多くを学びましたが、この記事を読んでいただいた皆さんには、同じような苦悩を感じる前にぜひ実践していただきたいと思っています。

これらの戦術を取り入れることで、きっと今よりも成果を出せるようになるはずです。

ぜひ、この記事を参考にして、スタートダッシュを決めてください!

<参考文献>
PMBOK対応 童話でわかるプロジェクトマネジメント
著者:飯田剛弘
初版発行日:2022月11月9日

頭のいい人が話す前に考えていること
著者:安達裕哉
初版発行日:2023月4月18日


執筆者プロフィール:野田 一希(のだ かずき)
大学卒業後、小売・流通業に就職。業務上での新規システム導入プロジェクトがきっかけとなりIT業界に転職。現在は株式会社SHIFTにて、QAエンジニアとして日々ソフトウェアと向き合っている。バイクとラーメンをこよなく愛している。

お問合せはお気軽に

SHIFTについて(コーポレートサイト)

SHIFTのサービスについて(サービスサイト)

SHIFTの導入事例

お役立ち資料はこちら

SHIFTの採用情報はこちら

PHOTO:UnsplashLuca Bravo