レビュー・プロセスの「ワークド例」とは？
レビュー・プロセスの「ワークド例」が意味するもの
レビュー・プロセスのワークド例とは、誰かが記録された入力、明示的な前提、そして再現可能な手順を使って、過去の意思決定をどのように見直すかを、完全に明示したステップごとの実演です。目的は未来を予測することではありません。あなたが何をしたのか、何が起きたのか、そしてその差がなぜ存在する可能性があるのかを検証することです。
実務上、「レビュー」とは通常、次のことを指します：（1）意思決定の状況を捉える、（2）計画した推論と条件を列挙する、（3）観測された結果を記録する、（4）ギャップを、安定している要因（あなたの手法）または変動する要因（市場の状況、コスト、執行の詳細）のいずれかで説明する。
仕組みはどう働くか（安定入力 vs 変動入力）
レビュー・プロセスは、コントロールできるメカニクスと、コントロールできない条件を分けると最も効果的です。
1) 意思決定メカニクス（安定）： どのように行動を選んだか、ポジションサイジングやリスク制限（該当する場合）をどう計算したか、そして「良い」結果と「悪い」結果の基準をどう定義したか。
2) 変わり得る入力（変動）： 市場の値動き、スプレッド／取引コスト、レイテンシや注文執行の違い、そして時間や管轄に依存していた制約。
3) エビデンス： 価格、タイムスタンプ、そして取引／注文の記録――あなた自身の記録に存在するあらゆる成果物。特定の記録がない場合は、そのギャップを埋めるのではなく、不確実性として扱うべきです。
したがって、ワークド例は最初に前提を明示すべきです。数値が例示であるならそう言ってください。ある構成要素が不明ならそう言ってください。
ワークド例（透明な数値と前提）
以下は、レビュー・プロセスのシナリオ形式のワークド例です。簡略化した「計画 vs 観測」の比較を使い、リアルタイムデータはないものとします。
前提（すべて宣言）：
- あなたは、1つの出来事をレビューしています。
- 計画したエントリー価格：1.2000。
- 計画した参照スプレッド、または推定取引コスト：0.0002。
- 計画した執行の実効価格（計画）：1.2000 + 0.0002 = 1.2002。
- 観測されたエントリー価格：1.1988（あなた自身の執行記録から）。
- 実際の取引コストは不明なので、この例では計画と同じ スプレッドモデル を仮定します。
- 数量（単位）は Q = 10,000（例示のため、スポットに近い換算を仮定）。
ステップ1：計画した「実効」エントリー値を計算（メカニクス）。
- 計画した実効エントリー = 1.2002。
ステップ2：同じコスト仮定を使って、観測した実効エントリーを計算（変動条件 + 繰り返しの仮定）。
- 観測した実効エントリー = 1.1988 + 0.0002 = 1.1990。
ステップ3：実効エントリーのギャップを比較。
- 差 = 1.1990 − 1.2002 = −0.0012。
ステップ4：簡略化したP&Lへの影響に翻訳（例示）。
- 例示のみとして、実効価格の差に数量を掛けると金銭的な差になると仮定します。
- 金銭的影響 = −0.0012 × 10,000 = −12。
ステップ5：ギャップを帰属させる（単一原因の物語を避ける）。
- ギャップの一部は、計画した参照と観測された執行の間の 市場の値動き によるものです。
- 残り（もしあれば）は コストモデリングの誤り による可能性があります（コストが同じ振る舞いをしたという、私たちの仮定）。
- 執行タイミングの違い が原因である可能性もあります（この例ではタイムスタンプが含まれていないため、ここではモデル化していません）。
完了したレビューは、「何が検証されたか（あなたの計画した数値 vs 観測された記録）」と、「何がなお不確実か（例：取引コストが本当に仮定と一致していたか。別途の観測コストデータを含めていないため）」を列挙することで終わります。
制限と失敗パターン（何がうまくいかない可能性があるか）
うまく構成されたワークド例でも、不確実性を隠してしまうと失敗し得ます。
- エビデンスの欠落： 執行のタイムスタンプや記録されたコストがない場合、重要なドライバーを「仮定で消してしまう」ことがあります。
- 非現実的なコスト仮定： 取引コスト、スプレッド、そして実効執行は、見積もりと異なり得ます。計画したコストモデルを流用すると、ギャップを誤って帰属させることになります。
- 一回限りの推論： 単一の出来事における過去の関係は、次に何が起きるかを示しません。
- 物語への過剰適合： よくある失敗は、他のもっともらしい寄与要因を無視して、好ましい要因だけで結果を説明してしまうことです。
レビュー・プロセスは、これらを「検証の限界」として扱うなら有用なままです。整合性の欠如を特定することはできますが、将来の結果について確実性を主張すべきではありません。
確認方法と次に何を聞くべきか
レビューを独立に検証するには：
- 各数値ステップが、記録された成果物か、明確に述べられた前提のどちらかに追跡可能であることを確認します。 2) 同じ前提を使って比較を再計算し、途中の値（実効エントリーのようなもの）を示します。