JSTQB FL の取得に向けて学習中のみなさん。初めまして、Yoです。
シラバスの読み込みは順調ですか？各項目をしっかり理解できていますか？
JSTQBの学習において、シラバスの熟読は避けて通れません。しかしながら、シラバスは言い回しが少々難解であったり、耳慣れない用語が多かったりとなかなかとっつきにくいものです。私もFL学習の初期には全然理解が追い付かずに苦労しました。
本記事では、シラバスを理解する上で私が個人的につまづいた箇所をかみ砕いて解説していこうと思います。
今回はプロダクトリスクとプロジェクトリスクについて解説します。
シラバスにおいて
プロダクトリスクとプロジェクトリスクについて、JSTQB FLシラバスでは以下のように解説されています。
※少々長いので、箇条書きにされている具体例は割愛します。
プロダクトリスクについて
プロダクトリスクは、作業成果物（例えば、仕様、コンポーネント、システム、テストケース）がユーザー、および/またはステークホルダーの正当なニーズを満たすことができない恐れを含む。プロダクトの特定の品質特性（例えば、機能適合性、信頼性、性能効率性、使用性、セキュリティ、互換性、保守性、移植性）に関連するプロダクトリスクは、品質リスクとも呼ばれる。
ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
プロジェクトリスクについて
プロジェクトリスクは、発生した場合にプロジェクトの目的達成に悪影響を与える
ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
英語の意味を考える
シラバスの引用だけではまだ表現が固くて取っつきにくいので、英語の意味を考えていきましょう。
プロダクトは「製品」、プロジェクトは「事業、計画」といった意味の言葉です。つまり、プロダクトリスクは「製品に対するリスク」プロジェクトリスクは「計画に対するリスク」と言い換えることができます。
※プロジェクトの和訳として、ここでは計画の方を採用しました。
もっと簡単に表現してみる
英語で意味を噛み砕いてみると、それぞれのリスクがどういったものか、多少はイメージしやすくなったのではと思います。更に、それぞれのリスクを「製品」「計画」というキーワードに着目して言い換えてみましょう。
- プロダクトリスク = 製品の利用者に害があるリスク、製品の提供者に不都合があるリスク
- プロジェクトリスク = 計画通りに進まないリスク、計画そのものが抱えるリスク
こうして両リスクを言い換えてみると、冒頭で引用したシラバスの記述が理解できるかと思います。
シラバスの例を具体的に考えてみる
言葉の意味の解説が済んだところで、ここでは両リスクが具体的にどういう物かを考えてみます。
先ほどのシラバス引用では割愛しましたが、シラバスには具体例が箇条書きで記載されているので、それらを見てみましょう。
プロダクトリスクの例
プロダクトリスクの例について、シラバスに以下のような記載があります。
特定の計算結果が状況によって正しくないことがある。
ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
これがプロダクトリスクである、と答えありきで言われると、確かにそうかもなと思うかもしれませんが。ヒントなしで何のリスクであるかと答えるためには、両リスクがどの様なものであるかをしっかり理解していることと、例からどの様な事象に発展してしまうのかを想像することが大切です。
この例では、計算の結果が正しくないということですので、以下のような事象に発展する可能性があります。
- ショップの購入者への請求額の誤り
- 在庫数の表示と実態の不整合
これらのようなことが実際に起こってしまうと、利用者は金銭的な損害を被りますし、サービス提供者は機会の損失が発生する可能性があります。これらは「製品」の機能不備によって引き起こされたものであるため、プロダクトリスクになります。
プロジェクトリスクの例
プロジェクトリスクの例としては、以下のような記載があります。
テスト環境が予定した期限までに用意できないことがある。
ISTQBテスト技術者資格制度Foundation Level シラバス 日本語版 Version 2018V3.1.J03
経験がある方もいらっしゃるのではないでしょうか。予定通りに環境が出来上がらない場合、どういった事態が考えられるでしょうか。すぐ思いつくのは、
- テストが遅延する
などでしょう。更に言うと、リリース判定、申請、リリース等が後ろにずれてゆき、当初計画していたスケジュール通りに開発が完了しないということが起こりえます。そうなると当然。
- 開発コストの高騰
等も発生しえます。これらは「計画」に影響を与えるリスクであるため、プロジェクトリスクだと判断できます。
上記の例のように、「どこで」「どの様に」悪影響があるのかを具体的に考えることで両リスクの判断が可能になります。
例題
ここまでで両リスクの説明と、具体例からの判別について一通りの解説ができたので、応用として簡単な例題を解いてみましょう。
| 以下のうち、プロダクトリスクはどれか A：ループ制御構造が正しくコーディングされていない B：人員のスキルやトレーニング不足 C：ツールによる支援が遅れる D：欠陥や他の技術的負債が累積する |
それぞれに対し、リスクが何に影響を与えるかと、どの様な問題が発生するかを想像して回答してください。
回答はAです。合っていたでしょうか。
解説になります。プロダクトリスクはどれか、という問いですので選択肢のうち「製品」が直に利用者か提供者に不都合をもたらすリスクであれば正解となります。Aはアプリなどで考えると離脱不可やフリーズなどを引き起こしかねないため「製品」のリスクとなります。故にプロダクトリスクとなります。
他3つのリスクに関して、個別の解説は省きますが、ザックリと言ってしまえば「うまく製造できない」という結果に繋がります。これは「計画」に対するリスクとなるためプロジェクトリスクです。
いかがでしたでしょうか。両リスクはシラバスで取り上げられる例も多いので一つ一つ覚えると大変ですが、内容を理解した上で想像することで問題の難易度がぐっと下げることが可能です。
リスクにどう対処するか
JSTQB FL対策というテーマからは若干逸れますが、それぞれのリスクに対して、業務でどのようなアプローチをとると良いのか、リスクを判断できるとどういうメリットがあるのかという話をしたいと思います。
プロダクトリスクに対処する
プロダクトリスクに対処するものとして、リスクベースドテストというものがあります。リスクベースドテスト自体もFLで軽く触れられているものになりますが、可能性や影響から優先度を決定していくアプローチになります。ただ、当然ながらリスクベースドテストでなくとも、テストの対象となる機能にはどういったプロダクトリスクがあるかを常に意識することは重要です。
可能性や影響を適切に判断することによって、テスト優先度やテストの詳細度合い等を決定することができるというメリットがあります。例としては、要件レビューに参加し、リスクの観点からレビューを行う、非機能テストの戦略をリスクに基づいて決定するなどです。
プロジェクトリスクに対処する
プロジェクトリスクへの対処は、JSTQBでは主にTMで解説される内容のため簡潔に、かつ個人の見解も含むものになりますが、自身が担当する範囲で、何かしら作業が滞る要因は全てプロジェクトリスクです。
阻害となっている要因（たとえばテスト環境構築の遅れなど）を適切に判断することができれば、テスト実行スケジュールの再検討などができるようになり、影響を最小限に抑えることができます。
環境構築はあくまで一例ですが、プロジェクトリスクを判断できるということは、プロジェクトやチームが抱える問題を発見できるということでもあるため、テストコントロールの観点においてもプロジェクトリスクを適切に判断できることは重要となります。
このように、対処のアプローチ、対処することのメリットも異なるため、それぞれの対処法だけでなく、それぞれを正しく「判別」出来ることが重要になります。
まとめ
以上でJSTQB FL対策の第1回、プロダクトリスクとプロジェクトリスクの解説は終了します。あくまで私が受験時に苦戦した内容をまとめているものになるため、「そんなことは知っている」という方もいるでしょうが、私と同じ個所で苦戦している方がいらっしゃいましたら、この記事で理解のお手伝いが出来れば幸いです。
本記事はFL対策と銘打っていますが、テストに向けてというだけでなく、JSTQBの用語理解にも役立てていただければと考えています。JSTQBの用語を基準とすることで認識の共通化を図ることでステークホルダとのコミュニケーションにおいてエラーも発生しにくくなると思いますので、プロジェクト内のポジションに関わらず、用語を深く理解することは重要と考えます。
では、また別の記事でお会いしましょう。
