はじめに こんにちは！ 株式会社マイナビで内製開発チームに所属している 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とはいったい何だ！？ は マイナビエンジニアブログ に最初に表示されました。

はじめに 皆さん、こんにちは。ITディベロップメント1部のS.Tです。 この記事では、私がベトナムの協力会社と協業で、弊社の既存業務システムの約700件のテストコードを3ヶ月で実装したときの話を紹介しようと思います。 背景 この案件が発生した経緯について説明します。 過去に、とある事業部の業務システムを内製し、保守運用をしていました(PHP,Laravelを使用)。 そのシステムは、開発当時はスモールスタートかつスピード重視だったため、テストコードを書いていませんでした。事業部の成長と共にシステムが拡張されていく中で、既存のPHP,Laravelのバージョンでは限界があり、アップデートの必要性が高くなっていきました。 しかしシステムの規模的に、バージョンアップをしたとしても不具合が頻発する危険性があります。そこで、テストコードを作成し、ソースコードの品質を担保する必要があるという話になりました。 　 ただ、一つ大きな問題がありました。それは、システムの規模が大きくなりすぎてしまったため、当時の社内のリソースだけで開発を進めると時間がかかり過ぎることでした。 そこで白羽の矢が立ったのが、当時丁度提携したばかりの ベトナム の協力会社N様でした。 開発の流れ 協力会社N様と協力して開発を進められることになりましたが、その前に弊社の方で協力開発のための準備をする必要がありました。 具体的には以下の準備を行いました。 テストを実行できる環境を用意 開発スケジュールの決定 協力会社N様との連携方法の決定 テストを実行できる環境を用意 弊社でPHP、Laravel　のテストコードについての技術調査を行い、どのメソッド単位でテストを行うかを決定し、実際に自らテストコードを書いてみたりしました。 開発スケジュールの決定 これに関しては、開発の工数を大まかに見積もり期限を設けました。また、テストのチェック内容を定義し、協力会社N様が何を実装すれば良いのかを明確にしました。 協力会社N様との連携方法の決定 週に一度協力会社N様とのオンラインミーティングを行い、お互いの進捗確認をしました。また、仕様の確認やソースコードのレビューに関しては、SlackとGitHub上で英語で行うことになりました。 補足 先ほど英語でやりとりをするとの話がありましたが、当時非常に不安だった記憶があります。というのも、システムの仕様が複雑な部分の細かいニュアンスをうまく伝えられないのではないかや、先方の質問にうまく英語で答えられないのではないかと考えていたからです。 実際には、オンラインミーティングでは先方に通訳の方がいたため、日本語でコミュニケーションを取ることができました。また、SlackとGitHubでのやりとりではGoogle翻訳などのツールを活用したことで、比較的スムーズに連携ができました。 実際の開発 事前に準備した内容をもとに開発がスタートしました。開発の流れとしては、週一回の定例会で先方の2週間分のタスクとその進捗、弊社のレビュー状況を確認するといった流れで進めていきました。開発自体は滞りなく進められてはいましたが、実際に開発が始まると想定外の事態が起きるものです。今回の場合は、以下2点が特に印象に残っている想定外の事態です。 技術的な提案を先方の方からしてくれる 先方の開発スピードが速すぎてレビューが追いつかない 技術的な提案を先方の方からしてくれる これに関しては、弊社としても非常に助けられました。結果的に提案していただいた内容の多くを採用し、開発速度を加速させることができました。 先方の開発スピードが速すぎてレビューが追いつかない これは完全に弊社側のリソース不足が原因だったのですが、先方の開発スピードが速すぎて、レビューがどんどん溜まって行く事態が発生してしまいました。この事態を解消するために、しばらくレビューばかりしている時期もありました。笑 二つとも良い意味での想定外で、こういった要因もあって最終的に、あらかじめ設定していたスケジュール通りに開発を終えることができました。 まとめ 上記のように、当初不安に感じていた英語でのやりとりも問題なく行うことができ、先方からの提案や想定外の開発スピードのおかげもあり、結果として表題にあるように、約700件のテストコードを3ヶ月で実装することができました。 終わりに 以上、ベトナムの協力会社と共に約700件のテストコードを3ヶ月で実装した話でした。 私自身も、初めて海外の方と仕事をするということもあり、不安に思うことも多かったですが、先方の通訳の方とGoogle翻訳に助けられ、なんとか完遂することができました。 英語での会話はできなくても、読み書きが最低限できれば問題なく業務遂行ができることはわかりましたが、次回同じような案件にアサインされた際にもっとスマートに格好よく業務遂行できるように、英語の勉強をしっかりしようかなと思った次第です。笑 長くなりましたが、最後まで読んでいただきありがとうございました。 投稿 既存業務システムの約700件のテストコードを3ヶ月で実装したときの話 は マイナビエンジニアブログ に最初に表示されました。

はじめに 2023年11月15・16日、4年ぶりに Google Cloud Next Tokyo'23 が東京ビッグサイトで開催されました。 当記事では筆者が参加した15日の内容についてレポートします。 イベント内容 Google Cloudを導入している企業のリーダーがビジョンや取り組みについて話をする 基調講演 、9つのジャンルに分かれた各企業の取り組みやクラウド活用事例が聞ける ブレイクアウトセッション 、Google Cloudの操作を学べるハンズオンセッション、各企業のブースで最新のサービスや事例を知ることができる Expo 、Google Cloudのデモも体験できるエンジニアのための Innovators Hive など様々なプログラムが用意されていました。 ブレイクアウトセッション 今回参加したブレイクアウトセッションのうち2つをピックアップします。 11冠エンジニアを輩出した組織とは？チーム立ち上げのための6つのキーポイント 講演者 株式会社G-gen 執行役員 CTO 杉村 勇馬　氏 講演概要 株式会社G-genは、Google Cloudインテグレーターで、2021年9月はエンジニアの数は杉村さん1名でしたが、2023年11月現在は23名にまで増えている状況。 スタートアップの企業でなおかつGoogle Cloudという先端技術に触れているということもあり、採用基準ではカルチャーマッチを1番に意識しています。 例） 攻めていくようなスタートアップの気持ちがあるか 教育制度を一緒に作ってもらえるか また、採用時点では23名中14名がクラウド経験者であり、そのうちGoogle Cloudを知っている方は5名でした。したがって、入社後に徐々にGoogle Cloudのプロフェッショナルへ成長していく流れとなっています。現在では11資格のコンプリート者が8名いる状況。プロ資格を持っている方は21名、パートナートップエンジニアとして選出されたのは9名です。 6つのキーポイント 今回の講演のテーマでもあったチーム立ち上げのための6つのポイントは下記になります。 ①分かりやすい行動指針を示す 行動指針などはいくつ作っても覚えられないことは実践できないため、 G-genの行動指針は本来は12個ありますが、 オーナーシップ スピード 成果 顧客視点 の4つを技術部門の行動指針にしています。(サーバーワークスの4つの行動指針) ②全ての業務を成長の場にする スタートアップだからこそエンジニア1人でもいろいろな業務領域があり、クラウドインテグレーション、プロジェクト構築、技術サポート窓口も同じエンジニアが担当しています。 このようなことを部署横断で実施することで、いろいろなエンジニアが複数の業務をできるようにしており、技術マーケティングもすべてのエンジニアにある程度行ってもらっています。(例：テックブログ執筆やウェビナーの登壇など) Google Cloudの正しい知識を身につけることになり、正確かつ論理的な文章を書き、体系的なドキュメントを校正することにもなります。これは、お客様とのプロジェクトにおいて、設計ドキュメントをどのように体系的かつ分かりやすく書くかに繋がっていきます。 ③学習を奨励する文化を作る　★一番重要★ スピードと受注率には相関性があると思っています。 計算式でいくらか出すことはできないが、売上利益の向上に確実には繋がると考えています。 【G-genが行っていること】 資格試験の受験代金全額補助 勉強会の奨励(業務時間中OK） 知識のシェアの奨励 （★特に重要） Slackで技術的な質問をすると、誰かが率先してすぐに答えるような仕組みをつくっています。技術マネージャーが率先して実施していかないとこの流れはできません。 ④資格を正義にしない 【資格は持っているが仕事はできない人に決してなってほしくない】 レベル0-100で段階を分けたとすると… 100⇒①要件定義・設計に活かせるレベル 75⇒②技術者として深く説明できるレベル 50⇒③嚙み砕いて理解(腹落ち)したレベル　《資格合格はこのレベルにすぎない》 25⇒④概要を把握したレベル 0⇒⑤名前しか知らないレベル ⑤会社の中に閉じない エンジニアは閉じこもりがちだと考えています。 そのため、お客様と積極的に技術交流や懇親会などを行うことを奨励しています。 これにより、以下のメリットが得られると考えています。 技術的な知見がプラスになる 新しいビジネスに繋がる可能性 外の世界が見えて見識が広がる 『世界が広がると技術力の幅も広がる』と考え、少しでもお客様と接点を持つことを励行しています。 ⑥コミュニティに貢献する 【コミュニティには参加せよ】 エンジニアには、コミュニティに参加することを奨励し、業務時間中の活動も許容しています。 前述と同様にメリットとしては以下のようなものがあると考えています。 技術的な知見がプラスになる 新しいビジネスに繋がる可能性 外の世界が見えて見識が広がる 感想 G-genがこの短期間で社員を増やしつつ、それぞれのスキルを高められているのはこういった仕組みがつくられているからなのだと知ることができました。 『世界が広がると技術力の幅が広がる』はまさにそうだなと思いましたし、 知識やスキルを得るためにインプットアウトプットする機会をもつ必要性を改めて感じました。 そのためにも会社という狭い世界の中だけでなく、外に出て新たな発見が得られるような風土をつくらなければいけないと思いました。 グローバルNo.1サービスを目指すmeviyに、なぜカルチャー推進が重要なのか？～社員の自己肯定感を高める#IAmRemarkable エンジニアに限らず、Google発信のワークショップを紹介するセッションもありました。 講演者 株式会社ミスミID企業体IDマーケティング推進室　ジェネラルマネジャー 大川 英恵 氏 Google Cloudパートナー事業本部Partner Development Manager,Data Analytics 小澤 真由子氏 講演概要 事業拡大に伴って、海外チームが加わり、コミュニケーションカルチャー等に課題が出てきた株式会社ミスミ。「困った」「わからない」「仲間が欲しい」に対してすぐに繋がれるコミュニティーを作ることを目的とし、公募で社内プロジェクトを募ってチームを結成。この課題を解決すべく実施したのが、Googleが提供する「IAmRemarkable」という取り組みです。 この取り組みは、ワークショップという形で提供されていて、もともとは女性やマイノリティの方々が自分の意見をしっかり言えるようになるための、という目的で始まりましたが、次第にマイノリティだけではなくどんな人にもこのワークショップが必要であると認識され始めるように。職場などのあらゆる場所で自分の実績をオープンに語ることを目指しています。 業務と関係ない取り組みに参加して良いのか、というメンバーのためらいや、ポジティブに集まったメンバーでもなるべく負荷をかけずに実施するにはどうしたら良いか等運営方法へ課題もありましたが、多様性とマイノリティグループを後押しし、モチベーションと自己肯定感の改善、チームの結束強化が狙えるこの取り組みで、同社はただ心理的安全性を実施するのではなく、なぜ必要なのかを事業部全体で理解することが出来、イノベーションを起こすカルチャーづくりを推進することが出来ました。 感想 カルチャーづくりを考えた際に、仕組みを整える、担当を決める…等ではなく、「困ったときにすぐ繋がれるコミュニティを作る」はなかなか出てこない、出てきても実現に意外とハードルが高い箇所なのではと思っており、実現されている力強さと、その意欲に対してアンサーが出来る取り組みとの両方に感銘を受けました。 組織活性、連携強化を目標に掲げる組織は多いかと思いますが、「そもそもなぜやるのか？」の部分についてもしっかりとフォーカスする、かつ”組織の全員が”その理由と重要性を理解する、というところまで落とし込めているかというと、出来ていない組織の方が多いのではないかと思います。本質の目線が合っていないと、どうしても必要な時に協力し合えないので、この研修を通して、お互いを知り、「なぜ必要なのか」を理解し合うことで、本当に連携が取れた組織が作れていくのが理想ではないかと感じました。 おわりに 今回は2講演をピックアップしましたが、興味を引くものが多く、講演時間が被っていて泣く泣くいずれかに絞ったものや、申し込み定員オーバーで断念したものも多く、心残りも…。 次回の開催も楽しみにしています！ 投稿 Google Cloud Next Tokyo’23 参加レポ は マイナビエンジニアブログ に最初に表示されました。

何の記事？ ＡＩで画像に 悪夢 のような変換を施す手法を紹介します！ 例）集合体が苦手な方は閲覧注意です… ※画像はtensorflowより引用 ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ この手法を TensorFlowのチュートリアル 通りに実装する際の流れの解説とTips 実際に試した例 を紹介する記事です！ 何に使うの？ 画像認識でDNN(Deep Neural Network)がちゃんと学習できているのかを可視化できる 深層学習ではモデルの予測が何を根拠に判断されているかが分からないという問題があり、その解決方法の一つ 同様の可視化手法で有名なのはCAM（後述） コンピュータービジョンの表現方法としての可能性 実際にプロのアーティストのミュージックビデオで使用されている Doing It for the Money (Foster The People) ◦ 0：37～をご覧ください 説明 概要 DeepDreamとは Alexander Mordvintsevによって作成されたコンピュータービジョンプログラムです。 画像の分類をするために学習した特徴を、逆に画像に足して出力することで悪夢のような変換をしています。 TensorFlowのチュートリアル通り に実装すれば任意の画像で変換可能。 チュートリアルではimagenet(物体認識ソフトウェアの研究で用いるために設計された大規模な画像データベース)で学習した機械学習モデルを使用しています。 やり方 チュートリアルを参考に、好きな画像でやってみましょう！！ 基本的な流れを紹介し、ちょっとずつTipsも加えます。 画像を用意 ・変換前の画像を用意します。 ・Tips：画像があまり大きいと時間がかかることがあります！ 特徴抽出モデルを用意 ・チュートリアルではInceptionV3を使用しています。 ・InceptionV3は、GoogLeNet (Inception v1) を改良したモデルです。tensorflowではImageNetによる事前学習済みモデルが用意されています。 ・ Tips ： InceptionV3でなくとも任意の事前学習済みモデルを使用できます！ KerasのAPI には多くの事前学習済みモデルがあるため、モデル変更の際はそちらを試してみるといいかもしれないです！ また、 事前学習済みモデルを任意のデータセットで転移学習したものを使う ことにより、任意の悪夢風変換を行うこともできます！ このあとの章で 自分の顔で転移学習したものを使った例 を載せています。 損失を計算 ・チュートリアルの損失計算部分では、選択した各レイヤーのすべての平均を取り、全レイヤーの平均値を合計したものを返しています。 勾配上昇方 ・普通は勾配降下法で損失を小さくしていきますが、DeepDreamでは入力画像に対して計算した勾配を元の画像に追加する勾配上昇方で変換を行っています。 その他補足 チュートリアル内で選択した画像の変換に使うレイヤーは、選択したレイヤーを最終層としたモデルを作成するのにつかわれています。つまりInceptionV3を指定レイヤーの部分で区切ったモデルを使って勾配の抽出を行っている感じです。 ↓レイヤーを選択している部分↓ # Maximize the activations of these layers names = ['mixed3', 'mixed5'] layers = [base_model.get_layer(name).output for name in names] 基本は変換したい画像に対して勾配を計算して元の画像に足すだけですが、 勾配を小さくしたやつを何回も足すようにするとイイ感じになります！ img = img + gradients*step_size 入力画像を拡縮してちょとずつ勾配を足してもイイ感じになります（Octaveという手法） def octave(original_img): OCTAVE_SCALE = 1.30 img = tf.constant(np.array(original_img)) base_shape = tf.shape(img)[:-1] float_base_shape = tf.cast(base_shape, tf.float32) for n in range(-2, 3): new_shape = tf.cast(float_base_shape*(OCTAVE_SCALE**n), tf.int32) img = tf.image.resize(img, new_shape).numpy() img = run_deep_dream_simple(img=img, steps=50, step_size=0.01) img = tf.image.resize(img, base_shape) img = tf.image.convert_image_dtype(img/255.0, dtype=tf.uint8) return img CAMとの違い 同様の画像分類モデル可視化手法であるCAM(Class Actiovation Mapping)では、勾配を取得し分類スコアに最も影響を与える入力画像の部分を識別します。 CAMの一般化手法であるGrad-CAMでの出力例 このような出力をするにあたり、CAMでは重要度をヒートマップで表した画像を新たに作成し、元の画像の上に薄く重ねます。 それに対してDeepDreamでは入力画像に対して計算した勾配を、小さく薄めて元の画像に直接足しています。 転移学習で任意の変換をしてみた ざっくりとした流れ 顔写真をたくさんあつめてデータセットを作る ↓自分の画像↓ tensorflowの転移学習チュートリアル に従ってInceptionV3を転移学習しました。（犬と猫のデータセットを自前のデータセットに置き換えるだけです） 転移学習後、InceptionV3のレイヤーConv2dの5と6を選択してDeepDream ↓選択レイヤーを出力にした勾配計算用のモデル図↓ 結果 若干髪の毛などの特徴で変換が行われている、、、？ おわりに 以上、悪夢のような画像変換を行うAI手法「DeepDream」の紹介でした。 手法自体は少し昔のものですが、内容はインパクトがあって面白いと思い紹介させていただきました。 昨今流行っている画像生成AIよりも仕組みは簡単だと思うので、この記事を見て興味を持った方はぜひトライしてみてください。 おまけ・勾配を小さくしないでそのまま入力画像に足した場合のDeepDream Stepsizeを0.1にするとこんな感じでした。 ノイズに近いですね。ちょっとゴーギャンっぽい？ 投稿 DeepDreamによる悪夢のような画像変換 は マイナビエンジニアブログ に最初に表示されました。

記事の説明 この投稿は、ファシリテーター未経験者の私が部署内でワークショップを開催し、その経験から学んだことについて書いたものです。 自己紹介 私は新卒で企画職として採用され、新規事業の企画やローンチ後のプロダクト施策提案を主業務とする部署に所属しています。配属されて数か月ですが、社内の様々な人とコミュニケーションを取りながら業務を進めていくことに楽しさを覚えています。 今回は、部署内で初めてワークショップを開催し、その経験から学んだ「場づくり」の大切さについてお話ししようと思います。 ワークショップの内容 私が開催したのは「カスタマージャーニーマップ」を作成し発表するワークショップです。ベンチマーク本として『はじめてのカスタマージャーニーマップワークショップ（加藤希尊著）』を参考にしました。 カスタマージャーニーマップを通じて、顧客の現状（As Is）を把握し顧客のあるべき姿（To Be）までの旅（フロー）を想像することで、精度の高い仮説を導き出すことができます。各自が持っている企画案のターゲット顧客の状態や感情を書き出し、顧客への理解を深められれば良いなという想いで行いました。 企画した背景 一般的にカスタマージャーニーマップは、マーケティング業務の中の販促フローを考える時に使われることが多いです。ではなぜ、ローンチ前の企画段階で顧客を考える必要性があると考えたのか。 それは、株式会社コーセーの商品企画を担当した青山陽一郎さんの動画を拝見し、顧客の状態を企画段階で言語化することの重要性を学んだためでした。 商品企画で大事なことは【自分ごと化による熱意と自信を持つ「共感」×分析・解釈により根拠を証明する「説得力」】が重要と述べられていました。どんなに質のいい商品だとしても、顧客に「共感」してもらわなければ商品は売れないのだと解釈しました。まずは顧客のことを考える、そこから商品の価値を見いだせるのではないかと考え、ワークショップを企画しました。 出典： 商品企画で大事なコト ~コーセーでの商品企画経験を事例に~ | GLOBIS学び放題×知見録 （ちなみにこのコンテンツは、弊社福利厚生の一つにある『GLOBIS 学び放題』内で視聴できます。福利厚生が充実していることは弊社のバリューであり有難く活用させていただいています！） いざ開催 ークショップは2時間で行いました。ワークでは、各自で企画テーマを決め、ペルソナを具体的に想像し、カスタマージャーニーマップを作るといった作業工程で行いました。 通常このようなワークショップは体感半日～丸一日かけて取り組むものですが、今回は業務時間中ということで時間を短めに設定しました。限られた時間の中で熱心にワークに取り組んでいただいた先輩方、ありがとうございます！ ワークショップの手順 ※08番は時間の都合により省略しました。 参加者のシート1 参加者のシート2! 参加者は7つの手順に沿って、顧客の感情や状態について付箋や印刷物を用いてシートを作っていきました。最終的に、参加者全員がカスタマージャーニーマップを完成させることができました。 とりあえずこのワーク自体は最後までやり遂げることができました。 振り返り さて、ここからは振り返りです。 ファシリテーターとしての技量、ワークの環境、完成度など踏まえた自己評価は以下の通りです。 自己評価 40点/100点 理由 「場づくり」の大切さを理解していなかった 今後の対策 1.　当日対応は先回りして用意すべし 当日のワークの中でこのような質問や要望をいただきました。 シートの書き方を教えてほしい →説明していなかった 記述例はないのか？→用意していなかった 合間に連絡業務が入りワークが一時中断してしまった→仕方ない 参加者の中にはカスタマージャーニーマップのことを知らない方も当然います。そんな環境下では、参加者の知識量、心理的状態、考えていることに応じて用意するものを先回りして考える必要がありました。当日なにが起きても大丈夫なように、チェックシートなど作りながらワークショップの精度を上げていきたいところです。 2.　参加者が心地よく感じられる型を意識するべし みなさんにとって心地いいデザインがあるように、ワークショップにも心地いいデザインがあるみたいです。株式会社MIMIGURIの安斎勇樹さんは、ワークショップをデザインすることは、「経験のプロセス」をデザインすることであると述べています。経験のプロセスをデザインするためには、「学習環境」を有機的にデザインすることが大事なのだとか。 上記の説に従うと、今回のワークショップは、使える時間が参加者にとって豊かな経験になるようにプロセスをデザインすることができていなかったなと振り返ります。参加者同士のアイスブレイクの時間を設けていなかったり、参加者が手を動かす時間が長すぎたりと、見直す部分がたくさん見つかりました！今後は、ワークショップの内容と併せて、参加者にとって心地のいいワークショップにするために学習環境を有機的にデザインしていこうと思います。 出典： ワークショップをデザインするとはどういうことか｜安斎勇樹 おわりに 今回、ワークショップを開催したことで、多くの課題を見つけ出せたことは大きな収穫だと捉えております！また、ファシリテーター未経験だからこそ分かった「場づくり」の大切さを肌で感じることができてよかったです。 顧客視点に立った企画立案は今後も業務で必要不可欠になってくるため、今回の振り返りを糧にアップデートをしていきたい所存です。これからも日々精進してまいります！ (´っ･ω･)っ ﾒﾘｸﾘ! 投稿 ワークショップを開催して学んだ「場づくり」の大切さ は マイナビエンジニアブログ に最初に表示されました。

はじめに GCPにはさまざまなストレージサービスやデータベースサービスがあります。 GCP試験の勉強中、頭がごちゃごちゃになったポイントでした。（私の場合） 今回は6つのストレージサービスについて簡単にまとめていこうと思います。 Google Cloud Storage（GCS） 特徴 オブジェクトストレージサービス 容量無制限 低価格 ◦Amazon S3と同じ感じ いろいろ ストレージクラス GCSには以下の4つのストレージクラスがあります。 種類 　説明 例 費用目安 Standard 　アクセス頻度の高いデータや短期間だけ保存されるデータ用。 ウェブサイト、ストリーミング系、モバイルアプリ $0.02～[GB 単位/月] Nearline 月一程度のアクセス頻度のデータ保存用。 30日以上保存が必要なバックアップデータ $0.01～[GB 単位/月] Coldline 四半期に一度程度のアクセス頻度のデータ保存用。 90日以上保存が必要なバックアップデータ $0.004～[GB 単位/月] Archive 年一程度のアクセス頻度のデータ保存用。 データアーカイブ、バックアップ $0.0012～[GB 単位/月] ユースケース 画像、テキスト、動画、その他のファイル形式などいろんなものを入れたいとき。 頻繁なアクセスのないバックアップデータなど。 非構造化データ置き場 基本はS3的な使いどころ Cloud SQL 特徴 フルマネージドなリレーショナルデータベースサービス MySQL、PostgreSQL、SQL Serverを使用可能 適切なディスクタイプとサイズを選択可能 ◦専用コア: 最大 64 TB ◦共有コア: 最大 3 TB いろいろ Cloud SQLの特長を掘り下げていこうと思います。 高可用性（HA構成） プライマリインスタンスと別のゾーンにスタンバイインスタンス配置 ◦プライマリインスタンスとスタンバイインスタンスは同期レプリケーション ◦障害時、スタンバイインスタンスにフェイルオーバー リードレプリカ リードレプリカは非同期レプリケーション 読み取りワークロードの負荷分散が可能 ※クロスリージョンレプリカ：リージョン間でのデータ同期が可能 ユースケース リレーショナルがいいけどオートスケールが不要な時 PostgreSQLを使用するとき CRM ERP系 Eコマースやウェブ系 SaaSアプリの構築 BigQuery 特徴 サーバレスで費用対効果に優れたエンタープライズデータウェアハウス 大量のデータセットを格納しながら即時処理が可能 データクエリ用の双方向性のあるSQLインターフェイス いろいろ データドリブンな分析機能がいくつかあるのでまとめていきます。 リアルタイム分析 イベント ドリブンな分析でビジネス イベントにリアルタイムで対応することが可能 組み込みのストリーミング機能あり ◦ストリーミングデータを自動的に取り込み、すぐにクエリが可能 予測分析 レコメンデーションと検出のシステムの構築が可能 BigQuery と BigQuery ML を使用する必要がある ◦BigQuery ML ：BigQuery で GoogleSQL クエリを使用して機械学習モデルを作成し、実行することができるもの ログ分析 ログデータを保存して探索したり、クエリを実行することが可能 ◦Googleアナリティクスで収集しているデータ（メジャメントプロトコル）をBigQueryに送り、集計・可視化することも… マーケティングデータウェアハウス スケーラブルなマーケティングデータウェアハウスの構築が可能 ◦BigQuery でマーケティング データと広告データを統合 ◦キャンペーンあたり、ユーザーあたりのコンバージョンに与える影響についての記述的分析 ◦BigQuery はキャンペーン マネージャー 360 の元データにアクセスできるため、この情報を利用可能 B ユースケース 大規模なデータ分析 SQLを使ったビッグデータ処理 Cloud Bigtable 特徴 フルマネージド NoSQL ビッグデータのデータベース サービス 数十億行、数千列の規模にスケール可能（＝数テラバイト、あるいは数ペタバイトのデータを格納可能） ◦Google 検索、アナリティクス、マップ、Gmail など、多数の主要サービスを支えているのと同じデータベース いろいろ 個人的に料金体系がパッと見だとよくわからなかったので要点をまとめます。 課金対象 ◦Bigtable インスタンスのタイプ、使用しているインスタンスのクラスタに含まれる合計ノード数 　　◦数/時間 ◦テーブルで使用しているストレージ量 　　◦GB/日 　　◦1か月での平均値から、月額を算出 ◦ネットワーク帯域幅の使用量 　　◦GB/日 Cloud Bigtable の料金の公式ドキュメント には、事例に基づき料金の例が載っているので大変助かります ユースケース 時系列データ ◦複数のサーバーにおける時間の経過に伴う CPU とメモリの使用状況など マーケティング データ ◦購入履歴や顧客の好みなど ◦低レイテンシーな読み書きを要するシステム 　　◦IoT・AdTech・金融サービス等 グラフデータ クレジットカードの不正利用検出（にも活用できるらしい） Cloud Spanner 特徴 無制限のスケーリング リージョンにわたる強整合性 最大 99.999% の可用性※マルチリージョン構成の場合 フルマネージド いろいろ Spannerの特長的な部分をいくつかピックアップします。 強整合性と水平スケーリングの両方が可能 Spannerはリレーショナルデータベースなので強整合性を保証しつつ、 noSQLデータベースでもあるため、グローバルに水平スケーリングが可能です。 （なかなか珍しいらしい…） 読み取り方式 Spannerには「強力な読み取り方式」と「ステイル読み取り方式」があります。 「強力な読み取り方式」 ◦デフォルトの読み取り方式 ◦強整合性を持った読み取りが可能◎ ◦読み取りの都度最新のデータであるかチェックするため、 内部通信が発生しレイテンシが大きい△ 「ステイル読み取り方式」 ◦高速な読み取りが可能 ◦レプリカ自身が持つ最新のデータであるかのチェックをスキップする 　　◦強整合性が重要ではない場合は良さそう ユースケース ミッションクリティカルなシステム ◦AdTech・金融サービス等 ポケモンGOはこちらを使用しているらしい Datastore 特徴 アプリケーション向けのNoSQLデータベース シャーディングとレプリケーションを自動で処理 負荷に合わせて自動的にスケールが可能 可用性と耐久性に優れている いろいろ Datastoreの特徴的な機能についてまとめていきます。 ACIDトランザクション 単一のトランザクションで複数のデータストアオペレーションを実行するACIDの特性により、データの整合性を確保 ◦不可分性(Atomicity) ◦貫性(Consistency) ◦独立性(Isolation) ◦永続性(Durability) 多様なデータ型 複数のデータ型が使用可能 ◦整数 ◦浮動小数点数 ◦文字列 ◦日付 ◦バイナリデータ 管理ダッシュボード さまざまな機能をダッシュボード上で使用可能 ◦エンティティ統計の表示 ◦データベースのクエリ ◦インデックスの表示 ◦データのバックアップと復元 ユースケース どれだけ増えても処理速度の変化を発生させたくないもの ゲームデータ ユーザデータ Google App Engineのデータベース さいごに 今回は6つのストレージ・データベースサービスについてまとめてみました。 それぞれの特長によって、使い分けしていきたいと思います。 投稿 GCPのストレージ・データベースサービスたちをまとめてみた は マイナビエンジニアブログ に最初に表示されました。