データセンターの原価計算について〜「クラウド」の別側面として

要するにデータセンターの「原価計算」です。いろいろこのあたりに関わっています。複雑な計算ロジックと大量のデータを扱う必要があるので、大規模並列計算の適用が必須になり、結果として当方の出番になった、という状態。尚、実行基盤にHadoop（MapR）を利用しています。（一応予定ではSparkに移行するつもりで、開発も始まっています。）

さて、いろいろやっていて思うところがあるので、現時点での考え方をまとめておきます。機微な部分はNDAになるので書きませんし、以下は自分の「個人的な」意見であり、特定のサービサーの話をしているわけではありません。基本的にInteropで公にしゃべった話のまとめです。

■現状認識
現在、国内DCはほぼ乱立状態に近いと思われます。ここへ来て春先のAWSの値下げのインパクトもありました。今後は、より競争的なマーケットになるでしょう。退場する企業やM&Aも活発化していくでしょう。生き残りをかけて各社は「次の一手」を打っていかないとあっという間に行き詰まるの業界の共通認識のようですね。

次の一手を打つ前に当然考えなければいけないのが、「それで今、いくら儲かっているだっけ？」という判断です。投資が有限である以上、回収して利益を出していかないと企業活動は停止に追い込まれます。勿論、「採算度外視で、まずはシェア優先」という戦略もあるでしょうが、それは前提として「採算の状況が正確にわかっている上での無視」が基本です。"わかった上での無視"と"わからないので無視"では意味が全然違う。

実は日本のDCはほとんどの場合、後者に近いのが現状です。要するに「いくら儲かっているだっけ？」が正確に把握できていない。いや、勿論簡単などんぶり勘定無敵のエクセルワークシートはありますが、それ以上のものはほとんどないでしょう。これは、サービサーの当事者に問題があるだけではなく、背景にある制度会計にも問題があります。この種のCostingを問題にしている人は中には多数いるとは思いますが、まず打つ手がないはずです。

■現状の「ざっくり原価計算」
DCビジネスは投資中心のビジネスです。従って、儲かっている＝投資回収ができている、のスキームです。この回収計算は大抵は以下のロジックで行われます。

初期投資：固定資産＝土地・建屋・電力設備等・空調設備等・NW機器・サーバー・その他のサービス系設備（セキュリティ・事務・防災）・付随する工事
ランニング：電力・空調・トラフィック・人件費

まず、初期投資額を提供可能なラック数または坪数で割り、ラック単価・坪単価を算定します。次にランニングを過去のトレンドから推定して、適当な指標を作り割り当てます。さらに収入サイドとして、ラック建値・坪建値を見積もり、稼働率や実際の見通し・実績を割り当てます。最後にラック（または坪）単位での収入から想定ランニングコストを引き、限界利益を算出して、期間累計でラック・坪単位で回収できていれば黒、ダメなら赤。以上です。

非常にシンプルです。結果として、やるべきことはラックの稼働率・坪効率の向上になります。あとは、できればラック単価・坪単価の値上げのための「付加価値戦略」の追加です。(尚、コストでは勝負にならないので、人手をかけた高サービス、ってな言い方をサービサーが言いますが、これは根本の投資回収ビジネスが変わっていない以上、付け焼き刃の後追い施策でしかないです。Costingを見ればすぐにわかる話です。)

この原価計算の最大の問題点は、「ラックベース・坪単位にユーザーを紐付けることができないクラウド型のサービス」では、ユーザー単位での収益性が文字通り「まったくわからない」ということです。無論、ハウジングなりコロケーションなり、ある程度ユーザーアカウントが特定のサーバ・ラック・敷地に「制限する」ことができているのであれば、この割とざっくりしたコストモデルでも、適用できます。実際、そうしてやってきたの現状でしょう。

ところが状況は変わりつつあります。クラウドベースのサービスは、リソース配分がハードベースからソフトベースに抜本的に変わります。本来であれば、ハードベースのコストモデルは役に立ちません。言われてみれば、当たり前です。しかし、現実にコストモデルを仕組みから変えていくというのはかなり厳しい。

■そもそもリソースコストの配分が変わりつつある。
さらに言うと、発生コストの負担割合が変わりつつあります。Interopでのセッションでも竹中工務店の方が話していましたが、「現状のDCでは初期投資よりも電力コストの割合の方が増えつつあります」。サーバ・ディスクの単価も下がりつつあるのは周知ですし、NW機器についてのコスト低減も時間の問題でしょう。しかしながら電力コスト（＋結果としての空調コスト）や人件費は、上がることはあっても、下がることはないです。というか確実に上がってます。

従って、とりあえず初期コストが回収できて、あとは「ほっておけばなんとかなる」というスタイルはそもそも、かなり微妙になるでしょう。リソースコストの側面から見ても従前のコストモデルは早晩役に立たなくなります。

■現状のDCのコストモデルはそもそも限界
つまり「ざっくりの投資モデル」というコストモデルは通用しない状況になりつつあります。普通に考えても、現実にこれだけ市場が競争的になれば、打つ手としては、より細かいサービスでしのぎ、細かい「利益」を積み上げて行く方法しかないでしょう。要するにロングテール。いまさら感もありますが。

では、それに合わせたコストモデルや原価計算の仕組みに変えればいいんじゃね？という話ですが、それができれば苦労はないわけです。以下のハードルがあります。それも相当高い。

・制度会計
要は特定のユーザーやアカウント単位でのCostingが必要になります。UsageベースやActivityベースの計算ですね。しかも多層的な構造になります。まともな会計プロフェッションならこの話を聞いた段階で「相当な厄ネタ」と判断するはずです。屍累々。

一般的にいって、というか制度会計的に、DCの主要コストの電気・空調を直接費にカウントするのは相当無理があります。普通に間接費なんで恣意的な配賦計算になります。まぁ要するに適当になります。私見ですが、現状の制度会計、特に原価計算は、DCに限らず一般的に、「現在」の日本企業のビジネスモデルにまったく合っていません。半世紀前の「ものづくり」的な発想が中心であれば、通用するのでしょうが、現在はうまくマッチしません。特に間接費的と直接費の間にある微妙なコスト、一般的な販管費よりもアカウントや製品・サービスに直接結びついて、しかし製造の直接費ほどその連関がはっきりしないコスト、は今後の企業活動では非常に重要なファクターです。が、現在のところ今の日本の原価計算の仕組みは、この手のコストファクターの管理にはかなり辛い。

つまり、DCのコストモデルを見直す、と言ったところで現行の会計の仕組みは何もしてくれません。つまり自分で一から考える必要があります。むしろ役に立たない制度会計が強制されている分だけ厄介です。

・ハード環境
ActivityベースやUsageベースの考え方が敬遠されてきた直接の原因は、データ取得の運用の困難さです。継続してコスト・ドライバーの動きが計測できない、またはそのデータの取得にコストがかかり過ぎる。結果、発生コストの配分ができず、勢い適当な基準になってしまいます。この対応策は、ある程度のデータ収集の自動化なのですが、当然ハードコストがかかります。また仕組みを構築する必要があります。

・ソフト環境
仮にこの手のActivityやUsageのデータがとれたとしても、普通に相当のデータ量になります。DCだと要するにトラフィックや電力のトランザクションデータですが、普通に「おい、ちょっと待て。それそんな簡単な話ではない」というのが相場でしょう。

要するに「本当のビックデータ（PCとかUSBメモリーとか俺のスマホに入らない）」になります。この手のデータを業務システムで扱うのは、ある程度の仕組みが必要ですが、そんなものはその辺に転がっているものではありません。マスコミ・コンサル各位のビッグデータ→統計分析→”データサイズは関係ない”という矮小化の結果、今の日本のITでは「普通のビックデータ」を処理する基盤・技術・ノウハウがたまらないという皮相的な状況になってしまっています。要するに環境や運用技術が一般的ではない。

・アプリケーション
そしてこれもないですね。コストモデルの実装がない。簡単に言うと多重的なコストツリー（ってそもそも末端のノードから見て、親が複数ある段階で「ツリー」じゃなくて、もっと複雑な別の何かですね。まぁDAGはDAGなんですが。循環とかないので。）なのですが、現状のRDBMSベースで構築すると、よほどうまく設計して実装しないと、奇妙奇天烈な巨大SQLのカタマリになり、ウンともスンともいいません。普通にSI屋に頼むと目玉飛び出る見積もりに加えて、なんか動くのかそれは？的なものができあがります。

・文化
そして実は一番大きなハードルは、たぶんこれです。「そんな細かい原価計算とかしても、仕方がないじゃん。要は投資が回収できていればいいだろ。それだけの話」という「ざっくり文化」です。これは相当強いと思われます。これによりコストモデルの変更ができない。

そして実は現状の日本のDCビジネスが根本的にクラウドになっていない理由もここにあります。要するにですね。発想が土建屋です。徹頭徹尾。特にマネージメント層に顕著に見えます。個々のお客さんにサービス要素と様々コストスキームの組み合わせを適用して、収益なり利益を稼ぐ、というのはサービス・ビジネスの基本です。「とりあえず投資して、頭数で割ればいい」ってのはですね。サービス・ビジネスではないです。この辺から切り替えていかないと厳しい。逆にここが切り替わるといろいろと打つ手が出てくる。上記の環境や手段の話は、この文化の問題に比べれば、大きな問題ではないですね。

■解決策
以上の解決策は課題が明快な分、実は自明です。簡単に言うとサービスベースに見合う、コストモデルを作って、必要なデータ収集・計算環境をつくって、マネージメントレベルでちゃんと運用しろ、ってことです。それだけの話です。あとは手段の問題でしかないです。

情報収集については、最近はbuilding management systemは相当に優秀ですし、トラフィック・データの収集はそれこそプロレベルの人も多い。分析環境もHadoopならなんやらのおかげで実行可能になっています。あとはコストモデルの設計ですが、これはそのDCビジネスのエース級を当てれば、なんとかなります。（なるはずです。いずれにしろSI屋さんはダメっすね。無理です。）

実際のアーキテクチャとかコストモデルとか、実装とか運用とかいろいろ書けばキリがないのですが、ざっくりの背景や大枠は以上の感じです。（これから先は、各Prjの詳細にどうしても触れざる得ないので割愛）

■本当にDCビジネスはスケールメリットのビジネスなのか？
とまぁ最後に、現在個人的に思うところとして、一般に言われる「DCビジネスはスケールメリットのビジネスである」のテーゼにはちょっと疑義を感じます。確かにこれは真実だと思いますが、それほど自明でしょうか？

これは前提にDCでのスケールメリットが特定の企業に寡占され、しかもそのコストメリットがビジネスに対して支配的であることがあります。私見ですが、それほど市場は単純に見えません。まず、スケールメリットの寡占ですが、この手のIT技術は見ている限り常にビジネス的にはカウンターバランスが働きます。少なくとも「圧倒的」というレンジには届かないと思います。というか、メリットの享受はフォロワーにも必ずあるはずです。

さらに、スケールメリットにより発生するコストメリットが支配的という前提も崩れつつあります。要するに電力・エネルギーのコストの問題。これは規模のメリットはあるにはあるのですが、それほど寡占優位ではないです。

要するにそれほど単純には見えません。にもかかわらず、卑近の例だと、日本でのDCビジネスについては、確かにAWSあたりが圧勝の勢いです。果たしてこれは「DCビジネスはスケールメリットのビジネスである」ということの証左なのでしょうか？

なんとなく感じるのは、・・・日本のDCビジネスを仕切っている「土建屋気質」そのものが問題のように感じます。日本勢は打つべき手が打てていない。その根っこの部分は、文化的なものを感じます。どんなビジネスモデルにもその裏側には、表には出ない、しかしはっきりとしたコストモデルがあります。現状の日本のDCビジネスのコストモデルが、旧態依然とした土建屋的なものであれば、クラウド的なサービスを取り繕ったところで、それは限界があるでしょう。手を打つべきは、仮想化やコンテナといった表面的な技術ではなく、根っこにある「基本的なビジョン」にあるような気がします。

そんな感じ。