こんにちは！
ライブ配信セミナー『現場学校』レポート班のSカオリです。

2019年2月19日に開催された、阿部 正幸さんのセッション「フロントエンドの現場」のセミナーレポートをお届けします。

今回はフロントエンドということで、構築周りの業務が多いわたし的にも関係が深いお話だったと思います。

CSSフレームワーク使ってますか？？

海外での調査では、サードパーティCSSフレームワーク（Bootstrap、Foundationなど）を使いますか？というアンケートで、

時々使う／よく使う／全て使う　：56%
使わない／めったに使わない　　：38%

という結果が出ているそうです。世界的に、CSSフレームワークは使う流れになっている…ということで現状の日本の数字はわかりませんが、日本でもCSSフレームワークは使うのが主流になっていくでしょうとのこと。

わたし自身、実はCSSフレームワークを使っていません。
すべてidやclassに対してフルスクラッチで書いてます。理由としては色々あるのですが、
・必要にかられてなく学ぶ機会を作ってなかった
・所属していた会社でも社内コーディングルールに基づいたフルスクラッチでやっていた
・基本的に自分ひとりでコーディングしているので誰かにコードを引き継ぐことが少ない
・CSSフレームワーク独特のclass名などにいまいち馴染めなかった
あたりですかね…Bootstrapはむか〜しにちょっと触ってみたのですがその時は自分で書くのと比べて何がいいのかいまいちわからずにそのまま触らなくなってしまいました…。

なので今回の講義は、フレームワークに関する認識を見直す機会になりました！

CSSフレームワークを使う理由①コーディング効率化

コーディングの効率化として具体的には

・レスポンシブ（ブレイクポイントの定義など）
・コンポーネント（部品）
・グリッド・余白など
・軽微なアニメーション
・ブラウザ検証
・要件定義が楽（CSSフレームワーク準拠で構築できるのでバグも少ない）

例えば、外注などにコーディングを頼んだ場合、その人がフルスクラッチで書く人だとしたら、その人のスキルによってはコーディングの品質がちょっと…なこともあります。そこでCSSフレームワークを使うことによって、ある程度のクオリティが担保でき、手直しもそのフレームワークの書式に則っておこなうことができます。

CSSフレームワークを使う理由②コーディングルールの統一

・運用メンテナンス性の向上
・可読性の向上
・工数が明確化

こういった理由もありますね。制作会社などで複数人のコーダーがいる場合はルールが統一されていると見てすぐにどうなっているかがわかるので、別の人が作ったコードを見てもあまり迷わずに修正や案件引き継ぎができます。また、見積もり時にどのぐらいの工数がかかるかも計算しやすくなります。

CSSフレームワークは比較的安価な案件で使う場合に良いようです。工数削減してサクサクっと構築完成させたいシーンでは強そうです！

フレームワークの使い分け

阿部さんの場合、案件の規模によって使い分けをしているそうです。

Bootstrap（CSSフレームワーク）
・1ページ〜10ページの案件
Bootstrap＋Riot.js（JSフレームワーク）
・10ページ〜30ページ
Drupal（CMS）＋Bootstrap
・ページが多くて安価
Drupal単体
・中規模以上
Synfony2＋Twig（スクラッチ開発）
・中規模以上

Drupalはよく大規模案件や大企業のサイトで使われてると聞くCMSですがわたしは存在しか知らず実際には触ったことないですね！JSフレームワークも今のとこほとんど触ってないです…阿部さんの場合はほぼ100％なんらかのフレームワークを使用しているとのことです。なんと！

それぞれのフレームワークをご紹介いただきました。

Bootstrap

CSSフレームワークとしてシェアNo.1、グリッドシステムだけ使っている人も多い。

bootstrap.css　　  　 ：全部入り。カード・ナビ・ハンバーガーなどコンポーネントもフルフル
bootstrap-grid.css　  ：レイアウトのみ。ブレイクポイントやflexboxなど使える。コンポーネントは使えない。これだけでも利用価値あり。
bootstrap-reboot.css ：reset.cssのようなもの。これだけ使うということはない。

Bootstrapのコンポーネントは使わないんだよなぁという人はまずグリッドシステムだけ取り入れてみるというのもよさそうです。レスポンシブが標準になっているのはとても楽になりますね。

Riot.js

シンプルかつミニマム（軽い）。
シングルページアプリケーションに向いてる（ページレンダリングが速い。ページ遷移時共通パーツは読み込まずコンテンツ部分だけ読み込む感じ）
コンポーネント志向。

コンポーネント志向というのは、独自のタグを自分で定義して書いていって、共通パーツなどをコンポーネントとして突っ込んでいく感じ。これは静的HTMLのサイトの場合にヘッダーなどの修正を全ページしないといけない…というケースでもコンポーネントを修正すれば全ページに反映できるので非常に楽です。

わたしは普段WordPress案件が多く、共通パーツをテンプレートファイルにして読ませるということはよくしているのでこの便利さはわかります！WPでやるほどじゃない規模のサイトの場合はこのRiot.jsでコンポーネント化するのはいいですね。ちょっと気になります。

Drupal

柔軟な開発が可能。企業用CMSとして使われている（トップ企業100の50％も使っているとか！各国の政府系でも使われてるので、中〜大規模案件向け）。
多言語対応が可能。
承認ワークフローがある。→企業内で承認が必要なケースに標準で対応！
マルチサイトを一つのCMSで管理できる。

動画内で管理画面を見せていただきましたが、WPよりも柔軟に画面上でコンテンツの入れ替えや画面を見ながら編集などができるので、作業としてPHPを書くということもせずに大まかなワイヤーからサイトを作っていけるのがすごい便利そうです！

ほぼコードを書かず、画面上のみで編集、あとはデザインのCSSを書いて画像を当てるだけという流れを実演していただきました。これは…速そう…

スクラッチ開発って今どう？？

スクラッチ開発はメンテナンス性がクローズド（人のコーディングの癖が出やすく、書いた人しか読めないなど）になりがち、コストが膨らむ、予測してないバグが出てしまうなどのデメリットもありますが、細やかなチューニングができるところはメリットです。

世界的にフレームワークを使っていくのが主流にはなっていますが、スクラッチ開発も今なお使われています。案件にもよるっていう感じですよね。

ただスクラッチ開発は（今自分はスクラッチマンですけど…）とにかく1件1件細かにコーディングしていく感じになるので、安価な案件には向かないというのは感じます。それなりの費用でやってくれ！というのであればちまちまコーディングするのは楽しいのですけどね…そういう意味でも安価な案件を効率よくさばくためにも今からでもフレームワークを取り入れたほうがいいかも…と心が動き出すわたしです。

ライブラリやフレームワークを選ぶ基準は？

それでは、世の中に数多く生まれているフレームワークやJSのライブラリなど、それぞれ何を基準に採用するか考えたらいいのでしょうか？

・枯れた技術か
・コミュニティ、開発者の数は多いか
・ドキュメントの数は多いか
・ラーニングコストと効果

「枯れた技術」というのは、世に出て何年も使われ続けて知識が蓄積されている技術のことで、何年ぐらい生き残っているかも大事な選定基準です。
1年2年ぐらいでポッと出てきた技術は、普及せず消えてく可能性もあり、サポートがなくなるリスクがあります。新しいものにすぐ飛びつくよりも、しっかり残っていてかつ使っている人が多い、困ったときにヒントをすぐ探せるなどのポイントも見ておいた方がいいでしょう。

CMSでもWPがやはり普及率が高いのは、やりたいこと、求められてる機能を実装するときにぐぐれば大抵記事が見つかる（それだけ使ってる人が多いから事例も多い）という理由もあるんじゃないかなと。新しいことを学ぶときには記事や解説がなるべく揃ってたりフォーラムが活発なほうが入りやすいですしね。

ソースコードを書かない時代へ

海外ではどんどんソースコードを書かず、いかにフレームワークを使って手早くサイトを作るか、というのが主眼になってきています。日本もこの流れが来つつあります。

コーダーという仕事は、コードを書くことそのものが仕事なので、コードを書かない流れが自分の仕事にとってどう影響してくるのかなというのが心配になる方もいるかもしれないですね。それこそまだ需要がある言語ならまだしも、HTMLとCSSに関して言えば、フルスクで書けることが価値、とは今後はならないでしょうし、もっともコストとして削減されていく傾向になるのかなと…。

当然、デザイナーとコーダーが別で、提供されたデザインに沿ってコーディング、という場面などフレームワークだけで対応できないサイトもあると思います。しかしそういったデザイン重視サイトと、凝ったデザインでないサイト、安価なサイトとで同じ労力を割くのではなく、前者は力を入れるべきは入れ、後者は省力化できるなら省力化してサクサク作り上げてく、という選択も必要です。

削減できたコスト分で別のことに注力できるということのほうが、クライアントのためにもなるんじゃないかなぁと思います。
コーダーにとっても安い案件でヒーヒー言いながら時間のかかるコーディングをするよりサクサク終わらせて次！って案件をどんどん回して効率よく稼げていけるならそっちの方がいいような気がします。

CMS中心設計が増えている

1つの企業で複数のサイトを持つケースが増え続けています。コーポレートサイトに限らず、プロダクト（商品）サイト、アプリ、社長ブログ、スマートスピーカー…など同じ会社でも様々なサイト・デバイスのシステムを持つケースが多くなっています。

今までは1サイトにつき1CMSで作っていた（フロントとCMSが一体化してた）のですが、サイトが増えるにつれ、情報を管理する工数、アップデートの工数などがどんどん増えていってしまいます。

そこで、CMS中心設計が主流になりました。
CMS中心設計とは、コンテンツを管理するためのCMSを立て、そこにコンテンツをすべて集約し、各サイトからそのCMSに情報を取りに行く、という形です。これによって、情報を各サイトごとのCMSに入れなくてはならなかったのが、1つのCMSに情報を入れればいいので大幅に運用コストが削減できるようになります。

CMS中心設計のメリット
・リニューアル時のコンテンツ移行が実質なくなる（既存の何十何百ページのコンテンツを移行するだけでも相当な費用がかかっていたのが削減できる！）
・運用メンテナンスの大幅なコスト削減
・効率良いコンテンツ管理
・デバイスが増えても開発費用が抑えられる

良いことづくめのようですがデメリットはあるのか？というと、
先ほどDrupalの説明に書いていた「画面上でコンテンツの入れ替えや画面を見ながら編集などができる」というのが、フロントとコンテンツサーバーが分離することでできなくなります。

このぐらいのデメリットなら、CMS中心設計の運用管理効率のメリットの方が大きいと思います。

フレームワークを使ってない人も取り入れてみよう

わたし同様、フレームワーク使わずフルスクラッチで書いてるよ！という人は、webデザイナーの中でもたくさんいると思います。まずそのやり方を学ぶし、そのやり方のままで今まで来ている人もきっと多いですよね。

ただ、世界的にも、これからの日本でも、「いかにコードを書かずにサクサクと制作するか」というのが主流になってますので、なにかしらのフレームワークを、なにかひとつ得意なものを持っておくのがいいのではないか、と阿部さんが講義のまとめでおっしゃってました。

でも、わたしも今回のお話を聞いて、ちょっと毛嫌いしていたフレームワークのメリットを強く感じるようになってきたので、BootstrapのグリッドシステムとRiot.jsのコンビを採用して実案件に使ってみたい！と思いました。

最後に質問コーナー！

田口さんと阿部さんのWまさゆきコンビによる対談形式の質問コーナー。今回はかなり具体的なツールによるワークフローについてのお話だったこともあり、質問も具体的なものが多かったです。

A. Bootstrapの読み込むcssによって利用できる範囲が違うので（Bootstrapの項参照）、全部入りかグリッドシステムのみか使いたい方を選ぶ。
レイアウトやレスポンシブなど、Bootに頼れるところはBootにどんどん頼り、Bootでは実現できない部分は自分でカスタマイズしていくのがいい。

基本、BootでできることはBootを使う！しかし、Bootに合わせたデザインにする必要はない（本当はこうしたいけどBootのデフォルトのデザイン仕様がこうだから…は×）デザインは犠牲にせず、Bootにないところは自分で足す！

あとは、デザイナーとフロントエンド間のコミュニケーションも、Boot準拠で考えるようにすればそこで揉めることもなくなるのでおすすめだそうです。

A. （阿部さん自身がほぼDrupal案件が多くWPはあまり使われないとのことですが、）やりたいことに対して向いているCMSでいい。

自分が得意なものを使っていけばいいので、満遍なく広く浅くよりは、何かしら一つ深く知ってて表現できることを増やした方がいい！

WPの話題全然出てこないからWPいまいちなんかな、他のCMSも覚えた方がいいのかな…と思ったけど、当分WPを深めていこうと思います…！

A. Drupalに関する書籍は少ない。和書はDrupal5、6、8がありますがそれ一択。英語であれば色々ある。

阿部さんはDrupal案件の担当になって触り始めてから覚えていったそうです。本だけじゃ補えない部分もあるので、英語のドキュメントを読めた方が良いかも？
動画でなら解説が見つかると思うので、英語動画でもYouTubeの翻訳字幕が出るのでそれで学ぶのもあり！

その他、お時間の許す限りたくさんの質問に答えていただきました！今まででいちばん質問コーナー時間がたっぷりでしたので、レポで書いてない部分もぜひ見てみてくださいね。

『現場学校』を体験しましょう！

ライブ配信セミナー『現場学校』は、生放送のライブ配信を見逃した場合でも、期間中「アーカイブ視聴」ができます。

参加チケットはこちらから
https://gbgk.jp/