# タイトルコール ようこそ、世界が広がるソフトウェア品質で このチャンネルでは、エンジニアリングマネージャー兼QAリーダーのサミーが ソフトウェアテストやソフトウェアの品質保証を中心に 日々奮闘していることや考えていることをお話します。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと テストや品質の世界を広げていきます。 # 📣いよいよ来週。10/1水20時から生放送 いよいよ生放送が来週となりました。 10月1日水曜日の夜8時から、 ゲスト、じゅんぺいさんをお呼びして、 生放送を行います。 じゅんぺいさんとはですね、 あれ、いつだろう、5年前? 4年前かな? アジャイルテスティングデイズという ドイツのテストの大きいカンファレンスに 一緒に参加をしましてですね、 その時いろいろご飯食べたりとか、 たくさん話もさせていただいて、 そこからですね、主に新潟でよく お会いしているかなという気がしています。 10月1日水曜日の夜8時からです。 # ブログ、音声発信、LT会、カンファレンス登壇の使い分け こんにちは、さみぃです。 体調崩してないですか?だいぶ風も涼しくなってきてですね、窓を開けて収録してるのでちょっと雑音入っちゃってるんですけれども、 はい、気合入れて今日も話していこうと思います。 今回のテーマはブログ音声発信LT会カンファレンス登壇の使い分けについて言語化を試みてみます。 これまで自分の中で言語化をしてみたことがなくて結構発信していこうみたいな感じで、 じゃあブログまずやるかってなって、LT会頑張って出てみるか、カンファレンス頑張って出てみるぞ、 音声発信もやってみるぞみたいな感じでやってきたので、果たしてどのように使い分けているのかいないのかというところを今回言語化していきます。 話す順番なんですけど、音声発信というかボイシーですね、ボイシーブログLT会カンファレンスの順番で話していこうかなというふうに思います。 ということで一つ目音声発信、このボイシーなんですけれどどういうふうに使っているかというと、 基本的にはパッと思いついたこと、考えたこと、ちょっとこれについて勉強したいから、 勉強のアウトプットとしてこのボイシーで話そうとか、あるいは今回のも結構近いんですけどテーマだけ決めて、 収録をしながら話しながら自分の思考を整理していくっていう使い方をしています。 基本的には本編は10分以内に収めるぞっていうのが自分の中のマイルールとしていて、 細切れに細切れに小さくちぎって毎日続ける、毎日発信するというところを大事にしています。 続いて二つ目はブログですね。ブログについてはある程度まとまった情報をまとめて発信する場として活用しています。 具体的にはですね、一番最初に発信するぞって書いたブログは採用目的だったんですけど、 QAチームを立ち上げました。自分は一人目QAです。ロードマップを作りました。 なのでこのうちのチームではこういうロードマップ方向性と大事にしているミッションはこういうもので、 活動の柱がこういうものになっていて、気になる方はぜひカジュアル面談しましょうみたいな感じで、 ロードマップだったりある程度活動の方針を決めた上で、そのような情報をまとめてブログとして発信したというのが一番最初やってたことですし、 あとはQAチームを立ち上げてから1年後とか、ちょうどそれがイコール入社1年でここまでできたみたいな感じでブログも発信しましたし、 前の会社はこれで3年目までいきましたね。なので1年1回はブログを書いていて、 入社2年目、QAチーム立ち上げ奮闘期みたいな感じで、2年目はこういうことができた。できたことと振り返りを書く。 次やりたいことを書く。3年目もここまで進んだよっていう感じですかね。 どういうことを考えて、どういうことをやったら結果はどういうことがどういう状態になったのかみたいなのをブログでは発信しています。 この音声発信とブログの文字での発信、比べてみると、私の場合はですけれど、ブログってなるテキストで何かを伝えるっていう風になると、 どうしても長くなってしまうんですね、文量とか。何でかっていうと、なるべく自分の伝えたいことがちゃんと伝わるようにしたいので、 注釈が入ったりとか前提を書いたりとか、言い回しも助長になりがちだったりするので、結構文章が長くなるんですね。 文章が長くなるとどうなるかっていうと、書くのに時間もかかるし、手直しとか修正とかも見直しっていうところも時間がかかるので、結構労力使うんですよね。 音声と比べるとですけど。なので音声発信の方はかなり気軽に話してます。ブログはかなり嫌い売れて書いてます。 余談ですけど、今ブログを書いていましてですね、多分今日この公開されてる日にですね、ブログ公開してると思いますので、ぜひ読んでいただけると嬉しいです。 はい、余談でした。続いて3つ目がLT界ですね。 LT界は使い分けっていう意味だと、発表のバカ図を踏むために活用させてもらっている部分は正直あるかなというふうに思います。 もちろん全部が全部じゃないですけれども、特に登壇したての頃の時は、とにかくLT界で数をこなして、人前で緊張するのをなるべく緊張しないようにしようとか、 どういうふうにスライドだったり発表する内容を整理していったら良いのかっていうところを繰り返しやれるようにLT界っていうのはどんどん積極的に参加している時期がありました。 LT界の方は大体発表時間が5分とか10分とか短い時間だったりするので、その時々で発表したいこととか宣伝したいことも含めて、 基本的には伝えたいことは1個ですね。1つの伝えたいことを伝えるためにスライドを作って発表しているというのがLT界の使い方かなというふうに思います。 そして最後がカンファレンス登壇ですね。カンファレンス登壇とか勉強会、1時間とかがっつりしゃべる勉強会も含めてにはなりますけれど、 30分とか1時間の枠でがっつり自分が話すという場合だと、ある程度まとまった知識だったり経験の共有、思考の共有ということをするのが多いかなと思います。 1年かけてやったこととか半年かけてやったこととか、長ければもっと3年とかこれまでのQA、人生10年ちょいですかねぐらいでやってきたことも全部ひっくるめて話す経験だったり、 こういう事例がありましたとかこういうことを大事にしてますとかいうのが多いかな。 結構自分のパターンとしては、パターンというのかな、カンファレンスの登壇とか勉強会の発表とかで大事にしているのは、 事例をお話しするということ、現場で今どういう、今というかどういう課題があって、どういう工夫だったり活動をして、 その結果どうなったのか、うまくいったのか失敗したのかというのを生々しくお伝えするということをとても大事にしているので、 大体発表のステップというかスライドの構成というか発表の構成は、大体いつも同じかな、いつも同じか分からないですけど、 よくあるパターンが前提とか課題をまず最初に提示をします、それに対してこういうアクションをしましたという活動、 大体その活動のところを一番詳しく、時間長く使ったりするんですけど、活動をやってその結果どうだったかみたいな感じの構成で話すことが多いかなと思います。 ということで、今回はブログ、音声発信、LT会、カンファレンス登壇の使い分けについてお話をしてきました。 ここまでの話をまとめてみると、音声発信、ボイシーというのが一番小さい単位で、 本当にパッと思いついたことを考えたことだったり、最近こんなことが詰まったとか、こんな経験があったとか、 いろいろ自分の思考を整理するためにまずボイシーで発信をします。 そこからある程度まとまってくると、1年とかある程度まとまった単位でブログにまとめます。 そこでまた違う思考の整理というか、違う流度での思考の整理が行われます。 またブログとは違う軸でLT会があるんですけど、LT会については単発でこの話がしたいという、 5分、10分で話すというのはトピック1、2個しか話せないので、 例えばB2位の児童テストでマジックポットでこれやってみたみたいな話とか、 STQBのエキスパートレベルのテストマネージャーの調査バスから学んだことはこんなことですみたいなエッセンス紹介しますみたいな、 そんな括りで1トピックでポンって話をするのがLT会。 一番内容が濃いっていうのかな、濃いのか、これまでの知識だったり経験だったりというものを総動員しているとか、 1年単位でやったもの、半年単位でやったもの、それ以上数年かけてやったものとかをまとめてお話しするのがカンファレンス登壇かなというのが、 私なりの合格発信方法の使い分けになります。 # #280のコメント返し😍 コメント開始のコーナーです。今回は280話目、1人前のテストエンジニアとはのコメントを開始します。 コメント3件いただいておりますので、なかなかいいお題目だったのかなというふうに自負しております。 はい、コメント1件目はマツさんです。 自分も考えながら放送を聞かせてもらいました。 ファミリーさんのテスト設計ができるに含まれる気がしますが、 保証したいことを確認するためのテストシナリオを考え、それを他人に説明できるのが自分の中で1人前とする基準です。 あと、バグ報告ができるのは完全同意です。 バグ報告って難しいですよね。 事実と推測を意図せず混ぜてしまったり、現象を説明するための前提条件の記載の過不足があったり、 バグ報告はいろんな役割の人が読む性質上、文章の中でも最も難しい分類な気がしますね。 ということで、コメントありがとうございます。 読んでいて確かにいいと思ったのが、他人に説明できるというのも確かに大事ですよね。 例えば、テスト計画書でもテスト計数とかテスト仕様書を作って、 それを関係者というのかな、開発の担当者だったり経営チームの中だったりで説明する必要がありますよね。 なので、フォーマットがあってそれを埋めて書きました。 以上だとやっぱり足りなくて、なんでこれが必要なのかというところ、 あるいはなぜその内容をテスト対象外としたのかというところもしっかり説明できることはとても大事なので、 確かに1、2枚のテストエンジニアの条件になりそうですね。 ありがとうございます。 2件目はひでみきょんさんです。 ひでみさんはですね、最近よくコメントを、あれ初コメ?初コメかな?初コメおめでとうございますって言いましたっけ? Xでもリツイートやリポストしていただいて本当にいつもありがとうございます。 コメントを読み上げます。 いつも素敵な放送ありがとうございます。バグ報告の話、とても共感できました。 実は失敗談があって不十分な情報を確認するために私がバグ報告書にたくさん質問をし、相手が萎縮してしまいました。 その後バグ報告書のフォーマットを見直し、バグ報告の勉強会をしました。 今ならこの放送を聞いてもらうのが良さそうです。 ○○できる?○○できない?について確かに人によって解釈が変わりますね。 スルーしてしまっていたので今後は相手の解釈を聞いてみます。 私は同じ理由で正しいかNGワードですということで。 コメントありがとうございます。そしてめちゃくちゃ嬉しいです。 素敵な放送ありがとうございますって言葉に対してもめちゃくちゃ嬉しいですし、 バグ報告についてこの放送を聞いてもらうのが良さそうと言っていただいたのもめちゃくちゃ嬉しいです。ありがとうございます。 失敗談も書いていただきありがとうございます。 これってどういうこと?っていうところを色々聞いたら相手が萎縮してしまったのかなというふうに思いますけど。 私はあるかな。聞かれまくったことは多分あるんだろうな。 特にテストエンジニアの一人前になる前の時とかですね。 いつも苦労しながらバグ報告をしていたような気もします。 ふとこのコメントをいただいて思い出したエピソードが一つあるんですけど、 本当最近ですね、CCIとか使って不具合修正をし始めていて、 自分がリグレッションテストで検出した不具合があって、それを記表したんですよね。 これをちょっと自分で直してみようと思って、 書いたディスクリプションから色々こういう風に直したら良いのかなっていうのを考えていたんですけど、 考えているうちにそもそもこの機能の挙動の期待結果ってこれで合ってるんだっけ? どっちが正しいんだっけ?みたいなことになっちゃって結構頭こんがらがっちゃったっていうところもあって、 改めてバグ報告を簡潔に書くというところ、 そしてあるべき姿がどうなのかっていうところをメキすることって大事だなっていうのを実感しました。 あと正しいがNGワードということで、 私どうだろうな、自分のいつもの考えてみるとテスト観点とかちょっと粒度の荒いときは正しいことって使ったりするんですよね。 そのじゃあ例えば〇〇の計算結果が正しいことっていうテスト観点があって、 それをテストケースに起こすときに正しいって具体的にどういうことなのとか、 例えば計算だったら具体的な数字を入れてこれがいくらで、これがいくらだった場合にここの数値がいくら何円になるみたいな風に、 正しいとは何かっていうところを客観的に誰が見ても判断できる書き方にするかなという風に思っています。 ありがとうございます。そして最後がみずけんさんですね。 みずけんさんいつもコメントありがとうございます。 現場的に一人前のテストエンジニアとなるとそんな感じになりますよね。 とても参考になります。 ちゃんとしたテストエンジニアさんはバグ表のタイトルをとても気を使って書いてくれる印象があります。 あとで管理者が一覧化してみるときに一目で何のことか分かりますし、 バグ修正する方にも間違いなく伝わるのでとても助かりますねということで。 ありがとうございます。 確かにタイトル大事ですよね。 そのタイトルを見てこの不害の事象、バグの事象ってなんだっけってところがパッと思い出せるのは、 いいバグ報告書の条件になりそうですね。 私も改めて気を引き締めてですね、バグのタイトルには気を付けたいと思います。 以上コメント開始のコーナーでした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、プロジェクト管理の失敗談についてお話をしていきます。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は是非、 画面右下、ハートマークでいいねを押していただけると、とっても励みになります。 是非是非、フォローもよろしくお願いします。 それではまた明日お会いしましょう。ごきげんよう。