システム開発の不確実性を攻略する

# 0.動機
システム開発の現場、オペレーション業務、日常生活において、思わぬ失敗／成功、ストレスの裏に不確実性(Uncertainty)が隠れています。不確実性とは確率以上の意味を含んでいます。不確実性は雲をつかむような難しい概念ですがなんとか理解に努め、不安の種に立ち向かいたいと思いメモをまとめてみます。

# 1.定義
不確実性は非常に重要な概念にも関わらず定義されることが少ないです。
日本語的な意味でも、英語的な意味でも日常感覚では「確かでないこと」となるでしょうか。では逆に「確かである」とはいったい何かと考えるとよくわからなくなります。

辞書的な説明[1]を引用します。
The uncertainty about a piece of knowledge in a knowledge base can  be represented in a variety of ways.
「知識のコレクションにおけるある部分の知識についての不確実性は様々な方法で表現される」
	⇒確かに不確実性は各分野において分散、確率、言葉(自然言語)で表されています。
例
(測定の)不確かさ:ある測定結果に関連し、その測定量に合理的に割り付けられる値の分散を特徴づけるパラメータ[2] ⇒ざっくり要約すると統計の分散のようなものを不確かさ(Uncertainty)と呼ぶ
経済学者ナイトの不確実性:ランダム性と不確実性を区別し、不確実性とは起こりうる事象についての定量化可能な知識の欠如と呼んだ[3]。　

あとは日常生活においては、例えば中古本をamazonで買うという状況で下記のような場合はないでしょうか。
・その本の状態が分からない  ※新品同様なのか、ボロボロなのか、
・送られてきた本は第何版なのか　※第一版は中古本として価値が高いそうですが・・・
などなど。これらも不確実性に属する項目です。不確実性は単に知らないことや、複数のパターンのうちどれかがわからないということもあります。

# 2. リスク
いくつかの国際規格ではリスクは不確実性の結果として下記のように定義されています。

定義：目的に対する不確かさの影響[4][5]
　この定義のリスクにはポジティブな影響もネガティブな影響も含んでいます。
　例
　開発プロジェクトを進めているときに、一緒に働くメンバーの力量がよくわからないケースがあります。    
　実はメンバーは優秀で良い結果になるかもしれないし、メンバーが期待するほど優秀ではなく悪い結果になるかもしれません。
　定量的・定性的に力量を測定・判定する科学的な方法をとっていればいくらか不確実性を減らせるかもしれません。

その他、リスクの定義として下記のものがあります。
・特定の脅威が特定の結果を意図して特定の脆弱性を利用する確率として表される損失の予測[6]
・ある危険の起こりやすさとその危険の重大性についての確率の組み合わせ[7]

# 3.ブラックスワン
ナシーム・ニコラス・タレブは著書の中で
西洋人がある時点まで、観察により「すべての白鳥は白い」と信じていたが、オーストラリアで黒い白鳥(ブラックスワン)を発見し驚愕したという歴史的事象から
ある時点までの観察により構築された知識体系では説明できない新たな現象のことをブラックスワンと呼びました。

タレブによればブラックスワンには3つの特徴があるそうです。
・過去の観察からすると異常であること。
	⇒統計的に外れ値として片づけられる。確率では表せられない、またはまったく未知の事象
・大きな衝撃があること。
・人間の性質により、起こってから適当な説明をでっちあげて筋道をつけたり、予測が可能だったことにしてしまったりすること。
	⇒あとから振り返れば歴史は必然であったかのように錯覚するが、現実で現在私たちが経験しているように将来起きることの多くは予測不可能

ブラックスワンは確率論に基づく理論に警鐘を鳴らしています。
福島原発事故についても津波の到達高さのシミュレーションをあまりに信じすぎ、あるいは大昔の津波の記録を無視し、準備を怠ったことから起きてしまいました。

# 4.自動運転と未知の未知
不確実性に立ち向かわなければならないおそらく究極の開発プロジェクトは自動運転車の開発です。自動運転車の安全性に関する規格にSOTIF[8]があります。自動運転車が安全であることを証明する枠組みです。
![画像1.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/556151/ada52e9e-11a9-d370-a145-6deaaf9ea44f.png)
そこではシナリオベースの検証方法が書かれています。
シナリオを下記の4つに分類します。
既知の安全シナリオ：設計時に想定しているシナリオでリスクが許容可能なレベルの状況
既知の非安全シナリオ：設計時に想定しているシナリオでリスクが許容できないレベルの状況
未知の安全シナリオ：設計時に想定していないシナリオでリスクが許容可能なレベルの状況
未知の非安全シナリオ：設計時に想定していないシナリオでリスクが許容できないレベルの状況

このうち未知の非安全シナリオは不確実性に満ち溢れた状況です。あらゆる考えうるシナリオで自動運転車を実験し、未知の非安全シナリオを最小化することを目指します。

別の視点で軍事戦略、プロジェクト管理で同様の枠組みがあります[9]。
![画像2.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/556151/d92c5062-c9c4-ec8f-d503-a19bab5279f1.png)
起きうるすべての事象、シナリオを以下の4つに分類します。
既知の既知・・・理解しているし、意識している。
既知の未知・・・意識しているが、理解していない。
未知の既知・・・理解しているが、意識していない。
未知の未知・・・意識していないし、理解もしていない。

# 5.攻略法
4項で示した事象・シナリオの4つの分類から攻略法が見えてきます。
・現実をより正しく認識する。何が確かで、何が不確かなのか理解する。ランダム性とその限界を理解する。
・知らないことを理解するように努める、実際に経験する。
・危険な事象を常に意識し対処できるか自分に問いかける。
・知らないことに気づくために興味の外の様々なことを学ぶ、経験する。

以上、不確実性について雲を掴む思いでメモをまとめてみました。
詳しい方で良い文献、良い本を知っていればぜひ教えてください。

# 6.参考文献
[1]Oxford dictionary of computer science
[2]Uncertainty of measurement Part3:Guide to the expression of uncertainty in measurement(GUM:1995)
[3]https://en.wikipedia.org/wiki/Knightian_uncertainty
[4]ISO31000(JISQ31000)
[5]ISO/IEC27000(JISQ27000)
[6]IEC/TS62443-1-1
[7]ISO26262-1
[8]ISO/PAS21448
[9]https://en.wikipedia.org/wiki/There_are_known_knowns

# 7.関連記事(技術者のための哲学)

https://qiita.com/Okome-man/items/02f9837eadaa72f4e852

https://qiita.com/Okome-man/items/7ebbc18a8838b5503b44

https://qiita.com/Okome-man/items/0a934cc36faf7f0048e5

https://qiita.com/Okome-man/items/d11b46357be83f51ad65