キャッチ。 伊藤さん、バトンを受け取りました。 冷房の効いた室内と近年とりわけ気候変動によって過熱している屋外とで、寒暖差の激しい日々が続いておりますが、いかがお過ごしでしょうか。 ノーコードテストツールのバトンは画鋲付きで渡した気分でした。 しかし、誠実に答えてくださり、ありがとうございました。 テスト自動化は運用が大切、というのは私自身、伊藤さんから繰り返し学んでいたことでしたね。 そして、ノーコードかコードベースかといった軸とは全く違うパラダイムの進化というのは大変示唆的です。 そもそも生成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 .

こんにちは！セーフィーでQAエンジニアをしている福山です。 「シフトレフト」という言葉を本気で実践しようとしたとき、私は思わぬ落とし穴にハマりました。 それは、上流工程に出ていくほど 「品質の言葉」だけでは仲間になれず、むしろ“後から検証しに来るブレーキ役”に見えてしまう ことがある、ということです。 この記事では、一般社団法人UXインテリジェンス協会が提供するUX検定の学習を通じてデザイナーとの「共通言語」を少しずつ獲得し、上流での対話が回り始めた経験を共有します。 🎯 この記事は以下のような方に向けた内容です シフトレフト推進で、他部署との対話が噛み合わないと感じるQAエンジニ

こんにちは、プロダクト部 部長の稲垣です。（自己紹介やこれまでのキャリアについて↓をご覧ください。） tech-blog.rakus.co.jp 今回は、私が作った「PdMタイプ診断」という取り組みについてご紹介します。 この診断は、既存の性格診断をそのまま用いたものではなく、 PdMとしての思考や行動の傾向を整理するために、認知スタイルに関する考え方をヒントに独自に設計したもの です。 診断の仕組みと、ラクスの開発組織で実施して見えてきたことをレポートします。 なぜ作ったのか 診断の仕組み：3つの軸、8つのタイプ 軸① コミュニケーション 軸② 価値の方向性 軸③ 志向性 ラクス社内で試してみた 開発組織全体の傾向：「Logic × UX × Discovery」が最多 プロダクト部の特徴：「Discovery」が際立って高く、2つのタイプが拮抗 この結果をどう受け取るか まとめ おわりに なぜ作ったのか きっかけは、小さな課題感からでした。 PdMのイベントや社外の方と話すとき、「どんなPdMですか？」という問いにうまく答えるのが難しいと感じることがありました。 職種名だけでは伝わらないですし、スキルセットを並べても、その人らしさまではなかなか見えてきません。 もう一つ感じていたのが、チームづくりの場面で、 このメンバーはどんな場面で力を発揮しやすいのか を共通言語で話しにくいことでした。 もちろん、人の適性や可能性は診断だけで決まるものではありません。 ただ、対話のきっかけになる整理軸があるだけでも、お互いの理解は進めやすくなります。 そこで、PdMとしての思考・行動スタイルを3つの軸で整理し、8つのタイプに分類する診断を作ってみました。 初対面のPdM同士で話すきっかけにしたり、チーム内で自分や他者の強みを言語化したりするための、 参考情報の一つ として使えることを期待しています。また今回の整理にあたっては、設問やタイプ説明のたたき台を考える過程で、生成AIも補助的に活用しました。 人が考えるべき軸や解釈を前提にしつつ、表現の幅を広げたり、説明文を磨いたりするうえで、AIは良い壁打ち相手になると感じています。 診断の仕組み：3つの軸、8つのタイプ 診断は、3つの軸の組み合わせでPdMのタイプを分類します。 軸① コミュニケーション Logic（理詰め型）／ Emotion（共感型） チームや関係者をどう巻き込むかを見る軸です。 データや論理で動かす傾向が強いのか、共感や関係性を起点に動かす傾向が強いのかを見ます。 軸② 価値の方向性 UX（ユーザー価値重視）／ BV（ビジネス価値重視） どの成果をより重視しやすいかを見る軸です。 顧客体験を起点に考えるのか、事業成長や収益性を起点に考えるのか、その傾向を整理します。 軸③ 志向性 Discovery（探索志向）／ Delivery（実行志向） どのフェーズでモチベーションを感じやすいかを見る軸です。 まだ見ぬ課題を発見することに惹かれるのか、価値を着実に届けることに手応えを感じるのかを見ます。 この3軸の組み合わせで、8つのタイプになります。 ※本記事では、診断の詳細な設問内容や公開方法そのものの案内は割愛します。 ラクス社内で試してみた せっかく作ったので、ラクスの開発組織でも試してみました。 プロダクト部のメンバーだけでなく、楽楽シリーズの開発に携わるエンジニア、QA、インフラ、管理職まで、幅広く参加してもらいました。 ここで紹介するのは、個人を評価したり決めつけたりするためのものではなく、 組織の傾向を俯瞰して見るための集計結果 です。 「どのタイプが優れているか」を見るものではなく、「どんな視点が集まっているか」を知るための材料として扱っています。 そのうえで、いくつか興味深い傾向が見えてきました。 開発組織全体の傾向：「Logic × UX × Discovery」が最多 開発組織全体を見ると、もっとも多かったのは サイエンティスト（Logic × UX × Discovery）タイプ でした。 各軸の全体比率は次のとおりです。 論理的に考え、ユーザー価値を重視し、探索や発見にモチベーションを感じる人が多い。 これが、開発組織全体の大まかな傾向でした。 実際、日々のプロダクト開発でも、 「顧客課題をより深く理解したい」 「仮説を立てて検証したい」 という姿勢を持つメンバーが多いと感じています。この傾向は、顧客にとって本当に価値のある機能や体験を考えるうえで、ラクスの開発組織らしさの一つかもしれません。 プロダクト部の特徴：「Discovery」が際立って高く、2つのタイプが拮抗 プロダクト部に絞ると、また少し違った顔が見えてきました。 プロダクト部の各軸比率は次のとおりです。 特に目を引いたのは、志向性です。 全体でも67%がDiscovery型でしたが、プロダクト部では 79% とさらに高くなっていました。まだ答えのない問いを探索することが好きな人、発見のフェーズにエネルギーが湧く人が多い組織だと言えそうです。 さらに興味深かったのが、タイプの分布です。 プロダクト部で最多だったのは、 ビジョナリー（Emotion × UX × Discovery） と ストラテジスト（Logic × BV × Discovery） の同率首位でした。 一方は、共感から未来の体験を描くタイプ。 もう一方は、構造から勝ち筋を見出すタイプです。 アプローチは対照的ですが、どちらも「Discovery（探索）」に強く向いているという共通点があります。 感性寄りの人と論理寄りの人、ユーザー価値を強く見る人とビジネス価値を強く見る人が混在している。 その多様さが、ラクスのプロダクト部の特徴の一つなのかもしれません。 この結果をどう受け取るか 「タイプが違うと、摩擦が生まれるのでは」と感じる方もいるかもしれません。 私は、むしろ逆だと思っています。 たとえばビジョナリーとストラテジストは、それぞれ異なる強みを持っています。 共感から体験を描く力と、構造から事業の勝ち筋を考える力は、どちらもプロダクトづくりに欠かせません。 大切なのは、「あなたはこのタイプだからこうあるべき」と決めることではなく、 このチームにはどんな視点が集まっているのか を知ることだと思っています。 その視点の違いを理解できると、 顧客課題の見立てに偏りがないか 意思決定の観点が足りているか 誰がどの場面で力を発揮しやすいか といったことを、より建設的に話しやすくなります。 実際、この診断をきっかけに、ラクスのプロダクト部でも 「自分はどういう場面で力を出しやすいか」 「チームとして見ると、どの視点が強くて、どの視点が薄いか」 を話題にしやすくなった感覚があります。 その結果として、顧客にとっての価値の捉え方や、プロダクトづくりにおける役割分担の解像度が少し上がったように感じています。 まとめ 「PdMタイプ診断」は、まだ発展途上のツールです。 型にはめることが目的ではなく、 共通言語を通じて、自分やチームの傾向を理解するための出発点 として使ってもらえたらと思っています。 PdMとして、あるいはプロダクトづくりに関わる一人として、 「自分はどんな場面で力を発揮しやすいのか」 「チームの中でどんな視点を持ち込みやすいのか」 を考えるきっかけになれば、作った甲斐があります。 そして、こうした相互理解は、よりよいチームづくりだけでなく、 顧客課題を多面的に捉え、より価値あるクラウドサービスを届けることにもつながるはずです。 興味を持っていただけたら、ぜひ一度試してみてください。 おわりに ラクスのプロダクト部では、さまざまなタイプのPdMやデザイナーが一緒に働いています。 違いを面白がりながら、顧客にとってよりよい価値を考え続けたい方と、ご一緒できたらうれしいです。 採用情報は、ぜひこちらからご覧ください。 career-recruit.rakus.co.jp speakerdeck.com