優秀なフロントエンジニアの特徴

次に，斉藤氏自身が考える，優秀なフロントエンジニアの特徴について紹介しました。

優秀なエンジニアは，次の特徴を共通して持っていると言います。

• 自分の哲学を持っていて，この哲学という抽象概念をプログラミングという具体的な形のあるものに変える力を持っていること。
• 他の人から見たら他愛もないと感じるかもしれないが，細部にこだわりを持ち続けられること。
• もし前提条件が変わったとしたら，そのこだわりを潔く捨て去ることができること。

また，イノベーションに対して常に敏感であり続けることの重要性を指摘しました。それは，Webは常に変化し続ける環境であり，それが何であれなすべきことを実行するのに不便な瞬間が確実に存在するためだからだと言います。

Webの利用者の多くは単純に消費したいだけで，その裏側にあるテクノロジーを鑑みることまずしないこと。また，1968年に公開された2001年宇宙の旅で，iPadの存在を予知していた，SF作家のArthur C. Clarkeのような慧眼を持ったエンジニアではないこと。

これらを挙げた上で，Paul Graham氏の「正しい方向に自分自身を向ける努力する代わりに，どこに正しい方向があるかが分からないことを認めてください。そして，風の流れが変わることに対して敏感であるようにするべきだ」という言葉を引用し，「⁠イノベーションに対して常に敏感であり続けることが，フロントエンジニアを救ってくれるものかもしれない」と述べました。

プロダクトへ継続した責任を持つこと

斉藤氏は，プロダクトには責任を持つことも重要なエンジニアの資質だと言います。このプロダクトに責任を持つことは，年々と続いていくはずのプロダクトをメンテナンスし続けることも含まれているそうです。

どのようなアプリケーションでも，ある一つの技術的な解決だけで作り出せることはなく，フレームワークや言語，サービスについての検討があります。これらを検討する場合，プロダクトが持っている根源的な問題を解決することよりも，開発者の利便性を上げることに焦点が当たりがちです。斉藤氏は「それ自体が悪くはないし，利便性を追求することはむしろ良いこと。しかし，それぞれのツールには，ツールごとに解決しなければいけない問題がそれぞれ存在する」と話します。

そして，「⁠たいていは短い開発のスケジュールで働いている中で，段階によっては抽象化が必要になります。しかし，ツールよって抽象化されたレイヤーをドキュメント化することなく，あるいは教育することもなく，ただただ使い続けることは結局最終的にはコストになっていく。プロダクトを出すことも求められる能力ですが，それを継続し続けることに気を配ることも重要な能力なのです」と説明しました。

変化への対応力は，多くの環境を考えておくこと

先ほどからWebは変化を続けると言及しているように，フロントエンドは速度や幅が大きい分野です。例えば，モニタサイズの変化や，様々なデバイスへのブラウザ搭載の広がりなどが挙げられます。斉藤氏は，「⁠プログレッシブエンハンスメントとは，あの機能がないからこうしようとか，あの機能が使えるからこうできるとか，具体的な実装論だけではなく，堅牢なプロダクトを作ること，その堅牢さに疑問を提示すること，もしをしつこいくらいに重ねること，もしこうだったらどうなるんだろう，ということを重ね続けることだ」と話します。

レスポンシブWebデザインを採用したthe Boston Globeのサイトは，Google Glassに発売される前にリリースされたものでしたが，何もせずにGoogle Glassでの表示に見事に対応していました。斉藤氏は「担当していたエンジニアたちは，未来を予想していたわけではない。画面サイズすらエンハンスメントの一つとして捉えて，質問を続けた結果だ」と言います。

それにより，可能な限り多くの環境に対応することになりました。「⁠多くの環境は多くのユーザを意味し，多くのユーザは利益につながる。非常にわかりやすい単純な原理」とし，「⁠イノベーティブな変化に対してすぐに対応できることも大切だが，何もしなくても対応できているほうが優れている」と述べました。

デバイスやネットワークなどの環境を考えると，日本は世界でもトップレベルです。斉藤氏は，その恵まれた環境がいったいどういう意味なのか理解できていない部分もあるかもしれないとし，「⁠エンジニアにとって作る力はすごく大切です。非常に言葉にし辛いのですが，思いやりの部分と言うのも同じくらい大切なものだと考えている」と述べました。

パフォーマンス

斉藤氏は，プログレッシブエンハンスメントと並ぶもっとも興味がある分野の一つとして，パフォーマンスを挙げました。パフォーマンスを向上させることはもはや義務や責任でもあると言います。パフォーマンスについての話をいくつか紹介しました。

• Twitterは，JavaScriptベースのViewではパフォーマンスを向上することができなかったため，サーバサイドのテンプレートを使ってViewを整形する選択をしました。

• filament groupが昨年12月に，様々な通信環境におけるAngular.js, Backbone.js, Ember.jsなどのパフォーマンスを検証しています。3G環境のモバイル端末における最初にレンダリングされるまでの時間（first render times；先読み込み時間）を計測したところ，1,000msの壁を越えたフレームワークは一つもなかったと報告しています（Backbone.jsだけは1,020msで，ギリギリ合格ラインとのこと⁠）⁠。斉藤氏は「先読み込み時間だけを見て，パフォーマンスが悪いから使ってはダメという結論にはならないが，完全に無視していい結果でもない」と話します。この問題に対してEmber.jsはFastBootという興味深い回答を出してきています。

• 2013年にNicholas C. Zakas氏は，フロントエンドにおいてNode.jsを組み込むアプローチを提案しました。今ではIsomorphic JavaScriptと呼ばれています。よくあるサーバサイドとこれまでのクライアントサイドの間に，緩衝材としてNode.jsをおいてViewの部分をまかなうという仕組みです。

• 先日，FlipboardのWeb版のサイトがリニューアルしました。その際，React.jsを使ったCanvas操作を用いることで，レンダリングのパフォーマンスが60fpsを越えるくらい速く，ネイティブアプリかと思えるくらいスムーズなアニメーションを実現しています。しかし，多く人が指摘している通り，パフォーマンスを最優先してしまうあまりアクセシビリティどころか，すべてCanvasなので，文字のコピーすらもできないという状態です。斉藤氏は「話がパフォーマンスから離れてまったが，アクセシビリティもまたエンジニアが担うべき責任です。もちろんFlipboardの開発者がそういった問題を認識していないわけではありません。技術を使って，存在し続けている問題に新たな提案をしてくれた」と述べました。