Unknown Unknowns
「知らないことを知らない」をどう扱うか、という問いはソフトウェア開発に固有のものではない。プロジェクト管理、組織論、防衛、医療、いずれの分野でも長く論じられてきた。世間に広まったのは2002年2月12日のDonald Rumsfeld発言 (DoD news briefing) だが、起源はもっと古い。1968年のAerospace Industries Association報告書ですでにNorth American RockwellのHudson Drakeが "unanticipated unknowns" と呼び、Lt. Gen. William B. Bunkerが "known unknowns / unknown unknowns" と発言している。Rumsfeld自身もmemoirで、NASA管理者William Grahamからこの言い回しを聞いたと認めている (Wikipedia)。 Rumsfeldの2×2は入口として便利だが、分析の道具としては素朴すぎる。なお、PMI の PMBOK はこの分類をそのまま予算管理に持ち込んでおり、known unknowns に充てる Contingency Reserve はプロジェクトマネージャ裁量、unknown unknowns に充てる Management Reserve は上位経営層の裁量でコストベースライン外に置く、と階層を分けている。Rumsfeld型の分類が実務にどう落ちているかの分かりやすい例である。 不確実性そのものを分類する古典的な枠もある。工学・統計の伝統では、不確実性を epistemic (知識不足によるもの、削減可能) と aleatory (本質的なランダム性、削減不能) に分けて扱う。両者を混同すると tail risk を過小評価することが Taleb 2020 / Statistical Consequences of Fat Tails で指摘されている。「unknown を known に引き上げる」手法はすべて epistemic の側を削る活動で、aleatory の側は手法では削れない。 認知フレームワーク
Five Orders of Ignorance
Armourの出発点は「ソフトウェアは製品ではなく、知識を蓄積するための媒体である」という主張である。そのうえで、無知 (ignorance) を5つの階層に分類する。
0OI (Lack of Ignorance): 知っていて、それを動くシステムなどの形で示せる状態。答えを持っている
1OI (Lack of Knowledge): 知らないが、何を知らないかは特定できる状態。質問を持っている
2OI (Lack of Awareness): 知らないこと自体を知らない状態。質問すら持てない
3OI (Lack of Process): どうやって2OIを発見すればよいか、その方法も知らない状態
4OI (Meta Ignorance): Five Orders of Ignoranceというモデル自体を知らない状態
Armourは2OIと3OIが本当の問題だとする。2OIは見積もりの大幅な乖離や「90%完了症候群」、Fred Brooksのいう "second system effect" を説明する。3OIに対するArmourの観察はこうである。「ソフトウェア開発方法論はすべて3OIプロセスである。その仕事は答えを与えることではなく、私の2OIを照らし出して質問に変えることだ」。方法論に答えを期待するのは間違いで、方法論は質問を返してくる装置だ、という指摘になる。後述する設計系の手法はここに直接つながっている。
適用対象はソフトウェア開発の知識管理。学習系・設計系の手法と相性が良い。
Cynefin
Clear: 因果が明白で誰でも見える。sense-categorize-respond
Complicated: 因果はあるが専門家でないと見えない。sense-analyze-respond
Complex: 因果が事後にしか見えない。probe-sense-respond
Chaotic: 因果が見えず時間もない。act-sense-respond
Disorder: どの領域か判別がついていない状態
他のフレームと違うのは、認識主体の知識状態ではなく世界の側の性質で分類する点である。Five Ordersが「私はどれだけ知っているか」を軸に取るのに対し、Cynefinは「この問題はそもそも事前に分析しきれる類のものか」を問う。Complex / Chaoticは、十分な努力や有能な専門家がいれば事前分析できる、という前提自体を否定する領域として宣言される。Unknown unknownsが支配的な領域があると正面から認めるフレームと言ってよい。
Five Ordersと補完関係にある。Five Ordersは知識獲得の階層、Cynefinは問題そのものの性質。適用対象は組織・社会の意思決定で、後述する実験系の手法と直接的に相性が良い。
Ousterhoutの複雑性の3形態
John Ousterhout A Philosophy of Software Design (公式ページ, 2018, 2nd ed. 2021) は、ソフトウェアの複雑性が現れる形態を3つに分類する。 change amplification: 小さな変更が多くの場所の変更を要する
cognitive load: タスク完了のために知る必要があることが多い
unknown unknowns: 何をすべきか、提案した解が機能するかさえ分からない
Ousterhoutは "Of the three manifestations of complexity, unknown unknowns are the worst" と明言する。他の2つは観測可能だが、unknown unknownsは事象が起きるまで存在を知れないから。
unknown unknownsの根本原因を obscurity (重要情報が明示されない) と dependencies (コンポーネント間の絡み合い) の2つに帰着させる。情報が隠れているほど、依存が散らばっているほど、unknown unknownsは増える。
Johari Window / Luft & Ingham 1955
心理学者Joseph LuftとHarrington Ingham が1955年にUCLA Western Training Labで発表したモデル (原論文PDF)。「自分が知っているか × 他者が知っているか」の2軸で4象限を構成する。 Open: 自分も他者も知っている
Blind: 他者は知っているが自分は知らない
Hidden: 自分は知っているが他者は知らない
Unknown: 自分も他者も知らない
Rumsfeld 2x2と形は似ているが、認知主体の非対称を扱える点が違う。「開発者には見えていたが運用者には見えていなかった」「Aチームの常識がBチームには共有されていなかった」といったチーム内のギャップを記述するのに適している。インシデント分析やコードレビュー、設計レビューで暗黙知を表に出す活動の根拠になる。
Known Unknowns 化の手法
言語化系
想像可能だが言語化されていないリスクを、人間の対話と思考実験で表に出す手法。認知主体は人間で、対象は人間が考えうる範囲のリスク。Johari WindowのHidden領域とBlind領域をOpenに移す活動と読める。
Pre-mortem: Gary Klein 2007 / Performing a Project Premortem, HBR。プロジェクト開始時に「1年後に大失敗した」と仮定して原因を逆算させる思考実験。Klein はDeborah Mitchell, Jay Russo, Nancy Pennington 1989 Back to the Future: Temporal Perspective in the Explanation of Events を引いて、prospective hindsightが原因特定の精度を約30%向上させると述べている。post-mortemと違い、まだ起きていない失敗について話せるので参加者の心理的抵抗が低い。失敗のメカニズムを説明させる構造はIOEDを発火させて2OIを露出させる作用も併せ持つ 悪魔の代弁人 / Red Teaming: 米陸軍 Red Team Handbook (University of Foreign Military and Cultural Studies)、イスラエル国防軍 Aman の Ipcha Mistabra (Tenth Man Rule)。後者は1973年のYom Kippur戦争での情報失敗を契機に、合意が形成されたときに10人目は必ず反論する役を担う制度として知られる。組織がgroupthinkに陥らないための仕掛け Five Whys + 石川ダイヤグラム (Fishbone): Five WhysはToyota Production Systemで大野耐一が用いたとされ、Fishboneは石川馨が1968年の特性要因図として体系化。Fishboneでカテゴリを広げてからFive Whysで深掘りするのが定石。Whyを5回問う構造はIOEDの実践応用と読める。因果連鎖を言語化させると、自分が分かっていなかった層が露出する。エビデンスベースで進める縛りがないと「思いつき」で終わる点に注意
Assumption Mapping: David Bland & Alex Osterwalder 2019 Testing Business Ideas。前提を「重要度 × 不確実性」の2軸で並べ、リスクの高い前提から優先的に実験で検証する。前提を明示する作業そのものがHidden領域をOpenに動かす
Robust Decision Making (RDM): Robert Lempert ら RAND Corporation が開発した Robust Decision Making。Scenario Planning の発展形で、無数の将来シナリオを探索的にシミュレートし、どのシナリオでもそれなりに機能する戦略を選ぶ。deep uncertainty (関係者がモデルや確率に合意できない状況) への正面からの応答 Horizon Scanning / Weak Signals: 曖昧で取るに足らないように見える兆候を意図的に拾い、戦略的サプライズを早期に検知する。Strategic Early Warning Systemとして1970年代以降に発展。Weak Signals (徐々に育つ変化の種) と Wild Cards (低確率高インパクトの不連続) を区別して扱う
Crawford Slip Method: C.C. Crawford 1925年頃にUSC で開発。匿名の付箋に各人がリスクや問題を書き出してから集約する手法。Brainstormingが声の大きい人に支配される問題を回避し、Hidden領域を強制的に Open に移す古い装置
分析系
設計や運用の構造から、想定されるべき障害モードを体系的に列挙していく手法。手続きが規定されていて、漏れを潰すための網のような役割をする。言語化系が自由連想なのに対し、こちらは構造化された手順で網羅性を担保する。
FMEA (Failure Mode and Effects Analysis): 1949年米軍 MIL-P-1629 起源、後にNASA・自動車・医療などで標準化。コンポーネントごとに「どんな故障モードがあり、何が起きるか、影響度・発生頻度・検知性はどれか」を表で書き出す。リスト化のテンプレートそのものがknown化の装置
HAZOP (Hazard and Operability Study): ICI (Imperial Chemical Industries) が1960年代に開発。プロセスの各ノードに対して "no", "more", "less", "as well as", "reverse" などの Guide Words を当てて偏差を網羅的に列挙する。化学プラントで標準的な安全分析手法
STPA (Systems-Theoretic Process Analysis): Nancy Leveson / Engineering a Safer World, MIT Press 2011 で提示。STAMP (Systems-Theoretic Accident Model and Processes) に基づき、コンポーネント故障ではなくコントロールの不在や相互作用に着目してハザードを抽出する。Levesonは "unknown unknowns that were previously only found in operations can be identified early in the development process" と明示的にunknown unknownsへの効果を主張している Bow-tie Analysis: 因果（脅威→事象）と帰結（事象→影響）を対称的に書き出し、予防コントロールと緩和コントロールを左右に並べる。航空・石油・金融業界で使われる
実験系
想像できないが実装や現実に存在する依存関係や挙動を、現実に発火させて検出する手法。認知主体は機械やランダム性で、人間が思いつかない入力・障害・タイミングを試す。CynefinのComplex領域における probe の具体化と読める。
設計系
設計系は他の系譜と性質が違う。設計という行為そのものが、未だ言語化されていない知識を露出させる発見手続きになる、という点である。「unknown unknownsを減らす設計」と「設計の過程でunknown unknownsを発見する」の二重構造を持つ。
設計の結果として unknown unknowns を減らす
Deep modules: Parnasの直系。インタフェースを浅く・実装を深くすることで、知るべき総量を最小化する (Ousterhout A Philosophy of Software Design)
Obscurityの削減: 命名・コメント・設計ドキュメントによる重要情報の明示化。Living Documentationはこの方向の延長
Information leakageの防止: 1つの設計判断が複数モジュールに散らばらないこと。leakage が起きていると変更が予期せぬ場所で壊れるが、これがunknown unknownsの典型的な発生源になる
設計の過程で unknown unknowns を発見する
ここがArmourの観察「方法論は答えではなく質問を返してくる装置だ」と直接つながる節である。モデリングは「すでに分かっていることを書き留める」活動ではなく、「分かっていなかったことを露出させる」活動だと見るべきである。
Event Storming: Alberto Brandolini / Introducing EventStorming。ドメインイベントをタイムラインに付箋で並べていく集団作業。並べる過程で誰も知らなかったポリシーやコマンドが見つかり、参加者が議論を始める「ホットスポット」が浮き上がる。Brandolini自身が "the ability to uncover hidden problems in a very short time" を主目的に挙げている。Johari Windowでいう、各参加者のHidden領域がぶつかってOpenに動く現象を、付箋という装置で意図的に起こしている イミュータブルデータモデル: データを更新可能な現在状態としてではなく不変な台帳として設計する立場。「いつ確定するのか」「どこで状態が変わるのか」を強制的に明示せざるを得なくなり、可変モデルでは曖昧に放置されていた業務上の決定点が顕在化する。注文を申込・確定・出荷指示・出荷の4イベントの累積として表現するというように書き換えていくと、業務担当者が「あれ、出荷指示と出荷のあいだに在庫引当がある」と気づく これらに共通する原理は、強い制約のあるモデル言語で書こうとすると、暗黙の前提が破綻して質問が返ってくる、という構造である。書き手の意図を超えて、モデルそのものが「ここはどうなっているのか」を問うてくる。Five Ordersでいえば 2OI を 1OI に引き上げる、設計時の手続きとして読める。Armourが「方法論は質問を返してくる」と書いたのと同じ事象を、モデリング言語の側で起こしている。
学習系
事故・経験を unknown から known に繰り上げる手法。事後の知識化で、Five Ordersの3OI→2OI→1OI への昇格手段にあたる。
限界
ここまで列挙した手法は、unknown unknownsを完全には消せない。冒頭で触れたepistemicな部分は削れるが、aleatoryな部分は残る。Nassim Taleb / The Black Swan, 2007 と Antifragile, 2012 はこの残余を扱う立場で、予測不可能な高インパクト事象は手法では削れないという前提に立つ。Talebの提案は予測の精度を上げることではなく、予測できない衝撃を受けても壊れにくい構造、可能なら衝撃で強くなる構造 (antifragility) を持つことだ。 実務で antifragility の方向に倒した古典的な手段が冗長化と多重化である。航空機の三重系制御、データセンタの可用性ゾーン、Erlang/OTPの supervisor tree。これらは原因を特定せずに「壊れたら別系統で受ける」という応答を構造として埋め込む。原因はunknownのままでよい、という割り切りで設計する点が、ここまでの手法と性格が違う。
unknown の大半は手法で削れる。しかし手法を選ぶには、自分がどの種類の無知に向き合っているかを見分ける枠組みが要る。知識獲得の階層 (Five Orders) なのか、世界の側の性質 (Cynefin) なのか、設計の不透明さ (Ousterhout) なのか、認知主体の非対称 (Johari) なのか。残余はTalebの方向に委ねるしかない。