この紙はとても具体的な一つの場面のためのものだ：誰かがあなたにシステムを作りましょうと申し出ている、あるいは引き渡そうとしている。そしてあなたはプログラミングをしない。この会合のためにプログラミングを学ぶ必要はない。必要なのは、何を見せてくれと求めるかを知ることだ。
方法の全体は二十四段の契約の中にあり、各契約は自分の「コードを読まない完全性の検証」を持っている：引き渡されたものについて持ち主が行う確認の一覧だ。それはプロジェクトが進行中なら役に立つが、三十二のファイルに分かれていて、誰もそれを持って会合に入らない。この紙は同じものを、何を約束されているかで並べてまとめたものだ。印刷して持っていく。
値のある答えは、見られる答えだ。 ファイル、それを生むコマンド付きの数字、失敗するのを見たテスト、マニュアル、日付入りの署名。見られないものは約束であり、約束は答えではない：会合を閉じたい誰かが言った意図だ。
見せられたものを理解する必要はない。存在することと、その人が目の前で開いてくれることで足りる。答えるためにまだない理由を説明しなければならないなら、日付を書き留めて次の会合でまた聞くこと：見せずに二度繰り返されるものは現れない。
見分けておくとよい三つの言い回し。「それは持っていない」という意味だからだ：
そして逆方向の正直な注記：理由つきの「ない」は良い答えだ。「利用者は三十人で、そう合意したので負荷試験はありません」は理由つきの「ない」であり、方法が釣り合いと呼ぶものそのものだ。役に立たないのは、見られない「あります」だ。
会合が短いなら、この五つが二十五よりも多くを教える：4（赤を見たテスト）、7（計画は保留項目だということ）、13（構築を止める限界値）、20（人が試した復旧マニュアル）、 24（検証できなかったものを言う報告）。この五つが見られるなら、残りはほぼ常にある。どれも見られないなら、残りはほぼ常にない。
1. あなたのコンピューターではない環境で動いているシステムを見せてもらえますか？ 見られるもの：あなた自身が自分の電話で開くアドレスと、試験用のデータ。作った人のマシンでしか動かないなら、まだシステムとしては存在していない。 （第15段。）
2. 私の依頼が終わったとあなたが見なすには、何が真でなければなりませんか？ 見られるもの：始める前に、依頼ごとに書かれたもの。「テストが通った」と「人が使った」を含んでいるべきだ。答えが「動いたとき」なら、基準はない：意見があるだけだ。 （第5段、受け入れ基準。）
3. 私が大事にすることの一つ一つに自動テストはありますか？ 見られるもの：テスト一式の実行結果が、数字つきで画面に。中身は問題ではない：出力があり、何件通ったかを言っていることが問題だ。 （第8段。）
4. そのテストの一つが失敗しているところを見せてもらえますか？ 見られるもの：直しの入っていないシステムに対してテストが赤くなった画面の一部と、それを走らせたコマンドと日付。この紙で最も重要な質問だ：誰も失敗するのを見ていないテストは、何かを証明しているかどうかわからない。システムは通るテストを千持ちながら、何も見張っていないことがありうる。 （第8段。方法では「赤で試した」と言う。）
5. あなたでもプログラムでもない誰かが、システムを使って最後まで到達しましたか？ 見られるもの：人のために書かれたテストケースの一覧と、日付、実行した人の名前、何が起きたか。作った人が試した唯一の人であってはならない。そしてモデルは自分が理解したことを試すのであり、それはあなたが求めたことと常に同じではない。 （第10段。）
6. 私が画面で間違えたら——二度入力したら、急いでボタンを押したら——どうなりますか？ 見られるもの：取り消せない操作の一覧と、それぞれの錠、そして途中で失敗したらどうなるか。正しい答えは決して「それは起きないはずです」ではない。 （第14段。）
7. 残っているものの一覧はどこにあり、今日見られますか？ 見られるもの：番号の付いた保留項目の登録簿。一つ一つが詳細に書かれ、閉じた日付が付いている。 その一覧が計画だ：別のところに計画があってこちらに一覧があるなら、計画は二つあり、価値があるのは誰も見ていない方だ。 （第5段。）
8. 私に作るもの一つ一つは、作る前に、私の言葉で書かれていますか？ 見られるもの：開いている保留項目。依頼がどこから出たかの経緯があなたの言ったとおりに書かれ、適用される規則、画面、変わった場合も書かれている。一行で書かれているなら、足りない部分は誰かがでっち上げる。 （第5段。）
9. 事業のことで何かがはっきりしないとき、あなたはどうしますか？ 見られるもの：決定のファイル。日付と、それぞれを誰が決めたか付きで。求めている答えは「あなたに尋ねて書き留めます」だ。事業の規則に穴を見つけたモデルは自分でそれを埋めて先に進み、六週間後には誰もシステムがなぜそうするのかを知らない。 （第1段と第6段。）
10. システムがしないことは書かれていますか？ 見られるもの：プロジェクトの文書の中の独立した節で、少なくとも二項目。言われていないことこそが、別のやり方で作られて現れるものだ。 （第2段。）
11. これを使うことになる人の種類はそれぞれ誰で、それぞれが何をできるかは書かれていますか？ 見られるもの：プロフィール一覧——それぞれが誰で何をしに来るのか——と、どのプロフィールが何をできるかを言う表。「ユーザー」という一つのプロフィールしかないなら、ほぼ必ず半分が足りない：自分のものでないボタンが誰かに見えている、あるいは権限があるのに画面が見つからない、その最もよくある原因だ。 （第2段、附属書Hの前提入力。第8段、行列。）
12. 誰かが見るのを覚えていなくても、変更ごとに機械が測るものは何ですか？ 見られるもの：リポジトリの中の検証の連鎖の設定と、直近の実行の記録。「私たちの間で見直しています」は答えではない：習慣であり、習慣は急ぎの週に崩れる。 （第4段と第9段。）
13. 超えたら構築を止める限界値はありますか？ 見られるもの：限界値とその今日の測定値が書かれたファイルと、そのどれかで止まった実行。そのまま尋ねるとよい統制の質問：*先に進むために限界値を上げたことはありますか？* 答えが「ある」で、なぜかが書かれていなければ、その限界値は飾りだ。 （第9段。）
14. そのコードを別の人が保守できると、どうしてわかりますか？ 見られるもの：単一の数字ではなく、ルールごとの報告：ファイルの大きさ、関数の大きさ、重複したコード、死んだコード。「品質九十五パーセント」は何を直すべきかを言わない。 （第9段と附属書H。）
15. 画面は誰かが考えたものですか、それともプログラムが必要としたものから出てきたものですか？ 見られるもの：使いやすさのルールの結果の記録と、消された例外の記録——書かれた理由、誰が承認したか、いつ見直すか。システムは技術的な検証をすべて通りながら使えないことがありうる：すべて緑で、人はどこで代金を受け取るのか見つけられない。 （附属書H、使いやすさの二十七のルール。）
16. 見せてもらったテストは本当に見張っていますか、それとも飾りですか？ 見られるもの：ミューテーションのスコア。わざと誤りを入れて、テストが何個捕まえるかを数えるプログラムで、数字はそのコマンドとともに出る。あなたのシステムに実際の利用者がいるなら、方法ではこれは任意ではない。 （第9段。）
17. 操作の途中で何かが壊れたら、私のデータはどうなりますか？ 見られるもの：操作とその取り消し可能性の表、そして疑わしいときはシステムが先に進む代わりに 止まるという書かれた規則。二重の課金や、誰も見ていない自動承認が典型的な場合だ。 （第14段。）
18. バックアップはありますか、そして一度でも復元を試したことはありますか？ 見られるもの：最後に試した復元の日付。一度も復元していないコピーはバックアップではない：誰も何も知らないファイルだ。 （第20段、復旧マニュアル。）
19. システムに既知の穴がないことを誰が、どのくらいの頻度で確認しますか？ 見られるもの：連鎖の中で走っている走査と日付、そして見つかったものが保留項目に変わっていること。加えて、短くてとてもよく効く質問：*システムの鍵やパスワードはどこに保管されていますか？* コードの中にあるなら、もう問題を抱えている。 （第18段と第15段。）
20. プログラミングをしない誰かが、マニュアルに従ってゼロからシステムを復旧しましたか？ 見られるもの：マニュアルと、その試行の記録の三つ：端から端まで何分かかったか、その人がどの手順で正確につまずいたか、どの語を理解できなかったか。マニュアルが「エージェントとのセッションを開く」で始まるなら、それは人のためのマニュアルではない。そしてそれが存在しない間は、遠回しにせず言う：持ち主は持ち主ではなく、借主だ。システムを持ち、代金を払い、作った人に許可を求めずには入れない。 （第20段。）
21. これはどんな数字で寸法を決めましたか、そしてその数字はどこから出ましたか？ 見られるもの：同時に何人の利用者か、一日に何件の操作か、年にどれだけ増えるか、どれだけの期間保管しなければならないか。そして大事な部分：その数字を持っているのはあなたの事業であり、作る人ではない。作る人がでっち上げたなら、それは間違っている。 （第3段。）
22. 私が与える負荷で試しましたか、そしてその十倍でも試しましたか？ 見られるもの：実行の報告と、システムが倒れた正確な地点。どこで壊れるかを知ることが、どれだけ余裕があるかを知る唯一の方法だ。 （第19段。）
23. 六か月後にシステムが遅くなったとき、理由をどうやって知るのですか？ 見られるもの：操作ごとの識別子を持つ構造化された記録、最も遅い問い合わせの報告、そして設定された警報。答えが「起きたときに見ます」なら、最初に見るのはあなたで、怒った利用者を通してだ。 （第16、17、21、22段。）
24. 何かができたと報告するとき、試したことと推測していることを私はどう区別しますか？ 見られるもの：三つの区画に分かれた報告：検証済み（証拠を隣に）、信じている（そしてなぜ試さなかったか）、盲点（今いる場所から見えないもの）。素っ気ない「できました」は報告ではない。そして質問の後半は前半より価値がある：*この引き渡しのうち、検証できなかったものは何ですか？* 答えが「ありません、すべて検証しました」なら疑うこと：すべてを検証する人はいない。 （第12段。）
25. あなた自身のほかに、誰が仕事を見直しますか？ 見られるもの：作った人とは別の誰か——あるいは何か——が行った監査と、その発見が保留項目に変わっていること、そして日付。モデルは自分の誤りのかなりの部分を是認するし、人もそうだ。作る人が検証する唯一の人であってはならない。 （第13段。）
各質問の横に三つのうち一つを書き留めること：見た、まだ見ていない（約束された日付付き）、 存在しないが理由を言われた（理由付き）。二十五すべてが「見た」になる必要はない：小さなプロジェクトは負荷試験も週次の監視も必要とせず、方法もそう言っている。必要なのは、どの「ない」にも理由が書かれていることだ。理由つきの「ない」はあなたの決定であり、理由のない「ない」は、選んでもいないのに払うことになる負債だ。
そして最後に一つ、提供者向けではないので番号を付けない：見せてくれと求めることで誰かが気を悪くするなら、それも情報だ。
二十五の質問は、この方法の契約の「コードを読まない完全性の検証」をまとめたものだ。それぞれが出どころの段を挙げているので、誰でも契約に行って完全版を読める。この紙のためにゼロから書いた。
これが一枚の紙として存在しなければならないという考えは私のものではない。 方法を別の形式に翻案した最初のもの——オスカル・シュミッツの小説『El Arte de Forjar Sistemas』、2026年、主文書のパートFで出典を示している——から来た。私よりうまく言ってくれた：方法は検証を契約に分けて持っていて、持ち主が会合に持っていく部品が欠けていた。この紙の冒頭の基準——値のある答えは見られる答えだということ——もそこから来ている。彼の版の質問は彼の作品であり権利は留保されている。ここにあるのは別のもので、私の契約から書いたものだ。だからこのリポジトリのライセンスで公開する。