VOYAGE ADTECH UNIT キャリア採用サイト

創り手と売り手がアドテクのプロフェッショナルとして
共にサービスを開発し、共に挑戦し続けている
それがVOYAGE ADTECH UNITです

Jobs 募集職種一覧
次へ

Service サービス

VOYAGE ADTECH UNITは株式会社fluct、株式会社Zucksを中心とした
アドテクノロジーに特化したユニットです

株式会社fluct

SSP(Supply-Side Platform)「fluct」、プライベートDMP(Data Management Platform)「cosmi Relationship Suite」の企画・開発・運営を行い、インターネット事業社の事業支援を行う

株式会社Zucks

スマートフォンに特化したアドネットワーク、アフィリエイト広告を通し、メディア・アプリ開発者のマネタイズ、広告主のプロモーションを支援

Service サービス

プロダクト

SSPやアドネットワーク、DMPなど、様々プロダクト・サービスを企画・開発しています

SSP Fluct

SSP fluct

SSP「fluct」は、提携する複数のアドネットワークやDSP、純広告など、様々なWEB 広告の中から最も収益性の高い広告を配信し、メディアの広告収益最大化および広告効果の向上を図る広告配信プラットフォームです。現在PC・モバイル・スマートフォンメディア/ アプリに対応し、5000 以上のメディアに広告を配信しています。
モバイル広告プラットフォーム Zucks

モバイル広告
プラットフォーム Zucks

Zucks では、スマートフォンやタブレット端末を含むモバイルアドプラットフォーム事業を展開しています。スマートフォンに特化したZucks Ad Network、Zucks Affiliate(成果報酬型広告)を通し、メディア・アプリ開発者のマネタイズ、広告主のプロモーションを支援しています。

Service サービス

業界内での位置づけ

広告主サイド・中立・媒体社サイドのそれぞれのフィールドでサービス展開をしています。

業界内での位置づけ

Service サービス

売上の推移とグループ内での内訳

過去21 ヶ月連続売上増加、VOYAGE GROUP 全体の売上の約半数を占め、今後さらに急成長が見込まれる事業です。

Session トークセッション

エンジニア×セールス プロダクト開発トークセッション

VOYAGE ADTECH UNITは作り手(エンジニア・プログラマ)と売り手(セールス・コンサルタント)によるユニットです。
両者に距離はなく、技術/サービス両方から共にプロダクト開発をしています。
ここでは、各プロダクトの作り手と売り手の対談を通して、ユニットの雰囲気をお伝えしたいと思います。

Session

大きなチームだからこそ「思いやり」が大切。
そしてfluctをダントツトップの地位に。

PC・モバイル・スマートフォンメディア/ アプリに対応し、5000以上のメディアに広告配信をしているSSP「fluct」。
総勢30名を超える大きなチームでのサービス開発について、話をきいてみました。

エンジニア Y.S

fluctの開発リーダーとして
エンジニアチームを率いる

コンサルタント K.Y

fluctを通してメディア収益化の
コンサルティングを行う

大きなメディアを任され、大きなトラフィックを捌く。
実積があるから、安心してお勧めできる。

(fluctに携わる上でのやりがいって何ですか?)

K.Y:fluctってネットメディアに広告を配信してマネタイズを支援するサービスなのですが、多くのメディアさまや有名メディアさまに広告配信を任せてもらえたりすることも増えてきて、大きなものを動かしているなぁっていう手応えを感じることが多いです。それは、エンジニアのみなさんが大量のトラフィックをさばいてくれるっていう絶対的な信頼があるからこそなのですが。

Y.S:アップアップすることもありますが(笑)まぁでも、大量のトラフィックが流れてくるっていうのもエンジニアとしてはやりがいで。というのも、私も十数年、色々なWEBサービスを作ってきましたが、その9割がほとんど使われずに人知れずクローズしちゃうんですよね。そんな中で、fluctは大ヒットサービスなんです。営業さんのお蔭で大量のトラフィックがくるし、広告が配信されて、メディアが儲かるという結果も出てるし。そういうところに、やりがいを感じますね。

K.Y:9割…!そうなんですね。でもほんとfluctはお客様にも「安心して任せられる」っておっしゃっていただいているんです。メディアも各社で収益性や安定性、コストなど、指標は色々あると思うんですが、総じてfluctなら安心だと選んでいただいています。そうした実績があるので、営業としても自信を持ってfluctをお勧めできることも、やりがいに感じます。

「思いやり」があるチーム。

(fluctってどんなチームですか?どんな人が、Fluctに向いていると思いますか?)

Y.S:fluct全体で30名を超える大きなチームなのですが、チーム全体で目標を共有して、お互いの職種をリスペクトするという基本的なところをちゃんと押さえているのかなと思います。

K.Y:そうですね、私は「思いやり」があるチームだなと感じています。たとえば、営業側のワガママをエンジニアさんがちょっと無理してでも受けてくれたりとか。それはもちろん背景を理解して、優先順位に都合を付けてくれているってことなんですが。その分、営業側も出来る限りエンジニアさんの作業の邪魔をしないよう心掛けます。例えば、集中して作業をしていそうな雰囲気だったら、一言事前にメッセンジャーで確認してから話をしにいくとか。小さなことかもしれませんが、そういう相手への思いやりがあるからこそ、大きなチームでも全体が巧く回っているのかなと思います。

Y.S:fluctに向いている人はどんな人かというと、現在のエンジニアチームは、全体で持っている目標に向けて各々が何をすべきか考えて動いて、fluct全体を回しているんですね。なので自分でやるべきことを理解して、考えて、自分で進めて行ける人が向いていると思います。きちんとできる人ですね。

K.Y:営業側は、特別な知識やスキルは必要無いのですが、メディアのことを好きな人、メディアについて詳しくなることが楽しいと思える人が向いていると思います。アドテク業界って覚える事が本当に沢山あり、最初は苦労することもけっこうあると思うんですが、そういった特性の人であればどんどん吸収できると思います。実際、他業界から転職してきたというメンバーも多いですね。甘くはないですが(笑)、チームでフォローする体制もありますし、教えてもらったことを結果で返していくっていうスタンスでチームも支え合っています。

お客様に選ばれるNo.1 SSPをめざし、ダントツトップの地位を築く。

(今後、fluctをどうしていきたいですか?)

Y.S:国内のSSP業者って、みんながみんな「国内最大級」って言ってるんですよね、今って(笑)。なので、もう文句なくダントツトップの規模にしていきたいですよね、fluctを。その為にできることって、当たり前のことを当たり前に、やるべきことをキチンとやっていくことかなぁと思います。

K.Y:その言葉がほんと頼もしいです。営業はエンジニアを信じてより多くのメディアさまに導入して頂くだけです。その為に営業が目指すべきは、お客様に選ばれるNo.1 SSPだと考えてます。選ばれるというのは、技術的な制約や規約的な制約など、色々な壁を超えてfluctを導入していただいて、その後もずっと使って頂けるということです。その為に営業としても、お客様に頼っていただけるように常に業界の最新情報を仕入れておいたり、営業スキルを上げたりしていかねばですね。「とりあえずfluct、やっぱりfluct」って社内で使ってるスローガンがあるのですが、fluctが目指しているのはそういう姿です。そうなったときに、ダントツトップの地位にもつけているんじゃないかって思います。

Session

開発スピードが事業成長に直結する。
市場の成長以上のスピードでZucksを大きくしていく。

モバイルアドプラットフォーム事業を展開しているZucks。
特に動きの早いスマホ広告市場でのサービス開発について、現場ではどのように動いているのか、話をきいてみました。

エンジニア M.M

Zucks Ad networkの開発・運営を行う

セールス T.K

広告代理店へZucks Ad networkを提案・販売している

Q毎の方針共有、週に1度の振り返り。
エンジニアと営業が同じ目標を目指す。

(エンジニアと営業が1つのチームとしてうまくいく秘訣は何だと思いますか?)

T.K:Qに1回は事業の振り返り・方針を全員で共有し、それに伴って開発したい機能の優先順位を決めてます。そして1週間走ってみて振り返りmtgをして、市場のニーズを汲んで優先度を微調整して、また走る。

M.M:大きな目標があって、そこに向かって色々やりたい事がある中で、エンジニアと営業が共に細かい軌道修正をしながら進めて行っている。ここらへんはZucksの特徴的なところかもしれませんね。

T.K:その他にもmtgは必要に応じて入れてます。mtg多いですかね?

M.M:いや、適度だと思いますよ。エンジニアのタスクは状況によってどんどん変わりますが、相談しながらmtgの頻度を調整しているので無理はないです。mtgをこま目にした方が、営業がいま何を狙って動いているのかが分かるので、エンジニアとしてもチーム全体の動きが掴みやすいです。

近い距離で本音を言い合えるからこそ、
スピーディーな開発ができる。

(Zucksはどんな雰囲気ですか?)

T.K:Zucksメンバー同士、言いたい事を言えてますよね。営業もエンジニアも。方向性や方針の共有を大事にしていて、目線が合っているので、議論しやすい環境だと思います。

M.M:ですね、お互いの距離が近いから、お客様からのフィードバックもすぐ貰えるし、こちらの意図もストレートに伝えられる

T.K市場のニーズや課題解決方法をスピーディーにシステム化していくのに、この距離感はとてもやり易いですね。欲しいモノを実現できて、それを売ることができる。営業にとってはとても嬉しい環境です。

M.M:限られたリソースの中で、何を優先すべきなのか、営業とエンジニアで目線が合っているからこそだと思います。普段の運用と新しい機能の開発のバランスについても理解してもらえているので、今までも大きな(配信)事故もなくこれているのかなと。

攻める時期がきた。
自ら考え動ける人と共にZucksを成長させていきたい。

(今後、Zucksをどうして行きたいと考えていますか?)

M.M:これまで順調に事業が成長してきていて、今後はよりそのスピードを加速させていきたいですね。やっと攻める時期が来たんじゃないかなと。これまでは競合サービスがやっている事をZucksでも出来るようにする、追いかけているフェーズでしたが、今後は自分たちがリードしていきたいですね。

T.K:そうですね、スマホ広告市場は成長市場ですが、それ以上の成長スピードでZucksを大きくしていきたいです。ここは絶対。スマホ広告の市場は動きが早いので、いかに広告主やメディアのニーズを拾って、スピーディーにシステム化して提供できるかが引き続き肝になってきますね。

M.M:ですね、開発スピードが事業の成長スピードに直結する。なので「言われて動く」じゃ到底間に合わない、仕事にならないけど、「自ら考えて自ら動く」人には魅力的な職場なんじゃないかなと思います。手を動かすだけでなくアイデアも出して、どんどん形にしていける人が活躍できるチームですね。

T.K:そういう方とぜひ一緒に働きたいですね!

CTO が聞く!アドテクの勘所 エンジニア座談会

アドテクユニットのエンジニアリングはプラットフォームとして大量のトラフィックを捌く
ミッションクリティカルな領域ですが、新しい技術にも積極的にチャレンジし続けています。攻めの姿勢を貫く技術の現場、
そこで働く3人のエンジニアのアドテクの勘所を探るため、CTOから率直な質問をぶつけていきたいと思います!

トークテーマ

分析基盤エンジニア@suzu_v

Zucks開発エンジニア@katzchang

fluct 開発エンジニア@ajiyoshi

VOYAGE GROUP CTO@makoga

広告配信サーバのトラフィックは最強

@makoga まずはアドテクのトラフィックって普通のメディアと違うよねってあたりから聞きたいけど、どう?

@katzchang すげえ緊張するなこれ。

一同 (笑)

@ajiyoshi 一般論でいって自社サービス向けの広告配信サーバを作るという時に、明らかにそのサービスのPVって言われているもの全部合わせた以上のトラフィックが通常来るんですよ。当たり前ですけど。なので、自社向けに広告配信サーバを作る場合ですら、その自社内でもっともトラフィックを喰らうのは、広告配信サーバになるはずです。なおかつ、我々は様々なメディアの広告配信も手がけているので、自社内で最強であるだけでなく、数千のメディアのトラフィックを全部合わせたトラフィックを喰らいます。

@makoga そうだよね。自社だけでなく、数千のメディアを束ねていて、そのPVが全部来るってところ。そこはある程度想定していたんだけど、やってみたらやっぱり凄いトラフィックくるんだって感じ?

@ajiyoshi えっとですね、それに関して言うと、ずっと(トラフィックに)追い立てられてはいますね。たとえば、唐突に大量のトラフィックが発生して「何や、コレは!」と思って監視のグラフ見ると「なるほど、これか!」、「どっかのプロ野球球団が日本一になりました、優勝しましたっていうセールとかキャンペーンとかやってたのか」ということがあります。このような世の中の動きみたいなものを受けますね。お盆だから連休だからトラフィックがこうなる、みたいな世の中の一部が見えている感じはします。

@makoga そうだよね。自社メディアだけだと自社の中でのマーケティング活動とか施策みたいなものに合わせて対策できるけど、事前にトラフィックが読めないってのがアドテクの大変なところってのはあるよね。

@ajiyoshi そうですね。

デザインするときの勘所は当たり前のことをちゃんとやること

@makoga そんなトラフィックが来るよってところから、次はもっと技術的な話を聞いていこうかなと思うんだけど。そういうのを踏まえて、技術の選定とかアーキテクチャをデザインする時に気をつけているポイントはどんなところ?

@katzchang いくつか小さいサービスの連携で成り立たせて、いろいろな変更の影響範囲を閉じ込めるとか。あとは、単一障害点みたいなものを当然作らない。サービス間の結合するとき、連携するサービスが繋がらない時でも正常に動く、何らかの動きをする、みたいなところは気をつけてやっています。

@suzu_v アドネットワークだと細かいサービスラインが増えるじゃないですか。APIが増えるっていうか。

@katzchang APIの切り替えはかなり頻繁に発生するので、下位互換性をどう保っていくかを大分気をつけています。

@makoga 下位互換性?

@katzchang 連携するサービスの昔のバージョンでも動くし、新しいバージョンでも動く。基本的にそういった作りにしています。

@ajiyoshi ScalaMatsuriでtodeskingさんも言ってましたが、アドテクやるまえに妄想していたものと比べて実際にやってみて思うことは、ハイパフォーマンスなソフトウェアを作るには当たり前のことをちゃんとやり続けるということが大事ということ。

@katzchang 逆に乱暴な妥協はあまりしないほうがいいかもしれないですね。

@makoga ほぉ、例えば。

@katzchang なんだろう、例えば、「こっちのサービスとあっちのサービスを一気にバージョン上げても上手く行くよね」みたいな更新の仕方はしない。複数サービスを1個にまとめるべきかも慎重に考える。

@ajiyoshi 互換性を失うような形でログのフォーマットとか変える時って、新旧両方出すって状態に移行して、次に新しい方を使うっていう状態に移行して、最後に古いのを止める。っていうのをいっぺんに切り替えるという乱暴な妥協っていうのがあるんですけど、やらない。「失敗したときの退路を無視するなら、もしかして全部うまく行けば5分で終わるかもしれない」というようなときに、乱暴な妥協はしない。どこかの手順がダメだったとしてもリカバリや後戻りができるような丁寧な手順を踏むと、終わるまで何日もかかるかもしれないけど、丁寧にやる。

@suzu_v そうですね。ログのフォーマットの話もそうなんですけど、マイグレーションじゃないけど両方走らせておいて正常に移ったことを確認してから閉じるとかはよくやりますね。まあでもそれも当たり前のことじゃないかっていう気もしますけどね。

@katzchang 例えばImmutable Infrastructureとか、広告はまあわりと世の中でやった方がいいと言われることをだいたいやる機会があるので、これはおもしろい分野ではあると思います。

@ajiyoshi いや、ほんとに。
インフラもそうだし、プログラムそのものもそうだし、テストみたいなものもおそらくそうだし、やった方がいいベースでいうとデータ解析とか、やってますよね。ビッグデータとか。普通広告をやってるならね、ちっちゃくはない、ちょっとしたデータが集まるので、それをちゃんとまあ解析して。分かるところは分かった方がいいだろうし。

@suzu_v 結構ボトムアップ的なアプローチが多いかなと思っていて、まあそのデータあるからやっぱ使おうよっていう話には当然なるし、広告ってどこまでいっても積み上げる部分がたくさんあるので、ベターなことをやろうよっていう流れにはなるかな。昨日イベントで話しているときにデータ分析しても新しいものは生まれないよねみたいな話をしていて、でもまあ改善にはなるので。続ければいいかなと思っていますけど。

※ここからデプロイ、Immutable Infrastructure、Blue-Green Deploymentの話で盛り上がりましたが、長すぎるので割愛

@suzu_v だんだん広告の話ではなくなってきてますね(笑)

@katzchang たぶんこれはおもしろい話だと。

@ajiyoshi おもしろい話なんだけど、この会の趣旨に合うかは別として話としては普通の #ajiting っぽくなってきている(笑)

一同 (笑)

いろんな言語を使い過ぎ!?

@makoga なんかだいぶまとめるのが難しい話が多くなってきたので、次もうちょっと分かりやすい話、実際に今使っている技術ってどんなのがありますか。

@ajiyoshi 言語の話からしますか。うちはカオスでPerlとPHPとRubyとErlangとPythonとJavaScriptと、Goがちょっとある。

@makoga だいぶカオスだよね(笑)

@katzchang うちがScalaとPHPとSchemeと、ぐらいですかね。あと微妙にRubyで書いたプラグインがちょっとあるかもしれないなあ。

@suzu_v そんなに変わらず、Erlangとかは使ってないですけど、Scalaも移しちゃったので、だからFluentdのプラグインがRubyで書いてあるのと、PHPで管理系とか書いているのと。

@katzchang Rust、動いているんでしたっけ。

@suzu_v Rust!Rustは結局やめました。なんかあれ、コンパイラのバージョンからFixしなきゃいけなくて、なんかそれ全然stableじゃないよねって話で。解析環境だとPythonとかPerlとかそのへんですかね。

@katzchang まあなんか好きなの使っていいような。

@suzu_v Gauche使ってるとか他の会社ではなかなか聞かないですけどね。

@katzchang あれはいいですよね。

@ajiyoshi 歯ブラシ(※)っぽいですよね。

@suzu_v (笑)

@katzchang スクリプト言語何にしようかなって。小さい、裏側のバッチ処理いくつか書きたかったんですけど、Rubyかなと思ったんですけど、なんとなくRubyに縁がないので。まあSchemeは素直で扱い易い言語だと思うので、いいと思います。

@suzu_v きっと、いつも話してるからそんなに違和感ないけど、(Scheme使うの)なぜって言われると難しい気がしますね。

@katzchang あれはほんとに素直な言語ですね。

@makoga 良く聞かれるのは、どうしてそんなにたくさんの言語を使うのか?

@katzchang これ、ScalaMatsuriでもちょっと話したんですけど、みんななんか基本使えるんですよ、プログラミング言語はなんでも。Hello, world!を立ち上げるのがたぶん一番難しくて、あと、使いこなせと言われるとまた難しくて、Schemeでマクロごりごり使えと言われると難しい。普通に使ってと言えば、みんな動く物はかける。
まあそんなに心配はない。優秀なエンジニアを雇っているからだ、と言われるとよく分からないんだけど、別に大丈夫じゃないかと思います。
前職の環境とか想像しても、これでこうやったらこう動くからっていうのは別にみんな、職業プログラマなら普通にがんばれるところかなと私は思います。

@ajiyoshi 私もそう思います。

※歯ブラシ:PHPの最初のバージョンの開発者であるRasmusが「PHP is about as exciting as your toothbrush. 」と言ったという話が元ネタ。

挑戦し続ける

@makoga じゃあ最後は、今後チャレンジしていきたいことについて。@suzu_vとかいっぱいありそうじゃん。

@suzu_v 僕のところは、やっぱり分析のところをみているので、実際に基盤とセットでどう分析していくのかというのが課題です。今まではシンプルにログ出てきたものを見ていこうかということをやっていて、まあHadoop使えばいいよねってやってきたんですけど、もうちょっと、いわゆるデータウェアハウス的なものに関するアプローチをしていかなければならないという風に思ってます。マスターデータと組み合わせて分析するっていうことがこれからすごく大事で、今も部分的にはやっているんですけどガッツリできていないところがあって、そこを使いやすくするというところがあるかなとは思っています。

なんで、最近Redshiftの環境を作って整備しているんですけど、とはいえ、やっぱりHadoopはHadoopでやる仕事があるし、MPPはMPPでやる仕事があるので、それをどう使い分けるかっていうのが一つの課題かなと思います。

@makoga 良い話ですね。

@suzu_v あ、もう一個あります。ターゲティングの仕組みがあるんですけど、それは結構シンプルに作っていて、軽量に動くからいいんですけど、なんかすごいヘビーな、リッチな仕組みで結果が遅く返ってくるのと、シンプルで結果が早く返ってくるのしかなくて、その間をいい感じにしたい。多様な条件なんだけど、結構早く結果が帰ってくるような仕組みを作りたくて、最近だとストリーム処理して、柔軟な条件でデータをフィルタして出すみたいな技術がありますけど、Esperとか。やっぱりその辺はやっぱりもうちょっとやるべきだと思います。

@makoga なるほどね。

@ajiyoshi 商売的なチャレンジではなく個人的なこだわりですけど、動作速度を超速にしたいですね。今はわりと富豪的に作っていて、広告配信サーバをPerlだのPHPだので書いています。RTBはErlangですけど。サーバ10台しかないのに最適化するなっていうのは基本なのでいいですよね。でも、100台以上あるとこれチューニングすると良いかもしれない。100台以上あると管理も大変みたいなのはあるので。そろそろ最適化してもいい!Michael A. Jackson先生の教えを破って。3つ目の、3つ目ないけど、幻の3つ目に入ってもいいかもしれないなと思っているので、超速にしたいっていうのはあります。

@makoga 「最適化するな」「まだするな」っていう最適化の法則ね。

@katzchang チャレンジか、難しい質問ですね…。

@makoga もっと楽(らく)したいとか?

@katzchang あー、楽はしたい。楽はしたいですね。
なんか、ほっといても動く、寝てても動くっていうのは。まあ今だいぶ寝れているので大丈夫なんですけど。 夜ゆっくり寝てても動くっていうのは今後、どれだけ複雑に、機能が多くなったり、配信規模が大きくなってしても、ゆっくり寝ていられるようにしたい。あとは、普通に負荷対策に追われているので、その辺をなんとかしたい部分はあります。

@makoga トラフィックの伸びというか、営業がガンガントラフィックを持ってくるという、すばらしい状態なので。

@suzu_v あー、そうですね。

@katzchang うれしい叫びってやつですね。

@makoga それに答えていきたいですね。

@katzchang データセンターにサーバ増設しましたって言ったとたんに営業チームが頑張ってガーンとトラフィックが伸びる。

@suzu_v あー、はい、そうですね。

@ajiyoshi そういう意味では実はLLではダメだったのかもしれないですね。まあそれは結果論だし。

@makoga まあ最初はよかったんじゃない?あの開発期間でFluctというSSPがリリースできたんだから。

@suzu_v なんか、普通にちゃんと喋って、そのまま音声で流した方がおもしろいんじゃないかっていう気がしてきますけどね、途中から。

@makoga そうそう。ちょっとそれも考えたんだよね。

@suzu_v でも聞いてくれる人が圧倒的に減っちゃうんですよね。

@katzchang voyage.fm。

@suzu_v voyage.fm。

@makoga そうそう。

@suzu_v でもajito.fmはおもしろいんじゃないかと。

@makoga うん、ajito.fmを定期的にやると面白いよね。

@suzu_v 個人的にはやりたい気持ちはありますけど。

@katzchang やりますか、世界に発信。

@suzu_v マイクとMacBookがあれば出来るので。

@makoga やっぱりそっちのほうが雰囲気が伝わるからね。

@suzu_v 伝わりますね。

@makoga ということで、今日はどうもありがとうございました。

全ては最高のサービスのために。
キーワードは「個の成長」×「チームワーク」

言うまでもなくアドテクノロジー業界は世界的にも成長市場であり、技術革新のスピードは日ごとに増しています。
そんなアドテク業界でより良いサービスを提供し、新たな価値を生みだして行くために、
VOYAGE ADTECH UNITは「個の成長」と「チームワーク」に重点を置き、制度・仕組み・環境を整えています。

社内勉強会誰しもが講師になり、生徒になって勉強する

VOYAGE ADTECH UNITでは毎日のように社内勉強会が開催されています。開催は自主的、参加も任意なのですが、新しい勉強会の告知をすると人数が集まりすぎて漏れてしまう人がいるほどです。勉強会の内容はバラエティに富んでおり、新卒による「アドテク業界勉強会」やSQL のスペシャリストによる全十三回での「SQL アンチパターン」まで様々です。 社内勉強会以外では、無料の外部勉強会はもちろん、社内の育成制度を使って有償の外部勉強会に参加する人もいます。また、毎年数名は海外カンファレンスにも参加しています。また外部の方が主催する勉強会の会場提供も行っています。仕事が忙しいときでも社内で行われていると1 時間だけ抜け出して話を聞けたりするのが魅力です。

クルー登壇の際のスライド一覧

最適な技術をエンジニア自ら選択裁量権が開発スピードを加速させる

VOYAGE ADTECH UNITでは技術を固定化しない方針でいます。ここで固定化しないというのは、ユニット全体では固定化しないということです。新しいプロダクトやサービスを生み出すときは、それに最適な技術をプロジェクトのリードエンジニアが選択するのが重要だと考えます。 プロジェクトのスピードを優先するために既存の枯れた技術を採用するのか、競合 優位性を高めるための機能を実現するために最新の技術を採用するのかは、プロジェクトごとの要件や制約を考慮し最適な技術を見極められるエンジニアが選択すべきと 考えているからです。 このように、プロジェクトごとの現場に任されている裁量権は大きく、結果として それがプロダクトやサービスの開発スピードを加速させています。

技術者の能力は技術者が評価技術評価会レビュー制度

評価は半期に1度、実積・能力・CCFB(360 度評価)の 3 軸で行います。基本的に評価は事業責任者やリーダーなどマネジメント層が行いますが、技術者の能力を非技術者が正しく評価するのは難しいところです。そこで、VOYAGE ADTECH UNIT では技術者の能力については「技術評価会」を設け、そこでのレビューを通して評価をするという制度を敷いています。レビュイーは半期の制作物とその制作目的・意図をまとめレビューに臨みます。レビュアーは実現力・改善力の 2 点を評価項目に置き、評価をします。 能力 さらなる能力向上に繋がるよう、評価内容は CTO+ レビュアーからレビュイーへフィードバックされます

全社総会での表彰仲間の功績を称賛し合う場

半年に一度、VOYAGE GROUP 総会が開催され、半期で最も活躍したクルーやプロジェクトへの表彰式を行っています。ベストセールス賞やベストエンジニア賞など7 つの賞があり、受賞者にはそれぞれオリジナルボトルトロフィーと賞金が授与されます。過去にアドテクユニットからも、コンサルタントとしての功績が認められたベストセールス賞や、cosmiの開発に貢献してベストエンジニア賞を輩出しています。
この総会での受賞を目標に、チームや個人でも日々の業務に取り組みます。また、この総会は仲間の功績を称賛し合う場でもあります。同じ目的・ビジョンへ向けて切磋琢磨する者同士が認め合う風土をVOYAGE ADTECH UNITでは大切にしています。

AJITING社内バーAJITO でアドテクについて語らう日々

VOYAGE GROUP 受付の裏にある社内バーAJITO は、定時以降に無料でアルコールを楽しむことができます。いつからか、お酒とノートPC を片手に技術やアドテクについて議論を交わすことをAJITING(アジティング)と呼ぶようになりました。ほぼ毎日、AJITING が開催されています。
わざわざ外に飲みに行くほどではないけれどちょっと相談したい、話したいという時に、上司とメンバーでお互い誘いを合ってAJITING したりもします。
また業務では直接かかわることのない人とも自然に交流が生まれやすいのもAJITING の特徴です。
時には外部の方を招いてイベントや交流会も開催されます。社内・社外ともAJITO でコミュニケーションを図り、良い関係性を構築しています。

また、社外からのAJITING参加も大歓迎しています。ご興味のある方はフォームよりご連絡ください。

Slack でのコミュニケーション業務のやりとりから、小ネタまで

VOYAGE ADTECH UNITではコミュニケーションツールの1つとしてSlackを導入しています。Trello、GitHubなどと連携させ、営業・エンジニア含むチームでこまめに情報を共有することにより、スピーディーな事業開発を促進しています。また、botやEmojiも導入し、時には業務と直接関係ない小ネタで盛り上がることも。チームの一体感を生み出すことにも一役買っているツールです。

Jobs 募集職種一覧

私たちに共感いただけた方、共に成長し、
共により良いサービスを作って行きたいと感じて頂けた方。

そんな方のエントリーをお待ちしています。現在募集中の職種はこちらです。

いきなりエントリーしたいわけではない、
もう少し詳しい話を聞いてみたいという方。

ぜひ一度、気兼ねなく話をしてみませんか。顔を合わせて話をした方が、お互いにとって色々話が早そうです。フォームからご連絡をお待ちしています。
※ここで収集した個人情報は弊社からの連絡に使用します。利用規約