元AWSエバンジェリスト堀内氏が話す、クラウド時代に向き合うエンジニア像のこれから（前編） July Tech Festa 2015

7月26日に産業技術大学院大学にて「July Tech Festa 2015」が開催されました。

基調講演に登壇したのは、元AWSエバンジェリストの堀内康弘氏。クラウド時代のエンジニアはどのようなスキル、マインドを目指すべきなのか、独自の見解を、ソーシャルゲーム企業のCTOやクラウドのエバンジェリストなどの経験に基づいて紹介してくれます。

講演の内容をダイジェストで紹介します。

ベンチャーCTO、AWSエバンジェリストを経て考える、クラウド時代に向き合うエンジニア像のこれから

みなさんおはようございます。朝早くから集まっていただいて私の話を聞いていただくのは非常に恐縮なんですけども、僕の経験とかちょっと面白いキャリアのお話が何かのヒントになればと思っております。

まず自己紹介なんですけども、堀内康弘と言います。大学を卒業してスタートアップに入ってですね、いわゆるWebサービスやソーシャルゲームの会社のCTO、直近ではAWSのエバンジェリスト、こういった仕事をしてきました。

去年の9月末にAWSのエバンジェリストを卒業しまして、今やっぱりスタートアップが好きだということで技術アドバイザーですとか、これから起業していく中でどういったことがつまずくかとか、そういったことをアドバイスする、というようなことをしています。

そのかたわら、まあこっちが最近は本業というかですね、月の半分ぐらい世界を旅しています。これはサンフランシスコから行けるヨセミテ公園ですね、あとはグランドキャニオン、ハワイ島とかキラウエア火山、直近はメキシコにちょっと行ってましてリビエラマヤってところなんですけども、こういったビーチでのんびり、ビーチが好きなので今日もちょっとアロハシャツを着てきました、というような形です。

よくエンジニアのキャリアといいますか、インフラエンジニアもアプリケーションのエンジニアも、エンジニアという名のつく方々から、一生プログラマーとしてやっていくべきかマネージャーとして目指すべきかとか、大手がいいのかスタートアップがいいのかとかですね、1社で頑張るべきか転職をすべきか、あとは、これからどんな技術を学んだらいいんでしょうかと、こういった質問をよく受けます。

こうしたエンジニアの考え方、僕がいままで大事にしてきたこととかを振り返ってみて、みなさんのヒントになりそうなことをこれからお話ししていきたいと思っています。

変化を楽しむ柔軟性を持とう

まず1つ目ですね。毎年新しい技術が出ますし、ついていくのが大変だということがあるかもしれませんけども、やっぱりですね、変化を楽しむ柔軟性を持とうということが一番大事かなと思っています。

これはですね、ちょっと昔の話なんですけども、IBMのThomas Watsonが1943年ですけども、コンピュータのマーケットってだいたい世界で5台ぐらいだよねって発言したことがあるんですね。

それから30年ぐらい経ってですね、DECのプレジデントがですね、家にコンピュータが置かれる時代なんてまだ来るわけないだろうと。

これも有名な話ですけども、マイクロソフトのSteve Ballmer、iPhoneを見て、こんな高い端末が売れるわけがないだろう、キーボードも付いてないのにビジネスで使えるかと言ったことがありました。

こういった偉い人たちだって間違えます。多くの方がよく言ってますけども未来なんか予測できないと。でもですね、確かなことはつねに変化は起こり続けてますと。

イノベーション、技術革新が変化を起こしてます。技術革新でなぜ変化が起こり続けるかというと、技術革新が起こりました、そうすると楽ができて時間ができます。時間ができることによってもっともっと新たな技術革新に時間をかけることができる、投資ができるからまた新たな技術革新が起こる。

例えば僕はアプリケーションのエンジニアだったのでプログラムを書く、まあサーバサイドのプログラムをよく書いていました。10年以上前に初めてプログラムを作ったあとにCVSってものを知ってですね、ソースコードの管理、バージョン管理ができるツールがあると、これで飛躍的に生産性が上がりました。

昔はPerlでプログラムをよく書いていたんですが、1つのファイルにずらずらと全てのコードを書いていました。それが、Webアプリケーションが一般的になってきて、いつも同じこと、リクエストを受け取って処理してデータベースに書き込むみたいな、だったらその部分はフレームワーク化しちゃえばいいじゃん、っていうことで、いまフレームワークを使わないでWebアプリケーションを開発している方はほとんどいないと思います。

こういったものもまさしくこの技術革新の1つなのかなあと思ってます。

で、いまはクラウドコンピューティングですね、サーバの調達ですとかセットアップ、物理的なものを扱わなければいけなかったものが、いつでも好きなときに好きなだけワンクリックでコンピュータリソースを調達できるようにと、まあそんな環境ができています。 クラウド時代と言ってますけども、これは昔からずっと行われてきているイノベーションの歴史の中での1つにすぎないと、こういったふうに捉えることができるのかなあと思います。

技術革新があることによって、もっともっと他のことに時間を費やせるようになったと、いつもこういうマインドが必要かなと。新しい技術を楽しもうということです。逆を言うとですね、これ面白いなって思えなくなってくるとけっこうしんどくなってくるのかなと感じます。

何を勉強したらいいのか？

2つ目ですね。これまあ自分の経験なんですけども、技術ってのはすごく変化していって、何を勉強したらいいか分からない、迷っちゃうと思うんですけども、そういうときは自分の直感といいますか、楽しいなと思ったものを選択して、それにのめり込むのがいいんじゃないかなと思います。

その根拠は、何か強みがある人は、その人の価値が上がるというのを痛感しているからなんですね。Perlの堀内さんとかAWSの堀内さん、○○の○○さん、こう言われるとしめたものかなと思います。

僕の場合はどういうふうに今まで選択をしてきたのかなと考えますと、スタートアップが面白そうだなというところから入って、そこでやったのがWebアプリケーション。BtoBの問い合わせフォームとかを作ったのが一番最初ですね。

そこでPerlと出会ってのめり込みましたと。このあとの話で出てくるんですけども、Perlにのめり込んで、コミュニティをきっかけに次はBtoCのサービスが楽しいなと、かっこいいなと思ってBtoCにのめり込んで、そしてソーシャルゲーム、AWSとのめり込んでいくんですね。

技術は手段であると心得よう

最近すごい思うのは、技術は手段であると心得ようとということです。

技術を目的にすると間違った方向に行きがち。それから、ある技術はいつかなくなるかもしれないですよね。

Flashもなくなりそうですけども、ある技術に特化しているとそれがなくなったときに、にっちもさっちもいかないということがあると思うんです。

けれど、技術を使って解決するビジネスの課題、仕事をしている中でぶつかる課題、そういったものは働いている限り一生なくなりませんと。その課題を解決するための技術っていう発想が大事なのかなと思ってます。

自分の経験で、技術が目的となった例の最たる例が、問い合わせフォームにSledgeを使った、ということがありました。まあほとんどの人は分からないと思うんですけども、WebアプリケーションフレームワークのSledgeっていうのがあったんですね。

で、Sledgeが好きだったんで全部Sledgeで作りたいと当時思いまして、問い合わせフォームでデータを受け取ってデータベースに保存するだけなのに、すごい重いフレームワークを使ってしまったと。自分で作ってる分にはまだいいんですけども、チームで作る際には非常に生産性が下がったという痛い経験があります。

それから、これもちょっと笑い話なんですけども、当時はサーバが高価でたくさん買えなくてですね、でも、はてなとかmixiとかではサーバをたくさん並べて負荷に対応してるんだというような話を読んで、これはやってみたいなと思いました。そこで1台のサーバにロードバランサーを入れて、そのうしろにWebアプリケーションサーバ何個も立ち上げてデータベースサーバも入れて、冗長化構成みたいなのを作って一人で楽しんでました。 これも本当に手段と目的を履き違えた例だと思うんですけども、まあそういったことをしてたんですね。

良かった例としましては、ソーシャルゲームのgumiにいた時代に、意図してなかったんですけれども良かったのが、ゲーム開発には、4～5人のチームをタイトルごとに作って、それぞれのチームに、ディレクター、エンジニア、デザイナーが所属するような編成でやっていました。

もちろん開発部という単位はあったんですけれども、やはりゲームを一緒に作るデザイナー、ディレクター、そういった仲間とほぼ毎日コミュニケーションをするような編成でやっていったんですね。

チームの目標はそのゲームの売り上げを最大化する、ゲームの売り上げを上げるぞと、それがいいか悪いかということは別にしまして、そういったチーム共通の課題に対して、エンジニアが技術を使って取り組むというふうになれたんですね。

gumiで失敗した話

逆に、gumiで失敗したこともありました。ゲームごとにチームを編成するのとは別に、ゲームの基幹を共通化しようと考えたときがあったんですね。

どのゲームでも「ガチャ」をするのだから、ガチャチームを作ってガチャモジュールの共通基盤を開発し、全部のゲームにそれを適用していった方が効率がいいじゃないかと考えたんです。

結果はどうなったかというとですね、ガチャチームのエンジニアのモチベーションが下がって、開発効率も下がっちゃった。

理由は、そもそもガチャがあまり一般化できなかったことと、なにより大きかったのは、ガチャの開発は、課題として魅力的ではなかったということですね。開発エンジニアが、工場でモノをひたすら生産してるライン工みたいになってしまってモチベーションが下がったんですね、

なので、やはり会社であったりチームであったりするとそこで同じ目標を持てて一緒に捉えていけるような、そういった環境ってのは非常に大事だと思っていますし、エンジニアもその中の一員であるべきです。

また、例えばエンジニアがこの技術しかやりませんとか、エンジニアだからプログラムしか書きませんとか、インフラエンジニアだからインフラの設定しかしませんとか、そういった考え方でいると、その技術が廃れたときになかなか方向を変えることができなくなります。

逆に、こういった会社の中でプロジェクトの一員として、そのプロジェクトの目標を達成するために自分の技術を提供するんだと、そういった感覚で日々仕事に向かい合うことによって、技術が変わってもいつも使い続けられるといいますか、自分の武器になるようなものになるのかなと思います。

でAmazonもですね、そういったことを理解してかどうか、お客様を一番大事にするのが社是の1つにあります。何かサービス、プロダクトをリリースするするときには、まず物から作り始めるんじゃないんですね、

お客さんはこのサービスを使ってこういった課題を解決することができます、そのためのサービスを発表できて嬉しいですと。そういったPRの文章をまず書くんですね。で、これはいいね、ということになったら、じゃあそれを作りましょう、っていう形で実際に開発をすると。

≫後編では、一緒に働く仲間やアニキの見つけ方。そしてCTOになろう。という話です。