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 .

1人のエンジニアとして成長し続けるために、私たちは何を意識するべきでしょうか。特定の知識を極めることでしょうか。最新の技術トレンドを追いかけることでしょうか。 それらも言うまでもなくとても重要なことですが、もう1つ普遍的な要素があるかもしれません。 武道やスポーツの世界で一流を目指す者が重んじる「心技体」という言葉があります。この「心技体」とは、心と技術と身体能力……この三つの要素がバランス良く揃って、初めて真の実力が発揮されると言われます。 このような三位一体的な依存関係という考え方は、ソフトウェア開発者に限らず、QA、SRE、インフラ、セキュリティなど、 ITに携わるエンジニア の成長にも当てはめることができると考えています。 本連載では、この「心技体」をエンジニアの成長に必要不可欠な要素を表すモデルとして当てはめ、特にその土台となる 「心」 、すなわちコミュニケーションやヒューマンスキルに焦点を当てて掘り下げていきます。 今回はその序章として、まずエンジニアにおける「心技体」の全体像を概観します。 「心」としてのマインドセット：エンジニアとしての在り方 本連載で最も深く掘り下げていく 「心」 。ここで言う「心」とは、曖昧な精神論ということではありません。では何かというと、それはエンジニアとしての「在り方」や「考え方」を指す 「マインドセット」 です。そして最も重要なのは、このマインドセットが 才能に依存するものではなく、意識をして訓練することによって後天的に習得・向上できる「スキル」である という点です。 このマインドセットのスキルには、主に以下の力が含まれると考えます。 本質的な「正しさ」を考え抜く力 例えば、与えられたタスクをこなすことは、スタートラインに過ぎません。なぜこのテストアーキテクチャなのか？このテスト計画で目指したい品質を本当に保証できるのか？目指したい品質とは何か？ビジネス価値や将来の拡張性まで見据え、プロジェクトにとっての「本当の正しさ」を誰よりも深く考え抜き、意思決定する力です。 目的のために、貪欲に学ぶ力 優れたエンジニアは、コンフォートゾーンに留まらない傾向にあります。目の前の課題を解決するため、あるいは自らが見つけ出した「正しさ」を証明するために、必要とあらば開発、品質保証、インフラ、さらにはビジネス領域まで、あらゆることを貪欲に学び続ける傾向にあると考えています。 考え抜いたことを「伝える力」 どれほど優れたテスト設計やテスト戦略も、「どうしてこの戦略になったのか」という意図や背景が他者に伝わらなければ価値は半減します。客観的に妥当な設計書、意図の明確なテストケース、ユーザーへのリスクが伝わる不具合報告など、考え抜いた結論を他者が理解し、活用したり 意思決定できるという伝える力 です。 他人を思いやる力 信じられないかもしれませんが、エンジニアの成長において「他人を思いやる力」こそが、最終的に最も大きな差を生むスキルだと考えています。なぜならば、ほとんどの人は誰かと働き、誰かからお金をもらっているからです。特にソフトウェア開発は、個人の能力以上にチームでの共同作業が成果を左右します。そして、そのチームを構成するのは、 必ずしも合理的ではない「人間」 です。相手の立場や感情を想像し、敬意をもって接する力は、 チームの生産性と品質に大きく関係する のです。納得できない人もいるかもしれませんが、 人は感情で動き、立場によって主観的な正義が変わり、時にはそれは客観的に見ると自己中心的にさえなります。 この変えようのない事実を前提として受け入れること。そして、相手の主観や感情を理解しようと努めること。これは、単なる「優しさ」や「気遣い」といった精神論ではありません。それは、多様な人間で構成されるチームで成果を最大化するための、最も重要なビジネススキルであると考えています。論理や正論を振りかざすだけでは人は動きません。時には「自分がどう見られているか」を意識し、相手の心を動かさないと乗り越えられない逆境や、プロジェクトの成功があります。 これらの力は、まさにエンジニアに求められるコミュニケーション能力やヒューマンスキルの核と言えるのではないでしょうか。次回以降の連載では、この 「心」 をどう体現するのか、詳しく掘り下げていきます。 「技」としての技術：想いを現実に変える力 「技術」は、文字通り 「技」 です。目的を達成するための具体的な手段や方法を指します。 「心」で描いた「ユーザーの体験を良くしたい」「品質を底上げしたい」といった想いを、設計書、テスト計画、コードといった具体的な「かたち」にするのが技術です。また、テスト自動化やIaCのように、技術は人間の能力を拡張し、限界を超える助けとなります。技術は、私たちの内面と現実世界を繋ぐ、強力な架け橋です。 「体」としての知識：引き出しの多さ そして「知識」は、エンジニアとしての 「体」 そのものです。問題解決のための「引き出しの多さ」や「手札の数」と言い換えることができます。 開発手法、テスト技法、クラウドアーキテクチャ、セキュリティ…。この「体」である知識の量が、エンジニアとしての基礎体力を決定します。 日進月歩のIT業界において、新しい知識をインプットし、体を大きくし続ける努力を怠れば、それは現状維持ではなく「相対的な退化」を意味します。 三位一体の依存関係：なぜ「心・技・体」は一つでも欠けてはならないのか これまで見てきたように、「マインドセット（心）」「技術（技）」「知識（体）」は、それぞれが独立して存在するものではありません。これらは密接に依存し合っており、三位一体となって初めて真価を発揮します。 豊富な 知識（体） がなければ、最適な 技術（技） を選択できません。 優れた 技術（技） がなければ、蓄えた 知識（体） は宝の持ち腐れです。 そして、確固たる マインドセット（心） がなければ、 知識（体） と 技術（技） を正しい方向へ導くことができません。 豊富な知識（体）という土台の上に、それを具現化する技術（技）を磨き、そして、それらをどこへ向かわせるべきかを指し示すマインドセット（心）を鍛える。この心技体をバランスよくレベルアップさせることが、エンジニアを本質的な成長へと導くと考えています。 エンジニアとしてのキャリアが進むにつれて、求められる役割は「一対一」の単なるタスクの遂行から、「一対多」という価値の創出や仕組みの創造へとシフトしていきます。特にシニアやスタッフといった立場になると、後進の育成や、自身の知識・経験を組織全体に還元することが重要な責務となります。 この時、決定的に重要になるのが「心」、すなわち他者への配慮や敬意といったマインドセットです。どれだけ優れた知識や経験を持っていても、その土台となる人間的な信頼がなければ、組織を正しい方向へ導くことはできません。あなたの提言は「正論」として響くだけで、チームメンバーが心から耳を傾け、協力してくれることはないでしょう。 例えば、QAエンジニアが目指す「品質文化の醸成」という目標は、この典型です。ルールやツールを導入するだけでは文化は根付きません。チームメンバー一人ひとりの共感と自発的な協力を引き出す「心」の力があって初めて、組織全体の品質意識を高めることができると私は考えています。 余談： 大いなる力には大いなる責任が伴う 時に、私が働いているQA組織のみんなに願うのは、ただ技術力が高いだけでなく、本当に「レベルの高いQAエンジニア」になってもらいたいということです。そして、そのために欠かせないと思っているのが、 「大いなる力には、大いなる責任が伴う」 ということを理解するということです。この 「大いなる力」 には、技術や知識だけではなくマインドセットも含まれています。 これは、私が敬愛してやまない映画『スパイダーマン』に出てくる、あまりにも有名な言葉です（特にサム・ライミ版が好きです）。物語の主人公であるピーターは、ある日突然すごいパワーを手に入れますが、最初はそれを自分のためだけに使っていました。その姿を見てベンおじさんはこう言います。 『スパイダーマン』 ピーター、お前の年頃でどう変わるかによって一生をどんな人間として生きていくのかが決まるんだ。どう変わるのかは慎重に考えろ。そのトンプソンという生徒は殴られて当然かもしれないが、お前の方が強いからといって、殴る権利があるわけじゃない。忘れるんじゃない。大いなる力には大いなる責任が伴う。 『アメイジング・スパイダーマン』 聞くんだピーター。お前は父親によく似ている。本当に似てる。それはいいことだ。だが、お前の父親は信念を持って生きていた。彼はこう信じていた。人のためになる行いができるのなら、それをやるのが道徳的な義務だとな。その信念はどこに行った。選ぶことはできない。それは責任だ。 そして、その力を正しく使わなかった（強盗を見逃した）せいで、一番大切な人を失ってしまいます。 「自分には救う力があったのに、何もしなかった…」 取り返しのつかない後悔を通じて、彼は力の意味と、それを使うことの「責任」を痛感し、人々を守るヒーローになることを決意します。 この物語、実は私たちビジネスパーソンの成長にも、すごく大切なことを教えてくれると思いませんか？ 私たちの世界でいう「力」とは、これまで積み重ねてきた知識や経験、問題を解決できるスキルのこと。そして「責任」とは、その力をちゃんと使って、チームや組織を助ける役割のことです。 あなたの知識や経験があれば解決できる問題が目の前にある時、あるいはチームが困っている時。「これは自分の仕事じゃないから」と見て見ぬふりをしてしまうのは、あの時スパイダーマンが強盗を見逃したのと同じことかもしれません。その小さな見過ごしが、後でプロジェクトの遅延やトラブルといった、もっと大きな問題につながってしまうかもしれません。 キャリアを重ねて影響力という「力」が大きくなるほど、この「責任」も自然と大きくなっていきます。時には、自分のこと（私）よりも、チームのこと（公）を優先しなきゃいけない、時にはしんどい決断も必要になるでしょう。リーダーや経営者が、時に孤独に見えるのは、きっとこの重圧とずっと戦っているからなんだと思います。 そのため、勉強してスキルを磨くっていうのは、ただ賢くなることではないと考えています。 いざという時に、その力を使う「覚悟」を持つこと でもあるのです。そこにはヒューマンスキルも強く求められていると考えていて、せっかくの強い力が正しく使えなかったり、かえって誰かを傷つけてしまうことはもったいないと考えているのです。上層部がかえって多くの誰かを傷つけた結果、多くの人が退職し、壊れてしまった組織も見たことがあります。 私は、自分の組織に来てくれた人たちには、この「力と責任」をちゃんと理解して、チームに良い影響を与えられる人になってほしい。そして、その責任をしっかり果たせるような環境を作ってあげたい。心からそう思っています。 おわりに：次回からの連載に向けて 本日は、エンジニアの成長における「心技体」の重要性についてお話ししました。 心（マインドセット） ：何を、なぜ、どうするのかを深く問う探求心 技（技術） ：想いを形にする実践力 体（知識） ：可能性を広げる学びの土台 この三つのバランスを意識することが、真に価値を生み出すエンジニアであり続けるための鍵となります。 そして、本連載ではこの中でも全ての土台となる 「心」 、すなわちエンジニアとしてのマインドセットやコミュニケーション、ヒューマンスキルに焦点を当てていきます。 次回は早速、「心」の重要な要素である 「他人を思いやる力」 について、ビジネスにおける合理的な配慮という観点から深掘りします。どうぞご期待ください。 The post 【第1回】QAエンジニアの「心技体」 first appeared on Sqripts .

今回は、「テストプロセス改善」を取り上げます。 これまでの連載で、「テスト設計」や「テストマネジメント」といった専門性について触れてきました。これらはQAエンジニアとしての価値を発揮するための重要な技術です。 しかし、これらの技術を個人として高めるだけでなく、チームや組織全体として成果を出すためには、テスト活動を全体的に把握し、批判的に見直し、より良くしていくための具体的な提案と行動が不可欠です。 この不可欠な行動を実現するものこそ、「テストプロセス改善」という技術なのです。 この記事では、テストプロセス改善を、体系づけられたアプローチで合理的にテストに関する課題を解決する専門技術として捉えます。この技術を私自身がどのように学び、それがQAエンジニアとしての基盤となったかをお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 テストプロセス改善という技術  テストプロセス改善とは、大きく2つのフェーズに分かれる、と考えます。 目の前のテストについて評価したり、時には現場から聞き取りを行う そのコンテキストで最も効果的な改善を提案し、実行に移す 実際にはキックオフや効果測定など、より細かいプロセスがありますが、これらは概ね上記に大別できると考えます。 これらについて体系的な手順やプラクティスを提供するのが、テストプロセス改善技術です。 テストプロセス改善技術については、ASTERが「テストプロセス改善技術 入門ガイド」という冊子を無料で公開しているので、ぜひご覧になっていただきたいです。 ■ テストプロセス改善技術研究会（Test Process Study group） ／ASTER 「テストプロセス改善」に対するよくある誤解  「テストプロセス改善」という言葉を使うと、実際に伝えたい内容とはまた違った解釈をされる場合があります。 1. テストプロセス  「テストプロセス」と聞くと、JSTQBのテストプロセスのような、テスト計画からテスト完了までのプロセスのことを考えるかもしれません。それはテスト活動をある側面から見れば間違いではありません。しかし、多くのテストプロセス改善技術では、様々なアクティビティが相互に影響し合う、生態系のような複雑なシステムとして捉えられると、私は解釈しています。 2. 改善  「改善」と聞くと、ふりかえりやPDCAサイクルといった日々の小さな工夫や試行錯誤を思い浮かべるかもしれません。こういった理解も間違いではないですが、テストプロセス改善モデルによっては、これらの改善サイクルが健全に回っているかどうかも評価項目として捉えることがあります。 テストプロセス改善技術は、より構造的・体系的なアプローチを指します。 体系的なテストプロセスモデルがあり、さまざまな現場の状況に合わせて、どの順番で、どのような施策を打てば最も効果的かの仮説を立て、実行していくのです。 モデルは「思考停止」ではなく、思考の補助線  テストプロセス改善技術には、先人たちが作り上げた様々なモデル（TPI NextやTMMiなど：テスト成熟度を測り、改善のロードマップを提供するモデル）が存在します。これらを使うことに対して、「モデルに従うのは思考停止だ」であったり、「現場ときちんと向き合っていないコンサル的な考えだ」と批判的な意見を聞くことがあります。 しかし、私は全く逆の考えを持っています。 これらの技術を正しく扱うには、むしろ深い知識と洞察、そして徹底した言語化と説明能力が求められます。 モデルで扱っている一つ一つのアクティビティについて、「なぜこれが必要なのか」という理論や背景、目の前で起こっている現実や聞き取った内容を深く総合し、その上で「このコンテキストではどう適用すべきか」を自分の言葉で説明できなければなりません。 そういった洞察がない単なるチェックリストを埋める作業は思考停止とも言えるかもしれませんが、これらはモデルが意図しているところではないと考えています。 モデルは、複雑なテスト活動を構造的に理解するための 「思考の補助線」 と言えるでしょう。それを使いこなすことで初めて、現状分析の解像度が大幅に上がり、そのコンテキストに合った的確な提案ができるようになります。 体験談：言語化がもたらした、揺るぎない自信  学びのきっかけ  私がテストプロセス改善技術を学んだことは偶然でした。私が第三者検証会社に在籍していたとき、テストプロセス改善技術の育成メンバーとして、当時の上長から推薦されました。 私にしては珍しく、自発的に参加したものではなかったのです。 当初は、正直言って「嫌だな」と思っていました。当時持っていたテストプロセス改善技術のイメージは、レガシーで、現場では使えない、重厚長大なモデルだという先入観を持っていました。当時の自分にアドバイスするなら、その先入観は全くの間違いだと話すでしょう。 実際に私にとって、テストプロセス改善技術を学んだことは、QAエンジニアとしての大きな転機となりました。 得られた気づき  テストプロセス改善技術を学ぶ過程で、私は様々な現場の聞き取りを行いました。 そこでは、テストプロセス改善技術の中で扱う一つ一つのアクティビティに対して、徹底的な言語化が求められました。そして、その言語化を土台として、現場の言葉を使いながら説明し、理解し、解釈する必要がありました。 それまでは漠然と「こうした方が良い」と感じていたことと、「テストはコンテキスト次第」という原則に、構造的な理解と明確な言葉を与えることができるようになったのです。 ある時点から私にとって現場が全く変わって見えたことがとても印象に残っています。 例えば今までテスト設計の問題だと思っていたものが、テスト計画やコミュニケーションの問題だと気付けるようになったのです。 混沌で圧倒されるだけの現場を論理的に解釈し、建設的に改善が可能だと確信できるようになったのです。 自信につながる  テストプロセス改善技術を学んだのはコンサルタントとしてです。その経験から、私はどのような役割であっても、自信を持ってテストプロセスの改善を主導できるようになりました。 やがて、どんな現場であっても、現場の状況を把握し、課題を特定し、モデルを参考にしながら具体的な改善策を提示できる自信を深めるようになりました。 私はたびたび「プロのテスター」と名乗ることがありますが、 Sqriptsのプロフィール で「ソフトウェアテストに専門性を持つ」と表現できるほど、自分自身の確固たる基盤となっています。 専門性の組み合わせ  テストプロセス改善技術は、個人の自信だけでなく、他の専門技術と結びつくことで、より大きな価値を生み出します。 テストマネジメントとの組み合わせ  テストマネジメントとテストプロセス改善は、極めて親和性の高い技術です。テストマネジメントを行う過程で「なぜ改善が必要なのか（Why）」という目的を定義することがあります。これに対し、テストプロセス改善は 「どのように改善するのか（How）」 という具体的な道筋を示します。 この二つが結びつくことで、単なる場当たり的な対応ではなく、論理的で建設的な改善活動を推進することができます。 テストマネジメントで特定された問題（アウトカムに近いビジネス的な側面であることが望ましい）に対し、テストプロセス改善のモデルを使って体系的にアプローチすることで、一般的なベストプラクティスを取り入れつつ、確実に成果を上げることが可能になるのです。 おわりに：今日からできるテストプロセス改善  この記事では、テストプロセス改善がQAエンジニアとしてのキャリアを支えうるような、再現性と応用性の高い専門技術であることをお伝えしました。 テストプロセス改善技術をいきなり習得するのは難しいと思います。 そこで、あなた自身のテスト活動を振り返り、 なぜこの活動をやっているのだろうか？そして、その活動はどのような『言葉』で体系的に表現できるだろうか？ と言語化することから始めてみてください。 その小さな問いの積み重ねが、あなた自身の成長だけでなく、チームや組織全体のテスト活動を次のレベルへと引き上げる、強固な土台を築くことができるはずです。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 The post 【第4回】テストプロセス改善：思考の補助線としての専門技術 first appeared on Sqripts .

こんにちは。Sqripts編集部のハチワレです。 かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。技術と非技術の狭間に佇み、両方の世界を行き来する日々を過ごしております。 前回は「 Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた 」と題し、Google Cloudの認定資格にチャレンジした体験をお伝えしました。 今回はその学びを活かし、技術的なバックグラウンドに関わらず、ビジネスパーソン全般に役立つ生成AIの基礎知識と実践的な活用方法をお届けします。 関連記事 Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた｜知識ゼロから始めた学習方法と試験対策 こんにちは。Sqripts編集部のハチワレと申します。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。「非エンジニア」を称しています。今回は、非エンジニアの私がGoogle Cloudの認定資格、Generati... 　続きを読む　 Sqripts はじめに 昨今、生成AIは私たちの暮らしに急速に溶け込んできました。 今日の夕食のレシピを考えて 週末の旅行プランを立てて 渋滞を避ける最適なルートは？ など、日常のちょっとした場面で気軽に活用できるのが魅力です。ふとした遊び心で使ってみると、その応答の豊かさに驚かされることも少なくありません。しかし、遊びや生活での活用と、ビジネスでの活用は少し異なります。特に業務で効果的に使いこなすには、単なる「お遊び」を超えた基礎知識と実践的な視点が求められます。 プログラミングスキルの有無にかかわらず、「AIを業務に効果的に取り入れたい」、「チームのAI活用を推進したい」という方に、明日から使える知識をお伝えできればと思います。 生成AI時代に必要な基礎リテラシー 対話型AIとのコミュニケーションという新しいスキル 現代の生成AIの最大の特長は、普通の会話のように対話できることです。技術的な詳細を理解していなくても、効果的なコミュニケーションができれば誰でも活用できるのが魅力です。 例えるなら、専門知識を持つアシスタントと会話するようなものです。その道に詳しければ会話が深まりますが、基本的なやり取りには高度な専門知識は必ずしも必要ありません。 大切なのは「何を、どのように伝えるか」という対話の作法。これは実は多くの方が日々の暮らしの中で自然と磨いているものでもあります。 AIとの対話は、ある意味「言葉のキャッチボール」です。投げ方次第で返ってくる球の質も変わります。丁寧に、意図を明確に伝えることで、AIからも価値ある返答が得られます。 なぜ今、技術者も非技術者もAIリテラシーを持つとよいのか Generative AI Leader資格の学習を通じて強く感じたのは、AIツールは「技術を作る人」も「技術を使う人」も、立場を問わず恩恵を受けられるということです。 技術者にとっては開発効率の向上や創造的な問題解決のツールとして、非技術者にとっては専門知識のギャップを埋めてこれまで届かなかった領域へ手を伸ばしたり、業務を効率化したりと、新たな可能性を開くツールとして機能します。 最近興味深く感じていることのひとつは、技術者と非技術者が協働する際の「共通言語」としてのAIです。お互いの専門性を尊重しながら、AIを介して効果的なコミュニケーションを図ることができます。かつては疎通にストレスを感じていた両者の会話が、AIという翻訳者を得て、よりスムーズに、豊かになる可能性を秘めています。 共通言語としての使用の実例 先日、開発部門の担当者から、私の理解が及ばない質問を投げかけられました。自分の守備範囲と異なりましたが間違った回答をするわけにもいかず、Geminiに聞いてみることにしました。 ■プロンプト例 私はマーケティング担当者で●●のWebサイトの管理をしています。 現在△△のプロジェクトが進行中で、作業は現在▲▲のフェーズにあります。 ▲▲を進めるにあたり開発担当者から以下のような質問が来ました。 この中で「******」という記述の部分について、質問の意図がわからず回答に困っています。 どのように回答するのが適切ですか？ [ここに開発部門からの質問をコピペ] するとGeminiは内容を的確に判断し、フェーズの作業の理解と「******」の質問の意図、回答例について教えてくれました。Geminiの回答を読んであらためて開発者からの質問を見ると、確かに内容に誤りはないなと思えたので、その回答をアレンジして返信しました。結果、問題なく作業を進行することができました。 生成AIの限界を理解することの重要性 生成AIの活用において大切なことの1つに、「その可能性と限界の両方を理解すること」が挙げられます。生成AIは「魔法の杖」ではなく「便利だけど特性のある道具」として捉えることが重要です。 特に注意すべきは、 ハルシネーション（事実と異なる情報を自信を持って提示すること）の可能性 最新情報へのアクセス制限（トレーニングデータによる） コンテキスト理解の限界（長い会話や複雑な状況の把握には限界がある場合がある） こうした限界を理解した上で活用することで、より効果的に生成AIを業務に取り入れられます。 また、それぞれの限界を「できるだけ回避する技術」もあります。ですが、まずはその技術についてよりも「そういう技術もある」という知識を持ち、必要になった時に深掘りする姿勢が大切です。 社外秘情報を扱う際の注意 生成AIという便利な道具を手にした私たちですが、ことビジネスにおいては慎重に取り扱うべき情報があることも忘れてはなりません。特に企業活動の中では、 社外秘情報 という守るべき大切な情報の数々があります。 AIに教えてはいけないこと 生成AIは基本的に「会話の内容を学習する」仕組みになっています（学習しない設定にもできますが、一般論として語ります）。これはつまり、私たちが入力した情報は、サービス提供元のサーバーに送信され、場合によっては将来のモデル改善のために使われる可能性があるということです。 特に注意が必要なのは、 顧客等の個人情報（氏名、連絡先、購入履歴など） 未発表の製品情報や研究開発データ 社内の財務情報や人事情報 取引先との契約内容 アクセス認証情報（ID・パスワード・秘密鍵など） こうした情報をそのままAIに入力してしまうと、知らず知らずのうちに情報漏洩の原因となりかねません。AIに尋ねる前に、一呼吸おいて「この情報は外部に出しても問題ないだろうか」と自問する習慣をつけましょう。 情報を匿名化・一般化する工夫 それでも業務上、機密性の高い文書や情報について生成AIの力を借りたいこともあるでしょう。そんな時は、情報を「匿名化」したり「一般化」したりする工夫が役立ちます。 【具体例 】 【NG例】 山田太郎様（43歳）からクレームがありました。先日購入いただいたXYZ製品について、起動しないとのことです。購入日は2024年10月15日、シリアルナンバーはABC-12345です。適切な対応方法を教えてください。 【OK例】 あるお客様から製品不具合のクレームがありました。先日購入いただいた当社製品について、起動しないとのことです。適切な初期対応と調査手順を教えてください。 具体的な固有名詞や識別情報を削除しても、多くの場合は有益なアドバイスを得ることができます。必要な情報だけを入力するようにしましょう。 企業におけるAI利用ガイドラインの重要性 組織全体で生成AIを活用する際には、明確なガイドラインを設けることが大切です。 ガイドラインに含めるとよい項目 利用可能なAIサービスの指定 入力してよい情報と禁止情報の明確化 生成AIの出力結果の取り扱い方針 緊急時の対応手順 定期的な教育・研修の実施 こうしたガイドラインがあることで、社員一人ひとりが安心してAIの恩恵を受けられる土壌が育まれます。 セキュリティを考慮したサービス選択 すべての生成AIサービスが同じセキュリティレベルで提供されているわけではありません。企業の機密情報を扱う可能性がある場合は、特に以下のポイントに注目してサービスを選びましょう。 エンタープライズ向けプランの有無 データの保持・削除ポリシー プロンプトとレスポンスの暗号化 オンプレミス/プライベートクラウド対応 SOC2やISO27001などの認証取得状況 例えば、Google CloudのVertexAIやMicrosoftのAzure OpenAIなどは、企業向けのセキュリティ機能を備えています。個人利用の無料サービスと企業利用のエンタープライズサービスは、使い分けることが賢明です。 生成AIは力強い味方ですが、大切な情報を守るのはあくまで私たち自身です。便利さと安全性のバランスを取りながら、賢く活用していきたいものです。 プロンプトの力：言葉の選び方が結果を変える 同じAIでも全く異なる結果が得られる不思議 生成AIを使う中で、指示の出し方を少し変えただけでまったく異なる結果が得られるという経験をされた方も多いのではないでしょうか。 たとえば、 マーケティング計画書のテンプレートを作って と頼むのと、 20代向けSaaSプロダクトのマーケティング計画書で、特にSNS活用に重点を置いたテンプレートを作成して。競合分析セクションも含めて と頼むのとでは、得られる結果の質が天と地ほど違います。 ぜひ普段使っている生成AIで上記のプロンプトを入力してその結果を見てみてください！ プロンプト例と改善例（ビフォー・アフター） 【改善前】 システム仕様書を書いて 【改善後】 次の条件でシステム仕様書のテンプレートを作成してください。 ・対象システム：社内向け在庫管理アプリ ・主な機能：在庫登録・検索・レポート出力 ・利用者：倉庫スタッフと管理者 ・開発環境：React+Node.js ・セキュリティ要件：ロール別アクセス制御必須 特に技術仕様と画面仕様のセクションを詳細に 改善前では汎用的な内容しか得られませんが、改善後ではより具体的で実用的なテンプレートが得られます。この差がプロンプトの力です。 誰でも使える基本的なプロンプトテクニック4つ 5W1Hを意識する Who（誰が）、What（何を）、When（いつ）、Where（どこで）、Why（なぜ）、How（どのように）を明確にします。 役割を与える （ロールプロンプティング） 「あなたはセキュリティ専門家として…」「経験10年のプロダクトマネージャーの視点で…」といったように、AIに特定の専門家の役割を与えると、その視点からの回答が得られます。 出力形式を指定する 「表形式で」「箇条書きで」「600字以内で要約して」など、出力の形式を指定することで、より使いやすい結果が得られます。目的に合った形式を考えるのも、プロンプトの腕の見せどころです。 出力の例をいくつか提示 する（Few-shotプロンプティング） 出力に特定の文脈・型を指定したい場合は出力例をいくつか提示することで、型に合った回答を得ることができます。ただし、型に適合するあまりに「一般化能力」が損なわれる恐れがあります。 これらのテクニックは技術的なバックグラウンドに関わらず、どなたでも実践できるものです。プロンプトの質がAIとの対話の質を決めるといっても過言ではありません。 組織の中での効果的な生成AI活用法 組織の中で生成AIを活かす道は一つではありません。それぞれの立場で、それぞれの視点から、AIを取り入れることで、組織全体に新たな可能性の芽が育まれていきます。さまざまな立場から見たAI活用の姿をご紹介します。 マネジメント視点：チーム全体の生産性向上への活用 マネジメント層にとって、生成AIは組織全体の生産性を向上させるツールとなります。 例えば、 チーム間コミュニケーションの効率化（議事録作成・要約、アクションアイテムの抽出） リソース配分の最適化（複数のシナリオシミュレーション） 意思決定のサポート（データに基づく客観的視点の提供） 実際の活用例としては、 週次レビューの議事録をAIで要約し、次週のアクションアイテムを自動抽出する ⇒フォローアップの漏れが大幅に減少する などの事例があります。 開発者視点：コーディングと設計プロセスの強化 エンジニアにとっての生成AIは、単なるコード生成ツール以上の存在です。 コードレビューの効率化（潜在的な問題点の指摘） ドキュメント生成（コメントからの自動ドキュメント作成） アイデア出しと設計支援（異なるアプローチの提案） テストケース生成（エッジケースの検討） 昨今注目されているのは「講師としてのAI」という使い方です。新しい技術やライブラリについて、AIに説明させたり、サンプルコードを生成させたりすることで、学習効率が大幅に向上します。 ▼ こちらの記事 では、AIがテストエンジニアの日常をどう変えるのか？AIの活用方法について解説しています。ぜひ参考にしてください。 関連記事 テスト自動化の新たな地平：AIはテストエンジニアの日常をどう変えるのか？最新トレンドとツールの実態... テストエンジニアのユッキーです。普段は自動化担当部署で、お客様のテスト自動化導入をご支援したり、社内の自動化技術の研究開発に携わっています。皆さんの周りでも、「AI」という言葉を聞かない日はないのではないでしょうか。ある調査では、2024年のソフトウェ... 　続きを読む　 Sqripts 業務担当者視点：日常タスクの効率化と創造性の拡張 日々の業務を担当する方々にとって、生成AIは次のような場面で力を発揮します。 文書作成の効率化（レポート、企画書、メールの下書き） 情報整理と要約（大量の資料からの重要ポイント抽出） アイデア出しとブレインストーミング 多角的視点の獲得（異なる立場からの意見や観点の提示） 私自身、マーケティング企画資料の作成時間が半分以下に短縮された経験があります。ただし、AIの出力はあくまで「叩き台」であり、内容の正確性や適切性は人間がチェックする必要があります。 【関連用語】 HITL：Human-in-the-Loop （人間参加型） AIによる自動化された作業や生成プロセスに、 人間が意図的に介入する 仕組みやアプローチ。 人間は、AIの出した判断や結果を最終的に チェック・承認 したり、誤りを 訂正 ・学習データとして フィードバック することで、AIの精度と信頼性を継続的に高める「不可欠な監督者・共同作業者」の役割を果たします。 「AIの得意なところ」（大量処理・高速生成）と 「人間の得意なところ」（判断力・倫理観・細かな調整）を組み合わせ、最も質の高い結果を出すことを目的とします。 ユースケース別・最適なAIモデル選び Google系サービス（Gemini Enterprise、Notebook LM、VertexAI）の特長と使い分け Google Cloudの生成AI製品群は、それぞれ得意分野が異なります。 Gemini Enterprise (旧Agentspace) ： 複数のタスクを連携させた複雑な業務に最適です。例えば「データを読み解き、傾向を把握した上で提案資料を作る」といった一連の流れを自動化できます。APIや外部システムとの連携もできるため、業務プロセス全体を効率化したい場合に適しています。 Notebook LM ： データ分析と文書作成を組み合わせたい場合に威力を発揮します。数値データから洞察を得て、それをわかりやすいレポートにまとめる作業が得意です。データドリブンな意思決定を支える強い味方となります。 VertexAI ： より高度なカスタマイズやチューニングが必要な場合に適しています。企業特有の専門用語や業界知識を学習させたモデルを構築できます。技術チームと業務チームの連携によって大きな効果を発揮できるプラットフォームです。 Claude、ChatGPTなど他社サービスとの比較 Claude ： 文章の論理性や一貫性に優れており、長文の作成・要約・分析が得意です。レポートや提案書など、論理的な文書作成のサポートに適しています。また、倫理的配慮が強いのも特徴です。 ChatGPT ： 最も汎用的で使いやすいのが特徴です。特にGPT-4は創造的な発想や多角的な視点の提供に優れています。アイデア出しやブレインストーミングのサポートに最適です。プラグイン機能で拡張性も高いです。 重要なのは「どれが一番優れているか」ではなく「どのケースにどのツールが最適か」を判断できるリテラシーです。それぞれの特性を理解し、場面に応じた選択ができることが、生成AIリテラシーのひとつの形であるように思います。 ▼ こちらの記事 ではTeamsとCopilotを使った議事録作成を紹介しています。ぜひ参考にしてください。 関連記事 生成AIによる議事録作成ABC -TeamsとCopilotを使って- こんにちは。クオリティマネージャーの”黒山羊さん”です。前回は生成AI作成の議事録を補完する議事メモの取り方について書かせてもらいました。これまで私は生成AIでの議事録作成を試したことがなく、生成AIを使った議事録作成はお客様が行ったり、チームメンバーが... 　続きを読む　 Sqripts 明日から実践できる生成AI活用の第一歩 既存業務フローの中で無理なく始めるポイント 生成AIの活用を始める際のコツは、いきなり大きく変えようとせず、既存の業務フローの「ちょっとした隙間」から取り入れることです。 例えば、会議の議事録作成、週次レポートのドラフト作り、企画のブレインストーミング、参考資料の要約など、「失敗しても大きな影響がない」作業から始めるのがおすすめです。成功体験を積み重ねてから、より重要なタスクに応用していきましょう。 また、組織全体に一気に導入するのではなく、まずは小さなチームや個人レベルで効果を実感してから、徐々に広げていくアプローチも効果的です。 小さな成功体験を積み重ねる方法 私自身の経験では、以下のステップで進めると成功しやすいです。 Geminiを常に開いておく（業務での普段使いの生成AIならなんでもよいです） 1日数分の「AI実験タイム」を設ける 毎日少しだけ、業務の一部をAIに任せる時間を作りましょう。 （出力に感動して活用したくなるフェーズです） 成功と失敗を記録する どんなプロンプトが効果的だったか、何が上手くいかなかったかをメモしておく。 （実験フェーズです） 同僚と知見を共有する 「これ、AIを使ったらすごく楽になったよ」と具体的な成功事例を伝える。 （人に言いたくなるフェーズです） 「AIでやること」「人間がやること」を明確にする AIに全て任せるのではなく、人間の判断が必要な部分を意識する。 （リテラシーの必要性を痛感するフェーズです） 業務にAIを組み込む 出力に納得できたら「 この業務は生成AIに 」を決めて次回以降は必ずAIを使用する。 （生成AIを 頼れるメンバー として認めるフェーズです） 試してみたい具体的なプロンプト例3つ 会議の効率化プロンプト 来週の進捗会議（参加者：マネージャー、開発担当、デザイナー、マーケティング担当）のためのアジェンダを作成してください。 目的は、現在の進捗確認と課題の洗い出しです。特に議論すべき重要な点と、各トピックの目安時間も含めてください。全体で45分に収めたいです。 2. リスク分析プロンプト ： 新規Webサービス立ち上げプロジェクト（予算300万円、期間3ヶ月、チーム5名）において考えられるリスクを分析してください。 技術面、スケジュール面、予算面、人員面の各観点から考えられるリスクと、その対策案を優先度順にまとめてください。 3. 技術資料の理解促進プロンプト ： 以下のAPIドキュメント概要を、プログラミング初心者でも理解できるように噛み砕いて説明してください。 特に、基本的な使用方法と具体的な実装例を示してください。 [APIドキュメント概要を貼り付け] まとめ：技術と非技術の架け橋としての生成AI 「使う視点」と「作る視点」の協働がもたらす可能性 生成AIの真価は「技術そのもの」と「その活用法」の両論にあります。 技術者は「どうやって作るか」に注力し、非技術者は「どう使うか」に知恵を絞る。そして両者が協働することで、AI活用の可能性は最大限に広がります。 特に期待されるのは、技術者と非技術者の間のコミュニケーションギャップを埋める役割です。AIが共通言語となることで、お互いの専門性を尊重しながら協働できるようになります。 最後に、生成AIリテラシーの基本は「道具としてのAI」という視点です。”金槌”を使う大工さんが金槌の内部構造を詳しく知らなくても素晴らしい家を建てられるように、AIの内部構造を詳しく知らなくても、それを使いこなして素晴らしい成果を生み出すことはできます。 同時に、より良い金槌を作るために金属工学の知識が役立つように、AIの仕組みについての理解が深まれば、その活用法もより洗練されていきます。 技術者も非技術者も、それぞれの強みを活かしながら、生成AIという道具を使いこなしていくことで、私たちの働き方はより創造的で、より価値の高いものになるはずです。 最後までお読みいただき、ありがとうございました。 ▼関連記事「Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた｜知識ゼロから始めた学習方法と試験対策」はこちらです。 関連記事 Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた｜知識ゼロから始めた学習方法と試験対策 こんにちは。Sqripts編集部のハチワレと申します。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。「非エンジニア」を称しています。今回は、非エンジニアの私がGoogle Cloudの認定資格、Generati... 　続きを読む　 Sqripts The post 生成AIの基礎リテラシーと明日から業務で使える活用術 first appeared on Sqripts .

こんにちは！みなさん、テストしてますか？ 第2回の前編 では、E2Eテストの基幹部分とも言える 要素探索 の技術の変遷について扱いました。中編では、前編の内容も踏まえつつ、様々な実装技術について説明していきたいと思います。 記事一覧：モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- 実装技術の変遷 ここで言う実装技術とは、例えば第1回でテストコードを作成するのに使った Playwright Codegen のようなものを指します。単にテストコードを書くだけでなく、機械的にテストコードを生成する技術だったり、テストコードの可読性を上げるための書き方を考えたりなど、様々な試行錯誤が現在進行系で行われています。この記事では、筆者が知るいくつかの代表的な手法を取り上げたいと思います。 レコードアンドリプレイ レコードアンドリプレイは、テスト対象のアプリケーションへの操作を「記録し、再生する」手法です。キャプチャアンドリプレイ、レコードアンドプレイバックなどとも呼びます。普段GUIを操作するのと全く同じ感覚で自動テストを実装できるので、非常にとっつきやすく、コーディングの知識がまるで無い人にとっても扱える他、ツールそのものへの学習も最小限に出来るのが特徴です。 原理としては、テスト対象のアプリケーションに記録用のコードを埋め込み、クリックや文字入力、スクロールなどのイベントを逐一記録していく、といったものです。 上記のように、誰でも簡単に使える反面、細かく記録しすぎてしまうことによるテストの不安定さや、生成されるテストコードの質が悪くメンテナンス性が著しく悪い、などの課題がありました。 特に、生成されるコードの質のところでは、当時使われていたページ表現の記法がCSSセレクターやXPathなどの内部構造であったこともあり、記録されたコードを後で読み返すと何をやっているのか良くわからない、ということもしばしばでした。 レコードアンドリプレイを採用するツールは多数ありますが、有名なのは Selenium IDE でしょう。その他 Ghost Inspector なども存在します。 Selenium IDE Ghost Inspector レコードアンドリプレイはなぜダメだったのか 先述の通り、レコードアンドリプレイツールはたびたび批判の憂き目に合っています。書籍『システムテスト自動化標準ガイド』 ※1 では、一章まるごと使ってこの手法への批判を記載しており、当時いかにこの手法によって苦しむ人が多かったのかが垣間見えます。 ※1『 システムテスト自動化 標準ガイド 』（Mark Fewster、Dorothy Graham 著／テスト自動化研究会 訳／翔泳社） レコードアンドリプレイの欠点として良く挙げられるのは以下のような点です。 記録されるロケーターの可読性が低かったり、ちょっとしたページの構造の変化に弱かったりする スクロールなど不要なステップの記録が多く、実行の不安定さにつながる テストコードが構造化されておらず、再利用性が低い ですが、みなさんは第1回ですでにレコードアンドリプレイを経験して、（簡単な例ではあるものの）素早くテスト自動化ができることを実感していますね。また、(1) については第2回の前編でセマンティクスベースの要素探索により、可読性が高くページの構造の変化に強いロケーターを作れることを知っています。 (2) についても、第1回で使った Playwright Codegen ではスクロールなどのステップは記録されておらず、余計なステップの記録はさほど発生しないことが分かったかと思います。 (3) については、それぞれのツールごとに考え方が異なりますが、後に記載するPage Object Model(POM)形式での構造化が一般的に使われており、サポートしているツールも多いです。 というわけで、過去にレコードアンドリプレイが使い物にならなかったのはコンセプトが悪かったからではなく、技術的に追いついていない部分が多かっただけというのが筆者の結論です。実際、Playwrightのようなツールにもビルトインされていますし、最近流行りのAIツールでもレコードアンドリプレイ形式を採用しているものは多いです（AIが操作した内容をレコードアンドリプレイで記録する、なんてツールもあります）。 キーワード駆動テスト さて、レコードアンドリプレイでは操作を記録することでテストを作りましたが、キーワード駆動テストではキーワードと操作対象、データを組み合わせてテストを書きます。例えば、次のようなイメージです。 キーワード ロケーター データ ページを開く – http://example.com 文字を入力する textbox#email john.example.com 文字を入力する textbox#password password クリックする span#button – 少しでもプログラミングをかじったことがある方なら、なんとなくこの記法がプログラミングと自然言語の合いの子のように見えるかもしれません。 このように、ある特定の分野（ドメイン）の課題を解決するために使われる、人間にとって読みやすく機械にとっても処理しやすい言語を DSL(Domain Specific Language) と呼びます。つまり、キーワード駆動テストはE2Eテスト用のDSLです。 読みやすい一方、出来ることがDSLとして定義されたもののみに絞られてしまうことが難点です。また、場合によっては操作対象のロケーターを読みやすくするためにたくさんのエイリアスを設定しなければならず、テストのための実装が必要以上に増えてしまい、テストを書き始めるまでの労力が比較的大きいです。 キーワード駆動テストを採用するツールの代表例として、 Robot Framework というものがあります。また、JavaScriptの文法の中でキーワード駆動のDSLのようなものを実現した珍しいツールで CodeceptJS というものもありますので一緒に紹介しておきます。 Robot Framework CodeceptJS ページオブジェクトモデル ページオブジェクトモデル（以下POM）は、一つのページに関連する要素と操作をひとまとめにしたものです。例えば、ログインページのページオブジェクトモデルは次のようになります。 // loginPage.js class LoginPage { /** * @param {import('@playwright/test').Page} page */ constructor(page) { this.page = page; this.emailInput = page.locator('#email'); this.passwordInput = page.locator('#password'); this.loginButton = page.locator('#login-form button.submit'); } async goto() { await this.page.goto('https://example.com/login'); } async fillEmail(email) { await this.emailInput.fill(email); } async fillPassword(password) { await this.passwordInput.fill(password); } async submit() { await this.loginButton.click(); } async login(email, password) { await this.fillEmail(email); await this.fillPassword(password); await this.submit(); } } module.exports = { LoginPage }; すると、テストコード側からは LoginPage という名前で、ページ内で使われる様々な要素と、ログインなどページ内で利用するアクションを定義できます。 // example.spec.js const { test, expect } = require('@playwright/test'); const { LoginPage } = require('./loginPage'); test('ユーザーがログインできる', async ({ page }) => { const loginPage = new LoginPage(page); await loginPage.goto(); await loginPage.login('john@example.com', 'securePassword!'); // たとえばログイン成功後に表示されるテキストを確認 await expect(page.locator('text=ようこそ')).toBeVisible(); }); 利点としては、キーワード駆動テストと同様にページ内のロケーター記述を隠蔽できる点と、「ログイン」などの一連の操作をひとまとめにしたショートハンドを作成してテストコードの記述を省力化できる点にあります。また、特定のページに対する操作であることが一目で分かるため、コードの可読性向上にもつながります。加えて、ページの構成が変わった場合などにも、POMだけを直せば良いので、メンテナンス性が向上します。 反面、キーワード駆動テストと同様、POMそのもののメンテナンスが煩雑になりがちです。POMはページ内の要素とアクションを抽象化したものです。言い換えると、POMを定義することは、アプリケーションのUIそのものの実装と、そのページの見た目と操作方法を定義するテスト用の実装の2つを作る必要があります。これは典型的なダブルメンテで、面倒に思う場合も多いでしょう。 BDD(振る舞い駆動テスト) BDD（振る舞い駆動テスト）は、その名の通りアプリケーションの「振る舞い」に着目した実装方法です。代表的なツールは Cucumber です。 Cucumber BDDでは、アプリケーションの振る舞いを自然言語に近い形で記述した Feature と、実際にテスト対象を自動操作するための Step Definition ファイルに分けて記述します。 Feature Feature: ユーザーログイン機能 ユーザーとして システムにログインしたい なぜなら、個人の情報やサービスにアクセスするため Background: Given ログインページが表示されている Scenario: 正しい認証情報でのログイン成功 When 有効なメールアドレス "user@example.com" を入力する And 正しいパスワード "password123" を入力する And "ログイン" ボタンをクリックする Then ダッシュボードページにリダイレクトされる And "ようこそ、user@example.com さん" というメッセージが表示される Step Definition Given('ログインページが表示されている', async function() { await driver.get('http://localhost:3000/login'); // ページタイトルを確認してログインページであることを検証 const title = await driver.getTitle(); expect(title).to.include('ログイン'); }); When('有効なメールアドレス {string} を入力する', async function(email) { const emailField = await driver.findElement(By.id('email')); await emailField.sendKeys(email); }); When('正しいパスワード {string} を入力する', async function(password) { const passwordField = await driver.findElement(By.id('password')); await passwordField.sendKeys(password); }); When('ログインボタンをクリックする', async function(buttonText) { await driver.findElement(By.id('login-button')); await loginButton.click(); }); // 検証系ステップ - 成功パターン Then('ダッシュボードページにリダイレクトされる', async function() { const currentUrl = await driver.getCurrentUrl(); expect(currentUrl).to.include('/dashboard'); }); Then('{string} というメッセージが表示される', async function(expectedMessage) { const actualMessage = await welcomeMessage.getText(); expect(actualMessage).to.equal(expectedMessage); }); 技術的には、BDDはアプリケーションの振る舞いを表した Feature ドキュメントと、テスト対象を自動操作する Step Definition コードとを組み合わせたものです。ですが、実際にはBDDを単なる技術として扱ってしまうと冗長な部分が多く、開発のオーバーヘッドになりかねません。 BDDはキーワード駆動テストのようにDSLでテストコードを記述する手法ではなく、要求仕様から開発をスタートし、要求仕様を表現するテストを中心に開発を駆動するためのプラクティスです。テストコードとは別に Feature を独立した自然言語のドキュメントとして切り出すのは、開発者だけでなく様々なステークホルダーと一緒に要求仕様を詰め、誤解を最小限にしたうえで開発を進めるためです。 また、BDDは必ずしもE2Eテストだけのものではなく、単体テストなどでもよく用いられます。ただし、コードレベル（単体テスト）の振る舞いとユーザーレベル（E2Eテスト）の振る舞いとでは異なる部分が多いため、ユーザーレベルのBDDを特にATDD（受け入れテスト駆動開発）と呼ぶ場合もあります。 実装手法の移り変わりと再評価 ここに挙げた自動テスト実装手法は、必ずしもどれが正しいとか、どれが最新だとかというものではありませんが、他の周辺技術の影響などを受けて多少の流行り廃りがあります。 例えば、最初に挙げた「レコードアンドリプレイ」という実装方法は、節の中でも記載していた通り、ある時代には非常に使うユーザーが多かったのですが、その後メンテナンス性の低さなどから批判を受け、キーワード駆動型の記述に乗り換えました。 一方で、ここ数年よく使われている、AIを利用した自動テストツールの多くはレコードアンドリプレイを採用しているケースが多いです。これは、レコードアンドリプレイは直感的で使いやすいという理由だけでなく、記録した要素やユーザー操作から様々な情報を得て自動テストに活かせるという、コンピューターによるコード生成ならではの利点があります。 そのため、「書籍で紹介されていたから」「ベストプラクティスらしいから」という理由で安易に実装方法を選んでしまうのでは危険です。チームの成熟度や手法の特性などを考慮しながら技術選定を進めると良いでしょう。一番のおすすめは、とにかく全部一度触ってみてから、一番しっくりくるものを使ってみることです。 まとめ この中編では、様々な実装技術について扱いました。後編では、より根幹となる 自動操作 の技術と、E2Eテストの 目的 の変遷について解説したいと思います。 【連載】モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回・前編】E2Eテストの歴史 -要素探索技術の変遷- 【第2回・中編】E2Eテストの歴史 -様々な実装技術- The post 【第2回・中編】E2Eテストの歴史 -様々な実装技術- first appeared on Sqripts .

こんにちは！みなさん、テストしてますか？ 第1回では、まずはとにかくやってみようということで、VSCode拡張を使いながら簡単なE2Eテスト自動化にトライしてみました。初歩の初歩とはいえ、自動化がどんなものなのか、ざっくりイメージはついたのではないでしょうか。 記事一覧：モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回-前編】E2Eテストの歴史 -要素探索技術の変遷- 第2回では、前・中・後編に分けて、E2Eテストを取り巻くパラダイム（考え方）や、使われるツールがどのように変わってきたのかについて書いていきます。この前編では、E2Eテストの重要な要素技術である「要素探索」の変遷について深堀っていきたいと思います。 なお、筆者自身は2017年ごろから自動テストに関わってきた身ですので、実は歴史を語るにはちょっと経験不足かもしれません。コメントがありましたらSNSなどでご連絡頂けますと助かります！ そもそもE2Eテストとは E2Eテストとは「完全に統合済みのシステムを、ユーザーインターフェース（特にGUI）から操作する」テストのことを指します。 完全に統合済みというのは、システムを構成する様々なコンポーネントが全てビルドされた状態のことを指します。この特徴から、システムテストと呼ばれることもあります。 ユーザーインターフェースからというのは、ユーザーが実際にシステムを利用する際のインターフェースを用いるということを指します。この観点から、受け入れテストと呼ばれることもあります。 E2Eテストの目的 E2Eテストの主な目的は、実際に提供されるシステム上で（あるいは、非常に近い構成の上で）ユーザーがビジネスケースを達成できるかどうかを検証することです。 例えば、ECサイトであれば、以下のようなビジネスケースが考えられるでしょう。 ログイン〜購入まで 商品を返品できる 発送前の商品はキャンセルできる これらのビジネスケースを、実際のシステムに近い構成でテストするのがE2Eテストです。これにより、単体テスト・結合テストのような小さい単位のテストでは見つけづらいコンポーネント間の齟齬や、各機能レベルでは問題なく動作するがビジネスケースは達成できない、といった問題を解決できます。 例えば、上記のECサイトの例なら、ログイン、カートに追加、購入といった機能レベルでは問題なく実装されているものの、住所の新規登録が出来ないので購入に進めない、といった問題を見つけることができます（さすがに、素朴すぎるケースではありますが、一例ということで）。 また、最近はWeb・モバイル問わず、クライアントとサーバーが相互に通信し合う構成のアプリが多いです。Webフロントエンドとバックエンドをそれぞれ個別に作って、実際の構成では様々なエラーが出ることもあるでしょう。こうした問題を見つけることもE2Eテストには期待されています。 要素探索技術の変遷 さて、E2Eテストとはどういうものか？についておさらいできたところで、ここからはE2Eテストの重要な技術である 要素探索 技術の変遷について見ていきましょう。 第1回のテストコードの中でも、要素探索は繰り返し出てきます。例えば、サンプルToDoアプリのテキストボックスをクリックするためのコードは、こんな感じで書かれていました。 TodoMVCのテキストボックス await page.getByRole('textbox', { name: 'What needs to be done?' }).click(); このうち、 getByRole('textbox', { name: 'What needs to be done?' }) という部分が要素探索に当たります。 実は、この getByRole を用いた探索方法はここ数年で出てきた比較的新しい手法です。そのため、ちょっと古めの本などを読むと全然違うことが書いてあったりします。 getByRole はなぜ利用を推奨されているのか、他の方法とどう違うのかを理解するために、どんな変遷を辿ってきたのかについてこの記事でおさらいしておきましょう。 内部構造を用いた要素探索 例えば、テスト対象がWebアプリケーションのログインフォームだとします。 <form method="post" action="/login"> <label for="email"> メールアドレス </label> <input id="email" /> <label for="password"> パスワード </label> <input id="password" /> <span id="button" class="login-btn">送信</span> </form> メールアドレス入力欄、パスワード入力欄、ログインボタンがあります。 これらのUI要素に、文字入力やクリックなどのアクションを行うためには、まずこれらの要素をHTML内（正確にはDOMツリー内）から探さなければいけません。ロケーターとは、この探索を行うために使う一意のキーのことを指します。 先ほどのHTMLに対してテストコードを書く場合、 CSSセレクター や XPath などのものを使ってそれぞれの要素を取得することができます。例えば、 CSSセレクター を使ってメールアドレスを取得するためのコードは以下のようなものになります。 #email という書き方で、 id が email のもの、という意味になります。 await page.locator("#email") ところで、この id とは何のために使われるものでしょう？ウェブ開発者向けの技術ドキュメントサイトであるMDNによると、 id は以下のような目的で使われるものと書いてあります。 ID 属性の目的は、リンク（フラグメント識別子を使用）、スクリプト、またはスタイル設定（CSS を使用）の際に、単一の要素を識別することです。 https://developer.mozilla.org/ja/docs/Web/HTML/Reference/Global_attributes/id#%E8%A7%A3%E8%AA%AC つまり、 id 属性はページ内で使われるJavaScriptやCSSのために使われるもので、これらの都合で変更される可能性があるわけです。 より具体的に言うと、上記のログインフォームは id の値を元にバックエンドサーバーにデータを送ります。そのため、バックエンドサーバーの仕様が変わった場合、フォームも変わる可能性があります。一例として、バックエンドサーバーが受け取る変数名が email から mailaddress に変わった場合、ログインフォームは以下のように変わります。 <form method="post" action="/login"> - <label for="email"> メールアドレス </label> - <input id="email" /> + <label for="mailaddress"> メールアドレス </label> + <input id="mailaddress" /> <label for="password"> パスワード </label> <input id="password" /> <span id="button" class="login-btn">送信</span> </form> もちろん、これに対応して、テストコードも変えなければいけません。 - const inputEmail = getElementById("email") + const inputEmail = getElementById("email") ですが、E2Eテストの本来の目的と照らし合わせると、このように内部構造の変化の影響をテストコードが受けるのはおかしいはずです。E2Eテストの目的は ユーザーがビジネスケースを達成できるかどうか のはずなのに、目的が変わらないのにテストコードを直さないといけなくなってしまいます。これでは本末転倒です。 テスト用のIDを用いた要素探索 そこで、内部構造の代わりに、テスト用に一意のIDを振ろうという考え方が現れました。例えば、 data-testid という属性を定義し、それをテスト用に使うことができます。 <form method="post" action="/login"> <label for="email"> メールアドレス </label> <input id="email" data-testid="email" /> <label for="password"> パスワード </label> <input id="password" data-testid="password" /> <span id="button" class="login-btn" data-testid="submit">送信</span> </form> この場合、テストコードは次のように書けます。 await page.locator('[data=testid="email"]') // 属性名が data-testid の場合は、 // Playwrightのショートハンドで次のようにも書ける await page.getByTestId('email') data- から始まる属性は データ属性 と呼ばれており、どんな属性も自由に定義でき、原則としてアプリケーションの振る舞いに影響を与えません。そのため、テスト用のIDを振るという用途にはぴったりです。 便利な半面、結局データ属性を個別に定義しないといけなくなってしまい、手間が増えることに変わりはありません。また、データ属性はユニークである保証が無いため、ページ内に同じデータ属性が複数存在する場合に、テストが不安定になる場合があります。例えば、一つのページに新規登録フォームとログインフォームがある場合、 data-test="email" が2つあると、ログインフォームのテストをしているつもりが実は新規登録フォームに入力していた、なんてことも考えられます。 セマンティクスを用いた要素探索 ところで、 id や class のような内部属性にしろ、 data-test のようなテスト用の属性にしろ、突き詰めると ユーザーにとっては何の関係もない値 です。ユーザーは「メールアドレス」と書いてあるフォームに文字を入力するのであって、 id や data-test に email と書いてあるフォームに文字を入力するわけではないからです。そのため、E2Eテストの大原則である「ユーザーがビジネスケースを達成できることの検証」という目的と照らし合わせると、とても不自然なことをしています。 この点をカバーするため、2025年現在では要素の セマンティクス（意味） を用いた要素探索手法が広く用いられています。アクセシビリティ支援技術の中には、例えばスクリーンリーダーのような「ページに表示されている情報を様々な方法でユーザーに伝える」ための技術があります。GUIのような視覚的に理解できるインターフェースを、ページの構造やUIコンポーネントの役割、表示されているテキストなどを用いて様々な形でユーザーに伝えます。 こうした支援技術が用いるデータは、ユーザーの目線からページを見た際の 意味 を機械的に表現したものが多いです。Webページでセマンティクスを表現する方法はいろいろありますが、一例として ボタン を表す方法をいくつか挙げましょう。 <input type="button" name="OK" /> <button>OK</button> <span role="button" aria-label="OK">OK</button> これらはすべてスクリーンリーダー上では OK というラベルを持った ボタン として振る舞います（※厳密には、3つ目の例はTabキーによるフォーカスが当たらない、Enterキーによる押下ができないなど、いくつか制約があります）。 仮に、これらの要素を 内部属性 を用いて探索する場合、それぞれ別の書き方をする必要があります。 await page.locator('input[type="button"][name="OK"]'); await page.locator('button:has-text("OK")'); await page.locator('span[role="button"][aria-label="OK"]'); ですが、 セマンティクス を用いる場合、一つの書き方で三つすべての要素にマッチします。 await page.getByRole('button', { name: 'OK' }); セマンティクスを手がかりに要素を探索することで、よりE2Eテストらしい、ユーザー目線のテストを書けるようになります。また、UIのセマンティクスを整備することによって、スクリーンリーダーなどのアクセシビリティ支援技術がUIを理解しやすくなる効果もあります。 まとめ 前編ではE2Eテストそのものの説明と、GUIを扱うという性質上重要になってくる要素探索についての解説を行いました。 次回、中編では、自動テストそのものの実装技術について触れたいと思います。 【連載】モダンなE2Eテストの考え方をマスターしよう 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） 【第2回-前編】E2Eテストの歴史 -要素探索技術の変遷- The post 【第2回-前編】E2Eテストの歴史 -要素探索技術の変遷- first appeared on Sqripts .

こんにちは。クオリティマネージャーの”黒山羊さん”です。 前回 は生成AI作成の議事録を補完する 議事メモ の取り方について書かせてもらいました。 これまで私は生成AIでの議事録作成を試したことがなく、生成AIを使った議事録作成はお客様が行ったり、チームメンバーが行ったりしていました。 チームメンバーの作成した議事録が、お客様作成のものと比べて綺麗にまとまっていたので、何か秘訣があるかと聞いたら、ちょっとしたコツを教えてもらいました。 それを聞いて自分でも生成AIを使ってみたところ、思った以上に簡単に議事録作成が出来ました。 このブログは私と同じように生成AIを使っている人が周りにチラホラ出てきて、自分も使ってみようかな。でも、初めてだとちょっと踏ん切りがつかないな。 そういう人に向けて書きました。 使用する生成AIと環境 まず、私が使用した生成AIと会議ツールをお伝えします。 生成AI ：Copilot 会議ツール ：Teams 業務PCがWindowsであれば、どちらも簡単に使用することが出来るものです。 他に生成AIはChatGPTが有名ですが、今回のような議事録作成はCopilotの方をお勧めします。 以下の表はCopilotに聞いた、ChatGPTとCopilotの比較です。 項目 ChatGPT（OpenAI） Copilot（Microsoft） 創作・文章生成 小説、ブログ、SNS投稿などの自然な文章が得意 ビジネス文書や要約は得意だが、創作性はやや控えめ 会話の自然さ 長時間の対話や雑談がスムーズ 実務寄りで、やや堅めの応答が多い プログラミング支援 多言語対応でコード生成・デバッグが得意 コード生成も可能だが、Office連携が主軸 カスタマイズ性 ユーザーの好みに合わせて育てやすい Microsoft製品との統合が前提で柔軟性は限定的 対応分野の広さ 教育、創作、趣味、雑談など幅広い ビジネス・業務効率化に特化 CopilotはOffice連携が得意であり、カスタマイズなどする必要なく作成した議事録を直接Word形式で出力することが出来ます。 ChatGPTでもアドインやプラグインを入れることでWord等と連携することも可能ですが、今回のように議事録作成しWord形式で保存するならCopilotの方が向いていると思います。 生成AIを使用した議事録の作り方（基本編） 1. Teamsで会議を実施し、文字起こしを行う Teamsで会議が始まったら、メニューの「その他」をクリックし、「レコーディングと文字起こし」→「レコーディングを開始」を選択する。 （会議設定時にレコーディングを自動的に開始することも可能です） 2. 会議が終了したらトランスクリプト（文字起こし）をダウンロードする 会議が終了したらTeamsのメニューから「チャット」を選び、先程まで行っていた会議チャットを選択。 コンテンツとして「トランスクリプト」が表示されているので、それをクリック。 出てきた画面より、「ダウンロード」を選択し、「.docx 形式でダウンロード」をクリックすれば、自分のローカルにダウンロードされます。 3. Copilotにトランスクリプトを渡し議事録を作成する 　Copilotを立ち上げ、先程のトランスクリプトをドラッグアンドドロップ。 　アップロードされるのを待って、「議事録を作って」と打ち込む。 　すると、要約された議事録が表示される。 4. 出力された議事録を確認し、適宜修正する 人の名前やサービス名、会社名などの固有名詞は間違っていることが多々あります。 そんな場合は「〇〇を△△にして」とお願いすれば、文言を直した議事録にしてくれます。 例：「苦労ヤギを黒山羊にして」 複数個所の修正が必要な場合は「、」でつなげれば1回で修正してくれます。 例：「苦労ヤギを黒山羊、ホワイトゴートをWhiteGoatにして」 5. 生成された議事録をWord形式で出力する 4. で生成された内容でよければ、「Wordで出力して」と打ち込めば、Wordファイルが表示されるので、それをダウンロードする。 以上で、Teamsの文字起こしから議事録がWordファイルで作成されました。 生成AIを使用した議事録の作り方（応用編） 基本編で議事録は出来ましたが、欲しい形式とは異なる場合もあると思います。 その場合はCopilotにお願いする内容を具体的にすると、より欲しいものに近づけることが出来ます。 例：「宿題事項と要点をまとめて議事録を作って」 　　 「要点を箇条書きにして議事録を作って」 などです。 また、結論や決定事項をまとめたい場合も、お願いするとAIがまとめてくれます。 例：「決定事項をまとめて」 他にも特定の発言者の意見を振り返りたいならその旨お願いすれば、改めてトランスクリプトから発言を抽出してくれます。 例：「黒山羊さんの手紙に関する意見についてピックアップして」 なお、白熱した会議でトランスクリプトが大きくなった際、何度試しても読み込みエラーになることがあります。（体感2時間超の会議でエラーになります） トランスクリプトを分割して、議事録作成を行うなどの工夫が必要です。 例：分割したトランスクリプトをまとめて読み込ませ、「2つのファイルをまとめて、議事録を作って」 ※分割したトランスクリプトを1つずつ読み込ませて議事録作成し、後でつなげることも可能 生成AIは何度でも修正してくれるので納得いくまで出力内容を見直してみましょう その他、作成手順で詰まったところ 上記の作成手順で、Copilotに聞く以前に詰まったところがあった為、備忘のため記述します。 ◆Teams会議が終わったのに「トランスクリプト」が表示されない 会議終了前にレコーディングを止めず、会議に誰かが残ったままだと、トランスクリプトが表示されません。 その場合は会議から全員出るまでしばらく待って見てください。 ◆「トランスクリプト」は表示されたがダウンロード出来ない （権限割り当てをしていない場合）「トランスクリプト」のダウンロードが可能なのは、会議の主催者のみです。 ダウンロードできない場合は主催者に取得をお願いしてください。 おわりに やってみると思った以上に簡単に議事録作成することが出来ました。 具体的な指示が必要だったり、文言の微調整は必要だったりしますが、それでも自分で議事録をまとめていた頃とは比較にならない労力で議事録作成出来ることに感激です。 また、自分で生成AIを使用して議事録を作るようになってからは、 会議の発言もより5W1Hを意識したり、具体的な意見を心掛けるようになりました。 よかったら皆さんも生成AIを使って、仕事を楽にしていきましょう！！ 参考書籍 この一冊で全部わかる　ChatGPT & Copilotの教科書 The post 生成AIによる議事録作成ABC -TeamsとCopilotを使って- first appeared on Sqripts .

前回 は、QAイネイブリングを進めた先におけるQAエンジニアの動き方・位置づけの変化についてお話しました。QAエンジニアから他のロールへの技術移転を行っていくとQAエンジニアは不要になるのか、という問いに対し、 ニーズは変化しつつも不要にはならないはず イネイブリング後の姿を描くことが大切である というのが私の考えです。 今回は、この「ニーズの変化」への対応や、いわゆる「この先生きのこるには」に関連して、QAエンジニア側はどうすればよいのかを考えていきましょう。 ＜QA活動のスキル伝達「イネイブリングQA」　記事一覧＞ ※クリックで開きます 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 【第3回】開発組織に品質技術を伝えるための2つのスキル 【第4回】品質技術をイネイブリングした先はどうなる？ 【最終回】イネイブリングQAは肩代わりではなく先回り 開発者へのイネイブリング圧と、QA側に求められること 本連載の第2回 で、開発者への「イネイブリング圧」について触れました。 とくに昨今は開発者に対してさまざまなロールからさまざまな知識・スキルを移転される傾向にあります。そのぶん開発者に求められることが増え、効率化しているはずが忙しくなってしまうことも多いように思います。QAエンジニア側からイネイブリング活動を行う際には、この点に注意が必要です。 そして開発者は色々なことをイネイブリングされているわけですから、「自分たちが品質に関するスキルや知識を得て業務に活かすべきなのはわかった。では、QA側はどんなスキルや知識を得て業務に活かすの？」と考えても、不思議ではありません。とくにシフトレフトを掲げてテストの実務の一部を開発者に移譲している場合などは、このような意見が出そうです。 イネイブリング≠タスクの再分配 QAから開発者にタスクが移ったのであれば、そのぶん開発タスクの一部を担ってくれよ、という気持ちを抱くのは自然です。イネイブリングとは無関係なところでも、一般にQA・テストチームができるだけ開発者を頼らず（手を煩わせず）に色々な業務ができるようにしよう、という動きは存在します。 たとえばDBへのアクセスを可能にしてもらって、テストデータの準備や環境のリセットをQA自身が行えるようにクエリの書き方を身につける、等ですね。 しかしここで確認しておきたいのは、イネイブリングはけっしてタスクの再分配ではないということです。 これまでの連載で、イネイブリングQAについて 開発チームに対して自分たちがQA業務を直接担うのではなく 従来であればテストエンジニアやQAエンジニアが行っていた業務の一部やそれを行うためのスキルを 開発者に移譲していく取り組みおよびそれを行うQAエンジニア のこと、と説明してきました。 このうち、業務やタスクの実行主体を移していくことのみにフォーカスしてしまうと、イネイブリングで本来実現したいことから逸れていってしまいます。イネイブリングは知識やスキルの移転を伴う点が大事で、単なるタスクの剥離と別ロールへの再分配ではありません。 アジャイルテスターの動き方 では、QA→開発者など他ロールという 一見 一方通行の移転に対する直接的な回答にはなっていないように見えてしまう状況について、どのように考えればよいのでしょうか。 書籍『アジャイルサムライ』 ※ にはアジャイルチームにおけるテスターの動き方が出てきます。これは原著が2010年、邦訳が2011年に出版された本ですが、今回考えているイネイブリングQAに関するヒントになりそうな点が載っています。（書籍上はアジャイルテスターという表現ですが、これらの点はテスターやテストエンジニアに限らずQAエンジニアに対しても通じるものです。） アジャイルテスターの仕事として、以下の例が挙げられています。 ユーザーストーリーのテストを書くのを手伝う ストーリーが期待通りに動くことを確認する テストの全体像を考える これらの仕事は、2025年時点ではアジャイル開発か否かを問わず、QA・テストエンジニアに対して当たり前に求められている部分です。たまに「QAがテストだけをしていれば良い時代は終わった」と言われることがありますが、（そのような時代があったかどうかはさておき）主戦場とみなされがちなシステムテストに限らず、広い範囲での活動が求められます。 また、アジャイルチームにおける役割の前提として、以下のようにも書かれています。 アジャイルなソフトウェア開発プロジェクトでは役割分担がはっきりとは分かれていない。（中略） プロジェクトの成功に寄与することなら何だって協力する。肩書も役割も関係ない。もちろん、その人ならではの強みというものはある。しかし一方で、人は自分の得意分野にこだわりすぎる傾向もある。だからアジャイルプロジェクトでは、あらかじめ細かく定義された役割というものは用意しない。アナリスト。プログラマ。テスター。少なくとも、旧来の意味合いでのこういう役割は存在しないと思ってもらっていい。 アジャイルサムライ――達人開発者への道 完全に役割分担のないチーム、というのはそれほど多くはないと思います。しかし上記の記述は、2025年現在のソフトウェア開発組織やその中における役割分担に関する世の中の傾向とも合致しているのではないでしょうか。各ロールの担う範囲が拡大し、役割分担の境界が曖昧になり、まさにそれぞれが「プロジェクトの成功に寄与することなら何だって協力する」ことを求められているか、もしくはそのような状態を目指している開発組織も増えていそうです。 ※ アジャイルサムライ――達人開発者への道 Jonathan Rasmusson 著／西村直人・角谷信太郎 監訳／近藤修平・角掛拓未 訳／オーム社 肩代わりではなく先回りをし続ける存在がイネイブリングQA ここまでの話を整理します。 イネイブリングQAの活動を進めていくと、QA→開発者という向きのイネイブリング＝知識・技術や業務の移転が行われます。だからといって逆向き、すなわち開発者→QAという向きで同じくらいの 業務を移転しよう 、と考えてしまうとイネイブリングで実現したい組織全体の向上からは逸れてしまいます。そのようなタスクの再分配を行うのではなく、10年以上前に『アジャイルサムライ』等で書かれていたように、各ロールの役割にとらわれずに範囲を拡大しプロジェクトのために何でも行うべきです。 イネイブリングは、皆がプロジェクトのために何でもできるように、知識・スキルを移転する活動、といえるでしょう。ここで大事になってくるのは、肩代わりではなく先回りをしよう、という発想だと思っています。つまり、たとえばテスト技法を開発者に伝えられたらイネイブリングは完了！のような区切りがあるものではなく、イネイブリングは「ずっと行い続けるもの」なのではないか、というのが今時点での私の考えです。 前回の記事および本記事冒頭でもふれた「個々のQAエンジニアが生き残るために必要なのはなにか」がまさにこの点です。これを身につければOK、という事項は存在せず、そのときどきでチームに必要な（しかしまだチームとして身についていない）ことを率先してキャッチアップし、チーム全体に対してイネイブリングすること。そしてそれを継続すること。これが生き残る方法のひとつです。 昨今は人手不足や開発組織の体制などの都合もあり、私個人の体感としては、一定規模のテスト・QA専門のチームを設ける会社の割合はあまり増えていないように感じています。結果として、イネイブリングができるQAのニーズがじわじわと増えていると思っています。 皆様の組織でQAのイネイブリング活動を行う際に本連載が参考になれば幸いです。また、ぜひ全体としてのQAイネイブリング活動自体の質向上のため、いろいろな会社での事例やナレッジの共有をいただきたいと思っています。 【連載】QA活動のスキル伝達「イネイブリングQA」 記事一覧 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【全文公開中】 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 【第3回】開発組織に品質技術を伝えるための2つのスキル 【第4回】品質技術をイネイブリングした先はどうなる？ 【最終回】イネイブリングQAは肩代わりではなく先回り 【Sqripts編集部より】 伊藤由貴さんの連載記事『QA活動のスキル伝達「イネイブリングQA」』はいかがでしたでしょうか。 読者のみなさまからの感想や今後の連載のリクエストをぜひお寄せください！ Sqriptsお問い合わせ 、または 公式Xアカウント のDMでも受け付けています。 The post 【最終回】イネイブリングQAは肩代わりではなく先回り｜QA活動のスキル伝達「イネイブリングQA」 first appeared on Sqripts .

こんにちは。Sqripts編集部のキジトラです。 組織におけるパスワード管理、第4回目となる今回は「 MITRE ATT&CK ※ フレームワークに見るパスワード管理 」についてです。 サイバー攻撃は日々巧妙化しており、その中でもパスワードは攻撃者にとって格好の標的となります。本記事では、サイバー攻撃の戦術やテクニックを体系的にまとめた「MITRE ATT&CKフレームワーク」を基に、攻撃者がどのようにパスワードを悪用するのか、その手口と対策について詳しく解説していきます。セキュリティ戦略を考える上で、参考にしていただければ幸いです。 ※ MITRE ATT&CK ：読み方「マイターアタック」 MITRE：アメリカの非営利団体である MITRE Corporation ATT&CK：「 A dversarial T actics, T echniques, and C ommon K nowledge（敵対者（攻撃者）の戦術、技術、および共通知識）」の略 MITREのフレームワークとは 正式には「MITRE ATT&CK」と記載され、MITREという非営利組織が作成しているフレームワークを指します。このフレームワークでは、CVE ※ を基に実際のサイバー攻撃を複数のプロセスに分け、各プロセスで用いられる戦術やテクニックに関する詳細情報を提供しています。 これらの情報を活用することで、組織は自組織が特に注意すべきハッカーグループを特定し、そのハッカーグループが得意とする攻撃手法・ツールを把握することができるなど、サイバーセキュリティ戦略を考える上で非常に役に立つフレームワークと言えます。 ※ CVE ： Common Vulnerabilities and Exposures （共通脆弱性識別子） 脆弱性情報をデータベース化したもの。 MITRE ATT&CKの攻撃プロセスとパスワード ここではMITRE ATT&CKで定義されている攻撃プロセスと、各プロセスでハッカーがどのようにパスワードを悪用して攻撃を展開するのか、そのテクニックを解説してきます。 MITRE ATT&CKで定義されている攻撃プロセス はじめに、MITRE ATT&CKで定義されている攻撃プロセスを解説します。 基本的には 1～14 の順で攻撃プロセスは進行していきますが、実際には途中から攻撃プロセスが開始されたり、1 から 4 に一気に攻撃プロセスが進むことがあるため、あくまで一連の流れとして考えるのがよいでしょう。 MITRE ATT&CKの攻撃プロセス 偵察 (Reconnaissance) リソース開発 (Resource Development) 初期アクセス (Initial Access) 実行 (Execution) 永続化 (Persistence) 特権昇格 (Privilege Escalation) 防御回避 (Defense Evasion) 認証情報アクセス (Credential Access) 探索 (Discovery) 横展開 (Lateral Movement) 収集 (Collection) コマンド&コントロール (Command and Control) データ窃取 (Exfiltration) 影響 (Impact) 攻撃プロセスとパスワードの関係性 では、一連の攻撃プロセスでハッカーはどのようにパスワードを悪用し、攻撃を有利に進めるのでしょうか。ここでは、具体的な攻撃内容を含め、一連の流れを解説していきます。 ※攻撃手法は多様ですので、ここではあくまで一例をご紹介します。 各攻撃プロセスとパスワードの悪用され方 偵察 ：ダークウェブに漏洩しているID・パスワードを探索、入手 リソース開発 ：偵察情報を活用した、フィッシングメール、なりすましサイトなどを作成 初期アクセス ：ソーシャルエンジニアリング、総当たり攻撃などで、一般ユーザーのID・パスワード（以降、アカウントと表記）利用を試みる 実行 ：一般ユーザーのアカウント悪用、エクスプロイトコードの実行等、後続の攻撃プロセスのための活動を実施 永続化 ：システム設定変更、新たなユーザーアカウント作成等により感染対象へのアクセス経路を秘密裏（セキュリティ製品等で検知されないよう）に確保する 特権昇格 ：設定不備、脆弱性悪用等により、一般ユーザーアカウントを権限昇格、特権アカウント奪取するなどして、所謂、特権アクセス権を掌握する 防御回避 ：セキュリティ対策の検知・防御を回避できるように設定を書き換える等する 認証情報アクセス ：キーロガーなどにより感染範囲内にあるパスワード等の認証情報の取得を試みる 探索 ：主に正規ツールを利用して、接続先システム、ローカルアカウント情報等、攻撃範囲拡大のためにNWを探索する 横展開 ：他のNW等へ感染範囲を拡大し、攻撃を継続する 収集 ：ストレージ、ブラウザ内等にある情報（個人情報・アカウント情報等）を収集する コマンド&コントロール ：10までで収集した情報等を正規ツール・サービスを利用して、秘密裏に外部に持ち出す環境を整える データ窃取 ：セキュリティ対策を回避しながら、データを外部に持ち出す 影響 ：データの破壊・改ざん、暗号化によるシステムダウンを被害を引き起こす ここで挙げたものはあくまで一例となりますが、パスワードの観点からみると 【主に攻撃の初期フェーズで直接的に悪用される】【他の攻撃の足掛かりとなる】 という点がポイントとなります。また、守る側は併せて以下の点を強く認識する必要があります。 想像以上に多くのパスワード情報が、既にダークウェブに漏れていること 高度なスキルが無くともブラウザ内のパスワード情報等は容易に入手ができること パスワードが推測可能、使い回されていると攻撃は短時間かつ低コストで進められる 攻撃にAI等を駆使することで、フィッシングの精度が飛躍的に向上し、それらの攻撃はセキュリティ製品での検知が極めて困難であること パスワードを悪用する攻撃への対策方法 ここまで、MITRE ATT&CKの攻撃プロセスと各プロセスにおけるパスワードの悪用手法を解説してきましたが、最後にそれらの攻撃への対策について考えていきます。 企業向けパスワードマネージャー サイバー攻撃に対抗していく上で特効薬はありませんが、パスワードを悪用する攻撃に対処するには基本的に専用ツールが必要不可欠となります。最も一般的な例として、組織においては企業向けパスワードマネージャーの利用が挙げられます。パスワードマネージャーを用いることで以下のような範囲・観点で対策が可能となります。 偵察 ダークウェブモニタリングで漏洩パスワードを監視 ⇒ 悪用可能な漏洩情報を事前に把握し、未然に対応が可能 リソース開発 　及び　3. 初期アクセス パスワード自動生成&自動入力機能により、従業員がパスワードを覚えない体制を構築 ⇒ フィッシングサイト等へのパスワード誤入力を阻止、推測しやすいパスワードの利用も抑止 特権昇格 　及び　8. 認証情報アクセス 安全性の高いパスワード共有により、誰でもパスワードが見れる状況を回避（＝最小限の原則に基づくパスワード管理を実現） ⇒ サイバー攻撃を“やりにくく”し、高い権限のアカウントを簡単に悪用できなくする 攻撃全般に対し て パスワード利用状況のログを監視し、不審なアカウント利用を検知 ⇒ 一般・特権アカウント共に、不自然な利用を早期検知することで感染範囲を最小限にする まとめ MITRE ATT&CKはCVEを基にしたサイバー攻撃の戦術やテクニックを分類したフレームワークで、組織は自組織を狙うハッカーや攻撃手法を把握し、セキュリティ戦略を構築するために利用できます。 企業向けパスワードマネージャーを活用することで、攻撃プロセス毎に対策が可能であり、セキュリティリスクの低減に寄与します。 マルウェア等に対する耐性が極めて高い強固な暗号化メカニズムで認証情報（パスワード等）を保護できる企業向けパスワードマネージャーでは、具体的に以下のような対策が可能となります。 ダークウェブモニタリングで漏洩パスワードを監視 パスワード自動生成＆入力機能で、従業員がフィッシング被害にあるリスクを低減 安全性の高いパスワード共有とログ監視で不審なアカウント利用を検知 シリーズ「組織におけるパスワード管理」記事一覧 【第1回】パスワードの基礎と主な管理手法について 【第2回】パスワードマネージャーの選定時のポイント 【第3回】ブラウザのパスワード保管機能を使う危険性 【第4回】MITRE ATT&CKフレームワークに見るパスワード管理 The post 【第4回】MITRE ATT&CKフレームワークに見るパスワード管理｜組織におけるパスワード管理 first appeared on Sqripts .

技術を土台にして自分なりのQAエンジニアを目指す本連載では、「テスト設計」に続き、今回は「テストマネジメント」を取り上げます。 「テストマネジメント」と聞くと、進捗管理やリソース調整といった、いわゆる「管理業務」を思い浮かべる方が多いかもしれません。 しかし、私自身はQAエンジニアとしての専門性を高める上で、テストマネジメントは根幹をなす重要な技術の一つだと捉えています。 この記事では、私の経験から得たテストマネジメントに関する考えを言語化し、皆さんにとってのヒントとなれば幸いです。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 「テストマネジメント」は単なる管理業務ではない 「テストマネジメント」という言葉もまた、組織や人によって様々な解釈が存在します。 例えば、JSTQBでは、 テスト活動の計画、スケジューリング、見積り、モニタリング、レポーティング、コントロール、完了のプロセス。 ISTQB Glossary Version2,2025年9月1日参照 とあります。 この記事では、もう少し身近な言葉を使って、以下のように定義します。 テストを通じて、プロジェクトのQCD（品質・コスト・納期）を調整し、その達成に責任を持つ活動 テストマネジメントは単に与えられたリソース（人、時間、お金）を管理するだけではありません。 テストにおける品質への貢献は、「プロダクトリスクを低減する」と言い換えることができます。 この目的を達成するためには、必要なテスト技術を適切なタイミングで活用し、意思決定を促すことが重要です。 時にはそういった意思決定の当事者になることも含まれる、専門性の高い活動だと考えています。 テストマネジメントを自分ごととして捉える 当初私は、テストマネジメントは経験豊富なマネージャーの仕事であり、キャリアの浅い自分には関係ないと考えていました。 しかし、テスト業務の中でテストマネジメントの側面に触れ、自らも学習していくうちに、この認識が先入観だったと気づきました。 『テストをマネジメントする』という考えは、テストのあらゆる活動に不可欠です。メンバー一人ひとりが主体性を持って取り組むべき課題だと、私は考えるようになりました。 「テストは本来不要な活動である」と捉える この先入観を壊すきっかけとなったのは、ある逆説的な考え方でした。 『テストとは、本来やるべきでない活動である』という捉え方です。 もちろん、品質を保証するためにテストが必要不可欠なのは言うまでもありません。 あくまで思考実験です。 しかし、もし完璧な人々が完璧なプロダクトを作れるのであれば、テストは本来必要ないはずです。 これは「開発者完全性仮説」という概念にも通じます。 この概念は、にしさんが以下の動画で紹介しています。 ▲YouTube：JaSST nano vol.13 #4「「もうQAはいらない」ってホントなの？」より しかし、現実には多くの現場がそうではありません。 ソフトウェア開発には何らかのリスクや不確実性があるため、その必要性に応じてテストを実施しているのです。 『本来不要な活動』であるテストに、私たちはなぜ貴重なリソース（時間やコスト）を投じるのか。 その問いに答えること自体が、テストにおけるマネジメント、すなわち『投資対効果を最大化するための意思決定』に他ならないのです。 テストマネジメントは「組織の合意形成」と「意思決定」の技術 例えば、『プロダクトを顧客に届け、安定的に運用して利益を得る』という目的があるとします。それを阻害するリスクがあるからこそ、テストを実施するわけです。 そう考えると、『テストとして何が必要で、どこまでやるべきか』という合理的な判断をするための根拠を、きちんと言語化する必要があると考えるようになりました。 この考えに至ったとき、テストマネジメントは現場で完結するものではなく、組織全体での『合意形成』や『意思決定』の側面もあることに気がつきました。 現場の特性に加え、時々刻々と変化する状況に応じてテスト戦略やリソースを判断し、その判断に責任を持つこと。これこそが、テストマネジメントの本質だと私は考えます。 この視点を持つと、テストマネジメントは特定の役職者だけのものではなくなります。 むしろ、現場の状況を深く理解した専門家としての判断が求められる分野であり、特に開発チームの中にQAが入り込む「インプロセスQA」においては、必須のスキルとなるのではないでしょうか。 ※「インプロセスQA」に関しては以下のスライドも参照ください。 品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話（3D版） Yasuharu Nishi／slideshare ドキュメントではなく、育てるテスト計画 JSTQBにおいて、テストマネジメントの代表的なアクティビティとして「テスト計画」と「テストのモニタリングとコントロール」が挙げられます。 『テスト計画』は、しばしばテンプレートに沿った重厚長大なドキュメント作りだと捉えられがちです。もちろん、そのような現場があることは否定しませんが、私は異なる考えを持っています。 むしろ、最初の段階では現場のコンテキストに合わせた最小限のテスト計画を作成し、合意形成を重ねながら育てていくことも有効だと考えています。 だからこそ、テスト計画に記述する典型的な項目や、テストモニタリングでの管理項目について深く理解し、その必要性を自分なりに説明できることが大切です。そうすることで、チームメンバーやステークホルダーとも納得感を持って進められます。 モニタリングにより、テストもコントロールする 『モニタリングとコントロール』は、リソースの調達やリリース日の延期といった決断のためだと考える人は少なくありません。 プロジェクトリスクの高いバグを早い段階で発見し、すぐにテストスケジュールを調整することは、まさにテストマネジメントの技術が発揮される場面です。 しかし、モニタリングとコントロールの役割はそれだけではありません。 テストを通じて品質に関する情報をモニタリングし、テスト戦略あるいはプロジェクト全体へフィードバックすることも重要です。 プロダクトリスクの高いバグを発見した際には、バグ分析を通して『欠陥の偏在』の原則に基づき、重点的なテスト設計をやり直すといったアプローチも可能です。 プロジェクト面、プロダクト面両方から「モニタリングとコントロール」を行うことが大切です。 専門性の組み合わせ 「テストマネジメント」という専門性もまた、他の技術と組み合わせることで、さらなる価値を生み出します。 テスト実行との組み合わせ テストマネジメントの視点を持つことで、テスト実行中に「この情報はいま誰に、どのように伝えれば、組織にとって有益だろうか？」と考えるようになります。 単に進捗を報告するだけでなく、発見した事象が今後のプロジェクトリスクや、全体的なプロダクトリスクの見立てにどう影響するかを示唆するなど、報告の質が格段に向上したと実感しました。 これは、自分自身のテスト実行がプロジェクト全体のどの位置にあるかを知る手がかりにもなります。 テスト設計との組み合わせ 限られたリソースで最大限の効果を発揮するというマネジメントの観点は、テスト設計に大きな影響を与えます。 例えば、テスト技法を選択する際も、その手法が生み出すテストケースの特性から、必要なリソースや低減できるプロダクトリスクを判断できるようになりました。 また、プロダクトリスクを把握することは、テストマネジメントにおけるモニタリングやコントロールにも有益なフィードバックとなります。 テストマネジメントの観点を持つことで、『どこまでテストすれば十分か』というカバレッジの判断基準が明確になり、費用対効果も考慮できるようになりました。 これにより、より実践的で『使える』テストケースを導き出せるようになりました。 おわりに：今日からできるテストマネジメント この記事を通して、テストマネジメントが特別な技術ではなく、あなたのQAキャリアを支える土台となる専門技術であることをお伝えしました。 例えば、テストケースを一つ設計・実行する際にも、「このテストは誰に、どんな意味があるのか？」と、その背後にあるマネジメントの観点を意識してみてください。 その問いから、あなたのテストマネジメントがはじまり、QAエンジニアとしてのキャリアを、そしてチームやプロダクトの未来を大きく変えていくはずです。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない The post 【第3回】テストマネジメントはテストマネージャーだけの技術ではない first appeared on Sqripts .