11歳のpixivが迎えた3度のリニューアル
渡邉拓巳氏（以下、渡邉）：「11歳のpixivが迎えた3度のリニューアル」というお話をします。よろしくお願いします。
（会場拍手）
まず自己紹介ですね、渡邉拓巳といいます。
do7beというIDとこのアイコンで活動しています。2016年の3月、ちょうど2年半ほど前にピクシブ株式会社に中途入社しました。いまはUX/UIエンジニアとして、主にPC版のpixivの開発をしています。この他には、「pixivFANBOX」というサービスの立ち上げなども行っていました。
最近、pixivの作品ページとプロフィールページをSPAとしてリニューアルいたしました。こちらがビフォーアフターですね。
左がビフォーで右がアフターなんですが、ビフォーではファーストビューにテキストがいっぱい出ていて、イラストがかなり下のほうにありましたが、アフターではファーストビューにイラストが出てきて、UIもシンプルなものに変わりました。
こちらがプロフィールページのビフォーアフターです。
クリエイターさんの作品の一覧性の向上だったり、UIのシンプル化だったり、よりポートフォリオとして使ってもらえるようなUIにリニューアルしました。
今日話すこととしては、このPC版pixivの作品ページとプロフィールのリニューアルのお話と、今回のリニューアルに至るまでに実は2度リニューアルに失敗しておりまして、その話をいたします。また、その3度のリニューアルに付随して、フロントエンドの技術がかなり変わりましたので、その話もします。
今日話さないこととしては、サーバサイドの話だったりSPAの話、リニューアルの裏話や、スマートフォン版・アプリ版のpixivの話です。
今回のリニューアルに至るまで
では、作品ページとプロフィールページのリニューアルに至るまでの話をしたいと思います。ちょうどいまから2年ほど前に、pixivのサービスの全面的なリニューアルを行おうとしていました。
こちらがpixivのトップページだったんですが、ページのデザインだけでなく、pixivというサービスのサービス設計そのもの、コア体験を変えようとしていました。
作品を開くときは、こういったかたちでモーダルで開くようにしていました。
例えば検索ページの一覧から作品を開いたら、このモーダルを閉じずに次の作品、次の作品と、パッパッと移動できるような、いまで言うSPAのようなものを作ろうとしていました。
これとは別に、ちょうど1年ほど前に、今度は作品ページのみリニューアルを行おうとしていました。それがこちらですね。
このときは、ページのデザインだけではなく、機能も同時にリニューアルしようとしていました。
しかし、残念ながら、決して数値などの結果が悪かったとかじゃないんですけれども、さまざまな理由からこの2度のリニューアルは中止となりました。pixivは今年で11年経ちますので、最長で11年続けている、だいたいの方は数年続けているようなユーザーが多い、このようなサービスでは、体験がすごく変わってしまうような大幅なリニューアルは、受け入れづらいのだということがわかりました。
デザインと機能は同時にリニューアルすべきではない
我々がこの2度の失敗から得た知見として、デザインと機能を同時にリニューアルしないほうがいいということがわかりました。
このリニューアルの中止から得た今後の方針なんですけれども、デザインと機能は同時にリニューアルするのではなく、変えるときは片方だけ、デザインのみを変えて、その後に機能を変えるというような、段階に分けてリニューアルしていく、こういったかたちを取ることにしました。
そして、リニューアルはすべてのページに行うのではなく、あくまでページ単位でやっていこうという話をしました。
そして、リリースする場合は少数ユーザーからリリースしていって、リニューアルに関するフィードバックフォームを設置することで、リニューアルがどうだったかということをユーザーからフィードバックを得て、フィードバックの内容によってはUIなどを変える、改善していくようなかたちを取りました。
先ほどの2度のリニューアルから、これからpixivはSPAのような体験を作っていくことがわかってきたので、SPAに耐えうる技術構成に少しずつアップデートしていくことにしました。その話をします。
フロントエンド技術の変遷
こちらが、2年ほど前のpixivと現在のpixivの技術構成です。
2年ほど前のメイン言語がCoffeeScript、ビルドがGrunt、テンプレートがHandlebars、スタイルがStylus、また、jQueryは1系を使っていました。
現在はメイン言語がTypeScript、ビルドがwebpack、コンポーネントはReact/Redux、スタイルがstyled-components、テストはJestで、LintがESLintとTSLint、jQueryは3系。あと、最後にお話ししますがStorybookというのも導入しています。
それぞれの移行についてお話します。jQueryは1系から3系に上げました。
上げるときは、jQuery公式が出しているUpgrade Guideというものがありまして、それに準拠して行いました。
また、その際にjQuery Migrate pluginというプラグインを入れました。このプラグインは、1系から3系に上げるときにDeprecatedとなってしまったメソッドを呼んでいる場合は、実行時に警告を出してくれるようなプラグインです。
また、1系から3系に上げるときに、メソッド自体がそもそもなくなってしまった場合はPolyfillをしてくれて、実行時にエラーにならずに警告を出すにとどめてくれるようなプラグインです。
このプラグインを使って、実行時に警告が出てきた.loadだったり、.bindだったり、.readyなどを移行しました。
また、バックエンドのテンプレートで、<script>だけで直書きしてるような箇所がいくつかあったので、そちらをbundle管理下に移動しました。
各技術の移行について
次に、CoffeeScriptからTypeScriptへの移行です。
このときはすでにwebpackを移行していたので、モジュール化をしました。import/exportに対応して、CoffeeScriptのexportしているような変数やメソッドの型定義を、.coffee.d.tsとして作成しました。
また、decaffeinateという、CoffeeScriptをJavaScriptに変換してくれるツールがあるんですけども、こちらを使ってCoffeeScriptをJavaScriptに変換しました。そして、先ほどの.coffee.d.tsを.d.tsにリネームして、先ほどのJavaScriptファイルと定義ファイルを使って、TypeScriptに書き換えていくといった手順で移行しました。
結果として、すべてのCoffeeScriptファイル、数十ファイルあったんですけれども、すべて移行完了いたしました。
次にビルドは、Gruntからwebpackに移行しました。
Gruntのときはconcatしていたものをwebpack bundleにしました。Gruntにはタスクが十数個あったんですが、それらをすべてnpm-scriptsに移行しました。
また、リニューアル後の先ほどの作品ページとプロフィールページでは、jQueryをimportしないようにしました。webpackでビルドする際にjQueryをimportしているとビルドエラーにすることで、jQueryをbudleできないようにしています。
次に、HandlebarsからReactなんですが、残念ながら移行はフルスクラッチしかできませんでした。
しかし、レガシーなpixivにしては、まだ使い回せるようなAPIもいくつかあったので、多少は楽ではありました。
次に、Stylusからstyled-componentsの話です。
Reactコンポーネント化に伴って、StylusからCSS Modulesに移行しました。ただ、よりコントリビュートが盛んだったり、可変にスタイルを変える実装が容易だったり、Providerから色情報をコンポーネントに渡すといった実装が非常に楽なstyled-componentsに移行することにしました。
Storybookの導入
最後にStorybookの話ですね。
StorybookはUIのカタログのようなツールで、ボタンのようなシンプルなコンポーネントから、モーダルのようなちょっと複雑なコンポーネント、カルーセルのようなコンポーネントまで、動作確認できるようなツールです。いままでリニューアルでは、軽度なデザイン崩れが非常に頻出してたので、その対策として導入しました。
現在のpixivでは、デザイナーがデザインガイドラインを用意してまして、すごく小さなコンポーネントからちょっと大きなコンポーネントまで、すべてガイドラインがありますので、UI単位で崩れていたら誰でもここで動作確認した際にすぐに気付けるようにしています。
こちらはStorybookにまとめている、リニューアル後のページで使用している色情報の一覧です。
これは管理が大変そうに見えるかもしれませんが、色を追加したら、勝手にここにもポンポンと追加してくれるようなかたちにしています。
GitLab CIによって、masterに変更が入るたびにジョブを走らせてビルドして、GitLab Pagesでホスティングしているので、社員なら誰でも常に最新のUIを確認することができます。
長期サービスのリニューアルで学んだこと
最後にまとめです。
やはり11年経つpixivのようなサービスでは、数年使い続けているユーザーがほとんどだと思います。そういったサービスでは、デザインの機能は同時にリニューアルしないほうがいいということがわかりました。
先ほどのプロフィールページでは、実際にデザインだけを先にリニューアルして、その後にピックアップ機能という、クリエイターさんが自分の作品だったりショップアイテムだったりをピン止めできるような機能を、後からリリースしました。
このように段階を分けてリリースしていくことで、ユーザーさんのフィードバックも良いものになり、結果として受け入れられたリニューアルができたんじゃないかなと思います。
また、2年前のリニューアルでは、モーダルを開いたり、ブラウザバックでそのモーダルを閉じたり、またフォワードで開いたりといったような実装を、すべてjQueryで実装しようとしていたんですけれども、その結果、かなりグチャグチャで、スパゲッティみたいなコードになってしまいました。
しかし、リニューアルを中止したからこそ、実現しようとしていた体験がどんなものかがわかり、どういった技術が必要なのかが把握できたので、アップデートする時間も取れました。まさに雨降って地固まるというようなもので、結果として良かったのかなと思います。
どのサービスのリニューアルもすごく大変だと思います。さまざまな事情で、方向性を変えようとか、そもそもリニューアルをやめたほうがいいんじゃないかとか、そういう話もあるとは思います。
そういったなかで、リニューアルをあきらめてしまう方も出てくるかもしれません。現に僕もこの2回のリニューアルの中止を経験して、正直心が折れそうになりました。
しかし、リニューアルするからには、我々にはなにかしらリニューアルしなければいけない理由があるはずなんだと思います。
僕の場合は、ユーザーの表現の自由だったり、好きなものを「本当にこれが好きなんだ」と言えるような場所を守るために、リニューアルが必要なんだと判断したから、諦めずに頑張れたんじゃないかと思います。
諦めなければリニューアルは達成できると思います。
今日来ていただいている方々のなかに、もしいまリニューアル中の方がいたり、これからリニューアルすることがあるのであれば、今回の話を思い出していただけると幸いです。あなたの現場のリニューアル、諦めないでください。
（会場笑）
以上です（笑）。発表終わります。ご清聴ありがとうございました。
（会場拍手）
ユーザーの反応をどうベンチマークしたか
司会者：ありがとうございました。質問がおありの方いらっしゃいますか？
質問者1：非常に貴重な発表ありがとうございました。一気にリニューアルせずに、細かく分割してリニューアルをしていくというところがすごく参考になったんですけれども。
体験向上っていうところを目的に置いたかなと思うんですが、実際に例えば細かくリニューアルした際に、実際のユーザーが「体験向上した」っていうふうに実感したかどうかっていうところっていうのは、なにかしら手法やアンケートを用いて、ベンチマークされていたのでしょうか？
渡邉：そうですね。フィードバックフォームを用意しています。これまでの3度のリニューアルで常にフィードバックは取っていたんですが、3度目のリニューアルでは、それまでのフィードバックとはかなり内容が違い、「使いづらい」という声はかなり減っているので、体験向上は得られたのかなと思います。
質問者1：なるほど。続いてもう1点質問なんですが、フィードバックをもらった際に、例えばあまりにも不評であるとなった場合は、ロールバックというか、以前のデザインに戻すというところも含めて、リリースを進めてきたっていう感じですかね？
渡邉：今回のリニューアルの話ですよね？
質問者1：はい。
渡邉：それで言うと、今回は、あまりにもそういった声が多ければ検討するということ話はあったんですけれども、そこはある程度は覚悟の上で我々は進めました。実際にはそういった声はあまり多くはなかった、という体感ではあります。
質問者1：ありがとうございました。
渡邉：ありがとうございます。
少数のユーザーを選ぶ仕組み
司会者：ほかに質問のある方いらっしゃいますか？
質問者2：新しい機能を作って、少数のユーザーからリリースするということでしたが、そのユーザーの決め方や、技術的にどうやって少数のユーザーだけに公開したのかお聞きしたいです。
渡邉：そうですね。さまざまな変更がこの1年間ぐらいあったんですが、やはり少数ユーザーから出していくということを常にやっていました。そんななか、対象のユーザーがかぶらないような仕組みを我々は作っています。
少数ユーザーから出したときに、毎回この人からスタートするとかだと、体験の偏りも出てきますので、そういった仕組みは作っていますが、その仕組み自体はあまり公開できるものではないので、すいません。そういった答えでよろしいでしょうか。
質問者2：大丈夫です。ありがとうございます。
渡邉：ありがとうございます。
司会者：では、渡邉さん、ありがとうございました。
渡邉：ありがとうございました。
（会場拍手）
