こんにちは、バックエンドエンジニアのまさです。 AI技術の急速な進化に伴い、従来のキーワード検索では対応できない「意味的な類似性」に基づく検索ニーズが急増しています。本記事では、 オープンソースRDBMSであるPostgreSQLにpgvector拡張を組み込むだけで、簡単にベクトル検索システムを構築する方法 を解説します。 ベクトル検索 とは、文章を数値ベクトルに変換して抽象的な意味を検索する技術であり、キーワード依存型の検索では捉えきれない「ユーザーが本当に求めている意図」を、 高い精度 で汲み取れる検索手法です。 この記事では、ベクトル検索をPostgreSQLに組み込む方法を、ハンズオン形式で環境構築を進めながら説明していきます。 ベクトル検索とは 3分で分かるベクトル検索の仕組み 従来のキーワード検索は、文字通りキーワードが一致するかどうかで検索結果を返します。しかし、言葉の表現は多様であり、ユーザーの意図と完全に一致するキーワードが使われるとは限りません。そこで登場するのが ベクトル検索 です。 ベクトル検索は、テキストや画像などのデータを、数値の集まりである ベクトル に変換します。このベクトルは、元のデータの意味的な特徴を捉えており、類似した意味を持つデータは、ベクトル空間上で近い位置に配置されます。 具体的な仕組み: エンベディング:  テキスト（質問や文章）を、事前に学習済みのAIモデル（例：OpenAIのtext-embedding-ada-002）を用いて、数値ベクトルに変換します。この処理をエンベディングと呼びます。 ベクトルデータベース:  エンベディングされたベクトルをデータベース（この例ではPostgreSQL + pgvector）に格納します。 類似度計算:  検索クエリも同様にベクトルに変換し、データベース内のベクトルとの類似度を計算します。類似度の高いベクトルを持つデータが、検索結果として返されます。 例: 「猫が好きな人におすすめの映画は？」という質問をベクトル検索にかけると、「猫」というキーワードが含まれていなくても、「猫が登場する映画」「猫を飼っている人が主人公の映画」など、意味的に関連性の高い映画が検索結果として表示される可能性があります。 つまり、ベクトル検索は、キーワードに縛られず、意味に基づいた柔軟な検索を実現する技術なのです。 PostgreSQL採用の5大メリット ベクトル検索システムを構築する上で、PostgreSQLを採用するメリットは多岐にわたります。以下に主な5つのメリットを挙げます。 拡張性:  pgvector拡張により、PostgreSQLにベクトル検索機能を追加できます。既存のデータベース環境を大きく変更する必要はありません。 コスト効率:  オープンソースであるため、高額なライセンス費用は不要です。必要なハードウェアリソースのみで運用できます。 信頼性:  PostgreSQLは長年の実績を持つ堅牢なRDBMSであり、高い信頼性と安定性を誇ります。 標準SQL対応:  既存のSQLクエリと組み合わせて、複雑な検索処理を記述できます。 コミュニティサポート:  世界中に活発なコミュニティが存在し、豊富な情報やサポートが得られます。 従来検索とのパフォーマンス比較表 検索方式 検索精度 検索速度 (データ量依存) 柔軟性 備考 キーワード検索 キーワード一致に依存。曖昧な表現や同義語に弱い。 高速 低い。キーワードの厳密な一致が必要。 シンプルな検索には適している。 ベクトル検索 意味的な類似性に基づくため、キーワードに依存しない。高い精度を実現。 データ量に依存。インデックス構造で高速化可能。 高い。ユーザーの意図を汲み取った柔軟な検索が可能。 大量のデータに対しては、適切なインデックス設計が重要。 全文検索 キーワード検索より高度な検索が可能だが、意味理解は限定的。 データ量に依存。 中程度。 日本語の形態素解析など、言語依存の処理が必要な場合がある。 補足: パフォーマンスは、データ量、ハードウェア、インデックス設計などに大きく左右されます。 上記比較表はあくまで一般的な傾向を示すものであり、実際のパフォーマンスは環境によって異なります。 専用のベクトルデータベースとの比較 専用のベクトルデータベース（例: Chroma, FAISS, Pinecone）とPostgreSQLの拡張機能であるpgvectorは、それぞれ異なる強みを持っています。ここでは、pgvectorと専用ベクトルデータベースとの違いや、それぞれのメリット・デメリットを解説します。 pgvectorの特徴 pgvectorは、PostgreSQLにベクトル検索機能を追加する拡張機能です。以下が主な特徴です： リレーショナルデータとの統合 ：ベクトルデータと従来のリレーショナルデータを同じデータベースで管理可能。 低コスト導入 ：既存のPostgreSQL環境に拡張機能として追加するだけで利用可能。 ACID準拠 ：トランザクション管理やセキュリティ機能をそのまま利用可能。 専用ベクトルデータベースの特徴 専用ベクトルデータベース（例: Chroma, FAISS, Pinecone）は、ベクトル検索に特化した設計がされています。以下が主な特徴です： 高速検索 ：高次元ベクトルに最適化されたインデックス設計（例: HNSW, IVF）。 スケーラビリティ ：分散システムによる水平スケーリングが容易。 多様なデータ形式対応 ：画像、音声、動画などの非構造化データも効率的に処理可能。 比較表 項目 pgvector 専用ベクトルデータベース（例: Chroma, FAISS） 導入コスト 低い（既存PostgreSQL環境で利用可能） 高い（新規インフラ構築が必要） 速度（大規模データ） 中程度（PostgreSQL依存） 高速（専用設計による最適化） スケーラビリティ 垂直スケール（ハードウェア増強が必要） 水平スケール（分散システム対応） 統合性 高い（SQLクエリでリレーショナルデータと統合） 低い（別途APIやミドルウェアが必要） ユースケース 小〜中規模データ、既存RDBMSとの統合 大規模データ、高速検索が求められるAI/MLワークフロー 学習コスト 低い（PostgreSQLユーザーに馴染みやすい） 中〜高（新しいツールやAPIの習得が必要） pgvectorのメリットとデメリット メリット 簡単な導入手順 ：PostgreSQL環境に拡張機能としてインストールするだけで利用可能。 低コスト運用 ：既存インフラを活用できるため、新たなサーバー構築が不要。 SQL統合性 ：従来のSQLクエリと組み合わせてハイブリッド検索が可能。 デメリット パフォーマンス限界 ：大規模データセットや超高次元ベクトルでは専用VectorDBに劣る。 水平スケーリング非対応 ：PostgreSQL自体が分散システムに最適化されていないため、大量トラフィックには不向き。 機能制約 ：画像や音声など非構造化データへの対応は限定的。 専用ベクトルデータベースのメリットとデメリット メリット 高速な類似検索 ：HNSWやIVFなど、高度なインデックスアルゴリズムを採用。 大規模データ対応 ：分散システムによる水平スケーリングで数十億件以上のベクトル処理も可能。 柔軟性 ：画像、音声、動画など多様なデータ形式に対応。 デメリット 導入・運用コストが高い ：新たなインフラ構築や運用管理が必要。 学習コストが高い ：新しいツールやAPIの習得が求められる。 統合性が低い ：従来のRDBMSとの連携には追加開発が必要。 選択基準 pgvectorを選ぶべきケース 既存のPostgreSQL環境を活用したい場合 中小規模のプロジェクトでコスト効率を重視する場合 リレーショナルデータとの統合性が重要な場合 専用VectorDBを選ぶべきケース 数千万〜数億件以上の大規模ベクトル検索を行う場合 非構造化データ（例: 画像、音声）の処理が必要な場合 高速性とスケーラビリティを最優先する場合 pgvectorは、PostgreSQLユーザーにとって手軽かつコスト効率の良い選択肢であり、中小規模プロジェクトには最適です。一方、専用VectorDBは、大規模かつ複雑なAI/MLワークフローにおいて圧倒的なパフォーマンスを発揮します。用途や要件に応じて、それぞれの特性を活かした選択を行うことが重要です。 環境構築 本章ではハンズオン形式で PostgreSQLコンテナのセットアップ から、 Streamlitを用いたフロントエンドの構築 、そしてそれらを連携させる Docker環境の設定 まで、必要な手順をわかりやすく解説します。この章の手順に従うことで、pgvectorを用いた簡単なベクトル検索システムを構築できます。 環境構成 上記のように非常にシンプルな構成をdocker composeで構築します。 ディレクトリ構成は以下のようになります。 ├── .streamlit │ └── secrets.toml *# DB接続情報* ├── docker-compose.yml ├── postgres │ ├── Dockerfile *# PG拡張機能インストール* │ └── initdb │ └── init.sql *# テーブル定義* └── streamlit ├── Dockerfile *# Python環境構築* ├── app.py *# メインアプリ* ├── embeddings.py *# ベクトル生成ロジック* ├── requirements.txt └── seed.py *# テストデータ生成* PostgreSQLコンテナの環境構築 PostgreSQLのデータベースを起動するコンテナ上に初期設定用のSQLファイルを作成します。 CREATE EXTENSION IF NOT EXISTS vector; -- サンプルテーブル作成（必要に応じてカスタマイズ） CREATE TABLE documents ( id SERIAL PRIMARY KEY, title TEXT, content TEXT, embedding VECTOR(1024) ); CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops); Streamlitコンテナの環境構築 メイン処理となるpythonコードを記述したファイルを作成します。 import streamlit as st import pandas as pd import numpy as np from datetime import datetime import psycopg2 from psycopg2.extras import execute_values from sqlalchemy.sql import text from streamlit.logger import get_logger from embedding import Embedding logger = get_logger(__name__) embedding = Embedding() # ページ設定 st.set_page_config( page_title="Vector Database Demo", page_icon="🔍", layout="wide" ) def get_embedding(text): return embedding.get_embedding([text])[0] # データベース接続関数 def get_connection(): return st.connection('postgresql', type='sql') # メインアプリケーション def main(): st.title("📊 Vector Database Demo") # サイドバーでの操作選択 operation = st.sidebar.selectbox( "操作を選択", ["データ表示", "データ追加", "ベクトル検索"] ) if operation == "データ表示": show_data() elif operation == "データ追加": add_data() elif operation == "ベクトル検索": vector_search() def show_data(): st.header("📋 登録データ一覧") conn = get_connection() # データ取得 query = "SELECT id, title,content FROM documents LIMIT 100" df = conn.query(query, ttl=0) if not df.empty: st.dataframe(df) else: st.info("データが登録されていません") def add_data(): st.header("➕ データ追加") # 入力フォーム with st.form("data_form"): title = st.text_input("タイトルを入力") content = st.text_area("テキストを入力") submitted = st.form_submit_button("登録") if submitted and content: conn = get_connection() # サンプルとして、ランダムな1536次元ベクトルを生成 # 実際のアプリケーションでは、適切なエンベッディングモデルを使用する embedding = get_embedding(title + " " + content) # データ登録 query = text(""" INSERT INTO documents (title, content, embedding) VALUES (:title, :content, :embedding) """) params = {"title": title, "content": content, "embedding": embedding} try: with conn.session as session: session.execute(query, params) session.commit() st.success("データを登録しました") except Exception as e: st.error(f"エラーが発生しました: {str(e)}") def vector_search(): st.header("🔍 ベクトル検索") search_text = st.text_input("検索テキストを入力") k = st.slider("表示件数", min_value=1, max_value=10, value=5) if st.button("検索") and search_text: # サンプルとして、ランダムなクエリベクトルを生成 # 実際のアプリケーションでは、入力テキストを適切にエンベッディング query_vector = get_embedding(search_text) conn = get_connection() # コサイン類似度による検索 query = """ SELECT title,content, 1 - (embedding <-> :query_vector) as similarity FROM documents ORDER BY embedding <-> :query_vector LIMIT :k """ params = {"query_vector": str(query_vector), "k": k} try: df = conn.query(query, params=params, ttl=0) if not df.empty: # 結果表示 for _, row in df.iterrows(): with st.expander(f"{row['title']} 類似度: {row['similarity']:.4f}"): st.write(row['content']) else: st.info("検索結果が見つかりませんでした") except Exception as e: st.error(f"検索中にエラーが発生しました: {str(e)}") # アプリケーション実行 if __name__ == "__main__": main() テキストの埋め込み処理を行うpythonコードを記述したファイルを作成します。 今回の例ではデフォルトで埋め込み用のモデルにmultilingual-e5-largeを使用するように設定しています。このモデルを変更することで検索時の傾向等を変えることが可能です。 intfloat/multilingual-e5-large · Hugging Face import torch.nn.functional as F from torch import Tensor from transformers import AutoTokenizer, AutoModel class Embedding: def __init__(self, model_name: str = 'intfloat/multilingual-e5-large'): self.model_name = model_name self.load_model() def load_model(self): self.tokenizer = AutoTokenizer.from_pretrained(self.model_name) self.model = AutoModel.from_pretrained(self.model_name) def average_pool( self, last_hidden_states: Tensor, attention_mask: Tensor ) -> Tensor: last_hidden = last_hidden_states.masked_fill(~attention_mask[..., None].bool(), 0.0) return last_hidden.sum(dim=1) / attention_mask.sum(dim=1)[..., None] def get_embedding(self, input_texts: list[str]) -> list[float]: batch_dict = self.tokenizer(input_texts, max_length=512, padding=True, truncation=True, return_tensors='pt') outputs = self.model(**batch_dict) embeddings = self.average_pool(outputs.last_hidden_state, batch_dict['attention_mask']) return F.normalize(embeddings, p=2, dim=1).tolist() 初期データの投入を行うpythonコードを記述したファイルを作成します。 単純にタイトルと内容をならべ、それらをデータベースに埋め込み表現と共に保存しています。 import psycopg2 import numpy as np from psycopg2.extras import execute_values from embedding import Embedding test_data = [ { "title": "Dockerコンテナのベストプラクティス2025年版", "content": "Dockerコンテナを本番環境で効率的に運用するためのベストプラクティスを解説します。イメージサイズの最適化、セキュリティ対策、ネットワーク設定、ボリューム管理など、実践的なトピックを網羅的にカバーします。マルチステージビルドの活用方法や、環境変数の適切な管理方法についても詳しく説明します。" }, { "title": "PyTorchによる深層学習モデルの最適化手法", "content": "PyTorchを使用した深層学習モデルのパフォーマンス最適化について解説します。バッチサイズの調整、学習率スケジューリング、データローダーの最適化、GPUメモリの効率的な使用方法など、実践的な最適化テクニックを紹介します。" }, { "title": "マイクロサービスアーキテクチャの設計パターン", "content": "マイクロサービスアーキテクチャを採用する際の主要な設計パターンについて解説します。サービス間通信、データ一貫性の確保、障害対策、モニタリング戦略など、実装時の重要なポイントを詳しく説明します。" }, { "title": "Kubernetes運用管理の実践ガイド", "content": "Kubernetesクラスタの効率的な運用管理方法について解説します。リソース管理、オートスケーリング、モニタリング、セキュリティ対策など、実運用で必要となる知識を体系的に説明します。" }, { "title": "効率的なデータベースインデックス設計", "content": "リレーショナルデータベースにおけるインデックス設計のベストプラクティスを解説します。クエリパフォーマンスの最適化、インデックス選択の基準、メンテナンス戦略など、実践的なアプローチを紹介します。" }, { "title": "GraphQLによるモダンAPIの構築", "content": "GraphQLを使用したAPIの設計と実装について解説します。スキーマ設計、リゾルバの実装、N+1問題の解決、キャッシュ戦略など、実践的な開発手法を紹介します。" }, { "title": "CI/CDパイプラインの自動化戦略", "content": "継続的インテグレーション/デリバリーパイプラインの効率的な構築方法について解説します。テスト自動化、デプロイ戦略、品質管理、モニタリングなど、実践的な自動化手法を紹介します。" }, { "title": "セキュアなWebアプリケーション開発", "content": "Webアプリケーションのセキュリティ対策について包括的に解説します。XSS対策、CSRF対策、認証・認可の実装、セキュアなセッション管理など、重要なセキュリティ考慮事項を説明します。" }, { "title": "効率的なキャッシュ戦略の実装", "content": "Webアプリケーションにおけるキャッシュ戦略の設計と実装について解説します。CDN、ブラウザキャッシュ、アプリケーションキャッシュ、データベースキャッシュなど、多層的なキャッシュ戦略を紹介します。" }, { "title": "大規模データ処理のベストプラクティス", "content": "大規模データ処理システムの設計と実装について解説します。バッチ処理、ストリーム処理、データパイプライン、スケーラビリティ確保など、実践的なアプローチを紹介します。" }, { "title": "ReactとTypeScriptによるフロントエンド開発", "content": "ReactとTypeScriptを組み合わせた最新のフロントエンド開発手法について解説します。型安全な開発、コンポーネント設計、状態管理、パフォーマンス最適化など、実践的な開発テクニックを紹介します。" }, { "title": "AWSでのスケーラブルなインフラ構築", "content": "AWSを使用したスケーラブルなインフラストラクチャの構築方法について解説します。オートスケーリング、負荷分散、障害対策、コスト最適化など、クラウドインフラの設計ポイントを説明します。" }, { "title": "効率的なログ管理とモニタリング", "content": "分散システムにおけるログ管理とモニタリングの実践的アプローチについて解説します。ログ収集、分析、可視化、アラート設定など、効果的な運用監視の方法を紹介します。" }, { "title": "マイクロフロントエンドアーキテクチャの実装", "content": "マイクロフロントエンドアーキテクチャの設計と実装について解説します。モジュール分割、統合戦略、ルーティング、状態管理など、フロントエンド開発の新しいアプローチを紹介します。" }, { "title": "NoSQLデータベースの設計パターン", "content": "NoSQLデータベースを使用する際の効果的な設計パターンについて解説します。データモデリング、クエリ最適化、スケーリング戦略など、実践的な使用方法を紹介します。" }, { "title": "機械学習モデルの本番環境デプロイ", "content": "機械学習モデルを本番環境にデプロイする際の実践的アプローチについて解説します。モデルのバージョン管理、スケーリング、モニタリング、再学習戦略など、運用上の重要ポイントを説明します。" }, { "title": "Terraformによるインフラのコード化", "content": "Terraformを使用したインフラストラクチャのコード化について解説します。リソース管理、モジュール設計、状態管理、チーム開発など、IaCの実践的な適用方法を紹介します。" }, { "title": "効率的なAPIバージョニング戦略", "content": "WebAPIのバージョニング戦略について実践的な方法を解説します。バージョン管理手法、下位互換性の確保、マイグレーション戦略など、長期的な API 運用のポイントを説明します。" }, { "title": "セキュアなマイクロサービス間通信", "content": "マイクロサービス環境におけるセキュアな通信方法について解説します。認証、認可、暗号化、証明書管理など、サービス間通信のセキュリティ確保方法を説明します。" }, { "title": "効率的なデータベースマイグレーション", "content": "大規模データベースのマイグレーション戦略について解説します。ダウンタイム最小化、データ整合性確保、ロールバック計画など、安全なマイグレーションの実施方法を紹介します。" } ] def insert_test_data(): conn = psycopg2.connect( dbname="vectordb", user="postgres", password="postgres", host="postgres", port="5432" ) cur = conn.cursor() embedding = Embedding() for data in test_data: # サンプルとして1536次元のランダムベクトルを生成 emb = embedding.get_embedding([data["title"] + " " + data["content"]])[0] cur.execute( "INSERT INTO documents (title, content, embedding) VALUES (%s, %s, %s)", (data["title"], data["content"], emb) ) conn.commit() cur.close() conn.close() if __name__ == "__main__": insert_test_data() データベースとの接続定義を記述したファイルを作成します。 [connections.postgresql] dialect = "postgresql" host = "postgres" port = 5432 database = "vectordb" username = "postgres" password = "postgres" 依存ライブラリを記述したファイルを作成します。 SQLAlchemy==2.0.35 streamlit==1.32.0 pandas==2.2.0 numpy==1.26.0 psycopg2-binary==2.9.9 torch==2.6.0 transformers==4.48.2 Docker環境のセットアップ まずはpostgresのDockerfileから作成をしていきます。 postgresベースのイメージにpgvectorのインストール処理を追加します。 FROM postgres:16.3 # pgvectorインストール RUN apt-get update && \\ apt-get install -y \\ build-essential \\ git \\ postgresql-server-dev-16 RUN git clone <https://github.com/pgvector/pgvector.git> /tmp/pgvector && \\ cd /tmp/pgvector && \\ make && \\ make install && \\ rm -rf /tmp/pgvector 続けてStreamlitのDockerfileを作成します。 FROM python:3.11-slim WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt CMD ["streamlit", "run", "./streamlit/app.py", "--server.port=8501"] 最後にこれらのコンテナを束ねて管理するdocker-compose.ymlを作成します。 version: "3.9" services: postgres: build: ./postgres environment: POSTGRES_USER: postgres POSTGRES_PASSWORD: postgres POSTGRES_DB: vectordb volumes: - postgres_data:/var/lib/postgresql/data - ./postgres/initdb:/docker-entrypoint-initdb.d ports: - "5432:5432" networks: - app-network streamlit: build: ./streamlit volumes: - .:/app environment: - STREAMLIT_SERVER_PORT=8501 ports: - "8501:8501" depends_on: - postgres networks: - app-network volumes: postgres_data: networks: app-network: driver: bridge 動作確認 起動確認 以下のコマンドでコンテナのビルドを行います。 docker compose build 以下のコマンドでコンテナの起動を行います。 docker compose up -d ブラウザで以下のアドレスにアクセスします。 http://localhost:8501/ 最初はモデルを読み込むためロード中となり、下記のような画面が表示されるかと思いますが その後このような表示になれば、サーバーの起動に成功しています。 初期データの投入 データベースに初期データを投入する為、コンテナ上でコマンドを実行します。 まずはコンテナの状態の確認を行います。 $ docker compose ps NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS pgvector-postgres-1 pgvector-postgres "docker-entrypoint.s…" postgres 2 hours ago Up 2 hours 0.0.0.0:5432->5432/tcp, :::5432->5432/tcp pgvector-streamlit-1 pgvector-streamlit "streamlit run ./str…" streamlit 2 hours ago Up 2 hours 0.0.0.0:8501->8501/tcp, :::8501->8501/tcp 上記で出力されたコンテナの内、streamlitのコンテナ上で以下のようにしてコマンドを実行します。 $ docker exec -it pgvector-streamlit-1 python streamlit/seed.py コマンド実行後に再度ブラウザで以下のアドレスにアクセスします。 http://localhost:8501/ 投入したデータが一覧で表示されるようになりました。 Vector検索の確認 先ほどアクセスした画面の「操作を選択」から「ベクトル検索」を選択します。 上記のような画面が表示されるかと思います。 試しにこちらの検索テキストに「MySQL」と入力して検索してみます。 上記のように結果が表示されました。内容としては以下のようなものですが、もちろん本文に「MySQL」という文言はありません。 内容の指向性や意味などからもっとも類似度の高い内容順に並べることができていることが確認できます。 おわりに 本記事で実践したPostgreSQLベクトル検索システムの構築は、AI時代のデータ活用における重要な第一歩です。 従来のリレーショナルデータベースの枠組みを超え、意味理解を組み込んだ次世代検索技術 を、既存インフラで実現する手法を具体例と共に解説しました。 本格的な導入を検討される方は、まずは pgvector公式ドキュメント と E5モデルに関しての記事 の精読をお勧めします。実際のプロダクション環境では、 インデックス再構築戦略 と メモリ最適化 が成否を分ける鍵となります。 最後に、本記事が皆様のAI/MLプロジェクト推進の一助となれば幸いです。 The post PostgreSQLで実践するベクトル検索入門：AI時代のRDBMS活用術 first appeared on Sqripts .

こんにちは、QAコンサルタントの ヤマダ です。 私はこのたび、JSTQB® Advanced Level テストマネージャ試験に合格しました。   本記事では、試験合格のために活用した書籍「 科学的根拠に基づく最高の勉強法 」の内容を解説するとともに、JSTQB試験の概要、そして実践した勉強法を共有します。 書籍の紹介：「科学的根拠に基づく最高の勉強法」 この書籍は、医師であり学習法の専門家である著者が、最新の研究論文やデータを基に、科学的に効果が証明された学習法を紹介したものです。特に、次のようなポイントが大きな特徴です。 効果が低い学習法 日常的に行われがちな以下の方法は、実は非効率とされています： 繰り返し読む ：一見効果的に思えるが、記憶の定着にはほとんど寄与しない。 ノートに書き写す ：時間がかかる割に、記憶や理解が深まらない。 ハイライトや下線を引く ：重要箇所をマークする行為そのものに学習効果はない。 効果が高い学習法 1. アクティブリコール（能動的記憶再生） 学習した知識を記憶から引き出すことで、記憶が強化されます。たとえば問題を解く、クイズ形式で学ぶといった方法が該当します。 2. 分散学習 短時間で詰め込むのではなく、間隔を空けて繰り返し復習することで、記憶の定着率が向上します。たとえば、1日おきに復習する、週ごとに学び直すといった方法です。 3. 精緻的質問と自己説明 精緻的質問 ：学んだ内容に対して「なぜそうなるのか」と問いかけ、深掘りして理解を深めます。 自己説明 ：学習した内容を自分の言葉で説明することで、曖昧な理解を防ぎます。 これらの方法を組み合わせることで、学習効率を大幅に向上させることができます。 JSTQB®の試験とテストマネージャモジュールの紹介 JSTQB®の概要 JSTQB®（Japan Software Testing Qualifications Board）は、ソフトウェアテストの知識と技能を体系的に学び、その理解度を証明する資格試験を提供する団体です。ISTQB®（International Software Testing Qualifications Board）の国際基準に基づいており、ソフトウェアテストの標準資格として広く認知されています。 試験の構成 JSTQB®試験には以下の3つのレベルがあります。 1. Foundation Level 初心者向け。テストの基本概念、設計技法、テスト管理の基礎が試験範囲に含まれます。 2. Advanced Level 経験者向け。3つのモジュールに分かれています。 テストマネージャ ：テスト計画やプロジェクト管理に特化。 テストアナリスト ：要件分析やテスト設計技法に焦点。   テクニカルテストアナリスト ：テストツールや自動化の活用。 3. Expert Level   ソフトウェアテストの最上級資格。リーダーシップやプロセス改善に関する知識を問われます。 Advanced Level テストマネージャの試験内容 テストマネージャは、テストプロジェクトを計画・実行・管理するスキルを証明するためのモジュールです。以下が主な試験範囲です。 テストプロセス ：テスト戦略の作成、計画、モニタリング、評価。 リスクベーステスト ：リスクを特定し、優先順位を付けてテスト計画を策定。 テストチームの管理 ：チームビルディングやステークホルダーとのコミュニケーション。 品質保証 ：メトリクス分析やプロセス改善の実施。 ツールと自動化 ：適切なツールの選定と導入。 実践した勉強法 以下の3ステップを繰り返しながら学習を進めました。このプロセス全体に書籍で紹介されている学習法を取り入れています。 1. シラバスを読む 方法とポイント 流し読みからスタート ：まずはシラバス全体を流し読みし、試験範囲を大まかに把握。 不明点をメモ ：分からない箇所や重要そうな部分をメモに記録し、後のプロセスで補強。 関連情報を調査 ：シラバスに記載された内容について理解が曖昧な部分は、ChatGPTやWeb検索で調査。 活用した勉強法 分散学習 ：シラバスを一度に全部読むのではなく、複数回に分けて学習しました。1日目に全体を流し読み、2日目以降に重点的な箇所を再度読むことで記憶を強化しました。 精緻的質問 ：各セクションで「なぜこの方法が重要なのか」「どうしてこれが推奨されるのか」を自分に問いかけながら学習しました。 2. 問題を解く 方法とポイント 問題演習の徹底 ：非認定問題集を使いながら繰り返し問題を解き、シラバスの内容を応用する練習を行いました。 間違いの記録 ：間違えた問題について、問題番号、対応するシラバスの箇所と間違えた原因をメモ。 ChatGPTを活用 ：シラバスと問題集をChatGPTにインプットし、問題集に含まれていない新しい問題を生成してもらうことで、幅広い演習を実施しました。 活用した勉強法 アクティブリコール ：問題を解くことで、学習した知識を記憶から引き出し、記憶を強化しました。 自己説明 ：解いた問題について「なぜこの答えが正解なのか」「他の選択肢が不正解の理由」を自分に説明しました。これにより、選択肢の背景や理論を深く理解できました。 3. 振り返り 方法とポイント 振り返りは学習の各ステップで必ず行い、学習効率を高めました。振り返りでは、これまでに取った メモ を活用して原因分析を行います。 メモの活用 ：シラバスを読んだ際に書き留めた不明点や、問題を解いた際に記録した間違えた箇所やその理由を参照。 原因分析 ：「知識不足」「問題文の読み違い」「思い込み」などに分類し、それぞれの対策を実施。 弱点補強 ：特に苦手な分野については、再度シラバスを読み直したり、問題を解き直したりして克服を図りました。 進捗の可視化 ：日々記録を取っているため、これまで間違えていた問題が出来るようになっていることが分かり、自分の成長を確認しました。 活用した勉強法 分散学習 ：振り返りを何度も行い、時間を空けて同じ内容を復習することで、知識の定着を強化しました。新しい知識よりも復習を重視しました。 精緻的質問 ：「なぜ間違えたのか」「どのように考えれば正解にたどり着けたのか」を繰り返し問いかけ、理解を深めました。 スキマ時間を活用した学習 スキマ時間を積極的に活用することも、 分散学習 の効果を得るための重要な手段です。以下のように、短時間の学習を複数回に分けて行いました。 通勤時間 ：シラバスの読み込みや、理解が曖昧な箇所の復習。 昼休み ：問題集を1問でも解く。 夜の15分 ：振り返りや弱点補強。 まとめ 「科学的根拠に基づく最高の勉強法」を取り入れることで、学習効率を向上させることができたと思います。この方法は、資格試験だけでなく、日常の学びやスキルアップにも応用可能です。これから受験を目指す方は、科学的なアプローチを試してみてはいかがでしょうか？ The post JSTQB Advanced Level テストマネージャ勉強法　-科学的根拠に基づく最高の勉強法を参考にして- first appeared on Sqripts .

この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 ＜QAエンジニアのスタートガイド 記事一覧＞ ※クリックで開きます 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- 第3話ではソフトウェアテストにおける「テスト実行」について、テスト活動における重要さと、充実させるポイントをお話ししました。「テスト実行」を実際に体験し、そこから学ぶことは大変重要なことだと思っています。 一方で、テスト実行を支えるその他の活動を理解することも大切です。そして、QAエンジニアとして大切なことは、これらの活動についてきちんと理解したうえで、「テストをマネジメントする」という考え方をすることです。 今回の記事ではテスト実行以外の活動について解説します。そして、それらの活動を踏まえた上で、さらにステップアップを目指す内容についてご紹介します。 テスト実行を支えるその他の活動 テスト計画・テスト設計といったその他のテスト活動は、テスト実行を支える活動と言ってもいいと思います。この記事では、テスト実行をベースにその他の活動を捉えることで、よりテスト全体への理解を深めることを目的としています。 この記事が、テスト実行以外の活動を実施する際の一助となれば幸いです。 テスト設計 本記事では、JSTQBにおける「テスト分析」「テスト設計」「テスト実装」を総称して「テスト設計」と呼びます。「テスト設計」という名前のプロセスや成果物は、実はチームや組織、文献によっても異なるからです。 そういった背景がありつつも、「テスト設計という活動によってテストケースを作成する」というところは共通理解として成り立つのではないでしょうか。 テスト実行中にテスト設計について気にするポイントとしては、「なぜこのテストケースを作成したのか」を考えることです。 もしかしたらテストケースの中には「テスト条件」「テスト観点」「テスト項目」といった項目があるかもしれません。それらの内容から、「テストを実行する理由」を探してほしいと思います。これらを念頭に置いた上で、「実際にどのようなテストケースでカバーしているか」「どのような思考でテストケースを作っているか」を考えることはQAエンジニアとして重要な学びに繋がると考えます。 テストのモニタリングとコントロール テストのモニタリングとコントロールという活動は、スケジュールや人のアサインの調整だと思われている方がいます。それらは重要な管理対象であることに間違いありませんが、それだけではありません。 たとえば、テスト実行で得られた情報を元に、テスト実行の順番を調整したり、テストの追加・削除を検討することもあります。他にもテストの開始基準や完了基準を再検討して、テスト計画をアップデートすることも含まれます。 テスト実行をしていて気にするべきポイントは、「テストのモニタリングとコントロールのためにどのような情報を収集しているだろうか」「それらによってどのような意思決定がされただろうか」だと考えます。 テストをただ消化するだけでなく、消化したテストによってどのような判断がされたかを理解することは、ご自身がテストをマネジメントする立場になったときに活きてくるでしょう。 テスト完了 「テスト完了」はテスト活動の集大成という側面や、次のテストのプロジェクトのために学びを活かすなどの側面があります。 所属する組織で「テスト完了レポート」を作成している場合、ぜひ一読されることをおすすめします。 我々のテスト活動が、ステークホルダーへどのように報告されるかを知ることができるからです。それによって、「我々のテストで重要なのはどの部分だったのか？」「我々のテスト活動を待っている人々は何が知りたかったのか？」を理解することができます。 また、完了報告のミーティングに参加することも学びに繋がります。これは、テスト活動において、どのようなニーズがあったのかを知り、ステークホルダーの反応を知るよい機会になります。 テスト計画 テスト計画の成果物であるテスト計画書は、その現場のテストを理解するにあたって、最も重要なドキュメントのひとつです。テスト計画書には、通常、「テストの目的」「テストにおける制約」「最適なアプローチ」「完了のための手段」などが記載されています。 ひいてはテスト実行の活動がどのような意味を持ち、どのような文脈の中で、どんな実行計画を立てたのか、その中で自分はどのような位置にいるのかを知ることは普段の仕事の目的意識を持つためにも重要です。 アジャイル開発などのプロジェクトでは、テスト計画という活動やテスト計画書といった成果物がない場合もあります。その場合でも上記のような観点で「どのようにテストを計画しているのだろうか」を考えることは学びに繋がります。 QAとして「テストをマネジメントするという」考え方を持とう ソフトウェアテストには「テストマネージャー」というロールがあります。彼らは「テストマネジメントをする」という役割を持っています。そのような役割を持った人がいるために、「テストマネージャーになるまでテストマネジメントはしなくていい」と考える人もいます。 この考えはQAエンジニアのキャリアや働き方にとって、ポジティブな意味を持たないと私は考えています。 自分のチームがテストを通して「どのような情報を取得したか」「どのような意思決定をしたか」についてきちんと把握することで、QAとして重要な「目的意識」を養うことができます。 読者の方の中には、自分一人で意思決定をすることはない人もいるかもしれません。 しかしながらそのための情報提供や、自分の専門性を元にチームへ示唆を与えることは必要だと考えています。 特に、「QAエンジニア」というロールの場合は、テストマネージャーではなくても「テストをマネジメントする」という考えを持つ必要があると考えます。 QAの責務を「テストの仕事を収める」ではなく、「品質を保証すること」であると考えるのはいかがでしょうか。 テストという分野においては、単にテストを消化するだけでなく、効果的にテストを行なう必要があります。そのために常に「テストマネジメント」の意識を持っておくことが重要になるのです。 QAエンジニアに求められるテストの周辺知識 テストエンジニアではなく、あえて「QAエンジニア」と名乗るからには、テストだけでなくもう少し広い知識をつけることも大切だと考えます。 ここからは、さらに飛躍するための知識について紹介します。 自動テスト 自動テストの知識は、QAエンジニアにとって必須になりつつあります。手動でテストの活動をするだけでなく、自動テストについてきちんと理解して・作り上げる知識を持つことが大切です。 自動テストを考える過程でテスト全体に向き合うこととなりますので、テストレベルやテストマネジメントへの理解が深まるという効果もあります。 品質管理 品質管理は、ソフトウェア開発よりも長い歴史を持つ分野であり、関連書籍も多数出版されています。これらについて深く理解することは、QAとしての考えの軸を定めるのに効果的です。 ひとつ補足をすると、ソフトウェア開発と、量産工程がある製品の開発は、品質管理のプロセスが異なります。そのため、単純にすべてのプラクティスを使うことには注意をした方がいいでしょう。 ソフトウェアエンジニアリング 私は「ソフトウェアエンジニアリング」を学ぶことが最も大切だと考えます。ここでいう「ソフトウェアエンジニアリング」とは、モデリングやプログラミングなど、ソフトウェア開発におけるさまざまなプラクティスを指します。 特にプログラミングについては、エンジニアでなくでもPCを使う全ての職種で必要になる技術だと考えます。 QAのハードスキルを手に入れるための参考文献 ソフトウェアテストについて知りたい場合、最も手軽なのは「JSTQBシラバス」です。専門用語が多く、最初はとっつきにくいですが、一読することをおすすめします。 ソフトウェアテストについての書籍を紹介しておきたいところですが、「この本さえ読んでおけば大丈夫」という本は私が読んだ中では存在しません。それぞれの書籍によって見解や専門分野が異なるためです。 そのため、さまざまな文献を多読して、自分なりのテスト観を育てることが大切です。 ソフトウェアテストの学習と参考になるのが、以下の「ソフトウェアテストの読書マップ」です。 ソフトウェアテスト読書マップ QAとしては SQuBOK(ソフトウェア品質保証知識体系) を一度読んでみることをおすすめします。 SQuBOKでは、ソフトウェアQAに必要な知識が網羅的に解説されています。 「この状況ではどんな方法があるんだっけ」というインデックスを早期に作っておくことは、QAエンジニアの経験を豊かにする良い方法だと考えます。 ソフトウェアエンジニアリングの本もおすすめです。特にQAに関係する方が翻訳している「 実践ソフトウェアエンジニアリング 」という本は、全体像を把握できるので、ぜひ手にとってみてください。 おわりに 第3話、第4話と続いた「ハードスキル」の紹介ですが、ITエンジニアにとってハードスキルの学習に終わりはありません。 この記事の内容に満足するのではなく、さまざまな分野に興味を持って、主体的に学習することをおすすめします。 【連載】QAエンジニアのスタートガイド 記事一覧 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編- The post 【第4回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -後編-｜QAエンジニアのスタートガイド first appeared on Sqripts .

この連載では、1人目QAとしてのチームの立ち上げや組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。 前回の記事 では、開発者とQAとのコミュニケーションに関する問題やその対応について解説しました。 【第4回】QAと開発者とのコミュニケーション｜QA組織の立ち上げ方 この連載では、1人目QAとしてのチームの立ち上げや組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。前回の記事では、チームビルディングの概念や考え方の説明と、QAチームにおけるチームビルディングについてタックマンモデルの各段階... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、QAチームを立ち上げていく過程でメンバーのキャリアをどう作っていくかを考えます。 チーム立ち上げにおけるメンバーのキャリアパス QAチームを立ち上げ成長させていく上で、メンバーのキャリアパスは重要なテーマです。とくに、立ち上げ初期のメンバーや若手エンジニアにとっては、チームでの活動を通じて将来どのようなキャリアを描けるのかが重要です。明るい未来が見通せるかどうかは、日々のモチベーションや成長に大きく影響します。 そこで、今回はQAチームにおけるキャリアパスを 社内でのキャリア 社外でのキャリア という2つの側面から掘り下げてみたいと思います。 社内でのキャリアパス QAエンジニアとして自社で働く過程で、どのような経験を積みどのような道に進めるのか、具体的なキャリアビジョンを示すことが不可欠です。 ビジョンを示すことの重要性 中堅・ベテランにもなれば「キャリアは自分で考えて築くもので、会社がすべて考えるわけではない」と言えるのですが、キャリア形成の初期段階にある若手エンジニアに対してはそうはいきません。QAチームを組成して数年が経ち、社内での役割・位置づけ・評価の仕方などが固まっている場合は、キャリアの見通しがつきやすいでしょう。しかし、本記事が対象としている「QAチームの立ち上げ」の段階においては、QAエンジニアとして働いた先のイメージが持ちづらくなります。 もちろん暫定ではあると思いますが、QA組織を将来どうしたいかのビジョンとともに ジュニアなQAエンジニアも含めて、QAチームのマネジメントを担えるようになる SETとしてテスト自動化等に強みを発揮する など複数の選択肢を提示できると良いでしょう。 このとき、 第1回 でも触れたQMファンネルを参考に、テストエンジニア・パイプラインエンジニア（SET）・QAエンジニアといった軸で検討をするとわかりやすいです。さらに、各ロールにおけるスプリット・インプロセス・コーチ・コンサルタント・プロモーターといった役割を組み合わせることで、より多様なキャリアパスを描くことができます。 【第1回】QA組織立ち上げの流れと組織の形 以前の連載である1人目QAとしての立ち回りでは、会社や開発組織の1人目QAになった人がどのような活動をするのかや、品質保証を浸透させる際のアプローチなどについて触れました。今回の連載では1人目QAとしてチームを立ち上げていく部分、組織づくりに関して、私が実... 　続きを読む　 Sqripts 関連記事｜Sqripts 社外でのキャリアパス QAチームを立ち上げる際、社外でのキャリアパスを考慮することは、一見するとチームの安定を損なうように思えるかもしれません。「せっかく育てたのに、転職してしまうのではないか？」という懸念を抱く方もいるでしょう。しかし、個人的にはむしろ積極的に社外キャリアを一緒に考える方が、長期的に良い関係を築けると信じています。 QAエンジニアが抱える不安 私は他社でQAエンジニアをされている方から相談をいただく機会があるのですが、その中で「今の自分の仕事は、本当にQAとして正しいのか？」「他の会社ではどうしているのか？」といった不安を感じている方が少なからずいらっしゃいます。自社だけでQAエンジニアの基準や業務を考えると、どうしても視野が狭くなりがちです。このときにやるべきことは、 世の中全体のQAの動向を把握し、その中で自分たちがどのような立ち位置にあるのかを理解すること だと考えます。 他社では開発チームとQAチームが完全に分かれているところもあるらしい ウチでは開発者がE2Eテストを書いているけれど、QAエンジニアが書いているところもあるらしい など、いろいろなパターンのQA組織・QAエンジニアの業務スコープがあると知ることも、とくにジュニアなメンバーにとっての安心感につながります。世の中のQAのトレンドや、最先端の技術、他の企業での取り組みを知ることで、自社の活動を相対的に把握できます。これは優劣をつけるのではなく、あくまでも「状況に応じて正解がいろいろある」と知ることが大事、という意味です。 その結果「自社ではスコープ外になっているけれど、どうしても挑戦したい領域がある」というメンバーがいて、残念ながらチームや会社を離れてしまうこともあるかもしれません。チームを立ち上げている身としてはつらいところですが、これは受け入れるしかありません。自社のQAエンジニアとしての未来に不安を抱えたまま退職をされるよりは、前向きなチャレンジのためにと巣立ってもらうほうがよい、と捉えましょう。 チームを立ち上げる側の役割 世の中のQA組織の形やQAエンジニアの仕事の動向≒「全体感」をメンバーに持ってもらうためには、チームを立ち上げる側の努力が必要です。 組織を立ち上げるQAエンジニア本人が世の中の動向を把握し、最新の知識をアップデートしておく必要があります。ただし、すべてを把握した上でメンバーに教えようと考えると大変です。QAチームを立ち上げる側がざっくりと掴んだ情報を伝えつつ、一緒に解像度を高めていくというイメージで、メンバーのキャリアを支援することが望ましいでしょう。JaSSTなどのイベントに一緒に参加して他社と情報交換しつつ全体感を捉えるのもよいですね。 社内・社外両面でキャリアパスをフォローする QAチームを立ち上げる際には、メンバーの社内外でのキャリアパスをともに考え、長期的な成長を支援することが重要です。 社内のキャリア：チームのビジョンを定め、進むべき方向の選択肢を提示する 社外のキャリア：業界全体の動向を共有し、自分たちの位置づけを把握してもらう という両面でフォローすることで、メンバーの成長にも繋がり、結果としてQAチームが強化されるでしょう。 【連載】QA組織の立ち上げ方－1人目QAが語る実践と工夫－ 記事一覧 【第1回】QA組織立ち上げの流れと組織の形 【連載初回、全文公開中】 【第2回】2人目以降のQAエンジニアの採用 【第3回】QAチームビルディング 【第4回】QAと開発者とのコミュニケーション 【第5回】QAチームにおけるキャリアの作り方 The post 【第5回】QAチームにおけるキャリアの作り方｜QA組織の立ち上げ方 first appeared on Sqripts .

こんにちは、AGESTでエンジニアをしているタカです。 今回は、最近話題のAI活用型コードエディタ「Cursor」のComposer機能を使って、簡単なNext.js製Webアプリケーションを開発し、CI/CDパイプラインを構築してGoogle Cloudの環境にデプロイする、という一連の流れに挑戦します。 目的は、個人的にCursorの操作に慣れることと、直近で触れていなかったGoogle Cloudの設定やCI/CD周りの知識を思い出すことです。実践を通して、これらのスキルをブラッシュアップできればと思っています。 ちなみに、CursorエディタやComposer機能の基本的な使い方については、2024年10月に公開されたこちらの記事で詳しく解説していますので、併せてご覧ください。 CursorのComposer機能でAIに0からテストコードを作成してもらう こんにちは、AGESTのバックエンドエンジニアのまさです。今回は、CursorエディタのComposer機能を用いて、AIにテストコードを記述してもらう方法をご紹介します。テストコードはソフトウェアの品質を高めるために重要ですが、手作業で書くのは時間がかかるものです。... 　続きを読む　 Sqripts 関連記事｜Sqripts Webアプリケーションのシステム構成について 今回は、あくまでCursorを使った開発に焦点を当てたいので、Google Cloud上のインフラ構成は、できる限りシンプルにすることを意識しました。具体的には、以下のような構成で進めます。 CI/CDパイプラインはGitHub Actionsで構築:  アプリケーションのビルド、テスト、デプロイはGitHub Actionsを使って自動化します。 アプリケーションはCloud Runに直接デプロイ:  Container Registryを経由せず、Cloud Runに直接デプロイします。これにより、手順を簡略化します。 Load BalancerやCloud Armorは使用しない:  これらの機能も便利ですが、今回は扱う範囲が広くなりすぎてしまうため、見送ります。必要に応じて、今後の記事で取り上げたいと考えています。 IaC (Infrastructure as Code）は使用しない:  今回はTerraformなどのIaCツールは使用せず、手動で設定を行います。 開発環境については GitHub Codespaces 上に構築: ローカル環境を汚さず、かつ、どこからでも同じ環境で開発できるようにする プロンプト1（Webアプリケーション） さて、ここからは実際にCursorにコード生成を依頼してみます。まずは、どのようなプロンプトでコード生成を依頼したのか、その内容と結果について掲載します。 初回は、以下のようなプロンプトで、Cursorの生成AIモデルとしてgpt-4oを指定して依頼してみました。 Webアプリケーションを構築したいです。 以下の条件でファイルの生成や手順を提示してください ----------------------------------- # リポジトリ * GitHubで作成したリポジトリをcloneしてcursorで現在開いています。ファイルを作成してください。 * gitの操作は把握済みなので、commit、pushなどは自分で行います。手順から省いてください。 # 開発環境 * GitHub CodeSpacesを使用します。 * ローカルのIDEはCursorを使います。CursorからGitHub CodeSpacesの接続手順を提供してください。 # アプリケーション * Next.jsで構築してください。まずはデフォルトで良いので、コマンドでの構築手順を提供してください * 今後、データベースやAPIのサーバーを立てる可能性がありますが、今回は不要です。 # インフラ * DockerコンテナにてWebアプリケーションを立ち上げてください * いずれTerraformでインフラ管理を行いますが、今回は不要です。 # 本番環境 * Google Cloud の Cloud Runにデプロイを行います。東京リージョンを使用してください。 * GitHub Actionsのワークフローを作り、CI/CDを行ってください。 * デプロイのために必要なシークレットの情報を提供してください。権限情報が必要だと思います。 ----------------------------------- プロンプト1の出力結果 生成された出力結果を全て貼り付けると長いため、ここでは概要のみ掲載します。以降の記事で必要に応じてキャプチャを掲載します。 1. Next.jsアプリケーションのセットアップ npx create-next-app@latest 2. GitHub CodeSpacesのセットアップ GitHubリポジトリで「Code」ボタンをクリックし、「Open with Codespaces」を選択します。 新しいCodespacesを作成するか、既存のものを選択します。 3. Dockerコンテナの設定 4. GitHub ActionsによるCI/CDの設定 5. 必要なシークレット情報 GCP_SA_KEY: Google Cloudのサービスアカウントキー（JSON形式） GCP_PROJECT_ID: Google CloudのプロジェクトID** この出力結果を見ると、少し順番を前後させた方が良い箇所もありますが、概ねやりたいことは実現できそうです。 プロンプト1で自動生成されたファイル 3、4の手順では、Cursorにより、 ファイルが自動生成 されました。以下に内容を記載します。 # ベースイメージ FROM node:16 # 作業ディレクトリの設定 WORKDIR /app # package.jsonとpackage-lock.jsonをコピー COPY package*.json ./ # 依存関係のインストール RUN npm install # アプリケーションのソースをコピー COPY . . # ビルド RUN npm run build # ポートの設定 EXPOSE 3000 # アプリケーションの起動 CMD ["npm", "start"] Dockerfile name: Deploy to Cloud Run on: push: branches: - main jobs: build: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v2 - name: Set up Cloud SDK uses: google-github-actions/setup-gcloud@v0 with: project_id: ${{ secrets.GOOGLE_CLOUD_PROJECT_ID }} service_account_key: ${{ secrets.GOOGLE_CLOUD_SERVICE_ACCOUNT_KEY }} - name: Deploy to Cloud Run run: | gcloud run deploy my-nextjs-app --source . --region asia-northeast1 プロンプト2（動作確認手順） プロンプト1では、アプリケーションに必要なファイルの生成に成功しましたが、動作確認の手順については言及されていませんでした。そこで、今回は動作確認に焦点を当てたプロンプトを作成し、Cursorに追加で指示を出します。 以下に、今回使用したプロンプトの全文を記載します。 開発の方法として段階を踏んで動作確認を行いたいと思います。 * まずは、CodeSpaces上でアプリケーションの構築を行ったうえで、 Dockerコンテナを起動し、ブラウザでエンドポイントにアクセスして表示が問題ないことを確認します。 * 次にワークフローを構築しますが、動作確認をCodeSpaces上でactというツールで行いたいです。 * 動作確認が問題なければ、mainブランチにマージしてワークフローを動かして Google Cloudにデプロイします。 これらのコマンドなどを示してください プロンプト2の出力結果 生成された手順は少し長いため、ここでは概要のみを掲載します。 1. CodeSpaces上でのアプリケーション構築と確認 2. Google Cloud Runへの手動デプロイ 3. GitHub Actionsワークフローの設定とローカルテスト 4. Google Cloudへのデプロイ この動作確認手順に従って、以降の記事を進めていきます。 1. CodeSpaces上でのアプリケーション構築と確認 CodeSpacesへのアクセス まずは、GitHub Codespaces上に開発環境を構築し、そこでNext.jsアプリケーションのセットアップと動作確認を行います。 GitHub Codespacesの起動は、本来であれば、Cursorのリモートエクスプローラーから行えるはずでした。 しかし、残念ながらこの記事の執筆時点では、CursorからGitHub Codespacesへの接続がタイムアウトしてしまい、正常に動作しませんでした。 そのため、今回は代替策として、ブラウザでGitHub上から直接Codespacesを作成してログインすることにしました。コードに関してはCursor上でpushし、ブラウザのCodespacesでpullするという流れになります。 Next.jsアプリケーションの起動と Dockerビルドエラーへの対処 続いて、Next.jsアプリケーションのセットアップを行い、Dockerコンテナを起動してみます。今回は、Next.jsのデフォルトアプリケーションをそのまま利用したため、セットアップ自体は非常に簡単でした。 ただし、Dockerコンテナの起動ではビルドエラーがいくつか発生したため、エラーメッセージをCursorに貼り付け、解析と自動修正を行いました。 なお、本来Cursorでは、キャプチャ画像に表示されている「 Run」アイコンをクリックすることで、自動的にコマンドを実行しますが、今回はブラウザのCodeSpacesが開発環境のため npx や docker コマンドをコピー&ペーストして実行しています。 結果として、初期生成のDockerfileから自動修正した差分は以下の通りとなりました。 # ベースイメージ - FROM node:16 + FROM node:20 # package.jsonとpackage-lock.jsonをコピー - COPY package*.json ./ + COPY my-app/package*.json ./ # アプリケーションのソースをコピー - COPY . . + COPY my-app/. . また、参考までに、ディレクトリ構成は以下のようになりました。 赤字がCursorでの自動生成ファイル、青字がnpxコマンドで生成されたNext.jsのアプリケーションファイルです。 . ├── .github │ └── workflows │ └── deploy.yml ├── Dockerfile ├── README.md └── my-app ├── README.md ├── eslint.config.mjs ├── next.config.ts ├── package-lock.json ├── package.json ├── public │ ├── file.svg │ ├── globe.svg │ ├── next.svg │ ├── vercel.svg │ └── window.svg ├── src │ └── app │ ├── favicon.ico │ ├── globals.css │ ├── layout.tsx │ ├── page.module.css │ └── page.tsx └── tsconfig.json 今回はシンプルな構成のため、Cursorで生成されるファイル数は少ないですが、仮にTerraformでインフラの管理を行う場合などは、生成するファイルが増え、Cursorの力が発揮される場面が増える見込みです。 2. Google Cloudへの手動デプロイ アプリケーション起動が確認できたので、次はCodeSpaces上からGoogle Cloudへ手動デプロイします。手動デプロイの手順についてCursorに出力を指示したところ、以下のような手順が提示されました。 1. Google Cloud SDKのインストール 2. Google Cloudにログイン: gcloud auth login 3.プロジェクトの設定 gcloud config set project YOUR_PROJECT_ID 4. Cloud Runへのデプロイ gcloud run deploy my-nextjs-app --source . --region asia-northeast1 Google Cloud SDKのインストール gcloudコマンドを利用するため、まずはGoogle Cloud SDKをインストールする必要があります。インストール手順については、 Google Cloud公式サイト を参照し、apt-getやcurlなどのコマンドを利用して、CodeSpacesにインストールを行います。 CodeSpaces上での実行のため、手順1.と同様に、Google Cloudへのログイン、プロジェクトの設定、Cloud Runへのデプロイコマンドを、コピー&ペーストで実行しました。 デプロイ完了後に、表示されたURLにブラウザでアクセスしたところ、無事にアプリケーション画面が表示されることを確認できました。 3. GitHub Actionsワークフローの設定とローカルテスト 次はいよいよGitHub Actionsを使ったCI/CDパイプラインの構築に取り掛かります。 シークレットの設定 まずは、GitHub ActionsでGoogle Cloudにアクセスするために必要なシークレットを手動で設定します。具体的には、以下の2つをGitHubリポジトリのSecretsに登録します。 Google CloudプロジェクトID Google Cloudサービスアカウントの秘密鍵 なお、サービスアカウントの作成と秘密鍵の取得は、Google CloudのIAM（Identity and Access Management）の画面から行います。 サービスアカウントのロールは、Cloud Run関係で充分かと考え、まずは下記を割り当てました。 この時点でサービスアカウントに割り当てたロール actでのワークフロー動作確認 GitHub Actionsのワークフローは、設定ミスがあると何度もトライ＆エラーが必要になることが多いです。そこで今回は、CodeSpaces上でactというツールを使って、ワークフローのローカルテストを行うことにしました。 actを使うことで、GitHub Actionsのワークフローをローカル環境で実行でき、本番環境への影響を最小限に抑えて動作確認を進めることができます。 https://github.com/nektos/act インストールと設定は以下のコマンドを実行しました。 $ curl -s <https://raw.githubusercontent.com/nektos/act/master/install.sh> | sudo bash $ ./bin/act --secret-file .secrets ※実行して表示される選択肢は Medium を選択。 実行コマンドのオプションですが、actでシークレットを使うためには、 .secrets というファイルを作成し、そこにシークレットを記述した上で、–secret-fileオプションで読み込ませる必要があります。 actの動作確認と修正 動作確認で判明しましたが、最初に設定したサービスアカウントはロールが不足しており、エラーが発生したため、このエラーログをCursorに貼り付け、解決を試みました。 Cursorは、具体的なロール名を直接教えてくれるわけではありませんでしたが、関連する情報を提供してくれたため、Google Cloudのコンソール画面でのロール検索や公式ドキュメントを参照して、以下の画像のロールをサービスアカウントに割り当てることで解決しました。 最終的に、actでワークフローを実行した際のデプロイログは以下の通りです。 [Deploy to Cloud Run/build] 🐳 docker exec cmd=[bash -e /var/run/act/workflow/2] user= workdir= | Building using Dockerfile and deploying container to Cloud Run service [my-nextjs-app] in project [***] region [asia-northeast1] | Service [my-nextjs-app] revision [my-nextjs-app-00002-zs9] has been deployed and is serving 100 percent of traffic. | Service URL: <https://my-nextjs-app-346239942346.asia-northeast1.run.app> [Deploy to Cloud Run/build] ✅ Success - Main Deploy to Cloud Run [Deploy to Cloud Run/build] ⭐ Run Post Set up Cloud SDK [Deploy to Cloud Run/build] 🐳 docker exec cmd=[/opt/acttoolcache/node/18.20.5/x64/bin/node /var/run/act/actions/google-github-actions-setup-gcloud@v0/dist/post/index.js] user= workdir= | Skipping credential cleanup - "export_default_credentials" is false. [Deploy to Cloud Run/build] ✅ Success - Post Set up Cloud SDK [Deploy to Cloud Run/build] Cleaning up container 注意点:  actでワークフローを実行すると、実際にGoogle Cloudへのデプロイまでが行われます 4. GitHub Actionsによる自動デプロイ actを使ったローカルテストでワークフローの動作確認が完了したので、最後にGitHub Actionsによる自動デプロイを実行します。 mainブランチへのpushをトリガーとしてCI/CDパイプラインが動き、アプリケーションがGoogle Cloudに自動でデプロイされることを確認しました。 おわりに：AIを活用した開発を振り返って 開発スピードと効率の大幅な向上 今回の開発を通じて、AIを活用することで、トライ&エラーのサイクルを高速に回せるようになったことを実感しました。 特に、コード生成やエラー解決において、Cursorが強力なサポートツールとして機能したことで、開発スピードが向上し、効率的な開発が可能になったと感じています。 AIの活用には基礎知識が不可欠 一方で、AIを効果的に活用するためには、開発者自身にも一定レベルの基礎知識が必要であることを改めて認識しました。 例えば、GitHubへのコードpushや手順3のGoogle Cloudでのユーザープロファイル生成など、セキュリティ上の理由から、人間が介在する必要がある操作は依然として存在します。 また、AIが生成したコードをそのまま使用するのではなく、内容を理解し、必要に応じて修正する能力も必要になります。 AIは開発の強力な「補助輪」 今回の経験から、AIは開発の「丸投げ」ではなく、あくまで「補助輪」であるという認識を強くしました。 AIは、開発者の作業を大幅に効率化してくれる一方で、 最終的な判断 や 責任 は依然として開発者が担う必要があります。このため、AIの得意なことと苦手なことを理解し、適切な役割分担を行うことが重要となります。 最後に 今回の記事では、特にソースコードの生成や、エラーの解決をCursorによって効率的に行うことができました。CodeSpaces上での実行のため、ソースコードはpushとpull、コマンドはコピー&ペーストという手間を挟みましたが、本来は生成されたコマンドを直接実行することが可能です。 Cursorを活用する中で、当初の目的だった直近で触れてこなかった技術領域の知識を思い出し、また、更に知識を深めることができたと実感しています。 今後、AIにどこまでを任せ、どこからを人間が担当するのか、その境界線は変化していくとは思います。しかし、AIによって開発の学習コストが大幅に下がったことは間違いないので、今後もAIを賢く活用し、より効率的で創造的な開発を目指していきたいと思います。 The post Cursorで手軽にWebアプリ開発！AIアシストで自動デプロイを実装 first appeared on Sqripts .

みなさんこんにちは。 「ソフトウェアレビューをエンジニアリングっぽく捉える会」 の”きたのしろくま”です。 これから6回に渡って「ソフトウェアレビュー」についてのリレー投稿を開始します。 私たちは何者か？ 私たち「ソフトウェアレビューをエンジニアリングっぽく捉える会：Software Review Engineering Explorers／SReEE(スリー)（以降、SReEE、とします）」は、2017年頃から月一度のペースで「ソフトウェアレビューをエンジニアリングっぽく捉える」ことを目指してあれこれ議論をしています。 実務におけるレビュー実践事例やカンファレンスでのレビュー関連の発表内容～メンバーがとある出来事で感じたことなど議論する題材はいろいろです。 私たちの関心事に対する議論がある程度まとまって話ができる状態になったり、発信したいメッセージが明確になった時点でソフトウェアレビューシンポジウム（JaSST Review）に組み込むなどして情報を発信してきました。 【参考：最近のソフトウェアレビューシンポジウム（開催レポート）】 JaSSTソフトウェアテストシンポジウム-JaSST Review'23-レポート 　詳細はこちら　 www.jasst.jp 関連情報 JaSSTソフトウェアテストシンポジウム-JaSST Review'22-レポート 　詳細はこちら　 www.jasst.jp 関連情報 JaSSTソフトウェアテストシンポジウム-JaSST Review'21-レポート 　詳細はこちら　 www.jasst.jp 関連情報 そう、私たちはJaSST Review実行委員会のコアメンバーでもあるのです。 どのような内容なのか？ このリレー投稿では、研究会で議論した結果を、、、いや、議論中（過程）の内容を発信します。 まだ検討過程なので、研究会としての統一見解や確定した内容を発信するものでもありません。 レビューは自由度が高く、対象範囲も広いため、おぼろげながら全体像が見えてきた（と思っているだけかもしれない（汗））、、、という状態。 このままではいつまで経っても世に情報が発信できない。ということで今回は、投稿を担当するメンバーが、それぞれの担当テーマに対する自らの認識や想い、自分なりの整理を記述することにしました。 そのため、投稿した記事間の整合が取れない部分が発生する可能性があることにご留意ください。 実験的にわれわれの考えを世に送り出してみなさんからの（そして、投稿後に自ら気づくｗ）フィードバックがあれば必要に応じて見直す。これを繰り返して内容の精度を上げていく「公開レビュー＆手直し方式」を採用した投稿となっています。 よって、一度公開した記事も適宜見直していく可能性があります。 この投稿を通じてみなさんと対話でき、私たちが気づかなかったことを認識できることも楽しみにしています。 投稿予定コンテンツ 現時点で投稿を予定しているコンテンツと担当者を以下に示します。 記載順に投稿していくのではなく 、それぞれの担当者の準備ができ次第投稿することになります。 毎回次に何が出るかはお楽しみにしてください。 ※（）内はXアカウント名です。 #0 イントロダクション （←いまココ）：きたのしろくま（ @kitanosirokuma ） #1 レビューとは？ ：うれっしー（ @ureshino66 ） #2 何のためにやるの？ ：弦音（ @tulune ） #3 レビューの観点 ：ブロッコリー（ @nihonbuson ） #4 レビューファシリテーション ：ぱいん（ @pineapplecandy ） #5 レビュー評価・ふりかえり ：きたのしろくま（ @kitanosirokuma ） #6 まとめ ：ブロッコリー（ @nihonbuson ） 当投稿におけるレビューの全体像と用語定義 現時点で私たちがレビューをどのように見ているかを示します。 図１：当連載におけるレビューの全体像 今回はこの図をベースにリレー投稿を行います。 図1に示した要素を簡単に説明しておきます。 レビュープロセス ： 「ISTQBテスト技術者資格制度Foundation Levelシラバス」で示されている作業成果物のレビュープロセス レビュー思考プロセス ： レビュープロセスのうち、レビュー対象をどのように確認して結果を出力するのか？を実践する部分を切り出したもの（レビューをエンジニアリングっぽく捉えるメイン対象がこちらです）。 レビューマネジメントプロセス ： レビュープロセスのうち、レビューを計画し、実施状況を把握し、実施結果を判定する部分を切り出したもの。 レビューに関わる関係者 ： レビュープロセス群に関わる関係者のうち、今回の投稿で取り扱う方たち。 レビューア ： レビュー対象を確認して結果を示す人。主にプロジェクトに携わっている人、特定分野の専門家、その他のステークホルダー等であることが多い。 作成者 ： レビュー対象の作業成果物を作成し、修正する人。 ファシリテーター ： 調整、時間のマネジメント、誰もが自由に発言できる安全なレビュー環境など、レビューミーティングを効果的に運営する人。 おわりに 当初から一緒にソフトウェアレビューについて議論してきた電気通信大学の西康晴さん（以降、にしさん、とします）が2023年に急逝されました。しばらくはその事実を受け入れられず途方に暮れていましたが、にしさんの意思を引き継いで議論を再開・継続しています。 もともとはにしさんの呼びかけで始まった会ですので、今回の投稿はにしさんなくしては語れない内容であることをお伝えしておきます。 では、このあと投稿を開始しますのでよろしくお願いします。 参考情報 　ISTQBテスト技術者資格制度　Foundation Level シラバス 日本語版 Version 2023V4.0.J02 この記事を担当したメンバー きたのしろくま（安達　賢二） 自律・自己組織化を促進する価値共創プログラムSaPIDをベースに三方よしとなる新しい価値を一緒に考えて創る「共創ファシリテーター」として活動中。 https://www.softwarequasol.com/ The post ［#0］イントロダクション｜ソフトウェアレビューをエンジニアリングっぽく語ってみる first appeared on Sqripts .

はじめまして、クオリティマネージャーのヒロたです。シフトレフトの有効性は皆さんもご存じのことと思いますが、本日は単体テストについて考慮する点と良い単体テストについてご紹介します。 単体テストとは 単体テストはシステム開発におけるテスト工程の一つで、結合テストや総合テスト（システムテスト）、運用テストの前に行われるものです。つまり、テスト工程で最初に実施するテストということになります。主に開発者が行い、各関数やメソッドの動作を確認するために使用されます。一般的には、少ないコードでテストすることから不具合の原因を特定しやすく修正も容易になります。プログラミングを担当した開発者がプログラムを組んだ直後に実施できることから、その機能がどのような動作をするべきかというイメージが鮮明な状態でテストが行えるため、精度の高い検証効果が期待できます。 単体テストのメリット 単体テストの結果、意図した動作をしないことがわかった場合に単体テストが最小単位で行われることから、問題の個所の特定や修正がしやすい。 開発全体のバグ修正コストを下げる効果が高い。 低コストで短時間で結果が得られる。 テストフレームワーク ※1 を使ってテストの自動化が可能。 ※1　 Java アプリケーションのJUnit、.NETアプリケーションのNUnitなど自動実行がサポートされています。 単体テストのデメリット テストコードを作成するのに工数がかかる テストコード自体は、自動化できないのでコーディング担当者が、一つひとつ作成しなくてはならない。 テストの精度が実施者のスキルに依存する テスト項目の策定にはスキルが必要となる。制御フローテストでは多くのテストパターンを試す必要があるが、時間は限られているためいかに最適なパターンを作成し、組み合わせるかが重要になる。 テストカバレッジ（網羅率）とソフトウェア品質 単体テストでは網羅率という指標がよく使われます。全体のソースコードに対してどれだけがテストされたかを見る指標になります。 コード網羅率　＝　実行されたコードの行数　/　総行数　（0-100%の範囲で算出） 数値化された指標は、全体を把握する上で必要ですが、数値だけに頼りすぎるとテストの質（中身）を見誤ってしまいます。 単体テストの完了条件として「C0/C1カバレッジ100%」となっているプロジェクトを見かけます。カバレッジが高ければ、ソースコードの品質が高いと言えるでしょうか。カバレッジが100%でも、テストケースが正しく作成されていなければ、バグが潜在している可能性を低くすることはできません。バグを適切に検出できるテストケースを作るにはスキルが必要です。 では、バグを適切に検出できずに潜在させてしまうテストケースとはどのようなものなのでしょうか。「Google Testing Blog: TotT: Understanding Your Coverage Data」も参考にアンチパターンをいくつか考えてみましょう。 アンチパターンその1 　 配列のインデックス範囲外アクセス java int[ ] array = new int[5]; int value = array[5]; // インデックス5は範囲外 テストケースがarray[0]からarray[4]までのインデックスをテストしている場合、C1カバレッジは100%になりますが、インデックス5にアクセスするテストケースがないと、配列の範囲外アクセスによるバグを見逃すことになります。 アンチパターンその2 　 null参照の処理 java String str = null; int length = str.length(); // null参照によるNullPointerException strが非nullの状態でのテストケースのみを実施していると、C1カバレッジは100%になりますが、strがnullの場合のテストケースがないと、NullPointerExceptionを引き起こすバグを見逃すことになります。 アンチパターンその3 　条件分岐の境界値 java int score = 85; if (score >= 90) {     // A評価 } else if (score >= 80) {     // B評価 } scoreが85の場合のテストケースだけを実施していると、C1カバレッジは100%になりますが、境界値である90未満や80未満のテストケースがないと、評価のロジックに潜むバグを見逃すことになります。 これらの例は、テストケースが特定の条件や境界値に対して不十分である場合に、潜在的なバグを見逃すリスクを示しています。テスト設計においては、さまざまな入力や条件を考慮する必要があります。 良い単体テストとは さて、良い単体テストとは、どんなものなのでしょう。Vladimir Khorikovは「Unit Testing Principles、 Practices、and Patterns」にて、次のように述べています。（「単体テストの考え方/使い方 」 2022 須田智之 訳） 良い単体テストとは、ソフトウェア開発プロジェクトを持続可能なものにすること。本書では、コードを資産ではなく、負の遺産として捉えています。プロダクションコードのコードベースに何らかの変更を加えることは、コードベースのエントロピー（無秩序の量）を増やします。コードの整理やリファクタリングをなどの適切な処置を常にしていなければ、そのソフトウェアはすぐに複雑になり秩序がなくなってしまいます。そうなると１つのバグを修正することが、より多くのバグを生み出すことになったり、他の部分が機能しなくなったり、ドミノが次々と倒れる状況に陥ります。しかし、テストを用意しておけば、それを防げます。テストがあることで、コードによる退行（regression）を検出することができるのです。 「単体テストの考え方/使い方 」 2022 須田智之 訳 本書では、良い単体テストについて以下のことが提案されています。　 ・プロダクションコードのリファクタリングに伴って、テストコードをリファクタリングすること ・プロダクションコードを変更するたびにテストを実施すること ・テストが間違って失敗した際にその対処をすること ・プロダクションコードの振る舞いを理解するためにテストコードを読むこと コードが増えれば、ソフトウェアにバグが持ち込まれる経路が増えることになり、プロジェクトを維持するコストもさらに高くなる。この問題を解決するためには、コードを最小限にすべきである。テストコードも同様でバグに対して脆弱であり、保守を必要とするものである。 「単体テストの考え方/使い方 」 2022 須田智之 訳 さて、どの様にテストの質をあげればいいのでしょう。何を単体と見做すかは、それぞれのプロジェクトによって様々だと思いますが、単体テストにおける「単体」を1単位のコードでなく1単位の振る舞いにするよう推奨されています。そして、テストケースを1つずつ評価して、本当に必要なテストケースと不必要なケースを識別して、テストスイートには必要なケースのみを残して、他のテストケースは削除する作業が必要です。優れたテストスイートとは次のようなものです。 テストが開発サイクルに組み込まれている コードベースの特に重要な部分のみがテスト対象になっている 最小限の保守コストで最大限の価値を生み出すようになっている コードベースのすべての部分が単体テストをする価値を持っているわけではありません。ほとんどのアプリケーションにおいて核となる部分はビジネス・ロジックを含む部分です。テストに費やした時間が最も効果的な箇所に重きを置いてテストするべきです。因みに重要でないコード ※2 とは次の様なものです。 インフラに関するコード 外部サービスや依存関係のあるもの（データベースやサードパーティーのシステム） 構成要素同士を結び付けるコード ※2　例に挙げたコードは、単体テストのフェーズでは、優先度は低いため重要でないコードと表現しましたが、これらの部分は統合テストや結合テスト、またはエンドツーエンド（E2E）テストなどで十分に検証する必要があります。 では、単体テストの良しあしをQA視点では、どのように見るのでしょうか。ソフトウェアの品質保証は、各テストフェーズの断面で保証する部分とトータルで保証する部分があります。単体テストでは、ひとつの振る舞いを検証しますが、システムの外部品質の保証は出来ません。少なくとも言えることは、単体テストにビジネスロジックの観点が網羅されている。間違った理由でテストに失敗することが少ない。テストに時間がかかりすぎていない。かの確認はレビューしましょう。テストフェーズは、結合テスト、統合テスト（システムテスト）、運用テストと続きます。単体テストで担保するもの、その後のテストフェーズで確認すればいいものを識別して、テストフェーズのトータルでソフトウェアの品質を高めていきましょう。 さいごに 本投稿では、単体テストについての考え方を紹介しました。カバレッジは、意味がないとまではいいませんが、たとえ単体テストのカバレッジ100%を達成したとしても、ソフトウェア品質が保証されたわけではありません。実際の品質保証にはテストの内容と深さを考慮する必要があります。皆さんがそれぞれ現場で実践してみて下さい。 最後まで読んでくださってありがとうございました。 出典 「ソフトウェア品質を高める開発者テスト」高橋寿一著　翔泳社 「単体テストの考え方/使い方 」 Vladimir Khorikov, 須田智之　マイナビ出版 「Unit Testing Principles、 Practices、and Patterns」Vladimir Khorikov (著) 参考情報 「Google Testing Blog: TotT: Understanding Your Coverage Data」 The post 単体テストについて ～テストの質を考えてみた～ first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 【第1回】見つけるための論理｜実務三年目からの発見力と仮説力 帰納的な推論 と 発見的な推論(アブダクション) は、私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意す... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回からしばらくは、 帰納的な推論 の考え方を見ていきます。 今回は帰納的な推論の“おさらい”と、いくつかある「形」の紹介です。 帰納的な推論とは 共通項を見つけて一般化する 図2-1 帰納的な推論 図2-1は、以下の特徴を持つ帰納的な推論の例です。 一般化 (A)(B)とも、有限個の 事例に“共通項” (共通する属性、特徴、法則性、etc.)を見出し、 「夕焼けが見られた日」全体や「着飾って出かけた場合」全体に 一般化 しています。 蓋然的 (A)は過去に観測した天候、(B)は自身の過去経験という 有限個の事例から全体に 話を広げており、“間違い”の可能性を含みます。 （当てはまらない場合を見落としている、未来の新たな事例には当てはまらないかも知れない、etc.） “ 共通項 ”とは次のようなものごとを指します。「見てすぐわかる」ものばかりでないこともあります。 共通する属性、特徴。 「事例にはすべてAという属性や特徴が見られる」 共通する法則性(相関関係、因果関係、etc.)。 「事例がPという属性/特徴を持っている時は、必ずQという属性/特徴も具えている」 「事例にPという事象があった場合、必ずQという事象を生じている」 法則性については、「共通している」からといって本当に関係があるかどうかは深く調べないと判らない点に留意しましょう（隠れた要因が存在する「擬似相関」かも知れませんし、「偶然の一致」であることもあり得ます）。 一般化の原理 帰納的な推論では、前提と結論との間に必然的な関連がない以上、事例や一般化される共通項には“納得感”――「確かに共通しているものがある」「確かにすべての場合に言えそうだ」と思えることが求められます。 前提で取り上げる事例が恣意的なものでないなら、納得感は強い （対象全体から偏りなく選ばれたものなら、なお好ましい） 共通項は事例にとって偶然的なものでなく、本質的・必然的な関連があると、納得感は強い 後者の「本質的・必然的な関連」には 自然の斉一性 や 因果性 が根拠になります（どちらも、私たちが知らず知らず当てにしている考え方です）。 自然の斉一性 ：自然現象には法則性があり、同じ現象は、同じ条件の下でなら同じように起こる、と見る考え 因果性 ：ある現象/性質/属性/特徴/etc. には、それを生じさせた原因がある、とする考え 図2-1の例では、(A)は過去何度も観測した出来事を事例としており、偏りも小さそうです。見出した「法則」は自然現象として因果関係が説明可能で、“納得感”は強いでしょう。 (B)は、事例に偏りはないかも知れませんが、数が気になる（少ないのでは？）ほか、印象が強かったことを選択的に記憶している可能性があります （たとえば、デートでは雨に降られたことがないが、それがいつものことなので記憶に残っていないのかも知れない）。 また、「着飾って外出すること」と「雨に降られる」こととの間には、(A)ほどの必然的な関連はないでしょう。 (A)に比べると“納得感”は弱いと言えます。 帰納的推論の形 事例を挙げて、共通項を見出し、対象全体に一般化する筋道にはいくつかの考え方があります。 次の章から見ていきましょう。 完全枚挙　――事例をすべて列挙する 有限の事例をすべて列挙 し、それらの共通項を一般化することを 枚挙的完全帰納法 といいます。 図2-2 すべて列挙し、“一般化”する 形は帰納的な推論ですが、「一般化」の観点からすると帰納らしくありません。 対象の事例を 全網羅 できたなら、それは 「全称判断の演繹的推論」と同じ と言えます 「すべての事例には共通項Pがある。従って、すべての事例には共通項Pがある」と 言っているわけで、 一般化も何も「判っていることを言い直している」に過ぎず、 前提から結論に何の飛躍もなく、「新たな発見」も感じられません 以上から、帰納的推論である意味が薄いと言えます。 枚挙的帰納　――帰納的推論の“基本形” 有限の不完全な列挙から結論を導く 図2-3 枚挙的帰納の例 図2-3の(A), (B)とも、 有限の事例の列挙 から 共通項 を見出し、それを 一般化 して： (A)では「入力欄はすべてある特殊文字を入力した時にフリーズする（すべての事例は共通項Pを持つ）」という結論を、 (B)では「ソフトウェアXは、ソフトウェアZがプリインストールされている機種なら必ず故障Fを起こす（すべての事例において、共通項Pを持つものは必ず共通項Qを持つ）」 という結論を、 それぞれ引き出しています。 このような、有限の不完全な列挙から結論を導くものを「 枚挙的帰納 」といい、帰納的推論の基本的な形です。 蓋然性の度合い 帰納的推論の蓋然性(結論が当てはまる確からしさ)の度合いは、前提で挙げられる事例の質と量に依存します（参考：『論理学入門』）。 ① 事例の数 。多い方が結論の蓋然性は高い ② 事例どうしの類似性 。 互いの共通点が多い方が蓋然性は高い ③ 事例の多様性 。事例の数が多いならば、 事例間の類似性が低い(多様性が高い)方が蓋然性は高い 「③多様な(偏りのない)事例を、①多く集めた上で、②なお類似点が多いなら、蓋然性はより高い」ということです。 （「一般化の原理」の節も参照してください） 図2-3の(A)では、「入力欄(入力項目)」「特殊文字」という類似性があります(②)。 10箇所が多いか少ないかは議論の余地がありますが(①)、 テスト視点でなら「疑うには十分」と感じる人が多いでしょう。 （「調べ過ぎ」と感じる人もいると思います。何個遭遇したら「怪しい！」と思うか、アンケートを取ってみたいですね） (B)では、テスト用に保有しているいちごフォンのバリエーションという類似性と多様性があります(②③)。 （世の中に実際に存在するバリエーションをすべて揃えることは現実的に困難なので、代表的なもの、最も普及しているものなどを中心に揃えることが多いでしょう） なお、どちらの例でも、得られた結論はいわば「仮説」であり、その正しさを評価するにはさらに事例を調べたり、実験したり、詳しく論証したりする必要があります。 評価した結果、「実際にはそうでなかった」という、“間違った”推論と判明する可能性があります。 統計的帰納 割合や傾向を推論する 事例に見てとれる“共通項”の割合/傾向を踏まえて、 対象全体の中で 共通項を持つものの 割合 や 傾向 を推論する、という形があります。 図2-4 統計的に推論したい 図2-4では、同じクラスの生徒が特定の機種のスマートフォンを所持する割合から、「学校全体」における所持の傾向を推し量っています。 クラスの中での所持割合を学校全体に広げて考えても相当程度に蓋然性があるだろう、と、A子さんは主張したいわけですね。 もっとも、事例における割合や傾向を全体に広げて考えてよいかどうかは以下の点にかかっています。 事例の数（＝標本の大きさ）。母集団(対象全体)の大きさに対してある程度の大きさであること 事例のランダムさ（＝偏りのなさ）。母集団の特徴/傾向を適切に反映していること 図2-4の例でいうと、1クラス40人という事例の数は、学校全体(数百人はいるでしょう)に対して蓋然性の精度を担保するにはやや物足りません。（無意味ではありません） 事例のランダムさ(偏りのなさ)については、A子さんのクラスの構成や傾向（男女比、機種の好み、etc.）が学校全体に比して偏りがなく平均的なら、学校の生徒全体の傾向と同じと考えやすく、A子さんの推論は蓋然性が高いと言えるでしょう。 そうでなく、学校の生徒全体の構成や傾向に比してクラスのそれが偏っているなら、A子さんの主張は“弱く”なるでしょう（学校全体に対して、A子さんのクラスはいちごフォン好きが異様に多い、など）。 統計の話は本連載の範囲を超えるのでこれ以上踏み込みませんが、統計的な推論の蓋然性を高めるなら、事例の数とランダムさは母集団の大きさに対して適切に定めるのが望ましいと言えます。 統計的一般化 図2-4のA子さんのように、統計的な前提をもとに「全体」へと話を広げるのは 統計的一般化 と呼ばれます。 「事例において、共通項Pを持つものの割合がこうである」から、「対象全体でも、割合はこうである」と一般化します。 統計的一般化の例。 ①この学校の生徒から相当数を無作為に選び、所有するスマートフォンを尋ねたところ、 90%がいちごフォンを所有していた。 ②【結論(A)】この学校の生徒（の90%）はいちごフォンを所有している。 ②【結論(B)】この学校の生徒は（おそらく）いちごフォンを所有しているだろう。 結論(A)は事例における割合を結論に引き継ぐ形、(B)は推量として表現する形です。 (B)の場合、割合が90%なら「きっといちごフォンを所有しているに違いない」という言い方もあるでしょう。 100%なら「いちごフォンを所有している」と断言したくなるかも知れません。 割合が高ければ結論の蓋然性も高いと見込まれ、“納得感”はあります。 そうでなければ“納得感”は弱いでしょう。 割合が50%程度か未満なのに「おそらくいちごフォンユーザーだろう」というのは無理があります。 また、事例における割合が100%であっても、対象全体における実際の割合は100%でないこともあります。 図2-5 統計的一般化 枚挙的帰納とは事例の数と偏りの点で異なる点に注意してください。 枚挙的帰納の例。 ①回りの友達に聞いたら、BさんもCさんもDくんもEくんもFさんもGくんも、全員いちごフォンを持っている。 ②だからこの学校の生徒はいちごフォンを所有している。 統計的三段論法 統計的帰納を用いて、演繹的な定言三段論法に似た形の推論ができます。 統計的三段論法の例。 ①この学校の生徒の90%は、いちごフォンを所有している。 ②いまこの場所にいる生徒は皆この学校の生徒である。 ③【結論(A)】ここにいる生徒（の90%）はいちごフォンを持っている。 ③【結論(B)】ここにいる生徒は（おそらく）いちごフォンを持っている。 結論(A), (B)は先の統計的一般化と同様です。 （余談ながら、この例は 論理スキル[実践編]・ソクラテスは電気羊の夢を見るか？(前編) で紹介した 定言三段論法の第1格 の形ですね） ソクラテスは電気羊の夢を見るか？ (前編)｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts 結論の蓋然性が前提における共通項の割合に依存するのは統計的一般化と同様です。 図2-6 統計的三段論法 レッツ帰納的推論 帰納的な推論には、他に 類推(類比推論) や 因果関係からの推論 という仲間がいますが、これらについては回を改めて紹介したいと思います。 ★ 枚挙的帰納や統計的帰納のような思考は、私たちが日ごろ仕事や私生活で（なんとなくでも、知らず知らずでも）行なっている形の推論で、特別・特殊なものではありません。 （統計的な帰納を自分で行なうことは少ないかも知れませんが、ニュースなどで頻繁に見る「アンケート調査」はその好例です） 帰納的推論は“間違い”の可能性を孕む推論ですが、それは手順のミスや不注意などによるのではなく、形式上避けることのできないものです。“間違い”に臆さず「新たな発見」に邁進しましょう。 次回は、帰納的推論をする上で参考になる考え方・進め方を紹介します。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. ソクラテスは電気羊の夢を見るか？ (前編)｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts The post 【第2回】 “共通項”を見つけ出す｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 ＜QAエンジニアのスタートガイド 記事一覧＞ ※クリックで開きます 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- QAエンジニアは開発・テスト・運用など、さまざまな場面で活躍しています。そんな中でも「ソフトウェアテスト」は外せない要素だと思います。 QAエンジニアになりたての頃は、ソフトウェアテストの「テスト実行」を任されることも多いと思います。そういった状況で「テスト実行はつまらない」と思っている人もいるかもしれません。それはもったいないことだと私は思っています。 実際のところ、「テスト実行」はテストプロセスの中で最も大切な活動であり、プロジェクトへの貢献はもちろん、学びや楽しみの多い活動でもあります。 「ソフトウェアテスト」を解説する記事として、第3話では「テスト実行」について取り上げます。 テストに似た用語として、「試験」「検査」「検証」「評価」といった言葉が使われることがありますが、ここでは「実際の製品を動かしてその結果を観察する作業」を「テスト」としています。また、JSTQBなどを勉強したことのある方は「静的テスト」と「動的テスト」という言葉を聞いたことがあるかもしれません。本記事では記載のない限り、「動的テスト」について扱います。 テスト実行はソフトウェアテストの華である テスト実行へのよくある誤解 「テスト実行」という活動はビギナーにも割り当てられやすいタスクです。 使用する際に資格や特殊な技能が必要のないような製品では、実際にソフトウェアを動かす人として、一般的なユーザーを想定している場合が多いです。 あるいは、製品の仕様のキャッチアップのために、テストエンジニアに限らず新規参入の人がテスト実行にアサインされる場合もあります。 そのために、テスト実行について以下のような印象を持っている場合があります。 テスト実行はテストケースを消化する単純作業でつまらない仕事だ テスト実行は簡単な作業だから学べることは少ない テスト実行は誰でもできるからテスト実行者はスキルがない これらの印象から「テスト実行」というタスクを拒否するQAエンジニアにも出会ったことがあります。私はテスト実行に対してこういった印象を持たれることを残念に思いますし、誤解であると思っています。 テスト実行は重要な活動である テストプロセスの中でのテスト実行 ソフトウェアテストは、テスト活動の開始から終わりまでプロセスで表現できるという考えが一般的です。これを「テストプロセス」といいます。 テスト実行はテストプロセスの中で最も重要なプロセスであると考えています。 たとえばJSTQBでは、テスト計画、テスト分析、テスト設計、テスト実装、テスト実行、テスト完了、テストのモニタリングとコントロールといった活動が識別されています。 ※上記の図において、「テストのモニタリングとコントロール」については、「テスト計画を含む」という考えで記載しています。2018年などの従来のシラバスではモニタリングとコントロールにはテスト計画を含まない形で定義されていました。一方、2023年に発行された最新のシラバスでは「checking of all test activities」とされており、テスト計画を含むとも読み取れます。 これらすべての活動を行うことがベストプラクティスと言われていますが、そうでないプロジェクトも存在します。たとえば「テスト分析」や「テスト実装」を行っていないプロジェクトも存在します。 一方で、「テスト実行」がないプロジェクトを（プロジェクトが中止しない限りは）見たことがありません。 これらの活動のうち、テスト計画・テスト分析・テスト設計・テスト実装は、あえて一言で表せばテスト実行の準備をしているとも表現できると考えます。 テスト完了についても、そもそもテスト実行が実施されていなければ完了できません。テスト実行結果を元に、報告や学びの蓄積や保守への移行など、さまざまな完了作業を行います。 ！注意！ この文章を読み、「テスト活動はテスト実行の準備をしている”だけ”」と片付けるのは少し乱暴です。 テスト計画ではステークホルダーとの合意形成を行う大切な活動です。また、テスト分析やテスト設計は、開発の資料にフィードバックする活動につながることもあります。 こういったテスト実行以外への効果は、この連載で書ききれないほどたくさんあります。 テスト完了についても「テスト実行結果”だけ”がテスト完了のインプットになる」と思ってしまうと少し誤解があります。実際はテストプロセス全般を通じて得られた情報のレポーティングや学びの蓄積を行います。 テスト実行を考えない成果物は取り扱いが難しい テスト実行は後工程であるので、テスト実行について考えることを一旦棚上げして、テスト計画やテスト設計を行う場合もあります。しかし、それはアンチパターンだと考えます。 「計画したテストがいつ・どのように実行されるのか」「設計したテストを実現するためにどうすれば実行できるのか」など、テスト実行についてきちんと考えた上で活動することが大切です。 テスト実行について検討できていないテスト計画やテスト設計は、テスト実装やテスト実行のフェーズで大きな負担になったり、場合によっては手戻りや追加のコストがかかってしまう場合があります。 テスト実行によって「事実を積み重ねる」ことが大切 テストプロセスにおいて、テスト計画からテスト実装は「想定を積み重ねている」にすぎないと考えます。 「お客様に品質を保証する」と考えた時に、私は「事実をきちんと把握できているかどうか」が大切だと考えています。 予測や想定ではなく、「こんな状況でソフトウェアはこんな動作をした」という事実を積み重ねることで、我々は自信を持ってお客様に製品を届けられると考えています。 事実を積み重ねることができる重要な活動が「テスト実行」なのです。 テスト実行の仕事を充実させるポイント アイデアを言語化したり実際に試す テスト実行をするにあたって、目の前のテストケースを思考停止で消化していることがあるかもしれません。それはQAエンジニアとしてもったいないことをしています。テスト実行の際には思考を停止するのではなく、むしろ思考を活性化させてほしいです。 ポイントは様々な発想を広げることです。たとえば以下のような疑問を持つことが有効だと考えます。 こういった動作で顧客はどんな風に感じるだろうか？ こんな都合の悪い操作を行ったらどんな動作をするだろうか？ 似たような製品ではどのような動作をしているだろうか？ これらについて実際に試す際には「言語化すること」もおすすめします。チケットを起票するときや、テスト分析をするときには、こうした言語化の技術が仕事の質やエンジニアとしての実力差に繋がると思います。 「言語化を考える以前にテスト実行進捗に対する圧力がある」ということもあると思います。 その場合は、ぜひテストの準備やテスト実行自体を効率よくできるように検討してください。 たとえばテストの準備・調達の手順が不明確だったり、テスト実行手順が非効率な場合があるかもしれません。もしかしたら自動化を行う余地があるかもしれません。 テスト実行という活動には創意工夫を行う余地があることはもちろんですが、テスト実行の場合、最も工数がかかる活動であるということもあり、改善の効果が得られやすいことがあります。 テストそのものやテストケースの目的に思いを馳せる テスト実行は学びが少ないと思われがちかもしれませんが、学習の材料は大量に存在します。 テストケースやテスト計画書などです。それらの成果物からテスト設計の意図やテストの存在意義について考えてみてください。 もしテストをしていて「このテストケースは無駄だな」と思われるなら、そういった考えの言語化に挑戦することをおすすめします。「無駄なテストを省く」「そのためにきちんと説明できる」というのはテストマネージャーやテスト設計者として必須のスキルになります。 これらはテスト実行を行いながら考えることができます。 テスト実行の専門性を高める テスト実行は誰でもできると思われがちですが、テスト実行にも専門性があります。不具合発生時のチケットでの報告や切り分けには、慣れや経験があります。これらは学習によってもキャッチアップできますが、バグというのは多種多様で、経験や感覚に頼る部分も多いのが現状です。 そのため、テスト実行を通して、よりよいテスト実行者になることも有意義だと考えます。 おわりに 本記事では「テスト実行」について充実させるためのポイントを紹介しました。 テスト実行を通してテストに関するさまざまなことを学んで欲しいと思います。 また、将来キャリアアップしたときに、テスト実行ができないポジションとなる可能性もあります。その時に「テスト実行での学びをするのを疎かにしていた」ということがないようにしてほしいと思います。 続く後編では、テスト実行以外の活動にフォーカスを当て、解説していきます。 【連載】QAエンジニアのスタートガイド 記事一覧 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編- The post 【第3回】QAエンジニアの第一歩、「ソフトウェアテスト」を知ろう -前編-｜QAエンジニアのスタートガイド first appeared on Sqripts .

この連載では、1人目QAとしてのチームの立ち上げや組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。 前回の記事 では、チームビルディングの概念や考え方の説明と、QAチームにおけるチームビルディングについてタックマンモデルの各段階をもとに概要をご紹介しました。 今回は、QAと開発者という、異なるロール間でのコミュニケーションについてご紹介します。 コミュニケーションというと非常に広い話になりますし、開発者とQAの関わり方や組織の形なども会社によっていろいろな形があります。ただ、私が他社のQAの方から「開発者とのコミュニケーションに課題があって・・・」と相談をいただいて話を聞くと、いくつかのパターンとそれに対する基本的な対応方法があるように感じています。 そこで、この記事ではQAと開発者とのコミュニケーションに関してよく聞く課題と、とくにQAと組織を立ち上げていく過程で気をつけるべきことについてご紹介します。 QAと開発者とのコミュニケーションにおける課題 QAにとって、開発者との関係性というのは非常に大切です。これは実際にQAとして働いている方にはほぼ確実に同意していただけるのではないでしょうか。 QAだけががんばってもプロダクトの品質向上には限界があり、開発者やマネージャー、デザイナーなど他のさまざまなロールの方と協力して初めて品質を高められます。特にQAが業務レベルで関わるのは開発者である場合が多いはずです。 そのため、開発者との関係性がよければ互いに協力して品質を高めることができますし、逆に関係性が悪いとなかなか同じ方向を向けず品質にも悪影響があります。最近よく聞く言葉で言えば、開発者とQAが協調するとか、互いにロールの垣根を越えて（越境して）働くとか、そういった動き方が良しとされていますね。 こうした理想の姿については、それほど反対されることはないかと思います。 しかし、実際に現場でQAとして働いている方の話を聞くと、開発者とQAとの間のコミュニケーションについていろいろな問題があるようです。 たとえば、技術面で開発者とコミュニケーションが取りづらい、品質に対する温度感の違いがある、QAに対してネガティブなイメージを持たれている、などです。そうした問題をいろいろな方から聞いた中で、大きく以下2つの要素が多く出てくると気づきました。 QAエンジニアの役割や業務が開発者側に伝わっていない コミュニケーションの土台が不足し、開発者体験が悪化している それぞれについて、どのように対応すればよいのか考えていきましょう。 QAの役割や業務に対する理解を得る ひとつめは、QAの役割や業務が開発者側に伝わっていないという問題に対する対応です。これは単純に問題の裏返しで、QAの役割や業務に対して理解を得ましょう、という話です。 とくにQA組織をこれから立ち上げる場合はQA組織の位置づけ、どのような役割を担うのか（それによって開発者の動きがどう変わるのか）などが明確になっていないと、すれ違いが発生します。 よく聞く具体的なお悩みとしては、大きく2パターンです。 品質に対する考え方に関するもの 開発者が「テストはQA・テストエンジニア側のしごと」と考えている 品質に対する開発者の意識が低い、大事だと思ってくれていない など QAの役割・動き方に関するもの QAが居ると開発スピードが遅くなる、と思われている 重要でない細かい指摘をたくさんされると思われている など これらの開発者からQAに対する誤解については、ていねいに説明をして理解を得ていくことが大切です。 方法1：QAがやること・やらないことの宣言 これは私が事あるごとにオススメしている方法なのですが、その組織の中でQAエンジニアが何をやるのか＆何をやらないのかを宣言することで理解してもらう、というものです。 たとえば私は現在のQA組織を立ち上げるにあたって、入社してすぐに「QAが決めた基準を守らせたり、アセスメントやメトリクスなどによる定量目標を強制はしません。品質はQAだけが考えるものではなく全員で考えるもので、合意・納得のないルールには意味がないからです」と宣言をしました。 実際に開発者からは「QAが来ると聞いていろいろ縛りがきつくなるのかと思ったけれど、最初に無理やりルールを押し付けないと聞いて安心した。協力できそうだと思った」というフィードバックをもらいました。 一般に「QAがやること」を明確にすることは行われますが、「QAがやらないこと」もセットで伝えることで、開発者にとっての安心につながり、QAに対する意識や見方がポジティブな方向に変わることもあります。 方法2：開発者も含めた全員が品質に対して関係していることを伝える 最近では少なくなってきているように感じますが、「テストはQAに任せておけばいい、品質を考えるのはQAの仕事」といった認識が開発者にあって困っている、という声を聞くこともあります。 この場合は、開発者も含め全員が品質に関係していると理解してもらう必要があります。世の中のQA担当者はさまざまな方法で開発者にアプローチしていますが、たとえばコストに関する以下の図はよく用いられています。 引用：ソフトウェア品質保証の 方法論、技法、その変遷 ～先達の知恵に学ぶ ～　P31より つまり、テスト工程でQAやテストエンジニアが問題を見つけるよりも、コーディング時や設計段階などで問題を見つけたほうがプロジェクトにとっては低コストで済む、ということです。そのため、問題はテスト工程で見つければいいやではなく、開発者も積極的に品質に関する活動やテストを行うべきである、という理屈です。 他にも、体重計とダイエットのメタファを用いることもあります。 ダイエットをしているとき、体重計に乗れば現在の体重がわかりますが、体重計に乗ること自体にダイエット効果はありません。そこでわかった体重をもとに、運動をしたり、食事を見直したりといった行動を起こして初めて体重が減少します。 品質もこれと同じで、テストをすることで現在の品質やどこにバグがあるか等がわかります。しかし、何度テストをしても品質はよくなりません。見つかったバグを修正することで初めて、品質が良くなるのです。 QAやテストエンジニアがいくらテストをしたとしても直接品質を高めることにはならず、開発者によるバグ修正が必要です。つまり、開発者も品質に十分関係している、という理屈です。 ちなみにこのメタファは『ソフトウェアプロジェクトサバイバルガイド』という書籍に登場するそうです。 とくにQA組織の立ち上げ時がカギ とくにQA組織の立ち上げ時というのはこの「理解を得る」もしくは「誤解を解く」ためにとても重要なタイミングです。組織立ち上げに向かって動き始めるタイミングで、QAの役割や業務に関する価値観・大事にしたいことを打ち出していくと、開発者からも「自分たちに協力してくれるんだ」「メリットが期待できるんだ」と感じてもらえ、協力関係が築きやすくなっていくでしょう。 QAに関する理解については以前 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み | Sqripts に記載しましたので、こちらもぜひご覧ください。 【第3回】品質保証やQAエンジニアを知ってもらうための取り組み 1人目QAとしての立ち回り、第3回となる今回は、QAエンジニアや品質保証のことを開発組織に知ってもらうための取り組みについてご紹介します。前回の記事では、1人目のQAは開発組織に対して品質文化を浸透させる役割を求められる、と書きました。しかし、「文化の浸透... 　続きを読む　 Sqripts 関連記事｜Sqripts QAとして信頼を得る もうひとつはコミュニケーションの土台が不足する問題への対応で、ひとつめとも関係しますが、開発者をはじめ他の職種の方から信頼を得ることが大事です。 とくに若手QAの方から相談されることの多いものとして「開発者と技術的な話ができなくて・・・」というものがあります。開発経験がない状態で、テストエンジニアやQAエンジニアになった方だと「開発者が普段話している内容がわからない」「技術的な話についていけない」と感じ、そこから開発者とのコミュニケーションがうまくいっていないと感じることが多いようです。 Developer eXperience Day 2024にて、AtCoder代表取締役社長 高橋直大氏の講演では以下のような内容が話されていました。 開発者体験はチームメンバーによっても決まる 多くのメンバーにとって当たり前のことを知らず、いちいち説明しなければならない状況が発生すると開発者体験が悪くなる 参考： アルゴリズムと開発者体験 – Tech Team Journal 私はこの講演をリアルタイムで聞いていて「なるほど確かに」と感じました。その後、よくよく考えてみると、開発者とQAとの間でのコミュニケーションにおいても同じことが言えると思いはじめました。 開発者とQAとではスキルセットや持っている知識に違いはあるものの、たとえば一般的な開発プロセスや、プログラミングのごく基礎的な内容については双方にとって「当たり前」とみなされる可能性があります。それをQA側が知らず、かつ理解しようという姿勢がない場合は、開発者体験が低下してしまいます。そうなってしまうと、「QAの＊＊さんがいると全体の効率が落ち（たように感じられ）るよね」「品質を高めるうえでは逆効果だよね」と捉えられてもおかしくありません。 では、QAはどこまで何を知っていればいいのでしょうか。この点に関しては絶対の正解はありません。過去の経験上、以下のような内容を把握しておくと開発者とのコミュニケーションの土台になります。 一般的なソフトウェア開発プロセスに関する知識 ウォーターフォールとアジャイル 継続的インテグレーション テスト対象アプリケーションを作るうえでの基礎的な技術 WebアプリケーションであればhtmlとCSS、JavaScriptなどそれぞれの役割と、Web上に公開するまでの流れ モバイルアプリケーションであればXCodeやAndroidStudioでアプリを作って公開するまでの大まかな流れ スクラム関連 各種イベントや用語 チケット管理 BTS/ITSなどを使ったチケット駆動の仕事の進め方 私がよくオススメしているのは、簡単なアプリケーションを作って動かしてみることです。難しいことをする必要はなく、インターネット上で公開されているサンプルや入門書のサンプルを作る流れを1度体験するだけでもかなり違います。 まとめ 今回は、開発者とQAとのコミュニケーションに関する問題やその対応について考えました。 一般的な同僚とのコミュニケーションに関する工夫、たとえば雑談をしたり一緒にランチをしたりといった接触機会を増やす他に、本記事でご紹介したような内容に気を配っていただけるとよいかと思います。 QAを取り巻く環境は、以前に比べるとだいぶ良くなっているように感じます。QAエンジニアという職種の認知も進んできています。そうはいっても、個々のQAが自分の周囲の同僚から理解を得たり、関係性を構築したりといった努力が不要になったわけではありません。 品質向上につながるアクションとして、開発者とのより良いコミュニケーションができるようにしていきたいですね。 【連載】QA組織の立ち上げ方－1人目QAが語る実践と工夫－ 記事一覧 【第1回】QA組織立ち上げの流れと組織の形 【連載初回、全文公開中】 【第2回】2人目以降のQAエンジニアの採用 【第3回】QAチームビルディング｜QA組織の立ち上げ方 The post 【第4回】QAと開発者とのコミュニケーション｜QA組織の立ち上げ方 first appeared on Sqripts .

こんにちは、フロントエンドエンジニアとして働いているぱやぴです。 これまで主にMantine UIを使って実務を進めてきましたが、最近注目されている「 shadcn/ui 」を試してみました。 本記事では、shadcn/uiの概要やメリット・デメリット、実際に触ってみた感想などを紹介していきます。Mantine UIに慣れている方はもちろん、その他のコンポーネントライブラリを使っている方にも参考になれば幸いです。 shadcn/uiとは？ shadcn/ui は、React向けのコンポーネントコレクションであり、UI構築をよりシンプルかつ柔軟にすることを目的としています。主な特徴としては、次の点が挙げられます。 Radix UI のコンポーネントをベースにしている スタイリングは Tailwind CSS を利用 セマンティクスやアクセシビリティ（a11y）を考慮したデザイン 公式サイトからコンポーネントをコピー＆ペーストで導入可能 必要なものだけ導入しやすい疎結合な設計 ビルド済みのコンポーネントを導入するのではなく、プロジェクト内に ソースコードとして取り込む 形式が採用されています。 後述するメリットにも大きく関係しますが、この方針によって細かいカスタマイズやアップデートに柔軟に対応しやすくなっています。 メリット 1. Radix UI由来のUIパターン & アクセシビリティ shadcn/uiは Radix UI をベースとしており、アクセシビリティ（a11y）を重視したUIコンポーネントが揃っています。以下の点がメリットです。 UIパターン Tailwind CSSと統合されており、UIデザインを簡単に適用可能 モダンなUIパターンを利用しつつ、ゼロからのデザイン構築の手間を軽減 アクセシビリティ WAI-ARIAのベストプラクティスが適用されているため、デザインを変更してもa11yが担保される キーボード操作やスクリーンリーダーへの対応が優れている 必要に応じてデザインシステムやスタイルを柔軟に追加可能 2. Tailwind CSSとの親和性 & 高いカスタマイズ性 shadcn/uiは Tailwind CSS でスタイリングされているため、次のような利点があります。 既存のTailwindベースのプロジェクトに組み込みやすい クラス名を直接編集することで、デザインやレイアウトを自由に変更できる また、コンポーネントをnpmパッケージとして利用するのではなく、プロジェクト内に直接ソースコードを取り込むスタイルのため、 必要に応じて自由に修正できる 柔軟さがあります。 結果的に、 プロダクト独自のデザイン要件 や将来的な拡張にも対応しやすい点が非常に魅力的です。 3. CLIやコピー＆ペーストで導入が容易 shadcn/uiにはCLIツールが用意されており、以下のようなメリットがあります。 コマンド一つでコンポーネントをローカルに自動生成 コンポーネント名を指定するだけで簡単に追加・削除が可能 また、公式サイトから コピー＆ペースト する方法でも導入できるため、初めて触れる場合でもセットアップがわかりやすく、すぐに実装に移れるのがメリットです。 4. v0との連携 v0で生成されたコードは shadcn/ui のコンポーネントを使用しているため、そのままプロジェクトに組み込むことができ、プロトタイピングの速度が大幅に向上します。 また、v0が生成するUIはshadcn/uiに基づいているため、AIを用いながらデザインの一貫性を保つことができます。 以下v0について紹介されていた記事になります。 最近話題のVercel v0 Teamプランを導入してみた！その効果と活用方法を紹介 こんにちは！フロントエンドエンジニアのつかじです。今回は、私たちの開発チームで導入した「Vercelのv0 Teamプラン」について、その魅力や実際に使ってみて感じた効果、そして活用方法を詳しくご紹介します。v0とは？まず、v0についてご存知ない方のために簡単に説... 　続きを読む　 Sqripts 関連記事｜Sqripts 5. オープンソースかつコミュニティ駆動で進化し続ける shadcn/uiは オープンソース として公開され、コミュニティが積極的に開発をサポートしています。 バグ修正や新機能要望への対応が比較的早い デザインやアクセシビリティ強化のプルリクエストが日々取り込まれている そのため、今後も 継続的なアップデート が見込まれ、時代に合わせたUI/UXの改善が期待できます。 デメリット 一方で、shadcn/uiを使うにあたってのデメリットや注意点としては、以下が挙げられます。 コンポーネント更新の手間 npmパッケージとして管理されているライブラリと異なり、shadcn/uiはソースコードを直接取り込む形式です。 新しいバージョンがリリースされた場合は、自分たちで差分を確認しながら更新しなければならないため、 保守コスト が増える可能性があります。 Tailwindベースであること Tailwind CSSでの開発が前提となるため、 Tailwind未経験の場合は慣れが必要 です。 既存プロジェクトに導入するには、ビルドチェーンの調整などが必要になる場合もあるでしょう。 実装責任がより増す コンポーネントをコピーしているとはいえ、 プロジェクト内でコンポーネントとして管理 することになります。 そのため、状況によっては同じコンポーネントなのにバージョン差異が生じるなどのリスクも考慮が必要です。 実際に動かしてみる ここでは、簡単に手順を紹介します。（プロジェクト環境によっては多少異なる場合があります） 詳細な導入方法は 公式ドキュメント を確認してください。 shadcn/uiのCLIで導入 npx shadcn@latest init Tailwind CSSのセットアップ npm install -D tailwindcss@latest autoprefixer@latest Next.js + Tailwind CSSのテンプレートを利用するか、既存プロジェクトであればTailwindの設定ファイル（ tailwind.config.js ）を用意します。 postcss.config.js や tailwind.config.js を適宜編集し、Tailwindを有効にします。 コンポーネントのインストール shadcn/uiの公式サイトで目的のコンポーネントを選択し、CLIまたはコピー＆ペーストでプロジェクトに取り込みます。 今回はサンプルとして button をCLIで取り込みます。 npx shadcn@latest add button 取り込んだコンポーネントは components/ui のようなディレクトリに配置されます。 動作確認 ローカルで開発サーバを起動し、ブラウザ上でUIを確認します。 import { Button } from import { Button } from "./components/ui/button"; export default function App() { return <Button>Click me</Button>; } カスタマイズ T Tailwindのクラスを使って自由にデザインを変更できます。 今回はxsサイズをxsサイズの追加とデフォルトでのボタンの表示を背景色に合わせるようにします。 import * as React from "react"; import { Slot } from "@radix-ui/react-slot"; import { cva, type VariantProps } from "class-variance-authority"; import { cn } from "~/lib/utils"; const buttonVariants = cva( "inline-flex items-center justify-center gap-2 whitespace-nowrap rounded-md text-sm font-medium transition-colors focus-visible:outline-none focus-visible:ring-1 focus-visible:ring-ring disabled:pointer-events-none disabled:opacity-50 [&_svg]:pointer-events-none [&_svg]:size-4 [&_svg]:shrink-0", { variants: { variant: { + default: "bg-background hover:bg-accent hover:text-accent-foreground", + primary: "bg-primary text-primary-foreground shadow hover:bg-primary/90", destructive: "bg-destructive text-destructive-foreground shadow-sm hover:bg-destructive/90", outline: "border border-input bg-background shadow-sm hover:bg-accent hover:text-accent-foreground", secondary: "bg-secondary text-secondary-foreground shadow-sm hover:bg-secondary/80", ghost: "hover:bg-accent hover:text-accent-foreground", link: "text-primary underline-offset-4 hover:underline", }, size: { default: "h-9 px-4 py-2", sm: "h-8 rounded-md px-3 text-xs", lg: "h-10 rounded-md px-8", icon: "h-9 w-9", + xs: "h-7 rounded-md px-2 text-xs", }, }, defaultVariants: { variant: "default", size: "default", }, } ); export interface ButtonProps extends React.ButtonHTMLAttributes<HTMLButtonElement>, VariantProps<typeof buttonVariants> { asChild?: boolean; } const Button = React.forwardRef<HTMLButtonElement, ButtonProps>( ({ className, variant, size, asChild = false, ...props }, ref) => { const Comp = asChild ? Slot : "button"; return ( <Comp className={cn(buttonVariants({ variant, size, className }))} ref={ref} {...props} /> ); } ); Button.displayName = "Button"; export { Button, buttonVariants }; sizeに今回追加した xs を指定します export default function App() { return <Button size="xs">Click me</Button>; } ボタンの色とサイズが変わりました。(わかりやすく変更前のものを並べて表示しています。) 実際に試してみた感想としては、 コンポーネントをコピー＆ペーストするだけ で「動くUI」がすぐに生成される点が非常に快適でした。 Mantine UIほどドキュメントが整備されていない印象はありましたが、UIの見せ方や挙動の細かな調整がしやすいので、個人的には プロダクトの独自性を出したいケースに向いている と感じます。 終わりに 今回は、新しく注目されている shadcn/ui について、概要からメリット・デメリット、実際に動かしてみた感想をまとめました。 とても簡単に導入することができ、感動しました。 長らくMantine UIを愛用してきた身としては、UIライブラリを丸ごと導入する手軽さや手厚いドキュメントを維持しつつ、もう少し細かいカスタマイズが欲しい…と感じることもありました。 そんなときにshadcn/uiの「コンポーネントを自前で管理できる」という方針は、とても魅力的に思えました。 今後のプロジェクトでは、 デザイナーや他のエンジニアがどれくらい自由度を求めるか によって、UIフレームワークを選ぶ際の選択肢が増えそうです。アクセシビリティとデザインを両立したい方や、 コンポーネントをより細かく制御したい という方には、ぜひ試してみてはいかがでしょうか。 ここまで読んでいただきありがとうございました。 The post コンポーネントライブラリではない！？「shadcn/ui」を触ってみた first appeared on Sqripts .

はじめまして！QAエンジニアのたくぞーです。　 テスト設計を行う上で、必要なテスト要件を網羅できているか不安に感じる…という方は少なくないのではないでしょうか。テスト設計時の仕様把握において、内容そのものの理解はもちろんですが、情報を十分に整理できていないと必要なテストの抜け漏れに繋がります。 テスト設計業務での仕様把握をきっかけに、テスト設計で活用できる情報整理の方法はないかと思い調べてみました。今回はそれぞれの概要やメリット、筆者の経験上の活用事例を交えてご紹介していきたいと思います。 テスト設計に使える情報整理術 デシジョンテーブル まず初めに デシジョンテーブル を紹介します。ブラックボックステスト技法の1つなので、ご存じの方も多いのではないでしょうか。複雑な条件（入力）の組み合わせによって、アクション（出力）が異なるシステムの場合に効果的です。条件とアクションの関係性をテーブル（表）に可視化することで組み合わせを整理しやすく、必要なテスト条件を漏れなく検討することができます。 簡単な活用例を交えて紹介します。ある会員限定の通販サイトの料金計算に関する下記の仕様があるとします。 会員ランクは「ゴールド」「シルバー」「ブロンズ」の3種類 購入代金から会員ランクに応じた下記の割引が適用される ゴールド：10%OFF　 シルバー：5%OFF　 ブロンズ：割引なし クーポン適用で購入代金から5%OFFする 会員ランクによる割引とクーポンによる割引は併用可能 これらの仕様をデシジョンテーブルで表すと下記の通りです。 ※存在しない条件の組み合わせ（異なる会員ランクの組み合わせ）は省略しています。 上記仕様では会員ランクの種類とクーポンの適用有無によって割引率が変動するため、各会員ランクとクーポン適用を条件部分に、各条件に対して「X」「Y」の値を記載します。その上でアクション部分に該当する割引率と「X」の値を記載します。 今回はシンプルな仕様なのでケース数は少ないですが、複雑な仕様となるとケース数も増大します。そのような時にデシジョンテーブルは効果的です。注意点としては、存在しない組み合わせなどの不要なケースを含めてしまったり、反対に必要な組み合わせを省略してしまうことが考えられるので、その点は気をつけましょう。 デシジョンテーブルは使う頻度も多く、筆者の場合はデシジョンテーブルと合わせてフローチャート部分をテスト分析・設計する時にも活用します。その際、分岐時の条件を条件部分に、その条件に応じた結果をアクション部分に入れて整理すると、必要なテスト条件を漏れなく効率的に検討でき、特に分岐が多い時はより効果的です。 また、デシジョンテーブルに関する詳細は下記の記事で詳しく取り上げられているので興味がある方はこちらも読んでみて下さい。 ▼参考記事 いまさらデシジョンテーブルというものを考えてみた ｜Sqripts 状態遷移図/状態遷移表 続いては 状態遷移図、状態遷移表 です。こちらもブラックボックステスト技法の1つですね。状態間が遷移するようなシステムやソフトウェアの場合に、状態とイベントの関係を図や表で可視化できるので全体像が把握しやすくなったり、考えうるパターンを整理することができます。 こちらも簡単な活用例を交えて紹介します。エアコンのリモコン操作に関する下記の仕様があるとします。 ボタンは「冷房」「暖房」「除湿」「停止」がある　 停止中に「停止」以外のボタンを押下すると運転中に切り替わり、各ボタンに応じた状態に遷移する 「冷房」ボタン：冷房　 「暖房」ボタン：暖房　 「除湿」ボタン：除湿　 運転中の各状態で「停止」以外のボタンを押下すると、各ボタンに応じた状態に遷移する 運転中の各状態で「停止」ボタンを押下すると、停止中に遷移する これらの仕様から、各状態とイベントの関係を状態遷移図で表すと下記の通りです。 各状態はそのまま状態として表し、各ボタン操作はイベント、イベントによる遷移は矢印で表しています。 次に、作成した状態遷移図の内容を踏まえて状態遷移表を作成します。 遷移前の状態を行に、イベントを列に入力し、イベント実行後の遷移先を表内に当てはめていきます。また、イベントを実行しても遷移が発生しない組み合わせには「-（ハイフン）」を入れます。 このように、状態遷移図では視覚的に全体の流れを把握できるため仕様を整理しやすくなり、状態遷移表では遷移しない組み合わせや無効な遷移も表すので必要なテスト条件の抜け漏れ防止に繋がります。 筆者の場合、例に挙げたような状態間の遷移を伴うシステムは当然のことながら、画面間の遷移を整理したい時にもよく活用します。画面数やイベント数が多いシステムになるほど作成や更新の手間は多少ありますが、用意しておくことで深く仕様を理解することができ、結果的にテスト分析・設計を円滑に行えた経験もあります。注意点としては、規模が大きいほど複雑化しやすく、逆に理解しづらくなってしまうことがあるので、適切に分割したり表記方法を簡潔にするなどの意識が必要です。 状態遷移図、状態遷移表に関する詳細な記事についても下記で取り上げられているのでご興味のある方は読んでみて下さい。 ▼参考記事 幅広いソフトウェアとテストレベルで適用可能な状態遷移テスト ｜Sqripts ロジックツリー ロジックツリー とは、ある課題や物事の要素をツリー状に分解して整理することにより、解決策を導き出していくフレームワークです。各要素を左から右に樹木が枝分かれしていくような形で階層化して整理していきます。 ロジックツリーにはいくつか種類がありますが、「 要素分解ツリー（WHATツリー） 」と呼ばれる、構成されている要素を網羅的に分解していく手法が整理しやすいかと思います。テスト対象となる画面や機能といった各要素を、WHATツリーを用いて段階的に分解（整理）していくことで、全体像を把握しやすく、テストすべき内容を整理することができます。 これまでと同様に簡単な活用例を紹介します。ログイン画面に関するテストを行うことになり、下記の仕様があったとします。 ユーザーID/パスワードを入力してログインする　 ユーザーIDは4～20文字の範囲で、半角英数字と半角記号が使用できる　 パスワードは8～64文字の範囲で、半角英数字と半角記号が使用できる 大文字・小文字・数字・記号の中から3種類以上含める必要がある　 ログインに成功すると会員画面に遷移する　 ユーザーID/パスワードの範囲内の文字数/文字種を入力し、ログインに失敗した時はログイン画面上にエラーAを表示する ユーザーID/パスワードの範囲外の文字数/文字種を入力し、ログインに失敗した時はログイン画面上にエラーBを表示する 「パスワードを忘れた場合はこちら」リンクから、パスワード再設定画面に遷移する これらの仕様からどのようなテストが必要かを分析する際、WHATツリーを使うと下記のように整理することができます。 テスト対象となる画面を起点に機能⇒観点の順に階層を分けていき、右にいくにつれてより詳細度の高い観点を記載していきます。筆者の場合はこのように、画面や機能の関係性をツリー上に展開してテスト観点を整理する際に活用していますが、実際に型に当てはめて可視化しながら整理できるので、頭の中だけで考えたり箇条書きで書いてみるよりも、観点が抜け漏れてしまう可能性がぐっと下がる印象を持っています。 検討すべき要素が多い場合はもちろん、要素が少なくても不安と感じる場合には一度WHATツリーを活用してみて下さい。 仮説思考 仮説思考 は限られた情報や知識・経験から最も可能性の高い結論を仮説立て、その仮説に基づいて検証を行い正確な情報を確認する思考方法です。テスト設計においては、テストベースの情報が少ない場面で活用できます。限られた要件や仕様から仮説を立てることで、テストベースを読むだけでは一見分からない要件や仕様について検討することができます。 筆者の場合、上記のロジックツリーの例と関連しますが、あるシステムのログイン画面に関する仕様把握を行っていた時に、認証に失敗する時の入力条件や、認証失敗時に該当のエラーを表示することはテストベースに明記されていましたが、一定回数失敗した時にロック状態になるといったことは明記されていない状況がありました。 過去に類似機能のテストを行った時はロック状態に関する仕様が存在していた経験から、その仕様が考慮されていない可能性があるといった仮説を立てて関係者に確認を行い、結果的にはそのシステムの性質上考慮は不要という結論に至りましたが、もし考慮が必要である場合には、何回失敗するとロック状態になるか、ロック状態はどのように解除されるか、という疑問も連想できるので仕様の有無と合わせて確認しておきましょう。 注意点としては、知識や経験に依存しすぎて仮説に頼ってばかりでは、返って柔軟なテスト設計ができない場合もあります。そのため、仮説は適切な場面に応じて立てて検討したほうが良いでしょう。 フェルミ推定 フェルミ推定 は予測することが困難な数値を、既知のデータや情報から論理的思考に基づいて概算を推定する手法です。限られた情報から答えを求めるという部分は、仮説思考と共通する部分になりますね。 テスト設計においては、数値に関する情報が不足している状況で活用することができ、限られた仕様や知識から概算を推定し、テストベースには記載されていなかった仕様について検討することができます。 筆者の場合、ある大企業向け業務システムのユーザー登録機能の仕様把握を行っていた時に、どれくらいのユーザーを登録できるかといったテストを検討する必要があったのですが、テストベースとして参照できるものに登録上限数が定義されていないという状況がありました。一見どこまでテストするのが妥当なのか見当が付かない数値でしたが、日本で最も従業員の多い企業が約35万人で、ここ5年で約3万人増加というデータを知っていたため、バッファ分を考慮しても50万人登録できるようであれば十分と考えることができます。 もちろん関係者に上限数を確認する必要はありますが、確認する際にただ確認するのではなく、上記の様に妥当性を提示することで客観的な根拠を得ることもでき、仕様の誤りの修正や仕様の決定を関係者がスムーズに行えるようになります。 その他の情報整理術 多面的な視点から物事を捉える ここまではテスト設計に活用できる各情報整理の手法について紹介してまいりましたが、その他にも意識的な技術として、多面的な視点から物事を捉える重要性についても紹介いたします。　 例えば、ある物事を特定の視点からしか捉えることができないとすると、他の視点から捉えることができる部分を見落とすことになり、その物事の本質を捉えることができません。これはテスト設計においても同様で、テスト対象の本質を捉えることができないと見当違いなテスト内容を検討してしまったり、考慮漏れという事態にも繋がります。 様々な視点から物事を捉えるために 「鳥の目、虫の目、魚の目、コウモリの目」 といった4つの視点を表す言葉が存在するため、概要について説明いたします。簡潔に表すと下記の通りです。 これらの視点はいずれも仕様把握において重要と考えています。 多少の主観を含みますが、テスト対象に関する理解を効率よく深めるには、はじめに鳥の目を意識する必要があると考えています。筆者の場合、テスト対象の全体像を把握しきれていない状態で詳細部分の分析から進めてしまったことで、より理解に時間がかかってしまったり、見当違いのテスト内容を検討してしまったという経験もあります。 まずは、テスト対象の全体を俯瞰して見ることを心がけ、その上で虫の目を意識して詳細部分の分析を行いましょう。そうすることで効率よく理解を深めるだけでなく、テストベースに明記されていない要件や仕様に気づける可能性も向上します。 また、その時にコウモリの目を意識してユーザー視点で仕様について考えることも必要です。ユーザー視点で考えてみると妥当ではないと捉えることができる仕様や、要件や仕様の誤りに気づける可能性もあります。 他にも、時間に特性を持つテスト対象においては魚の目を意識して、過去→現在→未来といった各時間軸でどのような違いがあるかを検討し、テストベースに明記されてなければ関係者に確認しましょう。 また、仕様把握を行う際には、下記の記事の記載内容と合わせて実践することでより高い効果が得られると思いますので、こちらの内容についても合わせて読んでみて下さい。 ▼参考記事 良い仕様把握は良い品質に繋がる 〜仕様把握をする時のコツ 5選を紹介〜 ｜Sqripts まとめ 改めて今回ご紹介した情報整理術と、その使い分けについて以下表にまとめました。 筆者の主観も多少含みますが、活用するときの基準の1つとして捉えていただければと思います。 今回ご紹介した情報整理術はあくまでも一例に過ぎませんが、テスト分析・設計をはじめとした様々な分野・業務においても活用することができるものです。　 各特性を把握いただいた上で実際に試していただき、自分にあったものをご活用いただけますと幸いです。 そして、これらを活用する際には参画しているプロジェクトの状況を考慮する必要があります。例えば、プロジェクトが繁忙期であったり、保守的なプロジェクトにおいて、これまで使用していない技法を用いると逆効果となってしまう可能性もあるため、状況に応じて適切な技法をご活用いただければと思います。 また、決してこれらだけを活用すればいいというものではありませんので、その点はご理解いただけますと幸いです。 最後まで読んでいただき、ありがとうございました！ #デシジョンテーブル #状態遷移図 #状態遷移表 #ロジックツリー #仮説思考 #フェルミ推測 The post テスト設計に使える情報整理術のご紹介 first appeared on Sqripts .

帰納的な推論 と 発見的な推論(アブダクション) は、 私たちがソフトウェア開発の現場/実務で（知らず知らずにでも）駆使している思考の形です（それどころか日々の暮らしでも使っています）。 それほど“自然な”思考の形ですが、どんな考え方で、どんなところに注意すると質の高い思考ができるのか、基本知識を押さえておくと実務のレベルアップにつながります。 今回は、推論の形を今一度おさらいし、本連載で取り上げるふたつの推論の概要を知りましょう。 「論理的」はつまらない？ 演繹的な推論の特徴 [実践編]で見てきた論理(演繹的推論、図1-1)には、次のような特徴があります。 前提に含まれていることだけから、論理の言葉の働きに従って一定の結論が導かれる 前提と結論には必然的な関連がある 前提が正しい(真)ならば、結論も正しい（と認めざるを得ない） 前提にないこと(意外な事実、新奇な発見、etc.)が結論で出てくることはない 図1-1 演繹的推論 演繹的な推論は、既知の事実/知識や普遍的な真理に基づいて個別の場合/個別の主張を論じる場合や、主張の正しさを論証する場合に活躍します。 論証(検証)のための論理 といった形容をされることもあります。 半面、「結論で主張することはみな前提にあることばかり」「当たり前のことを言うだけ」「新たな知見を得るものではない」と批判されることもあったそうです。 [実践編]で例として出てきた 「今日は雨だからAさんは自宅にいる」 にしても、 「ソクラテスと電気羊」 にしても、 前提からは思いもしないあっと驚く結論を出すのではありませんから、そのような“批判”も頷けなくはありません。 前提はどこから来る？ そうした批判の詳細や当否はここでは掘り下げませんが、「前提に含まれていることを基に」というその前提は、そもそもどこからどうやって出てきたのでしょうか。 356日欠かさずAさんの自宅を見張り、天候による過ごし方の違いを観察したのでしょうか。 「すべての哲学者は電気羊の夢を見る」という前提を得るために、すべての哲学者の見る夢を調べ上げたのでしょうか。 どちらも現実的にきわめて困難、ないし不可能でしょう。 そもそもどちらの例でも、その前提は演繹的な推論では得られそうもありません。 「発見」のための論理 非・演繹的な推論 演繹とは異なる形を持つ、非・演繹的な推論があります。 非・演繹的な推論その①は、「 帰納(帰納的推論) 」です。 図1-2 非・演繹的な推論①(帰納) 非・演繹的な推論その②は、「 アブダクション 」といいます。 図1-3 非・演繹的な推論②(アブダクション) これらの推論には次のような特徴があります。 結論として、前提に含まれていない 新たな知識 を引き出す （パン屋のチェーンP全体の営業終了時刻(または終了基準)） （特定のパンの売れ行きと近所の学校の生徒の購買傾向との関係） 前提と結論との間に必然的な関連がなく、なんらかの「 飛躍 」がある （調査した店舗が当てはまるからといって、すべての店舗がそうとは限らない) （焼きそばパンが残っていたのは、近所の学校の休校とは関係ないかも知れない） 前提が正しい(真)からといって、結論が正しいとは限らない 正しいと言える 蓋然性(確からしさ) が相当程度にある、にとどまり、誤りがある可能性を否定できない 結論が正しげに思えても、事例が追加されるなどして前提が変わると、それまでの結論が成り立たなくなる可能性をはらむ （よその街の店舗を調べたら、16時以降も店を開けているかも知れない) （近所の学校の休校が明けても売れ残るかも知れない） 演繹的な推論に比べると「(正しさの度合いが)弱い」半面、 新たな知見を得る際には大活躍する、 発見に寄与する論理 と言えます。 帰納的推論の概略 図1-4 帰納的推論 一般化 複数の有限個の事例から、同様の事例すべてに共通するもの(規則・法則、性質、原因、etc.)を見出す 「特殊から普遍へ」「部分から全体へ」などとも称される 蓋然的 有限個の事例を基に考えているので、「きっとそうだろう」「そうであるに違いない」とまでしか言えない。“間違い”の可能性が常にある 結論の確からしさは前提の質と量に依存する あくまで仮説 「きっと」「に違いない」が示すように、結論を導いただけでは「仮説」どまり アブダクションの概略 仮説の形成 結果(事象や事実)を説明する仮説(因果関係、法則、理論、etc.)を考える 蓋然的 「結果を説明する原因/理由や、結果に至る過程(プロセス)」は仮説の域を出ないので、“間違い”の可能性が常にある あくまで仮説 考えついた段階では道半ば 「その考えで矛盾なく整合的に説明できる」ことの論証を経てようやく仮説になる 綿密な論証や、実証（実際にそうであることの確認）が望まれる 論証が控えていてこその「発見」 ……ここまで読んできて、「論理の言葉なんかより、新しい知識を形成する「発見」の方が重要で、大事なのでは」と思う人もいるかも知れませんが、 三つの種類の推論はそれぞれに持ち場があり、それぞれに重要 だと考えてください。 一般化も説明仮説も、「すべての場合に当てはまるのか」「本当にその原因・過程でこの結果に至ったのか」などを確かめることで説得力が出ます。 その際には演繹的な推論が欠かせませんし、その論証で誤りがあったら、せっかくの発見が台無しになってしまいます（[実践編]の「 形式面の落とし穴 」、「 非形式面の落とし穴 」を参照）。 気をつけたい落とし穴(前編・形式面)｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts 【最終回】気をつけたい落とし穴(後編・非形式面)｜テストエンジニアのための論理スキル［実践編］ テストエンジニアが身につけておきたいスキルの一つ「論理のスキル」。「論理の言葉」の意味や働きに注意が向くようになったら、文や文章の読み書きで実践していきましょう。この連載では、「論理スキル“実践編”」と題して、「文章の筋道を把握する、主張を理解する... 　続きを読む　 Sqripts 関連記事｜Sqripts この連載では 「一般化」を指向する推論（細部に違いのある形がいくつかあります）を「帰納的推論」として扱います。 「因果関係や結果に至る過程(プロセス)などの説明仮説の発見」を指向する推論を「アブダクション」とします。 なお、アブダクションと呼ばれる形の推論は古代ギリシアには「アパゴーゲー」と呼ばれていたようです。そのギリシア語に当たる英語として提唱者のチャールズ・パース(論理学者・哲学者)がつけた名称が「アブダクション」だそうです。 アブダクションには「誘拐」というよくない意味があるのですが、本連載ではパースの命名を尊重してこの名称を用います。 ちなみに、日本語だと「仮説形成」という語を使う人もいます。 さらに余談ながら、パースはレトロダクションとも呼んでいたそうです。日本語だと「遡及推論」とする人もいます。 「目の前の事実(結果)から“遡って”考え、原因から結果への道筋を説明する仮説を考える」ということでしょう。 （実は）（あんがい）おなじみの論理 帰納もアブダクションも、私たち誰もが生活の中で行なっている推論 です。 図1-2, 1-3を見て、 こうした推論はどちらも、日ごろからしている と感じた人も多いのではないでしょうか（そう感じてもらえそうな例を挙げました）。 また、ミステリーが好きな人はこうした思考に見覚えがあるでしょう。 名探偵が見せる「灰色の脳細胞の閃き」の多くは、帰納やアブダクションを思わせるものがあります。 （そんなわけで、この連載では「品質探偵コニャン」が随所に登場します！） ソフトウェア開発で働く帰納やアブダクション こうした思考は、ソフトウェアの開発でも行なわれています。 特に動作確認やデバッグ以降の作業で大活躍します。 また、開発終了後のプロセス改善(原因分析)などでも重要な働きをします。 図1-6 ソフトウェア開発で働く帰納、アブダクション 私たちが実務でやっていることの一端を振返ってみましょう。ここに挙げた以外にも、「こんな局面でこんな考え方をしている！」と思い当たる人もいるでしょう。 いずれも、 当てずっぽうや“なんとなく”で行なうことではありません 。 動作確認や設計中のデバッグでは……( 帰納的な推測 ) 期待と異なる振舞い(インシデント)が見つかったら、 詳細(入力やデータの内容、操作や手順、設定や構成、etc.)を確認する 詳細の一部を変えて動かし、同じ結果になる場合の共通項を考える （共通項がインシデントの原因かどうか、実際に動かしたり、ソースプログラムを調べたりして確かめる） （共通項から、「詳細の一部を変更したらどのような結果になるか」推測する） テストで故障が検出されたら……( 帰納的な推測 、 アブダクション的な推測 ) 同じ故障を起こしている他のテストがあったら、 詳細(事前条件、入力データ、操作や手順、設定や構成、etc.)に共通項がないか考える 詳細に共通項がある他の機能/フィーチャーに同様のテストをする(類推) 故障を引き起こす原因を考え(仮説)、それに基づいた詳細でテストをする(仮説の実証) テストからのデバッグ（故障の原因究明、欠陥の除去）では……( アブダクション的な推測 ) 当該の故障を起こす原因と、故障に至る過程やそうなる理由を考える(仮説) 原因箇所(候補)を見つけたら、それが故障を引き起こすことを机上で、または実際に動かして再現する(仮説の検証) 欠陥を修正したら当該の故障が起こらないことを確認する(仮説の実証) プロセス改善時の原因分析では……( アブダクション的な推測 ) 対策を施すべきエラー(誤り)について、そのエラーがどの工程で、なぜ発生したか(発生原因)や、なぜ検知できなかったか(見逃し原因)を、結果であるエラーから遡って推測する(仮説) （通常、エラーに至るまで「原因と結果の連鎖」があるので、それぞれについて「結果を引き起こした原因」を掘り下げる） 「原因」を掘り下げたら、「原因」から結果であるエラーに至る過程を机上で再現する(仮説の検証) （「原因」がいくつか考えられる場合は、再発防止にとって最も重要なものを選定する） これらの論理の仕組みや考え方、留意点を、これから見ていきましょう。 参考文献 近藤洋逸, 好並英司 『論理学入門』 岩波書店 1979 鈴木美佐子 『論理的思考の技法Ⅱ』 法学書院 2008 藤野登 『論理学　伝統的形式論理学』 内田老鶴圃 1968 米盛裕二 『アブダクション　仮説と発見の論理』 勁草書房 2007 図版に使用した画像の出典 Loose Drawing 人物画をお借りしています。 品質探偵コニャン：Produced by Sqripts . No Unauthorized Reproduction. The post 【第1回】見つけるための論理｜実務三年目からの発見力と仮説力 first appeared on Sqripts .

この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 ＜QAエンジニアのスタートガイド 記事一覧＞ ※クリックで開きます 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう QAエンジニアやテストエンジニアとしてキャリアをスタートしたばかりの頃、多くの人は「与えられたタスクをこなす」ことに集中してしまいがちです。 しかし、それだけでは充実した社会人生活を送っているとは言えない、と私は考えます。 ここでは、充実したQAエンジニアとして過ごすために大切なことをお伝えします。 それは「目的意識」です。 本記事では、充実したQAエンジニアとして過ごすために欠かせない「目的意識」についてお伝えします。特に、「顧客志向」の重要性を中心に、これがQAエンジニアとしての働き方にどのように影響するかを解説していきます。 筆者の背景 私は最初からエンジニアだったわけではなく、営業職からキャリアをスタートしました。 エンジニアのような「何かをつくる」ではなく、営業職として「サービスを顧客に売る」という、顧客と直接関わるような働き方をしていました。 その後、第二新卒でテストエンジニアとして転職しました。転職後の最初の現場ではテストに限らず、リリース後の保守チームでの仕事にも携わったことがありました。 その中で特に重要だったことは「お客様の声をきちんと聞いて、不満を解消する」ということでした。 これらの経験を通じて、「サービスやプロダクトを使ってくれるお客様が実在する」というリアルな実感を、心に刻んだのでした。 営業と保守の経験から学んだ顧客の存在 営業経験からの学び 営業の働き方は多岐に渡りますが、私が経験した営業は「売り上げノルマに責任を持ち顧客が”注文する”と言ってくれるまでなんでもする人」という働き方でした。 営業を通じて、「どんなに優れた製品やサービスでも売れなければ使われない」という現実を痛感しました。 実際に営業を経験することで、営業職に対する印象も変わりました。これまで私は営業職とは単に「コミュニケーションが得意な人」というフワッとしたイメージしか持っていませんでしたが、実際はそうではないことに気がつきました。 製品や顧客のことをしっかりと理解して、課題に心から共感し、顧客をハッピーにするために全力を注ぐ。その結果として売れるーーそれが重要なのだと感じました。 課題解決を待っている顧客がいて、彼らを満足させることが何よりも重要だったのです。 保守経験からの学び エンジニアになったあと、私はテスト業務だけでなく、保守運用の業務にも携わっていました。ここでの保守運用とは「製品が実際の現場で使われている中でのお客様の困り事を解決する」という業務でした。 テストを十分にしていても、製品が使用されている現場では新たな問題が発生するということがありえます。 実際の現場でしか起こりえない問題もありますし、テストから漏れてしまった問題もあります。そういった問題を解決して、「顧客が求めている価値を取り戻す」という経験をしました。 ここでも私は「実際に製品を使用してくれている顧客がいる」ということを実感するのでした。 製品というものの本質 製品とは、単なる成果物ではなく、「顧客に対して価値を提供するもの」だと私は考えます。 ここで重要なことは、製品を単なる機能やサービスの集まりとして捉えるのではなく、現実の顧客に対して、価値を提供したり、問題解決するものであるということです。価値というものは提供側だけで完結するものではなく、「顧客」がいて成り立つものなのです。 たとえば、ネットワーク機器であれば、「IPv4のプロトコルが使えること」が機能としてあったとしても、実際の価値は「エンドユーザーの利用者が安心してインターネットにつながる」ことだったりします。「ネットワークのプロトコルで正しく通信できる」といった作り手から見た仕様にすぎません。 「正しく動作する」ことだけでなく、あくまで顧客のニーズを満たすことが必要なのです。 QAエンジニアとその使命 QAエンジニアのQAとはQuality Assuaranceつまり、品質保証を担う人だというのが共通理解として成り立つと考えます。本記事では「品質」とは「製品の価値」、保証とは”請け負うこと”ですが、ここでは「最終的に説明と確約ができること」とします。 本記事での品質保証とは「製品の価値が損なわれていないことをきちんと確認して、顧客やステークホルダに対する説明と確約ができる状態」を目指します。 QAエンジニアの使命として、「製品の価値を守り、顧客が期待する、あるいはそれ以上の体験を保証する」というものがあるというのが私の理解です。 品質保証のあり方やロールの定義については様々な考え、文化、規約があることは承知していますが、本記事では上記の位置付けであるとご承知いただければと思います。 製品の価値を守る QAエンジニアの使命には「製品の価値を守る」があります。 まず第一に、「顧客が製品を使うことで被害を被ってしまう状態から守る」ということがあります。これは、製品に問題があった場合に、人の命に関わることや財産を失ってしまうことに繋がってしまう場合があります。あるいはそういった損失に繋がらなくても、個人情報の流出なども挙げられると思います。QAエンジニアはこれらのリスクから顧客を守る必要があります。 次に、「顧客が期待することを達成できない状態から守る」というものもあります。例えば、「せっかくお金を払ってインターネットを使うためにパソコンを買ったのにブラウザが開かないじゃないか」といった、元々顧客が欲していたニーズを満たさない場合があります。「顧客がどう使いたいのか」をきちんと把握して、そうした状況を回避することもQAエンジニアの責務だと考えます。 最後に、「顧客が期待すること”以上”の感動を届ける」という考え方もあります。例えば、全く新しい予約体験を提供するアプリの場合、それらの体験に対しても自信を持って製品を送り出す必要があります。ここでも、ただ単に製品を送り出すだけではなく、「顧客にとってどういった価値があるか」ということを明確にしてリリースする必要があります。 価値を保証する 「価値を保証する」の使命についても言及します。 「QAエンジニアとして自信を持って送り出す」ということは重要ですが、顧客に製品の価値が守られていることをしっかりと説明して、請け負える状態にすることも同じく重要です。 単に自分で確認してそれで終わりではなく、顧客やステークホルダといったQAエンジニア以外の人に対しても理解できるうように、守られた価値についてきちんと報告する、あるいはできるようにしておくことで、QAエンジニアはその役割を十分に果たせたと言えると考えます。 QAエンジニアの仕事を充実させる顧客志向 もし、この記事を読んでいる方がQAエンジニアになりたてで、普段の仕事に対して「こんな作業は退屈だな」といったことを感じている場合、「誰のために仕事をしているのか」を意識してみて欲しいです。 「誰か」があなたの仕事を待っていることに気づいてみてください。そうすることで普段の仕事や業務に意味を見出せるのではないでしょうか。 こうした考え方により実際の仕事の進め方も変わってきます。 たとえばテスト実行の場合、「バグの起票」では「誰にとって困るか」を言語化できます。「顧客にとってどうなるか」をきちんと言語化することで、「バグです」「仕様です」といった不毛な押し問答を防ぐことができます。 また、テスト実行が単なる作業の消化ではなくなります。実際のリアルなユーザーに思いを馳せながらテスト実行ができるということがあります。 さらには、プロダクトのテスト以外の活動にも目を向けることができるようになります。製品が顧客に価値を届けるにあたって必要なものはプロダクトだけでしょうか？ユーザーサポートやマーケティングなどが関わるようなプロダクトに携わる方が多いのではないでしょうか。 「顧客が何を求めているか」をリアルに捉えることで、QAエンジニアとしての仕事にやりがいを感じられるようになると私は考えます。 日本における品質管理での”顧客志向”について 日本における品質管理のあり方として、「TQC(Total Quality Control)」という手法があります。 TQCでは、「顧客志向」が重要な原則とされていますので、もし気になった方はぜひ調べてほしいです。ソフトウェア開発におけるQAの業務に全てが結びつくわけではありませんが、QAにとって大切な原則やマインドセットについて学べます。 参考文献として以下を挙げます 現代品質管理総論 （朝倉書店） 「品質は誰かにとっての価値である」という言葉を聞いたことのある方はいらっしゃると思います。ただ、この文章で「誰か」を「エンドユーザー」と捉えることには誤解があります。 ここで大事なことは「製品へのニーズを持っている人は多様である」ということです。顧客の多様性というのは上記の「現代品質管理総論」でも語られています。 また、「品質は誰かにとっての価値である」の原著を知りたい方は以下の書籍を参考にしてください。 ソフトウェアの文化を創る1 ワインバーグのシステム思考法 （共立出版） また、「価値にフォーカスする」という考え方はプロダクトマネジメントの原則でもあります。品質保証だけでなく、プロダクト作り全般について気になった方は以下の書籍を参考にしてください。 プロダクトマネジメント ビルドトラップを避け顧客に価値を届ける （O’Reilly Japan） おわりに 日々の仕事の中で、「自分は何のためにこの作業をしているのだろう？」と考えることがあるかもしれません。 そんな時は、「誰がこの製品やサービスを待っているのだろうか」と顧客を思い浮かべてみてください。目的意識はQA業務の充実のみならず、自分自身のQAエンジニアライフの充実につながるのではないでしょうか。 【連載】QAエンジニアのスタートガイド 記事一覧 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン 【第2回】「誰のためか」を意識しよう The post 【第2回】「誰のためか」を意識しよう｜QAエンジニアのスタートガイド first appeared on Sqripts .

はじめまして、開発9年生、QAコンサル2年生のせとです。 先日、UI/UX改善のお仕事にて初めてユーザビリティテストについて携わり、様々な気づきを得たので備忘の意味も込めてこの記事で内容の紹介を簡単にしたいと思います。 ユーザビリティとは そもそもユーザビリティとはなんでしょうか？ 感覚的には、サイトの使いやすさや見やすさなどがわかりやすいところかと思います。 ユーザビリティの定義については JIS Z 8521 により定義され、主に人間工学的観点から「特定のユーザが特定の利用状況において，システム，製品又はサービスを利用する際に，効果，効率及び満足を伴って特定の目標を達成する度合い」として概念をまとめられています。 また、 JIS Z 8520 ※1 や JIS Z 8530 ※2 が深く関連しており、この3規格を主として定義づけされています。 ※1 　 JISさんぽ (01) JIS Z 8520:2022 「人間工学－人とシステムとのインタラクション－インタラクションの原則」 ｜Sqripts JISさんぽ (02) JIS Z 8522:2022 「人間工学－人とシステムとのインタラクション－情報提示の原則」 ｜Sqripts ※2 　 JISZ8530:2019 人間工学－インタラクティブシステムの人間中心設計 も併せてご参照ください。 ユーザビリティテストでやったこと 今回AGESTにて実施したユーザビリティテストでは、２つのロールを用いてロールごとの視点から評価を行っていきました。 ひとつは、評価するシステムを詳しく把握している「専門家」、もうひとつは評価するシステムを初めて触る「ユーザー」です。 ２つのロールをベースに、ユーザビリティテストでは大きく分けて2つのテストを実施しました。 ヒューリスティック評価 　←本記事で書く内容 WEBサイトやソフトウェアなどのユーザビリティ(使い勝手や分かりやすさ)を評価する手法の一つで、制作者や専門家がガイドラインや自身の経験則などに照らして評価する方式 ※3 ※3 　 ヒューリスティック評価（ヒューリスティック調査 / ヒューリスティック分析）とは – IT用語辞典 e-Words ユーザーテスト 機器やソフトウェア、WEBサイトなどを利用者に実際に操作してみてもらうテスト ※4 ※4 　 ユーザーテスト（ユーザビリティテスト / 操作性テスト）とは – IT用語辞典 e-Words 今回はヒューリスティック評価について何をしたか、簡単に書きたいと思います。 ヒューリスティック評価 ヒューリスティック評価では、「専門家」としてWEBシステムの評価を行います。 今回の評価にあたり、以下２点のアイテムを用意し、WEBレイアウト、表示物、文章、コントラスト、リンク構成などのWEBサイトを構成する要素から、応答性、操作性、入力規則、制約などのシステムの評価を実施しました。 JIS Z 8520 に記載されているインタラクションの7原則を軸に作成したチェックシート 実際に使用するユーザーを想定した「ペルソナ」とWEBサイト閲覧時の状況を想定した「シナリオ」（ ペルソナ／シナリオ法 ） 実際にWEBサイトを操作していく上でユーザビリティとして明確に低評価となる部分は以下の点がありました。 背景と文字色のコントラスト比の悪さ（コントラストスコアが低く、見えづらい） カルーセルメニューであることがわかりづらい コンテンツの案内が不足している ボタンが小さく押しづらい リンク構成が直感でわかりづらい 一方でペルソナになりきって操作をしていると、普段はあまり気にしないような細かい部分に気づくことが多かったと感じました。 文章の文字サイズ（周囲の文字やバナーなどに埋もれて相対的に見えづらい） ペルソナに対してWEBレイアウトが不親切（ハンバーガーメニューやナビゲーションウィンドウなどがわかりづらい） ペルソナ目線でメインコンテンツがどういうものか理解しづらい いつもは気にならないような部分も、ペルソナ目線（老眼、弱視、操作不慣れ、IT初心者など）で考えたときに「これは使いづらいかも？」を注意深く拾って行く必要があったので、私の人生で一番WEBサイトと向き合った作業だったと思います。 これらの問題点に対して改善案をまとめてお客様へ報告し、改善すべき内容について認識していただきました。 改善案を上げるにあたり、まず意識したことは「現状の状態から整えられるレベルの改善から始められるもの」です。 今回ユーザビリティテストを求められたお客様は、「AGEST目線から迅速かつ的確な改善提案をしていただき、共により良いUI作りができることを期待しています。」と、多大なる期待をいただきましたので、それに応えるべく時間をかけずに改善できる且つ目に見えて変化がわかるところを重点的に挙げていきました。 上記に挙げた問題に対する改善案の提案例として、以下の内容があります。 コントラスト比を改善し、文字の視認性を向上する。 サイト全体の案内を見直し、動線やコンテンツの内容がわかるようなラベリングを意識する。 レスポンシブルデザインを意識し、ボタンやリンクなどのサイズを見直す。 まとめ ユーザビリティは、要件定義としては非機能要件にあたり、開発現場としては性能要件やセキュリティ要件などが重視され他の非機能要件より優先度が低くなりがちです。 しかし、ユーザビリティを軽視した場合に起こりうるリスクとして、使用感の悪さによるサイト離脱率の増加や、悪評によるアクセス率の低下を招きかねません。 そのような事態を防ぐべく、他の非機能テスト（性能テストや脆弱性診断等）と併せてユーザビリティテストを実施してWEBサイトの利便性評価を正しく行い、ユーザーにとって快適で使いやすいWEBサイトへ改善していくことについて考えていただけたら幸いです。 次回後編にて「ユーザーテスト」について書きたいと思います。 ▼AGESTでは、ユーザビリティ診断についてのご相談も受け付けておりますので、ご気軽にお問い合わせください。 UI/UX向上支援サービス｜お役立ち資料｜株式会社AGEST（アジェスト） 本資料では、UI/UX向上支援サービスの概要について詳しくご紹介しています。製品のUI/UXに関する“お悩み”がある方は是非ご覧ください。フォームにご登録頂くと、ダウンロードURLがメールで送付されます。 　詳細はこちら　 株式会社AGEST（アジェスト） 関連情報 <出典> 三樹 弘之，JIS Z 8520 インタラクションの原則．J-Stage JIS Z 8521：2020　人間工学−人とシステムとのインタラクション− ユーザビリティの定義及び概念,日本産業規格 JIS Z 8530：2019　人間工学−インタラクティブシステムの 人間中心設計,日本産業規格 ペルソナ／シナリオ法を使ったユーザー中心のデザイン．株式会社イード．2009 JISさんぽ (01) JIS Z 8520:2022「人間工学－人とシステムとのインタラクション－インタラクションの原則」 ｜Sqripts JISさんぽ (02) JIS Z 8522:2022「人間工学－人とシステムとのインタラクション－情報提示の原則」 ｜Sqripts ヒューリスティック評価（ヒューリスティック調査 / ヒューリスティック分析）とは – IT用語辞典 e-Words ユーザーテスト（ユーザビリティテスト / 操作性テスト）とは – IT用語辞典 e-Words The post 初めてのユーザビリティテスト～前編～ first appeared on Sqripts .

この連載では、1人目QAとしてのチームの立ち上げや組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。 前回の記事 では、QA組織立ち上げのための２人目以降のQAエンジニア採用にあたって考えることについて解説しました。 【第2回】2人目以降のQAエンジニアの採用 この連載では、1人目QAとしてのチームの立ち上げ、組織づくりに関して、私が実践したことや試行錯誤中のことも含めてお伝えします。前回の記事ではQA組織立ち上げの流れや組織の形について解説しました。今回は2人目以降のQAエンジニアを採用する際に私が考えたポイ... 　続きを読む　 Sqripts 関連記事｜Sqripts 今回は、QAエンジニアの採用が進んだ先でチームとして成果を出すための、チームビルディングについてご紹介します。 QAエンジニアに限らずどのロールにおいても、ただ採用を行ってメンバーを増やせばよいわけではありません。メンバーがその能力を発揮し、成果を出すための仕組みや関係構築が必要です。私も現在所属している部署では、QAエンジニアを採用しチームを構築している最中です。採用やチーム構築にあたっては、過去に所属していた企業でのノウハウを用いて取り組んでいます。本記事では、チームビルディングに関する一般的なポイントから、とくにQAチームにおいて重要な点についてご紹介します。 そもそもチームビルディングとは QAチームの話に入る前に、まずは一般的なチームビルディングについて見ていきましょう。 チームビルディングはチーム（組織）をビルド（構築）することですが、前述の通り単純に人を集めるだけではいけません。『チーム・ビルディング[新版] 人と人を「つなぐ」技法』によると、チームビルディングとは「チームを機能させるための働きかけ」である、とされています。 チーム（組織）は、グループ（集団）とは違います。チームがチームであるためには 共通目的 貢献意欲 コミュニケーション が必要です。チームビルディングではこれらの要素をそろえて、個人の集まりであるグループから、共通の目的に向かうチーム（組織）へと進めていくことになります。成果を出せるチームに育てていくこと、と捉えても良いかもしれません。 チームビルディングの基本ステップ 同書では、チームビルディングの基本ステップ、という考え方が紹介されています。 『チーム・ビルディング』P31 図1-10 チーム・ビルディングの基本ステップ をもとに作成 チームビルディングの要素としてよく雑談などが取り上げられます。これらは①会話に該当し、チーム内の関係性を築く、土台としての役割です。チームビルディングにはその先があり、対話や議論を通じて意味の探求・行動の変革につなげ、そしてふりかえり（省察）をしてチームづくりにフィードバックと続きます。 QAチームでのチームビルディング ここまでは、一般的なチームビルディングの定義や意味について説明しました。ここからは、QAチームの立ち上げフェーズを、タックマンモデルで考えてみましょう。 タックマンモデル 『チーム・ビルディング』P19 図1-3 タックマンモデル をもとに作成 タックマンモデルとはチームの成長の段階を表したもので、以下の4段階があります。 形成期：メンバーが集まり関係性を築く時期 混乱期：メンバーの考え方の枠組みや感情がぶつかり合う時期 統一期：共通の規範や役割分担ができあがっていく時期 機能期：チームとして機能し、成果を出していく時期 ※各期の呼称は情報源によって複数ありますが、今回は前述の書籍に合わせています。 チームビルディングをうまく行うことで、機能期に至るまでを早められます。 QAチーム形成期 形成期はメンバーが集まり関係性を築く時期のため、とくにチームビルディングにおける基本ステップのうち、 ①会話 を通じた土台づくりが行われると考えています。 雑談や分報（Times）などを通じて会話や自己開示の機会を増やし、相互のキャラクターなどを理解する施策が一般的です。 このほか、エンジニアチームの形成期には「スキルや得意分野の可視化」を行うのが個人的にオススメです。QAチームのメンバーそれぞれが 【第1回】QA組織立ち上げの流れと組織の形 | Sqripts でも触れたQMファンネルにおけるスペシャリティ QAスキルアセスメントの結果 今こそQAスキルアセスメントについて考えてみた（JaSST新潟レポートにかえて） | Sqripts QAのスキルアセスメントシートを作って適用してみた – freee Developers Hub Test.SSFをもとにした所有スキル Test.SSF Skill Standards Version 1.0 などを可視化・共有することで、相互のスキルや得意な分野を把握できます。このようなスキルの可視化・共有は関係性作りに有効で、とくに「誰が何をできるか」だけでなく「チーム全体として経験がない分野は何か」がわかります。補うための勉強会を開催してさらなるコミュニケーションの機会にしたり、QAエンジニア教育のための仕組みやコンテンツ整備をしたり、といったアクションが取れるためです。 QAチーム混乱期 「混乱」や「感情がぶつかり合う」というと表現が強めなので、どちらかといえば「方向性がまだ定まっていない時期」くらいに捉えておくのが良いと考えています。 QAチームを立ち上げてメンバー間の関係性が出来てくるとともに、チームとして会社や組織の中でどのように価値を発揮するのかや、ミッション、業務の進め方など大きなレベルのものごとを定める必要があります。 個人的な意見ではありますが、この「チームのミッションや方向性を定める」という活動自体が、とくに立ち上げ中のチームにおけるチームビルディングでは大きな意味があると考えます。もちろん組織化ができあがったあとであれば仕方ありませんが、チーム立ち上げのいわゆる初期メンバーとしてJoinするのであれば、そのチームの方向性や大きな意思決定に関われないと面白くありませんよね。 私もまさにQAチームを立ち上げている最中ですが、最初に自分が立てた「QAチームのミッション」等はメンバーがJoinしてある程度組織の状況をキャッチアップしてもらった時点で、一緒に再検討するようにしています。 QAチーム統一期 統一期は、共通の規範や役割分担ができあがっていく時期、です。形成期のところでスキルや得意分野の共有について触れましたが、そこでトライした分担などが固まってきます。この段階では、チームの方向性と現在とのギャップもハッキリしてくるため、たとえば「SET:Software Engineer in Testが必要」といったロールごとの明確な人材募集をかけたり、あるいはQAチームと開発チームの関係性についても形が見えてくるころです。 QAチームの形のパターンについては、 第1回 アジャイルな品質・QA組織パターン | Sqripts も参考にしてみてください。 混乱期から統一期にかけて、チームビルディングの基本ステップにおける ②対話 や ③議論 に相当するやりとりが必然的に増えてきます。ここで細かいテクニックですが、定例会などで雑談タイムを設けていた場合は、雑談＝ ①会話 のためのMTGと、チームとしての方針や個々の業務について話し合うMTGをそれぞれ別枠で用意するのがオススメです。混ざっていると、業務のトピックによって雑談が飛んだり、逆に雑談が盛り上がって議論の時間がなくなったりするので、明確に分けたほうがいいですね。 QAチーム機能期 機能期は、チームとして機能し、成果を出していく時期です。ここまで来ればあとは何もしなくてOK・・・ではありません。チームビルディングの基本ステップにあるように、 ④省察 を行いながら、関係づくりなどのステップが回っていきます。「チームができあがったのでもうコミュニケーションは減らしていいよね」とはいきませんよね。 ベースができて安定してきたチームでより成果を出すために、 QAエンジニアの育成・教育 QAエンジニアの評価 なども（もしまだあいまいであれば）整備する必要があります。 まとめ 今回はチームビルディングの概念や考え方の説明と、QAチームにおけるチームビルディングについて、タックマンモデルの各段階をもとに概要をご紹介しました。 ポイントになるのは、単純にコミュニケーションの機会を増やせばよいというわけではなく、そこから対話や議論へと進めていくことです。そのためには、チームの方向性・ミッション、チームの構造パターンなどを一緒に考え、試行錯誤することが大切だと考えています。 今回ご紹介した書籍以外にも、チームビルディングやエンジニア組織に関する書籍や資料は数多くあるため、ぜひ読んで参考にしてみてください。 参考 チーム・ビルディング[新版] 人と人を「つなぐ」技法（日本経済新聞出版） チーム・ジャーニー 逆境を越える、変化に強いチームをつくりあげるまで（翔泳社） 【第13回】人がプロジェクトの源泉！チームは育てて強くする［後編］ | Sqripts 【連載】QA組織の立ち上げ方－1人目QAが語る実践と工夫－ 記事一覧 【第1回】QA組織立ち上げの流れと組織の形 【連載初回、全文公開中】 【第2回】2人目以降のQAエンジニアの採用 The post 【第3回】QAチームビルディング first appeared on Sqripts .

新卒でフロントエンド開発者をしています、イソダです。 本記事では、私があるプロジェクトで技術選定を行う際に活用したツール「Genspark」とその機能「Sparkpage」について、その利用体験を通して得た知見を共有します。 Genspark、Sparkpageとは？ Genspark は、AIを活用した検索ツールです。自然言語での質問に対して、ウェブ上の複数のソースから関連情報を収集し、回答を提供してくれます。 Gensparkには「 Sparkpage 」という便利な機能があります。この機能は、AIによる調査結果を基に、ウェブサイトのブログ記事のようなものを作成してくれます。 Sparkpageのメリットは次が挙げられます。 目的に合った情報を即座に提供 利用者が調査したい対象に特化したウェブページが存在しない場合でも、AIが最適なブログ記事を作成してくれます。 カスタマイズ可能な情報提供 情報収集や特定のテーマに合わせたページ作りが簡単です。 活用シーンとしては、次のような場合が挙げられます。 希望する調査対象にぴったり合った情報が見つからない。 独自の目的に合わせた情報をブログ形式でわかりやすく提示したい。 Sparkpageは、情報収集やコンテンツ作成を効率化したい人にとって強力なツールです。 Gensparkを使用した動機 今回の技術選定を進めるにあたり、次のような理由からGensparkを利用しました。 インフラに関する知識が不足していた。 技術選定する対象に関する基礎知識が不足していた。 限られた期間内での調査・分析が必要だった。 調査対象 今回の調査対象はChange Data Capture（CDC）サーバーというものです。データベース内の変更データをキャプチャし、リアルタイムで別のシステムに転送する技術です。この技術を利用することで、データ同期やイベントドリブンなアーキテクチャの実現に役立てることができます。 今回の技術選定では、以下の3つのCDCツールを検討しました。 PeerDB Debezium pgstream これらのツールについて、それぞれのメリットとデメリットを検討しました。 Gensparkでの実際の調査 ここでは、Gensparkを使用して実際に行った調査の内容を紹介します。 調査の流れ 1. 質問の入力 Gensparkのインターフェースに、今回知りたい内容をそのまま入力しました。(音声入力した内容をコピペしてるので、文章は一部誤りがあります) Gensparkへの質問 2. 情報の収集1 Gensparkは、複数のソースから情報を収集し、以下のような回答を提供してくれました。 スクリーンショットは回答の一部ですが、それぞれのツールのメリットデメリットを挙げてくれています。 Gensparkの回答内容 回答の文章の末尾にある丸1, 丸2, …は参照した文献を示しています。カーソルを合わせてURLリンクをクリックすることで参照文献に飛ぶことができます。 参照文献 3. 情報の収集2 回答の下の方にはSparkpageができています。 回答結果にあるGensparkpage Sparkpageを見ると、今回知りたい内容にぴったりのブログ記事が作成されています。 Sparkpageの目次 Sparkpageの「はじめに」にはCDCサーバーの概要を簡潔にまとめてくれています。 「はじめに」の章でCDCサーバーの概要とユースケースを紹介してくれている 次に続く章で各ツールの特徴と利点、デメリットを説明してくれています。 PeerDBの特徴と利点 pgstreamの特徴と利点 各方法のデメリット 「Googleクラウドでの実装」の章では、各ツールがGoogle Cloud Pub/Subと統合できるかを解説してます。 Googleクラウドでの実装 この章でpgstreamはGoogle Cloud Pub/Subと統合できるかの正確な回答がなかったので、筆者自身が追加の調査を行い、統合できることを確認しました。 Googleクラウドでの実装」内のpgstreamに関する段落。Pub/Subに関する記述がない 最後の「結論と推奨事項」では、各ツールのメリットデメリットを比較して、ある評価軸ではどのツールが優れているかの解説をしてくれています。 結論と推奨事項 Sparkpageを読むことで、 CDCサーバーの概要 各ツールのメリットデメリット Google Cloud Pub/Subと統合できるかどうか ツールを選択する上の評価軸と各評価軸においてどのツールが優れているか を一度に把握することができました。 4. 情報の分析と確認 Gensparkによってある程度の情報を収集できたので、それを参考に分析と情報の不足を補ったり、AIの回答が正しいかの調査を行いました。具体的には、Gensparkが挙げてくれたメリットデメリットを参考に評価軸を決めて、その軸に沿って追加の調査を行ったり、AIが提示してくれた参考文献を読み込んでAIの回答に間違いがないかの確認を行いました。 基礎知識は既に把握できてるので、追加の調査もすいすい進みました。 このように、Gensparkを活用することで、効率的に情報の収集と分析を行うことができました。 Gensparkが活躍したポイント 今回のプロジェクトでは基礎知識が乏しい状態だったため、いきなりツールを試すのではなく、事前にそれらの背景や特徴を理解しておくことが重要でした。その際にGensparkが以下の点で役立ちました。 基礎知識の迅速な習得 初心者でもわかりやすいCDCサーバーの概要を含めたブログ記事を提示してくれました。 各ツールのメリット・デメリットの比較情報を提示 3つのツールを横並びで比較できる資料を提供してくれたことで、調査の効率が大幅に向上しました。 これによって、短時間で各ツールの概要や特徴を理解し、より適切なツール選定を行うことができました。 まとめ 技術選定において、基礎知識の習得や情報収集は多くの時間を必要とします。特に私は、インフラやデータベースの経験が浅いため、知識のキャッチアップを効率よく行うことが大きな課題でした。しかし、Gensparkを活用したことで、限られた時間の中でもスムーズに調査と分析を進めることができました。 The post 技術選定の調査がGensparkで捗った話 first appeared on Sqripts .

ソフトウェア開発の世界では、アジャイル開発やスクラムが一般的になってきました。そのアジャイル開発のコアとも言えるのが、対話や協調です。この連載では、アジャイル開発におけるコミュニケーション・コラボレーションスキルを解説しながら、ファシリテーションスキルのレベルアップを目指します。 ＜スクラムマスターのためのコミュニケーション講座　連載一覧＞ ※クリックで開きます ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ ・ 実践1on1[4] 〜 実例をもとに1on1をレベルアップ ・ 【最終回】さらなる成長のためのコミュニケーショントレーニング 最終回のテーマは「コミュニケーションのトレーニング」です。 前回のおさらい 前回までは、ファシリテーション、コーチング、1on1と、具体的なコミュニケーション技術を解説してきました。この連載の最後は、学んだ技術を磨いていくための技術の解説です。 人見知りでもアジャイルコーチはできる 私は独立して、アジャイルコーチとして仕事をしています。前職などではエンジニアリングマネージャとして、メンバーの育成や採用を通して部署の立ち上げを行っていましたが、もともとコミュニケーションが得意な人間ではありません。 たとえば、もう40歳を超える年齢になりましたが、買い物に行って店員さんに「あの、この服のMサイズありますか？」と聞けません。店員さんが忙しそうなら「買うのやーめた」とすぐ諦めます。イベントの懇親会などにも多く出席しましたが、話かけるのが苦手なので、たいていは会場のすみっこでちびちびビールを飲んでいます。 こういう話をお客さまに話すと「またまた〜」と一蹴されますが、この話は本当です。こんな私でも、仕事で訓練を積むことで、人並みにコミュニケーションスキルを身につけられるようになりました。 コミュニケーションが苦手な人は多いですが、コミュニケーションスキルはあとでどうにでもなると思います。 それでは、どのようにそのスキルを学んでいくかを考えていきます。 国際コーチング連盟の認定資格を学ぶ 国際コーチング連盟（通称ICF）は、国際的なコーチング資格を運営している団体です。日本にも支部があります（ 一般社団法人国際コーチング連盟 日本支部 ）。 ICF認定資格 は、ACC（アソシエート認定コーチ）、PCC（プロフェッショナル認定コーチ）、MCC（マスター認定コーチ）の3つがあり、毎年多くの人が認定されています。 個人的な感覚になりますが、普段から1on1などに慣れているならACCは簡単だと思います。しかし、PCCになると独学では難しい部分があるため、スクールで様々な人とセッションを持つのがおすすめです。PCCにもとめられるレベルは、PCCマーカーという形で公開されているので、PCCマーカーの内容を眺めてみるといいでしょう（参考： PCCマーカーを使いコーチとしてのスキルや振る舞いを鍛えていく方法 ）。 MCCレベルは達人です。コミュニケーションの取り方、間、質問内容、ふるまいかた、どれをとっても自然な所作なので、わかるひとにしかわからないスキルに感じています（私自身もPCCの勉強をすることでMCCのすごみに気がつきました）。 ICF認定資格は、国内にも認定スクールがたくさんあるので、自分にあったスクールに通うといいと思います。 期間的にはACCやPCCで1年ずつぐらいかかります。これはスクールで単位（CCUと呼ばれる）を取るのに時間がかかるからです。また、ICF認定資格は最低限必要となるコーチング経験がACCだと100時間以上、PCCだと500時間以上、MCCだと2,500時間以上必要になるため、条件を満たすために時間がかかる人も多いです。 アジャイルコーチやスクラムマスターの仕事をしているなら、ICFは基礎的なコーチングスキルを学ぶのにぴったりです。最近だと、海外企業で専任コーチを雇う傾向が強く、今後、国内でも専任コーチが求められてくると思います。実際に、専任コーチをやとっているIT企業もあります。ICFのコーチングはとても純粋で、独自路線を嫌い、王道を歩み続けている印象があるため、基礎を学ぶにはピッタリと言えます。 コミュニティで学ぶ コーチングなどは地元にコミュニティがあったりします。私の場合、お世話になったメンターコーチにおすすめされた 日本コーチ協会神奈川チャプター に所属しており、イベントなどにたまに参加して腕を磨いています。 スクールは比較的高い金額を身銭を切って参加している方が多い影響か、比較的意識高く学ぼうとする人が多いため、企業向けのビジネスコーチを目指す方が多い印象があります。 一方、ローカルのコミュニティだと、料金は抑えめです。その影響か、主婦や定年を迎えた方など、一般の方々が多い印象です。一般的なパーソナルコーチを目指すのであれば、お互いいい練習相手になると思います。 ファシリテーションであれば、 FAJ：特定非営利活動法人 日本ファシリテーション協会 があります。基礎講座が定期的に開催されており、とっかかりとして学ぶには最適でしょう。コーチングを学んだ方であれば、ファシリテーションの基礎講座に共通点が多いことに気が付きます。傾聴や質問は、両者に共通するスキルなのです。 1on1で学ぶ 私は一人で働いているため、客観的に自分を見てくれる人がお客さましかいません。たとえお客さまでも、厳しいフィードバックを伝えにくいと思う方も多いです。 そこで、私の場合は、信頼できるパートナーを選んで、定期的に1on1をしてもらっています。パートナーも似たような仕事をしているので、お互いに悩みを持ち寄ったり、共通のテーマで意見を交換したりしています。 現在1on1をしているパートナーとは付き合いも長く、家族ぐるみの付き合いなので、定期的な1on1が近況報告にもなっています。 コロナ全盛期では、外部とのやりとりが途絶えてしまいましたが、こういったつながりによって、切磋琢磨することができました。 自分たちで学ぶ 先生役がひとりいればとてもよいですが、もしいなければあなた自身が先生になればよいでしょう。認定資格やコミュニティで学んだことを現場で実践すれば、わかっていること、わかっていないことが明確になり、どんどんスキルが付いてくるでしょう。 1on1やふりかえりのあとに、ふりかえりのふりかえりをするのも有効な手です。 今回良かったところはどこか？ 今回いまいちだったところはどこか？ 次にどう活かすか？ を簡単にふりかえり、改善サイクルを回していきます。 1on1だと上司部下の関係が多いので、部下に聞くのをためらう人も多いはずです。しかし、1on1は相手の場です。いいところやいまいちなところを正直に話してもらえる関係性を築けば、1on1は成功したも同然でしょう。 ＊ この連載では、「スクラムマスターのためのコミュニケーション講座」と題して、スクラムマスターに求められるコミュニケーションについて解説してきました。コミュニケーションスキルは、スクラムマスターだけでなく、アジャイルコーチやエンジニアリングマネージャ、ソフトウェア開発に関わる方であれば、必ず役立つスキルだと思います。 エンジニアに限らず、人として生きる限り、一番良く使うスキルかもしれません。 それなのにコミュニケーション技術は、なかなか教えてもらえません。なんとなくMTGを仕切ったり、ファシリテーションをやったりする機会は多いのに、具体的なスキルアップ方法が学びにくいのはとてももったいないことだと思います。 そんな思いからできたのが「チームが自走するためのコミュニケーション入門」というトレーニングでした。毎回やるたびに改善を重ね、バージョンはv2.1になっています。この記事はこのトレーニングをベースにしています。 今回は、コミュニケーショントレーニングについて解説しました。 これまでにコミュニケーション技術を解説してきたので、具体的な手段を手に入れることができたはずです。さらに今回、腕の磨き方も解説したので、やる気さえあればどんどん上達できる場が整いました。 次はみなさんが、その成果を発揮する番です！ みなさまの現場において、すばらしいコミュニケーションが行われ、素晴らしいプロダクトが生まれることを祈っています。 連載一覧 ・ #イントロダクション：優れたスクラムマスターが絶対に言わないこと 【連載初回、全文公開中】 ・ あなたの提案はなぜ受け入れられないのか？｜ファシリテーション技術-1- ・ よりよい場を作るための9つのルール［前編］｜ファシリテーション技術 -2- ・ よりよい場を作るための9つのルール［後編］｜ファシリテーション技術 -3- ・ コーチング技術 〜 基本技術を学ぼう｜コーチング技術 -1- ・ コーチング技術 〜 質問力を高めよう｜コーチング技術 -2- ・ 上級者が活用する質問例｜コーチング技術 -3- ・ 実践1on1[1] 〜 簡単だけど難しい1on1 ・ 実践1on1[2] 〜 コミュニケーションの方法を使い分けよう！ ・ 実践1on1[3] 〜 相手に合わせたコミュニケーション方法とは？ ・ 実践1on1[4] 〜 実例をもとに1on1をレベルアップ ・ 【最終回】さらなる成長のためのコミュニケーショントレーニング The post 【最終回】さらなる成長のためのコミュニケーショントレーニング first appeared on Sqripts .

こんにちは！QAエンジニアのうえやまです。 現在、E2Eテスト自動化に携わっている中で「メンテナンス性の高いロケーター」を使うことの大切さを実感しています。 本記事では簡単なロケーターの解説から始め、私が普段意識しているロケーターの書き方を実体験とあわせて紹介していきます。 ロケーターとは？ UI自動テストツールにおいて「入力欄」や「ボタン」等の要素を指定する部分です。例として以下のように書きます。 id=signIn ：システムIDがsignInの画面要素 xpath=//input[1] ：上から１番目の入力エリア xpath=//button[text()=’サインイン’] ：テキストが「サインイン」のボタン ※細かい文法はツールによって異なるようですが、本記事ではSeleniumに近い文法で紹介します。 「良い」ロケーターとは？ 良いロケーター＝メンテナンス性が高い＝変更が入っても壊れづらい メンテナンス性とは「コード/スクリプトの保守性」を指します。 変更とは主に「ソースコードの変更」を指します。（e.g. 要素の階層変更、テキストの変更） 以下のような変更があった際はスクリプト修正が必要になります。 仕様の変更 オブジェクトIDの変更（要素をID指定している場合） ⇒ツールによっては自動修復してくれるものもあるようです。 一意のロケーター idとname どちらも識別子としての役割を果たしますが、以下の違いがあるようです。 idは一意性あり nameは一意性なし（グループ化された要素の識別に使用されることが多いとこのこと） nameを指定する場合は画面上で一意であるか確かめる必要がありそうですね。 次に、「xpath」で一意性を持たせる書き方を紹介します。 水色の要素を指定したい時、以下だけだと当てはまる要素が複数あります。 //a[@class=’hoge’] ですが、親要素も指定することで一意にすることが出来ます。 //li[@id=’topics2′] / a[@class=’hoge’] 「xxが存在すること」のような期待値確認でこれらを意識することで、「Aのテーブルに存在することを確認したかったのに、Bのテーブルに存在する時でもOK扱いになってしまった」のようなミスを防げます。 汎用性の高いロケーター テストを作っている時に「これ他のケースでも使うだろうな」と思った部品（e.g. ログイン動作、データの初期化）は共有ステップとして登録しておくと後が楽になります。またスクリプトの可読性も上がります。 さらに汎用性の高いロケーターにしておくと「過去の自分ナイス！」または「○○さんさすが！」ということになります。 例えば自分が今作っているのはタブAのテストだとしても、BとCもテストすることが決まっているなら変数にして他のタブでも選択出来るような作りにしておくと良いです。 Tips : text指定の使い分け text指定する場合は「文字列自体が正しいかチェックしたい時」または「変更されにくいテキストであること」が望ましいと考えます。 経験談として、ツールが推奨してくるtext指定のロケーターをやみくもに採用し、ソースコードのリファクタが入った際に元々入っていたスペースが消えてＮＧが多発するということがありました。影響範囲の調査と対応に１日かかり、その後も何らかのコード修正がきっかけで同じ問題が散見されてます。text以外で指定するか、containsを使った部分一致で文字列指定していれば防げた例です。 どんなロケーターを使うとより良いテストが出来るか、またリスクがあるか考えながら実装出来ると良いですね。 実践編 私がロケーターを作成する時の方法を紹介します。 テストを作っていると、ツールのロケーター生成には出てこないけど「こういう感じで要素指定したいから自分で書きたいな」という箇所が出てきます。その時に一々ロケーターを実装して流して失敗してを繰り返すのは大変なので、以下の方法でパスが通ることと一意であることを確認してから実装します。 F12または右クリック→検証で開発者ツールを開く ctrl+Fでセレクター検索窓を出す パスを書いてみる ヒットすれば要素にハイライトが当たります。画像では右下の数字が「3 of 6」になっていて、「同じパスの要素が6個あるうち、今は上から3個目にハイライトが当たっているよ」という意味になります。 目的の要素を一意に指定出来るまで試行錯誤する 1 of 1になったら成功。パスをコピーして実装する。 今回は親要素を指定して一意にしました。 おまけとして、ロケーターを探してくれるツールも紹介します。 POM Builder Chromeのアドオンに入れて、先ほど紹介した開発者ツールの中で使うツールです。 お手軽に推奨のロケーターを生成してくれます。 ただ、万能ではないので複雑なロケーター指定をしたい場合はやはり自分で作成する必要があります。 最後に 私自身も自動テストについてはまだまだ研究中ながら、実践を通して得た知識を紹介しました。テスト実装初心者の方やロケーターの書き方に興味がある方に少しでも参考になれば幸いです。 メンテナンス性が高いロケーターを書いて、壊れづらい自動テストを作りましょう！ 最後まで見ていただきありがとうございました。 The post メンテナンス性が高いロケーターを書いて、壊れづらい自動テストを作ろう！ first appeared on Sqripts .

あなたはQAエンジニアとして、どのようにキャリアを積んでいけばよいか、迷ったことはありませんか？ 私はたくさんあります。 組織やプロジェクトによって、QAエンジニアの役割や責務は大きく異なります。しかし、どんな環境でも共通して押さえておくべきポイントが存在します。 『目的』『ハードスキル』『ソフトスキル』『継続的な学習』『マインドセット』『仲間』です。 この連載では、ソフトウェア開発のQAエンジニアとして働き始めた皆様に向けて、私の実体験をもとに「こんなことを知っておけばよかった」という、ちょっとした気づきを共有します。 一緒にソフトウェア開発のQAエンジニアとしての充実したエンジニアライフを築くためのヒントを探っていきましょう。 連載の第一回となる本記事では、それらのポイントについて概要を紹介したいと思います。 これらのポイントは、続く第2回以降の記事で深堀りしていきます。 なお、本連載では今後”QA”と表現していますが、これは単にソフトウェア開発におけるQAを指します。 顧客のことを考えて仕事をしよう 仕事の『目的』は、単にタスクをこなすことや数字を上げることではありません。最も重要なことは「顧客に価値を届けること」だと私は考えています。 つまり、「あなたの仕事を待っているお客様がいる」ということです。 こういった視点はQAエンジニアにとっても非常に大切です。 あなたがテストや品質保証の活動で携わっている製品やサービスは、必ず誰かにとって価値があります。 その価値を守り、きちんと届けることがQAエンジニアとしてのあなたの役割です。 これらの考えは、TQCにおける「顧客志向」という原則にも通じる部分があり、QAエンジニアとしても参考にしていただけると思います。 本テーマは連載の第2回で取り上げます。 QAエンジニアの必須スキル：ソフトウェアテスト 一言でQAエンジニアと言っても、多種多様な役割やあり方が存在します。 とはいえ、その中でもソフトウェアテストは基本的なスキルだと言っていいのではないでしょうか。 テストという活動は、高品質の製品を、自信を持って世の中に送り出すために必要不可欠な活動の一つです。 QAエンジニアとして重要な『ハードスキル』として、ソフトウェアテストについて知り・理解し・考えていくことが、あなたのQAエンジニアとしての活動を充実させる道標になると思っています。 本テーマは連載の第3回、第4回で取り上げます。 チームで働いているということ QAエンジニアとして、一人で働いていることはほとんどないのではないでしょうか。 QAエンジニアが専任のロールとして置かれている現場では、まず誰かが何かを作らないと品質保証の活動ができない場合がほとんどだと思います。 QAエンジニアに課せられた責務を一人で完結させられる人は稀です。実際にQAエンジニアは様々なステークホルダーと協力して、効率的に、そして効果的に仕事を進める必要があります。 『ソフトスキル』として、チームプレイヤーとしての心構えや、効果的で誠実なコミュニケーションの取り方についてきちんとキャッチアップして、チームの中で貢献することが必要となります。 QAエンジニアにとってチームで働くということは、個々の役割を理解し、他のメンバーとの協力を通じてチーム全体でより良い製品を顧客に提供することを目指すことです。 本テーマは連載の第5回で取り上げます。 スキルアップするためのスキルをつける 一般的に、IT業界では技術や知識体系のアップデートが早いと言われています。これは事実です。 QAエンジニアも同様に、この先生き残るためには学習を継続して、自分を成長させることが必要不可欠になります。 これはスキルアップすること自体をスキルとして捉えて、身につけることと同じです。 『継続的な学習』をするために必要な習慣や心構えを知り、自走できるQAエンジニアとなることが成長への道を開くと考えます。 また、学習をするために様々なプラットフォームを利用したり、イベントに参加することもいい手段だと思います。 本テーマは連載の第6回で取り上げます。 目の前の現場を改善するマインドセット スキルや知識だけでQAエンジニア生活を充実させるのは難しいでしょう。 学んだ知識やスキルを実践し、現場の働き方を改善できてこその良いQAエンジニアではないかと私は考えます。 QAエンジニアは仕事の性質上、様々な問題や課題に出会うことになります。 これらの問題や課題について、決して他責にして終わってしまうのではなく、自分から改善のきっかけを作っていけるような動きが求められます。 そのためには、柔軟な思考や前向きな考えといった『マインドセット』を身につけることが必要になります。 これらはエンジニアとしてだけではなく、どんな職種においても力を発揮できるマインドセットです。 本テーマは連載の第7回で取り上げます。 あなたは一人でない ここまでのポイントをしっかりキャッチアップして頑張っていても、実際の職場では孤独に感じることはあると思います。 「改善したいのは私だけでは？」「努力しているのは自分だけでは？」と感じてしまう日もあります。 もしそう感じているのならば、そう感じているのはあなただけではないと、私は断言できます。 社内に仲間がいないと思ったら、思い切って社外に飛び出して『仲間』を探してみましょう。 QAというニッチな領域にも様々なイベントやコミュニティが存在します。 また、QAだけではなく、様々なエンジニアコミュニティや他業種のコミュニティに参加するのもいいと思います。 本テーマは連載の第8回で取り上げます。 一番大切なのは自分自身 これらの内容は今後の連載のアウトラインとなりますので、今後読んでみたいと思ってくださった方はぜひSqriptsへの 会員登録 をお願いします。 記事執筆時点(2024/11/27)では無料で会員登録が可能です。 本記事ではもう一つだけ、紹介したいことがあります。 社会人として一番大切なことはなんでしょうか？ ビジネスマナーやマインドセットやスキル、もしかしたら人脈と思う方もいらっしゃると思います。 私は全部違うと思います。 一番大切なことは『体調管理』です。 体調を崩してはどんな仕事も充実しませんし、自分自身がいい状態でいることはよりよい人生を歩むために大切なことです。 どんなに優れたスキルや知識があっても、体調管理ができなければ充実したQAエンジニアライフは続きません。 心身の健康を維持して、QAエンジニアとしての道を力強く進んでいくために、まず自分自身を大切にしてください。 自分自身の健康のために、以下の書籍から学ぶことをおすすめします。 今後の連載では、それぞれの記事で同様の形で私からおすすめの書籍を紹介していきます。 ヘルシープログラマ ｜O’Reilly Japan 「アジャイル式」健康カイゼンガイド ｜翔泳社 セルフケアの道具箱――ストレスと上手につきあう100のワーク ｜晶文社 それでは皆さん、健康を大切にしながら、充実したQAエンジニアライフを楽しんでください！ The post 【第1回】充実したQAエンジニアとしてスタートするためのガイドライン first appeared on Sqripts .