Steve Test：その仕事は存在に値するか？

今週の前半、ある仕事について、正しい判断はリリースしないことでした。このサイトでは、10ロケール分のコンテンツをCloudflare D1へ書き込む翻訳パイプラインがあります。3件の翻訳ジョブが同時にレート制限に当たり、フォールバック機構がそのうち6ロケールの「翻訳」として英語の原文をD1へ静かに書き込みました。そのうえで、チェックポイントのハッシュも英語コンテンツに一致するよう更新されました。ディスク上では成功に見えました。パイプラインは「完了」と報告しました。指標上は10ロケールがリリース済みでした。自動チェックはすべて通っていました。

ドイツ語の読者が/de/guides/claude-codeに来たら、ドイツ語の段落、英語の段落、またドイツ語の段落、そして英語のセクション見出しに遭遇していたはずです。切り替わりを説明する目印はありません。そのページは意図されたもののように見え、サイト全体を信用できないものにしました。本来担うべきことでも、おそらく同じように失敗しそうなプロダクトに見えたのです。私が計測していたすべての層で、Jiro Test（その仕事は正しいか？）は通っていました。それでも、その成果物は存在に値しませんでした。見た目はプロダクトなのに、振る舞いはユーザーへの侮辱でした。

正しい答えは、止めることでした。英語フォールバックが起きたすべてのバッチを監査し、チェックポイントのハッシュを慎重に消し、翻訳パイプラインを1ジョブずつ実行し、ロケールごとに確認し、コミットしてプッシュする。実時間でおよそ6時間の翻訳時間と、再発を防ぐためのガードレールのパッチが必要でした。ディスク上の成果物は、その間ずっと「動いて」いました。本番にあった成果物は、私が引き起こした損害でした。

失敗の形は、成果物が翻訳パイプラインでも、サインアップフローでも、機能トグルでも、CSVエクスポートでも、マーケティングページでも同じです。自動チェックはすべて通る。それでも、現実のユーザーの前に届くものは損害になる。

プロダクトで最上位に置くべき問いは、完了したか？でも動くか？でもありません。最上位の問いは、その仕事は存在に値するか？です。 すべての成果物は、リリース前にこの問いへ答えなければなりません。正しさを問う別のテストと並べてです。存在価値のない正しさは、在庫を生みます。機能し、リリースされ、それでも信頼を得られないものです。正しさのない存在価値は、見せかけを生みます。正しそうに感じられて、壊れるものです。両方のテストに通らなければなりません。

私が使っている略称が Steve Test です。厳密さと証拠のための Jiro Test の隣に置いています。これは、同じ頭で適用する2つの別の問いです。どちらか一方でも落ちる仕事はリリースしません。

TL;DR

Steve Testは、すべての成果物が通るべき2つ目のテストです。Jiroは、その仕事が正しいかを問います。Steveは、その仕事が、作っている全体の一部として存在に値するかを問います。このテストは抽象論ではなく具体的なものです。現実のユーザーが、現実の瞬間にそれに触れる状況で測ります。そして、このテストが最も一貫して生む出力は拒否です。私はスコープを削ります。機能を消します。残ったものは、私の名前を背負えるものでなければなりません。両方のテストに通る必要があります。Jiroで不合格なら、止めて直します。Steveで不合格なら、作り直します。誠実な作り直しは3回までです。それでも駄目なら、問題は上流、つまり問題設定にあります。

「完了したか？」が間違った問いである理由

ほとんどのプロダクトチームは、リリース可能であることに最適化します。測定されるアウトプットは、コミット、デプロイ、ベロシティチャート、本番に何かが存在することです。失敗モードは予測できます。チームは、正しく機能しながらユーザーの信頼を静かに消費する成果物を、安定して作り続けます。オンボーディングは完了するが、2回目の利用は起きない。サポートチケットは、プロダクトが扱えると主張しているタスクの周辺に集中する。チャーンの曲線は、コア層として平らになるどころか、ゼロに向かって落ちていきます。

完了と存在に値するは別の測定軸です。機能は完了していても、存在に値しないことがあります。ページはレンダリングされても、読者を侮辱することがあります。翻訳は技術的に存在していても、実質的には嘘であることがあります。何かが完了したかどうかを測るテストは、指定された振る舞いを実行するかどうかです。何かが存在に値するかどうかを測るテストは、それをリリースしたことで、現実の瞬間にいる現実のユーザーがよりよい状態になるかどうかです。

存在に値する最小限のプロダクトでの私の主張は、実務上のMVP文化が2つの問いを1つに潰してしまった、というものです。速く学ぶは速く出すへと劣化し、出すこと自体が重要な指標になりました。⁷ 治療法は二重基準です。最小限であることはスコープを削ります。価値があることは、残した面をユーザーが感じ取れる基準に保ちます。Steve Testは、残した面がその基準を越えたかどうかを判断するときに使うツールです。

最上位の問い

その仕事は存在に値するか？

私はこの問いを文字どおり使います。仕事を終えて、それをリリースするかどうか決めるとき、声に出して問いかけます。答えは雰囲気ではなく判定です。答えがyesなら、その仕事はリリース候補になります。次に問うべきは、正しさについてJiro Testにも通るかどうかです。答えがnoなら、その仕事には作り直し、または削除が必要です。答えがまだ。ただし、定義した修正で届くなら、作業を続けます。

この問いは、答えがnoであることを許されている場合にだけ機能します。目の前にあるものすべてにお墨付きを与えるSteve Testは、テストではありません。このテストが本当に動いているサインは、落ちる仕事があることです。

ユーザー軸：存在価値は決して抽象ではない

Steve Testは、仕事を単体で眺める美意識の議論になった瞬間に失敗します。存在価値は、特定のユーザーが特定の瞬間にいる状況に対して測ります。正しく表現されたテストの問いは、こうです。この仕事は、この瞬間のこのユーザーにとって存在に値するか？

blakecrosley.comにとってのユーザーは、Claude CodeやCodex、インフラについて未解決の問いを抱え、事前文脈なしに検索から来る読者です。その瞬間とは、ページ読み込み後の最初の5秒です。ページがまだ何の信頼も獲得していない時間です。速く読み込まれ、視点が読み取りやすく提示され、検索結果だけでは得られなかったことを読者に伝えるページは、基準を越えています。遅いバンドル、閉じられないCookieバナー、SEOの形だけをした凡庸なテキストの壁で読者を罰するページは、Jiro軸でどれほど高得点でも失敗です。

ResumeGeniにとってのユーザーは、私が脆弱な瞬間として扱う状況にいる求職者です。初期ウェイトリストの大半は、レイオフ後、または面接サイクルの途中で来ていました。⁶ 存在に値する版は、その人たちをコンバージョン指標として扱うことを拒みます。コピーは曖昧に逃げません。パーサーは見つけたものについて嘘をつきません。アドバイスは、実際に行動できるほど具体的です。ハッピーパスだけをリリースしたせいで、途中でユーザーを置き去りにすることもありません。

ユーザー軸は、Steve Testを自分の好みの隠れ家にしないための確認です。ユーザーを名指しできない。その瞬間を名指しできない。リリースされる面がその人をどう尊重し、強くするのかを説明できない。そうであれば、私はテストを適用したのではありません。そう主張しただけです。

二重テスト：JiroにSteveを足す

この原則全体には、1つではなく2つのテストが必要です。¹ どちらか一方でも落ちるものはリリースしません。

Jiro Testは、これは正しく作られているか？と問います。証拠が必要です。エッジケースが扱われていること。見えない細部が仕上がっていること。主張が具体的な証拠を引用していること。曖昧さは許されません。そう思うは証拠ではありません。テストは通る。回帰はない。証拠ゲートは、コード報告やエージェント出力に対して私が実行するJiro Testの版であり、Jiroの品質哲学はそのより深い解説です。

Steve Testは、その仕事は存在に値するか？と問います。存在価値が必要です。全体との一貫性。目に見える視点。表面をきれいに保つために行った、名指しされた拒否または削除。読者が識別できる喜びや明瞭さの仕組み。曖昧に語るだけのものではありません。自分の名前を背負えることです。

裁定は単純です。Jiroで不合格なら、止めて直します。正しくない仕事はリリースしません。Jiroの拒否権は絶対です。Jiroが通ってSteveが落ちたら、作り直します。正しいが存在に値しない仕事もリリースしません。両方落ちるなら、問題は上流にあります。依頼、問題設定、スコープのどこかです。両方を通った仕事だけが、リリース候補になります。

多くのリリース文化は、この2つのうち片方だけを静かに実行しています。エンジニアリング主導の文化では、強いJiroと弱いSteveになりがちです。テストが通ればプロダクトはリリースされ、存在価値は誰か別の部署の仕事になります。デザイン主導の文化では、強いSteveと弱いJiroになることがあります。見た目が正しければプロダクトはリリースされ、正しさは運用上の問題になります。どちらの失敗モードも、見覚えのある成果物を生みます。美しいだけのまやかし。正しいが魂のない仕事。見たことがあるはずです。出したことさえあるかもしれません。

2つのテストは隣り合っています。

全体験：すべてに責任を持つ

Steve Testは、成果物を単体では判定しません。ユーザーが出会う体験全体の一部として判定します。

冒頭の翻訳事故は、最近の最もわかりやすい例です。罠の形を示しているので、具体的な失敗メカニズムをはっきり書く価値があります。Claudeのサブプロセスがレート制限に当たったとき、パイプラインのフォールバック機構は英語の原文をD1へ書き込みました。D1ライターは、それがバイト列だったので受け入れました。チェックポイント更新処理は、保存済みコンテンツをハッシュ化し、そのハッシュをディスクに書き込みました。保存された「翻訳」が英語原文と同一だったため、ハッシュは完全に一致しました。同一のバイト列が同一のハッシュを生んだのです。次の--update実行では、英語原文のハッシュと保存済みハッシュが比較され、等しいと判定され、そのバッチは未変更とマークされました。各コンポーネントは、単体では自分のJiro Testに通っていました。欠陥が存在していたのは組み合わせの側です。人間がページを開くまでの数時間、ユーザーには6ロケールで言語が混ざった文章が見えていました。

「全体験に責任を持つ」がルールです。プロダクトの振る舞い、UXフロー、言語、データの真実性、サポートシステム、パッケージング、ドキュメントの正確性、プロンプト、ルール、メモリ、スキル、フック、スクリプト、オーケストレーション、出力構造。すべてです。直近にリリースした成果物だけではありません。全体の整合性を損なうなら、局所的な勝利は受け入れられません。Steve Testは、ある面が局所的には通っていても、ユーザー体験全体が通っていないときに作動します。

削除：足すだけのSteve層は偽物です

Steve Testが生むものの中で、最も役に立つのは削除です。

何も取り除かずに終わるレビューは、実際には走っていません。現実の複雑さを持つ面に対してその仕事は存在に値するか？と問うと、ほとんどの場合、存在を正当化できないスコープ、コピー、機能、またはアフォーダンスが少なくとも1つ見つかります。そうしたものを1つも見つけないレビューは、たいていレビューを実践しているのではなく、レビューらしさを演じています。

Steve Testが具体的に探すものは、次のようなものです。

• そこにある理由が、存在に値するからではなく、入れておくと安全に感じたからである面。
• 本当の主張をしなければならなくなるため、曖昧に逃げているコピー。
• 以前の版から引き継がれているが、現在の約束にはもう役立っていない機能。
• 現在のスコープでは実際には起きないエッジケースに対応するため追加されたアフォーダンス。
• 作り手が下すべき決定をユーザーへ押しつける設定項目。
• プロダクトがもう行っていない振る舞いを説明しているドキュメント。
• 削除すべきコードを覆っているテスト。

削除は、美意識と蓄積を分ける行為です。存在に値する面は、誰も問いを投げなければリリースしていたであろう版より小さくなります。リリース済みプロダクトから何かを取り除いて後悔したことはありません。残してしまったものを後悔したことは、何度もあります。

主要な行為としての拒否

削除に関連し、さらに強いことがあります。Steve Testは、何かが作られた後ではなく、作られる前に作動することがよくあります。美意識の主要な行為は拒否です。つまり、そのものをまったく作らないという決定です。

ここで重要なSteve Jobsの言葉は、2006年のAppleのプロダクト規律に関するBusinessWeekのカバーストーリーで報じられた、「私たちがやらないことについても、やることと同じくらい誇りに思っている」です。⁵ この言葉がよく引用されるのは、特定の技術的な意味で真実だからです。リリースされたすべてのプロダクトの周りには、リリースを拒んだプロダクトの見えない輪郭があります。その輪郭こそが、本当の視点です。バックログではなく、人間が決めたことの証拠です。

blakecrosley.comにとって、スタックは私が何を刈り込んだかの記録です。Reactを検討し、採用しませんでした。Tailwindを検討し、採用しませんでした。再構築の最初の2週間、バンドラーは候補にありましたが、切りました。リポジトリのどこにもnode_modules/がないことは、単なるデザイン上の選択ではありません。デフォルトツールの引力に対して、時間をかけて維持している拒否です。これらの拒否は、どんな採用よりも仕事の形を決めます。私がどの基準を守るつもりだったのかを定義します。

ResumeGeniでは、検証結果は明確でした。340件のメール登録、12件の直接問い合わせ、早期アクセスに対する3件の自発的な支払い申し出がありました。⁶ その需要が浮かび上がらせたバックログは大きいものでした。テンプレート、チーム共同作業、分析ダッシュボード、LinkedIn連携、Indeed連携、バージョン履歴、複数のエクスポート形式、モバイルアプリ。最初にリリースする版では、そのすべてを拒みました。譲れなかったものは、正確な解析、正直なギャップ評価、求人票に合う具体的な書き換え、Wordで正しく開くエクスポート、脆弱な状況にいるユーザーが安心できるフローです。拒んだものは永遠に消えたわけではありません。存在に値する最初の面を出した先で待っています。

何も拒まない面には、視点がありません。チームが何も拒まなかったなら、スコープが間違っています。

まやかしを早く見抜く。まず自分に対して

拒否と削除が機能するには、偽の成功が現れたときに、テストがそれを実際に名指しできなければなりません。Steve Testは、次のものに対して、すばやく「それはまやかしだ」と言えなければなりません。

• 偽の進捗。 進んでいるように見えて、何も生まない動き。
• 汚染された証拠。 間違った理由で通るテスト。本当だったことではなく、証明したかったことを証明する統計。
• 見栄のためのカウント。 コミット数、リリース済み成果物数、ベロシティチャート。すべて存在していても、本質から外れています。
• 一貫しないシステム。 単体ではきれいにリリースされ、組み合わさると互いを劣化させるシステム。上の翻訳事故はその1つです。
• 「すべて順調です」というレポート。 誰も下していない決定を覆い隠すもの。Steve Testは、こうした報告の敵です。
• 低価値な機械活動。 コンピューターができるから行う仕事であり、出力が存在に値するからではない仕事。

最も難しく、最も一貫して役に立つルールはこれです。まず自分の出力をまやかしだと言い切ること。 このエッセイ冒頭の翻訳事故は、まさにそれです。パイプラインは成功を報告しました。ログはきれいでした。私が仕込んだすべての指標は通っていました。その仕事はまやかしであり、ユーザーがそう判断する前に、自分でそう呼ぶ必要がありました。自分の仕事に対してまやかしを見逃さない規律こそが、テストを正直に保ちます。礼儀正しさは真実から身を守る盾ではありません。多忙さは価値の代替ではありません。

サーフェスの勾配：合格基準を調整する

Steve Testは、1つのしきい値を持つ単発の合否判定ではありません。取り戻しにくいサーフェスほど、合格基準は厳しくなければなりません。²

テストの問いは同じです。求められる答えの厳しさは、影響範囲に応じて変わります。チャットの返信は次のターンで直せます。大きな問題にはなりません。Steve Testに落ちる本番公開は、獲得に何か月もかかったユーザーの信頼を燃やし、修正コストは最初のリリース判断で節約した時間を上回ります。

実務上の帰結は、取り戻しにくいサーフェスほどリリースペースを遅くするべきだということです。取り戻しやすさが大きく異なるサーフェスに対して、一律の速度でリリースするチームは、テストの厳しさが変わると思っていないことを自ら示しています。たいていの場合、そのチームはすでにテストを実行しなくなっています。

美意識は気性ではありません

Steve Testには、もう1つ必要な区別があります。これが最もよく失われる区別です。Steveを持ち出すということは、彼の美意識を持ち出すことであり、気性を持ち出すことではありません。

この原則は、次のものを明確に禁じています。³

• 残酷さ。
• 屈辱を与えること。
• 見せ物としての軽蔑。
• ビジョナリーごっこ。
• 判断の代用品としての攻撃性。
• 恨みの芝居。
• 基準と取り違えられたドラマ。

Steveの層が実際に動いているサインは、静かな拒否です。「いいえ、この仕事はまだ存在に値しません」と判定として伝え、その後に具体的な修正行動を示すことです。演技ではありません。存在に値しない版を作った人、しばしば自分自身を辱めることではありません。チームへの軽蔑を見せることでもありません。自分の基準が高いと宣伝することでもありません。仕事が基準を越えるか、越えないか。それだけです。基準とは、厳しそうに見える美学ではありません。

この区別が重要なのは、戯画化されたSteve Jobs像が気性を中心にしているからです。Steveを演じる人に管理されたことがあるなら、意味はわかるはずです。残酷さは仕事をよくしません。職場を悪くします。そして判断の代わりに芝居を置くため、リリースされる仕事も悪くします。

Steveの美意識の層にいるのか、それともSteveの気性を演じているだけなのかを見分ける実用的なテストは、テストの出力が具体的な技術的行動になるかどうかです。「その仕事は存在に値しない」は結論ではありません。問いの始まりです。答えは、落ちた軸、修正行動、次のテストを名指ししなければなりません。レビューが「この仕事は悪い」で終わり、何があれば存在に値するのかを名指ししないなら、そのレビューは演技でした。

作り直し上限と、停滞を防ぐ条項

停止ルールのない高い基準は、回避になります。私は、すべての非自明な仕事に対して、誠実な作り直しは3回までという上限を適用しています。

誠実な試行とは、失敗した軸を特定し、具体的な修正行動を名指しし、アプローチを実質的に変え、両方のテストで再評価することです。同じ磨き込みを3回繰り返しても、3回の試行にはなりません。それは、1回の失敗した試行を3回繰り返しただけです。

3回の誠実な作り直しを経ても存在に値する仕事にならないなら、問題はほとんどの場合、技量ではありません。問題は上流、つまり問題設定、スコープ、依頼、またはチーム構成にあります。サーフェスを作り直すのをやめ、前提を見てください。約束が、現実的に基準を保てるスコープに対して大きすぎたのかもしれません。検証が思っていたより弱かったのかもしれません。そもそもプロダクトの問題ではないのかもしれません。

作り直し上限は、反対方向の2つの失敗モードを同時に解きます。弱い仕事に祝福を与えることを拒み、同時に、磨き込みが隠れ場所になるのを止めます。リリースを拒むこと自体に、もともと徳があるわけではありません。 完璧を追って際限なく作り直すことも、それ自体が失敗モードです。勇気のない職人技です。目標は完璧ではありません。目標は、存在に値し、リリースされていることです。純粋だが永遠に保留ではありません。

同じサーフェスの4回目の作り直しに入っているなら、プロダクト作りをやめて、そのプロジェクトを隠れ場所にし始めています。

観測できる兆候：本当にテストを実行したのか？

Steve Testは、主張するのは簡単で、実際に実行するのは難しいものです。規律は、テストが何を生んだのかを具体的に述べることです。

非自明な仕事を完了と呼ぶ前に、私は次のすべてに答えられることを確認します。⁴

1. ユーザーは誰か？ ペルソナの類型ではありません。現実の状況にいる現実の人です。
2. このサーフェスはどんな視点を持っているか？ 名指しできないなら、視点はありません。あるのはバックログだけです。
3. これをきれいに保つために、何を拒み、何を取り除いたか？ 削除は、テストが実行された証拠です。
4. これは全体験にどう役立つか？ その一片は、他のすべての一片と一貫していなければなりません。全体を劣化させる局所的な勝利は、勝利ではありません。
5. これが健全であることをどんな証拠が示しているか？ Jiro軸です。検証が実行され、主張が支えられています。
6. なぜ存在に値するのか？ 平明に述べます。答えが曖昧なら、テストは実行されていません。
7. 私はためらわずに自分の名前を出せるか？ 美意識の最終判断です。判断が不確かなとき、この基準群の中で最上位になる問いです。

7つすべてに具体的に答えられないなら、私は原則を適用したのではなく、唱えただけです。その仕事を差し戻します。

実例：実際のサーフェスに7つの兆候を当てる

ここでは、翻訳事故の後にリリースした具体的なサーフェスに、この兆候を当てます。翻訳パイプラインに書いた同時実行ガードです。別の翻訳プロセスがすでに動いている場合、guide_bootstrap.pyまたはblog_translate_batch.pyの開始を拒む、Python約100行のコードです。

1. ユーザーは誰か？ 2週間後に翻訳実行を始める私です。そのとき私は、6ロケールを壊した正確なレート制限の失敗モードを忘れているでしょう。将来の作業回で、どちらかのスクリプトを呼び出す任意のエージェントもユーザーです。
2. そのサーフェスはどんな視点を持っているか？ 同時翻訳実行は、決して正しいツールではありません。このガードは、その判定をコードに埋め込み、次の呼び出し元が覚えていなくてもよいようにします。
3. きれいに保つために、何を拒み、何を取り除いたか？ ガードを警告にすることを拒みました。--forceのような短く便利なオーバーライドフラグを与えることを拒みました。唯一のオーバーライドは環境変数I18N_ALLOW_CONCURRENT=1であり、偶然タイプするには十分に長いものです。
4. 全体験にどう役立つか？ 翻訳パイプライン、D1ライター、フォールバック機構は、それぞれ単体では正しいものです。このガードは、それらが組み合わさって静かに破損する全体になるのを防ぐ一片です。
5. 健全であることをどんな証拠が示しているか？ 2つの手動チェックでガードを検証しました。1つ目は、他の翻訳ジョブが走っていないときに正常終了すること。2つ目は、実際のguide_bootstrap.pyサブプロセスが生きているときに非ゼロで終了すること。どちらのチェックも、モックではなく実際のスクリプトに対して実行しました。
6. なぜ存在に値するのか？ 6ロケールを壊した同じ同時実行レースは、このガードがある間、混在言語のD1行を生めません。すべての場合を防ぐものではありません。この原則が学習した特定の失敗モードに対する防止策です。
7. 私はこれに自分の名前を出せるか？ はい。1つの仕事、明確なオーバーライドの意味づけ、そして将来の作業回がこのガードの存在理由を引き継げるようにしたメモリ記録があります。

この実例の要点は、それぞれの兆候に具体的な答えがあることです。答えを出せないなら、テストはまだ走っていません。

対照的に、失敗はどう見えるでしょうか。同時実行ガードを下書きしたとき、兆候3に対する最初の答えは、「過剰設計を拒みました」でした。この文は、よさそうに聞こえて何も言っていない種類の答えです。過剰設計を拒んだと言っても、検討して却下した具体的なものは何も名指しされていません。それは態度であり、拒否ではありません。私は自分に本当の答えを書かせました。ガードを警告にすることを拒んだ。便利なオーバーライドフラグ名を拒んだ。プロセス一覧を取得できないときにガードがフェイルオープンする振る舞いを拒んだ。それらは決定です。最初の版は原則を演じていただけでした。

要点

創業者とソロビルダーへ： - どのサーフェスを存在に値すると呼ぶ前にも、現実の瞬間にいる現実のユーザーを名指ししてください。抽象的な存在価値は使えません。 - リリースされたすべてのサーフェスには、少なくとも1つ、見える拒否があるべきです。何も取り除いていないなら、スコープが間違っています。 - サーフェスの勾配を適用してください。本番公開には下書きより厳しい合格基準が必要です。マーケティング上の主張には、最も厳しい合格基準が必要です。

プロダクトリーダーとPMへ： - Steve Testが本当に動いているかどうかは、リリースサイクルごとの拒否と削除を数えて測ってください。ゼロなら危険信号です。 - 自分のレビューチェックリストで、「動く」と「存在に値する」を分けてください。独立した軸として扱います。 - 作り直しの予算を守ってください。誠実な試行は3回まで。その後はエスカレーションです。完璧主義を隠れ場所にしてはいけません。締切の圧力でテストを殺してもいけません。

エンジニアリングリードへ： - チームがリリースするすべてのサーフェスについて、Jiro側の基準とSteve側の基準を名付けてください。どちらも通る必要があります。 - 見えない細部に投資してください。正しいだけのものと存在に値するものの差は、たいてい接合部に宿ります。 - 気性を拒んでください。静かな拒否がサインです。厳しさの演技は失敗モードです。

デザイナーへ： - 視点は装飾ではありません。プロダクトを認識可能にする仕組みです。 - 存在に値するサーフェスは、ものを拒みます。見える形で拒みます。何を切ったのかを名指しすることも仕事の一部です。 - 曖昧なときの実用的なテストはこれです。その決定に、ためらわず自分の名前を出せますか？

終わりに：これに自分の名前を出せるか？

プロダクトで最上位に置くべき問いは、その仕事は存在に値するか？です。判断が不確かなときに最上位になる問いは、この基準群の中で最も単純なものです。

これに、ためらわず自分の名前を出せるか？

答えがyesなら、その仕事はリリース候補です。答えが「まだ。ただし3回以内の誠実な作り直しで届く」なら、作業を続けます。答えがnoであり、3回の誠実な試行の後もnoのままなら、サーフェスではなく依頼を作り直します。

私はこのテストを毎回実行します。コードに対して。コピーに対して。コミットメッセージに対して。ドキュメントに対して。プロダクトサーフェスに対して。このエッセイに対して。

このエッセイでは、下書き開始時には必要だと思っていた3つのセクションを切りました。Jobsについての長い伝記的セクション、「宇宙にへこみを作る」という言葉の入門、そしてこの原則が抽象概念ではなく実在の人物の名前を使う理由の擁護です。どれも、私が書いていたユーザーには役立ちませんでした。そのユーザーとは、自信を持てないサーフェスをリリースすべきかどうか判断しようとしている作り手です。削除によって、この文章は小さく、より正直になりました。そして冒頭の翻訳失敗は、修正以外に1つの恒久的な成果物を生みました。別の翻訳ジョブがすでに走っている場合、翻訳パイプラインが開始を拒む同時実行ガードです。拒否された仕事が、ルールの変更を生みました。この原則は学習しました。

Steveは合格です。Jiroも合格です。リリースします。

FAQ

Steve Testとは何ですか？

Steve Testは、ある仕事が、現実の瞬間にいる現実のユーザーにとって存在に値するかを問うものです。Jiroの品質哲学の隣に置かれます。Jiroは正しさ、証拠、エッジケースを確認します。Steveは存在価値、一貫性、拒否、美意識を確認します。

Steve TestはJiro Testとどう違いますか？

Jiroは、その仕事が正しく作られているかを問います。Steveは、正しい仕事をそもそもリリースすべきかを問います。機能はテストに通っても、ユーザー、プロダクト、またはサーフェスの背後にある視点を裏切ることがあります。

チームはいつSteve Testを実行すべきですか？

取り戻しにくいサーフェスをリリースする前に実行してください。公開デプロイ、マーケティング上の主張、オンボーディングフロー、料金ページ、ドキュメント、ユーザーの信頼を形作るプロダクト機能です。軽い仕事には緩やかな基準を使えますが、公開サーフェスには厳しい基準が必要です。

テストは何を生むべきですか？

テストは、具体的な決定を生むべきです。リリース、作り直し、削除、または拒否です。本当に合格したなら、ユーザー、瞬間、視点、証拠、そして全体を守るためにチームが取り除いたものを少なくとも1つ名指しできます。

Steve Testは完璧主義になり得ますか？

はい。だからこの原則には作り直し上限が必要です。誠実な作り直しは3回で十分です。それ以降、問題はたいてい依頼、スコープ、チーム、または前提の側にあります。

レビューテンプレート

これをスクラッチパッド、PRの説明、Notionページ、またはコミットメッセージの先頭に貼り付けてください。非自明な仕事を完了と宣言する前に埋めます。どこかの行に具体的なものを答えられないなら、テストはまだ走っていません。

Steve Test: Review Record

User:          [real person in a real situation, not a persona archetype]
Moment:        [the specific moment the user encounters the work]
Point of view: [what this surface asserts; what it refuses to do]
Refusal:       [what I considered and cut, or declined to build at all]
Whole-widget:  [how this coheres with every adjacent piece of the product]
Evidence:      [Jiro axis: verification ran; specific proof the claim is supported]
Worthy verdict:[yes / no / not yet within N defined rebuilds]
Signature:     [would I sign my name to this without flinching? if no, stop]

このテンプレートの仕事は1つだけです。テストする人に、すべての行で具体的な答えを出させることです。曖昧な答えは基準を越えません。「過剰設計を拒みました」は拒否ではありません。「便利なオーバーライドフラグとフェイルオープンの経路を拒みました」は拒否です。「ユーザーに役立ちます」は全体験への答えではありません。「前回の事故を引き起こした、特定の組み合わせ上の穴を閉じます」は答えです。ある行が具体化に抵抗するなら、その仕事はまだ準備できていません。その抵抗こそが、作り直しの行き先をテストが教えているということです。

このテンプレートは、このエッセイの運用上の成果物です。このページの他のすべては、なぜ各行が存在するのかを説明するためのものです。

参照