pixivで２ヶ月間インターンを行なっていたので、そこで学んだことや感想を中心に記事にまとめました。

pixivで２ヶ月間インターンをさせていただいたので、せっかくなのでそのことをブログにまとめようと思います！

# インターン概要

pixiv本体リクエストチームで２ヶ月ほど開発に携わらせていただきました。具体的には、管理系の機能開発とフロントエンドの修正を3件行いました。メインタスクが管理の方だったため、部分的にわかりにくいと思いますがサボっていたわけではないので悪しからず...

# リクエストについて

[リクエストについて](https://www.pixiv.net/request/about)
リクエスト機能とは、その名前の通りピクシブを利用しているクリエイターに対しイラスト等を依頼するものです。具体的には、クリエイターは募集したい内容をもとにプランを作成し、それをもとにユーザは依頼を出します。また、利用規約的にはSNSアイコンで使用する旨を依頼文に明記し、クリエイターからOKがもらえればアイコンの依頼をするなんてこともできます。

# 取り組んだ課題の背景

今回の課題は、審査完了時に作品投稿時にスナップショットを作成するといったものでした。
具体的には、納品された状態で作品をきちんと保管し、必要になった際は提示できる状態にするといった内容でした。

# メインタスクの道のり

今回はいただいたタスクをただ実装するだけでなく、仕様の策定から行うといったものでした。そのため、せっかくなのでそれぞれ紹介させていただければと思います。

## まずは仕様策定

今回は以下の順番で仕様を整理しました。

1. 必要機能の整理
2. データ容量等の見積作成
3. 周辺調査・他チームのヒアリング・折衝

### 必要機能の整理

先ほどの課題をもとに必要機能の洗い出しを行いました。こちらについては、メンターさんが既に整理していただいけていたのでそちらについての確認と深掘りを行いました。結果として、以下の３ヶ所（サーバサイド・バッチ処理・フロントエンド）の機能開発を行いました。

- サーバサイド：リクエスト完了時にスナップショットを作成する
- バッチ処理：過去の分のリクエストについてスナップショットを作成する
- フロントエンド：作成したスナップショットを管理ページから確認できるようにする

### データ容量等の見積作成

必要な要件を洗い出したら実装！という流れになるのではなく、機能が完成した際どれくらいのリソースが必要になるかを洗い出す必要があります。（特に今回の場合はイラストデータもあるので...）そのため、１ヶ月あたりのリクエスト量から１イラストあたりの平均的な容量を調べたり、小説の文字数からデータ数を割り出したりしました。

### 周辺調査・他チームのヒアリング・折衝

上記の見積をもとに、オンプレに載せるのかそれともクラウドサービスを使うのかを検討しました。また、クラウドの場合どのサービスが良いかなどを他チームにヒアリングしたりし、メンターさんと共に考えまとめました。最終的にはオンプレを用いることになったため、その結論をもとにインフラ部の方と相談し、実装に必要な情報のキャッチアップ等を行いました。

### 感想

今回のインターンの中でこの仕様固めについてはとても印象に残るものとなりました。というのも、実はここまで追えるのに１ヶ月ほどかかってしまい、エンジニアのインターンなのに半分近くコードを触らずに過ごすという...でも、今までの長期インターンでは、開発が主で基本的に与えられたタスクをこなすだけだったので、とても新鮮でまた楽しく取り組むことができました！特にこのように他チームへのヒアリングや、インフラ部への相談などエンジニアとしてのタスクの内、コーディング以外の部分に触れられたことは、自分の経験としても非常に大きかったと思います。特に、資料のまとめ方や相談の仕方、コストとリソースのバランス感など非常に学びになることが多く、今後コーダーではなくエンジニアとして働く上で必要な部分に触れることができたと思います。また、さすがオンプレだと思ったのは、途中でCephなどのクラウドを使用しているとおそらく触れることがないであろう概念が出てきたのが印象的でした。

## ようやく実装開始

先ほど作成した仕様等に沿ってそれぞれ実装を行いました。
また、こちらについてはあまり具体的な話は大丈夫かわからないので、感想を中心に書きたいと思います。

### サーバサイド

今回のサーバサイド開発では、DBのセッションがそれぞれの用途で分かれていたことがとても印象的でした。過去のインターンでは新規開発がメインだったこともあり、もちろんテーブルは分けていたものの、管理系やコンテンツ系などそれぞれの用途によってDB自体が異なっていることはなかったので、さすが大規模サービスだなと感じました。
また、実装後いただいたレビューの中で、PHPはNullの扱いに気をつける必要があるということを指摘いただきました。自分は過去にPHPを用いた開発に携わった経験はありますが、基本的に０から同じライブラリで同じバージョンを用いたものだったため、他のコードを参考にすれば大体問題なく実装することができました。しかし、今回は数十年単位で開発されてきたサービスだったため、その時々での最適な形で実装されていたため、なぜ返り値の型が異なっているなどをお教えいただきました。その中で、Nullをそのまま使ってしまうとエラーなのかデータがないのかがわかりづらいと教えていただき、ただ実装するのではなくきちんとコード特性を学び取り入れることの必要性を改めて認識するきっかけになりました。特に自分の場合、ライブラリによって抽象化されたものを組み合わせて使うということが多いので、このような型やデータの処理については特に意識しなければならないと感じました。

### バッチ処理

今回の実装では、既に仕様が定まっておりバッチ処理でもスナップショットの作成を行うことがわかっていたため、ヘルパー関数として実装を行なっていました。そのため、ここではデータを取得し加工の部分に集中して開発を行うことができました。
また、こちらではレビューの中でデータベースとのやり取りについて指摘をいただきました。具体的には、最も重い処理の実行速度と実行計画を意識しなければならないという点でした。いままでの開発では、ORMをそのまま使用していたことやそもそもデータ数が多くなかったため、インデックスを貼ったりはしたものの、SQLのチューニングなどを特別気にすることはありませんでした。しかし、今回のような大規模なデータベースだからこそ気にしなければならない点や、実行計画について実際に手を動かしながら学ぶことができ非常にためになりました。もちろん、このような部分は当たり前のことであると思いますが、そもそも大規模サービスに触れる機会が少なかったため、勉強していても実感として味わうことはありませんでした。そのような中、今回の経験は非常に有意義なものとなったので、今後自分の中で知識を深め個人開発や実際に働いた際に活かしていきたいと思います。

### フロントエンド

フロントエンドの実装については、取ったスナップショットの表示を行うのみだったため、他に比べ特に難しい部分はなかったと思います（記憶の中では...）。しかし、この部分については何度か仕様変更が入っており、表示の仕方の変更や機能の増減がありました。最終的には、一番簡単な形での実装でしたのでスムーズに行うことができましたが、このような会話の中でやはり管理画面ひとつとっても表示の部分については目的と強く結びついている部分だと感じました。特に印象的だったことは、その画面はリクエストの人以外も使うことを想定しているため、なるべくリクエストの要素は取り除いてあると教えていただいたことです。確かに、専門的なページにしてしまえばそのチームでは最も使いやすいものができますが、ドメイン知識がない人のことも考慮すると載せるべき情報のバランスを考えなければならず、大人数でサービスを運用しているからこそ気を配らなければならない点だなと感じました。

### 感想

今回の実装では、自分が一番知ってる状態で実装できたため、ヘルパー関数などある程度先を見越した実装ができ良かったです。一方、今回は短期間でチームを離れるため実際に使用する場面に遭遇しませんでしたが、本来であれば自分で設計・実装をしたためそのチーム内である程度機能に対して責任を持つことになると思います。そのため、自分の中ではある程度ドキュメントにしたつもりですが、今になってエンジニアではなく実際に使うであろう人にチェックいただいた方がよかったなと後悔してます...
また、開発を通し大人数でコードを触ることを意識して取り組むという点がとても勉強になりました。特に、テーブル設計や使用頻度や想定クエリ数が書かれたスキーマレビューや、SQL内にてFORCE INDEXでどの部分にインデックスを貼っているのかを明記するといった部分は、今まで経験したことがなかったため今後の開発では明記するという部分を意識していこうと思います。
他にも、今回のインターンでは開発フェーズによって意識する部分が大分異なることを実感しました。今まで携わった新規開発では、どちらかといえばスピード重視で開発を行っていたため、一部仕様が未定の状態で実装し後から付け加えることもありました。しかし、大規模サービスの場合他との兼ね合いやパフォーマンスに気を配るなど、それぞれの違いを体感することができ今後のキャリアを考える上でもとても良い機会になりました。

# 全体を通しての感想

## 開発について

開発環境はとても良く、ローカルで環境構築し実装を行うのではなく全て個人ごとの環境をサーバ上に構築し、そこをリモートでコーディングを行うとい
ったものでした。そのため、基本的にはスクリプトを走らせるだけで全て綺麗に完結したのでストレスなく実装に入れました。過去のインターンでは、環境構築で一度止まりドキュメントを読み漁った結果、終えるまでに2・3日かかると言ったことがあったので、ここはさすがオンプレの会社だなと感じました。また、今回12月からお世話になっていたのですが、ちょうどlog4jsやChrome周りの騒動があったので直接関わることはなかったものの、どれくらいの影響があるかやその対応などは身をもって体験しました。

## チームについて

今回リクエストチームにお世話になっている中で、ちょうどコミケ前だったので出店のお話をされていたりYoutubeから銀の盾をもらっている方がいたりと、作るだけでなく自身もクリエイターとして活動されている方非常に多い印象でした。他にも、翻訳の修正タスクを行なった際トリリンガルを超えた人がいたりなど、様々なところに強みを持った方が働かれているなという印象でした。また、チーム内の雰囲気も良く所々古き良きニコニコの雰囲気を感じることもあり、個人的にはとても魅力的な環境だなと思いインターンをしていました。

２ヶ月という短い時間でしたが、メンターさんをはじめチームの皆様、相談に乗ってくださった他のチームの方々また、インターンを受け入れてくださったピクシブの皆様本当にありがとうございました！

pixivでのインターンを終えて

開発型のインターンで、事前開発や当日3日間の開発をもとに実際にエンジニアとして働いている社員さんにFBをもらいながら成果物を突き詰めていくという内容のインターンに参加しました。

初めまして[つばめ](https://twitter.com/is_tsubame)と申します！
今回サイバーエージェントさんのACEというインターンに参加し個人とチームで賞をいただけたので、これを機会にブログを始めてみようと思います。

# インターンACEとは

[インターン募集ページ](https://www.cyberagent.co.jp/careers/students/event/detail/id=26121)

開発型のインターン（**ハッカソンじゃない**ここ重要）で、事前開発や当日3日間の開発をもとに実際にエンジニアとして働いている社員さんにFBをもらいながら成果物を突き詰めていくという内容でした。
具体的には、自分のチームの場合だとフロント2名+サーバサイド2名の計4名で取り組みました。使用技術は以下に示します。また、使用技術は他のチームの場合Golangだったり、Reactだったりとチームによって異なりました。また、これらの技術は選べるわけではなく、選考時に使用希望言語を選択する欄があり、そこで入力したものからチーム分けが行われるという形でした。そのため、この技術の欄はなるべく自信があるものを選択しておくほうが良いと思います...（自分達のチームでは2人ともあまりNodeに触れたことがなく大変なことになりました...）

* フロント（記憶違いだったらすみません...）
  		- Swift（iOS）
  		- Swift UI
* バックエンド
  		- Node.js（後にTypeScript化）
  		- AWS（Fargate＋Aurora）

# 今回のインターンで学びたいと思っていたこと

最近[Scenery](https://scenery.cam)というサービスを開発しており、その過程で自分の作ったコードが読みにくかったり追いづらいなど、あまりにも保守性や拡張性が極端に低く、このままでは継続して開発してたらスパゲッティーしかできないと思い、「ドメイン駆動設計入門」という本を参考にドメイン駆動設計を学ぶことにしました。
そのため、今インターンでは実際に自分が思うコードを作り、メンターさんからFBをもらうことでより設計手法についての理解を深めたいという目標を掲げ参加しました。

# 本番前に感じたこと

募集ページにも書いてあるとおり、本番は3日間（8/20〜8/22）ですがその前に事前開発の期間があります。
自分は面接の最後に「事前開発の時間をとってもらいたいが大丈夫か？」という質問に対し「1週間開けてあります！」と答えましたが、全然足りませんでした...
7/30日にはチーム発表されているので少しずつ開発を行なっていたのですが、ディレクトリ構成やDockerfileの修正など行なっていたら、ベースを作るだけで後1週間ちょっとしかない...!?となります

また、他のチームではSwaggerを使いすでにフロントとサーバサイドでAPIの内容よあモックの共有をされていたのですが、自分達はエンドポイントとこのデータを返すという部分しかなくフロントの作業に迷惑をかけてしまうということがありましたので、最初のチーム会で決めておけばよかったなと後々後悔しました...

# 実際に作ったもの

私たちのチームではドメイン駆動設計を元にAPI開発を行いました。ディレクトリ構成図は以下に示したとおりです。

![ディレクトリ構成](//images.ctfassets.net/xvuucoeywj65/3Lu8Fh5sAmM3RUi0IqTvQF/301a5afdaf2003e1e701e4874336f440/___________________________-2021-08-28-15.31.12.png)

今回のインターンでは事前にMySQLやNode.jsの動くDockerfileと、Hello Worldが変えるAPIとMySQLに接続確認ができているプログラムファイルが提供されていてそれを元に開発を行うという流れでした。ちなみにもとのファイルはJavascriptで書かれており、Typescript化は自分達で行う必要があります。

また、今回の開発ではそれぞれ以下のことを目的にテストコードを書きつつ開発を進めていました。

* Repository層（infra）：正しくデータベースの検索が行われているかや、ORMのエンティティの定義が間違っていないか
* Usecase層：RepositoryやInterfaceからのデータをもとに正しく処理が行われているか、または必要な箇所で想定する例外が返ってくるか
* Handler（Interface層）：今回統合的なテストコードを書く時間がなかったため、リクエストに対し想定するレスポンスが返ってくるか

細かい部分だと、Dockerfile内にTypescriptをコンパイルする処置を作ったりなど工夫した点は様々あるのですが、今回のインターンの目的が割と品質寄りだったこともあり、自分の中ではテストコードは書いてAPIを作成したつもりです...

# 開発中について

開発中に様々なアドバイスをいただきましたが、その中でも印象に残った2つについて書かせていただきたいと思います。

（私の受け取り方が違ったらすみません...）

## Interface層で入力されたデータの確認をしっかりとするべき

以前DDDの勉強中、入力された値のチェックはどのように行うべきかを調べた際、ドメインロジックを使いバリデーションを行うと書かれていたものがあったため、それに倣いInterface層で受け取ったパラメータをそのままUsecase層に流していました。
そこでメンターさんから、途中でデータのバリデーションをつけるべきだというアドバイスをいただき上記のことを質問させていただいたところ、確かにしっかりとしたオブジェクト指向の言語の場合はUsecaseの入力時に型をつけることである程度不正な値は弾けるが、今回のTypescriptなどの場合Interface層できちんと値の選別をしないと不正データがUsecase層まで侵入し大変なことになると回答をいただき、なるほどなと思いました。また、その後に設計は決まった形があるわけではなく言語特性によって加えたり減らしたりする必要があるというお話をいただき、今まで自分は複数の言語で同じものを作るということがなかったため、とても印象的でした。

ちなみに、はそれぞれの言語でテンプレートを作ってGithubとかに持っておくと便利だよというアドバイスもいただきました。勉強して適宜修正すれば学んだことの履歴を残すこともできるので、今度時間がある時に今行っているNodeとGolangのテンプレート作ろうと思いました！

## Usecase層とのやりとりで直接ドメインモデルを渡さないほうが良い

上記のアドバイスをもらった際、Interface層とUsecase層のデータの受け渡しに関してもアドバイスをいただきました。
今回作成したAPIの場合、そもそもデータの加工が少なかったため特に大きな問題が発生しているわけではないが、今後複雑化していく中で返すデータもモデルと1対1で結びつくわけではなくなる可能性が高いので、きちんとインタフェースを作りデータの受け渡しをしたほうが良いとのことでした。このことに関しては、DDDを元に自分がまだそこまで大きな開発を行なったことがないのですぐになるほど！とはならなかったのですが、確かに、規模が大きくなった時のことを考えると、それぞれで型を決めておかないと拡張性が下がるなと思い結局なるほどなりました。

他にも参照透過性やlet→constなど、ものすごく細かくまたためになるコードレビューをいただけたので、今後記録に残したものをいろんな場面で使っていこうと思います！
（そのレビューをもらうためには早く開発を終わらせる必要があるので事前開発が大事に...）

また、とにかくメンターさんのフォローがすごかったです。
インフラ担当のメンターさんは開発時間外にも関わらずAWSの操作可能時間ギリギリまで手伝ってくれたり、サーバサイド担当のメンターさんは日付が超えそうになるまでプログラミングの面倒を見ていただきました。本当にありがとうございます！！！の一言に尽きます。
他にも、当日Discord上に駆け込み寺が設置されたりと本当につきっきりで3日間メンタリングをしてもらいとても勉強になる日々でした！
開発とは関係ありませんが、私たちがチームで作業していたりする間Discordのチャンネルに集まって話していたり、もともと社員さん同士の繋がりが強いイメージがありましたが、想像以上に仲が良さそうな印象を受けました。

# 感想

今回のインターンでは3日間という短い時間にも関わらずとても多くのことを学べたなと感じました。特に、自分が今興味のある設計についてアドバイスを頂けたことは非常に大きかったです。
また、その他にもチーム開発ができたことはとても良い経験でした。今までにもインターンでチーム開発を行うことはありましたが、その場でフロントとサーバを分けて行うという形だったため、今回のようにしっかりとアプリとサーバで分けて開発を行うことはありませんでした。そのため、別れているからこそ共有しなければならないことがあり、その点で色々と迷惑をかけてしまったことが今後の反省点です...。
また、私たちのチームはありがたいことに賞をいただけたことで1ヶ月追加開発する期間をいただけたので、可能な限り完成形に近づけるため残りの期間頑張っていきたいと思います。

Welcome to sZma5a's Blog

Create Services

Intern History

Webシステム開発会社

Webシステム開発会社

Webシステム開発会社

Webシステム開発会社

Blog

pixivでのインターンを終えて

ACEインターンを終えて...