技術を土台にして自分なりの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 .

帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える 【第9回】発想を促すヒント 【第10回】注意はしながら、恐れずに 最終回【第11回】論理をスキルの引出しに タイトルを変えながら、 論理の言葉 、論理の言葉で組み立てる 演繹的な推論 、帰納やアブダクションといった 蓋然的な推論 の基本を解説してきた連載も、今回で終わりです。 最後に論理のスキルについて補足を少々述べて締めくくりたいと思います。 三つの推論形式・まとめ これまでに紹介してきた推論の特徴をまとめました。 図11-1 演繹、帰納、アブダクションの特徴 各推論の形については 実践編第1回 、そして 本連載第1回 でも説明しています。 関連記事 論理のかたち。推論とは｜ソフトウェアエンジニアのための論理スキル［実践編］ エンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する」「文... 　続きを読む　 Sqripts 関連記事 【第1回】見つけるための論理｜実務三年目からの発見力と仮説力 帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意す... 　続きを読む　 Sqripts 「AI時代」と論理のスキル 連載の間に、生成AIやLLM(大規模言語モデル)はソフトウェア開発業務にも浸透してきています。 この「AI時代」に、論理のスキルは（どんな面で、どう）活躍するでしょうか。 出力のレビュー①演繹的なチェック ハルシネーションに代表される「生成AIの出力を盲信する危険性」はつとに指摘されている通りです。 AIの出力を利用しようとする時には、内容面と論理面で問題がないかの レビュー が重要です。 内容に問題はないか 前提、結論(主張)は正しいか 論拠や典拠(参考文献の類)は正しいか（実在するか。正しく用いているか） 前提から結論(主張)までの筋道に矛盾・不整合や飛躍は見当たらないか 出力のレビュー②帰納面のチェック 『AI時代の質問力　プロンプトリテラシー』によれば、帰納的推論は生成AIの得意とするところです。 (略)複数の実例から背後にあるパターンを見出す「帰納」の能力は 機械学習モデルの真骨頂である。 (略)「帰納」は論理的な飛躍を含む。これは機械学習モデルの特徴であると同時に、 コンピュータが人間のように間違う一因でもある。 『AI時代の質問力　プロンプトリテラシー』p. 106 生成AIは蓄えたデータの量が人間より遥かに多いこと、人間が見落としそうな細部の特徴も“憶えている”ことから、共通する特徴を持つ複数の事例を見つけることに長じているのは頷けます。 人間が行なう帰納的な推論を（相当程度）肩代わりしたり補完したりしてくれるかも知れません。 とはいえ、生成AIが“間違える”可能性はありますから、帰納面のチェックは欠かさないようにしましょう。 挙げられた事例は適切か？ どこに共通項を見出したのか？　その共通項は適切か？ etc. 出力のレビュー③アブダクション AIに発見的な推論をさせるといった使い方も考えられます。 私たちが簡単には思いつかないようなもっともらしい「仮説」を“考えて”くれるかも知れません。 が、その出力をレビューする必要があるのは、先述の演繹的なチェックや帰納面のチェックと同様です。 （仮説のもっともらしさや検証可能性を、人間と同じように生成AIが“考えて”いるとは限りません） よい仮説の4つの条件 ( 第7回 、 第10回 )に照らして問題はなさそうか(特に、もっともらしさと検証可能性) 結論に至る道筋に問題はないか （AI相手に限らず）よいレビューのために こうして見てくると、人の思考過程や成果物をレビューする時と違いはありませんね（当然といえば当然ですが）。 論理のスキルを高めることは、レビューのスキルを高めることにつながる……とは言い切れないかも知れませんが、人間でもしばしば起こる「ロジックの誤り」はレビューで見つけたい誤りのひとつです（ 実践編第1回 「「真」と「妥当」」参照）。 図11-2 レビューの視点のひとつ 生成AIの名誉？ のために書き添えると、先述のように彼らの蓄えているデータの量と細部の“記憶”は厖大 (ぼうだい) ですし、人間が思いもつかないような“着眼点”の出力を出してくることもあります。 AIの“思考過程”をなぞってみるのは、自分の思考過程の整理や振り返りにもなるでしょう。 その特性を活かしながら、彼らの不得意なことを見逃さずに賢くつき合っていきましょう。 プロンプトづくり 出来の悪い出力を改善するよりは、出力の質を高める方が楽です。 よい出力を得るためのプロンプトづくりは、プロンプトエンジニアリングと呼ばれ、プログラミングにもたとえられます。 よいプロンプトを組立てる際に、演繹的な推論のスキルが貢献するでしょう。 （作ったプロンプトのレビューも含め） 答えて欲しい事柄や、出力の作り方（資料の集め方、推論の組み立て方、出力の体裁、etc.）を具体的に、 理路整然と 指示する 矛盾や不整合のない 指示を組立てる スキルの名前は覚えなくても できている人は 「本連載の内容、自分はできている（んじゃないかな）」「いや日々普通にやってるんだが？」と感じた人は、素晴らしいです。引き続き日々の暮らしや仕事でがしがし使ってください。 実際に使えることが大事 「この連載で初めて論理の言葉とか、推論の形とか、その意味を知った」という人や「できてるかどうか自信ない」と感じた人は、なんとか三段論法とか、アブダクションとか、そんな名前は覚えなくてかまいません。 仕事の場や暮らしの中で、 「論理を意識する」ということを意識 してみてください。 思い込みや予断に気をつけながら、事実に即して、筋道を意識して思考を働かせましょう。 「なんとなく」や「直感」かと思っていたことが 実はそうじゃなかった と感じられるかも知れません。 「でもそれにはちゃんと裏づけがあることまでは意識していなかった」とも感じるかも知れません。 あるいは、今までは「なんとなく」や「直感で！」でやっていたことが、 そうじゃなくなった！！ と感じられるかも知れません。 そういう体験をするうちに、論理のスキルが頭に沁み込んでくるでしょう。 図11-3 名前は覚えなくても 名前を覚えることにも意味はある 論理のスキルの名前を覚えることにももちろん意味やメリットはあります。 個別の具体例から離れて、推論の形（帰納、選言三段論法、etc.）を 名前で指す ことができる 論理の働きを 形(の名前)で表してメタ的に振り返る ことができる 思考の過程を俯瞰しやすくなる プログラミングで言えば、ライブラリ/メソッド(関数、手続き)の名前を言えばどんな処理をしてどんな結果が得られるか通じる、とか、ソフトウェアテストで言えば、テスト技法の名前を言うことでどんなテストケースか概ね把握できるようなものです。 図11-4 名前で指せると捗ることも ★★★★ 連載におつき合いいただき、ありがとうございました。 論理スキル[再]入門第1回 で触れましたが、私たちソフトウェアエンジニア(テストエンジニアを含む)の仕事は論理とのつき合いは避けて通れません。 この記事たちが、皆さんが自分のスキルの引出しに論理のスキルを加える手助けになれていたら幸いです。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 アンリ・ポアンカレ(著), 南條郁子(訳) 『科学と仮説』 筑摩書房 2022 岡瑞起, 橋本康弘 『AI時代の質問力　プロンプトリテラシー』 翔泳社 2024 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える 【第9回】発想を促すヒント 【第10回】注意はしながら、恐れずに 最終回【第11回】論理をスキルの引出しに The post 最終回【第11回】論理をスキルの引出しに｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

テストエンジニアのユッキーです。 普段は自動化担当部署で、お客様のテスト自動化導入をご支援したり、社内の自動化技術の研究開発に携わっています。 皆さんの周りでも、「AI」という言葉を聞かない日はないのではないでしょうか。ある調査では、2024年のソフトウェア開発トレンドの第1位が「生成AI」で、半数以上の開発者が実際に導入しているという結果も出ています 。この大きな波は、私たちテストエンジニアの仕事にも確実に押し寄せています。 しかし、「AIがテストを自動化する」という言葉だけが先行し、具体的に「何が」「どのように」変わるのか、現場目線での実感はまだ少ないかもしれません。そこで今回の記事では、流行りの言葉としてAIを語るのではなく、日々の業務で向き合っているテスト自動化の現場で長年課題とされてきたことを、最新のAI技術がどのように解決しようとしているのか、その実態に迫ってみたいと思います。 具体的には、「自己修復（セルフヒーリング）」、「AIビジュアルリグレッションテスト」、そして「生成AIによるテストケース生成」という3つの重要な技術トレンドを掘り下げ、私たちテストエンジニアの日常がどう変わっていくのかを、具体的なツールの動向も交えながら考察していきます。 AIが解決する、テスト自動化の根深い課題 テスト自動化に取り組んだことがある方なら、誰もが一度は直面するであろう「根深い課題」があります。それは、テストスクリプトの「メンテナンスコスト」と「脆弱性」です。UIのちょっとした変更でロケータが外れてテストが失敗し、その修正に多くの時間を費やす…という経験は、皆さんにもあるのではないでしょうか。 この問題は非常に深刻で、ある調査によると、企業におけるテスト全体の自動化率は平均で33%に留まっているそうです。多くの企業が、メンテナンスコストの高さから自動化の範囲を広げられず、依然として手動テストに大きく依存しているのが現実です。ソフトウェアテストにおける最大の悩みとして、「コストの肥大化」と「開発期間の長期化」が挙げられていることからも、この課題の根深さがうかがえます。 こうした状況の中で登場したのが、AIです。AIは私たちエンジニアの仕事を奪う存在ではなく、むしろ強力な「アシスタント」や「副操縦士（Copilot）」として、最も時間と手間がかかる反復的な作業や、不安定な部分を引き受けてくれる存在です。AIに面倒な作業を任せることで、私たち人間は、より戦略的で創造的な、付加価値の高い業務に集中できるようになります。 この価値は単なる効率化に留まりません。メンテナンスに追われる時間を削減できれば、そのリソースを新機能の探索的テストや、セキュリティの脆弱性分析といった、品質を本質的に高める活動に再投資できます。つまり、AIの導入は、単なる生産性向上だけでなく、品質と開発スピードに対するビジネスリスクを軽減するための戦略的な一手となり得るのです。 テストの現場を変える3つのAI技術トレンド それでは、AIが具体的にどのような技術で私たちの課題を解決してくれるのでしょうか。ここでは、特に重要と思われる3つのトレンドを詳しく見ていきましょう。 1. メンテナンス工数を劇的に削減する「自己修復（セルフヒーリング）」 テスト自動化における最大の悩みの一つが、UIの変更によるテストスクリプトの破損です。ボタンのIDやクラス名が少し変わっただけでテストが失敗し、その度に修正が必要になるのは、本当に骨の折れる作業です。この「テストの脆弱性」という長年の課題に、正面から向き合うのが「自己修復（セルフヒーリング）」技術です。 自己修復とは、テスト実行時にアプリケーションのUI変更をAIが自動で検知し、テストスクリプトをその場で修正してテストを続行する仕組みです。この魔法のような技術は、主に以下の3つのステップで機能します。 要素の特定（Element Identification） : 従来のテストツールがXPathのような単一で壊れやすい情報に依存していたのに対し、AIを搭載したツールは、要素をより豊かに「指紋認証」のように捉えます。ID、name、CSSクラス、テキスト内容、さらには画面上の相対的な位置関係や視覚的な特徴まで、複数の属性を総合的に記録します。これにより、一つの属性が変わっても、他の情報から「おそらくこの要素だろう」と推測できる、堅牢な識別が可能になります。 問題の診断（Issue Diagnosis） : テスト実行中に、記録されていた主要なロケータで要素が見つからなかった場合、AIは即座にテストを失敗させません。代わりに診断モードに入り、保持している他の属性情報（指紋）を元に、変更後のUIの中から最も一致する要素を探索します。 自己修復アクション（Self-Healing Action） : AIが「これが探していた要素だ」と高い確信度で再特定できた場合、テストスクリプト内の古いロケータを新しい、正しい情報に自動で更新します。これにより、現在のテストをパスさせることができるだけでなく、将来のテスト実行もより安定したものになります。 この自己修復機能によって、私たちはロケータ修正という不毛な作業から解放され、CI/CDパイプラインの安定性を劇的に向上させることができます。結果として、メンテナンスコストの削減、迅速なフィードバックの実現といった、計り知れないメリットがもたらされるのです。 2. 人間の眼を超える「AIビジュアルリグレッションテスト」 Webアプリケーションの見た目（UI/UX）は、ユーザー体験に直結する非常に重要な要素です。しかし、そのテストは非常に難しいものでした。従来の「ピクセル比較」によるビジュアルリグレッションテストは、広告やアニメーションといった動的コンテンツ、あるいはブラウザ間のわずかなレンダリング差にまで反応してしまい、「偽の失敗（False Positive）」を大量に発生させるという問題がありました。 この問題を解決するのが、「AIビジュアルリグレッションテスト」です。Applitoolsのような先進的なツールが採用しているこの技術は、AIの画像認識（コンピュータビジョン）と機械学習を用いて、人間の眼のようにUIを評価します。単にピクセルを比較するのではなく、ページの構造や文脈を理解しようと試みるのです。 AIが可能にする主な機能は以下の通りです。 レイアウト比較（Layout Comparison） : AIは、要素の配置やサイズ、重なりといったレイアウト構造を理解します。そのため、「ボタンの位置が5ピクセルずれた」「テキストが画像に重なってしまった」といった、ピクセル単位の比較では見逃しがちな、しかしユーザー体験にとっては致命的なデザイン崩れを正確に検出できます。 動的コンテンツの無視 : テストエンジニアは、AIに対して「この領域は広告なので無視して良い」「ここはタイムスタンプなので毎回変わる」といった指示を与えることができます。これにより、意図しない変更によるノイズを劇的に減らし、本当に重要な視覚的バグだけに集中することが可能になります。 文脈の理解（Contextual Understanding） : 高度なAIは、変更の文脈を理解することさえできます。例えば、「購入ボタン」が消えてしまうといった致命的なバグと、商品画像が新しいものに差し替わるといった意図した変更を区別し、前者のみを重大な問題として報告します。これは、単なる画像比較から、ユーザーへの影響度を考慮した品質保証への進化と言えるでしょう。 3. 「仕様書」からテストを創り出す「生成AIによるテストケース生成」 これまで紹介した2つの技術がテストの「メンテナンス」と「実行」を革新するものだとすれば、この「生成AIによるテストケース生成」は、テストプロセスの上流である「設計」と「作成」のあり方を根底から変える可能性を秘めています。 これは、テストエンジニアが要件定義書や仕様書を読み解き、手作業でテストケースに落とし込んでいたプロセスを、AIが代行するというパラダイムシフトです。 自然言語からの生成 : TestsigmaやFunctionizeといったツールでは、私たちが普段使っているような自然言語（日本語や英語）で書かれた機能説明やユーザーストーリーをAIに与えるだけで、実行可能なテストスクリプトやテストケースを自動で生成できます。これにより、プログラミングスキルを持たないQA担当者やビジネスアナリストも、テスト自動化に直接関与できるようになります。 ユーザー行動分析からの生成 : さらに先進的なアプローチとして、testRigorのようなツールは、本番環境で実際のユーザーがどのようにアプリケーションを操作しているかを分析し、最も頻繁に使われる重要な業務フローをカバーするテストを自動で生成します。これにより、テストリソースを「ユーザーにとって本当に価値のある機能」に集中させることができ、効率的かつ効果的な品質保証が実現します。 AIが生み出すのは、単なるテスト手順のリストではありません。テストに必要なデータや、SeleniumやPlaywrightといったフレームワークで直接使えるコードまで、包括的なテスト資産を生成してくれるのです。 これら3つの技術トレンドは、テスト自動化ツールの進化の道のりを示していると考えることができます。まず、発生した問題に「反応」する自己修復。次に、問題の発生を「予防」するAIビジュアルテスト。そして最後に、何もないところから新しいテスト資産を「創造」する生成AI。この進化の先に、私たちの新しい働き方があります。 最新AIテストツール動向と統合プラットフォームの価値 現在、市場にはこれらのAI技術を搭載した優れたツールが数多く存在します。自己修復に強いTestim、ビジュアルAIの先駆者であるApplitools、ローコードAIで定評のあるmablなど、それぞれが特定の領域で高い専門性を発揮しています。 しかし、個別のツールを組み合わせるだけでは、テストプロセス全体が分断され、かえって非効率になることがあります。テストケースはExcelで管理し、自動実行は別のツールで行い、結果報告は手作業でまとめる…といった具合です。この課題を解決する次なるトレンドが、「統合プラットフォーム」という考え方です。 以下の表は、これまで説明してきたAI技術と、統合プラットフォームがどのような位置づけにあるかをまとめたものです。 機能 (Capability) 概要 (Description) 解決する主要な課題 (Key Problem Solved) 自己修復 (Self-Healing) UI変更時にテストスクリプトの要素ロケータをAIが自動で検知・修正する機能。 テストスクリプトのメンテナンスコストと脆弱性の削減。 AIビジュアルリグレッション AIがレイアウトやコンテキストを理解し、意味のある視覚的バグのみを検出する機能。 動的コンテンツによる誤検知（False Positive）の抑制と、UI/UX品質保証の精度向上。 生成AIテストケース作成 自然言語の仕様書やユーザー操作ログから、AIがテストケースやスクリプトを自動生成する機能。 テスト設計・作成工数の大幅な削減と、カバレッジの向上。 統合テストプラットフォーム 上記のAI機能を個別にではなく、テストライフサイクル全体で一貫して提供する基盤。 テストプロセス全体の分断をなくし、設計から報告までのシームレスな効率化を実現。 この統合プラットフォームという考え方を体現しているのが、私たちAGESTが開発している「 TFACT（ティファクト） 」です。TFACTは、特定の機能に特化したツールではなく、QAライフサイクル全体を包括的に支援するAIアシスタントとなることを目指して設計されています。 TFACTは、単にテストを実行するだけではありません。 AIテスト手順作成 : テストの設計段階からAIがアシストします。 AIテスト自動実行 : もちろん、堅牢な自動実行機能を備えています。 AIテスト分析と自動デバッグ : さらに、テスト結果がNGだった場合に、ログをAIが分析してコード上の問題箇所を特定するのを助け、デバッグ作業を効率化します。 AIインシデントレポート : そして、分析結果を元にインシデントレポートの作成までを自動化し、報告という最後の面倒な作業までをサポートします。 このように、設計から実行、分析、報告まで、テストプロセス全体を一気通貫でサポートすることで、プロセス間の断絶をなくし、テスト工数を全体で30%削減するような、本質的な効率化を目指しているのがTFACTの大きな特徴です。 まとめとエンジニアとしての所感 今回は、AIがテスト自動化の世界をどのように変えようとしているか、3つの主要な技術トレンドと、統合プラットフォームという未来の方向性について見てきました。AIは、メンテナンス、ビジュアル検証、テスト作成といった長年の課題に具体的な解決策を提示し始めています。 最後に、一人のテストエンジニアとして、今回のテーマについて感じたことをいくつかまとめてみたいと思います。 AIは「バズワード」から「実用的なパートナー」へ 自己修復のような技術に触れると、AIがようやく流行りの言葉から、現場の痛みを理解してくれる実用的なパートナーに進化したことを実感します。壊れたロケータを延々と修正し続ける、あの単調なサイクルから解放されるだけでも、私たちはより創造的で本質的な「考える仕事」に時間を使えるようになります。これはエンジニアとして純粋に嬉しい変化です。 問われる「AIを見極める力」 一方で、「AI搭載」を謳うツールなら何でも良いというわけではない、という点も強く感じています。汎用的なLLMを薄くラップしただけのようなツールもあれば、何十億ものテストデータで学習させた専門的な機械学習モデルを搭載したツールもあります。私たちエンジニアに次に求められるのは、ツールのAIが持つ「質と深さ」を評価する力ではないでしょうか。どのようなデータで、どのようにモデルを学習させているのか、複雑な現実のシナリオにどこまで対応できるのか、といった批判的な視点を持つことが重要になると思います。 「QAストラテジスト」への進化 TFACTのような統合プラットフォームがテストプロセス全体を支援してくれる未来を考えると、私たちテストエンジニアの役割は、「AIテストの指揮者（オーケストレーター）」や「QA戦略家（ストラテジスト）」へと進化していくように思います。私たちの仕事は、高レベルなテスト戦略を定義し、AIを教育・指導し、AIが提示する複雑な分析結果を解釈することへとシフトしていくでしょう。「作業する人」から「戦略を立て、監督する人」への変化は、非常にエキサイティングな未来だと感じています。 AIと共に、テスト自動化の世界は新たな地平を迎えようとしています。次回以降も、TFACTの具体的な機能など、さらに踏み込んだテーマについてお伝えしていければと思います。 関連情報 AIテストツールTFACT The post テスト自動化の新たな地平：AIはテストエンジニアの日常をどう変えるのか？最新トレンドとツールの実態に迫る first appeared on Sqripts .

皆さん初めまして、QAコンサルタントのノブです。 私はこれまで、大手IT企業等の品質管理部門を長年担当し、様々なプロジェクトの商談判定・監査/監視・レスキュー対応・PMO支援・社内研修等を実施してきました。 その経験の中で、多くの問題プロジェクトで共通することは、”引継ぎ”に関する取組みが不十分、又は全く考慮されていないという点でした。 ”引継ぎ”の対策が不十分であれば、何が問題になるのか、どのように対応すべきかを紹介させて頂きます。 ブラックボックス化による弊害 システムを開発･運用するためには、様々なITスキルと業務知識が要求されますが、簡単に身につくものではありません。現実的には、要員や予算･納期等の事情により、特定の人物に業務固定化･ノウハウ集約が進んで、ブラックボックス化するケースが多く発生しています。このような状況になると、下記のような弊害が発生します。 ドキュメント化がされていない、又は最新化漏れのため、実際の仕様が把握出来ない。 改善･最適化を実施するうえで、客観的な判断や効果的な施策が出来ない。 設計時の仕様決定や課題の切り分け時に特定人物に負荷が集中する。(ボトルネック化) ナレッジ化が出来ていないため、スキルトランスファーに時間が掛かる。 →　新規プロジェクト/トラブル発生時に、増員メンバーの生産性/品質が低下する。 キーマンの病欠･所属変更･休職･離職に伴うリスクが非常に高い。 ウォーターフォール開発(WF)における分業化と問題 私がシステム開発に携わり始めた1990年代は、要件定義→設計→開発→テスト→保守が、同一のサプライヤーで開発･運用されることが一般的でした。 そのため、システム企画段階から関与した会社･メンバーが一貫して従事することで、品質を担保することが出来ていました。 しかしながら現在は、企画はコンサルティング会社、設計はA社、開発はB社×複数(オフショア開発含む)、テストはC社、運用はD社と、工程の分業化が進んでいます。 ここで問題となるのが、工程間の業務引継ぎです。 引継ぎの際には設計書の品質が一番重要であり、後工程のサプライヤーは、設計書に記載されていないことは、開発もテストも実施することが出来ないのが実態です。 私が関与したQCDが問題化したプロジェクトでは、設計書のレベル(資料構成･記載項目･記載内容等)が、全て不十分な状況となっていて、後工程で多くの問題が発生していました。 開発担当者及びテスト担当者にとって、仕様の行間を読み取ることは困難であり、要件定義等で確認した背景･検討事項も把握していないため、記載不備=不具合となってしまいます。 またサプライヤー間の壁(利害関係)に加え、昨今はリモート開発によるコミュニケーション密度の低下により、業務･工程引継ぎや仕様調整の難易度は上昇しています。 このため、引継ぎ時及び後工程では様々なコンフリクトが発生し、QCD悪化のみならず、プロジェクト全体の雰囲気(コミュニケーション)が悪化するという事象が発生しています。 引継ぎの円滑化によるメリット ブラックボックス化(属人化)が防止できて、円滑に仕様継承とスキルトランスファーが出来れば、下記のようなメリットがシステム開発に出てくると考察します。 後工程での仕様漏れ･仕様誤認が大幅に減り、システムの品質が向上する。 新メンバーの仕様理解が進み、QA数が大幅に削減できる。 担当者の理解度が向上し、生産性･品質が向上する。 キーマンへの負担が減り、本来の重要な作業･課題に集中できる。 要員補充が効果的となり、特定キーマンへの依存度が低下し、リスクが分散される。 引継ぎに対する対策 複数のサプライヤーや担当者が入れ替わるプロジェクトにおいて、引継ぎ作業を円滑に行うことは誰もが望むことです。しかしながら引継ぎ作業は軽視されるケースが多いのが実態です。なぜならば、引継ぎ作業には非常に多くの手間と時間を要するため、コスト面の制約があること、具体的なタスクにブレイクダウンすることが難しいことが主な理由です。 そのため実際のプロジェクト推進では、QCDの制約がある中で全体最適化を意識し、該当プロジェクトに適した施策を実施することが重要となってきます。 規模･システム特性･要員構成･業務特性･継続性等を考慮して、下記のような施策をテーラリングして効果的に取り込むことがPM/PMO/QMには要求されることになります。 プロセス関連 1-1.プロジェクト計画書での引継ぎ関連事項の明記(OUTPUT一覧、役割分担、レビュー等) 1-2.工程毎の計画と詳細体制図/役割分担(企画～運用保守) 1-3.引継ぎ作業のWBS化と見積り 1-4.メンバー管理台帳の作成と管理(役割、期間、スキル、ナレッジ教育状況等) 1-5.新メンバー受入作業(誰が、いつ、何を教えるか) 1-6.工程完了判定 1-7.業務説明/引継ぎ会の開催(マイルストーン化) 1-8.運用設計書/マニュアル等の整備 引継ぎ資料/設計書関連 2-1.要件定義書/概要設計書/詳細設計書の詳細化と最新化 ※システム全体を俯瞰出来る概要図･一覧系の拡充が効果的 2-2.開発規約書/プロジェクトルール等の策定(標準化資料) 2-3.新メンバー向けの説明資料の集約 2-4.業務概要/詳細説明書(用語集の作成含む) 2-5.プロジェクト概要説明書 2-6.ひな型アプリ 2-7.テスト/本番環境/パラメタ定義等の一覧化 その他 3-1.リスク管理台帳での対策(要員関連) 3-2.新メンバーのトレーナー設定(ペアプロ等) 3-3.工程/プロジェクト完了時の振返り会の開催(KPT等を活用) 3-4.人員育成計画の立案と実行(短期と中長期) 3-5.習熟度の管理と評価 対策事例と効果 私が実際に推進、又は関与したプロジェクトでは下記のような対策を実施し、ブラックボックス化の弊害を減らし、効果を上げることが出来た事例があります。いくつかを簡単にご紹介させて頂きます。 事例１.レビューの徹底 スキルトランスファーを意識したレビューを確実に推進。 →　仕様理解が進み、追加メンバーの業務スキルが向上。(＋不具合の早期発見) 事例２.要件定義書の体系化 運用保守及びシステム改版までを意識して、要件定義書を充実･詳細化･最新化。 →　引継ぎ･説明工数の短縮と理解度UPに加え、改定時の影響範囲の検討に活用。 　　設計･開発工程以降は追加メンバー主体で対応し、コアメンバーの負荷は大幅減。 事例３.要員育成と管理の徹底 要員管理台帳を作成し、受入手続きを体系化。スキルを把握し、役割に応じた育成を実施。 →　全メンバーに対する「プロジェクト計画書」をはじめとするルール･業務要件の周知徹底を実施することで目的意識/役割が明確化。早期習得とチームの一体感の醸成にも寄与。 まとめ 私の現役時代は、一貫してお客様のシステムを請け負っているという自負と責任感を持ち、プライドを持って対応していました。そのため、部外者がシステム開発/運用に加わる際は、非常に警戒し、受け入れた場合はルールを徹底させたものでした。(逆の立場もあり) 現在のプロジェクトは、役割が専門家･細分化され、責任範囲が曖昧になってきています。もちろん工程の分業化や専門化は時代の流れであり、適用するメリットは大きいです。 しかしながら、工程の分業に対するデメリットを意識し、対策を練らなければ、個別組織や個人の役割最小化が進んだり、責任の押し付け合いになり、結果としてプロジェクトが破綻する可能性が高くなります。 また顧客はLCM(Life Cycle Management)全体での品質を求め、Devopsといった開発手法が注目されているなど、運用保守が重視される流れとなってきています。 最適解はプロジェクト毎に異なりますが、当記事をきっかけに、引継ぎを重視した計画･対策を事前に立案することで、少しでも円滑にプロジェクトを推進して頂ければ幸いです。 機会があれば、引継ぎ･標準化に関連する組織的な対策(人材育成･情報共有･プロセス)について投稿させて頂きます。 The post 脱・属人化のための「引き継ぎ設計」～ドキュメントとプロセスで実現するナレッジ共有術～ first appeared on Sqripts .

イネイブリングQAについての連載、第3回となる今回は、イネイブリングQAに必要なスキルについて考えていきましょう。 ＜QA活動のスキル伝達「イネイブリングQA」　記事一覧＞ ※クリックで開きます 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 【第3回】開発組織に品質技術を伝えるための2つのスキル 前回の記事 では、開発者に対するさまざまな「イネイブリング圧」がある状況のなか、単純に品質に関する知識やスキルを伝えるだけでなく「開発者の負担を軽くすること」を意識しましょう、と書きました。 開発者をはじめとした他の職種・ロールの方々に品質の知識やスキルを伝え、実践できるようにしていくには、さまざまなスキルが必要になります。今回はその中でも、大きく2つのスキル 課題設定・提案・解決のスキル 品質技術の編集スキル について説明します。 大前提：QAエンジニアとしての実務スキルは必須 イネイブリングQAとしてのスキルについて説明する前に大前提を確認しておきます。 前回・前々回の記事では、QAエンジニアが持っているテスト・品質関連のスキルや実務を開発者に移譲していくことがイネイブリングQAです、と説明しました。 つまりイネイブリングQAは「自分自身が手を動かすことをグッと堪えて、周りができるようにする」という側面があります。そのためには、自分自身が実務を担おうと思えば担えるだけのスキルが必要です。 口だけ出して自分はできません、ではなかなか信頼は得られません。自分自身ができるか、最低でも「知識としては持っているけど実践したことはないから、一緒にチャレンジしよう！」という姿勢は必要です。この点は忘れないようにしましょう。 必須スキル１：課題設定・提案・解決のスキル 開発チームの納得を得る重要性 イネイブリングQAとして品質技術を移転するにあたり、品質保証や向上に関する取り組みが開発チーム内で自走する状況を作る必要があります。主導していたイネイブリングQAがチームを離れたら全部止まってしまいました、では意味がないですよね。 品質に関する取り組みを行うというのは、それまでやっていなかったことを始めるという場面も多く、一時的に工数が増えたり、開発者の気持ちの面でも負担がかかることがあります。そのような状況において、開発チームで品質関連の取り組みを自走してもらうためには「最初は少し手間だけど、ちゃんとやるとメリットがあるよね」と納得してもらうことが大切です。 納得して続けてもらうために必要なのが、課題設定・提案・解決のスキルです。 開発者の納得する形で 現状の課題 品質に関するスキル習得や取り組みによって、課題が解決されること 課題解決によるメリット を提示できれば、前向きにイネイブリングを進めることができるでしょう。 理想・現実・問題・課題の整理 課題設定・提案・解決のために、私はよく「理想・現実・問題・課題」を整理した図を用います。本図については 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 | Sqripts でもご紹介しました。 この構造に当てはめて理想・現実・問題を明らかにしたうえで、そこから導き出した課題について開発チーム内で相談します。QAが一方的に設定したのではなく一緒に考えて決めた、という状態が望ましいので、「相談」という形がよいでしょう。課題の共通認識を持てたら、それに対する解決策の提案を行い、実際のアクションを起こします。 関連記事 【第4回】1人目QAのスタートは開発組織の現状把握から。やるべきこと・把握すべきこと。 会社や部署の1人目QAとしてJoinした場合、「このタスクをこなしてください」といった、やることが定まった状態とは限りません。むしろQAに限らずその組織におけるそのロール1人目というのは、そのロールの役割や組織内の位置づけなどを自ら定めるところからのスター... 　続きを読む　 Sqripts 解決策の検討・実行における姿勢 解決のための活動は、QAエンジニアとしての腕の見せ所です。過去の経験や社内外の知見などをもとにして 色々な手段を試すことになるでしょう。開発者やマネージャーなど共に働く仲間は、こうした解決策の検討・実行の様子を（QAエンジニアが思っている以上に）見ています。取り組む姿勢や引き出しの多さなども信頼関係の醸成につながります。しっかりと取り組みましょう。 必須スキル2：品質技術の編集スキル 編集スキルとは何か 今回触れるもう1つの必須スキルは、品質技術の編集スキルです。品質技術の編集、という言葉は聞き慣れないかと思います。それもそのはず、この記事を書きながら作った言葉です。 イネイブリングQAの役割である、品質技術や実務を開発者に移譲していく活動においては、「教える」という行為が中心となります。教えるという表現に抵抗があったり、しっくりこないという場合には「伝える」と表現してもよいでしょう。 誰かに何かを教えるという行為について、よく「教える内容の10倍知っていなければ、教えられない」などと言われます。ひとに物事を教えるには、順序付けや取捨選択が大切であり、そのための「10倍知っている」だと私は理解しています。 私自身がイネイブリングQAとして仕事をしていて、品質技術を教えるうえでも同じことが言えると感じています。単純に自分自身が知っていること・できることをそのまま開発者に伝えればよいわけではありません。 どうすれば伝わるのか どのように説明すれば身につけてもらえるのか 自分が居なくなっても、伝えたことが定着している・自走してもらえるにはどうすればよいか を常に考えて伝えることが大切です。このような工夫を指して、ここでは 編集 と表現しています。 編集スキルを身につけるための2つのポイント 適切な編集を行うために私が心がけているポイントを2点ご紹介します。 ①全体像を描く 何事もそうですが、個別のトピックを散発的に伝えられても、全体像がわからないと理解しづらい場合が多いです。 たとえば開発者に対してテスト設計技法を教えて業務で活用してもらおう、と考えたとします。今週は組合せ、来週は同値分割・・・とただ説明していても、おそらく身につきづらいでしょう。 まずは テスト設計技法とは 技法を使うメリット などの概要から入ったうえで「このさきテスト技法を5つレクチャーします！」のように全量を提示したほうが、聞く側も理解しやすいはずです。 全体ボリュームやゴールなどの全体像を先に設定・提示してから進めるようにしましょう。 ②QAにとっての正しい言い方・やり方にこだわりすぎない 開発者はJSTQBのシラバスを読み込んでいることはまれですし、日常的にインプットしている内容もQAエンジニアのそれとは異なります。つまり、完全に同じ共通言語をもっているわけではありません。 そうした状況で品質技術を伝える際に、いわゆる「QAにとっての常識」を押し付けることになると逆効果です。 たとえば「開発者が行うテストにおいても、テストプロセスに厳密に則らなければならない」や「テスト分析とテスト設計を厳密に区別して行わなければならない」などの押し付けをしてしまうと、反発を生んでしまいます。 実際に私も開発者とテストプロセスの見直しを行った際には、あえて「テストプロセス」「テスト分析」「テスト設計」といったワードは出さずに進めました。「いきなり細かいテストケースを作るのではなく、観点レベルでレビューしてから詳細化したほうが結果楽ですよ」など、一般用語を中心に説明したほうがよりスッと受け入れてもらえます。 このように、QAエンジニアの間で常識・普通とされているやり方や言い方にこだわり過ぎず、まずはエッセンスだけを取り入れてからだんだんとブラッシュアップしていく作戦も持っておくと良いでしょう。 まとめ：イネイブリングは「人を動かす」こと 今回はイネイブリングQAとして主に開発者に対して品質技術を伝える際に必要となる2つのスキルについて説明しました。 とくにイネイブリングQAに求められるのは、私は「人を動かす」ことだと考えています。知識を一方的に伝えるだけ、であれば簡単です。しかし必須スキル1の項目でも触れたように、開発者が品質知識や技術を身に着け、自走できてはじめてイネイブリングできたと言えます。そのためには、はたらきかけの方法について工夫をし、自分ごとと捉えて動いてもらうことが必要になります。 なかなか大変ではあるものの、それだけにやりがいがあるのがイネイブリングQAです。また、人に何かを伝えて行動を起こしてもらうためのスキルは、イネイブリングQA以外のあらゆる面で応用が効くものです。 私自身まだまだ試行錯誤中で、この先もそうだと思います。一緒に頑張っていきましょう。 【連載】QA活動のスキル伝達「イネイブリングQA」 記事一覧 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【全文公開中】 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 【第3回】開発組織に品質技術を伝えるための2つのスキル The post 【第3回】開発組織に品質技術を伝えるための2つのスキル｜QA活動のスキル伝達「イネイブリングQA」 first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える 【第9回】発想を促すヒント 【第10回】注意はしながら、恐れずに 今回はアブダクションをする時の注意点です。 各回で触れてきたことのおさらいも含めて確認しておきましょう。 おさらい・「よい仮説」の4つの条件 4つの条件(再掲) 第6回 で触れた「「よい仮説」が持つべき性質」と、 第7回 で述べた「パースによる「よい仮説」の判定基準」の表を再掲します(図10-1)。 （説明は当該回の記事を参照してください） 図10-1 「よい仮説」の判定基準と、「よい仮説」が持つべき性質 (図7-3再掲) もっともらしさと検証可能性 4つの条件はそれぞれに重要ですが、「もっともらしさ」と「検証可能性」は欠かせません。問題の事象を説明できないものは論外ですし、飛躍や矛盾を含む説明は納得度が（著しく）低いでしょう。 正しいかどうか確かめる方法がないのなら、いくらもっともらしくても空論の域を出ません。故障の原因説明に地縛霊とかを出されても困るわけです。 （この業界では不可解な現象や「なぜかできていた」作業などが「小人さんのしわざ」とされることがまれにしばしばありますが……筆者も小人さんにはずいぶんお世話になりましたが……） もっとも、検証可能性の点では弱くても（実際に確かめるのが難しくても）、もっともらしい原因や過程はあり得ます。 （ソフトウェア故障で言えば、たとえば「実行や同期のタイミングに起因する故障」や「コンパイラの吐くコードに起因する故障」「外部からの割込みに起因する故障」など） 調べ尽くし考え尽くした末に、「こう考えれば説明はつく」（そのような原因しか考えられず、他の点で飛躍や矛盾がない）場合は、検証可能性はいったん措いておくことになります。 もっともらしい説明であるには： 根拠や前提が確かなものか、 事実 に基づいて説明できるか。 因果関係の説明が 合理的 で 筋が通っている（飛躍や矛盾を含まない） か。 が重要となります。 事実を大事に 事実を集める 「その時目の前に見えている材料」だけで仮説を作ろうとしない 「何が原因か」「どのようにしてこの結果が生じたか」を考え始める時は、得てして「その時見えている事実」だけで仮説を考えがちです。(図10-2)。 しかし、問題の事象に附随して起こっている事象のうち、何が関係していて何が関係しないかは、特に仮説検討の初期には判らないことも多い筈です。 問題の事象とかけ離れているように見えるからといって、うっかり切り捨てないように気をつけましょう（次節「先入観と向き合う」も参照）。 目の前に見えているものは、原因を考えるのに必要な全てと言えるか 「取るに足りない」と思い込んでいるものはないか 図10-2 事実を集める 先入観と向き合う 先入観（や、各種の認知バイアス）は、 仮説案を“裏づける/強化する”事実にばかり注意が向いてしまう 仮説案と合わない(邪魔になる)事実に目が曇る といったことを引き起こし、因果関係の誤謬(図10-4)につながるおそれがあります。 先入観からフリーでいるのは誰にとってもたやすいことではありませんが、自分にバイアスがかかっていることに気づければ、対処はしやすくなります。 考え始めには 「自分は今どんな前提で考えようとしているか？」 「最初に思いついた仮説案は、何を前提としているか？」 「その前提は妥当なものと言えるだろうか？」 など、 また、仮説案と整合しないような事実を見た時には 「 仮説の方が間違っているのでは？ 」 「 この事実と両立するように仮説を修正できるのでは？ 」 などと、自分に問いかけてみる習慣をつけられるとよいでしょう(図10-3)。 図10-3 先入観と向き合う 因果関係の説明だから 因果関係推定の落とし穴 原因から結果に至る過程の説明を考える際には、因果関係の推定に関わる落とし穴(誤謬)に気をつけましょう(図10-4)。 詳細は本連載 第4回 、 第5回 を参照してください。 図10-4 因果関係推定の落とし穴をよける 論理の筋道を整える 仮説の骨組みを支えるのは演繹的な論理です。 原因から結果に至る筋道に無理がなく、誰もが納得できる ものかどうか、論理の言葉の使い方には気をつけましょう(図10-5)。 図10-5 論理の筋道を整える 「間違い」を恐れずに 間違った仮説に行き着いてしまうのは避けたいことではありますが、とはいえ誤りを恐れて発想を抑えてしまっては、よい仮説の芽を摘みかねません。 アブダクションも蓋然的な推論であり、 誤りはつきもの です。 大切なのは、誤りに（いち早く）気づけることと、誤りを認めて仮説を修正する姿勢です（それは仮説の質を高めることにつながります）。 第7回 で紹介した「仮説のふたつの段階」は、「誤り」の混入に対処しやすくする進め方と見ることもできます。 さまざまな見方から（できれば複数の）仮説を考える第1段階・「洞察の段階」 考えた仮説から最も「よい」ものを選ぶ第2段階・「熟考の段階」 と分けて取り組むことで、途中で間違いに気づいて仮説を見直すチャンスが生まれるわけです。 間違いがあってこそのアブダクション、くらいに気を楽にして、どんどん仮説を考え、仮説思考に慣れていきましょう。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 T・エドワード・デイマー(著), 小西卓三(監訳), 今村真由子(訳) 『誤謬論入門　優れた議論の実践ガイド』 九夏社 2023 米盛裕二 『アブダクション　仮説と発見の論理』 勁草書房 2007 ポリア(著), 柴垣和三雄(訳) 『数学における発見はいかになされるか 2 (発見的推論　そのパターン)』 丸善 1959 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える 【第9回】発想を促すヒント 【第10回】注意はしながら、恐れずに The post 【第10回】注意はしながら、恐れずに｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

こんにちは、QAエンジニアのうえやまです。 現在私はE2Eテスト自動化に携わっており、日々さまざまな特性を持ったテストの自動化に取り組んでいます。 本記事では、自動化したいテストの内容が決まった後、「そのテストの特性に合わせた設計をどう行うか」という品質と効率を左右する重要な部分にフォーカスして、私の経験から得られた3つの設計パターンをご紹介します。 いずれも、キャプチャ＆リプレイ（ノーコード、ローコード）やスクリプティングでの自動化といった環境によらず適用可能な設計方法になります。 テスト特性にフォーカスした自動テスト設計方法 １．新規に作成する場合：基本となる設計思想 E2Eテストの自動化に着手する際に重要な初期ステップの一つは、どのようなテストを自動化するのか、全体像を明確に描くことです。特に新規で自動テストを作成する場合「自動化ならではの注意点」を事前に考慮した設計が、後の運用フェーズでの手間を大きく左右します。 まず自動化用のテスト構成を検討し、テストケースに起こします。このとき「１ケースにつき１スクリプト」として作成するのが良いでしょう。 理由としては複数ありますが、一連のシナリオごとにテストを分割管理することで以下のようなメリットが生まれます。 可読性と管理性の向上: スクリプト名を見るだけで、どのようなテストかが直感的に理解でき、管理が容易になります。例えば、特定の機能に不具合が見つかった際、その機能に関連するスクリプトが明確に分かれていれば、影響範囲の特定や修正作業が迅速に行えます。 安定性の向上: テスト実行時間が長くなるほど、ネットワークの瞬断や予期せぬポップアップなど、外部要因による失敗のリスクが高まります。テストを短く区切ることで、それぞれの成功率が上がり、CI/CDパイプラインに組み込む際の信頼性も大きく向上します。 構成の検討が出来たら、共有ステップ化出来そうな処理を検討します。他のテストでも使えそうな一連の処理（ログイン、利用者作成 等）があれば共有ステップ化しましょう。 共有ステップは、自動テストの「再利用性」を高めるために不可欠です。一度作成すれば複数のテストケースで利用できるため、スクリプト全体の記述量を減らせるだけでなく、共通処理の修正が発生した場合も一箇所の変更で済み、メンテナンスコストを大幅に削減できます。 下図では、本編の前後に初期処理と後処理を入れています。 内容としてはケース内で登録するデータ（下図でいうところの「連絡先追加」で追加した連絡先など）の削除になります。この「テストデータのクリーンアップ」は、自動テストの信頼性を保つ上でとても重要です。特に、テスト環境が共有されている場合、他のテストや手動テストに影響を与える可能性があります。 もし自動テストがエラーになって中断されデータが残った状態で次回実行されると、それが原因でテストが通らなかったり意図したテストが出来なかったりする恐れがあるため、クリーンアップ作業は必ず入れるようにしています。 また、テストデータもここで検討出来ると良いでしょう。私は以下に注意して検討しています。 ■ テスト同士が干渉しないようにスクリプトごとにデータを分けて設計する これは、テストの独立性を保つために重要なポイントです。例えば、Aというテストが作成したデータをBというテストが意図せず変更してしまい、結果としてBのテストが失敗するといった「テスト間の依存性」を避けることができます。 このような依存関係があると、テスト結果が不安定になり問題の特定が困難になるため、各スクリプトが独自のテストデータを持つか、実行ごとに初期状態にリセットされるような設計が理想的です。 ■ なるべく本番環境でより多く使われているデータを採用する テストデータのリアリティは、テストの有効性を大きく左右します。本番環境で頻繁に使われるデータパターンを中心に含めることで、実際の運用に近い状況でテストを実行し、より現実的な不具合を発見しやすくなります。 ■ 自動テストを動かすために事前に登録が必要なデータを記載しておく 自動テストを安定して実行するためには、常に決まったテストデータが環境に存在している必要があります。そのため、テスト環境を再構築する際や新しい環境をセットアップする際に、どのような初期データが必要なのかを明確にドキュメント化しておくと後々便利でしょう。 以上、新規に自動テスト設計する場合について記載しましたが、これらの内容をドキュメントにまとめてレビューに出し、通れば実装開始する流れが多いです。 既に存在している手動ケースをもとに作成する場合も、画像のようにおおまかなブロックに分けるところから流れや注意点は同様です。 ２．データドリブンテストを行う場合 データドリブンテストは、同じテストシナリオを異なる入力データで繰り返し実行する必要がある場合に非常に効果的です。 例えば、5種類の異なる権限を持つユーザーで、同じ「ログイン〜特定機能の操作」をテストしたい場合を考えてみてください。もし5つのスクリプトを個別に作成すると、少しの仕様変更でも5つのファイルを修正する必要があり、非効率的です。 データドリブンテストでは、「操作を定義するスクリプト」と「入力値や期待値を定義するテストデータ」を分離します。これにより、テストしたいデータの増減があっても、ExcelやCSVファイルといったデータソースを修正するだけで対応でき、スクリプト本体に手を入れる必要がありません。 この手法のメリットは以下です。 高いメンテナンス性: ロジックとデータが分離しているため、テストデータの追加・変更が容易です。非エンジニアのメンバーでもスプレッドシートを編集するだけでテストパターンを増やせます。 カバレッジの拡大: 多言語対応サイトの翻訳文字列チェックや、ECサイトの様々な割引パターンの計算など、組み合わせが膨大になるテストも効率的に網羅できます。 私が過去に担当したプロジェクトでは、PDFにまとめられた大量の仕様データをテストデータに活用する必要がありました。その際に行った、手作業を軽減する整形手順をご紹介します。 データ原本のPDFをWordで開いてhtml形式で保存 html形式で保存したデータをExcelで開き、Excel形式で保存し直す 上記をスプレッドシートにコピーし、テストで使用したい変数と値の形になるよう関数やフィルターを使い整形する（最終的に画像右「テストデータファイル」のような形になります） 整形したデータをスクリプトから参照し、データドブリンテストを行う 私が使っている自動化ツールはCSV形式のみ参照可能のため、CSVで出力しツールに取り込む作業も挟みますが、これはあくまで一例です。 より高度な方法として、PythonのPyPDF2やpdfplumberといったライブラリを使い、PDFからのデータ抽出プロセス自体をスクリプトで自動化することも可能です。定期的に更新される仕様書からテストデータを生成するような場合には、こうしたアプローチが大きな力を発揮するでしょう。 ３．画面遷移確認を目的としたテストの場合 最後に、システムの各画面への遷移を網羅的にテストすることを目的とした設計で使用した方法をご紹介します。 特に、大規模なWebアプリケーションや頻繁にUI変更が発生するシステムでは、全ての画面遷移を手動で確認することは非常に困難です。このような状況において、自動テストによる画面遷移確認は、品質保証の効率化に有効なアプローチとなります。 普段図を描く系のドキュメントはMiro( Miro | イノベーション ワークスペース )を使って作成しているのですが、今回紹介する方法でもmMiroを使うのがおすすめです。図を使ったドキュメントを感覚的に綺麗に作成出来るツールです。 ※使用するツール、アカウントはプロジェクトに確認してください。 画面遷移テストの設計の流れとしては以下になります。 作業対象画面を決め、画面名と番号を振る。（画面一覧があればそれを元にします） Miroにテストしたい画面のスクリーンショットを貼って各ボタン・リンクからの導線を描く。この時以下２点をルールとしています。 一筆書きになるよう遷移順を振る 上から下に遷移順になるよう並べる（追いやすさに配慮） 作成した導線通りにスクリプトを実装する テキストベースのテスト仕様書では、「どの画面の、どのボタンを押すと、どの画面に遷移するか」という流れを直感的に把握するのが難しく、レビューの際にも認識齟齬が生まれがちです。しかしこの方法では視覚的に遷移パスを示すことで、設計者もレビュー者も容易に内容を理解できます 。 また、設計段階で「見落としがちな遷移パス」や「意図しない画面ループ」、「どこからもリンクされていない孤立した画面」などを発見しやすくなるという副次的な効果も期待できます。 例としてAGESTのホームページの遷移図を一部描いてみると以下のようになります。 Miroだと同じ資料上の違う要素にリンクで飛べるようにも出来るので複雑な遷移でも分かりやすく表現可能です。 以下にこの方法のメリットとデメリットをまとめますので、参考にしてみて下さい。 メリット: 設計の網羅性の向上: 視覚化により、考慮漏れや設計の不備を早期に発見できます。 レビューの効率化: テキストを読み解く必要がなく、直感的なレビューが可能です。 デメリットと対策: ドキュメントの陳腐化: UIの変更が頻繁に発生する場合、Miroの図を最新の状態に保つためのメンテナンスコストがかかります。これを完全に防ぐのは難しいですが、UI変更のタスクとセットでMiroの更新も行うというチームルールを設けることで、乖離を最小限に抑えられます。 まとめ 本記事では、3つの異なるテスト特性にフォーカスした自動テストの設計方法を、具体的な事例を交えながらご紹介しました。いずれの手法においても、設計段階からテストの安定性、メンテナンス性、そして可読性を意識することが重要です。 自動テストは一度作成したら終わりでなく、プロダクトと共に育てていくものです。そして、その価値を最大限に引き出すためには、作成者だけでなくチームの誰もが内容を理解し、修正できる状態になっていることが不可欠です。 誰もが触れる「開かれた自動テスト」は属人化を防ぎ、チーム全体の資産となります。完璧な設計は存在しませんが、プロジェクトの特性やチームのスキルセットに合わせてトレードオフを理解し、最適な手法を選択していくことが、自動化を成功に導く鍵となるでしょう。 本記事が、皆さんのテスト設計における新たなアイディアや改善のきっかけになれば幸いです。最後までお読みいただき、ありがとうございました。 The post 【実践】テスト特性を徹底活用！効率的かつ効果的な自動テスト設計術 first appeared on Sqripts .

開発現場で働く中で、「自分の専門性とは何か？」と自問したことがあるのではないでしょうか。 特に「品質保証」という広大な領域を担うQAエンジニアにとって、その問いはキャリアの節目で繰り返し現れます。 品質保証における技術や、その活動がソフトウェア開発への貢献する形は様々です。 そのため、「QAエンジニア」と一口に言っても、多様な専門性や個性があります。 この連載では、そのような問いと向き合うための一つの考え方として、「多様な専門性を積み上げて、自分だけのQAエンジニア像を作っていく」というアプローチについて、私自身の経験を交えながらお話ししていきます。 筆者はテスターとしての専門性を基盤とするQAエンジニアです。 そのため、テストの話が中心となってしまいますが、実際には多様な専門性の積み上げがあり得ることにご留意いただいた上で、皆様のキャリアを考える際のヒントになれば幸いです。 第一話となる本稿では、様々な専門性を組み合わせて、「自分自身のQAエンジニア像を育てる」という考えについて紹介します。 専門性を身につける 自分自身が「プロである」という意識を持った上で開発組織の中で貢献することは重要です。 ソフトウェア開発はクリエイティブな仕事であり、単に「定められた時間で決められた作業をする」という性質よりも、「自分自身の専門性を発揮して良いソフトウェアを作る」性質を持っています。 こういった状況の中で、きちんと自己を確立するためには、「専門性を身につける」ことが大切だと考えています。 巨人の肩に乗る 「巨人の肩に乗る」という言葉があります。これは「先人たちの知識や成果を土台として、さらにその上に新しい発見や進歩を築き上げる」という意味です。 プロとして専門性を身につけるために、私はこの考えをとても大切にしています。 例えば、「理論や知識よりも、まずは現場での経験がすべてだ」と考え、経験から学ぶこと”だけ”を重視する方に出会うことがあります。 経験から学ぶことはとても重要です。しかしながら、経験”だけ”から学ぶことは専門性を高めるスピードを遅くしてしまうと感じる時があります。 現代で確認できる様々な技術や知識は、先人たちが積み上げてきたものです。これらを「現実では意味のないものだ」「現場では役に立たない」と断じるのではなく、その上に自分自身が何を積み上げられるかを考えることも重要です。 巨人の肩に乗って、良い景色が見れなければ降りればいいのです。 この世界にはたくさんの巨人がいるのですから。 品質保証に関わる様々な専門性 「品質保証」といっても、その活動の中で活かせるスキルや技術は多様です。私はテスターからキャリアをスタートして、今でもテスターとして自認しています。 「テスター」と一言で片付けても、テストの分野にはテスト設計、テストマネジメント、テスト自動化、様々なテストタイプの実践など、多様な専門分野が識別できます。 また、品質保証においてテストは必要不可欠ですが、QAエンジニアは必ずしもテストの専門家である必要はないと私は考えています。実際に私が知っている人の中には、QAエンジニアとしてキャリアを積み上げる中で、SET、プログラマー、EM、スクラムマスター、広報など、さまざまなキャリアのパターンがあります。 T型人材になる キャリアの考え方として「T型人材」というものがあります。 「T型人材」とは、特定の分野を極め、専門的な知識や経験とスキルを蓄積し、これらを軸にして、その他の幅広いジャンルに対しても知見を持っている人材のことを指します。英語で「T」の文字の縦を「専門性」、横を「視野の広さ」に見立て、「T型人材」と呼ばれています。 kaonavi人事用語集 品質保証の担い手として活動しようと考えたとき、私は「T型人材であること」は必要不可欠だと考えます。品質保証は、特定の専門性、例えばテストへの習熟だけでは不十分だと考えます。 品質保証には、経営課題を理解したり、開発者の思想に寄り添ったり、ユーザーの視点への洞察が求められます。幅広い領域への理解があって、私たちはより効果的な品質保証を行うことができるのです。 QAエンジニアとしてTになる 私自身、T型人材であることを体現するために、ソフトウェア開発だけでなくビジネス側の知識や組織論などを勉強している途中です。 これらの知識は、ソフトウェア開発以外での品質保証への貢献、連携、対応などに役に立ちます。 プロダクトの方向性やスコープを考える際にはビジネス戦略への理解や顧客理解が不可欠ですし、プロダクトと共に成長するチーム運営を考えるには、長期的な人材戦略と連携して考える必要があります。 また、それらを単なる知識として学ぶだけでは不十分だと考えています。知識に偏ってしまうと、これらは先入観となってしまうリスクがあります。先入観は様々な人と連携していく上で、足かせになってしまうことがあります。 ぜひ他の分野についても実際に働いている人とも話して、リアルな知識を身につけてほしいと思っています。 私なりに実践してきたTの形 私自身は、テストの専門性がある「テスター」と名乗っています。一方で、QAエンジニアとして品質保証を考える上では、テストの専門性だけでなく、様々な知識が必要になると考えています。 こうした思いから、QAエンジニアと名乗るべき文脈においては、私はあえて「テストに専門性を持つQAエンジニア」と名乗るようにしています。 テスト以外でも自分自身が「強み」だと思っている分野があります。スクラムマスター・コーチング・プロジェクトマネジメントなどです。これらの専門性を身につけることで、テスターとしての自分がより強固になると感じています。 専門性を緩やかに繋げる 様々な専門性を身につけると、それぞれ単一の独立した専門性だったものが、自分の中で緩やかに繋がりができることがあります。 コラボレーションするように、ある専門性と別の専門性を掛け合わせることで、新たな貢献が生まれることがあります。 他にも、ある技術を学ぶことで、それまで自分の中で培ってきた専門性や経験に、新たな側面を見出したり、知見を得たりすることがあります。新たな専門性を身につけることで、これまでの知見もリフレーミングされるのです。 こうした「緩やかな繋がり」はQAエンジニアとしての自己を確立するための基盤になると考えています。 さいごに 本連載は、私が今まで獲得してきた「専門性」を取り上げ、どのようにそれらを獲得して、緩やかに繋げていったかをお伝えします。 この連載を通して、皆さんの興味関心を伸ばし、ご自身だけのQAエンジニア像をデザインするためのヒントとなれば幸いです。 The post 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる first appeared on Sqripts .

こんにちは、QAコンサルタントのツマミです。 皆さま、JIS ※1 スキーのツマミが今回目を付けましたのは“色”についてのJISです。我々AGESTの本社前には江戸二大庭園のひとつ、水戸のご老公とも所縁の深い「小石川後楽園」という日本庭園があります。春は枝垂れ桜、初夏は若葉、盛夏は蓮、秋は紅葉、冬は常緑の木々が目を楽しませてくれる素晴らしい日本庭園です。昼休みに窓から「小石川後楽園」とその先に建つ黄色いビルを眺めておりましたところ今回のテーマは“色”が良いのではと思い至りました。 さて、 “色”について言及しているJISは色々ございまして、JIS検索 ※2 で調べますと500件を超え検索不可能と言われてしまいます。規格名称の一部に持つJISに限りましても、なんと144件もの規格がヒットいたします。とはいうもののやはりユーザビリティやアクセシビリティに関連する規格を取り上げたい。 という訳で、次なるさんぽはJIS C 0448「表示装置（表示部）及び操作機器（操作部）のための色及び補助手段に関する規準」。今日もまた、ゆるゆると楽しんでまいりたいと思います。 どうぞ皆さま、ちょっとした気分転換としてこのJISさんぽにお気楽にお付き合いの程、よしなに願い奉ります。 ※1　JIS：日本産業規格（Japanese Industrial Standards） ※2　JIS検索：https://www.jisc.go.jp/app/jis/general/GnrJISSearch.html ▼これまでの「JISさんぽ」はこちら JISさんぽ(01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 こんにちは、QAコンサルタントのツマミです。唐突過ぎますが私ツマミ、JIS（日本産業規格：Japanese Industrial Standards）が大好きです。お客様のプロダクト品質やプロセス品質の課題に対して何か基準は無いか、定義や分類法は無いかと探ると何かしらのJISに行き当... 　続きを読む　 Sqripts JISさんぽ(02) JIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」 こんにちは、QAコンサルタントのツマミです。皆さま、先日JIS※1スキーのツマミが報告しましたコラム、JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」はご覧いただけましたでしょうか。「インタラクションの原則」を知って... 　続きを読む　 Sqripts 今回のJIS JIS C 0448「表示装置（表示部）及び操作機器（操作部）のための色及び補助手段に関する規準」とは この規格は様々な製品やシステムの表示部や操作部に使用する色について規定しています。 色に関する学びを深めるとともに、色だけに頼らないユーザーインタフェース（UI）の構築方法についても学ぶことができる規格となっています。UIを新たにデザインする方、リニューアルを考えていらっしゃる方、不特定多数の方が利用するシステムに携わっていらっしゃる方には是非知っていただきたい規格です。 なぜ、このJISを選んだのか 人間の感覚（視覚、聴覚、触覚など）の内、情報入力においては8割ほどを視覚が担うといわれています。入力情報の内、どの程度を視覚情報から賄っているのかとなると更なる研究が必要だそうですが ※3 、スマフォアプリやWebシステムのユーザーインタフェース（UI）において視覚情報の比重が高いことは、皆さまも頷いてくださると思います。 であれば、“色”や色の補助手段を知っていることは、UI改善のための強力なツールを手に入れたも同然！　と言えるといいなぁ…と思ってこのJISを選びました。 でも、本当に学びの多い規格なんですよ！システムのデザイン標準を策定なさる方は是非一度触れていただきたいJISです。 ※3　 筑波技術大学テクノレポート Vol.25 (1) Dec. 2017 『「視覚は人間の情報入力の80％」説の来し方と行方』 道行 まえがき、序文 まえがきはシンプルです。「この規格は～日本工業規格である」と紹介されています。前に取り上げたJIS Z 8520、JIS Z 8522とは異なり「この規格が著作権法で保護対象になっている云々」は記載がないですね。1997年版という時代を感じます。 まえがき後半は付属書3件の紹介です。「情報基準の適用例」、「色の補助手段による基準の例」、「電気装置のとっての操作と状態の表示」。“とって”って平仮名で書かれていると分かりづらいですが「取っ手/把手」のことです。この付属書を読んで周りにある“とって”を見渡してみると、なるほどと思うことが多い面白い付属書です。 序文では、この規格がIEC　60073 ※4 を翻訳したものであることが記されています。 なので、この規格に準拠していれば国際的な規格に準拠している ※5 といえそうです。 ※4　IEC：International Electrotechnical Commission 約90か国が参加している ※5　IEC　60073は2002年度版が出ているので、最新版での準拠が必要です。 1章　適用範囲 1章ではこの規格の目的と適用範囲が述べられています。 目的は次の3点。 装置を安全に監視したり操作したりすることで、人体、資産、環境の安全性を高める 装置の適切な監視、操作、保全を容易にする 操作条件や操作部の位置の迅速な確認を容易にする 適用範囲は次のとおり。 単一の表示灯、押しボタンから機械や工程の制御装置、制御ステーションまで 　（広いですよね！　表示や操作による「マンマシンインタフェース」全般が対象ということです） 人体、資産、環境の安全が関係する場合、色や補助手段が装置を適切に監視したり操作を容易にしたりするために使用される場合 個別の規格で特有の機能に対して固有の識別方法を定めた場合 2章　引用規格 この規格にはJIS C 0447、JIS C 0167という2件のJIS規格が引用されています。 JIS C 0447　「マンマシンインタフェース（ＭＭＩ）－操作の基準」、操作機器（スイッチやレバーなど）を動かす方向と、動かすことによって機械がどう動くかという関係を統一する規格です。 JIS C 0167　「電気用図記号」、この規格は電気・電子回路の設計図（回路図など）を描く際に使用する記号の形や使い方を定めています。 3章　用語及び定義 ここでは11の用語が定義されています。まず着目したい用語は3.1項の「表示装置（表示部）」。「可視または可聴情報を出す機械的,光学的,電気的又は電子的装置」となっていて、音も対象に入っているという点です。 また、3.2項の「操作機器（操作部）」も本規格の名称に入っている用語ですので着目しておきたい用語です。 備考欄は“ハンドル、とって、押ボタン”などと物理的な形状がある場合に限られるような書き方にも思われますが、注記で「インタラクティブ・スクリーン・ディスプレイの場合にも触れられていてタッチスクリーンのボタン類なども含まれていることが分かります。 他に気になる定義としては「対比(contrast)」。「コントラスト」ではなく「対比」となっているのですが「知覚された明度の対比と対比するように意図された数量」という文章があり、一つの文章の中で若干ニュアンスの異なる対比が使われていて少々おもしろく感じました。 「補助手段」の定義も面白くて、視覚的な補助手段と聴覚的な補助手段があると定義されていますが、どちらにも時間という概念が入っています。確かに、光の点滅や音の断続によって位置や方向、時間的なリミットを示す場合があると思わず頷いてしまいました。自分で定義を考えたらヌケモレしそうな要素です。 4章　一般要件 4章は色を使うときに必要な要素や条件が示されています。 4.1　基準の原則 4.1項ではユーザビリティで非常に重要な要素だとツマミが考えている「統一性」について述べられています。つまり(色の使い方や点滅の仕方などについての)規準となる原則は同じプラントや工程内の他の装置の原則と一致させましょうと書かれています。しかもその規準をシステム設計の初期段階で制定しましょうとも書かれています。 その上で色相（色合い、赤・黄・緑・青など）と点滅の規準については色の持つ意味を一貫させ、最優先としたい情報のために使用するようにと言ってきているわけですね。 更に表1と2で決めるべき要素はこれとこれですよと示してくれています。 主要素である「色」は色相、彩度（色の鮮やかさ）、明度（明るさ/暗さ）、対比（コントラスト）の4要素があがっています 因みにコントラストはアクセシビリティに影響するので、デザイン標準を作成なさる方は是非JIS X 8341-3の達成基準である4.5：1を思い出して欲しいところです。 色だけではなく補助手段や文字の表記も使用を勧められています。特に色覚に違いのある方のことも考慮して色だけを基準の手段としないよう、補助手段の併用が推奨されています。 その補助手段は色と同じ視覚情報として「形状、位置、時間」があげられており、聴覚情報として「音の種類、周波数、時間」があげられています。「音」の要素って「音色、音程、音の大きさ」だとツマミは思っていたのですが、この規定では「音色」がさらに細分化され「音色、雑音、言葉」となっています。補助手段としての「雑音」って何なのだろうと思いましたが附属書Bに参考例として「ノック音」が入っており、注意を喚起する音として例えば単音でもなく和音とも言えない音使いを「雑音」と表しているのかなと思いました。 他の要素も「音程」は計測、再現しやすいよう「周波数」として定義するようになっていますし、「音の大きさ」は「時間」の中の「音圧レベルの変化超過時間」という言葉で定義されていて規格っぽい感じを受けます。 4.2　色による基準 本項の冒頭で「色は，注意を喚起するために最も有効な手段である。」と述べられています。 また、特定の色には特定の意味を割り付けること、実際に使用する特定用途の色数を最小限にすることが推奨されています。この規格でも説明は「赤、黄、緑、青、黒、灰、白」の7色だけに絞り込んでいます。 4.3　色の選定 本項では、まず色の意味についての一般原則が「人体又は環境の安全」、「工程の状態」、「装置の状態」に分けて次のように定義されています。 色 人体または環境の安全 工程の状態 装置の状態 赤 危険 非常（緊急） 一般的な意味づけは無い 黄 注意 異常 緑 安全 正常 青 強制的な意味 黒、灰、白 特別な意味づけは与えていない デザイン標準などでは上記表に記載の意味に従って色使いの規準を定めていくわけですが、後述の3つの表 ※5 の間で意味の混乱が起きず、しかも色の意味に従った内容で明確に決定する必要があると記載されています。 なお、本項ではビデオ・ディスプレイ・スクリーン上の表示色についても言及されています。「各色に割り付けされた意味は,ディスプレイ内で調査していること」と、割と難しめのオーダーがサラッと書かれています。 ※5 後述の3つの表 表4：「人体,資産及び／又は環境の安全に関して表示装置（表示部）の色が表す意味」 表5：「工程の状態に関して表示装置（表示部）の色が表す意味」 表6：「表示装置（表示部）の好ましいとされる色が装置の状態に関して表す意味」 4.4　点滅表示による情報の規準 　点滅表示は通常より注意を惹きたい場合に使うなど、点滅表示を使う状況や状態が定められています。点滅状態はゆっくり目と通常の点滅の2つのモードがあり、1つのモードしか使わない場合は通常の点滅を使う必要があるようです。 ゆっくり目と通常の点滅は、もちろん周波数で定義されています。 ∫1：ゆっくりとした点滅。 0.4Hz～0.8Hz（24～ 48点滅/1分間） ∫2：通常の点滅。 1.4Hz～2.8Hz（84～168点滅/1分間） 　心拍数が通常60～100回/1分間なので通常の点滅でも結構早目な感じがしませんか。 　更に本項では点灯と滅灯の時間比を1：1にすることや、ゆっくり目の点滅（∫1）と通常の点滅（∫2）の周波数の比を∫1：∫2＝1：4（例　0.5Hz：2.0Hz）にすることが推奨されるなど学びの多い項となっています。 4.5　補助手段に使用する色 　本項はあっさりとしていて、安全性に関わる用途で色の基準を決める場合は他の補助手段の基準で補足することが定められています。安全にかかわる場合、色だけで判断しようとして誤解が生じると取り返しのつかない障害になる場合も考えられるので、補助手段の利用は納得の極みです。 5章　表示装置（表示部） 5.1　使用形態 　表示装置（表示部）の表示は装置の状態に関する情報を提供すること、操作員に対しては注意を喚起したり、次にどうすればよいかに関する情報を表示したりすることが述べられています。 　そして具体的な例として次の3表が掲載されています。 表4：「人体,資産及び／又は環境の安全に関して表示装置（表示部）の色が表す意味」 表5：「工程の状態に関して表示装置（表示部）の色が表す意味」 表6：「表示装置（表示部）の好ましいとされる色が装置の状態に関して表す意味」 5.2　機械的表示装置（表示部）への特別要件 　機械的表示装置（表示部）の表示について、図記号や色の要件が述べられています。 6章　操作機器（操作部） 　操作機器（操作部）に使用する色についてかなり詳細に述べられています。 　非照光式操作機器（操作部）と照光式操作機器（操作部）については、是非、本規格や関連規格を読み込んで使用する色の基準、位置や形状を定めてください。 　ビデオ・ディスプレイ・スクリーン上の画像表示の一部としての操作機器（操作部）についても6.3項で述べられている「非常（緊急）操作に備えて, ビデオ・ディスプレイ・スクリーン上に再生する操作機器（操作部）は,操作員が作業及び操作をしている位置から,指定されている時間に見ることができ,かつ,利用しやすいこと」の意味を熟考して画面をデザインください。 附属書A(参考)　　情報基準の適用例 「試験所に連結した表示装置（表示部）及び操作機器（操作部）の表示」 例として表示機器や操作機器がどのように配置されているか示した図を用いて、どのスイッチはどの色でなければいけないか、補助手段が必要かといったことが説明されています。本文で示された基準をどのように用いるのかの参考となる例だと思います。 附属書B(参考)　　色の補助手段による基準の例 　補助手段にどのようなものがあって、どのように使うのかといったことの手がかりとなる例が示されています。特に補助手段としての可聴符号例は表示部や操作部が見えない場合（夜間、煙の中などといった状況下も考えられます）の解決手段のヒントになるのではないでしょうか。 附属書C(参考)　　電気装置のとっての操作と状態の表示 　この付属書Cはネガティブな操作（N操作：より消極的方向への操作）とポジティブな操作（P操作：より積極的方向への操作）がどういったものであるのかが学べてツマミ的には楽しい読み物となっています。また、操作を言語で表す際の定義や様々なとって（把手）、スイッチの形状と操作方向が図で示されています。全部で25ページある本規格の約1/3（9ページ）が割かれていて大変読み応えのある附属書です。 以上がJIS C 0448「表示装置（表示部）及び操作機器（操作部）のための色及び補助手段に関する規準」となります。 今日見つけた宝物 「人体、資産、環境の安全性を高める」 この宝物はJISの第1章「適用範囲」の第1項にあります。操作者や周りの方々が咄嗟の時でも安全に操作できるよう知恵を重ねてきた先人たちの努力が伺えます。UI設計に携わる方でも、直接本規格に準拠する必要のある方は少数だと思いますが、このような基準があることを知っておき色の使い方の原則を崩さないUI設計を心掛けてくださればと願います。 さてさて今日も最後までお付き合いくださりありがとうございます。本日の道行きはいかがでしたでしょうか。次のさんぽは今度こそJIS S 0137「消費生活用製品の取扱説明書に関する指針」にしたいと思っております。全く別のJISになった場合も、そこは気まぐれな道行き、是非ご一緒くださいますようお願いいたします。 ▼関連記事 JISさんぽ(01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 こんにちは、QAコンサルタントのツマミです。唐突過ぎますが私ツマミ、JIS（日本産業規格：Japanese Industrial Standards）が大好きです。お客様のプロダクト品質やプロセス品質の課題に対して何か基準は無いか、定義や分類法は無いかと探ると何かしらのJISに行き当... 　続きを読む　 Sqripts JISさんぽ(02) JIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」 こんにちは、QAコンサルタントのツマミです。皆さま、先日JIS※1スキーのツマミが報告しましたコラム、JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」はご覧いただけましたでしょうか。「インタラクションの原則」を知って... 　続きを読む　 Sqripts The post JISさんぽ(03) JIS C 0448「表示装置（表示部）及び操作機器（操作部）のための色及び補助手段に関する規準」 first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える 【第9回】発想を促すヒント 発想法というと、 第8回 で取り上げた親和図法(KJ法)がありますし、ブレーンストーミングの4つの原則やオズボーンのチェックリストなども有名ですが、説明仮説の発案には「発想を広げる」以外の切り口もあるとよいでしょう。 今回は、仮説の発想を促す「考えるためのヒント」を、2冊の書籍から紹介します。 糸口をつかむヒント 『いかにして問題をとくか』は、数学分野の教育者と学生向けに、数学の問題に立ち向かうためのヒントが書かれた本です。 ■ いかにして問題をとくか G.ポリア 著・柿内 賢信 訳／丸善出版 B6判・262頁　ISBN：978-4-621-04593-0 ※令和4年3月25日 第11版59刷発行分より紙面がリニューアルされています。 ソフトウェア設計者やテスト担当者、デバッグ担当者に向けた内容ではないのですが、挙げられている中にはソフトウェア故障/不具合の原因究明時にも役立つと思えるものがあります。 その中からいくつか紹介します（ページ番号は同書のもの）。 類似の事例を探す ソフトウェアの現場では、“初めて目にする”ような奇妙な(と思える)事象、不可解な(と思える)事象にしばしば遭遇しますが、 そのような時はすかさず： ■過去に類似した事例がないか、然るべき相手に質問/相談する。 （然るべき相手には、自分自身を含む) 具体的には： 「前にこれと同じ事例に遭遇したことはないか」 (pp. 138 – 139) 「これと似た事例、細部は違うが同様の事例を知っているか」 (pp. 163 – 164) 「これと似た事例で、解決されているものはないか」 (p. 162) 図9-1 類似の事例を質問/相談/検索する 過去の類似事例が現在直面している問題にそっくりそのまま当てはまるとは限りませんし、記録や記憶が間違っている場合もあり得ますが、似た点があれば問題の切り分け（次節参照）など考えを進める手がかりになり得ます。 また、 原因探求の過程 自体も手がかりになり得るでしょう。 （何から調べたか、どんな点に着目して原因を突き止めることができたか、etc.） 「似た事例」の場合、どの点で似ていてどの点で似ていないのか、 共通点と差異 の識別に十分注意を払いましょう。 これには 第3回 で取り上げたミルの帰納法の考え方、また 第5回 で取り上げた類比的推論(類推)の考え方が参考になるでしょう。 事象や条件を切り分ける 問題の糸口をつかむには、以下のような“発想の転換”が有効なこともあります。 ■細部に目を向けることで重要点が見えてこないか。 (pp. 44 – 51) 問題の事象が小さな事象の組合せである可能性はないか。 既知のこと・未知のことを切り分けて、把握しやすい大きさの“小問題”に分解できないか。 小さな事象を引き起こす条件(原因)を考えられないか。 個々の小問題を調べてから全体を組み合わせることはできないか。 ■小問題を別の問題に置き換えて考えることはできないか。 (pp. 69 – 75) 問題の事象自体や分解した“小問題”を、既に解明されている“類似の問題(事象)”に置き換えて、仮説を考えることはできないか。 ■複雑な条件の各部分を“分離”できないか。 (pp. 96 – 97) 原因となる条件の粒度が大きい場合、もっと小さい個別の条件の複合として捉えることはできないか。 個別の条件ひとつひとつを試す（実験してみる）ことはできないか。 他の条件を変えずにひとつだけ条件を変えて試すことはできないか。 図9-2 （複雑・巨大な）問題を切り分ける “バックグラウンドの自分”が味方 アイデアを生み出す5つの段階 『アイデアのつくり方』は、アメリカの広告業界で活躍した著者が、広告の核となる優れたアイデアを生み出す方法について解説している本です。 ■ アイデアのつくり方 ジェームス・W・ヤング 著・今井茂雄 訳・竹内 均 解説／CEメディアハウス ※本書日本語訳は、1988年に(株)TBSブリタニカから出版されました。その後阪急コミュニケーションズでの発行を経て現在はCEメディアハウスより発行されています。 本書から、仮説の着想でも参考になる「アイデアを生み出す5つの段階」を紹介します。 考えあぐねている時はこのプロセスも思い出してみてください。 （ 第8回 で紹介した図式化表現は①、②、⑤を中心に使えるでしょう） 時間に追われる場合もありますが、焦らずに考えを煮詰めていってください。 ① 資料(データ)を集める。 当面の問題そのものの資料(特殊資料)と一般的知識(一般資料)を絶えず収集する。 一般的知識の収集は継続的な活動。アップデートを怠らない。 ② 資料(データ)を考え尽くす。 資料のひとつひとつ、事項のひとつひとつを何度も、細部まで読み込み、理解する。 飽きて嫌になるくらいまで繰り返す。 ③ 考え尽くしたら、 いったん当面の問題から離れて考え続ける緊張を解く。 別の作業をしたり、関係ない書籍を読んだりなど、異なることに関心を向けるのがよい。 ④ アイデアが降りてくる。 不意を突いてくるので、閃いたら逃さないように。 ⑤アイデアを 詳しく調べ、現実に適合させる。 閃いた瞬間のままのアイデアは使いものにならないことが多い。 （ここで落胆してアイデアを投げ出さずに）当面の問題に適合するよう、具体化し、細部を検討する。 考え続ければ思いつく、とも限らない 『いかにして問題をとくか』でも、いわば バックグラウンドの自分に任せる ことの重要さに触れています。 われわれが意識的な考察をおしすすめることには限界がある． 問題からしばらく手をひくによい潮時がある． (略) しかし全然収穫がないままに手を休めることはしない方がよい． 仕事を離れるときには何か少しの点は解決し，なにかは明らかにしておくべきである． われわれが非常な熱意をもってそれをとこうとし， 異常な緊張をもってとりくもうとする問題だけがこのような成功をおさめるのであって， 意識的な努力と緊張とは無意識の仕事にはかくべからざるもの のようである． もしそうでなかったら話がうますぎる．果報はねてまてということになるからである． 出典：『いかにして問題をとくか』 pp. 153 – 154。太字は引用者による 考え詰めてから、「いったん」離れる 、というのがポイントです。 図9-3 “バックグラウンドの自分”に任せる ★ 『いかにして問題をとくか』と『アイデアのつくり方』は、どちらも主題とする分野以外にも通じるヒントをくれる書籍です。 どちらも良書なので、書店や図書館の蔵書棚などで見かけたら手にとってぱらぱら読んでみてください。 ★ 次回はアブダクションを行なう際に気をつけたいことをおさらいする予定です。 参考文献 ポリア(著), 柿内賢信(訳) 『いかにして問題をとくか』 丸善 1954 （1997(日本語第11版30刷)) 【注】本書日本語訳は、第11版59刷から仮名遣いや旧字体を改めた新装版となっています。 J.W.ヤング(著), 今井茂雄(訳) 『アイデアのつくり方』 阪急コミュニケーションズ 1988 (2012(初版64刷)) 【注】本書日本語訳は、1988年に(株)TBSブリタニカから出版されました。現在の発行元は(株)CEメディアハウスとなっています。 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える 【第9回】発想を促すヒント The post 【第9回】発想を促すヒント｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

テストエンジニアのマッツーです。 前回の記事 ではテスト自動化における「アサーション」の機能や活用方法について操作方法や所感をお伝えしました。 今回はテスト自動化において確認内容に日時が関係するような場合の実装方法について、操作方法や所感を書いていきます。 確認内容に日時が関係するケースはテスト自動化において登場する可能性が高いと思いますが、いざ実装するとなると少々難しかった点もありました。 機能の内容だけでなく実際の自動テスト実装で感じたことを書いていくので最後まで読んでいただければと思います。 過去の記事はこちらになります。 ローコード自動化ツール「mabl」#1 mablの基本操作 ローコード自動化ツール「mabl」#2 変数の使い方 ローコード自動化ツール「mabl」#3 テスト自動化における「アサーション」の機能や活用方法 ローコード自動化ツール「mabl」とコードの使用について 初めに、mablではコードを使用せずにテスト自動化を行うことが可能ですが、一部の実装内容については画面操作やトレーナーの操作のみでは実現が難しい場合があります。 本記事ではJavaScriptスニペット（以下、JSスニペット）を使用しての内容となります。 JavaScriptスニペットはコードの書き方や使用方法など初めてだと戸惑うところもあるかもしれませんが、それらについても併せて解説していきます。 ただ、時刻に関するアサーションは今後mablのアップデートによりJSスニペットを使用せずに実装可能となる可能性もあります。 現在日時のアサーションの考え方 今回は「日時を表示」ボタンを押下すると現在の日時が「現在時刻 YYYY/MM/DD hh:mm」と表示されるwebサイトを考えます。 デフォルトでは日時が表示されておらず、ボタンを押下すると日時が表示され再度押下すると日時が更新という仕組みになっています。 この画面において、ボタンを押下したときに日時が表示されることを確認したいと考えます。 単に「現在時刻 YYYY/MM/DD hh:mm」が表示されることを確認したいだけであれば前回記事で紹介したアサーションの一種であるcontainsを使用して「現在時刻」の文字が表示されることを確認するだけで済みます。 しかし、日時の表示は常に変化しているため現在時刻が正しいことの確認や複数回押下した場合に時刻が更新されることの確認はこの方法では実装できません。 そこで、時刻が更新されることを確認できるよう以下の方法を試してみます。 JSスニペットで現在時刻を取得してみる mablの基本機能には現在時刻を取得してアサーションする機能は現状存在していません。 そのため、まずJSスニペットでタイムスタンプを取得しその値を変数としてアサーションに使用するという方法を考えます。 JSスニペットを使用するには、トレーナーの「+」ボタン押下後、「JavaScript」を選択し「新規」を押下すると以下のようなエディタが表示されます。 このエディタ内に必要なコードを書き込むことで使用することができるようになります。 ここで、アサーションに使用するためにはただタイムスタンプを取得するだけでなく以下に注意する必要があります。 日本標準時(JST)に変換する 表示形式を「現在時刻 YYYY/MM/DD hh:mm」とする これらを考慮して記述したものが以下になります。 const now = new Date(); // JSTはUTCに +9時間（ミリ秒で加算） const jst = new Date(now.getTime() + 9 * 60 * 60 * 1000); // JST時刻を使用してフォーマット const year = jst.getUTCFullYear(); const month = String(jst.getUTCMonth() + 1).padStart(2, '0'); const day = String(jst.getUTCDate()).padStart(2, '0'); const hours = String(jst.getUTCHours()).padStart(2, '0'); const minutes = String(jst.getUTCMinutes()).padStart(2, '0'); const formatted = `現在時刻 ${year}/${month}/${day} ${hours}:${minutes}`; callback(formatted); JSTはUTCより9時間進んでいるため取得した時刻に9×60×60×1000を足して調整しています。 その後、年月日時分をそれぞれ取得し最後に表示形式に合わせて出力するようにしています。 各要素の取得には「getMinutes」のようにUTCを省略して記述することも可能ですが、mablでクラウド実行する際にタイムゾーンが絡んでくるためここでは「getUTCMinutes」のようにUTCで固定するようにしています。 mablでのクラウド実行におけるタイムゾーンの設定は後ほど紹介します。 これをエディタ内に記述し、実行ボタンを押下した結果が以下のようになります。 正しいフォーマットで時刻が表示されていることが確認できました。 このJSスニペットを使用するためには、保存ボタン右の「▼」ボタンから「新しい再利用可能なスニペットの保存」を選択する必要があります。 取得した現在時刻の使い方 次に保存したJSスニペットを使用してアサーションを行う方法を解説します。 ただ、直接JSスニペットを使用することはできないのでまずは変数を作成していきます。 作成方法は「+」ボタンから「変数」を開き「新しい変数を作成」を選択し、変数の設定から「JavaScript」を選択すると先ほど作成したJSスニペットを選択できるようになります。 変数名を設定して「OK」ボタンを押下すれば変数の作成は完了です。 後はこの変数をアサーション作成の際に設定すればOKです。 比較対象で変数を選択し、先ほど作成した変数を選択します。 この時「期待する値」の欄に現在時刻と異なる時刻が表示されていると思いますが、テスト実行時にはこの値ではなく現在時刻を取得してアサーションを行うので気にしなくて大丈夫です。 以上で現在時刻の取得からアサーションまで完了となります。 mablにおけるタイムゾーンについて テストの作成が完了したところで、早速実行してみましょう。 ただし、このままクラウド実行を行うと実行結果がNGとなってしまいます。 実行結果のリザルトを確認すると期待値が「現在時刻 2025/06/16 20:11」に対し、実行時の値が「現在時刻 2025/06/16 11:01」となってしまっています。 丁度9時間ずれていることからもわかる通り、テスト作成時にはJSTだったタイムゾーンがテスト実行時にUTCになってしまっているのが原因です。 そこで、テスト実行時にJSTで実行できるように設定する必要があります。 尚、ローカル実行では特に指定しなくてもテスト作成時と同じタイムゾーンで実行可能であるため、クラウド実行やプラン実行を行った場合のみNGが出ている場合にはタイムゾーンの確認を行いましょう。 設定方法自体は簡単で、「カスタマローカライズ設定」をオンにすると複数の項目が表示されます。 この中で、タイムゾーンを環境に合ったものに変更すればOKです。 今回の場合「Asia/Tokyo」を選択します。 この設定を行った後に再び実行してみます。 無事テスト結果は成功となりました。 まとめ 今回はテスト自動化において確認内容に日時が関係するような場合の実装方法について書いてきました。 特に気になった点は以下の通りです。 ・デフォルトで日時に関するアサーションを実装できずJSスニペットが必要な点 テスト自動化において日時に関連する確認項目は少なからず出てくるように思いますがノーコードでは現状実装できない点が気になりました。 ただし、生成AIによるJSスニペット作成補助機能はmablに存在するのでプログラミング知識が少なくても以前よりコードを書きやすくなったのは利点でもあります。 テスト作成時に変数を選択した際に「期待する値」に現在時刻が表示されない点 これは仕様上仕方ない部分でもありますが、初めてテスト作成する際にはトレーナー上に現在時刻が表示されないため実行するまで期待値を正しく確認できるかわからない点は少し不安がありました。 テスト実行時のデフォルトがUTCになっており、カスタマローカライズ設定を押下しないとタイムゾーンが選択できない点 これについては知っていれば問題ありませんが、私は最初テストが失敗したときに原因を発見するまで数十分ほどかかってしまったので、テスト失敗時にカスタマローカライズ設定の見直しが必要になることが表示されるとよいと感じました。 一方、コード知識が浅くても日時確認のような動的な要素をテストすることができるのもmablの良さであります。 アップデートによりJSスニペットの使用ハードルは下がっていますし、今後さらに便利になることも十分考えられます。 次回以降も様々な機能や特徴についてお伝えしていこうと思います。 mabl関連記事 ローコードでテスト自動化を実現したいなら「mabl」（メイブル） ローコード自動化ツール「mabl」#1 mablの基本操作 ローコード自動化ツール「mabl」#2 変数の使い方 ローコード自動化ツール「mabl」#3 テスト自動化における「アサーション」の機能や活用方法 ローコード自動化ツール「mabl」#4 ～確認内容に日時が関係する場合の実装方法 ｍablとGithub Actionsの連携してE2Eテストを自動化する mablで一連のステップを共通部品にして再利用できる「flow機能」について TestRailと自動テストの連携#2　mabl編 mabl APIテストでJavaScriptを用いて変数を扱う方法 The post ローコード自動化ツール「mabl」#4 ～使ってみた所感～確認内容に日時が関係する場合の実装方法 first appeared on Sqripts .

イネイブリングQAについての連載、今回は第2回となります。 ＜QA活動のスキル伝達「イネイブリングQA」　記事一覧＞ ※クリックで開きます 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 第1回 では、イネイブリングQAということばの私なりの定義や、QA組織をイネイブリングチームの形に変えていく動きについてお話しました。 今回は、イネイブリングQAを目指すうえでの注意点について解説します。 イネイブリングQAの背景（おさらい） QAのイネイブリングとは 前回の記事で詳しく説明した通り、イネイブリングQAとは： 開発チームに対して自分たちがQA業務を直接担うのではなく 従来であればテストエンジニアやQAエンジニアが行っていた業務の一部やそれを行うためのスキルを 開発者に移譲していく取り組みおよびそれを行うQAエンジニア のことです。 つまりイネイブリングQAは、QAエンジニアが持っているテスト・品質関連のスキルや、場合によっては実務の一部を開発者に移譲していく動きになります。組織全体や開発サイクル、プロダクトのことを考えたときに、そのほうがメリットが大きいと判断しているわけです。 QAエンジニアの界隈でも、「QAエンジニアやテストエンジニアだけが品質に対して責任を持つわけではない。全員で品質を高めよう！」などと言われたりします。そのためには、開発者にも品質のことを知り、担ってもらう必要があるというのは自然な流れでしょう。 開発者が抱える「イネイブリング圧」の現状 開発者を取り巻く厳しい状況 このようなイネイブリングの動きは、QAに関することだけではありません。 たとえばSRE（Site Reliability Engineering）の文脈でも、開発者に対するイネイブリングが行われています。 組織にSREの文化を作り上げていくEnabling SRE – Money Forward Developers Blog モニクルのSREチーム形成期を振り返って SREの他にも、開発者に対しては DevOps推進 ：開発と運用の統合 AI活用推進 ：AIエージェント活用と定量改善成果の要求 など、さまざまなスキルや知識を身に着け、改善することが求められています。 これらの取り組みは、個々に見ていくと当然やったほうが良いことであり、意義のあることです。 しかし開発者を取り巻くこの状況は、例えるならばあなたのもとに「管理栄養士です！」「フィットネストレーナーです！」「ファイナンシャルプランナーです！」「メンタルコーチです！」「「「「さあ、豊かな人生のためにがんばりましょう！」」」」と言われているようなものです。そう考えてみると、かなり厳しい状態に追い込まれていますよね。 イネイブリングをする側は皆、「自分たちの持っている知見や技術を伝えて、組織全体を良くしたい」という思いを持っています。しかし、それを受け取る側にも事情やキャパシティがあり、すべてをこなしていくのは困難です。 このような状況を踏まえると、イネイブリングQAを進める際には、開発者の負担を考慮した慎重なアプローチが必要になります。 具体的な注意点：どのように進めるべきか イネイブリングに重要な視点 開発者や開発組織は、さまざまな「イネイブリング圧」の下にある可能性がある。このような前提で、開発組織にアプローチしていかなければならないと、私は考えています。 そこで大事になるのは、開発者や開発組織を楽にする・効率的にするという視点です。 イネイブリングに限らず、なんらかの改善施策というのは、一時的な負担増を伴う場合があります。いままでのやり方を変え、新しいやり方をキャッチアップしなければならないとなると、当然ながら学習のための時間が必要です。また、変化に対しては心理的な負担も発生します。 とくに注意が必要な組織形態 とくに丁寧な動き方が求められるのは、開発チームとQA・テストチームという形でそれぞれが別のチームとして業務分担がなされている組織で、イネイブリングQAを実現していく場合です。 QAチームが行っていたテストの一部を、開発者により早いタイミングで実施するように開発プロセス自体を変更する、といった施策も考えられます。 開発チームからすると「なぜ今までQA側でやっていたことを開発側でもやらなければならないんだ」と反発したくなるかもしれません。単純にQAチームの仕事が減り、開発チームの仕事が増える、という見え方をしてしまうとこのような誤解につながります。 そうではなく、 最終的には今より楽になる 手間は増えるけれどもそれ以上のリターンが見込める など、開発チームにとってのメリットをまず理解してもらうことが重要です。 事例：開発チームにテスト分析・設計を取り入れる ある開発組織では、開発者が各テストレベルのテストを考え、実施していました。しかし、テストベースからそのままテストケースを導出するやり方で進めており、テストの充分性や「そもそもこのやり方で合っているのか」といった疑問を抱えていました。 そこで、イネイブリングQAから「テストケースを考える際には、何をテストするか→どうテストするかの順で段階的に考えましょう」というアドバイスを行い、テスト分析・設計相当の活動を取り入れました。 テスト実装前にテスト設計とレビューが追加されることになり、一見手間が増えるようにも見えます。しかし、いきなりテストケースを作成したあとにレビューで網羅性などを確認する負担と比べ、設計→レビュー→実装と進めたほうがレビュワーの負担が軽減されることを説明し、実践。実際に開発チームのリーダーからは「レビューがしやすくなった」というフィードバックが得られました。 このエピソードでは、あくまでもテスト分析・設計「風」の活動を取り入れたにとどまっています。しかし、QAエンジニアと同等のやり方をいきなり開発者に求めるのではなく、まずは簡易版としてのプラクティスを導入し、必要に応じてやり方を強化していくというのも有効だと考えています。 まとめ：今後の展望 本記事では、開発組織におけるイネイブリングがQAのみならず多方面から行われていることや、その中でイネイブリングを進めるうえで重要な視点についてお伝えしました。 イネイブリングQAを進めることで開発組織全体にメリットがあるのはもちろんですが、現場の開発者にとってもメリットがないとなかなか進みません。 メリットを実感してもらうためには、たとえば 口を出すだけでなく、手も動かす。QAが自分たちから動いて、課題などを引き出し、解消していく。 開発とQA両者のニーズをつなげる。開発チームの課題を解決することと、イネイブリングQA側がやるべきだと思っていることを結びつけ、取り組む。 楽になる未来を見せつつ改善を進める。 などが必要になってくるでしょう。このあたりは、次回以降の記事でも触れていく予定です。 【連載】QA活動のスキル伝達「イネイブリングQA」 記事一覧 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩 【全文公開中】 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方 The post 【第2回】「開発者の負担を軽くする」イネイブリングQAの考え方｜QA活動のスキル伝達「イネイブリングQA」 first appeared on Sqripts .