ピクセルグリッドの2013年 前編 二極化する業務
2013年のまとめとして、今年1年の業務の中で印象に残ったことを、ピクセルグリッドのスタッフ全員に語ってもらいました。今回は、2013年になって目立ちはじめた、案件の二極化についてです。
HTML5関連技術でFlashのリプレイス
——では、まず始めに今年1年の仕事で印象に残ったことがあればお願いします。
小原：僕はCanvasを使った仕事を、今年、初めてやりました。実際の案件で使ったのは、初めてです。
小山田：僕もです。たぶん、仕事では初めて。
小原：別にこの話膨らまない？
全員：（笑）
小山田：僕もCanvasを使ったサイトを、今年は2つやりました。あれだけちゃんとCanvasを使った案件は初めてでした。
高津戸：確かに初めてじゃないですか？
小山田：ひとつは、いろいろ色のパターンがシミュレートできる商品カタログのようなもので、これにはCreateJSを使いました。もうひとつはイベントの告知サイトです。こちらには、生のCanvas APIを使いました。
*注：CreateJS
興味のある方は、今年の4月から8月まで連載された「CreateJSでHTML5 Canvasを操る」シリーズを参照してください。
*注：イベントの告知サイト
Node学園祭2013のサイト制作です。「ピクセルグリッドのケーススタディ」シリーズで紹介しています。
——案件で使ったCanvasは具体的にどういう用途で使われたんですか？
小山田：色がシミュレートできる商品カタログツールは、もともとFlashで作ったものがあるから、それをiPadで見られるようにしてほしいという案件でした。でも結果的にFlashで作った元のカタログよりは、さらにいいものがCanvasでできてしまいました。
外村：すごい。
中村：そのクライアント企業ではiPadを営業の方全員に配ったんですよ。いままでの商品カタログツールはFlashで実装されていたので、iPadでは見られなくなってしまったんです。それでFlashと同等の機能を実現するためには、Canvasを使いましょうって話になったんです。
小山田：APIはもともと使われていたありものをそのまま流用して、外側だけをCanvas（CreateJS）で作り替えました。だから、いい意味で既存のAPIを有効活用できました。
——ありもののAPIというのは？
小山田：JSONを返してくれるAPIです。
小原：何を表示するかってデータをJSONで持っているんですね。サーバーから投げられるJSONデータを元に、フロント側で表示をするんです。
小山田：単純に表示のメディアをFlashからHTML5関連技術に変えて、バックエンドのデータはそのまま有効活用するという仕組みですね。イチから全部作る必要はなかったので、ものすごくスムーズに進行した案件でした。
——HTML5関連技術というのはどんな技術を使っているんですか？ Canvas以外にも？
小山田：そうですね。Canvas以外にも、SVGや、CSS3の3D Transformsなんかも使っています。だからすごくHTML5らしい商品シミュレーションサイトができあがりましたね。
小原：そうだね。
小山田：デスクトップのブラウザでも動きますし、タブレットでも動きますからね。UIがちょっと画面が大きいものでないと機能しない部分もあるんですけど、iPhoneでも一応動くことは動くんです。
小原：そう、表示はされるんだけど、実用性がないって感じかな（笑）。
小山田：Androidは対象外だったのでテストしていないですけど、おそらく、いろいろな端末で動きます。
高津戸：営業ツールみたいな使い方をするサイトなんですよね。
——カタログのような？
高津戸：そうです。インタラクティブなUIで、お客さんの目の前で、いろいろなカラーパターンを見せられるんです。各店舗でiPadがあるだけで、そのインタラクティブなカタログが使えるんです。それが、よもつ（小山田）と、小原さんがやってた案件ですね。
Canvasを積極的に使った理由
小原：なんでCanvasを使わなければなからなったかというと、ひとつの商品でもいろんなカラーパターンがあるんですね。だからクライアント側で、商品とそのカラーリングの画像を合成して見せる必要があったんです。
小山田：わかりやすく言うと、MONSTER HUNTER*っていろんな装備が変えられるゲームがあるんですけど、その装備の色も変えられるような感じです。
*注：MONSTER HUNTER
小山田、高津戸などがプレイしている獣を狩るゲームです。身もふたもない説明ですが……。念のため。
高津戸：それ、わかりやすい（笑）？
小原：今後カラーバリエーションが増えても、JSONデータを差し替えるだけでいいような作りによもつさんがしてくれました。
小山田：商品が増えても再構築とか必要ないです。いいものが作れました。
中村：iPhoneなどのネイティブアプリでもデータを取ってくるようにすれば、できるはずだけどね。
高津戸：ああ、僕も今、それを思ってました。
高津戸：今まではFlashでインタラクティブな仕組みを実現していたけど、それはもう使えないので、なんとかしたいという案件は確かにありましたね。
中村：新規の実装案件でも、従来だったらFlashを使っていた部分を、Canvasで作るっていう話も増えましたね。
外村：IE10のキャンペーンサイト*は？
*注：IE10のキャンペーンサイト
IE10とタイアップしたキリンジ「いつも可愛い」のプロモーションサイト。Interactive Filmとなっていて、随所にCanvasの技術が使われている。
小山田：ああ、あれも確かにCanvasを使ったサイトだ。すっかり忘れてた（笑）。
高津戸：あれって今年だっけ？
小山田：今年の1月リリースだったら、ぎりぎり年は越えていたかな。
高津戸：僕が今年の1月にやっていた「いつも可愛い」っていうInteractive Filmのやつも、あれはもともとがvideoを使って「すごい」っていうのをやる企画でした。
——その案件で印象に残っていることはあります？
高津戸：サウンドノベルみたいなものをブラウザでvideoを使ってやるっていうことだったんです。でも、videoの対応がブラウザによってマチマチだったので。これにハマったいきさつは別の記事にも書きましたね。あ、でも、これ実装は去年でした。これは、なし（笑）。
効率化するツールを使えない案件の存在
高津戸：僕は今年はスマートフォン案件が多かったんですけど、これで印象に残っていることを言うと、Androidの愚痴になっちゃうからなあ。
中村：ずどさんは今年入るまで、大きなAndroid対応が必要そうな案件がなかったからね。
高津戸：Androidは昔のバージョンがけっこう残っているのと、それに加えて、同じバージョンでも機種ごとに出現するバグっていうのもあって、それがつらかったですね。
——なるほど。
高津戸：あと最近感じているのは、GruntとかCompassとか開発の効率性を高めるツールがいっぱいあるんです。そういうのが使える機会は以前より増えたんですけど、逆に、そういうのを使えない案件というのもまだあるってことです。
——どんな案件ですか？
高津戸：例えば、かなり以前からコードを流用しつつ運用している熟成されたチーズのようなサイトとか、そういう仕事もあるわけじゃないですか。CMSを作っても、なるべく運営サイドの方々に幅広く使ってもらおうとすると、新しいツールは安易に導入できないんですよ。だから、そういうサイトを実装するのって、あまり効率的にはできない。相対的に楽しくなくなってしまうんです。
——やってて楽しくないんですね。仕事だから当然やることは、きっちりやるとしても。
高津戸：そうなんですよね。だから……どうしようかなって思って（笑）。まあ、仕事だから仕方ないんですけどね。ああ、でも新しいツールを使ってできる仕事も、以前よりは増えてきたかな。
——効率化のためのツールが使える案件の条件ってなんでしょう？
高津戸：クライアントがまったくサイトの更新にタッチしなくて、こちらですべて公開まで担当するっていうのならまったく問題ないですね。さっきの「いつも可愛い」のようなJavaScriptで書かれた複雑なWebアプリケ—ションのようなサイトであれば、そもそもクライアントはいじれないので、全部こちらがコントロールすることになります。
——では逆に、使えないサイトは？
高津戸：ちょっとニュースの部分を自分で更新したいとか、ちょっとパーツを追加したいとなると、その時点でだめですかね。だって更新をするには、まず、大量のコマンドラインツールをインストールしないとできないってなると……。うーん。やばい、答えがすごくグダグダになっている（笑）！
全員：（爆笑）
小山田：ありますね、そういうの（笑）。CSSをminifyして.min.cssにしてあるのに、なにもminifyしてない.cssに変更が加えられて、それがそのまま運用されてたり。
高津戸：超ウケる（笑）。でも、中途半端にやると、また逆に大変なんですよね。
——中途半端っていうのは？
高津戸：こちらと同じようにSassやGruntを使って運用してもらうとなると、クライアントにいろいろ教えないといけなかったり、多くの場合は導入してもらえないです。
なので、例えばSassでコンパイルしたCSSだけを納品しますよね。そのCSSをクライアント側で修正したとするじゃないですか。そうすると、その修正をSassにマージするのが大変なんですよ。
みんな悩んでいる新ツールの運用
小山田：僕も最近、そのパターンになること多いからDiffツール*があったらほしいんですよ。
高津戸：僕、DiffMergeっていうの使っている。
*注：Diffツール
Diff（差分）を抽出して、マージしたり、どちらかを破棄したりという作業をサポートしてくれるツールです。ピクセルグリッドでは、高津戸の言う「DiffMerge」や、OS X用の「Kaleidoscope」がよく使われているようです。
小原：変わった部分教えてくださいとは聞けないの？
小山田：うん、こっちでそれは言えないです。だってSassにしろ、勝手に使っているだけだし。
小原：納品はどうしているの？
小山田：コンパイル済みのCSSだから、先方はSCSSの存在は知らないですね。
高津戸：ものすごい大規模なサイトなので、一様に全部新しいツールを導入っていうのは、無理なんですよ。でも、スマートフォン対応とか、RWDの実装が必要になってくると、ベンダープリフィックスを付けるmixinとか、そういうものを使っていかないと、かなり実装が大変になるんですよ。
小山田：作るものや技術が複雑になっているので、Sassを使わないと、かなり大変です。そもそも、その複雑化に合わせて、ツールが発達してきたという背景があります。
高津戸：そうそう。なので、よけい成熟したチーズのようなサイトは実装していて、つらいですね。
——その間を繋ぐツールはなんですかね？ さっきいったSassでコンパイルしたCSSが修正された場合、それをうまいことSassに取り込んでくれるような……。
高津戸：いやー、ないですね。それは。
小原：ほしがっている人はいっぱいいそうだけど……。
坂巻：同じものにはならないですからね。例えば、mixin自体はSCSSにはあっても、CSSには現れないですからね。
小原：できるとしたら、Sass自体がそういう機能を持って実装すればあるのかなあ。
小山田：でも、CSSの変更は手動で加えたものだから難しいでしょうね。
高津戸：うん。無理でしょう。
坂巻：個人的には分けて運用すればいいと思っているんですよね。自分たちが使うファイルと、先方が修正する用のCSSを用意してあげて、自分で修正したい場合は、がんばって上書きしてもらって、それには僕らは感知しないという方法。
高津戸：お悩み相談みたいになってますね（笑）。
——案件によっては、効率や複雑化に対応した開発環境を、そのままクライアントの環境へは導入できない。そのことから起きるギャップというか、開発の非効率さが印象に残っているというわけですね。
SassからいつCSSに切り替えるか悩んだ
——たかみー（山田 敬美）はどうですか？
山田 敬美：私はいままで既存のサイトを運用していくような受託案件をやったことがなかったんです。いままでは、そのときに一番イケてると思う設計方法で自由にコードを書いていたんですけど、長く運用していくことを考えると、どんなレベルの人でも理解しやすく、編集しやすいコードの方が正義だということに気づくことができました。自社サービスの場合は、最新の開発ツールをバンバン使った方が上手くいくこともわかりますけど。
坂巻：でもレガシーな案件では、別に効率は求められてなかったりするんですよね。
高津戸：ああ、なるほどね。
坂巻：「今まで通り」でいいんです。
小原：今のところ満足しているやり方だから、それを変えるのが大変、っていうのはあるのかも。
——たかみーは効率化するSassのようなツールは使ってます？
山田 敬美：先方も運用するので、基本は使っていないんです。ただ、新規に作るサイトがあって、そのときは使ったんです。けれど、まだこちらがSassで制作を進めているときに、コンパイル後のCSSを元にして先方が編集したりすることがままあって、つらいって思いまして。先方とのやりとりはZip納品でバージョン管理はされておらず、弊社側でもコンパイル後のCSSはバージョン管理の対象外としていたので、差分をとるのが難しくて……。また、どのタイミングでSassからCSSの運用に切り替えるか迷いました。
——通常の案件と逆ですね（笑）。
山田 敬美：先方にこちらの編集を伝えるときに、「CSSのXX行目を変更しました」ってドキュメントに書かないといけないんですけれど、Sass上では、どこなのかわからないし。
高津戸：いやー、それは無理だよ（笑）。
山田 敬美：いや、ほんとにこれどうしようかな、って思いました（笑）。いまだにここはどうやって解決したらいいか、わからないですね。
中村：先方が言うなら、Sassのファイルを納品して、CSSはminifyしておく。
山田 敬美：あ、先方も編集しなくちゃならないんですよ。
中村：そうそう。だから編集するためにはSassを覚えてください、って言うことです。
山田 敬美：クライアントだけじゃなくて、関連する制作会社の方も全員、編集するから、ちょっと無理ですね（笑）。
中村：だけど、さっきいったような状態で出しておけば、わからないから「これ編集してください」って戻ってくる可能性もあるよ。そうなれば、CSSを読み解いてSassに戻す作業が必要なくなる。
坂巻：でも、僕、minifyしたCSSを編集されたことあります（笑）。
高津戸・山田 敬美：それは、すごい（笑）！すごすぎる。
坂巻：検索して置き換えるだけなので……。
外村：CSSだったら、なんとかなるよね。
クライアントが編集する場合の対処
高津戸：ああ、僕の場合は、クライアントが編集する可能性がある場合は、最初からSass使わないね。
山田 敬美：それはスマートフォンサイト制作の案件だったんですよ。だから、ベンダープリフィックスをたくさんつけたり、グラデーションのCSSを手で書くのがつらいって思って、Sassを使ったんですよね。
高津戸：それは頑張って書くか……。あとはextendとかmixinもSassを使ってやるのではなくて、マルチクラスを使ってやる。
山田 敬美：ふんふん。
高津戸：そうやってやっておいた方が『Sassわかりません。』って言われたときに、なんとかなる。
山田 敬美：そうですね。OOCSSの方が、今、私がやっている案件だといちばんいいなと思ってます。今度、作業が発生することがあったら、それでやろうと思ってます。自分が書くときもわかりやすいし、人が読むときもわかりやすい。
高津戸：そうそう。
山田 敬美：例えばモジュールごとにクラス名を個別につける設計方法の場合、複数の人が更新をしていく大規模サイトでは向いてないなと思うことがあって。長く運用するうちにいろんな人がいろんな考え方でモジュールをどんどん追加していって、管理しきれなくなったりしますよね。あと、モジュールを追加する場合は、必ずCSSを追加しないといけないじゃないですか。その点、OOCSSの場合は、既存の汎用的なクラス名を組み合わせば、なんとかなる場合もあるのでいいなと。
高津戸：そうそう。そうやっておく。
——先方にはモジュール一覧を渡しておくわけですか？
山田 敬美：そうですね。それを見れば、どんな汎用クラスが用意されていて、どう組み合わせればよいかがわかるモジュール一覧が必要だと思います。今回の受託で、Sassが使えない場合は、OOCSSがいいなって思いました。自分が実際、すでにできがっているサイトの運用に関わるとすれば、そういうモジュール一覧が用意されていると、とてもやりやすいと思うんです。
高津戸：今、OOCSSがすごくあいまいな定義のまま話が進んでますね（笑）。この話は、ひとつは、CSSのモジュール一覧があると便利ですよねっていう話。複雑な構造を作るための手法がSassの場合は、extendとかmixinを使って書くんですけど、これだと、コンパイルされたCSSそのものをいじるのはもう無理。そこで、OOCSSの「モジュール」「スキン」という考え方を使えば、複数のクラスを使って、extendと似たようなことが実現できるということですね。
*注：OOCSS
OOCSS（Object Oriented CSS）とは、CSS設計の考え方のひとつ。モジュールは基本的なスタイルと、基本スタイルからのわずかな違いをスキンとして設定し、マルチクラスで指定することで、見た目を実現するという考え方を含みます。詳しくは「CSSの設計：OOCSSとjQuery UI」を参照してください。
——つまりSassを使えないときは、OOCSSの考え方を使いながら、モジュールとスキンというマルチクラスで対応するということですね。
山田 敬美：例えばボタンを作るとき、Sassで作る場合は、button-XXXXっていうひとつのクラスを作って、CSS上で基本のスタイルとオプションになるようなスタイルを組み合わせていたんです。でもOOCSSの場合は、buttonっていう基本のクラスのほかに、もうひとつオプションになるようなクラスを作っておくんです。そして、そのクラスをHTML上で組み合わせてスタイルを作るっていう方法がいいなと思いました。
高津戸：そうそう。OOCSSのメリットはクラスがうまく設計されていれば、CSSをいじらなくても、HTML上でクラスを組み合わせるだけでスタイルの編集ができるところ。Sassが使えない場合の策なんですけどね。
小原：オレオレBootstrapを作るっていうこと？
外村：そうそう、そうですね。
山田 敬美：今度は、そうやろう！
坂巻：懸念としては、ボタン青くしたかったんで、button-blueっていうクラスを作りました！みたいな使われ方をしちゃうところですよね。
小原：ああ、それはありがちだね。自由だもんね。
クライアントが編集できる時代ではない？
小山田：まあ、僕たちは使っているけれど、まだ広く普及はしていないので、そういうSassを使っていて、クライアントが編集したい場合どうする？っていう問題が起きていますね。
小原：Sassが出てきて使い始めた頃から、その問題はずっとありましたね。『コンパイルしたCSSを編集されたらどうするんだ？』ってことは、言われ続けています。
坂巻：世界を分けるしかないですね（笑）。
高津戸：確かにね。
坂巻：先方に同じ開発環境を作ってもらうのは、先方にとってハードル高いですからね。
中村：Web制作会社とのやり取りだったら、向こうも特に説明なしでツールが使えるので、いいんですけど。Sassのファイルも一緒に納品すればいいだけなので。
高津戸：そうですね。そういう仕事はやりやすいですね。そういうWeb制作会社とやり取りできる案件もありました。GitHubでやり取り、Gruntも使ってという環境でも、特に説明なくやり取りできて、とてもスムーズに進行しました。クライアントには、その制作会社から成果物だけを納品するので、問題はないんです。
——直にクライアントとやり取りをすると、それができないってことですか？
小原：それを先方が自分で修正するとなったときに、問題が発生するかな。
高津戸：個人的には、もうクライアントがファイルをいじるのは無理なんじゃないかなって思います。昔、Dreamweaverなど単一のツールで制作を行っていた時代は、クライアントでも十分、編集はできたと思います。最近はもうツール自体が複雑化している。Nodeが入っていて、Rubyも入ってて、Gruntが入ってて、Sassが入ってて、Compassが入ってて……というように、すごく複雑化しているんですよね。
小山田：HTML5のせいで、すべてが複雑になってきている。
高津戸：『せいで』はないよ。HTML5は関係ないじゃん（笑）。
外村：まあ、フロントエンド技術が複雑になり過ぎたから、そもそも、そういうツールを使わないと開発できない。それが使いこなせない人はソースにさわれなくなるっていうのは、流れとしては仕方ががないと思うんですよね。例えば、Ruby on Railsで書いたファイルを納品して、それをクライアントが自分で編集したりして運用するなんて、ないじゃないですか、普通。それと一緒ですよ。
高津戸：それはないね。確かにね。
外村：その昔、CGIで書かれていたようなやつは、クライアントも少しさわれたりしましたけど、だんだんサーバー側も複雑化してきて、Railsのようなフレームワークが登場すると、担当者レベルではさわれなくなりました。このサーバーサイドで起きたようなことが、このあと、フロントエンドでも起こってくるんじゃないかと思います。
高津戸：「さわれない」っていう認識になってないかも。
外村：昔はさわれましたからね。
高津戸：そうそう。
山田 順久：最近の複雑化したツールは、別に「こんなもんじゃないの」感はあります。むしろ、フロントエンドの開発環境が便利な技術の採用に出遅れてたと思うんですよ。
高津戸：なるほど。確かに。
外村：ああ、やっと追いついてきたっていうのはあるかもね。
小山田：ひょっとして、フロントエンドのソースも「さわれないもの」っていう認識が、今後、広がっていくのかなという気もします。
山田 順久：ニュースをちょっと更新したいというような場合は、まあ、静的なファイルを更新すればいいというふうに外部化していけばいいし……。
外村：ああ、簡易CMS的なものにするとかね。例えば、JSONを更新したら、ニュースが変わるとか。もうちょっとクライアントがさわりやすい環境を別に作ってあげるような方法をとるのがいいかも。そもそも、HTMLをちょっといじれば、サイトが思い通りに変わるような場合は、Sassのようなツールは必要ないしね。
小原：Backbone.jsで作られたようなものだと、すでにファイル構成をみただけで、ああこれは担当者レベルではダメだってわかると思う。どこになにがあるのか、わからないですからね。
外村：Backbone.jsとかさわれないよね、絶対。
高津戸：いじれたらすごいよ。逆に（笑）。
小原：そういうふうになってきているよね。
高津戸：なってきてますね。
小山田：それはたぶんみんな感じていると思う。それを感じてない人はたぶん……数年後に仕事がなくなってしまうんじゃないかと。
高津戸：どうかなあ。
小山田：同じ仕事しか、やれないってことだから。
高津戸：Twitterで@CodeGridのタイムラインのツイートを見ていると、「Gruntって最近フロントエンドで流行っているっていうけど、それは一部だけじゃないのかな」って言っている人もいるんですよ。そういう感想を読むと、やっぱり昔ながらのサイト制作というか、同じサイトをずっと更新し続けるというような仕事も、引き続き、残っていくのかなという気はします。
外村：分かれてくるのかな。
高津戸：そうね、分かれてくると思う。ピクセルグリッドは今、そういう2つのタイプの仕事が混ざっている状態。Canvasみたいな新しい技術を使ったサイト制作をやることもあるけれど、昔ながらのサイトの運用的な仕事もあるし。
——なるほど。古いものを作り替える案件っていうのは、ありましたか？
高津戸：あまりないですね。そういう古いサイトも「新しい技術を取り入れつつ、全部作り直したいですね」というような話を担当の方とすることもあるんですけど、現実的にはお金がかかることなので、難しかったりします。
——そうなんですね。
（続く）
ちいさいまとめ
フロントエンドの技術の複雑化に伴って、ようやく制作を効率化するフレームワークやツールが実用レベルにまでなってきた2013年。でも依然、単一のツールで作っていた時代の資源を引き継ぎながら、クライアントが運用する必要があるサイトもあります。
効率化を優先できる案件、クライアントでの運用を考えると安易に効率化ツールを導入できない案件。Web業界全体がそうだ、という話ではありませんが、ピクセルグリッドの2013年の業務では、その二極化が顕著だったようです。
ここまでのまとめ
- Flashのリプレイス案件では、Canvasを上手く使うことでスムーズな実装ができた。
- 納品後クライアントが編集をするような運営体制のサイトは、安易に、Sassなどの効率化ツールを導入することができない。
- Sassが使えない場合は、OOCSSの考え方を取り入れたモジュール一覧を作り、スタイルの組み合わせとコピー＆ペーストで運用してもらうのがよいかもしれない。
- バックエンドではRuby on Railsなどのフレームワークの普及につれて、かつてのようにクライアントが編集できるものという認識が変化してきた。
- フロントエンドもこれからバックエンドと似たような過程をたどり、クライアントがソースコードそのものを編集するような時代ではなくなるように思う。
- クライアントが直接さわれないサイトでも、ニーズがニュース更新などにあれば、テキストファイルの更新だけで、ニュースが更新できるような環境を、別途作って提供する方法もあるだろう。
- それでも効率化ツールを必要としない案件、やはり運用上の都合で効率化ツールを導入できない案件は今後もありつつける。
- 効率化ツールをどんどん導入しクライアントがさわれない案件と、クライアントがさわれるように効率化ツール以外の方法をとる案件と、二極化が進むだろう。
- ピクセルグリッドの2013年は、その案件の混在が特に印象に残った年だった。
座談会はこのあとも続きます。フロントエンドの技術が複雑化してきたという話を発端に、ではそれを操るエンジニアはどうなんだろう？ という話に発展していきます。