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