社員の交流を図っていくための部活動。コロナ禍で活動を一時休止していた部も多い中、徐々に活動を再開中！今回はアウトドア部、競技プログラミング部、バスケ部、研修旅行部の部長のから活動の魅力など、熱いコメントをいただきました！

【アウトドア部】企画多数！誰でも気軽に参加できるのが魅力です！

サバゲーやBBQ、屋形船、スノボ等、季節に合わせた企画を月に1回開催しており、最近では1回の参加者が20名以上になることも。Slackのチャンネルには約70名のメンバーがおり、話すきっかけがほしい、仲良くなりたいなど、部署を超えて幅広く参加いただいているのが最大の特徴です！

【競技プログラミング部】エンジニアが大活躍！活動頻度ならどの部活にも負けません！

2022年度入社の新卒社員の働きかけで結成。以前は社内メンバー数名で、個人で競技プログラミングをやっていましたが、部活動として成立したのはごく最近です。部員は7名で、月1回の勉強会、週に3、4回程度、競技へ参加しています。各人で競技プログラミングに参加しつつ、結果を共有したり感想戦を行ったりしています。部活動としての活動は絶賛模索中です！

【バスケ部】スポーツこそ青春！バスケ部が叶えます。

社内のバスケ好きが週末に集まってバスケをしていたことがきっかけで創部されました。現在は部員数40名程で月1〜2回程度、体育館を借りて活動しています。メンバー交流の一環として歓迎会やダーツ大会も開催。大人になると、勝利やゴールに向かってスポーツに全力を注ぐ機会が少ないと思いますが、バスケ部はかつての青春を思い起こさせてくれる部活です（笑）。

【研修旅行部】旅で、相互理解が深まります！

現在は約30名程が所属しており、2ヵ月に１回の頻度で活動しています。研修旅行部は、部署を超えて交流を深めることを目的に、毎回研修テーマを決めて日本各地を旅しています！これまでに千葉や、群馬など関東圏の他、伊豆などにも訪れました。コロナ禍でなかなか遠出が難しいので、最近では都内で脱出ゲームを開催しました。 役割を分担し、お互いの弱い部分をカバーしていくチームワークを養うことができました。旅にはそこでしか味わえない醍醐味があり、 日常生活を忘れさせてくれます。

ジーニーには他にも部活動がたくさんあります！
部活動に参加することで、仕事中とは違った意外な一面を見られ、良好な関係を築けるきっかけになるかもしれません。
ジーニーのいいところは仕事をするときはきちんとする、遊ぶときは遊ぶ。このON／OFFがしっかりつけれるところも魅力のひとつだと思います。

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。

こんにちは、コーポレート本部の経営情報システム開発部でリーダーをしている近藤です。
ジーニーには新卒で入社して４年目になります。
私が所属しているチームでは社内システムの運用・保守を担当しているのですが、昨年にこのシステムへCI/CDを導入するプロジェクトを進めていました。
今回はこのプロジェクトについて書きたいと思います。

Contents
・CI/CD導入の経緯
・社内システムの問題点
・CI/CD導入の結果
・まとめ

１　CI/CD導入の経緯

まず私のチームで開発と運用・保守を担当している社内システムについて簡単に説明します。
このシステムの主な機能は、弊社のプロダクトであるGENIEE SSPやGENIEE DSP、GENIEE SFA/CRMなどの請求金額や支払金額を集計し、経理部が使用する財務会計システムへ連携することです。これにより計上業務の工数を削減することがこのシステムの大きな目的の1つとなっています。また支払先や請求先の情報を管理したり、反社チェック※1を自動で行う機能も持っています。
弊社の他プロダクトと比較するとそれほど大規模なプロダクトではないのですが、このシステムが停止すると月次の計上業務がほぼ停止してしまうため、とても重要なシステムです。
^{※1 反社チェックとは、弊社と新しく契約を結ぼうとしている個人や企業が反社会的勢力に関係していないかチェックをすること}

２　社内システムの問題点

この社内システムですが、様々な要因から開発をスムーズに進められない状態が続いていました。

■テストに膨大な工数がかかる
新しく機能を追加する際、テストにかなりの工数が必要となる状態になっていました。そもそも複雑なビジネスロジックが実装されていたり、外部の複数のシステムと連携する機能が存在するためどうしても大規模なテストが必要にはなるのですが、単体テストやE2Eテストが適切に実装されていれば手動で行うテストの工数を減らすことができます。ところがどちらのテストもメンテナンスされず動作しない状態であったため、小さいhotfixやリファクタリングであっても手動でのテストが必要でした。フレームワークのバージョンを上げる際はあらゆる機能に対して動作確認を行うテストが必要となり、定期的に膨大な工数を割いて作業に当たる必要がありました。

■DBのスキーマ管理が手動
DBのマイグレーションが導入されておらず、DB定義の管理を手動で行う必要がありました。これは自動テストを行う際に問題となり、本番環境で更新されたDBの定義を自動テストの環境へ手動で反映するというような作業が必要となっていました。
また、大規模な開発を複数人で進める場合には、最新のテーブル定義がどれなのか分からなくなるといった問題が起きていました。
実は、以前は自動テストが開発に活用されていました。しかしユニットテストの記述方法や自動テスト環境のメンテナンス方法などの情報が引き継がれないままメンバーが入れ替わってしまったため、辛うじて動作しているものの開発には全く活用されていない状態でした。
そこで改めてCI/CD環境を整備し、メンバー内で継続的に活用していける状態にしたいと考え、このプロジェクトを進めることになりました。

３　CI/CD導入の結果

このプロジェクトでは、主に以下の改善を行いました。これらについて順に詳細を書いていきたいと思います。
■自動テスト導入によりテストの工数を削減
■DBマイグレーションを導入し、スキーマの管理を自動化
■デプロイ時に発生する手作業を可能な限り削減

■自動テスト導入によりテストの工数を削減
私のチームではGitlabを使用しているため、CI/CDの環境はGitlabのCI/CDパイプライン機能を使って実現しました。作業中のブランチに対してコミットをpushすると自動でユニットテストが実行されるように設定しています。これにより実行されたユニットテストに通過していなければ、そのMRをマージできないようにもなっています。
ユニットテストは以前動いていたものを整備しました。具体的には使われなくなった機能のユニットテストを削除したり、メンテナンスされず壊れてしまったユニットテストを修正し、カバレッジは低いもののテスト全体が正常に通過する状態になりました。

■DBマイグレーションを導入し、スキーマの管理を自動化
DBマイグレーションを行うライブラリの導入と設定を行い、マイグレーションに用いるクラスファイルの配置と記述方法についてドキュメント化しチームに共有しました。
DB変更を伴う機能の開発は、DB変更が不要な開発に比べてかなり手間がかかる状態でしたが、これにより、ある程度解決できました。

■デプロイ時に発生する手作業を可能な限り削減
以前の開発フローでは、まず作業中のブランチをステージング環境にデプロイしたのち手動でテストを行い、通過した場合はマネージャーの承認を得てMRをマージし、本番環境へデプロイしたのち機能追加のお知らせをSlackで送るという流れになっていました。
これらが全てGitlab上で完結するよう、開発フローの変更とGitlab PipeLinesの設定を行いました。新しい開発フローでは、ステージング環境へのデプロイも、本番環境へのデプロイもGitlab上でジョブを実行するだけで完了します。機能追加のお知らせはMRから自動生成され、自動でSlackに投稿されます。
これらの変更は、一度リリース作業を行うだけならそれほど大きくない変更ですが、何度もリリース作業を行う場合には無視できない改善点になってきます。

４　まとめ

このプロジェクトを進めていて、たとえ小さな作業であっても、それを何度も繰り返す場合の負担は意外と大きくなるという気づきが得られました。逆に言えば何度も繰り返す作業であれば、細かい時間短縮であっても行ってみるべきで、実際の作業時間があまり変わらなかったとしても精神的に楽になったりすることはあると思います。
また、新しい開発フローをGitlab Pipelinesの設定に落とし込むところで時間がかかってしまったというのが反省点になります。ドキュメントを読むだけだと見落としている点に気づけなかったりもするため、実際に触ってみるのは重要だと感じました。

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

10月14日、ジーニーの2022年下期キックオフがオンライン＆オフラインにて開催されました！毎年このイベントでは、期毎の全社方針や各事業目標等が発表されます。今回はその様子をお伝えできればと思います。
（※登壇者、撮影時のみマスクを外しています。）

毎年、年2回行れるキックオフでは、 今期の方針や活躍した社員の表彰などを行う、皆が一丸となって仕事に取り組むための大切な行事です。社員全員で会場に集まり、楽しみながらお互いを称えあうのがジーニー流です。

第一部では、代表の工藤から13期下期方針が共有されました。
事業方針の他にも工藤からは、Purpose（会社の存在意義）の実現に向けた施策と共に、「ジーニーのカルチャーや価値観について改めて認識合わせをしていきたい」との思いが伝えられました。今期のスローガンである「コラボ！」のもと、全社でコラボ！しながら一丸となって下期も精進していきたいと思います！

各事業責任者からの今期戦略発表

続いて第二部では、上期に活躍した社員の表彰が行われました。
ジーニーでは毎年、事業に貢献し、ジーニーのパーパスの実現につながる功績を残した社員が選抜され表彰されます。
表彰者の発表の前に・・
毎回ジーニーのキックオフでは社員の中からプレゼンターを推薦し、司会のアシスタントを行っていただきます。
今回、下期キックオフのプレゼンターは遠藤悠平さんです。

表彰に戻りまして、今回はVP（Valuable Player）2名、VT（Valuable Team）2チーム、MVT（Most Valuable Team）1チームです！
ーーーー以下表彰者、チーム
VP　増田 航（GENIEE SFA/CRM事業本部 プロダクト開発部 リーダー）
VP　本川 昂次朗（GENIEE CVG事業本部 REACT事業部 マネージャー）

増田さんコメント（右）
上期は自分で全て仕事をこなすというよりはメンバーと議論をし、チームをサポートする形で動いてました。チームの皆さんと出せた結果だと思います。
本川さんコメント（左）
今後は会社の手本となるようなビジネスマンとして、組織や事業に向き合っていきたいと思っています。

また、MVT1チーム、VT2チームが、パーパスの実現につながる功績を残し受賞されました。

代表して高橋さん（右から三番目）コメント
難易度が高いプロジェクトでしたが、チームや部署と連携し、試行錯誤を繰り返しながら業務を遂行しました。自分の中でメンバーの特性などを見ながら任せる業務を判断し、チーム一丸となったからいただけた賞だと思ってます。

代表して小林さん（上段左から二番目）コメント
受賞ありがとうございます。
上手くいかないことも多く心が折れそうになったこともありましたが、時には営業メンバーにも助けてもらうこともありました。リスク管理も含めて学びが多かったです。大きなリリースを出していけるように今後も頑張っていきたいです。

代表して小林さん（上段左）コメント
初期メンバーは3〜4人でしたが、壇上メンバー含めチームを拡大させながら事業に貢献できたのが嬉しいです。課題はまだありますが、メンバーと一緒に頑張っていきたいです。

皆さん、おめでとうございます！！！
以上、下期ジーニーキックオフの様子をお届けしました。
これをきっかけにまた、社員が一つとなって一歩ずつ頑張っていきたいと思います。

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。

こんにちは！今回は10月1日（土）に行われた2023年度入社の新卒内定式についてお伝えします！

ジーニーのラウンジで行われた内定式に集まったのは、ビジネス職31名 エンジニア職29名　計60名の内定者（内定者は全部で65名ですが、欠席者がいたために、計60名の参加でした）。
採用人数は60名を超え、ますますジーニーの成長が期待でき、今から楽しみです！
ジーニーのことをさらに知り入社の心構えを持ってもらうために、今年は以下のコンテンツを実施しました。

第一部：代表挨拶

　　　　祝辞

　　　　内定証書授与

第二部：内定者サマリ

　　　　内定者決意発表

　　　　オフィスツアー

第一部の、代表 工藤からの挨拶は「素直な心を持って、他社や社内の先輩から学んでほしい」「当事者意識、向上心を持ってどんどん成長していってほしい」というメッセージがありました。
また祝辞を担当したCTO 孟、人事部長 川﨑からもそれぞれ祝辞をいただき、記念撮影をして一部は終了となります。

内定証書授与は代表して、佐藤さん、前川さんの2名が受け取られました。

第二部では、内定者決意表明やオフィスツアーが実施されました。

内定者全員がそれぞれ素晴らしい決意表明をしてくださいました。
抱負では「ユーザー視点を大事にできるエンジニアになりたい」、「CTOの孟さんのようにプロダクト愛を持って業務に取り組んでいきます！」、「世界に貢献できる人材になりたい」など力強い決意が述べられました。

続いてはオフィスツアーです。

初めてオフィスに入るメンバーがほとんどで、「きれい！」「すごい！」などの声であふれていました。
また、ジーニーはそれぞれの会議室に人物の名前がつけられており、ガイドを務めた人事からは会議室の名前の由来にまつわる裏話なども聞くことができました。
きれいなオフィスで働けることも、内定者のモチベーションのひとつになってくれたら幸いです！

皆さん、キリっとお顔が引き締まって、凛々しくもさわやかないい表情ですね。
入社まであと半年…
みなさんの入社を社員一同、心待ちにしています！

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。

こんにちは、21卒エンジニアの金重です。
テクノロジー戦略室データエンジニアリンググループに所属しています。
今回は、私が１年間ジーニーのエンジニアとして働いて得た気づき「学生時代の開発・プログラミングとの違い」についてお話しさせていただきます。

金重 光典／名古屋大学大学院卒業後、2021年入社。テクノロジー戦略本部テクノロジー戦略室データエンジニアグループデータチーム所属。

改めまして、2021年4月に株式会社ジーニーのエンジニアとして新卒入社した金重といいます。大学院では化学の反応を機械学習で予測する研究をしていました。
開発経験に関して、研究では、言語は Python で PyTorch, NetworkX といったライブラリを用いてプログラムを書いていました。その他に書いていたコードで言うと、簡単なWebアプリケーションや競技プログラミングのものでした。この時はプログラムを実行して「正しく動いてそうだからヨシ！」と動作を確認しながらコードを書いていました。これでなんだか私いける気がしていました。
「正しく動いてそうだからヨシ！」という言葉の「動いてそう」という部分に疑問をもったかもしれません。ここで一見あやふやに思われる言葉を用いたのは、プログラムが完全に正しく動いていると証明することは現実的ではないためです。これは実質的に判断の問題と言えます。

ジーニーでの開発

私は最初、ちきゅう（現SFA/CRM事業部）開発部に配属されました。
そちらでは
– 不具合修正
– 新機能開発
などを行っておりました。
何をやっていたかというとプロダクト開発です（自分は一部を担当していたに過ぎませんが）。プロダクト開発は終わりのない旅です。実際には終わる時もありますが、お金のある限り続けることはできますし、願わくば終わりなき発展を遂げていくことがプロダクト開発の夢でもあります。
大事なこととして、プロダクトは進化させていく必要があるということです。システムの挙動を変えるためにはコードを付け足すことも修正することも時にはコードを消すことも厭いません。
また、プロダクトの終わりなき発展という夢は、1人では到底実現できないでしょう。チームで取り組みます。

チーム開発で考えること

チームでプロダクト開発を行うとなると、色んな人が様々な変更を加えるわけですが、そんなことをして大丈夫なのでしょうか。その判断はといえば、チーム開発でもやはり「正しく動いてそうだからヨシ！」とされるかどうかでしょう。
しかしこの判断は自分1人がするものではありません。対象のコードベースに関わるチームのみんなが「正しく動いてそうだからヨシ！」と判断できるものであることが望ましいです。それは現在チームに在籍するメンバーにとどまらずこれからチームにジョインしてコードに変更を加える人をも含みます。そしてその人は他ならぬあなたかもしれません（実際に一度退職して再度ジョインする方もいます）。
ではみんなが「正しく動いてそうだからヨシ！」と思えるためには何が必要でしょうか。

テスト

私が最も大事だと感じたのはテストです。
テストはシステムが正しく動いていることを特定の場合に限ってしか証明してくれませんが、システムの振る舞いの一端を見せてくれます。これはシステムに要求される振る舞いの具体例を示すことにもなりコードの理解にもつながります。
また、1人でコードを書いていた時に比べるとコード規模も段違いに大きくなるでしょう。CIを設定してシステムの振る舞いが壊れた/壊れていないことを自動で知るためにもテストは欠かせません。テスト・動作確認が手動になると正しく動いていることを確認するのに時間もかかり、コードベースも開発規模もスケールさせるのがしんどくなります。

レビュー

次に大事だと感じたのはレビューです。
対象のコードをレビューして承認する行為、これはまさに自分以外の誰かが「正しく動いてそうだからヨシ！」と判断することに他なりません。
「正しく動いてそうだからヨシ！」は、判断の問題と言いました。ではどうやって判断を下すのでしょうか。おそらくレビュアーはコードを読んで内容を理解し、動作させて期待した結果が得られることを確認する、などしてその判断を行うでしょう。
そうなんです、あなたが丹精込めて書いたコードは自分以外の誰かに読まれてしまうのです。そして、願わくばそのコードは自分以外の誰かも読めて理解できるものであって欲しいのです。
架空のケースを考えてみましょう。あなたが以前勤めていた職場では開発者がいなくなってしまった。しかしどうしてもシステムを改修したいという話が浮上しています。誰にお願いしようか。そこで白羽の矢が立ったのが5年前にそのシステムを開発していたあなたです。しかも成功報酬3億円。これはやらない手はありません。早速改修に取り掛かるあなた。しかし当時の記憶はほとんど残っておらずコードが何をしているのか、変更を行った際の影響範囲は点でわからず。結局のところあなたは案件を完遂することができませんでした。そして思います、あの時もっとわかりやすいコードを書いてレビューを行い今現在の自分でも読めるコードを残せていれば、と。
レビュアーもまたコードを改変します。コードレビューでは正しく動いてそうかだけでなく、自分がこの先コードを変更する際に「正しく動いてそうだからヨシ！」と言ってもらえるかという視点でもコードの良し悪しを判断することになるでしょう。「正しく動いてそうだからヨシ！」のバトンを繋いでいくのです。もはや動作だけの問題ではありません。読み手を意識して書くことが大事になります。これはコードに限らず、プルリクエストを出す際にどのような意図を持ってどんな変更を行ったかをきちんと記述することも含まれます。

おわりに

まとめるとチームでのプロダクト開発では、
・テストを書くこと（できれば自動で回す）
・レビューを行うこと
・読み手を意識して書くこと
が大事だと感じました（基本的なことですね）。
チーム開発で大事なことはまだまだたくさんありますが、書き出すと本が何冊も書けるほどトピックがあります。私は来るべき執筆依頼のためにプロダクト開発やチーム開発のことを絶賛勉強中です。
今回は、ジーニーでエンジニアとして１年働いてみた私のソフトウェア開発に対する印象のアップデートを通して「学生時代の開発・プログラミングとの違い」をお話しさせていただきました。特に就職活動をしている学生でインターン経験などがない方の参考になれば嬉しいです。
最近はチームでモブプログラミングに取り組んだりもしていますが、この話はまた誰かがしてくれると期待しています（これを読んでいるあなたかもしれません）。

P.S.
「正しく動いてそうだからヨシ！」は “LGTM” と言われています。

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

GENIEE DOOH開発チームの朴（パク）です。
現在、DOOHチームでAndroidアプリの開発をしています。
今回、GENIEE DOOHに興味がある方向けにプロダクトの構成と、スケジュール登録からコンテンツ放映までの流れを説明しようと思います。
^{※本記事はコンテンツがスクリーンに表示されるまでの説明になるため、メディア向けのサービス（DOOH SSP）に重点を置いて説明しています。}

Contents

１. DOOHとは
２. GENIEE DOOHの構成
３. スケジュール登録
４. STBとDOOHアプリ

１. DOOHとは

DOOHはDigital Out Of Homeの略で屋外デジタル広告のことです。

２. GENIEE DOOHの構成

GENIEE DOOHプラットフォームの構成要素は3つに大別されます。具体的には①コンソール画面、②バックエンドサーバー、③DOOHアプリになります。エンジニアの技術区分で言うと、Front-End、Back-End、Appになります。

①コンソール画面はSSP（Supply Side Platform）とDSP（Demand Side Platform）に別れて、SSPでは広告配信できる媒体を持っているメディア向けのサービスを、DSPでは広告を入稿したい広告主または代理店向けのサービスを提供しています。
②バックエンドサーバーは、コンソール画面で登録したスクリーンの情報、広告の単価、予算、広告枠、空き枠の時間を計算して、スクリーン（配信を行う画面）ごとにスケジュールを作成して、配信側でデータを取得できるように変換してくれます。また、配信が終わった広告の集計やレポート作成など、目には見えない計算とコンソール画面と配信アプリ間のデータ連携を担っています。
③最後に、DOOHアプリはコンソール画面で設定したスケジュール通りに広告を配信し、配信された結果を定期的にサーバーに送信しています。

３. スケジュール登録

前章でも少し触れていますが、サイネージでコンテンツの放映をするためには、いつ、どのスクリーンで、どのコンテンツを流すかを決める「スケジュール」が必要です。
ここからは実際のコンソール画面を用いてSSP側でのスケジュール登録と商品作成手順を説明します。
まず、SSP側の画面でメディアと広告を流したいスクリーンの情報（名称、営業時間、デモグラフィック情報、入稿可能動画形式など）を入力して保存します。

その後、配信したいクリエイティブがあれば、入稿をしておきます。

このまま「タイムライン設定」ページに進んで、スケジュール設定も可能ですが、一定時間ごとに固定のクリエイティブを流したい場合（例：1時間ごとに同じスケジュールにしたい場合）には、先にロールを作成します。
ロールにクリエイティブを配置したら名前をつけて保存します。

広告枠はDSP経由で商品として販売することができます。商品は、「純広告」（パッケージ販売）と「PMP(PD)」（imp/CPM販売）の２種類で販売可能です。

時間ごとにコンテンツ枠、広告枠、ロールが決まったら、いよいよ「タイムライン」ページに進んで、放映時期と放映するスクリーンを選んでスケジュールを登録します。登録したスケジュールは翌日分から配信に反映されます。

４. STBとDOOHアプリ

放映するスケジュールが決まってサーバーに反映されたら、物理機器を操作して画面にコンテンツが表示されるように準備します。屋内用タブレット型サイネージも存在しますが、今回は屋外のビルボードを想定して説明します。
必要なものは①モニター、②STB（Android）、③HDMIケーブル、④DOOHアプリになります。
よく「STBって何ですか？」と聞かれますが、STBは「Set Top Box」の略で「小さいデスクトップPC」だと思って頂ければ分かりやすいです。屋外で見るビルボードは、いわゆる大きいモニターと、STBとを繋げてパソコンの画面を表示していることになります。（図はHDMIケーブルを使って表示しているサンプルです）

モニターとSTBを繋いで電源を入れたら、DOOHアプリをインストールします。

アプリの初回起動時には認証用の画面が表示されます。この画面ではコンソール画面で発行されたID/PASSを入力し、受け取るスケジュールを指定します。アプリはバックエンドサーバーから受け取ったスケジュールに基づいて、必要なクリエイティブをダウンロードし、登録された時間通りにクリエイティブを放映します。

^{※容量削減のためフレームレートを落としています}

５. おわりに

ここまでプロダクトの構成と、スケジュール登録 〜 コンテンツ放映までの流れをざっくり説明しました。もっと詳細のことを知りたい方や、デジタルサイネージに広告を出したい方はいつでもご連絡お待ちしております。

【GENIEE DOOH紹介ページはこちら】
https://geniee.co.jp/products/dooh.php
【メールでの問い合わせはこちら】
dooh@geniee.co.jp

こんにちは、21卒エンジニアの渡邉です。GENIEE CHATのバックエンドを開発しています。
今回は、新卒エンジニア向けの技術研修である「bootcamp」に関する対談の様子についてご紹介いたします。
（GENIEE CHAT事業本部 GENIEE CHAT開発部 チャモ Team2　渡邉祥太朗　2021年新卒でジーニーに入社。大阪府立大学工学部出身）

―― まず、bootcampで運営を担当された牛丸さんと金重さんにお聞きします。bootcampとは何でしょうか？

牛丸（運営）：
ジーニーで行っている、新卒エンジニア向けの技術研修です。
今年の実施期間は4月中旬から6月上旬でした。

金重（運営）：
具体的には、以下のような講義を行いました。エンジニアリングに必要な知識を網羅的に学ぶことにより、基礎的な力を底上げすることが目的です。
▼研修内容の例
・CUI
・Git
・UNIXコマンド
・プロダクトマネジメント
・ネットワークと仮想技術
・データベース
・HTML / CSS
・JavaScript / TypeScript / React
・LEMP
・アルゴリズムとデータ構造
・デバッグ
・Golang
・クラウド
・サーバー作成
・開発ルール
・セキュリティ
・テスト
・コードレビュー
・チーム開発

―― 今回は、実際にこのbootcampを受講した22卒エンジニアの早木さんと久保田さんにお越しいただいています。bootcampを振り返ってみていかがですか？

早木（受講者）：
楽しかったですね。特に、普段1人ではやらない分野や、いままで知識がなかった分野についても学べたので充実した期間だったと思います。
また、少人数のグループに分かれて講義の課題を解いたので、多くの同期と話すことができ、仲良くなるキッカケになりました。

久保田（受講者）：
bootcampが始まる前は自分の技術力に不安を持っていました。ですが、講師の方が一生懸命に講義をしてくださったお陰で、幅広い知識を学べました。
そして自分も、同期と仲良くなることができましたね。研修に関することに限らず、プライベートなことについても話すことで同期との絆が生まれました。

牛丸（運営）：
特にためになった講義はありますか？

早木（受講者）：
データベース（MySQL）研修と、React・TypeScript研修ですね。MySQLについては事前知識を持っていたものの、パフォーマンスチューニングなどを通してより深い知識についても学べました。React・TypeScriptについては実際にいま業務で使用しているため、役立っています。

―― 今年度は、昨年度と異なりCUI研修とチーム開発研修が行われました。まず、bootcampの最初に実施したCUI研修の感想をお聞かせください。
^{_{※CUI研修：今後の開発環境を整備し、便利なツールを知ることによって、CUIやMacに慣れる研修。}}

早木（受講者）：
bootcampが始まったばかりで緊張していましたが、取っつきやすい講義だったので良かったですね。自分は以前からCUIやMacを使っていましたが、知らないCUIコマンドやツールについて学べたのでためになりました。

久保田（受講者）：
自分は入社するまでMacを使ったことがなかったので、CUI研修の時間を使ってMacに慣れることができました。Windowsに慣れた人にとってはすごくありがたい講義でしたね。

―― では、チーム開発研修はいかがでしたか？
^{_{※チーム開発研修：8-9人のチームに分かれ、5日間で与えられた要件に沿ったゲームを作成する研修。}}

牛丸（運営）：
特に、課題の難易度や期間が適切だったか気になります。

早木（受講者）：
自分のチームは苦労しましたが、最終的には必須要件をほぼ満たして完成させることができました。
それまでの講義は「座学を受けて、課題を解く」という流れだったのに対し、チーム開発研修では自分で細かい仕様を決めたり、チームメンバーと協力するなど、なかなか貴重な体験
でしたね。

久保田（受講者）：
自分も「作業をチームメンバーと分担する」のは初めてのことで、良い経験になりました。

牛丸（運営）：
実は、チーム開発研修の計画段階では「チームでの開発は配属後でもできるから、bootcampで経験させる必要はない」という意見もあったんです。
チーム開発研修をbootcamp内で行って良かったと感じるポイントはありますか？

早木（受講者）：
自分はbootcamp内で経験できて良かったと思います。チームメンバーが同期だけで、明確な上司がいないという状況だったので、強く当事者意識をもつことができました。
具体的には、チームリーダーがどのようなことを考えているか、という意図を汲んで、自分の行動を考えるキッカケになりました。

久保田（受講者）：
自分にとっては、「ゲームの要件だけが用意されているなかで、アーキテクチャの設計などを含め、ゼロからゲームを作る」ということが難しくもあり、貴重な経験でしたね。

牛丸（運営）：
チームに配属されてから「ゼロから作る」ということは中々経験しませんもんね。

―― 各研修の講師は、入社2〜4年目の先輩エンジニアが担当していました。これについて感想はありますか？

早木（受講者）：
少人数のグループに分かれて講義課題を解いているとき、講師の方が何度か見回りに来てくださったので、分からない部分を質問しやすかったですね。出社日であればオフィスの各テーブルを、リモートであればGoogle Meetの各ルームを定期的に講師の方が訪ねてくださり、質問や相談に対応してくださりました。

久保田（受講者）：
自分は、講義の進め方が講師によって違っていたのが気になりました。
講義内容をスライドに書いて口頭で説明する方もいれば、講義の発展的な内容については外部資料や公式のドキュメントを見るように指示する方もいて……。個人的には前者に統一すると分かりやすいと思いました。

金重（運営）：
前者と後者にはそれぞれメリットがあるので、状況によって使い分ければ問題ないのではないかと思います。
スライドや口頭ではすべての情報を網羅することは難しいので、基礎的な内容についてはスライドや口頭で、発展的な内容については外部資料や公式のドキュメントを利用するのが良いと思います。

久保田（受講者）：
なるほど。確かに業務では、口頭やスライドでの説明では網羅できなかったことを、外部資料や公式のドキュメントで補完していく機会は多々ありますね。

金重（運営）：
そうですね。講義ではRedis（サーバ作成）研修でRedisのプロトコルを読む機会があったと思いますが、これも業務で必要な能力を身につけてほしいという意図で実施しました。

―― 他に、受講者の方が思う改善点はありますか？

早木（受講者）：
配属先に関する情報や、配属がどのように決まるのかについて、受講者間で情報格差がありました。
配属先については一通り紹介があり、また配属先メンバーとの座談会もありましたが、より詳しく情報が得られる機会があれば良かったなと思います。

牛丸（運営）：
具体的には、どのような情報が足りないと感じましたか？

早木（受講者）：
配属先に関しては、配属先のチームにどんな人がいるかや、チームの雰囲気を知るために、配属先の方とランチをしながら1対1で話せる機会があったら良かったです。
また、bootcampの講義課題の成績がどれほど配属に影響するのか、ということについて噂が飛び交っていました。

牛丸（運営）：
成績が配属に及ぼす影響については、一度全員に向けて説明はしましたね。ただ、他の話題とまとめて話したのであまり記憶に残らなかったのかもしれません。来年のbootcampでは、もっと明確に伝わるように工夫します。

―― 最後に、運営委員や実行委員を担当されて感じたことや、今後の展望についてお聞かせください。

牛丸（運営）：
bootcampはまだまだ成長途中です。今年の反省を基に、来年も新たな試みを意欲的に行って改善を図っていきたいです。

金重（運営）：
講師に講義を依頼する上で、チームリーダーやマネージャーなど多くの方と関わったことが印象的でした。多くの方の助けがあったからこそbootcampを実施できたことに感謝します。

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

全世界で多くの企業に利用されている Google Cloud。ジーニーは自社プロダクト開発において BigQuery等のGoogle Cloud Platform（以下：GCP）を利用してきた実績を多数保有し、本年6月8日には、Google Cloud Build パートナーに認定されました。認定に至るまでの経緯や取り組みを佐藤祐樹さん、深澤要さんに伺いました。

佐藤 祐樹さん
SFA/CRM事業本部 カスタマーサクセス部
マネージャー代理
2021年7月、ジーニー入社、R&D本部プロダクトマネジメント部へ配属。2022年1月にリーダーに昇格し、2022年4月にマネージャー代理に昇格。現在はプロダクトマネジメント部とプロダクトセールスグループ部を兼務。

深澤 要さん
SFA/CRM事業本部 カスタマーサクセス部
リーダー
2019年4月、ジーニー入社。デマンド事業へ配属され広告運用を担当。
2020年4月、マーケティングテクノロジー事業本部　事業開発部配属へ。2021年4月にリーダー昇格。現在は事業開発と代理店開拓を推進中。

ーーGCPとの連携についてお伺いします。取り組みはいつ頃から開始されたのでしょうか

佐藤：「Googleとの取り組み」と大きく言うならば、開発、営業メンバーを含め、SFA事業部全体で関わってきたものです。当社は2019年にGCPのサービスパートナー認定を取得しました。Google は「パートナー制度」というものを採用しており、Google からパートナーとして認められることで、商品の提供が可能になります。
また、当社はもともと、Google Workspace^※１の代理店としてグループウェアを採用していたのですが、Googleの「Gmail連携」や「Googleマップ連携」などをSFAと一緒に導入することでビジネスの幅が更に広がるのではないか、と考えていました。
当社は各サービスの裏側でGoogleのプロダクトを利用しているため、Google Cloud上で実行されるソリューション開発に十分な実績があったこともあり、Google Cloud Build パートナー^※２（以下、Buildパートナー）の取得を申請することにしました。
^※１：Google Workspace：Gmail や Googleカレンダー といったツールにビジネス向けの機能を追加した組織向けオンライン アプリケーション セットのこと。
^※２：Google Cloud Build パートナー：Google Cloud と統合されたソリューションもしくは、Google Cloud 上で実行されるソリューション開発に十分な実績を持つパートナーのこと

ーーBuildパートナーの認定条件について教えてください

深澤：Google Cloud ソリューションをお客様に適切に提供しているかどうかの実績やGoogle指定の資格を満たしていることが条件です。
ジーニーのSFAにGCPがどう関わっているのか、どう連携されているのかなどのアーキテクチャをGoogleに提出し、プロダクトの設計を証明しました。資料作成には、プロダクト開発に携わる井古田さんにもご協力いただき、今年6月にBuildパートナー認定を取得することができました。

ーーGoogleはパートナーとしてどのようなサポートをしてくれているのでしょうか。

深澤：Googleから共催セミナーの実施などのマーケティングサポートやセールスサポートを受けることができるため、Buildパートナーという名の通り、共同でプロダクトを推進しています。また、Googleパートナー向けの、開発ナレッジセミナーもあり、ジーニー社員も積極的に参加しています。

ーーGoogleと共同で取り組みを進めていく上で開発やビジネス面で変わった点や良かった点があれば教えてください

深澤：私は開発サイドには関わっていないのですが、ビジネスサイドで言うと、販路が拡大した点が大きなメリットです。
GENIEE　BIに関してはLookerの導入によって売上を伸ばせています。

ーー現在の課題や今後の取り組みについて教えてください

佐藤：今はGCPのプロダクトを使用してサービスを提供しているので、OEMで販売を迅速にできていますが、今後はGCPのプロダクトを、ジーニー製品としてどう改良し、オリジナリティを出して世の中に提供していくか、という転換を進めていかなければならないと考えています。そういった意味で言うと、Googleの「パートナー」として、新たなスタートを切ったばかり、というところですね。
そのために、今後は開発メンバーと議論を重ね、GoogleのプロダクトをSFAにどう活用していけるのかなど、どんどん改良していきたいですね。

深澤：今後の取り組みとして、まずは社内業務のBI化をもっと推奨していきたいです。既に使い始めている事業部もありますが、今後も全社でデータをきちんと可視化し、次の分析につなげていきたいと感じています。他部署でも検討を進めてもらいたいと思っています。

佐藤：業務改善や分析にも役立っているので、全社にもビジネス系のインフラとしてBIを使用していけるようにしていくことが直近の目標ですね。

世界レベルのプロダクトに携わる面白さを実感

ーー佐藤さんがご入社された当時はBIを取り入れたばかりでしたが、関わっていく中で得たメリットなどあれば教えてください。

佐藤：Googleは世界レベルのプロダクトなので、単純にそれに携わる面白さがあります。また、Lookerに関して言うと、エンジニアをはじめとした多くの人が関わって開発を進め、次々に新しいことにチャレンジしています。ジーニーのその「スピード感」がいいところですし、それを活かしてどんどん化学反応を起こし、ジーニーらしいBIを作っていけたらと思います。

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。

4月15日に行われたジーニーの2022年上半期キックオフ（キックオフについてはこちら参照ください。）にてMVM（Most Valuable Manager）を受賞された中釜由起子さんにマネジメントへの思いと今後の展望についてインタビューを行いました。

中釜由起子
新聞社で記者・編集者・多数の新規事業を経験した後、2019年12月にジーニーに入社。2020年1月よりマーケティングテクノロジー事業本部マーケティング・インサイドセールスグループマネージャー。2020年4月より経営企画室広報・ブランディンググループマネージャーを兼務。2020年12月よりBSTマーケティング部部長。2022年4月よりコーポレート本部ブランドデザイン部部長代理、BST事業開発本部長。中3、小6男児の母。

複数の部門、チーム、プロジェクトをマネジメントするのは大変ではないか

最近、この質問をされることが増えました。
ジーニー2部門、BST、職種もマーケティング、広報、デザイン、事業開発など多岐に渡るので携わる組織やプロジェクトが多いのは確かです。
「多くはありますけど、楽しいですよ」
と答えることが多いのですが、楽しく仕事をし、ある程度成果が出せるようになるには数々の失敗と試行錯誤がありました。

組織運営の方針と進むべき方向を示す

2020年にマーテクのマーケ部門のマネージャーに着任した当初は、うまく成果が出せませんでした。オフライン・オンラインマーケティングともにほぼゼロから仕組みを作り結果が出るようになるまで時間がかかったこと、事業部内の部門責任者にマーケティングの方針や見込みを説明し、合意を得られるようになるまで時間がかかったためです。
そもそもマネジメントで実現すべきは、メンバーが成果を上げられるような手法や仕組みを考え、組織を管理すること。私はビジョンを示し、メンバーの話を「聴く」ことを最も大切にしています。
組織運営の方針として「仕事は楽しく、強みを生かしてチームでやりましょう」と伝えています。「一人ひとりが成長に向けてチャレンジできる」「お客様に喜んでもらえた実感を得る」ことで仕事の楽しさは感じられると思っており、あるべき姿について全員が共通認識をもつことは最も重要だと考えています。細かい指示は極力控え、理想や進むべき方向を示すことを心がけています。
とはいえ、最初は細かい施策までコメントすることが多かったのですが、メンバーが徐々に増え、インサイドセールス部門の組織化や数値目標の上昇（前年比200%程度）など難易度が上がるにつれ、マネジメントの方法を見直し、昨年4月頃から「チームを信頼し、任せる」「仕組みを作る」ことに注力し始めました。

メンバー一人ひとりの強みを生かし、主体的に働く環境を整える

「チームを信頼し、任せる」ために意識的に行うようにしているのは、
・中計など、目標設定の背景と短期・長期のゴールを示す（優先順位と期限を伝える。細かい指示はしない）
・マネージャーやリーダーに改善の方針を具体的に伝え、メンバーとのコミュニケーションや連携をしてもらう
・メンバーとは1on1を通じて月次の成長や改善すべきことを個別にフィードバックし、信頼関係を築く
この3点です。
マーケティング業務は特に、期（ジーニーでは四半期に分かれています）、月次のKPI（リード）、KGI（商談数）の目標値の他に、セミナー集客数、WebサイトCVR、メール開封率、イベント名刺獲得数、リードto商談転換率など、様々な達成すべき中間成功指標（KSF=Key Success Factor）があり、タスクも膨大です。裁量を持って働けるように、部長、Mgr、リーダー、メンバーの役割を定義しました。「データ分析、仮説に基づいた施策であればどんどんチャレンジしてください。PDCAを回しましょう」「困ったら相談してください」というメッセージを伝えました。
「自律的に仕事をする」スタイルが定着するのには3カ月ほどかかったと思います。細かい質問に直接回答することをやめ、Mgrやリーダーから報告を受けるようにしました。これによって、それぞれの役割や裁量の範囲の理解が進んだと思います。

「仕組み化」をする

その代わり、私自身は「仕組み化」と「部門間の交通整理」に徹しました。
・タスク管理→プロジェクト管理ツール「backlog」の導入
・インサイドセールス業務の定義、プロセス可視化
・目標管理の粒度とKPI・KGIがGAPした時の打ち手（GAPfill）の進め方の標準化
・着任者用の研修マニュアル整備
・部内問題提起用チャンネルの開設（slackで長期的な事業・業務課題を提起するチャンネル作成）などです。仕組み化に必要な問題提起のみ行い、プロジェクトごとに推進責任者を決めて同時並行で進めていきました。そのメンバーと認識合わせや進捗確認を行い、運用プランまで考えてもらうようにしています。その過程で出てくる困りごとや調整に徹しています。

人材を育成し、新規プロジェクトに挑戦する

今後は、より今進みつつあるリーダーやマネジメント層の育成により力を入れ、ジーニーの未来を担える方を増やしていければと思っています。また、4月に新設されたブランドデザイン部で、全社のブランディングや事業拡大の礎や道筋をつくっていきたいと思います。

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。

4月15日に行われたジーニーの2022年上半期キックオフ（キックオフについてはこちら参照ください。）にてMVM（Most Valuable Manager）を受賞された井古田光晴さんにマネジメントへの思いと今後の展望についてインタビューを行いました。

井古田光晴
GENIEE SFA/CRM事業本部 プロダクト開発部 部長
2021年4月に入社、R&D本部 マーケティングテクノロジー開発部 ちきゅうグループ マネージャー代理に就任。ちきゅう開発チーム3 マネージャー代理、ちきゅうグループ マネージャー、ちきゅうグループ 部長代理を経て、2022年4月GENIEE SFA/CRM事業本部 プロダクト開発部 部長に昇格。

現在の業務について

現SFA/CRMのマネジメントと、去年12月から再始動したSFA/ CRMの新基盤プロジェクトのほかに、今年の3月頃からALSVID（アルスヴィズ：エンジニア組織の課題解決）を進めています。
ALSVIDではエンジニアが抱える不満についてアンケートを取り、モニターやツールの不便さ、インセンティブ、ドキュメント管理までさまざまな意見が集まりました。チーム内だけでは解決が難しい問題を全社で解決するため、工藤さんと推進担当の鈴木さん、12名の有志メンバーでエンジニアの働き方改善に取り組んでいます。

体制を見直し見通しがよい組織へ

SFA/CRMの新基盤プロジェクト推進では、OKRに沿って各々が役割を持ち主体的に業務を進められる組織体制に変更し、目的・役割ごとに、新基盤開発、プロダクト価値向上、顧客要望対応、不具合やCS対応の4チームに分け、新しくUI/UXのチームも加えました。
役割を分けることで割り込み業務による計画のずれを解消し、リーダー一人当たりの担当メンバーを少なくしてフォローが行き届くようにしました。

ーー組織変更時に気を付けたことはあるか

認識の齟齬が生じないように図解などでわかりやすく伝えることを意識し、事業における優先度を説明した上でチーム編成や役割について共有することで納得して組織体制変更を受け入れてもらえたと思っています。
また、週1度のリーダー会でメンバーのモチベーションや業務の進め方に問題がないかを把握するようにしました。リーダーにはメンバーとの1on1を徹底するように伝え、コミュニケーションを取るとともにメンバーのタスク状況を確認してもらいます。組織変更の負荷がないよう移行期間を3週間〜1カ月程度設け、不具合が多い場合には変更自体を中止する判断もしました。

育成と業務委譲を進め組織の基盤を固める

現SFA/CRMでは中西さんやリーダーたちが主体となってタスクを巻き取り、スクラム開発でも自走してくれています。私のマネジメントのミッションの一つである育成を進めることで業務委譲が進み組織基盤も固まります。これまで手が回らなかった幅広い領域のマネジメントができるようになりました。

ーー業務推進で難しい部分はどこか？

開発側とビジネス側で共通認識を持つことです。開発の難しさはビジネス側に伝わりにくい点もあります。例えば工数見積の依頼などで、不明確な部分について開発側が「半年くらいかかるんじゃないか」と伝えたところ、ビジネス側で「半年でできる」とニュアンスが異なって伝わることがあります。ビジネス側からのリクエストに対して応えられる範囲を適宜判断し、情報共有と認識合わせを行い、両者の橋渡しをしながら共に事業を創っていけるように心がけています。

開発ならではの方法で組織改善を進める

優れた機能開発や大規模リニューアルを短期間で行うことが難しいように、組織全体も一朝一夕では変えられません。規模が大きく関わる人が増えるほど改善は難しくなります。大きな課題を解決するためには、自分やチームに合った難易度で課題を再定義し、着手しやすいように分解した上で一つずつ改善を進めることです。開発がいくつもの小さなプログラムを積み上げてシステムを作っていくように、組織も一つのチームの役割や動きを改善して横に連携することができます。そうしたエンジニアならではの方法で組織改善を進めています。

エンジニア組織の改善に向けて

エンジニアの領域は、この4、5年で開発から分析・検証などにまで広がり、コロナ禍で進むDX化への貢献もしやすくなっています。設計能力や抽象的な課題を具体化する力を使い組織のDX化や改善につなげられるエンジニアを増やしたいです。今後は、SFA/CRMの新基盤プロジェクトの例をもとに全社課題の改善とALSVID推進に向けたアウトプットや勉強会の実施を考えています。

■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。