編集部：この記事はCrunch Networkのメンバー、 Martin Puryearの投稿。Puryearは14週間でフルスタックエンジニアを養成するブートキャンプ、 Coding Dojoのカリキュラムとテクノロジーの責任者。
今年の1月、私はTechCrunchへの寄稿で2016年の主なプログラミング上のトレンドを予測した。
ソフトウェアの開発というのは非常に変化の速い分野だ。ぴかぴかの新しい開発言語、フレームワーク、ツールについての議論は賑やかだが、上位レベルのプログラミングのトレンドを正確に予測するのはたいへん難しい。まず私の2016年の予測がどの程度当たったおさらいしてみよう。
最新のJavaScriptが急成長する
JavaScript/ECMAScript version 6（通常ECMAScript 2015あるいはES6）は2015年の6月にリリースされた。私は2016年にはこの言語が広く採用され、デベロッパーが新しいバージョンに慣れるにしたがって新たサポートされた機能がウェブに普及するだろうと予測した。この予測は概ね当たった。
主要なブラウザすべてとNode.js（オープンソースのJavaScriptランタイム）の90%はES6準拠となった。この頃では、ES6は実験的、実験的な小さなシステムや内部利用に限られるツールに埋め込まれているだけでなく、さまざまな製品や主要顧客が直接触れるようなインターフェイスにも採用されている。既存のプログラミング遺産に縛られないユーザー、AirbnbやGoogleなどはES6のシンタックスを社内のプログラミングのスタイルガイドとして利用している。
ただしES6は普遍的、全面的に採用されたわけではない。一部のシステムは旧バージョンのJavaScriptをレガシーとしてサポートし続ける必要がある。デベロッパーはの多くはES6の記法を使いたくても、レガシー・ブラウザを使うユーザーを置き去りにするわけにはいかない。そのためtranspilerやpolyfillsといった新しいES6で書かれたコードを古いJavaScript向けにコンバートするツールが利用されている。
ただしES6の新しい機能をすべてのJavaScript環境がサポートするには至っていない。たとえば多くの環境で末尾呼び出し最適化がサポートされていない（Safari 10と iOS 10はありがたいことに例外だ）。この表はどのコンパイラやブラウザがES6のどのシンタックスをサポートしているかの一覧でたいへん便利だ。JavaScriptの旧バージョンは一夜にして消えはしない。しかし2016年を通してES6は急速に普及を続けた。新年にリニューアルされたサイトはほとんどがES6互換の環境に移行しているだろうと予想する。というわけでES6に関する予想は十分正確だったと思う。
BaaS―バックエンド・アズ・ア・サービス
BaaSつまりBackend as a serviceも予測どおり2016年のシステム開発の主要なトレンドになった。BaaSはクラウドストレージやノーティフィケーションなどプロジェクトの中で繰り返し行われる定型的処理の実行にサードパーティーのサービスを使う手法だ。BaaSを利用することによってデベロッパーは自分の得意分野に開発、運用の努力を集中することができる。バックエンドAPIの利用が盛んになっているのはフロントエンドのフレームワークがこうしたBaaSに接続しやすい形に変化してきたからだ。
デベロッパーはコンポジションと呼ばれるテクニックを多用するようになってきた。コンポジション方式の場合、システムいくつかの小さな部品（アプリケーション）から組み立てられる。このような構成の場合、小さな部品は容易にサードパーティーから入手できる。
私は特に今後ブログラミングのパラダイムがどう変化するかに興味を持っている
注意：前回の投稿で私は人気のあるBaaSの例としてParseを挙げた。記事が発表されたすぐ後にParseの所有者のFacebookはBaaSとしてのParseの運用を近く中止すると発表した。Parseを使い続けるつもりなら、ユーザーはそれぞれ独自にParseサーバーを構築し、 2017年1月28までにそちらに移行する必要がある。
イメージ管理と配布管理
2016年にはDockerやPackerなどが予想どおりデベロッパーの主要なツールとなった。 これらのサービスは デベロッパーはコンテナと呼ばれるマシン・イメージを簡単かつ素早く生成ないし複製することがができる。コンテナはソフトウェア、そのランタイム、システム・ツール、言語ライブラリーなどがバンドルされどんなプラットフォーム上であれ実行するのに必要な要素をすべて備えている。デベロッパーは軽快なバーチャルマシンの上で素早くプロトタイプを作ることができる。ここにはバージョン管理機能がビルトインされているので、複数のサーバー環境であっても矛盾のないアップデートが可能だ。マニュアルでサーバーのプロビジョニングをするというのは本質的に時間がかかり間違いが起きやすい作業となる。そこでこうした面倒な作業を自動化するBaaSが急速に普及したのは当然だろう。
これに関連してVagrant（開発環境の設定の自動化）、 Puppet、Chef、 Ansible（コンフィグレーション管理）などのツールにも人気が出た。コンテナ・ベースの開発はますますデベロッパーにとってますます標準的なものとなりつつある。この傾向が今後原則するとは考えられない。
関数型プログラミング言語への依存が強まる
Haskell、Clojure、Scalaのような関数型プログラミング言語は2016年を通して普及を続けた。こうしたサーバーサイド言語を採用するプロジェクトが増えたのはスマートフォンやIoTデバイスの爆発的な増大によるものだ。コンピューター、タブレット、スマートフォン、IoTガジェットの数が増え、ますます強力になるにつれてサーバーの処理能力がシステムのボトルネックとなってきた。大量の「つながったデバイス」からのリクエストを処理するためにはサーバーの能力をアップする必要がある。処理能力の不足は反応の遅れをもたらし、ユーザー体験を著しく下げる。
関数型プログラミング・モデルは基本的にステートレスだ。 ソフトウェアの各部分を複雑な同期処理なしに多数の異なるCPUないしマシン上で効率的かつ容易に並行動作させることができるようになる。オブジェクト志向言語に比べて関数型言語のパラダイムが本質的に優位なのはウェブからのリクエストのような並列処理の場合だ。
マテリアル・デザインと共通パターンへのシフト
2016年にはビジュアル・デザインの分野でも興味ある進展があった。 予期されたことだが、Googleはすべての分野でビジュアル要素としてマテリアル・デザインを採用したプロダクトの数を増やしている。システム（ChromeOS、Android）、アプリケーション（Chrome、Drive、Google Play Music）、ウェブサイト（YouTube,、AdSense）、それにウェブ検索もマテリアル・デザインになった。サードパーティーのAndroidアプリ、Slack、Twitter、Spotify、Airbnb、Wikipediaがマテリアル・デザインを採用しており、AsanaからGeekbenchに至る多数のウェブサイトもビジュアルをマテリアル・デザインに準拠している。
ただし他のプラットフォーム（(iOS、Tizen、Windows、MacOSなど）ではマテリアル・デザイン採用の動きは見られない（Ubuntuには多少の影響がある）。他のプラットフォームのデベロッパーは独自のデザイン・ポリシーを推進している。
デザイン分野での私の予測が当たったのは一部に限られるようだ。改めて2017年を予測するなら、サービスやアプリケーションにおける伝統的な視覚的デザインの役割は減少し、非視覚的なインターフェイス（Amazon Alexa、Siri、Cortana、Google Home）や別の視覚的要素（仮想現実、拡張現実）を利用したインターフェイスが普及期を迎えると思う。
結論
2016年のソフツには数々の興味ある進展があった。2017年にはさらなる発展が期待される。これにはコンテナや関数型言語の一層の普及、JavaScriptがアプリ開発に占める役割のさらなる増大などが含まれるだろう。私は特に今後ブログラミングのパラダイムがどう変化するかに興味を持っている。デベロッパー諸氏の考えを聞きたいところだ。
画像： Bernhard Lang/The Image Bank/Getty Images
[原文へ]
（翻訳：滑川海彦@Facebook Google+）
