DMM英会話始めました

英語力向上の必要が出てきたので、２ヶ月ほど前からDMM英会話なるものを始めた。特に結論はないけど、当時こんな事を思っていたんだな〜と振り返るためにメモ。

いまから始められる「ネットで英会話」♪オンライン英会話ならDMM.com
f:id:seikoudoku2000:20130706220248g:plain


◎DMM英会話にした理由

  • 比較的新しいサービスなので敷居が低そう。
  • 初月980円 + 最初の更新月は4900円だった。
    • ただ、７月の更新から高くなる(というか通常価格になる)ので悩み中。
  • 国際色豊か。
    • 東欧の国々の人とかブラジル人とか、普通に生きてるとなかなか話す機会は無いよな的な。
  • (元)社会人教師、在宅妻教師もちらほら。
    • 自分のそもそものコミュニケーション能力的に、大学生よりそっちの方が安心できそうww。


◎やっていて思った事

  • とにかく話せない。
    • 嫁からは、「日本人相手でも初めての相手は人見知りして上手く喋れないのに、そりゃ、そうでしょ」というグウの音も出ない指摘を受ける。。が、話せないと困っちゃうのでそうも言ってられない。
    • 英語の記事を初見でそれなりに音読できても、それに対するちょっとした感想ですら言葉に詰まる事が多い。こっちが止まると、当然向こうも喋るのをやめるので、ヒヤリングだけできてもあんまり意味ない。
    • 自分の普段話している/考えている言葉を英語にするという所に注力したほうがいい気がする。
      • 例えば、自分の仕事をITに詳しくない人にどう説明するか？とか。
      • 「村上式シンプル英語勉強法」で紹介されていた、"自分に関していろいろなシナリオに応じての話を100通り用意しておく"、"興味のあることを英語で話せるようにする" って辺りがかなり重要と思った。
  • レッスンするだけで満足しがちw。
    • レッスン中は自然と緊張しているので、それだけで何かを成し遂げた気になってしまう。要注意！復習しないとほぼ何も残らない。
  • でも、復習のやり方がよく分からない。
    • アーティクルレッスンとかであればそれを読み直せばいいけど、上手く喋れなかったこととかは、それ自体が形に残らないので振り返りずらいし、逆に逐一英作文するというもはコスト高くて続かない。
  • 最初の頃は30分くらい前から緊張してPCの前でそわそわww。
    • とりあえず回数重ねることで、ここの苦手意識は克服できた気がする。

引き続き、試行錯誤しながら頑張るのみ。また、何ヶ月かしたらブログに書いてみよう。

村上式シンプル英語勉強法―使える英語を、本気で身につける

村上式シンプル英語勉強法―使える英語を、本気で身につける


サンワサプライ USBヘッドセット MM-HSUSB10SV

サンワサプライ USBヘッドセット MM-HSUSB10SV

AWS Summit Tokyoの１日目に行った #awssummit

AWS Summit Tokyo、１日目だけ参加。
今年が初参加で先日初参加したJAWS DAYS と似たような感じなのかな〜と思っていったのですが、数倍、いや１０倍くらい？の規模だったのでちょっとビックリでした。
JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug - seikoudoku2000のブログ

以下、メモと感想。
特にテクニカルセッションは、講演だけでは理解できなかった所も多々あったので、復習がてら関係ありそうなリンクをペタペタ貼っといた。
インフラ/ネットワークのことはフワッとしか分かってないな〜というのを痛感したり、Netflixが障害を日常に組み込むために意図的に本番で障害を起こしてるという話を聞いて、言いたいことは分からなくもないけど、、いまいち咀嚼しきれない感じで、自分は守りに入ってしまっているのか？？と自問自答したりw。きっと講演の内容/出てたキーワードをしっかり消化できれば、「月〜木はGame Dayやりましょう」と上長に提案できる男になれるはずなので、もうちょっと頑張って勉強してみる。（おお、そのやり方いけてるからやってみよう！と思った人はどれくらいいるのだろう？？）

資料と動画

ここに一通りアップされている
AWS Summit Tokyo 2013 レポート セッション動画・資料一覧| アマゾン ウェブ サービス（AWS 日本語）

基調講演

いわゆるAWSとは、、 + 事例の話。
その中で、Cycle Computingという会社の偉い人が少し話をしていたのですが、個人的に最近読んだ「ジェノサイド」という小説の世界の話とリンクしていて、ちょっとワクワクしました。webやエンタープライズのシステムをAWSに置き換えるというのは色々と聞くようになってきましたが、こっち方面だとこれからまだまだ未知のことが起きそうだな〜と。全くその世界のことは知らない状態での妄想ですがw
ちなみに↓は「このミステリーが凄い」第１位に輝いた名作で、とても面白かったのでオススメです。
ジェノサイド

  • Cycle Computing
    • AWSのHPCを活用
    • 製薬や遺伝子研究向けのHPCクラウドを提供
      • オンデマンドで調達できるという特性がとても有効。
      • 39年が11時間に！
      • ジェノサイドは進化した人類が新しい薬を開発するためのソフトを作ったり、通信の暗号を解読(膨大な計算が必要)したりという話だったが、HPCがそれを実現するのか？？？、、、(と勝手にドキドキ)

ハイブリッド構成を支えるAWSテクノロジー

  • AWSだけではできないこともある！
    • 片側に今までのDC , 逆側にAWS
  • ハイブリッドのユースケース
    • 開発で使う
    • DRで使う
      • データの同期どうする？
    • アプリケーション単位での順序置き換え
      • 監視とか大変だよ
    • 一つのシステムをハイブリッドに
      • レイテンシ、帯域の問題
  • VPCシステム構築のポイント
    • ネットワーク分割のベストプラクティス
      • ELB, RDS, Elasticacheなど、ログインの必要のないプロダクト用のサブネットを準備する。/22, /24 などで台数を確保できるように。
    • AWSのAPI接続にはインターネット接続が必要なので、DNS経由でアクセス！
    • Direct Connect
      • 自分たちでコントロールできるネットワークを持てる。
  • ファイルコピー
    • S3使おう
      • リージョン確認
      • 数十MB以上ならマルチパート化
      • 並列転送
      • 無駄なオペレーションしない
  • サードパーティーの提供する運用支援サービス
    • 環境構築
      • Puppet, opscode(chef)
    • 監視
      • App Dynamics, new relic
    • ログ蓄積
      • splunk, loggy, treasure data

クラウド利用もハンズ流。POSシステムもAWSで

  • クラウド導入に向けて
    • 「クラウド」じゃなくて、「超可用性データセンター」みたいな名前だったら良かったのに、、
      • 漠然としたものという先入観を持たれてしまう。
    • サービス継続性の話、SLAの話は出るよね。
      • でも、今、御社はどういう数値ですか？と聞くと、大体答えが返ってこないww。
        • 「時々は止まってしまうかな〜」みたいな感じ。
    • イノベーティブな進化があった時に多くの人がネガティブな反応をするのは仕方ない
      • 携帯電話、webメール、（多分データセンターも）も最初は受け入れられなかったが、今は当たり前に業務で使われている。
  • 導入の話
    • 震災を機にDRの観点からAWSの導入を始めた。
    • 無難な所/ぽしゃっても影響ない所から始めるのが定石かもしれないが、それって意味あるの？
      • 最後までやりとげられる？途中でダメになったら二重運用だよ。
    • 基幹を含めた本丸からいく！
      • それがダメだったら撤退する。
      • リーダーがどこまで本気かは言葉で伝わる。それに合わせた結果が部下から上がってくるよ。
  • その他



AWSクラウドで構築する、ワールドクラスの分散クラウドアーキテクチャ

結論：マルチAZがおすすめ。マルチリージョンはとっても難しいから、明確な目的があってどうしても必要な時だけ、制約を理解した上で取り組むべし。

  • リージョンとアベイラビリティーゾーン
    • リージョン > アベイラビリティーゾーン
    • マルチAZはAWSのコアコンセプトの一つ
    • マルチリージョンはAWSのビルディングブロックの範囲外であり、非常に難しい
  • マルチリージョンが必要なユースケース
    • UXの向上
      • データのローカリティの保持
      • Tsunami, Aspera, Cloudpackなど
      • Route53のレイテンシーベースでのルーティング
      • データの近さを意識してアーキテクティング
      • データのリージョン間での受け渡し
      • SQSを使ったpub-sub
    • ディザスタリカバリ
      • AMIやデータをリージョン間でコピー。非常時にはそっちを起動。
      • Route53の重み付け切り替えでフェイルオーバーを容易にできる。
      • AWS内のプロダクトで完結するので比較的やりやすい
    • 非常に高い可用性が必要
      • NASA (GlusterFSをマルチリージョンで使ってる)
      • Netflix
      • Obama For America
  • 合意プロトコル
    • 分散システム内で合意が必要
    • リーダー、マスター選定
    • 分散ロック
    • Paxos, ZooKeeper
    • 耐障害性の維持
      • データセンター間では非同期レプリケーションになる。
      • 同期でやろうとすると、1トランザクション辺り70-80msはかかる。サービスとして厳しい。
      • ここが障害復旧時のリカバリーで難しい所
  • 事例
    • NASA
    • Netflix
      • Cassandraを利用
      • QUORUM(X台以上から応答があった時点で書き込み成功とする) + Geo Replication
        • 難易度が超高い
      • Fail fast & silent
      • Netflix内部のテクノロジーで色々カバーしている。
  • マルチリージョン化のポイント
  • テストどうする
    • GameDay！！
    • 実際の負荷、本番環境
      • ほんとの本番環境
        • このセッションを聞くまで、本番環境相当の環境を準備してやるものと勘違いしてましたが、そうじゃないんですね。すごい&恐ろしい。。
    • Netflix の Chaos Monkey
    • 障害は避けられない。受け入れて日常へ。
    • リカバリーオリエンティドコンピューティングパターン
    • ボーアバグ、ハイゼンバグ


↓も関係してそう。

Tatsuhiko Miyagawa's Podcastを聞いて思ったこと　#bulknews

最近、遅ればせながら話題になってた宮川さんのpodcastを聞いた。
Tatsuhiko Miyagawa's Podcast

第５回のmatzさんとのやり取りの中で、なるほどな〜と思った言葉があったのでメモ。

オープンソースは安定すると死んでしまう。
Javaなどを引き合いに出して安定性云々を言う人は、Java自体にValueを見いだしているのではなく、その上で動くプロダクトにValueを見いだしている。
しかし、Rubyを作っている我々からするとRuby自体がValueなので、そこに安定性を入れることは受け入れられない

というような感じ。

で、ふと思ったのは、巷で、うちの会社では技術が評価されない云々の話をよく聞く気がするけど、状況としてはこれに近いのかな〜と思った。
技術評価してくれ云々の思いの裏にあるのは、技術が会社の利益につながるはずという思い(これがうまく数値化しずらいのも問題)に加え、技術者/エンジニアとしてやっていくには自分を安定させてしまう(=新しいものを取り入れない)と死んでしまうかもしれないという危機感なんじゃないかなと。

従来、新技術の導入にあたってはその技術が会社の利益にどうつながるかというロジックを作るのが一般的でしたが、西條剛央さん曰く「価値は関心に応じて決まる」ということなので、評価する側にエンジニアとして死んでいくということに対することに関心を持ってもらうというのも一つの手段なのかなと思いました。
一方でcookpadのような、なぜそんなバリバリいけるんだ！？と思う会社はそっちのへの関心も強いのかな〜と勝手に思ったり、そういう関心の違いのことを会社のカルチャーと呼ぶのかなと思ったり。

35歳定年説なんてものは信じてませんが、実際近づいてくると色々と考えてしまいます。（まだ数年ありますがww）

構造構成主義 - Wikipedia

JAWS DAYS 2013に行ってきた day1 #jawsdays #jawsug

↓に行ってきました。
JAWS DAYS 2013 | 2013/3/15（金）～16日（土）東京ビッグサイトで開催！
一週間経った今でもちょいちょい思い出すくらいにインパクトの強いイベントだったので、今更感は気にせずにブログ投稿。

ユーストのアーカイブ
jaws daysのメインチャンネル

メインどころはPulblicKeyで素晴らしいレポートがまとめられているので主に感想など。

Obama For America on AWS

これを生で聞けただけでも休暇とっていった価値はあったな〜と。といいつつ、ゲームデイでインフラの手順書作るとかデータセンタ移設を９時間でやったとか、自分の常識とはかけ離れすぎてて逆に中々腹落ちしてきませんでしたが、他の人のtweetを眺めたりPulblicKeyのレポート読みながら復習したりしながら、そういうことか！と後からジワジワときましたw。
あとはAWSの話をした時によく聞く反例として、
・ミッションクリティカルな所はダメでしょ？
・セキュリティ大丈夫なの？
というようなのが自分の周りでは多いですが、
・選挙当日に絶対落ちてはいけないアメリカ大統領選挙選で使われていました。
・1分あたり40万ドルもの寄付を取り扱って問題は起きていないそうです。
・災害に備えたデータセンタ移設が９時間で行えたそうです。
みたいな回答ができるなと。





クラウドファースト時代に求められるシステムインテグレーター像とは？

自分はSI業界で働いているわけではないのですが、とても聞き応えのあるパネルでした。
自分がクラウドってとんでもないものだな〜と初めて感じたのは2010年の楽天techの時の日経コンピュータ中田さんの話を聞いた時だったと記憶していますが、ここで語られていたことがいよいよ広まってきたんだなというのを実感できました。そして、その頃は全く知りませんでしたが、大石さんは2008年から社内サーバ購入禁止令を出していたわけで、自分が海の向こうでえらいことが起こっているようだぞと知識として知った時には、既にそっちに舵をきっていたわけで、あの頃にそういうアクションがとれるってのは凄い行動力だな〜と。
これからの時代に求められるのは「使う技術」って言われても、それだけだとどんどんコモディティ化していきそうだし、これからどうやったら生き残れるんだろうか？という思いが頭を占領して不安になったりしつつ、クラウドという波に早くから乗っていった人たちが今になって花開いているのをみて勇気づけられたりと、自分にとっては大きな問いを投げかけられた気分のセッションでした。まあ、答えなんてないんでしょうがww。

  • 自分のtweet






クラウド時代の個人に必要な変革とは?

いい意味であっちいったりこっちいったりしたので、あんまりメモとかとれなかったですが聞いてて面白かったです。先のセッションとは違ってゆるい感じを保ちつつ、でも凄くコアな話がいっぱい出てました。
印象に残ったのはTreasure Dataの太田さんの「AWS使ってるとこいつらAPIの切り方分かってるな〜と思う」という(若干の上から目線の)発言で、AWSってやっぱイケてるプロダクトなんだな〜というのを改めて感じさせてくれました。

（自分が思ったことなのでこの例が正しいかはよく分からないですが、）最近、↓のような記事が公開されていましたが、
DynamoDBにおけるスループット超過対策 〜 Fallback-Queueingパターン ｜ Developers.IO
これもオープンソースのNoSQL製品を導入しようとすると、ミドルウェアの選定、ハードウェア構成の検討〜購入、パフォーマンステスト、障害時のリカバリー方法の調査等々、それだけで数ヶ月の準備期間が必要そうな所を、
DynamoDBではこれだけお金払えばこれだけのスループットは保証するよ & 他のサービスと併用することでスループット超えた分もリカバーできるという形での提供になっているわけで、目から鱗な感じを味わいました。
一方で、AWSが一人勝ち状態で他のIaaSベンダーはそれに追随している形なのがどうなんだろう？みたいな話も出ていましたが、これは確かにな〜と。ベンダーロックインされないようにオープンソースを使いこなせるようになろう！みたいな所から、やっぱAWSが楽&いいねってなりつつあるような感じもするので、次はどういうトレンドが起きてくるのかな〜と。そういう所をふまえていくと、最終的に古典を読もう！って話につながるのかなとも思ったり。

  • 自分のtweet



LT (一部抜粋)

Redshiftの衝撃・性能は？用途は？Hadoopとの関係は？実際どうなの？ Hapyrus 藤川(@fujibee) さん

RedShiftって言葉だけは知っていつつ、実体はほとんど知らなかったので、短い時間の紹介でしたがかなりイメージは湧きました。一方で、hadoopは既存バッチの置き換えという課題があってある意味分かりやすかったのですが、RedShiftが既存のDWHを1/100のコストで実現できると言われても、既存のDWHを使っていない層(=自分)にはまだピンときづらいものがあるので、その辺の話をもっといい感じにブレイクダウンしたりラップしたりしたプロダクトなりが出てくると、コストの話と合わさってもっとドーンといくんじゃないかなと思ったり。

AWSはとんでもないものを盗んでいきました @shimy_net

アマゾン芸人恐るべし。。ムダに技術を使って面白いことをするというコンセプトは秀逸だなと。
内容もめちゃめちゃ面白かったです。SlideShareのPV数も半端ないですね。
今の所、AWSは仕事での出番はないので、A1グランプリを目標に頑張って勉強していきたいと思いました。



(多分)２日目に続く。

(第０回?)新宿鮫に行ってきた。 #jawsug

Amazon Web Services 勉強会（新宿） on Zusaar
今の所、仕事で導入するあてはないけれど、ただただ面白そうなのと、これからのキャリアプランとか考えると必須のスキルだよな〜という所で、CDP本を買ったりしつつ勉強中な所に見つけたので行ってみました。

ちなみにタイトルの"新宿鮫"というのは、この回の主催者の吉田さんがこれから立ち上げようとしている新宿コミュニティの仮称だそうですが、いい響きだなと思ったのと、普通に今回の資料の先頭に記載してあったので拝借。

最初に感想を書くと、本編の中ではAWSの共有責任モデルの話&コイニーの導入事例が印象に残りました。セキュリティって大丈夫？くらいの認識だったのが申し訳ない感じです。。逆に自分は何でオンプレの方が安全だと思っていたのだろうかと自問自答してしまいました。個人利用では中々気にすることはないですが、会社に導入するとなると必ず話題になるはずなので、聞かれた時用にしっかり勉強しておく必要があるなと。
あとはAWSカルタが面白かった。カルタデータ公開されたら社内の興味ある人と一緒にやってもいいかもしれないww。
懇親会はcloudpackさんのビール奢り(しかも余った分はお土産でいただきました。あざっす！)&500円でピザ。
人数少なめで、素人ながらに吉田さんから色々と聞けてとても勉強になりました。
来る日に向けて、楽しみながら、しっかりと知識を蓄えたり、ちょいちょい使ったりしつつ、時間が合えば新宿鮫にも参加してみたいなと思った次第です。


以下、本編のメモとか資料とか。

趣旨、AWSの概要とか

AWSカルタ





セキュリティに関して

  • 共有責任モデルの採用
    • インフラはAWSが責任を持つ。
    • その上で動くアプリに関してはユーザが責任を持つ。
  • AWSのセキュリティ
    • データセンターの場所は秘密！！
    • 第三者認証。
  • 利用側のセキュリティ

コイニーの導入事例

  • PCI DSS v2.0
    • クレジットカード会社５社が制定したセキュリティ基準
    • アメリカでは結構浸透している。
      • データが漏洩した場合、PCI DSSの運用をちゃんと行っていたことを証明できれば、被害の訴訟を避けることができる(州がある)。これがインセンティブになっている。
  • 登場人物
    • Coiney(サービス提供者)
    • cloudpack(AWS導入支援)
    • Payment Card Forensics(監査会社)





※懇親会で絶賛されてた#devsumiでのサーバーワークス 大石さんの講演資料

Amazon Web Services クラウドデザインパターン 設計ガイド

Amazon Web Services クラウドデザインパターン 設計ガイド


Amazon Web Services クラウドデザインパターン実装ガイド

Amazon Web Services クラウドデザインパターン実装ガイド




2/28 追記：
試しに"新宿鮫"でぐぐった所、大沢 在昌さんのシリーズ小説があることを知った。。

新宿鮫 (光文社文庫)

新宿鮫 (光文社文庫)


毒猿　新宿鮫ＩＩ: 2 (光文社文庫)

毒猿　新宿鮫ＩＩ: 2 (光文社文庫)


屍蘭　新宿鮫ＩＩＩ: 3 (光文社文庫)

屍蘭　新宿鮫ＩＩＩ: 3 (光文社文庫)

デブサミに行った その２ #devsumi

前回のエントリーの続き。

最初２つは言語の話。長年の付き合いのJavaと最近学び始めたRuby。
付き合いの長さ(?)、自分はまだまだJava愛が強いなと感じることができましたww。

Ruby2.0 by Matz

  • ruby 生誕20周年！
    • 1993年2月24日に開発開始
    • 1995年12月21日に公開ver 0.95
    • 1996年12月に1.0
    • 以降順調にバージョンアップを重ねたが、1.8と1.9の間がかなり間が空くようになった。
      • 心理的な障壁。

  • とうとうやってきた2.0
    • RubyConf2001 で始めてruby2に言及
      • 第一回。31人の参加者。
    • 新VM、新GC、埋め込み、ネイティブスレッド
      • 2001年に考えていたことは1.9で実現された

  • 現代のRuby2.0の起源
    • ruby conf2003で言及していたのが最初。
    • 壁を乗り越える要因
      • 20周年！(誰に言われたか忘れたけど、強く後押しされた。)
      • ADD(=Aniversary Driven Development)
      • キーワード引数、メソッドコンビネーション、セレクターネームスペースが2011年位にできあがってきて、いけそうな気がした。


Java! 日本オラクル 寺田さん

寺田さんの話を聞いているうちに自分の中のJava愛が目覚めてきて、普段はあんまりやらないんですが、頑張ってつぶやいてみました。














QA@ITの事例 西村さん

GitHub時代の開発委託とは？ デブサミの資料を公開しました - QA@IT公式ブログ



後半のパネルでメモった内容を補足。


Q.技術的負債、プロト作成について
負債を溜め込んででも開発速度を極限まであげるべきでは？
離陸しなければ、そもそも開発が継続しない。プロトを捨てる必要はあったのか？

A.うらしまさん
ケースバイケース。今回に関していうと、ローンチ = 開発終了というわけではなく、ゴールが明確ではなかった。この状況では、ある程度、きれいなものを積み上げていくしかなかった。
プロトは何を作るかを理解するために作ったもの。三回作れば勝てる仮説。

A.西村さん
テスト無いプロダクトで幸せになった人はいない。 by うらしまさん
(あとからの機能追加がすごく大変。メンテコストが高くなってプロダクトが死んでしまう。)



Q.これって特殊解なんじゃないの？

A.角谷さん
プロジェクトは全て特殊(そうじゃなかったら980円/月とかで提供されるでしょ)だけど、そこは掘り下げずに。
ジム・コブリン：三回起きたらパターン。二回だとcoincidence。一回だとaccident。
今は特殊かもしれないが、そういう潮流は肌感覚として感じている。これからあり得るんじゃないか。


朝のセッションで日本は付加価値をつけるIT投資が苦手だが、そこを伸ばしていかないといけないという話がありましたが、こういう事なのかな〜と思った。SI云々の話はよく聞くけれども、アメリカと比較して日本が全然伸びれていないということは、それだけの伸びしろを秘めてるとも言えなくもないので、逆にチャンスは転がっているんじゃないかと思ったり。
個人的にちょっと気になったのは、西村さんがpull-req送った話や、Github云々の話も多く、ツールにフォーカスあてすぎかなと感じました。本質的/普遍的な言葉で説明がもうちょっとあったら、腹落ちの度合いも増した気がします。
あとは角谷さんの↓がちょっと気になります。。

デブサミ2013に行った その１ #devsumi

Developers Summit 2013 の１日目だけ参加しました。

資料は↓に適宜アップされていく模様。
デブサミ2013、講演関連資料まとめ：CodeZine

エンタープライズ、ソーシャル、スタートアップ 3つの世界 玉川さん（司会）、三谷慶一郎さん、naoyaさん、孫泰蔵さん


今回はこのセッションが圧倒的に印象的だった。パネルというよりは３人の凄い人が色々と喋ってたという感じでしたが、玉川さんの問題提起も興味深かったし、何より、孫泰蔵さんの話が強烈でした。

東アジアベンチャー生態系の話等夢見心地にさせてくれる話もありつつ、自分的には、手を変え品を変え今がいかに恵まれた、チャンスの多い時代であるかを語っていたのが、とても心に染みました。
時代の変化や技術の進化に対して、会社/個人ともについていかなければダメになるという危機感駆動で変化を促す話が巷には多いような気がしますが、それだとどうしても変化や進歩に対して（わずかながらにでも）負の感情を抱いてしまう。

が、孫さんのように、「それによっていい時代なったから挑戦しようよ！」と言ってもらえると、全く違う気持ちでチャレンジ心や向上心が持てるな〜と感じました。何かを学んだりする時も、焦りながら勉強するより、好きでワクワクしながらやってるほうが楽しいし長続きする。
そういうモノの見方に気付けたことが一番の収穫だったと思います。

  • 玉川さんからの問題提示
    • 日本のIT業界は二つの世界に袂を分かった！？
    • エンタープライズ系
      • 大資本、高品質、高可用性、高コスト、Information Technology
    • web, social系
      • 低コスト、スピード重視、Internet Technology
    • プラスで、スタートアップの登場。
      • スタートアップ元年と言われた2012年
    • 他の世界と自分の世界を見比べることで見えてくるものがあるのではないか？
    • 良い人生とは？ ワーク・シフト ― 孤独と貧困から自由になる働き方の未来図〈2025〉　

エンタープライズのいままでとこれから by 三谷さん
  • エンタープライズの特徴
    • 省力化、自動化
    • 対象はバックオフィス業務中心
    • 業務内容がかっちりしている方が自動化がはまる
    • 信頼性、安全性
    • 要求収束と大規模PMの安定的推進が鍵
    • こういった需要がなくなることは無いだろう。
  • IT投資の推移
    • 日本のIT投資は全然伸びておらず、アメリカとの差は開くばかり
      • アメリカは80年代は投資効果はなかったが、2000年代はぐいぐい伸びた。日本はその逆。
    • 80年代の投資は省力化・自動化を対象にした投資。アメリカは苦手で日本が得意。
    • 2000年代の投資は付加価値向上を目的としたIT投資がアメリカは上手い。日本は苦手。
    • が、80年代のモデルは一巡すると後が続かない。2000年代のモデルは市場がどんどん拡大していっている。
      • これがIT投資額の推移の差に現れている！

  • 新しいパラダイム
    • 人間のやってることをIT化するのではなく、ITでしかできない付加価値を生み出す必要がある。
    • ユーザーとともに構想するデザイン型人材が必要！
    • 他の世界(web、スタートアップ)では当たり前！？そういった世界との協調が重要。

webサービスの世界 by naoyaさん
  • 二つのwebサービス
    • 既存のビジネスをITで提供
      • EC,交通予約
    • ITそのもので価値提供 ※今回はこっちにフォーカスをあてる

  • これまでの展開
    • Googleの台頭
    • web2.0 へ（Googleがやらないところじゃないと潰される）
    • Facebook
    • Post PC （スマフォ、タブレット）
      • Post PCの時代は既にきてる！

  • PCインターネット
    • 儲かったのはgoogleだけ
      • 広告資本をインターネットに取り込んだ
      • （他の儲かったのは既存ビジネスの持ち込み組）

  • 現状の課題
    • モバイルプラットフォームの寡占、アプリストアの飽和
    • 国内市場の相対的縮小
    • webの大衆化

  • 世界を変えていく要因
    • モバイル
    • アジアの興隆 スマフォの普及による。
    • エンタープライズのコンシューマライズ

  • これから
    • サービス開発
    • 建前のないベストプラクティス
    • モバイルの波には抗えない
    • webの理想を追い求めることはできるのか？？


孫さん
  • 年間投融資総額の推移
    • 2006年の半分、アメリカの1/20。IPO件数もorz...
    • が、全く悲観的になる必要はない！
    • こういった統計資料に新しいムーブメントは反映されてない。
      • ex. 日本を代表する企業の平均値である日経平均は10年前よりも下落している。が、全ての企業の平均としては57%の企業は株価が上がっている。

  • 誰でもスタートアップできる時代！スタートアップムーブメント！
    • クラウド環境、オープンソース、モバイル
      • 10年前のラグナロクの時代、、設備投資に三億円必要だったが、五千万しか集らずorz。ログインゲームと言われた。。
      • 試しに今AWSで同じことをやろうとした場合を見積もってみたら15万円/月！
    • ダウンサイドリスクはほとんど無い。
    • でも成功したら世界中へ！

  • EXIT戦略
    • M&Aが主流。
      • IPOが少なくても関係ない！

  • 起業環境
    • シリコンバレー
      • 17000社できて、12000社がexitしたり潰れたり
      • 毎年5000社増えてる
      • ベンチャー生態系ができているから
    • 日本
      • 砂漠みたいな感じ
      • 補助金は砂漠に水を蒔くようなもの
  • 孫泰蔵さんの野望
    • 2030年までにシリコンバレーのようなベンチャー生態系を東アジアに作りたい！！
    • 韓国や中国にもそういう動きはある
    • インドネシア/シンガポールにもある
    • MOVIDA School

  • バンドを組むようにスタートアップしよう！！
    • 起業者の人格 + 動くプロトを見て、500万円くらいはぽーんと出すよ！
  • サービス作りに関して
    • 英語で作れ！
      • 言葉が使いこなせないから、言語に依存しないUXができる。
      • 日本語で作ると日本の暗黙のコンテクストが入り込んでしまう。
      • インド人の英語、シングリッシュ（シンガポール英語）等、英語の逆輸入も始まってる？日本人もみんなで話せば、、



今年のデブサミのお題のAction!はすぐには決められませんが、、とりあえず出来ることからということで、AWSをもっと勉強するべくポチってみた。仕事で使ってみたいな〜。

Amazon Web Services クラウドデザインパターン実装ガイド

Amazon Web Services クラウドデザインパターン実装ガイド