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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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