## What — 逆算とボトムアップの位置づけ 業界の標準はゴール逆算（トップダウン）。ただし純粋トップダウンは現場で破綻するので、実務は**トップダウン7 : ボトムアップ3のハイブリッド**で回す。 データ基盤・分析レポートの標準プロセスは、国内の解説記事を横断してもほぼ全社が同じ順番を推している。 1. **目的・KGI / KPI 定義** — ここが「ゴール」 2. 利用者・ユースケース整理 — 誰が・いつ・何を決めるために見るか 3. アウトプット設計 — ダッシュボードのワイヤーフレーム 4. データモデリング — ディメンション・ファクト・粒度 5. インジェスチョン・パイプライン設計 6. 実装 → 利用 → 改善ループ ポイントは「① ② ③ を固めてから ④ ⑤ に降りる」こと。BI 文脈の鉄板は **KGI → KPI → アクションプラン → 可視化** の順で逆算する流派。 一般的なアプリ開発には2つの流派がある。 | | Top-Down（ゴール逆算） | Bottom-Up（入り口から積む） | |---|---|---| | 進め方 | 全体像・主機能 → 詳細へ分解 | 部品・モジュール → 組み上げ | | 強み | 早い段階でユーザーに見える形が出る／要件と合わせやすい | 既存資産の再利用が効く／技術的不確実性を先に潰せる | | 弱み | 下層の技術的制約に気づくのが遅れる | 全体が見えるまでユーザーは待たされる／作って捨てが発生しやすい | | 向く場面 | プロダクト・分析系・要件が比較的明確 | 既存システム拡張・PoC・基盤ライブラリ | 第三の流派として**Middle-out**（中間のユースケースを先に固定し、そこから上下双方向に展開）も実務でよく使われる。 > [!warning] 純粋トップダウンの3つの落とし穴 > 1. **「理想のレポート」を一人で描き切ってしまう** → ② 利用者ヒアリングをモデリング前に必ず挟む。理想像はユーザーから引き出すもの。 > 2. **ソースデータの実態を見ずに設計する** → ④ モデリング前にプロファイリングを5〜10%先回りでやる。粒度・欠損・更新頻度を見ないと「そもそも作れない」が後で発覚する。これがMiddle-outの正体。 > 3. **完成形まで作ってから出す** → ペーパープロト or ダミーデータで1枚作ってユーザーに反応を取る。トップダウンの最大の強み（早期可視化）を活かす。 ## How — 分析案件に着手するときの順番 1. このレポートは「誰が・いつ・何を決めるため」に見るのか？（1行で書く） 2. その意思決定に必要な指標（KGI / KPI）を 3〜5 個 3. ワイヤーフレームを1枚（紙でも FigJam でも） 4. 必要な粒度・ディメンション 5. ソースデータの実態確認（ここで 3・4 に戻ることが多い） 6. モデリング → インジェスチョン → 実装 7. ユーザーに見せて改善 手順 5 で必ず一度上に戻る。これが純粋トップダウンとの差。「逆算するが、現実とすり合わせて再帰的に直す」が業界の本音。 > [!success] > ゴール逆算で骨格を作り、データの実態で殴り合わせる。一人で完成させない。早く見せて、早く戻る。 ## 関連 - [[開発環境]]