帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第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 .

皆様こんにちは、ハヤシです。 2025年5月30日(金)に開催された、JaSST2025東北に参加してきました。 初めての仙台、JaSST、新幹線などでいろんな経験ができました！ それでは基調講演とワークショップで行った活動をもとに参加レポートを作成いたします。 JaSST東北とは JaSST東北とは、NPO法人ASTER (ソフトウェアテスト技術振興協会) が主催する「Japan Symposium on Software Testing (JaSST)」の東北地方での開催を指します。 JaSSTは、ソフトウェアテストに関する最新の情報やノウハウを共有し、ソフトウェア業界全体のテスト技術向上を目指したシンポジウムです。（ JaSST公式サイトより ） JaSSTの開催地 JaSST公式サイトより JaSST東北の流れ 以下は今年のJaSST東北の正式名称とテーマ、テーマ概要、プログラム概要です。 正式名称： JaSST’25 Tohoku　ソフトウェアテストシンポジウム2025東北 【やってみよう！テスト開発 〜チームで育てるテスト観点〜】 テーマ： 「テスト設計」 テーマ概要： JaSST東北、本年のテーマは「テスト設計」です。 シンポジウム後半には、テスト設計を体験できるワークも用意されています。そこで本セッションでは（主にテストの）「設計技術」について、お話します。 ご参加のみなさまの理解をより深めていただくために、背景となるテスト設計のモチベーションや、技術の世界観全体感をつかむためのテスト設計プロセスの話題も盛込んで、設計の話を展開します。また設計技術を学んでいくためのヒントも提供できればと思います。 JaSST’25 Tohoku公式サイト より プログラム概要： 基調講演→ワークショップ（全体説明）→ワークショップ１→ワークショップ2 ※参加前に心掛けていたこと 僕自身去年の4月に新卒で入社後、今までの案件でテスト設計を一からからやったことはなかったので（1回は以前あった設計を元にアップデートされた内容を追加して修正するだけでした。）将来担当することになるテスト設計のために、「実践で使えるテスト設計インサイト」を確実に自分のものにして帰ろう、という気持ちで参加いたしました。 基調講演「テ。ーテストの設計についてー」 今回の基調講演に登壇された方は近美克行さん（シーイーシー／ディペンダビリティ技術推進協会／ASTERテスト設計コンテスト）でした。セッションが始まる前からテストに関するすごい情熱が伝わってきて本当にプロフェッショナルな方だと感じました。 基調講演では全部話しきれない分量のプレゼンテーション資料でしたが、テスト設計における重要なポイントを中心に講演してくださいました。（テストに関する愛を感じました！） 講演の流れ 　講演の流れは以下のような流れでした。 PART1. なぜ、わざわざ（テストの）設計を行うのか？ 設計の目的（ゴール）を知る PART2. 設計技術を構成する技術要素や原則を知る そして設計のご利益を知る PART3. 設計技術を磨くアイデアを考える PART1.なぜ、わざわざ（テストの）設計を行うのか？（テスト）設計の目的（ゴール）を知る テスト設計を行う理由を理解するために本講演のPART1ではまず、ソフトウェア開発で設計が行われなかった時にどのような困りが生じるかについて考えることから始めました。 以下は本講演で述べられた設計を行わなかった時の困りごとです。 事前検証機会の喪失（作ってからじゃないと設計の良し悪しが判断できないため） 知識共有機会の喪失（設計レビューの形で有職者の支援が受けられない） コミュニケーション機会の喪失（設計書というドキュメントの形で情報を残さないことにより、未来の自分、他の設計者、実装者、テスト担当、保守担当者に設計知見や意図が伝達できない） たしかに…と考えました。設計をしてドキュメントの形で保存すると上記全てをある程度未然に防ぐことができるかと。なんとなくわかってはいたものの、確実にまとめて説明して頂いてきれいな形で頭の中に整理される感じでした。 では、設計をすることによって得られる利益は以下となります。 事前検証機会確保によるフィードバックループの短縮→速度向上 知識共有機会確保による「既知・確実」情報の共有 コミュニケーション機会確保による合意形成達成・説明責任の達成 困りごとと連携される利益でとてもわかりやすく、設計を行うことによるメリットとデメリットが確実に理解できました。 そこからテスト設計の場合どのようになるかをみると… 事前検証機会の確保 製品出荷以前にテストの有効性を判明し、致命的な有効性不足を判明できる 知識共有機会の確保 最近のソフトウェアは一人で作成、実施、検証するには規模が大きすぎるため、知識共有機会の確保により、多数人でプロジェクトを行える コミュニケーション機会の確保 もし、テストを一人でできたとしても、利害関係者への説明は必要となる このように、テスト設計は絶対的に必要なプロセスだということがわかりました。 PART2.設計技術を構成する技術要素や原則を知る。そして設計のご利益を知る PART2ではテスト開発プロセスを重点に講演が進みました。以下星マークがついてる部分がこの講演で重点的に扱われた部分です。 テスト開発プロセスにおける、 ☆ テストの目的は？ テストのINPUTは？　 テストベース テストのOUTPUTは？　 テストケース ☆ テストの構成要素（情報要素は？） ☆ 構成要素間の相互作用は？ のうち、星マークがついてる部分を講演の内容を元に解説していきます。 1. テストの目的は？ 欠陥の修正（QC）への貢献と品質保証（QA）への貢献 欠陥の修正（QC）への貢献 いかに少ないコスト （人的リソース、時間、スキルニーズ、精神力など）で、是正に      つながる 欠陥を発見できるか？ NGが発生する条件を絞り込めるような十分な情報提供ができるか？ 欠陥であることが正しく判断しやすいか？ 品質保証（QA）への貢献 開発とテストプロセスがどの程度うまくいっているか？ についてのフィードバックに使う すべての利用者、利用状況、ユースケースの組み合わせは現実的に検証不可能であるため、品質保証目的、目標のモチベーション（テスト結果を証拠として、検証したい内容）を定義し、それにあわっせて適切な品質保証戦略（論証戦略＝説明ロジック）を構築する 2. テストの構成要素（情報要素は？） テスト要求とテスト条件の集合 テスト目的に関する情報要素：テスト要求  （品質論証の論証ゴールと論証の有効範囲を表現したもの） →テストの目的のパートで解説したもの テストケース実装に関る情報要素： テスト対象とテスト対象の持つI/Fに関連する情報 3. 構成要素間の相互作用は？ テストフレームやテストコンテナで表現されるテストケースやテスト条件の依存関係 テスト同士に依存関係がある場合、複数のテストケースをまとめて管理/実行する必要　があります。そのため、テストコンテナやテストフレームといった単位で整理します。 こうした単位でまとめる際に、「どのような目的・利益を得たいか」を明確にすることも、テスト活動において重要なポイントです。 PART3.設計技術を磨くアイデアを考える 　PART3では、設計技術を磨くポイントとしていくつかをご紹介くださいました。 　各ポイントは以下になります。 夢は大きく！ 設計を学ぶ際のポイント 続けるのは楽しさ（そして達成感） ひとつずつ述べて自分の感想を加えていきます。 1. 夢は大きく！ 目指すは全自動！ すごく共感しました。全自動を目指していたら、もし全自動にならなかったとしても、テストの全体的なプロセスのうち大多数が自動化できるのは可能かと考えました。 自然言語や図のコンピューター解析技術も進歩している 最近のAI技術の成長から見て私も近未来では人でしか対応できなかったテストをAIに任せられる日が来るのではないかと考えました。 2. 設計を学ぶポイント 設計の目的を意識する 一番大事かと思います。常に目的を意識してると必要なことに早く気が付き、自ら学ぶのではないかと考えました。 ゼロから考えることは大変なためパターンやベストプラクティスを学ぶ パターンやベストプラクティスを学ぶことによって一番正解に近い設計になると考えました。加えてその数が多ければ多いほど精度はより高くなるのではないかと考えました。 しかし、真似するだけでは成長できないのでそれらはあくまでも一例として、現場、コンテキストに合わせて使う必要があることも伝えてくれました。 3. 続けるのは楽しさ（そして達成感） 仲間を持つ 一人ではできないことも多数では行けるので大切だと考えました。仲間自体がモチベーションになることは自分も経験したことがあり、すごく共感しました。 継続は力 継続することにより、習慣になり、携わっていた絶対的時間が増えることで結果も残り、続けられる力になると考えました。 ワークショップ VSTePとは？ VSTeP（Viewpoint-based Software Test Engineering Process）とはテスト技法の一つで簡単に説明すると「テストケースをざっくり考えてから具体化する方法」になります。 いきなり細かいところから考えると大きな抜け漏れが発生しやすいので、一例としてブレインストーミングのような形で出来るだけ多くの観点を出し、UMLっぽい図を用いて（わかりやすくするため）どんどん具体化していく形です。 以下はVSTePの簡単な流れとなります。 テスト要求分析（テスト観点を出す）→テストアーキテクチャ設計（テストコンテナ設計）→テストアーキテクチャ設計（テストフレーム設計）→テスト詳細設計（テストケース作成）→テスト実装 （テストスクリプト作成） 今回のワークショップでは上記の流れのうち「テスト要求分析（テスト観点を出す）」と「テストアーキテクチャ設計（テストコンテナ設計）」の部分を実際やってみました。 各ワークショップで行った活動については下で詳しく説明いたします。 ワークショップ１（テスト観点図作成） ワークショップは4人一組で行うグループ作業でした。（私のチームは3人でした…）各チームごとにファイルボックスがあり、その中に今回行うワークショップの資料が入っていました。（ワークで使用するターゲットユーザの情報、機能設計書等）今回の対象プログラムは「アラームアプリケーション」でした。 運営の方々から「機能設計書はまず詳しく見ずに、アラームアプリケーションで必要だと考える観点をだし、後から機能設計書に合わせて対象外判定など行ってください〜」と言われました。 そこで私達のチームでは「まず各自でできるだけ観点を出して発表し合い、議論して追加すべきと考えられる観点を追加」する方法で行いました。 私は一人で考える時は「アラームアプリケーションで抜けてはいけない」点を中心に観点を作成いたしました。 （作成した観点一例：レイアウト・表示、ボタン挙動、状態遷移、画面遷移、アラーム正常起動、編集機能等） 個人作成の時間が終わり、他のチーム員と作成した観点をすり合わせてみたら…なんと重なる部分と重ならない部分で 5:5 くらいの割合でした。 ある程度自分が考えていなかった観点も出てくることも想定していましたが、自分一人では長く考えても思い浮かばなさそうな観点もあり、集合知性の力を感じました。 その後はお互いの観点とその観点を選んだ理由などを聞き、議論して追加の観点を引き出す作業をおこないました。議論することで、より多くの観点を見つけることができ、自分の視野もどんどん広くなっていくことを感じました。 最後には今まで出した観点を大きな項目で分け、対象外の観点はステッカーで表示し、ツリー構造でまとめることでワークショップ１の作業は終わりました。大きな項目で分ける時は作成した観点を最大限同じカテゴリーの観点とまとめること、大項目の考え方に注意しながら作成しました。 以下は私たちのチームで作成したワークショップ１の成果物です！ 作成が終わった後5分ほどで他のチームの成果物を見ることができました。見てから考えたのは「どのチームも同じではないが納得できる、私たちのチームで出なかった観点だけど必要な観点だ」等私たちのチームの改善点、良かった点、悪かった点等をもう一度考えられる良い機会でした。 　ワークショップ２（テストコンテナ図作成） ワークショップ２ではワークショップ１で作ったテスト観点図をもとにテストコンテナ図の作成を行いました。 テストコンテナとは？ テストコンテナとは、テストタイプやテストサイクル、テストレベルをまとめたもの うまくまとめると全体像を把握しやすくなる JaSST2015東京 より 上記の説明をもとにテストコンテナ図とは、テスト観点を「テストタイプ」「テストサイクル」「テストレベル」などの分類で整理し、図として可視化したものと考えられます。 私たちのチームはワークショップ１で作成した観点をもとにテスト実行手順に沿ってテストコンテナ図を作ることにしました。「どの観点をどのタイミングで実施するか」の判断がとても難しく、議論にも大きな時間がかかりましたが、結果的にはよくまとまってるテストコンテナ図になったのではないかなーと思います。 以下は作成したテストコンテナ図です！ ※テストコンテナ図で表現したテストの順序は以下です 「UI、基本機能チェック」→「アラーム作成（基本動作確認）」→「アラーム動作（アラームがなる時の動作）」→「アラーム削除→アラーム動作（アラーム削除後の動作）」→「アラーム編集、詳細設定」→「アラーム動作（詳細設定されたアラームの動作）」→「性能（アプリの性能）」→「異常系」→「アプリ外要因」→「アラーム動作（アプリ外要因によるもの）」 今回もまた他のチームの成果物を拝見できる機会があり、見させていただきました。感想は以下になります。 意外とコンテナが少ないチームもある 私たちのチームは機能的な面を中心に作成したが、非機能のテスト観点を含んでいるチームもあった やっぱりチームによって分類の仕方が大きく異なる。でも全部納得できる。 気づいた点、今後活かせると考えられるポイント 気づいた点 今回のJaSST2025東北を通じて気づいた点は大きく分けて3点あります。 テスト設計が必要な理由の明確化 複数人でテスト設計を行う時の利点、コミュニケーションの重要性 私が属しているチーム以外の成果物から得た気づき まずは１の「テスト設計が必要な理由の明確化」です。いままで漠然と「テスト設計は必要」だと考えていましたが、それがなぜ必要なのか、しなかった時にどのようなことが起きるのかに関して深く考えていませんでした。 しかし、今回その理由とそれにより得られる利点を明確化したことで、今後行うテスト設計の理解を深めることができました。 2の「複数人でテスト設計を行う時の利点、コミュニケーションの重要性」はワークショップでチーム活動を行い、お互いの観点、フィードバックによりどんどん成果物の完成度が上がることを目にしました。 そこで複数人の観点、良いコミュニケーションが合わさったことにより、上がる成果物の完成度は「たし算ではなく掛け算に近い」と感じました。それにより「私の観点を増やす」、「コミュニケーション能力を増やす」ことの重要性にもう一度気づきました。 3の「私が属しているテスト設計チーム以外のチームの成果物をみる利点」は成果物作成後、他のチームの成果物を見ることにより、観点の拡大を感じました。 自分の成果物を見ることが大事なのはもちろんのこと、時には他のチームの成果物を見ることもエンジニアとして成長するために大切な行動であるということにも気づきました。 今後業務で活かせると考えられるポイント 　数多くのポイントがありますが、基調講演とワークショップでいくつかを選別して説明します。 基調講演 「テスト設計の方向性、情報の位置付けと関連性」 テスト設計の方向性 設計するテストの目標をしっかり把握し、その目標にたどり着けるテストを設計することでテストの抜け漏れが発生しないようにする 情報の位置付けと関連性 情報同士の位置付けと関連性を考えることにより、テストの網羅性を向上し、設計の一貫性と論理性の向上を得られる。 ワークショップ 「設計時のコミュニケーション、VSTePのやり方」 設計時のコミュニケーション 自分の意見の出し方、他チーム員の意見を受容する姿勢、議論を通じた意見のすり合わせ VSTePのやり方 テスト観点の出し方、出したテスト観点の整理、テストコンテナの設定（どのような形で分けるか） このような点を今後の業務で活かせると考えました。 おわりに 今回JaSST2025東北に参加することにより、参加されえた多数の方たちからたくさんのインサイトを得ることができ、エンジニアとして一歩成長することができたと思います。これを読まれてる皆さんもぜひ機会があれば参加してみると成長につながると思います。 長文を読んでいただき、ありがとうございました。 The post JaSST’25 Tohoku 参加レポート｜テ。ーテストの設計についてー first appeared on Sqripts .

前回の連載 では、1人目QAとしてチームを立ち上げていく部分、組織づくりに関する内容についてお伝えしました。 【第1回】QA組織立ち上げの流れと組織の形 以前の連載である1人目QAとしての立ち回りでは、会社や開発組織の1人目QAになった人がどのような活動をするのかや、品質保証を浸透させる際のアプローチなどについて触れました。今回の連載では1人目QAとしてチームを立ち上げていく部分、組織づくりに関して、私が実... 　続きを読む　 Sqripts 筆者はQAエンジニアとして業務をしていますが、特定の開発チームに所属してテスト業務や品質改善を行っている、という動き方が中心ではありません。どちらかといえば、開発チームに対して外から関わり、開発者へのテスト・QA技術の伝達や、効果的に品質向上ができるような支援を行っています。 こうした関わり方について、他社のQAの方から「自分たちもそのような形を目指しているが、うまくいかない」「ヒントがほしい」といった声をいただくことがあります。そのため、自分なりの取り組みについて語ることも意味があるだろう、と思い今回連載のテーマとして選びました。 本連載では、QAチームを立ち上げている間もしくはチームが形になってきたあとで、実際に開発チームに貢献する形の1つとしての「イネイブリングQA」の概念と、メリットや注意点についてお伝えしたのち、開発組織に品質技術を根付かせたその先の姿についても考えてみたいと思います。 「自社でもイネイブリングQAを目指しているものの、開発チームとの連携がうまくいかない」「どのように品質技術を伝達すればいいか具体的な方法がわからない」といった課題を持つQAエンジニアの皆さんへ、本連載が解決の糸口となることを願っています。 イネイブリングQAとはなにか まずはじめに、イネイブリングQAという概念についてご説明します。 イネイブリングQAというのは厳密に定義された用語ではありませんが、私の観測範囲では2023, 4年ごろから用いられているようです。 なぜQAエンジニアがSLO導入をリードしたのか – tebiki_techblog SmartHRのライティング組織の3つの役割｜otapo チームメンバー全員で品質を向上させる。タイミーのQA EnablingTeamとは？｜Timee 私の考えるイネイブリングQAは、このあとご説明するイネイブリングのスタイルで業務にあたっているQAエンジニアおよび業務そのものを意味しています。 ITエンジニアの界隈で「イネイブリング」という言葉が使われるようになったのは、『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』がきっかけでしょう。 ■ チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 （マシュー・スケルトン 著／マニュエル・パイス 著／原田　騎郎 訳／永瀬　美穂 訳／吉羽　龍太郎 訳／JMAM）　 この書籍は開発組織のチーム構成を「ストリームアイランドチーム」や「イネイブリングチーム」などの概念で説明していて、イネイブリングチームは以下のように書かれています。 イネイブリングチームは、特定のテクニカル（プロダクト）ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う。 イネイブリングチームはスペシャリストで構成される小さくて長続きするグループで、ある時点では１チームもしくは少数のチームだけ担当し、チームの能力と認知を向上させることに集中する。 『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』が出版されたのが2021年末（※原著は2019年に出版）なので、日本で目にするようになったのはここ数年の間です。 この「特定ドメインのスペシャリストが、開発チームの能力ギャップを埋めるのを助ける」という概念、すなわち開発チームになんらかの技術を伝え身につけてもらうという動き方を私は「イネイブリング」と捉えていて、この概念をQAに当てはめたものを「イネイブリングQA」と読んでいます。 整理すると、イネイブリングQAとは 開発チームに対して自分たちがQA業務を直接担うのではなく 従来であればテストエンジニアやQAエンジニアが行っていた業務の一部やそれを行うためのスキルを 開発者に移譲していく取り組みおよびそれを行うQAエンジニア のことです。たとえば、テスト設計技法やテストプロセスに関するナレッジをまとめて開発者に対してレクチャーを行うなどの活動が該当します。 イネイブリングQAという呼称自体は新しいものの、その概念は以前から存在しており、たとえば1999年出版の『Automated Software Testing』（邦訳：『自動ソフトウェアテスト　導入から、管理・実践まで　効果的な自動テスト環境の構築を目指して』）に登場する「システム方法論およびテスト（SMT）チーム」の活動と共通点が見られます。 SMTチームの活動として チームメンバーは、次から次へとさまざまなプロジェクト開発チームの主任と一緒に作業をして、知識移転、その他の活動を遂行する。 と述べられており、私はイネイブリングQAに近い概念だと捉えています。 このように、イネイブリングQAという呼称自体は『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』をきっかけに徐々に出てきている状態ですが、その概念や考え方自体は以前からあるもののようです。 開発組織とQAとの関わり方をイネイブリングQAに転換する動き イネイブリングQAのような形での開発組織への関わり方を目指すのは、どのような理由からなのでしょうか。 ひとつには、採用や体制面の都合があると見ています。 最近はITエンジニア全般的に採用が大変だ、という声を耳にします。QAエンジニアも同様で、募集を出しているけれどもなかなか集まらない、という会社さんもあるようです。システムテストなどテストの実務的な部分を担うエンジニアを、それに足るだけの人数採用するというのは、かなり大変です。そうなると、テスト・QAエンジニアだけではなく、開発者自身がテスト等の業務も行うような業務設計にならざるを得ません。 実態としては、このような会社ではもともと開発者自身でテストなどの品質関連の業務を行っているか、もしくは外部のテスト会社の力を借りている場合が多いようです。とくに前者の場合、内製のQAエンジニア組織を立ち上げることになったとしても、開発者が主体となって品質関連の業務を行っているというメリットは活かしたまま、QAエンジニアを採用してイネイブリングを中心とした活動を行うのは理にかなっていると思われます。 他のパターンとしては、開発組織の中にテスト・QA組織がすでにあるものの、開発効率や品質意識の向上を目指してイネイブリングQAにシフトしていきたい、という場合もあります。 開発チームとテスト・QAチームがある程度別れており、開発プロセスにおいて「後工程での品質担保」が常態化してしまっている場合があります。このような組織では、シフトレフトを目指して開発者を積極的に品質向上に巻き込んでいくため、QAチームの業務をイネイブリング主体に切り替えようという動きが出てきます。 上記のような理由で、QA組織の動き方、とくにテストに関連する部分の動き方を「自分たちがテスト計画から実行・報告までをすべて担う」から「開発者がそれらの活動を行うのを助け、技術移転する」というイネイブリングQAへの転換をする動きが見られています。 今後の連載トピック：イネイブリングQAの課題と考慮すべきこと このあとに続く連載の各回では、以下のトピックについて触れる予定です。 イネイブリングの注意点 イネイブリングに必要なスキル イネイブリングした先の姿 QAは何をイネイブリングされたらいいのか、イネイブリングすることと引き換えに何をするのか 先に挙げた組織課題などに対する解のひとつとしてイネイブリングQAを志向し、実現に向かって動いているQA組織もあるようです。しかし、「QAは手を動かしません」「開発者や他のロールの皆さんを中心に品質を担保します」と宣言するだけでは、おそらくうまくいきません。 「開発者がテストの重要性を理解してくれない」「品質向上に必要なスキル習得に時間を割けない」「QAチームが単なる『口を出すだけの存在』と見なされてしまう」といった問題も発生する可能性があります。 今後の連載においては、そうしたイネイブリングQAを進めていくうえでの注意点や、必要となるスキルについてご説明し、イネイブリングQAを進めた先で我々QAエンジニアはどうなるのかについて考えていきます。 The post 【第1回】イネイブリングQAとは何か？開発組織に品質文化を根付かせる第一歩｜QA活動のスキル伝達「イネイブリングQA」 first appeared on Sqripts .

こんにちは！QAエンジニアのK.Kです。 今回はPostmanを使用したAPIのシナリオテストについて解説していきたいと思います。 APIのシナリオテストについて なぜAPIのテストが重要なのか 現代のアプリケーション開発では、APIが重要な役割を果たしています。フロントエンドとバックエンドの連携、外部サービスとの統合、マイクロサービス間の通信など、APIは様々な場面で使用されており、APIの品質が低いと、アプリケーション全体のユーザーエクスペリエンスに大きな影響を与えてしまいます。 「シナリオテスト」が求められる背景 従来のAPIテストでは、個々のエンドポイントの動作確認が中心でした。しかし、これだけでは以下の問題が見過ごされる可能性があります。 エンドポイント間の連携エラー ：前のAPIで取得したデータを次のAPIで正しく使用できない 状態管理の問題 ：セッション情報や認証状態の維持ができない データ整合性の問題 ：複数のAPI操作後のデータ状態が期待と異なる パフォーマンスの劣化 ：連続したAPI呼び出しでの応答時間の増加 実際のユーザーの行動を模擬した一連のAPIリクエストを通じて、上記の問題を見つけ出すことが可能となります。例えば、ブログシステムでは以下のような流れをテストします。 ユーザー情報取得 → 認証・権限の正常性確認 投稿一覧取得 → データ取得とページネーションの動作確認 新規投稿作成 → 作成処理とデータベース登録の確認 投稿詳細取得 → 作成したデータの一貫性と関連情報の整合性確認 投稿更新・削除 → データ変更処理と他機能への影響範囲の確認 この一連の流れを通じて、単体テストでは発見できない「エンドポイント間の連携エラー」「状態管理の問題」「データ整合性の問題」を効率的に検出できます。 APIシナリオテストのメリット シナリオに沿ったテストにおいてE2Eテストも存在しますが、APIレベルでのシナリオテストには異なる価値があります。両者は補完的な関係にあり、適切な使い分けが重要です。 E2EテストとAPIシナリオテストの特徴比較 観点 E2Eテスト APIシナリオテスト 検証範囲 UI操作からデータまでの全体フロー API層のビジネスロジックとデータフロー 実行速度 時間がかかる 高速実行が可能 適用タイミング UI完成後 バックエンド開発完了後すぐ 得意分野 ユーザー体験の検証 データ処理・連携の検証 それぞれの適用場面 E2Eテストが適している場面 ユーザーの操作フローの検証 画面遷移や表示内容の確認 ブラウザ固有の動作検証 統合テストの最終確認 APIシナリオテストが適している場面 ビジネスロジックの詳細検証 データ整合性の確認 マイクロサービス間の連携テスト 継続的インテグレーション（CI）での自動テスト 大量データ処理のテスト APIシナリオテストの特有のメリット 早期テスト開始 ：UIが完成する前からバックエンドの品質を検証可能 詳細なデータ検証 ：レスポンスデータの詳細な検証が容易で、データ構造や値の妥当性を厳密にチェック 高速実行 ：ブラウザやUIレンダリングが不要で、テスト実行時間を大幅に短縮 安定した実行環境 ：ブラウザバージョンやOS環境に依存せず、安定したテスト実行が可能 並行実行 ：軽量なため、大量のテストケースを並行実行してCI/CDパイプラインに組み込みやすい シンプルなデバッグ ：リクエスト・レスポンスが明確で、問題の特定と修正が迅速 効果的なテスト戦略 APIシナリオテストとE2Eテストを組み合わせることで、以下のような段階的なテスト戦略が可能になりますす。 開発初期 ：APIシナリオテストでビジネスロジックを検証 統合段階 ：E2Eテストでユーザー体験を検証 運用段階 ：両方を組み合わせた包括的な品質保証 Postmanとは？ Postmanの概要 Postmanは、APIの開発やテストを効率的に行うためのプラットフォームです。 なぜPostmanがシナリオテストに向いているのか 1. 直感的な視覚操作 GUIベースでAPIリクエストを簡単に作成・編集 ドラッグ&ドロップでワークフローを構築 テスト結果をリアルタイムで視覚的に確認 2. 高い再利用性 コレクション機能でテストケースを体系的に管理 環境変数を活用した柔軟な設定切り替え JavaScriptを使用した高度なテストスクリプト 3. AI補助機能 Postbotによるテストスクリプトの自動生成 自然言語でのテスト要件入力 4. 豊富な機能 チーム間でのテストケース共有が容易 CI/CDパイプラインとの統合 環境構築手順 必要なもの Postman Postman公式サイト からデスクトップ版をダウンロード または Web版（ https://web.postman.co/ ）にアクセス テスト対象API 本記事では、JSONPlaceholder（ https://jsonplaceholder.typicode.com/ ）を使用します これは無料で利用できるRESTAPIのテストサービスです 注意 : JSONPlaceholderはテスト用のAPIサーバーのため、POST/PUT/DELETEリクエストは実際にはデータベースに反映されません。レスポンスは正常に返されますが、データの永続化は行われないことをご了承ください Postmanによるシナリオテストの実践方法 コレクションとフローの概要・比較 Postmanでは、 コレクション機能 と フロー機能 の2つの方法でシナリオテストを実施できます。 特徴 コレクション フロー 操作方法 リスト形式でリクエストを管理 ドラッグ&ドロップの視覚的操作 学習コスト 低い（従来のAPIテスト経験があれば習得容易） 中程度（視覚的だが新しい概念） 複雑な処理 JavaScriptコードで実装 GUIで条件分岐・ループを設定 デバッグ コンソールログで確認 実行フローを視覚的に追跡 適用場面 CI/CDへの組み込み 非技術者との共有 メリット・デメリット コレクション 学習コストが低い 既存のAPIテスト資産を活用可能 CI/CDとの連携が簡単 複雑な条件分岐の実装が煩雑 フロー 複雑なワークフローを視覚的に表現 非技術者でも理解しやすい エラーハンドリングが直感的 新しい機能であるため学習が必要 コレクションを使った手法 コレクション機能は、関連するAPIリクエストをグループ化し、順次実行するPostmanの基本機能です。フォルダ構造でテストを整理し、環境変数を活用してデータを受け渡しながらシナリオテストを実現します。 例：ブログAPIのシナリオテスト 1. コレクションの作成 まず、新しいコレクションを作成します。Postmanの左サイドバーで「Collections」タブを選択し、「Create Collection」ボタンをクリックします。 作業内容解説 ： コレクション名に「Blog API Scenario Test」などの分かりやすい名前を設定 フォルダ構造でテストを分類（認証、CRUD操作、エラーハンドリングなど） 2. 環境変数の設定 環境変数を設定することで、異なる環境（開発、テスト、本番）でのテスト実行や、テスト間でのデータ受け渡しが可能になります。 作業内容解説 ： 「Environments」タブから新しい環境を作成 baseUrl にAPIのベースURL（ https://jsonplaceholder.typicode.com ）を設定 postTitle 、 postBody などのテストデータを定義 実行時に動的に設定される変数（ userId 、 postId ）用の枠を用意 3. 各リクエストの詳細設定 設定画面(01_Get Users) 作業内容解説 リクエスト名を分かりやすく設定（01_Get Users） HTTPメソッドとURLを指定 「Tests」タブでレスポンス検証とデータ抽出を行うJavaScriptコードを記述 01_Get Users このリクエストでは、全ユーザー情報を取得し、最初のユーザーIDを後続のテストで使用するため環境変数に保存します。 GET {{baseUrl}}/users Tests: pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); pm.test("Response has users", function () { const jsonData = pm.response.json(); pm.expect(jsonData.length).to.be.greaterThan(0); // 最初のユーザーIDを環境変数に保存 pm.environment.set("userId", jsonData[0].id); }); 02_Get Posts 全投稿を取得して、APIが正常に動作することを確認します。 GET {{baseUrl}}/posts Tests: pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); pm.test("Response has posts", function () { const jsonData = pm.response.json(); pm.expect(jsonData.length).to.be.greaterThan(0); }); 03_Create Post 新しい投稿を作成し、前のステップで取得したユーザーIDを使用します。 POST {{baseUrl}}/posts Body (JSON): { "title": "{{postTitle}}", "body": "{{postBody}}", "userId": {{userId}} } Tests: pm.test("Status code is 201", function () { pm.response.to.have.status(201); }); pm.test("Post created successfully", function () { const jsonData = pm.response.json(); // 作成された投稿IDを保存 // pm.environment.set("postId", jsonData.id); // テスト用のAPIサーバであるため投稿したIDが使用できないので100を設定 pm.environment.set("postId", 100); }); 04_Get Created Post 作成した投稿が正しく取得できることを確認します。 ※本来は先ほどの手順で追加した投稿を取得すべきだが、JSONPlaceholderではPOSTで追加した投稿はデータベースに登録されないため、登録済みの投稿を取得 GET {{baseUrl}}/posts/{{postId}} Tests: pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); pm.test("Retrieved correct post", function () { const jsonData = pm.response.json(); pm.expect(jsonData.id).to.eql(100); pm.expect(jsonData.title).to.eql("at nam consequatur ea labore ea harum"); }); 05_Update Post 投稿内容を更新し、変更が正しく反映されることを確認します。 PUT {{baseUrl}}/posts/{{postId}} Body (JSON): { "id": {{postId}}, "title": "{{postTitle}} - 更新版", "body": "{{postBody}} 更新されました。", "userId": {{userId}} } Tests: pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); pm.test("Post updated successfully", function () { const jsonData = pm.response.json(); pm.expect(jsonData.title).to.include("更新版"); }); コレクションランナーでの実行 1. コレクションランナーを開く 作成したコレクションの「…」メニューから「フォルダーを実行」を選択します。これにより、コレクション内の全リクエストを順番に自動実行できます。 2. 実行設定 Iterations ：テストを何回繰り返すかを設定 Delay ：リクエスト間の待機時間を設定（APIサーバーへの負荷軽減） Data File ：CSVやJSONファイルからテストデータを読み込み 3. 実行結果の確認 各テストの成功/失敗状況が一覧表示 レスポンス時間の確認でパフォーマンス問題を早期発見 失敗したテストの詳細情報を確認してデバッグ コレクション手法のメリット 一括実行 ：複数のAPIを手動で実行する必要がなくテスト効率が向上 再現性 ：同じテストを何度でも同じ条件で実行可能 フローを使った手法 概要 フロー機能は、APIリクエスト間の関係性を視覚的に表現し、複雑なワークフローを構築できるPostmanの新機能です。条件分岐やループ処理をGUIで設定でき、プログラミング知識が少ない人でも複雑なシナリオテストを作成できます。 実践例：条件分岐を含むAPIフロー フローの構成 以下のような条件分岐を含むワークフローを作成します。 Start (初期設定) ↓ Get All Users (全ユーザーの情報を取得) ↓ Get All Posts (全投稿を取得) ↓ Loop 全投稿 └─If (一番最初のユーザーの投稿かどうか) ├─YES → Update Post (投稿を更新) └─NO → 次の投稿へ 作成されたフロー図 作業内容解説 フローの作成 ：Postmanで「Flows」タブを選択し、新しいフローを作成 Start ブロック ：フロー開始時の初期設定を行う API リクエストブロック ：既存のコレクションからAPIリクエストをドラッグ&ドロップで追加 Loop ブロック ：全投稿をループ処理するための設定 If ブロック ：条件分岐の設定 接続線 ：各ブロック間のデータフローを視覚的に設定 フロー手法のメリット 視覚的理解 ：複雑な条件分岐も図で一目瞭然 リアルタイムデバッグ ：実行中にどのブロックが動作しているかをリアルタイムで確認 エラーハンドリング ：エラー時の処理フローも視覚的に設計可能 チーム共有 ：非技術者でもワークフローの内容を理解しやすい AI機能（Postbot）の活用 Postbotの概要と機能 PostbotはPostmanに組み込まれたAIアシスタントで、以下の機能を提供します。 1. テストスクリプトの自動生成 自然言語での要件入力 適切なJavaScriptテストコードの生成 ベストプラクティスに基づいたコード提案 不足しているテストケースの提案 2. APIドキュメントの自動生成 リクエスト・レスポンスからドキュメント作成 サンプルコードの生成 API仕様書の自動更新 利用例 テストスクリプトの自動生成 Postbotに以下のように指示： ユーザーが1件以上存在することを検証するためのテストと最初のユーザーのIDを変数に保存するためのコードを書いてください。 自動生成される例： pm.test("Ensure at least one user is retrieved", function () { const jsonData = pm.response.json(); pm.expect(jsonData.length).to.be.greaterThan(0); }); // 最初のユーザーIDを環境変数に保存 pm.environment.set("userId", pm.response.json()[0].id); Postbotに以下のように指示： Add basic tests 自動生成される例： // Check if the response status code is 200 pm.test("Status code is 200", function () { pm.response.to.have.status(200); }); // Check if the response body is an array of users pm.test("Response body is an array of users", function () { const jsonData = pm.response.json(); pm.expect(jsonData).to.be.an('array'); pm.expect(jsonData.length).to.be.greaterThan(0); }); // Check if the user ID is saved in the environment variable pm.test("Save the first user's ID in environment variable", function () { const firstUserId = pm.response.json()[0].id; pm.environment.set("userId", firstUserId); }); APIドキュメントの自動生成 ドキュメントが空の状態から自動生成される例： まとめ APIシナリオテストは、単体テストやE2Eテストでは捉えきれない独自の価値を提供します。本記事の実践を通じて、その真の価値を改めて確認することができました。 APIシナリオテストが解決する主要課題 実ユーザー体験の再現 ：単発的なAPIテストでは発見できない、一連のAPI呼び出しで発生するデータ整合性や状態管理の問題を早期発見 システム間連携の信頼性 ：マイクロサービス環境での複数サービスを横断する処理の信頼性を確保 データ一貫性の検証 ：CRUD操作の流れにおけるデータベース状態の一貫性を継続的に検証 性能問題の早期発見 ：連続したAPI呼び出しで発生するセッション管理やキャッシュ関連の性能劣化を特定 開発プロセスへの貢献 UIが完成する前からバックエンドの品質を検証できるため、開発ライフサイクル全体での品質保証を効率化できます。また、CI/CDパイプラインに組み込むことで継続的な品質確保が可能となり、アジャイル開発やDevOpsにおいて重要な役割を果たします。 今回の実践を通じて、APIシナリオテストは現代のソフトウェア開発における品質保証の要となる手法であることを再確認できました。適切なツールの選択と活用により、その価値を最大限に引き出すことが重要です。 The post APIテストを強化する！Postmanのシナリオテスト活用法 first appeared on Sqripts .

QAエンジニアとして、日々の業務に取り組む中で、ふと孤独を感じる瞬間はありませんか？ もしかしたら、「この問題意識を持っているのは自分だけだろうか」「この改善に取り組もうとしているのは、もしかして私一人なのではないか」と感じてしまうことがあるかもしれません。 そう感じているのはあなただけではないと私は断言できます。 もしあなたが今、孤独を感じているとしても、あなたは一人ではありません。 世の中には、同じように悩み、学び、高め合おうとしている仲間がいます。 本記事では、QAエンジニアとしてのキャリアをより豊かにするための最終話として、仲間を見つけることの意義と、コミュニティやイベントがもたらす価値についてお伝えしたいと思います。 ＜QAエンジニアのスタートガイド 記事一覧＞ ※クリックで開きます 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- 【第5回】コミュニケーションが鍵を握る 【第6回】学ぶ姿勢を持ち続けよう 【第7回】良い働き方を継続するためのマインドセット 最終回【第8回】あなたは一人ではない、共に走る仲間を見つけよう コミュニティやイベントという存在 もし、あなたの所属する組織の中に、心を開いて話せる仲間がいないと感じるならば、思い切って社外に目を向けてみることをおすすめします。 幸いなことに、QAやソフトウェアエンジニアリングの領域には、様々なイベントやコミュニティが存在します。 これらの場は、新しい知識や技術を学ぶいい機会となります。 そして、同じ志を持つ人々と出会い、繋がり、「私は一人ではない」という確かな実感を得られる、非常に価値のある場所です。 コミュニティで得られる豊かな学び コミュニティに参加することで得られるものは、単なる情報交換だけではありません。 そこには、あなたのQAエンジニアライフをより豊かにしてくれる、大切な要素が詰まっています。 正統的周辺参加 例えば、コミュニティの場に身を置くことは、「正統的周辺参加」と呼ばれることがあります。 これは、積極的に発言したり、中心的な活動に参加したりしなくても、その場の雰囲気や会話、他の参加者の様子から、自然と多くの学びや刺激を得られるという考え方です。 周囲の人たちの議論を聞いたり、他の人がどんな課題に悩んでいるかを知るだけでも、多くの気づきがあるはずです。 そうした経験を重ねることで、徐々にコミュニティの中心的な活動へ関われるようになっていく、それが正統的周辺参加という考え方です。 第三の居場所 また、コミュニティは、家庭でも職場でもない「第三の居場所」となり得ます。 普段の業務から離れて、共通の興味や課題について気兼ねなく話し合える場所があることは、いいリフレッシュの機会になります。 自分と同じ状況にいなくても、同じような課題や技術を通じて、同じような学びを持つ人たちが集まり、お互いにゆるやかに支え合う場として、コミュニティに参加することは自分のキャリアを充実させるために必要な要素の一つだと考えています。 仲間の存在があなたを引き上げる コミュニティで出会う人たちは、あなたの成長を後押ししてくれる存在です。 同じように品質向上やいいソフトウェア開発を目指して努力している人たち、自分にはない知識や経験を持つ人たち、そして何よりも、あなたの取り組みや悩みに共感してくれる人たちと出会うことができます。 仲間の活躍を見て刺激を受けたり、彼らの視点やアプローチから新たなアイデアを得たりすることもあるでしょう。 仲間の存在が、まるで自然な力のように、あなたをより高いレベルへと引き上げてくれることを実感できるはずです。 コミュニティ参加における注意点 コミュニティに参加することは非常に有益ですが、いくつかの注意点もお伝えしておきたいと思います。 内輪ノリと感じてしまう まず、初めて参加するコミュニティでは、最初は少し居心地の悪さや内輪感を感じてしまうかもしれません。 既に仲の良いグループによる「その場のノリ」ができているように見えたり、話についていけないと感じたりすることもあるかと思います。 これは多くの人が経験することです。 そのような場合でも、気後れしたり斜に構えたりせず、まずはその場の雰囲気を観察し、楽しんでみることをおすすめします。  楽しんでいるうちに、自分自身が気になることもなくなる経験を私はしました。 現場を手放さない 次に意識したいのは、コミュニティでの活動を通じて、普段の自分の仕事を充実させることです。  コミュニティの活動自体を楽しむことも大事ですが、そこで得た学びや刺激を、現場で実践することも重要です。 参加していく中で、「自分の現場ではどのように活かせるだろうか」と考えながら参加することは、より楽しむための有意義な視点でもあります。 現場を悲観的に捉えない 最後に、コミュニティで他の組織や個人の話を聞いた際に、自分の所属する現場と比較してしまいがちになる点には、注意が必要です。 これは、「エンジニアのはしか」 ※ と言われることもあります。 ※参考記事: 「エンジニアのはしか」について｜意欲ある若手が陥りやすい？それを乗り越えるには？ 「社外の人たちはこんなにキラキラしているのに自社はだめだ」と思ったり、「自分の会社の人は意識が低い」と思ってしまうことがあるかもしれません。 こういった感情を持つことは、実は多くのエンジニアが経験しています。 そして、後になって恥ずかしいと思っている人が多いです。 私もそうです。 「隣の芝生は青い」ということわざがあるように、現場と離れている非日常のコミュニティで話すからこそ、実際よりもキラキラしているように見えているのかもしれません。 しかしながら、キラキラしている人の話を聞いてみると、実際には自分とそう変わらない難しい現場で泥臭くもがいた結果であることも少なくありません。 私が大切にしていることは、「現場ときちんと向き合う」ということです。 「社内の他の人」がいるとして、その人がどのような気持ちで働いているのか、どのような考えを持っているのかについて、社外コミュニティの人と接するのと同じように興味を持ち、共感することです。 そういった中で、「自分は現場の中でどう違う思いを持っているのか」「そんな中で自分は現場でどう貢献できるのか」を真剣に考えることが、私はコミュニティを有効活用する手段だと考えています。 仲間を探せる場所 具体的にどのような場所で仲間を見つけられるのでしょうか？ まず、テストコミュニティがあります。これはQAやソフトウェアテストに特化したコミュニティで、専門的な知識や現場の課題について深く話し合うことができます。 例えば、 JaSST というソフトウェアテストシンポジウムや WACATE といったソフトウェアテストに関するワークショップがあります。 これらは一見すると敷居が高いように見えますが、むしろ初参加の人を歓迎したいと思っている人たちが運営していることは断言できます。 私も testingOsaka という大阪のテストコミュニティを運営していますので、ご近所の方はぜひ参加してほしいと思っています。 ソフトウェアテストだけでなく、開発コミュニティに参加するのも非常に良い経験になります。 ソフトウェア開発のプロセス全体への理解を深めることは、QAエンジニアとしての視野を広げ、開発チームとの連携を強化するためにも重要です。 「自分はQAだから開発コミュニティは場違いかも…」と思うことがあるかもしれませんが、意外とそんなことはありません。  私の経験では、「テストの専門家」として話すだけで、良い意味で個性を出すことができます（キャラ立ちします）。  そして、そんな開発系コミュニティの中で、ちょっとしたテストに関する話をするだけで、「参加できてよかった」と言ってくれる人がいます。 私はそんな人が1人でもいるだけで、参加する価値はあると思っています。 イベント告知サイトで「QA」や「テスト」といったキーワードや興味のある内容で検索してみると、多くのコミュニティやイベントが見つかるでしょう。 オンラインで開催されているものも多いので、まずは気軽に参加してみてはいかがでしょうか。 おわりに 〜そして現場と向き合う〜 現場にいると、時に困難で、孤独を感じることもあるかもしれません。 しかし、あなたは一人ではありません。同じように悩み、学び、成長しようとしているたくさんの仲間がいます。 コミュニティやイベントは、そうした仲間と出会い、繋がるための素晴らしい機会です。 そこで得られる繋がりや学び、そして何よりも仲間の存在は、あなたのQAエンジニアライフをより豊かにし、困難を乗り越える勇気を与えてくれるでしょう。 そして、コミュニティを通して、自分の現場についても同じように向き合ってみてください。 また違った視点で現場と向き合えたり、もしかしたら気づかなかった仲間に出会えるかもしれません。 社外のコミュニティに参加する良さとは、 社内に対して新しい視点を得られること だと私は考えています。 QAエンジニアとして充実させるために、繰り返し伝えたいのは、現場に目を向けるということです。 学び続け、仲間と共に、より良い製品を顧客に届けるという目的に向かって、それぞれの現場で頑張っていきましょう。 そしていつか、コミュニティで皆さんとお会いできることを楽しみにしています。 【連載】QAエンジニアのスタートガイド 記事一覧 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- 【第5回】コミュニケーションが鍵を握る 【第6回】学ぶ姿勢を持ち続けよう 【第7回】良い働き方を継続するためのマインドセット 最終回【第8回】あなたは一人ではない、共に走る仲間を見つけよう The post 【第8回】あなたは一人ではない、共に走る仲間を見つけよう｜QAエンジニアのスタートガイド first appeared on Sqripts .

初めまして。金丸です。 この度、私が参加していたSQiP研究会の研究成果として執筆した論文「繰り返しのテストを要する生成AIテストの効率化 – 類似度算出と同義文判定による検証コスト削減の検討 -」が、幸運にも最優秀賞をいただくことができました。本日は、この研究にどのように取り組み、SQiP研究会でどのような経験を得られたのか、私の視点からお話ししたいと思います。 ※SQIP研究会とは？ ソフトウェア品質向上と開発プロセス改善をテーマに、日科技連が主催する実践的な学びの場です。参加者は事例共有や討議を通じて、現場で役立つ知識やノウハウを深め、具体的な課題解決を目指します。 なぜSQiP研究会に参加したのか？ 私がSQiP研究会に参加した一番の動機は、日々進化する「AI」に関する最新の動向や技術に対する強い渇望感でした。特に、私たちの主要な事業領域である「ソフトウェアテスト」において、AI、とりわけ生成AIの存在感は無視できないものになってきています。しかし、そのテスト手法についてはまだまだ確立されていない部分が多く、体系的で詳細かつ具体的な知識を身につけたいと考えていました。SQiP研究会であれば、様々なバックグラウンドを持つ専門家の方々と集中的に議論できる機会があると考え、参加を決めました。 試行錯誤から生まれた研究テーマ SQiP研究会は、月1回の定例会を中心に活動が進みます。午前中は特別講義として、ソフトウェア品質に関する第一線で活躍されている講師の方々から、大変示唆に富むお話を伺うことができます。午後は分科会に分かれ、それぞれのテーマに沿った知識共有や活発なディスカッションが行われます。 私たちの分科会には、私と同じようにAI、特に生成AIのテストや品質評価に課題意識を持つメンバーが集まりました。最初は漠然とした問題意識の共有から始まりますが、議論を重ねるうちに、それぞれが抱える具体的な課題の共通点が見えてきます。そこで、似通った課題を持つメンバーでチームを組み、検討するテーマを絞り込んでいきました。 私たちのチームが着目したのは、生成AIの「回答の多様性」がテストの大きな負担になっている、という点でした。同じ問い合わせをしても、AIの回答の表現は毎回異なります。もちろん、その意味内容が同じであれば問題ないのですが、テスト担当者はその都度、回答を読んで内容が正しいかを確認する必要があり、これが繰り返しのテストにおいて膨大な工数を生み出していたのです。 研究の核心：類似度評価はテストを効率化できるか？ この課題を解決できないか、という問題意識から生まれたのが、本研究テーマである「類似度算出と同義文判定による検証コスト削減」の検討です。つまり、生成AIが生成した文章の意味的な類似度を機械的に評価し、「これは以前に確認済みの回答と同じ意味内容だ」と判定できれば、人間の確認作業を大幅に削減できるのではないか、と考えたのです。 研究では、この「類似度の数値化」の手法として、文章をベクトル化して類似度を測る「埋め込み表現のコサイン類似度」と、生成AI自身に類似度を評価させるという、ある種ユニークな「生成AIによる類似度評価」の2つのアプローチを取り上げ、どちらがより人間の感覚に近い判定ができるかを比較検証しました。 夏には泊まり込みの合宿を行い、長時間にわたり集中的に議論を深めました。この合宿で、研究の方向性が固まり、その後の実験計画が具体的に定まりました。合宿後は、メンバー間で役割分担を行い、手分けして実験データの準備、実験の実行、そして結果の分析を進めました。 実験の結果、特に生成AIを用いた類似度評価が、人間の感覚により近い評価傾向を示すことが明らかになりました。AUC（曲線下面積）という評価指標で比較しても、生成AIによる評価の方が高い値を示し、テスト効率化の手段として一定の有効性があることが示唆されました 。一方で、文章が長くなると類似度が高く判定されやすくなるなど、課題もいくつか見つかりました 。これらの実験結果に基づき、メンバー３名で分析を行い、追加で検討すべき観点なども取捨選択しながら、研究の論旨をまとめていきました。   論文執筆、そして成果報告会へ 12月頃からは、研究成果を論文としてまとめる作業と並行して、成果報告会での発表資料作成を進めました。論文執筆は初めての経験でしたが、メンバーと協力し、お互いのドラフトをレビューしながら推敲を重ねました。 そして迎えた3月の成果報告会。緊張感のある空気の中、研究成果を発表しました。発表会後に「最優秀賞」という素晴らしい評価をいただき、チームメンバーと共に喜びを分かち合いました。 SQiP研究会に参加して得られたもの、そしてそのメリット・デメリット SQiP研究会に参加して得られたものは非常に大きかったです。まず、最新のAI品質評価に関する国内外の知見や、RAG、Ragas、MCPといった関連技術の情報をキャッチアップできたことは、日々の業務にも直結する大きなメリットでした。また、特別講義や分科会での議論を通して、講師陣や他の参加メンバーからいただいた本質的で的確なレビューやフィードバックは、研究の質を高める上で不可欠でした。 SQiP研究会の大きなメリットとして挙げられるのは、「締め切り駆動で研究を進めることができる」点だと感じています。本業がある中で研究活動の時間を確保するのは容易ではありませんが、定例会や論文提出、発表会といった明確なマイルストーンがあることで、モチベーションを維持し、計画的に研究を進めることができました。そして何より、普段の業務では関わることが難しい、社外の様々なバックグラウンドを持つ方々と深く議論できたことは、自身の視野を広げ、新たな視点や着想を得る上でかけがえのない財産となりました。 おわりに 私の所属している会社ではSQiPでの活動も業務の一環として認められており、この論文以外にも、非常に多くの知識を得ることができました。 今後、それらを社内のAIテストのワーキンググループなどにフィードバックし、よりよいAIテスト手法の構築を目指して行きたいと考えております。 参考文献 繰り返しのテストを要する生成AIテストの効率化 – 類似度算出と同義文判定による検証コスト削減の検討 – (本研究論文)(PDF) AIプロダクト品質保証コンソーシアム ガイドライン 謝辞 最後に、本研究を共に推進し、貴重なご意見とご協力を賜りました共同研究者の皆様に心より感謝申し上げます。 リーダーとして本研究を牽引してくださった 中川 桂 様（東京海上日動システムズ株式会社）、共に研究員として議論を重ねた 多田 麻沙子 様（TIS株式会社） には大変お世話になりました。 主査として的確なご指導を賜りました 石川 冬樹 様（国立情報学研究所）、副主査として本研究をサポートしてくださった 徳本 晋 様（富士通株式会社）、アドバイザーの 栗田 太郎 様（ソニー株式会社） に深く感謝申し上げます。 皆様のご協力なくして、本研究の成果は得られませんでした。この場をお借りして、改めて御礼申し上げます。 The post SQiP研究会で生成AIテストの最前線に挑む：不確実性による評価の壁をどう乗り越えるか？ first appeared on Sqripts .

はじめまして。クオリティコンサルタントの つとう工房 です。 ソフトウェア開発における「品質」とは、いったい何を意味するのでしょうか。 PMBOKやISO等の国際的な標準に準拠し、チェックリストを整備し、ルール通りにレビューを行う。確かに、それは品質保証にとって欠かせない取り組みの一つです。しかし、「品質」の問題に関して、私が、現場で常に感じているのは、その取り組みだけでは不十分だということです。 真に求められるのは、現場の実態を理解し、プロジェクトごとの特性を見抜き、表層的な課題の奥に潜む本質を見極める力。言い換えるならば、“イメージ力”と呼ばれるものの重要さです。本稿では、気軽な読み物の体裁を保ちながら、私が、直近対応した大規模プロジェクトの事例をもとに、“イメージ力”がなぜ品質向上に不可欠なのかを掘り下げてみたいと思います。 1. 品質の確保を阻んでいたのは開発に向き合う“体質”だった 現在、私が支援中の案件は、3年にわたる大規模システム開発プロジェクトです。私が参画したタイミングでは、開始からすでに2年以上が経過していましたが、進捗管理も、プロダクトの品質管理もまったく機能していない状態でした。 ヒアリングを開始した当初、関係者からは「うまくいっていないのは外部要因のせい」「人手不足がすべての原因だ」といった声がまことしやかに囁かれていました。 しかし、私は、その言葉を鵜呑みにせず、現場で交わされる会話、提出された資料、ミーティングでの空気感から醸し出される、いわゆる“ノイズ”に注目しました。そうして、時間をかけて丁寧に観察していくうちに、次第にプロジェクトの根本的な問題が浮かび上がってきたのです。 問題の本質は、管理スキルの不足にはなく、開発部門に根付いた“組織体質”にありました。 たとえば、明らかに遅延しているのに「全体的には順調です」と報告されるケースが散見されたり、進捗会議では数値を用いた報告がほとんどなく、問題を報告する文化自体が欠如していたり、さらには、開発メンバーの多くが「自分のタスクだけやっていればよい」という姿勢で、チームとしての一体感が感じられない雰囲気が蔓延していました。 エンドユーザーからは、「遅延の原因を具体的に示してほしい」「今後の改善策を提案してほしい」といった要求が繰り返し出されていましたが、開発側からは具体的な説明もなければ、対策の提示もありませんでした。結果として、ユーザーとの信頼関係は大きく損なわれ、プロジェクトの空気は次第に重苦しくなっていくのが、傍からも感じ取れました。 PMBOK、ISO/IEC25010およびISO/IEC9126に基づく改善提案 私は、品質コンサルタントとして、本プロジェクトの中盤からこの案件に参画させていただき、PMBOK、ISO/IEC25010およびISO/IEC9126などに基づく、A4用紙100枚程度の体系的な改善提案書を作成しました。 そして、その提案書の中で、 進捗管理の可視化 リスク管理の仕組みの提案 レビュー手順の見直し などの提案を展開しました。 しかし、その一方で、その作業を進めながら、この提案だけでは足りないと強く感じながら執筆を進めてもいました。 なぜなら、この現場の品質の根本的な問題は、プロジェクトマネージメントのテクニカルな手法不足に起因しているというよりも、「事実を正しく受け止めようとしない・伝えようとしない」という姿勢の欠如、つまり“ ファクト＝事実 ”に寄り添うというごくごく常識的で基礎的な姿勢の欠如にあると痛感していたからです。 レトロスペクティブ文書にまとめる これを受け、私は、テクニカルな提案書とはまた別に、振り返り文書として「レトロスペクティブ文書」をまとめることにしました。 「レトロスペクティブ文書」では、まず、この数年にわたってエンドユーザーが声を上げても、不毛地帯に向かって叫んでいるように実行に結びつかなかった、あたかも“暖簾に腕押し”のように繰り返されてきた虚しいやりとりを、ひとつひとつ議事録から拾い上げ、その実態を示しました。そして、問題の根本原因は、開発担当部門の組織体質に関わる問題であり、プロジェクトの状況をありのままに報告し、解決に向けて真摯に取り組む姿勢がなかったことに起因すると結論付けました。 そして、さらにそれを受け、「進捗を正直に報告する」「問題を隠さずに共有する」「曖昧な表現を避ける」といった、組織として根付かせるべき“行動様式”を示し、「良い報告ではなく、正しい報告が信頼を生む」「実態を変えずに見せかけだけ整えても意味がない」といった箴言も書き添えることにしました。これらの提言は、テクニカルな手法以上に、文化的な改革の重要性を訴えるものでした。 2. 「イメージ力」が導く実践的な品質支援 品質エンジニアが、品質改善を検討する上で最も重視しなければいけないのは、プロジェクトに対して杓子定規に「標準規格を適用する」という点にはありません。もちろん、標準に従うことは大変重要ですが、それ以上に必要なのは、「 現場の実態を正しくイメージし、適切な手を打つこと 」です。それを、私は、“イメージ力”と呼びたいです。 “イメージ力”とは、形式に表れない情報を読み取る力です。たとえば、ある週の進捗会議で「ほぼ予定通りです」と報告されたとします。その言葉の裏に、何があるか。関係者の表情や声のトーン、前週の報告との矛盾、未提出の成果物の存在、些細な変化に注意を向けることで、プロジェクト実態の息遣いを汲み取ることができます。 また、開発メンバーとの雑談の中からも、重要なヒントを得ることがあります。あるメンバーが「最近は、毎晩遅くまで残業していて…」と漏らした一言から、タスクの見積もりに無理があることを察知し、工数再計算の提案をしたこともありました。これは、数値データだけでは決して見えてこない問題です。 また、ドキュメントレビューでも、単に「記載ミスがないか」をチェックするだけではなく、「このドキュメントで次工程の作業者が正しく動けるか」という視点を持ちます。文書が整っていても、読み手の視点を想像しなければ、品質は担保できません。実際、過去にレビューで「問題なし」とされた仕様書が、実装段階で多数の不整合を生んだケースもありました。 こうした経験から、私は、「品質とは、書かれていないものを想像する力」によって左右されるものと考えます。品質エンジニアにとっての武器は、標準規格の知識だけではなく、現場と対話し、空気を読み、背景を推察する“イメージ力”なのです。 以下、ここまで詳述してきた“イメージ力”について、簡潔に要約してみます。 現場とつながり、密に対話する姿勢を持つことの必要性 直接、現場に足を運ぶ、ないし定期的な対話やオンラインでのやり取りを通じて、現場の声や温度感をつかむことの重要性。情報の行間や空気を捉えるには、「話す量」と「聴く姿勢」が何より大切であるということ。 些細な変化や違和感を見逃さない観察眼を持つことの必要性 進捗報告やレビュー内容、メンバーの一言一言の裏にある「兆し」に気づくためには、日頃から注意深く観察し、「あれ？」と感じる感度を磨いておく必要があるということ。 ドキュメントや発言の“先”を読み、次工程や他者の立場を想像することの必要性 成果物は、次工程の作業者にどう伝わるか？ 実際に手を動かす人の視点を想像することで、形式だけではない「本当に使える品質」を見極めることが可能になるということ。 標準の適用に捕らわれ過ぎず、柔軟に現場に合わせた対応を心掛けることの必要性 いうまでもなく標準は重要ですが、それをどう現場に馴染ませるかが、品質エンジニアの腕の見せ所。常に、現場の実態を起点に考える姿勢が、品質改善の鍵になるということ。 私が、本稿でお伝えしたい“イメージ力”は、上記のような形に要約できるかと思います。 3. 前職のQA統括部門に抱いた違和感 私の前職では「QA統括部」という部門があり、全社の品質保証活動を担っていました。部門としての体制は整っており、各プロジェクトに対して一律の品質ガイドラインを適用するスタイルでした。 しかし、私は、その部門の品質に対するアプローチに対して、長年、強い違和感を抱いていました。なぜなら、その施策の多くが“目的化”しており、本来支援すべき現場の実態と乖離していたからです。 たとえば、ある小規模な改善プロジェクトでは、ステークホルダーが限られており、関係性も非常に安定していたにもかかわらず、「PMBOKに記載されているから」という理由だけで、「ステークホルダー・エンゲージメント・アセスメント・マトリックス」の提出が求められたことがありました。担当PMは、「この作業、誰のためにやるんでしょうか…」とこぼしていたものです。（デヴィッド・グレーバー博士の“ブルシットジョブ —— クソどうでもいい仕事”が産み落とされた瞬間！） また、プロジェクトに重大な品質リスクが発生した際にも、「定期レビューに合格しているから問題はない」と判断され、現場の悲鳴は聞き流されたこともありました。形式的なレビュー手続きが、実態を覆い隠す盾となっていたのです。 私は、QA部門こそが、最も柔軟であるべきだと考えています。プロジェクトごとに状況を見極め、何が本当に必要なのかを見出す。それは、画一的な知識ではなく、経験と洞察と対話から生まれる対応力です。つまり、ここでも“イメージ力”が問われているのです。 QA部門が、ただ規格を押し付ける存在ではなく、「現場のパートナー」として機能するようになれば、品質文化は劇的に変わるはずです。そのためには、制度やチェックリストよりも、現場に寄り添う姿勢が求められます。 まとめ 言うまでもなく、われわれは、品質エンジニアのプロとして、お客様や、そこらのソフトウェア開発ベンダーが足元にも及ばないくらい、ソフトウェア品質に関しての専門的な知見を保有していなくてはいけません。しかし、品質とは、標準規格による単なる文書管理やレビュー手続きの整備ではありません。それに加え、現場に入り込み、プロジェクトの実像を“イメージ”し、必要な対応を的確に提案できることを併せ持つことが不可欠なのです。 品質を支えるのは、標準規格ではなく“人”です。だからこそ、QAエンジニアには、机上の知識だけでなく、現場を観察し、対話し、本質を見抜く力が求められます。私は、これからも“イメージ力”を更なる武器に、プロジェクトの実態に即した品質支援を続けていきたいと思います。 そしていつか、形式に縛られず、現場の声を真に受け止められるQA部門が、業界全体に広がっていくことを願っています。品質の本質は、形式ではなく、“想像と行動”の中にあると考えるからです。 ——しかし、いったんそんな風に結論付けてはみたものの、その理想郷を目指そうとする姿勢自体が、かつて紀元前の昔、世界最高の知性が独り言ちた、 “The more perfect a thing is, the harder it is to acquire.”（物事が完全であればあるほど、それを手に入れるのは困難である。）——　アリストテレス という、現代に至るまで、人間が性懲りもなく繰り返してきた“退屈な”取り組みそのものを、また繰り返し反芻してしまっていることにハタと思い至り、その結論の凡庸さに、我ながらいささかのうんざり感を覚えつつ、この場はいったん以上で筆を擱きたいと思います。 The post 品質はイメージ力で決まる —現場に寄り添うQAエンジニアの視点 first appeared on Sqripts .

こんにちは、セキュリティエンジニアの河村です。 今回はオライリー出版による｢ポートスキャナ 自作ではじめるペネトレーションテスト｣の書評をお届けします。本書はペネトレーションテストを初めとするセキュリティ業務では必須なツールと言えるポートスキャナについて、基本的な原理から説明してくれる内容です。 ■ ポートスキャナ自作ではじめるペネトレーションテスト―Linux環境で学ぶ攻撃者の思考 （株式会社ステラセキュリティ 小竹 泰一 著／O’REILLY JAPAN） ポートスキャナ自作ではじめるペネトレーションテスト 本書は、ポートスキャンを用いて攻撃者がネットワークを経由してどのように攻撃してくるのかを具体的な手法を交えて学び、攻撃手法を知ることでセキュリティレベルの向上を目指す書籍です。Scapyを用いてポートスキャナを自作し、ポートスキャンの仕組みや動作原理を... 　詳細はこちら　 www.oreilly.co.jp 本の概要 セキュリティエンジニアが通常、業務でツールを用いるときはsocketモジュールやnmapなどの高度なツールを用います。しかしながら、それらのツールは、多くの人にとって高度に自動化されてるが故に中身がブラックボックスな部分があります。また、特殊なパケットの再現を行いたい場合などでは再現が難しいことがあります。 本書ではサイバー攻撃が具体的に行われるプロセスを表したフレームワーク、Unified Kill Chainの解説から始まり、ScapyというPythonライブラリを通してパケットレベルでSynスキャンなどを体験できるプラットフォームを用意してくれています。第三章以降ではNmap、Nessus、Metasploitとペンテスターにとって基本となるツールの用い方を通して、ペンテスターにとって必要不可欠な攻撃の手順を体系的に学べます。 章ごとの概要 以下に、本書の各章で特に注目したい内容をピックアップしてご紹介します。 第一章 攻撃者はいかにしてシステムを攻撃するのか この章では攻撃者がシステムを侵害していく過程を具体的に学ぶことで、各種セキュリティ対策をより効率的に実施する方法を学びます。 攻撃者がシステムを侵害していく過程を学ぶことは、管理しているシステムの弱点を把握し、セキュリティ対策を効果的に実施する上で重要です。 本章では具体的な事例として2019年の7payが不正利用によりサービス停止となった事件 ※1 、2021年、徳島県の病院で発生したランサムウェアによる電子カルテが閲覧不能になった事件 ※2 、2009年から2010年の間にイランの核燃料施設を攻撃したStuxnet ※3 などが紹介されています。この中でもStuxnetの攻撃は特定の組織を狙って周到に準備した上で実行され、標的型攻撃と呼ばれます。 ※1 「7pay」決済サービス、開始早々の大量不正アクセス,5500万円の被害 ※2 徳島・鳴門の病院にサイバー攻撃　電子カルテにアクセスできず ※3 国家間サイバー戦争の幕開け　イラン核施設を攻撃したマルウェア「Stuxnet」（2009～10年） 標的型攻撃の中でも特に高度で持続的に行われるものはAPT(Advanced Persistent Threat)攻撃と呼ばれたりもします。 現在進行形で行われているウクライナでの戦争では現実世界の軍事行動と一体化したハイブリッド攻撃が行われています。このことからわかるように、サイバー攻撃を制す者が現実の戦いをも制す時代になっています。 サイバー攻撃の進行をスケーリングした指標として有名なものがMITRE ATT&CK ※4 やUnified Kill Chain ※5 です。本書ではUnified Kill Chainを用いて説明します。このフレームワークを学ぶことでサイバー攻撃の過程をより分析して捉えることが可能になります。 ※4  https://attack.mitre.org/ ※5  https://www.unifiedkillchain.com/ サイバー攻撃における最初の段階である｢初期の足場の確保｣から解説します。 初期の足場の確保(Initial Foothold) 流れ：偵察⇒武器化⇒配送⇒ソーシャルエンジニアリング⇒攻撃⇒永続化⇒防衛回避⇒コマンド＆コントロール 偵察 Reconnaissance 攻撃者は標的組織の情報を収集し、攻撃に活用出来る情報がないか調査します。この活動で用いる手法はOSINT(Open Source INTeligence)と呼ばれます。 この偵察フェーズは受動的偵察と能動的偵察の2種類に分類出来ます。受動的偵察は標的組織の組織にアクセスしないので、検知されるリスクが低いです。対して、DNS問い合わせ、Nmapなどのポートスキャン行為を行う能動的偵察は直接標的組織にアクセスするため、検知リスクがあります。Subdomain Takeover ※6 などの攻撃の実行可能性はこの段階でわかったりします。 ※6 Subdomain Takeoverについて   武器化 Weaponization 偵察によって得た情報をもとに攻撃に必要な環境を準備するフェーズです。標的組織の環境に合わせてマルウェアを作ることもこのフェーズに含まれます。対象組織がセキュリティ対策を適切に行ってる場合、攻撃に工夫が必要となります。 このような際に必要である検知回避技術にはLOTL攻撃(Living Off The Land攻撃)があります。標的の端末にすでにインストールされているソフトウェアを活用して攻撃を行うことで、検知を回避する手法です。GTFOBins ※7 などにはこのような攻撃を行うのに有用なコマンドが記載されています。 ※7 GTFOBins   配送 Delivery 武器化フェーズで作成したマルウェアを標的組織へ届けるフェーズです。攻撃者この手段として、メールやSNS、USBメモリなど様々な手段を用います。特に特徴的な手法として、 水飲み場型攻撃 サプライチェーン攻撃 があげられます。 ソーシャルエンジニアリング Social Engineering 配送したマルウェアを、メールやSNS等での人を通した会話によって、能動的に起動する手法をソーシャルエンジニアリングと呼びます。ときにはマルウェアの起動をスキップして、直接クレデンシャルを狙う場合もあります。｢スミッシング｣、｢スピアフィッシング｣などもソーシャルエンジニアリングにあたります。 攻撃 Exploitation 標的組織にマルウェアを能動的に実行させる方法は前述のソーシャルエンジニアリングの他に｢攻撃｣があります。例えば、標的にRCE（Remote Code Execution）の脆弱性があれば、それを用いてシステム内でマルウェアを実行させられます。 攻撃フェーズ以前からIPアドレスを偽造したり、SOCKS5プロキシ、Torネットワーク、VPNなどを用いて送信元を偽るケースも多いです。 永続化 Persistence 攻撃者は、システムへの持続的なアクセスの獲得を目的としている場合があり、この場合永続化フェーズが必要になります。永続化の手法として代表的なものに以下の三つがあげられます。 アカウントの操作⇒サーバへの公開鍵の追加など ブートまたはログオンの自動開始実行⇒Linuxでのrcコマンド、Windowsでのスタートアップなど スケジュールされたタスク/ジョブ⇒cronなど 防衛回避 Defense Evasion 攻撃者がセキュリティ製品に検知されないようにとる対策のことです。様々な手法がありますが、本書では5章でMetasploitを用いた防衛回避方法を解説します。 コマンド＆コントロール Command and Control ｢初期の足場の確保｣の最後のフェーズとして、マルウェアは攻撃者の用意したC2サーバ ※8 との通信を確立します。 これらのプロセスではドメインフロンティングやDNSトンネリングなどの隠蔽技術が用いられることがあります。 ※8 C2サーバとは   標的ネットワーク内での被害拡大 標的となるネットワークにアクセスした後、目的の資産を獲得する際の活動をUnified Kill Chainでは｢ネットワークを介した拡大｣(Network Propagation)と名付けています。 ネットワークを介した拡大フェーズは以下のようなプロセスで構成されています。 流れ：ピボッティング⇒探索⇒権限昇格⇒実行⇒クレデンシャルアクセス⇒横展開 ピボッティング Pivoting 攻撃者は必要に応じて侵害した端末を通じて、直接アクセス出来なかった他のネットワークへ通信をトンネリングし、これをピボッティングといいます。横展開と異なり端末間の移動のみをUnified Kill Chainではピボッティングとしてます。 探索 Discovery 攻撃者が現在ログインしているシステムとそのシステムが接続している内部ネットワークに関する情報を得るために行う活動を探索と言います。検知されないようにPowerShell等、OSにデフォルトで備わってるツールが多用されます。 権限昇格 Privilege Escalation 取得出来た権限が制限されたものだった場合、脆弱性を利用してより高いレベルの権限への昇格を試みます。この活動を権限昇格と呼びます。 実行 Execution コードを実行するのに必要な権限を得た攻撃者は攻撃を実行します。 クレデンシャルアクセス 攻撃者は目的に応じて、クレデンシャルを盗み出そうとします。この活動をクレデンシャルアクセスと呼びます。 ⇒ わざわざ侵入行為を働かなくても、GitHubなどで公開されてるリポジトリから機微な情報を取得出来る場合もあります。 横展開 Lateral Movement 侵入した端末から、同一ネットワーク内の他の端末の権限の取得を試みます。 目的の実行 （Action on Objectives) ここまでのプロセスで攻撃者は標的のネットワークへの足場を広げ、多大な被害を拡大できました。このあと、入手できたデータを収集し、持ち出していきます。 流れ：収穫⇒持ち出し⇒影響⇒目的 収穫 Collection 攻撃者は目的に応じて標的からデータを収集します。システム内のデータ以外にSamba、クラウドストレージから収集したり、キーロガー、Webカメラなどを用いる場合もあります。 持ち出し Exfiltration 目的達成のために収集されたデータを持ち出します。検知回避のためにデータを圧縮・暗号化することも多いです。IDS・IPS回避のための工夫も行われます。この際以下の技術が用いられます。 Smash&Grab Low&Slow 影響 Impact 攻撃者が標的のビジネスプロセスや運用プロセスを操作することで、その可用性や完全性を損なわせる活動です。 目的 Objectives 攻撃者の社会的・技術的な最終目標のことです。以下に例をあげます。 知的財産（ソースコードなど）の奪取 奪取したアカウントの販売 ランサムウェアによる身代金の獲得 第二章 Scapyでポートスキャナを自作して動作原理を知ろう ポートスキャナは前章のUnified Kill Chainの中では｢初期の足場の確保｣の｢偵察｣にあたる行為です。この章ではポートスキャナを｢Scapy ※9 ｣というライブラリを用いて自作することを通して、パケットの操作方法を学んでいき、実在する脆弱性に対する攻撃も体験します。 ※9 https://scapy.net/ 実際の業務では基本的にポートスキャナはNmapで十分なのですが、ポートスキャナの仕組みを理解するには自作することは非常に有用です。このようなことを学ぶとセキュリティエンジニアにとって必要なPoCのコードの実装を素早くできたりします。 環境構築の細かいことについては本書を読んで欲しいです。また、ここに掲載してるソースコードは本文が冗長にならないよう概要のみなので、そのままでは動作しないものがあることはご了承ください。更に、外部に対してこれらのコードを実行することは法に抵触する可能性があるため、必ず自分の管理下のネットワークで試してください。 ここでは大まかな流れと概要を伝えます。本書の実習環境は、Docker ※10 を用いており、Scapyが使えるコンテナと各種脆弱性を持ってるコンテナが用意されております。 ※10 コンテナの基本   本書はDockerの知識がない方でも環境を十分に扱えるよう基本レベルからDockerの解説が載っているので安心です。また、Dockerの性質上、Windows、Mac、Linuxのどれでも検証環境は動作します。 Scapyに入門する Scapy は、Pythonでネットワークパケットを操作するための強力なライブラリです。パケットの生成、送信、解析、操作などを簡単に実現でき、ネットワークテストやセキュリティ分析に広く利用されています。使用仕方として、Pythonから呼び出す方法と、インタプリタから使用する方法があります。 Pythonコードから使用する方法 from scapy.all import srl, IP, ICMP のような形で必要な関数、クラスをインポートしてします。 インタプリタから使用する方法 scapyを使用できる環境のコマンドラインから以下のコマンドを押下します（Linux、Macの場合）。 $ sudo scapy インタプリタを終了する場合、exitと入力します。 パケットの送受信 ICMPを題材としたパケットの送受信が紹介されています。インタプリタ版の場合、以下のようにしてICMPパケットを作成します。 >>> req = IP(dst="10.8.9.3")/ICMP() >>> req.show() scapyの基本的な使い方は本書を実際に読むか、もしくは下記などを参考にしてください。 ※11 Scapy入門　 https://qiita.com/Howtoplay/items/4080752d0d8c7a9ef2aa パケットキャプチャを行う Scapyのsniff関数を用いるとパケットキャプチャが容易に実装できます。以下のようなコードを用います（詳細は本書P.50）。 from scapy.all import sniff def print_packet(packet):   packet.show() sniff(filter='icmp', prn=print_packet, count=5) このPythonスクリプトを実行するとICMPパケットを待ち受けます。 TCP SYNスキャンをScapyで行う SYNスキャンは、TCP 3ウェイハンドシェイクの特性を利用します。以下はその流れです。 3ウェイハンドシェイクの流れ SYNパケット送信 スキャナーがターゲットにTCP SYNパケットを送信します。 応答の受信 SYN/ACK : ポートが「オープン」の場合。 RST : ポートが「クローズ」の場合。 応答なし: ポートが「フィルタリング」（ファイアウォールでブロック）されている場合。 接続の中断 スキャナーは応答を受け取ると、接続を完了せずにRSTパケットを送信して接続を終了します。 SYNスキャンは接続を完全に確立しないため、高速で実行でき、ログに残りにくく比較的検出されづらいことが特徴です。 Scapyにおいては syn_packet = IP(dst=dst_p)/TCP(dport=target_port, flags='S') # SYNパケットの作成 response_packet = srl(syn_packet) # パケットを送信する のように記述することで、SYNパケットオブジェクトを作成出来ます。 これでSYNパケットを送信した後にSYN/ACKパケットが返ってくるかを判別するコードを追加すると、ポートが開いてるか判断出来ます。 if(response_packet.haslayer(TCP) and   response_packet[TCP].flags == "SA"):   print(f"TCP port {target_port} is open") else:   print(f"TCP port {target_port} is closed") TCP ConnectスキャンをScapyで行う TCP Connectスキャンでは3ウェイハンドシェイクを最後まで行うので、SYNスキャンのときのコードにTCPの接続を正常に終了するためのFINパケットの送受信のコードも書き加えます。 3ウェイハンドシェイクを完了するにはシーケンス番号や確認応答番号の設定が必要です。Pythonを用いたら容易に実装できます。 パケットの確認 tcpdumpを使います。 $ sudo tcpdump port <port> and host <ip> socketモジュールを使って実装する より高性能なsocketモジュールならばTCP Connectスキャンの3ウェイハンドシェイクをより簡単に実装できます。 s = socket.socket() errno = s.connect_ex((target_ip, target_port)) # これでTCP Connectを試みます s.close() 特殊なパケットやパケット単位の実装はScapyが便利ですが、それ以外の場合はsocketモジュールが便利だったります。 パケットを工作しないと攻撃出来ない脆弱性 以下の脆弱性の学習にはパケット単位でカスタマイズ可能なsocketモジュールのカスタマイズ性の高さがいきてきます。 ARPスプーフィング ARPスプーフィング（ARP Spoofing）は、コンピュータネットワークにおける攻撃手法の一つで、偽のARP（Address Resolution Protocol）メッセージを送信して、通信を傍受したり改ざんしたりする攻撃です。 この攻撃を行う上で、ARP要求を送信し、偽のARP応答を送りつけてキャッシュを改ざんします。偽のARPパケットはScapyでは以下のようにして送信できます。 arp_response = ARP(pdst=target_ip, hwdst=target_mac, psrc=dest_ip, op='is-at') send(arp_response) scapyモジュールのARPクラスでは以上のように、容易に改ざんされたARPパケットを作れます。 DoSを引き起こすCVE-2020-8617 CVE-2020-8617 は、BIND（Berkeley Internet Name Domain）に関連する重大な脆弱性です。BINDは最も広く使用されているDNSサーバーソフトウェアの一つで、この脆弱性を悪用されると、リモートの攻撃者がサービス拒否（DoS）攻撃を引き起こす可能性があります。 この脆弱性では細工されたTSIGリソースレコードを含むリクエストを用います。発見者はPython上でバイト列を組み立て、Socketモジュールで送信していますが、Scapyを用いるともっとシンプルに記述出来ます。 DNSRRTSIG(rrname="local-ddns", algo_name="hmac-sha256", rclass=255, mac_len=0, ac_data="", time_signed=0, fudge=300, error=16) 以上のコードの断片がペイロードの一部です。 第三章 デファクトスタンダードのポートスキャナNmap Nmap ※11 の基本的な使い方は以下のような様々なソースで確認出来るので省略します。 ※11  https://qiita.com/kenryo/items/1b49bddce44e9412638f Nmapの機能を拡張するNSE NmapにはスクリプトエンジンであるNSE(Nmap Scriting Engine) ※12 上で動くLua製スクリプトが付属してます。これらを使うことで、コマンド一つでブルートフォース攻撃などを行えます。 ※12 NSEの使い方の参考   NSEの使用例：ミドルウェアへのログイン試行を行うスクリプト $ nmap -p 22 --script ssh-brute 127.0.0.1 有名な脆弱性であるHeartbleedやPOODLE、EternalBlueなどをNSEで調査することも出来ます。 $ nmap -p 443 --script ssl-heartbleed example.com 第四章 既知脆弱性を発見できるネットワークスキャナ Nessus Nessus ※13 の基本的な使い方は以下のような様々なソースから確認出来るので省略します。 ※13  https://qiita.com/mefuku/items/d22a2747bcdb6ff19d75 ネットワークスキャナには他のものもたくさんあります。例として、CloudflareによるFlan Scan、GoogleによるTsunamiなどがあります。 Nmapとの使い分け NessusのBasic Network ScanやAdvanced Scanでは脆弱性をスキャンする前段階でポートスキャンを行います。ただし、出力結果がNmapとは異なったていたりするので、使い分けとして、網羅性を重視するセキュリティベンダの場合、NessusとNmapを併用して両方の差分を確認する場合したりします。 第五章 攻撃コードを簡単に生成できるMetasploit Framework MetasploitはRapid7社が開発してるペネトレーションテストツールです。無料版はCUIでしか基本的に使えませんが、有料版のMetasploit ProはGUIで操作できます。 Metasploitの基本的な使い方は以下のような様々なソースから確認出来るので省略します。 ※14  https://zenn.dev/sanflat/articles/6c9b007c787035 第六章 攻撃者はどのように被害を拡大するか Unified Kill ChainにおけるPost-Exploitationで行う行動をここでは解説しています。 ファイル読み込みを成功させたあと 標的端末のファイル読み込みが出来ただけでは、RCEが出来た場合と比べて出来ることが限られています。そこでまず、端末内の多数の重要なファイルを｢収集｣します。｢収集｣ファイルを元に、次のステップであるファイル書き込みに向けての権限昇格を目指します。 ファイル書き込みを成功させたあと RCEへの発展や、マルウェアの書き込みを目指します。Unified Kill Chainでは｢初期の足場の確保｣の｢永続化｣にあたります。 以下が具体的に行うことの例です： ・Webシェルの配置 ・SSH公開鍵の配置 ・cronを用いた永続化と権限昇格 RCEを成功させたあと RCEを成功させたということは、任意のコマンドが実行可能です。このフェーズで行いたいことを列挙します。 コンテナエスケープ ⇒既知脆弱性の利用、Dockerソケットがマウントされてる場合、特権コンテナ マルウェアの実行 ⇒Vimプラグインによるキーロガー ⇒LD_PRELOADによる関数フック C2フレームワークによる侵害した端末の管理 C2フレームワークは侵害した端末を遠隔操作するためのツールです。目的達成には侵略した端末をまとめて操ることが必要だったりするので、攻撃において有用な場合が多いです。 OSSのC2フレームワーク： 　⇒Covenant、C3、Empire、PoshC2、Sliverなど 商用のC2フレームワーク： 　⇒Brute Ratel C4、Cobalt Strikeなど DBにアクセス出来たら DBには重要な情報が格納されてることが多いため、DBにアクセスできる事は目的達成において重要です。 DB内の情報の閲覧 ファイル読み込み ファイル書き込み RCEを行う ⇒ PostgreSQLのCOPYコマンドなど どのようにして他の端末へ被害を拡大させるか ここまでのフェーズで目的を達成できなかった場合、組織が管理しているネットワーク上の他の端末への攻撃を試みます。その方法の例をあげます。 メモリからのクレデンシャルの抽出 既存のセッションの活用 ⇒ ControlMasterによって既存のSSH接続を活用するなど ⇒ 二回目以降のSSH接続ではPWの入力が不要な場合がある 認証情報が弱いサーバや既知脆弱性が存在する端末への攻撃 ⇒後者はスキャナで発見できることがある 本書を読んで 第一章で学ぶUnified Kill Chainはペネトレーションテストのフレームワークとしてはかなり詳細な部類です。これの各フェーズを日本語で丁寧に解説してる文書はインターネット上には少なく、なので本書の解説は貴重で有用だと思いました。ペンテスター向けのフレームワークですが、セキュリティエンジニアは皆サイバー攻撃と何らかの形で関わり、このフレームワークを知ることでサイバー攻撃についての理解が非常に深まると思います。 第二章でのScapyを用いた自作のポートスキャナの章は本書の目玉といえると思います。本書を読む人で3ウェイハンドシェイクを知らないって方はあまりいないと思いますが、実際にパケット単位で操作できる実行環境を作った人は少ないと思います。Socketモジュール等の一般的なモジュールでは、Synスキャンのような基本的なハッキング技術でさえ再現が意外とめんどくさく、比較的低レイヤーの操作が可能なツールScapyの有用性を感じました。私自身も今後より高度なレベルのScapyの使用法を学び、仕事でのPoC作りなどに活かしたいと思いました。 第三章から第五章の内容は非常にメジャーなツールの入門的な使い方なので今回はほとんど省略しましたが、ペンテスト系の学習をしたことがないセキュリティエンジニアにとっては網羅的に学ぶ上でいい教材だと思いました。これらを学習すればハッキングの登竜門であるHack The Boxなどにも挑みやすくなると思います。 第六章は、第二章から第五章までのツールを用いて標的端末へアクセス出来たあとの手順が第一章に登場したUnified Kill Chainフレームワークに基づいて記載されており、非常にためになります。Hack The Box等では端末のルートを取れたら終わりだったりしますが、現実のハッキングでは違います。機密情報の取得だったり、DoSの達成と言った目標達成にはルートの取得後の端末間の垂直・平行移動や情報収集が必要だったりします。 本書は取り扱ってる内容はペンテスト全域に渡っており、ボリュームはかなりありますが、要求レベル的にはLinux（できればPythonも）の基本がわかってれば十分に読める内容だとも思いました。ポートスキャナの原理に限らず、ペンテスターが用いるツールについて学びたい人は是非一読をお勧めいたします。 The post 『ポートスキャナ自作ではじめるペネトレーションテスト』書評 first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 ＜実務三年目からの発見力と仮説力　記事一覧＞ ※クリックで開きます 【第1回】見つけるための論理【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる 今回は仮説を考える時の進め方の解説です。 仮説は拙速を貴ぶ――とは限らない コニャンくんがソフトウェアXで起こる故障F( 第3回 など参照)の原因について考えを巡らせています(図7-1)。 図7-1 よい仮説を求めて アブダクションは杖ひと振りでよい仮説を手にする魔法ではありませんし、そもそもよい仮説がすぐに見つかることは稀です。 アブダクションの進め方・パースの「ふたつの段階」 ホップ、ステップ、よい仮説 パース（ 第6回参照 ）は、仮説はふたつの段階を経て形成されるとしています。 （参考： 『アブダクション　仮説と発見の論理』 。以降『アブダクション』） 第1段階：心に思い浮かぶ仮説を列挙する 第2段階：最も正しいと思われる仮説を選ぶ 図7-2 アブダクションのふたつの段階 第1段階 では、対象について考えを巡らせ、判っていることや調べたことをもとに、説明仮説を考えていきます。 この段階で素晴らしい仮説を思いつくかも知れません。 しかしそこで決めてしまうのでなく、事象を説明できる仮説は他にも考えられないか、検討します。 （思いつきがイマイチならなおさらです） 時にはいわゆる閃きや天啓といったものの助けもありますが、それが降りてくるよう、対象を詳しく調べたり理解を深めたりしながら考えることが大切です。 『アブダクション』では 洞察的な段階 とも言っています。 第2段階 では、第1段階で挙がった仮説を、後述の4つの基準で総合的に評価し、最も理にかなっていると思われるものを選定します。 『アブダクション』では 熟考的な段階 とも言っています。 「最も正しいと思われる仮説」の選定基準/条件 「最も正しいと思われる仮説」の選定の基準ないし条件として、パースは次の4つを挙げています。 （参考： 『アブダクション』 ） (1) もっともらしさ(plausibility) 問題となっている事象や因果関係について、理にかなった説明を与えるものであること。 (2) 検証可能性(verifiability) 仮説は事実に照らして検証可能（真偽を判断できる）であること。 反証可能であること（偽であると判定できること）も含みます。 (3) 単純性(simplicity) (1), (2)が同程度の仮説が複数ある場合は、より単純な仮説であること。 (4) 経済性(economy) 仮説の検証にかかる思考の努力や、時間やコストが少なくて済むこと。 総合的に見て「最も理にかなっている」と思えるものを選定します。 これらの基準は、第6回で挙げた 「よい仮説」が持つ性質 に対応します。 （「検証」の意味も第6回に準じます） 図7-3 「よい仮説」の判定基準と、「よい仮説」が持つべき性質 なお、パースのいう 単純性 は、論理的な単純さ（原因から結果まで一本道/短い、過程が入り組んでいない、etc.）よりは「説明が自然で考えやすい」「受け容れやすい」といった“自然さ”を意味しています。 また、 経済性 は第6回で挙げた仮説の性質の4番目とは若干異なりますが、「少数の仮定から整合的に説明できる」ならパースのいう経済性の条件にかなうと言えるでしょう。 念のため 「最も理にかなった仮説」が選ばれたとしても、 それはまだ仮説 です。 仮説が事実に対して正しい（不整合がなく、過程や結果をよく説明している）かどうかは、その後の検証（ソフトウェアの場合、最終的には動的テストなど）に委ねられます。 「ふたつの段階」の取り組み方 二重ループでイテレーティブに 筆者の経験を交えると、次のように考えると取組みやすいでしょう。 第1段階で「仮説を列挙する」際には： 考えやすいところから手をつける。 「説明仮説にはならない」ものを早めに排除して考える範囲を絞るのも大事。 思いついた段階でざっと検証してみる。 現象や結果を説明できるか、ざっと確かめる( 粗い検証 ）。 よさそうなら残す。 そうでなければ脇に置いておく。 （忘れ去る必要はなくて、後で修正を施されて“敗者復活”してもよい） これを繰り返す（いわば「 内側のループ 、 小ループ 」）。 最初の仮説で終わらず、「粗い検証」で得たフィードバックも加味して次の仮説を考える。 ある程度考えられた（もう思いつかない）と判断できたら終了する。 第2段階で「最も正しいと思われる仮説を選ぶ」際には： 「1回目の第2段階」で「最も正しいと思われる仮説」が決まらなくてもよい。 （詳しく考えてみると、細部に説明できないことがある場合や、必ずそうなるとは言えない場合もある） そういう場合はもう一度「第1段階」からやる（いわば「 外側のループ 、 大ループ 」）。 図7-4 アブダクションのふたつの段階・変形版 第1段階で心がけたいこと ①原因候補と説明仮説をさまざまな視点・見方から考えてみる。 原因候補が結果(故障や不具合)を引き起こす筋道を、多角的に考えましょう。 図7-1のように、途中で道が塞がっていても、別の道が見つかるかも知れません。 人的要因やプロセス要因の可能性を含めて考えるのがよい場合もあります（作業や確認の漏れ、単純ミス、勘違い、etc.）。 原因候補から結果までの筋道(可能性としての)が一本か、複数あり得るか考えられると、仮説の確からしさを強化できるでしょう。 原因候補を絞り込みたい場合には、差異法や剰余法の考え方が参考になります（ 第3回参照 ）。 ②大きな“瑕”がある仮説は躊躇なくいったん脇によけておく。 魅力ある原因候補でも、結果に至る筋道を説明しきれない、仮説の通りにならない場合がある、 といった目につく“瑕”があるなら、いったん脇に追いやって別の仮説を考えてみるのがよいです。 いわば「幅優先の探索」です。 原因の候補がいくつも考えられる状況なら、候補から外してよいものと、残しておくものを仕分けるためにも「幅優先」で考えた方がよいでしょう。 幅優先に対して「深さ優先の探索」をしたくなる場合もあります。 “瑕”がなければ最有力になるような原因候補なら、“瑕”をなくせないか時間をかけて考えてみるのもありでしょう。 「粗い検証」 は、①②を柔軟に行なうことを促します。 第1段階の「粗い検証」 机上（ひとり脳内ウォークスルーで可）でよいので、「仮説Hが正しいならば、Cという結果になる」かどうか、先の4つの選定基準/条件をざっと評価します。 大雑把なウォークスルーでも もっともらしさ や 検証可能性 を損ねるような大きな“瑕”が見つかるなら、綿密に検証してみるまでもありません。 また、第1段階で仮説による説明の 単純さ 、 判りやすさ がある程度把握できていれば、第2段階が捗ります。 アイデアを見失わないように ただでさえアイデアは思いついたそばから消えていってしまうものですから、「原因から結果に至る見えない道筋を、結果から遡って考える」作業を頭の中だけで完結させるのは困難です。 思い浮かんだ考えや仮説案は忘れずに書き留めましょう。 考える過程を書き留めること自体が重要ですし、形に表すことで考えがはっきりすることもあります。 （“見込みあり”と光明が差すこともあれば、足りていないところ・弱いところが判明することも） ということで、次回は「アブダクションを支援するのに使える“ツール”」をいくつか紹介する予定です（特定のプロダクトではありません）。 参考文献 米盛裕二 『アブダクション　仮説と発見の論理』 勁草書房 2007 パース(著), 伊藤邦武(訳) 『連続性の哲学』 岩波書店 2001 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 図版に使用した画像の出典 Loose Drawing 人物画、電球の絵をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. 【連載】ソフトウェアエンジニアのための論理スキル［実務三年目からの発見力と仮説力］ 記事一覧 【第1回】見つけるための論理 【連載初回、全文公開中】 【第2回】 “共通項”を見つけ出す 【第3回】発見はよい観察とよい方法から 【第4回】帰納の仲間と落とし穴 -前編- 【第5回】帰納の仲間と落とし穴 -後編- 【第6回】 なぜ・どのようにを説明したい 【第7回】 仮説の糸を手繰り寄せる The post 【第7回】 仮説の糸を手繰り寄せる｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

こんにちは！フロントエンドエンジニアのつかじです。 皆さんは日々の開発の中でテスト自動化に取り組んでいますか？手動での繰り返しテストは時間がかかり、ヒューマンエラーも発生しがちです。そこで今回は、JavaScriptベースのE2Eテストフレームワーク「CodeceptJS」をご紹介します。シンプルな記述でありながら、強力な自動テストを実現できるツールです。 CodeceptJSとは？ CodeceptJS は、エンドツーエンド（E2E）テストをシンプルに記述できるテストフレームワークです。 主な特徴は以下の通りです。 直感的なDSL記述 自然言語に近いDSL（ドメイン固有言語）を採用しており、テストコードが読みやすく、出力結果も直感的に理解しやすいです このシンプルな記述方法は、BDD（振る舞い駆動開発）の文脈で、テストの意図を明確に伝え、保守性の向上にも寄与します 複数のヘルパーへの対応 Puppeteer、Playwright、WebDriver、TestCafe など、さまざまなブラウザ操作ライブラリをヘルパーとしてサポート ヘルパーを切り替えるだけで、同一のテストコードを異なるバックエンドで実行可能なため、プロジェクトの要件に合わせた柔軟な運用が実現できます 複数ブラウザでのテスト実行 Chromium、Firefox、WebKit など、複数のブラウザ上でテストを実行でき、クロスブラウザテストが容易に行えます エコシステムの充実 豊富なプラグイン群（スクリーンショット自動取得、レポート生成、リトライ機能、データ駆動テストなど）により、様々なニーズに対応可能 カスタムヘルパーやプラグインを自作することも容易で、コミュニティによるサポートも充実しています APIテストへの対応 HTTPリクエストの送信やレスポンスの検証を行うためのAPIヘルパーが用意されており、Webアプリケーションだけでなく、APIテストもシンプルに記述できます モバイルテスト（Appium利用）への対応 Appiumを利用することで、CodeceptJSからモバイルアプリケーションのテストも可能です 同一のDSLで、WebだけでなくモバイルのUIテストも統一的に記述できるため、テスト環境の統合が容易です 他ツールとの比較 Cypress 高速で自動ウェイト機能が強力ですが、対応ブラウザが限定的です。一方、CodeceptJSは複数のドライバーに対応しており、柔軟なテスト環境を提供します。 Selenium ほぼ全てのブラウザに対応する実績がありますが、APIが冗長でテストコードが複雑になりがちです。CodeceptJSは抽象化レイヤーを提供することで、シンプルな記述を可能にします。 Robot Framework 非エンジニアでも扱いやすいキーワード駆動型ですが、JavaScript環境との統合が難しいという点があります。 Playwright/Puppeteer 低レベルのAPIで柔軟な自動化が可能ですが、テスト全体を構築する際に記述量が増えがちです。CodeceptJSはこれらをヘルパーとして統合し、BDDスタイルの簡潔な記述を実現します。 WebdriverIO 柔軟性が高く、多くのプラグインや拡張機能が利用可能ですが、設定が複雑になりがちです。また、BDDスタイルの記述を行うには追加のプラグイン導入が必要な場合があります。 TestCafe インストールや設定が非常にシンプルで、Seleniumを必要としません。自動待機機能が組み込まれており、非同期処理が扱いやすいですが、細かいカスタマイズや多様なブラウザサポートには制限がある場合があります。 Gauge + Taiko Gaugeはシナリオ記述に重点を置いたフレームワークで、Taikoはシンプルな構文でブラウザ操作を実現します。非常にシンプルな記述が可能ですが、CodeceptJSのような豊富なプラグインや柔軟なヘルパーの選択肢は少ないです。 Nightwatch.js Selenium/WebDriverを利用した標準的なE2Eテストフレームワークとして実績がありますが、設定が煩雑になりがちで、BDDスタイルの記述を実現するには追加の工夫が必要です。一方、CodeceptJSは複数のヘルパーをサポートし、シンプルなAPIで記述できる点で差別化できます。 各ツールともに独自の強みがあるが、CodeceptJSはDSLの記述のシンプルさ、多様なヘルパー対応、豊富なプラグインエコシステム、さらにはAPIテストやモバイルテストまでカバーできる点で、非常にバランスの取れたテスト自動化フレームワークと言えます。 CodeceptJSのインストールとセットアップ 必要な環境 Node.js（バージョン12以上） ※ 執筆時（2025/04/03）時点での CodeceptJS 最新バージョン：3.7.3 インストール CodeceptJSは、インストーラーを使用する方法が最も簡単で推奨されています。以下の手順で簡単にセットアップできます： # 新しいディレクトリを作成してインストール mkdir codeceptjs-demo cd codeceptjs-demo npx create-codeceptjs . 特定のディレクトリにインストールする場合は、以下のようにディレクトリ名を指定できます： npx create-codeceptjs e2e-tests デフォルトではPlaywrightがインストールされますが、他のテストエンジンを使用したい場合は、以下のようにオプションを指定できます： # Puppeteerを使用する場合 npx create-codeceptjs . --puppeteer # WebDriverIOを使用する場合 npx create-codeceptjs . --webdriverio その他のインストール方法や詳細な設定については、 公式マニュアル をご参照ください。 セットアップ インストール完了後、以下のコマンドでCodeceptJSのセットアップを行います： npx codeceptjs init 対話形式で以下の設定を行います(本記事のセットアップ内容。テスト対象の機能名以外はデフォルト値です。)： # TypeScriptを使用するか? ? Do you plan to write tests in TypeScript? -> No # テストファイルの配置場所 ? Where are your tests located? -> ./*_test.js # 使用するヘルパー（テストエンジン）の選択 ? What helpers do you want to use? -> Playwright # テスト実行時の出力ディレクトリ（スクリーンショットやレポートの保存先） ? Where should logs, screenshots, and reports to be stored? -> ./output # テストの言語設定 ? Do you want to enable localization for tests? <http://bit.ly/3GNUBbh> -> English (no localization) # Playwrightの設定：使用するブラウザの選択 ? [Playwright] Browser in which testing will be performed. Possible options: chromium, firefox, webkit or electron -> chromium # テスト対象のベースURL ? [Playwright] Base url of site to be tested -> <http://localhost> # ブラウザウィンドウを表示するかどうか ? [Playwright] Show browser window -> Yes # テスト対象の機能名（今回は予約機能をテスト） ? Feature which is being tested (ex: account, login, etc) -> reservation # 作成するテストファイルの名前 ? Filename of a test -> reservation_test.js 基本的なテストの作成｜CodeceptJS ここでは、日本Seleniumユーザーコミュニティが提供しているデモサイト「予約情報入力」にアクセスして簡単な操作をテストします。 今回は以下のケースを記述します。 トップページを開く 入力フォームに日付、宿泊人数、名前などを入力 「利用規約に同意して次へ」をクリック後、予約内容を確認 「確定」をクリック後、予約完了を確認 ※ デモサイトは現時点で利用可能ですが、将来的にURLが変更される可能性があります。 テストファイル作成 reservation_test.js へ以下のようなテストコードを作成します。 Feature('reservation'); Scenario('宿泊予約ができることを確認する', ({ I }) => { // 1. トップページへ遷移 I.amOnPage('<http://example.selenium.jp/reserveApp_Renewal/>'); // 2. 入力フォームに日付, 宿泊人数, 名前などを入力 // 日付を選択（例: 2025/05/01） ※ 翌日以降3ヶ月以内の日付を指定 I.fillField('#datePick', '2025/05/01'); // 宿泊日を入力（例: 3日） I.selectOption('#reserve_term', '3'); // 人数を入力（例: 2人） I.selectOption('#headcount', '2'); // 名前を入力（例: 山田太郎） I.fillField('#guestname', '山田太郎'); // 3. 「利用規約に同意して次へ」をクリック I.click('利用規約に同意して次へ'); I.see('予約内容'); I.see('2025年5月1日'); I.see('3泊'); I.see('2名'); I.see('山田太郎'); // 4. 「確定」をクリック I.click('確定'); I.see('予約を完了しました'); I.see('ご来館、心よりお待ちしております。'); }); ポイント: CodeceptJSでは、Scenarioの第2引数に{ I }を受け取ることでブラウザ操作APIを利用できます .amOnPage() でページを開き、.fillField() や .checkOption() などでフォーム操作を行います I.see() によってページ上に特定の文字列が存在するかをテストできます I.see() のシンプルな記述方法は、ユーザー視点でページに表示されるテキストの存在をシンプルに確認できるため、テストコードの保守性と可読性を向上させ、BDDの振る舞い記述と非常に相性が良いです。テストの目的に応じて、単にテキストの存在を確認するだけの場合は I.see() を使用し、特定のエリアや要素内でのテキストの存在確認など、より厳密な検証が必要な場合にはセレクタなどを追加するのが望ましいです。 例: // ページ上のどこかに「ログイン成功」が存在すればOK I.see('ログイン成功'); // ヘッダー部分に「ログイン成功」が表示されているかを検証する場合 I.see('ログイン成功', '.header'); テストの実行｜CodeceptJS ターミナル上で次のコマンドを実行します。 npx codeceptjs run --steps -stepsオプション: テストの各ステップ（I.fillFieldなど）をコンソールに詳細表示します。 実行結果: CodeceptJS v3.7.3 #StandWithUkraine Using test root "path-to-your-project" reservation -- 宿泊予約ができることを確認する Scenario() I am on page "<http://example.selenium.jp/reserveApp_Renewal/>" I fill field "#datePick", "2025/05/01" I select option "#reserve_term", "3" I select option "#headcount", "2" I fill field "#guestname", "山田太郎" I click "利用規約に同意して次へ" I see "予約内容" I see "2025年5月1日" I see "3泊" I see "2名" I see "山田太郎" I click "確定" I see "予約を完了しました" I see "ご来館、心よりお待ちしております。" ✔ OK in 2197ms OK | 1 passed // 3s 上記のように「OK」と表示されればテスト成功です。もし失敗すると、該当ステップでエラーが表示され、スクリーンショットも自動保存されます（デフォルトでoutputフォルダ内）。 また、言語設定で日本語に設定している場合は、下記のような実行結果になります。(日本語でのテスト記述も可能) CodeceptJS v3.7.3 #StandWithUkraine Using test root "path-to-your-project" reservation -- 宿泊予約ができることを確認する Scenario() 私は ページを移動する "<http://example.selenium.jp/reserveApp_Renewal/>" 私は フィールドに入力する "#datePick", "2025/05/01" 私は オプションを選ぶ "#reserve_term", "3" 私は オプションを選ぶ "#headcount", "2" 私は フィールドに入力する "#guestname", "山田太郎" 私は クリックする "利用規約に同意して次へ" 私は テキストがあることを確認する "予約内容" 私は テキストがあることを確認する "2025年5月1日" 私は テキストがあることを確認する "3泊" 私は テキストがあることを確認する "2名" 私は テキストがあることを確認する "山田太郎" 私は クリックする "確定" 私は テキストがあることを確認する "予約を完了しました" 私は テキストがあることを確認する "ご来館、心よりお待ちしております。" ✔ OK in 1444ms CodeceptJSと他のツールとの連携について CodeceptJSは複数のブラウザ制御エンジン（ヘルパー）に対応しており、以下のように設定を変更するだけでテストが動作します。 Playwright（今回使用） Puppeteer WebDriver TestCafe codecept.conf.jsファイルの中でヘルパーを指定する部分があります。たとえばPlaywrightの場合は以下のようになります。 helpers: { Playwright: { url: '<http://example.selenium.jp/reserveApp_Renewal/>', show: true, browser: 'chromium' } } browserを切り替えるとFirefoxやSafari相当でもテスト可能です。 また、他のプロダクトと連携したい場合（Allureレポート、BDDツールなど）のプラグインも充実しています。 おわりに デモサイトを使った簡単なテストを書くことで、CodeceptJSの導入からE2Eテストの実行までの流れを理解していただけたかと思います。シンプルな記述で強力なE2Eテストが実現できるCodeceptJSは、テスト自動化の強い味方となるでしょう。ぜひ本記事を参考に、あなたのプロジェクトでもCodeceptJSを導入・活用してみてください。 また、今後はAIを活用したテストコードについても解説したいと考えています。CodeceptJSは公式にAI連携機能を提供しており、ChatGPTなどの生成AIを活用したテストコードの自動生成や、自然言語での指示によるテスト作成が可能です。さらに、テスト失敗時の原因分析やテストケースの提案など、AIの力でテスト自動化をさらに効率化できます。CodeceptJSのAI機能を活用すれば、テストコードの品質向上と開発時間の短縮を同時に実現できるでしょう。 The post テスト自動化の決定版！CodeceptJSで実現するメンテナブルなE2Eテスト first appeared on Sqripts .