はじめに

これまで、データ分析・機械学習などの知識を重点的に学んできたので、BI周りはかなり疎かになっていました。今の知識のままではBI案件のお手伝いが大変だなと思ったので、少しはリソースを割いて勉強していこうと思います。今回はコードも何も出てこない内容なので、データサイエンティストの方はそっ閉じで良いと思います。
海外のブログで、“12 Best Business Intelligence Books To Get You Off the Ground With BI”という記事があり、”Performance Dashboards: Measuring, Monitoring, and Managing Your Business (English Edition)“という書籍が紹介されていました。それについてわかりやすくまとめられたスライドがあったので、2006年と古いですが、何もBIを知らないものとしては非常に勉強になると思い、訳して自分のための忘備録としておきます。

目次

・パフォーマンスダッシュボード
・ダッシュボードの不満
・パフォーマンスダッシュボードの２つの原則
・戦術的なドライバー
・戦略的なドライバー
・パフォーマンスダッシュボードは何で構成されるか
・おわりに

パフォーマンスダッシュボード

• ダッシュボード
• パフォーマンスチャート
  からなる

ダッシュボードの不満

意思決定を阻害するもの

• データが多すぎる
• 情報が少なすぎる
• 届くのが遅すぎる

パフォーマンスダッシュボードの２つの原則

パフォーマンスダッシュボード = BI + 企業の経営マネジメント

（画像はPDFより拝借しております。）

• 1.BI
  • 情報（DWH）
  • 知識（分析ツール）
  • 計画（ルール、モデル）
  • 行動（レビュー、計測、洗練）
  • 知恵
  • イベント発生→情報へ
    の繰り返し
• 2.企業の経営マネジメント
  • 戦略（ミッション、バリュー、ゴール、目的、インセンティブ、戦略マップ）
  • 計画（予算、計画、見込み、モデル、イニシアティブ、ターゲット）
  • モニタリング、分析（パフォーマンスダッシュボード）
  • 行動、調整（行動、決定、見直し）

戦術的なドライバー

• 利用者と共鳴する
  • 一つのスクリーンでいくつかの領域のステータスをモニタリングできる
  • 重要な指標のグラフ表示
  • 例外的な状況に関してアラートを上げる
  • クリックして分析し、詳細を深掘りできる
  • ルールに基づきカスタマイズされた表示
  • 訓練が要求されない
• リッチなデータ
  • 複数の情報ソースからブレンドされたデータ
  • 詳細も集計値もある
  • 履歴もリアルタイムのデータもある
• 労働者に力を与える
  • 本当に重要なことにユーザーを集中させる
  • 労働者の貢献がどのように集計されているかを示す
  • ゴール、競争、インセンティブで動機づけをする
  • プロアクティブな介入を促進する

戦略的なドライバー

• ビジネスを調整する
  • 皆同じデータを使う
  • 皆同じ指標を使う
  • みな同じ戦略で働く
• コミュニケーションの改善
  • コミュニケーション戦略のためのツール
  • マネジャーとスタッフのコラボレーション
  • 部門間のコーディネート
• 視認性とコンプライアンスの向上
  • 驚きの少なさ
• 戦略的なドライバーの5つのC
  • Communicate
  • Compare
  • Collaborate
  • Coordinate
  • Congratulate

パフォーマンスダッシュボードは何で構成されるか

• 3つのアプリケーション
• 情報の3つのレイヤー
• パフォーマンスダッシュボードの3つのタイプ

3つのアプリケーション

• モニタリング
• 分析　
• コラボレーション

（画像はPDFより拝借しております。）

情報の3つのレイヤー

（画像はPDFより拝借しております。）

• モニタリング：グラフ、図形、チャート
• 分析：ディメンション、階層、細かく分割
• レポーティング：DWHのクエリ実行、運用レポート
• これらをプランニングする
  　・計画、モデル、予測、更新

ダッシュボード

　　・目的：現在の活動状況を測る
　　・ユーザー：経営者層、マネジャー、スタッフ
　　・更新頻度：即時
　　・データ：イベント
　　・クエリ：リモートシステムで実行
　　・画面：チャート

スコアカード

　　・目的：進行状況を示す
　　・ユーザー：経営者層、マネジャー、スタッフ
　　・更新頻度：周期的なスナップショット
　　・データ：サマリー
　　・クエリ：ローカル環境のデータマートで実行
　　・画面：図形

・経験則
　・ビジネスユーザーが好むものは何でも使う！

パフォーマンスダッシュボードの3つのタイプ

• 業務系
  • 焦点：モニタリング業務
  • 重点：モニタリング
  • ユーザー：管理者
  • スコープ：現場
  • 情報：詳細
  • 更新頻度：日中
  • 適しているのは：ダッシュボード
• 戦術系
  • 焦点：プロセスの最適化
  • 重点：分析
  • ユーザー：マネジャー
  • スコープ：部門
  • 情報：詳細/サマリー
  • 更新頻度：日次/週次
  • 適しているのは：BIポータル
• 戦略系
  • 焦点：戦略実行
  • 重点：コラボレーション
  • ユーザー：経営者層
  • スコープ：企業
  • 情報：サマリー
  • 更新頻度：月次/四半期
  • 適しているのは：スコアカード

パフォーマンスダッシュボードをどのように作るか？

3つのアーキテクチャー

・ビジネスアーキテクチャーとテクニカルアーキテクチャー
・BIアーキテクチャー
・データアーキテクチャー

ビジネスアーキテクチャー

• ステークホルダー：投資家、取締役、全従業員、顧客、サプライヤー、監督機関
• 戦略：ミッション、ビジョン、バリュー、ゴール、目的、戦略マップ
• 戦術：資産、人員、知識、計画、プロセス、プロジェクト
• 意味：用語、定義、ルール、メタデータ、教育、ガバナンス
• 指標：先行、遅行、兆候

テクニカルアーキテクチャー（パフォーマンスダッシュボードに直接つながるところ）

• ディスプレイ：ダッシュボード、BIポータル、スコアカード
• アプリケーション：モニタリング、分析、マネジメント
• データソース：スプレッドシート、メモリーキャッシュ、DWH、データマート、レポート、ドキュメント
• 統合：カスタムAPI、EAI（Enterprise Application Integration）、EII（Enterprise Information Integration）、クエリ実行、ETL、手動
• データソース：レガシーシステム、パッケージのアプリ、Webページ、ファイル、サーベイ、テキスト

BIアーキテクチャー

（画像はPDFより拝借しております。）

ビジネスアーキテクチャー

・統合BI能力
　・モニタリングレイヤー
　・分析レイヤー
　・レポーティングレイヤー
　・プランニングレイヤー
・BIプラットフォーム（分析サーバ）
　・共通のサービス、モデル、API、ファイル形式
・データデリバリーアーキテクチャー

データアーキテクチャー

Quicken Loans（アメリカの金融業者）の例

（画像はPDFより拝借しております。）

• 企業内のソフトウェアのデータを統合し、Web経由で2日分のデータを蓄積（Real-time Store）→業務系、戦術系のダッシュボードに利用
• Real-time Storeのデータを整形して、2ヶ月分のデータを蓄積（Operational Data Store）
• Operational Data Storeから2週間分のデータを蓄積したものを100件ほど保持する（OLAP（online analytical processing） Cubes）→業務系、戦術系のダッシュボードに利用
• Operational Data Storeのデータを整形して、7年分のデータを蓄積（Data Warehouse）
• Data Warehouseのから7年分のデータを蓄積したものを250件ほど保持する（OLAP Cubes）→レポーティングや分析ツールに利用

データアーキテクチャにはいろいろあるようです。

Direct Queryアーキテクチャー

スクリーンの要素が個々のクエリに直接的にリンクしている

• 良い点：
  • すばやくデプロイできる
  • 低コスト
• 悪い点：
  • 浅く、ドリルダウンが制限される
  • ディメンションがない
  • ハードウェア組み込みクエリ

Query and Cacheアーキテクチャー

クエリがクエリ化可能なキャッシュとともに置かれている（In-memory or disk cache）

• 良い点：
  • すばやくデプロイできる
  • レスポンスが速い
  • ナビゲーションが速い
• 悪い点：
  • 静的なデータセットに縛られる

BIセマンティックレイヤー

BIツールがユーザーのためにビジネス用語で表現したクエリオブジェクトを提供

• 良い点：
  • 抽象的なクエリオブジェクト
  • ディメンションで分けられたビュー
• 悪い点：
  • 一般的なODBCコネクション
  • 主にDWHのヒストリカルデータ

Federated Queryアーキテクチャー

EII（Enterprise Information Integration）ツールが、スクリーンの要素と合うように複数のソースからクエリ化する

• 良い点：
  • 複数のソース
  • セマンティックレイヤー抽出
  • デプロイが素早い
  • プロトタイプ
• 悪い点：
  • 履歴がない
  • データの質の問題
  • 複雑性

データマートアーキテクチャー

ダッシュボードがバッチで読み込まれた永続的なデータマートに対してクエリを実行する

• 良い点：
  • 複数のソース
  • ディメンショナルモデル
  • ヒストリカルコンテキスト
  • 素早く複雑なクエリ
• 悪い点：
  • 即時性がない
  • 統合されていない？

Event-drivenアーキテクチャー

• インプット：DWHや業務系システム
  ↓
• 業務系ダッシュボード：データの把握、データの集計、指標のマネジメント、イベントの検知、ルールの適用、作用/トリガー
  ↓
• アウトプット：アラート、トリガー（ワークフローエンジン）、SQL/Stored Procedures（業務系システム）

おわりに

BIダッシュボードを作成する際の洗い出しが面倒だと思っていたので、この資料で良い初期値を手に入れられました。これまでの分析業務はビジネスの一部を切り取って、疎結合なものを多く扱ってきたと思います。あるイベントの効果検証とか、ある対象の予測などです。この資料を読んで、組織の戦略などと密に絡み合い、様々な関係者の目的を成し遂げるようなBIダッシュボード作成において、組織間の調整力が強く求められるのかなと思いました。そこにデータサイエンティストの持つスキルはどうフィットするのだろうか？と思いつつ、どうやってサイエンス要素をバリューが出る形で盛り込んでやろうかと考えています。

参考情報

[1]Wayne W. Eckerson(2006). “Performance Dashboards:Measuring, Monitoring, and Managing Your Business”
[2]Sandra Durcevic(2019). “12 Best Business Intelligence Books To Get You Off the Ground With BI”, The datapine Blog

今日は午後から有給をいただいて、ABEJA SIXの1日目に行ってきました。印象的だなと感じたものに関して、つらつらと雑記を載せておきたいと思います。

こちらは品川グランドプリンスホテルの庭園です。

こちらは会場の雰囲気です。

ブースの様子1です。

ブースの様子2です。

ABEJA SIX 2019

「食事画像認識モデル開発プロジェクトでの10個5個の教訓」 株式会社FiNC Technologies 南野 充則 氏

• FiNCは450万ダウンロードされているヘルスケア系のアプリを開発している会社。
• ユーザーの継続率を高めるための施策として、機械学習を用いている。
• 今回の紹介事例ではユーザーの食事に関する情報を入力する手間を機械学習で短縮させ、短縮させることで継続率を高めることを狙っている。
• 食事の画像は1日に数万枚がアプリに投稿される。
• 食事の画像から栄養価などを計算することを目指している。
• 食事レシピ認識モデルでは、画像からレシピを識別し、メニューの量（グラム数）なども推定し、カテゴリ単位で決まっている栄養価から推定している。レシピ本の情報を入力したり、レシピサイトをクローリングし、レシピを一人あたりの栄養価になるように標準化などもしている。きれいな画像と栄養価（材料何グラムか）の伴ったクリーンなデータセットを用意するために自社のキッチンに料理人を呼び2000レシピ分の料理を作ったとのこと。
• 食材認識モデルでは食材一つ一つ（トマト一つとか、キャベツ一枚とか）を識別して、栄養価を素材単位で計算している。
• 学習の結果、管理栄養士よりも3%程度の誤差でメニューの栄養価を推定可能になった。
• 開発期間は6ヶ月間。
• 東大の松尾研にアドバイスをもらっているらしい。

5つの教訓

• １．DL/ML人材をソフトウェアエンジニアから輩出すべき：
  インフラ、サーバー、DB、パフォーマンスなどに明るいソフトウェアエンジニアが機械学習や深層学習を学ぶと、分析も実装もできる頼もしいメンバーになるので、ソフトウェアエンジニアのデータサイエンティスト化に注力しているらしい。目指すは論文のリプリケーションができるレベルとのこと。
• 2.データ取得から学習までのPDCAを最速にする：
  ユーザーが画像を出したあとのフローをしっかりしていなかった。予期せぬデータが入ってくるので、そこへの対応も必要。アノテーションした項目を再学習するような仕組みを作り、そばの画像が苦手であれば、そばの画像を集中的に集めて学習させる。
• 3.オペレーションは自社で構築せよ：
  泥臭い仕事と思い、丸投げしてはいけない。データセットの質が最も大事。データセットの質を担保するには評価手法を理解し細かいオペレーションを作る必要がある。アルバイトも自社で雇用、マネジャーもエンジニアとすることで当事者意識も芽生えやすい。
• 4.評価方法の決定からプロジェクトを始めよう：
  AIを使えば、想像を超える何かが出てくると期待していまうフシがある。評価の仕方を決めたほうが、メンバーのゴールが見えるし。やりやすい。10%以内の誤差の難易度がどの程度なのかわからなかったりするし、解釈の多様性が生まれてしまうこともある。
• 5.プロジェクトはアジャイルで進めるべき：
  作ったことのないモデルを作る際にスケジューリングを引くことは難しい。SOTAくらいいけますよと言ってしまい、自らを苦しめることになりかねない。

「機械学習におけるクラウド活用のポイント」 アマゾン ウェブ サービス ジャパン株式会社 針原 佳貴 氏 & 宇都宮 聖子 氏

• SageMakerいいぞというお話。
• ビジネスにおいて、機械学習を進めるに際して重要なポイントは、
  「ビジネス価値に落とし込む」
  「データの流れを理解する」
  「自分の力で頑張らない」
  の3点が挙げられていた。
• 必要ではあるが、付加価値にはつながりにくい作業のことをUndifferentiated heavy liftingと呼ぶらしい。
• 機械学習プロジェクトを回す際に重要なこととして、
  データ取得
  ↓
  データ前処理
  ↓
  モデルの開発・学習
  ↓
  モデルの評価
  ↓
  モデルの変換（エッジデバイスに送るにはデータを小さくする必要がある。）
  ↓
  本番環境のデプロイ
  ↓
  監視・評価データ変換
  のループを繰り返すことが挙げられている。
• S3(Simple Storage Service)に蓄積しているデータがあったとして、そのデータに対して、SageMakerで前処理やら機械学習を行い、学習済みの結果をS3にためれば、それを用いてエンドポイントの推論としてカジュアルに活用することができる。S3→SageMaker→S3のコンボが良いとのこと。
• ここ1年間で200個くらいAWSのサービスやら機能が増えているので、それを知るだけでも大変そう。でもうまく使えば、Undifferentiated heavy liftingを避けることができる。
• わからないことがあれば、ソリューションアーキテクトに質問したり、SageMakerのSlackで聞いたりすると良いらしい。
• SageMakerでの学習の進め方としては3種類ある。１つ目は、TensorFlowなどでゴリゴリとアルゴリズムを書く。2つ目はAWS Marketplaceで販売されているアルゴリズムを時間単位で課金して使う。3つ目はAWSのビルトインのアルゴリズム（Object Detection、Semantic Segmentation、Factorization Machineなど）を使う。

「少数データからの学習法の展開とABEJAの取り組み」 株式会社ABEJA 藤本 敬介氏

• データの質がモデルの結果を左右するが、きれいなデータを大量に集めるためにアノテーションをやるのは大変。少ないデータでも性能を出したい。
• アプローチとしては、Data Augmentation、Transfer Learning、Meta learningの3つがある。

Data Augmentation（データ拡張）

• データを擬似的に増やす手法
• mixup:Beyond Empirical Risk Minimizationの研究では画像とラベルを合成してデータを水増しが行われている。
• AutoAugment:LearningAugmentation Policies from Dataの研究では、強化学習で精度が上がりやすい水増し方法を学習している。
• 使わない手はない。

Transfer Learning（転移学習）

• 異なるデータセットで学習したものを再利用する。
• Fine-tuning：別のデータで学習済みのモデルに対して、タスクに対してのデータに適用する。
• Domain Adaptation：学習済みのモデルやデータの知識を再利用する。
• Fine-tuningは有効な手段。

Meta learning

• タスクの学習のしかたを学習する
• 少数のデータでのうまい学習方法を訓練しておいて、それを使い回す。

ABEJAの取り組み

• データが少ない場合はFine-tuningで高精度を出しやすい。
• External Network：中間層の情報を利用して、例外的な処理（ネットワークにバイパスみたいなものを通す）をすることで、Fine-tuningした際に精度が落ちないようにしている。不均衡データやクラス追加に対して強い手法とされている。データ数に応じてExternal Networkのサイズを調整でき、クラス1に大量のデータがある場合、1だけネットワークを深くして、2やら3はネットワークを浅くするなどの柔軟な対応が可能。これでもって不均衡データに対応できるとのこと。また、クラス追加に関しては、追加したクラスの分だけ学習すればいいようにネットワークの学習ができるらしい。ただし、学習に時間がかかるとのこと。
• （よくわからないが）Model-Agnostic Meta-Learning（MAML（マムル））を応用したら精度が高まるらしい。

うーん、DNNは全然追いかけれていないので断片的にしかわからなかった。悔しいものです。

「Deep Learningの都市伝説と現実」 株式会社ABEJA 白川 達也氏

• リサーチャーをする上で大事なこととしては、
  1.先に見つけること
  2.シンプルに解くこと
  3.先に失敗する（大きな失敗は会社としてしないために）
  の3つがある。
• クリーンなデータで学習したほうが精度が高くなりやすく、過学習しにくい。ラベルの精度が高ければ、高いほどよい。Big Clean Data + DLで勝つる？
• アノテーションは簡単ではない。アノテーターごとにわかりやすい情報がバラバラで、ブレるのが本質的。どこまでやるのか、どこが基準なのかというフレーミングとアンカーリングが重要。人間とかタスクを理解してすすめるのが良い。
• 半教師あり学習（アノテーションされていないデータを使って精度向上させる取り組み）も魅力的だが、教師データを増やしたほうが効率的。アノテーションできるならば、アノテーションしてしまおう。事前学習も意味があるので行う。
• 次にどんな技術がくるのか？ Graph Convolution、Annotation、Poincare Embeddings、ML in Hyperbolic Space
• Taskonomyという研究が今後熱くなるかも。見たこともないタスクも解けるという柔軟性を持つモデルが構築できる？

感想

機械学習で精度を出すためにそこまで頑張るのか！という事例を聞けたり、知識として不足していたAWS系のサービスの話を聞けたり、自分の足りていない知識を補えた良いイベントだと思いました。