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

入社してからいろんなプロジェクトで鍛えられた話

こちらは ピクシブ株式会社 Advent Calendar 2014 の12/17の記事です。

こんにちは。フレッシュさが足りないと言われている新卒エンジニアの@yudemanjyuです。

今日は入社してからいろんなプロジェクトに放り込まれて鍛えられた話、早い話がOJTを受けた話をします。

プロジェクト1: Androidアプリ開発

入社当初はアプリチームに配属され、主にAndroidアプリの開発を担当していました。 入社以前はロボット制御やゲーム開発、スマートフォン向けアプリ開発のためのプログラミング経験が大半だったため、入社直後はサーバーサイドの技術にはかなり疎い状態でした。

そんなある日、メンターからこんな話が飛んできました。

「サービス全体を開発する能力を身に付けるために、ちょっとサーバーサイドの開発チームに行ってみない?」

こうして長い旅が始まりました。

プロジェクト2: pixivサーバーサイド開発

サーバーサイドで初めて参加したのはpixivのサーバーサイドを担当するチームです。 ここでは主にうごイラの開発に関わっていました。

pixivには既にPHPで実装された巨大なコードベースが存在します。 そのため、pixivの開発には単にPHPの知識だけではなく、pixiv独自の設計や実装に対する知識、つまりpixiv開発のお作法が必要です。 このプロジェクトではこのお作法との戦いが中心でした。

当然、お作法を一から教わるには時間が全く足りません。

そこで、pixiv開発に慣れている人にレビュワーになってもらい、以下のように進めました。

  1. アサインされたタスクの実装方針を決定する
  2. 実装方針のレビューを受ける
  3. 実装する
  4. 実装コードのレビューを受ける

ここでの実装方針は、ざっくりとした概要ではなく、具体的にどこにどのようなデータ、関数、メソッドを追加するかというレベルまで深堀りしたものです。

例えば、指定した作品がうごイラかどうか判定する処理が必要になったとします。 すると、そもそもうごイラを区別するための識別子の追加指定した作品の種別を取得できるようにする必要があります。

というわけで「作品種別にうごイラの識別子を追加して取得出来るようにする」というタスクの実装方針を考えます。

# 作品種別にうごイラ用の識別子を追加して取得可能にする
* /◯◯/IllustTypes.phpにうごイラ用の識別子を追加する
    * まだうごイラ用の識別子を定義してないのでそれを追加する必要がある
    * 作品種別自体は既に取得しているので取得用メソッドの追加は不要

実装方針を考える上では、なぜその実装を選択したか説明することも重要です。
実装理由を説明出来るようになるまでコードを読み込むことで、その部分に関して十分な知識が得られました。
と言うか、実装理由が説明出来ないのに実装出来るはずがありません。

実装方針のレビューを受けてOKをもらったら後は実装するだけです。 PHP自体もこのプロジェクトに参加してから始めて触りましたが、こちらはpixivの既存のコードからいくらでも情報が得られたので、特に問題にはなりませんでした。

これを繰り返していろんなタスクを消化することで、着実にpixiv開発のお作法を学ぶことが出来ました。

プロジェクト3: 社内向け勤怠管理システム開発

3つ目のプロジェクトは社内向けの勤怠管理システムの開発です。

こちらは既に稼働していた勤怠管理システムと、別途管理していた人月管理を統合した新システムを構築する案件でした。 ゼロベースで開発が始まったプロジェクトで、Ruby + Padrinoで実装することが決まった段階で、

「yudemanjyu、Rubyの勉強してみない?」

という軽いノリでプロジェクトの参加が決まりました。

pixiv開発ではpixivのソースコードをサンプルコード代わりに出来ましたが、このプロジェクトでは既存コードが全く無い状態からスタートなので出来ません。

そこで、最初の機能は社内のRubyのすごい人とペアプログラミングしながら開発を進める事になりました。

新規にシステムを構築する場合、当然一般的な開発スタイルに近いほどシステムのメンテナンス性が良くなります。 しかし、何も知らない状態から独学で開発すると、一般からかけ離れたバッドノウハウの塊のようなシステムが出来上がることがよくあります。(入社前によくやってました...)

今回はペアプログラミングをすることで、採用した言語・ライブラリの独学で偏った開発方法ではなく、一般的な一般的を一気に吸収することができました。 基本的な機能を一つペアプログラミングで実装すれば、後はその応用で開発を進められるようになります。

また、Padrinoは社内であまり広く使われているフレームワークではありませんでしたが、ペアプログラミングしたことで設計・実装方針やハマりどころの知見がスムーズに共有出来たというメリットもありました。

プロジェクト4: アプリ向けAPI開発

再びpixivの開発に戻ってきました。ただし、今度は弊社のアプリ向けに提供するAPIの開発です。

Viewを返すpixivとは異なり、アプリ向けAPIはJSONを返すRESTful　APIとして設計しています。

構造的にはアプリ向けAPI側ではController層とModel層を定義し、Modelからpixiv側との共通ライブラリを呼び出してデータを取得するという形です。 とは言えController層はルーティングの設定とModelの呼び出し、JSON化して返す以外のことはしないので単純でした。

アプリ向けAPIで定義するModelはpixivが持つデータをAPIのリソースに合うように整理したものになっています。 そのため、Model層では共通ライブラリから取得したデータを整理してModelに詰め直すためのユーティリティが用意されているといった独自の部分がありました。 なので、この部分をこれまでと同じようにペアプログラミングしながら教えてもらいました。

その後は一人でも意外と書けていたので、この数カ月で結構成長したんだなぁという実感を得られました。

プロジェクト5: そして現在

12月初旬

「yudemanjyu、来週からScalaやってみない?」

というわけで入社から4言語目、Scala案件が始まりました。

まとめ

サービスを開発する上では、アプリとサーバーサイド、両方とも出来ることが一番望ましいのは言うまでもありません。この一年は、それを学ぶ良い機会を得られたと思っています。

一方で、一から十まで全て学んでからプロジェクトに参加するのはコストがかかりすぎて現実的ではありません。 なので、言語仕様やライブラリのAPI等の基本的なところはGoogle検索等でカバーしつつ、プロジェクトの作法に従っているかを早めにチェック・教育する今回の進め方が、OJTの現実的な運用方法の一つと言えるのではないでしょうか。

エンジニア募集！

pixivではWEBアプリケーションエンジニアを絶賛募集中です。

次回のAdvent Calendarは？

明日は@chocomelonがAndroidのいい話をしてくれます。