前回 、エンジニアの成長における「心技体」の中でも、土台となる「心（マインドセット）」の重要性についてお話ししました。早速、具体的な話に入っていきます。まずはちょっとしたことから「思いやり」を始めていきましょう。 関連記事 【第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 .

こんにちは。Sqripts編集部のハチワレと申します。 かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。「非エンジニア」を称しています。 今回は、非エンジニアの私がGoogle Cloudの認定資格、 Generative AI Leader （生成AIリーダー）に挑戦した理由、学習方法から、合格の軌跡を記事にしました。 この認定資格は、公式サイトによると「実践的な技術経験の有無を問わず、あらゆる職務のすべての方を対象」としており、以下の分野の知識が評価されます。（ Generative AI Leader ） 生成AIの基礎 Google Cloudの生成AIサービス 生成AIモデル出力を改善する手法 生成AIソリューションを成功に導くビジネス戦略 「なんとなく」生成AIを使っていませんか？ 「生成AIは便利だ」と感じつつも、少し複雑なことをやろうとすると「プロンプトエンジニアリング」、「ハルシネーション」、「ML（マシンラーニング）」、「エージェント」…と専門用語が出てきて戸惑うこともしばしば。 「なぜこのAIモデルを選ぶのか？」という問いに、明確な根拠を持って答えられなかったり…。 そんな経験はないでしょうか？ 私はあります。 業務ではGeminiやChatGPTを積極的に活用していますが、その技術的知識はほぼゼロ。 「生成AIに業務の相談をする」ことはできても、「なぜこのAIはこういう回答をするのか」は説明できない。 今回、そんな私でも 約31時間の学習 でGoogle Cloud認定資格「Generative AI Leader」に一発合格することができました。 この記事は、私と同じような課題を持つすべてのビジネスパーソンやエンジニアに向けた具体的な合格ガイドです。 この記事を読むと、どのような人にこの資格がおすすめかがわかるかと思います。 また、もし挑戦すると決めたなら、ぜひ学習方法も参考にしていただけると幸いです。 費用対効果は？ 投下コストと得られたリターン まず、資格取得にかかった全コストと、それによって得られたリターンを公開します。 【投下コスト】 学習時間：合計 約31時間 （内訳） 公式講座の受講：12時間 対策ブログの読み込み：6時間 問題演習（自作問題含む）：13時間 費用：受験料($99)＋問題集（300円）購入 ※後述 【得られたリターン】 生成AIに関する思考の解像度が劇的に向上した 根拠を持って説明できるようになった 次に何を学ぶべきかの指針が明確になった AI関連技術やGoogle Cloudの製品群に詳しくなった 最大のメリットだと感じたのは、 知識が体系化され、「説明できる」レベルになったこと です。 例えば「ハルシネーション」という言葉。学習前は「AIが嘘をつくこと」程度の認識でした。 しかし学習後は、「なぜ起きるのか」「どのような対策（グラウンディングなど）が有効か」まで含めて、自分の言葉で説明できるようになりました。 “知っている” と “説明できる” は、ビジネスの現場では天と地ほどの差があります。 この変化により、具体的なサービス名を挙げてAIの活用法を検討したり、技術的な裏付けを持って企画やプロジェクトの実現可能性を判断したりできるようになりました。 【完全再現】31時間で合格するための学習ロードマップ 私が実践した学習のポイントは、 「アウトプットを徹底的に重視する」 ことです。知識の詰め込みは早期に終えて、思い出し・使う練習に時間を割きました。 学習法は、 科学的根拠に基づく最高の勉強法 の記事を参考にしました。学習法に関する知識を習得することで、「じつは効果がない」学習を排除。効果の高い学習を徹底し、記憶の定着に努めました。 ▼ 私が参考にした学習法は、こちらの記事で詳しく解説されています。 関連記事 JSTQB Advanced Level テストマネージャ勉強法　-科学的根拠に基づく最高の勉強法を参考にして- こんにちは、QAコンサルタントのヤマダです。私はこのたび、JSTQB® Advanced Level テストマネージャ試験に合格しました。  本記事では、試験合格のために活用した書籍「科学的根拠に基づく最高の勉強法」の内容を解説するとともに、JSTQB試験の概要、そし... 　続きを読む　 Sqripts ステップ1：全体像の把握（インプット期 / 合計18時間） やること①： Google Cloud Skills Boostの公式トレーニングを1周する （目安：12時間） ポイント： ここでは完璧を目指さない。 「知らない単語をなくす」 「2周しなくていいように集中力をもって取り組む」 集中力が切れたらすぐに休憩する、その日はもう学習しない、などの決断も大事だと感じました。解説動画は英語なので（文字起こしの日本語テキストもありますが）、英語が苦手な私は集中力が切れることも多く、まとめてのインプットはせず細切れで学習しました。 この2点を意識し、まずは最後まで走り抜きましょう。全体像を早く掴むことが重要です。 やること②：対策ブログを読み込み、戦略を練る （目安：6時間） ラリオス川口さんのnote をはじめ、ブログなどで合格者が自身の学習法・試験対策を公開しています。それらを読み込み、試験の傾向、合格者が「重要ポイントだと感じている点」をインプットします。 ステップ2：知識の定着（アウトプット期 / 約13時間） インプットを終えたら、アウトプットに移ります。ここが合否を分ける最も重要なフェーズです。 やること①：公式の模擬試験を受ける Generative AI Leaderの模擬試験を受験します。模擬試験は何度でも挑戦できますが、正解を覚えてしまうので、ここでは「問題の傾向をつかむ」、「翻訳日本語に慣れる」を目標にします。 ※試験自体は日本語版として2025年7月に正式リリースされており、日本語で受験ができます。しかし、問題文は「英語を元にした日本語だな…」と感じる部分も多く（1文が長いなど）、集中して読み込まないと問題の意図もわからないことがありました。 やること②：演習問題でアウトプットを繰り返す [ポイント！] 最も効果的だと感じたのが、 学習ガイド(PDF) にも載っている 「NotebookLMを使った学習」 です。私は今回の学習にあたり、NotebookLMを活用して自作問題集を生成して演習しました。 NotebookLMに、ソースとして公式講座のテキスト（学習ガイド）と試験ガイドをアップロードし、参考にしたブログなどもソースに追加します。 ソースの準備ができたら以下のようなプロンプトを入力します。 ▼プロンプト例 ソースから試験対策の50問の模擬テストを作成してください。出題形式は4択問題です。正解と各解説も作成してください。試験ガイドを参考に、各分野の出題割合を調整してください 模擬テストは何度でも生成が可能ですし、プロンプトを工夫し苦手分野だけの問題を作ってもらうこともできます。また、1問1答でひたすら演習ノックのようなこともしました。 試験直前にラリオス川口さんのnoteにあった想定問題集「 10.Generative AI Leader 試験完全攻略！本番想定問題集 100 本ノック！ 」にも取り組みました。（当時価格300円） （私は時間がなく取り組みませんでしたが、Udemyの講座を受ける方も多いようです。） やること③：「弱点克服ノート」を作成する 演習で間違えた問題や、曖昧な用語はすべてGoogle Documentにまとめました。Google Documentなら、PCでもスマートフォンでも復習ができるため、電車移動の時などもこの自作ノートを眺めていました。このノートは試験直前まで見返しており、最強の武器になりました。 ステップ3：自分を追い込む やること： 学習がある程度進んだ段階で、先に試験の予約を入れます。 ポイント： 「〇月〇日に受験する」という明確なゴールを設定することで、学習の質と集中力は劇的に向上します。（緊張感や焦燥感も増します…） 試験本番：当日の流れと合否を分けた「55分の見直し」 試験当日は、10数年ぶりの資格試験ということもあり、とても緊張しました。 また、Google Cloud認定資格試験の受験は初めてでしたので、受験システムにも不慣れで、そのことでの緊張もありました。 試験形式： 90分 / 45問 （公式では50問～60問となっていますが私が受験したものは45問でした） ※すべて4択問題。 ※私はオンサイト監督試験（テストセンターでの受験）を選択。 ※試験概要はアップデートされることがあります。 公式サイト をご確認ください。 試験本番： まず開始から約35分で、全45問を一通り解き終えました。 わからない問題、自信がない問題は「見直し」マークをつけてどんどん進みます。全容把握が先決です。 一巡した段階で、自信がなく「見直し」マークを付けた問題が 13問 （約29%）。正直、「ダメかもしれない…」と思いました。 ※公式では合格ラインは公表されていませんが、正解率80%を目指していました。 諦めるのはまだ早い！ここからが本番です。 残った 55分をすべて見直し に充てました。まずはマークを付けた13問について問題文と選択肢を何度も読み返し、知識・記憶を総動員して解答の精度を上げていきます。 最終的に、自信のない問題は 9問 （20%）まで減少。 まったくわからない「あてずっぽう」が2問、「正解の可能性が高い」と思えるものが7問です。 「これ以上考えても結果が変わらない」と思えるところまで取り組んだら見切りをつけます。 残り7分ぐらいの段階で、マークしていない「自信のある問題」のケアレスミスがないか見直し。時間ギリギリまで粘りました。 ドキドキしながら回答を送信して試験が終了です。 運命の結果は… 試験終了直後にPC画面に 「 合格 」 の文字…。 静かな会場で、心の中でガッツポーズしました… この経験から言えるのは、 試験は時間配分と、最後まで諦めない姿勢が合否を分ける ということです。 試験が始まる前までは「90分も必要？早めに退室してもいいかな」と根拠のない余裕を持っていましたが、現実はそんなに甘くはありませんでした。時間があれば、もう一巡、見直したいぐらいでした。 3日後には合格の通知も届き、正式に資格取得者として登録されました。 まとめ：「なんとなく知っている」から「根拠を持って説明できる」へ この記事のポイントをまとめます。 資格の価値： 「なんとなく知っている」から「根拠を持って説明できる」へ。思考の解像度が上がる。 学習時間： 約31時間。忙しい人でも十分に挑戦可能。 学習戦略： アウトプットを重視。特に「NotebookLMでの自作問題」と「弱点克服ノート」が効果的。 合格の秘訣： 先に試験日を決めて自分を追い込む。本番では最後まで見直しを徹底する。諦めない。 回答のポイント： さまざまな業種・チームにおける生成AI活用について、「私がこのチームの一員ならどうするか」、「この立場ならどう行動するべきか（役職者・開発者など）」、「多種多様なモデルから、このケースだとどのモデルが最適か」を考えることが大切です。模擬試験などもそういった形式の問題が多数出題されていますので、自分をプロジェクトの一員として考える癖をつけておくとよいです。 もし、この記事を読んでくださったあなたが、キャリアや自己研鑽のために何か新しいスキルを身につけたい、生成AIの知識を体系的に学びたいと考えているなら、この資格は費用対効果が高い、優れた自己投資と言えそうです。 「苦手な分野の学習こそ、資格取得という明確な目標が大きな助けになる」。 これは、私が今回の挑戦で実感したことです。 この記事が、どなたかの新たな一歩を後押しできれば幸いです。 最後までお読みいただき、ありがとうございました。 The post Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた｜知識ゼロから始めた学習方法と試験対策 first appeared on Sqripts .

開発チームと品質保証チームは、どちらも製品やソリューションを、よりよい品質でお客様に届けるために必要不可欠なチームで、共通のゴールにたどり着くためには協力が必要です。ですが、それぞれのチームの背景、思想、文化、知識、様々な要因によりうまくかみ合わない、チームが対立するという経験をしたことはありませんか？ 私はあります。 これは、過去に私が参加した、とあるプロジェクトの話です。 開発を担当するのは海外の開発ベンダーで、開発されたソフトウェアを受け入れる部門はソフトウェアに関する知識が乏しい。そのため、私が所属する部署が製品としてリリースする前に、ソフトウェアの品質を確認することになりました。 私が参画したころは、すでにいくつかのお客様先にインストールがされていて、現場ではトラブルが起きていました。発生した問題を開発チームに伝えると… 「 Ah, it’s a known issue! （知ってた）」 「 It will be fixed in the next release, so it is not a problem. （次で直すから、問題なし）」 という回答。入ってすぐにこの光景を目の当たりにして、私は愕然としました。 今思えば、このプロジェクトに散見していた課題は、JSTQB® Advanced Levelテストマネージャのシラバスで語られる典型的な課題そのものでした。機能していない欠陥マネジメントプロセス、そして何より深刻だったのは、主要なステークホルダー（開発チーム）とのコミュニケーション不全です。 では、この教科書通りの「詰んだ状況」を、私たちはどうやって乗り越えたのか。 当時はただがむしゃらに、目の前の課題に対して地道で人間的なアプローチを繰り返すだけでした。しかし、今こうして振り返ってみると、その一つひとつの行動が、JSTQB® Advanced Levelテストマネージャで語られる概念に見事に当てはまることが分かったのです。 この記事では、過去の出来事をJSTQB® Advanced Levelテストマネージャで学ぶ概念と対比させながら振り返っていきたいと思います。私の経験が、皆さんがJSTQB® Advanced Levelテストマネージャの知識を、実践で活用するための一助となれば幸いです。 開発チームとのコミュニケーション不全 「話せば分かる」と最初は楽観視していました。それまでの私は品質保証側ではなく開発側の立場でしか仕事をしたことがなかったので、自分の経験をベースに考えていたのです。自分は品質保証チームのいうことに対して、多少の面倒くささは感じましたが、品質を上げるためには仕方がないと思って対応をしてきました。きっと他の開発者も同じように考えてくれるだろうと安易に考えていたのです。 そこでまずは、理解を深める場として、定例のミーティングを実施し、こちらのソフトウェアの仕様に対する知識を深めると同時に、こちらが課題だと感じている点を理解してもらおうとしました。ところが、このミーティングは当初の目的をなかなか果たせませんでした。 現状を把握するために、技術資料やソースコード、バグ管理システムへのアクセスを依頼しても、なかなか情報を開示してくれません。提供してもらった情報を基に、問題の深堀をして、根本的な課題を解決したかったのですが、できないので、表面的な問題についてばかり話をする羽目になりました。 そんなことばかり話すから、開発チームからは「次のリリースで直すのに何が不満なんだ？」と不満が続出。 お互いの主張がぶつかり合い、折り合いがつかず、またこちらも言葉の壁のせいで、言い負かされて、うまく言いたいことも伝えられません。あっという間に予定時間を超え、2時間3時間ひたすら会話が平行線をたどって決着がつかないこともありました。 こんな状況で、顧客からきているクレームの対処をこれからどうしていけばいいのか、どうやっていいものを作っていけばいいのか、途方にくれました。 コミュニケーションの改善 この試行錯誤は、まさにテストマネージャに求められるスキルの実践でした。今振り返ると、私たちが無意識に行っていた工夫は、JSTQB® Advanced Levelテストマネージャで学ぶ重要な概念と見事に一致していたのです。 JSTQB® Advanced Levelテストマネージャのシラバス「7.6 コミュニケーション」で語られているように、とにかく「メッセージが受け入れられるための適切な土壌を作るのに必要な説明は何であるかということを、理解することが重要」です。 彼らに響く言葉は何なのか、どういう振る舞いをすれば話を聞いてもらえるようになるのか。そこでまずは、相手が自分の話を聞いてあげてもいい、お互いのためになると思ってもらうためにはどうしたらよいかを、今までのやり取りを基に考えるようになりました。 何故、こちらの伝えたい言葉が伝わらないのか？ JSTQB® Advanced Levelテストマネージャのシラバス「2.8 分散テスト、アウトソーステスト、およびインソーステスト」に「地域、時間帯、文化、言語の違いが、コミュニケーションの問題と、期待との差異による問題を引き起こしやすくする」という記述があります。まさに、私たちが直面していた課題そのものでした。そこで、こちらから話を伝える際に、いくつか工夫をして、「メッセージが受け入れられるための適切な土壌」を作るようにしました。 雑談で距離を縮める 直接会える機会があれば、積極的に雑談をして話すチャンスを増やしました。人となりを知ることで、話しやすい関係を作るように試みたのです。昔彼らの国に父が駐在していたことがあったので、その話をすると、向こうの開発チームのマネージャーの住んでいる街だったようで、そこから徐々に色々な話ができるようになりました。 対等なパートナーとして意見を伝える また、これはよく外国の方と話していると感じるのですが、彼らは自分の意見もはっきり言いますが、こちらの意見も求めてきます。日本人はあいまいに「いいと思う」と言ってしまいがちかと思いますが、議論に値する相手だと思ってもらうためにも、自分の意見を理由と共に伝えるようにしました。向こうの社長にUIについて意見を求められた時も、「ここのこの部分が直感的ではないのでユーザーには使いにくいと思う」とはっきり言い、世界共通でわかりやすいUIとは何かという議論を、スタバで繰り広げたこともあります。 伝え方を工夫する とにかく話せと言われても、うまく伝えられないと話す気持ちも萎えてしまいますよね。そんな時は伝わりやすい言葉を選んで、伝えるようにしました。例えば、彼らがよく使う言葉に言い換えたり、時にはあらかじめ図を用意して説明をしたり。会議中にうまく口頭で答えられないことはいったん持ち帰り、話したい内容を整理してからメールで補足をするようにしたのです。分からないことは自分の言葉で言い換えて正しく理解できているか都度確認をして、相互の理解を深めることを意識しました。 会議は効率よく さらには、会議の進め方も、改善をしていきました。 時差がある分をうまく有効活用し、会議の前日までに議論したいアジェンダを送付することで、翌朝には一次回答がもらえている状態になり、会議では合意をするだけか、細かい部分のずれの調整のみで済むようになりました。 大小合わせて10以上の議題があっても、会議の時間が1時間を超えるようなケースはほとんどなくなりました。 リスクベースドテストのアプローチを活用する 人って納得できないことはやりたくないですよね。何故そんなことを聞くのかわからない質問にも答えたくないという気持ちが働くのは当然です。ですから、質問や依頼をする際には、背景や理由を説明するようにしました。 例えば、「開発側では軽微なバグだと思われているような内容でも、日本のプロジェクトでは非常によくお客様が目にする機能なので問い合わせが相次いでいる。このままでは、重要顧客の信頼を損ねるので対応をしてください」というような形です。 なぜ必要なのかが分かると彼らも、柔軟に考えを変えてくれるようになりました。「そういうことなら、こちらの問題の方を優先度を上げて確認してみるよ」と、前向きに問題に向き合ってくれるようになった瞬間は、今でも忘れられません。 この「なぜ重要か」を伝える行為は、JSTQB® Advanced Levelテストマネージャのシラバス「2.3.1 リスクベースドテスト」のアプローチそのものです。テストマネージャは、単に欠陥を報告するだけでなく、「その欠陥がビジネスや顧客に与えるリスクの大きさ」を評価し、ステークホルダーに理解可能な言葉で伝える責任があります。私たちは、開発チームにこの「ビジネスリスク」を共有することで、初めて修正の優先順位について同じテーブルで議論できるようになったのです。 ステークホルダー間の利害を調整する 相手の意見とこちらの意見がぶつかってしまう時には、自分の意見を押し通す前に、まず相手の考えをきちんと聞くことから始めます。そのうえで、もともとの要求のプロジェクトへの影響度を再確認し、プロジェクトの成功を大きくするためには、何をどう優先して対応していくべきか議論をするようにしたのです。 この時、自分たちの意見が一方的な要求にならないように、気を付けました。私たちは同じゴールを目指す仲間で、敵ではないのですから。 これは、JSTQB® Advanced Levelテストマネージャで重要視されるステークホルダーマネジメントの一環です。JSTQB® Advanced Levelテストマネージャのシラバス「2.2.1 テストステークホルダについて」には「ステークホルダとテストとの関係の本質、およびテストチームがステークホルダのニーズに応える方法について理解する必要がある。」とありますが、そのためにテストマネージャは、「7.6 コミュニケーション」に記載されたような、開発、ビジネス、運用など、異なる目的を持つステークホルダー間の利害を調整し、プロジェクト全体の成功という共通ゴールに向かって合意形成を導く、高度なピープルスキルが求められます。 気持ちは伝わる こうした相手を尊重した動きは、少しずつではありますが実を結んでいきます。尊重には尊重を返してくれるようになり、こちらが根気強く訴えていた、開発側での品質の作りこみが開始されるようになりました。私たちの対話は、単に目の前のバグを修正させるだけでなく、彼らの組織構造そのものを変え、専門の品質保証チームを設立させるという、大きな変化のきっかけになったのです。 この品質保証チームの設立は、単なる組織変更以上の意味がありました。テスト組織の成熟度を測るモデルであるTMMi（Test Maturity Model integration）に照らし合わせれば、場当たり的なテスト（レベル1）から、組織として管理されたテストプロセス（レベル2以上）へと移行する、非常に大きな一歩だったのです。 テストのモニタリングとコントロールを続ける こうして、お互いを信頼できるパートナーとして認め合うほど、2つのチームの信頼関係はかなり強固なものとなったのです。だからこそ、私たちは「次なる問題」に、チームとして立ち向かうことができました。 導入してくれる顧客が増えてくると、関わってくる人も増え、想定していなかった使われ方により新たな問題が現場で発生することが増えます。オペレーターが設定機能をうまく使いこなせず、誤った設定をデバイスに送ってしまい、デバイスが全く動作をしなくなることがあったり、フィールドに設置してみたら周囲の電波環境の影響かうまく通信が出来なかったり、などなど。 ラボでテストをしている人たちの想定している状況とは異なる何かがフィールドにはあったのですが、ベンダーの開発チームや品質保証チームにはフィールドでの使われ方の情報が伝わりきらないため、テストでは検出できず、問題が流出してしまうという現象が続きました。 そこで、顧客が望む運用方法や、オペレーターの設置フェーズのプロセスについてを、オペレーション担当からヒアリングし、インシデントの傾向を分析することで、設置フェーズ、運用フェーズそれぞれで「できなければいけないこと」の観点を抽出し、受け入れテストのブラッシュアップを図りました。 ベンダー側に品質保証チームが設立されるまでは、受け入れテストで開発チームのテストの妥当性を再確認する必要もあったため、ベンダーで実施しているテストとオーバーラップするテストが多くありました。これらを半分に減らし、その分ヒアリングや分析から得られた観点を基に、シナリオテストや組み合わせテストを追加したのです。 この対応により、今まで見逃されていた、設定の画面での操作ミスで発生するバグや、機能追加により作りこまれてしまったけれど特定条件でしか発見できないデグレードも、受け入れテストの段階で検出できるようになってきました。 この活動は、テスト計画が一度作って終わりではないことを示しています。JSTQB® Advanced Levelテストマネージャのシラバス「1.2.2 テストのモニタリングとコントロール」で学ぶテストのモニタリングとコントロールの一環として、プロジェクトから得られた新たな情報（今回の場合はフィールドでの利用状況という新たなリスク情報）を元に、テスト戦略を動的に見直すことが求められます。これもテストマネージャの重要な役割です。 まとめ この記事で見てきたように、私たちの旅は、コミュニケーションが崩壊したチームという厳しい状況から始まりました。その分厚い壁を壊したのは、魔法のような特効薬ではなく、「対話」と「尊重」という地道な積み重ねでした。 そして最も重要なのは、それらの実践の一つひとつが、JSTQB® Advanced Levelテストマネージャで語られる「リスクベースドテスト」や「ステークホルダーマネジメント」といった理論と、後から見事に結びついていたという事実です。 この経験から得た学びは、JSTQB® Advanced Levelテストマネージャの知識によって、より普遍的な原則へと昇華されました。 人は、自分を尊重してくれる相手を、信頼する。（これは「コミュニケーション」の核心です） 背景（ビジネスリスク）を理解すれば、相手は自ら動いてくれる。（これが「リスクベースドテスト」の実践です） そして、その全ての土台となるのが、諦めない「対話」です。（これこそ「ステークホルダーマネジメント」そのものです） JSTQB® Advanced Levelテストマネージャの知識は、資格取得のためだけの暗記項目ではありません。それは、複雑で困難な現場で人間関係の課題を解決し、チームを前に進めるための、強力な「思考のフレームワーク」なのです。 もしあなたがチームの壁に悩んでいるのなら、ぜひその知識を武器に、隣にいる仲間との「対話」から始めてみてください。きっと、あなたのチームも「対立」から「共創」へと変わるはずです。 The post JSTQB® Advanced Levelで海外チームとの壁を越える first appeared on Sqripts .

こんにちは、エンジニアのタカです。 今回は、私が直近で開発業務で使用している JsonSchema（ジェイソン・スキーマ） の紹介と、Pythonの Pydantic（パイダンティック）モデル と組み合わせたバリデーションについて解説します。 JSONのメリットとのデメリット JSON (JavaScript Object Notation) は「キーと値のペア」というシンプルで直感的なデータ定義形式が特徴です。 比較的自由に値を定義でき、高い可読性を持つ上に、プログラミング言語に依存しないフォーマットであるため、現在ではデータ交換フォーマットの 事実上の標準 として、多くのシステムで利用されています。 一方で、このJSONの柔軟性は、時に以下のような課題を引き起こすことがあります。 構造の不透明性 : JSON自体には、どのようなデータが存在し得るかという「型」や「必須項目」を定義する仕組みがありません。別途ドキュメントを準備する必要があり、また、アプリケーション側で意図しないデータが紛れ込んだり、あるいは期待するデータが存在しないといった状況が発生しやすくなります。 データ品質の低下 : スキーマが存在しないことにより、データの中身に対する開発者間の認識にズレが生じやすくなります。これが原因でデータの品質が低下したり、予期せぬバグを引き起こしたりするリスクがあります。 バリデーションの複雑化 : 受信したJSONデータのバリデーションをアプリケーション側で手動で実装しようとすると、コードが複雑化し、結果として保守性の低下を招く恐れがあります。 私が現在開発に携わっているシステムでも、PostgreSQLのテーブルに jsonb 型のカラムを設け、JSON形式で可変長のデータを保存しています。 このデータはユーザーごとにJSONに保存するキーが異なる場合があり、一貫したデータ形式にならず、データのバリデーションに苦労していました。この問題を解消するために、 JsonSchema という定義を導入することにしました。 JsonSchemaとは JsonSchemaは、JSONデータの構造やルールを定義するスキーマ言語です。簡単に言うと、「 JSONデータがどんな形をしているべきか 」というルールを定めるもので、JSONの柔軟性ゆえに生じる前述の「構造の不透明性」や「データ品質の低下」といった課題を解消するために定義されました。 このJsonSchemaには、主に以下の3つの用途があります。 データのバリデーション : 入力データが期待する形式に合致しているかの検証 コード生成 : 定義されたスキーマから任意の言語向けのデータモデルクラスやバリデータコードの自動生成 ドキュメンテーション : データ構造の定義による開発者間の共通認識の形成 これらの用途について、実際のJsonSchemaのサンプルを交えて解説します。こちらのサンプルは、架空のユーザーデータを表したものです。 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/schemas/user.json", "title": "User", "description": "User profile data", "type": "object", "properties": { "id": { "type": "string", "format": "uuid", "description": "Unique identifier for the user" }, "name": { "type": "string", "minLength": 1, "maxLength": 100, "description": "User Name" }, "email": { "type": "string", "format": "email", "description": "User email" }, "is_active": { "type": "boolean", "default": true, "description": "User active status. active is true" } }, "required": ["id", "name", "email"] } JsonSchemaは、規定のキーワードを用いて表現されます。以下に、代表的なものを記載します。 キーワード 役割 $schema スキーマが準拠するJsonSchemaのバージョンURI $id スキーマを一意に識別するためのURI title , description スキーマの名称と説明 type データの基本型（ object , string , integer , boolean など） properties type が object の場合に、オブジェクトが持つプロパティとその定義 required オブジェクトのプロパティのうち、必須となるもののリスト 1. データのバリデーション JsonSchemaの最も基本的な用途がデータの バリデーション です。 properties キーワードの中に各プロパティごとのルールを定めることで、受け取ったJSONデータが期待通りの形式や値の範囲に適合しているかを自動的に検証できます。 前述のユーザーデータのサンプルでは、 id は uuid 形式の文字列、 name は1文字以上100文字以下の文字列、 email はメールアドレス形式の文字列、 is_active は真偽値でデフォルトは true 、といったルールになります。 また、 id 、 name 、 email は required キーワードによって必須項目と定義されます。 このような厳格なデータチェックをコードで手動実装すると複雑になりがちですが、JsonSchemaを使えば宣言的にルールを記述できるため、可読性と保守性を高められます。 なお、AIモデルが生成する出力形式を指定する structured output (構造化出力) というアプローチでもJsonSchemaが利用されており、AIモデルの出力をJsonSchemaで定義した形式に指定することで、AIの出力を他のシステムやアプリケーションが自動的に処理・解析しやすくなります。 2. コード生成 JsonSchemaは、データ構造の厳密な定義となるため、そこから アプリケーションコードを自動的に生成 する基盤にもなります。 フロントエンド、バックエンドを問わず、JsonSchemaから各種ツールを用いて以下のようなものを生成できます。これらは、開発プロセスの効率化や、手動実装でのミスを削減する効果があります。 生成物 例 説明 データモデルクラス PythonのPydanticモデル、 TypeScriptのインターフェースなど JsonSchemaで定義されたJSONの構造を、各プログラミング言語のオブジェクトとして扱うためのクラスやインターフェース バリデータコード 関数、クラス JsonSchemaに記述された minLength や format 、 pattern といった具体的な制約に基づき、入力データが正しい形式であるかを検証するためのコード（関数やクラス） APIドキュメント OpenAPI/Swaggerなど 人間が読みやすい形式のAPIリファレンスドキュメント（Swagger UIのような対話型ドキュメント）。JsonSchemaは、OpenAPI Specificationの基盤としても使用されている なお、本記事で後述する datamodel-code-generator はPydanticモデルを生成するツールです。スキーマが変更された際も、ツールを再実行すれば関連クラスを最新の状態に保つことができます。 3. ドキュメンテーション JsonSchemaそのものが、JSONデータの持つプロパティの種類、データの型、制約、そして説明を詳細に記述しているため、これ自体が質の高いドキュメントとして機能します。 さらに、JsonSchemaのエコシステムには、JsonSchemaをより視覚的で分かりやすいHTMLドキュメントなどに変換するツールも存在します。個別のツールについては、 公式サイトのToolページ に記載があるので参照ください。 ただし、ドキュメンテーションツールに限らず、JsonSchemaのツールに関しては、対応するJsonSchemaバージョンによって利用できるものとそうでないものがあります。利用の際には $schema キーワードで指定するバージョンに対応するものを選ぶ必要があります。 (補足) JsonSchemaのバージョンについて JsonSchemaは継続的に仕様追加や変更が行われており、 $schema キーワードで指定するURIで どのバージョンの仕様に準拠しているか 示す必要があります。 これにより、JsonSchemaを処理するライブラリやツールは、どのルールセットに基づいてスキーマを解釈し、バリデーションやコード生成を行うべきかを判断できます。 主要なJsonSchemaのバージョンとその説明を以下に記載します。 バージョン名 URI 説明 Draft 4 http://json-schema.org/draft-04/schema# 広く採用された初期のバージョンであり、現在のJsonSchemaの基礎部分が定義された。 Draft 7 http://json-schema.org/draft-07/schema# 現在、最も広く使われているバージョン。 if / then / else キーワードの追加により、複雑な条件に基づいたバリデーションが可能になった。 Draft 2020-12 https://json-schema.org/draft/2020-12/schema 最新安定版のバージョン。 $dynamicRef や $dynamicAnchor といったキーワードの追加で、より柔軟な再帰的参照が可能になるなど大規模なスキーマ定義がしやすくなった 実践: JsonSchemaを用いたバリデーション ここまで、JsonSchemaの基本的な概念と用途について説明しました。ここからは、Python のライブラリである Pydantic を用いて、実際のアプリケーションにおける JsonSchemaを活用したバリデーション方法を紹介します。 Pydanticとは Pydantic は、 Pydanticモデル と呼ばれる、Pythonの型ヒントとその型定義に基づいたデータバリデーション機能を持つクラスを生成できるライブラリです。 Pydanticモデルは型ヒントを最大限に活用するため、IDEの補完機能や、 mypy などの静的型チェッカーと連携できます。これにより、単なるデータのバリデーションに留まらず、コード記述時からミスを減らすことで、開発者の工数削減が期待できます。 JsonSchemaからPydanticモデルを自動生成する Pydanticモデルは手動で記述することもできますが、JsonSchemaからの自動生成が可能です。 今回、自動生成を datamodel-code-generator というツールを使用して行っていきます。本ツールは、JsonSchemaやSwaggerといったスキーマ定義から、Pydanticモデル（またはその他のデータクラス）を自動生成するためのコマンドラインツールです。 ※なお、本ツールは、 Pydanticの公式ドキュメント でも紹介されています (補足): Pydantic vs. JsonSchema Library PythonでJsonSchemaを使ったバリデーションを行うライブラリはPydanticだけではありません。例えば、 jsonschema （JSON Schema Library） というPythonライブラリも存在します。 それぞれの特徴の比較は、以下の通りです。 特徴 Pydantic JSON Schema Library JSON Schema標準への準拠 JSON Schemaのサブセットをサポートし、Pythonのデータモデルに最適化 JSON Schemaの標準仕様に厳密に準拠 パフォーマンス 高速（v2ではRustベース） 中程度（Pythonベース） 型安全性 Pythonの型ヒントに基づいてコードレベルでデータモデルの型チェックが可能 Pythonの辞書を直接扱うため、コード記述時のデータ構造の事前チェックは限定的 ライブラリの軽量性 多くの機能を持つため、比較的大規模。 検証に特化しているため、より軽量 学習コスト、依存関係  中程度（データモデルの知識が必要） 低い（JSON Schemaの知識のみ） 既存コード統合 導入に際して既存コードの改修が必要な場合がある  辞書ベースのデータをそのまま組み込み可能 カスタムバリデーション 豊富なバリデーター、カスタムロジック追加可 基本的な検証のみ エラーメッセージ 詳細で分かりやすい  基本的だが十分 実行時安全性 型エラーを事前検出 実行時エラーのリスク IDEサポート 補完・型チェック完全対応 辞書アクセスのみ データ変換 自動型変換・シリアライズ 検証のみ（変換機能なし） それぞれメリット・メリットがありますが、今回は、JsonSchemaから生成されるデータモデルをPythonのクラスとして扱いたい点、そして型安全性や開発効率のメリットを享受したい点から、Pydanticを用いてバリデーションを行っていきます。 datamodel-code-generator の導入と基本的な使い方 それでは、 datamodel-code-generator を導入し、実際にPydanticモデルを生成してみます 導入 pipを使ってインストールします。 pip install datamodel-code-generator 基本的な使い方 JsonSchemaの解説で用いた user_schema.json を例に、Pydanticモデルを生成してみます。 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/schemas/user.json", "title": "User", "description": "User profile data", "type": "object", "properties": { "id": { "type": "string", "format": "uuid", "description": "Unique identifier for the user" }, "name": { "type": "string", "minLength": 1, "maxLength": 100, "description": "User Name" }, "email": { "type": "string", "format": "email", "description": "User email" }, "is_active": { "type": "boolean", "default": true, "description": "User active status. active is true" } }, "required": ["id", "name", "email"] } user_schema.json ファイルと同じディレクトリで、以下のコマンドを実行します。 datamodel-code-generator --input user_schema.json --input-file-type jsonschema --output user_models.py --input user_schema.json : 入力となるJsonSchemaファイルを指定します。 --input-file-type jsonschema : 入力ファイルの種別がJsonSchemaであることを明示します。 --output user_models.py : 生成されるPythonファイルの出力先を指定します。 コマンドを実行すると、 user_models.py というPythonファイルが生成されます。 # generated by datamodel-codegen: # filename: user_schema.json # timestamp: 2025-07-01T08:54:39+00:00 from __future__ import annotations from typing import Optional from uuid import UUID from pydantic import BaseModel, EmailStr, Field, constr class User(BaseModel): id: UUID = Field(..., description='Unique identifier for the user') name: constr(min_length=1, max_length=100) = Field(..., description='User Name') email: EmailStr = Field(..., description='User email') is_active: Optional[bool] = Field( True, description='User active status. active is true' ) JsonSchemaで定義したデータが、Pythonの Pydanticモデルのクラスに 変換されています。 description や min_length 、 max_length といったJsonSchemaのプロパティごとの制約が、Pydanticの Field 関数に適切にマッピングされているのが分かります。 アプリケーションへの組み込みとバリデーション実行 生成されたPydanticモデルを使い、実際のJSONデータのバリデーションを行ってみましょう。不正なデータが入力された場合に、Pydanticがどのようにエラーを検知し、更に詳細なエラーメッセージをJSON形式で出力することを確認します。 from pydantic import ValidationError from user_models import User import json # JSONデータの例 json_data = { "id": "a1b2c3d4-e5f6-7890-1234-567890abcdef", "name": "Alice", "email": "alice@example.com", "is_active": True, } try: # JSONデータをPydanticモデルにパース（バリデーションも自動実行） user = User.model_validate(json_data) print("データは正常にパースされました。") print(user.model_dump_json(indent=2)) # 型ヒントの恩恵を受ける print(f"\\nユーザーの名前: {user.name}") # 不正なデータでのバリデーションエラー invalid_json_data = { "id": "invalid-uuid", # 無効なUUID "name": "", # 最小文字数違反 "is_active": "invalid-boolean" # パターン違反 # emailは必須項目 } User.model_validate(invalid_json_data) except ValidationError as e: print("\\n▼ カスタムエラーメッセージ") error_messages = {} for error in e.errors(): # locタプルをドット区切りの文字列に変換 # (例: ('address', 'city') -> "address.city") field = ".".join(map(str, error['loc'])) message = error['msg'] error_messages[field] = message # 辞書をJSONとして出力 print(json.dumps(error_messages, indent=2, ensure_ascii=False)) コマンドラインでの実行と出力結果です。 python input.py データは正常にパースされました。 { "id": "a1b2c3d4-e5f6-7890-1234-567890abcdef", "name": "Alice", "email": "alice@example.com", "is_active": true } ユーザーの名前: Alice ▼ カスタムエラーメッセージ { "id": "Input should be a valid UUID, invalid character: expected an optional prefix of `urn:uuid:` followed by [0-9a-fA-F-], found `i` at 1", "name": "String should have at least 1 character", "email": "Field required", "is_active": "Input should be a valid boolean, unable to interpret input" } この通り、JsonSchemaの定義に基づき、Pydanticが詳細かつ分かりやすいエラーメッセージを生成してくれました。これにより、どのフィールドでどのような問題が発生したのかを特定し、デバッグやエラーハンドリングを効率的に行うことができます。 実践: 動的カラムのバリデーション 次に、本記事の冒頭で触れた、PostgreSQLの jsonb 型カラムに保存されたユーザーごとに異なる形式のデータのバリデーションを行っていきます。 このJSONデータはキー名などに一貫性のないデータ形式であり、この課題を解決するため、JsonSchemaとPydanticを組み合わせた動的バリデーションのアプローチを導入します。 具体的には、ユーザーごとに異なるJsonSchemaをデータベースに保存し、アプリケーション実行時にそのJsonSchemaを読み込んでPydanticモデルを動的に生成し、バリデーションを行います。 ここでは、動的なデータの一例として、ユーザーの profile を表すJsonSchema（例： profile_schema.json ）を定義します。このスキーマは、実際にはユーザーごとにDBに格納されるJsonSchemaを模したものとして扱います。 { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://example.com/schemas/profile.json", "title": "UserProfile", "description": "User profile data. This can vary from user to user.", "type": "object", "properties": { "hobbies": { "type": "array", "items": { "type": "string" }, "description": "List of user hobbies" }, "hometown": { "type": "string", "description": "User's hometown" }, "favorite_programming_languages": { "type": "array", "items": { "type": "string", "enum": ["Python", "JavaScript", "Java", "Go", "Other"] }, "description": "Favorite programming languages" } }, "required": ["hobbies"] } この profile_schema.json は、 hobbies が必須の文字列配列で、 favorite_programming_languages は特定のenum値のみを許容する文字列配列、といったルールを定義しています。 JsonSchemaを読み込み、Pydanticモデルを動的に生成する 今回のケースように、 ユーザーごとにスキーマが異なり、実行時に動的にスキーマを切り替えてバリデーションを行う 場合は、 datamodel-code-generator などでのPydanticモデルの事前生成はできません。 このようなケースでは、Pydanticライブラリの create_model 関数を用いることで、実行時にJsonSchemaを読み込み、その内容に基づいてPydanticモデルを動的に生成し、 model_validate 関数でバリデーションを行うことができます。 以下のコードでは、JsonSchemaの型定義をPythonの型にマッピングするユーティリティ関数を実装し、これを用いてJsonSchemaからPydanticモデルを生成します。 import json from pathlib import Path from typing import Any, Dict, List, Type from pydantic import BaseModel, create_model, ValidationError, EmailStr from uuid import UUID # JSON SchemaのタイプをPythonの型にマッピング SCHEMA_TYPE_MAP = { "string": str, "number": float, "integer": int, "boolean": bool, "array": List, "object": Dict, } # JSON Schemaのフォーマット指定を特定の型にマッピング FORMAT_TYPE_MAP = { "uuid": UUID, "email": EmailStr, } def schema_to_pydantic( schema: Dict[str, Any], model_name: str, exclude_fields: List[str] = None ) -> Type[BaseModel]: # フィールド定義を格納する辞書 fields = {} # スキーマからプロパティ一覧を取得 properties = schema.get("properties", {}) # 除外フィールドリストを初期化（Noneの場合は空リスト） exclude_fields = exclude_fields or [] # 各プロパティを順次処理してPydanticフィールドに変換 for key, prop in properties.items(): # 除外対象フィールドはスキップ if key in exclude_fields: continue if "type" in prop: # フォーマット指定がある場合は専用の型を使用（UUID、Emailなど） if prop.get("format") in FORMAT_TYPE_MAP: field_type = FORMAT_TYPE_MAP[prop["format"]] else: # 通常のタイプマッピングを適用 field_type = SCHEMA_TYPE_MAP.get(prop["type"], Any) # フィールドが必須かどうかを判定 is_required = key in schema.get("required", []) default_value = ... if is_required else prop.get("default") # フィールド定義を追加（型, デフォルト値） fields[key] = (field_type, default_value) # 動的にPydanticモデルクラスを生成して返す return create_model(model_name, **fields) def validate_schema_data( data: Dict[str, Any], model: Type[BaseModel] ) -> Dict[str, Any]: """ 独立したスキーマデータを検証する関数 """ validated_data = model.model_validate(data) return validated_data.model_dump(mode='json') def main(): # profile_schema.jsonファイルを読み込み try: profile_schema = json.loads(Path("profile_schema.json").read_text()) except FileNotFoundError as e: print(f"エラー: {e}") return # profile_schemaのPydanticモデルを動的生成 ProfileModel = schema_to_pydantic( profile_schema, profile_schema.get("title", "UserProfile")) print("✅ 動的Pydanticモデル生成完了") print(f"モデル名: {ProfileModel.__name__}") print(f"モデルフィールド: {list(ProfileModel.model_fields.keys())}") # テストケース1: 正常なプロファイルデータの検証 valid_profile_data = { "hobbies": ["プログラミング", "読書", "映画鑑賞"], "hometown": "東京都", "favorite_programming_languages": ["Python", "JavaScript", "Go"] } try: validated_profile_data = validate_schema_data( valid_profile_data, ProfileModel) print("\\n✅ テストケース1: 正常プロファイルデータテスト成功") print(json.dumps(validated_profile_data, indent=2, ensure_ascii=False)) except ValidationError as e: print("❌ 予期しないエラー") print(e) # テストケース2: 不正なプロファイルデータの検証（必須フィールド不足・不正値） invalid_profile_data = { "hometown": "大阪府", "favorite_programming_languages": ["InvalidLanguage", "Python"] # hobbiesが不足している（必須フィールド） } try: validate_schema_data(invalid_profile_data, ProfileModel) print("❌ エラーが発生すべきでした") except ValidationError as e: print("\\n✅ テストケース2: 不正プロファイルデータテスト成功") print("▼ エラーメッセージ") # エラーメッセージを整理して表示 error_messages = {} for error in e.errors(): field = ".".join(map(str, error['loc'])) error_messages[field] = error['msg'] print(json.dumps(error_messages, indent=2, ensure_ascii=False)) if __name__ == "__main__": main() 出力結果は以下になります。 python input.py ✅ 動的Pydanticモデル生成完了 モデル名: UserProfile モデルフィールド: ['hobbies', 'hometown', 'favorite_programming_languages'] ✅ テストケース1: 正常プロファイルデータテスト成功 { "hobbies": [ "プログラミング", "読書", "映画鑑賞" ], "hometown": "東京都", "favorite_programming_languages": [ "Python", "JavaScript", "Go" ] } ✅ テストケース2: 不正プロファイルデータテスト成功 ▼ エラーメッセージ { "hobbies": "Field required" } おわりに 本記事では、 JsonSchema について、用途やバージョン、Pydanticモデルへの変換と活用方法について解説しました。 課題だったPostgreSQLの jsonb 型のような動的なカラムに保存される可変長のデータに対しても、JsonSchemaとPydanticの機能を組み合わせることで、実行時にスキーマを読み込んで動的にバリデーションを行い、柔軟なデータ構造を扱いながらもデータ品質とアプリケーションの信頼性を確保することが出来ました。 JsonSchemaは、JSONデータの信頼性を保証し、開発プロセスの様々な面の効率化もできる便利な定義だと実感したため、同じような悩みを持つ方は、ぜひ一度本記事で紹介した内容を試してみてください。 なお、次回は複数のアプリケーションで利用する共通のスキーマ定義やその管理方法など、さらにJsonSchemaを用いた実践的な内容ついて記事を書いていこうと思います。 どうぞよろしくお願いします。 The post 【実践】JsonSchemaとPydantic – 自由なJSONデータで動的バリデーションを実現する first appeared on Sqripts .

前編のおさらい 前編 となる「事前準備編」では、自動化に必要なツールとして Node.js VSCode Playwright の3つをインストールしました。この後編では、いよいよ自動化にトライしてみたいと思います。 ▼前編はこちら 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） テスト対象とテストケース 今回は、PlaywrightのWebサイトにあるデモ用のTODOアプリ https://demo.playwright.dev/todomvc/#/ を使ってみます。以下のような手順で、TODOアプリの基本的な動作をチェックすることにします。 テストケース：TODOアプリの基本操作 TODOアプリにアクセスする 新しいTODO項目「買い物リストを作成」を追加する TODO項目「買い物リストを作成」が追加されていることを確認する 2つ目のTODO項目「牛乳を買う」を追加する TODO項目「牛乳を買う」が追加されていることを確認する 最初のTODO項目を完了状態にする 残りのTODO数が「1 item left」と表示されることを確認する テストを記録する E2E自動テストを作成するには、実際のWebサイトへの操作を 記録 してテストコードを出力する方法と、まっさらな状態からテストコードを 記述 する方法の2通りがあります。実務上は、完全にまっさらな状態からテストコードを記述するのはちょっと面倒なので、記録した内容を元にコードを微修正するのが手っ取り早いです。 テストコードの記録はVSCodeの拡張機能を使って行います。Playwrightをインストールすると、VSCodeの左側に表示されているフラスコのようなマークから、現在作成されているテストの一覧や、新しいテストの記録などができるようになります。 Testingサイドバー Record Newをクリックすると、新しいウィンドウが立ち上がり、ページ内で実施したアクションが記録されていきます。 また、レコーディングウィジェットを使うと、要素の情報を取得したり、ページに正しい情報が表示されているかどうかの検証をセットしたりできます。 レコーディング中に表示されるウィジェット : レコーディングの停止。 ▲: 要素の情報の取得。クリックした要素の情報がVSCodeの Playwright タブに表示される。 : 要素が表示されていることを検証。 ab: 表示されている文字列の検証。 : 値（value）の検証。 <>: Ariaスナップショットの検証。 一連の操作と検証を記録すると、次のようなコードが生成されます。このうち、 await page から始まるものはページへの操作、 await expect から始まるものは検証ステップです。 import { test, expect } from '@playwright/test'; test('test', async ({ page }) => { await page.goto('https://demo.playwright.dev/todomvc/#/'); await page.getByRole('textbox', { name: 'What needs to be done?' }).click(); await page.getByRole('textbox', { name: 'What needs to be done?' }).fill('買い物リストを作成'); await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter'); await expect(page.getByTestId('todo-title')).toBeVisible(); await expect(page.getByTestId('todo-title')).toContainText('買い物リストを作成'); await page.getByRole('textbox', { name: 'What needs to be done?' }).click(); await page.getByRole('textbox', { name: 'What needs to be done?' }).fill('牛乳を買う'); await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter'); await expect(page.locator('body')).toContainText('牛乳を買う'); await page.getByRole('listitem').filter({ hasText: '買い物リストを作成' }).getByLabel('Toggle Todo').check(); await expect(page.locator('body')).toContainText('1 item left'); }); 記録したテストは、左側のツールバーから実行できます。 Test Explorer タブからテストを実行できる テストコードの解説 ここで、生成されたテストコードについて簡単に解説しておきます。 要素選択 テストコードの中で、繰り返し page.getByRole('textbox', { name: 'What needs to be done?' }) という表現が出てきました。これは、ページの中から特定の要素を探すための書き方です。要素とは、ページの中のある一部分を指します。ボタンやテキストボックスなどのパーツのことだと考えてください。 現代のE2Eテストでは、「要素がどんな意味を持っているか」を手がかりに画面内の要素（ボタン、入力フォームなど）を記述するのが一般的です。例えば、上記のコードでは以下のような意味を持つ要素を探しています。 役割が textbox である 名前（この場合は書いてあるテキスト）が What needs to be done? である 余談ですが、以前自動テストにトライしたことがある人は、 getByRole の代わりに getElementById のようなコードを書いたことがあるかもしれません。以前は自動テストのコードを書くときに id や class などを用いるのが一般的だったのですが、技術の進歩や考え方の変化により、現代では getByRole のように要素の役割やラベルなど「要素の持つ意味」を使ってテストコードを書くのが一般的になりました。こうした考え方の変遷については今後の連載で説明できればと思いますので、今の段階では一旦「最近は getElementById は使わないんだ」と覚えておいてください。 検証 TODO項目「牛乳を買う」が追加されていることを確認する が追加されていることを確認するために、次のようなコードが出力されています。 await expect(page.locator('body')).toContainText('牛乳を買う'); page.locator('body') とは、ページ全体のことを指します。このステップは、ページ全体のテキストが「牛乳を買う」という文字列を含むことを確認しています。 ページのどこかに「牛乳を買う」というテキストが入っていればOK 個人的な好みでは、このような「XXという文字が表示されている」ことを確認する検証ステップについてはこのように「ページのどこかに存在すればOK」としてしまうことが多いです。理由は、一つ前の節「要素選択」で説明したように、ページに表示されている文言を元に要素を探すことが多いため、重複になってしまうためです。 一方で、全く無関係のところに表示されている文言を取得してしまうケースも無くはありません。より厳密に記述したい場合は、次のように listitem ロールの中から探すようにすることもできます。 await expect( page.getByRole("listitem").filter({ hasText: "牛乳を買う" }) ).toBeVisible(); まとめ 前編・後編を通して、自動化に必要なツールの準備と、拡張機能を使った自動化の方法を学びました。 ここに取り上げたのはあくまで初歩の初歩ですので、もっと勉強すればより良い自動テストが実装できるようになります。一方で、前編の冒頭でも説明したように、いざ学ぼうとすると様々な時代の様々な手法が出てきてしまい、どのやり方が良いのか判断がつかないかもしれません。後編で紹介した id や class を使った要素探索が良い例で、ある時期のベストプラクティスが、その後アンチパターンとなってしまうことはままあります。 そこで次回は「E2Eテストの歴史」を取り上げ、なぜPlaywrightのようなモダンなツールが生まれたのか、過去のツールや手法との違いについて解説します。また、「レコードアンドリプレイ」や「ページオブジェクトモデル」、それに「テストピラミッド」など、E2Eテストの発展に影響を与えた重要な概念についても触れる予定です。 The post 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） first appeared on Sqripts .

こんにちは！みなさん、テストしてますか？ この連載では、モダンなE2Eテストの考え方をマスターするために、実践的なハンズオンから始まり、歴史的な背景や理論的な知識、そして実際のプロジェクトで活用するためのベストプラクティスまでを幅広くカバーしていきます。 E2Eテストのアイディアそのものは普遍的なものですが、いざ学ぼうとすると様々な時代のプラクティスが混在しており、どれを取り入れるべきか迷うことも多いと思います。この連載を通じて、現代的で実用的なE2Eテストの知識を体系的に身につけていただければと思います。 初回となる第1回では、理論よりもまず「動くもの」を作ることを重視し、Playwrightを使った実践的なハンズオンを通じてE2Eテストの基本的な流れを体験していきます。ちょっと長めなので前後編に分け、前編ではまず環境構築などの事前準備を進めていきます。 出来るだけプログラミングなどの知識が無くてもついていけるように書いていますので、初学者の方も怖がらずにトライしてみてください。あ、でも、みんな苦手なあの文字だらけの黒い画面のヤツはちょっとだけ出てきますから、頑張って克服しましょう！ 必要な環境 Playwrightはクロスプラットフォーム（Windows、Mac、Linux）で動作しますが、いくつかシステム制約が存在します。2025-08月時点の動作環境は次の通りです。 Node.js 20、22、または24の最新版。 Windows 10以降、Windows Server 2016以降、またはWindows Subsystem for Linux（WSL）。 macOS 14 Ventura以降。 Debian 12、Ubuntu 22.04、Ubuntu 24.04（x86-64およびarm64アーキテクチャ対応）。 また、本記事ではPlaywrightのコードを作成する際に Visual Studio Code （以下 VSCode ）の拡張機能を使いますので、VSCodeの最低動作環境も満たす必要があります。 1.6 GHz以上のプロセッサ 1 GB以上のRAM Windows 10および11（64ビット） macOS（Appleのセキュリティアップデートが提供されているバージョン。通常は最新バージョンとその2つ前まで） Linux（Debian系）：Ubuntu Desktop 20.04、Debian 10 Linux（Red Hat系）：Red Hat Enterprise Linux 8、Fedora 36 この記事では、WindowsとMacでの操作を説明します。 事前準備: Node.jsのインストール PlaywrightはNode.jsというランタイム（プログラミング言語を実行するための土台）の上で動作します。 CLI（コマンドラインインターフェース）を使う まずは、お使いの環境でCLI（コマンドラインインターフェース）を起動しましょう。CLIとは、普段みなさんが使っているグラフィカルユーザーインターフェース（GUI）とは異なり、テキストベースでコマンドを用いてコンピューターを操作するためのUIです。Windowsの場合はPowershell、Macの場合はターミナルというCLIアプリを使います。 Windows: スタートメニューを開き、「powershell」と入力してEnter（PowerShell） または「Windowsキー + R」を押して「powershell」と入力しEnter Mac: 「command（⌘） + スペース」を押して「ターミナル」と入力し、Enter（Spotlight検索でターミナルを起動） Node.jsのインストール PlaywrightはNode.js上で動作するため、まずNode.jsをインストールする必要があります。Node.jsは、JavaScriptをブラウザ外で実行できるようにするランタイム環境です。 公式サイト https://nodejs.org/ja/download に、各OS向けにインストール方法が記載されていますので、そちらにならってインストールしましょう。 Node.js公式サイトからインストールコマンドを確認できる 参考までに、MacOSにNode.jsとnpm（パッケージマネージャー、後述します）を、nvmというNode.jsのバージョン管理ツールを使ってインストールする方法を記載しておきます。こちらは上記の公式サイトから転載したものです。 # nvmをダウンロードしてインストールする： curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.3/install.sh | bash # シェルを再起動する代わりに実行する \. "$HOME/.nvm/nvm.sh" # Node.jsをダウンロードしてインストールする： nvm install 22 # Node.jsのバージョンを確認する： node -v # "v22.19.0"が表示される。 # npmのバージョンを確認する： npm -v # "10.9.3"が表示される。 CLIからのインストールがうまく行かない場合は、公式サイト下部にインストーラーへのリンクがあるので、そちらを使ってもOKです。 インストールの確認 インストールが完了したら、以下のコマンドで正しくインストールされたか確認しましょう。バージョン情報が表示されればOKです。 Windows/Mac共通 # Node.js のバージョンを確認 node --version # v22.x.x のような出力が表示されればOK # npm のバージョンを確認（Node.js と一緒にインストールされます） npm --version # 10.x.x のような出力が表示されればOK 事前準備: Visual Studio Code (VSCode) のインストール 次に、VSCodeをインストールします。VSCodeはオープンソースのエディターで、プログラミングをするときに使いますが、Playwrightのテストを簡単に記録・実行できる拡張機能なども用意されています。 VSCodeのインストール 公式サイトからインストールします。 https://code.visualstudio.com/Download ここは特に難しいところも無いので省略します。公式サイトに記載された手順に従って進めてください。 Playwright 拡張機能のインストール 次に、Playwright拡張機能をインストールします。VSCodeは様々な拡張機能をインストールすることで機能を追加できるのが大きな特徴です。Playwright拡張機能をインストールすることで、ブラウザのインストールなどの準備やテストの記録、管理などをVSCode上で出来るようになります。 以下のURLから拡張機能をインストールしましょう。 https://marketplace.visualstudio.com/items?itemName=ms-playwright.playwright Install をクリックするとVSCodeが開くので、ここでもInstallをクリックします。 Playwrightのインストール 続いて、Playwrightをインストールします。一つ上の節でインストールしたのはVSCodeの拡張機能でしたが、今度はPlaywright本体をインストールします。なお、VSCodeやNode.jsなどは一般的なアプリケーションと同様に一度インストールすればOKですが、Playwrightはプロジェクト（フォルダ）ごとにインストールする必要があります。 VSCodeで File > Open Folder の順にクリックし、フォルダを選択します。このフォルダの中にPlaywrightをインストールします。慣れていない人は、なるべく新しいフォルダを作って作業するようにし、うっかり大事なファイルが消えてしまわないようにしましょう。 インストールはVSCode上で行います。Windowsの場合は Ctrl + Shift + P 、Macの場合は Cmd + Shift + P を押し、コマンドパレットを開きます。 コマンドパレットからは、VSCodeの様々な機能にアクセスできます。まずは Install Playwright と入力し、Enterを押します。 コマンドパレットからPlaywrightをインストールする 次に、インストールするブラウザを選択します。特に好みがなければデフォルトのままで良いでしょう。 インストールするブラウザを選択する 前編のまとめ 前編では、Node.jsとVSCode、それからPlaywrightをインストールして、自動化に必要な準備を一通り終えました。慣れている方はスムーズに行くと思いますが、不慣れな方は結構時間が掛かったんじゃないでしょうか。もし分かりにくいところがあったら、筆者のXアカウント https://x.com/tsueeemura などで遠慮なく聞いてくださいね。 続く後編「テスト自動化編」では、さっそく最初のテスト自動化に挑戦してみますよ！ ▼後編はこちら 【第1回・後編】まずはやってみよう – Playwrightを使ったハンズオン（テスト自動化編） The post 【第1回・前編】まずはやってみよう – Playwrightを使ったハンズオン（事前準備編） first appeared on Sqripts .

イネイブリングQAについての連載、第4回となる今回は、開発組織に対して品質技術をイネイブリングしたその先の姿について考えてみたいと思います。 ＜QA活動のスキル伝達「イネイブリングQA」　記事一覧＞ ※クリックで開きます 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 【第3回】開発組織に品質技術を伝えるための2つのスキル 【第4回】品質技術をイネイブリングした先はどうなる？ 前回の記事 では、開発組織に品質技術を伝えていくために必要となる2つのスキルについて解説しました。 今回はその先のお話です。品質技術を伝えていったその先では、開発組織はどのような状態になっているのでしょうか。また、そのときQAはどのような位置づけになっているのでしょうか。 イネイブリングが進んだらQAエンジニアは不要？ QAエンジニアによるイネイブリング活動が進んでいき、開発者やPdMなどのロールが主体的に品質向上の取り組みを行えるようになった。そんな未来が訪れたとします。 イネイブリングQAとしてはまさに目指していた状態ですから、目的は達成したといえるでしょう。 しかし、開発組織がそのような、目指していた状態になったとき。QAエンジニアは何をするのでしょうか。安直に考えると、QAエンジニアの知識・スキル・業務自体をどんどん移譲していったら、QAエンジニアは不要になるようにも思えます。 もしかしたら、組織としても QAエンジニアの採用は大変だから、今いる最小人数で回せるようにしよう。できればゼロでもいいようにしよう。 派遣で来てもらっているテストチームの費用がかさんでいる。内製化の動きもあるし、段階的にテストチームをクローズしよう。 といった思惑があるかもしれません。その場合、イネイブリングによってQAのナレッジや業務を移譲していくことと、上記の思惑とがマッチします。イネイブリングQAは、がんばって自分たちの椅子を減らしているようにも見えてしまいます。 QAエンジニアのニーズはなくならない 私自身がQAエンジニアをやっていることもあり、ここからの話はポジショントーク的になってしまうかもしれません。しかしそれでも、QAエンジニアのニーズはなくならないのではないか、と思っています。 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩｜QA活動のスキル伝達「イネイブリングQA」 | Sqripts にて、1999年出版の『Automated Software Testing』（邦訳：『自動ソフトウェアテスト　導入から、管理・実践まで　効果的な自動テスト環境の構築を目指して』）に登場するシステム方法論およびテスト（SMT）チームの活動について紹介しました。 再度引用します。 チームメンバーは、次から次へとさまざまなプロジェクト開発チームの主任と一緒に作業をして、知識移転、その他の活動を遂行する。 Automated Software Testing あるチームで「イネイブリングしきった」となったとしても、他の開発チームでも同様の活動をできるかもしれません。ここは会社や開発組織の規模にも依存しますが、ある程度大きな会社であれば、数年でイネイブリング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採用市場の状況など外的な制約もありましたが）。 そして、開発者やPMなどのロールが主体的にQA活動を行い QAエンジニアがいなくても回る状態で品質を高めていけるのが理想 であると設定。そのために必要なのはイネイブリング活動である、という流れでイネイブリングQAに至りました。 繰り返しになりますが、理想形というのは組織によって異なります。開発者は開発に専念し、システムテスト以降はテストチームが担う、というスタイルが最適な組織もあると思います。 理想形を考えるうえでは、QA組織と開発組織の位置づけ・QAのロールなどの概念が関わってきます。以前の記事 【第1回】QA組織立ち上げの流れと組織の形 | Sqripts も関連しますので、こちらも参照してみてください。 なお余談ですが、2年ほどイネイブリングQAとしての活動をしてきた個人的な感触としては、イネイブリングQAとインプロセスQAとのハイブリッドなスタイルが比較的多くの開発組織にマッチするのではないかと考えています。インプロセスQAが開発チームでの実務を担いつつ、イネイブリングQAが仕組み化や技術移転を伝える、という両輪を回すのが良さそうです。 イネイブリングの仕方自体も試行錯誤して、理想の姿に近づけましょう 今回はイネイブリングQAの活動を行った先の姿について考えてみました。 「それぞれの組織で最適な姿を描きましょう」という月並みな結論になってしまいましたが、それでも大事なことに違いありません。 私自身、イネイブリングQAの活動の仕方自体を色々と試行錯誤してきましたし、今も続けている最中です。先に「開発者やPMなどのロールが主体的にQA活動を行いQAエンジニアがいなくても回る状態で品質を高めていける」を理想として進めていると述べました。この理想に向けて、開発チームの外から支援をしたり、あるときには開発チームに入り込んで活動をしたりとさまざまなやり方を試しています。 このような試行錯誤は大変ですが、開発者から「品質に関して考える機会が増えた」というコメントをもらったり、開発プロセスの色々な部分が可視化されたり改善サイクルが回ったりしているのを見ると「組織に良い変化をもたらせているのかもな」と感じてとても嬉しくなります。ここに、イネイブリングQAのやりがいがあるように感じています。 次回はイネイブリング活動をするのとは反対に、 QAが何を移譲されるのか 何ができるようになることを求められるのか といったイネイブリングを「される」側となる場合について考えてみたいと思います。 【連載】QA活動のスキル伝達「イネイブリングQA」 記事一覧 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【全文公開中】 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 【第3回】開発組織に品質技術を伝えるための2つのスキル 【第4回】品質技術をイネイブリングした先はどうなる？ The post 【第4回】品質技術をイネイブリングした先はどうなる？｜QA活動のスキル伝達「イネイブリングQA」 first appeared on Sqripts .

技術を土台にして自分なりのQAエンジニアを目指す本連載では、まず「テスト設計」を取り上げたいと思います。 例えば、情報処理技術者試験でテスト技法が問われるほか、テスト設計コンテストというイベントが開催されます。そのため、日本においては最も馴染み深いソフトウェアテストの技術の一つと言えるでしょう。 この記事では、私自身の経験を通じて得た「テスト設計」に対する考えを言語化し、皆さんにとってのヒントになることを目指します。 ▼前回の記事はこちら 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる この記事におけるテスト設計 「テスト設計」という言葉の意味や扱い方には、実は組織や人によって大きな違いがあります。 この記事では、以下のような定義をしたいと思います。 テストをする理由を具体化し、テストケースを作成することが目的のアクティビティ 一般的に、この記事で「テスト設計」としているプロセスは「テスト分析」「テスト設計」「テスト実装」といった複数のアクティビティに分割されます（ソフトウェアテスト技術者資格であるJSTQBの定義などが代表的です）。 それぞれを区別することには合理的な理由がありますが、この記事では説明を分かりやすくするため、これら一連の流れをあえて「テスト設計」という単一のプロセスとして扱います。 テスト設計という技術の捉え方 テストエンジニアとしてのキャリアをスタートさせたときに、最初に魅力的に感じたのはテスト設計でした。 テスト設計は「テストすべきこと」を捉え、構造的に整理して、テストケースに書き下す一連の活動です。これらは私自身が得意とする分析的な思考を活かせる活動だと感じたからです。 「テスト設計プロセス」という壁 一方で、「テスト設計プロセス」という考え方は、駆け出しだった私にはとっつきにくい概念でした。 まず現場において、テストの土台となるテスト計画がなかったり、「テストすべきことを段階的に詳細化する」という概念がない場合もあります。そのため、テストを設計するノウハウやリソースが十分でないこともあるでしょう。 また、「テストすべきこと」を発散させ、テストスイートやテストケースの形に収束させる作業は、簡単なものではありません。当時の私はそれにも気づけていませんでした。 テストケースを捉えることで壁を見通す 「テスト設計」というものを自分なりに深く理解するきっかけとなったのが、「テストケース」という概念を捉えたことでした。 テストケースとは、「テストを扱いやすい単位で定義するための成果物である ※ 」と私は捉えました。 「テスト」という活動は、多くの時間やリソースを要するにもかかわらず、曖昧で捉えどころがないものです。テストケースとは、その巨大で曖昧な活動を、プロジェクトや組織にとって扱いやすい単位に分割し、共通理解を促すために定義するものだと理解したのです。 テストケースは構造を持っています。そしてそれ自体が暗黙の前提や期待を形として表すものとして機能する性質があると捉えました。 テストには普遍的な課題があり、それを解決するための「テストケース」があり、課題とテストケースの間に「テスト設計」というプロセスがあると捉えることが、私にとっての最初のブレイクスルーでした。 壁を超えたとまでは言えませんが、「見通すことができた」という実感が湧いた瞬間でした。 ※発信する媒体やコンテキストによって「テストケース」の表現を変えることはあります テスト技法についての自分なりの理解を深める 「テストケース」を中心にテスト設計プロセスを捉え直すと、「テスト技法」についての理解が深まりました。 当初、「なんとなくルールにしたがって図を書いたり表を書いたりする」程度の理解をしていましたが、「テストケースを作るためにテスト設計は存在する」と考えると、様々なものが私の中で繋がりました。 「テストのスコープと網羅性を定義するための合理的な手法が存在し、それらを満たすテストケースを導出するものがテスト技法である」という理解をしました。 自分なりの理解をすることで、単に「それっぽい図を書く」ではなく、「目的意識を持って必要なテスト技法を使う」という、テスト技法の活用に対する主体性を手に入れることができたのです。 テスト対象の特性を理解する テスト設計する際には、「テストすべきこと」を考えることが必須となります。ちなみに、「テストすべきこと」はテスト観点、テスト条件、テスト要件など、現場によってさまざまな表現がされます。 これらはブレインストーミングとしてアドホックに導出することは有効ではありますが、様々な特性や手法を意識して導出することもひとつの方法だと考えています。 この中で重要だと考えているのは「テスト対象の特性を理解する」ということです。 テスト対象の特性としては、アーキテクチャスタイル/パターンや入出力の特徴や取り扱うデータの性質などが挙げられます。 これらの特性はテスト設計の方針やテストケースの形にも影響を与えます。 テスト対象の特性を踏まえた上でどのようなバグが発生しうるか、などはテスト設計の際に必ず考えておきたい点です。 専門性の組み合わせ 本連載のテーマのひとつである「専門性の組み合わせ」について、今回は「テスト設計」を軸に、テストエンジニアの基本的なタスクである「テスト実行」との関連を解説します。 テスト実行を通じてテスト設計にフィードバックする テスト設計とテスト実行を繋げるような技術としては、テスト実行とテスト設計を短いスパンで繰り返すような探索的テストというスタイルがあります。 探索的テストを明示的に選択していなくても、テスト実行で得られた気づきや知見の中で、「テストすべきこと」につながるものを見つけることがあります。こうした気づきについてフィードバックを行ったり、自らそれらをカバレッジする合理的なテストケースをすぐに作って実行できるようになります。 合理的に切り分けを行ったバグ報告ができるようになる 「テスト設計」とは「適切な形に分割する」という側面があることに言及しました。この専門性を別の角度から捉えると、バグ報告や調査の際に適切な切り分けができることに発展する可能性があります。 現実に起こっている事象から、構造的に理解して、バグの影響範囲や原因特定に必要な情報を提供することは、前提となる情報が仮説か事実かの違いだけで、実際にはテストケースの設計と同じような同じ思考プロセスを辿っています。 おわりに この記事では、テスト設計という技術について私がどのように向き合ってきたかを述べました。 なお、実務や学習においては「テスト設計」という単一のアクティビティという理解から、何をテストすべきかを見極める「テスト分析」、合理的なテストケースを導出する「テスト設計」、テストを実行可能にする「テスト実装」など、それぞれのアクティビティを意識することが、専門性をさらに高める鍵になります。 「テスト設計」を単に与えられたタスクとしてテスト観点やテストケースを書くのではなく、自分なりに必要性や目的意識をしっかりと理解して実施することは、自分自身の確かな土台となるはずです。 ▼前回の記事はこちら 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる The post 【第2回】テストを設計する専門性 first appeared on Sqripts .

こんにちは、セキュリティエンジニアの河村です。 今回はオライリー出版「セキュリティエンジニアのための機械学習」の書評をお届けします。 本書は、セキュリティエンジニアがこれからの時代に必要とされる 機械学習 の基礎的な考え方に入門するための書籍です。 ■ セキュリティエンジニアのための機械学習 （Chiheb Chebbi 著、新井 悠、一瀬 小夜、黒米 祐馬 訳／O’REILLY JAPAN） セキュリティエンジニアのための機械学習 情報セキュリティのエンジニアや研究者を読者対象とした機械学習の入門書。フィッシングサイト、マルウェア検出、侵入検知システムなどの情報セキュリティ全般の課題に対して、機械学習を適用することでどのようなことが可能になるのか？ 本書ではサイバーセキュリテ... 　詳細はこちら　 www.oreilly.co.jp 本の概要 本書で扱われている内容は幅広く、データサイエンスの基本（たとえばPandasの操作方法）から、SVM（サポートベクターマシン）などの古典的な機械学習（以下「 古典ML 」）、さらに CNN （畳み込みニューラルネットワーク）といったディープラーニング、 Deep Q-Network に代表される強化学習までをカバーしています。 そのため、理論を厳密に学ぶための専門書というよりも、「機械学習とは何か」を広くイメージできるよう構成された入門書となっています。 もちろん、ディープラーニングや強化学習といった最先端の内容には専門性が求められ、すべてを完全に理解するのは簡単ではありません。 しかしながら、たとえば「特徴量」や「正規化」といった基本的な考え方は、機械学習全体に共通するものであり、理系出身でなくても、本書で紹介される具体例を通じて体感することで、概念的な理解を深めることが可能です。 ※1 なお、本書は内容が多岐にわたるため、本書評は 前後編 に分けて掲載します。第一回となる本稿では、 古典的な機械学習を中心とした第3章まで の内容について、概要・得られる知見・ブログ執筆者である私の所感を整理して紹介します。 続く第二回では、 ディープラーニングや最先端の攻撃手法 など、より発展的な内容について取り上げる予定です。 それでは次節より、本書の内容を章ごとに追っていきます。 本書がお勧めできる読者層 読者層 おすすめ度 コメント 機械学習・統計の知識があり、セキュリティ分野に応用したい方 ★★★★★ 理論と実践が噛み合い、応用力が高まります。 サーバ監視業務に携わっている方 ★★★★★ 実務に直結する内容が豊富です。 セキュリティ分野のトレンドを広く浅く把握したい方 ★★★★★ 最新情報を網羅的に知ることができます。 セキュリティ関連のソフトウェア開発者 ★★★★☆ 実装のヒントが得られ、開発に活かせます。 ペンテスター ★★★★☆ マルウェアや攻撃手法の知識が深まります。 IoTテスター ★★☆☆☆ 新しい攻撃手法の理解のヒントにはなりますが、実用性はやや限定的です。 初心者セキュリティエンジニア ★★☆☆☆ 統計の基礎を先に学ぶことを推奨。やや難易度が高めです。 本書がお勧めできる読者層 ( ※1) 雰囲気だけでもいいので機械学習の理論のイメージを掴むことが大事な理由 例え理論を完全に理解出来なかったとしても、機械学習のプロセスやアルゴリズムの性質を知ることで、ブラックボックスになりがちな機械学習・AI関連の技術で行われてることにもある程度の想像力が付くようになります。 機械学習・AI分野の進歩は非常に早く、既知の技術が一年で時代遅れになることもざらです。しかし、セキュリティ業務を行うものはテキストに乗ってない脆弱性だからといって見落とすことは許されません。つまり今まで以上に想像力と慧眼(けいがん)が重要になってきてると言えます。 現在進行形で脅威度が増してるLLMに対するハッキング( https://genai.owasp.org/resource/owasp-top-10-for-llm-applications-2025/ )の手法などの理解には、本書で記載されてるようなデータ分析・機械学習の考え方は非常に重要です。できるだけ初心者の方にもわかりやすく伝えるつもりなので、少しでも理解の手伝いになれればと思っております。 章ごとの概要 章ごとに内容の難易度を主観で付けさせてもらいます。以下が難易度の指標です。 ★☆☆ 基本的な内容 ★★☆ 重要な内容、基本情報レベルの数学・技術要素あり ★★★ かなり発展的な内容 第1章 情報セキュリティエンジニアのための機械学習入門(★☆☆) 序章と第1章では、近年、機械学習やAIがセキュリティ分野でますます重要な役割を果たしていることが説明されています。 具体例として取り上げられているのが、 侵入検知システム（IDS） ※2 における異常検知です。IDSでは、通常とは異なる挙動（異常値）を識別する際に、機械学習の手法が非常に効果的であるとされています。これにより、ルールベースでは検出しきれない未知の攻撃への対応が可能になるといった利点があるのです。 こうした理論的な説明を踏まえ、第2章以降では実際にコードを動かしながら、より具体的な手法や実装を学べる構成となっています。 ※2 侵入検知システム（IDS）とは、ネットワークやシステムへの不正アクセスや異常な挙動をリアルタイムで検知するセキュリティ対策の仕組みです。 また、本書で紹介されているサンプルコードは、 Google Colaboratory 上で実行できるようになっています。実行環境の構築方法についても、序章にて丁寧に説明されています。 ただし、ブログ執筆者である私が実際に試したところ、Google Colaboratoryの仕様変更などの影響で、一部のコードがそのままでは再現しづらいケースが見られました。そのため、以下のような代替手段を検討してもよいでしょう。 実行環境の選択肢 ローカル環境で Jupyter Notebook ※3 を使用する 特に GPU を搭載した PC をお持ちの場合は、ローカル環境の構築が有効です。本書のほとんどのサンプルコードはそのまま動作します。 環境構築の詳細については、以下のようなサイトが参考になります。 https://ai-inter1.com/jupyter-notebook/ AWS や GCP などのクラウドサービスを利用する 本書のコードは比較的軽量であり、10年ほど前のゲーミングノートPCでも動作可能です。しかし、より発展的な内容に取り組む場合、高性能なPCが必要になるため、クラウドサービスを活用したほうがコスト面で有利になることがあります。 Google Colaboratory の有料版を利用する ブログ執筆者である私は未検証ですが、有料版では無料版の制限（インスタンスの維持時間、メモリ容量、ディスク容量など）が緩和されます。ただし、AWS や GCP のような高い拡張性はなく、コストパフォーマンスの面でもやや劣るため、あくまで学習用途として割り切って利用するのがよいと考えられます。 ※3 Jupyter Notebookは、コードの実行・可視化・ドキュメント作成を一つのインターフェースで行える、データ分析や機械学習に特化した対話型開発環境です。 機械学習によるモデル開発は以下のようなステップになります： 🗃 データセットの作成 ↓ 📥 データセットの読み込み・前処理 ↓ 🔍 探索的データ分析・特徴量エンジニアリング ↔ 🤖 モデルの訓練と評価 ↓ 🚀 デプロイ 2章以降ではこの流れも体験出来ます。 ※ 以下の図が更に詳細です https://www.researchgate.net/figure/Machine-learning-workflow_fig3_360998525 個人的な所感として、初心者が機械学習の学習で最初に最もつまずきやすいのは「環境構築」ではないかと感じています。実際、私自身も本書のサンプルコードを再現する際に、多くの困難に直面しました。 コードが動作しない原因を調べながら、環境依存の問題を解決していく過程では、 Linux の基本操作、Python のパッケージ管理、ソフトウェアのバージョン管理 など、セキュリティエンジニアとして重要なスキルを体系的に学ぶことができます。 確かに手間はかかりますが、その分得られる知見は大きく、将来的な技術的応用力にもつながります。ぜひ本書の内容を足がかりに、積極的にチャレンジしていただければと思います。 「セキュリティエンジニアのための機械学習」より 第2章 フィッシングサイトと迷惑メールの検出(★★☆) この章ではフィッシングサイトや迷惑メールの検知器の開発を通して、機械学習・ディープラーニングの初歩である、 ロジスティック回帰 、 決定木 のアルゴリズム、 NLP（自然言語処理） の技術を学びつつ、サンプルコードを通して実際に実装して学びます。 機械学習・ディープラーニングのアルゴリズムは大雑把に以下のように進化しました。 【統計モデル】 └─ ロジスティック回帰（線形分類の基本） 【単体学習器】 ├─ 決定木（ルールベースの非線形モデル） ├─ k-NN（距離ベースの分類器） └─ SVM（マージン最大化） 【アンサンブル学習】 ├─ ランダムフォレスト（決定木×多数決） └─ 勾配ブースティング（決定木×逐次学習） └─ XGBoost / LightGBM / CatBoost など --------------------------- ↑ ここまでが古典ML --------------------------------- --------------------------- ↓ ここからがディープラーニング ----------------------- 【ニューラルネットワーク系】 └─ ニューラルネット（多層パーセプトロン） └─ 深層学習（DNN, CNN, RNN）→ 2010年頃の初期のディープラーニング └─ BERT / GPT などの大規模言語モデル → モダンなディープラーニング ※ より詳しくは以下リンクの図を参照してください https://www.researchgate.net/figure/Development-history-of-classical-machine-learning-algorithms-since-the-1930s_fig2_360998525 ロジスティック回帰や決定木は機械学習の基本ではありますが、ベースとなる理論に線型代数、確立・統計の要素があったりと、特に文系の方にとって決して容易な内容ではございません。数学的な背景を知りたい方は以下のサイトなどを参照してください。 https://bellcurve.jp/statistics/course/26934.html 「セキュリティエンジニアのための機械学習」より フィッシングサイト検出器の開発(ロジスティック回帰・決定木) UCI Machine Learning Repository のフィッシングサイトのデータセットを用いて、演習を行います（※ 参考 https://archive.ics.uci.edu/dataset/327/phishing+websites ）。ここには各サイトのヘッダの有無、アドレスがIPアドレスか否かなどの 特徴量 ※4 が0、1で記されています。 UCI Machine Learning Repositoryのデータセット ※4 特徴量 とは、機械学習モデルが判断や予測を行うための入力データの要素（情報の断片）です。 この数字を 行列・テンソル としてプログラムが扱えるように加工することで、初めてロジスティック回帰を初めとする機械学習のアルゴリズムが実行可能となります。 ここでは sklearn 、 optuna 等のツールを用います。 sklearnとoptunaについて sklearn は機械学習のアルゴリズムが複数搭載されたPythonライブラリです。今回取り扱ってるロジスティック回帰などは sklearn を用いずに実装することも可能なので、理解を深めたい方は調べてみるとよいと思います。 ※ 参考 https://qiita.com/phyblas/items/375ab130e53b0d04f784 optuna は｢ ハイパーパラメータ のチューニング｣を行うためのライブラリです。ハイパーパラメータのチューニングでは機械学習で用いられるモデルの構造を調整することで、精度や速度を大幅に改善できるため、非常に重要な工程です。 sklearnの ロジスティック回帰 と 決定木 モジュールを用いて、 UCI Machine Learning Repository のデータセットで迷惑メールの検出を行います。これらはどちらも基本的な分類アルゴリズムですが、得意不得意があり、使い分けが重要となってきます。 観点 決定木（Decision Tree） ロジスティック回帰 （Logistic Regression） モデルのタイプ 非線形・木構造 線形モデル 予測の仕組み 条件分岐（if-then）による分類 特徴量の線形結合＋シグモイド関数で確率を算出 可視化 木の形で視覚的に理解しやすい 回帰係数を数式で把握する 特徴量の扱い カテゴリ・数値ともに柔軟に対応 数値的な特徴量が向いてる（要ワンホット） 前処理の必要性 基本的になし スケーリングやダミー変数化が必要なことも 過学習しやすさ 高（特に深い木） 中（正則化で抑制可能） パフォーマンス 単体では弱いが、ランダムフォレスト等で強化可 単体で高速・安定した性能 sklearnではそれぞれ以下のモジュールのクラスで容易に実装できます from sklearn.linear_model import LogisticRegression # ロジスティック回帰 from sklearn.tree import DecisionTreeClassifier # 決定木 X = training_data[:,:-1] y = training_data[:, -1] X_train, X_test, y_train, y_test = train_test_split( X, y, test_size=0.2, shuffle=True, random_state=101) このコードでデータセットを訓練用とテスト用に分割します。テスト用にはデータセットの20%を割り当て過学習を防ぎます。 以下のようなコードで処理を進めていきます。 ▲ロジスティック回帰を使った検出器の作成 LogisticRegression クラスのインスタンスを作成し、そのインスタンスに対して X_train と y_train を使って訓練（fit）を行い、学習済みモデルで X_test に対して予測（predict）を行っています。 交差検証を行ってる様子 cross_val_scoreは交差検証を行うための関数です。 コードの詳細については本書を参考にしてください。 ハイパーパラメータのチューニング ハイパーパラメータのチューニングとは、機械学習モデルの「設定値」を調整して、モデルの性能（精度や汎化性能）を最大化する作業のことです。先ほど紹介した optuna を用います。 チューニングが必要な理由： ハイパーパラメータの設定によって、モデルの性能は大きく左右されます。 正則化が強すぎる場合、過学習の防止にはなるものの、学習が不十分になり精度が低下します。 逆に正則化が弱すぎる場合、訓練データに過剰に適合し、汎化 ※5 性能が落ちてしまうこともあります。 ※5 簡単に言えば、「未知のデータに対しても正しく予測できる能力」のことを指します。 わずかですが、ハイパーパラメータのチューニングで検知の精度が向上してます。 決定木を用いた場合。sklearnを使う場合、ロジスティック回帰のときとパラメータの設定以外ほぼ同様の記述で済みます。 迷惑メールの検出器の開発(勾配ブースティング・NLP) 迷惑メールの検出器の開発にあたっては、機械学習・ディープラーニングのアルゴリズムの他に、自然言語を実際に処理して分析する技術が必要になります。この自然言語を扱うための技術を NLP（Natural Language Processing） といいます。 NLP(自然言語処理)の手順（30頁 図2-8より） 字句解析 テキストを単語や形態素に分割し、品詞を特定する ↓ 構文解析 文法構造（係り受け、句の関係）を解析する ↓ 意味解析 単語や文の意味を理解し、曖昧さを解消する ↓ 談話統合 複数の文をつなげて前後関係や指示語などを解釈する ↓ 語用論的分析 文脈・話者の意図・社会的背景などを踏まえて意味を補完する 「セキュリティエンジニアのための機械学習」より NLPを行うにあたって、言語情報を特徴量として利用できるようにするために tf-idf を使用します。tf-idfとは、文書内での単語の出現頻度と、他の文書群における出現頻度の逆数を組み合わせることで、その単語の相対的な重要度を算出する指標です。下記に簡略化した定義を載せます。 TF-IDF(t, d) = TF(t, d) × IDF(t) - TF(t, d) = 単語 t の文書 d における出現回数（または割合） - IDF(t) = log( N / (df(t) + 1) ) + 1 - N：全体の文書数 - df(t)：単語 t を含む文書の数 このように、 その文書でよく使われて、他の文書ではあまり使われていない 単語ほど、TF-IDFスコアが高くなり、その文書の“特徴的な語”として扱われます。 本書では、この計算を sklearn.feature_extraction.text モジュールの TfidfVectorizer クラスを用いて行います。 Pandas のDataFrameオブジェクトに迷惑メールリストを変換します。それを TfidfVectorizer でベクトル化します。 今回は LightGBM というマイクロソフトによって公開された 勾配ブースティング木 ※6 というアルゴリズムを用います。このアルゴリズムについて詳しくは第3章で記載されています。今回もハイパーパラメータのチューニングをoptuna で行ってます。 ※6 勾配ブースティング木（Gradient Boosting Decision Trees）は、たくさんの「決定木（Decision Tree）」を組み合わせて、高精度な予測を行う手法です。1本1本の木はそこまで賢くないけれど、「間違いを少しずつ直していく」ことを何度もくり返すことで、最終的にかなり正確な予測ができるようになります。 実行結果、この場合、98％の精度で迷惑メールを検出できました。 これで本章は終わりですが、章末には演習問題が載っています。時間に余裕がある方はこれらを解くことで理解が深まります。 第3章 ファイルのメタデータを特徴量にしたマルウェア検出★★★ 本章では機械学習アルゴリズムを駆使して、マルウェア検知器を実装しつつ、メモリ解析の手法や、ランダムフォレストなどの機械学習アルゴリズムについて学びます。 マルウェア解析の種類 マルウェア解析にも様々なアプローチがあります。以下のようなものがあります。 表層解析 ウイルス対策ソフトによるスキャン ハッシュ値の取得 文字列の抽出 PEヘッダ のちのちこれについて詳細に取り扱います 動的解析 マルウェア解析用サンドボックスを用いて、感染動作を記録する手法 生成する子プロセスの情報、TCPの通信などがここからわかります。 メモリ解析 感染PCのメモリダンプを分析する手法 Volatility3などを利用します。 また、マルウェアは検出を回避するために以下のような手段をとります。 検出回避の手段 難読化 ファイル寄生 パッキング PEヘッダとは PE(Portable Executable)は、Windowsで実行ファイルが正しく動作するための構造化フォーマットです。多くのマルウェアはこれを改ざんして検出を回避します。ここにあるインポート 、 エクスポート 、 タイムスタンプ などの情報はマルウェア解析にも役立ちます。 PEファイルの基本構造 PEファイル ├── ヘッダ │ ├── DOSヘッダ │ ├── PEヘッダ │ ├── オプショナルヘッダ │ └── セクションテーブル └── セクション ├── コード ├── インポート └── データ PEヘッダ解析には、PEview、PeStudio、Pythonのpefileといったツールを用いることが可能です。 特徴量エンジニアリング この章ではセキュリティブロガーであるPrateek Lalawniによって配布されたマルウェアのデータセット MalwareData.csv のデータをもとにマルウェア検出を試みます。以下の画像のように、このデータセットでは、各exeファイルのPEヘッダ情報がcsv形式で格納されています。 第一段階として、 探索的データ解析(EDA) を行います。探索的データ解析（EDA）とは、データを集計・要約・可視化しながら実際に中身を観察することで、傾向や異常値、特徴を把握する分析の初期ステップです。 探索的データ解析では以下のようなツールが用いられます。 ツール・ライブラリ 用途 備考 pandas データの集計・要約 describe() や groupby() などで統計量やグループ集計が可能 matplotlib 基本的な可視化 折れ線、棒グラフ、散布図などの描画に対応 seaborn 高機能な可視化 ヒートマップや箱ひげ図など、統計的グラフが得意 plotly インタラクティブな可視化 ブラウザ上で操作可能な動的グラフが描画可能 ydata-profiling（旧 pandas-profiling） 自動EDAレポート生成 一行で詳細な統計・可視化レポートを生成 Sweetviz 可視化中心の自動EDA 複数データセットの比較に適しており、HTML出力も可能 dtale GUIベースでEDA操作 pandasデータフレームをブラウザで直感的に確認・操作可能 本書では pandas-profiling が使用されているのですが、こちらは名前が ydata-profiling に変更されています（機能は同じです）。 このツールを使うと、データセットの各カラムについて、 値の分布 や 欠損値の有無 、 ゼロの割合 などを自動で可視化できます。 MalwareData.csv のデータセットにydata-profilingを用いてみました。以下のようなレポートが生成されました。 たとえば、MalwareData.csv の「legitimate」列では、値が 0 と 1 の2種類しかなく、そのうち約70%が 0（偽物）であることが一目でわかります（下図の赤い部分）。また、「VersionInformationSize」列では、0〜26までの数値が観測され、ゼロが約21%を占めていることがわかります。 このように、ydata-profiling を使うことで、 データの偏りや異常値、欠損の有無などを視覚的に確認 でき、前処理やモデリングの方針を立てやすくなります。 今回は、 ydata-profiling によって得られたレポートを眺める中で、「 legitimate 」と「 VersionInformationSize 」という2つのパラメータが特に気になりました。そこで、これらの関係を詳しく調べるために、 matplotlib を使ってそれぞれの分布を重ねて可視化してみたところ、両者の間に明確な違い（相関関係）があることが視覚的に確認できました。 こうやって見つけた関係を元に、手動で新たな特徴量を作り出すこともあります。また、不要な特徴量を削除することもあります。そうすることで機械学習アルゴリズムがよりうまくいきます。 以下に探索的データ解析(EDA)の流れを図にしました。 この④の工程が特徴量エンジニアリングです。 これらを 特徴量エンジニアリング といいますが、非常に重要でかつ専門的な工程です。kaggle(データサイエンスの実力を実践で試し、世界中と競い合えるオンライン競技場)などの上級レベルとなると、機械学習アルゴリズムへの知識量よりも特徴量設計が勝敗をわけることが多いです。 機械学習を用いた特徴量の分類 機械学習アルゴリズムを用いて、重要度の高い特徴量を選択することも可能です。本書ではsklearnの以下のライブラリを用いて、分類を行ってます。 ExtarTreesClassifier (複数の決定木を使って分類するアルゴリズム) RandomForestClassifier (ランダムフォレスト) GradientBoostingClassifier (勾配ブースティング) AdaBoostClassifier (AdaBoost) 以下のようなコードでパラメータ設定さえ正しく行えば、それぞれのアルゴリズムを比較的簡単に実装できます。第一段階として、特徴量を機械学習アルゴリズム(この場合ランダムフォレスト)を用いて選択します。 以下にランダムフォレストを用いた場合のコードの様子を示します。 ランダムフォレストの結果、選択された特徴量 その後、以下の第二段階のコードで得られた特徴量をパラメータに用いて、モデルを学習し、正答率を評価しています。 これはつまり、ランダムフォレストアルゴリズムを用いて、選択された特徴量で学習を行った結果、99.2％の確率でマルウェア検出に成功できたということがわかります。 詳しくは本書を読んで欲しいのですが、それぞれのアルゴリズムには得意不得意があり、今回のケースでも正答率に違いが出ています。プロのデータサイエンティストの場合、コストとの兼ね合いも含めて、これらを的確に選ぶ能力が求められます。 本書では次の節でAndroidマルウェアのデータセットを題材に SVM(Support Vector Machine) を用いた例も掲示されてます。 アルゴリズム名 分類 主な特徴 長所 短所 ExtraTreesClassifier バギング系 非常にランダムな決定木を多数構築 ・学習が高速・過学習しにくい ・解釈性が低い・ノイズにやや敏感 RandomForestClassifier バギング系 ランダムサンプリング＋特徴量選択の多数決 ・過学習に強い・特徴量の重要度が分かる ・推論が遅くなる・メモリ使用量が多い場合あり GradientBoostingClassifier ブースティング系 弱い学習器を順番に重ねて誤差を補正 ・非常に高精度・柔軟性が高い（回帰にも使える） ・学習時間が長い・過学習しやすい AdaBoostClassifier ブースティング系 誤分類に重みをつけて弱学習器を組み合わせ ・実装がシンプル・ノイズが少ないと高精度 ・外れ値に弱い・データの前処理が重要 SVM（Support Vector Machine） マージン最大化 マージンを最大化する超平面で分類 ・高次元データに強い・カーネルで非線形も対応可能 ・データが多いと遅い・ハイパーパラメータの調整が難しい 3章までで、概要レベルですが古典MLの代表的なアルゴリズムをPythonで実装する方法を学べました。 第3章までを読んで 第3章まででは、ロジスティック回帰・決定木・SVMといった古典的な機械学習アルゴリズムの実装を一通り体験することができました。今後公開予定の「第二回」では、AdaBoostやSVMとは異なるアプローチから発展した、現在のAI技術の主流である ディープラーニング について取り上げます。加えて、その応用例として、機械学習システムへの攻撃や、ディープラーニングを活用した マルウェア検知器 の実例も紹介する予定です。 将来的に機械学習・ディープラーニングエンジニアとして活躍したい方にとって、第3章までの内容は欠かせない基礎となります。本書には優れた演習問題も多数収録されており、これらに積極的に取り組むことを強くおすすめします。 The post 書評【セキュリティエンジニアのための機械学習】(第1回) first appeared on Sqripts .