ピクセルグリッドの2013年 前編 二極化する業務

2013年のまとめとして、今年1年の業務の中で印象に残ったことを、ピクセルグリッドのスタッフ全員に語ってもらいました。今回は、2013年になって目立ちはじめた、案件の二極化についてです。

発行

  • 中村 享介
  • 高津戸 壮
  • 小山田 晃浩
  • 外村 和仁
  • 外村 奈津子
  • 德田 和規
  • 山田 順久
  • 小原 司
  • 山田 敬美
  • 坂巻 翔大郎
ピクセルグリッドの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年は、その案件の混在が特に印象に残った年だった。

座談会はこのあとも続きます。フロントエンドの技術が複雑化してきたという話を発端に、ではそれを操るエンジニアはどうなんだろう? という話に発展していきます。

中村 享介
PixelGrid Inc.
Jamstackエンジニア

2009年、JavaScriptの会社として株式会社ピクセルグリッドを設立。 多数のWebリニューアル、新規立ち上げを取り仕切った経験を持ち、情報設計、フロントエンド、クラウド活用、開発フローの効率化を得意とする。 Webをより発展させるため、新しくブラウザに実装された機能の活用事例を数多く生み出しつつ、日々、クラウドサービスを利用した効率のよい制作・開発手法の試行錯誤を続けている。現在の興味はWeb Componentsを使ったマークアップの改善とJamstack。 著書に『WebクリエイティブのためのDOM Scripting』(単著:毎日コミュニケーションズ、2007年)など。ここ数年は書籍の執筆をせず、フロントエンド技術情報メディア「CodeGrid」で精力的に執筆活動を行っている。

高津戸 壮
PixelGrid Inc.
テクニカルディレクター

Web制作会社、フリーランスを経て、株式会社ピクセルグリッドに入社。数多くのWebサイト、WebアプリケーションのHTML、CSS、JavaScript実装に携わってきた。受託案件を中心にフロント周りの実装、設計、テクニカルディレクションを行う。スケーラビリティを考慮したHTMLテンプレート設計・実装、JavaScriptを使った込み入ったUIの設計・実装を得意分野とする。 著書に『改訂版 Webデザイナーのための jQuery入門』(技術評論社、2014年11月14日)がある。 CSS Nite 2011ベストセッションにおいて、全170セッションの中から、ベスト10セッションに、CSS Nite 2013ベストセッションでは、全278セッション中、ベスト20セッションに選出。

小山田 晃浩
PixelGrid Inc.
フロントエンド・エンジニア

2006年よりWeb制作会社にてUI実装や運用業務を経験した後、2010年よりフロントエンド・エンジニアとして株式会社ピクセルグリッドに入社。これまでの経験の大半は大規模Webサイトの壊れにくいHTML/CSS設計、及び実装。また、SVG, Canvas, WebGLの扱いも得意としている。 外部に向けたアウトプットも積極的に行っており、カンファレンスでの講演などを多数こなしている。Tokyo WebGL Meetupの主催者。2011年から2021年まで10連続でMicrosoft MVP(Developer Technologies)を受賞。 著書に『Webデザイナー/コーダーのための HTML5コーディング入門』(共著:エクスナレッジ、2011年3月12日)や『CSS3デザイン プロフェッショナルガイド』(共著:毎日コミュニケーションズ、2011年5月28日)』などがある。

外村 和仁
フロントエンド・エンジニア

HTMLコーダー、JavaScriptプログラマ、PHP、Perlのプログラマといった職務を経験後、2010年に株式会社ピクセルグリッドに入社。大規模サイトの運用、開発の経験を活かしてバックエンドからフロントエンドまで幅広く担当。2015年、退社。好きな言語はJavaScriptとRuby。 著書に『ノンプログラマのためのJavaScriptはじめの一歩』(単著:技術評論社、2012年11月7日)があり、共著も多数。このほか、WEB+DB PRESS、Software Designなどにも寄稿。

外村 奈津子
PixelGrid Inc.
編集

情報出版社に在籍中、Mac雑誌、中高年向けフリーペーパー、コラムサイト運営、健康食雑誌、グラフィック・Web技術書籍編集、IT系ニュースサイトの編集記者を経験。その後フリーランスのエディター/ライターとして独立。2011年4月より株式会社ピクセルグリッドへ入社。ピクセルグリッドが提供するフロントエンド技術情報を提供するサービス「CodeGrid」の編集を担当している。

德田 和規
PixelGrid Inc.
テクニカルディレクター

HTML/CSSコーダーとしてWebに触れ、その後WebディレクターとしてJavaScriptの特性を活かしたサイトのテクニカルディレクションからUI開発までを経験。2011年にフロントエンド・エンジニアとして株式会社ピクセルグリッドへ入社。 著書に『jQuery逆引きマニュアル』(共著:インプレスジャパン、2010年12月17日)などがある。

山田 順久
フロントエンド・エンジニア

HTML・CSSのコーディング、後にJavaScriptの設計や実装を主業務として経験を積む。キャンペーンサイトやコーポレートサイトの、動きと操作性に工夫を凝らしたUI実装を多く手がけている。複雑なWebアプリケーション実装における、コンポーネント的な考え方を念頭においたJSの設計を得意とする。2021年、退社。 著書に『JavaScriptエンジニア養成読本』(共著:技術評論社、2014年12月11日)がある。

小原 司
PixelGrid Inc.
UIデザイナー

紙媒体をメインに制作しているデザイン事務所で広告デザインの基礎を学ぶ。2000年に独立。化粧品関連媒体の販促物を中心に、店頭グラフィック、パッケージ、POP、グッズ立案など多岐にわたるデザインを担当。2007年頃からWeb媒体へのデザインにも積極的に取り組み、クロスプラットフォームアプリのデザイン、画面設計、実装に携わる。2013年にピクセルグリッドに入社。現在では利用者にストレスを与えず迷わないユーザーインターフェースの設計とデザインに励んでいる。 著書に『ノンデザイナーズ・デザインブック[第4版]』(日本語版補足解説:マイナビ出版、2016年6月30日)などがある。また、マンセル色相環とムーン&スペンサー配色理論を採用した配色アプリ『HUE360』を1人でデザインから開発まで行い公開している。

山田 敬美
フロントエンド・エンジニア

Web制作会社、自社サービス運営会社などでサービス企画、マークアップ・エンジニアの経験を積むも、退職して1年間専門学校に通う。プログラミングの基礎を学んだのち、2013年4月、ピクセルグリッドのフロントエンド・エンジニアとして入社。CSSの設計を得意とするが、JavaScriptも好き。2019年、退社。 著書に『Sass入門 ~より効率的なCSSコーディング』(共著:技術評論社、2012年10月19日)や『CSS3デザインブック 仕事で絶対に使うプロのテクニック』(共著:MDN、2012年3月21日)などがある。

坂巻 翔大郎
PixelGrid Inc.
フロントエンド・エンジニア

大手ソフトウェアダウンロード販売会社、Web制作会社などで、マークアップエンジニア、プログラマ、サービス企画、ディレクターを経験。2013年、株式会社ピクセルグリッドに入社。HTML、CSS、JavaScriptなどをオールラウンドに担当。とりわけ、プログラマブルなCSSの設計、実装を得意とする。 趣味で作成したゲーム「CSS PANIC」は、JavaScriptを一切使わず、HTMLとCSSのみで実装。海外サイトで紹介されるなど話題となった。

Xにポストする Blueskyにポストする この記事の内容についての意見・感想を送る

全記事アクセス+月4回配信、月額880円(税込)

CodeGridを購読する

初めてお申し込みの方には、30日間無料でお使いいただけます