• Home
  • コーポレートブログ Geniee’s BLOG
コーポレートブログ

Geniee’s BLOG

ジーニーは最先端の広告テクノロジーで
顧客の収益を最大化します。

こんにちは、R&D本部2019年卒エンジニアの浅井です。
マーケティングテクノロジー開発部MAJINグループでエンジニアをしています。
今回は、オンプレ上にあるHadoop環境をAWSに移行した話をしようと思います。

浅井迅馬/京都大学工学部卒業後、2019年にジーニーに入社
R&D本部マーケティングテクノロジー開発部・MAJIN開発チーム所属

Contents

1 オンプレ上の旧クラスタについて
2 AWS上の新規クラスタについて
3 おわりに 改善できた点・できなかった点

1  オンプレ上の旧クラスタについて

私の開発しているMAJIN(マーケティングオートメーションツール)というプロダクトでは、2016年からオンプレ環境にて構成されたHadoopクラスタを用いて、エンドユーザー行動ログの集計を行っています。
旧クラスタの構成は以下です。

■ハードウェア

クラスタはCloudera Managerを用いて管理されており、Cloudera Managerだけが立っているサーバー(cloudera)が1台あります。
Hadoopクラスタに対する問い合わせを行えるようなGatewayとなるサーバー(client)が2台、コアノードと呼ばれるようなサーバー(core)が19台、マスターノードと呼ばれるようなサーバー(master)が2台の全24台で構成されています。

■アプリケーション

・CDM/CDH
・HBase
・HDFS/YARN
・Zookeeper
・Spark2
・Java
・Scala
・Digdag

MAJINではHDFS及びHBaseをデータレイクとして扱っており、MapReduceやSparkでそれらの集計を行っています。ジョブのスケジューラーとしてはcronとDigdagが使われています。

■アーキテクチャ

旧クラスタの概略を図示すると、以下のようになっています。

旧オンプレアーキテクチャ

td-agentからHBase/HDFSにエンドユーザーの行動ログが流れてきます。そして、clientサーバーにてDigdag/cronを契機にそれらを集計するMapReduce/Sparkが走ります。
この旧クラスタで行われる集計は約30のMAJINの機能に関わっており、約60個のジョブが動いています。

さて、旧クラスタでは以下のような問題を抱えていました。

複雑化したclientサーバー
・Hadoopクラスタへの問い合わせが行えるということで、clientサーバーは様々な用途に使われてきました。
・MapReduceやSparkジョブのサブミット
・ジョブのスケジューラーが動いている
・cron及びDigdag
・ジョブのタスクランナーが動いている
・cronで定期実行される自社製タスクランナー
・Hadoopクラスタへのアドホックな問い合わせ
・MapReduceやSparkジョブのビルド
・Hadoopと関係のない謎のデーモン
clientサーバーは数年間「便利」に使われてきており、このサーバーが停止したらどうなるのかとを想定することすら難しい複雑な環境になっていました。

自社製タスクランナー
このクラスタを立ち上げた時から、cronと自社製のタスクランナーを合わせたジョブワークフローを利用しています。このタスクランナーはPerlで書かれており、さらにPython2系に依存しています。現在MAJINチームではPerlを読み書きできる人間がおらず、またPython2系はEOLを迎えていることから、この自社製タスクランナーのメンテナンス性が問題視されていました。

無駄の多いクラスター
前述の通り、このクラスター上では HDFSやHBaseといったデータレイクからYarnで管理されたジョブまで様々なHadoop周りのコンポーネントが動いています。
すべてが1つのクラスターで動いていることから、負荷が重なるとお互いにリソースを奪い合ってしまう可能性があります。もちろんYarnが完全にHDFSやHBaseのリソースを奪うということはなく、考えられる負荷の上限に合わせたクラスタ構成になっていますが、その分無駄も多くなってしまっています。

こうした問題がある中、2021年7月にクラスタを構成している大部分のサーバーの保守が切れるという事態が発生しました。
そこで、まず移行先として既存のオンプレ継続・IDCF・GCP・AWSと4つの選択肢が挙げられました。そして、移行の要件としては、既存の機能をそのまま移せること、移行自体のコストが小さいこと、移行後の保守コストが既存よりも下がることなどが求められていました。
それゆえに、可能な限りミドルウェア等の管理が不要でかつ既存のMapReduce・Sparkの資産が活かせる環境としてGCP・AWSが残り、最終的に既存のアプリケーションがAWS上で動作していることからAWSを選定しました。またAWSでデータの集計基盤を作るとしても様々な案が考えられますが、今回は移行自体のコストを下げるということで、Athenaなどは使わずAmazon EMRクラスタへ移行する計画が練られ、実行されました。

2 AWS上の新規クラスタについて

新規アーキテクチャの概略図は以下になっています。

大きな変更点としては、1つのクラスタ上で行われていたことを分離しました。
HDFSをS3に、HBaseをEMRクラスタに、MapReduceやSparkを実行するクラスタはSpot Fleetを用いて必要なときに必要な分のEMRクラスタを起動するように変更しました。
またclientサーバーはGatewayの役割だけをもつサーバーとタスクを実行するサーバーに分離しました。それに伴い、自社製タスクランナーを廃止しDigdagに統合しました。

この移行はまずtd-agentからのログをAWSへも転送させるところから着手しました。td-agentからKinesisへはfluent-plugin-kinesisを、HBaseへは既存の自社製pluginを使用しました。
続いてcronからDigdagへの移行に移りました。これによってタスクランナーとスケジューラーが別れて管理されていた問題が解消されました。また自社製タスクランナーにはなかった並行処理の機能や管理画面など、実行速度や運用面においても改善されました。
最終的な切り替えにあたっては処理を冪等に修正し、万が一誤ったデータを書き込んだとしても差し戻せばすぐに修正できる状態にすることで、無停止での移行を実現しました。

しかし、移行もスムーズに行えたわけではありませんでした。例えばDigdagのemrオペレーターはステージングディレクトリにusリージョン以外のS3バケットを指定できないというGitHub上のIssueに気づかず、バケットをusリージョン以外に作ってしまったため作り直しを行いました。他にもDigdagのemr-fleetオペレーターが存在しますが、今回利用にあたってステップの並行実行数やAllocation Strategyの設定ができなかったことから、必要なオプションを設定できるようにしました。

3  おわりに

この移行によって様々なメリットを得ることができました。
■Digdagによる集計アーキテクチャの一本化ができました。
■タスク実行クラスタの自由なプロビジョニングができるようになりました。
■継続して管理が必要なクラスタはHBaseのみになりました。

しかし、まだまだ課題が残っています。
■Digdagのタスクを実行しているサーバーは1台しかなくSPOFになっています。
・Ansibleによる構成管理を行っているため、すぐに復旧可能な状態ではありますが、今後はDigdagで可能なHA構成にする予定です。
■インフラの構成管理ができていません。
・本番環境は手動で作ってしまいました。
・ステージング環境からCloudFormationでの管理を行っています。

移行にあたって協力してくださったAWSソリューションアーキテクトの方々に、心から感謝申し上げます。
今後オンプレHadoopクラスタをAWSなどのクラウドサービスへ移行することを考えている方々の参考になれば幸いです。

一緒に働く仲間募集中!
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

2020年度下半期の優秀社員表彰(※)で、MVP(most valuable player)を受賞した、入社6年目の小林彩香さん。小林さんは、デマンドサイド事業本部においてPM(プロダクトマネージャー)とBD(事業開発)を兼任し、新規プロダクトを立ち上げ、ジーニーのDSP(Demand Side Platform)の成長に大きく貢献したことが評価されてMVPに選ばれました。

チーム一丸で辿り着いたプロジェクトの成功

私が兼務するPMとBDの役割は、事業の数値達成やプロジェクトの成功という目標に対し、何が足りないか、何をすべきかを考え、課題を解決していくことです。自分一人では結果を出すことはできず、チームメンバーと成功に対し諦めずやり抜き、結果が出せた時に初めてやりがいを感じる仕事だと思っています。

今回、アプリ向けの新規プロダクト立ち上げをMVPとして評価いただいたのですが、プロダクト開発後、しばらくはビジネス側の売上が安定しませんでした。それでも同じ目標を目指し、真剣に議論できるメンバーと推進することで、1年程過ぎたころにようやく売上が安定し始め、その後は順調に伸ばすことができました。MVP受賞と同じタイミングでVT(valuable team)も受賞し、皆と喜びを分かち合いました。ようやく事業としてのスタートが切れたと言える瞬間だったと思います。

伸び代しかない市場、皆で成果を分かち合いたい

デマンドサイド事業本部の向き合うマーケットは大きく、これからも成長が見込まれていますが、その中でジーニーがサービスを提供できているのはほんの一部分です。また、流動性のある市場でもあるため、今後も顧客の課題やニーズに合わせたプロダクトを作って提供し続けていきたいです。その上での事業成長、数値達成の喜びを、デマンドサイド事業に関わる皆と味わいたい。これからも、プロダクトとビジネスの橋渡しという役割で事業や組織の成長を創っていこうと思います。

※ジーニーの表彰制度について
ジーニーグループでは、全社員を対象として半期ごとに社員の表彰を行っています。その期に活躍した個人が「VP(valuable player)」「MVP(most valuable player)」、団体が「VT(valuable team)」「MVT(most valuable team)」として選ばれるほか、通年に一度、「年間MVM(most valuable manager)」や社員投票で選ばれる「ベストジーニスト」、「新人賞」などがあります。

ジーニーの2021年度の新入社員で、人事部(新卒採用担当)の鈴木と申します!
ジーニーの社風や魅力を少しでも伝えるべく、今回は、2021年4月1日から14日までの2週間に渡って行われた新卒研修の様子を紹介したいと思います!

contents

1.自己紹介
2.研修の全体像
3.印象的だった二つの研修
 3-1.「事業(プロダクト)理解研修
 3-2.グループワーク「プレゼン」研修
4.研修を終えて

1.自己紹介

改めまして、ジーニーの2021年度新入社員の鈴木と申します。この春はるばる神戸から上京し、週末はカメラを持って、おしゃれそうな都内のスポットを徘徊している典型的なおのぼりさんです!
2週間の新卒研修を経て人事部に配属され、業務を進めながら採用について学んでいます!!

2.研修の全体像

まずは新卒研修の形式や内容の一部をご紹介します。


ビジネスマナー研修

名刺交換や電話対応のロープレに挑戦しました。

プレゼンテーション研修

講師の先輩社員と。垂直思考や水平思考など、単なるプレゼンのテクニックにとどまらない様々な思考法を学ぶことができ、大満足の研修でした!

チームビルディング

チームビルディングでチーム対抗のペーパータワー作り。優勝チームは2mも積み上げていました!

3.印象的だった二つの研修

事務的な短時間の研修も含めると93コマもの講義を受けました!その中でも特に私の印象に残った研修を二つご紹介します。

3-1 「事業(プロダクト)理解」研修
一つめは「事業理解」研修です。
現在ジーニーが持つ八つの事業について、各事業部の社員がプレゼン形式で講義します。講義の後に質疑応答の時間があり、新入社員の質問に答えてくれました。
■
図や事例を用いた説明が多くて初心者でも理解しやすい
私は大学で「労働経済学」を専攻しており、ジーニーの事業領域であるITやマーケティングに関する知識はほぼありませんでした。そんな私にとって、ジーニーのBtoB(Business to Business)かつ無形商材を扱う事業は、最初イメージしづらいものでした。
しかし、この研修ではマーケティングやITの初心者にわかりやすい事例紹介や、視覚的に理解しやすい図を使った説明が多く、事業への理解を深めることができました。
また、同期同士でインプット内容を共有する機会や復習の場が設けられていたため、得た知識をしっかり定着させることができました。

■先輩・同期からの刺激をもらう機会に
現場で活躍する先輩社員から、今後事業を成長させるための方向性や取り組みを聞けたことは、これから新たに加わる身としてモチベーションが高まりました。
また、新入社員の中でも「大学時代の研究をDOOHで活用してみたい」というエンジニア職の同期や「マーケティングSaaS事業で難易度の高いSaaSの営業スキルを身につけ、事業と一緒に自分も成長していきたい」というビジネス職の同期と、お互いに興味のある事業部や目標を話し合うことができ、大きな刺激になりました。

3-2 グループワーク「プレゼン」研修
二つめに印象に残った研修は、グループで行うプレゼン研修です。
新入社員が5名1組に分かれて、指定されたテーマについて資料準備からステージでのプレゼンテーションまで行いました。

内容:プレゼン準備~発表
グループ人数:5名1組
準備期間:約2週間
課題テーマ:ジーニーの強みについて

研修が始まって最初の数日、私のグループには以下のような問題点がありました。
・指定されたテーマに対して、メンバー間で前提整理や具体的な定義・論点の確認をせずに議論していた。
・メンバーの意見や議論の流れに違和感や疑問を感じても口に出さなかった。
・ゴールまでの進行計画を立てていなかった。

このようなことから、テーマに対する共通認識がどんどんずれて議論が膠着し、何も進まないまま1、2時間が過ぎてしまうこともざらでした。

しかし、このプレゼン研修を通して、ジーニーが大切にしている「アウトプットに妥協しない」というスタンスを吸収しながら問題点を改善していき、社会人の課題への取り組み方を知ることができました。
この研修を通して学んだことを三つご紹介したいと思います。

■学び1.チームで共通認識を持つことの大切さ
準備の進め方やテーマに対する論点についての共通認識をグループで持つことの大切さを学びました。

研修3日目に先輩から「社会人として、与えられた仕事はゴールを明確にしてスケジュールを決めてやり切るのが基本だよ」とアドバイスを受けました。
この言葉で、自分たちはこのテーマに対してこれから何をどう話し合っていくか共通認識すら持てていないことに気づき、まずはグループで認識のすり合わせに取り組みました。

次に、発表内容の全体の骨子を作り、議論のステップや方向性を決めました。
作成した骨子に基づき、議論に必要な社内情報や、その調べ方を洗い出し、課題に割ける時間を考えながら各タスクに対して動くようにしました。
このようにグループで要点を丁寧にすり合わせることで、「今は何について議論をする時間か」の認識が合い、議論がスムーズに進むようになりました。

■学び2.当事者意識を持つ重要さ
二つめの学びは、「当事者意識を持つ」ことの重要性です。これはジーニーのブランドパーソナリティ(BP)の一つです。ジーニーにはこのBPを体現した社員が多く、年次や役職を問わず意見を伝え合って業務を改善していく社風があります。
そうした先輩の影響をうけて、私達も「今はそれについて議論をする時間ではなくて、この議論をした方が前に進むのではないか」といった指摘や、「ここは表現を変えた方が私達の意見が伝わりやすい」などの改善意見を妥協せずに伝え合うようになりました。
プレゼン研修の終わりごろには、グループのメンバー全員が積極的に発言し、自分の考えを共有するようになっていました。
このように、何事も人任せにせず、自分の考えや業務を進める上で気づいた課題を共有する姿勢は配属後の業務にも活かされています。

■
学び3.やり抜くことの重要さ
最後の気づきは、月並みですが「やり抜くことの大切さ」です。
プレゼン研修の途中で講師からフィードバックをもらう機会があり、本来伝えたい内容の半分も伝わっていなかったという出来事がありました。
しかし、私達のグループは「自分達のアイデアやロジックは生かして、後は伝え方を改善していこう」と前向きにとらえ、妥協せずに言い回しや使用する図などを改善することにしました。
グループのなかでも「ここまでは今日中に形にしよう!」「ここは納得できるまでやり切ろう」という発言が増え、予定時間を過ぎて議論する日もありました。
また、発表直前までリハーサルを行い、他のグループにフィードバックをもらいながら細かな表現や言い回しまで修正をかさねました。
こうして最後までプレゼンの完成度を貪欲に高めた結果、本番の発表では「ロジカルでわかりやすかった」という評価をもらうことができました。
グループワーク研修本番

4.研修を終えて

新卒研修を受けるまでは、「ITやマーケティングの知識のない自分が同期についていけるのか」や「任せてもらった仕事が全くできなかったらどうしよう」という不安を感じていました。しかし、研修で事業の知識や社会人のポータブルスキルを学べたことで、仕事を進めるイメージを持つことができ、不安も解消されました。

配属後、自分でできる仕事も増えてきてはいる実感はありますが、まだまだ難しい課題に直面して自分の知識や実力の不足を実感する場面も沢山あります。
そのような時は、グループワーク研修で学んだ「当事者意識を持つ」や「やり抜く」といった仕事への向き合い方を思い出し、「できないことを不安に思うのではなく、自分から一歩一歩できることを増やしていくしかない」と前向きなマインドで新しいインプットに取り組むようにしています。

なにより、ジーニーには新卒が自ら学んで行くことを応援してくれる風土があります。
例えば先輩が新卒の疑問に向き合ってくれますし、新しい知識をインプットする書籍補助制度なども充実しています。
そんな環境があるからこそ、「自分もできることを増やして、会社の成長に貢献したい!!」と主体的に日々の業務に取り組めています。

ジーニーは「日本発の世界的なテクノロジーカンパニーを作る」という大きなビジョンを掲げている会社です。新入社員である私も、会社や事業部といった組織の目標を当事者としてとらえ、会社と自身の成長をリンクさせて働くことができています。
こんな環境で仕事をすることに魅力を感じてくださった方がいらっしゃったら、ぜひ一緒に働きたいです!

最後までお読みいただきありがとうございました。

一緒に働く仲間募集中!
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

Date
Author
社風やジーニーでの働き方などをご紹介していきます。 ジーニー人事チーム
Tag

2021年4月、ジーニーでは新たなCxOが誕生し、5人のCxO体制となりました。今後、ジーニーを牽引していくCxOを代表して、初のCPO(Chief Product Officer)に就任した大橋弘崇さんに、ジーニーの展望や全社のプロダクトの方向性について伺いました。


大橋 弘崇(おおはし・ひろたか)
執行役員CPO 兼 R&D本部 プロダクトマネジメント部 部長/アド・プラットフォーム開発部 LAMP開発グループ 部長/マーケティングテクノロジー事業本部 カスタマーサクセス部 部長/ビジネスサーチテクノロジ株式会社 取締役

ーー4月、CPOに就任されました。抱負を聞かせてください。

CPO(Chief Product Officer)はあまり日本でも就任者が少なく、馴染みがない方も多いと思いますが、海外ではメジャーな役割です。自分もまだ手探り状態ですが、自分がジーニーでやる仕事がCPOの仕事になっていく、と思ってやっています。

CPOとしてまず進めていきたいのは「発信」と「PMの育成」

二つ観点があると思っていて、一つは「発信」。
プロダクトのビジョンや重要な方針を全社に伝えていくべき立場になったと思っています。
各事業部の仕事が横でつながるようなビジョン、プロダクトの新機能やクライアントの声を発信できるような場を作りたいですね。

プロダクトは別に開発だけのものじゃない。使う人や売る人やサポートする人、関わる人全員のプロダクトなので、開発者と使い手、売り手を繋ぐ存在として全員が幸せになるようなプロダクト創りをしていきたいと思います。

もう一つの観点は、「プロダクトマネージャー(以下、PM)の育成」。事業の成長や成功の可否を握るPMについては代表取締役社長の工藤さんからも以前から話があり、ここはより力を入れて進めたいと思っています。

ーーPMの育成が大切だ、というメッセージをもう少し掘り下げて教えてください。

PMの役割は会社によって多少異なるんですが、共通しているのはプロダクトに関する最終決定を行い、責任を持つということ。プロダクトのロードマップ作りなどの計画策定、企画立案から、顧客体験の設計、ローンチ後の改善など、幅広い領域でやることやスキルが求められ、全ての領域で社内外のプロフェッショナルを巻き込んで推進していく必要がある。

今後ジーニーが時価総額1兆円の企業になっていくうえで、ジーニーの文化や財産である自社プロダクトという軸は非常に重要になります。そのプロダクトを中心で支える存在がPMです。1兆円企業になると、今よりも多数のプロダクトを世の中に提供している企業になるでしょう。その為にも現任のPMの人には非常に期待をしていますし、社内外から優秀な人材が集まってくるような部署にしたいと思っています。

PMの意思決定が事業の鍵を握る

1年程度で一領域では成果を出せるようになりますが、事業ドメインが変わると動き方や必要な知識、スキルも変わる。PMとして本当に仕事ができるようになるには、優秀な人でも3年くらいかかるんですよ。

ジーニーの場合は、PMへの期待や裁量が比較的大きい方だと思いますが、まだまだロールモデルが曖昧なので、そもそもPMはどうあるべきかを定義して自ら体現し、若手を一人前のPMになるまで育成するのが自分の役目だと思っています。

一方で、事業の観点でプロダクトを見ると、ジーニーは複数のマーケティングプロダクトを抱えていますので、俯瞰して全体のバランスをとり、プロダクトのポートフォリオで戦っていく観点を磨き続ける必要があると思っています。

ジーニーに全て任せたい、といっていただけるように

大きな方向性としては、プロダクト単体ではなくジーニーの全プロダクトを使ってくれるお客様を増やしていきたいと思っています。これからもジーニーのプロダクトはマーケティングに必要な機能をどんどん追加していく予定です。

世間では企業が複数のSaaSツールを導入することが当たり前になってきましたが、反面統合管理が難しくなってきているという現実があります。先日、ある企業の方が「32種類のツールを部署ごとにバラバラに使っていてデータ管理が難しく、非効率なんだ」という課題を話してくれました。都度違う担当者と打ち合わせをしていくというのは、非常に難しいですし非効率。また、マーケティングの課題が明確にわかっている担当者であればどのツールがソリューションになりうるかがわかりますが、全てのマーケ担当者や営業担当者がそうではないと思います。

企業のDXが進めば自然と導入ツール数が増えると思いますが、それにより複数サービスの弊害に直面する企業は今後増えていくと思います。ジーニーがワンパッケージでソリューションを提供できるから、ジーニーに任せておけばマーケティングの課題は全て解決する、といってもらえる存在になりたいと思います。

最終的には各領域でもちろんNo.1を目指しますが、マーケティングツールはジーニーに全て任せる、といってくださるお客様の数を伸ばしていきたいと思っています。

そのためにはプロダクト同士の機能連携も強化していかないといけないし、連携できるからこそ提供できるバリューを強化していきたい。SFA/CRMのデータをMAのセグメントに使う等という基本的な連携は、その一例ですね。

ーージーニー流のNo.1の目指し方とはどういうものなんでしょうか?

ジーニーは、これまでプロダクトを作ったり改善したりしていく際に、GoogleやSalesforceなどのグローバルでトップシェアを持つ企業をベンチマークとして設定して成長してきました。海外の先行者を見習いつつ、ローカルのクライアントの声を聴きながらユーザー体験や機能の土台を顧客に合わせて創っていく、という戦い方がジーニー流のサービスの磨き方だと思います。

ーー今後の中長期の方針についても教えてください。

社のミッション「テクノロジーで新しい価値を創造し、クライアントの成功をともに創る」をより具体的なプロダクトビジョンという形で体現し、どんな世界をジーニーが目指していくのか、を社内外に対して発信していきたいです。

プロダクトを通じて、ジーニーのファンを増やしていくというのも重要な自分のミッション。ファンの顧客が増えていくことで更にプロダクトに投資ができ、ファンの顧客により価値を返すことができる、という好循環を創っていきたいですね。

今のビジネス活用における技術トレンドは人工知能やAI、機械学習です。
人がやっている単純作業を機械に置き換えようというDXの流れのまさに真っ只中を生きていると思います。昨年、ジーニーでは「GENIEE DSP」でAIを使った自動入札機能をリリース(※)しましたが、強みとなる最先端のテクノロジーをプロダクトに昇華させ、AIや自動化によって業務を効率化し、全ての働く人により創造的な仕事にフォーカスしてもらう環境を提供することで、クライアントの成功を共に創っていきたいと思います。

また、お客様の成功を作るには、ツールを提供して終わりではありません。常に「もっとお客様が楽になるにはどうすれば良いか、業績を上げるにはどういった使い方ができるだろうか」と言う提案設計が求められています。ジーニーではカスタマーサクセスの領域も積極的に強化しており、色々なことができる「製品」を顧客の課題を解決できる「サービス」に昇華させ、顧客の成功を共に創るまで伴走できる組織でありたいと思います。
その為にも、ジーニー社員が顧客の成功にフォーカスできるような体制や環境作りの一環としてジーニー自体のDXも更に推進していけるように社内外に働きかけを行っていきます。

※ 2020年11月、「GENIEE DSP」において AIを利用た自動入札機能の提供を開始
https://geniee.co.jp/news/20201111/259

何かをゼロから生み出す楽しさ、作り出したものを使ってもらえる喜び

何かをゼロからつくり出すって、すごく面白いことだと思うんですよ。プロダクト開発にはゼロイチでものを生み出す要素が詰まっていて、エンジニアが構想して「作れる」と言ったものは、時間がかかっても必ずできるんです。
そうして世に生み出したものを多くのお客様に使ってもらえると、すごく嬉しいし面白い。そんな体験にジーニー社員には関わってほしいし、それで顧客の成功を創りながら共に喜び、業界のNo.1を目指しにいけるってワクワクしますよね。ジーニーには確かな最先端のテクノロジーがあり、それを支えられる素晴らしい仲間が揃っています。一緒に戦ってくれる仲間は常に募集していますので、この記事を見て少しでもジーニーに興味を持ってくださったら嬉しいです。

こんにちは、R&D本部 18卒エンジニアの鈴木です。
経営システム情報開発部でリーダーをしています。
今回はタイトルの通り、リーダー業務について紹介しようと思います。
(経営システム情報開発部 鈴木望 2018年新卒でジーニーに入社。早稲田大学理工学部出身)

Contents

1 普段の業務紹介
2 メンバーとリーダーの違いとは
3 これからリーダーになる人へ

1 普段の業務紹介

開発業務
私の所属する経営情報システム開発部では、主に社内の各プロダクトを統合する業務管理ハブの開発を行っています。それに伴い社内の工数削減につながる業務を担うことが多いです。直近の業務だと、財務会計システムのオンプレミスソフトウェアからクラウドSaaSへの移行などを行っていました。
リーダーとは言っても、開発業務自体はメンバーと特に違いはありません。組織運営などがある分、実際に手を動かす時間は減ります。

プロジェクト管理
開発業務の中には、数日で終わるものから要件定義含めて数年かかるものがあります。
開発業務の箇所で紹介した財務会計システムの移行なども全体で1年ほどかかった大きなものでした。
小さな開発でもスケジュールを決めることは必要ですが、プロジェクトが大きくなればなるほどスケジュールの管理が重要になってきます。
また、プロジェクトの中のタスクを持ちつつも、プロジェクト全体の進捗にも意識を向けてPL(※1)のフォローをする必要があります。そのためには、各メンバーのタスク内容を把握して適切にフォローを行えるようにした上で、全体的にプロジェクトを俯瞰できることも重要になります。

組織運営
組織運営と言っても色々あるとは思いますが、今回は「チーム」運営に絞って話そうと思います。その中でも効果がすぐに期待できる会議運営とそれに付随した当事者意識の促進に関して話そうと思います。

各チームで定例的に開催している会議体はいくつかあると思いますが、会議自体に対しての改善を行っていく姿勢を少なくともリーダーは持つ必要があります。つまり自チームの運営に関して当事者としての意識をより強く持つ必要があるということです。また、チームメンバーに対しても当事者としての意識をより強く持たせるように促す必要があります。

今は在宅勤務をしている方も多いと思いますが、その中で当事者としての意識の有無がより顕著に出てきていると思います。例えば、会議に参加しているが裏で別の作業をしていて発言をしない、あるいは会議には参加しているが終始受け身になっているなどです。
前者に関しての問題点は、会議の進行中に別作業をしているので、会議の進行自体に対して何も意識を向けられないこと、また自分が会議に参加している理由を考えて提案を行うところまで行動にできないことです。後者に関しての問題点は、課題感を正確に把握してフィードバックを行うことができないことです。

会議で当事者意識を持ってもらうために、私は例えば、会議の中で、発言のない人に意見を聞いてみる、あるいはタスクを持ってもらうなどして積極的に関わらざるをえない状況を作っています。また全員でフィードバックの会(※2)を設けてチームメンバーに対してお互いに改善のためのフィードバックを与えるようにしたことで、それぞれがチームメンバーをちゃんと意識して業務を行えるようになったと思います。また、それによって意見を出す敷居が下がり、積極的に話し合いが行えるようになったと感じています。

このように、現状の課題を洗い出し、適切なアクションを考えチームに落とし込むことも業務の一つになると思います。

(※1)プロジェクトリーダーのこと。今回は比較的大きなプロジェクトだったので、プロジェクトに関わる各チームで一人ずつ割り当て、担当する各チームのプロジェクト作業を管理する役割を担ってもらいました。
(※2)お互いのメンバーに関して、改善のためのフィードバックを与える会。開発に関わる業務だけでなく、会議進行やslackでのメッセージの送り方など幅広くフィードバックを与えています。

2 メンバーとリーダーの違いとは

視座と価値の出し方
一般的に言われていることだと思いますが、メンバーとリーダーの違いとして視座の違いがあるかと思います。自分の動きだけではなく、メンバー全体の動き、延いてはチームの動きも考える必要があるからです。

リーダーとして動く中で意識していることは、メンバーとマネージャーの間になぜリーダーというポジションがあるのかということです。また、マネージャーや部長と動きの方向性がずれていないかということです。

メンバー全体の動きという点で一例をあげます。
メンバー全体の開発の進捗を、音頭を取ってスケジュール管理していくというのは、一つの重要な役割になるかと思います。メンバー一人ひとりの開発タスクの確認まで細かいことはマネージャーが行う必要はなくリーダーが行い、まとめたものをマネージャーに報告すればいいからです。マネージャーの資源はより上位の組織運営などに使われるべきです。

次に、チームの動きに関して一例をあげます。
チームの動きを考えていく姿勢は確かに重要なものです。しかし、同じ方向を向いていなければリーダー以下のチームの動きとしてはうまくいっているように見えても、より広いグループや部という視点から見ると混乱を招いているだけです。

このように、リーダーとしての動き方の前提になるのは、マネージャーや部長と同じ方向性を持った上で、メンバーとマネージャーの間のブリッジになることです。そのためにもマネージャーとは密にコミュニケーションをとって業務を行っていくことが重要です。
その上で、「どのように」「どれくらいの速さで」チームを取りまとめて動いていけるか、また、「どれくらい」マネージャーや部長の手からメンバーの細かいタスクへの意識を手放せられるかが、リーダーとしての価値の出し方になると思います。

3 これからリーダーになる人へ

いかがでしたか。
これからリーダーになる方や、リーダーではあるがメンバーとの違いを意識できていない方はこの機会に一度、なぜメンバーとマネージャーの間にリーダーという役職があるのか振り返ってみてはいかがでしょうか。これからの働き方のヒントが浮かび上がってくるのではないでしょうか。

一緒に働く仲間募集中!
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

こんにちは、R&D本部 20卒エンジニアの高橋です。
今回はタイトルの通り、GENIEEで行われた20卒エンジニア研修について、受講者という視点から振り返ってみたいと思います。

※ GENIEEにおけるエンジニア研修は “bootcamp” と呼ばれており、実施年度と共に表現します。(例 : 2020年度のbootcamp → bootcamp2020)
また、ビジネスを含む新卒全体に対する研修もbootcampの前に別途実施されます。

CONTENTS

1 新卒エンジニア研修「bootcamp」概要
2 研修内容
3 アンケートサマリ〜受講者から見る bootcamp2020〜
・評判のよかった研修について
・フルリモート実施について よかった点、課題点
4 来年度に向けて

1 新卒エンジニア研修「bootcamp」概要

例年、bootcampは1ヶ月半程度の期間で実施されており、GENIEEで使用されている技術を中心に、業務に最低限必要となる技術について学びます。また、具体的な研修内容やスケジュールについては、状況に合わせて毎年調整されています。
bootcamp2020は、個別研修が4月中旬から5月中旬頃、チーム研修が5月下旬から6月上旬頃、というスケジュールで実施されました。
また、新型コロナウイルスの影響が考慮され、bootcamp初のフルリモートでの実施となりました。

2 研修内容

bootcamp2020で実際に行われた主な研修内容について簡単にご紹介していきたいと思います。
【Git研修】
Gitの基礎的な知識と使い方を知り、コード管理の基礎を学びます。
【UNIXコマンド基礎研修】
よく使うUNIXコマンドを知り、状況に応じた使い分け方、調べ方を学びます。
【プロダクトマネジメント研修 】
プロダクト開発の一連の考え方を知り、プロダクトマネージャーの役割について学びます。
【ネットワークと仮想技術研修】
仮想化技術の基礎知識から、代表技術の一つであるDockerの仕組みと使い方について学びます。
また、コンテナ間の接続を通して、ネットワーク構築について学びます。
【MySQL研修】
データベースの基礎からその使い方、注意点など、業務に最低限必要となるデータベースに関する知識を学びます。
また、テーブル設計やレプリケーションなど、データベース設計の基礎知識を学びます。
【CSS研修】
CSSの位置付けとその用途を知り、その調べ方と試し方を学びます。
【LEMP研修】
Webアプリケーションの基礎から構築までを学びます。
※ LEMP; Linux, Engine-X(nginx), MySQL(or MariaDB), PHP(or Python) の頭文字を取ったもの
【アルゴリズムとデータ構造研修】
基本的なアルゴリズムとデータ構造を知り、計算量の感覚を学びます。
【JavaScript研修】
JavaScriptの基礎的な知識から、Next.js, React といった、ライブラリやフレームワークについて学びます。
また、サーバサイドである Node.js や、JavaScriptの拡張言語であるTypeScriptについて学びます。
【Python研修】
Pythonの基本的な構文とライブラリについて学びます。
【デバッグ研修】
デバッグの基本的な考え方や当たりの付け方を知り、デバッグ全体の流れを学びます。
【Go研修】
Go言語の基本的な構文やテストの書き方について学びます。
また、Go言語における非同期処理やプロファイラについても学びます。
【クラウド研修】
クラウドの基礎知識や、GENIEEで活用されているサービスの基本的な使い方について学びます。
【サーバー作成研修】
サーバーの基礎知識から構築までを、実際の作成をしながら学びます。
【開発ルール研修】
GENIEEにおける開発ルールを知り、実際の業務における開発の流れを学びます。
【セキュリティ研修】
セキュリティの基礎と重要性を理解し、開発で注意すべき点について学びます。
【テスト研修】
開発におけるテストの重要性とテストの種類などを知り、目的に応じたテストの仕方を学びます。
【コードレビュー研修】
コードレビューの意義と注意点を理解し、開発におけるレビューの仕方を学びます。
【Git研修(応用編)】
Gitにおけるcommit操作やブランチモデルといった、より高度なGitについての知識を学びます。
【チーム開発研修】
実際にチームに分かれ、チーム開発の流れを開発を通して学びます。

3 受講者から見る bootcamp2020

ここからは、研修後にbootcamp2020運営の方々が取ってくださった20卒エンジニアに対するアンケートの回答を元に、受講者視点から振り返ってみたいと思います。

評判の良かった研修について
各自で3つほど良かったと思う研修を選んでもらい、その理由とともに回答を集めた結果が以下になります。

また、上位3位(3位はタイなので4つ) の講義について、いくつかの詳細な回答とともにご紹介します。
【Go研修】
「Goの使い方から、低レイヤーを扱う処理についても実装する機会があったのが良かったです」
「初めてGoを触ったのですが、Goを好きになれるような研修でした」
【JavaScript研修】
「充実したドキュメントにしたがって進めていくことで、JavaScript, TypeScript, Reactのことなどフロントに関する知識を沢山仕入れることができました」
「モダンなサーバーサイド開発を学べて嬉しかったです。RESTAPI・ページネーション・セキュリティ認証などWeb開発において必要な技術を学ぶことができました」
【ネットワークと仮想技術研修】
「今まで Docker やデータベースに触る機会があまりなかったのですが、研修以降 Docker コンテナを作って作業するのは当たり前になりました」
「ネットワーク的な知識も勉強できたのが良かったです。研修序盤にあったことでその後の研修でも環境構築に利用できました」
【サーバ作成研修】
「ソケットを通してバイト列を送受信する仕組みを作ることで、同時に個人的に学んでいたHTTPの理解が進みました」
「作業時間に余裕があったので、設計にこだわることができました。また、他人の成果物を読んで、他の人がどういうアプローチをしたのか探ることができたのも良かったです」

フルリモート実施について
フルリモートという実施形式に対しての意見についてもご紹介したいと思います。こちらについては、各自良かった点と課題点を自由回答するアンケート形式でした。

リモート研修 良かった点
まずは、良かった点についてです。良かった点については、それぞれ異なる視点の意見が多く見られました。以下に簡単にまとめたものをご紹介します。

【環境要因による効率化】
周りに人が居ないことで、集中力を保つことができたり、自分のペースで自由に進めることができた。
【通勤時間分の有効活用】
通勤時間がないことで、その時間を有効に使うことができた。
【リモート開発の練習】
実際のリモートでの開発や、文字ベースでのコミュニケーションの取り方の練習になった。

リモート研修 課題点
次に、課題点についてです。課題点については、挙がった意見のほとんどがコミュニケーションに関するものでした。以下に簡単にまとめたものをご紹介します。

【コミュニケーションの難航】
同期間のコミュニケーションが取りにくく、関係構築に時間がかかった。
また、細々としたものなど、質問自体がし難いと感じた。

4 来年度に向けて

bootcamp2021は、筆者を含めた20卒エンジニアが主体となって運営をすることになり、実施に向けた準備を着々と進めています。bootcamp2020での良かった点はしっかり踏襲した上で、一部研修での課題難易度調整および説明不足の解消や、フルリモート研修におけるコミュニケーションの更なる促進など、反省点はしっかり活かし、より良い研修を目指していきたいと思います。

一緒に働く仲間募集中!
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

はじめまして。
昨年10月に入社した新卒エンジニアの鈴木です。現在情報システムグループで社内SEをやっています。
今回は社内SEとしてこの半年間やってきたことを振り返って行こうと思います。
(情報システムチーム 鈴木悠太 2020新卒でジーニーに入社。慶應義塾大学理工学部出身)

Contents

1 社内SEって?
2 直面した問題① 管理すべきものが多い!
3 GASとSlack Incoming Webhookで自動通知飛ばしてみた。
4 直面した問題② タスクがめちゃくちゃ多い!
5 Jira Core導入
6 さいごに

1 社内SEって?

社内SEの主な仕事は以下の3つです。
・社内のIT問合せ対応
・社内の資産管理・調達
・アカウントの管理・設定
社内のITコンシェルジュのような存在をイメージしていただければ分かりやすいかと思います。
一口に「問合せ」と言っても内容が非常に多岐にわたるので最初は仕事を覚えることに必死でした。
具体的にはPCやアダプタの貸出・交換対応やVPN設定、メーリングリストのメンバー管理など、一つひとつ列挙していくとキリがありません。
社内SEは社内全部署がお客様です。円滑なコミュニケーションや他部署への理解が求められます。コミュ障を自負する理系インキャの私でもコミュ力はついてきたかなと思います。
とにかく聞かれたことには適切な応答ができるように日々粛々と業務をこなしています。

2 直面した問題① 管理すべきものが多い!

社内SEが管理するものは非常に多いです。
・PC
・モバイル端末
・周辺機器
・各種アカウント
例えばgithubアカウントの登録やVPN接続などの申請はスプレッドシートで受け付けているのですが、社内SEはこれらのシートを毎日逐一チェックする必要があります。面倒くさがり屋の私としてはこのチェック作業は煩わしい事限り無しでした。

3 GASとSlack Incoming Webhookで自動通知飛ばしてみた。
チェックは人が行うものだからミスや発見遅れが生じる可能性があるよねってことで申請シートに記入されたらslackへ通知が行くような仕組みを作りました。
スプレッドシートとGAS(Google Apps Script)は非常に相性が良いです。シートの情報を自由自在に取得できます。

このようにシートの記入列にユーザ名が記入されたらセルの内容を取得してslackに通知を飛ばしています。(本記事ではサンプルコードを見易くするため、一部マジックナンバーをそのまま記載しています)

Webhook URLはここから取得できます。
以上の工程を経てSlackチャンネルに通知が飛んでくるようになりました

簡単な仕掛けではありますが2つの効果を生み出すことができました。やったぜ。
・毎日シートをチェックする時間をゼロに
・チェック漏れがなくなった
エンジニアブログっぽい感じにしたかったのでコードとか入れて格好つけました。普段はもっと泥臭いことやってます。現在は機器管理台帳と格闘中です。

4 直面した問題② タスクがめちゃくちゃ多い!

これには困りました。
社内SEの仕事に抜け・漏れは許されません。毎日様々な依頼や申請を捌きながら機器管理や入退社の定常業務をこなしていく必要があります。そのためにはタスクを正確に管理し、チームメンバー間でも進捗や課題を共有認識として持っておく必要があります。
スピード感を持ちながらもヒューマンエラーを限りなくゼロにしていく努力が求められるわけです。
現在社内のIT問合せは「情シス依頼」という形でSlackコマンドとGoogleフォームから受け付けています。

この仕組み自体は非常に便利でよくできています。しかしスプレッドシートでのタスク管理に難がありました。
・ひとつの依頼内容を1行で表現しているので横に長く見辛い
・タスクのステータス管理が難しい
・そもそもR&DではタスクをJiraで管理している

5 Jira Core導入

こういったタスク管理状況を改善すべくJira Coreというビジネス・運用チーム向けのタスク管理ツールを導入しました。
Jira Coreの特徴は以下の通り。
・カンバンボードでのタスク管理
・カレンダーによる期日の管理
・詳細画面があるのでタスクの全容が見えやすい
・サマリ・統計レポート機能
・UIがイケてるぜ
イケてます。Dopeです。
どのように情シス依頼タスクをJira Coreに反映させたかをかいつまんで説明していこうと思います。
はじめに浮上した問題はSlackコマンドとGoogleフォームの両方から依頼を受け付けていることでした。依頼があれば直接Jira Coreに反映させようとしたのですが全く違う窓口が2つあったのでこれは困難だということになりました。
こういった経緯で管理用のスプレッドシートに記入された内容を取得してJira Coreに飛ばすことに。

ここでもGASを使ってスプレッドシートに記入された依頼内容が自動的にJira Coreへ送られる仕組みを作りました。便利ですねGAS。スプレッドシートからもJira Core側のタスク状況を参照できるようにリンクも挿入しておきました。
スプレッドシートの内容取得は以下のように最終行から未タスク化依頼を探索して取得しています。

次にJira REST APIを叩きました。


先ほどスプレッドシートから取得した情報をJira Coreのフィールド情報として反映されます。

結果としてタスクの全容が非常に分かりやすくJira Core上で表示されるようになりました。とても分かりやすいですね。細長いスプレッドシートの行を凝視する苦行から解放されたわけです。

Jira Coreとスプレッドシートの連携によってタスクが分かりやすく表示され、ストレス無く管理をしながら仕事が進むようになりました。
社内SEが抱える多種多様なタスクを整理することは非常に大切です。ジーニー社員の皆さんが抱える問題を解消していくためにもミスなく迅速な対応を心がけています。

6 さいごに

ジーニーに入社してからこれまでの半年間はあっという間でした。毎日様々な小さいタスクに対応して、その積み重ねの日々だったと思います。
地味で目立たない仕事も多いですが社員の声をダイレクトに聞くことができるのでやりがいも大きいです。これからもジーニー全社員がストレスなく快適に仕事していけるよう努力していこうと思います。
最後にありきたりなことを言うと入社当初なにもできなかった私を助けてくれた情報システムチームメンバーには感謝しています。先輩からのアドバイスやレビューを通して私もなんとか今に至っています。隣人を大切にするカルチャーがジーニーの良いところです。

一緒に働く仲間募集中!
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

11期上半期、「GENIEE DSP」は機械学習を活用した自動入札機能の正式提供を開始しました。企画から半年、驚異的なスピードでの機能リリースを成功させたエンジニア二人に、開発の裏話とチームでの取り組みを聞きました。

R&D本部 マネージャー代理 内木 正隆
「大規模なデータを使い様々な開発ができそう」と感じたことが、入社の決め手に。
R&D本部 リーダー 遠藤 悠平
「広告事業はデータ分析を実践的にできそうで面白そうだった」という思いでジーニーへ。

チームのミッションを教えてください。

遠藤  担当プロダクトの指標、広告配信の指標であるCVとCPAを最適化することです。

自動入札開発チームは、上半期MVT(Most Valuable Team)を受賞しました。成果について、改めて説明をお願いします。

内木 機械学習の予測を用いて入札の価格づけを自動的に行う「自動入札機能」をジーニーとして初めて開発しました。今まで人手に頼っていた広告運用作業を部分的に自動化することで、工数削減と広告パフォーマンスの改善を実現できました。
遠藤 私達が入社する前から、DSPにこの機能を組み込むことはジーニーにとって悲願でした。しかしお客様にも納得していただけて、かつ運用チームの要望を実現するのは、技術的に難しいものでした。

かなりスピード感のある開発だったそうですが、なぜ短期間で成果を上げることができたのでしょうか。

内木 自動入札機能自体は企画から半年でリリースできたのですが、周辺の開発も含めると丸3年かかってようやくできたものなんです。第一弾としてCTR(クリック率)予測機能を開発し、その後プロトタイプであるCVR(コンバージョン率)予測機能をリリースしました。
遠藤 リリース後、もっとこういう機能があったらいいのではと二人で話し合い、他機能をいくつか追加した「自動入札」の企画を私が上げたのが4月です。
内木 PMとCTOが開発の大枠の方向性を決め、主に遠藤さんがアイディアの取りまとめや要件定義、スケジュール設定を行っています。
遠藤 チームは各々が専門的な知識を持っているので、企画についてミーティングやテキストで議論し、プロジェクトに関わるチームみんなで形を作っています。配信チームのメンバーには、非常に技術的に難しいところを実現してもらいました。私たちの作ったモデルが実際に機能するかどうかは配信にかかっています。1億、10億といったリクエストを捌けるような配信構成を取り、実装できたのは配信チームのおかげです。

プロジェクトが計画通り進まない時、どのようにして課題を解決し、進めていますか。

内木 プロダクト開発は積み重ねです。使えるものが一度でできることは滅多にありません。予測の精度は赤字に直結します。予測する範囲等のチューニングを繰り返し、チームを跨いだ話し合いと改善を何度も重ねました。計画通り進まないことの方がむしろ多いです。今回企画から半年、初回リリースでパフォーマンスを出せたことの方が驚きです。

数年来開発を積み重ね、一つひとつ技術を積み重ね、メンバーの皆さんが一体となって進めてきたことが、結実したのですね。

遠藤 そうですね。自チームだけでは解決しない課題も多いですし、他チームとのコミュニケーションがずれていてうまくいかない時もあります。実装に至るまでは多くの過程を経るので、周辺の知識や解決策を多く知り、積み上げていくことが成功につながると思います。それを乗り越えてうまくいった時は、やはり嬉しいですね。この時のためにやっていると言っても過言ではないです。

※役職・職務は取材時のものです

大学生活につまずいていた2年生の3月、1本の広告に出会ったことで、道は拓かれました。
文系学部出身の僕が、アドテク企業のジーニーでエンジニアになった今、同じように悩む後輩たちに伝えたいこと。
(R&D本部 東哲志 2020年新卒でジーニーに入社。東京大学経済学部出身)

Contents

・なぜエンジニアになろうと思ったか
・3ヶ月でアプリをリリース
・経済学部での経験もエンジニアの仕事に生きる
・GENIEEでの仕事

なぜエンジニアになろうと思ったか

きっかけはFacebookの広告。「4時間でマリオ風ゲームを作ってみよう」というプログラミング無料体験会の宣伝でした。経済学部に進学が決まり、専門科目の基礎を一通りやったところで、自分にはこの学部は向いていないなと思っていた時で、何かやってみたいと思っていたところだったので、秒で飛びつき、気付いたら申し込み完了していました。大学2年の3月これがエンジニアライフの始まりです!
実際の体験会ではUnityを用いて避けゲー(オブジェクトを左右に移動させて障害物を避けながらゴールを目指すゲーム)を作りました。

画面上を移動させる主人公や障害物、ゴールなどは、Unity上に予め用意されているオブジェクト(球とか立方体)をドラッグ&ドロップで、Scene上に配置するだけでできてしまいます。なので、実際にプログラミングした内容としては、「主人公が一定のスピードでX座標上を移動する。右左のキーの入力を受けてY座標を移動する」という至ってシンプルな内容です。
プログラミングを初めてつまずく最初の難関は、大量の「気にしてはいけない」コードです。Unityで言えば以下のような初期コードが以下のような物で、初めての人にとっては意味不明な概念が大量に出てきます。

(void?,public,class?,MonoBehaviour?)
しかし、そういった細かいことが気にならないたちで、 Start(){} のなかに書いた内容が再生ボタンを押した際に1度だけ実行され、Update(){} のなかに書いた内容が1秒間に60回[^1]処理されるといった説明を自然と受け入れ、オブジェクトが意図通りに動くのを眺めてめっちゃ楽しい!となったわけです。

[^1]: 1秒間に何回処理されるかは実際には端末に依存するが、そんなことは初心者にとってはどうでもいい。

プログラミングを始めて3ヶ月でゲームアプリをリリース

そんな訳で、体験会後に誘われるままGeekSalonというプログラミングスクールで3ヶ月間のUnityコースに取り組むことになりました。目標はなんとアプリリリース!
作ったのはピンポンダッシュ風のアプリです。連打するタイプのゲームで、ロジック部分は簡単でしたが、ゲーム中に出てくる3Dのオブジェクトやキャラを、MagicaVoxelというアプリを用いて一から作ったり、Admobを使ってアプリ内広告を出したりといった点まで作り込みました。
かなり熱中していて大学の授業中でもずーっと作業を進めていたりしていて、メンターの方に色々と手伝ってもらいつつ無事AppleStoreとGooglePlayにリリースすることができました![^2] [^3]
スクールを卒業した後はエンジニアインターンに誘われ、長期インターン[^4]を始めました。3ヶ月間のプログラミング漬け生活は本当に楽しくて、エンジニアは天職だと確信していたので迷いはなく、そのまま大学3年の後期の休学を決めるまで時間はかかりませんでした。

[^2]: アプリ名を「ピンポンダッシュ」で出そうとして、Appleに「反社会的な行為を助長するアプリは受け入れられない」とRejectを食らってしまい、名前とキャラだけ変えてゴーストダッシュという謎のアプリを生み出してしまった。
[^3]: 広告収入より、AppleDeveloppersへの登録料(年間¥12,000)の方が高くついてしまうので、現在はAppStoreには公開されていない。
[^4]: 大学3年の夏からGeekSalonを運営していた株式会社Scovilleという会社で長期インターンをさせてもらっていた。

経済学部の経験もエンジニアの仕事に生きる

元々、経済学部が自分には向いていないと感じていた部分もあり、インターンにのめり込んでるうちにだんだんと大学の方が辛くなってしまっていました。半年単位で休学・復学・休学を繰り返し、辛くて本気で退学も視野に入れていのですが、このまま逃げるように辞めてしまうのもちょっと嫌だなと思うところがあったので、最終的に腹を括って、インターンは継続しつつ復学もしました。[^5]
ただ、卒業を目指すからにはきちんとということで、
・授業はきちんと出席、課題はきちっと提出
・試験勉強もちゃんとして余裕を持って単位をとる
といった基本的なことを目標に、経済学部での勉強をやり切りました。また幸いにして、他学部での講義も単位取得が可能であったため、コンピュータアーキテクチャ、オペレーティングシステム、ネットワーク基礎などの理・工学部の単位も修了しました。大学の最後の一年間は、エンジニアとして文系未経験の弱点をそのままにせず、経済の勉強も思いっきりできたのが良かったです。
文系未経験からエンジニアになれたとしてもその後が大変なイメージがあるかも知れません。実際の情報系出身の人に比べたらコンピュータ系の基礎理解はやっぱり弱くて、そういう点では苦労することがあります。
しかし、仕事をする上ではいろいろな分野のことを知っていることは間違いなく強みになります。実際、エンジニアの仕事はプログラムを書くばかりではなく、事業の方針を見て何を作るかを考えたり、エンジニアの人的リソースの分配などの戦略の部分を決めたりと、ビジネス側と協力する部分も非常に重要です。そういった話し合いや決定の背景を理解するのに、経済学部で学んだ土台がとても生きていると感じます。

[^5]: 親に大学だけは絶対出たほうが良いと言われたのもある。

GENIEEでの仕事

R&D本部 アドプラットフォーム開発部 DOOHグループのフロントチームに所属しています。DOOHというのはDigital Out of Homeの略で、屋外のデジタル広告を指しています。
[YUNIKA VISION (新宿)]

主な業務内容は、このようなサイネージへ広告を配信するためのプラットフォーム開発です。、フロントエンドの開発ではTypeScript+React+Next.jsと、流行りの技術スタックを使っており、どれも初めて触る技術だったのですが、最近ではだいぶ慣れてスムーズに開発を進められるようになってきました。また、チームに囚われず、いろんな技術に挑戦できる環境で、時にはフロントだけでなくバックエンドAPIの開発、配信やレポートのバッチ、インフラ設定なども担当しています。

現在の目標はフロントチームのリーダーになることです。チームでの開発を通してシステム全体の構成や、仕様はだいぶ把握できてきたので、今度はフロントエンドの技術をさらに極めて、技術的にもリードできる頼れるエンジニアになりたいと思います!

一緒に働く仲間募集中!
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/

Date
Author
エンジニアの視点から、様々な技術、サービス開発秘話、イベントをご紹介していきます。 ジーニーエンジニアチーム
Tag

2020年の大ヒットドラマ「半沢直樹」。
ジーニーは、シリーズの幕開けとなる「ロスジェネの逆襲」編の主要な舞台として撮影協力しました。現場の様子や撮影風景をご紹介します。

画像1 こちらは普段のGENIEEラウンジ正面の様子です。

画像2 Spiral社長室設営中…美術さんが魔法をかけている最中です。

画像3 IT企業「東京スパイラル」瀬名洋介社長のデスク。このコートハンガー、実はジーニー代表の工藤が普段ジャケットをかけているものなんです。

画像4 Spiral共同経営者2人のデスク。ジーニーラウンジのインテリアと美術さん持ち込みのインテリアが、全く違和感なく調和しています。

画像5 ストーリーの中で重要な役割を果たす時計とホワイトボード。

画像6 Spiralのポスターは全部で3種類。もちろんオリジナルです。

画像7 大きいモニターに映っているのはオリジナルアニメーションです。モニターの電源はオフ。画面にはそれらしい「紙」が貼ってありました。遠目にはわかりませんね。

#画像8 ちょっとニヒルな笑いが印象的な青いウサギ、その名も「スパイラビット」。公式グッズもTBSショップに売っています。(買いました)

今期、本格始動した「ブランドマネジメント事業」はジーニーの社会的な認知を高めるために始まりました。
今回ご紹介した「半沢直樹」のほか、今年は日本テレビ「35歳の少女」、テレビ朝日「相棒19」、また多数のテレビ等CMにも撮影協力させていただいています。来年もどうぞご注目ください。

Back to top