今回は、ブログ記事「1人目QAの自己投影」をテーマに、1人目QAエンジニアが組織に与える影響や陥りがちな課題について掘り下げます。テスト技術の軽視やコスト調整のみに頼る危険性を指摘しつつ、QAエンジニアの増員や組織拡大だけが正解ではない理由を解説。開発者やプロダクトマネージャーをも巻き込み、組織全体が自律して品質保証活動について考えられる状態を作るための理想的なアプローチについて、イベントで寄せられた質問への回答を交えながら語ります。
📌 今回のエピソードのポイント
- 「1人目QAの自己投影」の危うさ: 品質保証のあり方をQA組織のやり方に固執させてしまうリスクや、1人目QAという強いソースが抜けた後に組織が直面する課題について考察します。
- 組織が自律する品質保証活動: QAエンジニアの存在感を高めることだけを目指すのではなく、他職種も含めた組織全体が自律して品質に向き合える状態を作る重要性を説きます。
- QA文化をじわりじわりと根付かせる方法: トップダウンでの押し付けを避け、共感してくれるチームと共に成功体験を作り、それを言語化して広げていく具体的なステップを解説します。
📕 参考文献
- 1人目QAの自己投影-誰かの”品質保証”が独立したソースへ変容してしまうとき
- ブルシットプロダクトからチームを守れ! 「顧客が本当に必要だったもの」を追求するプロダクトマネジメントを実現するぞ
- 少数精鋭QAのリアル:プロダクトが増え続ける組織で、QAはどう戦うか(GENDA Tech Talk #4)
🕒 チャプター
- () オープニング
- () 記事「1人目QAの自己投影」の紹介と共感
- () プロダクトマネジメントの事例から学ぶ1人目の罠
- () 1人目QAが陥りがちな課題(私見)
- () 質問コーナー:QA文化を開発チーム全体に根付かせるには?
- () エンディング
📢 あなたのご意見をお聞かせください
今回は1人目QAの役割や、組織全体で品質に向き合う文化の作り方についてお話ししました。あなたが考える「理想的な品質保証活動のあり方」や、チームに品質文化を根付かせるための工夫などがあれば、ぜひご意見をお聞かせください!
-
X(旧Twitter):ハッシュタグ #b_testing でのポストをお待ちしています。
-
お便りフォーム:こちらからお気軽にどうぞ。
-
フォローのお願い:最新回を逃さないよう、Podcastアプリでのフォローをぜひお願いします!
感想
まだ感想はありません。最初の1件を書きましょう!
00:07
皆さん、こんにちは。B-Testingのブロッコリー です。このB-Testing.fmは、QAエンジニア
である私、ブロッコリーがテスト や品質に対する私なりの考えを
約10分間で語っていくPodcast番組です。 先月、イベントの登壇が3つありました。
その中の1つで、登壇後の懇親会で B-Testing.fm聞いてますって声をかけて
もらいました。すごい嬉しかった なと思ってます。その方は曰く、
Podcastだとすごい落ち着いた人だな と思っていたんだけれども、登壇
を聞いてみたらすごいパッション 全開だったっていう、そういう感想
をもらいました。多分、おそらく 登壇のときのパッション全開というか
すごいテンション上がって話している のが、普段の自分なのかなと思って
るんですけれども、Podcastだと結構 一人語りをする状態になっている
ので、結構落ち着いた感じに聞こえ ちゃうんだろうなと思ってます。
ということで、今日はある記事を 読んでの感想についての話になります。
ということで、今回もB-Testing.fm スタートです。
ということで、今日はある記事 というのが、一人目QAの自己投影
という記事を読んでの感想であったり とか、結構自分も共感できるところ
が多かったので、それを話していきます。 この記事、何かというと、ヤマズン
さんによる記事でして、正式な タイトルは、一人目QAの自己投影
誰かの品質保障が独立したソース へ変容してしまうときというタイトル
になっています。これどういう 記事かというと、一人目QAエンジニア
というのが、結構キラキラした存在 だというふうに思っていて、それが
組織にどのような影響を与える のか、そしてどういう危険性がある
のかというのを書いた記事になっています。 ここからいろいろ共感できる部分
があったので、それを紹介していこう かなと思います。
まず最初に共感したところは、 こういう話です。テスターは新卒
の仕事やソフトウエア品質保障 はくだらないといった言説に心
当たりのある方もいるのではない でしょうかと。これらは事実として
起こっていました。そして多くの ベテランQAは、その圧力を乗り越え
成果を出した人々ですと。QAは 舐められてはいけない。QAは本来
高尚な仕事だ。そういったマインドセット が土台の一部に形成されている
ことは私自身もそうであり、そうい った人も少なくありませんと。これは
自分も結構そういうところはある かなと思います。高尚な仕事だ
03:03
までは思ってはいないとは思うん ですけど、よくQAを下に見られる
みたいな言い方は結構されるかな と思っていて、そこに対して何くそ
っていうふうに思うのは確かに あるのかなと思っています。続いて
一人目QAというソースが強いエネルギー でいかのように認識することがあります
QA組織が成功したのはQA組織の あり方ややり方を実践したから
だと。逆にQA組織が失敗したので あれば、それはQA組織のあり方
ややり方を実践できなかったから だっていうふうに認識することが
一人目QAっていうところだとあった りしますよと。品質保障っていう
のは本来その組織や事業において 適したものであるべきだと考えて
いますと。山津さんはそう考えて いますと。その前提に立ったとき
私はQA組織とはQAエンジニアの プレゼンスを高める、QAエンジニア
を増やす、QAエンジニアの雇用 を生むといったものが必ずしも
正解ではないと考えますと。私は その点において、組織が自立して
品質保障について考えることが できる状態にすることという立場
を取りますっていうふうに書いて いますと。ここは自分も非常に共感
をしていって、結構QA組織を拡大 するみたいな、そのためにどうやって
採用をすればいいんだろうとか。 QAエンジニアを活躍するためには
どうすればいいんだろうみたい に、そういうふうに考えがちなんだけれども
そうじゃなくて適したものである べきであって、それをQAエンジニア
がどうこうとか、QA組織がどうこう っていうところに限定する必要はない
かなというふうに自分も思っています。 なので、自分はQAとか品質保障っていう
言い方をできるだけしないように していて、品質保障活動までつけて
活動という名前もつけて話しています と。そうすることによって、品質保障
活動っていうものは別にQAエンジニア に限定されるものではないと思っていて
開発者が品質保障活動をやった っていいですし、PDMやPOが品質保障
活動をやったっていい、あくまでも 活動なのでっていう話を考えています。
そうすると、この山津さんが書いている 組織が自立して品質保障、品質保障
活動について考えることができる 状態にすることっていうのがいいん
じゃないかっていうのは非常に 自分も共感していますし、自分も
そのような考え方で進めている かなと思っています。
これは別のものですね。森 優弥 さんが書いているスライドから
持ってきました。ブレシッドプロダクト からチームを守れ、顧客が本当に
必要だったものを追求するプロダクト マネジメントを実現するぞっていう
06:01
このスライドから持ってきました。 ここに書いているのはQAエンジニア
っていうわけではなくて、どっち かっていうとPDM、プロダクトマネージャー
の一人目プロダクトマネージャー とかシニアプロダクトマネージャー
と呼ばれるような人たちがこういう ふうに陥りがちだよっていうの
を物語形式でここのスライドの 一部では書いているかなと思って
います。その中でどういうふうに 書いているかというと、シニア
プロダクトマネージャー、一人目の プロダクトマネージャーがこういう
ふうに考えるわけですね。最近 うまくいってない気がするなと。
自分自身もあんまり組織に貢献 できなくなってきた。これはもう
僕たちのフェーズではないのかも しれない。会社は立派になったし
後の人たちに任せようと。だから 自分は有名会社のきらびやかな
ポジションに今度転職しますって 言ったりしますと。そうすると
その転職した後にその転職先の 会社の同僚か分からないですけど
こういうふうに言われるんですね。 知ってます?あの会社プロダクト
マネージャーをクローズしたみたい ですと。5年前はすごい勢いだった
ね。シニアプロダクトマネージャー は言います。実は5年前まで統括リーダー
をしていたんですよ。でももう 自分がいなくても大丈夫かなって
転職しちゃってと。そうすると その同僚はそうだったんですか
と。やっぱりあの会社に不確実な 存在だったんですねと。シニア
プロダクトマネージャーはいやいや そんなことないですよ。でもこれから
も全力でやっていきますと。次は 有名企業の社外取締役になり
ますっていう話ですね。一見する とこの一人目PDMとかシニアPDMに
とってはすごいいい感じにステップ アップしているようにも見えます
けれども その一人目プロダクト マネージャーが元いた会社にとって
は一人目プロダクトマネージャー がいないから困ったっていう話
ではなくて それはむしろ一人目 プロダクトマネージャーのいる
段階で どう組織の拡大にうまく 合わせるかっていうのができて
ない部分の話なのかなと思っています これは結構一人目QAエンジニア
にとっても当てはまるかなと思 っています これは完全に試験 若干
偏見も含むんですけれども 一人目 QAで結構陥りがちなこととして
別に全員が全員そうと思ってはい ないんですけれども 結構テスト
の技術とか品質管理の技術を軽視 している もしくはあんまり意識
しないで働いてることが多いかな と思います それでどうしてうまく
いってるかというと 圧倒的な ドメイン知識とかソフトスキル
で業務を回してるんですね ソフト スキルの中には 例えばコミュニケーション
スキルも含まれるでしょうと テスト の技術がなくても こういうふう
なドメインだからっていう知識 を基にしているので あの一人目
09:00
QAの人に聞くと わかんないけど うまくいくな バグ見つけてくる
なみたいな話になるわけですよ ね これが拡大しようってなった
ときに一人目QAはそれでうまく いったけれども 二人目以降入って
きたQAっていうのは もちろんドメイン 知識はゼロの状態でスタート
するので 組織の拡大がうまくいきません よと 一人目QAの人がテストの技術
とか品質関連の技術を伝えられる 立場でもなかったりすると じゃあ
それがQAとしてうまくいかない うまく成長していかないっていう
ふうに陥りがちかなと思っています そうすると もう一つあるのが 結構
そういうような一人目QAとかだと QCDプラスSという言い方があります
ね Quality Cost Delivery それにスコープ を足したものに対して その中の
調整方法として Cの部分 コスト の調整方法しか知らないっていう
QAエンジニアは結構いるかなと思います そうすると 第一選択肢として 今
ちょっとリソースが足りない コスト 結構高数がかかって そこを何とか
調整する デリバリー リリース のタイミングは変えたくない リリース
するものの内容も変えたくない 品質はもちろん下げたくないっていう
ふうになると コストの調整方法 として 人を増やすっていう調整
方法しか知らないとかになります そうすると テスト会社をいかに
使うかみたいなのが第一選択肢 になったりとか あとは テスト
をどう減らすかっていう調整方法 として テスト技術とか このPodcast
の中でよく話しているテスト設計 技術とかを使って うまく合理的に
減らすっていうことができずに じゃあ これ どれをテストすれば
いいかっていうのは 開発者と話し合う ことで決めますと あとは 圧倒的な
ドメイン知識を使って ここは重要 層だから ここはやろうねみたいな
そういう話しか調整ができない みたいなことが結構あるかなと思
っています そうすると さっきの 森家さんのスライドみたいに この
やり方っていうのは 二人目以降 同じようにできるかっていうと
そうではないので 一人目QAが 抜けてしまったあとは さざんな
結果になるみたいなことはあり がちかなと思っていますと なので
最初に山津さんの記事で紹介した 品質保障っていうのが その組織
や事業に適応したものであるべき っていうところは そういうところ
でして 一人目QA入れます あとは 二人目QA以降はうまく育ってくれ
ればいいやとか あとはテスト 会社に頑張ってお任せするとか
っていうのは どの組織でも同じ ようにやるとかではない立ち
かなと思うし 組織が自律的に 品質保障活動について考えることが
できる状態っていうのが 今言った 一人目QAはうまくいってそう
に見えるけれども 二人目QA以降 入れたときにうまくいかないとか
組織を別にQAに限らず 組織を 拡大したときにうまくいかない
12:03
っていうところに対する対処策 になるかなと思っています
ということで 今日はこの一人目 QAの自己投影という山津さんの
記事を読んで そこから自分の中で 思いを巡らせて いろいろと喋って
いきました ここからは質問コーナー ですね これも以前 先月あった
三つの登壇の中の一つのイベント ジェンダーさんのイベントの中で
いただいた質問をもらってきて ここで答えようかなと思っています
今回の質問は どうやって開発チーム 全体にQA文化を根付かせました
かとか リードするには一人目 QAが一定の信頼を得ている必要
があると思ったより どう存在意義 を示し 組織を巻き込んでいった
のか知りたいという質問をいただき ました ありがとうございます これは
ちょっと今の自分のいる組織とか は関係なく 一般論的な話になって
しまうんですけれども 結構QA文化 を根付かせるっていうのは まず
マインドを変えるっていうところ はすごい大事だなと思っています
ただ それをいきなりトップダウン で いや QAってこうあるべきだから
とかっていうのはあんまり良くない かなと思います さっき言った山津
さんの記事でもあったように こう あるべきっていうのを強い思いやる
んではなくて 組織に合った形を 考えていくっていうのはすごい
大事だなと思っています そのために どうするかっていうと 最初から
トップダウンでQA こうあるべき っていう話をするのではなくて
まずはQAって結構 それこそシフトレフト であったりとか テスト設計の技術
とかっていうのもすごい重要だと 個人的には思ってるんですけど
そこに強化を持ってくれている 人とかチームとかっていうところ
をまずポイントを当てて そこの 部分で一緒に協業する 開発と一緒に
やっていくっていうところから 成功体験をつくっていくっていう
のがすごい大事かなと思っています それで こういうふうにやったら
うまくいきそうだな この組織でも うまくいきそうだなっていうのが
分かったら それを基にそのやっている 内容を言語化なりして こういう
ふうにやっていきましょうっていう のを 初めて他の組織にもちゃんと
伝えるようにすると そのときに それをただただ伝えるだけではなくて
こういうふうにやっていきましょう と ちなみに 今 すでに入っている
チームのところでは 実際にこういう ふうにうまくいってますっていう
のを 提案だけではなくて 実際に 成功した事例として紹介していく
っていうのが効果的かなと思っています なので 存在意義を示すっていう
ところで言うと 頑張ってトップ ダウンでやるんじゃなくて 共感
を持ってくれるところからじわり じわりと浸透させていくっていう
のが何よりも大事かなと思っています ということで 質問ありがとうございました
15:08
ではエンディングです btesting.fm では リスナーさんからのお便り
を募集しています エピソードの 感想や 私に聞いてみたい質問や
テストのお悩みなど どんなこと でも構いません 投稿フォームは
番組概要欄にあります また エピソード の感想は ハッシュタグ
btesting.banscotestingでXのポスト をお願いいたします 今日の話
で言えば 結構 一人目QAっていう 話を話してきましたけれども あるある
分かる分かるっていう話で 感想 であったりとか 一人目QAってやった
ことないけど こんな感じなんだ っていうところの感想であったり
とか 何でも構いませんので ぜひ 感想いただければなと思います
あと もしもこれからも聞きたい という方は お手持ちのPodcastアプリ
で番組のフォローもお願いします 最新回が上がったときにすぐに
気づけます 今日みたいなブログ 記事の感想的なものであったり
とか 登壇がこうだったよとか そういうのは不定期に木曜日あたり
にあげようかなと思っているので それは自分の気分次第であげる
とか 収録するっていうところも あるので ぜひフォローをお願い
したいなと思います すぐに気づける と思いますので ぜひよろしくお願いします
ということで 今回はここまでです それでは また次回
バイバイ
16:39
コメント
スクロール