みなさんこんにちは。 「ソフトウェアレビューをエンジニアリングっぽく捉える会」の”弦音”です。 今回は「何のためにやるの？」がテーマです。 ＜ソフトウェアレビューをエンジニアリングっぽく語ってみる　記事一覧＞ ※クリックで開きます 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） 【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2） 【第5回】［#2］何のためにやるの？ レビューって、何してますか？ 「これ、レビューしておいて」「さて、レビューしようか」 さて、レビューと言われて何を思い浮かべますか？ 誤字脱字を探すのでしょうか。 仕様の抜け漏れを調べるのでしょうか。 設計や実装に問題がないかを評価するのでしょうか。 どれもレビューで行われることですが、これだけだとレビューの目的を十分に表しているとはいえません。 レビューでは、成果物を読み、内容をさまざまな観点から評価します。その結果、問題や改善の余地が見つかれば、指摘や提案として伝えます。 ここで見つける問題や改善の余地とはどのようなことでしょうか。 レビューで指摘すること レビューでまず思い浮かぶのは、成果物に含まれる欠陥をみつけることです。 ここでいう欠陥とは、成果物に含まれる不備があることや、要求・仕様に合っていないことを意味します。 たとえば、次のようなものです。 要求や仕様と異なる内容が記載されている お客様が本当にやりたかったことと仕様がずれている 計算式や条件分岐に誤りがある 必要な処理や仕様が抜けている 前提条件が考慮されていない 仕様の解釈が曖昧で、関係者によって理解が分かれる ドキュメント内に誤字脱字衍字がある このような欠陥は、発見した時点で指摘し、修正する必要があります。 しかし、レビューで扱うのは、すでに存在している欠陥だけではありません。 現在は問題なく動作するように見えても、将来、問題につながる可能性があります。たとえば、データ量が増えると性能が低下する恐れがある、構造が複雑なので保守が難しい、アクセス権限の設定が不十分である、といったケースです。これらはレビューでは欠陥ではなくリスクとして扱います(一緒に扱うこともあります)。 また、欠陥やリスクには該当しなくても、よりよい方法を提案できる場合があります。処理結果は同じでも、より効率的なアルゴリズムを選べるかもしれません。現在の仕様でも要求を満たしていても、別の仕様のほうが利用者にとって使いやすいかもしれません。 このように、レビューで指摘するものには、次の三つがあります。 欠陥 ：要件や仕様を満たさない不備や欠点 リスク ：将来、障害や損失につながる可能性 改善点 ：欠陥やリスクではないものの、よりよくできる点 レビューでは、これらを見つける(指摘する)ことが目的だ、と考えてよさそうです。 レビューで指摘するものの深堀（何に着目しているか） レビューで指摘する欠陥やリスク、改善点にはどのようなものがあるかもう少し見ていきましょう。 たとえば、次のようなものがあります。 表1　レビューで着目しているものの例 機能性 要求された機能を実現できるか 信頼性 障害が発生しにくく、発生時にも適切に対応で 効率性 性能に関すること。必要な処理速度やデータ量に対応できるか 安全性 不正アクセスや情報漏えいなどのリスクを抑えられているか 使用性 利用者にとって理解しやすく、操作しやすいか 保守性 将来の修正や機能追加を行いやすいか 運用性 監視、障害対応、バックアップなどを適切に行えるか 互換性 他のシステムや既存の仕組みと適切に連携できるか 法令・規約への適合性 関連する法令や規約、社内標準などに適合しているか レビューでは、対象となる成果物や開発の段階に応じて、必要な品質の観点から内容を評価します。 たとえば、要求された機能を実現していても、個人情報の扱いが不適切であれば、安全性や法令・規約への適合性に関する問題になります。 また、仕様に適合した処理であっても、プログラムの構造が複雑であれば、将来の変更時に欠陥を作り込むリスクが高まります。 このように、レビューの目的に、機能が成立しているかどうかだけではなく、利用者、運用、保守、性能、安全性、法令などの観点から、成果物に必要な品質が備わっているかを確認するということがあります。 問題を早い段階で発見する これらの問題は一部を除いて(この一部、は大事なので次で説明しますね)、テストで見つければいいじゃないか、と、思う人も多いでしょう。確かに、多くの問題はテストして(モノを動かして)見つけることができます。でも、レビューで見つけることの良さがあるのです。レビューを行うことの良さの一つに開発の早い段階で発見できる、ということがあります。 ソフトウェア開発では、要求、仕様、設計書、プログラムなどの成果物を順に作成していきます。 ある段階の成果物に欠陥やリスクが残ったまま次へ進むと、それらが後続の成果物に引き継がれます。 たとえば、要求に含まれる問題を発見しないまま仕様を作成し、その仕様をもとに設計や実装を進めると、後になって複数の成果物を修正する必要が生じます。 安全性や法令・規約への適合性に関する問題であれば、設計やデータの扱いを根本から見直さなければならない場合もあります。 一方、要求や仕様の段階で問題を発見して指摘できれば、その段階で修正できます。 問題の発見が後の工程になるほど、指摘後に必要となる修正の範囲や影響は大きくなりやすくなります。 そのためレビューの目的には、問題が後の工程へ広がる前に発見し、手戻りや将来のリスクを小さくするということもあるのです。 表2　欠陥の修正：レビューとテストの比較 項目 レビュー テスト 発見してから修正にかかる時間 短い(数分～数時間) 長い(数日～数週間) 修正に必要なプロセス 指摘されたところの修正、再レビュー 原因究明(デバッグ)、修正、ビルド、再現環境の構築、テスト 再確認方法 修正箇所をレビューアが確認 テスト、リグレッションテスト レビューでしか見つけられない問題 先ほど「問題は一部を除いて、テストで見つければいい」の、一部とはどのようなものでしょうか。既に答えの出ているものもありますが、このようなものがあります。 要求そのものがあいまい 記述があいまい 仕様と要求に齟齬がある 変更や保守、障害発生時の対応が難しい コードがコーディング基準に則っていない ドキュメントやコードが読みにくい ドキュメントやコードの管理がめちゃくちゃ 思い当たるものはありますか。このようにレビューでは要求や仕様の不備、設計上のリスク、保守・運用への影響、関係者間での認識の齟齬、標準への遵守、など、テストでは見つけにくい・見つけられない問題を指摘するという目的もあるのです。 複数の視点から評価する レビューは何人で行いますか？ ひとりで行うセルフレビューもありますが、チームや組織で行うものもあるでしょう。 レビューには、作成者とは異なる視点から成果物を評価するという意味もあります。 成果物を作成した人は、その内容や背景をよく理解しています。しかし、前提を疑わなくなったり、自分の見落としに気づきにくくなったりすることがあります。 別の人がレビューすることで、異なる知識や経験を取り入れられます。 データベース、性能、セキュリティ、過去の障害、利用者、運用など、それぞれの立場から成果物を評価することで、一人では発見しにくい欠陥やリスク、改善点が見つかることがあります。 たとえば、次のような指摘です。 「この処理は、データ量が増えたときに性能上のリスクになりそうだ」 「この仕様では、利用者が意図しない操作をする可能性があるのではないか」 「この設計では、将来の機能追加による変更範囲が大きくなりそうだ」 ひとりでレビューする場合でも、一晩寝かせておく、帽子をかぶりなおす(比喩表現です)など、違う人を演じると問題を見つけられるといったハックもありますね。 このように、レビューの目的として、作成者では発見しにくい問題や改善点を見つけ、成果物の品質を高めるということもありそうです。 過去の問題を繰り返さない 複数の人がレビューに参加し、問題や知識を共有することには、さらに別の意味があります。 それは、過去に発生した問題を、次の開発に生かせることです。 たとえば、以前のプロジェクトで、特定の条件を考慮していなかったために、本番環境で障害が発生したとします。 その経験を関係者の記憶だけに頼っていると、時間の経過や担当者の交代によって失われてしまいます。 そこで、過去の障害や問題から得られた知識を、チェックシートやデータベースとしてまとめておき、レビューで評価する観点として活用します。そうすれば、同じような成果物を作成するときに、過去と同じ問題がないかを検討できます。 レビューには、目の前にある成果物の欠陥やリスクを発見するだけでなく、過去の経験を組織の知識として蓄積し、同じ問題を繰り返さないようにする目的もあります。 レビューによって得られる副次的な効果 レビューを通して、作成者とレビュアーが互いの考えや前提を知ることもあります。 「この仕様は、こういう意図で作成されたのか」 「この処理には、このような前提があったのか」 このような理解が進めば、チーム内の認識合わせにつながります。 また、 「このアルゴリズムより、こうしたほうが性能が出る」 「この処理は××ライブラリを応用するとよい」 などの知見を得られることもあります。 さらに、 「この機能の実現はどうしたらよいか」 という議論に発展してしまうこともあります。（組織によってはレビューの場での議論は禁じられていることもあるので注意） このような場に同席することによって、経験の浅いメンバーは、経験者がどのような観点で成果物を評価し、どのような問題を指摘するのか、どのような知見があるのかといったことを学ぶこともできます。 このように、レビューにはコミュニケーションや教育、議論の場を提供するといった目的もあります。 ただし、これは、レビューの第一義の目的ではないでしょう。副次的な効果と捉えてよいと思います（諸説あります）。 まとめ：「レビューってなにするの？」にもいろいろある ここまで見てきたように、レビューと一口に言ってもいろいろな目的があることがわかりました。 成果物に含まれる欠陥を見つける（指摘する） 成果物に必要な品質が備わっているか確認する 問題が後の工程へ広がる前に発見し、手戻りや将来のリスクを小さくする テストでは見つけにくい・見つけられない問題を指摘する 作成者では発見しにくい問題や改善点を見つけ、成果物の品質を高める 過去の経験を組織の知識として蓄積し、同じ問題を繰り返さないようにする コミュニケーションや教育、議論の場を提供する 何を目的とするかによって、レビューで注目する点や、やり方は変わります。 レビューしようと思った時、目的は何かな？ということをまず考えてみてください。そうすればよりよいレビューをおこない、より良い結果を得ることになるでしょう。 この記事を担当したメンバー 弦音（ 吉澤智美／ @tulune ） 物を作るのは好きだけどじっくり壊すのも好き。ということで、レビューやらテストやらの集まりに生息。NPO法人ASTER テスト設計コンテスト担当理事。 https://aster.or.jp/testcontest/ 【連載】ソフトウェアレビューをエンジニアリングっぽく語ってみる｜記事一覧 【第1回】［#0］イントロダクション 【第2回】［#1］レビューとは？ 【第3回】［#5］レビューの終わり方～レビュー評価・ふりかえり（1/2） 【第4回】［#5］レビューの終わり方～レビュー評価・ふりかえり（2/2） 【第5回】［#2］何のためにやるの？ The post 【第5回】［#2］何のためにやるの？｜ソフトウェアレビューをエンジニアリングっぽく語ってみる first appeared on Sqripts .

こんにちは、QAコンサルタントのヤマダです。 ソフトウェア開発の現場では、日々、品質の確保、生産性の向上、そして技術の継承といった課題に直面します。経験豊富なエースエンジニアの活躍で一時的に問題が解決されても、そのノウハウがチームに共有されなければ、同じ問題が繰り返し発生してしまいます。 こうした「属人化」という名の落とし穴を避け、チームとして継続的に成長していくために不可欠なのが 「標準」 という考え方です。 「標準」と聞くと「形式的で堅苦しい」「創造性を縛るもの」といったネガティブなイメージを持つ方がいるかもしれません。しかし、標準は開発現場を混乱から救い、より高品質なソフトウェアを、より効率的に生み出すための強力な「羅針盤」となり得ます。 この記事では、まず「標準」そのものについて深く掘り下げ、具体的な事例を交えながら、標準を形骸化させずに「生きた資産」として育て続けるためのアプローチについて解説していきます。 そもそも「標準」とは何か？ 「標準」には、その成り立ちや適用範囲によっていくつかの種類があります。大きくは、公的な機関が定めたものと、市場で事実上標準と見なされるようになったものに分けられます。 デジュールスタンダード (de jure standard) 国際標準化機構（ISO）や日本産業規格（JIS）といった公的な標準化団体によって策定・発行された、公式な規格です。「法律上の」といった意味を持ちます。 デファクトスタンダード (de facto standard) 公的な機関が定めたものではなくても、市場での競争や業界の支持によって広く普及し、事実上の標準として機能しているものです。「事実上の」という意味を持ちます。 しかし、私たちが現場で意識すべき「標準」は、これだけではありません。チーム内で定められた コーディング規約 、プロジェクトで共通して使われる 設計書のテンプレート 、 Gitのブランチ戦略 といったものも、私たちを日々の迷いから救ってくれる重要な「現場の標準」なのです。 ソフトウェア開発に関連する「標準」のランドスケープ では、具体的にどのような標準が存在するのでしょうか。ここでは代表的なものを「デジュール」と「デファクト」に分類してご紹介します。 デジュールスタンダード (公的標準) 国際的な合意形成に基づいているため信頼性が高く、認証制度と結びついているものも多くあります。 標準/規格名 発行元 概要 ISO 9001 ISO 品質マネジメントシステム の国際規格。製品・サービスの品質保証の仕組みを構築・運用するための要求事項を定めています。 ISO 21502 ISO プロジェクトマネジメント の手引に関する国際規格。デファクトスタンダードであるPMBOK®ガイドなど世界中の知見を基に策定されました。PMBOK®が詳細なツールや技法（How）を含むのに対し、本規格は組織が従うべきハイレベルな概念やプロセス（What）を定義するガイダンスであり、相互補完的な関係にあります。 ISO/IEC 25000 (SQuaRE) ISO/IEC ソフトウェア品質 に関する国際規格群。ソフトウェアの品質モデルを定義し、その測定と評価の方法を規定しています。 ISO/IEC/IEEE 12207 ISO/IEC/IEEE ソフトウェアライフサイクルプロセス の国際規格。ソフトウェアの企画から開発、保守、廃棄までの一連のプロセスを定義しています。 ISO/IEC/IEEE 29119 ISO/IEC/IEEE ソフトウェアテスト に関する国際規格シリーズ。テストプロセス、テストドキュメント、テスト技法、キーワード駆動テストなど、テストに関する包括的な内容を扱います。 ISO/IEC 27001 ISO/IEC 情報セキュリティマネジメントシステム (ISMS) の国際規格。情報資産を保護するための管理策を体系的に示しています。 デファクトスタンダード (事実上の標準) 技術の進化に迅速に対応しやすく、特定の分野で強い影響力を持つものが多くあります。 標準/規格名 発行元/管理者 概要 PMBOK®ガイド PMI プロジェクトマネジメント の知識体系。公的規格であるISO 21502の策定にも大きな影響を与えた、業界で最も広く参照されるガイドラインの一つです。 CMMI® ISACA 組織の プロセス成熟度 を5段階で評価・改善するためのモデル。元々は米国カーネギーメロン大学（SEI）で開発され、現在はISACAが引き継いで維持・管理しています。 ITIL® AXELOS ITサービスマネジメント におけるベストプラクティス集。多くの企業のIT部門で運用管理の指針として採用されています。 OWASP Top 10 OWASP Webアプリケーションのセキュリティ に関する最も重大な10のリスクをまとめたレポート。セキュリティ対策の基準として広く参照されます。 【事例】標準を知らないと、実績のあるベテランでも大怪我をする ここで、標準の重要性を実感していただくために、ある現場で実際に起きた 「実績のあるベテランが、標準を知らなかったために大失敗してしまった」 苦い事例をご紹介します。 ある小規模な医療系システムの開発プロジェクトに、開発歴20年で数々の修羅場をくぐり抜けてきたエンジニアのAさんが助っ人として参画しました。Aさんは技術力も高く、過去の経験をもとに独自の「秘伝のタレ」のような効率的なテスト方針を組み立て、 圧倒的なスピードと手際の良さ で次々とテストを消化していきました。チーム全員が「さすがAさんだ」と安心していました。 しかし、プロジェクトの最終盤、クライアントである大手医療機器メーカーによる 品質レビュー が入ったときに事件は起きました。 先方の担当者から 「国際規格である『ISO/IEC/IEEE 29119』に準拠したテスト成果物（ドキュメント）を見せてください」 と求められたのです。 Aさんは「独自の効率的なやり方」でテストを進めていたため、国際規格が求めるプロセス（どのような根拠でそのテスト技法を選び、どう成果物を残すべきか）を満たしていませんでした。Aさんにとっては「十分にテストした」という自信がありましたが、先方からは 「国際規格（標準）を満たしていないため、品質が客観的に証明されていない」 という最悪の評価を下されてしまったのです。 結果として、膨大なテストのやり直しとドキュメントの再作成が発生し、プロジェクトのリリースは数ヶ月延期。Aさんのプライドも、チームの信頼も大きく傷つく結果となってしまいました。 Aさんの技術力や熱意は本物でした。しかし、 「世界中の知見が集まった『標準』を知ろうとしなかったこと」 が失敗の原因でした。 どれだけ実績のあるベテランであっても、自分の「経験則」だけで標準という「集合知」に勝つことは難しいのです。 なぜ私たちは「標準」を活用すべきなのか？ Aさんの事例からも分かるように、標準とは単なる堅苦しいルールではなく、先人たちが同じような失敗を重ねた末にたどり着いた「これさえ守れば絶対に大怪我をしない」という防御壁（ベストプラクティス）です。これらを適切に活用することは、開発チームに計り知れないメリットをもたらします。 品質の安定と向上: 先人たちの知見に基づき、担当者のスキルに依存しない一定の品質レベルを客観的に確保・証明します。 生産性の向上: 「車輪の再発明」や「プロセスの独りよがり」を避け、開発者がより本質的な課題解決に集中できるようにします。 コミュニケーションコストの削減: 「共通言語」を持つことで、組織内外との認識の齟齬や無駄な手戻りを減らします。 技術の伝承と人材育成: 標準化されたドキュメントは、新メンバーや次世代のエンジニアにとって最高の「教科書」となります。 「標準」を育てる：知識創造のアプローチ「SECIモデル」 標準を導入しても、それが形骸化しては意味がありません。また、先ほどのAさんのように外から与えられた標準に振り回されるだけでなく、自らの知見を標準へと昇華させ、チームの資産として育てていくことが重要です。 標準の改善というと、多くの方が品質管理の基本である 「PDCAサイクル」 を思い浮かべるかもしれません。確かに、 既存の標準をより効率的に、 より安定させる といった「改善」のフェーズにおいてPDCAは非常に有効です。 しかし、「エースエンジニアのノウハウ」のような まだ形になっていない知恵を標準化する 、つまり 「創造」 のフェーズではどうでしょうか。この「0→1」を生み出すプロセスで特に力を発揮するのが、知識創造のフレームワークである 「SECIモデル」 です。 SECIモデルは、個人の「暗黙知（経験や勘）」を、組織の「形式知（＝標準）」へと昇華させていく4つのプロセスから成ります。ここからは、別のチームの成功事例を追いながら、そのプロセスを見ていきましょう。 【事例】開発チームが「無敵のエース依存」から脱却した話 新機能の開発を進めていた開発チームには、セキュリティ実装にめっぽう強いエースエンジニアのBさんがいました。Bさんが担当する機能は常に堅牢でバグもありません。しかし、Bさんが他の重要案件で手一杯になると、チーム全体の開発スピードがガクンと落ち、他のメンバーが書いたコードにはセキュリティ上の指摘が多発するという「属人化」の課題を抱えていました。 そこでチームは、Bさんの頭の中にあるノウハウを「標準」に変えるため、SECIモデルに沿った取り組みを行いました。 共同化 (Socialization) – 暗黙知から暗黙知へ まずは若手メンバーがBさんとペアプログラミングを行い、Bさんがコードを書く際に見ているポイントや「なんとなく怪しい」と感じる勘所を対話を通じて肌で学びました。SECIモデルは、PDCAのように明確な「計画」からではなく、こうした現場での自然な知識共有から始まります。 表出化 (Externalization) – 暗黙知から形式知へ ペアプロで得た知見をもとに、Webアプリケーションで特に注意すべき脆弱性対策を誰もが理解できる形に言語化・図解化し、5項目の簡易的な「セキュリティレビュー・チェックリスト」を作成しました。ここで初めて、組織の資産としての「標準 Ver. 1.0」が誕生します。 連結化 (Combination) – 形式知から形式知へ 生まれたばかりのチェックリストを、チームが元々持っていた「Gitブランチ運用ルール」や「コードレビュー方針」のドキュメントと組み合わせ、より体系的な開発フローのガイドラインへと発展させました。 内面化 (Internalization) – 形式知から暗黙知へ 体系化された標準をメンバーが毎回のプルリクエストで実践しました。繰り返すうちに、意識せずともセキュアなコードが書けるようになり、メンバー全体の新たなスキル（暗黙知）として体得されました。 SECIモデルとPDCAサイクルの融合 この開発チームの取り組みには、さらに続きがあります。 作成したチェックリストを運用していく中で、チームは業界のデファクトスタンダードである 「OWASP Top 10」 の存在を知りました。そこで、自分たちの標準（Ver. 1.0）とOWASP Top 10を見比べ、「あ、この視点が抜けていたね」と気づき、 PDCAサイクルを回して標準をさらにアップデート（Ver. 2.0へ） していったのです。 このように、SECIモデルは特に、属人化しがちなノウハウを組織の力に変えるための新しい標準を生み出すプロセスとして非常に有効です。そして、SECIモデルによって生み出された「標準 Ver. 1.0」を、今度は日々の運用の中でPDCAサイクルを回して「Ver. 1.1、 1.2」へと磨き上げていく。 このように両者を組み合わせることで、組織は創造と改善の両輪を手に入れることができるのです。 まとめ ソフトウェア開発における「標準」は、デジュール、デファクトといった公的なものから、現場のテンプレートまで多岐にわたります。これらを単に導入するだけでなく、チームの資産として育てていくことが重要です。 個人の経験則だけで突っ走ると、世界の標準に通用せず思わぬ大怪我をすることがあります（Aさんの例）。一方で、エースの持つ優れたノウハウを SECIモデル で組織の「標準」へと昇華させ、それを PDCAサイクル で磨き上げ続ければ、チーム全体の力が底上げされます（Bさんの例）。 標準は私たちを縛るものではなく、無駄な作業や致命的な失敗から解放し、より本質的な仕事へと導いてくれる強力なパートナーです。創造と改善のサイクルを回しながら、チームの力を最大限に引き出す「生きた標準」を育てていきましょう。 The post なぜ、車輪の再発明をやめるべきなのか？ ソフトウェア開発における「標準」の本当の価値 first appeared on Sqripts .

＜【連載】具体と抽象を往復しよう！ 記事一覧＞ ※クリックで開きます 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 【第3回】『具体と抽象』から見る、デザインと直感 【第4回】『具体と抽象』から見る、テスト設計 はじめに 前回の記事では、具体と抽象の往復が、デザインや直感にどのように表れるのかを書きました。 デザインでは、ユーザーの頭の中にある「こうしたい」という抽象的な期待を、ボタンやアイコン、色、配置といった具体的なUIへと変換します。直感では、過去の具体的な経験から抽象化されたパターンが、思考を高速化します。 つまり、抽象は単に物事を整理するためだけにあるのではありません。具体的な成果物をつくるためにも、複雑な状況を素早く判断するためにも使われています。 今回は、これまでの話をQAとソフトウェアテストの領域に戻します。 テストは、目の前にあるソフトウェアという具体を観察し、そこからリスクやテスト条件、テスト観点といった抽象をつくり、その抽象を再びテストケースや実行手順という具体へ落とし込む活動です。 つまり、テスト設計は、具体と抽象の往復そのものです。 前回の記事の最後では、直感による思考のショートカットは便利である一方、見えている関係だけを信じてしまう危うさもあると書きました。人はパターンを見抜けるからこそ、早合点もします。 そこでQAエンジニアが行うテスト活動では、直感に頼るだけではなく、関係性そのものを構造として捉え直す必要があります。さらに、さまざまな抽象度で複雑に発散したテスト観点を人間が扱えるように、適切な抽象度で階層化する必要もあります。 今回の記事では、次の順番で話を進めます。 まず、仕様や要件を条件と結果の関係として捉え直す方法を見ます。次に、テストがなぜ必要なのか、テストをどのようにリスクとして捉えるのかを整理します。そのうえで、テスト要求分析、テストアーキテクチャ設計、テスト詳細設計、テスト実装というテスト開発プロセスを、具体と抽象の往復として見ていきます。 テストケースをたくさん作ることが、テスト設計ではありません。 テスト対象を理解し、重要なものを抽象化し、構造化し、必要十分な具体へ戻すこと。これが、今回考えたいテスト設計の本質です。 抽象は関係性を見抜く：逆・裏・対偶という見方 前回の記事では、抽象化されたパターンが直感を生み、思考を高速化するという話を書きました。 しかし、直感は便利である一方、見えている関係だけをそのまま信じてしまう危うさもあります。「この条件なら、きっとこうなるだろう」と思い込んでしまうからです。 そこでテスト対象を理解する上では、関係性そのものを形式として捉え直す視点が重要になります。その一つが、命題を「逆・裏・対偶」で捉える考え方です。 前回の記事で扱ったように、抽象化は単に「似ているものをまとめる」だけではありません。複数の事象に共通する関係性を取り出し、形式として扱うことも抽象化です。 仕様や要件の多くは、「もしこうなら、こうなるはずだ」という形で記述できます。これは論理の世界では、「PならばQである」という命題です。 元の命題：P ならば Q P：条件、操作、入力 Q：結果、状態、出力 逆：Q ならば P 裏：Pでない ならば Qでない 対偶：Qでない ならば Pでない こうして書くと、少し数学のように見えるかもしれません。しかし、実際にはかなり実務的な考え方です。 ログイン機能に当てはめる たとえば、ログイン機能に当てはめると、次のように整理できます。 論理 テスト観点 テスト例（ログイン機能） 元の命題（P → Q） 正常系テスト 有効なIDとパスワードでログインでき、マイページに遷移するか。 裏（Pでない → Qでない） 準正常系・異常系テスト IDまたはパスワードが間違っている場合に、ログインできないか。 逆（Q → P） 状態の正当性・セキュリティ ログイン状態になっているなら、正当な認証経路を通ったはずだと考え、URL直打ちやセッションの不正利用ができないか。 対偶（Qでない → Pでない） 原因の切り分け ログインできない場合、本当にIDやパスワードが無効なのか。それともサーバー障害など別の原因なのかを区別できるか。 ここで大事なのは、元の命題だけを見ていると、テスト観点がかなり限定されてしまうということです。 「有効なIDとパスワードならログインできる」という仕様だけを見ていると、正常系の確認で満足してしまいがちです。しかし、逆や裏や対偶まで視野を広げると、セッションの正当性、URL直打ち、ブラウザバック、エラーメッセージの妥当性、原因の切り分けなど、別の角度から仕様を見られるようになります。 つまり、ここで行っているのは、「ログイン」という機能を、単なる具体的な画面操作ではなく、「条件と結果の関係」という抽象モデルで捉え直すことです。 前回の記事で言えば、見た目の違いを超えて共通する構造を抜き出しているのと同じことです。 抽象モデルの便利さと限界 ただし、ここで注意が必要です。 ログイン失敗の原因は、IDやパスワードの妥当性だけとは限りません。サーバー障害、ネットワーク障害、外部認証基盤の問題など、別の要因もあります。 「サーバー起因か、ユーザー起因かを区別できるか」というテストは、先ほどの命題の枠組みの外側にある観点です。対偶の確認だけで、すべての原因を説明できるわけではありません。 このあたりに、抽象モデルの便利さと限界が両方表れています。 モデルは思考を整理してくれます。しかし、現実を完全には覆い尽くせません。前回の記事で引用したGeorge Boxの言葉、「すべてのモデルは間違っている、しかし有用である」が、ここでもそのまま当てはまります。 共通点と相違点を適切にどう掴むのか。どこまでを同じ構造として扱い、どこからを別物として扱うのか。 この判断が、抽象的に考えるコツなのだと思います。 テストは具体と期待を突き合わせる活動である ここまで、仕様や要件を関係性として抽象化する話をしました。では、そもそもなぜテストが必要なのでしょうか。 テストとは、目の前にある具体的なソフトウェアと、そこから期待される振る舞いを突き合わせる活動です。 たとえば、会議室予約システムであれば、利用者が実際に会議室を予約します。その結果、予約が登録され、予約完了が表示され、必要な情報が関係者へ伝わるかもしれません。これが、実際に起きたこと、つまり具体です。 一方で、テストをする前には、「この条件なら、この結果になるはずだ」という期待があります。 空いている会議室なら予約できる 予約済みの時間帯なら予約できない キャンセルした会議室は再び予約できる 権限のない利用者は他人の予約を変更できない これらは、現実の利用目的や仕様から取り出した、期待される振る舞いです。 具体的なソフトウェア ↓ 期待される振る舞い ↓ 一致しているかを確認する つまり、テストは単に画面を操作することではありません。実際に起きたことと、起きるはずだったことを比較することです。 テストはリスクを具体化する活動でもある テストのリソースは有限です。すべての入力値、組み合わせ、環境、ユーザー行動を確認することはできません。 そこで、「何を確認するか」を決める前に、「何が起きると困るのか」を考えます。 会議室予約システムであれば、同じ時間帯に二人が同じ会議室を予約できてしまうと、重要な会議を開催できなくなるかもしれません。 予約処理の不備 ↓ 重複予約が登録される ↓ 会議室を利用できない ↓ 業務に支障が出る この具体的な失敗の経路から、「予約の整合性」や「重複の防止」といった抽象的なテスト条件を取り出します。そして、その重要度に応じて、どこを厚く確認するのかを決めます。 テスト設計では、具体的な機能や利用場面からリスクを抽象化し、その抽象的なリスクを、具体的なテストへ戻していくのです。 テストを設計するまでのプロセスは、抽象度を変換する活動である テスト要求分析、テストアーキテクチャ設計、テスト詳細設計、テスト実装という流れは、単に活動を区切るためのものではありません。 それぞれ、異なる抽象度の問いを扱っています。 テスト要求分析：具体から抽象へ まず、実際の利用場面やシステムの構造を見ます。 利用者は何をしたいのか。どの失敗が困るのか。システムのどこが複雑なのか。 こうした具体的な事実から、「何を守るべきか」「何をテストすべきか」という抽象的なテスト条件やリスクを取り出します。 テストアーキテクチャ設計：抽象を構造へ 次に、抽象化したテスト条件を、どこで確認するのか整理します。 画面で見るのか、APIで見るのか、部品同士の連携で見るのか、システム全体で見るのか。どこを厚くし、どこを代表的な確認にとどめるのか。 ここでは、現実をそのまま写すのではなく、考えやすく、分担しやすい構造へ変換します。 テスト詳細設計：抽象から具体へ 構造が決まったら、テスト条件を具体的な値や操作へ落とし込みます。 「重複を防ぐ」という抽象的な条件を、同じ時間帯、部分的な重なり、隣接する時間帯など、具体的なパターンへ変換します。 すべてを組み合わせるのではなく、何を代表する値なのかを考えながら、必要十分な条件を選びます。 テスト実装・実行：具体へ着地する 最後に、選んだ条件を、前提データや操作手順、期待結果を含む実行可能な形へ落とし込みます。 ただし、ここで終わりではありません。実際に手順へ落としてみると、テストしにくい構造や、想定していなかった条件が見つかることがあります。 そのときは、手順だけでなく、上位のテスト条件や構造を見直します。 テスト実装は、抽象を具体へ着地させる工程であると同時に、具体を通じて抽象モデルを検証する工程でもあります。 このように考えると、テスト開発プロセスは単純な一方向の流れではありません。具体的な現実から抽象化し、その抽象を構造化し、再び具体的なテストへ落とし込みます。そして、実行によって得られた事実をもとに、また抽象へ戻ってモデルを見直します。 次に、このテスト設計全体を、具体と抽象の往復運動として整理してみます。 テスト設計全体は、抽象と具体の往復運動である ここまでをまとめると、ソフトウェアテストの各工程は、次のように見ることができます。 テスト要求分析：具体的な現実を観察し、テスト条件やリスクという抽象へ持ち上げる テストアーキテクチャ設計：その抽象を、整理棚や担当構造としてさらに構造化する テスト詳細設計：抽象的な条件を具体値へ落とし込みつつ、具体値を代表性という抽象で整理する テスト実装：具体的な手順へ着地させ、その実行可能性から上位の抽象モデルを見直す つまり、これは一直線の分解プロセスではありません。 具体 ↓ 抽象化 ↓ 構造化 ↓ 具体化 ↓ 実行 ↓ モデルの見直し 前回の記事で、分類学は多様な生き物に名前を与えることで、世界を理解しやすくしていると書きました。 ソフトウェアテストも同じです。 現実のシステムや要求は、そのままでは複雑すぎて扱えません。だから、リスク、条件、責務、レベル、パラメーター、担当、手順といった名前を与えて整理し、人間が扱える形に変えていきます。 しかし、分類学がそうであったように、その分類やモデルは現実そのものではありません。 実際のテスト対象に向き合い、テストを実装し、テストを実行する中で、モデルはまた見直されなければなりません。 だから、テスト設計の本質は、単にケースを作ることではないのだと思います。 具体と抽象を往復しながら、納得できるモデルを育てていくこと。 これが、テスト設計の本質です。 おわりに：テストケースの数ではなく、モデルの質を見る 今回は、ソフトウェアテストを具体と抽象の往復として捉え直しました。 テストでは、まず実際の利用場面やシステムの構造を観察します。そこから、利用者にとって重要なことや、起きると困ることを抽象化し、リスクやテスト条件として整理します。 そのうえで、抽象化した条件を、確認する場所や役割に割り当て、具体的な値や操作へと落とし込みます。最後に、実行可能なテストケースとして現実に戻します。 具体的な現実 ↓ リスクやテスト条件への抽象化 ↓ 確認する構造の設計 ↓ 具体的なテストケース ↓ 実行結果をもとにモデルを見直す この流れを意識すると、テストケースの数だけを見て、テストの良し悪しを判断することが難しいと分かります。 重要なのは、ケースが何件あるかではありません。 どのような利用目的に対応しているのか どのようなリスクを軽減するのか どのテスト条件から導かれたのか なぜその値や組み合わせを選んだのか どの場所やテストレベルで確認するのか 実行結果をもとに、上位のモデルを見直せるか こうしたことを説明できることが重要です。 たとえば、「会議室を予約できること」を確認するテストケースがあったとしても、それだけでは十分ではありません。 そのテストケースが、単に予約ボタンの動作を確認しているのか、それとも「利用者が確実に会議室を使える」という目的を確認しているのかによって、意味は変わります。 後者であれば、重複予約、権限、変更、キャンセル、同時操作、外部カレンダーとの連携など、別の具体的な条件も必要になるかもしれません。 つまり、テストケースは単独で存在するものではありません。 上位にある目的、リスク、テスト条件、構造とつながって初めて、意味を持った成果物になります。 一方で、モデルをつくったからといって、現実を完全に捉えられたわけでもありません。 実際にテストを実行すると、想定していなかった利用方法や、テストしにくい構造、抽象化の際にこぼれ落ちた条件が見つかることがあります。 そのときに必要なのは、テストケースを追加することだけではありません。 なぜそのケースが必要になったのかを考え、リスクやテスト条件、確認する構造そのものを見直すことです。 テスト設計の技術力とは、思いついた観点を並べることではありません。 具体的な現実から重要な構造を抜き出し、その構造を必要十分な具体へ戻し、実際の現物と突き合わせる力です。 そして、現実との突き合わせによって、抽象モデルを更新する力です。 テスト設計とは、ケースを増やし続ける作業ではありません。 具体と抽象を往復しながら、現実に耐えられるモデルを育てていくことです。 次回は、抽象度の高い仕事ほど責任の質がどのように変わるのかを考えてみます。 AIが具体的なコードやテストケースを生成するようになった今、QAエンジニアには何が求められるのでしょうか。キャリアが上がるにつれて、どのような抽象的なタスクが待っているでしょうか。 次回は、「抽象的なタスクと責任」をテーマに書いてみたいと思います。 【連載】具体と抽象を往復しよう！ 記事一覧 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 【第3回】『具体と抽象』から見る、デザインと直感 【第4回】『具体と抽象』から見る、テスト設計 The post 【第4回】『具体と抽象』から見る、テスト設計 first appeared on Sqripts .

＜【連載】具体と抽象を往復しよう！ 記事一覧＞ ※クリックで開きます 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 【第3回】『具体と抽象』から見る、デザインと直感 はじめに 前回の記事では、分類学という一見するとソフトウェア開発やQAとは遠い学問を手がかりに、「抽象化とは、複数の具体から共通する本質を抜き出し、名前を与えることだ」という話を書きました。 クジラとカバが近縁であることは、見た目という具体だけを見ていてはなかなか気づけません。しかし、胃の構造や反芻の有無、DNAといった、より本質に近い特徴を比較していくと、そこには別のグルーピングが見えてきます。つまり、世界をどう切り分け、何に名前をつけるかによって、見える景色は変わるということです。 そして、その話を通じて私が書きたかったのは、単に「抽象化は大事だ」ということだけではありませんでした。重要なのは、何を抽象化するのかを選ぶこと、抽象化したモデルを疑うこと、そして具体と抽象を往復し続けることでした。 今回の記事では、その続きを書いてみたいと思います。 前回は主に「分類すること」「グルーピングすること」「共通する本質を抜き出すこと」に焦点を当てました。今回はそこから一歩進めて、抽象と具体の往復が、実際の仕事の現場でどのように働いているのかを見ていきます。 今回は、デザインと直感を取り上げます。 一見すると、デザインと直感はまったく別の話に見えるかもしれません。しかし、どちらも抽象と具体を往復する営みです。 デザインでは、ユーザーの頭の中にある抽象的な期待を、具体的なUIへと落とし込みます。直感では、過去の具体的な経験から抽象化されたパターンを使って、目の前の状況を素早く判断します。 前回は「分類学と抽象化」でした。今回は「抽象化されたものが、現実の行為や判断にどう作用するのか」を見ていきましょう。 具体と抽象とは何か まずは改めて、具体と抽象という言葉を確認しておきます。 具体とは、目の前にある個別の物事や、実際に手で触れたり目で見たりできる特定の事象のことです。抽象とは、複数の具体的な事象から、共通する規則やパターンを取り出し一般化した考え方のことです。たとえば「リンゴ」「みかん」「バナナ」は具体で、それらに共通する「果物」という括りが抽象にあたります。 前回の記事では、分類学を例にこの話をしました。個々の動物は具体ですが、「鯨偶蹄目」や「反芻亜目」といった名前は抽象です。名前をつけるということは、世界に対して「ここまでは同じものとして扱おう」という線を引くことです。これは非常に強力な営みです。 『具体と抽象』という本があります。最近、AI時代や現代に合わせて新しい解釈の本が出版されました。この本は、この具体と抽象を行き来する力について書かれています。個別の事象から共通のパターンを見つけ出す力、すなわち抽象化の力と、抽象的な考えを個別の行動や成果物に落とし込む力、すなわち具体化の力。この両方が、仕事や思考のさまざまな場面で使われていることを説明しています。 前回の記事の最後でも触れましたが、抽象は応用が利く一方で、必ず何かが欠けています。複数の具体的な事象から共通する規則やパターンを取り出している限り、それは構造（すなわちモデル）になって現れます。モデルは便利ですが、現実そのものではありません。ガンダムのプラ「モデル」がガンダムではないように。だからこそ、抽象を使うだけでなく、具体に戻る力が必要になります。 今回の記事では、抽象が具体に形を与えるデザインと、抽象化されたパターンが思考を速くする直感について見ていきます。 ここから先は、それぞれ別のテーマの話をしているようでいて、実際には同じ軸の上にあります。抽象は、ただ概念として頭の中にあるだけでは価値を持ちません。具体に降ろされたとき、あるいは具体的な状況を判断するために使われたときに、初めてその力がはっきり現れます。 まずは、その最もわかりやすい例として、抽象が具体に形を与える営みであるデザインから見ていきます。 抽象はどう具体化されるのか：デザインという翻訳 前回の記事では、具体から共通する本質を抜き出して抽象化する話を書きました。今回はその逆向き、つまり抽象を具体に落とす営みとして、まずデザインを見てみたいと思います。 人間は、「物理世界（目に見えて、触れることができる現実）」と、「精神世界（頭の中の思考や概念）」という二つの世界を同時に生きています。UI/UXデザインは、まさにこの二つの世界をつなぐ行為です。 精神世界には、ユーザーの「こうしたい」という目的があります。期待があります。過去の経験からくる思い込みがあります。これがいわゆるメンタルモデルです。 一方で、物理世界には、ユーザーが実際に目にして操作する画面上のボタンや入力欄、アイコン、色、配置といった具体的なUIがあります。 優れた体験とは、この二つの世界がなるべくギャップなく接続されている状態を指します。頭の中で思い描いたことが、そのまま自然に操作として実現できる。ユーザーが「考えなくても使える」と感じるとき、その背後では抽象から具体への変換がうまくいっています。 デザインとは、ユーザーの頭の中にある抽象、つまり期待、心理、意図を、目に見える具体的なUIへと変換する行為です。 善なる具体化は期待を形にする 見出しに書いた「善なる具体化」とは、ユーザーの抽象的な期待を、自然に理解できる具体へと落とし込むことです。 たとえば、「押せるものは押せそうに見えるべきだ」という期待があります。これは抽象です。ユーザーは頭の中でそうしたルールを持っています。これを具体に落とすと、ボタンに立体感を持たせたり、ホバー時に色を変えたり、押せない場合にはグレーアウトしたりするといったUI上の表現になります。 つまり、「押せる／押せない」という抽象的な区別は、ボタンの影や色、余白、シグニファイアといった具体によって表現されます。抽象と具体がここでつながるわけです。 前回の記事で言えば、これは分類学とは逆向きの動きです。分類学は、たくさんの具体から抽象をつくります。一方、デザインは、頭の中にある抽象を、操作可能な具体に変換します。方向は逆ですが、どちらも本質を扱っているという点では同じです。 デザインによって抽象的な期待が適切に具体化されると、ユーザーは操作方法を一つひとつ論理的に考えなくても済むようになります。見た目や配置、挙動から「これは押せる」「ここに入力すればよい」と判断できるからです。 つまり、良いデザインは、ユーザーの思考を具体的なUIの中に埋め込んでいるとも言えます。 悪しき具体化は諦めを形にする しかし、具体化は常に善とは限りません。 ダークパターンとは、前述したユーザーのメンタルモデルを意図的に裏切ることで、「諦め」や「勘違い」や「誤操作」といった心理状態を誘発するために設計された具体的な仕掛けです。 たとえば、ユーザーは「解約ボタンはアカウント設定のどこかにあるだろう」と考えます。これは抽象的な期待です。ところが実際には、解約導線が複雑に分岐していたり、文言が意図的に曖昧にされていたり、異常に小さなリンクになっていたりすることがあります。 これはユーザーの抽象的な期待を形にしているのではなく、裏切っています。そしてその結果、「もういいや」「探すのが面倒だ」という行動を引き起こしてしまうのです。つまり、ここでは「諦め」という抽象的な心理が、具体的なUIの設計によって作り出されているのです。 デザインとは、単に見た目を整えることではありません。抽象をどう具体化するかという営みということなのです。 ユーザーの期待を具体化するのか。それとも、ユーザーの期待を裏切った具体化をするのか。同じ「抽象から具体への変換」であっても、そこには大きな違いがあります。 このように、デザインは抽象的な期待を具体的な形へと翻訳する仕事です。そして、この「抽象を扱うこと」が力を発揮するのは、UI設計だけではありません。 抽象化されたパターンは、成果物をつくるときだけでなく、目の前の状況を素早く判断するときにも使われています。 次に見たいのは、抽象が思考そのものをどう変えるのか、という話です。 抽象は思考を速くする：直感と大局観 デザインの話では、抽象的な期待を具体的なUIに落とし込む営みを見ました。しかし抽象の力は、成果物を形にする場面だけで発揮されるわけではありません。人が素早く判断するときにもまた、抽象化されたパターンが大きな役割を果たしています。 前回の記事では、抽象化すると応用が利くと書きました。なぜなら、複数の異なる事象のあいだにある共通のルールを取り出せるからです。 これは、単に説明が上手になるとか、整理ができるといった話だけではありません。思考の速度そのものにも影響するのです。つまり、具体と抽象をうまく扱える人は、頭の回転が速く見えます。 頭の回転の速度は生まれつきの処理速度とは限りません。法則やパターンを認識していることによって、毎回ゼロから考えなくて済むこともあるのです。 1. 法則の認識と、「直感」 法則やパターンを認識する、つまり複数の具体的な経験から共通の規則を抽象化して持っておくと、思考は高速になります。これは、繰り返し行われる論理的思考が脳に定着し、意識せずとも使える「直感」へと昇華されるためです。 将棋で有名な羽生善治さんが、こんな言葉を残しています。 以前、カーネギーメロン大学の金出武雄先生と対談をさせていただいたときに『論理的思考の蓄積が、思考スピードを速め、直感を導いてくれる。計算機の言葉でいえば、毎回決まったファンクションが実行されているうちにハードウェア化するようなものだ。それまでは毎回発火していた脳のニューロンが、その発火の仕方がいつも同じなので、そこに結合が生まれ、一種の学習が行われたということではないか』と指摘してもらったことがあった。 つまり、直感とは、論理的思考が瞬時に行われるようなものだというのだ。 （『直感力』PHP新書より） この言葉は非常に示唆的ですよね。直感とは、論理の反対ではありません。むしろ、論理的思考が十分に蓄積され、抽象化され、身体化されたものであると羽生善治さんは仰っています。 前回の記事の言葉で言えば、たくさんの具体からルールを抜き出し、その抽象モデルを自分の中に持っている状態が、直感の正体に近いのだと思います。 たとえば、何度も似たような不具合を見ているQAエンジニアは、受け入れ条件や仕様書に明確に書かれていなくても、「ここは危なそうだ」と感じることができますよね。 それは、何も考えていないのではありません。過去に見た具体的な不具合や、似た構造のシステム、失敗しやすい条件が、本人の中で抽象化されているのです。その抽象モデルが、目の前の具体的な状況に対して素早く反応します。 「メカニカルシンパシー」という言葉があります。この考え方は、レーシングドライバーが車のエンジンやタイヤの挙動を理解し、それに合わせて運転技術を最適化することで、「機械への共感」というニュアンスを持っています。これは、F1ドライバーのジャッキー・スチュワートが語った言葉です。 ソフトウェアエンジニアリングにおいては、システムやハードウェアの動作を深く理解し、それに合ったソフトウェアを設計・実装するための概念です。具体的には、ハードウェアの特性や制約、たとえばCPUキャッシュの読み込み単位、メモリの連続アクセスとランダムアクセスの速度差、分岐予測の失敗コスト、マルチコア環境でのキャッシュライン競合といった要素を理解し、その特性に逆らわないソフトウェアを書くことを意味します。 これと同じことがQAエンジニアにもある、ということです。私たちもそのプロダクトのメカニカルシンパシーを持てるときっと素晴らしいことだと思います。 2. 直感の具体例：将棋における「大局観」 さて、話を羽生さんに戻しますが、この「直感」が特に顕著に現れるのが、将棋における大局観です。 熟練者は盤面を見た瞬間、膨大な経験の蓄積に基づいて、有望な手筋と悪い手筋を瞬時に見分けます。これは、無数の具体的な局面を経験し、その中から共通する構造を抽象化してきた結果です。 ここで起きているのは、思考のショートカットです。 実際にはショートカットというより、「前処理が済んでいる」と言ったほうが正確かもしれません。過去の膨大な思考が、すでに抽象的なモデルとなって脳内に格納されているため、毎回すべてを計算し直す必要がないのです。 その結果として、無駄な思考を減らし、本当に読むべき手に時間と集中力を投下できます。つまり、思考回数の最大化ではなく、より正確に言えば「質の高い思考回数の最大化」が起きているのです。 ここでいう大局観とは、盤面全体を抽象的な構造としてとらえる力です。個々の駒の配置という具体だけを追いかけていては見えない、流れや優勢、不利、狙いの方向性といったものを感じ取る力です。 盤面上の一つひとつの駒は具体です。しかし、それらの配置から「攻めが続く」「守りが薄い」「この駒では交換が不利だ」といった構造を読み取ると、盤面全体を抽象的に把握できます。 3. 抽象は、直感による高速な具体化を支援する この話は、成果物をつくる場面でも同じです。 たとえば、文章を書く、設計をする、テスト観点を出す、UIを考える。こうした仕事では、最初から完璧な論理を積み上げて一行ずつ作るよりも、まずある程度まとまったアウトプットを高速に出し、あとからレビューと修正を繰り返したほうが、結果として良いものになることが少なくありません。 このときに働いているのが、抽象モデルに支えられた直感です。 つまり、まず直感で高速にアウトプットする。これは抽象から具体への変換です。そして、その後に論理でレビューする。必要であれば、具体に戻って観察し直し、抽象モデルのほうも修正する。この往復を高速で回すことが、質の高い成果物を生む鍵になります。 前回の記事で、「抽象化された後の世界に居続けられる力」よりも、「具体と抽象を往復する力」が大事だと書きました。直感の話もまさにそうです。直感とは、抽象だけの世界に浮いているものではなく、具体への着地を伴ってこそ力を発揮します。 直感の質が低い人は、論理的思考の回数を増やすことがトレーニングになるかもしれません。たくさんの具体に触れ、そこから規則を見つけ、抽象を自分の中に蓄積することです。 補足すると、ここで言う「直感」はあくまで思考の性質の話であって、直感型の人か論理型の人かといった性格分類の話ではありません。直感は鍛えられるし、その正体は論理の圧縮であるというのが、今回の記事でお伝えしたいことなのです。 ただし、直感によるショートカットは強力である一方で、見えている関係だけをそのまま信じてしまう危うさもあります。人はパターンを見抜けるからこそ、早合点もしてしまうのです。 過去にうまくいったパターンが、今回もそのまま通用するとは限りません。見た目が似ていても、重要な条件が違うかもしれません。抽象化によって共通点を見つけたつもりでも、実は相違点のほうが重要かもしれません。 そこでQAエンジニアは、直感だけに頼るのではなく、関係性そのものをもう一段構造化して捉える必要があります。 次回は、仕様や要件を「条件と結果の関係」として抽象的に捉え直し、そこからどのようにテスト観点を広げていくのかを見ていきたいと思います。この具体と抽象の往復をQAやソフトウェアテストの文脈で考えてみることで、仕様を「条件と結果の関係」として捉えること、逆・裏・対偶からテスト観点を広げること、そしてテスト対象を抽象度の異なる階層で扱うことについて書いてみたいと思います。 【連載】具体と抽象を往復しよう！ 記事一覧 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 【第3回】『具体と抽象』から見る、デザインと直感 The post 【第3回】『具体と抽象』から見る、デザインと直感 first appeared on Sqripts .

はじめに ITコンサルタントのKです。以前、Webサービスの新規開発に関わっておりました。機能開発の段階だったので、機能やビジネスロジックが正しいことの評価が大半で、運用の評価はもっと先という段階でした。 昨今のモダナイゼーションにおいて、開発と運用は切り離せない関係にあります。クライアントサーバー方式からクラウドネイティブなWebサービスへと進化させるプロジェクトを例に、 「継続的な価値提供」を支えるプロセスと品質の考え方 を、鉄道の仕組みになぞらえて紐解いてみたいと思います。 プロジェクトの背景：目指すのは「リカーリング型」への転換 プロジェクトは、レガシーな業務アプリをフルスクラッチでクラウド化するものです。単に「動けばいい」のではなく、ビジネスモデルを フロー型（切り売り）からリカーリング型（継続収益）へ転換すること を目的としています。 開発体制は社員が要件を作成後、開発と評価をそれぞれ別の会社に委託するという建付けです。開発会社が要件をプロダクトバックログに落とし込み、Agile開発で設計から結合テストまで実施します。評価会社はシステムテスト以降の担当です。 運用は自社で担当していましたが、サーバーの監視、障害対応、セキュリティ対策（パッチ適用、ウイルス対策）、バックアップというレガシーなインフラエンジニアでした。 顧客満足度を支える5つの要素 継続的な収益を得るためには、ユーザーにとっての「負」を排除し続けなければなりません。 直感的なUI/UX : 迷わず使える操作性 過不足ない機能性 : 障害やムダがなく、必要十分な機能 高速なレスポンス : ストレスのない処理速度 信頼性 : 高いSLAと安定稼働 保守の迅速性 : 障害修正や機能追加のスピード感 これらの価値を「当たり前」のものとして提供し続けることが、LTV（顧客生涯価値）の最大化に直結し、解約率の低減を実現します。 DevOpsの「8の字ループ」を鉄道に見立ててみる 開発と運用の連携を語る際によく使われる「DevOpsの8の字ループ」は、子供の頃に遊んだ 「プラレールの線路」 を思い出します。左右のループは、それぞれ「開発」と「運用」という別の組織（鉄道会社）が運営し、繋がった線路を相互に乗り入れます。 開発ループ ：　新たな価値を積んだコンテナ（機能）を載せ、運用へ送り出す。 運用ループ ：　現場の利用状況や障害という「情報」を載せて、開発へフィードバックする。 鉄道における「安定稼働」と「迅速さ」を両立させる知見は、そのままDevOpsのプラクティスに当てはめることができると思い、鉄道での取り組みを調べてみました。 鉄道の仕組みとDevOps施策の比較 鉄道の仕組みとDevOps・Agile・SREの施策を比較すると、同じような仕組みがあることがわかります。 顧客満足度の向上 を目的に据え、「SLI/SLOと基盤整備」・「エラーバジェットにより自動制御」・「開発と運用の相互協力」・「継続的な強靭性向上」といったステップで上記施策を選択・実行し、成熟度を高めていくことになるでしょう。 項目 鉄道における仕組み DevOps (全体像) Agile (開発側の動き) SRE (運用側の動き) 衝突防止 信号・閉塞 (区間内の車両制限) CI/CDパイプライン (自動テスト/ゲート) WIP制限 (開発速度の維持) カナリア・Blue-Greenデプロイ (段階的リリース) ATC (自動速度制御) 継続的モニタリング (ログ/メトリクス) スプリントの中止 (PO判断) エラーバジェット (SLOに基づくリリース制限) 相互乗り入れ 車両規格統一・乗務員訓練 シフトレフト/ライト (開発・運用境界の解消) シフトライト (運用考慮の設計・非機能要件) シフトレフト (開発段階での信頼性への関与) 無線/信号共通化 (リアルタイム監視) APM (性能監視/最適化) アジャイルKPI (進捗・ベロシティ計測) SLI・SLO (可観測性の監視) 貨物効率化 規格化コンテナ (積み替え容易) コンテナ化 (環境依存解消・スケーリング) マイクロサービス化（機能の独立・パッケージ化） コンテナ運用 (安定運用と負荷・効率の最適化) コンテナ/列車位置管理 (リアルタイム情報提供) バリューストリームの可視化 (進捗のリアルタイム共有) カンバン (作業フローの可視化) コンテナ運用ツール (デプロイ・監視・スケーリング・保守) 強靭性 災害時の迂回・縮退運転計画 マルチクラウド・マルチリージョン (即時に稼働移動) フィーチャーフラグによる縮退運転機能 (基幹機能の維持) カオスエンジニアリング (耐障害性テスト) 品質管理の変革：評価部門は「門番」から「パートナー」へ この「鉄道網」のようなプロセスを回すとき、品質保証のあり方も変わらなければなりません。 前プロジェクトにおける評価部門は、リリース直前に立ちはだかる「門番」でしたが、保守運用が中心となるモダナイズ後の世界では、 「信頼性のガードレールを構築するパートナー」 への転換が求められます。 具体的な施策 SLO （サービスレベル目標）の共有 : 「不具合ゼロ」ではなく、SLOを全員の共通ゴールにします。これにより、全員が「攻め（新機能）」と「守り（信頼性）」のバランスを自分事として考えられるようになります。 エラーバジェットとバックログの連動 : エラーバジェット（許容できる失敗の枠）が枯渇した際、即座に「信頼性向上タスク」を優先するルールをバックログ運用に組み込みます。POが責任を持ち、新規機能と改善を両立します。 テストの自動化とテスト環境のコード化 : 評価部門はテストを代行するのではなく、開発・運用がセルフまたはCI/CDで利用できる「高精度なテスト環境（IaC、AIエージェント指示書（AGENTS.md））」と「自動テストスイート」を提供します。AI駆動開発では評価ハーネスを構築します。 SRE視点での信頼性テスト 独立した評価部門が関わる場合、以下のようなテストを「開発の早い段階（シフトレフト）」と「リリース後の運用段階（シフトライト）」に分けて組み入れます。継続的にテストできるよう「テストを自動化し、開発・運用に環境をフィードバックする仕組み」を構築することで「安定稼働」と「迅速さ」に貢献できます。 テスト種別 内容 SREにおける目的 負荷・ストレステスト 限界値やスパイクアクセスを確認 SLOを維持できる最大キャパシティの把握 カオスエンジニアリング 意図的に障害を注入 自己修復能力と監視・発報の妥当性確認 DR（災害復旧）テスト リージョン切り替え等を試行 RTO（目標復旧時間）がSLO内かの確認 オブザーバビリティテスト 擬似異常によるアラート確認 「未知の異常」を検知できるかの確認 最後に：外部委託における「SRE」の法的リスクと対策 ここまではプロセスや文化の話でしたが、実務上の大きな壁となるのが 「委託契約」 です。安全な運行を支えるのは、車両や信号（技術）だけでなく、鉄道会社間の『運行規定（ルール）』であるのと同様に、ITの世界でも『契約』が重要です。SREのアプローチを外部委託する場合、以下の4点に注意が必要です。 準委任契約における「善管注意義務」 ： エラーバジェット枯渇による「開発停止」が、委託範囲に含まれていないと、発注側から「予定の成果が出ない」とクレームになり、受注側は「契約外の改善を強いられた」と紛争化するリスクがあります。 請負契約における納期遅延 ： SREの判断でデプロイを止めた場合、法的観点では「発注者側の都合による履行不能」とみなされ、ベンダーから納期延長や追加費用を請求される根拠になり得ます。 偽装請負の懸念 ： 発注側のSREチームが、ベンダーの開発者に対して直接「予算が尽きたからバグ修正に全リソースを割け」と細かく指示を出すと、指揮命令権の問題（偽装請負）が生じる可能性があります。 納品物の著作権 ： AI駆動開発における評価基盤の構築（ハーネスエンジニアリング等）において、AIエージェントを活用して評価プロセスを自動化する際に、テスト観点等をルールとして提供することがあります。再利用性が高い知見をそのまま納品することになるので、著作権への配慮や暗号化するなどの対応が必要となります。 解決のためのアクション これらのリスクを避けるためには、契約段階で 「SLA/SLOの仕組みそのもの」を合意事項に組み込む ことが不可欠です。「エラーバジェットが枯渇した際は、優先順位を動的に変更する」というルールを業務範囲として定義しておくことが、健全なDevOps運用の第一歩となります。 モダナイゼーションは、単なる技術の刷新ではありません。開発・運用・そして契約を含めた「文化の刷新」であることを、改めて意識していきたいものです。 The post 「止まらない鉄道」に学ぶ、モダンなシステム開発とSREの品質管理　〜業務システムのクラウド化と、評価部門の新たな役割〜 first appeared on Sqripts .

伊藤さん、往復書簡ありがとうございました。 この連載では、ある種「本質は変わらない」と思われるような達観的な流れになりましたね。 そして、熱狂と冷静の間にあるもの、この大切さも今は身に沁みてわかっています。 技術や仕組みの成熟を点で見るのではなく、連続的な状況の変化を繋ぎ、線で感じとること。 これもまた、テストで大切にされている「コンテキストを理解する力」だと思っています。 これは、ある種、「その場で起こることを歓迎し、生成的なものに繋げる」というプロセスワークにつながるようなものの見方だと思っています。 ＜専門家2人による往復書簡 Connecting the dots 記事一覧＞ ※クリックで開きます 【第1回】E2Eテスト自動化でつなぐ①〜E2Eテスト自動化のいまむかし〜 【第2回】E2Eテスト自動化でつなぐ②〜生成AIがテスト自動化に及ぼす影響をどう捉えるか〜 【第3回】E2Eテスト自動化でつなぐ③〜テスト自動化における寒暖差〜 【第4回】E2Eテスト自動化でつなぐ④〜冷静でいるのもテストエンジニアの役割〜 【第5回】E2Eテスト自動化でつなぐ⑤〜Connected the Dots〜 成熟の過程で起こることを「冷静に」捉える 私自身もその途中にあるように、初心者から成熟までには大きな差があります。 自身の成長を実感しては喜び、ふと目の前を見ると、未知の壁に直面して挫折感を味わいます。 私はこれを何度も経験してきました。伊藤さんもそうかもしれませんね。 この連載で私が投げかけた「冷静な」という言葉の意図を、伊藤さんは鋭くキャッチされましたね。 この言葉の裏には、一見すれば相反する願いがあったことに気づきました。 それは、「成熟の過程を冷笑的に受け止めたり、発信するようなことはしたくない」ということです。 そして、結果的にその私の隠れたシグナルを受け取る、ある種の懐の広さが伊藤さんにはあったのでしょう。 伊藤さんとの往復書簡は私の想定を上回る奥行きのあるものでした。 その見えない繋がりを実感して、画面の前で「しめしめ」と一人ニヤついているのでした。 生成AIと新たな自動テストの形 生成AIを活用したとして、gTAAの基本的な構造は変わらないというのは同意です。 しかし、伊藤さんが例に出された「Bug Detection Layer」というのは面白い概念だと思います。 一般的に、あるいは私自身も「テストに正解などない」「テストはコンテキスト次第」などと表現することがあります。 一方で、この前提がひっくり返るとき、具体的にはテストオラクルが、より確からしいものになることかもしれません。 その時に我々、今を生きるテストエンジニアは、今まで学んだことや前提を「いかに手放すか」が問われるかもしれませんね。 その時が楽しみで仕方ありません。 テストエンジニアが担うバランサーとシステム思考の接続 テストエンジニアがブレーキやバランサーになるという話は、実は最近私が注目しているテーマと面白いように重なります。それが、システム思考における「自己強化型ループ」と「バランス型ループ」です。 システム思考が目指すことは、実は過剰に成長、あるいは減衰するシステム（過剰な自己強化型ループ）にバランスを取り戻し、長期的に持続可能な状況（バランス型、あるいはゆるやかな自己強化型ループ）にしていくことです。 これはまさに、里山のように絶えず手入れを続ける営みだと言えます。 ここで、私が以前から強く主張しているテストエンジニアの専門性——テスターは「現実を見る専門家」という考え——と接続してみようと思いました。 「テストエンジニアの貢献は、”現実”のフィードバックを適切に行い、持続可能なバランスを保つこと」 そう考えた時、システム思考の言葉でテストエンジニアの働きを捉えると、「情報フローの設計」や「時間的遅れ」(これはシステム全体において何らかの傾向が見えやすい形に現れるのは、問題が起こっているその時ではないという考え方です)をどうしていくか、ということになると考えています。 追伸：残された問い、答えのなさ ここから先はもう、伊藤さん個人との対話のための文章ではありません。 この問いはこれを読んでいるあなた、あるいは書いている私自身に向けられています。 いま、私のなかではこういった問いも生まれています。 「テストエンジニアである私は、本当に何かのバランスを保つことができるのだろうか？」 「そのバランスには、役割や職能に紐づいた何らかの傾向性（エゴ）が潜んでいないだろうか？」 実はこの問いは、テストエンジニアに限らず、多くのシステムシンカーにも投げかけられる問いだったりします。 この「バランサー」という表現に強く共感しつつも、普段の仕事の中で、「私にそれだけの実力があるのだろうか」 「それができる関係性を周囲と築けているだろうか」 と自問することが多くなりました。 かつて、にしさんは「テストとは納得してもらうことである」と語りました。 参考： https://www.aster.or.jp/business/contest/contest2013/pdf/kansai_2012_keynote.pdf 私はこの言葉に深く賛同しています。 そして、その発言から10年以上経った現在、私はその難しさに直面しています。 “納得感の醸成” これが可能なほど私は論理、認知、人、関係性——あるいはそこに映る自分自身——に向き合ってきたのだろうか。 「バランスすること」、これは本当に手に負えるものなのでしょうか？ それを実現するのは、論理的なテストの技術かもしれません、建設的な対話かもしれません、心理的安全性のある場かもしれません。 もしかしたら、ひょっとすると、アーノルド・ミンデルがそうしたように、踊りや歌や散歩だったりするかもしれませんね。 参考： https://eijipress.co.jp/products/2355 私は、こうして問いを投げかける行為自体が、すでに私の傾向性（エゴ）から生まれていることの矛盾に静かに気づいています。 Connected the Dots 問いに答えようとするとき、私はたびたび何か別の場所から答えを探し、見つけることがあります。 自動化について問うとき、この連載で伊藤さんをお呼びしたのも、その一つかもしれません。 あるいは、自動化から離れ、「バランス」という考えに対して、システム思考を持ち出したのもそうでしょう。 その先に、私は論理で捉えきれない繋がり、例えばコーチングやプロセスワークなどから立ち現れる身体知に通じるものがあると考えています。 これを繋がりと捉えるのか、支離滅裂な飛躍と捉えるのか、それはそれぞれの方に委ねたいと思います。 この往復書簡では、伊藤さんは私の意図を深いところまで汲み取ってくださり、鋭い洞察のもと、誠実に返信してくださいました。 今回はSqriptsでの連載という、単なるブログのやりとりではなく、比較的フォーマルな形式をとっています。 お互いに内容を打ち合わせることなく、（驚くことですが）AGESTの方の意向を伺うこともなく、自由に考えを交換しました。心から感謝しています。 いま私は、この企画を始める前には思ってもみなかった価値を感じています。 これが「繋がり」（あるいは多様性と表現されるもの）の面白さだとも思っています。 もしこの一連の記事を「面白い」と感じた方がいらっしゃれば、私は、こういった繋がりはありふれたものだと伝えたいです。 我々一人ひとりの専門家の点が繋がるだけで、そこには大きな可能性が広がるのです。 そういったことが頭に浮かぶような連載でした。 【連載】専門家2人の往復書簡 Connecting the dots 記事一覧 【第1回】E2Eテスト自動化でつなぐ①〜E2Eテスト自動化のいまむかし〜 【第2回】E2Eテスト自動化でつなぐ②〜生成AIがテスト自動化に及ぼす影響をどう捉えるか〜 【第3回】E2Eテスト自動化でつなぐ③〜テスト自動化における寒暖差〜 【第4回】E2Eテスト自動化でつなぐ④〜冷静でいるのもテストエンジニアの役割〜 【第5回】E2Eテスト自動化でつなぐ⑤〜Connected the Dots〜 The post 【第5回】E2Eテスト自動化でつなぐ⑤〜Connected the Dots〜｜専門家2人の往復書簡 first appeared on Sqripts .

山下さんとの往復書簡、第四回目（そして私のパートの2回目）の記事となります。 前回が画鋲付き（！）とは気づかずに答えていました・・・。 今回の往復書簡は、当然ながら一つ前の記事を書いたのが自分ではないので、ひとりで書いているときと比べて注意ぶかく読んだうえで続きを書こう、という努力をしています。そうすると、繰り返し読むうちに考え方や文体の違いがだんだんと見えてきて、単純に直接会ってディスカッションしているときとはまた違った趣があります。 さて、話を本題に戻しまして。前回の山下さん記事の内容に対するコメントかつ感想かつ読者の方向けの補足、から入っていければと思います。 自動化は当たり前になったが、「どうテスト実行を自動化するのか」にとどまっているのでは これは完全に同意です。ふと思い出して、過去の自分の発表資料を見返してみたのですが、同様の趣旨のことを言っていました。（※念のためお伝えしておきますがマウンティングではありません。「ここ4, 5年、引き続き、そのような傾向があるみたいです」といいたいのです。） 以前の、テスト自動化が今ほど当たり前でなかった頃には、 小手先の自動操作ができれば技術力があるっぽく見えていた 時期があったように思います。（そしてその時代に、小手先の自動操作ができることで先行者利益を得ていた自覚もあります。） 一方自動化が当たり前になってきた今では、小手先の自動操作だけでは価値を発揮しづらく、また市場価値的な意味でも特別な強みとは言い難い状態です。山下さんがおっしゃるような、テスト自動化に関するより大事なところがわかっていて、かつ組織の中で自動化を適切に取り入れ、推進できるレベルが求められています。そのレベルになってようやく「テスト自動化ができます」と言える、のが今なのではないでしょうか。ひとことで言えば「当たり前になった結果、ハードルが上がった」と言えるでしょう。しかしテスト・QA界隈を超えてソフトウェア開発の業界全体を見たときに、本当にその上がったハードルを皆が超えているのかと言われると、そうとは限らない。まさに「どうテスト実行を自動化するか」にとどまっていることがまだまだ多いように見えます。主観ですが。 ただし、これは必ずしも悪いことではないと考えています。合理的なテスト計画と設計に基づき～と書いてくださっていたようなレベルまで皆が成熟するには、小手先の「ちょっとできます」を通過することになるはず。手を動かす経験、たとえば「自動テストを作りすぎてメンテが辛い」などの経験があって初めて、本当の意味で理解して戦略を立てられるという面もあると思います。 まだまだ成熟しきっていないという指摘は正しい反面、 当たり前のレベルが上がって、みんなが「小手先レベル」に来た。全体としては確実に進化はしていて、ほんとうに大事な部分の手前までは来た 、という捉え方もありそうです。前は50点取れたらスゴイと言われていたけれども、今は80点を取らないとスゴくない。けどみんな70点を取れるようになっている。こんな感じでしょうか。 冷静な視点とその必要性 これも、自動化の成熟度の話とセットだと思っています。 小手先の自動化で「わかったつもり」状態にとどまっていると、山下さんのおっしゃっている「冷静な視点」で物事は見られないと思います。自分の知識や経験に対して、眼の前のひとつの物事があまりに大きいと、熱狂したり、必要以上に慌てたりしてしまいます。視界の８割をひとつのこと（今だとAIがあればテスト自動化できるぞ！など）が占めると冷静でいられません。広く知識と経験があれば視界も広いので、ひとつのものごとが占める割合が少なくなります。 つまり知識と経験があって、小手先でなく、より大事な点について考えられるくらい視界が広がっている人は、熱狂や過剰な期待に陥らずに済みますね。 すこし脱線すると、何かに「意図して熱狂」することも時と場合によっては大事だと思っています。視界のメタファでいえば、視界の広い・狭いを自分で意識的にコントロールできる人は、健全に熱狂できるということです。もちろんそれは広い側の視界を体得している人にしかできないことなので、どちらにせよ知識と経験をもって視界を広げておくことは大前提です。 と、こういったコメント兼私自身のスタンスや考え方を共有したうえで、また再度バトンを受け取りましょう。 生成AIが前提の開発において、自動テストアーキテクチャにはどのような変化があるか まず目先の変化としては、アーキテクチャの構造は大きく変わらず、その構成要素がAIによって効率化される、あるいはAI向けに置き換わるといったことはありそうです。 gTAAでいえば、テスト実行レイヤーのテストレポート作業に対してAIを使ったり、テスト生成レイヤーでは以前は「手動設計」という部分がありましたがここがAIによる自動・半自動を含むなど、です。 さらに進んだ先でどのような変化があるのか、についても、この質問をいただいて考えてみたのですが・・・実はアーキテクチャの構造はそれほど大きく変わらないかもしれない」という考えに至りました。 理由としては、ISTQBのTAEシラバスが示すように、そもそもベースとして4つのレイヤー（生成・定義・実行・適合）からなるgTAA（汎用テスト自動化アーキテクチャ）があり、それを個別のプロジェクトや組織に合わせて具体化してTAA（テスト自動化アーキテクチャ）を設計する、というステップを踏むからです。ベースにあるgTAAの構造自体が持つ「汎用さ」が、生成AI時代の変化を吸収するため、構造としての変化はほぼ無いのではないか、というのが今のところの予想です。 ここで余談ですが、現状のTAEシラバス日本語訳の元になったバージョンよりも、さらに新しいISTQB側のTAEシラバスが出ています。この新シラバスに出てくるgTAAが、実はすごく簡素になっているんですよね・・・理解のしやすさの面では新バージョンのほうが勝っていると思います。簡素になっているぶん、さらに生成AIによる変化をある意味内包できるようになっているのではないかなと思います。 話を戻すと、gTAA→TAAは自動テストの生成・定義・実行・適応というざっくりとした構成を満たすようなアーキテクチャを作ろう、という考え方なので、生成AIが前提でもここの基本は変わらない、と思われます。 ただ、それだと答えとしては面白くないと思うので・・・少しひとひねりして、異なるテスト自動化アーキテクチャになるとしたらどのような場合か、を考えてみます。。 ここまでの、gTAA->TAAの話は、基本的に「スクリプトテスト」が前提の話です。ということは、スクリプトテストではないテストを自動化して実行するための自動テストアーキテクチャは、また違った形になる可能性がありますね。スクリプトテストではないテストは、例えば探索的テストがありますね。 探索的テスト自動化の論文見ていると、操作の過程の状態や画面表示に対して「バグかどうか」を判断する「Bug Detection Layer」のようなものが入ってきたりしそうです。スクリプトテストだと「期待通り動いたか否か」の判定を行いますが、探索的テストの場合は正解がわからない状態で、おかしいかどうかを判断してレポートする必要があるので、このようなテストオラクルを生成するようなレイヤーもまた、gTAA->TAAがあるとすれば、含まれるのではないでしょうか。 テストエンジニアはソフトウェアエンジニアリングの世界にどのような良い影響を与えうるか 壮大な問いなので、「はたして私が答える資格はあるのだろうか・・・」と思ってしまう面もありつつ。おそらく、ひとつ上の「自動テストアーキテクチャにどんな変化があるか」について考えているとき、私はQAエンジニアの、いわゆる「帽子を被って」答えていたように思います。無意識に。 そこであえて「テストエンジニアは」という聞き方をされている点については、なにか特別な意図があるように（勝手に）感じますね。山下さんが「テスター」にこだわりを持っているのも知っていますし。 そのような前提で、個人的な意見としては、優秀なテストエンジニアは開発プロジェクトにおけるスピードのコントロールができる存在なのではないか、と思っています。 生成AI以前であれば、開発サイクルは速いほうがいいと思われていたはずです。（しかしたら生成AI以降もそう思われているかもしれませんが。）しかし、私は「速ければいいというものでもない」と考えています。 車のレースを例に説明すると、（私も詳しくはないのですが）スピードが速いほうがよいからといって、アクセルを踏みっぱなしではレースには勝てません。速く走るためにはブレーキングも大事になってくるそうです。コーナーをいかに効果的に曲がるか。そのための適切なブレーキのタイミングがあります。 テストエンジニアはこの、ブレーキを用いた適切なスピードコントロールによってソフトウェア開発チームに貢献できると思っています。ブレーキを踏んだその瞬間は確かにスピードは落ちるのですが、その先のコーナーを上手に曲がることができれば、レース全体で見たときには速く走れている。そうした、先や全体を見通す役割として、テストエンジニアの存在意義があるのではないでしょうか。自動テストが当たり前になった、という話も関わってきていて、「スピードを殺さない」自動テストと、「適切にスピードを落とす」手動のテスト、のようなバランス取りが求められそうですね。 と、ここまでの抽象論ではもとの質問に半分くらいしか答えていません。上記の意見は「開発チームやプロジェクト」という目の前の現場に与える影響の話です。ここから、主語を「ソフトウェアエンジニアリングの世界」というマクロなスケールに変えて考えてみます。 スケールが変わっても、テストエンジニアが果たすべき役割は変わらないと私は思っています。それは、ソフトウェアエンジニアリングの世界における一方向への過剰な熱狂に対して、いい意味で水を差し、まさに「冷静な視点」を提供するということです。 たとえば、ロールや考え方が似通った開発者だけで構成されたコミュニティや業界のトレンドがあったとします。そこには強いまとまりや推進力が生まれるかもしれませんが、もし進む方向が間違っていた場合に、自浄作用による軌道修正が行われにくくなるリスクもあります。 だからこそ、異なる専門性や「批判的思考」を持つテストエンジニアという存在が不可欠になります。私たちが日々の開発現場で「ブレーキを踏み、中長期的に走り続けられるチーム」を泥臭く作り続けること。そして、その実践から得られたリアルな知見を発信していくこと。その積み重ねこそが、トレンドに傾きがちな、熱狂しがちなソフトウェアエンジニアリングの世界全体に対して、中長期的な持続可能性という形で良い影響を与えられるのではないでしょうか。具体的に「こうなる！」という未来の形がぱっと出てくるわけではありませんが、業界のバランスを保つ「バランサー」としての役割に、テストエンジニアの存在意義があるのではないかと考えています。 おわりに 山下さんがくれた問いに対するアンサーを考えてみたところ長くなってしまいました。回答になっていればよいのですが・・・ こうして文章を通じてやりとりするのは、直接会話するときのテンポとはまた違っていて、やっているほうとしては大変さと楽しさを同時に感じています。読者の皆さまにもそのあたり伝わっていたら嬉しいです。 The post 【第4回】E2Eテスト自動化でつなぐ④〜冷静でいるのもテストエンジニアの役割〜｜専門家2人の往復書簡 first appeared on Sqripts .

キャッチ。 伊藤さん、バトンを受け取りました。 冷房の効いた室内と近年とりわけ気候変動によって過熱している屋外とで、寒暖差の激しい日々が続いておりますが、いかがお過ごしでしょうか。 ノーコードテストツールのバトンは画鋲付きで渡した気分でした。 しかし、誠実に答えてくださり、ありがとうございました。 テスト自動化は運用が大切、というのは私自身、伊藤さんから繰り返し学んでいたことでしたね。 そして、ノーコードかコードベースかといった軸とは全く違うパラダイムの進化というのは大変示唆的です。 そもそも生成AIの多くは、LLMにチャットというインターフェースを使って接続するものです。チャットを組み込んだことはLLMにおける大きなUXの発明です。 しかし、これは今では当たり前になり、誰もそのことを意識しないようになってしまいました。これもパラダイムの進化だと思っています。 それでは、受け取ったバトンを見てみます。 非常に鋭く、かつ本質的な問いがありますね。 伊藤さんからいただいた「テスト自動化は本当に『当たり前』になったのか」「なぜ冷静な視点が必要なのか」という2つの問いについて、私の視点からお答えしつつ、これからの自動テストが向かうべき新たなパラダイムについて考えてみたいと思います。 「当たり前」の現在地 伊藤さんからの最初の問いである「幅広いコミュニティから見て、テスト自動化は本当に当たり前になったのか」について。 私の実感としても、テスト自動化が前提の技術として扱われる機会は確実に増えていると感じます。 プログラミングやアジャイルの文脈を問わず、様々なカンファレンスで自動テストに関するセッションはありますし、「今だからこそ、確かなテストや品質保証が大事である」という共通認識は、かつてないほど高まっていると感じます。 そういった背景もあって、私が「QAエンジニア」あるいは「テスター」という肩書きのまま、受け入れられているという側面があります。 こういった、テストの専門性を受け入れるような”暖かい”雰囲気がある一方、冷静に見極めなければならない「ズレ」があるとも考えます。 世間で当たり前になりつつあるのは、あくまで「どうテスト実行を自動化するのか」に留まっているケースが多いのではないか、ということです。 プロダクトの特性やコンテキストを分析し、合理的なテスト計画と設計に基づき、真に必要な活動を「自動テスト」として成熟しているかというと、そこにはまだ大きな隔たりがあるという肌感覚があります。 (これに対しては、いわゆる”テストエンジニア”による歩み寄りが必要で、その歩み寄り方自体についてもきちんと向き合って考えるべきことだと個人的に思っていますが、ここでは深入りしません) 伊藤さんが指摘された「生成AIという次のブームに押し出されて、自動化の流行りが落ち着いた（ように見える）」という視点は的を射ていると感じます。 これは私自身にも言えることですが、私たちは「知ったつもり」になるのをやめ、その当たり前の中身を問い直さなければなりません。 なぜ「冷静な視点」が必要なのか 私は手動テストの設計時のような「冷静な視点」が必要だと伝えました。そのまま返ってきましたね。 現在、生成AIの台頭によってプロダクトコードが大量かつ高速に生み出されるようになりました。 これに伴い、現場では「開発スピードに合わせて、テストも急いで大量に作らなければならない」という焦燥感のようなプレッシャーが生まれているように感じることがあります。 他方、プレッシャーとは逆の視点で、「難しいコードを書かなくても実装できるぞ！」という熱を垣間見ることもあります。 以前、テストマネジメントの記事でも述べたことですが、私は「コストや期間の制約を考えれば、テストは極力すべきではない（最小限に抑えるべきである）」というのを基本的なスタンスとしています。 むやみにテストを自動化し、ただコードの量を積み上げることは、それこそ運用の破綻を招くだけだと考えます。 ここで問われているのは、大量生産への追随ではなく、「何をテストすべきで、何をテストしなくてよいのか」を見極める、本質的なテストマネジメントの力に他ならないと考えています。 これはプロダクトコードにおけるプロダクトマネジメントの考え方にも通じるものがあります。 生成AIを発端とする熱狂や過剰な期待にただ熱くなるのではなく、事実に基づいてソフトウェアテストの責任をどう果たすか。 これが私の考える「冷静な視点」です。 生成AIがもたらすリアルな制約 ここで、現状の生成AIを使ったテストの「リアル」についても触れておきます。 今後、テスト自動化の現場は「コードを書く」ことから「プロンプトを書く」ことへとシフトしていく可能性が高いです。実際に、BDD（振る舞い駆動開発）のようなプラクティスも再び注目を集めています。 しかし、現状の生成AIを組み込んだテスト運用には、実行時間の制約や、スケールさせた際の予算的な制約が存在します。 その他、並列処理のための最適化などの自動テスト実行環境を綿密に整備しないかぎり、AIによるテストの量産は現実的な運用に乗せられないというのが2026年7月の私の見解です。 ただし、この予算やリソースの制約をクリアした先、あるいは「価値がある」と計算し切れた先には、全く新しい展望があると考えています。 制約を乗り越えた先にあるgTAAの気候変動 その展望とは、組織が集めたプロファイルや顧客データなどに基づいて、品質特性の質感（代用特性としての確らしさ）、つまり「品質が良さそうだ」と判断する根拠に対する感覚が今とは全く異なったものになることです。 ※この意見はスクラムフェス新潟2026のきょんさん、nacoさん、じゅんぺいさんの以下の発表とその後の対話から、私なりに受け取り、解釈したものです。 そして、自動テストの文脈で言えば、JSTQBのテスト自動化エンジニアシラバスで定義されている「gTAA（汎用テスト自動化アーキテクチャ）におけるテスト生成レイヤー」の構築がより簡単になると考えます。 参考： https://jstqb.jp/dl/JSTQB-Syllabus.Advanced_TAE_Version2016.J01.pdf これは、gTAAにおける水平レイヤーそれぞれで生成AIを使ったパイプラインを使用し、例えばテスト生成レイヤーの出力をそのレイヤーの中で検証し、それぞれのレイヤーで確からしく実装まで繋がっていく様子をシームレスに確認できるような、発展した形の汎用テスト自動化アーキテクチャです。 そして、生成AIが当然に用いられるプロダクト開発において、「決定論的に見極められる事実を確認する」という意味でテストが重要視されるでしょう。 ※これは冒頭で話した「今だからこそ、確かなテストや品質保証が大事である」の単なる言い換えでしかありません。 「生成AIを活用する」という目的で作るTAAは、「手動テストをただ単に自動化する」という、かつてのテスト自動化の熱狂と同じ構造を持っているのではないでしょうか。 もちろん、それが学習の途中で辿る道であり、私もその中にいることすらあると思っています。 テストが持つ本質的な役割を理解した上で、それをどう生成AIと統合していくかということが、今後の”冷静な”論点になりうると考えています。 そして、その論点を踏まえた上で、自動テストは新しいパラダイムでの「TAA（テスト自動化アーキテクチャ）」を語る熱量が上昇するのではないか、と考えています。 伊藤さんへのバトン 単にテストを自動化する・コードを生成するという次元を超えて、システムや組織のデータそのものをインプットとした「TAAの再定義」という変化が来ているという私の見通しがあります。 ここで、MagicPodのエヴァンジェリストであり、ISTQB Advanced Level Test Automation Engineerの翻訳者のひとりである伊藤さんに、ぜひ最後のバトンをお渡ししたいです。 生成AIが前提の開発において、自動テストアーキテクチャ（TAA）にはどのような変化があるのでしょうか？ そういった状況の中で、テストエンジニアは、ソフトウェアエンジニアリングの世界にどのような良い影響を与えうると見通されていますか？ 私の上記の見解もまた、冷静ではなかったりしますかね？ ←これには答えなくていいです。 一人の専門家としての見解を、ぜひお聞かせください。 The post 【第3回】E2Eテスト自動化でつなぐ③〜テスト自動化における寒暖差〜｜専門家2人による往復書簡 first appeared on Sqripts .

はじめまして、クオリティマネージャーのヒロたです。 近年、多くの企業で DX（デジタルトランスフォーメーション） が求められ、システムは単なる業務効率化ツールではなく、ビジネス戦略の中枢を担う存在になっています。その結果、従来のように 「要件定義 → 詳細設計 → 実装 → テスト → リリース」 と長い時間をかけて作る大規模スクラッチ開発では、ビジネスの変化のスピードに追いつかない。変更対応や機能追加にも時間がかかり、結果として競争力を削ぎかねません。こうした背景から、 「早く作る／早く直せる」 ことが重視されるようになり、コードを書き続けるスクラッチ開発よりも、再利用可能な部品やテンプレートを活かせる手法 、すなわちローコード／ノーコードの需要が高まってきています。 本日は、ローコード／ノーコード開発（以降、LCP/NCP開発と表記） の品質について筆者が考える考慮点をご紹介します。 LCP/NCP開発の「品質」を測る、新しいものさし 1. そもそも品質って何だろう？ 私たちがシステムに求める「品質」とは何でしょうか？ 昔は「欠陥がないこと」を指していましたが、今では「要求を満たす程度」や「価値そのもの」と捉えられています。 近年はローコード／ノーコードの普及により、従来のようにコード量や詳細設計を基準に品質を把握する手法が通用しにくくなりました。部品再利用や自動生成が前提となり、開発速度は大きく向上した一方で、内部構造が見えにくくなる場面があります。そのため従来のようにコード量や詳細設計を基準にした品質の捉え方が当てはまりにくくなり、最終的な成果物が業務要求をどれだけ満たしているかという“価値そのもの”に重心を置いた評価がより重要になってきています。しかし、新しいLCP/NCP開発では、従来の品質管理のやり方があまり当てはまらないという課題があります。 2. 従来のやり方ではなぜ測れないのか？ 従来のスクラッチ開発（ゼロからコードを書く開発）では、コードの行数（SLOC）や機能の規模（機能数）を基準に品質を測ってきました。 しかし、LCP/NCP開発には、従来の統計値、基準値が使えないという問題があります。 (1)　コード行数がわからない LCP/NCP開発は部品（コンポーネント）を組み合わせて作るため、コード行数（SLOC）を正確に数えることができません。 (2)　カスタマイズ性の限界 プラットフォームの提供するテンプレートや部品に依存するため、業務が複雑だったり、高度な処理が必要だったりすると、“やりたいこと”を満たせない場合があります。 (3)　保守性・スケーラビリティの不安 開発は速いが、アプリが大きくなったりユーザー数が増えたりすると、パフォーマンスや拡張性、セキュリティ確保が難しくなることがあります。 (4)　ガバナンス／標準化の困難 経験の浅いエンジニア（または、現場担当者など）が容易にアプリを作れる反面、誰が、どんな品質で作ったか分かりにくくなります。 (5)　ベンダーロックインのリスク プラットフォーム依存になるため、別のツールへの移行が難しく、将来的な柔軟性が損なわれる可能性があります。 このように、LCP/NCP開発は、“軽さゆえの穴”を持っており、そこをどう管理するか 。 — ガバナンス、標準化、運用・保守体制の整備 — が今後ますます重要になっています。 3. 新しい基準 (1) FUNCTINAL POINT数で規模を測る FUNCTINAL POINT数は、コード行数ではなく機能の規模を測る客観的な基準です。IFPUG法 ※１ に代表されるFUNCTINAL POINT数を使うことで、プロジェクト管理を「勘」から「定量的な判断」に変えることが出来ます。（ITシステム可視化協議会（MCIS）の研究会lcncSig ※2 より） (2) テストの基準 FUNCTIONAL POINT数規模に基づいてテストケース数を分析し、規模に応じた適切なテストケース数の目安を作ります。（テスト密度） これにより、必要なテスト量が明確になります。また、テストは “業務の流れ” を中心にすることが重要です。 ローコードのテストはコードではなく、人がどう操作するかに焦点を当てた方がよいでしょう。 入力して → 承認して → 通知されて → 次の人が処理して… この辺がきちんと回っていることがテストで確認出来れば、大きな問題は起きにくいと考えられます。 (3) ODC分析 ※3 　で不具合の「質」を見る LCP/NCP開発では不具合の「量」だけでなく「質」に着目するODC分析が有効です。 LCP/NCP開発で発生しやすい不具合の傾向は次の様に考えられています。 不具合の種類（タイプ属性） LCP/NCP開発の傾向 アルゴリズム 従来のコード開発より比率が高い ビルド・パッケージ・結合 従来のコード開発より比率が高い タイミング・順序、インタフェース 従来のコード開発より比率が低い ※出展：SQiP ※4 　 2025 発表論文 LCP/NCP開発ではコンポーネントの結合部分や拡張コード（アルゴリズム）の不具合が発生しやすい一方で、LCP製品が標準で制御してくれるインターフェースや順序に関する不具合は減ることになります。 ODC分析については、次のScripts記事を参考にして下さい。 ODC分析：なぜなぜに疲れたQAメンバーに捧ぐ分析手法 4. 品質を判断するためにどうあるべきか LCP/NCP開発は発展途上であり、品質を測る新しいメトリクスもまだ完全に確定していません。前述の指標を活用しつつ、現場のアイデアも取り入れることが重要です。 （1）レビューの活用 製造工程がないLCP/NCP開発では、処理構造やロジックをレビューすることが、実装の品質と保守性を保つために有効です。 余談ですが、コード量と不具合数が相関しない新しいタイプの開発（AIによる自動生成プログラムなど）においても同様な事が言えます。 （2）ガバナンスと標準化の徹底 LCP/NCP開発は手軽に作れる反面、同じような機能でも開発担当者やチームによってバラバラなコードを使用してしまうことがあります。そこで重要になるのが ガバナンス（統制）と標準化 です。 共通の部品やテンプレートの利用 命名ルール、データ定義ルールの統一 変更時の影響範囲を把握できる設計文書の整備 LCP/NCP開発はまだ一般化した標準も少なく、現場ごとに最適なやり方を模索する段階にあります。ですが、設計の可視化・指標に基づいた継続的な評価による品質管理、業務シナリオ中心のテスト、部門内の開発標準の徹底を図ることにより品質の安定化を図ることが出来ます。 まとめ 従来の品質管理が「個々のレンガの強度」を測っていたとすれば、LCP/NCP開発の新しい品質指標（FUNCTIONAL POINT数やODC分析）は、「規格化されたブロックの組み立て方の確かさ」を測ることにシフトしています。これにより、作るスピードを落とさず、安全で丈夫な建物（システム）を確実に建てられるようになるのです。 LCP/NCP開発はまだ一般化した標準も少なく、現場ごとに最適なやり方を模索する段階にあります。設計の可視化・指標による品質管理・業務シナリオ中心のテストを丁寧に組み合わせれば、スクラッチ開発に引けを取らない品質は十分に実現できます。 これからローコード開発の品質に向き合う企業に向けて、このブログが少しでも参考になれば幸いです。 用語解説 ※1　IFPUG法 1980年代に米国で生まれた国際標準(ISO/IEC20916)の機能規模測定法で、画面やファイルなどの“提供する機能”を数値化してシステムの大きさを客観的に評価する手法 ※2　ITシステム可視化協議会（MCIS）の研究会lcncSig LCP/NCP開発の課題を解決するための活動を推進 MCIS | IT システム可視化協議会 ※3　ODC分析 1992年に米IBM社 ワトソン研究所で確立された「欠陥分類手法」、「Orthogonal Defect Classification」の頭文字で、直訳すると「直交　欠陥　分類」となり、お互いに依存しない別軸から欠陥を分類して分析する手法 ※4　SQiP 実践的で実証的なソフトウェア品質技術・施策の研究・普及を目的として、日本科学技術連盟の下に設置されたソフトウェア品質向上のための活動 日科技連|ソフトウェア品質|SQiP研究会 The post ローコードアプリ開発における品質保証 first appeared on Sqripts .

第1回 では、AI時代に求められる思考力とは何かを問い直しながら、「抽象化」と「アナロジー」という武器の正体を解き明かしました。 分類学をアナロジーに、クジラとカバが実は親戚であるという驚きとともに、具体から本質を抜き出す面白さを感じてもらえたでしょうか。 今回はいよいよ実践編。抽象化とアナロジーを、テスト・QAの現場でどう使うか。テスト観点の洗い出し、同値分割法、状態遷移モデル、そして過去の不具合や競合製品からの類推まで、具体的な手法を通じて「考える力」を使いこなすヒントをお届けします。 抽象化をテストに活用する 抽象化は、具体的な仕様から本質的なテスト観点を抜き出し、体系的で漏れのないテストを効率的に設計するために活用することができます。 1. テスト観点の洗い出しと体系化 個別の機能仕様をそのままテストするだけでなく、それらに共通する「本質的な振る舞い」を抽象化してテスト観点を洗い出します。 例えば、「ユーザー登録画面」「商品購入画面」「問い合わせフォーム」など、入力フォームを持つ複数の画面があります。これらから「入力処理」という概念を抽象化し、「必須項目チェック」「文字数チェック」「型チェック（数値、メールアドレス形式など）」「禁止文字チェック」といった共通のテスト観点を導き出します。これにより、個別の画面ごとにゼロから観点を考える必要がなくなり、テストの抜け漏れを防ぐことができます。 2. テスト技法の適用（同値分割法・境界値分析） テスト技法そのものが、抽象化の考え方に基づいていることもあります。 例えば、同値分割法を使って「18歳以上が利用可能」という仕様に対し、無数にある年齢の入力パターンを考えます。これを「17歳以下（無効）」「18歳以上（有効）」という2つの抽象的なグループ（同値クラス）に分けます。そして、各グループから代表的な値を一つずつ（例：10歳、25歳）選んでテストすることで、効率的に入力値の検証ができます。これは、具体的な値を「有効」「無効」という概念に抽象化する思考プロセスです。 3. テストモデルの作成 システムの振る舞いを、状態遷移図やデシジョンテーブルといった抽象的なモデルに落とし込むことで、複雑なロジックを網羅的にテストすることができます。 例えば、状態遷移図を使ってECサイトの注文ステータス（「注文受付」→「入金待ち」→「発送準備中」→「発送済み」→「完了」/「キャンセル」）を状態遷移図としてモデル化します。この図を基に、全ての状態と全ての遷移パターンをテストすることで、ロジックの抜け漏れや意図しない状態遷移がないかを確認できます。 アナロジーをテストに活用する アナロジーは、過去の経験や他の類似システムから類推することで、仕様書には書かれていない潜在的な欠陥や、ユーザーが陥りやすい問題を発見するために活用されます。特に、アナロジーは経験ベースのテストで威力を発揮すると感じています。 1. 過去の不具合事例からの類推 過去のプロジェクトで発生した不具合は、アナロジーを使えばテストケースの宝庫になるかもしれません。 例えば、「以前開発したAというシステムの決済機能で、通信が途切れた際に二重課金される不具合があった。今回のBシステムも同じ決済代行会社を使っているから、同じような状況を再現するテストをしてみよう」と考えることは、過去の事例とのアナロジー（類推）によって、新たなテストケースを発想しています。 2. 類似製品や競合他社からの類推 テスト対象と似た機能を持つ他の製品の挙動は、ユーザーの期待や潜在的な問題点を教えてくれます。 例えば、「競合のCというアプリでは、大量のデータをスクロールするとパフォーマンスが著しく低下する。我々のアプリも似たような一覧表示機能があるので、同様に大量データを登録して性能をテストすべきだ」と考えることで、仕様には明記されていない非機能要件（パフォーマンス）のテスト観点を得ることができます。 3. 実世界のアナロジー システムの振る舞いを、身近な実世界の出来事に例えることで、ユーザー視点のテストケースを発想します。 例えば、「この会議室予約システムは、ホテルの予約と似ている。ホテルなら『ダブルブッキング』『直前のキャンセル』『連泊予約の途中の日程変更』といった複雑なケースがある。システムでもこれらの操作を試してみよう」と考えることで、単機能のテストだけでは見つけにくい、複数操作が絡んだシナリオテストのアイデアが生まれます。 まとめ: 具体と抽象の「往復」が思考の質を変える ここまで、分類学という学問をアナロジーに、「抽象化」と「アナロジー」が私たちの思考にどのような恩恵をもたらすかを見てきました。 クジラとカバが親戚であるという驚きは、私たちが「外見」という具体に囚われていたからこそ生じるものです。「胃の構造」や「蹄の数」という抽象のレベルで世界を捉え直したとき、初めてそこに隠れた本質的な繋がりが見えてきます。 これは、日々のテスト業務やQA活動においても全く同じことが言えます。 目の前の仕様書（具体）をただなぞるのではなく、そこにある「共通項」を見抜くこと。そして、過去の失敗や他者の知恵を「あ、これはあのパターンだ」と今の課題に転用（アナロジー）すること。この抽象化のプロセスこそが、複雑化する現代のシステムを効率よく、かつ深く検証するための強力な武器になります。 The post 【第2回】分類学とアブストラクト（抽象化）〜「思考の武器」をテスト・QAの現場に活かす〜 first appeared on Sqripts .

はじめに 今後のAI時代に必要な「抽象を扱う力」とは 今後のAI時代において、抽象という領域を扱う能力は非常に大事なっていくと言われています。生成AIはコードやテストケースなど、それらを作る具体の作業を代替しつつあるためです。 しかし、私の感覚を正直に言うと、「抽象を扱う力が重要」というのはその通りですが、ちょっと言い足りない気がしています。 というのも、実はAIは抽象化がかなり得意です。大量の具体例から共通項を抜き出して概念化する作業はむしろ人間より速いのです。そのため、「抽象化できる人が強い」という単純な話だと、すぐにAIに追いつかれてしまうかもしれません。 私が大事だと思うのは、「何を抽象化の対象として選ぶか」という手前の判断力です。世の中には抽象化できるものが無限にあって、AIはお題を与えられれば見事に処理してくれます。でも「今、この状況で、何について考えるべきか」を決めるのは人間の仕事として残り続けるはずです。それは問題設定力、もしくは問題発見力と言えるものなのかもしれません。 もう一つは、抽象化された後の世界に居続けられる力です。それはつまり、「具体と抽象を往復する力」です。綺麗に抽象化をすることができると、物事がスッキリ整理されて、見通しが良くなります。一方で、現実は具体の積み重ねで動いています。抽象というモデルからこぼれ落ちたことや抽象にぼやかされた中にこそ本質があったりします。これは、一度具体に降りてそれを発見し、また抽象に戻り、先ほどとは異なる抽象モデルを発見しないと気づくことができません。 抽象化されたモデルを疑う力が今後問われる イギリスの統計学者George Boxは「すべてのモデルは間違っている、しかし有用である」と述べました。この名言において最も重要なことは、モデルとは現実を完全には写し取れず、あくまで近似であるということです。 テストやQAにおける「手順書」「チェックリスト」「方法論」は、いずれも「現実（仕様・ユーザー行動・制約・リスク）」を扱いやすくするためのモデルです。天気予報が地球の気象を完全には再現できず、様々な要因が絡み合った結果外れてしまうように、ガンダムのプラモデルがガンダムではないように、現実を扱いやすく抽象化したものでしかありません。近似とは、そのような性質を持っています。 モデルである以上、必ず取りこぼしや歪みが生じます。だから、手順や方法論に「盲従」しても完全にはなりません。そのため、抽象化する力よりも、抽象化されたモデルを疑う力が、AI時代には希少になっていくと考えています。 その上で、今後の人材には抽象を扱う力が重要であると考えます。それは何を抽象化するかを判断する力です。それは抽象と具体を往復する力です。これらを抽象化すると「思考力」と言うことができます。考える力です。この連載を通して、考える力とは何かについて少しでも皆さまの解像度を上げるお力になれれば幸いと考えています。 分類学と抽象化 非常に唐突ですが、分類学という学問があります。分類学とは、地球上に存在する多種多様な生物を、共通の特徴に基づいて整理し、グループ分け（分類）して、それぞれに名前を付ける（命名）学問のことです。この、名前をつけるという行為はまさに抽象化です。 分類学は、以下のような重要な目的を果たします。 情報の整理: 数百万種とも言われる生物を整理することで、生物の多様性を理解しやすくします。 進化の解明: 以前は「見た目（形態）」を中心に分類していましたが、現在はDNA解析などの技術が進み、生物同士が進化の過程でどのように分かれてきたか（系統関係）の解明に役立っています。 さて、分類学の面白い一面を紹介したいと思います。動物のグループ分けには、鯨偶蹄目という哺乳網の1目があります。鯨偶蹄目は、主にラクダやイノシシ、カバなどが含まれています。 鯨偶蹄目は、以下のようなグルーピングになっています。 鯨偶蹄目（Cetartiodactyla） ┃ ┣━ 核脚亜目（Tylopoda） ┃　　┗ ラクダ科（ラクダ、リャマ） ┃ ┗━ Artiofabula類 　　┣━ 猪豚亜目（Suina） 　　┃　　┗ イノシシ科（ブタ、イノシシ）、ペッカリー科 　　┃ 　　┗━ Cetruminantia類 　　　　┣━ 反芻亜目（Ruminantia） 　　　　┃　┣━ マメジカ下目（Tragulina） 　　　　┃　┗━ 真反芻下目（Pecora） 　　　　┃　　　┗ ジャコウジカ科、シカ科、ウシ科、キリン科、プロングホーン科 　　　　┃ 　　　　┗━ 鯨河馬形類（Cetancodonta） 　　　　　　┣━ カバ下目（Ancodonta） 　　　　　　┃　┗ カバ科（カバ、コビトカバ） 　　　　　　┗━ 鯨類（Cetacea） 　　　　　　　　┣ ヒゲクジラ小目（シロナガスクジラ） 　　　　　　　　┗ ハクジラ小目（マッコウクジラ、イルカ） このツリーの最後に注目してみてください。鯨偶蹄目はラクダやイノシシの仲間と言いましたが、鯨も含まれています。それはなぜでしょうか。 答えは、偶数の蹄があるためです。そのため鯨偶蹄目という名前という名前がついているのですね。実はこのツリーが示す通り、クジラはカバの親戚であることがここ最近の研究でわかりました。ここで、「クジラには蹄なんてないじゃないか！」と思ったことでしょう。実は、水中生活へ適応する進化の過程で後ろ脚や蹄は完全に消失し、現在では骨盤や大腿骨の小さな痕跡が体内に残っていることが研究でわかりました。 さらに、外見上の特徴だけでなく、内臓のつくり、特に「胃」の構造や消化の仕組みにも、進化の足跡が色濃く残されています。 注目すべきは、胃が一つ（単胃）なのか、それとも複数（複胃）なのか。そして、一度飲み込んだ食べ物を口に戻して噛み直す「反芻（はんすう）」を行うかどうかという点です。 例えば、ウシが4つの胃を持っていることは、焼肉がお好きな方ならよくご存じでしょう。焼き肉上の呼び名に、「ミノ、ハチノス、センマイ、ギアラ」があります。これらはいずれも焼肉店でお馴染みの部位ですが、実はすべてウシの胃にあたります。ウシはこの4つの胃を駆使して植物を分解し、反芻を繰り返すことで効率よく栄養を吸収しているのです（焼き肉上の呼び名ってなんだ）。 対照的なのが、同じ草食動物でも奇蹄目に属するウマです。ウマの胃は人間と同じく一つしかありません。その代わり、彼らは巨大に発達した「盲腸」の中に微生物を飼い、そこで時間をかけて食べ物を消化しています。 改めて、そこで再びクジラに注目してみましょう。実はクジラも、複数の胃を持つ動物です。種によって異なり、3つのものから、ツチクジラのように13個もの胃を持つ例外も存在しますが、「胃を複数持つ」という点はウシなどの仲間と共通しています。しかし一方で、クジラは反芻を行いません。この点はウシとは明確に異なります。 ここで重要になってくるのがカバの存在です。カバの胃は3つあり、クジラと同様に「複胃でありながら反芻はしない」という特徴を持っています。この消化器官の共通性は、クジラがウシよりもカバに近い系統であることを示す、有力な証拠の一つとなりました。 このように、現代の分類学はDNA解析だけで決まるわけではありません。内臓の構造や消化の仕組みといった解剖学的な特徴を緻密に比較することで、生物が進化の過程でどのように枝分かれしてきたのか、その壮大な物語をグルーピングしているのです。 抽象化とは、共通する本質的な要素を抜きだすこと さて、抽象化をイメージしやすいように非常に長々と書いてしまいましたが、抽象化とは、具体的な事柄から共通する本質的な要素を抜き出して、一般的な概念やモデルを作ることを指します。抽象化によって概念やモデルが作られると命名することができます。分類学はまさに多様な生き物のモデルを作っています。 抽象化は、具体という複雑なものを単純化し、本質を捉えることができます。これを垂直な思考と呼んだり、ボトムアップと呼んだりします。 抽象化の目的は、複雑さを減らして本質を理解しやすくすることです。 例えば、「柴犬」「プードル」「チワワ」などの個々の個体から、「4本足で歩く」「哺乳類である」「人に懐く」といった共通の特徴を抜き出して「犬」と名付けることができるかもしれません。様々な企業の成功事例から、「顧客中心主義」「迅速な意思決定」といった共通の成功要因を抜き出すことも抽象化です。 グルーピングをして名前をつけるということは、抽象化とは複数の具体に対して1つの抽象が対応するような「N:1」の関係が成り立つことがわかります。 再び鯨偶蹄目のツリーを見てみましょう。鯨偶蹄目に対して、たくさんの対応関係が紐づいていることがよくわかります。 鯨偶蹄目（Cetartiodactyla） ┃ ┣━ 核脚亜目（Tylopoda） ┃　　┗ ラクダ科（ラクダ、リャマ） ┃ ┗━ Artiofabula類 　　┣━ 猪豚亜目（Suina） 　　┃　　┗ イノシシ科（ブタ、イノシシ）、ペッカリー科 　　┃ 　　┗━ Cetruminantia類 　　　　┣━ 反芻亜目（Ruminantia） 　　　　┃　┣━ マメジカ下目（Tragulina） 　　　　┃　┗━ 真反芻下目（Pecora） 　　　　┃　　　┗ ジャコウジカ科、シカ科、ウシ科、キリン科、プロングホーン科 　　　　┃ 　　　　┗━ 鯨河馬形類（Cetancodonta） 　　　　　　┣━ カバ下目（Ancodonta） 　　　　　　┃　┗ カバ科（カバ、コビトカバ） 　　　　　　┗━ 鯨類（Cetacea） 　　　　　　　　┣ ヒゲクジラ小目（シロナガスクジラ） 　　　　　　　　┗ ハクジラ小目（マッコウクジラ、イルカ） これを言葉に置き換えてみると、 曖昧な言葉は複数の解釈を生む ことがわかります。犬といっても、チワワもいるし、ダックスフンドもいるし、ゴールデンレトリーバーもいる。これが「曖昧なことを言われてもわからないよ」となってしまうことの正体です。 一方で、抽象化は応用が効きます。 「複数の異なる事象の間にある『共通のルール（本質）』を取り出せるから」 です。「具体」の世界に留まっていると、新しい問題が起きるたびにゼロから考えなければなりません。しかし「抽象」という武器を持っていれば、過去の経験を「あ、これはあのパターンと同じだ」と当てはめて解決できるようになります。これが「応用が効く」という仕組みの正体です。 アナロジーという応用 アナロジーとは、「類推」や「類比」を意味し、ある事柄（ベース）をもとに、類似点を持つ他の事柄（ターゲット）について推し量る考え方です。具体的には、異なる事柄の間に共通点を見つけ出し、その共通性を利用して未知の事柄を理解したり、解決策を導き出したりします。 私が長々と例に挙げた「分類学」も、抽象を説明するためのアナロジーです。これは、ある領域から別の領域に思考を広げる、水平な思考と呼ばれる思考法です。未知のものを既知に例えることで理解を助けることができます。そのほかにも、既知の領域の知識を応用し、新しいアイディアや解決策を発想することができます。 例えば、 「原子の構造」を「惑星が太陽の周りを回る太陽系」に例えて説明することができます。 「コンピューターウイルス」の振る舞いを、「体内に侵入して増殖する生物のウイルス」に例えることができます。 次回へ続く 次回、「『思考の武器』をテスト・QAの現場に活かす」へ続きます！ 私たちが手に入れた抽象化とアナロジーの力が、日々の検証業務をどう変えるのかについてお話しします。 The post 【第1回】分類学とアブストラクト（抽象化）〜AI時代を生き抜くための「思考の武器」〜 first appeared on Sqripts .

ここまで3回にわたって、アウトプットの意義、実践知の言語化、そして社外への踏み出し方についてお話ししてきました。いずれも主にアウトプットする個人の視点から取り上げてきた内容です。 アウトプットが重要であり、ぜひやっていこうというメッセージは伝わったかと思います。しかし、アウトプットを「あくまで個人の責任だ」「本人の努力でやるべきだ」と個人の問題に帰属させると、結局は個人の意欲頼みになってしまいます。それでは組織として長続きしません。 連載の最終回となる今回は、アウトプットの活動を支える組織としての仕組みについて、いくつかの視点から考えていきたいと思います。 記事一覧：【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 【最終回】アウトプットを「個人の頑張り」で終わらせない：学びのスパイラルを組織で支える 同僚・チームメンバーとしてできること まずは、アウトプットをする人の隣にいるチームメンバーや同僚の立場から考えてみます。 皆さんの視点からぜひお願いしたいのは、アウトプットに協力して背中を押したり、フィードバックをしたりするといった直接的な支援活動です。 特に私が価値を感じるのは、日々の雑談やコミュニケーションの中で 「それってアウトプットのネタになるんじゃない？」と提案する ことです。そこから実際にアウトプットが完了するまで隣に寄り添い、レビューやコメントをしたり、背中を押し続けたりする活動は、身近にいるからこそできる直接的な貢献です。 こうした身近なメンバーがお互いに背中を押し合いながらアウトプットをしていけると、切磋琢磨する関係にもつながります。組織の中で最も人数が多く、アウトプットする人の最も近くにいるのは同僚です。だからこそ、誰もが今日から実践できるという意味で、これが現場にアウトプットを根付かせる一番の鍵だと考えます。 マネージャーの役割 次に考えたいのは、マネージャーの立場です。 マネージャーの振る舞いとして最も重要なのは、 アウトプットを奨励する環境をどれだけ作れるか という点です。日々、マネージャーという指導的な立場にある人が、どれだけアウトプットを促すような考え方や振る舞いを見せられるかが、組織のアウトプット文化を大きく左右します。 注意したいのは、採用広報のためだけにアウトプットのノルマを強制したり、やらないメンバーの評価を下げたりしないことです。大切なのは、メンバーの「学びたい」「成長したい」という内発的な動機を自然に後押しし、その手段としてアウトプットを位置づけることです。 そのためには、まずマネージャー自身がアウトプットへの理解を深めなければなりません。マネージャーが自ら学ぶ姿を見せることがメンバーの学習行動を促すという研究知見もあるように（参考： Leadership and Learning at Work ）、マネージャーこそ積極的にアウトプットを行い、外部のカンファレンスやコミュニティなどの学びの機会に自ら出ていくべきです。そこでの学びを組織に持ち帰り、「良いアウトプットの仕方」をメンバーに伝えるサイクルを作れると素晴らしいのではないでしょうか。 マネージャーの「権限」を活かす マネージャーには組織のリソースの配分を決定できる「権限」があるという独特の強みがあります。この権限を活かしてできることとして、以下の二点が挙げられます。 業務時間の配分 ：アウトプットの時間を「業務時間」として認める 予算の確保と行使 ：外部イベントへの参加費・協賛費として予算を確保し、使う この二つのうち、後者の予算の使い方として、私が特に強調したいのが「協賛の意思決定」です。イベントへの参加・登壇・運営は、個人が自分の意思で動ける関わり方です。しかし協賛だけは、社名を出して組織のリソースを投じる判断が必要です。稟議を通す力を持つか、組織を代表して意思決定できる立場にある人しか、この選択肢にはアクセスできません。 だからこそ、その立場にいる方にはぜひ積極的に動いてほしいのです。協賛を通じてメンバーに参加枠を提供することは、学びの機会への投資であり、外部イベントという「学びの場」を直接支援する活動です。それは業界への貢献でもあります。長期的には採用や自社のプレゼンス向上にもつながっていきます。 学習への投資を組織の仕組みにする アウトプットは、それだけで完結する活動ではありません。前回お話しした「学びのスパイラル」を思い出してください。現場での実践から得た気づきを言語化し、外部で共有してフィードバックを受け、新たな視点を持ち帰って再び実践に還元する。この循環の中にはインプットも対話も内省も含まれていて、それらが噛み合ってこそアウトプットが生まれます。ですから組織としては、アウトプットだけを単独の施策として促すのではなく、このスパイラル全体を支える制度や仕組みを整えることが重要です。 具体的には、以下のような支援の仕組みをぜひ検討してみてください。 カンファレンスへの参加支援 業務として参加できるようにする ：有給休暇を消化して参加するのではなく、業務扱いにする 出張代を支給する ：交通費や宿泊費を組織が負担する 参加費を会社で負担する ：チケット代を経費として処理できるようにする 前回お話しした通り、私はカンファレンスでの学びを仕事の一部だと捉えています。これを「プライベートな活動」として個人に負担させるのではなく、組織として投資する姿勢を示すことが大切です。 その他の学習支援 書籍の購入補助 ：業務に関連する書籍を会社の費用で購入できるようにする 研修への参加支援 ：外部の研修やトレーニングに参加する機会を設ける こうした制度は、誰かが前例を作らないとなかなか広がりません。私自身はマネージャーとして、カンファレンスの協賛予算の確保、書籍購入手続きの簡略化、コミュニティ運営の業務時間への組み込みなど、自ら先行事例を作ることを意識的にやっていました。前例のない予算の使い方には抵抗がつきものですが、誰かが最初に突破口を開かないと後が続きません。こうした「道を均す」活動こそ、マネージャーだからこそできる貢献だと考えています。 組織制度としての支援 もう少し広い視点から、組織の制度や文化としてアウトプットを支える仕組みについても触れておきます。ここまで来るとマネージャー一人の一存では決められない範疇ですが、全社的な方針や人事施策を考える立場の人にとって重要なテーマです。 アウトプットを正当に評価する仕組み 奨励する仕組みとして最も重要なのは、アウトプットする人をきちんと評価することです。 「アウトプットしてもしなくても、日々の業務を遂行するという点では差がない」というのは、短期的にはその通りかもしれません。しかし、少なくとも私の経験上、長期的に見るとアウトプットを続ける人とそうでない人では、成長の軌跡、外部ネットワークの広がり、業界内でのプレゼンスにおいて大きな差が生まれています。Wengerの「実践共同体（Communities of Practice）」の考え方が示すように、コミュニティへの参加と貢献を重ねること自体が、専門家としてのアイデンティティを形成する成長プロセスです（参考： Introduction to Communities of Practice ）。 アウトプットしないからといって評価を下げる必要はありません。しかし、アウトプットに励んでいる人に対しては、しっかりとプラスアルファの評価をしていくことが重要です。 文化とコミュニケーションスタイルの変革 アウトプットを支え合うには、組織のカルチャーや日々のコミュニケーションスタイルが大きな影響を与えます。 クローズドなやり取りしか行われず、オープンに問題をディスカッションする文化がない状況では、お互いのアウトプットを支え合うのは困難です。また、広報のチェックが過度に厳格で、社名を出して発信することのハードルが非常に高い組織も多く見受けられます。まずは社内で活発な情報共有ができるようなツールの整備や、環境作りから始めていく必要があります。 これらに即効性のある手段はありません。経営層や人事部門が「こうしたアウトプットやコミュニケーションをしっかりとっていくことが大事だ」と繰り返し発信し続ける必要があります。 心理的に安全な環境を整え、その中でメンバーが自律性を持って活動を広げていけるような仕組み作りが、組織のアウトプットを加速させる鍵となります。 連載のまとめ：アウトプットとは何か 4回にわたってお伝えしてきたことを整理します。 アウトプットとは、単にブログを書いたり登壇したりする一方向の情報発信活動ではありません。アウトプットという活動自体が、本人の学びや思考力を鍛えるための貴重な成長の機会です。 アウトプットは本人の内発的な動機から生まれるものです。「アウトプットができる状態を作る」ということは、メンバーの「学びたい」という意欲を阻害せずに、いかに発露させられるかという問題に帰結します。 そこから生まれたアウトプットは、単に情報を公開して終わりではありません。もちろん、組織としてレピュテーションリスクや情報管理に配慮する必要はあります。しかし、それを理由にアウトプットを過度に制限してしまうのはもったいないことです。公開された情報は、それを受け取った人にとって大きな学びや気づきの機会になります。発信が増えれば増えるほど、受け手にとっての学びが増えるだけでなく、組織に対する興味を喚起し、採用や組織の成長にもつながる長期的な投資です。 さらに、アウトプットのメリットは本人や自組織の利益に留まりません。業界全体の知見共有が促進され、知識がアップデートされ、より良い手法が広まり、全体のレベルが高まっていきます。アウトプットとは単なる情報発信や採用活動ではなく、コミュニティへの貢献であり、業界とのコミュニケーションの手段そのものです。 こうした知識のオープンな共有という文化は、エンジニアが長年かけて築いてきたオープンソースの精神と地続きです。私たちはすでに、先達が公開してきたコード・記事・登壇資料・ツールの恩恵を日々受け取っています。その積み重ねの上に、自分たちの仕事が成り立っている。ならば、自分たちもその一部として発信し、次の誰かに手渡していく。アウトプットとは、その連鎖に自らも加わることだと思っています。 上手にアウトプットができる組織は、業界に貢献することでより多くの学びを得て成長し、コミュニティからの信頼も得られるという「良いサイクル」を回すことができます。 「アウトプットしてもしなくても、自分の成長には影響がない」と感じている方がいるかもしれません。しかし、一見すると小さく些細に思えるこの活動には、大きなポテンシャルがあります。そこから学びが広がり、外の世界とつながることで、見える景色は全く違うものになっていきます。 組織としてアウトプットに向き合うということは、学びに対する姿勢そのものを見直すということです。メンバーの学びを支え、背中を押し、内と外を往復する学びのスパイラルを組織全体で育てていく。その最初の一歩を、ぜひ踏み出してみてください。 【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 【最終回】アウトプットを「個人の頑張り」で終わらせない：学びのスパイラルを組織で支える ［全文公開中］ The post 【最終回】アウトプットを「個人の頑張り」で終わらせない：学びのスパイラルを組織で支える first appeared on Sqripts .

前回の山下さんからバトンを受け取りました、伊藤由貴です。 「E2Eテスト自動化」という話題は私としてもある程度関わってきたジャンルなので、なにか思考のタネをご提供できればと思います。 今回は山下さんから2つのポイントをいただいているので、それに対して私なりの意見をお伝えしつつ、私から山下さんや読者の皆さまに問いを立てていきます。 テスト自動化の移り変わりや流行りについて テスト自動化と一口に言っても、そのツールや対象などはだんだんと変化してきました。これはテスト自動化単独というよりは、例えばデスクトップからWeb・モバイルへと、一般的なアプリケーションの動作環境が変わってきたことなど、さまざまな環境要因によるものです。 いろいろと思い出話をしてしまうと長くなるので割愛しますが、ここ10年ほどはWebアプリケーションの自動化がかなり盛り上がった期間だったように思います。SeleniumやPlaywrightなどオープンソースのライブラリが登場したことで、それまでの高価・高機能な有償ツールを用いた自動化から、誰でも手元で学習・トライアルできる自動化へと移り変わってきました。 そして現在は、生成AIによるコード生成など、また新たな変化の波が来ています。このあたりは山下さんの記事中でも言及されていましたね。 問い：生成AIの登場でノーコードのテスト自動化ツールがどのような影響を受けるのか 山下さんからいただいたポイントのひとつがこちらです。 まず、この問いの背景情報として、私は現在「ノーコードのテスト自動化ツール」を提供する会社に所属しています。そのため（可能な限りフラットに発言しようと思いますが）バイアスが含まれていたり、ポジショントークのように見えたりする可能性があります。読者の皆さまに対してフェアでいるためにも先にお伝えしておきます。 そのうえで、実はこうした「ノーコードテスト自動化ツールは生成AIにどのような影響を受けるか」に類する質問は最近よくいただきます。山下さんがそのような意図かどうかは別として、多くは「（ビジネス的に）大丈夫なの？」という言外のニュアンスを含んでいるようです。SaaS is DEADなどと言われることもあるように、生成AIが既存のツールやビジネスを破壊する、駆逐するといった印象をもたれることは、一般論として増えていそうです。 このような側面は、確かにあると思います。ノーコードテスト自動化ツールは、コードを読み書き出来なくてもテスト自動化ができる、という点が一つのメリットです。ところが生成AIを使うことでも、コードを書かずに（正確にはAIがコードを書いてくれることによって）テストを自動化できるようになりました。最近は全社員が生成AIを使えるという会社も増えていて、テスト自動化に限らずさまざまなツールの契約を見直し、生成AIでできることはそれでまかなってしまおう、という動きも多くあるようです。ただ、個人的には生成AIでノーコードツールが完全に代替できるかというと、そうではないと考えています。生成AIのサポートで自動化ができる人・チームもあれば、やっぱりノーコードツールが必要だよねという人・チームもあるだろう、という予想です。 生成AIで自動テストコードが生成できるのは確かに便利ですが、私が JaSST’26 Tokyoのセッション でも繰り返し述べたように、テスト自動化は運用が大事です。 個人の、あるは短期的な視点で「自動化をする」「自動テストを生成する」ことはできても、組織で、長期的な視点で「自動テストを継続的に運用する」ためには、生成AIだけでほんとうに十分なんだろうか？そこにノーコードツールの強みがあるのではないか？と思っています。 生成AIはものすごいスピードで進化しているので、運用まで含めてAIにおまかせできる時代が来る可能性は十分にあります。しかし、そういう時代が来ることと、運用のことを考慮せずに「生成AIがあればオッケー」と安易に考えるのとでは別の話です。自動テストを自分たちが運用しつづける際のプロセスや担当など、組織としての取り組み方や仕組みを十分検討したうえで、それらが生成AIによって実現可能である、と判断できたのであればノーコードツールを使わずに生成AIでいこうとするのは納得できます。自動テストの作成だけを考えて判断するのは危険である、という点はぜひ気にしていただきたいポイントです。 また違った視点として、生成AIはテスト自動化をしたい方だけが使える道具ではありません。テスト自動化ツールを提供する側もまた、生成AIを自社のツールに取り込み、これまで以上にユーザーのためになる機能や新ツールの開発を続けています。テスト自動化ツールが生成AIを活用することで、たとえばノーコードかコードベースかといった軸とは全く違うパラダイムでの自動テストを行うツールに進化をするかもしれません。 このように、大きな変化をもたらすきっかけや手段として、生成AIがノーコードテスト自動化ツールに影響するのではないかと思います。 問い：自動テストについて慎重に考えること 山下さん記事の内容を引用します。 私はテスト自動化が「当たり前の技術」となり、だからこそ慎重に「自動テスト」について考えるような、手動テストの設計時と同様に、冷静な視点が必要だと感じています。この点について、ぜひ見解をお聞きしたいです。 まず、前提となっている テスト自動化が「当たり前の技術」となり の部分について。 この点は、実感としては合っているように思います。各社の求人を見ていても、「QA・テストエンジニア」と「テスト自動化エンジニア・SET」を明確に分けている求人が減ってきており、QA・テストエンジニアの必須もしくは歓迎スキルとしてテスト自動化が扱われることが多くなっているように感じます。（データがないので、体感です。） 一方で「本当にそうだろうか、当たり前になっているんだろうか」と思うこともあります。 そのひとつには、これまた生成AIの普及がある、とみています。 数年前はある種「テスト自動化ブーム」のような時期もあり、日本で一番大きいソフトウェアテスト関連のカンファレンス、JaSST Tokyoのセッションで自動化の話題がいくつも出てきていました。 それが、2026年現在は「生成AIを用いた～」が（大げさに言えば）ほぼすべてのセッションに含まれているくらい、生成AI活用が流行っています。 テスト自動化は、ある意味この生成AIという「次のブーム」に押し出される形で「一昔前の流行り」になっていて、それを「当たり前の技術」になったと捉えている部分があるのではないでしょうか。 たしかに、自動化の技術や考え方は以前と比べると当たり前に近づいています。しかし、当たり前になることと、流行りが落ち着いたこととを一緒にしてはいけません。 ということで、もとの山下さんからのコメントに戻ると、 冷静な視点が必要だと感じています に賛成です。 山下さんの意図した冷静な視点、に沿う回答かどうかはわかりませんが、仮にズレていたとしてもそれもまたこの往復書簡スタイルの面白さ、ということにしましょう。（ちなみに、裏に台本などはなく、事務的なやりとりを除けば本当にこの記事だけでやりとりをしています。） もうひとつ、普段私が考えていることでかつ冷静な視点に当てはまりそうなこととして、テスト自動化のこれまでの常識を改めて考え直す必要がある、という点です。 テスト自動化に関するベストプラクティスやアンチパターンは、書籍や事例発表など先駆者たちの活動で広く皆が知るところになりました。これも当たり前の一部ですね。 しかし、ベストプラクティスやアンチパターンと言われるものには、当然ながら前提があります。 たとえばテストピラミッド。おおざっぱに言えば、単体テストを充実させ、E2Eテストは必要最小限にするのが良い、という考え方です。 この考え方には、単体テストのほうがE2Eテストに比べて実行時間が短く、実行コストが低いという前提があります。ではもし、E2Eテストが単体テストと同じくらい高速・低コストで実行できるなら・・・？ これはあくまでも一例ですし、改めて前提を疑った結果、それでもやはりベストプラクティスだ、という結論になることもあるでしょう。 しかし、テスト自動化が当たり前になったことに加えて生成AIの登場によりさまざまな前提が覆る可能性のある今、テスト自動化を知ったつもりになって当たり前をなぞるのではなくて、きちんと理解したうえで一度問い直す、といった姿勢が求められているのではないでしょうか。 山下さんへのバトン テスト自動化が当たり前の技術になったのかどうか、という点について、山下さんから見た印象もお伺いしてみたいです。ソフトウェアテスト・QA界隈だけでなくプログラミング言語やアジャイル、そして海外も含めた幅広いコミュニティに参加している山下さんの視点での感覚も知りたいです。 また、自動テストについて冷静な視点が必要ではないかという意見は、裏を返すと「冷静でない」、たとえば過剰な期待や、それとは反対に価値を低く見られているなどの状況を目にしたことがあるのかな？と想像しました。 このあたり、具体的に「こんなのを見た・聞いた」があれば（話せる範囲で）聞いてみたいです。 The post 【第2回】E2Eテスト自動化でつなぐ②〜生成AIがテスト自動化に及ぼす影響をどう捉えるか〜 first appeared on Sqripts .

「QAエンジニア」と一口で言っても、その背景や専門性は多岐にわたります。 前回の連載では、自身の経験がブリコラージュのように結びつき、現在の土台となっていることについてお話ししました。 本連載は新たに、「 Connecting the dots 」というテーマを扱います。 本連載では、今まで現場やコミュニティの中で出会ってきた専門家の皆様と、往復書簡のような形で意見を交換していきます。 ひとりひとり独立した専門家という「点」を、技術や関心ごとといった共通点で繋ぎ、連載を形作ります。 本シリーズ最初の話題は「E2Eテスト自動化」を取り扱いたいと思います。 お相手は同じくSqripterの伊藤由貴さんで、2回程度の往復（全5回）を予定しています。 本記事では、私の視点から「E2Eテスト自動化のいまむかし」について振り返りつつ、伊藤さんへバトンを渡したいと思います。 ※これ以降、単に「テスト自動化」と表現するものは「E2Eテスト自動化」を指します。 テスト自動化との出会い 私が「テスト自動化」というものに本格的に触れる機会があったのは2021年ごろです。 第三者検証会社での「テスト自動化トレーニング」という1ヶ月ほどのフルタイムの研修に通った時期でした。 当時の私はターミナルがインターフェースとなる製品にしか携わったことがありませんでした。 テスト自動化の技術が公に議論されているWebの分野については全くの未経験であり、どこか蚊帳の外にいるような感覚がありました。 Seleniumを主として、複数のツールを使ってE2Eテスト実装の体験をしました。 2020年にもJSTQBのワーキンググループからテスト自動化エンジニアのシラバスが翻訳されたこともあり、「テスト自動化」という技術が「特別な経験者が持つスキル」から「勉強すればアクセスできるスキル」という位置付けに変わってきたタイミングだったなと今では思います。 現在隆盛を誇っているPlaywrightを触り始めたのもこのタイミングであり、当時は後発のツールであるPlaywrightがどんな思想で、どんな優位性を持っているかという、初期段階の構想を調べたことがあります。 この体験がきっかけとなって、テスト自動化カンファレンスで発表するアイデアが生まれたことなど、今振り返ると、感慨深いものがあります。 余談：伊藤さんとの不思議なご縁 この連載を始めるときに全く意識していなかったのですが、この研修コースを企画・運営している課の課長が伊藤さんでした。 また、現在私は主に”QAエンジニア”と呼ばれるロール、あるいはテストや品質保証に関する明確な専門家がいない現場を支援することがあります。いわゆる「一人目QA」のような立場で支援を行っています。 当時は（今もですが）雲の上のような存在でしたが、今でもこうして伊藤さんから多くを学びつつ、親しく交流させていただいていることに、不思議なご縁を感じています。 テスト自動化の現在 2026年現在、私がテスト自動化を学んでから5年程度が経ちましたが、特にWeb分野のテストエンジニアのスキルセットとして、その位置づけが大きく変化してきたように感じます。 5年前は「テスト自動化ができる環境をセットアップしてコードが書ける」というだけでも重宝されていた記憶があります。 一方、今ではテスト自動化という分野は採用において前提条件となっていたり、当たり前の技術になっていると強く感じます。 特にPlaywrightについてはプロダクトコードを書くエンジニア、いわゆる”開発者”が詳しく知っているような現場に何度か出会いました。 生成AIによるコード生成 こういったテスト自動化のやりやすさは生成AIの登場により、ますます顕著になったと考えます。 （個人的にはあまり推奨したくない表現ですが）いわゆる「エンジニア経験のないQA」であっても、自然な日本語を使ってテスト自動化フレームワークが動作する環境を作り、開発環境をセットアップし、テストコードを書くことができるようになったためです。 テスト自動化をどう考えるか テスト自動化の成果物、つまりテストコードが簡単に書けるようになって、「何を自動テストにするか」というテスト計画・設計・分析といった知見の必要性が強くなってきたことも感じます。 一見これは生成AIによるプロダクトコードと同様の論点に聞こえます。 しかしながら、テストはプロダクトコードと違い、ユーザーの使われ方や売り上げといった、効果測定や仮説検証がしづらい課題があると考えています。 こうしたテストコード特有の落とし穴は想像以上に根深く、AIを活用してテストコードを生成する際に、その課題の大きさを痛感させられます。 テスト自動化ではなく自動テスト ここで一言言及しておきたい考えがあります。 「テスト自動化ではなく自動テスト」という考え方です。 「テストを自動化する」ではなく「自動化に適したテストを自動テストとして捉え直す」という提言はSqripterでもある末村さんが2020年にすでに言及されています。 私も、本記事では「テスト自動化」という言葉を使っていますが、普段は文脈により「テスト自動化」と「自動テスト」は使い分けるようにしています。 そして、可能な限り後者の表現が適した活動になるよう日々心がけています。 参考： テストを自動化するのをやめ、自動テストを作ろう​​ （Speaker Deck）／Takuya Suemura AIテストツールの現在は？ 生成AIが爆発的に流行する以前にあった、いわゆる「ノーコードテスト自動化ツール」はどうでしょうか。 実のところ、私は過去にノーコードテスト自動化ツールに対して苦手意識を持っていました。 2021年にMagicPodをはじめとしたテスト自動化ツールを触りましたが、率直な感想として「ノーコードよりもコードを書いた方が実装者としていい体験ができる」という感覚を持った覚えがあります。 そうした背景から、ノーコードテスト自動化ツールに関しては自発的に学習する意欲を保つのが難しい時期がありました。 そのため、テスト自動化ツールの知識はテスト自動化実装担当者として手を動かさなくなってから、アップデートされていないのが実情です。 私がツール選定に関わる立場になっても、これらのツールを積極的に採用する機会に恵まれませんでした。 一方で現在では、PlaywrightのCodeGenのように、コードベースのツールでもノーコードツールと同等の機能が簡単に実現できるようになっています。 また、PlaywrightCLIなど、生成AIを効果的に使いながらさまざまな運用が可能になっていますね。 なにより、テストコードの自動修正など、機能レベル（あるいはカタログスペックとして）で同等のことが簡単にできるようになったとも考えます。 伊藤さんへのバトン ぜひ伊藤さんに聞いてみたいことがあります。 私はテスト自動化が「当たり前の技術」となり、だからこそ慎重に「自動テスト」について考えるような、手動テストの設計時と同様に、冷静な視点が必要だと感じています。この点について、ぜひ見解をお聞きしたいです。 そして、生成AIの登場でノーコードのテスト自動化ツールがどのような影響を受けるのか。 現在MagicPodのエヴァンジェリストをされている伊藤さんがこの状況をどう捉えておられるか、ぜひ見解をお聞かせいただきたいです。 The post 【第1回】E2Eテスト自動化でつなぐ①〜E2Eテスト自動化のいまむかし〜 first appeared on Sqripts .

こんにちは、QAコンサルタントのヤマダです。 「いい感じのシステム、よろしく！」 エンジニアやプロダクトマネージャーの皆さん、顧客からこんな風に、フワッとした要望を受けて困った経験はありませんか？ 良かれと思って作ったのに「なんか違うんだよな…」と言われてしまったり。 こうした悲しいすれ違いを防ぎ、顧客の真のニーズを引き出してプロジェクトを成功に導くための強力な武器が、ビジネスアナリシスの知識体系 BABOK® (Business Analysis Body of Knowledge) です。 今回は、このBABOKの考え方を使い、ある飲食店の「漠然とした想い」を具体的なシステム要求に落とし込んでいくプロセスを、ケーススタディ形式でご紹介します。 BABOKとPMBOK：プロジェクト成功の両輪 BABOK（バボックと読みます）は、ビジネスアナリシスの専門機関であるIIBA®が策定した、ベストプラクティスを体系的にまとめた「知識の地図」のようなものです。 この話をすると、プロジェクトマネジメントの知識体系である PMBOK® (Project Management Body of Knowledge) とどう違うのか、という質問をよく受けます。この二つの違いを理解することは、プロジェクト全体を成功させる上で非常に重要です。 一言で言うと、その目的が異なります。 BABOK® (ビジネスアナリシス) PMBOK® (プロジェクトマネジメント) 目的 正しいプロダクトを作る (Do the right thing ) プロダクトを正しく作る (Do the thing right ) 焦点 What (何を作るか), Why (なぜ作るか) How (どう作るか), When (いつまでに) 役割 ビジネスニーズの発見、要求の定義 計画の立案、リソース・進捗の管理 BABOKが「そもそも何を作るべきか？」という上流工程を担う のに対し、 PMBOKは「作ると決まったものを、いかに計画通りに完成させるか？」という実行工程を担います。 例えるなら、BABOKが「目的地（＝ビジネスゴール）を定め、そこへ至るための航海図を描く」役割、PMBOKは「その航海図に基づき、船（＝プロジェクト）を安全かつ効率的に運航する航海術」と言えるでしょう。 両者は対立するものではなく、プロジェクトという船を成功に導くための「両輪」なのです。ビジネスアナリストとプロジェクトマネージャーが協力し合うことで、初めて「価値あるものを、計画通りに」届けることができます。 ちなみに、BABOKにはその知識レベルを証明する国際資格として、 CBAP® (Certified Business Analysis Professional) など、実務経験に応じた認定資格制度（ECBA , CCBA®, CBAP®）もあります。 さて、今回のケーススタディでは、特にBABOKが担う 「何を作るべきか」を定義する部分 に焦点を当てて見ていきましょう。 ケーススタディ：あるレストランオーナーの悩み クライアント: 地域で人気のイタリアンレストランのオーナー 相談内容: 「最近『ネットで注文や予約できないの？』ってよく聞かれるんだ。電話対応も大変だし、テイクアウトも強化したい。ついでに人気メニューも分析できたら最高だね。」 さあ、この「想い」をBABOKの6つのステップで具体化していきます。 実践！BABOK流・要求具体化の6ステップ Step 1: 計画とモニタリング (どう進めるか決める) いきなり機能の話をするのではなく、まずプロジェクトの進め方を決めます。 やること: 関係者は誰か、どうやって情報を共有するか、どんな進め方をするかを計画します。 具体例: 関係者: オーナー、ホール・キッチンスタッフ、常連客など 進め方: 週1でオーナーと会議。簡単な試作品を触ってもらいながら進める（アジャイル的アプローチ）。 情報共有: 議事録や資料はGoogle Driveで共有する。 Step 2: 引き出しとコラボレーション (本音と課題を聞き出す) 関係者から、言葉の裏にある本音や現状の課題を引き出します。 やること: インタビューや業務観察を通じて、関係者のニーズや問題点を深く理解します。 具体例: スタッフに現状の電話予約業務の課題（聞き間違い、予約の重複など）をヒアリング。 店舗のピークタイムの様子を観察し、業務のボトルネックを発見する。 ヒアリング結果を簡単な図や文章にまとめ、「こういうことで合ってますか？」と認識を合わせる。 Step 3: 戦略アナリシス (ビジネスの「なぜ」を掘り下げる) ここは、プロジェクトの心臓部とも言える非常に重要なステップです。単に現状の課題を洗い出すだけでなく、 「そもそも、このプロジェクトを通じてビジネスとして何を達成したいのか？」という根本的な問い（ビジネスニーズ） を定義します。 このステップを飛ばすと、いくら高機能なシステムを作っても「で、結局ビジネスの何が良くなったんだっけ？」という状態に陥りがちです。戦略アナリシスでは、主に以下の4つの視点で考えます。 現状の分析 (Analyze Current State): 我々は今どこにいるのか？ なぜ変化が必要なのか？ 将来状態の定義 (Define Future State): どこへ向かいたいのか？ 成功した状態とはどんな状態か？ リスクのアセスメント (Assess Risks): その道のりにどんな障害物（不確実性）があるか？ 変革戦略の定義 (Define Change Strategy): どうやってゴールまでたどり着くか？ 最適なルートは？ これらを踏まえた上で、今回のレストランのケースでは以下のように考えます。 具体例: 現状(As-Is): 電話対応に追われ、機会損失や顧客満足度の低下が起きている。売上データが属人的で活用できていない。 将来状態(To-Be): オンラインチャネルからの売上が30%向上し、スタッフはより付加価値の高い接客に集中できている。データに基づいたメニュー開発が可能になっている。 リスク: スタッフがシステムを使いこなせない。導入コストが想定以上にかかる。 変革戦略: まずはリスクの少ないテイクアウト機能からスモールスタートし、スタッフと顧客の反応を見ながら予約機能などを段階的に導入する。 Step 4: 要求アナリシスとデザイン定義 (アイデアを設計図にする) 理想の姿を実現するための具体的な機能（＝要求）を洗い出し、設計に落とし込みます。 やること: 要求を機能（例: 決済機能）と非機能（例: 使いやすさ）に分類し、システムの画面イメージなどを作成します。 具体例: 機能要求: メニュー表示、オンライン決済、予約カレンダー 非機能要求: スマホで使いやすいデザイン、3秒以内の画面表示 手書きのラフな画面イメージ（ワイヤーフレーム）を描いて、オーナーと「こんな感じですか？」とすり合わせる。 Step 5: 要求ライフサイクル・マネジメント (変化に強く、ブレない軸を持つ) プロジェクトを進める中で発生する要求の変更や追加に、うまく対処します。 やること: 機能に優先順位をつけ、追加要望が出た際の影響を評価し、対応を判断します。 具体例: 優先順位付け: 「オンライン決済」は必須（Must）、「クーポン機能」はできれば（Could）のように整理する。 変更管理: 「デリバリー機能も欲しい」という追加要望に対し、開発期間とコストへの影響を提示し、導入するかどうかをオーナーと合意する。 Step 6: ソリューション評価 (作って終わりじゃない、価値を測る) 完成したシステムが、本当に当初の目的を果たしているかを確認します。 やること: システム導入後の効果をデータで測定し、さらなる改善点を見つけます。 具体例: 導入前に立てた目標（KPI）である「電話対応時間を50%削減」「オンライン売上30%UP」を達成できたか計測する。 「メニューの更新が少し面倒」といったスタッフからの意見を収集し、次の改善アクション（例: 管理画面の改修）を提案する。 まとめ いかがでしたか？ BABOKのフレームワークに沿って進めることで、オーナーの 「いい感じにしたい」 という漠然とした想いが、 何を: テイクアウトと予約のオンラインシステム なぜ: 業務効率化と売上向上のため どうなれば成功か: オンライン売上30%UP といった、 誰が見ても明確で、測定可能なゴールを持つプロジェクト に変わりました。 日々の開発業務で「これ、何のために作ってるんだっけ？」と感じたとき、この6つのステップを少しだけ意識してみてはいかがでしょうか。きっと、あなたのプロジェクトを成功に導くヒントが見つかるはずです。 The post 脱・伝言ゲーム！BABOKの知識で顧客の想いをカタチにする方法【飲食店のDX事例】 first appeared on Sqripts .

前回 までは、アウトプットの意義と、日々の仕事を記事にまとめる実践的な方法についてお話ししてきました。ブログで思考を整理し、仕事と発信を1サイクルとして回すところまでお伝えしました。 今回は少し視点を変えます。ブログを書くことに慣れたら、次におすすめしたいのは「別の形でのアウトプット」です。特にここで取り上げたいのは、外部のコミュニティやイベント、カンファレンスでの「登壇」というアウトプットの形です。 記事一覧：【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 なぜ外部の場に出るのか ブログのようなアウトプットは、自分の思考を整理し深める点で非常に効果的です。しかし、外部のイベントでは、それとは違う種類の学びが得られます。 外部イベントには、多様な文脈を持つ人々が集まっています。自分の取り組みや学びを発表・共有すると、そこで独特の化学反応が起きます。 一つは、 他者との対話から生まれるフィードバック です。異なる現場の経験を持つ参加者から意見をもらったり、自分が考えてきたテーマについてディスカッションしたりする中で、思いもよらない視点に出会います。「うちのチームでは当たり前だと思っていたことが、他社では珍しい取り組みだった」と知ったときの驚き。「自分たちが悩んでいることは、どこのチームも同じだった」と気づいたときの安堵感。こうした「自分や自社の相対化」は、外の人との対話があってこそ得られるものです。 もう一つは、 情熱を持つ人からの影響 です。あるテーマに真剣に取り組む人と直接話したとき、自分の向き合い方がガラッと変わる瞬間があります。知識を得たというより、何か火がついたような感覚。これは、テキストを読んだり書いたりするだけでは起きにくい種類の変化です。 内と外をつなぐ学びのスパイラル こうした外部イベントでの化学反応は、単発の刺激で終わるものではありません。ここで起きているのは、もっと構造的なサイクルです。 外でアウトプットし、フィードバックを受け、他の実践者から刺激をもらうことで、自分の中に新たな気づきが生まれます。「もしかしたらこういうアプローチもあるのではないか」という仮説が立ち上がる。「あの人がやっていたことを自分のチームでも試してみたい」という意欲が湧く。これまで見えていなかった角度からの洞察が得られる。 そして、その気づきを持ち帰り、自社の普段の業務で新たな実践を行います。その実践から得られた学びをアウトプットし、再び外部のイベントに出て知見を共有する。そこでまた新たな化学反応が起き、さらなる気づきが生まれる。 つまり、 日々の業務での実践 → アウトプットとして言語化 → 外部での共有と化学反応 → 新たな気づき → 実践に還元 というスパイラルが回り始めるのです。一方通行の情報収集ではなく、内と外を往復することで学びが積み上がっていく構造です。 前回お話しした「仕事と発信を1サイクルにする」という考え方に、外部イベントという新たなフィードバックループが加わることで、学びの循環がさらに広がっていきます。外に出る意味は、情報収集や人脈形成だけではありません。この学びのスパイラルを動かすエンジンを手に入れることにあるのです。 QAエンジニアにとっての身近なカンファレンス ブログで思考を整理することに慣れたら、次のステップとしてぜひ外部の場に参加してみましょう。 QAエンジニアにとって身近なカンファレンスといえば、JaSST（ソフトウェアテストシンポジウム）などがあるかと思います。アジャイル開発の文脈では、全国各地で開催されている「スクラムフェス」もおすすめです（私自身はスクラムフェス仙台の運営に携わっています）。中でも「スクラムフェス新潟」はアジャイルテスティングの色が強く、QAの方には特に相性が良いでしょう。 初めての人にとって、外部の人とコミュニケーションをとるのはハードルが高いものです。そこで役に立つのが、すでにブログなどで書いてきた記事です。「こういうことを書いています」「それ読みました！」と話のきっかけにできますし、相手も事前に読んでくれていれば会話が一気に深まります。外部イベントでのコミュニケーションを円滑にするという意味でも、事前のアウトプットは効果的なのです。 もちろん、育児や介護、地理的な事情などで現地参加が難しい場合もあるでしょう。最近は多くのカンファレンスがオンライン参加の選択肢を用意していますので、まずは自分の状況に合った形で参加してみてください。ただ、先に述べた化学反応の強度という意味では、やはり現地での対話が持つ力は大きいと感じています。 登壇への道筋：LTから始める まずは参加することから始めてみてください。セッションを聞く、他の参加者と話す。外の空気を感じるだけでも、先ほどの化学反応は起きます。そうした場でのアウトプットに興味が湧いてきたなら、次のステップとしてぜひセッションへの登壇を目指してほしいと思います。 大きなカンファレンスで登壇している人は華々しく見えますが、彼らも突然その舞台に現れたわけではありません。日々のアウトプットの積み重ねがあってこそ、その場に立っています。小さなアウトプットを継続する中で「アウトプットの筋力」が少しずつ鍛えられ、やがてより大きな聴衆に自分の知見を届けられるようになっていく。ブログもLTもカンファレンス登壇も、すべて地続きの活動です。 こうした舞台に立つことは、キャリアにおいて大きな意味を持ちますし、自信にもつながります。ですが、いきなり大きな場での登壇を目指すのは現実的ではありません。 そこでおすすめなのが、5分程度の「ライトニングトーク（LT）」から始めてみることです。コミュニティイベントやカンファレンスでLT枠があれば、積極的に応募してみましょう。 登壇のネタは、日々のブログの延長線上にあります。ブログがタスクレベルや日々の業務での「小さな気づき」を書くものだとすれば、登壇テーマはもう少し長い時間軸での学びをまとめるものです。プロジェクト単位や、半期・1年といった期間をかけて取り組んだことと、そこでの学びを共有する。私自身は、半年ほどの業務で得た学びを棚卸しする形でプロポーザルを書き、年に2〜3回登壇するというサイクルで活動していました。ブログで蓄積してきた小さな気づきが、こうした振り返りのときに線としてつながります。 いきなり外部のイベントで登壇するのが難しければ、社内勉強会や朝会でのミニLTなど、身近な場から始めてみるのも良いでしょう。「壇上に立って話す」という経験を、小さな場で少しずつ積み上げていきましょう。 外部イベントは「業務」か「プライベートな活動」か 外部イベントへの参加をめぐって、「これは業務なのか、プライベートな活動なのか」という点で多くの人が悩んでいます。業務と認められるかどうかによって、勤務時間内に参加できるか、費用を会社が負担するかが変わってくるからです。事実として、私がカンファレンスで会った参加者の多くは、有給休暇を取り、自費で参加していました。 私の考えはシンプルで、これは「業務」だと捉えています。前回・前々回でお伝えしたように、アウトプットは学びと成長のための営みであり、仕事と地続きのものです。外部イベントへの参加や登壇もその延長線上にある活動です。確かに短期的には通常の業務が止まるためコストに見えますが、変化の速い時代において継続的に学び続けることは、私たちの仕事の本質そのものではないでしょうか。 もちろん、現時点ではそのように位置づけられていない組織の方が多いのが現実です。だからこそ、組織としてこうした場への参加や登壇を後押しする仕組みが必要になります。具体的にどのような制度や文化があれば「個人の根性論」にならずに済むのかについては、次回の最終回で詳しくお話しします。ここでは、外部イベントへの関わり方のグラデーションを整理しておきましょう。 関わり方のグラデーション 外部イベントへの関わり方には、コミットメントの深さに応じたさまざまな形があります。どの関わり方が優れているということではなく、自分の状況や目的に合ったものを選べるのが理想です。 参加者として聴く ：チケットを購入してセッションを聴く、インプットに徹する形です。 積極的に交流する ：他の参加者と話をしたり、ライトニングトーク（LT）をしたりする関わり方です。 登壇者として知見を共有する ：しっかりと準備をしてセッションのプロポーザルを出し、登壇します。参加者たちに知見を共有することで貢献する形です。 協賛（スポンサー）として支援する ：少し経路は違いますが、協賛を通じて間接的に学びを支援することも良い方法です。協賛することでブースの出展やスポンサーチケットが得られるため、複数人のメンバーを参加させることができます。 運営スタッフとして貢献する ：通常参加や登壇とはまた異なる種類の学びが得られます。コミュニティや組織の運営を通じて得た知見は、社内でのチーム運営や組織づくりにも活きてくるため、個人的には非常におすすめです。本連載の本筋からは外れるため詳しくは触れませんが、興味のある方はぜひ一度試してみてください。（参考： スクラムマスター往復書簡 第6回：スクラムマスターにとってなぜコミュニティ活動は重要なのか ） 私自身のマネージャー時代の経験として特におすすめなのは、協賛して数枚の参加枠を確保した上で、「アウトプットに興味はあるけれどイベントにあまり参加したことがない」というメンバーを誘い、2、3人で一緒に参加するという方法です。一人では踏み出しにくいハードルを下げられるというだけでなく、同じ体験を共有することで、イベント後に「あのセッション良かったね」「自分たちでもやってみよう」という会話がチーム内に生まれやすくなります。外の刺激を、そのままチームの中に持ち込めるのです。 この学びのスパイラルが組織全体に広がっていくためには、個人の意欲だけに頼らない仕組みが必要です。次回の最終回では、内と外を往復するこの学びの循環を「個人の根性論」にせず、組織としてどう支えていくかについて考えます。 【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 The post 【第3回】登壇はゴールじゃない：社内実践に効く「外とのつなぎ方」 first appeared on Sqripts .

様々な専門性を掛け合わせて「自分だけのQAエンジニアの土台を作る」という趣旨で続けてきた本連載も、とうとう最終回を迎えました。 今回はまとめとして、「それぞれのQAエンジニア像」を作ることについて総括したいと思います。 私は最近、ポジティブな意味でもネガティブな意味でも「あなたはQAエンジニアっぽくないね」と言われることが増えました。一方、自分としては「QAエンジニアのど真ん中」を歩んでいるという気持ちでいます。 正直、この言葉には少し複雑な気持ちを抱くこともあります。 この問いに対する私なりの答えについては、本稿の終わりでお話しするとして、まずは私が土台にしていきたい技術について、今後の展望についてお伝えしたいと思います。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む 【最終回】自分なりのQAエンジニア像を組み立てよう これから土台にしていきたい技術 私はこれからもソフトウェアテストについて深く学んでいきたいですし、もちろんソフトウェアエンジニアリングについても学び続けるつもりです。 ただ、それ以外にも習得したいと思っている技術や領域があります。 そちらをいくつか紹介いたします。 関係や組織に働きかける技術 今、私は「システムコーチング®」を学んでいます。 これは、個人ではなく、チームや組織全体を一つの「システム」として捉え、その関係性にアプローチするコーチング手法です。 実は、私が個人向けのコーチングを学び始めたのも、最終的にこのシステムコーチング®に繋げたいという思いがあったからです。 以前より言及していますが、私は「プロセス品質」を非常に重要だと考えています。 そしてそこには「関係性の質」や「対立をどう扱うか」などが重要になってくると考えています。 これらを生産的なエネルギーに変え、うまく扱うためのための再現可能な技術として実践するにあたり、システムコーチング®をはじめとしたさまざまな介入の手法を学んでいる最中です。 システム思考   関係性や情緒といったウェットなものだけでなく、もう少しハードなものの見方も鍛えたいと思っています。 そこで見つけた技術のひとつが「システム思考」です。 ソフトウェア開発の現場を見ていると、今まで特定の因果関係で成り立っていると思っていたものが、実は「外部」あるいは「見えていなかったもの」にあるより大きな要因から影響を受けていることに気づかされます。そうした現実において、対象を「システム」「境界」「外部」として捉え、より俯瞰して物事を見るアプローチもできるようになりたいと思っています。 倫理観・哲学的思考 本連載のテーマでも何度か触れたように、私自身は物事の本質を考える哲学的な思考や、倫理観を持つことがとても重要だと考えています。 まさに今で言えば、生成AIの登場により哲学や倫理が注目されているとよく聞きますよね。 今後、私たちには、生成AIを超えるような、さらに人間性を揺さぶるテクノロジーや問いが投げかけられるでしょう。 だからこそ、私は今後も倫理的な視点や哲学的な思考力をしっかりと育て、自分自身の確たる土台（自己基盤）として育てていきたいと思っています。 技術の組み合わせ これら新しく学ぶ領域が、今後どのように組み合わさっていくのか、これには見立てがあります。 ただ、私自身は、私の想像を超えるような何かが生まれるとも思っています。そしてそれにワクワクしています。 なぜなら、本連載で扱った技術の組み合わせのほとんどは、私の当初の見立てを超えたものだったからです。 かつて何かを学び始めた私は、様々な先輩や周囲の人から「そんなことを勉強しても無駄だよ」と言われることがありました。もしかしたら、私自身も過去、誰かに対してそう言ってしまったことがあったかもしれません。 しかし今では、「その経験や技術、学んだことが無駄になるかどうか」は、「学ぶ対象」や「自分が何をしているか」によって決まるものではないと考えています。 点と点を繋ぐ（Connecting the dots）  「Connecting the dots」という考え方があります。これはスティーブ・ジョブズの有名なスピーチに登場する言葉で、バラバラに学んだ「点」が、後になって思いがけず「線」として繋がるという考え方です。 私の知っているQAエンジニアには、さまざまな背景を持っている人がいます。傍からみて、一貫性がなくパッチワークのように見えることがあるでしょう。 私はそこにこそ「私らしさ」「あなたらしさ」「あの人らしさ」が宿るのだと考えています。 私はそこに、自分の人生に起こるすべてのことを必然として肯定する、ニーチェの「運命愛」のようなものを感じずにはいられません。 ブリコラージュ   「ブリコラージュ」という考え方があります。一見無関係に見える複数の分野の知識や概念を寄せ集め、自分の中で新しい価値や意味を作り出すことです。 第一話では「T型人材」という言葉を紹介しました。今でもその大切さは感じています。 一方で、ブリコラージュのように、むしろ様々な専門性を繋げ、自分なりに意味づけして捉えることが、執筆当初に私自身が本当に「大切だ」と伝えたかったことなのだと、今になって気がつきました。 あなたなりのQAエンジニア像を組み立てよう ジュニアの方を支援する中で、「これを学ぶべきでしょうか？」と質問をもらうことがあります。そんな時、私は照れや恐れの気持ちから少しはぐらかして答えることもあるのですが、この記事でははっきりと伝えたいと思います。 「あなたが学びたいと思ったことを、全力で学べば良い。そして、それらをあなたの中で繋げていけば良い」 と。 この連載は、「QAエンジニアの土台」というテーマで進めてきました。 連載を始めた当初、私は「QAエンジニア」という言葉に強い誇りを持っていましたし、その気持ちは今も変わりません。 ですが、冒頭の「あなたはQAエンジニアではない」という言葉に対する答えとして、「QAエンジニアという肩書きを無理に使う必要はない」とも考えるようになりました。 私が「営業」から「テストエンジニア」「QAエンジニア」、そして「コーチ」になったように。 実は今の私は自分の専門性を上記のどれでもない言葉で表現しています。 「System Fixer」 です。 これを聞いて「さすがだ」という人もいれば、「いい歳してイタい奴だ」という人もいます。正直、他者からの評価や冷笑を気にしている自分も否定できません。 一方で、パッチワークのように紡がれた土台を通じて、「自分らしさ」がどこにあるのかを探求し、見つけることの尊さも深く感じるようになりました。 これは、コーチングを通して他者と深く関わることで気づくことができた、「人生の美しさ」だと考えています。 私は、自分自身の中に強くこびりつく「既存のどのような属性・ラベルを持っているか」というこだわりを一度横に置いて、新たなチャレンジを進めている最中にいます。 他者からの評価、そして冷笑。 これは私が、私自身に向けているものでもありました。 これを自覚したときに感じた重要な学びがあります。 「自分が抱いている問題意識や興味・チャレンジしたい気持ちから目を背けないことの価値」 そして、「自分らしさを発揮して何かを学び、そして繋げていくことの価値」です。 この連載を最後まで読んでくださった皆様、本当にありがとうございました。 もし、この先「自分なりのQAエンジニア像」が生まれたなら、ぜひどこかで私に教えてください。 あなたのQAエンジニア像を見られる日を、私は心から楽しみにしています。 ※「システムコーチング®」は、CRR GlobalおよびCRR Global Japanが所有する登録商標です 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む 【最終回】自分なりのQAエンジニア像を組み立てよう The post 【最終回】自分なりのQAエンジニア像を組み立てよう first appeared on Sqripts .

前回は、アウトプットがなぜ「強力な学習手段」なのかについてお話ししました。アウトプットをゴールではなく「インクリメント」として捉え、リズムを決めて始めることが大切だ、というところまで整理しました。 今回は「では、具体的に何をどう書けばいいのか」という話に踏み込みます。 記事一覧：【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 「何を書いたらいいか分からない」問題 アウトプットの意義は理解できた。リズムを作ろう。そう思ったものの、いざ書こうとすると手が止まる。多くの人がぶち当たるのが「何を書いたらよいかわからない」という壁です。 エンジニアブログのようなコンテンツでは、以下の3点を基本構成として意識するのがおすすめです。 目的 ：解決したいイシューや背景 実際に取り組んだこと ：起きたことなどの生の体験、一次情報 そこから得られた学び ：分かったことや教訓 この「目的・取り組み・学び」の3点セットを型として持っておくと、書くべきことが自然と見えてきます。 この構造は、研究論文の報告形式であるIMRaDや、軍発祥の振り返り手法「After Action Review」にも通じるものがあります。学術の世界でも実務の世界でも、「伝わり、再利用される知識の形」として効果が認められてきた構造です。 一次情報の価値 ここで強調しておきたいのが、一次情報としての具体的な体験の価値です。 個別具体のケーススタディや取り組みなど、実際に手を動かした生の体験そのものに大きな価値があります。しかし、これを抽象化・一般化すると、どこかで見たことのある情報になっていきます。著名人や書籍がすでに語っている内容と大差がなくなり、「自分が書く意味」が薄れてしまいます。 今の時代、一般的な知識や情報はAIに聞けば手に入ります。書籍の要約も、技術的な概念の解説も、AIが十分にカバーできるようになりました。しかし、個別具体のケーススタディはあなただからこそ書ける情報です。具体的であるからこそ、読者が自分の状況と照らし合わせて参考にできるリアリティがそこにはあります。 だからこそ、まずは自分が実際に経験したことをそのまま書く、ということを意識してください。 ただし、実際に行ったことを時系列に並べるだけでは不十分です。何のためにそれをやったのか、どのような結果になり、どんな学びが得られたのかという情報がなければ、読者にとって価値のある記事にはなりません。先ほどの型（目的・取り組み・学び）を意識しましょう。 仕事と発信を「1サイクル」にする この「型」を、日々の業務やプロジェクトなどの区切りの良い単位で実践してみてください。仕事が一段落したら、その概要や取り組み、学びを振り返る形でブログ記事にまとめる。この一連の流れを「仕事の1サイクル」として捉えることから始めてみましょう。 仕事と発信をセットで捉えるようにすると、アウトプット駆動で仕事に取り組む意識が芽生えてきます。常に読み手・聞き手を意識し、自分の活動の意義や狙いを言語化しようとすることは、発信の質を高めるだけでなく、日々の何気ない業務の中に新たな気づきをもたらします。「これ、どう説明するんだろう」と考える習慣が、仕事そのものを深める。これが、発信と実践を循環させることの本質的な価値だと思います。 私自身の経験を二つ紹介します。 一つ目は、スクラムマスターとして参加していたチームでの話です。レトロスペクティブ（振り返り）で議論している中で、チームとして重要な気づきが得られることがありました。「この学びは社外にも共有できるのではないか」というアイデアが自然と生まれ、次のスプリントのアクションアイテムとして「気づきをブログにまとめて発信する」というアクションにつながったこともあります。 二つ目は、マネージャーとしてスクラムマスターのメンバーと日々の1on1をしていたときのことです。最近の取り組みや悩み、そこからの学びを聞く中で、「これは他の人にとっても参考になりそうだ」と思ったものについては、「アウトプットしてみませんか？」と提案するようにしていました。 また、あるチームではスプリントの最終日を「アウトプットデー」と定め、スプリントレビューでのデモ準備と並行して、そのスプリントでの学びをブログ記事としてまとめるという活動を行っていました。 このように、日々の業務の一部としてアウトプットを組み込んでいくのがおすすめです。アウトプットによる自己変容は、筋トレに近いところがあります。1回やれば恒久的に変わるものではなく、適切な強度の取り組みを定期的に繰り返すことで、少しずつ鍛えられていくものです。だからこそ、仕組みを整え、一度きりではなく継続的な営みとして回していくことが大切です。 フィードバックを活用する 書き上げたら、一人で抱え込まず、積極的に他者からフィードバックをもらいにいきましょう。 他者によるレビュー は、最も直接的な方法です。上司や同僚に実際に読んでもらい、違和感のある表現や、解釈がぶれるような点を指摘してもらいます。他者がどのように解釈するのかという情報は貴重ですし、フィードバックを受けてブラッシュアップすることで、記事の質が高まり、自身の学びもより豊かなものになります。 生成AIの活用 もぜひ検討してみてください。私自身、執筆活動全体でAIをフル活用していますが、おすすめの使い方は大きく3つあります。 まず 執筆前の壁打ち です。書きたいネタは断片的に頭の中にあるものなので、「こんな記事を書きたいのだけど、対象読者と持ち帰れる学び、骨格となる論点の整理を手伝ってほしい」とAIに相談し、アウトラインを整えていきます。 次に 執筆中のペアライティング です。AIエディタを使い、ペアプログラミングのような感覚で一緒に書き進めます。コツは、AIをただの作業者ではなく、有能な同僚のように扱うことです。例えば、「このセクションは冗長だから削除して」とただ指示するのではなく、「このセクションは冗長に感じるのだけど、どう思う？」と聞く。するとAIは文章全体を踏まえて「このセクションには構成上こういう役割があるので、簡略化した上で位置を調整するのがよいのでは」と提案してくれたりします。 そして 書き上げた後のレビュー です。まず論点としての大きな穴や全体の整合性をチェックしてもらい、全体の構造を整えてから日本語のブラッシュアップに入る、という順序がおすすめです。 ただし、執筆そのものをAIに任せるのはおすすめしません。前回触れた通り、構成を考え、言葉を選ぶプロセスそのものが学びの核です。あくまで自分で書き、AIは壁打ちとレビューのパートナーとして活用するのがよいバランスだと思います。 「マサカリ」への備え方 フィードバックを経て公開する際、「ツッコミが怖い」という懸念もあるかと思います。私自身も昔は、不用意な記述によっていわゆる「マサカリ」が飛んできて苦い思いをしたことが何度もあります。 ツッコミが入りにくい発信の仕方を身につけることが大切です。これについては「 防御力の高い技術ブログを書こう 」という記事が非常に参考になりますので、ぜひご一読ください。 私が個人的に意識しているのはシンプルで、 読み手の感情的な反射を引き起こさないよう配慮する ということです。具体的には以下の2点です。 事実と解釈を明確に区別する 特定の人・組織・ツールを名指しで批判するような表現を避ける メリット・デメリットの比較が必要な場合は事実として淡々と行い、感情的な反応を引き起こしやすい表現を控える。読み手が最後まで冷静に読めるよう整えることが、アウトプットをする上での誠実さではないでしょうか。 まとめ 書き方の型を持ち、フィードバックを取り入れながら続けていく。それだけで、アウトプットは確実に仕事の質を底上げしていきます。 ここまで2回にわたって、アウトプットの意義と実践的な書き方についてお伝えしてきました。次回は少し視点を変えます。テキストのアウトプットに慣れてきたら、次は「外の世界」に出てみましょう。コミュニティやカンファレンスでの登壇・発表も、アウトプットの一形態です。そこで得られるフィードバックの質と量は、ブログとはまた異なります。外に出ることで検査と適応のサイクルがどう広がるのか、次回お話しします。 【連載】社内外を往復するアジャイルQAの育ち方 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す ［全文公開中］ 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 The post 【第2回】社内の仕事が記事になる瞬間：実践知を言語化する型と習慣 first appeared on Sqripts .

QAエンジニアの採用・選考　どう採るどう通る？連載の第5回、今回が最終回となります。 第2回・第3回では求職者側の視点、 前回(第4回) からは募集側の視点に切り替えて、QAについて何を理解すべきか、理解を深めるための具体的なアクションについて解説しました。 しかし、QAを理解し、良い募集文面を作ることができたとしても、その募集がQAエンジニアの目に触れなければ応募にはつながりません。連載の最終回となる今回のテーマは「認知」です。 採用における認知の重要性は、さまざまな調査データからも裏付けられています。 talentbook社が2024年に実施した調査 では、採用施策において「応募者認知」に課題を感じている企業が中堅企業で78.2%、大企業で70.3%にのぼりました。また、 markeTrans社の調査 では、企業名を事前に認知している人の9割が業務内容の理解まで進んでいるという結果が出ています。年代が上がるにつれて事前認知の比率が高くなる傾向もあり、中途採用においては事前認知がアドバンテージになり得ることが示唆されています。 本記事では、QAコミュニティの中で自社の認知を獲得するための具体的な手段についてご紹介します。前回の「理解する（インプット）」に続く、「知ってもらう（アウトプット）」のフェーズとしてお読みいただければ幸いです。 記事一覧：QAエンジニアの採用・選考［どう採る　どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える なぜ「認知」が必要なのか QAエンジニアは元々の母数が少なく、多くの企業が採用を競い合っている状況です。そうした中で、求人を出して待っているだけでは、QAエンジニアの選択肢にすら入ることが難しくなっています。 ここでいう「認知」とは、単なる企業の知名度のことではありません。QA採用における認知とは、「この会社は品質に対する取り組みをしている」「QAに対する理解がありそうだ」といった、品質への姿勢が伝わっている状態を指しています。 では、どの程度の認知を目指すべきなのでしょうか。いきなり「この会社で働きたい」と思ってもらうことを期待するのは、とくにまだQAエンジニアがいない企業の場合は現実的ではありません。まずは「社名を聞いたことがある」、できれば「あの会社は品質に力を入れているらしい」「QAとしてどんなことが求められそうか、なんとなく想像がつく」くらいのレベルを目指すのが妥当だと考えています。 私自身の体験として、事業会社に転職した後に外部のイベントに参加したり登壇したりしていたところ、「QAがいたんですね！」「募集してたんですね！」「御社の人をあまり外でお見かけしないので」と言われたことがありました。裏を返せば、それまではQAコミュニティの中で社名が認知されていなかったということです。外に出て顔を見せるようになってから、少しずつ「あの会社にはQAがいる」ということが広まっていった実感があります。即効性があるわけではありませんが、じわじわと効いてくるものだと感じています。 QAコミュニティでの認知を獲得する手段 ここからは、QAコミュニティの中で自社の認知を獲得するための具体的な手段をご紹介します。 スカウト・ダイレクトリクルーティング——「攻め」の認知 ビズリーチやFindyなどの媒体を通じてスカウト等を送ることは、応募を獲得するための手段として広く知られています。しかし、スカウトにはもう一つの側面があります。それは「認知を獲得する手段」としての効果です。 いちエンジニアの立場で正直なところを言うと、スカウトに返事をしないことは多いです。（転職するつもりがない場合は特に。）しかし、メールに含まれる文面は読んではいますし、社名も頭に残っています。「あの会社、QA採用してるんだな」という印象が積み重なることで、いざ転職を考えたときに選択肢に入る可能性が生まれます。 ただし、ここには大きな注意点があります。テンプレ感の強いスカウトや、まったく関係のないロールでの「いいね」は逆効果です。一方で、自分のこれまでのアウトプットを見てくれていたり、得意領域を踏まえたうえでの打診であれば、たとえ応募に至らなかったとしても印象は良いです。 面白いのは、経歴について具体的に言及されていてもテンプレ的に感じる文章もあれば、短くてもこちらのことを理解してくれていると感じるスカウトもある、ということです。この違いは言語化が難しい、感覚的な部分ではありますが、候補者側には良くも悪くも伝わっています。 これは前回の記事で述べた「QAを理解すること」と直接つながっています。QAという職種やその人のキャリアに対する理解が浅いままスカウトを送ると、それは候補者に見抜かれてしまいます。理解に裏打ちされたスカウトであればこそ、返事がなくても良い認知につながるのだと思います。 SNS・技術ブログでの発信——「蓄積する」認知 DevRelやHRのSNSアカウントが活発で、タイムラインでよく見かける企業は、それだけで認知につながります。「あの会社、よく発信しているな」という印象は、採用において意外と大きな力を持っています。 「でもうちにはまだQAエンジニアがいないので、QAに関する発信ができない」と感じる方もいるかもしれません。しかし、QAがいない段階でもできる発信はあります。 たとえば、開発組織のトップ（CTOやVPoEなど）の名前で、品質に対する課題意識や今後の方針を発信するという方法があります。これはQAエンジニアにとって「この会社は品質に対して経営層レベルで意識を持っている」「入社したときに後ろ盾がありそうだ」というメッセージになります。QAとして入社するにあたって、経営層の理解と後押しがあるかどうかは非常に重要なポイントです。 また、開発者がテストに関する取り組みを発信することも効果的です。テスト自動化の導入、品質改善の施策、テスト設計の工夫など、QAエンジニアがいなくても開発者自身が品質に向き合っている姿を見せることができます。QAエンジニアから見て、「品質に対して何もしていない会社」と「QAはまだいないけれど、開発者が自分たちでテストに取り組んでいる会社」では印象が大きく異なります。後者のほうが入社後のイメージも湧きやすいです。 大切なのは、「品質に課題があります」という発信だけでなく、「今、こういうことに取り組んでいます」という部分も含めることです。課題の認識が適切にできていること自体がアピールになりますし、取り組みの内容を伝えることで「この会社は本気で品質に向き合おうとしている」という印象を与えることができます。 このほか、QA系のイベントに参加した後に感想ブログを書くのも有効な方法です。学びの姿勢を示しつつ、発信もできるという一石二鳥のアクションと言えます。 イベントへの参加・スポンサー——「存在感を示す」認知 JaSSTなどQA系イベントのスポンサーになっている企業を見ると、「この会社は品質に力を入れているんだな」という印象を持ちます。スポンサーは認知獲得の有力な手段の一つです。 とはいえ、いきなりスポンサーになるのはハードルが高い場合もあると思います。まずはイベントに参加して、QAコミュニティの空気感を知ることから始めるのも良い方法です。前回の記事でも「学びの姿勢で」と述べましたが、認知獲得においても同じスタンスが大切です。 懇親会への参加も、QAエンジニアとの自然な接点を作る機会になります。ただし、注意すべきなのは「採用目的で懇親会に来ている」「採用目的の声がけをたくさんしている」とならないようにすることです。これらは候補者であるエンジニアの間で印象が悪くなってしまうので、あくまでも交流や、QAコミュニティの空気感を知るためのスタンスを守ることが重要です。 また、開発者やDevRelの方がイベントに参加し、その感想をブログに書くというのも認知獲得につながります。「うちの会社の人がQA系イベントに関心を持っている」ということ自体が、QAコミュニティに対するメッセージになるからです。 合同ミートアップの開催——「双方向」の認知 最近では、複数社（3〜4社程度）が合同でミートアップを開催するケースも見られます。各社からのLTやパネルディスカッションを通じて取り組みを紹介し、参加者に「面白そうだな」「この会社で働いてみたいな」と感じてもらうことを狙ったイベントです。 ただし、この手段には難しさもあると感じています。採用目的を前面に出してしまうと、参加すること自体が転職意思の表明のように見えてしまい、エンジニア側からすると気軽に参加しづらくなります。一方で、あくまでも技術イベントというスタンスで開催すると、エンジニア側は気軽に参加できる反面、採用のためのアピールがしづらくなる可能性があります。このように、開催側の意図と建前と、参加者側の思いとが、噛み合いきらない部分があるように見受けられます。 認知獲得の手段の一つとして選択肢に入れておく価値はありますが、設計の難しさは認識しておいたほうが良いでしょう。 QAがまだいない企業の場合 ここまでご紹介した手段の中には、QAエンジニアがまだ社内にいない企業にとってはハードルが高く感じるものもあるかもしれません。 そうした場合は、 前回の記事 でご紹介した「副業QA」の活用が、認知獲得の土台を作る手助けになります。副業QAが社内にいることで発信の内容に説得力が増しますし、イベント参加やスカウト文面の作成においても、QAの専門家の視点を取り入れることができます。 まずは小さく始めて、少しずつQAコミュニティの中での認知を広げていくことが大切です。 連載のまとめ 本記事では、QAコミュニティの中で自社の認知を獲得するための手段として、スカウト・ダイレクトリクルーティング、SNS・技術ブログでの発信、イベントへの参加・スポンサーなどをご紹介しました。それぞれの手段にはそれぞれの特性がありますが、共通して重要なのは、前回お伝えした「QAを理解すること」が前提になっているという点です。理解が浅いままの発信やスカウトは、候補者には伝わってしまいます。 また本連載では、全5回にわたってQAエンジニアの採用について、求職者側・募集側の双方の課題を取り上げてきました。連載を通じて一貫してお伝えしたかったのは、採用活動を「なんとなく」や「他職種と同じように」進めてしまうと、うまくいかないことが多い、ということです。 求職者であれば、募集側がどんな背景でどんなQA像を求めているのかを理解し、それを踏まえてアピールすること。募集側であれば、QAという職種の幅広さや文化を理解し、その理解をもとに認知を獲得していくこと。どちらの立場であっても、相手の行動原理や思いを理解し、汲み取ったうえで行動することが大切です。 この「理解」こそが、QA採用を成功に近づける鍵ではないかと考えています。本連載が、QAエンジニアの採用に関わるすべての方にとって、何かしらのヒントになれば幸いです。 【連載】QAエンジニアの採用・選考［どう採る どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える The post 【最終回】募集側の課題2：QAの中での認知を獲得する first appeared on Sqripts .

こんにちは。QAエンジニアのなおたです。 日々ソフトウェア品質と向き合っている若手エンジニアの皆さん。昨今、「生成AI」という言葉を聞かない日はないでしょう。 先日、生成AI本のベストセラー 『 生成AIで世界はこう変わる 』 （今井翔太著／SB Creative）を読んでみました。想像を超える速度でAIのインパクトは社会全体に及んでいますが、私たちソフトウェア開発の現場、特に「ソフトウェアテスト」の領域は、今まさに変革期の入り口に立っていると感じました。 「AIがテストケースを自動で作ってくれるなら、エンジニアの仕事はなくなるのでは？」 そんな不安や疑問を感じている方も少なくないかもしれません。 しかし、結論から言えば、仕事は「なくなりません」。 ただし、その「質」は根本から変わります。本ブログでは、生成AIがソフトウェアテストをどう変革し、私たちエンジニア、特に若手エンジニアの方々が今後どのようなスキルを身につけるべきか、考察していきます。 なぜ今、ソフトウェアテストが「変革期」なのか IPA（情報処理推進機構）が示すように、ソフトウェアテストは開発プロセスにおいて「品質の作り込み」と「品質の確認」を担う、極めて重要な工程です。（参考: IPA ソフトウェアテスト） ※1 従来の開発（例えばV字モデル）において、テスト工程は多くの工数とコストを要する領域でした。テスト設計の属人性、テストケースの網羅性の担保、膨大なリグレッションテストの工数確保等 これらは、多くのプロジェクトが抱える共通の課題です。 まさに今、この領域に、生成AIがメスを入れようとしています。 生成AIが可能にすること（例）： テストケースの自動生成: 仕様書（自然言語）を読み込ませ、境界値や同値分割を考慮したテストケースを瞬時に生成する。 テストデータの多様化: 正常系だけでなく、異常系やエッジケースのテストデータを大量に生成する。 テストコードの自動記述: E2Eテストや単体テストのコード（例: Selenium, JUnit）を生成・修正する。 バグ報告の初期分析: ログやエラーメッセージをAIが分析し、原因のあたりをつけたり、バグ報告書を自動起票したりする。 リグレッションテストの最適化: コードの変更箇所を解析し、影響範囲を特定。実行すべきテストケースを最小限に絞り込む。 これらが実用レベルになれば、テストにかかる工数や時間は劇的に減少するでしょう。もはや「テストは作業工数で頑張るもの」という時代は終わりを告げ、 生成AIの活用を前提とした新しいテストプロセス が主流になる。これが、私たちが「変革期」と呼ぶ理由です。 ※1 IPA 独立行政法人 情報処理推進機構 新しい視点：AI時代に「本当に」求められるスキルとは？ 視点を変えてみましょう。テスト作業の多くをAIが担うようになったら、エンジニアの価値はどこにあるのでしょうか？ ここで、一つの重要な視点があります。それは、 「生成AIを活用するためには、基礎的なビジネスリテラシーが、むしろ以前より重要になる」という逆説的な事実です。 生成AIは「万能の魔法」ではありません。AIは「指示されたこと」しかできません。 そして、その指示が曖昧で不明確であれば、AIが生み出すアウトプット（テストケースやコード）もまた、曖昧で使い物にならないものになります。 つまり、私たちが獲得すべき新しい知的スキルとは、以下の3つに集約されます。 1. 高度な「仕様読解力」と「要件定義能力」 AIに的確なテストケースを生成させるためには、 エンジニア自身が、その機能の「要件」と「仕様」を完璧に理解している 必要があります。 「この機能の目的は何か？明示的、暗示的な意味は何か？」 「ユーザーにとっての本当の価値はどこにあるのか？」 「仕様書のこの一文の『行間』に隠された暗黙の前提条件はどこにあるのか？」 要件を深く理解し、AIが解釈できる明確な言葉（プロンプト）に落とし込む能力。 これこそが、AI時代のテストエンジニアに求められるメインスキルです。 曖昧なテスト仕様書を渡されて「あとはAIさん、よろしく」は成立しません。 AIを使いこなす前提として、人間の本質的な能力と知見、深い洞察力が問われるのです。 2. 「論理的思考」に基づくテスト設計能力 AIが何千ものテストケースを生成したとして、その妥当性を誰が判断するのでしょうか？ 「網羅性、カバレッジは十分か？」 「重要な観点（セキュリティ、パフォーマンス、ユーザビリティ）が抜けていないか？」 「AIが“見落としているケースはないか？将来の潜在リスクはないか？」 これらを判断するには、基本仕様の理解やテスト設計の原理原則（同値分割、境界値分析、状態遷移など）を深く理解した上での「論理的な思考力」が不可欠です。 AIは「作業」自体は高速化しますが、「基本設計の思想」や「品質保証」を担保してくれるわけではありません。AIの出力を鵜呑みにせず、クリティカルに評価し、テスト戦略全体を設計する「知的アーキテクチャ」としての役割が重要になります。 3. 基礎的な「読み書き能力」 ここでいう「読み書き能力」とは、言語化力そのものです。 書く力: AIへの的確な指示（プロンプトエンジニアリング）、ステークホルダー（開発者、PM）への明瞭なバグ報告、AIが生成したドキュメントの校正。 読む力: 膨大な仕様書の本質を掴む読解力、AIの生成物を迅速にレビューする能力。 結局のところ、私たちの仕事は「言葉」で成り立っています。AIという新しい”仲間”と正確にコミュニケーションを取り、プロジェクトを円滑に進めるための「読み書き能力」の重要性は、かつてないほど高まっていると考えます。 まとめ：変革を乗りこなし、新しい価値を生み出すAIテストエンジニアへ 生成AIの登場により、「ソフトウェア産業」全体が抜本的に変わることは間違いありません。特に、ソフトウェアテストの現場は、その影響を最も強く受ける領域の一つです。 テストエンジニアの役割は、「手を動かしてテストを実行する人」から、「AIを駆使して、品質レベルをどのように高めて、どう保証するかを設計・判断・評価する人」へとシフトしていくでしょう。 こうした変革の中で、実際のテスト現場でも新しいAI駆動型のソリューションが登場し始めています。 例えば、AGESTが展開する次世代AIテストツール『TFACT』のように、生成AIの力をテストの標準プロセスに組み込んだAIプラットフォームもその一つです。 ■AGEST AIテスト管理ツール ｜ TFACT 自律走行型AIソリューションは、私たちのテストプロセスを劇的に効率化してくれる強力なパートナーとなり得ます。 そして、AIに意図通りのテストを行わせるためには、曖昧さを排除し、「正確な言葉」で表現する力が不可欠です。ツールが進化すればするほど、そのツールを指揮する人間の「言語化能力」や「論理的思考」の価値はむしろ高まるのです。 若手エンジニアへのエール 若手エンジニアの皆さんにとって、この変革は「脅威」ではなく、むしろ「チャンス」です。なぜなら、ベテランエンジニアが長年の経験で培ってきた「経験」や「勘」の一部をAIが補完し、若手エンジニアは新しい発想とAIツールで勝負できるからなのです。 今、身につけるべきは、特定のツール操作ではなく、 1. 仕様を深く読み解く力。 2. 物事を論理的に考える力。 3. 要件を深く理解し正確な言葉で表現しATに的確なプロンプトを定義できる力。 という、極めて「基礎的」で「普遍的」なスキルです。 このAI変革の波を恐れず、AIという強力な仲間を使いこなし、ソフトウェアの品質を支えるプロフェッショナルとして、共に未来に向けて成長していきましょう。 プロフィール： QAエンジニアなおた 前世紀は主に大手携帯通信事業者の海外（米国・英国・インド）新規事業開発マネジャーとして従事。 今世紀は、主に自動車向けコネクテッドカーの企画コンサルティング、開発実務の支援、実装テスト関連のPMを経験。近年は幅広い企業クライアント向けQAコンサルタントとして活動中。 The post 生成AIはソフトウェアテストを”破壊”するのか？ ー 若手エンジニアが備えるべき「変革」と「新しいスキル」 first appeared on Sqripts .