コミュニティマネージャーもデータ活用!#BigQuery #Looker の利用事例

こんにちは!初めまして、tkです! 2019年4月に入社し、pixivプレミアムやpixiv PAYの運営、pixivチームのコミュニティマネージャー(以下、CM)をやっております。

CMとは、「ユーザーの抱えている根本的な問題を改善するため最適解を導き、いろんな角度から改善していく」役割を担うお仕事になります。 詳細は下記、弊社役員のインタビュー記事をご参照ください!

inside.pixiv.blog

pixivチームのCMの主なお仕事は、カスタマーサポートです。 今回はカスタマーサポート業務にデータ活用を取り入れるために、BigQueryとLookerをCMで積極的に使い始めたよ、というお話をしたいと思います。

データ活用できて良いことは、「CMが自分で動けるから迅速にカスタマーサポートできる」「未来を見据えた仕事ができる」ですね!

カスタマーサポートとデータ活用

一見縁遠そうに見えるカスタマーサポートとデータ活用ですが、実はpixivユーザーの体験を向上させるための非常に良い友人です。

「ログインできない」「投稿できない」など、種別ごとのお問い合わせ数がどのように推移しているか、どの時期にお問い合わせが増えたか、どの言語設定のユーザーが多いか、このユーザーは何で困っているかなどなど。 これらの情報を時系列順に俯瞰したり、局所的に分析したりすることで、ユーザーが持つ「根本的な問題」を演繹する助けになります。

例えば、どの時期にお問い合わせが増えたかがわかれば、お正月、クリスマスなどの外的要因でお問い合わせが増えているのか、pixivのアップデートなど内的要因でお問い合わせが増えているのかがわかりますよね。

また、データは発言に説得力を持たせ、戦略的なコミュニティマネジメントを促進します。 ユーザーの悩みがまとまった数字として現れれば、改善に動くための指標がはっきりとし、施策の承認が得られ易くなります。 つまり、受動的なカスタマーサポートだけではなく、我々CMがユーザーの「根本的な問題」を解決する施策を打てるようになるのです。

しかし、上記のようなデータは、CMを含め全ての社員が簡単に確認できるものではありません。 毎日届くお問い合わせを手動で計測したり、経験則でレポートを作ることはできますが、pixivもおかげさまで大きなサービスとなり、現実的ではありません。

BigQueryとLooker、二人の救世主

そこで、我々CMのデータ活用を助けてくれるツールが、弊社には現在2つございます。

一つはBigQuery。SQLを用いることで複雑な条件を指定し、データを持ってくることができるデータウェアハウスです。 もう一つがLooker。簡単にデータを可視化(グラフ化)することができ、非エンジニアでも気軽に使用することができます。 それぞれの長所が、それぞれの短所を打ち消す形でCMのデータ活用を後押ししてくれています。 CMが使ってみての雑感なので、認識の相違があったとしても大目にみてください。

BigQuery

さてまずは、Google BigQueryです。 BigQueryはGoogleが運営するサーバーレス クラウド データ ウェアハウス。つまるところ、膨大なデータをしまう便利な倉庫です。 この倉庫にSQLという言語で話しかけると、爆速でデータを返してくれます。

BigQueryを利用することで、例えばお問い合わせいただいたユーザーにその時起こった問題を迅速に発見することができます。 BigQueryは他にも、エラーの影響範囲を調べたり、コンタクトをとりたいユーザーのリストを作ったりなど、複雑なオーダーにも対応し、我々に柔軟なデータ活用を可能にします。

一方で、SQLを扱えなければBigQueryを運用することが難しいという面もあります。いわゆるプログラミング言語ではありませんが、プログラミング経験のない非エンジニアが自由に使えるようになるには時間がかかるものに違いはありません。 幸い、私には少しばかりSQLの知見があったので、便利なSQLのテンプレートを作成し、共有することはできました。 しかし、BigQueryだけではpixivのCM全体がデータ活用できる場を整えるのは難しかったでしょう。

長所:複雑に条件を指定し、データを得ることができる。 短所:SQLを習得していないと活用することが難しい。

Looker

そこでCMチームが利用している2つ目のツールがLookerです。 Lookerは、ある人がSQLと分析の知見を持っていれば、その人と同じ切り口で、誰もがデータ分析や、情報の可視化をすることができる様になる夢の様なBIツールになります。 Lookerで分析するデータの参照元は、弊社では上記のBigQueryです。簡単に言ってしまえば、人間の代わりにSQLを話してくれる翻訳機のようなものです。

詳細は下記の記事をご参照ください。

inside.pixiv.blog

Lookerとは、x軸とy軸の指標を設定するだけで時系列などの属性ごとに推移を可視化(グラフ化)できるツールで、またこの設定を保存し、複数のグラフを組み合わせたダッシュボードを作成することもできます。 ちなみにpixivのCMチームでは、「お問い合わせの種別がどのように推移しているか、どの時期にお問い合わせが増えたか、どの言語設定のユーザーが多いか」といった指標に加え、問い合わせの返信までにかかった時間や、対応率などをダッシュボードで追いかける指標に設定しました。

こういったダッシュボードがあることによって、複雑な操作をせずとも、サービス上で起こっている問題に気付きやすくなります。

ダッシュボードの作成は、カスタマーサポートの業務をこなす中で、SQLや分析の知見が幾分かあった私と、弊社のデータの専門家集団”データ駆動推進室のみなさま”によって行われ、メンテナンスはCMである私によって行われています。 日々の業務での気付きをすぐに生かすことができ、見やすいグラフでCMがデータを共有できる体制になっています。ダッシュボードは、毎朝、社内で使用しているコミュニケーションツールの「Slack」に通知されるため、pixivのCMチームの全員が確認することができます。

Lookerはデータの可視化だけでなく、SQLの代替品としても機能し、比較的容易にBigQueryから情報をとって来ることができます。 ただし、BigQueryへ実際にSQLを用いるよりも簡単なお願いしかできず、情報の深堀りには向いていません。 もちろん、Lookerの整備に時間をかければ、Lookerは複雑化したニーズにも答えることはできます。ただし、都度そのコストをかけるかというと、難しいのが現実です。

長所:簡単にデータを可視化(グラフ化)できる。 短所:複雑なデータを取ってくるのには不向き。整備にコストがかかる。

つまり!

前述の通り雑感ですが、複雑なデータはBigQueryで、ずっと追っていたい比較的単純なデータはLookerで追えばいいじゃん!短所ないじゃん!という結論に私は落ち着きました。 全社的にLookerを利用し始めてから3、4ヶ月ほどの時間を使い、現在は、安定して運用できるようになりました。

データ活用を始める

私がデータ活用にコミットするまでCMチームでは、秘伝のSQLを使ってBigQueryを叩くことが数少ない能動的なデータ活用の機会でした。複雑なデータは、エンジニアに頼んで集計してもらっていました。

まずは秘伝のSQLを増やしていくことから始まり、今ではLookerのダッシュボードを導入し、毎朝全てのpixivのCMが指標を確認できるところまで辿りつくことができました。 ここまできてやっとデータ活用の萌芽を感じることができたような気がします。

CMが自ら触れるデータを増やすことで、サービスの開発に関わっているという、当事者意識が生まれ、積極的に施策に打ち込むことができるように思います。Lookerのおかげですね。 ユーザーの抱える根本的な問題を解決するために、今だけを見るのではなく、未来を見据えるための土台を作ることができました。 早急に解決しなければならない場合も、エンジニアさんに頼らずLookerやBiqQueryを活用して、CMだけで対応できるケースも増えています。 最初の方にも述べましたが、CMのデータ活用の利点は、「CMが自分で動けるから迅速にカスタマーサポートできる」「未来を見据えた仕事ができる」です。 ここに価値を見出せるあなたは、少しばかりのデータ分析の知識を手に入れ、環境づくりに励んでみましょう!

まずはSQLを学び、Lookerでなくともエクセルやスプレッドシートを駆使して、データを可視化するところから始めてみると何か見えてくるかもしれません。

pixivで検索エンジン向けにDynamic Renderingを実装した話

English version: Implementing Dynamic Rendering for Search Engines on pixiv.net - pixiv inside

pixivでプロダクトマネージャーをしているmu-koです。

大規模サービスのpixivで検索エンジン向けにDynamic Rendering(ダイナミックレンダリング)を2019年から実装し始めました。Dynamic Rendering実装の経緯や検証方法、注意点などをご紹介します。

pixivとは

pixivはクリエイターがイラスト・マンガ・小説を投稿し、声援をもらうことができるサービスです。

2019年9月時点で登録ユーザーは4,000万ユーザー超、投稿作品数は8,500万作品あります。また、日本からのアクセスは約60%で日本以外の国からのアクセスが約40%です。

日本国外のユーザーが作品を簡単に検索できるように、日本語タグを翻訳する機能を2018年に提供し、日本語が読めないユーザーでもpixivで作品を探せるように改善しました。

提案した翻訳が活用される例を知りたい – pixivヘルプセンター

ページ数やクロール数

現在8,500万作品が投稿されているため、作品画面だけで8,500万ページある状況です。

pixivの数字

それに対して、概算で以下の件数のクロールがきています。

  • Googlebotのクロール数は100~200万クロール / day1

  • Bingbotのクロール数は800~1,000万クロール / day

Dynamic Renderingを実装するまでの経緯

pixivでは2018年からSPA化を伴うリニューアルを少しずつ進めています。しかし、2018年時点ではログイン状態で表示されるページにスコープを絞ってリニューアルを行いました。ログイン前ページをSPAにした場合、Google検索などからの流入が最終的に減少する恐れがあると判断したためです。

検索流入が減少すると、投稿された作品が見られるチャンスを失ってしまうことになります。pixivとしては創作物の発揮する価値を下げてしまうことになります。これは本意ではありません。

しかし、ログイン前にもリニューアル後のSPA版をリリースしたいと考えていました。そこで、Dynamic Renderingを実装することを決めました。SSR(サーバーサイドレンダリング)することも検討しましたが、一旦SSRはしない方針を取っています。

pixivではカスタマイズしたRendertronを実装しました。 Rendertron は headless Chromiumをベースとしたレンダラです。

GitHub - GoogleChrome/rendertron: A Headless Chrome rendering solution

Dynamic Renderingを実装することにした理由

  • SPAで検索エンジンにインデックスされるまでの時間を短くするため
    Googlebotはクローリング後にJavaScriptベースのページをRender Queueに入れるため、インデックスされるまでの時間が長くなる可能性があります。
    Understand the JavaScript SEO basics | Search | Google Developers

  • SSRより開発コストが低いと判断
    開発コストが低いため、他の開発に時間を割り当てることができます。

  • Bingbotに対してもDynamic Renderingを利用しても問題ないことを確認したため
    詳しい情報はBing blogsに掲載されています。

Dynamic Renderingを実装した場合のデメリット

pixivの場合はDynamic Rendering用のサーバーを用意したため、別途監視する仕組みが必要になりました。

また、応答時間がSSRを実装した場合に比べて遅くなりました。

Dynamic Rendering実装後の検証

Dynamic Renderingを実装する際に、インデックス率やインデックスされるまでの時間を計測しました。

また、Dynamic Renderingを利用しない場合では、Render Queueの影響でインデックスまでどれくらい時間が掛かるか計測しました。

検証したことは以下のことになります。

  1. Rendertronの利用でコンテンツ量に影響がないか
  2. モバイルフレンドリーテストをクリアしているか
  3. 構造化データテストツールで正しく認識されているか
  4. URL検査ツールでページがどのようにクロールされているか
  5. 自社のアクセスログ上でクロール量に変化がないか
  6. インデックスに影響がないか

5, 6については1-4をクリアしてから検証した形です。

1. Rendertronの利用でコンテンツ量に影響がないか

Rendertronから出力されたHTMLを見て、pixivでは以下のような要素に影響がないかを確認しました。

  • スタイルに影響を与えていないか
  • LazyLoadされるコンテンツが正しく表示されているか

2.モバイルフレンドリーテストをクリアしているか

モバイルフレンドリーテストツールでテストをクリアするか確認しました。

3.構造化データテストツールで正しく認識されているか

構造化データテストツールのUAからのアクセスに対してRendertronを通すようにしてテストしました。

4.URL検査ツールでページがどのようにクロールされているか

少数のページでDynamic Renderingを実装し、Google Search Console上でどのように認識されているかを確認しました。

すでにクロールされたページは「VIEW CRAWLED PAGE」から結果を確認できます。 このHTMLを確認してコンテンツ量が減っていないかをさらに確認しました。

5.自社のアクセスログ上でクロール量に変化がないか

GooglebotのUAを用いて、SPA化されたページのクロール量が変化ないかを調査しました。

この調査をしたことで新規公開されたページがどれくらいの時間でクロールされるかを知ることもできました。

6.インデックスに影響がないか

Dynamic Renderingが実装されたページと実装されていないページでインデックス率に差が出るかを調査しました。合計20回以上のテストを行い、様々な調整をした際にどのような影響があるかを確認しました。

結果を簡単にまとめると、新規公開されたSPA版のページでDynamic Renderingを実装しない場合は、最終的なインデックス率が10~15%低くなることがありました

また、最終的なインデックス率は同等になる場合でも、インデックスされるまでの時間が3日以上遅くなることがありました

テストによってはSPA版のページでDynamic Renderingを利用しなくても順調にインデックスされることがありました。

しかし、基本的にはDynamic Renderingを利用しない場合はRender Queueの影響でインデックスされるまでの時間が遅くなったと考えています。

Dynamic Rendering実装時の注意点

コンテンツ量に影響がないか

コンテンツ量が減った場合はインデックス率や評価に影響する可能性があります。そのため、コンテンツ量が減っていないかを確認するために上記の検証などをすることをおすすめします。

応答時間が長くないか

Rendertron用のサーバーがGooglebotのリクエストをさばけるか注意する必要があります。 Rendertronのデフォルトのタイムアウトは10秒になっています。pixivは無駄な読み込みの待ち時間をカットするためにタイムアウトを3秒に変更し、同時にさばけるリクエスト数を増やしました。

キャッシュを有効化する手段もありますが、pixivでは有効化しませんでした。ページ内容の更新頻度が高く、キャッシュの管理が複雑になるためです。

最後に

pixivは今後10年の開発効率やユーザーの利便性向上のためにSPAベースにすることを決めました。その上で投稿作品をより多くの方に見ていただくために、SEO面ではDynamic Renderingを実装しました。

この記事がSPAベースのサイトでSEOに悩んでる方の助けになればと思います。

何かご質問がありましたら、以下のサービスからご連絡お願いします。


  1. ※これはUser agent tokenがGooglebotと定義されているクローラの数値になります。Mediapartners-Googleのクローラの数値は含んでいません。
    Google のクローラ(ユーザー エージェント) - Search Console ヘルプ 

Implementing Dynamic Rendering for Search Engines on pixiv.net

Japanese version: pixivで検索エンジン向けにDynamic Renderingを実装した話 - pixiv inside

Hello, I am mu-ko, a product manager at pixiv.

This year, we have implemented Dynamic Rendering for Search Engines such as Google on our largest service, pixiv.net. In this article, I will be talking about the background behind our Dynamic Rendering implementation, reexamining methods, and notes.

What is pixiv

pixiv is a service for creators to post illustrations, manga, and novels.

As of September 2019, there are over 40 million registered users and 85 million works. Accesses from Japan amount to approximately 60%, the rest being from overseas.

In order to make it easier for users outside Japan to find artworks, we provided a feature for users to suggest translations for the Japanese tags in 2018, so that even users who can't read Japanese are able to find artworks on pixiv.

I want to know how my translation will be used – pixiv Help Center

Number of pages and crawls

  • About 85 million work pages
  • etc

pixivの数字

  • Googlebot crawls 1 to 2 million pages / day1

  • Bingbot crawls 8 to 10 million pages / day

The background behind the implementation of Dynamic Rendering

pixiv has been gradually transitioning to SPA since 2018. However, the renewal was visible only to logged-in users. This was because it has been determined that if pixiv's pre-login pages become SPA, the traffic from Google Search or the likes may eventually decrease.

If search traffic decreases, discovering new artworks will become harder.

However, we wanted to release the new (SPA) design for not logged-in users. Since the SPA are rendered Client Side, the options were either Server Side Rendering or Dynamic Rendering. Implementing SSR was cost-prohibitive, so we decided to implement Dynamic Rendering instead.

To implement Dynamic Rendering we used a customized Rendertron.

Rendertron is a headless Chrome rendering solution designed to render & serialise web pages on the fly.

GitHub - GoogleChrome/rendertron: A Headless Chrome rendering solution

Why Dynamic Rendering?

  • Allow the bots to index the pages faster

Googlebot can render and index Client Side Rendered pages, but it’s slow and there’s a high probability of pages being stuck in the Render Queue for some time, therefore it will take longer for CSR SPA pages to be indexed.

Understand the JavaScript SEO basics | Search | Google Developers

  • Development costs were lower than SSR

Since the app was not built with SSR in mind initially, rebuilding it would take considerable effort, time we can spend instead on other development.

  • It was confirmed that there is no problem using Dynamic Rendering for Bingbot

More information is available on Bing blogs.

Disadvantages of Dynamic Rendering

  • The response can only be “good enough” for bots, unlike SSR.
  • Can’t be used to render the pages to end users.
  • To check the Dynamically Rendered pages we had to implement a custom workflow when monitoring the renderer servers.

Examining the Dynamic Rendering implementation

When implementing Dynamic Rendering, we measured the index rate and the time it took to index.

Also, when Dynamic Rendering was not implemented, we measured how long it took to index due to the influence of Render Queue.

We examined the following:

  1. Does pre-rendering using Rendertron affect the content of the page?
  2. Does the page pass the mobile-friendly test?
  3. Is the structured data on the page correctly recognized by Google’s Structured Data Testing Tool?
  4. How are pages crawled by URL inspection tools?

------- Examinations after passing the first 4 steps -------
5. Is there a change in the crawl volume in the access logs?
6. Is there an effect on the index?

1. Does pre-rendering using Rendertron affect the content of the page?

We checked the HTML output from Rendertron and confirmed that some things were missing from it:

  • CSS on React pages - we are using Styled Components and the implementation does not render the styles inside <style> tags by default
  • Lazy-loaded content - the default viewport for Rendertron was too small for our use case

2. Does the page pass the mobile-friendly test?

We confirmed that it indeed passes the test with the mobile friendly test tool. Rendertron allows us to request the mobile version of the website for Googlebot.

3. Is the structured data on the page correctly recognized by Google’s Structured Data Testing Tool?

We tested this by enabling Dynamic Rendering for the UA of Structured Data Testing Tool.

4. How are pages crawled by URL inspection tools?

We implemented Dynamic Rendering on a small number of pages and confirmed how it was recognized on Google Search Console.

We can check the results of crawled pages from "VIEW CRAWLED PAGE". We compared this HTML to the client-side rendered page, and made sure there is no missing content.

5. Is there a change in the crawl volume in the access logs?

By scanning our access logs for Googlebot's UA, we investigated whether the amount of crawling on SPA pages changed.

By doing this research, we also found out how long it takes for a newly published page to be crawled.

6. Is there an effect on the index?

We investigated whether there is a difference in the index rate between pages with and without Dynamic Rendering.

We performed more than 20 tests in total. And we checked the effect of various adjustments.

To summarize the results, the final index rate can be 10-15% lower if Dynamic Rendering is not implemented on newly published SPA version pages.

In addition, even if the final index rate were to reach the same level, the time it takes for a new page to be indexed was delayed by more than 3 days.

Some tests were indexed smoothly without using Dynamic Rendering on SPA pages. However, if Dynamic Rendering is not used, the time until indexing is delayed due to the pages being stuck in Render Queue.

Important notice when implementing Dynamic Rendering

Make sure the content does not change

If the amount of content decreases, it may affect the index rate and evaluation. Therefore, it is recommended to perform the above verification to confirm whether the amount of content has decreased.

Pay attention to response time

We need to be careful about the time it takes for the Rendertron server to handle Googlebot requests.
Rendertron's default timeout is 10 seconds. pixiv changed the timeout to 3 seconds and optimized the SPA for it, in order to cut the waiting time for unnecessary loading, thus increasing the number of requests to be processed at the same time.

There is a way to enable caching for Rendertron, but pixiv did not use that feature. This is because our page contents update frequently and because of that, cache management is going to be extremely complicated.

Finally

pixiv has decided to make its frontend SPA-based in order to improve development efficiency and user convenience over the next 10 years. On top of that, we implemented Dynamic Rendering so that more people can reach the submitted artworks.

I hope this article will help those who are struggling with SEO on SPA-based sites.

If you have more questions, you can find me at:


  1. This is the number of requests by crawlers whose User-Agentis reported as Googlebot. The Mediapartners-Google crawler is not included.
    Google crawlers (user agents) - Search Console Help 

新卒デザイナーが「pixiv最大規模のユーザー企画」のプロジェクトを任された話

自己紹介

こんにちは、pixivでデザイナーをしているganchanです。元々は福岡オフィスでデザイナーとしてアルバイトをしていて、2018年4月に新卒で入社しました。 本記事ではpixiv最大規模のユーザー企画、「pixivファンタジア」の10周年イベントに新卒デザイナーが携わって得られた経験について紹介します。

きっかけ

pixivファンタジア10周年を記念して、pixivが開催を支援することが正式に決まったときに、「興味があるならやってみないか」と声をかけてもらいました。

案件の下調べをするため、pixivファンタジアの歴史や今までに投稿されたイラストを眺めているうちに、どんどんこの企画に興味が湧いてきました。私自身が絵を描いていることもあり、「この企画に参加したい!そしてデザインも担当したい!」と強く思いました。

しかし、その時はまだ新卒7ヶ月目でしたので、pixiv内の大型プロジェクトやゲームライクなデザインは担当したことがありませんでした。そのため、私がやり遂げられるか不安でしたが、こんな面白そうな企画にチャレンジしないのはもったいないと思い、挑戦することにしました。

pixivファンタジアについて

「pixivファンタジア」はarohaJさんが主催する「ファンタジーイラストを盛り上げる」ユーザー企画です。参加作品の閲覧数によって競われるバトルと、その結果によって変化するストーリーが特徴です。また、参加者が新たな設定を創造し、自由に世界観を拡張できます。

2018年でシリーズ10周年を迎え、pixiv事務局が開催に協力しました。現在10シリーズ累計の投稿数は約25万作品を超え、毎回の平均参加者は約5,000人を超えるpixiv内最大規模のユーザー企画となっています。

今回開催したpixivファンタジア Last Sagaでは、新たな物語の舞台「ラスト大陸」で三国にわかれ、大陸の覇権を争いました。

ペーパープロトタイピング

今回の企画をリリースするために、下記の手順で作業を進めました。

  • 目標定義
  • 企画内容決め
  • ユーザーペルソナ定義
  • ユーザーのモチベーション定義
  • 情報設計
  • 画面設計
    • ペーパープロトタイプ
    • デザインツール「Figma」でデザイン
  • 開発
  • リリース

本記事では、主に画面設計でやったことについて詳しく説明します。

画面設計をはじめるにあたり、プロダクトマネージャーからペーパープロトタイプについて説明された本を紹介されました。

プロトタイピング実践ガイド スマホアプリの効率的なデザイン手法

ペーパープロトタイプとは、デザインや実装を始める前に紙とペンを使ってデザインの試作品をつくるものです。パソコンでデザインするよりもすばやく試作と改善を繰り返せます。

まずはこの本を読みながら、実際に自分でペーパープロトタイプを作成しました。ペーパープロトタイプを一度作った後、様々な人にレビューをしてもらっては改善をすることを繰り返し、徐々に完成度を上げていきました。

ペーパープロトタイプで大まかな仮枠を作った後は、デザインツール「Figma」を使って、ブラッシュアップしていきました。

Figmaのメリットを2つ紹介します。

  • 1つのファイルを複数のデザイナーがWebブラウザ上でリアルタイムに編集できる
  • エンジニアがWebブラウザ上でリアルタイムでデザインを閲覧できるため、ファイルの共有や管理コストが低い

Figmaはとても便利なデザインツールで、このおかげでエンジニアやディレクターとのコミュニケーションも円滑に行うことができました。

世界観を壊さないために

この企画のデザインをする際に気をつけていたことは、pixivファンタジアの主催がpixivだと勘違いされないようにすることです。 あくまでもpixivファンタジアの主催者はarohaJさんであり、pixivはarohaJさんの企画に協力している立場であることが、誤解なく伝わるように努めました。

まずは、pixivファンタジアのページにarohaJさんが主催であることを明記しました。加えて、LPにはarohaJさんからメッセージを頂戴し、記載することにしました。

さらに、arohaJさんが10年間で作り上げたpixivファンタジアのブランドを壊さないように、細心の注意を払いました。 このことについて上司に相談したところ「デザインルールを定めるといいよ」とアドバイスをもらいました。そのため、まずはデザインルールを定めることにしました。

過去10回開催されたpixivファンタジアから、今回の企画にテイストが近いものを参考にし、button, font-size, color など、様々な要素のデザインルールを決めました。ルールを決める際には、arohaJさんとも念入りに打ち合わせをして、arohaJさんの考える世界観やテイストにマッチするように微調整を繰り返しました。 このデザインルールに従うだけで、自然とpixivファンタジア Last Sagaのテイストが表現できる仕組みができました。

失敗から学んだ要件を明文化する大切さ

プロジェクトの開始当初は「なぜこのデザインなのか」を言語化しておらず、デザインの作り直しが何度も発生するという失敗がありました。 例えば、「これあると良さそう」という直感で新しい要素を追加したことがありました。しかし、新規要素をなぜ追加したのか開発メンバーから質問されたときに答えられず、デザインを作り直すことがありました。

こういった失敗を繰り返さないためにプロダクトマネージャーに相談し、毎回以下の要件を定義してから、デザイン要素の追加をするようにしました。

  • 概要 (作りたい機能を1行で説明したもの)
  • その機能で実現する三箇条
  • ターゲットユーザー (この機能を使ってくれるユーザーは誰か)
  • ワークフロー (ユーザーがどんな手順でこの機能を使ってくれるか)

この4つの要件を明文化した後にデザインすることで、以下の3つのメリットがありました。

  • デザインするときに考えやすくなり、手戻りが減る
  • デザインの理由を開発メンバーに説明できる
  • チームで議論するときの基準がある

要件を明文化する仕組みを利用することでデザインの作り直しがなくなり、デザインスピードが上がりました。

まとめ

イベント全体の結果として

  • 総投稿数:45010枚
  • 参加者数:4984人
  • 1人あたりの平均投稿枚数:9.56枚

と多くのユーザーの皆様に楽しんでいただけました。特に1人あたりの平均投稿枚数は歴代最高となり、(※前回の『pixivファンタジア Revenge of the Darkness』では6.64枚)直近では一番盛り上がったシリーズとして締めくくることができました。

この企画に携わってみて、デザインを作成する前に要件を明文化するべきことを学びました。その後の他のプロジェクトを担当するときにも要件の明文化をまず行っています。その度に、pixivファンタジアの開発に携わった経験が役に立っていると実感しています。

入社一年目でpixivファンタジア Last Sagaのデザインをやり切ることができたのは、「チームで助け合い、チームで仕事をする」というピクシブの環境があったからだと考えています。この経験を活かし、自身も他のチームメンバーをフォローできるデザイナーとして成長していきます。

「pixivの認知を広げ、さらに成長させていきたい」17新卒・アソシエイトプロダクトマネージャーにインタビュー!

人事・新卒採用担当のnaiです。 学生さんとお話をしていると、ピクシブの社員が実際どんな業務をしているのか?という質問をいただくことが多くあります。前回の出版社営業に続き、今回はアソシエイトプロダクトマネージャーの仕事をご紹介!仕事の内容ややりがいについてインタビューしました!

本日はよろしくお願いします。まずは自己紹介からお願いします。

2017年の4月に新卒で入社したmu-koです。入社から現在までずっと、pixiv運営本部でアソシエイトプロダクトマネージャーをしています。趣味は健康になることで、食事・睡眠・運動をどうやったら改善できるかよく考えています。最近はヨーグルトを毎日食べています。

pixiv運営本部とはどのような部署でしょうか?

文字通り、「pixiv」の開発・運営を行っている部署です。その中で「Web」「アプリ」「レコメンド」「小説」「コミュニティ」の5つのチームに分かれていて、僕はWebチームに所属しています。ユーザーにより便利に、楽しくサービスを使ってもらうための機能を開発するチームですね。

pixivという1サービスの中でも、細かくチームが分かれているんですね!では、アソシエイトプロダクトマネージャーというのはどのようなお仕事でしょうか?

pixivユーザーに向けた新機能開発や既存機能の改善を行っています。作業としては、機能の仕様を考えたり、実装した後の結果を分析したりすることが多いですね。

ユーザーに向けた機能とは、たとえばどのようなものでしょうか?

去年は英語圏ユーザーに向けて、pixivの日本語タグを翻訳して提供する機能をリリースしました。ユーザーから日本語タグに対する英訳の提案を集めてpixiv上に反映していく仕組みを考えたり、関わる法律を調べて調整を行ったりしました。

現在pixivでは、未翻訳の単語や文章をなくしていくという翻訳プロジェクトが進んでいて、その一環として実装した機能です。ユーザーに英語でアンケートを取り、どういう機能にしたら使いやすいか、という声を集めました。

ユーザーの声を聞きながら、新しい機能を考えていくんですね。

そうですね、ユーザーにフォーカスをあてることは常に意識しています。どのユーザーがどのような課題を持っているのか、どうすればそれが解消されるのかを考えています。アンケートなどで調査をすることもあります。

課題と言うのは、サービス運営上の課題ですか?

はい。ユーザーからお問い合わせをいただいて課題に気付くこともありますし、自分で考えたり、エンジニアと話していて生まれたりすることもあります。課題が明確になったら解決策を考えて、仮説を立てて、目標を決めて、実装後にその結果を分析します。



Webチームに所属しているというお話でしたが、チームメンバーは何名いるのでしょうか?

ビジネス職は僕1人だけです。他にデザイナーが2名、エンジニアが9名います。

ビジネス職が1人!ということは、先程仰っていたお仕事はすべてお1人でやられているんですか?

いえ、課題や目標はデザイナーと考えることが多いです。課題設定から一緒にやることで、目指す場所をみんなで決めることができて、チームの中で方向性がぶれることなく進められています。

職種ごとの分業ではなく、チーム一丸となって取り組んでいるんですね!職種が異なるメンバーとのコミュニケーションで、心がけていることはありますか?

まずは感謝を伝えることだと思います。あとは、自分の考えが絶対正しいとは思わないこと。「でも」と反論するのではなく、いろんな人の意見を素直に聞くように気を付けています。実際、自分にない視点で意見をいただくことが多いのでありがたいです。

17新卒ということは、入社して3年目ですよね。チームを任されたのはいつ頃からだったのでしょうか?

今のチームを任されたのは、ちょうど入社1年後くらいだったと思います。期間限定で単発のプロジェクトが発生することがあるんですが、その管理は1年目からやっていましたね。かなり裁量大きくやらせてもらっています。

1日の仕事のスケジュールを教えてください。

日によりますが、たとえばこんな感じです。

  • 10:00 朝会(その日行うタスクを毎朝チームで確認)
  • 11:00 デザイナーと機能の仕様を考える
  • 13:00 ランチ
  • 14:00 前週にリリースした機能のデータ分析
  • 16:00 エンジニアが開発した機能の動作確認
  • 17:00 エンジニアやデザイナー用のタスクの用意や整理
  • 18:30 夕会(その日の進捗を毎夕チームで確認)

pixiv運営本部の他のチームのプロダクトマネージャーとのミーティングも定例でやっています。単発のプロジェクトや採用関係のミーティングなど、他部署の人と関わる機会もたくさんあります。

仕事のやりがいはどんなところですか?

リリースした機能について、ユーザーからポジティブなコメントや感謝をいただいたときはとても嬉しいです。

他には、日本から海外へ大きな影響を与えられているところでしょうか。海外ユーザーも増えてきていますし、貴重な経験ができていると思います。

逆に、どんなところに難しさを感じますか?

自分で考えた仮説が正しくなくて、リリースした機能が思ったように使われないときは辛いですね…。ただそういった場合でも、チームで仮説検証を繰り返しながら進めていくので、最終的には目標を達成できていることが多いです。

上手くいかないことがあった時、チームで乗り越えられるのは良いですね!ご自身が成長したな、と思うのはどんな時でしょうか?

今まで自分ができなかったことができるようになった時です。特に強く感じたのは、BigQueryでSQLを用いてデータ分析ができるようになった時でした。

BigQueryというのはデータ分析のツールで、学生の頃に使っていた別のツールよりも詳細なデータが正確に取れるんですね。これは革新的だ!と思いました。ただ、使うにはSQLという専門知識が必要なんです。入社してから勉強を始めて、業務に必要なレベルまで身につけることができたのは、3,4か月後くらいでしょうか。新しいツールを使えるようになったことで仕事の効率も上がりましたし、成長を実感しました。

今後はどんなチャレンジをしていきたいですか?

日本以外のユーザーにももっとpixivを知ってもらえるような開発を、これから行っていく予定です。きっと来年には、pixivを認知・訪問する海外のユーザー数が大きく増加していると思います。そのために、pixivに表示されている日本語の翻訳を今よりもっと進めていって、海外の検索エンジンからもユーザーが流入できるようにしたいです。

伺っていると、サービスの成長への思い入れの強さが伝わってきます。もともとサービス開発のお仕事に興味があったんですか?

そうですね。就職活動では、自社でWebサービスを開発・運営している企業を中心に見ていました。

子どもの頃からPCやWebが好きで、どんどん新しいサービスが生まれて成長する様子にわくわくしていたんです。多種多様な人々がWebサービスや会社を作るのを見て、これはビジネスチャンスだなと。次第に、自分でもWebサービスを作り出して、世の中に提供したいと思うようになりました。

で、学生時代はITベンチャーでインターンをしてみたり、自分でもWebサービスを作ってみたりして。それが楽しかったので、仕事でも似たような経験を積みたいなと考えていました。

自社でWebサービスを運営している企業はたくさんありますが、ピクシブに入社を決めたのは何故ですか?

ピクシブは、サービスは知っていたけど会社についてはあまり詳しくありませんでした。就職系のメディアで偶然見かけたのがきっかけで、自分がやりたいことができそうだと感じ、そこから興味を持ちました。

決め手になったのは、1週間の選考インターンですね。ピクシブの社員と働くのがとても楽しかったし、成長できそうなイメージが湧きました。自分で様々なことを体験することが好きなので、会社の雰囲気を実際に味わえたことは大きかったです。

選考インターンで会社の雰囲気や人の良さに魅力を感じた、という声は多いですね!最後に、学生へのメッセージをお願いします。

ピクシブには、人の意見を尊重して一緒に考えられる人や、新しい技術や情報に興味を持って挑戦し続ける人が集まっています。僕はこういう人たちが好きで、一緒に働くのもとても楽しいです。

でも、社員の性格がどうとか、自分がそこに馴染めるかっていうのは、実際に中に入ってみないと分からないんですよね。なので、もし志望している業界や企業があるなら、ぜひバイトやインターンとして参加してみるために行動してみてください!もちろん、ピクシブでもお待ちしています!

ありがとうございました!

ピクシブでは通年で新卒採用を行っております。 興味のある方はぜひ下記をご覧ください。皆様のご応募、心よりお待ちしております!

21新卒募集要項:エンジニア職 / ビジネス職 中途採用募集要項 / Wantedly

最新の情報は下記公式Twitterで随時発信しております。ぜひフォローしてくださいね!

公式Twitter: @pixiv_corp

毎秒1万リクエストの負荷試験をした話

はじめまして。ピクシブで広告関連のプロダクトを開発しているeastです。今回は、社内で運用している広告配信サーバーの負荷テストを実施したので、その話をしたいと思います。

経緯

ピクシブの広告配信サーバーは、pixiv本体を中心に複数のサービスに対して広告配信を行なっています。現在私はこの広告配信サーバーの大規模改修を行なっているのですが、先日ついに広告配信サーバーの改修がほぼ完了したので、試しに負荷試験を行なってみたいと思い立ちました。

目標は毎秒1万リクエスト

ピクシブの広告配信サーバーへのリクエスト数はDailyで 4〜6億req もあり、これは毎秒平均に直すと約 5,000RPS(Request Per Second) になります。さらに、ピークタイムである休日の深夜帯には 12,000RPS にも達します。つまり新しい広告配信サーバーにも、毎秒12,000のリクエストを捌く性能が必要ということです。

負荷テストツールの選定

負荷テストを行うためのツールはいくつも存在しており、どれを使うか迷ったのですが、最終的にはLocustを使うことにしました。

Locustは、OSSのPython製負荷テストツールです。Locustを選んだ理由としては、

  • GUIのダッシュボードが使えて途中経過もリアルタイムで見れる
  • LocustはPythonでテストシナリオを書ける(個人的にPythonは書き慣れてるので)
  • Pythonで独自の拡張もできる

等が挙げられます。単純に負荷を与えるだけなら、CPU効率の良いツールが他にもありました。しかし、他の有名なツールはXMLで独自の記法でテストシナリオを書く必要があったりと取っつきにくい物が多かったため、ツールとしての使いやすさからLocustを選びました。 ちなみに、採用を迷ったツールの1つがTsungです。 Tsungを選択しなかった理由は、

  • XMLの独自形式でシナリオを書く必要があるので学習コストが高そうだった
  • ダッシュボードがないのでテスト中の観測や調整がしづらい
  • Erlang、Perlと言った、普段自分が使っていない言語で書かれているので、拡張しにくい

等で、Locustを選択した理由の裏返しとも言えます。単純なCPU効率ならTsungの方が優秀だったと思いますが……

総じてLocustは負荷テストツールとして癖が少なく敷居が低いので、小〜中規模の負荷テストなら特にオススメです。

また、Locustを動かすためのインフラとしては、Google Cloud Platformから提供されているGoogle Kubernetes Engine(GKE)を採用しました。GKEなら発生させたい負荷に応じて容易にクラスタをスケールすることが可能なためです。これにより、小規模・短期間の負荷テストから、大規模・長期間の負荷テストまで幅広く対応することができます。また、必要な時だけマシンリソースを増加させることができるので、負荷テストに必要な金銭的コストを削減することにも繋がります。

負荷テスト環境構築の流れ

基本的にはこのページを参考にしつつ独自に改良を加えました。

大まかな流れは以下のようになります。

  1. GKEのクラスタを作成
  2. Locustの設定ファイルの作成
  3. Docker Imageの作成
  4. Master Podのデプロイ
  5. Worker Podsのデプロイ
  6. Masterのserviceをデプロイ
  7. ダッシュボードから負荷試験開始

テンプレート用のリポジトリを作成してあるので、これを利用して進めていきます。

ちなみに、負荷試験中サーバーのモニタリングはPromethus + Grafanaで行いました。

GKEクラスタの作成

GKEクラスタ作成の方法や、gcloudコマンド、kubectlが使えることは前提とします。GCPは公式のドキュメントが充実してるので、初めての場合でもそれほど迷わず設定できると思います。

それでは、Locustを動かすためのGKEクラスタを作成します。負荷試験の規模によりますが、今回は毎秒1万リクエストを目指すので余裕を持ってn1-standard-2を20台で構成しました。費用を抑えたいなら、プリエンプティブノードを有効にするといいかもしれません(参考)。後は特に気をつけることはありませんが、ブートディスクは小さくてもいいかもしれませんね。

Locustの設定ファイルを作成

まず、前述したテンプレートリポジトリをcloneします。

リポジトリ内のlocust-tasks/tasks.pyにテストシナリオを書きます。詳しくは公式のドキュメントを見てという感じですが、単純に特定のエンドポイントに対してリクエストを飛ばすだけならとても簡単です。

例えば、https://hogehoge/indexというURLに対してGETする場合、locust-tasks/tasks.pyを以下のように書き換えます。

sessionの利用も普通にできるので、ログイン処理等も可能です。以下は公式ドキュメントから引用したサンプルコードです。

Docker Imageの作成

前項で編集したtask.pyを含むDocker imageをbuildします。リポジトリのルートにDockerfileがあるので、buildしてGoogle Container Registryにアップロードします。 以下のコマンドを実行すると、buildとGoogle Container Registryへのアップロードが続けて実行されます(PROJECT-IDの部分は適宜置き換えて下さい)。

Master-Podのデプロイ

リポジトリのdeployment-master.yamlにDeploymentが定義してあるので、これを編集します。

まずcontainers.locust.imageに、先ほどbuildしたDocker imageを指定します。

また、containers.locust.envのTARGET_HOSTに、負荷を与えたいURLのHOSTを指定します。https://hogehoge/indexなら、以下のように編集します。

編集が終わったら、applyなりcreateなりでデプロイします。

Worker-Podsのデプロイ

masterと同じ要領でdeployment-worker.yamlを書き換えます。また、GKEのクラスタ数に応じて、レプリカ数を調節します。適切なレプリカ数に関してはまだ検証不足ですが、今回(vCPU 2 × 15台)はレプリカ数80に設定しました。

編集が終わったら、masterと同じようにデプロイします。

MasterのServiceをデプロイ

webブラウザからlocustのダッシュボードにアクセスするために、locust-masterのserviceをデプロイします。

type: LoadBalancerのServiceがデプロイされるので、数分経ったらkubectlコマンドあるいはGCPのダッシュボードから外部IPを確認します。

EXTERNAL-IPが、目的のIPアドレスになります。

ダッシュボードから負荷試験を開始

Port 8089でダッシュボードにアクセスします。以下画像のようなwindowが出るので、負荷を与えたい量を入力します。

上段のNumber of users to simulteには、作成するクライアント数を指定します。1秒間にテストを実行する分量と考えて差し支えないと思います。毎秒1万リクエストの負荷試験を行いたい場合は、ここに10000と入力します。

下段のHatch rateには、クライアント数の増加ペースを指定します。例えばここに10を指定すると、毎秒10のペースでクライアント数が増加します。Number of users to simulteに10000を指定した場合を考えると、開始してから段々とRPSが上昇していき、開始から1000秒後に10,000RPSに達する感じですね。

以下は、10,000RPSに到達した際のスクショです。

考察

今回、10,000RPSを目指した際には vCPU 2 × 15台 のクラスタでGKEを構築しました。今回は単純にいくつかのエンドポイントに対してGETリクエストするだけの負荷試験だったため、この台数で10,000RPSに達することができました。しかし、本格的なシナリオで負荷テストを行う場合は、今回以上にマシンリソースが必要になると思われます。

せっかくなので、負荷テストに使ったクラスタの料金を簡単に計算してみました。 n1-standard-2を15台使って、負荷試験を1時間行う場合を考えてみます。n1-standard-2の東京リージョンでの料金は 0.122$/h です。が、今回の用途ならプリエンプティブインスタンスで事足りそうなので、それだと 0.0265$/h になります。これを前提にすると、0.0265 × 15 × 1 × 110(円/ドル)として、 約44円 の計算です。実際にはこれに加えて通信量とかもかかってくるのでもう少し上がりますが、10,000RPSの負荷試験が1時間40円超でできるというのは悪くないのではないでしょうか。

まとめ

今回負荷試験を行うことで、以下のように様々な情報を得ることができました。

  • 本番稼働に必要と思われるサーバーの台数
  • 本番稼働時の推定費用
  • システムの負荷が増大した際のスケーリングの動き
  • システムのボトルネックとなっていたポイント

また、これまで動作検証では発見できていなかったバグや不具合を見つけることもできました(例:高負荷時にRedisのコネクションが溢れる等)。

今回に限らず、今後も重要な機能をリリースする際には負荷試験を行うことを検討してもいいかもと思いました。

pixivがコミックマーケット出展にかける想い

こんにちは。アライアンスチーム、プランナーのaikoです。

pixivは2008年から日本最大規模の同人誌即売会「コミックマーケット」に企業出展をしています。今回はピクシブとコミックマーケットの関係性や企業出展にかける想いをお伝えします!

コミックマーケットと同人誌

「コミックマーケット」は1975年から続く同人誌の展示即売会1です。

サブカルチャー好きであれば知らない人はいないという日本最大規模のイベントです。実はきちんと考えたことがなかった……という方のために、そもそも同人誌とは何なのかをご説明いたします。

【同人誌】主義・志などを同じくする人たちが、自分たちの作品の発表の場として共同で編集発行する雑誌

― 大辞林 第二版

同人誌は文学・芸術・学術の分野から、マンガを中心とするサブカルチャーの表現形態として、日本において飛躍的に発達しました。 現在は『同人』という集団(サークル)に限らず、個人が自分たちの作品の発表の場として編集発行する本も『同人誌』と呼ぶようになりました。

基本的な定義としては下記があげられます。

  • 商業流通には基本的に乗らない
  • 非営利目的、 限定的な配布形態

多くの同人誌は、自身の表現を発表するためにつくられているんです。

コミックマーケットでは回を重ねるごとに、多様な表現を受け入れ続けています。 いまではサークル参加以外にも、企業として出展ができますし、商品の展示・頒布は無く、コスプレをしてイベントを楽しんでいる参加者も多いです。

コミックマーケットとpixivの関連

pixivは昨年サービス開始10周年を迎えました。コミックマーケットの長い歴史に比べると比較的新しいサービスに感じます…が!
驚くことにコミックマーケット参加者の83%もの方がpixivを利用しているのです!
(数値の詳細については以前開催されたpixiv MEETUPセッションの内容をご覧ください)

2009年、pixivから同人ポータルサイト「Circle.ms」へ連携登録ができるようになりました。 この連携は、個人のpixivでのイラスト投稿活動とサークルの同人活動がより緊密に展開していくことを目的としています。pixivで交流のあるユーザーに自身の同人活動を宣伝告知することができ、またCircle.msで交流のあるユーザーがpixivで公開しているイラストを簡単に閲覧することができます。

こういった連携もあり、pixivとコミックマーケットは10年近くも前から強い関連性を持っています。

pixivがコミックマーケットに出展する意義

pixivはコミックマーケットごとにpixiv投稿作品を収録したイラスト集を製作し、販売しています。 できるだけたくさんの作品に触れて魅力を知っていただきたいという考えから、商品の値段はできる限り抑えるようにしています。

直近に開催されたコミックマーケット94では、オリジナル作品を収録した「年下彼女」「年上彼女」というイラスト集と、人気ゲーム「Fate/Grand Order」をテーマとしたファンアート作品を収録した「Fate/Grand Order×pixiv illust collection 2」を販売しました。

いずれの商品も準備数完売という大変嬉しい結果になりました!

pixivに投稿されている作品はどれも魅力的で、数も膨大です。自身の好みの作品やクリエイターに出会うのも簡単ではありません。 私たちはこうした企画を実施することで、pixivでこれまで出会ってこなかった作品に触れるきっかけの1つになってほしいと考えています。

本企画は私たちのこの考えを理解いただいたクリエイターの皆さまのご協力があってはじめて実現できています。

おこがましい考え方かもしれませんがイラストコンテスト受賞経歴やpixivの企画に関わったことがきっかけで仕事が増えたり、成功への足掛かりになると良いなと思っています。 pixivをきっかけに飛躍し、お仕事が忙しくなった結果「そういえばpixivのイラストコンテストに応募していた時代もあったな…」と振り返ってもらえたら個人的にはとても満足です。

今後のコミックマーケット出展について

コミックマーケットはリアルタイムで放送されているアニメやゲームなどのコンテンツが大変人気を博しており、それらのコンテンツとコラボレーションすることで、より多くの方々に企画を知ってもらうことができます。 そのため、人気コンテンツとのコラボ レーションは今後も力を入れていきたい部分になります。

また、pixivの知名度は高いものの、pixivの関連サービスについてはまだまだ知られていないのが現状です。コミックマーケットという場を活かして、pixivの様々なサービスに触れていただければと考えています。

最後に、私たちはpixiv=Web上のコミックマーケットのような場所だと考えています。 好きな作品・クリエイターに出会える場所・交流が生まれる場所として、pixivができることを実施し続けていきます。

今後もWeb・リアルイベントともに、皆さまが素敵な作品に出会える機会を創出していきますので楽しみにしていてくださいね!


  1. 同人誌の展示・頒布を主とするイベント