前編のおさらい 前編 となる「事前準備編」では、自動化に必要なツールとして 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 .

みなさま、こんにちはあるいは、こんばんは。「プライベートは大事だよ」の、しろです。   以前「 Playwrightはじめました 」という記事を書かせていただきました。 Playwrightはじめました ～E2Eテストを4Stepで自動化～ みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。今回はE2EツールであるPlaywrightについて書いていきます。なぜPlaywrightなのか・・・。やはり【無料】・【Microsoftが開発した】という、特徴で選定しました。▼続編はこちらPlaywright... 　続きを読む　 Sqripts その時は、画面操作して自動化できると記事を書きました。 が、今回は少し踏み込んだ内容で、Restful APIのテストについてご紹介したいと思います！ 前提 この記事を読み進めるにあたり、以下の知識があるとスムーズです。 JavaScript/TypeScriptの基本： 変数、関数、非同期処理（async/await）などの基本的な文法を理解している Playwrightの基礎知識： 先述の記事を参考に、Playwrightのインストールや基本的なテストの実行方法を把握している コマンドラインの基本操作： ターミナルやコマンドプロンプトでコマンドを実行できる Restful APIの知識：後述で触れますが、HTTPリクエストやJSONなどの知識があるとなおよし Restful APIとは？ APIテストの話に入る前に、少しだけ「Restful API」について触れておきましょう。 そもそもAPIとは？ API (Application Programming Interface) は、ざっくり言うと「ソフトウェア同士が情報をやり取りするための窓口」のようなものです。例えば、天気予報アプリが気象庁のサーバーから最新の天気データを取得する際、この「窓口」であるAPIを介して情報のやり取りをしています。 RESTの考え方 REST (REpresentational State Transfer) は、そのAPIを設計する上での考え方・ルールの一つです。 ネットワーク上のリソース（情報やデータ）に、一意のURLでアクセスし、HTTPメソッド（GET、 POST、 PUT、 DELETEなど）を使って操作するという特徴があります。 以下のようにRESTの原則に従って作られたAPIを「RESTful API」と呼びます。 GET： リソースを取得する（例: ユーザー情報を閲覧する） POST： 新しいリソースを作成する（例: 新しいユーザーを登録する） PUT/PATCH： 既存のリソースを更新する（例: ユーザー情報を編集する） DELETE： リソースを削除する（例: ユーザーを退会させる） 例えば 今回は株式会社アイビス様が提供している zipcloud というAPIサービスを使用して、郵便番号から住所を検索できるサイトを使用してAPIを実行して、住所情報を取得していきます。 ※ 過度なアクセスなどはお控えください。 例えば、東京駅の情報を取得します。 そのために「 https://zipcloud.ibsnet.co.jp/api/search?zipcode=1000005 」にアクセスします。 すると、以下のような情報を取得できます。 { "message": null, "results": [ { "address1": "東京都", "address2": "千代田区", "address3": "丸の内", "kana1": "ﾄｳｷｮｳﾄ", "kana2": "ﾁﾖﾀﾞｸ", "kana3": "ﾏﾙﾉｳﾁ", "prefcode": "13", "zipcode": "1000005" } ], "status": 200 } 実践 それでは、実践いきましょう！ 以降の記事の構成は、サンプルとして、実行できるプログラムコードを記載して、その後に各部分について解説していきます。 APIテストの概要 先述の通りですが、自前でAPIの構築や作成をするのは、少し手間がかかるので、zipcloudを使用して「東京駅」の情報を取得して内容を検証していきます。 本当は登録（POST）もしたいところですが、zipcloudにはデータを登録（POST）するための窓口は用意されていないため、今回は取得（GET）に絞って解説します。 #事前準備 Playwrightのプロジェクトが、まだない場合は、以下の記事を参考にセットアップをお願いします。 – 参考記事:「 Playwrightはじめました 」 サンプル 1. baseURLの設定 まず、 playwright.config.ts ファイルに、APIリクエストのベースとなるURLを設定します。これによって、テストコード内でURLの共通部分を省略できます。 import { defineConfig, devices } from '@playwright/test'; export default defineConfig({   // ... 他の設定   use: {     // APIリクエストのベースURL（共通部分）を設定する    baseURL: 'https://zipcloud.ibsnet.co.jp/api/search',    // ！！書き換える！！     trace: 'on-first-retry',   }, }); 2. テストファイルの作成 次に、APIテスト用のファイルを作成します。ここでは tc_get_zipcode_api.spec.ts という名前にしました。 import { test, expect } from '@playwright/test'; test('郵便番号で住所を取得する', async ({ request }) => {   // 東京駅の住所を取得   const response= await request.get(`?zipcode=1000005`)   // レスポンスの検証   // ② レスポンスコードが「成功（2xx系）」であることの検証   expect(response.ok()).toBeTruthy();  // ③ レスポンスボディ（JSON）の検証   const json = await reponse.json()   // ③-1 結果が1件だけあること   expect(json.results).toHaveLength(1)   // 結果の1件目を取得   const result = json.results[0]   // ③-2 JSONの各項目の検証   expect(result.zipcode).toBe('1000005');   expect(result.prefcode).toBe('13');   expect(result.address1).toBe('東京都');   expect(result.address2).toBe('千代田区');   expect(result.address3).toBe('丸の内');   expect(result.kana1).toBe('ﾄｳｷｮｳﾄ');   expect(result.kana2).toBe('ﾁﾖﾀﾞｸ');   expect(result.kana3).toBe('ﾏﾙﾉｳﾁ');   // ③-3 検証を緩和（具体的な値を検証しない）   expect(result).toHaveProperty('zipcode')     //  "zipcode"の項目が存在すること   expect(typeof result.zipcode).toBe('string') //  "zipcode"が文字列型であること }) 解説 ① 東京駅の情報をGET まずは、データを取得する部分をE2Eテストと比較して見ていきましょう。 E2E： page .goto({URL}) API： request .get(`{EndPoint}`)  E2Eテストのブラウザページを操作する page オブジェクトを使いましたが、APIテストではリクエストを行うためには request オブジェクトを使います。 `request`オブジェクトのHTTPメソッド（.get()、.post()、.put()など）を呼び出してAPIリクエストを送信します。引数には、 playwright.config.ts で設定した baseURL に続くクエリを記載します。今回は ?zipcode=1000005 です。 ② レスポンスコードが「成功（2xx系）」であることの検証 まず、レスポンスコードとは・・・ HTTPリクエストにおけるサーバーからクライアントへのレスポンスを3桁の数字で表すものです。 200番台は成功レスポンス、400番台はエラーと定義されています。 本題ですが、以下のアサーションコードは、上記のレスポンスコードの検証をするためのコードです。 response.ok()は、HTTPステータスコードが200番台（成功）の場合にtrueを返します。これにより、リクエストが成功したことをまず確認します。 expect(response.ok()).toBeTruthy(); それ以外は、レスポンスコードを取得して、値として検証してあげる必要があります。 expect(response.status()).toBe(200); ③ レスポンスボディ（JSON）の検証 レスポンスのボディは、ただの文字列です。 なので、まずは await response.json() を行い、オブジェクトに変換（パース）して、中身を簡単に扱えるようにします。 おまじないの「await」を忘れずに！ 変換したJSONオブジェクトの中身を検証します。 ③-1 結果が1件だけあること expect(json.results).toHaveLength(1) JSONの中にある、 results という項目に、1件だけ（オブジェクト）値があるという検証をしています。 ③-2 JSONの各項目の検証 expect(result.zipcode).toBe(‘1000005’); これは、zipcodeにセットされている値が、「1000005」と一致しているか検証しています。 ③-3 検証を緩和（具体的な値を検証しない） expect(result).toHaveProperty(‘zipcode’)     //  “zipcode”の項目が存在すること expect(typeof result.zipcode).toBe(‘string’) //  “zipcode”が文字列型であること 上記は、コメントにも記載した通りなんですが、具体的な値を検証せずに、そもそも「zipcode」という項目があるかということと、「zipcode」にセットしている値が文字列型かどうかを検証しています。 あとがき 今回はPlaywrightを使ったAPIテストの第一歩として、GETリクエストの基本を紹介しました。クセがあるように見えたJSONのアサーションも、意外とシンプルに書けることがお分かりいただけたかと思います。 今後は、以下のような内容も追加していきたいと考えています。 Pathパラメータやクエリパラメータの使用方法 POSTリクエストとリクエストボディの送信 ヘッダー情報の追加と検証 APIテストの世界は奥が深いですが、Playwrightを使えば一貫したツールでUIもAPIもテストできるのが大きな魅力ですね。 ▼関連記事 Playwrightはじめました ～E2Eテストを4Stepで自動化～ みなさま、こんにちはあるいは、こんばんは。日夜業務に励んでいる、しろです。今回はE2EツールであるPlaywrightについて書いていきます。なぜPlaywrightなのか・・・。やはり【無料】・【Microsoftが開発した】という、特徴で選定しました。▼続編はこちらPlaywright... 　続きを読む　 Sqripts VSCodeとPlaywrightで始めるウェブサイトテスト自動化：初心者向け完全ガイド こんにちは、エンジニアのぱやぴです！ 前回は「Playwright 実践～超簡単 4Step～」を解説しました。今回は、Microsoft Visual Studio Code（以下VSCode）とPlaywrightを使って、ウェブサイトのテスト自動化を実現する方法をご紹介します。具体的には、こちらのウェ... 　続きを読む　 Sqripts The post PlaywrightでAPIのテストをしてみよう first appeared on Sqripts .

※本ページに記載の部署名・役職名・所属は2025年6月12日現在の情報です こんにちは。Sqripts編集部です。 2025年6月11日(水)～6月13日(金)に幕張メッセで開催されたインターネットテクノロジーのイベント「 Interop Tokyo 2025 」に参加してきました。 今回は、6月12日に行われた基調講演のひとつ、株式会社AGEST、KELA株式会社、ULTRA RED Ltd.の3社による「 【悪用の実態】漏洩クレデンシャルと脆弱性～民間企業でも取り組める防御策を徹底解説～ 」についてレポートをお届けします。 講演名 ：Interop Tokyo 2025 基調講演 【悪用の実態】漏洩クレデンシャルと脆弱性 ～民間企業でも取り組める防御策を徹底解説～ 開催日時： 2025年6月12日（木）16:05～16:45 スピーカー： KELA株式会社 Head of pre-sales　川崎 真 氏 ULTRA RED Ltd. セールスエンジニアリング部 部長　末吉 裕二 氏 株式会社AGEST マーケティング本部 マーケティング推進部　岡部 康弘 氏 はじめに：なぜ今、このテーマなのか？ サイバーセキュリティの脅威は日々巧妙化し、企業にとって避けては通れない経営リスクとなっています。今回参加した「 【悪用の実態】漏洩クレデンシャルと脆弱性～民間企業でも取り組める防御策を徹底解説～ 」は、まさに現代のサイバー攻撃の「今」を知り、実効性のある対策を考える上で非常に示唆に富む内容でした。 サイバー脅威に対抗する「アクティブサイバーディフェンス」 講演は、AGEST社 岡部氏のセッションから始まりました。 「アクティブサイバーディフェンス」という言葉が注目される背景には、 アクティブサイバーディフェンス法案の成立 があります。これは、サイバー攻撃が単なるシステム障害に留まらず、病院の診療停止や航空会社の運航不能といった実生活に及ぶ深刻な被害をもたらすため、政府と重要インフラ事業者が連携し、 反撃を含む防御策を講じる ことを目的としています。 法案自体は、現時点では重要インフラ事業者が主体となっているため、一般企業には少し縁遠いかもしれません。この講演においては「アクティブサイバーディフェンス」という言葉の元々の意味（攻撃が発生する前に能動的な対抗措置を取ること）に立ち返り、一般企業でも取り組める能動的な防御策にフォーカスを当てていました。 「漏洩クレデンシャル」の深刻な実態 次に、KELA社の川崎氏から、サイバー攻撃の「入口のひとつ」となる「漏洩クレデンシャル ※ 」について、その実態が解説されました。 特に印象的だったのは、「インフォスティーラー ※ 」と呼ばれる情報窃取型マルウェア ※ の脅威です。 これは、PCに保存された様々なログデータ（例えばユーザーがWebサイトにアクセスする際にブラウザに保存するIDやパスワード、さらにはオートフィル機能に登録された個人情報など）をまとめて盗み出すというもの。 川崎氏は、ダークウェブのフォーラムで実際に日本の大手企業のアクセス権が売買されていた事例を紹介しました。こうした「初期アクセスブローカー」による情報の売買は日常的に行われているとのことで、「顔の見えない攻撃者同士が」「大きな金額をやり取りする」商業活動として成立しているという事実は、とてもショッキングなものでした。 ダークウェブ（Dark Web） 一般にはアクセスが難しいインターネットの隠された領域。 KELA社が観測したデータによると、昨年1年間で 約430万端末が感染 し、そこから 3億3000万件もの認証情報が漏洩 しているとのことです。ただし、KELA社がすべての情報を集めているわけではないため、実際の被害はさらに大きいだろうと川崎氏は指摘していました。 「漏洩クレデンシャルと脆弱性」講演資料より また、これらの情報が一度漏洩すると、サイバー攻撃を仕掛ける敷居が「 スキルが低くても実行できてしまう 」ほどに下がってしまうと警鐘を鳴らしました。 「漏洩クレデンシャルと脆弱性」講演資料より 情報漏洩はもはや対岸の火事ではなく、身近に迫る現実的な脅威であると改めて感じ、自社のセキュリティ対策を見直す必要性を痛感しました。 用語解説：クレデンシャル クレデンシャル（Credential） ＝資格、経歴、証明書などを意味する英単語です。 具体的には、 ユーザー名とパスワード 生体認証情報 デジタル証明書や資格証明書 トークン APIキー 秘密鍵 などがクレデンシャルにあたり、システムへの不正アクセスを防ぎ、情報セキュリティを確保するための重要な役割を担っています。 用語解説：インフォスティーラー インフォスティーラー（Infostealer） は、コンピュータから個人情報や機密データを盗み取ることを目的とした悪意のあるソフトウェア（マルウェア）の一種です。 主な特徴： パスワード、クレジットカード情報、個人識別情報などを収集 ブラウザの保存されたログイン情報やクッキーを標的にする 感染したコンピュータから情報を外部のサーバーに送信 しばしば他のマルウェアと組み合わせて使用される 感染経路： 悪意のあるメール添付ファイル 怪しいウェブサイトからのダウンロード フィッシングサイト 感染したUSBメモリなど インフォスティーラーは近年、サイバー犯罪でよく使われる手法の一つとなっており、特に個人のオンライン活動が増えた現在、注意が必要です。 用語解説：情報窃取型マルウェア（じょうほうせっしゅがたまるうぇあ） 情報窃取型マルウェア（Information-stealing malware）は、コンピュータやデバイスから機密情報や個人データを不正に収集・送信するマルウェアの総称です。 収集する主な情報： ログイン認証情報（ユーザー名・パスワード） クレジットカード・銀行口座情報 個人識別情報（氏名、住所、電話番号など） ブラウザに保存されたクッキーやセッション情報 企業の機密文書やデータベース 暗号通貨ウォレットの情報 動作の仕組み： システムに侵入・感染 指定された情報を自動的に検索・収集 収集したデータを暗号化 攻撃者のサーバーに秘密裏に送信 痕跡を隠蔽して活動を継続 被害の影響： 金銭的損失（不正送金・カード悪用） 個人情報の悪用（なりすまし） 企業秘密の漏洩 プライバシーの侵害 近年、テレワークの普及やデジタル化の進展により、この種のマルウェアによる被害が増加傾向にあります。 ランサムウェア攻撃までの流れ 川崎氏のセッションのまとめとして、二重脅迫型ランサムウェアがどのような形で攻撃が進められるのか、順番に解説がありました。 「漏洩クレデンシャルと脆弱性」講演資料より 「漏洩クレデンシャルと脆弱性」講演資料より ダークウェブで販売されたアカウントなどの情報を購入した攻撃者が初期アクセスを行い、攻撃を仕掛けます。この流れの中でランサムウェア攻撃を阻止できるポイントは「不正に入手したアカウント情報を販売」と「購入した攻撃者が初期アクセスを発見」するまでの間です。 ここで例えばパスワードリセットをするだけで、ランサムウェア攻撃の芽を摘むことができるのです。 「漏洩クレデンシャルと脆弱性」講演資料より また、ダークウェブを監視し、 不正に入手したアカウント情報を販売していることを発見する のは、自社で対応するのは難しいという解説がありました。 漏洩クレデンシャルへの対策としては、脅威情報収集力に特化した専門ベンダーを利用することを強く推奨していました。 「脆弱性管理」の現実と課題 「漏洩クレデンシャルと脆弱性」講演資料より 講演の後半では、ULTRA RED社の末吉氏が「脆弱性管理」の現実と課題について詳しく解説しました。 末吉氏によると、インターネットに直面している資産に対しては、「 1日1回 ぐらい」「 偵察行為が行われている 」とのことです。常に攻撃の対象となっているというこの事実は、システムの安全神話が通用しないことを明確に示しています。 特に印象に残ったのは、「把握できていない隠れたリスク」の存在です。 多くの企業で「危機」は見つかるとのことでしたが、「十年ぐらい前の脆弱性がそのまま残っているケースもある」という指摘がありました。これは、クラウドサービスの普及などにより、IT部門以外の部署がシステムを立ち上げるケースが増え、企業全体のIT資産の把握が困難になっている現状を表していると感じました。 脆弱性管理の具体的なアプローチとして、末吉氏は「CTEM（Continuous Threat Exposure Management）」の概念を紹介しました。これは、「どういった資産を対象にするのか」といった スコーピング から始まり、「重大性を検出し」「優先度を決め」「修正していく」というサイクルを継続して行っていくという考え方です。 「漏洩クレデンシャルと脆弱性」講演資料より リスク評価においては、一般的なCVSS（共通脆弱性評価システム） ※ だけでなく、実際の悪用状況を示す「KEV」 ※ という指標の重要性を強調されていました。 特に「KEV」に該当する脆弱性は、「 15日程度 」という切迫した期間で対応が必要とのことです。また、プラットフォームの脆弱性だけでなく、攻撃者視点での診断が必要な「Webアプリケーションの脆弱性」への対策も重要であると述べられました。 「漏洩クレデンシャルと脆弱性」講演資料より 末吉氏からのアドバイスとして、まずは「インターネットに面している資産」への対策を最優先すべきとお話しされていました。脆弱性管理は「運用を回して、徐々に徐々に改善していけばいい」という考え方もあるとしつつも、継続的な取り組みが不可欠であることを学びました。 用語解説：CVSSとKEV CVSS（Common Vulnerability Scoring System / 共通脆弱性評価システム） とは CVSSは、ソフトウェアの脆弱性の深刻度を数値で評価する国際標準システムです。 特徴： 0.0〜10.0のスコアで脆弱性の深刻度を評価 技術的な観点から脆弱性の危険度を判定 攻撃の複雑さ、必要な権限、影響範囲などを考慮 理論的な最大リスクを示す 評価項目例： 攻撃ベクター（ネットワーク経由か、物理アクセスが必要か） 攻撃の複雑さ 必要な権限レベル 機密性・完全性・可用性への影響 KEV（Known Exploited Vulnerabilities / 既知の悪用された脆弱性） とは KEVは、実際にサイバー攻撃で悪用されていることが確認された脆弱性のリストです。 特徴： 米国CISA（サイバーセキュリティ・インフラストラクチャ庁）が管理 実際の攻撃事例に基づく現実的なリスク評価 理論上の危険度ではなく、実証された脅威を示す 定期的に更新される動的なリスト 重要な違い： CVSS ：「この脆弱性はどれくらい危険か？」（理論値） KEV ：「この脆弱性は実際に攻撃に使われているか？」（実証値） CVSSスコアが低くても、KEVリストに載っている脆弱性は優先的に対処すべきとされています。実際の攻撃者が狙っている脆弱性だからです。 まとめ 「漏洩クレデンシャルと脆弱性」講演資料より 今回の講演で強く感じたのは、 「漏洩クレデンシャル」 と 「脆弱性」 という二つの「入り口」が、現代のサイバー攻撃において密接に連携し、脅威を増大させているということです。攻撃者は、漏洩した認証情報を足がかりにシステムに侵入し、見つかった脆弱性を悪用して被害を拡大させる――この一連の流れが、以前よりも「スキルが低くても」「実行できてしまう」状態になっているという指摘は、非常に恐ろしい現実です。 講演から得られた具体的なヒントは多くありました。 ダークウェブを監視することによってクレデンシャル漏洩を早期に検知し、実被害（ランサムウェア、不正アクセス）に至る前に対策（パスワードリセットや設定変更）が可能となる ダークウェブ監視の実施は非常に難しいため、専門事業者の利用を推奨 脆弱性は悪用される期間（ = 対応までの猶予期間）が年々短縮化してきており、効率的な運用が重要 CTEMというフレームワークが有効である これらはサイバーセキュリティを語る上では基本的な知識ではあるものの、このような講演に参加することで重要性を再認識することができました。 講演のアンケート結果 AGESTが発表した講演のアンケート結果を掲載します。 聴講者の声 （満足）EDR、ID保護、ダークWeb監視の次の手としてCTEMになるということが参考になった。 （満足）クレデンシャルがどのように漏洩し、攻撃に使われているかよく理解できた。 （満足）対処のための時間がどんどん短くなってきていることがよくわかりました。最新のトレンドを理解できました。 （やや不満）概論的なお話だったので、KELAやULTRA REDの優位性などをお聞きしたかった。 おわりに 本講演は、サイバーセキュリティ対策の最前線に触れる非常に貴重な機会となりました。筆者も、この学びを今後の業務に活かしていきたいと思います。 Interopのようなイベントは、普段なかなか得られないリアルな情報に触れることができる絶好の機会です。今回の講演で得た知識を活かし、今後も積極的に情報収集と対策に取り組んでいきたいと改めて感じました。 ▼2024年の講演レポートはこちら Interop Tokyo 2024参加レポート｜基調講演【情報漏洩／流出対策】最前線「ダークウェブ監視と内部不正... ※本ページに記載の部署名・役職名・所属は2024年6月12日現在の情報です2024年6月12日（水）～14日（金）に幕張メッセで開催されたインターネットテクノロジーのイベント「Interop Tokyo 2024」に参加してきました。今回は、6月12日に行われた基調講演のひとつ、株式... 　続きを読む　 Sqripts The post Interop Tokyo 2025基調講演参加レポート：【悪用の実態】漏洩クレデンシャルと脆弱性～民間企業でも取り組める防御策を徹底解説～ first appeared on Sqripts .

こんにちは、QAコンサルタントのW-Hです。 プロジェクトの遂行においては、コミュニケーションの一環として、定例会議やアドホックな会議が行われていると思いますが、私は会議の「議事録」を「プロジェクト管理ツール」の１つとしてとらえています。 そのキッカケとなったのは、今よりずいぶん若い30代半ばだった頃、あるトラブルプロジェクトのリカバリーPMに任命されたことでした。 製造～テスト工程で検出された非機能面の問題が収束せず、延伸が続いていたプロジェクトでした。 着任してお客様から言われたのは、「貴社の実装が、設計時に言っていたことと違う」ということでした。自社のチームのメンバーに確認したところ、「お客様の方が言ってることが違う」という見解だったのですが、それを示すエビデンス（議事録）が残っておらず、最終的には発注者側であるお客様の言い分を尊重して進めることを選択しました。 記録が残っていない以上、「言った・言わない」の議論を続けるのは生産的ではありません。 以来、私は、お客様のみならず、社内のステークホルダーとの会議においても、議事録に正確な記録を残し、それを重要なプロジェクト管理ツールとして運用していくことを重要視するようになりました。 以下、「プロジェクト管理ツール」として「議事録」を運用するにあたりに、私なりに大切にしているポイント（≒こだわり）をご紹介します。 議事録の目的 広辞苑によると、議事録は「会議の議事の主要事項・討議の状況を記録したもの」とされています。 私は、上述の経験を教訓として、議事録を残す目的を以下の3点ととらえています。 問題が発生したときや、意見や記憶の食い違いが生じたときに合意点に立ち戻れるようにすること。 記録をすることより、「言った・言わない」の水掛け論を防止すること。 文書として一定期間、保管・管理することにより、当事者の記憶が薄れた場合や、議論当時の当事者が不在となった場合でも基礎情報に立ち戻れるようにすること。 議事録に求められる品質 「議事録の目的」を達成するためには、単に議事録を作るだけではダメで、以下のような品質が求められると考えています。 誰が読んでも同じ理解に至り、解釈に差異の出ない記述 「言った・言わない」の水掛け論が生じないような記述 判読性の高い構成と記述 議事録が「無い」、あるいは「品質が低い」場合に想定される弊害の例 以下のようなシナリオは読者の皆様にもご経験があるのではないでしょうか？ 関係者同士で「口約束」で合意した事項があったが、当事者が退職してしまい、その内容を知る人がいなくなった。 議事録は作成したが、出席した当事者間でしかわからない書き方（≒会話の羅列）になっており、第三者には結論や合意事項がよくわからず、当該議事録をビジネス判断の材料として利用できなかった。 議事録は作成したが、結論や合意事項に至った会話の流れを一切記載しなかったので、欠席していた上司から、「XXXという観点での検討はされたのか？」という問い合わせを受け、再度、上司出席の下で同じ議論を繰り返す必要が生じた。（いわゆる、”巻き戻し”） 会話に発言者の氏名を記載していなかったため、時間が経過した後、誰の発言、判断で意思決定がなされたのかがわからなくなった。 議事録作成時のポイント さて、これまでに述べた議事録に求められる品質を担保し、弊害を防止するためには、以下のようなポイントに配慮が必要と考えています。 結論や合意事項は、ポイントを押さえて簡潔にまとめる。箇条書きや表・図を活用する。 結論だけ知りたい第三者もいると思われるため、議事録の冒頭に記載するのがよい場合がある。 結論や合意に至った協議や会話の流れを、議論のキーポイントに焦点を当てて記載する。 結論や合意事項のみを記載しても、会議に出席していないメンバーに判断の根拠が伝わらないので、どのような会話がなされたのか、どのような観点で議論が進み、結論に至ったのか、を記載する。 単に会話の羅列だけではNG。あくまで議論のキーポイントに焦点をおいてなるべく簡潔にまとめる。 会話の記録には、発言者の氏名を付記する。時間が経過すると、「誰がこの発言、判断をしたのか」など、発言者本人も忘れてしまう場合がある。 客観的な「事実」とそれ以外のアイテム（例：意見、アイデア、感想、推察など）が混同されないように配慮する。 作成した議事録は出席者間で相互確認し、必要に応じて修正をした上で、合意を得て、内容確定させる。議事録の内容が出席者の合意を得られている旨のエビデンスを残しておく。ここまで完結させて、合意エビデンスとしての議事録が有効となり、「議事録の目的」を達することができる。 会議ファシリテータに求められる役割 議事録が有効なものになるためには、実は、まず会議自体の中身が有効なものでなければなりません。そのためには会議のファシリテータには以下の役割が期待されます。 これには相応の経験が必要と思います。 会議の目的を十分に理解し、目的に合致した議論が進むようにリードする。 結論や合意事項が明確になるように会話をリードする。例を以下に示します。 ファシリテータが会議をリードする例 あるプロジェクトキックオフ会議での会話の議事録について、2つのケースを想定します。 ケース１ 議事録例 メールで事前にプロジェクト計画書をお送りしましたが、ご確認いただけましたでしょうか？(PM山田) → 一通り目を通した。(お客様川田） → ありがとうございます。(PM山田) ケース2 議事録例 メールで事前にプロジェクト計画書をお送りしましたが、ご確認いただけましたでしょうか？(PM山上) → 一通り目を通した。(お客様川上） → ありがとうございます。プロジェクト計画書の内容はご承認いただけますか。(PM山上)   → 承認する。（お客様川上) いかがでしょうか。どちらが会議をリードしているかは一目瞭然ですね。 ケース1 については、お客様川田さんは「一通り目を通した」と言っているだけで、承認したかどうかの意思表示をされていません。PM山田さんは御礼を述べているだけです。このままでは会議での確認結果として有効ではありません。 ケース2 では、ファシリテーターであるPM山上さんが、追加で「ご承認いただけますか。」という問いかけをし、お客様川上さんの「承認する」という発言を引き出すように会話をリードしています。お客様の「承認する」という記録がエビデンスとして有効になるわけです。 AIによる議事録、文字おこしの活用について 以上、かなりアナログな視点でのお話をしてきましたが、昨今、AIを用いた議事録や文字おこしを利用されているケースも多いと思います。 弊社内でも使われていますが、うまく要旨を掴んでまとめているのに感心することがしばしばあります。アジャイル開発のチーム内の会議のメモとしてはそのままで使えそうですね。 ただ、あくまで私見ですが、ウォーターフォール開発や、重要なビジネス意志決定をするような会議については、これらのAI機能は、最終的な「議事録」へのインプットとする「議事メモ」として活用するのがよいと思います。（セキュリティ、機密情報保護を担保する使い方をすべきであることは言うまでもありません。） その「議事メモ」を基に、会議の目的に合致した形で、構成や表現を整えて、「議事録」としてまとめるのが、少なくとも現時点では適切なアプローチと考えています。 あと、プロジェクトマネジメント領域のキャリアを志向している若手エンジニアの方には会議の進め方やまとめ方のスキルを身に着ける意味でも、ご自身の手で議事メモや議事録を作成する経験を積むことをお勧めしたいです。決して無駄な経験ではないと思います。 まとめ 冒頭に「プロジェクト管理ツール」と書きましたが、これは「合意事項のエビデンス」であることを再認識した上で「議事録」を活用する、という意図でした。 今回、「合意事項のエビデンス」として「議事録」を意味あるものにするために、普段、私が重点をおいている考えについて述べさせていただきました。ご参考になれば幸いです。 ありがとうございました。 The post プロジェクト管理ツールとしての「議事録」｜「言った・言わない」をなくす！”使える”議事録作成の秘訣 first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える 今回は仮説の検討を支援するのに使える図式化表現(表記法)をいくつか紹介します。 図式化に馴染んでいる人はいつも使っているものや気に入ったものを応用すればよいのですが、ふだんあまり図を描かない人は参考にしてみてください。 もちろん、ここに挙げた以外にもアブダクションを支援する“ツール”はたくさんあります。自分に合うものを探しましょう。 なお、紹介では概要のみ記しています。詳細は当該表記法の文献等に当たってください。 グラフ、ツリー、フロー グラフ ○(丸)を描いて、○と○を線で結んだだけの図(図8-1)も、グラフと呼ばれる立派な図形です（「グラフ」は数学の用語）。 ○を ノード や頂点、線を エッジ や辺と呼びます。（念のため、ノードは○(円形)でなくても問題ありません） エッジでつながれたノードの並びを 経路 と呼びます。 図8-1の(b)のように、辿っていくと始点に戻る経路は 閉じている(閉じた経路) といいます。 図8-1 グラフ 矢印のついた線を使うと、向きのあるグラフ( 有向グラフ )になります（図8-2。矢印がない図8-1は 無向グラフ ）。 有向グラフでは、経路は矢印の向きに従います。 順序や依存関係、原因・結果の関係などを表わすのに都合がよいです。 図8-2 有向グラフ 問題となっている事象やその原因(候補)、付随する事象などをノードにして、エッジでそれらを結べば、「原因と結果の関係を示す図」の出来上がりです(図8-3)。 考え始めや、考えがまとまらない時などは、事実を集めながらこんな図形でも描いて眺めてみるとよいでしょう。 問題の特徴が見えてきたり考えるべきことの焦点を絞れたりして、別の図式化の方が適しているならそちらに切り替えればよいわけです。 図8-3 グラフで考える ツリー ツリー(木)、樹形図 も誰もが知る図式でしょう。 ひとつのノードを“根っこ(ルート、root)”として、ルートから他のすべてのノードがつながっているように表した無向グラフです(図8-4)。 閉じた経路はない ツリー上の任意のふたつのノードをつなぐ経路はただひとつ 図8-1 (b)、図8-3はツリーではありません。 図8-4 ツリー ツリーはノード間の階層関係（親・子、上位・下位など）を表すのに向いています。 構成要素や概念を 段階的に詳細化 する 主題(ルート)を 特定の観点に沿って掘り下げる 主題から 発想を漸進的に広げていく ソフトウェア故障の説明仮説の検討では、故障(結果の事象)をルートに据え、原因として考えられることを枝から葉に向かって書き出しながら詳細を考える、といった使い方ができます(図8-4a)。 注意点としては： ひとつの階層で挙げる事項の観点を統一する （たとえば、事象の種類、発生部位、etc.） ひとつの階層で挙げる事項の 見落とし・重複がないように する 枝や葉で挙げる事項が 階層関係を飛び越えない ようにする （あるノードの子ノード(以下)に、そのノードの親/上位の項目を書かない） 図8-4a ツリーで考える ツリー系の表記法には ロジックツリー 、 マインドマップ などがあり、それぞれに適した用途や描き方があります。 フロー 原因から結果に至る筋道を描くなら、これもおなじみのフロー図があります。これもグラフの親戚です。 グラフそのままとしても描けますが、 フロー系の表記法には アクティビティ図 、 フローチャート を始め、表現力が高いものが多くあります。 図8-5 フローで考える(アクティビティ図の例) フロー系の表記を利用する場合には、「ソフトウェアの実行の詳細な流れや動作」に注意を奪われないように気をつけましょう。 「原因から結果に至る過程」と「ソフトウェアの詳細な動作」は一致しないこともよくあります。 連関図 事象間の因果関係の解明を支援するための図式化表現に 連関図 があります(図8-6)。 （連関図は新QC七つ道具のひとつです） 結果事象(解決したい問題)に 多くの事象(原因) が関係しており、 事象どうしの因果関係が複雑 と見込まれる状況で、 事象間のつながり、因果関係を図示 し、全体を俯瞰しながら 主原因 を検討する場合に適しています（プロセス改善時の原因分析など）。 図8-6 連関図 注意点としては： 結果事象に直結するノードには 一次原因 として、事象を引き起こした直接の原因を配置する。 一次原因に 抜け漏れ・重複がないように する 一次原因から、それを引き起こした原因という風に、 結果から原因を逆向きに 考える 原因から結果へのつながりをよく考える（ひとつの原因から複数の結果、複数の原因からひとつの結果） 主原因（支配的な原因や、対策を打つべき原因）が必ずしも末端のノードにあるとは限らない。 問題が生じても、それを無化したり回復する仕組みを設けて対処すればよい場合もある ソフトウェアの故障や不具合でも、複数の要因が絡み合ったり連鎖したりした結果であることはしばしばあります。 特に人的要因が絡んでくる場合にはこの図式化は適しています。 親和図(KJ法) そもそも原因の手がかりがつかめない、現象自体が入り組んでいてよく判らない、といった状況なら、親和図(KJ法A型図解)を使ってみるのも手です（図8-7。親和図は新QC七つ道具での呼称です）。 図8-7 親和図 ソフトウェア故障や不具合について、確認された事実を集め、グループ化してみることで（たとえば、環境や設定、事前状態、付随して発生した事象、事後状態、など）、込み入ったデータが整理されていき、重要な事柄が見えてくるでしょう。 図8-7a 親和図で考える どんな図式化を使うにしても 気をつけたい点 手段と目的が入れ替わらないように気をつけましょう。 きれいな図、“正しい”図を描こうとすることに労力を傾けてしまう （その結果、事実を集めたり見直したり発想を広げたりすることに時間がさけない） 図が間違っていると感じた時に修正するのを躊躇してしまう 仮説を考える助けとして図を描いているだけなのですから、図のきれいさや図としての“正しさ”を気にする必要はありませんし、間違いに気づいたらさっさと破棄して描き直すのが吉です。 まず、目に見える形に表そう どこから手をつけていいか見当がつかない、原因や過程の候補を思いつかない、といった五里霧中状態では、「考える手がかり」を考えるのが大変だったりします。 先に紹介した親和図(KJ法)的アプローチはそんな場合に有効で有用です。 関係のありそうな ものごとをとにかく 書き出す （先行/後続する事象, 環境や設定, 実際に行なった操作, etc.) 関係のなさそうな ものごとでも目にしたものや気になったことは 書き出す つながりがありそうなものがないか考える （関連しそうなものをグループ化してみる、関係なさそうなものは取り除けておく、etc.） ★ 視覚化してもいい考えが出てこないという時は……次回は仮説の着想を促す「考えるためのヒント」を紹介します。 参考文献 猪原正守 『新QC七つ道具　混沌解明・未来洞察・重点問題の設定と解決』 日本規格協会 2016 二見良治 『演習　新QC七つ道具』 日科技連出版社 2008 川喜田二郎 『発想法　改版』 中央公論社 2017 図版に使用した画像の出典 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 【第8回】 視覚化して考える The post 【第8回】 視覚化して考える｜実務三年目からの発見力と仮説力 first appeared on Sqripts .