『スクラムとは？』の説明②（「リスク」と「不確実性」の観点から）

どもども。ひぐちぇです(゜д゜)ﾉ

土日のお休み中、妻や娘の相手しながら、その合間合間にスマフォで「『スクラムとは？』の説明」について調べてて、前とは別観点で考えがまとまったので、それを書いときますｗ
（※正確には『アジャイルとは？』です。）

以前、『スクラムとは？』の説明として、↓をあげました。
junhiguchi.hatenablog.jp
これは、計画と生産性の観点からでした。

今回は、「リスク」と「不確実性」の観点からです。

スクラム（アジャイル）とは「不確実性」に対するアプローチ

「リスク」と「不確実性」の違いについては、以前も少し話題にあがりましたが、こんな感じです。

リスク　…確率的に出現を予想できる人や組織などにとって望ましくない事象
不確実性…確率的に出現を予想することができない事象

ソース：リスクと不確実性
https://www.works-i.com/research/paper/works-review/item/100601_WR05_01.pdf

そうなると、ソフトウェア開発においてのリスク、不確実性を考えると、それぞれは例えばこんな事象がはいるのではないでしょうか

リスク	・正しく動かないかもしれない ・お客様担当者との認識のズレがあるかもしれない など…
不確実性	・市場の動向が変わるかもしれない ・お客様側の会社の経営陣や担当者が変わるかもしれない など…

そう。。

スクラム（アジャイル）は、こういった「不確実性」に対するアプローチなのです！ m9( ﾟДﾟ) ﾄﾞｰﾝ！！
→「不確実性」の中でも成果を出すための手法という言い方もできるかと思います。
→あ、「リスク」＋「不確実性」に対するアプローチですよ。「リスク」も含んでます。

アジャイルではないソフトウェア開発方法論では、リスクに対するアプローチまでではないでしょうか？
不確実性に対しては極めて弱いと思っています。
アジャイルでは、「リスク」に対するアプローチだけでなく、「不確実性」に対するアプローチを含んでいるのです。

アジャイルではないソフトウェア開発方法論が「不確実性」に弱い理由

それは、以下４つが「プロジェクト計画」として固定になっているためです。
事業計画書として会社に提出してしまっているので、それを守らなければならなくなります。

• コスト
• 期間
• スコープ
• 品質

「コスト」が固定になっているため、開発メンバーを追加する事ができない。
「期間」が固定になっているため、開発する機能を途中で増やす事ができない。
「スコープ」が固定になっているため、開発する機能を変更する事ができない。
「品質」はそもそも変えるわけにはいかないものでしょう。
※ここで言っている「品質」というのは、機能品質（バグが出ない、正しい動きをすることの担保）の事です。

余談ですが、
「コスト」＋「期間」＋「スコープ」＝「品質」　と言われるそうです。
support.office.com

「コスト」「期間」「スコープ」のいずれかを柔軟にコントロールできるのであれば、「不確実性」に対応する何かが出来たうえで、「品質」を担保できるのでしょう。

実際、アジャイル開発プロジェクトでは、「スコープ」を柔軟にしている事が多いです。

現実的には、アジャイル開発におけるプロジェクト計画では、「コスト」と「期間」は変えることができないもの（固定）とし、「スコープ」を柔軟に変えれるようにしているものが多いと思います。

ご存知のようにスクラムでは、スプリントの初めに計画を立てるのですが、その際に実施するプロダクトバックログアイテムの調整をPO（プロダクトオーナー）と共に柔軟に内容を増やしたり、変更したり、削除したり、優先順位を入れ替えたりしてから、計画を練るのです。
こういった行動が「不確実性」に対する対応といえるのです。

スクラムの流れを見直したい場合はこちら
www.ogis-ri.co.jp