Compass
経営の『問い』と判断軸を揃える
Target Audience
経営企画 / 事業責任者 / 経営層
- 狙う意思決定(会議)とKPIの棚卸し
- 現場のドメイン知識を前提にした『見るべき分布』の定義
- BI/既存レポートとの役割分担の設計
- 最小パッケージ(8週間)の成功条件を合意
Factbookは、会議の共通言語を作り、
議論を『数字の確認』から『未来の創造』へ変える
組織のための学習装置です。
7Modules
10min
Pipeline Runtime
Weekly Report
FY2025 Q1
ボトルネックは『アクセス性』ではありません。『受容能力』と『共通認識』の欠如にあります。組織の9割の人材にとって、BIのダッシュボードは『探索』するには難しすぎるのです。
『売上』『会員数』『粗利』が部署ごとに違う。その結果、会議の大半が『数字の正誤確認』という不毛な時間に消えていきます。
平均値だけで判断し、『いつも通り』の裏にある異常を見落とす。ビジネスの機会もリスクも、すべては平均の向こう側に隠れています。
データはある。だが『現場の肌感』がない。外傷的な事実(数値)と、内面的な文脈(現場の物語)が分断されています。
思想・マテリアル・学習(運用)の3層で設計します。主役はデータではなく『人間の対話』であり、マテリアルはそのための道具に過ぎません。
SECIモデルを回す。データを『インストール』する。バウンダリー・オブジェクトとして共通言語を作る。
1スライド1グラフ1メッセージ。相対化(予実/前年/競合)と分布で『意味』を作る。定例で読む統計の本。
隔週×読み会で、事実→文脈→仮説を回す。失敗を責めず、問いを立てる文化を定着させる。
最初は『整えること』が勝負です。作れる形にして、数分で回るパイプラインを作り、読み会で内面化を起こします。
Start Small,
Learn Fast.
いきなり全社のデータを統合する必要はありません。
まずはひとつの重要な「問い」から始め、
7つのモジュールを必要な分だけ組み合わせて
最小のサイクルを回します。
経営の『問い』と判断軸を揃える
Target Audience
経営企画 / 事業責任者 / 経営層
データ資産・定義・品質を診断する
Target Audience
データ責任者 / 情シス / 分析チーム
DWH/基盤を『作り直す』のではなく『整える』
Target Audience
情シス / データエンジニア / ベンダー管理
計算定義書で『共通言語』を固定する
Target Audience
分析チーム / 経営企画 / 現場キーマン
再現性ある自動生成パイプラインを作る
Target Audience
データエンジニア / 分析チーム
マテリアルは主役ではない。対話を起こす道具
Target Audience
経営会議 / 事業会議 / 現場リーダー
読み会(Yomikai)でSECIを回す
Target Audience
経営企画 / 事業責任者 / 現場 / 分析チーム
BIは探索に強い道具ですが、部門横断の共通言語を作るには『別設計』が必要です。
| Dimension観点 | Generic ToolBI Tools | Our SolutionFactbook |
|---|---|---|
| Shape形 | 操作する画面 (Dashboard) | 読むための本 (Book / Slides) |
| Purpose目的 | 探索・掘り下げ (Exploration) | 共通言語化・学習ルーチン (Learning) |
| Strength強み | アドホック分析・ドリルダウン | 相対化・分布・定義の統一 |
| Weakness弱点 | 『見る人』によって解釈が割れる | 初期の設計・定義統一が重い |
Typical Success Pattern:
BIで等しく"気になった事象"を見つける → Factbookで読み直し、定義・文脈を揃えて議論する
実名非公開のリテールチェーンA社。かつて『1回の分析に1週間』かかっていた作業を、数分で回すところまで整備。以降、会議の論点は『数字の確認』から『未来の創造』へと劇的にシフトしました。
Excel / 手作業集計
Pipeline化と定義統一
学習する文化の定着
※ クライアントの機密保持のため、業態・規模・数値を特定不能な粒度に抽象化しています。
キャッチコピーではなく、エンジニアリングと運用で裏付けます。
定義統一と相対化で、 意思決定の質が上がる
仮説検証が 『会議中に回る』速度になる
自社で揃える 採用・基盤・運用のコストを圧縮
再現性・監査性・異常値の抑止を 仕組みにする
読み会で 『学習する文化』が定例化する
作って終わりではなく、貴社の中に再現性と学習ルーチンが残る形にします。
計算定義書 / 命名規則 / 例外処理 / 比較対象(相対化)の仕様書一式
集計SQLコード / 実行ジョブ設定 / レポート生成テンプレート / 差分検知等の監査機構
読み会運営ガイドライン / 役割分担(RACIチャート)/ KPT振り返りテンプレート
定例で読む統計マテリアル(スライド/レポート)。会議の共通言語として運用します。
あります。BIは『画面(ユーザーが操作する道具)』であり、Factbookは『境界対象(全員で読む共通言語)』です。BIで個々人が掘り下げた発見を、Factbookの「相対化・分布・定義統一」の枠組みで読み直すことで、組織としての解釈や打ち手が変わることが多々あります。
初期フェーズでは『海の物とも山の物とも分からない』部分が確実に出ます。また、定義の統一・基盤整備・部門横断の参加は、現場の局所最適(慣れ親しんだやり方)との摩擦を生みます。トップが『学習装置を入れる』という意思決定を持つことで、前提の揃え直しがスムーズに進みます。
理想は『会議で数字に基づいた実質的な議論ができるようになること』です。KPIの定義が揃い、議論が『数字の確認』から『次の手』へ移る。定量的な指標としては、分析リードタイム(例:1週間→数分)の短縮も分かりやすい成果となります。
現実的に、データを『落とせる形』にするまでが最も重いです。データの所在確認・品質チェック・多義性の解消(定義合わせ)により、初期構築で1人月程度かかることがあります。ただし一度Pipeline(自動化)ができると、以後の運用負荷は劇的に下がります。
出発点は問いません。Excelデータ起点で『定例の統計マテリアル』に落とすケースもあります。ただしスケール性や再現性を重視する場合は、Foundation(DWH/整流化)へ段階的に進めることを推奨します。
最小権限・環境分離(dev/stg/prod)・監査ログを基本方針として設計します。データを外部に持ち出さない運用(クライアント環境内での実行)も選択可能です。詳細はDiagnoseフェーズで要件を詰めます。
貴社のデータ環境と組織の課題感をお聞かせください。
Factbookの導入が適切か、どのモジュールから始めるべきかをご提案します。
フォームが表示されない場合はこちらから開けます。
※ 無理な営業は一切いたしません