# タイトルコール ようこそ、世界で広がるソフトウェア品質展。 このチャンネルでは、QnAエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質創出を中心に、 日々奮闘していることや考えていることを話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # 音声LT大会🔫 はい、こんにちは。今回は久しぶりの生放送なんですけれど、 音声LT大会というタイトルにしています。 鉄砲は水鉄砲のイメージで、夏の音声LT大会というイメージなんですけれど、 なんで音声LT大会やりたいかと思ったきっかけを最初お話ししようかなと思います。 で、きっかけがJustNANOですね。先日、いつでしたっけ? 7月にJustNANOというJustのソフトウェアテストシンポジウムの一番ちっちゃい、 割と気軽にライトニングトークというか、おしゃべり発表をするイベントがあって、 それが一回区切りになって最終回だったんですね。 そこでいろいろ改めて、運営の方の思いとかを聞いていて、 めちゃくちゃいいなって、LTってめちゃくちゃいいなって改めて思ったわけです。 というとこで、ふと自分だったらこのVoicyのチャンネルを使って、 LTってできるのかな?どうなんだろう?というのを試したくなったというのがきっかけだったりします。 結構その登壇系とかって、スライドを用意してとか顔を見ながらとか話すことが多いので、 もちろんオンラインオフラインありますけれど、それがどうなんだろう? 音声だとそもそも成り立つのかどうかっていうところ。 スライドだからこそ伝わる部分もあるだろうし、 どうなんだろうな?それが果たして音声でも成り立つんだろうかっていうのを ちょっと今日は検証してみたいなと思って企画をさせていただきました。 ということで、森崎先生がせっかくいらっしゃっているので、 ちょっと登壇の方に挙げたいと思います。 ゲストとして招待をします。 こんにちは。 こんにちは。よろしくお願いします。 よろしくお願いします。 今回参加しますって言ってくださってめちゃくちゃありがとうございます。嬉しいです。 ゼロ人と伺って、ゼロ人であれば邪魔にはならないはずと。 邪魔どころか、スペシャルゲストです。ありがとうございます。 いつもと違う端末でいつもと違うネットワークから入ってて、 ちゃんと音は出てますかね?自分ではチェックできるんですよね? バッチリ音聞こえております、クリアに。 よかったです。 森崎先生、今日はどんなトピックを考えていらっしゃるんですか? 学び。 初対面じゃないですけど、初対面のくせに偉そうな、 おじさんムーブを発揮してるんですが、 一応さっき、 いいですか、ダラダラ喋ってていいのかな。 他の方も喋るってなったら邪魔になっちゃいそうなんですけど、 5分で喋るって結構難しいなと思って、 素手でというか何も準備せずに行こうと思ってたんですけど、 アプリのインストールがいるとかアプリがインストールできるデバイスってどれとか、 2、3トピックを用意して、 5分が来たらやめるっていう準備をしてます。 内容はQAとか未然防止とかの効果ってなかなかみんなに理解されないというか、 やってることがそもそも正しいのかどうかもわかんないし、 上手くいったとしても割とその人の中、あるいはチームの中で閉じちゃって、 なんかフラフラしてる人だなみたいな話になりがちだなっていうのが一つ。 もう一つは、最初にこういうつもりでやっていこうと思いますっていう、 作り物もそうなんですけど、品質の合意ってあんまり早い段階でされてなくて、 そんなの作るとすごい大変なんですけどっていうのが後から出てくるなっていう話の2つぐらいで、 具体例を入れながら引き延ばしたりしつつ、5分で終わらせるっていうそんなつもりで望んでます。 ありがとうございます。 そしたら、最初5分枠で1つ目の方ぜひお聞きしたいなと思ってレビューの効果みたいなところで、 その後、私も少し1個ネタを用意したので、複数チームの今QAというかテスト担当やってるので、 そこでの学びみたいな、悩みみたいなところをお話ししようと思ってて、 あとはですね、飛び入り?飛び込み?あれ?飛び込み? 参加でも全然構わないので、もしどなたかいらっしゃればその方に話していただくし、 いらっしゃらなさそうだったら、森崎先生の2個目の品質の合意の方にお話しいただこうかなと思います。 では、1個目のレビューの効果ですかね。お願いします。 もうちょっと広い話で、テストとかもそうだし、そのレビューより前に自分で何かコードを書いてる人たちであっても、 そもそもこれ問題が起きそうだから、いい感じで対処しておこうという頑張りとか未然防止ってすぐ消えちゃう。 効果は高いと思うんですけど、なかなかそれを効果を示すっていうのは難しくて、 どっちかっていうと逆に問題が起きてから、この問題は僕に任せてくださいって解決した方が、あの人は頑張ってるなってなると思うんですよね。 テストも割とその傾向があって、誰が見てもこのテストはやらねばならんっていうところに関してはそんなに問題がない気がしていて、 そこを工夫してもそういうもんでしょってなりがちな気がしてます。そこが一つ課題かなと。 一方で作り物のもともとのプロダクトとかコードとか、機械設計の製品とかもそうだと思うんですけど、 もともとよくできてるものに関しては、QAが頑張ったところで、追認してるだけでいい感じでできてることを確認しましたっていう感じになって、 悪いって言うとよくないな。品質があんまり良くないものが作られてる上に、QAもちゃんとしてなかった時だけ問題が露呈するという感じがしていて、 この辺のどれぐらいの時間と手間を投じて、ちゃんとテストやるかっていう、特に作り物の品質が十分でないときに、どれぐらい頑張るかっていうのをみんなで話し合ったり、 もしうまくできてるっていう感触があれば、どんどん手を抜いて、さっさとリリースして、そういうのが許されるところではさっさとリリースしたらどうかなって思ったりするんですよね。 それが僕の1個目のトピックなんですけど、だけどどこにそのバグが潜んでるかはわかんないし、そもそもそんなの見極めるってそんな簡単じゃないし、そういうのができるといいなって思ってます。 多分流行りの生成アイとか使って、ちょっと適当にスモークテストじゃないですけど、簡単なやつやってみてって言って、何個かバグが見つかりましたってなったら、じゃあ本腰入れてやりましょうかってなるし、そこでそこそこ成績が良ければ正常系みたいな、ごく当たり前のところに関しては少し手を抜いてからやりましょうみたいな、それぐらいしかできないのかなと思いながら、ここ2、3週間それをぐるぐる思ってました。 LTになってますかね。5分ちょうど過ぎて締め切られて、残念、僕の一番痛かったところはここでしたとかっていうのが、対面LTとかだと面白いんですけど、ちょっと音声だけだと難しいなって思って。 確かに。ありがとうございます。大体3分、2分半かな、3分ぐらいかなと思います。どうしようかな、せっかくだからコメントというか、これでお話しするのが少し良さそうかなと思ってまして。 確かに、お話を伺ってて良さそうという印象はありつつ、どうやったらいいんだろうっていうのはまだ全然イメージが今湧いてないんですよね。 でも、ちょっと伺ってて思ったのは、うまく言語化できてないんですけど、これとこれと、ハッピーバスとか一番守りたい、担保したいオペレーションだったり動作みたいなところと、 プラスちょっと意地悪系というか異常系だというのか、そこら辺を少し確認をして、そんなときに出てきた不具合のセビリティというか、結構根本のヤバそうな不具合なのかそうじゃないのかというところで、 先ほど森崎先生おっしゃってたみたいに、手を抜いて、このくらいの不具合だったら出しちゃって良さそうだよねっていうふうに判断をしてしまうとか、ちょっとこれかなり今回のコア機能とかコアロジックの部分での不具合が出てきちゃってるねっていうことであれば、ちょっともう少しテスト集めにしようねみたいな、そんなことはできるのかもなというふうに伺ってて思いました。 はい。で、多分その適切なテストを思いついたり、適切な評価をしたりレビューをしたりっていうことよりも、ここにこういう問題があると最終的に使ってる人とか関係者にどれぐらいのダメージを与えてしまうかっていうリスク見積もりがそのQAの仕事の本質的なところになっていくというか、そこが割と希少価値のまま残っていくんじゃないかなっていう気がしてまして。 うーん。 で、多分そういうのって何とか技法でカバーできない気がしていて、もっとそういう、何でしょうね、リスク見積もりとか、当たらなさそうなんですけど、割とエキスパートの人だとこの辺が危ないとこの辺も危ないよねとか、これってちょっと不吉な感じがするねっていうのが勘なのか、ここも難しいんですけど、 単に言ってるやつがたまたま当たってるのか、確たる証拠を持ってそう感じてるのか全然わかんないんですけど、当たってるとするならば、そのリスク見積もりっていうのがQAのスキルの中では相当価値が高くて、全体感を持ってこの辺はちょっと力を入れて、この辺はちょっと力を抜くみたいなやつができると、何でしょうね、効果が可視化できるのかなと。 直接コストとかお金に響きやすいと思うので、外れるとめちゃくちゃ怒られそうですけどね、この辺は手押しでいいですよって言ったらバグだらけでしたみたいな、お客さんめっちゃ怒ってますみたいな感じになると、すごいまずいと思うんですけど、多分そういう、そんなにそういう話ってたくさんされてないと思うんですけど、お金とか直接聞いてくるとこなんじゃないかなって思うんですよね。 たくさんやるのは、もはや誰でもできる、誰でもじゃないな、それなりのレベルのスキルを持っていればできちゃうっていう感じで。 いかにやらなくて大丈夫ですと、度胸ではなく勘ではなく、多分いけるって確証を持てるかっていうところが、これからのスキルなのかなと、いくつか共同研究してるところがあるんですけど、その辺のお話を聞いて感じました。 ありがとうございます、確かに。リスク見積もりめっちゃ大事ですし、私はスタートアップだったり、ベンチャーでの経験しか長いので、リスクはがっつりリスクアセスメントとかの、全然できてないんですけど、一応リスクの高いところ、ビジネスインパクトの大きいところから優先的にテストしましょうみたいなところとか、 ここまでやったらもうちょっとこれ以下のこういう不具合とかあるかもしれないけど、それは許容してねみたいなことはやってるので。 いや、そっちの方が多分リスクが高いと僕は思ってまして、ゆっくりやってると市場から追い出されちゃうじゃないですか。競合がゼロだったら全然OKなんですけど、だいたい競合がいるので、そうするとゆっくりやってちゃんとやりましょうとか言ってる間にシェアを取られて終わっちゃうっていう可能性は結構高いので、 他の分野、一番高いとは思わないですけど、他の分野よりも割とQAのさっきのリスク見積もりの腕は見せどころの職場なんじゃないかなっていう、そんな感じがしてます。 はい、ありがとうございます。 それまで今日はこの話は選んだっていう感じですかね。もっと重厚頂戴系のテストの話も一応あるんですけど、それはここでしてもしょうがないかなっていうので。 はい、ありがとうございます。 自分がこれまでやってきたよりももっとスピーディーにリスクを見積もって、ちょっと少し軽くテストして、大丈夫そうだったらもう出しちゃうっていう感じなんですかね。 多分、ユーザーとか環境とか使う側のダメージとか、それを見積もるっていうのが一つ大きくて、そもそもそれがちっちゃければ、許容範囲とか笑って済ませられてもらえるみたいな感じだったら、そこはとんでもないもの以外は大丈夫ってなると思うんですよね。 特定のユーザー層でそこそこ、そのプロダクトを持ちのとこだと、このユーザー層がダメージを受けると、プロダクトとしてはまずいっていう、そのプロダクトとユーザー層の関係で決まるようなとこもある気がしていて。 ユーザー層は少なくても絶対守らないといけない。例えば個人情報漏らしましたみたいなやつだと、クレジットカードの情報全部ばらまいてしまいましたとかなるといろいろめんどくさいので、そこはしっかり頑張るみたいな感じで、まずユーザーとプロダクトの関係で決まるのかなと。 開発の担当の方にも癖があったりとか、部門の分かれ方でこういうタイプのそこが発生しやすいみたいな、そういうのもあるような気がしていて、次はその開発の体制とか作り方みたいなんで決まるっていう感じがしていて、その先もなんかありそうなんですけど、僕その2つぐらいしか今のところは思いついてないって感じですね。 はい、ありがとうございます。面白いお話でした。ありがとうございます。じゃあ次、私のターンいきます。私からはですね、複数チームのQAというかテスト担当みたいな話をしようと思ってます。 先に言っておくと、あまりこうしたらいいみたいなところまではまだいけてなくて、7月こうだったな、こういうのやっぱ悩ましいなという、それ自体が学びだったんで、その話をしようと思ってます。 今ですね、ざっくり開発チームA、B、Cとあって、規模的には中と小と極小みたいな感じです。もともとはそのAとBのがメインで新機能とか作ってたので、1人自分がメインに入っているのと、あともう1チームの方はチームメンバーの方が、Kチームのメンバーの方が担当しているので、それのサポートみたいな感じで入ってました。 さらに7月はプラスその3つ目のチームで新機能かな、それこそ素早くリリースするぞみたいな機能のプロジェクトが立ち上がって、そこに一旦私入りますみたいな感じになったんですけど、困ったことっていうのがあって、やっぱりミーティングの時間が結構取られてしまうとか、 あとコンテキストスイッチで、この機能のAチームの方のやつがどこまでだったっけとか、仕様の詳細とか、あと結構デザインが変わったりとか、仕様変更が結構入ったりするので、それのキャッチアップがだんだん追いつかなくなっていく3つのチームの分をやる。 もちろん自分メインやるのは2つなんだけど、もう1つか2つなんだけど、そのもう1個の方もQAチームのメンバーの人が作ったテストの設計とかのレビューをするので、そうなるとその仕様の内容とか最新の仕様とかを理解してなきゃいけなくて、そこがなかなかキャッチアップしきれなくなっちゃって、そのインプットしてる情報の濃淡がついてきちゃって、だんだんちょっと浅くなってきちゃったっていうのが、 7月に久しぶりに3チームとか数の多い機能開発を見ることになって、すごいやっぱり大変だなみたいな、その前の全職の方でも、全職の時は6チーム持っていてもっと大きくて、なので6チーム全部は見れないので完全に、その中でも特に今気にした方がいいチームだったり、プロジェクトだけ1つピックアップするぐらいだったんですけど、 その辺は久しぶりに3つのアンキングを追っていこうってなった時にめちゃくちゃ大変だなというのが今なので、さて次どうしようかなっていうのを考えてるところですという感じです。 なのでどうしたらいいはないんですけれど、やっぱり複数のチームに対してどうアプローチしていくのか、エンジニアだったりの人数が少ないという中でどうアプローチしていくのか、やっぱり難しいんだなっていうのを改めて感じた7月でした。以上になります。 じゃあ先ほどいろいろコメントいただいたんで、私もそれから次の方がいらっしゃるかを確認するか、どっちがですかね。少しコメントを。 はいコメントお願いします。 いや難しいですよね。まずたくさんインプットしないと、そもそも何ですかね。ちょっと待ってくださいね。多分QAって難しいのは、何か作業が切り出しにくいっていうか、全体を理解してなかったり細かいところまで把握しないとできない仕事が割と多い気がしていて。 行動確保とか仕様も決める方も割と全体感が必要だと思うんですけど、行動確保ってこういうふうにインターフェース決まってるからその実装をよろしくっていうと、わからないなりにもなんとなくできそうな気がしていて、当然全部わかってる方がうまくいくんですけど。 QAがちょっと一部だけ知ってるってなると、漏れちゃう。よりリスクの高いところとか、より問題が起きそうなところとか、つかめないですよね。だからこの一番そういう仕事しておられないと、さっきの話を聞いて思うんですけど、 この仕様に対する普通のテスト考えてくださいとかっていう仕事だと、別に切り出してここだけよろしくとかできそうなんですけど、それだと足りないんですよね、多分ね。それも大事なんですけど、それだけやってて全体がうまくいくかっていうと、それぐらいだと作ってる方が自分でチェックしてもそれぐらいできる感じ。 そうですね、確かに。 そうですね、なんかストーリーごととか、今だいたい1週間スプリントとか2週間スプリントで回してはいるので、それぞれのストーリーとかに対してのテストは受け入れ条件を作るし、それぞれの機能テストとかも作ったりはしてるし、それはそれでやってるんだけれど、 じゃあ果たしてトータルとしてというか、ストーリーとストーリーを超えるものだったりとか、なんか全体的なのかな、の確認とかってなると、やっぱり全体を分かってないといけないし、それぞれの詳細も分かってないといけないしって感じなんですよね。 そうですよね。だからストーリー間の整合性が取れてないとか、これは確か便利だけどこっちからのパスが全然考えられてないとか、なんか多分、全てじゃなくていいけど、このスプリントのストーリーだけ分かってるから大丈夫ってやつは、QAが入ってやるほどの仕事かってなりがちな感じがしますよね。 またその専門家というか、僕QAの方々が多くの方に感じるのは、少ない情報からも、プロダクトとかシステムとかソフトウェアとしてどんなふうに動くべきかとか、ユーザーはこういうときどう操作するかみたいなところの想像を膨らませる方が、違うな、膨らませるのが上手な方が多いっていう印象で、それが素早いっていう感じがするんですよね。 それだけ読んでそこまで分かるんですねっていう感じがしていて、逆にコード書く方とかだと、そこから全部そこまで、その細かい手順まで全部思い浮かぶんですねっていうところがすごい気がしていて、両者割と、両方持ってる人もいると思うんですけど、そんなに重なりが多くない気がしていて、掛け持ちしちゃうとそれが結構そがれやすい気がしますね。 そうですね。前、6チームあるときは最初はそんなに見切れないからって言って、1プロダクトしか私は見ませんみたいなことをやって絞ったんですけど、もう一回それをやるのか、もうちょっと別のアプローチというかチャレンジができるのかはまだちょっと悩み中ですね。 一応システムを分割したりなんとかっていうときに、いわゆる疎結合にして、こっちで変なことが起きてもこっちに影響しないようにしてくださいねみたいな話はあって、一定の効果ありそうなんですけど、だからといって他のとこ全く知らなくても大丈夫ですって言うほど簡単でもない気がするんですよね、特にQAは。 そこが人類の限界を感じるというか、規模がでかくなるとしょうがないなみたいな話なんですよね。 一つ妄想してたのは、記憶力悪いので、その記憶を生成アイなのか、マイルドルームに頼るみたいなのはできるのかなと思って、妄想はしていて。 PRDとかUIデザインの資料とかをインプットできると思ってて、そこをどうしたらいいんだろうな、それをうまく活用して、もしかしたらデビューをしてもらうのか、 それこそテスト分析とかテスト設計の叩き台を作ってもらうとかで、それは作業の省エネはできるかもしれないけれど、コンテキストスイッチの問題とはあまり関係ないのか、というのは少しもやもやと考えてたりします。 記録に残ってないとか、触ってもわかんないっていうところを、他の作業をしているチームの人の手を止めずに理解できるっていうぐらいが、なんとこの生成アイのいい感じのというか、期待しすぎないというか。 あれと今、僕も含めて、人類全般に生成アイに期待しているお金が入っている感じがするんですけど、ここから多分こういうのができないとか、これは実はできてなかったみたいな、だんだん明らかになっていく気がしていて、ようやくとか元ある情報を形を変えてご説明しなさいというのはめちゃくちゃ得意なので、 どっかのドキュメントに書いてあるけど、よくわからないときに問い合わせて聞くみたいなやつはすごい得意だと思うんですよね。そこに使うと、効果が上がるというよりは効率が、スピードが上がるっていう感じが、よりいい感じにできるっていうことは、元に書いてあるやつ以上のことはあんまりできない気がしてて、そういう発展があるといいなと。 ブックスの法則っていう、プロジェクトの終盤に人を投入しても、その後から来た人への説明に時間が取られて、本来作業できる人の作業を止めちゃうから、スピードが上がりませんみたいなことが言われてるんですけど、それがもしかして多少改善するんじゃないかなっていうふうに期待してるんですよね。 今伺ったお話は、それとの共通点は割と大きいかなっていうところと、本当はテストまで整合が全部やってくれるとか、なってくれると、こっちはリスク見積もりだけやればいいっていうことになるので、そんな理想の世界もやってくるかもしれないんですけど。 今の状態、結構ここ1年で相当上がったと思うんですけど、やっぱりまだ考えて実行するっていうのはちょっと重いかなっていうなんでしょうね。できそうに見えてできなかったときにこっちが、人間側のダメージがでかいっていうか、これ全部自分でやるんかみたいな感じになっちゃうので、そこは割とでかいかなっていう感じですね。 そうですね。そのあたりが解決できるとすごいなと思います。 そうですね。 あとはですね、今の続きではあるんですけど、プロリクの修正内容とかを自然言語で解説してもらえる。 だいたい今ってどういう修正をしたんですかっていうのを本人に聞くことが多くて、そこの時間を取らないみたいな作業のお話で、せせやに代わりに解説してもらうとかっていうのは活用としてはできそうだなみたいなのは考えてたりします。 それ良さそうですね。多分変更、波及、解析みたいな感じで、ここが普通に考えるとチェックしない、確認しないといけないとこだけど、こっちにも波及してるかもしれませんよとか言ってくれるとすごいですよね。 そうですね。そこまでいけるのか。 ソフトエンジニアリングの研究では、その生成AIが出る前からプロリクのコードの差分を与えると説明を加えてくれるAIみたいなやつは、5年か6年ぐらい前からいろいろやってて、どれも失敗してるんですけど、成功してると必ずVisual Studioとかに必ず機能として搭載されるので、 これにないかったり知らなかったりするってことはうまくいってないんだなっていうふうに、これちょっと録音されるとそういう研究されてる方もいらっしゃるんであれですけど、聞かないから大丈夫かな。 そういう取り組み自体はあって、基盤ができてたりとか、これができると性能上がりましたねっていう性能評価のベンチマークデータとかも用意されてるので、そこがうまくいくと発展の何かブレークスルーがあるとバーンとうまくいくポテンシャルがある気がしますね。 聞かなくていいとか、そもそもコミットする方も書かなくていいっていう、そのあたりが効く気がしますね。書いた人は細かいところは理解してるけど、読む人はもっと前段の大まかな話を書いて教えてほしいみたいな感じになりがちなんで。 それは割とせいせい合い得意。ふわっとした概要を説明する人は割と得意な気がしますね。 確かに。修正内容からそれを自然言語でこういう修正しましたとか、そういうので書いてくれたら楽そうです。 ありがとうございます。では3つ目のトピックと言いますか、飛び入り参加でLT話したいよとか、別にLTと思わずにちょっと声出したいよっていう方いらっしゃいませんか。 アプリで参加されている方を多分挙手するっていうのがあったような気がするので、ちょっとアピールをしていただくとですね、こちらでゲスト登壇できるかなと思いますけれど。いかがですかね。どうだろう。 いなさそうかな。 話したいとこありましたらお便りでも話したいとか。あれかお便り。名前が出るっけな。 いらっしゃらなさそうなので、3つ目はまた森崎先生にバトンを渡したいと思います。 いいんですかね。僕が手を挙げるときって、何ですかね。手を挙げようかなって迷っている間に手を挙げる期間がなくなって、手を挙げられなかったみたいな感じが僕が持っている。 もう少し待ちましょうか。 なんか無音で待つのもしんどい感じはしますが。 そうなんですよね。 だらだら話しているうちに2分ぐらい経ったらもう1回伺うみたいな感じですかね。 ありがとうございます。 それを僕のさっき準備してた話にしちゃえばいいんですよね。 メモが。 どこいった。 あったあった。 よくこういう機能を作ると、これ結局作るのも大変だし評価するのも大変で、結局誰の価値にもなってないから、そもそも作るのやめましょうみたいな話がだんだん増えていっていて。 そういうなんかこれって僕、作る側の話に意味にされがちだと思うんですけど。 QA側とか評価側の話でもある気がしていて。 作るのは簡単だけど、特に作るのは簡単だけどテストするのがすごい大変みたいなやつがある気がしていて。 そこに関してもうちょっとこれは作るかどうかは他の人が判断してもらっていいですけど、例えばプロダクトオーナーに判断してもらっていいですけど。 評価の面で言うとこれって結構大変で、それに見合う価値をユーザーに届けられるのかなっていうのは、QA側からもっと声を大にして言ったほうがいいんじゃないかなって思うことが多いです。 そこをみんな、僕の周りに僕のようなずずしいやつ飲んでみなさんをおとなしくされててそう思うだけかもしれないんですけど、それは自分たちで決めることじゃないからってなって、材料もあんまり出てないっていう。 決めるのは別の人でいいと思うんですね。自分たちで決めてもいいと思うんですけど。だけど材料が出てないっていう、そんな印象があって。 もっと何ですかね。2分経ったかな。まあいいか。よく地下鉄とか電車の自動改札機って、切符が入るやつと入らないやつがあって、切符が入らないやつって切符を飲み込むところの故障が多いから、駅側からこれ故障が増えるんで切符入らない形にしてくださいって鉄道の事業者側から出てるみたいなんですよね。 それって多分メンテナンス、ちょっとテストの話とは少しずれますけど、メンテナンスが大変じゃないやつの台数を増やしたいっていう話になっていて。普通に考えれば、どの改札からでも切符が入るようになってれば、お客としては便利だからお客さんに便利になってもらいましょうみたいな感じで、作る側の話が強いとそうなっちゃうと思うんですよね。 メンテナンスする立場からすると、どれが壊れるか分からないし、故障率高いからやめてほしいっていうのを、うまく実運用に取り込めてる気がするんですよね。テストに関しても多分それは言えるはずで、運用ではないですけど、これ全部テストすると結構手間がかかるし、ここを変更されるとこっちもまたデグレードの確認しないといけないとかってなって手間がかかると、 ちょっとこれって本当に作る価値を、作る手間に対して得られる価値は十分なんですかねみたいな話があってもいいのかなっていうふうに思ったりします。 その価値をどこに置くかっていうことなんですかね、価値なのかな。 多分作るための手間っていうのはコードを書くだけじゃなくて、マニュアル作ったり評価をしたり、あと何があるんですかね、もろもろいろんなことをしないといけなくて、そのトータルコストが一般には作る手間とそれ以外の手間も大体相関してて、作るのが大変だと評価するのも大変っていうのが多いと思うんですけど、 作るのは簡単だけど意外と評価が大変とかサポートが大変とかってやつもたまにかな、わかんないですけどいくつかはあるはずで、そういうときにあんまり作る側の意見が通されちゃうような気がするんですよね。 そこはちょっと多分野に行くと、ITの歴史が短いっていうのもあると思うんですけど、他の分野だとこういうのつけちゃうとすごい故障率上がっちゃうし、そもそも設計時点で評価するのが大変だからやめませんかみたいな話は結構出るみたいなんですよね。 あんまりソフトウェアでのイメージがついてない、まだついてないですね。 割引機能をつけましょうみたいな話で、割引をどんどん複雑にしていくっていうような話があると、割引のテストどんどん増えていくし、割引ほどプロダクトとしては上がりが少ないというか、いただけるお金が少ないにもかからずこんな複雑なことをしていいんでしょうかと。 割引っていうのはもう一種類だけでいいんじゃないですかっていうような話を、その仕様を変えていきましょうっていう話をしてもいいんじゃないかなと思うんですけど、僕がお話を伺う範囲だと、ゼロではない、全然ないと思うんですけど、そんなに多くないんですよね。 こういうルールを作って、こういうプログラムを書けば割引できますよみたいな話。作るほうの話になっちゃいがちですよね。平日割引、子供割引、深夜割引みたいな感じでどんどん増えていくと、どんどんテストが増えていくっていう感じで。 そのあたりって本当に評価が大変だけど、プロダクトの価値を上げてるのか。割引するとユーザー数が増えて、結果として全体のお金が増えるのか、入ってくるお金が増えるのかみたいな議論が抜けちゃうことがあるような、そんな感じがしてます。 全然2分に収まりますね。 本当だ。 スタートアップとかベンチャーとかのほうが、それは多分厳しくて余計なものを作ってる場合じゃないっていう話になりがちなんじゃないかと思うんですけど、余計なものっていうところにこんなにたくさんのテストが必要になったり、何か機能追加するたびにデグレードの確認の範囲が広くなるっていうのは、あんまり良くないんじゃないですかっていう話はあってもいいんじゃないかなっていう、そんな感じですかね。 あー、確かに確かに。 私自身の話ですけど、この機能やめません?みたいなのは言ったことがありますね。 今毎週アプリのリリースの前に全体の機能の確認のリグレーションテストをやってるんですけど、やっぱり新機能が増えていくとどんどんリグレーションテストの数も増えてきちゃってっていうのがあって、その中で見ていて、この機能って今ほとんど使われてないですよね、とか入口閉じません?みたいなのは言ったことがあるし、閉じられたものもあったりするので。 それです、まさにそれです。 もしかしたらできてる、今部分的にはできてるのかもしれないなと思いました。 多分そこの材料を提供するのもQAの仕事なはずで、だからやめましょうとやめる決定権があるかどうかは一旦置いておいて、これ大変だとか。 一方でテストコードをちゃんと書いてる人たちがいるところだと、そこは割と加味されるんですよね。 それってテストコードのメンテナンスが大変そうなんで、それってやめませんか?みたいな話は割と起こりやすい印象でして。 だけどQAの方がやるテストに関しては少し重みがそんなにかかってないなって思うことがある。 いや、あんまりそういうふうな小説を読みました。 でも確かに、職場の雰囲気、文化、あと開発とテストチームの距離感みたいなところも含めて、結構関係性によっても違うのかもしれないなと思いました。 それが一番大きいファクターな気がします。その後に今みたいな話ですかね。 はい、ありがとうございます。 でも45分くらいにはなってきたので、ネタが切れました。ネタが切れたので、全然違う話しようかなと思っていて。 森崎先生も最近ボイシーでチャンネル開設されているので、その辺どうかなっていうのを普通におしゃべりしようかなと思いました。 はい。 何ですかね。いや、思ったよりは僕の所老のおっさんの声を聞きたくないっていう人が多いんじゃないかなっていう。 どうも知られてないっていうのと、もし聞いてもしょうがないんじゃないかなっていう。ニヤニヤしながら喋ってるなこいつみたいな感じになってるのかなっていうのが印象で。 やっぱりサミンさんみたいにその、淀まないですよね、喋りがね。喋りが淀まないっていうのと、これはちょっとおじさんとしてはあれですけど、声がいいんじゃないかなって思うんですよね。 いやいやいや、全然そんなことないです。 それに比べると僕なんか咳払いめっちゃするし、なんかなってるんやろなみたいな感じになるのかなと思って。 その始めたきっかけは、そのブログとか書いてるやつをこう、わざわざ読むのめんどくさいから走ってる時とかに聞きたいんですよね、映画。 それがその、あるところで、どれくらいにも結構な人に言われたんですよね。今の僕のボイシーのフォロワーより多い人数で言われた気がして。 お前ら結局聞いてないやんけって僕は思ってるんですけど。そこがちょっと黙呑みが外れてるって感じですかね。 毎日更新とか相当僕にはハードルが高くて、そんな難しいなっていうのと。 佐々木、元かな?分かんない。今フリージャーナリストっていうか、結構なフォロワーの方いらっしゃるじゃないですか、ボイシーの中で。 僕、佐々木なんとかさんっていう、普通にこう、元新聞社の方かな。おじさんがいるんですけど、その方の話とかを聞いてて、その人、毎朝更新されるんですよね。 たまにこう見つけて、この話聞いてみようみたいな感じで、そういうコンテンツの多さというか、いっぱいある中から選んで聞こうみたいな感じにならないと、なかなか難しいなっていうのが、今の感覚です。 ありがとうございます。そうなんですよね。なんか最初の3回の、壁があると思ってて、継続の壁じゃないですけど、最初の3回の次が出ない人がいているのと、あとそうですね、何ヶ月かみたいなところ、数ヶ月がそこを超えられるかっていうのは結構、壁があるんだろうなっていうのを思っているのと。 僕、社長の尾形さんとかも言ってるんですけど、音声は最後まで聞けるかというか、動画とかと違ってインパクトがないので、そこが難しいよねっていうと、認知してもらうのがちょっと難しい。 絵があるものと比較すると難しいかもね、みたいな話とかはあります。周知は確かに結構、認知してもらうとかは大事かもしれないです。 そうですよね。紙のやつチラッと見たら何万回とかって再生されてて、すげえなとか思ってたんですけど。 放送の数が増えていけば増えていくので。 その継続ですよね。 継続は1個あるかもしれないですね。 私も最初は母子の発信というか毎日やるぞっていうのを決めて、3ヶ月ぐらいはかなり努力をして自分の習慣に入れる。 朝会の後に収録の時間を取ってて、収録が終わらないと仕事が始まらないっていう風にしてたんですよね。 そういう風に無理矢理時間を作って、最初は時間を取ってたんですけど、3ヶ月ぐらい経つと歯磨きと同じぐらいな感じになって、やらないと気持ち悪いみたいな体質になれば後はもう勝手に継続できるので、そこまで続けられるかっていう。 ちょっと突きつけられた感じがして、ちょっとだけ折れた感じがします。 折れちゃ困るんですけど。 でも毎日である必要は全然ないと思っていて、そこは自分で継続できるサイクルでいいと思いますし、 別のチャンネルだとQAゼミチャンネルっていうチャンネルがあって、 メンバーで、QAゼミに参加してるゼミのメンバーの方で回してたりもしていて、ちょうどこないだ、これまで週3回放送してたのを週1回に変え回すっていう風に告知もされてたので、全然それでもいいんじゃないかなと思います。 なんか声のログとかログとして溜まっていく資産を溜めていくみたいな感じで、コツコツ放送を溜めるのが良いのかなという風にも思ったりします。 いや、はい。難しい。書くのに比べて、書く方が時間が選べる感じかな。別に音声も。ちょっとそれなりにまとまった時間を取らないといけないっていう感じがしていて、 1本10分くらいなんですけど、10分取らないとっていう感じがちょっと大変かな。僕は休みの日にご飯作る担当の時があるので、その間の時間とかでやってるんですけど、そこまでになんとなく準備して説明すると。 今は昔書いたブログをかいつまんで説明してるっていう感じなんで、準備はほとんど必要ないんですよね。昔の自分の文字を読めば良いという感じで、それ自体もあんまり良くないというか、面白みがないコンテンツを生み出してるのかもしれないんですけど、 サミンさんみたいに毎回新しい何かをってなると、結構なプレッシャーがありそうかなっていう感じなんですよね。すごいですよね。毎日ブログ更新してる友達とかいるんですけど、その人も同じようなことをおっしゃってて、言ってて。 その習慣になると別に、息をするように何かこれを書こうとか喋ろうみたいな話になるって言うんですけど、なかなかそれができてない時点から見るとすげえなっていう、そんな感じですね。 一つ継続ですね。定期発信っていうのは大事なんですか?定期ってこの時間に来ると新しいやつが出てるっていうことが、僕が1リスナーの時は別にそんなに感じないんですけど、時間を決めてる方って結構多い気がしていて。 そうですね。結構その固定にしてるのが良いところというか、リスナーさんも割とこの時間に聞くっていうので、一番多いパターンが朝、通勤中に聞くっていう方が多いので、 で、だいたい8時から9時とか、人によっては7時からとか、その朝の時間に聞く方が多いので、そこに間に合うように5時とか6時とかに毎朝出してるっていう、その方がリスナーさんの行動のリズムに入りやすいっていうのが1個メリットかなと思いますね。 習慣にしてもらうっていう感じですね。 あ、そうそうそうそう。 ちょっとそこには放送いない。 いやなんかアドバイスがあれば、広告でこんな、その、なんでしょう、普通の話をしていいのかわかんないですが、アドバイスがあればぜひぜひいただきたいなと思ってます。 せっかく始めたんで。 なんか解説が、私もよく聞かせていただいてるんですけど、ちょっとなんか流れてっちゃう感じとかもしていて、聞いていて、解説とか結構その文字と違うところって、同じことを2回3回言っても聞けるのが良いしむしろそのくらい大事なことって言わないと流れてっちゃうので、 もう1回しても全然耳だと食うじゃないですね。 なるほど。 なんか河野さん何回も同じこと言ってるって言わないかなって。 まあなんかまあ同じ、そうですね、なんかその大事な論文のポイントとかその視聴、視聴というかそのブログの一番伝えたいところをなんか最初に言って、それを別の言い方で言って、あ、なんか同じこと言ってたんだみたいなことでも全然いいと思いますし、全く同じ言葉でも全然大丈夫ですし。 そうですね、あと声のいいところは感情が伝わるっていうところがすごくいいところなんですね。ニュアンス、そのブログで文字書いて、何だろうな、例え、何だろうな、いい例がちょっとパッと思いつかないんだけど、何だろう、なんかネガティブな言葉が文字面では書いてあったとしても、それを声で喋るとポジティブに言えるじゃないですか、何だろうな。 ああ、なるほど。 ブログでは伝えきれない、なんかニュアンスとか感情とか思いとかっていうところをなんか表現できるとすごく魅力的になるのかなという感じがします。 なるほど、何も考えてなかった。確かにそうですね。ちょっとそれは反省点として、改善点として入れてみたいと思います。改善されるのかどうかわからない。 そうですね、なんか個人的にはソフトウェアテストだったり、ソフトウェア開発だったりの人たちが、何だろうな、ボイシーで盛り上がるというか、いろんなチャンネルができると嬉しいなって思ったのも一個自分がチャンネルを始めたきっかけだったりして。 なんで森崎先生始められたっていうのを聞いたときめちゃくちゃテンション上がってました。 審査って書いてあって、これもう通らないんじゃないかなと思って、割ときつめにアピールがガンガン通って良かったなって後で思いました。 なので、せっかく作っていただいたので、継続できるように私にできることはしていきたいなと思いますし、それがプロダクトとかサービスとかのフィードバックというか、もっとそこの続けづらいみたいな大きい課題としてはあると個人的には認識をしていて、 そういうところもうまくこうやったらいいよっていう、ソフトでのカバーの仕方もあるし、もう少し機能っていう意味での仕組みみたいなところとかにもつなげていけたらいいなというふうに思ってますので。 なんか使ってるとあれですよね。単純に配信ツールっていうよりは、発信自体を支援する施策付きって感じがしますよね。すごいシンプルに言うと応援って多分ソフトの機能じゃあんまりない気がするんですけど、応援しますよみたいな。 こうやるとうまくいきますよとか、こういうのが良くないアンチパターンですよみたいな情報が共有されるだけでも十分ソフト以上のことはしている気がしていて、ある意味UXだと思うんですけど、そういう工夫されてるなっていうのはよく感じます。 僕がそれをうまく活用できるかって言うとまたそれが、それ僕どこで言ったのかな。僕にとっては割と大きいヒントで、提供側が想定する価値をユーザーがそのまま受け取って発揮できるかっていうのは必ずしもみんなそうじゃなくて、初心者向けとか、銀行のATMとかそうだと思うんですけど、 ユーザーに何も期待してないというか、ずぶの素人で初めて使う人みたいなことしか想定してなくて、何回も毎日毎日驚かしてるような人から見ると余計な手順とか操作とかがあるんですけど、そこはあんまり考えてないんですよね。 多分ボイシーの中でもすごい発信者の方と、僕みたいにちょっと今はうまくいってないなみたいな人たちがいて、その人たちの間で支援の方法を変えたりとか、こういう人たちにはまずはこれをやってもらおうみたいな段階的な話とかっていうのはきっと考えられる。考えておられると思うんですけど、 そういうのってボイシーに限らずいろんなソフトとかサービスとかでありそうだなとかって思いながら、違うな、思いました。これをきっかけに具体的なユーザーになってですね。 いろんな方の話を聞いたりとか、他社の製品を見てこういう話があるんですよっていう別のユーザーの話を聞いてふーんって思ってる時よりも、自分がユーザーになった時の方が感じることが多いかなっていう、そんな感じですね。 はい、ありがとうございます。そうですね、やっぱり使ってみると全然解像度が上がるので、私もパーソナリティとして発信して始めたからこそ、会社内でもいろいろ意見というか新しい機能、それこそ企画のタイミングとかでも、いやでもそれってこうじゃないですかみたいなのを結構言えてたり、本質的なコメントを言えるようになったのはすごい使っててよかったなと思ってたりします。 そうですよね、そうですよね。単純に評価だけしてるとそうはいかないはずなので。 本当にそう思います。 はい、ということでお時間になりましたので締めていきたいと思います。 今回はですね、音声LT大会ということで音声でLTは成り立つのかというところをやってみました。 思ったよりは上手くいったかなというふうに思ったよりはというか、そんなにスライドがないと全然伝わらないということは全然なくて、先ほどちらっと自分でも言ったんですけど、やっぱり思いみたいなところはもしかしたら通常のプレゼンテーションよりも感情みたいなものはもしかしたら伝わる可能性もあるかなと思いますし、全然口頭で補足できる部分もあるかなと思ったので。 また次回はですね、もう少しちゃんと告知をして発表者をちゃんと集めてですね、LT大会またそのうちできるといいなと思います。 はい、今回小石先生も事前にやりますよと参加したいですって言っていただきまして本当に助かりましたし、私も朝一で通知を見てめっちゃ目が覚めたというか飛び起きたぐらいすごい嬉しかったのでまた次回もLT大会だけじゃなくてよかったらゲストトークをしてとかでコラボレーションさせていただけたら嬉しいなと思っております。 ということで、最後一言ありますか? いえ、よろしくお願いしますって言いたかっただけで。 はい、ありがとうございます。 はい、ということで音声LT大会はここまでです。最後までお聞きいただいてありがとうございました。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はVoicyのトークテーマ、「忙しいからこそ気づけたこと」というところで、 忙しいからこそ気づけた自分の限界とその先についてお話をしていきます。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 ぜひ、画面右下のハウトマークでいいねを押していただけるととても励みになります。 ぜひぜひフォローもよろしくお願いします。 それではまた明日お会いしましょう。 ごきげんよう。