ジーニーは最先端の広告テクノロジーで
顧客の収益を最大化します。
いつもジーニーコーポレートブログ「Geniee’s BLOG」をご愛読いただき、ありがとうございます。
この度、6月6日（水）より、当ブログの更新を停止し、「note（※）」のプラットフォームへ移行することをお知らせします。noteを通じて、当社の事業や社員の働き方の紹介など、ジーニーに関わる情報を積極的に発信してまいります。
※noteはクリエイターが文章や画像、音声、動画を投稿して、ユーザーがそのコンテンツを楽しんで応援できるメディアプラットフォームです
・移行先のご案内
note:https://note.com/geniee_inc
新しいプラットフォームであるnoteでも、変わらぬご愛顧を賜りますようお願い申し上げます。
2017年からスタートしている「新卒bootcamp」は今年で7年目となります。
約2カ月の期間で新卒1年目のエンジニアが6月の本配属に向けて、基礎的な知識・技術を習得する導入研修です。
6/16に無事に終了した今年のbootcampを振り返って実行委員会から4名の方々にお話を聞きました。
東 哲志さん
2020年4月入社
CVG事業本部 CATS マネージャー
牛丸 創太郎さん
2020年4月入社
SFA/CRM事業本部
小林 誠明さん
2022年4月入社
テクノロジー戦略本部 Science
窪寺 壮哉さん
2021年7月インターン入社
SFA/CRM事業本部
小林：約2カ月の期間で各技術分野の研修とチーム研修を行います。
新卒の基礎的な知識・技術の向上やどのチームに配属されても必要となる知識を習得することを目的としています。
牛丸：4/16~5/30は各分野(git、クラウド、コードレビューなど)の研修を、5/31~6/16ではチーム研修を行ないました。
各分野の研修は半日から三日程度の期間で基礎を学び、その後演習を体験し、チーム研修は全体を3チームに分けてそれぞれ別のサービスを作る形で行なわれました。
研修のメインの目的としては、基礎技術・能力の向上・どのチームに配属されても必要になる知識、技術を効率的に習得してもらう事です。
牛丸：Copilot・ChatGPT研修や、ドキュメントライティング研修です。
Copilot・ChatGPT研修は、利用する際の注意点を学び、利用頻度を向上させることで全体の開発速度が上がることを目指した研修です。
ドキュメントライティング研修は書き方の基礎を学ぶことで、社内の資料の質を向上させることが目的です。
窪寺：それとは別に新たな取り組みとして、入社前にプレブートキャンプの課題をメールで送付しました。これにより、新入社員は最低限の技術知識を身につけ、本格的にbootcampへ臨む準備を整えることができたかと思います。
窪寺：各講義のクオリティーを担保するのがとても難しかったです。一律で守ってもらう基準を策定したものの、修正を依頼することも少なくありませんでした。来年以降は講義資料のテンプレートを作成することで、ある程度均質化できるのではないかと思います。
小林：難易度の高い研修は、 研修資料の作成にも多くの時間がかかるため、 工数の調整などで苦労しました。難易度が高くなりすぎている研修は一部簡略化し、 講師の負担を軽減することで改善されると考えています。
牛丸：新卒の配属に関して、人事とHRBPの方々と協力できたおかげで、去年よりもスムーズかつ納得感のある配属になったのではないかと思います。
窪寺：エンジニアの仕事だけでは気付くことができなかった関係各所とのスケジュール調整や働きかけ、コネクションなどの大切さを実感しました。
東：単純に技術のレベルを底上げするための研修で終わるのではなく、新卒が配属後に即戦力として活躍できるようになるためのサポートを、総合的にできる組織の構築を目指していきたいです。
一方でbootcampの運営を担当してくれるメンバーには、横の連携や他部署の上司との繋がりなどを築き、社内全体への視野をもってリーダーシップを磨くための場として活用して行ってもらえるように業務フローの整備や評価体制を整えていきたいと考えています。
富岡 真由さん
bootcamp後、GENIEE CVG事業本部へ配属
bootcampは今まで知らなかった様々な技術を学ぶことができた研修でした。その中で特に印象に残ったのはLEMP研修です。それまでの研修で各テーマに沿って学んできた技術を総合的に使用して課題を解いていくことで、自分の理解が甘かった部分などに気がつくことができ、技術者同士のつながりも感じることができました。
内藤 隼矢さん
bootcamp後、SFA/CRM事業本部へ配属
今まで触れたことのない様々な技術を幅広く経験でき、充実した楽しい期間でした。特に印象深いのはチーム研修です。自分を含むほぼ全員が初めての集団開発でしたが、チームリーダーを中心にメンバー全員が協力し合い、プロダクトを完成させられた事に達成感を感じました。
ジーニーは新卒3年目でマネージャーに昇格するなど、若手社員が多く活躍しています。13期も若手マネージャーが続々と誕生しました。今回はエンジニアマネージャーに昇格した2名に、今までの業務を振り返ってもらいつつ、マネージャーとしての抱負を聞きました。
東 哲志さん
2020年4月にジーニーに入社、DOOHフロントチームに配属。2020年12月にDOOHコンソールチームのリーダー、2022年4月CVG事業本部マネージャーに昇格。同年10月より事業本部付マネージャーへ。
2022年度の第2四半期〜第3四半期にかけて広告連携に関する新規プロジェクトがありました。
この開発では大量データ処理やデータを取得するための設計などが大きな課題でした。
ログの保持や集計にはデータベース管理システムを利用しましたが、チーム全員が初めて触るシステムということもあり実装やデバックに苦労しました。
技術的に難しい課題などもありますが、メンバーの力も借りて解消してもらうなどして、共に新しい挑戦を続けています。
普段から技術的なことに限らず、プロダクトの価値向上に貢献できないかという視点でチームや組織を観察し、必要なサポートを行うというスタンスを心がけてきました。
その過程で必要な技術があれば学んだり、自分自身のタスクがボトルネックになってしまわないような振る舞いやコミュニケーションの工夫をしています。
メンバーに対しては、まずはタスクを大きめの粒度で任せて、行き詰まっていそうな場合は助け船を出すという進め方を基本にしています。技術や知識のサポートは行いつつも、メンバー自身が考えて行動し、必要なコミュニケーションを取って解決していける能力をつけてもらうためにどうしたら良いかを常に考えています。
最近進めている業務標準化のためのドキュメント整備や、新卒エンジニア向けの技術研修「bootcamp」（参考：https://geniee.co.jp/blog2022/09/05/002/）の運営などのプロジェクトはR&D組織が成長・拡大していくのに間違いなく必要なことなので、みなさんにも納得してもらえるようにValue（ジーニーの行動指針）に掲げられている「Logic」を意識して取り組んでいきたいと考えています。
中西 航平さん
2019年12月にインターンとしてiosアプリ/web開発に携わった後、2020年4月にジーニーに入社。ちきゅう機能開発チーム、ちきゅう team3リーダーを経て2021年11月 SFA/CRM team1-4マネージャー代理に昇格。2022年11月よりSFA/CRM team2-3マネージャーへ。
今年度の上半期は、SFAバックエンドに新しくジョインしたメンバーの戦力化に力を入れました。主にオンボーディング資料や動画作成、研修、OJT等を進めました。
下半期は個々人が自走できる組織作りを目標に、成長したメンバーへのタスク委譲や業務のドキュメント整備を行っています。案件の受注ペースが上がっており、事業成長のためには開発リソースの拡大や効率化が必要です。これまでは各チームリーダーが納期や品質管理にコミットするトップダウン型のチームになっており、マネジメント層も不足していて事業が拡大しにくいことが課題でした。
現在は、新しく入社したメンバーをはじめ、リーダー陣と共に各々がロールを持って自走できるようなチームの土台作りの準備を進めています。
元々、物事に対して目標を持ち、計画して成し遂げることが好きだったのでリーダーになることを目指していました。
そのために、業務でのコーディング以外でも先輩が書いたコードや社内コミュニケーションツールであるSlackのやり取りを参考にしながら、仕事の理解を深めていきました。
リーダーからマネージャー代理に昇格したばかりの頃は、目先のタスクに忙殺されることが多く、本来のマネジメントタスクが疎かになってしまい悩んだ時期がありました。上司にアドバイスをもらいながら、中期的な視点を持ち開発グループの成長にフォーカスして取り組める力がついてきたと思っています。
事業拡大のためにはチームの拡大、開発リードタイムの短縮が必須です。
今後は一人ひとりがロールを持って自走できるような開発組織を目指したいです。
■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。
10月14日に行われた下半期キックオフでVP（Valuable Player）を受賞された本川昂次朗さんに受賞の感想や現在の業務で大切にしていることや思いなど、インタビューを行いました。
本川 昂次朗
2018年4月にジーニーに入社。Aladdin Team2、lamp ASP開発チームを経て、2021年1月に CTO付へ。その後テクノロジー戦略室基盤技術開発、マーケティングテクノロジー開発部Team3、ちきゅう開発チーム5を経て、2022年12月、REACT開発マネージャー代理に昇格。
キックオフについてはこちら参照ください。
自分としては、まだ成果を上げ切っていない中での受賞となりましたので、歯痒い気持ちがあるのが正直なところです。
とはいえ、私をサポートしてくださったCVG事業本部の皆様のお力があっての受賞だと考えていますので誇らしい気持ちです。
既存のプロジェクトに関して言うと、「プロジェクトの価値向上に伴って、私の存在価値が下がる、という状況を作り出すこと」が理想だと考えています。具体的に言うと、実際に数値を作り出しているのはフロントに立っているCSチームや営業チームなので、私が関わらずともそのチーム内で業務が遂行できる状況です。
今回、単純な「カゴ落ち機能」の改善という点においては、やり切ったかと聞かれると分かりません。しかし、エッジケース※１といったバグの割合を少なくできたという点では良い方向に向かっていることを実感できています。
※1 エッジケース：ユーザーが遭遇する可能性のあるまれなバグのこと。
今回のプロジェクトに関して言うと、大変だったことは特にはないです（笑）。
そのタスクが目の前にあり、タスク自体の解像度を上げる動きをしつつ、それを愚直にやっただけです。何よりも、CVG事業本部の開発だけでなくCSや営業といったメンバーに恵まれていたのが幸いでした。
数字の成果につながったアクションとしては、単純なカゴ落ち機能をCS、営業チームで回せるようにする、その納品までサポートを続けたことだと思います。具体的にはCSの方とペアプログラミング（以下ペアプロ）に似た体制をとりました。厳密なペアプロではなく、私の方でデバック※2のナビをし、CSの方にドライバーをしてもらう形です。また、ABテスト機能、コンテンツ出し分け、レポート機能のような新規開発においてはプロジェクトの内容を把握している方とのやり取りをしっかり行い、解像度を上げていった点も成功要因の一つと考えています。例えば上司と共に、顧客の要望などをヒアリングしたりしていました。
※2 デバック：コンピュータプログラムや電気機器中のバグ・欠陥を特定して取り除き、動作を仕様通りのものとするための作業のこと。
業務では、エンジニア、という枠を超えて、目の前にある課題を解決していくことを意識していきたいです。今後の目標は、CVG事業部で一体となって目指すべき年商を達成することです！！
■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。
10月14日に行われた下半期キックオフでVP（Valuable Player）を受賞された増田航さんに受賞の感想や現在の業務で大切にしていることや思いなど、インタビューを行いました。
増田 航さん
2019年3月にジーニーに入社、lamp開発バックエンドチームに配属。2020年12月にリーダーに昇格。同年12月よりSFA開発チームへ。
10月14日に行われた下半期キックオフでVP（Valuable Player）を受賞されたお二人へインタビューを行いました。（キックオフについてはこちらを参照ください。）
実は、これまでエンジニアがVP（Valuable Player）のような、個人で賞を取るイメージがなかったため、私自身は授賞式で気を抜いていました(笑)。授賞式で自分の名前が呼ばれた時は正直驚きました。
振り返ってみると、「SFAの画面の高速化」というタスク自体がユーザー体験的にも定量評価のしやすさ的にも分かりやすい成果だったので、それも受賞できた一因だと思っています。
一方で、分かりやすい成果ではないけれど、もっと技術的に難易度の高いことに挑戦して成果を挙げているエンジニア社員がたくさんいると思うので、そういった方も適切に評価されていけば、エンジニア内のモチベーションも上がっていくかな、と思っています。
プロジェクトは、高速化の余地があるかどうかを計測ツールを使用して把握するところから始まりました。
しかし、画面速度の高速化に取り組んだ経験がなかったので、どのように進めていけば良いか、始めは全く分からない状態でした。自分一人ではどうしようもない状態だったので、有識者の方に意見を伺ったり、高速化の余地がどこにありそうかをメンバーと議論し、コミュニケーションを密に取ることで課題を解決していきました。
成果に繋がった一番の要因は、メンバーと実際の画面やDevツール、プロファイル結果を一緒に確認しながら高速化余地の検討の議論をたくさん行ったことだと思います。チームや部署関係なく、全員で協力する体制が整っていくのが理想だと思っています。
「コミュニケーションをとる相手に応じて使う言葉や説明の仕方を変える」、「伝わらないのは、基本的に説明する側の責任だと思って説明する」ことです。例えば、ビジネス部分の方とお話する際には、エンジニア用語を可能な限りかみ砕いて分かりやすいように説明するようにしています。その上で、リーダーとしてメンバーを主導する際には、タスクをアサインしても具体的な作業が明確でない場合には、明確になるまでメンバーと議論しながらタスクを詳細化することを特に心がけています。とは言えまだできていない部分もあるので、引き続き改善していきたいです。
今後は高速化に限らず、リリースした機能等がNSM※などの指標に対してどのように寄与したのかというような、機能リリースの事業への貢献度合いを可視化できる仕組みを作っていきたいと思っています。
※NSM：North Star Metricの略。「プロダクトの本質的な価値が顧客に提供できているかを測る単一の指標」のこと。
■ジーニーについて
ジーニーは、「誰もがマーケティングで成功できる世界を創る」「日本発の世界的なテクノロジー企業となり、日本とアジアに貢献する」というパーパス（企業の存在意義）のもと、企業の収益拡大・生産性向上など様々な課題解決につながるソリューションを開発・提供するマーケティングテクノロジーカンパニーです。
こんにちは、R＆D本部2019年卒エンジニアの増田です。
マーケティングテクノロジー開発部SFA開発チームでチームリーダーをしています。
増田 航／早稲田大学大学院卒業後、2019年入社。GENIEE SFA/CRM事業本部プロダクト開発部GENIEE SFA/CRMグループGENIEE SFA/CRM開発チーム2 リーダー
今回は15~20人の中規模な開発チームにおいて、どのように振り返りの活動を導入して定着させていったかについて話そうと思います。
SFA開発チームでは2年ほど前からスクラムでの開発フローを導入し始めました。ただ、導入して3ヶ月の間はスプリントレトロスペクティブと呼ばれる振り返りのイベントがなかったため、開発体制などに関して問題点を議論して改善をするプロセスがありませんでした。ちょうどそのタイミングで、前職でスクラムでの開発を長く指揮していた経験のある新しいマネージャーの方が参画したため、その方と当時のリーダー陣で相談をして振り返りのイベントを設けることにしました。
前提として弊社の開発部署は一つのプロダクトに対して、2~4程度のチームで構成され、さらにチームはリーダーと2~4人のメンバーで構成されています。
私が新卒で配属された部署でも振り返りのイベントが四半期に一度ほど行れていたのですが、個人的に以下のような点で問題があると感じていました。
これらを考慮した上でSFAチームでの導入の際には、以下のように開催ルールを工夫した上で導入を開始しました。
| 前部署 | SFAチーム | |
| 参加メンバー | リーダー、MGR、PM、部長 | リーダー、メンバー |
| 開催頻度 | 四半期に一度 | 隔週 |
| 改善アクションの個数 | 優先度の高いものは全て | 1-2個 |
| 改善アクションの粒度 | 部署内で行えるもの | チーム内で行えるもの |
| 振り返りのフレームワーク | KPT | KPT |
導入後1ヶ月ほど運用をしてみて、いくつか課題が上がってきたため、3つほど紹介したいと思います。
１.チーム内で解決できないような課題も意見として挙がってくる
一つめの課題は例えばプロダクト内でテストコードをどう運用していくかといった、プロダクトチーム全体で共通認識を持って行うことや、組織体制に関わることなど、チームの中だけでは解決できないような課題が振り返りで意見として出てくるというものです。これについてはチームの振り返りとは別でリーダー以上で組織改善定例を行っており、そこに議題として持っていくことでプロダクト全体への周知を行っていました。
2.毎週よかった点や問題点を挙げるのが大変
二つめの課題は開催頻度を多くしたために出てきた課題で、自分も同じことを導入時に考えていました。これについては記載のハードルを下げて個人的なことでもなんでもいいから書いてもらうようにしました。また、最近では振り返りのフレームワークをもう少し雑談形式にして日々のつぶやきのような形でフランクに話せるように工夫をしています。一年以上続けていますが、意外と毎週色々な意見が聞けています。
3.プロダクトや組織の愚痴になってしまう
三つめの課題は、問題点の議論がプロダクトや組織や個人に対する愚痴になってしまうといったものです。振り返りの場で愚痴が多くなってしまうとチームの雰囲気も悪くなってしまうため、ファシリテーターがうまく本質的な課題だけを抽出したりしてコントロールする必要があります。
最後に具体的に振り返りの中で出てきたアクションでどのような改善に繋がったかをご紹介します。
数として多かったのは、ドキュメントやコードの管理の改善でした。機能改修に当たってドキュメントが少なかったので仕様調査・機能改修と一緒にドキュメントを整理するといったことや、プロダクトコードとは直接関係がないような作業自動化のコードなどのGitでの管理などです。
次に多かったのは、リリースや本番での作業、問い合わせ等に関するフローの見直しでした。これはチーム内で完結できないことも多いですが、現場の意見として他チームや他部署にも問題提起することで全体での改善が行えていたと思います。
また、情報共有という面で、メンバーが直面した課題や作業効率化のためのツールの設定などを他のメンバーと共有して効率化を図ることも振り返りの中で行えていました。
振り返り自体は多くのチームが行っているかと思いますが、実際の改善に繋がらなかったり、現場の意見をうまく吸い上げられなかったりと課題があるかと思います。振り返りを行っても実際の改善が行われないと開催の意義がなくなってしまうため、まずはチーム内ですぐに始められる改善から徐々に進めていくのが良いと思います。
一緒に働く仲間募集中！
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/
こんにちは、コーポレート本部の経営情報システム開発部でリーダーをしている近藤です。
ジーニーには新卒で入社して４年目になります。
私が所属しているチームでは社内システムの運用・保守を担当しているのですが、昨年にこのシステムへCI/CDを導入するプロジェクトを進めていました。
今回はこのプロジェクトについて書きたいと思います。
Contents
・CI/CD導入の経緯
・社内システムの問題点
・CI/CD導入の結果
・まとめ
まず私のチームで開発と運用・保守を担当している社内システムについて簡単に説明します。
このシステムの主な機能は、弊社のプロダクトであるGENIEE SSPやGENIEE DSP、GENIEE SFA/CRMなどの請求金額や支払金額を集計し、経理部が使用する財務会計システムへ連携することです。これにより計上業務の工数を削減することがこのシステムの大きな目的の1つとなっています。また支払先や請求先の情報を管理したり、反社チェック※1を自動で行う機能も持っています。
弊社の他プロダクトと比較するとそれほど大規模なプロダクトではないのですが、このシステムが停止すると月次の計上業務がほぼ停止してしまうため、とても重要なシステムです。
※1 反社チェックとは、弊社と新しく契約を結ぼうとしている個人や企業が反社会的勢力に関係していないかチェックをすること
この社内システムですが、様々な要因から開発をスムーズに進められない状態が続いていました。
■テストに膨大な工数がかかる
新しく機能を追加する際、テストにかなりの工数が必要となる状態になっていました。そもそも複雑なビジネスロジックが実装されていたり、外部の複数のシステムと連携する機能が存在するためどうしても大規模なテストが必要にはなるのですが、単体テストやE2Eテストが適切に実装されていれば手動で行うテストの工数を減らすことができます。ところがどちらのテストもメンテナンスされず動作しない状態であったため、小さいhotfixやリファクタリングであっても手動でのテストが必要でした。フレームワークのバージョンを上げる際はあらゆる機能に対して動作確認を行うテストが必要となり、定期的に膨大な工数を割いて作業に当たる必要がありました。
■DBのスキーマ管理が手動
DBのマイグレーションが導入されておらず、DB定義の管理を手動で行う必要がありました。これは自動テストを行う際に問題となり、本番環境で更新されたDBの定義を自動テストの環境へ手動で反映するというような作業が必要となっていました。
また、大規模な開発を複数人で進める場合には、最新のテーブル定義がどれなのか分からなくなるといった問題が起きていました。
実は、以前は自動テストが開発に活用されていました。しかしユニットテストの記述方法や自動テスト環境のメンテナンス方法などの情報が引き継がれないままメンバーが入れ替わってしまったため、辛うじて動作しているものの開発には全く活用されていない状態でした。
そこで改めて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/
こんにちは、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）に重点を置いて説明しています。
１. DOOHとは
２. GENIEE DOOHの構成
３. スケジュール登録
４. STBとDOOHアプリ
DOOHはDigital Out Of Homeの略で屋外デジタル広告のことです。
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（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年新卒でジーニーに入社。大阪府立大学工学部出身）
牛丸（運営）：
ジーニーで行っている、新卒エンジニア向けの技術研修です。
今年の実施期間は4月中旬から6月上旬でした。
金重（運営）：
具体的には、以下のような講義を行いました。エンジニアリングに必要な知識を網羅的に学ぶことにより、基礎的な力を底上げすることが目的です。
▼研修内容の例
・CUI
・Git
・UNIXコマンド
・プロダクトマネジメント
・ネットワークと仮想技術
・データベース
・HTML / CSS
・JavaScript / TypeScript / React
・LEMP
・アルゴリズムとデータ構造
・デバッグ
・Golang
・クラウド
・サーバー作成
・開発ルール
・セキュリティ
・テスト
・コードレビュー
・チーム開発
早木（受講者）：
楽しかったですね。特に、普段1人ではやらない分野や、いままで知識がなかった分野についても学べたので充実した期間だったと思います。
また、少人数のグループに分かれて講義の課題を解いたので、多くの同期と話すことができ、仲良くなるキッカケになりました。
久保田（受講者）：
bootcampが始まる前は自分の技術力に不安を持っていました。ですが、講師の方が一生懸命に講義をしてくださったお陰で、幅広い知識を学べました。
そして自分も、同期と仲良くなることができましたね。研修に関することに限らず、プライベートなことについても話すことで同期との絆が生まれました。
牛丸（運営）：
特にためになった講義はありますか？
早木（受講者）：
データベース（MySQL）研修と、React・TypeScript研修ですね。MySQLについては事前知識を持っていたものの、パフォーマンスチューニングなどを通してより深い知識についても学べました。React・TypeScriptについては実際にいま業務で使用しているため、役立っています。
早木（受講者）：
bootcampが始まったばかりで緊張していましたが、取っつきやすい講義だったので良かったですね。自分は以前からCUIやMacを使っていましたが、知らないCUIコマンドやツールについて学べたのでためになりました。
久保田（受講者）：
自分は入社するまでMacを使ったことがなかったので、CUI研修の時間を使ってMacに慣れることができました。Windowsに慣れた人にとってはすごくありがたい講義でしたね。
牛丸（運営）：
特に、課題の難易度や期間が適切だったか気になります。
早木（受講者）：
自分のチームは苦労しましたが、最終的には必須要件をほぼ満たして完成させることができました。
それまでの講義は「座学を受けて、課題を解く」という流れだったのに対し、チーム開発研修では自分で細かい仕様を決めたり、チームメンバーと協力するなど、なかなか貴重な体験
でしたね。
久保田（受講者）：
自分も「作業をチームメンバーと分担する」のは初めてのことで、良い経験になりました。
牛丸（運営）：
実は、チーム開発研修の計画段階では「チームでの開発は配属後でもできるから、bootcampで経験させる必要はない」という意見もあったんです。
チーム開発研修をbootcamp内で行って良かったと感じるポイントはありますか？
早木（受講者）：
自分はbootcamp内で経験できて良かったと思います。チームメンバーが同期だけで、明確な上司がいないという状況だったので、強く当事者意識をもつことができました。
具体的には、チームリーダーがどのようなことを考えているか、という意図を汲んで、自分の行動を考えるキッカケになりました。
久保田（受講者）：
自分にとっては、「ゲームの要件だけが用意されているなかで、アーキテクチャの設計などを含め、ゼロからゲームを作る」ということが難しくもあり、貴重な経験でしたね。
牛丸（運営）：
チームに配属されてから「ゼロから作る」ということは中々経験しませんもんね。
早木（受講者）：
少人数のグループに分かれて講義課題を解いているとき、講師の方が何度か見回りに来てくださったので、分からない部分を質問しやすかったですね。出社日であればオフィスの各テーブルを、リモートであればGoogle Meetの各ルームを定期的に講師の方が訪ねてくださり、質問や相談に対応してくださりました。
久保田（受講者）：
自分は、講義の進め方が講師によって違っていたのが気になりました。
講義内容をスライドに書いて口頭で説明する方もいれば、講義の発展的な内容については外部資料や公式のドキュメントを見るように指示する方もいて……。個人的には前者に統一すると分かりやすいと思いました。
金重（運営）：
前者と後者にはそれぞれメリットがあるので、状況によって使い分ければ問題ないのではないかと思います。
スライドや口頭ではすべての情報を網羅することは難しいので、基礎的な内容についてはスライドや口頭で、発展的な内容については外部資料や公式のドキュメントを利用するのが良いと思います。
久保田（受講者）：
なるほど。確かに業務では、口頭やスライドでの説明では網羅できなかったことを、外部資料や公式のドキュメントで補完していく機会は多々ありますね。
金重（運営）：
そうですね。講義ではRedis（サーバ作成）研修でRedisのプロトコルを読む機会があったと思いますが、これも業務で必要な能力を身につけてほしいという意図で実施しました。
早木（受講者）：
配属先に関する情報や、配属がどのように決まるのかについて、受講者間で情報格差がありました。
配属先については一通り紹介があり、また配属先メンバーとの座談会もありましたが、より詳しく情報が得られる機会があれば良かったなと思います。
牛丸（運営）：
具体的には、どのような情報が足りないと感じましたか？
早木（受講者）：
配属先に関しては、配属先のチームにどんな人がいるかや、チームの雰囲気を知るために、配属先の方とランチをしながら1対1で話せる機会があったら良かったです。
また、bootcampの講義課題の成績がどれほど配属に影響するのか、ということについて噂が飛び交っていました。
牛丸（運営）：
成績が配属に及ぼす影響については、一度全員に向けて説明はしましたね。ただ、他の話題とまとめて話したのであまり記憶に残らなかったのかもしれません。来年のbootcampでは、もっと明確に伝わるように工夫します。
牛丸（運営）：
bootcampはまだまだ成長途中です。今年の反省を基に、来年も新たな試みを意欲的に行って改善を図っていきたいです。
金重（運営）：
講師に講義を依頼する上で、チームリーダーやマネージャーなど多くの方と関わったことが印象的でした。多くの方の助けがあったからこそbootcampを実施できたことに感謝します。
一緒に働く仲間募集中！
【ジーニーのリクルートサイトはこちら】
https://geniee.co.jp/recruit/
ジーニーの経営、社内の制度雰囲気、マーケティング、技術まで、いろんなテーマで、ジーニーをご紹介していきます。
