- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理今ここ
- DB保存
第14期の最終回です。9本で見てきた線を、引く前の判断にまとめます。
まず結論
線を引く判断は、場所の良し悪しより先に「後から引き直せるか」で二つに割れます。引き直せる線は速く決めてよく、引き直せない線だけが時間を要します。
どちらかは、線の向こうで呼んでいる相手を全部列挙できるかで決まります。列挙できなくなった瞬間に、その線は引き返せない側へ移ります。
「可逆な決定は速く、不可逆な決定は慎重に」という区別は、どこから来た言葉でしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
良い場所より先に決まること
9本かけて、線を引くと何が起きるかを見てきました。最後に残る問いは「ではどこに引くか」です。
ところが実務では、先に別の問いが割り込みます。この線は、後から動かせるのか。 動かせるなら間違いは後で直せます。動かせないなら、いま決めきる必要があります。
ここで言う「引き直す」は、表を引き直す(名前の解決をやり直す)ことではありません。1本目が扱ったのは表引きで、ここで言うのは境界の位置そのものを動かす操作です。
この区別が、どこから来た言葉なのか
「可逆な判断は速く、不可逆な判断は慎重に」の出所は、設計の文献ではありません。Amazon の2015年度株主宛書簡です。SEC に提出された Exhibit 99.1 で、署名は Jeffrey P. Bezos。"Invention Machine" という節にこうあります。
Some decisions are consequential and irreversible or nearlyirreversible – one-way doors – and these decisions must be mademethodically, carefully, slowly, with great deliberation andconsultation. (中略) We can call these Type 1 decisions. But mostdecisions aren’t like that – they are changeable, reversible –they’re two-way doors.
節の主題は設計ではなく、大きな組織が遅くなる理由です。続く段落は、組織が大きくなると Type 2 の判断にまで重い手続きを使いがちで、その結果が slowness, unthoughtful risk aversion, failure to experiment sufficiently, and consequently diminished invention だとしています。
「可逆/不可逆の区別はソフトウェアアーキテクチャの原則である」という説明の問題はどこですか。
原典が書いていないこと
この書簡は、二つに分かれることと、それぞれをどう扱うべきかを書いています。書いていないのは——節の全体を読んでも——どちらなのかをどう見分けるかです。原文では、どちらかは既に分かっているものとして扱われます。
設計では、ここが一番難しい。引き返せると思っていた線が、実は引き返せなかったという形で事故が起きるからです。
9本が答えているのは、この見分け方です。6本目のとおり、内部の関数を自由に変えられるのは呼び出し元を全部書き換えられるからです。
- ・分かれ目は社内/社外でも版番号でもなく、書き換えられる範囲の輪郭
- ・この判定は原典にも既存クイズにも無い、本コースの整理
9本が、それぞれどこを照らしていたか
判定の材料は、9本がそれぞれ置いたものです。
- 1本目 — 境界とは名前が解決される場所。表引きがいつ失敗するかが硬さでした。
- 3本目 — Fielding 本人が、帯域外の知識で資源の構造を仮定することを RPC の関数結合に相当する(the data-oriented equivalent to RPC’s functional coupling)と書きました。呼ぶ側の知識は外から見えません。
- 5本目 — 分けると、同一トランザクション・呼び出しが必ず返る確実さ・型検査が消えます。
- 6本目 — Semantic Versioning は公開済みの版への修正を事故でも認めません。
- 7本目 — 線は設計書ではなく話せる場所に出ます。費用には合意の取り直しも入ります。
- 9本目 —
202は RFC 9110 がintentionally noncommittalと書くとおり**何も約束しません。**約束しなかったものは後で足せます。
引き返せなくなるのは、手の届かない場所に何かが渡ったときだけです。渡ったのが値か知識か版か合意かによらず、共通するのは回収する手立てが無いことです。
社内の別チームだけが使っている HTTP の口があります。この線は引き返せる側ですか。
同一リポジトリ内のモジュール境界
分け方を変えたいとします。呼び出し元は同じリポジトリ内にあり、検索で数え上げられます。全部直して型検査を通せば、漏れは出す前に分かります。
やること できるか呼び出し元を数える できる全部書き換える できる漏れを出す前に知る できる(型検査)
公開した HTTP の口
同じく分け方を変えたいとします。呼んでいるのは知らない誰かのコードで、一覧は手元に届きません。古い口を残して新しい口を足し、移るのを待ちます。
やること できるか呼び出し元を数える できない全部書き換える できない漏れを出す前に知る できない
同じ「分け方を変える」でも、掛けるべき時間が違います。どちらにどれだけ掛けるべきで、それはなぜでしょうか。
間違えたときに何が残るか、を両方で考えてみてください。
なぜこの判断だけが残るのか
序章『生成されたコードの読み方 — 「動く」と「正しい」の差』は、「動く」をある1回の実行で観測された結果、「正しい」を実行しない場合も含めて成り立つ性質と定義しました。
線の引き方の帰結は、すべて後者の側にあります。型が越えないことはその値が来るまで、公開が取り消せないことは変えようとするまで、観測に現れません。実行を重ねてもこの範囲は埋まりません。
だから序章1本目『エージェントに任せられること — 観測できないものは検証できない』の結論が当てはまります。境目は難しさではなく観測窓の内か外かです。実装が速く正確になるほど外に残る判断の比重が上がり、線を引く判断は、そこに残ります。
この章のまとめ
- 「どこに引くか」の前に「後から動かせるか」が決まり、掛けるべき時間はここで決まる。
- この区別は Amazon の2015年度株主宛書簡(SEC 提出の Exhibit 99.1)由来で、規格でも論文でもなく組織の意思決定についての文書。
- 原典は見分け方を書いていない。本コースが置いたのは「呼び出し元を全部列挙できるか」という判定で、これは教材側の整理。
- 判定に社内/社外・版番号は入らない。入るのは書き換えられる範囲の輪郭だけ。
- 線の帰結は実行しても観測に現れない。だからこの判断は人の側に残る。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
2015年度株主宛書簡の記述を、教材で使うときの扱い方として適切なのはどれですか。
用語集(4語)
- Type 1 / Type 2 decisions
- 2015年度の Amazon 株主宛書簡が導入した区別。引き返せない判断(one-way doors)と引き返せる判断(two-way doors)。組織の意思決定についての記述で、設計の文書ではない。
- 線を引き直す
- 本コースでは、既にある境界の位置そのものを動かす操作。1本目が扱う「表を引き直す」(名前の解決をやり直す)とは別の操作。
- 呼び出し元の列挙可能性
- その境界を越えて呼んでいる相手を全部数え上げて書き換えられるか。線の硬さの判定に使う、原典にも既存クイズにも無い教材側の整理。
- 観測窓
- 序章が導入した語。ツールが返す値として現れる範囲。この外側の性質には、誤りを示す信号が出ない。