00:07
皆さん、こんにちは。B-Testingのブロッコリーです。 このB-Testing.fmは、QAエンジニアである私、ブロッコリーが、テストや品質に対する私なりの考えを約10分間で語っていくポッドキャスト番組です。
最初、オープニングは、音声メディアというところに対しての、自分の一つの今の思いを話そうかなと思うんですけれども、結論から言うと、音声メディアというのはこれから来るのかもなというふうにはちょっと思っています。
自分の場合、前まではブログで自分の意見とかを書いたりしてたんですけれども、最近やっぱりブログ記事とかも正直AIっぽい記述がどんどん増えていっているなと思っていて、あとは以前のそれこそツイッターとか呼ばれていた頃には結構自分と異なる意見とかっていうのを建設的に言い合っていたなと思うことも結構あったんですけれども、
正直今のXはそういう雰囲気にならないなと思っています。そんな中、こういうポッドキャストっていうのはあんまりそんな聞いている人が少ないっていうところもあって、ある程度の好き放題言える感じなのかなとは思ってはいますし、今までだったらブログで書いていたこともこういう口頭でしゃべるみたいなことはこれからもどんどん増えていくと思うし、
あんまりこのポッドキャストの内容はAIっぽさがみたいなのはまだまだ差別化できるかなと思っているところです。今日はそんな中、言語化について話していきたいなと思います。ということで今回もbtesting.fmスタートです。
今日は言語化について話してみようと思っています。きっかけは他の方のポッドキャストですね、あらたま移行のマネジメントレディオを聞いていて、それに感化されて今日話そうかなと思っています。
その中の言語化ってみんな言うけれどっていう回なんですけれども、簡単にそのポッドキャストの放送の内容で自分がすごいいいなと思ったところをピックアップしてみたんですけれども、まず言語化は大事っていうときのその背景について考えてみると、
言語化をすることによって自分で考えていること、こういうことを考えているよっていうのをラベリングするみたいなところとか、あとは言語化して一度外に出して、それを客観視してというか俯瞰して眺めるという過程が内製につながるため、言語化は大事だよっていうふうによく言われるかなと。
03:05
で、それに対して、ただし、この新田さんがおっしゃっていた話ではあるんですけれども、言語化をして言葉にした瞬間に実は失われるものもあるんじゃないかみたいなことは言っていますと。
その中、ある意味言語化をすることによってきれいになっている部分もあるかなと思っていて、その結果、実はちょっとずつこぼれ落ちているものがあると。で、実際、内製につながるっていうところは、言語化をしたときに何がそこからこぼれ落ちたのか、言語化していない部分っていうのを見つめ直すっていうことが、実は本当の内製につながるかもねみたいな話をしました。
で、あとは場合によっては無理に言語化をしない方がいい場合もあるなみたいな話も、この2人のPodcastの中で話していて、例えばその中で話していたのは、なんか自分自身できれいに言語化できているわけではないけれども、なんか課題に感じてるんだよねみたいな、そういうのを表明してもらって。
で、それに対してその課題に感じているのって何だろうって、みんなで解きほぐしたことによってチームの課題として扱うこともべきというふうになったと。で、この言葉にならないんだけれども、なんか大事そうだなみたいな、そういうのもまだ全然あるのかなみたいな、そんな話をしていました。
はい。自分もまさにそれは思っていてですね。特に自分はQAエンジニアとしてやっていく中で、結構発する内容、発言する内容、実はその多くは結構わからないって言っちゃったりすることが多いかなと思っていて、特に開発が設計をやって、その設計ドキュメントのレビューのレビュアとして参加するときに、
あの、その設計のドキュメントの説明を聞いて、ここってこうだろうみたいな、なんかピンポイントでいい指摘をするみたいなことは実はほぼなくてですね。で、一番よく言う言葉で、なんか説明をしてもらったときに、あ、ちょっとわからなかったのね。この部分がちょっとよくわからなかったので、もう一度説明してもらえますかみたいな、そういうフィードバックというか、そういう会話をすることが多いかなと思っています。
で、そうすると、それを言われた開発者だったりとかは、あの、全く同じ言葉、一言一句違わずに同じことを言うっていうのはほぼありえなくて、大体が、あ、ここはあんまりわかってもらえなかったんだなって思って、すごい丁寧に話してもらえるんですよね。
で、これって、自分、私自身が頑張って言語化するっていう話ではないと思うんですけれども、そういうふうな話をすることで、他の人の言語化を結果的に促してるかもなと思っていて、で、それによって開発者って、より丁寧に説明しようとしたときに、
06:13
で、この部分っていうのは、例えばパターンとしては3つあって、Aっていうパターンはこういうふうに処理しようとしていて、Bっていうパターンの場合はこういうふうに処理しようとしていて、Cっていう場合は、ここはどう処理するか考えてなかったなみたいな、その人自身が気づけたりするんですよね。
で、結果として抜けとか漏れに気づいたりするっていうのはよくあることだかなと思っています。で、もう一度繰り返し言いますが、別に私は最初からそのCのパターンが抜けてるだろうみたいに完璧な指摘はできてなくて、っていうか自分もよくわかってないので、ただそこについてちょっと聞いてみることで、結果として本人が抜けとか漏れに気づけるっていうのはすごい良いことだと思っていて、
今言った話でいうとパターンCの場合漏れてたな、じゃあそこも考えてちょっと修正してきますって、多分本人が自分自身で言える話なんですよね。
で、もしも頭ごなしにパターンCの場合考えてないじゃないか、ちゃんと書いてこいって言われてもモチベーションは上がったりしない、人によってはモチベーション上がらないまま設計のレビューが終わっちゃったりする可能性はあると思うんですけれども、これ自分自身で気づいてなかったのはやんなきゃって思ってもらえればより良いレビューにもつながるかなと思っています。
今回今この話はレビューっていうのに限定していましたけれども、そういうふうに分からないっていうことって結構あるなと思っていて、この感覚をすごい持ってたのは一つきっかけがあってですね、以前の職場にいたときにですね、とある職場で開発マネージャーからこんな言葉をもらったんですね。
特に自分がそこの現場に入りたての頃とかに言われたこととして、システムのことは全く知らないかもしれないと。
開発者も質問なんか言われたことによって、特に分かんないとか言われたことによって、なんでそんなまた外れな質問をするんだとか、どうして分かんないなんて言われなくちゃいけないんだよとか、人によっては思うかもしれないと。
ただし、この分からないって表明するのは大事、大切ですよと。
その分からないというのに対して開発者が一生懸命説明することで、その実装方針になって、背景とかっていうのを説明することになりますと。
この背景を反強制的に伝える機会っていうのは、背景を結果的に聞くことになった開発経験が少ない他の開発者とかにとってもすごい良い機会だよと。
なので、この背景を知らなくて、自分とか他の開発者も知らなくて、機能をAの方針で実装するっていう場合と、そこの背景をきちんと伝えてもらって知った上で、実は他にもBっていう方針とかCっていう方針もあったんだけれども、
09:15
とあるXっていうリスクがあるから、BとかCの方針は取らずにAの方針で実装することになったっていうのを言うっていうのは、
これは別に質問やり取りしたことで、Aの方針から別の方針に変われっていう話ではないんだけれども、
そのやり取りの結果、実装方針が変わらなかったとしても、結構そこの理解度、みんなの知識、知る内容としては雲泥の差があるから、
だから特に入りたてで分からないって言いづらいかもしれないけれども、置くせず発言をしてほしいと開発マネージャーから言われたことがあります。
これすごい良い経験だったなと思っていて、なので別に分からないっていうことで何も変わってなかったとしても、
その背景とかいろいろ考えてたんだなって知るきっかけになるので、そういう意味ではここがどうこうっていうふうなちゃんと言語化をするとかっていう、
そうじゃなくてもやっぱり重要なのかなと思っていますと。
あとはテスト設計とかにおいても大切なのは言語化、明示をすることによって、
あとはそれによってこの部分はうまく表現できたんだけど、この部分は表現できないんだよねみたいな、
そういう部分を炙り出すっていう効果があるかなと思っていますと。
テスト設計を考える前とかだと、これって何かできてるんじゃない、分かるよって思っていたけれども、
ちゃんとテスト設計することで、あれここよく分かんなかったなっていうふうになることが多いと思っているので、
頑張って全部を全部うまく言語化するっていう話じゃなくて、
分からない部分を分からないっていうようなちゃんと言語化してない状態にするっていうのはやっぱり大事かなと思います。
あともう一つですね、スライドのフレーズで体験するあのチームっていうスライド、
これはXPまつりで関さんと宮さんという方が話されていた資料にはなるんですけれども、
その中でこの分かんないっていうフレーズについての考えについて話したりしていましたと。
分かんないっていうフレーズがあると、それが発することになるとすぐにチームとして、
何でこれが分からないのかっていうのをみんなが一斉に考え話し始めますよと。
大抵の場合、そこから課題とか問題が見つかるみたいな話を書かれていました。
そこのスライドの中で自分がすごいいいなと思ったのは、この分かんないっていうことは、
分かんないっていうのは自分なんだけれども、これを分からないって言った瞬間、
発した瞬間に自分一人の問題ではなくて、みんなの問題に変化するよと。
12:03
自分一人で考え込んでそれを解決するんではなくて、分かんないっていうふうに発することで、
みんなで取り組んでみんなの問題に変化するっていう、そのためのフレーズだよみたいな話をしていますと。
さっきの開発マネージャーの言葉も踏まえて、特に今多分これ公開してるの3月とかだとは思うんですけれども、
例えば4月から新卒に入社される方であったりとか、何かしら転職したりとかで新しい現場に入る人っていうのは、
ぜひどんどんこれ分かんないですねって言えるようになるっていうのはすごい大事かなと思います。
ということで、これまさにここがすごい分かっていて、ここが分かんないってちゃんと言語化しきれるとは限らない話だと思うんですけど、
この言語化してない状態っていうのは実は大切だし尊いなというのを今日は話していきました。
続いて前回とかまでと一緒に同じような感じで、実際に感想のポストをいただいてたところに対するコメント返しをしたいなとは思っています。
これはnewtowarさんと読めばいいんでしょうかね。
towarさんという方がポストしてもらっていたのが、これは第9回ですね、テストを早めに行うことの大切さの話を聞いての感想のポストをいただいてて、
シフトレフトでバグを未然に防ぐことを学校の先生がこれテストに出るって言えば、生徒が対策するのに例えているのは面白いっていう感想のポストをいただいてまして、ありがとうございます。
ここに対してっていう話だけじゃないんですけれども、結構テストって普段学んできたっていう人はすごい少ないと思うんですよね。
開発とかプログラミングとか、そういうことは例えば大学とかで学んでいる人とか結構いるとは思うんですけれども、テストとか品質っていうのを大学とかどっかしらで体系的に学ぶっていう人はすごい少ないと感じていますと。
そういう人たちに対して専門的にテストってこうだっていう話をしても伝わらないと思っているので、そうすると感情を抱いているかどうかは別としても、ほぼ皆さんが経験しているのが学校生活だと思っているんですよね。
なので、ここのテストに出るっていう、第9回だと応仁の乱の話とかしましたけれども、そういうような学校生活にまつわるような例っていうのはすごい皆さんに響きやすいなと思っているので、今も使ってますし、これからも他のエピソードの中で何回かいろいろなパターンで使うかなと思っています。
15:11
ということで東原さん、感想のポストをいただきありがとうございました。
ではエンディングです。
btesting.fmでは、リスナーさんからのお便りを募集しています。
エピソードの感想や私に聞いてみたい質問やテストのお悩みなど、どんなことでも構いません。
投稿フォームは番組概要欄にあります。
またエピソードの感想は、ハッシュタグBテスティングでXのポストをお願いいたします。
今日は言語化の話っていうところで、言語化しきれなくてもいいんじゃないみたいな話を多めに話したんですけれども、
エピソードの感想のポストとかも、何かよくわからなかったとか、きちんと頑張って言語化とかもしないでも全然いいので、
軽い感じでポストとかいただけると嬉しいなと思います。
もしもこれからも聞きたいという方は、お手持ちのPodcastアプリで番組のフォローもお願いします。
最新回が上がったときにすぐに気づけるかなと思っています。
今日ですね、最初のところでオープニングで音声メディアみたいな話をしましたけれども、
やっぱり自分のここ最近は結構このPodcastを通じていろいろ喋りたいものが増えてきて、
毎週月曜日公開の予定だったんですけれども、木曜日も結構話したり不定期ではあるんですけれども、
公開しようとは思っているので、そういうときにもすぐ気づけると思うので、ぜひ番組のフォローもお願いします。
ということで今回はここまでです。それではまた次回。バイバイ。
