伊藤由貴 / Yoshiki Ito

QAエンジニアとしてQA組織の立ち上げやテストの技術移転、システムテスト自動化など色々…

伊藤由貴 / Yoshiki Ito

QAエンジニアとしてQA組織の立ち上げやテストの技術移転、システムテスト自動化など色々行っています。 noteではエンジニア関連のことを書きつつ、 読むのはゲームや写真、知的生産など趣味関連のことも読んで「いいね」してます。

メンバーシップに加入する

■メンバーシップの概要 QAエンジニアとして働いている、もしくはこれから働こうという方に向けて、 より楽しくキャリアを歩んだりスキルアップしたりできるような情報を提供します。 ■記事について QAエンジニアとして働くなかで ・キャリアどう考えてるの/考えてたの ・転職活動ってどうだったの ・QA採用ってどんな判断基準で何を見てるの ・副業ってどうなの などなど、知っている・経験したことだけれどもSNSやブログなどでおおっぴらに書くのはちょっとアレかなぁということを書いていきます。 更新は月に2記事以上が目安です。 客観的事実やエビデンスに基づく正解というよりは、 経験に基づく生の声・感想などをお伝えします。 ■登録してくださった方とのやりとり noteのメンバーシップには掲示板機能があるらしいので、 そちらを使って ・こんなテーマで書いてほしい ・こんなことで困ってるからなにか情報ほしい などリクエスト受け付けたいと思います。

  • スタンダードプラン

    ¥200 / 月
    初月無料

マガジン

  • 技術推進の心がけ

    ITエンジニアが組織内になんらかの技術や考え方を広めていく際の心がけについて、 自分が出来ているかどうかは棚に上げつつ「こういうことが大事では?」と思う内容をしたためていきます。 エヴァンジェリスト経験をもとにしています。

最近の記事

  • 固定された記事

QAの仕事やキャリアに関して相談を受けるありがたみ

ちょっと思い立って、個人のブログやWeb連載のほかにnoteも書いてみることにしました。 仕事やキャリアの相談をうけることありがたいことに、他社のQAの方から仕事やキャリアについて相談いただくことがあります。 たとえばエンジニアイベント後の懇親会だったり、あとは個別にカジュアル面談(採用に関係ないつ)で相談してもらったりします。 興味あればこちらから。 正直、別に「すべての悩みに答えられます」とか「自分はすばらしい答えを提供できます」というつもりはありません。どちらかと

    • QAは誰でもできるのか?自身のスキルをどう可視化すれば良いのか?

      たまに、QAエンジニアとはテストエンジニアは誰でもできる的な発言やコメントを見かけます。(ほんとうにたまに、です) 肌感覚として、こういった誤解は昔と比べると減ってきているようにも思うのですが、なぜ「だれでもできる」と思われてしまうのか、について少し考えてみたいと思います。 またそこから派生して・・・ もし「誰でもできる」と思われる可能性があるのであれば、QAエンジニア自身が「これはスキルであって、誰でも学習・訓練なしにできるものではない」と示していくこともまた必要です。

      • テスト自動化は3回や4回やれば元が取れるの?

        テスト自動化でたまに言われる「自動化してから3回もしくは4回実行すれば元が取れる=コストに対してメリットが上回る」という説について考えてみましょう。 その前に・・・この記事と同じような内容を、別のWebメディアでも別途掲載する予定です。かつ、そちらは無料で全文読めます。 Webメディアのほうは開発者やPMなどより広い範囲向けに書き、こちらは主にQAエンジニア向けとして書きます。 そのため、こちらの記事内容が全て別記事に載るわけではありません。 背景テスト自動化にはコスト

        • NotebookLMで英語論文の概要を把握してから読むと捗る

          タイトルで言いたいことを言い切ってしまったのであとはメモとして雰囲気が伝わればオッケーです。 カッコつけてACM Digital Libraryで論文をペラペラ読んでいます。(年間数万払っているので元はとりたい) ただ、論文は基本英語なので、読めなくはないけれどもたいへん時間がかかります。流し読みでも時間がかかります。 これまではReadableを使っていたReadable|見た目そのまま、PDF翻訳の新基準 こちらのサービスに有料契約をして、日本語に機械翻訳されたも

        • 固定された記事

        QAの仕事やキャリアに関して相談を受けるありがたみ

        マガジン

        • 技術推進の心がけ
          1本

        メンバーシップ

        • メンバーシップの終了について

          この投稿を見るには メンバーになる必要があります
        • 今後の記事予定

          この投稿を見るには メンバーになる必要があります
        • メンバーシップの終了について

          この投稿を見るには メンバーになる必要があります
        • 今後の記事予定

          この投稿を見るには メンバーになる必要があります

        メンバー特典記事

          QAは誰でもできるのか?自身のスキルをどう可視化すれば良いのか?

          たまに、QAエンジニアとはテストエンジニアは誰でもできる的な発言やコメントを見かけます。(ほんとうにたまに、です) 肌感覚として、こういった誤解は昔と比べると減ってきているようにも思うのですが、なぜ「だれでもできる」と思われてしまうのか、について少し考えてみたいと思います。 またそこから派生して・・・ もし「誰でもできる」と思われる可能性があるのであれば、QAエンジニア自身が「これはスキルであって、誰でも学習・訓練なしにできるものではない」と示していくこともまた必要です。

          QAは誰でもできるのか?自身のスキルをどう可視化すれば良いのか?

          テスト自動化は3回や4回やれば元が取れるの?

          テスト自動化でたまに言われる「自動化してから3回もしくは4回実行すれば元が取れる=コストに対してメリットが上回る」という説について考えてみましょう。 その前に・・・この記事と同じような内容を、別のWebメディアでも別途掲載する予定です。かつ、そちらは無料で全文読めます。 Webメディアのほうは開発者やPMなどより広い範囲向けに書き、こちらは主にQAエンジニア向けとして書きます。 そのため、こちらの記事内容が全て別記事に載るわけではありません。 背景テスト自動化にはコスト

          テスト自動化は3回や4回やれば元が取れるの?

          開発→QAはいけるけどQA→開発は難しいのか

          X(Twitter)を見ていると、たまにこのような話題が出てきます。 し、実際テスト会社に居たころは「開発やりたい」といって転職していく人もいました。若いころの自分も「Web開発者になりたいなぁ」と思っていた時期もありましたし、気持ちとしてはとてもわかります。 実際、開発者からQAになるパターンと比べて、QAから開発者になるパターンは難しいのでしょうか。

          開発→QAはいけるけどQA→開発は難しいのか

          テスト設計を学ぶときにハマりがちなことと自分なりの回避策

          テストエンジニア歴浅めの方と話をする機会がありまして。その中で「テスト設計がよくわからない」的な話になったんですね。 同値分割・境界値分析や状態遷移、組み合わせなど、各種テスト設計技法については本なども揃っているのである程度はわかったつもりになれると思います。 ただ、よく聞くのはその先、「テスト技法がわかったつもりになったけど、実務でなかなか使えない」です。そこから派生して、技法を学んだけどテスト設計はできない・わからない、などもありがちなパターンです。 テスト設計技法

          テスト設計を学ぶときにハマりがちなことと自分なりの回避策

          他社のQAエンジニアと交流するには

          先日とあるQAの方と雑談している際に話題になったのが、他社QAの方との交流についてです。 人によってグイグイ交流している方もいれば、「本当はそうしたいけどなかなか」という方もいらっしゃるように思います。 マインドセット的なところはいろんな場面で語られていそうなので、本記事ではどこでどう交流のきっかけを持てばいいのか、について書いていきます。 その前に1つだけマインドセットの話を・・・しないと言って数行後にマインドセット的なところを書いてしまうのですが、ものすごく大事なの

          他社のQAエンジニアと交流するには

          エンジニアが社内の取り組みを外部に向けて発信する隠れたメリット

          社名と自分の名前(もしくはSNS等のアカウント名)を出してアウトプットすること、例えば社内での取り組みなどについて登壇したりブログを書いたりすることには、さまざまなメリットがあります。 たとえば、会社にとっては社内の様子や実態を発信することで採用につなげる可能性が増えたり、社外発表することが逆に社内への情報共有につながったり、といった効果も期待できます。 個人レベルでは、自分の取り組みを社外発表することで、言語化や思考の深堀りをする良い機会になる、というメリットもあります

          エンジニアが社内の取り組みを外部に向けて発信する隠れたメリット

        記事

          開発→QAはいけるけどQA→開発は難しいのか

          X(Twitter)を見ていると、たまにこのような話題が出てきます。 し、実際テスト会社に居たころは「開発やりたい」といって転職していく人もいました。若いころの自分も「Web開発者になりたいなぁ」と思っていた時期もありましたし、気持ちとしてはとてもわかります。 実際、開発者からQAになるパターンと比べて、QAから開発者になるパターンは難しいのでしょうか。

          開発→QAはいけるけどQA→開発は難しいのか

          テスト設計を学ぶときにハマりがちなことと自分なりの回避策

          テストエンジニア歴浅めの方と話をする機会がありまして。その中で「テスト設計がよくわからない」的な話になったんですね。 同値分割・境界値分析や状態遷移、組み合わせなど、各種テスト設計技法については本なども揃っているのである程度はわかったつもりになれると思います。 ただ、よく聞くのはその先、「テスト技法がわかったつもりになったけど、実務でなかなか使えない」です。そこから派生して、技法を学んだけどテスト設計はできない・わからない、などもありがちなパターンです。 テスト設計技法

          テスト設計を学ぶときにハマりがちなことと自分なりの回避策

          他社のQAエンジニアと交流するには

          先日とあるQAの方と雑談している際に話題になったのが、他社QAの方との交流についてです。 人によってグイグイ交流している方もいれば、「本当はそうしたいけどなかなか」という方もいらっしゃるように思います。 マインドセット的なところはいろんな場面で語られていそうなので、本記事ではどこでどう交流のきっかけを持てばいいのか、について書いていきます。 その前に1つだけマインドセットの話を・・・しないと言って数行後にマインドセット的なところを書いてしまうのですが、ものすごく大事なの

          他社のQAエンジニアと交流するには

          エンジニアが社内の取り組みを外部に向けて発信する隠れたメリット

          社名と自分の名前(もしくはSNS等のアカウント名)を出してアウトプットすること、例えば社内での取り組みなどについて登壇したりブログを書いたりすることには、さまざまなメリットがあります。 たとえば、会社にとっては社内の様子や実態を発信することで採用につなげる可能性が増えたり、社外発表することが逆に社内への情報共有につながったり、といった効果も期待できます。 個人レベルでは、自分の取り組みを社外発表することで、言語化や思考の深堀りをする良い機会になる、というメリットもあります

          エンジニアが社内の取り組みを外部に向けて発信する隠れたメリット

          仕事で暴れるって何なの〜QAの仕事をつくるのも茨の道でありまして

          先日JaSST'24Kansaiで登壇してきました。 ここで「QAエンジニアの仕事をつくる」というタイトルで発表しまして、内容的には 的なメッセージをお伝えしました。 で、これについて補足というか別側面もあると思うのでnoteメンバーシップ向けにつらつら書いてみることにします。

          仕事で暴れるって何なの〜QAの仕事をつくるのも茨の道でありまして

          テスト会社で働くメリット

          先日JaSST'24Kansaiにて、「QAエンジニアの仕事をつくる」というタイトルで講演させていただきました。 JaSSTソフトウェアテストシンポジウム-JaSST'24 Kansai-セッション概要 テスト会社で働くことで身につく能力や得られる機会があるよね、と思っています。 講演の中で少しだけ触れたのは、テスト会社で学んだのは「理想と現実を把握して、そこから課題設定をして解決をする」ということです。講演のタイトルにも設定した「仕事をつくる」(そしてその仕事を進める)

          テスト会社で働くメリット

          QAエンジニアと競争優位性、これからなることの大変さについての色々

          「QAエンジニアを楽しみたい」というメンバーシップを運営しておきながら、そうはいっても楽しむためには色々な現実が立ちはだかるよな・・・と思う日々です。 今回はそのうちのひとつ、QAエンジニアの競争優位性や、いま有利な人不利な人の差が生じている話について思うところを書いてみます。 「皆さんに正解を伝えます」的なものではなく「こう思ってるんですけど、みなさんどう思われます?」というほうの記事です。

          QAエンジニアと競争優位性、これからなることの大変さについての色々

          QAエンジニアを入れると儲かるんですよ、という理屈を考えている

          はい、考えてるんですけど、なかなかコレだ!という理屈が浮かんでこないので、とりあえずnoteにでも書いてみようかな、という次第です。 なおここでの儲かるというのは、QAエンジニア本人がではなく、QAエンジニアがJoinした組織が儲かる、という意味です。 おそらく多くの方がそうだと思うのですが、高い給料って欲しいですよね。 ただ、たとえば「QAエンジニアで年収1000万になりたい」と考えたとします。 このとき、QAエンジニアである自分が居ることで組織に1500万とか200

          QAエンジニアを入れると儲かるんですよ、という理屈を考えている

          QAエンジニアは開発者の反発ではなく開発者の遠慮を取り除くのに腐心しているかもしれない

          この記事はなんらかのメッセージや主張というわけではなく、雑記です。 ちょっとわけあっていろいろ調べ物をしているなかで、以下のスライドが目に止まりました。 これ、自分も一人目QAやっててすごく「うわー、あるあるー」と思う場面です。 開発者から「品質について相談のって」と言われるのは、QAエンジニアとして基本的にはありがたい限りです。 ところが、なんでかこの「工数取らせちゃうと悪いので」というふうに言われるんですよねー。 いつも「忙しかったり無理だったらちゃんと言うので、

          QAエンジニアは開発者の反発ではなく開発者の遠慮を取り除くのに腐心しているかもしれない

          第三者検証会社のジュニアエンジニアの目標設定の考え方

          今回の記事も、メンバーシップで質問いただいた内容に対する私なりの考えになります。質問投げてくださってありがとうございます。(考えて言語化するきっかけになるので大感謝) 質問のおおまかな内容・経緯としてはこうです。

          第三者検証会社のジュニアエンジニアの目標設定の考え方

          初心者とかよわよわとか駆け出しとか言うな

          これは過去自分も言っちゃってたんですが・・・ 初心者 よわよわ 駆け出し とか言うなー プロとしてー というような趣旨の話が、最近見ている写真の上達法の動画の中で出てきて、ハッとしたわけです。 プロのエンジニアなら言うなーということですね。 写真に関しては、明確に「趣味として楽しみたいんです」という人と「プロです」という人が分かれないというか、両方居ますよね。 ただ、エンジニアとしてはほぼほぼプロしかいないはずなので、 プロがSNSで「まだ駆け出しなんで」とか「初

          初心者とかよわよわとか駆け出しとか言うな

          組織で評価される人の特徴~その2

          前回の記事 組織で評価される人の特徴~その1|伊藤由貴 / Yoshiki Ito に引き続き、評価される人の特徴について考えていきます。 一応この記事は「QAエンジニアを楽しみたい」というメンバーシップ向けのため、QAエンジニアの方を想定して書いています。が、他のロールの方にも共通する部分はあると思います。

          組織で評価される人の特徴~その2