セッション概要 タイトル 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広告の効果検証の仕方 は マイナビエンジニアブログ に最初に表示されました。

１．はじめに 本記事はマイナビ社内でRPAの活用を進める部署で1年間働いてみて思ったあれこれを社会人2年目が書いたものになっています！ そもそもRPAとは！ 記事のタイトルにも付いている「RPA」という言葉ですが、そもそもRPAとは"Robotic Process Automation"の略となります。 それぞれの単語を訳したらそのままなのですが、 "ロボットによる業務の自動化" になります。 基本的に業務改善の際に組み込まれますが、定型業務を肩代わりすること(マニュアル通りの動き)が最も得意になります。 タイトルから「マイナビってロボットいじるんだ…？」って思った方、申し訳ございません…。 一般的にイメージされるドラ〇もんやガン〇ム、ペッ〇ー君のようなものではなく、ソフトウェア上のロボットのことをここでは指しております…！ ２．ロボット君と仲良くなるためには(RPA開発/導入の流れ) そんなRPAを使って多くの企業は業務の自動化をしています。 マイナビも例に漏れず、RPAを使った業務の自動化を行っているのでどのようにRPA活用しているか、 もとい、 どうやってロボットと仲良くしているか を紹介していきます！ ①ロボット君を知る。～RPAの詳細～ 仲良くなるためにはもう少しロボット君のことを知らないといけないなと考えております。 まずは RPAの特徴 を深堀していきます！ RPAの特徴 単純作業/反復作業が得意 ◦その作業自体は単調なものの、1回の作業に時間がかかってしまうのだったり、逆に1回の作業自体は簡単なものの、頻度が異常に多いものを肩代わりすることが多い。 条件が一定でないもの、何かを生み出すことは苦手 ◦都度条件が変わってしまうものや文章生成等の融通を利かす必要のある工程は苦手としている。 　　→マニュアルがあるような定型業務を任せていくのが一番有効的な使い方だと思われます！ 併せて導入によるメリット/デメリットも触れさせていただきます！ 導入するメリット RPAが稼働している間、他の作業への余力が生まれる 人為的ミスの削減が期待できる 人材不足や勤務時間外での対応ができる 　　→活用次第では時間や金額等が大幅にコストカットできます！ 導入するデメリット 通常のプログラミング言語に比べ開発担当や保守担当がまだ多くない RPAツールも有償のものが多く、基本的に高めである 　　→初期導入の敷居がどうしても高めなハードルになってしまいがちな印象です…。 ➁業務を丁寧に教えてより細かな指示を行う。～要件定義と開発～ 続いてロボット君は最初何も知らないので丁寧に業務を教えていく必要があります…！ そのためここでは要件定義、もとい業務の洗い出しとそれに基づくRPAの開発についてお話しします！ RPAに限らず 業務改善の肝 は 業務の背景(目的や経緯や関係人数等)理解 　　→そもそもRPAや他の業務改善ツールを本当に使う必要があるかの見極めに差が出ることになると思います…！ 属人化していない業務フローの洗い出し 　　→細かく整理することでRPAや他の業務改善ツールを導入しやすくなる上に、それを機に引き継ぎが行いやすくなるという利点があります！ 効果の有無よりも小さい改善から 　　→改善は少しずつ行っていくようにしていくと良いとされています！ の3点が挙げられると思います。 特に3点目は導入時に特に意識するべきことだと考えています。 この意識で、目先の大きい改善目標に対し効果を過期待することがなくなり、加えて現場も徐々に慣れることで別の改善案が産まれるかもしれないからです。 業務の背景はおおよそ現場にあり、現場で新たに気付き、そして解決できることが一番早く大きく効果があります。 また開発時に注意する点として、 特徴にも挙げていた通りロボット君は指示した内容を従順にこなすため、型や条件の定義を特に意識する必要があり、この工程ではある程度のプログラミング知識やアルゴリズム組立の経験が必要になると思われます。 ➂向いている仕事を振って適度に様子を見る～運用と保守～ ここでは②で開発したRPAの運用とその保守についてお話しします！ ロボット君に仕事を任せるときの注意点や、任せた後のケアにあたりますね。 ここまで来たらこれといって難しいことを考えずに運用していけそうです。 ただ、実際は現場でRPAを扱う際はいくつか注意するべき項目があります。 以下、RPAに関わらず業務改善ツール導入時の 現場での適切な運用フローの項目 を挙げてみました。 承認や購入等の決済が発生するところは人が担当する トラブルが起きた時の対応方法を周知、もしくはマニュアル化しておく 定期的な効果測定を行う 特に3点目の「定期的な効果測定を行う」に関しては、費用対効果が分かるだけではなく、良い効果が出た理由が明確になれば他のものにも転用ができますし、 その逆で悪い効果が出た理由も整理できれば業務改善の目的としては十分に効果を発揮することになると思われます。 (もちろんうまくいかなかった箇所は保守してさらに改善していきます) "効果測定をしなくとも効果はあるが、効果測定をすることでより効果がでる" といった認識で構わないと思います。 また1点目の内容にも触れますが、 ロボット君は責任取ることができないため実行時の責任者の所在は明確にしておくべき、予期せぬ動きになってしまうため適切な権限を持たせるべき…等細かく触れれば運用フローで検討することは多くなります。 …といったように、 諸々の手順を踏めばロボット君と仲良く出来るのかな、と考えております！ 3.RPA導入事例紹介 以上のようにロボット君と仲良くすると、色々なところで活躍をしてくれます！ ここでは一般的な事例やマイナビでの事例を紹介させていただきます！ 一般的なRPA 人事部での給与計算 概要 　従業員の勤怠状況を紙ベースで行っていて、労働時間やボーナスの計算に手こずってしまっていた…。 結果 勤怠状況の読み込みをロボットに任せ、計算まで自動化させました。 それにより時間と人件費のコスト削減やミスの減少に繋がり、人事部の業務効率化に貢献できました！ 通販サイトの在庫数の更新作業の自動化 概要 　通販サイトでの在庫数の更新作業及び、受注入力までを手作業で行っていてかなりの時間を要していました…。 結果 手作業では1日1回しか行うことのできなかった作業をロボットに任せ、1時間置きに更新するように自動化させました。 作業者の負担軽減に加え、更新頻度の向上により売上向上にも繋がりました！ マイナビのRPA アンケート回答を自動でPDF化・格納 作業・確認にかかる時間を削減 概要 　人材紹介サービス（医療福祉領域）において、クライアント様からのアンケート回答をPDF化し、その後に営業で扱うシステムへ格納という一連の処理を手動で行っていました…。 結果 データのPDF化とシステムへの格納を自動で行うようにロボットに任せました。 自動化することによって担当者は別の作業を行えるようになり、また時間でみると1回あたりの当作業時間が 5.0時間 → 0.5時間 も削減できました！ 4.RPA界隈の流れとマイナビでの取り組み ここまでロボット君と仲良くなる、という名目で進めて参りましたが最後に今後のRPAの活用や界隈の流れについて触れていきたいと思います。 ハイパーオートメーションな流れ RPAは人と同じ画面操作(UIベース)も得意だったりするのですが、それだけだとシステム間のデータの受け渡し等がスムーズにできません。 そのため、システム側にAPIを設け、そのAPIやiPaaS製品を絡めた自動化をして"ハイパーオートメーションにしていく"流れが最近はあります！ ハイパーオートメーションとは、RPAよりも自動化する業務の幅がもっと広いような…いわば 最上級の自動化 のようなものになります…！ 生成AI、OCR技術との連携な流れ RPAの特徴でも触れていた通り、RPA自体は指定した動きはちゃんと行ってくれます。 しかし、チャットボットのようなやり取りや予想外のエラーに対してはうまく対応できず止まってしまうことがしばしば起こります。 しかし、最近では生成AIの技術やOCR技術の進化が目まぐるしく、これらと組み合わせることでこれまではできていなかったマニュアル外の動きも自由に行ってくれそう…！と期待されていたりします！ 市民開発な流れ RPA導入時のデメリットを払拭するような流れも最近はあります！ 題目の"市民開発"というのは言わば自炊のようなものでして…、詳しくいうと自動化を求めてる方が自分自身でどんどん自動化していくことです。 現状のRPA開発はある程度プログラミングの知識やITスキルが必要になる場合が多い(まるで調理を専門としているシェフが料理を出すような)ですが、様々なサービスやライセンス形態がリリースされている影響で初期導入の敷居は下がっている傾向があると思われます！ おわりに ここまでマイナビでは「RPAを使って主に業務自動化している」ような書き方をしてしまいましたが、他にもPythonやGAS,BIツールの活用も行い日々の業務の改善を行っています。 併せて僕が所属している部署でのRPA以外の自動化例も以下紹介させていただきます。 エンジニアブログの更新分をGmailに通知してみた～ 投稿 【RPA】ロボットと仲良くなる方法3選。 は マイナビエンジニアブログ に最初に表示されました。

はじめに エンジニアとしてお仕事をしていると耳にする機会も多い言葉”SRE”　 SREとは　Site Reliability Engineering：サイト信頼性エンジニアリングのことです。 ……つまりなんだ？というわけで今回はSREについてお勉強したのでまとめてみました。 使用した書籍 サイトリアイラビリティワークブック ――SREの実践方法 SRE サイトリライアビリティエンジニアリング ――Googleの信頼性を支えるエンジニアリングチーム SREを学ぶ理由 現状の運用には一般的な答えがない状態です。 ベストプラクティスだ！と思っていても状況や環境に依存している場合が多いです。 運用チーム自体の運用も宙に浮いてしまってしまっているようです。 その状態ではソフトウェアシステムをスケーラブルで信頼性高く効率的に構築・運用することは難しいです。 SREという考えを取り入れて実施して行くことで上記のような問題を解決していきたいし現状を超えていきたいよね！という感じです。 SREとは SRE グーグルのエンジニアリング担当バイスプレジデントのBen Treynor Slossが作った言葉であり、仕事のロール・定義です。 特に「標準化」「自動化」に目を向けることでサイトの信頼性を上げていこうよ！という考え方となります。 SREの背景 SREにおいて主要な7つの原理を説明していきます。 ①運用はソフトウェアの問題 運用をうまく行えるかどうかはソフトウェアの問題です。 ソフトウェアの問題解決にはソフトウェアエンジニアリングでアプローチします。 ②サービスレベル目標（SLO）にて管理するべし SLOとは、サービスレベル指標（SLI）で達成させたい目標のことです。 SLIとは、サービスの品質を測るものです。 例を挙げます。 SLI：サーバの稼働率 SLO：サーバの稼働率が99.9%以上 サーバの稼働率（SLI）が99.9%以上（SLOで定めた目標値）であればSLOを満たしているといえます。 もしサーバの稼働率が80％だった場合はSLO違反となります。 この際は誰かを責めるのではなく、全員でSLO達成に向けて取り組んでいきます。 ちなみに、サービス品質保証 / サービスレベル合意書（SLA）はサービスを提供する事業者がサービスの契約者とかわすSLOについての合意のことを言います。 ③トイルはなるべく減らしたい SREにおけるトイルとは、手作業で繰り返し行われる運用タスクを指しています。 このようなタスクはマシンにて自動化させることが可能ですので、「マシンにお願いして問題ない作業だったらどんどん自動化させちゃいたい」というのがSREの信念になります。 組織の中での役割にこだわらず、同じツールを使用することは重要と考えます。 状況によって振る舞いが異なると、サービス管理として△であると感じるのは自然な感覚かと思います。 また、1つに絞ることでツール改善の労力も削減できるかと思います。 ④自動化できるトイル、出来ないトイル トイルに費やすことができる時間に50%という絶対的な制限を設けています。 SREでは、自動化できる事は自動化し、自動化出来ないことは残します。 自動化出来ないトイルに支配されることはありません。 ⑤失敗コストdownによって開発速度up SREの関与による主な利点の1つに「プロダクト開発のアウトプットの向上」があります。 ※プロダクト開発：仕様書に沿って開発していくシステム開発とは異なるもので、目的達成のため様々な手段を用いて開発していくことをプロダクト開発といいます。 「プロダクト開発のアウトプットの向上」がなぜできるのかというと、失敗のコストを削減することができるからです。 失敗（=問題発見）はプロジェクトの後ろになればなるほど対応が大変です。 つまり、失敗コストが高くつきます。 上記で上げてきたトイルの削減や障害へのリカバリーをはやくすることで、エンジニアがプロダクト開発にさける時間が増えます。 さける時間が増えると、失敗の発見も早くすることができるので失敗コストを避けることができます。 失敗コストが下がるとプロダクト開発の速度も向上しますので、会社全体としての利益も向上すると考えられます。 ⑥アプリ開発とプロダクションの境界をぼかす アプリケーション開発者とプロダクション（プログラマーと運用者とも言う）が完全に分離していると非生産的です。 生産性もそうですが、責任の分離がされたり、「運用ってコストセンターだよね～…」といった心無い言葉が出てきてしまって組織内での評価が偏ってしまう危険があります。 ※コストセンター：コストはかかり利益は生まないものを言います。 プロダクト開発チームの全員が、該当のシステムの全体像を把握していると効率が良くなります。 反対に、どこか1つのコンポーネントをどこかが独占してしまう事は避けたいです。 想定されるコンポーネントは以下です。 フロントエンド バックエンド ライブラリ ストレージ カーネル 物理マシン 境界をぼかすことで可能となる範囲が広がります。 例えばSREチームがJavascriptを、プロダクト開発者がカーネルの修正を行うことで知識と権限が広がり成せることが増えると考えられます。 ⑦みんなでおそろいのツールを仲良く使いましょう DevOpsにもつながってくる話かと思います。 組織の中での役割にこだわらず、同じツールを使用することは重要と考えます。 状況によって振る舞いが異なると、サービス管理として△であると感じるのは自然な感覚かと思います。 また、1つに絞ることでツール改善の労力も削減できるかと思います。 感想 お仕事の進め方として、かなり定義づけられていると感じました。 SREの考えのもとチームが動くことで、かなり効率が上げられるのではと考えます。 今回使用した本では、ケーススタディなども細かく載っておりかなり実践的です。 サイトリアイラビリティワークブック ――SREの実践方法 実際我々のチームでは、トイルの撲滅とポストモーテムの活用に挑戦しています。 ぜひ、多くの方にSREの考え方に触れていただきたいなと思いました。 投稿 【学習メモ】SREについて は マイナビエンジニアブログ に最初に表示されました。

はじめに 去年の10月に現場に配属されてから、はや1年間が経っていました。(また一つ歳をとってしまいました、、) 1年たった記念に、去年の配属直後に書いていたコードを見返してみました。 気になったところと、改善点をまとめてみます。 まとめてみた (1) 無駄な改行など <tr> <th style="width: 10rem;">ID</th> <td style="width: 20rem;">{{$sampleArray[0]->id}}</td> </tr> 良くないところ 全体的に無駄な改行やスペースなどが目立ちます。 また、var_dump(javascriptで言うところのconsole.log的な)の消し忘れもちらちら。 修正点、対策 commitやプルリク作成時にしっかり差分をチェックすれば大方防げるかなと思います。 またformatterの利用も有効だと思います(改行とかは消えないかも？) (2) 命名が適当 $sample_item = [1, 2, 3]; 良くないところ 配列なのに変数名からそれが分からない 修正点、対策 配列の場合は複数形にしたり、sample_arrayとかにして、配列であることが分かるようにする。 配列の変数名に限らず、いろんな変数や関数の命名が雑でした。 リーダブルコードとかでも散々書かれていることですが、他の人が読んでわかりやすいように、変数や関数の命名には気を配っていきたいです。 ちなみに、変数名の後ろにくる複数形のsとか_arrayをサフィックスっていうらしいです。 (3) 肥大した関数 $sample_array = [1, 2, 3]; $sample_value1 = sampleFunc(); $sample_value2 = 0; foreach($sample_array as sample) { $sample_value2 += sample * $sample_value1 } 以下何十行、何百行と続く、、 良くないところ 適切な粒度で関数の切り出しが行われておらず、大きくて見通しの悪いコードとなっている 修正点、対策 全体として見通しの良いコードとなるように、適切な粒度で関数の切り分けをおこなっていく。 適切な粒度の頃合いが難しいですが、明らかに肥大しすぎてた関数が多く見受けられます。 前は関数を切り分けるのは主に処理の共通化のためだと考えていたのですが、例え一箇所でしか使われない関数でも、関心を分離して処理の大まかな流れを掴みやすくするためにも関数を切り分けていくべきだと思っています。 (4) PHPDoc /** * サンプル * @param $sample_param1 * @param $sample_param2 */ public function sampleFunc($sample_param1, $sample_param2) { 良くないところ PHPDocが適当 修正点、対策 動的型付け言語のPHPですが、PHPDocというフォーマットでコメントを書くことによって、クラスやメソッドの引数や返り値の型などを示すことができます。 あくまでコメントなのでこの型を守らなくてもエラーなどは起こりませんが、適切に記述することによってエディタの補完が働いたり、他の開発者が見たときにコードの理解が容易になります。 (2)の変数名の命名と共通しますが、他の人にとって読みやすいコードという意識が足りなく、他の関数でもなんか書いてるから適当に書いとくかーって感じでやってました PHPやPythonなどの動的型付け言語に後付けで型に関する情報を追記する際は、それをどこまでやるかはプロジェクト次第だと思います。 開発のスピード感とのトレードオフになってしまい難しい問題かもしれませんが、PHPDocをちょっと丁寧に書くくらいならそこまで手間じゃないと思うので、今後はしっかり書いていきたいなと思っています。 (5) gitの使い方が雑 sampleCommit1: 一通り完成 sampleCommit2: バグ修正 良くないところ commitの粒度が大きすぎる(そこそこ規模の大きなプルリクなのに、一回のcommitにまとめてる)、コミットメッセージが適当、不必要なcommitが混ざっているなど 修正点、対策 作業の途中ではcommitせずに、完成した段階で全ての変更を一つのcommitにまとめていました。 ある程度規模の大きいプルリクの場合、適切な粒度でcommitして行った方が良いのかなと思います。 また、commitのメッセージについても、change、addなどの接頭語を使ったりしてそのcommitがどういった変更なのかが分かりやすいようにできると良いと思います。 (6) パフォーマンスに対する意識(N+1問題などなど) $prefectures = getPrefectures(); foreach($prefectures as $prefecture) { $cities = getCities($prefecture->prefId); $prefecture->cities = $cities } 良くないところ 上の例のようにfor文の中で都度sql叩くような処理をした結果パフォーマンスが悪くなるのをN+1問題と言います。 とりあえず動けば良いと考えて、こういったパフォーマンスに対する意識が低いコードが散見されます。 修正点、対策 sql頑張って書いてワンクエリにするか、hasManyとかのリレーションを宣言してwithとかでとってくるかすればN+1問題解決できます。 実装時はあまり違いが分からなくても、レコード数の増加によって後から致命的な問題になってくることが多々あるので、N+1問題とかは解決しておいた方が良さそうです。 場合によってはさらなるチューニングが必要になってくることもあると思いますが、開発速度や可読性とのトレードオフになってくることもあるので、難しいところですね、、、 (7)ほとんどすべてのdb操作の記述をクエリビルダで行っている $query = sampleTable1::query() 　->leftjoin('sampleTable2', 'sample_column', '=', sampleTable2.sample_column') 良くないところ ほとんどすべてのdb操作をクエリビルダで行っていた 修正点、対策 Laravelではdbの操作を行うにあたって、主にsqlの記述に近いクエリビルダで書く方法とO/RマッパーであるEloquentを使う方法があります。 なんとなく理解しやすかったのと既存のコードがクエリビルダで書かれているものが多かったのでクエリビルダをつかいがちでした。 どちらもメリットデメリットあるので、一概にEloquentを使えば良いという訳でもないと思いますが、Eloquentを使った方がすっきりとした記述で済みそうな箇所が結構ありました。 Eloquentに限らず、Laravelのようなフレームワークには知らないだけでかなり色々な機能が備わっています。 とりあえず何かしらの方法である実装ができるようになると、その方法で他の同様の実装も済ませてしまいがちですが、もっと便利な方法、推奨されている方法がないか常日頃から意識して調査していきたいですね、、！ (8)場当たり的な対応で凌ごうとする $sample = sampleFunction1() // 何故か1秒待たないといけない sleep(1) 良くないところ 上の例はちょっと極端ですが、何か実装で詰まった時に問題の根本を調査・理解しようとせずに、既存の実装の変更を最小にして場当たり的な対応のコードを追加していく形で対応しています。 修正点、対策 一番の解決策は、分からないところを他のメンバーに聞くことだと思います。 大抵こういう場当たり的な対応は後々問題になります、、 後々対応すると実装内容の理解から始める必要があり余計に時間がかかってしまうので、最初に実装して詰まった段階で詳しそうな方に聞くのが一番です！ また、レビューの段階でこういったことを質問して結果大幅な変更が必要になることがわかると実装者も辛いですし、レビュワーもなんか申し訳なくなるので、出来るだけ早い段階で聞いた方が良いし、もっといえば聞ける関係を普段から作れてると良いのかなと思います！ 感想 全体的な傾向として、知識と意識が足りなかったです。 そもそもどのようなコードが良いのかが分からなかったですし、N+1問題っていう名前すら知らなかったです。 また良い書き方を知っているところにしても、可読性やパフォーマンスの重要度があまり肌感として持っていないが故に、目の前の仕事を早く終わらせることに夢中になって妥協をしてしまうことが多かったです。 もちろんまだまだ勉強中の身ですが、一年前よりは知識の面でも感覚の面でもマシなコードを書けてるなと思いました。 願わくは、来年の今頃に今年の自分のコードを見て、たくさん改善点を見つけられればと思います。 投稿 一年前の自分のコードを見てみる は マイナビエンジニアブログ に最初に表示されました。

はじめに 皆さん、こんにちは！ 開発系の部署に配属された、2023 入社新卒 M.K です。 日々、フロントエンジニアとして業務に取り組んでおります。そこで、私がどのような経緯でエンジニアになったのか経験も踏まえてご紹介できればと思いますので、最後まで目を通して頂ければ幸いです。 学生時代 －概要－ まずは、学生時代について少し紹介させてください。 私は、関西の大学を卒業し、大学時代は自動車のエンジンなどの機械について学び最終的には流体工学に関係した研究を行っていました。 初めは、自動車関係のエンジニアになりたいと思い大学に入ったのですが、気づいたらなぜか IT エンジニアになっていました。エンジニア違いですね（笑） 大学の授業で、少しだけ C 言語を学んだのですが全く理解できず、恐らく成績は下から数えた方が早いのでは？って感じでした。（いや、恐らくではなくて、事実ですね。。。） そんな私がエンジニアになろうとした原点は、大学時代の「ベトナムの IT 企業でのインターンシップ」でした。 なぜベトナムの IT 企業かというと、特に理由とかはなくて、まず海外で働いてみたいな～って思い、働くなら IT 系、そしてベトナムが最近 IT 人材が伸びてきて、将来日本との関わりが増えそうと予測したので、ベトナムにしました。 学生時代 －ベトナムでのインターンシップ（IS）－ ベトナム IS で行ったことをプロジェクトの事など詳しくは、大人の事情で話せないのですが簡単に紹介だけさせて頂きます。 経緯 まず、私がその会社で IS をすることになった経緯は、その IS する前にベトナムで短期留学をしていました。その際に、プロジェクト関係で会社を訪問する機会があり、働いてみたいと言う意欲から直接人事部の人とコンタクトを取ったのが大きなきっかけです。 短期留学を終えて、日本に帰って来てからすぐに人事部の人にメールを送り、IS の引き受け可否から IS 期間、給料交渉、業務内容まで直接交渉を行いました。 仕事内容 そして、私を受け入れて頂いたベトナム企業は、オフショア開発を行っていて、私の所属していた部署は日本をクライアントとする部署でした。 主な業務は「ブリッジ SE」的な立ち位置でした。しかし、ブリッジ SE を名乗ることができるほどでは全然ありませんでしたけど…。 実際にクライアントから課題などヒヤリングを行い、プロジェクトマネージャー(PM)やエンジニアとコンタクトを取っていました。私の場合はベトナム語は話せないので、コミュニケータが付いていました。 また、システムのテストを行ったり、日本語のコミュニケータとして応募してきた方の面談も行っていました。そして時には、少しだけコーディングをする業務を行っていました。大学で少しコードを書いたくらいで、「来週から、コードを書いて開発してもらうからよろしく！」って言われたときは、本当に焦りました。。。 コミュニケーションについて 仕事して、帰ったら家事を行い、深夜までプログラミングを勉強する日々でした。とても辛くて、時には逃げたいと思ったこともありますが、海外まで来ていて、コロナの影響で飛行機は飛んでいないという状況でしたので、逃げられない環境でした（笑） またIS当初は、文化や言語の壁がありコミュニケーションが上手く取れませんでした。 プロジェクトメンバーにある日 「あなたはとても、仕事に対して真面目で指示が細かいのは良いと思うけど、相手の意見を引き出す力がまだないし、話しているときに目を合わせないと本当に聞いているかが伝わりにくい。ベトナムの人達は、コミュニケーションをするとき最後まで相手の目を見て、まずは相手の意見を聞くことを大切にしている。」 と言われてしまいました。 確かに業務中、ベトナム人同士で会話しているのを観察すると目を逸らすことなく、しっかりと相手の目を見て話していました。私を挟んだ両サイドの人が話すときも、私を避けてまで目を合わせて会話していました！（初めはそれが慣れなかったので、業務にあまり集中出来なかったのが本音ですが。。（笑）） そこから、私も相手と話すときは必ず相手の目を見て、まずは相手の意見を聞くようになりました。すると、距離感を感じていたチームメンバーともコミュニケーションを取れるようになっていきました。 色々ありましたが、必死にくらいついて何とか目標である 1 年間をなんとか乗り越えられました。 学生時代 －ベトナム IS で学んだこと－ 私がベトナム IS を通して成長したと感じたことが、IT 知識も勿論ですが 2つあります。 1つ目は「物事を多角的に考える力」、2つ目は「失敗は成功の種」です。 ① 物事を多角的に考える力 まず私が 1つ目に上げたのは、「物事を他視点で見る」大切さです。当時は、大学とバイト先という小さな世界で生きていたため無意識に固定概念を持っていました。 しかし、ベトナムにいるとき、国や文化が異なる人と働いていていたら、予測あるいは期待する返答が返ってこないことが日常的にありました。 例えば、実際に経験した話ですが、システム開発の中で地震が来たときに地震を知らせてくれるアラート機能をクライアントから依頼されました。日本では、地震が来たときにアラートがなる事はみなさんご存知だと思います。そして、流石にベトナムにもありそうだからすぐ実装できるだろうと思っていました。そして、開発者に依頼したところ、ベトナムには地震がそもそもあまりなくて、そんな機能がないから開発のイメージが湧かないと言われました。 結局、1から説明をして何とか実装はできたのですが、少し時間が掛かってしまいリリース遅れの原因の一部にもなりました。 そこから現在では、 物事を考えるときや相手から意見を聞くときは固定概念にとらわれず、多角的な視点を意識するよう にしています。 ② 失敗は成功の種 ベトナム IS が始まって 2か月くらい経ったある日、社長からいきなり「案件が取れるかもしれない大事な打ち合わせが来週あって、打ち合わせなどは君が仕切って先方とやり取りをお願い」と依頼されました。IT の知識どころか、打ち合わせもそんな経験もない中で、会社の売上に直結する業務を渡された時は、拒絶していました。もちろん、その依頼が来たときは、全力で断っていました（笑） できるだけの全力を尽くしたのですが、結局その案件は取ることができず、社長に直接謝りに行きました。絶対、怒られると思いながらビビり散らかしていたのですが、社長が初めに発した言葉が、「なんで、そんな謝るの？君の失敗という辞書に、これで 1 つまた追加できたから良いんじゃない？私（社長）の失敗の数を超えてから、謝ってほしい。それまでは、挑戦し続けて！」って言われました。当時はその言葉がとても刺さりました。そこから、 失敗を恐れず、何事にも挑戦しよう と思いました。 マイナビに入社して活かせたこと ① 物事を多角的に考える力 研修のプロジェクト開発では、チームメンバーと議論するときに自分の価値観や固定概念を押し付けるのではなくて、まずは相手の意見を聞いてから自分の意見を述べるようにしました。そうすることで、相手も意見が言いやすいし、結果としてチーム全体のコミュニケーションも活発になっていたのではないかと思います。 ② 失敗は成功の種 研修の中で、新卒が始業から終業まで、研修を運営する期間がありました。それぞれが役割を持ち、運営しなければならない状況で、私は自ら司会に手を挙げました。司会など、大勢の人前に立って話したことがなかったので、初めは正直、不安と後悔でいっぱいでした。しかし、ベトナム IS で社長から頂いた「失敗していいから挑戦し続けろ！」という言葉を思い出して、最後までやり遂げる事ができました。 現在、部署に配属されてからも失敗を恐れることなく、システム開発以外にも挑戦し続けています。まさに、このエンジニアブログも初めての挑戦です（笑） マイナビのグローバル化 最近、マイナビでは外国籍の方の採用を増やしたり、海外と共同開発に力を入れているように感じます。 実際に、マイナビの常務執行役員である吉田さんも 「マイナビを日本から世界へ」 とグローバル化を強調されております。 マイナビ　取締役常務執行役員　吉田和正さんのインタビュー記事 https://mynavision.jp/purpose-story/007/ 海外の方と協力して仕事をする上で、私の中で一番大事だと感じているのが「仕事のことより、相手の文化を最優先し、理解する。」ことだと思っております。（これはあくまでも海外で 1 年しか働いていない私の所感ですが。。。） 一緒に働く多文化の方々に日本の文化を押し付けると言うよりも、相手の文化を吸収するというイメージかもしれないですね。文化と言っても、難しく考える必要はないと思っていて、挨拶をするときも相手の言語で話すとかでも良いと思います。実際に、私がベトナム語を勉強して、片言のベトナム語で話しただけでもとても親近感を持ったのか、私に話しかけてくれる人が増えて行きました。 また、私がベトナムに行って、IS 先の企業以外にも訪問したことがありますが、どの企業もエネルギッシュで活気のある優秀な人材がいると感じました。個人的な体感ですが日本のスピード感より、ベトナムの方が圧倒的に早くて刺激を受けました。 将来目指す姿 将来私が目指しているのは、 「グローバルにも通用するエンジニアになること」 です。 グローバルなエンジニアと言っても、色々あるとは思いますが、日本や海外で働くことになっても過去の経験を活かして、文化や考え方にとらわれることのないようにしていきたいと思います。 沢山の人に刺激を受けながら、物事を押し付けるのではなく引き出して自分をもっと成長させていきたいです。 しかし、現状では IT 知識やコーディング力、英語力など様々な課題が山積みです（汗） でも、足を止めていたら何も始まらないので、小さい事でも困難なことでも一歩ずつ進んで行きたいと思います！！ 最後まで、ご覧いただきありがとうございました。 投稿 未経験からエンジニアへの道のり は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは。23卒のT・Nです。 配属されて初めて触れたRailsについて、日々苦戦しつつ学んでいます。 この記事では、Railsで開発する上で欠かせないgemについて、汎用的なものをいくつか紹介したいと思います。 ※勉強途中の若輩者です。間違っていたら優しい指摘をお願いします。 そもそもgemとは 標準のライブラリではなく、有志のすごい人たちが開発した外部ライブラリのことです。 インストールして使います。すごく便利だな〜と思いながら日々使っています。 興味がある人はコミュニティを見てください→ RubyGems 紹介するgemたち ransack・・・検索する kaminari・・・ページ処理する view_component・・・コンポーネント letter_opener・・・メール見るやつ seed_fu・・・データ投入するやつ rubocop・・・コードを指摘してくれるやつ 多いです。あまりに多くて、ここに記すには余白が狭すぎるので、おおまかな機能だけを紹介しようと思います。 ちょっとだけ使用例を提示するために、TODOアプリ(仮)を作成します。まず、適当に画面を作ります。 並んでいます。すごく。 多忙な現代人です、日々管理すべきことは多いのでしょう。きっと。 積もること山の如しなタスクからたった一つを探そうなんて、大層なもんです。 効率的で優雅な画面を実現するために使用したいgemは、ransackとkaminariです。 kaminari github ページネーションを簡単に実装できます。 嬉しいところ ページネーションを簡単に使える コンテンツ数やページ表示を好きな感じにカスタマイズできる 使用例 インストールした後使いたいところのcontrollerに追記します。10個毎にページ変えたかったらこんな感じ。 def index @tasks = Task.all.order(created_at: :desc).page(params[:page]).per(10) end ページ処理したいindex.html.erbに追記します。たったこれだけです。 <%= paginate @tasks %> ransack github 検索gemです。よくある検索フォームを簡単に作れます。 ransackには、シンプルモードとアドバンスモードがあります。 嬉しいところ 依存関係を追加することなく、Railsアプリケーションに検索を簡単に追加可能 アドバンスモードを使うことで、複雑な検索も標準的なRubyとERBでできる 使用例 シンプルモードでの例を紹介します。 インストールした後、modelに検索対象を追加します。 class Task < ApplicationRecord def self.ransackable_attributes(auth_object = nil) ["title"] end end controllerを編集します。 def index @q = Task.ransack(params[:q]) @tasks = @q.result(distinct: true).page(params[:page]).per(10) end viewは以下のように非常にベーシックな検索欄を作りました。"_cont"は、部分一致で検索させたかったので指定しています。条件を簡単につけれるのも魅力的ですね。 <%= search_form_for @q, url: tasks_path do |f| %> <%= f.search_field :title_cont, class: 'form-control', placeholder: '検索ワード' %> <%= f.submit '検索' %> <% end %> ということで、kaminariとransackを使った結果。 ちょっとだけ賢そうですね！ こんな感じで、gemを使いこなすとスマートでモダンな何らかのアプリを簡単に実現できます。 view_component github コンポーネント志向UIを実現するgemです。 コンポーネント志向UIとは、ざっくり言うと、UIを再利用可能な部品（コンポーネント）に分割する感じの、環境にやさしいSDGs精神っぽいやつです。 例えば、どの画面でも共通して使用する「ボタン」があるとします。いちいち全ページに記述するよりも、コンポーネントにして使いまわした方が幸せになれます。 嬉しいところ Componentベースで開発するので再利用が簡単 テストやデバッグがしやすい ERBでそのまま呼べる seed_fu github Railsには、初期データをデータベースに投入するためのseeds.rbファイルが最初から用意されています。 が、seed_fuを用いると、id(キー)を指定してレコード作成・更新ができます。 つまり、seedを実行する度に同じデータできちゃった…という事態を回避できます。 注意：seed_fuは更新が止まって久しいです。新規プロジェクトで採用するのは、できれば控えたいところです。 嬉しいところ seedの一部を変更した時、変更したところだけ読み込める 環境ごとに分けやすい FIXTURE_PATHやFILTERオプションをつけることでパス変更できる キーはid以外(ユニークであれば)も指定できる 使用例 基本的には　 rails db:seed_fu 　でデータを投入します。 ちょっと試します。db/fixtures/seed_test.rbを作成します。 例えば、Userテーブルがあって、emailがユニークだとします。emailをキーとして指定する場合は以下の感じです。 User.seed(:email) do |s| s.name = "me" s.email = "me@example.com" s.dog_name = "wanwan" end User.seed(:email) do |s| s.name = "you" s.email = "you@example.com" s.dog_name = "wanwan" end 実行して、データを見ます。 irb(main):001> User.all User Load (0.1ms) SELECT "users".* FROM "users" /* loading for pp */ LIMIT ? [["LIMIT", 11]] => [#<User:0x0000000103dfa328 id: 1, name: "me", email: "me@example.com", dog_name: "wanwan">, #<User:0x0000000105817bc0 id: 2, name: "you", email: "you@example.com", dog_name: "wanwan">] データをキー(email)で判定して、重複していた場合は「追加」ではなく「更新」となります。 例から、 me の方だけ、　 s.dog_nam = "w" 　に変えて実行します。 irb(main):001> User.all User Load (0.1ms) SELECT "users".* FROM "users" /* loading for pp */ LIMIT ? [["LIMIT", 11]] => [#<User:0x0000000103dfa328 id: 1, name: "me", email: "me@example.com", dog_name: "w">, #<User:0x0000000105817bc0 id: 2, name: "you", email: "you@example.com", dog_name: "wanwan">] 新規レコードは作成されずに、無事に更新できました！ letter_opener github アプリにメール送信を導入したとき、コンソールで確認するのって、面倒ですよね。 メール確認をするときにとても便利なgemです。 嬉しいところ メールのプレビュー確認を視覚的に優しくできる 間違えて送っちゃった！を防げる 使用例 localhost:3000/letter_opener 　にアクセスすると、ブラウザ上で送信したメールの確認ができます。 ターミナルばかりを眺めるのは不健康ですから、健康的で使いやすいのは素敵ですね！ RuboCop github RuboCopは、ソースコードの変なところを指摘してくれるgemです。インデントや空白のミス、ふさわしくない書き方まで教えてくれます。ついでに、簡単な修正ならば、半自動的に修正してくれます。 私は毎日RuboCopに修正してもらいつつ学んでいます。 また、RuboCopは、.rubocop.ymlを編集することで、検査対象や検査項目をアレンジすることができます。 嬉しいところ コードの変な部分を知ることができる 簡単な修正をしてくれる 複数人がコードを書くチーム開発で導入する場合、書き方を統一できる Cop(検査ルール)のカスタマイズ可能 使用例 bundle exec rubocop オプションに -a を指定すると、自動修正してくれます。ちなみに修正オプションは、 a ... safeとマークされたCopのみ修正 A ... unsafeも含めて全てのCopを修正 とありますが、個人的には、commit → bundle rubocop -A → git diffで確認するのがいいのかなと思っています。 おわりに 非常に雑多になりましたが、以上でgem紹介は終わります。 これからも色々試して、環境にやさしい素敵なRailsライフを送れるよう、精進していきたいと思います。 投稿 【Rails】汎用的に使えそうなgemたちまとめ は マイナビエンジニアブログ に最初に表示されました。

概要 マイナビエンジニアブログの記事をスクレイピングして、更新される度に通知が飛ぶプログラムをGASのライブラリであるCheerioで作りたい！！ 前提 マイナビエンジニアブログを自動通知したいと思うときがきっと来るはず。。。 そんな時に役立つのが、今回紹介するCheerioを使ったスクレイピングの技術です！！ 流れとしては、GASとスプレッドシートを紐づけてGASでURLをスクレイピングした後に、スプレッドシートのURLと照合して、もしURLが一致していたら、スプレッドシートに書き込みとGmail通知をしないようにします。どのURLとも一致しなかったら、スクレイピングしてスプレッドシートに書き込みします。書き込んだあとは、Gmailに通知を飛ばす処理を書く感じ。。。 下ごしらえ ①Google Drive上にスプレッドシートを作成します。スプレッドシートのヘッダー及び、UIは以下の図のようにします！ ②作成したスプレッドシートの拡張機能から、Google Apps Script（以降、GASと表記）を選択します。 ③GASのライブラリタブの「+」ボタンを押し、CheerioのIDをコピペしましょう！ CheerioのID 1ReeQ6WO8kKNxoaA_O0XEQ589cIrRvEBA9qcWpNqdOP17i47u6N9M5Xh0 これをGASのライブラリのところにコピペしましょう！ Cheerioとは、簡単に説明するとHTML要素を受け取り、DOM操作的なことをするためのライブラリです！ ④マイナビエンジニアブログ一覧のURLです。どこかにメモをしておきましょう！ホームページ上で「F12キー」を押すと、開発者画面になります。 https://engineerblog.mynavi.jp/posts/ 本題 関数定義 Webスクレイピングには、HTML要素が必要なので、まず、URLからHTML要素を取ってくる処理を書きます。 function scraping() { let resultList = []; const html = UrlFetchApp.fetch("https://engineerblog.mynavi.jp/posts/").getContentText(); const cheerio = Cheerio.load(html); } 分解すると、以下のようになります。 let resultList = []; これは、最終的なスクレイピング結果を格納するリストです。scraping関数のうち、最も上位階層に書きます。 UrlFetchApp.fetch("各サイトのURL").getContentText(); これで、そのWebページ全てのHTML要素を取得でき、 Cheerio.load("HTML要素"); こちらで、Cheerioによって、HTML要素を分析するための準備ができました。 Cheerioの使い方 ここから先のCheerioの使い方としては、 cheerio('クラス.クラス名').each(function(i, elem) { cheerio(elem).text(); }) 上記のコードで、タグで囲まれたテキストを取得でき、 cheerio('クラス.クラス名').each(function(i, elem) { cheerio(elem).attr('タグ名'); }) こちらで、タグの中にある要素の値を取得できます。 実際にCheerioを使う // ブログのタイトル一覧を取得 let titleList = []; cheerio('div.article-info h3.article-list-title-h3').each((i, elem) => { titleList.push(cheerio(elem).text().toString()); }) // ブログの各URLを取得 let urlList = []; cheerio('div.archive-contents div.list-content ul li.article-list-li-type5 a').each((i, elem) => { let url = "https://engineerblog.mynavi.jp" + cheerio(elem).attr('href').toString(); if (!(url.includes('tag'))) { urlList.push(url); } }) 上記のコードで、それぞれのブログのタイトルとURLが取得できました。 詳しく見ていきましょう！ let titleList = []; タイトルを格納するリストを作ります。 let titleList = []; cheerio('div.article-info h3.article-list-title-h3').each((i, elem) => { titleList.push(cheerio(elem).text().toString()); }) このコードで、ブログのタイトルが取得できています！ 'div.article-info h3.article-list-title-h3' cheerio()の中に、このようにありますが、記法はCSSと似ていて、 'タグの名前.クラス名 タグの名前#ID名' これでタグで囲まれた要素を取得できます。ここで「.」は、次に続く文字列がクラス名であることを表しています。 「.」= クラス 「#」= ID 左から右にかけてより詳細なタグへと向かうように書きます。タグとの間は空白を空けましょう！ 次に、Cheerioで解析したHTML要素を一つずつ取り出します。 .each((i, elem) => { }) eachの第２引数に解析結果が格納されています。 cheerio(elem) 解析結果は、これで取り出すことができました！また、cheerio()は、text()、attr()を持つことができます。 cheerio().text() → タグで囲まれた文字列を取得 cheerio().attr() → タグ内のクラスや、hrefの値を取得 今回は、h3タグで囲まれたタイトルを取得したいため、text()を使います。 titlelist.push() titleListのリストに、取得したタイトルを追加します。 以上の作業で、タイトルが取得できます。 次に、URLを取得するコードを見てみましょう！ <a class="hover-thumb_title-mynavi_life" href="/mynavi_life/mynavi_sys_newoffice/"></a> URLは、このように、aタグの中にあります。これを取得するには、前述のようにattr()で取得します。 cheerio(elem).attr('href') これで、aタグの中にあるhref情報を取得できます。 しかし、実際のHTMLを見ると、このさらに下の階層にaタグとhref情報が存在します。この下の階層のhrefは取得したくないので、href情報の値で、絞り込みを行う必要があります。 今回必要なURLは、tagという文字列が入っていないURLです。 let url = "https://engineerblog.mynavi.jp" + cheerio(elem).attr('href').toString(); if (!(url.includes('tag'))) { urlList.push(url); } このように書くことで、tagがついていないときにurlListに追加する処理が実現できます。 以上のコードで、ブログのタイトルとURLを取得することができました。 スプレッドシートに書き込み ここからは、スクレイピングした情報をスプレッドシートに書き込みを行います。 その前に、今回のスクレイピングは同じものをスクレイピングしないようにしたいので、URLを照合する処理を書きましょう。 const spreadSheet = SpreadsheetApp.openById(<スプレッドシートID>); const sheet = spreadSheet.getSheetByName(<シート名>); const urlValues = sheet.getRange(2, 2, sheet.getLastRow(), 1).getValues(); //多次元配列を一次元配列に変換 const urlValuesFlat = urlValues.flat(); URL照合には、URLのみを取得すれば良いので、(2, 2, シートの最後の行, 1)が範囲となります。 flat関数は、多次元配列を一次元配列に直す関数です。getValues()で取得した値は、二次元配列のため、一次元配列に直す必要があります。 このコードは、resultListを定義した上位階層の部分に書きます。 次に、スプレッドシートに書き込みを行うには、二重リストである必要があります。 if (titleList.length == urlList.length) { for (let j=0; j<urlList.length; j++) { if ( !(urlValuesFlat.includes(urlList[j])) ) { resultList.push([titleList[j], urlList[j]]); } } } else { throw new Error("タイトルとURLの数が一致しません"); } resultListを用意して、その中に、リストを埋め込むことで、resultListは二重リストになります。 forループで数字を回すことで、タイトルとURLがそれぞれ入っているリストのIndexを回すことができます。 if ( !(urlValuesFlat.includes(urlList[j])) ) この部分は、スプレッドシートにもともとあるURLとスクレイピングしてきたURLが被っていないかを照合しています。 被っていなかったら、resultListに、タイトルとURLをpushします。 if (titleList.length == urlList.length) { } else { throw new Error("タイトルとURLの数が一致しません"); } この部分は、タイトルとURLの数が一致していたらresultListにpushする処理です。 もし数が合わないと、違うURLを取得していることになるため、エラーにしましょう。 やっとスプレッドシートに書き込む準備が整いました！！ // スプレッドシートに書き込み if (resultList.length > 0) { sheet.getRange(sheet.getLastRow()+1, 1, resultList.length, 2).setValues(resultList); } resultListに値が入っているときに、書き込み処理を行います。 書き込む行は、前にスクレイピングしたブログの下に入れるので、スプレッドシートに値が入っている最後の行+1が、書き込みを始める行になります。書き込む行数は、リストの値の数の分だけです。 そのため、(最後の行+1, 1, リストの長さ, 2)となっています。 複数ページのfetch エンジニアブログは、もちろん１ページでは終わっておらず、複数ページにまたがります。ページをループさせ、それぞれのページでもURLfetchを行っていきましょう。 for (let i=0; true; i++) { try { const html = UrlFetchApp.fetch( `https://engineerblog.mynavi.jp/posts/page/${i}/`).getContentText(); const cheerio = Cheerio.load(html); /** * スクレイピング処理 */ // 要素が取得できなかったら、ブログは存在しないのでbreak if (titleList == "") { break; } /** * スクレイピング処理 */ } catch(e) { console.log(e.message); break; } } for (let i=0; true; i++) まず、上のコードでページ番号をループさせます。 `https://engineerblog.mynavi.jp/posts/page/${i}/` このように埋め込むことで、各ページのfetchが可能になります。 このままだと、無限ループになるため、タイトルが取得できなくなったらbreakすることも忘れずに！！ if (titleList == "") { break; } 念のため、エラーが発生した際もbreakしましょう！ catch(e) { console.log(e.message); break; } ちなみに、トライキャッチとは、簡単に言うとエラーが発生しない間はトライの処理を行い、エラー発生でキャッチの処理を行うことを指します。 ここまでで、スクレイピングの処理が完了しました！！ここまでのコードをまとめると、次のようになります！ function scraping() { let resultList = []; const spreadSheet = SpreadsheetApp.openById("1CSRh2KnFP33wb1QPigBCxw7xD5c8EvgmBJzXAts7Ias"); const sheet = spreadSheet.getSheetByName("スクレイピング結果"); const urlValues = sheet.getRange(2, 2, sheet.getLastRow(), 1).getValues(); for (let i=1; true; i++) { try { const html = UrlFetchApp.fetch(`https://engineerblog.mynavi.jp/posts/page/${i}/`).getContentText(); const cheerio = Cheerio.load(html); //多次元配列を一次元配列に変換 const urlValuesFlat = urlValues.flat(); // ブログのタイトル一覧を取得 let titleList = []; cheerio('div.article-info h3.article-list-title-h3').each((i, elem) => { titleList.push(cheerio(elem).text().toString()); }) // 要素が取得できなかったら、ブログは存在しないのでbreak if (titleList == "") { break; } // ブログの各URLを取得 let urlList = []; cheerio('div.archive-contents div.list-content ul li.article-list-li-type5 a').each((i, elem) => { let url = "https://engineerblog.mynavi.jp" + cheerio(elem).attr('href').toString(); if (!(url.includes('tag'))) { urlList.push(url); } }) if (titleList.length == urlList.length) { for (let j=0; j<urlList.length; j++) { if ( !(urlValuesFlat.includes(urlList[j])) ) { resultList.push([titleList[j], urlList[j]]); } } } else { throw new Error("タイトルとURLの数が一致しません"); } } catch(e) { console.log(e.message); break; } } // スプレッドシートに書き込み if (resultList.length > 0) { sheet.getRange(sheet.getLastRow()+1, 1, resultList.length, 2).setValues(resultList); } } メール送信 あとは、メール送信のコードを書いて終了です！！ function sendGmail(resultList) { const toMail = '<送信先メールアドレス>'; const subject = '【自動送信】エンジニアブログの更新'; const options = { from: '<送信元メールアドレス>' }; let bodyList = []; for (let result of resultList) { let eachBody = `${result[0]}（${result[1]}）`; bodyList.push(eachBody); } const joinBody = bodyList.join('\n'); const body = `以下のエンジニアブログが更新されました！\n\n${joinBody}`; GmailApp.sendEmail(toMail, subject, body, options) } 詳しく見ると、以下のようになります！ const toMail = '<送信先メールアドレス>'; const subject = '【自動送信】エンジニアブログの更新'; const options = { from: '<送信元メールアドレス>' }; これは、メールの送信先、題名、送信元を指定しています。 let bodyList = []; for (let result of resultList) { let eachBody = `${result[0]}（${result[1]}）`; bodyList.push(eachBody); } const joinBody = bodyList.join('\n'); const body = `以下のエンジニアブログが更新されました！\n\n${joinBody}`; これは、本文に更新されたブログのタイトルとURLを載せているコードです。 一旦、一次元リストにまとめてから、それをjoin関数を用いて、改行区切りで文字列に変換しています。 変数bodyに本文を埋め込んで、 GmailApp.sendEmail(toMail, subject, body, options); これで送信完了！！ あとは、このメール送信のタイミングが、resultListを書き込むときにすれば、まとめて更新分のブログを送信できます。 /** * メール送信 * スプレッドシート書き込み */ if (resultList.length > 0) { sendGmail(resultList); sheet.getRange(sheet.getLastRow()+1, 1, resultList.length, 2).setValues(resultList); } scraping関数の中の、このif文の中に埋め込みましょう！ トリガー設定 最後に、完全自動実行を実現てみましょう！ GASにはトリガーが設定できます。今回は、毎日18:00になるとスクレイピング処理するトリガーをセットします。 メニューから、「トリガー」を選択します。 右下にある「+トリガーを追加」ボタンを押します。 「実行する関数を選択」をscraping、「イベントのソースを選択」を「時間主導型」、「時間ベースのトリガーのタイプを選択」を「日付ベースのタイマー」、「時刻を選択」を「午後6時～7時」にします。 あとは既定の値で、「保存」ボタンを押します。 上の図のようになってたらOK！！ 完成 ▼完成コード function scraping() { let resultList = []; const spreadSheet = SpreadsheetApp.openById("1CSRh2KnFP33wb1QPigBCxw7xD5c8EvgmBJzXAts7Ias"); const sheet = spreadSheet.getSheetByName("スクレイピング結果"); const urlValues = sheet.getRange(2, 2, sheet.getLastRow(), 1).getValues(); //多次元配列を一次元配列に変換 const urlValuesFlat = urlValues.flat(); for (let i=1; true; i++) { try { const html = UrlFetchApp.fetch(`https://engineerblog.mynavi.jp/posts/page/${i}/`).getContentText(); const cheerio = Cheerio.load(html); // ブログのタイトル一覧を取得 let titleList = []; cheerio('div.article-info h3.article-list-title-h3').each((i, elem) => { titleList.push(cheerio(elem).text().toString()); }) // 要素が取得できなかったら、ブログは存在しないのでbreak if (titleList == "") { break; } // ブログの各URLを取得 let urlList = []; cheerio('div.archive-contents div.list-content ul li.article-list-li-type5 a').each((i, elem) => { let url = "https://engineerblog.mynavi.jp" + cheerio(elem).attr('href').toString(); if (!(url.includes('tag'))) { urlList.push(url); } }) if (titleList.length == urlList.length) { for (let j=0; j<urlList.length; j++) { if ( !(urlValuesFlat.includes(urlList[j])) ) { resultList.push([titleList[j], urlList[j]]); } } } else { throw new Error("タイトルとURLの数が一致しません"); } } catch(e) { console.log(e.message); break; } } /** * メール送信 * スプレッドシート書き込み */ if (resultList.length > 0) { sendGmail(resultList); sheet.getRange(sheet.getLastRow()+1, 1, resultList.length, 2).setValues(resultList); } } function sendGmail(resultList) { const toMail = '<送信先メールアドレス>'; const subject = '【自動送信】エンジニアブログの更新'; const options = { from: '<送信元メールアドレス>' }; let bodyList = []; for (let result of resultList) { let eachBody = `${result[0]}（${result[1]}）`; bodyList.push(eachBody); } const joinBody = bodyList.join('\n'); const body = `以下のエンジニアブログが更新されました！\n\n${joinBody}`; GmailApp.sendEmail(toMail, subject, body, options); } これで完成です！！scraping関数を実行すると、更新分だけ、スプレッドシートに書き込みを行い、メール通知が来ます。 初回のスクレイピング処理は、すべて取ってくるため、メール通知には、全てのエンジニアブログが来ます。 所感 Cheerioを使うと、GASでも比較的簡単にスクレイピングができるんです！私自身、Parserというライブラリも試しましたが、要素を取り出すときに苦労しました。 結果的にはCheerioで良かったと思っています！ 業務では、似たようなスクレイピングを行うことがありますが、そのときもCheerioを使ってスクレイピングすることが多いです。 今回紹介したスクレイピングで、ブログの自動通知を行うというものは、業務自動化の一種なので、広義の意味でRPAに該当します！ぜひ、この記事を見ている方々は試してみてほしいです！！ 投稿 エンジニアブログの更新分をGmailに通知してみた は マイナビエンジニアブログ に最初に表示されました。

はじめに こんにちは、私、23年新卒入社のM.Mと申します。 突然ですが、CRMについてご存じですか？ 「CRMって聞いたことはあるけど、実際何かはよくわかってない…」 「顧客の情報のなんかでしょ？？？確か…。」 など、聞いたことは有るけど「よくわからない」という方が大半ではないでしょうか？ 分かります。 かくいう私は、2か月前に現場配属され、初めてそこでCRMという言葉を知ったほどです。 そこで、今回は、配属してから２か月で学んだ、「CRMとは何か」 について、新卒ながら、記事を書いてみました。 新卒ながらの着眼点として、本記事を楽しんでくだされば、幸いです。 CRMとは この章ではCRMについて、書いていきます。 そもそも、「CRMとは何なのか」 一体、「何に役立っているか」 実際、CRMが「無いとどうなるか」 の３つの観点からお話出来ればと思います。 CRMとは何なのか CRMとは、 Customer Relationship Management 　の略で、一言で言うと「顧客関係管理」のことを指します。顧客関係とは、”一般的に企業とお客様の間で成り立っている関係”のことで、この関係はお客様が一般消費者（サイト利用者など）であればBtoC、お客様が企業であればBtoBと称します。 例えば、マイナビにおけるBtoBの顧客関係には どのような企業がマイナビ2025に求人広告を掲載しているのか 求人広告をどの媒体で掲載しているのか（就職・転職・アルバイトなど…） などがあります。 現在、多くの企業がこういった顧客関係を管理する”CRM”を導入しており、会社の営業活動を支える基盤として重要な役割を担っています。 何に役立っているか では、このCRM、実際何に役立っているでしょうか？ 一言でいうと、「企業の管理を出来る」ことに役立っています。 マイナビでも実際CRMツールを使ったデータの統合管理を行っておりますが 例えば 各拠点に点在するマイナビの拠点間で、情報を共有することが出来る 同じ企業に２回以上、架電（営業の電話）をかけてしまう事を防げる。 などの情報のサイロ化を解消することが出来ます。 また、支社の管理や、合併した会社についても、管理することが出来るので 「企業の管理を出来る」ことは全社的に大きなメリットになります。 無いとどうなるか 何に役立っているかについてその逆、 無いと「企業の管理が出来ない」という状態に陥ってしまいます。 支社ごとに各企業を管理することになるので、 お客様に対して持っている情報がバラバラになる 複数の営業担当がアプローチしてしまう可能性 がある 話の食い違いなどにより大きな出戻りが起こる可能性がある など、サイロ化が起こります。会社規模に比例してその問題は大きくなります。 SFAとCRMの関係性 ここまではCRMについて触れてきました。 CRMは、単体で強い効力を持ちますが、より強くCRMを生かす方法があります。 そこで、よくCRMとセットで扱われるもの、それが SFA です。 今回は、SFAについても軽く触れていきたいと思います。 よく間違えるSFA・CRMは実は違う SFA・CRMは、一色端として扱われることが非常に多いですが、実際は全く異なるものです。 SFAとはSales Force Automationの略で、「営業支援システム」と訳されます。詳しい説明は省きますが、営業進捗の可視化や活動管理を行うものです。 CRMは顧客管理を行う事がメインであることに対して、SFAは営業活動の管理を行うものであるので、根本的に全く違います。 SFAとCRMはセットで使うととても強い では、全く違うものだから、相性が悪いのかと言われれば、そうではありません。 寧ろとても強い効力を持ち、SFA・CRM双方において相乗効果を持ちます。 例えば、CRMの基盤を整えた上で、SFAを配置すると、 顧客情報を的確に営業職にコミットした営業活動を促進することが出来ます。 且つ、顧客関係のカテゴライズ化や商談・受注の情報などを管理することにより 成功フォーマットを作成することが出来るなどのメリットがあります。 つまり、CRMとSFAを一緒に活用することで、 的確なアプローチをもって、営業活動を行うことが出来る 受注成功情報や、企業分析などを行うことが出来るようになる。 気が付けない需要に気が付くことが出来るようになる。 など、色々な旨味を得る事が出来るというわけです。 最後に 今回は、CRMについて説明してみましたがいかがでしたでしょうか。 新卒ながらに知っている「CRMとは何か」について書いてみました。 正直、この文章を書きつつ、「まだまだ、分かっていないなぁ」と思いながら書いていました。もっと深い部分にCRMの底力と魅力があると思っています。 より多くの人にマイナビを知ってもらう為にも、新卒として様々な勉強をしていきたいと思います。 投稿 最近流行りのCRMとはいったい何だ！？ は マイナビエンジニアブログ に最初に表示されました。