00:07
皆さん、こんにちは。B-Testingのブロッコリー です。この B-Testing.fm は QAエンジニア
である私 ブロッコリーが、テスト や品質に対する私なりの考えを
約10分間で語っていくポッドキャスト 番組です。オープニングは、この
ポッドキャストについてなんですけ れども、最近、このポッドキャスト
聞いてますよ、と直接声をかけられる ようになりまして、すごい嬉しかった
んですけど、それ唐突に言われた ので、かつ面と向かって言われた
ので、すごい恥ずかしかったなという 思い出があります。ただ、じゃあ
ポッドキャスト聞いてますって言 わないでくれとも思ってなくて、
ぜひこれからリアルイベントであった りとかで、直接顔を合わせて会う
ような機会がある方で、もしもポッドキャスト 聞いてる方がいれば、ぜひ声をかけて
いただければと思いますし、その 時に感想も言ってくれると、すごい
嬉しいなと思っています。ということで 今日は、まだテストエンジニアの
価値を知らないチームに入り込む ための方法と題して、今までのテスト
の話よりもチームに具体的にどういう ふうに入るかっていう話をして
いければと思っています。ということで 今回もbtesting.fmスタートです。今回
はまだテストエンジニアの価値を 知らないチームに入り込むための
方法と、今回は出してるんですけれども 実際に自分が所属している企業
会社さんの中で、QAエンジニア とかテストエンジニアと呼ばれる
人がいませんと、これから一人目 QAとして自分がやっていくぞとか
もしくは組織として一人目QAを 取っていきたいっていうふうになる
ときに、言うてもQAエンジニアとか テストエンジニアって別にいなくても
いいんじゃないとか、いることで どういう価値があるのっていうの
をちゃんと組織として理解しき れてないときに、その価値をちゃんと
チームに知らしめるというか 伝えていくっていう方法ですね
そういうチームにまず入り込む ための方法っていうのを、今日お話し
できればなと思っています 一つ やり方としてあるものは特に
テストプロセスっていうのを自分 は最初に入れていけるといいの
かなとは思っています そのときに ただそもそもテストプロセスを
知らないチームにテストプロセス ってこういうもんですよっていう
のを前までのこのエピソード retesting.fmで話したエピソードを
元にテストプロセスってこうですよ っていきなり頭小出しに言っても
03:04
何でそんなん入れるのみたいな そういう反応が来ると思うんですね
そのためにまずテストプロセス を知らないチームにはどうしたら
いいかっていうと そのテストエンジニア を入れる価値 QAエンジニアを入れる
価値とか テストプロセスを入れ たいって思っている理由として
例えば不具合が頻発しているとか ちょっと発生しちゃすごい困る
障害が発生してしまったみたいな ちょっとネガティブな状況が何かしら
あると思うんですね それの不具合 とか障害になったものを題材にして
もしテストプロセスをここに導入 したらどうなってたんだろうって
想定して進めるといいかなと思 っています なので そのためには
発生した不具合とか障害に対して の分析ですね 不具合分析とか障害分析
から始めることが大事かなと思います その分析を始めるときに 言っても
自分自身が当事者じゃなかったり すると 結構ヒアリングをして
この不具合ってとか この障害って みたいにヒアリングすることが
あると思うんですね そのときに ちょっと注意しなくちゃいけない
っていうところがあるかなと思 っています それが何かっていう
と この後から不具合分析や障害 分析をする際のコツとして 質問
の仕方 問いかけの仕方として どうして何々をやらなかったんですか
みたいな 例えば どうしてテスト をやらなかったんですか どうして
テスト設計をやらなかったんですか とか どうしてこのテストをやらなかったん
ですか みたいな問いかけをして しまうと これ 良くないこととして
まず一つが こっちが答えを持っている ような問いかけなんですよね それ
やればよかったのにっていう そういう 問いかけになっちゃうわけ
ですよね そうするとどうなるか って言うと その質問を言われた
当事者側は すごい責められている 感覚を持つんですよね それやった
ほうがよかったのに どうしてやらない のみたいに言われてしまっている
ような気がするので すいません みたいな そういう状況になっちゃう
と 別に分析をしたいっていうのは こういうのをやればよかったん
っていうのを出すためではないん ですよね それをやらなかった理由
とか こういう事情があったとか そもそもそういうのを知らなくて
とかもあると思うんですよね そういう 話を引き出しづらくなるんですよね
どうして何々やらなかったんですか みたいな話し方をしてしまうと
じゃあ そういう場合はどうしたら いいかっていうと 不具合分析を
やるにしても 障害分析の障害の 部分を考えるにあたっても 特に
プロセスの改善につながるような 話としては もしもさっき言った
ように テスト設計とかあったら いいのに 何でやらなかったんですか
06:02
っていう質問ではなくて もう実際 に自分が もしもこのチーム内に
行ってテスト設計するとしたら みたいな過程で進めたほうがいい
と思います そうするとテスト設計 をするとしたら これで分析をして
仕様の理解をして設計をしてって やっていったときに そうすると
ここの部分がちょっとよく分かって ないんですよね みたいな不明点
が出てくると思うんですよね もしくは 既存の今まで障害が起きた
ときとか 不具合が起きたときに 作っていたテストケースと比較
したときに ここがやれてないとか やれてないだけではなく ここが
何なのかっていう不明点がいろいろ 出てくるはずなんですよね その
不明点に対して質問するっていう のが すごい大事なことかなと思
っています そうすることによって 先ほどのどうして〇〇をやらなかったん
ですかっていうのは 外からの 評論家みたいな質問の仕方に対して
もしも自分がテスト設計するとしたら ここがよく分からないので困って
ますみたいな 私がここで困ってる から教えてくださいっていう意思
表明をしてあげるっていうのが 大事かなと思います 責められている
感覚じゃなくて いや 自分 これ 答えてもらえると助かるんです
自分が困ってるから教えてください みたいな そういう問いかけの仕方
っていうのが すごい大事かなと思います そうすると ここって確かに 今 仕様書
とかだけ見ると曖昧だよねとか っていうのも お互いに納得して
チーム みんなで納得して進められる はずなんですよね そういうのを
一連の作業としてやった後に ちなみに 今 これ 後からで自分が
テスト設計とか入って そうしたら ここ不明点でっていう話をした
けれども 別にこれって障害が起きて からとか 不具合が起きてから入る
じゃなくて 先にテスト設計をやる ことによって こういう会話って
できるんですよっていう話ができる はずなんですよね そうすると これから
チームにテストの価値とか テスト プロセスとか テストエンジニア
がいる価値っていうのを いまいち 理解できていなかった人に対しても
なるほど テスト設計ってこういう ふうなコミュニケーションができる
のかっていう シミュレーション になるわけですよね 実感が持てる
ことになると思います なんで こういうふうな形をして 不具合
分析とか障害分析から入っていって テストプロセスっていうものを
ちゃんと考えてみるといいんだな テスト設計入れてみるといいんだ
なみたいな話につながってくる かなと思います ということで 今回
はこのまだテストエンジニアの 価値を知らないチームに入り込む
ための方法というか ちょっとティップス 的なことをお伝えしてきました
09:01
ここからは質問コーナーです 午後 最近のエピソードでやってるように
また今回も一つ質問にお答えしたい なと思っています いただいた質問
が 大きめの開発組織で現場から ボトムアップの組織改善提案を
求められたときに どのような糸口 や方針で改善提案を組み立てて
いくか アイデアがあればお聞き したいです ありがとうございます
自分は特にボトムアップ型の組織 改善提案というか 組織に限らず
ですけれども 今日話したプロセス を導入したらみたいな そういう
改善の提案に関して 特にボトム アップ的なところをどうやるか
っていう話なんですけれども 今日 言ったように 実際に もしも自分
がチーム内に行ってテスト設計 するなら みたいな話もそうですし
それ以外にも ボトムアップでやる ときは とりあえずこういうのやって
みたいんですよっていう提案という よりかは もう既にやっちゃった
ほうがいいと思います 実際にやって みて 自分のチームだけでもいい
から それでやってみて これで うまくいったんですよっていう
実績を作っちゃったほうがいい と思います 実績を作って こういう
ふうにうまくいったから 他のチーム でもやってみませんか みたいに
やったほうがいいと思います ちなみに こういう書籍があるん
ですね Fearless Change アジャイル に効くアイデアを組織に広める
ための48のパターンという書籍 があります その中にも163ページ
からですからね その中のパターン 柔軟にやってみるというパターン
がありますと これ ちょっと抜粋 して読みますと 新しいアイデア
を実際に実行しながら学ぼうと 実行してみて分かった長所と短所
を記録していきましょうと そこから できれば長所を定量的に計測して
十分な情報を集めて 新しいアイデア がいかに役に立つか 周囲の人に
説明するのだと そして ちょっと 飛ばしますが 単に周囲の何人か
に新しいアイデアの導入経験について デモンストレーションし そのおかげ
でどんな恩恵を受けたのかを 伝えればいいのだと 十分に確信
を持てる情報が手に入ってから 新しいアイデアをお試し期間として
導入してみるように会社に提案 しようというのが書かれています
この感覚がすごい大事かなと思 うんですね アイデアというか
改善提案っていうのを求められて こういうのを考えてます だから
全社で入れましょうとか 自分たち がいる部署で全部で入れましょう
12:06
とかではなくて まずは自分でやって みる 自分でやってうまくいった
から自分のチームでやってみる それもうまくいったから どんどん
広げていくっていうふうにした ほうが現実的にいいのかなと思
っています では エンディングです btesting.fm
はリスナーさんからのお便りを 募集しています エピソードの感想
や私に聞いてみたい質問やテスト のお悩みなど どんなことでもか
まいません 投稿フォームは番組 概要欄にあります また エピソード
の感想はハッシュタグ btesting banscotesting で xのポストをお願いいたします
今日のお話でいえば テストとか QA の価値っていうのをどう伝えれば
いいのかっていうのを 自分なり の経験なんていうか 一つ考えを
述べさせてもらいましたけれども 自分のところはこういうふうに
やってうまくいったよとかっていう のも もしあれば ぜひポストとか
してもらえるとうれしいなと思 っています もちろん単純に感想
とかでも全然構いません もしも これからも聞きたいという方は
お手持ちのPodcastアプリで番組の フォローもお願いします 最新回
が上がったときにすぐに気づける ので 大変便利です ということで
今回はここまでです それでは また次回
バイバイ
