# タイトルコール ようこそ、世界が広がるソフトウェア品質へ。 このチャンネルでは、QAエンジニアのサミーが、 ソフトウェアテストやソフトウェアの品質保証を中心に、 日々奮闘していることや考えていることをお話しします。 毎日、お昼の12時30分に配信しています。 ゲストの方やリスナーのあなたと、 テストや品質の世界を広げていきます。 # プロジェクト管理 こんにちは、経営エンジニアのさみぃです。今日もワクワクしてますか。今回はISTQBのエキスパートレベル、テストマネジメントのシラバスより、 6章のプロジェクトマネジメントの中の6.2.4と6.2.5についてお話をしていきます。 6.2.4のほうは、マネージング&トラッキングプロジェクトということで、プロジェクトの管理とトラッキング、追跡について、 そして、6.2.5がDealing with Trade-offsなので、トレードオフの取扱いについて書かれています。 ということで、最初は6.2.4、マネージング&トラッキングプロジェクトの話です。 この章は、1、2、3、4、5、6個のパラグラフに分かれています。最初、1つ目のパラグラフを英語で読んでいきます。 The key to effectively managing and tracking a project is to make an estimate and monitor adherence to that estimate. ということで、効果的にプロジェクトをマネージしてトラッキングするためのキー、大事なポイントというのは、 to make an estimate なので、見積もりを作って、そしてモニターするですね、adherence to that estimate。 その見積もり、見積もりの通りに進んでいるかどうかをモニタリングすることが重要というふうに書かれています。 次も読んでいきます。 Since budget and schedules are usually based on these estimates, tracking to the estimate is a sensible way to quickly spot variances and to improve the estimation process. ということで、バジェット予算とスケジュールというのは、だいたいこの見積もりに沿っているので、 この見積もりをトラッキングすることというのは、とても大事ですよと、 ちゃんと、quickly spot variancesって差分だったと思うんですけど、見積もりと実績の差ですよね。 そして、to improve the estimation process なので、見積もりのプロセスを改善するためには、ちゃんとトラッキングすることが必要ですよというところが書いてあります。 続いてまた読んでいきます。 For example, if a test project is taking longer than that was estimated, the test manager should determine the cause. ということで、例えば、もしテストプロジェクトというのが思っていたより見積もりよりも長く時間がかかっている場合は、 テストマネージャーというのは、その原因というところを判断していく必要があります。 続きも読んでいきます。 Are test cases being executed more times than expected? Are there more defects than estimated? Is testing being blocked or rendered inefficient by test system problems? ということで、具体例が書いてあるんですけど、実行されたテストケースというのが思っていたよりも時間がかかったんだろうか。 あるいは、思っていたよりも、見積もっていたよりもたくさんの欠陥、ディフェクトが見つかったんだろうか。 あるいは、テストがブロックされたりとかで効率的に実行できなかった、非効率だったからなのかなどなどというのが考えられます。 最後に自分で読んでいきますね。 When the test manager has a schedule and estimate to track to, it is easier to spot variances and to address quickly those variances. ということで、ここまでの内容のまとめですよね。 もしテストマネージャーというのがスケジュールだったり、見積もりというものを持っていたら、 トラックするためのそういうものを持っていたら、簡単にその差分というところを特定することができますよねって話でした。 次のセクションは、英語を読まずに日本語で軽く説明していきます。 たまにいくつかのケースとして、テストチームが差分の計画と実績の差異の原因というものを直せないことがあります。 例えば、もしソフトウェアの品質が悪くて思っていたよりも、結果がたくさん見つかってしまった場合だと、 テストマネージャーというのは受け取りですよね。 テスト対象のソフトウェアの受け取りというものが十分だったのかとか、どこに問題がありそうかというところをちゃんとディテクト、探偵というか探す必要がありますよねというふうに書かれています。 例えば、ユニットテストが十分じゃなかったのかとか、予定していたインテグレーションテストが行われていなかったのかとか、 こういう情報というのが、プロセス改善のどこの領域を改善したらよいかというところもサジェストしてくれるし、 プロジェクトチームがこれらの問題を解決するためにも必要な情報、どういう問題があってどういう状況なのかというところをしっかり理解するためには必要な情報になってきますということが書かれていました。 3つ目のセクションに行きます。英語を読んでいきます。 1行目は、アジアルのチームにおいては、この差分というのが、原因というのが環境の中で起こって、かつチーム内で解決されるという傾向がありますよというふうに書かれています。 次が、スクラムのプロジェクトにおいては、こういう見積もれないとか予測できない差分を、 見積もれないとか予測できない差分を特定して徐々に解決していくということは、スクラムマスターのメインのタスクですというふうに書かれています。 すぐには解決できないような大きい障害を、スクラムの用語としてインペリメント、日本語だと障害事項の解消とか特定と解消というのは、スクラムマスターのメインのタスクですよというふうに書かれています。 次、読んでいきますね。 スクラムというのは、アジャイルの開発の方法論で、特に特定のチームロールと用語によって特徴づけられるアジャイル開発手法ですよというふうに書いてあります。 Team members may be defined as either core team members or ancillary team membersというところで、チームメンバー最後はちょっと余談というかおまけの情報に見えますけど、チームメンバーというのはそのコアのチームメンバーとアンシュラリーなので補助的なメンバーに分けられますよというふうに書かれています。 ここまで読んでてちょっと思ったことは、そういういろんな課題とか見積もりに対してうまくいくこと言ってないこととかあるんだけど、その問題の解決のためにはスクラムマスターとの協同、協業が必要になってくるんだよな、それはそうだよなとか思いながら考えてました。 特にアジャイル開発とかスクラムで開発するという文脈においては、メトリックスというか何を見積もりをして何をトラッキングしていくのかというところもチームで同じ認識を持って、毎週だったりイテレーションごとスプリントごとというのでしっかりモニターしていくといいんだろうなというのを考えています。 これまでの自分の経験とかを考えてみると、見積もりというところがなかなかうまくいってなくて、じゃあ見積もりに対して今順調なのかとか、全体のプロジェクトという意味でもある程度精度のある見積もりに対して今順調なのか、このままで終わるのかみたいなところも含めて、まだあまり自分で登壇とかで発表するほどうまくいった成功事例とかはないので、引き続き模索していきたいなという感じです。 次のパラグラフを読んでいきます。 今話したことが出てきましたね。プロジェクトを管理してトラッキングするに必要なのはプランですね。 メジャーブルメトリックスなんで、計測可能なメトリックスというものをちゃんと持ってそれを評価をしてという、あちこちのプロジェクト、あちこちのポイントで評価をしていくことが必須ですというふうに書かれています。 次読んでいきます。 めちゃくちゃ耳が痛いですね。 もう無くないプロジェクトだと、クイックリゲットオフトラックなんで道筋というかトラックからどんどん落ちていっちゃう。あっという間に落ちてしまいますよと。 もし誰も知らないプロジェクトがこのスケジュールでどのポイントをどの地点に行ったら良いのかというものを誰も知らなかったら問題がどこかというのが見つからないまま検出されないままになってしまいますよね。 めちゃくちゃ耳が痛いです。 次のパラグラフ読んでいきます。 # プロジェクト管理続き、トレードオフ 間違えました。パラグラフではなくて、次の文章ですね。 The test manager should work with the project manager to define the measurable quality goals and to track the progress toward those goals. ということで、テストマネージャーは、プロジェクトマネージャーと一緒に協業をしてですね、どういう品質のゴールというものを定義するのかとか、 どうやってトラックをするのか、これらのゴールに向かっての進捗というものをトラックしていく必要がありますよというふうに書いてあります。 There are often trade-off decisions that must be made as part of managing a project. For example, is it better to accept the late delivery of a feature that is highly desired by the business but risk the quality of the project? ということで、もう先まで読んじゃいましょう。 Being able to quantify and explain the risk so the project team can take the best possible decisions is the job of the test managerというところですね。 時にはトレードオフの決定を下さないといけないことがあるんですよと書いてあって、 例えば、Is it better to accept the late delivery? なので、ビジネスサイドの人から強く求められている機能の提供、デリバリーを遅らせるというのかな、 後にするということを受けるのが良いのだろうかと。 でも一方でクオリティ、プロジェクトのクオリティのリスクはあるんだけど、どっちを取るのかという話だったりとか、 そんな時に大事なのが、リスクを定量化して説明できるということができると、 プロジェクトチームが可能な限り最良の決定を下せるようにすることができるので、 とても大事なテストマネージャーの仕事であるというふうに書かれています。 リスクの定量化、難しいな、ちょっと今の自分にまだできる自信はないんですけれど、 今でもプロジェクトチームが最良の決定を下せるように、今どういう品質のリスクがあるのかというのか、 どのくらいなのかというところはそうですね。 定量的までは言えないけれど、どのくらいやばいのかというのは話しているかなという気がします。 次のパラグラフは飛ばして、最後のパラグラフを読んでいきます。 Test Case Execution Resultsということで、ここが具体で書いてあるんですけれど、 メトリックス、プロジェクトをトラックするためのメトリックスとしてこういうのがありますよという紹介されていて、 テストケースの設計の完了のパーセンテージ、割合ですね、どのくらいのテスト設計が完了しているのか、 コストアップクオリティだから、品質のコストですかね、 あとが、結果を見つけられたパーセンテージ、結果を実際に見つけたのと予想との比較の数、 あとはテストケースの実行結果というものがプロジェクトのメトリックスになり得るよというふうに書いてあります。 最後の一番ですね。 Developer metrics such as root cause, defect removal effectiveness, feature completion, and unit test coverage should also be available to the testing. というところで、他にも開発者のメトリックスとして、 root cause、such as root cause、root causeってroot根本ゲインかな、 defect removal effectivenessは、欠陥が除去された、それの効果とか、機能が完了した、機能の完了とか、あとはユニットテストのカバレッジというものが紹介されています。 この辺、まだまだ自分の解像度低そうだなと思ったので、Azure Metricsの本とか改めて読み返してみようかなというふうに思いました。 ここからは、6.2.5のDealing with trace ofについて話していきます。 6.2.5は2つのパラグラフに分かれています。 最初の方は、ちょっと日本語で話していこうと思います。 完璧なプロジェクトっていうのは滅多にありません。 ほとんどのプロジェクトではトレードオフっていうのが必要になってくる。 どんなトレードオフとかっていうと、品質、スケジュール、予算、そして機能です。 これらのトレードオフっていうのは、プロジェクトの最初だったり、あるいはだんだんテストフェーズを進んでいくにつれて明らかになってきます。 次から英語で読んでいきますね。 The test manager should be aware of the interdependencies between these project components and be prepared to participate in trade-off decisions. というところで、テストマネージャーはこれらのinterdependenciesだから、相互関係とか依存性みたいな感じですかね。 これらのプロジェクトコンポーネント要素を、相互の依存性っていうところにちゃんと注意をして気づいていて、 そして、このようなトレードオフの決定に参加すると、それに準備しておく必要がありますというふうに書かれています。 次読みます。 While the test manager should always defend quality, there are times when quality is not the most important aspect of the project. ということで、これも大事そうですね。 テストマネージャーっていうのは、いつも品質を守るということが多いんだけれども、 時には品質っていうのが一番大事な要素、側面ではない時もありますよねっていうことです。 次読みます。 The test manager must be able to objectively analyze what changes in the schedule, budget, or feature set may affect the overall quality of the project, for better or worse. というところで、これも大事なメッセージを感じるんですけど、 テストマネージャーっていうのは客観的に分析しなければなりません、できなければなりません。 何を分析するかっていうと、どんな変更がスケジュールにあったのか、 どんな変更が予算だったり、機能セット、フィーチャーセットにあったのか、 それらの変更がどのように全体のプロジェクトの品質に影響を与えるのかっていうところを、 ちゃんと客観的に分析をできなきゃいけないんですよって、 その変更が良くても悪くてもねっていう感じです。 最後の一文かな。 ということで、一例として予定していなかったフィーチャーをプロジェクトに足すことになったとします。 そうするとですね、オーバーロールクオリティは下がっていきます。 何でかっていうと、全体の品質が下がっていくのは何でかっていうと、 オーバーロールクオリティが下がっていくと、 オーバーロールクオリティが下がっていくと、 オーバーロールクオリティが上がっていくと、 オーバーロールクオリティが下がっていくと、 何でかっていうと、全体の品質が下がっていくのは何でかっていうと、 テストのリソースが割けなくなるからですと。 なんだけど、新しいフィーチャーっていうのが、 プロジェクトの受入れドアにとって、 とてもクリティカルっていう可能性もありますよねっていう具体例が書かれています。 ここ本当に難しいですよね。 こうしたら、こういう場合はこうしたらいいっていう、 1対1の答えもないので、本当にその時の状況を見て、 この機能の必要性だったりとかっていうのと、 そのテストをどうきゅきゅっとまとめるのかとか、 どうこう諦めるのかっていうのは、 本当毎回難しいなというふうに思っています。 次のパラグラフ読んでいきます。 テストマネージャーは、プロジェクトのトレードオフに賛成しないかもしれないです。 特に、全体の品質を下げるプロダクト、 リリースするプロダクトの品質を下げるような決定には賛成しないかもしれないんだけど、 情報をちゃんとプロバイトしないと、提供しないといけません。 ステークホルダーに提供して、 全員が明確に理解できる。 何が起こるのかというと、 その変更によってどういう影響がありそうなのかというところが、 全員が分かるように、 情報を提供しなきゃいけませんよというふうに考えています。 次が例が書いてありますね。 ここもめちゃくちゃ大事なことを言っているなという感じなんですけど、 例えば、もし結果として変更によってテストの時間というのが、 全てのコンポーネントのテストというのが3分の1になるというのは一体どういうことなんだろうか。 その結果として品質がどういうことになるかというのを、 ちゃんと説明できるという話ですね。 なのでテストマネージャーは、 Explain the impact of the reduction in testing in terms of the increased risk なので、 どういう文脈で言うかというと、 リスクが増えるということですね。 プロダクトの品質のリスクが増えるよという、 そんな観点でどういうインパクトがあるのか。 テストを減らすというのは一体どういうインパクトがあるのかというのを、 説明できる必要があります。 さらには、Clearly explain なので、 どこの領域のテストが減るのか、あるいはできなくなるのか。 案外機能を追加することでどこのテストができなくなるのかというのも、 ちゃんと説明しなきゃいけませんよという話です。 ということで、今回はプロジェクトの管理トラッキングと、 トレードオフの取り扱いについてお話をしました。 # 今日のほっこり話💇 今日のほっこり話です。美容院の話をします。 今週末がオフ会なので、ちょっと髪の毛を切っておこうと思って美容院に行ってきたんですけど、 いつもお願いしている美容師さんがですね、個人事業主なのかな、一人でやっててなかなか予約が取れないんですよね。 ちょっと今週末行こうとか来週行こうぐらいだと、週末もいっぱいで全然予約できないので、 家の近くで初めて行くところで予約して行ったんですけれど、 いつもの調子でちょっとかやみの毛重くなってきたんで軽くしたいんですって話をしたらですね、 なんか思ってたのと違うところを好かれてしまいまして、 私的にはなんていうの、耳の上のあたりがボリューム感というか厚さ感じると重く感じるので、 そこらへんをついて軽くしてほしかったんですけど、下の方、毛先の方がかなり好かれましてですね、 だいぶ毛の量が減った気がします。 なかなか一度でこうしてほしいというのを伝えるのって難しいですね。 ということで以上、今日のほっこり話でした。 # 次回予告 今回も最後までお聞きいただきありがとうございました。 次回はですね、テスト観点を洗い出すコツ3点についてお話をしていきます。 今回の放送を聞いて、なるほどな、確かにな、学びになったなと思った方は是非、 画面右下、ハートマークでいいねを押していただけると、とっても励みになります。 是非是非、フォローもよろしくお願いします。 それではまた明日お会いしましょう。ごきげんよう。