予測可能性には二つの源がある — コードから読めることと、既に知っていること
「実行前に結果が読める」(実行前に結果が読めることがIaCの根本価値である)と言うとき、その「読める」の中身は一つではない。二つ混ざっている。
- 静的予測可能性 — 目の前のコードを読めば、graph形状と属性値が決まる
- 習熟による予測可能性 — そのmoduleを何度も使ったので、中を読まなくても何が出てくるか分かっている
同じ「予測できる」という状態でも、どこに根拠が置かれているかが違う。1はコードという成果物の性質で、2は読み手の頭の中にある。
二つが同じに見える場面
実務では両者が混ざる。よく使うmoduleを呼ぶとき、人は中を読んでいない。それでも「これを呼べばVPCとサブネットとNATが出る」と予測できて、planを見れば想定どおりだと確認できる。この状態は静的予測可能性が高いのと体感上は区別がつかない。
抽象化境界の透明性は記述自由度とは独立した軸であるは「呼び出し側がどれだけ中身を読みに行く必要があるか」を独立した軸として立て、それをドキュメント文化・テスト文化が補うとした。習熟はその補いの実態の一つである。ただし補い方が違う — ドキュメントは成果物に残るが、習熟は個人の中にしか残らない。
経済的性質がまるで違う
| 静的予測可能性 | 習熟による予測可能性 | |
|---|---|---|
| どこに宿るか | コード(成果物) | 読み手(個人) |
| 新規参加者 | すぐ効く | 効かない。積み直しが要る |
| 転用 | リポジトリを移っても効く | そのmodule群を離れると消える |
| 陳腐化 | コードを直せば追随する | moduleが変わっても頭は古いまま |
| 検証 | 静的解析・型検査が代行できる | 代行できない |
| 獲得コスト | 書くときに一度払う | 使うたびに少しずつ、人数分払う |
最後の行が効く。習熟は人数に比例して払い直される。10人のチームなら10回、入れ替わればまた払う。静的予測可能性はコードに一度書けば全員が使える。組織が大きくなるほど、また人の出入りが多いほど、2に頼る設計は割高になる。
危険なのは陳腐化のほう
もっと悪いのは、習熟が間違ったまま自信を保てることである。静的予測可能性は、コードが変われば読んだ結果も変わるので、勘違いはコードを読み直せば直る。習熟は違う。moduleの中身が変わっても、「知っている」という感覚は自動では更新されない。読まないことを正当化した状態のまま、前提だけが古くなる。
しかも習熟が高いほどplanを注意深く見なくなる。「いつもどおりのはず」で差分を流し読みする。予測可能性が高い状態が、逆に検証を省く理由になる。これが黙って捨てるのは、落とすことより悪いと同じ構図 — 気付けないことが被害を大きくする — に落ちる経路である。
設計判断としての含意
この区別は、抽象化を評価するときの見え方を変える。「このmoduleは分かりやすい」という評価が、コードの性質を指しているのか、評価者が慣れているだけなのかで、下すべき判断が違う。後者なら、その分かりやすさはチームの外へ持ち出せない。
IaCでは賢い抽象より退屈で逐語的な記述の方が価値が高いが退屈な逐語的記述を推すのは、1に寄せる主張として読める。抽象を厚くすると1が下がり、その埋め合わせを2に頼ることになる。埋め合わせは効くが、上の表の性質を引き受けることになる。
AIの側から見ると差はもっとはっきりする。AIのコンテキスト窓は人の局所読解と同質の制約であるで書いたとおり、AIはコンテキストに入っていないものを知らない。AIには2が無い — 正確には、学習データに含まれる著名なmoduleについては疑似的に2を持つが、その組織固有のmoduleについては持たないし、持ったつもりで誤ることがある。人間の習熟は経験の反復で更新されるが、AIの「知っているつもり」は学習時点で凍っている。1に寄せておくことの価値は、この非対称のぶんだけ大きい。
根拠の確度
二つの源を分ける枠組み自体が、既存ノートからの派生として立てた解釈である。経済的性質の表は論理的な整理であって、実測や事例調査に基づかない。「習熟が高いほどplanを流し読みする」という観察は筆者の経験則で、定量的な裏づけを取っていない。AIが組織固有のmoduleについて「持ったつもりで誤る」という記述も、機序としてはもっともらしいが未検証である。