ビジネスに必要な全てを担い、自分の専門性を見つけ出すフルサイクル開発者のあり方【技育祭2024秋】

今回は2024/09/21,22に行われた技育祭2024 (秋)にて登壇した @pei0804のセッション文字起こしをお届けします!🍁

資料はこちらから: ビジネスに必要な全てを担い、 自分の専門性を見つけ出す フルサイクル開発者のあり方@技育祭 秋 / how-find-own-speciality-in-full-cycle - Speaker Deck


ビジネスに必要な全てを担い、自分の専門性を見つけ出すフルサイクル開発者のあり方

今回は「ビジネスに必要な全てを担い、自分の専門性を見つけ出すフルサイクル開発者のあり方」と題して発表します

1. 専門性ってそもそもなんだっけ?

ってことで、早速なんですけど、何か身につけたい専門性ある人とか身につけたい人いますか?

「じゃあその専門性ってどうやったら身につくんだろう?」って悩ましいじゃないですか。私も就活生のとき、なんとなく専門性つけたいような気がするんですけど、何かそっちの方が何かお賃金をもらえそうだしと思ってました。じゃあどうするかってなったら 「いやなんか特定分野にバキバキに特化したエンジニアになればいいんじゃね?」と当時は考えた んですけど。

私、今年で7年目なんですけど、何かキャリアの初期に専門性決めるのってちょっと早すぎるなみたいなのがわかってしまったんで、今回それをぜひシェアできたらなって思ってます。で、今回話すことは 「私の専門性は仕事で発生する必要なことを全部やってたら見つけたよ」 って話をしようと思います。

1.1 @pei0804の専門性

近森淳平です。ぺいと呼ばれてます。

私の専門性は大きくこの4つです。

専門性1: Snowflake

Snowflake知ってる人、Snowflake知ってる人って言って、手が上がったらめっちゃその人すごい!みたいな気持ちになってるんですけど。いや、すごいですね。 最近の人ってどこで知るの?まあ、優秀な学生が多いということでですね

Snowflakeデータに特化したクラウドサービスなんですね。とかGoogle Cloudとかあるじゃないですか。あれのデータにめちゃくちゃ軸足を置いたサービスがそのSnowflakeですよね。

このSnowflakeにはSnowflake Data Superheroes っていうのがあるんですけど、世界21か国から80人に選ばれるうちの1人に私選ばれて。なのでSnowflakeに詳しいです。 プレスリリースも出してるんで見てください。

専門性2: アドテク

アドテク、めちゃくちゃ簡単に説明すると、私は広告主側の立場に立って広告配信するマンです。

いろんなメディアありますよね。何かスマホとか見てたら広告が出てくるじゃないですか。 表示されてる広告をいかに、届けたい人に出したいというニーズに応じて自動的に出すシステムを作ってる人です。

じゃあエンジニアとして見たときにどういうところが難しいかっていうと、データがめちゃくちゃ多い んですよ。これはログなんですけど、1日で10億レコードは余裕で超えるんですよね。しかも構造もややこしくて扱う面倒くさいですよ。ぶっちゃけ。 そのアドテクのデータって実はお金に直結する んですよ。例えば「クリック数がめちゃくちゃ多かった」って言っても、そのデータが消えちゃったら「いや、実際には出てないよね」で終わっちゃうんです。

だからデータそのものが実績であり、会社の価値にも直結するんです。そのため、データをきちんと扱えることがめちゃくちゃ重要 なんですよ。でも、大量のデータを扱うのは本当に難しい。そこで、そのデータをうまく扱うための専門性としてデータエンジニアリングを得意としています。

専門性3: データエンジニアリング

データエンジニアリングって何かっていうと、何かビジネスの意思決定にデータを使うみたいな話です。 最近よくあるじゃないですか。データでなんちゃらAIだとか言ってるじゃないですか。あれ一回落ち着いてくれと。やることめちゃくちゃあるんですよ。裏側でデータをいい感じに扱えるようにして、ぱっと見れるみたいな環境するのってめちゃくちゃ大変なんですよね。これ、全体のプロセスをいい感じにするのがデータエンジニアリングって言うんですけど、データ基盤構築とかやってたらだいたいデータエンジニアが裏でいい感じにしてるんですね。その、例えば何かデータ集めて分析できるはず、その一連の流れをいい感じに作っていくっていうのが得意です。

図引用: データアーキテクチャ特集 データ利活用を推進する8社の技術選定

専門性4: VP of Data

もう一つの専門性としてはVP of Dataです。私、今、株式会社CARTA MARKETING FIRMという会社で働いてるんですけど、経営戦略とデータ戦略をガッチャンコする役割 に就いています。簡単に言うと、経営リソースってヒト・モノ・カネとか言うじゃないですか。 私はこのヒト・モノ・カネにデータを加えるっていう仕事を今やってます。

これらの専門性は必要なこと全部やるっていう姿勢で全部身につけた んですね。

だから、なんか「俺は○○になるぞ」みたいな固定観念はなくて、 ただ仕事をする中で必要なことをやってたら自然と身についていった って感じだったんですよね。

2. 「必要なことは全部やる」から成長する

じゃあなぜ全部やるのかって話をしていくんですけど、事業開発とかってやっていったらわかるんですけど、正解ないんですよ。「何かこれやったらもう何兆円」みたい感じじゃないんですよ。 たくさんいっぱい繰り返してやって思考してて、やっと正解が出てくるみたいな感じなんですよね。

じゃあ正解分かってたら、別にそれ上手にやったらいいですよ。それをめちゃくちゃバキバキに上手にやればいいんだけど、現実そんなことないんで。たくさん試すしかないですよね。

2.1 サイクルを高速に回す

じゃあ何が大事かっていうと、施行サイクルを素早く回すのが最適解になるんです。だからそのサイクルを早く回すには、じゃあ何しますか? 結局、「全部やる」のが一番早い。

私が言いたいこととしては、このサイクルを回す上では担当領域とかただの障害でしかないよねって思ってる。で、何かのサイクルを回す時に一人で全部やっと早いですよ。当たり前ですけど。

例えば、かの有名なPDCAサイクルがあるじゃないですか。極端な例ですけど、Planマン、Doマン、Checkマン、Actionマンみたいなのがチームに4人いたとすると、これ絶対回らないですよ。

担当領域を分けるっていうのが実際の現場であるとすると、例えばこんな感じですね。設計から開発、テストまでは私がやるけど、リリース作業は別チームが担当するってパターン。そうなると、私がめちゃくちゃ頑張ってテストまで終わらせても「リリースですよ」って言った時に「ああ、ちょっと今忙しいです」と言われたら、僕の価値出るの遅くなるじゃないですか。担当領域を変に分けちゃうと「これは全部自分でできた方が早いよね」っていう話で。

2.2 フルサイクル開発の実践

じゃどうするのか?私が今所属しているCARTA HOLDINGSって、どうやってこのサイクルを回してるかっていうと、フルサイクル開発っていうのをやってます。

フルサイクル開発って、簡単に言うとプロダクトっていうのがあるじゃないですか。何でもいいですけど。それに対してオーナーシップとか持って、それを価値届けるための必要なサイクルは全部ちゃんと回そうぜっていう話です。

平たく言うと、自分とかチームが作った機能は自分とかチームで保守運用したらいいじゃんって。なんでかっていうと、自分で考えてるから何をすればいいかって意思決定もできるし、全部関われるから。それもいい経験になる んですよ。しかもどんどんどんどん試せるから、最終的にそれが事業の成長のサイクルを後押しして加速させていくんですよね。

このサイクルの過程に別に技術領域とかないですよ。ここの技術領域までは誰々さんがやって、ここの技術領域からは誰々さんがやってるとかじゃないですよ。もう 価値出すのにチームで全部やればいい っていう話です。

2.3 器用貧乏になるのでは?

で、ここで一つの疑問が出てくるんですよね。

何か色々やってたら器用貧乏になるんじゃない?

みたいな。そうなんですよね。「器用貧乏なるじゃん」みたいな。

私もそう思ってたんですけど、じゃあ特化させる?「じゃあ俺はここだけやるぞ」って。スペシャリスト vs ジェネラリストになるみたいな話が出てくる。

で、私はこの2項対立に1石を投じるぞ、と思って話してます。

「全部やる」から専門家になれるし、「全部やる」から幅広いゼネラリストにもなれる。だから別に2項対立の構図じゃなくて、全部やればいい。

そのためにはまず 目の前の課題にまっすぐ向き合う。そうすると、できることが増えてきて、そしたらその中から得意なことが出てくるんですよ。それが専門性になっていきます。

3. キャリアの軌跡:全部やることの実例

2018年、私はVOYAGEGROUPという会社に入社しました。今のCARTA HOLDINGSですね。今から振り返ると、あっという間に7年目になって、自分でもびっくりします。7年か...。

私の新卒時代って、ちょっと変わってたんです。大学卒業してから専門学校に入ったんですよ。

変な話ですよね。22歳まで全くプログラミングとか触れてなくて、専門学校でプログラミングを始めたら、これが意外と面白くて。フロントエンドとかインフラとか、色々触ってるうちにどんどんハマっていって。 「エンジニアになるのもいいかな」くらいの軽い気持ちだったんですけど、エンジニアの仕事って意外と多いんだなって後から気づいて。当時の私って、特に強みがあるわけじゃなくて、ただ好奇心旺盛で元気でしたね。

3.1 新卒1-3年目:基礎固め

入社して最初の3年は、本当にがむしゃらに取り組みましたね。

1年目は新規サービスのグロース開発に挑戦したんですけど、最初に所属したチームで3ヶ月ぐらい働いてたら、全然違うチームが新規サービスをローンチして、慌ててメンバー募集してるって言ってたんですよ。私はペーペーじゃないですか。別にぶっちゃけどこ行ってもバリュー出せないと思ったから、よくわかんないけどやりたいって感じで、そのチームに入ったんですね。シニアエンジニアと君二人で頑張ってくれって言われて。俺まだ全然できないけどみたいな感じでしたが。

そこで経験できたことっていうのは、自分の書いたコードがそのままビジネスインパクトが出たりとか、開発から運用まで全部やるっていう、そういったエンジニアリングを学べたりしました。あと、 やっぱり正解がないので、事業開発ってそのぐるぐる回すのが大事だな っていうのをここで知りました。

2年目になって、そのサービスのグロース開発が一区切りついてやることがなくなったんです。でも、事業的に伸びしろがあった他のプロダクトがあって、「こっち来て一時的に手伝って」って言われたんですけど、それが一時的どころか永続化されちゃいました。そこのチームは、やっぱり結構 長いことプロダクトアウトでやってるんで、システムがでかいんですよ。マジで。そこでの仕事はまた変わったんですよね。複雑なコードをどうやってまず理解するか、それをどうやって良くしていくかっていうのは、もう戦略がめっちゃ難しいし。あとサービスを安定的に動かし続けるのって、複雑になればなるほど難しいです。そこら辺の知識とか、あとはDevOps的なアプローチとかを、その時に体現というか実際にやれたんでよかった。

3年目になってくると、だんだん調子に乗り始めるんですけど、大規模開発とかも終わり始めたら、何か技術的な課題が見えてくるんですよね。「ちょっとアーキテクチャ見直したいっす」みたいな。エラーハンドリング的なところをやりたいし、ネットワークリソースがちょっと微妙なので直したい、とか。 広範囲に影響を与えるような仕組みとか、そういうのを作る面白さとか難しさってのはここで学びました。あとはフロントからインフラまで全部やってたから、色んな技術を使って開発するほうが色んなことできるなっていうことが分かったので、そこら辺とかもすごい良かったです。

3年くらい働くと、ようやくアドテクってこういうことかみたいな感じになったんですよね。何か「石の上にも3年」とか言うけど、まさにそうで ようやくここから仕事が一気に面白くなる んですよね。

3.2 4年目の転機:データエンジニアリングへ

で、4年目はもう本当に 私のキャリアにおいてのターニングポイント で、それがレポーティング基盤刷新プロジェクトっていうのがあったんですよ。

このプロジェクトのトリガーとなったのが CARTAの経営統合(VOYAGE GROUP x CCI)。で、経営統合するってことは、何かしらやっぱ事業戦略変わるんですよ。事業戦略変わるってことは「今作ってるプロダクトの事業モデル、そろそろ根本的に違うやつだよね」っていうペインがあったんですね。

そこで「広告レポーティング基盤を一から全部作り直したいよね」みたいな話になって僕に仕事が振られてきたんです。最近はレポーティング基盤を作ってるんですけど、これが今まで言われた中で一番やりたくなかった仕事だったんですよ。なんでかっていうと、レポーティングの仕組みが当時えぐいぐらい複雑で、「これ絶対やりたくないな」って思ってたんです。でも結局僕がそれを直すことになって。当時は本当にどう解決すればいいか分からなくて、社内だけじゃなく社外も含めて解を模索したって感じでしたね。これは「僕の考える最高レポーティング基盤」っていうスライドでまとめてたりします。

控えめにいってめちゃくちゃ大変でしたね。もう大変でマジでやばかったですね。

で、この仕事の過程で私はデータエンジニアリングに出会い、それに関する情報発信をし始めたんですよね。

当時、データエンジニアリングの知見が社内外で限られていて、 日本でもこの話題について語る人がほとんどいなかった んです。マジで。だから、これは絶対みんなが困る問題だと思ったんですよ。データ活用の重要性が叫ばれている割に、実際にその話をしている人が少ないような状況だったので、そこから色々な発表を始めました。どうせみんな同じところで詰まるだろうと思って、積極的に情報発信を始めたんです。

この活動が後にコミュニティの基盤となり、結果的に私が2024 Snowflake Data Superheroesに選ばれることにもつながりました。情報発信を始めてから約4年後に、「めちゃくちゃ詳しい人」という評価をいただいたんですね。私がよく書いていた記事は、ディメンショナルモデリングやデータエンジニアリングの基本的な内容などですね。

ディメンショナル・モデリング データエンジニア道の俺のバイブル

3.3 5年目: チームの危機と"ヒーロー"の道

はい、5年目。ここで一大イベント発生するんですよ。

隣のデータサイエンスチームでエースプレイヤーが退職することになった。 なるほど、みたいな。「あの人、マジで抜けるの?」みたいな感じだったんですね。

5年目はそのデータチーム再建というのをやってました。エースプレイヤーが抜けたし、改善するためにやれること全部やってました。

当時のデータサイエンスチームと私の立ち位置について。

データサイエンスチームの主な仕事は広告の入札ロジックを構築することでした。広告を出す時、瞬時にいくらで出すかを決めるロジックを作るチームです。普通に考えて、事業の根幹なのでこの状況は「やばい、やばい、やばい」ってなるはず なんですよ。でも、私はそのロジックについて全く知識がなかった。普通に考えて、エースプレイヤーが抜けたらヤバくない?みたいな感じになるじゃないですか。だから、全然違うチームだったんですけど、何かできることないかなと思って、そのチームのコードを読んでたんですよね。

そしたら「もうチームを移った方がいいかも」って思う理由が見つかったんです。当時、データサイエンスチームが持ってるデータ基盤があったんですけど、これって俺が作り直したレポーティング基盤とほぼ一緒じゃない?みたいになって、「いけそう」って思ったんです。 それに加えて、 データが事業にとって重要なリソースになるっていうのは、まあ当然だろうな って思ってたんですよ。だから仕事するならここにちょっとBETしたい気持ちがあったんです。エースプレイヤーが退職して、みんなめっちゃ困ってる状況じゃないですか。でも、どうすればいいか分からない。そこで、「俺がいたらヒーローになれるんじゃない?」みたいな感じになって、データチームに異動したいって言ったんですね。

これまでのキャリアっていうのは、単純に必要なことだけやってきたんです。事業にとって必要だからね。でも、 この時は事業課題と自分のやりたいことがすごくちゃんと合致した瞬間 でしたね。すごい私にとって重要な経験でした。

データサイエンスチームに異動してからやったのは、既存のデータ基盤を全部作り直して、Snowflakeをベースとしてデータ基盤作ることでした。 その時にそのプロジェクト提案、その後おそらくデータ基盤を事業部全社向けに使うだろうと思ってたので、それ込みで使えるように作って今も実際そうなっていきました。

やっていくうちに、データエンジニアリングという仕事とデータサイエンスって違うよねってことが分かってきたんですね。データ人材の役割が曖昧すぎるがゆえに、データサイエンスチームがすごく大変な状況になっていて、全然その正解に再現性がないという課題があったんです。そこで、どうしたらチームとして再現性を持って動けるのかというところに着目して、役割をわざと明確にしてみるというのをやりました。その上で、フルサイクル開発というのも取り入れたりしたんです。

techblog.cartaholdings.co.jp

この時からデータエンジニアという肩書きを名乗る ようになりました。データエンジニアリングは今後めちゃくちゃ重要になると思っていたので、私はここにオーナーシップを持っていることをあえて宣言しようと決めたんです。それ以来、ずっとデータエンジニアとして仕事をしています。

組織設計とデータ基盤の構築について、両方とも発表しているんですが、興味があればぜひ読んでみてください。

ぼくのかんがえる最高のデータ分析基

データをモデリングしていたら、組織をモデリングし始めた話

コメントを少し読んでみますね。そうですね、とりあえずやってみないとわからないですよね。ああ、そうそう。

そう、そうなんですよ。学士編入とかじゃなくて、専門学校に行ったんです。実は、私はそんな真面目な学生じゃなくて、大学までプロゲーマーをやっていたんです。これでいけると思ったんですが、世界の壁が高すぎて。当時はレベル高すぎて意味がわからなくて、このままニートになるぞと思ったら親に怒られて。それで、「じゃあ専門学校に入るか」っていう感じで。全然真面目じゃない。

そうなんです。面白い方がええから。大学卒業と就職の間にプログラミングを選んだんです。なぜかって?私、その時チームのホームページとか自分で作ってたんですよ。それを親が見て「こいつ、いけるんちゃうか」って思ったみたいで。ただそれだけなんです。大学卒業後に専門学校行ったのは、このままじゃ家追い出されるから。専門学校行くしかなかっただけです。

3.4 6年目: チームのために「全部やる」

6年目の話に戻りますね。6年目になって、これまでデータ基盤を作ったりして色々やってきた中で、新しいデータ基盤に既存の業務がどんどん移行されていった んです。当然、利用者が増えると要望もめちゃくちゃ増えるんですよ。でも、当時フルタイムのデータエンジニアは私一人しかいなかったんです。そうなると、普通に業務遂行が大変じゃないですか。障害が起きたら全部俺がやらないといけないみたいな状況で。これじゃまずいと思って、もっとなんとかしてこの状況を打開しなきゃいけないなと思ったんです。

データ基盤の管理を個人からチームでやろうと思ったんです。これまで1人で扱ってきた感じだったので。今では2024年現在、4名体制のチームになっています。ここで仲間と一緒に事を成すということを覚えたんですけど、それまではデータ基盤を運用する際、ぶっちゃけ私個人の力で全部バキバキにやるっていう傾向があったんですよ。マンパワーでね。私、結構コード書けるんで、つい全部やっちゃってたんですよね。

このデータ基盤の仕事が多くなりすぎて、仕事の数がエグすぎて無理になってきたんです。そこで、他者との協力が大事だなって思うようになったんですよ。チームで事に向かうと、単純に色んな人が来るから手数が増えるってのは確かにそうなんですけど、それだけじゃないんです。 色んなメンバーが入ってくると、多様なアイデアがバンバン出てくるんですよ。そうすると、システムがどんどん堅牢になっていく進化の過程が見えてきて、「やっぱり色んな人とやった方が面白いことになるな」って実感した んです。この辺りから、仲間とやることをすごく意識するようになりました。ちなみに、データ基盤内では「Vision」と呼んでいるデータ基盤があるんですけど、それがどう進化してきたかっていう話はブログにまとめてるので、よかったら是非見てみてください。

techblog.cartaholdings.co.jp

これまではマジで早く行きたければ1人で行けというか、もうそれ以外考えてないって感じのキャリアだったんですけど、この辺から私は遠くに行きたいし、みんなで行こうということになりました。

だから何か今となっては私は1人でやるより、何か仲間とやるのが最高にいいよねって。当然、仲間を増やしたら別の仕事が出てくるんですよ。そうなると、採用や評価、大切にしていることや採用など、色々な仕事が出てくるんです。当たり前ですよね。仲間が増えるってことは、私が立ち上げた以上、マネージャーになるってことですから。

これら全部必要だから、やるしかないんですよ。エンジニアだからってそういうのをやらないでいられる状況じゃないんです。何かしなきゃいけないから、全部やってます。

3.5 7年目: VPoDに就任

はい、長(おさ)に就任しました。VPoDに就任した当時の状況ですが、2023年10月1日に私が在籍していた会社を含めて4社がCARTA内でガッチャンしたんです。それまでデータ基盤の管理を個人でやっていた感じだったんですが、チームでやろうということになりました。

なんで VPoDになったかっていうと、4社統合して組織は一体どこに向かってんだみたいな感じだったんですよ。私からしたら「いやー、統合しただけでよく分かんないっす」みたいな感じだったんで、「なんでシナジーが生まれないんだろう」ってことを考えていました。現場をどんどんヒアリングしていくと、 データに関連する業務問題がめちゃくちゃ根深い ってことがわかって。混乱してる中で、確かにシナジーが生まれてないなって気づいて「これ、俺まだまだやることあるわ」ってなったんです。そこで「よし、データドリブンをぶち上げるんでよろしく」って感じで、後から経営者向けに説明しました。

speakerdeck.com

そしたらVPoDになったんですが、経営統合って大変そうだよね。統合があると大変そうじゃないですか。実際大変なんですよ。やっぱり全体把握が難しくなるし、文化も違うので、ややこしくなるんですけど、でもガッチャンすればするほど、実はデータってめちゃくちゃ大事になってくるんです。

これまでは何人かに会えば状況がわかるみたいな感じだったんですけど、人が増えてくると人力で何かをやるのは無理になってくるんです。だから、データとかコンピューティングリソースを使って、ちゃんと今何が起きているか知ろうっていうことが大事になってくるんです。 これはそういう意味ではチャンスだなと思ってですね。

カオスが生み出した課題、これはデータエンジニアリングで解決できるんじゃないか って。だからうちのチームは単純なデータ基盤チームというよりは、データを駆使して事業を動かすという覚悟で動いています。確かに統合による課題もありますが、それ以上にデータドリブンな状態に持っていけば、今は問題だと思っているものも多分メリットになると思っているんです。そういう思いで取り組んでいます。

まあつまり、会社をいい感じにするために全部やるって感じですね。

実は先日、また社内合併した

2024年9月19日、また私の所属している会社がガッチャン(合併)しました。

チームメンバーと話していたら、「やることが増えますね」みたいな感じになりました。多分、もっとデータをちゃんとやらないといけないと思うんです。

こういう、全部やるってメンバーが揃っているのはめっちゃいいなって思いません?だって、例えば何か大変なことに対して「これ絶対仕事めっちゃ増えるわ」みたいな感じだったら、ベンチャー的な向き合い方の人が集まってるほうが面白い。今すごく面白いんですよ。

4. 現場で必要とされる専門性を獲得する

価値を出すために必要なこと全部やる。いろんなことありますよ。とにかく価値を出す。

まとめると、現場で必要とされるその専門性っていうのは、何か狙って獲得できるもんじゃないですよ。

仮に例えば「ここだけめちゃくちゃ特定分野で頑張ります」といってやったとして、現実の問題、そんな甘くないですよ。マジで色々あるんで。

CARTA技術コーチの @soudai1025 から教えてもらった例えで面白かったんでちょっと紹介するんですけど。

弁当をプロダクトとして例えた時に、ご飯だけめちゃくちゃうまい弁当って別にお客さんは欲しくない。一緒に例えばご飯やおかずとか何でもいいんだけど、それがないと美味しくないじゃないですか。それでおかずじゃあ作るの苦手ですってなったら、別に手作りじゃなくてもいいし、冷凍でもいい。究極何か別にめちゃくちゃ良くなくてもいいんだけど、ご飯に合う何かをセットで売ることが大事なんですよ。

だから大事なものは結局顧客にとって必要なものを用意して自分が得意なものを押し付けるんじゃなくて、必要とされているものを作る。それが専門性なんですね。

専門性とか活かしたい、仕事したいなら泥臭いことと向き合う必要があると。

結局私もデータエンジニアリング得意ですとかSnowflake得意ですって言っても、じゃあ仕事の9割が全部それで済むか?そんなことない。だってVPoDみたいな やらないと解けない問題があるから超えてるんですね。実際、そういう泥臭いことに向き合うのを現場は求めてるんですよね。

まっすぐ目の前の課題にまず向き合う。そうするとできることが増える。そしたら得意かなってことが出てくる。

別に得意じゃなくてもいいんすよ。できること増えたらそれでいいです。

それがだんだん専門性になってきて、いい感じになります。 真の得意はどこにあるかわかりません。

私もデータエンジニアリングとかSnowflakeとか、学生に何も知らなかった私になるつもりなかったから、そもそも仲間と仕事するとか面倒くさいみたいだったから全然わかんなかったけど。でも今はやっていくうちに「これ好きかも」とか「これできるかもしれないな」って、だんだんと専門になる。だったらとにかくたくさん問題解いた方が良い。

これが最速で実現できるのがフルサイクル開発。

最後に宣伝なんですけど、弊社CARTA HOLDINGSがソフトウェアエンジニア職とデータサイエンスエンジニア職を新卒募集してます。 ぜひ我々と「全部」やりましょう。はい、以上です。



🍁 CARTA プレエントリー 募集中 🍁

20近い事業を持つCARTA。26,27卒のプレエントリーを募集中!

必要なことは全部やる」エンジニア学生求ム!!!

26卒 プレエントリー27卒 プレエントリー

CARTAを詳しく知るなら CARTA GUIDE for Engineers エンジニア向け福利厚生を知るならCARTA TECH BLOG 挑戦と成長を支える働き方・福利厚生