エンジニアとしてのブランクを乗り越え、Serverlessを使って開発した話
坂本直樹氏：今日お話しするのは、「エンジニアとしてのブランクを乗り越え、Serverlessを使って開発した話」です。
簡単な自己紹介ですが、坂本と申します。
昔はたくさんコードを書いていました。ハッカソンに出たり、スタートアップ2社の立ち上げをしました。ただ、組織が大きくなってエンジニアを引退してからは、ほとんどコードに触れていませんでした。
最近、久しぶりにコードを書きました。だいたい3〜4ヶ月間ぐらいの話ですが、今日はこの話をします。これからServerlessを使って開発するような人の参考になるようなお話ができればと思っています。
お伝えすることは3つです。1つ目が「Serverlessを選択した理由」で、（1）3つの社会変化（2）Serverlessを選んだ理由と期待する効果です。2つ目が、「エンジニアに復帰してブランクを乗り越えた話」。3つ目が、たくさんあるんですけど「失敗談」です。あまり具体的なコードの話は出てこなくて、ちょっと概念的なお話になると思います。
「3つの社会変化」の1つ目が、一言で言うと「目標設定が不可能になった」ということです。
変動性（Volatility）と不確実性（Uncertainty）と複雑性（Complexity）と曖昧性（Ambiguity）の頭文字を取って「VUCA」と言われています。
2つ目が「機能的価値から情緒的価値になった」というところです。
80年代は多機能性があって、90年代ぐらいからかっこよさ・おしゃれさのデザイン価値というものがフィーチャーされてきて、最近は経験価値というところがフィーチャーされています。
3つ目が、「『プロダクト』中心から『顧客』中心へ」ということです。
プロダクトがあって、たくさんのチャネルがあって、マーケティングしていくのが昔のモデルだったんですけれども、今は顧客中心にサブスクリプションで提供していくというかたちです。
Serverless frameworkを選んだ理由
こういう社会変化がある中でどうするかというところで、自分がとった戦略がこの3つです。
長期的に実現したい未来を描く。でも、その目標設定ができなくなったので、短期では仮説と検証を高速に回す。そして大胆な実験ができる体制をつくる。この3つが大事だと思っています。
戦術として、こういう体制を作る具体的な方法です。
企画のところではデザイン思考があって、そこから出てきたフィーチャーをバックログにためて開発を回していきます。今回は、開発のマイクロサービスとDevOpsあたりのお話がメインになるかと思います。
serverless frameworkを選んだ理由は、「全てコードだけで完結できる」「少人数で開発」できる、その結果として「圧倒的な柔軟性」が得られるということです。
期待する効果がこの4つです。
（1）サーバ管理が不要、（2）柔軟なスケーリング、（3）組み込まれた高可用性、（4）アイドル時のリソース確保不要です。
まだサービスリリースはしていないんですが、今はサーバ代がほとんどかかっていない状態で、本当に安いなと感じています。
あと、プログラミング言語はPythonを選んだのですが、理由はこの4つです。
（1）ドキュメントが充実している、（2）コードの書きやすさ、（3）データ分析と機械学習、（4）エンジニアの数も多く、これからも増加していくということで、採用も楽なんじゃないかといったところです。
ソフトウェアのライフサイクルとして、こういうものを作りました。
コーディングはCloud9を使って、GitHubを通して、CircleCIでテストを回してデプロイして、Slackに流すというところです。
ブランクを乗り越えるためにやった2つのこと
ここからが自分の経験です。コンセプトとインタビューをずっと繰り返していたんですが、去年の11月か12月ぐらいに、お願いしていたエンジニアが離脱しちゃったんです。
なので自分でコードを書くしかなくなって、決断をしました。ここからの話は3〜4ヶ月の期間に、ブランクを乗り越えてコードを書いたという話です。
最初に感じたのが、まったく手が動かないということです。身体がもうコードを書くことを忘れていて、2週間ぐらいすごく悩んでいました。
どうやって乗り越えたかというと、2つあります。
1つは「巨人の肩の上に立つ」ということと、2つ目が「『テーマのない努力』ほどムダなものはない」という2つです。
巨人の肩の上に立つ
1つ目、「巨人の肩の上に立つ」。これはアイザック・ニュートンの言葉なんですけれども、ニュートンの重力理論は全部自分でゼロから作ったものじゃなくて、過去のいろんな先達の理論の上に立っているということを意味する言葉です。
それに倣って、自分がやったことは、「自分が困っていることであっても、世の中の誰かが知っている」ということです。なので、たくさんの人のアドバイスをもらいました。
さっきのソフトウェアライフサイクルの、「コーディングして、デプロイして、テストして」みたいなところも、ほとんどがServerless Frameworkコアコミッターの堀家隆宏さんにお願いして作ってもらったり、たくさんの人に助けてもらいました。
あと、AWSのLoftをすごく使っています。ソリューションアーキテクトにいつでも話が聞けるので、アーキテクチャで困ったことやDynamoDBの設計で困っていることがあると、すぐに聞けるのはすごく助かっています。
そして、専門家からのアドバイスです。コーディングでは、大半の時間を調査に使います。専門家に「ここで困っているから、ちょっとサンプルのコードを書いて」というようなお願いをして、もらったコードを参考にしながら自分で書くというように、専門家からのアドバイスをうまく使っています。そうすると調査に要する時間が劇的に少なくなります。
「テーマのない努力」ほどムダなものはない
次に、「『テーマのない努力』ほどムダなものはない」です。（プロ野球で活躍した）野村監督の言葉ですが、何かしらのテーマを決めて努力をしなさいというメッセージです。
例えば、「テストを書きたい」となると、Udemyにすごく優れたコンテンツがあるので、「テストを書きたい」というテーマを決めて、それに即したものをUdemyで探すとか。「もっとスムーズにコードを書きたい」というテーマだったら、コードを書く時間をとにかく増やしたり、開発環境でCloud9を使ったり、（スライドを指して）こういうコードスタイルを助けてくれるようなツールを使ったりしました。このように必ず何かしらのテーマを決めてから努力するようにしました。
失敗談
失敗談はいっぱいあります。
最初はコードエディタにVimを使っていたんですが、難しすぎてまったく作業が捗らなかったというのが最初の失敗談です。Vimは初心者には難しすぎました。Cloud9に変えてからは少し捗るようになりまして、やっぱりGUIは便利だなと思いました。
そして、ユニットテストとインテグレーションテストがなかなか通りませんでした。今の自分の事業のフェーズは、プロトタイピングと検証が大事なので、ここはもうレッドのままにしています。
あと、コードと関係ないんですけど、Macbook Proを買ったというところですね。開発するにはハイスペックなマシンが必要だと思って、12月ぐらいにMacbook Proを新しく買ったんですけど、今の環境はほとんどクラウドで完結しているので、ハイスペックなマシンは必要なかったです。
あと、DynamoDBの設計はすごく苦戦しました。RDBはずっとやっていたので土地勘はあるんですけど、DynamoDBは初めてだったので、何度も手戻りしました。勢いでやってもやっぱりダメで、ここは基本に立ち返ってユースケースを作りました。
まずアウトプットのイメージを作って、それに対して、DynamoDBのテーブル設計と「そのテーブルからどういう順番でデータを取るのか？」みたいなところを、ユースケースをちゃんと作ったら書けるようになりました。遠回りのようで、実は近道だったというお話です。
あと、マイクロサービスにこだわりすぎることによる弊害も失敗談です。
ジレンマですけど、マイクロサービスで開発すると、その設計に慣れていなくてやっぱり時間を使ってしまうんですね。でも、モノリシックで開発すると柔軟性を欠いて、柔軟性を担保したいから、またマイクロサービスで開発するというジレンマが起きました。
やっぱり「今、自分にとって何が大事なのか？」に立ち返って、すばやくプロトタイプを作って検証することが大事なので、今書いているソースコードを捨てることを前提に開発することに決めました。テストを通らなくてもよいということと、あとからモジュールを分けられるようにすることを決めました。
とはいっても、ユニットテストとインテグレーションテストは通したほうがいいと、いろんな方からアドバイスもらっていて、ここはとても困っているので、アドバイス、もしくは手伝ってくれる人がいたら募集しています。
以上です。みなさんにとって何かヒントになれば幸いです。ありがとうございました。
（会場拍手）
