QAエンジニアの採用・選考　どう採るどう通る？連載の第5回、今回が最終回となります。 第2回・第3回では求職者側の視点、 前回(第4回) からは募集側の視点に切り替えて、QAについて何を理解すべきか、理解を深めるための具体的なアクションについて解説しました。 しかし、QAを理解し、良い募集文面を作ることができたとしても、その募集がQAエンジニアの目に触れなければ応募にはつながりません。連載の最終回となる今回のテーマは「認知」です。 採用における認知の重要性は、さまざまな調査データからも裏付けられています。 talentbook社が2024年に実施した調査 では、採用施策において「応募者認知」に課題を感じている企業が中堅企業で78.2%、大企業で70.3%にのぼりました。また、 markeTrans社の調査 では、企業名を事前に認知している人の9割が業務内容の理解まで進んでいるという結果が出ています。年代が上がるにつれて事前認知の比率が高くなる傾向もあり、中途採用においては事前認知がアドバンテージになり得ることが示唆されています。 本記事では、QAコミュニティの中で自社の認知を獲得するための具体的な手段についてご紹介します。前回の「理解する（インプット）」に続く、「知ってもらう（アウトプット）」のフェーズとしてお読みいただければ幸いです。 記事一覧：QAエンジニアの採用・選考［どう採る　どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える なぜ「認知」が必要なのか QAエンジニアは元々の母数が少なく、多くの企業が採用を競い合っている状況です。そうした中で、求人を出して待っているだけでは、QAエンジニアの選択肢にすら入ることが難しくなっています。 ここでいう「認知」とは、単なる企業の知名度のことではありません。QA採用における認知とは、「この会社は品質に対する取り組みをしている」「QAに対する理解がありそうだ」といった、品質への姿勢が伝わっている状態を指しています。 では、どの程度の認知を目指すべきなのでしょうか。いきなり「この会社で働きたい」と思ってもらうことを期待するのは、とくにまだQAエンジニアがいない企業の場合は現実的ではありません。まずは「社名を聞いたことがある」、できれば「あの会社は品質に力を入れているらしい」「QAとしてどんなことが求められそうか、なんとなく想像がつく」くらいのレベルを目指すのが妥当だと考えています。 私自身の体験として、事業会社に転職した後に外部のイベントに参加したり登壇したりしていたところ、「QAがいたんですね！」「募集してたんですね！」「御社の人をあまり外でお見かけしないので」と言われたことがありました。裏を返せば、それまではQAコミュニティの中で社名が認知されていなかったということです。外に出て顔を見せるようになってから、少しずつ「あの会社にはQAがいる」ということが広まっていった実感があります。即効性があるわけではありませんが、じわじわと効いてくるものだと感じています。 QAコミュニティでの認知を獲得する手段 ここからは、QAコミュニティの中で自社の認知を獲得するための具体的な手段をご紹介します。 スカウト・ダイレクトリクルーティング——「攻め」の認知 ビズリーチやFindyなどの媒体を通じてスカウト等を送ることは、応募を獲得するための手段として広く知られています。しかし、スカウトにはもう一つの側面があります。それは「認知を獲得する手段」としての効果です。 いちエンジニアの立場で正直なところを言うと、スカウトに返事をしないことは多いです。（転職するつもりがない場合は特に。）しかし、メールに含まれる文面は読んではいますし、社名も頭に残っています。「あの会社、QA採用してるんだな」という印象が積み重なることで、いざ転職を考えたときに選択肢に入る可能性が生まれます。 ただし、ここには大きな注意点があります。テンプレ感の強いスカウトや、まったく関係のないロールでの「いいね」は逆効果です。一方で、自分のこれまでのアウトプットを見てくれていたり、得意領域を踏まえたうえでの打診であれば、たとえ応募に至らなかったとしても印象は良いです。 面白いのは、経歴について具体的に言及されていてもテンプレ的に感じる文章もあれば、短くてもこちらのことを理解してくれていると感じるスカウトもある、ということです。この違いは言語化が難しい、感覚的な部分ではありますが、候補者側には良くも悪くも伝わっています。 これは前回の記事で述べた「QAを理解すること」と直接つながっています。QAという職種やその人のキャリアに対する理解が浅いままスカウトを送ると、それは候補者に見抜かれてしまいます。理解に裏打ちされたスカウトであればこそ、返事がなくても良い認知につながるのだと思います。 SNS・技術ブログでの発信——「蓄積する」認知 DevRelやHRのSNSアカウントが活発で、タイムラインでよく見かける企業は、それだけで認知につながります。「あの会社、よく発信しているな」という印象は、採用において意外と大きな力を持っています。 「でもうちにはまだQAエンジニアがいないので、QAに関する発信ができない」と感じる方もいるかもしれません。しかし、QAがいない段階でもできる発信はあります。 たとえば、開発組織のトップ（CTOやVPoEなど）の名前で、品質に対する課題意識や今後の方針を発信するという方法があります。これはQAエンジニアにとって「この会社は品質に対して経営層レベルで意識を持っている」「入社したときに後ろ盾がありそうだ」というメッセージになります。QAとして入社するにあたって、経営層の理解と後押しがあるかどうかは非常に重要なポイントです。 また、開発者がテストに関する取り組みを発信することも効果的です。テスト自動化の導入、品質改善の施策、テスト設計の工夫など、QAエンジニアがいなくても開発者自身が品質に向き合っている姿を見せることができます。QAエンジニアから見て、「品質に対して何もしていない会社」と「QAはまだいないけれど、開発者が自分たちでテストに取り組んでいる会社」では印象が大きく異なります。後者のほうが入社後のイメージも湧きやすいです。 大切なのは、「品質に課題があります」という発信だけでなく、「今、こういうことに取り組んでいます」という部分も含めることです。課題の認識が適切にできていること自体がアピールになりますし、取り組みの内容を伝えることで「この会社は本気で品質に向き合おうとしている」という印象を与えることができます。 このほか、QA系のイベントに参加した後に感想ブログを書くのも有効な方法です。学びの姿勢を示しつつ、発信もできるという一石二鳥のアクションと言えます。 イベントへの参加・スポンサー——「存在感を示す」認知 JaSSTなどQA系イベントのスポンサーになっている企業を見ると、「この会社は品質に力を入れているんだな」という印象を持ちます。スポンサーは認知獲得の有力な手段の一つです。 とはいえ、いきなりスポンサーになるのはハードルが高い場合もあると思います。まずはイベントに参加して、QAコミュニティの空気感を知ることから始めるのも良い方法です。前回の記事でも「学びの姿勢で」と述べましたが、認知獲得においても同じスタンスが大切です。 懇親会への参加も、QAエンジニアとの自然な接点を作る機会になります。ただし、注意すべきなのは「採用目的で懇親会に来ている」「採用目的の声がけをたくさんしている」とならないようにすることです。これらは候補者であるエンジニアの間で印象が悪くなってしまうので、あくまでも交流や、QAコミュニティの空気感を知るためのスタンスを守ることが重要です。 また、開発者やDevRelの方がイベントに参加し、その感想をブログに書くというのも認知獲得につながります。「うちの会社の人がQA系イベントに関心を持っている」ということ自体が、QAコミュニティに対するメッセージになるからです。 合同ミートアップの開催——「双方向」の認知 最近では、複数社（3〜4社程度）が合同でミートアップを開催するケースも見られます。各社からのLTやパネルディスカッションを通じて取り組みを紹介し、参加者に「面白そうだな」「この会社で働いてみたいな」と感じてもらうことを狙ったイベントです。 ただし、この手段には難しさもあると感じています。採用目的を前面に出してしまうと、参加すること自体が転職意思の表明のように見えてしまい、エンジニア側からすると気軽に参加しづらくなります。一方で、あくまでも技術イベントというスタンスで開催すると、エンジニア側は気軽に参加できる反面、採用のためのアピールがしづらくなる可能性があります。このように、開催側の意図と建前と、参加者側の思いとが、噛み合いきらない部分があるように見受けられます。 認知獲得の手段の一つとして選択肢に入れておく価値はありますが、設計の難しさは認識しておいたほうが良いでしょう。 QAがまだいない企業の場合 ここまでご紹介した手段の中には、QAエンジニアがまだ社内にいない企業にとってはハードルが高く感じるものもあるかもしれません。 そうした場合は、 前回の記事 でご紹介した「副業QA」の活用が、認知獲得の土台を作る手助けになります。副業QAが社内にいることで発信の内容に説得力が増しますし、イベント参加やスカウト文面の作成においても、QAの専門家の視点を取り入れることができます。 まずは小さく始めて、少しずつQAコミュニティの中での認知を広げていくことが大切です。 連載のまとめ 本記事では、QAコミュニティの中で自社の認知を獲得するための手段として、スカウト・ダイレクトリクルーティング、SNS・技術ブログでの発信、イベントへの参加・スポンサーなどをご紹介しました。それぞれの手段にはそれぞれの特性がありますが、共通して重要なのは、前回お伝えした「QAを理解すること」が前提になっているという点です。理解が浅いままの発信やスカウトは、候補者には伝わってしまいます。 また本連載では、全5回にわたってQAエンジニアの採用について、求職者側・募集側の双方の課題を取り上げてきました。連載を通じて一貫してお伝えしたかったのは、採用活動を「なんとなく」や「他職種と同じように」進めてしまうと、うまくいかないことが多い、ということです。 求職者であれば、募集側がどんな背景でどんなQA像を求めているのかを理解し、それを踏まえてアピールすること。募集側であれば、QAという職種の幅広さや文化を理解し、その理解をもとに認知を獲得していくこと。どちらの立場であっても、相手の行動原理や思いを理解し、汲み取ったうえで行動することが大切です。 この「理解」こそが、QA採用を成功に近づける鍵ではないかと考えています。本連載が、QAエンジニアの採用に関わるすべての方にとって、何かしらのヒントになれば幸いです。 【連載】QAエンジニアの採用・選考［どう採る どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える The post 【最終回】募集側の課題2：QAの中での認知を獲得する first appeared on Sqripts .

こんにちは。QAエンジニアのなおたです。 日々ソフトウェア品質と向き合っている若手エンジニアの皆さん。昨今、「生成AI」という言葉を聞かない日はないでしょう。 先日、生成AI本のベストセラー 『 生成AIで世界はこう変わる 』 （今井翔太著／SB Creative）を読んでみました。想像を超える速度でAIのインパクトは社会全体に及んでいますが、私たちソフトウェア開発の現場、特に「ソフトウェアテスト」の領域は、今まさに変革期の入り口に立っていると感じました。 「AIがテストケースを自動で作ってくれるなら、エンジニアの仕事はなくなるのでは？」 そんな不安や疑問を感じている方も少なくないかもしれません。 しかし、結論から言えば、仕事は「なくなりません」。 ただし、その「質」は根本から変わります。本ブログでは、生成AIがソフトウェアテストをどう変革し、私たちエンジニア、特に若手エンジニアの方々が今後どのようなスキルを身につけるべきか、考察していきます。 なぜ今、ソフトウェアテストが「変革期」なのか IPA（情報処理推進機構）が示すように、ソフトウェアテストは開発プロセスにおいて「品質の作り込み」と「品質の確認」を担う、極めて重要な工程です。（参考: IPA ソフトウェアテスト） ※1 従来の開発（例えばV字モデル）において、テスト工程は多くの工数とコストを要する領域でした。テスト設計の属人性、テストケースの網羅性の担保、膨大なリグレッションテストの工数確保等 これらは、多くのプロジェクトが抱える共通の課題です。 まさに今、この領域に、生成AIがメスを入れようとしています。 生成AIが可能にすること（例）： テストケースの自動生成: 仕様書（自然言語）を読み込ませ、境界値や同値分割を考慮したテストケースを瞬時に生成する。 テストデータの多様化: 正常系だけでなく、異常系やエッジケースのテストデータを大量に生成する。 テストコードの自動記述: E2Eテストや単体テストのコード（例: Selenium, JUnit）を生成・修正する。 バグ報告の初期分析: ログやエラーメッセージをAIが分析し、原因のあたりをつけたり、バグ報告書を自動起票したりする。 リグレッションテストの最適化: コードの変更箇所を解析し、影響範囲を特定。実行すべきテストケースを最小限に絞り込む。 これらが実用レベルになれば、テストにかかる工数や時間は劇的に減少するでしょう。もはや「テストは作業工数で頑張るもの」という時代は終わりを告げ、 生成AIの活用を前提とした新しいテストプロセス が主流になる。これが、私たちが「変革期」と呼ぶ理由です。 ※1 IPA 独立行政法人 情報処理推進機構 新しい視点：AI時代に「本当に」求められるスキルとは？ 視点を変えてみましょう。テスト作業の多くをAIが担うようになったら、エンジニアの価値はどこにあるのでしょうか？ ここで、一つの重要な視点があります。それは、 「生成AIを活用するためには、基礎的なビジネスリテラシーが、むしろ以前より重要になる」という逆説的な事実です。 生成AIは「万能の魔法」ではありません。AIは「指示されたこと」しかできません。 そして、その指示が曖昧で不明確であれば、AIが生み出すアウトプット（テストケースやコード）もまた、曖昧で使い物にならないものになります。 つまり、私たちが獲得すべき新しい知的スキルとは、以下の3つに集約されます。 1. 高度な「仕様読解力」と「要件定義能力」 AIに的確なテストケースを生成させるためには、 エンジニア自身が、その機能の「要件」と「仕様」を完璧に理解している 必要があります。 「この機能の目的は何か？明示的、暗示的な意味は何か？」 「ユーザーにとっての本当の価値はどこにあるのか？」 「仕様書のこの一文の『行間』に隠された暗黙の前提条件はどこにあるのか？」 要件を深く理解し、AIが解釈できる明確な言葉（プロンプト）に落とし込む能力。 これこそが、AI時代のテストエンジニアに求められるメインスキルです。 曖昧なテスト仕様書を渡されて「あとはAIさん、よろしく」は成立しません。 AIを使いこなす前提として、人間の本質的な能力と知見、深い洞察力が問われるのです。 2. 「論理的思考」に基づくテスト設計能力 AIが何千ものテストケースを生成したとして、その妥当性を誰が判断するのでしょうか？ 「網羅性、カバレッジは十分か？」 「重要な観点（セキュリティ、パフォーマンス、ユーザビリティ）が抜けていないか？」 「AIが“見落としているケースはないか？将来の潜在リスクはないか？」 これらを判断するには、基本仕様の理解やテスト設計の原理原則（同値分割、境界値分析、状態遷移など）を深く理解した上での「論理的な思考力」が不可欠です。 AIは「作業」自体は高速化しますが、「基本設計の思想」や「品質保証」を担保してくれるわけではありません。AIの出力を鵜呑みにせず、クリティカルに評価し、テスト戦略全体を設計する「知的アーキテクチャ」としての役割が重要になります。 3. 基礎的な「読み書き能力」 ここでいう「読み書き能力」とは、言語化力そのものです。 書く力: AIへの的確な指示（プロンプトエンジニアリング）、ステークホルダー（開発者、PM）への明瞭なバグ報告、AIが生成したドキュメントの校正。 読む力: 膨大な仕様書の本質を掴む読解力、AIの生成物を迅速にレビューする能力。 結局のところ、私たちの仕事は「言葉」で成り立っています。AIという新しい”仲間”と正確にコミュニケーションを取り、プロジェクトを円滑に進めるための「読み書き能力」の重要性は、かつてないほど高まっていると考えます。 まとめ：変革を乗りこなし、新しい価値を生み出すAIテストエンジニアへ 生成AIの登場により、「ソフトウェア産業」全体が抜本的に変わることは間違いありません。特に、ソフトウェアテストの現場は、その影響を最も強く受ける領域の一つです。 テストエンジニアの役割は、「手を動かしてテストを実行する人」から、「AIを駆使して、品質レベルをどのように高めて、どう保証するかを設計・判断・評価する人」へとシフトしていくでしょう。 こうした変革の中で、実際のテスト現場でも新しいAI駆動型のソリューションが登場し始めています。 例えば、AGESTが展開する次世代AIテストツール『TFACT』のように、生成AIの力をテストの標準プロセスに組み込んだAIプラットフォームもその一つです。 ■AGEST AIテスト管理ツール ｜ TFACT 自律走行型AIソリューションは、私たちのテストプロセスを劇的に効率化してくれる強力なパートナーとなり得ます。 そして、AIに意図通りのテストを行わせるためには、曖昧さを排除し、「正確な言葉」で表現する力が不可欠です。ツールが進化すればするほど、そのツールを指揮する人間の「言語化能力」や「論理的思考」の価値はむしろ高まるのです。 若手エンジニアへのエール 若手エンジニアの皆さんにとって、この変革は「脅威」ではなく、むしろ「チャンス」です。なぜなら、ベテランエンジニアが長年の経験で培ってきた「経験」や「勘」の一部をAIが補完し、若手エンジニアは新しい発想とAIツールで勝負できるからなのです。 今、身につけるべきは、特定のツール操作ではなく、 1. 仕様を深く読み解く力。 2. 物事を論理的に考える力。 3. 要件を深く理解し正確な言葉で表現しATに的確なプロンプトを定義できる力。 という、極めて「基礎的」で「普遍的」なスキルです。 このAI変革の波を恐れず、AIという強力な仲間を使いこなし、ソフトウェアの品質を支えるプロフェッショナルとして、共に未来に向けて成長していきましょう。 プロフィール： QAエンジニアなおた 前世紀は主に大手携帯通信事業者の海外（米国・英国・インド）新規事業開発マネジャーとして従事。 今世紀は、主に自動車向けコネクテッドカーの企画コンサルティング、開発実務の支援、実装テスト関連のPMを経験。近年は幅広い企業クライアント向けQAコンサルタントとして活動中。 The post 生成AIはソフトウェアテストを”破壊”するのか？ ー 若手エンジニアが備えるべき「変革」と「新しいスキル」 first appeared on Sqripts .

技術を土台にして自分なりのQAエンジニアを目指す本連載、第9回のテーマは「コーチング」です。 QAやテストの専門性からすると、少し遠い領域だと感じる方も多いかもしれません。正直、私自身、コーチングというものを「なんだか怪しいもの」だと思っていました。 しかし、アジャイルコーチなど現場の最前線で活躍する方々の話を聞くうちに、その認識は大きく変わりました。 人々のアウトプットとしての「品質」を本当に良くしていく、あるいは組織の「品質文化」を変えていくためには、コーチングの技術が極めて有用であると考えたのです。 その気づきから、私自身も本格的に個人やシステムに対するコーチングを学ぶため、スクールに通い始めました。 今回は、私にとって最も直近で築かれた新たな「土台」であるコーチングについてお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む 「教える」から「引き出す」への転換 QAエンジニアとして活動する中で、私は品質やテストについて、比較的解像度高く言語化してきた、あるいは『自分にはそれができる』という自負がありました。 しかし、その自負が、時にチームに対して「専門家としての正解を押し付ける」ような振る舞いを生んでしまっていたと今では思います。 テストにおいても、品質保証においても、「こうあるべきだ」という強い思いがありました。 そういった状態で特に「QAエンジニア」という役割を担ってしまうと、「高圧的で怖い人」として映ってしまうことも少なくありません。 もちろん、専門家として意見をはっきりと伝えることが必要な場面は多々あります。 しかし、人の行動やマインドセットを変容させようとするフェーズになったとき、専門家からの一方的な指摘だけでは人は生き生きと動くことは困難だと気づいたのです。 そんな中で、コーチングという技術を詳しく知る機会がありました。コーチングという技術あるいはその関わり方が、その人の内発的動機を高め、行動に繋げることができるものだと知りました。 そして、実際にコーチングを実践するときには、単なる「聞く」「質問する」といった目に見える表面的な技術だけでなく、自己基盤やコーチングマインドが大事だと知ったのです。 私が実際に通った銀座コーチングスクールでは「コーチングピラミッド」という形で示されています。 図：銀座コーチングスクールのコーチングピラミッドを参考に作図 https://www.ginza-coach.com/overview/feature/curriculum.html （参照日:2026/3/21、最終更新日2026/1/20） 自己基盤 まず、コーチングピラミッドにおける「自己基盤」という考えを示しておきたいです。 これは私の理解で言えば、コーチ自身がクライアントに対して恥じることのないあり方を体現していることです。「プロのコーチ」としてプロフェッショナリズムを持っていることだと考えています。 これはQAエンジニアとしての土台にも同じことが言えます。私自身の自己基盤もまた、「プロであること」に加え、例えば「高い倫理観を持つ」「自分自身を裏切らないこと」をベースとしています。 安易に「見栄えのいい専門家」を演出してしまうと、結果として自己欺瞞に繋がり、それは自分自身の自己基盤を揺るがしてしまうと考えています。 泥臭くても自己開示し、困難に対しても正面から向き合えるような、「良いクライアントの鏡でもある」という自負が、私自身のプロフェッショナリズムを育てていると考えています。 コーチングマインド コーチングを学んだことによる最大の収穫は、「答えは相手の中にある」というマインドセットを得たことです。 コーチングを書籍などで表面的な手法だけ学んでしまうと、「質問」や「聞く」といったスキルで終始してしまうことも少なくありません。私自身も実際にそういった過ちを犯していました。 今ではコーチングマインドや自己基盤、信頼関係といった土台の構築こそが、専門性として身につけるべき本質だと思っています。 相手の中にある視点や気づきをどのように発見し、どう繋げていくか。 この「あり方」こそが、特にQAエンジニアがコーチングを学び、品質文化を醸成する上で非常に重要だと確信しています。 その「答え」は、実は相手が自覚していない場合があります。 むしろ「答え」に向き合う過程で、相手を困難に直面させるようなこともあるかもしれません。 そのような場合であっても、相手のプロフェッショナリズムを心から信頼し、目を背けたくなるような事実を鏡のようにフィードバックすることも、コーチとして時に必要になると考えています。 コーチングの技術を品質保証に活かす コーチングには「聞く」「認める」「フィードバックする」「質問する」といった技術があります。 上記で述べたように、これらの技術を土台なしに実施することは、本質を欠いたまま適用してしまう危うさがあります。 一方で、正しくこれらを用いて、クライアントの壁打ち相手になったり、適切な問いかけを行ったりすることは、品質保証の活動と非常に相性が良いです。 ここからは、コーチングの技術が、これまでの連載で触れてきた専門性とどのように組み合わさるのかを紹介します。 専門性の組み合わせ：テスト計画(リリース基準)との組み合わせ テスト計画を立てたり、リリース基準をチームで合意したりする際、コーチングの「問いかけ」や「フィードバック」の技術が力を発揮します。 第３回 でテストマネジメントは「合意形成」の技術だと述べましたが、その合意を真に納得感のあるものにするための具体的なアプローチの一つが、このコーチング的な「問いかけ」です。 QAエンジニアが一人で基準を決めるのではなく、チームに対して次のような問いを投げかけます。 「どういう状態になれば、自信を持ってリリースできますか？」 「あなたがステークホルダーであればこの製品に対してどう感じますか？」 「あなたが知っているステークホルダーはどのような人ですか？」 このように相手の思考や気づきを引き出すことは、チームが品質に対するオーナーシップを持つことに役立ちます。 自分自身の言葉で紡ぎ出したオーナーシップは、「生きた品質文化」として根付いていくと考えています。 専門性の組み合わせ：テスト実行との組み合わせ テスト実行を通じてメンバーの成長を促す場面でも、コーチングは有効です。 テスト実行中に手が止まっているメンバーや、バグを見つけたメンバーに対して、「こういう視点でテストしなさい」と教えるのではなく、気づきを促す問いを投げかけます。 「今、テストを実行していて何に気づきましたか？」 「もし自分ではなく、別のユーザー(あるいは尊敬するテスター)だったら、次にどうすると思いますか？」 「あなたが作り手だったらどんなフィードバックを望むでしょうか？そのためには何をすればいいですか？」 「こういう視点があるよ」と教え込むのではなく、「あ、こういう視点もあるんだ」と自分自身で気づいてもらうこと。 これが、テスト実行における個人のスキルアップや深い洞察に繋がります。 おわりに QAエンジニアとしてコーチングの技術を扱う上で重要だと考えている点があります。 それは「コーチング技術を自分自身の存在価値のため、あるいは相手のメンタルケアのために使わない」ということです。 QAエンジニアの専門性とコーチングを複合した時に、個人の感情やモチベーションだけではなく、「システム（構造）」に直面することがあると感じます。 例えば、バグが放置されがちな現場があったとします。 ここで「どういう理由で直さないの？（本当はどうしたいの？）」と個人のモチベーションを聞いたり、あるいはただ共感して寄り添うだけでは、根本解決にならないと感じています。 コーチであると同時にQAエンジニアとして考えたとき、このような状況では品質保証の原則である「源流管理」に立ち返ることも時には必要です。 プロのQAエンジニアが行うコーチングとは、我々が理解できていることや、ソフトウェアの動作、バグの発生状況といった「客観的な事実」と向き合うことです。 そして、「この事実が、今の私たちのシステム（開発プロセスやチームのコミュニケーション構造）のどこに問題があることを示しているのか？」という問いを立て、メンバーのプロフェッショナリズムを信じて共に探索していくことだと考えています。 コーチングは、ソフトウェアテストや品質保証とは遠い場所にあるように思えるかもしれません。 しかし、それは「プロとしてのあり方」を学び、チームと協調しながら根本的な品質文化を形作るための、非常に強力な技術です。 この新たな土台が、皆さんのQAエンジニアとしての幅を広げる一つのヒントになれば幸いです。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む The post 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む first appeared on Sqripts .

こんにちは。Sqripts編集部のハチワレです。 最近は生成AIに携わることが多く、日々の進化を驚きと喜びを感じながら眺めています。そして、「コードを書く」ことの垣根がどんどん低くなっていることも、「AIってすごいな～」ぐらいの気持ちでただただ感心して眺めておりました。 今回は、そんな私が実際に遭遇した「ちょっとヒヤッとした話」をもとに、生成AI時代の実装リスクについて書いてみたいと思います。 あくまで「とあるDX現場の物語」として読んでいただければ幸いです。 ※本記事は、実際に現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。 ある日、フォームが動かなくなった 「フォームが表示されません」 こんな連絡が届いたのは、ごく普通の業務日のことでした。 確認してみると、たしかに挙動がおかしい。コードに少し修正を加えるように伝えると、今度はこう返ってきました。 「フォームは動きましたが、フォーム送信完了ページ（サンクスページ）が404です！」 ……サンクスページが、ない！？（404は「ページが見つかりません」のエラーコードです） 調査を進めてみると、MA（マーケティング・オートメーション ※ ）側の設定を、あるマーケティング担当者が生成AIと対話しながら変更していたことがわかりました。 ※マーケティング・オートメーション（MA）とは、フォームの発行、ユーザー管理、メール配信など、マーケティング活動に関わる様々な機能を持つツールのことです。 「動いた」と「大丈夫」は、まったく別の話 その担当者に、開発の経験はありません。 それでも、生成AIに「やりたいこと」を自然言語で説明してJavaScriptのコードを生成してもらい、MAに実装することができました。 コードは動き、担当者は大きな成功体験を得ました。 問題は、誰もその「先」を確認していなかったことです。 — ここで少し、「影響範囲」という概念についてお話しさせてください。 システムやWebサイトを構成するコードは、それぞれが独立しているようで、実はさまざまな形でつながっています。あるページの挙動を変えるコードが、別の処理の前提条件になっていることも珍しくありません。 今回のフォームと送信完了ページがまさにそれでした。 表から見ると、「フォームを送信する。送信後に『ありがとうございました』のようなページが表示される」というシンプルな存在です。しかし裏側では、いくつかの処理が連鎖していました。 フォーム送信の完了を検知して計測する処理 送信者の情報をほかのツールに連携する処理 担当者への通知やスコアリングに関わる処理 など、このフォームから送信完了ページへの遷移は、「ユーザーが正常にフォームを送信した」というシグナルでもあったわけです。そのシグナルを受けて、複数のシステムが動いていました。 変更されたコードは、この一連の流れに割り込みました。結果、送信完了ページは404エラーを返し、連携データは正常に記録されなくなっていました。フォームそのものは見た目上は「動いて」いましたが、その裏側で起きるべきことが、静かに止まっていたのです。 影響範囲スコープの例 フォームが「動いた」のは確かです。でもそれは、「大丈夫」ではありませんでした。 影響範囲とは、「自分が触れたコードが、どこまでの処理に関係しているか」という見取り図のようなものです。この見取り図を持っているかどうかが、「動かせる」と「安全に実装できる」の分かれ目になります。 悪意があった人は、誰もいない 誤解のないようにお伝えしておくと、今回の件で悪意があった人は一人もいません。 担当者は業務を効率化しようとしていましたし、生成AIを活用しようとしていました。その姿勢は、むしろ前向きです。 Webサイト側の担当者も、相談は受けていました。ただ、コードの中身をレビューできる知識はなく、「何かを変えるらしい」とは知っていても、何がどう変わってどんな影響が出るかまでは判断できませんでした。 そして、もうひとつ大事なことがあります。 実装した担当者は、そもそも「フォームや送信完了ページに『他の働きをする何か』が仕込まれている」という知識を持っていませんでした。表から見ればただの入力フォームと送信完了ページ。まさか、その裏側でツール連携や計測が動いているとは、思いもよらなかったのです。 「確認しなかった」のではなく、「確認すべきものがあると知らなかった」。これは責める話ではありませんが、だからこそ厄介です。本人の注意や意識だけでは、防ぎようがない。 誰も手を抜いていないのに、システムは壊れた。 これが今回、私が一番伝えたいことです。 「コードが書けない」という壁が、なくなった 少し前まで、「コードが書けない人」はコードを書きませんでした。当たり前のことですが。 やりたいことがあっても、実装する手段がない。だから、担当範囲を超えた変更は物理的に起きにくかったのです。 「この機能を変えたい」と思っても、コードが書けなければエンジニアに依頼するしかない。依頼するということは、必然的に「何をどう変えたいのか」を説明し、確認してもらうプロセスが発生する。面倒に感じることもあったでしょうが、このプロセスが「影響範囲の確認」を担っていたと言えます。 生成AIは、その壁を取り払いました。 プログラミングの知識がなくても、やりたいことを言葉で説明すれば、動くコードが出てきます。エンジニアへの依頼も、確認のプロセスも、必要なくなりました。 これ自体は、すごいことです。間違いなく。 ただ、壁が取り払われたとき、同時に「ゲート」も消えてしまいました。 エンジニアが影響範囲を判断するタイミング、このプロセスが、いわば「実装前のゲート」として機能していたのです。生成AIによって誰もが一人で完結できるようになったことで、そのゲートもなくなってしまいました。 「書けるようになった」と「わかるようになった」は、まったく別の話です。 生成AIはコードを書いてくれます。でも「このコードが既存のシステムと干渉しないか」「影響を受けるのはどの処理か」「変更前に誰に相談すべきか」という問いを立てられるのは、影響範囲の見取り図を持っている人、つまりシステム全体を俯瞰して把握している人だけです。 もちろん、生成AIにその見取り図を渡すことができれば影響範囲の判定もしてくれます。 ですが、見取り図を持たない人に、その「問いを立てる力」は、生成AIは与えてくれません。（今のところ） だからこそ、「人間が介在する」設計が必要になる ここで、AIの世界でよく使われる概念をひとつご紹介したいと思います。 HITL（Human-in-the-Loop） という考え方です。 AIによる自動化されたプロセスに、意図的に人間が介在する仕組みのことを指します。AIが得意な「大量処理・高速生成」と、人間が得意な「判断・文脈の理解・倫理的な配慮」を組み合わせることで、より質の高い結果を目指す、という発想です。 私はこの概念がとても好きで、AIの活用を考えるときの基本的な視点として大切にしています。 今回の件は、まさにHITLが機能していなかったケースです。 生成AIがコードを生成する→人間がそのまま実装する、という流れに、「影響範囲を判断できる人間」が介在していなかった。AIの出力を人間がレビューし、「これは既存のシステムに影響しないか」「担当者に確認が必要ではないか」と判断するステップが、すっぽり抜けていました。 AIを使うこと自体が問題なのではありません。AIの出力をそのまま「正解」として扱い、人間の判断を挟まなかったことが、問題だったのです。 「これ、大丈夫なやつ？」という感覚 私はこれを、「大丈夫チェック」と呼んでいます。 コードを実装する前に一瞬立ち止まって、「これ、大丈夫なやつ？」と自問する。シンプルな問いですが、これができるかどうかが、今の時代に大きな差を生むのではないかと思っています。 具体的には、こんな確認です。 全体のシステムのどの部分に触れる変更か 既存のコードや設定と干渉する可能性はないか 担当者への事前確認は完了しているか こうした確認を、属人的な「声かけ」に頼るだけではなく、チームの手順として持っておくこと。それが「動いた」と「大丈夫」のギャップを埋める方法だと、今回の経験から強く感じました。 そして、この「大丈夫かどうか」を 仕組みとして担保する のが、「テスト」という考え方です。 変更後に期待通りに動くかを確認するだけでなく、「既存の動作が壊れていないか」を検証するテスト（リグレッションテストと呼ばれます）は、まさに今回のようなケースの再発を防ぐための安全網になります。 生成AIが実装の入口を広げたことで、テストの重要性もまた、以前より増していると感じています。 関連記事 リグレッションテストとは？目的、実施タイミング、実施方法、自動化について解説 リグレッションテストとは「リグレッションテスト」（Regreesion Test／レグレッションテスト）は、ソフトウェア開発におけるテスト手法のひとつで、「回帰テスト」「退行テスト」とも呼ばれます。リグレッションテストは、プログラムの修正や変更を行った際に、変更... 　続きを読む　 Sqripts まとめ 今回お伝えしたかったことを整理すると、こうなります。 「動いた」≠「大丈夫」 ：生成AIが生成したコードが動作することと、既存システムに悪影響を与えないことは別の話 壁がなくなった時代のリスク ：誰でも実装できるようになったからこそ、「影響範囲を測る」プロセスの重要性が増している 悪意より怖い「善意のインシデント」 ：誰も悪くないのに壊れる、というケースへの備えが必要 「問いを立てる力」は人間が持つ ：生成AIはコードを書いてくれるが、「これ大丈夫？」と問えるのは、構造を知っている人間だけ HITLの視点を持つ ：AI任せにするのではなく、判断できる人間がプロセスに介在する設計を意識する 「テスト」は「大丈夫」を仕組みにする手段 ：変更が既存の動作を壊していないかを確認するテストが、善意のインシデントを防ぐ安全網になる 生成AIの登場で、ソフトウェアに関わる実装のハードルは確実に下がっています。だからこそ、「実装してよいかを判断する人・仕組み」の価値は、むしろ上がっているのではないでしょうか。 この記事が、どなたかの現場での一助になれば幸いです。 最後までお読みいただき、ありがとうございました。 本記事は、実際にとあるDX現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。 ▼非エンジニアにもおすすめの関連記事 関連記事 Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた｜知識ゼロから始めた学習方法と試験対策 こんにちは。Sqripts編集部のハチワレと申します。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。「非エンジニア」を称しています。今回は、非エンジニアの私がGoogle Cloudの認定資格、Generati... 　続きを読む　 Sqripts 関連記事 生成AIの基礎リテラシーと明日から業務で使える活用術 こんにちは。Sqripts編集部のハチワレです。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。技術と非技術の狭間に佇み、両方の世界を行き来する日々を過ごしております。前回は「Generative AI Le... 　続きを読む　 Sqripts The post AIがコードを書いた。動いた。でも、システムは壊れていた話。 first appeared on Sqripts .

みなさまこんにちは、天野です。 私は前職のサイボウズでスクラムを導入し、同社初のスクラムマスターとして長年活動してきました。社内のアジャイル導入の過程でさまざまな職能のメンバーと関わり、特に品質については強い関心を持って取り組んできました。プロダクションレベルの品質をいかに素早く確立するか、スプリントの中でどう品質を満たすか、といったテーマです。 その中でQAのメンバーとも多くの時間をともに過ごし、品質や人材の成長について考えてきました。後年はマネージャーとしてQAメンバーのキャリアを支援したり、QAからスクラムマスターに転身したメンバーをマネジメントしたりもしてきました。 組織の中にいるときは当たり前だったことが、外に出てみてはじめて「あれが自分を育てていたのか」と気づくことがあります。社内での実践と社外への発信を行き来する中で得てきたものを、一人の実践者として届けたい。それがこの連載を書こうと思った理由です。 本連載ではそんな背景をもとに、「社内外を往復するアジャイルQAの育ち方」というテーマで全4回の記事を書かせていただきます。よろしくお願いします。 アジャイルな人材とは さて、連載の第1回となる今回は「アウトプット」の話から始めたいと思います。 まず、アジャイルなQAとは何でしょうか。私は、QAに限らず「アジャイルな人材」とは、学習する力が高く、これまでのやり方に固執せず、新しいことを吸収しながら改善を重ね、自律的に仕事をより良くしていける人だと考えています。 こうした学習する力は、何によって支えられているのでしょうか。一つには書籍を読む、ウェブから情報を得るなど、個人的なインプットがあります。もちろんそれも重要です。しかし、インプットした情報を踏まえて実際に手を動かし、発信する。そこで他者からフィードバックを得て議論し、新たな知見を蓄積し、さらに実践を深めていく。このサイクルを回している人は、学習する力が極めて高いと感じます。 インプットにとどまらず、実践、発信、フィードバック、それをさらに実践に生かすサイクル。この起点としてまず取り組みたいのがアウトプットです。 「アウトプットした方がいい」のに踏み出せない理由 アウトプットの重要性を語る場面でよく聞くのが、「した方が良いと分かっているけれど、なかなかできない」という悩みです。 アウトプットできない理由としてよく挙がるのは、こんなものです。 「時間がない」 「マサカリが飛んでくるのが怖い」 「自分なんかがやっていることを発信しても大した価値はないのではないか」 「もっとちゃんとした成果が出てから発信したい」 正直に言えば、私もかつてはこれらすべてに当てはまっていました。特に「もっとちゃんとした成果が出てから」という気持ちは強く、書けずにいた時期が長くありました。 理由はそれぞれ異なりますが、共通しているのは アウトプットのハードルが高くなっている ということです。特にQAに携わる方は、日頃から品質を見極めることを仕事にしているぶん、自分のアウトプットに対する暗黙の品質基準も高くなりがちではないでしょうか。その根底には、アウトプットとは十分な成果をまとめ上げた「完成品」であるべきだ、という前提があるように思います。つまり、 アウトプットを活動の「ゴール」として捉えている のです。 しかし、アウトプットをゴールと捉えると問題が起きます。私たちの仕事は明確な区切りがないものも多く、基本的にはずっと続いていきます。「区切りがついたらアウトプットしよう」と思っていると、なかなかそのタイミングが見つからず、ハードルが上がり続けてしまいます。 これはソフトウェア開発に喩えれば、ウォーターフォール的な「ビッグバンリリース」の発想です。すべてが完成してから一括でリリースしようとすると、リリースそのものが重く、遠くなっていく。アジャイルの考え方に従えば、リリースはできるだけ小さく、高頻度に届け、そこからフィードバックを受けて学ぶというサイクルを回します。 アウトプットも同じです。小さくして頻繁にリリースすれば、学習のサイクルが速く回り始めます。そしてそれは、アウトプットそのもののハードルを下げることにもつながるのです。 アウトプットは「思考のインクリメント」 私が提案したいのは、アウトプットを自分の活動から生まれる「インクリメント」の一つとして捉えることです。スクラムにおけるインクリメントとは、スプリントごとに積み上がる「利用可能な成果物」のことです。一定の周期で小さな成果物を届ける仕組みがあるからこそ、「検査と適応」のサイクルが回ります。 アウトプットにも同じことが言えます。自分の活動や考えを定期的に言語化して外に出していれば、そのアウトプットが検査と適応の対象になります。アウトプットは自分の思考の過程そのものですから、つまり 自分の思考や考え方そのものが検査と適応の対象になる わけです。 これは極めて強力な、思考を鍛える仕組みです。アウトプットとは、頭の中にあるものをそのまま外に出す作業ではありません。 教育心理学者のBereiterとScardamaliaは、著書『 The Psychology of Written Composition 』(1987)の中で、書くプロセスを「知識伝達（knowledge telling）」と「知識変換（knowledge transforming）」の二つに区別しました。知識伝達とは、知っていることをそのまま書き出すこと。一方、知識変換とは、読者に伝わるように構成を考え、言い回しを工夫する過程で、「そもそも自分は何が言えるのか」「どこが弱いのか」が露呈し、知識や理解そのものが更新されていくプロセスです。 アウトプットの過程ではまさにこの知識変換が起きています。言語化する過程で、理解の怪しい点が否応なく炙り出されます。書き進めるうちに、曖昧だった思考の輪郭が次第にはっきりしてくる。書いたものを読み返し、スムーズに読めるか、論理に齟齬がないかを確認する。こうした一連のプロセスが、対象についてより深く考えることを促し、累積的な思考量を増やしていきます。 つまりアウトプットとは、思考を「出す」行為であると同時に、その過程で思考内容が検査され、思考を「鍛える」行為でもあるのです。 なぜアウトプットが自己変容を促すのか 継続的なアウトプットは、思考量を大きく押し上げます。書くことでインプットへの欲求も自然と高まり、学びのサイクルが加速していきます。 また、認知心理学では「プロテジェ効果」と呼ばれる現象が知られています。他者に教えるつもりで学ぶと、自分のために学ぶ場合よりも学習成果が向上するというものです。興味深いのは、実際に教えなくても「教えるつもりで準備する」だけで効果があるという点です。つまり、「読者に伝えよう」と意識してアウトプットを準備する行為そのものが、学びを深めているのです。 さらに重要なのは、継続的なアウトプットを支えるには、長期にわたる「一貫したテーマ」が必要になるということです。 一貫したテーマを持つと、常にそのテーマについてアンテナを張るようになります。アンテナを張った状態とは、すなわち問いを立てている状態です。これが普段の思考と行動に影響を与えます。 たとえば「開発チームの品質文化を育てる」というテーマを持っていれば、日々のテスト設計やレビューの中でも常にそのレンズで物事を見るようになります。気づいたことや試行錯誤をアウトプットすることが、さらなる行動変容を駆動する。こうしたループが回り始めます。 また、過去のアウトプットを見返せば、自分の思考の変遷を辿ることができます。差分を比較することで、さらに理解が深まる。このように、アウトプットは強力に自己変容を促す仕組みとして機能します。 ここで一つ強調しておきたいのは、このプロセスを自分自身で経験することの重要性です。今はAIに文章を書かせることも容易になりました。しかし、構成を考え、言葉を選び、論理を組み立てるプロセスそのものが思考を鍛えているのです。それをAIに外注してしまうと、アウトプットから得られる学習効果の大部分を手放すことになります。AIは下調べや推敲の相談相手としては有用ですが、「自分で考えて書く」という核の部分は、自分でやるからこそ意味があります。 PVやバズを目的にすると続かない 昔の私はエンジニアブログを書いては、はてなブックマークが何件つくかで一喜一憂していました。「ホッテントリ入りだ！」「300ブクマ超えた！」といった具合です。正直なところ楽しかったですし、書くモチベーションにもなっていました。 ただ、反応というのは期待したようにはつかないものです。数字を目的にし続けると、伸びなかったときに落胆し、だんだん手が止まるようになりました。また、必要以上に注意を引こうとして、炎上や論争を煽るような記事を作る「歪み」をもたらすリスクもあります。そうした記事には批判的なコメントもつきやすく、不毛な応酬は精神を消耗させます。 PV数やLike数を目的にすると、価値判断の基準が単純な数値に置き換えられます。さらに厄介なのは、「もっと注目されるにはどうすればいいか」という問いが頭を支配しはじめることです。これは、学びの促進や自己変容という本来の目的から大きく逸れた動機です。 では、何を目的にすればいいのか。ここまで述べてきたように、アウトプットの本質的な価値は、累積的な思考の蓄積と自己変容にあります。それを目的とするならば、アウトプットした時点で目的は達成されます。反応がつくかどうかはあくまでおまけです。「書くことそのものが自分を鍛えている」という実感があれば、外部の数値に振り回されることなく、アウトプットを続けていくことができます。 何のためにアウトプットするのか アウトプットの目的としては、他にもよく語られるものがあります。特に会社のエンジニアブログのような公式の媒体では、「採用につなげる」という目的が必ずと言っていいほど挙がります。実践の結果や学んだことをブログに書いておけばポートフォリオになり、転職や副業の際にキャリアのプラスになるという考え方もあります。 これらはアウトプットの成果として確かに大切です。ただ、人によっては「採用のために頑張ろう」「転職に有利だから書こう」と言われても、今の自分にとって少し遠い話に感じられ、なかなか手が動かないこともあるのではないでしょうか。少なくとも私はそうでした。 そこでもう一つの捉え方を提案したいのが、これまで述べたような「自分自身を変容させるための手段」、そして「学びを得るための手段」としてのアウトプットです。この捉え方であれば、活動自体に意義を感じ、取り組むための心構えができるのではないでしょうか。 そして、自分を鍛えるためにアウトプットを続けていると、結果としてその知見が誰かの参考になっていたり、業界全体の学びの蓄積に貢献していたりすることがあります。採用やキャリアへの好影響も、狙って得るものではなく、続けた先に自然とついてくるものです。 まずはリズムを作ることから とはいえ、自己変容「だけ」を目的にすると、変化を実感するまでに数年単位の時間がかかります。それはそれでしんどいものがあります。 ただ、実際にアウトプットを続けてみると、もう少し手前の段階で変化を感じられるものです。書く過程で自分の理解の穴に気づく。人に読まれることを意識して構成を考えるうちに、普段の仕事でも論理の組み立て方が変わってくる。こうした小さな手応えは、数回のアウトプットで感じ始める人が少なくありません。 おすすめなのは、「アウトプットのリズム」だけを決めて、淡々と続けることです。その過程で、たまにバズったり仕事の機会につながったりすればラッキー、くらいの気持ちでいるのが長続きのコツだと思います。 いきなり公開のブログを書く必要はありません。まずは日記やメモでも十分です。書くこと自体が思考を鍛えるプロセスだからです。 その上で、もし一歩踏み出せるなら、社内のSlackやチャットで今日学んだことを一言書いてみてください。日報や週報に「気づいたこと」の欄を設けてみるのもよいでしょう。こうした小さなアウトプットも立派なインクリメントです。外に出すことで他者からフィードバックが得られ、学びのサイクルの質がぐっと上がります。チームや組織にとっても、ナレッジが蓄積されるという大きなメリットがあります。 慣れてきたら、書き溜めたものを少し整理して社内のナレッジベースやブログにまとめてみる。隔週でも月一でも構いません。 大切なのは、始めること。そして、続けることです。 次回は、「では具体的に何をどう書けばいいのか」という実践的な話に踏み込みます。日々の仕事を「記事になる形」に整える技術についてお伝えします。 The post 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す first appeared on Sqripts .

エンジニアのキャリアにおいて、技術を極め続けるICとしての道が理想とされることも多い一方で、現実には企業によってICキャリアが用意されていないことも少なくはありません。 もし、あなたがQA技術者のトップとしてだけではなく、QAマネージャーという立場で誰かの将来も同時に背負うことになったとき、一体どう立ち振る舞うべきでしょうか。連載の最終章となる今回は、前回までとは少し趣を変え、マネージャーの観点も含めて「メンバーと一人の人間としてどう向き合うべきか」というテーマでお話しします。 記事一覧：AI時代だからこそ「あなたにお願いしたい」と頼まれるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」（連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ 【第4回】深夜のラーメンがやめられない僕たちは、いかにして「シフトレフト」を実現すべきか 【最終回】思い通りにならない他者へ敬意を シニアが直面するかもしれない、とある「孤独」 あなたがもし組織のリーダーとして頂に立つと、きっとメンバーを手塩にかけて育てることでしょう。そのうち、「右腕」と呼べる大切な存在が生まれるかもしれません。しかしその時、もしかしたらこんな悩みに出会うかもしれません。 「自分のチームメンバーは、どんなミッションも完璧にこなしてくれる。でも、私の『理想』は体現してくれない。特に右腕にはもっと多くの理想を体現してほしい！」 このような寂しさを感じるかもしれません。でも、その正体は、 「機能的な右腕」と「精神的な右腕（イズムの継承者）」のズレ にあります。メンバーはあなたの「忙しさ」を分かち合ってくれるかもしれませんが、あなたの「孤独や葛藤」を分かち合ってはくれないものです。特にあなたの右腕には多くを求めてしまうかもしれませんが、それは右腕であっても同じで、そういうものなのです。 立場が全く異なるため、もしかしたら彼は優秀な右腕であっても、「理想を継承した右腕」ではないのかもしれません。 全てを一人に求めないことも「信頼」の一つ もし、あなたが「理想の継承」と「実務遂行」をメンバーや右腕に同時に求め、それが叶わないことに寂しさを感じているなら、組織には2つのタイプの人材がいることを思い出してください。 宣教師タイプ： ビジョンに共感し、その「意図」を追い求める人。 傭兵タイプ： プロとして「どうやるか」を極め、タスクを完遂することに喜びを覚える人。 あなたがそのように悩むのは、あなたの右腕は、極めて優秀な「傭兵」タイプなのでしょう。 もし彼がそうでなかったら、今の現場はこれほど円滑に進んでいなかったはずです。 「安心して背中を預けられる存在」。この役割の徹底こそが、右腕なりの「合理的配慮」であり、相棒の形なのです。 「思い通りにならない他者」へ敬意を そんなメンバーや右腕と仕事をしていくことで大切になるのが、「思い通りにならない他者」への敬意です。 「思い通りにならない」という事実は、相手が自分とは異なる独立した人格（心、背景、論理）を持っているという証左でもあります。その「違い」や「ままならなさ」を否定してコントロールしようとするのではなく、そこに他者の存在を認めて敬意を払うというのは、成熟した対人関係への第一歩かもしれません。 この考え方には、いくつかの重要な側面が含まれています。 コントロールからの解放： 相手を自分の期待通りに動かそうとする気持ちを手放すことで、相手も、そして自分自身も 不必要な葛藤 から解放されます。 他者性の受容： 自分にとって都合の良い部分だけでなく、 理解できない部分や意に沿わない部分も含めて「その人である」と認める姿勢 です。 期待の適正化： 「敬意」は諦めるような冷たさではなく、 「相手には相手の正義や事情がある」と想像力を働かせる温かい距離感 を作ることにつながります。 自分の思い通りにならない時こそ、相手の「個」が最も強く現れている瞬間だと言えるのかもしれません。その「個」をありのままに尊重したその先に、私たちはようやく、彼がなぜあなたの理想に触れようとしないのか、という次の問いに向き合えるようになります。 あなたがもしそれでも「精神的な右腕」を求めてメンバーに理想の体現を求めているなら、まずメンバーが自立することが大切です。そのためには、「主語」を取り戻す手助けをする必要があります。 あなたの右腕は主語を失っているのかもしれない 手前味噌ですが、私の昔書いたブログを引用させてください。 「 迷った時は、主語を取り戻そう 」／MAX https://zenn.dev/enjapan/articles/bca0153009c7ef あなたのメンバーや右腕が理想を体現してくれないとき。それは彼らが 「主語＝私」を失い、「他人軸」で生きているから かもしれません。 リーダーの期待に応えたい、リーダーが言ったからやる……。こうした「他人軸」で動いている間、人は「私はどうしたいのか？」という問いを失います。主語を失った状態では、自分の選択を環境や他人のせいにしてしまい、自分のキャリアに「手応え」を感じられなくなります。そのような状態で、メンバーが同じ理想を共にすることは不可能です。 メンバーを可愛がるあまり、メンバーの役に立つために答えを与え続けていませんか？もしくは、自分の力を誇示しようとはしていないでしょうか？ 「主語を取り戻す」とは、自分の内側から問いを発し、その答える責任も、行動も、自分で引き受けることです。 メンバーがあなたの思う理想の右腕になってほしいと思うのであれば、今すぐあなたという「正解」を追うことをやめさせ、彼自身の「主語」を確立させるプロセスが必要です。 アドラー心理学が教える「水平な関係」と「課題の分離」 この「主語の奪還」を支える土台が、 アドラー心理学 です。 アドラー心理学の核心は、全ての対人関係を「垂直（上下）」ではなく 「水平（対等）」 として捉えることにあります。彼があなたを「師」として仰ぎ、あなたがそれに応えて正解を与え続ける限り、二人の関係は「垂直」なままです。垂直な関係では、メンバーは決断の責任を師に委ね、「選ばされた」という受動的な立場でい続け、結果として主語を失います。 ここで重要なのが 「課題の分離」 です。 「メンバーが私の理想を学ぶかどうか」は、メンバー自身の課題であり、あなたの課題ではありません。あなたが無理に学ばせようとすることは、相手の課題に土足で踏み込む「垂直な介入」です。 シニアの役割とは、メンバーを「未熟な部下」ではなく「一人の自立したエンジニア」として扱い、彼ら自身が自分の課題に向き合えるよう 「勇気づけ（エンカレッジメント）」 を行うことです。 あなたが偶像の椅子から降り、対等な目線で「信頼」を伝えること。それが、彼に「自分の主語で生きる責任」を自覚させる第一歩となります。 オープンクエスチョン——自分自身に責任を持つ 水平な関係を構築し、メンバーに主語を取り戻させるための具体的な「技」が、 オープンクエスチョン（開かれた質問） です。これは単なる会話術ではなく、相手に「自分自身に責任を持つこと」を教えるための大切な行動なのです。 「はい/いいえ」で答えられる質問（クローズドクエスチョン）は、あなたの正解をなぞらせるだけの「試し行為」にすぎません。 そうではなく、相手の内側から「私はこう思う」を引き出す問いを投げかけます。 「この目標で大丈夫か？（垂直な確認）」ではなく、 「この目標を実現した先に、君はどんな自分でありたい？（水平な対話）」 あえて答えを言わず、相手が自分の言葉で語り始めるまで静かに待つことも大切です。この沈黙の時間こそが、私のブログにもあるような、相手が他人軸ではなく、主語を自分の手に取り戻すための時間になります。マネージャーが責任を持って「決断を委ねる」ことで、メンバーは初めて「自分の声」を聴き直すことができるようになります。 結び：大いなる力には、大いなる責任が伴う 第1回 で、私はこう書きました。 「大いなる力には、大いなる責任が伴う」 。 あなたが積み上げてきた「心・技・体」という大いなる力。その力を、自分一人の成果や賞賛のためだけに使うのは、前回お話しした「深夜のラーメン（目先の快楽）」に負けるのと同じです。シニア、そしてマネージャーとしての真の責任とは、自分一人が高く登ることではありません。 「あなたがいなくなった後も、自分の主語で走り続けられるエンジニアを育てること」 にこそ、その本質があります。 それは、あなたという「人間」にしか作ることができない、しかしあなたが居なくなった後も組織の中で回り続ける「真の属人的な仕組み」です。これこそが、他の誰でもない「あなた」にしかできない仕事であり、創造できない価値なのです。 右腕があなたの理想を完全に理解してくれないと寂しいかもしれません。ですが、承認欲求による関係は、相手を自分の目的のための「対象」として扱っているに過ぎません。これは、あなたが頭の中に投影した理想の相手と対話しているに過ぎず、 目の前の生身の人間とは一度も目が合っていません。 目の前の相手と目が合わせられなければ、初めからそのメンバーと出会っていなかったことと同じです。 あなたがチームのトップとして必要なことは、対話を試み、相手を信じ続けることです。自分をいつか超えていく存在を生み出すためには、偶像の椅子から降りて自分の鎧を脱ぎ、対等な視座で「信頼」を伝え続けなければいけません。 あなたが育てたエンジニアが、自らの足で立ち、あなたを追い越していくその瞬間、あなたの「心」は、別の誰かの「体」となって生き続けます。彼らはあなたの心を受け継いで、外の世界から吸収し、あなたに新しい視点をもたらす特別な存在になってくれます。その時、あなたは一人のリーダーとして、もう孤独ではありません。 大いなる力を、大いなる責任へ。 技術だけでなく「心」を。より良いQAエンジニアの未来を、ここまで読んでくれたあなたと共に。 （連載完） 【連載】AI時代だからこそ「あなたにお願いしたい」と言われるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」（連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ 【第4回】深夜のラーメンがやめられない僕たちは、いかにして「シフトレフト」を実現すべきか 【最終回】思い通りにならない他者へ敬意を （最終回 全文公開中！） The post 【最終回】思い通りにならない他者へ敬意を first appeared on Sqripts .

今回は、 第5回の「営業」の回 に続き、再び「幕間」として、技術とは少し異なる、しかしQAエンジニアにとっては避けて通れないテーマについてお話しします。 そのテーマとは、「品質」です。 QAエンジニアと名乗る以上、「品質」という言葉は常に私たちの隣にあります。 私はこの言葉をなんとなく分かった気で使っていました。 そして、(今となっては幸いなことに)あるタイミングで、この言葉を明確に言語化する必要に迫られました。 その過程で出会ったのが、TQMという品質マネジメントに関わる包括的な方法論です。 私自身、TQMの専門家と呼べるほど成熟しているわけではありません。しかし、この考え方に触れたことが、私が「品質」をどう捉え、それをどう自分のキャリアの土台とするかに、決定的な影響を与えました。 今回は、このTQMという概念を通じて、私がどのように「品質」という言葉に向き合ってきたかをお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う “品質”という言葉を使うことの畏れ多さ 「品質」という言葉は開発現場でよく使われます。 一方で、「品質はなんもわからん」と口にするベテランのエンジニアや品質保証の専門家も多く見受けられます。 QAエンジニアとして「品質」という言葉を意識し始めた頃、私自身はこう思っていました。 「“品質”という言葉を軽々しく使ってしまうことは失礼に当たるし、本質を理解していないことになる」 今振り返ると、自分の虚栄心からそう思い込んでいたのかもしれません。 今でも「品質」という言葉を使う時には、多くの人が思い悩みながらも言語化を避けてきた恐ろしさ、そして先人達への畏れ多さを感じずにはいられません。 それでも、あえてその「魂」の部分に向き合い、自分なりに腹落ちさせるプロセスを経たことは、私のQAエンジニアとしてのスタンスを大きく変えるきっかけとなりました。 QAエンジニアという職能の捉え直し 現在の日本のソフトウェア開発現場において、『QAエンジニア』といえば、『テストをする人』や『テストの専門性を持っている人』を指しているのが実情です。私自身もその一人です。 しかし、TQMにおける「品質保証」という視点から捉え直すと、QAエンジニアの職能はもっと大きな範囲に広がるのではないか、と考えられるようになりました。 「顧客との間で明示的に約束しようがしまいが,徹底的に満足させてやろうとすること」 『 マネジメントシステムに魂を入れる 』p.54 TQMでの「品質保証」について学んだのはこの書籍ではないですが、私がこういった捉え方と出会ったとき、私はこの上なく自由さを感じました。私のQAとしての活動に、文字通り魂が宿ったと感じました。 そして、この目的を達成するためには、いわゆる「テスト」という活動だけでは不十分だと私は考えています。 私がSqriptsなどのプロフィールで、単なる「QAエンジニア」ではなく、あえて 「 テストに専門性を持つQAエンジニア 」 と書いているのには、実はそうした背景があります。 私はあくまで、「テストの専門性」を土台（強み）として持っているQAエンジニアに過ぎないと考えています。そう考えれば、世の中にはもっと多様な土台を持つQAエンジニアがいて良いはずだと思うのです。 プロダクトマネジメントに専門性を持つQAエンジニア SREに専門性を持つQAエンジニア カスタマーサクセスやマーケティングに専門性を持つQAエンジニア どのようなバックグラウンドであれ、「品質」という目的のためにその専門性を発揮するのであれば、それは胸を張って「QAエンジニア」と名乗ってよいのではないか。 TQMの思想に触れる中で、私はそう確信するようになりました。 品質保証を広義に捉えることの危うさ 「品質保証」をこういった広義に捉えることはある種の危うさをはらんでいます。 それは「品質保証の責務を押し付けられた」あるいは「QAが品質保証を放棄した」と捉えられることです。 現実との差分として、そういった捉え方をするのは自然なことだと思います。 だからこそ私は今まで語ってきたさまざまな専門性と接続して、建設的に、そして納得感を持ってチームに実装していく必要があると感じています。 専門性の組み合わせ 「品質」という概念を深掘りしたことによって、他の専門性との結びつきもより強固になりました。 スクラムマスター（アジャイル）との組み合わせ 「品質」という言葉の本質を捉えようとすると、「アジャイル」という概念がより鮮明に理解できるようになりました。 例えば「アジャイルソフトウェア開発宣言」で語られている価値観は、驚くほどTQMの思想と合致しています。 品質を単なる「仕様通りであるか（品質特性）」だけで理解するのではなく、「顧客にとっての価値」や「提供側としての在り方」という本質的なところから考えることなどです。 スクラムやアジャイルの実践は、単なるフレームワークの導入ではなく、「本質的な価値提供のために、我々はどう行動すべきか」という問いをより強固なものとします。品質への深い理解は、アジャイルなチームビルディングを行う上での強力な土台になると考えるのです。 テストマネジメントと品質マネジメント かつての私は、「テストマネジメント」と「品質マネジメント」をほぼ同一のものとして捉えていました。しかし今は、これらを明確に区別して考えています。 品質マネジメントという全体の中に、テストマネジメントが位置づけられる。 この視点を持つと、テストの役割がより柔軟に見えてきます。 品質を作り込むために、テストはどうあるべきか。 そう考えると、典型的には「シフトレフト」の必要性にまず気付けると思います。 あるいは、「シフトライト」や「運用でカバーする」という判断、さらには「オブザーバビリティ」を高めることや、マーケティングの視点からのフィードバックが必要になるかもしれません。 「テスト」という枠組みを超えて、様々なステークホルダーと「品質」を共通言語に会話ができるようになる。これが、品質マネジメントの視点を持つ最大のメリットだと感じています。 実務において、「品質」を脇に置くことも考える 正直なところ、実務の現場において、「品質とは何か？」といった哲学的な議論を頻繁に持ち出すべきではないと私は考えています。 定義論争は時に不毛なものになりえます。 特にQAエンジニアの実務において、個人の胸の内に留めておくということもチームを健全に前に進めるためには必要になるでしょう。 私自身、哲学的な議論が大好きです。 一方で 「私たちはどういった世界を実現したいのか」、 「そのために、お客様やステークホルダーにどういう状態になってほしいのか」、 そういったことを建設的に議論するほうが、プロジェクト、あるいは世界は前に進むことも多いでしょう。 大切なことは「顧客満足のために在りたいスタンスを取り続けられること」だと思っています。 そしてその議論の中で使われる言葉は、必ずしも「品質」という言葉でなくても構わないと思っています。 「品質」という言葉を使ってしまうと、今まで「品質」という言葉をつかってこなかったチームにとってマウントを取られた気分になりえます。 実際に私は「QAエンジニアとして品質について理解している」そういった気持ちでいたことがあります。 そんな時に、別の言葉で表現したり、脇に置いて前向きに対話していくことで、私は「いきいきとした」チームになっていく姿をたくさん見てきました。 そして、それこそが品質を扱う私の働き方の醍醐味だと思うようになったのです。 それでも品質を言語化すること 最後まで読んでいただきありがとうございます。 本稿を読まれた皆様は、「QAエンジニア」を名乗っている、あるいは目指しているのではないでしょうか。 皆さんのアイデンティティの核である「品質」、あるいは「品質保証」について、一度じっくりと考え、自分なりの言葉で向き合ってみてはいかがでしょうか。 ここであえて、私なりに品質について一言で表しましょう。「誰かがハッピーになること」です。 「品質」。 畏れ多い言葉です。 しかし、そこから逃げずに自分なりの答えを持てた時、それは「自分はなぜここにいるのか」「自分の専門性はどこで活かせるのか」という、QAエンジニアとしての揺るぎない土台になると、私は信じています。 参考文献 書籍『マネジメントシステムに魂を入れる』 ／飯塚悦功（著）、公益財団法人日本適合性認定協会（編集）日科技連出版社、2023年 やまずん、QAとしての自分の考えを表明するためのポジションペーパー https://55ymzn.com/me/positioning_paper_of_qa/ 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う The post 【第8回】幕間：「品質」という言葉に向き合う first appeared on Sqripts .

QAエンジニアの採用・選考　どう採るどう通る？連載の第4回です。 前回の記事 では、求職者の立場から職務経歴書や面接で「採用したい」と思わせるアピール方法について解説しました。第2回・第3回は求職者側の視点での話でしたが、今回からは募集側が意識すべき、QAエンジニアの採用を成功させるためのポイントをお伝えしていきます。 QAエンジニアの募集を出しているけれどなかなか応募が来ない 応募はあるけれど、求めている人材とマッチしない といった悩みを持つ企業やエンジニア採用担当の方のお話を伺うことがあります。 市場におけるQAエンジニアの母数は開発者等に比べて少ないですし、かつ 第1回 でも触れたように、ハイレベルな人材が求められがちなので、結果として採用に苦労している企業が多い状況です。 本記事では、そのような状況の中で求めるQAエンジニアを採用するために必要な「QAに対する理解」を中心に説明します。 記事一覧：QAエンジニアの採用・選考［どう採る　どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える よくある「もったいない」パターン 私は過去に事業会社でQAエンジニアの採用を担当し、書類選考や面接を行ってきました。また、個人活動としてQA採用に悩む企業の方から相談を受けることも多くあります。その中で、「この書き方ではなかなか応募が来なさそうだな・・・」と感じる、もったいない募集のパターンがいくつかありました。 たとえば以下のようなものです。 業務内容が「テスト業務をお任せします」だけで具体性がない 必須要件が「品質評価業務の経験＊年」などふわっとしている プロセス改善や品質向上への取り組みに言及がない 「単純作業」「コツコツ作業できる人向け」などの表現が使われている 開発との協調や上流工程への関与について触れられていない 給与が開発職に比べて極端に低く設定されている テスト、評価、検証などの用語が混在している 類似のものや相互に関連するものも含まれますが、これらに共通しているのは QA業務や品質への理解が浅い ということです。 理解が浅いままだと、QAエンジニアからは「この会社はQAのことをわかっていないな」や「リスペクトが無いな」などと判断されてしまいます。理解やリスペクトのない状況に敢えて飛び込んでいくエンジニアは、あまり多くはないでしょう。（飛び抜けて待遇が良い、などであれば別かもしれませんが・・・） QAについて理解すべきこと では、QAを理解するとは具体的にどういうことでしょうか。大まかに3つのポイントがあります。 QAエンジニアの業務の幅広さ まず押さえておきたいのは、QAエンジニアの業務はテスト実行だけではない、という点です。 テストを実行するのはもちろん、テスト設計や、組織・チームにおけるテストや品質保証の方針を策定することや、テスト・QAプロセス改善、テスト自動化の推進、開発者へのテスト技術の移転、不具合分析等を通じた品質の可視化や改善アクションなどなど、QAエンジニアが担う可能性のある業務は多岐にわたります。QAエンジニアはその中で得意領域を持って開発組織に貢献したり、できること・領域自体を広げるための努力をしたりしています。 QAエンジニアは「開発の後工程でテストをする人」ではありません。 第2回 で触れた”自走できる人”というキーワードも、こうした幅広い業務を自律的にこなせる人材を指しています。プロダクトのQA活動を一貫して担い、必要であれば仕事を自分で作っていく。そのような役割を期待している企業が多いですし、多くのやる気のあるQAエンジニアはそのような期待に応えようとしているはずです。 にもかかわらず「QAってテストする人でしょ？」という理解で募集をしてしまっていては、QAエンジニア側とのギャップが大きく、採用はうまく進まないと思います。 品質文化とQAの位置づけ 続いて理解しておきたいのは、品質文化とQAの位置づけです。 QAエンジニアが重視しているものの一つに、「品質は全員で作るもの」という考え方が組織に根付いているかどうかがあります。品質はQAエンジニアだけが考えるものではなく、開発チーム全体で作り込むものだという理解が前提にあるのです。 そのため、既にQAチームが存在する場合は開発とQAが対立していない環境、一緒に良いプロダクトを作る仲間として協働している環境を求めたいところです。いわゆる「上流から関われる」「開発チームとの距離が近いor開発チームの中で働いている」といった、開発プロセスに何か意見を反映できる、品質向上のための活動が尊重されるような環境かどうかを気にする人が多いでしょう。 1人目QAを募集する場合は既存のQAチームが無い状態なので、「品質文化がありますよ」「ウチは上流から関わっていますよ」といったアピールはできません。が、QAチームの体制が整った暁にはそういった協働状態を目指したいと思っているんだ、という一つの理想像として提示すると良いと思います。 QAにとってのスタンダードな考え方を理解する もう一つ理解しておきたいのは、QA業界におけるスタンダードな考え方です。 たとえばシフトレフトやシフトレフトテストという考え方があります。開発プロセスの早い段階から品質を考えたりテスト活動を行うというアプローチで、以前はちょっとした流行り、最近よく聞くようになった言葉、といった位置づけだったように思います。しかし、今ではスタンダードな考え方として浸透しているのではないでしょうか。スタンダードとして浸透している、ということはつまり QAエンジニアの多くはその考え方を知っている・聞いたことがある状態であり （個別の賛否はあるものの）概ね皆が賛同している、取り入れたほうがいいと思っている ということです。 テスト自動化などもそうですし、上で述べたような「QAエンジニアの業務・やれることは幅広い」や「品質はQAだけでなく皆で作るものである」なども、スタンダードな考え方と言っていいでしょう。 これらのスタンダードな考え方を知っておくことは、募集文面を書くうえでも重要です。私自身、QAの求人票を見たときに、「この会社はQA界隈の考え方などを理解しているかな」と無意識に見ています。募集側が求職者の職務経歴書を見たときに「github（正しい表記はGitHub）」のような細かいミスが多かったり、自社の事業について的はずれな理解をしていては「大丈夫か？」と思ってしまいますよね。求職者から募集側を見たときにも同じです。 逆に言えば、こうしたスタンダードな考え方が反映された募集文面は、それだけで「QAのことをわかっている会社だな」という印象を与えることができます。 理解を深めるための具体的アクション ここまで、QAについて何を理解すればいいのかを整理してきました。しかし「理解しましょう！」だけでは実際に何をすればいいのかわかりません。ここからは、理解を深めるための具体的なアクションについて説明します。これらのアクションは主に1人目のQAを採用する際の活動が中心ですが、もちろん2人目以降の組織拡大フェーズにおいても適用できる方法だと考えています。 他社求人を参考に、自社のニーズを言語化する まず取り組みやすいのが、他社の求人を参考にすることです。ビズリーチやFindyなどのメジャーな媒体でQAエンジニアの求人を検索すると、さまざまな企業の募集文面を確認できます。 ここで重要なのは、他社の求人を「真似る」のが目的ではないということです。他社の求人を見ることで、QAエンジニアに期待したいことや、開発プロセスをどうしていきたいのかを適切に言語化することが本来の目的です。他社の求人はそのための「ヒント」として活用するものだと考えてください。 具体的には、業務内容の書き方や使われている表現、必須要件と歓迎要件の内容とバランスなどを参考にしながら、「自社の場合はどうか？」と置き換えて考えましょう。もちろん、他社が必須や歓迎としている要素すべてが自社に必要とは限りません。プロダクトがtoBなのかtoCなのか、モバイルアプリなのか基幹システムなのか、などプロダクトやドメインの性質によって要件は変わってきます。 似た業種や規模の会社の求人を参考にし、不要な要素は除きつつ、「考えていなかったけど、確かにこういう要素もほしいな」などの気づきがあれば取り入れる。このプロセスを通じて、「QAに何を期待しているのか」「開発プロセスをどうしたいのか」が少しずつ言語化されていきます。 実際に私がお話した、QA採用に成功した企業の方も、まずは他社の求人を研究することから始めたとおっしゃっていました。そのプロセスを通じて自社のニーズが明確になり、それが募集文面に反映されたとのことです。 QAコミュニティに触れる JaSSTやQA系のミートアップイベントなど、QAエンジニアが集まるイベントやコミュニティに参加してみることもおすすめです。QAエンジニアが何を話しているか、どんなトピックに関心を持っているかを直接知ることができます。 ただし注意点として、採用目的を前面に出した参加は避けましょう。私がお話した、QA採用に取り組んでいる方の中にも、「宣伝目的でコミュニティに参加すると、かえってQAエンジニアの間で心象を悪くしてしまうのでは」と懸念されている方がいました。これは非常にまっとうな考え方だと思います。 コミュニティへの参加はあくまでも「QA界隈の文化や考え方を学びに行く」ことや「自分たちの開発や品質保証のプロセスをよくするヒントを得にいく」ことをメインとして、結果としてつながりができたら嬉しい、というスタンスを大切にしましょう。こうした姿勢で参加することで、QAエンジニアとの自然な交流が生まれ、場合によってはカジュアル面談などにつながることもあるかもしれません。 一般にカジュアル面談では、自社に興味を持ってくれているエンジニアに対して自社のビジネスや課題感、採用にあたって期待することなどを話すと思います。しかし、採用がなかなかうまくいっていない、どうやっていけばいいかわからない、という場合は 現役のQAという立場で募集内容に対するフィードバックをくれませんか？ と素直にお伝えして、そのような意図のカジュアル面談を申し込むのも一つの手です。 自社がリーチしたい層に響く内容になっているかどうか、応募したくなるかどうか、現役のQAエンジニアの生の声を聞くことが最も確実な確認方法だと考えています。 なお、最近は複数社が合同でミートアップ形式のイベントを開催するケースも増えています。こうした場を活用して認知を広げることも一つの手ですが、そちらについては次回詳しく触れます。 社内におけるQAへの理解と、QA側の思いとのギャップを埋める QAコミュニティに触れて学んだことと、社内での理解との間には、ギャップがある場合があります。たとえば、本記事中でも説明したような、QAは品質向上に関わる幅広い業務をスコープとして考えているけれども、開発者は「テストする人でしょ？」と思っている、などです。 このようなギャップを放置したまま採用を進めると、うまくいかないことが多いです。採用が難航するだけでなく、仮に採用できたとしても早期離職につながるリスクがあります。 そのため、採用活動と並行して社内における QAや品質に対する理解 を得ることも大切にしてください。開発チームリーダーやプロダクトマネージャー、CTO・VPoEなど、とくに組織の文化を醸成したり広く情報を発信できる立場にある方から、「QAエンジニアという存在に対するイメージ」や「QAエンジニアに期待すること」を広めていただくのが理想です。こうした土台が整っていると、入社したQAエンジニアが力を発揮しやすい環境が生まれます。 もちろん、開発者やマネージャーなど他のロールの方に「QAエンジニアと同等の知識を身に着けてから採用活動をしてください」ということではありません。（それが実現できるならば、QAエンジニアの必要性があまりなくなってしまいますね。） そうではなく、誤った理解を減らし、今後入社したQAエンジニアの話に耳を傾けられる姿勢を皆がもっている状態を目指しましょう、ということです。特別扱いは必要ありませんが、QAエンジニアを品質の専門家として尊重することが大切です。これが、本記事の冒頭でも用いた「リスペクト」にあたります。 副業QAに入ってもらう 最後は、現役のQAエンジニアに業務委託として入ってもらう、いわゆる「副業QA」の活用です。副業QAに文化づくりや募集文面づくりなど、採用の土台を整える活動を担ってもらうというもので、社内の品質に関する現状把握や開発プロセスの分析、募集文面の作成・レビュー、社内への品質文化の醸成、採用面接のサポートなどを依頼することが考えられます。 このアプローチが有効な理由はいくつかあります。まず、QAの専門家の視点が社内に入ることで、募集文面が「QAに刺さる」内容になります。面接での見極めもより適切になるでしょう。また、副業QAと一緒に仕事をする中で、社内のメンバーが「QAとは何か」を実際に体験できます。これが品質文化の醸成にもつながります。そして、いきなり正社員を採用するよりもリスクが低く、まず試してみることができるという点も魅力です。 とくに初めてQAエンジニアを採用しようとしている企業にとっては、こうした形でQAの専門家と関わりを持つことが、その後の正社員採用をスムーズにする近道になるのではないかと考えています。2人目以降の採用を行うにあたっても、もし既存のQAメンバーが若手中心であれば、ベテランの副業QAに入ってもらうことで刺激や学びになる部分もあります。QA採用のためには「いまいるメンバーの、同僚としての魅力」が求められる場合もあるため、その点の強化にもつながります。 副業可能なQAエンジニアとの接点としては、前述のカジュアル面談から副業の話に発展させるなどの方法があります。ほかにも、YOUTRUSTなどのサイトでは転職希望のほか副業希望の度合いもエンジニア側が設定できるので、副業を希望しているエンジニアを探すことも可能です。 まとめ 本記事では、QAエンジニアの募集でなかなか応募が来なかったり、求めている人材とマッチしなかったりする原因として、「QAへの理解不足」があることをお伝えしました。 募集文面の表現を工夫する前に、まずQAエンジニアの業務の幅広さ、品質文化とQAの位置づけ、QA業界のスタンダードな考え方を理解することが大切です。そのうえで、他社求人を参考にした自社ニーズの言語化、QAコミュニティへの参加、社内での対話、副業QAの活用といったアクションを通じて、理解を深めていきましょう。 学ぶプロセスは、単に募集文面をよくするためだけではありません。QAについて学び、社内で対話を重ねること自体が、組織の品質意識を高めることにつながります。QA採用の成功は、こうした地道な積み重ねから始まるのではないかと考えています。 次回は募集側の課題2として、QAエンジニアの中での認知を獲得するための手法についてご紹介します。 【連載】QAエンジニアの採用・選考［どう採る どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える The post 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える first appeared on Sqripts .

こんにちは、QAコンサルタントのツルリンです。 2025年11月15日(土)に実施されました、第16回 中級ソフトウェア品質技術者 資格試験に合格することができましたので、受験体験記として、試験の概要、受験に向けた私の取り組みをご紹介します。 これから中級ソフトウェア品質技術者 資格試験（以降、JCSQE中級試験）を受験する方のお役に立てれば幸いです。 これまでの経緯 2024年6月8日(土)実施の第32回 初級ソフトウェア品質技術者 資格試験に合格しました。その際、 受験体験記 を執筆しました。JCSQEやSQuBOK Guideに関する情報、受験準備・勉強方法などをまとめていますので、ご参照ください。 今回の受験は、上位資格であるJCSQE中級試験へのチャレンジになります。 関連記事 初級ソフトウェア品質技術者 資格試験(JCSQE)の受験体験記 はじめまして、QAコンサルタントのツルリンです。2024年6月8日(土)に実施されました、第32回 初級ソフトウェア品質技術者 資格試験に合格することができましたので、合格体験記として、JCSQEに関する情報と受験に向けた私の取り組みをご紹介します。これから初級ソフ... 　続きを読む　 Sqripts JCSQE中級試験の概要（ 試験要綱 ） 出題範囲：中級ソフトウェア品質技術者資格試験 シラバスVer.3.0に準拠 ※主参考書籍『ソフトウェア品質知識体系ガイド ‐SQuBOK Guide‐第3版』 試験時間：120分 出題形式：選択式25問、記述式3種類の出題形式からあわせて17問出題 記述式の出題形式は以下の通り。 穴埋め問題：文章中の用語の穴埋め 説明問題　：用語についての定義や活用方法の説明 解説問題　：あるテーマについて、その理由や留意点などの考察を記述 合格ライン：70%程度（選択式、記述式ともに） 合格率：10%前後 中級ソフトウェア品質技術者が遵守すべき倫理規定が定められており、事前に倫理規定の確認が求められています。使命、法の遵守、品位の保持、社会への貢献などについて記載されています。 JCSQE中級試験 シラバスVer.3.0の項目は、SQuBOK Guide 第3版の目次と一致しています。要求される知識レベルは、選択式は知識レベル２（知識を説明できる）〜レベル３（概念と使い方がわかる）、記述式は知識レベル３〜レベル４（詳しく理解し応用できる）となっています。 JCSQE中級試験では、初級試験に比べて、より高度な理解、実務での応用力が試され、合格するためには、記述式問題への対応力が要求されます。 受験申込み 試験料 20,900円（税込）※2025年11月時点 最初に、受験地域を選んで申込みを行います。その後、受験可否の連絡があり、期限までに受験料を振り込んで、初めて受験登録完了となります。 受験地域は、宇都宮、東京、名古屋、大阪、福岡、那覇になります。 受験準備・勉強方法 参考書籍と学習リソース JCSQEサイトの 学習方法 を参考に以下を使って勉強しました。 ソフトウェア品質知識体系ガイド － SQuBOK Guide － 第3版 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】 ソフトウェア品質保証 入門－高品質を実現する考え方とマネジメントの要点　※副参考書籍 過去の記述式問題の解説 JCSQE中級試験 記述式問題（第2回〜第15回）の一部が解説付きで公開されています。 JCSQE初級試験では、試験対策アプリ（テス友）が大変役に立ちましたが、JCSQE中級試験に対応した試験対策アプリなどは特にないようでした。 勉強方法と時間配分 【3か月前】 受験申込み後、主参考書籍のSQuBOK Guide　第3版と副参考書籍のソフトウェア品質保証 入門－高品質を実現する考え方とマネジメントの要点（フリマサイトで購入）を一通り、流し読みしました。（約4時間） 公開されているJCSQE中級試験 記述式問題の解説（第2回〜第15回）を全て確認しました。各年度に出題された問題の一部について、解答用紙のスタイル、問題、解答例、解説が記載されています。（約14時間） 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】を1回解きました。（約2時間） 【1か月前】 JCSQE中級試験 記述式問題の解説の直近5年分（第11回～第15回）の再確認を行いました。（約3時間） 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】の再確認を行いました。（約2時間） 【試験直前の1週間前～直前】 JCSQE中級試験 記述式問題の解説の直近5年分（第11回〜第15回）の再々確認を行いました。また、JCSQE初級試験受験の際に、作成していたメモ（間違った問題を復習のために整理したもの）を再確認しました。（約5時間） 【受験当日】 上記のメモを試験会場に持参し、試験開始直前まで確認しました。 試験対策・意識したポイント 選択式問題は、JCSQE初級試験の復習、記述式問題については、過去問題の確認を行ったレベルでしたので、トータルの勉強時間は、約30時間でした。 試験3か月前に、参考書籍を一通り確認した結果、以下のような方針で勉強を進めることに決めました。 選択式問題への対策： マークシート形式の試験で、概念や用語に対する知識の確認になるため、JCSQE初級試験と同様の勉強で対応可能と判断し、JCSQE初級試験　問題と解説【第3版】の復習（再確認）を行うことにしました。 記述式問題への対策： 過去の出題と解説の確認とその理解が中心になります。解答の視点や実際の解答内容は、ほぼ私自身と同じ考え方でしたので、ある程度納得できましたが、過去の記述式問題の公開範囲は、一部に留まるため、明確な出題傾向を見い出すことは難しいと感じました。 ここで、記述式問題の過去の出題と解説には、「中級ソフトウェア品質技術者資格試験の記述式問題の採点においては、唯一の正解との適合をみるのではなく、受験者の意図を読み取って採点しています」との記載があります。この記載から、出題者の意図を汲み取り、自分自身の考えをまとめて、分かり易く伝える力を試される試験と捉え、以下の対応とすることに決めました。 穴埋め問題 選択式問題と同じ対策（JCSQE初級試験　問題と解説【第3版】の再確認） 説明問題 JCSQE中級試験 記述式問題の解説の直近5年分の再確認 解説問題 同上 論述式試験における鉄則の適用 解答の観点： 解答の観点や形式が指定されている場合は、必ず、指定に沿って解答する。 出題者が何を期待しているか、どのような解答を求めているかを考えて解答する。 問題文に解答のヒントや視点が示されているので、それを読み取って解答する。 記述の仕方： 分からない問題でも、空欄にせず、部分点を貰えるように必ず解答する。 指定文字数での解答は、少なくなり過ぎないように9割程度の文字数を目標にする。 解答は、「～であること」「～であるため」などのように表現を統一する。 採点して貰い易いように、できる限り丁寧な、読みやすい字で書く。 受験当日の流れ・受験後の感想 試験会場、流れ、注意事項 試験は、大阪会場で受験しました。受験者は約40名で、若手からベテランまで幅広く、いらっしゃいました。 開始10分前から試験終了までは退室できず、退室すると失格となります。 試験問題は持ち帰ることはできません。 中級ソフトウェア品質技術者倫理規定への同意書にサインを行う必要があります。 試験終了後、配布された受験票控えに印刷されたQRコードからアンケートに回答します。（所属企業に関する情報や合格した場合、氏名掲載を希望するかなど） 実際の試験での難易度と感想 試験時間120分で、選択式25問、記述式17問（小問を含めると22問）でした。 記述式問題の解答を終えたのが、終了5分前でしたので、見直す時間はありませんでした。 選択式問題は、それほど難しい問題はなく、8割程度は正解できたという感触でしたが、記述式問題については、何とか一通り解答したというレベルであまり自信はありませんでした。 特に解説問題は、実際の業務で日常的に考えていないと的確な解答をするのは難しい内容と感じました。答えはどこかを見れば載っているという類いのものではないので、改めて、ソフトウェア品質向上に対する見識や経験、日頃の取り組み姿勢が問われる試験であると思いました。 合格発表・結果の確認方法 試験日：　2025年11月15日(土)13:30～15:30 合格発表：2026年1月22日(木)10:00頃 受験地域別に合格者受験番号がWebサイトに掲載されます。 氏名掲載希望者は、氏名が掲載されます。 第16回結果）126名中、14名合格（合格率11.1%） 認定証到着：2026年1月27日(火) 試験結果のお知らせと資格認定証が送付されてきました。 試験結果のお知らせには、採点結果が記載されていました。選択式84点、記述式82点でした。 採点結果からすると、私個人としての試験対策は正しかったのだと思われます。特に記述式問題に対しては、「論述式試験における鉄則」の適用が有効だったと思われます。 記述式の採点は、選択式の合格者（68点以上）のみ行っているとのことです。 まとめ 今回の私の受験の取り組みをまとめると以下のようになります。 選択式問題は、JCSQE初級試験の復習を行う。 記述式問題は、過去（直近5年分）の記述式問題の解説を確認する。 記述式問題は、論述式試験における鉄則を適用して、解答する。 参考情報（他の合格者の勉強法） JCSQE中級試験は、QAコンサルティングを担当する私の所属部門の重点取得資格となっており、今回、私の他に3名が合格しました。勉強法、アドバイス事項をお聞きしましたので、参考情報としてお伝えします。 Ａさん： 怪しい、うろ覚えの略語や用語があったらすぐに調べる 業務で作成する文章は、主語を略さず40文字前後で書ききる 漢字の用語は、時々実際に書いてみる なお、記述式に備えて、当日はマークシートも記述もしやすい「大人の鉛筆」2本と良く消えるMONO消しゴムを2個、持っていきました。日頃、字を書くことが少ない方は文房具にも気を配った方が良いと思われます。 Ｂさん： SQuBOK を何度も読み込み、各品質技術や知識を使いこなせるように理解する ただ、なかなか頭に残らないため、2の手段へ JCSQE 中級シラバスのPDFをExcel形式に変換して自分だけの用語集を作成し、試験直前まで苦手なところを読み返す SQuBOK （Amazon Kindle）からのコピペだけでなく、使用イメージや具体的なことが分からない場合はWebで検索して用語集へリンクを入れたり、その資料をPDFにして保存したりして見返した。 短時間で問題に答える訓練をする テス友 JCSQE初級の問題を短時間で答えられるように訓練 初級ソフトウェア品質技術者資格試験（JCSQE）問題と解説【第3版】 一通り問題を解き、解説を読破 SQuBOK そのものの記述よりも、この解説の方が役に立ったことがたくさんある JCSQE 中級の過去問の公開されている分を一通り解いて解説と出題意図を読みこんだ ただ、これは時間がなくなって一部飛ばしているところもあった Ｃさん： SQuBOKはKindleで持っていましたが、書籍版を購入し直してPDF化しました また、シラバスと公開されている過去問を全てChatgptに入れて、30日計画の学習プランを立ててもらい、基本的にはSQuBOKの章ごとに穴埋め、説明、解説の3種類の演習問題を作ってもらい演習を解いていました 意味が曖昧な用語や理解が曖昧なところは復習し、時には語呂合わせも作ってもらいながら覚えたりもしました 今後、JCSQE中級試験を受験される方の参考になれば、幸いです。 最後までお読みいただき、ありがとうございました。 The post 中級ソフトウェア品質技術者 資格試験(JCSQE中級試験)の受験体験記 first appeared on Sqripts .

QAエンジニアの採用・選考　どう採るどう通る？連載の第3回です。 前回の記事 では、求職者の立場から「どのようなQAエンジニアが求められているのか」を把握する重要性について解説しました。募集背景を理解し、「自走できる人」などの抽象的なキーワードの裏にある具体的な期待値を読み取ることが大切、という内容でした。 では、企業が求めるQA像を理解できたとして、それをどう伝えれば採用担当者や書類選考を行うエンジニアに「この人を採用したい」と思わせることができるのでしょうか。 第1回 で述べたように、私が採用担当として書類選考や面接を行っていると、「落とす理由は無いけれど、通すための理由にも欠ける」という判断になる方が一定数いました。おそらくスキルや経験があるのに、適切にアピールされていない。これが、もったいなさを感じるポイントでした。 本記事では、職務経歴書を中心に「この人を採用したい」と思わせるアピール方法について解説します。 記事一覧：QAエンジニアの採用・選考［どう採る　どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる よくある「もったいない」パターン まずは、実際に書類選考や職務経歴書のレビューを通じて、よく見かける「もったいない」パターンについてです。 職務経歴を羅列しているだけ 一番よく見かけるのは、やったことを時系列で並べているだけの職務経歴書です。 たとえば、「20XX年〜20XX年:〇〇プロジェクトでテスト実行を担当」「20XX年〜20XX年:△△システムのテストリーダーを担当」といった形で、プロジェクト名と役割を淡々と列挙しているケースです。 もちろんこれらの情報自体は悪くありません。しかし、採用担当者が知りたいのは「この人が何をできるのか」「どう貢献してくれるのか」という点です。単純な経歴の羅列だけでは、企業側のニーズとの接点が見えませんし、書類選考担当者は経歴からその方のスキルなどを想像する必要があり、それなりの「認知負荷」がかかります。それも仕事のうち、と言ってしまえばそうなのですが、応募側が少しでも書類選考通過の確率を上げようと思うならば、読み手がたまたま疲れていたとしてもスッと伝わるような書類を作ったほうが安全です。 仮に集中して読んでもらえたとしても、単純な経歴の羅列で終わっていると「経験はあるようだけど、ウチで何ができるのかがわからない」という印象になってしまいます。これでは、選考を通す理由として弱いんですね。 企業側のニーズとアピールポイントがズレている 上で述べた内容と関連しますが、募集要項に書かれている課題・やりたいことと、自分のアピール内容がズレているケースもよく見受けられます。 典型的な例として、プロセス改善や仕組み化を求めている企業に対して、「納期に遅れることなくテストを消化できました」「メンバー〇名を抱えてテスト進捗管理を行いました」とアピールしている場合などです。（このパターンは本当に多いです。） もちろんウソを書いたり必要以上に盛ったりせず、正直に書いてくださっているのはわかります。しかし、企業が求めているのが品質保証体制の構築や仕組み化であるにもかかわらず、「テスト業務を着実にこなせます」というアピールでは、「業務をこなすだけの人」に見えてしまいます。 重要なのは、相手の求めるものを理解し、自分の経験を適切に翻訳することです。たとえば進捗管理の経験があるなら、企業が仕組み化を求めているのであれば、「効率化のための仕組み作り」という文脈で語る必要があるでしょう。前回の記事でお伝えした、求められるQAエンジニア像を理解するというのは、ニーズに対して適切なアピールをする土台になる部分です。 「貢献」の視点が欠けている もう一つよく見かけるのは、「こんな経験があります」「こんなスキルを持っています」と書いて終わっているパターンです。 これは、私が職務経歴書レビューをしている際には必ずお伝えしているのですが、できることや経験で止まっているとやはり物足りないんですよね。採用側が知りたいのは「雇うとどんなメリットがあるのか」という点です。つまり、「貢献」の視点が必要になります。応募先の課題に対して、自分がどう解決できるのか。これを明確に示さなければ、採用担当者は「この人を通す理由」を見つけられません。 正しいアピールの構造:「課題→貢献→根拠」のロジック ここまで、よくある「もったいない」パターンについて解説してきました。では、どうすれば採用担当者に「この人を採用したい」と思わせることができるのでしょうか。 アピールの基本構造 前回の記事で、求職者側が職務経歴書や面接で伝えるべきポイントについて構造化した図を示しました。改めてこの図を見てみましょう。 多くの人は下段(経歴・スキル)だけを書いて終わっています。先ほど述べた「職務経歴を羅列しているだけ」というパターンですね。 しかし、重要なのは中段(雇う側のメリット・貢献)を起点に構成することです。企業の課題を理解し、「私を雇うとこう変わります」と明確に示す。そして、その根拠として職務経歴や成果を提示する。このロジックで組み立てることが大切です。 なぜこの順序が重要なのか なぜこの「課題→貢献→根拠」という順序が重要なのでしょうか。それは、採用担当者の視点で考えるとわかります。 採用担当者は、候補者を次のステップに進める際、「なぜこの人を通過させるのか」を説明できなければいけません。これは社内でより上位の選考官に共有するためという側面もありますし、「迷ったら不合格」が採用のセオリーとも言われています。 つまり、採用担当者は「この人を通す理由」を探しています。正直、直感で「良さそう！」と思ってから、あとからその理屈を探すというパターンもあると思います。 だからこそ、採用担当者の中で「この人を採用したら、こんな動きをしてもらって、結果こう良くなりそう」という明確なイメージが持てると、内定にかなり近づきます。経歴・スキルはあくまでもその根拠であって、過去の成果を転職した先でも再現できるだろうと思ってもらう材料です。 自分の経験を「翻訳」する ここまでの内容を踏まえて求職者側ができるのは、見せ方や表現を工夫することです。転職活動中にスキルが急に伸びるということはあまりないので、自分の持っているものをどう表現すれば興味を持ってもらえるか、を考えます。 たとえば、テストチームにおいてメンバーの進捗管理をしながらプロジェクトを進めた経験があるとします。ある程度の規模のテストエンジニアを率いてテストを行うようなチーム・会社に応募しているのであれば、「＊人規模のリーダーを行いました」といった切り口で表現すると合うでしょう。 一方で、「ウチは開発者もテストをするし、QAの方にはもっと全体の仕組み化とかプロセス改善とかをお願いしたいんだよね」と思っている会社に対して「＊人を率いてテストのプロジェクトを回しました！」と言っても、刺さらないわけです。そうではなく、「ジュニアなメンバーもいる中で、仕組み化して業務品質を担保した」や「要件や仕様の段階からPdM・開発者との定例に参加しテスタビリティに関するフィードバックをしつつテストプロセスを進めていました」等の表現をしたほうがマッチします。 このように、自分の経験を応募先のニーズに合わせて「翻訳」することが、効果的なアピールにつながります。 自己PRへの「貢献の視点」の盛り込み方 先に「貢献の視点が大事」とお伝えしました。具体的には、どのような書き方で貢献の視点を表現すればよいのでしょうか。 たとえば、「誰とでもスムーズに仕事ができるコミュニケーション能力があります」といった内容を自己PRに書く人がけっこういらっしゃいます。しかし、コミュニケーション能力があるのはある意味当然・当たり前で、そこで止まっていると自己PRにはなりません。コミュニケーション能力自体が計測ができないものですし、「コミュニケーション能力が高いと、それがウチでどう活きるの？」と採用側は思うわけです。 もしも「バイト先の全国接客コンテストで優勝しました」等の、採用担当者が聞いてもすごさがわかるような具体的なエピソードがあれば、コミュニケーション能力が高いというアピールが成立しますし、面接のネタにもなるでしょう。しかし、多くの人はそうではないはず。そうなると、やはり「コミュニケーション能力があります」のようなふわっとした表現は、自己PRとは言い難いです。 では、どう書けばいいのでしょうか。 たとえば「QAやテストの教育・研修をたくさん経験してのべ○○○人に教えてきたので、自分なりのノウハウがたまっています。もし入社したら、新たに社内向けのコンテンツを書き起こして、研修を開いて組織内に展開できます」などは、自分を雇うことで会社が得られるメリットが表現されています。もちろん、それを嬉しいと感じるかどうかは会社やそのときの状況次第なので、そこは募集要項などからできるだけ正確に読み取る必要がありますが、すくなくとも貢献の視点は含まれています。 あるいは、一人目QA募集のような求人であれば、以下のようなアピールも効果的です。 「登壇やブログ執筆などで社外に向けたアピールができます。だから自分を採用すると、二人目以降の採用にも貢献でき、QA組織体制の構築が可能です」 このように、自分のスキルや経験を「企業にとってのメリット」に変換して示すことが、効果的な自己PRにつながります。応募先の課題を理解し、その課題に対して自分がどう貢献できるのかを具体的に書く。これが自己PRで意識すべき最も重要なポイントです。 まとめ 本記事では、職務経歴書を中心に、採用担当者に「この人を採用したい」と思わせるアピール方法について解説しました。 よくある「もったいない」パターンとして、経歴の羅列だけになっている、応募先のニーズとアピールポイントがズレている、「貢献」の視点が欠けている、という3点を挙げました。 正しいアピールの構造は、「課題→貢献→根拠」のロジックです。企業の課題を理解し、自分がどう貢献できるかを明確に示し、その根拠として職務経歴や成果を提示する。この流れを意識することで、書類選考を通る可能性は確実に高まると考えています。 次回は募集側の課題として、企業がどのように「求めるQA像」を表現するかについて解説していきます。 【連載】QAエンジニアの採用・選考［どう採る どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる The post 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる first appeared on Sqripts .

技術を土台にして自分なりのQAエンジニアを目指す本連載の第7話のテーマは 「スクラムマスター」の専門性 です。 これまでの連載では、テスト設計、テストマネジメント、テスト自動化といった、テストエンジニアの職能に直結するいわゆる「王道」の技術についてお話ししてきました。 しかし今回は、少し視点を変えて、チーミングの領域、特に私が学び・実践してきたスクラムについて深掘りしたいと思います。 皆さんは、アジャイルやスクラムに対してどのようなイメージをお持ちでしょうか？ 私がスクラムという概念に初めて触れたのは、市谷聡啓さんの著書『チーム・ジャーニー』がきっかけでした。本の中では、バラバラだったチームが対話を重ね、困難を乗り越えていく姿が描かれています。 ■ チーム・ジャーニー 　 市谷 聡啓 著／翔泳社 「アジャイルとは、チームを輝かせる手法なんだ」「あらゆる問題が起こりながらも、チームで向き合う現場で働きたい」。 ひと昔前には「キラキラQA」という言葉が使われたこともありました。私自身、そうなりたいと強く願ったことを覚えています。 しかし、実際に現場でスクラムをやってみると、現実もまた簡単ではありませんでした。 本を読んでトラブルを追体験することと、現場の当事者としてトラブルの泥を被ること。その間には、大きな差があったからです。 そして、「QA」あるいは「テスト」という専門性をその環境で発揮するためには、「スクラム」というフレームワークやその背景にある「アジャイル」を謙虚に学び続ける姿勢が必要だと考えました。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして スクラムマスターの専門性 本来、スクラムマスターは「チームの成果」に責任を持つ重大な役割です。  私はQAエンジニアであり、スクラムマスターそのものではありません。しかし、彼らが持つ「チームを支援し、障害を取り除く」という視点やスキルは、私たちQAにとっても学ぶべき重要な「ふるまい」だと考えています。 本記事ではスクラムマスターのふるまい、あるいは専門性を以下のように捉えます。 アジャイルソフトウェア開発が実現したい”状態”を理解し、その実現のためにチームの一員としての具体的な支援が可能であること もちろん、実際のスクラムマスターの責務は、障害物の排除やチームの集中支援など多岐にわたり、本記事の内容だけでは収まりきりません。ここで語る専門性だけで「スクラムマスターになれる」わけではないことは、あらかじめお伝えしておきます。 アジャイルにおける「テストを分業する」ということ “QAエンジニア”が存在し、かつそのチームが”アジャイル”を標榜しているとき、「プログラマーが作る人」「QAはテストする人」という明確な境界線が引かれてしまうケースは少なくありません。もしかしたらプログラマーだけが「開発者」と呼ばれているかもしれません。  しかし、アジャイルの価値観において、この分業は時に過度であり、「毒」にさえなり得ると考えます。 「それは私の仕事ではない」「仕様は誰かが決めているはず」。 こういった考えが蔓延すると、アジャイルチームであるはずが、いつの間にか「プロセスやツール」を「個人との対話」よりも優先するようになってしまいます。 QAがアジャイルを形骸化させる こういった現象が起こる背景には、導入の動機が関係しているのではないでしょうか。 つまり、「顧客満足」や「自己組織化」といったアジャイルの価値観への共感ではなく、「”ウォーターフォール”が嫌だから」という消極的な選択の結果であるケースです。(そして、多くの場合、”ウォーターフォール”への理解すら十分でないことも多いでしょう) スクラムは、シンプルかつ軽量で、無料で公開されている、気軽に適用できるフレームワークです。 スクラムを適用したその結果、例外なく多くの問題に直面すると思います。しかし、それはチームが真剣に向き合っているからこそ起きる、避けては通れない壁なのだと思います。 問題に直面したとき、そこから学習し、適応しようとする姿勢を失ってしまうと、いわゆる“なんちゃってスクラム”に陥ってしまいます。（私はこの言葉があまり好きではありませんが、状況をよく表していると思います） 集中力を欠いたデイリースクラムや、心理的安全性を履き違えたレトロスペクティブ。 これらは典型的なアンチパターンですが、見方を変えれば、スクラムを実践しようとした結果として表出した課題であり、ある程度の成熟度があるからこそ見える問題だとも言えます。 恐ろしいのは、形骸化したアジャイルチームに加えてQAエンジニアという専門職がいることで、「品質はQAの仕事だよね」という分業が加速し、“開発者“の品質への責任感が薄れてしまうことです。 そのようなチームでは、誰もが品質を気にかけたいと願っているのに、構造的に「誰も品質に責任を持てない」。そんなもどかしい状況に陥ることが少なくありません。 これに対して私はどうしようもない停滞を感じてしまう時があります。 「動くソフトウェア」を共通言語に、開発プロセスを再構築する 構造的に品質に責任を持てない、そんな停滞した空気の中で、現状を変えるきっかけを作れるのが、私たちQAエンジニアだと考えています。 なぜなら、私たちには「動くソフトウェア」という共通言語があるからです。 「QAエンジニアはテストを考えて、バグを見つけることに責任を持つ」という考えはアジャイルにとって悪い方向に作用しうると考えます。テスト技術の真価は、バグを見つけることだけではありません。プロダクトの現状をありのままに映し出す「透明性」を確保することにあります。 むしろ、「動くソフトウェア」から得られた事実を根拠に、スクラムのフレームワークを利用して、チームの動き方にフィードバックを返し、適応のきっかけを作ることこそが重要です。 ここで、テストをしていて、仕様や価値に対する理解の齟齬を起因とするバグを起票するケースを考えてみます。 私は、起票だけで終わりにしてしまうのは、とてももったいないと感じます。  「テスト実行の段階でこのような問題が出るのは、バックログリファインメントやスプリントプランニングに何か問題があるのではないでしょうか？ 次回のスプリントでは、実装前に具体例を使って認識合わせする時間を設けませんか？」 借りてきたベストプラクティスをそのまま当てはめるのではなく、目の前の「動くソフトウェア」という事実を通して、チームで向き合う。これはスクラムチームにとって、最も健全な活動だと私は考えます。 テストから得られたフィードバック(透明性)を起点にして、形骸化していたスクラムイベント（リファインメントやふりかえり）を通じ、本来の意味（検査と適応）を吹き込んでいく。 これこそが、スクラムマスターという役職を持たずとも発揮できる、QAエンジニアならではの貢献ではないかと思っています。 専門性の組み合わせ では、具体的に過去に取り上げた専門性とスクラムの専門性をどう組み合わせられるのか。2つの事例を紹介します。 1. テスト設計 先述した「『動くソフトウェア』を共通言語に、プロセスを再構築する」アプローチは、アジャイルにおけるテストエンジニアの典型的な貢献の一つです。これはSpecification by Example、実例マッピング、ATDDなどのプラクティスとして活用されています。 特に、仕様検討段階においてテストの経験知からフィードバックを行うことは、典型的な「シフトレフト」の実践と言えます。 たまに「テスト観点リストがあるからテスターは不要」という主張を目にしますが、それにはあまり賛同できません。 テストエンジニアの真骨頂は、一見関係のない「ソフトウェアの特性」と「テストの観点」を結びつけ、そこから重要なリスクや欠陥の可能性を見出す洞察力にこそあると考えるからです。 自分では気づかないかもしれませんが、ぜひスクラムイベント等でご自身の懸念や疑問を声に出し、対話してみてください。きっとそれはチームにとって気づきとなります。 2. テストプロセス改善 「テストプロセス改善」はアジャイルとミスマッチだ、と感じる方は少なくありません。 私も既存のテストプロセス改善モデルを単純適用することはかえってアジャイルの価値観を損なうと考えています。 一方で、「既存の知識体系の枠組みから状況に合わせてテーラリングする」という技術はアジャイルでも有効です。アジャイルチームでは「経験主義」が重視されるあまり、既存の有用なテスト技法などが、「今の私たちには重すぎる」と敬遠されてしまうことがあります。 そんな時、既存のテストプラクティスを、チームの文脈に合わせて「対話可能（議論のテーブルに乗せられる）」な状態に翻訳して提示すること。これもまた、テストの専門性を持つ人間がチームに提供できる価値の一つです。 ここで「アジャイルソフトウェア開発宣言」をご紹介させてください。 アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発宣言でも、「プロセスやツールよりも個人の対話を」と述べられています。 「対話」そのものはチーム全員の責務です。 しかし、健全な対話を行うために、プロセスやツールの価値をプロとして「対話可能な状態」に整えておくこと。これこそが、テストエンジニアが果たすべき責務だと考えています。 おわりに 今回の記事では、スクラムマスターの専門性をQAエンジニアが取り入れることについてお話ししました。 記事の中で触れた「テスト設計」や「テストプロセス改善」との組み合わせ、そしてQAがチーム開発に関与していく姿勢をさらに学びたい方はぜひ「アジャイルテスティング」という分野に触れてみてはいかがでしょう。 品質・テストの観点からアジャイルについて論じた本は様々あります。 しかし、初学者の方が学ぶ際には、あえて「テスト」を標榜していない書籍から学習することをおすすめします。  その方が、QAエンジニアとしての関心と、アジャイルの関心がどこで重なるのか、自分自身で「気づき」を得やすいからです。 冒頭で述べた通り、私は「アジャイルとはチームを輝かせる手法だ」と強い憧れを抱きました。 実は、その憧れを今も捨ててはいません。しかし、今と昔とでは違う部分があります。 それは「チームの一員として問題に向き合い、チームをいきいきとさせる」ことを、はっきりと、自分ごととして捉えたことです。 私はかつて、「キラキラQA」という言葉に憧れたことがあります。しかし今、こう捉え直しています。 「開発（チーム）をキラキラさせる触媒になることができるQAエンジニア」だと。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして The post 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして first appeared on Sqripts .

「深夜に食べるラーメンは、体に悪い」 そんなことは、誰だって知っています。太るし、血圧は上がるし、翌朝の胃もたれも酷い。健康診断の結果を見てからやっと「次こそは……」と思うことでしょう。 でも、仕事が遅くに終わった帰り道、煌々と光る看板を見ると、つい足が向いてしまう。……美味しい。実はこれ、ソフトウェア開発における「シフトレフト」や「技術的負債の返済」が進まないことと大体同じような心理的状況だったりします。 連載第4回となる今回は、さらに踏み込んだ、シニアやスタッフ、プリンシパルといったICキャリアのQAへ進みたいQAエンジニアの皆様に向けてお話ししたいと思います。QAエンジニアとして品質について深く向き合ってきたあなたは、テストだけではなく様々な領域において幅広く活躍してきたステージだと思います。 「テストを前倒し（シフトレフト）した方が、後でバグを直すよりコストが低い」 「今、負債を返却しておかないと、将来の開発速度が落ちる」 論理的には100%正しい。誰もが同意する正論です。でも、目の前のリリース期限や、山積みのタスクを前にすると、私たちはつい美味しい方に手を伸ばしてしまうもので、それは決して間違いではありません。この「わかっちゃいるけど、できない」というジレンマを突破するために必要なのは、論理的な正論ではなく、実は 「情緒的な関わり」 である場合があるのです。 私も現在の会社ではチームリーダーとしてメンバーをマネジメントをしながら、スタッフエンジニアの仕事もしています。それまでのキャリアではいろんな品質改善の取り組みにチャレンジしてきましたが、上手くいかなかったことが8割で、上手くいった2割でなんとか成果を出してきたような気がします。打率はもっと低いかもしれません。今日はそんな経験の中で私自身や周囲から学んできた話をしたいと思います。 記事一覧：AI時代だからこそ「あなたにお願いしたい」と頼まれるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」 （連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ 【第4回】深夜のラーメンがやめられない僕たちは、いかにして「シフトレフト」を実現すべきか なぜ「正論」だけでは現場は動かないのか 私たちはプロとして、機能的な会話を得意としています。 「この設計だと、後にテストがしにくいです」 「不具合修正コストを考えれば、今自動化すべきです」 これらは事実に基づいた正しい指摘です。しかし、人は論理だけでは動きません。特に、疲弊しているチームや、プレッシャーのかかっている現場において、正論は時にただ追い込むだけになってしまうリスクがあります。 雨が降っている時に「傘を持っていけ」と言われるのは正しいアドバイスですが、すでに雨に濡れて凍えている時に欲しいのは、傘よりも先に「雨に濡れて寒かったね」という共感ではないでしょうか。そして、傘を持ち出した後にかけるべきは濡れなかったことへの事実ではなく「雨の音って何だか落ち着くね」という言葉だったりするのです。 「情緒的な関わり」という「心技体の心」の本質 私が考える「情緒的な関わり」とは、情報や事実の伝達（何が起きたか、どう解決するか）を目的とせず、 「その時どう感じたか」「心がどう動いたか」という感情や感覚を共有し合うこと です。もっと噛み砕いて言うと、 「正解や解決策を出さなくてもいい、心の交流」 です。人を動かすためには、前回私がお話した、「伝達スキル」とは正反対のスキルが必要になってくるのです。 「機能的」と「情緒的」の違い 論理的・機能的な会話との違いを対比させると、よりイメージしやすいかと思います。 特徴 機能的な会話・関わり (Functional) 情緒的な会話・関わり (Emotional) 目的 情報伝達、問題解決、タスクの完遂 共感、安心感、親密さ 焦点 「事実」や「結果」 「感情」や「プロセス」 反応 分析、アドバイス、評価 肯定、受容、相槌 例 「雨だから傘を持って行って」 「雨の音って、なんだか落ち着くね」 情緒的な関わりの正体（3つの要素） 具体的には、以下のような要素が含まれているとき、人は「情緒的な繋がり」を感じます。 共鳴 相手の言葉に対して「わかるよ」「私もそう感じる」と、チューニングを合わせる行為です。論理的な正しさよりも、「あなたがそう感じているという事実」を大切にします。 自己開示と弱さの共有 自分の完璧ではない部分、迷い、不安、あるいは喜びを素直に見せることです。そうすることで、相手も「ここでは素の自分でいいんだ」という安心感（心理的安全性）を抱きます。 「無駄」の共有 生産性や効率とは無縁の、とりとめのない話をすることです。「気遣いが嬉しかった」「なんとなく寂しかった」といった、生きていく上で必須ではないけれど、その人の「人間味」そのものである部分を分かち合う時間です。 なぜ情緒が必要なのか 人は論理だけで生きているわけではないため、機能的な関わりだけでは 「孤独」 が埋まらないからです。 シフトレフトが進まない背景には、多くの場合「不安」や「孤独」が隠れています。 「新しい手法を試して、スケジュールが遅れたらどうしよう」「品質を上げたいのは山々だけど、誰もこの苦労を分かってくれない」。 こうした感情を無視して論理だけで殴っても、ただ単に防御本能が働くだけです。「自分の感情が、そのままの形で他者に受け入れられた」という体験は、自分の存在そのものを肯定された感覚に繋がります。情緒的な関わりは孤立を防ぎ、関係に「深み」と「色彩」を与える役割を持っています。そのためには、まずはあなたが鎧を脱ぎ、目の前の人間と関係性を作ること。それが、変化への第一歩です。 ICキャリアのQAに求められる「真のスキル」 ここからが本題ですが、この 「情緒的な関わり」を使いこなすことは、シニアやスタッフ、プリンシパルといった上位職のQAエンジニアにとって、絶対に欠かせない必須スキル だと断言します。むしろ、キャリアの階段を上がれば上がるほど、これは『あったら良いもの』ではなく、 『成果を出すための必須スキル』 になっていくと思います。 なぜなら、キャリアが上がるほど、QAの仕事は「テストを回すこと」から「組織や文化を動かすこと」へとシフトしていくからです。 ① 影響力の行使（信頼残高を使う） 高度な改善（シフトレフトの定着やプロセスの改革など）は、時に痛みを伴います。その痛みをチームに受け入れてもらうには、 普段からの「情緒的な関わり積み重ね」による信頼残高 が不可欠です。「この人は自分たちの苦労を分かってくれている」「普段から私のことを気にかけてくれている」という安心感があるからこそ、厳しい提案やフィードバックも「自分たちのために言ってくれている」と受け止められます。 ② 心理的安全性の設計 技術的に鋭い指摘ができるシニアほど、周囲を萎縮させるリスクを持っています。 マネージャーの場合: メンバーが「失敗や弱音を吐いても大丈夫だ」と感じられる空気を作るのは、マネージャーの情緒的な受容力にかかっています。 シニア・プリンシパルの場合: 意識的に「弱さの共有」や「とりとめのない雑談」を差し込み、情緒的な繋がりを作っておかなければ、ただの「怖い人」「面倒な人」になり、現場の本当の悩み（＝品質リスク）は、あなたの耳に届かなくなります。 ③ 人と人の摩擦を解く（EQ：心の知能指数） プロジェクトが停滞する原因の多くは、純粋な技術的難問ではなく、部署間のメンツやステークホルダーの不安といった「感情のもつれ」です。ロジックを振り回すのではなく、相手の感情を読み取り、配慮し、情緒的に関わる。このEQ（心の知能指数）の高さこそが、複雑な問題を解決する武器になります。 ④ 孤独なリーダーシップを支える 上位職になればなるほど、答えのない決断を迫られる「孤独」な場面が増えます。その時、周囲と情緒的な関わりを持っているリーダーは、メンバーから情緒的なサポートを受け取ることができ、それが折れない心の支えになります。私の人生においては、正直ほとんどがこのメンバーからの情緒的なサポートで支えられてきました。もしかすると、実はこれが全てかもしれません。 品質に完璧な答えは出せない。だから、共に歩むスキルが必要。 正直に言って、シフトレフトや改善の推進のやり方について私自身もまだ明確な答えを持っているわけではありません。私だって、今夜もまた、「体に悪い」と知りながらラーメンを食べてしまうことでしょう。 でも、いちQAエンジニアとして、チームのみんなとは一緒に歩んでいきたいと思っています。 その中で、「情緒的な関わり」を「甘え」や「無駄」と切り捨てるリーダーは、個人の能力で突破できる範囲で頭打ちになります。それだけは人間が働く限りは変わらない事実ではないでしょうか。 「健康にならなきゃダメだよ」と指を差すのではなく、「ラーメンって美味しいよね」と隣に座る。そんな情緒的な関わりを積み重ねた先に、ようやく「じゃあ、明日は少しだけ健康的なものにしようか」という、小さな、でも確かな変化が生まれるのだと信じています。 「論理で正解を出すが、情緒で人を動かす」 そんな素敵な大人を目指して、今日も一歩ずつ進んでいきましょう。 【連載】AI時代だからこそ「あなたにお願いしたい」と言われるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」 （連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ 【第4回】深夜のラーメンがやめられない僕たちは、いかにして「シフトレフト」を実現すべきか The post 【第4回】深夜のラーメンがやめられない僕たちは、いかにして「シフトレフト」を実現すべきか first appeared on Sqripts .

QAエンジニアの採用・選考　どう採るどう通る？連載の第2回です。 第1回 では、QA・テストエンジニア採用市場において私が見聞きしてきたミスマッチ等について、そして本連載の全体的な内容についてご説明しました。 今回からは2回に分けて、とくに求職者側が気をつけるべき点について書いていきます。 本記事のタイトルにもあるように、求職者の立場からはまず「どのようなQAエンジニアが求められているのか」を把握する必要があります。私自身、事業会社でQA組織を立ち上げるために募集をかけて、応募してくださった方の書類選考や面接などを行っていました。また他社でQAエンジニアを募集している方から募集文面のアドバイスを求められる機会などもあり、世の中の開発組織がどのようなQAエンジニアを欲しているのか、の感覚を持っているつもりです。本記事ではこのあたりを中心にご説明します。 求められているQA像を把握する、とは QAエンジニアに限らず、採用ではお互いをよく知ることが大切です。「そんなのは当たり前だよ」と思うかもしれません。しかし実際に書類選考などを行っていると、その当たり前が意外とそうではないことに気が付きます。 募集側から見たときに「募集要項ちゃんと見てくれたのかな？」「これってウチじゃないよね」と感じる書類が届くことも少なくありません。 もちろんこれには色々な事情があると思うのですが、求職者側にとっても募集側にとってもメリットがあまりありません。 ミスマッチを避けて、自分が興味を持っている企業から、自分を正しく理解してもらう。そして、選考を先に進めてもらう。そのために求職者側ができるのは、相手が求めているQA像をできるだけ正しく把握することです。 まずは企業がQAを募集している背景について知ろう 企業が出している採用ページや各種媒体の説明文には、募集の背景・求める人材像・必須要件などが書かれています。まず、募集の背景＝なぜQAエンジニアを採用しようとしているのか、を押さえることが必須です。 「開発を続けてきてサービスが軌道に乗って、いよいよ一人目のQAを採用して品質にも力を入れていきたいんです」という場合もあります。また「QA組織はあるけれど、ビジネスがどんどん拡大していて開発チームやプロダクトの数に対してQAの数が追いついていないんです」というケースもあるでしょう。 企業側が抱える課題や実現したいことがあって、そのためにQAの力が必要となっている。だからQAエンジニアを採用したい。このように考えているわけです。なので、求職者側は募集背景として課題や実現したいことを把握したうえで、「私であればそれに貢献できますよ」とアピールする必要があります。 上の図は、求職者側が職務経歴書や面接で伝えるべきポイントについて構造化したものです。 先に述べた内容は図中の一番上、募集要項やカジュアル面談を通じて、課題ややりたいことを把握しましょうという部分です。 この図は次回に説明する「採用したいと思わせるには」という内容にも関連します。 背景をもとに、求められているQA像を把握する 募集の背景がわかったら、続いて募集側がどのようなQAエンジニアを求めているのかを把握しましょう。といっても、背景と求められているQA像というのはバラバラなものではなく、当然セットです。 先に挙げた例のうち、「開発を続けてきてサービスが軌道に乗って、いよいよ一人目のQAを採用して品質にも力を入れていきたいんです」パターンについて考えてみましょう。 一人目のQAの採用ということで、例えば以下のようなQA像を求めていると考えられます。 QA組織を立ち上げた経験がある 採用、評価、マネジメントができる QA組織のミッションや、開発組織の品質目標を定められる 社外向けの発信を通じてプレゼンスを向上させられる 開発者等に対して品質・テストに関する知識や技術移転を行える すべて挙げるとキリがないのでこのくらいにしておきますが、求める人材像として想像できる条件はいくつもあります。 これらの中には、募集要件の中に明示的に書かれていることもあれば、書かれていない場合もあります。書かれていない場合、条件が厳しすぎると応募が来ないので意図的に外すという選択をしているかもしれませんし、QA業務に対する解像度がまだそれほど高くないがゆえに思いついていないのかもしれません。 いずれの場合も、まずは募集要項に書かれている内容から求めるQA像を読みとること。それに加えて、書かれていないけれども募集背景から考えるとこういった要素も必要そう、という事項についても書き出せるとよいでしょう。それをカジュアル面談等で事前に確認しておくと、意図的に除いているのか思いついていなかったのかがわかりますし、場合によっては「『このひとはデキる！』」と思ってもらえるかもしれません。 世の中の会社がQAに求める要素 募集の背景や求めるQA像を把握するやり方について、イメージを持っていただけたと思います。 ここからは、実際に世の中の各社がどのようなQAを求めているのか、その全体感についてお話していきます。 同じQAを募集しているといっても、各社ビジネスの内容や規模など状況が異なるので、求めるQAには当然違いがあります。 とはいえ、とくに最近多いWebサービス関連の事業会社でQAを探していますというケースでは、求めるQA像には共通する内容があると考えています。 代表的な要素は”自走できる人” 募集要項などで頻繁に目にするのは”自走できる人”という条件ではないでしょうか。自律的に動ける人、主体的に動ける人、などもよく見かけます。よく見かけるものの、抽象的な表現ですよね。この”自走できる人”というキーワードを深堀りすることが、内定につながるひとつのポイントだと私は考えています。 QAを募集する側の考えている”自走できる”とは、具体的にはどのような要素を指しているのでしょうか。 たとえば、私が事業会社でQAエンジニアを募集している際に”自走”の意味合いとして考えていたのは、特定のプロダクトのQA業務をお任せできるレベル、です。社内で複数のプロダクトが存在する会社さんも多いと思いますが、プロダクトの数に対してQAエンジニアの数が足りていない、というケースもよく見かけます。そこで、QAエンジニアを採用して今着手できていないプロダクトもしくは開発チームに対してQA活動を行おうという意図があるわけですね。 特定のプロダクトのQA業務をお任せできる、というのも色々なパターンはあります。すでに担当がいるプロダクトのQAを引き継ぐ場合や、新規に立ち上げるプロダクトの担当を任せたい、という場合もあるでしょう。 いずれの場合も、社内にある知見・既存のプロセスだけではなく、QAエンジニア本人の経験やナレッジをうまく融合させて、そのプロダクトにおけるQAのやり方・あり方を作っていくことが求められます。これが、「自走」として求められる1つの要素だと考えています。 この要求を満たすためには、単純に「言われたことができます！」では足りません。開発者やプロダクトオーナーなど他の職種と常にコミュニケーションを取りながら、自分の仕事を自分で探したり、作ったりして進んでいくスキルが必要となります。 組織構造や体制も把握する必要がある 自走できること、が大事であるという点は納得していただけたのではないかなと思います。 加えて、実際に応募するにあたっては、応募先の事情に応じてどのような”自走”が求められているのかを考える必要があります。 代表的なものとして、募集側が想定しているQA組織の構成が挙げられます。たとえば、正社員のQAエンジニア数名と、他社からテストのプロに来てもらってプロジェクトのテスト業務を回そう、という想定をしているとします。このような会社に応募する場合は、実際にテスト会社のプロとしてリーダーをやっていた経験や、外部の専門家を率いて現場のプロジェクトを回していた経験が求められるでしょう。逆に、正社員のみでQA活動を行う状態を想定している会社の場合は、外部の専門家を率いた経験の優先度は低くなるでしょう。それよりも、プレイングマネージャーのような形で、仕組み化や効率化をしながらも自分自身も手を動かせる人、を求めているはずです。 応募先の求める人物像を把握したうえで、実際の職務経歴書や面接でどのようにアピールするかに関しては、次回詳しく解説します。 ニーズを正しく捉えてアピールにつなげよう 本記事では、募集背景やQA像の理解、そして代表的な「求められるQA像」である”自走できる人”について解説しました。 募集背景を理解し、「自走」という抽象的なキーワードの裏にある具体的な期待値を把握することが、応募において重要な第一歩です。そして、応募先の組織構造や想定している体制によって求められるスキルセットも変わってくることを認識しておきましょう。 次回では、これらの理解を踏まえて、職務経歴書や面接でどのようにアピールすれば採用担当者に「この人を採用したい」と思わせることができるのか、具体的な考え方とテクニックについて解説します。 関連記事 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 今回から新連載をスタートします。本連載では、QAエンジニアやテストエンジニアの中途採用において生じているミスマッチを解消し、求職者・募集側双方の「解像度」を高めるための具体的なニーズ、課題、対策について解説します。私は仕事・プライベート両面で（自分... 　続きを読む　 Sqripts The post 【第2回】求職者側の課題1：求められているQA像を把握する first appeared on Sqripts .

こんにちは！みなさん、テストしてますか？ 第2回の前編 では、E2Eテストの基幹部分とも言える 要素探索 の技術の変遷について扱い、 中編 では 実装 の技術の変遷について扱いました。 後編では、どのようにブラウザを介してWebアプリケーションを自動操作するのか、つまり 自動操作技術 について触れたいと思います。また、UIを自動操作して実施するテストという点から、E2Eテストには良くも悪くも様々な目的が期待されてしまっていましたが、これらはWebアプリケーション開発技術の変遷と共に徐々に変わってきました。こうした E2Eテストの目的 についても触れたいと思います。 記事一覧：モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 自動操作技術の変遷 さて、この連載では一貫してPlaywrightを使っています。PlaywrightはいわゆるE2Eテストフレームワークですが、大きく分けると「Webブラウザを自動操作するコンポーネント」と「自動テストを記述するコンポーネント」で成り立っています。 このうち、「自動操作」のほうには様々な変遷がありました。あまりに古いものは自分も良く知らない部分が多いので、おおむね2016年以降の主要なマイルストーンについて記載します。 Selenium 3 と Webdriver CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 開発者体験を重視したツールの流行 Selenium 3 と Webdriver Seleniumは、2025年現在で利用できるものの中では、もっとも歴史の長いブラウザ自動操作ライブラリです。複数のブラウザを統一されたAPIで自動操作できる、というのが強みで、たくさんのテストケースをたくさんのブラウザインスタンス上で実行するためのインフラも用意しています。 クロスブラウザの複雑性をライブラリ側で吸収するというアイディアと、ブラウザとSelenium Serverの中継ぎをするWebDriver部分は仕様を公開して各ブラウザベンダーに実装を任せるという思想そのものは良かったのですが、自動テストインフラの複雑さを招くことにもつながり、インフラの構築やメンテナンス、テスト実行時のトラブルシューティングなどの別の辛さを招いてしまうことも多かったです。 加えて、Selenium WebDriverの（少なくとも当時の）設計思想は「UI上で実際にユーザーが可能なインタラクションを模倣する」というものだったため、テストのためのモック/スタブを作りにくかったり、ネットワークスロットリングなどで特殊な環境を再現した上でのテストが難しいという弱点もありました。 また、仕組み上全てがHTTPベースのコミュニケーションになってしまう点もパフォーマンス上問題になるケースが多く、特にページロードや要素の表示待ちなどが非常に長くなるケースがありました。当時E2Eテストに「不安定」「遅い」という印象を持っていた人たちは、おそらくこれらに苦しめられたいたことでしょう。 一方で、色々と問題はありつつも、自動テストのための大統一APIを作るというビッグピクチャーに向けて今もなお前進し続けているプロジェクトであることは疑いの余地はなく、自動テストエンジニアとして生きるならぜひ動向を追い続けたいプロジェクトの一つです。 ちなみに、HTTPベースの単方向通信しか出来なかったのを改善するために、新しくWebDriver BiDiという仕様が策定されています。こちらについては後述します。 CDP（Chrome DevTools Protocol）とヘッドレスChromeを用いた自動テストの流行 ChromeがHeadlessモードをサポートしたことと、CDP（Chrome DevTools Protocol）をテストに使うことでSeleniumの弱点をカバーできると考えて、CDPをベースにしたハイレベルAPIを実装したのがPuppeteerです。当初はCDPを使っていたのですが、現在は後述するWebDriver BiDiを用いています。 Seleniumがあくまでユーザーに出来る操作のみにフォーカスしていたのに対し（参考： Selenium使いのためのPuppeteer解説｜Qiita ）、PuppeteerはCDPを用いるためネットワーク速度のスロットリングやスタブなど様々な開発者向け機能に対応しており、テストしやすさを改善していました。 一方で、Seleniumユーザーたちの多くがJavaやPythonなどでテストコードを書いていたのに対して、PuppeteerはJavaScriptのみの対応でした。これは普段UIを扱うフロントエンドエンジニアたちには自然だった一方で、JavaScriptの非同期APIに慣れ親しむ前の自動テストエンジニアたちにとってはかなり悩みのタネで、筆者も「自動テストスクリプトが順番通りに動いてくれない……おれはただテストを自動化したいだけなのに……」と毎日悪戦苦闘していたのを覚えています。 ちなみに、パフォーマンスの点について公平のために補足しておくと、Chrome/Chromiumブラウザの自動操作を担うWebDriver実装であるChromeDriverもまたCDPベースで実装されています。ですが、やはりWebDriver自体の通信がHTTP通信であることによるオーバーヘッド自体が大きかったため、速度の面でPuppeteerの方が有利でした。 また、SeleniumとPuppeteerの大きな違いとして、Selenium Gridのような大規模テストインフラを構築する機能の有無がありました。これは大量の実機テスト実行環境を束ねる目的では重要なのですが、CI/CD環境の中でChromiumをインストールしてテストを回すようなケースではそもそも不要なものでもありました。 開発者体験を重視したツールの流行 Cypress さて、Puppeteerの登場で、あくまで筆者の肌感ではあるものの、自動テスト界隈の人気は二分された印象がありました。 テストコードが書けるたくさんのテストエンジニアを中心にたくさんの自動テストを実行したい→Selenium 開発者が日常の開発サイクルの中でガンガンE2Eテストを回していきたい→Puppeteer そうすると、開発者はどうしても 開発者体験 の良さに目が行ってしまいます。例えば、ドキュメントが豊富であるとか、コードが書きやすいとか、デバッグ用のツールキットが充実しているとか、普段の開発エコシステムの中に組み込みやすいとか、そういった具合です。 そんな中で登場したのがCypressです。Cypressははフロントエンドの開発体験をウリにしたツールで、当時の開発者たちが慣れ親しんでいたjQueryのメソッドチェーンを踏襲した書きやすいAPI、フロントエンドエコシステムとの親和性、デバッグ体験の良さなど、良いところがたくさんありました。 一方で、仕組み上複数タブ・ウィンドウの切り替えが出来ないことや、クロスドメインiframeがテストできないことなどは、テスト対象のウェブサイトによっては致命的でした。ちなみに、Cypressのドキュメントは本当に徹底していて、これらのトレードオフまでつまびらかに解説されています。 Cypress docs： https://docs.cypress.io/app/references/trade-offs こうした課題はありつつも、上述した開発者体験の良さ、ならびにこうしたトレードオフまで充分に解説されたドキュメントなどは非常に開発者フレンドリーで、多くの開発者たちに親しまれていました（余談ですが、筆者はあるオンラインカンファレンスでCypressの中の人が「ドキュメントが充実しているのもCypressのいいところで、困ったことがあったらCommand+Kで一発で検索できる」と誇らしげに語っているのを見て、とても良いことだなと感心した覚えがあります）。 Playwright さて、Cypressのメジャーリリースとほぼ同時期に、本連載でも使っている Playwright がα版として産声を挙げました。自動操作の方法としてはPuppeteerが使っているCDPというものになるのですが、この方法は名前の通りChromium系のブラウザ（Chrome、Chromium、Edge）でしか使えないので、FireFoxやSafariはテスト用にビルドしたものを使っています。 個人的には非常にバランスの取れた、良い意味でいいとこ取りのツールだと捉えています。開発者体験の観点からCypressと人気を二分していましたが、その後Cypressと似た機能を取り入れることでより強力なツールになりました。 余談: Selenium4・Webdriver-BiDi 冒頭で紹介したSeleniumですが、何となくオワコンのように見えてしまいがちですが、きちんとメンテナンスされ続けており、2022年には待望の新メジャーバージョンが登場しました。本記事のPuppeteerの項目で「PuppeteerはCDPを直接触れるのでテストが楽」というようなことを書きましたが、Selenium4は待望の cdp エンドポイントが実装され、ブラウザによりますがCDPによる豊富なデバッグ機能にアクセスできるようになりました。 また、Seleniumの根幹となるWebdriver規格も進化しており、新たにWebdriver-BiDiというものが提案されています。BiDiはBiDirectional、つまり双方向の略です。SeleniumがHTTPベースの単方向通信のみのツールだったのを、Webdriver-BiDiはWebsocketベースの双方向通信のものに変えています。これにより、ページの表示待ちなどのパフォーマンスが改善しました。 Puppeteerの話の中で触れたとおり、現在PuppeteerはCDPベースからWebdriver-BiDiベースに変わっています。これがより進んでいくと、クロスブラウザテストのやりやすさはより高くなっていくはずです。 目的/役割の変遷 さて、この「E2Eテストの歴史」は、主にE2E自動テストで使われる技術の変化にスポットを当てることで、「本/記事によって書いてあることが全然違う」という状態を解きほぐすことを目的にしていました。締めくくりとして、これらの技術が何に対して使われるのかの変遷についても理解しておきましょう。 手続き的UIの時代: UIテスト = E2Eテスト JavaScriptによるインタラクティブな表現が可能になった直後のWebアプリケーションは、UIの変化をDOMツリーの操作によって行っていました。例えば、以下のサンプルは簡単なToDoアプリの実装です。ページ全体を読み込み直すことなく、ToDoアイテムの追加/削除のタイミングでデータをバックエンドサーバーに送信しています。 <div id="todoApp"> <input type="text" id="todoInput" placeholder="新しいタスク"> <button onclick="addTodo()">追加</button> <ul id="todos"></ul> </div> <script> function addTodo() { const text = $('#todoInput').val(); if (text) { // バックエンドにPOST送信 $.post('/api/todos', {text: text}, function(todo) { // 成功時にDOMに要素を追加 $('#todos').append(`<li data-id="${todo.id}">${todo.text} <button onclick="deleteTodo(${todo.id})">削除</button></li>`); $('#todoInput').val(''); }); } } function deleteTodo(id) { // バックエンドにDELETE送信 $.ajax({ url: `/api/todos/${id}`, method: 'DELETE', success: function() { // 成功時にDOM要素を削除 $(`li[data-id="${id}"]`).remove(); } }); } </script> DOMツリーを直接編集するということは、状態を再現させるためにはそこまでの手続きを再現させなければいけないということでもありました。再現させるためにはバックエンドも（データベースなども含め）完全なものを準備する必要があるため、必然的にUIテスト=E2Eテストという構図が生まれていました。 宣言的UIの時代: UIテストとE2Eテストの分離 一方、Reactに代表される宣言的UIフレームワークは、「状態を引数として受け取り、UIを返却する」関数としてUIを定義しています。同じToDoアプリをReactで書くと以下のようになります。 function TodoApp() { const [todos, setTodos] = useState([]); const [inputText, setInputText] = useState(''); const addTodo = async () => { if (inputText) { const response = await fetch('/api/todos', { method: 'POST', headers: {'Content-Type': 'application/json'}, body: JSON.stringify({text: inputText}) }); const newTodo = await response.json(); setTodos([...todos, newTodo]); setInputText(''); } }; const deleteTodo = async (id) => { await fetch(`/api/todos/${id}`, {method: 'DELETE'}); setTodos(todos.filter(todo => todo.id !== id)); }; return ( <div> <input value={inputText} onChange={e => setInputText(e.target.value)} placeholder="新しいタスク" /> <button onClick={addTodo}>追加</button> <ul> {todos.map(todo => ( <li key={todo.id}> {todo.text} <button onClick={() => deleteTodo(todo.id)}>削除</button> </li> ))} </ul> </div> ); } これにより、状態を再現させるための手続きを踏まなくても、特定の状態をテストできるようになります。 また、特徴的なのがUIをいくつかのコンポーネントのまとまりとして構成しており、各コンポーネントを分けてテストすることも可能である点です。子コンポーネントたちも親と同様に状態を受け取る関数として定義されているので、コンポーネントごとに状態を変えられるようになりました。 同時に、WebフロントエンドのビルドはバックエンドのWebアプリケーションフレームワークと別のフレームワークが担当することも増え、フロントエンドUIのみを分離してテストする傾向が増えてきました。その結果、純粋にUIの挙動だけをテストしたい場合はUIコンポーネントテストで済ませ、バックエンドとの統合における不具合の検知やCUJ（クリティカルユーザージャーニー: もっとも重要なユーザー導線）をE2Eテストで守る、という考え方が広まってきました。 まとめ この後編では、自動操作技術の変遷と、E2Eテストの目的の変遷について、流れを追う形でまとめてみました。 第2回はこれで終わりです。続く第3回では、E2Eテストが他のテストレベルとどう違うのか、どのような目的で行われるのか、どのように使い分けるべきなのか、などについて深堀りしていきたいと思います。 【連載】モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 【第2回・後編】E2Eテストの歴史 -自動操作技術と目的の変遷 The post 【第2回・後編】E2Eテストの歴史 – 自動操作技術と目的の変遷 first appeared on Sqripts .

前回 はエントリーキャリアの方に向けて、在宅勤務における「他人を思いやる力」を具体的な行動レベルで深掘りしました。 連載第3回となる今回は、対象を少し広げ、中堅（ミドルキャリア）のQAエンジニアの皆様に向けてお話ししたいと思います。テーマは、実務とエンジニアの「心（マインドセット）」を照らし合わせた、 「コミュニケーションに重点を置いたドキュメンテーション」 についてです。 記事一覧：AI時代だからこそ「あなたにお願いしたい」と頼まれるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」 （連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ AIにお任せしてコミュニケーションを放棄していませんか？ 本題に入る前に、少し今の時代背景を振り返ってみましょう。 ChatGPTをはじめとするLLM（大規模言語モデル）の登場により、私たちの文章作成のあり方は劇的に変わりました。仕様書のたたき台、コードのドキュメント、日々のメールまで、AIは驚くほど流暢なテキストを瞬時に生成してくれます。 その一方で、AIが生成した文章に対して「AIっぽいな…」「なんだか人間味がないな」と感じた経験はないでしょうか？ ここ最近では、「AIが出力しがちな語彙」というトピックが結構目に入るようになってきました。私自身も日頃から生成AIを活用していますので、「おっ、この言い回しは自分がいつも見ている回答にも使われがちだな」と思うことは多々あります。他人に向けた文章として引用する場合は、わざわざAIの回答から仰々しすぎるような記載を削除することもあります。 しかし、「AIっぽさ」の正体は単なる語彙力や表現力の問題とは限りません。もっと根本的な 「コミュニケーション」 にあると思います。AIを使いこなす時代だからこそ、エンジニアとして、一人の人間として、私たちが本当に磨くべきスキルについて考えてみませんか。 AIの文章が見抜かれる本当の理由 結論から言うと、AIが生成した文章に人間味が感じられない根本的な原因は、「誰に、何を伝え、どう行動してほしいか」という意図や目的が込められていないからです。 これは、プロンプトエンジニアリングのテクニック以前の、もっと本質的なことです。どんなに優れた技術や事実も、それを伝える「目的と意図」がなければ、相手には届きません。目的のない文章は、単なる事実の羅列、つまり一方的な「主張」で終わってしまうのです。 「主張」と「伝達」の決定的な違い コミュニケーションにおける「主張」と「伝達」の違いを、日常の「地図アプリ」の例えで考えてみましょう。 AIが書きがちな「主張」 「この地図アプリは、高解像度の地図データと高精度ルーティングエンジンを搭載しており、オフラインでも動作します」 これは単なるスペックの提示であり、事実の「主張」です。 人間が設計すべき「伝達」 「この地図アプリがあれば、初めての街への出張でも乗り換えに迷わず、約束の5分前に余裕をもって到着できます」 こちらは、「初めての街に向かうビジネスパーソン」というターゲットに、「迷わず到着し、時間に余裕が生まれる」という未来（メリット）を届けることで、インストールや有料プランへの登録といった行動を促す、明確な目的と意図を持った「伝達」になっています。 これはマーケティングの世界で言われる 「ドリルと穴」 の話と同じです。「顧客が求めているのは『4分の1インチのドリル』ではなく、それによって開けられる『4分の1インチの穴』である」という、手段（ドリル）よりも目的または価値（穴）の重要性を説く有名な格言です。 この差は、エンジニアの日常業務にも当てはまります。仕様書やドキュメントは、単なる機能の「主張」に終わっているかもしれません。読み手（他のエンジニアや企画職）が「何をすべきか」を明確に理解できる「伝達」になっているでしょうか。 QAエンジニアのドキュメンテーションでは伝達力も大事な要素 QAエンジニアが作成するドキュメント群においても同じことが言えます。これらは単なる「事実の列挙」ではありません。プロジェクトを健全な方向に導くための「意思決定支援のためのツール」であるべきです。ここで求められるのが、事実を並べるだけの「主張」を超えた、相手を動かすための「伝達力」です。 なぜQAにとって伝達力が重要なのか、3パターンの成果物からその本質を深掘りします。 1. テスト計画・QA戦略： 品質の「定義」を共有し、目線を合わせる テスト計画書やQA戦略を策定する際、単に「どの機能を、いつまでに、どうテストするか」というスケジュールや手法を羅列するだけでは不十分です。 大切なのは、 「今回私たちが守るべき品質とは何か？」という目的を言語化し、関係者に伝達させること です。 主張： 「全機能を網羅的にテストし、重大なバグがないことを確認します」 伝達： 「今回のリリースでは新機能のUX向上に注力するため、決済導線の安定性を最優先事項として定義し、そのためのエッジケース検証を重点的に実施します」 このように、守るべき価値を言語化することで、PdMや開発者と「品質に対する納得感」を共有でき、品質においてプロジェクト全体が一貫した方向性を持てるようになります。 2. テスト分析・設計：専門家としての「根拠」が信頼を作る 「なぜそのテストが必要なのか」という根拠が伝わるドキュメントは、QAエンジニアとしての専門性を示す重要な成果物になります。 「仕様書に書いてあるから」という受動的な理由ではなく、 「このリスクを排除するために、この観点でのテストが必要である」という意図 を分析結果に込めることが重要です。 設計意図が伝達されているドキュメントは、開発者にとって「この人がここまで考えてくれているなら、このテストをパスすれば安心だ」という信頼感にもつながります。この積み重ねが、QAチームの組織内におけるプレゼンス（存在感）を高めていくのです。 QAエンジニアの成果物には、コードのように「動作する・しない」という明確な成立条件がありません。だからこそ、あなたにしか考えられない「根拠や意図」こそが、成果物の価値や あなたの専門性 を決定づけるのです。 3. 不具合起票：チームを「修正」へと突き動かす 不具合報告（バグチケット）こそ、最も伝達力が試される場所です。単に「期待値と異なる挙動」を報告するだけでは、それは単なる事実の「主張」に過ぎません。 優れたQAエンジニアは、 「この事象によって、誰が、どのように困るのか（ビジネス・ユーザーへのインパクト）」 を明確に伝えます。 単なる事実： 「ボタンの反応が3秒遅れます」 伝達力のある報告： 「初回利用ユーザーがこの遅延に直面した場合、アプリがフリーズしたと誤認し、離脱率が上昇するリスクがあります」 特に修正可否の判断が難しい境界線上の不具合において、あなたの伝達力が試されます。エンジニアやPdMに対し、重篤度（Severity）や優先度（Priority）を意思決定するための「温度感」を専門家としての立場から正しく伝え、チーム全体を「これは直すべきだ」という合意形成へ導くこと。これこそが、プロダクトの品質を左右するQAの真の価値です。 誰の目から見ても明らかな不具合だけでなく、 「あなたしか気づいていない、潜在的なリスクや使い勝手の欠陥」 を見つけたとき。それを単なる主張で終わらせず、価値ある改善へと変えられるかどうかは、あなたの「伝達力」にかかっているのです。 AI時代に、私たちが本当に磨くべきスキル AIは、文章の「下書き」や「壁打ち相手」として非常に強力なツールです。しかし、AIが生成したテキストを鵜呑みにして、そのまま利用することは、「私は読み手のことを何も考えていません」と公言しているに等しい行為です。それは思考の放棄であり、コミュニケーションの放棄に他ならなくなってしまいます。 私たちの仕事は、コードやテストを書くだけで終わりません。プルリクエストのコメント、設計思想を伝えるドキュメント、チームメンバーとのチャット。そのすべてが、目的を持ったコミュニケーションです。私自身もQAエンジニアで、私のチームでもAIを用いたテスト設計が進んでいます。そこでも全く同じことが言えると思っています。 AIが私たちの知的労働の一部を代替してくれる時代だからこそ、私たち人間が磨くべきなのは、AIには（まだ）できない、この 「コミュニケーションを設計する力」 ではないでしょうか。 技術がどれだけ進化しても、その中心には常に「人」がいます。AIという相棒は強力です。この強力な相棒を手に入れた今だからこそ、コミュニケーションの基本に立ち返り、思考する価値を、再認識すべきなのかもしれません。 【連載】AI時代だからこそ「あなたにお願いしたい」と言われるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」 （連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ The post 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ first appeared on Sqripts .

技術を土台にして自分なりのQAエンジニアを目指す本連載、第6回のテーマは「テスト自動化」です。 前回の記事 をご覧いただいた方はご存じだと思いますが、私は文系大学出身で、キャリアのスタートは営業職でした。 実務で、商用のプロダクトコードを書いた経験は、今もありません。 もっと言えば、かつての私は「Pythonの環境構築」をするためだけに、1カ月以上も躊躇して手が動かなくなるような人間でした。当時の上司から「Python興味あるんだったらなんで入れないの？」「やらないってことは興味ないってことじゃん」と言われた記憶があります。 私が上司だったらそんなことは言わないですが、そう思う気持ちはすごくわかります。 当時は本当に何もわからずに、「Anaconda」がいいのか、「仮想環境」がいいのか、公式からインストールできるPythonがいいのか。 そもそもPCにPythonを入れてしまって、壊してしまうかどうかも不安でした。 そんな私が、どのようにしてテスト自動化という領域に自信を持ち、それをQAエンジニアとしての土台に変えていったのか。 今回は、ツールを動かすことの先にある「設計原則」への理解と、そこから得られた視点についてお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 本稿におけるテスト自動化 本題に入る前に、この記事で扱う「テスト自動化」について定義しておきます。 一般的にテスト自動化といえば、「ツールを使ってテスト実行を自動化すること」と捉えられがちです。 しかし、AIによるコーディングが当たり前になった現代において、私はより広い意味を定義したいと思います。 「テストという活動を構造化し、実行可能な『ソフトウェアシステム』として設計・構築・運用する技術」 テストにおいて、単にスクリプトを書くことと、システムとして構築することは似て非なるものです。 前者は時に手順の翻訳となってしまいますが、後者にはアーキテクチャが必要で、保守性への配慮も必要であり、なにより 「テストそのものへの深い理解」 が必要です。 かつてはテスト自動化スクリプトを書くだけでも立派な「テスト自動化エンジニア」でした。  しかし、2026年1月現在、AIはスクリプトを書くことはできますが、プロジェクトのコンテキストに適した「テストシステム」の青写真を人間の補助なしに、プロジェクトに最適化された形で描くことはできません。 この 「テストシステムを設計する技術」 こそが、本稿で伝えたいテスト自動化の本質です。 ツールを通して「普遍的な課題」を学ぶ 私がテスト自動化を学び始めた当初、関心は「どうやって動かすか」というHowにありました。 当初は書いたコードがすぐ壊れる辛さや、朝になったら自動テストが動いてない悲しみを味わっていたことを覚えています。そこから、Page Object ModelやCIの学習を深め、Playwrightなどのモダンなツールの設計思想に触れるにつれて、視点が変わっていきました。 自動化ツールやデザインパターンは、単なる便利な機能の寄せ集めではありません。 それらは、 テスト活動が抱える「普遍的な課題」への解決方法 そのものでした。 例えば、WebのE2Eテストでは「待機処理」が頻繁に課題になります。 これは、テスト実行環境やネットワークの「不確実性」といかに向き合うかという、Webの自動テストにおける難しいテーマです。 また、UI変更のたびにテスト修正に追われた経験や、Flakyなテストへの対応は、まさに「保守性」の課題そのものでした。 優れたツールには、こうした課題に対する一貫した問題意識や思想が込められています。 「なぜ、この機能があるのか？」「なぜ、この設計なのか？」 その背景にある思想を理解することは、単にツールの使い方を覚えるだけでなく、テストそのものに対する解像度を一気に高めてくれます。 自動化技術を学ぶことは、コーディングスキルを磨くだけでなく、こうしたテストの構造的な課題を深く理解するプロセスでもあります。 これはE2Eテストツールを通じて、自分ごととなる課題と、それをソフトウェアで解決するということをリアルに感じた瞬間でした。 「設計原則」が技術的な自信をくれた プロダクトコードを書いたことのない私が、技術的な議論に加われるようになった最大の要因は、「設計原則」を知ったことです。 自動テストを書いていくうちに、「動けばいい」だけのコードに限界を感じ、気がつきました。自動テストのコードもまた、ソフトウェアだということです。 そこにはソフトウェア設計の原理原則が適用されます。特に重要だったのが「関心の分離」や「単一責任の原則」といった概念です。 テストコードの良し悪しを言語化できる これらの原則を意識するようになったことで、私はコードを「なんとなく動く」ではなく「構造」や「意味」で捉えられるようになりました。 例えば、表面的な理解しかしていない私では、生成AIや他者が書いたテストコードに対し、「動いているからOK」としか言えなかったと思います。 しかし今は、違和感を自分自身で言語化し、「テストの保守性」や「意図」という観点からレビューができるようになりました。 「このアサーションはこのテストで本当に確認したい内容でしょうか？」 「このコードは分離して共通化することが可能ではないでしょうか？」 「ツールが目指す方向性に合っているか」「良い構造か、将来の変更に耐えうるか」を判断するための視点は、ツールの思想や、設計原則を学ぶことで養えます。 この視点を持てたことが、私の技術的な自信の源泉となりました。 自動化を「当たり前の選択肢」にする 設計原則を知り、技術的な見通しが立つようになると、テスト自動化に対する心理的なハードルが消え去りました。 そして、テスト自動化は特別な領域ではなく、「当たり前の選択肢」の一つになっていることに気がつきました。 「選択できる」という強み 今の私は、簡単なスクリプトであれば構成を考えてサッと自分で書くことができます。(今では生成AIを使いますが) あるいは、複雑なテストであっても、その構造を読み解き、保守のリスクを見積もることができます。 重要なのは「全てを自動化すること」ではありません。 「ここは手動でやるべきか、自動化すべきか」という問いに対し、技術的な裏付けを持った上で自信を持って検討できる状態にあることです。 自動化もできるし、手動もできる。「今回はこちらがベターな選択だ」と根拠を持って説明できること。 これが、QAエンジニアとしての幅を広げていると考えています。 専門性の組み合わせ 最後に、この技術が他の専門性とどう結びつくか触れておきます。 テスト設計との組み合わせ 自動化の構造（アーキテクチャ）を理解することで、テスト設計の質が変わります。 まず私が強く感じているのは、 自動テストを書くことによってテストケースの性質を理解できるようになったことです。 自動化しやすいテストケースは、往々にして「前提条件が明確」で「責務が単一」な、人間にとっても分かりやすいテストケースです。 「関心の分離」という思考の補助線は、自動・手動を問わず、堅牢なテスト設計を行うための強力な武器になります。 テストマネジメント テストマネジメントにおいては、ROIの判断や戦略的に自動化を取り入れるかどうかの判断が、より精緻になると考えています。自動化コードの「保守コスト」や「技術的負債」のリスクを実体験に基づいて理解しているため、過度な期待も悲観もせず、 プロジェクトの状況に合わせて適切なタイミングで自動化という選択肢を選べるようになりました。 おわりに かつての私のように、「文系だし」「環境構築すら怖い」と尻込みしている方も多いかもしれません。 私にとって、テスト自動化を学ぶことは、ある意味で「プログラマーになること」と同義でした。 しかし、そのハードルは、想像していたよりもずっと低いものでした。 そしてそのハードルを飛び越えることによって、プログラマーとして「プロ」であることの困難さと、その凄みを目の当たりにしました。 勇気を出してその一歩を踏み出してみれば、そこにはシステムが動く仕組みや、先人たちが築き上げたソフトウェア設計や原則が、複雑な現実を生き抜くための「道しるべ」となってくれるはずです。 テスト自動化を学ぶことは、その「道しるべ」を発見する最高のきっかけになるはずです。 その小さな一歩が、あなたのQAエンジニアとしての強固な土台となると考えています。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする The post 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする first appeared on Sqripts .

こんにちは。システムエンジニアのバッサーノです。 私はここ1年ほどモバイルデバイスに関連したソフトウェアの開発業務に携わっています。 特に近年はテスト自動化への注目が高まっており、モバイルデバイスについてもテスト自動化の導入が進んでいます。 今回はモバイルテストの自動化をする上で最もオーソドックスなツールであるAppium（アピウム又はアッピウム）について、概要や使い方に触れていきたいと思います。 この記事がモバイルアプリのテスト自動化に興味がある方、導入を検討している方や勉強中の方の参考になれば幸いです。 1. Appiumとは？ 1.1. Appiumの概要 まずAppiumとは何か、形式的なところで言うと Appium は、iOS・Android向けのネイティブアプリ、ハイブリッドアプリ、Webアプリのテストを自動化するためのオープンソースツールです。 構造としては以下の図のようになっており、Appium Serverがテストスクリプトの命令を解析してAndroid/iOSデバイスを操作するコマンドへと変換し、デバイス上で指定した操作を実行してくれます。 またAppiumという名前からもわかるように、Webのテスト自動化で標準的に使用されているSeleniumベースの記法となっているため、すでにSeleniumを使用している方は同じような形式でAppiumのテストスクリプトを作成することができます。 1.2. Appiumの主な特徴 1.2.1. クロスプラットフォーム対応 iOS と Android の両方に対応し、同じテストコードで異なるプラットフォームをテストできます 1.2.2. 多言語サポート WebDriver Protocol に基づいているため、以下の言語でテストコードを記述できます Java Python JavaScript (Node.js) Ruby C# PHP 1.2.3. オープンソース Appiumはオープンソースで開発が進められているため、無償で利用することができます 1.3. Appiumを利用するメリット Appiumを使うことで以下の点を改善することができます。 自動化によってリグレッションテストのたびに同じ操作を繰り返す必要がなくなる iOSとAndroidで別々のツールを使い分ける必要がない CI/CDパイプラインにテストを組み込むことができる 2. Appiumを動かしてみる では実際にAppiumを使ってどのように自動テストができるのか、Appiumを実際にインストールして動かしてみましょう。 2.1. 事前準備 前項でも述べているようにAppiumはオープンソースであるため、無償でインストールして利用することができます。ここではサンプルとして以下の環境でAppiumを使用してAndroidのテストを実行してみます。 OS バージョン macOS 14.6.1 ツール バージョン 確認コマンド Node.js v20.19.1 node -v npm 11.6.2 npm -v JDK Java 8 java -version 2.2. Appium のインストール この記事の執筆時点（2025年11月）ではAppiumの最新バージョンは3.1.1であるため、今回はこのバージョンをインストールして使ってみます。使用するAppiumのバージョンによっては事前条件の各種ツールの必要バージョンも変化します。 # Appium本体のインストール npm install -g appium # インストールの確認 appium -v 出力例 : 3.1.1 2.3. UiAutomator2ドライバのインストール Appiumでは、プラットフォームごとのドライバを個別にインストールする必要があります。 # Android用UiAutomator2ドライバのインストール appium driver install uiautomator2 # インストール済みドライバの確認 appium driver list --installed 出力例 : ✔ Listing installed drivers - uiautomator2@6.3.0 [installed (npm)] なお、すでにAppium2系をインストール済みの場合は、ドライバのバージョンの競合などによりエラーが発生する場合があります。その場合はドライバの更新や再インストールなどを試してみてください。 2.4. Android Studioのインストール 今回はAndroid Studioのエミュレータを使用してテストを実行します。Android Studioをインストールされていない場合は公式サイトからインストールが可能です。 Android Studio公式サイト： https://developer.android.com/studio 2.5. 環境変数の設定確認 Androidツールを使用するためには環境変数が設定されている必要があります。以下のコマンドを実行し、JAVA_HOMEとANDROID_HOMEに正しいパスが表示され、PATHにそれらのパスが含まれていれば問題ありません。 # 環境変数の確認 echo $JAVA_HOME echo $ANDROID_HOME echo $PATH 未設定の場合は、以下を ~/.zshrc または ~/.bash_profile に追加します: # Java export JAVA_HOME=$(/usr/libexec/java_home -v 8) # Android SDK export ANDROID_HOME=$HOME/Library/Android/sdk export PATH=$ANDROID_HOME/platform-tools:$PATH export PATH=$ANDROID_HOME/cmdline-tools/latest/bin:$PATH export PATH=$ANDROID_HOME/emulator:$PATH # 設定を反映 source ~/.zshrc # または source ~/.bash_profile 2.6. Appium Doctorで環境チェック Appium Doctor を使って、環境が正しくセットアップされているか確認します。 # Appium Doctorのインストール npm install -g appium-doctor # Android環境のチェック appium-doctor --android 出力例 : info AppiumDoctor Appium Doctor v.1.16.2 info AppiumDoctor ### Diagnostic for necessary dependencies starting ### … info AppiumDoctor ### Diagnostic for optional dependencies starting ### … 「 ### Diagnostic for necessary dependencies starting ### 」のすべての項目に ✓ が表示されればOKです。 2.7. Androidエミュレータの準備 今回はAndroidエミュレータを使用してテストを行います。 Android Studioを起動 Tools > Device Manager を開く Add a new device… > Create Virtual Device をクリック デバイス（例: Pixel 5）を選択して Next システムイメージ（例: API 33 (Android 13)）を選択して Next (未ダウンロードの場合はダウンロードアイコンからダウンロードが可能) エミュレータ名を設定（例: Pixel_5_API_33 ）して Finish Device Managerメニューにある「 ︎」を押してエミュレータを起動する Android Studio上でエミュレータの画面が表示されればOKです。 また、以下のコマンドでデバイスの接続状態が確認できます。「emulator-5554」という文字列がこのデバイスを指定するためのシリアルIDとなっており、実機の場合もここがデバイス固有の値になります。 # 接続されているデバイスを確認 adb devices 出力例 : List of devices attached emulator-5554 device Status が device と表示されていればOKです。 2.8. Python環境のセットアップ Appiumは複数の言語のスクリプトに対応していますが、今回はその中でもPythonを使用してサンプルのスクリプトを作成します。 以下で必要なライブラリのインストールを行います。 # Appium Pythonクライアントのインストール pip install Appium-Python-Client # Seleniumライブラリ（依存関係） pip install selenium # pytest（テストフレームワーク） pip install pytest 2.9. テストスクリプトの作成 それでは、実際に実行するテストスクリプトを見ていきましょう。ここでは、以下のようなテストを作成しています。 Androidの標準の設定アプリを起動する 画面要素を探して標準出力する スクリーンショットを取得する 流れとしてはまず端末の指定するためのシリアルIDやテスト対象のアプリの指定などの各種情報をcapabilitiesに設定して、この後立ち上げるAppium ServerにHTTP通信してセッションを作成します。 そして、そのセッションを使用してテスト内の各命令を送信し、デバイスを操作してテストを実行します。 ファイル名 : test_android_settings.py from appium import webdriver from appium.options.android import UiAutomator2Options from appium.webdriver.common.appiumby import AppiumBy import time def test_android_settings(): # Desired Capabilitiesの設定 options = UiAutomator2Options() options.platform_name = 'Android' options.automation_name = 'UiAutomator2' options.device_name = 'emulator-5554' # adb devicesで確認したデバイス名 # 設定アプリを起動（アプリのインストール不要） options.app_package = 'com.android.settings' options.app_activity = '.Settings' # セッション開始までのタイムアウト設定 options.new_command_timeout = 300 # Appium Serverに接続 driver = webdriver.Remote('http://localhost:4723', options=options) try: print("✓ 設定アプリが起動しました") # アプリが起動するまで少し待機 time.sleep(2) # 現在のアクティビティを取得 current_activity = driver.current_activity print(f"✓ 現在のアクティビティ: {current_activity}") # 画面上の要素を検索（検索ボックスを探す） search_elements = driver.find_elements(AppiumBy.CLASS_NAME, 'android.widget.TextView') print(f"✓ 画面上に {len(search_elements)} 個のTextView要素が見つかりました") # 最初のいくつかの要素のテキストを表示 print("\n--- 画面上の要素 ---") for i, element in enumerate(search_elements[:5]): text = element.text if text: print(f"{i+1}. {text}") # スクリーンショットを保存 driver.save_screenshot('settings_app.png') print("✓ スクリーンショットを保存しました: settings_app.png") print("\n✓ テスト成功！") except Exception as e: print(f"✗ エラーが発生しました: {e}") driver.save_screenshot('error_screenshot.png') finally: # セッションを終了 driver.quit() print("✓ セッションを終了しました") if __name__ == '__main__': test_android_settings() 2.10. Appium Serverの起動 ここまででテストを実行する準備が整いました。早速テストを実行してみましょう。 手順としてはまずAppium Serverを先に起動します。 # デフォルトポート（4723）で起動 appium # または、ログレベルを指定して起動 appium --log-level info 起動成功時の出力例 : [Appium] Welcome to Appium v3.1.1 [Appium] The autodetected Appium home path: /Users/testkit/.appium [Appium] Attempting to load driver xcuitest... [Appium] Attempting to load driver uiautomator2... [Appium] Requiring driver at /Users/testkit/.appium/node_modules/appium-uiautomator2-driver/build/index.js [Appium] Requiring driver at /Users/testkit/.appium/node_modules/appium-xcuitest-driver/build/index.js [Appium] AndroidUiautomator2Driver has been successfully loaded in 1.403s [Appium] XCUITestDriver has been successfully loaded in 3.417s [Appium] Appium REST http interface listener started on http://0.0.0.0:4723 [Appium] You can provide the following URLs in your client code to connect to this server: http://127.0.0.1:4723/ (only accessible from the same host) http://192.168.3.13:4723/ http://192.168.64.1:4723/ http://172.32.1.15:4723/ http://172.32.1.34:4723/ http://172.32.1.26:4723/ [Appium] Available drivers: [Appium] - xcuitest@10.8.0 (automationName 'XCUITest') [Appium] - uiautomator2@6.3.0 (automationName 'UiAutomator2') [Appium] No plugins have been installed. Use the "appium plugin" command to install the one(s) you want to use. 注意 : Appium Serverは起動したままにしておきます（テストスクリプトは別のターミナルウィンドウで実行してください）。 2.11. スクリプトの実行 # スクリプトを実行 python test_android_settings.py 実行成功時の出力例 : ✓ 設定アプリが起動しました ✓ 現在のアクティビティ: .Settings ✓ 画面上に 42 個のTextView要素が見つかりました --- 画面上の要素 --- 1. Settings 2. Network & internet 3. Connected devices 4. Apps 5. Notifications ✓ スクリーンショットを保存しました: settings_app.png ✓ テスト成功！ ✓ セッションを終了しました 出力されたスクリーンショット(settings_app.png) このようにAppiumを使用することでモバイル端末上でアプリを起動し自動テストを実行することができます。実行時にAndroid Studioのエミュレータの画面をみてみると、実際に端末の設定画面が起動されるところも確認できると思います。 また、今回はAndroid Studioのエミュレータを使用しましたが、実機をADB接続することでエミュレータと同様に実機上でアプリをテストすることも可能です。 3. まとめ 本記事では、モバイルテストの標準的な自動化ツールとして、Appiumの概要を説明し、インストールから実際のテストコード実行までを解説しました。 Appiumは環境構築でのコマンドラインの操作やテストスクリプトの作成など、普段あまり触れない方にとってはとっつきにくい部分もあるかもしれません。実際に現在では様々なテスト自動化のGUIツールが存在し、コードレスに自動テストを作成することもできます。しかしAppiumは原始的な分、より柔軟なテストが作成できますし、自動テストの原理や流れを理解しやすいという点でも勉強して損はないと思います。 次回は、実機でのAppiumのテスト実行の手順や、より複雑なテストを作成するのに便利なツールの紹介をしていきます。 The post Appiumモバイルテスト自動化入門(1) 〜環境構築と初めてのテスト〜 first appeared on Sqripts .

前回 、エンジニアの成長における「心技体」の中でも、土台となる「心（マインドセット）」の重要性についてお話ししました。早速、具体的な話に入っていきます。まずはちょっとしたことから「思いやり」を始めていきましょう。 関連記事 【第1回】QAエンジニアの「心技体」 1人のエンジニアとして成長し続けるために、私たちは何を意識するべきでしょうか。特定の知識を極めることでしょうか。最新の技術トレンドを追いかけることでしょうか。それらも言うまでもなくとても重要なことですが、もう1つ普遍的な要素があるかもしれません。武... 　続きを読む　 Sqripts 本記事は、まずはQAエンジニアとしての社会人キャリアを歩み始めたばかりの方々（エントリーキャリア）を主な対象としています。今回は「心（マインドセット）」の一つである 「他人を思いやる力」 について、具体的な行動レベルまで深掘りしていきます。 コロナ禍を経て在宅勤務が当たり前の働き方のひとつになった今、 「見えない相手をどう思いやるか」 というスキルは、チームで成果を出すための重要なスキルとなったと考えています。 そして、ビジネスにおける「思いやり」とは、単なる優しさや気遣いではありません。それは、 チーム全体の生産性を最大化するための、合理的な配慮 です。このスキルは、お互いの姿が見えない在宅勤務という環境で、その真価が問われると思います。 私自身、エントリーキャリアの時には何度もこれから話すようなことで怒られてきました。私は全く完璧な人間ではないのです。たった1人のQAとして会社に所属をし、1人で周り全ての信頼を積み重ねなければいけないこともありました。その中でこれからお話しするようなことをしなかったばかりに失敗をして周囲の信頼を落としてしまうこともありました。 これからお話しすることは当たり前のように聞こえますが、誰でも最初からできることでは決してないのです。それでは、見ていきましょう。 在宅で他者と働く……ための、前提と作法 在宅勤務では、あなたが仕事をしている姿を誰も直接見ることはできません。これは、 あなたが報告をしない限り、周囲は「仕事が進んでいるのか」「どこかで困っていないか」を把握できず、不安や憶測を生む原因となります。 ここで「いちいち進捗を報告しないといけないのか？」という疑問を持つ方がいるかもしれません。その答えは明確に「はい」です。なぜなら、他者と協力して働くとは、 自身の状況を適切に共有し、チームの透明性を保つこと だからです。 ただし、「報告」と「むやみな割り込み」は紙一重です。特にテキストコミュニケーションは、口頭での会話と異なり、相手に文脈の理解や論理構造の読解を強いてしまいます。また、レスポンスする際にも書き手の論理構造や客観的な分かりやすさを考えるコストや時間が必要になります。そのため、安易な割り込みは相手に考える時間を使わせてしまい、結果的に相手の時間を大きく奪ってしまうのです。 「むやみな割り込みをしない」ことは、相手の時間を不必要に奪わないためにも、非常に大切な「思いやり」です。そのためには、メッセージを送る前に、背景や根拠、判断に必要な材料をあらかじめ整理し、要点を簡潔にまとめておくことが重要です。あるいは、すぐに返事が必要ない用件であれば、相手が都合の良い時に確認できるチケットのコメントに残すなど、「バーチャルな肩たたき」の作法を意識しましょう。 「この連絡内容や連絡のやり方は、相手の時間を奪うだけの価値があるものか？」と自問自答することが、信頼関係の第一歩です。 在宅勤務で大切なのは「ステータスで仕事を進めること」 前述の「報告」を実践する上で最も大切なのが、 ステータスの更新を意識すること です。 ステータスを細かく区切ってこまめに更新するほど、あなたの状況は明確になり、周囲も「ちゃんと仕事が進んでいる」と安心して自身の業務に集中できます。 これが、在宅勤務において自律やセルフマネジメントが必要であるとされる理由ではないでしょうか。 「いつでもいい」の正しい意味 この「ステータス管理」を実践する上で、特に注意すべきなのが「いつでもいい」と言われたタスクの扱いです。これは決して「放置していい」という意味ではありません。依頼が発生した時点で、相手はあなたの成果を待つ状態に入っています。あなたが完了を遅らせるほど、相手はその時間を奪われ、後続タスクがある場合はチーム全体の進捗が滞ります。 例えば、あなたに以下の4つのタスクがあるとします。 5分で終わるタスク（いつでもいい） 1時間で終わるタスク（いつでもいい） 1日かかるタスク 1週間かかるタスク もし、あなたがDの完了後にAを報告したら、依頼者はどう思うでしょうか。 「5分で終わるなら、もっと早く対応してくれれば、自分の次の仕事が進んだのに…」 と感じるのが自然です。 「いつでもいい」ものほど早く終わらせようとする意識は、こうした些細な待ち時間をなくし、あなたの信頼を積み重ねる大事な行動になります。また、優先度の低いタスクがいつまでも滞留（スタック）するのを防ぐ効果もあります。 ただ、優先度が低いタスクであることには変わりありません。そこで有効なのが、 「このタスクは、自分だけで完結するのか、それとも他者を巻き込むのか」 を自問自答することです。自分だけで完結する作業であれば他の優先タスクとの兼ね合いで調整しても良いですが、他者を待たせるタスクだけは、積極的に片付けていくようにしましょう。 ミーティングの予定をカレンダーに入れるというちょっとしたことでも、MTGに招待される側はその日の予定を確認し整理をして、明日の始業に向けて準備をするというタスクを後ろ倒しにさせてしまいます。 ステータスの更新が信頼を作る 複数のタスクがすべて「Doing」のままだと、周囲は何が進んでいて、どこで詰まっているのか判断できません。そこで重要になるのが、ステータスを「やっているか否か」ではなく 「どの程度完成しているか」 で区切る意識です。 「叩き台が完成したので、方向性が合っているか確認お願いします」といった途中経過の共有は、問題を早期に解決し、周囲に安心感と信頼をもたらします。手が止まった時点で「ここまでは自分で考えました。でもここから迷っています」と伝えるのは、あなたの誠実さを示し、問題を早期に解決するための極めて有効な手段です。 遅れるほど成果物に「質」が求められる こまめな報告を怠ったりちょっとしたことを後回しにすると、もう一つ厄介な問題があります。それは、 成果物の提出が遅れるほど、アウトプットに対する期待値が上がってしまう という点です。時間をかけた分、「しっかり作り込まれているはずだ」と思われるのは当然のこと。 もし2日かけて提出した成果が、実は15分で終わるような内容だったり、他者の成果の流用だったりした場合、「時間を無駄にしたのではないか」という不信感に繋がりかねません。こまめな進捗共有や困っていることの相談は、こうした過度な期待値の上昇を防ぐためにも不可欠なのです。 相手の時間を尊重するコミュニケーション技術 これまでの話は、主に「報告」という受け身のコミュニケーションでした。ここからは、依頼や質問といった、より能動的なコミュニケーションにおける「思いやり」の技術について解説します。 1. 根拠のある依頼 タスクの期限延長や仕様変更など、相手に行動や承認を求める際には、必ず 客観的な根拠 が必要です。「私が困っているから助けてください」という主観的な訴えは、相手に判断材料を与えず、一方的な要求の押し付けになりかねません。客観的なデータや事実に基づいて依頼することは、相手が迅速かつ合理的に判断するための手助けとなり、結果的に相手の時間を尊重する「思いやり」となるのです。 2. 相手の時間を奪わない質問の仕方 エントリーキャリアの方が最も悩むのが「質問」でしょう。良い質問の基本は、「よくない質問＝相手の時間を奪う行為」という意識を持つことです。 自己解決の過程を示す： 「〇〇を達成するために、AとBの方法を試しましたが、Cというエラーが出てしまいます」のように、自分がどこまで調査・試行したかという具体を伝えます。 期待する結果と現状の差分を明確にする： 「本来は〇〇となるはずが、現状は△△になっています」と、ゴールと現在地という抽象を示します。 質問を具体的にする： 「動きません」ではなく、「この部分のエラーメッセージの意味が分からず、解決のヒントをいただけますか？」と、何に困っているのかをピンポイントで伝えます。 3. 一度のやり取りで完結できる文章を意識する 在宅勤務は、相手がすぐに返信できない「非同期」が基本です。一度のメッセージで完結させる文章術は、相手の集中力を奪わず、無駄なやり取りを減らす「思いやり」です。 結論ファースト： 「〇〇について相談です」と最初に目的を明確にします。 背景と経緯の提供： 相手が「これって何の話だっけ？」とならないよう、関連するチケットのURLや過去のやり取りへのリンクを必ず添えます。 選択肢と自分の意見の提示： 「どうしたらいいですか？」と丸投げするのではなく、「A案とB案があり、私は〇〇という理由でA案が良いと考えますが、ご意見いただけますか？」と書きます。 まとめ 在宅勤務で他者と円滑に働くための基本は、以下の行動に集約されます。 ステータスを軸に仕事を進め、更新を早める 周囲を巻き込む「いつでもいい」は、相手を待たせすぎないことが前提と心得る ステータスを「完成度」で細かく区切り、途中経過を共有する 依頼や質問は、相手が判断しやすいように「根拠」と「試行錯誤の過程」を添える 文章は、一度のやり取りで完結するように情報を整理して書く これらはすべて、相手の時間を尊重し、チームの透明性を高め、不必要な不安や手戻りをなくすための 「合理的な配慮」 です。こうした一つひとつの配慮がチームに心理的安全性を育み、あなたの「信頼」を築き上げます。 The post 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは first appeared on Sqripts .

今回から新連載をスタートします。本連載では、QAエンジニアやテストエンジニアの中途採用において生じているミスマッチを解消し、 求職者・募集側双方の「解像度」を高める ための具体的なニーズ、課題、対策について解説します。 私は仕事・プライベート両面で（自分自身の転職を含め）、QA・テストエンジニアの採用に関連して色々な活動をしてきました。そのなかでわかったのは、募集する側も、求職者側も、それぞれに困っているということです。 採用したいという会社・仕事を探しているという個人がいずれもたくさんいるのであれば、多くの人・会社がハッピーになれるような気がします。しかし実際には、両者のマッチングはそううまくいっていないようです。中にはうまくいっているように見える会社さんもありますが、全体の割合で考えると決して多くはないでしょう。 このような、募集側・求職者側が双方困っている状態に対して、個人として微力ではありますが、なにかしらお役に立てれば・・・と思って今回の連載を書こうと決めました。 連載の全体像については本記事後半で触れることとし、まずはQA・テストエンジニアの採用で感じることからお話していきます。 求職者側・募集側になって、そして両者を支援してみて見えたこと 私は過去の所属企業においてQAエンジニア/テストエンジニア/テスト自動化エンジニアの採用に関わっており、募集内容の作成や書類選考・面接などを行ってきました。本職の人事の方には及びませんが、エンジニアとしては採用活動に関与したほうかなと思っています。 また、個人活動として「QAのことならなんでも話せるカジュアル面談」の窓口を設けて、本記事執筆時点で丸2年ほど色々な方とお話する機会をいただきました。この活動でさまざまなお悩みに対して相談に乗っていたりもしたのですが、そのなかのトピックとして「転職活動がうまくいかない」等採用に関するものもありました。実際に職務経歴書についてレビューしたり、気になる会社さんのカジュアル面談にお繋ぎしたり、といったことも行っています。 この実体験から、いくつか重要な点が見えてきました。 スキル・経験値部分でのミスマッチがある 転職サイトなどの募集を見ると、QAエンジニアの募集は昔と比べてかなり数が多いように見えます。募集がたくさんあるということは、良い条件で容易に転職が可能・・・と思いますよね。 しかし、そこで求められているのはQAのリーダーができる人など、いわゆるハイクラス人材、スペシャルな人である場合が多いです。 背景にはさまざまな要因が考えられますが、全体の傾向としては「とにかく人が欲しい」という企業は少なくなっており、「優秀な人だけが欲しい」「ベテラン相当の即戦力が欲しい」というのが本音のようです。 では求職者側はどうでしょうか。身の回りのQAコミュニティでの人の移動などを見ていると、企業側が欲している 優秀な人は、リファラル等で転職していく 傾向があるようです。一方、若手だけれども伸びしろがある人や、強い意欲があるけれども現職でなかなかスキルアップの機会に恵まれないため転職を考えている人、も世の中にはたくさんいます。しかし、経験年数や経験した業務の内容などが企業の求める「ハイクラス」の要件に満たず、なかなか転職活動がうまくいかない状況が見られます。 まとめると、 企業側：ハイクラス人材が欲しいがリファラルなどで転職する場合も多く、採用市場にはでてきづらい、母数が少ない 求職者側：やる気とポテンシャルをもつ層が、ハイクラス相当の実績や経歴を得る機会を求めている という、若干のミスマッチが起きているというのが現状ではないか、と私は見ています。 アピール不足による機会損失 採用市場におけるミスマッチがあるとして、企業側も「ハイクラスでなければ絶対にダメ」というところばかりではありません。ポテンシャルに期待しての採用や、＊年後にはこのくらいに成長してくれそうだから、といったように未来を見通した採用をしている会社ももちろんあります。 ここで求職者側が、自身のポテンシャルや今後の成長についての見通しを適切にアピールできれば、双方にとって良い形でマッチングすると思うのですが・・・募集する側の立場から見て非常に「もったいない」と感じる場面も多々あります。 採用面接や書類選考を担当し、担当のステップで合格判断をして次のステップに進んでもらう場合は、「なぜこの候補者を通過させるのか」を説明できなければいけません。これは社内でより上位の選考官に共有するためという側面もありますし、「迷ったら不合格」が採用のセオリーとも言われています。 つまり、合格にするには合格にするなりの理由が必要なんですね。 落とす理由は無いけれど、通すための理由にも欠ける。 そういった判断になる方が一定数いる、というのが私の実感です。おそらくスキルや経験があるのに、適切にアピールされていない。これが、もったいなさを感じるポイントでした。 募集側も訴求に困っている 求職者側だけでなく、募集側もアピールに困っているという話をよく聞きます。 どのような場所・インフラで募集をかけるとQAエンジニアにリーチできるのかがわからない どのような文面・内容で募集すれば応募してもらえるかがわからない、本職のQAに「刺さる」募集がだせていない が、個人的にいただくご相談トップ2です。「QAの方ってどこにいるんですか！？」は本当に鉄板の質問ですね。現職QAからすると「そこらにいっぱいいますよ」なのですが、募集側にとってはそこに適切にリーチできていないという問題があるようです。 とくに一人目のQAエンジニアを採用する場合はこれらの問題は切実です。QAエンジニアが社内にいれば募集文面のレビューや面接担当など任せられますが、一人目を募集している状態ではそれはかないません。QAエンジニアに対する知見やコネクションが無い状態でQAエンジニアを募集・採用しなければならないというのは、ハードルが高いです。 本連載の概要 QA・テストエンジニアの採用に関して、私が体験した・見聞きした情報をもとに現状をお話してきました。 本連載では、先に述べたような課題をクリアして、募集側・求職者側のチャンスが増えるためにはどうすればいいのかについてそれぞれの立場について解説していきます。前半である第2回・第3回は求職者側について、第4回・第5回は募集側についての内容となります。 第2回では、まずどのようなQAエンジニアが求められているのか、募集する側の声や実際に私が事業会社でQAエンジニアを募集していた際に「このような人を求めていた」という内容について説明します。全ての会社が同じような人材を求めている、というわけではありませんが、大まかな傾向とともに、パターンの一つとして参考にしていただければと思います。 第3回では、職務経歴書や面接でどうやって相手に「採用したい」と思わせるのか、考え方について解説します。これまでQAエンジニア個人に対して行ってきた職務経歴書のレビューの中で、よくコメントするポイントについてまとめます。書類・面接で落ちてしまう場合は単純にスキルが足りていないというケースもありますが、相手に合わせた見せ方・アピールができていないことが原因となっている場合もあります。こういった問題への対策を説明します。 第4回では、募集する企業側がどのように「求めるQA像」を表現するか、について解説します。とくに一人目QAを募集する場合、何を書けば訴求できるのか、逆に何を書くと避けられてしまうのかの勘所が無くて困ることも多いと思われます。QAが居ないから採用したいけど、QAが居ないから知見・勘所がない。このようなデッドロック状態の解消に役立てていただきたいです。 そして最後の第5回では、QAエンジニアに対する認知獲得について触れていきます。いくら募集が魅力的でも、実際にエンジニアから知られていないことには応募が集まりません。もちろん、「これをやればQAエンジニアの中での認知が獲得できます」というような銀の弾丸はありません。しかしやれることをコツコツやらなければ、いつまでも認知はされません。このあたりの、手の打ち方のバリエーションをご紹介できればと思っています。 最後のおことわり：採用・転職することがすべてではありません 連載の初回記事の最後で水を差すようなことを書いてしまいますが、なにもQAを採用することがすべて、転職をすることがすべて、ではありません。 冒頭で書いたように、採用したい、転職したいという思いを持った方同士がうまくマッチして双方が幸せになればそれは嬉しいことです。しかし、QAを採用すれば万事うまくいくわけでもなければ、個人が転職をすれば万事うまくいくわけでもありません。これらは言わずもがな、ですね。 しかしそれでもこのような記事を書くのは、QAを採用するための努力やQAとして採用されるための努力を適切に行うことが、企業・個人双方がQAに関する解像度を高めたり、自分たちのやろうとしていることを深堀りするよい機会になると考えているためです。 ひとことで言うと、さまざまなことを考え、言語化する強制力が働くというメリットがあります。 募集側であれば、自分たちが品質という視点でどのような困りごとがあって、QAエンジニアに何を求めたいのか。あるいは自分たちが何をわかっていて何をわかっていないのか。 こうしたポイントを言語化する必要に迫られますし、言語化できていないと結果的にふわっとした募集になり、誰も応募してこない・・・という結果になります。これは求職者にとっても同様です。 繰り返しになりますが、本連載を通じて絶対にQAを採用したり転職したりしろ！というつもりはありません。ただ、実際に募集・応募するかどうかは別として、考えるきっかけ・材料にしていただけるといいかと思います。 The post 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 first appeared on Sqripts .

これまでの連載では、「テスト設計」、「テストマネジメント」、「テストプロセス改善」といった、QAエンジニアとしての専門技術についてお話ししてきました。 今回は「幕間」として、技術とは少し異なるテーマを語ります。 連載の第1話で 、「多様な専門性を積み上げて、自分だけのQAエンジニア像を作っていく」というアプローチを紹介しました。 そう言っている私のキャリアのスタートは、実はエンジニアではありませんでした。 文系大学を卒業し、新卒で「営業職」に就いたのです。 いわゆる異業種転職であり、「回り道だね」と言われることもあります。 その気持ちも理解できます。 しかし、私自身はこの営業経験もまた、今のQAエンジニアとしての活動に息づいており、「土台」 になっていると感じています。 今回は、この「土台」がどのようにQAの専門性と繋がって いるのか、私の経験をお話しします。 営業の本質とは何か？ 「営業」と聞くと、コミュニケーション能力、交渉力、スピード、あるいは体力といったスキルや特性を思い浮かべるかもしれません。 もちろん、それらは重要です。 しかし、私が学んだ営業の本質は、それらを使う「目的」にあります。 営業の本質とは、突き詰めれば「発注書をもらってくること」だと私は捉えています。先に挙げたスキルは、すべてそのための「手段」に過ぎません。 この考えは、「目的のために必要な手段を正しく使う」という、私のエンジニアリングの指針に通じると考えています。 営業として「発注書」という明確なゴール（目的）のために、あらゆる手段（コミュニケーションや交渉）を最適化しようともがいた経験が今でも生きています。 現在のQAエンジニアとして「品質保証活動の目的は何か？」「この改善のゴールはどこか？」を常に問い、その達成のために最適な技術（手段）を選択するという、専門性の基盤になっているのです。 「納品後」の緊張感と説明責任 私は建設業の営業だったのですが、キャリアの土台として最も強烈に記憶に残っているのが、「施主検査」という体験です。これは、納品物（工事結果）をお客様（施主）が最終確認する場です。 私は営業であり、現場の作業を直接管理しないことが多かったです。 しかし、営業として施主検査に同行し、「正しく工事が行われたこと」「問題が正しく解決されたこと」を顧客に説明する「説明責任」がありました。 現場には、お客様、職人、そして営業の私といった関係者が集まります。 その中で、お客様が鋭い視点で確認していくのです。 「この配線はこれでいいの？」 「これの使い方はどうするの？」 どんな質問が飛んでくるかわからない。顧客の厳しい目線に晒される、あの独特の「スリル」と、緊張感を、私は肌で感じていました。 この経験は、現在のQAエンジニアとしての私に、二つの強さを与えてくれました。 社内ステークホルダーへの報告に、心理的負担がないこと チーム内のレビューや、マネージャーへの報告などで、私は心理的なプレッシャーをほとんど感じません。 なぜなら、本当の「厳しい目線」は、身銭を切って発注してくれた顧客の目線であることを知っているからです。 社内の指摘は、その「本当の検査」を通過するための、仲間からのフィードバックに過ぎないというマインドセットに繋がりました。 「どう伝えるか」を目的志向で考えられること  第3回の「テストマネジメント」で、QAは「意思決定を促すことが重要」であり、「組織全体での『合意形成』や『意思決定』の側面もある」と記述しました。 施主検査での説明責任は、まさにこれです。 ただ事実を並べるのではなく、「この問題は、このように解決済みです」と、相手が「OK」という意思決定ができるように情報を構成し、伝える必要があります。 顧客という最も厳しい相手に説明責任を果たそうとした経験が、「何を伝えるか」と同時に、「どう伝えれば、相手がより良い意思決定ができるか」を考える思考の土台となっています。 信頼を構築する「誠実さ」 “営業”というと、フィクションの影響か、数字のために軽薄な行動をとるイメージがあるかもしれません。 しかし、私が「発注書」をいただき続けるプロセスで痛感したのは、「信頼関係」の重要性であり、それを構築するための「誠実さ」でした。 特に私は20代前半と若かったため、知識や経験ではベテランにかないません。また、お客様からもそういった期待はされていません。 そんな私がお客様に信頼感を得るために唯一できたことが、「誠実さ」でした。 目の前のお客様が抱える問題に対し、真摯に考える。 時には、自社のサービスではなく別の方法を勧めるなど、会社にとって短期的な利益が最大にならない提案であっても、お客様にとっての最適解を「誠実」に答える。 こうした姿勢は、短期的な売上には繋がらないかもしれませんが、「あの若い営業は、うちのことを本気で考えてくれる」という長期的な信頼関係に繋がります。 結果として、継続的に相談を受けられるようになり、顧客との関係が強固になることを学びました。 この「誠実さ」は、QAエンジニア、特にテスターとしての振る舞いに直結しています。 テスターの仕事は、しばしば「悪い報告」（バグ報告やリスクの指摘）をすることとも言えます。 しかし、その際に「自分はテスター（役割）だから」とあぐらをかき、事実だけをドライに突きつけていては、本当の信頼は得られません。 大切なのは、例えば1on1などを通じて「個人として認識してもらい」、信頼関係を築くことです。 第4回の「テストプロセス改善」でも、現場の聞き取りや「徹底的な言語化」が重要だと述べましたが、その土台にも「信頼」が不可欠です。 悪い報告であっても、「誠実さ」という強みをもって、「あなたの仕事を否定したいのではなく、一緒にプロダクトを良くしたい」という姿勢で伝える。そうすることで、それは単なる「ダメ出し」ではなく、「プロダクトを共により良くするための建設的な情報」としてチームに受け取ってもらえるのです。 「顧客目線」の生々しさを知る 営業として新規の飛び込み営業をしていた時、「異物を見る」ような冷たい目線を浴びることも日常でした。 飛び込み営業では、受付で「いいですいらないです」と冷たくあしらわれることがほとんどです。「大変だね」と憐れみを持って親身に話を聞いてくれる人もいます。 QAエンジニアが語る「顧客目線」は、時として「この製品のファン」というポジティブな側面で語られがちだと考えます。 しかし、営業現場で体験した「顧客」とは、もっと多様で、生々しいものでした。 「品質は誰かにとっての価値」という言葉がありますが、私はこの「誰か」の多様性、特に「ファンではない人々」、あるいは「製品に全く興味がない人々」のリアルな視線を、この時に学びました。 この経験は、単に「ユーザー」と一括りにするのではなく、「この機能に全く期待していない人」や「競合製品と比較している人」といった、多様なステークホルダーの生々しい視点を想像する解像度が、営業経験によって格段に上がったと感じています。 QAエンジニアとして、営業の「土台」を活かすために 私にとって営業経験は、開発における「視野の広さ」 とも取れるような視点を形成する重要な土台となっています。 我々は開発チームの中にいると、時に「営業が変な要求を聞いてきた」と、一方的に批判してしまうことがあります。 しかし、こう想像してはいかがでしょうか。 「私たちが作った製品をお客様に届けるために、営業担当はどのような努力をしているのか？ 」 私が体験したような「生々しい顧客」と、日々対峙しているのは彼らです。 我々は「ユーザーにとって価値がある」だけでなく、「売れることが可能な製品」を作れているでしょうか？ もし、この記事を読んで「土台」の重要性に共感してくれたなら、ぜひ彼らの「リアルな声」に、パートナーとして耳を傾けてみていただきたいです。 可能であれば、ぜひ「商談に同席させてもらう」ことをお勧めします。 開発側からの歩み寄りを歓迎している営業担当は、皆さんが思うよりずっと多いと思っています。 そこで得られる「生々しい」顧客の視点や、営業担当が目的を果たすために、どれほどの「誠実さ」と「説明責任」を果たそうとしているかをぜひ体感してみてほしいです。 それこそが、あなたの専門性を強固にし、プロダクトを「売れる製品」へと導く、確かな「土台」となります。 一見、関係ないように見える経験も、必ずどこかで緩やかに繋がっています。 皆さんのキャリアを形作る「土台」は、どのような経験でできているでしょうか。 The post 【第5回】幕間：異業種経験を土台にする first appeared on Sqripts .