今すぐアイデアを形にするたった1つの方法
西谷圭介氏：みなさん、こんにちは。「今すぐアイデアを形にするたった1つの方法」ということでお話しさせていただきます。アマゾン ウェブ サービス ジャパンの西谷と申します。よろしくお願いします。
簡単に自己紹介をさせていただきますと、ふだんはアプリケーション開発者向けの支援をするチームをリードしています。
Serverlessやアプリケーションのプロトタイピングをお客様と一緒に作るといった活動をしています。
ちなみに本日はデモが20分もあるので、サクサクいきたいと思います。
まず、「たった1つの〜」と言いましたが、スタートアップとひと言で言ってもいろいろな考え・定義があると思っています。僕が考えるスタートアップの定義というか、スタートアップの特徴はこの2つかなと思っています。
「イノベーション」と「急成長」ですね。イノベーションは、新しいテクノロジーや世の中に存在していない技術に限らず、世の中の課題や問題を解決する新たな方法という意味で捉えてもらえればと思います。
あとは、スタートアップという言葉の中で最も大きい要素と考えているのが「急成長」の部分だと思っています。
スタートアップの特性として、急成長を狙うという部分があると思いますし、それを求められている。いわゆるベンチャー企業だったり、同じように中小規模の企業であっても、スモールビジネスをして直線的に業績が伸びていく会社とは違うところなのかなと思っています。
スタートアップでありがちなこと
「スタートアップのあるある」と書きましたが、よくある課題として私なりに感じているのがこのあたりです。
とくにアーリーステージにある会社の場合、「エンジニアがいない」。それは次の「お金がない」にも関わってきますが、自分自身しかいない場合も当然ありますし、資金がないのでエンジニアを雇えなかったりすると思います。
中には受託をやって日銭を稼ぎながら、自社のプロダクト開発をするケースもあるのかなと思います。例えばサーバ云々の話でいくと、安いのでとりあえずVPSにしたものの、サービスが成長していったときになかなかスケールしなくて困ったり。
受託でとりあえず日銭を稼ぐというやり方をとっている場合、受託自体が悪いわけではありませんが、日々の忙しさがあるので、当初自分がスタートアップした目的を見失って何をやっているかわからなくなったり、受託業務が忙しいことで本来自分たちがやりたい自社のプロダクトを作る時間がなくなるということが起こりがちです。
あとは、仮説だけでプロダクトを作って、そこに本当にニーズがあるかどうか評価・検証ができずに失敗してしまうパターンや、いろいろな機能が必要だろうと思って時間をかけて作り込んだものの、実はそれが市場では必要とされていない機能だった、みたいなこともあります。
「アイデアを形にする」とは何か？
今日は「今すぐアイデアを形にするたった1つの方法」と言っていますが、まずこの「アイデアを形にする」という部分に関してお話をしたいと思います。
「アイデアを形にする」とは具体的にどんなものを指しているかについてです。今日ここにいらっしゃる方は、比較的テクノロジー系のスタートアップが多いのではないかと思います。そういったテクノロジー系のスタートアップの場合、アイデアをかたちにするということは、ほぼ「システムとしてそのアイデアを落とし込む」「アプリケーションを開発する」ことにほかならないと思います。
では、アプリケーションを開発しつつ急成長を実現するためにどんなことを考えなければいけないかというと、「いかに速くアイデアを形にするか？」ということと「いかに速くアプリケーションを開発するか？」ということです。
それを少ない人数で、低コストでできなければいけません。当然お金がないので、資金調達するにしても、事業として成功するかまだまだわからないフェーズで大金を突っ込むわけにはいかないので、「低コスト」というのは非常に大事なポイントです。
ですが、スケールしなければいけません。とくに起業、創業初期や、Web系のアプリケーションだった場合はスケールが悩みどころになると思います。
そうすると、やれることは自ずと決まってくると思います。選択と集中。よくある言葉ですが、限られた人とお金というリソースで、ある程度の成果を出していく必要があるとなった場合、選択と集中が必要です。
つまり、やることとやらないことを決めていくのですが、余計なことはなるべくクラウドに任せたり、いろいろなサービスに任せて、ビジネスと開発に集中するのがいいのではないかと思います。
その開発というのは、ここに書かれているとおりです。差別化につながるポイントにいかにフォーカスするか。つまり、自社のプロダクトの価値をいかに伸ばすかということです。それ以外の開発もどうしても発生してしまいますが、そこはなるべく、利用できるものをオフロードすることで、自社の差別化ポイントにつながる部分にフォーカスできる時間を増やすということが、今日お伝えしたいことです。当然ながら、低コストでそれを実現する必要があると思います。
AWSを駆使して高速なアプリケーション開発
そうは言っても、必要とされることとして、Scalability・Flexibility・Agility・Low Costなどがあります。
これらをふまえて、いかに簡単に速くできるかを、今からデモをお見せしつつお伝えしたいと思います。今日は、そういったことができる具体的なやり方を知るというよりも、エッセンスとしてそういうこともできるんだな、と知っていただければ思います。
というわけで、デモをお見せしたいと思います。チャットのアプリケーションを作ります。AWSを使って速く作る一例として、チャットのアプリケーションを一から作って公開します。うまくいけば、みなさんもサインアップして利用できるようになります。最後に時間があればチャットで質問を受け付けたいと思います。
ここから20分ほど、ほとんど説明をせずに進めるのですが、ひととおり作ったあとに裏側で動き出す時間があるので、その間に解説をしようと思います。
AWS Cloud9でアプリ開発デモ
ちなみに、僕はふだんはあまりデモはやらないんですね。というのも、緊張するじゃないですか。失敗するし。
「Cloud9」というWebブラウザで使えてアクセスできる統合開発環境がAWSのサービスにあるのですが、今日はこれでアプリケーションを開発していきたいと思います。
実際にはAWS Amplifyという、フロントエンド向けのライブラリやフレームワーク、ツールセットがAWSには用意されていますので、それを使ってReactのアプリケーションを書いていくと考えていただければいいかなと思います。
というわけで、アプリケーション名は「startupday」にしておきます。こちらを作りますが、これはAWSはぜんぜん関係なく、普通にReactのサンプルアプリがscaffoldでできあがってくるととらえていただければいいかなと思います。
はい、できました。これが作られたアプリですね。ローカルで起動してみたいと思います。
Reactで開発したことがある、もしくはReactで勉強したことがある方にはお馴染みの画面ですね。ここに今からチャットの機能を突っ込んでいきます。
では、さっそくAmplifyを使うので、Amplifyで初期化します。
このあたりは何をやっているかよくわからないかもしれませんが、今日の話としては重要ではないので割愛します。AmplifyはReactやAngularなどいくつかのフレームワークに対応しているので、そのあたりを指定しています。
CloudFormationという自動化ツールがあるのですが、書いたことのある方はご存じだと思いますが、CloudFormationのテンプレートファイルは書くのがけっこう大変だと思います。Amplifyを使うと、そのあたりが自動で出力されて、自動で動いていきます。
その間に、今日はCI/CDのパイプラインも一緒に作るので、そのあたりを先にやっておきます。
具体的には、AWS CodeCommitというソースコード管理サービスがありますので、それを使って、アプリケーションをpushしたら勝手にビルドされて、勝手にデプロイされるというものを実現したいと思います。
今、CodeCommitのリポジトリを作ったので、そのURLをこのプロジェクトのフォルダに指定しています。ということで、設定ができたので、とりあえず作ったリポジトリにpushしてみたいと思います。
これでpushができたのですが、併せて、Amplify Console……Amplifyはいくつかのツールからなっていて、Amplify Consoleというサービスがあります。AmplifyはSPAを作るためのフレームワークやライブラリからなっているのですが、それらをデプロイしたりするパイプラインを作る機能があるので、今日はそれを使いたいと思います。
その設定を今からやっていきます。
先ほど作ったCodeCommitのリポジトリをそのパイプランと紐づけていくかたちになります。「demo2」というリポジトリを作ったので、「master」ブランチと紐づけます。
これ以降、デモの中で何度か途中経過のファイルをpushするのですが、あのリポジトリにpushすると、勝手にビルドが走ってデプロイされるというしくみが実現されます。そんな感じでとりあえず作ります。
裏でなにが行われているかというと、今回はJavaScriptのSingle Pageのアプリケーションです。いわゆるReactベースのSPAのアプリケーションなのですが、それをS3のStatic Website Hostingという機能を使ってインターネット側に公開します。
これは画面サイズの問題でややレイアウトが崩れていますが、あの「プロビジョン」となっているのが終わって「ビルド」「デプロイ」「検証」に進んでいきます。
このURLが、このあと使うURLですね。あとでbitlyで設定したり、みなさんにアクセスしてもらうURLです。
そちらが動いている間に、クライアントサイドとチャットツールを作るのですが、サーバサイドが必要になるので、それをここで作っていきたいと思います。
まず、サーバサイドのAPIを作りたいと思います。Amplifyはaddでできた機能を追加できるようになっていて、amplifyコマンドでこういったことをすると、裏側のAWS上の関連サービスも自動でデプロイされる機能があります。今回はこのAPIをGraphQLで作りたいと思います。RESTではなくGraphQLのAPIを作ります。
最初は、AWSがよく使うSignature V4というかたちのAPIキーでの認証になっているのですが、これはあとでサインアップできるようなかたちに変えていきたいと思います。このあたりはデフォルトでいいですね。
実際にはGraphQLをAppSyncというサービスを使って実現しているのですが、このGraphQLのスキーマを書きたいと思います。これは自動で生成されたものを修正するだけですね。こんな感じでできました。
このあと反映するコマンドを打つのですが、これだけでもう、サーバサイドでチャットのメッセージを保管する部分のAPIとストレージができあがっていると思ってもらうといいかなと思います。
これは今、パイプラインを作った部分ですね。これはデプロイされて、すでにインターネット側からアクセスできるようになっています。
今の、あの小さい文字をちょちょちょっと読み取れる方はアクセスできると思うのですが、そんな方はなかなかいないと思うので、あとでbitlyで短縮したいと思います。
それは置いておいて、今お話ししたとおりAPIを作ったのですが、これを反映したいと思います。
このあたりの細かいところは、今日のところは気にしていただかなくて大丈夫です。
ここでもまたCloudFormationが動き出すので、その間に短縮URLを生成したいと思います。bitlyで「201903……」、今日27ですよね。このトラックはb4だと思うので「b4」というかたちで作って、「bitl.ly/20190327b4」とします。さっきのReactの画面しか見えていないのですが、これで、たぶんみなさんのスマートフォンなどからもアクセスできるようになっていると思います。もしできなかったら言ってください。はい、見えるようになっていますね。
ほとんどサーバを構築するみたいな作業をしていないのはおわかりいただけるかなと思うのですが、それで先ほどお話ししたようなスケールするWebサーバがすでに動いているのがポイントかなと思います。
今、APIをここで作っているのですが、amplify pushでこうやっていろいろ裏側で自動で作られています。もうここは実際のところ待つしかないです。CloudFormationのテンプレートファイルを自分で書くのは大変なんだけど、全部やってくれているとも言えるので、ここはおとなしく待ちましょう。その間に、ちょっと違うことをやろうかなと思います。
同じプロジェクトのフォルダですね。今APIを追加で作って、それができあがっているので、このファイル名をまたcommitしてですね。よいしょ。
そうすると、ちょっと時間が経つと、このpushされたのを検知して、今度はこのパイプラインが……あっ、もう動き出しましたね。
また、プロビジョンされて、ビルドされて、デプロイされていくというところですね。
ここから実際のクライアントを作っていくのですが、ここもAmplifyを使っていきます。最初にAmplifyをインストールするところからです。先ほどお話ししたとおり、AmplifyはReact、Angular、Ionic、React Native、あとVue.jsに対応していて、今回はReactを使うのでReact版を入れます。
これで先ほどReactで作られた雛形に対して、Amplifyを使う準備が整ってきたので、実際にその雛形のコードに対してちょっと手を入れてチャットの機能を実装していきたいと思います。ここはコピペで勘弁してください。よいしょ。
ちなみに、文字的には見えていますかね。見えていますね。
ちょっとindex.jsに、Amplifyを使って、AWSのバックエンドサービスにアクセスしましょうというような設定を入れる処理を追加しました。
次がapp.js。これが実際のアプリケーションの本体になるのですが、GraphQLで公開されているAPIへ、先ほど作ったメッセージのスキーマに対してクエリする処理を書いていきます。
これも時間があれば、この時点でGitに追加してデプロイして、その結果を見てもらってもいいかなと思うのですが、若干時間がないのでローカルでやりたいと思います。
実際には今、手を入れた状態でどんな画面が出てきているかというと、ただの真っ白な画面ができあがっています。
ただし、裏ではこれはGraphQLに対してクエリをして、実は標準出力でコンソールにはメッセージが出てきています。
Amplifyのうれしいところは……ハイオーダーコンポーネントはご存じですか？ Reactにはいろいろなコンポーネントがあるのですが、そのハイオーダーコンポーネントとして、例えば認証の機能などを提供しています。ReactベースのアプリケーションにCognitoというサービスを使った認証を組み込みたい場合、例えば「ログインしていないユーザーであれば認証画面に飛ばして、サインアップして、認証されたユーザーであれば先に進める」といった処理を、通常は自前で書いたりすると思うのですが、ハイオーダーコンポーネントを使うことで簡単に実装できるのがポイントだったりします。
まず、そのauthの処理を追加したいと思います。今日はデフォルトでやりたいと思います。
これだけで、裏側ではCognitoのauthの処理ができるようになっています。これもpushしておきます。
その間にアプリケーションを書き換えます。先ほどの真っ白な画面に対して認証画面を追加するという話をしましたが、実際にやることはこの2行を追加するだけなんです。
まず、認証用のハイオーダーコンポーネントの画面をインポートすると、最後にappをエクスポートしているのですが、この代わりにwithAuthenticatorというハイオーダーコンポーネントが提供されているので、それを使ってappをラップするかたちでエクスポートしてあげます。この2つをやるだけで、認証画面ができあがっています。
では、まずはそれをローカルで見ていただこうと思います。
先ほどは真っ白な画面でしたが、こんな感じでサインインの画面ができあがっています。これはこのあとGitでpushすると、先ほどのURLのところに実際にデプロイされるので、みなさんアクセスして、実際にアカウントを作成してログインできるようになります。
ここはチャットなので、投稿する機能などを追加していきたいと思います。基本的に、先ほどから作業をしているapp.jsに対していろいろな機能を追加していくだけですね。このあたりは普通のReactの話です。
途中で確認していけるとベストなのですが、なにぶん時間がないのでそのままいきたいと思います。
チャットなので、自分の画面にほかの人が投稿した内容が反映されていなければいけません。それをブラウザのリロードなくリアルタイムで反映させるために、GraphQLにsubscriptionという概念があるので、それを使ったsubscribeの実装も追加しておきます。
subscribeして、変更があったら、それを画面上に表示するという機能を追加しました。
これで、チャットの機能そのものはできあがりました。これを見てもサインアップしないとこの先にいかないのでなにも見られないのですが、まずはamplify pushして、今コードを書いたので、それをcommitしてpushします。そうすると、またここが動き出して、そのうちデプロイされると思います。
先ほどのURLにアクセスしていただくと画面が見えるようになっている思うので、サインアップしていただいてかまいません。パスワードの要件が厳しくなっていて、記号と英数字の大文字、英数字の小文字、数字で8桁ぐらいのパスワードを入れる必要があるのですが、それでサインアップができます。
メールアドレスは有効なEメールアドレスを指定していただく必要があります。いわゆるconfirmation codeが飛んできて、それを入れてアクティベーションするというような処理も、今ここでちょろちょろっと書いていた中ですべて実装されていると考えていただくといいかなと思います。無事にデプロイされていればの話です。
（デモ終了）
AWS Amplifyの概要
というわけで、デモはいったんこれで終了です。デプロイされるのを待ちましょう。その間にプレゼンテーションの続きをしたいと思います。
今作ったもののアーキテクチャはこんな感じになっています。
Amazon Cognitoで認証機能を追加して、S3とCloudFrontでJSのファイルをパブリッシュして、インターネットからアクセスできるようになっています。GraphQLのAPIは、AWS AppSyncというサービスと、Amazon DynamoDBというNoSQLのデータストアを使って実現されています。
このあたりの構築も含めて、先ほどここでやっていた作業だけですべてが終わっているのがポイントになります。
このデモの肝になっているのは、このAmplifyというツールです。FrameworkとCLI、Developer Toolsという3つからできあがっています。
Frameworkはライブラリなどの一連のものを指しています。
途中で何度かコマンドを叩いていたと思うのですが、CLIを使うことで、AppSyncやPinpoint、Lambda、API Gatewayを使ったAPIなどの実装が簡単にできるようになっていると思ってください。最後のDeveloper Toolというのは、今まさにGitにpushしたらデプロイされるところを作っていると思ってもらうといいかなと思います。
Developer Toolの1つ、Amplify Consoleは、モダンなモバイルWebアプリケーション……フロントエンドとバックエンドに分かれているのですが、そのデプロイ作業を簡単にしてくれるようなサービスです。
S3を使うと、実は静的コンテンツであればサーバを立てることなくWebに配信できるようになっています。今回はHTMLとJSだけで作られた、いわゆるSPAのアプリケーションなので、これだけで済んでいます。
動的コンテンツ、通常RESTfulな場合はこういったサービス群を使って実現できるのですが、RESTfulなAPIを実装する場合はAPI GatewayとLambdaを使うことが多いかなと思います。
GraphQLの場合は、今ご紹介したAppSyncとLambdaを組み合わせたり、バックエンドのデータストアとしてはDynamoDBといったものが使えるかと思います。AppSyncというのはGraphQLのマネージドサービスだと思っていただくといいかなと思います。
まとめると、静的ファイル、いわゆるHTML・JS・ImageファイルはS3とCloudFrontで配信をして、RESTfulなAPIはAPI GatewayとLambda、GraphQLであればAppSync、データストアは、「Persistent Layer」と書いていますが、永続化の層はDynamoDBといったものを使っていただくといいかなと思います。
サーバレスなコンピュートエンジン
アプリケーションの部分ですね。ビジネスロジックを書くのは基本的にこの2つになると思います。
LambdaとFargateと呼ばれるものですが、LambdaはServerlessでevent-drivenなアプリケーション実行ができるようなサービスで、FargateはコンテナのためのServerlessなコンピュートエンジンだと思っていただくといいかなと思います。
それぞれ特徴あるので、アプリケーションやシステムの機能の特性に応じて使い分けてもらえればと思います。Fargateの場合、コンテナなのでオーケストレーションレイヤーはすべてServerlessでやってくれるのですが、コンテナの管理そのものはユーザーがやらなければいけないので、あまり時間がなく、かつ、実装上問題ないのであれば、Lambdaを使ったほうが手間は減ると思います。
AWSではServerlessとよく言っていますが、アプリケーションのビジネスロジックは実行するLambdaを中心として、AWSには多種多様なポートフォリオ、ビルディングブロックが存在しています。
ひと言でServerlessと言っても、実はイベントソースとして存在しているフルマネージドのサービス群であったり、データストアであったり、いろいろあります。それらをevent-drivenにつないでいくのがServerlessなアプリケーションです。
このポートフォリオは、LambdaというこのServerlessなFunction as a Serviceがあるだけではなく、いろいろなポートフォリオ、ビルディングブロックと組み合わせられるのがAWSの特徴です。このポートフォリオ自体もいまだに広がり続けています。
実行する側だけではなく、それらを開発するためのツールセットも用意されています。先ほどから使っている、フロントエンド及びモバイル開発者向けのAmplifyや、サードパーティのFrameworkも存在しています。
Experiment early & frequently
あと5分なので、最後に伝えたいことをお話ししたいと思います。ほんの20分で作っただけで、アプリケーションができあがります。デザインに関しては、今回なにもしていないので目をつぶっていただければと思います。
ポイントは、20分ぐらいで書いただけで、認証機能を持ったチャットアプリケーションができて、それがインターネットの世界へデプロイまでいって、かつ、ユーザーが増えてもすぐ落ちることもなく、シームレスにスケールする基盤としてすでに動いているということで、プロダクションレディな基盤が動いていると思っていただくといいかなと思います。そういったことが、ツールを使うことで可能になるということが、今日一番お伝えしたかったことですね。
最後にお伝えしたいことは、「Experiment early & frequently」です。
何事も、早期に何回も経験することが大事であると考えています。私もそう考えていますし、Amazon自体もそう考えています。
よく「Time to market vs Feature set」と言っていますが、先ほど「スタートアップのあるある」でも言ったように、「今ある機能で市場に先に出してしまうのか、もっと作り込んでよりよいものにしてから出したほうがいいのか？」という部分は悩みどころだと思います。
ですので、基本的にはMVP、リーンスタートアップの文脈でいうところの「Minimum Viable Product」という考え方が、やはりスタートアップには向いているのではないかと思います。
MVPをご存じない方のために簡単に説明します。MVPとは、顧客にとって価値をもたらす、かつ、利益を生み出せるような最小限のプロダクトのことです。最小限の仕様で市場に投入して、それに対するお客様のフィードバックをもとにイテレーションを回して成長させていくのが、スタートアップに一番向いている開発手法なのかなと思います。
「お客様と一緒に作り上げていく」と言ってもいいでしょう。というのも、「一生懸命いろいろ考えて、1年かけて開発して投入しました。ですが、それとお客さんが考えていることは微妙に異なり、求められているものも微妙に違っていました」となったときに、その1年は無駄ですし……まぁ無駄ではないかもしれませんが、1年という期間はかなり長い期間だと思います。それよりは、お客様からフィードバックをもらって実装したもののほうが、お客様に使ってもらえるようになるというところですね。
実は、AWSも含めたAmazonのサービスは、みんな同じ考え方で作られています。みなさん記憶にあるかもしれませんが、AWSのサービスは、サービスがローンチされてちょっと使ってみたら、いろいろとできないことがあると感じられることが多いかなと思います。それはまさに、このMVPの考え方を地でいっているわけです。
また、機能としてはまだまだ未成熟で、使っていただくお客様からフィードバックをいただいたり、ミーティングを数限りなく繰り返して、それをプロダクトのロードマップに取り込んでサービスを提供しています。
今すぐアイデアを形にする方法はない
今日のタイトルは「今すぐアイデアを形にするたった1つの方法」と、若干盛り気味のタイトルでしたが、実はそんな都合のいい方法はありません。1つの方法と言いましたが、そんな都合のいい方法はないのです。
ツールはいろいろ揃ってきています。AWSに限らず、世の中にはいろんなツールがあり、プロダクトの生産性、開発の生産性を高める手法が揃ってきているので、みなさんがいかにそういったツールをうまく活用して、実際に作ってデプロイするかということかなと思います。
今日は20分でチャットアプリを作ってデプロイできました。あれは、悩んでいるだけで1〜2日は平気でかかるかなと思います。それを20分でデプロイして、それに対して「もっとこうしてほしい」といったフィードバックを聞いて、製品に取り込んだほうが、プロダクトは成長するのではないかなと思います。
そうした運用やコードをいかに減らすかが、AWSのいろんなサービスのコンセプトです。お客様のopsとcodeを減らすお手伝いは、AWSと、我々SAがさせていただきます。
私からは以上です。ありがとうございました。
（会場拍手）