2018/12/19 株式会社GIGにて行われた「デザイナー・ディレクター向け！これだけは知っておきたいフロントエンド / サーバーサイドの知識」の資料になります。 https://giginc.connpass.com/event/109580/

1. デザイナー・ディレクターとして
知っておいたほうが良いフロントエンドの知識
2018年12月19日

2. 自己紹介
大学の頃：フリーランスで仕事を始めた
大学を卒業する頃：フリーランスで稼げるから就活はいいや
大学を卒業して半年ぐらい：起業しない？と誘われた
会社代表としてやっている頃：マネジメント/営業/経理/雑務 ... 頑張った。
会社をやめた頃：フリーランスに戻るか…
半年ぐらいした頃：Webサービスの会社に入ってみるか…
Webサービスの会社で２年ぐらい経った頃：会社が受託も始めたしやめるか…
また半年ぐらい：フリーランスやるか…
GIGに出会って：２日で応募
江崎 修平 株式会社GIG ソリューション事業部事業部長

3. アジェンダ
1.フロントエンド開発の複雑化
2.Webの歴史
3.フロントエンド界隈に走る衝撃
4.なぜ、こんなことに…
5.ディレクターとして考えること

4. 話の前に…
今日、フロントエンドエンジニアの方は居ますか？

5. フロントエンド開発の複雑化

6. フロントエンド開発の複雑化
今、確実にフロントエンド界隈は荒れています。

7. フロントエンド開発の複雑化
SPA
データフロー設計
ルーティング
バリデーション
CSS設計
コンポーネント化
SASS
gulp
Webpack
Node.js
npm
Vue.js
React.js
Riot.js
Redux
Fluxパターン

8. なぜ、こんなことが起こったのか…。
歴史を見ていきましょう。

9. Webの歴史

10. Webの歴史
20001990 2010 2018
Webの誕生
第一次ブラウザ戦争
JS/CSS搭載のWebブラウザ
登場
CGIの登場
サーバサイドMVC型フレーム
ワークの登場
HTML5/CSS3/Ajax/jQuery/
Node.jsの登場
Alt JS/Babel/ESLint/Webpack
などのツールの登場
Webフロントエンドフレーム
ワーク登場
第二次ブラウザ戦争

11. Webの歴史
1990年代
Webの誕生
第一次ブラウザ戦争
JS/CSS搭載のWebブラウザ
登場
CGIの登場
1991年にインターネット上に誕生しました。
Netscape vs Internet Explorer
Netscape や IE が続々と対応し始めました。
サーバサイドの言語としてはCGIがありました。

12. Webの歴史
2000年代
MVCという言葉が流行り、Webサーバサイドフレームワークもたくさ
ん出ました。
フロントエンドはHTML5が勧告され、jQueryでFlashからJSへの乗り換
えが進みました。
サーバサイドMVC型フレーム
ワークの登場
HTML5/CSS3/Ajax/jQuery/
Node.jsの登場

13. Webの歴史
2010年代
ChromeのV8 engineを始めとするJSレンダリングの高速化により様々
なツールが登場しました。また、それを取り巻く環境整備も進みます。
jQueryでは耐えきれなくなったフロントエンドの整備が始まりました。React.js
やVue.jsを始めとするWebフロントエンドフレームワークが登場します。
Alt JS/Babel/ESLint/Webpack
などのツールの登場
Webフロントエンドフレーム
ワーク登場
第二次ブラウザ戦争 Internet Explorer vs Firefox vs Google Chrome

14. 歴史を振り返ってみましたが、
フロントエンド界隈にいくつのか衝撃があった箇所があります。

15. フロントエンド界隈に走る衝撃

16. １つ目の衝撃
Ajaxの登場
それまでフロントエンドのJSといえば貧弱でブラウザ対応が面倒くさく、簡単な
動きをつけるのが一般的な使い方でした。
しかし、2005年にGoogle社がGoogleMapをリリースして常識が覆ります。
当時、画期的であったページ遷移をすることなく、Ajaxを使用してデータ通信を
行い、Webブラウザ側で地図を拡大・縮小する機能を提供しました。

17. ２つ目の衝撃
jQueryの登場
Ajaxの衝撃以降、技術者はAjaxとそれに対応したDOMの高度な操作を求められるよ
うになりました。そこで登場したのがjQueryです。
jQueryに登場によりアニメーションの作成やAjaxの通信、ブラウザ間の実装違いの
吸収を行ってくれるようになりました。
2007年になるとiPhoneも発売されFlashからJSへの移行がより進みました。
サーバサイドもRESTfulをベースとしたWeb APIの提供をするだけで良くなり、フロ
ントエンドとサーバサイドの分業が一気に加速しました。

18. ３つ目の衝撃
HTML5/CSS3の登場
HTML5とCSS3の登場はWebのリッチインターフェイスの表示に大きく貢献しまし
た。特にCSS3での装飾は今まで画像化していた部分をCSSで表現できるようにな
り、難解だったデザインを簡単に実装できるようになりました。
HTML5では、より明示的にマークアップできるようにいくつもの新しいタグが追加
され、<div>だらけのマークアップから抜け出すことになります。
また、doctype指定がIEでも弊害なく使用できたため、導入障壁がほとんどなかった
のも特徴的でした。

19. このように…。
フロントエンド界隈では大きな変化が起こってきました
ここまででもフロントエンド界隈で大きな変化が起こってきたのがわかると思い
ます。
しかしこれは序章にすぎませんでした。フロントエンドをより複雑化させる大き
な衝撃がこのあと訪れます。
ここまではいわゆる、”Web2.0”と言われていた時代の話です。
これからモダンフロントエンドの話に移行します。

20. ４つ目の衝撃
HTML5実装のJSのAPIの増加
先程はHTML5のマークアップの構文について触れましたが、HTML5はJSにも大
くのAPIの追加が行われました。
DOM APIやHistory APIは実務でもよく使います。その他にもService Workerや
LocalStorageの実装など、様々な役に立つAPIが多数実装されました。

21. ５つ目の衝撃
Node.jsによるJSエコシステムの進化
2009年にはNode.jsが登場します。
サーバサイドの技術ですが、フロントエンドにも大きな変化をもたらしました。
１つ目は今までブラウザに閉じられていた実行環境がより広く使えるようになったこ
とです。Node.jsはフロントエンドの開発、検証に非常に有用な環境を提供しました。
２つ目はパッケージマネージャー、npmの普及です。JSで実装されたライブラリを
npm経由で利用できるようになりました。これによって開発したものをモジュール化
してnpm経由で配布する文化が育ちました。

22. ６つ目の衝撃
ES2015によるプログラミング言語としての進化
ECMAと呼ばれる機関があります。JavaScriptはECMAにより標準化されており、
昨今では、ECMAが提唱した仕様をブラウザがその通りに実装するという流れに
なっているため、ブラウザ間での誤差が生まれづらい環境になっています。
ES2015は、その中でも非常に大きな改修が入ったバージョンで、Webフロントエ
ンド開発が高度化する中で、今まで貧弱だったJavaScriptの言語機能を大幅に上
げました。数々の便利なメソッドの実装と、構文の実装が行われました。

23. ７つ目の衝撃
React.js Vue.jsをはじめとするフレームワーク登場
最近のフロントエンド界隈ではこの話題は持ちきりですが、React.jsやVue.jsを始めとする
コンポーネントベースのフレームワークが登場しました。
サーバサイドはほぼ完全にRESTfulになり、更にはサーバレスといった技術にまで発展して
います。
ReduxやVuexの導入でstate管理がしやすくなり、可読性が上がり、メンテナンスのしやす
いソースコードへと変貌を遂げました。
ただし、学習コストも高く、しっかりとしたアーキテクトの元作成をしないとスパゲッティ
になりやすいのは変わりません。

24. と、色々とありました。
激動のフロントエンド界隈でしたが、
ここ１年ぐらいは落ち着きつつあります。
React.jsかVue.jsをやっておけば２∼３年はいけそうです。

25. ちなみに…。
ここまでの話はVue.js入門という本にかな
り詳細に載っています。
もし興味があればご購読ください。
※１章の1.1∼1.3ぐらいまでの内容です。

26. なぜ、こんなことに…

27. なぜ、こんなことに…
jQueryはすごかった
jQueryが与えたインパクトはすごいものでした。
それまで簡単にできなかったアニメーションの作成や、ブラウザ間の仕様の誤差を埋めてく
れるのは、当時画期的でした。
プラグインの作成機能も提供していたため、たくさんのjQueryに依存したプラグインが生ま
れ、サイト制作におけるデファクトスタンダードになりました。

28. なぜ、こんなことに…
jQueryはスゴかった
jQueryはスゴかったのですが、簡単に扱えすぎたのです。
RESTfulなWebになるにつれ、 プログラマー としての高い技術力がコーダーに求められる
ようになりました。そしてフロントエンドエンジニアと名前を変えました。
ChromeやFirefoxを始めとするブラウザの進化により、JSでの処理速度が早まったことも
あり、今までサーバサイドで処理をしていた内容をフロントエンドのエンジニアに任される
ようになりました。
すると、複数人での作業が発生するようになったのですが、jQueryは複数人の作業に向い
ておらず、管理をするのが非常に大変でした。

29. なぜ、こんなことに…
フロントエンドにはテコ入れが必要だった
・Ajaxのコールバック地獄
・DOMを直接触るソースのブラックボックス化
・メンテナビリティの欠落したソースコード
…などなど上げたらキリがないですが、とにかくJSは2000年代後半∼2010年代前半にお
いて、非常に脆くて複数人での作業がし辛い言語になっていました。

30. なぜ、こんなことに…
そこに現れた救世主
そこに現れたのが現在のコンポーネントベースのJSフレームワークです。
コンポーネントベースにすることで、
・影響範囲の分離化
・HTMLとJSロジックの密接化
・再利用性の担保
などなど、今までメンテナンスしづらかった部分を解決してくれました。

31. ディレクターとして考えること

32. ディレクターとして考えること
ディレクターに知っておいてほしいフロントエンドのこと
・技術選定のこと
・ワイヤーフレームやディレクトリ設計
・作成する成果物のこと
・スケジュールのこと
・お金のこと
・テストのこと
・開発の体制のこと
・運用のこと

33. ディレクターとして考えること
技術選定のこと
ディレクターが技術選定をすることは少ないかもしれませんが、
クライアントとの会話の中で知識があったほうが良いとは思います。
例えば作成するサイトをSPAで作るのか、CMSで作るのか、サーバレスが良いのか、また
はなにか違う方法で作るのか、ある程度は企画や提案段階での会話の中でクライアントと話
せるとその後の進行が楽になると思います。
なぜその方法で作るのが良いのか、利点を知識として知っておくことで会話の幅がより一層
広がると思います。

34. ディレクターとして考えること
ワイヤーフレームやディレクトリ設計
これは主にSPA開発に言えることですが、ワイヤーフレームには動きの詳細をしっかりと書
いておく必要があります。
ここでしっかりとフロントエンドエンジニアと認識の齟齬をなくしておかないと、後々これ
が必要だった！となってもソースコードの大幅な修正が必要になってしまう場合もあります。
また、基本的にはSPA開発の場合、routerという仕組みで管理するため、ディレクトリは一
度決めたら簡単に変えられない場合があります。（開発の手法にもよります）
そのことにも注意しながらディレクトリの選定は進めていきましょう。

35. ディレクターとして考えること
作成する成果物のこと
成果物に関しては常にディレクターとして考えなくてはいけないことです。
要するにクオリティの担保です。どのようにクオリティを担保するかはディレクターとして
考えなくてはいけません。
作成するサイトにおいて、絶対に外せないポイントを見極めましょう。
サイトの使い勝手なのか、絶対にバグが出ないことなのか、UI/UXのクオリティなのか、ア
クセシビリティなのか。しっかりと見極めて、エンジニアに伝えてあげましょう。
それによってフロントエンドのエンジニアは使うツールを変えてサイトの制作をするはずで
す。

36. ディレクターとして考えること
スケジュールのこと
ディレクターにとって大事なスキルの一つにスケジュール管理があります。
スケジュールに関してもエンジニアとしっかりと話し合って決める必要があると思います。
昨今では、特にSPA開発の場合です。SPA開発の場合はアーキテクチャの考察に時間をかな
り使ったほうが良いです。要するに設計にかなりの時間を使い、制作は思ってるより少し圧
縮しても大丈夫なぐらいです。その他にもサーバレスで作成する場合、CMSで作成する場
合、jQueryを使う場合、など様々な条件で設計に使う時間や制作に使う時間を逐一変更し
て、臨機応変なスケジュール作成をする必要があります。

37. ディレクターとして考えること
お金のこと
お金の管理もディレクターの業務の一つです。例えば制作を外注する場合などです。
今でいうとトレンドのSPA開発やサーバレス開発などをする場合は、今までの相場より少し
高いぐらいだと思ったほうが良いと思います。
私が現状を見る限りでは、SPAでのサイト制作の需要に対して技術者の供給が足りておらず、
相場より高い金額の設定になっているように感じます。

38. ディレクターとして考えること
テストのこと
テストのことも考えてサイト制作を行いましょう。
制作するサイトの規模によっては、テスターをアサインする必要があるかもしれません。
できるのであれば、自動化で行っても良いと思います。
フロントエンドのエンジニアにとっては、どの端末まで動作を保証するのか、iOSはいくつ
までなのか、iPhone5は対応するのかなど、開発の最初から決まっていたほうが色々なこと
に配慮しながら制作を進めることができます。

39. ディレクターとして考えること
開発体制のこと
開発の体制は重要です。
特にSPA開発の流行りに伴いサーバサイドとフロントサイドの分業がかなり進んだとは言え、
APIの設計は誰がやるのか、最終的なGOサインを出すのは誰なのか、ソースコードのレ
ビューはするのか、アジャイルの体制で開発をするのか、バグトラッキングや課題管理はど
ういったツールを使うのか、開発体制はいろいろ考えることが多いです。
サイトの制作が始まる前に技術リーダーの存在をしっかりと明確にし、困ったときや設計漏
れが発覚した際に誰に聞けば良いのかすぐに分かる状況にしておくと作業者はやりやすいで
す。

40. ディレクターとして考えること
運用のこと
特にWebサイトの制作は運用フェーズというものがあります。
運用時のことまで考えられていると、フロントエンドのエンジニアとしてもどういったソー
スコードにしたほうが良いか、変える場合があります。
制作の中で運用時のことを見据えて何度もリファクタリングを行ったり、仕様書を常に最新
の状態に保ったりといった、細かいけど塵も積もれば山となる作業を制作フェーズに組み込
む意識付けになると思います。

41. ディレクターとして考えること
ディレクターに知っておいてほしいフロントエンドのこと
・技術選定のこと
・ワイヤーフレームやディレクトリ設計
・作成する成果物のこと
・スケジュールのこと
・お金のこと
・テストのこと
・開発の体制のこと
・運用のこと

42. ディレクターとして考えること
ディレクターに知っておいてほしいフロントエンドのこと
他にもたくさんのことを考えなくてはいけませんが、今日ここでお話した内容に関しての知
識を深めておくと、フロントエンドエンジニアとのやり取りが楽になるのは間違いないと思
います。
また、この知識を深めることによって、クライアントへの提案の幅や企画力の向上にもつな
がると思います。
ぜひフロントエンドの知識を身につけて、より良いディレクターになれるようにお互い成長
していきましょう！

43. ディレクターとして考えること
ディレクターに知っておいてほしいフロントエンドのこと
他にもたくさんのことを考えなくてはいけませんが、今日ここでお話した内容に関しての知
識を深めておくと、フロントエンドエンジニアとのやり取りが楽になるのは間違いないと思
います。
また、この知識を深めることによって、クライアントへの提案の幅や企画力の向上にもつな
がると思います。
ぜひフロントエンドの知識を身につけて、より良いディレクターになれるようにお互い成長
していきましょう！