pixiv inside

Zendeskを活用した社内ヘルプセンター導入と業務効率化の軌跡

2025-03-18T12:46:21+09:00

こんにちは、経営企画推進部のtsuboです。

今回は、現在ピクシブで月間約600件の社員の問い合わせを処理する社内ヘルプセンター「P-ガイドポータル」を導入した背景、効果、導入後の変遷についてお話しします。

なお、今回導入したピクシブのヘルプセンターの主幹ツールには、プロダクトのヘルプツールとしてよく使われるZendeskを採用しています。

社内ヘルプセンター設立の背景

経費精算、勤怠管理、各種業務ルールの運用やオペレーションの効率化は、多くの企業やバックオフィスにとって重要な課題です。

ピクシブでは、これらの業務ルールや指針の案内について、従前バックオフィスの各部署がそれぞれ社内に周知してきました。その際、ルールに関する質問・問い合わせは、特定のSlackチャンネルやDMで自由に受け付け担当者が個別に対応するという運用が常態化していました。

しかし、ピクシブ株式会社はこの5年で急速な成長を遂げ、社員数が300名以上増えました。

結果、この5年間で加速的に社内の問い合わせや相談件数が増え、バックオフィスの個別対応コストが膨らんでいきました。200名規模の対応に最適化した当時の体制は、質問に対して担当者が都度回答やケアを行なっており、ナレッジの蓄積・共有や業務効率向上のための施策が行いづらい環境となっていました。

この状況を改善するため2022年10月に経営企画推進部が中心となり、「社内業務ルールの一元化」と「社内問い合わせ機能の集約」を目指した社内ヘルプセンターの導入を決定しました。

なお、立ち上げ当時はスピードを優先し、別のドキュメントツールにあった業務ルール関係の資料を全て洗い出し、特に精査せずZendeskに一括で移植するという強硬な移行手段を取りました。

これによる功罪は後述しますが、社内では変化が大きく社員が戸惑う声も一定聞かれました。

社内ヘルプセンター設立の目的

上記の経緯を少しまとめると、社内ヘルプセンター導入には以下の3つの主目的がありました。

社内業務ルールの一元化
- 業務ルールや事務手続きに関する情報を一つのプラットフォームに集約し、社員が必要な情報に容易にかつ速やかにアクセスできるようにしたい
社内問い合わせ対応の効率化
- バックオフィスに連絡される多種多様な問い合わせを一元管理することで、応答窓口を統一し、一人に業務量やナレッジを過密させることなく対応コストを削減・標準化したい
- 結果、バックオフィスの業務が効率化され、問い合わせ以外の業務にも集中できるようにしたい
データの利活用による社内業務ルールの改善/更新
- 問い合わせ内容や業務ルールの検索・閲覧履歴から社員の困り事や関心傾向を把握し、業務ルールの案内文やコンテンツの改善に活用したい

この目的意識は現在も変わっておらず、今もこれらの実現のために地道な改善業務を行っています。

なお、社内ヘルプセンターは当初「ピクシブヘルプセンター」と名付けましたが、後に「P-ガイドポータル」へと改称しました。これはプロダクト側の「pixivヘルプセンター」と呼称が被っており、特に口頭での説明時の誤解を防ぐためでしたが、自分たちが目指すツールについて、改めて役割や期待を整理・定義する良い機会となりました。

導入後の課題と地道な改善の軌跡

導入後の課題

前述した通り、「P-ガイドポータル」は導入直後、それまで利用していた社内ドキュメントを無理やり大量に移植した状態からスタートしました。また、問い合わせに関してはこれまで仲の良いバックオフィスの社員に気軽にSlackで質問できていたことがZendeskのリクエスト機能を利用して問い合わせる形式となりました。

これにより当初社員には「集約したい意図は理解するが、掲載されている記事も膨大でわかりづらく、リクエストも億劫で使いづらい」という意見が多くありました。

またバックオフィスの社員からも「とにかく日々リクエストが多く応答で手一杯になってしまい、記事の改善まで手が回らない」という課題も聞かれました。会社組織が急成長を遂げる過渡期だったこともあり、相互に新しいツール・運用に慣れていくことに四苦八苦する日々が続きました。

社員とバックオフィス相互が、より便利に使ってもらうために

突然ですが、私は過去プロダクトを持つ事業部にて、CSとして問い合わせ対応やプロダクトヘルプのナレッジマネジメントを行った経験がある状態で経営企画推進部に異動した経緯があります。そこで上記の課題を持ったこのツールをより便利なサービスにできるよう、CS経験を活かしていくつかの改善活動を実施しました。

今回はその中で、特に効果があったと感じた4つを紹介します。

社員アンケートの実施と要望投書窓口の常設

導入後、全社員を対象としたアンケートを実施しました。

極めて一般的な手法ですが、上記のような社内課題が明確に認知できるようになり、改善に向けた大筋を立てることができました。このアンケートでは認知度、利用状況、改善要望を収集し、この結果に基づき、UIの改善やコンテンツの見直しなど、さまざまな改修を行い、より使いやすいヘルプセンターへと進化させていきました。UI/UXの改善については現在も進行しており、追って続編の記事を出せたらと思っています。

また、アンケートという非日常な立て付けだけでなく、日々使っていて不便な事象や修正してほしい記事を発見した場合、気軽に要望を話せるSlackbotを運用しました。これにより「〇〇という情報が見つけられなかった」「〇〇という記事の内容が古い」など社員の自発的な改善要望をリアルタイムでキャッチできるようになり、改善が大きく捗りました。
業務ルール記事の閲覧傾向分析とコンテンツ整備

運用整備における最も大きな課題は、大量に移植したことにより情報が枝分かれ散逸したドキュメント群の統合と再構築でした。惨状を前に私は、移行が完了していることはポジティブに捉え、社員の閲覧傾向の分析を実施しました。

Zendeskはユーザー動向の数値把握が行いやすく、記事の閲覧数や離脱率などを細やかに算出することができます。この機能を活用し、社員が恒常的に関心を持つ業務ルールは何か、社員が検索したが記事にたどり着けなかったワードは何かなどを定常的に取得し改善に繋げました。人気の高い記事の内容は担当者と話してわかりやすく再構成したり、トップページにPICKUPとして掲載するなど、社員のニーズの高いものから改善を着手することに注力しました。
バックオフィス連携体制の構築と改善定例の実施

当時、日々増加する社員の対応にバックオフィス側は多種多様な苦労を重ねていました。

その結果、業務ルールについては前述の通り、社員からの問い合わせを応答することに手一杯で、なかなかコンテンツの整備や改善までは着手できる体制やリソースがなかったことが導入当初、大きな課題でした。

そこで、記事の体裁管理やZendeskへの反映作業は経営企画推進部にて巻き取り、各部署は制度内容や応答に集中してもらう連携体制を構築しました。不慣れなZendeskのコンテンツ入稿に全員が慣れることは一定後回しにすることを許容し、コンテンツ内容を更新したい場合、それぞれが慣れたツールで書いた資料を共有するだけで反映される状態を作りました。

これにより各部署は応答対応に力を入れることができるようになり、リクエストの処理時間が飛躍的に向上しました。また、この成果や状況を全員で認識するため、問い合わせ件数を週ごと・月ごとに集計し、共有や改善を相談する定例を実施しました。定例の場では例えば「今月はこの部署宛にこういう問い合わせが多かった、なのでこの情報は記事化して問い合わせを減らしていかないか」という提案を行い相互に改善を助け合う環境を作りました。

この定例はリリースから2年経った現在も続いており、小さな改善を日々重ねています。
社員側の立場に立った利便性の向上

前述の通り、私はもともとプロダクトを持つ事業部にいたため、社内ヘルプセンター設立時はバックオフィスへリクエストを送る側の社員でした。Zendeskでは自分が送ったリクエストに返信があるとメールで通知してくれるのですが、ピクシブでは日常的にSlackを使っており職種によってはメールチェックをする習慣がないため、メールを確認しに行かずともSlack上で気づけないものかと思った記憶があります。

その後社内ヘルプセンターの担当になり、他の社員からも同様の声が届いているのを知った私は、返信をSlackで気づくことができれば社員にとってストレスなく利用できるようになるのではないかと考え、すぐに着手しました。Zendeskのwebhookとトリガを元にZapierを経由して、返信の通知メールが届くと同時にSlackで通知する仕組みを作りました。

これにより社員はリクエストの返信にすぐに気づけるようになり、自分が送ったリクエストの結果を都度気にしなくても良い環境を作ることができました。社員からも「状況を都度チェックしに行かなくて済むので助かっている」という声を聞いています。

自ら課題解決できるヘルプを目指して

上記の改善活動によって、「P-ガイドポータル」の利便性は大きく向上しました。

導入・改善により、当初目的としていた業務ルールの一元化や問い合わせの可視化、バックオフィスの負担軽減が現在目に見える形で成果として認識できるようになっています。

「P-ガイドポータル」の閲覧数・問い合わせ数推移

この図では前提となる社員数の増加がありつつも、着実に利用者数が増え、記事数、記事閲覧数、問い合わせ件数が徐々に増加していることがわかります。

導入当初は上手く社内浸透しておらず、リクエストもしばらくはDMや対面で質問・相談されることが多々ありましたが、その後地道に改善を続ける中で時間をかけて浸透していき、現在はDMや対面で質問されることは殆どなくなっています。

2024年10月現在、記事数は368本、記事閲覧数は月9,396回、問い合わせ件数は月631件に達しました。業務委託を含めた社員数は500名を超え、社内ヘルプセンターは業務や事務処理の迅速な遂行に不可欠なツールへと成長しています。

「P-ガイドポータル」のミッションは、「社員が業務ルールをスムーズに把握し、自ら課題解決できるヘルプを作る」ことです。目標達成に向け、今後も継続的にコンテンツや体制を工夫し、社員の自己解決を促進する、利便性の高いヘルプセンターを目指していきます。

RubyKaigi 2025に「Road to Go gem」で登壇するので採択されたProposalを公開します

2025-03-05T17:02:50+09:00

こんにちは、インフラ部のsue445です。

2025年4月16日(水)〜18日(金)に愛媛県松山市で開催されるRubyKaigi 2025に登壇します！

rubykaigi.org

自分のトークについて
実際に採択されたProposal
- Title
- Agenda
- Details
- Pitch
- 補足
【おまけ】過去のRubyKaigiで採択されたProposalの一覧

自分のトークについて

3日目の4月18日(金)に登壇予定です。

rubykaigi.org

「Road to Go gem」というタイトルで、Rubyのnative extensionをGo言語で書きやすくした話をします。

RubyKaigiはコード自慢大会*1なのでここ最近趣味で作ってた https://github.com/ruby-go-gem/go-gem-wrapper やその周辺の話をします。

github.com

タイトルにGoが入っていますが実際にはC言語の話の方が多いかもしれません。

余談ですが僕の名前はGoです。

実際に採択されたProposal

実際に採択されたProposalはこちらになります。今後Proposalを出す時の参考にしてください。

このProposalの内容をベースに発表資料も作るので当日の僕のトークの予習資料としてもご利用ください。

Title

Road to Go gem

Agenda

Go talks about Ruby native extension gem with Go. (a.k.a. Go gem)

I created https://github.com/ruby-go-gem/go-gem-wrapper for Go gem.

This is a library to make it easier to create Go gem. (contains both Go module and Ruby gem)

I will talk the following regarding go-gem-wrapper and Go gem.

Auto-generate (almost) all of Go's bindings from ruby.h. (about 1,100 functions)
Parse CRuby's ruby.h with Ruby
C lang's pointer difficulties from ruby.h parser's point of view
Run go test with CRuby
Pros/Cons of Go gem
My bundler's patch for Go gem

Details

Goでnative extensionを作りやすくした話をします。

長いのでGoで作られたnative extensionのことを僕はGo gemと言っています。このプロポーザルでもそのように呼称します。

このトークは2024年9月に開催されたTokyuRuby会議15の発表の続きになります。 https://esa-pages.io/p/sharing/8985/posts/887/74fdd1ed44cec5284a40-slides.html#/18

Tokyuの時はWIPでしたが今回は完成してるので完成物（Go gemを作りやすくするためのライブラリとその周辺のエコシステム）の話をします。

これによりこれまでよりも少ないコード量でGo gemを作ることができます。

僕がbundlerに送ったパッチ（後述）がマージされると bundle gem --ext go でGo gemのスケルトンが作れるようになるんですが、プロポーザル執筆時点ではまだマージされていないです。

コードだと下記の話が中心になります

https://github.com/ruby-go-gem/go-gem-wrapper
- https://rubykaigi.org/2015/presentations/mmasaki/ の時には動いていたコードが、Goの内部仕様の変更により今はもう動かなくなっていた件の修正
  - c.f. https://github.com/ruby-go-gem/go-gem-wrapper/blob/v0.6.0/ruby/wrapper.go#L36-L41
- ruby.hをパースしてGoのbindingを自動生成し、Go module（Goのライブラリ）として利用できるようにしたライブラリ
- ruby.hに定義されている約1,100個の関数を実際に https://github.com/ruby-go-gem/go-gem-wrapper/blob/v0.6.0/ruby/function_ruby_3_4_generated.go のような形で自動生成している
- 他にもCRubyのenumやstructなどもGoで使えるようにbindingを自動生成している
https://github.com/ruby-go-gem/go-gem-wrapper/tree/v0.6.0/_gem ( https://rubygems.org/gems/go_gem )
- extconf.rbにパッチを当ててGo gemをビルドするためのMakefileを作るためのgem
- Rust gemにおける https://rubygems.org/gems/rb_sys みたいなやつ
- go test を実行するためにはCRubyの RbConfig::CONFIG をいい感じにGoに渡す必要があったのだが、結構コツがいるので https://github.com/ruby-go-gem/go-gem-wrapper/blob/v0.6.0/_gem/lib/go_gem/rake_task.rb のようなラッパも作った
https://github.com/ruby-go-gem/ruby_header_parser
- go-gem-wrapperから切り出したruby.h専用のパーサー
- ctagsを使ってるので実はruby.h以外もいけるとは思うけど未検証
bundlerの改良
- https://github.com/orgs/rubygems/discussions/8128
  - bundlerでGo gem対応するためのproposal
- https://github.com/rubygems/rubygems/pull/8183
  - 前述のproposalでhsbtさんからLGTMもらった後に実際にbundlerに送ったパッチ
https://github.com/sue445/funnel_http
- 実際に作ったGo gem
- 複数のHTTPリクエストをgoroutineの中から並列実行することで、ThreadやRactorなどのpure-Rubyな実装を寄せ付けないパフォーマンスを得ることができた

コード以外の部分のネタはこの辺があります。（探せばもっとあるかも）

ruby.h をparseするために頑張ったこと
- 既存のツールを検証した結果
- その結果なぜ自分でパーサーを書くことになったかの理由
- C言語のポインタを他言語で解釈する時の苦労話
  - 具体的には下記に苦労点が詰まっています...
  - https://github.com/ruby-go-gem/ruby_header_parser/blob/v0.4.1/CONFIG.md
  - https://github.com/ruby-go-gem/ruby_header_parser/blob/v0.4.1/config/default.yml.erb
Go gemのメリット
- goroutineはRactorの約28倍速いｗ
  - https://github.com/ruby-go-gem/go-gem-wrapper/tree/v0.6.0/_benchmark
- 現状Rubyで並行・並列処理を書く場合にはThreadやFiberやRactorを使うことになると思いますが、Go gemによりgoroutineという新しい選択肢ができました
- osyoyuさんも以前言ってたけどRubyを速くするためにRuby以外を書くことになった
現在の課題（Go gemの制限）
- Goの可変長引数をそのままCの可変長引数に渡せない件
  - https://github.com/ruby-go-gem/go-gem-wrapper/blob/v0.6.0/ruby/ruby_internal_error.go のようなハックが必要
- goroutineの中からCRubyの関数を呼ぶとSEGVになる件
bundlerにFeature proposalやPRを投げた時の苦労点など
- 最初rubygemsのdiscussionに投稿した時にあまり反応がなかったのでruby-jp slackでhsbtさんに相談した
- bundlerはUbuntu/macOS/WindowsでそれぞれCIを実行しているのだが、特定のテストを実行しようとするとなぜかWindows Runnerだけでハングする事象が見つかって調査して直した件
  - bundlerのWindowsのCIは通常時でも1.5時間くらいかかるので調査がむっちゃ大変だった

Pitch

Go gemに関する話は2015年のRubyKaigi( https://rubykaigi.org/2015/presentations/mmasaki/ )で話されたきりで、僕が知ってる範囲ではその後特に進展はなかったと思います。

2015年の発表当時だと bundle gem した直後のスケルトンに色々手を加える必要があったので万人が手を出せるものではありませんでした。

そのため、ruby.hからGoのbindingを自動生成する仕組みを整えてbundlerに組み込めるレベルまで持っていくという一連のエコシステムを全て僕1人で作りました。

僕が取り組むまではbundlerにこの手のissueやproposalはなかったので、Go gemに取り組んでいるのは現在世界中でおそらく僕しかおらず、間違いなく僕にしかこの話はできないです。

ここ数年のRubyKaigiではRubyで書かれたコードのparserのトークが盛り上がっていますが、僕はもうちょっと低レイヤー寄りでCRubyのソースコードのparser枠として話をすることになると思いますｗ

bundle gem に新しい言語を追加しようとしてる人はほとんどいないので、今後 bundle gem に他の言語を追加したい人の手助けになると思っています。

補足

TitleとAbstractはサイトに公開されるものなので全て英語で記載してますが、Details（発表のテーマや流れ）とPitch（このCFPを採択すべき理由やアピール文）に関してはレビュアーしか見ないものなので日本語で記載しています。

【おまけ】過去のRubyKaigiで採択されたProposalの一覧

inside.pixiv.blog

sue445.fanbox.cc

*1:諸説あります

Android Viewのパスワード入力部分をComposeでも実現したい

2025-03-03T12:00:00+09:00

はじめに

こんにちは、Palcyでアルバイトをしているorukunnnです！

僕はpixivのAndroid育成プロジェクトというモバイルエンジニア不足を解消するために始まったプロジェクトに参加させていただき、1からAndroidの学習を進めてきました。この記事ではそのOJTのフェーズで技術的に挑戦したことについて話していきます。

背景

実際にOJTで渡されたタスクとしてはアプリの引き継ぎ部分をAndroid ViewシステムからComposeに移行するというものです。

Palcyアプリは2018年からあるアプリなので、OJTの中ではユーザーの体験を損なわないよう、使用感を出来るだけ変えずに実装していくことを心がけていました。そこでEditTextに出会いました。EditTextというのはAndroid Viewシステムが提供するViewコンポーネントで、ComposeでいうTextFieldの役割を果たし、InputTypeをtextPasswordに指定することで入力された文字をいい感じにマスクしてくれます。はっきり言ってめちゃくちゃ簡単です。

<!-- レイアウト側で制限するとき -->
<EditText
        android:layout_width="wrap_content"
        android:layout_height="wrap_content"
        android:inputType="textPassword"
        android:ems="10"/>

//実行ファイルで制限するとき
editText.inputType = InputType.TYPE_TEXT_VARIATION_PASSWORD

課題

Android ViewシステムのEditTextでは最新の1文字を除いてマスクを行い、最新の1文字もおよそ1秒後にマスクをするという処理をシステム側でやってくれていましたが、Composeではその機能がそのまま提供はされていませんでした。使用感を変えないようにするという目標を達するため、自身でEditTextのinputType=textPasswordと同じ機能をComposeで作る必要がありました。

選択肢

選択肢として以下のような2点が上がりました。

AndroidViewを使ってEditTextをCompose上に表示する
ComposeでEditText(inputType=textPassword)と同じ機能を実現する

今回はComposeへの完全移行を目的としているため1番初めの選択肢はすぐに除外され、2番目の選択で取り組むことにしました。

どう取り組んだか

EditTextをComposableで実現するためには次の2つの仕様について実装する必要があります。

テキストのマスク
最後の1文字だけ1秒後にマスク

これらを実装するため、まずは次の資料を参考にComposableを作成しました。

https://qiita.com/twumo/items/155a7f1cc53aa55dc739

こちらの記事では最後の1文字だけマスクしない専用のVisualTransformationを作成し、それを1秒後に全てをマスクするPasswordVisualTransformationに切り替えています。これで2つの仕様について実装ができました。

var inputText by remember { mutableStateOf("") }
var visualTransformation: VisualTransformation by remember {
    mutableStateOf(PasswordVisualTransformationInstance)
}

LaunchedEffect(Unit) {
    var job: Job? = null
    snapshotFlow { inputText }.onEach {
    job?.cancel()
    job = launch {
            visualTransformation = PasswordVisualTransformationExcludesLastInstance
            delay(1.seconds)
            visualTransformation = PasswordVisualTransformationInstance
        }
    }.collect()
}

qiita.com しかし、ここでもう2つの問題に直面しました。

2つの問題

再利用性の欠如

LaunchedEffectがないとPasswordTextField()は利用できていませんでした。
処理の遠さ、可読性の悪さ

はじめはsnapshotFlowを使うためにViewModelをDIしているComposable、つまりTakeoverPasswordInputScreenでLaunchedEffectを使用しましたが実際に使用するところから処理が遠く最適化できていませんでした。

// 階層構造(Composableの親子関係)
TakeoverPasswordInputScreen(viewModel)
├── LaunchedEffect
└── TakeoverPasswordInputScreen
        ├── TakeoverPasswordInputContent
        │   ├── Text
        │   ├── PasswordInputField
        │   │   ├── PasswordTextField
        │   │   │   └── BasicTextField(実際に使用する所)
        │   │   └── Text
...

var visualTransformation: VisualTransformation
        by remember { mutableStateOf(PasswordVisualTransformation()) }
        
LaunchedEffect(Unit) {
        var job: Job? = null
    napshotFlow { viewModel.password }.onEach(initial = "") { old, new ->
        if (old.length < new.length) {
            job?.cancel()
            job = launch {
                visualTransformation = PasswordVisualTransformationExcludesLast()
                delay(1.seconds)
                visualTransformation = PasswordVisualTransformation()
            }
        } else {
           　visualTransformation = PasswordVisualTransformation()
        }
    }.collect()
}

初めはこのLaunchedEffectをBasicTextFieldと同じ階層にほとんどそのまま移動させましたが、PalcyのプロジェクトはMVVMというアーキテクチャで書かれていてViewModelクラス側で入力文字列を保持しているため、Composable側で文字列の状態を保持している記事の状況とは異なりsnapshotFlowが使えません。従ってLaunchedEffectの中の処理がうまく実行されませんでした。

解決策

再利用性を考えると第1に解決しなくてはいけないことはLaunchedEffectをBasicTextField()と同じ階層に持っていくことでした。同時に可読性の面も解決できることに気づき、この方針でLaunchedEffectを書き換えることになりました。

大事なのは「文字列が変更されたときに一つ前の文字列の状態と比較して新しく文字が追加されたら1秒遅れてVisualTransformationを変更する」ということなので以下のようにも実装できます。

oldInputTextという状態を用意し一つ前の文字列を保持しておくように変更
- 文字の過去の状態をもつためのsnapshotFlowが不要に
LauncheEffectのkeyをinputText(入力される文字列)に変更
- ViewModelのinputTextを渡している階層ならどこにでも配置可能に
- 文字の入力が行われる度にLauchedEffectが走るのでJobが不要に

// 階層構造(Composableの親子関係)
TakeoverPasswordInputScreen(viewModel)
└── TakeoverPasswordInputScreen
        ├── TakeoverPasswordInputContent
        │   ├── Text
        │   ├── PasswordInputField
        │   │   ├── PasswordTextField
        │   │   │ 　├── LaunchedEffect
        │   │   │ 　└── BasicTextField
        │   │   └── Text
...

var oldInputText by remember { mutableStateOf("") }
var visualTransformation: VisualTransformation
        by remember { mutableStateOf(PasswordVisualTransformation()) }
        
LaunchedEffect(inputText) {
    val isAppended = inputText.length > oldInputText.length
    oldInputText = inputText
    if (isAppended) {
        visualTransformation = PasswordVisualTransformationExcludesLast()
        delay(1.seconds)
        visualTransformation = PasswordVisualTransformation()
    } else {
        visualTransformation = PasswordVisualTransformation()
    }
}

コード自体もシンプルになり、階層の位置もPasswordTextFieldの中にまとめることができたため実行性や可読性の向上が見込めます。またこのPasswordTextFieldをComposeのモジュールに移動することで実際に再利用を可能にし、同じ引き継ぎ画面の引き継ぎ時にパスワードを入力する際に再利用することができました。

最終的な動作

最後に

動きのあるComposableを作成する中で

LaunchedEffectはかなりの頻度でkeyの部分をUnitにしがちだったのですが、今回のようにより具体的なものをkeyに渡すことでそこの処理が何をしているのかが明確化されることと、実際に使用するコンポーネントの近くに配置することができる場合があること。
再利用可能なComposableを作ること。

上記2点を心がけることで結果として可読性の高いコードを書くことができるのではないかという考えを持つことができた。

また、今まであまり階層構造を図に書き記す機会はなかったのですが、保守の観点から最後に必ず書いて関連性のある処理が遠すぎないかを確認するようになりました。

BOOTH 3Dモデルカテゴリ取引白書2025

2025-02-19T11:45:00+09:00

ピクシブが運営する創作物の総合マーケットプレイス「BOOTH」では、近年VRChatなどで利用される「3Dモデル」の取引が大きな盛り上がりを見せています。
2024年に公開したBOOTH 3Dモデルカテゴリ取引白書2024から一年を経て、さらに活性化するBOOTH 3Dモデルカテゴリについて、取引データや成長の背景をご紹介いたします。

（参考）BOOTH 3Dモデルカテゴリ取引白書2024

3Dモデルカテゴリの取引データ
2024年の3Dモデルカテゴリ関連取り組み
- BOOTH
- BOOTH以外
3Dモデルカテゴリのさらなる成長を目指して
ピクシブで働きませんか

3Dモデルカテゴリの取引データ

取扱高は前年比約187%

2024年のBOOTH 3Dモデルカテゴリ取扱高は前年までのペースと比較しても大きく伸びました。
2023年の取扱高は約31億円でしたが、2024年の取扱高は58億円超となり、前年比約187%の驚異的な成長ぶりです。

取扱高成長のウラ側

2024年の急激な成長の背景として、以下が推測されます。

VRChatを取り上げた人気配信者の動画が話題になったこと
VRChat内での出会いを広げるワールドが人気を博したこと
アバターの衣装などの着せ替えを簡易化するツールや環境が普及したこと

大きな要因がひとつだけあったわけではなく、さまざまな出来事が影響しあったことで想像以上の化学反応が起こったと言えそうです。
中でも、人気配信者の動画をきっかけにVRChatを始めたユーザーは多かったと思われます。

注文件数は前年の約2倍

注文件数も2024年は大きく増加し、前年の2倍以上となる402万件でした。

注文者数は前年の約1.5倍

2024年の注文者数は21万人を超え、前年と比較して約1.5倍になりました。
また注文者一人あたりの平均注文件数も、2024年は前年の135%となっており、注文者が増えているだけでなく一人ひとりの熱量も高まっていることが伺えます。

注文者件数・注文者数成長のウラ側

以下は、BOOTH 3Dモデルカテゴリにおける2023年から2024年の月ごとの注文件数を表したグラフです。注文件数が2024年夏以降に急激に伸びています。成長の要因の1つとして「VRChatを取り上げた人気配信者の動画が話題になったこと」を前述しましたが、その動画が公開されたのが2024年の夏でした。その時期を境に大きく注文件数が伸びていることが見て取れます。

ただ、盛り上がりは瞬間的なものにとどまりませんでした。

以下は、BOOTH 3Dモデルカテゴリで初めて注文を行った初回注文者数を2023年から2024年の各月で表したグラフです。月ごとの流入数と言ってもいいでしょう。 2024年夏から初回注文者が大きく増えています。VRChatに関する動画を見て「自分もVRChatで遊んでみたい」と思った方がBOOTHで初めて3Dモデルを注文したと考えられます。

その後も初回注文者は減りつつも高い水準を保っています。一時的なブームにとどまらず、ある程度継続的に新規ユーザーが流入していると言えるでしょう。

ライト層もヘビー層も盛り上がる

2023年と比べると、2024年はどの支出額帯でもユーザー数が大きく伸びています。ライトに楽しむ層に限らず、ヘビーユーザー層も含め幅広い層で盛り上がっていると言えます。ヘビーユーザー層の増加については、「アバターの着せ替えをしたい」「新しいアバターも欲しい」「新しいアバターに合う衣装も欲しい」「フレンドの持っていた装飾品も気になる」といったサイクルが回っている結果だと思われます。

注文が伸びた3Dキャラクター（アバター）価格帯は5,000円〜6,999円

3Dモデルカテゴリのサブカテゴリである「3Dキャラクター」内の商品の価格帯と注文件数を表したのが以下のグラフです。 2024年はどの価格帯でも2023年に比べて注文件数が伸びましたが、中でも目立つのが5,000円〜6,999円の価格帯の伸びです。

だんだんと人気の商品の価格帯が固まりつつあると言えそうです。

着せ替えニーズと3D衣装・3D装飾品カテゴリの盛り上がり

3D衣装・3D装飾品カテゴリも着せ替え需要を受けて大きく伸びています。

着せ替え需要の一端には、周囲のユーザーの衣装や装飾品を見て「流行に乗りたい」「自分もいろんな服を着て見てもらいたい」とユーザー同士が影響しあう流れがあるようです。

衣装のトレンドとしては、日常で着ているようなデザインのリアルクローズ風商品の人気が目立ちました。

着せ替え需要の高まりを受けて、着せ替えを簡易化するツールも増えています。

ピクシブでも3Dキャラクター制作ソフト「VRoid Studio」において、VRChat想定アバターなどのフルスクラッチアバターに対応していない衣装も簡単に着せ替えられる機能を2024年11月にリリースしました。作成したモデルを外部プラットフォーム利用可能なVRM形式で書き出すこともできます。

ギフト文化の定着と成長

次に、3Dモデルのギフト需要についてご紹介します。(これまでに紹介したすべてのデータはギフト機能を利用した取引を含んだものです)

BOOTHでは、ダウンロード商品をギフトとして購入しメールや各種SNSのメッセージ機能などを通じて贈ることができる「ギフト機能」を2022年12月にリリースしています。

以下は2023年から2024年にかけての、3Dモデルカテゴリにおけるギフト機能を利用した注文件数とその割合を表したグラフです。ギフト注文件数は着実に増加しており、ギフト需要が高まる12月のギフト注文割合は10%を超えています。

2024年12月25日に至ってはギフト注文の割合が30%を超えていました。

元々VRSNSはコミュニケーションを主な楽しみとされる方が多いですが、そこに現実のようにギフトを贈りあうという文化がうまく定着したのだと思われます。

2024年の3Dモデルカテゴリ関連取り組み

2024年にピクシブが行った活動のうち、3Dモデルカテゴリの活性化に関連するものをご紹介します。

BOOTHでは3Dモデルカテゴリの多様化と成長に伴い、カテゴリ構成の細分化を行いました。また、BOOTH全体でさまざまな機能開発やキャンペーン実施に取り組んでいます。

BOOTH以外でも、VRChat内に自分好みにカスタマイズできるプライベートな空間「BOOTH Room」を公開するなど、さまざまな3Dモデルカテゴリの盛り上がりに寄与する取り組みを行いました。

BOOTH

3Dモデルカテゴリの構成細分化

商品ページに「商品公開日時」が表示されるように

3D空間におけるBOOTHのロゴガイドラインを追加

購入履歴を検索できるように

売上情報を年別に表示するページを追加

定期的なキャンペーン

月刊BOOTH 3Dカテゴリの開始

BOOTH以外

プリペイド式電子マネー「pixivcoban」の提供を開始

X-NEOKET開催

BOOTH Room公開

VRoid Hub上でアニメーションを再生できる「撮影ブース」機能がリリース！さらにBOOTHに「VRMアニメーション（.vrma）」が出品可能に

VRoid Studioでの着せ替え機能のオープンβ、正式リリース開始

キモノデザイナー『JOTARO SAITO』× XWear VRChat向け3Dアバター着物「縞牡丹 -Shimabotan-」公開

アバターダンス動画が簡単に作れるスマホアプリ「VEAT（ビート）」リリース

3Dモデルカテゴリのさらなる成長を目指して

ピクシブは、今後もBOOTH 3Dモデルカテゴリをさらに成長させ、3Dクリエイターとファンの皆さまに貢献できるよう、さらなるサービスの拡充を目指していきます。

その一環として、BOOTHでは今後以下のような機能追加を予定しています。
※あくまで検討段階であり、変更や中止となる場合があります

ライブラリの構造見直し
- 無料ダウンロード商品の入手履歴を残すようにする
- ライブラリ内のアイテムの検索をできるようにする
- 検索条件としてカテゴリでの絞り込みなどを追加
メッセージ機能の拡充
- 画像送信を可能にする
- メッセージ送信画面にショップからの案内文言を掲示できるようにする
- 重要なメッセージを見つけやすくする

VRoid Studioでは着せ替え機能の拡充を予定していますので、楽しみにお待ちください。

3Dモデルカテゴリの成長はもちろん、さまざまなジャンルの創作活動を支援し、より多くの人に楽しんで頂けるよう努めていきます。

ピクシブで働きませんか

ピクシブでは採用を行なっています。
採用ページ

※数値が過去発表したものと異なる箇所は、カテゴリ構成の細分化やショップオーナーによる商品編集の影響によるものです

中高生国際Rubyプログラミングコンテスト2024 in Mitaka 最終審査会に参加しました

2025-02-17T16:00:00+09:00

こんにちは、コミック事業部のconopです。

11月30日（土）に中高生国際Rubyプログラミングコンテスト2024 in Mitakaの最終審査会が、三鷹産業プラザで開催されました。ピクシブは本コンテストに Gold スポンサーとして協賛しており、取締役CTOのharukasanがスポンサー審査員、エンジニア職のconop、alitasoが現地参加しました。

今年のピクシブ賞

去年・一昨年に続き、今年もスポンサー賞を提供いたしました。

ピクシブ賞として選出したのは椎葉友渚さんの作品「マイプロフ帳」です。

受賞理由

以下、審査員を担当した取締役CTO harukasanからのコメントです。

プロフ帳は私が中学生高校生だった頃にはすでにあり、交換するのが楽しかったです。プロフ帳は単なるプロフィールではなく、いろんな個人的なメモなどから友達の知らなかったことなどが知れます。それを今のインターネットが普及した時代にどうやってやるかといったことを考えたときに、マルチキャストではなくユニキャスト、個人のつながりというところを大事にしてそのために必要な機能を設計して作られていたのが素晴らしいと思いました。実際のソースコードを見てJavaScriptなどで頑張って実装していた様子を伺えました。まだまだこれから改善できるところや機能が増やせるところなどもあると思うので開発を続けてください。

また、副賞として「Wacom社製ペンタブレット」をお贈りしました。

その他スポンサー活動

今年もスポンサー賞の贈呈と併せて、全応募者の皆様に向けて大会ノベルティの製作を行いました。

昨年はタオルマフラーでしたが、今年はレザーマルチケースです。小物を持ち運ぶ際にどうぞご利用ください。

最後に

ピクシブはこれからも Ruby の普及活動を応援します。またコミュニティを盛り上げながら Ruby でプロダクトを作る仲間も募集しています。

ピクシブでの就業に興味をお持ちの方は、下記ページよりエントリーをお待ちしております。

www.pixiv.co.jp www.pixiv.co.jp

ピクシブが運営するサービスの基盤を支えるインフラ部ソリューションアーキテクトチームの仕事とは？

2025-02-12T17:00:00+09:00

こんにちは、広報部のmikoです。

ピクシブには、技術開発本部インフラ部ソリューションアーキテクトチーム（以下、SAチーム）というチームがあります。インフラ部は会社全体のサービスなどのインフラストラクチャ―の管理が主な仕事で、その中でもSAチームは新規サービスのアーキテクチャを考えたり、相談に対応するのがメインです。

今回は、インフラ部 SAチームのエンジニア3名に、仕事の内容やチームの雰囲気についてお話を伺いました。

自己紹介と、直近で関わった仕事について教えてください

yoshimin：2013年中途入社で、前職はソーシャルゲームの開発を行っていました。最近はモダナイゼーションに関わることが多いです。直近だとお絵かきコミュニケーションアプリ「pixiv Sketch」のオンプレミスのKubernetes (k8s) クラスタへの移行を行いました。

sue445：2018年中途入社で、前職はソーシャルゲームの会社でエンジニアをしていました。直近だとインターコネクト関係の開発に携わりました。2023年末に自社のデータセンターとAWSとをDirect Connect Gatewayで、データセンターとGoogle CloudとをCloud Interconnectで、それぞれインターコネクト（閉域網接続）を開通しました。

昨年9月に開催された完全招待制カンファレンス PIXIV DEV MEETUP 2024で詳しくお話しています。

inside.pixiv.blog

lyluck：2022年に中途で入社しました。前職はマーケティングオートメーションの開発をしていました。現在は主にバックエンドのエンジニアをしています。直近で関わったのは、社内のGitLabのOSアップデートです。古いままだとGitLabのバージョンアップができないという課題があり、その解消のため実施しました。

仕事のやりがいや楽しいところは？

lyluck：非常にさまざまな経験ができるところだと思います。やったことがある仕事を再度行うより、初めての仕事に取り組むことの方が多いです。大変ではありますが、経験を積んで自身が成長できているのが目に見えて分かるので、楽しさを感じられます。

sue445：lyluckさんと近いのですが、初めてのことが多く飽きないところですね。また、ピクシブにはまだ自動化されず手作業が残っている部分があり、現在それらの自動化にも取り組んでいるのですが、目に見えて改善していける点にもやりがいを感じています。

yoshimin：インフラ部、SAチームの特に面白いところは、上から下までトータルで触れることだと思います。

インフラストラクチャーを管理しているので、何か問題が起こったときに総合的な視点で対応することが可能です。問題の内容によって取れる方法が毎回変わってくることもあり、解決手段として総合的に色々な手段を検討できる点も面白いところかなと思います。

チームの働き方や雰囲気について教えてください

yoshimin：基本的にリモートワークのメンバーが多いですが、定期的に集まる機会を作ったり、何か相談したいことがあるときにすぐ話せる環境を作るように心がけています。例えば、オンラインで朝会を開き、毎日必ずメンバーが集まって話す機会をつくっています。突発的なトラブル対応などがあった際はDiscordで随時話して対応しており、リモートでもコミュニケーションに困ることはないですね。

sue445：月1でオフィスに出社するようにして、集まったタイミングで一緒にランチを食べに行ったり、定期的にオフラインでのコミュニケーションもとっています。

yoshimin：働き方に関してですと、テキストに残す文化が全社的に根付いており、私達もオペレーションをドキュメントに残すようにしています。作業内容を積極的に残すことで、情報の伝達がスムーズになっていると思います。

lyluck：特にSAチームは初見の仕事が多く、さらに範囲も広いため、未来の自分やチームのために、やり方をしっかりドキュメントに残すことを心掛けていますね。

sue445：全社的にエンジニアは自走しているのがピクシブの特徴ですが、大切な場面では一人で作業を行わないようにしています。アカウントの解約作業のように、破壊的な変更を行うときや、万が一ミスがあると致命的な作業は、Discordで画面共有しダブルチェックしています。

また、最近始めたこととして、意思決定する際にどのような意図や考えを持って決定したのかを、ADR(Architecture Decision Record) にまとめて残すようにしています。

どんな人がこの仕事に向いていますか？

sue445：先ほど触れたように自走する場面が多く個人の裁量が大きいので、言われたことのみではなく、自分で考えて選択肢を出せる人は向いていると思います。

lyluck：初めてのことに遭遇してもひるまない人、ですね。時には知らないことが芋づる式にどんどん出てくることがありますが、そうした状況でもくじけずに解決へ向けて取り組んでいける人は向いていると思います。

もちろん、一人で取り組むわけではなく、周囲のサポートや協力もきちんとあります。私自身、入社以降ずっと周囲にサポートしてもらって仕事ができていると実感しています。

yoshimin：好奇心旺盛な方も向いていると思います。私達の仕事はかなり幅広いため、様々な知識を必要とする場面が多いです。もちろんスキルや経験はあるに越したことはないですが、入社時点で全部できる必要はありません。好奇心をもって、新しい知識をどんどん吸収することが楽しめる人は合っていると思います。

ピクシブのここが好き！を教えてください

lyluck：冒頭でもやりがいとして触れましたが、色々なことにチャレンジできるところです。多くの経験を通して想像以上に成長できる環境だと思います。周囲のサポートももちろんありますが、自身の裁量も大きいので、自由にチャレンジさせてもらえていると感じます。

sue445：自分自身のスキルを高めるのを会社が支援してくれるところです。例えば書籍購入制度を利用して技術力向上につながる書籍を買って勉強することができます。

yoshimin：BtoCのサービスが主なので、ユーザーの反応をダイレクトに見ることができる点が楽しいなと思います。とくに新規プロダクトや大きな変更があったときには反響も大きく、それを目にできると嬉しいですしやりがいにも繋がりますね。

lyluck：ユーザーへの貢献はもちろん、インフラ開発という点で社内のエンジニアにもダイレクトに貢献できるのが良いですよね。

最近だと、アプリケーションをデプロイしたときに来るSlackの通知メッセージをより分かりやすい形に変更したのですが、喜びの声を社内メンバーから直接もらうことができて嬉しかったです。また、そういう感想や反応を活発に送りあう空気が会社全体としてあり、そういった点もピクシブの良いところだなと思います。

ピクシブへの入社を検討している人にメッセージをお願いします

yoshimin：幅広い業務ができる環境だと思います、興味の範囲が広く色々なことにチャレンジしてみたい人はぜひ一緒に働きましょう！

sue445：SAチームの業務では、個人の裁量が大きく、システムのアーキテクチャなどを一人で考えて構築することができます。そうした進め方に興味がある人にはおすすめです。

また、ピクシブはAWS、Google Cloudの両方に携わることが可能です。両方ともがっつり経験したいという人はぜひお待ちしています。

インフラ部 SAチームではクラウドエンジニアを募集しています。業務に興味をお持ちいただいた方は、下記エントリーフォームよりご応募をお待ちしています！

hrmos.co

“つながりが生まれる場所”「#P-HUB（ピーハブ）」誕生の背景に迫る！担当者インタビュー第2弾

2025-02-06T17:30:00+09:00

こんにちは、広報部のmikoです。2024年2月からスタートした社内交流機会「#P-HUB」について、インタビュー第2弾をお届けします！

前回は「#P-HUB」前身イベントの復活を経て、再度交流設計を検討しなおすことになった経緯を、社内交流促進を担うカルチャー推進部のメンバーに伺いました。今回は、一緒に検討を行ったコミュニケーションデザイン部（以下CD部）のお2人もお迎えして、どのように「#P-HUB」が形になっていったのかご紹介します。

「#P-HUB」担当者インタビュー第1弾 inside.pixiv.blog

メンバー紹介

カルチャー推進部：becci、megmilk
CD部：hamacooh、penpen

このメンバーで検討を進めることになった経緯を教えてください

hamacooh：CD部のメイン業務はピクシブが運営するプロダクトの交流デザインですが、インハウスのデザイン組織として、新年会や新卒歓迎会など社内イベントに関するデザインにも関わっています。

社内交流機会の設計に関わることになったのは、コロナ禍だった2022年に開催されたオンラインの社内交流イベントで、配信内で使うビジュアルデザインを担当したことがきっかけでした。

becci：オンラインイベントを開催した時に、デザインを通じてイベントの魅力がぐっとアップした実感がありました。そのため、今回もぜひCD部の力を借りて一緒に検討したいと考えていました。

hamacooh：私達デザイナーとしても、会社の価値向上にデザインでコミットしていきたいという想いがあったので、カルチャー推進部とリレーションを築き一緒に交流設計を進めたことはお互いにとってWinWinな出会いだったと思います。

どのように交流設計を進めていきましたか？

becci：まずは交流機会を実施する目的を再設定するところからスタートしました。第1弾インタビューでもお話したように、前身イベントはどれも「メンバーの交流」「繋がりを生む」という大きな目的が共通してました。新たな交流機会の目的には、さらに「ピクシブらしさ」を反映していきたいと4人で認識合わせをしていきました。

hamacooh：どういう場にしていきたいのか、ディスカッションを重ねる中でピンと来たのが「好きで繋がる」というワードでした。ピクシブには、好きなものに情熱をかけられる人達が集まっています。だからこそ「好きで繋がる」というワードがとてもしっくりはまる感覚がありました。

megmilk：「好きで繋がる」のワードに続いて、「新しく繋がる」というワードも出てきました。新しく入社してくる仲間がどんどん交流を広げられる場にしたいという想いもあったんです。更に、元からいるメンバーの関係も大事にしたいよね、ということから「もっと繋がる」というワードも出てきました。

そのようにピクシブらしい繋がり方を整理し、社内交流機会を「つながりが生まれる場所」、目的を「あたらしくつながる」「すきでつながる」「もっとつながる」の3つと位置付けました。

目的が決まり、次の議題である「名称」はどのように決めていきましたか？

becci：まず、「つながり」をイメージできる名前をそれぞれで出し合いました。例えば「LINE」「HUB」「コネクト」などのワードです。そこから何度も話し合ったりキーワードを組み合わせたりと大変だった記憶があります。「HUB」はCD部から出てきた案でした。

penpen：総称として「HUB」を使う提案をしたんです。ちょうどその頃、前身イベントとして「TGIF」「TTT（Tea Time Talk）」の2つが開かれていました。目的に合わせて異なる時間帯で開催していたので名称も異なっていたのですが、それを見て、色んなイベントが様々な名称でバラバラと点在するよりは、大きな一つのくくりのもとで統一感を持たせるのが良いと考えました。

それをふまえ、総称として「#P-HUB」があり、各イベント名称は開催時間や形式を表す「#P-HUB NIGHT」や「#P-HUB TIME」という展開をしてはどうかと提案しました。

megmilk：「#P-HUB」の「#P‐」は、社内で活用しているSlackのチャンネル名がヒントです。ピクシブで働く全員に関係するチャンネルに「#p-」から始まる名称が使われていたので、そのカルチャーと連動することで社内に馴染みやすいのではと考えました。

becci：そのような検討を重ねながら名称候補を「#P-HUB」を含む4つに絞り、最後は社内投票で決定しました。ピクシブではこれまでも社内投票で何かを決めることがよくありました。例えば、福利厚生の1つにフリードリンク制度があるのですが、商品の入れ替え時期にあわせて新たに導入するドリンクを社内投票で決める「推しドリンク総選挙」を開催しています。

そうやって社内投票で盛り上がる様子を見てきて、今回も私達だけで決めるより、メンバーみんなに選んでもらう形がピクシブらしいのではないかという想いがありました。

megmilk：交流機会がピクシブメンバーみんなの文化として浸透して欲しいと考えていたので、これまで培われてきたピクシブらしさを大事に社内投票をすることに決め、投票フォームを作りました。

becci：megmilkさんが作ってくれた投票フォームは「好きな名称を選ぶ」のではなく「各候補の好き度合いを聞かせてください」という聞き方で、良い指標だなと思いました。

megmilk：単純に、4つの候補から好きな1つ選んでもらうのではなく、それぞれどれくらい好きなのかを聞いておくことで名称に対する好感度が分かるのではと考えたんです。投票の結果、「最推しの総数」だけでなく、「好き度合い」が全体的に「#P-HUB」に集まっていることが可視化できました。メンバーみんなの名称に対する「好き」という想いがちゃんとここに集まっていると感じられたので、納得感を持って「#P-HUB」に決めることができたと思います。

＜投票フォーム＞

＜投票結果＞

投票企画について、社内の反応はいかがでしたか？

megmilk：投票で決めることを発表したときは、ポジティブな反応が多く自然に盛り上がってくれました。何かを新しく決めるとき、メンバーみんなも参加できる作り方だと受け入れてもらいやすいと改めて実感しました。

hamacooh：ピクシブでは、普段の業務でもトップダウンではなく社員一人一人が当事者として関わることが多いので、メンバーみんなで決める投票形式はピクシブらしい選択だったと思います。

megmilk：名称検討に対して熱量高く想いを寄せてくれる社員がとても多かったです。高い参加率で投票してくれて、メンバー全体をうまく巻き込んでいる実感がありました。

becci：一方で、昔からいる社員からは「TGIFの名前変えちゃうの？」という反応もちらほらありました。なので、リネームに関するアナウンスは「ピクシブらしくしたい」という意図をしっかり伝えることを大事に進めていました。

キービジュアル制作の狙いを教えてください。

hamacooh：「つながりが生まれる場所」をイメージして一緒にワクワクしてもらうためにも、キービジュアルは必要だと思っていました。

人間は視覚から一番多くの情報を得ます。ピクシブはSlackなどのテキストコミュニケーションが多いですが、Slackで「#P-HUBを開催します！」と言葉のみで発信してもイメージが湧きづらいでしょう。発信時に画像が一枚あるだけで、見え方や受け取り方が大きく変わるはずです。

becci：実際に、全社会議で「#P-HUB」という新名称を発表するときに、キービジュアルをドーンと出したことで盛り上がった実感がありました。CD部にデザイン面でも協力してもらえたおかげで、イベントの価値をより高められたと思います。

megmilk：キービジュアルがあることでイベントの内容や空気感をイメ―ジしやすく、「こういうイベントだったら行ってみたいな」と参加しやすくなっていると思います。

デザインを作るときに考慮した点は？

penpen：最初はキャラクターを入れる案もありましたが、“好みが分かれないデザイン”を目指して、あえて抽象的なデザインに落ち着きました。

また、個性豊かなピクシブメンバーが集まる場所であることをデザインで表現しています。タイトル周りの粒の一つ一つはメンバーの様々な個性を表しています。それらが繋がって一つの大きな何かになる、というコンセプトで作りました。

megmilk：キービジュアルは、会場に置くパネルや当日掲示するスライドなど、「#P-HUB」を発信するときに必ず使っています。キービジュアルがあると、何をするにも統一感が出て助かっています。

hamacooh：「#P-HUB」の名称とキービジュアルを、運用込みで固められたことはとても良かったですね。今後新たなイベントが増えても、その趣旨や内容に合わせて「#P-HUB ○○○○○」と様々な展開をしていくことができます。目的は同じイベントだという統一感を常に出せるのは大きなメリットです。

「#P-HUB」を実際に開催してみていかがでしたか？

megmilk：2024年2月にオフライン社内交流イベント第1弾「#P-HUB Time」が開催されました。まもなく1周年を迎えますが、やはり、目的をしっかり設定し、名称とキービジュアルに落とし込んだことで、どのような場なのかわかりやすく伝わっていると感じます。

becci：現在、隔月で開催している「#P-HUB NIGHT」は平均約80名、「#P-HUB TIME」も平均約70名の方に参加してもらっています。これだけの人が、オフラインで交流できる場を毎月提供できていることは、会社として大きなことだと思っています。

megmilk：参加者同士の交流に繋がる仕掛けや、会話が自然と盛り上がるための種もたくさん用意しています。会社主導で交流のきっかけは用意していますが、そこからどのように交流するかは参加者のペースに任せるスタンスです。

becci：私達から「交流してください」と無理に促すのはピクシブらしくないですし、良いコミュニケーションも生まれないと思っています。私達が提供するのは、あくまできっかけになる場所。そこから先は、みんなの好きでどんどん繋がっていけるのがピクシブらしい交流促進かなと思っています。

実際の開催内容はこちらもご覧ください！ inside.pixiv.blog

penpen：自分が作成したデザインが実際に使われ、みんなに受け入れてもらっていることを目にできることが嬉しかったです。今後、フェーズに合わせてイベントが進化したり、ビジュアルのアップデートが必要な場面も出てくるかもしれません。その時も、カルチャー推進部の皆さんと一緒にイベントを創っていけたらと思います。

hamacooh：私達もこうして会社のイベントに関わることで、デザイナーとしての価値を発揮できていると感じています。良い関係値を持って今後も関わっていきたいです。

becci：社内イベントに対して、ここまで議論して創りあげることができたのはピクシブだからこそだと思っています。時間をかけて作ってきたものが実際に形になり、メンバーみんなが前向きに受け取ってくれる姿を見て、やって良かったと感じました。これからもピクシブらしさをどこまで継続できるか、という視点で交流施策を創っていきたいと思います！

pixivリクエストで新しい創作の形を提供リクエスト部の仕事とは

2025-01-30T18:00:00+09:00

こんにちは。広報部のmikoです。
今回は、pixivリクエストの機能開発を継続的に進めているpixiv事業本部ユーティリティユニットチームリクエスト部のメンバー3名に、仕事の内容やチームの雰囲気についてお話を伺いました。

自己紹介をお願いします。

wata：2018年に入社し、マネージャーを務めています。前職はスマートフォンゲーム開発会社でシステム開発に携わっていました。趣味はダーツとコーヒーです。

saito：2020年からアルバイトとしてピクシブで働きはじめ、2022年に新卒入社しました。2020年のpixivリクエストリリース直後からチームに参加し、様々な機能開発に関わってきました。最近は自炊にハマっています。

izmipo（いずみぽ）：前職はIT系スタートアップ企業で、2021年にピクシブに入社しました。現在はpixivリクエストのPM（プロダクトマネージャー）として働いています。クラフトビールと読書が好きです。

リクエスト部について教えてください

wata：まず、pixivリクエストとは、ファンがクリエイターにつくって欲しい作品を有償で依頼できるpixivの機能です。クリエイターとファンの「好き」の気持ちをつなげ、創作活動を支える場のひとつとなっています。

リクエストサービスページ www.pixiv.net

リクエスト部は、pixivリクエストの開発や改善を行うチームで、ファンとクリエイター双方の視点に立ったプロダクト改善に日々取り組んでいます。

具体的な業務内容について教えてください

wata：マネージャーとしてチームの目標設定と進捗管理を行いながら、PMやエンジニア、デザイナーと連携しています。各メンバーの強みを活かしながら、プロジェクトの進行調整や、技術面やプロダクトの方向性についての意思決定に関わっています。

saito：pixivリクエストの機能開発や運用・保守に関わるエンジニアリング全般を担当しています。ユーザーからのお問い合わせに関する調査やデータ分析のサポートなども行うほか、pixivリクエストだけに留まらずpixiv全体に関わる取り組みを行うこともあります。

izmipo：プロダクトバックログの運用や、プロジェクトの起案と全体進行などに携わっています。リクエスト部では要件定義の段階からエンジニアと一緒に決めていくことが多く、PMとしてディスカッションの「場」を用意することも大きな役割です。

過去の印象的な業務はありますか？

wata：印象的なのは、pixivリクエストの立ち上げメンバーとして担当した決済周りの設計や実装です。決済基盤を扱うチームや経理チームと調整を重ねながら進行し、スムーズかつ安全な決済フローの構築を目指しました。現在も安定して稼働しており、ユーザーが安心して利用できるサービス基盤を支えている点に大きなやりがいを感じます。

saito：大規模なプロジェクトにリードエンジニアとして参加したことです。効率的に開発を進行できるように、事前に設計や技術選定のレビューをする仕組みを整えたり、開発経験が少ないメンバーでも自走できるようにドキュメントを整備しました。自分も他のメンバーも高い生産性を維持してプロジェクト終盤まで開発を進めることができたと思います。

izmipo：[クリエイターがリクエストの募集を再開したときに通知を受け取れる機能]の開発です。一見シンプルな機能ですが、開発の過程で多くの議論がありました。「さまざまな理由でリクエスト募集をお休みしているクリエイターの存在をどこまで可視化するか」「モチベーションに繋がるベストな通知頻度や内容は？」といった課題を、ターゲットの視点に立ちながら検討を重ねました。ありがたいことに、予想以上に多くのユーザーにご利用頂けています。

仕事のやりがいや楽しいところは？

saito：コミッションという事業ドメインはまだ新しく、今も成長し続けているため、pixivリクエストのシステムも常にアップデートしています。急速に変化する環境下で、ユーザーへ新たな価値を迅速かつ安定的に提供するためには、高度なエンジニアリングが不可欠です。エンジニアとして、そのような環境で腕を振るえることにやりがいを感じます。

izmipo：複数のステークホルダーの視点を踏まえて解決策に落とし込むのは、難しいですが取り組みがいがあります。「pixivリクエストのユーザー」と一言で言っても、クリエイター、ファン（リクエスト送信者）、相乗りファン（既にあるリクエストに同じ金額を上乗せして応援するファン）と様々な形が存在します。そのため一方のメリットを追求すると、他方の負担になることも発生し得ます。プロダクトとして一貫した方針はありますが、最終的な着地はステークホルダーを取り巻く状況を加味して決めることが多いです。

チームとしてはどのように連携していますか？

wata：リモートワークが基本で、必要に応じて出社しています。フレックス制度も活用して、各メンバーが生活スタイルに合わせた働き方をしていると思います。

saito：自分もほぼ毎日リモートワークです。リモートでも働きやすい仕組みや文化が醸成されており不便を感じることはほぼありませんが、コラボレーションが要求される業務では出社することもあります。

izmipo：同期・非同期でコミュニケーションを使い分けていますよね。リクエストチームは発足当初からNotionを使ったドキュメント文化が浸透しており、私がチームに参加したときも過去のログに助けられました。

wata：定期的なミーティングとNotionでの情報共有を通じて、非同期でもコミュニケーションを取りやすい環境が整っているのでありがたいです。

saito：Notionのプロジェクトテンプレートに加え、最近はエンジニア相談のSlackワークフローも追加するなど、仕組みをうまく活用しながらコミュニケーションを取れていると感じます。

チームの雰囲気について教えてください

wata：各メンバーが自走しながら、必要に応じて意見交換やサポートを行っています。互いに尊重し合う文化が根付いているため意見も出しやすく、また受け入れられる環境も整っています。幅広い視点をふまえてプロダクトをより良くし、その中でメンバー自身も成長できていると実感します。

saito：サービスリリース当初は、メンバーが各々の裁量を発揮して成果を上げるという良い意味で属人化したチームスタイルでした。最近はチームが成熟してきたこともあり、チーム全体で生産性を高めるスタイルに移行しつつあります。業務の仕組み化が進行しているため、オンボーディングが終了したばかりの新メンバーでも活躍しやすいと思います。

izmipo：課題に対し集合知で解決していく姿勢と、自律性の高さの2つを兼ね備えたチームだと感じます。また、過去にインターンやアルバイトを何名も受け入れた実績があり、新メンバーへのオンボーディングも常にアップデートされています。私がチームに参加した当初は自身のドメイン知識不足が気がかりでしたが、疑問の共有を歓迎する雰囲気がチームにあり、安心して一つずつ学ぶことができました。

チャレンジしていきたいことや目標など今後の展望を教えてください

wata：今後もチーム全体でスキルを高めつつ、ユーザーにとって価値あるプロダクトを提供していきたいです。特に、pixivリクエストのさらなる可能性の模索とサービス全体の安定性向上に注力したいと考えています。

saito：入社してすぐの頃はpixivリクエストのことで精一杯でしたが、ここ数年はpixivというプラットフォームの一部としてpixivリクエストを捉えられるようになってきました。今後は、pixivリクエストを足がかりとしてpixiv全体に寄与できるようなエンジニアリングに挑戦していきたいです。

izmipo：pixivリクエストは現在多くのユーザーに利用いただいていますが、まだまだ成長途中のプロダクトです。ピクシブの他のサービスとも連携して、コミッションに関する多様な楽しみ方を提供していきたいと思っています。

どんな人がこの仕事に向いていますか？

wata：チームでの連携を大切にし、ユーザー視点で考えられる人は向いていると思います。また、技術的なチャレンジを楽しみながらプロダクトの成長に貢献したい方も活躍できるのではないでしょうか。

saito：全体最適と個別最適のバランスを取ったエンジニアリングをできる人も向いていますね。pixivリクエストは、pixivやpixivFANBOXと同じコードベースでモノレポとして管理されています。そのため、pixivリクエストの機能を実装するときに他のプロダクトでも利用されているコードを参照することがよくあり、実装時にはバランス感覚が求められます。

izmipo：要件定義からディスカッションに加わることが多いので、ユーザーと開発者の目線を行き来できることも大事だと思います。コミッションに触れたことがあるかは重要ではなく、様々な立場にあるユーザーの存在を尊重できる人と一緒にプロダクトを良くしていきたいです。

ピクシブのここが好き！を教えてください

wata：お互いの趣味や好きなことを尊重し合う文化がとても良いなと感じます。趣味を楽しみながらプロフェッショナルとして成長できる環境も魅力です。

saito：社員みんなが、お互いの「好き」という気持ちを尊重しあっていますよね。"With Open Minds（多様な好きを受け容れよう。）" という企業バリューを体現していると思います。

izmipo：尊重しあう空気のおかげで、自分の趣味について臆せず話せる環境が嬉しいです。私はピクシブに入社してから小説を書くようになり、最近人生初のサークル参加を経験しました。身近な誰かが創作しているという状況に元気をもらいながら自身も創作を楽しんでいます！

ピクシブへの入社を検討している人にメッセージをお願いします

wata：チャレンジ精神を持って新しいことに取り組める環境が整っています。一緒にプロダクトを成長させ、ユーザーに喜んでもらえるサービスを作っていきましょう！

saito：創作を続けるためには、評価・数字・孤独・お金の不安といった様々な壁を超える必要があります。私達はコミッションという新しい創作の形を提供することでクリエイター支援を目指しています。エンジニアリングで一緒に創作文化を支えたいという人は、ぜひお待ちしています。

ユーティリティユニットチームリクエスト部の業務に興味をお持ちいただいた方は、下記エントリーフォームよりご応募をお待ちしています！

hrmos.co

「ピクシブキッズデー2024」を開催しました！

2025-01-30T13:00:00+09:00

ピクシブでは2023年より「ピクシブキッズデー」という子育てをしながら働く社員と、そのご家族を招待するイベントを開催しています。子どもを交えた社員同士の交流や、ご家族に会社の雰囲気を知ってもらうことを目的としています。
前回の経験を踏まえて、より子どもたちの思い出に残るようなイベントとなるようにコンテンツを充実させました。そんな2024年12月に行われた「ピクシブキッズデー」の模様をお伝えします！

当日の様子

会場には、たくさんの食べ物と飲み物を用意しました。イベントの中盤にはケーキも登場！クリスマスらしいデザインのケーキに子どもたちの喜ぶ声が聞こえました。

ゲームコーナー

射的、ボール投げ、ボウリングと3つのゲームを設置し、幅広い年齢層の子どもに楽しんでもらえるようにしました。子どもたちには事前にスタンプカードを配り、すべてのゲームで遊んでスタンプを集めるとオリジナル缶バッジが制作できるスタンプラリー形式にしました。

創作体験コーナー

ピクシブのサービスの根幹である「創作活動」を体験してもらうべく、3つのコンテンツを用意しました。
まず、ピクシブが2024年にリリースしたペイントツール「Pastela（パステラ）」体験コーナー。iPadを使って自由にお絵描きを楽しんでいました。
そのほかにも、木材でできたクリスマスオーナメントにクレヨンで色塗りができたり、ツリーやリースが描かれているシートにシールを貼ることができるコーナーを用意し、集中して創作に取り組む子どもたちの様子が見られました。

ジャグリングショー

前回に引き続き、社員によるジャグリングショーが行われ、本格的なパフォーマンスに子どもだけでなく大人からも歓声があがりました。また、バルーンアートにも子供たちは大喜び！バルーンでできた剣を持って会場を駆け回る子もたくさんいました。

ステージショー

今回は、なんとオフィスに怪人イラストレーターのチェリ藻さんが登場！突然現れたスペシャルゲストに子供たちは大興奮！
ショーの後はチェリ藻さんとの撮影会やグリーティングが行われました。開催にご協力いただいたチェリ藻さん、ありがとうございました！

ビンゴ大会・絵本交換会

お菓子やおもちゃなどの景品が当たるビンゴ大会では、子供たちの「ビンゴ！」という元気な声が飛び交いました。
絵本交換会では、年齢ごとにグループを分けて、それぞれ買ってきた絵本を音楽に合わせて交換しました。後日社内Slackへ、交換会でもらった絵本を食い入るように読む子どもの写真をアップする社員もいました。

お土産

社員のご家族や子どもたちにピクシブのサービスに触れてもらいたいという想いのもと、pixivFACTORYで作成できるDECOチョコをプレゼントしました。キッズデーオリジナルのかわいらしいデザインに仕上がっています。

終わりに

初めて開催した昨年の経験を踏まえて、よりコンテンツを充実させて実施することができました。今年、新たに用意した企画も楽しんでくれて子どもたちに特別なクリスマスの思い出を提供できたと思います。

参加してくれた方からは「イベント翌日、保育園に行く際に何度も会社の方向に行こうとするくらい楽しかったようです」「一年に一度といわず、何度も開催してほしい！」といった、嬉しい感想を多くいただきました。社員が家族を交えて交流できるイベントとして、今後もピクシブの恒例行事として開催できればと思っています。

そしてピクシブは、どんなライフスタイルにおいても心地よく働けるようなさまざまな支援制度を設けています。関心がある方は、ぜひ会社HPをご覧ください！

www.pixiv.co.jp

ピクシブはRubyKaigi 2025に参加したい学生さんを招待します

2025-01-29T17:00:00+09:00

クリエイター事業部FANBOX部の丸山(@alitaso)です。

本記事の要点

ピクシブは2025年4月16日（水）〜4月18日（金）に愛媛県松山市にて開催されるRubyKaigi 2025に参加したい学生向けの招待企画を実施いたします。
RubyKaigi 2025一般参加チケット/公式懇親会チケット/RubyKaigi会期中の宿泊費/往復交通費をピクシブが負担しますので、招待学生は格安でRubyKaigi 2025に参加可能です。
参加希望の学生さんは2月9日（日）23時59分までにこちらのフォームからご応募ください。

RubyKaigi 2025とは

RubyKaigiはプログラミング言語Rubyに関する世界最大級の国際カンファレンスです。

今年は4月16日（水）〜18日（金）の3日間にわたって、愛媛県松山市にある愛媛県県民文化会館にて開催されます。Rubyの作者まつもとゆきひろ氏をはじめ、国内外から数多くのRubyコミッター、Rubyistが参加します。

Rubyコミュニティのお祭りであり、OSSプログラマーが集結するRubyKaigiの熱量は圧倒的です。Rubyが好きな学生さんはもちろん、言語処理系やOSSに興味がある学生さんにぜひおすすめしたいカンファレンスになっています。 rubykaigi.org

招待企画の概要

RubyKaigi 2025に参加したい学生をご招待します。参加費・宿泊費・交通費の全額をピクシブが負担しますので、RubyKaigi 2025に格安で参加することが可能です。

参加可能な人数

4名

参加特典

RubyKaigi 2025一般参加チケットおよび公式懇親会チケット
RubyKaigi会期中の宿泊費
往復交通費
ピクシブ社員とのカンファレンス参加
ピクシブ社員との交流（ランチ会・懇親会等）

応募条件

大学、大学院、高専、専門学校に所属する学生（※学校種別、学部・学科、専攻不問）
カンファレンス終了後、参加体験記・ブログを書ける

選考フロー

書類選考
面接（1回）
参加決定

応募締め切り

2月9日（日）23時59分

応募方法

こちらのフォームからご応募ください

昨年、一昨年も同様の企画を提供しておりました。その時の様子は以下の記事をご覧ください。

遠方開催により金銭的に参加が難しいと考えていた学生の一助になればと思い始めた企画です。プログラミング言語やOSS好きな学生に届いたら嬉しいです。

学生の皆様からのご応募を心よりお待ちしています！

唯一の日本人としてイタリアのカンファレンスに参加してみた！【GoLab登壇レポート】

2025-01-29T12:00:00+09:00

こんにちは！カスタマーオペレーション＆セーフティ本部所属のエンジニア学生アルバイト、logicaです。

去る11/11〜13、イタリアのフィレンツェで行われたGo言語の国際カンファレンス「GoLab」に参加 & 登壇するという貴重な機会をいただきました。今回は私視点から見たGoLabの様子と、この活動に対してピクシブからどんな支援をいただけたのかについて、お話しできればと思います。

GoLabとは

golab.io

The International Conference on Go in Florence

Develerという会社が運営している、Go言語の国際カンファレンスです。RustLabというRustのカンファレンスと同時開催しています。

RustLabとの合算ですが、600人以上が参加しているかなり大規模なカンファレンスです。Contributor Summit (Go言語のメンテナンスをしているエンジニアたちがオフラインで集まってディスカッションをする場所) をホストしていることもあり、Go Teamのメンバーも多数参加しています。イタリアをはじめヨーロッパ全土やアメリカ、果てにはチリから来ていた参加者もいて、人気の高いカンファレンスであることがうかがえます。

登壇に至るまで

私のGo言語コミュニティ参加

今の部署では主にPHPを用いて開発を行っていますが、私は以前から趣味開発でGo言語を多用する生粋のGopherです。人との交流を好み、人前での発表が苦にならない性格が幸いし、1年ほど前から日本Go言語コミュニティに頻繁に顔を出したり、登壇させていただいたりするようになりました。

国内登壇を何度か経験すると「次は海外で！」という機運が高まるものです。幸いある程度英語は得意だったので、腕試しのつもりで1つ海外向けのプロポーザルを書いてみました。そのプロポーザルでいくつかの海外カンファレンスに応募してみたところ、大変ありがたいことにGoLabでご採択いただき、登壇が決定しました。

渡航費の捻出

GoLabでの登壇が決まった時、最大の問題だったのが渡航費です。元々申し込み時に「宿泊費を出します」としか書かれておらず覚悟はしていましたが、プロポーザルの採択のお知らせを受け取った際、やはり「日本からの旅費は出せないから、自分で捻出してほしい」という旨を伝えられました。

イタリアまでの渡航費と運営がサポートしない前乗りの宿泊費は、学生の私が捻出するにはさすがに高い金額なため諦めようかとも考えました。ですがこの登壇は大変貴重な機会でしたので、ひとまず今通っている大学とアルバイト先のピクシブに相談することにしました。

指導教員に調べていただいたところ、大学からの渡航費の支援は最大5万円までであることがわかったため、そこを踏まえてピクシブに相談しました。

挑戦を応援していただける環境

ピクシブではプロダクト開発ギルドを中心に、社員のコミュニティ活動を奨励する取り組みが行われています。その代表的なものが、つい最近insideに掲載されたこちらの支援制度です。 inside.pixiv.blog

私はアルバイト社員のためこちらの支援制度が適用されたわけではないのですが、在籍部署の上長とプロダクト開発ギルド、人事採用チームを中心に今回の支援を検討していただきました。最終的には出張という扱いで、残りの金額を負担していただいただけでなく、GoLabの会期中は勤務扱いとしていただくという、想定をはるかに上回る支援をしていただきました。

GoLabの様子

ここからは、GoLabの中で個人的に印象に残っている部分をお届けします！

Keynote: Go Telemetry Wins - Russ Cox

Go Team(Go言語をメンテナンスしているGoogle内のチーム)の元Tech Lead、Russ CoxさんによるKeynote Session！Goに最近導入された、Goコマンドがどのように使われているのか利用状況調査をする「Telemetry」という仕組みのお話でした。

youtu.be

OSSの言語として利用状況を把握するためには、利用者のプライバシー・利用者の払う計算リソース・開発者と利用者の情報格差など様々な考慮事項を解決する必要があります。GoではTransparent Telemetryという設計を導入することで安全かつ効率的な利用状況調査を実現しており、まだ導入から数か月しか経っていないにも関わず様々な利点が生まれているということを話していました。

Keynote: Go Back To The Future - Ron Evans

Tiny Goのメンテナー、Ron EvansさんのKeynote Session！

youtu.be

セッション中に部屋の中でドローンを飛ばし、最後には複数のAIモデルに「今後人類がAIと共存していくためにはどうしたら良いか」を議論させるなど、かなりぶっ飛んだセッションでした。個人的には最後のAI議論の中で「人間をAIのペットにする」という不穏な発言が出た際、会場が笑いの渦に包まれていた瞬間が一番面白かったですね。

日本でtakasagoさんが主催していた「TinyGo Keeb Tour 2024」という企画についてもセッションの中で触れていただき、日本Goコミュニティのメンバーとして非常に誇らしい思いでした。 https://tinygo-keeb.connpass.com/tinygo-keeb.connpass.com

登壇: Resizing Animated GIFs Without CGO or Third-Party Libraries

もちろん私の登壇もありました！GoLabの中では、最後のLT・Keynoteの直前、Deep Dive Sessionの最終枠で登壇させていただきました。 youtu.be

Goの標準ライブラリではサポートのない、アニメーションGIF画像の拡大縮小をGo言語のみでやる方法について話しました。もともとGoは画像処理に強くないと言われており、GIFの拡縮はC言語ライブラリとの組み合わせでやることが多いため、かなり目新しい内容だったんじゃないかと思います。

登壇後、見ていただいた方々から「順序立てた説明がめっちゃわかりやすかったよ！」というお言葉をいただいたり、「GIFって辛いよね」みたいな議論に発展したりと、初めての海外登壇としては個人的に大満足の出来でした。

参加者との交流

実はKeynote以外のセッションはほとんど聞けておらず、その代わり同じくGoLabに参加していた人たちとの交流を楽しんでいました。

Russ CoxさんをはじめとするGo Teamの方々との会食で、Russ Coxさんのセッションの深堀りや日本Go言語コミュニティの盛り上がりについての共有をしたり Ron Evansさんから、最近の日本TinyGoコミュニティについて大変好意的なフィードバックをいただいたり他にも様々な国のGo言語ユーザーとお話しをして、様々なユースケースに対するGo言語の使い方や、エンジニアとしての生き方について意見交換することができました。

まとめ

今回、ピクシブや大学からの支援をいただいたおかげで、非常に少ない自費負担でGoLabに参加でき、多大な学びと経験を得ることができました。重ね重ね感謝申し上げます。

今回のGoLabの経験を、これからピクシブ内をはじめとして日本Goコミュニティに還元していきたいと思っています。日本のGoコミュニティ全体が一つ上の段階を目指せる、そんな環境づくりができたらいいなと考えています。

最後に、GoLabの運営をしていただいたDeveler様、GoLab中に交流していただいた皆様、日本から応援してくださっていた皆様への感謝でこの記事を締めくくらせていただきたいと思います。誠にありがとうございました！

BOOTHの安心・安全な運営を支える CSサポートチームの仕事

2025-01-22T17:30:00+09:00

こんにちは、広報部のmikoです。今回はクリエイター事業部 BOOTH部 CSサポートチームのメンバー4名に、仕事の内容やチームの雰囲気についてお話を伺いました。

自己紹介をお願いします

misakit：エンジニアとして2016年に新卒入社しました。入社以来BOOTH部の所属で、現在は、CSサポートチームのマネージャーを務めています。

naminbo：2018年に入社し、現在はコミュニティマネージャー（以下CM）としてCSサポートチームに所属しています。現在の主な業務は、商品チェック運用周りの管理などです。

reud：2023年にエンジニアとして新卒入社しました。入社以来CSサポートチームに所属しており、管理画面の改善や商品チェックシステムの実装をしています。

cornpan：2023年にピクシブに中途入社しました。現在はCMとしてCSサポートチームに所属し、ユーザー対応や、BOOTHをご利用いただいている企業の対応などを主に担当しています。

BOOTH部 CSサポートチームについて教えてください

misakit：まずBOOTHとは、ピクシブの運営するショップ作成サービスで、クリエイターが自由にグッズや作品を販売し、それをファンが購入できる創作物の総合マーケットプレイスです。2013年にリリースし、現在は累計登録ショップ数約62万店を突破する規模へと拡大しています。

BOOTHサービスページ booth.pm

CSサポートチームは、BOOTHを運営しているチームのひとつです。サービス規模が大きくなるにつれ増えていくユーザーの困りごとやサービス運営上の問題に対応し、安全かつ円滑な運営を続けるための改善を担当しています。

具体的な業務内容について教えてください

misakit：私はチームにおける最終判断やメンバーの進行サポート・マネジメントが主な業務です。メンバーが立案するサービス改善、業務改善、満足度向上の施策などのレビューや方向性決め、業務の進行補助などを行っています。また、エンジニア出身なので、たまにコードを書いたりもしています。

naminbo：現在の主な担当は商品チェックに使う基準書の整備などBOOTHサービスの安全面に注力した業務に携わっています。他には、BOOTHで利用している運送会社やチャットボットを提供する会社の窓口の対応を行なっています。

reud：私はエンジニアなので、BOOTHの運営にあたってCMメンバーが困っていることをエンジニアの観点から解決できないか、を常に模索しています。今取り組んでいる仕事の一例として、今はnaminboさんが先ほど話していた商品チェックの基準書改善に併せて、チェックシステムの継続的な開発をしています。

cornpan：ユーザーまわりの対応や特集の企画が主な業務です。BOOTHの問い合わせ対応は基本的に福岡のCSチームが行ってくれていますが、一部はCMで対応をしています。その他にも、BOOTHを使ってくださっている企業の窓口対応なども行っています。

仕事のやりがいや楽しさについて教えてください

cornpan：季節やイベントに合わせた商品特集をBOOTHサービスサイト上で定期的に組んでいます。商品をピックアップしたクリエイターの方々から喜びの声をいただくこともあり、やりがいに繋がっています。また、最近は他部署からこういう特集を組んでほしいという依頼を受けることもあり、部署間の連携が広がっていることも嬉しいです。

reud：同じチームのCMの方々の悩みを解決する仕事が多いので、喜んでくれている姿を間近で見れる点が嬉しいです。人に目を向けて仕事をしている感覚があり、自分には合っていると感じます。

naminbo：ユーザーや社員の声を受けてサービス改善を適宜行っています。エンジニアと相談を重ね試行錯誤しながら、その結果が形になってリリースされていく体験はとても達成感があります。

misakit：現場目線でサービスに必要な施策を自主的に行える環境が、チームとしての魅力であり仕事のやりがいに繋がっていると思います。また、チームメンバーにエンジニアがいるため、必要なサービス改善をスピーディーに行える環境も良いところです。

働き方やチームの雰囲気について教えてください

misakit：メンバーは基本的にリモートワークで勤務しています。各々で仕事を進めることが多く、定例や必要なときにオンラインで打ち合わせをするなど、適度な距離感があるのが良いところかなと思います。

reud：ミーティングもリモートが主ですが、部の振り返りのときなどはオフラインで集まっています。話しやすいメンバーが多いので、リモートでもコミュニケーションに困ることはないですね。

naminbo：基本は各々で仕事を進めていますが、1人で考えていると分からないことも当然出てきます。業務の悩みを相談したいというときは、声をかければすぐにミーティングを開いて壁打ちができる環境があります。

cornpan：メンバー1人ひとりが自走しながらも、仕事を一人で進めている感覚はないので安心して仕事を進められています。

reud：全社的に根付いているテキスト文化も、働く中でとても助けられています。情報をテキストで蓄積することが重要視されているので、例えばちょっとした疑問が出たときに、SlackやNotionなどを検索して出てきたログが解決に役立つことが良くあります。

misakit：テキストコミュニケーションがあるおかげで、リモートであってもお互いどこかで作業しているのが伝わり、チームで動いていると感じられる環境だと思います。

どんな人がCSサポートチームの仕事に向いていると感じますか？

misakit：先ほども話に出たようにテキストによってコミュニケーションを行う必要があるので、言語化してテキストを残すことが苦にならない方が働きやすいかなと思います。

reud：私はピクシブで働く中で、テキストでのコミュニケーションの居心地良さを感じるようになりました。文章で何かを伝えるとき、書き方やニュアンスによって感じるイメージが変わる点が難しいですが、チームメンバーが書く文章はみんな読みやすく丁寧で、伝えたいことが的確に伝わってきます。自分の発言によって相手がどう捉えるかを意識できる人は合っていると思います。

cornpan：ピクシブのサービスはアニメやマンガなどサブカルチャーを扱うものがメインです。私自身そういったカルチャーがもともと好きで、前提知識があったからこそ今業務しやすいと感じる場面が多いです。なので、マストではないですが、業界やカルチャーを知っているとより業務に活かせます。

naminbo：情報を自ら拾ってきたり、分からないことは人に聞きに行く推進力がある人も向いていると思います。リモートが主体で人と顔を合わせる機会が少ないぶん、Slackで聞いたり、情報を積極的に探しに行ける方は働きやすいと思います。

ピクシブのここが好き！を教えてください

reud：入社して感じたのは、ピクシブは社内における情報の透明性が非常に高いという点です。会社として重要な動きがあると、その理由や経緯が全社的にきちんと共有されます。私は入社時の理由のひとつが「インターネットの最前線がどういう動きをしているのかを見たい」と思ったことでした。なので今、企業の判断やその背景、それに対する反響を最前線で見れることをとても面白いと感じています。

misakit：他部署がやっていることが見えるのも楽しいと感じられる部分かもしれないですね。私は、働くスタンスを選ぶ自由度が高いところや、先ほどリモートワークの話でも触れた「メンバー同士の適度な距離感」が好ましいと感じています。

naminbo：適度な距離感、わかります。私は、社員同士の交流企画が多い点が印象的でした。会社として交流の機会が積極的に創られていて、かつ強制ではないところもまさに「適度な距離感」だと思います。また部署を超えての交流は、仕事のやりやすさにも繋がります。他部署と仕事をする際、少しでも知っている人だと相談もしやすいので、単なる交流に留まらない良い取り組みだと感じます。

cornpan：会社自体がこういった交流機会を用意してくれるのはありがたいですよね。強制ではなくて、自由に好きなタイミングで参加できるので、自分のスタイルや状態にあわせて選べるのがとても良いと思います。

チームとしての目標やこうなりたいという展望があれば教えてください。

misakit：対処する対象が、日々予想されるものよりも突発的なものが多いチームなので、リスクを先読みしたり、不測の事態が起きたときにも後手になりすぎず対応を考えられるチームになりたいと考えています。

そのために、「何をするべきか」をきちんと考えることを大事にしていきたいです。何か課題が出たときも、様々な場面を想定して解決案をパターン出しするなど、チームみんなで常に考え、その時々の最適解を探しながら、BOOTHの運営を支えていければと思います。

名古屋工業大学『C0deハッカソンwithピクシブ』を今年も開催しました！

2025-01-14T12:00:00+09:00

みなさんこんにちは。採用担当のmarikoです。

この度、『第2回C0deハッカソンwithピクシブ』を開催いたしました！今年もたくさんのアイデアやプロダクトが生み出されましたので、当日の様子をぜひ紹介したいと思います。

第1回ハッカソンの様子はこちらから確認いただけます。

inside.pixiv.blog

なぜ第2回が開催されたのか？

1年前に開催された第1回ハッカソン。「来年もできたら良いね」と話はしていましたが、実際に「今年もやりましょう！」と学生からお話をいただき開催が決まりました。昨年のよかったところを残しつつ、新たな取り組みも加わっており、みなさんの力強さを感じました。

ハッカソンのテーマは？

ピクシブとの共催ということもあり、親和性の高いテーマ含め以下3つを設けました。

お絵かき関連アイデア
ピクシブに関連するアイデア
自由アイデア

昨年同様、ピクシブからは学生が困った時に相談ができるメンターを技術領域ごとに3名アサインしました。決まった時間にDiscordで気軽にコミュニケーションがとれる体制を継続して作りました。

発表会の様子

今年は10チーム約33名が参加しました。各チーム3分でプレゼンを行い、その後ブースでデモを見てまわりました。

受賞チーム

今回もどのチームも素晴らしかったのですが、ピクシブからは下記5つのチームに賞を贈りました。おめでとうございます！どのチームも頑張った自分たちに大きな拍手を贈ってください。

最優秀賞：チーム名：ひつじのひつじ（プロダクト名：マチケンナンバ 🐏）
優秀賞：チーム名：NOT画像生成AI（プロダクト名：copilust 👨‍🎨）
kobaken賞：チーム名：昆虫色のすゝめ（プロダクト名：HTMiL 🎨）
atsuyan賞：チーム名：河野素人共（プロダクト名：アプリを閉じただけなのに 😠）
mimo賞：チーム名：電気情報工学科（プロダクト名：HUMOR 🎶）

各チームやプロダクトの詳細は、C0deさんのXアカウントに掲載されています。

機能の紹介や工夫したポイントが紹介されているので、ぜひチェックしてみてください。

参加者および運営の皆さん今回もお疲れ様でした。チームで協力する姿や、開発の過程を楽しそうに話す姿が強く印象に残っています。

ピクシブは、今後もエンジニアを目指す学生を様々なかたちで応援していきたいと思っています。あなたの学校でも、ハッカソンやピクシブを知るきっかけになるイベントを開催しませんか？今回の記事を読んで、興味を持っていただいた方はお気軽にお問い合わせください。

おわりに

現在、新卒採用および学生向けにアルバイト・インターンの募集を行っております。ピクシブで働くことに興味をお持ちの方は、エントリーを検討いただけると嬉しいです。

www.pixiv.co.jp hrmos.co hrmos.co

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

ピクシブにおける「ビジョン」の取り扱われ方

2024-12-27T17:30:00+09:00

プロダクト開発イネーブルメント部マネージャーのminamitaryです。

PIXIV DEV MEETUP 2024では、ピクシブにおける「ビジョン」の取り扱われ方 というタイトルでメインセッションを担当しました。

スライドはイベント当日に公開されていますが、スライドだけでは伝わりづらい部分も多くなっています。

本記事では、時間の関係でカットせざるを得なかった内容を補足しつつ、セッション内容を紹介していきます。

2020: プロジェクトシェルパ

まず背景として、2020年のピクシブでは「社員数の増加」「プロダクトの増加・多角化」「個々のプロダクト規模拡大」といったことが同時進行していました。そこに対してさらに「新型コロナウイルスの感染拡大」という出来事が重なります。人数・並列数が増加するなかでリモート環境への強制移行が同時に進み、プロダクトづくりの難易度が著しく高まるような状況でした。

そのタイミングで私が携わっていたチームが「プロジェクトシェルパ」です。

プロジェクトシェルパはVP of Productを筆頭とする部署横断のタスクフォースで、プロダクトマネージャーを中心とするシニアメンバーメインに組織されました。私自身も事業部門でUXリサーチャーとして動きつつ、ここにも携わっていたという形です。

プロダクトづくりを「険しい山に登るような行為」と捉え、山の案内人「シェルパ」のような立ち位置で社内をサポートして回る。そんな動きをこのチームでやっていました。その際スローガンとして掲げていたのが、「ピクシブらしい開発を誰でもできるように。」という言葉です。

この、「ピクシブらしい開発」とはどのようなものかと思われるでしょう。

ここについては、プロジェクトシェルパとしての活動を具体例として紹介する方が伝わりやすいと思います。プロジェクトシェルパは社内の開発現場に対する個別の支援はもちろん、そこから得られた知見を元に仕組みを作って社内に提供するようなこともやっていました。

その一つが「インセプションデッキ」です。

インセプションデッキ

「インセプションデッキ」は、プロジェクトを起案する際に概要をまとめ、チームメンバーやステークホルダーとの間で共通認識とするためのドキュメントテンプレートです。もともとピクシブでは、アジャイル開発の現場で使われているものに手を加える形でテンプレート化・運用されている状態にありました。そこに対し、プロジェクトシェルパとしてさらにアップデートを加えていった形となります。

その際、重視していたのは「何のために取り組むか」を明文化するという部分です。この言葉は、本記事の中で何度も登場します。

ピクシブで運用されている「インセプションデッキ」のテンプレートを簡単に紹介すると、大きく以下の4段階で構成されています。

まずはDraftとして、どういったアイデアや背景がプロジェクトのベースになっているのか。それからWhy、なぜ、何を目的としてプロジェクトをやるのか。その後Whatで「具体的に何をするのか」、Howで「進める上での懸念はあるか」、といった流れで記述していく形のテンプレートとなっています。

時間の都合上イベント当日のセッションでは割愛しましたが、Whyの部分は「誰に意味を提案するか？」「どんな意味を提案するか？」といった問いに答える形式となっています。

実際のところはプロジェクトシェルパだけですべてを整備するのではなく、開発チームの方々に実際に使ってもらいつつ、Notion上のテンプレートやドキュメントを一緒に育てていくようなイメージで進められていました。

その取り組みのなかでも、「二つめの”Why”、すなわち“何のために取り組むか”の部分を大事にしましょう・しっかり明文化しましょう」というところに重点が置かれていました。

シェルパガイドブック

そう言われても、「実際のところどのようにプロジェクトを進めていくか」という部分こそが難しいと思われるかもしれません。ドキュメントテンプレートだけあっても、じゃあ「あとはやるだけ」とはなかなかならないと感じる方も多いでしょう。

そこに対して手を打つ形で作られたのが「シェルパガイドブック」です。

先ほどお話しした通り、プロジェクトシェルパでは、プロダクトづくりを「険しい山に登るような行為」と捉えていました。

山を登る間に目指すべき場所を見失ってしまったり、障害にぶつかって先に進みづらくなったりといったことが、時には起こってしまうものです。

険しい山に登る際にこの「シェルパガイドブック」を手元に忍ばせておいてもらい、困った時に開くと「こうするともっとうまくいくかもよ」と解決方法を提案してくれるような、そんなコンセプトでこのドキュメントを作り、社内に向けて提供していました。

このガイドブックの中でも、先ほどのインセプションデッキでも触れた”Why”の部分、「なぜ山に登るのか」「山登ることで何を得たいのか」といった問いに対して、きちんと向き合うことの重要さを説いています。

そこに対するアンサーは、ビジネスゴールであることももちろんありますが、開発チームにおいては「ユーザーに対してどういった価値・意味を提供したいか」といった観点を基調として運用されています。

こちらのドキュメントは長らく社内に閉じたNotionで運用してきましたが、この度、この場を利用して、社外からもアクセス可能な場所に配置させていただきました。

pixiv.notion.site

こちらを読んでいただければ、ピクシブらしいプロジェクトの進め方についてより理解が深まるのではないかと思っています。

ビジョナリーシート

先ほど「インセプションデッキ」というドキュメントテンプレートについてお話ししましたが、ほかにも「ビジョナリーシート」という名前のドキュメントテンプレートも社内に向けて提供しています。耳馴染みがないと思いますが、こちらはピクシブ独自で作成・運用されているものです。

このビジョナリーシートはその名の通り、「ビジョン」を扱うドキュメントテンプレートです。プロジェクトのスコープよりもさらに広い視点でビジョンを記述し、人に伝える用途で作成されました。

当日のセッションでは時間の都合上割愛してしまいましたが、少しだけ中身について触れておくと、以下の3つの問いに対して答えていく形式のドキュメントとなっています。「X年後」の部分は対象とするプロダクトによって調整する形で、3年や5年を想定して書かれることが多いです。

プロダクトとその周辺の世界観はX年後どうなっているか？
このX年間で腰を据えて取り組むべきイシューはなにか、その理由は？
結果として、プロダクトそのものにどういう差分が生じているか？

「インセプションデッキ」と「ビジョナリーシート」はそれぞれ扱うスコープが異なるため、併用することが前提の設計となっています。

「ビジョン」

ここまでに紹介した事例から、「何のために取り組むか」という問いと向き合うことを重視し続けていることが伝わるのではないでしょうか。それこそが、プロジェクトシェルパにおいて「ピクシブらしい開発」として掲げていたものです。

このセッションのタイトルに掲げている「ビジョン」という言葉は、これが明文化されたものを指す言葉であると思ってください。

明文化そのものは手段でしかありません。重要なのは、開発者それぞれが日々この「何のために取り組むか」について考えているという状態です。その状態が前提としてあって、明文化され、共有認識となることで、フルリモートな環境においても我々らしい開発ができる。そういった考え方をしていました。

2023: ミッション・ビジョン・バリュー刷新

時は進んで2023年、ピクシブはミッション・ビジョン・バリューを刷新しました。同年9月に開催されたPIXIV MEETUP 2023にて新しいMVVがお披露目されています。

www.pixiv.co.jp

2020年の話をする際に触れた「会社規模の増大」も、MVV刷新の背景の一つとしてありました。その後、社員数の増加スピードはさらに加速していきます。組織だけでなくプロダクトの規模についても同様に拡大が進む中で、立ち上げられたのが「MVV刷新検討プロジェクト」でした。

このプロジェクトは、経営陣もメンバーに含まれる部署横断のタスクフォースを主体として進められていきました。その中で私は、刷新検討プロセスを設計し、リードする役割を担っていました。

本セッションのタイトルは「ビジョンの作り方」ではなく「扱い方」であるため詳細は省きますが、ミッション・ビジョン・バリューそれぞれの検討プロセスについて、さまざまな工夫を凝らしています。中でもビジョンの刷新検討プロセスは、まさしく会社を主語とした「何のために取り組むか」を探求するようなプロセスだったと思います。

結果的に、出来上がったビジョンがこちらです。

特徴的なのは、”something”、「何か」という言葉を使っている部分にあると私は思っています。

さまざまなプロダクト・サービスを手がけるピクシブが、それらに「何のために取り組むのか」。そのアンサーとなるのがこのビジョンです。にもかかわらず、このビジョンにおいては”something next”「次の何か」と、それが何であるかをあえて明言していません。

検討するプロセスの中でも議論が白熱したポイントですが、結果として読み手、すなわちピクシブのメンバーそれぞれの解釈に委ねるという、難易度の高い選択を下した形です。

「創作活動を、もっと楽しくする。」というミッションに比べて抽象度が高く、考えられる幅が広いことが、そういった背景を知らずとも伝わるのではないでしょうか。

度々用いているこの「何のために取り組むか」というキーワードですが、その対象には様々なワードが入ります。

さきほど紹介したのは、ピクシブ株式会社の「会社としてのビジョン」になります。これは「何のために”会社としての活動”に取り組むか」という問いに対するアンサーであると言えます。

ピクシブとして開発し、提供しているプロダクトそれぞれについては、「何のために”プロダクトづくり”に取り組むか」という問いが立てられます。

さらに、プロジェクトシェルパの例にあるように、「何のために”プロジェクト”に取り組むか」という問いもまた立てることが可能です。

これら3つを並べた上で。本来会社としてのビジョンは、プロダクトづくりやプロジェクトに対し、方向性を明確に定めるものであるべきなのかもしれません。しかし、一番上段の会社としての問いは、先ほど述べた通り、我々ピクシブメンバーに明確な答えを与えてくれません。

「何のために取り組むか」という問いに自ら向き合うところにこそ「ピクシブらしい開発」の核があると、プロジェクトシェルパは考えていました。

もちろん、そういった考えから新しいコーポレートビジョンに解釈の幅が広く与えられたわけではありません。私はあくまでプロセス設計のところを受け持っただけです。あくまで「結果的にそうなった」というだけではありますが、このように並べると、我々らしいビジョンになったのではないかと私は思っています。

PIXIV MEETUPへ

前の項目でも触れた通り、新MVVお披露目の場も兼ねて2023年に開催されたイベントが「PIXIV MEETUP 2023」です。また、2024年に開催され、本セッションを披露する場にもなったのが「PIXIV DEV MEETUP 2024」です。

inside.pixiv.blog inside.pixiv.blog

招待制で開催されたこれらのイベントも、これまでの話と決して無関係ではありません。

たくさんのピクシブメンバーが登壇したり、ゲストの方をお招きして直接もてなしたりといった趣旨のイベントでしたが、その際「我々がどのようなことに取り組んでいるのか」だけでなく「その裏にどのような想いがあるのか」というところをセットで伝えるという部分を、私を含む我々イベント運営チームでは重要視していました。

その場で伝えられる想いもまた、それぞれにとっての「何のために取り組むか」に対応するものとして解釈できるのではないでしょうか。それら個々の想いを「ビジョン」という名前で呼び表すことはピクシブにおいても稀だったりはしますが、そういったカルチャーがあることを社外の方に広く伝える手段として、イベントはこの上ないものであると感じます。参加者の皆さまに、そこを含めお楽しみいただけていたなら幸いです。

今後も様々な方法で、「ビジョン」の取り扱われ方を追求していきたいと思います。ここまでお読みいただきありがとうございました。

創作の楽しさを加速させる pixivcobanプロダクトマネージャーの仕事

2024-12-26T13:00:00+09:00

こんにちは。広報部のmikoです。ピクシブには、全社的なお金に関する課題の解決に取り組むファイナンシャルサービス本部という部署があります。

今回はファイナンシャルサービス本部ビジネス開発部のpixivcobanチームに所属し、PdM （プロダクトマネージャー）として活躍するpasoさんに、仕事の内容やチームの雰囲気についてお話を伺いました。

自己紹介をお願いします

2019年に新卒で入社しました。入社後はpixivの有料サービス「pixivプレミアム」のグロース業務やプリペイド式電子マネー「pixivcoban」の開発などに携わり、現在は「pixivcoban」のPdM兼PMM（プロダクトマーケティングマネージャー）を担っています。

私が所属するファイナンシャルサービス本部ビジネス開発部は、お金に関する課題を解決することで、企業ミッション「創作活動を、もっと楽しくする。」を叶えることを目指しています。具体的な仕事としては、決済の運用・保守、決済の利便性向上、不正決済対策、キャンペーン等によりユーザーへ還元を行うマーケティング領域などがあります。

現在pixivのアカウント数は累計1億アカウントを超え、それを支える決済のトランザクション数もかなり膨大になっています。これらを安定的に処理し、クリエイターやファンが安心してスムーズにお金のやり取りを行えるような仕組み作りに部署として取り組んでいます。今年の4月にはプリペイド式電子マネー「pixivcoban」をローンチしました。

pixivcoban特設サイト coban.pixiv.net

具体的な業務内容について教えてください

PdMとしての仕事内容は、プロダクトコアの定義、目標やロードマップの策定、要件定義、業務フロー作成、UI/UX改善、関係各所との折衝などがあります。決済という領域でいかにユーザーに価値を届けられるかを日々チームで模索しています。

PMMとしての仕事内容は、ユーザーのアクティビティや決済関連データの分析、キャンペーンの企画や実施に向けたディレクション、効果測定などがあります。BOOTHやpixivFANBOXをはじめ、ピクシブの様々なプロダクトのチームとともにキャンペーンを行っています。キャンペーンを通じて得たユーザーインサイトは、pixivcobanの機能開発・改修計画にも反映させています。

印象的だった業務や、今後チャレンジしていきたいことを教えてください

立ち上げから関わったpixivcobanのリリースが一番印象に残っています。プロダクトのポジショニングやブランドコアを一から策定するにあたり、便利な電子マネーは既に数多くある中で私たちがユーザーに届けられる価値は何か？を突き詰める過程は大変ですがやりがいがあるものでした。

pixivcobanは単なる決済手段ではなくて、決済という領域でクリエイターやファンにどういった価値を届けられるのかを考えて開発しています。これまで、pixivを始めとするピクシブのサービスはクリエイターの支援を様々な形で行ってきましたが、一方でファンへのアプローチは十分ではない面がありました。pixivcobanは、サービスを利用するユーザーにコバン（無償）を還元することで、ファンがクリエイターの作品をより一層楽しみ、クリエイターの創作活動が盛り上がることを目指しています。

キャンペーンを通じた還元として、例えば2024年11月にBOOTHで「#BOOTHこれスキ」という施策を開催しました。期間中にXで推しの商品またはショップをタグ付けしてポストした人に抽選でコバンをプレゼントするもので、クリエイターとファンのコミュニケーションを加速することも意識しています。

booth.pm

今後は、さらに創作のコミュニティを盛り上げる機能を開発できたらと考えています。ピクシブが運営するサービス・プロダクトには多くのクリエイターとファンがいます。pixivcobanを通じてユーザーのアクティビティを活発にできるようなきっかけを提供し、コミュニケーションを促進することでコミュニティをより強化していけると良いなと思います。

仕事のやりがいや楽しいところは？

ピクシブは、pixiv以外にもBOOTH、pixivFANBOX、VRoid Studioなど様々な事業を数多く展開しています。だからこそ、年齢・経験を問わずチャレンジできる領域が広く、それがやりがいや楽しさに繋がっていると感じます。一気通貫でプロジェクト全体に携われるところも嬉しいです。

また、企業ミッション「創作活動を、もっと楽しくする。」に共感し創作活動やクリエイターにリスペクトを持つ人が多く集まっています。一緒に働くメンバーがみんな同じ視点や目標を持っていることで、部署横断でディスカッションしたりサポートし合いながら課題解決に取り組む文化があります。そうした企業風土も、やりがいを高めているポイントだと思います。

働き方やチームの雰囲気について教えてください

私が所属するpixivcobanチームは10名ほどの少数のチームです。中途入社の社員が多いこともあり、トップダウンで仕事を行うよりは、ボトムアップで各々が仕事を見つけて主体的に動いています。

もちろん、初めての業務は経験者が並走しますし、困ったときにはSlackやDiscordで気軽に質問できる環境があります。プロジェクトとタスクの進捗状況はNotionのデータベースでオープンに管理され、毎週開かれる定例会議で共有しており、安心して仕事を進められる環境だと思います。

働き方としては、私を含めてオフィスワークよりもリモートワーク中心の社員が多いです。一方で、チームとして定期的なワークショップや、プロジェクトの打ち上げ開催などリアルでコミュニケーションをとる場も用意されています。出社推奨日を作り、出社のタイミングが被ったメンバーで一緒にランチを楽しむこともあります。

ピクシブのここが好き！を教えてください

全社的に「自社プロダクトをより良くしていきたい」という熱量が高いところです。目標に対して、自部署だけではなく他部署にも協力的で、相互に協力して提案や相談ができていると感じます。

また、良い意味で何かの「オタク」である社員が多いです。各々が熱量の高いこだわりや趣味を持ちながらも、他の人の「好き」にもリスペクトがあり、ジャンルを超えてお互いの「好き」を共有できる空気があるのはピクシブならではだと思います。

ピクシブへの入社を検討している人にメッセージをお願いします

pixivcobanのPdMの仕事は、主体的で自走力のある方、また、客観的に物事を見れるバランス感覚がある人が向いていると思います。「ミッション実現のためにこうしたい」という理想があることは重要ですが、それを実現するためにビジネスとユーザーへの価値提供のバランスが求められる仕事です。そうしたことが得意でピクシブに興味を持っていただいた方と、ぜひ一緒に働けると嬉しいです。

PdMの業務に興味をお持ちいただいた方は、下記エントリーフォームよりご応募をお待ちしています！ hrmos.co

今年もブックサンタやったよ〜

2024-12-18T16:30:00+09:00

ほ〜、ほ〜、ほ〜。こんにちは、マーケティング部のhotepです。今年も「ブックサンタ」の季節がやってまいりました！

「ブックサンタ」とはNPO法人チャリティーサンタによる「厳しい環境にいる全国の子どもたちに本を届けること」を目的にしたチャリティーです。

2022年からpixivはNPO法人チャリティーサンタと協力し、「pixiv小説子どもチャリティー企画　ブックサンタ」という投稿企画や、RP数により寄付をするキャンペーンを行なっています。今年も絶賛開催中。

＼🎅RPで子どもたちに本を贈ろう🎁／
チャリティー企画 #ブックサンタ2024 リポストキャンペーン第2弾✨

本ポストを1RPにつき5円、チャリティーサンタへ寄付😀

寄付は大変な境遇にいる子どもたちへ本を贈る活動に充てられます📚https://t.co/PwyVcKIw6S
⏰12月25日（水）17時まで
— pixiv (@pixiv) 2024年12月16日

投稿企画はクリスマスをテーマにした小説やエッセイを執筆し、参加タグ「ブックサンタ2024」を付けてpixivに小説を投稿すれば、作品数×500円をピクシブ株式会社からNPO法人チャリティーサンタへ寄付します。

いままで累計1,417,250円の寄付を行っており、今年はさらに多くの子どもたちに本を届けたいと思っておりますので、ぜひご参加ください。

www.pixiv.net

また同時に、ピクシブの社員たちも個人的にこのブックサンタに参加しています。ブックサンタは、提携書店で本を選び、購入時に「ブックサンタでお願いします」と伝えるだけで参加できます。毎年、私は有志の社員たちと本屋に行きブックサンタで本を購入し、その後みんなで酒を飲むというのを恒例にしています。今年もやってきました。初めて話す社員もいましたが、小さい頃に読んだ本の話や、どんな本が喜ばれるかを話すことですっかり打ち解けられたと思います（だよね？）ブックサンタは参加する側も楽しいチャリティーだと思います。ぜひご興味ありましたら、公式HPを見てお友達や同僚と参加してみてください。

booksanta.charity-santa.com

最後に、今回はそんなズッ友な社員たちと寄付した本を紹介します。購入時の参考になれば幸いです。

星のカービィあぶないグルメ屋敷!?の巻

チームメンバーから「小学生の姪っ子が読んでます」と教えてもらい、小学生のリアルバイってマストバイじゃんと選びました。それに、こういうキャラクターきっかけで活字を読みはじめることもあるんじゃないかなぁと。というか、昭和生まれだしゲームをあまりやらない子どもだったのでカービィはファミコンでしか知らないのですが、カービィって人語を喋るんですね。（hotep） store.kadokawa.co.jp

これだけは知っておきたい岩石・鉱物図鑑

図鑑はブックサンタでも人気らしいし、鉱物ってやっぱきれいだし、きれいなものの写真がたくさん載ってる本はプレゼントとしての特別感があるかなと選びました。「きれ〜」って理由でこの本を手にとって、本を読む楽しさに目覚めてくれたらうれしいですね。それにもしこの本を読んだ子が将来オタクになり、小説でキャラの瞳を宝石に例えたい思ったとき、この本で得た知識はきっと役立ちます。（hotep） pie.co.jp

メアリ・ポピンズ

シンプルに大好きな物語だから選びました。子どもの頃に読んで、人の想像力ってすごい！と改めてハッとした本です。空飛ぶ傘や天井でのお茶会や踊る牛や、え、何食ったらそんなお話考えられんの！？というお話がたくさん収録されています。この本でクリエイティビティを高めて、将来pixivにマンガや小説を投稿してくれたらうれしいです。できれば私と同じジャンルだともっとうれしい。（hotep） www.asahipress.com

金曜日の砂糖ちゃん

可愛らしい少女と仄暗い夜の雰囲気が溶け合う酒井駒子先生の絵本は、子供の頃に書店で見かけて衝撃を受けました。この素敵な本がどうしても欲しい！と思ったのですが、当時のお小遣いではハードカバーの本を買うのは難しかったです。（uchien） www.kaiseisha.co.jp

たまごのはなし

友人のプレゼントで知った絵本です。精密な絵が魅力的です。主人公のたまごが途中で出会ったマシュマロに齧り付くのですが、その齧り跡がずっと取れないまま一緒に行動しているのが面白く、人と共有したくなりました。（uchien） www.bronze.co.jp

オーデュボンの祈り

小さな島で起こるカカシの殺人事件。読み進めやすいミステリーで、浮世離れした不思議な世界観を小冒険する気持ちにもなり、最後は満たされた気持ちになれる読後感が魅力的で、ぜひ贈り物にしたいと思う一冊です。（uchien）www.shinchosha.co.jp

飼育員がつくったサルの図鑑: かならず会いたくなっちゃう56のなかまたち

サルの種名、いくつ言えるでしょうか。ニホンザル、チンパンジー、ゴリラ、ヒト……。この本には56種類載っています。マニアックで素晴らしいですね。「ブラッザグエノン」がどんな姿か想像できますか？今回私が選んだ本はどれも同じものを持っているのですが、このブックサンタの選書のために書店を訪れて初めて、この本が児童書コーナーにも置かれていることを知りました。「ブックサンタオンライン書店」にも掲載されていて、そこでの分類によると小学校中学年向けということらしいです。こういう隙間の知識は何歳でも面白いものであるはずだし、次動物園へ行くときの楽しみが増えると良いな、と思って選びました。（roiban） www.kumonshuppan.com

石は元素の案内人 (たくさんのふしぎ傑作集)

福音館書店から毎月刊行されている「たくさんのふしぎ」という子供向けの絵本雑誌があり、その中の一号が単行本化されたものです。岩塩や水晶といった様々な「石」を紹介しながら、それらが元素に関してどのような示唆を与えてくれるのか、やさしい語り口で教えてくれます。（roiban） www.fukuinkan.co.jp

世界ぐるぐる怪異紀行: どうして”わからないもの”はこわいの? (14歳の世渡り術)

ヒマラヤのイエティ、中国の鬼、ロシアの呪術信仰……。世界各国の「怪異」とそれを取り巻く人々の暮らしを、9人の文化人類学者がそれぞれのフィールドワーク体験を軸に語る本です。各話20ページ程度とさらっと読める長さでありつつ、記述に留まらず文化を深くまなざす学問の深みが感じられます。「14歳の世渡り術」という中学生以上向けのシリーズから出ている一冊で、最近本屋で見つけて読み、面白かったので選びました。（roiban） www.kawade.co.jp

太陽系最後の日 (ザ・ベスト・オブ・アーサー・C・クラーク 1)

人類を救うべく、破滅が迫る地球へやってきたエイリアンたちの探検隊が見たものとは……。『太陽系最後の日』はSF作家アーサー・C・クラークの短編集です。私は今回がブックサンタ初参加で、「自分が読んで面白かった」以外に本を選ぶ基準がまだ分からず、つまりまあ趣味からこの本をここに含めました。いわゆる児童文学という感じの作品とは違いますが、平易な言葉で科学をストーリーに落とし込むのが見事で、小学生くらいで出会っても十分価値がある気がしています。（roiban） www.hayakawa-online.co.jp

めんどくさがりなきみのための文章教室

子どもの頃、小説って誰でも、自分でも書いていいんだ、と教えてくれたのがはやみねかおる先生の本でした。主人公の男の子とともに、文章の書き方を楽しく学んでくれたらいいなと思います。（yto） www.asukashinsha.co.jp

世界のかけら図鑑

旅行先の本屋で平積みされていたのが目に入って、自分用に1冊と、子どもが読んでも楽しいだろうなと思ってもう1冊をブックサンタにしました。イラストも文章も楽しい本なので、科学に興味を持ったり、より深く知りたいと思うきっかけになってくれたら嬉しいです。（yto） www.kadokawa.co.jp

深すぎてヤバい宇宙の図鑑宇宙のふしぎ、おもしろすぎて眠れない!

bookclub.kodansha.co.jp 私は昨年に続いて二回目の参加です！今回は小学生高学年くらいの方々を思い浮かながら、「本の世界の入口」というテーマで上記5冊を選定しました。

「僕らの七日間戦争」は、ジュブナイル小説の「ありふれた手法」はSFの「キノの旅」はファンタジーの「二十億光年の孤独」は自由詩の「宇宙の図鑑」は、科学を志すものとしてのそれぞれの入口として。本は広大で深淵なこの世界を知る窓であり、扉であり、乗り物だと思っています。これらの本をきっかけにみなさんがワクワクする世界に没頭してもらえると嬉しいです。（ushio）

プロダクトの未来を創る pixivcobanバックエンドエンジニアの仕事

2024-12-12T18:20:00+09:00

こんにちは、広報部のmikoです。ピクシブには、全社的なお金に関する課題の解決に取り組むファイナンシャルサービス本部という部署があります。

今回はファイナンシャルサービス本部基盤開発部のバックエンドエンジニアのお二人に、仕事の内容やチームの雰囲気についてお話を伺いました。

自己紹介をお願いします

rkun：2022年に新卒エンジニアとして入社しました。pixivcobanが部署として立ち上がった7月にちょうど本配属だったので、プロジェクトの初期段階から並走して今に至ります。現在は、開発業務以外にpixivcobanプロダクトオーナーの業務も担っています。

matsub：2024年1月にピクシブに入社し、pixivcobanチームでバックエンドエンジニアの業務とインフラまわりの開発に携わっています。最近は、プロダクトオーナーであるrkunをサポートしたり、チームのタスク整理なども行っています。

ファイナンシャルサービス本部基盤開発部について教えてください

matsub：ファイナンシャルサービス本部は、お金を扱う機能に関する内外向けサービスを担当する部署です。ファイナンシャルサービス本部には複数のチームがありますが、それらに所属するエンジニアが集まる横断組織が基盤開発部です。

大きく分けて、決済基盤とpixivcobanという2つのサービスを扱っています。決済基盤ではピクシブの各種サービスの決済を扱う内部向けのAPIを開発しており、決済に関する全社的な課題を集約し解決しています。pixivcobanは今年の4月にリリースしたプリペイド式電子マネーです。

pixivcoban特設サイト： coban.pixiv.net

具体的な業務内容について教えてください

rkun：普段はエンジニアとしてバックエンドの設計・実装や、他のメンバーのコードレビューを行っています。またプロダクトオーナーとして、pixivcobanの方向性を考えたり、課題や開発優先順位の整理などを担当しています。

matsub：私もバックエンドエンジニアの業務が主です。それに加えて、システムの監視業務や、システム上で問題が発生したときのオペレーション業務などを担っています。

過去の印象的な業務はありますか？

rkun：pixivcobanの立ち上げからリリースまで走り抜けたことが大きな経験になりました。新卒で経験も浅い中、社内のたくさんのエンジニアに助けてもらいながらやり遂げることができました。リリース直前の2024年1月に入社したmatsubさんに、残っていたタスクをお任せできたのも本当に助かりました。

matsub：リリース間近というタイミングでの入社だったので、リリース前のテスト環境や本番環境を整えるなど、インフラ系の仕事も当時は多かったです。

rkun：matsubさんにはpixivcobanリリース後の開発プロセスなども整えてもらい、まさに縁の下の力持ち的な存在でした。

matsub：長いスパンで取り組むプロセスの改善業務などに関わることも多いのですが、自分としてはまだ道半ばという感じなので、今後もしっかり取り組んでいきたいですね。

仕事のやりがいや楽しいところは？

rkun：pixivcobanリリース後も色々な機能を開発しています。直近では、社内からコンテスト参加の返礼やキャンペーンの賞品としてユーザーにコバンを付与したい、という相談があったことをきっかけに、ピクシブ側がユーザーに無償コバンを配布できる機能をリリースしました。

実際にユーザーにコバンが付与され、SNS上で喜びの声を目にできた時は嬉しかったですね。プロダクトからファンへの還元を実現し、双方を繋ぐ存在になれたと実感しました。

matsub：pixivcobanはリリースして間もないサービスなので、自分の考えを大きく反映できるシーンが多いです。チームの文化を自分たちの手で創り上げていくプロセスに楽しさを感じています。

働き方やチームの雰囲気について教えてください

rkun：リモートワークのメンバーが多いのですが、毎日オンラインでのコミュニケーションを取るようにしています。雑談も交えながら、日々のコードの課題から今後のpixivcobanの展望まで共有しあっています。

matsub：こうした時間を設けているのは、「エンジニアの自走を助けること」が狙いです。ピクシブは、高いスキルを持つエンジニアが多く、チームや個人に任されている裁量が大きいことが特徴です。一方で、エンジニアが自身で考えて自由に進めるためには、その判断軸となる情報が必要です。

各自に振られるタスクに関しても「なぜこれが必要なのか」「なぜこの優先度なのか」を必ず説明し、納得したうえで対処してもらうようにしています。そうした時間を含めて、毎日しっかりとコミュニケーションを取る時間を作っているんです。自走を求められる会社だからこそ、自走しやすい土壌を作ることを意識しています。

毎週チームのふりかえり会をFigjamを使って実施

チャレンジしていきたいことや目標など今後の展望を教えてください

rkun：pixivcobanは、これからまだまだ大きくなるプロダクトだと思っています。ピクシブのミッション「創作活動を、もっと楽しくする。」をより促進するために、何ができるかを今まさにメンバー一丸となって模索しているところです。

matsub：pixivcobanは夢がある、という話をメンバーでよくしており、実際にメンバーで集まると、驚くような新しいアイデアが出ることもあります。

決済に関するプロダクトというと、「固い」イメージがあると思います。もちろんユーザーの資産を預かっている責任はしっかり守りつつ、一方で攻められるところは攻めていきたいと考えています。新しいことにチャレンジできるチームを目指したいです。

rkun：私達はピクシブの全サービスと関われるポジションにいるので、色々な相乗効果を生んでいくことができるといいなと思います。

ピクシブのここが好き！を教えてください

rkun：ピクシブには、P-HUBという社内交流機会があり、私自身もよく参加しています。そこでさまざまな部署のメンバーと話すなかで、pixivcobanに対してアイデアや要望をもらうことも多くて仕事のヒントにも繋がっています。もちろん、社内のメンバーとの交流自体も楽しいですし、その中でサービスについての会話をすることもできて、メンバーがみんなプロダクトのことをいつも考えてるんだなと感じられるのが楽しいです。

matsub：私はピクシブのBigQueryが面白くて好きです。全社的に使われており、さまざまな情報をBigQueryで叩けるので、データ分析が好きな人はすごく楽しいと思います。

rkun：BigQueryの活用に関しては、エンジニア以外のメンバーも自分でSQLを書いて分析したりデータを共有しあったりしています。職種関係なくナチュラルにBigQueryを使えているのはすごいですよね。

matsub：他のプロダクトとpixivcobanのクロス分析もBigQuery上で簡単にできますし、私達pixivcobanチームも、マーケティング分析にかなり活用しています。

ピクシブへの入社を検討している人にメッセージをお願いします

matsub：楽しいからぜひ来てください！というのがストレートなメッセージです（笑）

pixivcobanは、ファンがクリエイターの作品をより一層楽しみ、クリエイターの創作活動が盛り上がることを目指しています。そこにお金の動きを使ってリーチすることは難しいですが面白く、きっとやりがいを感じられると思います。

rkun：個人の裁量が大きく、自分が考えたことがダイレクトに反映される会社です。また、pixivcobanはリリースしたばかりのプロダクトです！自ら考えてプロダクトの未来を創り出していく、そんな環境が面白そうだなと思った方はぜひ一緒に働けると嬉しいです。

matsub：ピクシブのバリューの一つに「遊び心で楽しませよう。」というものがあり、それがとても気に入っています。遊び心を持って提案しチャレンジすることや、他の人が出した遊び心を受け入れて一緒に楽しむことが好きな人は、ぜひお待ちしています。

バックエンドエンジニアの業務に興味をお持ちいただいた方は、下記エントリーフォームよりご応募をお待ちしています！ hrmos.co

「PIXIV DEV MEETUP 2024」登壇者を支える仕組みの紹介

2024-12-10T18:30:00+09:00

はじめに

こんにちは！PIXIV DEV MEETUP 2024 運営チーム/ステージチーム全体進行のrenmaです。

ピクシブでは完全招待制カンファレンス PIXIV DEV MEETUP 2024を9月20日に開催しました。MEETUPにおける発信の中核を担うのが、ピクシブメンバー自らが登壇するセッションです。合計42名の登壇者が、日々行なっているプロダクト作りの裏にある想いや技術を発信しました。

conference.pixiv.co.jp

本記事ではMEETUPのセッションの制作過程だけでなく、より良いセッションを作るための仕組みや、登壇経験の少ない登壇者を支える工夫をお伝えします。それぞれのセクションは、その分野に最も詳しいメンバーが執筆しており、詳細かつリアルな内容に仕上がっています。ぜひお楽しみください！

メインセッション&LT編

登壇者の募り方　by renma

PIXIV DEV MEETUP 2024の運営コアメンバーが決定した後に、全社員に対してMEETUPの社内参加者募集を行いました。MEETUPへの参加意欲のある社員には、以下4つの参加方法から複数の「やってみたいこと」を選んでいただきました。

メインセッション登壇：15分 ~ 30分のセッション
LT登壇：5分程度の勢い重視のセッション
企画制作：ブース出展、ノベルティ制作、その他やりたいことがあれば応相談
その他何かしら関わりたい：受付、ノベルティ配布、懇親会準備

登壇者募集ではなく、参加者募集と広く募集を行うことで「登壇もやって、ブース出展もして、受付もして…」と稼働オーバーになる人を減らしたり、よりスキルを発揮しやすい関わり方をしてもらえるようにしました。また、セッション内容を任意回答していただくことで、この後に続くタイムテーブル設計をやり易くしました。

タイムテーブル設計　by sourmilk

登壇者を募ったら、タイムテーブルに落とし込んでいきます。

PIXIV DEV MEETUP 2024では、昨年と同様に「キーノート」「メインセッション」「ライトニングトーク（LT）」の3つの登壇方法がありました。

キーノート
- イベントの目玉となるセッション。1時間にわたり、各プロダクトや部門を代表するメンバーが入れ代わり立ち代わり登壇する。直近1年におけるピクシブの活動のハイライトを凝縮して伝える。
メインセッション
- 15-20分のセッション。
ライトニングトーク(LT)
- 5分のセッション。今回のイベントでは、単に5分のショートセッション形式の発表から、いわゆる狭義のライトニングトーク、すなわち速いテンポと勢いで魅せる発表までが含まれる。

タイムテーブル作成にあたっては、特にキーノートとメインセッションにおいて「会社として伝えたいことは何か」を意識する必要があります。そこに強い意思を持っているCTOのharukasan, VP of Product のnorioを交えながら、ファシリテーターの私を含めて議論を進めました。

基本的には「キーノートとメインセッションを誰に話してもらうか」を軸に考えていきます。特にキーノートに関しては会社として伝えたいコンテンツを軸に登壇していただきたい方を決めるため、登壇希望を提出していない方に登壇をお願いする場合もあります。また単純にキーノート＞メインセッションという序列があるわけではなく、例えば今年リリースされたPastelaとpixivcobanという2つのプロダクトに関しては時間をかけてより深くお伝えすることが重要と考え、時間的制約が厳しめのキーノートではなくメインセッションに配置しています。

大まかな流れとしては、まずイベントコンセプトや直近の会社としてのリリース等からキーノートで伝えたいことをまとめて布陣を決め、次にメインセッション希望者の一覧を見て全体的な多様性（特にフロントエンド、バックエンド、インフラ、デザイン、PdMといった職域）を確保しながら登壇者を決定していきます。最後にメインセッション同士やメインセッションとLT群で視聴者層が出来るだけ同一時間帯に被らないように調整しました。

作業にはFigjamを使い、応募内容を付箋にして書き出し、付箋を動かしながら配置を考えました。また応募時点で登壇内容の詳細が書かれていなかったり、漠然としている方もいらっしゃったため、適宜ご本人にSlackのDMで確認を入れながら進めていきました（この点は来年改善出来るポイントと考えていますが、普段登壇機会のない方にも気軽にご応募いただきたい気持ちもあり、バランスが難しい点です）。

多忙なメンバーを集めてミーティングを行う必要があるため、カレンダーを抑えるのが難しく、また多面的な観点から議論を行う必要があるため、最終的に3週間半かけて30-60分枠のミーティングを計8回行いました。

基本的には登壇希望者は全員登壇いただけるように調整しています。ただ昨年は登壇者が総勢32名だったのに対し、今年は42名と大幅に増えているため、昨年より開会時間を30分早めて登壇枠を増枠する判断を行いました。これは昨年実績で、当日朝のリハーサル時間には余裕があったため、今年も同会場で開催するにあたり開会を早めることは可能と考えたものです。

来年以降同様のイベントを開催し、更に登壇希望者が増加した場合、同様のスキームで運用すると開催時間が長くなりすぎる可能性が懸念されます。今回2トラックだったのを3トラックにする、もしくは選考フローを設けるなどが考えられますが、選考フローは公平性の担保や審査のために必要な手間が増加することや、プロポーザルを書くのが上手い人に登壇してもらいたいとは限らないこと（むしろ普段面白い仕事をしているが登壇など考えたこともなかった、というような方にも発表の場を設けたいという思いがあります）などから、導入検討は慎重に行う必要があると考えています。

登壇内容の質を上げるための取り組み　by sourmilk

リハーサルを見守る登壇サポートの様子

リハーサル中の登壇者

昨年のPIXIV MEETUP 2023の反省として、特に登壇経験の少ない方へのケアが不足しており、目立ったヘルプ体制もないままリハーサルを迎えた結果、本番直前に発表内容の構成レベルでの見直しが必要になるといったケースが発生してしまった点があります。またリハーサル時は傍聴者なら誰でも気になった点を書き込めるGoogleスプレッドシートを用意していたのですが、ある程度責任を持って網羅的に内容を監修する担当者は明確に定めていませんでした。

そこで今回は、初めての登壇であっても安心して、かつ一定のクオリティで発表出来るよう、登壇サポートという役割を新設しました。数多くのテックカンファレンスへの参加経験を持つメンバーを含む3名で構成され、LPやパンフレットに掲載される発表タイトルや概要文の改善提案、発表リハーサルのレビュー、必要に応じて発表構成の壁打ちやリハーサル後のさらなる改善提案ミーティング等を実施しました。特にメインセッションは会社を代表する発表としての性格がより強いため、全セッションについてリハーサル後にCTOのharukasanと登壇サポートを交えた30分のレビュー会を行い目を通しています。

リハーサルは2回行うため、これだけでも10時間におよび、決して運用コストは低くありません。しかしイベントの核となる登壇のクオリティを確実に底上げすることができ、かつ直前に慌てるような事態も最小限に抑えられました。昨年と比べても登壇品質は総じて高まっていると感じており、今後企業カンファレンスを開催する上でも欠かせない役割だと手応えを得られる結果となりました。

キーノート編　by saki

キーノートは複数の登壇者で構成されますが、ひとつのセッションです。各登壇者の色を出しつつもキーノートとしての統一性も必要になります。そのために、キーノート統括のharukasanの方向づけと中央集権的な資料作成を重視しました。これを成り立たせてキーノートを完成させる役割としてキーノート旗振り役がいます。

作成にあたっては最初に、キーノート統括と各登壇者の間で打ち合わせをしてピクシブとして打ち出したいものを固めます。その後、2回の打ち合わせをマイルストーンにしてスライドの概形を作ります。この時点で、各登壇者の発表内容がほぼ確定します。

そこから先、各登壇者は練習や修正を行い、キーノート旗振り役は本番用の資料完成に注力します。各登壇者の作成スライドをベースに本番用の資料を新たに作りました。挿入する画像と動画は全部で60件近くあり、構造図などの図表はクリエイティブを扱うクリエイティブチームと相談します。すべてにIDを振ってテーブル管理をし、画像個別にやり取りを行えるようにしました。やり取りの中では素材ファイルの受け渡しの他、図表の意図の相談や言語化などをしていました。最後にキーノート統括と演出の力を借りた全体的なスタイリングやアニメーション設定を経て完成しました。

また、キーノートの冒頭ではChatRoidを用いてnorioとの掛け合いを行いました。これは資料作成と並行し、演出とChatRoid担当のエンジニア陣の協力をもらって演出プランや台本を固めました。

全員集まってのリハーサルは本番までに3回行いました。こちらも各登壇者の負担が大きいものでしたが、実際に見ることで修正点に気づくことができ、回を経るごとにクオリティの増加を実感できました。

キーノートは各登壇者が一番緊張します。各登壇者が集中できるように負荷を下げつつもひとつのキーノートとして完成できるような役割があると、ゲストによいメッセージを届けられると考えています。

おわりに　by renma

改めてMEETUPのセッションの準備過程を振り返ってみると、登壇者や運営メンバーの多くの創意工夫/努力がMEETUPを形作っていたことを感じます。日々の業務の傍ら発表の準備を進めてくださった登壇者・運営メンバーの皆さん、本当にお疲れ様でした。

さまざまな工夫を行ったPIXIV DEV MEETUP 2024でしたが、まだまだ改善できるポイントはあると感じています。登壇者と運営メンバーの負担をさらに軽減しながら、より質の高いセッション/カンファレンスを実現できるような新しい仕組み作りを進めていきたいと考えています。

また、MEETUPで行われた発表のまとめ記事を、pixiv insideで順次公開されていく予定です。MEETUPに来られなかった方や、見逃してしまったセッションがある方も、ぜひpixiv insideの記事をご覧ください。

最後までお読みいただきありがとうございました！

HR SUCCESS アワード2024を受賞！採用システム導入の取り組みについて担当者にインタビュー

2024-12-10T12:00:00+09:00

2024年7月、ピクシブは、株式会社ビズリーチが主催する「HR SUCCESS アワード 2024」にて、採用・人事を変革し先進的な取り組みを行った企業として受賞しました。

受賞につながったのは、2023年に導入した新しい採用管理システムに関わる取り組みです。採用課題の解決や改善をどのように進め、仕組みを整備していったのか、中途採用チームの4名にお話しを伺います。

メンバー紹介

minami：2020年入社。中途採用を主に担当。
chihiro：2021年入社。中途採用とオンボーディング、研修業務を担当。
coco：2023年入社。中途採用とオンボーディングを担当。
camiii：2023年入社。中途採用と研修をメインに担当。

新システム導入の背景について教えてください

chihiro：ピクシブは社員の約7割が採用の選考プロセスに参加しているのが特徴です。そのため、各社員に合わせた閲覧権限で情報を共有する必要があるのですが、以前利用していた採用管理システムは、閲覧権限を細かく設定できませんでした。

結果、選考に関する社内のやり取りが採用システム上ではなく、SlackやSlack内のDMなど様々な場所で行われており、選考プロセスに関する情報が集約できていない状態でした。

情報を一元管理できていないという課題を解決するために、2023年5月頃、新システム導入の検討を始めました。どのようなシステムがあるかを調べ、集まった候補を比較検討しました。7月に株式会社ビズリーチが提供するHRMOS（ハーモス）の導入を決定し、そこから1ヵ月で運用方法を検討し、2023年8月から導入を開始しました。

coco：HRMOSを導入したことで、閲覧権限の問題が解決し、選考に関わるやり取りが全て1つのシステム上に集約されました。更に、全てのデータを一元管理したことでデータ分析が容易になったため、PDCAを回して業務効率の改善に取り組んでいくことができるようになりました。

システム導入にあたり苦労した点はありましたか？

chihiro：HRMOS導入により、以前のシステムでは解決できなかった多くのことができるようになりました。使える機能が多い分、それぞれの細かな設定が大変でしたが、そのなかでも権限まわりの設定に苦労しましたね。

coco：HRMOSの担当者によると、選考担当者がここまで採用に携わる会社は珍しく、ピクシブほど細かい設定を必要とする事例がなかったそうです。そのため、ピクシブに合わせて一から設定を構築していく必要がありました。

一方で、複雑にしすぎてしまうと、選考プロセスに参加する社員が評価を記入する際などに混乱や不明瞭な点が生じる可能性があります。。選考担当者が楽に入力でき、かつデータをきちんと抽出できる状態を目指して作業を進めました。

chihiro：テスト画面を見ながら何度も試しましたね。相当な組み合わせのパターンで試行錯誤する日々でした。そのほか、データの落とし込みにも苦労しました。前年との比較もできるように、過去のデータをHRMOSに移行する作業を行ったのですが、当然ながら膨大なデータ量で…。

camiii：移行したデータは全部で約23,000件でした。そのうち、選考のステップなど詳細まで残しておきたいデータが1,500件ほどありました。これらに関してはCSVで移行するだけでは完結できず、手入力でデータ移行を行いました。

1,500件の手入力は大変でしたが、今後データ分析にウェートを置きたいという想いが強かったので、ここは手間をかけてもしっかりやり遂げたい部分でした。

特に注力したことはありますか？

minami：新システムを社内に浸透させるための案内です。以前はSlack上で行っていたやり取りを、全てHRMOS上の社内メモで行う形に変更しました。HRMOS導入直後は、システムからの通知に気付いてもらえず、やり取りが滞ることもありました。もちろん、新システムがすぐ浸透するのは難しいことだと思っていたので、漏れがあった場合は一人ひとりへの案内を徹底して行っていきました。

導入から1年以上を経た今は、社員も大分慣れて、採用に関係するやり取りはほぼ全てHRMOS上でできています。

chihiro：HRMOS導入にあたり、社員を役職別の3グループに分けて説明会も実施しました。導入の目的を伝えたうえで機能や活用方法の説明を行い、実際の運用をお願いする内容です。丁寧に説明を行うことで、社員全員がHRMOSを理解しスムーズに使える状態を作ることができました。

coco：他にこだわった点としては、面接の評価項目アレンジもありますね。入力がしやすくかつデータも取りやすくする、ということをかなり意識して設定しました。

chihiro：採用に関わるメンバーにも意見をもらいました。例えば、評価の記入はプルダウン、選択式、記述式どれがいいのか、など細かい設定について相談し、整えていきました。

coco：新卒採用もHRMOSを使っているので、新卒採用チームやバックオフィスのメンバーとも密に連携を取りましたね。新卒採用はインターンシップがあるなど、中途採用とは選考フローが大きく異なります。HRMOS上の評価項目アレンジを全く同一にすることは難しいですが、少しでも混乱しない形を試行錯誤し整えていきました。

新システム導入から1年が経ちますが、いかがですか？

chihiro：最終的に2つの候補でとても悩んだのですが、今となってはHRMOSにして本当に良かったと実感しています。アップデートも多く、担当の方もとても丁寧で、些細な相談にも親身にのっていただいています。

minami：社員の採用における当事者意識が強く、システムを使うなかで積極的に意見を出してくれるのですが、それをHRMOS担当者の方にすぐ相談できる体制ができており本当にありがたいです。

他のサービスと連携しやすい点にも満足しています。大手求人媒体との連携がしやすく、自動で情報を取り込めるため、非常に助かっています。

camiii：Googleカレンダーとも連携してるので、面接を設定するときにHRMOS上だけで完結できるのも大きなメリットですね。

coco：選考担当者の社員から「使いやすい」と言ってもらえることが多いのも嬉しいです！また、振り返り時のデータエクスポートも以前と比べて格段に早くて感動しました。導入を進める中で大変なことも多かったですが、結果的に多方面で良い影響が出ていると思います。

「HR SUCCESS アワード 2024」受賞

これらの取り組みを経て「HR SUCCESS アワード 2024」を受賞。7月10日に東京国際フォーラムで開催されたイベント「HR SUCCESS SUMMIT 2024」内で授賞式が行われました。

ピクシブは採用オペレーション業務において「システムの導入により選考プロセスをデータ化しPDCAを回すことで中長期的に改善した点」「採用課題解決のため社内全員を巻き込み仕組みを整備した点」が評価され表彰を受けました。

表彰式に参加して、いかがでしたか？

chihiro：当日は、チームメンバー8名で出席しました。誰もが知る有名な会社が表彰企業として名を連ねる中に「ピクシブ」という文字が並んでいる様子を見て感慨深かったです。

coco：当日は表彰式に加えて、受賞企業が取り組み内容を語る公開座談会に登壇させていただきました。他にも様々なセッションが開催されており、メンバーみんなで回って様々な人事課題について学んだり、他社の人事の方と交流しました。

他社の方と話していて一番聞かれたのが「ピクシブはなぜこんなに多くの社員が採用に積極的に関わってくれているのか？」という質問でしたね。そこを課題に感じている会社が非常に多い印象でした。

chihiro：以前からピクシブには、社員全員で採用に関わるという文化がありました。ピクシブは来年で創立20周年を迎えますが、その歴史の中で、そうした風土が作られ根付いてきたことが採用担当として本当にありがたいです。改めて社員の皆さんに感謝を伝えたいです。

受賞したことについて、社内からの反応はありましたか？

chihiro：採用に関わってくれている選考担当者や採用チームの方々から、すごい！と声をかけてもらえて嬉しかったです。代表取締役からも「表彰式頑張ってね」と激励の言葉を直々にもらいました。

coco：社内にとどまらず、人事領域で繋がりがある他社の方からも連絡をいただきました。管理部門で外部から表彰される機会は少ないですし、感激しました。

今取り組んでいることや今後取り組みたいことについて教えてください

camiii：HRMOSで得たデータを活用していくため、現在、サーベイのチームを立ち上げて分析を進めています。採用方針にあわせて「このポジションはどこが課題か」「どんな方に来ていただきたいか」「どういう媒体に仕掛けていくと効果的か」などを分析していく予定です。

また、分析を深めることで、ポジションによる評価指針のばらつきを防ぐ仕組みづくりや、ポジションごとの採用施策などにも取り組んでいきたいと考えています。HRMOSを活かして色々なことに挑戦していきたいです。

最後に

chihiro：先ほどお話したように、ピクシブは採用に積極的な社員が多く、協力してもらえることが本当にありがたいと感じています。採用に関わらず、当事者意識が強い人が多く、会社全体で何かに取り組もうという空気があります。

今回の新システム導入の成功や受賞も、この土壌があってこそだと思うので、この記事を読んだ方にそんなピクシブの文化に魅力を感じてもらえたら嬉しいなと思います！

次世代のクリエイターが熱中できる機会を提供したい pixiv高校生イラコン担当者インタビュー

2024-12-09T17:00:00+09:00

こんにちは、広報部のwestenoriです。ピクシブでは毎年、「pixiv高校生イラコン」を主催しています。今回はその運営を行っているisamushiさんにコンテストへの想いや経緯についてお話を伺いました！

pixiv高校生イラコン2024：https://www.pixiv.net/contest/highschool2024

自己紹介をお願いします

芸術大学在学中にマンガを学んでいました。卒業後は広告系の仕事を7年ほど勤めた後ピクシブに入社し、現在はエデュケーション部で教育に関わる様々な企画を担当しています。pixiv高校生イラコンには2021年頃から関わっています。

pixiv高校生イラコンとはどのようなコンテストですか？

次世代のクリエイターが可能性を掴む場の創設を目的として2018年にスタートした、高校生向けのイラストコンテストです。毎回、漢字一文字のユニークなテーマ（2024年のテーマは「熱（ねつ）／Heat」）を設けていて、プロのクリエイターによる厳正な審査を経てグランプリを決定しています。全審査員が全作品に目を通すという点が特徴です。

テーマは企画のコアになる部分なので、毎回こだわって考えています。最近は海外からの応募も増えていることもあり、海外の方にも伝わりやすいという点も意識してテーマを設定しています。

pixiv高校生イラコン立ち上げの経緯を教えてください

「次世代のクリエイターが可能性を掴める場の創設」という目的を掲げていますが、立ち上げ当初はpixivに新しい風を吹かせたいという想いも大きかったと聞いています。pixivがサービス開始して今年で18年目を迎えます。プロダクトとして進化を止めないために、若い世代にpixivを認知し、投稿してほしいと考えたことも企画立ち上げのきっかけでした。 2021年に私が担当してから、授賞式の発信や講評などの機会を増やすなど、より応募者に寄り添った内容を盛り込むようにしました。

コンテストはどのように変化してきましたか？

当初から応募作品のレベルは高かったのですが、回を重ねるごとにプロと遜色ないレベルの作品が増えてきたと感じます。例えば、2021年に最優秀賞を受賞した庄一さんは高校卒業後、アニメ制作会社MAPPA所属のアニメーターになっていますし、2020年の最優秀賞受賞者である石田さんは受賞後に玄光社から画集を出されています。また、今回のクリエイター審査員のこむぎこ2000さんは実はpixiv高校生イラコンに作品を応募されているなど、過去の受賞者がプロの世界でどんどん活躍しています。

コンテスト全体のレベルが上がってきたことを受け、2023年にコンテストのロゴマークを一新しました。それまでは高校生のフレッシュさを意識したポップなデザインでしたが、コンテストのもつプロフェッショナル性を表したいと考え、よりハイレベルな印象を与えるデザインに変更しました。

【旧ロゴ】　

【新ロゴ】

pixiv高校生イラコンが浸透してきている実感はありますか？

授賞式後に、最優秀賞を受賞した方のXフォロワー数が一夜で約4,000人増えたという話を聞いて、かなり影響力があるコンテストに育っていることを実感しました。投稿作品の絵柄の幅も広がってきました。企画サイドでも審査員の先生を多彩な活動ジャンルからお迎えするようにしているのですが、そういった狙いも功を奏しているかと思います。また、審査員をお願いした先生方が、以前からpixiv高校生イラコンの存在を認識しており、「あのコンテストからオファーが来た！」」と感じてくださっているようで、審査員としてのご参加を喜んでいただけていることが大変嬉しく思っています。

コンテスト運営の面白さはどのようなところですか？

コンテストを通して、若いクリエイターの人生のターニングポイントに関わっていると実感できるところが一番のやりがいだと感じています。また、コンテストにおける評価は技術だけが全てではない点も面白いと思っています。例えば、単純な技術力だけを見た時に大きな評価を得にくい作品でも、何か他とは違う光るものを審査員に見出されて受賞へとつながることもあります。運営としてさまざまな投稿作品を見ることができるのも、とても楽しいです。高校3年間、毎年応募してくれた方もいて、リアルな成長を目の当たりにするときもあります。何かに熱中し、成長につながる機会を提供できていることも、この企画に携わっていてよかったと感じる部分です。

運営するうえでとくに大変と感じる瞬間はありますか？

結果発表に向けて進行しているときですね。締め切り後はすぐに審査に入り、結果発表および授賞式開催に向けて準備を進めます。結果発表の時期は、受験を控える高校生の事情に配慮して決めています。11月頃になると多くの高校生が受験モードに入り創作活動を休止する方もいるため、10月頃までに結果を届けられるよう進行しています。しかし、急ぎすぎて審査が煩雑になっては本末転倒ですし、かといって丁寧すぎる進行で発表や授賞式の開催が遅くなってもいけません。スピードとクオリティの両方を成立させる調整力が求められます。そのバランス感覚が難しさでもあり楽しさでもあります。

あと、コンテスト開催期間中は高校生の描いたイラストにSNS上でリアクションできないことですかね。とても素敵なイラストに素直にリアクションできないのは我慢が必要です。

関係者から届いた嬉しい反応はありますか？

応募者から頂く、プロのクリエイターとしてのお仕事に繋がったという声が一番嬉しいです。受賞者はもちろんですが、受賞に届かなかった方からも投稿をきっかけに企業から声がけがあったという声も聞きます。また、協力企業の方からは、イラストを描く高校生が一堂に会するこのコンテストで若いクリエイター支援の場に関われることがありがたい、という声を多くいただきます。

今後の高校生イラコンの展望はありますか？

今年からネクストクリエイター賞を新設しました。この賞は企業から受賞者への正式な案件発注を前提としたWチャンス枠で、2024年はYouTube甲子園様とアンコロール株式会社の企画協力により、受賞者に第8回全国高校生動画コンテスト「YouTube甲子園」のビジュアル制作などの発注が予定されています。企業と連携することで、高校生クリエイターがより活躍できる機会を増やしていきたいと思います。

例えば、音楽と絡めて文化祭のようなイベントにしていくというのも面白いですよね。高校生バンドとコラボレーションしてテーマソングをつけてみたり、CDや音楽配信を行うときのジャケットをコンテストの入賞者が描いたり、チャレンジしてみたいアイデアはたくさんあります。音楽を作りながらイラストを描く高校生も珍しくないと思うので、イラストを軸に企画を広げていけたらと思います。

pixiv高校生イラコン2024の授賞結果は10月26日に公開されました。こちらからご覧ください！

pixiv高校生イラコン2024
https://www.pixiv.net/contest/highschool2024

pixivision
最優秀賞は過去イチの激戦⁉ pixiv高校生イラコン2024結果発表＆作品講評
https://www.pixivision.net/ja/a/10250

pixiv高校生イラコン2024 授賞式
https://www.youtube.com/watch?v=REpYo9deNRk

アルバイトメンバーにインタビュー！クリエイター支援の楽しさを語る

2024-12-05T12:30:00+09:00

皆さまこんにちは。クリエイターリレーション室のaikoと申します。

私たちのチームには現在アルバイトメンバーが2名勤務しています。

本日はアルバイトporiechiruさん、inubouzakiさんへ、普段どのような業務を行っているのか、やりがいや楽しいと感じるポイントについてインタビューを行い、皆さまにご紹介したいと思います。

クリエイターリレーション室のミッションや業務詳細はこちらの記事をご覧ください。 inside.pixiv.blog

自己紹介をお願いします

poriechiru：私は現在大学院に通っていて、2024年5月からアルバイトとして働いています。もともとクリエイターとしてpixivにイラストを投稿していたのですが、イラストをもとにビジネス展開をすることに興味を持ったため応募させていただきました。

inubouzaki：私は現在大学4年生で、関西からフルリモートで働いています。友人が先にピクシブのインターンに応募していたのですが、友人の話を聞いて素敵な会社だなと感じ、自分もインターンに応募させていただきました。

いまは内定者アルバイトとして働いており、2025年4月から正社員として勤務予定です。

アルバイト業務の内容

poriechiru：私は週4日ほど勤務しています。SNSなどをみてイラストレーターさんの情報を収集するような地道な作業から、プロジェクトの一員として企画を担当するなど、幅広い業務を行っています。グッズの製造販売やリアルイベントも多い部署なので、発送業務などもあります。

案件担当者のサポート業務の割合が多いですが、自身で企画を考えて進行することもできるので、自由度は高いと思います。

inubouzaki：私はフルリモート勤務なのでデスクワークがメインです。週2、3日ほどの勤務で、イラストレーターさんとの案件進行のやりとり、事務処理、チームメンバーのサポートなどをメインで行っています。イベント時は出張して関東で勤務することもあります。

アルバイトだからこの業務はできないというような制限があまりなく、様々なことをまかせてもらえる環境だと思います。案件のメイン担当をまかせてもらうこともあり、早くから実践的な業務を覚えるのには良いかもしれません。

必要に応じて二人でリモートミーティングを行い、相談してタスクを割り振って業務を進めています。

やりがいや楽しさについて

poriechiru：成長できるところがやりがいだと感じます。企画を成功に導くための過程をメンバーとして体験できるので、プロジェクトに関わっていくごとに成長しているという実感があります。

また、大好きなイラストレーターの皆さまとともにビジネスを進めていること、お手伝いできていることが嬉しいです。

あとは部署の皆さんとカジュアルに意見交換ができたり、積極的に意見を求めてもらえることも多く、自分も1メンバーとして貢献できていると感じられます。

inubouzaki：イラストレーターの方々と一緒にお仕事ができること、自身が憧れていたイラストレーターの皆さまとのプロジェクトに携われているので、すごく楽しいです。

仕事中でも常に大好きなイラストのことを考えていられる環境もすごく働きやすいです。

成長を感じるのはどんなとき？

poriechiru：業務を早くこなせるようになったときです。繰り返しの業務ばかりでなく様々な性質の業務があるので、どのような業務に対してもスピード感を持って取り組む必要があり、それができるようになると成長を感じます。

あとはイラストレーターさんや取引先企業とのコミュニケーションを通して案件を進めていくのですが、相手からポジティブな意見をいただいた時などにも成長を感じます。

inubouzaki：チームの一員として働いていると感じるときに成長を感じます。様々な新しい仕事を経験することで知見が溜まっていくような感覚を得られる気がします。

あとは目標を設定してスピーディに処理できるようになったとき、自分で考えて行動できるようになったときなどは成長を感じます。

アルバイトの制度や待遇について

poriechiru：アルバイトでもリモートワーク手当が出るのと、有給休暇がとれることがすごく良いと思っています。

働いていると正社員との違いはあまり感じません。

ただサポート業務の割合は増えるので、イベントの視察をして写真を撮影したり、イベント什器を自分で探して買ってくるなど社外で体を動かすような業務が多少多い気はします。

その場合交通費や備品購入費などは月ごとに立替清算をしています。

inubouzaki：私もアルバイトも正社員もあまり変わらないと思っており、そこも良いところだと思っています。アルバイトを経験してからピクシブの正社員になる方もいると聞きました。

今後チャレンジしてみたいことがあれば、教えてください

poriechiru：イラストレーターさんとの新企画を立案して成功に導きたいです。

先日大型イベントのプロジェクトメンバーとして業務を経験させてもらったのですが、すごく良い刺激になりました。

今後はほかのイラストレーターさんの大型イベントを成功させることや、そのプロジェクトメンバーとして制作進行ポジションで関わることも経験してみたいです。

inubouzaki：私は社員の方と同じレベルで働けるようにスキルアップしたいです。

そしてイラストレーターの皆さまと信頼関係を築き、企画をスムーズに進行できるようになりたいです。

あとは正社員になるまでに、社員の方も含め世の中のビジネスパーソンとたくさん接してみたいです。ロールモデルになりそうな方と出会ったり、いろいろな価値観を知っておきたいと思っています。

最後に

ピクシブ株式会社ではサービス開発だけでなく、事業領域でもクリエイターにリスペクトを持ち、日々サポート業務に取り組んでいます。今後も創作文化への貢献を目的として、様々な事業にチャレンジしていく予定です。

クリエイターリレーションの記事をお読みいただき、クリエイターのサポート業務に興味をお持ちいただいた方は、下記エントリーフォームよりご応募をお待ちしております！ hrmos.co

【PIXIV DEV MEETUP 2024】Revamping VRoid Hub’s model processing pipeline with Rust

2024-12-03T18:30:00+09:00

Hi, my name is yue, from the VRoid team.

This article was created based on a talk given at "PIXIV DEV MEETUP 2024" held on September 20th, 2024.

speakerdeck.com

Introduction

In February 2024, We published an article about how we adopted Rust as a server side language. This article will provide a comprehensive overview of our progress since then.

System architecture

Here's a picture of our system’s overview before the migration.

VRoid Hub’s Architecture (Before)

This may seem a bit complex at first glance, but I will explain it one component at a time.

This is VRoid Hub's frontend application. It was built with Next.js and written in TypeScript.

There was some code compiled from Dart used for client-side validation, and we used WebAssembly to handle 3D models’ textures.

VRoid Hub's API Server is a Ruby on Rails application. It has a job queue for optimizing 3D models in the background.

We also have a library called vrm-ruby used internally which is written in Ruby. This makes it easy to use with Rails, but there are also some issues. For example, the model processing logic can easily get coupled to the API code.

Also, because it does not have many features, it cannot perform advanced transformation.

This is another component called VRMIO on the server side. It is a CLI application for optimizing VRM files.

Since it's written in C-sharp and powered by Unity Engine, it can perform advanced transformation, but it has an extremely complex build setup and runtime.

The final component on the server side is called VRMFLUX. It is a web server for downloading 3D models on demand.

It only has a small code base, so it is relatively easy to maintain, but just like vrm-ruby, it cannot perform advanced transformation logic. Also, because it is a user-facing service, its performance and security issues are critical.

To summarize, the server-side components are: vrm-ruby, which provides basic VRM support; VRMIO, for optimizing VRM; and VRMFLUX, the on demand download server.

As you can see, vrm-ruby, VRMIO, and VRMFLUX are all doing some kind of 3D model processing, but they are all written in different languages using different runtimes.

In a worst case scenario, a developer has to investigate each system to get something fixed.

Also, if there are any performance or security issues, each has to be fixed separately, one at a time.

The question became: how do we improve what we have?

Our journey

Next, I will talk about our journey to improve our system architecture.

First, we decided to try using Rust as a language to unify and migrate our processing pipeline.

There were many reasons to choose Rust.

First, Rust performs very well. Secondly, thanks to the strong type system and the borrow checker, Rust gave us more control and improved the overall correctness of the code base.

Also, Rust has a wide range of build targets and a good variety of libraries with excellent quality. I will talk about libraries a bit later in this article.

We also considered how well it matched our team members’ skills before we made the decision.

The first step of migrating the system was migrating VRMFLUX. You can find more details of the process here.

After the migration of VRMFLUX, we saw that the average response times were four times faster and only consumed a quarter of original CPU usage.

This looked good to us and gave us the confidence to continue on with this decision.

After the first step was done, the second step was converting VRMIO and vrm-ruby to Rust.

It is interesting to note that another developer on our team gave a talk on a similar topic three years ago. The title was The Optimization of 3D Models on VRoid Hub.

As you can see on this slide from the previous talk, the setup and requirements for running a portable unity application on the server side was extremely complex. We were even using GPU emulators to make the application run.

There were so many dependencies we needed to keep track of in addition to actually building the application. By migrating the application to Rust, the build step could be as easy as just running the cargo build.

The main challenge of converting a Unity application to Rust was preparing for advanced processing. For example, we had to perform texture atlas in a pure Rust context and build an importer and exporter for glTF or VRM files from scratch.

Modifying glTF files with Rust

Although glTF looks like JSON, it's actually a property graph.

If we try to visualize the graph, it will look something like this.

Texture atlas is a method for improving rendering costs.

Given the fact that glTF is a property graph, we can imagine a model has some definitions like this.

This model has four different meshes, four different materials, textures, and images.

With texture atlasing, we have to add and remove edges from existing materials and texture node graphs to complete the change.

So if we look at what is actually happening in the code, we are essentially doing what is shown in the picture above.

We first find the edge with the relationship we want to modify, then we just call the remove_edge and add_edge methods to change the model.

After testing, we converted the VRMIO and the vrm-ruby to Rust.

VRoid Hub’s Architecture (After)

By doing this, we were able to migrate all the server-side network requests to use zstandard as well.

As a result, we were able to build a stable GLTF/VRM importer and exporter. The average speed of model optimization is two times faster with much less memory consumption.

One important outcome of the migration is that the application is much easier to build, test, and maintain.

Looking at an overview of the system’s architecture at this point, you can see that we now have a shared Rust engine.

Here are some future possibilities for the engine.

We can compile the engine into WebAssembly or WASI targets for running with different runtimes. We could also compile the code as bindings if we decide to use the engine in Node or Ruby one day.

Libraries & Testing

We have utilized various crates throughout the migration process. For instance, we are using gltf_rs for glTF handling—the same library employed by the Bevy engine, a pure Rust game engine.

We are also using petgraph for graph processing. It is the same core component behind SWC, the famous JavaScript build tool.

Additionally, we are leveraging libraries like euclid for mathematical implementations. These libraries originate from the Servo community, which is developing a cutting-edge browser engine.

In essence, our system is powered by technologies derived from game and browser engines.

Here are some details about how we did the test.

We are using insta for snapshot testing, playwright for E2E testing WebGL contents.

We are also using Sentry to check for errors. Sentry actually has an official Rust crate, and that helps us a lot.

In addition, we are using Datadog for performance monitoring to see if something goes wrong or to check performance metrics.

We even built a dedicated real-time testing tool.

OSS contributions

We contribute intensively back to the ecosystem during the process. For example, we made contributions back to Three.js, GLTF-Transform, and many other repositories.

We also maintain OSS projects ourselves. For example, we have been maintaining three-vrm for several years.

During the migration process, we open sourced a new library called vrm-utils-rs, which contains the data structures for the VRM format.

We are also a part of the VRM consortium, so we are deeply involved in the process of discussing and designing the 3D model file format itself.

Summary

At VRoid, we will continue to focus on improving existing systems and user experiences.

We have many more plans to enhance our service this year.

Please stay tuned.

Kaigi on Rails 2024に参加しました！

2024-11-25T17:30:00+09:00

こんにちは、新規事業部のSketch部でバックエンドエンジニアをしているあやぬん(@ ayatk_ch)です。

2024年10月25日(金)～10月26日(土)に有明セントラルタワーホール & カンファレンスで開催されたKaigi on Rails 2024にピクシブはGold Sponsorとして協賛し、スポンサーブースを出展しました。

ピクシブからは13人のメンバーが参加しました。

inside.pixiv.blog

セッション

当日聞いたセッションのうち、個人的に印象に残ったものを紹介します。

基調講演 Day1

speakerdeck.com

これまで自分の中で幾度となく「Rails Wayとはなんなのか」考えてきましたが、「導きの星」という単語が表現したいことを100%表してくれていて感動したのを覚えています。SNSを見ていても自分と同じような感想を持つ方が多かったようです。スライド後半のRails Wayをどう実装に落とし込んでいくかという内容に関しても、modelのどこがダメでRails Wayの思想をどう適用していくかという過程が丁寧に解説されており、経験年数に関わらず「なるほど」と思える素敵な内容でした。

Railsの仕組みを理解してモデルを上手に育てる - モデルを見つける、モデルを分割する良いタイミング -

speakerdeck.com

このセッションではメンテナンス性の高いmodelについての具体的な実装方法の話でた。modelをどう分割するかについては悩みの種となりがちですが、テーブルやイベントで判断すると良いというわかりやすい説明があって、個人的に考えつかなかったことではありました。3層アーキテクチャを採用している場合Service層を作りがちですが「強くやめてほしい」と3度言っていたのが印象的でした。このセッションのターゲット層としては1年~数年のRailsエンジニア向けでしたが、自分のような5~6年のRailsエンジニアでも参考になる話でとてもよかったです。Service層を作りたくなったらこのスライドを見よう！！

登壇者であるigaigaさんは弊社で月一健康診断をしてもらっているのですが、そのことについても触れてもらっていたので嬉しかったです。

推し活としてのrails new

speakerdeck.com

Railsの得意分野である小さいものを作って最速でリリースするということと、DHHがRails World 2024で言っていた「One Person Framework ¹」を実感できる良いセッションでした。大変偏見ですがエンジニアはオタクの属性を兼ね備えることが多いと思っていて「こんな世界もあるんだ」とか「こんな “きょりちか” で作ったものが推しに使われるの良すぎない？」といった気持ちになっていました。プロダクトの仲間になりたそうな顔をしている人を巻き込むのもスキルも高く、自分にはないものでちょっと羨ましく感じました。後で本人に聞いたのですが、110ページにわたるスライドを15分33秒で話したらしくめちゃ早口でした。すごい。

基調講演 Day2

speakerdeck.com

Day2の基調講演は、2日間に渡るKaigi on Rails 2024の締めくくるセッションとなりました。

普段開発を行っていると、「この仕組みを実装するにはどうすれば良いか」を考える機会も多く、時にはRails Wayに乗らない選択肢というのも出てきます。現実の物事を実装に落とし込む際の複雑性に対して、よりシンプルに作ることができれば将来の不確実性や変化に対しても”修復”していけるというのが聴いていて強く印象に残りました。

タイトルにもある「TO HAVE FUN」という言葉のように、ビジネスもプログラミングも楽しくやっていきたいですね。

セッション外のコミュニケーション

Railsとは関係なく個人的にJRubyが気になっていたのですが、ちょうどJRubyのセッションを行なっていたRyudoさんとも2日目のお昼に実際使ってみてどうだったか、今後試してみたいことについてのお話しができてとても楽しかったです。

ブース

ピクシブではGold sponsorとして協賛しており、スポンサーシップの一環でブースを出させていただきました。

ブースでは「あなたの周りの面白いこと・人を教えてください」という絵馬書いてもらったり、クイズやアンケートに答えたらオリジナルグッズをプレゼントするという施策を行いました。

inside.pixiv.blog

ピクシブではカンファレンス参加時にTシャツではなく法被を着るのが恒例になっているため、ブースの設計としてもお祭りをベースに考えていきました。

お祭りといったら光るブレスレット！ということで、光るブレスレットをノベルティーとして配布していました。ブースに来てくれた方からは「懐かしい」、「子供の頃につけてた！」、「セッション中に光ってて気になってたんです！」といった声があり嬉しかったです。

ピクシブのオフィス入り口には大きな絵馬がある²ということと、「お祭りって神社だし絵馬がいいのでは」という考えから、ブースに来てくれた方に「あなたの周りの面白いこと・人」を絵馬に書いていただきました。続々と貼られる絵馬に対して、参加した社員もブースに来てくれた方からも「これ何！？」や「すごい気になる」といった感想をいただき、賑わっていました。

会期中ピクシブブースに寄っていただいたみなさま本当にありがとうございました！

RubyMusicMixin on Rails 2024

RubyKaigiや、去年のKaigi on Railsに参加している方はご存知かとおもいますが、ピクシブでは音楽を流しながら交流をする懇親会としてRubyMusicMixinを開催しており、今回のKaigi on Railsでも開催いたしました。

例年、RubyMusicMixinはクラブで行うことが多いのですが、今年はフットニック大崎店さん(https://footnik.net/osaki/) にて落ち着いた雰囲気の中で行ったため、より会話がしやすい環境にすることができました。

受付時にはサイリウムやブースで配っていた光るブレスレットを配布したことでよりパーティー感溢れる会場になりました。

今回は話のきっかけとして好きな音楽のジャンルをシールに書いて貼ってもらいました。「この人はこんな音楽が好きなんだ！」ということが一目でわかり、このシールを会話のきっかけとしてコミュニケーションが活発になっていました。

参加してくださった皆様ありがとうございました！また次のRubyMusicMixinもよろしくお願いいたします！

終わりに

今年のKaigi on Railsでは約700人もの参加者がオフラインで参加し、普段リアルで会わない参加者の方とも色々なお話ができて非常に楽しいカンファレンスでした！このような貴重な機会を企画・提供してくださった運営の皆様、ほんとうにありがとうございました。

ピクシブでは、毎回カンファレンスに参加するエンジニアが主体となってカンファレンスのブースやイベントの企画や設計を行っています。RubyMusicMixinをはじめとしたカンファレンスのスポンサーシップ以外にも、これからもRubyコミュニティの一員として、Ruby、Ruby on Railsを盛り上げていきたいと考えています！

今後のカンファレンスで皆様にお会いできることを、楽しみにしています！

高専プロコン第35回奈良大会に協賛・参加しました！

2024-11-19T18:00:00+09:00

皆さん、こんにちは。採用担当のmarikoです。

2024年10月19日（土）〜10月20日（日）、全国高等専門学校プログラミングコンテスト　第35回奈良大会が開催されました。ピクシブは特別協賛を行い、CTO道井が課題部門の審査委員を務めました。今回は協賛企業として出展したブースの様子と、審査委員から見た高専生を姿をご紹介します。

高専プロコンとは？

全国の高専生を対象としたプログラミングコンテストです。課題部門、自由部門、競技部門の3つの部門で構成されています。

課題部門は毎年設定されるテーマに即した作品、自由部門は自由な発想で開発された独創的な作品が提出されます。競技部門は設定された競技ルールによる対抗戦を行い、各チームの勝敗を決定します。

CTO道井が審査委員を務めた課題部門の今年のテーマは、「ICTを活用した環境問題の解決」が設定されていました。 ※今回の会場の「なら100年会館」。皆さんの緊張感・高揚感が伝わってきました！

ブースでみなさんをお迎え

今年も企業ブースを出展し、高専出身のエンジニア2名と人事で皆さんをお迎えしました。プロダクトや技術の紹介をしたり、社内の雰囲気や日頃の業務について、さまざまなお話をさせていただきました。

また、課題部門・自由部門に出場された各高専のブースも拝見し、開発のきっかけや当日に至るまでの思いなどを質問しながら交流を図りました。

ピクシブの企業賞は大島商船高専の皆さんに

どの作品も素晴らしいものでしたが、ピクシブは「プラたべる」を開発された、大島商船高専の皆様に企業賞を贈らせていただきました。

賞品としては、iPad ProとApple Pencil Proをお渡ししました。

二日間および当日までの準備・開発、本当にお疲れ様でした。

皆さんのやり切った表情を見て、私たちも非常に嬉しくなりました。心からの拍手を送ります。

開発に至る思いを直接聞くことができ、大変有意義な時間となりました。

審査委員を務めたCTOからのコメント

今年も課題部門の審査委員を務めさせて頂きました。今年の課題部門では「ICTを活用した環境問題の解決」という新しいテーマが設定されました。なかなか漠然としていて課題設定が難しいテーマだったと思います。

今年の課題に限らないですが、与えられたテーマについて自分ごととして問題を追求する、多くの課題を探索し、そのなかで独創的なアイデアを発見できたチームが良い結果につながっている印象があります。予選を通過され本選に出場されたどのチームも、様々な発想で課題解決に挑まれていて1人のエンジニアとしても多くの刺激をうけました。

今回のピクシブ賞は大島商船高専の「プラたべる」に贈呈させていただきました。

マイクロプラスチックによる汚染という地域課題に対してハードウェア、ソフトウェアの両面で様々な施策を提案してチャレンジした意欲的な作品でした。その中でも、専門家の方と共にアプリのコンテンツを考えられたり、ユーザーのことを考えキャラクターデザインや画面設計を丁寧に行われており、課題解決のなかでもたくさんのクリエイティビティを発揮されていたのがとても印象的な作品でした。これからも様々な開発でみなさんのクリエイティビティが発揮されることを期待しています。

来年開催予定の松江大会に向けて

あっという間の高専プロコンが今年も無事終了し、来年は松江での開催が発表されました。

お会いした皆さんの成長した姿を見られることを楽しみにするとともに、これからチャレンジする皆さんの挑戦を心から応援しております。

ピクシブは今後も学生を応援していきます

ピクシブでは今後も高専プロコンを含め、エンジニアを目指す学生の皆さんを応援していきます。今回の記事を通じて、ピクシブの話を聞いてみたい方がいらっしゃいましたら嬉しいです。

現在学生の皆さん向けにアルバイト・インターンの募集を行っております。ピクシブで働くことに興味をお持ちの方は、ぜひエントリーをご検討ください。 hrmos.co hrmos.co

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

「創作活動を、もっと楽しくする。」ために～京都芸術大学イラストレーションコースを支えるシステム開発～

2024-11-19T12:30:00+09:00

初めまして、kaniです。
普段はエデュケーション部教育開発チームのリーダーとして、システム開発に従事しています。

今回は、PIXIV DEV MEETUPのkeynoteセッションにおいて発表しました「京都芸術大学イラストレーションコースを支えるシステム開発」について、発表では省略した部分なども含めて書いていこうと思います。

ピクシブのエデュケーション部とは？

私の所属するエデュケーション部は、「教育事業」を通じて「創作活動を、もっと楽しくする。」チームです。ピクシブと京都芸術大学の提携事業である『京都芸術大学通信教育部イラストレーションコース（以降、イラストレーションコース）』の開校に合わせて2021年に新設された事業部です。

京都芸術大学イラストレーションコースとは？

そんなエデュケーション部の主なプロダクトの一つが『京都芸術大学イラストレーションコース』です。

2021年に開校し、今年で4年目を迎えました。入学者数は、延べ6,200名以上に上る日本最大級の通信制大学のコースです。

イラストレーションコースの特徴

完全オンラインでイラストを学べる
学費は年間約36万円（一般的な美術大学の5分の1程度）
卒業することで学士を取得することができる

また、学習体験にも力を入れており、以下の点が特徴となっています。

イラストレーションコースでの学習の特徴

「教員」としてプロのイラストレーターが所属し、イラストレーター本人が制作した授業からノウハウや知識を学ぶことができる。
制作した作品に対して実績のある教員から直接添削をもらえる。
教員と個別で話すことのできる「個別面談」を月100件近く実施しており、サポートも手厚い。

制作した課題に対して、教員から直接フィードバックをもらうことができます。

イラストレーションコースのシステム開発

イラストレーションコースは京都芸術大学とピクシブが連携した「イラストレーションコース研究室」によって運営されています。私もその一員です。

イラストレーションコースの立ち上げにあたっては、京都芸術大学、ピクシブ双方に“はじめての挑戦”が多くありました。京都芸術大学としては初の企業提携コースであり、ピクシブにとっても初めての高密度かつ長期の提携事業でした。

初年度入学者は予想の8倍、1600名

そうして生まれたイラストレーションコースですが、初年度の入学者は予想の8倍の1600名を記録します。

システムチームとしても『これだけの人数をどのように捌くのか？』ということが最大の課題になりました。

大きく課題になったのは「問い合わせ」と「作品評価」の二つでした。

問い合わせでは、回答状況を管理し、寄せられた問い合わせをコースの改善に繋げるための「カスタマーサポート」の仕組みが、作品評価では大量の作品を一定の基準で評価できる仕組みが求められました。

Google Workspaceを中心にしたシステム構築

システム構築に利用したのはGoogle Workspaceです。

GmailとGoogle Spreadshet、そしてGoogle App Scriptを活用することでオペレーションを構築しました。

問い合わせでは、メールを受信することで発火し、本文から学生の情報を抽出、スプレッドシートにまとめるスクリプトを作成しました。カスタマーサポートに必要な担当者の割り振りや回答状況の管理はスプレッドシート上で行い、手動での更新としました。

（このシステムは、今ではZendeskというSaaSに以降し、運用は終了しています）

作品評価では、評価基準を統一するために、「配点」と「評価結果」を管理する2つのデータベースに加えて「採点作業するインターフェース」の3つをスプレッドシートで構築し、それぞれをGoogleAppScriptで繋ぎました。

これにより、作業時間の短縮、対応遅れの早期検知を実現し、2500件の課題を2週間で評価することができました。

評価システムを構築する上で大切にしていることは、できる限り細やかな調整ができるようにすることです。

エデュケーション部では、教員のフィードバックが学生に齟齬なく伝わるように、教材や評価の仕組みの細部までこだわっています。システムチームでは安易にSaaSに乗ってしまうことでそうしたこだわりが失われないように、上述のような技術選択を行っています。

こうして運用実績を積んだ上で、段階的にSaaSへ以降していくことで、適切な技術選択ができるようになっていると感じています。

エデュケーション部システムチームのこれから

京都芸術大学イラストレーションコースの開校から4年目を迎え、個別業務を最適化する中で、さまざまな知見が蓄積されました。今後は、これらのデータを統合し、より情報技術的なアプローチで教育の開発を行なっていきます。

システムチームで大事にしていることは教育事業を推進するための「機会探索」と「効率化」です。

例えば、データ基盤の構築により、学生と教員のマッチングを最適化することで学習体験をより良いものにしたり、学生の興味関心を教材に反映したり、またコース運営の意思決定をデータを活用して支援するといった挑戦を行っていきたいと思っています。

エデュケーション部のMISSION・VISION

以上が、京都芸術大学イラストレーションコースにおけるシステム開発についてでした。ピクシブのエデュケーション部は、「感応と創造の力を育む」というミッションの元、「表現が聞こえる。表現で語れる。」というビジョンを目指して日々事業を行っています。

このイラストは京都芸術大学イラストレーションコース卒業生のイラストレーター安藤うりさんにエデュケーション部のビジョン「表現が聞こえる。表現で語れる。」を描いていただいたものです。

奥の学校から花が風に乗って広がり、動物たちの生活を彩るように、今後もエデュケーション部は「教育」を通じて「表現」が色々な人の生活を彩るような世界を目指してまいります。

安藤うりさんX：https://x.com/uri_illust

エデュケーション部の新しいプロダクト

エデュケーション部の二つ目のプロダクトとして、ZEN大学で「pixiv提携科目」の提供が始まります！

2025年開校の総合大学で、エデュケーション部ではpixiv提携科目を制作しています。今後の展開にご期待ください。

creative.zen.ac.jp

全社のデータを横断的に扱う！データ基盤チーム・データエンジニアの仕事とは

2024-11-18T18:00:00+09:00

こんにちは。広報部のmikoです。ピクシブには、全社・全プロダクトの基盤になる部分の開発や管理、運用を主に行うCTO室プラットフォーム開発部という部署があります。

今回は、プラットフォーム開発部のなかで、プロダクトのデータベースを分析などに活用できるようデータ基盤を管理・運用する「データ基盤チーム」のデータエンジニア3名に、仕事の内容やチームの雰囲気についてお話を伺いました！

自己紹介をお願いします

oystersuki：2023年に中途入社しました。以前はWEBマーケティングの会社で、広告運用やSEOのライティング、クライアントのデータ基盤構築などの仕事をしていました。現在は、全社のデータ基盤の管理・運用を担当しています。

kashira：2021年に中途入社し、全社共通のデータインフラやデータマネジメントの整備を行っています。前職ではECサイトのデータ基盤の構築や、データパイプラインの運用を行っていました。

shigenii：前職ではマッチングアプリの開発や分析支援、運用を行っていました。よりデータに関する仕事に関わりたいと考え、2022年にピクシブに入社しました。現在はマネジメントをメインに行いつつ、プレイヤーとしても業務を行っています。

具体的な業務内容を教えてください

kashira：一般的にデータエンジニアには、データのインフラを管理する仕事や、データを収集・分析しわかりやすい形に加工するデータパイプライン整備などの仕事がありますが、ピクシブのデータ基盤チームの場合は、データインフラを整備するのが主な仕事になります。

最近だと、私はAirflowのKubernetes(k8s)移行を担当したり、データマネジメント関連では、全社のBigQueryアカウントのセキュリティ強化を行っています。

oystersuki：私も全社データ基盤の管理・運用が主な業務です。新しいツールを導入した際に、古いツールの中身を移行する地道な作業を行うことも多いです。直近の大きな業務としては、大きなデータ量を占めているBigQueryのテーブルを移行・削除して3,500万円/年ほどのコスト削減を行いました。

kashira：コスト削減に関しては、かなり大きなインパクトがありました。扱っているデータ量やアクセスログが大きいため、5〜10個のテーブルの削除が、数千万円のコスト削減に繋がりました。

shigenii：私は先ほどお話しした通り、マネジメントが主な業務ですがやりたいことが多くプレイヤーもやっています。また、同じCTO室配下にあるデータ駆動推進チームや財務データ企画部も兼務しています。プラットフォーム開発部は業務内容が全社を横断するため、他チームとの調整を行う業務もあります。

inside.pixiv.blog

他部署との関わりは多いですか？

shigenii：全社のデータを扱う部署なので、色々な部署から相談が来ます。データエンジニアが在籍する部署と不在の部署があり、それによって相談の内容も異なります。データエンジニアが不在の部署だと、そもそもどのようにデータを活用したらいいか？という相談から始まることもありますね。

kashira：他部署の社員とコミュニケーションを取り、良い関係を築くことはとても大事だと思っています。私たちは社内にデータインフラを提供していますが、データインフラを自分なりに解釈すると「社内用プロダクト」のようなものなんです。そのため、社内からフィードバックや要望を拾えるよう、他部署との連携を普段から意識しています。

チームの働き方や雰囲気について教えてください

shigenii：データ基盤チームは、全メンバーがほぼリモートワークで稼働しています。そのぶんオフィスに集まる頻度は多くないですが、会社のオフラインイベントがあるタイミングでチームメンバーが出社して一緒にご飯に行ったりしています。

oystersuki：shigeniiさんがマネージャーに就任されてからは、チームとして積極的にコミュニケーションの機会を作っていただいていますね。

kashira：仕事の進め方に関して触れると、各々にタスクがあり、責任をもって自走していくパターンが多いです。かと言ってお互いに会話しづらい雰囲気はなく、仕事をする中で何か困りごとがあれば相談できる場はきちんと用意されています。

shigenii：チーム外だと、全社的にエンジニアの成長を支援するための横断組織として「エンジニアギルド」という体制があります。また、社内の勉強会も毎週開催されています。いずれも業務内容をお互いに共有したり、情報交換を行いお互いの成長を促す取り組みとなっています。また、データエンジニア同士の互助会が週1回あり、他チームのデータに関わるメンバーと情報共有をする機会としています。

kashira：読書会はチームでも行っています。データエンジニアリングに関して日本語で書かれた参考書がなく、洋書でFundamentals of Data Engineering という書籍があるんですが、分厚い洋書を一人で読み進めるのは大変なので、週に1回、チームで集まって読み込む会をしています。読んだものに対しての感想を交わし、チーム内でスキルの共有を図っています。

他にも、成果をinsideで外部発信したり、一緒に勉強会に行ったりと、交流や技術に関する取り組みをチームとして積極的に行っています。

inside.pixiv.blog

どんな人がデータ基盤チームのデータエンジニアに向いていますか？

kashira：利用者目線で使いやすいデータインフラを考えられる人は向いていると思います。また、全社的にいろいろな人とやり取りをする必要がある関係上、コミュニケーションが苦手だと辛いかもしれません。

スキル面で言うと、データエンジニアはスキルセットが広く求められます。データエンジニアリングの知見があることは大前提ですが、例えば業務内容によって、バックエンド系のプログラムを書く場面や、インフラの基礎知識が必要な場面が発生することがあります。そのため、色々な技術に触れることを楽しめる人が向いているのではないかと思います。

oystersuki：技術面に限らず、興味の範囲が広いと動きやすいことが多いです。例えば、私は少しマーケティングに関わった経験があるんですが、その経験のおかげでマーケティングチームとの意思疎通などはしやすく、仕事が進めやすいです。必須ではありませんが、データ以外のバックグラウンドもあると、より活躍できると思います。

後は、「データ基盤を良くしたい」という気持ちがあることが一番大事ですね。

仕事を通してのやりがいや楽しいところは？

kashira：インフラ、データ分析、フロントエンド側、など様々な場面でデータを扱う仕事が発生します。それらに対し、ある程度自分の意思で自由に進められる点が楽しいと感じますね。色々なことに挑戦できる機会がとても多いです。

shigenii：ピクシブに入社して強く感じたのが、会社全体として最上志向で、向上心が高いメンバーが多いということでした。そういったメンバーに囲まれて、自身の経験値を増やしスキルをあげていきたいという方にとっては非常にモチベーションが上がる会社だと思います。

また、大変ではありますが、かなり裁量を持って仕事を任せてもらえる環境なので、自身で考えて自走できる人は向いていると思います。

今後チャレンジしてみたいこと、課題や目標を教えてください

kashira：チームとして今一番考えているのは、社内の様々なデータ分析の支援です。今、その実現のためのタスクを積んでいるところです。

oystersuki：利用者が使いやすいデータインフラ作りを目指す中でも、マーケティング分析がしやすいデータ基盤を作っていきたいと個人的に思っています。例えば、「現状何がボトルネックになっているのか？」など、マーケティングにクリティカルに活用できるデータを求められたときに、今以上にスムーズに提供していける流れを作りたいです。

shigenii：ピクシブはプロダクト数が非常に多い会社です。私達のチームは全社を横断する業務が多いので、多くのチームとうまく連携する必要があります。そのため、各チームと良い関係を築くことを大事にしたいと思っています。そのうえで、ユーザーの価値に繋がるような組織、データ基盤を作っていきたいです。

ピクシブの好きなところ、入社して良かったと思うことを教えてください！

shigenii：とにかくプロダクト愛に溢れているメンバーがとても多いところです。自社サービスやプロダクトを好きな人が多い会社は良い会社だと肌で感じています。あとはサービスやプロダクトはもちろんですが、自社の様々な環境をより改善していこうと考えているメンバーが多いことですね。

kashira：自分は、好きなサービスの会社で働きたいと思ったことがきっかけでピクシブに入社しました。好きなものの裏側に関われると、モチベーションも上がります。入社してからは、技術選択の裁量の大きさや、エンジニアのスキルアップに対してのサポートの手厚さを実感しています。

oystersuki：私も昔からpixivを使っていました。まさか運営会社に入社するとは思っていなかったです（笑）。好きなプロダクトを保守する側に回れる喜びを感じられますし、自分の仕事がプロダクトに見合うように頑張ろう、という気持ちになります。

ピクシブへの入社を検討している人にメッセージをお願いします

kashira：働きやすく、裁量を持って働ける環境でスキルアップができる会社だと思います。少しでも気になったらぜひご応募いただければと思います。

oystersuki：データ基盤チームは、課題を自ら探して自ら動くことが求められることが多いので、周りに流されずに自分の仕事をしていきたい人にはぜひおすすめしたいです。

shigenii：「興味関心がある」という方と一緒に仕事をしたいと思っています。ひとつはもちろんデータ基盤への興味ですが、何よりピクシブのミッションへの興味です。「創作活動を、もっと楽しくする。」というピクシブのミッションに共感いただける方といっしょに仕事をしたいです。必ずしもデータについての知見が多くなくても、これからデータ基盤に挑戦したい！創作活動をもっと楽しくしたい！という強い気持ちがある人も大歓迎です。お待ちしています！

データエンジニアの業務に興味をお持ちいただいた方は、下記エントリーフォームよりご応募をお待ちしています！ hrmos.co

フロントエンドの標準仕様をどう追っているか

2024-11-18T17:00:00+09:00

こんにちは。福岡オフィスエンジニアの @petamoriken です。普段ECMAScriptやWeb標準を追ったり、DenoやTypeScriptにコントリビュートしたりしています。

PIXIV DEV MEETUP 2024にて、「フロントエンドの標準仕様をどう追っているか」という内容でLTをしました。その内容に触れながら軽く当日を振り返ろうと思います。

speakerdeck.com

ピクシブフロントエンド互助会

ピクシブでは2018年5月からフロントエンド互助会を開催しています。毎週フロントエンドエンジニアが集まり、最近の出来事や悩みなどを共有しています。

「今週の出来事🔨」「お悩み相談🚨」「今週の草🌴」の3つのコーナーに分かれており、特に「今週の草🌴」コーナーでは業務に直接関係のないフロントエンドのニュースや耳寄り情報について話題に出してよいことになっています。私は発足当初から積極的に情報を提供しています。

詳しくは過去の記事を参照してください。

inside.pixiv.blog

標準仕様を追うにあたって、おすすめの情報収集先

フロントエンドのニュースを分類すると、プラットフォームとエコシステムの大きく2つに分けられます。プラットフォームは標準仕様やブラウザ動向、エコシステムはライブラリや非ブラウザJavaScriptランタイムなどがあたります。

私は主にプラットフォームを追っており、その情報収集先として4つを紹介しました。

TC39 meeting agendas/notes

JavaScriptの言語仕様であるECMAScriptの変更や提案について議論しているECMA TC39が2ヶ月ごとに会議を開いています。その議題と議事録が公開されています。

github.com

ちなみにこの会議のまとめを個人的にCosense（旧Scrapbox）上で公開しているので、よろしければこちらも御覧ください。

scrapbox.io

Intents

Google Group上でGoogle ChromeやMizilla Firefoxに実装される新しい機能についての情報が共有されます。これを有志の方がX（旧Twitter）やBlueskyなどに流してくれるbotを作ってくれています。

intenttoship.dev

Standards Positions

最近はWeb標準への提案はGoogleやMicrosoftから出されることが多いです。Web標準は3つのブラウザエンジンによる多数決によってその可否が決まるため、新しい提案が入るかどうかはMozillaやWebKit（Apple）が賛成するか反対するかに大きく左右されます。各提案に対してそれぞれのポジションがGitHub issuesで管理されています。

github.com

mozaic.fm

ここまでは一次ソースを紹介してきました。mozaic.fmでは毎月プラットフォームとエコシステム両方をまとめてPodcast配信されています。

mozaic.fm

プラットフォームを追おう

よくフロントエンド技術の変化は激しいと言われます。実際にエコシステムではフレームワークに限らず、バンドラー、リンター、非ブラウザランタイムとありとあらゆるものが乱立している状況にあります。一方でプラットフォームについては一度ブラウザに取り込んでしまうとWeb互換性の観点で取り除くことが出来ないこともあり、数年かけてかなり慎重に議論されることが多いです。

プラットフォームを追うとまだブラウザで使えない機能に詳しくなってしまうというデメリットはありますが、大局的なWebの進化を俯瞰することができ、フロントエンドエンジニアとして長期的な成長が見込まれるのではないかと思います（……と言いつつ、ただ好きで追っているだけなんですが）。

余談

発表後の懇親会では「良い刺激になった」と感想をいただいたり、ObservableやSignalなど具体的な提案についての議論をしたりと、とても有意義な時間を過ごせました。

個人的には[[IsHTMLDDA]]についてや中黒（・）はJavaScriptの変数名として使えるかの話がとても面白かったです。

プラットフォームも一緒に追っていきましょう！！

「創作活動を、もっと楽しくする。」ために～インフラ部の挑戦とインターコネクト同時開設について～

2024-11-12T18:00:00+09:00

前置き

こんにちは、インフラ部のsue445です。

下記の記事でも書いたように、先日開催されたPIXIV DEV MEETUP 2024のキーノートでインターコネクト同時開設に関して話をしました。 inside.pixiv.blog

発表スライドだけでは当日喋った内容が伝わらないと思ったため、本記事では当日喋った内容の書き起こしを掲載したいと思います。

前置き
書き起こし全文
- 諸注意
- P1
- P2
- P3
- P4
- P5
- P6
- P7
- P8
- P9
- P10
- P11
- P12
- P13
- P14
- P15
- P16
- P17
- P18
- P19
- P20
- P21
- P22
- P23
- P24
当日の反応
懇親会で聞いたみんなの感想
余談

書き起こし全文

諸注意

場所によっては日本語が若干変な文章になっているかもしれませんが、その場の雰囲気を出すために言い間違え以外は実際に喋った内容をそのまま掲載しているのでご了承ください。（文章を直しすぎるとそれはもう書き起こしじゃなくなるので...）

P1

（場内拍手）

ご紹介にあずかりましたインフラ部の末吉です。

我々インフラ部では直接プロダクト開発に携わっているわけではないんですけども、間接的に創作活動を支えています。

P2

ピクシブではクリエイターの皆様を支えるためのサービスをこれだけリリースしています。

インフラ部ではpixiv.netを始めとするこれら全てのサービスのインフラを見ています。

P3

そして我々はエンジニアをはじめとする「創作活動を支える人たち」も支えています

P4

先程のエンドユーザー向けのサービスの他にも、GitLabやSentryやKubernetesなどの開発者向けのツールの運用もしています。

P5

ピクシブといえばこういうベニア板のサーバが有名でしょう。

長年社内のサーバーラックでこのベニヤサーバが開発環境として運用されてたんですけども、とうとう昨年全てデータセンター内のOpenStackに移行しました。

（場内から拍手喝采）

さっき出したKubernetesも一部このOpenStack上で動かしています。

P6

創作活動を支えるために、インフラ部では毎年様々な挑戦を行っています。

P7

私は昨年のPIXIV MEETUPでこのような発表を行っていました。

昨年Doingだったこの2つは現在両方とも本番稼働してます。

2つ目の既存サービスのKubernetes移行に関しては、今日のメインセッションで話されていたものになります。

このキーノートでは1個目の「オンプレミス環境と各クラウドとの閉域網接続」に関して、実際に本番稼働させるまでのチャレンジとプロセスについて少しだけ話そうと思います。

P8

今年ピクシブはPastelaとpixivcobanという2つのサービスをリリースしました。

PastelaではAWSのECSを、pixivcobanではGoogle CloudのCloud Runをそれぞれ利用しています。

P9

双方の開発の初期段階、ほぼ同時期にそれぞれある相談がきました。

P10

その相談というのは

新規のサービスをクラウドでリリースしたい
オンプレ側にある認証基盤や決済基盤をクラウドからも利用したい

というものでした。

マジでシンクロニシティでしたｗ

P11

それぞれ僕はこのアーキテクチャの選定にも携わりました。

チームのスキルセットや作りたいサービスの特性なども考慮して各チームと相談した結果、PastelaではAWS、pixivcobanではGoogle Cloudを利用することになりました。

P12

例えばオンプレミスで動いてるアプリケーションからECSとかCloud Runにあるサブシステムを実行するなど、これまでもオンプレミスからクラウドへのインターネット経由での連携は行っていました。

P13

しかし今回はクラウドからオンプレミスへの閉域網接続が必要でした。

閉域網接続、インターコネクトというのはインターネットを通らない通信のことです。イメージ的には専用線に近いんですけどもちょっと違います。

このような閉域網接続は弊社ではほぼ初の試みでした。

リリースの予定時期もPastelaとcobanでほぼ同じくらいだったんで、結果AWSとGoogle Cloudで同時にインターコネクトを開設することになりました。

マジで狂気でしたｗ

（場内爆笑）

P14

構成技術としてはAWSはDirect Connect Gateway、Google CloudではCloud Interconnectをそれぞれ採用しました。

P15

インターコネクトの開設にあたって様々なチャレンジがありました。

今回はそのチャレンジに対するプロセスを1個だけ紹介したいと思います。

P16

それは「クラウドからオンプレミスへのDNSに対して通信を行う」ということです。

クラウドからオンプレへのDNSに対してインターコネクト経由で通信を行うだけでも様々な困難がありました。

P17

例えばクラウド上にあるアプリケーションからオンプレミス側にある foo.example.internal に通信する場合を考えます。

この時、こんな図のような構成になります。

まずクラウドの中から foo.example.internal のゾーンである example.internal への通信をクラウド内のDNS転送ゾーンに転送します。 AWSではRoute53 Resolver、Google CloudではCloud DNSの転送ゾーンにあたります。

この転送ゾーンがいったんクラウド内のDNSのクエリを受け付けて、インターコネクト経由でオンプレのネームサーバの方に転送します。この転送ゾーンがオンプレ側とクラウド側とのDNSの二重管理を防いでいます。

オンプレ側のネームサーバは弊社ではBINDを使ってます。 BINDがインターコネクト経由でサービスのプライベートIPを返します。

返されたプライベートIPをもとに、アプリケーションがインターコネクト経由で実際のエンドポイントを叩いて、オンプレ側のアプリが決済基盤とかアカウント基盤とかのなんか、APIの実行結果 *1 をインターコネクト経由でレスポンスを返します。

手法は違うものの基本的にはAWSとGoogle Cloudでほぼ同じような構成をとりました。しかし、Google Cloudの場合DNSサーバの仕様が一部AWSと異なるため特殊な対応を行いました。

P18

例えばAWSの場合、AWSのRoute53 resolverというのはVPCに紐づけられているんで、Route53がBINDに通信する場合の送信元のCIDRはVPCのCIDRになります。

この図でいうところの 10.xxx.xxx.xxx/27 がVPCのCIDRになります。

P19

しかしGoogle Cloudの場合、Cloud DNSはVPCの外で動いてるんで、BINDに通信する時の送信元のCIDRがCloud DNSのCIDRになります。

具体的にはここの 35.199.192.0/19 って書いているやつです。

P20

インターコネクトの回線が1個だけならこれでもよかったんですけども、今後2つ目以降のインターコネクトの機器を追加した時に困ることが予想されました。

戻り先はオンプレミス側で指定するんですけども、CIDRが同じだと当然戻り先は固定になります。

行きのルートはそれぞれのなんか回線 *2 なんですけども、戻りのルートがなんかその1個の回線に固定されてしまって、そこがSPOFになって困ることが予想されました。

P21

そのためどう解決したかっていうと、VPCの中にDNSのサーバを別に立てて、Google CloudからオンプレのDNSを参照する時はそこを経由させるようにしました。

具体的にはVPCの中にGKE Autopilotのクラスタを立てて、その中で動いているcorednsがクエリを受け付けています。

P22

実際にはこういうルーティングになりました。

P23

その他技術的な詳しいことは先日こっちのテックブログに書きました。

inside.pixiv.blog

もしも興味ある方は御覧ください。あと懇親会で感想を聞かせてくれると嬉しいです。

P24

僕はインフラ部でたくさんの仕事をしています。そして、色んな顔を持っています。

そのうちの1個であるソリューションアーキテクトとしてこのような持論を持っています。

まずアーキテクチャに正解はないです。その時系列や組織構成によって最適解が変わります。

そしてその最適解を出すために我々は常に挑戦し続けています。

ご清聴ありがとうございました。

（場内拍手）

当日の反応

下記でまとめています。

togetter.com

懇親会で聞いたみんなの感想

事前のinsideがなかったら半分も理解できなかったw
（Cloud DNSのCIDRの仕様に関して）「マジか？」って思って調べたらマジだった...
最近Cloud Interconnectを開設したのでCloud DNSの仕様に戸惑ったのがわかりみしかなかった。

余談

特に意識はしてなかったんですが、インターネット企業でみんなご存知インターネットの基礎に関してキーノートをできたのは我ながらいい選択だと思いました。

インターネット企業のピクシブではインターネットが好きな人をお待ちしています。

www.wantedly.com

*1:訳注：「〜とかの、なにかしらのAPIの実行結果を」と言いたかった

*2:訳注：「なにかしらの回線」のこと

みんな大好き 🫶🏼 取引先との「セキュリティチェックリスト」への付き合い方

2024-11-07T19:00:00+09:00

PIXIV DEV MEETUP 2024当日の夕方にAquaステージ側におられた方は、「枕詞」についての語りから突然ボルテージ高くコールアンドレスポンスがはじまり、早口トークののちコールアンドレスポンスとともにドラが鳴るという発表を見た方も多くいらっしゃると思います。きっと言葉では言い表せないLT体験みたいなものを感じたのではないでしょうか。

申し遅れました。経営企画本部経営企画補佐を務めております*1エンジニア職bashと申します。

ぜひこちらのじっくりとスライドを再読いただき、ポップな話に隠されたテック業界への問題提起とその解決について読み取っていただけるとうれしいです。

スライド

この発表の経緯

世の中一般として「セキュリティチェックリスト」については大変だとか、記入を自動化できないかとか、そういう話題が多くあることにひっそりと心を痛めていました。

そこで私がセキュリティチェックリストに真摯に向かい合った経験から、セキュリティチェックリストとはどのような位置付けにあるのか、関係者をどのように媒介するものなのか、記入したチェックリストがどのような作用や使い方を及ぼすのかなど、一歩踏み込んで解釈するとその意義と価値を再発見できると考え、実体験をもとにライトウェイトなトークに仕立てました。

スライド内で引用した情報

https://t.livepocket.jp/e/aonyan-20190715
- オレモーコールをあらわすべく掲載画像の一部を引用いたしました
https://objectclub.jp/download/files/pf/ProjectFacilitationValuePrinciple.pdf
- オブラブのプロジェクトファシリテーションページにて公開のプロジェクトファシリテーション価値と原則編から、You vs. Us構図・Problem vs. Usの構図を引用いたしました

*1:加えてこの2024年10月より事業横断で開発全体を強化する「プロダクト開発ギルド」のギルド長として、開発サイクル改善のCoE組織、Developer Relations、そしてプロダクトマネージャー・コミュニティーマネージャー・プロダクトデザイナー・エンジニアの各開発系横断職能組織を束ねる役割をお預かりしています。メンバー個人の成長とコミュニティ貢献のために作られた支援制度を紹介します - pixiv inside にてもその一端を紹介しておりますのであわせてご覧ください。

connect-goとsqlboilerで構築するクリーンアーキテクチャ

2024-11-07T18:00:00+09:00

こんにちは、アドプラットフォーム事業部で広告エンジニアをしているhirocyです。

本記事は、2024年9月20日に開催された「PIXIV DEV MEETUP 2024」で行ったLTをもとに作成しました。ぜひ資料と併せてご覧ください。 speakerdeck.com

はじめに

ピクシブの広告プラットフォームは、広告管理サーバーと広告配信サーバーに分かれており、それぞれRuby on RailsとGo言語で実装されています。現在、広告管理サーバーをGo言語でリプレイスするプロジェクトが進行中で、可能な限りクリーンアーキテクチャを採用して開発を進めています。

本記事では、広告管理サーバーにおけるクリーンアーキテクチャの実践について、考慮したポイントを共有します。まず、クリーンアーキテクチャの概要およびconnect-goやsqlboilerの概要を説明します。その後、実際に広告管理サーバーを設計した際のディレクトリ構成を紹介し、connect-goとsqlboilerをクリーンアーキテクチャに取り込む際の工夫について詳しく解説します。

クリーンアーキテクチャとは

クリーンアーキテクチャは、Robert C. Martinが2012年に提唱したアーキテクチャの概念です。このアーキテクチャは、以下の4つのレイヤー構造を持つことが特徴です。

Enterprise Business Rules（domain層）
Application Business Rules（usecase層）
Interface Adapters（interface層）
Frameworks & Drivers（infrastructure層）

本記事では、それぞれをdomain層、usecase層、interface層、infrastructure層と呼びます。

connect-go・sqlboilerとは

connect-goの特徴

connect-goは、Connectという通信プロトコルのGo実装であり、Protobufという形式で記述された通信の定義に基づいてGoのパッケージを生成してくれるライブラリです。

sqlboilerの特徴

sqlboilerは、実際のDBスキーマからGoのORM（Object-Relational Mapping）をパッケージとして生成してくれるライブラリです。

広告管理サーバーのディレクトリ構成

広告管理サーバーの最終的なディレクトリ構成は以下のようになりました。

.
└── internal
    ├── domain
    │   └── user.go
    ├── infrastructure
    │   ├── db
    │   └── grpc
    ├── interface
    │   ├── controller
    │   │   └── grpc
    │   │       ├── interceptors
    │   │       ├── (connect-goの生成物)
    │   │       ├── presenter
    │   │       └── user.go
    │   └── gateway
    │       ├── (sqlboilerの生成物)
    │       ├── presenter
    │       └── user.go
    └── usecase
        ├── repository
        │   └── user.go
        └── user.go

クリーンアーキテクチャの各レイヤーごとにディレクトリを分けて実装されていることがわかります。

パッケージはinterface層の中に生成しています。

interface層に生成を行った理由

クリーンアーキテクチャに基づいて実装を進める中で、例えばconnect-goに関連する部分については以下のように理解しました。

interface層
- 通信の中身を扱うレイヤー
  - リクエストの内容をusecase層が求める形に変換
  - usecase層の結果を変換し、レスポンスとして返す
infrastructure層
- 通信そのものを扱うレイヤー
  - 例：gRPC通信の具体的な処理

このため、今回のケースでは、ハンドラーやDBクエリはinterface層に記述するのが適切だと判断しました。それに伴い、必要となる生成物もinterface層に生成することにしました。

connect-go・sqlboilerを扱う上での工夫

最後に、クリーンアーキテクチャの中でconnect-goとsqlboilerを扱う際に工夫した点について紹介します。

sqlboilerを扱う上での工夫

sqlboilerの特徴として、クエリの結果が独自の型で返ってくることが挙げられます。これをクリーンアーキテクチャに取り込む際には、domain層との間でデータの変換が必要となります。この変換をスムーズに行うために、converterをgateway内に作成して対処しました。

また、sqlboilerの実行には*sql.DBが必要です。そのため、infrastructure層で接続を確立した*sql.DBを返すように実装し、それをsqlboilerに渡してクエリを実行できるようにしています。

connect-goを扱う上での工夫

connect-goに限らず、Echoなどのライブラリでも共通して言えることですが、connect-goでは決められたハンドラーの型に従ってメソッドを実装する必要があります。これは、クリーンアーキテクチャにおけるusecaseからpresenterを呼び出す流れと相性が悪く、そのままでは実装が難しくなります。

そこで、controller層から直接presenterを呼び出す形にアーキテクチャを変更しました。

func (h *UserHandler) GetUser(
    ctx context.Context,
    req *connect.Request[pamv1.GetUserRequest],
) (*connect.Response[pamv1.GetUserResponse], error) {
    u, err := s.userS.GetUser(ctx, presenter.ToDTOUserInput(req.Msg))
    if err != nil {
        if errors.Is(err, domain.ErrNotFound) {
            return nil, connect.NewError(connect.CodeNotFound, err)
        }
        return nil, errors.Wrap(err, "failed to get user")
    }
    return connect.NewResponse(presenter.ToGRPCUserResponse(u)), nil
}

このメソッドはcontroller層に属しており、presenterを直接呼び出していることがわかると思います。このような工夫により、クリーンアーキテクチャにおける制約に対応しながら、実装を進めています。

最後に

今回の記事では、広告管理サーバーにおけるクリーンアーキテクチャを実践したなかで、考慮したポイントを紹介しました。

本記事で紹介したアーキテクチャは現段階のものであり、これからもリファクタリングを行いながら、より良いアーキテクチャを目指していきます。

pixiv inside

Zendeskを活用した社内ヘルプセンター導入と業務効率化の軌跡

社内ヘルプセンター設立の背景

社内ヘルプセンター設立の目的

導入後の課題と地道な改善の軌跡

導入後の課題

社員とバックオフィス相互が、より便利に使ってもらうために

自ら課題解決できるヘルプを目指して

「P-ガイドポータル」の閲覧数・問い合わせ数推移

RubyKaigi 2025に「Road to Go gem」で登壇するので採択されたProposalを公開します

自分のトークについて

実際に採択されたProposal

Title

Agenda

Details

Pitch

補足

【おまけ】過去のRubyKaigiで採択されたProposalの一覧

Android Viewのパスワード入力部分をComposeでも実現したい

はじめに

背景

課題

選択肢

どう取り組んだか

2つの問題

解決策

最終的な動作

最後に

動きのあるComposableを作成する中で

BOOTH 3Dモデルカテゴリ取引白書2025

3Dモデルカテゴリの取引データ

取扱高は前年比約187%

取扱高成長のウラ側

注文件数は前年の約2倍

注文者数は前年の約1.5倍

注文者件数・注文者数成長のウラ側

ライト層もヘビー層も盛り上がる

注文が伸びた3Dキャラクター（アバター）価格帯は5,000円〜6,999円

着せ替えニーズと3D衣装・3D装飾品カテゴリの盛り上がり

ギフト文化の定着と成長

2024年の3Dモデルカテゴリ関連取り組み

BOOTH

BOOTH以外

3Dモデルカテゴリのさらなる成長を目指して

ピクシブで働きませんか

中高生国際Rubyプログラミングコンテスト2024 in Mitaka 最終審査会に参加しました

今年のピクシブ賞

受賞理由

その他スポンサー活動

最後に

ピクシブが運営するサービスの基盤を支える インフラ部ソリューションアーキテクトチームの仕事とは？

自己紹介と、直近で関わった仕事について教えてください

仕事のやりがいや楽しいところは？

チームの働き方や雰囲気について教えてください

どんな人がこの仕事に向いていますか？

ピクシブのここが好き！を教えてください

ピクシブへの入社を検討している人にメッセージをお願いします

“つながりが生まれる場所”「#P-HUB（ピーハブ）」誕生の背景に迫る！担当者インタビュー第2弾

メンバー紹介

このメンバーで検討を進めることになった経緯を教えてください

どのように交流設計を進めていきましたか？

目的が決まり、次の議題である「名称」はどのように決めていきましたか？

投票企画について、社内の反応はいかがでしたか？

キービジュアル制作の狙いを教えてください。

デザインを作るときに考慮した点は？

「#P-HUB」を実際に開催してみていかがでしたか？

pixivリクエストで新しい創作の形を提供 リクエスト部の仕事とは

自己紹介をお願いします。

リクエスト部について教えてください

具体的な業務内容について教えてください

過去の印象的な業務はありますか？

仕事のやりがいや楽しいところは？

チームとしてはどのように連携していますか？

チームの雰囲気について教えてください

チャレンジしていきたいことや目標など今後の展望を教えてください

どんな人がこの仕事に向いていますか？

ピクシブのここが好き！を教えてください

ピクシブへの入社を検討している人にメッセージをお願いします

「ピクシブキッズデー2024」を開催しました！

当日の様子

ピクシブが運営するサービスの基盤を支えるインフラ部ソリューションアーキテクトチームの仕事とは？

pixivリクエストで新しい創作の形を提供リクエスト部の仕事とは

星のカービィあぶないグルメ屋敷!?の巻

これだけは知っておきたい岩石・鉱物図鑑