# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々、奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方や、リスナーのあなたと、 テストや品質の世界を広げていきます。 # 📣第1回オフ会の日程決定！ 本編の前に一つお知らせです。 オフ会の日程が決定しました。 第一回オフ会の日程は、 2025年8月31日日曜日の午後になります。 時間は午後2時スタートから終わりは夜の8時ぐらいかなと考えております。 ぜひ興味のある方は日程確保をお願いします。 申し込み方法や金額は検討中ですので少々お待ちください。 次のアナウンスを楽しみに待っていただければと思います。 # Lead the Test Team こんにちは、Q-Engineerのサミーです。 今日もワクワクしていますか? 今回はですね、Reading the Testingというところで ISTQBの3.4章を あ、間違えた。 ISTQBエキスパートレベルテストマネジメントのシラバス 3.4のReading the Testingについて 英語と日本語で学んでいきたいと思います。 シラバスの内容を英語で読みつつ 私が考えていること、考えたことだったり これまでの経験というところでこうなったな というところをお話ししていきます。 まず最初に3.4 Reading the Testingの その中の章立てをお話しします。 3.4の中には3.4.1、3.4.2、3.4.3、 3.4.4、3.4.5の5つに分かれています。 それぞれのトピックは3.4.1が Information Sharing and Communicationなので そのままですね、情報の共有とコミュニケーション。 3.4、3.4.2がFostering Loyalty and Trustなので ロイヤリティ、忠誠の信頼の情勢という感じですね。 3.4.3がTeam Buildingですね。 3.4.4がMotivating and Challenging the Testingということで テストチームをモチベートしたりとか チャレンジさせるという感じでしょうか。 3.4.5がManaging Distributed Teamsということで 距離の離れたチームを分散しているチームの マネージ・管理についてという感じになっています。 まず最初3.4のReading the Testingの最初のパラグラフ 全体のところのパラグラフを読んでいきたいと思います。 In order to be a strong manager and effective leader, a test manager should strive to use appropriate management and leadership principles and techniques. ということで、強力なマネージャー、 そして効果的なリーダーであるためには テストマネージャーはuse appropriate management 不相応しいマネージメントだったりリーダーシップだったりの原則 そしてテクニック技術というものを 使えるべきですよというふうに書かれています。 Many of these are not specific to test management, but rather are general principles and techniques that are widely used for the management of technical teams or teams in general. ということで、これらというのは前の文に書いてあったやつですね。 マネージメントリーダーシップの原則だったりテクニックというのは テストマネージメント特有のものではなくて どちらかというとかなり一般的なもの 広くテクニカルチームのマネージメントだったり チーム全般のマネージメントで使われている原則だったり手法、テクニックだったりというものと 一般的なものですよということが書かれていますね。 続いて The focus of this section is on those aspects which affect test managers. ここのセクションでフォーカスしているのは those aspectsから側面 テストマネージャーに影響を与える側面について書かれていますよという感じですね。 わりかしこの3.4のところとかは テストチームだからというよりかは 結構最初に書いてあった通り 概要違和なテストチームのマネージメント以外にも活用できるというか 一般的なマネージメントとかチームをリードするという チームマネージメントみたいなところをチームビルディングだったり というところが書かれているかなというのは確かに読んで印象を受けています。 続いて3.4.1 Information sharing and communicationに入っていきます。 それは情報共有とコミュニケーションについてですね。 読んでいきます。 最初に書かれているのはテストマネージャーの責任として 以下のことを担保しましょうというふうに書いてあります。 何かというとテストチームがグループの役割 組織全体の組織の中でのテストチームのグループの役割というものを しっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ グループの役割というものをしっかり理解をしているかつ コミュニケーションシェアとコミュニケーションのところ どういう方法があるかというとここで1on1ミーティングだったり weekly status reports 毎週の週日のステータス報告だったりとか 毎週の週日のステータス報告だったりとか informal communications 公式じゃない非公式のコミュニケーションでの会話というものもあるよね そういう場を使って情報共有というのをしっかりしていきましょうね ということが書いてあります 続いて3.4.2 Fostering Loyalty and Trust 忠誠心だったり信頼の情勢というところになります こちらはですねパラグラフ1個しかないので わりかし短い内容です 全文読んじゃいます In order to promote loyalty and trust within the test team, the test manager must be open and honest with the team and should encourage a safe environment where test team members are not punished for sharing bad news. In addition, the test manager should treat test team members with respect and ensure that team members feel that their opinions are valued. というところで そういうロイヤリティとか忠誠心とか信頼関係というところを テストチームに醸成するためには テストマネージャーというのはオープンで 誠実でないといけませんよというところと エンカラージだから 励ますという感じですかね いわゆる心理的安全性みたいな感じですかね ちょっと異役と言いますか解釈が入ってますけれど そういうテストチームのメンバーが悪いニュースをシェアしても それを抜しないという やっぱり心理的安全性というのが大事ですよねという話だったりとか should treat test team members with respect 経緯を持って 彼らのメンバーのオピニオンの意見というのが 価値があるものだよというところを ちゃんとそういう風に取り扱うということが必要ですよね ということが書かれています ここはあまりテストチームだからという感じはしないですけれども やっぱりプロジェクトの進捗がうまくいかないとか こういう不具合が見つかったとかっていうのは バッドニュースっていうのはあると思うので それを聞いたときに教えてくれてありがとうねとか という風に言うことは結構大事なんだろうなという風には思ってます 私の工夫してるところは 全部が自分がリーダーとして全部決めなきゃボンって ロードマップだったり今期の目標だったりボンっていうことを 決まってからチームメンバーに共有するのではなくて 最近こういうこと悩んでるんだよねとか 目標設定もこういうこと考えてるんだけど なかなか決まんないんだよねみたいなところを 小出しにしていって そのメンバーチームメンバーからの意見というものも こう出しやすくするこういうのどうですかって 言いやすい風に気にしたいなとか しているつもりではあったりします 次のチャプターいきます # 続き 3.4.3はチームビルディングについてです。 最初の字幕を読んでみます。 テストマネージャーのロールの一部として、 まとまりのあるテストチームだったりとか、 ポジティブなチームダイナミックスを作るという、 そういう情勢をするというのが、 テストマネージャーのロールの一項部分でありますよね、 という風に書かれています。 どうやってチームビルディングするかというのが、 次に書かれています。 一文飛ばしてまた読み上げます。 ということで、オープンコミュニケーションだったり、 リスペクトフルビヘビアだから、 チームメンバー間での経緯のある行動だったりとか、 シェアアンドアスタンディングのロールとリスポンスビリティだから、 グループのロールだったり、責任というところの 共通認識を持つ、理解を共有するというところは、 全部まとまりのあるチームに影響を与えますよ、 そういう活動が必要ですね、ということが書かれています。 さらに、もうちょっと具体的な例が書いてあるので、 紹介していこうと思います。 デイリーの毎日の活動に加えて、 強いチームをビルディング作るためには、 いくつかのエクササイズ取り組みだったりとか、 活動取りがありますよ、というところで紹介されているのが、 1、2、3、4、5、6、6個あります。 一つ目、Hold a group lunch where each team member brings in a special dish ということで、グループランチ、チームランチをしましょうというところですね。 かつ、ここに書いてある内容だと、チームメンバーが持ち寄り、 それぞれの特有料理とか、おすすめの料理というものを 持ち寄って食べましょうという感じです。 ちょっとヨーロッパっぽい感じはしますかね、持ち寄りのランチは。 でもチームランチとか、ウェルカムランチとかは されている会社は多いんじゃないかなと思います。 二つ目、Have a celebrity party after a project is completed というところで、プロジェクトが終わったら、お祝いのパーティーをする。 打ち上げとかですかね、打ち上げやってます。 私をなるべくプロジェクト、新しい機能がリリースとかされたら、 テストチームでというよりからは、 開発チーム全体でという感じはしますけど、 開発チームの方で打ち上げやりましょうとか言って、 企画されていなさそうだったら企画したり、 そこは積極的にやってたりします。 三つ目、Celebrate test team members' special events such as birthdays, weddings and birthsということで、 テストチームメンバーの特別なイベントを、 例えば誕生日、結婚とか、 お子さんが生まれたみたいなところを祝いましょうというところですね。 ここはどうなんだろうな、やってる時もあるし、 最近あんまり派手にやらなかったりとかするようなイメージもありますけど、 そういう特別なイベントをチームとしてお祝いすることで、 チームビルディングというか、 お互いの結束力を募るというのはその通りかなと思います。 ちょっと脇道それますが、前にQAチームの、 昔ですけど先輩が結婚するという時に、 宿伝って言うんでしたっけ、 電報、メッセージとぬいぐるみを送ったんですよね、 結婚式の会場に。 私自身は二次会に参加させていただいたんですけど、 式の方は参加していなかったので、 QAチーム一同からメッセージを送ろうということで送ったんですけど、 その当時ですね、熊本に私がめちゃくちゃハマっていたので、 熊本の口調で、なんとかだもん、みたいな感じでメッセージを送りました。 ちょっと当日どういう感じで司会の方が読んでくださったのかは分かりませんが、 熊本の口調だったので、もしかしたら私がやってくれた、 司会になってくれた、準備してくれたのかなというふうに、 先輩も気づいてくれたのではないかなというふうに思います。 はい、4段でした。 チームビルディングのためのアクティビティ、4つ目に戻ってきます。 4つ目は、クリエイター・テストチーム・ニュースレターやイントラネットということで、 テストチームのニュースレターとかイントラネット、 社内上で情報をシェアするというところですかね。 これはどうだろうな、やったことないな。 あまりニュースレター的なのは。 5つ目が、 ということで、これいいなと思いましたね。 教育的なセッションをランチタイムに行うという。 実質やったことあるようなないような。 いや、ちゃんとやったことないかな。 テストチームメンバーが何か興味のあるものをプレゼンする、 ランチタイムにプレゼンするというイベントです。 これは確かに新しい情報をインプットできるし、 どういうものをシェアするかというと、 新しいテストツールだったり、 面白いテストに関連する記事というものをシェアするという会なんですけど、 確かにランチしながらコミュニケーションを取りながら 新しい情報をインプットできるというのがすごく良さそうだな。 たまにやってみるというのが面白そうだなというふうに思いました。 前に、カンファレンスの参加レポート。 任意の人で集まって、お昼の時間に集まって、 食べながらワイワイこういうカンファレンスに参加して、 こういう学びがあった、こういうセッション面白かったみたいな話はやったことがあります。 最後、Engage an External Firm which Specializes in Team Building Activities というところで、こちらは外部の会社ですね。 チームビルディングが得意なサービスセッションを提供している 外部の会社に委託する、頼むというところもあるよという話でした。 この後にチームビルディングの注意事項みたいなのが書いてあって、 ちょっと時間が来そうなの、足りなさそうなので日本語で話し、 ようやくだけかいつまんだ話をしますけれど、 こういうチームビルディングのイベントをするときは、 必ず全員を含めるようにしましょうというところが書かれています。 全員と言っているのはオフサイト、オフショアのチームも含めてとか、 もし不可能な場合は別のアクティビティというものを分けて スケジュールしましょうねというふうに書かれています。 オフラインでやるときとオンラインでやるときとか、 オンラインの方も含めて楽しめるように何か工夫をするとか、そんな感じですかね。 特になのかな、このシロバスの前提として、 多分異なる地域での活動というんですかね、 異なる地域のディストリビューティーとチームというふうに表現されていますけど、 例えば東京とか関西とか、 大阪と北海道みたいなところの距離的な、地理的な遠さというところも しっかり考慮してやっていきましょうねというニュアンスがシロバス全体にあるので、 そういう意味でもチームビルディング、土地が離れている場所だとしても楽しめるというか、 チームビルドができるような工夫をしましょうねということが書かれています。 もう1個が広い意味でチームビルディングというと、テストチームだけじゃなくて、 テストチーム以外の関係者というところ、 アナリシス、デベロップメント、テスティング、テクニカルドキュメンテーションとかと書いてあるので、 分析をするような人たちだったり開発する人たち、 テクニカルドキュメンテーション、運用チームみたいな感じだったりとか、 もうちょっと広く解釈をすると、 サクセスチームとかサポートチームを含めて一緒にチームビルドってやるのもいいですよねみたいなことが最後に書いてあります。 ここ最後のトピックにしようと思います。 3.4.4、モチベーティング&チャレンジングのテストチームというところで、 どうやってテストチームをモチベートしたりとか、挑戦をさせるかということになります。 モチベーティングとかチャレンジングのヒントとして6個紹介されています。 1個目がKeep team members informed on important projects and corporate informationというところで、 チームメンバーに情報を伝え続けるということですね。 大事なプロジェクトの情報だったりとか、会社の全体の情報をちゃんと伝えることということは、 モチベーションとかにとっても大事ですよというふうに書かれています。 確かにタスクだけ振られちゃっていると、 なんで自分がこの仕事をしているのか、なんでこの機能を作っているのか、 テストしていなかったりとか見えなくなってしまうので、失いがちなので、 あなたが携わっているプロジェクトは大事なんだよ、こういうふうに大事なんだよというのを、 会社の全体の流れの中で、だから今この機能を作っているんだよみたいな、 そういうところまできちんと伝えていくことによって、 自分はとても大事なプロジェクトに関わっているんだというところで、 モチベートされるというところは多いにあると思います。 2つ目がGive team members honest and helpful feedback on their workというところで、 正直で役に立つフィードバックというところをちゃんとしていきましょうというのが2つ目。 3つ目がGive people the opportunity to do something different by moving test team members between different projects and tasksということで、 配置替えをすることによって、新しいことをこれまでと違うことにチャレンジできる、 そういう配置替えとかをしましょうということですよね。 次、Give test team members the chance to develop their skills by attending training sessions. 業務以外にも教育的なトレーニングセッションというところにも参加をさせて、スキルを伸ばせるようにしましょう。 次、Ask test team members what they are interested in doing and set goals and objectives that work towards these interestsということで、 あと10秒でワンラインの次のチャプターに移ります。 # さらに続き チームメンバーにどういうことに興味があるのかというところと、 それを聞いた上でゴールだったり目標というものを決めていきましょうねという話ですね。 確かにこれってめちゃくちゃ大事だなと思っていて、 私も少なくとも半期に1回の振り返り面談とか、 次の期の目標設定を決めるタイミングで、 最近どこと興味があるのとか、将来どういうキャリアを積んでいきたいとか、 イメージありますかみたいなところの話を聞いて、 それを聞いた上で、じゃあ次の期はこのプロジェクトにアサインしようかなとか、 こういうタスクをお願いしようかなとかっていうのを考えてたりします。 そうすることでやっぱりモチベーションって上がりやすいですよね。 はい、最後。 アサインタスクアコーディングトゥアビリティーアンドグロスパラランド。 サムシングダディスチャレンジングフォアジュニアプロジェクトメイビーボーリングフォアモアエクスペリエンストパーソンということで、 能力とか成長プランに合わせてタスクをアサインしましょうねということです。 はい、3.4.4のモチベーティングアンドチャレンジーテスティングはこんな感じでした。 最後の3.4.5のマネジングディストリビューティーティームズですね。 土地が離れているチームの管理については、ちょっと書いてはあるので、本当にさらっとといこうと思います。 マネジングディストリビューティーティームズにはユニークなチャレンジがあります。 もちろん土地だけじゃなくて会だったり、同じオフィスの中の会だったりもするんですけれど、 そういう距離が離れているチームのマネージというのは、それ独特の課題というものがありますよというふうに書いてあります。 どういう課題があるかというと、4つ書いてあって、 1つがマネジングアクロスタイムゾーン、タイムゾーンが違う可能性がありますよねというところ、 あとは文化的な違い、特に国をまたいでいる。 ヨーロッパだと隣の国の人たちと働くというのが日本以上に当たり前だったりするので、 でも国とか場所が違えばカルチャーも変わってくるというところがありますよね。 3つ目がマウンティブルラングウェイジーですので、複数の言語、そして最後の4つ目が ディフェンススキルレベルとエキスペクティションというところで、 これはあんまりディストリビューティーというのも関係ないような気がしますけど、 スキルレベルが違った、あるか期待値が違ったりというところですよね。 例えば、前の職場でベトナムのテストチームとかなりコラボレーションしていた地域があるんですけど、 やっぱりそこのスキルレベルだったりとか、そもそも事業会社でテストチームのリーダーだって マネージャーとしてバリバリ活躍していたっていう人は、前の職場では少なくともほとんどいないという状況。 新しく会社に入ってきてチャレンジするみたいな方が多かったりとか、 それまではずっとテスト実行だけやってきました、開発者が作ったテストを実行だけやってきましたみたいな方が 複数にいたりして、なかなかそういう方にはまずテスト設計からやりましょうねとか、 テスト分析とはなんだろうって話をしたり、そこから教えていくみたいなことをやっていたりもしました。 期待値というところもその通りで、ずっと自分のキャリアの中でテストの実行ばかりやっていた。 それで良いともし思っていたとしたら、自分のテスターとしてやるべきことはここまでというふうに線引きとかされちゃう。 あるいは周りのメンバーからの期待値としても、テスターというのはテスターなのかな、ここのチームはテストする人でしょうみたいな期待値もあるかもしれなかったりするので、 それが土地によって国が違ったりすると違いは確かに大きく出るので、そこのマネジメントというのは確かに大変だなというか、かなり苦労はしました。 もう少し距離が離れているチームの管理については少しヒントが書いてあるので、興味がある方はぜひシラバスをご覧ください。 ということで、今回もだいぶ長くなっちゃったな、もうちょっとできれば1チャプター10分で収めたいと思ったんですが、なかなか英語と日本語と両方読むと時間がかかってしまうようです。 でも英語のキャッチアップにもなれば良いなと思っております。ということで今日はここまでです。 # 今日のほっこり話🐀 今日の誇り話です。レオレオーニのお話をします。先日ですね、あの光江、渋谷の光江で今もやってますけれど、レオレオーニの 展覧会がやっていまして、そちらに行ってきました。土日ということもあって、子供もたくさんいてすごい わちゃわちゃしてました。レオレオーニさんは芸術家、絵本で、絵本作家って言うんですかね、とても有名な方なんですけど 代表作はスイミーとか、フレデリックとか、アレクサンダとゼンマイネズミとかあたりがとても有名かなと思いますが、 ネズミがすごい好きなんですよね、フレデリックですかね。今回、原画が展示されていて、すごい個人的には良かったです。良い体験ができました。 普段、絵本とかも今読まないので、なかなか見ないですけれど、あのギフトショップで本とかがあって、絵本を見てたんですけど、 やっぱりそこの、紙をちぎっているネズミとか、動物の体フォルムの部分は、紙をちぎって、ハサミで切るんじゃなくて、ちぎってこうフサフサ感というか、 モサモサ感を表現されているっていうのも展示で知ったんですけれど、そこのなんかギザギザ感とか、紙の厚さみたいなところっていうのは、原画じゃないと伝わらなくて、 絵本だとなかなか伝わらない部分だったので、すごく原画を見てテンションが上がりました。 ということで、今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はVoicyのトークテーマ、 良い会議にするには、についてお話をしていきます。 今回の放送を聞いて、 なるほどな、確かにな、学びになったな、 お深い楽しみだなという方は、 是非、画面右下のアートマークで いいねを押していただけると、とても励みになります。 学んだこと、感想、意見、悩みなどなど、 疑問とかありましたら、是非、 コメント欄でコメントをお願いします。 それでは、また明日お会いしましょう。 ごきげんよう。