インターンでCloud Runに挑戦した話

エンジニアインターンとして約1ヶ月アカツキで就業したyasuさんの体験記をお届けします。来年4月に入社予定のyasuさんですが、今回の経験で入社までの課題も見えてきた様です。

はじめまして、yasuといいます。
今回私はアカツキで内定者インターンに参加させて頂きました。
期間は1ヶ月ほどでしたが、色々と貴重な経験をさせて頂けたので具体的にどのようなことをしたのか紹介して行きたいと思います。

自己紹介

私は現在、大学で経営工学を学んでいる4年生です。
普段は趣味でGo言語を主に触っています。
Go言語で主にやっている事としては研究室のSlackボット開発や自分用のブログエンジンの開発、ハッカソンなどでネイティブアプリ用のAPIの開発などです。
最近はOSのカーネルやコンパイラなどソフトウェアの中でも低いレイヤーに位置する技術に興味があります。
新しいものが好きです。

きっかけ

きっかけは逆求人イベントでした。
逆求人に参加した際に会社訪問に誘われ、そのまま選考 => 内定 => インターン参加という流れです。
大学3年生のころに一度インターンに参加したことがあり、アカツキの技術に対する挑戦的な姿勢や「なぜ？」を大切にする社風、オフィスの快適さに惹かれてすぐに内定承諾とインターンに参加することを決めました。

何をしたのか？

今回は面接の際にお世話になった坂尾さんの所属するゲームの基盤開発チームでお世話になり以下の3つのタスクをこなしました。

• 基盤の管理システムのCloud Run移行
• 基盤の管理システムの操作ログのBigQueryからStackdriver Loggingへの移行
• アプリケーション側でのIP制限機能の追加

今回利用したCloud Runについて

公式の説明ではRun stateless HTTP containers on a fully managed environment or in your own GKE cluster.と書かれています。
Google Cloud Next ’19で発表されました。
Knativeをベースにしたサービスで、オートスケールの機能やインフラ周りの設定の自動化などが特徴です。
Cloud Run ではContainer Imageさえあれば、その他の設定はほとんど自分でせずにデプロイできます。
公式ではCloud Buildを使ってContainer Imageをビルドしているので今回はCloud Buildも合わせて利用します。

基盤の管理システムのCloud Run移行

今回のインターンの大本のタスクです。
もともとGAE FEで動いていた基盤の管理システムをCloud Runへ移行します。
このタスクをこなすために次のフローを踏みました。

1. アプリケーションのCloud Runでの動作確認
2. Cloud Run へCircleCIでデプロイするようにする

アプリケーションのCloud Runでの動作確認

もともとGAE FEを使用していたので既にアプリケーションを動かすためのDockerfileが存在しました。
これをドキュメント通りにCloud Buildでimageをビルドしてgcloud beta run deployをするとすんなりとデプロイ出来ました。

また、GAE FE上でシステムを動かしていた際にはこちらのイメージを使っていたのですが、余計なパッケージを含まないようにDockerオフィシャルのPythonイメージを使うようにDockerfileを修正しました。

Cloud Run へCircleCIでデプロイするようにする

管理システムはCircleCIを使ってデプロイを自動化していたのでCircleCIのconfigファイルを修正する必要がありました。
具体的にはGAE FE向けに書かれていたconfigファイルをCloud Buildを使ってイメージをビルドし、Cloud Run へデプロイするように書き直す必要がありました。
gcloud build submitコマンドでイメージをビルドし、gcloud beta run deployコマンドを使ってCloud Run へデプロイするよう修正しました。

システム操作ログのStackdriver Loggingへの移行

管理システムの監査のための操作ログを、もともとは BigQuery に書き込んでいました。 これを Stackdriver Logging へ移行しました。
このタスクでは次の事を行いました。

1. Cloud Run 上でStackdriver Logging の構造化ロギングが動くことの確認
2. ログのデータ構造を定義する
3. 構造化ログを吐くように操作ログのコードを修正する
4. ログをRequestログと紐づけて表示できるようにする

Cloud Run 上でStackdriver Logging の構造化ロギングが動くことの確認

Cloud Run では 標準出力・標準エラー出力などにログを書き込むことで、 Stackdriver Logging に自動で集約されます。 またJSON文字列でログを書き込むことで Stackdriver Logging の LogEntry に jsonPayload として格納されます。
これを構造化ログと呼びます。
今回はこちらを使用して操作ログを記録することにしました。
参考 Using simple text vs structured JSON

print('{"sample": "hello"}')

実際に上記のようなJSON文字列でログを標準出力に吐くとLogEntryのjsonPayloadに入り、無事に構造化ロギングが動くことを確認できました。

ログのデータ構造を定義する

操作の際に送信されるパラメーターと送信元と送信者を特定するメタデータをログの構造としてまず定義します。 今回は操作ログなので操作内容と実際に操作しているユーザーのemailなどのメタデータをログのスキーマとして定義しました。

構造化ログを吐くように操作ログのコードを修正する

その定義していた構造通りにJSON文字列をログとして出力します。
今回はFlaskのapp.logger(python標準のloggingライブラリ)を使って標準エラー出力へJSON文字列を吐き出すようにしました。

ログをRequestログと紐づけて表示できるようにする。

Requestログとの紐づけは次の資料を参考にしました。

https://cloud.google.com/run/docs/logging#correlate-logs

In the Stackdriver logs viewer, logs correlated by the same trace are viewable in "parent-child" format: when you click on the triangle icon at the left of the request log, the container logs related to that request show up nested under the request log.

Container logs are not automatically correlated to request logs unless you use a Stackdriver Logging client library. If you want this correlation without using a client library, use a structured JSON log line that contains a trace field with the content of the incoming X-Cloud-Trace-Context header. Then your logs will be correctly correlated to the request log.

https://cloud.google.com/logging/docs/agent/configuration#special-fields

logging.googleapis.com/trace is stripped from jsonPayload and assigned to the LogEntry trace field. For example, assume the value of logging.googleapis.com/trace is [V]. [V] should be formatted as projects/[PROJECT-ID]/traces/[TRACE-ID], so it can be used by the Logs Viewer and the Trace Viewer to group log entries and display them in line with traces. If autoformat_stackdriver_trace is true and [V] matches the format of ResourceTrace traceId, the LogEntry trace field will have the value projects/[PROJECT-ID]/traces/[V].

飛んでくるRequestからHTTP HeaderにあるX-Cloud-Trace-Contextの値を取ってログとして吐くだけです。

ちなみにX-Cloud-Trace-Contextは
X-Cloud-Trace-Context: TRACE_ID/SPAN_ID;o=TRACE_TRUE
というフォーマットになっているので
/以下を取り除いてTRACE_IDだけ抽出する必要があります。
このTRACE_IDをログとして吐くJSONのlogging.googleapis.com/traceキーのバリューとして設定します。
そうするとLoggingエージェントが収集し、LogEntryのtraceフィールドに自動的にTRACE_IDを設定してくれます。
これでStackdriver Loggingでリクエストログと紐付き、まとまったログとして見る事ができます。

アプリケーションへのIP制限機能の追加

今回の基盤の管理システムは社内用ツールであるため社外からアクセス出来ないようにする必要がありました。
GAE FEではGAEのfirewallの機能でIP制限をしていたのですがCloud Runでは現時点でそのような機能が提供されていませんでした。
なので、今回はアプリケーションレイヤーでIP制限機能を実装することにしました。

最初は Flask の request.remote_addr の使用を試みてみたのですが、 Cloud Run にデプロイすると、これには Google Frontend の IP アドレスが設定されるということがわかりました。
X-Forwarded-For には Google Frontend がクライアントの IP アドレスを付与してくれていたため、こちらの IP アドレスを使用してアクセス制限機能を実装しました。

Cloud Run を実際に使ってみて

学習コストが低いので初学者でもすぐに始められて良いと感じました。
インフラ周り初心者の私でもすんなりデプロイできたのでの学習コストはかなり低いなと感じました。
また、デプロイをすれば設定など何もすることなくスケーリングなどのサーバー全般の管理をGoogleがやってくれるのでかなり便利だと感じました。

インターンで学んだこと

何をするにも なぜ？ そうしたのか深堀ること。

インターン中一番改善しなきゃいけないと思った点はこれです。 どのタスクの際にも技術を理解せずに突き詰められていた事が多かったと思います。 例えばシェルスクリプトでShebangを使っているのにshコマンドを使っていたことがありました。

また、traceの設定の仕方もドキュメントを読めばしっかり書いてあるのに網羅的に読まなかったせいで見落としていたりしていました。 プルリクエストで詰めて頂いたおかげでかなり勉強になったので凄く感謝しています。 理解しないで実装するのは結局はバグや脆弱性を生み出し非効率なので一番自分が成長しなければならない部分だと感じました。

チーム開発でのコミュニケーションの大切さ

普段私はハッカソンや個人開発を主にしていたこともあり一人よがりな開発をしがちです。 そのせいで今回、妙に一人で抱え込んだりして余計に時間をかけたり心配をかけてしまったりしていました。 開発の効率にも関わる問題なので普段からのコミュニケーションも大切にしていきたいなと感じました。

良かったこと

新しい技術に挑戦できた！

他社でのインターンやバイトは自分のできる技術をベースにできることを任されることが多かったです。 しかし今回のインターンではCloud Runという発表されて間もない新しい技術を触らせて頂いた上にインフラ部分の移行を任されるという大きな課題に挑戦できたので他では体験出来ない有意義な経験が出来ました。 プルリクエストのコメントも議論が活発でそこから学べる事も沢山あったので凄く感謝しています。 今までのインターン経験上一番悩んで、一番楽しかった１ヶ月でした。

働きやすい環境が用意されている！

アカツキさんのオフィスではみんなが楽しんで仕事をしている雰囲気があり、オフィスも働きやすい設備(バリスタが常駐してたりとか休憩スペースが用意されてたりとか...etc)が整っていたので非常に働きやすかったです！ 私の経験上一番働きやすい環境だと思いました。

最後に

2年前にアカツキでインターンをした際も感じたのですが、アカツキの働きやすさを改めて実感できた1ヶ月だったと思います。 インターン生が行うタスクに関しても他では経験できない裁量が与えられる非常に有意義なものでした。 また、今回のインターンで入社するまでのあと半年で解決すべき私自身の課題も見えてきたので半年後には進化した姿でまた戻ってこれるように精進したいです。 今回色々と見て頂いた坂尾さん、田中さん本当に感謝しています。

長々と書いてしまいましたが最後までお付き合い頂きありがとうございました！

インターンでミニゲームづくりに挑戦しました。

エンジニアインターンとして2週間アカツキで就業したkeiwさんの体験記をお届けします。ゲーム開発は経験があったものの、これまで触れてこなかったUnityでの開発。課題としてミニゲームづくりに挑戦してもらいましたが、どのような学びがあったのでしょうか。今回はその様子をご紹介します。

こんにちは、２週間ほどインターン生としてお邪魔させていただきましたkeiwです。

今回、２週間で、ちょうど企画フェーズにあったバッテイングセンターのミニゲームをインターンテーマとして挑戦させて頂きました。今後、ハチナイ開発チームによる改修などを経て実際ゲームに登場するかも、とのことですが、自分が作ったものの何割が残れるか楽しみです。

この記事では、そのインターン体験記的なことを書こうと思います。（拙い文章ですが、お付き合いください^^;）

以下、目次です。

インターン開始まで

インターン開始まであと１ヶ月のとき。UnityとC#、GitHubをさわってくるように言われました。ゲーム作りはそれまで、バンバンやってきたのですが、それらはノータッチ。やってきてねと言われたリストは一応一通り試したのですが、他の用事などもあって十分にはさわれず、不安しかありませんでした。

インターン開始！

不安（と期待もあった）を胸に始まった初めてのインターンでしたが、自分が配属されたチームは会社っぽいというよりは雰囲気は高校の部活という感じで、技術的な不安以外はだいぶ緩和されました。ほとんどの読者には伝わらないと思いますが、とくにアイスブレイク担当を指名する愉快な茶番は面白かったし、そのアイスブレイクの内容自体もけっこう面白かったです。スターウォーズ昼食会などもよかったです。

壁、壁、壁！

初めての事ばかりで、当然壁にもぶち当たりました。

まずは、技術的な問題。雰囲気はよかったものの、やはり技術的な不安は的中してしまいました。１か月前からある程度さわってきたとはいえ、ほとんど初心者のUnityやGitHub。けっこう苦戦しました。何よりもMacPCには準備期間もなく、最後まで慣れなかったですね。（普段使っているWindowsやUbuntuもデキるわけではないのですが^^;）

また、今まで個人で何本かゲームを作ってはいたのですが、企画もイラストもコードも全て一人でやってきて、ゲームの内部的なところを人にみてもらうのは初めて。特にプログラムは１か月後の自分が再び編集し始められる程度を目安に書いていたので、人に読んでもらうことを前提とした書き方はなかなか難しかったし、恥ずかしかったです。ただ、細かく丁寧にコメントをしてもらえ、恥ずかしさによる抵抗感はすぐに消えました。

成果報告（一応メイン）

先ほど述べた通り２週間でミニゲームをつくることになりました。
ボールが飛んでくる。タイミングよく打つ。飛距離がスコアになる。というバッティングセンターを模したシンプルなゲームをつくりました。以下にゲームの使用を簡単に説明し、できたゲームのスクショにコメントを添える形で成果報告とさせてもらいます。

簡単な仕様

初めて見た現場の仕様書。ちょっと感動しました。

かなり簡単に書くと、

　１：画面内にいるバッターのストライクゾーンめがけてボールが飛んでくる
　２：それを画面をスワイプすることで打ち返す
　３：スワイプのタイミングと位置に応じて飛距離（スコア）が決まる

というもの。これを10球１セットで遊びます。イメージ図もあり、非常にわかりやすく、また作る前からワクワクしてました。

簡単なフロー

下図のように状態遷移させることで実現させました。

・「初期化１」

　１０球ごとに初期化が必要なものの初期化

・「初期化２」

　１球ごとの初期化

・「準備OK？」

　ボールがいきなり投げられるのを防止。タップで「メイン」へ

・「メイン」

　高スコア目指してバッティング！
　スコア計算はスワイプ終了直後にされる

・「ヒット」

　バッティング成功したら、キャラのカットインが入り、
　スコアがカウントアップするシーンが入る

・「空振り」

　バッティング失敗。タップで「初期化２」に戻り、もう一度トライ！

・「結果」

　今回のスコアを表示。

・「最終結果」

　今回で最高スコアと今までの最高スコアを表示。

プレイ画面

「メイン」の画面です。主に右下の赤い十字めがけてボールが飛んできますが、ボールは少しブレます。ボール到達直前に青い十字が出るので、出来るだけ近い位置で指を離そう！

「ヒット」のカットインです。バッティングに成功すると見れます。さらにスコアによって効果音が変わります。

「最終結果」です。記録更新を目指せ！

スコア計算

スコア計算に使う主な要素は３つで、その要素を掛け合わせることでスコアを決定しました。

・スワイプで指を離すタイミング

・スワイプで指を離す位置

・スワイプにかける時間

工夫・苦労した点

工夫・苦労した点はやはりスワイプの判定です。きちんとスワイプしたかどうかの判断は４つのチェックポイントを設け、順に通過させた場合のみ、きちんとバッティングしたと判断するようにしました。通過したチェックポイントは色を濃くするようにし、次回へのフィードバックができるように工夫してあります。

他にも指を離した位置に白い十字マーカーを置くことでも、失敗しても「次こそは」と思えるようにしてあります。

また、タイミングの判定が悪ければ、面白くならないどころか、理不尽さにイライラしてしまうだけので、タイミングの判定にも工夫をしました。スワイプを終了すべき正しいタイミングを把握するために、発射されたボールの位置を把握してストライクゾーンをいつ通過したのかを把握するのではなく、ボールがストライクゾーンに到達するまでの時間を変数でおき、その変数に応じてボールを動かす感じ（変数が０の時がストライクゾーン通過中）で、正確なスワイプを終了すべきタイミングを得ました。

成果報告は以上です。

慣れないツールで、２週間は短かった。やり足りない部分もありますが、自分自身ワクワクしながらでき、先日の簡単なお披露目会では楽しそうにやってもらえたので、おおよそ満足。

反省・その他

初めての場所で初めての事ばかりで緊張しまくりの状態。集中したらちょっと周りが見えなくなる性格もあいまって、雑談とかはあまりできなかった。ちょっともったいなかったなぁ。


今後、同じようなインターンを受ける場合、ただ絵を画面に表示させるだけなどの何もしない状態でも実機で試すまでの一連の流れを３日目くらいまでにやるべきだったかなぁと。

色々とギリギリだった今回のインターン、デザイナーさんに絵素材をお願いする機会もあったのですが、背景絵を翌日にもらえないかと無茶な依頼もしました。でも、翌日にはハイクオリティの絵素材が！　感謝するとともになんか感動してしまいました。

最後に

サポートしてくれたメンターさんをはじめとする野球チームの皆さんや、人事・総務の皆さん、非常に濃密な２週間をありがとうございました。

初めてのインターンがここでよかったです！

【LT会】Akatsuki Geek Live開催レポート！Vol.2

こんにちは、エンジニア採用担当の花田です。

元号を跨ぐ大型GWも終えましたが、去る4/26（金）に学生向けLT会「Akatsuki Geek Live Vol.2」を開催いたしました！

2月の初開催に次ぐ、2度目の開催となりましたが、今回もリピーターを含む約30名の学生の方に集まっていただき、序盤から大いに盛り上がりました！この記事では、その様子を紹介いたします。

 「Akatsuki Geek Live」とは...

学生エンジニアと、アカツキエンジニアが登壇するLT会です。今回は学生3名、アカツキメンバー5名の計8名が発表しました。その後、参加メンバーで懇親会を実施、学生同士やアカツキメンバーとの交流をいたしました。

▼イベント概要はこちらから

aktsk.connpass.com

▼なぜLT会を開催するに至ったのか

初回の開催レポートに開催の思いを綴っていますのでご興味ある方は、こちらから

hackerslab.aktsk.jp

 #当日の様子

前回、前半のLT会はかなり真面目な雰囲気で進んでいき、後半の懇親会では、わいわいと盛り上がりました。それはそれで良かったのですが、今回は序盤から更に盛り上げていきたいと思い、LT会スタート時から参加者の方にドリンクを取っていただきました。カジュアルな空気で開始したこともあり、Twitterも序盤から活発に動く中、早速スタートです。

▼1人目：@3nan3さん（アカツキ）

「Ruby/Railsで、key-valueなオブジェクトから値を取得するイディオム」

1人目は、アカツキメンバーから！Ruby on Railsで「おれはHashから値を取り出したいだけなんだ！」という熱い思いを語ってくれました。

発表資料

qiita.com

▼2人目：@カレーエンジニアkomaiさん（アカツキ）

「世界最大級のゲームカンファレンスGDCって何？どんな雰囲気なの？どうやったら行けるの？」

2人目もアカツキから、絶品カレーを振舞うエンジニアが3月にサンフランシスコで開催されたGDC 2019の紹介をしてくれました！

発表資料

speakerdeck.com

▼3人目：@諏訪さん（アカツキ）

「What's "Google Cloud Next"?」

3人目もアカツキから諏訪さん。GDCに続いて、4月にサンフランシスコで開催されたカンファレンスの参加レポートを紹介！

発表資料

speakerdeck.com

▼4人目：@きょーまさん（アカツキ）

「C#のリフレクションを使ってみよう」

4人目はアカツキ枠からきょーまさん！C#のリフレクションについて基本的な使い方と便利な使用方法を紹介してくれました。

発表資料

speakerdeck.com

▼5人目：@yasu0327さん（学生）

「ゼロから始めるGo Modules」

5人目は学生枠からyasu0327さん。Go Modulesの管理機能とその流れを紹介してくれました！最近Goに取り組まれている学生さん多いですね！

発表資料（speakerdeckには代理で登録しています）

speakerdeck.com

▼6人目：@給前さん（アカツキ）

「Unityエンジニアを目指す方が、学生のうちに学んでおいてほしい技術」

6人目はアカツキから、Unityエンジニアを目指す方向けに、自身の学生時代の学習方法・内容を交えながら語ってくれました。勉強量がとにかくすごい。

▼7人目：@Matts966さん（学生）

「Go言語で書くLispインタプリタ」

7人目は学生枠からMatts966さん！この発表では特に「タイトルがもう強い」「Lispインタプリタすごい」とTweetが盛り上がっていました！

発表資料

▼8人目：@takanakahikoさん（学生）

「学生がOSSに挑戦するということ」

トリを務めるのは学生枠よりtakanakahikoさん！OSSへの挑戦について語ってくれました。実は私も彼が作った拡張機能を使わせて頂いています！

発表資料

speakerdeck.com

8名による熱のこもったの発表はあっという間にすぎ、懇親会へと移ります。

今回も学生 x アカツキメンバーの交流が盛んで、至るところで笑い声が聞こえました。中にはセグウェイに乗りながら懇親会に参加するメンバーも笑

参加者のみなさん、お疲れ様でした！

今回、アカツキの技術領域の話はもちろん、海外カンファレンスの話や、学生同士の交流を通して、これからの一歩を踏み出す一つのきっかけとなったのではないでしょうか。

次回は7/1（月）に開催予定です！またエネルギー溢れる皆さんにお会いできることを楽しみにしています^^

 ▼次回予約はこちらから

aktsk.connpass.com

RubyKaigi 2019 に SAKE Sponsor として参加してきました！

こんにちは、18卒で入社したサーバサイドエンジニアの氏平です。
普段はゲームコンテンツの運用をしています。

アカツキが4/18(木)〜20(土)に福岡国際会議場で開催された、RubyKaigi2019 に SAKE Sponsor（Platinum）として参加してみてきましたのでレポートをしたいと思います！

はじめに

アカツキでは Ruby on Rails を使用して、ゲームのサーバーサイド（APIサーバ・管理画面・インフラ）の開発・運用を行っています。普段業務で使用している言語の最新の情報をキャッチアップしてこようと今回 RubyKaigi 2019 に参加しました。
アカツキからは８名の参加です。

RubyKaigi とは

Ruby の中で最大級の国際会議。 

rubykaigi.org

世界中からコミッターや開発者が集まり、Ruby の新機能の情報や開発事例などが紹介されます。
RubyKaigi 2019 では主に 現在開発中の Ruby 2.7 と Ruby 3.0 の機能紹介が行われました。

アカツキブース出展

今年はアカツキとしてスポンサーブースも出展したので紹介させていただきます！

アカツキから配信している「八月のシンデレラナイン」（通称ハチナイ）をベースにブースを出展しました。
野球盤を用意し*1ヒットを打てた方にオリジナルカレーをお渡しするというゲーム形式です。 

ハチナイのアニメもちょうど４月から始まり、見てくれた方もいたので楽しくコミュニケーションを取ることができました。

Matz さんもブースに来てくださって、オリジナルカレーを持って帰っていただきました！

SAKE Sponsor として参加して

RubyKaigi の後、毎夜パーティーが開かれました。
その中で RubyKaigi 2019 Official Party で我々がスポンサリングしたお酒が配られました！

中洲川端商店街を貸し切りのイベントでお酒以外にも地元の名物も多数配られました。
美味しいご飯を頂きながら、いろんな方とお話することができました！

KBC九州朝日放送のニュースにも取り上げられたようです！
地元の方にも喜んでいただけてよかったです！

kbc.co.jp

さいごに

目黒周辺では Meguro.rb という Ruby の Meetup が定期的に開催されています。
５月開催はアカツキではないですが、LT大会や懇親会などございますのでぜひお越しください！

megurorb.connpass.com

*1:エポック社さんの許可をいただき、野球盤をアレンジしました。

インターンで好き勝手働かせていただいた話

エンジニアインターンとして二週間アカツキで就業したstalagmiteさんの体験記をお届けします。「自分の理想とするエンジニア」を意識して働いたインターン、どのような経験をされたのでしょうか。その様子をレポートいただきます。

自己紹介

この度アカツキのもとで内定後インターンをさせていただきました。その時のことについて、主に自分が何を考えながら動いたかを書きたいと思います。 とても自分語りが多くなるかもしれませんが、多分アカツキの社風的に大丈夫だと踏みました。

所属当初の背景

大学では情報系の専攻をしていた。
大学での研究はOpenStreetMapのことについてやってる。
ゲーム製作サークルに所属していて、学祭でゲームの展示をしたりしていた。

プログラミング経験

C++,Haskell,C#,Unity,GLSL

隙間時間で調べてること

数学(圏論、集合論、確率論)
シェーダ
VR

普段やっていること

DxLibやOpenSiv3Dを触りつつゲームの部品を作ったりモックを考えたりしている
（しかし完成したものはないという地獄）

所属時の話と自分語り

大学でプログラムの勉強をしていると、プログラマーというのは「厳密に仕様を決めて高い水準で要求に答える」みたいな、専門家としてのSE像があった。 ただ、もともと大雑把な性格で緻密なことが苦手な自分は、「そういうイメージのプログラマになれるのか」という漠然とした不安があった。（もちろん、ある程度のコード力はあると自負はしているけれども、その専門家としての価値と自分の性格って合わないような気がしていた)
就職活動をしている中の、そんな漠然とした不安のを抱えているときに、アカツキとの面談や、会社の説明を聞く中で、

「うちで働いているエンジニアはそれぞれ違う部分で価値を出し働いている。」
「インフラのことについての専門性で貢献しているエンジニアもいれば、プランナーなどの別職と連携をとったり、自分で案を出しつつ実装までするエンジニアもいる」
「全員が自分で考えていて、受け身なだけの人はいない」

という社風に興味をひかれ、アカツキの入社を希望した。

インターンの目標

インターン初日、メンターの方に言われたのは、
「このインターンでの目標を決めましょう」 という抽象的なものだった。 働き方も、目指すものも、全部自分で決めて良い。
具体的な課題をひたすら潰すもよし、実際のプロダクトの小さい機能を設計から作ってもよし、「 インターンで僕が何か良いものが得られたと感じられる、それがこのインターンの意義です」と説明してくださった。
僕は、大手のゲーム業界でたまに、規模は大きいのにゲーム性そのものがイマイチなゲームというのがあるのが嫌だった。
これは入社前から持っていた偏見であるが、「イマイチになってしまうのは、プランナーが仕様を考えてエンジニアが実装して、それをプランナーに戻してまたフィードバックして、というサイクルが重いのが原因なんじゃないか」と思っていた。だから、僕はこのインターンの目標として
「プランナーの考えている抽象度の高い案をとっととモックを作って実現して改善する、というプロセスをぶん回すエンジニアになりたいです」
と答えた。
一つ重大な問題がある。僕は自分の「ゲームエンジニア」としての像をここに置いた。この作業はいわゆる「ヒアリングから問題点を聞き出し解決策に落とし込む」というまさにSEとしての分野であり、
僕は大学でこの内容の授業の単位を落としているのである。
ついでに言うともともと僕はコミュ障であって、就活中にも自己嫌悪で大変なことになっていたほどだ。もう不安しかない

最初の1週間

目標を決めた後、ソーシャルゲームの開発（クライアント）チームに配属された。このチームでは、プランナーエンジニア問わず、Trelloに

「何か改善すべき問題」
「さらにゲームを面白くするためのコンテンツ案」
「UIUXの改善案」

など、色々な抽象段階の案を共有することができることを教えてもらった。
ここから自分が面白そうな案、実現できそうな案を拾い、話を聞きに行く。
プランナーがしたいことを、現在実装がどうなっているかを把握できるエンジニアが聞き、仮設計を考え形にする
これは結構自分がやりたい立ち回りに近いものだと思えた。

ここで色々な意見を聞いていく中で、「ゲーム内のキャラクターの編成を組むときの、画面遷移を伴う操作が煩雑であり、それを改善したい」という意見をプランナーSさんに頂き、これは手を付ける影響も少なくて済みそうだし、いい感じに抽象的だったので、担当することにした。 幸い、個人的にプログラムのバイトの経験があったので、さほど時間を取られずに自力で規模の大きいコードを読みつつ、既存コード内のでのゲームデータの扱い方や簡単な画面遷移の処理を頭に入れ、最初の1週間のほとんどをヒアリングに使った。
ここで最初の山を迎えた。最初の実装、設計案を考えたときに、「これは難しい。既存の画面遷移の中にどうUIUXをいじっても、複雑な操作が発生してしまい、意味がなくなってしまう」という結論になってしまった。このことをプランナーSさんに相談しにいくと、
「もっと根本から考えてみたほうが良い。本当は、編成なんて１タップでできるんじゃないか？それが実現できたら、最も便利なんじゃないか？」
僕は仕事として、与えられた役割としてプログラマを引き受ける時に、どうしても今確実にできることベースで物事を考えてしまう癖がある。それは情報系プログラマ、エンジニアとして大事な要素ではあるが、何かを解決したいときの思考方法ではない。なまじコードが読めるから、設計案が頭に浮かぶから、わかる範囲で片付けようとしてしまっていた。
なので僕は「1タップで自動編成」を一番上に置いて、それにもっとも近づくように、要求を分析することにした。これは、他のエンジニアに相談すると、「完全に自動編成するためには、キャラごとに編成する際の評価値を計算する必要があるが、その厳密な計算は難しい」
ということになってしまったのだが、
「他ユーザの編成を分析してそれを元に評価値を作れば、厳密な計算はいらないし、信頼性も高いのではないか」
という案が浮かび、既存の資産も活かせるということで、落とし所として、
「同レベル帯で成績の良い他ユーザの編成(=クリアログ)を自分の手持ちキャラなるべく似せて自動編成できる機能を作る」
とういことになった。(プランナーとエンジニアを行ったり来たりして解決案をだすというムーブ、これがしたかった)

これが決まった後、既存のコードを利用した設計と実装案、ドキュメントを書くことができた。
ここまで来るのに二度提案を練り直した。 この時点のドキュメントで
関数の影響範囲
この提案で操作が便利になるユーザー層の想定
までは書くことができた。ここまでは、いいペースだったと思う。

次の1週間

手をつけた課題についてドキュメントを書き、仮のコードも書いて、最初のプルリクエストを飛ばした。 当初の予想では、もっと議論が活発になると予想していた。というのも、僕が担当したのはロジックで、仮提案であり、現状のコードや設計により詳しい人にコメントがもらえるだろうと予測していた。ロジックだけでなく、本実装する際はUIUXの話も絡んでくるだろうと思っていたので、正直なところ「あれ、ウケが悪いな」と思った。
この時、元々の提案を出してくれたプランナーSさんが別の部署に行ってしまい、次にやることも含めて自分で考える必要が出てきて、３日ほど右往左往してしまった。

その後なんとか僕は、「現時点での提案の「自動編成の精度」が、どの程度良いのか分析できていないから、皆現在の提案の進捗が想像が難しいんだ」、と考えた。それは部分的には真で、自分でも「じゃあこの自動編成を使うと、どう便利になるの？具体的にどのユーザがどのように便利になるの?」という風に疑問に思っていた。なので次は、
「既存のユーザの分析」
「この提案で便利になるユーザとはどのような状況の人間か」
を調べることにした。

最後の1週間

mysqlをいじってアプリで使われているデータから、ユーザの手持ちキャラ、自動編成の通してみた結果を比較したデータを用意し、分析した。具体的には、自動編成後の編成のスコアの分布ごとに、
「編成結果のスコアがここのユーザたちは、ゲーム内ではこのコンテンツをするためにこの操作をすると考えられる」
「編成結果の低いここのユーザ層は、そもそもここのコンテンツを触らないな。より良いコンテンツへの推奨はUIUXでこう解決できるな」
というところを分析し、ドキュメント化した。
また、このデータを他のエンジニアが検証できるよう、デバッグメニューの実装し、プルリクエストを飛ばした。 これによって、2回目のコメントもらい、時間的にも区切り的にもちょうど良いので本インターンでの作業を終了した。

総評

一応、ヒアリング、提案、実装、分析、デバッグメニューで他者に検証してもらうフロー、今後の展望のドキュメント、までを、いろんな人に話を聴きながら作り上げることができたので、最初の目標である、
「プランナーの考えている抽象度の高い案をとっととモックを作って実現して改善する、というプロセスをぶん回すエンジニアになりたいです」
という動きはできたのではないかと思う。
ただ反省点として、
「プランナーSさんがいなくなったタイミングで、この提案の実現の進路を考える人が自分以外にいなくなったことに気づかず、失速していた」 というのがあげられる。
本来これにすぐに気づき、次に決めるべき内容、この提案について本腰を入れて一緒に考えてくれる(自分以外の)人間を巻き込む必要があった。 (ずっとメンターにも相談していたのだが,いつも「次どうすればいいですかね」と聞いてしまった。僕が考えるべきだったことなのに)
確かに、僕はプルリクを飛ばしてエンジニアとしてコードを書いてドキュメントを書いて分析もできたが、じゃあこれが何かの役にたったのかというと、正直よくわからない。なぜなら
提案の進路、実現の持っていき方を考えていなかった
or
それを考えてくれる人間の確保が必要なことに気づかなかった
からだ。
「プランナーの考えている抽象度の高い案をとっととモックを作って実現して改善する、というプロセスをぶん回すエンジニア」
のそれっぽい動きはできたけれども、そういう立ち回りののオリジナルな価値を生み出せたかというと、それは少なかったように思う。
そもそも僕がやりたいこの動きって、「プランナー<->エンジニア間で速度の速いフィードバックをして、抽象から具体に落とし込む」というのをやりたかったのだ。 しかしそもそも、
「抽象的な目標、提案をチームの内側から通すって時は、具体的な設計、方針が決まるまでその提案の立ち位置、自分の立ち位置、他人の立ち位置をよく把握しなければならない」
、そうでなければ、空中分解しかねないという基本を、僕は知っておくべきだった。
これはものを考えるプランナーだけでなく、何かを作るという当事者全員が意識すべきことだったことに気づいた。
三週間のインターンなので、大きい規模を実現することはできないという前提があったなかで、最大限のことをしようと覚悟をしたはずなのに、その覚悟がまだ足りなかったように思う。
インターンが終わったらまた日常生活に戻る。そこには、大学でも、個人ゲーム制作チームでも、やり残していることがある。
来年アカツキに入社するまでに、それらにケリをつけて成長して出直そうと思った。