ソースコードを書かないことが武器になる～あらゆる情報がクラウド化される時代の歩き方【連載:えふしん】

2015/06/05公開

えふしんのWebサービスサバイバル術

藤川真一（えふしん）

FA装置メーカー、Web制作のベンチャーを経て、2006年にGMOペパボへ。ショッピングモールサービスにプロデューサーとして携わるかたわら、2007年からモバイル端末向けのTwitterウェブサービス型クライアント『モバツイ』の開発・運営を個人で開始。2010年、想創社を設立し、2012年4月30日まで代表取締役社長を務める。その後、想創社（version2）を設立しiPhoneアプリ『ShopCard.me』を開発。2014年8月1日からBASE（ベイス）株式会社のCTOに就任

どんな処理でもゼロからソースコードを積み上げて作れる人と、フレームワークやライブラリがないとアプリケーションが作れない人、あなたはどっちになりたいですか？

……と聞くと、大体のケースで前者になりたいと思う人が多いのではないでしょうか？

僕も完全にそういうタイプです。

Windowsアプリを作っていた時、Visual C++を書く機会がなく、Visual Basicしか使う機会がなかった自分はWin32 APIに対してコンプレックスがあります。

仕事では高級言語や便利なライブラリを使いつつも、アセンブリ言語など、よりプリミティブな技術に憧れたりはしないでしょうか？

しかし、今後はそれとは別の価値観軸が出てくるような気がしています。それは、

「なるべく自分でソースコードを書かず、ありものの技術をうまく組み合わせる」

という考え方です。

職人肌の人は、既存のライブラリやフレームワークなどに「癖のある仕様」などを見つけると、すぐにライラブリなどを使わずに自分でソースコードを書きたくなってしまいます。

また、技術への柔軟性が低い人は、フレームワークなどを学ぶ時間を捨てて、自分で車輪の再発明をしてしまうことがあります。

それはそれで妥当性は高いとは思うのですが、それがゆえにシステムが安定しなかったり、時間が掛かったり、他の人に引き継げなかったりという事態が起きたりします。

iOSのアプリを作る時にStoryboardと呼ばれるGUI上でデザインをすると、Auto Layoutという機能を使うことができます。

これは端末のサイズが変わっても、そこで指定したルールに沿って自動的にレイアウトを調整してくれる機能です。その機能を使わないのであれば、Objective-Cなどで個々にUIの制御を書かないといけません。

ところが、Storyboardはあまり使いやすくない部分もあるため、開発ツールであるXcodeに精通しないといけないので、ついついObjective-Cで制御コードを書いて解決してしまいます。

from Kārlis Dambrāns
解像度のバリエーションが技術的負債を生むことになったと考える

ところが、iPhone 5の時代のように何種類も画面サイズがなかったころは良かったのですが、iPhone 6やiPhone 6 Plusなどさまざまな解像度が追加されてくると、ソースコード上の分岐がどんどん増えてしまって、コードの見通しはどんどん落ちていきます。

Auto Layoutが出てきた段階で、こうなることは予見できていたのに、ついつい努力を怠ったがゆえに、技術的負債を作り込んでしまう結果になります。

AWSありきの発想を持ってみる

そういう部分での器用さや合理性というのは、あまり技術者の評価軸に乗らないのが現状ではないでしょうか？

優れたソースコードを書けるか否かという評価はあっても、コードをなるべく書かずに済ますスキルが、あまりポジティブな文脈で評価されるところを見たことありません。

しかし、そろそろ変わってきてもよいかなと思っています。Webのサーバサイド開発においても、CGIを書いていた時代よりも、開発者が記述をするコードは少なくなっており、かつ、フレームワークを使うと簡単に高度な機能を使えるようになりました。

新しい技術が出てくると、必ず語られるのが学習コストの高さです。要するに、他人が作ったものを理解するまでに必要な時間のことです。

学習コストが高いものは、なかなか普及しないというのがネックだったと思うのですが、今は学習コストを支払っても、新しいパラダイムについて勉強しにいくべきタイミングなのかもしれないです。

その代表例がAWS(Amazon Web Services)です。AWSは、Lambda（ラムダ）というサービスを出しています。これはS3への画像のアップロードや、Amazon SNSに到着したPush通知などにイベント・ドリブンでスクリプトを実行することができるサービスです。

エンジニアにとって分かりやすさがヒットにつながったAWS

実体は、それらのサービスに連動して動くNode.jsのスクリプトで、S3にアップロードされた画像のサムネイルを自動で生成したり、通知処理をそこで書くことができます。

つまり、画像のサムネイルサーバを作るためにわざわざWebサーバを構築したり、処理をcronなどで回す必要がなくなります。生成したサムネイルをS3に保存してしまえば、サーバを立てることなく最適な画像配信が可能になります。

AWSの人たちは、開発者の目先を「何でもEC2」から「脱EC2」に向けたいのだなと思っています。

Google App EngineとAWSが出てきた時に、AWSが注目されたのはEC2が素のOS環境で、多くのエンジニアにとって分かりやすく使いやすかったからだと思っています。

そして、新たなフェーズとしてAWS上のサービスと連動したLambdaが出てきたのは、非常に大きな話だと思っています。エンジニアは、自分たちが実現しようとするサービスを無意識にEC2で組もうとするのではなく、AWS上のサービスだけで実現できないか？を考える訓練が求められるでしょう。

ソースコードをできるだけ書かないという選択

さらに次のサーバサイドアプリケーションとして、例えば、アカウント制御やデータを外部のBaaSやSNS連携に紐付けてしまって、重要なビジネスロジックもAPIに委ねてしまうという考え方もあります。

セキュリティ、スケーラビリティ、機能をクラウドサービスに外出したような、シンプルでスケーラブルのアプローチというのは遠くないうちに実現するような気がしています。

いわゆるマイクロサービスのアプローチで、外出しできるものは全部外に委ねてしまうわけです。

そうなると求められるのは、世界中に存在するクラウドサービスの存在と、そのメリット・デメリットを素早く知り、適切に組み合わせる技術です。

つまり、一生懸命ソースコードを書くのではなく、できるだけコードを書かずに機能を実現することが必要になるということです。これは言うのは簡単ですが、やるのは意外と難しい話です。

Webシステムの開発手法を訓練されて来た人たちは、1画面の単位に要素を分解し、HTTPのリクエストとレスポンス、DBの入出力を組み合わせるというシンプルな組み合わせでシステムを実現する方法が板についています。それが、あっちのサービス、こっちのサービスを組み合わせて、どういうデータダイアグラムにすれば、簡単に実現できるのか？を考えるのは頭の訓練が必要です。

現状、複雑なシステムは考えるのが面倒くさくて、ほぼEC2かRDSしか使っていないという人もたくさんいるのではないでしょうか。ベストプラクティスが出てくれば、それを真似すればいいんでしょうけどね。