# タイトルコール ようこそ、世界が広がるソフトウェア品質生。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質を 所を中心に日々、奮闘していることや 考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと テストや品質の世界を広げていきます。 # 英語と日本語で学ぶ、テストチームの開発 こんにちは。QnEngineerのさみです。 今日もわくわくしていますか? 今回はですね、英語と日本語で学ぶテストチームの開発というところで、 ISTQBのシラバス、エキスパートレベルテストマネジメントのシラバスの3.3章、 Developing the Testingについて、 英語と日本語でお話をしていこうと思います。 まず章のタイトルのDeveloping the Testingなんですけど、 テストチームの開発というところを育てていくニュアンスなのかなというふうに感触をしています。 そしてですね、この3.3の中にも、いくさんだな? 3.3の1、2、3、4、5、6、7、8まであるので、 ちょっと最初のタイトルだけリストアップを読み上げていきますね。 3.3.1、Developing Individuals、個人の育成とか開発。 2がSetting Goals and Objectivesなんで、ゴールとか目標設定。 3.3.3がDefining Clear Roles and Responsibilitiesなので、明確なロールとか責任というものを定義する。 3.3.4がIndividual Personalities and Roles Within Teamsというところで、 個人のパーソナリティとか役割、チームの中での役割というところですね。 3.3.5がSkills Developmentということで、スキルの開発、スキルを上げていくというところですね。 3.3.6がTraining Opportunitiesなので、トレーニングの機会。 3.3.7がMentoring、3.3.8がPerformance Reviews and Feedbackというところで、 人事効果みたいなやつかな、パフォーマンスのレビューとフィードバックという感じになっています。 今回もたくさんあるので、全部はピックアップできないと思いますが、 内容をかいつまんでと、あと自分の経験のところを交えて、考えも交えてお話ししていきます。 ということで、まず最初は3.3の大元点ですかね、 ディベロップできたテスティングのところが2分ぐらいしかないので、ここを読み上げていこうと思います。 Part of a test manager's role is to provide the necessary tools and opportunities to their team members so that they are able to successfully perform their current duties and improve their skills and capabilities over timeというところで、 テストマネージャーのロールの一部として、必要なツールだったり機会をチームのメンバーに提供することが求められています。 それは何のためかというと、メンバーがちゃんとパフォーマンスを成功できるパフォーマンスをしっかり出すというところとか、 Current duties なので今の責務に対してしっかりパフォーマンスを出したりとか、 彼ら彼女らのスキルというところをインプループ、改善する、あるいはインプループはスキルとか、 ケイパビリティ、能力とかをだんだんと時間をかけてインプループ、改善できるように、 そういう機会だったりとか、ツールを提供することが第一ですよ、必要とされていますよ。 それがテストマネージャーのロールですよというふうに書かれています。 続いて3.3.1はDeveloping Individualsということで、個人の開発について書かれています。 2つパラグラフに分かれていて、最初のパラグラフは日本語だけでお話ししますね。 マネージャーの責任の一部として、メンバー、人々の開発みたいなところがまず求められていますねということが書いてあります。 2パラグラフ目から読んでいきます。 Many organizations require or encourage their managers and employees to create a development plan which outlines areas of improvement and includes a roadmap on how to achieve the changes. というところで、多くの組織が求めている、あるいは招致している、マネージャーに対して求めたり招致していることっていうのは、 マネージャーと従業員に対して求めていることっていうのが、ディベロップメントプランを作るというところですね。 育成計画みたいな感じでしょうかね。どうやってスキルアップしていくかっていうところの計画。 それらの計画の中には何が書かれているかというと、改善の分野、areas of improvementとか、あとincludes a roadmapだから、 どのように達成していくのか、スキルアップしていくのかっていうところのロードマップも含めて、ちゃんと作っていきましょうねっていうことが求められています。 次の文か。 The roadmap may include such tasks as attending formal training courses, working toward a degree, self-study on a specific topic, taking on a new role or task, or working toward a testing certification. というところで、そのロードマップにはこのようなものが含まれているかもしれないですねって書かれていて、 フォーマルなトレーニングコースだから、公式なトレーニングコースだったりとか、あとディグリーを取る、大学とか大学院のやつですよね、学位かな。 あとはセルフスタディなんで、自学、特定のトピックに関する自学習とか、あとは新しいロールとかタスクに就くとか、携わるとか、 あとはテスティングサーティフィケーションなんで、資格ですね、テストの資格を取ったりってところが含まれていますという感じですね。 はい、というところで、ここから私の意見とか考えとかなんですけれど、どうですか?皆さん、プラン作ってますか? 個人の育成計画とか、あるいはその個人の目標設定とかの中で、そういうスクリアアップの項目だったりって入ってますか? 私はですね、必ず入れるようにしていて、救援チームの目標としても育成系の目標は必ず1個入れてますし、個人の、自分自身もそうだし、チームメンバーの目標設定のところにも必ず1個はスキル向上系の目標を入れてます。 大体はですね、救援チームのゴールとしては品質文化の醸成みたいなタイトルにしていて、その中で自分たちもキャッチアップをして、スキルアップをしていくし、 自分たちだけではなくて周りの開発チームだったり、他の当課の人たちも巻き込んで、一緒に品質とかってところを同じ目線で話せるようになるじゃないですけれど、 品質文化を作っていくぞみたいなところの1個の大目標。その中に各個人のスキルアップとかっていう目標が入ってたりします。 続いて3.3.2がSetting Goals and Objectivesということで、ところでゴールとか目標の設定についてですね、最初のパラグラフ1文目飛ばして2文目読むんですけど、 It is a test manager's responsibility to work with the individual test team members to mutually agree on a set of individual goals and deliverables and regularly monitor progress towards the goals and objectives. ということでテストマネージャーの責任として、個人のテストチームメンバーと一緒にお互いに相互に合意を取っていく。 高校のゴールだったり生化物に対しての相互で合意を取っていったりとか定期的にモニターをする進捗を確認をすると、 ちゃんとその目標とかゴールに対しての進捗がどうなのかをモニターするのがテストマネージャーの役割、責任ですよと書いてあります。 続いて3つ目のパラグラフを読んでいきます。 Test setting goals, the test manager should outline specific deliverables, what is to be done and how it will be achieved, and the time frame for when the goal or objective is to be completed, when it will be completed. ゴールを設定するときはテストマネージャーはアウトラインとして概要を書くべきです。 Specific deliverablesなんで、ちゃんと特定的なというか、1位で分かる生化物というものをアウトラインとして書く必要がありますよというので、 具体的にどういうことかというと、何がなされるのか、そしてそれがどのように達成されるのかというところを明記するということ。 明記すれば向こうを意識を合わせるということですよね。 あとはタイムフレームfor when the goalだから、タイムフレームというのはどういう期間でそれを達成するのかというのもきちんと分かるようにしましょうというところですね。 When it will be completedですね。 この後に測れない、計測できないとか達成できないものというのはゴールにはするべきではありませんよというふうに書いています。 この後にさらに具体例が書いてありますね。 それがちょっと面白かったので読んでいこうと思います。 For example, setting a goal to complete a set of test cases may not be realistic if the time frame is too short or if the incoming quality of the software is not sufficient. というところで1個の例として、テストケースのセットを完了させるというものを1個目標として置いたとして、 でもそれがもしタイムフレーム期間というのがめちゃくちゃ短かったりしたら、 あるいは入ってくるソフトウェアですね、テスト対象のソフトウェアというものがクオリティが十分じゃなかったら特定の期間にテストケースをやりきるみたいなことって現実的じゃないので、 こういうのは目標に入れるべきではありませんというふうに例を書いています。 # 続き 続いて、It is very important that test goals are fair and within the control of the person being evaluated. というところで、とても大事なこととして、そのテストゴールっていうのはフェア、公平で、 control of the person、その人の個人がコントロールできる範囲であることということ、 コントロールできる範囲で評価されるみたいなところがとても大事というふうに書かれています。 ここめっちゃ確かにというふうに思っていて、過去に何度もいろんな目標を達成、達成じゃないな、セットしてみては、 なかなかこれってゴールとして設定するのが良くないなと思ったものっていっぱいあって、 まさにテストケースの数だったりとか、見つけた欠陥の数だったりとか、 このプロジェクトのテストをやり切るだったりとか、リリースし切るみたいな目標っていうのも立てたことあるんですけれど、 必ずしも一位個人としてコントロールできないものが多かったりして、 特にテストってなると、そのテスト対象物のソフトウェアの状況、進捗だったりによって、 かなり左右されてしまう部分もあるので、 じゃあどのくらい、何だろうな、例えば不具合の数、このくらいに抑えるなのか、 あるいは逆にたくさん見つけるみたいなのは、あまり意味のない数字になっちゃうというのは、 本当にその通りだなというふうに思っています。 ちょっと次の文のことを先に話しちゃったようなんですが、次の文を読んでいきます。 Metrics such as number of defects found, percentage of the test cases passed, and number of defects found in production are not within the control of the individual testers. 全く今と同じ話をしていました。 メトリックスですね、例えば、ディフェクト、見つかった欠陥の数、あるいはテストケース、 パーセンテージ、あるいはプロダクション、本番環境で見つかった欠陥の数というものは、 個々人のテスターのコントロールの中にはないと、コントロールできる範囲ではないですよね、ということが書かれています。 続いて、 The test manager must be very careful not to encourage the wrong behavior by measuring the wrong data. ところで、テストマネージャーは、とても注意しないといけませんよと、 間違った行動だったり、間違ったデータに基づく計測によって間違った行動を促してしまわないように、とても気を付ける必要があります。 というふうに書かれています。 もうちょっとこのシラバス、2年ぐらい、もうちょっとかな、3年ぐらい前に読むべきでしたと思います。 次いきます。 3.3.3は、Defining clear roles and responsibilitiesというところで、明確にそのロールだったりとか責任を定義しましょうということが書かれていますが、 ここは時間の都合で割愛します。 その中にはですね、それぞれの、これですね、その1個人に対してテストアナリストを求めているのか、テクニカルテストアナリストなのか、 ツールデベロッパーなのか、テストマネージャーなのか、何なのかというところをちゃんと明示的にしないと評価というものは評価できないですね、 みたいなことが書いてありますので、興味ある方は原文を読んでみてください。 続いて3.3.4は、Individual personalities and roles within teamsということで、個人のパーソナリティ、性格とかですかね、パーソナリティとチーム内のロールについて書かれています。 ここは4つのパラグラフがあるんですが、ちょっと面白いなと思ったのが2つあるので、そこの2つを紹介していこうと思います。 1つ目ですね。 テストマネージャーとテスターの間のインタラクションなんで、会話っていうんですかね、というのはしばしば複雑で、 必要なスキルがないと間違った誤解に繋がっちゃったりとかするよねっていう話が書かれています。 次の文いきますね。 Test managers do not need to be psychologists, but they do need good interpersonal skills, which come from an appreciation of core dependent behaviorというところで、 ここが面白いなと思った文なんですけど、テストマネージャーっていうのは、サイコロジスト、心理学者である必要はないんだけれども、 でも、グッとインターパーソナルスキルだから、相互的にコミュニケーションをとるスキルっていうんですかね、がすごい大事ですよねというふうには書かれています。 で、コーディペンデントビヘビア。 確か心理学の用語で、共依存的な行動だったかなと思いますけれど。 共依存ともに依存するっていう感じなんですけど、今ちょっと簡単にGoogleで検索した感じだと、 共依存っていうのは自分自身に焦点が当たっていない状態のことなので、 自分の価値とかを周囲の基準だけで判断するとか、周囲の期待に応えることだけに必死になるみたいな説明が出てきました。 私なりの解釈ではあるんですけれど、チームメンバーとの深いコミュニケーション、相互理解みたいなところもしっかり、 テストマネージャーとして必要ですよっていうところを伝えたいのかなというふうに解釈しました。 もう一つ面白かったところを読んでいきます。 The test manager may want to invest in personality profiling of the individual testers, so that both the manager and the testing members have a better understanding of their individual behaviors. またこれもさっき言ったこととかぶるんですけれど、 テストマネージャーっていうのはパーソナリティのプロファイリングだったりとかを may want to invest だから、ちゃんと知りたいみたいなところですかね。 それは何のためかっていうと、 マネージャーとテストチームが相互にお互いのことをよりよく理解するためには必要ですよねというふうに書かれています。 続きが、a professionally administered personality test, such as Myers-Briggs type indicator, may be used to this end. どうやって個々人のパーソナリティを理解するかというところのやり方として、 パーソナリティ診断のMBTIというものが役に立つかもしれませんねというところで紹介されています。 会社によってはこういう診断を入社のときに診断をして、 社内で公開したりとか、ワンワンのときに使ったりとか、相互理解で使ったりとかってあると思うんですけど、 それの使い方、そういうツールとかっていうのはテストチームのマネジメントでも使えるんだなというところを学びました。 続いて、3.3.5はSkills Developmentというところでスキル開発に書かれています。 どういうスキルが含まれているかというところがリストアップされているので、そこのリストだけ紹介をします。 Tools、Skillsなのでそのままの通りツールを使うスキルですかね。 Technology Skills、テクノロジーのスキル。 Testing Methodology Skills、例えばスクラムというところでテストのやり方に関連するスキルというのでスクラムで紹介されていました。 ちょっとこれがなんでこのテスティングメソロジーとスクラムが私の中であまり結びついてはいないんですけど。 次がTechnical Testing Skillsというところですね。 例えばテクニカルテスティング、セキュリティのテストスキルとかまたちょっと他のテクニカルがついていないテスティングスキルとちょっと違うスキルが必要かなと思います。 Domain Knowledge、ドメイン知識ですね。 最後がSoft Skills、例としてコミュニケーションが書かれています。 ここら辺のツールを使うスキルもそうだし、テクノロジーのスキルもそうだし、 ドメイン知識だったりソフトスキル、コミュニケーションスキルというところもスキル開発としてはとても必要な要素になっていますよということが書かれています。 確かにソフトスキルも結構大切だよなって思ったりします。 特にテストエンジニア、Qエンジニアだと同じことを言うバグ報告一つとっても伝え方も大事になってくるし、言うタイミングだったりとかもあるし、 結構ソフトスキルというかソフト面でも気にしていることを確かにあるなと思ったので、納得の内容です。 続いて3.3.6のTraining Opportunitiesは飛ばします。 3.3.7、メンタリングも飛ばします。 最後3.3.8のPerformance Previews and Feedbackをお話ししていこうと思います。 最初のパラグラフは英語を吹っ飛ばして日本語で翻訳していきたいと思います。 多くの会社ではそれぞれのエンプロイン従業員に対して年単位のパフォーマンスレビューを行うことを求めています。 そこではAvion Goalsなんで、こういう取ったゴールとか目的に対してどうだったのかというレビューがされたりとか議論がされたりします。 それによってエンプロインサラリー、お給料とかボーナスとかステータス、役職みたいなところが決まってくるというわけですね。 テストマネージャーというのはコンタクト、コーポレート・ヒューマン・ウィソーシスだから、HR部門の人に連絡をするコンタクトをして、連携をして、 どういうパフォーマンスレビューにとってどういう情報が必要なのか、何が必要なのかというところをしっかりコンタクトする、連携する必要がありますねというふうにまず前段として書かれています。 2パラグラフ目いきますね。ちょっとあと1分では終わらなさそうなんで次のチャプターに行きます。 # さらに続き 読んでいきます。 パフォーマンスレビューの準備をするときに テストマネージャーは情報を集めるべきです。 どんな情報かというと、テストチームメンバーの 過去の評価機関の仕事というところからも 情報を集める必要がありますと書かれています。 ということで、どういうアウトプットというか 成果物というか仕事を集めるかというと、 そのテスターによって作られた、例えばテストケースだったり ステータスレポート、進捗報告書とかだったり そういうものを見ることで情報を得ることができます というふうに書かれています。 次、今続きます。 私、めっちゃその通りだなと思ったんですけど、 テストマネージャーは考える。 他の従業員の意見というところも聞きたいでしょうね というふうに書かれているわけですね。 どういう従業員に意見を聞きたいかというと、評価対象、レビュー対象の個人と密接に仕事をしているメンバー、 エンプロイからの意見というのは聞きたいですよね というのは本当その通りだなと思っていて、 私がQHMリーダーをしていたときにチームメンバーが 各プロダクトの担当QAをやっているわけです。 自分はQHM全体を見ているとなると、各プロダクトでのQHMのチームメンバーの動きとか どういうふうに動いているかというところを 全部が全部見えているわけじゃないですね。 もちろんメンバーが作ったテストケースを見たりとかすれば、 ある程度のテストスキルを見たりとかもできるんだけど、 ソフト面でのコミュニケーションがちゃんと取れているのか みたいなところは全然わからない。 全然というか、なかなか把握しきれないし、 テストチームのメンバーからのワンワンでの情報だけだと不十分だったりするので、 当時やっていたのは開発チームのリーダーの方と 評価の前のタイミングとかで、 あるいは月1のワンワンを入れさせてもらって、 定期的に情報を聞いているこのメンバーの動きってどうですかとか、 もっとこうしてほしいとは思いますか、みたいな 期待値のところだったりとかをいろいろヒアリングしたり、 訂正的な情報を得たりということはやっていました。 次いきます。 This can be done by creating a questionnaire which asks specific and open-ended questions about the employeeということで、 アンケート的なところの質問表みたいなものを作って、 あるいは特定のものだったりオープンエンドクエスチョン、 オープンエンドクエスチョンという形で質問表を作って、 そのメンバーについて聞くことができますねというふうに書かれています。 次いきます。 Performance reviews incorporate both objective evaluation, work products, test performance, as well as subjective evaluation, the manager's opinion on the performanceというところで、 そのパフォーマンスレビューというところは両方の定量的、 ちょっと私のかなり解釈入っちゃってますけど、 定量的な評価と適正的な評価、 両方必要ですよねというふうに私は感触をしています。 という感じでした。 また早口になってしまいましたが、 今回はエキスパートレベルのシラバステストマネジメント 3.3のディベロッピング・ダテストチームについてお話をしていきました。 何か学びやこれやってみたいなという内容がありましたが、 あったらぜひコメントで教えてください。 # 今日のほっこり話🌹 今日のほっこり話です。結婚記念日の話をします。 実はですね昨日の7月7日が結婚記念日でした。 私自身はですねグロッキーで、体調悪かったので、本当1日中寝てました。1日中寝てたらだいぶ回復しました。 じゃああと、沢窪香さんが4月7日の放送で入籍記念日という放送をされていて、 お揃いだーと思って勝手にテンションが上がったというか、勝手に新規感を感じてほっこりしております。 以上、今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、スピードは価値という話をしていきます。 結構自分の中で大事にしている価値観だったりもします。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 是非、画面右下、ハートマークでいいねを押していただけるととても励みになります。 また今ですね、オフ会を絶賛企画中でございます。 オフ会では読書会とお食事会を行います。 これまでとはまた変わった別のコミュニティで新しい仲間とお話をしませんか。 興味がある方はチャンネルページの、チャンネルのトップに固定してあります放送をお聞きください。 日程調整のGoogleフォームの締め切りは、今週の日曜日、7月13日の日曜日のお昼となります。 なんとなく興味ある方どのくらいいるのかな、ちょっとこの人数を把握したいなと思ってますので、 ぜひご協力お願いします。 それによって部屋がどうなるかとか場所がどうなるかとかを少し考えるかもしれません。 それではまた明日お会いしましょう。ごきげんよう。