2013 デブサミ 「siの未来ってどうなのよ？」

Summit Developers

Developers Summit 2013 Action !

SIの未来ってどうなのよ？ SIer大淘汰時代に、AWS専業で !新しいSIの形にチャレンジする企業の舞台裏

大石 良 @ooishi

株式会社サーバーワークス

代表取締役

14-D-3 #devsumiD

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

おおいし 大石 株式会社サーバーワークス 代表取締役

クラウド の すけ

蔵人之助

クラウド の すけ

蔵人之助

というくらいですから、

持ちネタ

切腹

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

切腹します

私たちの過去のAction をお伝えすることで、

答えではなく材料を ご提供します

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

昔の合格発表

今の合格発表

大学向�けサービス

2004年 2011年

約200校

シェア 6600%%

ところが・・・

必要なコスト

課題

2月 8月

必要なサーバー数

無駄

そこで、

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

22000088年

社内サーバー購入�禁止令

22001111年 AWS Solution Provider

22001122年 Amazon Partner Network最上位の

Advanced Consulting Partner に認定

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

Action! by AWS

サイトダウンの理由

被災者： 救急医療など、支援が受けられる場所を探す目的で

非被災者： 義援金やボランティア活動など、支援できる方法を探す目的

EC2

義援金受付システム

２０台の、物理的に離れた ２つのデータセンターに設置 されたウェブサーバー １日に５００万通送信できる

メールサーバー

負荷分散装置

物理的に離れたデータセンター間で リアルタイムに同期し、かつ１時間おきにバックアップを取るデータベース 環境構築22時間

アプリ開発4488時間

タイムチャート：

33月1144日 日本赤十字社様との打ち合わせ

33月1155日 サイト復旧

33月1177日 義援金管理システム稼働開始

事実 震災後の迅速な義援金の募集に

一役買ったのは、　

だった！

本日のメインテーマ

SIerって死ぬの？

世間の論調

SIは必要悪だ

SIは終わった

SIは保険でしかない

データを見ても

SSII企業倒産件数

120  

140  

160  

180  

200  

220  

240  

2010年 2011年 2012年

年間222211件 過去最悪！

厳しいのは 本当っぽい

22000088年ごろの 私たちも・・

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

SIオワタ＼(^o^)／

ユーザー企業が自分でシステム構築できてしまう

ソフトもAAWWSSを使えば流通がいらなくなる

AAWWSSでハードが要らなくなる

AWSでSIオワタの図

仮説からActionへ 仮説： ユーザー企業は、自前でクラウドを コントロールしようとするのでは無いか？ 　　　　　　　　　↓

Action! ユーザー企業が、AAWWSSのコントロールを やりやすくするツールをビジネスにしよう！

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

AAWWSSの画面

ユーザー数

0  

100  

200  

300  

400  

500  

600  

700  

800  

900  

ビジネス上の結果

• 有料ユーザーが全く増えず！ • 22000099年〜22001100年は

大赤字！！

大失敗の理由

11.. タイミング 22.. 仮説そのものの間違い

失敗11.. タイミング

• AAWWSSは、エンジニアが評価のために使うケースがほとんどだった

• 投入�が早すぎた

失敗22.. 仮説そのもの

•  よく顧客が自社にへばりついているSIerの悪口をいっているので、それを

「コントロールを取り戻したい」 という意図と勘違いした

そこに震災

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

予測不能

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

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

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

•  大切なことは、 予測の精度を高めるのでは無く、 予測不能な事態がおきても最善手を打つ

「適応マネジメント」

私たちが得た学び

•  顧客が望んでいるものはセルフサービスではなく、新しい技術を安全に利用する

ための保険 •  日本赤十字社の事例が示すように、突発的な事態（災害・ハードの故障）への

迅速な対応の方が大切だった

Pivot and Action!

Cloudworks自体は無料で続け、AWSの導入�支援（SI）で収益化

顧客はセルフサービスを 望んでいない

成果（SI売上）

2010年 2011年 2012年

〜材料編〜

クラウドをやって わかったこと

わかったこと

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

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

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

NO!

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

今までのSI のどが 渇いた！

バケツを 調達する係

川から 水をくむ係

水の量を 計る係

水の品質を 調べる係

○×○×○×○×○×○×○×○×○×○×○×○×○×

○×○×○×○×○×○×○×○×○×○×○×○×○×

○×○×○×○×○×○×○×○×○×○×○×○×○×

○×○×○×○×○×○×○×○×○×○×○×○×○×

○×○×○×○×○×○×○×○×○×○×○×○×○×

○×○×○×○×○×○×○×○×○×○×○×○×○×

調達チーム 品質チーム

これからのSI

アマゾン工場 （クラウド事業者）

H O  

H2O

H

のどが 渇いた！ 　 　どうぞ！

ピラミッド型

•  「人が多い」ことが前提だった •  「コミュニケーション」が重要なスキルだった

•  下請け企業の役割は、技術では無く 「人材バッファ」だった

クラウド型調達では

•  非常に小さいチーム

• つくらない技術≒使う技術 が重要に！

– 「組み合わせる」分子式の知識 • AWSのCDP • Heroku と EC2+SQS •  Salesforce と S3

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

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

戦艦大和

ゼロ戦

共通のポイントは？

一点豪華主義

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

単体の性能は優れていたが こだわりすぎて

大量生産できなかった

こだわり過ぎエピソード

•  最初は三菱が開発したが、中島飛行機もライセンス生産し、あとから改�造して燃料タンクを取り付けるなど勝手に改�良。戦地の整備兵にとってはありがた迷惑！

•  飛行機によっていちいち部品が違うので非能率で、空母上でネジをやすりで削って使ったりしていた・・・！

単体の性能が良くても 戦争には勝てない

•  航空機が戦力として機能するには、 大量生産＋運用システムが必要

運用システム

• 空母 • レーダー • 通信網 • 補給

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

日本では

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

その頃 アメリカさんは・・

•  開発者を空母に同乗させてた •  現地で何がおきるか、一緒に把握して改�良させていた

•  新技術のリーンスタートアップ

国産クラウドで

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

その頃 Amazonさんは・・

•  44兆円のEEコマースサイトをAAWWSSに乗せて、一緒にサービスを枯れ

させていた・・・！

利用者へのインパクト

最近よく見る比較広告

AA社より4400％安い！

AA社よりCCPPUUが早い！

現実

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  

現実

Amazon  Elas+c  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  

EC2相当のサービス

他社クラウド

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

EECC22相当のサービスを使った場合

他社クラウド

BIND

PosXix

MySQL

Backup

インストール時間 サーバー資源 が必要！

監視

squid

EC2相当のサービス

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  

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  

インストール時間０ サーバー（EECC22）の利用量削減

実システムでの比較（コスト）

AWS EC2 20台

ELB 2

RDS 2

Route53 1

CloudFront -­‐

SES -­‐

CloudWatch -­‐

S3 20GB

Total 約18万円／月

EC2相当

仮想サーバー 45台

約22万円／月

実システムでの比較（時間）

EECC22相当 4455台分の

セットアップ時間 4455台分の 運用時間

AWSでは

インフラにかかる時間とコストが減る！

サーバーのセットアップとメンテナンスに かかる時間が減って

EECC22以外のサービスが

システマチックに連携しているから

私が伝えたいこと

•  11点に拘る姿勢は日本人特有 •  それが、クラウドの様にシステム思考が必要なサービス開発には仇

•  クラウドの構築は車輪の再発明。それは得意な人に任せて、

使う技術の洗練に注力しよう！

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

予算

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

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

実際に案件単価は激減

クラウド前 クラウド後

SSII費用

保守・運用

ハードウェア

SSII費用

クラウド利用料

保守・運用

予算は減るが利益は上がる

クラウド前 クラウド後

総額は縮小

利益は 増加

SSII費用

保守・運用

ハードウェア

SSII費用

クラウド利用料

保守・運用

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

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

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

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

よくある懸念

クラウドって、 セキュリティが不安…�

一般的なシステムの脅威

攻撃者によるアタック

物理的アクセスによる データ盗難

データ漏えい

外部

内部

クラウド特有の脅威

仮想マシン

仮想マシン

仮想マシン

物理マシンを共有したら、 意図せず漏洩したりしないか

場所が分からなくて、 なんとなく不安・・・

AWSのオペレーターが情報をもっていったりしないか？

Amazonは何をしているのか？

AAWWSSのセキュリティモデル

外部 アタック

物理的 アクセス

データ漏えい

外部

内部 AAWWSSが 防御

利用者 が防御

仮想マシン

仮想マシン 内部同士の共有も、 明示しない限り禁止

第三者認証

•  ISMS(ISO27001) • PCI DSS Level 1 • FISMA-Modarate •  ISAE3402 SOC1 (formerly known as SAS70 type II)

テクノロジー

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

皆さまにご質問

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

なぜ大切なお金を銀行に預けるのか？

• セキュリティ – 社内より銀行の方が安全

• 可用性 – 預けた支店が事故を起こしても口座情報は保持

• 利便性 – AATTMM＋カードでどこでもアクセス

• セキュリティ – 社内よりAAWWSSの方が堅牢な物理セキュリティを確保

• 可用性 – クラウド側で高い耐久性を維持 （SS33のファイル耐久性は9999..999999999999999999%%）

• 利便性 – ネット越しにどこからでも簡単にアクセス

クラウドも、銀行と同じです

NASAと、御社とでは、 どちらがIITTインフラの

セキュリティレベルを保つ 仕組みが整っていると思いますか？

AAWWSSで、われわれの組織内の インフラよりもはるかに高い

セキュリティを保てるようになる

NASA  ジェット推進研究所（JPL）のシニア・ソリューション・アーキテクト  カワジャ・シャムズ（Khawaja  Shams）氏  hap://www.atmarkit.co.jp/ait/ar9cles/1301/24/news087.html

セキュリティを高めるために、

銀行にお金を預けることと同様

システムもクラウドに預けた方が、

セキュリティレベルが上がる

聞かれるポイント

•  ほぼ決まっている •  セキュリティ •  従量制 •  国産との比較

大切なこと

聞かれるポイントを、事前に想定しておく

相手の立場で、何がメリットになるのか考える

相手のメリットになることを、 わかりやすく、丁寧に伝える

伝える能力が

より大切に！

一人がカバーする範囲が増える

チームが小さくなる

私たちのAction!

•  毎週金曜日の夕方、22名のエンジニアが社内でLT＋UST配信

•  Yammerでリアルタイムにフィードバック

〜クラウドをやって分かったこと〜

11.. 調達モデルの変化 •  小さいチーム •  作らない技術の追求

22.. 日本のクラウドとAAWWSSとの違い •  システム思考 vs 一点豪華主義

33.. AAWWSSの導入�に必要なモノ •  予算→社内・社外に未来を示すこと •  伝える能力

本日のまとめ

まとめ

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

切腹しろ

という方は お申し出下さい

そうでない方は・・・

I suggest your Next Action!

Action! • 変化させよう！ –  変化しない周�りをなげくのではなく、 自分で変化を起こす方法を学ぼう！

–  周�りの一人に、あなたが進めたい技術の話を してみて下さい

•  変化を楽しんで、 SSIIは楽しい！未来がある！ というメッセージを一緒に発信しよう！

It’s your turn!