FANCOMIでのCTR予測インターン

データ分析コースのインターンシップに参加させていただいた NAIST の福田です。
普段は、機械学習を使って、アンケートにより得られる労働者の心身状態（ワークエンゲージメント、うつ度合いなど）を当てる研究をしています。

元々、広告業界に興味があり、なかでも機械学習を使ったものがあると聞き、FANCOMIの広告枠のCTR予測について、5 日間取り組みました。

最近は、コロナウイルス（COVID-19）が流行っていますが、体調に気をつけて頑張っていきたいと思います。
※ 福田さんがインターン参加の時期（2020年2月頃は）は、コロナの影響でファンコミュニケーションズでは、出勤・退勤時間をずらす対応やテレワーク業務を実施していました。（ファンコミュニケーションズ追記）

1day : 広告配信の仕組みの勉強＆CTR予測のための事前知識の勉強

私が取り組んだテーマである 広告枠のCTR 予測は、広告を表示したい広告主がよりうまく宣伝できるように、RTB で広告枠の取引する際に用いる指標となるものです。
　
具体的には、Webページを開いたときに、訪問者の画面に表示する広告枠がリクエストされ、どの広告主がその権利を得るかのRTB取引市場に流れた時に、広告主は、クリック率などの指標を基に、入札処理を行い、勝ち取った場合に、その広告主の広告が表示されます。

機械学習での CTR 確率予測

CTR（Click Through Rate）は、広告枠に表示された広告をクリックするかしないかの確率であり、機械学習で予測する場合、クリックするか / しないか の分類ではなく、何%でクリックするかの確率値を予測することになります。

実際の例で言うと、広告素材やサイトのジャンル、サイトの訪問者の属性によって異なりますが、おおよそ 2 ％ 程度らしいです。学習データとなる広告リクエストのトラフィックデータもそのような割合になっており、クリックされた時の広告リクエストの割合は全体の1-3 % 程度です。
つまり、極端な不均衡データとなっています。

また、別の問題として、予測は確率値で行いますが、その評価に用いるデータは、クリックしたか / していないかの 2 値であるため、どのような評価指標で、予測した確率値とクリックの有無の2 値を紐付けて評価するかが課題になります。
この辺りの議論は、ここに詳しく書いていますので、参考にしてください
www.jstage.jst.go.jp
CiNii 論文 -  CTR 予測モデルの評価に AUC や log-loss は適切か?

2day : nend サービスのトラフィックデータのクリーニングとCTR 予測を行う機械学習モデルの構築

5 日間のインターンシップで、自分が行うCTR予測の目標設定をしました。
NN系のモデルやKaggleなんかではFactorization Machines (FM)による方法が精度が良さそうということがわかっていましたが、5日間しかないため、そこは目指さず、特徴量の改良にフォーカスしてみました。

カテゴリー変数となる広告ID などが特徴量に入っており、OneHotエンコーディングでスパースになっているため、次元の呪いなどもあるんじゃないかと思い、色々試してみることにしました。
具体的には、スパースになりにくい特徴量で、モデルを組むとどうなるのかを試すことにしました。

流れとしては、nend のリクエストなどが格納された DB から、Treasure Data経由のSQLによりトラフィックデータを取得し、欠損値補完などを行い、ロジスティック回帰などのモデルに学習させました。

CTR予測のながれ

まずはじめに、広告宣材ID, サイトID, キャンペーンID などをOneHotエンコーディングし、特徴量とした場合の結果です。

機械学習のモデル構築・評価に使用したデータは、昨年度の nend のトラフィックデータのうちの、学習データ：10日間、評価データ：7日間です。モデルには、パラメータ調整を行なっていないロジスティック回帰モデルを使用しています。

広告宣材ID, サイトID, キャンペーンID などを特徴量とした場合の結果

model	N	pos. rate	Expecred click	AUC	log loss	mean entropy	NE	ECE
train	3,279,148	0.113428	0.113113	0.703659	0.322233	0.353622	0.911236	0.003114
test	4,042,439	0.002305	0.002571	0.698176	0.015577	0.016297	0.955832	0.000282

上の表の NE が、正規化エントロピー (NE) であり、今回着目した指標となります。
これは、CTR 予測などの不均衡データに対して対応されている指標であり、対数損失（Logloss）に対してデータの不均衡性に対応する形で正規化されたものです。
おおよそ 1 を超えると、平均確率で予測するよりも悪い精度ということになります。

今回は、上記の結果を基準に特徴量を増やした場合などの比較をしていきたいと思います。
明日以降に特徴量を増やした場合との比較を行なっていきます。

余談ですが、CTR 予測を行う機械学習のモデル運用では、オンライン学習や強化学習により、どんどんモデルを更新していく手法が取られており、これは、サイト ID や広告 ID なんかを入れて対応させていることも起因しているかなと思いました。

個人的な感想としては、Pythonの実行環境構築に苦戦しました。使っているライブラリのバージョンなどがかなり違っていたり、後々分かったのですが、Python3.6 系統でしか動かないものもあったのでこの辺りが大変でした。

3day : 時間帯、Wifi有無、表示端末の機種モデルなどの特徴量の追加による検証

Pythonの機械学習ライブラリのバージョンに苦戦しました。Jupyter Notebookのサーバを用意して頂いたので、そこに開発環境を移していると、自作ライブラリのインストールやバージョンの設定などで時間がかかってしまいました。

昨日行ったベース値に対して、特徴量を増やした場合にどの程度精度が向上するのかを試してみました。

特徴量を増やした結果（WIfi、時間帯、機種モデル）

model	N	pos. rate	Expecred click	AUC	log loss	mean entropy	NE	ECE
train	3,279,148	0.113428	0.113321	0.706092	0.321479	0.353622	0.909102	0.002886
test	4,042,439	0.002305	0.002538	0.701241	0.015553	0.016297	0.954351	0.000234

特徴量追加前 Test データの NE: 0.956, 特徴量追加後のTest データの NE: 0.954, 精度向上：0.002 程度でした。
モデルのせいもありますが、あまり精度が上がらなかったのが少しショックでした。
OneHotエンコーディングをした大量のカラムもある中で、それらと一緒に学習させた影響もあるのかも知れないです。大量の特徴量の項目に埋もれてしまって、学習がうまくいっていない可能性もあります。

気を取り直して、どんどん試していきたいと思います！

次に、あまり広告業界のことは知らなかったので、こんなことを試してみました。

Count エンコーディングによる特徴量の変換

仮説：よく表示されているほど、いいサイト（キャンペーン）なのでは？

この仮説に基づき、OneHot エンコーディングではなく、Count エンコーディングを行い、モデルを作成していきました。

Count encoding の結果(広告のID etc. + WIfi、時間帯 etc.)

model	N	pos. rate	Expecred click	AUC	log loss	mean entropy	NE	ECE
train	3,279,148	0.113428	0.116982	0.570453	0.352621	0.353622	0.997168	0.020263
test	4,042439	0.002305	0.001706	0.589540	0.016390	0.016297	1.005701	0.000866

結果としては、NEが悪くなってしまいました。
この時の結果を見て、少し気付いたのですが、
現在のモデルはサイトID なども入れており、クリックされやすいサイトを判断する特徴もとらえたモデルになっている可能性もあるんだなと感じました。

4day：Optuna でのパラメータ調整のプログラムの実装

特徴量抽出に関してはこれ以上深くせず、機械学習モデルのハイパーパラメータの方に力を入れていきました。
ライブラリとしては、Optunaと呼ばれるベイズ系の最適化を行ってくれる物を使用してパラメータの探索を行っていきました。

実装自体の際、Trial ごとのトレーニングデータに対するNEなどを Optuna の user_attrs を使って、保存できるとメンターの方に教えてもらい、それを元に、過学習しているのかなどを見ていきました。

探索

上の図がパラメータの最適化を行っていった時の誤差（NE）の推移です。
作業に時間がかかってしまい、 あまり試行回数を増やすことができませんでした。

大量のトラフィックデータの解析をするのは、今回のインターンが初めてなのですが、
Random Forest のパラメータ調整では、時間がかかりすぎたため、ロジスティック回帰の精度を上回るパラメータを見つけることができず、データ量が多いと、このような影響が出てくるんだなと思いました。

Random Forest のアルゴリズムでは、決定木を大量に作っていきますが、一本の木の一つの分岐を作る際、情報利得や不純度の計算に全てのトラフィックデータにアクセスするため、時間がかかるんだと思いました。
この辺りは、データ量がそこまで多くないと気になりませんが、今回のケースのように数百万件のデータを学習させる場合は、時間がかかると知りました。

夕方からは、パラメータの探索をさせてる間に、明日の発表資料づくりを頑張ってました。

5day：インターンの内容の発表会

お昼の時間帯に、他部署の社員さんも交えて、インターン内容の発表会をしました！

ファンコミュニケーションでは、幅広い年齢層の方がワイワイ話している感じでした。
機械学習というなかなか尖った分野の発表ですが、エンジニアの方以外も温かい眼差しで発表を熱心に聞いてくださいました。

感想：色々経験できて良かったです！

5日間という短い期間でしたが、実際の業務で機械学習を使用する現場に混ざることができてとても良かったと思っています。

実際のデータを分析して、特に勉強になった点としては、

• NN系のモデルを試すも、学習時間がかかり断念。（実際の用途ではRTBでは速度が大切と教えてもらった）
• OneHot エンコーディングするとスパースデータにしないとメモリが足りない
• IPアドレスから住所に変換するAPIを試そうとしたけど...
• ハイパーパラメータのチューニングに時間がかかった

が経験できて、よかったです！

ファンコミュニケーションズのインターンに参加しました！

はじめまして！京都で技術補佐員をやっている林と申します(秋から院生になります笑)。
今回は、9月9日~13日の１週間で、ファンコミュニケーションズで「広告配信システム(DSP)の構築」というインターンに参加させていただきました。このブログでは、インターンの参加までの流れから、インターンの内容や感想について書いていこうと思います。

インターン参加まで

この会社を知るきっかけにもなったのがサポーターズという会社が行なっている1 on 1 面談イベントでした。1番最初に面談をしてもらえたことがかなり記憶に残っています。このサポーターズでのイベントをきっかけに「そもそもアドテクって何？」「広告配信の裏側を知りたい！」と思い、このインターンに応募しました。オンライン面接での選考が行われました。
一度インターン参加確定になったのですが、私的な諸々の都合で日程をずらしていただき、9月9日から無事に参加させていただけることになりました。

前日から東京で宿泊していました。インターン中の宿泊先は外苑前という駅にあるホテル(神宮球場の目の前)だったのですが、そこが大変綺麗だったので、前日から一人でテンションが上がっていました笑。

インターンの内容

インターンの内容は、PHPを使ってminiDSPを構築する、という内容でした。最初は、「DSP???」という感じでしたが、初日に広告配信の仕組みを解説してもらい大枠を理解することが出来ました。気になる方は、「DSP SSP」とかでググると良い記事が沢山出ると思います。

具体的には、 SSPからのリクエスト(「Aというメディアが広告欲しがってるよ」、SSP)に対し、そのメディアの広告枠を買う金額を予測し(ここは対象外、ML)、最適な広告を決定して返す(「私たちはこの広告をこの値段で出すのが良いと思います」、DSP)という処理を実装しました。

初日

深夜に台風が関東を直撃した日だったので、会社には出社出来た数人しかいませんでした(運良く地下鉄は動いてた)。午前中は、書類の手続きと社内見学、SSP・DSPの説明、PCのセットアップ等がありました。
ランチは、入社して数年目の若手社員の方々と食べました。
午後は、メンターの人とオンラインで挨拶をした後(電車が動かなかったらしい)、仕様の説明や技術選定、開発のスケジュール等を話し合い、実際に開発に取り組んでいきました。

言語はPHPだったので素のPHPでも良いかなと思ったのですが、とりあえずAPIを光速で作りたいなと思ったので、自分が慣れているLaravelというフレームワークを使用しました。

その他、選定したものは以下になります。

• PHP (Laravel, Lumen, Slim4)
• Mysql 8
• Redis × 2
• Nginx
• Fluentd

これらを全てDockerにのせ、Docker-Composeで立ち上げられるようにしました。
その後、今回のAPI作成で関わるモデルのDB設計をして、実際にAPI作成の途中までを行いました。

Docker化には以下の参考サイトが非常に役立ちました！
qiita.com

2日目

2日目はひたすらAPIを作っていきました。リクエスト毎にMysqlに接続するのは無駄な処理なので、Predisを使ってRedisにキャッシュさせるようにしました。

また、DSPサーバーからMLサーバーへリクエストをする必要があるので、Guzzleを使用してリクエストを送るようにしました。しかしながら、MLサーバーを立ててないことに気づいたので、Slim4という軽量のフレームワークを使って簡易的に立てました。(Laravelばっかりでもね・・・)

メディアタイプや金額でフィルタリングをする必要があるのですが、それはLaravelで使われているCollectionクラスで実装しました。

インターンの課題に含まれていた、イベントに対してログを出すという仕様も実装しました。(Laravelは便利！)

結果として、2日目で仕様に書かれていたAPIやログは一応全て実装できました！！

3日目

コントローラーに処理を殴り書きしていたので、関数に切り出す作業を行いました。

また、運用を考え、1つのRedisで書き込みと読み込みを行うのは負荷が高くなるので、書き込み用のRedisと読み込み用のRedisに分けることにしました。(世に言うmaster-slave構成です)

3日目のお昼は社内で食事をしましたが、昼以降はとあるイベントのため帰宅となりました。

（3日目の午後は、私は渋谷に行ってカラオケと本屋で楽しんでました笑）

4日目

4日目は、Redisのmaster-slave構成を終わらせ、AWS上でメンターに用意してもらったSSPとの連携を行いました。

その後に、速度計測をすると想定よりも遅かったので、速度改善にシフトしていきました。
具体的に行ったことは、不要な処理を削除し出来るだけデータ操作回数を減らしたのと、Slim4をLumenというフレームワークに変えたことです。

これとは別に、ログをFluentdで集約するように設定しました。

最終日

仕様を満たしていない箇所があったので(ログにmsecを残す部分)、そこを修正しました。AWS上で動いているかを最終確認し、発表のためのスライドを作成していました。

発表には多くの社員さんが来ていただき、無事に終えることが出来ました。

その後は、このブログ記事を書いて終わりです・・・。(あっという間でした)

感想

広告全体の仕組みやその裏側の仕組み等、アドテクの基礎が理解出来るようになったと思います。実際の技術や仕組み等も見ることができ、自分でもminiDSPを作ることが出来たのは大きな収穫だったなと思います。また、インターンを通して、自分が慣れている技術(Laravel)だけでなく、慣れていない部分(Docker, Redis, Lumen)にも触れられたので大変良かったです。

会社自体で言うと、とてもフレキシブルな会社だなと思いました。リモートで作業している社員さんが多いだけでなく、出勤・退勤時間も裁量労働制なのでかなり自由です。自分に合った働き方が出来る会社で素晴らしいなと思いました。

メンターさんについてですが、かなり優しく接して頂いたという印象です。技術的なことからサービス的なことまで、色んな質問に答えていただき非常に勉強になりました。

まとめ

インターンに行くことで会社の中の雰囲気を感じ取ることが出来て非常に良かったと思います。
また、アドテク自体への興味もかなり深まったので、個人的には最高に良かったインターンだと思いました。

短い間でしたが、インターンに受け入れていただき、また多くのサポートをしていただき、本当にありがとうございました！

ネット広告CTR予測業務体験記

データ分析コースのインターンシップに参加させていただいた大庭です。 今回はデータサイエンティストとしての働き方を間近で体感するためにインターンに応募しネット広告のCTR予測について5日間取り組みました。

CTR予測とは

ネット広告が表示される流れとして、ユーザがサイトに訪問したときに広告リクエストがアドネットワークに送信されます。 そのリクエストに含まれる情報により、広告主側が入札金額を決定し、その入札に勝った広告主の広告がサイトに表示されます。

このとき、広告主側は当然クリックの確率が高いユーザへ広告を流したいので、リクエストに含まれる情報から広告が表示されたときのクリックの確率を予測するというのがCTR予測です。

CTR予測の流れ

1. DBからデータを取得する
2. データを特徴量に変換する
3. 特徴量をモデルに入力し、学習させる
4. 評価

本記事では2~4について言及していきます。

2. データを特徴量に変換する

DBから取得したデータを予測に役立ちそうな形式(特徴量)に変換します。 例えば、DBにtimeと呼ばれる広告が表示された時刻を記録したデータがある場合、hourのような時間帯の情報に変換したり、土日か平日かなどに変換するといったことが挙げられます。

今回私は、

• 広告の表示時間から時間帯を抽出
• 広告開始から何日経っているか
• wifiの有無
• 貰った処理例から変数を減らす

などを検討しました。

3. 特徴量をモデルに入力し、学習させる

2で変換した特徴量を機械学習のモデルに入力、学習させます。

モデルには

• 主成分分析
• ロジスティック回帰

を用いました。 カテゴリカルな変数が多く入力次元数が数千となったため、主成分分析で次元圧縮を行い、ロジスティック回帰に入力しました。

• 学習データ: 2019年8月の連続する平日3日間
• テストデータ: 学習データの次の日(平日)

しかし、実データが膨大かつ不均衡 (クリック率がとても低い) なので処理の負荷を考えて 、学習データに関しては負例を一定割合取り除き (ダウンサンプリング) 、テストデータに関しては正例・負例を問わず一定数割合取り除き (ランダムサンプリング) ました。

ちなみに、今回はテストデータ (1日分のデータ) は5%を残すランダムサンプリングをしたのですが、それでも膨大なデータが残っていました。

また、ハイパーパラメータの探索にOptunaを用いました。

4.評価

CTR予測ではクリックされる確率を予測したいのですが、データに存在するのはクリックされているかの 0/1 データしかないので、適切な評価指標を定めにくいという問題があります。 そこで、予測確率と正解ラベルのないクリック確率の近さを測るキャリブレーション精度により評価します。(こちらの記事をご参照ください。)

結果

	期待キャリブレーション誤差
最初に貰った処理例の結果	0.00033
改良した処理の結果	0.00022

最初に貰った処理例の結果

改良した処理の結果

期待キャリブレーション誤差の結果、私が改良した処理の結果の方が誤差が小さいですが、キャリブレーションカーブを見ると対角線から離れたグループがより見受けられる結果となりました。 深くは検証していませんが、貰った処理例で使われている変数を減らしたのと、主成分分析が結果に出たかなと思っています。

今回はここで時間切れでしたが今後の展望として、 ロジスティック回帰以外のモデルの検証 特徴量の検討 を行いたいです。

本番サーバを止めてみたよ。

参加した経緯

某マッチングイベントで仲良くなり、５日間のインフラ系インターンに参加させていただいた。

私は誰なのか

飛田一貴(通称: かずきち)です。
大阪の専門学生で、しがないWebエンジニアをやっています。
インフラは素人に毛が生えた程度にしか分かりません。

なぜインフラ系のインターンを選んだのか

今まではWebを中心にやってきましたが、自分のスキルの幅を広げたかったからです。

何をやったのか

端的に言うと、本番環境で動いているサーバを止めてみました。
それに至るまでにサーバの構成や役割、ユーザからのリクエストがどう流れているか等を調べ、最終的に「止めても問題ない」と判断できたサーバを止めました。

技術的な話

インフラの細かい構成の話とかをすると怒られそうな気がするので、代わりに技術調査メモをいい感じにまとめてここに貼り付けておこうかなあと思います。

sysctl

sysctlはLinuxカーネルのパラメータを確認したり変更したりできるコマンド。
カーネルの再構築が不要で、コマンドで動的に動作を変更できる。

systemctl

sysctlと似ているが別物。
systemctlはsystemdを操作するコマンド。
サービスのステータスを確認したり、設定したりできる。
CentOS 6まではserviceというinitをいじくるコマンドが用意されていたが、CentOS 7からはsystemdが採用されたためsystemctlを使うようになった。
systemctl <operation> <unit_name> の形式で操作できる。

journalctl

systemdの動作している環境では、標準のログ(≒ジャーナル)収集・格納サービスとしてjournaldが用意されている。
journaldの操作は journalctl コマンドで行う。
よく使うオプションとして、ジャーナルを流し続ける -f や指定したサービスのジャーナルに絞る -u <unit_name> がある。

rsyslog

rsyslogはsyslogというログを転送するための仕組みに信頼性(reliability)が担保されたもの。
TCPで転送できるようになったらしい。

LVS

LVSはLinux Virtual Serverの略。
レイヤ４で動作するロードバランサ。
正確には、Linuxカーネルに組み込まれているIPVS(IP Virtual Service)というロードバランサの実装を用いて作ったクラスタのことを指している。
LVSの設定や操作には、 ipvsadm か、それをさらにラップした keepalived を使用する。

ipvsadm

あんまりよく分かっていない。
ipvsadm -Ln というコマンドでリアルサーバのweightとかアクティブなコネクション数、インアクティブなコネクション数を確認できた。
このコマンドでリアルサーバの生死を簡易的に判別できる。

keepalivedの設定

ここの設定を一番読んだ気がする。

リアルサーバ

リアルサーバとは、仮想サーバに関連付けられた実際のサーバのこと。

ウェイト

重み(weight)はヘルスチェックが成功/失敗する度にプライオリティをどれだけ上げるかとかそういう設定っぽい。
weight というパラメータに対して設定する。

ヘルスチェック

リアルサーバが生存しているかを確認するリクエスト。
delay_loop というパラメータに対してヘルスチェックを送信する間隔を設定する。

ヘルスチェックでどんなリクエストを送信するかを設定することができる。
例えば以下のように記述すると、 /foo.html に対してGETリクエストを送信し、HTTPステータスが200かどうかを確認する。

HTTP_GET {
  url {
    path /foo.html
    status_code 200
  }
}

タイムアウト時間

connect-timeout というパラメータに対して設定する。
ここで設定された秒数の間、ヘルスチェックが失敗するとリアルサーバがダウンしたと判断する。

再試行間隔

リアルサーバがダウンしている場合のヘルスチェックを再試行する間隔。
delay_before_retry というパラメータに対して設定する。

ヘルスチェック失敗時

ヘルスチェックに失敗した場合にweightを0にする設定として、 inhibit_on_failure という設定がある。

スケジューリングアルゴリズム

どのようにロードバランシングするかの種類(スケジューリングアルゴリズム)の設定。
lvs_sched というパラメータに対して設定できる。

スケジューリングアルゴリズム	説明
rr	ラウンドロビン(round-robin)アルゴリズム。リアルサーバを設定順に選択する。全てのサーバに均等にトラフィックが分散される。
wrr	weight round-robin。rrにweightによる重み付けを加味したもの。
lc	least connection。コネクション数が一番少ないサーバを選択する。
wlc	weight least connection。lcにweightによる重み付けを加味したもの。(コネクション数 + 1) / weight という計算式によってサーバが選択される。

SSL化していると、暗号化/復号化にそれなりの処理が必要なため、複雑なスケジューリングアルゴリズムを選択するとリクエストを処理しきれなくなることがあるらしい。
ちなみにスケジューリングアルゴリズムは他にも色々あった。

ステート

state というパラメータに設定する。
MASTER とか BACKUP がある。

転送方式

lvs_method というパラメータに設定する。
nat はNATで、LVSでアドレス変換をして返す方式。
dr はダイレクトルーティングで、LVSを介さずに直接クライアントへ返す。
ダイレクトルーティンではLVSの負荷が軽減されるというメリットがある。

感想

いつもと違う技術領域に触れることができたため、新鮮で刺激的でした。
また、現場で働いているインフラエンジニアの方から適切なアドバイスを貰うことができるため、効率的に学ぶことができました。
フロントエンド、バックエンド、インフラ、ネットワークと様々な技術領域やレイヤを扱うことのできるつよつよエンジニアを目指していきたい。

インターン：実業務体験編

　9/2~9/6インターンに参加させて頂いたYです。本名を言うのが恥ずかしいので、MIB風の名前でお許しください。

　最近は歴史ものにハマっていて、今回のブログは宮本武蔵が書いていた五輪書のような構成で書かせていただきたいと思います。

地の巻：参加するまでの経緯

　まずは簡単な自己紹介をさせていただきたいと思います。私は現在情報理工学を勉強している大学院1年生です。本当は意識高い学生みたいな感じで書きたかったのですが、正直に話すと、今年の4月に入ってから

=============================================
なんとなくそろそろ就活を動きださないマズイなと思い始める
　　　　　　　　　　↓
なんとなくCodesprintというエンジニア就活向けのサイトを知る
　　　　　　　　　　↓
なんとなく逆求人イベントに応募してみる
　　　　　　　　　　↓
なんとなくファンコミュニケーションズさんに声を掛けていただく
　　　　　　　　　　↓
なんとなくwebサービス開発に興味があって参加してみた
=============================================

という全く参考にならない意識低い学生でした。でも元々物作りや新しい技術を勉強することが好きで、せっかくこのような勉強させていただく機会があるから、参加しないと絶対後悔すると思い、お話しを頂いたとき、即参加すると決めました。

水の巻：一週間の流れ

　今回私が参加したのは実業務体験コースで、社員さんが普段実際にやられている仕事を一緒にやるという感じでした。事務作業を含むこの一週間の大体のスケジュールは以下のようになります。

• 月曜日：入社手続き　社内見学　開発環境の設定
• 火曜日：タスク①の開発作業
• 水曜日：タスク①のリリース作業
• 木曜日：タスク②の開発作業
• 金曜日：退社手続き　ブログ作業　一週間の成果発表

　最も仕事密度が高いのは火水木の三日間でした。長いように思われますが、新鮮な体験ばかりで、三日間合わせた体感時間は6時間半くらいで、本当にあっという間って感じでした。ちなみに、ブログを書いている金曜日11時20分現在では、午後の成果発表の準備は13%くらいしかできていません。ちゃんと発表できるか正直凄く不安です。

火の巻：主にやったこと

　今回はファンコミュニケーションズさんのサービスであるnendに関する開発業務を二つやらせていただきました。実際に書いていたコードや詳しい開発画面をお見せできないので、雰囲気で感んじていただければと思います。

①情報を削除する際に警告を出す

　お客さんが間違って必要となる情報を削除してしまって復元してほしいという報告を受け、このような依頼がきました。具体的には、削除ボタンを押したあとに、「本当に削除して宜しいでしょうか」みたいな警告を出すという仕組みを作る仕事でした。使い慣れていない開発環境やプログラミング言語もあったのですが、無事に期間中にリリースができて凄く達成感を感じました。

②検索機能に新たな検索項目を追加する

　文面通りに検索機能の項目一覧に新たな検索項目を追加する仕事でした。最初はそれほど難しい内容ではないと思っていたのですが、途中に開発要求の仕様変更があったり、変更したコードが別のところにも使われていることが判明し、やり直すことになってしまったり、思っていた以上に時間がかかってしまい、苦労しました。でも、これもエンジニアの醍醐味だと思うので、結構楽しんで作業をしました。残念ながらインターン最終日の金曜日は基本リリース禁止なので、インターン期間中にリリースすることができず、ちょっとした心残りです。

（追記）※ 上記の機能、無事にリリースできてました！

風の巻：感じた雰囲気

　今回のインターンに参加する前は、IT会社の社員さんはＴシャツジーパンで、パソコン画面とにらめっこしながらキーボードをガチャガチャするという勝手なイメージを持っていました。実際にファンコミュニケーションズさんで一週間働いてみたら、「あっ、思ってた通りなんだ。本当にそうなんだ」と、イメージが覆されませんでした。でも、これはだらしないとかチャラチャラしているとかの悪い意味ではなく、嫌な緊張感がないリラックスしている状態で仕事できる環境が整えられているという意味です。
　また、モブプロという開発チームの皆さんが一緒にプログラミングをする会にも参加させていただきました。より良いサービスを提供できるように、皆さんが意見を出しあいながら、共にさらなる高みを目指して頑張っている感じは個人的に凄く好きです。内容は難しく、正直全てを理解することができませんでしたが、社会人の仕事スタイルも含め、勉強になったことがたくさんありました。

空の巻：感想&今後について

　私はエンジニア就職希望なので、今回のインターンを通して、エンジニアが普段どのような感じで仕事をしているのかをかなりイメージを掴みました。まだまだかじった程度に過ぎないですが、PHPやDockerなど、新しい技術も勉強できて、本当に大変有意義な一週間でした。一方、メンターさんがいないと、とても一人でできるとは思えない仕事なので、自分の実力不足を痛感しました。
　これから本格的に就活が始まると思うので、今回の経験を糧にして就活頑張っていきたいと思います。短い間ですが、本当にお世話になりました。ありがとうございました。