クラスメソッド新卒1年目の業務・働き方をご紹介します（数字も添えて）

こんにちは。DA事業本部の春田です。

クラスメソッドに新卒入社してから1年が経ちました。内定を頂いた時に部長から言われた言葉が今でも忘れられません。

そう、私は部の新卒サンプル第一号なのです。なのでサンプルはサンプルらしく、最後までサンプルでありたいと思います。

各プロジェクトでやってきたこと

各案件の業務内容についてご紹介していきます。

某配信サービスのリアルタイムデータ分析基盤構築

入社月の4月から6月までは、某配信アプリのリアルタイムデータ分析基盤を構築している案件にアサインされました。ゴリゴリのサーバレスアーキテクチャを使うこの案件は、部署の中ではかなり異端な方です。主に使っていたリソースは以下の通りです。

• AWS Lambda
• AWS Step Functions
• Amazon CloudWatch
• Amazon Aurora
• Amazon DynamoDB
• Amazon S3
• Amazon SQS
• Amazon SNS
• AWS CloudFormation
• AWS X-Ray
• AWS CodeCommit
• AWS CodeBuild
• AWS CodePipeline

モダンなマネージドサービスをフル活用した設計だったので、AWSに慣れるにはもってこいの案件でした。また、サーバレスの楽しさもこの時知りました。Step Functionsはまじで楽すぎる。

ざっとBacklogを見直したところ、以下のような実装を担当していました。太字の上4つが割としっかりめの内容で、それ以外は細かいタスクをひたすら捌いていました。受託案件ながらも準委任という契約形態のおかげで、自由度高くやらせてもらえたのが良かったですね。

• ジョブの実行結果をSlackチャンネルに通知する
• Step FunctionsでAthenaのクエリ実行をコントロールする
• 無料版Slackのメッセージ数制限をなんとかするLambdaの作成
• 新規APIサーバーから流れてくる日次データのETL処理構築
• Lambda・Step Functionsのログ出力の調節と強化
• Auroraのデータライフサイクルを管理するLambdaの作成
• SQLやServerless YAMLのリファクタリング
• サービスの監視で使うメトリクスの洗い出し
• Serverless Frameworkの各種プラグインの調査
• バグ調査、改修に伴う影響範囲調査

ジョブの実行結果をSlackチャンネルに通知する

Slackの通知機能……。そうそれは、システム側のロジックに全く影響ないけどあったら嬉しい機能という、まさに新人にもってこいのタスクです。ほぼ初心者で案件にアサインされた場合は、間違いなく皆さんも通知機能を実装していると思います(笑)。簡単そうに見えて、意外とSlack Appの認証方式とかが細かくて苦戦するんですよね〜。アサインされたての4月に実装していた機能でした。

Step FunctionsでAthenaのクエリ実行をコントロールする

Step Functionsに慣れようということで、非同期のAthenaをワークフローで処理するためのステートマシンを構築しました。先輩が別のアプリで実装していたアーキテクチャを丸パクリすれば間違いないだろう、と思って同じような作りにしたら「素晴らしい」とお褒めいただきました。平和な世界で良かったです。こちらも4月の実装です。

無料版Slackのメッセージ数制限をなんとかするLambdaの作成

Slackの無料版ってメッセージ数の限界があるので、機械的に通知しまくっていると他のチャンネルのメッセージが読めなくなってしまうんですよね。それをかなりセコい方法で解決するLambdaを作成しました。セコすぎて笑えてくるので、ブログにしています。5月の実装でした。

新規APIサーバーから流れてくる日次データのETL処理構築

6月に入って、いよいよETL処理の構築を担当させてもらえるようになりました。要件整理から設計、実装までやった初めてのタスクで、かなり面白かったです。ざっくりいうと、LambdaでAPIを叩いてデータを一旦S3に置き、jqで変換してAuroraにInsertするというワークフローをStep Functionsで書くという内容でした。大変だったのは、クライアントの要望を汲み取るのが難しかった要件整理と、APIサーバーの仕様が特殊すぎてLambda上で簡単には扱えなかった、という点です。大変でしたが、ロジックを組んでいくプロセスがかなり楽しかったです。

ビッグデータ分析用のDWH構築

7月に入って、ビッグデータ分析用のデータウェアハウスを構築している案件にアサインされました。これぞデータアナリティクス事業本部！といった感じで、ゴリゴリにRedshiftを使います。EC2にPython製のワークフローを配置して、RedshiftやRDSに対してデータを捌いていく、よくあるDWHですね。

• Amazon Redshift
• Amazon EC2
• Amazon RDS MySQL
• Amazon S3

コード上では小さな変更でも影響範囲はかなり広く、テストに時間がかかるタスクが多かったです。一つ一つがかなり重く、例えば1つのカラムをテーブルに追加するだけで、影響範囲の確認に3週間は必要とするシステムでした。また、他のメンバーは沖縄と岡山にいるという、クラメソらしいチームだったなと思います。Wow!

実装内容は以下の通りです。

• 軽減税率対応
• Redsfhitのテーブルチューニング
• 新しく追加されるマスタデータやカラムのELT処理を実装・修正
• AuroraのSSL/TLS証明書更新

軽減税率対応

2019年10月から適応された軽減税率に際して、一部のテーブルにカラムが追加される変更がありました。変更箇所自体は大したことないのですが、リポジトリ内に大量にある他のワークフローへの影響確認が大変だったり、単体テスト・内部結合テスト・外部結合テストを行う入念なテストフローだったり、「システムを作ってるんだな」って一番実感した案件かもしれません。データ量も膨大だったので、単体での実行に数時間かかるワークフローもあったり、なんとなく「身動きが取りづらいなぁ……」とも感じていました。ただその後のタスクは、これと似たようなものが多かったので楽ちんでした。

Redshiftのテーブルチューニング

この案件で技術的に1番勉強になったのは、Redshiftのチューニングです。10月以降はDBチューニングの沼にどっぷりと浸かってました。Redshiftはソートキーだけでなく、データをどうノードに分散させるかを決める分散キーもあるので、チューニングパターンが結構複雑だったりします。Compound SortkeyとInterleaved Sortkeyの細かすぎる特徴を整理し、自分で検証も繰り返しましたが、年末のRedshiftの内部処理改善によって、その知見が無に帰することとなった時は泣きました。クラウド時代のDBチューニングは、シンプル・イズ・ザ・ベストです。ベンダー側の改善にあやかりましょう。

せっかくなので、AWS大薗さんの超ありがたいスライドを置いておきます。

Amazon Redshift Deep Dive & Update

某サブスクリプションサービスのデータ分析基盤構築

12月から現在までは、某サブスクリプションサービスのデータ分析基盤構築に携わっています。この案件はS3に配置したファイルデータを、Athenaでクエリするデータレイクっぽいアーキテクチャです。マネージドサービスはあまり使わず、EC2上のDigdagでワークフローを制御しています。

• Amazon S3
• Amazon Athena
• Amazon EC2
• AWS Lambda
• AWS API Gateway
• Amazon SQS

フランクに濃いタスクが振られてきます。また、弊社側はチームで動いているわけではなく、クライアントと私でほぼ一対一です。まだまだ甘いところはありますが、ようやく一人立ちできたのかな？と思いたいです。

• Redashバージョンアップに伴うコンテナ化
• CIによる自動テスト&本番デプロイ
• SlackのSlashコマンドでDigdag APIを叩く
• データ変換処理改善・リファクタリング

Redashバージョンアップに伴うコンテナ化

データを可視化するBIツールにRedashを使っているのですが、新機能やバグ改善のためにバージョンアップしたいとのことでした。ただ、OSSのRedashは最近のバージョンからコンテナ化したこともあって、どうすれば何も問題なくデータが移行できるかの検証を重ねてました。需要ありそうだったので、ブログにしています。

CIによる自動テスト&本番デプロイ

リリースした最新バージョンを、本番環境にデプロイする方法が手動だったので、Digdag上でワンクリックでデプロイできる機能を実装しました。CI/CDをスクラッチで実装する難しさを知り、GitHub Actionsに恋い焦がれました。併せてスクラム手法に合うようなGitブランチ戦略を考えちゃったりして、色々ルールを決めてしまった自分が今でも怖いです。

スクラムのGitブランチ戦略は、以下を参考にしました。今のところ特に不便はないです。

SlackのSlashコマンドでDigdag APIを叩く

SlackのSlashコマンドで、Digdagジョブを実行させる機能を作りました。今回はプライベートなEC2インスタンスのDigdag APIを叩くために、API Gatewayを噛ませました。Slashコマンド → API Gateway → VPC Lambda → Digdag APIといった感じです。API Gateway上の認証をどうするかに苦戦しました。汎用性高いので、後日ブログにできたらと思います。

データ変換処理改善・リファクタリング

ユーザーログの急増によってデータを処理しきれないジョブがあったりしたので、それの処理改善やリファクタリングを行いました。大体の原因が、メモリを食いすぎるpandasなんですよね。こんなにPythonのジェネレータを意識して開発したことは今までなかったです。

数字で見るわたしの実績

昨年度1年間の稼働時間を折れ線グラフにしてみました。有給休暇も8時間として換算しています。データの特性上、少数桁の最大値は6です。

１日15分くらいしか残業してませんでした。月の労働時間で帳尻が合えばいいので、定時前にあがることも結構多かったです。

次にプロジェクトごとの稼働時間も見てみます。

1年間で携わったメインの案件は3つで、大体3ヶ月スパンで回っていました。これらが稼働時間全体の約75%を占めています。「ちょい役サポート」というのはスキマ時間に手伝った他のプロジェクトに当たります。全社イベントなどの会社業務は合計240時間ですが、他の会社に比べたら少ないのでしょうか？業務中のブログ執筆時間は、大体月10〜20時間でした。

書いたブログの実績を見てみます。

re:Invent2019のレポートを書きまくった12月の14本が最高で、普段は頑張った月で4本、最低2本は書けるよう努めていました。昨年度はねた記事は6本で、技術系とそうでないので半々。これ以外にも気合い入れて書いた記事はありますが、ニッチ過ぎてあまりバズらなかったり。

その他の取り組み

角川ドワンゴ学園N中等部取材企画

「新卒だけど何か自分で企画持ちたいな〜」と思い、1年かけて連載取材企画を進めてきました。「なんでクラスメソッドが角川ドワンゴ学園と関わってるの？」と疑問に思う方がいるかと思いますが、この企画は僕の好奇心のみで動いていて、僕の方から学園に協力をお願いしている企画です。取材に協力いただいている生徒さんご家族、学園側の先生方だったり、企画書作成から交渉まで色々アドバイスをくれた弊社のマーケ部だったり、多くの人を巻き込んでいる企画なので、とりわけ思い入れが強いです。

何より、角川ドワンゴ学園が展開しているカリキュラムって本当にユニークで面白いんですよ。生徒や先生と話していると、僕のワクワクは止まることを知りません。良かったら読んでみてください。最終回は近日上がります。

RareJob英会話

弊社で7月から福利厚生の一貫として始まったRareJob英会話。ほぼ毎朝30分こなしてきました。9ヶ月続けてきて、英語が上達したかと言われれば微妙です。いつかは流暢に話せるようになると信じて、引き続き頑張ります。

AWS認定試験

去年の8月にAWS Certified Solutions Architect Associate(SAA)に合格しました。11月にSolutions Architect Professional(SAP)にも挑戦しましたが不合格。今年はもうちょっと頑張りたいです。

AWS re:Invent2019

出張としてre:Inventに行くには、SAPに合格してないといけないのですが、今期中にSAPを取得することを条件に、部長のはからいで行かせてもらいました。終始現実感がない毎日で凄かったです。お決まりのセッションレポートは日本語と英語で計15本書きました。

登壇・LT

こういった自分語りをしている辺り、どこかで登壇してると思いましたか？

全く人前に出ておりません(笑)。会社説明会でちょっと喋ったくらいです。昔はLT大会やカンファレンスとかにたまーに参加していましたが、もう今は外部イベントに参加しなくなってしまいました。

振り返ってみて

1年間1日8時間で、かなり色々な経験が積むことができたなと実感できました。一方、自分の中では全力でやってきたつもりが、こう可視化してしまうと大したことできてないなと思えてしまうのが辛いです。

クラスメソッドは新卒採用を始めています。少しでも興味があれば会社説明会などに遊びにきてください！