JAWS DAYS 2013に行ってきたよ
アマゾン ウェブ サービス（AWS）をご利用いただいているユーザーが交流しあうコミュニティ「JAWS-UG」が全国から集まり、お台場、東京ビッグサイトにて「JAWS DAYS 2013」を開催いたします。
JAWS DAYS 2013 | 2013/3/15（金）〜16日（土）東京ビッグサイトで開催！
もともとは知らなかったんだけど、知り合いが行くということでイベントの存在を知ったのが先日。それで事前受付をしようと思ってページを開くと「受付終了しました」
orz...
でも、その知り合いが確認してくれたこともあり、名刺を持っていけば見れると！！！！なんですとぉ！
@arcanum_jp JAWS DAYS 当日受付 OK との事です！ 名刺2枚持って受付へ。
— 志賀 慶一 しが けいいちさん (@Keiichi_SHIGA) 2013年3月16日ごきげんようクラウドエンジニアの種を蒔く
途中で参加でした。学校の授業でClouVOというチャットの変型版のサービスを思いついたという話。チャットの言葉を音声として出してみればどうなるか？というのが発想の原点でもともとは端末のsayコマンドが面白くてみんなではまったのがそのサービスにつながったという。
アプリを作るだけじゃなくてこのサービスが運用された時の試算、そして黒字化する方法まで考えている。例えばユーザー数１０万人、アクティブユーザーがその６０％、一日発言数３０ぐらいとするとAWSに支払う年貢は年間１１０万円！なにぃぃ！こりゃ個人でチマチマなんかできないね。ということで黒字化するにはキャラクターボイスで課金、フレーズスタンプで課金するとか。
AWSを活用して小さなチームで、世界で使われるサービスを運用する方法
ぬーらぼのソメダさん（すみません、漢字知らずです）BacklogとCacooというサービスについての運用ノウハウ
仕事を楽しく。チームを明るく。まとめて実現
http://www.backlog.jp/
Web上で図の作成＆リアルタイムコラボレーション
https://cacoo.com/lang/ja/
データベースはRDBMSかKVS系かどっち使うかは要件次第。たとえばお仕事に使うシステムでは一貫性が大事なのでKVSではなくRDBMSなど。ちゃんと考えようねとか。
アクションファーストという言葉。価値提供の重要性、まず行動をとってからインフラをどうにかする。不確実な未来に対してコミットしすぎない。これ大事。インフラはあとからどうにかする。これがクラウドを使うメリット。インフラをどうするか考えてからアクションじゃなく、発想の転換が必要。それはサービス展開のスピードをキープする。
AWSを使っていると自動化できる部分は多い、たとえばfabricやcuisineを使う。ツールを使うことによってステージングをオートメーション化。gitが更新されるとジェンキンスがテストしてそこを通ると各環境へデプロイ（ここでfabricを使う）など。でも過度な自動化はしない。自動化そのものが目的にしない。
異常があったらツールに読んでもらう。障害を再発しないために検知項目を増やすのと監視のクオリティを保つ。それはあまり頻繁に呼ばれるとオオカミ少年的になってしまい、人間が異常をスルーしてしまう。なので検知する監視のクオリティは常に保つようにする。
あと、サービスに障害は必ず出る。ユーザーさんがその対応にリーチ（知ること）できるように様々な方法をとる。サービスサイトのトップ画面、ツイッターから・・・
札幌とVPCと私
VPCの事例。お客様の環境に構築されていたAPサーバーが負荷に耐えられなくなってきて初めはAPサーバーを購入しようかという話になっていたが、そのときAWSって何？となった。その環境ではRDBだけは社内に設置しておきたい、（お客様によってはDBをどっかに預けるのは嫌だというのは多い）そういった環境のため、AmazonVPN接続を使い処理はAmazon、DBは自社という要件を実現。VPCを使えばこういったハイブリッドな環境の構築が可能という話
VPCにすると色々なメリットがある。たとえば固定IP。EC2-ClassicではEC2が再起動するとIPが変わってしまうなどがあり、そこいらを踏まえた仕組みを構築する必要があるが、VPCなら大丈夫。セキュリティグループの移動も簡単！
・・・といったVPCラブな話題。
http://www.slideshare.net/HiroshiKoyama/jaws-days-2013-vpc
ってこの方、ITホールディングスの方？
コミュニティファーストのススメ
コミュニティってなんだろう、例えば一人のリーダーがいて、複数のメンバーがいるという構成ではリアクションをもらえるのはリーダーのみ。このやり方は会社など一部の集団では機能する。しかしコミュニティってのは、管理人のいない共同作業
そのコミュニティの中の個々の人はお金や会社からの強制とかで動いているわけではない。自分から何かをしよう、そういう考えでいろいろアクションを起こしていかないと物事はよくならない。それらはダニエル・ピンク著の「モチベーション3.0」などでも言っている。お金をたくさんもらえればパフォーマンスがよくなるか、そうではない。
コミュニティはコピーできない。
あと、コミュニティを運営してみてのノウハウ。
この辺、考え事しながら聞いていたため、失念
行ってみて
実は初めに見た学生さんの発表が今日のメインだった。学校の勉強のなかで思いついたサービスであるがどんなものを思いつくんだろう。どんなきっかけだったんだろうか。それは先に書いたように端末のsayコマンドからチャットの文字を音声で出したら面白いよね。たったこれだけ。しかも作って終わりじゃなくてそれを収益化するにはどうするかといったアイデアも披露。作っては終わっている僕とは雲泥の差です。頭が下がる思いです。最後にあった音声をテキスト化するってサービス、あれは実はそういったものがあったら使えるよねって会社で話し合っていた時期があって、やっぱあのアイデアはよかったのかもとか思ったり。
コミュニティの話は刺さったり刺さらなかったり。外発的動機、内発的動機の話が出たが、こういったイベントに来る人はもともと内発的動機で来ている。外発的動機（この話ではお金が主に言われていたが）がなくてもいいよね、外発的動機別に不要じゃん。という感じだったけど、内発的動機を作るためにはどういったことが必要か、そもそもコミュニティに興味もない人にどうやったら入ってもらえるか、（会社の話とコミュニティの話がごっちゃになっています）そういった事が気になった。多分時間をかけてやる泥臭い事なんだろうけど。外発的動機ってのはお金以外にも承認であったり人とのかかわりであったりと色々ある。多分コミュニティ内で無意識に行っているようなその辺がどういった事か知りたいと思った。そもそも個人活動で何をするにもボッチでコミュニティって言われても一歩覚めてた目で見てしまうような僕にはあまり関係がない話なのです。ではなんでこのTrackに来たの？
コミュニティを運営するノウハウはいろいろと面白かった。自分も以前１回だけど勉強会を開いたことがあって、その苦労がそのまんまあったり、AWSを使い始めるようになると昔はサーバールームに男どもでこもってっていうのが女子会の女子に囲まれてお酒が飲めるようになるなど・・・サーバールームにこもるって・・・最近の俺じゃないですかぁ！ユーザーグループを作るようになったきっかけとか、ほんと些細なかかわりがはじめだったんですね。
こういったユーザーグループの話はどっちかというと技術者そのものよりも会社の管理職やもっと上の方の人に来てほしいと思う。なんでかというとこのイベントに来るような人はどっちかと言うとAWSを日ごろから使っていてそのメリットを享受しているような人。「AWSいいですよ！」って言っても「セキュリティがあぶないんじゃ」「サーバーは海外なんだよね」「稼働率99.99％って１日に何分止まるの？使えないでしょ」といった主に感情が混じった「AWS危険だから使いたくない病」、もしくは「なんかわからんけど面倒だからAWSなんか使いたくない病」の人たちが多いから。そういった人たちを攻略するのは並大抵の事ではない。（経験済み）そういった人たちがこういったイベントにきて、メリットを肌で感じてもらえれば色々とSIアーとか変わっていくんではないかい？と感じた。
あーーー何かのサービスをいちから構築してAWS使ってってのを学習目的でなんか勉強会したいな。ディエゴスティーニの本みたく毎回来るとものが出来上がってきて最後にサービス公開とか。でそのノウハウは全部公開していくとか。面白そう。
