曖昧な要求からテスト可能な基準へ

仕様書は主観をテストに変える

曖昧な要求（「オンボーディングを良くしろ」「データを整理しろ」「検索機能を追加しろ」）は、完成の基準が誰にも言えないため、提供も検証もできません。仕様書（specification） は、形容詞をテストに置き換えます。誰かが測定できる形で成功基準を述べ、解決策が守らなければならない制約を定義します。

仕様書を現実的なものにする2つの要素があります：

- テスト可能な成功基準: 議論なしに合格/不合格を確認できる条件。「速い」は主観です。「200リクエスト/秒でp95応答時間が400ms未満」がテストです。「より良いオンボーディング」は主観です。「新規ユーザーの80%が初回セッション内でステップ3を完了する」がテストです。

- 明示的な制約: 解決策が従わなければならない境界線：予算、期限、触れてはならないデータ、変更してはならないシステム、満たさなければならない規制。制約は障害物ではなく、正しい答えの定義の半分です。

有用な規律です。依頼に含まれる形容詞のそれぞれについて、それを決定づける測定方法と、それを制約する条件を記述してください。テストを書けない場合、まだ依頼を十分に理解しておらず、着手する準備ができていないということです。

最初のドラフトを生成するコストが低い場合、そのドラフトが良いものかどうかを判断するのは仕様（spec）です。正確な仕様は再利用可能な判断基準です。それはすべての候補となる回答を同じ方法で評価します。

独立して検証可能なサブ問題

巨岩を、検証可能な小石に砕く

大規模な問題は、どの部分が間違っているか判断できないため、評価が困難です。分解とは、問題をそれぞれが個別に検証できるほど小さなサブ問題に構造化することです。良い分解には、2つの特性があります。

- 独立性: サブ問題は、可能な限り重複を避け、ある部分の変更が他の部分を無意識に壊さないようにします。部品が独立している場合、それらは並行して作業、テスト、さらには自動化が可能になり、失敗は拡散するのではなく局所化されます。

- 検証可能性: 各サブ問題は独自の成功テストを持ち、全体を組み立てる前に解決済みであることを確認できます。チェックできない部品は、信頼できない部品です。

適切に分解された問題は、限られた人間の判断力をどこに注ぐべきかを示します。ほとんどのサブ問題はルーティンであり、自動化システムやジュニアスタッフに任せ、そのテストに対してチェックできます。1つまたは2つが核心であり、不確実性が高く、影響が大きく、自信を持って誤りやすいものです。それらが専門家の注意を引き続けます。

偽の分解に注意してください。一見分離可能に見えるが、隠れた依存関係を持ち、「完成した」部品が機能する全体に組み立てられない場合です。分解のテストは、各部分が検証された状態ですべての部分を実際に解決したとき、元の問題が本当に解決されるかどうかです。

質問が回答の上限を決める

曖昧な問いには、自信満々な曖昧な答えが返る

ステークホルダー、データセット、あるいは自動化システムに問いかける場合であっても、問いの精度は答えの価値の上限を決定します。曖昧な問いは、派手に失敗することはありません。それは、あなたが意図していなかった問いに対して、流暢で、自信満々で、妥当に見える答えを返します。そして、その答えは完成されたように見えます。

曖昧なデータリクエストを考えてみましょう。「最高の顧客リストを抽出して」。すべての重要な単語が未定義です。「最高」の基準は何ですか：総売上、利益率、継続率、成長率、紹介数？どの期間についてですか：生涯、過去12ヶ月、今四半期？どの顧客を対象としますか：アクティブのみ、解約済みを含む、トライアルを含む？データセットは、クエリが偶然エンコードしたバージョンの問いに対して喜んで答えを返します。そして、依頼者は、それが頭の中で考えていたものだと信じて、その結果に基づいて行動します。

正確な問いは4つの要素を固定します：正確な数量またはエンティティ、対象となる母集団、時間ウィンドウ、そしてタイブレーカー（同点時の決着方法）または閾値。同じ規律は人間にも適用されます（「『最高』と言うとき、今年の最も利益率が高い顧客を意味していますか、それとも更新の可能性が高い顧客を意味していますか？」）。また、自動化システムにも適用されます。そこでは、不十分な仕様のプロンプトは、誤った問いに対する自信満々な答えを生み出します。

プロフェッショナルとしてのスキルは、答えが到着する前に曖昧さに気づくことです。なぜなら、自信満々な誤った答えは、事後的に検出するコストが高いからです。問いの精度は、事後的な修正よりも安価です。

今、あなたのレバレッジが存在する場所

最初のドラフトは安価だが、フレーミングと判断はそうではない

糸を引いてまとめましょう。ほぼすべてのものの妥当な最初のバージョンがオンデマンドで生成できる時代において、価値を持つ作業とは、自動化されたシステムがあなたに代わって実行できない作業です。それは、どの問題を解決する価値があるかを決定すること、「正解」が何を意味するかを指定すること、問題をチェック可能に分割すること、質問を正確にすること、そして返された回答が実際に仕様を満たしているかを判断することです。

曖昧なタスクでは、単一のドラフトを生成する前に、このフレーミングのチェックリストを持ち込みましょう：

- 問題: 表面に出ている症状は何ですか？根本的な問題は何ですか？間違った問題を解決することのコストはどれくらいですか？

- 成功: 「完了かつ正確」であるための検証可能な基準は何ですか？各基準が満たされているかどうかについて、2人が意見が分かれる可能性がありますか？もしそうなら、基準をより明確にしてください。

- 制約条件: 解決策が遵守すべき境界は何ですか：予算、期限、データ、システム、ルール？

- スコープ: 意図的にスコープ外とされているものは何ですか？

- 分解: これは独立した、個別に検証可能なサブ問題にどのように分解されますか？そのうち、人間の判断が最も重要となる（核心となる）のはどれですか？

- 質問: 人、データセット、またはシステムへの任意のクエリにおいて、指標、対象母集団、期間、および同点時の処理ルールは明確に定義されていますか？どのような曖昧さが、自信満々な誤った答えを返す原因になり得ますか？

- 判断: 答えが届いたとき、それが単に流暢であるだけでなく、正しいことを示すテストは何ですか？

この時代のプロフェッショナルは、初稿を最も速く生成する人ではありません。問題を適切にフレームワーク化し、良い答えが検証可能になり、誤った答えが見えなくなるようにする人です。

持ち帰るもの

覚えておくべき2つの文

あなたは、症状と問題を分離し、明示的な制約付きの検証可能な成功基準を作成し、問題を独立して検証可能な部分に分解し、自信を持って誤った答えを返さないよう質問を鋭くすることを実践しました。これら4つの動きは、1つのスキル、すなわち「フレーミング（問題の定義）」です。

間違った問題をうまく解決することは、知識労働における最も高価なミスです。なぜなら、それは成功のように見えるからです。 そして、あなたの質問の精度は、人、データセット、または自動化システムからのあらゆる回答の価値の上限を決定します。

初稿を作成することは今や安価になり、さらに安価になりつつあります。プロのレバレッジ（影響力）が生きる場所は、問題のフレーミング、仕様書の作成、そして結果の判断にあります。チェックリストを持ちましょう。より鋭い質問をしましょう。開始前に「完了」の定義をしましょう。