クラウドはライブラリ以上の必須スキル――クラウド時代の開発者の学びをソラコム 片山暁雄さんに聞く

クラウドネイティブ時代のデベロッパー生存戦略 第1回（後編）

　IT業界でのキャリアをSIerからスタートし、AWS ソリューションアーキテクトを経て、現在はソラコムにて、再び開発者の立場としてサービス開発を行う片山暁雄さんへのインタビュー。後編では、開発者はなぜクラウドを学ぶ必要があるのか、クラウド時代に、開発と運用はそれぞれどうなっていくべきか、そして片山さんの考える、自分にあった技術選択や、開発者の学び方について伺った。

• 前編はこちらから「AWSが普及すれば、プログラマが活躍できる世界になると思った――ソラコム 片山暁雄さんのキャリア」

ライブラリもクラウドも、知ってるかどうかで開発効率に大きな差がでる

ソラコム プリンシパルソフトウェアエンジニア 片山暁雄さん

株式会社ソラコムにて、ソフトウェアエンジニアとしてソラコムの提供するIoTプラットフォームの設計構築を担当。

オープンソースのJavaフレームワークプロジェクトや、 AWSの日本ユーザーグループ（JAWS-UG）の立ち上げに関わり、2011年にアマゾンデータサービスジャパンに入社。日本でのクラウド普及をミッションとし、AWSソリューションアーキテクトとしてAWS利用のアーキテクチャ設計サポートや技術支援、イベントやセミナーでの講演などを行う。

著書として『AWSクラウドデザインパターン設計編/実装編』『Amazon Web Services 基礎からのネットワーク&サーバー構築』『Javaルールブック』『SORACOM入門』など。

1977年 大阪生まれ。芝浦工業大学工学部金属工学科卒。

吉羽　そもそもなぜ、開発者がクラウド学ぶ必要があるのか。その辺りについてのご意見をお聞かせいただけますか？

片山　やっぱり手返しですよね。トライアンドエラーだと思うんですよ。繰り返しを早めると、全体的な効率ってすごく上がるんですね。特に開発者にとって、クラウドってそこをかなり加速できると思うんです。

　例えば、API Gatewayについての知識があるとすると、まずAPI Gateway自体はパッと使えますよね。で、何かデータを集めるサービスを作ってみたいと思った時に、受け口はもうAPI Gatewayでいいなってすぐ思えるか思えないかで、手間が変わると思うんですよ。Webサーバを立てて、ロードバランサーも付けて……って考えるよりも、API Gatewayならパッと作って、サンプルプログラムを書いて、ダメなら消せばいい。お金もそんなにかからない。そういうのを知ってるか知らないかで大きく違う。

吉羽　早くゴールにたどり着くかどうかですよね。

片山　ですが、本番でいけるかどうかの判定まではまだ早いじゃないですか。で、いけるとなったらそこからプロダクションにいくまでに詰めていく、そのスパンというのがクラウドを使うと短くなると思うんですね。僕の中では樹脂成形を何回も練習するのも一緒で、プログラムもデバッグ効率が高い人が速かったりするじゃないですか（編集部注：片山さんは新卒では製造業で働いていました。前編参照）。手返しを速くするという意味で、クラウドサービスを知っておくことは有用だと思います。

吉羽　それって、ライブラリを使えばやりたいことが一瞬で実現可能だっていうことと似ていますね。ここでいうライブラリのスコープがクラウドまで拡大したイメージ？

片山　おっしゃる通りですね。だから、知ってるか知らないかで開発効率に大きく影響がある。僕もJavaで開発していますが、コード自体は全体から見るとほとんど書いてないと思いますね。例えば、僕が使っているSpring frameworkはいろんなライブラリに依存しているのですが、自分が何か作りたいものがあったとき、知っているライブラリで実現できるのであればすぐ使っています。全体でいえばものすごいコード量になるじゃないですか。とても一人では書ききれない。ただ自分がやりたいことを満たすためのコードってそんなに数はいらない。

吉羽　すごく短い。それってRailsも同じですよね。

片山　そうなんですよ。なので、ライブラリがあるって知ってるか知らないかで全体的な工数がだいぶ変わると思うんですね。ソフトウェアの視点で見ると、EC2も僕の中ではライブラリの一種のようなイメージです。クラウドはライブラリ以上の価値はある素晴らしいサービスだと思うので、少なくとも使えそうかどうかぐらいは知っておくといいんじゃないかなと。

なぜAWSを導入したいかを説明するのもプログラマーの責任

吉羽　その話って、アーキテクチャを自分である程度決められる立場だともちろんなんだけど、SIなど大きい会社になると、全員がその技術を知らないとリスキーだし、もっと事例や調査が必要となることが多くてハードルが高いじゃないですか。そういうのってどうすればいいと思いますか？

片山　ありますね。なぜこれを使うメリットがあるのかを、導入したい側はちゃんと言い切る。使ってみたいから、流行ってるからでは押し切れないので。

吉羽　説明責任があると。

片山　そうですね。僕がAWSにいたときも結局それをずっとやっていたようなものでした。今まで使ってたものと置き換えることで、どういうメリットがあるのを説明する。あとはなぜ、新しいものが嫌がられるのかをしっかりイメージする。例えば、それは外部のサービスを使うからなのか。ではなぜ外部サービスを敬遠するんだろう。セキュリティの問題なのか、お金の問題なのか、それとも……。そういうふうに突き詰めていくと、解決できることは多いと思うんですね。負けない心で強く押せるだけの材料をそろえることが、ある意味プログラマとしての責任なんじゃないかと思います。

　ただもちろん、ちょっと使ってみたいという理由で何かを入れるのは別に反対じゃなくて、ただ、相手に対するロジックや裏付けがあれば別に、動機がそれだけでもいいと思いますけど。