2013年2月 Developers Summit 【14-D-3】 「SIの未来ってどうなのよ？」SIer大淘汰時代にAWS専業で新しいSIの形にチャレンジする企業の舞台裏と題して、AWS専業のインテグレーター、サーバーワークスの代表を務める大石が、なぜ「AWS専業」を目指すことにしたのか、今までどのようなAction!を起こしてきたのか、そしてクラウド時代のSIerはどうなり、どんなAction!が求められるのか、お伝えさせて頂きました！ AWSに関するお問い合わせ：https://www.serverworks.co.jp/contact/ サーバーワークスエンジニアブログ：http://blog.serverworks.co.jp/tech/

1. Developers
Summit
SIの未来ってどうなのよ？
SIer大淘汰時代に、AWS専業で!
新しいSIの形にチャレンジする企業の舞台裏
14-D-3 大石 良
#devsumiD @ooishi
株式会社サーバーワークス
代表取締役
Developers Summit 2013 Action !

2. おおいし クラウド の すけ
大石 蔵人之助
株式会社サーバーワークス
代表取締役
– 昭和48年7月20日 新潟市生まれ
– コンピューターとの出会いは10歳の頃
– 当時はPC-8001にベーマガのプログラムを入力する日々
– コンピューターの購入は11歳 ／ SHARP X1
– 中2の時に初めてプログラムが書籍に掲載
– 高校入学記念にX68000を購入
– 仙台の大学に進学・本格的なオタクライフ開始
– 大学生の時にパソコン通信開始。本格的にシェアウェアを販売
– 総合商社でインターネットサービスプロバイダー事業に携わる
– 2000年にECのASPを立ち上げるべく起業

3. クラウド の すけ
蔵人之助
というくらいですから、

4. 持ちネタ
切腹

5. もし今日のセッションで
皆さんに何も得るものがなければ・・・
切腹します

6. 私たちの過去のAction
をお伝えすることで、
答えではなく材料を
ご提供します

8. 大学向�け
合否照会サービス

9. 昔の合格発表

10. 今の合格発表

11. 大学向�けサービス
約 200
校
2004年 2011年

12. シェア
6600%%

13. ところが・・・

14. 必要なサーバー数
課題
無駄
必要なコスト
2月 8月

15. そこで、

16. 22000077年からAAWWSSのテスト利用を開始

17. 22000088年
社内サーバー購入�禁止令

18. 22001111年
AWS Solution Provider
22001122年
Amazon Partner Network最上位の
Advanced Consulting Partner
に認定

19. 日経コンピューター
クラウドランキング

20. Action! by AWS

23. サイトダウンの理由
被災者： 非被災者：
救急医療など、支援 義援金やボランティ
が受けられる場所を ア活動など、支援で
探す目的で きる方法を探す目的

26. EC2

27. 義援金受付システム

28. 負荷分散装置
２０台の、物理的に離れた
２つのデータセンターに設置
されたウェブサーバー １日に５００万通送信できる
メールサーバー
物理的に離れたデータセンター間で
リアルタイムに同期し、かつ１時間おきに
環境構築22時間 バックアップを取るデータベース
アプリ開発4488時間

29. タイムチャート：
33月1144日 日本赤十字社様との打ち合わせ
33月1155日 サイト復旧
33月1177日 義援金管理システム稼働開始

30. 事実
震災後の迅速な義援金の募集に
一役買ったのは、
だった！

31. 本日のメインテーマ
SIerって死ぬの？

32. 世間の論調
SIは必要悪だ
SIは終わった
SIは保険でしかない

33. データを見ても

34. SSII企業倒産件数
240
年間222211件
220
過去最悪！
200
180
160
140
120
2010年
2011年
2012年

35. 厳しいのは
本当っぽい

36. 22000088年ごろの
私たちも・・

37. AWSで
SIオワタ＼(^o^)／

38. AWSでSIオワタの図
AAWWSSでハードが要らなくなる
ソフトもAAWWSSを使えば流通がいらなくなる
ユーザー企業が自分でシステム構築できてしまう
SIオワタ＼(^o^)／

39. 仮説からActionへ
仮説：
ユーザー企業は、自前でクラウドを
コントロールしようとするのでは無いか？
↓
Action!
ユーザー企業が、AAWWSSのコントロールを
やりやすくするツールをビジネスにしよう！

40. Cloudworks
• コンセプト
「日本語でEECC22が操作できる！」

41. AAWWSSの画面

43. ユーザー数
900
800
700
600
500
400
300
200
100
0

44. ビジネス上の結果
• 有料ユーザーが全く増えず！
• 22000099年〜22001100年は
大赤字！！

45. 大失敗の理由
11.. タイミング
22.. 仮説そのものの間違い

46. 失敗11.. タイミング
• AAWWSSは、エンジニアが評価の
ために使うケースがほとんど
だった
• 投入�が早すぎた

47. 失敗22.. 仮説そのもの
• よく顧客が自社にへばりついているSIer
の悪口をいっているので、それを
「コントロールを取り戻したい」
という意図と勘違いした

48. そこに震災

49. 震災が私たちに教えてくれたこと

50. 予測不能
• リーマンショック
• 震災・原発事故
• AAKKBBから前田敦子に
続いて板野友美�まで
引退！？

51. ロードマップを描くことはできません。
しかし知恵を磨くことはできます。
--- ウォーレン・バフェット

52. 震災が私たちに教えてくれたこと
• 大切なことは、
予測の精度を高めるのでは無く、
予測不能な事態がおきても最善手を打つ
「適応マネジメント」

53. 私たちが得た学び
• 顧客が望んでいるものはセルフサービス
ではなく、新しい技術を安全に利用する
ための 保険
• 日本赤十字社の事例が示すように、突発
的な事態（災害・ハードの故障）への
迅速な対応の方が大切だった

54. Pivot and Action!
顧客はセルフサービスを
望んでいない
Cloudworks自体は無料で続け、
AWSの導入�支援（SI）で収益化

55. 成果（SI売上）
2010年
2011年
2012年

56. 〜材料編〜
クラウドをやって
わかったこと

57. わかったこと
11.. 調達モデルの変化
22.. 日本のクラウドとAAWWSSとは何が違うか
33.. クラウドの促進には何が必要か

58. クラウドをやってわかったこと
①調達モデルの変化

59. SIerは
いらなくなるんじゃないか？

60. NO!

61. • 顧客はSIerを必要としている
• ただし、
SIerに求められるモノは変わる

62. 今までのSI
のどが
渇いた！
○×○×○×○×○ ○×○×○×○×○
×○×○×○×○× ×○×○×○×○×
○×○×○×○×
○×○×○×○×
調達チーム 品質チーム
○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○
×○×○×○×○× ×○×○×○×○× ×○×○×○×○× ×○×○×○×○×
○×○×○×○×
○×○×○×○×
○×○×○×○×
○×○×○×○×
バケツを 川から 水の量を 水の品質を
調達する係 水をくむ係 計る係 調べる係

63. これからのSI
のどが
渇いた！ どうぞ！
H2O
H
H
O
アマゾン工場
（クラウド事業者）

64. ピラミッド型
• 「人が多い」ことが前提だった
• 「コミュニケーション」が重要なスキル
だった
• 下請け企業の役割は、技術では無く
「人材バッファ」だった

65. クラウド型調達では
• 非常に小さいチーム
• つくらない技術≒使う技術
が重要に！
– 「組み合わせる」分子式の知識
• AWSのCDP
• Heroku と EC2+SQS
• Salesforce と S3

66. SIerの変化
• 分業モデル崩壊による下請けニーズの縮小
• 「コミュニケーション＜技術」が鮮明に
• 人材バッファとしての役割は終了

67. クラウドをやってわかったこと
②国産クラウドとAAWWSSとの違い

68. 戦艦大和

69. ゼロ戦

70. 共通のポイントは？

71. 一点豪華主義

72. なぜ一点豪華主義が
敗戦を招いたのか？

73. 単体の性能は優れていたが
こだわりすぎて
大量生産できなかった

74. こだわり過ぎエピソード
• 最初は三菱が開発したが、中島飛行機
もライセンス生産し、あとから改�造し
て燃料タンクを取り付けるなど勝手に
改�良。戦地の整備兵にとってはありが
た迷惑！
• 飛行機によっていちいち部品が違うの
で非能率で、空母上でネジをやすりで
削って使ったりしていた・・・！

75. 単体の性能が良くても
戦争には勝てない
• 航空機が戦力として機能するには、
大量生産＋運用システムが必要
運用システム
• 空母
• レーダー
• 通信網
• 補給

76. 運用のキモである
レーダーの例

77. 日本では
• 実は技術としては確立していた
• でも、実地で戦闘員がはずしてた
• レーダーがあっても、通信網と
接続されていなかったので無意味

78. その頃
アメリカさんは・・
• 開発者を空母に同乗させてた
• 現地で何がおきるか、一緒に把握
して改�良させていた
• 新技術のリーンスタートアップ

79. 国産クラウドで
• 自社のシステムを全部クラウドに
乗せたという話を聞きますか？

80. その頃
Amazonさんは・・
• 44兆円のEEコマースサイトをAAWWSS
に乗せて、一緒にサービスを枯れ
させていた・・・！

81. 利用者へのインパクト

82. 最近よく見る比較広告
AA社より4400％安い！
AA社よりCCPPUUが早い！

83. 現実
Amazon
Elas9c
Compute
Cloud
（EC2）
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela9onal
Database
Service
（RDS）
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
（SQS）
Amazon
Simple
No9fica9on
Service
（SNS）
Amazon
Simple
Email
Service
（SES）
Amazon
CloudWatch
Amazon
Route
53
Amazon
Virtual
Private
Cloud
（VPC）
Elas9c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
（S3）
Amazon
Elas9c
Block
Storage
（EBS）
AWS
Import/Export

84. 現実
他社クラウド
Amazon
Elas+c
Compute
Cloud
（EC2）
EC2相当のサービス
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela9onal
Database
Service
（RDS）
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
（SQS）
Amazon
Simple
No9fica9on
Service
（SNS）
Amazon
Simple
Email
Service
（SES）
Amazon
CloudWatch
Amazon
Route
53
Amazon
Virtual
Private
Cloud
（VPC）
Elas9c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
（S3）
Amazon
Elas9c
Block
Storage
（EBS）
AWS
Import/Export

85. どんな違いをもたらすか？

86. EECC22相当のサービスを使った場合
他社クラウド
EC2相当のサービス
BIND
PosXix
インストール時間
サーバー資源
が必要！ squid
MySQL
Backup
監視

87. AAWWSSの場合
Amazon
Elas+c
Compute
Cloud
（EC2）
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela+onal
Database
Service
（RDS）
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
（SQS）
Amazon
Simple
No9fica9on
Service
（SNS）
Amazon
Simple
Email
Service
（SES）
Amazon
CloudWatch
Amazon
Route
53
Amazon
Virtual
Private
Cloud
（VPC）
Elas+c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
（S3）
Amazon
Elas+c
Block
Storage
（EBS）
AWS
Import/Export

88. AAWWSSの場合
Amazon
Elas+c
Compute
Cloud
（EC2）
Amazon
Elas9c
MapReduce
Auto
Scaling
Amazon
CloudFront
Amazon
SimpleDB
Amazon
Rela+onal
Database
Service
（RDS）
Amazon
Elas9Cache
AWS
Elas9c
Beanstalk
AWS
CloudForma9on
Amazon
Simple
Queue
Service
（SQS）
Amazon
Simple
No9fica9on
Service
（SNS）
Amazon
Simple
Email
Service
（SES）
インストール時間０
Amazon
CloudWatch
Amazon
Route
53
サーバー（EECC22）の利用量削減
Amazon
Virtual
Private
Cloud
（VPC）
Elas+c
Load
Balancing
AWS
Direct
Connect
Amazon
Simple
Storage
Service
（S3）
Amazon
Elas+c
Block
Storage
（EBS）
AWS
Import/Export

89. 実システムでの比較（コスト）
AWS
EC2相当
EC2
20台
仮想サーバー
45台
ELB
2
約22万円／月
RDS
2
Route53
1
CloudFront
-­‐
SES
-­‐
CloudWatch
-­‐
S3
20GB
Total
約18万円／月

90. 実システムでの比較（時間）
4455台分の 4455台分の
EECC22相当 セットアップ時間 運用時間

91. AWSでは
EECC22以外のサービスが
システマチックに連携しているから
サーバーのセットアップとメンテナンスに
かかる時間が減って
インフラにかかる時間とコストが減る！

92. 私が伝えたいこと
• 11点に拘る姿勢は日本人特有
• それが、クラウドの様にシステム
思考が必要なサービス開発には仇
• クラウドの構築は車輪の再発明。
それは得意な人に任せて、
使う技術の洗練に注力しよう！

93. クラウドをやってわかったこと
③AAWWSS導入�に必要なもの

94. 予算

95. クラウドを進めるために
（１）社内編

96. 利益が減るんじゃないか？

97. 実際に案件単価は激減
クラウド前 クラウド後
SSII費用
SSII費用
保守・運用
クラウド利用料
ハードウェア
保守・運用

98. 予算は減るが利益は上がる
クラウド前 クラウド後
総額は縮小
SSII費用
利益は
SSII費用
保守・運用 増加
クラウド利用料
ハードウェア
保守・運用

99. 「クラウドに行きたい」のであ
れば、クラウドで未来が創れる
ことを説明しなくちゃ！

100. クラウドを進めるために
（２）顧客編

101. 「クラウドに行きたい」ので
あれば、クラウドの懸念を
払拭しなくちゃ！

102. セキュリティに関する
疑念に対する回答例

103. よくある懸念
クラウドって、
セキュリティが不安…�

104. 一般的なシステムの脅威
外部
データ漏えい 攻撃者によるアタック
内部 物理的アクセスによる
データ盗難

105. クラウド特有の脅威
仮想マシン
場所が分からなくて、
なんとなく不安・・・
仮想マシン 物理マシンを共有したら、
意図せず漏洩したりしないか
AWSのオペレーターが情報を
仮想マシン もっていったりしないか？

106. Amazonは何をしているのか？

107. AAWWSSのセキュリティモデル
外部
外部 利用者
データ漏えい アタック が防御
仮想マシン
内部同士の共有も、
明示しない限り禁止
仮想マシン
物理的 AAWWSSが
内部 防御
アクセス

108. 第三者認証
• ISMS(ISO27001)
• PCI DSS Level 1
• FISMA-Modarate
• ISAE3402 SOC1
(formerly known as SAS70 type II)

109. テクノロジー
• 特許技術で、Xenを拡張
• AWS社員も顧客のデータに
アクセスできない

110. 皆さまにご質問
1. 会社経営に必須の資源は何ですか？
2. それはどこにありますか？

113. なぜ大切なお金を銀行に預けるのか？
• セキュリティ
– 社内より銀行の方が安全
• 可用性
– 預けた支店が事故を起こしても口座情報は保持
• 利便性
– AATTMM＋カードでどこでもアクセス

114. クラウドも、銀行と同じです
• セキュリティ
– 社内よりAAWWSSの方が堅牢な物理セキュリティを確保
• 可用性
– クラウド側で高い耐久性を維持
（SS33のファイル耐久性は9999..999999999999999999%%）
• 利便性
– ネット越しにどこからでも簡単にアクセス

115. NASAと、御社とでは、
どちらがIITTインフラの
セキュリティレベルを保つ
仕組みが整っていると思いますか？

116. AAWWSSで、われわれの組織内の
インフラよりもはるかに高い
セキュリティを保てるようになる
NASA
ジェット推進研究所（JPL）のシニア・ソリューション・アーキテクト
カワジャ・シャムズ（Khawaja
Shams）氏
hap://www.atmarkit.co.jp/ait/ar9cles/1301/24/news087.html

117. セキュリティを高めるために、
銀行にお金を預けることと同様
システムもクラウドに預けた方が、
セキュリティレベルが上がる

118. 聞かれるポイント
• ほぼ決まっている
• セキュリティ
• 従量制
• 国産との比較

119. 大切なこと
聞かれるポイントを、事前に想定しておく
相手の立場で、何がメリットになるのか
考える
相手のメリットになることを、
わかりやすく、丁寧に伝える

120. チームが小さくなる
一人がカバーする範囲が増える
伝える能力が
より大切に！

121. 私たちのAction!
• 毎週金曜日の夕方、22名のエンジ
ニアが社内でLT＋UST配信
• Yammerでリアルタイムに
フィードバック

122. 〜クラウドをやって分かったこと〜
11.. 調達モデルの変化
• 小さいチーム
• 作らない技術の追求
22.. 日本のクラウドとAAWWSSとの違い
• システム思考 vs 一点豪華主義
33.. AAWWSSの導入�に必要なモノ
• 予算→社内・社外に未来を示すこと
• 伝える能力

123. 本日のまとめ

124. まとめ
①保険？いいじゃないか！
顧客はSIを求めている。自信を持って突き進もう
②会社も、個人も、未来の予測より、
適応力が大切。技術も考え方も、適応力をつ
けていこう！
③クラウド時代のSIに必要な知識
（クラウド分子式・説明力）を
身につけて、クラウド時代の先頭に立とう！

125. 切腹しろ
という方は
お申し出下さい

126. そうでない方は・・・

127. I suggest your Next Action!

128. Action!
• 変化させよう！
– 変化しない周�りをなげくのではなく、
自分で変化を起こす方法を学ぼう！
– 周�りの一人に、あなたが進めたい技術の話を
してみて下さい
• 変化を楽しんで、
SSIIは楽しい！未来がある！
というメッセージを一緒に発信しよう！

129. It s your turn!