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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

皆様こんにちは、ハヤシです。 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 .