pixiv insideは移転しました！ ≫ https://inside.pixiv.blog/

「最速で最高のプロダクトを！」即戦力を生む、新卒エンジニア研修とは？

今年の4月に入社した新米エンジニア、せすたです。ピクシブ株式会社では今年から新卒エンジニアの研修期間を約1ヶ月に拡大することになりました。今回は受講者である新卒の目線から、生まれ変わったエンジニアの研修について内容や感じたことをお伝えします。

伝えたいこと

今回の記事でお伝えしたいことは以下の2点です。

  • スクラム研修や実務開発研修などの実践的な研修内容
  • 研修を通して学んだチーム開発で大切なこと

ピクシブ株式会社に興味を持っている学生の方や、新卒研修を企画している方の参考になれば幸いです。

研修の内容

研修は「（pixivで）最速で最高のプロダクトを作れるようになる」「プロダクト作成後もメンテナンスに気を配れるようになる」「業務を通じて開発の段取りを覚える」を大目標として行われました。内容は主に以下の5つです。

  • 基礎を固めるためのpixivのソースコードのメンテナンス研修
  • 開発のフローを学ぶスクラム研修
  • プロジェクトを体験するための実務開発研修
  • 技術職の新卒が総合職の新卒に技術を教えるプログラミング研修
  • 次回の出題者によるISUCON研修

プログラミング研修とISUCON研修については、弊社のcatatsuyが既に記事を書いていますので、今回の記事では割愛します。

メンテナンス研修

昨年までは配属先チームでのOJTによる研修とpixivの技術的背景についての短期間の座学が主で、新卒全員を対象にした開発研修はありませんでした。今年度は昨年度にも増して多様・大人数の新卒が入社したため、1ヶ月に渡っての技術研修が企画されました。

また、BOOTHなどRubyを採用したチームに配属されると、会社の中核サービスであるpixiv.netのソースコードに触れる機会がなかなか訪れないという事情もあります。本年度からはエンジニア全員がpixiv.netについて最低限の理解を得る機会として「pixivメンテナンス研修」が行われました。

この研修では実際にpixiv.netに発生している問題（コード上に残るレガシーな記述の置き換えや、ごく稀な場合に発生するエラーなど）を修正してサービスに反映し経過観察という流れを繰り返し行います。ひとりひとりに明確な課題としてGitLabのissueが割り当てられ、自分で実装の方針を考え、メンターや既存の社員と相談やレビューを繰り返しながらデプロイできる状態まで持っていきます。

スクラム研修

みなさんはスクラムをご存知でしょうか？スクラムは目標達成に向けてチームが一体となって動くことを重視したソフトウェア開発手法の1つです。今回のスクラム研修ではLEGOを使ってスクラム開発手法を体験しました。この研修は前半でスクラム開発手法はどのような流れで進んでいくかについて学び、後半は学んだ内容を元に実際にLEGOを用いて作業をしていきます。

f:id:sesta:20160707142515p:plain

この研修ではプロダクトとしてリゾート村を作りました。私たちはそのために、プロダクトオーナー（村長）にヒアリングを行い、要件定義やタスクの割り振りを行い、理想とするプロダクト（リゾート地）を完成させます。上の画像は私たちがLEGOを使って作ったリゾート地で、画用紙に道などを書きながらLEGOで施設を作っていきました。リゾート地とは程遠いですね（汗）。後でメンターの方から聞いた話なのですが、このスクラム研修では良いプロダクトが生まれたといった成功体験ではなく、ここがよくなかったといった反省点を多く持ち帰って欲しかったらしいです。実際に終わった後での振り返りでは多くの改善点が出てきました。

実務開発研修

最後に行われたのが実務開発研修です。この研修は先ほどのスクラム研修のような仮想のプロダクトオーナーではなく、実際にその機能を必要としている人が社内にいる業務効率化ツールを開発するものです。新卒は2チームに分かれて2つのプロダクトを開発していきますが、このチームは途中で交代となります。ですので、前半と後半でそれぞれどこまでやるかといった納期の意識と、引き継ぎまで考えてタスクをこなす責任感がこの研修では求められます。また、前半と後半は1週間ずつしかないため、スクラム研修で得た開発フローの知識や反省点を生かし、いかにうまくプロジェクトを回すかが重要となってきます。

学んだこと

ピクシブのエンジニア研修はとても実践的だったと感じています。最初から最後まで勉強になることばかりの研修でした。折角なので研修の内容ごとに感じたこと、学んだことをお話します。

メンテナンス研修

今まで、個人やチームで好きなものを好きなようを作っていた私にとって、1900万人が使うサービスのソースコードを触るというのは最初は不安が大きく、本当にデプロイをして大丈夫だろうかという気持ちでした。いくらメンテナンスとはいえ、バグが入ってしまえばサービスが機能しなくなる可能性もあります。ですが、この研修ではコードの改善からデプロイまでを反復的に何度も行いますし、前半はメンターの方がデプロイから経過観測まで付き添ってくれました。これによって研修が終わるころにはある程度の緊張感は持ちつつもデプロイを恐れることはなくなっていました。また、デプロイを繰り返すたびに自分の書いたコードが反映されていくため、自分も開発者の一員なんだという自覚をすぐに持つことができ、やりがいに繋がりました。

スクラム研修

この研修は本当に自分の行動を考えさせられました。「研修の内容」でお話したように、この研修自体は多くの反省点を得ることが重要だったわけですが、作業の共有ができていなかったり、終盤になってタスクが終わらないことに気づいたりなど、ここまでうまくいかないものかと思いました。しかし、研修が終わった後にしっかりと振り返りを行ったことで、チームメンバーとのコミュニケーションやスケジュールを意識したスピード感など多くの気づきを得ることができました。 一度やっただけでこれだけ多くの気づきを得られるスクラム研修は本当にやってよかったと思います。

実務開発研修

この研修はスクラム研修で得た反省があってこその研修でした。スクラム研修で先に開発のフローと、チームで動く時に重要な要素を知っていたため、チーム全員で同じ方向に向かって開発ができたのだと思います。スクラム研修ではコミュニケーションとスピード感の大切さを強く学びましたが、この研修では信頼関係がプロダクトに及ぼす影響を学びました。具体的には、プロダクトの内容を決める時に仲間同士で良いものは良い、悪いものは悪いと意見しあわなければ良いプロダクトは生まれないということです。メンテナンス研修やスクラム研修ではある程度作るものが指示されていました。ですが、この研修からはプロダクトオーナーは要望を伝えてはくれますが、具体的に何を作れば良いかを指示してくれるわけではありません。要望を満たすための詳細設計はチーム内で議論しなくてはいけないのです。信頼できる仲間と意見をぶつけ合いながら議論できたからこそ、最終的に良いプロダクトが生まれたのだと思っています。

まとめ

ピクシブのエンジニア研修は内容が濃く、常に挑戦し続けることができる研修でした。メンテナンス研修では開発の基礎を学びながら既に動いているサービスの修正を行い、スクラム研修では開発のフローを学びながら失敗を経験し、実務開発研修ではスクラム研修の失敗を生かすことでプロジェクトを完遂しました。これらの研修のおかげで最初に挙げた3つの大目標も達成できたのだと思います。今回の研修で学んだことを生かし、来年は次の新卒を教えられるように、1年間で技術面はもちろん開発の段取りを精一杯学んでいきます！

ピクシブでは一緒に最高のプロダクトを作ってくれる人を募集中です。今年の夏もインターンシップを行いますので、実際にチームでサービスを企画・開発してみたいと思っている学生のみなさんは、下のページから 7月11日(月)23：59 までに応募をお願いします！参加を待ってます！

ssl.pixiv.net

Slackを一句BOTで風流に

おはようございます。プログラマーのhakatashiです。

普段はpixivコミックやpixivノベルの開発を手伝っています。が、今回はそれとは全く関係ないSlackの話をします。

一句BOTとは

みなさんSlackは使っているでしょうか。普段から業務にプライベートにと幅広くSlackを使っていると、メンバーの何気ない一言に“一句”を感じることがあります。

f:id:hakatashi:20160705180600p:plain

風流ですね。

pixivにはこのような日常に潜む和の心を大切にする風雅なエンジニアが多いので、平安貴族よろしく日常会話や業務連絡に5・7・5の形の川柳を混ぜて会話します。とても優雅ですね。

ですが、上の画像のような完全に日常に溶け込んだ野生のステルス一句は、誰にも気づかれずにログの彼方へ流れていってしまうことも多いようです。そこで、Slackのメッセージから自動で一句を検出してReactionをつけるBOT、slack-ikkuを(1時間で)作りました。

github.com

f:id:hakatashi:20160705170036p:plain

このBOTを社内Slackに導入したことにより、人間がメッセージを読んで一句判定をする必要がなくなり、社員の負担が軽減され、QoLが上昇、業務成績は右肩上がりとなり、社内から笑顔の絶えない明るい職場となりました。みなさんもslack-ikkuを社内に導入して優雅な一句ライフをエンジョイしましょう。

使用した技術

というのはもちろん冗談ですが、これで終わるのも情けないので、今回のBOT制作に使用した技術を書き連ねていきます。

言語(処理系): Node.js

筆者はJavaScript大好きマンなので迷わずNode.jsを選択しました。

形態素解析: kuromojin

与えられた文章が5・7・5に分割できるかを判定するためには、文章の読みと単語の境界を解析しなくてはいけません。これを行う形態素解析器にはChaSenやMeCabなどの実装が存在しますが、今回はkuromojinを使用しました。

kuromojinは、形態素解析器kuromojiの純JavaScript実装であるkuromoji.jsを平易なAPIでラップしたライブラリです。このライブラリを使用すると、以下のように書くだけで文字列を形態素に分割することができます。

const tokenize = require('kuromojin').tokenize;
 
tokenize('「スラック」と「一句」で韻を踏んでいる').then((tokens) => {
    console.log(tokens);
});

kuromojinはtextlintの日本語プラグインを作る際にもよく用いられるライブラリです。覚えておいて損はないでしょう。

一句判定

形態素解析した文章が一句であるか判定するには、与えられた形態素を適当なスパンで分割して5音・7音・5音の三句に分けられるかどうかを判定すればよいでしょう。ですが、それだけの条件だとあまり和の心を感じない文章も一句判定されてしまい、一部の風流人に怒られてしまいます。

f:id:hakatashi:20160705172052p:plain

これはよくありません。このような一句は文節の途中で句切れが入ってしまっているため、あまりよい一句とは言えません。このような文章を除外するために、形態素列から文節の切れ目を適当に検出します。この手法は私が過去執筆した機械学習で石川啄木の未完の短歌を完成させるに書いた方法を応用したものなので、詳しくはそちらを参照してください。

Unicode正規化: unorm

一句の文化がSlackに根付くにつれて、だんだんと過激派の一句も登場します。

f:id:hakatashi:20160705183634p:plain

もはや風流を通り越してシュールですが、このような一句にもUnicode正規化を行うことで対応できます。

const unorm = require('unorm');

unorm.nfkc('㌠ ㌢㍍ ㌕'); //=> 'サンチーム センチメートル キログラム'

正規化で多少の表記ゆれにも対応できるので、事前処理としてこのような処理を入れておいて損はないでしょう。ライブラリはNFKCを正しく実装しているならなんでも良いですが、一番DL数の多いunormを使用しました。

機能テスト: mocha, mockery, nock, mock-socket

正直これだけのアプリケーションなのでテスト書かなくてもよいと思ったのですが、仮にも業務用Slackで動かすものだというのと、HTTP通信のモックを書いてみたかったのがあったので、簡単に機能テストを書きました。Travis-CIで動いています。

  • mocha: テストフレームワーク。
  • mockery: npmモジュールをモックするライブラリ。今回は設定ファイルとWebSocketをモックするのに使った。同名のPHPライブラリとは別物だと思われる。
  • nock: HTTP通信をモックするライブラリ。Slack API への通信をモックした。
  • mock-socket: WebSocket通信をモックするライブラリ。Slack Real Time Messaging への通信をモックした。

軽い気持ちで書き始めたら想像以上にたくさんのモジュールをモックする必要があって大変でした。

メンテナンス: GreenKeeper

こんな一発芸的なBOTは作ったあと誰にもメンテされないのは目に見えているので、あとの管理作業は機械に任せてしまいましょう。テストを書いたあと、GreenKeeperを導入しました。

GreenKeeperはリポジトリ上のpackage.jsonを監視し、依存しているライブラリにアップデートがあったら自動でテストを走らせて、ビルドが壊れていないかどうか確かめてくれます。npmの依存モジュールのバージョン解決はデフォルトでメジャーバージョンの最新に追従するようになっているので、新しいコードが浸透しやすい代わりにこれがビルドが壊す原因にもなっています。Node.jsアプリケーションを作ったら、ちゃんとテストを書いてこういったサービスを導入することを検討したほうがいいかもしれません。

また、GreenKeeperは依存バージョンにpackage.jsonでカバーされてないアップデートがあった場合に、package.jsonを更新するプルリクエストを自動で発行してくれます。

f:id:hakatashi:20160705175639p:plain

プルリクを受け取ったら、テストが通っているのを確認してGitHub上のマージボタンを押すだけでpackage.jsonの更新が完了します。スマホからでも余裕です。テストが落ちてたら不健全なのでコードを修正しましょう。

次回予告

slack-ikkuの開発により社内Slackに一句文化を根付かせることに成功したhakatashi。実装が落ち着いたと思ったのも束の間、pixivのリードエンジニアから新たな難題が……。

f:id:hakatashi:20160705184956p:plain

果たしてhakatashiはこの無茶ぶり難問に立ち向かうことができるのか。次回へ続く?

おわりに

pixivでは和の心を大切にするクリエイティブで風流なエンジニアを募集しています。一緒にSlackで一句バトルを繰り広げましょう。アルバイトもインターンもあるんだよ。