はじめに はじめまして！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のストレージ・データベースサービスたちをまとめてみた は マイナビエンジニアブログ に最初に表示されました。

はじめに GCPにはリソース階層というものがあります。 私がしょっぱなで躓いたところです。 前提として階層の関係性と役割を理解していないと、GCPまわりのドキュメントが何も理解できませんでした…。 「最低限この理解があれば先の勉強に進むことができた」レベル感でリソース階層についてまとめてみました。 階層構造の全貌 階層構造を図で表すとこのようになります。 大きい枠組みとして組織ノードがあり、配下にはフォルダがあります。 フォルダではフォルダ自体をまとめることも可能です。 フォルダの配下にはプロジェクトがあり、各リソースはプロジェクトに紐づいている形になります。 下層から見ていくと理解がしやすいかなと思いますので、まずはリソースからまとめていきます。 リソース リソースとは、GCPでシステムを構築していく際に使用するサービスのことです。 具体的には、サーバを使用したいときに使うGoogle Compute Engine、ストレージを使用したいときに使うGoogle Cloud Storageなどのことです。 このようなGCPサービスのことをリソースと呼びます。 （AWSでもリソースっていいますね'ω'） リソースは、1つのプロジェクトに属します。 プロジェクト GCPにて構築するシステムの単位です。 プロジェクトを使用することで、システムごとに管理することが可能です。 具体的な管理内容の例として、以下のものがあります。 請求の管理 ◦プロジェクト単位で請求が発生します。 ◦発生した費用の請求先アカウントを指定できます。 ユーザの管理 ◦プロジェクトごとにオーナーとユーザの作成を行い、管理することが可能です。 プロジェクト自体は以下の形式で管理します。 「名前・プロジェクトID・プロジェクト番号」 名前 ◦任意 プロジェクトID ◦永続的かつ不変なGCP全体で一意 ◦基本的に自動割り当て 　　　 ◦ただし自分でも決められる プロジェクト番号 ◦固有 プロジェクトはフォルダに属します。 フォルダ 部署、部門、チーム、アプリケーションなどの単位でプロジェクトをまとめることが可能です。 複数のフォルダをフォルダをで管理することも可能です。 フォルダを活用するメリットには以下のようなものがあります。 メリット チームの管理権限を付与することで各チーム独立して対応・作業が可能 フォルダ内のリソースはそのフォルダのIAMポリシーを継承 デメリット IAMポリシーの継承範囲を見誤るとミスオペの原因に、、、 フォルダは、フォルダもしくは組織ノードに属します。 組織ノード 階層の最上位で、プロジェクトをまとめて管理することが可能です。 リソースの使用状況の確認とポリシーの適用を一元的に行うことができます。 G Siiteドメインがある場合、GCPプロジェクトは自動的に組織ノードに属します。 そうではない場合はGoogle Cloud Identityを使用して作成が可能です。 組織ノードで付与したIAMポリシーは自動ですべてのプロジェクトに継承されますので気を付けましょう！ 最後に 階層構造によって管理を行うのは、GCPとAWSの大きく異なる部分かなと思います。 階層構造の理解ありきでGCPは話が進んでいくことがありうるイメージなので、まずは階層の全体像をつかむ必要があると感じました。 投稿 GCPのリソース階層について は マイナビエンジニアブログ に最初に表示されました。

はじめに GCPのIAMは、AWSのIAMとはまた別の概念を持っています。 そろそろこんがらがってきたので、GCPのIAMについて思考整理のためにまとめてみました。 IAMについて Cloud IAMとは アクセスの①主体②アクション ③対象リソースを指定することができます。 ⓵ 主体：ユーザ・グループ・アプリ ⓶アクション：特定の権限・操作 ⓷対象リソース：Google Cloudサービス 例えば、Compute閲覧権限ユーザをA君がもらうとすると、以下のようになります。 ⓵主体：A君のユーザ ⓶アクション：読み取りの権限・操作 ⓷対象リソース：Compute Engineリソース 今回は①と②についてまとめてみます。 ①主体 リソースに対してアクションを起こす主体のことを総称して メンバー と呼んでいます。 メンバー には以下の種類があります。 メンバー Googleアカウント Gメールアドレスとの関連付けが可能です。※所謂普通のGoogleアカウントのことです。 GCPを使用するユーザ（開発者や管理者などなど）を指します。 サービスアカウント アプリケーションやVMに属するアカウントの事です。 アプリの様々な論理コンポーネントを表します。 GCDKのコード実行するときなどに使用されるアカウントです。 わかりにくいですがGCP Service Accountを理解するを読んだら理解できました。 ◦インスタンス・イメージ・アプリコード内に鍵や認証情報埋め込まなくてよいっていうのがポイントっぽいです。→(・・? ('ω')｡oO(たぶん、AWSのIAMロールに近い感じ…) Googleグループ Googleアカウントとサービスアカウントをグループ化できます。 ◦まとめてアクセスポリシーの適応などが可能です。 workspaceドメイン 「～.com」のような組織のインターネットドメイン名ごとのアカウントです。 workspaceにユーザを追加することで、Googleアカウントが作成されます。 Cloud Identity Google管理コンソールにて、ユーザとグループが管理できます。 50ユーザまで無料ですが、GoogleドキュメントやGoogleドライブなど使用できないサービスもあります。 workspaceドメインに似てます。 ②アクション 特定の権限・操作をまとめたものを ロール と呼んでいます。 ロール には以下の3つの種類があります。 ロール 基本ロール GCP側で準備してくれている役割ごとのロールのことです。 以下の3つがあります。 閲覧者 ◦読み取り専用 　　　　◦既存リソースやデータの表示が可能 編集者 ◦閲覧者権限含む ◦状態を変更するアクションが可能 　　　　◦既存リソースの変更 　　　　◦アクセスの変更削除　　など… オーナー ◦編集者権限含む ◦管理者権限 　　　　◦メンバーの追加や削除が可能 　　　　◦プロジェクトおよびプロジェクト内のすべてのリソースの権限とロールを管理 　　　　◦プロジェクトの課金情報を設定　　などなど 事前定義ロール 特定のリソースに対するロールのことです。 GCPリソースへのアクセス権を細かく決められるため、他のリソースへの不正アクセスなどを防ぐことができます。 いくつかあるうちの何個か('ω')ノ Compute管理者ロール：Compute Engineリソースに対する全アクション許可 ネットワーク管理者ロール：ネットワークリソースの作成・削除可能 ◦※FWやSSLには適応外✖ ストレージ管理者ロール：ディスク・イメージ・スナップショットの作成・削除可能 ◦※プロジェクトのイメージ管理者にプロジェクトの編集者ロールを渡したくないな…って時に使える カスタムロール カスタマイズが可能なロールになります。 事前定義ロールよりも自分好みの権限の組み合わせにできます。 多くの企業では、　 最小権限モデル 　が採用されているらしいです。 ユースケース インスタンスオペレーターロールを定義！ ユーザにこのロールを付与することで、「VM起動・停止は可能だが再編成はできない」という権限を持ったユーザを発動！ バインディングとポリシー バインディング メンバーとロールの紐づけを バインディング と呼びます。 AWSの時はなかった概念の気もするが、強いて言えばterraform使って構築するときのアタッチメントなんちゃらみたいなやつ…？ バインディングでは条件を決めることができます。 条件でインスタンス名等を指定できます。AWSの IAM Policy的な奴だと思います。 ポリシー バインディングをまとめたものをポリシーと言います。 誰がどのロールを持つかをまとめたものがポリシーです。 リソースは、上の階層（親）からポリシーを継承となります。 IAMポリシーの階層はGoogle Cloudリソースの階層と同じです。 強さで言うと、「制限の緩い親ポリシー＞制限の厳しいリソースポリシー」になります。 親レベルで付与されたアクセス権を子ポリシーで制限はできないです。 って事で最小限で付与していくのがベストプラクティスになるってことですね('ω') さいごに（かんそう） 権限の分断などが細かくできるので、複雑には見えますが使いこなすとかなりいい感じに開発・運用ができるなと思いました。 特に大人数でいろんな立場の人がいるプロジェクト等ですとかなりいい感じに思います。 ポリシー継承のIAMの決まりなども複雑なので、GCPのリソース階層とIAMの関係についても今後まとめてみたいと思います。 投稿 【学習メモ】GCPのIAMについて調べてみた は マイナビエンジニアブログ に最初に表示されました。

はじめに ITD 2部1課 のM・Sです。 CSS Gridを学ぶ際に、面白いサイトを紹介していただいたので共有させていただきます。 そもそも、CSS Grid とは？ CSS Grid Layout（グリッドレイアウト） は、二次元のレイアウトをCSSで自由に操作できる機能です。 格子状のマス目にグリッドを好きな順番におけたり するので複雑なレイアウトを従来よりも簡単に実装することができます。 ↓みたいなレイアウトを簡単に実装できる。 なぜグリッドレイアウトがいいのか 従来のWebサイトでは、 flex を使用してレイアウトを作成していきます。 flex とは、横並びのレイアウトを簡単に実装できるプロパティーです。 flexでも、十分レイアウトすることはできるのですが、問題点として、 "無駄なネストが増える" "要素の並び替えが難しい" という問題点がありました。 こちらの画像のようなレイアウトを実装しないといけない場合。 flexでは、こんな感じで実装します。 <style> body { width: 200px; } header, nav, article, footer { border: solid 1px #333; box-sizing: border-box; } header { height: 30px; } div { display: flex; } nav { width: 30%; } main { width: 70%; } article { display: block; height: 30px; } footer { height: 30px; } </style> <body> <header>タイトル</header> <div> <!-- ←横並び用のdivタグ --> <nav>ナビ</nav> <main> <article>記事1</article> <article>記事2</article> <article>記事3</article> <article>記事4</article> </main> </div> <footer>フッター</footer> </body> タイトル + ナビと記事の横並び + フッター のようなイメージですね。 シンプルなレイアウトでさえ、divタグのように ネストしてしまっていることがわかります。 gird だと、こんな感じで実装します。 <style> header, nav, article, footer { border: solid 1px #333; box-sizing: border-box; } body { width: 200px; display: grid; grid-template: repeat(6, 30px) / 30% 70%; } header { grid-area: 1 / 1 / span 1 / span 2; } nav { grid-area: 2 / 1 / span 4 / span 1; } main { grid-area: 2 / 2 / span 4 / span 1; } article { display: block; height: 30px; } footer { grid-area: 6 / 1 / span 1 / span 2; } </style> <body> <header>タイトル</header> <nav>ナビ</nav> <main> <article>記事1</article> <article>記事2</article> <article>記事3</article> <article>記事4</article> </main> <footer>フッター</footer> </body> タイトル + ナビ + 記事 + フッター のコンテナごとに 二次元配置が可能になるため簡単に実装することができます。 今回の例だとdivタグがあるかないかの差ですが、 要素が増えれば増えるほどこのネストが発生するので、 flexの使いすぎで深いhtml構造になってしまう ということでできることなら grid を使っていきたいですね。 さらに上記では活用していませんが、 grid は順番を気にせず配置できる ので、レスポンシブ等で 表示の順番が大きく変わる際にも対応することが可能 です。 なので今回は、flex を卒業すべく、gridに触れてみようと思います！ gird をゲーム感覚で学べる GRID GARDEN そんな、gridレイアウトですが、学べる教材がかなり少ない印象です... 紹介記事などはあるのですが、実際に手を動かしながら学べる教材が殆どありません ... そこで紹介いただいたのが、"GRID GARDEN" でした。 全28ステージあり、gridで使われるプロパティーを色々学ぶことができます。 例えばステージ1だと、 こんな感じで穴埋めのgrid-colum-startのプロパティーが空欄でそれを入れていくという感じですね。 こんな感じで28ステージあるのですが、大体、30分くらいで全ステージできました！ Gridレイアウトのプロパティーは一通りさらえたかなという印象でした。 Gridを使ってみたいといった方には、おすすめの内容な気がします！ ですが、内容としては "どういうプロパティーがあるか知る" がメインなので もう1アウトプットあればいいなと思いました。 余談 FLEXBOX FROGGY 同様のゲームで flex も学べるみたいです。 他にも面白そうなcssのゲームがありそうですが、紹介した2つ以外は有料っぽいですね https://flexboxfroggy.com/#ja アウトプットしてみる Grid 用いた面白そうな模擬コーディングを探してみたら、良さげな課題があったのでこれを軽くやってみようと思います。 普通のwebサイトでも活用先はあると思うのですが、管理画面の方が1画面で写すコンテンツが多い関係上、gird がより効果的だと思ったのでこれにしました。 課題 https://codepen.io/TurkAysenur/pen/QWyPMgq 実際に書いたコードが こちら です。 (あくまで grid の学習なので、完璧には模写していないのとクラスの命名などをあまり考慮せず実装しています...) ▼画面 PC (1075px ~) ▼画面 タブレット (900px ~ 1075px) ▼画面 SP ( ~ 550px) コードに関しても軽く触れます。 girdの部分のみ抜き出してみました。 こんな感じになります。 <!--簡略版 詳細は上記をご覧ください。--> <body> <h2 class="header-left">TASK MANAGER</h2> <aside class="sidebar">...</aside> <div class="header-right">...</div> <div class="tasks">...</div> <div class="detail">...</div> </body>`` //grid body { display: grid; grid-template: 70px 1fr / 360px 420px 1fr; .header-left { grid-area: 1 / 1 / span 1 / span 1; } .sidebar { grid-area: 2 / 1 / span 1 / span 1; } .header-right { grid-area: 1 / 2 / span 1 / span 2; } .tasks { grid-area: 2 / 2 / span 1 / span 1; } .detail { grid-area: 2 / 3 / span 1 / span 1; } } @media screen and (max-width: 1075px) { body { .tasks { display: none; } .detail { grid-area: 2 / 2 / span 1 / span 2; } } } @media screen and (max-width: 900px) { body { display: block; .header-left { display: none; } .sidebar { display: none; } } }` 終わりに コード書いた感想ですが、grid を使った方が レスポンシブ対応もはるかに楽だと 感じました。 細かい表示非表示はもう少し書いていますが、レイアウトのレスポンシブは大体これくらいでできます。 かなりスッキリかけた印象です。 まだまだ、使いこなせていないですが、積極的に使っていきたいなと思いました。 以上です。 最後まで見ていただきありがとうございました 投稿 ゲーム感覚で “CSS Grid” が学べる “GRID GARDEN” をやってみた は マイナビエンジニアブログ に最初に表示されました。

はじめに 先日、AWS 認定デベロッパーアソシエイト（DVA）を受験したので、体験記として残します。 これから受験する人の参考になれば嬉しいです。 筆者のスペック 新卒１年目のインフラエンジニア AWS歴　２か月 AWS SAA取得済み AWS認定 デベロッパーアソシエイトとは AWS Certified Developer - Associate AWS DVAはその名前の通り開発者向けの資格です。 公式サイトでは以下の経験を持つ人を本試験の受験対象者と記しています。 少なくとも 1 つの高度なプログラミング言語の深い知識を持つ開発者として勤務した経験 AWS テクノロジーに関する経験 オンプレミス IT の経験、オンプレミスとクラウドのマッピングの理解 他のクラウドサービスでの業務経験 また、AWS認定全体ではアソシエイトレベル（中級者向け）の試験とされており、AWSを用いたアプリケーション開発について1年以上の実務経験を有している人が目安となっています。 試験の内容は以下の通りです。（DVA-C02の場合） 試験時間：130分 問題数：65問（採点対象外15問を含む） 出題形式：択一選択問題または複数選択問題 出題分野： ◦AWS のサービスによる開発 ◦セキュリティ ◦デプロイ ◦トラブルシューティングと最適化 サンプル問題がこちら↓　 （※ AWS Certified Developer - Associate (DVA-C02)試験問題サンプル より引用） Q. デベロッパーは、ユーザーがほぼリアルタイムでコメントを投稿したりフィードバックを受け取ったりできるようにする必要があるウェブアプリケーションを作成しています。 これらの要件を満たすソリューションはどれですか (2 つ選択)。 A) AWS AppSync スキーマと対応する API を作成する。Amazon DynamoDB テーブルをデータストアと して使用する。 B) Amazon API Gateway で WebSocket API を作成する。AWS Lambda 関数をバックエンドとして使用す る。Amazon DynamoDB テーブルをデータストアとして使用する。 C) Amazon RDS データベースによってバックアップされる AWS Elastic Beanstalk アプリケーションを作 成する。長期間有効な TCP/IP ソケットを許可するようにアプリケーションを構成する。 D) Amazon API Gateway で GraphQL エンドポイントを作成する。Amazon DynamoDB テーブルをデータ ストアとして使用する。 E) Amazon CloudFront への WebSocket 接続を確立する。AWS Lambda 関数を CloudFront ディストリ ビューションのオリジンとして使用する。Amazon Aurora DB クラスターをデータストアとして使用する。 AWS SAAとの違い AWSの登竜門的な資格としてAWS認定 ソリューションアーキテクトアソシエイト（SAA）があります。 同じアソシエイトレベルの試験ですが、SAAでは幅広いAWSサービスから表面的な内容が出題されるのに対して、DVAでは限られたAWSのサービスから少し深い内容が出題される印象です。 問われるサービスにも違いがあり、SAAではあまり出題されないCode兄弟（Code Commit・CodeBuild・CodeDeployなど）やAWS CDKやCloudFromationなどの構築系サービスなどからも出題されます。 難易度は個人的にはSAAの方が少し高いかなぁと感じました。 得手不得手あると思いますが、SAAは単純に覚えるサービスが多い印象です。逆にDVAはAWS CLIのコマンドオプションなどの細かい部分も出題されるので、普段からAWSを触っていないと難しく感じるかもしれません。 結果 結果は… 合格しました！！ 772/1000なのでまぁ微妙なスコアですね… SAAより簡単と言ったもののスコアは下がってしまいました。 全セクションのコンピテンシーは満たせているので良しとしたいところです。 高得点ではないですが、一応合格は合格なので自分が勉強した方法について書いておきます。 勉強方法 勉強方法についてですが、まずAWS認定はSAAとSAP以外の試験は学習教材があまり充実していません。 また、試験自体も定期的に更新されるため最新版に対応していなかったりと注意が必要です。 今回受験したDVA-C02に関しても現状対応している参考書はありません。（※11月末にポケットスタディシリーズからC02対応版が出るみたいです。）そのため、本で勉強することが好きな人には辛い試験だと思います。 私がやった勉強は以下の通りです。 Input Udemy： AWS認定Developer Associate（DVA-C02）試験対策トレーニング C02版に対応してる貴重な学習教材です。2倍速でさらっと見て試験の雰囲気をつかみました。 Udemy Bussinessで無料で受けられるのはすごくありがたいです。 ただし、これだけだと合格は難しいと思います。 書籍： AWSの基本・仕組み・重要用語が全部わかる教科書 結構前に買った本です。AWSのサービスがどんなものかざっくり知るのに便利ですが、あくまでざっくりなのでほかの資料と組み合わせて使うのがおすすめです。 ハンズオン ：手を動かすことが一番理解につながるので以下の3つ取り組みました↓ ◦ AWS Codeサービス群を活用して、CI/CDのための構成を構築しよう！ ◦ AWS SAMを使ってテンプレートからサーバーレスな環境を構築する ◦ Amazon Elastic Container Service 入門　コンテナイメージを作って動かしてみよう 公式ドキュメント： AWS Documentation 結局ここに行きつきます。詳しくサービスのことを知ろうとするとここを見ることになりますが、読解には訓練が必要です。 その他：ChatGPT（GPT-4） 神です。最近課金してしまいました。 気になったことを投げると参考文献付きで回答してくれるため、学習の効率がすごく上がりました。令和最新版の勉強法です。 ※情報が古い場合もあるため注意が必要です。 Output 模試： CloudTech SAAを受験した際に、Udemyの模試が本番と乖離していると感じたので、契約しました。（検索すれば他にもいろいろあります。） 約5000円で90日間AWS認定全資格の模試が受けられます。 DVAは266問用意されていて分量と難易度がちょうどよかったです。最終的に2周しました。 公式サンプル問題： AWS Certified Developer - Associate Official Practice Question Set (DVA-C02 - Japanese) 公式が20問の模擬問題を出してくれています。解説も充実しているので一度は受けておくのをおすすめします。 私は前日に受けて65%だったのですごく焦りました。 おすすめとしては、まずUdemy＋ハンズオンである程度の内容をインプットしたら問題演習をしつつ、足りない知識を公式ドキュメントやChatGPTなどを用いて補うのが一番効率が良いと思います。あまりインプットで完璧を目指しすぎると沼にはまっちゃう気がします。 試験を振り返って いくつか個人的な教訓です。 前日は睡眠をしっかりとる 試験は130分とまぁまぁ長いです。集中を保つのが大変ですし、問題文も専門用語が多くて解読にエネルギーを使うので万全な状態で臨む必要があります。 試験は早めに予約する 試験日を決め、メリハリを付けて勉強をすることが大切です。試験の24時間前まで予約可能ですが、土日に受ける場合は早めに予約しておきましょう。 ちゃんと手を動かす CI/CDやIaCは実際に試してみないとなかなか理解が深まりません。この記事内で上げたハンズオン以外にもネット上にあるものを使って動かしてみるのが大事だと思います。 まとめ 今回めでたくAWS認定を2冠することができました！ 資格で培った知識を業務で活かせるように頑張ります。 次はSolutions Architect Professionalか Security Specialtyあたりを受けたいと思います。 p.s. ベンダー資格は受験料が高いので、受験料補助制度（1回までは会社から受験料が出る制度）にすごく助けられています。ありがとうございます。 投稿 AWS認定 デベロッパー アソシエイト (DVA-C02)を受けてみた は マイナビエンジニアブログ に最初に表示されました。

はじめに 今年もアドベントカレンダーの季節がやってきました。マイナビからも20人以上のエンジニアが参加して、クリスマスまで毎日記事を投稿します！ カレンダーは毎日更新されますのでお楽しみに！ アドベントカレンダー 2023年12月 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Twitterでも発信中 マイナビの公式Techアカウントでも、毎日更新していきます。 こちらもぜひご覧ください！ @mynavi_tech 投稿 アドベントカレンダー2023開催します！ は マイナビエンジニアブログ に最初に表示されました。

はじめに 皆さん、こんにちは。マイナビエンジニアブログ編集部です！ この度、デジタルテクノロジー戦略本部（以下：デジ戦）の新オフィスリニューアル工事が完成しました！ こだわりが詰まった自慢の新フロアになっています。 今回はそのなかでもTOWN HALLというスペースをメインにご紹介させていただきます。 ぜひこのブログを見て来社気分を味わっていただければと思います。 執務エリア TOWN HALLのご紹介の前に、まずは執務エリアの一部をご紹介させていただきます。 執務エリアはABW(アクティビティベース)を採用し、作業内容や気分によって働くスペースを選択できるようになっています。 ▲全席デュアルモニターまたは湾曲モニターを設置。作業効率を高めて働くことができます。 TOWN HALL TOWN HALL(タウンホール)は、勉強会や懇親会など幅広い用途で活用できるコミュニティスペースです。 執務エリアと隣接しており、ガラス張りの壁には部署名である「Drive Digital Inovasion digital technology strategy division」の文字が！かっこいいですよね。 TOWN HALL内にあるモニターやテーブルは動かすことができるため、会議室とは異なり人数の縛りがなく利用ができるスペースとなっています。 ▲プロジェクターが設置してあるため、プレゼンテーション形式での利用も可能です。 ▲可動式モニターも複数あるため、グループワーク形式での会議も可能です。 ▲壁際にはベンチのような座れるスペースもあるため、多数の社員が集うことができるようになっています。 椅子やモニターなどを移動させて広場のような形にすることもできるので、部署全体での懇親会など大規模なイベントの実施も可能です。 先日もTOWN HALLのお披露目会を行い、多くの社員が飲食を伴いながら交流を深めていました！ ▲お披露目会でデジ戦：坂本本部長がお話をされている様子 「このイノベーティブな空間を利用して、社内外を問わないオープンなコミュニケーションを活発化させ、より良いアイデアが湧き出てくるような場にしていきたいと考えています。 そして、そのアイデアを自ら開発し世の中にご提供していく基点にもなれたらと思っています。」 さいごに 今回は新しくオープンしたコミュニティスペースである「TOWN HALL」をメインにご紹介させていただきました。 今後はこのスペースを利用して、社員のスキルアップのための勉強会や交流を深めるためのイベントなどを行っていく予定です。

はじめに 株式会社マイナビでは実際の仕事を数か月かけて体験していただく就業型インタ―ンシップを実施しています。 本記事はインタ―ンシップに絶賛参加中のK君に就業型インターンシップに参加したきっかけや、実際に参加して経験した業務などをインタビューをさせていただいた内容について記載をします。 自己紹介 情報系の学部に所属している大学3年生です。 大学1年生の時に、HTML／CSS・JavaScriptを授業で習いプログラミングに興味を持ちました。勉強し始めた当初は中々うまくいかず難しいな、と感じていましたが一つ一つ出来ることが増えていく達成感が好きになりました。 就業型インタ―ンシップ参加まで マイナビの就業型インタ―ンシップは「マイナビ2025」経由で応募をしました。情報系の企業に絞って探していた際にマイナビのITコースが募集をしているのを見て、正直マイナビにITのイメージは無かったものの、興味のある教育にも同時に関わることが出来るのではないかと思い応募をしました。 書類選考や面接後から初出勤までは1か月程時間があったので、面接時に聞いた技術のキャッチアップやアルゴリズムを勉強しました。ただ、インタ―ンシップに対して特別準備をするわけではなく自分の知見を更に広めたいという思いから今まであまり触れてこなかった技術を学んでいました。 就業環境について 1日のスケジュール 時間 やること 9：15～9：30 オフィスに出社して1日のタスクを確認 9：30～12：30 タスクを行う・適宜相談 12：30～13：30 お昼休憩（新宿駅周辺でランチ） 13：30～15：00 タスクを行う・適宜相談 15：00～16：30 課会（やったことやお悩みについての共有会） 16：30～17：30 タスクを行う・適宜相談 17：30～17：45 進捗共有・退勤 インターン生は週2～3回の出勤のうち半分程度がリモートワークです。 テスト前や用事がある日にはシフトも柔軟に対応していただくことができました。 オフィス環境 オフィスは新宿駅直結のミライナタワーです。席はフリーアドレスになっていて、出社の時は好きな席に座って作業をします。オフィスには私たちの所属している開発課だけでなく、ＡＩシステム課・マーケティング課・ＲＰＡ課など様々な組織の方が働いています。毎日座席が違うので気分も変わりますし、オフィスからはスカイツリーなど東京の景色が一望できるのがお気に入りのポイントです。 私は今回のインターンシップで初めて企業のオフィスに入りました。それまではエンジニアはパソコンの前でプログラミングをする事だけが仕事なのかな、と思っていましたが実際に足を踏み入れてみるとそうではなく、ディスカッションなどコーディング以外のこともされていたので驚きました。 ▲会議室での一コマ。大きいディスプレイをみんなで見ながらディスカッション中 仕事内容 使っている技術について プロジェクトにもよりますが、私が参加させていただいたプロジェクトは以下のような技術を利用していました。 PHP データベース 実際にやったこと 社内プロジェクトの機能実装 不明点があればメンターを初めとする社員の皆さんにSlackで質問をしたり、対面で質問をしていました。 学びと感想 本インターンシップは私にとって初めての就業型インターンシップでした。エンジニアとして働くということが今まではぼんやりとしたイメージでしたが、インターンシップに参加した事で仕事のイメージがつき、1人ではなくチームで開発をすることがどういうことなのかを理解することが出来ました。 特に印象的だった出来事としてはエラーが起きたときに、メンターの方に質問をしたときのことです。他の業務があったと思いますが優しく、質問をしやすい環境を作って頂き様々な目線でアドバイスをくださいました。結果として業務も成功し、1つ1つ自分の出来ることが増えたときの達成感を味わうことが出来ました。 また、普段1人ではできないようなことにも沢山挑戦をさせていただきました。マイナビ＝自社開発を積極的行っているというイメージもつきましたし、参加前は若手社員の方は「上から言われた指示を淡々とやるのではないか」と思っていましたが様々なことに手を挙げて意欲的にチャレンジをしていらっしゃったのも印象的でした。 ▲メンターの方にエラー内容を相談中 今後の目標 今回、インターンシップに参加して普段自分ひとりでプログラミングをする場合と、企業でチームでプログラミングをしている場合ではレベルにギャップがあることに気付きました。頑張ってそのギャップを少しでも減らせられるようにスキルをあげて行きたいと思います。 様々な年代・バックグラウンドを持った方と働くことが非常に楽しいと感じたので、今後も自分自身を磨いていきたいです。エンジニアとして働きたい、と改めて感じました。 まだまだインターンシップは続くのでもっと沢山のことを吸収できるように頑張ります！