見出し画像

渡る世間は落とし穴だらけ〜色んなリスク

良い子のみんなー!
愛と平和を歌って笑顔を届ける愉快なピエロ、MR.SMILEだよー🤡

昨日の昼くらいに外を歩いてると暑いくらいだったね?思わずアイスを買い食いしてしまったよ。
暑いのは苦手なんだけどアイスとビールが美味しく感じられる季節に入っていくね。

スーパーで買えば安い!(セコい?)


アイスもビールも摂りすぎは体にも良くないし太ってしまう「リスク」があるから要注意だね?

今回はそんな「リスク」についてのお勉強をしておこうね。

リスクってよく聞くけど

リスクは、将来に否定的な結果となる事象が起きる恐れを含む。リスクのレベルは、そのような事象が起きる可能性とその影響(事象による結果がもたらす損害)で決まる。

JSTQB FLシラバス 5.5.1 リスクの定義

JSTQBでの定義はこんな感じらしいよ。

何か嫌なことが起きてしまう可能性と起こった何かの嫌なことの度合と言うことだね。

一般には「危険度」みたいな意味で「リスクが高い」とか「リスクが大きい」と言うけど、発生した時の危険度とその起こりやすさも考慮してリスクと呼ぶ感じが合ってそうだね。

プロダクトリスクとプロジェクトリスク


テストマネージャーが考えるべきリスクは大きく分けて二つ。
プロダクトリスクとプロジェクトリスクがあるんだ。

プロダクトリスクとは、ソフトウェア(製品、システム)がユーザーやステークホルダーの要求を満たすことができない可能性。プロジェクトリスクとは、ソフトウェア開発やソフトウェアテストのプロジェクトの進行や目標達成に悪い影響を与える可能性のことを言うんだ。

プロダクトリスクの例として、
・ソフトウェアの機能が仕様通りに動作しない可能性やユーザーの要求した動作にならない可能性
・システムアーキテクチャー(システムの構造)に問題があり性能が十分に発揮されない可能性
・計算結果の正確性に問題がある可能性やループ制御に問題が発生する可能性
と言ったものが挙げられるんだ。

一方、プロジェクトリスクの例として、
・プロジェクトの遅延や予算が不足する可能性
・変更による作業のやり直しが必要となる可能性
・人員不足、スキル不足などの問題が発生する可能性
・組織内の人間関係の問題が発生する可能性
・情報伝達が不十分、または不確実となる可能性
・要件の定義不足や制約により要件が満たせなくなる可能性
・必要なテスト環境、ツール、データの遅延の可能性
と幅広いリスクが存在するよ。

渡る世間は落とし穴だらけ


プロダクトリスクもプロジェクトリスクもソフトウェアテストだけでなく開発プロジェクト全体を通して考慮すべき重要な要素だね。

プロジェクトマネージャーが開発プロジェクト全体のリスクに対処する責任があるんだけど、テストマネージャーもテストに関連するリスクには対処をするケースもあるよ。

リスクは発生した時の影響度とその可能性だったよね?
そのリスクを軽減するためにテスト計画の時点で対策を考えるし、テストモニタリングで常に気を配って問題が起きれば早めの対応が必要になるね。

落とし穴だらけの道を運任せに突き進む訳にいかないし、どこに落とし穴がありそうか?落ちた時にどうやって登ったり、別ルートへ移動できるか?を考えておくべきだよね?

例えばプロダクトリスクに対しては
製品、システムの要件を明確に定義されているか?
製品、システムに要求される性能を考慮して設計・開発をしているか?
を開発側に確認したり、
リスクベースのテストで対策すると言う考え方があるよ。

プロジェクトリスクに対しては
担当するプロジェクトの内容に応じて、どんなリスクがあるかを特定して開発やプロジェクト全体の責任者を巻き込んで予算管理や割当てる人員のスケジュール確認、テスト準備の予定確認、情報伝達のルールとかを小まめに連携しながら考えて行けるのが理想の形になるんじゃないかな?

虎穴に入らずんば虎子を得ず


落とし穴を避けてばかりだと何も前に進まなくなるから、しっかりと対策を練って進んで行くんだね。

最近、話題のアニメで機動戦士に乗ってる主人公が
「逃げたら一つ、進めば二つ」
と言ってるし、良い子のみんなもしっかりと対策を整えて前に進んでいこうね!

AIが考えた「水星の魔女」


逃げても一つは手に入るし、それで十分だから僕は颯爽と逃げる派だけどね🤡

では、今回はこの辺で!
最後まで読んでくれた良い子のみんなー!
さんきゅーすまいる🤡

いいなと思ったら応援しよう!