RareJob Tech Blog

レアジョブテクノロジーズのエンジニア・デザイナーによる技術ブログです

#2 スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみる(全5回)

まえがき

レアジョブテクノロジーズの三上です。

2回目の投稿です。前回から1年と4ヶ月振りの投稿です。お待たせし過ぎたかもしれません。

前回の記事 -> #1 スクラムマスターを雇う時に聞いてみるとよい38個の質問に答えてみる(全5回) - RareJob Tech Blog

早速ですが、今回もインタビューを受ける気持ちで直感で答えてゆきます。

スプリントプランニングについて

チームがもっとも価値のあるストーリーに取り組めるようにするためにどのようにスプリントプランニングにスクラムマスターとして貢献するか?

前提としてプロダクトバックログは優先度の高いもの、価値のあるバックログアイテムから順に並んでいるはずです。もしもそうなっていないのなら、まずはその議論からはじめます。

また「価値のあるストーリー」は組織の状況、市場の状況によって変動するものという前提です。各ストーリーの先には組織またはチームが達成したいゴールがあるはずです。毎日忙しいとゴールは見失いがちです。何度でも問いかけて良いと思います。

目指す先があって、チームの目線が揃ってこそ建設的なプランニングができると思うのでそこを意識してファシリテーションします。

ユーザーストーリーの価値をどんなメトリクスに基いて判断するか?どんなメトリクスは受け入れがたいものか?

ユーザーストーリーのWHOに依存すると思いました。例えばエンドユーザーであればCVRやLTVは成果として分かりやすく適切に思いますし、社内の人であればコスト削減の結果の数値だったり可能な限り定量的な目標にしたいです。

リファクタリングや負債解消を目的としたストーリーの場合、前提としてDORAなどのメトリクスを計測できているとプロダクトオーナーと優先度の会話もしやすくなると思います。

そんな我々もDORAメトリクスの計測をはじめました!!(大事)

受け入れがたいものは前述の逆で、抽象度の高いものや誰がどう判断できるのか説明できないものは避けるべきと思いました。

チームのコミットメントの権限を侵犯することなくどのようにもっとも価値のあるユーザーストーリーを選べるようにファシリテーションするか?

コミットメントの権限 の解釈が難しく思いましたが、チームとステークホルダー(PO)の間でデリバリーの確約に対するズレが生じた状況を想像しました。

ここでお互いの達成したいことは何だろうと考えた時に「価値のあるユーザーストーリーを選べる」ように支援することだと思いました。双方の「ズレ」が何なのか観察して問いかけ、解決に導くようにします。このような状況では、あくまで第三者的な観点を持ち、冷静でいることを意識しています。

どれくらいの時間をリファクタリングや重要なバグの修正や新しい技術やアイデアの調査につかうのが適切と考えるか?

正直なところ状況による と思いますが、経験上はリファクタリングが後回しになりがちな状況があるあるだと思いました。この状況の場合は、「ベロシティの3割程度はあえてプランニングに含めずに改善の時間として使う」ということを試したことがあります。この時間がなぜ必要で重要なのかはチーム全体で納得いくように支援します。

チームの個人にストーリーやタスクを割り当てようとするプロダクトオーナーをどう扱うか?

面白い質問ですね。笑

幸いこの状況になったことがありませんが、あるとしたらチームへの信頼がないのだと思いました。チームはあなたが思っているより優秀だし、マイクロマネジメントは必要ないと伝えます。逆にチームが未成熟なのであれば、自律思考になるようにチーム側を支援すると思います。

チームメンバーによるタスクのつまみ食いをどのように扱うか?

絶対にやってはいけない!とは強くは言わないですね。

なぜつまみ食いしたのかを確認して、それが必要なものだったとしたら透明性やベロシティの重要性を伝えます。自分の担当すべきアイテムが完了していて、スプリントゴールも達成しているって前提だったとしたらチームに共有した上でつまみ食いも良いんじゃないかと個人的には思います。

ユーザーストーリーが最終的に確定していないがスプリントの2日目には確定する状況で、プロダクトオーナーはそれをスプリントバッグログに入れようとしている。どのように行動するか?

完成の定義が決まっていないアイテムを計画に入れた場合、意図していないもの=価値の低いものになってしまう可能性があるのでそれを伝えます。また、ストーリーとして確定していないのでポイント見積もりも出来ていないので、他のストーリーが完成できないリスクもあるかもしれない。それでも追加したいですか?とまずは問いかけますね。

どうしても、というならあえて失敗して学ぶのもアリと思う。それがスクラムの強みでもありますし。

スクラムチームのメンバーがスプリントプランニングに参加したがらないだけでなく、時間の無駄だと考えている。このような態度をどう扱うか?

時間の無駄と感じる理由から聞きたいですが、実際にありそうなのは「プランニングが直接自分に関係のない話だ」と感じるとしたら、本当に関係ないか?と問いたい。チームが分業のようになってしまうのはよくあるパターンだと思うので

スクラムチーム内には、サブチームや階層は存在しない。これは、⼀度にひとつの⽬的(プロダクトゴール)に集中している専⾨家が集まった単位である。

というスクラムガイドにある記述を引用しつつ、チーム開発をするメリットを理解してもらえるよう会話します。多くのメンバーがそう感じるとしたらスクラム自体の採用を見直す議論も必要だと思いました。

終わりに

いくつかは回答に詰まるものもあり、改めて考え直す良いきかっけになりました。レアジョブテクノロジーズでの開発に少しでも興味を持っていただけたら嬉しいです。

We're hiring!
弊社では、一緒に働いてくださるエンジニアを募集しています。
rarejob-tech.co.jp

Buildkit でキャッシュを ECR に保存する

はじめに

こんにちは。DevOps グループの中島です。

弊社では CI ジョブ実行のために EC2 でホストした GitLab Runner (Docker Executor) を利用しており、Docker コンテナ上で CI ジョブを実行しています。 それらのジョブのうちコンテナイメージをビルドするジョブにおいて、時間がかかっている問題がありました。 今回はその問題に対して比較的新しい機能を用いた解決策の紹介と、処理の概要について説明したいと思います。

背景

ビルドに時間がかかっている理由としては、レイヤーキャッシュが利用されていないのが 1 つの要因としてあげられました。 コンテナビルド用の Docker は dood (Docker outside of docker) を採用しており、レイヤーキャッシュは EC2 上に保存されますが、Docker のキャッシュは EC2 の容量の問題から毎日削除しています。 もし削除していないにしても、SaaS のような実行環境ではどのサーバで CI ジョブが実行されるかは定まらず、ローカルのキャッシュは利用できないと考えるのは妥当といえます。

この問題の解決策として、AWS の記事 で紹介されていた ECR にキャッシュを保存する方法*1 を利用しビルド時間の削減を達成することができました。

実装

以下に実装のポイントを説明します。

gitlab-ci.yml

build:
  image: docker:25-rc
  script: ...

ECR へのキャッシュの保存に対応しているのが Docker のバージョン 25 からのため、CI ジョブを実行するコンテナには docker:25-rc を指定します。(現状では正式リリースされていないため rc を利用しています)

script

# キャッシュの格納先 ECR
REPO_URI=<account-id>.dkr.ecr.<my-region>.amazonaws.com/<repository_name>

# 1. Buildkit コンテナの作成
docker buildx create --use --name <buildkit_container_name>

# 2. キャッシュの格納先を指定してビルド
docker buildx build -t ${REPO_URI}:<image_tag> \
  -t ${REPO_URI}:latest \
  --load \
  --cache-to mode=max,image-manifest=true,oci-mediatypes=true,type=registry,ref=${REPO_URI}:cache \
  --cache-from type=registry,ref=${REPO_URI}:cache .

# 3. Buildkit コンテナの削除
docker buildx rm <buildkit_container_name>

script 内のポイントは以下のとおりです。

  1. docker buildx create --use で Builder の driver として、デフォルトの docker ではなく、docker_container を作成して利用する指定をします。(docker driver では インラインキャッシュ しか対応していません)

  2. docker buildx build でキャッシュの格納先を指定してビルドします。

オプション 説明
--load ローカルに保存する指定 (通常の docker build と異なりデフォルトではどこにも出力しないため、これを指定しないと warn が出ます)
--cache-to mode=max 最終レイヤだけでなく、全てのレイヤをキャッシュの対象とする
image-manifest=true,
oci-mediatypes=true
ECR に格納できる形式の指定
type=registry,ref=${REPO_URI}:cache キャッシュ格納先(書き込み)の指定
--cache-from type=registry,ref=${REPO_URI}:cache キャッシュ格納先(読み込み)の指定

以上の実装で、一度ビルドしたレイヤーが ECR に保存され、次回以降のビルドではそのキャッシュが利用されるようになります。

ビルドの全体像と処理の流れ

GitLab Runner 上では Docker コンテナで CI ジョブが動いていて、そのジョブが Buildkit 用の Docker コンテナを起動していたりします。 一応動作はしているものの、実際にはどのように各コンポーネントが連携して動いているのか全体像が把握できてないことから、どこの設定を変えれば何が変わるのかの確信が持てなかったため、少し詳しく調べてみました。 以下に図を用いてビルドの過程を示しています。

GitLab Runner Server 上では Docker が起動しています。gitlab-runner は CI ジョブ実行のため、Docker Engine API を用いて CI Job Container を起動します。

ホストの /etc/gitlab-runner/config.toml で CI ジョブは /var/run/docker.sock をマウントするように設定しているため (dood)、コンテナ内のジョブはこのソケットを経由してホストの dockerd にアクセスすることができます。

docker buildx create で docker_container の Builder (Buildkit Container)を作成します。コンテナの起動は前述したとおりマウントしたソケットを経由し Docker Engine API を用いてホスト側で行われます。

Buildkit Container が作成されました。このコンテナは /var/lib/buildkit 配下にキャッシュなどを保存しますが、このパスはホスト側のファイルシステムにマウントされています。

docker buildx buildでビルドを実行します。ci-job 内で buildx がクライアントとして buildkitd と通信し、Buildkit Container 内でイメージのビルドが実際に行われます。ビルドの出力は CI Job Container に返却されます。

docker buildx build--loadを指定しているので、イメージを読み込む Docker Engine API を呼び出し dockerd にイメージを保存するよう依頼します。 その後、同様にdocker push で保存したイメージをリモートにプッシュするよう依頼します。

終わりに

CI ジョブでイメージをビルドする処理の流れを追うことで、もやもやしていた感じがスッキリしました。自信を持って Buildkit を使えるようになった気がします。 このポストが誰かのお役に立てば幸いです。

We're hiring!
弊社では、一緒に働いてくださるエンジニアを募集しています。
rarejob-tech.co.jp

*1:イメージにキャッシュを埋め込むインラインキャッシュを利用するという方法もありますが、マルチステージビルドでは利用に制限があるため採用しませんでした。

ジョブスケジューラの導入

はじめに

こんにちは、DevOps グループの中島です。
年末年始は前からやろうと思っていたエルデンリングをプレイしました。DLC もそのうち出るらしいので楽しみです。
今回はジョブスケジューラの導入をしたときの話をシェアします。

背景

エンタープライズ向けでは、サーバの監視とジョブの管理を行うツールとして、日○や富○通の製品が業界標準として選ばれることが多いように思います。 一方で OSS だと有名どころは Rundeck あたりが候補になるでしょうか。 弊社では AWS を利用しているためその中で見繕うことをまずは考えたのですが、それ専用に提供しているサービスはありません。

そこで、要求仕様を挙げ、最適なものを OSS から選定することにしました。

要求仕様

必要な要件としては以下で、cron を画面操作に置き換えられれば良いという簡単なものとなっています。

  • 社内サーバで動作している cron を置き換えたい
  • サーバにログインせず、GUI から実行や実行結果の確認がしたい
  • ジョブのグルーピングはしたい
  • ジョブ定義のバックアップができる
  • 実際のサービス提供では利用しないため、特段 SLA は高くない

比較

今回は OSS のジョブスケジューラである、Rundeck, Dkron, Cronicle を比較してみました。

Rundeck Dkron Cronicle
開発元 PagerDuty Distributed Works PixlCore
GitHub Stars 5.2k 4k 3k
WebUI あり あり あり
言語 Java Go NodeJS
グルーピング あり なし あり
ジョブ定義のエクスポート あり なし あり

Rundeck は開発元がメジャーなため長期のサポートが期待出来そうです。また、導入事例が多くありトラブルが発生した際の対応が比較的容易と考えられます。 ただ、導入してみた感想としては、とにかく機能が豊富で、ジョブの定期実行をしたいだけなのに設定する必要のある項目が多くあり、学習コストが高いなと感じました。 GUI のデザインも少々分かりにくく(個人の感想です)、動作もサクサクという感じではありませんでした。

Dkron については Go で作られている点や、This is the only job scheduler in the market with truly no SPOF と謳っている部分が魅力に感じました。 しかし、求めているグルーピングやバックアップの機能が、商用サポートを購入しなければ利用できなかったり、そもそも存在していなかったので今回は見送りました。 高 SLA を求められる場合には選択肢に入るかもしれません。

Cronicle は、Dkron と同様に開発元があまり知られていないという懸念はあるものの、今回の要求仕様を満たしています。 それに GUI もシンプルで美しく(個人の感想です)、直感的に操作ができ、必要十分な情報を表示してくれていました。 機能性や拡張性、保守性はそれほど高い要求がされていないことから、今回は利便性の高い Cronicle を採用することにしました。

Cronicle の UI

終わりに

Cronicle を導入してから数ヶ月経ちますが、特に問題なく動いています。 ジョブスケジューラって探してみると意外とこれってのが無いんですよね。 もし導入を検討していたら、Cronicle を選択肢に入れてみて下さい。

We're hiring!
弊社では、一緒に働いてくださるエンジニアを募集しています。
rarejob-tech.co.jp

EdTech LLM元年でした!という話

どうもCTOの @jumboOrNot です。 今年は怒涛のLLMの年でしたね〜、弊社でもさまざまなトライがあり振り返ってみようと思います。

「見(ケン)」の時期

2022年11月にChatGPTが公開されて、3月にAPIが公開されるまでは私を含め弊社でも関心を持ったり注目する人は増えていましたが、実際にプロダクトへ反映するまでは割と慎重になってしまったかなと思っています。様子見をしつつ、いいプロダクトへの組み込みはなんだろうな〜と考えることが多く、あまり手数を持てていませんでした。まさに「見(ケン)」の時期で手を組んで唸ってました。しかし歩みが遅いと言われていた EdTech 界隈でも想像の何倍ものスピードでさまざまなリリースが増えてきて、だいぶ危機感を持ったことと、技術顧問でもある広木さんからも支援をいただき弊社でもプロダクトへ早期に組み込むこととなりました。

プロダクトへの組み込み

xtech.nikkei.com

思い立ってから1ヶ月、社内外の協力を得て「レッスンAIアシスタントβ」のリリースを実施できました。弊社でしかできない・わかりやすい顧客課題・LLMだからできることを考えての最初のリリースでした。弊社の PROGOS と組み合わせて、レッスン中にレベルに合った学習の支援をする仕組みでした。 多くの方からフィードバックもいただき、APIをstreamで利用できてないことでレスポンスが遅くレッスン中というシチュエーションで使い勝手がまだまだ良くないことや、プロンプトの改善などリリースしてきて見えてきたことが本当に多かったです。 またそれだけでなく「LLMを使ったプロダクト開発」における注意しなければいけないことや、必要なこと、課題なども多く見えてきてその後の開発に活かせる知見を多く得られました。

社内向けのガイドライン・イントラ内にChatGPT

また社内での活用という観点でも、早期にガイドラインを策定し直接ChatGPTを触るのでは無く、統制やユースケースを計測するために社内に ChatGPTをラップしたシンプルなチャットアプリケーションを展開しました。社内でもアンケートを取り、活用におけるハードルや関心、課題を抽出しました。

マナビアップデートソン2023

rarejob-tech-dept.hatenablog.com

初のハッカソンをオフラインで開催し、ここでもLLMを活用した多くのアイデアやプロトタイプが生まれました。 私は学生の頃にさまざまなハッカソンに出てきたんで流石に楽勝かと思いましたが、各チームともめちゃくちゃいいアイデアが多くて結構接戦する結果となりました・・・! 各チームもそうですし、LLMをはじめ技術としても価値が高いものがスピード感を持って組み込める時代になったと感じました。

CTO室の立ち上げ

弊社ではグループでさまざまなプロダクトを運用しており、なかなか横断した支援や改善がしにくいところもありました。 今期はCTO室を立ち上げて、すでにあった弊社のEdTechLabチームと協業し、各チームの支援やR&Dを推進しました。

新プロダクトのローンチ

rarejob-tech.co.jp

K12領域(幼稚園1年と12年間の初等・中等教育を含めた13年間の教育期間)のユーザーに対して、覚えた単語でオリジナル絵本を作成し、親子で楽しむカスタマイズ絵本サービス「WordWiz」をリリースしました。ここはCEO、CIO主導で企画からリリースまでメンバーを巻き込みながら進めてくれていました。 CTO室としてもこのPJに参画してもらい実際に手を動かしてもらったり、ユーザーヒアリングなどを実施していきました。

社内での活用の促進

  • OpenAI APIのお試し用・検証用のapikeyの発行、取得手順公開
  • 社内向けのLLM利用ガイドラインの準備・公開
  • 社員向けのprivate LLMの準備(Amazon Bedrock)
  • 相談用のchannel作成、アイデア募集
  • working groupの発足
  • Github copilotの導入

etc...

とにかく今年は手数だなと思っていたので触れる機会を多く社内でも作りました。

Amazon Bedrock の活用

機会をいただき弊社でも Amazon Bedrock を活用したさまざま検証を進めた結果、re:invent にロゴを掲載いただくことができました。 (まさかの私のミスでレアジョブテクノロジーズで無くて、親会社のレアジョブロゴを渡してしまい、そっちが載ってます・・・なんて親孝行なんでしょうか(違う)) 勉強会もお誘いいただき弊社メンバーにも参加してもらい(様子もブログに書いてもらいました)、弊社でもこれを使ったサービス企画やプロトタイピングがはじまりました。

そして来年

この1年、LLMのもたらす怒涛のリリースにいい意味で焦燥感を得ながら考えていたことは「人とAIが共創して価値を作ること」だなと思いました。 もちろん人の仕事をAIが奪っていくようなことは増えていく一方で、あらためてAIだけでなく「人が何をなすべきか」が EdTech サービスを提供する弊社でも再定義が必要なことだと思いました。

真面目な記事になってしまったので、ここらで共創のトライとして締めのジョークはLLM君に任せてみようと思います。

・・・

スベッてますね、バナナだけに。

まだまだ価値の創出までは遠いですが、回り道をしながらでもトライの数を増やし続けたいと思います。 良いお年を、ウホウホ

Application Integrationを使ったSaaSからのBigQueryへのデータ取り込み

こんにちはデータエンジニアの杉光です。

今年6月くらいにGAとなりデータ界隈で一瞬話題となったApplication Integrationを試した感想について書きます。
実運用で使えないか試した結果、今回は見送ることにしました。その経緯を踏まえて機能と検証内容をお伝えできればと思います。

Application Integrationとは

cloud.google.com

日本語名ではアプリケーションの統合と表記され、Google CloudのIntegration Platform as a Service(iPasS)になります。
GUIからトリガー設定や様々なアプリケーション・データソースへの接続、データ変換などのワークフローをノーコード/ローコードで作成ができます。iPasSという言葉は馴染みがなかったですが、このような機能を含むことが多いようです。 AWSでいうところのStep FunctionsApp Flowを兼ね備えたものになるでしょうか。

全体イメージは公式のアーキテクチャ図を引用します https://cloud.google.com/static/application-integration/images/overview-diagram.png?hl=ja

主な機能

Integrationデザイナ

フローを直感的に作成可能なビジュアルエディタ。
できることが多いので一通り機能を把握しないと何から触れば良いかわかりません。チュートリアルが複数用意されているので、近いユースケースで慣れていくのをお勧めします。

トリガー

一連のタスクを開始するイベント。 APIトリガーやScheduleトリガー、Pub/Sub、Error Catcherなどがあります。

統合タスク

タスクは入力を受け取り、処理を行い、出力を行います。大きく分けて統合タスクとGoogle Cloudサービスタスクがあり、統合タスクはApplication Integrationが提供するタスクです。
JavaScript、Send Email、Restエンドポイント呼び出し、ループ、フローの呼び出し、後述で説明するデータマッピングやコネクタどがあります。

データマッピング
ソースデータとターゲットデータのスキーママッピングを担います。
JSONの複雑なデータ構造のフィールド抽出が可能でマッピング関数を使うと簡単にマッピングできます。 連携値を任意に定義したり、それらをフロー全体の変数としてとして利用することも可能です。

コネクタ
Google CloudのサービスやThirdPatyアプリケーション、データストアに接続することができる。厳密にはIntegration Connectorsと連携します。
プレビュー含めると50種類以上あり、他の統合ツールのコネクタと引けをとらない感じがあります。 cloud.google.com

料金に注意
GCP以外のコネクタは無料枠がなく接続ノードあたり $0.70/時間 掛かります。

Google Cloudサービスのタスク

他のGoogle CloudサービスやGoogle Workspaceと連携するタスクです。 Cloud Function、DataFlow、Vertex AI、App Script、スプレッドシート、ドライブなど様々なサービスに対応しています。

試した理由

少し話題になったからというのもそうですが、当データ基盤ではBigQueryを利用しており、Zoho CRM API から取得するデータをBigQuery上で扱う必要がありました。
REST APIからデータを取得するケースは今後他にも可能性があり、その度に実装するのも手間(メンテナンスも含めて)なので、リードタイムを短くしたいと思っていました。予算的にFivetranやtoroccoなどのデータ統合ツールに手を出せなかったのもあり、GCPと連携できる安価なものを検討しました。料金については上述の通り、外部サービスと連携するときには注意が必要です。

試した内容

以下のフローでZoho CRMからBigQueryへデータを取り込むパターンを試しました。

  1. Zoho CRM APIを実行してデータを取得する(レスポンスはJSON形式)
  2. レスポンスから必要なKeyを取得する
  3. JSON配列をNDJSONに変換する
  4. GCSへファイルアップロード
  5. GCSのファイルをBigQueryへロード

APIトリガーを起点として、RESTエンドポイント呼び出し、GCSのコネクタ、BigQueryのコネクタをデータマッピングタスクで繋ぎ、必要な項目を選択、変換しつつ取り込む流れになります。

全体フロー

1. Zoho CRM APIを実行してデータを取得

今回の検証ではQuery APIを利用しました。リクエストBodyにSQLを指定し、レスポンスBodyにデータが返されます。

認証情報はAuthentication Profile画面から作成します。
Zoho CRM APIの認証仕様に基づき、OAuth 2.0 client credentialsを選び設定します。

Task inputにEndpoint、HTTP methodやRequest bodyを設定します。

RESTエンドポイント呼び出しタスク

今回指定したQuery APIのリクエストbodyは以下になります。

{
    "select_query":"select Account_Name, Corporate_Number, Jurisdiction_Company from Accounts Where Jurisdiction_Company = 'レアジョブ' Limit 3"
}

2. レスポンスから必要なKeyを取得する

データマッピングタスクにてリクエストbodyから必要なデータ部分を取得します。
ここでは取得した値を"data"というフロー全体で使える統合変数に入れます。この時点で取得した値はJSONのArray型になっています。

データマッピングタスク

3. JSON配列をNDJSONに変換する

最終的にBigQueryがロードできるフォーマット(NEWLINE DELIMITED JSON)に変換します。データマッピングタスクでは変換ができなかったので、JavaScriptタスクを使います。

以下では"data"変数から取得した値を変換し、"ndjson"変数に入れています。

/**
 * Function that is called during the JavaScript Task execution.
 * @param {IntegrationEvent} event
 */
function executeScript(event) {
    const resp = event.getParameter('data');
    const ndJson = resp.map(JSON.stringify).join('\n');
    event.setParameter('ndjson',ndJson);
}

4. GCSへアップロード

Google Cloud Storageのコネクタタスクを使い、変換したデータをGCSバケットへアップロードします。

各コネクタでは幾つかのサービスのAPIに準じたアクションが用意されていますが、今回は UploadObject を使います。
パラメータの指定はコネクタタスク前段のデータマッピングで行います。3で設定した"ndjson"変数の値をContentへマッピングし、BucketやObectNameなどを適切な値に設定します。

GCS UploadObject Input

5. GCSのファイルをBigQueryへロード

最後にGCSバケットへアップロードしたファイルをBigQueryに取り込みます。
BigQueryのコネクタアクションは InsertLoadJob を使います。

前手順と同様にBigQueryのコネクタタスク前段のデータマッピングからINPUTの指定を行います。GCSのURIや取り込み先のテーブルなどの他にテーブル作成や更新方法のパラメータとして以下を設定しました。

Parameter Value
CreateDispositon CREATE_IF_NEEDED
WriteDisposition WRITE_TRUNCATE
AutoDetect true

テスト実行と結果

操作の詳細は割愛しますが、フロー画面上部の「TEST」ボタンから実行します。 実行結果はGCS、BigQueryの内容は以下のようになりました。

GCSオブジェクトの内容

{"Account_Name":"株式会社ABC","id":"3743557000003706168","Jurisdiction_Company":"レアジョブ","Corporate_Number":null}
{"Account_Name":"株式会社ABC02","id":"3743557000003706229","Jurisdiction_Company":"レアジョブ","Corporate_Number":null}
{"Account_Name":"株式会社DEF","id":"3743557000003706274","Jurisdiction_Company":"レアジョブ","Corporate_Number":null}

BigQueryテーブルの内容 スキーマの自動検出でロードしたので、JSON keyがカラム名になっていることが確認できます。

採用しなかった理由

今回の検証で使ったAPIはJSONを返しますが、実際に使いたかったのはZip形式のバイナリを返すBulk APIでした。大量件数のデータを取得するためのものなので、非同期の取得になります。
これに対して、RESTエンドポイント呼び出しタスクのOUTPUTはString型で受けてしまうため、文字化けが発生するのでマッチしませんでした。
また、ステータスをポーリングするフローを書くのがプログラムを書くより手間と感じていたのとZipファイルを解凍する処理を書く必要があり、CloudFunctionのタスクで実装すれば可能だが、そこまでするなら全て実装しても変わらないことが主な理由です。

良い点

実運用としては使わないものの良い点はいくつかありました。

RESTエンドポイント呼び出しタスク

下記の認証プロファイルと併せてノーコードツールとして一番便利と感じた部分です。任意のAPIを叩けるのは利用ケースが大きく広がりそうですし、AWS Step Functionsも追従してか最近同じような機能をリリースしています。
Call third-party APIs - AWS Step Functions

認証プロファイル

RESTエンドポイント呼び出しタスクやコネクタ接続時の認証情報をタスクとは別に設定でき、サポートする認証タイプが充実していると感じました。

データマッピング

GUIの恩恵を一番受けられたところ。マッピング関数が便利でした。

フローをJSONエクスポートできる

コードで管理可能になる。但し認証プロファイルの設定は出力されない。 ノーコードツールで作っても設定内容はコードで管理したいし、デプロイも自動化したいとなる思います。 Google公式でintergrationcliというtoolが公開されています。 github.com 複数環境で管理されることが前提とされ、環境変数や認証プロファイルの出力も考慮されているのでCI/CDで組み入れできそうです。

終わりに

Application Integrationにてフローを作成し、APIから取得したデータをBigQueryへ取り込むイメージを少しでも持って頂けたら幸いです。 Google Driveやスプレッドシートなども連携できるので、コーポレート業務の効率化にも活用できそうです。

We're hiring!
弊社では、特に データマネジメントプラットフォーム(DMP) グループでは、
一緒に働いてくださるデータエンジニアを大募集しています。
rarejob-tech.co.jp

マナビアップデートソン2023

はじめに

こんにちは!CEOの山田です。

11月8日、9日に全社合宿を行ない、そこで弊社ミッションに因んで名付けたハッカソン「マナビアップデートソン2023」を開催しました。 場所は「クロス・ウェーブ府中」さんにお世話になりました。宿泊可能な大規模な研修施設で、建物は綺麗で開放感もある造りで、宿泊した部屋も広くて眺めもよく、懇親会も施設内で開催でき、満足出来る施設でお勧めです。

目的

合宿でハッカソンを開催した目的は、チームビルディングとアイディアの掘り起こしです。

チームビルディング

弊社はリモート主体の勤務体制をとっており、プロジェクトベースで業務を推進しています。対面でのコミュニケーション機会は限られていますが、今回の合宿で長時間のグループワークや懇親会を通じて、組織の活性化と心理的安全性の高い環境を目指しました。

アイディアの掘り起こし

深くプロダクトに関わる人たちが持つアイディアを引き出し、それを具体化するためにハッカソンを設けました。チーム活動を通じてアイディアを洗練させ、実現可能なものへと発展させることが目標です。

開催概要

合宿前知見共有

合宿前には、業界動向や技術トレンドに関するプレゼンテーションを5人のメンバーに行ってもらいました。これは、当日をアイディア決定作業だけで終わらせないための準備です。5人の中には、お願いして親会社であるレアジョブの中村CEOにも発表して頂きました。中村さんだからこそ知っている内容が多く、盛り上がりました。

ハッカソン概要

  • 3もしくは4名1チーム
  • 普段関わらない人同士のメンバー構成
  • 制限は、EdTech領域であることのみで、英語学習でなくてもOK
  • 一日目は制作、二日目は発表(二日目は会議室が12時までだった)
  • 評価軸
    • インパクト(有用性、利便性)
    • ユニーク(独創性、先進性)
    • マーケット(市場性、実現性)
  • 評価方法
    • 全員の投票で、各チームの評価軸を5段階で採点
    • 3つの評価軸と総合点の最優秀賞を選出

結果

CTO率いるチームが最優秀賞と2つの評価軸で圧倒的な成績を収めました。 ただ、発表された作品は、想像以上にクオリティが高く、みな業務の合間で真摯に向き合って合宿に臨んだことがわかりました。 多くの作品は、次の企画に入ることになる可能性が高いので、成果については非公開になります。

感想

イベントでは予期せぬトラブルに直面することもあります。今回は、ランチのお弁当が足りないという問題が発生しました。この点については、数量の見落としでご迷惑をおかけし、申し訳ありませんでした。しかし、このトラブルを通じて、チームとしての対応力が高まったと感じますね(笑)。

このイベントは、リアルな交流と新たな学びを得る貴重な機会であり、非常に楽しいものでした。今後もこのような取り組みを続けていきたいと思います。

集合写真

We're hiring!
弊社では、一緒に働いてくださるエンジニアを募集しています。
rarejob-tech.co.jp

WordWiz - 子供の学習意欲を高める新しいサービス

こんにちは、ディズニーパークとドナルドダックをこよなく愛するCIOの岩堀です。今日は初の試みで行ったプロジェクトについてお話ししようと思います。それは、私たちの会社が初めて公募にて有志が集まってスタートしたプロジェクト「WordWiz」です。これは、K12領域において、子供たちが学んだ単語を使ってオリジナルの絵本を作成し、親子で楽しみながら学ぶことができるサービスです。

wordwiz.rarejob-tech.jp

サービス導入背景

K12市場は、まだまだ成長の余地があります。そこで、私たちは「WordWiz」を通じて、この市場に新しい風を吹き込むことを目指しました。このアイデアは、社内公募プロジェクトから生まれ、チームの情熱と創造性が詰まっています。ドナルドダックのように時にはちょっとドジながらも、常に前向きに挑戦する精神でこのプロジェクトに取り組みました。

技術的な挑戦

このプロジェクトでの、フロントではこれまでレアジョブでは使っていなかった技術を採用し、バックエンドではモダンな形でAWSを中心に構築しました。これらの技術を使いこなす過程で、私たちも大きく成長しました。

フロントエンド
  • Nuxt3 x Vue3
  • TailwindCSS x DaisyUI
  • Pinia
  • Bun
バックエンド
  • Go
AWS
  • ECS
  • ALB
  • CloudFront
  • Lambda
  • SQS
OpenAI
  • GPT-4
  • DALL-E3

サービス提供目的、狙い

WordWizは、K12領域の子供とその保護者を対象に、学習体験を豊かにすることを目指しています。子供たちが楽しみながら単語を学び、親子でオリジナルの絵本を作成することで、学習への興味を深めることができます。 私たちの目標は、学習をもっと楽しく、もっと身近なものにすることです。WordWizを通じて、子供たちが自分のペースで学び、親子で共有できる経験を提供することで、学習への新たなアプローチを提案し、応援したいと思っていただけるようなサービスになることを目指しています。

絵本イメージ

今後の展望

WordWizは現在、テストマーケティングの一環としてローンチし、ユーザーニーズを探っています。私たちは、ユーザーの声を大切にし、サービスの改善と進化を続けていきます。そして、これからもドナルドダックのように、時には失敗を恐れず、常に新しい挑戦を続けていきます。

このプロジェクトは、ただの仕事以上のものでした。私たちの情熱と、子供たちの笑顔を想像しながらの開発は、まさに魔法のような体験でした。WordWizを通じて、多くの家庭に新しい学びの形を届けられることを心から楽しみにしています。

We're hiring! 弊社では、一緒に働いてくださるエンジニアを募集しています。

rarejob-tech.co.jp