日本語の特定フォント使用部分でレイアウト崩れまりますが。そこは気にせず。2013年2月の講演の資料。データセンターの選択にはクラウドへの理解が必須で、クラウドの選択には、開発から運用まで全体最適の観点での理解と検討が必要ですよね、というお話。

1. 今こそユーザー視点で！
攻めと守りの
データセンター選び
～クラウド時代の iDC 選び再考～ 2013.02
Arichika Taniguchi / 谷口 有近 / @arichika, Facebook, G+ 谷口有近 検索
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 1

2. 業界バズワードの変遷から見る
時代認識
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 2

3. 時代認識
IT革命/BB元年 Web2.0 ビッグデータ元年
x5 ’96 | ’97 | ’98 | ’99 | ’00 | ’01 | ’02 | ’03 | ’04 | ’05 | ’06 | ’07 | ’08 | ’09 | ’10 | ’11 | ’12 | ’13 |
|
w95OSR2 w98 w2k wXP wVista w7 w8
IE3 IE4 IE5 IE6 IE7 IE8 IE9 IE10
.NET1.0 .N2.0 .N3.0 .N3.5 .N4.0
FF1 FF3 FF4-7 FF18
x4 NN3 NC4.5 N6
Gecko
N7 N8
GC1 GC2-8- GC14 GC24
<HotJava
Kindle1 Kindle iPad
BlackBerry Surface
iPhone iPad
Y!JP iMac Mac OS X iTunes WP7 WP8
x3 BlackBerryJP Android
DeNA Nexus 7
GOOG Suica DeNAﾓﾊﾞｵｸ
楽天 i-mode mixi
<eBay NASDAQ
LINE
Salesforce AMZN Coins
<AMZN PayPal GREE twitter
x2 MySpace
Facebook HTML5 Draft
ePUB
HTML5勧告候補/5.1 Draft
CSS1
CSS2 jQuery
CSS2.1 勧告
Dynamic HTML マッシュアップ CSS3
LOVE LETTER Ajax(JS+XML)
HTML4.01
Nimda BigData
Hadoop
x1 SQL Slammer/Blaster
SaaS Cloud (US) クラウド(JP)
Cloud Foundry
PaaS クロネコDC
sakura AWS G.AppEng.
Heroku Azure
x1/2 VMware WS VMware ESX Xen VMware GSX Hyper-V L2広域/SDN – Open Flow
<‘88 ﾒｲﾝﾌｰﾑPR/SM Cisco UCS
NK225 月アスキー廃刊 NEWS WEB24
MS独禁法NSDAQ急落
ライブドアショック リーマンショック アベノミクス
COP3 米)ｱﾙｺﾞ台頭 民主党政権時代
ITバブル崩壊
x1/3
米)ｲﾝｽﾃｨﾈｯﾄ 米)代替市場ATS 9.11テロ 欧)ｸﾞﾘｯﾄﾞﾌﾞｰﾑ 米)NMS施行 米)NYSE Linux クラウドファンディングソーシング
- - - - - - - いざなみ景気（第14循環） - - - - - --ミセスワタナベ
-
日)山一證券廃業 日)株式委託手数料自由化 日)ｱﾙｺﾞ話題 日)金商法・PTS 日)東証新シス
APNIC Dist.
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 3
背景チャート出所：NASDAQ統計資料(www.nasdaq.com), APNIC統計資料(www.apnic.net) , 日経平均プロファイル統計資料(indexes.nikkei.co.jp) をもとに作成

4. 時代認識
WebAPI UI → UX 組織内
標準 < 独自拡張 標準化 志向
疎結合 ｴﾝﾀｰﾃｲﾒﾝﾄ UX標準化
既存体験/業務の 新しい事をWebで Blog/CGM：発信 O2O
Web化≒OA ｺﾐｭﾆｹｰｼｮﾝのﾈｯﾄ化 SNS
音楽・書籍 音楽 書籍
物理所在をﾈｯﾄで流通手配 データのﾈｯﾄ流通 データのﾈｯﾄ流通
携帯 TV融合
スマホ
家族PC/会社PC ノート/個人用PC タブレット
パッケージ SaaS/ASP
PaaS
Hosting IaaS 高度化 BaaS
IA仮想化 NW仮想化
汎用機 → PCサーバ
Grid IA分散 高度化 物理で仮想化
貸し渋り ルール変更 US 金融引締 JP 個人 競争力変化 安全・安心
金融不安 自由化 アルゴ 投資家台頭 危機管理/スピード 監督強化
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 4

5. 時代認識
エコ リスク/セキュリティ 個々の力/マネタイズ
法人/家族 単位 個人 単位 デバイス単位＋世界
数値を集める 統計を見る 相関を探る
計画して ＋走りながら ＋外部環境次第で
予定通り造る 未知を創る 素早く変える
機械化の模索 個性の模索 柔軟性の模索
安心（＝繁栄）のために 安心（＝発展）のために
変わらない・変えない 変わる・変える
コスト/単価 著作権 モノ→情報 ○ない権利
物流の革命 IT革命 モノから情報へ 権利の変化
要求規模 オプトイン/アウト
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 5

6. インターネット直近17年を振り返る
時代認識
OA（業務自動化）からIT（情報技術）へ（未だ）変化中
• 業界により進捗の差あり。金融、行政あたりで最後尾争い中。
SIer 的請負からの脱却（OA的SIからIT的ビジネス開発へ）
• 景気改善鈍く、IS部門/子会社はコストセンター化し自立を促される。
開発手法の見直しと取捨選択（銀の弾丸はない）
• オブジェクト志向＋関数型、ウォーターフォール＋アジャイル。
マーケティング手法の多様化（チャンネル横断UXの整備）
• 既存メディアに変化を与える新メディアと情報経路の多様化。
ネットも重厚長大から軽薄短小だが同時に深く世界規模にも
• 早期、創造、測定、即断 がキー 早創測即（そうそうそくそく）
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 6

7. 時代認識
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 7

8. 競合他社が同業他社では”無い”時代
時代認識
海外：アマゾン、アップル、グーグル、マイクロソフト …
• APPL vs. GOOG vs. MSFT vs. AMZN デバイス＋アプリ全方位対決
• Amazon vs. GOOG vs. MSFT の IaaS/PaaS 対決
• VMware vs. MS の仮想基盤＋ミドルウェア対決
• HP vs. Cisco の IAサーバ + SDN 対決
• Amazon( Coins を発表) vs. PayPal の 流通+決済基盤 対決
タイムマシン商法のディレイが縮む
• ５年遅れの国内金融もかなり追いついてきた感ありで、国内ITも独自
色あるものの、決して負けてない技術力の背景。
• 新規参入によるタイムマシン商法アタックは普通のお話でもあり。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 8

9. 競合他社が同業他社では”無い”時代
時代認識
例えばネット証券も例に漏れず
• 株式ベースのネット上位5社の競争に、FX専業が挑戦状を叩きつけ、
現状シェア3位に食い込む。
• 収益構造の差を利用し、他社を振り落とすコスト面での戦略。
出版やTVなどメディアの競合他社は？
• もはや海外勢だけでなく、ニュースサマリアプリなどの小規模アプリ
開発者が影響力を持ち、競合になり得る。
• 海外勢の動向を見るにTV型端末の影響力はO2O的に重要な観点で、
（古い言い方ですが）報道のメディアミックスという視点も必要。
（今回のテーマである）データセンター業界は？
• そもそもで AMZN やマイクロソフト、グーグルは自社運用の発展系。
• 日本でもクロネコDCがサービス開始。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 9

10. 時代認識
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 10

11. 技術領域・スキルも“クロスオーバー”化
流行の BigData のキーとなるデータサイエンティスト
• 統計を使いこなしてプログラムも書けるし数字の意味がわかってる、
つまり業務の理解が出来てるからこそ仕事になる職種。
流行の SDN/OpenFlow はネットワークの仮想化だが
• サーバー仮想化からネットワーク仮想化の流れで、サーバー技術者と
ネットワーク技術者の垣根が曖昧になっており、あえて区別すると非
効率になっている。
流行の UI/UX は、業務理解とプログラミングとデザインをア
ジャイル風味で和えた代物
• 優れたユーザー体験には、見た目の素晴らしさだけでなく、サービス
（＝業務データ）を得る体験について、サーバーやクライアント領域
双方で支える技術への理解が不可欠。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 11

12. 時代認識
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 12

13. ネットだ！と言うが…とはいえ実際は？
時代認識
EC関連市場規模 2011年度 実績
• BtoC EC市場 約 8.8兆円 前年度比+13.6% (*1)
• O2O市場 約 24兆円 (*1)
• スマートペイメント市場 約 43兆円 (*1)
• 家計最終消費支出（実質） 約300兆円 前年度比 +1.6%(*2)
• 実質GDP 約514兆円 （震災影響でも+0.3％だが実質GDIで-1.0%）(*2)
実質GDP比（O2O規模で）5%程度の影響力をどう見るか
• 市場に影響を与えるプレイヤーの数、不況下でも衰えない成長
• 業務上の連関から購買に至るまで、O2O過程としての連関の効果
*1 出所：NRI ITナビゲーター 2013年度版
*2 出所：内閣府 http://www.esri.cao.go.jp/jp/sna/data/data_list/kakuhou/files/h23/sankou/pdf/point20121225.pdf
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 13

14. 時代認識
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 14

15. 変化に寛容である事が武器になる
クラウド時代の
データセンターとは
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 15

16. 簡単に “クラウド” と言いますが
データセンターとは
クラウド時代の
“クラウド“ という言葉の（発言者の）背景で論点が変わる
• 自前主義とアウトソースとしての比較？
• NISTの定義もなんのその。文脈依存する怖い言葉。
クラウドの時代≒柔軟な○○の時代 言い換えてみる
• 予算に対して柔軟な基盤の時代⇒ 高度な IaaS
• スケールアウト設計に対して柔軟な基盤の時代⇒ PaaS 視野に
• 競争力関係無いので汎用サービスで良い… ⇒ SaaS 提供を受ける
• 柔軟に技術領域の人材を活用したい⇒ 派遣クラウド
• ITよくわからんのでとりあえずよろしく⇒ 丸投げクラウド
達成しようとしている「柔軟な○○」が見えてますか？
• クラウドでコストカット！という短絡は間違いの元。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 16

17. “データセンター“の意味が拡張している
データセンターとは
クラウド時代の
狭義のデータセンター：ファシリティとしての DC
• 国内は、まだこの言い方をすることが多い感触。
• DCは「電源品質、耐震品質、ネットワーク・コネクティビティ、災害
対策の観点で最適化し、運用リスクを低下させ、IT機器を最適な状態
で稼働させるためのNW込みの施設」という理解。
日本データセンター協会活動内容ご紹介
• http://hosting-pro.jp/jdcc/jdcc.pdf
新たなデータセンター・ファシリティ基準の概要
• http://www.ffr-plus.jp/material/pdf/110606_04.pdf
• 2011年 JDCC 運営委員 市川氏の素晴らしいファシリティ基準の説明
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 17

18. 例えば…
データセンターとは
クラウド時代の
出所：総務省「クラウドコンピューティング時代のデータセンター
活性化策に関する検討会 報告書」p.5 (2010.05)
• http://www.soumu.go.jp/menu_news/s-news/02kiban02_02000043.html
• 引用「～「データセンター」とは、サーバー類（サーバーや付随する通信機
器、電源設備などをいう。以下同じ。）を収容する建物や部屋などの「施
設」及びそこに収容されるサーバー類を一体として指し示す言葉である。す
なわち、特殊な機器であった「汎用機」や「メインフレーム」などを作動さ
せるために必要な電源や空調設備、通信回線用の管路が用意された、特別な
施設をデータセンターと称した。サーバー類が小型化し、一般の事務所など
でも作動可能なものとなった現在においても、複数のサーバー類を集約的に
設置する際には、このようなデータセンターに収容することが一般的である。
この施設とサーバー類とを別の者が整備することがあり、その場合には施設
のみを指してデータセンター（狭義のデータセンター）と呼ぶこともある。
～」
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 18

19. “データセンター“の意味が拡張している
データセンターとは
クラウド時代の
データセンターはより広義へ：PG実行環境としてのDC群
• 海外はこの言い方することが増えてきた感触
• DCが解決すると期待される課題は、DCのファシリティ改善だけでな
く、OSやミドルウェアの改良、開発プラットフォームを改良するで、
より効率的な代替が出来る場合があり、故に、プログラムを安全に動
作させるための仕組みを概念モデル的に指し示して使う。
• あえて別の言い方「DCは課題を解決する “IT機能” を売るクラウド」
背景の推測
• 海外品質＝ なかなか安定しない安い電力、相変わらず安い土地、信頼
たり得ない品質もある労働力という環境条件において、ITの最適化を
図れという課題解決だと考えれば、比較的素直に納得がいくのでは？
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 19

20. データセンターとは
クラウド時代の
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 20

21. クラウド化≒実は複雑化≒適材適所
データセンターとは
クラウド時代の
得るモノ 捨てるモノ 適用範囲例
迅速な機能の低コスト導入 機能の自由度 会計システム
汎用的なサービスレベル （≒つまり競争力を捨てる） 間接系基礎業務
開発生産性の向上 PG設計自由度（≒利点でもあり） 情報系ビジネス
スケールアウト耐性 ミドル以下は自社改良が不可 ベンチャー系
ミドル以下自社運用不要 （≒高負荷の場合技術力が必要） ハイブリッドクラウド
構成や運用設計の自由度において ハード依存AP運用
H/Wリードタイム短縮
一定の制限あり イベント系Webサイト
H/W以下自社運用不要 ベンチャー系・小規模
（≒長期稼働の償却利点の減少）
サービス廃止リスク低減 業務含めた全体最適への道程 自社でシステムを構築し
日本的商習慣の融通 技術主導イノベーション ていない企業
全て自分達で決めるのでコスト高 超大規模
最高の自由度 （GOOG.FB.AMZN.MSFT.）
（≒人材採用コストでもある） 機密性が高い業務
コスト換算が出来ればなんでも 通常は金銭面コストと将来におけ なんでもOK！
ござれ（≒責任回避とも言う） るビジネスの変革と自由度 旧来型金融など
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 21

22. それぞれのクラウドで考えるコトの例
データセンターとは
クラウド時代の
忘れがちなコト 対策例 よくある間違い
ユーザーのアカウント管理 パスワード変更管理規約を作成して現場
SSOサービスでID一元管理
データ保護（論理破壊対策） のISO運用はカバーしたが不便だなぁ。
ミドルウェア・N/Wなどでの 業務レベル性能の監視 ミドル・H/Wの性能を額面通りに信じて
ピークI/O性能の担保 データ運用管理は自前で みたけどやはりピーク性能出ない。
データ保護（発想の転換） ハイブリッド化 CPU負荷を監視して○%以下に抑える。
スケールアウト耐性PG設計 開発要件に含める とにかく怒鳴ってなんとかさせる。
データ保護（自前対策視野） PaaS へシフトする うちは感染しないと信じてみる。
ミドルのセキュリティ対策 運用管理費をさらに出す うちは壊れないと信じてみる。
誰かがどこかで、やっぱりがん ”ごめんなさいもうしません”と書いてあ
知らないフリを決め込む
ばっているという事実 る改善報告書の提出で指導したよフラグ。
運用開発の壁が無く、仕組みを維 ここ、社内からの SNS 禁止だし、そも
技術者賃金の引き上げ
持することが出来るだけの技術力 そもでウェブアクセス禁止だし。困った
自己啓発推奨と現場理解 ときに情報が調べられないって。
あってこそのオンプレ
「形あるものはいつか壊れる」と 供給者訪問やITパスポート お金で未来の課題を解決することが出来
いう基礎的な概念 試験、まず自社を知る事 るのであれば、まだ楽な話です。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 22

23. データセンターとは
クラウド時代の
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 23

24. 自分達にとっての“良さ“の定義から
より良い選択の武器
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 24

25. システムコストの大前提
より良い選択の武器
第一法則「孤立系のコストの総量は変化しない」
• 熱力学第一法則：エネルギー保存則
金銭的コストが下がった分だけ、何かしらのコスト（当然リスクを含
む）が上昇してると見るべき。リスクテイクの領域を変更しているんだ
という理解。
• #1：安い IaaS に丸投げ、データ保護がなく障害時に戻せない。
• #2：アジャイル開発で速度優先したが、事業会社側作業量が増大。
• #3：保守費をケチったら、運用担当者の品質が下った。
• #4：SaaS を採用したけど長期利用で損益分岐点が遙か遠くに。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 25

26. システムコストの大前提
より良い選択の武器
第二法則「孤立系のコスト構造の乱雑さは増大する」
• 熱力学第二法則：エントロピーは増大する
高いコスト状態は低いコスト状態に移動するが、その際に乱雑さを増大
させ、非可逆な状態遷移を形成する。≒ようはシステムコスト構造は放
置すると把握が出来なくなりまっせ、という理解。
• #1：社内 IS 部門の対応が悪いので、営業部門主導で SaaS / IaaS クラ
ウドによってシステム化したところ、マスタ情報の多元化が進んでし
まい、データ一元管理から遠くなったので BigData 夢のまた夢。
• #2：部門毎にクラウドを勝手採用したら、これまでは部門の壁と勘定
科目により把握が出来ていたITコストが、雲のようにぼやけてしまい
実態の把握が出来なくなった。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 26

27. より良い選択の武器
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 27

28. 多種多様な開発要件と選択肢（新規系）
より良い選択の武器
ワンショット マーケティング サイト の運用
• レンタルサーバーで十分だしコストバランス、開発コストも見合うも
のが多い。さすがに社内にサーバー置いてる時代でもなく。
• 最近はグローバルレベルのストレージサービスが静的コンテンツを配
置公開するサービスがあり、ホスティングさえ不要になる可能性。
考え方の例
• 落ちてもリカバリが容易で影響が小さい（むしろ炎上マーケ？）
• 元データを管理しておけば再配置して再開が出来るような仕組み。
• マルウェアの感染源になってしまうとつらく、一定の対策は必要。
ホスティング/レンタルサーバー等をベースに負荷対策検討
• スキル/技術/理解が進めば将来的に PaaSベースか SaaS ベース？
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 28

29. 多種多様な開発要件と選択肢（新規系）
より良い選択の武器
大規模ベンチャー系ネットサービス開発
• 例えばネット上にディスク領域を提供する Bitcasa （Dropboxの競合と
して最近正式サービスイン、無限のディスク容量を提供）は、バック
エンドは AWS を採用。
考え方の例
• 自社で一式そろえて運用するには夢がデカすぎて、コストが割に合わ
ない。クラウドで始めたほうが安い。Leanスタートアップ。彼らはク
ラウド事業者になる必要はなく、安いクラウド事業者を選択的に選べ
るシステム設計に注力したほうが得策。
高度なカスタマイズが可能な IaaS + PaaS/BaaS の選択肢
• オンプレ採用で余ったリソースを売る事も可能だがコア事業はそこで
はないし非効率（株式非公開化のDELLも今からで大変な苦労）。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 29

30. 多種多様な開発要件と選択肢（新規系）
より良い選択の武器
技術者の層が厚いミッションクリティカル業務
• 金融や製造業・サービス業で自社系列のIS部門があり、社内開発して
いる。業務系アプリの開発や、マスターデータ管理の観点で業務系ア
プリと外部向けアプリのシステム基盤統合が出来ている、など。
考え方の例
• 自前主義はIT統制が効いていれば、丸投げよりはコストを下げる事が
出来る。（もちろんパブリッククラウドのほうが安いが）
• 特殊要件ケースで、まだクラウド環境とのデータ連係に難あり。
全面オンプレ または H/W以下を まるっと IaaS でカバー
• オンプレの場合、技術者には、その業務領域における理解が必要で、
比較的高給が求められてくる。
• DC契約先次第で、プライベートクラウド的な IaaS 運用も可能。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 30

31. 多種多様な開発要件と選択肢（新規系）
より良い選択の武器
（最近）技術者の層が厚い、ソーシャル基盤サービス
• 例えばゲーム等を提供する基盤サービス業の場合、自社系列・内部の
IS部門が基盤としてのミドル、OS やマスターデータを管理するなど。
考え方の例
• 基盤側がサービス提供の主導権を握っている場合、ミドル～基盤に近
い部分は徹底的に自前主義でIT統制を効かすという選択肢も。ミドル
ウェアの設計次第でパブリッククラウドのベースの基盤も。
全面オンプレ/ミドル集中でHWは IaaS 化、または日本型クラ
ウドで基盤自由度を引き上げた柔軟構成も
• OTTアプリは社内で造らず、箱だけ徹底的にマネジメントするなど。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 31

32. 多種多様な開発要件と選択肢（拡充系）
より良い選択の武器
BCP対策で既存DCを拡充する
• 震災対策電力対策として、稼働済みシステムのBCPサイトを拡充。
考え方の例
• データレベル待避から東京・大阪壊滅時の稼働継続担保まで選択肢は
無限大。まず事業継続性の観点から、ミニマムな構成を検討、必要に
応じて順次拡充していく。
• インターネット接続性の観点からキャリアダイバシティも視野？
既存基盤複製の配置なら、別のDC業者を選択することも
• ただし同じ業者ならではの利点もあるため比較は必須。
• グローバル PaaS で作成すると、このあたりは基盤側の開発設計環境
として織り込み済みのケースあり。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 32

33. BCP向けDCの選択肢
全ての可能性を考えてたらキリ無い ～宇宙線から航空機落下など～
まず電力は？
• まだ実感沸きやすいが、電力系iDCが必ずしも有利とは限らず。
地震や活断層が少ないところ…
• 比較的地震が少ないエリアは存在するが、大切なのは真っ当な耐震制震設計
と運用で、大規模DCであれば大同小異。（そもそもで地震が少なくても通信
ケーブルと電源確保の目処が無ければ DC としては失格で）
（アプリ次第で）重要な観点は “ネットワーク遅延“
• 福岡～東京、石狩～東京で ~20ms あたり香港で ~60ms 程度が実績。
• 業務によりサービスを提供する相手の場所や距離、アプリの速度要件と通信
の実装方法を考慮必要。（とはいえ上位層でも、開発力でなんとかなる話）
ユーザー以上に DC 屋さんは真剣に場所の設定をしてる
⇒ 情報開示体制がしっかりしてる DC 事業者に相談すべし
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 33

34. より良い選択の武器
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 34

35. DC 自社でやる≒リスクテイクの難しさ
より良い選択の武器
やることがとにかく多い上に、業界専門知識の理解が出来るマ
ネージャ必須、さらにファシリティ供給者とのタッグが不可欠
• C工事から上全部！！＝電力需要と余力設計、給電側との交渉、ラッ
クやサーバー単位での電力量管理、漏電管理、弱電強電を上位レイ
ヤーと調整、空調運用、空調設計、通信事業者折衝、ビル内配線工事
調整、床上げ設計工事依頼、耐震設計、耐荷重設計、消防法準拠設計、
各種監査基準準拠の入退室管理設計、… まだサーバーに到達しない
各種の障害発生時に担保できる体制があってこそ
• 夜中の2時に原因不明の電圧降下によるアラートにどう対応するか。
5年前は設備余力削減で市場単価の半値も可能だったが…
• 自前運用で機器導入までのリードタイム削減が効果を発揮する時代も
事実あった。今はクラウドで時間短縮、現時点ではメリットに乏しい。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 35

36. 自社DC運用のメリットは無くなっていく
より良い選択の武器
技術領域のターゲッティングにより検討の価値はある
DC事業者が DC事業者側での 主に自社で担保する
展開規模 例
担保する利点 一般的な欠点 技術領域
世界規模 Geo-Scale ミドルウェア 国内IT運用の常識は忘れ アプリケーションレイ AWS,
費用面アドバンテージ たほうが良い ヤーでの可用性で設計ノ Google,
クラウド的迅速な展開 ウハウが次世代感 Microsoft
国内規模 国内向け高品質の電力や運用、危 費用面（事業者次第） プラン次第の柔軟性 さくら, IIJ, NTT
機管理対策 PaaS 選択肢が無い 既存技術の活用可能
都市規模 電力融通（電力系） BCP設計の自由度 NWレイヤーから上全て 電力系など
心理的な近さによる安心 既存技術の活用可能 ネット取引
ミッションクリティカル系低遅延 取引所系
建物・フロア 自社ビジネスにあわせた展開（自 自社管理運用負荷が高 基本的に全て 再販前提の
規模 由度高い）と余力調整によるコス くなる 自社運用DC
トメリット＆安心”感” 金融大規模系
会社の床 物理的再起動のしやすさ 空調電気代 基本的に全て 今時はほぼ見ない
基本的にタダ？（違う！） 停電対応 ですねさすがに
ここの改善で自社 DC 運用のメリットは大幅に削がれており、 戦略的な理由が無い限り選択肢にはならない
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 36

37. より良い選択の武器
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 37

38. 必要なのは “CIOの手腕 x 現場の連携”
より良い選択の武器
CIOとITの現場との距離を縮める事
• CIOは経営体制のなかで、企業が達成する目標を踏まえたIT全体の最適
化を自信を持って進める必要がある。
• データセンターや開発運用の標準化基盤の整備はチャレンジし続ける
ものであり、ロードマップを修正しながら走り続ける。
• 実情を最も理解している現場は、認識している弱みを普段から共有し
つづける事。（上司が永遠に無理解ならそこで組織は終わり）
• CIOはテクノロジーを理解する事。
開発と基盤、サーバとNWなど既存業務領域の分断からの解放
• 自らの専門領域をより深めるには、クロスオーバーが必須となった時
代と認識すべし。
• 他領域の課題を自領域で解決することが出来るかを普段から思考する。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 38

39. そのシステム案件での課題を整理する
より良い選択の武器
案件遂行の課題を認識し全員が共有すること
• NWの問題？コード上の問題？基盤の問題？全ての課題を共有する。
• 会議はチーム単位で問題ないが、メールなり社内SNSなりで共有を図
る。上司・リーダーは課題のコンフリクトを調整し、その理由を開示
し必ず共有する。
• ここをPMO依存にすると今度はPMOの力量依存になる。
クロスオーバーでの発想を支援する
• 担当業務の範囲でのみ課題を解決しようとすると遅いし全体最適から
ほど遠くなる。程度の差を許容しながら、全員がクロスオーバーで発
想し考える技を習得する。
最も完遂リスクが高くコアからも遠い部分はアウトソース
• 本当にサーバー運用まで必要？そのデータ保持は必要？
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 39

40. 実践する iDC 選択
より良い選択の武器
IT基盤最適化 x 業務改革 の長期戦略があれば、どの選択でも大
きくは失敗しない
• 自社の弱みを整理し、それを補完してくれる開発基盤やデータセン
ター事業者を選定すれば良い。
iDC選択での失敗はつまり、需給の”ミスマッチ”
• 速度は業務設計上必要なのに、遠い海外DCをチョイス。
• データ保護とBCP体制が必要なのに適切な体制が無い業者をチョイス。
• 速いサイクルの変化を望んでいるのにコスト面のみでチョイス。
需要側ロードマップが無ければマッチングの判定も不可能
• つまりは自社自部門の強み弱みをどう変えていくのかの視点。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 40

41. より良い選択の武器
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 41

42. 本日の内容を箇条書きで
まとめ
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 42

43. まとめ
DC選択は、開発・運用体制の設計と切り離せない
クラウド選択肢への理解は、DC選択の助けに
自社の特に弱みを認識し、全体最適の視点で設計する
「一度造れば終わりであとは減価償却」ではない
正解は無い故、評価しながら適切に変更し続けていく
開示体制が良好なDC事業者は力量ある良いパートナー
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 43

44. Thank you. ^^/
ご質問はオンラインでもオフラインでも
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 44

45. 付録
本資料を利用する上のライセンスについて
• 本資料は、各項にて特段の捕捉が無い限り、CC BY-NC 3.０ ライセンスによって許諾
されています。ライセンスの内容を知りたい方は
http://creativecommons.org/licenses/by-nc/3.0/deed.ja にてご確認ください。
• 本資料中の引用文献・引用資料については、著作権法第32条にしたがう引用です。
商標
• 記載されている会社名、製品名は、各社の登録商標または商標です。
免責
• 本公演は、特定企業や技術その他事項についての好意的否定的を問わずその価値判断
について、情報提供者個人の見解を述べるものであり、過去や未来において所属した、
もしくはその可能性がある法人や所属組織の公式見解ではありません。
• 情報の内容につきましては万全を期しておりますが、その内容を保証するものではあ
りません。万一この情報に基づいて被ったいかなる損害についても、情報提供者は一
切の責任を負いません。
• 本資料に記載された金融商品や上場企業についての見解は、その価値を断定的に判断
し勧誘するものではありません。
CC BY-NC 3.0 (引用除く), 2013, Arichika Taniguchi, 45