はじめに
前回に引き続きJSTQBの勉強をしているわけですが、何回やっても頭に入ってこない厄介な単元（？）があるんです。それが、
5.5.2 プロダクトリスクとプロジェクトリスク
です。いやこいつは本当に厄介ですよ。何が厄介かって、知識が曖昧でも何となく言葉の意味を捉えてよく考えれば問題に正解できちゃうというところです。
問題を解いているその場で考えて解いちゃってるイメージです。
正解できるならそれでいいじゃん、という感じで今まで放置してきましたが、テストでよく考えて時間を使った挙句、合っているか不安な気持ちでもやもやはするのは嫌です。そのうえ、間違えていることも平気でありますから困ったものです。
それならばQiitaに勉強も兼ねて内容をまとめておけばいいじゃん！と。
プロダクトリスクって？
JSTQBのシラバスには
「作業成果物（例えば、仕様、コンポーネント、システム、テストケース）がユーザー、および/またはステークホルダーの正当なニーズを満たすことができない恐れを含む。」
と表現しています。
・・・。
まぁ、わかるっちゃわかるんですがちょっとだけわかりにくいので簡単に説明すると、
何かしら製品を作るうえで世に出す前に、その製品のテストを実施して品質を保証するのはとても大切なことです。しかし、人間なのでテスト漏れがすることもあります。で、その時に発生し得る損失や損害に対するリスクというイメージです。
これは「プロダクトリスク」という言葉の意味を考えれば大抵の人はイメージできるかと思います。特に重要な試験に出るプロダクトリスクの項目をまとめておきます。
・故障の起きやすいソフトウェアの出荷
・ソフトウェアやハードウェアが個人や会社に対して損害を与える可能性
・貧弱なソフトウェア品質特性
・貧弱なデータの完全性と品質
・予定の機能が動作しないソフトウェア
以上を基にしたシラバスに挙げられている例がこちら。
・ソフトウェアの意図されている機能が仕様通りには動かないかもしれない
・ソフトウェアの意図されている機能がユーザー、顧客、および/またはステークホルダーのニーズ通りには動かないかもしれない
・システムアーキテクチャーが非機能要件を十分にサポートしないことがある
・特定の計算結果が状況によって正しくないことがある
・ループ制御構造が正しくコーディングされていないことがある
・高性能トランザクション処理システムで応答時間が適切でないことがある
・ユーザーエクスペリエンス（UX）のフィードバックがプロダクトの期待と異なるかもしれない
プロジェクトリスクって？
シラバスでは
「発生した場合にプロジェクトの目的達成に悪影響を与える。」
と表現しています。
こちらはわかりやすいですね。プロジェクトリスクを正しく捉えるうえで重要になってくるのが
・ヒト
・モノ
・カネ
の3項目です。この3項目でどういったリスクがあるかを考えると非常にわかりやすいと思います。
こちらもシラバスに載っている例を基に理解を深めたいと思います。
スケジュールに関するリスク
・テストにより大量の問題が検出され、テストの進捗が滞る
・機能追加や仕様変更により、テストケースの作成/実行が追い付かなくなり、スケジュール内で収まらなくなる
テスト環境に関するリスク
・シミュレーターや測定器などの機材の調達が滞り、テスト環境が構築できない
・テスト環境で前バージョンの開発が終わっていない
・データ変換ツールの開発の遅れにより、予定通りにテスト環境用のデータが揃わない
・開発環境からステージング環境へ移行するためのツールに問題があり、受け入れテストの環境が構築できない
テストマネジメントに関するリスク
・テストの計画/設計/実行に要するコストと必要なテスト人員（スキル面、人数）が確保できない
・テスト計画、設計フェーズへ十分に人をアサインできない
・一度作った後に、誰も見ないテスト計画を作ってしまう
・無計画、かつ成り行き任せでテストリソース（ヒト、モノ、カネ）を割り当ててしまい、その結果予算がショート（不足）してしまう
おわりに
以上になります。プロジェクトリスクの例は多いので、プロダクトリスクを覚えちゃって、それらに類似しないものはプロジェクトリスク、と覚えるのが良いかもしれません。
これでJSTQBの試験問題を解いていてこの問題が出てきても自信をもって答えることができると思います。
JSTQBが気になった方は勉強記録①もまとめておりますので是非そちらもご覧になってください。
それでは～。