伊藤由貴 / Yoshiki Ito
ITエンジニアが組織内になんらかの技術や考え方を広めていく際の心がけについて、 自分が出来ているかどうかは棚に上げつつ「こういうことが大事では？」と思う内容をしたためていきます。 エヴァンジェリスト経験をもとにしています。
ちょっと思い立って、個人のブログやWeb連載のほかにnoteも書いてみることにしました。 仕事やキャリアの相談をうけることありがたいことに、他社のQAの方から仕事やキャリアについて相談いただくことがあります。 たとえばエンジニアイベント後の懇親会だったり、あとは個別にカジュアル面談（採用に関係ないつ）で相談してもらったりします。 興味あればこちらから。 正直、別に「すべての悩みに答えられます」とか「自分はすばらしい答えを提供できます」というつもりはありません。どちらかと
だと思っています。 特に、テスト会社での仕事経験がある方は、複数の現場で働いたことがあることも多いのではないでしょうか。 その場合、会社ごとのカルチャーの違いをなんとなく感じているのでは、と思います。
たまに、QAエンジニアとはテストエンジニアは誰でもできる的な発言やコメントを見かけます。（ほんとうにたまに、です） 肌感覚として、こういった誤解は昔と比べると減ってきているようにも思うのですが、なぜ「だれでもできる」と思われてしまうのか、について少し考えてみたいと思います。 またそこから派生して・・・ もし「誰でもできる」と思われる可能性があるのであれば、QAエンジニア自身が「これはスキルであって、誰でも学習・訓練なしにできるものではない」と示していくこともまた必要です。
テスト自動化でたまに言われる「自動化してから3回もしくは4回実行すれば元が取れる＝コストに対してメリットが上回る」という説について考えてみましょう。 その前に・・・この記事と同じような内容を、別のWebメディアでも別途掲載する予定です。かつ、そちらは無料で全文読めます。 Webメディアのほうは開発者やPMなどより広い範囲向けに書き、こちらは主にQAエンジニア向けとして書きます。 そのため、こちらの記事内容が全て別記事に載るわけではありません。 背景テスト自動化にはコスト
タイトルで言いたいことを言い切ってしまったのであとはメモとして雰囲気が伝わればオッケーです。 カッコつけてACM Digital Libraryで論文をペラペラ読んでいます。（年間数万払っているので元はとりたい） ただ、論文は基本英語なので、読めなくはないけれどもたいへん時間がかかります。流し読みでも時間がかかります。 これまではReadableを使っていたReadable｜見た目そのまま、PDF翻訳の新基準 こちらのサービスに有料契約をして、日本語に機械翻訳されたも
X（Twitter）を見ていると、たまにこのような話題が出てきます。 し、実際テスト会社に居たころは「開発やりたい」といって転職していく人もいました。若いころの自分も「Web開発者になりたいなぁ」と思っていた時期もありましたし、気持ちとしてはとてもわかります。 実際、開発者からQAになるパターンと比べて、QAから開発者になるパターンは難しいのでしょうか。
テストエンジニア歴浅めの方と話をする機会がありまして。その中で「テスト設計がよくわからない」的な話になったんですね。 同値分割・境界値分析や状態遷移、組み合わせなど、各種テスト設計技法については本なども揃っているのである程度はわかったつもりになれると思います。 ただ、よく聞くのはその先、「テスト技法がわかったつもりになったけど、実務でなかなか使えない」です。そこから派生して、技法を学んだけどテスト設計はできない・わからない、などもありがちなパターンです。 テスト設計技法
先日とあるQAの方と雑談している際に話題になったのが、他社QAの方との交流についてです。 人によってグイグイ交流している方もいれば、「本当はそうしたいけどなかなか」という方もいらっしゃるように思います。 マインドセット的なところはいろんな場面で語られていそうなので、本記事ではどこでどう交流のきっかけを持てばいいのか、について書いていきます。 その前に１つだけマインドセットの話を・・・しないと言って数行後にマインドセット的なところを書いてしまうのですが、ものすごく大事なの
社名と自分の名前（もしくはSNS等のアカウント名）を出してアウトプットすること、例えば社内での取り組みなどについて登壇したりブログを書いたりすることには、さまざまなメリットがあります。 たとえば、会社にとっては社内の様子や実態を発信することで採用につなげる可能性が増えたり、社外発表することが逆に社内への情報共有につながったり、といった効果も期待できます。 個人レベルでは、自分の取り組みを社外発表することで、言語化や思考の深堀りをする良い機会になる、というメリットもあります
先日JaSST'24Kansaiで登壇してきました。 ここで「QAエンジニアの仕事をつくる」というタイトルで発表しまして、内容的には 的なメッセージをお伝えしました。 で、これについて補足というか別側面もあると思うのでnoteメンバーシップ向けにつらつら書いてみることにします。
先日JaSST'24Kansaiにて、「QAエンジニアの仕事をつくる」というタイトルで講演させていただきました。 JaSSTソフトウェアテストシンポジウム-JaSST'24 Kansai-セッション概要 テスト会社で働くことで身につく能力や得られる機会があるよね、と思っています。 講演の中で少しだけ触れたのは、テスト会社で学んだのは「理想と現実を把握して、そこから課題設定をして解決をする」ということです。講演のタイトルにも設定した「仕事をつくる」（そしてその仕事を進める）
「QAエンジニアを楽しみたい」というメンバーシップを運営しておきながら、そうはいっても楽しむためには色々な現実が立ちはだかるよな・・・と思う日々です。 今回はそのうちのひとつ、QAエンジニアの競争優位性や、いま有利な人不利な人の差が生じている話について思うところを書いてみます。 「皆さんに正解を伝えます」的なものではなく「こう思ってるんですけど、みなさんどう思われます？」というほうの記事です。
はい、考えてるんですけど、なかなかコレだ！という理屈が浮かんでこないので、とりあえずnoteにでも書いてみようかな、という次第です。 なおここでの儲かるというのは、QAエンジニア本人がではなく、QAエンジニアがJoinした組織が儲かる、という意味です。 おそらく多くの方がそうだと思うのですが、高い給料って欲しいですよね。 ただ、たとえば「QAエンジニアで年収1000万になりたい」と考えたとします。 このとき、QAエンジニアである自分が居ることで組織に1500万とか200
この記事はなんらかのメッセージや主張というわけではなく、雑記です。 ちょっとわけあっていろいろ調べ物をしているなかで、以下のスライドが目に止まりました。 これ、自分も一人目QAやっててすごく「うわー、あるあるー」と思う場面です。 開発者から「品質について相談のって」と言われるのは、QAエンジニアとして基本的にはありがたい限りです。 ところが、なんでかこの「工数取らせちゃうと悪いので」というふうに言われるんですよねー。 いつも「忙しかったり無理だったらちゃんと言うので、
今回の記事も、メンバーシップで質問いただいた内容に対する私なりの考えになります。質問投げてくださってありがとうございます。（考えて言語化するきっかけになるので大感謝） 質問のおおまかな内容・経緯としてはこうです。
これは過去自分も言っちゃってたんですが・・・ 初心者 よわよわ 駆け出し とか言うなー プロとしてー というような趣旨の話が、最近見ている写真の上達法の動画の中で出てきて、ハッとしたわけです。 プロのエンジニアなら言うなーということですね。 写真に関しては、明確に「趣味として楽しみたいんです」という人と「プロです」という人が分かれないというか、両方居ますよね。 ただ、エンジニアとしてはほぼほぼプロしかいないはずなので、 プロがSNSで「まだ駆け出しなんで」とか「初
