共同研究体験記

こんにちは❗️筑波大学システム情報工学研究科社会工学専攻2年の渡邊と申します。2020年4月から現在に至るまでKaizen さんと共同研究をしていました。

2月に修士論文として提出し、 3月には卒業予定である為、 最後に携わらせて頂いた研究についてせっかくですので振り返らせて頂きます🙆🏻‍♂️

きっかけ

昨年3月までは最適化系の研究をしており、4月から新しい研究テーマを探していた中同じ研究室の先輩から「技術面に明るい人が多い+仕事のような姿勢で研究できる」とお勧めされました。  

当時データ分析関連の研究に興味はあったもののロクにSQLも触ったことがなく、Pythonを動かせる程度の自分にとって「何でもすぐに質問できる」という環境もありがたかった為、指導教員にお願いして4月からチームに加入させて頂けることになりました❗️

研究の背景

SNSは現代社会においてなくてはならないものとなりました。その中でもYouTube及びFacebookは馴染みの深いコンテンツではないでしょうか。これらのプラットフォームは広告プラットフォームとしても成長が著しい分野であり、今後広告業界においてますます発展していくことが予想されます。

さて、皆さんは同じ広告が何度も出てきて、すぐ広告をスキップする経験はありますでしょうか(私はしょっちゅうあります笑)。これは、Ad Fatigue(広告疲れ)といって、同じ広告素材を使い続けることによる広告効果が薄れてしまう現象です。

f:id:kaizenplatform:20210427134853p:plain Creative Fatigue: What It Is & How to Avoid It | Consumer Acquisition

Ad Fatigueに対処するためには、期間経過後に新しい広告素材に差し替えるなどの工夫が必要になります。ここで、予め広告の効果が低下し始める時期が分かると嬉しいこととして

  1. 差し替えのタイミングを前もって決められる
  2. 効果が下がる時期が分かれば予め施策を打てる

の2つがあります。これらを叶えるため、「YouTube及びFacebook広告における効果指標(CPC)予測」について取り組みました。

どうだった?

研究する中では当然ですが、行き詰まる当たることもありました。特に昨年4月から新型感染症の影響もありフルリモートになったりと、これまでの経験とは異なる活動形態を余儀なくされたため、最初はリズムを掴めずうまく成果を出せない時期もありました💦 

このままではいけないと思い、区切りの良い段階でのMTGを設定(週一回教授とのすり合わせ、成果が纏まり次第Kaizenさんへの発表)し、自ら成果物のゴールを決めてリズムを作ることを行いました。単純なことですが、Goalを細かく設定することの重要性を身に染みて学ぶことができました。また、都度分からないことがあればすぐKaizenさんのSlackに投げる(すぐに返答して頂ける)を繰り返していた為、何不自由ない環境で研究に取り組むことが出来ました❗️

kaizenさんと行った共同研究における1番良かった点は、社会人としてやっておいたほうが良いことをアドバイス頂いたり、 基本的に自分からスケジュールを立て動いていくなど、 仕事のような姿勢を実際の社会人の方々と接しながら学んで行けたことです(意外と大学に所属しているだけだと、 社会人に自分から働きかけて何かをするという機会は少ない気がします)。

最後に

忙しい中丁寧に対応して下さったチームメンバーの方々には感謝しております🙏 特にこの研究をするきっかけを下さり、 研究において多くのアイデアを与えてくれたCTOの渡部様、SQL関連の質問を始め様々な相談に丁寧かつ素早く対応して下さったアプリケーションエンジニアの白井様には大変感謝しております🙇‍♂️

共同研究でも、インターンでもKaizenさんから頂ける恩恵は多くあると実際に1年を通して感じました。 技術力に加えて仕事としての能動的な姿勢を学びたい学生さんに是非、お勧めしたいと思います❗️

hrmos.co

Serverless Frameworkで作るお手軽アプリケーション

Kaizen Platformでアプリケーションエンジニアをしている白井(@kaito2280)です。

今回はServerless Frameworkを使ったお手軽アプリケーションの作成をtips等を交えてご紹介したいと思います。

Serverless Frameworkとは

サーバーレスのアプリケーションを作るのに便利な構成管理ツールです。オープンソースのCLIとServerless社がホストしているダッシュボードがあります。

今回の例はこのCLIを利用してアプリを作成します。

Serverless Frameworkでは、AWSやGCPなどのプロバイダーに対応しています。対応プロバイダーはこちら

今回の例では、AWSのLambda/API Gateway/S3/Cloud Frontを利用します。

Getting Started

aws-cli, nodeの設定が完了している前提です。

今回は社内で多く採用されてる言語のRubyを使用することにしました。

まずは、下記のコマンドを実行してみてください。

npm install -g serverless
serverless create -t aws-ruby -p myserverless
cd myserverless/

こちらでmyserverlessディレクトリにhandler.rbserverless.ymlの2つのファイルが作成されていることがわかります。

この状態で

sls deploy

を行うと、Lambdaの関数が作成されます。(slsserverlessの短縮形です。)

また、handler.rbに定義されているhello関数を叩く場合、

sls invoke -f hello

を実行することでhello関数を実行し、その結果が返ってきます。

serverless.ymlに下記のようにhttpのeventsを追加することでdeploy時にAPI Gatewayも同時に作成されます。

functions:
  search:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get

その他設定もserverless.ymlに追加し、deployすることで簡単に作成できます。

さらに、作成したアプリは、

sls remove

をすることで削除できます。

このようにServerless Frameworkを使用すると、サクッと作ってサクッと消すことができ、サーバレスアプリケーションを簡単に試すことができます。

今回作った機能

今回は、Kaizen Adという動画制作を支援するプラットフォーム上で、ユーザーが動画制作用の素材を外部サービスから無料で検索できる機能をServerless Frameworkを用いて作成しました。

構成は以下の通りです。

f:id:kaizenplatform:20210324135928p:plain

Serverless Frameworkを使用するとこれくらいの規模のサービスであれば簡単に構築が可能です。

また、すべての設定情報がserverless.ymlの1ファイルに収まるので、メンテナビリティにも優れてると思います。

以前弊社ブログでご紹介したPulumiでも似たような体験を得ることができますが、Pulumiはリソース全体の構成管理という側面が強く、簡単にアプリケーションを作るという意味だとplugin等も充実しているServerless Frameworkの方が速度が出ると思います。

API Gatewayの前にCroudFrontを置いている理由はレスポンスキャッシュを使用して検索を高速化したかったためです。

また、S3にアクセスログを溜めておきAthenaで分析しています。

最終的なserverless.ymlはこのようになっています。(多少省略している部分があります。)

service: search-material
frameworkVersion: '2'

provider:
  name: aws
  runtime: ruby2.7
  timeout: 10
  memorySize: 256
  stage: ${opt:stage, self:custom.defaultStage}
  region: xxx
  logRetentionInDays: 90
  
functions:
  search:
    handler: handler.search
    events:
      - http:
          path: search
          method: get
          
    environment:
      STAGE: ${self:provider.stage}
      PEXELS_API_KEY: ${ssm:/xxx/${self:provider.stage}/PEXELS_API_KEY~true}
      UNSPLASH_API_KEY: ${ssm:/xxx/${self:provider.stage}/UNSPLASH_API_KEY~true}
      UNSPLASH_API_SECRET: ${ssm:/xxx/${self:provider.stage}/UNSPLASH_API_SECRET~true}
      PIXABAY_API_KEY: ${ssm:/xxx/${self:provider.stage}/PIXABAY_API_KEY~true}

resources:
  Resources:
    LogBucket:
      Type: AWS::S3::Bucket
      Properties:
        BucketName: xxx-cloudfront-log-${self:provider.stage}
        VersioningConfiguration:
          Status: Enabled

plugins:
  - serverless-api-cloudfront
  - serverless-prune-plugin
  - serverless-ruby-layer

custom:
  defaultStage: dev
  priceClass:
    dev: PriceClass_200
    qa: PriceClass_200
    prd: PriceClass_All
  domain:
    dev: xxx
    qa: xxx
    prd: xxx
  certificateArn:
    dev: arn:aws:acm:xxx
    qa: arn:aws:acm:xxx
    prd: arn:aws:acm:xxx
  # settings for serverless-api-cloudfront
  apiCloudFront:
    domain: ${self:custom.domain.${self:provider.stage}}
    certificate: ${self:custom.certificateArn.${self:provider.stage}}
    priceClass: ${self:custom.priceClass.${self:provider.stage}}
    logging:
      bucket: xxx-cloudfront-log-${self:provider.stage}.s3.amazonaws.com
  # settings for serverless-prune-plugin
  prune:
    automatic: true
    includeLayers: true
    number: 10

package:
  exclude:
    - node_modules/**
    - package.json
    - package-lock.json
    - Gemfile
    - Gemfile.lock
    - README.md

Tips

  • serverless-prune-pluginの導入

LambdaはdeployされるごとにVersionを保持するため、運用・保守し続けると使用しない過去のLambda関数が残り続けることになります。Lambda上ではコードの合計ストレージに制限があるため、できるだけ無駄な関数は残さないほうが良いでしょう。

このプラグインを入れておくことで指定した世代より前のVersionの関数を削除してくれるようになります。

  • Parameter Storeの導入

環境変数の管理といえば煩雑になりがちですが、Serverless Frameworkでは最近一般的に使われるようになってるAWS Systems ManagerのParameter Storeに対応しています。

${ssm:/xxx/HOGE~true}

このような記法を使うことでSecureStringで保存した環境変数をdeploy時に複合して参照してくれるようになります。

  • Lambdaリソースのチューニング

Lambdaを使用する際に悩むことの一つとしてメモリサイズが挙げられます。

メモリサイズを大きくすることで割り当てられるコンピューティングリソースやネットワーク帯域も比例して大きくなると言われており、実行速度と料金の落とし所を自分で探ることになります。

しかし、AWS Lambda Power Tuningというものを使用することでメモリサイズを簡単に最適化することができます。

詳しい利用方法はクラスメソッドさんの記事を参照してください。

最終的には以下のようなグラフが出力され、今回作成したLambda関数には256MB割り当てると実効速度とコストのバランスが良さそうだということがわかりました。

f:id:kaizenplatform:20210324140204p:plain

最後に

今であれば、Lambda上でコンテナがサポートされ、またそれがServerless Frameworkでもサポートされたため、もっと違った作り方があるのではないかと思います。

手軽にアプリケーションを作りたい場面があればそちらにも挑戦してみたいと思います。

本番使用に耐えうるアプリケーションがインフラ含め簡単に作成できるので、開発で速度を出したい場合やユーザー動向を探るためのお試しリリースをする場合の選択肢にしていただければと思います。

We're hiring!

Kaizen Platformで一緒に働いてくれる方を絶賛募集中です!

話を聞いてみるだけでもいいので、ご興味ある方はぜひ! hrmos.co hrmos.co hrmos.co

プロダクトに関することを全部やる。それが、プロダクトマネージャー

皆様お久しぶりです。Kaizen PlatformでCTOをやっている渡部です。

先日、プロダクトマネージャーというキャリアについてインタビューをいただきました。 eng.kandc.com

良い機会なので、プロダクトマネージャーとしての仕事観と、これまで Kaizen Platform でやってきたことを振り返ってみたいと思います。

プロダクトマネージャーの仕事は企画職?

アイデアに価値はない、実行にこそ価値がある

Google創業者のラリー・ペイジさんも言っています。 アイデア自体には(その時点では)価値はなくて、より良い形で実現するための実行(エクセキューション)にこそ価値があるのだと。

プロダクトを何のために作るのか? という問いに皆さんは答えられますでしょうか? いろんな答えがあっていいと思いますが、私は迷わずこう答えます。

続きを読む

インターン生活を振り返って

エンジニアインターンの舩越です。

Kaizen(※) でインターンを始めてちょうど 1 年程経つので、ここらでインターン生活を振り返ってみようと思います。

※ Kaizen: Kaizen Platform の略称。

なぜ、Kaizen のインターンに応募したか

f:id:kaizenplatform:20210210103442j:plain

調べてみたところ、Kaizen のインターンに応募したのは 2019-12-21 でした。この時はちょうど就活中で、一通り業界を見終えて、「エンジニアになりたいかも・・・!」と思い始めた頃でした。しかし、エンジニアが実際にどんな仕事をしているかなどは曖昧だったため、「じゃあ実際に働いてみっか!」と思い立ち、インターンを探し始めました。

Wantedly を眺めていて「ここ、徒歩 1 分(※)じゃん!(ポチー」ということで申し込んだのが、Kaizen のインターンでした笑

※ 当時住んでいたアパートから。

参考までに「インターン応募時のスペック」を載せておきます。当時の自分は知識も技術力もありませんでした。

  • 就活中の M1(工学系)
  • コードを書くのが大好き(技術力があるとは言ってない)
  • Python でちょっとしたスクリプトを書けるくらい(アプリなんてもちろん作れない)
  • Rails チュートリアル挫折
  • HTTP?キャッシュ?ポート番号?Docker?なにそれ美味しいの?状態

多分、「コードを書くのが大好き」と言う部分が伝わって採用に至ったのかなと思っています笑

「向いているかどうか」より「好きかどうか」が重要ですよね、うんうん。

Kaizen のインターンの良いところ・悪いところ

実際に 1 年働いてみた自分が思う、良いところ・悪いところを列挙してみます。Kaizen のインターンに興味がある方向けになるかと思います。

良いところ

続きを読む

Kaizen Platform のエンジニアインターンのご紹介

Kaizen Platform で開発組織の部長をしているKawabeです。
今回は、エンジニアインターンの取り組みについてご紹介します。

インターンの取り組みの歴史

f:id:kaizenplatform:20210125093240p:plain

Kaizen では創業当初よりインターン生が活躍してきてくれているのですが、開発組織でエンジニアの1人目のインターン生がジョインしてくれたのは2019年でして、実は長い歴史がある訳ではありません。

2017年頃までの採用方針はどちらかというと即戦力重視の傾向があり、開発チームではインターン生の受け入れはしていませんでした。

その後、将来的な開発チームのスケールを見据えて採用方針やチームのあり方を見直し、オンボーディングプロセスの標準化や若手採用の推進、勉強会・読書会などのチーム力強化の取り組みをおこなってきました。

そして2019年にインターン生の受け入れ開始し、2021年現在では4名のインターン生が活躍してくれています。

インターンの働き方・指針

夏季・冬季休暇に短期集中型で参加してもらうようなものではなく、定常的に週に何日か稼働いただくスタイルをとっています。 もちろん時期によって忙しさは変わるので、「卒論・修論前はしばらく稼働を減らしたい」「夏季休暇はガッツリ働きたい」といった変動には柔軟に対応しています。

インターン生を受け入れるにあたっては、極力ほかのエンジニアと同じ環境で働いてもらいたいという指針をもっています。

続きを読む