コードさえあれば全て動かせる世界を、AWSなら作れると思った
吉羽 じゃあ、外は外で刺激があったのに、11年いた会社を離れてAWSに移ったのはなぜなんですか？
片山 SIer時代にAWSを初めて触った時、APIでいろいろできるのはすごくいいなと思ったんですね。特に僕はアプリケーションエンジニア寄りだったので、ソフトウェアだけで完結する世界があるのは自分にとってすごく有利だなと感じました。
吉羽 なるほどね。
片山 AWSで一番衝撃だったのはEBSのスナップショット機能です。バックアップを取るのってけっこう面倒くさいじゃないですか。
吉羽 面倒面倒。
片山 ミドルウェアに頼るとそれはそれで面倒くさい。もうちょっと下のレイヤーでごそっと取れると、めっちゃ便利じゃないですか。MySQLの差分だけ取るようなプログラムを書いたり、いろいろしてたんですけど、単純にMySQLを止めてディスクを丸ごとバックアップしちゃえば、数行のスクリプトだけでなんでもバックアップできるのはすごいなと。もちろんサーバーを立てられるというのもすごいし。
元からそういう世界がいいなと思ってて、これ、2009年のエイプリルフールとして僕が書いたブログ（「SSDLoader1.0をリリースしました。」）なんですけど、ちょっと見てもらえますか？
吉羽 これ、本当にリリースしたの？
片山 全部エイプリルフールです。もともとSDLoaderっていうアプリケーションサーバを自分で作っていて、ブログで紹介しているSSDLoaderっていうのは、いわゆるアプリケーションコンテナなんですけど、EIコンテナという、コードだけで実行環境を構築できる機能を追加しましたっていう。まあこれ嘘なんですけどね。これをセットして、例えば@Tomcat(version=6,port=8080)とか、@MySQL(4)って指定して実行すると、そのまま動くという。
吉羽 今で言うInfrastructure as Codeとかプロビジョニングの話？
片山 今風に言うとそうですね。2008、2009年ごろって、35歳プログラマ限界説が叫ばれてたじゃないですか。SEにならないと給料上がらない、アーキテクトを目指せって。でもITをやっているのにプログラムを書く人が軽視されるのは、僕はすごくおかしいと思ってたんですよ。
で、この現状を打破したいと思いました。プログラマってある意味、他の業種と比べて、ものを作れる幅が広いんですよね。僕が最初にいた製造業の例だと、金型を作っても材料がないと何も作れないけど、プログラマってもっと幅広いことができるので、ちゃんと扱われてもいいなと本気で思っていました。本質的には実際のアプリケーションのロジックに価値があるのに、それ以外のところに払ってるお金が実に多い。勤めていた会社が金融系のお客さんを相手にしてたってのもあるかもしれないですけど。
吉羽 いわゆる「SIの本質は保険屋だ」って言われているところや、バッファや仕様書、調整にってこと？
片山 そうですね、もちろんそれ自体は必要なものではあるとは思うのですが、実際に作れないような仕様書が出てきて、実装やテストにすごく費用がかかる、みたいなことがもっと減らせれば、例えば生命保険の保険料をもっと下げられたりするなと。また、コードだけあれば、それに従ってインフラ含めて動くような世界観があれば、そういった手間をもっと省けるなと思ってました。EC2やS3だけをとっても、いろんなことができるなって妄想していたので。そういう世界が来たほうが、僕が35歳になったときもプログラマが続けられるんじゃないかなと思って。
吉羽 新しいフィールドに先にちょっとツバつけといて、そっち行っといたほうがいいかなって。
片山 どちらかというと、このインフラ自体が広まらないと、僕の期待している世界観にはならないって思ったんです。
吉羽 なるほどね。
片山 で、僕がAWSに入社した2011年は、AWSはまだ走り始めだったけど、僕はこれいけるなって思った。AWSに入ることで、しばらくプログラマから離れちゃうけども、自分が何かものを作る側として、戻ってこれる場所を作るために、このインフラをともかくみんなに使ってもらう仕事をするのも別に悪くないなって思った。というのが入社したのがきっかけです。
吉羽 へええ。まさに自分が戻ってくる場所を作りたいと思ってAWSに行き、実際そういう世界になったので、ソラコムで、またサービスを開発するエンジニアに戻ったということですよね。狙った通りになった。一方で、AWSってどうしてもインフラレイヤーだから、アプリケーションエンジニアがインフラを触ることへの若干の敷居の高さがあったと思うんですけど、その辺はどうやって克服したんですか？
片山 まあ、あんまりなかったっていうのが正直なところですね。逆に、アプリケーションの一部として見たほうがいい。設計する時って結局みんなそうするじゃないですか。アプリケーションていうか、ネットワークも、サーバーも仮想的なものとして。で、ミドルウェアがあってその中にアプリケーションがあるけれども、アプリケーションの中もいろいろなコンポーネントが混じってて、それらが通信しあって処理をしてるっていうモデルなので……。
吉羽 じゃあ物理かそうじゃないかとか、インフラかソフトウェアなのかが、あんまり関係なかったということですかね。
片山 そうですね。そこの抵抗感は僕はあんまりなかったので。
吉羽 ある意味、全部あるクラスのインスタンスであった、以上終わり。
片山 そういうイメージですね。なので僕はあまりインフラを触ることに抵抗がなかった。それらが全て仮想化、デジタル化していくことで、ものごとがよりトライしやすくなる。デジタルだとコストが非常に安いですし。
吉羽 片山さんがAWSに入った時代って、まだサービスがそんなに多くなくて、VPCも全然なかったですよね。
片山 なかったですね。EC2、S3、SQS、そんなもんですか。他にRoute 53とRDSがあったかな。5個ぐらいしかなかった。
吉羽 そういう意味ではキャッチアップもしやすかった。
片山 今ほどリリースも多くなかったですしね。新しい製品が出たらそれを覚えればよかったので。
吉羽 ちょっとずつやればよかったと。
片山 そうですね。それは大きなアドバンテージではありますね。Javaもわりと早いうちから始めたので、新しい機能が出てもそれを覚えればよかった。
吉羽 Javaを始めたのは1.2ぐらいの時？
片山 1.1ごろから始めましたね。やれることは多くなかったので。
吉羽 積み重ねしやすかった。
片山 そうですね。フレームワークが来た時も、もう知ってたし、Strutsもそんなにコード量が多いわけじゃないので、読めばそれで理解できたし。早くやっとくっていうのは、ある意味特典ではありますよね。
吉羽 なんでもそうだけどね。新しい、よさそうな技術があったら、機能が増えまくる前に先にツバつけとくってのは大事。
片山 それはすごく思いますね。
吉羽 AWSの中でどんどんサービス出てきた時も、いろんな案件を担当しつつ、新しいものが出るたびにキャッチアップすれば、普通についていけた。
片山 ただ、深く使うことが難しくなってきて、例えばDynamoDBが、どういう機能を持っているか、どういう使い方をしたほうがいいのかというのは、なんとなく頭ではわかっているんです。でも、アプリケーションのコードと組み合わせた時にどんな感じになるのかな、あと運用してみたらどうなるのかなっていうのは、ちょっとわかりにくい。お客さんと話をしても、こういうケースでこう使ってますとは言えるんですけど。
吉羽 それは本当にね。僕もやっていたからわかるけど、他のお客さんが「こう使ってます」って言ったら、それ聞いて次のお客さんで、「あるお客さんではこう使ってます」って横流ししていくイメージ。
片山 そうなんですよね。細かい演算処理や、どのように実装しているかまでは、やっぱり落とし込めないので。
吉羽 そりゃ自分で動くプロダクションコードを書いてないからね。
片山 AWSにいた時、そういうのをやってみたいなと思ってましたし。
吉羽 中にいた時みんな言ってましたよね。お客さんが大規模サービスをやれるようにアドバイスしているのに、自分はやったことないという話。初期の人ほど言ってましたよね。
片山 ジレンマはありますね。あとは、自分の目標に対して、プログラムなりクラウドは使うべきだと思うので、そこが持ちにくいってのはありますね。例えば、このゲームをヒットさせるにはどうしたらいいかという目標があると、最短で到達できる手段を選べばいいと思うんですけど、やっぱりクラウド主体になっちゃうと、なかなかそこに行きつけない。
なので、どこかで、プロダクトを自分で作りたいなと思ってましたね。そんなモヤモヤはありながらも、AWSのソリューションアーキテクトは素晴らしい仕事だと思っていました。作り手側になると情報が全然入って来なくなるので、他のところからいろんな話を集めてきてくれる人の存在ってすごく必要。
あと、業界自体を進める、例えばFISC（金融情報システムセンター）の有識者会議のようなアプローチは、AWSにいないと出来ないですね。大きな視点でお客さんや業界を変えたりするところにモチベーションがある方には理想的な仕事だと思います。
吉羽 ロールが違うっていうことですよね。
片山 そう、ロールがね、やっぱり違うので。そういう仕事はすごく価値があるのは自分の中でもわかっていたんですけども、作り手側のほうが僕はどっちかっていうと得意なので、作りたいプロダクトがあって、それが自分のスキルでできると一番いいなとは思ったんですね。
