この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
『AWS Summit Tokyo 2017』が2017年5月30日(火)〜6月2日(金)、グランドプリンスホテル新高輪 品川プリンスホテル アネックスタワーで開催されています。
当エントリでは「 多数のコンサル案件と運用実績で見えた!? 安定＆急成長ビジネスを支えるデータ分析基盤とAWSインフラ環境 」をレポートしたいと思います。
セッション概要
当セッションの登壇者及び概要は以下の通りです。
スピーカー：
代表取締役 横田 聡 クラスメソッド株式会社：
「ビッグデータ分析をしてマーケティングに活用したい」、「システムをクラウドにおいて柔軟性を持ちつつ安価に利用したい」、「万が一の事故に備えて IT と運用の双方で対策を準備したい」といった様々なご要望について、これまで数多くの AWS 導入実績を持つクラスメソッドが、業種を問わずお客様のビジネスに共通する課題とその解決策についてご紹介します。
まえがき
まず始めに、セッションにご参加頂いた皆様ありがとうございました。時間を思いっきりオーバーしてしまい大変申し訳ございませんでした。
クラスメソッドとして、今回はじめてゴールドスポンサーとして出展しました。「なんでクラメソがスポンサーなの？どうしたの？」と多くの人に言われましたが、今まではほぼエンジニアのみの会社であり、リードを管理するという概念が無く、お客様情報を頂いても全く対応できないため、出展を控えていました。ほぼインバウンドのみで生き延びて来た会社です。弊社では昨年営業部が強化され（主にフォローアップとサポートが中心なのでアウトバウンドは今もあまりしていない）、今年からマーケ部が出来て（デジタル、イベント、施策等）、様々な施策を打ち始めています。
スポンサー出展に併せてセッション枠を持つことが出来まして、社内で私が指名され登壇となりました。スポンサーセッションだし、タイトル盛り過ぎだし、という感じで100人ぐらい来てくれればイイなぁと思っていましたが、400人部屋でほぼ満席ということで久しぶりに大変緊張しました。ここ数年は社員が優秀で何もやることがないのでセッション登壇の機会が無かったのですが、せっかく頂いた機会ですし、今まで伝えられてなかったことを中心に情報発信をしました。「謎のブログの会社」クラスメソッドをお楽しみください。
セッションレポート
以下、セッションの（セルフ）レポートです。
はじめに
- 自己紹介
- 77年世代、3人の子の父親です。約13年前にクラスメソッドを創業しました
- 企業向けにサービスをしています。
- クラスメソッドの社名の由来
- クラスメソッドやDevelopers.IOを知ってる人、挙手：7割
- 学生時代のアルバイトで企業向けのシステム開発や販売接客の仕事をしていた経験→卒業後に独立して企業研修を仕事に
- Javaのクラスメソッドとはインスタンスメソッドとは、と教室で教えながらこのキーワードに興味を持ちました。社名の最終候補には、ExceptionやThrowableもありましたが、それだと会社が続かなそうだったので、Classmethodにしました。
- 社名は広く一般的なキーワードですが、検索でも最後尾から始めてトップを取ろうと思っていたのでクラスメソッド株式会社にしました。→シークレット・ウィンドウでクラスメソッドを検索してみてね
AWSとの出会い
- AWSとの出会い
- 私がAWSを利用し始めたのは2008年11月。社内ではこの半年ほど前から一部の社員が使っていました。
- 利用のキッカケは新規事業。オンプレの見積が数千万円で困っていたところAWSに出会います。
- 当時は日本リージョンが無かったのですが、EC2とS3を使ってやりたいことができました。
- 結果的に、新規事業で5000万円以上溶かしてしまいましたが、AWSが簡単で初期投資が少なくてすむという点に魅力を感じました。
学び
- 事業は失敗しましたが副産物としてAWSとの出会いは大きかったです。
- 学び
- アジリティ：荒くても早く始めたほうが良い
- パッション：エンジニアが情熱を注げる環境を常に用意することが重要
- カルチャー：けっこう失敗します。そのコストを最小化して繰り返しチャレンジできる文化づくり
- スケーラビリティ：小さくはじめて大きく育てるノウハウは残り後で生きる
副産物が主役に
- 副産物
- インフラエンジニアが居ない会社でインフラを使いこなすためにはAWSは必須になりました。
- その後、開発環境はAWSを利用するケースが増えていき、最終的には全てAWS上で作る流れになりました。
- クラスメソッドがAWSを使いはじめて10年
- 最初の4年程は社内利用のみ
- その後3年間はAWSを顧客サービスに活かそうとして専門のコンサルをチームを作り活動
- 直近の3年間は、AWSをコンサルするだけではなく、運用監視、クラウドネイティブなアプリケーション開発、モバイル開発、データ分析基盤、新規事業など、全方位で活用するに至っています。
- AWSの利用のハードル
- AWSにはインフラ周りの機能は大体揃っている
- 社内説得と稟議には時間がかかる→社内の小遣いで結果出しましょう。
- どうしても会社の理解を得られなければ飛び出そう。＞エントリーお待ちしております。
本セッションの内容
- 本セッションの流れです
- 当社での活用についてご紹介
- よくある課題と処方箋についてご紹介
- AWS活用がどのようにビジネスに貢献するか
最近のクラスメソッド
- 数字でみるクラスメソッド
- 社員数160人。最近は月3人程入社しています。
- 資本金1億円で自己資本のみ。今期は売上42億円見込み。
- 顧客数はアクティブが500社、累計だと1000社程。
- 管理しているAWSアカウント数は1500を超えています。毎月50-100増えています。
- AWS認定プロの取得数は70、アソシエイトは160。新しい試験が始まったので早々に総数300を超えます。
- 拠点は、東京、札幌、大阪、上越、バンクーバー、ベルリン。シアトルでも登記しています。今年中にアジアも予定しています。
- 今日の時点で上場やM&Aの予定はありません。
- Developers.IO
- やってみた系、参加した系
- 累計1万本の記事
- 120万PV/月
- 30万UU/月
- 0.001%の方からのビジネスのお問合せで成り立っています。
- 社員を増やしてノウハウをもっと公開していきたいので、発注書をお待ちしております。
- この5年間でビジネスが大きく成長しました。
- レベニュー：自社のみで利用していたところから、顧客のインフラを支援することで急激に拡大しています。
- アカウント数：お客様の数も伸びています。
- ブログ：2011年にブログを書き始めて今年で丸6年になりました。継続は力だと思って今後も全社員で書きます。
- AWS認定資格：SA Pro、DevOps Proのエンジニア全員取得を推奨しています。
お客様とパートナーに支えられて13年
- 既に事例公開等をさせて頂いている企業様の例
- クラスメソッドだけでビジネス課題を解決することはできません。プロダクトやサービスをお持ちのパートナー、システム開発やWEB制作をして頂けるパートナーと一緒になってお客様にサービス提供をしています。
- 今後もパートナーを増やし続け、クラスメソッドとしてAWS活用部分に特化していきます。
- AWS Summitに合わせてロゴの掲載を許可頂いたお客様です。
- 大変お世話になっております。いつもありがとうございます。この場を借りまして御礼申し上げます。
お客様のビジネスを支える体制
- ある月のEC2の起動台数を調べて見ました。6万を超えていました。これだけの数を支える体制を作っています。
- もちろん、AWSには100以上のサービスがあり、それぞれに多数の機能があります。
- 24時間365日いつでもお客様ビジネスを支えられるように世界3拠点に事務所を構えています。
- 日本から社員を送り込んだり、現地で採用をしています。
- 全拠点にAWS認定プロが居ます。
- 今までは日本語のみの対応でしたが、来週から英語でのサポートを始める予定です。
- 自社で24時間対応の運用サポートをするためには結構な体制が必要です。もし体制を持っていないのであれば、おそらく一部の社員がずっと携帯電話を持って対応しているはずです。
- サポート件数は月500件、運用対応は月100件ほどになっています。今後も増え続ける予定です。
- サポートしたチケットについて毎回ご評価を頂いています。直近1年間の平均は、97.3%でした。100%目指して改善を続けます。
クラスメソッド自身が最大のAWSユーザーです
- 今回のセッション登壇で最初は顧客事例を中心にご紹介しようかと思ったのですが、他セッションでは大変魅力的なユーザー企業による発表も多数ありますし、技術的な内容はDevelopers.IOに詳しく載っているので、自社のことを話そうと思いました。
- 社内業務システムにおけるAWS利用
- 増え続けるアカウント数、サポートチケット数、請求書数において、人数を増やさずに、顧客に迷惑を掛けずに、どうやって対応するか、AWSや様々なサービス・製品の活用で解決をしています。
- リード登録、見積書作成、契約管理、従量課金計算、集計、請求書作成、送付手続きまで一連の流れがほぼ自動化しています。
- 社内業務システムは、できるだけ作らず、サービスを組み合わせて利用しています。
- 例えば、今まで手作業だった営業周りの仕組みは、Billing Reportから集計システムを通り、Lambda経由でSalesforceに繋がり、さらにLambdaを通じて請求データがMoney Forwardに繋がり、請求書が発行されています。
- 運用チームにおいては、OTRS、Zendesk、IAMを連携させた、承認ワークフローなどが動いています。
- 開発チームにおいては、Confluenceで仕様を管理し、Backlogで顧客と要件管理し、Githubでコードを管理し、コミットをフックにCircleCIが走っています。
クラスメソッドが開発して運用する各種プラットフォーム
- クラスメソッドでは、顧客向けに様々なシステムを開発して自社で運用しています。今回はそれぞれのアーキテクチャーをご紹介します。
顧客向けポータル
- これは、クラスメソッドメンバーズポータルといって、契約中の顧客に提供するポータルです。Beanstalkで作っています。
- AWSのBilling Reportを集計するためにEMRを用いています。
- このシステム作ったのは5年ほど前です。この当時は、RedshiftもS3 Event Notificationもありませんでした。API GatewayもCognitoもECSもありませんでした。ひとりのエンジニアが全部作りました。今でも現役のシステムで会社の稼ぎ頭になっています。
ECとCRMのプラットフォーム
- これは昨年はじめたECとCRMのプラットフォーム事業であるPrismatixの構成図です。
- この構成図はv2でして、ALBとECSになっていて、機能ごとにマイクロサービス化しています。
- RDSやDynamodDBにCRUD操作を行うとイベントが発生してKinesis Streamに渡り、検索用のElasticsearchに反映されます。こうすることで、ドメインは固く、検索などの利用は柔らかくできるようになっていて、スケールも容易です。
- このシステムは毎日ビルドが走っていまして結果がメールで飛んできます。
- インフラ構築とテストの自動化、アプリケーションのビルドとテストの自動化がされています。
- 毎回ゼロからCloudFormationやBeanstalkを使った自動化をすると1回のテストに時間が掛かりますので、DockerとかCircleCI 2.0等を使ってテストの高速化を図っています。
モバイルバックエンド
- このシステムは、モバイルアプリのバックエンドをSaaS化したものです。フロントとバックに分かれています。
- フロントは、ALBとDockerです。多くのコンテンツはCloudFront経由で配信します。
- バックエンドは、顧客の管理者がログインしてCRMやCMSを管理します。Cognitoでログインして情報を更新します。Pinpointでセグメントプッシュしたり、モバイル操作ログがMobile Analytics経由でRedshiftに格納されたりします。
時代とともに進化するサービス
- 少しお気づきの点があるかと思います。
- クラスメソッドでは、10年前、EC2とS3のみを使っていました。
- 5年前に作ったサービスでは、CloudFormation、Beanstalk、EMRなどを活用しています。
- 1年前から作っているサービスでは、ALB、ECS、Kinesis Stream、Elasticsearchを活用しています。
- 現在作っているサービスでは、Cognito、Pinpoint、Mobile Analyticsを活用しています。
- 10年前は2つ3つのサービスを使うために「クラウド使っても良いか？」を議論していました。
- 今は100あるサービスから「どのサービスを組み合わせるか」を議論しています。
- 毎月のように新しいサービスや新機能が出てくるので、ゼロから自作していてはスピード感が出ません。時間がかかればコストも掛かります。
- 失敗を恐れずに繰り返し打席に立ってビジネスをするためには、やりたいことを実現できる適切なサービスを見つけ、組み合わせて利用することが最短パスかと思います。
- 世の中には沢山の事例が公開されていますが、そのシステムが出来た時期を意識するとより参考になるかもしれません。
- 昨日と今日ではベストプラクティスが変わっています。（進化している）
- リリースされた時期がとても古いサービスでも劇的な進化を遂げています。
- S3には、イベント通知機能が付いています。
- SQSには、FIFOが付きました。
AWS利用における症状と処方箋あれこれ
- 社内でアンケートとりましてお客様から頂く悩みに対するアンサー集です。
- IAMを制するものがAWSを制します。
- RootアカウントやAdmin権限ユーザーを複数名で使いまわしたりしていませんでしょうか。
- この部分の設計はとても重要です。
- 本番と検証と開発でAWSアカウントを分けることも検討してください。
- CloudFormation実行するためには強い権限のIAMが必要だったりします。本番システムを傷つけないように分けましょう。
- エンプラ含めてAWSに全部乗せようという意思決定をする企業が増えています。
- しかし、ガバナンスを強く意識するあまり、EC2とS3しか使えないこともしばしば。
- それは、10年前のAWSですよーとささやきたくなります。
- 今は、100のサービスが出ています。これを使うことでビジネスにアジリティをもたらします。
- 折衷案として、ガバナンス対応のガチガチAWSアカウントとは別に、クラウドネイティブ用のAWSアカウントを作りましょう。
- どんなに優秀なセキュリティソフトウェアを入れていても、鍵が漏れてしまっては元も子もありません。
- AWSには以前からAPIキーを用いてシステム間連携する機能が提供されていますが、現在これはあまり推奨されません。
- ソースコードの中や設定ファイルにAPIキーを書かないようにするために、IAM Roleがあります。特定のAWS Account指定のロールもできます。
- もしどうしてもAPIキーを書く必要がある場合には、git secretsなどのチェックツールを用いましょう。
- 完璧な手順書があったとしても、人は誰でもミスをします。
- 人によるブレが発生しないように、できるだけ自動化します。
- また、Ci/CDするためにも、構築やテストは自動化します。
- インフラ構築時は、CloudFormation
- ミドル構築時は、UserDataによるスクリプト指定。
- 運用時は、System ManagerのRun Command。Ansible実行したり、Windows Updateできます。
- 再現性を持ち、人作業を減らすことが、事業継続にも繋がります。
- AWSに関するあらゆる操作について履歴を取ることができます。CloudTrailです。当社では全部ONです。
- このログは、CloudWatch Logsに送れます。フィルタすれば週間ログインレポートなど取れます。
- 他にも、IP制限したり、設定変更の履歴を取ったり、IT統制が取れる機能が揃っていますので利用しましょう。
- ネットワーク設計は後で響いてきます。
- DX経由でVPCに接続させる際に、余裕をもって大きなサブネットを切ってしまった場合
- 後からAuto Scalingさせたいとか、MultiAZでファイルオーバーしたいとか、Internal LB入れたいとかいった要件で直ぐにIPアドレスが枯渇してしまいます。
- 別VPC作れば良いのですが、複数VPC接続できるDX契約していないとか、VPC Peeringだとルーティングどうしようとか、細かい課題が後々出てきます。
- WEBサイトのパフォーマンスが出なくてインスタンスサイズを上げ続けることもあるかと思います。
- インスタンスサイズを上げることで、ネットワーク、CPUなどに余裕が出ますが、なぜそんなに必要なのか考えることも必要です。
- 例えば、ゲームのダウンロードをしようとした時に、1アクセスあたり100MBをダウンロードするとします。
- 1万人が同時に来たとして
- インバウンドのHTTPリクエストトラフィックは大したことありません。
- アウトバウンドのHTTPレスポンストラフィックで詰まります。
- 100MB * 1万人 = 1TB
- ディスクの読み込みでも遅延が発生します。
- 1万人が同時に来たとして
- 認証のみEC2などに任せて、CloudFrontに置いた大容量コンテンツに対して、時限付きのユニークURLを発行することで、ほとんどのトラフィックを逃がすことができます。この仕組みであれば、EC2の負荷は大したことがありません。
- もっというと、認証はCognitoで行ってしまえば、EC2さえも必要ありません。
- サーバー運用においてログは最重要ですが、サーバー内ログしか取っていないケースがあります。
- CloudFrontやELB、更にはVPC内トラフィックのログをとれますので、必要に応じてONにしてください。
- 何をもってサービスが正常な動作をしているか考えますと、あるサーバーの死活監視だけでは不十分です。
- URL監視、ディスク監視、アプリケーション内のステータス監視など、サービスが正常動作する状態を監視します。
- また、そもそも1台のサーバーが落ちたとしてもサービスが落ちない設計が必要です。
- できるだけマネージドサービスを活用することで、監視の負担を下げることも検討ください。
- 世の中のサービスがソーシャル化、モバイル化する中で、過去の経験はあまり役に立ちません。
- 高額なハードウェアを買うわけではありませんので、初日は最大構成で備えましょう。
- 大きく構えて、後から最適化することで、コストとパフォーマンスのバランスを取れます。
- また、どんなに台数を増やしても、全てのトラフィックがDB書き込みに行っていたりすると必ず落ちます。
- できるだけ、キャッシュを使うなど、サービス全体に負担が掛からないように設計してください。
- AWSは100を超えるサービスがあります。これから更に増え続けるでしょう。私がAWSを始めた10年前とは全く異なる世界観です。
- しかし、実際の事業会社において、インフラ担当は裏方で兼務であることが多い割に、仕事の範囲は広がる一方で、AWS使いたいけどよく分からんといった状況かと思います。
- 時間を掛けて学習することも必要ですが、知っている人に聞くほうが早いと思います。AWSは全ての機能がAPIドキュメントという形で公開されていますし、Developers.IOやコミュニティに参加すれば必要な情報は大体手に入ると思います。
- このように、AWSを活用することで、システムを作るから使うになり、さらには選ぶになりました。
- 繰り返しテストできること、ノウハウが流通していること、詳しいパートナーなどがいることで、より加速すると思います。
- 一番最初にもお伝えしましたが、ビジネスはどんなに挑戦しても失敗することのほうが多いのですから、早く安く簡単に作って失敗のコストを最小化することが企業競争力そのものになるかと思います。
- 当社においても陽の目を見ない数々のプロジェクトがありますが、懲りずに繰り返し挑戦しています。現在は同時に4つほどやっています。
ビジネスに貢献する
- クラスメソッドは、創業以来、事業会社を支える「掛かり付けの医者のような」技術支援を目指してやってきました。
- 最近頂くお問合せは、情シスからだけではなく、ほとんどの部署からご連絡を頂きます。
- クラスメソッドにおいても、コンサルティングをしている部署だけが利用しているのではなく、10以上の部署やチームが活用しています。
- AWS活用のポイントは、
- 全部署で活用できるサービスがある
- 目的に応じてフィットするサービスを選ぶ
- SaaSなど他のサービスと組み合わせて活用する
- 大規模でも大丈夫。日本一の規模であったとしても、海外では事例が多数あります。
- 世界規模に対応したサービスが揃っています。いつでも実機を使って試験できます。
- 月100円ぐらいのサービスも多数ありますので、これを利用しないのは本当にもったいないです。
- システムの規模が大きくても安く使い続けることができるサービスがあります。
- どんな部署でもどんな規模でも適用できるAWSですが、採用や人材育成で困っている企業も多いかと思います。
- まずは既存の社員が自由に使える環境を用意するところから始めたほうが良いと思います。
- 次に、社員が困ったときに相談できるパートナーを見つけておく。
- AWSを活用することで確実に成果が出ることから始め、社内に味方を作りながら適用範囲を広げていく。
- 大きな会社でもエースは1人であることが多いため、その人がチャンピオン（第一人者）でありスターであり続けるために、構築したシステムは早々に社内外に引き継ぐ。
- 多くの企業で結果が出やすい部分は「データ」に関することです。
- 長年掛けて作ってきたIT環境は、部署毎にベンダーやSI業者が異なったり代わったりして、連携していないことが多いです。
- 新たに連携するシステムを作ろうとすると、調整だけで何年も掛かってしまい、調整中に保守切れで最初からやり直しも発生します。
- そこで、あらゆるデータの保管場所として、データレイクとしてS3を活用することを私は提案します。
- S3をデータレイクとして、独立した様々なシステムのデータをそのままのフォーマット（CSV、JSON、ダンプ、画像、テキスト）を置きます。
- 置かればデータは、そのまま長期に保管しつつ、データ変換や加工をしてデータウェアハウス等に格納します。
- S3にさえデータを置いておけば、後ろの行程で目的に併せた処理を行うことができます。
- 例えば、Redshift、EMR、Athena、Spectrum、Elasticsearch、Lambdaなどと繋がります。
- S3は、歴史が長く、安価で、スケーラブルで、あらゆるサービスの基盤となるものです。まずここからがスタートです。
- クラスメソッドでは、S3を起点とした、データ分析基盤を構築して運用するサービスを提供しています。
- 最近では、Tableau ServerとTableau Desktopを込み込みの価格で構築と運用を提供するサービスも始めました。
- このような構成のプロジェクト実績は100件を超えていると思います。
- 最初のスライドに戻ります。
- AWSを活用することで、
- アジリティ：早くはじめて学ぶことができる。
- パッション：エンジニアが情熱を注げる環境を手に入れる。
- カルチャー：失敗のコストを最小化して繰り返しチャレンジできる。
- スケーラビリティ：投資の最小化と結果の最大化に対応する。
- そして、これらの実現を手助けする良いパートナーに出会ってください。
クラスメソッドの次回作
- クラスメソッドの挑戦は続きます。
- 世界複数拠点での体制を活かして、海外オフィスではAlexa技術の活用が始まっています。
- LexやPollyなどはその要素技術としてAPIサービス化されています。
- 人とコンピューターの歴史は、ユーザー・インタフェースの歴史でもあります。
- 研究室で文字入力するインターフェースから始まり、パーソナル化して、ブラウザが生まれました。
- スマートフォンが出てきて、タップしてスワイプして利用するようになりました。
- メールからチャットベースのコミュニケーションに変化しました。
- コンピュータが進化しても、全世代との関係づくりは今まで難しかったと思っています。
- タブレットによって、幼児でもコンピュータを扱えるようになりましたが、
- まだまだ年配の方までリーチできていないと思っています。
- 音声のインタフェースは今までもありました。
- IVRという形でプッシュボタンによるナビゲーションは簡潔ですが自然ではありません。
- 最近の深層学習の発展による、音声認識や自然言語理解によって、人間同士の会話に近づいてきました。
- つまり、幼児から老人まで、全世代でコンピュータとコミュニケーションが取れるようになります。
- 日本は高齢化社会で、インバウンドに力を入れています。
- 一部の若者向けだけではなく、幼児や老人を含めるとマーケットは非常に大きいです。
- 音声を認識できるということは、外国語を扱うことができます。
- つまり、全世代、全世界に対して、ひとつのアプリケーションが提供できる可能性があります。
- 蓄積されるログデータの活用も期待できます。
- 飲食業や小売店では、人材不足により、サービスレベルを下げざるを得ません。
- つまり、ビジネスチャンスの点でも、社会問題を解決する手段として、やりがいがあるエリアだと思っています。
- もちろん、AWSをフル活用します。（黒船を恐れずに）一緒に乗りこなしましょう。
おわりに
- ここ数年は優秀な社員に支えられ、登壇機会が減っていて久しぶりに緊張しましたが、自社の現状を振り返ることができて大変有意義な時間でした。「謎のブログの会社」として何やっているかよく分からないと言われることが多いクラスメソッドですが、今回の発表で雰囲気を掴んで頂ければ幸いです。
- クラスメソッドが受託システム開発（納品して終わり）をやっていたのは一昔前の話です。今は、AWSをフル活用して、顧客のインフラを支え、自社向けサービスを開発して運用し、顧客向けサービスを開発して運用し、新規事業をたくさん回しています。
- また、社員の待遇や働きやすさの改善に力を入れています。子育て世代を応援したいので、男性社員の育児休業取得を推奨して1ヶ月の給与保証したり、女性社員の出産時と復帰時には健保とは別に多めのお祝い金を支給など、様々な支援制度を用意しています。
- 世帯収入を最大化するファミリー・ビジネスを目指していまして、ご家族での入社を歓迎しています。フルタイムの夫婦が3組、奥様がパートタイムで在宅勤務している夫婦が15組、親子1組が働いています。遅い出勤、早い退勤、長期休暇を歓迎します。短時間の正社員もいます。
- また、学ぶ機会の最大化をするために、海外カンファレンスや海外出張の参加のべ人数は年間100人を超えます。今年は、AWS re:Inventに30〜40人程で参加しようと思っています。世界のトレンドを肌で感じてお客様に還元したいです。
- クラスメソッドにご期待下さい！Developers.IOを応援してください！よろしくお願いいたします。
- 本セッションをご参加頂いた皆様、ブログ読んで頂いた皆様ありがとうございました！
謝辞
- AWS Summitの準備や当日対応して頂いたマーケ、セールス、エンジニアのみなさんありがとう！「クラスメソッドさん、社員が楽しそうですね」って何人かの方に言われてめっちゃ嬉しかったです！
- セッション当日まで資料のデザイン調整をしてくれたマーケチームSさんありがとう！！箇条書きの雑なテキストからこのスライドがアニメーション付きで出来上がるなんてまさにマジックでした。
18
