準備度の読み方
構成図の各ノードに付いている数字は、実装がどこまで書けたかの進捗ではありません。 その機能を「動く」と主張してよい証拠がどこまで揃っているかを表します。 数字が低いノードは、作っていないのではなく、まだ証拠が足りないと自分で申告している状態です。
段階の意味
| 範囲 | 意味 | 典型的な証拠 |
|---|---|---|
| 0% | 未実装 | 図の上だけ、または将来の範囲 |
| 5–10% | 設計・置き場だけ | 文書、ラベル、構想中のスキーマ |
| 15–25% | 部分実装。意味のあるテストなし | SQL・スクリプト・設定は存在するが、そのノードを裏づける自動検査がない |
| 30% | 実装は完成に見えるが未テスト | コード経路はある。自動テストなし。テストのない実装はここが上限 |
| 35–45% | 限定的な自動テストがある | 単体テスト、ローカルの明示ハーネス、限定的な失敗経路テスト |
| 50–60% | 範囲を限った統合品質を検査済み | 意味のある統合テスト、トレース検査、ローカルの端から端までの経路、明示的な即時失敗 |
| 65–75% | 実環境の経路と回帰検査を確認済み | 実 Snowflake / Cortex または公開配信＋その範囲での再現可能なテスト |
| 80–90% | MVP リリース品質 | 回答品質の評価、SQL・結果の正しさ、UI の端から端まで、権限と失敗経路、CI ゲート |
| 95–100% | 本番相当の信頼 | 監視された本番類似の運用、回帰の閾値、セキュリティ・費用の防護、復旧経路 |
上限を設ける理由
証拠の種類には序列があります。人が一度手で動かして確認した、は再現性がないので上限 30%。 単体テストだけでは統合の失敗を捕まえられないので約 45%。この上限があることで、 「たまたま一度動いた」ことを「完成」と書けなくなります。
代替物では本体を上げない
代わりのもの、迂回路、代理のデータ、隣接する回避策から得た証拠は、 対象そのものの準備度を上げられません。
例: マートへ直接 SQL を投げて動いても、その上流の取込層は上がりません。 ルーティングの単体テストが通っても、dbt のテストは上がりません。
迂回で動く画面に騙されない
下流の画面が別経路で答えられてしまう場合、実際に読んでいる経路を注記に明示します。
対話画面が動いていることを、dbt や Cortex が使われている証拠のように見せません。
上流を超えない
順に流れるパイプラインでは、下流のノードを上流の前提より高く採点しません。
staging が未実装なら、その先のマートがそれより高くなることはありません。
サンプルデータの扱い
外部データ源や KPI のノードをサンプルで上げる前に、必要な粒度・実体・ラベルが 本当に含まれるかを対応表で検証します。
名前が似ているだけでは足りません。値引きは販促カレンダーではなく、 供給可能量は店舗在庫ではありません。
いまの数字が意味すること
現在の構成図では、データ源のノードが 20〜35%、dbt の変換層が 65% です。 この差は品質の差ではなく、証拠の種類の差です。
| ノード | 現在 | その値である理由と、上を止めているもの |
|---|---|---|
| データ源(注文・顧客・商品) | 20–35% | 公式サンプルデータを小売の代替として参照しているためです。注文と明細はありますが、 POS・店舗在庫・販促カレンダーそのものではありません。上げるには実データへの置き換えが必要です (代替物では本体を上げない原則)。 |
| dbt staging / mart / テスト | 65% | 実 warehouse 上で build とテストが通り、静的契約の検査と回帰も揃っているため 「実環境の経路＋回帰検査」の帯に入っています。ただしその下限です。 鮮度検査・増分更新・失敗時の再実行・回答品質が未証明で、これらが上を止めています (サンプルデータであることが理由ではありません)。 |
| Cortex Agents(ベンダー機能) | 0% | 試用アカウントでは製品側の制限で到達できません。アプリ側の指揮役で代替していますが、 代替物では本体を上げないため据え置いています。代替の側は別ノードとして評価しています。 |
95〜100% を追わない理由
最上位の帯は、監視された本番類似の運用、回帰の閾値、復旧経路を要求します。 これは実際の利用者とデータを持つ運用組織でしか積めない証拠で、 このプロジェクトの範囲外です。妥協ではなく、範囲の宣言です。 そのため到達目標は 80〜90% 帯(MVP リリース品質)に置き、 そこで何が未証明として残るかを各ノートに明示しています。