2013 デブサミ 「SIの未来ってどうなのよ？」
212 likes24,684 views
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/
2013 デブサミ 「SIの未来ってどうなのよ？」
- 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 をお伝えすることで、 答えではなく材料を ご提供します
- 9. 昔の合格発表
- 10. 今の合格発表
- 11. 大学向�けサービス 約 200 校 2004年 2011年
- 12. シェア 6600%%
- 13. ところが・・・
- 14. 必要なサーバー数 課題 無駄 必要なコスト 2月 8月
- 15. そこで、
- 18. 22001111年 AWS Solution Provider 22001122年 Amazon Partner Network最上位の Advanced Consulting Partner に認定
- 20. Action! by AWS
- 23. サイトダウンの理由 被災者： 非被災者： 救急医療など、支援 義援金やボランティ が受けられる場所を ア活動など、支援で 探す目的で きる方法を探す目的
- 26. EC2
- 27. 義援金受付システム
- 28. 負荷分散装置 ２０台の、物理的に離れた ２つのデータセンターに設置 されたウェブサーバー １日に５００万通送信できる メールサーバー 物理的に離れたデータセンター間で リアルタイムに同期し、かつ１時間おきに 環境構築22時間 バックアップを取るデータベース アプリ開発4488時間
- 29. タイムチャート： 33月1144日 日本赤十字社様との打ち合わせ 33月1155日 サイト復旧 33月1177日 義援金管理システム稼働開始
- 30. 事実 震災後の迅速な義援金の募集に 一役買ったのは、 だった！
- 32. 世間の論調 SIは必要悪だ SIは終わった SIは保険でしかない
- 33. データを見ても
- 34. SSII企業倒産件数 240 年間222211件 220 過去最悪！ 200 180 160 140 120 2010年 2011年 2012年
- 35. 厳しいのは 本当っぽい
- 36. 22000088年ごろの 私たちも・・
- 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. クラウドをやってわかったこと ①調達モデルの変化
- 60. NO!
- 61. • 顧客はSIerを必要としている • ただし、 SIerに求められるモノは変わる
- 62. 今までのSI のどが 渇いた！ ○×○×○×○×○ ○×○×○×○×○ ×○×○×○×○× ×○×○×○×○× ○×○×○×○× ○×○×○×○× 調達チーム 品質チーム ○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○ ○×○×○×○×○ ×○×○×○×○× ×○×○×○×○× ×○×○×○×○× ×○×○×○×○× ○×○×○×○× ○×○×○×○× ○×○×○×○× ○×○×○×○× バケツを 川から 水の量を 水の品質を 調達する係 水をくむ係 計る係 調べる係
- 63. これからのSI のどが 渇いた！ どうぞ！ H2O H H O アマゾン工場 （クラウド事業者）
- 64. ピラミッド型 • 「人が多い」ことが前提だった • 「コミュニケーション」が重要なスキル だった • 下請け企業の役割は、技術では無く 「人材バッファ」だった
- 65. クラウド型調達では • 非常に小さいチーム • つくらない技術≒使う技術 が重要に！ – 「組み合わせる」分子式の知識 • AWSのCDP • Heroku と EC2+SQS • Salesforce と S3
- 66. SIerの変化 • 分業モデル崩壊による下請けニーズの縮小 • 「コミュニケーション＜技術」が鮮明に • 人材バッファとしての役割は終了
- 68. 戦艦大和
- 69. ゼロ戦
- 70. 共通のポイントは？
- 71. 一点豪華主義
- 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費用 保守・運用 増加 クラウド利用料 ハードウェア 保守・運用
- 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社員も顧客のデータに アクセスできない
- 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. 本日のまとめ
- 125. 切腹しろ という方は お申し出下さい
- 126. そうでない方は・・・
- 127. I suggest your Next Action!
- 128. Action! • 変化させよう！ – 変化しない周�りをなげくのではなく、 自分で変化を起こす方法を学ぼう！ – 周�りの一人に、あなたが進めたい技術の話を してみて下さい • 変化を楽しんで、 SSIIは楽しい！未来がある！ というメッセージを一緒に発信しよう！
- 129. It s your turn!