山下さんとの往復書簡、第四回目（そして私のパートの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 .

技術を土台にして自分なりのQAエンジニアを目指す本連載、第9回のテーマは「コーチング」です。 QAやテストの専門性からすると、少し遠い領域だと感じる方も多いかもしれません。正直、私自身、コーチングというものを「なんだか怪しいもの」だと思っていました。 しかし、アジャイルコーチなど現場の最前線で活躍する方々の話を聞くうちに、その認識は大きく変わりました。 人々のアウトプットとしての「品質」を本当に良くしていく、あるいは組織の「品質文化」を変えていくためには、コーチングの技術が極めて有用であると考えたのです。 その気づきから、私自身も本格的に個人やシステムに対するコーチングを学ぶため、スクールに通い始めました。 今回は、私にとって最も直近で築かれた新たな「土台」であるコーチングについてお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む 「教える」から「引き出す」への転換 QAエンジニアとして活動する中で、私は品質やテストについて、比較的解像度高く言語化してきた、あるいは『自分にはそれができる』という自負がありました。 しかし、その自負が、時にチームに対して「専門家としての正解を押し付ける」ような振る舞いを生んでしまっていたと今では思います。 テストにおいても、品質保証においても、「こうあるべきだ」という強い思いがありました。 そういった状態で特に「QAエンジニア」という役割を担ってしまうと、「高圧的で怖い人」として映ってしまうことも少なくありません。 もちろん、専門家として意見をはっきりと伝えることが必要な場面は多々あります。 しかし、人の行動やマインドセットを変容させようとするフェーズになったとき、専門家からの一方的な指摘だけでは人は生き生きと動くことは困難だと気づいたのです。 そんな中で、コーチングという技術を詳しく知る機会がありました。コーチングという技術あるいはその関わり方が、その人の内発的動機を高め、行動に繋げることができるものだと知りました。 そして、実際にコーチングを実践するときには、単なる「聞く」「質問する」といった目に見える表面的な技術だけでなく、自己基盤やコーチングマインドが大事だと知ったのです。 私が実際に通った銀座コーチングスクールでは「コーチングピラミッド」という形で示されています。 図：銀座コーチングスクールのコーチングピラミッドを参考に作図 https://www.ginza-coach.com/overview/feature/curriculum.html （参照日:2026/3/21、最終更新日2026/1/20） 自己基盤 まず、コーチングピラミッドにおける「自己基盤」という考えを示しておきたいです。 これは私の理解で言えば、コーチ自身がクライアントに対して恥じることのないあり方を体現していることです。「プロのコーチ」としてプロフェッショナリズムを持っていることだと考えています。 これはQAエンジニアとしての土台にも同じことが言えます。私自身の自己基盤もまた、「プロであること」に加え、例えば「高い倫理観を持つ」「自分自身を裏切らないこと」をベースとしています。 安易に「見栄えのいい専門家」を演出してしまうと、結果として自己欺瞞に繋がり、それは自分自身の自己基盤を揺るがしてしまうと考えています。 泥臭くても自己開示し、困難に対しても正面から向き合えるような、「良いクライアントの鏡でもある」という自負が、私自身のプロフェッショナリズムを育てていると考えています。 コーチングマインド コーチングを学んだことによる最大の収穫は、「答えは相手の中にある」というマインドセットを得たことです。 コーチングを書籍などで表面的な手法だけ学んでしまうと、「質問」や「聞く」といったスキルで終始してしまうことも少なくありません。私自身も実際にそういった過ちを犯していました。 今ではコーチングマインドや自己基盤、信頼関係といった土台の構築こそが、専門性として身につけるべき本質だと思っています。 相手の中にある視点や気づきをどのように発見し、どう繋げていくか。 この「あり方」こそが、特にQAエンジニアがコーチングを学び、品質文化を醸成する上で非常に重要だと確信しています。 その「答え」は、実は相手が自覚していない場合があります。 むしろ「答え」に向き合う過程で、相手を困難に直面させるようなこともあるかもしれません。 そのような場合であっても、相手のプロフェッショナリズムを心から信頼し、目を背けたくなるような事実を鏡のようにフィードバックすることも、コーチとして時に必要になると考えています。 コーチングの技術を品質保証に活かす コーチングには「聞く」「認める」「フィードバックする」「質問する」といった技術があります。 上記で述べたように、これらの技術を土台なしに実施することは、本質を欠いたまま適用してしまう危うさがあります。 一方で、正しくこれらを用いて、クライアントの壁打ち相手になったり、適切な問いかけを行ったりすることは、品質保証の活動と非常に相性が良いです。 ここからは、コーチングの技術が、これまでの連載で触れてきた専門性とどのように組み合わさるのかを紹介します。 専門性の組み合わせ：テスト計画(リリース基準)との組み合わせ テスト計画を立てたり、リリース基準をチームで合意したりする際、コーチングの「問いかけ」や「フィードバック」の技術が力を発揮します。 第３回 でテストマネジメントは「合意形成」の技術だと述べましたが、その合意を真に納得感のあるものにするための具体的なアプローチの一つが、このコーチング的な「問いかけ」です。 QAエンジニアが一人で基準を決めるのではなく、チームに対して次のような問いを投げかけます。 「どういう状態になれば、自信を持ってリリースできますか？」 「あなたがステークホルダーであればこの製品に対してどう感じますか？」 「あなたが知っているステークホルダーはどのような人ですか？」 このように相手の思考や気づきを引き出すことは、チームが品質に対するオーナーシップを持つことに役立ちます。 自分自身の言葉で紡ぎ出したオーナーシップは、「生きた品質文化」として根付いていくと考えています。 専門性の組み合わせ：テスト実行との組み合わせ テスト実行を通じてメンバーの成長を促す場面でも、コーチングは有効です。 テスト実行中に手が止まっているメンバーや、バグを見つけたメンバーに対して、「こういう視点でテストしなさい」と教えるのではなく、気づきを促す問いを投げかけます。 「今、テストを実行していて何に気づきましたか？」 「もし自分ではなく、別のユーザー(あるいは尊敬するテスター)だったら、次にどうすると思いますか？」 「あなたが作り手だったらどんなフィードバックを望むでしょうか？そのためには何をすればいいですか？」 「こういう視点があるよ」と教え込むのではなく、「あ、こういう視点もあるんだ」と自分自身で気づいてもらうこと。 これが、テスト実行における個人のスキルアップや深い洞察に繋がります。 おわりに QAエンジニアとしてコーチングの技術を扱う上で重要だと考えている点があります。 それは「コーチング技術を自分自身の存在価値のため、あるいは相手のメンタルケアのために使わない」ということです。 QAエンジニアの専門性とコーチングを複合した時に、個人の感情やモチベーションだけではなく、「システム（構造）」に直面することがあると感じます。 例えば、バグが放置されがちな現場があったとします。 ここで「どういう理由で直さないの？（本当はどうしたいの？）」と個人のモチベーションを聞いたり、あるいはただ共感して寄り添うだけでは、根本解決にならないと感じています。 コーチであると同時にQAエンジニアとして考えたとき、このような状況では品質保証の原則である「源流管理」に立ち返ることも時には必要です。 プロのQAエンジニアが行うコーチングとは、我々が理解できていることや、ソフトウェアの動作、バグの発生状況といった「客観的な事実」と向き合うことです。 そして、「この事実が、今の私たちのシステム（開発プロセスやチームのコミュニケーション構造）のどこに問題があることを示しているのか？」という問いを立て、メンバーのプロフェッショナリズムを信じて共に探索していくことだと考えています。 コーチングは、ソフトウェアテストや品質保証とは遠い場所にあるように思えるかもしれません。 しかし、それは「プロとしてのあり方」を学び、チームと協調しながら根本的な品質文化を形作るための、非常に強力な技術です。 この新たな土台が、皆さんのQAエンジニアとしての幅を広げる一つのヒントになれば幸いです。 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む The post 【第9回】コーチング：相手の中にある答えを引き出し、品質文化を育む first appeared on Sqripts .

こんにちは。Sqripts編集部のハチワレです。 最近は生成AIに携わることが多く、日々の進化を驚きと喜びを感じながら眺めています。そして、「コードを書く」ことの垣根がどんどん低くなっていることも、「AIってすごいな～」ぐらいの気持ちでただただ感心して眺めておりました。 今回は、そんな私が実際に遭遇した「ちょっとヒヤッとした話」をもとに、生成AI時代の実装リスクについて書いてみたいと思います。 あくまで「とあるDX現場の物語」として読んでいただければ幸いです。 ※本記事は、実際に現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。 ある日、フォームが動かなくなった 「フォームが表示されません」 こんな連絡が届いたのは、ごく普通の業務日のことでした。 確認してみると、たしかに挙動がおかしい。コードに少し修正を加えるように伝えると、今度はこう返ってきました。 「フォームは動きましたが、フォーム送信完了ページ（サンクスページ）が404です！」 ……サンクスページが、ない！？（404は「ページが見つかりません」のエラーコードです） 調査を進めてみると、MA（マーケティング・オートメーション ※ ）側の設定を、あるマーケティング担当者が生成AIと対話しながら変更していたことがわかりました。 ※マーケティング・オートメーション（MA）とは、フォームの発行、ユーザー管理、メール配信など、マーケティング活動に関わる様々な機能を持つツールのことです。 「動いた」と「大丈夫」は、まったく別の話 その担当者に、開発の経験はありません。 それでも、生成AIに「やりたいこと」を自然言語で説明してJavaScriptのコードを生成してもらい、MAに実装することができました。 コードは動き、担当者は大きな成功体験を得ました。 問題は、誰もその「先」を確認していなかったことです。 — ここで少し、「影響範囲」という概念についてお話しさせてください。 システムやWebサイトを構成するコードは、それぞれが独立しているようで、実はさまざまな形でつながっています。あるページの挙動を変えるコードが、別の処理の前提条件になっていることも珍しくありません。 今回のフォームと送信完了ページがまさにそれでした。 表から見ると、「フォームを送信する。送信後に『ありがとうございました』のようなページが表示される」というシンプルな存在です。しかし裏側では、いくつかの処理が連鎖していました。 フォーム送信の完了を検知して計測する処理 送信者の情報をほかのツールに連携する処理 担当者への通知やスコアリングに関わる処理 など、このフォームから送信完了ページへの遷移は、「ユーザーが正常にフォームを送信した」というシグナルでもあったわけです。そのシグナルを受けて、複数のシステムが動いていました。 変更されたコードは、この一連の流れに割り込みました。結果、送信完了ページは404エラーを返し、連携データは正常に記録されなくなっていました。フォームそのものは見た目上は「動いて」いましたが、その裏側で起きるべきことが、静かに止まっていたのです。 影響範囲スコープの例 フォームが「動いた」のは確かです。でもそれは、「大丈夫」ではありませんでした。 影響範囲とは、「自分が触れたコードが、どこまでの処理に関係しているか」という見取り図のようなものです。この見取り図を持っているかどうかが、「動かせる」と「安全に実装できる」の分かれ目になります。 悪意があった人は、誰もいない 誤解のないようにお伝えしておくと、今回の件で悪意があった人は一人もいません。 担当者は業務を効率化しようとしていましたし、生成AIを活用しようとしていました。その姿勢は、むしろ前向きです。 Webサイト側の担当者も、相談は受けていました。ただ、コードの中身をレビューできる知識はなく、「何かを変えるらしい」とは知っていても、何がどう変わってどんな影響が出るかまでは判断できませんでした。 そして、もうひとつ大事なことがあります。 実装した担当者は、そもそも「フォームや送信完了ページに『他の働きをする何か』が仕込まれている」という知識を持っていませんでした。表から見ればただの入力フォームと送信完了ページ。まさか、その裏側でツール連携や計測が動いているとは、思いもよらなかったのです。 「確認しなかった」のではなく、「確認すべきものがあると知らなかった」。これは責める話ではありませんが、だからこそ厄介です。本人の注意や意識だけでは、防ぎようがない。 誰も手を抜いていないのに、システムは壊れた。 これが今回、私が一番伝えたいことです。 「コードが書けない」という壁が、なくなった 少し前まで、「コードが書けない人」はコードを書きませんでした。当たり前のことですが。 やりたいことがあっても、実装する手段がない。だから、担当範囲を超えた変更は物理的に起きにくかったのです。 「この機能を変えたい」と思っても、コードが書けなければエンジニアに依頼するしかない。依頼するということは、必然的に「何をどう変えたいのか」を説明し、確認してもらうプロセスが発生する。面倒に感じることもあったでしょうが、このプロセスが「影響範囲の確認」を担っていたと言えます。 生成AIは、その壁を取り払いました。 プログラミングの知識がなくても、やりたいことを言葉で説明すれば、動くコードが出てきます。エンジニアへの依頼も、確認のプロセスも、必要なくなりました。 これ自体は、すごいことです。間違いなく。 ただ、壁が取り払われたとき、同時に「ゲート」も消えてしまいました。 エンジニアが影響範囲を判断するタイミング、このプロセスが、いわば「実装前のゲート」として機能していたのです。生成AIによって誰もが一人で完結できるようになったことで、そのゲートもなくなってしまいました。 「書けるようになった」と「わかるようになった」は、まったく別の話です。 生成AIはコードを書いてくれます。でも「このコードが既存のシステムと干渉しないか」「影響を受けるのはどの処理か」「変更前に誰に相談すべきか」という問いを立てられるのは、影響範囲の見取り図を持っている人、つまりシステム全体を俯瞰して把握している人だけです。 もちろん、生成AIにその見取り図を渡すことができれば影響範囲の判定もしてくれます。 ですが、見取り図を持たない人に、その「問いを立てる力」は、生成AIは与えてくれません。（今のところ） だからこそ、「人間が介在する」設計が必要になる ここで、AIの世界でよく使われる概念をひとつご紹介したいと思います。 HITL（Human-in-the-Loop） という考え方です。 AIによる自動化されたプロセスに、意図的に人間が介在する仕組みのことを指します。AIが得意な「大量処理・高速生成」と、人間が得意な「判断・文脈の理解・倫理的な配慮」を組み合わせることで、より質の高い結果を目指す、という発想です。 私はこの概念がとても好きで、AIの活用を考えるときの基本的な視点として大切にしています。 今回の件は、まさにHITLが機能していなかったケースです。 生成AIがコードを生成する→人間がそのまま実装する、という流れに、「影響範囲を判断できる人間」が介在していなかった。AIの出力を人間がレビューし、「これは既存のシステムに影響しないか」「担当者に確認が必要ではないか」と判断するステップが、すっぽり抜けていました。 AIを使うこと自体が問題なのではありません。AIの出力をそのまま「正解」として扱い、人間の判断を挟まなかったことが、問題だったのです。 「これ、大丈夫なやつ？」という感覚 私はこれを、「大丈夫チェック」と呼んでいます。 コードを実装する前に一瞬立ち止まって、「これ、大丈夫なやつ？」と自問する。シンプルな問いですが、これができるかどうかが、今の時代に大きな差を生むのではないかと思っています。 具体的には、こんな確認です。 全体のシステムのどの部分に触れる変更か 既存のコードや設定と干渉する可能性はないか 担当者への事前確認は完了しているか こうした確認を、属人的な「声かけ」に頼るだけではなく、チームの手順として持っておくこと。それが「動いた」と「大丈夫」のギャップを埋める方法だと、今回の経験から強く感じました。 そして、この「大丈夫かどうか」を 仕組みとして担保する のが、「テスト」という考え方です。 変更後に期待通りに動くかを確認するだけでなく、「既存の動作が壊れていないか」を検証するテスト（リグレッションテストと呼ばれます）は、まさに今回のようなケースの再発を防ぐための安全網になります。 生成AIが実装の入口を広げたことで、テストの重要性もまた、以前より増していると感じています。 関連記事 リグレッションテストとは？目的、実施タイミング、実施方法、自動化について解説 リグレッションテストとは「リグレッションテスト」（Regreesion Test／レグレッションテスト）は、ソフトウェア開発におけるテスト手法のひとつで、「回帰テスト」「退行テスト」とも呼ばれます。リグレッションテストは、プログラムの修正や変更を行った際に、変更... 　続きを読む　 Sqripts まとめ 今回お伝えしたかったことを整理すると、こうなります。 「動いた」≠「大丈夫」 ：生成AIが生成したコードが動作することと、既存システムに悪影響を与えないことは別の話 壁がなくなった時代のリスク ：誰でも実装できるようになったからこそ、「影響範囲を測る」プロセスの重要性が増している 悪意より怖い「善意のインシデント」 ：誰も悪くないのに壊れる、というケースへの備えが必要 「問いを立てる力」は人間が持つ ：生成AIはコードを書いてくれるが、「これ大丈夫？」と問えるのは、構造を知っている人間だけ HITLの視点を持つ ：AI任せにするのではなく、判断できる人間がプロセスに介在する設計を意識する 「テスト」は「大丈夫」を仕組みにする手段 ：変更が既存の動作を壊していないかを確認するテストが、善意のインシデントを防ぐ安全網になる 生成AIの登場で、ソフトウェアに関わる実装のハードルは確実に下がっています。だからこそ、「実装してよいかを判断する人・仕組み」の価値は、むしろ上がっているのではないでしょうか。 この記事が、どなたかの現場での一助になれば幸いです。 最後までお読みいただき、ありがとうございました。 本記事は、実際にとあるDX現場で起きた出来事をもとに構成しています。登場人物・インシデントの内容は一部変更しています。 ▼非エンジニアにもおすすめの関連記事 関連記事 Generative AI Leader（生成AIリーダー）認定資格試験を受けてみた｜知識ゼロから始めた学習方法と試験対策 こんにちは。Sqripts編集部のハチワレと申します。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。「非エンジニア」を称しています。今回は、非エンジニアの私がGoogle Cloudの認定資格、Generati... 　続きを読む　 Sqripts 関連記事 生成AIの基礎リテラシーと明日から業務で使える活用術 こんにちは。Sqripts編集部のハチワレです。かつてはフロントエンドやUI開発に携わり、テクニカルサポートも経験しましたが、現在の私の主戦場はマーケティング。技術と非技術の狭間に佇み、両方の世界を行き来する日々を過ごしております。前回は「Generative AI Le... 　続きを読む　 Sqripts The post AIがコードを書いた。動いた。でも、システムは壊れていた話。 first appeared on Sqripts .

みなさまこんにちは、天野です。 私は前職のサイボウズでスクラムを導入し、同社初のスクラムマスターとして長年活動してきました。社内のアジャイル導入の過程でさまざまな職能のメンバーと関わり、特に品質については強い関心を持って取り組んできました。プロダクションレベルの品質をいかに素早く確立するか、スプリントの中でどう品質を満たすか、といったテーマです。 その中でQAのメンバーとも多くの時間をともに過ごし、品質や人材の成長について考えてきました。後年はマネージャーとしてQAメンバーのキャリアを支援したり、QAからスクラムマスターに転身したメンバーをマネジメントしたりもしてきました。 組織の中にいるときは当たり前だったことが、外に出てみてはじめて「あれが自分を育てていたのか」と気づくことがあります。社内での実践と社外への発信を行き来する中で得てきたものを、一人の実践者として届けたい。それがこの連載を書こうと思った理由です。 本連載ではそんな背景をもとに、「社内外を往復するアジャイルQAの育ち方」というテーマで全4回の記事を書かせていただきます。よろしくお願いします。 アジャイルな人材とは さて、連載の第1回となる今回は「アウトプット」の話から始めたいと思います。 まず、アジャイルなQAとは何でしょうか。私は、QAに限らず「アジャイルな人材」とは、学習する力が高く、これまでのやり方に固執せず、新しいことを吸収しながら改善を重ね、自律的に仕事をより良くしていける人だと考えています。 こうした学習する力は、何によって支えられているのでしょうか。一つには書籍を読む、ウェブから情報を得るなど、個人的なインプットがあります。もちろんそれも重要です。しかし、インプットした情報を踏まえて実際に手を動かし、発信する。そこで他者からフィードバックを得て議論し、新たな知見を蓄積し、さらに実践を深めていく。このサイクルを回している人は、学習する力が極めて高いと感じます。 インプットにとどまらず、実践、発信、フィードバック、それをさらに実践に生かすサイクル。この起点としてまず取り組みたいのがアウトプットです。 「アウトプットした方がいい」のに踏み出せない理由 アウトプットの重要性を語る場面でよく聞くのが、「した方が良いと分かっているけれど、なかなかできない」という悩みです。 アウトプットできない理由としてよく挙がるのは、こんなものです。 「時間がない」 「マサカリが飛んでくるのが怖い」 「自分なんかがやっていることを発信しても大した価値はないのではないか」 「もっとちゃんとした成果が出てから発信したい」 正直に言えば、私もかつてはこれらすべてに当てはまっていました。特に「もっとちゃんとした成果が出てから」という気持ちは強く、書けずにいた時期が長くありました。 理由はそれぞれ異なりますが、共通しているのは アウトプットのハードルが高くなっている ということです。特にQAに携わる方は、日頃から品質を見極めることを仕事にしているぶん、自分のアウトプットに対する暗黙の品質基準も高くなりがちではないでしょうか。その根底には、アウトプットとは十分な成果をまとめ上げた「完成品」であるべきだ、という前提があるように思います。つまり、 アウトプットを活動の「ゴール」として捉えている のです。 しかし、アウトプットをゴールと捉えると問題が起きます。私たちの仕事は明確な区切りがないものも多く、基本的にはずっと続いていきます。「区切りがついたらアウトプットしよう」と思っていると、なかなかそのタイミングが見つからず、ハードルが上がり続けてしまいます。 これはソフトウェア開発に喩えれば、ウォーターフォール的な「ビッグバンリリース」の発想です。すべてが完成してから一括でリリースしようとすると、リリースそのものが重く、遠くなっていく。アジャイルの考え方に従えば、リリースはできるだけ小さく、高頻度に届け、そこからフィードバックを受けて学ぶというサイクルを回します。 アウトプットも同じです。小さくして頻繁にリリースすれば、学習のサイクルが速く回り始めます。そしてそれは、アウトプットそのもののハードルを下げることにもつながるのです。 アウトプットは「思考のインクリメント」 私が提案したいのは、アウトプットを自分の活動から生まれる「インクリメント」の一つとして捉えることです。スクラムにおけるインクリメントとは、スプリントごとに積み上がる「利用可能な成果物」のことです。一定の周期で小さな成果物を届ける仕組みがあるからこそ、「検査と適応」のサイクルが回ります。 アウトプットにも同じことが言えます。自分の活動や考えを定期的に言語化して外に出していれば、そのアウトプットが検査と適応の対象になります。アウトプットは自分の思考の過程そのものですから、つまり 自分の思考や考え方そのものが検査と適応の対象になる わけです。 これは極めて強力な、思考を鍛える仕組みです。アウトプットとは、頭の中にあるものをそのまま外に出す作業ではありません。 教育心理学者のBereiterとScardamaliaは、著書『 The Psychology of Written Composition 』(1987)の中で、書くプロセスを「知識伝達（knowledge telling）」と「知識変換（knowledge transforming）」の二つに区別しました。知識伝達とは、知っていることをそのまま書き出すこと。一方、知識変換とは、読者に伝わるように構成を考え、言い回しを工夫する過程で、「そもそも自分は何が言えるのか」「どこが弱いのか」が露呈し、知識や理解そのものが更新されていくプロセスです。 アウトプットの過程ではまさにこの知識変換が起きています。言語化する過程で、理解の怪しい点が否応なく炙り出されます。書き進めるうちに、曖昧だった思考の輪郭が次第にはっきりしてくる。書いたものを読み返し、スムーズに読めるか、論理に齟齬がないかを確認する。こうした一連のプロセスが、対象についてより深く考えることを促し、累積的な思考量を増やしていきます。 つまりアウトプットとは、思考を「出す」行為であると同時に、その過程で思考内容が検査され、思考を「鍛える」行為でもあるのです。 なぜアウトプットが自己変容を促すのか 継続的なアウトプットは、思考量を大きく押し上げます。書くことでインプットへの欲求も自然と高まり、学びのサイクルが加速していきます。 また、認知心理学では「プロテジェ効果」と呼ばれる現象が知られています。他者に教えるつもりで学ぶと、自分のために学ぶ場合よりも学習成果が向上するというものです。興味深いのは、実際に教えなくても「教えるつもりで準備する」だけで効果があるという点です。つまり、「読者に伝えよう」と意識してアウトプットを準備する行為そのものが、学びを深めているのです。 さらに重要なのは、継続的なアウトプットを支えるには、長期にわたる「一貫したテーマ」が必要になるということです。 一貫したテーマを持つと、常にそのテーマについてアンテナを張るようになります。アンテナを張った状態とは、すなわち問いを立てている状態です。これが普段の思考と行動に影響を与えます。 たとえば「開発チームの品質文化を育てる」というテーマを持っていれば、日々のテスト設計やレビューの中でも常にそのレンズで物事を見るようになります。気づいたことや試行錯誤をアウトプットすることが、さらなる行動変容を駆動する。こうしたループが回り始めます。 また、過去のアウトプットを見返せば、自分の思考の変遷を辿ることができます。差分を比較することで、さらに理解が深まる。このように、アウトプットは強力に自己変容を促す仕組みとして機能します。 ここで一つ強調しておきたいのは、このプロセスを自分自身で経験することの重要性です。今はAIに文章を書かせることも容易になりました。しかし、構成を考え、言葉を選び、論理を組み立てるプロセスそのものが思考を鍛えているのです。それをAIに外注してしまうと、アウトプットから得られる学習効果の大部分を手放すことになります。AIは下調べや推敲の相談相手としては有用ですが、「自分で考えて書く」という核の部分は、自分でやるからこそ意味があります。 PVやバズを目的にすると続かない 昔の私はエンジニアブログを書いては、はてなブックマークが何件つくかで一喜一憂していました。「ホッテントリ入りだ！」「300ブクマ超えた！」といった具合です。正直なところ楽しかったですし、書くモチベーションにもなっていました。 ただ、反応というのは期待したようにはつかないものです。数字を目的にし続けると、伸びなかったときに落胆し、だんだん手が止まるようになりました。また、必要以上に注意を引こうとして、炎上や論争を煽るような記事を作る「歪み」をもたらすリスクもあります。そうした記事には批判的なコメントもつきやすく、不毛な応酬は精神を消耗させます。 PV数やLike数を目的にすると、価値判断の基準が単純な数値に置き換えられます。さらに厄介なのは、「もっと注目されるにはどうすればいいか」という問いが頭を支配しはじめることです。これは、学びの促進や自己変容という本来の目的から大きく逸れた動機です。 では、何を目的にすればいいのか。ここまで述べてきたように、アウトプットの本質的な価値は、累積的な思考の蓄積と自己変容にあります。それを目的とするならば、アウトプットした時点で目的は達成されます。反応がつくかどうかはあくまでおまけです。「書くことそのものが自分を鍛えている」という実感があれば、外部の数値に振り回されることなく、アウトプットを続けていくことができます。 何のためにアウトプットするのか アウトプットの目的としては、他にもよく語られるものがあります。特に会社のエンジニアブログのような公式の媒体では、「採用につなげる」という目的が必ずと言っていいほど挙がります。実践の結果や学んだことをブログに書いておけばポートフォリオになり、転職や副業の際にキャリアのプラスになるという考え方もあります。 これらはアウトプットの成果として確かに大切です。ただ、人によっては「採用のために頑張ろう」「転職に有利だから書こう」と言われても、今の自分にとって少し遠い話に感じられ、なかなか手が動かないこともあるのではないでしょうか。少なくとも私はそうでした。 そこでもう一つの捉え方を提案したいのが、これまで述べたような「自分自身を変容させるための手段」、そして「学びを得るための手段」としてのアウトプットです。この捉え方であれば、活動自体に意義を感じ、取り組むための心構えができるのではないでしょうか。 そして、自分を鍛えるためにアウトプットを続けていると、結果としてその知見が誰かの参考になっていたり、業界全体の学びの蓄積に貢献していたりすることがあります。採用やキャリアへの好影響も、狙って得るものではなく、続けた先に自然とついてくるものです。 まずはリズムを作ることから とはいえ、自己変容「だけ」を目的にすると、変化を実感するまでに数年単位の時間がかかります。それはそれでしんどいものがあります。 ただ、実際にアウトプットを続けてみると、もう少し手前の段階で変化を感じられるものです。書く過程で自分の理解の穴に気づく。人に読まれることを意識して構成を考えるうちに、普段の仕事でも論理の組み立て方が変わってくる。こうした小さな手応えは、数回のアウトプットで感じ始める人が少なくありません。 おすすめなのは、「アウトプットのリズム」だけを決めて、淡々と続けることです。その過程で、たまにバズったり仕事の機会につながったりすればラッキー、くらいの気持ちでいるのが長続きのコツだと思います。 いきなり公開のブログを書く必要はありません。まずは日記やメモでも十分です。書くこと自体が思考を鍛えるプロセスだからです。 その上で、もし一歩踏み出せるなら、社内のSlackやチャットで今日学んだことを一言書いてみてください。日報や週報に「気づいたこと」の欄を設けてみるのもよいでしょう。こうした小さなアウトプットも立派なインクリメントです。外に出すことで他者からフィードバックが得られ、学びのサイクルの質がぐっと上がります。チームや組織にとっても、ナレッジが蓄積されるという大きなメリットがあります。 慣れてきたら、書き溜めたものを少し整理して社内のナレッジベースやブログにまとめてみる。隔週でも月一でも構いません。 大切なのは、始めること。そして、続けることです。 次回は、「では具体的に何をどう書けばいいのか」という実践的な話に踏み込みます。日々の仕事を「記事になる形」に整える技術についてお伝えします。 The post 【第1回】アウトプットが続かない本当の理由：「完成品」を手放して最初の一歩を踏み出す first appeared on Sqripts .

エンジニアのキャリアにおいて、技術を極め続けるICとしての道が理想とされることも多い一方で、現実には企業によってICキャリアが用意されていないことも少なくはありません。 もし、あなたがQA技術者のトップとしてだけではなく、QAマネージャーという立場で誰かの将来も同時に背負うことになったとき、一体どう立ち振る舞うべきでしょうか。連載の最終章となる今回は、前回までとは少し趣を変え、マネージャーの観点も含めて「メンバーと一人の人間としてどう向き合うべきか」というテーマでお話しします。 記事一覧：AI時代だからこそ「あなたにお願いしたい」と頼まれるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」（連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ 【第4回】深夜のラーメンがやめられない僕たちは、いかにして「シフトレフト」を実現すべきか 【最終回】思い通りにならない他者へ敬意を シニアが直面するかもしれない、とある「孤独」 あなたがもし組織のリーダーとして頂に立つと、きっとメンバーを手塩にかけて育てることでしょう。そのうち、「右腕」と呼べる大切な存在が生まれるかもしれません。しかしその時、もしかしたらこんな悩みに出会うかもしれません。 「自分のチームメンバーは、どんなミッションも完璧にこなしてくれる。でも、私の『理想』は体現してくれない。特に右腕にはもっと多くの理想を体現してほしい！」 このような寂しさを感じるかもしれません。でも、その正体は、 「機能的な右腕」と「精神的な右腕（イズムの継承者）」のズレ にあります。メンバーはあなたの「忙しさ」を分かち合ってくれるかもしれませんが、あなたの「孤独や葛藤」を分かち合ってはくれないものです。特にあなたの右腕には多くを求めてしまうかもしれませんが、それは右腕であっても同じで、そういうものなのです。 立場が全く異なるため、もしかしたら彼は優秀な右腕であっても、「理想を継承した右腕」ではないのかもしれません。 全てを一人に求めないことも「信頼」の一つ もし、あなたが「理想の継承」と「実務遂行」をメンバーや右腕に同時に求め、それが叶わないことに寂しさを感じているなら、組織には2つのタイプの人材がいることを思い出してください。 宣教師タイプ： ビジョンに共感し、その「意図」を追い求める人。 傭兵タイプ： プロとして「どうやるか」を極め、タスクを完遂することに喜びを覚える人。 あなたがそのように悩むのは、あなたの右腕は、極めて優秀な「傭兵」タイプなのでしょう。 もし彼がそうでなかったら、今の現場はこれほど円滑に進んでいなかったはずです。 「安心して背中を預けられる存在」。この役割の徹底こそが、右腕なりの「合理的配慮」であり、相棒の形なのです。 「思い通りにならない他者」へ敬意を そんなメンバーや右腕と仕事をしていくことで大切になるのが、「思い通りにならない他者」への敬意です。 「思い通りにならない」という事実は、相手が自分とは異なる独立した人格（心、背景、論理）を持っているという証左でもあります。その「違い」や「ままならなさ」を否定してコントロールしようとするのではなく、そこに他者の存在を認めて敬意を払うというのは、成熟した対人関係への第一歩かもしれません。 この考え方には、いくつかの重要な側面が含まれています。 コントロールからの解放： 相手を自分の期待通りに動かそうとする気持ちを手放すことで、相手も、そして自分自身も 不必要な葛藤 から解放されます。 他者性の受容： 自分にとって都合の良い部分だけでなく、 理解できない部分や意に沿わない部分も含めて「その人である」と認める姿勢 です。 期待の適正化： 「敬意」は諦めるような冷たさではなく、 「相手には相手の正義や事情がある」と想像力を働かせる温かい距離感 を作ることにつながります。 自分の思い通りにならない時こそ、相手の「個」が最も強く現れている瞬間だと言えるのかもしれません。その「個」をありのままに尊重したその先に、私たちはようやく、彼がなぜあなたの理想に触れようとしないのか、という次の問いに向き合えるようになります。 あなたがもしそれでも「精神的な右腕」を求めてメンバーに理想の体現を求めているなら、まずメンバーが自立することが大切です。そのためには、「主語」を取り戻す手助けをする必要があります。 あなたの右腕は主語を失っているのかもしれない 手前味噌ですが、私の昔書いたブログを引用させてください。 「 迷った時は、主語を取り戻そう 」／MAX https://zenn.dev/enjapan/articles/bca0153009c7ef あなたのメンバーや右腕が理想を体現してくれないとき。それは彼らが 「主語＝私」を失い、「他人軸」で生きているから かもしれません。 リーダーの期待に応えたい、リーダーが言ったからやる……。こうした「他人軸」で動いている間、人は「私はどうしたいのか？」という問いを失います。主語を失った状態では、自分の選択を環境や他人のせいにしてしまい、自分のキャリアに「手応え」を感じられなくなります。そのような状態で、メンバーが同じ理想を共にすることは不可能です。 メンバーを可愛がるあまり、メンバーの役に立つために答えを与え続けていませんか？もしくは、自分の力を誇示しようとはしていないでしょうか？ 「主語を取り戻す」とは、自分の内側から問いを発し、その答える責任も、行動も、自分で引き受けることです。 メンバーがあなたの思う理想の右腕になってほしいと思うのであれば、今すぐあなたという「正解」を追うことをやめさせ、彼自身の「主語」を確立させるプロセスが必要です。 アドラー心理学が教える「水平な関係」と「課題の分離」 この「主語の奪還」を支える土台が、 アドラー心理学 です。 アドラー心理学の核心は、全ての対人関係を「垂直（上下）」ではなく 「水平（対等）」 として捉えることにあります。彼があなたを「師」として仰ぎ、あなたがそれに応えて正解を与え続ける限り、二人の関係は「垂直」なままです。垂直な関係では、メンバーは決断の責任を師に委ね、「選ばされた」という受動的な立場でい続け、結果として主語を失います。 ここで重要なのが 「課題の分離」 です。 「メンバーが私の理想を学ぶかどうか」は、メンバー自身の課題であり、あなたの課題ではありません。あなたが無理に学ばせようとすることは、相手の課題に土足で踏み込む「垂直な介入」です。 シニアの役割とは、メンバーを「未熟な部下」ではなく「一人の自立したエンジニア」として扱い、彼ら自身が自分の課題に向き合えるよう 「勇気づけ（エンカレッジメント）」 を行うことです。 あなたが偶像の椅子から降り、対等な目線で「信頼」を伝えること。それが、彼に「自分の主語で生きる責任」を自覚させる第一歩となります。 オープンクエスチョン——自分自身に責任を持つ 水平な関係を構築し、メンバーに主語を取り戻させるための具体的な「技」が、 オープンクエスチョン（開かれた質問） です。これは単なる会話術ではなく、相手に「自分自身に責任を持つこと」を教えるための大切な行動なのです。 「はい/いいえ」で答えられる質問（クローズドクエスチョン）は、あなたの正解をなぞらせるだけの「試し行為」にすぎません。 そうではなく、相手の内側から「私はこう思う」を引き出す問いを投げかけます。 「この目標で大丈夫か？（垂直な確認）」ではなく、 「この目標を実現した先に、君はどんな自分でありたい？（水平な対話）」 あえて答えを言わず、相手が自分の言葉で語り始めるまで静かに待つことも大切です。この沈黙の時間こそが、私のブログにもあるような、相手が他人軸ではなく、主語を自分の手に取り戻すための時間になります。マネージャーが責任を持って「決断を委ねる」ことで、メンバーは初めて「自分の声」を聴き直すことができるようになります。 結び：大いなる力には、大いなる責任が伴う 第1回 で、私はこう書きました。 「大いなる力には、大いなる責任が伴う」 。 あなたが積み上げてきた「心・技・体」という大いなる力。その力を、自分一人の成果や賞賛のためだけに使うのは、前回お話しした「深夜のラーメン（目先の快楽）」に負けるのと同じです。シニア、そしてマネージャーとしての真の責任とは、自分一人が高く登ることではありません。 「あなたがいなくなった後も、自分の主語で走り続けられるエンジニアを育てること」 にこそ、その本質があります。 それは、あなたという「人間」にしか作ることができない、しかしあなたが居なくなった後も組織の中で回り続ける「真の属人的な仕組み」です。これこそが、他の誰でもない「あなた」にしかできない仕事であり、創造できない価値なのです。 右腕があなたの理想を完全に理解してくれないと寂しいかもしれません。ですが、承認欲求による関係は、相手を自分の目的のための「対象」として扱っているに過ぎません。これは、あなたが頭の中に投影した理想の相手と対話しているに過ぎず、 目の前の生身の人間とは一度も目が合っていません。 目の前の相手と目が合わせられなければ、初めからそのメンバーと出会っていなかったことと同じです。 あなたがチームのトップとして必要なことは、対話を試み、相手を信じ続けることです。自分をいつか超えていく存在を生み出すためには、偶像の椅子から降りて自分の鎧を脱ぎ、対等な視座で「信頼」を伝え続けなければいけません。 あなたが育てたエンジニアが、自らの足で立ち、あなたを追い越していくその瞬間、あなたの「心」は、別の誰かの「体」となって生き続けます。彼らはあなたの心を受け継いで、外の世界から吸収し、あなたに新しい視点をもたらす特別な存在になってくれます。その時、あなたは一人のリーダーとして、もう孤独ではありません。 大いなる力を、大いなる責任へ。 技術だけでなく「心」を。より良いQAエンジニアの未来を、ここまで読んでくれたあなたと共に。 （連載完） 【連載】AI時代だからこそ「あなたにお願いしたい」と言われるQAエンジニアになろう 【第1回】QAエンジニアの「心技体」（連載初回 全文公開中！） 【第2回】見えない相手への「思いやり」とは何か？——エントリーキャリアが在宅勤務で信頼を築くための合理的な配慮とは 【第3回】AI時代に問い直すドキュメンテーション —「主張」から「伝達」へ 【第4回】深夜のラーメンがやめられない僕たちは、いかにして「シフトレフト」を実現すべきか 【最終回】思い通りにならない他者へ敬意を （最終回 全文公開中！） The post 【最終回】思い通りにならない他者へ敬意を first appeared on Sqripts .

今回は、 第5回の「営業」の回 に続き、再び「幕間」として、技術とは少し異なる、しかしQAエンジニアにとっては避けて通れないテーマについてお話しします。 そのテーマとは、「品質」です。 QAエンジニアと名乗る以上、「品質」という言葉は常に私たちの隣にあります。 私はこの言葉をなんとなく分かった気で使っていました。 そして、(今となっては幸いなことに)あるタイミングで、この言葉を明確に言語化する必要に迫られました。 その過程で出会ったのが、TQMという品質マネジメントに関わる包括的な方法論です。 私自身、TQMの専門家と呼べるほど成熟しているわけではありません。しかし、この考え方に触れたことが、私が「品質」をどう捉え、それをどう自分のキャリアの土台とするかに、決定的な影響を与えました。 今回は、このTQMという概念を通じて、私がどのように「品質」という言葉に向き合ってきたかをお話しします。 記事一覧：技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う “品質”という言葉を使うことの畏れ多さ 「品質」という言葉は開発現場でよく使われます。 一方で、「品質はなんもわからん」と口にするベテランのエンジニアや品質保証の専門家も多く見受けられます。 QAエンジニアとして「品質」という言葉を意識し始めた頃、私自身はこう思っていました。 「“品質”という言葉を軽々しく使ってしまうことは失礼に当たるし、本質を理解していないことになる」 今振り返ると、自分の虚栄心からそう思い込んでいたのかもしれません。 今でも「品質」という言葉を使う時には、多くの人が思い悩みながらも言語化を避けてきた恐ろしさ、そして先人達への畏れ多さを感じずにはいられません。 それでも、あえてその「魂」の部分に向き合い、自分なりに腹落ちさせるプロセスを経たことは、私のQAエンジニアとしてのスタンスを大きく変えるきっかけとなりました。 QAエンジニアという職能の捉え直し 現在の日本のソフトウェア開発現場において、『QAエンジニア』といえば、『テストをする人』や『テストの専門性を持っている人』を指しているのが実情です。私自身もその一人です。 しかし、TQMにおける「品質保証」という視点から捉え直すと、QAエンジニアの職能はもっと大きな範囲に広がるのではないか、と考えられるようになりました。 「顧客との間で明示的に約束しようがしまいが,徹底的に満足させてやろうとすること」 『 マネジメントシステムに魂を入れる 』p.54 TQMでの「品質保証」について学んだのはこの書籍ではないですが、私がこういった捉え方と出会ったとき、私はこの上なく自由さを感じました。私のQAとしての活動に、文字通り魂が宿ったと感じました。 そして、この目的を達成するためには、いわゆる「テスト」という活動だけでは不十分だと私は考えています。 私がSqriptsなどのプロフィールで、単なる「QAエンジニア」ではなく、あえて 「 テストに専門性を持つQAエンジニア 」 と書いているのには、実はそうした背景があります。 私はあくまで、「テストの専門性」を土台（強み）として持っているQAエンジニアに過ぎないと考えています。そう考えれば、世の中にはもっと多様な土台を持つQAエンジニアがいて良いはずだと思うのです。 プロダクトマネジメントに専門性を持つQAエンジニア SREに専門性を持つQAエンジニア カスタマーサクセスやマーケティングに専門性を持つQAエンジニア どのようなバックグラウンドであれ、「品質」という目的のためにその専門性を発揮するのであれば、それは胸を張って「QAエンジニア」と名乗ってよいのではないか。 TQMの思想に触れる中で、私はそう確信するようになりました。 品質保証を広義に捉えることの危うさ 「品質保証」をこういった広義に捉えることはある種の危うさをはらんでいます。 それは「品質保証の責務を押し付けられた」あるいは「QAが品質保証を放棄した」と捉えられることです。 現実との差分として、そういった捉え方をするのは自然なことだと思います。 だからこそ私は今まで語ってきたさまざまな専門性と接続して、建設的に、そして納得感を持ってチームに実装していく必要があると感じています。 専門性の組み合わせ 「品質」という概念を深掘りしたことによって、他の専門性との結びつきもより強固になりました。 スクラムマスター（アジャイル）との組み合わせ 「品質」という言葉の本質を捉えようとすると、「アジャイル」という概念がより鮮明に理解できるようになりました。 例えば「アジャイルソフトウェア開発宣言」で語られている価値観は、驚くほどTQMの思想と合致しています。 品質を単なる「仕様通りであるか（品質特性）」だけで理解するのではなく、「顧客にとっての価値」や「提供側としての在り方」という本質的なところから考えることなどです。 スクラムやアジャイルの実践は、単なるフレームワークの導入ではなく、「本質的な価値提供のために、我々はどう行動すべきか」という問いをより強固なものとします。品質への深い理解は、アジャイルなチームビルディングを行う上での強力な土台になると考えるのです。 テストマネジメントと品質マネジメント かつての私は、「テストマネジメント」と「品質マネジメント」をほぼ同一のものとして捉えていました。しかし今は、これらを明確に区別して考えています。 品質マネジメントという全体の中に、テストマネジメントが位置づけられる。 この視点を持つと、テストの役割がより柔軟に見えてきます。 品質を作り込むために、テストはどうあるべきか。 そう考えると、典型的には「シフトレフト」の必要性にまず気付けると思います。 あるいは、「シフトライト」や「運用でカバーする」という判断、さらには「オブザーバビリティ」を高めることや、マーケティングの視点からのフィードバックが必要になるかもしれません。 「テスト」という枠組みを超えて、様々なステークホルダーと「品質」を共通言語に会話ができるようになる。これが、品質マネジメントの視点を持つ最大のメリットだと感じています。 実務において、「品質」を脇に置くことも考える 正直なところ、実務の現場において、「品質とは何か？」といった哲学的な議論を頻繁に持ち出すべきではないと私は考えています。 定義論争は時に不毛なものになりえます。 特にQAエンジニアの実務において、個人の胸の内に留めておくということもチームを健全に前に進めるためには必要になるでしょう。 私自身、哲学的な議論が大好きです。 一方で 「私たちはどういった世界を実現したいのか」、 「そのために、お客様やステークホルダーにどういう状態になってほしいのか」、 そういったことを建設的に議論するほうが、プロジェクト、あるいは世界は前に進むことも多いでしょう。 大切なことは「顧客満足のために在りたいスタンスを取り続けられること」だと思っています。 そしてその議論の中で使われる言葉は、必ずしも「品質」という言葉でなくても構わないと思っています。 「品質」という言葉を使ってしまうと、今まで「品質」という言葉をつかってこなかったチームにとってマウントを取られた気分になりえます。 実際に私は「QAエンジニアとして品質について理解している」そういった気持ちでいたことがあります。 そんな時に、別の言葉で表現したり、脇に置いて前向きに対話していくことで、私は「いきいきとした」チームになっていく姿をたくさん見てきました。 そして、それこそが品質を扱う私の働き方の醍醐味だと思うようになったのです。 それでも品質を言語化すること 最後まで読んでいただきありがとうございます。 本稿を読まれた皆様は、「QAエンジニア」を名乗っている、あるいは目指しているのではないでしょうか。 皆さんのアイデンティティの核である「品質」、あるいは「品質保証」について、一度じっくりと考え、自分なりの言葉で向き合ってみてはいかがでしょうか。 ここであえて、私なりに品質について一言で表しましょう。「誰かがハッピーになること」です。 「品質」。 畏れ多い言葉です。 しかし、そこから逃げずに自分なりの答えを持てた時、それは「自分はなぜここにいるのか」「自分の専門性はどこで活かせるのか」という、QAエンジニアとしての揺るぎない土台になると、私は信じています。 参考文献 書籍『マネジメントシステムに魂を入れる』 ／飯塚悦功（著）、公益財団法人日本適合性認定協会（編集）日科技連出版社、2023年 やまずん、QAとしての自分の考えを表明するためのポジションペーパー https://55ymzn.com/me/positioning_paper_of_qa/ 【連載】技術を土台にして自分なりのQAエンジニアを組み立てる -あるQAの場合 【第1回】専門性をつなげて、あなたらしいQAエンジニアの像をつくる 【第2回】テストを設計する専門性 【第3回】テストマネジメントはテストマネージャーだけの技術ではない 【第4回】テストプロセス改善：思考の補助線としての専門技術 【第5回】幕間：異業種経験を土台にする 【第6回】テスト自動化：「設計原則」を知り、当たり前の技術にする 【第7回】スクラムマスターの専門性を持ったQAエンジニアとして 【第8回】幕間：「品質」という言葉に向き合う The post 【第8回】幕間：「品質」という言葉に向き合う first appeared on Sqripts .

QAエンジニアの採用・選考　どう採るどう通る？連載の第4回です。 前回の記事 では、求職者の立場から職務経歴書や面接で「採用したい」と思わせるアピール方法について解説しました。第2回・第3回は求職者側の視点での話でしたが、今回からは募集側が意識すべき、QAエンジニアの採用を成功させるためのポイントをお伝えしていきます。 QAエンジニアの募集を出しているけれどなかなか応募が来ない 応募はあるけれど、求めている人材とマッチしない といった悩みを持つ企業やエンジニア採用担当の方のお話を伺うことがあります。 市場におけるQAエンジニアの母数は開発者等に比べて少ないですし、かつ 第1回 でも触れたように、ハイレベルな人材が求められがちなので、結果として採用に苦労している企業が多い状況です。 本記事では、そのような状況の中で求めるQAエンジニアを採用するために必要な「QAに対する理解」を中心に説明します。 記事一覧：QAエンジニアの採用・選考［どう採る　どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える よくある「もったいない」パターン 私は過去に事業会社でQAエンジニアの採用を担当し、書類選考や面接を行ってきました。また、個人活動としてQA採用に悩む企業の方から相談を受けることも多くあります。その中で、「この書き方ではなかなか応募が来なさそうだな・・・」と感じる、もったいない募集のパターンがいくつかありました。 たとえば以下のようなものです。 業務内容が「テスト業務をお任せします」だけで具体性がない 必須要件が「品質評価業務の経験＊年」などふわっとしている プロセス改善や品質向上への取り組みに言及がない 「単純作業」「コツコツ作業できる人向け」などの表現が使われている 開発との協調や上流工程への関与について触れられていない 給与が開発職に比べて極端に低く設定されている テスト、評価、検証などの用語が混在している 類似のものや相互に関連するものも含まれますが、これらに共通しているのは QA業務や品質への理解が浅い ということです。 理解が浅いままだと、QAエンジニアからは「この会社はQAのことをわかっていないな」や「リスペクトが無いな」などと判断されてしまいます。理解やリスペクトのない状況に敢えて飛び込んでいくエンジニアは、あまり多くはないでしょう。（飛び抜けて待遇が良い、などであれば別かもしれませんが・・・） QAについて理解すべきこと では、QAを理解するとは具体的にどういうことでしょうか。大まかに3つのポイントがあります。 QAエンジニアの業務の幅広さ まず押さえておきたいのは、QAエンジニアの業務はテスト実行だけではない、という点です。 テストを実行するのはもちろん、テスト設計や、組織・チームにおけるテストや品質保証の方針を策定することや、テスト・QAプロセス改善、テスト自動化の推進、開発者へのテスト技術の移転、不具合分析等を通じた品質の可視化や改善アクションなどなど、QAエンジニアが担う可能性のある業務は多岐にわたります。QAエンジニアはその中で得意領域を持って開発組織に貢献したり、できること・領域自体を広げるための努力をしたりしています。 QAエンジニアは「開発の後工程でテストをする人」ではありません。 第2回 で触れた”自走できる人”というキーワードも、こうした幅広い業務を自律的にこなせる人材を指しています。プロダクトのQA活動を一貫して担い、必要であれば仕事を自分で作っていく。そのような役割を期待している企業が多いですし、多くのやる気のあるQAエンジニアはそのような期待に応えようとしているはずです。 にもかかわらず「QAってテストする人でしょ？」という理解で募集をしてしまっていては、QAエンジニア側とのギャップが大きく、採用はうまく進まないと思います。 品質文化とQAの位置づけ 続いて理解しておきたいのは、品質文化とQAの位置づけです。 QAエンジニアが重視しているものの一つに、「品質は全員で作るもの」という考え方が組織に根付いているかどうかがあります。品質はQAエンジニアだけが考えるものではなく、開発チーム全体で作り込むものだという理解が前提にあるのです。 そのため、既にQAチームが存在する場合は開発とQAが対立していない環境、一緒に良いプロダクトを作る仲間として協働している環境を求めたいところです。いわゆる「上流から関われる」「開発チームとの距離が近いor開発チームの中で働いている」といった、開発プロセスに何か意見を反映できる、品質向上のための活動が尊重されるような環境かどうかを気にする人が多いでしょう。 1人目QAを募集する場合は既存のQAチームが無い状態なので、「品質文化がありますよ」「ウチは上流から関わっていますよ」といったアピールはできません。が、QAチームの体制が整った暁にはそういった協働状態を目指したいと思っているんだ、という一つの理想像として提示すると良いと思います。 QAにとってのスタンダードな考え方を理解する もう一つ理解しておきたいのは、QA業界におけるスタンダードな考え方です。 たとえばシフトレフトやシフトレフトテストという考え方があります。開発プロセスの早い段階から品質を考えたりテスト活動を行うというアプローチで、以前はちょっとした流行り、最近よく聞くようになった言葉、といった位置づけだったように思います。しかし、今ではスタンダードな考え方として浸透しているのではないでしょうか。スタンダードとして浸透している、ということはつまり QAエンジニアの多くはその考え方を知っている・聞いたことがある状態であり （個別の賛否はあるものの）概ね皆が賛同している、取り入れたほうがいいと思っている ということです。 テスト自動化などもそうですし、上で述べたような「QAエンジニアの業務・やれることは幅広い」や「品質はQAだけでなく皆で作るものである」なども、スタンダードな考え方と言っていいでしょう。 これらのスタンダードな考え方を知っておくことは、募集文面を書くうえでも重要です。私自身、QAの求人票を見たときに、「この会社はQA界隈の考え方などを理解しているかな」と無意識に見ています。募集側が求職者の職務経歴書を見たときに「github（正しい表記はGitHub）」のような細かいミスが多かったり、自社の事業について的はずれな理解をしていては「大丈夫か？」と思ってしまいますよね。求職者から募集側を見たときにも同じです。 逆に言えば、こうしたスタンダードな考え方が反映された募集文面は、それだけで「QAのことをわかっている会社だな」という印象を与えることができます。 理解を深めるための具体的アクション ここまで、QAについて何を理解すればいいのかを整理してきました。しかし「理解しましょう！」だけでは実際に何をすればいいのかわかりません。ここからは、理解を深めるための具体的なアクションについて説明します。これらのアクションは主に1人目のQAを採用する際の活動が中心ですが、もちろん2人目以降の組織拡大フェーズにおいても適用できる方法だと考えています。 他社求人を参考に、自社のニーズを言語化する まず取り組みやすいのが、他社の求人を参考にすることです。ビズリーチやFindyなどのメジャーな媒体でQAエンジニアの求人を検索すると、さまざまな企業の募集文面を確認できます。 ここで重要なのは、他社の求人を「真似る」のが目的ではないということです。他社の求人を見ることで、QAエンジニアに期待したいことや、開発プロセスをどうしていきたいのかを適切に言語化することが本来の目的です。他社の求人はそのための「ヒント」として活用するものだと考えてください。 具体的には、業務内容の書き方や使われている表現、必須要件と歓迎要件の内容とバランスなどを参考にしながら、「自社の場合はどうか？」と置き換えて考えましょう。もちろん、他社が必須や歓迎としている要素すべてが自社に必要とは限りません。プロダクトがtoBなのかtoCなのか、モバイルアプリなのか基幹システムなのか、などプロダクトやドメインの性質によって要件は変わってきます。 似た業種や規模の会社の求人を参考にし、不要な要素は除きつつ、「考えていなかったけど、確かにこういう要素もほしいな」などの気づきがあれば取り入れる。このプロセスを通じて、「QAに何を期待しているのか」「開発プロセスをどうしたいのか」が少しずつ言語化されていきます。 実際に私がお話した、QA採用に成功した企業の方も、まずは他社の求人を研究することから始めたとおっしゃっていました。そのプロセスを通じて自社のニーズが明確になり、それが募集文面に反映されたとのことです。 QAコミュニティに触れる JaSSTやQA系のミートアップイベントなど、QAエンジニアが集まるイベントやコミュニティに参加してみることもおすすめです。QAエンジニアが何を話しているか、どんなトピックに関心を持っているかを直接知ることができます。 ただし注意点として、採用目的を前面に出した参加は避けましょう。私がお話した、QA採用に取り組んでいる方の中にも、「宣伝目的でコミュニティに参加すると、かえってQAエンジニアの間で心象を悪くしてしまうのでは」と懸念されている方がいました。これは非常にまっとうな考え方だと思います。 コミュニティへの参加はあくまでも「QA界隈の文化や考え方を学びに行く」ことや「自分たちの開発や品質保証のプロセスをよくするヒントを得にいく」ことをメインとして、結果としてつながりができたら嬉しい、というスタンスを大切にしましょう。こうした姿勢で参加することで、QAエンジニアとの自然な交流が生まれ、場合によってはカジュアル面談などにつながることもあるかもしれません。 一般にカジュアル面談では、自社に興味を持ってくれているエンジニアに対して自社のビジネスや課題感、採用にあたって期待することなどを話すと思います。しかし、採用がなかなかうまくいっていない、どうやっていけばいいかわからない、という場合は 現役のQAという立場で募集内容に対するフィードバックをくれませんか？ と素直にお伝えして、そのような意図のカジュアル面談を申し込むのも一つの手です。 自社がリーチしたい層に響く内容になっているかどうか、応募したくなるかどうか、現役のQAエンジニアの生の声を聞くことが最も確実な確認方法だと考えています。 なお、最近は複数社が合同でミートアップ形式のイベントを開催するケースも増えています。こうした場を活用して認知を広げることも一つの手ですが、そちらについては次回詳しく触れます。 社内におけるQAへの理解と、QA側の思いとのギャップを埋める QAコミュニティに触れて学んだことと、社内での理解との間には、ギャップがある場合があります。たとえば、本記事中でも説明したような、QAは品質向上に関わる幅広い業務をスコープとして考えているけれども、開発者は「テストする人でしょ？」と思っている、などです。 このようなギャップを放置したまま採用を進めると、うまくいかないことが多いです。採用が難航するだけでなく、仮に採用できたとしても早期離職につながるリスクがあります。 そのため、採用活動と並行して社内における QAや品質に対する理解 を得ることも大切にしてください。開発チームリーダーやプロダクトマネージャー、CTO・VPoEなど、とくに組織の文化を醸成したり広く情報を発信できる立場にある方から、「QAエンジニアという存在に対するイメージ」や「QAエンジニアに期待すること」を広めていただくのが理想です。こうした土台が整っていると、入社したQAエンジニアが力を発揮しやすい環境が生まれます。 もちろん、開発者やマネージャーなど他のロールの方に「QAエンジニアと同等の知識を身に着けてから採用活動をしてください」ということではありません。（それが実現できるならば、QAエンジニアの必要性があまりなくなってしまいますね。） そうではなく、誤った理解を減らし、今後入社したQAエンジニアの話に耳を傾けられる姿勢を皆がもっている状態を目指しましょう、ということです。特別扱いは必要ありませんが、QAエンジニアを品質の専門家として尊重することが大切です。これが、本記事の冒頭でも用いた「リスペクト」にあたります。 副業QAに入ってもらう 最後は、現役のQAエンジニアに業務委託として入ってもらう、いわゆる「副業QA」の活用です。副業QAに文化づくりや募集文面づくりなど、採用の土台を整える活動を担ってもらうというもので、社内の品質に関する現状把握や開発プロセスの分析、募集文面の作成・レビュー、社内への品質文化の醸成、採用面接のサポートなどを依頼することが考えられます。 このアプローチが有効な理由はいくつかあります。まず、QAの専門家の視点が社内に入ることで、募集文面が「QAに刺さる」内容になります。面接での見極めもより適切になるでしょう。また、副業QAと一緒に仕事をする中で、社内のメンバーが「QAとは何か」を実際に体験できます。これが品質文化の醸成にもつながります。そして、いきなり正社員を採用するよりもリスクが低く、まず試してみることができるという点も魅力です。 とくに初めてQAエンジニアを採用しようとしている企業にとっては、こうした形でQAの専門家と関わりを持つことが、その後の正社員採用をスムーズにする近道になるのではないかと考えています。2人目以降の採用を行うにあたっても、もし既存のQAメンバーが若手中心であれば、ベテランの副業QAに入ってもらうことで刺激や学びになる部分もあります。QA採用のためには「いまいるメンバーの、同僚としての魅力」が求められる場合もあるため、その点の強化にもつながります。 副業可能なQAエンジニアとの接点としては、前述のカジュアル面談から副業の話に発展させるなどの方法があります。ほかにも、YOUTRUSTなどのサイトでは転職希望のほか副業希望の度合いもエンジニア側が設定できるので、副業を希望しているエンジニアを探すことも可能です。 まとめ 本記事では、QAエンジニアの募集でなかなか応募が来なかったり、求めている人材とマッチしなかったりする原因として、「QAへの理解不足」があることをお伝えしました。 募集文面の表現を工夫する前に、まずQAエンジニアの業務の幅広さ、品質文化とQAの位置づけ、QA業界のスタンダードな考え方を理解することが大切です。そのうえで、他社求人を参考にした自社ニーズの言語化、QAコミュニティへの参加、社内での対話、副業QAの活用といったアクションを通じて、理解を深めていきましょう。 学ぶプロセスは、単に募集文面をよくするためだけではありません。QAについて学び、社内で対話を重ねること自体が、組織の品質意識を高めることにつながります。QA採用の成功は、こうした地道な積み重ねから始まるのではないかと考えています。 次回は募集側の課題2として、QAエンジニアの中での認知を獲得するための手法についてご紹介します。 【連載】QAエンジニアの採用・選考［どう採る どう通る］ 【第1回】QAテストエンジニア採用における募集側・求職者側のニーズと課題 ［全文公開中］ 【第2回】求職者側の課題1：求められているQA像を把握する 【第3回】求職者側の課題2：適切なアピールで「欲しい」と思わせる 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える The post 【第4回】募集側の課題1：QAエンジニアの業務や考え方を理解し、敬意を伝える first appeared on Sqripts .