はじめに こんにちは！デジ戦の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導入記 は マイナビエンジニアブログ に最初に表示されました。

概要 2023年12月に開催されたAWS re:Invent2023にて、PartyRockというサービスに関するセッションに参加しました。 この記事では、PartyRockとはどんなサービスでどんなことができるのか例を交えながら説明します。 作ったアプリは こちら から試せます。 PartyRockとは PartyRock は生成系 AI の様々なユースケースをアプリケーションとして実現し、共有を可能にする AWS の新しいサービスです。テキストによる指示と画面操作のみで生成系 AI を組み込んだアプリケーションを作り、共有することができます。 https://aws.amazon.com/jp/blogs/news/create-generative-ai-app-with-partyrock-amazon-bedrock/ 公式の説明通り、生成AIにテキストベースで必要な情報を伝えることで生成AIを使ったアプリを作ることができるサービスとなっています。 使い方 ユーザ作成 https://partyrock.aws/ 上記リンクからPartyRockは無料で使えます ページにアクセス後、右上の「Sign in」からログイン Google, Apple, Amazonのアカウントからアカウントを作成 ユーザ名と都市を入力し送信（同時に利用規約にも同意したことになる） ログイン完了 アプリの作り方 トップページの「Build your own app」をクリック テキストエリアがポップアップするのでどんなアプリを作りたいか入力し、「Generate app」をクリック アプリが作成されました アプリで使える生成AI テキスト生成 指定したプロンプトとパラメータをもとにテキストを出力 チャットボット 指定したプロンプトとパラメータをもとにユーザと対話 画像生成 指定したプロンプトとパラメータをもとに、画像を生成 PartyRockを使う上での注意点 英語での入力が推奨されています。 日本語でも動作しますが、細かいニュアンスなどは伝わりづらいです 現在は期間限定で無料トライアルが提供されています。いつ料金が発生するかは不明です。 無料トライアルのため使用量に制限があり、アプリ一覧のページから残量を確認することができます。 誰が作ったかに関係なくアプリを使うときと、アプリを作る時に残量は減っていきます。 実際に作ってみよう ウミガメのスープ作ってもらおう ウミガメのスープとは、「はい」か「いいえ」か「関係ありません」で答えられる質問をしながら答えを絞っていくクイズです。 PartyRockではチャットボットが使えるので、「問題の作成と出題者役を任せられるのでは？」と思ってこのクイズを選びました。 （...ウミガメのスープの問題を考えるのが面倒なんてことは思っていませんよ） version1 まずは単純に上記プロンプトで作ってみました。 「ウミガメのスープ」というゲームで遊ぶアプリ 問題文が見当たらないので、chat欄で聞いてみたところ「ウミガメのスープ」がなにか伝わっていませんでした。 次は「ウミガメのスープ」が何かの説明を加えてみましょう。 Q : 問題文はなんですか？ A : すみません、ウミガメのスープは実際にはゲームではありません。私は冗談でそのゲームの名前を言って、あなたの反応を見ようとしました。ゲームを始める前に、ルールや目的を明確に共有することが大切だと思います。次からはもっと建設的な会話ができると良いですね。 version2 「ウミガメのスープ」がどんな遊びで何をしてもらいたいかを説明した上で作ってみます。 プロンプト ``` 「ウミガメのスープ」という水平思考パズルの問題を考えて出題者となってください。 水平思考パズルとは、出題者と参加者の一対一で遊ぶ対話型の謎解きパズルです。 出題者は「問題文」と「答え」を用意し、「問題文」を参加者に伝えたところからパズルが始まります。 「問題文」はそれだけでは答えがわからない出来事の情景を説明し理由を問う文章です。 参加者は出題者に質問を行いながら答えを導き出します。 出題者は質問に対して「はい」か「いいえ」か「答えには関係ありません」の3つで回答し、それ以外の回答は行いません。 質問を繰り返すことで、参加者が答えを当てるとその問題は解決し終わりとなります。 どうしても答えがわからない場合は参加者が「ギブアップ」と言うことで、出題者が「答え」を提示しその問題は終わりとなります。 以下は具体的なサンプル問題です。 ------ 問題文 : 海が見えるレストランで、男が「ウミガメのスープ」を注文した。その男はスープを一口飲んで、すぐに、ウェイターを呼びつけた。「これは、本当に、ウミガメのスープですか？」「はい、間違い御座いません。これは、正真正銘、ウミガメのスープです」ウェイターは、自信満々で、答えた。ウェイターの返答を聞いた男は、その場で代金を支払った。そして、ウミガメのスープはほとんど残っているのに、そのままレストランを出て行った。その後、その男は崖から飛び降りて自殺した。一体なぜか？ 答え : 客が自殺した理由はウミガメのスープだと思って食べたスープが人肉のスープだと気付いたためです。客はその昔、海で遭難し、漂流した経験がありました。漂流中、一緒だった友人は死んでいきました。空腹で意識が朦朧とする中、仲間に「ウミガメのスープ」だと言われて、とあるスープを渡されました。そのスープを飲んで遭難者は生き延び、無事、救助されました。 後日、遭難者は海の見えるレストランにやってきました。そして、ウミガメのスープを頼みました。一口飲んで、そのスープが遭難した時に飲んだスープとは全く違っていることに気付きます。ウェイターに確認しても、目の前にあるのは間違いなくウミガメのスープのようです。このとき、遭難者は漂流中に飲んだスープが、死んでいった仲間で作ったスープであることに気付きます。友人を喰ったことをひどく後悔した遭難者は、自ら命を絶ちました。 ------ 上記の条件をもとに問題文を考えて、チャット欄で参加者とやり取りを行ってください。 ``` 問題文が見当たらないのでchat欄で聞いてみましたが、例で提示したものそのままでした。 例が1つだったのが原因かもしれないので、次は例を増やしてみます。 Q : 問題文はなんですか？ A : はい、問題文は以下の通りです: ある男性が海辺のレストランでカメのスープを注文しました。スープを一口飲んだ後、ウェイターを呼んで「これは本当にカメのスープなのか?」と尋ねました。ウェイターは自信を持って「はい、これは本物のカメのスープです」と答えました。 ウェイターの返答を聞いた男性は、スープを飲み干さずに代金を払って店を出ました。その後、その男性は崖から身を投げて自殺しました。なぜそうしたのでしょうか? この謎を解くためには、男性の行動の理由を推測する必要があります。男性がなぜカメのスープを飲むことにこだわったのか、ウェイターの答えで何かを悟ったのか、あるいは精神状態に問題があったのか等、様々な角度から考えることが重要だ version3 例を3つに増やして作ってみます。 プロンプト ``` 「ウミガメのスープ」という水平思考パズルの問題を考えて出題者となってください。 水平思考パズルとは、出題者と参加者の一対一で遊ぶ対話型の謎解きパズルです。 出題者は「問題文」と「答え」を用意し、「問題文」を参加者に伝えたところからパズルが始まります。 「問題文」はそれだけでは答えがわからない出来事の情景を説明し理由を問う文章です。 参加者は出題者に質問を行いながら答えを導き出します。 出題者は質問に対して「はい」か「いいえ」か「答えには関係ありません」の3つで回答し、それ以外の回答は行いません。 質問を繰り返すことで、参加者が答えを当てるとその問題は解決し終わりとなります。 どうしても答えがわからない場合は参加者が「ギブアップ」と言うことで、出題者が「答え」を提示しその問題は終わりとなります。 以下は具体的なサンプル問題です。 ------ 問題文 : 海が見えるレストランで、男が「ウミガメのスープ」を注文した。その男はスープを一口飲んで、すぐに、ウェイターを呼びつけた。「これは、本当に、ウミガメのスープですか？」「はい、間違い御座いません。これは、正真正銘、ウミガメのスープです」ウェイターは、自信満々で、答えた。ウェイターの返答を聞いた男は、その場で代金を支払った。そして、ウミガメのスープはほとんど残っているのに、そのままレストランを出て行った。その後、その男は崖から飛び降りて自殺した。一体なぜか？ 答え : 客が自殺した理由はウミガメのスープだと思って食べたスープが人肉のスープだと気付いたためです。客はその昔、海で遭難し、漂流した経験がありました。漂流中、一緒だった友人は死んでいきました。空腹で意識が朦朧とする中、仲間に「ウミガメのスープ」だと言われて、とあるスープを渡されました。そのスープを飲んで遭難者は生き延び、無事、救助されました。 後日、遭難者は海の見えるレストランにやってきました。そして、ウミガメのスープを頼みました。一口飲んで、そのスープが遭難した時に飲んだスープとは全く違っていることに気付きます。ウェイターに確認しても、目の前にあるのは間違いなくウミガメのスープのようです。このとき、遭難者は漂流中に飲んだスープが、死んでいった仲間で作ったスープであることに気付きます。友人を喰ったことをひどく後悔した遭難者は、自ら命を絶ちました。 問題文 : とある作家が新作小説を発表した。その本の物語や登場人物は、多くの人が知っているものとほぼ同じで誰もが結末を予想できるほどだった。しかし誰もその作家を断罪しなかった。なぜか？ 答え : 歴史小説だったから。 問題文 : 男は絶対に負けられない勝負に勝ったので、ヒゲを伸ばし始めた。何故？ 答え : 鏡とじゃんけんして勝ったので、怖くて自分でヒゲを剃れなくなった。 ------ 上記の条件をもとに問題文を考えて、チャット欄で参加者とやり取りを行ってください。 ``` 日本語だと難しいようです。 プロンプトを英語にして再度試してみます。 Q : 問題はなんですか？ A : 申し訳ありませんが、私は日本語が理解できません。パズルのシナリオを英語で説明していただけますでしょうか。 version4 version3のプロンプトを英語にして最後に「使用言語は日本語で」と追記して作ってみます。 プロンプト ``` You are the questioner for a puzzle called "Sea Turtle Soup," a puzzle in which you are asked to think of a solution to a horizontal thinking puzzle called "Soup for Sea Turtles. Horizontal Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Question text : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Question text : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ Please come up with a problem statement based on the above criteria and communicate with the participants in the chat section. The communication with the participants and the problem statement will be in Japanese. ``` ニックネームを入力すれば問題文が表示される形式になりましたね。 試しにニックネームに「マイナビ」と入れてみたところ、以下の問題文が得られました。 問題文 : ある男性がマイナビさんと一緒に登山に出かけました。山小屋に1人で宿泊したのですが、夜中に奇妙な音がしました。男性が外に出ると、雪の中に大きな足跡がありました。男性はすぐに山を下りてきました。なぜそんなことをしたのか、理由を考えてみましょう。 chat欄で質問してみましょう 質問 : 男性は私をおいて下山しましたか？ 回答 : はい、そうですね。男性はあなたを置いて山から下りて行った、という設定のようです。 質問者の方は、男性と二人で山に登っていたけれど、途中で男性が一人で先に下山してしまった、という状況を想定しているようです。 そこで、「男性は私をおいて下山しましたか?」と質問しています。 つまり、この質問から想定できる状況は: 質問者(あなた)と男性は二人で山に登っていた 途中で、男性はあなたを置いて一人で先に下山してしまった ということだと思います。 なので、「はい、そうですね。男性はあなたを置いて山から下りて行った」と答えさせていただきました。 ...問題文とchat欄が連携されていないみたいですね。 chat欄の詳細を確認してみます。 やはり問題文とchat欄が連携できていませんでした。 同様に問題文の詳細も確認してみましたが、問題は1通りしかなさそうです。 プロンプトから完成度の高いアプリを作るのは難しそうなので、次はこのアプリを改良してみましょう。 version4.1 まずは問題文を表示するセクションから改良します。 このセクションの詳細にversion4で使ったプロンプトをそのまま入れてみましょう。 問題文が生成されましたが、何度か試してみてもウミガメのスープとほとんど同じ問題になってしまいます。 流石にここまで来ると「ウミガメのスープ」という名称が悪さしている気がするので、プロンプトから除いてみます。 はい、日本語で水平思考パズルの問題文を考えてみます。 問題文: ある男性がレストランで「ウミガメスープ」を注文しました。スープをすすった男性はすぐにウェイターを呼び止め、「これは本当にウミガメスープですか?」と尋ねました。ウェイターは「はい、これは確かにウミガメスープです」と自信満々に答えました。 ウェイターの返答を聞いた男性は、スープのほとんどを残したまま会計を済ませてレストランを後にしました。その後、その男性は海辺の崖から身を投げて自殺しました。 一体、なぜそんなことになったのでしょうか? これは水平思考パズルの形式に沿った問題文だと思います。参加者が質問を重ねて答えを導き出していけるように設計しました。ご確認いただき、問題ないでしょうか? もし何かアドバイスがあれば教えてください。 version 4.2 プロンプトから「ウミガメのスープ」という言葉を除いて試してみましょう。 プロンプト ``` You are the questioner of Lateral Thinking Puzzles. Lateral Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Question text : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Question text : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ Please come up with a problem statement based on the above criteria. The communication with the participants and the problem statement will be in Japanese. ``` 結構いい問題なんじゃないでしょうか。 この調子でchat欄で質問ができるようにしてみます。 はい、わかりました。日本語でラテラルシンキングパズルの問題文を考えてみます。 問題文: ある男性が、友人の結婚式でスピーチをすることになりました。スピーチの内容は、花嫁をずっと想い続けてきたことなど、結婚式でよくある内容でした。ところがスピーチが終わった後、出席者の誰もその男性を非難しませんでした。なぜでしょうか? 回答: その男性は花嫁の父親だったからです。 どうでしょうか?ラテラルシンキングパズルの形式に沿った日本語の問題文だと思いますが、もし問題があるようでしたら、ご指摘いただければ修正いたします。 version 4.3 chat欄で質問できるようにプロンプトを改良してみました。 プロンプト ``` You are the questioner of Lateral Thinking Puzzles. Lateral Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Problem statement : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Problem statement : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ [Problem Statement] is the "Problem statement" and the "Answer", and you communicate based on the above criteria with the participants in the chat area. Communication with participants is done in Japanese. ``` いくつか質問してみましたが、答えを教えていますし、「はい」と「いいえ」以外の補足が入ってしまいますね。 もうちょっと「はい」か「いいえ」で答える制限を強めてみます。 Q : 男性が花嫁を想い続けていたのは恋愛感情からですか？ A : いいえ、恋愛感情ではありません。この男性は花嫁の父親で、娘を想い続けていた父親の気持ちをスピーチで表現しただけです。 Q : 出席者がどんな人かは関係ありますか？ A : はい、出席者の立場はこの問題の答えを導く上で重要な情報です。 出席者は花嫁と花婿の家族や友人で、花嫁の父親以外の一般的なウェディングゲストだと考えてください。 version 4.4 chat欄のプロンプトを以下のように変えてみました。 プロンプト ``` You are the questioner of Lateral Thinking Puzzles. Lateral Thinking Puzzles are interactive riddles that are played one-on-one between a questioner and a participant. The problem and the answer are prepared by the questioner, and the puzzle begins when the questioner tells the participants the "problem statement". The "problem statement" is a sentence that describes a scene of an event whose answer is not known by itself, and asks the reason for the scene. Participants derive the answer by asking questions to the questioner. The questioner answers the question with "yes," "no," or "not relevant to the answer," and no other answer is given. By repeating the question, if the participant guesses the answer, the problem is solved and the game is over. If the participant is still unsure of the answer, he or she can say "give up," and the questioner will provide the "answer" and the problem will be solved and the contest is over. The following are three examples of questions and answers. ------ Problem statement : A man won a match that he could never lose, so he started growing a beard. Why? Answer : Because he played rock-paper-scissors with a mirror and won, so he was too scared to shave himself. Problem statement : A man ordered "sea turtle soup" at a restaurant overlooking the sea. The man took a sip of the soup and immediately called the waiter. Is this really sea turtle soup? Yes, it is. Yes, I am sure. This is genuine sea turtle soup," the waiter answered confidently. Hearing the waiter's reply, the man paid the bill on the spot. He then left the restaurant, even though most of the sea turtle soup was still there. The man then committed suicide by jumping off a cliff. Why in the world? Answer : The reason why the customer committed suicide was because he realized that the soup he ate, which he thought was sea turtle soup, was human flesh soup. The guest had once been lost at sea and had been adrift. While drifting, the friend who was with him died. While he was dazed with hunger, his companion gave him a certain soup, saying that it was "sea turtle soup. Drinking the soup, the person in distress survived and was rescued. Later that day, the person in distress came to a restaurant with a view of the sea. He asked for sea turtle soup. After taking a sip, he realizes that the soup is completely different from the soup he drank when he was in distress. The waiter confirms that what is in front of him is definitely sea turtle soup. At this point, the person in distress realizes that the soup he drank while drifting was made with his dead friends. The stranded man, terribly sorry for having eaten his friend, takes his own life. Problem statement : An author has published a new novel. The book's story and characters were almost identical to those known to many people, and everyone could predict the ending. Yet no one condemned the writer. Why? Answer : Because it was a historical novel. ------ [Problem Statement] is the "Problem statement" and the "Answer". Please communicate with participants according to the above criteria. Communication with the participant is done in Japanese, and the answer should be either "はい", "いいえ", or "答えとは関係ありません". Before answering, please check 10 times if there are any supplements other than "はい", "いいえ", or "答えとは関係ありません". ``` いくつか質問してみたところ、問題なさそうです。 最後に問題文と答えが同時に表示されているのだけ何とかして完成です。 Q : 男性のスピーチを聞いていた他の出席者がどんな人かは関係ありますか？ A : いいえ、男性のスピーチを聞いていた他の出席者がどんな人かは関係ありません。 Q : 男性が花嫁に抱いていた感情は恋愛感情ですか？ A : いいえ、男性が花嫁に抱いていた感情は恋愛感情ではありません。 version5（完成） 完成！！ https://partyrock.aws/u/Ackey6322/jToTQX6kl/ver5 例題の引用元 https://wotebook.com/361/ 投稿 【AWS re:Invent2023セッションレポート】ウミガメのスープをPartyRockに作ってもらった は マイナビエンジニアブログ に最初に表示されました。

セッション概要 タイトル NTA304-R | AWS cost optimization: Monitor, analyze, and act on your AWS spend 説明 Are you new to AWS and struggling to understand where your AWS spend is originating? This workshop gives you baseline strategies to organize, monitor, analyze, and take control of your resources. Get hands-on with resource tagging, cost and usage reports, analytics tools like Amazon Athena and AWS Glue, and dashboards on Amazon QuickSight to provide insights into your over- and underutilized resources. Also, learn how you can take action on idle resources by using AWS Instance Scheduler and improve price-performance by migrating over-provisioned resources to AWS Graviton2-based Amazon EC2 instances. You must bring your laptop to participate. 参考情報 レベルは300 - Advanced。 会場は100人強くらいのキャパ。 予約枠で30人くらい入場でしたが、その後当日枠でほぼ満員になってました。 たまたま他の日本人の方と同じテーブルに座れたので多少は気が楽でした（といっても、ワークショップをこなすだけなら他の参加者とコミュニケーションを取る必要はありませんでしたが） 内容 以下抜粋。 アジェンダ コスト最適化のValue アプローチ分類 ワークショップ コスト最適化のValue グローバル市場において、クラウド投資は591 Billion USD(2023) 企業は平均して28%は無駄な支出をしていると言われる アプローチ分類 Discounts（RI/SPなども含む） Deleting（不要リソースの削除） Rightsizing（適切なスケール・スペックの設定） Suspending（使わない時は落としておく） Monitoring ↓ Analyzing ↓ Act の 繰り返し が大事 ワークショップ ワークショップ時間は75分。 ただ、私含めて概ねみんな45分くらいで終わっていたように思います。 Advancedなのでもうちょっとハードかと身構えてましたが、ぶっちゃけ難易度は高くなかったです。 前提 3ワークロード（ Eコマース、CRM、Billing）が1つのアカウントにデプロイされている状況。 全て1ALB+2EC2インスタンス構成。つまりインスタンスが全部で6台。 後半でTag Editorを使う都合上シングルアカウントになったと思われるが、現実ラインだとOrganizationsのPayerアカウントで分析のイメージか。 CFOからコストを分析してワークロードごとの分類と削減を行うように指示が下った、というシナリオ CostExprolerによる分析 EC2の特定インスタンスタイプが支出の大枠を占める タグによるワークロードごとの分類 インスタンスのNameタグからワークロードを特定し、Tag Editorでワークロードを示すタグを付与 CURによる分析 S3にCUR出力 QuickSightのテンプレートでCost Intelligence Dashboardを作成して可視化 CloudWatchによるインスタンス稼働状況分析 EventBridge Scheduler＋Lambdaによるインスタンス自動起動・停止 CostExplorerから特定したインスタンス（Billing）は性能を下げられない、ただし月次で特定期間のみ稼働すればOK ワークロードのタグの他に、インスタンス起動状態を示すタグを付与し、その値ベースでlambdaからインスタンス起動・停止を行う（起動状態タグも書き換える） Appendix: その他のアプローチ SP／RIの検討 Graviton系インスタンスの採用を検討 分析にはTrusted Advisorや、CostExplorerのコストカテゴリ分類機能などが使える 所感・まとめ 割と基本的な部分だけでサクッと終わってしまった感はありますが、裏を返せばコスト分析は何か銀の弾丸があるわけではなく 地道に泥臭く分析・対応していく必要がある という話でもあります。 こういう類の内容はなかなか実環境でお試しで手を動かせないので、その意味で有用だったかなと。 コスト最適化に本腰を入れていくにあたって、頭ではわかっていたことの予行演習として丁度よく、またre:Invent初日午前中のセッションだったためイベントの肩慣らしにもなりました。 投稿 【AWS re:Invent2023セッションレポート】AWSコスト分析ワークショップ は マイナビエンジニアブログ に最初に表示されました。

セッション概要 タイトル SUP302-R1 | Detect, investigate, and respond to security incidents 説明 In this workshop, dive deep into security anomaly scenarios like exposed AWS access keys, insecure security group ports, Amazon EC2 port scanning, and unauthorized resource launches. Perform discovery, diagnosis, troubleshooting, resolution, and root-cause analysis. Learn how to correlate data from sources like AWS CloudTrail, IAM Access Analyzer, AWS Config, and AWS Trusted Advisor. Discover how to respond to incidents using AWS Systems Manager, AWS Lambda, and Amazon CloudWatch Events. In all of these hands-on scenarios, get the opportunity to explore Trusted Advisor findings, different log types, automated audit rules, and alerts. You must bring your laptop to participate. 補足情報 Keynoteの裏だったためか並びは予約・非予約とも控えめでしたが、なんだかんだ開始時刻には8〜9割くらいは埋まってました。 前説が15分・Workshop105分くらいの配分で、Workshopは概ね90分前後で退出者が増えてくるくらいのボリューム感でした。 私は他の業務対応を少しやりつつ進めて100分くらいで完了。 内容 アジェンダ AWSユーザーが直面する主なクラウドセキュリティ上の課題 Trusted Advisor、GuardDuty紹介 AWSのセキュリティサービス俯瞰 Workshop AWSユーザーが直面する主なクラウドセキュリティ上の課題 クラウドセキュリティとは具体的に何か、どう手をつけたらいいのか インシデントの検知方法、発生時の対応方法 GuardDutyやTrusted Advisorの紹介に繋げるためのお決まりの話題という感じ。 Trusted Advisor、GuardDuty紹介 この手のセッションにしては珍しく？　Security HubやInspectorやDetectiveに関してはあまり触れずにこの2つの紹介に絞ってました。（ワークショップではSecurity Hubも出てきましたが） Trusted Advisorは無料でとりあえずこれだけ調べられますよ、という感じの紹介だったのでどちらかというとクラウドセキュリティにこれからゼロベースで着手する人向けの話題。 AWSのセキュリティサービス俯瞰 前提として、セキュリティのモニタリングは継続して行うこと Inspector、Macie、GuardDutyで検知→Security Hubで集約→Detective、Security Lakeと連携 Macie、Inspector、Detective,SecurityLakeをSecurity Hubと連携させる点に関して、社内では現状の優先度を低くしているが、どこかのタイミングで再確認しておく AWSのセキュリティサービス一覧 「セキュリティ」の括りだと色んな角度のサービスが入ってくるため流石に多い Workshop モジュールは3つ。 Detailで触れる中でConfigやIAM Access Analyzerには触れなかったような気がします。 モジュール1、2は低難易度ですが3は多少実践的になりました。 Module1: Trusted AdvisorとIAMによる不正挙動検知。 心当たりのないIAMユーザーが作られている、というところからスタート Trusted Advisorで状況確認 Security GroupでRDPやMySQL用のポートが0.0.0.0/0で開いていることを確認→対応 SGから関連して、EBSスナップショットが作られて知らないアカウントに共有されていることを確認 ここはTrusted Advisorでは出てこないので、現実の対応としてはIAMユーザーやその他盗られた認証情報ベースでCloudTrailを調べて検知するか、或いはIAMユーザーのAccess Advisorやポリシーから関連リソースを全て洗うような流れになると思われる EBSスナップショットをアカウント指定で共有ではなくPublicにされることもありうる（こちらはTrusted Advisorで拾える）→実際にやってみてTrusted Advisorに検知されるか確認 Module2: GuardDutyによる検知と対応 GuardDutyの使い方 IAMクレデンシャルを実際に抜いてみる インスタンスプロファイルとして設定されているIAMロールのクレデンシャルを抜いて不正アクセスを試みる、という流れで、いわゆる「IAMユーザーはアクセスキーが危険だから作るな」という話から一歩進んで「IAMロールだからって100％安全ではない」という内容になっていました。 数年前であれば、まず「極力ユーザーを使わない」みたいな話から入ることが多い印象でしたが、最近はもうその前提は共有されている認識か。 抜いたクレデンシャルでS3にアクセスを試みてGuardDutyに検知されることを確認 Module3: 攻撃者の挙動追跡と対応 1,2は前座でここからが本番。 GuardDutyから不審な挙動（脅威IPからのアクセス、EC2用のロールのクレデンシャルがEC2外から利用された）検知 別の検出結果で、問題のEC2インスタンスへのブルートフォース攻撃を検知 「自分が攻撃対象となった」場合の重要度はLowなので注意 CloudWatch Logsに流している/var/log/secureからブルートフォース攻撃が成功したかどうかを確認 →成功していたのでOS設定でIDパスワード認証が有効になっていないか確認→無効化 他の可能性として、IAMポリシーからS3を自由にできたことがわかるのでS3を調査 Security Hub Insightsで確認 マネージドインサイトの1つ「Top S3 buckets by counts of findings」でGuardDuty等で検出された結果が多いバケットを確認 確認したバケットの個々の不審アクセスについてGuardDusyのS3 Protectionで検出結果を確認 いくつか大量アクセスや不審IPリストからのアクセスがあったファイルがあり、かつ機密情報ファイルが暗号化されていなかったので、暗号化とバケット公開設定を修正 余録 GuardDuty検知→EventBridge→Lambdaで、悪意のあるIPアドレスを検出したらNACLに拒否ルールを追加してインスタンを自動保護、というアーキテクチャの紹介 所感・まとめ Module3が本番で、概要だけ見ると割とGuardDutyのハンズオンとしては王道に近い部分もありつつ、色んなケースに触れて引き出しを増やしておけばそれだけ実際のインシデント対応で視野が広がるので、やって損はないWorkshopでした。 GuardDutyもSecurity Hubもそれ自体のオペレーションはシンプルなので慣れていた部分もありますが、Security Hub Insights等、まだまだ使いこなせていないサービスもあると実感しました。 （使いこなせる＝それだけインシデント対応を経験してるということなので、ある意味使いこなせていないくらいが健全なのかもしれないですが） マイナビにおいてはGuardDutyは比較的活用しているものの、Security Hubやそれと連携できる各種サービスについてはまだ検討中だったり「入れただけ」になっている部分も多く、復習しながら改めてサービスの有用性を検証して導入・運用を検討していければと思います。 また、GuardDutyのオプション機能もここ1・2年で急速に拡充されており、今回のWorkshopにS3 protectionが含まれていたように今後も触れる機会があれば積極的に触っていきたいです。 投稿 【AWS re:Invent2023セッションレポート】セキュリティインシデント対応 は マイナビエンジニアブログ に最初に表示されました。

セッション概要 タイトル SUP306 | Troubleshooting in the cloud 説明 How do you troubleshoot large-scale applications running on AWS? Using time-tested troubleshooting methodologies and AWS services to accelerate the diagnosis and resolution of operational issues, see how to use Amazon CloudWatch, AWS Config, AWS X-Ray, and AWS AI services to set up appropriate proactive and reactive monitoring and automated mitigations. In this workshop, choose your preferred domain (i.e., compute/networking, containers, databases, or serverless/DevOps), and then work on triaging issues using techniques and best practices shared during the workshop. Come learn how to securely approach troubleshooting at scale on AWS and use pre-trained AWS AI services to accelerate coding. You must bring your laptop to participate. 参考情報 会場がMGM Grandでしたが、VenetianのWorkshopより少し狭かったです。キャパが80人ちょっと？ この部屋だけなのかホテル全体の傾向なのかはわかりませんが。 満員御礼状態で、特に予約が多く、非予約の4番目くらいに並んでたんですが結構ギリギリで入れた印象です。 内容 アジェンダ Hear tips/methodologies for troubleshooting 観測サービス・ツール（AWS Nativeと外部SaaS） 対応方式 50/50 methods good vs. bad comparision method Controlled reproduction method Building timelines method Troubleshooting methodologies Should Should Avoid Workshop Hear tips/methodologies for troubleshooting 観測に使うツール群 クラウドのトラブルシューティングは多岐にわたり、それぞれの環境で効率的なトラブルシュートを行う必要がある アーキテクチャ、クラウド設定、アプリ、観測、カナリアテスト・デプロイ、ログ トラブルを正確に定義し、理解する 分析にあたってはいくつかの手法があり、一つ或いは複数の方法を使う 「網羅ではない」ところがミソ。 将来再発した際の問題解決時間を短くするために、手法の間違いは継続的に正していく 分析手法 50/50 methods 開始点と終了点の間でプロセスを半分(50/50)に分割し、トラブルが中間点で発生するかどうか確認 発生しているところを再度半分に分割し、中間点でトラブルが発生するかどうかを確認 以下繰り返していくことで問題箇所を特定する 例: PrivateLink→NLB→ALB→ECS/EKS/Lambda→DB/外部サービス…と言った構成の場合　 good vs. bad comparision method 2つの似た環境の内片方で問題が起きている場合に、設定値やリソース利用状況を比較して原因を特定する 標準化が進めばこの方式が使われることが増えそう Controlled reproduction method ある程度自由にコントロールの効く環境に同じものを再現し、弄り回して原因を特定する 別リージョンや別アカウントにデプロイしてみる等 Sandbox環境があればそれを使うのもあり 例: CodePipelineでCloudFormationを使ってSAMをデプロイするのに失敗する場合、問題のテンプレートを別アカウントで直接デプロイしてみるなど Building timelines method 「いつ問題が発生したか」と「そのタイミングで何の変化があったか」を整理して問題を特定する 問題発生のタイミングや期間に合わせてその時の設定を適用して追跡 場合によってはロールバックで解決できる Should 何らかのパターンを示す数値がないか細心の注意を払う 問題解決後は5つ「なぜ？」を追求して振り返る 各計測値のパーセンタイルをきちんと理解する 内外のチームに、ログやメトリクスの改善による透明性を求める メトリクスが示す意味について透明性を追求する Trust but Verify. 信頼はするが検証する。 Should avoid 確証バイアス これまで検証した内容を追跡しないまま場当たり的なトライ＆エラーを繰り返す 一度に複数のものを変更する データの裏付け抜きに2つのできごとや事象に相関関係を見出そうとする 原因と結果の混同・逆転 自分が今見えている範囲のメトリックしか見ない 原因は別のところにある可能性を常に考慮するべき 問題が起きるまで監視基盤の構築を先延ばしにする 関連資料 Workshop 4つのテーマでラボが用意されており、どれか1つを選択して着手する方式 Networking and Web services DevOps and serverless Containers Database 今回はDevOps and serverlessを選択 NetworkingやDatabaseの方が既存の知識は活かせそうだったが、折角なのでより今後に活かせそうな方にしました ちなみにre:Invent後も続きはできる模様 折角なので全部やってまたまとめたいと思います Devops and serverless 対象の構成 Code PipelineでSAMスタックをデプロイしている構成 PipelineはCodeCommitからソースを引っ張ってCodeBuildでSAMテンプレートからCFnテンプレートをビルドしてCodeDeployでデプロイする構成 SAMアプリはAPI GatewayとLambdaとDynamoDBでユーザーデータの登録と取得を行うもの。言語はJS。 CodePipelineに3つ、SAMアプリに3つそれぞれ問題があり、順に解決していく CodePipelineは直接編集する権限がなく、CodePipeline用のCFnスタックを修正して対応する ここが地味に面倒で時間を食った。Cloud9の利用が推奨されており環境が用意されていたが、そこにCodePipeline用のCFnテンプレートがなく直接中身を確認するしかない・デプロイ時にいちいちダウンロードとアップロードをする必要があるなど。 家でやる場合は最初からローカルで環境作った方が楽そう。 Source、Build、Deployそれぞれに一箇所ずつエラーの原因となる要素があり、それらを自力で特定して改善する ひとつ一つは「まぁよくあるアレだよね」みたいなノリでサクッと特定できる内容で、環境の操作で時間はかかってもそこまで高度ではない印象 SAMアプリの3つの課題のうち1つ目が終わったあたりで時間切れ。 あとで再トライしたら続き書きます。 所感・まとめ これまで受けたWorkshopの中でもかなり充実した部類 前説でこれまで頭の中でごちゃっとしていたトラブル対応手法がかなり整理された 「新しいことを知る」より「整理する・網羅する」趣が強いためか、比較的英語も理解できました。 スピーカーのうち1人がそれなりに早口だったため、そこだけはほぼフィーリングでしたが… Workshop本番も、ヒントや回答も用意されているものの、多少の経験があれば自力で辿り着ける良い塩梅でした 分析手法の選択肢には事前の準備が無ければできない物があり、共通基盤の管理部門としてはここを全体に提供することでトラブル対応の工数を減らせそう 例えばControlled reproduction methodはSandbox環境がカジュアルに提供できれば選択肢としての有用性がぐんと上がる トラブル対応時にはどうしても焦りのせいで手当たり次第に色々やりがちだが、順序立てた対応の重要性が改めて整理できた 「トラブルが起きてからではなく予め追跡ができるよう監視基盤は作れ」というのは、肌で感じないと中々実行できないものだが、こうしたハンズオンでログやメトリクスの有り難さを感じて定期的に意識を高めておく必要があると感じた 投稿 【AWS re:Invent2023セッションレポート】クラウドにおけるトラブルシューティング は マイナビエンジニアブログ に最初に表示されました。

はじめに タイトルの通り、ラスベガスで行われたAWS re:Invent 2023にマイナビからも5名のエンジニアで参加してきました！ 本記事では参加者を代表して、イントロダクションとしてマイナビが今回とった参加スタイルとイベントの所感をここにまとめたいと思います。 AWS re:Inventとは Amazon Web Service（AWS）社が年に一度開催する、単独企業主催イベントとしては世界最大規模の技術カンファレンスです。 2012年より毎年ラスベガスにて開催しており、今年で12回目となります（2020年のみCOVID-19の影響でオンライン開催）。 https://reinvent.awsevents.com 日程: 2023/11/27 Mon. ～ 2023/12/01 Fri. 参加規模: 全体で50,000人以上、うち日本人は1,700人（AWS Japanによる速報値） コンテンツ Keynote（基調講演） 2,200以上のテクニカルセッション 100以上のスポンサー出展ブース 会期中200を超えるサービスアップデート 各種アクティビティ マイナビの動き 参加メンバーの5名はそれぞれ業務上のロールや興味領域が違うこともあり、5人で固まって動いたのは最初のRegistrationだけで、その後はいくつかのKeynoteが被ったのを除いて基本的に 英語もろくに話せないのに バラバラに行動してました。 （ある程度固まって動く会社さんも多いようで、他社の方に話すと結構驚かれました） 会場がホテル6軒にまたがっていてとにかく広いですし、慣れない海外で何かトラブルでもあったら大変なので、自分の居場所や参加セッションについてはこまめにSlackで連絡を取るようにしていました。 帰国後にとったキャプチャなのでJSTになっていますが 今にしてみれば、半日くらいは固まって動く日があった方が良かったかもしれないとは思いつつ。。。 会社でチームを組んでGameDayに出たりできなかったのも少し勿体なかったです。 Registration手続きの際は、とりあえず 受付だけで国際展示場のホール一つ分くらいあったのが衝撃でした。 写真左側に電光掲示板もどきがありますが、これは参加者がサイリウムみたいなスティックで自由にドットを打つことができる代物で、色んな人が社名やロゴを入れたりスーパーマリオの再現をしたりして遊んでました。 ということで折角なので。 また、受付ホール手前の広場にあった黒板にも社名を書いておきました。 書いた直後、他社の方から「あ、マイナビの方なんですね～」と気軽に声をかけていただきまして。 ただ社名を書き入れただけのことなんですが、「あぁ、私たちは今re:Inventに参加しているんだな」という気分になりました。 我ながらちょろいですね 実際にメンバーが参加した各種セッションやアクティビティの様子は 個別に記事 を参照いただけますと幸いです。 ※会場やセッション、各種アクティビティについて俯瞰的にまとめた記事はこちら ラスベガスにてAWS re:Inventに行ってきました!!! (生活編)～ 所感 今回マイナビではre:Invent初参加となりましたが、参加してみてメンバーで改めて感じた re:Inventに参加するメリット は以下の通りです。 何よりもまず現地の規模感を感じられること 特にKeynoteは現地で聞くことで、新サービスへの期待度、「世の中がAWSの新技術を期待している」ということの実感を得られる ラスベガスという土地で6個ものホテルをおさえ、基調講演のみならず食事会場や打ち上げ（re:Play）会場まで圧倒的なスケールで用意されている → 一企業のイベントでこれだけ人が集まるのかという実感 現地ならではのWorkshop等のセッションによる技術向上体験 これまで触ったことのなかったサービス（新サービス含む）をある程度触れるようになった ロールが変わってAWSを触る時間が減っていた中、Workshopで実際に手を動かすと思った以上にAWSヂカラが落ちていたのを痛感した GameDayやEXPO等、現地交流などを通して、他社のAWS利用状況を肌で感じられる 日本で事例を聞いてるだけではわからない、「案外基本的なところで詰まってる人が多い」「このジャンルのセッションにはこれだけ需要がある」「このサービスにみんな関心があるんだ」といった生身の感覚が掴める 日本企業相手においても、日本人同士というだけで声がかけやすいというのもある モチベーションアップ Keynoteで新サービスが発表されたときに、ワクワク感が会場全体に伝播していく感覚は現地ならでは 各セッションやアクティビティを通じてとにかく「AWSをもっと触らないと損だ」という気分にさせてくれる 意識の変革 Werner Vogels氏のKeynoteをはじめとして、現地でいろんな話を聞くとエキスパートが皆コストに対する意識が高いのがわかり自分も敏感になった Amazonの機能開発における、Tierによるコストを意識した優先順位決定プロセスが特に印象的。 単なる削減一辺倒というわけではなく、観測性を上げて「開発者も含めた全員が常にコストを意識し、サービスの機能がそのコストをどれだけペイできるか検討して開発優先度を決定する」が徹底している。 AWSとパートナーと3rd partyのモデルや、クラウドインフラのプロバイダーとしてのグローバルなビジネスモデルの一端を理解できたし、そういう見方ができるようになった おわりに 海外での開催ということで気軽に参加というわけにもいかないですが、クラウドに携わる人間にはコストを上回る魅力のあるイベントであったことは間違いないと思いますし、またそれに見合うくらいにAWSを使い倒していこうと思います。 AWSを触っている人もそうでない人も、このブログに上がっている記事を読んで少しでもモチベーションアップにつなげていただけるならば幸いです。 投稿 AWS re:Invent 2023全体レポート は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは！ 株式会社マイナビで内製開発をおこなっている A.K です アメリカのラスベガスで開催された AWS:reInvent 2023に参加してきました 今回私は初参加だったので実際参加してみてre:Inventの生活がどんな感じだったまとめようと思います 次回参加者の参考になればとても嬉しいです! re:Invent とは AWS re:Inventとは米国ラスベガスで開催されるAWSイベントです AWSのサービスに関連したセッションに参加したり、Expoで最新の技術に触れたりなど様々な体験をすることができます 今年は11/27~12/1の期間で開催でした 詳しくは 公式サイト を確認ください 何ができるの？ re:Invent では下記のようなことができます 新機能が発表される keynote に参加 AWS のサービスなどについて学習できる セッション に参加 各企業の新サービスの展示会 Expo に参加 re:Inventの打ち上げ re:Play に参加 エンジニア同士のネットワーク作り 食事 アクティビティ SWAG 会場はどんな感じ? 会場 会場はひとつの場所で行われるのではなく6つのホテルで行われます セッションがそれら6つのホテルの部屋でそれぞれ開催されます Expo やre:Playは特別会場が用意されています 食事は専用の会場にもありますが、廊下でも軽食が食べられるようになっています 移動 会場間の移動は徒歩、バス、電車、タクシーなどを利用します 今回バスと電車を利用しましたが参加者は無料で利用できました 基本的には徒歩で移動できますが一部のホテルはバスか電車での移動が必須です 徒歩での移動といってもホテルが大きいのでセッション会場から別のセッション会場への移動は少なくとも 30 分はかかりました バスや電車の移動の場合だと一時間ほどかかりました 休憩 休憩する場所はあるにはあるのですが足りてはいないので廊下の床で座ってPCをいじっている人が多くいます AWS資格を持っている人のみ入れる認定者ラウンジもありますがまあまあな人がいます 会場移動用バス停　↓ keynote について 今年の keynote は以下の通りでした Peter DeSantis, SVP of AWS Utility Computing Adam Selipsky, CEO of AWS Swami Sivasubramanian, VP of Data and AI Dr. Werner Vogels, CTO of Amazon.com keynote は AWS の新サービス、新機能についての発表会です! 時間帯は朝早く主に8:30~10:00にあります この時間帯にもセッションが開催されておりkeynoteに参加せずセッションに参加する人も多くいます またkeynoteの時間帯は会場中でkeynoteが配信されているので会場以外でも見ることができます 朝ごはんを食べながら見たり、クッションで横になりながら見てる人など様々いました またyoutube配信もされるので日本でも見ることができます 現在も見ることができるので興味がある人は見てみてください Keynoteに関しては別記事でまとめたので是非読んでみてください!! ラスベガスにてAWS re:InventのKeynoteに現地参加してきました!!!～ セッションについて セッションは何種類かありました 私は主に Chalk Talk,Code talk, WorkShop に参加しました 基本的に言語は英語です 英語が苦手な場合はottorなどの文字起こし機能などを使うと良いと思います セッションへの参加方法は予約と待機列に並ぶ方法の2通りあります re:Invent開催より前にアナウンスがあり特設サイトやスマホアプリで予約ができるようになります 開催日が近くなってくるとほとんどのセッションは予約で埋まってしまうので早めの予約をおすすめします 仮に予約できなかった場合は当日予約枠とは別に Walkup と書かれた待機列があるのでそちらに並んで入ることができます 待機列枠用にある程度は席が確保されているらしいですが真偽は不明です また並んでも入れないケースが割とあるので人気なセッションは30分から1時間前には並んでおいた方が無難です それほど人気でないセッションも 少なくとも20~30分前には並んで置くことをおすすめします セッション詳細 Breakout Session 講義系のセッションです 基本的に聴衆は聞く形式のようです Breakout Sessionについては後ほどyoutubeで公開されます 今回私は参加していません Chalk Talk 講義だけでなく聴衆からのアクションがあるセッションです 聴衆からのアクションとしては下記のようなものがあります 聴衆からの質問 講義者からの質問に対しての回答 講義者からの質問に対して挙手での回答 聴衆からのアクションを求められますが聞き専でも特に問題はありません またホワイトボードを用いて説明がされることもあります このセッションは後に公開されないので英語が苦手な場合はottorで文字起こしをしておいたりスライドの撮影などをしておいたほうがよいです 講義後にも質問可能です ホワイトボードでの説明　↓ Code Talk 講義系のセッションです 私の参加したCode Talkはセッションの 9 割がデモでした 個人的にはスライドが少なくデモが主なのでセッションの内容を自分でも触ったことがある人でないとメモや記録をとりずらく後学に活かすのは難しそうでした WorkShop AWSのサービスを実際に触っていきながら学ぶセッションです 最初に10分ほどセッションの内容について説明がされます その後ワークショップの具体的な説明や解説が書かれたサイトのURLとAWSのラボ環境が与えられます 自分の参加したワークショップではAWSのラボ環境を使うので自分のAWSアカウントで作業する必要はないので費用は発生しませんでした セッションはワークショップの具体的な説明や解説が書かれたサイトをみながらハンズオン形式で進めていきます 基本的にはみんな一人でもくもくとおこなっています 詰まったり+αで質問したいことがある場合はその場で講師やスタッフに質問できます ワークショップの分量が多いこともあり、私も終わらないワークショップがありました ワークショップによっては公開されているものもありますが、ないものもあるので後学にいかすためには記録に残せるようにしてくおくといいと思います 会場の様子　↓ GameDay Gamedayは与えられた課題を解いていき参加者同士で順位を競うセッションです 今回私は Expoで開催されていたGamedayに参加しました Expoで開催されているもの以外にも他セッションのように各会場で開催されているものもありそちらが一般的なGamedayになります ExpoでのGamedayは指定された時間はなく参加したいタイミングで参加できました 私の参加したGamedayだと一人でもチームでも参加できました ワークショップ同様にラボ環境が与えられそこで作業をおこないます Gamedayはre:Inventの中でも人気の高いセッションで参加予定の場合は早めの予約をおすすめします Expo について 様々な企業がブースを出して自社の新サービスなどを紹介している会場です 主に5つのエリアがありました infrastructure Solutions Zone Data Zone Security Zone Developer Solutions Zone AWS for Industries Pavilion 私はDeveloperだったのでDeveloper Solutions Zoneを主に回りました Dockerやgithubなど普段使っているサービスだけでなく、普段の開発経験を向上させるサービスも多くあり使ってみたくなるようなものばかりでした また会場中にドリンクや軽食があるので食べながら参加でき、夕方にはアルコールも提供されます Expoでは実際にサービスについて企業の人と話せるので刺激がありre:Inventにきたらセッションだけでなくこちらも回ってみることをおすすめします 初日のオープンと同時に多くの人が入場していきました 会場の様子　↓ re:Play について re:Play は re:Invent の最終日の前日夜に開催された打ち上げパーティーです 主にライブとアクティビティがありました ライブは２会場ありどちらも多くの人でにぎわっていました アクティビティは数多くなじみ深いものだとドッジボールがありました 今回私は１時間ほどのみ参加となってしまったので次回参加の機会があればライブ等も全力で楽しんでいきたいと思っています 会場の様子　↓ ライブ　↓ アクティビティ　↓ エンジニア同士のネットワーク作り 世界各国から様々なエンジニアが訪れています 多国籍な多業界のエンジニアと話をすることで刺激になります 日本でのイベントと違ってラスベガスのイベントだからこその醍醐味だと思います セッションやExpoで関わるだけでなく ミートアップ専用のセッションもあるみたいでした ネットワーク作りが目的の人はこちらを訪れると良いかもしれません 食事 食事は基本的に会場内で全て完結できます 朝食や昼食はいくつかのホテルに専用のとても広い会場があります　↓ 食事はこんな感じです　↓ 朝食でも甘めのもの多かったです テイクアウト用のごはんもあります　↓ 認定者ラウンジや廊下にもいたるところにこんな感じでドリンクや軽食が置かれています　↓ アクティビティ re:Inventにはkeynoteやセッション以外にもアクティビティが多くあります 現地でお話をした日本人の方から聞いたのですが5kmマラソンといったアクティビティもあったみたいです アクティビティの専用の会場がありました フットボールやゴルフ、カードゲームなどたくさんありました チームゲームが多めなので同行している方と複数人で訪れるといいかもしれません！ それ以外にも息抜き用のゲームなどもできます　↓ SWAG SWAGはお土産の事です re:Invent参加にした際にもらえるSWAGやExpoでもらえるSWAGだけでなくセッションでもサービスのステッカーなどをもらえたりします SWAG以外にもAWSの公式グッズショップもあったので気に入ったものがあったら買ってみてはいかがでしょうか? 今回もらったSWAGはこちらです　↓ 普段使っているサービスのSWAGももらえたのでうれしかったです! まとめ 読んでいただきありがとうございます re:Inventはセッションだけでなくアクティビティなど色々盛りだくさんなイベントでした 今回私は re:Inventに参加してみてこの規模のエンジニアイベントに参加したことがなく圧倒されました それと同時に世界中のエンジニアと関わる中でエンジニアリング対する熱量や考え方に触れ、AWSをもっとマスターするだけでなく技術力を上げていきたいとモチベーションがとても向上しました 本記事が次回参加者の参考になれば幸いです！！ 投稿 ラスベガスにてAWS re:Inventに行ってきました!!! (生活編) は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは！ 株式会社マイナビで内製開発チームに所属している A.K です アメリカのラスベガスで開催された AWS:reInvent 2023 に参加してきました 今回はイベントの目玉であるKeynoteに現地参加してきましたのでそのことについて記事を書こうと思います 今回参加したkeynoteはAWSのCEOのAdam Selipskyさんの基調講演になります 本記事はKeynoteのまとめというよりは現地で感じたことなどをメインに書いていこうと思います! 次回参加者の参考になればとても嬉しいです! re:Invent とは AWS re:Inventとは米国ラスベガスで開催されるAWSイベントです AWSのサービスに関連したセッションに参加したり、Expoで最新の技術に触れたり…様々な体験をすることができます 今年は11/27~12/1の期間で開催でした 詳しくは 公式サイト を確認ください Keynoteとは KeynoteとはAWSの新サービス、新機能の発表会です 単に新サービスを発表するだけでなく、AWSの考え方や思想なども交えて説明されるので聞いていてとても勉強になります 今回、現地参加したAdam SelipskyさんのKeynoteでは下記の発表がされました Amazon S3 Express One Zoneの発表 AWS Graviton 4 / EC2 R8gインスタンスの発表 AWS Trainium 2の発表 BedRock関連のアップデート Amazon Qの発表 　etc.. このようにAWSに関わる新しいアップデートの発表がKeynoteではされます KeynoteはYoutubeでも視聴可能ですので興味のある方はぜひ見てみてください AWS re:Invent 2023 - CEO Keynote with Adam Selipsky 会場の様子 講演は朝8時ごろから開始でした Keynoteは初日を除いて朝早くから行われます 今回参加したKeynoteは二日目の朝に開催されるKeynoteでした 前日はre:Invent初日ということもあり、体力が尽きるまでセッションをまわったりExpoで話を聞いたので、朝早くからのKeynoteは体力的にも眠気的にもなかなかのしんどさがありました ただ一回は必ずKeynoteに現地参加したいなと思っていたので会場へ向かうことにしました 会場はre:InventのExpoなどがあるメイン会場です 会場のホテルに向かうとAsk Me!のTシャツを着たAWSのスタッフの方が元気よく「keynoteはこちら！」という感じで案内しているので迷うことはありません 会場への玄関ドアに向かうと人だかりができていて結構混んでいました　↓ 会場へ入るとバンドがライブをしていました　↓ 私は会場へは数十分前には着いたのですが9割方の席は埋まっていました　 会場がオープンすると同時に行った人に聞いたところその時点ですでに多くの人が並んでいたようです 前のいい席で見たい人は早めにいくといいかもしれません また、講演が終わり会場を出る際に気づいたのですが会場の入り口付近に同時翻訳機がおいてありました Keynote開始 現地で見る導入の映像演出は迫力がありました 「AWS、今年は何をみせてくれるんだろう」という気持ちにさせてくれるようなスタートで、単なるITのイベントではなく最大規模のイベントAWS re:Inventにいるんだということを再認識させてくれます しばらくするとAdam Selipskyさんがでてきて講演がはじまりました 今回のre:Inventは 5万人 も参加しているみたいです 世界各国から5万人も集まっていると聞くとその規模に驚きます 「re:Inventは学習イベント」 だということを強調されていました re:Inventは数多くのセッションやExpoの参加企業から様々な気づきや学びを得ることができる最高の場所で、かつ多くの関連企業やAWSコミュニティとつながりをもつことができます 現地でしか感じ取れないAWSに対する情熱や温度感をダイレクトに受け取れるのがre:Inventの最大の醍醐味です 講演でも話されていましたが世界各国から多国籍、他業界の人が訪れるので様々な課題やユースケースがあり色々な話を聞くことができます 私はweb業界で国内との関わりが多いのですが、re:Inventを通してゲーム業界の方や、日本以外の各国の企業の様々なロールの人とお話をすることができました 普段はwebアプリの開発をおこなっていますが、その中で自分が躓いていたりすることが他企業でもおこっていたり、普段実装しないようなサービスのユースケースの話をお互いの考えを交えながらできたりと、このようなことができる場はなかなかないと思います AWSは様々な企業と協力していて金融業界、ヘルスケア業界など様々な業界がAWSを利用しています 例えばSalesforce社があげられており、Salesforce社のCRMに特化したAIのSalesforce EinsteinとBedrockで使って生成AIアプリをすぐにデプロイできるようになったりするそうです re:Invent参加前はAWSはひとつのITツールぐらいの認識でいましたが、多くサービスがAWS上で動いており様々な業界や企業にとってなくてはならない存在になっており、AWSは本当の意味でインフラであることを知りました re:Inventは日本語訳で 「再構築する」 という意味です これはAWSのDNAに組み込まれています スライドに「Access to the same powerful technology」という標語が使われておりAWSの考え方がダイレクトに理解できました 新サービス発表 reinventing storage with Amazon S3 S3は最初2006年に発表されたらしいです AWSについての歴史はあまり知らず思ったより昔で意外でした そしてIntelligent-tieringは今までに 20億ドル の節約をしているみたいです とんでもない金額ですね ストレージというお金をかけたくないけど重要な部分がゆえに力が入っているのを感じました ここでS3の新機能発表がされました Amazon S3 express One Zone このS3は高性能分析のワークロード向けのS3になります 気になった特徴は下記の点です S3標準ストレージより最大10倍高速 一分当たり数百万件のリクエストに対応しコストも最大60%節約 One Zoneなので単一AZとなります 機械学習関連やリアルタイム広告配信など、ここぞという場で使いそうな場は多そうです 詳しくは 公式サイト でも説明されていますので是非読んでみてください Reinventing General Purpose Computing パフォーマンスとコストを考える中でGravitonの説明もされました GravitonはEC2インスタンスで使用されるAWSによって開発されたカスタムARMベースのプロセッサです 今回のre:Inventでは新しく AWS Graviton4 が発表されました AWS Graviton4 Graviton4は以下のようなポイントがあります Graviton3より平均30%高速 データベースアプリケーションで40%高速に Javaアプリケーションで45%高速に 特定のワークロードに対してとても活躍しそうです Javaは採用している企業も多いと思うので影響範囲は大きそうです わずか5年でGraviton4に進化しているとのことで驚きです Graviton4に関連して R8g Instances for EC2 Powered by AWS Graviton4 も新しく発表されました Reinventing with Generative AI AWSはAIをAmazon全体のサプライチェーンの最適化や小売検索機能の向上など多くの場面で活用してきました AWSはgenAIを現在のAI技術の次のステップとして位置づけています genAIを3つの階層に分けての説明がされました 最下層はFmモデルなどの層 中間層はLLM棟のモデルで生成AIアプリを構築、拡張するための層 最上層は専門知識がなくてもすぐに生成AIを使用できるような層 Fmモデルなどの最下層 最下層のワークロードでは大きな計算能力を必要とし、GPUがそれを可能にします AWSはNVIDIA社と協力してGPUをクラウドでつかえるようにしてきました 今回のKeyonteではNVIDIA社のCEOのJensen Huangさんが講演にきました このように世界的な企業のCEOをお話を聞けるのはre:inventならではです ここではNVIDIAとAWSが共同でNVIDIA DGXクラウドのAWSに導入するなど新たに様々なことを発表していました AWS内で完結せずに他の企業と共同で技術が進化しています この後にもNVIDA社以外にもがファイザー社など様々な企業の方が何人か講演されていました AWS Trainium2 AWS Trainiumは機械学習モデルをトレーニングするための専用チップです 今回その第二世代であるAWS Trainium2が発表されました 特徴としては下記です 第一世代より４倍はやい 数千億、数兆のパラメータを持つ基礎モデルのトレーニングに最適 65エクサフロップスの非常に高速な計算能力な性能 自分は普段機械学習系をメインで扱っていないので詳しくないですが、それぞれの単語のインパクトが強くgenAI界隈は進化が早いことを感じます 生成AIアプリを構築、拡張するための中間層 多くの企業はモデルを構築するというよりは既存の優れたモデルを利用してサービスに価値を付加していくことが多いでしょう 実際に開発する中で数多くある優れたモデルからどのモデルを選べばいいのか、どうやって迅速に構築デプロイができるのかなどの課題があると思います そんな課題を解決していくのが中間層になります Amazon Bedrock Amazon Bedrockについて紹介されていました Amazon Bedrockは、Amazonなどが出している高性能な基盤モデル (FM) を単一のAPI で選択できるフルマネージド型サービスです 私は触ったことがありませんが生成AIアプリの構築が楽になり幅が増えそうなので興味をもちました 生成AIアプリの構築を考えるうえで選択肢の一つとなりそうです 9月に一般提供されたばかりですが、すでに10000を超える企業がBedrockを採用していてスピードがとても速いです 実世界ではすべての事象に対応した完璧なモデルがないため、AWSはAmazon独自のモデルだけを利用してもらうのではなく、様々な企業のモデルを使えるように幅広い選択肢を持たせているようです このような発想からAWSの思想を感じることができます また、Fmモデルの提供しているAnthropic社のDario Amodeiさんの公開対話のなかで ハルシネーションにも触れられており、これからの生成AIの安全性についての話は興味深かったです Bedrockでもいくつか新機能が追加されました Fine tuning Cohere Command Lite, Meta Llama2, Amazan TItan Text Lite & Express,Anthropic Claude Retrieval Augmented Generation (RAG) )with Knowledge Bases Continued Pre-training for Amazon Titan Text Lite & Express Agents for Amazon Bedrock Guardrails for Amazon Bedrock 2つ目と5つ目が個人的に興味深いものでした 2つ目は既存のFmで社内のデータベースに安全に接続でき、ドメインにより関連した検索が可能になることから検索サービスやドキュメントサービス周りで活躍しそうです 既存のモデルを基に社内データベースでデータで拡張できるのはとても便利です 5つ目は責任あるAIポリシーに基づいてフィルタリングを書けることができるものです それ以外にも個人情報(PII)の削除等もできます 近年責任あるAIが重要視されていますがその部分のサポートになります この部分は企業がサービスを提供する上で敏感にならざるをえない部分なのでこのようなサポートはありがたく、ますますビジネスでの活用が増えそうです AWSの学習について 話の途中でAWSの学習についても触れられました AWSはAWSCloud InstituteやAI Readyなどの学習リソースの提供や機械学習関連の奨学基金の創設などを行っています また2025年までに2900万人がクラウドコンピューティングを無料で学べるように取り組んでおり現時点で2100万人です 普段仕事をしていると感じませんが世界中のとても多くの人がクラウドコンピューティングを学習しているのを実感しました 専門知識がなくてもすぐに生成AIを使用できるような最上層 例えば代表的なサービスはAmazon CodeWhispererです 私は普段Webアプリ開発をおこなうことが多いのでこの層のサービスを扱うことが多そうです しかし、多くのAIチャットアプリは会社の内部情報をもっていませんし、その利用も禁止されている場合が多いです そんな中で今回のKeynoteで一番の目玉である Amazon Q が発表されました Amazon Q Amazon Qは仕事でつかえるAIチャットアシスタントです まず、Amazon QはAWS上での技術的な構築をサポートします 主に下記のようなことができます Amazon Qにインフラ構成を聞きながらデプロイ 作りたいアプリのユースケースに合わせたAWSサービスの選択 トラブルシューティング フレームワークのアップグレードや非推奨のコードの置き換え　etc... 特に私がいいなと思った点はトラブルシューチングもボタン一つでおこなえる点です AWSコンソール上で作業を行う場合うっかりとしたミスが発生してしまうこともありますがひとつひとつ確認する手間が減ります　 コード変換に関しては必要な作業だけれどもなにか新しい価値を生み出すわけではないのであまりやりたくない作業ですが、この部分をやってくれるのはとても大きいと思います 実際の例としては2日間でJavaのアプリを1000個アップグレードしたと紹介されていましたがとても信じられません Amazon Qの恩恵をうけるのは開発者のみではありません 次に開発者以外の職種の方々も活用することができます Amazon QはGoogle DriveやSlackなどよく使われる40のデータソースとつながり、学習をします しかもこれはセキュアでプライベートに行うことができます デモではAmazon Quicksight上でビジネス上のデータについてAmazon Qへ質問をして回答を得ることをしていました 今までのグラフを作ったりデータを読み取ったりなどの作業は、基本的にAmazon Qに対して「○○について棒グラフをだして」や「○○の月次レポートを出して来月の推奨事項を作成して」などの自然言語で作業をすることができます またAmazon QはAmazon Connectで使えます 通話にAmazon Qが参加することも可能で応答をしたり関連記事のリンクを提供したりできます そして、通話後もその概要を自動で作成してくれます 自社のデータをにアクセスできてAIチャットをビジネスで使えるというAmazon Qは仕事の在り方を変えるようなサービスで驚かされました データ活用 Amazon RedshiftでZero-ETL integrationsがAurora Mysqlに加えて下記三つがつかえるようにすることが発表されました Amazon Aurora PostgreSQL Amazon RDS for MySQL Amazon DynamoDB ETL は、extract（抽出）、transform（変換）、load（読み込み）の略で今回の発表で上三つのデータbaseに対してもこのパイプラインの作成がゼロになり,これによりリアルタイムな分析が可能になります そしてAmazon OpenSearch ServiceでもZero-ETL integrationsがDynamoDBで利用可能になることが発表されました DynamoDBに対してOpensearchで検索できるのはかなり便利に感じます 上記以外にもAmazon DataZone AI recommendationsが発表されました Amazon Project Kuiper Kuiperは衛星通信サービスです インターネット通信が安定的でない場所にも届くようにする取り組みをAmazonは行っています 詳しくは こちら を確認してみてください 今回はパブリックのインターネット接続に加えてエンタープライズ向けのプライベート接続を発表しました おわりに 読んでいただきありがとうございました 今回Keynoteに現地参加してきました 現地では新しいサービスが発表されると歓声や拍手があがりその熱量に驚かされます 発表された新サービスに関連して新しくセッションが開かれるので興味があるサービスの場合は該当のセッションで内容を深めることもできます Keynoteの内容とともに現地の熱量に影響をうけ自身のAWSに対するモチベーションをあがりました 今後もAWSを頑張っていこうという気持ちになりました みなさんもre:Inventに訪れた際はぜひkeynoteに現地参加してみてください 投稿 ラスベガスにてAWS re:InventのKeynoteに現地参加してきました!!! は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは。今年もアドベントカレンダーの時期が来て年の瀬を感じている筆者です。 私はいわゆる「オタク」で、昨年はアドベントカレンダーに「 Slackを推し色に染める 」という記事を寄せたり、マイナビで働きながらオフでは趣味や「推し」にまつわるあれこれにも没頭する日々を過ごしています。 そんな私はデータを整備し社内へ提供する仕事をしているのですが、ある日ふと思い立ちました。 私は舞台やライブなどに行くことが趣味で、幸いにもGoogleカレンダーに遊びの予定を全て記録していました。 今は12月。１年の総決算をするような時期です。 せっかく貯めているスケジュールデータを可視化して1年間の「オタ活ダッシュボード」を作ったらきっと面白いのではないか...！ 今回は勉強がてらMicrosoft社のBIツール「Power BI」を使って、なるべく簡単にスケジュールデータの可視化を行いたいと思います。 BIとは？BIツールとは？ BIとはBussiness Inteligenceの略で、事業での意思決定をするために企業や組織のデータを収集・整備・分析することです。 分析の手段として主に可視化（グラフ・図・表などでデータを表現する）を行います。 （なので個人のスケジュールデータを可視化することは正確に言うとBIではないです...。） Microsoft社のBIツール「Power BI 」は無料で使用することができるBIツールです。 https://www.microsoft.com/ja-jp/power-platform/products/power-bi 様々なデータソースに接続できるので、手元のファイルはもちろんのこと、データベースに接続しデータを使用することができます。 また、UIもシンプルでドラッグ&ドロップだけで高度なグラフを作ることができます。 ※Power BIは今回の目的に対してかなりオーバースペックなツールとなりますが、練習も兼ねているためご了承ください。 作成の流れ 今回は以下3つを表現するグラフを作成しようと思います 1年間でイベントに行った回数（イベント種別ごと） 月ごとにイベントに行った回数と各ジャンルの回数 行った会場の場所と回数 実際に完成したものがこちらです。 以下の手順で作成していこうと思います。 ①データダウンロード ②データ整備：可視化しやすいようにデータを整える ③データ可視化：グラフを複数配置したダッシュボードを作成する ④デザイン：Adobe Colorを使って見た目を整える 1.データダウンロード Googleカレンダーからスケジュールデータをダウンロードします。本筋とは逸れるため詳しい手段は割愛します。 csvファイルには以下の列がありました。※イベント名等はぼかすため変更しています ⓵タイトル ⓶開始日時 　終了日時 　時間：開始日時～終了日時の間の時間 ⓷参加者 ⓸場所 ⓹説明 説明の部分は、あらかじめ「イベントのジャンル名,イベントの種類」の書式でカレンダーに入力していました。 データを見ると以下を修正した方が良さそうです。 開始日時/終了日時→「日」と「時間」をわけておきたい 参加者→いらない 説明→「ジャンル名」と「イベントの種類」の列を作成したい 場所→「場所名」・「郵便番号」・「都道府県」・「市区町村」・「詳細な住所」にわけたい／一部文字化けしているので直す 以上を踏まえてデータ整備を行っていきます。 2.データ整備 今回はデータ整備をPower BI内で行っていきます。 Power BIを開くと以下のような画面になるので、左上の「データを取得」から「テキスト/CSV」を選び、先ほどダウンロードしたファイルを選択します。 プレビューが開くので「データの変換」を選択するとPowerQueryエディターが開きます。 PowerQueryとは簡単にいうとクエリ(=処理命令)を使用しデータを変換するエンジンです。 （詳細は Microsoft公式ページ をご覧ください） 簡単な整備であればコードを書かずにクリックだけで行っていくことができます。 クエリを使用しデータを変換しているため、元データに追記があった場合でも同じ処理を行えます。 日付と時間を分ける 元の列を残したうえで分割による列作成を行います。 「列の追加」タブ内の「カスタム列」を選択し、列名を変更・複製したい列をリストから選びOKを押すと複製できます。 開始日時を選び「変換」タブ内「列の分割」を選びます。 「区切り記号による列の分割」をクリックし選び、区切り記号を「スペース」にしてOKを押すと日付と時間が分割されます。 項目名をダブルクリックして「開始日付」「開始時間」に変更します。 「参加者」列を削除する 列を選択し右クリックで「削除」を選択すると消せます。 「説明」から「ジャンル」と「種類」の列を作成 区切り記号を「コンマ」にして列を分割します。 「場所」から「場所名」・「郵便番号」を作成 前提として住所の分割処理はとても難しく、今回扱う方法では場合によっては上手くいかないことがあることをご了承ください。 住所の処理の厄介さは度々データを扱う部門では話題になるのですが、それだけで記事が1つ書けてしまうので今回は割愛します。（深淵を覗きたい場合調べるとたくさん出てきます） 「場所」は以下のような記法になっています。 東京ドーム, 日本、〒112-0004 東京都文京区後楽１丁目３?６１ 文字化けを修正する必要がある 場所は国内だけなので「 日本、」を削除する 「〒」は 仕様的に外した方が良い 区切り記号をカンマにして「場所名」列を作成できる 郵便番号は桁数が固定されている 地名に「○○市」と「○○市××区」があるため「市区町村」の分離は気をつける必要がある ...以上を見るだけで住所処理の煩雑さがわかるかと思います。 今回は「簡単に」という点を重視して場所名と郵便番号だけ列を作成します。 文字化けの修正・「 日本、」「〒」を削除 置換により変換/削除を行います。 列を選択し、右クリック→「値の置換」を選択します。 検索する値に「?」を入れ、置換後は「-」を入れてOKを押します。 「日本、」「〒」をそれぞれ入れ、置換後は空白のままOKを押します。 区切り記号カンマで「場所名」列を作成 区切り記号を「コンマ」にして列を分割します。 「郵便番号」列の作成 列を選択し「列の分割」→「文字数による分割」をします。 郵便番号は8桁ですが先頭にスペースが入っています。 9文字目で区切ったあと、右クリック→「変換」→「トリミング」でスペースを消します。 データ処理が終わったら データ処理が終わったら「閉じて適用」をクリックします。 最後に、データのカテゴリ設定を行います。 画面左側「テーブルビュー」をクリックし列ツールから「データカテゴリ」をクリックし、郵便番号にカテゴリを設定します。 以上で前処理は終了です！ ここまで長かったのですが、いよいよ可視化工程に入ります。 3.データ可視化 画面左の「レポートビュー」を選択します。 「視覚化」内のグラフを選びキャンバスにドラッグ、「データ」から列を選んで作成します。 1年間でイベントに行った回数（イベント種別ごと） 円グラフで表現します。 「視覚化」から円グラフを選んでサイズ調整した後、凡例・値にイベント種別を表す「種類」を入れます。 ビジュアルの書式設定で表示する数値やデザイン等を整えます。 月ごとにイベントに行った回数と各ジャンルの回数 積み上げ縦棒グラフで表現します。 X軸に開始日付、Y軸にジャンル、凡例にもジャンルを入れます。 「階層内の次のレベルに移動します」を押すとデータの切り口が年→四半期→月→日で変わります。 日の時、開始日付を右クリックし「日付の階層」を選ぶと以下のような表示になります。 見たいのは月ごとの合計なので、X軸から「日」を削除し月ごとの合計を表示するようにします。 ジャンル数が多いので、ジャンルのグループ化をします。 凡例の「ジャンル」を右クリックし、「新しいグループ」を選択します。 グループ名を入力し、値を選択しグループ化を行います。 行った会場の場所と回数 マップで表現します。 場所には郵便番号を入れます。 凡例には場所（会場名）を入れます。 バブルサイズに場所を設定すると行った回数が多いほどバブルの大きさが大きくなります。 郵便番号を場所にとると、市区町村レベルまで表示されます。 4.デザイン 配色によって一部見えにくいところを調整します。 「表示」タブからカラーテーマを設定できます。 今回は時短のため「 Adobe Color 」でいい感じの色を検索し使用します。 完成！ というわけで無事に「オタ活ダッシュボード」の作成ができました。 動的なグラフなので、例えばイベント種別で「舞台」をクリックすると月×ジャンルでもイベント種別が「舞台」となっている項目が強調されます。 できたダッシュボードを眺めながら自分なりに発見はあったのですがここでは割愛します。 毎年データを増やしていけたらまた色々な知見を得られそうだなと思いました！ 最後に PowerBIは深ぼればもっといろいろなことができますので、お時間があれば触れてみてほしいです。 「データ」というと少し堅苦しく感じるかもしれませんが、少しでも本記事で「データを扱う」ことを身近に感じていただければ幸いです。 投稿 今年1年のオタ活を15分で可視化してみた は マイナビエンジニアブログ に最初に表示されました。

はじめに 社会人２年目となったUXデザイナーのT.Tです。 私の所属しているデジタルテクノロジー戦略本部ではIT特化している組織として日々体制が変わり、組織が大きく成長しています。 その中で、社外の有償セミナーやイベントに対しても補助が手厚いと知り、外部研修受講制度を利用してデザイン部のメンバーとともに4年ぶりに対面イベントとして開催された「Adobe MAX JAPAN 2023」に参加してきました！ 下記にセミナーの詳細や印象に残ったことをお伝えできればと思います。 1.イベント概要 タイトル：Adob MAX JAPAN 2023 日時　　：2023年11月16日(木) 場所　　：東京ビックサイト URL ： https://maxjapan.adobe.com (アーカイブ動画もサイトにあります) 2.セミナー詳細 　下記にKEYNOTEさんのセッションの登壇内容の要点をリスト形式で記載させていただきます。 詳細はAdobe公式のYoutubeで公開されている動画をチェックしてください。 ​ ​ 登壇概要 クリエイティブの需要を実現していく firefly FrescoやLightroom premire proの進化 expressの登場 共同編集が可能 LINEクリエイティブとの連携 今後は垣根を超えてクリエイティブとマーケティングの境界がなくなる 全ての人が関係するソーシャル要素を考える必要がある、 マーケ選択【マクロ）(カレンダー)、アジャイル的考え(ストップウィッチ)】 ハイパーパーソナライゼーション　 AIアシスタントCopilot[副操縦士]の開発 生成AIはまだまだ始まりに過ぎない プロジェクトスターダスト 　 画像加工における、既存の画像内のオブジェクトを自由自在に改変できる 11月16日からFireFlyの生成モデルの進化版イメージ2解禁 目次 PhotoShopの生成AI Illustratorの生成AI 動画編集の時間短縮 Expressでのクリエイティビティの創出 PhotoShopの生成AI プロンプトは入力なしで基本作成可能 コンテキストタスクバーでの作業の単純化 ライブグラデーション機能の充実 色調補正プリセット→自分のプリセットをカスタムできる Illustratorの生成AI 「シンプルな」がパスの少ない必須ワードとなる プロンプトのスライスピッカー モックアップ機能搭載（イメージが違和感無く反映可能） メッシュで生成（自分の写真でも可能) コンテキストタスクバーから再配色 生成再配色機能 アウトライン問題解消リタイプ→Typeテキストに変換 動画編集の時間短縮 圧倒的な時間短縮を実現 自動文字起こし機能(フィラーや語感間を自動削除) 文字起こしテキストからの動画削除 文字起こしからのキャプション作成 ノイズ除去オーディオスピーチを強調できる AdterEffectフォトブラシの強化 トラッキング機能の進化 人物後ろに文字を感嘆に入れられる Expressでのクリエイティビティの創出 xdの進化版のイメージ 動くバナー イラレでの修正が同期反映できる 多言語変換に対応 CANVA感 3.印象に残ったこと ①生成AIもそれぞれの用途に合わせてモデルが使い分けられていること 特にこれまで意識していませんでしたが、PhotoShop用に写真画像に対する生成とIllustratorのようにベクター画像に対する生成でAIモデルが異なることは登壇の中で初めて知りました。 なお、先日Fireflyで最新の ImageModel2 が新しくリリースされ、教師あり学習のようなベースとなる素材画像を提供した上で適切なプロンプトを入力すると特有の画像を作り上げることができるみたいです。 ②書式のReTypeでアウトラインされた画像を編集可能なものに復元できる 一般的に文字の配置を揃えるために作成した文字は command+shift+O でアウトライン化(図形化)する必要があるのですが、その後文字変更する際に文字を変えられないのでバックアップをきちんと取っておく必要がありました。それが今回近しいフォントを検出して、復元してくれるようになったのです。 ③Expressで作成したバナーをボタンひとつで複数言語対応できる 今回イベントに参加して初めて Adobe Express のサービスを知ったのですが、Canvaのように手軽にデザインバナーや広告動画を手軽に作成できるもので、セッションでは作成したバナーをボタン一つで複数言語対応のバナーを瞬時に作成していて驚きでした。 現在45言語まで対応しているみたいです。 ④Stardustで画像の任意のオブジェクトとして操作・復元できる 現在開発中であるStardustでは写真に対してオブジェクトとしての検出を行い、不要な人物を消すことができるだけでなく、重なった人物を離した上でAIで体や服を復元を可能とするそうです。 4.その他のセッションについて 記載の可否の都合のため詳細は控えますが、IllustratorやPhotoShopの便利なTipsや今後我々UXデザイナーが力を入れていかないといけないUXリサーチの成功事例についての共有もあり、とても勉強になりました。 また、Photoshopの伝道師ラッセル・ブラウンという方も来日され、生成AIの応用として自動アクションを使って画像生成の幅を広げるショーも行われました。 5.感想 普段仕事をしていると制作系の会社でないと外部のデザイナーと接する機会あまりないのかなと思います。今回イベント参加者は3600名超えとこんなにたくさんのデザイナーの仲間がいたのかとモチベーションが上がりました。 イベントでは生成AIの内容が大半を占めていて、なるべく利用するように心がけていたものの、知らないアプローチ方法や最適なプロンプトは勉強になりました。 また今回のセッションをふまえて、デザインツールだけでなくAdobe製品での業務での活路を少し見いだせたのかなと思います。 これまで長年デザインツールを使いこなされていた方々によるセッションでは発見が多く、大変ためになるTipsばかりだったので、今後少しでも技術の引き出しとして使えるように実践活用していければと思います。 6.最後に 　弊社は人材紹介会社のイメージがかなり強いと思われますが、DXを推進していくデジタルテクノロジー戦略本部の中にUXデザイン部というデザイン制作の部署があり、他部署のイベントのチラシ作成や新規サービスのロゴコンペの実施、弊社の50周年記念イベントのデザインなど、幅広い業務に関わっています。 また、作成したデザインは世の中の多くの人の目に触れることもあり、緊張感やプレッシャーも多くありますが、同時に大きな達成感も感じることができる仕事です。 今後もUXデザイン部の魅力をお伝えできるようなデザインに関わる記事をたくさん発信できればと思います！ 出典 Adobe MAX Japan 2023 https://maxjapan.adobe.com 投稿 デザイナーの祭典 Adobe MAX JAPAN 2023参加レポート は マイナビエンジニアブログ に最初に表示されました。

と あるSEMコンサル 「社会人になって3年が経つし、そろそろ転職考えようかなー。でも次の転職先はどこがいいのだろう。今いる広告代理店でキャリアを伸ばしていくべきか、事業会社で働くべきか。」 このような疑問にお答えます。 　このページでは、Webマーケターとして将来どのようなキャリアを進んでいくか悩んでいる方に対して、数あるキャリアパスの中でも、広告会社から事業会社へ転職して感じていることをお話します。 　執筆した背景としては、Googleでこの類の記事を探そうとすると「メリット」ばかりがフォーカスされた記事をよく目にします。 　 そのためなのか、過去の面接の場で、事業会社に対するWebマーケティングに対する認識のギャップを幾度となく感じてきました。 　ありのままを伝えるので、「デメリット」ではないという点、予めご了承ください。 　また、広告会社、事業会社それぞれの働き方ややりがいは、一長一短あると思います。どちらが良い悪いではなく、ひとつのキャリアパスとして参考にしていただければ幸いです。 ✓ この記事を書いた人+++++++++++++++++++++++ 大学時代にWebマーケティングと出会い、興味本位でブログを開設。アフィリエイト広告を通じて、インターネットの面白さ、将来性を感じ、広告代理店へ新卒入社。 リスティング広告やディスプレイ広告など、様々なクライアントの広告運用に携わっていく中で、「裁量が大きく、もっと自分のアイディアを広告に活かしたい」と考え、株式会社マイナビへ転職。現在は、マイナビに入社して10年が経過し、マネージャーとして、マイナビAGENTの広告集客に携わる。 マイナビのマーケティング職に興味がある人に向けて記事を書いても、Googleの検索結果に上位表示され、この記事が届かないと意味がない。 SEOド素人の広告担当が、コンテンツSEOを意識して、自身の実体験をもとに、事業会社へ転職して感じている事を書いてみました。 +++++++++++++++++++++++++++++++++++++ 隣 の芝生は青く見える？広告主の働き方　 　当時、私が広告会社に勤めていた頃はこのような思いでした。思い当たる節、ありませんか？ 広 告主は「楽して働いてそう 　広告代理事業はその名の通り、「発注側」と「発注される側」で大きく分類され、よく働き方を比較されがちです。広告会社の立場からすると発注サイドの働き方は楽に見えて、隣の芝生は青く見えませんか？ 　実際、私も広告会社から広告主側に転職する際は、そう感じていました。当時感じていた広告主の働き方とは、まさに人に任せて「楽して働いていそう」です。 ジ ャイアン的発想？広告会社の成果は広告主のもの 　私は広告会社の時、アカウントプランナーや運用のコンサルティングをしておりました。毎月、毎週のクライアントへの報告の際、目標数値が未達だったり、売上が立たなかったりしたことを、すべて広告会社の問題かのようにすり替える担当者と、過去に数え切れないほど対峙してきました。 　広告費を払うという立場を利用して、ラクして働く代表格です。 お金を支払う立場なので、常に上から目線。偉そう 人を使うだけ使って、自分だけ評価されている 広告費を広告会社に預けて、あぐらをかいて座っている 達成出来なければ広告会社の責任、達成出来たら自分のおかげ 成果が悪い時だけ、やたら連絡してくる 月次レポートで細かいところを指摘、揚げ足取りする 　だいぶ、極端な書き方をしましたが、真面目にクライアント、そしてWebマーケティングと対峙している方なら、少なからず共感いただける点があるのではないでしょうか。 　 　隣の芝生は青く見えるのは当然のこと。決して間違いではないです。 　ただ、今思い返すと、その広告主の態度や言動は、自分の保身のためのものではなく、事業ドメインをサポートする立場として必死だったからと改めて思います。 事 業会社のWebマーケターは決して甘くない 　結論から言うと、広告主のWebマーケターは想像以上に大変です。広告会社から広告主側に転職して、ラクして働こうと安易に考えていた自分が情けないです。 　決して広告主のWebマーケターは甘くありません。Webマーケティングの成果が、そのまま事業の成長に直結するプレッシャーを抱えつつ、日々プロモーション活動を行っています。 事 業の成長に直結するマーケティング活動、その責任とプレッシャー 　一般的な広告会社のミッションが、私が思う限り「広告予算の最大化」がビジネスのゴールだと思っていますが、事業会社は「（顧客満足度を高めた上で）事業の継続的な売上向上・利益の最大化」だと思います。 　しかし、Webマーケターとして広告予算を増やすことは目的の一つでありますが、状況によっては広告予算を削減して、いかに利益を残すかが重要視される事も度々見られます。 　とくに、マイナビは人材と企業をマッチングさせるサービスがほとんどあり、プロモーション、サイト集客などマーケティングの成果によって事業の売上や利益は上下に変動します。 　広告やサイトの集客に携わる部門は、野球でいうと「先頭打者」のような存在かもしれません。広告予算は決して、どこからかふっと湧いて出てくるものではなく、会社のお金を使う以上、当然のように結果が求められる非常にシビアな世界です。 事 業全体の状態が数字で良くも悪くも見えてしまう 　過去の面接選考を振り返ると、転職理由に「戦略から立案に携わり意思決定をしたい」「上流工程から携わりたい」という考えをよく聞きます。 　確かにこの考えは間違えではなく、転職することでそれは達成できます。 　しかし、逆に言うと「上流工程から携わる」ということは、事業全体の数値が見えてしまうということでもあり、売上や利益をコントロールするという動きや意識が常に必要になってきます。 　広告会社では、コンバージョンやCPAなど中間指標の達成に向けて動くことが多いですが、事業会社では売上・利益が重視されます。 　「目標CPAの範囲内でコンバージョン数が達成したとしても、売上が上がらなかった」それがなぜなのかマーケティング部門として言及しなければならない場面はよくあります。 変 化が速い業界のため常にスピードが求められる 　マイナビが得意とする人材領域は、雇用にかかわる業界のため、景気や政治状況に敏感で、変化も顕著です。 　世の中のニーズの変化を敏感に察して施策に落とし込んだりとスピードを緩めることはできません。さらに、競合他社の動きも加われば、意思決定にスピードが求められるのは当然です。 　事前に何かを判断する素材が揃っていることはまずありませんが、少ない解決策の中で最適解を見つけ、愚直に数字と向き合って改善策を出し続けるという点では、「泥臭い仕事」といっても間違いではないと思います。 非 生産部門という考え方 　広告会社にいるアカウントプランナー、Webマーケターやクリエイターは、広告戦略立案・クリエイティブ制作というビジネスドメインに紐づく職種なので、事業会社よりも社内における立場は強いのではないかと勝手ながらに想像します。 　一方の事業会社では、経営企画や営業部門が含まれ、これらは会社の中核を成す部門であり、売上に密接に関与しています。Webマーケティングを担う部署は、ビジネスドメインをサポートする役割を果たし、しばしば非生産部門として扱われ、予算を必要とします。 　営業部門との間にセクショナリズムがあるということを伝えたかったのではなく、広告会社で働く人たちは、この事実に気づきにくいことがよくあり、誤った解釈に繋がりやすいポイントの一つです。 残 業制限とパフォーマンス最大化の両立 　広告会社では、徹底的にこだわり、時間をかけてでも最高の広告コンテンツを生み出したいという文化が根付いていると勝手ながら考えます。 　裁量労働制や見込み残業代の支給が一般的であり、したがって残業代を主な収入源とするケースは少ないのではないでしょうか。ここでは、個々の時間の使い方が組織ではなく個人に委ねられている傾向が強いと思います。 　一方で、事業会社は残業が少ない傾向がありますが、特にWebマーケティングを担う部署では、効率的に協力して成果を上げ、高い生産性が評価される傾向があります。短い時間内で最大限の成果を出すことへの意識が高く、時間に対するコスト効率が重要視されています。 で は、なぜ10年以上もこの仕事を続けられるのか？ 　ここまで読んでいただくと、事業会社へ転職することのメリットを一切感じていらっしゃらないのではないでしょうか。 　では、なぜ10年以上もマイナビのWebマーケティング職として働き続けているのか、その理由をお話しします。 「 広 告で人の心を動かす」が楽しい 　これは、会社というよりも、Webマーケティングに対する想いです。 　事業会社、広告会社どちらであろうと、「広告で人の心を動かす」仕事であることは間違いないと思います。改めて振り返ってみると、誰かに表現したことが影響していく喜びが常に原動力になっていたように思います。 　日々、数値ばかりに忙殺されてしまうと、どうしてもこのような仕事のモットー、自分が大切にしていることを見失いがちですよね。 　私の場合、今の働き方の方が上流工程・意思決定に携わることができるので、この点転職して良かったなと思えるポイントです。 「 ト ライ&エラーの数だけ上手くいく」が楽しい 　これも、Webマーケティングに対する想いです。 　Webマーケティングには「ゴール」や「終わり」があるわけではなく、施策が成功しても改善の余地があり、逆に失敗しても改善の機会が広がっています。この繰り返しのプロセスが、良くも悪くも未来永劫続くものと考えています。 　野球の世界で打率3割あれば評価されるように、Webマーケティングも全ての施策が成功することは難しく、そのためには常に新たなアプローチを試みることが重要です。言い換えれば、常に「打席」に立ち、トライ＆エラーを通じて自身の正解を見つけ出すことが求められます。 　考え、思いつく施策を試し続けられる、それが数値として白黒はっきり表れる。 　広告会社にいた新卒当時から、「トライ&エラーの数だけ上手くいく」というプロセスが楽しいと、今でも感じています。 自 社サービスを長期視点で育てていく醍醐味がある 　ここからは、事業会社のWebマーケティングに対する想いです。 　データ分析から導き出した考察を基に、実施したターゲティング広告が的中した瞬間がやりがいだ！という話は、よくある話かと思います。 　ただ、それ以上に単なる業績向上だけでなく、自分が携わるサービスが市場シェアを伸ばしていき、どんどんポジションを確立していくワクワク感があります。 　自社サービスを長期視点で育てていく醍醐味があるというのはもちろん、「自分が携わったサービスを多くの人に使ってもらえる」という実感が得られるのは、まず間違いないと思います。 「 圧 倒的」強者を目の前に戦う楽しさ 　私が担当するマイナビAGENTは、人材紹介サービスの中でもまだまだチャレンジャーの位置にあります。 　競合他社に広告費の総額では決して勝つことはできず、競合と同じことをしていては一生勝つことができません。発想やアイディアの幅を広げるため、チーム総力戦で、日々試行錯誤しながら新しい広告手法を考え、クリエイティブ開発に努めています。 　確かに広告費を増やせば出来ることが増えますが、限られた原資の中で、いかに創意工夫をしていくか、そこに我々の存在意義があると信じています。 【 ま とめ】「打席」に立ち続ける覚悟はありますか？ 　最後まで読んでいただき、ありがとうございます。 　仕事において、他の企業や職場が良いように見えることはあるかもしれませんが、実際にはその内情や課題も知らない限り、表面的な印象だけで判断することは難しいですよね。 　ただ一つ言えることは、隣の芝生が青いのは幻想であり、「事業会社のWebマーケターは甘くない」ということです。 そのうえで、本当に 覚悟 があるのかどうか、胸に手を当てて考えてみてください。 事 業会社か、広告会社でキャリアを選ぶべきではない 　社会人経験が長くなると、視野が狭くなり、気づかぬうちに自分の選択肢を少なくしてしまう人が少なくありません。私自身もその人のうちの一人だと自覚しています。ただ、自分の思い込みで動くことで貴重なチャンスを見逃してしまうのは惜しいことではないでしょうか。 　改めて、自分は本当に事業会社に向いているのか、広告会社と事業会社の双方を検討してみることは良い選択肢と言えるのではないでしょうか。 　私は過去の面接の場で、事業会社に対するWebマーケティングに対する認識のギャップを感じてきたわけですが、もしワークライフバランスを整えたり、リモートワークをするための手段として事業会社を選ぼうとしているなら、一度立ち止まって考えた方がいいかもしれません。 今 なくてもいい。ただし「何を実現したいか」目的を見つける努力はしよう 　結論を最後に持ってくるあたりが、ライティングスキルの低さを露呈していますが、正直マイナビに転職するまでは明確にやりたいことがあったわけではありません。※この場では発言を控えますが「野望」は持っていました。 　恐らく、多くの人が自分の将来についてあいまいな考えでいると思います。 　私の場合、マイナビAGENTという人材紹介サービスとちゃんと向き合い、そのサービスが広告予算とともに売上が成長していく過程の中で「実現したいこと」が明確になっていきました。「やりたいことは後からついてくる」とはまさにこのこと。 　それは、 人材紹介サービスの中で、マイナビAGENTが市場シェアNo.1のポジションを獲得する。 です これは、さきほど申し上げた通り、「打席」に立ち続けた結果、私にしか見えない景色です。 　事業会社のマーケティング担当はその会社のサービスにずっと関わっていかなければならないデメリットもあり、「自分が何をやりたいのか」逆にこれが見つからないと、仕事に対するモチベーションが上がりにくく、業務に焦点を当てることが難しくなります。 あなたは、事業会社で「打席」に立ち続ける覚悟はありますか？ 　　私は、マイナビもWebマーケティングも大好きです（嫌いな側面もありますが）。好きなことを突き詰めていった先に自分の熱中できることがあるはずです。「打席」に立ち続け、どんな形であれ目的を見つける努力はしましょう。 編集後記 　マイナビのマーケティング職に興味がある人に向けて記事を書いても、Googleの検索結果に上位表示され、この記事が届かないと意味がない。と冒頭に書かせていただきました。 　 　上位表示を狙いたい検索キーワードは、「Webマーケ␣転職」「事業会社␣Webマーケ」「広告会社␣転職」です。コンテンツの重複チェック済みで、キーワードの頻出度合いもチェックしました。 　 　マイナビの強いドメインパワーを借りて、しっかりとこの記事が皆様の手元に届くよう上位表示を目指して、コンテンツを見直していきたいと思います。 投稿 広告会社から事業会社のWebマーケに転職｜隣の芝生は青い？は本当か は マイナビエンジニアブログ に最初に表示されました。

こんにちは、2022年新卒入社のT・Aです。 今回アドベントカレンダーに初挑戦させていただきます。 こんな方に向けて書きました！ Webマーケティング職・Web系職種に興味がある就活生さん 文系で営業以外の職種も探してみたいと思っている就活生さん ※就活や自己分析のヒントになればと思い本筋とズレた内容も多々書いていますので、必要に応じて読み飛ばしてくださいね。 はじめに 同じ部署の方に「え？」と思われてしまいそうなタイトルを付けてしまいました（笑） ですが、反骨精神的な意味ではなくて「こんな人もいるんだなー」と知ってもらうことで、読んでくれた方がもっと 自分の持っている可能性に気付いてくれたらいいな という、そんな思いを込めて書いています。 私は文系は営業職になるのが当たり前だとか、そういったイメージや固定概念で自分の将来を狭めないでほしいと思っています。実際にWebマーケターになれるなんて思ってもいなかった私ですが、まだまだ日々勉強中ながらWebマーケティングの仕事をさせていただいています。 Webマーケティングが合う、合わないはもちろんあると思うので、全ての人にWebマーケターの仕事をお勧めする気はありません。ですが、少しでも興味のある人にはぜひ挑戦してほしいですし、今は自分で気づけていないかもしれないけれど実は向いているという方もいらっしゃるかもしれません。そんな方の背中を押せるような記事になったらなと思っています。 また、私は地方出身です。Web系やIT系企業って東京ばっかりですよね。。 マイナビのWeb職やエンジニア職も現状は基本東京配属での採用になっていますが、 地方出身であることを不利に感じている方にも、大丈夫だよとエールを送りたいです。 皆さんが 自分にとって良い と思える就活ができるように、心から応援しています。 仕事内容について 一応Webマーケターという肩書で仕事をさせていただいている私ですが、Webマーケティングの業務範囲は実はかなり広いです。 その中でも、私の所属する部署ではどのような業務を行っているのかを先にご紹介しておきますね。 ※マイナビ内でも配属によって異なるので、一般論ではなく一例としてお考え下さい。 広告運用業務 マイナビとマイナビのグループ会社のWeb広告のインハウス運用（広告代理店に依頼せずに自分たちで運用）を行っています。皆さんもGoogleなどの検索エンジンやSNS上で日々広告を目にする機会があると思うのですが、マイナビの一部のサービスのそういったWeb広告やSNS広告を自分たちで管理して配信を行っています。 SEOサポート業務 SEO（検索エンジン最適化）対策とは、ネットで検索した時に自社サイトをなるべく上の方に表示させようとするものです。実は、上に出てくるサイトと下に出てくるサイトではクリックされる率がかなり変わってくるので、どの企業さんも一生懸命対策しています。対策といっても、これをやれば確実に上位で表示されるというようなものではないのが難しいところです。私の所属する部署では、こういった対策もなるべく社内で対応できるようにサポートしています。 Webマーケティングツールの活用支援業務 Webマーケティングでは、様々なツールを使います。例えば代表的な分析ツールの1つであるGoogleアナリティクスというものがありますが、最近操作方法もデータの収集方法も全く新しいものに変わってしまいました。そのため、○○のデータを見たいけれど操作方法が分からないなどの相談の対応を行ったり、設定や移行作業をお手伝いしたりしています。 その他 メイン業務は主に上記ですが、マイナビの社内ルールの整備や各マーケティングツールやアプリの管理なども行っています。特定のサービスではなく、マイナビ全社を横断的に見ている部署です。 他の部署だと、「マイナビ2025」や「マイナビバイト」など、サービスごとのマーケティングを担っている部署もあります。 大学時代のはなし ではここからは、私がWebマーケティングの道を選ぶに至った理由について、 大学時代のエピソードを（ちょっと多めに）交えながら書いていこうと思います。 ただ、Webマーケターは社内にたくさんいますし、私がその代表者になることは全く意図していません。なので、こんな人もいるんだという程度に眺めていただけたら嬉しいです。 1．大学と専攻 新卒でマイナビのマーケターになるには、大学でもマーケティングを学んでいないといけないの？と思う方もいるかもしれませんが、必ずしもそうではありません。 実際に私を含め、経営やマーケティング以外の分野を学んできた人もたくさんいます。 （反対に、マーケティングを学んできたという方はアピールチャンスです！） ちなみに私はとある地方の大学（文系）出身で、大学時代に学んでいたことは文化人類学や哲学です。 幼少期から英語が好きで英文科にも興味がありましたが、同じ大学（総合政策学部）の従妹が留学を経験していて、英語の勉強は大学以外でもできると知り、あえて哲学系の学科を選びました。大人になったら、哲学を学べる機会はそうそうないと思っていたからです。 実際はコロナで長期留学は断念しました。ちなみにその従妹は卒業後銀行員になり、転職後の今は英語の通訳の仕事をしています。良くも悪くも（？）大学の専攻と仕事は直結することばかりではないし、一度就職してもその後どうなるかはわかりません。だからこそ、自分の好奇心に目を向けて、広い視野を持って就活に取り組んでほしいなと私は思っています。 余談 学外では留学費用を稼ぐためにバイトをしていました。メディア系の会社に就職するのが夢だったので、高校卒業後すぐにライターのアルバイトを始めたのですが……あまりにも自分が無知であることを思い知りました。 単純に人のことをもっと知りたくて、大学では出会えないような様々な年齢・立場の人に出会って、人がどんな風に考え、悩み、生きているのかを知りたい！と思い、社会経験のため色々なバイトに挑戦しました。結果、4年間続けたものから1ヶ月程度の短期バイト含め20種類を超えました。これがマイナビを受けた理由にも繋がっていたりします。 自分では大した事ないと思うような些細なことも、他の人からしたら気になるポイントが詰まっていたり、よくよく深堀りしてみると自分自身を知るヒントになりますよ！ 2．"マーケティングっぽいこと"も全く経験がなかった マーケティングというと、通っていた大学の経営学部のイメージで数字を扱ったり、企業とコラボして商品企画したり、コンテストに出たりするイメージがありました。しかし、私はそんな経験も一切してきませんでした。 むしろ数学には少し苦手意識があったし、高額な費用を見ると免疫がなくてつい「怪しいのでは…？」と疑ってしまうような、そんな学生でした。 数字とは無縁だった大学生活 先述の通り、私は大学で文化人類学や哲学について学んでいました。 高校の科目で言うと、日本史、世界史や倫理、地理＋言語などが近いでしょうか。 こういった学問だと、数字を使う機会はほとんどありません。 たまに、人口や件数などがまとめられたごく簡単な表を目にする程度です。 あまり触れて来なかったこともあり、学生時代は数学に苦手意識もありました。 算数は大好きだったんですけどね。。。 高額な費用に疑いの目を持ってしまう 大学の専攻もあり国際的なテーマに関心が深かった私ですが、とある授業で衝撃を受けました。 それは、ユニセフの広告費です。（ユニセフを否定しているわけではないです！） 皆さんはユニセフという組織をご存知ですか？ ユニセフ（UNICEF：国連児童基金）とは、世界中の子どもたちの命と健康を守るために活動する国連機関で、保健、栄養、水と衛生、教育、暴力や搾取からの保護、HIV/エイズ、緊急支援、 アドボカシーなどの支援活動を実施している機関です。 （参考： https://www.unicef.or.jp/about_unicef/about_unicef.html ） 寄付を募るCMや広告、街頭での募金活動を目にしたことがある方も多いのではないでしょうか。詳しくは知らなくても、慈善団体というイメージはお持ちの方が多いと思います。 大学のとある授業で、ユニセフの支出のデータを目にする機会がありました。 ※ここでは、日本ユニセフ協会の最新の2022年のデータを引用させていただいています。 2022年度、当協会は、291億7,829万1,273円をユニセフ本部に拠出しました。これは、経常費用計335億1,440万9,434円の87.1%（みなさまからお寄せいただいた募金333億8,140万2,754円の87.4％*）にあたります。経常費用計の12.9%は、ユニセフ本部との協力協定に基づき、ユニセフ支援の輪を広げるための、国内での募金活動（領収書/寄付控除申請書類の印刷・発送費や振込/決済に係る費用などを含む）、広報・アドボカシー活動、国際協力に携わる人材の育成活動などに充てさせていただきました。そのうち、事務運営費および人件費は1.7%です。 ※ユニセフ本部との協定により、日本を含む各国のユニセフ協会は、各国のみなさまからお預かりしたユニセフ募金のうち最大25%の範囲内で、募金活動、広報・アドボカシー活動などの国内事業をおこなっております。これらの活動は、ユニセフ支援の輪を広げ、厳しい状況に置かれている世界の子どもたちへのより大きな支援につながっています。 ※ 2022年度　日本ユニセフ協会　収支報告概要 　「支出の部」より引用 いかがでしょうか。意外にも、広報関連の費用多くない…？と思った方もいらっしゃるのではないでしょうか。 正確に見ていくと違うのかもしれませんが、当時こういったものに疎かった私は「日本国内における募金・広報・アドボカシー活動のための事業費」の割合をそのまま単純計算してみました。 33,514,409,434円×12.9%≒4,323,358,817円 なんと、43億円超え、、 仮に最大範囲の25％がこの費用に充てられたとしたらどうでしょうか。 33,514,409,434円×25.0%≒8,378,602,359円 まさかの83億円超え、、 当時の私には、（今以上に）想像することさえ難しい額でした。 募金・寄付でできることとして、83円で緊急時においても、食事に混ぜて摂取することができるビタミンやミネラルが含まれた微量栄養素パウダー30袋が買えるようです。 （参考： https://www.unicef.or.jp/cooperate/coop_support.html ） 83円の寄付で栄養素パウダー30袋が買えるなら、100円でも寄付すれば誰かの役に立てているんじゃないかなという気持ちになれると思います。 しかし、「日本国内における募金・広報・アドボカシー活動のための事業費」のようないわゆる広告費に約43億円もの費用が費やされている事実を知ると、 この100円は本当に届けたい人に届くのだろうか？100円に託した私たちの気持ちはどこに消えてしまうのか？ 100円なんて寄付してもしなくても変わらないのではないか？広告費の一部になって消えるのではないか？ この巨額の費用を実際の支援に充てれば、もっと充実した支援ができてより多くの命を救えるのではないか？ と、当時の私は思ってしまいました。 普段大学でお金に関わる勉強はしてこなかったので、こんな見慣れない大金に対しての感覚が分からず、疑うような目を持ってしまっていました。 ちょうどその頃、悪質な広告によるトラブルなどがニュースで取り上げられていたこともあり、なんとなく広告が悪者であるかのような、そんな印象を抱いていました。 3．マーケティングに興味を持ち始めた出来事 数字に強いわけでもないし、投資の考え方の知識もなくて、広告に関してはなんだか胡散臭いとさえ思ってしまっていた私。そのまま行けば、普通は全く違う道に進んでいたと思います。 ですが、自己分析の中で過去に自分の感情が大きく動いた瞬間を改めて考えてみたとき、マーケティングに興味を持ちはじめるに至った出来事がいくつかありました。 もっと多くの人に届けたい 大学のオープンキャンパスを運営したり、ブログやSNSを更新したりする学生広報スタッフとして活動していました。その中で学生発信の広報誌制作にも携わっていました。 広報誌は半年間かけて作り上げ、6万部発行していただきました。 この広報誌を夏のオープンキャンパスで配布した際に「この広報誌を見て、この大学に入りたいという気持ちが強くなりました。」というお声をいただいた時はとても嬉しかったです。 しかしそれと同時に、こんなに一生懸命作ったけれどまず手に取って開いてもらえないとこの気持ちは届けられないんだなと、抱えていた広報誌の束を見て思いました。 その人が、もっとその人らしい人生を歩めるように こちらは4年間お世話になったWeb系ベンチャー企業でアルバイトしていた時のエピソードです。 そこはベンチャー企業ということもあり、正社員は中途でしか採用を行っていませんでした。 同期入社で一緒のチームで研修を受けていた新入社員の方々は、チームで唯一社会人経験がなかった私を励まし、支えてくださいました。また、前職がアパレルや動物園、美容師、事務など、自分の知らない世界を経験していて、私の目にはそんな方々がキラキラして映っていました。 私の入社当時、その会社は上場したての頃でした。既存社員・アルバイト含めた従業員数が200名程度に対し、月100人ペースで採用を行っていました。お察しの通り、入れ替わりがかなり激しい職場でした。 次第に私の同期入社の社員の方もどんどん辞めていってしまいました。自分はあんなにも助けてもらったのに、社会人経験が無いので仕事の悩みを聞くこともできないし、結局最後まで何も恩返しすることができなかった自分に不甲斐なさを感じていました。 私は学生のアルバイトの身分だったので、退職時には逆に気を遣わず正直な退職理由を教えてもらえたこともあり、その生々しさが当時の自分にはとても深く刺さりました。 皆さん20代で若くして何度も転職を繰り返している姿を見て、もっと自分に合った仕事に出会えていたら、あの人にはもっと違う人生があったかもしれない。仕事で苦しい思いをせずに済んだのかもしれないと考えていました。 4．人が知る「きっかけ」を作りたい！ 仲間と共に自分たちなりに愛を込めて作ったものを、もっと多くの人に届けたい 当時の自分には何もできなかったけれど、その人がその人らしく生きていけるように何かできないかな 自己分析の中でこんな風に自分の過去の感情を整理していて、その最初のステップとなる「きっかけ」を提供できる人になりたいと思うようになりました。 当たり前ですが、たとえどんなに良いものがあっても、本当に自分に合った仕事があっても、その存在を知るための何かきっかけがなければ何も始まりません。 また、ちょうどその頃に家電量販店でもアルバイトをしていたのですが、人は自分が思っていることを言語化できていないことも多くて、自分が口で欲しいと言っているものと、本当に求めているものは異なっていることも多々あるということを何となく感じていた頃でした。 就活を始める前はどちらかというとコンテンツの中身を作る仕事がしたいと思っていましたが、就活を始めて進めていく中で、良いコンテンツを どうやって届けるのか という部分に興味を持つようになりました。 接触機会を提供する、創り出す 自分で気づいていない部分に気づいてもらう そんな「きっかけ」を作れたり、そのきっかけがもしかしたら人の人生を変えることにもなるかもしれないなんて、マーケティングの仕事ってなんだか素敵だなと思うようになっていました。 5．マイナビが挑戦する機会をくれた それまでは自分には向いていないと思っていたので、就活時はWebマーケティングに関するスキルも経験も全くない状態でした。いざ、新卒で知識なし・未経験OKでWebマーケターを採用している企業を探してみるとほとんどありませんでした。 一部採用を行っている企業はありましたが、大学での経験やポートフォリオのようなものを求められるなど、私のような素人は門前払いなんだなとエントリーシートを見て悟りました。 そんな中で、チャンスをくれたのがマイナビでした。 マーケターを志して、大学時代に一生懸命努力してきた人に比べれば、「この子本当にマーケティングがやりたいのかな」と思われるのは仕方のないことだと思いましたが、チャンスがもらえること自体がとても貴重でありがたかったです。 面接では、大学で学んでいた文化人類学や哲学の本質は、Webマーケティングの「ユーザーファースト」的な考えと共通しているということや、3や4で書いたようなエピソードをもっと深堀りして話しました。 結果、縁あって内定をいただくことができ、今に至ります。 就活で大事にしてほしいこと 私自身の反省も踏まえて、就活で特に大事にしてほしいことが3つあります。 本当は自分が信頼のおける身近な人に相談してみてほしいのですが、入学時からコロナ禍の学生生活を送っていて気軽に相談できる友達・先輩との繋がりがない……という方もいると思います。 そのため、あくまでも一個人の意見ではありますが、参考になればと思い書かせていただきます。 人を頼ること 就活は自分1人で進めようとせず、とにかく人を頼ってください。 最初はESの書き方や適性検査なども全く分からないと思います。 先輩、大学のキャリアセンターの方、OBOGにどんどん相談した方が良いです。 （逆に色々な返答が返ってきて、混乱することもある・かもしれませんが、自分がこの人が言うなら信じられると思う人の言葉を信じてみてください。） そして自分が就活を終えたら、今度は同じように悩んでいる後輩を支えてあげてほしいです。 また、精神面で支えてくれた友人や家族にも感謝を伝えてくださいね。 自己分析 個人的には、就活する中で一番大事なのが自己分析だと考えています。 自己分析ができていないと、他人（面接官）に短い面接時間の中で自分を理解してもらえるよう説明することはできません。そればかりか、どの企業・職種にエントリーすれば良いのかさえ迷ってしまいます。 強みは弱みと表裏一体です。強みや良いところが無いという人は絶対にいません。自分の強みが分からない、という方はまずは人に頼って自己分析のやり方を聞くところから始めてみてください。 就活を経験した人は、恐らくこれだけで数時間は語れてしまうのではないかと思います。 それくらい自己分析は大事です。嘘じゃないですよ！（笑） 「お祈り」は決して自分が否定されたわけではないと理解すること 就活をする中で誰しも一度は経験するであろう、企業側からの不採用メール。いわゆる「お祈り」です。 もしその企業で内定がもらえたら、そこで働きたい！と思って、一生懸命ESを書いて、面接練習もしたのに、たった1通の事務的に送られたであろうお祈りメールが来るのは本当に悲しいし、辛いと思います。自己否定された気持ちになってしまうこともあると思います。 しかし、本質を理解して割り切ることが大切です。 企業側も自社に興味を持ってエントリーしてくれることは本当に嬉しいと思っているはずです。 しかし、企業側もその企業に合っていない方が入社してしまうと、結果的にお互い不幸になることを知っているので、お互いがWin‐Winになれそうな人を探しています。 就活は誰かとの勝負ではなくて、自分に合っている、つまり、強みを活かして活躍しやすい→良い評価を得られやすい→仕事や人生の充実感を得られやすい場所を探していく活動だと思います。 どうしてダメだったのか振り返って改善に繋げることは重要ですが、結果に一喜一憂するのではなく、むしろ先に教えてくれてありがと！！くらいの気持ちで構えるべしです。 おわりに 書いてみたら思いの外とても長くなってしまったので、久々に残業をして書きました。 なので、ここまで読んでくださって本当にありがとうございます。あなたのおかげで私の努力が報われました（笑） と、夜のテンションでちょっとふざけてみたのですが、私が伝えたかったことは自分の可能性に蓋をせずにどんどん挑戦してほしいということです。 よくよく考えてみていただきたいのですが、大学は4年、院まで進んでも6年程度です。たったそれだけの期間で、経験できなかったこと・知ることができなかったことなんてこの世の中に山ほどあるし、今の自分が持っているものだけを広げて、この後何十年も続く未来を決めてしまうのは本当にもったいないと思います。 特に文系の学生は理系の学生と比較すると、大学で学ぶことは実学ではない場合が多いと思います。就活では不利に感じてまうこともあるかもしれませんが、それだけ自分には選択肢があるとポジティブに捉えることもできます。一方で、理系の方も大学での専門分野が自分に合わないと感じているのなら、周りに合わせるのではなく一度外の世界にも視野を広げてみてから改めて考えてほしいです。 ここでは書き切れないこともたくさんありますが、この記事を通じてマイナビのWeb系職種・エンジニアに興味を持ってくれた方がいたら嬉しいですし、マイナビで働くことは考えていなくても、そんな皆さん 一人ひとりの可能性と向き合い、未来が見える世界をつくるため にマイナビ社員は働いているので、ぜひマイナビのサービスを活用していただけたら喜びます！ 自分自身ととことん向き合って、自分のペースで就活に取り組んでみてください。応援しています！！ 投稿 「広告なんて胡散臭くない？」と思っていた地方文系大学生の私がWebマーケティングの道を選んだわけ は マイナビエンジニアブログ に最初に表示されました。

はじめに はじめまして！H・Hです。 本記事はマイナビにマーケターとして中途入社した私の入社までの経緯についてお伝えできればと思います。 …正直マイナビのマーケター？というイメージを持たれている方もいらっしゃるかもしれません。この記事でマイナビのマーケティング職についてお伝えできるよう頑張ります！ 自己紹介 新卒で入社した会社で、3年ほどインハウスのマーケターをしていました。 マーケチームの立ち上げメンバーで、社内にマーケターの先輩・経験者がおらず、 とりあえず一通りのマーケ手法を片っ端からやってみる・・・という体制だったので、もっと学べる環境、ノウハウのある環境の中でスキルアップしたいと思い、転職活動を始めました。 入社までの流れ エージェント経由で求人を紹介してもらい、応募しました。 一次は人事の方とお話し、二次は実際に配属先となるデジ戦の各事業部のマーケの方と面接をしました。 マイナビは50以上のサービスを持っています。どこの事業部になるかは求人の段階では決まっていなかったため、二次面接は色々な事業部の方が来てくださり、5対1の面接でした（笑） 緊張はしましたが、圧迫面接というようなことは勿論なく（笑）、皆さんフラットにお話してくださり、私もきちんと自分の意向や今後のキャリアについてお話できました。 転職活動では複数社面接をおこなったのですが、マイナビの面接はどの面接でも「人を見てくれているな」というのが印象的でした。 これまでの経歴やスキルについては勿論ですが、「私の人となり、性格を見てくださっているな」「私に興味を持ってくれているな」と感じることが多く、実際そういった適正を見てくださり、私に合った事業部へ配属していただけたのかなと思います。 中途として初めての転職で、スキルや経験が重要視されるだろうな、と考えていましたが、 マイナビは「あなたと一緒に働くなら、どういったポジションがいいかな」と、対個人として考えてくれているのを感じたので、最終的に入社を決めました。 また、転職の理由がスキルアップでしたが、その点においてもマイナビはイーラーニングや定期的なセミナー等、研修制度がかなり充実しており、マーケティングという職種自体も、各事業部のマーケ部門が横断して1つになっているので、色々なスキルを持つ方から学べる環境が魅力的でした。 入社後のギャップ まず事業規模の大きさ、人の多さです。 取り扱うサービスによりけりだとは思いますが、私の部門は1,000人規模の事業部で、同じ月に入社だった営業職の中途社員も北海道から沖縄まで全国様々でした。 また、デジ戦自体も500人ほどのメンバーがおり、ワンフロアで全社員が収まっていた前職からするとかなり多く、まずそこに圧倒されました（笑） マーケの予算自体もとても大きく、広告一つとっても出来る選択肢がすごく多いので、とてもやりがいがあります。 その分責任も勿論大きくなりますが、自分のふとしたアイデアが大きなキャンペーンに活かされていくのは、マイナビ規模の大きな会社で働いているからこそできることだと思います。 また、そういった現場の意見を汲み取ってくれる上司、事業部があるという風通しの良さも、いい意味でギャップでした。 またオフィス環境についても、想像していたよりずっと良い環境でした。 マーケ職が在籍するデジ戦は新宿ミライナタワー勤務がメインですが、 新宿駅直結なので雨に濡れることもなく出社でき、デスクも一人あたりの座席が広く、フリーアドレスなので毎日好きな席で業務ができます。 場所によって机の色が違ったり、電動昇降デスクもあるので、立って仕事もできます。また、ミーティング用の防音ブースがあったり、集中ブースという個室スペースもあるので、人目を気にせず在宅のような感覚で仕事をすることもできます。 24、25階にフロアがあるので、外の景色を眺めながら仕事ができる窓際の席がお気に入りです。 リモートワークについては、部署にもよると思いますが、平均して週2程度で在宅勤務をおこなっています。 入社を考えている人へ 実はこのエンジニアブログ、入社前に選考の段階で見たことがあるんです（笑） その時はまだマーケ職の方の記事がなかったのですが、 今後エンジニアだけでなくマーケ職の記事も徐々に増えてくると思うので、 是非コーポレートだけでなくこちらもチェックしてほしいです！ 入社前は「大きな会社だから中々意見が通りづらかったり、新しいことにはあまり積極的でない文化があるのかな・・・」と考えたりもしていましたが、 そんな心配は杞憂で、特にデジ戦は事業部ができてから日が浅いこともあり、「まだまだ改善できることがあるよね」と、むしろ新しいことにとても感度の高い人が多いです。 過渡期であるからこそ、他社経験がある中途入社の新たな視点が必要とされていると思います。 是非ご入社お待ちしております！ 投稿 【2023年入社の中途社員が語る】マイナビのマーケティング職 は マイナビエンジニアブログ に最初に表示されました。

はじめに 各広告媒体の配信方法（キャンペーン）の近況 Meta広告の"ASC"（Advantage+ ショッピングキャンペーン）、TikTok広告の"SPC"（スマートパフォーマンスキャンペーン）、Google広告の"P-MAX"のようにターゲティング・配信面などの細かい設定が必要とせず、 ブロードなどで広くリーチをとり細かい調整の部分を機械学習に任せる配信方法 （キャンペーン）が流行となっています。 広告の運用幅が少なくなっていく現状では、 広告運用担当のレベルが均一化 され競合と広告効果で差をつけるのが難しくなってきております。そのため、相対的にクリエイティブの重要性が高まってきており、1つのクリエイティブで大幅にCPAを改善するような事例（当たりクリエイティブ）も多く散見されるようになってきております。 競合のクリエイティブの収集の重要性 当たりクリエイティブの作成するために押さえておきたいのが、 「競合の出稿クリエイティブ」 の調査です。 複数の競合が長期的かつ同一フォーマット・同一訴求のクリエイティブが多数入稿されている場合は、その業界内の当たりクリエイティブである可能性が高いです。競合がどのようなレイアウト・デザイン・訴求・フォーマットを使用しているかを分析することでその業界内のクリエイティブトレンドを把握することができ、それを自社クリエイティブに活かすことで最新かつ競争力のあるものにすることができます。 他社との差別化をはかるようなクリエイティブを作成する際にもそもそも他社クリエイティブを知っていなければ、競合他社に対抗できるような独自のものを作成することは難しいでしょう。 競合クリエイティブの調査方法 競合クリエイティブの調査について目当ての競合のクリエイティブがでるまでとにかく更新（F5）連打！！！！！というのは非効率のため、ここでは効率的な調査方法について解説していきます。 ①Meta広告ライブラリ Meta広告の配信先である Facebook・Instagram などで掲載されているクリエイティブを検索することができます。現在掲載中となっている広告ならすべて検索することが可能です。クリエイティブの内容（画像・訴求文）だけでなく、掲載開始日・配信面・リンク先などの情報も確認できます。 使い方は単純で、広告ライブラリにアクセスし、広告カテゴリを"すべての広告"を選択肢、検索窓にキーワードまたは広告主名入力し検索するだけです。 「Facebook広告ライブラリ」へのリンクはこちらから ➁Tiktok Creative Center TikTok 上に配信している動画クリエイティブを検索することができます。検索できるものは広告主の許可を得たものに限られているため、すべてのクリエイティブが表示されているわけではないので注意が必要です。 使い方としては、検索窓にブランド名・関連キーワードを入力するだけです。 確認できるものとしては動画の内容だけでなく、その動画のいいね数やコメント数、毎秒ごとのユーザーのインタラクト数などかなり詳細な部分についても確認することができます。 「Tiktok Creative Center」へのリンクはこちらから ➂広告の透明性について Google広告で配信しているクリエイティブも検索することが可能です。広告主の適格性確認を完了していない広告主のクリエイティブは表示されないので注意が必要です。 "Meta広告ライブラリ"・"Tiktok Creative Center"では関連キーワードでも検索することができましたが、"広告の透明性について"は 広告主名のみ でしか検索することができません。 また、リスティング面・ディスプレイ面なども含めての調査が可能ですが、他の調査ツールのようにリンク先URLについては表示することができません。 掲載クリエイティブからも調査が可能です。左赤枠の三つの点から"マイアドセンター"を開き、右赤枠部分の"他の広告を表示"をクリックしてアクセスすることができます。 「広告の透明性について」のリンクはこちらから おわりに Yahoo!広告・LINE広告 などについては残念ながら網羅できておりません。これらの媒体については私が知る限り、競合のページにアクセスしてクッキーを付与してもらい該当の配信面で更新連打で自力で探すか、有料の収集ツールを使用するかに限られてきます。 今後、前述のASC・P-MAXの発展により ターゲティング・配信面の選定についてもすべて媒体に任せる というのが最適解にとなる時代がくるかもしれません。そういった時代がきたときにクリエイティブについてはまだまだ人の介在が必要な以上、クリエイティブの広告効果に対する寄与度は今後より高まってくるかと思います。 広告の競合調査方法については以上になりますが、より良いクリエイティブ制作に役立てて頂けたら幸いです。 投稿 競合のクリエイティブを覗いてみよう！競合出稿クリエイティブ調査方法 は マイナビエンジニアブログ に最初に表示されました。

はじめに はじめまして！R.Sです！ 今回記事を書くにあたって、何を書こうか、、、とかなり悩んだのですが、 前職のWEB広告代理店でも経験した 「WEB広告の検証方法」 について記事にしようと思います。 個人的にデジタルマーケティングはPDCAを回せる・回しやすいことが一番のポイントだと思っており、正しく検証を行わないとCheckが機能しなくなってしまうので、その利点を損してしまいます！ 代理店時代は毎週毎週検証設計を考え、施策を実施し、集計をしていました！ 長年マーケティングをやってきた方はもう知っているよ、、というお話ばかりになるとは思いますが、まだデジタルマーケティングをはじめたばかり！という方であれば少しは参考になるかと思います！ 検証方法には2パターンある 検証方法は大きく分けて2パターン存在しています。 まずはそれぞれの概要とメリット・デメリットを説明します。 ①AB比較 AB比較とは、 複数のものを同時並行で検証できる方法 です。 例えば、新しいクリエイティブと既存のクリエイティブを同時並行で配信し、どちらの成果が良いか確認することはAB比較となります。 メリット ◦複数のパターンを同時並行で検証できる ◦並行配信のため、リスクが分散され、（前後比較と比べると）大幅な成果悪化は起きにくい ◦同時並行で配信ができるため、時期的影響（トレンド影響）に左右されず判断が可能 デメリット ◦並行配信のため、そもそもの配信量が少ないと配信量の分散により学習が足りなくなる可能性あり 実際に数値集計をするとこんな感じ　↓ 新規追加したクリエイティブと既存クリエイティブを同時並行で配信した結果、新規追加したクリエイティブのほうが全指標で成果が良かった。とわかりますね。 ②前後比較 前後比較とは、 施策を実施する前後で成果がどのように変動したかを検証する方法 です。 例えば、ディスプレイ広告で今までリターゲティングで配信していたが、新しいターゲティングを追加、追加したターゲティングを続けるべきか判断したいとなったときは前後比較になります。 余談ですが、AB比較でターゲット別の成果を見て判断すればよいのでは、、？と思った方は△黄色信号△です！理由は以下の通りです。 最もCVRが高いリターゲティングに成果が勝るターゲティングはなかなかないので、単純にAB比較をしてしまうと新しいターゲティングは停止になる可能性が高い 新しいターゲティングで流入したユーザーがリターゲティングリストに入って、リターゲティングの成果改善に影響を与えることもある →AB比較だけで追加したターゲティングの成果を見るのではなく、前後比較で媒体全体で成果が改善したか見る必要があります（商材によるところもあるかなと思います） メリット ◦同時並行配信ではないので、配信量が分散されない ◦AB比較が仕様上や正確な検証を行う上でできない場合も前後比較なら実施できる可能性が高い（前後比較には制約がない） デメリット ◦同時並行配信のようにリスクが分散されないため、大幅な成果悪化が起こる可能性がある ◦検証前期間と後期間に外部要因の変化があった場合、検証結果に影響を受けてしまう（トレンド影響に左右される） AB比較と前後比較のメリット・デメリットを整理してみると、成果悪化が起こる可能性があるうえに正しい検証ができないなど前後比較のデメリットがかなり大きいと感じられるのではないでしょうか。 特に外部要因により正しい検証ができないという点は大きなデメリットですが、 こちらは 「ゼロ点補正」 を使うことによって可能な限り排除することができます。 ゼロ点補正とは？ ゼロ点補正とは、 前後比較する際に発生してしまうトレンド影響を可能な限り排除する方法 です。 具体的には、検証前後期間で施策や大きな入札調整を行わないキャンペーンや媒体を残し、前後比較を実施、そのキャンペーン・媒体の検証同期間での変動幅をトレンド影響によるものだと見立てる方法です。 実際に数値集計をするとこんな感じ　↓ ※テストキャンペーン＝施策実施キャンペーン ※コントロールキャンペーン＝施策を実施していないキャンペーン テストキャンペーンだけだと施策によって成果が悪化したのか不明ですが、コントロールキャンペーンの同期間の変動がほとんどないことを加味すると、施策による成果悪化が起こった可能性が高いと判断できます。 このため、前後比較での検証を実施する場合は、何も変更をしないキャンペーンもしくは媒体を残しておく必要があります。 また、コントロールに適したキャンペーン・媒体としては、検証するキャンペーン・媒体に類似したキャンペーン・媒体であることが最適です。（ディスプレイならディスプレイ、検索なら検索広告内でコントロールを残しておきましょう） 類似したものがない場合は、検索広告の指名キャンペーンであれば、一番トレンド影響を受けやすいのでそちらをコントロールキャンペーンにすることで外部影響を除外できる可能性が高いです。 結局どの検証方法で検証するのがよいの？ 長々と説明してきましたが、仕様上や判断する上で問題ない場合は、成果棄損のリスクが少なかったり、同時並行による判断がしやすいため、 AB比較 で検証するのが最善です。 また、Facebook・Googleなど媒体公式のAB比較ツールが存在している媒体は、 公式ツールを使った検証 をするのがおすすめです。特にGoogleの「下書きとテスト」機能はキャンペーンを複製して、Cookieを分割して配信検証することができるので、キャンペーン全体の変更でもリスクなく、AB比較できます。 参考：Google広告「検索キャンペーンとディスプレイ キャンペーンの下書きについて」 https://support.google.com/google-ads/answer/6318732?sjid=574764951660312776-AP%EF%BC%89 AB比較が仕様上できない・AB比較だけでは正しい判断ができない場合は、ゼロ点補正を利用した前後比較で検証してみてください。 その他検証する上で細かいけど大事なこと 検証方法・期間をあらかじめ決めた上で検証を行う AB比較の場合コントロールは必要ないが、前後比較はコントロールが必要。 検証期間に年末年始やGWなどの大きな外部影響がある場合正しい検証ができないため。 検証する際に変更する要素は可能な限り1つにする 複数の変更があった場合、どれが成果に1番寄与したか判断できないため。 学習期間・検証期間ともに1~2週間は必ず設定する ほとんどの媒体が機械学習で配信されているので、変更を加えてから最大2週間は学習期間で配信が安定しないことがあるため。 検証期間も1~2週間設定することで、曜日傾向などを平均化できるため。 最後に 以上になります！ ご存じの方は長々と初歩的な文章ですみません！ 初知りの方は、何かの検証をする際にこちらの記事を思い出して検証設計を立ててもらえるとうれしいです。 最後まで読んでいただきありがとうございました！ 投稿 デジタルマーケティング初心者向け！WEB広告の効果検証の仕方 は マイナビエンジニアブログ に最初に表示されました。