# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、旧エンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # 前半 こんにちは、経営人柳澤美衣です。今回はISTQBのエキスパートレベル、テストマネジメントのシラバスを今、斜め読みしていますので、ちょっとそれの読書ログ的な話をしようかなと思っております。 ISTQBにエキスパートレベルってあるのご存知でした。私もたまたまそのシラバスの一覧見てて知ったんですけど、 ファウンデーションレベルとアドバンスドレベルは日本語訳もされているので、知っている方も多いかなと思うんですけど、さらにプラスアルファでスペシャリストとか、 エキスパートレベルっていうのもあるそうです。今回はエキスパートレベルのシラバスのうちのテストマネジメントのシラバスについての話です。 このチャプターにURLを入れておりますので、ISTQBのサイトをスクロールしてずっと行くと、ダウンロードマテリアスだったかな、中にシラバスっていうのがありますので、そちらからPDFをご覧いただけます。 今日の流れなんですけれど、最初にテーブルコンテンツというところで目次を見ながら全体像でどういうことが書かれているのかっていうところをお話しします。 その後に特に気になるコンテンツについて2つか3つぐらいピックアップして中身を読んでみつつ、考えたこととか学んだこととかお話ししようかなと思っております。 最初がテーブルコンテンツですね。目次というところで、大きい章が1章から11章まであるんですけれど、 1章目がイントロダクショントゥディスシラバスということで前提とかシラバス自体の説明というのと、あと10と11ですね。10章がリファレンシーズ、11章がアペンディックスなので、実質的なその中身としては8章分になります。 今各章のタイトルを見てるんですけど、学習時間が結構ゆっくりですね。JSTKBとかISTKBのシラバスって学習時間の目安時間が書いてあると思うんですけれど、例えば2章目テストミッション、ポリシーズ、ストラテジーズ、ゴールズというのが555分みたいな、 初っ端からめちゃくちゃボリュームの大きそうなトピックが載ってたりします。次の3章目もマネージング・ダ・テスト・チームって書いてあるんですけど、855分ということで、これまたかなり大きなトピックですね。 このシラバスの全体像に戻ってくるんですけど、最初2章目でテストミッション、ポリシー、戦略とかゴールっていうところがあって、大冗談みたいな話があって、その後に3章でマネージング・ダ・テスト・チームの管理っていうところがある。 その4章目がエクスターナル・リレーションシップのマネージメントって書いてあるので、テスト・チーム外との関係性っていうのがあって、5章がマネージング・アクロス・ダ・オーガニゼーションだから、組織横断みたいな感じ、さらに広い範囲でのマネージング、マネージの話になっているっていう感じですね。 6章からはプロジェクト・マネージメント・エッセンシャルズなんで、プロジェクト・マネージメントのことが書いてあって、7章がテスト・プロジェクト・エヴァリエーション&レポーティングなので、6章以降がプロジェクト内での動き方みたいになっているのかなというふうに読みながら考えております。 で、8章目がテスト・コンシデュレーション・フォードメイン&プロジェクト・ファクターということで、これもドメインとかプロジェクトのためにテストで考えるべきことみたいな感じですかね。 はい、で、最後の9章がエヴァリエーティング・エフェクティブネス&エフィシェンシーというところで、効果的・効率的にできているかみたいなところなんですかね。テスト・プロセスのメトリックスとか、プロジェクトの振り返りみたいなことが書いてあるようです。 はい、で、ここまでの内容をまとめると、もう結構3つに分けることができるのかなと思いまして、最初がミッション・ポリシー・戦略・ゴールとか大冗談の話、真ん中がいろんなマネージングの話が載っていて、まさにこのシランパスの肝かなと思うんですけれど、 テストチームの管理もそうだし、テストチームのリーディングというところもあるし、さらにそのテストチームだけでなくて、他のチーム外とのリレーションシップだったりとか、組織横断でのマネージングというところも書いてあります。 で、3部目っていうんですかね、最後のところがプロジェクトマネージメント関連のお話というところで、そもそもエッセンシャルズの話、本質的なところ、基本的なところから始まって、テストプロジェクトの評価やレポーティングというところだったり、あとはプロジェクト内で考えるべきこと、テスト・コンシデュレーションズなんでテストで考えるべきことみたいなところが書いてあるという感じですね。 プラスアルファは効率的、効果的にできているかというところの評価についても書かれています。 で、後半戦ですね、この目次見てて私2カ所というか3カ所ちょっと気になったところがあるので、そこをピュークアップして深掘りしていきたいと思います。 1カ所目と2カ所目っていうのが、マネージング・エクスターナル・リレーションシップスなんで、その関係性、テストチーム外との関係性と、あと組織横断での管理みたいなところ、要はテストチーム外とのコミュニケーションどうやったら通ったらいいのかとか考えたらいいのかみたいなところが1つ気になるので、ここを深掘ろうと思います。 で、2つ目が効率性とか効果的なのかみたいなところの評価のメトリックスが気になるので、この2つ深掘っていこうかなと思います。 1つ目、2つ目のところは4章と5章ですね。なので、4章の28ページ目から覗いていこうと思います。 今、4.2のタイプス・オブ・エクスターナル・リレーションシップスってところを読んで分かったんですけど、このエクスターナルっていうのは社外のってことですね。 私、てっきりテストチーム外のっていうふうに解釈しちゃったんですけど、確かにエクスターナル・リレーションシップスここで言ってるのは基本的にはサードパーティーとか、社外の別の会社の人たちが開発をしたものを自分たちでテストするとか、そういう社外との関係性という話でした。 で、4.4のコミュニケーション・ストラテジーズっていうところを少し読んでるんですけど、例えばですね、ロケーションが違う場合とかだったら文化的な違いに気をつけましょうねとか、もしオフショアで開発とニットテストをお願いしているっていうプロジェクトであれば、 ミクリでステータスレポートをちゃんと出してもらうように要求をしたりとか、あとデイリー、毎日に不具合なレポートをしてもらうとか、あとは学習とかかなでちゃんとお話ししましょうねみたいなところのアグリメント、合意っていうのをしっかりとっておきましょうねというようなことが書かれております。 確かに自分の経験でも、オフショアではないんですけれど、海外事業所のグループ会社で開発をしているプロジェクトで自分がテスト担当者というかテストマネージャーとして入ったことっていうのがありまして、何をもって完了とするのかみたいなところに意思がずれてるってことはしょっちゅうあったので、 成果物を定点的にというか毎週とか毎日とかで見るっていうのは結構大事だなというのは読んで思いました。実際にあったのは単体テストまでを書くみたいなところが伝わってなくて、プロダクトコードの方は書いて開発担当者は終わりと思っていたと。 なのでその話を聞いて、やばいじゃんというか、自分が入っていくその後の手動テストのところで思っていた、当初想定したというよりもかなり細かくテストを実行したみたいなこともあったりしました。 私の経験は社外の人ではなくて同じグループ会社というか同じ会社の人みたいな関係性であったんですけど、それが社外のサードパーティーの会社になるとさらにコミュニケーションって反ずつというか何のどこまでやってもらうのかっていう決め事はもっと大事なんだろうなというふうに思います。 続いてですね、4.6のマージングテストスターディジーのところに出たんですけど、まさに今しゃべったことが載ってました。テストマネージャーにとって最も難しいプロジェクトの1個っていうのが、どこまでがサードパーティーが行うのかというところを決めるみたいなところですかね。 ここの2は複数の拠点かもしれないし、あと複数の組織かもしれないし、複数の社内社外のグループかもしれませんというふうに書かれています。 要は社内外両方を含めてテストスターティジーというかテストでこういうことをやっていかなきゃいけないというものがあって、それを誰がどこまでやるのかというところの役割分担っていうんですかねっていうのが1個難しいというふうに書かれています。 特に社外の人というふうになると契約内容にもよって変わってくると思うので、例えば業務委託なのか、自宅開発なのかみたいなところとかでも、想定した時間内で終わらなかったものができなかったときにどうするのかみたいなところの稼働時間だったりお金のやり取りみたいなところが調整するのは結構面倒そうですね。 確かに自分の経験としても過去に海外事業所のメンバーと一緒に開発をするというところはやったことがあって、先ほど言ったように単体テストはどこのチームでやるのかという話がうまくかみ合ってなかったこともありますし、あとはその海外事業所と日本と両方でテストチームが一緒に絡むみたいなプロジェクトもあったりして、 インテグレーションテストまでは海外事業所の方のテストチーム、経営チームでやって、その後の最後のシステムテストのところを日本の経営チームの方でやりますね、みたいなこともお話をしたことがあります。そのときもフローズみたいなのを作って、ここからここまではどこの拠点の誰で、どこのチームでみたいな話とかをディスカッションしました。 # 後半 あとはですね、社外とのやりとりでいうと、テストベンダーさんに入ってもらうことが多かったりもするので、 例えば稼働時間で契約を結んでいる場合とかで、この稼働時間内にテストの設計とか事故とかが終わらなかった場合にどうするのかみたいなところは、 お金と相談しながら残業してもらうのか、自分の会社の方で巻き取るのかみたいなところの判断はよくしてたりします。 はい、ということでここまでが4章ですね、マネジング・エクスターナル・リレーションシップスの話でした。 続いて5章目のマネジング・アクロス・ダウン・オーガニゼーションというところで、テストチームを超えたマネジングの話にしようと思うんですけど、 思ったより4章でたくさん時間を使ったので、5章のところはさらっとトピックスだけ、キーワードだけ拾っていこうかなと思います。 5.1のイントロダクションのところに書かれているのが、効果的にマネジングするということになると、 それはテスト組織だけじゃなくて、それ以上以外、その外側の開発チームを含めてのマネジングなのかなとか、 あとコミュニケーションとか情報のシェアというものが必要になってきますというふうに書かれています。 もう少し具体的にどういうことをやっていく、アクションをするべきなのかというところで、 例えばテストの価値についてを売り込むだったりとか、テストチームを守る、サポートするということとかですかね、 というのもテストチームというのは、いい意味でも悪い意味でも、その外側の組織に対しては脆弱であることがよくあるので、 テストマネージャーはそのテストチームを守る必要があるみたいなことが書いてあったりします。 他のアクションですね、テストマネージャーに求められるというか、やるべきアクションというところだと、 ステークホルダーとのコミュニケーションとか、関係性を構築するとか、品質のアクティビティというものを擁護していく、支援していくみたいなことだったりとか、 あとツールですかね、ツールのインテグレーションみたいなのが書かれています。 1個だけそのステークホルダーのコミュニケーションってどういうものが含まれるかというところをご紹介、 テラバスに書いてあることをご紹介しますと、5.4のステークホルダーコミュニケーションの中に書いてあるんですけれど、 コミュニケーションの情報として含まれるのはテストのプロジェクト自体だったりとか、 あとテストのステータスだったりとか、特定のディフェクト障害のステータスだったりとか、 あと不害のトレンドだったりとか、テストプロセスの効果的、効率的かどうかみたいなところ、 その他インディケーター、指標メトリックスみたいなところですね。 そういった情報が適切なタイミングで、ステークホルダー適切な人に共有されていることが大事ですよねというところが書かれていて、 優秀なテストマネージャーというのは双方向のコミュニケーションということが大事だよねということもしっかり分かっているというようなことが書かれていたりします。 ということでここまでが5章ですね。 マネージングアクロス・オーガニゼーションというところで、テストマネージャーがいろんな人に対していろんなアクションをしなきゃいけないということが盛り盛り書かれている章でした。 最後3つ目が9章ですね。 エヴァリュエイティング・エフェクティブネス&エフィシェンシーというところを読んでいこうと思います。 9.1のイントロダクションに書かれているのは、テストマネージャーは継続的に効率性だったり効果的かどうかというところを評価しないといけないですよというのと、 あと今進捗しているテストに関して、テストプロジェクトだけではなくてその改善のもの、改善についてもちゃんと評価していかないといけない、効率的効果的かというところを評価していかないといけないですよというふうに書かれています。 続いて9.2のエフェクティブネス・エフィシェンシー&サティファクション・メトリックス・フォー・ダ・テスト・プロセスというのがすごい読んでいて面白いです。 面白いというのは私の知らない情報もいっぱい載っているので、もっとちゃんと時間をかけて勉強しますという意味なんですけれど、 具体のエフェクティブネスなんで、効果的かどうかのメトリックスと、あとエフィシェンシー、効率的かのメトリックス、あとサティファクションなんで、満足度のメトリックスというのが具体で書いてあります。 例えば効果的かどうかのメトリックスとして、パーセンテージですね。リクライアメントをどのくらいテスト条件でカバーしているかのパーセンテージだったりとか、テストによってカバーされているテストコンディションのパーセンテージとか、見逃してしまったディフェクト障害の割合とかというのがあります。 あとは効率的かのメトリックスとして、テストプランへのアンマネージのチェンジ、意図してないとか想定しなかった変更に対してどのくらい時間とか期間とかリソースがかかったかみたいなものだったり、テストが自動化された割合だったり、過去のプロジェクトでの学びによってどれくらい今回のプロジェクトの工数だったり期間とかリソースが節約できたかみたいなところも書かれています。 もう一つですね、サティスファクションメトリックスということで満足度のメトリックスってこれまで私全然意識してなかったので新しい発見なんですけれど、例えばステークホルダーへのサーベイの結果だったりとか、あとテストレポートを受信している人へのサーベイだったりとかが満足度のメトリックスとして書かれています。 あとはですね、9.2の最後に注意事項というか書かれていて、このテストプロセスのメトリックスというのはプロジェクト全体のとか組織全体の行動とか活動とかによってかなり影響されるよというところが書かれています。 上流工程ですね、システムの要求とか仕様とか設計とかコーディングユニットテストみたいなところを含めて効果的にできているかというのがそのテストプロセスのメトリックスに大きく影響していきますよというところが書かれています。 これは本当におっしゃる通りだなというふうに感じていて、テスト設計とかテスト実行のところだけ頑張ってもなかなか全体の品質というのは上がらないというか、テスト活動自体は品質を上げないので、PRDとかその要求を作るとこ、仕様を作るところの活動の改善というんですかね、そこから品質を作り込むみたいな活動をしていかないと全体の品質、プロセス品質、プロダクト品質というのは上がってこないかなというのは本当に強く思っているのでとてもアグリー。 あと9.3のところではテストポリシーの目的、目標に対してどのくらい効果的、効率的にできたかというところのメトリックスというのも書かれています。 一例として1個だけ紹介すると、重大な障害というものがちゃんと見つけることができたのかみたいなところが結構例えば1個典型的なテストの目的としてあるので、それに対して実際に検出できた結果はどのくらいだったのかとか、プリティカルな障害を見つけたパーセンテージはどのくらいだったのかみたいなメトリックス、具体的なメトリックスがいくつも紹介されています。 はい、ということで今回はISTQBエキスパートレベルテストマネージャーのシラバスを斜め読みして、その読書ログということで学ぶこと、考えたこととか書いてあることをご紹介しました。 具体的な内容が気になる方はぜひシラバスを読んでいただきたいと思います。 シラバスは全部英語なんですけれど、翻訳サービスだったりとかLLM使えば省エネでインプットできるかなと思いますので一緒に頑張っていきましょう。 私も今回斜め読みしただけですけれど、知らない情報とか新たな学びがありそうだなと思ったので、もうちょっと時間をかけてしっかり読んでいきたいと思います。 # #75のコメント返し🥰 コメント返しのコーナーです。今回は75話目のコメント返しをします。 1週間前はですね、QAエンジニアは魅力品質にどう貢献できるのかという話をしました。 コメントはみずけんさんからいただいております。いつもありがとうございます。 魅力品質って本当昔から言われてるけど、QA現場では使ってみて使いづらいところをフィードバックするくらいかな。 魅力品質、利用時品質、バリデーション、UI、UXとかありますけれど、何がどう違うんですかね。 商品企画部門的な人がやってるのかなとコメントいただいております。 そうですよね、確かにQA現場でテストしててっていう時だとここら辺使いづらいとかは、フィードバックは確かに良くしますよね。 あとはですね、利用時の品質っていうのは多分システムの品質との単位で使われている言葉なのかなって私は思ってたりとか、 あとバリデーションはですね、ベリフィ、ベリファイ、ベリフィケーションとバリデーションの違いみたいなのよくお話ありますよね、確かに。 その辺、また今後の放送のネタにさせていただこうかなと思います。 ありがとうございます。以上、コメント返しでした。 # 📣放送/相談/コメントリクエストを募集中！ 放送・相談・コメントのリクエストを募集中です。 おしゃべりリクエストボックスという名前のGoogleフォームを作りました。 このチャプターにリンクを貼っております。 2025年3月31日までの期間限定でトライアル運用中です。 こういう話を聞きたい、相談に乗ってほしいなど、ご意見をいただきたいです。 一緒にこのチャンネルを盛り上げていきたいので、あなたの投稿をお待ちしております。 # 次回予告 今回も最後まで見ていただきありがとうございました。 次回はですね、QAエンジニアのお仕事ってバグを見つけることだけじゃないんだよというところをお話ししようかなと思っていて、 他の業種の方でも役に立ちそうな失敗から学ぶ仕組み作りについてお話ししようと思っております。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は、 是非、画面右下、ハートマークでいいねを押していただけるととても励みになります。 コメントもいつもありがとうございます。 より多くの方に知っていただきたいので、ガシガシシェアしていただけると嬉しいです。 それではまたお会いしましょう。ごきげんよう。