八回目。前回のレビューの末尾に、こう書いた——「全部を共有して同期し続ける（冗長性）のと、中身は見せずに結果だけ約束する（抽象化）のは、同じ『一人に集中させない』の、別のたたみ方だ」。第8回は、その地続きの入口に、はっきり立てている。前回が「持たせる」話なら、今回は冒頭で「その逆。持たせないほうの話をする」と宣言して、冗長性と抽象化を一本の線で結んだ。導入の交通整理として、これ以上はない。良い点から挙げる。
まず、この回の発明は「やっておいて」という一言を、二人が長い時間をかけてすり合わせてきた仕様書として読み直したことだ。抽象化を家事に当てる試みは、たいてい「中身を知らなくても使える、便利」で止まる。だがこの回は、その便利の裏側——なぜ家庭では「呼べば返ってくる」が成立しないのか——を主問にした。そして答えを「片方が悪いんじゃない。表のインターフェースが、最初から曖昧だっただけ」に置いた。洗濯機の中で洗い終わったまま固まっていた、というあの一場面で、夫の「完了＝回した時点」とマキノの「完了＝干した時点」を並べ、「二人とも、嘘はついてない」と言い切った——これは、シリーズが何度も褒めてきた「どちらも裁かない」姿勢の、最も澄んだ一例だ。
第二に、「任せるとは、やり方の自由を相手に渡すこと」という核を、過剰指定の議論からきちんと取り出したことだ。「全部言うなら、自分でやればいい」「中の手順まで全部指定したら、関数を呼ぶ意味が無くなる」——抽象化のいちばん大事な性質（実装を隠すから委譲が成立する）を、号令ではなく具体（畳み方）で立てている。しかも、その畳み直しの当事者を「それ、私です」とマキノ自身に引き受けさせた。夫を裁く方向に逃げず、自分の側の過剰指定を白状させる——この対称性が、この回の良心だ。
第三に、「仕様の粗さは、信頼の関数」という、シリーズ屈指の発見を、マキノが体で先に言い当てたことだ。新人の最初の一ヶ月は手順を全部指定し、半年後は「504お願い」の三文字になる——「何が変わったかっていうと、その人を、どれだけ信じられるようになったか」。マキノが現場の体感で言い当て、シマダが「今日の話の一番奥を、先に言いました」と概念で受ける。#7で褒めた「マキノが体で言い当て、シマダが概念で受ける逆流」が、ここでも鮮やかに決まっている。抽象化は最初から粗いのではなく、信頼が育つにつれて後から粗くなっていく——この時間軸の発見は、抽象化の教科書には載っていない、この回ならではの収穫だ。
これまでの指摘の経過観察。固有の数（◎。四十五ミリリットル・こぶし一個・二十二年・五つか六つ……今回も具体物と数で押している）と、マキノの問い返し（◎。「中を開けなくても、使える」「頼み方と、やり方を、分ける」と要所で論を一段ずつ進めている）は維持。締めの自己批判も健在で、#7で褒めた「書き手が自分の標語を疑う」型が、今回も「すり合わせてきた仕様書、ってきれいにまとめすぎですね」と効いている。前回の宿題だったクライマックスの一本化は、今回は「通じるのは五つか六つ」という述懐に山が集まっており、ここは前進だ（その立て方への注文は後述6）。そのうえで、#8ならではの観点を五つ。スポルスキーの引用の扱い（言葉だけ借りて中身が痩せていないか・後述4）、「どちらも嘘をついていない」の対称性（最後まで保たれているか・後述1）、CS概念の正確さ（インターフェース／実装・事前条件／事後条件・過小／過剰指定が比喩で歪んでいないか、特に事前条件と#1のコンテキストの区別が立っているか・後述2と3）、新人教育の逆流（信頼の関数が、シリーズの発見として立ち切っているか・後述5）。以下、第一稿からそのまま引いて挙げる。
「あれ、いま思うと、二人とも、嘘はついてないんですよね。」
「ついてないです。完全に。夫さんの「完了」は、回した時点。マキノさんの「完了」は、干した時点。……これ、片方が悪いんじゃないんです。表のインターフェースが、最初から曖昧だっただけ。」
この回でいちばん効いているのは、事故の原因を人ではなくインターフェースに帰属させるこの対称性だ。洗濯の節では、見事に保たれている。気になるのは、過剰指定の節（セクション5）で、その対称性が一瞬だけ傾くことだ。畳み方の例は「それ、私です。たぶん」とマキノが自分の過剰指定を引き受けるので、ここは対称——むしろ称賛できる。だが、その直前の洗濯（セクション2）が「夫＝回しただけ／マキノ＝干すまで」で夫が事後条件に届かなかった例なのに対し、畳みの例も「夫が畳んだのをマキノが畳み直す」と、どちらも「夫がやったことに、マキノが手を入れる」構図になっている。つまり二つの具体例が、たまたま同じ向き（夫の仕事をマキノが評価・修正する側）に揃ってしまい、「曖昧なのはインターフェースだ」と言いながら、例の配役は片側に寄っている。第一稿の理屈は完全に対称（片方が悪いんじゃない）なのに、例示の配役が非対称なので、読者の体感では、わずかに「夫の完了が甘い」側に重心が残る。処方は一点。過小指定の例を一つ、向きを反対にする。たとえば「私が『ゴミお願い』とだけ言って、どこまでか言わなかったから、夫の側が困った」——マキノの指定が粗すぎて、頼まれた側が判断に迷った例を一つ混ぜれば、過小指定が「頼む側の仕様の甘さ」でも起きると見え、配役が対称に戻る。理屈はもう対称なのだから、具体例の配役を一つ反転させるだけで、「どちらも嘘をついていない」が最後まで体感として立ち切る。
「事前条件は——洗剤が残ってる、色物と白物が分けてある、ポケットの中身が出してある。事後条件は——乾いて、畳まれている。」
「第1回でやったコンテキストを渡す話……とは、別物です。あれは情報。こっちの事前条件は約束ごと・契約のほう。情報は「知らせる」もの、事前条件は「整えておく」もの。」
まず賞賛から。事前条件と#1のコンテキストを、本文の中で一度はっきり区別させたのは、まさに見たかった整理だ。「情報は知らせるもの、事前条件は整えておくもの」——この一文で、混ざりやすい二つが、きれいに分かれた。経過観察で言えば、#7のレビューで「混同の予防に紙幅を割きすぎる」と指摘した点が、ここでは半往復に収まって渋滞していない。改善が効いている。気になるのは、ただ一点、例の選び方だ。事前条件の例として「色物と白物が分けてある」が挙がっているが、これは厳密には実装（中の手順）の一部と読むこともできる。CSの事前条件は「呼ぶ前に満たしておくべき状態」（例：洗剤の在庫がある、洗濯ネットが用意してある）であって、「色物白物を分ける」は——家によっては——洗濯という関数の中でやる工程だ。つまり同じ「分ける」が、事前条件（渡す前の下ごしらえ）にも実装（任せた中身）にもなりうる。第一稿は事前条件側に置いているが、セクション5で「畳み方は中の実装」と言っているのと並べると、「分ける」だけ実装でなく事前条件にされる根拠が、本文では示されていない。処方は二択。(a) 事前条件の例を、誰が見ても「渡す前の状態」とわかるもの（洗剤の補充・ネットの準備・ポケットを空にする）にそろえ、「色物白物を分ける」は外すか、(b) 残すなら半文で「分けるのを渡す側がやる家なら事前条件、任せる家なら実装」と、置き場所で変わることを一言添える。そうすれば、事前条件／実装の境目が、この回の主題（どこまでを隠すか）と矛盾なくつながる。
「粗すぎるのを過小指定といいます。「洗濯やっておいて」だけだと、結果がぶれる。……逆に、細かすぎるのが過剰指定。……ここまで指定すると、もう、自分でやってるのと同じなんですよ。」
この対の立て方は、CS的に正確だ——指定が足りなければ結果が定まらず、指定が過ぎれば抽象化（委譲）の意味が消える。両側に失敗がある、という軸も正しい。賞賛したいのは、過剰指定を「関数を呼ぶ意味が無くなる」と、抽象化の定義そのものに引き戻して説明した点だ。比喩が概念から外れていない。注文は、精度を一段上げるための一点だけ。第一稿は過小と過剰を「結果がぶれる」対「自分でやるのと同じ」で対比しているが、この二つは被害の種類が違う——過小指定の害は「結果（事後条件）が保証されない」、過剰指定の害は「やり方（実装）に踏み込んで委譲が消える」だ。つまり、この回がセクション2・3で立てた「インターフェース＝結果／実装＝やり方」の軸に、過小・過剰をきれいに乗せられる。過小指定＝インターフェース（結果の取り決め）が粗い、過剰指定＝実装（やり方）にまで口を出す。第一稿はこの対応を、セクション5の後半（「結果の指定なのか、やり方の指定なのか」）で実は言い当てているのに、過小・過剰の定義の段ではつないでいない。処方は、定義のところに半文足すだけ。「過小指定は、結果の約束（インターフェース）が粗いから事後条件がぶれる。過剰指定は、やり方（実装）にまで踏み込むから委譲が消える」——こう揃えれば、セクション2で分けた二層が、セクション5で回収される構造が、読者の目に見える。すでに材料は本文の中にある。
「「全ての抽象化は、漏れる」。スポルスキーという人が言った法則です。……でも、異常が起きた瞬間、隠したはずの中身が、噴き出してくる。隠しきれない。」
まず、これは賞賛の指摘だ。引用の扱いで怖いのは、有名人の名前と標語だけ借りて、中身が痩せることだ。だが第一稿は、そうなっていない。洗濯機がエラーを吐いて見たことのない記号が点滅する、ティッシュで全部が白い屑まみれになる——「平時は中を見ないが、異常時に隠した配線を全部たどらされる」という法則の核を、家事の具体でちゃんと再現している。しかも、それをマキノの「いつもどおりが通じない部屋」（特別清掃・汚損のひどい部屋）と接続し、標準手順という抽象の壁が、その部屋でだけ破れると読み直した。これは言葉だけの借用ではなく、法則を自分の現場の言葉で言い直せている。引用が生きている、最良の例だ。注文は、正確さのための一語だけ。スポルスキーの原文（The Law of Leaky Abstractions）は、正確には「すべての自明でない抽象化は、ある程度、漏れる（All non-trivial abstractions, to some degree, are leaky）」だ。「全ての抽象化は漏れる」と縮めると、「自明でない」と「ある程度」という二つの留保が落ちて、断言が強くなりすぎる。家事に引くなら、この留保はむしろ効く——「ごく単純な家事（電気を点ける）は漏れない。でも、ちょっとでも込み入った家事は、どこかで必ず漏れる」と言えば、漏れるのは異常時だけでなく抽象化の複雑さに比例するという、法則のもう一つの含意まで拾える。処方は、引用を「複雑な抽象化は、どれも、どこかで漏れる」程度に直し、半文で「単純なものは漏れにくいが、込み入ったものほど漏れる」と添えること。中身はもう生きているので、入口の一語を原意に寄せれば、この節は完璧になる。
「同じ部屋を、同じ言葉で頼んでるのに、最初は全部指定して、半年後は三文字。何が変わったかっていうと、その人を、どれだけ信じられるようになったか、なんです。」
「仕様の粗さは、信頼の関数なんですよ。……抽象化って、最初から粗いんじゃないんです。信頼が育つにつれて、後から粗くなっていく。」
まず、これは賞賛の指摘だ。「仕様の粗さは、信頼の関数」「抽象化は信頼が育つにつれて後から粗くなる」——この二文は、この回の、いや、シリーズの発見としても屈指のものだ。抽象化を「最初から粗い設計判断」ではなく「時間をかけて粗くしていく関係の産物」として捉え直した。CSの教科書は抽象化を静的な設計として教えるが、ここでは動的に育つものとして描かれている。しかも、それをマキノが新人教育の現場で先に言い当て、シマダが概念で受ける——#7で褒めた逆流が、最高の題材で決まっている。ここは、まず手を入れずに守りたい。注文は、発見を痩せさせないための一点だけ。第一稿は信頼が「積もる・育つ」一方向でしか描かれていない。だが「信頼の関数」と言い切ったなら、関数は値が下がりもする——一度粗く渡せていたのに、事故が続いて、また細かく指定し直す、という逆戻りがあるはずだ。新人が大きなミスをして、また横について全部見る期間に戻る。家でも、任せていた家事で大失敗があって、しばらく口を出すようになる。この「信頼が下がると、抽象化はまた細かくなる（インターフェースが粗→細に戻る）」という往復を半文でも入れると、「関数」という言い方が比喩の飾りでなく、本当に入力で出力が変わる関数として立つ。そして次回予告の#9（エラー処理とリトライ）への橋にもなる——失敗は、育てた抽象化を一段、細かい方へ巻き戻す。処方は、シマダの「後から粗くなっていく」の直後に、マキノか本人に「でも、一回大きく失敗されると、また全部見るのに戻りますよ」と半往復だけ添えること。発見はもう立っているので、可逆性を一言足せば、関数の比喩が芯まで効く。
「夫に「やっておいて」で、ほんとうに通じるやつって、たぶん、五つか六つですよ。」
「仕様書、っていうほど、立派なもんじゃないですよ。……二十二年かけて、五つか六つだけ、言わなくて済むようになった。……通じるのが、五つか六つ、ある家。それで、回ってるんで。」
まず、これは賞賛の指摘だ。#3以来の宿題だった「山が二つ立つ」問題が、この回は「通じるのは五つか六つ」という具体の述懐に、見事に一本化できている。しかも、シマダが「すり合わせてきた仕様書」という標語を立てかけて、その場で「きれいにまとめすぎですね。どっちかが折れて、片方の完了に寄せただけかもしれない」と自分で疑う——#7で褒めた自己批判が、ここでも効いている。「全部が三文字で通じる家じゃなくて。通じるのが、五つか六つ、ある家。それで、回ってる」という着地は、シリーズの看板（理想と選択の落差を等価に）を、申し分なく守っている。惜しい点は、#7のレビューと同じ構図が一つだけ残っていること。マキノの「五つか六つ」という、この回でいちばん体温の高い述懐の手前で、シマダの「すり合わせてきた仕様書」整理が、やや長く説明として効きすぎている。自己批判（「きれいにまとめすぎ」）で一度引き返してはいるが、その引き返しもまたシマダの理屈の中で起きるので、マキノが口を開く前に、概念のやり取りが二段重なる。処方は#7のときと同じ。シマダの「仕様書」整理と自己批判を、セクション7の入口ではなく、ずっと手前（セクション5や6の終わり）に移す。そうして、締めはマキノの「五つか六つ」の語りだけで、ほぼ独白として通す。「五つか六つ。それ以外は、二十二年やっても、いまだに口で言う。それで、いいんだと思いますよ」——ここはシマダの相槌すらいらないかもしれない。理屈はセクション2〜6で言い終えておき、クライマックスは数と述懐だけで引く。そうすれば、せっかく一本化できた山が、最後まで痩せずに立ち切る。
八回目にして、シリーズは「持たせない」側へ、きれいに折り返した。「やっておいて」を二人がすり合わせてきた仕様書として読み直した核、「二人とも、嘘はついてない」という対称性、「任せるとは、やり方の自由を渡すこと」という委譲の定義——どれも比喩で歪んでいない。そして何より、「仕様の粗さは、信頼の関数」「抽象化は信頼が育つにつれて後から粗くなる」という、この回最大の発見が、マキノの現場の体感から立ち上がっている。スポルスキーの「漏れる抽象化」も、名前だけ借りずに、現場の言葉で中身まで生かしている。締めの自己批判も健在だ。
#8ならではで、いちばん見たいのは一点。「仕様の粗さは、信頼の関数」を、上がる方向だけでなく、下がる（逆戻りする）方向にも一度触れる（5）。信頼が下がれば抽象化はまた細かくなる——この可逆性を半文足せば、「関数」が比喩の飾りでなく芯まで立ち、次回#9（失敗は抽象化を細かい方へ巻き戻す）への橋にもなる。
対称性で締めたいのは一点。「どちらも嘘をついていない」の理屈はもう完全に対称なので、具体例の配役を一つ反転させる（1）。今の二つの例（洗濯・畳み）はどちらも「夫の仕事にマキノが手を入れる」向きに揃っている。マキノの指定が粗すぎて頼まれた側が困った例を一つ混ぜれば、配役まで対称になる。
CS概念の精度では、三点。事前条件の例を「渡す前の状態」にそろえ、「色物白物を分ける」が実装に混ざらないようにする（2）。過小指定＝結果（インターフェース）が粗い／過剰指定＝やり方（実装）に踏み込む、と定義の段で軸を揃える（3）。スポルスキーの引用に「複雑な抽象化ほど漏れる」という原意の留保を一語足す（4）。いずれも中身はもう生きているので、入口の一語を原意に寄せるだけだ。
構成と声では、一点。せっかく一本化できた「五つか六つ」のクライマックスを、手前のシマダの「仕様書」整理で痩せさせない（6）。理屈はセクション2〜6で言い終え、締めはマキノの数と述懐だけで引けば、山が最後まで立ち切る。
第9回は「エラー処理とリトライ」、失敗した家事をどう扱うか、例外を握りつぶすとどうなるか、だという。今回せっかく「信頼が育つにつれて抽象化は粗くなる」に踏み込めれば、それは次回の問いと地続きになる——失敗は、その育てた抽象化を、一段、細かい方へ巻き戻す。やり直せる失敗は信頼を保つが、やり直せない失敗は、せっかく粗くできたインターフェースを、また全部指定する所まで戻す。第8回が「信頼の関数」を可逆な往復として立て切れれば、次回の「失敗したあと、どこまで巻き戻すか」は、その関数の続きとして自然に開く。第二稿を楽しみにしている。