Photoshopで加工された画像をプログラムで再現

あんちぽくん: 技術的な話もしたいんですけど、技術的に「ここは工夫したぞ」っていう点があったら教えてください。

きたけー: 画像加工まわりですかね、やっぱり。
あんちぽくん: SUZURIやるぞって決定して、1週間もしないうちにくぼりゅーさんが画像加工部分のプロトタイプ作ってみんなに見せて「おお、これこれー！」って感じで盛り上がって、当初からコアな部分でしたよね、画像加工まわりは。そこからどういう感じの進化をしたんでしょうか。
くぼりゅー: 見え方の部分はデザイナーのデミさんがリードしてくれました。デミさんがプリントＴシャツの写真をまずPhotoshopで作ってくれました。このPhotoshopで作られた画像は、こういう工程で、こういうレイヤーで構成されてるので、これをプログラムで再現できないかなって。
あんちぽくん: でもそれって、Photoshop上で手動で微調整できるから成立するわけで、その方法をそのままコーディングにあてはめればうまくいくんじゃね？っていうのは、発想としてはそのとおりだとは思うんですど、実現はかなり難しいんじゃないですか？
くぼりゅー: そうですね。でもPhotoshopにあるディスプレイスメントマップとか焼き込みとかの機能は、ImageMagickにだいたいあるんですよ。
あんちぽくん: 合成画像の中でも特にTシャツの画像がすごくて、ユーザーがアップした絵がシワに沿って曲がってたり、ちゃんとシワの影がついてたりって加工をしてるじゃないですか。あのへんはどうやってるんですか？

galaxxxy　バケツスライム Tシャツ

くぼりゅー: このとおりにシワが入りますよっていう曲げる用のグレースケールのマップがあるんですね。アップされた画像をまずこの曲げマップに沿って曲げて、影を乗せて…途中はちょっと端折りますけど、順にTシャツのボディ画像に重ねていきます。最後に、プリント部分にだけもう一度、影を乗せる。Tシャツって無地の部分の影より、柄が乗っている部分の影のほうが濃いんですよ。なので、最後にプリント部分にだけさらに影を乗せるってことをやってるんですよ。
あんちぽくん: ただ全体に同じ色で影を乗せればいいかというとそうでもなくて、実際のTシャツは絵が乗った箇所の影が濃く見えるってことですね。それはどうしてそういう発見に至ったんでしょう。
くぼりゅー: デミさんのPhotoshopデータ上だとそうなってたんですよね。最初は、別にわざわざ上から乗せなくても、下から焼き込みで透けさせればいいんじゃないかっていう話だったんですけど、僕が「いや、上から乗せたいです」って言ったんですよね。クオリティが全然違うんですよ。そこまでこだわる必要もなかったのかもしれませんけど、何でしょうね、ヒマだったのかな…。
きたけー: いやいや（笑）。

「いや、ちょっとできないですね」みたいなのってダサい

あんちぽくん: ぶっちゃけ「そこまでやんなくてもいいんじゃね？」っていうところもあるじゃないですか。僕みたいな雑みたいな人間が見れば十分「いいじゃんいいじゃん」ってなる。でも作りこんだものを見たら見たで、作りこんでないものよりもっと良くなってるなってわかるわけで、くぼりゅーさんはそこまでのクオリティを求めたってことなんですかね。

だって、この話をモチベーションの部分抜きで話すと、デザイナーがPhotoshop駆使して作ったものを、プログラムでやれって無理矢理言われた超大変な人の話、みたいになりかねないじゃないですか。でも、自分でこだわってやれるところまでやるっていうのは、たとえば僕だったらそこまでやれないかもなーと思うので、純粋にすごいなと思うんですけど、なぜそれをやろうと思ったのかなって。
くぼりゅー: どうしてなんですかね、僕も普段はめんどくさいこと言われたら「イヤだな…」ってなるタイプなんですけど。どうしてやる気があったのかよくわかんないです。
あんちぽくん: 技術的なチャレンジみたいなところは大きかったんですかね。
貼りこむ時に、ゲームなんかのCGの世界だったら、テクスチャをもうちょっと工夫して、とかテクニックが色々あると思うんですけど、ウェブサービスで画像を作るときってあんまりそこまでやらないと思うんですよね。しかも動的にやってるわけじゃないですか。
くぼりゅー: 画像のアルゴリズムは全然詳しくないんですけど、Society6っていうサービスの画像合成のクオリティが高くて、ウェブでもここまではいけるんだなっていうのがありました。
あんちぽくん: その時のチームのテンションも関係あるんですかね。今でこそこういう処理をすればいい感じの画像になるって説明できると思うんですけど、最初からそう簡単にはいかなかったですよね、きっと。
くぼりゅー: 最初は全然ダメでしたね。がんばれたのは、やっぱりみんながんばってたからかな。デミさんのデザインもかっこいいし、画像もPhotoshopで作ってもらったし、ここでできないって言ったらダサいなって思って…。いや、それはちょっといい言い方をしすぎちゃったけど、ちょっと悔しいなって。
せっかく面白い部分を任せてもらったのに、「いや、ちょっとできないですね」みたいなのってダサいなと…。
あんちぽくん: ある意味エンジニアとして、ここは自分の勝負時だな、ってタイミングだったんですかね。
くぼりゅー: 画像合成に詳しかったり、ネイティブな言語で普通にできたり、もっとすごい人はいっぱいいると思うんで、そんな人たちに比べると全然だと思うんですけど…。
あんちぽくん: 画像合成部分の話だけじゃなくて、画像をアップロードするところとか、タイトルをかえていくところとか、SUZURI的なUIの流れでの画像合成の見せ方とか、UIの提案や実装ができるのって、やっぱりくぼりゅーさんしかいなかったのかなって感じはしますけどね。
おもしろいものを提案したり作ったりするのもそうだし、デザイナーとか他のスタッフが「これよくね？」って言ったものを実際に作って打ち返せるっていうのは、純粋に技術的な能力ですから。
くぼりゅー: ありがとうございます。

Ruby on Railsで動くSUZURIの中身

あんちぽくん: それでは少し全体的な話もしていきましょう。簡単にSUZURIのアーキテクチャについて説明してもらっていいですか。
きたけー: 今SUZURIのトップページで表示しているのがRuby on Railsで作られているアプリケーションです。商品の作成画面などに関しては、JavaScriptのフレームワークとしてBackbone.jsを利用しています。画像をアップロードした時に、それが合成された商品画像が出てくるんですけども、その画像を返すのが別のアプリケーションになっていて、僕たちの間ではそのアプリケーションをlensと呼んでいます。
あんちぽくん: 商品画像はそのlensを通して、画面に見えているってことですね。サーバーサイド側は大きく分けて2つコンポーネントがあって、ウェブアプリケーション全体を統括するRailsアプリケーション、それから画像合成を担当するlensと呼んでいるコンポーネントがあると。

フロントエンドは、Railsアプリケーションのビューと、もうちょっと表側のUIのところはBackbone.jsを使って実装しているっていう感じですかね。JavaScriptのフレームワークは、MVC的なフレームワークが複数あるわけですけど、その中からBackbone.jsを選択したのは何か理由があるんですか？
くぼりゅー: 開発を始めた時はすでにBackbone.jsはかなり古参だったんですよね。

あんちぽくん: 枯れたフレームワークって感じでしたよね。AngularJSとかも既にありましたよね？
くぼりゅー: Angularも検討したんですけど、AngularJSちょとキモすぎるなって自分があんまり好きじゃなかったっていうのと、SUZURIは基本、ECサイトなのでGoogleにインデックスされやすかったり、URLを公開してすぐ飛べたり、そういうことが簡単なほうがいいなっていうのがあって。

AngularJSは、それ自体でJSでページ遷移までしたり、そういうのは簡単なんですけどね。
あんちぽくん: Angularは、いわゆるシングルページアプリケーションを作りやすいフレームワークってことですよね。
くぼりゅー: 今回はあんまり合わないかなって思ったんですよね。でもSUZURIをリリースした直後に、思いっきりAngularで作られてるnoteっていうサービスがリリースされて、SEOもバッチリだったので、なんかごめんなさいって感じになりました（笑）。
noteはAngularJSで作ってあって、JSでページ遷移してるんですけど、直リンクしたときにサーバーサイドでちゃんとページを返すようなしくみもあるのでSEO対策もできてるんですね。PhantomJSとかでサーバーサイドでクライアントと同じ仕事をしてhtmlを作って返すみたいなことをしてるんじゃないかな。

いつGemにするんすか？

あんちぽくん: 見せ方的な部分で画像加工のお話がさきほど出ましたが、サーバーサイドでここはがんばってますってところはありますか？
きたけー: 画像加工まわりのレスポンスがかえってくるまでに時間がかかるんですね、一番大きいやつだと10秒ぐらいかかります。それをなんとか短くすることはできないかなって、くぼりゅーさんと一緒に試行錯誤しています。10秒っていうのはImageMagickを使った合成で10秒かかるので、合成の過程をキャッシュしたり、できあがったものをキャッシュしたりして。それでもまだかかるんですよね。
あんちぽくん: それは一番下のＴシャツの色は違うけど、その上に乗せる影を当てるレイヤーとかは同じだから、同じ部分はキャッシュできるってことだよね。
きたけー: そうですね。他にもCDNを使ってみたり、なんとかレスポンスが短くならないかなと試行錯誤しています。
あんちぽくん: 他にアプリケーション寄りの工夫はありますか。
きたけー: 作ってる途中でベタにコードを書いてて、なんかこれイケてないなって話に2人でなるんですよね。普通にGemにしてライブラリとして出してもいいかなって思ってるんですよね、まだそこまで手が回ってないんですけど。
あんちぽくん: ある程度共通化できるところは、外部にライブラリとして出すような形にしていこうぜってことですね。
きたけー: アクションの中でエラーが起きたら、エラー用のJSONを返すみたいにそれぞれのアクションで書いてたんですけど、それをもっときれいに書けないかなって2人で話してました。たとえば商品がアップロードされましたとか、トップページに出すオススメ商品をスタッフが選びましたとか、何かのイベントを起こす処理を、もっときれいに書くにはどうしたらいいかなとか。そういったイベントをトラッキングするようなライブラリを作ったり。
あんちぽくん: それ、もうGemになってるんすか。
きたけー: Gemにはなってないです…これから、これからできればいいかなーと。
あんちぽくん: これからやる感じ？いついつ？いつまでにやる感じ？
きたけー: え、え？じゃあ月末までに…！
あんちぽくん: では、このインタビューが世にでる頃には出てるんですね！

～第3話へつづく～

採用情報

SUZURIの中の話

SUZURIの中の話

今回の登場人物

Photoshopで加工された画像をプログラムで再現

「いや、ちょっとできないですね」みたいなのってダサい

Ruby on Railsで動くSUZURIの中身

いつGemにするんすか？