Boundary Object for Strategy

データを「見る」から、
組織にインストールする。

Factbookは、会議の共通言語を作り、
議論を『数字の確認』から『未来の創造』へ変える
組織のための学習装置です。

15分で診断する(無料)

7Modules

10min

Pipeline Runtime

FB

Weekly Report

FY2025 Q1

Sales
Performance

KPI Definitions Aligned
Weekly Review Routine
The Bottleneck

なぜ、BIを入れても意思決定が変わらないのか?

ボトルネックは『アクセス性』ではありません。『受容能力』と『共通認識』の欠如にあります。組織の9割の人材にとって、BIのダッシュボードは『探索』するには難しすぎるのです。

01
01

定義の迷子

『売上』『会員数』『粗利』が部署ごとに違う。その結果、会議の大半が『数字の正誤確認』という不毛な時間に消えていきます。

02
02

分布の無視

平均値だけで判断し、『いつも通り』の裏にある異常を見落とす。ビジネスの機会もリスクも、すべては平均の向こう側に隠れています。

03
03

文脈の欠如

データはある。だが『現場の肌感』がない。外傷的な事実(数値)と、内面的な文脈(現場の物語)が分断されています。

Concept

Factbookは『成果物』ではなく
『学習装置』です。

思想・マテリアル・学習(運用)の3層で設計します。主役はデータではなく『人間の対話』であり、マテリアルはそのための道具に過ぎません。

1. 思想 (Philosophy)

SECIモデルを回す。データを『インストール』する。バウンダリー・オブジェクトとして共通言語を作る。

2. 具象 (Material)

1スライド1グラフ1メッセージ。相対化(予実/前年/競合)と分布で『意味』を作る。定例で読む統計の本。

3. 学習 (Learning)

隔週×読み会で、事実→文脈→仮説を回す。失敗を責めず、問いを立てる文化を定着させる。

The 7 Modules

学習装置を組み上げる

最初は『整えること』が勝負です。作れる形にして、数分で回るパイプラインを作り、読み会で内面化を起こします。

Start Small,
Learn Fast.

いきなり全社のデータを統合する必要はありません。
まずはひとつの重要な「問い」から始め、
7つのモジュールを必要な分だけ組み合わせて
最小のサイクルを回します。

MOD.01

Compass

経営の『問い』と判断軸を揃える

Target Audience

経営企画 / 事業責任者 / 経営層

  • 狙う意思決定(会議)とKPIの棚卸し
  • 現場のドメイン知識を前提にした『見るべき分布』の定義
  • BI/既存レポートとの役割分担の設計
  • 最小パッケージ(8週間)の成功条件を合意
MOD.02

Diagnose

データ資産・定義・品質を診断する

Target Audience

データ責任者 / 情シス / 分析チーム

  • データソース棚卸し(CSV/Excel/DB/ログ)
  • 多義性(言葉の定義ズレ)と欠損・単位・異常値の検出
  • 計算定義の論点整理(分母/分子/除外条件)
  • 『作れる形』にするための作業見積り
MOD.03

Foundation

DWH/基盤を『作り直す』のではなく『整える』

Target Audience

情シス / データエンジニア / ベンダー管理

  • DWH(例:BigQuery等)または既存DWHの整流化
  • 中間テーブル(Mart)設計と命名・単位ルール
  • 権限設計・監査ログ・環境分離(dev/stg/prod)
  • まずは『最小スコープ』で動かすための基盤整備
MOD.04

Blueprint

計算定義書で『共通言語』を固定する

Target Audience

分析チーム / 経営企画 / 現場キーマン

  • 指標の計算定義(分母/分子/除外/比較対象)
  • NULLや粒度(週/月/店舗/カテゴリ)の統一
  • レビュー/承認フロー(手戻りの最大原因を潰す)
  • 『1スライド1グラフ1メッセージ』の構成原則
MOD.05

Pipeline

再現性ある自動生成パイプラインを作る

Target Audience

データエンジニア / 分析チーム

  • 集計SQL/ジョブをコード管理(例:Git)
  • スライド/レポートの自動生成(テンプレート化)
  • 差分検知・異常値アラート(信頼性の担保)
  • 『数分で回る』運用のための実行設計
MOD.06

Material

マテリアルは主役ではない。対話を起こす道具

Target Audience

経営会議 / 事業会議 / 現場リーダー

  • 定例で読む『統計の本』としてのファクトブック
  • 相対化(前年差/予算/地域/競合/ベンチマーク)
  • 平均値だけでなく分布(箱ひげ/ヒストグラム/五数要約)
  • BIで掘った『気になる事象』と突き合わせ可能な構造
MOD.07

Yomikai

読み会(Yomikai)でSECIを回す

Target Audience

経営企画 / 事業責任者 / 現場 / 分析チーム

  • 隔週×4回(最小2ヶ月)からの運用設計
  • 事実→文脈→仮説の順で議論(責めない/学ぶ)
  • ドメイン知識者(現地担当・営業・バイヤー等)の同席を最重視
  • KPTで改善し、学習するルーチンを定着させる
Structural Difference

BIの『画面』と、Factbookの『境界対象』

BIは探索に強い道具ですが、部門横断の共通言語を作るには『別設計』が必要です。

Dimension観点Generic ToolBI ToolsOur SolutionFactbook
Shape操作する画面 (Dashboard)
読むための本 (Book / Slides)
Purpose目的探索・掘り下げ (Exploration)
共通言語化・学習ルーチン (Learning)
Strength強みアドホック分析・ドリルダウン
相対化・分布・定義の統一
Weakness弱点『見る人』によって解釈が割れる
初期の設計・定義統一が重い
i

Typical Success Pattern:
BIで等しく"気になった事象"を見つける → Factbookで読み直し、定義・文脈を揃えて議論する

Case Study

週次分析が『数分』になった瞬間、組織が変わった。

実名非公開のリテールチェーンA社。かつて『1回の分析に1週間』かかっていた作業を、数分で回すところまで整備。以降、会議の論点は『数字の確認』から『未来の創造』へと劇的にシフトしました。

Before

Excel / 手作業集計

  • 作成に5〜7営業日消費
  • 定義ズレによる手戻り多発
  • 会議は『数字の正・誤』確認で終わる
Turning Point

After

Pipeline化と定義統一

  • 作成は約10分(自動生成)
  • 差分が見える(相対化×分布)
  • 会議が『次の打ち手』に集中

Impact

学習する文化の定着

  • 現場キーマンの参加が増加
  • 施策の振り返りが定例化
  • 成功事例(ナレッジ)が横展開される

※ クライアントの機密保持のため、業態・規模・数値を特定不能な粒度に抽象化しています。

Value Proposition

提供価値

キャッチコピーではなく、エンジニアリングと運用で裏付けます。

うまい

定義統一と相対化で、 意思決定の質が上がる

はやい

仮説検証が 『会議中に回る』速度になる

やすい

自社で揃える 採用・基盤・運用のコストを圧縮

あんてい

再現性・監査性・異常値の抑止を 仕組みにする

あたらしい

読み会で 『学習する文化』が定例化する

Deliverables

納品物

作って終わりではなく、貴社の中に再現性と学習ルーチンが残る形にします。

1

The Blueprints

計算定義書 / 命名規則 / 例外処理 / 比較対象(相対化)の仕様書一式

2

The Pipeline

集計SQLコード / 実行ジョブ設定 / レポート生成テンプレート / 差分検知等の監査機構

3

The Playbook

読み会運営ガイドライン / 役割分担(RACIチャート)/ KPT振り返りテンプレート

4

Factbook Material

定例で読む統計マテリアル(スライド/レポート)。会議の共通言語として運用します。

FAQ

よくある質問

BIを入れている会社でも意味がありますか?

あります。BIは『画面(ユーザーが操作する道具)』であり、Factbookは『境界対象(全員で読む共通言語)』です。BIで個々人が掘り下げた発見を、Factbookの「相対化・分布・定義統一」の枠組みで読み直すことで、組織としての解釈や打ち手が変わることが多々あります。

なぜ社長(トップ)のコミットが必要になるのですか?

初期フェーズでは『海の物とも山の物とも分からない』部分が確実に出ます。また、定義の統一・基盤整備・部門横断の参加は、現場の局所最適(慣れ親しんだやり方)との摩擦を生みます。トップが『学習装置を入れる』という意思決定を持つことで、前提の揃え直しがスムーズに進みます。

最小パッケージの成果は何で測りますか?

理想は『会議で数字に基づいた実質的な議論ができるようになること』です。KPIの定義が揃い、議論が『数字の確認』から『次の手』へ移る。定量的な指標としては、分析リードタイム(例:1週間→数分)の短縮も分かりやすい成果となります。

最初のFactbookができるまで、どれくらい大変ですか?

現実的に、データを『落とせる形』にするまでが最も重いです。データの所在確認・品質チェック・多義性の解消(定義合わせ)により、初期構築で1人月程度かかることがあります。ただし一度Pipeline(自動化)ができると、以後の運用負荷は劇的に下がります。

扱うデータは何でもよい?(Excelでも?)

出発点は問いません。Excelデータ起点で『定例の統計マテリアル』に落とすケースもあります。ただしスケール性や再現性を重視する場合は、Foundation(DWH/整流化)へ段階的に進めることを推奨します。

情報セキュリティや権限はどうしますか?

最小権限・環境分離(dev/stg/prod)・監査ログを基本方針として設計します。データを外部に持ち出さない運用(クライアント環境内での実行)も選択可能です。詳細はDiagnoseフェーズで要件を詰めます。

まずは「診断」から始めませんか?

貴社のデータ環境と組織の課題感をお聞かせください。Factbookの導入が適切か、どのモジュールから始めるべきかをご提案します。

フォームが表示されない場合はこちらから開けます。

※ 無理な営業は一切いたしません