• 業績は順調だがデータ(根拠)に基づく経営判断が十分でない。
• 投下した資本は計画通り回収できているか把握しずらい。
• サービス改善、新サービス提供等ユーザーメリット追及には投資判断基準が必要。
• 上記を解決するためには、ユーザー/サービス単位で原価を把握する。

コスト計算の精度が低い

ユーザ単位,細粒度のサービス単位の個別原価が不透明
サマリーデータをもとにした計算で精度不足
ラックやサーバー単位のデータを按分img{ width: 100%; }ユーザー単位・細粒度のサービス単位の個別原価が不透明
ログデータの集計が有効に生かされていない

コスト計算のルールが未整備である

明確なコストモデルが確立されていない
顧客単位のサービス設計が原価レベルで明確に行えない
いわゆる個別の原価企画が行えていない
現状のコストが細かいレベルでの積み上げでサポートされていない

必要データの収集が十分に行えない

あっても処理しきれない or ルールが無いので計算できていない

コスト計算そのものに時間がかかる

集計の多くは手作業

ベストの投資原価シミュレーションが困難

意思決定判断が細粒度までサポートされない
行った意思決定の正しさをあとから検証することが困難

ユーザー単位での原価把握を可能にするツリー構造のコスト・モデルを確立。これは、ツリー構造最上位のインパクトが下位に与える影響を見積もれるモデルで、構成コストの原価ドライバーの因果関係をモデルしたものです。各ファクターの限界コスト(マージナルコスト)を算出するもので

例えば
　・サーバーを１単位増やした場合の追加的に発生するコスト
　・どの有余サーバー・設備をどう割り当てるかの判断
また、ユーザーレイヤの追加により
　・XXというユーザーがYYという行動をした場合のコストの
算出が可能になりました。

これは、Activity Based Costing(ABC):活動原価基準管理の導入にほかなりません。ABCは従来の会計手法に比べて正確にコストを把握できる一方、情報収集などの手間が生じたり算出の仕組みが複雑になるため実現は簡単ではありませんが

• データセンターのコスト構造分析により原価計算モデルを確立できたこと
• 粒度の細かい大量データでツリー構造の関連を辿る複雑な計算をSpark*(分散処理)の圧倒的な処理性能

が可能にしました。これにより、無駄を軽減することで利幅が向上し様々は打ち手が出て更なるユーザーメリットの追及が可能となりました。

• データに基づく迅速な意思決定の実現
• 原価企画・予算・実績・レビューの原価PDCAサイクルの確立により利益率の改善
• 投資効率の向上
• 日次バッチの積み上げで月次バッチが実行でき新たな月次バッチ処理は不要に。

• Sparkは、Apache Software Foundationの登録商標です。
• 本記事に記載されている製品名などの固有名詞は、各社の商標または登録商標です。