はじめに 皆さんこんにちは！ ラスベガスで開催された AWS の re:Invent にマイナビからも 4 名のエンジニアで現地参戦してきました！ re:Invent がどういったイベントなのか、Keynote から SWAG、認定者ラウンジまで、実際に参加してみたレポートをご紹介します。 AWS re:Invent とは？ AWS re:Invent  は Amazon Web Service（AWS）社が年に一度開催する、AWS 最大規模の技術カンファレンスです。2012 年から開催されており、今年で 13 回目の開催となります。 多くの参加者が注目する Keynote(基調講演)から、2,000 以上の技術セッションへの参加、Expo(展示会)などさまざまなプログラムが用意されており、毎年イベント中に多くの新サービスや、新機能が発表されます。 イベント概要 開催日程：12 月 2 日（月）- 12 月 6 日（木）の 5 日間 開催地　：アメリカ ネバダ州 ラスベガス 参加者　：現地参加者：約 60,000 名（うち日本からの参加者：約 2,000 名） 参加費用：$2,099 会場 引用： https://reinvent.awsevents.com/experience/plan-your-trip/ キャンパス（会場）はラスベガスの中心地のホテルで、全部で 6 つあります。 会場のホテルがかなり大きいため、ホテル間の移動は無料のシャトルバスまたはモノレールを使います。 基本的にはシャトルバス、人が多く集まるイベントが開催されるタイミングでの移動はモノレールでの移動をオススメします。 プログラム ここからは re:Invent で実際に体験したプログラムを紹介していきます。 Keynote（基調講演） EXPO（展示会） 技術セッション SWAG AWS 認定者ラウンジ Keynote（基調講演） Keynote とは、AWS のトップリーダが今年注目の新サービスや新機能についての発表を行う講演で、開催期間中は毎日行われます。 オンラインでの視聴も可能で、動画配信もされています。 Keynote現地参加レポート 今回はその中でも最注目だった Day2 の Keynote、AWS の CEO である Matt Garman の講演に参加しました。 Matt Garman は EC2 の最初のプロダクトマネージャーで、24 年の 6 月に AWS の新 CEO に就任したため、今回が初の Keynoteとなります。 朝 8:00 から始まる講演でしたが、会場に入りたかったので1 時間半ほど前から並びました。 メンバーと 6:00 に集合で MGM からローカルバスに乗り（シャトルバスが出ていない時間）移動。 6:45 に講演会場の Venetian に到着して待ち列へ。 7:00 には入場規制されていたので、開始 1 時間前には並んでいないと会場には入れないようです。 早朝とは思えない人の多さ 7:15 すぎにメイン会場へ。ここもとにかく広かったです。 運よく先頭の方に並んでいたので、会場の真ん中のあたりに着席できました。 ノリノリの DJ がいる会場 講演開始の 8:00 になるとオープニングムービーが流れた後、AWS の CEO である Matt Garman 氏が登場し、会場の盛り上がりも最高潮に！ 登場の瞬間を激写することに成功 この後 3 時間ほどかけて、たくさんの新サービスや新機能が発表され、発表のたびに拍手喝采が起こっていました。 Amazon EC2 Trn2 インスタンス/ Trn2 UltraServers Amazon S3 関連 Amazon S3 Tables Amazon S3 Metadata Amazon Aurora DSQL Amazon DynamoDB global tables Amazon EKS Auto Mode Amazon EventBridge と AWS StepFunctions のプライベート接続 Amazon Nova Amazon Bedrock 関連アップデート Amazon Q 関連アップデート etc... Amazon の CEO 兼社長である Andy Jassy も登壇 早朝から 3 時間の講演はかなりハードでしたが、AWS のスケールの大きさや影響力を肌で感じることができました。 EXPO（展示会） EXPO とはいわゆる企業展示会場のことで、AWS のエキスパートやパートナー企業の方と直接お話ししたり、最新の情報収集をすることができます。 この会場もとにかく広いです。日本の企業もちらほら見かけました。すべてのブースを回ろうと思うと数時間かかるのではないでしょうか... EXPO は Day 2 の 16 時からの開場で、初日はフードやドリンクの提供もあり、ちょっとしたパーティーのようでした。 EXPO 会場の様子 企業ブースがたくさん 気になる企業でサービスについて詳しく話を聞くのもよし、いつもお世話になっている企業のブースに行ってグッズをもらうのもよしです。 頂いたぬいぐるみ自慢 技術セッション イベント中には3,000 以上の技術セッションが開催されます。 セッションタイプや対象業種/業界、レベルが分かれており、予約または事前に並んで（Walk-Up Seats）参加します。 セッションタイプ 主要なセッションについて説明します。 Breakout Session 1 時間の講義形式で特定のトピックについて深掘りする。のちにオンデマンドで動画配信あり Workshop 2 時間の実践型セッション。個人やグループでのハンズオン Chalk Talk 10~15 分の講義の後、45~50 分の質疑応答を行う。少人数での開催 Builders Session 1 時間の小グループセッション。AWS エキスパートとのハンズオン GameDay ゲーム形式のセッション。 レベル 100 レベル（入門）から 400 レベル（エキスパート）まで難易度が分かれているので、自分のスキルレベルや興味に合わせてセッションを選択できます。 参加してみて セッション選びが難しい かなりの数なので、開催場所やスケジュールを考慮しながら自分に合ったセッションを選択するのが難しかったです。 事前にセッションカタログの絞り込み機能を活用しつつ、タイトルだけではなく詳細まで確認して、よくよく検討しておけば良かったなぁと反省しました。 予約なしでも意外といける 人気そうなセッションでも、30〜45 分前に並んでいれば予約なしで入れました。 予約いっぱいでも、直前に席が空いて予約できたりもしたので、諦めずにチェックするのも一つの手です！ 予約すべきセッション Breakout Session は配信があるので、それ以外のグループワークや質疑応答ができるセッションに参加するのがおすすめです。 特に GameDay のようなゲーム形式のセッションは、すぐ予約が埋まってしまうので、参加したい場合はセッション予約開始時にすぐ予約するのが良いです。（私はぼけっとしていて予約できなかった） SWAG SWAGとは企業のオリジナルグッズのことです。 re:Invent 参加者全員がもらえる AWS のグッズから、EXPO に出展している企業のグッズまで様々なアイテムが手に入ります。 AWS の認定を取得している人だけがもらえるグッズもありました。 SWAG 受け取り会場 戦利品のご紹介 企業ごとに特色がありますね。 AWS パーカーや T シャツはもらってそのまま着ている人が結構いました。 持って帰るのが大変な量 認定者ラウンジ 認定者ラウンジとは、AWS 認定資格取得者だけが入ることのできるラウンジです。 資格を 1 つでも保有していると入ることができます。 入場するためには、受付で Credly での認定バッジを提示する必要があるので、あらかじめ準備しておくのが良いと思います。 ラウンジの中には作業スペースがあり、ドリンクや軽食が提供されています。 私がステッカーをもらったり撮影したりと喜んでいる隣で、みなさん黙々と作業されてました。 照明がオシャレ 広々とした作業スペースで黙々と作業する人々 おわりに AWS re:Invent 2024 参加レポート、いかがだったでしょうか。 なんとなくでも雰囲気を感じ取っていただけたら幸いです。 私自身、かなり開発や語学学習のモチベーションが上がりました。 興味のある方はぜひ来年参加してみてください！ 参加メンバーと会場にあった大きな黒板の前でパシャリ 📷✨ マイナビロゴはどこにあるでしょう？👀 イベントURL： AWS re:Invent 2025 | December 1 – 5, 2025

バケットくんとは バケットくん(正確な日本語訳不明・英語: Buckets)は、S3のマスコットキャラクターです。 AWS Storage Blog の下部に紹介文が記載されています。 re:Inventに参加しないと知りえない情報を集めてみました。 身体的特徴 バケットくんが羽織っているダウンにはS3テーブルとS3メタデータという今回発表された機能のワッペンのようなものが付いており、AWS社内で予め準備されていたことが伺えます。 後頭部に存在する取っ手のような部分を動かそうとしている人を見かけましたが、動かせず固定されていました。触られたことに気づいたようでしたが、バケットくんには首が存在しないため後ろを確認するのに少しあたふたしている様子でした。 生息域 毎年開催されるre:Inventのイベント会場内に出現されることが知られています。今回マイナビのエンジニアはEXPO会場・KeyNoteの会場近くにいるところを目撃しました。また、Wynnホテルなど、会場内の他の場所で目撃したという情報も耳にしました。 EXPOのAWSブースの方に、バケットくんに会ったことがあるか聞いたところ、今回は3日間ブースに立っているが見たことが無いと言っていました。バケットくんに会いたい方は、能動的に探すことが求められそうです。 バケットくんの周りには必ず人間が2名程度付き添い、一緒に行動をしていました。 性格 気さくな性格。女性と撮影する際は膝をつくことも。 撮影用にダンスもしてくれます。大きめの上半身とは裏腹に、意外と身軽です。 関連情報 マイナビで入手することはできませんでしたが、re:Invent2日目までは、バケットくんに会うとステッカーをもらえたらしいです。そのため、ステッカーを集めたい人は早めにバケットくんを探し始めたほうがよいです。 EXPOのAWSブースでは、バケットくんの亜種？のステッカーが貰えました。 最後に マイナビ社内向けに本記事を公開したところ、なんとお世話になっているAWSの担当者さまに「 AWS社内に展開したい 」とお声がけをいただきました！バケットくんは、多くの人に愛されるキャラクターのようです。

はじめに 皆さん、こんにちは！デジタルテクノロジー戦略本部(以下デジ戦)のT.Uです。2024年11月にAI・ディープラーニングに関する資格「JDLA Deep Learning for GENERAL（通称：G検定）」を受験しましたので、今回は学習方法や受験の内容についてお伝えできればと思います。少しでも参考になれば嬉しいです。 資格取得にあたり、マイナビのデジ戦社員は、会社の制度を利用することで勉強～受験までを実質無料でできます。（マイナビ&デジ戦最高！） 資格・試験の概要 資格・試験名 JDLA Deep Learning for GENERAL（G検定） 資格・試験の説明 G検定とは、一般社団法人日本ディープラーニング協会（JDLA）が実施する、AI・ディープラーニングの活⽤リテラシー習得のための検定試験です。（公式ページより） 試験日 2024年11月09日（土） 試験の形式 CBT（自宅受験可）形式　120分160問 受験に際して 2024年第6回の試験からシラバスと問題数に変更があります。 ネット上には変更前の情報が多いためご注意ください！ 資格取得の背景 マイナビバイトではGoogleのDeep learningやAIの技術を取り入れようという取り組みを進めています。 そのため技術の背景や歴史を知ることで、より業務理解を深めることを目的に取得しました。 学習方法 使用した教材 Udemy デジ戦の社員が無料で利用できるオンライン学習ツールです！ 「【全200問の模擬試験付き】G検定に合格するための集中講義！人工知能（AI）について体系的に学ぶ（初心者向け）」 公式テキスト 「深層学習教科書 ディープラーニング G検定（ジェネラリスト）公式テキスト 第3版」 公式問題集 「徹底攻略ディープラーニングG検定ジェネラリスト問題集 第3版」 オンライン問題集 「 Study-AI 」 学習期間 約3か月（30時間程度） 学習スケジュール 最初の1か月半で公式本、Udemyをざっと見る。 とりあえず見る。何となく見る。興味を持って見る。何はともあれ見る。 残りの1か月半で問題集をとりあえず解いてみる。 間違った箇所は「×」、何となくしか分からなかった箇所は「△」を付けておき、その部分は解説→（それでも意味が分からない場合は）公式本を読む。 土日など時間を取れるときに模擬問題をやってみる。 私は問題集の模擬問題をやりましたが、Udemy、Study-AIでも良いと思います。 まずは時間を気にせず解いてみる→時間を計って解く。 時間以内に解けるように頑張る。 試験は120分で160問（単純計算で1問当たり45秒）なので、時間配分や120分160問の恐ろしさを身体で理解する。 学び・気づき 「実質無料」で受験可能！？とは 結論、 勉強はデジ戦の「書籍購入補助制度」で購入した書籍とUdemy 受験は自宅なので交通費不要 受験料はマイナビの「IT・ビジネス資格取得支援」制度を利用する ことで、資格取得に関わる費用が基本的にかからなくなります！ 資格取得支援制度に関しては、合否に関わらず受験資格ごとに1回は支給されるため、安心してチャレンジできますね。 p.s. 今回紹介しているオンライン問題集のStudy-AIについても、現在はβ版ということで、無料で利用することができました。（会員登録は必要） 勉強に関しては範囲が広く、量が多いです。（公式本は448ページ、Udemyも13時間くらいあります。） 全てを真剣に調べながら進めると試験に間に合わないため、「こういうものなんだ」程度で一旦納得し、興味がある部分だけ詳しく調べるという進め方をしました。 試験に関しては、PCを使った自宅受験ができます。 試験内容は、どれだけすぐ解ける問題に回答して、次に行けるかが合格のカギだと思います。 問題文がかなり長いものもあるので、読解力も併せて必要な気がします。 かくいう私も全て解き終わった時には、残り時間が15秒でした。（見直しほぼできず ..> <.. ） 一応ですが、全く分からない問題は「A」といったルールを事前に決めておきました。 結果についてはその場では分からず、受験後３～４週間でメールが届きます。 私の場合は、2024年11月25日（月）に合否メールが届きました。 メールには「合否結果」「総受験者数と合格者数」「各分野別の得点率」等が記載されています。 合格証やオープンバッチなどの発行は、もう少しかかるようです。（2024/11/26時点） 資格取得支援制度で必要になる受験料の領収書に関しては、合否メールとは別で届きます。 ▼2024/12/10　追記 合格証書も無事届きました。 さいごに 今後もし取得を目指している方がいれば、 内容も多く大変な資格かと思いますが、合格率は高い資格ですので合格目指して頑張ってください！

はじめに デジタルテクノロジー戦略本部とは 2022年10月、事業部門ごとに点在していたITとデジタルマーケティングの担当部署を1つに統合する形で『デジタルテクノロジー戦略本部（以下、デジ戦）』が誕生しました。 それまではドメインごとにサービスの開発・運用・マーケティングを行うという縦割りの構造で事業を展開していましたが、それだけでは予測不能と言われるこれからの時代に対応することは困難です。そこで、データやシステム、人材などアセットの最適化を図り、より大きなスケールでイノベーションを推し進めていく組織が作られました。 デジコネとは デジコネとは、デジ戦に所属するメンバーの中で、 「他のチームの人が何をしているのか分からない」 「もっと他チームのマーケターと交流を図りたい・・・」 といった悩みを持った方や、組織自体への課題に対し、マーケター間で交流を図る機会の1つとして発足したプロジェクトです！ 詳しくはこちらの記事をご確認ください！ ###card_post_id=1068### 内容：第6回開催内容に関して テーマ：「マイナビが競合に打ち勝つためのマーケターの心得とは？」 登壇者：ノバセル株式会社　田部 正樹様　 ノバセル株式会社 は、「マーケティングの民主化」をビジョンに掲げ、「指名検索」を重要指標とし、当社が独自に開発した「ノバセル for TV」や「ノバセル for デジタル」などの効果分析ツールや、第三者目線で評価・改善を行う「オーディットサービス」など、オンオフ横断で多様なマーケティングサービスを展開しています。 マーケティングの定義 マーケティングの基礎的な考え方や重要なポイントをご紹介いただきました マーケティングとは、商品を売ることではなく、売れる仕組みを作ること。 具体的には、プロダクト、価格、場所、プロモーションの4つの要素（4P）を組み合わせて、顧客に選ばれるための戦略を立てることを指す。 マーケティングの目的は顧客に選ばれて当たり前の状態を作ることであり、これがマーケティングの本質 だと解説いただきました。 また、他社にはない独自の特徴（POD: Point of Difference）を見つけ、それを強調することが重要であることや、カテゴリー内でのポジショニング（カテゴリーエントリーポイント）を確立することが重要であるという内容に関しても講義いただきました。 グループワーク 勉強会後半では、自分たちのサービスに関するマーケティング戦略を考えるワークショップに取り組みました。各グループは、サービスの存在理由（Why）、対象顧客（Who）、強み（What）、価値（Value）等を明確にするためのフレームワークを使用しました。 田部様より、複数サービスにおけるマーケティング戦略の貴重なフィードバックをいただき、大変有意義なワークショップとなりました。 感想 事後アンケートではこんな感想をいただきました！ 「再認識させられること、ハッとさせられること、どちらも盛り沢山で有意義でした」 「事業が成長する過程や、自社の訴求ポイントを整理するための手法を学ぶことができた」 「同じサービスのメンバーで、今改めてマーケティングの話を聞き、ブランドについて話し合う。とても貴重な機会になりました」 感想にもある通り、改めてフレームワークを活用し、サービス内のメンバーと時間とって話し合うことで再認識できたことや気づきを得ることができたという意見が多かったです。今後も皆様の業務に役立つよう、デジコネの開催を進めてまいります。 過去回はこちらから！ 第1回　「Z世代の心を掴むマーケティングとは？」 第2回　「Meta／マーケ担当が抑える最新トレンドとは？」　 第3回「ADKマーケティング・ソリューションズ／明日から認知マーケターになれる？TVCMプランニングのすべて」 第4回「株式会社イー・エージェンシー／データの力を引き出す！GA・Looker Studio・BigQueryの基礎知識」 第5回「株式会社FaberCompany／LP大解剖！CVR改善！LPのPDCAの回し方

はじめに お疲れ様です。 Webマーケティング課のY.Dと申します。 専門はGA4などのマーケティング分析基盤を中心に仕事しています。 約一年ほど、マイナビが出資しているインドネシアの「企業×フリーランサー」のマッチングサービス「Sribu」に対して、私含めたデジ戦プロモーション部隊の3人でマーケティングサポートを行って参りました。 https://www.sribu.com/en ★買収時のニュースなど https://www.nikkei.com/compass/content/PRTKDB000001540_000002955/preview https://www.mynavi.jp/news/2021/12/post_32688.html サポート内容 Sribuマーケティング支援の詳細内容は以下です。 ①週一の定例会議 Sribu×グローバル経営×デジ戦で会議を行います。 ここではマイナビインドネシアが通訳となり英語と日本語が入り混じる会議となっています。（英語勉強しろ） ②広告戦略の立案 Sribuではオンライン広告でGoogle広告とMeta広告を運用しており、適切なキャンペーン構造や投資金額を立案します。Sribu側CMOと打ち合わせをしながら最適な広告効果を狙います。 ③計測設定 GA4やGTMなどの計測に関与するツールに関して技術的な支援をします。マイナビでも起きている数値が取れない・間違っているみたいな問題の解消をめざします。 なぜ出張したのか？【目的など】 オンラインでの会話を重ねてきた本件でしたが以下の理由で今回の話へとつながりました。 つまり、「直接会話をするため」ということです。 これは外国人だからというわけではないと思うのですが、実際に会ったこともない人・リアルでの交流がない人からの意見は基本素直に受け取ってもらえません。 人に話を聞いてもらうためには、まずは信頼関係を構築しコミュニケーションを深めることが最優先であると今回学びました。 出張場所（ジャカルタ,Sribuオフィスなど） 羽田空港からジャカルタまでは片道7時間半で、赤道直下の南国でした。日本よりも直射日光が鋭く、冷房の効きもより強いものでした。穏やかな時間がゆったり流れている雰囲気でした！ ★渋滞 なんと・・・インドネシアには 信号がありません。 あまりも交通量が多く、雰囲気で横切ったり、合流したりしています。 ★辛い 食べ物がすべて辛いです。下記は適当に入った街のごはん屋さん。 伝統的な「ナシゴレン」などもスパイスの効いた激辛料理です。（個人的には） ※水道水が飲めない（というかアブナイ）ため氷などには注意が必要 ★Sribuオフィス ベンチャーキャピタルを感じるオフィスでした。 出張スケジュール 全体で3泊4日の出張スケジュールは以下です。 10月30日（水） 移動日なので割愛。 10月31日：木曜日 Ryan（CEO）挨拶：9:00-9:30 Alex（CMO）挨拶：9:30-10:00 マーケチームとのMTG①：10:00-12:00 自己紹介、質疑応答、問題点の整理、解決策のディスカッション [宿題] 自己紹介スライド（簡易）+Sribuへの質問を準備 一緒にランチ：12:00-13:00 各自手を動かす作業時間（都度質問対応・モニタリング）：13:00-15:00 Staffinc訪問（webマーケチームとの情報交換）：16:00-17:00 Sribuではこんなことやっているという共有 Staffincはどんな感じで運用しているのかのヒアリング 11月1日：金曜日 マーケチームとのMTG②：9:00-10:00 昨日の振り返り、今日のアクション明確化 各自手を動かす（都度質問対応・モニタリング）：10:00-12:00 一緒にランチ：12:00-13:00 マーケチームとのMTG③：13:00-15:00 改めての問題整理、解決策のディスカッション、帰国後のそれぞれのアクション明確化 CEO,CMOへの成果報告：15:00-16:00 マイナビインドネシア訪問：16:30-17:30 11月2日（土） 帰宅日なので割愛。 出張での成果 課題の再発見 ：直接の対話を通じて、Sribuの計測や広告キャンペーン設計の不整合、予算配分の課題など、遠隔では把握しにくかった運用上の問題を特定できました。 集中した支援による意思決定への貢献 ：2日間にわたりデジ戦側の知見を活用し、P-MAXキャンペーンや計測精度の改善策を提案し、Sribu側の意思決定プロセスに貢献できました。 戦略転換の合意形成 ：繁忙期戦略として、CPA悪化を一時的に許容してCV数の最大化を目指す方向へ転換する方針を共有し、獲得広告の予算の合意を得ました。 基本的には初日にヒアリングを行い、2日目に最終成果としてデジ戦チームからの提案を行いました。 以下の資料が最終的なアウトプットと言えます。 ①ヒアリングまとめ ②改善提案（※抜粋） 上記とても真面目に書いておりますが、一番は「会話ができたこと」が大きいです。 最終日には集合写真を撮りました。言葉の壁はありましたが、お互いの信頼関係を築く機会となったと感じております。 感じたこと 今回の出張は3人で行きましたので、それぞれの感想を載せておきます！ 日本の基準よりも細かい設定確認などがされておらず、現地で会話しながら事実確認をしないと現状を把握することが難しい。特に計測に関しては基礎的なパラメータの整理など日本では共通ルールとなっている部分も個人(企業)独自のルールとなっていたりして会話しながらすり合わせないと修正案を出せないと感じた。 広告配信において、これまで改善インパクトが大きいであろう提案したものの、内容のすべてが反映されているわけではなかった。今回の出張の間に、各キャンペーンの配信目的や意図、改善アクションにつなげる際にどこが障害になっているのかなど、現地で直接コミュニケーションをとることで、どのように提案したら納得してもらえるか考えることができた。 デジ戦管轄のサービスは既にサービスとして成り立っているものがほとんどだと思いますが、今回の支援はまだ小さなサービスをいかに成長させるかという視点で、WEB広告施策も本当にゼロからの取り組みとなったので、戦略的マーケティングの重要性を改めて知るいい機会になりました。たった「10万円」の投資でサービスを大きく改善できる可能性を持っているということ、マーケティングサイドの目標未達が致命傷になり得ることなど、マーケターとして常に感じなくてはいけない「責任」の重さを実感しました。 まとめ 海外でビジネスの経験ができたことは非常に視野が広がる有難い経験でした。 また、英語勉強を本格的にしないとまずいなと言う感覚になりました。AIでの同時通訳も技術的にはありますが、よりリアルタイムでラフにコミュニケーションを取ることが如何に重要か気づきを得られたと思っております。 グローバル経営企画×デジ戦との連携強化は全社にも大きなメリットがあると思います。 今回の出張をきっかけで新たな東南アジア企業のマーケティング支援の話も複数上がったとのことで、こういった案件が各所で起こっている状態が起きればデジ戦グローバル化も現実になるかも・・・？ 読んでいただきありがとうございました。

はじめに デジタルテクノロジー戦略本部とは 2022年10月、事業部門ごとに点在していたITとデジタルマーケティングの担当部署を1つに統合する形で『デジタルテクノロジー戦略本部（以下、デジ戦）』が誕生しました。 それまではドメインごとにサービスの開発・運用・マーケティングを行うという縦割りの構造で事業を展開していましたが、それだけでは予測不能と言われるこれからの時代に対応することは困難です。そこで、データやシステム、人材などアセットの最適化を図り、より大きなスケールでイノベーションを推し進めていく組織が作られました。 デジコネとは デジコネとは、デジ戦に所属するメンバーの中で、 「他のチームの人が何をしているのか分からない」 「もっと他チームのマーケターと交流を図りたい・・・」 といった悩みを持った方や、組織自体への課題に対し、マーケター間で交流を図る機会の1つとして発足したプロジェクトです！ 詳しくはこちらの記事をご確認ください！ ###card_post_id=1068### 内容：第5回開催内容に関して テーマ：「LPのPDCAの回し方」 登壇者：株式会社FaberCompany　岩本 庸佑様　　 ＝＝＝＝＝＝＝＝＝＝＝＝ 株式会社FaberCompanyにてCROコンサルタントをされている岩本様をお招きし、LP制作にお けるPDCAサイクルの回し方について詳しくお話しいただきました。 Web広告におけるLPの重要性 LPはユーザーの検討フェーズに合わせた訴求やストーリー設計を行い、ターゲットを絞ったコンバージョン率最適化（CRO）を実現するための重要なページです。ここではFaberCompany様のサイトを例に、WEBサイトとLPの使い分けについて詳しく解説いただきました。 LP検証と分析の基本的な流れ 月並みですがPDCAを継続的に回すことが基本！ 今回は②～③を重点的に解説いただきました。 現状把握から打ち手設計 気づきの抽出 現状把握のための手法を詳しくご紹介いただきました。下記から１つ又は複数の手法で「気づき（課題要素）」を抽出します。 数値的なアプローチ：GA探索レポートによる把握 簡易ユーザーテスト：身近な人にCV手前までを試して貰い、横から見る ヒートマップ分析：スクロール（ページの精読率）状況、クリック箇所 差分分析：競合他社との差分分析からテスト要素抽出 打ち手の設計 抽出した気づきを施策まで落とし込むプロセスをご紹介いただきました。最初はこのプロセスを丁寧に実施することが推奨とのことでした。 ヒートマップ分析を実践！ マイナビサービスのLPを、ヒートマップを活用して上記プロセスを実践しました。短時間ではありましたが、多くの施策案が出され、岩本様から貴重なフィードバックもいただき、大変有意義なワークショップとなりました。 ▼実際にワークの中で出た気づき～打ち手 感想 事後アンケートではこんな感想をいただきました！ 「まさにLP制作における成果について、課内で苦戦している最中だったのでとても参考になりました。」 「終了後同じチームになった方と各サービスのLP状況などをお聞きできて参考になりました。」 感想にもある通り、各サービスのLP運用状況を知るきっかけとなり、具体的な代理店へのオーダーにつながったというお話も伺いました！今後も皆様の業務に役立つよう、デジコネの改善を進めてまいります。 第1回　「Z世代の心を掴むマーケティングとは？」 第2回　「Meta／マーケ担当が抑える最新トレンドとは？」　 第3回「ADKマーケティング・ソリューションズ／明日から認知マーケターになれる？TVCMプランニングのすべて」 第4回「株式会社イー・エージェンシー／データの力を引き出す！GA・Looker Studio・BigQueryの基礎知識」

はじめに はじめまして！23卒のエンジニアのR.Aといいます。 現在は主に社内システムのデバイス管理ツールの開発を行なっています。 現在はバックエンド側はGoを用いてレイヤードアーキテクチャとDDD(ドメイン駆動設計)に沿って開発を進めています。 開発していく中でレイヤードアーキテクチャやクリーンアーキテクチャなどは綺麗に書けるもののコードの量が多く、時間が取られてしまうという問題点がありました。 その問題を解決するために定型的なコードは自動生成したほうが業務効率化につながると思いコードを生成できるようにしました。 使ったライブラリとしては以下のものになります。 jennifer 概要 自動生成の概要としては以下のようになります。 プロジェクトのdomain配下に対象のentity構造体を作成しておく generator配下のmodelディレクトリに対象のmodelの構造体を配置する(sqlboilerだとスキーマからmodelが自動生成されるの楽です) make generate-backend-base-code Entity=”任意のエンティティ名” Model=”任意のモデル名” というコマンドを実行 interfase, di, repository, usecaseのコードが自動的に生成される レコードの新規作成関数、更新関数が自動生成される 以下が動画になります。 0:04くらいにコマンドを実行しています。 自動生成の中身の説明 各フォルダにソースコードを生成してくれる素となるものが入っています。 generator ┣ di ┃ ┗ gen_di.go // di生成 ┣ handler ┃ ┗ gen_handler.go // handler生成 ┣ models ┃ ┣ admin.go // 生成したいモデル ┣ repository ┃ ┣ gen_repo_impl.go // レポジトリ実体生成 ┃ ┗ gen_repo_interface.go // レポジトリインターフェース生成 ┣ usecase ┃ ┗ gen_usease.go // ユースケース生成 ┗ generator.go　// main関数 コード生成の部分を全て書くと長くなってしまうので生成するときに実行されるmain関数と、ユースケースの生成部分について書きます。 generator.go(main関数) 以下のmain関数を実行することで各フォルダの関数を実行し、生成するという形をとっています。 func main() { // コマンドライン引数を定義 entity := flag.String("e", "", "Entity name") model := flag.String("m", "", "Model name") // コマンドライン引数を解析 flag.Parse() // エンティティ名を取得 e := *entity m := *model fileName := toSnakeCase(e) // handler作成 genhandler.GenHandler(e, fileName) // di作成 gendi.GenDi(e, fileName) // usecase作成 genusecase.GenUsecase(e, fileName) // repositoryinterface　作成 genrepository.GenRepoInterface(e, fileName) // repositoryimpl作成 genrepository.GenRepoImpl(e, m, fileName) } gen_usease.go (ユースケース生成) ここでモデル名とエンティティ名を使い、ユースケースのコードを生成しています。 難しそうに見えますがコードの文字を羅列していく感覚に近いので、ライブラリの仕様を理解してしまえばそこまで難しくはないです。 package genusecase import ( "strings" "github.com/dave/jennifer/jen" ) func GenUsecase(e string, fileName string) { // Usecase interface E := strings.Title(e) // エンティティ名の先頭を大文字に abbrUsecase := strings.ToLower(string(e[0])) + "u" abbrRepository := strings.ToLower(string(e[0])) + "r" f := jen.NewFile("usecase") f.ImportName("main/domain/entity", "entity") f.ImportName("main/domain/repository", "repository") f.Type().Id(E+"UseCase").Interface( jen.Id("Add"+E).Params(jen.Id(e).Op("*").Qual("main/domain/entity", E)).Error(), jen.Id("Update"+E).Params(jen.Id(e).Op("*").Qual("main/domain/entity", E)).Error(), ) f.Type().Id(E + "UseCaseImpl").Struct( jen.Id(E+"Repository").Qual("main/domain/repository", E+"Repository"), ) f.Func().Id("New"+E+"UseCaseImpl").Params(jen.Id(abbrRepository).Qual("main/domain/repository", E+"Repository")).Id(E + "UseCase").Block( jen.Return(jen.Op("&").Id(E+"UseCaseImpl").Values(jen.Dict{ jen.Id(E + "Repository"): jen.Id(abbrRepository), })), ) f.Line() f.Func().Params(jen.Id(abbrUsecase).Id(E + "UseCaseImpl")).Id("Add"+E).Params(jen.Id(e).Op("*").Qual("main/domain/entity", E)).Error().Block( jen.List(jen.Id("err")).Op(":=").Id(abbrUsecase + "." + E + "Repository").Dot("Add" + E).Call(jen.Id(e)), jen.If(jen.Id("err").Op("!=").Nil()).Block( jen.Return(jen.Id("err")), ), jen.Return(jen.Nil()), ) f.Line() f.Func().Params(jen.Id(abbrUsecase).Id(E + "UseCaseImpl")).Id("Update"+E).Params(jen.Id(e).Op("*").Qual("main/domain/entity", E)).Error().Block( jen.List(jen.Id("err")).Op(":=").Id(abbrUsecase + "." + E + "Repository").Dot("Update" + E).Call(jen.Id(e)), jen.If(jen.Id("err").Op("!=").Nil()).Block( jen.Return(jen.Id("err")), ), jen.Return(jen.Nil()), ) // Save to file f.Save("../application/usecase/" + fileName + ".go") } コマンド実行後に生成されるコードは以下のものになります。 package usecase import ( "main/domain/entity" "main/domain/repository" ) type MemberUseCase interface { AddMember(Member *entity.Member) error UpdateMember(Member *entity.Member) error } type MemberUseCaseImpl struct { MemberRepository repository.MemberRepository } func NewMemberUseCaseImpl(mr repository.MemberRepository) MemberUseCase { return &MemberUseCaseImpl{MemberRepository: mr} } func (mu MemberUseCaseImpl) AddMember(Member *entity.Member) error { err := mu.MemberRepository.AddMember(Member) if err != nil { return err } return nil } func (mu MemberUseCaseImpl) UpdateMember(Member *entity.Member) error { err := mu.MemberRepository.UpdateMember(Member) if err != nil { return err } return nil } 工夫した点 インフラ層でエンティティからDBモデルに変換するための関数が必要でした(sqlboilerのmodel特有の型があるため) この関数の中にはフィールド30個ほど存在するものがあり書くのが大変であったため、この関数を生成できるようにしました。 該当の関数は以下のような変換関数です。 func ToDbModelMember(mri *entity.Member) *models.Member { return &models.Member{ Email: mri.Email, EntryTime: mri.EntryTime, Kana: mri.Kana, MemberID: mri.MemberID, Name: mri.Name, Post: mri.Post, UpdateTime: mri.UpdateTime, } } 上記のコードを生成するために以下の手順を立てました。 ASTを使いmodelの構造体の型情報をループさせentityと比較する 比較した上でentityをどの型に変換したらいいか分岐させる 上記の情報をもとに関数を生成する この手順をもとに以下のコードを作成しました。 models, _ := FindModelStruct(fileName, modelName) // ここでmodelを取得 dict := make(map[string]jen.Code) // ここでフィールド名をkey 変換するentityをvalueとして作成 pk := "none" for _, field := range models.Fields.List { // modelの構造体をループさせます name := field.Names[0] if strings.Contains(name.Name, "ID") && strings.Contains(name.Name, E) { pk = name.Name // 主キー取得 } // ここでtypeごとに変換関数を記述させるようにしています // sqlboilerで使われているnull.stringなどを変換できるようにしています switch typeName := fmt.Sprintf("%s", field.Type); typeName { case "&{null String}": dict[name.Name] = jen.Qual("github.com/volatiletech/null", "StringFrom").Call(jen.Id(abbrRepository + "." + name.Name)) case "&{null Int}": dict[name.Name] = jen.Qual("github.com/volatiletech/null", "IntFrom").Call(jen.Id(abbrRepository + "." + name.Name)) case "&{null Time}": dict[name.Name] = jen.Qual("github.com/volatiletech/null", "TimeFrom").Call(jen.Id(abbrRepository + "." + name.Name)) default: // その他の型の場合の処理 dict[name.Name] = jen.Id(abbrRepository + "." + name.Name) } } stmt := jen.Dict{} for k, v := range dict { stmt[jen.Id(k)] = v } // model関数生成 f.Func().Id("ToDbModel" + E).Params(jen.Id(abbrRepository).Op("*").Id("entity." + E)).Op("*").Qual("main/infrastructure/postgres/sqlboiler", modelName).Block( jen.Return( jen.Op("&").Qual("main/infrastructure/postgres/sqlboiler", modelName).Values(stmt), ), ) model構造体取得関数 上記のFindModelStruct(modelの構造体を取得関数)について解説していきます。 ファイルをパースして Goの抽象構文木（AST） という標準ライブラリを使用し、取得しています。 func FindModelStruct(fileName, modelName string) (*ast.StructType, error) { fset := token.NewFileSet() node, err := parser.ParseFile(fset, "./models/"+fileName+".go", nil, parser.ParseComments) if err != nil { log.Println(err) return nil, err } var model *ast.StructType ast.Inspect(node, func(n ast.Node) bool { switch t := n.(type) { case *ast.TypeSpec: if t.Name.Name == modelName { if x, ok := t.Type.(*ast.StructType); ok { // modelの構造体を取得 model = x return false // 構造体が見つかったら探索を終了します } } } return true }) if model == nil { return nil, fmt.Errorf("%s struct not found", modelName) } return model, nil } 今後と課題 新規追加と更新処理しかないのでCRUD処理全てを生成できるようにしたい　また、不要なものが生成されてしまう場合があるのでカスタムして必要なものだけ生成できた方がいい プロジェクトに応じて関数名など微妙に変えないといけないので、プロジェクトに応じた対応が必要　統一化するなどをした方がいい entityからmodelに変換する関数部分がsqlboilerに依存してしまっている、また今回のようにDBモデルとエンティティが似ているものにしか使用できない DB駆動設計となっているので改良が必要 最後に 自動生成を自ら提案してプロジェクトの業務効率化に貢献できたことは大きな経験となりました。 自主的に行動して、開発スピードを上げていくような工夫をこれからも続けていきたいです。 参考にした記事 https://qiita.com/nghrsss/items/e6c9c95db19640f0f654 https://qiita.com/po3rin/items/a19d96d29284108ad442

Dreamforceについて Dreamforceとは、Salesforce社が毎年開催している世界最大のカンファレンスイベントになります。 世界中のSalesforceユーザが集まり、基調講演やセッションからインサイトや成功を共有し、業界の最新イノベーションやテクノロジーの未来を学ぶことができる場となっています。 1. Dreamforce2024 Dreamforce2024は、9/17日～9/19日の3日間、サンフランシスコで開催されました。 世界中から45,000人以上、日本からは700人以上の顧客・パートナーが現地参加されたそうです。 今年のDreamforceのテーマは、 『Humans with Agents drive customer success together』 （人とAIエージェントが共同して顧客の成功を支援する） と掲げ、「AIの第3の波」についてメインテーマとして取り上げられました。 WEBページ： https://www.salesforce.com/dreamforce/ 2. AIのイノベーション（第3の波） Dreamforce2024では、「AIの第3の波」が取り上げられました。 ここでは、AIのイノベーションを紹介させていただきます。 第1の波では「Chatbot」でAIが質問に対してルールベースで回答することができるようになりました。 第2の波では「Copilot」でAIベースで処理をすることができるようになりました。例えば、AIがメール作成や要約をし、人の業務をアシストすることができるようになりました。 そして、第3の波では「Agentforce」というAIプラットフォームが発表されました。こちらは、目的に対して計画を作成し、オーケストレーション、実行することができます。第2の波では、アシストすることまででしたが、第3の波でアクションを実行することまでできるようになり、人のように業務をこなすことができるようになりました。 マイナビでは、現在「Copilot for Microsoft365」など議事録や資料作成に利用していますが、「AIの第3の波」を導入することでさらに業務を効率化できるとともに新しいところに目を向けられる時代がくると感じました。 3. Agentforce 「Agentforce」とは、自律型AIエージェントとなり、営業・サービス・マーケティング・コマースなど、ビジネスのあらゆる領域で活用できるAIプラットフォーム。 簡単に言うと、Salesforceに蓄積されたデータをもとにAIが人のように業務をこなすエージェントとなるプラットフォームのようです。 また、Salesforceの新しいアーキテクチャが同心円の図で示されました。 これまでSalesforceが掲げてきた「Customer 360」の基盤としてData Cloudが位置づけられ、その外側の顧客接点のレイヤーにAgentforceが配置されています。 この新しいアーキテクチャは、Data CloudがSalesforceプラットフォームの心臓部として機能し、Salesforceに蓄積されたデータを集約し管理します。そのデータを利用し、各「Agentforce」が顧客との関係性に直接反映させる役割を担うことを示して紹介されていました。 4. SalesAgentのご紹介 「Agentforce」は、営業・サービス・マーケティング・コマースなど、ビジネスのあらゆる領域で活用できるAIプラットフォームになります。 ここでは、営業組織のための「Sales Agent」を紹介させていただきます。 「Sales Agent」とは、営業組織のための「Agentforce」になります。 「Sales Agent」には、「Einstein SDR」と「Einstein Sales Coach」のエージェント機能があります。 ①Einstein SDR Einstein SDR Agentは、見込み顧客と自然言語で自律的に対話し、問い合わせへの対応や営業担当者とのミーティングを設定することができます。 今後、見込み顧客や一度契約いただいたお客様に対して、Agentにより問い合わせ対応をすることできると営業担当者に時間ができますね。 ②Einstein Sales Coach Einstein Sales Coach Agentは、お客様役として、ヒアリング、プレゼン、交渉時のシミュレーションを行い、営業担当者と自律的なロールプレイを実行することができます。また、実際に商談に参加し、商談進行中にアドバイスをすることもできます。 この機能を使うことで、営業担当者全体の商談スキルも向上し、その結果商談成功率もあがることへ繋がると思いました。 5.（おまけ）Waymo Dreamforce2024では、「Agentforce」が「AIの第3の波」と紹介されていましたが、サンフランシスコの街中にも「AIの第3の波」がありましたので紹介させていただきます。 サンフランシスコでは、Waymoという完全無人の自動運転タクシーが走っていました。 Waymoは、現在 アリゾナ州(フェニックス)、カリフォルニア州（ロサンゼルス/サンフランシスコ）にて自動運転タクシー「Waymo One」を商業運用しているそうです。 「AIが人のように業務をこなす」まさしくこういうことなんだなと実感しました。 WEBページ： https://waymo.com/ 6. まとめ Dreamforce2024に参加し、これからは人とAIが共に働く時代がやってくることを実感しました。 その第一歩がSalesforceの「Agentforce」になるかもしれません。 また、今後のビジネスの中心は、AIによりデータ駆動型の意思決定がされる方向性であるそうです。 そのために、まずデータを整理すること、データの繋がり作ることが最低限必要と感じました。 今後のAI共同時代に向けて、データ活用を意識し業務を遂行していきたいと思います！

自己紹介 ゼネラルエージェント事業本部IT_WEB領域にて、求人企業の採用支援、求職者の転職支援を担当している佐藤です。 担当企業　：WEB事業会社（マイナビも担当しています） 担当求職者：WEBエンジニア、WEBエンジニアを目指している方 メイン業務は企業の採用支援ですが、現在は求職者支援もおこなっております。普段はCTOやVPoE含め、現場の方々とコミュニケーションを取っておりますため、（可能な範囲での）生の情報をご共有できます。 想定する読者 現在WEBエンジニアとして活躍されている方や、WEBエンジニアを目指し自己研鑽などをされている方を想定しています。 マイナビなどWEB事業会社に興味はあるけど、何から始めるべきかわからない… 今の実力でどういう会社に転職できるかわからない… 転職は考えていないけど、今の環境が今後に活きるのかわからない… 今後のために情報収集したいという方に、少しでも参考になる情報をお渡しできればと思っています。 はじめに WEB事業会社は、面接の数日前に対策をして合格するほど簡単な会社ではないです。普段の業務から意識や行動を変えていく必要があると捉えているため、1人でも多くのエンジニアの方に、WEB事業会社で活躍するエンジニアになるために、「持つべき意識」「取るべき行動」をお伝えできればと思っております。 ※本記事では技術的な部分ではなく、スタンスやマインド部分に注目し、まとめています。 本記事のまとめ（特徴5選） プロダクト志向の重要性 手段とやりがいの理解 3方向の視点（自分、仲間、ユーザー） 自責 プロダクトは仮説の集合体（課題定義力と課題解決力） まずは転職市場を理解するために、よくある転職理由から見ていきます 人それぞれ、理由は多くありますが、まとめると下記の理由が多いです。 スキル（キャリア）アップ 現在の仕事の成長機会が限られている 人間関係のストレスや職場環境の問題 現職の待遇（給与、福利厚生）に不満がある ワークライフバランスの改善を希望 業界や職種の変化に興味を持った 企業の将来性に不安を感じる 自分のスキルや専門知識をより活かせる仕事を探している 長期的な目標と現職のミスマッチ 地理的な要因や家族の事情による転居 よく聞く内容ですね。 この理由だけでWEB企業で合格が出るか、お見送りになるか、が判断されるわけではないです。ここから一歩踏み込んだところに、重要な理由が隠れています。 【例】スキル（キャリア）アップしたいという求職者 ⇒ なぜスキル（キャリア）アップしたいのか？ 【求職者A】 今の環境では古い技術を用いた開発しかできず、新しい言語を用いた開発にチャレンジすることが難しい状況です。環境を変え、新しい言語を用いた開発環境に身を置きスキルアップしていきたい etc… 【求職者B】 自身が扱える技術の幅を広げ、よりユーザーに価値を届けるための技術の選択肢を増やしていきたい。新しい技術が必ずしも正解ではないが、新しい技術を学び理解しておくことで、今後プロダクトの成長や、自組織の効率化に貢献できる気付きにつながるかもしれない etc… WEB事業会社で活躍する人（WEB事業会社で内定が出る人）かどうか、求職者AとBの違い、面接官がみているポイントを整理していきます。 プロダクト志向と技術志向 プロダクト志向とは？ 他者(ユーザー)視点で物事を考えており、技術を手段として利用し「何をつくればユーザーに価値を届けられるか」「なぜこの技術を選択したのか」を考えられることが多く、プロダクト重視の志向性 技術志向とは？ 自分視点で物事を考えており、技術力が上がれば良いという考えで「何をつくればユーザーに価値を届けられるか」「なぜこの技術を選択したのか」を考えられないことが多く、技術重視の志向性 志向性を理解すること エンジニアとして、どちらが良いか悪いか、の答えはないです。どちらも良いと思います。ただWEB事業会社を目指すのであれば、「プロダクト志向」を持っていることが重要です。 2つの志向性どちらも持っているエンジニアもいたりしますし、技術志向でもWEB事業会社で活躍されているエンジニアもいたりします。繰り返しになりますが、どちらが良い悪いではなく、エンジニアとしてどうなりたいか、目的や将来の理想像によって異なるものでもあるので、まずこの志向性を理解することが重要です。 手段とやりがい 技術をどう捉えているか？ WEB事業会社のエンジニアの多くは技術を「手段」として捉えていて、WEB事業会社以外のエンジニアは「目的」と捉えていることが多いです。 日本のIT環境がそうさせてしまっている可能性も高いですが、クライアントワークをしている人だと開発環境が限定的であることが多く、とある1つの開発環境に強いエンジニアとしてキャリアを積まれることが多いです。単価も上がり、会社も同等の開発環境の案件を集中させるケースも多いので、異なる開発環境を目指したり、手元のスキルを向上させることに意識が向いてしまうのは仕方がないことなのかもしれません。 エンジニアとして感じるやりがいにも違いがある WEB事業会社のエンジニアがユーザー貢献、サービスグロースなどをやりがいに感じている一方で、WEB事業会社以外で働くエンジニアは「技術向上」がやりがいになっていることが多いと感じます。※それが決して悪いわけではなく、希望する環境、将来の理想像につなげればいいだけです。 「なんでこの会社がこのサービスを作ろうとしているのか気になる」 「なんでこの設計になったのか気になる、他にも選択肢はあったのに、なんでだろう」 「リリースしたあと、そのサービスやシステムがどう使われているのか気になる」 といった理由から、WEB事業会社を志望されるエンジニアも多くいます。やりがいが「技術向上」以外に向いていると、上記のような発想になることが多いと感じています。 3方向の視点（自分、仲間、ユーザー） 自分視点、仲間視点、ユーザー視点、と3つに分けていますがWEB事業会社にいるエンジニアはこの3つの視点を持ち、うまく使いこなしていることが多いと感じます。よく利己的、利他的、とも表現されたりしますが… 自分視点　　＝利己的 仲間視点　　＝利他的 ユーザー視点＝利他的 と捉えるとわかりやすいかもしれません。 WEB事業会社のエンジニアは自分視点（利己的）も持っていますが、仲間視点（利他的）、ユーザー視点（利他的）を存分に活用し、仕事していることが多いです。※自分視点は言葉の通りですので、割愛します。 仲間視点とは？ この部分のコード、このままだとわかりづらいからもっとシンプルにしよう、ここに躓くかもしれないからコメント残しておこう、など、将来自分以外の、ただ自分に関係している仲間が仕事をするときのことを考えられる視点。 ユーザー視点とは？ このプロダクトにどんな機能を追加したら、よりユーザーは使いやすいと思ってくれるか、ユーザーの利便性が上がるか、またはこのプロダクトからどの機能を排除すれば、よりシンプルにユーザーにとってわかりやすく使ってもらえるか、を考えられる視点。 ※普段はユーザー視点、仲間視点を合わせて他者視点と言ったりしていますが、ここではわかりやすく分けてます。あまり普段の会話の中で「仲間視点」は使わないですが、理解を深めるために記載しています。 自責か他責か 自責：自分で自分のあやまちを責めること 他責：自分以外の人や状況に責任があると考えること ここに関しては、エンジニアだけでなく全社会人共通して言えることだと思いますが、他責よりも自責で物事を捉えられる人であることが重要です。過剰過ぎる自責は不要ですが、ひとつひとつの行動に対し、成功も失敗も振り返りが大事です。 他責の人は自分は悪くないと思い考え方や行動を変えようとしない（＝成長がない） 自責の人はどんなことからも改善点を見付け、考え方や行動を変えようとする（＝成長がある） ので、ここは受ける企業がどこであろうが、意識すべきポイントになります。 （余談）プロダクトは仮説の集合体 有名な話ですが、「プロダクトは仮説の集合体」と言われています。またWEB事業会社では、仮説志向も重要視されていて… 課題定義力 × 課題解決力 この2つの能力が備わっていることも重要だと言われています。ここは長くなってしまうので、ご面談の機会をいただけた際にお伝えします。 最後に WEB企業への入社難易度は高いため、転職を考え始めた前後数ヶ月だけ頑張ってもあまり意味がありません。普段の生活から変えていく必要があります。 マイナビ含め、将来WEB事業会社で働いていくために今すべきことが知りたい 今の自分でWEB事業会社に受かるのか、受からないなら何が足りないのか、 など、気になる方はぜひお問い合わせください。 https://mynavi-agent.jp ※私の思いとしては、1人でも多くのエンジニアがWEB事業会社で活躍する世界をつくることです。面接対策をして、その時だけ良く見えるようにして、WEB企業に入れるエンジニアを増やそうとは考えていないです。ので、転職すべきではない方に求人紹介はいたしません。

はじめに こんにちは! 株式会社マイナビで内製開発をしているA.Kです！ アメリカのラスベガスで開催された AWS re:Invent2023 に参加してきました 今回はre:Inventで開催されていたExpoに行ってきましたのでそのことについて書こうと思います Expoとは 世界各国の企業のサービスの展示会場です 各社がブースをもっていてサービスの紹介をしていたり質問をうけつけたりしています 主に5つのエリアがありました infrastructure Solutions Zone Data Zone Security Zone Developer Solutions Zone AWS for Industries Pavilion 会場はどんな感じ? 会場自体は初日の夕方からWelcome receptionという形でオープンされます オープン初日は入り口前で多くの人が待っていました オープン初日の様子 それ以降は朝１０時ごろにオープンしていました 中に入るとこんな感じで各企業がブースを開いています 各企業のブースではこんな感じでサービスの紹介をしたり質問をうけつけたりしています それ以外にもイベントを開催したりセッションが開かれたりしています 企業のブースによってはレースのようなアクティビティが開かれたりしています こういったブースも数多くありました 企業のブース以外は下記のようなものがありました AWS資格の学習用ブース Jamのブース Gameday用のブース 会場にはドリンクや軽食が置かれており食べたり飲んだりしながらブースを回っている人が多くいました 夕方になるとアルコールの提供もされます 企業ブースではSwagを配っておりそれを目的にExpoを回るひとも多くいるみたいです 今回自分がもらったSwagはこんな感じです(Expo以外もあります) 個人的にDockerのマウスパッドはうれしかったです まわってみた企業ブース Expoは歩き回ったりアクティビティに参加するだけでも面白いのですが現地で企業の人から直接お話を聞けるのもre:Inventに参加する醍醐味の一つです せっかくなのでいくつかまわってみました どの企業もブースには多くの人がいて話し合いが行われています 自分は普段はWebアプリの開発をおこなっているのでDeveloperエリアを主にまわっていました Postman PostmanはなじみのあるサービスでしたがPostman Flowsの紹介をしていたので話を聞いてみました Postman Flowsはこんな感じでAPIを複数組み合わせて作るワークフローを視覚化された形で作成できます シナリオベースのテストをおこないたいとき活用できそうです ビジュアライズされてることでワークフローがわかりやすく開発効率が上がるだけでなく人に説明するときも便利です デフォルトではオフらしいので各自でオンにする必要があります 参考記事 Postman Flowsとは Postman Flows ドキュメント LaunchDarkly feature flagを利用して本番コードを管理するサービスになります feature flagとはコードにfeature flagと呼ばれるフラグを埋め込みその真偽値で表示の有無を変えたり特定のユーザー郡に対しての限定リリースに対応したりします launchDarkly上でフラグを作成しsdkを通じてそのフラグの真偽値を取得しコード上で利用できます その値はGUI上で切り替えることができます 簡単にユーザーに対しての表示を切り替えることができるのでABテストなどのユースケースで効きそうです 参考記事 LaunchDarklyとは LaunchDarkly ドキュメント rootly 障害発生時のアラートに関連したサービスになります 障害が発生すると専用のチャンネルが作成されzoomのリンクやJiraのチケットが作成されます Slack上でアサインなども可能です 会場では利用方法などをデモなども交えて見せてもらいました slack上でほとんど作業がおこなえるので作業効率が上がりそうです 参考記事 rootlyとは Pinecone ベクトルデータベースのサービスです 機械学習などでは文章や画像などのデータをベクトルに変換したデータを取り扱うためのデータベースをベクトルデータベースといいます このデータベースを用いた検索では、ユーザーの意図なども加味した検索だったりマルチモーダル検索などがあります ExpoではPineconeの無料枠のチケットをもらうことができました こういったのもExpoならではです 参考記事 Pineconeとは その他 それ以外には有名なサービスの企業も多くありいくつかまわりました github redis docker Vercel etc.. おわりに 今回はExpoについてまとめました re:Inventでセッションに参加するのも良い経験となりますがExpoで実際に現地でサービスなどに触らせもらったりすることもre:Inventならではの経験となりました Expoを回っていると自分の知らない普段の開発経験を向上させるサービスが数多くありました オンラインでもそういったサービスを得ることはできますが素通りしてしまいがちです Expoではオンラインとは違いその場でどんなサービスやどんな特徴があるのかをデモや説明ともに知ることができるので得るものが多くありました 読んでいただきありがとうございます

4年ぶりに対面で行われ、約3000人ものエンジニアが集結した Developers Summit 2024 にて、「マイナビの全社データ基盤のモダナイズ」をテーマに弊社社員が登壇をしてきました！ 講演内容 マイナビ、そして私たちが所属するデジタルテクノロジー戦略本部の説明をした後、講演テーマでもある『全社データ基盤のモダナイズ』についてお話しさせていただきました。 オンプレで構築していたデータ基盤をどのようにしてAWSにクラウドシフトしたのか、導入前後の変化や技術選定のポイント、反省点について等、講演内容は登壇資料にもまとめておりますので、ぜひご確認いただければと思います！ 講演資料 画像をクリックしてご覧ください！ 登壇後記 マイナビではデータ民主化について取り組んでいます。 今回はそのデータ民主化のために必要不可欠なデータ基盤のモダナイズについてお話させていただきました。 オンプレ更改が起因ではありましたが、TCO削減や働くエンジニアの負荷軽減も含めた技術刷新ができ、そのおかげで新たなことに挑戦しやすくなりました。 今まで運用・保守に割かれていた時間が浮いた分、新しいことに取り組めています。 限られた時間で伝えきれないことも多かったですが、マイナビの取り組みが多くの方の参考になれば嬉しいです。 発表の中でお話できなかったところで少し技術的なお話をしますと、Snowflake接続のところでちょっと苦労した話があります。 より安全な接続をということでIP制限をしているのですが、PC接続では環境変数で適用するわけにもいかず、各ツール毎にbatを作ってプロキシを通すような対応をしました。 また、SnowflakeはIdPにAzureADを利用していたのですが、Power BIからの接続で外部OAuthセキュリティ結合が必要だったのですがここでも苦労しました。 ALTER SECURITY INTEGRATIONでexternal_oauth_any_role_mode = ‘ENABLE’を設定し デフォルトロールを設定しておかないといけないというのは盲点でしたのでPower BIからSnowflake接続を検討されている方のために記述を残しておきたいと思います。 最後に、マイナビではエンジニアを募集しておりますので、ご興味がある方はぜひお応募いただけますと幸いです！

はじめに サイトのローンチ時にサクッと負荷テストを行いたいといった依頼が多々あるのですが、0から負荷テストの環境構築をしたり、テスト会社へ依頼をすると時間や費用の負担が多くなります… AWSが提供している負荷テストソリューション「Distributed Load Testing on AWS」ではサクッと負荷テストの環境構築ができるとのことで、実際に試してみました。 Distributed Load Testing on AWS について AWS での分散負荷テストは、大規模な負荷時のソフトウェアアプリケーションテストを自動化して、リリース前に>潜在的な性能上の問題を特定するのに役立ちます。このソリューションは、一定のペースでトランザクションレコードを生成する数多くの接続ユーザーを作成およびシミュレートします。サーバーをプロビジョニングする必要はありません。また、このソリューションでは、複数の AWS リージョンにまたがってテストを実行することができます。 AWS公式ドキュメント： https://aws.amazon.com/jp/solutions/implementations/distributed-load-testing-on-aws/ 構成 上記は公式ドキュメントより引用したDistributed Load Testing全体の構成図です。 frontendはシナリオを作成するWebコンソール、backend/regionのリソースは負荷テストを実行するAPIと実行環境になっています。 公式ドキュメントページ内にCloudFormationテンプレートのソースコードのリンクもあるので、ソースコードをカスタマイズして実行環境の構成を変更することも可能です。 ※実際にDistributed Load Testing を利用してテストを実施した案件ではIP制限をしていたため、NAT Gatewayを実行環境の構成に追加し、アクセス元IPの固定化を行いました。 特徴 AWS Fargateコンテナを使用した負荷テスト実行環境 JMeterスクリプトを作成することで、アプリケーションテストのカスタマイズが可能 スケジュール機能を利用した負荷テストの自動化が可能 Web コンソールからテストデータのライブ表示が可能 コスト Distributed Load Testingで使用するAWSサービスの利用料が掛かります。 負荷テストの要件によりコストは変動しますが、サーバーレス構成のため比較的安価かと思います。 コストに関する詳しいドキュメントは こちら 今回のゴール 「Distributed Load Testing on AWS」の実行環境構築および、負荷テストの実施 ※本記事での負荷テスト対象は、CloudFront+S3で作成した検証用の静的ページとします Distributed Load Testingのデプロイ 公式ドキュメント の「AWSコンソールで起動する」ボタンを押下します。 CloudFormationのコンソール画面に遷移するため、画面に沿って処理を進めます。 テンプレートソースが指定されていることを確認して「次へ」を押下 スタック名、コンソールにアクセスするユーザー名、メールアドレスが必須項目のため、入力して「次へ」を押下 デプロイするVPCを変更したい場合やCIDR Blockを変更したい場合は、その他の項目も入力してください。 スタックオプションの設定は特に変更をせず「次へ」を押下 確認画面ではThe following resource(s) require capabilities: [AWS::IAM::Role]のチェックボックスにチェックを入れて「送信」を押下し、デプロイ完了を待ちます。 10分前後でデプロイが完了しました！デプロイ時に入力したメールアドレスにWebコンソールのログイン情報が届いているので、コンソールにログインします。 メール コンソールログイン画面 ダッシュボード Distributed Load Testingが利用できるようになりました！ テストシナリオの作成・実行 コンソール画面上部の「CREATE TEST」を押下し、シナリオ作成画面に遷移します。 以下のように負荷テストの設定を行っていきます。 General Settings ここでは同時接続数やテスト時間など、負荷テストに関する一般的な設定をしていきます。 Task CountとConcurrencyの積が同時接続数の最大値となるため、今回は同時接続数最大値を5×200=1000に設定しています。 Ramp Upは5分、Hold Forは10分にし、5分かけて同時接続数の最大値まで到達させその状態を10分維持するように設定しました。 項目 説明 Task Count 起動するコンテナ数 Concurrency タスク当たりの同時接続数（推奨上限は200） Ramp Up 同時接続数に達するまでの時間 Hold For 同時接続数の保持時間 Run Now 予約実行をしない場合はこちらを選択 Run on Schedule テストのスケジュール設定 Scenario テストのシナリオ設定を行います。 今回はTopページへ負荷をかけるシンプルなテストのためSingle HTTP Endpointを選択し、エンドポイントを入力しました。 項目 説明 Test Type（Single HTTP Endpoint） 特定ページに負荷をかけるようなシンプルなテストであればこちらを選択 Test Type（JMeter） 複雑なシナリオを設定する場合はこちらを選択（別途JMeterのシナリオ作成が必要） シナリオを入力し画面右下の「RUN NOW」を押下するとテストが実行され、詳細画面に切り替わります。実行ステータスがRUNNINGとなっているため、このまま完了を待ちます。 ステータスがCOMPLETEとなれば、負荷テストは完了です！ テスト結果 テストが完了するとSUMMARYが表示され、レスポンスタイム、レイテンシー、コネクションタイムの平均や、カウント数（トータル・成功・失敗）を確認できます。 より詳細の情報を確認したい場合は、CloudWatch Logsなどで確認可能です。 まとめ 実際に使ってみての所感は下記の通りです。とりあえず特定ページの負荷耐性だけ確認しておきたい！という場合には丁度良いのではないかなと感じました。 メリット 環境構築がとにかく簡単 Webコンソールの操作も分かりやすい 特定ページに負荷をかけるだけといった単純なシナリオであれば手軽に実施できる デメリット 複雑なシナリオを作成する場合は、JMeterでのシナリオ作成が必要 同時接続数最大値に達するまでのカウントもSUMMARYに含まれているため、整合性に欠ける？ 長時間に渡って高負荷をかける場合は、コストに注意 Distributed Load Testingのリソースだけでなく、テストを行うサイトの側の通信量（見落としがち）の考慮も必要です

はじめに 皆さん、初めまして！ WEBアプリケーション開発系のエンジニアとして採用された、2024年新卒入社のK.Iです。 私は学生時代は文系の出身でプログラミングとは無縁の学生生活でした。 そこから、とあることをきっかけにプログラミングやアプリ開発に興味を持ち、学習を続けてきた結果、ご縁あってマイナビに入社しました。 今回は、そんな僕が学生時代にWEB系のエンジニアとしてキャリアをスタートさせるために学んできたことを僭越ながら皆さんに共有させていただこうと思います。 現在WEB系エンジニアとしての就職を考えている方や、これからエンジニアを目指していく学生の方にとって少しでもヒントとなるように、なるべく再現性の高い内容に絞ってお伝えしていくので是非最後まで目を通していただけますと幸いです。 （※注意） 今回紹介する内容はあくまで個人の経験による内容を多く含むものとなるので、必ずしもすべての人に等しくあてはまる内容とは限らないということをあらかじご理解いただきたいと思います。 一個人がエンジニアになるまでにどんなことを考え、何を実践してきたのかということを事実としてとらえていただけると記事の意図が伝わるかと思います。 学習のゴールを設定する 学んだことを紹介する前に、私がエンジニアとして就職を検討する際に行った「ゴール設定」をお伝えさせていただきます。 私がエンジニアとして就職するにあたって、まずはじめに行ったこととしては、 「技術をどこまで学習したら就職活動を開始するか」 ということを先に定めるようにしました。 目的にもよるかと思いますが、私の場合、WEB系エンジニアとしての就職がメインだったので下記のようなゴール設定で学習を本格的にスタートさせました。 「企業に見せる成果物（WEBアプリケーション）を1つ作成する」 私の場合、文系でしたので企業にとっては「プログラミングやWEBに関して何の経験もない人」と判断されることは当然の事実としてありました。 そのため、 ある程度、技術的な興味関心がある この業界で長く続けていける素養がある ことを示すために上記のような目標を設定しました。 学んできたこと ここから本題の私がWEB系エンジニアとして内定をもらうまでに学んできた技術的な内容に関してお伝えさせていただきます。 先に結論から述べさせていただくと、、 コンピュータサイエンス Linux HTML, CSS JavaScript Ruby RDB, SQL Git, Github Ruby on Rails 上記の順番で学習を継続してきました。 全体として、約3か月程度の学習期間を設けました。 そののちに、就職活動をスタートさせ無事、エンジニアとして就職することができました。 ここからは、上記の内容に関して実際にどんなことを学んできたかを深堀りしていきたいと思います。 コンピュータサイエンス はじめに、コンピュータサイエンスの基礎的な内容に関して学び始めました。 現在学生の方ですでに情報の分野を専攻しているorいた方は、このパートをスキップしてしまったも問題ないかもしれません。 私の場合、情報専攻ではなかったので下記のような内容を中心にコンピュータの基礎的な内容を一通り学びました。 n進数 デジタルデータ（ビットとバイトなど） CPU・メモリ ハードウェア・ソフトウェア データベース ネットワーク セキュリティ 実際に利用した参考文献も記載しておきます。 エンジニアとして実務にかかわる上で、上記のような内容を知っているのといないのでは、理解に差が生まれるので情報系以外の方は改めて学習しておくことをお勧めします。 参考 基本情報技術者試験 対策用書籍 Linux Linuxは、Windows, Macと同様にOSの一種で、アプリケーションのサーバーのOSとして利用されることが多いので、エンジニアとして業務を行っていく上では必須の概念になります。 主にCLI（Command Line Interface）でのコマンド操作を扱うことになるため、Linuxの基礎的な概念と併せてよくつかわれる基本コマンドを押さえておくと、今後の作業がスムーズになります。 参考 https://linuc.org/textbooks/linux/ HTML, CSS HTMLはWEBページを表示するための骨組みのようなもので、CSSはHTMLに色を付けたり大きさを変えたり等の装飾を加えるための技術になります。 HTML, CSSの学習を通じて、WEBサイトが表示される基本的な仕組みを学習しました。 基礎的な内容に関しては、オンラインの学習教材（ Progate , ドットインストール ）を使って一通り学習し、その後は他のWEBサイトを模写する形でアウトプットを行いました。 模写に使用したおすすめサイト： https://code-jump.com/ 参考 https://prog-8.com/courses/html https://dotinstall.com/lessons/basic_html_tags_v3 JavaScript JavaScriptはWEBアプリケーション開発でよく用いられるプログラミング言語で、フロントエンドと呼ばれるユーザーの目に触れる部分の仕組みを実装することができます。 HTML, CSS同様、基礎的なインプットに関してはオンラインの学習教材を使用しました。 アウトプットとして、先述のHTML, CSSで模写したサイトに動き（ユーザーのアクションに対するイベント処理等）をつけながら改良したり、アルゴリズムの問題をJSを使って解きながら文法を身に着けていきました。 参考 https://prog-8.com/courses/es6 https://dotinstall.com/lessons/basic_javascript_v6 Ruby RubyはWEBアプリケーションのバックエンドと呼ばれる裏側の仕組みを構築できるバックエンド言語になります。 フロントエンドの言語であるJavaScriptと合わせて、一連のWEBアプリケーションを構築するために、バックエンド言語のRubyを学習しました。 Rubyを選んだ理由としては、 文法が簡単で、初学者でも学びやすいため。 日本語のリファレンス等も豊富で調べやすいため。（日本人が開発した言語のため？） フレームワークやライブラリが豊富でWEBアプリケーションを開発しやすいため。 また、日本の企業では比較的Ruby, Railsを採用している企業が多く、求人数も多かったたことも選択した理由の一つです。 ここでも、オンラインの学習教材メインで使用して学習を進めました。 アウトプットに関しては後述のRuby on Railsでまとめて行いました。 参考 https://prog-8.com/courses/ruby https://dotinstall.com/lessons/basic_ruby_grammar RDB, SQL 続いて、データベースの学習です。 RDB（Relational Database）は現在のWEBアプリケーション開発で主流のデータベースになります。 主な特徴として、テーブルと呼ばれるデータをExcelの表のような形式で管理し、それぞれのテーブル間の関係性を定義していきます。 また、RDBに格納されたデータに対して問い合わせを行い、データの取得・削除・追加・更新等の操作を行うための命令を記述する言語がSQL（Structured Query Language）になります。 いずれもWEBアプリケーションのバックエンドを実装する上では必須の知識となります。 なお、RDBを管理する仕組みにはいくつか種類があります。 MySQL PostgreSQL OracleSQL 主流かつ代表的なものとしてはMySQL, PostgreSQLになりますので、その辺りを学習しておけば問題ないかと思います。 学習方法に関しては、私の場合、SQLは書籍を使用し、RDBに関してはオンライン学習教材使用して学習を行いました。 RDB(RDBMS)の種類や役割、基本的なSQL文の文法が理解できていれば問題ないかと思います。 参考 RDB SQLおすすめ書籍 Git, Github Gitはプログラミングコードの変更履歴を管理するためのツールになります。 実務では複数人のチーム単位で行うことが一般的なのでその際に、ファイルの変更や最新版のファイルの管理等を円滑に行うためにGitがほぼ確実に使われます。 まずは Github のアカウントを作成し、そこに学習で使用したソースコードを挙げておくようにすると、Gitの練習になるのでお勧めです。 Git, Githubの学習に関しては実際の動きを確認できる方がよりイメージしやすいかと思いますので、動画で行うのがおすすめです。（参考資料の中にも動画教材を挙げています。） ただし、Gitを学習する際の注意点として、動画等でインプットしたら必ずアプトプットまでセットで行うことをお勧めします。 概念・ルールを理解することより「操作できる」ことが重要になるため、教材で学んだらそれをご自身の環境でも実践してみる形で並行して進めていくことをお勧めします。 参考 YouTube Udemy Ruby on Rails Ruby on RailsはWEBアプリケーションの開発を効率的に行えるようにするためのRuby言語のフレームワークになります。 要するに、Rubyでアプリ開発する際に必要となる機能をはじめから準備してくれている便利ツールです。 学習の流れとしては、、 Railsで開発する全体像を把握する チュートリアル等を使用して実践する になります。 1の全体像に関してはオンライン学習教材の Progate の講座等を活用して、Railsがどんなもので、どんな流れで開発してくのかをざっくり理解するとよいでしょう。 次のステップとして、Railsで記述するコードの内容やGemの使い方等を詳細に理解しながら、チュートリアルを進めていくことをお勧めします。 環境構築でいろいろなソフトをインストールしたりバージョンを合わせたりする必要があり、思った以上に苦労した経験があるので、一つ一つの手順を把握しつつ進めることをお勧めします。 まずは、見よう見まねで手順通りに動かして、徐々に理解できて来たら自分なりに改良しながら理解を深めるような流れで行うと良いかと思います。 Railsを学ぶ上での代表的な教材として Railsチュートリアル があります。 こちらの内容が大まかに理解できれば成果物のアプリケーションを作成する上で困ることはほとんどありません。 Railsの学習まで一通り終えることができたら、チュートリアルで完成したアプリの延長線上で独自のテーマを設定して自作のアプリケーションの作成に取り掛かりましょう。 テーマは～クローン等ありきたりなものではなく、身の回りで感じた悩み等を解決できるような独創性の感じられるテーマで作成しましょう。 ちなみに筆者は、コロナ禍で自宅にいる時間に料理を通じてつながりを増やしたいという発想から、SNS×レシピサイトのようなテーマで作成しました。（なぜこういう発想に至ったのかに関してはあまり覚えていません（笑）） 参考 Progate Railsチュートリアル 学習のポイント 最後に学習のポイントについていくつかお伝えしようと思います。 5, 6割理解できたら進める 内容が理解できず何度も何度も反復してしまうという方も中にはいるかもしれません。 私自身も文系で何の知識もないところからのスタートだったので、非常に気持ちは理解できますが、学習の目的は、「成果物を完成させること」なので、内容をはじめのうちから内容を100%近く完璧に理解しておく必要はありません。 実践していく中で理解できてくることも多いと思いますし、そこに何時間もとらわれてしまうのは非効率になってしまっていることの方が多いと思います。 なので、「やった内容がざっくり頭に残っている」ぐらいの状態でさっさと先に進むようにすると挫折することなくスムーズに基礎学習を終えることができます。 アウトプットを重視する 経験上、書籍や教材でインプットしているだけでは、用語や一定の知識は多少身に付きますが本質的な理解につながらず、いつまでたってもプログラミングができるようにはならないと思います。 そのため、インプットを行ったら併せて必ずアプトプットも一緒にするべきだと思います。 割合としては 7:3 (アウトプット：インプット） ぐらいがちょうどよいかと思います。 先述の「5, 6割理解できたら進める」の話ともつながりますが、半分以上内容を理解できたらさっさと実践してみるとより効率的に身に着けられると思います。 何よりも、そっちの方が楽しいですよね！ ググりまくる エンジニアは実務において、実装方法に関して調べる場面が多々あります。 特に実装したことのない機能や、新しい技術を使用して実装するときなどはその割合が多くなります。 初学者であれば、なおさらわからないことや知らない知識・用語が多く出てくるかと思います。 ただ、安心してください。 そういった悩みはほとんど全てどこかの誰かしらが解消してくれています。 世界中の誰も遭遇したことのない目新しいエラーを引き当てる方が難しくなっています。 そのため、現在であればChat GPTなどの生成AI等の力も借りられるので、それらも活用しつつ自力で解決して、自力で実装する力をつけることがエンジニアとしてジョインしてからの苦労を減らすことにもつながると思います。 なので、わからなくてもとにかくググりまくって解決する癖をつけておくとよいかと思います。 投稿 文系・未経験からWEB系エンジニアになるために学んできたこと は マイナビエンジニアブログ に最初に表示されました。

はじめに 皆さん、こんにちは！デジ戦のT.Tです。 就職に伴い、上京する方はとても多いと思います。土地勘が無い中での住まい探しは不安だと思いますし、私も実際そうでした。 そこで今回は、私や同期の家探し状況や入社後の生活をお伝えし、少しでも参考にしていただけたらと思います。 経歴 静岡県出身。2024年よりUI/UXデザイナーとして入社。 大学では美術系の学部に在籍し、その中でもUI/UXデザインを中心に広くデザインについて学ぶ。 入社に伴い勤務地である新宿から電車で30分ほどの埼玉県に転居。同時に初めての一人暮らしを始める。 部屋選びで注意することってある？ 私の場合は周辺環境を特に重視していました。中でも重視していたのはこの３つです。 虫の出にくさ 2階以上 日当たりの良さ（北向きは絶対に避けていました。） 付近に公園などの自然が無いところ 徒歩圏内にスーパーがあるかどうか 駅からの近さ 最寄駅から徒歩15分圏内で探していました。 初めての一人暮らしだったため、部屋選びに関する知識は全くありませんでした。大学時代から一人暮らしをしている友人から助言をもらい、確認すべき項目をまとめたチェックリストを作成してから不動産屋に向かった記憶があります。 人気のエリアってあるの？ 基本的には東京在住の方が多い印象です。 路線でいうと、私の体感ですが小田急線沿いと埼京線沿いが特に多いイメージです。小田急線沿いでいうと、特に登戸にはなぜか関西出身の同期が集中しています。埼京線沿いも多いですが、こちらは結構最寄り駅はばらけている印象でした。 他にも埼玉県や神奈川県、千葉県といった県外から通われている方もいらっしゃいます。県外でいうと埼玉県が特に多い印象です。私も埼玉県から出社しています！ 家賃って実際どれくらい？ 家賃は、管理費込みで9万円ほどです。同期にも聞いてみたところ、6万円～9万円台と意外と幅広い結果が得られました。 私は部屋探しにあたってかなりこだわり（虫の出にくさや水回りなど・・・）があったためこの価格でしたが、選り好みしなければある程度家賃を抑えることも可能だと思います。 部屋の広さ リビングが6畳半くらいです。同期にも聞いてみたところ、大体5.5~7畳台くらいが多い印象でした。 ベッド、デスク、棚を置くとある程度面積は埋まってしまいますが、一人で住むことや掃除のしやすさなどを考えると個人的には丁度良い広さだと感じています。決して広いとは言えないですが、この「私の城」感をとても気に入っています！ レイアウト 1K、風呂・トイレ別の独立洗面台付きの部屋です。 部屋決めにあたって風呂・トイレ別と独立洗面台だけは絶対に譲れないポイントだったため、とても気に入っています。 ドアや窓の配置や部屋自体の形は家具のレイアウトやその後の住みやすさにも大きく関わってくるので、間取り図や内見でチェックしてみてください！ 定時後の生活 基本そのまま家に直帰していますが、週１，2回ほど同期と夜ご飯を食べに行きます。私が勤務している新宿のミライナタワーオフィスでは付近に美味しいご飯屋さんや有名チェーン店が多く、同期のおすすめのお店に連れて行ってもらうことが多いです。 同期として研修やインターンシップなどの話もしますが、同世代の友達としての会話もできる貴重な機会だと思っています。 休日の過ごし方 休日は、沢山寝たり平日出来なかった家事をやったりと、ゆっくりとした時間を過ごしています。 同期の方々と遊びに行くことも多いです。最近は一緒に服を買ったり美味しいものを食べに行ったりしました。 新社会人と初めての一人暮らし、不安はあった？ 私は実家から大学に通っていたため、社会人になると共に一人暮らしをスタートさせました。 家事にかなり苦手意識があり、一人暮らしが決まった段階からかなり不安を感じていたのを覚えています。 そんな私でも、今のところ生活に困らない程度にしっかり一人暮らしできていると思います！ 「この時間に洗濯だけでもやろう」など最低限のタスクを決めて、自分の余力を見てプラスワンの家事もやる、といった方式で家事をやっています。 また現段階では週1～2回テレワークがあるため、本来通勤に使う時間で家事を片付けたりと時間の活用を工夫しています。 最後に 一人暮らしの醍醐味はなんといってもこの自由さだと思います。 一人暮らしに不安を感じている方もいるかと思いますが、一緒にこの自由を楽しみましょう！

はじめに こんにちは！デジ戦のM.Mです。 今回は、入社後はもちろん、就職活動においても重要な、マイナビで利用できる 「福利厚生」 についてご紹介します。 近年、働く上でワークライフバランス等を意識する人が増えており、「福利厚生」は重要な会社選びの基準となっています。 マイナビでも、社員の働きやすい環境やモチベーションの維持を目的に、様々な福利厚生が用意されています！ この記事では、マイナビにどのような「福利厚生」があるか、会社生活編と私生活編に分けて紹介していきます。 ◆会社生活編 スキルアップ マイナビには様々なスキルアップ制度が用意されています。これらを活用して、効率よく自分の能力を磨きましょう。 IT・ビジネス資格取得支援制度 マイナビの資格支援制度には、 受験料補助型と祝金型 があります。 受験料補助型では合格不合格問わず、資格ごとに 受験料が全額支給 され、祝金型では該当資格については 取得祝金が支給 されます。 書籍購入制度 業務を遂行する上で必要な書籍や定期購読物などを、会社経費で購入することができます。 Udemy 学習プラットフォーム「Udemy」を用いてさまざまなジャンルのスキルを習得することができます。 「Udemy」には プログラミングやAI、データ分析などだけでなく、マーケティングやビジネススキルなどに関する幅広いテーマの動画 が投稿されています。 IT知識だけでなく、新しく社会人になる皆さんにとって役に立つ講座がたくさんあるので、自分が学びたいテーマに合わせてコンテンツを選択し、スキルアップできます！ 健康・ヘルスケア 「マイケアルーム」 マイナビグループ社員向けのマッサージルームです。 オフィス内に設置されており、 格安（45分1,000円ほど） でマッサージを受けることができます。 デスクワークの増える社会人にはマッサージが必須です！ 一般のマッサージ屋さんだと、施術者との相性によって当たりはずれがありますが、マイケアルームでは全員が国家資格を持ったヘルスキーパーのため、安心して施術を受けることができます。 資産形成 マイナビ社員持株会 会員が自分の勤務する会社の株式を取得することを容易にし、中長期的な資産形成を支援する制度です。 積立金以外にも、積立金への奨励金・保有株式に応じた配当金などがあります。 ◆私生活編 福利厚生施設 会社生活も大切ですが、どうせなら私生活も充実させたいですよね…！マイナビには全国各地に保養所や提携ホテルがあります。施設の多くは、家族や友人と利用することができます。 保養所 　中軽井沢・京都・沖縄にそれぞれ保養所があります。 　保養所なので空いていれば好きな時に利用できます。特に週末は大人気で、家族や友人と過ごす方が多いようです。 会員制リゾートホテル 保養所以外にも、マイナビでは会員制リゾートホテルを契約しているため全国の対象施設を格安で利用できます。 箱根や軽井沢、京都などの魅力的なリゾートが多数あります。 マイナビグループ社員本人およびその家族が利用可能です！ 社員優待 福利厚生施設の他にも、社員優待があります！ 健康なお弁当のサブスクを安く利用可能 マイナビ従業員は、冷凍のお弁当を常時60種類以上サブスクで販売しているサービスをお得に利用できます。プロの料理人と管理栄養士が監修している健康なお弁当を、1食500円程度で注文できます！ 1人暮らしを始める方もいると思いますが、社会人1年目は新しい環境にばたばたすることも多く、ご飯を作る余裕のない日もあるかと思います。健康なお弁当はそんな日の心強い味方ですね…！ スポンサーチケットをお得に購入可能 マイナビがスポンサーをしているイベントのチケットを安く購入できることがあります。もちろん、イベントの種類や状況に応じて条件は異なりますが、仕事の息抜きに同期や友人とイベントに参加してみるのもいいですね！ 福利厚生サービスの利用 サービス数100万以上の福利厚生サービスに加入しており、いつでもどこでも何度でも利用することができます。 サービスには、eラーニングの受講、映画館等の割引補助、育児・介護補助等があります。 おわりに 以上のように、マイナビにはお得な福利厚生制度がたくさんあります。 他にも色々な制度がありますので、気になったらぜひマイナビの採用イベントで聞いてみてください！ 閲覧いただきありがとうございました。

はじめに 皆さん、こんにちは。マイナビエンジニアブログ編集チームです。 本年度も4～6月の3か月間で、デジタルテクノロジー戦略本部の新人研修が行われました。 今回は、新卒2名の方に「新人研修で学んだことと今後の抱負」についてインタビューしました！ 新卒研修の概要 概要は以下の記事をご覧ください。 ※昨年度の内容になりますが、概要は今年度とほとんど同じになります。 ###card_post_id=1471### 自己紹介 T.Yさん（システムエンジニア／システムディレクター） 学生時代は「システム理工学部 数理科学科」で、主に数学を学んでいました。また、教職課程も勉強していて、高校数学の教員免許を持っています。大学時代から、「論理的な思考」や「問題解決」、「人の人生に影響を与えるようなこと」に興味がありました。 マイナビであれば、サービスを利用する多くの方の人生に良い影響を与えることができ、これからITに力を入れていくという方針であるというのを就活時に知って、この会社に入社いたしました。 しかし、 IT業界についてはほとんど未経験で、 新たなフィールドに挑戦することに不安であり、緊張していました。 I.Tさん（WEBアプリケーションエンジニア） 東北出身で、大学卒業まで仙台に住んでいました。学生時代は、「工学部 電気電子工学科」に在籍していて電気情報を学んでいました。趣味で iOSアプリやモバイルゲームを開発 していて、プログラミングを使った職業に興味がありました。マイナビは事業会社で事業も幅広く展開しており、IT分野も急成長していて、この環境であればITエンジニアとして成長できると思い、入社を決めました。 しかし、Webアプリ開発の経験は マイナビハッカソンインターンシップ に参加したのがほとんどで、今までとは違った開発言語やフレームワークを使うと聞いていたので自分の経験を活かせるか不安でした。 新人研修で学び得たことはありますか？ T.Yさん（システムエンジニア／システムディレクター） 私は研修を通して、ITに関する基礎的な知識を得ることができました。HTMLやPythonなどのプログラミング言語の基本から、ソフトウェア開発のプロセス、チームでの働き方など、多くのトピックを学びました。最初は、 ITの知識やコードを書く経験がほとんどなく 、毎日が学び続けるような日々でした。 研修の最後にはチーム開発を行いました。私は研修で得られた知識を活かして、複数の機能を実装できるほどの成長をしました。研修当初は コードがほとんど書けなかった自分が、複数の機能を実装できた時は、 成長を実感することができました。 また、私のチームは全部8チームある内の 技術賞 をいただくことができました。その時の達成感は非常に大きく、チームで一つのことをやり遂げることの良さを学ぶことができました。 I.Tさん（WEBアプリケーションエンジニア） 私は2つあります。 (1)Web開発におけるスキル全般 AWSやデータベースなどのWeb開発におけるスキルをつけることができました。私はプログラミングの経験はありましたが、研修前まではWeb開発に関する知識はほとんどない状態でした。研修にあったAWS研修ではコンソール画面を自分で操作して、EC2サーバーの作成とセットアップを行いました。アドレスを自分のスマホに入力して、作ったサイトの画面が閲覧できた時にはWebサイトはこうやって作ることができると知れて感動しました。 　またデータベースに関しても全く知らない状態でしたが、基本的な文法からテーブルの結合・設計まで学びました。研修ではSQLに関する問題集が用意されていて、コードを書きながら学習するので、まるでゲームをしているような感覚で取り組むことができました。 (2)コミュニケーションスキル 研修にはグループワークや発表する機会が多くあり、人に伝えたいことを伝えられるコミュニケーション力をつけることができました。大学時代にはほとんど個人開発しかしていなかったので、チーム開発でのコミュニケーションや自分の考えを人前でプレゼンしたりすることがとても不安でした。研修にはチーム開発や、同期の前でプレゼンする「3分間プレゼン」など多くのコミュニケーション力をつけるための機会が用意されていました。私は他の人のプレゼンでよかったところを真似してみたり、Udemyという動画学習サービスや社内で用意されているfilerという本の要約が掲載されているサービスを使ってプレゼンに関するコツを取り入れることで、コミュニケーションに対する苦手意識を少し克服することができました。 研修を振り返って、楽しかったことはありますか？ T.Yさん（システムエンジニア／システムディレクター） 主に2つあります。 (1)研修を通して知識が身に付いていき、機能を実装できたこと 前述したように、研修当初はプログラミングにほとんど触ってきませんでした。しかし、研修終盤には複数の機能を実装できるほどの成長して、その結果チームメンバーから感謝されました。その時は非常に嬉しく、自分が他人に対して良い影響を与えることの楽しさに気づくことができました。 (2)与えられた課題をチームで解決できたことです。 1人では解決できないような内容でも、複数人で協力し合いながら作業を進めていき、無事解決できた時は今まで経験のない達成感と楽しさを感じることができました。チーム活動を通して、同期との仲も深めることができ、その点も嬉しく思えた点です。（そのようなチームメンバーで行く飲み会は最高です！） I.Tさん（WEBアプリケーションエンジニア） 私も2つあります。 (1)Webサイトの開発と発表会 研修では学んだ技術を使って自由に開発する時間があり、その中で分からなかった部分を突き詰めたり、プログラミング経験者同士で作成したものを共有するのが楽しかったです。私以外にも経験者は多くいて、ToDoリストやクイズ、チャットアプリなどいろんなものを作っている人がいて面白かったです。私は簡単なブログアプリを作りました。 (2)自分の名刺をデザインしたこと 研修にはITに関するものだけではなく、デザインやマーケティングなどを学ぶ研修もあり、特にデザイン研修の自分の名刺を作成して同期同士で見せ合ったのが印象に残っています。私は今までデザインとは無縁の生活をしていたので、デザインの基礎である配色やレイアウトを教わり、これを意識するだけでそれっぽいデザインの名刺が作れたときは嬉しかったです。同期にはデザイナーの方もいて、成果物をみせてもらったときには凄すぎて驚かされました。この研修を通して、その後のプレゼン資料の作成や開発に活かすことができて、研修の恩恵を大いに感じることができました。 ▲私が作ったブログアプリです。 ▲自分でデザインした名刺です。 逆にもっとも大変だったことは？ T.Yさん（システムエンジニア／システムディレクター） ２つあります。 (1)同期の方との差を感じた時 私がIT初学者だったということもありますが、私が問題を1つ解いている間に何問も解いてしまう方もいて、悔しい思いをしました。しかし、同期の方はみんな優しく、質問をしたら必ず教えてくれて、苦戦しながらも理解をして、問題を解けることが多かったです。この時に周りの環境を頼ることの重要性を学びました。 (2)基本情報技術者試験に落ちてしまったこと 社会人になりこれまでと環境が変わったというのと、研修と両立しながらだったので、試験勉強に取り組む時間が作れず、一度挑戦しましたが、落ちてしまいました。周りに受かっている同期がいる中、私は落ちてしまい、非常に悔しい思いをしました。そのため、もう一度勉強をしなおして再受験をしました。その際も研修と勉強の両立が大変でしたが、2回目の挑戦で無事合格をすることができました。隙間時間に（短い時間でも良いので）継続して勉強をすることが重要だと実感しました。 I.Tさん（WEBアプリケーションエンジニア） 研修の最後にはシステムをチームで開発する研修があり、要件定義からプログラミング、テストまでの一連の流れを期間中に開発して納品するのが大変でした。 要件定義では、他のチームから実装してほしい機能をヒアリングし要件定義やシステム設計をしました。依頼される機能は本当に開発期間中に実装できるか、そもそも必要なのか考えながら進めていく必要があり、大変苦労しました。 開発期間ではGitの運用やディレクトリ構成、変数の命名規則などのルールをチームで考えたためチーム開発における手法に関しても学ぶことができました。開発では特に今まで実装したことがないような検索機能や絞り込み、お気に入り機能などをシステム設計で組み込みすぎてしまったため、当初組んでいたスケジュール通りに進まず、胃を痛めてしまったメンバーがいたほど大変でした。 そこで、タスク管理の方法を見直したり、ペアプログラミングを取り入れて開発スピードを上げたり、メンバーの頑張りによって計画していた機能をほぼすべてを実装し納期日に間に合わせることができました。 また最後の成果報告会では納品した成果物が評価され、グランプリをいただくことができました。メンバーに恵まれたことや時間的に実装できるか難しい機能でも、最後まで諦めずに開発を続けることが要因ではないかと思っています。この研修は一番大変でしたが、終えたときの満足感も一番でした。（チームメンバーとの打ち上げも最高に楽しかったです！） ▲最後の開発演習プロジェクトで実装したサイトです。 今後の抱負について教えてください。 T.Yさん（システムエンジニア／システムディレクター） 研修を通して、IT業界の魅力に気づきました。今まではサービスを利用する立場だったのが、今度はサービスを作る立場に変わり、IT技術の利便性をより一層意識するようになりました。現在はまだ配属前で具体的にどのような業務をするかは未定ですが、配属後は自分が携わるサービスを利用するユーザーの方に少しでも便利だなと思ってもらえるようなシステムを作成することが今後の抱負です。 上記の抱負を達成するためには、自己の成長が欠かせないと考えられます。そのため、自宅のPCでも開発環境を整えて、研修を振り返りながら自分でWEBサイトを作成することと基本情報技術者試験よりも難易度の高い資格に挑戦することを抱負達成のための目標として日々成長し続けたいです。マイナビにはこれらの目標を達成するための制度・環境が多くあります。そのような環境に頼りながら、抱負を達成できるよう精進していきたいです。 I.Tさん（WEBアプリケーションエンジニア） この研修を通して学んだことはWebアプリケーション開発の面白さと可能性です。 入社前まではあまりWebアプリケーションを使った開発経験がなかったこともあり、言語やフレームワークの種類の多さ、Webアプリケーションの仕組みについて学ぶことが多くありました。Web業界の進歩はものすごいスピードで進んでいて、私は社会や世界中の人に大きな影響を与えることができる可能性があると思っています。マイナビは事業規模が大きい会社なので開発エンジニアにとって幅広く活躍できる環境のではないかと考えています。 そういった中で日頃から、技術に関する情報収集や開発経験を積み、いち早く戦力になれるように勉強していきたいです。 おわりに 2人にインタビューを行って、研修にて学び得たものはとても大きかったのだと感じました。 デジタルテクノロジー戦略本部の新人研修ではプログラミングの分野だけでなく、チーム開発、デザイン、データサイエンス、マーケティング、さらには3分間プレゼンのようなコミュニケーションスキル向上まで幅広く行っているため、自己成長するには最適な環境ですね。 配属後は、それぞれの部署で大いに活躍してもらいたいなと思います。 最後まで読んでくださり、ありがとうございました。

はじめに 皆さんこんにちは！マイナビのシステムエンジニア、N.S.です。 私は、韓国生まれ韓国育ちの韓国籍エンジニアです。Career in Japan 2022の採用イベントに参加し、マイナビの内定を頂きました。 今は立派なSEとしてマイナビで日々楽しく働いております。 この度は、私がマイナビで働くきっかけになったイベントに運営側として参加させていただきました。熱かった現場の雰囲気を皆様にご共有できればと思っております。 Career in Japan 2024とは 韓国貿易協会、マイナビ国際派就職、マイナビコリアで主催する採用イベントです。毎年韓国ソウルで年二回イベントが開催されています。主に日本企業に就職を希望して、韓国で面接を受けることができる学生さんが参加するイメージです。 現場に行く前に 現地での登壇以外に、私はマイナビITコース採用のオンライン説明会とWebセミナーに先輩社員として参加致しました。オンライン説明会では緊張もしましたが、沢山の方がマイナビの魅力を感じて欲しく、頑張って弊社について伝えました。Webセミナーは、（ここだけの話）実はNG7回で収録しました。熱い思いが伝わってくださっていたら嬉しいです。 イベント当日 イベント当日には各企業の選考を通じて、面接を受ける学生さんたちがイベント会場にいらっしゃいました。私も面接者の受け入れや案内、企業説明、当日エントリー者には面接官として参加させて頂きました。 面接志望者と向き合って 少し緊張した様子でしたが、多くの学生さんたちが熱心に準備しただけに、自分の魅力をアピールする瞬間を味わいました。みんなが一生懸命で、自分もその元気いっぱいのエネルギーをもらうことができました。また、面接の直前は少しでも皆さんの緊張が解けてリラックスできるように声をかけたりしました。 企業説明会 企業説明会には、マイナビに興味を持った多くの学生の方々が参加してくださいました。私は実際に働く現場の雰囲気とデジタルテクノロジー戦略本部の魅力を伝えようと頑張りました。最近登壇した別イベントである多国籍交流会についても伝え、デジ戦には多国籍のエンジニアが活躍していることも伝えました。 マイナビの企業説明会が終わって帰ろうとしたら、何名かの学生さんに声をかけられました。企業についての質問をたくさん受けましたが、マイナビで働いて一番やりがいを感じることは何ですか、 先輩後輩社員との関係性はいかがですか、会社で仕事以外の楽しいことは何かという質問を頂きました。 そして学生さんに言われて一番嬉しかった言葉は、私のような素敵なエンジニアになりたいと言われたことです。 私も誰かのロールモデルになることができて嬉しい反面、もっと精進しなければならないと思い、物凄く感銘深い瞬間でした。 最後に 先日、私が働くきっかけとなったところで会社の魅力を伝える側としてイベントに参加することができてとても感銘深く貴重な瞬間でした。また、マイナビコリアと他事業部で活躍中のマイナビの韓国籍の社員さんたちと交流できてとても嬉しかったです。 また、私が今回のイベントに参加して以来、一番大きく感じたのは、誰かが私のようなエンジニアになりたいと感じるほど、もっと尊敬できる先輩エンジニアとして成長したいと思いました。頑張ります！ 少しでもこの記事を読んで現場の熱かった雰囲気が伝わったらうれしいです！

はじめに 株式会社マイナビでは実際の仕事を数か月かけて体験していただく就業型インタ―ンシップを実施しています。 本記事はS君に就業型インターンシップに参加したきっかけや、実際に参加して経験した業務などを振り返っていただいた内容になっています。 自己紹介 情報系の学部に通っている3年生です。 大学ではWebを中心に、企画・マーケティング・デザイン・開発・チームマネジメント・UXUIなど幅広く学んでいます。 個人ではアプリ開発はもちろん、アーティスト活動や合唱活動などをしています。 趣味ではゲームやスポーツ、漫画、アニメなどのエンターテインメントに囲まれた生活を送っています！ 就業型インターンシップ参加までの流れ マイナビを知ったきっかけは、以前からマイナビのサービスを自己分析などで利用していましたがエンジニア採用があることを知ったのは大学3年生の春に参加したオンライン合同会社説明会でのことでした。 また、そこでマイナビにエンジニア向けインターンシップがあることも知りました。 まずは、【ハッカソン】フルスタック開発プログラムに参加し、その後就業型インターンシップの案内がありました。 自己満足ではない、社会的信頼の問われる、責任のある実務としての開発経験を積みたいと思い参加を決意しました。 1日の動き 時間 仕事内容 10:00 ~ オフィスに出社して打刻し、メールとタスクの確認 10:15 ~ 事業部との確認・タスクを行う・悩んだときは上長や社員へ相談 13:00 ~ お昼休憩（一人で食べに行ったり。社員とご一緒させていただくことも！） 14:00 ~ 事業部との確認・タスクを行う・悩んだときは上長や社員へ相談 17:30 ~ タスクの進歩まとめ 18:00 ~ 退勤 在宅頻度 自分はオフィスが好きだったので在宅していませんが、上長からは「いつでも在宅していい」と言っていただいておりました。 PCの持ち出し申請をして上長に確認をもらえればいつでも在宅できたので、マインド的にもとても働きやすかったです。 ↑　お気に入りの昇降式デスクです。 実際にやったこと リリース前のプロダクトの開発に取り組みました。主にフロントエンド開発に携わらせていただき、デザインからフロントロジック、API操作などの実装を行いました。 使用技術 AWS(EC2) Docker Ruby on Rails Next.js13(Typescript) NextAuth Tailwindcss 学びと感想 エンジニアとしての技術はもちろん学びなりましたが、それ以上に組織・チームの一員として開発していく体験がとても学びになりました。 上長は良い意味で放任的な方で自由に開発に取り組ませてくださったため、そのなかでいかに効率よく丁寧に仕事をこなしていくかを日々考えて取り組んでいました。 例えば、タスクに対してアイデアがあるときとないときがあります。アイデアがあるときはスムーズに実装に移れますが、そうでないときは、調査→実装をしなければなりません。 インターンシップが始まったばかりのころは、この調査→実装に時間をかけすぎてしまいがちでした。タスクに時間がかかるということはプロジェクト全体に迷惑をかけてしまうという責任があります。 そこで、あらかじめ調査・実装に使う大まかな時間を設定し、時間内は粘って、設定時間を超過しそうな場合は迷わず上長や社員へ相談するように心がけました。それによって徐々にタスクの効率も上がるだけではなく、社員とのコミュケーションも増えていきました。 自分は良くも悪くも最後まで自分でやり切りたいという思いが強く、コードを書いていると「もう少しでできそうだから粘りたい…」なんてことが多々ありました。 もちろんなんでもすぐに質問するのではなく一旦自分で調べてやってみることは大事だと思います。ただ自分を追い込みすぎてもよくないと感じました。 潔く質問することがチームないしはプロジェクトの作業効率を上げるだけではなく、逆に良いチップスや参考にできるコードを教えてもらい、いいベクトルに伸びていく。 できないこと、わからないことを恥ずかしいと思わず、素直になることの大切さや、チームで開発する責任と楽しさを一番学んだ時間だったと思います。 どんな質問でも快く答えてくださった上長や社員の皆さんには感謝してもしきれません。この場をお借りして感謝申し上げます。本当にありがとうございました！ ↑　メンターを務めたSさんと。

背景 Udemyで講座受講後、無事GA4のGoogleアナリティクス認定資格に合格できました。 忘れないうちに簡単に振り返りをしつつ、今後受験を検討されている方へ、少しでも役立つご共有ができればと思います。 Udemyで受講した講座 GA4に関する知識を証明する！「Google アナリティクス認定資格」試験対策講座 Googleアナリティクス認定資格合格を目的とした講座。 進め方も分かりやすく、初心者向けの丁寧な説明でとても良かったです。 試験対策の部分と、試験に関係ないけど重要な部分をしっかり分けて説明されていました。 講師である木田さんの話し方も、聴いているうちにクセになるような感じで、耳に残りました。 学習方法 10月～Udemyで上記コースを1周閲覧 通勤の電車で週2～3回、10～20分/回視聴（1.25倍速再生） Google公式のスキルショップ内コンテンツでは学習せず 家ではあまり定期的に時間が取れないため、通勤電車内だけでやると決め込み、 12月中までに試験に合格することを目標として、コツコツ続けていきました。 Google アナリティクス認定資格（GA4）とは 以下 Google アナリティクス認定資格 より引用 Google アナリティクス 4 を活用して、有用な分析情報を取得し、マーケティング上の意思決定を行う能力があることをアピールしましょう。認定を受けると、プロパティの設定と構成、各種レポートツールや機能の使い方など、Google アナリティクスを理解していることを証明できます。 Google アナリティクス認定資格を取得すると、以下の能力があると認められます。 ・ウェブサイトまたはアプリ用に Google アナリティクス 4 プロパティを設定する ・ビジネスに必要なデータを収集し、各種レポートツールや機能を使用する ・オンライン マーケティング活動の効果を示す主な測定機能を認識する 受験場所： Skillshop 費用：無料 試験方式：4択50問（一度回答したら前の問題には戻れない） 制限時間：75分 合格基準：80％以上 再受験：何度でも受験可（ただし1日空ける必要あり） 以前GAIQ（ユニバーサルアナリティクスVer.）を受験した際は、60分70問だったので、 比較すると少し余裕があった印象です。 試験内容・感想 スマホでも手軽に受験可能なため、受験のハードルが低い点が良いと思いました。 制限時間は75分ですが、30分程度で終了しました。 Udemy講座資料の中の、太字部分が主に出題された印象です。 ひっかけ問題や解釈が難しい問題などはなく、素直に回答すればよい内容が多かった印象です。。 全問回答後はすぐに結果が分かりますが、どこを間違えたのかは分からない点が、少しネックです。 Udemyの講座で十分対策できるレベルの内容でした。 以前、GAIQ受けた際はスキルショップで学習後、2回目でようやく合格できましたが、 今回は何とか一発で合格できました。 ただ正答率は84％とギリギリ合格だったので、内容を復習後、再受験しようと思います！ 今後受験される方へのおすすめ 学習にあたっては、目標と期限を設定しておくと継続しやすいかと思います。 この試験は何度も受験できるので、ガッツリ勉強してからではなく、まずは一度試しに受験してみて、なんとなくポイントを掴んでから学習を進めると効率良さそうだと思いました。 投稿 Udemyを使ってGoogleアナリティクス認定資格（GA4）に一発合格！ は マイナビエンジニアブログ に最初に表示されました。

はじめに 昨年、運用を担当しているWeb集約基盤にて一部サイトのアクセスが急増し、データベースのコネクション上限に達したことで新たなコネクションが確率できずにサイトダウンとなる障害が発生しました。 再発防止策としてAmazon RDS Proxy（以下、RDS Proxy）を導入したので、選定理由や導入のあれこれを記事にしてみようと思います！ Web集約基盤について 今回障害が発生したのは社内で共通化されているWebサイトの集約基盤で、本番・STG合わせて100以上のサイトが稼働しています。 コストやサイト規模を考慮してデータベースを複数サイトで共用しているため、今回の障害のようにコネクション数が枯渇するとデータベースを共用している全てのサービスに影響が出てしまいます。 サイト数が多く影響範囲も広いことから、再発防止は重要な課題でした。 選定理由 RDS Proxyとは (以下　AWS公式サイトより引用： https://aws.amazon.com/jp/rds/proxy/ ) Amazon RDS Proxy は、Amazon リレーショナルデータベースサービス (RDS) 向けの高可用性フルマネージ型データベースプロキシで、アプリケーションのスケーラビリティやデータベース障害に対する回復力と安全性を高めます。 簡単に言うと、アプリケーションとリレーショナルデータベースの間に配置し、データベースへの接続を効率的に管理することでアプリケーションのスケーラビリティを向上させるサービスです。 導入メリット コネクションプーリングによるリソース効率の改善 フェイルオーバー時間の短縮による可用性向上 AWS Secrets Manager や IAMを利用した認証情報の管理 RDS Proxy導入のメリットとしては上記の通りいくつかありますが、今回の障害の再発防止策として特にコネクションプーリングに着目しました。 アプリケーションがDBとの接続をプールしたり共有することで、データベース効率とアプリケーションの可用性が向上するため、データベースコネクション数の枯渇の回避が期待できます。 上記のメリットに加え、導入も比較的容易であることからRDS Proxyを導入する方針に決まりました。 その他の検討案 選定理由としてRDS Proxy導入のメリットを挙げましたが、もちろん他の案を検討していなかった訳ではありません。 Auroraサーバレスや分散型データベースの導入なども検討にあがったものの、以下のような理由で却下となりました。 Auroraサーバレス 障害発生時、データベースのCPU/メモリは逼迫していなかったため、同様の事象が起きた際のスケーリングが期待できなかった。 分散型データベース 社内で導入実績が少なく、データ移行も必要となることから対応負荷を考え見送りとなった。 それでは、本題のRDS Proxyの導入について進めていきます！ RDS Proxyの導入 RDS Proxyの導入までは、大まかに以下のような順で進めました。 ①Secrets作成 ②RDS Proxy構築 ③エンドポイント切り替え ①Secrets作成 RDS Proxyでは、Secrets Managerを利用してRDS Proxy データベース間の認証を行うため、まずはSecretsを作成します。 集約基盤ではサイトごとにデータベースのユーザー・パスワードが異なるため、各サイト毎にSecretsを作成する必要がありました。 各サイトの設定ファイルでユーザー・パスワード情報を管理しているので、ユーザー・パスワード情報を設定ファイルから抜き出し、CLIコマンドを利用して一括でSecretsを作成しました。 ※サイト毎にSecretsが存在するという点が、実は今回一番苦戦する原因となったところです…詳しくはRDS Proxy構築の部分でお話します。 ②RDS Proxy構築 いよいよRDS Proxyの構築です！ 我々の部署ではCDKやCloudFormationといったIaCを導入していて、インフラもコードで管理することが主流となっています。 集約基盤ではCloudFormationを採用しているため、RDS Proxyの構築はCloudFormationで行いました。 RDS Proxyの構築に必要なリソースは以下となりますが、SecretsはCLIで作成済みのためその他のリソースをCloudFormationで作成・変更していきます。 Secrets Manager セキュリティグループ IAMロール・ポリシー RDS Proxy セキュリティグループ セキュリティグループは既存のテンプレートで管理しているため、既存テンプレートを修正しました。 詳細は割愛しますが、ECS→RDS Proxy間の通信と、RDS Proxy→データベース間の通信を許可すればOKです。 エンドポイント切り替えまでは ECS→データベースの通信経路となるため、そこの設定は残したままにしておき、切り替え後に安定稼働を確認できたら削除します。 RDS Proxy RDS Proxyのテンプレートでは、RDS ProxyにSecrets Managerの参照権限を付与するIAMロール・ポリシーも一緒に作成します。 今回作成したRDS Proxyのテンプレートがこちらです。 AWSTemplateFormatVersion: 2010-09-09 Description: Create RDS Proxy. #-----------------------------------------------------------------------------------# Parameters: #-----------------------------------------------------------------------------------# EnvName: Type: String Default: dev AllowedValues: - dev - stg - prod #-----------------------------------------------------------------------------------# Metadata: #-----------------------------------------------------------------------------------# AWS::CloudFormation::Interface: ParameterGroups: - Label: default: "Common Configuration" Parameters: - EnvName #-----------------------------------------------------------------------------------# Resources: #-----------------------------------------------------------------------------------# DBProxyRole: Type: AWS::IAM::Role Properties: Path: / AssumeRolePolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Principal: Service: - rds.amazonaws.com Action: sts:AssumeRole Policies: - PolicyName: sample-dbproxy-secret-policy PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: - secretsmanager:GetSecretValue Resource: - !Sub "arn:aws:secretsmanager:${AWS::Region}:${AWS::AccountId}:secret:sample-dbproxy-*" DBProxy: Type: AWS::RDS::DBProxy Properties: DBProxyName: sample-dbproxy EngineFamily: MYSQL IdleClientTimeout: 3600 RoleArn: !GetAtt DBProxyRole.Arn VpcSubnetIds: - Fn::ImportValue: !Sub ${EnvName}-private0 - Fn::ImportValue: !Sub ${EnvName}-private1 VpcSecurityGroupIds: - Fn::ImportValue: !Sub ${EnvName}-DBProxy-securitygroup Fn::Transform: Name: AWS::Include Parameters: Location: !Sub "s3://cfn-for-dbproxy-${AWS::Region}/${EnvName}-auth.yml" DBProxyTargetGroup: Type: AWS::RDS::DBProxyTargetGroup Properties: TargetGroupName: default DBClusterIdentifiers: - !Sub ${EnvName}-db-cluster DBProxyName: !Ref DBProxy ConnectionPoolConfigurationInfo: MaxConnectionsPercent: 90 MaxConnectionsPercent RDS Proxy がターゲットデータベースに対して確立できる接続の数を制限する項目で、データベースで使用可能な最大接続数（max_connections）に対する割合 (%) で指定します。 デフォルトでは MaxConnectionsPercent の半分（50%）まではアイドル状態の接続が確立されることが期待される挙動となっており、最大接続数はMaxConnectionsPercentを超えることは無いといったしようとなっています。 例えば、データベースターゲットの max_connections が 1000、RDS ProxyのMaxConnectionsPercent が 95 に設定されている場合、RDS Proxyのデータベースターゲットへのアイドル状態の接続は約半数の475前後を保持し、同時接続の最大は 950までとなります。 Web集約基盤ではデータベース接続をRDS Proxy経由で行わないケースが一部存在するため、データベースのmax_connectionsを使い切らないよう90％に設定しています。 SecretsArnの設定について 先ほども少し書きましたが、今回一番苦戦した部分がSecretsArnの設定です。 各環境・各サイト毎にSecretsが存在するため、RDS ProxyのテンプレートにすべてのSecretsを記載してしまうと膨大な量になります。 コードの可読性が下がること、サイト追加の度にテンプレート修正が必要となり運用負荷が高くなることなどからテンプレートに直書きは避けたい部分でした。 そこで、AWS::Include関数を利用して以下のようにSecretsArnの設定部分だけ外部ファイルから取ってくるような仕組みにしました。 各サイトのSecretsArnを記載した${EnvName}-auth.ymlを作成してS3 Bucketに配置し、RDS ProxyのテンプレートでS3 Bucketに配置したファイルを読み込ませます。 DBProxy: Type: AWS::RDS::DBProxy Properties: DBProxyName: !Sub sample-dbproxy ~ 中略 ~ Fn::Transform: Name: AWS::Include Parameters: Location: !Sub "s3://cfn-for-dbproxy-${AWS::Region}/${EnvName}-auth.yml" #S3に配置した${EnvName}-auth.ymlからAuthの値を参照する Auth: - {AuthScheme: SECRETS, IAMAuth: DISABLED, SecretArn: 'arn:aws:secretsmanager:ap-northeast-1:XXXXXXXXXXXX:secret:sample-dbproxy-service01-XXXXX'} #service01 - {AuthScheme: SECRETS, IAMAuth: DISABLED, SecretArn: 'arn:aws:secretsmanager:ap-northeast-1:XXXXXXXXXXXX:secret:sample-dbproxy-service02-XXXXX'} #service02 - {AuthScheme: SECRETS, IAMAuth: DISABLED, SecretArn: 'arn:aws:secretsmanager:ap-northeast-1:XXXXXXXXXXXX:secret:sample-dbproxy-service03-XXXXX'} #service03 こうすることで、サイト追加・削除時にRDS Proxyのテンプレートを修正する必要が無くなりました。（※スタックの更新は必要） RDS Proxyに多数のSecretsArnを設定するケースは少ないかもしれませんが、一部の設定項目をテンプレート外で管理したいケースは多々あるかと思います。 そういった場合にとても便利な関数なので是非取り入れてみてください！ AWS::Include関数に関するAWS公式記事は こちら ③エンドポイント切り替え RDS Proxyの構築は完了しましたが、まだECS→RDS Proxy→データベース といった通信経路となっていません。 どのデータベースを参照するかは各サービスの設定ファイルに記載しているため、設定ファイルのデータベースエンドポイントをRDS Proxyのエンドポイントに書き変える必要があります。 今回は稼働中のすべてのサービスの設定ファイルに記載してあるエンドポイントの書き替えが必要なため、Ansibleを利用しました。 サービスのディレクトリ配下から設定ファイルを探し出し、エンドポイントを書き変えるplaybookを作成し実行することで、一度にエンドポイントが書き変えられダウンタイム無しでRDS Proxy経由の通信に切り替えることができました。 以上でRDS Proxyの導入は完了です！ さいごに 今回は導入のメリットに触れましたが、RDS Proxyには多少のレイテンシーが発生するなどデメリットも存在するため、メリット・デメリットやコストを比較した上で検討するのをお勧めします！ 導入後の効果についてもまたどこかでまとめたいなと思います。 投稿 既存システムへのAmazon RDS Proxy導入記 は マイナビエンジニアブログ に最初に表示されました。