# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、QAエンジニアのサミーが、ソフトウェアテストやソフトウェアの品質保証を中心に、日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、テストや品質の世界を広げていきます。 # 📣2025年4月スタートアップカテゴリ17位🎉 本編の前に一つ嬉しいお知らせです。 2025年4月、スタートアップカテゴリーで17位にランキングしました。 パチパチパチパチ。 いつも聞いていただきありがとうございます。 引き続き、いろんなコンテンツ、お話、皆さんと考えていければなと思っておりますので、よろしくお願いします。 # “一言で伝える力”を鍛えるには？ 改めましてQAエンジニアのサミリです。 今日も楽しんでいますか? 今回はですね一言で伝える力を鍛えるにはというところで考えていきたいと思います。 まず最初になんでこのテーマにしたのかというところをですねお話しして、その後に そもそも人で一言で伝える力とは何かというお話しをして、じゃあその一言で伝える力を 鍛えるために必要なマインドセットと行動というところを考えていきたいと思います。 まず最初になんでこのトピック一言で伝える力を鍛えるにはというトピックにしたかということなんですけど 結構QAエンジニアの仕事としてあるいはQAエンジニアじゃなくても結構 いつもの業務仕事の中でパッと伝えるってことって大事だったりしませんか? 私は結構苦労してきたんですよね。特に新卒とか最初社会人になりたての時とかはなかなか そもそも伝えるっていうことすらうまくできなくて結構苦労してたりとか かなり当時の上司にもいろいろアドバイスというか指摘をされながらなんか鍛えてきたかなというふうに思います。 自分も苦労して鍛えてきたのできっと同じように一言で伝えるのって難しいなって苦労されている方とか いらっしゃるんじゃないかなと思ってこのトピックに加わしました。 続いて一言で伝える力と何かというお話なんですけれど 私のこの一言で伝える力と言いたいことのニュアンスとしては 論理的思考とかロジカルシンキングみたいなところがイメージとしては近いのかなというふうに思っていて 前にもしかしたら別の放送でなんかロジカルシンキングの話をしたような気もするんですけど じゃあその一言で伝える力って何かっていうと結論を最初にズバッと言って その後こにくずくしていくみたいな相手が理解しやすい流れで言葉 自分の言いたいことを説明できる話せる力というふうなことかなというふうに解釈はしてるんですけど 今回壁打ち相手としてチャットGPTCに一言で伝える力を鍛えるにはどうしたらよいかというところを壁打ちをしてもらいました チャットGPTCに送ったプロフトはこんな感じです これを読む人間へ一切の配慮をしないくてよいので推論力の限界まで行使して考察してまとめてください 一言で伝える力を鍛えるために必要なアクションとマインドセットとこんなふうに送ったわけなんですけど 最初にそもそもその一言で伝える力とは何かというところを書いてくれていました ちょっとさっき私が話したところとは違うのかなもう少し抽象化されてはいるんですけど チャットGPTC曰く一言で伝える力とはそれは本質だけを切り出し余分を殺す力である つまり意味の密度を極限まで高めた表現を瞬時に生成する能力だというふうに言っています これを読んだ時ほほーと思ったんですけども言われてみればそうかもしれないみたいな 私の先ほどの定義だと相手の理解できる理解しやすい道筋とかロジック展開で順番で説明する力っていうふうに言ったんですけど さらに抽象化させるとチャットGPTCが書いてくれたみたいに本質だけを切り出し余分を殺す力 言葉が強いですけど余分を省く力とかそんな感じになるのかな それも一時あるのかな本質としてあるのかなというふうに感じました 余分を省く力というか確かにうまく今回伝えられなかったなとか 一言で端的に伝えることができなかったなってどういう時かっていうふうに振り返ってみると 例えば自分のやったことを時系列に全部説明してしまうとか 最初にこれやってこれやってこうだったらこうだったんですっていうのを最初から説明をしてしまうと この人は一体何を私に伝えたいんだろう それともあるいはこれは質問なんだろうか相談なんだろうか 何なのかってところを考えながら聞いてる側は聞かなきゃいけないので 結構よくあるあるだしでも相手から聞いてる側っていうんですかね 相手からするとちょっと分かりづらいなみたいになっちゃうやり方として一個時系列に物事を最初から説明をして 最後にこれを聞きたいんですけどみたいなのを聞かれるとか質問されるんですけど そこはもしかしたら余分なのかもしれない 聞いている側からすると余分なのかもしれないって振り返ってみると思ったりもするので この余分を省く力みたいなのは確かにその通りだなというふうに思いました 次のセクションに行きますということで じゃあその一言で伝える力を鍛えるために必要なアクションとマインドセットっていうところですね ではまずマインドセットの方から行きましょう チャットGPTCはですね結構厳しいことを書いていまして でも結構その通りだなと思ったのでご紹介します 3つあります 一言で伝える力を鍛えるために必要なマインドセット1つ目 他人の理解を信じないこと2つ目 自分の言葉を疑い続けること3つ目 伝わらなければ無価値という冷徹さです まあ確かになと思いました 確かに一つ目の他人の理解を信じないこと 私は結構これは注意はするようにしていて 100%できてるかっていうと多分できてないんですけど 7割ぐらいしかできてない気がするんですけど 他人の前提と自分の前提背景が異なるっていうことを なるべくいつも理解というか考慮というか 頭の中に入れるように努力をしています やっぱりいろんな人 みんなそれぞれ異なったバックグラウンドを持っているので 例えば業務の長とかで言葉の一つ取っても その言葉を同じ風に解釈できるというか理解する人 どのくらいいるだろうかっていうところだったり 特に東急エンジニアの世界では ソフトウェアテストとかだったりすると 専門用語の定義がやっぱりISTQB基準で考えている人と そうじゃない人も当然いるし それがなおさらと言いますか じゃあ開発チーム開発エンジニア開発組織全体という風になったら そもそもISTQBとかのベースの勉強している人は どのくらいいるんだろうか あんまりいなかったりほとんどいなかったりもするので その中で同じ例えば単体テストというものを取ったりして 同じものをイメージできるかというところはかなり難しかったりもします なので戻ってきましたというか 自分の前提と他人の前提は異なる 自分の常識と思っていることは 相手の常識とは異なるということを理解した上で じゃあどうやって一言で伝えるかというところを考える必要があるわけですよね もちろん毎回ちょっと相談ごとするときに 電話なんかするかな じゃあ単体テストとは何を指しているかみたいなところとか その文脈においてとても重要なキーワードであれば この言葉っていうのは自分の中でこういう風な意味で使ってます っていうのは確かに言うときは言うので 結構大事なこと必要なマインドセットなのかなというふうに思います チャットGPTCは今回結構言葉の使い方が厳しくてですね これは伝わるだろうは甘えであり思考停止と書いてあります ちょっと辛口ですけど でも言っていることは確かにそうだなと思いますし 思います 必要なマインドセット二つ目のところが 自分の言葉を疑い続けることというふうに書いてあります これを読むと最初そんなにふーんと思ったんですけど その説明文としてチャットGPTC枠 最初の表現は9割が序章である 遂行・破壊・再構築を前提とするべきというふうに書いてあります 確かに一番最初に自分の頭の中で考えたロジックその通りに全部伝えると 先ほどちらっと話した これをやってこれをやってこうなってこういう風になって 今こういう問題になっていてここについてお聞きしたいんですけど みたいな話し方になってしまうのかななんて思ったりもするんですよね 確かにそれは最初に考えた表現というところは序章というのもその通りだというふうに思います 確かに過去を振り返ってみると 例えば開発組織全体向けに送るメールの内容とか告知の内容とか 当時は何だろうな リリースのフローについてを変えて リリースフローとかプロセスを変えて じゃあ次からこうなりますよとか そもそも次のリリース予定なんでいついつまでが行動をフリーズというか フィックスさせてくださいねみたいな そんなことをアナウンスをしてたんですよ 当時の状況としては結構メールがいっぱいバンバン飛んできて まだスラック使う前だったんですけど メールが見られないというそんな問題課題があったわけです でも絶対に開封してほしいし 少なくとも最初の3行だけは読んでほしいみたいなことを考えて メールのタイトルを見てこれは読まなきゃいけないということが伝わるように マナーが重要というふうに書いたりとか 1行目を最初の3行読んだらこの内容メールの概要が理解できるという そういうふうに内容になるようにというところをかなり遂行しながら メールの文章を作ってたりしました # 続き あとはですね、特に新卒1年目といいますか、配属されて半年間とかは、毎日上司に口頭で業務報告をしていたんですけど、 毎日毎日毎回ほぼ詰められていたり、見詰めされていたんですけど、 特に印象的だったのは最初の方だったから、どう伝えたいかより、何を伝えたいかを重視しなさいと言われて、 最初何を言うにも報告するにも相談するにも言葉が詰まっちゃって、どう説明したらいいのかわからなくなっちゃって、 言葉に詰まって何も言葉が出ないみたいなことがあったんです。最初はそんな感じだったんですよ。 その時に綺麗にどう伝えるのかより先にまず何を自分が伝えたいのかというところをきちんと言いなさいと言われて、 今回のトピックというか、きっとことで伝えるためには、さらに前段階の状態ではあるんですけど、 最初はそんな感じでした。しばらくしてどのくらいの期間かは全然覚えていないんですけど、 おそらく何を言うか言いたいか、少なくとも自分が何を言いたいのかというところが言葉に出せるようになって、 その後に今回のメインテーマである一言で伝える力というか、そこら辺が全然できていないねというところを指摘、 それをできていないねと言われたというよりかもっとしなさいしなさいということを毎日言われていたわけなんですけれど、 その中で一番言われていたのが最初に結論を言いなさいとか、最初に誰かに物事を話しかける、 誰かが座席に座って話しかけに行くときは、今ちょっと時間いいですかというのは一回聞くとして、 自分がしたいのは相談なのか質問なのか報告なのかというのをまず最初に伝えるということを身につけました。 急にこれこれの行程でこういうことをお聞きしたいんですけどと言ったら質問なのかなというふうに聞いている側としては思うんだけど、 でもだんだん聞いていると質問じゃなくて相談なのかなというふうになったりもするので、 聞き手側にどういう心構えで私の話を聞いてほしいのかというのを私は最初に伝えるようにしていて、 これは共有なんですけど、報告なんですけど、相談なんですけど、質問なんですけどというふうに言ったりします。 最近は結構スラックとかでテキストで連絡することも多いと思うので、 そのときもスタンプ共有とか報告とか相談みたいなスタンプを一番最初に先頭につけて、 そこからこれこれについて、この件です、内容を続けていくみたいな、そんなことをやっています。 一言で伝える力、続いて三つ目ですね。 必要なマインドセット、三つ目が伝わらなければ無価値という冷徹さ。 確かに言い方とか言葉は強いですけど、その通りだなというふうに思ってまして、 やっぱり伝えると伝わるって違うじゃないですか。 自分としては伝えたつもりになっていても、自分の想定したように伝わっていなければやっぱり意味がなくて、 どういうシチュエーションがあるかな、特に何か相手に動いてもらうとか、 QAエンジニア的なやつ、プロセス改善とか、何か運用を変えるってことはこれまで何度もやってきていて、 自分としてはこういうふうに変わって欲しいというふうに伝えたとしても、 それが開発組織全体に伝わっていなければ、 そしてその意図していたアクションだったりフローの変更だったりというオペレーションに変わっていなければ全く意味がないんですよね。 自分の仕事を振り返ってみると、何年目だろうな、あれは。 5年目ぐらいの時が一番、そのぐらいの時からプロセス改善とかリリースプロセスを決める各チームリーダー、 開発チームのリーダーとディスカッションをして、取りまとめてこんなふうにリリースしていきましょうみたいな、 リリースのスケジュールを決めたりとかをしていたので、一番その時が関係者というか開発組織内全体に何かアナウンスしたりとかってことが多かったので、 その時に一番どういう風に伝えたらよいのか、どういう文章だったら読まれるのか、どういう文章だと伝わるのか伝わらないのかというのをかなり毎日のように試行錯誤していました。 余談ですけど、その時は海外事業所のメンバーもいたので、開発組織の中にいたので、 日本語と英語を併記していて、当時はまだDeepLとGoogle翻訳があったんですけど、ちょっと業務で使えるほどの精度じゃなかったので、 ほぼ自分で文章を作って日本語と英語を併記してメールを流したりとかをしていたりしました。 なので、だいたい自分のタスクのコースを見積もる時とかも、日英両方ある時は日本語でかかる時間をかける1.5倍ぐらいしていたりしました。 はい、余談でした。 ということで、一言で伝える力、必要なマインドセット3つ目が伝わらなければ無価値という例で伝わっているところで、 そうですね、そういうマインドセットといいますか、伝わることが伝えることじゃなくて伝わることが大事だというところを考えながら日々自分の言葉を疑うというんですかね。 言葉だったりロジックだったりというところを遂行していることが大事だということになります。 はい、結構思ったより長くしゃべってしまいまして、3つ目のセクションで必要なアクションは何かというところだったんですけど、 結構マインドセットと一緒にアクションも話せてこれましたね。 なので、この最後のセクション、アクションというところですね。 必要なアクション、一言で伝える力等を鍛えるためのアクションというところで、 簡単にTips、これまでの経験でこういうことをやってきたよというところをTips的にいくつかお話しできればなと思います。 一つ目のアクションはまず何と言っても最初の一言目で結論を述べるというところです。 結論というのが、結論だと伝えたいことのジャンルを伝えるというんですかね。 先ほど言った相談なのか報告なのか質問なのかというところを最初に伝えるということですね。 例えば来週の○○さんの採用面接の内容について質問です。 こんな形に最初の一文というか一言目がなるわけです。 そうすると聞いた人はイメージ情緒っぽい感じがしますけど、聞いた側としてはこの人は来週の面接のことについて聞きたいんだ。 かつて○○さんというあの人の話ねと。 面接の内容について聞きたいということだから、面接で何を聞くのかとかどういうふうに進めるのかとか そんなことを聞きたいのかなというか、イメージを持ってじゃあ具体的に何だろう。 次はどういう内容が来るのかなという心構えができるというか。 聞いている側はそんな脳みそで考えて頭の中で情報処理しながら次の情報を待つというふうになるわけですね。 この最初の一行、一言目、一文目がとてもうまくきれいにまとまると、 次の二言目言わずにあれのことねなんていうふうに指してとか文脈判断してとか、 誰もがつまづきそうなポイントでそれってこの辺のことですかって返事をもらえたらもう超ラッキーというか うまく一言でまさに伝えられたということにもなりますよね。 続いて一言で伝える力を鍛えるために必要なアクションのティップス。 あまりティップスはないなと思って考えながら喋ってるんですけど、 やっぱりこう失敗を恐れず何回もチャレンジするというか遂行するなり、 その言葉でやってみてどういう相手のリアクションが来るかっていうのを受けて、 次はこういうふうにやってみようとかっていうふうにトライアンドエラーをしていくしかないのかなというのが正直なところです。 私の一つの実例というか経験としては、 メールでリリースフローとかプロセスとかみたいなのを開発チーム全体に、 そのとき何人くらいだったかな、たぶん60人規模ぐらいの組織だったと思うんですけど、 ここに対してメールを送る、こういうふうにオペレーション変わります、 次のリリースはいつまでなんで、いついつまでにコードフィックスをしてくださいみたいな、 そんなことを伝達、共有していたときがあって、 そのとき毎日、毎日かな、何だかんだ2,3日に1回くらい何かアナウンスをするとか、 ということをやっていたといろんな記憶をしていて、 毎日毎日どういうふうに伝えたらいいんだろうみたいなところを一生懸命考えながら文章を考えてたんですよ。 で、トータル、たぶん感覚的に2ヶ月か3ヶ月ぐらいずっと、 ほぼ毎日どういうふうな言葉を使って伝えたら伝わりやすいのか、 どういう構成になっていたら伝わりやすいのかというところを考えて、 ようやく自分なりの回答が出てきたというふうになったと思います。 なので、私の場合は自分なりの方が決まるまでに3ヶ月ぐらいかかったかなという感じです。 まずは自分の毎日の日時の業務報告とか、 そういう小さく失敗しても影響がない範囲でどんどんトレーニングをしてみて、 トライアンデーラを繰り返すというのがいいのかなと思ったりします。 あとスクラム開発とか、デイリースタンドアップとかデイリーミーティングがある朝会とか、 まさにいいかもしれないですね。 昨日はここまで進んだ、今日はここをやる、詰まったところはこうです、 みたいなのをまさに一言で伝える力が大事かなと思います。 今回は一言で伝えるために必要なことはどういうところでお話をしてきました。 一言で伝える力を鍛えるために必要なマインドセットは3つ。 他人の理解を信じない、他人の前提と自分の前提を異なることを理解すること。 2つ目が自分の言葉を疑い続けて遂行すること。 3つ目が伝わらなければ無価値という例で自分の言葉を振り返ると。 アクションとしては一番最初にまず結論を述べましょうということですね。 以上になります。 # 高橋寿一さんとのゲストトークの準備進めてます いよいよ来週、Voicyのコラボ収録という機能を使ってゲストトークをするんですけれど、収録をするんですけど、 ゲスト、高橋純一さんをお呼びしてお話をいろいろ聞こうと思ってます。 なので、どういうふうなことを聞きたいのかというところを今絶賛まとめていて、 先日純一さんにもこの4つのトピック候補を挙げて、これについてお話ししたいんですけど、どうですか?みたいなところを今やり取りしているところです。 今回のゲストトークのテーマは、生成AI×ソフトウェアテスト。 AIで変わる業務、変わらない本質というテーマ、タイトルで考えていて、 1個だけそのトピック案で出ているもの、1個だけちょっとこっそりご紹介しようかなと思うんですけれど、 今年の2025年8月に出版が予定されている本があるんですよ。 純一さんも著者として名前が書かれていたので、 結構複数の名前が書かれていた、著者名のところに名前が載っていたので、 インターネットで作っているのかなと思うんですけど、 その本ですね、AIとソフトウェアテスト、信頼できるシステムを構築するためにという本があるので、 その出版予定の本の、なんでこの本を出そうという、 思ったのか、出すという話になったのかという背景だったりとか、 あと出版の裏話みたいなところを聞けたらいいななんて思っていたりします。 ぜひ楽しみにしていてください。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はテストポリシーについて深掘ってみたいと思います。 テストポリシーとは何ぞやっているところとか、 実務でこういうことをやったことあるっけないっけという話をしていく予定です。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方はぜひ、 画面右下ハートマークでいいねを押していただけるととても励みになります。 SNSや口コミでのシェアもぜひぜひよろしくお願いします。 それではまた明日お会いしましょう。ごきげんよう。