TECH PLAY

株式会社マイナビ デジタルテクノロジー戦略本部

株式会社マイナビ デジタルテクノロジー戦略本部 の技術ブログ

234

はじめに:AIに 取って代わられる 恐怖よりも、エンジニアとして学ぶべきことの多さに恐怖している 4月で、エンジニアとして4年目に突入しました。まだまだ、エンジニアとして未熟だと痛感する毎日でございます。私は、プロダクト開発に関わる傍ら、AIを組織に導入したりその後の活用を推進するプロジェクトにも属していました。 プロジェクトの進行で必要な知識をつけるために、AIモデルプロバイダーが発信する知識や、LT会・カンファレンス・社外の事例の記事を調べています。その中で感じているのは、エンジニアとして学ぶべきことの多さです。AIについて調査すればするほど、取って代わられる恐怖よりも、「これからエンジニアとしてこんなに学ばないといけないのか…?」と学ぶべきことの多さに戦慄しています。 2026年4月22日(水)に Sansan株式会社Eight主催のテックリードカンファレンス に参加しました。本記事では、そこで感じたことを、それを増強するための書籍・動画で発信されている知識と組み合わせてお伝えしようと思います。 左: 和田 卓人氏(タワーズ・クエスト株式会社 取締役社長) 右: 佐藤 治夫氏(株式会社ビープラウド 代表取締役社長) なお、本記事は 4ヶ月前に書いた記事(AI時代も変わらない、ソフトウェア開発の基礎) の続きという位置付けでもあります。基礎の重要性を改めて確認し、より具体的な「ではどうするか」に踏み込んでいく内容です。 TL;DR(この記事のまとめ) 「AIに取って代わられる恐怖」や「AI爆速開発の焦り」への対応は、分からないことを放置せず基礎をコツコツ学び続けること。 AIは「簡単さ(Easy)」を極限まで高めたが、システムを「シンプル(Simple)」にしてはくれない。複雑性を切り分け制御できるのは、ドメインや技術を深く理解している人間の役割である。 「1人でAIと爆速開発」というリソース効率の罠から抜け出し、モブプログラミングや Agent Skills による「チームでの意思決定と暗黙知の言語化」へ向かう。 AIエージェントとの関わり方:物的生産性から離れ、対象物を深く理解する カンファレンスでハッとさせられたのは、和田卓人氏の「 AIによる物的生産性に血眼になっているのではないか? 」という問いかけでした。 AIによってコードの記述スピードは劇的に上がりましたが、だからこそ「誰もいらないものを高速に作っても意味がない」状態になっています。和田氏は講演の中で、AIの登場によってプロトタイプを用いた価値の検証が容易になり、「 価値探索とプログラミングがかなり紐づいてきた 」と語っていました。コードを速く書くことではなく、対象物を深く理解し「何を作るか」を探索することに、エンジニアの主眼は移りつつあります。 この「 スピード(簡単さ)に溺れず、理解を優先する 」という姿勢の重要性は、世界的なソフトウェアエンジニアリングの潮流とも完全に一致しています。Netflix のエンジニア Jake Nations 氏による講演「 The Infinite Software Crisis 」では、次のように指摘されていました。 簡単(Easy)はシンプル(Simple)を意味しない。簡単とはシステムに素早く追加できることであり、シンプルとは自分のやった仕事を理解できることだ。簡単を選ぶたびに、私たちは「今のスピード」と引き換えに「後々の複雑さ」を選んでいる。AIは簡単さを極限まで高めたが、シンプルさを生み出すわけではない。 何を作るかを理解し設計することの難しさは、どのツールも排除できません。 また、「 Software Fundamentals Matter More Than Ever 」という講演でも、次のように語られていました。 「コードは安い」という言説は誤りである。悪いコードは今まで以上にコストが高い。変更しにくいコードベースは AI の恩恵を受けられない。 これは私が4ヶ月前に書いた記事でも触れた DORA レポートの「AI は増幅機」という主張と重なります。良いコードベースであるほど恩恵を受けやすく、悪いコードベースであるほど機能不全が拡大する。基礎の重要性は、AI 登場後にむしろ高まっています。 この点について、『ソフトウェアエンジニアガイドブック』(Gergely Orosz 著)の日本語版特別付録インタビュー(p.557)でも、次のように語られていました。 「問題は、経験の少ないエンジニアがAIに『主導権を握らせ』、AIが何をしているのか理解しないまま仕事を全部任せてみたくなるように誘惑されることです。したがって、『AIと共に学び続け、思考をAIに外注しないエンジニア』への需要は増加するものの、その供給はおそらく減少します!奇妙な時代が訪れることでしょう」 理解を放棄してAIに主導権を渡さない姿勢こそが、これからのエンジニアの価値を左右しそうです。 では、AIに主導権を渡さず、自分たちの理解を保ちながら開発するにはどうすればいいのか?  その具体的な対策として和田氏が推奨していたのが、 Test First でやる場所と、Red-Green-Refactor のように小さなサイクルで回す場所を分ける  ことでした。 エージェントに任せても良いと判断した領域では、ざっくりとした Test First で問題ない。一方で、人間がリアルタイムにレビューして品質を担保したい領域では、Diff(差分)の小さい TDD のステップを強制する方がよい。これは、人間が何千行ものファイルを一気にレビューして理解するのは現実的ではないからです。 AIの爆速な出力に流されず、人間の認知負荷を意図的に下げるために、理解できる範囲に留める仕組みとして、非常に納得感がありました。 開発速度の見直し:モブプログラミングの再評価とリソース効率の罠 AIの登場により、コーディング工程は劇的に短縮されたように感じる場面が多くなったのではないでしょうか。しかし、Tech Lead Conference 2026 でのSansan株式会社(笹川裕人氏)のセッションでも指摘されていたように、開発プロセス全体のボトルネックは「コーディング」から「レビューやテスト」へと移動しています。 かつてGitHubが普及した頃、「1人1ブランチで開発できる=リソース効率100%」という発想が、プルリクのレビュー待ちというボトルネックを生みました。今、「コーディングエージェントをN列並列で動かす」という発想も、全く同じパターンにはまる危険性があります。 真のボトルネックは、コードを書くことではなく、人間側の判断・レビュー能力です 。 この点について、和田卓人氏は別の対談動画( AI疲れとジュニアエンジニア育成、モブプログラミングの役割 )で、次のように語っています。 コーディングエージェントによって、実行責任はエージェントへ、説明責任・品質保証は人間へ、という役割分担になっていく。テックリードが担っていた判断の負荷が全員に降りてきた。 AIが多様な要求に対して提案を返してくる中で、その判断を一人で全部こなすのは現実的ではありません。そこで和田氏が推奨していたのが、 モブプロの実施 です。 AI によってコード生成は十分に速くなっていたとしたら、人間はペアやモブを組む余裕があるはずです。複数人でエージェントと関わり、即時に判断していく。この判断を複数人ですることで、知識移転(教育)も行える可能性について言及していました。 そして、この「リソース効率からフロー効率への転換」と「教育」の重要性は、別の動画( シニアのゲームに巻き込まれるな )でも触れられています。 「AIで1日のプルリク量が何倍に」「数日で個人開発アプリを完成」という SNS 投稿に踊らされてはいけない。シニアには元々の積み上げがあるため同じ土俵では勝てない、という主張は、私としては耳が痛い話でした。 圧倒的な積み上げがあるシニアエンジニアと同じ土俵で戦おうとすれば、経験の少ないエンジニアは疲弊し、学びの機会を失います。私も、特に言われたわけではないですが、物的生産性にとらわれて、AIにコード生成させたりレビューさせて、そのまま使うみたいなことがありました。これを、意図的にやっているというより、誰からも要求されていないのに、無理して成果を出そうとしていたなと反省しています。物的生産性を多少下げてでもモブプログラミングの場にジュニアを巻き込み、「チームとしての判断力」と「教育」を両立する構造を作ることが、AI時代には不可欠ではないかと考えています。 開発プロセス:変わらないものと、Agent Skills による専門知識の言語化 AI時代になっても、チーム開発のプロセス全てがひっくり返るわけではありません。Sansan株式会社(笹川裕人氏)のセッションでも、「スクラム等のプロセスの本質(経験的に起きる課題への対処法)は変わらない」とはっきり言語化されていました。 一方で大きく変わるのは、AIという新しいメンバーへの指示の出し方です。合同会社Have Fun Tech代表の曽根武友氏は、「 AI時代における具体と抽象の往復 - 日常にチャンスがある 」というセッションの中で次のように語っていました。 AIへの指示も、結局は人間同士のコミュニケーションと同じ原理。「いい感じにして」が伝わらないのは、プロンプトの抽象度と相手(AI)の抽象度が一致していないから。 具体化には知識が必要であり、相手のドメインで話すにはそのドメインの知識が要る。 この「『いい感じに』という抽象的な指示を具体的な手順に変換するための知識」の重要性は、Anthropicの講演「 Don't Build Agents, Build Skills Instead 」でも強く主張されています。エージェントという曖昧な存在にすべてを丸投げするのではなく、特定のタスクを遂行するための「Skills(専門知識のパッケージ)」を構築すべきだというのです。 AIに的確な指示を出すための「Agent Skills」の整備は、単なるツールの設定ではありません。 チーム内の暗黙知を言語化し、共有知にしていくプロセスそのもの なのです。 国内の企業では、すでにこの「個人の暗黙知から組織の共有知へ」という取り組みが始まっています。 株式会社タイミーでは、「 Agent Harness Group 」という組織を立ち上げ、「個のAI活用」から「組織のAI駆動開発(AI-DLC)実践」へと協業を推進しています。また株式会社LayerXでは、モバイルチームで「 Claude Code Subagents祭 」と題した社内イベントを開催し、属人化しがちなAIへの指示やプロンプトをチームの共有知へと昇華させています。 私自身が推進しているAIエージェント活用においても、ここが最大のポイントになると感じました。単にAIツールを導入するだけで終わらせるのではなく、 Agent Skillsという機能を、AIというメンバーに暗黙知を伝える手段や、組織のベストプラクティスを誰もが簡単に再現できる方法として利用するための仕組みを作っていきたい と考えています。それこそが、AI時代における組織の長期的な競争力の源泉になるはずです。 学習:焦らず、理解を放置しない AIエージェントがコードを爆速で生成してくれる時代において、私たちが個人として取り組むべき最も重要なアクションは、「分からないところを放っておかない」という基本的な学習姿勢です。 Tech Lead Conference 2026でのセッションを通じて、登壇者三者の主張が見事に一致していたのが、この「継続的な学習の重要性」でした。和田卓人氏は、学習について次のように語っていました。 新人は、焦らずに学んでいく必要がある。自分がわからないところを放っておかずにやっていく必要がある。質を下げればスピードが上がるわけではない。トレードオフなのは教育である。質とスピードを担保させるために、教育することが必要になる。 曽根武友氏も、AI が発展しても変わらないこととして「 抽象と具体の往復スキル、ドメイン知識、継続的な学習 」を挙げていました。仕事の形は変われど、この往復の精度を上げることが本質である、と。 さらに、Sansan株式会社 のセッションでも、エンジニアのキャリアパスについて語られていたところで、「 仕事の総量は変わらない——AI で効率化されても別の仕事が生まれる。継続的な学習の必要性は変わらない 」という言葉がありました。この三者の主張は完全に一致しています。 『良いコード/悪いコードで学ぶ設計入門』の著者であるミノ駆動氏も、AI時代に漠然とした不安を抱えるエンジニアに対して、動画( AI時代に“伸びる人・終わる人”の決定的な差 )で次のように指摘しています。 漠然と不安に思っている人は、技術を学んでスキルアップすることが不安の解消に繋がっていると思えていないのではないか。不安を覚えるのなら勉強しましょう。 ミノ駆動氏は、AIは「ネット上の学習内容の平均」に収束する傾向があるため、設計的に問題のある構造でも技術知識がなければ素通りしてしまうと語っています。 AIが60〜70点のものしか出せないのは、指示する人間の基礎力(問題を見抜く力)が足りていないから でもあるのです。 また、ファインディ株式会社の高橋氏の動画( ジュニア育成と組織学習 )では、AI時代のエンジニア評価について、次のような組織側の変化が語られていました。 機能を何個作ったかっていうよりも、何を学んだかをアピールする時代になってきている。 これは個人の姿勢だけでなく、組織側にも問われることです。アウトプットの量だけを評価指標にすると、生成AIでいくらでも量産できてしまい、本当の力が見えなくなります。「何を学んだか」を評価し、基礎力を高め続ける仕組みを持っているかが、これからの人材育成の分かれ目になります。 最後に、和田卓人氏が別の対談動画の結びで語った、若手エンジニアに向けた言葉を引用します。 自分の能力をコツコツ上げていくことが、自分の競争力を上げていくことにそのままより大きく繋がる時代になってきたと思ってください。…(中略)… 焦らずにコツコツやっていけばいい。希望を持つ上でのコツは、人と比べないことです。比べるのは過去の自分です。 SNSを見れば、AIを使って爆速で開発している人がいくらでも目に入ります。しかし、そこで焦って理解を放棄するのではなく、自分の分からないところを放置せずにコツコツと基礎を積み上げていく。それこそが、AI時代を生き抜くための最強の生存戦略なのだと、改めて心に刻みたいと思います。 まとめ:教育とフロー効率を両立する3つの方向性 4つの観点を通じて感じたのは、ひとつの共通したメッセージでした。 AI は「理解の代替」ではなく「理解の加速器」として使う。 そのために、私たちが明日から取れる具体的なアクションは、以下の3つに整理できると考えています。 1. 物的生産性に流されず、対象への「理解」を深める姿勢と仕組み化 AIによる爆速なコード生成に流されず、「自分が理解できないもの」を放置しないことが第一歩です。分からない概念があればAIに説明させて基礎をコツコツ積み上げる「個人の学習姿勢」を持つと同時に、Test First でざっくり任せる領域と、Diffの小さいTDDのサイクルで回す領域を分け、人間の認知負荷を意図的に下げる「開発の仕組み」を取り入れること。アウトプットの量ではなく、「何を学び、どう理解したか」を重視する姿勢が問われます。 2. モブプログラミングによる判断とレビューの分散 一人がエージェントと対話して爆速で開発するリソース効率の罠から抜け出し、複数人のチームで専門性を持ち寄りながら判断するモデルへ。チームにジュニアが参加することで意思決定の OJT にもなる——教育とフロー効率の両立策として、今後試していきたい方法論です。 3. Agent Skills による組織のベストプラクティスの再現 「いい感じに」という抽象的な指示を具体的な手順に変換する Agent Skills は、単なるツールの設定ではありません。 チームのベストプラクティスを「AIという新しいメンバー」に伝える手段 として捉え直す必要があります。 実際に、株式会社タイミー では「 Agent Harness Group 」を立ち上げて AI との協業を組織的に推進していますし、株式会社LayerX では「 SubAgent 勉強会 」という知識共有の場を作っています。誰もが組織のベストプラクティスを簡単に再現できる仕組みを、社内でも作っていきたいと考えています。 おわりに AI にとってかわられる恐怖よりも、学ぶべきことの多さに恐怖している——というのは、裏返せば「学べば学ぶほど武器になる」ということでもあります。Tech Lead Conference 2026 で登壇者たちが口を揃えて言っていたのは、「 基礎知識を持つ人間がこれまで以上に価値を持つ 」ということでした。 特に4年目という、中途半端な立ち位置にいる自分にとって、和田卓人氏の「焦らずコツコツ自分の能力を上げていけば、それがそのまま競争力につながる時代になってきた」という言葉は、強い励みになりました。 焦らず、分からないところを放っておかず、基礎をコツコツ積み上げていく。その上で、AI を理解の加速器として使う。それがAI時代にエンジニアとして今後も活躍するための必要な考えかもしれません。 最後まで読んでいただきありがとうございました。
アナリティクス推進課の新井です。当課は、マイナビ全社のデータ活用/BI活用推進のため、TableauやPower BIのビジネス部門への導入支援、ツール利用サポートを行っています。 はじめに マイナビでは、BIツールの運用においてTableauを使う部門とPower BIを使う部門の両方が存在します。利用者には利用者の要望や都合があるため、アナリティクス推進課として利用するBIツールを制限していません。従って、BIツール活用の推進を行う当課としては、TableauとPower BIのどちらのツールに対しても知見を持つことが求められます。世間一般のビジネスデータ活用シーンからすると少数派の環境だと思いますが、なかなかおもしろい経験が得られます。 私がBIツールを使い始めたのはTableauが先でしたが、現在はPower BIを併用し始めてから時間も経ち、一定の知見がたまってきた感覚があります。また当社の本格的なBIツール導入もTableauの方が先でしたが、後発のPower BI利用者も増えてきており、どちらのツールに対しても導入支援や問い合わせ対応を行っています。このようにTableauとPower BIの両ツールを併用していると、Power BIを使っているときに「Tableauだったら○○の機能でできるからあっちの方が使いやすいな…」と感じたり、またその逆も起こり得ます。そこで今回は、実際に両ツールを使いながら私が感じた「UX(ユーザー体験)における大きな印象の違い」を1つご紹介します。なお本記事では、 BIツールを利用する上でのテクニックに関する話は出てきません! (すみません) Tableauを利用したデータ加工~ビジュアライズ Tableauにおけるデータ加工はTableau Desktopでも行うことが可能ですが、複雑な加工や大規模な処理を行う場合はTableau Prep Builderを使う方が効率的です。両ツールは役割分担・住み分けが明確であり、 基本的に、データの加工はPrep、ビジュアライズはDesktopで行ってくださいというTableau(Salesforce社)からのメッセージを感じます 。 常にPrepとDesktopの両方を起動させておく必要はありませんが、状況によっては両方起動させなければならないこともあり、その場合両ツールを稼働させる分メモリも使うのでPCの動作が重いと感じることもあります。加えて「 両ツール間を行ったり来たりしなければならない 」という心理的な負荷も少し感じます(これは個人差もあると思いますが)。 以下の画面は、Prepで作成中のフローにおいて、フローの途中時点でデータがどうなっているか確認しようとしているところですが、ポップアップメニューに「Tableau Desktopでプレビュー」と表示されています。ここをクリックすると、Tableau Desktopが起動し、フローの途中時点のデータがDesktopで読み込まれた状態になります。そのままグラフ化などの検証を行うことが可能です。 ボタンなどのUIの原則として「クリック後に何が起こるか分からない曖昧な表現のテキスト、説明文を記載すべきではない」という考え方がありますが、この「Tableau Desktopでプレビュー」という記載は、クリック後に何が起きるかが分かりやすく、親切な表現であると言えます。 Power BIを利用したデータ加工~ビジュアライズ 一方、Power BIを使ってビジュアライズを行う場合、その前段階となるデータ加工はPower BI Desktop内の「データの変換」機能で行うことができます。この機能を使って大元のデータソースを読み込み、変換・加工処理を行い、Power BI内に読み込んでいきます。読み込み完了後にモデルビューで複数テーブル間のリレーションをはることもできますが、リレーションはあくまで論理結合であり、簡易的な関係性を持たせるに留まります。物理的な結合を行う場合は、「データの変換」機能の中で行うことができます。このあたりの概念は、Tableauに似ていると感じます。 …ということで、ここまで読んだ方は「Power BIはデータ加工とビジュアライズが1つのツールの中で完結するんだ」という印象を受けると思うのですが、実はこれは100%正確ではなく、「データの変換」は実は Power Queryエディターという別のツールが起動し、その中で行われます 。 以下のキャプチャのとおり、データの変換はPower BI Desktopのウィンドウ内で行われる機能ではなく、新しいウィンドウが開かれそちらで行われるもので、そのウィンドウにPower Queryエディターと明記されています。 UI/UXの違いから勝手に推察する、Microsoftの設計思想 「なんだ、じゃあ結局TableauとPower BIのどちらも、データ加工用ツールとビジュアライズ用のツールを使い分ける必要があるってことね」と思った方が多いと思います。それは正しいです。ただ私は、Microsoftには「 ユーザーにデータ加工ツールとビジュアライズツールの2つを別々に使っていると感じさせないUI/UX設計をしよう 」という狙いがあるのではないかと推察しています。 たとえば、Power BI Desktopでデータ加工をしようとしたときにクリックするのは、前述のとおり「データの変換」ボタンです。これはオリジナルである英語版も同様の表現で、「Transform Data」となっています。 日本版 英語版 UIの原則を考えると、この部分のテキストは前述のTableauパートで挙げた例のように「Power Queryでデータを変換する」であってもいいはずで、多少冗長ですがPower Queryエディターが起動することを教えてあげた方が親切であるとも考えられます。他社製品ではないのだから製品名を伏せる必要もありません。ただ、あえてなのかそうでないのかは分かりませんが、Power BIのUIはそのようになっていません。 加えて、Power BIで利用する目的でPower Queryエディターを起動するときの導線は、Power BI Desktopの「データの変換」ボタンであり、単体で起動することはありません。Tableauにおいては、プレビュー目的でTableau PrepからTableau Desktopを起動することもできますが、基本的にはPCのメニューや保存したワークブック/フローのファイルからTableau Desktop、Prepを個別に起動することが多く、両ツールを併用している感覚が強いです。 Power Queryエディターの起動導線がPower BI Desktop内にあることは、Power QueryがPower BI内の一機能であるかのように感じさせることにつながり、両ツールをシームレスに扱える印象を強めていると感じます 。 またそもそもの話ですが、Power QueryエディターはツールとしてはPower BIとは別であるものの、Power BIをインストールするときに同時にインストールされます。ユーザーに後から追加でインストールさせる選択肢をはじめから用意しておらず、ユーザーからすると 別のツールがインストールされたということすら気づきません 。 おわりに 本記事で書いたとおり、TableauもPower BIも、データ加工ツールとビジュアライズツールの2つを起動し使い分けているということに変わりはありません。記事に書いたことをもって両ツールに優劣をつける意図もありませんし、こんないち側面だけをもって優劣をつけることは不可能です。 ただ、UI/UX面では両ツールに大きな違いが垣間見え、その結果私個人が受けた印象も大きく異なっているのは、とても興味深いと感じています。プロダクトのUI/UX設計って大事だなと思いました。 とはいえ、何も考えずに適当な表現を当てただけという可能性も十分にありえますけどね…。真相は一体…!!
法人ディベロップメント課のS.Sです。 マイナビBiz / LIVING の新規開発・保守運用を行なっております。 この記事では、現在、私が関わっている、とあるPJ で、Techtus さまとの協業(オフショア開発)により、PJ を進める中での経験や気づきについて、ご共有できればと思います。(※ PJ は、現在進行中です) オフショア開発事情について気になる オフショア開発の難しい点や良い点について知りたい 経験を踏まえて、次回オフショア開発を進めるならどうしたいか という方には、お力添えになれる記事かと思います。 参照: Techtus とは オフショア開発の3つの良さ 1、開発速度が本当に早い! 協業で開発を進めて頂いた Techtus さまの開発チームの開発速度は非常に早く、こちら側で元々想定していたスケジュールから、1ヶ月以上巻きで進めてもらうことができました。 今回、実装して頂いた開発者は、2名体制でしたが、2画面/日ペースでPR レビュー依頼が届き、レビューコメントへの対応も基本的に 即時返信・対応で、滞りなくスムーズに進んだ 印象でした。 2、にも書いていますが、 技術的なレベルも高く、技術的な詰まりなども、ほぼなく進めて頂けたのも開発速度が早い 理由なのかなと思っております。 2、開発チームの技術力が高い! 本PJでは、Next.js(v15) による開発を進めているのですが、新しい機能活用、技術/SEO提案などが、頻繁に飛び交いながら、PJ が進んでおります。 迅速に、依頼画面を作って頂くだけに止まらずに、 積極的に技術的な付加価値を提供頂き、ともにブラッシュアップして開発を進めていけた のも非常に感謝でした。 3、言語の壁なく、素早く問題解決が進められるスムーズな連携! オフショア開発をする、となった時に最初に思い浮かんだのが言語の壁でした。 しかし、Techtus さまでは、 コミュニケーター(マイナビと Techtus エンジニア間で日本語 / ベトナム語 でやり取りしてくださる人)がいるため、言葉の壁を感じず、いつもの開発のように進めることができました。 また、コードレビュー時には、お互いに英語でのやり取りが可能でしたので、ここも言葉で悩むことなくスムーズに進められた印象でした。 私自身、英語力に関しては簡単な英語の読解ができるくらいのレベルで伝えることには不安がありましたが、今は Google 翻訳があるので、そんなツールも活用しつつ、特にストレスなく対応できました。 やり取りを進めていく内に自然と、Google 翻訳に頼る頻度は減っていくので、さらにスムーズになった印象でした。 (副次的なものですが、初見PRレビュータイミングでは、訳さずに読解することで、英語力が少し上がるのもよかったです。(次は、ベトナム語にもチャレンジしてみたいな。)) オフショア開発で工夫した3つの点 1、ファーストレスポンスを最速で行う オフショア開発では、開発している場所・時間が物理的に違います。 そのため、お互いに相手方の状況が見えません。 したがって、 分からない状態での「待ち」が相当なストレスを生み、開発パフォーマンスに悪影響を与えてしまいます。 なので、普段の開発よりも増して、ファーストレスポンス速度を早めるように意識しました。 これによって、お互いに、分からない状態での「待ち」を作らないことで、互いにノンストレスかつ、滞り少なくトントンと開発を進めることができたのかなと思います。 2、前提を含めた丁寧な説明 オフショア開発では、相手方は、初めて向き合うサービスであることがほとんどです。 自分たちが思っている当たり前や前提がほぼ 0 のため、なるべく丁寧に、前提説明をする ように努めました。 開発を進める中での質問やレビュー時には、 「こうこう、こういう理由で、こんな実装してほしい」 などを 具体的かつ論理的に伝えることで、納得感を持って開発を進めてもらえた のかなと思います。 ※ ここは、工夫した点でも、あり改善余地ありの点でもあるので、そちらに記載します 3、視覚的情報(+数値)を用いた意思共有 言葉の壁はありませんでしたが、開発文化やニュアンス、表現、受け止め方の違いは、あったかなと感じました。 そんな違いを問題にしないために、視覚的情報を用いるように工夫しました。 この手法を用いることで、 見たそのもの、そのままは、どこの誰が見ても基本的には同じように捉えることができます。 数字についても同様です。 なので、視覚的情報と、数値を用いることで、認識ズレを減らせたのかなと思います。 言葉のみの場合: タイトル: タイトルの位置を気持ち下げて、全体としていい感じに中央っぽく見えるようにしてください。 メール欄 メールの入力欄は、今より少し大きめにして、押しやすそうな印象に寄せてください。 パス欄 パスワードの入力欄も、メール欄と同じくらいのサイズ感に整えてください。 ボタン ボタンは角をもう少し丸くして、入力欄との間隔もちょっと広めに調整してください。 視覚的情報を用いた場合: 圧倒的に、後者の方がズレなく伝わることが体感できます。 オフショア開発で苦労した3つの点 1、仕様を認識ズレなく理解してもらうこと 先ほどの工夫の箇所でも書きましたが、 前提や背景知識が違うので、こちら側の当たり前は、相手方の当たり前ではなかった です。 特に、開発初期は、レビュータイミングで、認識がズレていたり、こちら側で当たり前としてしまっていたことが、相手方の当たり前ではないことでやり直しが発生してしまうこともありました。 早めに気づいて改善することで軌道修正はできましたが、当初は苦労しました。 2、開発環境の共有 完全な自チームの場合であれば、AWSを含む各種アカウントの共有がなされている、かつ物理的に近い距離で開発ができ、環境共有に困ることは、ほぼありません。 しかし、 オフショア開発の場合は、各種アカウントの全てではなく、必要なものかつ、共有できるものが限られる中で対応を進めていく 必要がありました。 そのため、開発の進め始めに、あちらの local では動いているが、こちらの local では動かない、というようなタイミングがありました。(Github, Docker 利用をしていたのでベースの共有化はできてはいるものの。。) 3、開発手法や進め方の足並みを揃えること 当初、開発文化が異なるチーム同士で開発を進める中で、 どんな手法を用いて どんな粒度で どんなルールでやっていくか という所の認識合わせが困難でした。 事前に、キックオフ会の実施や、ドキュメントを作成して、足並みが揃うよう努めましたが、やはり、前提や背景、文化が違うもの同士で協業をするというのもあり、 「あ、この観点や考え方もドキュメントに追加しないとな」 というものがボロボロと出てきた印象がありました。 PJ を進める業務を行いつつ、こういった基礎の部分を同時修正していくことに苦労 しました。(もっと早めの段階の問題出しが重要だなと) ただし、ここを軌道修正したことで、様子見やすれ違い頻度も減り、スムーズにPJ が進むようになった印象がありました。 次回、オフショア開発をする時に、気をつけたい3つのポイント 最後に、ここまでの経験を踏まえて、次回、オフショア開発を進める際に、気をつけたいポイントをまとめたいと思います。 1、最初に、開発手法や進め方・ドメイン知識の共有の時間をしっかり取る 今回は、キックオフ(全体のスケジュール感や対応範囲の認識合わせ)に加えて、開発者向けドキュメントを作成し、共有することで、最初の認識合わせを終えました。 しかし、これでは、軌道修正タイミングが遅れてしまうなと反省しています。 最初に、 開発者の認識合わせの時間をしっかりと確保し、その中でこちら側、あちら側のそれぞれの認識を理解しあって、足りないものに気づき補うことで、開発スタートとともに素早くスタートダッシュを切れるようになる と思いました。 早めに問題を浮き彫りにした方が、全体として効率・改善速度は早められますからね。 2、スプリント単位での依頼チケットの丁寧な概要説明と時間の確保 スプリント単位ごとに、チケット依頼タイミングに、概要説明の時間をしっかりと確保し、認識合わせを密にしていきたい です。 このようなやり方は、一見、工数がかかってしまうように感じてしまいますが、これにより、手戻りやスムーズなレビュー・マージができるようになるかと思いました。 チケット内容に、概要記載が前提なので、ある程度打ち合わせを繰り返す中で、OKなものはサクサク進めていけます。 そのため、 最初の最初は、工数かかる体感はあるかもしれないですが、段々とその負荷は減り、認識ズレもなくなるので、全体で見たら、最適な進め方 なのかなと思います。 このようなイメージです。 3、検証環境の対応順序を早めにする 上記の通りですが、次回以降は、local でベースの環境構築ができたら、すぐに、検証環境の準備を進めていくようにしたいです。 デジ戦側・Techtus 側・事業部側が、共通して同じ環境で確認ができる検証環境を先んじて作っておくことで、同じ目線で動作確認や修正を前倒しで進めていくことができるため です。 検証環境の構築は、インフラメンバーへ構築依頼が必要になるため、始めにそう決めておかないといけない部分だと思っており(いきなり依頼は物理的に難しい)、次回、スケジューリングを立てるタイミングで必須で早めの設定と依頼を進めていきたいと思いました。 最後に ここまで、振り返ってみて感じたことの一言でまとめると、 共通認識を早めに、丁寧に、細かくアクションを取ることが重要 ということかなと思いました。 オフショア開発に限らずですが、より文化や背景、物理的な距離、ドメイン知識の違いなどがどうしてもある中で、 早め早めに、「共通認識」を持つ機会を能動的に作っていくことで、そのズレを無くし、スムーズなPJ 進行ができる のかなと思います。 こうして、文章で書いているとすごく当たり前ではあると思うのですが、 当たり前だからこそ、いざやるタイミングで抜けてしまいがち なので、未来の自分が新PJ スタートタイミングでこの記事を見て、戒めようと思います。
はじめに AWS CDK(Cloud Development Kit)を使って、異なるAWSアカウント間(クロスアカウント)でリソースをデプロイする方法を解説します。 対象読者 :AWSちょっとわかるレベル 所要時間 :約60〜90分 実行環境 :Windows PowerShell このハンズオンで学べること CDKプロジェクトの初期化とスタック構成 cdk bootstrap  の仕組みと役割 クロスアカウントデプロイに必要なIAM設定 --cloudformation-execution-policies  による最小権限の実現 cdk destroy  を使ったリソースの後片付け アカウント構成 本ハンズオンでは2つのAWSアカウントを使用します。 事前準備 必要なツール Node.js(v18以上推奨) AWS CDK CLI( npm install -g aws-cdk ) AWS CLI v2 PowerShell AWSプロファイルの設定 本ハンズオンでは以下の2つのプロファイルを使用します。 プロファイル名 対象アカウント 用途 test-111111111111 アカウントA(111111111111) デプロイ先の操作 test-A アカウントB(222222222222)のIAMユーザー CDKデプロイの実行元 ~/.aws/credentials  および  ~/.aws/config  に各プロファイルを設定しておいてください。 Step 1:CDKプロジェクトの作成 プロジェクトディレクトリの作成 mkdir C:\github\cdk-cross mkdir C:\github\cdk - cross cd C:\github\cdk-cross cd C:\github\cdk - cross CDKアプリの初期化 cdk init app --language typescript cdk init app -- language typescript 実行すると以下のようなプロジェクト構成が生成されます。 cdk-cross/├── bin/│ └── cdk-cross.ts # エントリーポイント├── lib/│ └── cdk-cross-stack.ts # スタック定義├── cdk.json # CDK設定ファイル└── package.json cdk-cross/ ├── bin/ │ └── cdk-cross.ts # エントリーポイント ├── lib/ │ └── cdk-cross-stack.ts # スタック定義 ├── cdk.json # CDK設定ファイル └── package.json Note : git config  の設定がない場合、 Unable to initialize git repository  という警告が出ますが、ハンズオンの進行には影響ありません。 Step 2:スタックの実装 エントリーポイントの編集 bin/cdk-cross.ts  を以下のように編集します。デプロイ先のアカウントIDとリージョンを明示的に指定します。 import * as cdk from 'aws-cdk-lib';import { CdkCrossStack } from '../lib/cdk-cross-stack';const app = new cdk.App();new CdkCrossStack(app, 'CdkCrossStack', { env: { account: "111111111111", <em>// デプロイ先アカウントA</em> region: "ap-northeast-1" }}); import * as cdk from ' aws-cdk-lib ' ; import { CdkCrossStack } from ' ../lib/cdk-cross-stack ' ; const app = new cdk . App () ; new CdkCrossStack ( app , ' CdkCrossStack ' , { env : { account : " 111111111111 " , <em> // デプロイ先アカウントA</em> region : " ap-northeast-1 " } } ) ; ポイント :クロスアカウントデプロイでは  env  の  account  と  region  を 必ず明示 する必要があります。省略すると CDK が環境を解決できずエラーになります。 スタック定義の編集 lib/cdk-cross-stack.ts  を以下のように編集します。今回はシンプルなS3バケットを1つ作成します。 import * as cdk from 'aws-cdk-lib';import { Bucket } from 'aws-cdk-lib/aws-s3';export class CdkCrossStack extends cdk.Stack { constructor(scope: Construct, id: string, props?: cdk.StackProps) { super(scope, id, props); new Bucket(this, 'TestBucket', { removalPolicy: cdk.RemovalPolicy.DESTROY, autoDeleteObjects: true }); }} import * as cdk from ' aws-cdk-lib ' ; import { Bucket } from ' aws-cdk-lib/aws-s3 ' ; export class CdkCrossStack extends cdk . Stack { constructor ( scope : Construct , id : string , props ?: cdk . StackProps ) { super ( scope , id , props ) ; new Bucket ( this , ' TestBucket ' , { removalPolicy : cdk . RemovalPolicy . DESTROY , autoDeleteObjects : true } ) ; } } removalPolicy: DESTROY : cdk destroy  実行時にバケットを削除する設定 autoDeleteObjects: true :バケット内にオブジェクトが残っていても削除できるようにする設定(ハンズオン向けの設定です。本番環境では慎重に検討してください) CloudFormationテンプレートの確認 実際にデプロイする前に、CDKが生成するCloudFormationテンプレートを確認しましょう。 cdk synth cdk synth S3バケット・バケットポリシー・Lambda関数(autoDeleteObjects用)・IAMロールが出力されれば成功です。 Step 3:bootstrap(1回目) bootstrapとは CDKでデプロイを行うには、事前に対象アカウント・リージョンに CDKToolkit というCloudFormationスタックを作成する必要があります。これを  cdk bootstrap  と呼びます。 bootstrapのメリット デプロイの自動化 :アセット(Lambda ZIPやDockerイメージ)のアップロード先(S3・ECR)が自動で用意されるため、手動でバケットやリポジトリを作成する必要がない IAMロールの一元管理 :デプロイに必要なIAMロールがまとめて作成・管理されるため、個別にロールを設定する手間が省ける クロスアカウント対応 : --trust  オプションで他アカウントからのデプロイを安全に許可できる 権限の最小化 : --cloudformation-execution-policies  でCloudFormationが使う権限を絞り込める 冪等性 (何度実行しても同じ結果になる性質):すでにbootstrap済みの環境に再実行しても、差分のみUpdateとして適用されるため安全に再実行できる bootstrapはアカウントとリージョンに紐づく bootstrapは  「AWSアカウント × リージョン」の組み合わせごとに1回実行 する必要があります。 アカウントAの  ap-northeast-1  にデプロイ →  aws://111111111111/ap-northeast-1  にbootstrap アカウントAの  us-east-1  にもデプロイしたい →  aws://111111111111/us-east-1  に 別途 bootstrap アカウントBの  ap-northeast-1  にもデプロイしたい →  aws://222222222222/ap-northeast-1  に 別途 bootstrap 同じアカウントでも リージョンが異なれば別のbootstrapが必要 です。 bootstrapで作成されるリソース bootstrapによって以下のリソースが作成されます。 S3バケット (StagingBucket):デプロイ用アセットの保存場所 ECRリポジトリ :Dockerイメージのアセット保存場所 IAMロール群 :CDKがデプロイ操作を行うための各種ロール DeploymentActionRole :デプロイ操作を担うロール CloudFormationExecutionRole :CloudFormationがリソースを作成する際に使うロール FilePublishingRole  /  ImagePublishingRole :アセットをS3/ECRにアップロードするロール LookupRole :コンテキスト情報の参照に使うロール 組織のIAMポリシー制限がある場合 組織(AWS Organizations)のSCP(Service Control Policy)やセキュリティポリシーによって、 各種リソースの作成が制限されている環境 では、bootstrapをそのまま実行できないケースがあります。 その場合は以下のいずれかの対応を取ります。 既存のbootstrap済み環境を使う :組織の管理者がすでにCDKToolkitをセットアップしている場合は、そのまま利用する(追加のbootstrapは不要) 別途ロールを手動作成して利用する :セキュリティチームが承認した最小権限のIAMロールを事前に作成し、 --role-arn  オプションでCDKに指定する cdk deploy ` --role-arn arn:aws:iam::111111111111:role/MyCustomDeployRole ` --profile test-111111111111 cdk deploy ` -- role - arn arn:aws:iam:: 111111111111 :role / MyCustomDeployRole ` -- profile test-111111111111 アカウントAにbootstrapを実行(1回目) 確認ポイント :デプロイ先アカウントにすでに  CDKToolkit  という名前のCloudFormationスタックが存在する場合は、bootstrapは 実行済み です。その場合は本Stepをスキップしてください。 まずはシンプルにアカウントAへbootstrapします。 cdk bootstrap aws://111111111111/ap-northeast-1 ` --profile test-111111111111 cdk bootstrap aws: // 111111111111 / ap - northeast - 1 ` -- profile test-111111111111 成功すると  ✅ Environment aws://111111111111/ap-northeast-1 bootstrapped.  と表示されます。 Step 4:アカウントAへのデプロイ(同一アカウント) まず、アカウントAのプロファイルで直接デプロイできることを確認します。 cdk deploy --profile test-111111111111 cdk deploy -- profile test-111111111111 IAMの変更内容が表示されるので確認し、 y  を入力します。 Do you wish to deploy these changes (y/n)? y Do you wish to deploy these changes ( y / n ) ? y ✅ CdkCrossStack  と表示されればデプロイ成功です。 Step 5:クロスアカウントデプロイの試行(失敗) 次に、アカウントB( test-A  プロファイル)からデプロイを試みます。 cdk deploy --profile test-A cdk deploy -- profile test-A 以下のエラーが発生します。 Could not assume role in target account using current credentials(which are for account 222222222222)User: arn:aws:iam::222222222222:user/test1 is not authorized to perform:sts:AssumeRole on resource:arn:aws:iam::111111111111:role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1 Could not assume role in target account using current credentials ( which are for account 222222222222 ) User: arn:aws:iam:: 222222222222 :user / test1 is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam:: 111111111111 :role / cdk - hnb659fds - deploy-role - 111111111111 - ap - northeast - 1 Note :エラーメッセージ中の  cdk-hnb659fds  はCDK bootstrapが生成するデフォルトの qualifier(識別子) です。 cdk bootstrap --qualifier <任意の値>  で変更可能なため、組織の設定によっては異なる文字列になる場合があります。 本ハンズオンではデフォルト値( hnb659fds )を使用します。 なぜ失敗するのか CDKのクロスアカウントデプロイでは、操作元アカウントBのユーザーが、デプロイ先アカウントAの  DeploymentActionRole  を  AssumeRole(一時的に引き受ける)  することでデプロイを行います。 しかし現時点では、 アカウントAの  DeploymentActionRole  がアカウントBからのAssumeRoleを 許可していない アカウントBの  test1  ユーザーが  sts:AssumeRole  を実行する 権限を持っていない この2つを解決する必要があります。 Step 6:最小権限ポリシーの作成 --cloudformation-execution-policies  とは cdk bootstrap  の  --cloudformation-execution-policies  オプションは、 CloudFormationがリソースを作成・更新・削除する際に使用するIAMポリシー を指定するものです。 デフォルト(AdministratorAccess)の問題点 指定しない場合は  AdministratorAccess (全権限)が使われます。これには以下のリスクがあります。 CDKスタックのコードに誤りがあった場合、 意図しないリソースを削除・変更 してしまう可能性がある 最小権限の原則(Principle of Least Privilege)に反する 組織のセキュリティポリシーに違反するケースがある 最小権限ポリシーを使うべき理由 CloudFormationが操作できるリソースを スタックで必要なものだけ に限定できる 万が一のミスや不正アクセス時の 被害範囲を最小化 できる 組織のコンプライアンス要件を満たしやすくなる 今回のスタックで必要な権限は以下の3つです。 S3 :バケットの作成・削除・ポリシー設定 IAM :Lambda実行ロールの作成・削除・ポリシーアタッチ Lambda :autoDeleteObjects用Lambda関数の作成・削除 ポリシーJSONの作成 @"{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": ["s3:*"], "Resource": "*" }, { "Effect": "Allow", "Action": [ "iam:PassRole", "iam:CreateRole", "iam:DeleteRole", "iam:AttachRolePolicy", "iam:DetachRolePolicy" ], "Resource": "*" }, { "Effect": "Allow", "Action": ["lambda:*"], "Resource": "*" } ]}"@ | Set-Content cdk-minimal-policy.json @ " { " Version " : " 2012-10-17 " , " Statement " : [ { " Effect " : " Allow " , " Action " : [ " s 3 :* " ], " Resource " : " * " }, { " Effect " : " Allow " , " Action " : [ " iam:PassRole " , " iam:CreateRole " , " iam:DeleteRole " , " iam:AttachRolePolicy " , " iam:DetachRolePolicy " ], " Resource " : " * " }, { " Effect " : " Allow " , " Action " : [ " lambda:* " ], " Resource " : " * " } ] } " @ | Set-Content cdk-minimal-policy.json ポリシーをアカウントAに作成 aws iam create-policy ` --policy-name CdkMinimalPolicy ` --policy-document file://cdk-minimal-policy.json ` --profile test-111111111111 aws iam create - policy ` -- policy - name CdkMinimalPolicy ` -- policy - document file: // cdk - minimal - policy.json ` -- profile test-111111111111 作成されたポリシーのARN( arn:aws:iam::111111111111:policy/CdkMinimalPolicy )を控えておきます。 Step 7:bootstrap(2回目)―クロスアカウント対応 なぜ2回bootstrapするのか 1回目のbootstrapは「CDKToolkitを作成する」ための最低限の実行でした。この時点では: --trust  未指定 → アカウントBからのAssumeRoleが 許可されていない --cloudformation-execution-policies  未指定 →  AdministratorAccess  が使われている 2回目のbootstrapでは、これらを正しく設定し直します。CDKToolkitスタックは Updateとして適用 されるため、既存リソースを削除せずに設定を変更できます。 Tips :最初からクロスアカウントデプロイを想定している場合は、1回目のbootstrapから  --trust  と  --cloudformation-execution-policies  を指定することで、2回に分ける必要はありません。 クロスアカウント対応のbootstrapを実行 cdk bootstrap aws://111111111111/ap-northeast-1 ` --profile test-111111111111 ` --trust 222222222222 ` --cloudformation-execution-policies arn:aws:iam::111111111111:policy/CdkMinimalPolicy cdk bootstrap aws: // 111111111111 / ap - northeast - 1 ` -- profile test-111111111111 ` -- trust 222222222222 ` -- cloudformation - execution - policies arn:aws:iam:: 111111111111 :policy / CdkMinimalPolicy 各オプションの意味: オプション 意味 --trust 222222222222 アカウントB(222222222222)からのAssumeRoleを許可する --cloudformation-execution-policies CloudFormationが使うIAMポリシーをAdministratorAccessから最小権限に変更する ✅ Environment aws://111111111111/ap-northeast-1 bootstrapped.  と表示されれば成功です。 補足 :bootstrap再実行によって  CloudFormationExecutionRole  に紐づくポリシーが  AdministratorAccess  から  CdkMinimalPolicy  に切り替わります。 ただし、Step 4でデプロイ済みの  CdkCrossStack  に対して新ポリシーが適用されるのは、 次回  cdk deploy  を実行したタイミング です。 既存スタックのリソース自体はそのまま維持されます。 DeploymentActionRoleの信頼ポリシーを確認 bootstrap後、 DeploymentActionRole  の信頼ポリシーにアカウントBが追加されていることを確認します。 aws iam get-role ` --role-name cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1 ` --query "Role.AssumeRolePolicyDocument" ` --profile test-111111111111 ` --no-cli-pager aws iam get-role ` -- role - name cdk - hnb659fds - deploy-role - 111111111111 - ap - northeast - 1 ` -- query " Role.AssumeRolePolicyDocument " ` -- profile test-111111111111 ` -- no - cli - pager レスポンスにアカウントB( arn:aws:iam::222222222222:root )の  sts:AssumeRole  が含まれていれば正しく設定されています。 Step 8:アカウントBのIAMユーザーにAssumeRole権限を付与 アカウントAのロールを引き受けられるようになりましたが、アカウントBの  test1  ユーザー自身にも  sts:AssumeRole  の権限が必要です。 インラインポリシーのJSONを作成 @"{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:AssumeRole", "Resource": "arn:aws:iam::111111111111:role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1" } ]}"@ | Set-Content assume-role.json @ " { " Version " : " 2012-10-17 " , " Statement " : [ { " Effect " : " Allow " , " Action " : " sts:AssumeRole " , " Resource " : " arn:aws:iam:: 111111111111 :role/cdk-hnb 659 fds-deploy-role -111111111111 -ap-northeast -1 " } ] } " @ | Set-Content assume-role.json test1ユーザーにポリシーをアタッチ aws iam put-user-policy ` --user-name test1 ` --policy-name AllowAssumeCdkDeployRole ` --policy-document file://assume-role.json ` --profile test-A aws iam put - user - policy ` -- user - name test1 ` -- policy - name AllowAssumeCdkDeployRole ` -- policy - document file: // assume - role.json ` -- profile test-A Step 9:AssumeRoleの動作確認 デプロイ前に、実際にAssumeRoleが成功するかを確認します。 aws sts assume-role ` --role-arn arn:aws:iam::111111111111:role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1 ` --role-session-name test ` --profile test-A aws sts assume - role ` -- role - arn arn:aws:iam:: 111111111111 :role / cdk - hnb659fds - deploy-role - 111111111111 - ap - northeast - 1 ` -- role - session - name test ` -- profile test-A 以下のように一時クレデンシャルが返れば成功です。 { "Credentials": { "AccessKeyId": "ASIAXXXXXXXXXXXXXXXX", "SecretAccessKey": "****", "SessionToken": "****", "Expiration": "2026-03-24T19:05:06+00:00" }, "AssumedRoleUser": { "AssumedRoleId": "AROAXXXXXXXXXXXXXXXXX:test", "Arn": "arn:aws:sts::111111111111:assumed-role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1/test" }} { " Credentials " : { " AccessKeyId " : " ASIAXXXXXXXXXXXXXXXX " , " SecretAccessKey " : " **** " , " SessionToken " : " **** " , " Expiration " : " 2026-03-24T19:05:06+00:00 " }, " AssumedRoleUser " : { " AssumedRoleId " : " AROAXXXXXXXXXXXXXXXXX:test " , " Arn " : " arn:aws:sts::111111111111:assumed-role/cdk-hnb659fds-deploy-role-111111111111-ap-northeast-1/test " } } Step 10:クロスアカウントデプロイの実行 再度アカウントBからアカウントAへのクロスアカウントデプロイを実行します。 cdk deploy --profile test-A cdk deploy -- profile test-A ✅ CdkCrossStack (no changes)  と表示されれば成功です。(Step 4で既にデプロイ済みのため変更なしと表示されます) Step 11:後片付け [!WARNING] この手順は  本ハンズオン用に作成した検証環境を前提 としています。 業務システムや他の CDK プロジェクトでも同一アカウント・リージョンで CDK を利用している場合、以下の操作を実行すると 他のスタックやデプロイ処理に影響を与える可能性 があります。 cdk destroy  によるリソース削除 CDKToolkit スタック(bootstrap 環境)の削除 IAM ユーザー/ポリシー/アクセスキーの削除 検証環境以外で実施する場合は、 削除対象が本ハンズオンで作成したものに限定されていること を 事前に十分確認したうえで実行してください。 スタックの削除 クロスアカウント操作の確認ができたら、作成したリソースを削除します。 cdk destroy --profile test-A cdk destroy -- profile test-A Are you sure you want to delete: CdkCrossStack (y/n)?  に  y  を入力します。 ✅ CdkCrossStack: destroyed  と表示されれば削除完了です。 スタックが削除されたことを確認 aws cloudformation describe-stacks ` --stack-name CdkCrossStack ` --profile test-111111111111 aws cloudformation describe - stacks ` -- stack - name CdkCrossStack ` -- profile test-111111111111 Stack with id CdkCrossStack does not exist  というエラーが返れば正しく削除されています。 CDKToolkitスタックの削除 aws cloudformation delete-stack ` --stack-name CDKToolkit ` --profile test-111111111111 aws cloudformation delete - stack ` -- stack - name CDKToolkit ` -- profile test-111111111111 test1ユーザーのインラインポリシーを削除 aws iam delete-user-policy ` --user-name test1 ` --policy-name AllowAssumeCdkDeployRole ` --profile test-A aws iam delete - user - policy ` -- user - name test1 ` -- policy - name AllowAssumeCdkDeployRole ` -- profile test-A test1ユーザーのアクセスキーを削除 まずキーIDを確認します。 aws iam list-access-keys --user-name test1 --profile test-A aws iam list - access - keys -- user - name test1 -- profile test-A 確認したキーIDを指定して削除します。 aws iam delete-access-key ` --user-name test1 ` --access-key-id AKIAXXXXXXXXXXXXXXXX ` --profile test-A aws iam delete - access - key ` -- user - name test1 ` -- access - key - id AKIAXXXXXXXXXXXXXXXX ` -- profile test-A AWSプロファイルの削除 エディタで  test-111111111111  および  test-A  のセクションを削除して保存します。 削除後のプロファイル確認 aws configure list-profiles aws configure list - profiles 削除したプロファイルが表示されなければ完了です。 まとめ cdk bootstrap  は アカウントとリージョンの組み合わせごと に実行が必要 すでにbootstrap済みの環境では 再実行不要 。既存のCDKToolkitをそのまま利用する 組織のIAMポリシー制限がある場合は、 別途ロールを手動作成 して  --role-arn  で指定する cdk bootstrap --trust  でデプロイ先アカウントが操作元アカウントを 信頼する 設定を行う --cloudformation-execution-policies  で  AdministratorAccess を避け最小権限 を使う 操作元アカウントのIAMユーザーにも  sts:AssumeRole  権限 が必要 bin/*.ts  の  env.account  は 必ず明示的に指定 する 参考資料 AWS CDK ブートストラップ AWS CDK で使用する環境をブートストラップする
はじめに 普段の業務で、TypeScript, Ruby, PHPを使ってアプリケーション開発をしているY.Mです。 携わっているプロジェクトの保守運用を行なっていく中で、AWS側でパフォーマンス向上や負荷対策などを検討する機会も増えてきて、これを機にAWSサービスを包括的に学習できるSAA-C03試験を受けようと思いました。 昨日、AWS SAA-C03試験(ソリューションアーキテクト試験)を受験してきました! 当日中に結果が返ってきて無事合格していました。 結果は 1,000点中  773点 (720点以上で合格) でした。 すごい余裕合格!ってわけではなく、残り2週間ぐらいで点数をグンと伸ばしてなんとか合格って感じだったので、そのプロセスを共有できればと思います。 試験形式 65問 130分(うち50問が採点対象) 択一問題・複数選択問題(記述問題はなし) 720点以上で合格(1,000点満点) 出題される65問のうち、50問が採点対象で15問がダミー問題ってのが他の試験と特色が違いますよね...w 【得点率40%スタート】試験4週間前(試験前時点) 当時の自分の実力 基本サービスの図解でのイメージを理解している状態(参考URLは こちら  ) 実務では、CloudWatch, CI/CD自動化, System Managerなどシステムの保守運用で触れている状態(自らの構築・設計経験はなし) 結果 Udemyの  SAA-C03版模擬試験①  を使って、最初の実力を計測しました。 感触 勉強する前は、実務で保守運用で使う数サービスを触っているだけで、自らのアーキテクチャの設計・構築はほとんどありませんでした(ハンズオンでちょっとだけ構築した経験あるくらい)。 その状態でどのくらいで取れるかな〜って受けたら、 そもそも知らないAWSサービス多すぎ(AWS SageMaker, EFS, Direct Connect...) 漠然と知っていて中身を知らないサービスも多すぎ(VPCエンドポイント, セキュリティグループの設定方法) 知っているサービスも深すぎ(S3のストレージタイプ多すぎ) って感じで、得点率が  41%  と合格には程遠いなあと遠い目になりました。 ググって他の受験者の体験記を参考にしてみて、3〜4週間後に、 得点率80%(800点)  を目指そうと目標を立てました。 【絶望の44%】試験3週間前(参考書1冊走破時点) 使用教材 AWS認定資格試験テキスト AWS認定ソリューションアーキテクト - アソシエイト 改訂第3版 (AWS認定資格試験テキスト) 学習内容 教材に載っているのAWSサービスをイメージで暗記( こちら  の拡張版イメージ) S3, EC2などの頻出そうな単語は特徴まで暗記 結果 Udemyの  SAA-C03版模擬試験②  を使って、模擬試験を受けてみました。 感触 大体1週間くらいで参考書を1周しました。 勉強前時点よりもほとんど伸びてなくて、嘘だろ...と思いました。得点率まさかの 44% .... 一通り頻出で出るサービスは抑えたはずなので、大体60%は取れているだろう...とは思ったんですが、とんでもない過信をしていたようです。他の同様の試験も受けてみたんですが、案の定40%台だったので、点数がほとんど伸びていないことを痛感しました。 この結果を受けて、平日の夜もAWS勉強に捧げた時間はなんだったんだ...と1日くらい立ち直れなかったです笑 【一縷の望み】試験1週間前(Udemy動画視聴完了時点) 使用教材 【SAA-C03版】AWS認定ソリューションアーキテクト アソシエイト試験:短期突破講座(300問の演習問題) 学習内容 上記動画で見直す(基礎サービス・合格点到達に必須のサービス) 動画を見ながら、用語・用語詳細・サービス特徴・紛らわしい用語の違い をスプレッドシートにまとめて、自作問題を作成 自作問題・Udemy小テストを使ってアウトプット 動画で出てこない場合は、テキストで補完 結果 Udemyを使って、2回分模擬試験を実施してみました。 SAA-C03版模擬試験③ SAA-C03版模擬試験④ 感触 そもそもテキストだけだと僕の場合歯が立たないと思ったので、動画形式で学べるUdemyを使って、大体2週間くらいでUdemyを1周しました。 参考書を1周して点数が伸びなかったのは、 サービスを全体像で理解するだけでは点数に直結しない そもそもサービスの特徴の大半を抑えられていない シナリオにおいて、技術的な違いを問われた時に、絞りきれない問題が多すぎた といった感じで、用語理解からさらに1段階, 2段階踏み込めていなかったのが敗因だなと感じました。 そのため、Udemyでサービスの全容を掴みつつ、とにかくサービスの特徴(ECS/EKSの特徴, Amazon Kinesisの特徴 など...)、違い(ネットワークACLとセキュリティグループの違い...)などをスプレッドシートにまとめて、簡易的な問題を作成して、通勤時間の電車などで確認していました。 その結果、模擬試験のテストを受けて初めて合格点に届いた試験が現れました(まだまだギリギリですが...)。得点率も平均  64%  まで上がって、少し安心したのですが、試験まで1週間なのであと最低でも10%はあげないといけません。 正直気持ちに余裕はあまりなかったかな...って感じでした。 【合格が見えてきた】試験1日前(模擬試験完了時点) 使用教材 【SAA-C03版】AWS認定ソリューションアーキテクト アソシエイト試験:短期突破講座(300問の演習問題) 学習内容 上記動画で見直す(高得点を狙うサービス) 小テストの復習 結果 試験前日に3回分模試を解きました。 本番レベル模試① 本番レベル模試③ SAA-C03版模擬試験⑥ 感触 最後の1週間は、比較的アウトプット重視で勉強していました。 自分は問題解くことが割と好きなタイプなので、この期間の勉強は結構楽しかったです。 得点率も着々と上がってきて、平均で得点率  74%  まで上がっていました。 自分が予想するAWSのスコアに換算すると  766点  、試験前日になってようやく合格点に届いていそうな感じがしました。 ▼予想スコア換算方法 SAA-C03は、100〜1000点の得点が付与 → 900点分の点数レンジ式:100 + 0.74 * 900 = 766 ※実際のテストでは、すべての設問が採点対象でないことや設問ごとに点数が異なる(らしい)ので、一概に言えないですが目安としてこのくらいって感じで見積もりました。 【あれ手応え何処へ...】本番(受験当日) 試験直後は、「あれ...手応えあんまない...」って感じになりました。 感覚的には、自信あった問題・怪しい問題含めて、もしかしたら40問正解( 100 + 40 / 65 * 900 = 653点 )ぐらいもあり得るな...って不安になってました、、良くて700点かも...って感じにもなってました。あれ?落ちた??って思いましたw 試験を受けて約6時間後に結果のメールが届いたんですが、そこに「 Congratulations! 」と書いてあって、嬉しさよりも、え??見間違えじゃない??って感じで疑いの目をかけてしまっていました。 実際のスコアレポートを見て点数が上回っていたのを確認してから、合格したんだぁと噛み締めてました。 実際は773点だったので、得点率を単純算出すると 74.8% でした。 最後に 得点率推移は下記になります。途中、絶望に打ち拉がれてたんですが、なんとか持ち直して一発合格まで持って行けてよかったです。 期間 得点率 AWSスコア(仮算出) 試験4週間前 41% 473点 試験3週間前 44% 501点 試験1週間前 64% 681点 試験1日前 74% 766点 本番 74.8% 773点 この体験記で、SAA-C03試験を勉強中だったり、これから受ける人へのエールになれば幸いです! 自分もAWSの資格他にもとってみようかな... ちなみに弊社では、資格取得支援制度として、資格取得にかかる受験料を会社が補助してくれるので、こちらも有効活用できます!
はじめに 私たちは、マイナビでの業務で推薦システムの開発や面接対話システムの開発プロジェクトで自然言語処理の技術を使っています。 その知見を深めるべく、2026年3月9日〜13日に栃木県宇都宮市で開催された「 NLP2026 (言語処理学会 第32回年次大会)」に現地参加し、各種発表を聴講しました。 この記事では会場の様子や講演、ポスターセッションの様子をお伝えし、気になった発表についていくつかご紹介します。 言語処理学会とは 言語処理学会が主催する言語処理に関する理論から応用まで幅広く研究発表が行われます。 情報科学に限らず、言語学、心理学、認知科学など多様な分野から参加があります。 毎年3月ごろに開催され、アカデミアだけでなく多くの企業も積極的に参加しており、社会実装を主眼に置いた研究も多くなっています。 ChatGPTの登場から3年あまりがたち、自然言語処理に分野は大きく進展しました。 今回のトピックとしては、LLMの解釈性、法規制・倫理、複雑な対話や図表読解など高度なマルチモーダル研究が挙げられ、実世界での運用を一層意識した会となりました。 開催地の宇都宮について 近年西日本で開催されることが多かったのですが、今回は栃木県宇都宮市で行われました。 会場となったライトキューブ宇都宮は宇都宮駅の目の前で、周辺の飲食店や商業施設など充実していました。 開催期間中に宇都宮では 21年ぶりの大雪 に見舞われましたが、大きなトラブルなく参加することができました。 会場目の前の様子 宇都宮はギョーザの町としても知られていますが、マグロの消費量が上位の地域でもあります。 駅周辺には寿司屋が多数あり、ランチの時間はシャリの大きいお寿司を満喫しました。 会場の様子 初日にはチュートリアル講演、2~4日目は研究発表と招待講演、5日目はワークショップというスケジュールで開催されました。 今回の最終的な参加者は 2316名 、発表件数 797件 で、ともに過去最高の規模で行われました。 この発表件数の増加に対応するため、口頭発表は選考のうえシングルセッション形式のみとなり、ポスター発表が標準形式となりました。 招待講演は以下の2件で、いずれも盛況でした。 松井智子先生「非典型な言語発達と言語使用:発達障害とバイリンガルから考える」 尾形哲也先生「ロボット基盤モデルにおける言語の役割—運動と言語の統合—」 セッション以外のホスピタリティも充実しており、昼時には中庭にキッチンカーが出展されていたり、終日茶菓と飲み物が提供されました。 また、託児所やコワーキングスペースも設置され、幅広い参加者に配慮されていました。 発表の紹介 ここからは、学会を通して気になった発表を簡単にご紹介します。 ハルシネーションから学ぶ:内部表現への介入によるハルシネーション抑制 門谷 宙, 西田 光甫, 西田 京介 (NTT) NTT研究所からの発表でLLMのハルシネーションを低減するための研究です。 LLMが嘘をつく能力を容易に獲得することに着目し、嘘を含むデータでanti-expert LLMを構築し、この出力確率をペナルティとすることでLLMの事実性を向上させることができるという手法です。 この手法では二つのLLMを動かすことによる推論コストを、モデルの統合によって削減する新たな手法を提案しました。 この結果、出力確率の操作ではなくLLMの内部表現に介入して事実性を向上させることができました。 ハルシネーションの原因は知識不足と、知識の想起失敗とされていますが、この手法は後者に効くとされています。 RAGで知識不足を補うだけではなく、本手法のように原因別で対処することでハルシネーションを抑制することができます。 感想・考察 LLMのハルシネーション問題はLLMの登場からずっと問題となってきましたが、最近では内部的なふるまいの研究が進んでおり、この研究もその流れの一つとなっています。 業務でハルシネーションを可能な限り減らさなければいけない場面で、RAG以外で有効な対策だと思いました。 LLM の生成する方言テキストを音声合成したデータによる音声言語モデルの方言理解能力向上 三森 俊祐, 藤田 雄介, 水本 智也 (SB Intuitions) 国産LLMのsarashinaなどで知られるSB Intuitionsからの発表です。 音声言語モデルと方言を話すために、LLMで生成した方言を学習させた結果、方言性能が向上したという研究です。 手法としてはまず標準語を方言の指示プロンプトを与えLLMを用いて方言に翻訳し、これを音声合成で標準語の韻律で疑似方言データを作成する。このデータで音声言語モデルを学習し、方言適応を行いました。 標準語の翻訳と英語の翻訳の比較で実験を行った結果、文法や語彙については学習が成功したことが分かった一方で、実音声特有の音韻変化への適応は難しいことがわかりました。 感想・考察 日本各地で幅広い人に音声対話システムを使ってもらうとしたとき、方言理解が必要になることもあると思われるのでこれからの対話システムの開発で重要な発表だと思いました。 また、合成データのみでモデルの向上が期待できるというのも参考になり、商談や就職面接など機密保持の観点から学習が難しいデータでも合成データによって性能向上が見込めるかもしれません。 Transformer事前学習における最終層隠れ状態ジャンプの抑制 柴田 圭悟, 矢野 一樹 (東北大), 高橋 良允 (東北大/理研), 李 宰成, 池田 航 (東北大), 鈴木 潤 (東北大/理研/NII) Transformerにおける"最終層隠れ状態ジャンプ"の抑制が精度改善に寄与することを示した研究です。 まず、"隠れ状態ジャンプ"とはモデルの隠れ状態(ベクトル)の角度がある層を通したときに急激に変化することを指しています。 Transformerにおいて、この隠れ状態ジャンプが最終層付近でのみ発生していることが確認されており、中間層の冗長性が議論されているようです。 この研究では "Transformerの性能面において最終層隠れ状態ジャンプは悪い現象" と仮説立てています。 発表者は仮説から隠れ状態ジャンプを抑制するような損失計算を設計しています。 また、これを実際にベンチマークタスクで評価し、性能の向上を確認しています。 感想・考察 Transformer内部で起きている現象に着目し、そこから仮説を立て、直観的かつシンプルな修正によって性能改善につなげている点が非常に印象的でした。 近年は、データや評価から仮説を立て、入力、モデルを取捨選択、修正をするアプローチが主流になりつつあり、特にLLMの普及以降、そもそもモデル内部には手を加えないことも増えてきているように感じます。 そのような背景を踏まえると、本研究のようにモデル内部の挙動そのものに焦点を当てた研究は、今後も高い価値を持つと私は考えています。 また、Transformerの発表から9年経過している現在においても、十分に解明されていない現象が存在する点も非常に興味深く感じました。 おわりに 今回は、言語処理学会の様子をお伝えしました。参加してよかった点は、現在の自然言語処理の流れと今後の発展方向を直接把握できたことです。実社会でLLMの活用が一層進むなか、性能向上の方策や安全性の確保などに向けて、多くの示唆を得られました。 次回の開催地は福岡の博多ということなので、ぜひ次回も参加したいと思います。
このシリーズでは、当社のデジタルテクノロジー戦略本部(通称:デジ戦)で働く社員が、どのようにスキルを伸ばし、キャリアの幅を広げてきたのかを紹介します。キャリアチェンジの背景や挑戦のプロセス、日々の学びを通じて、デジ戦で描けるキャリアの可能性をお伝えします。 筆者プロフィール 所属:ビジネスイノベーション第1統括本部 ITソリューション第3統括部 ビジネスシステム部 入社時期:2019年 中途入社 職種:システムエンジニア 経歴: 新卒で鉄道会社に入社し、駅係員などの業務に従事。 2019年2月にマイナビへ中途入社し、企画職としてマイナビ転職フェアのイベント企画に従事したのち、採用支援部門へ異動。 企業の採用を支援する商材の企画やカスタマーサクセス、部門の業務効率化支援などを担当。 2024年10月にデジタルテクノロジー戦略本部へシステムエンジニア職として異動。 現在は、ライフキャリア事業本部の社内システムの開発・保守・運用や、全社の業務ツールの内製開発などを行っています。 はじめに デジ戦への異動が決まったとき、うれしさと同じくらい不安がありました。30歳、未経験でシステムエンジニアとしてやっていけるのか。正直、自信があったわけではありません。 この記事では、私がITに興味を持ったきっかけや、デジ戦へ異動した理由、異動直後に感じたギャップ、現在担当している業務、そしてこれから目指したいキャリアについてお話しします。キャリアチェンジは決して簡単なことではありませんが、これまでの経験がどのように今の仕事につながっているのかをお伝えできればと思います。 現場で感じた違和感が、ITへの入口になった 私がITに興味を持ったのは、鉄道会社で現場の仕事をしていた頃でした。 駅係員として働く中で、「もっと効率的にできるのではないか」「この手間は仕組みで減らせるのではないか」と感じる場面が多くありました。そうした思いから社内プロジェクトに参加し、業務ツールの開発に関わる機会がありました。そこで、ITやデジタルの力で仕事の進め方そのものを変えられることを実感しました。 単に便利なツールとしてではなく、現場の負担を減らし、仕事の質を高める手段としてITに惹かれるようになったのが、この頃だったと思います。 企画職として働く中で、「使う側」から「つくる側」へ気持ちが変わっていった 2019年にマイナビへ中途入社してからは、企画職としてイベント企画や商材企画、カスタマーサクセス、業務効率化支援などに携わってきました。 この時期に特に力を入れていたのが、業務改善です。手作業や属人的な運用を見直しながら、VBA、GAS、BIツールなどを活用して、部門全体の業務効率化を進めていました。 その中で実感したのは、ITは単なる作業効率化にとどまらず、業務の進め方そのものを変える力があるということです。課題を整理し、関係者を巻き込み、運用まで含めて形にしていく経験は、今振り返るとシステムエンジニアとして必要な視点につながっていたように思います。 30歳、未経験でシステムエンジニアへ異動するという挑戦 デジ戦への異動が決まったのは、30歳のときでした。 それまでITツールや業務改善には関わっていましたが、システムエンジニアとしての実務経験があったわけではありません。うれしさはありましたが、それ以上に「本当にやっていけるだろうか」という不安もありました。 デジ戦には、技術畑を一直線に歩んできた人だけでなく、事業側の経験を持つ人や、さまざまな職種を経て今の仕事に就いている人もいます。そうした環境に触れる中で、システムエンジニアとして大切なのは技術力だけではないのだと感じるようになりました。 もちろん、未経験からでも簡単に通用するという意味ではありません。技術を学び続けることは前提です。そのうえで、現場を理解する視点や、業務を整理する力、関係者と認識をそろえながら前に進める力も価値になる。そう思えたことで、自分がこれまで積み重ねてきた経験にも、挑戦する意味があると前向きに捉えられるようになりました。 それでも挑戦しようと思えたのは、「現場や事業の課題を仕組みで解決したい」という思いが自分の中にずっとあったからです。やらずに後悔するよりも、まずは飛び込んでみたい。そうした思いを持つ中で、デジ戦へ異動することになりました。 また、マイナビには、研修やUdemyなどの学習機会に加え、キャリア希望申告や社内公募制度など、挑戦を後押しする仕組みがあります。自分のキャリアを考えながら、次の一歩につなげやすい環境だと感じています。 異動直後の3か月は、知識不足と向き合う時間だった 実際に異動してみると、最初にぶつかったのは想像以上の知識差でした。ベンダー様との打ち合わせではシステム用語が当たり前のように飛び交い、会話の前提も意思決定のスピードも速い。単語そのものは調べれば分かっても、その場の文脈や論点の重みまですぐにつかむのは難しく、最初の3か月は特に苦労しました。 会議が終わるたびにメモを見返し、分からなかった言葉を調べる。必要に応じて生成AIも活用しながら、一つずつ知識の穴を埋めていきました。その繰り返しで、少しずつ理解できることが増えていきました。 また、未経験だからこそ、実務に触れる量を増やさなければ前に進めないと感じ、できるだけ案件に手を挙げるようにしていました。加えて、後輩、先輩、上司を問わず、分からないことは素直に聞くようにしていました。初歩的な質問でも受け止めてくれる雰囲気があり、そのことに何度も助けられました。 今振り返ると、この3か月は知識を増やすだけでなく、未経験の立場で前に進むための姿勢を身につけた時間だったと感じています。 今担当している仕事と、そこで活きているこれまでの経験 現在は、ライフキャリア事業本部の社内システムの開発・保守・運用や、全社の業務ツールの内製開発に携わっています。 システムエンジニアの仕事というと、実装や設計のイメージが強いかもしれませんが、実際にはそれだけではありません。利用部門の要望を整理し、課題を言語化し、関係者と認識をそろえながら、開発や運用につなげていくことも重要な役割だと感じています。 業務では、たとえば以下のような技術・ツールを活用しています。 言語・スクリプト:OfficeScript、VBA、Python、SQL インフラ・クラウド:AWS ツール:Power BI、Power Automate 、Dify、denodo、Reckoner また、生成AIも情報整理や論点の洗い出し、理解が曖昧な領域のキャッチアップなどに活用しています。 ここで活きているのが、これまでの現場経験や企画職の経験です。現場で働いていたからこそ、「使う人にとって無理のない運用か」「本当に役立つ仕組みになっているか」という視点を持ちやすい。また、事業部門での経験があるからこそ、「何の課題を解決したいのか」「どう伝えれば関係者の認識がそろうのか」を考えることにも自然と意識が向きます。 全社横断プロジェクトのPJリーダー経験で、課題を仕組みに変える面白さを強く実感した 私にとって大きな転機のひとつになったのが、全社横断プロジェクトのPJリーダーとして取り組んだ、社内備品共有の仕組みづくりです。 事業部門にいた頃、まだ使える備品が十分に活用されないまま廃棄されていく状況を見て、「社内で共有できる仕組みがあれば、もっと有効活用できるのではないか」と感じていました。 そこから始まったのが、社内備品共有ツール「マイカリ」につながる全社横断のボトムアップ型プロジェクトです。課題意識を持つだけでなく、それを関係者と共有し、実際に使える仕組みとして形にしていく難しさと面白さを、このプロジェクトを通じて強く実感しました。 特に印象に残っているのは、デジ戦の方々と一緒に進める中で、単に機能を作るのではなく、「どうすれば使われるか」「どうすれば運用に乗るか」まで見据えて考える姿勢に触れたことです。立ち上げから約4か月で都内拠点でのリリースにつながり、その後、全社リリースまで進めることができたのは、多くの関係者の協力があったからこそだと感じています。 また、この取り組みは社内にとどまらず、日経GXなど複数の社外メディアにも掲載されました。現場の課題意識から始まったボトムアップの取り組みが、社外からも関心を持って見ていただけたことは、大きな励みになりました。 この経験を通じて、私は「ITを業務改善に活用する」だけではなく、「ITで仕組みそのものをつくる側に回りたい」と、より明確に思うようになりました。 関連リンク マイナビ サステナビリティニュース https://www.mynavi.jp/sustainability/news/2025/10/post_50484.html これから目指したいキャリア システムエンジニアとしては、まだまだ道半ばです。現在担当している社内システムの開発・保守・運用や、業務ツールの内製開発を通じて基礎を固めながら、今後はさらに扱える領域を広げていきたいと考えています。 具体的には、開発言語の幅を広げること、AWSなどのクラウドサービスへの理解を深めることに加え、AIも適切に活用しながら、開発や業務改善の質とスピードを高めていきたいです。 将来的には、既存業務の改善や運用支援にとどまらず、新規事業の創出にも関わっていきたいと考えています。現場や事業の課題を起点に、新しい価値を形にしていくプロセスにも挑戦し、仕組みづくりを通じて事業の可能性を広げられる人材を目指したいと思っています。 そのうえで目指したいのは、技術だけに強い人ではなく、現場や事業のことも理解したうえで、使う人にとって本当に意味のある仕組みをつくれる人です。 これからマイナビのデジ戦を目指したいと考えている方には、新卒・中途を問わず、これまで培ってきた経験や自分なりの視点を強みとして大切にしてほしいと思います。最初からすべてできる必要はありませんが、学び続ける姿勢に加えて、分からないことを素直に周囲に聞き、吸収していく姿勢はきっと力になります。自分の経験やこれまで培ってきた力を、デジ戦でどう活かせるかを考えながら、ぜひチャレンジしてみてください! 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。
はじめに 普段はRuby, PHP, Typescriptを主に使ってアプリ開発をしているITエンジニア4年目のY.Mです。 AWSを勉強していく中で、「サービスめっちゃ多い」とか「どんな用途で使えばいいか毎回忘れる・混乱する」なんて経験ありませんでしょうか? また、実際にAWSを触ってみて、VPC・ECS構築やCI/CD自動化などで「今自分って何でこの操作しているんだろう...」と思うことありませんでしょうか? 自分はもうすぐ社会人4年目を終えるところで、AWSもちょこちょこ触ったりしているのですが、あまり頻繁に構築したりもしていないせいか、悲しいことに忘れてしまうこともかなり多いです。 そこで、どうしたらAWSを包括的にかつ長期的に概念を覚えられて、実務にも活かせるんだろうと考えていました。その時に思いついたのが、今回執筆する AWSの全体像をスーパーマーケットに例える という内容です。身近なものに例えて、脳に長期記憶を促そうといった狙いです。 今回の記事は、 AWSの基本構成を包括的に理解したい AWSの概念を長期記憶化したい といった初級者向けの記事になっています。 私は、実務ではCloudWatchでのログ監視やS3バケットへのデータ格納は使っていますが、正直AWSの理解が断片的であったり、1からAWSサービスを構築した経験はほぼないので、これを機にAWSのサービスを包括的に覚えてみようと思いました。私も実際にこの例えを活用したことで、AWSに対する全体の理解が一気に深まりました。 今回、身近なものに例えていくため、厳密な定義ではないところもあるかもしれませんが、この記事にて 「包括的」かつ「長期的」 にAWSサービス全容の大枠な理解が深まれば幸いです。 AWSの学習ロードマップ 今回、AWSの全体像を掴んでいくにあたって、 AWS学習ロードマップ (制作者 くろかわこうへいさん、小山雄太さん)が非常に有用だなと思ったので、こちらを使って解説していきます。 上記URLから、PDFでAWS学習ロードマップをダウンロードできます(営利目的の使用は厳禁と記載があります)。 こちらの学習ロードマップですが、全部でセクション数が12個あり、大きく3つに区切ると綺麗かなと思ったので、3つに分けてそれぞれ図解も交えて解説していきます。 AWSの基本構成 (Section 7まで) サーバレスなサービス導入 (Section 10まで) 分析・マルチアカウント作成 (Section 12まで) AWSの基本構成 (〜Section 7) AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例 (サービスはめ込み版) 解説 ここでは、スーパーマーケット、隣接する工場やオフィス、そして面している道路を使ってサービスの解説をしていきます。無色・薄い灰色のエリアがパブリック空間(一般市民が出入りできる空間)・濃い灰色のエリアがプライベート空間(専用の人間しか入れない空間)になっています。 AWS(Amazon Web Service) 概要:Amazonが提供するクラウドコンピューティングサービス 例示:地域全体 AWSは、Amazonが提供するクラウドコンピューティングサービスで、シェアNo.1を誇っています。 AWS空間にて、サーバーの構築・管理までを一貫して管理する集合体になります。 実世界では、地域全体と同等になるかと思います。 Route53 概要:ドメイン名を検索してIPアドレスに変換するサービス 例示:自動車のカーナビ Route53は、ドメイン名をIPアドレスに変換することで、コンピュータ内部で通信できるようにする役割を持っています。 例えば、「mynavi.jp」が入力されたら、「3.165.11.119」といったように変換されて通信されます。 これが、実世界では自動車のカーナビ(目的地名を入力し、ナビでもわかるようにピン表示へ変換する)でも同様なことが言えると思いました。 CloudFront 概要:コンテンツを近くから配信し、高速通信を可能にするサービス 例示:配送センター CloudFrontは、コンテンツを近くから配信することで、低遅延・データ転送性能向上を可能にするサービスで、コンテンツをキャッシュする役割を持っています。 実世界では、配送センター(中継所)のようなイメージで、遠方の倉庫から運搬してきた荷物を配送センターで保管し、必要な時に配送センターから届けることで、より短い時間で出荷可能になるのと同様になるかなと思います。例えば、スーパーで発注した食材が必要になった時に、倉庫(県外にあるとする)から出荷すると運送時間に比例して、鮮度やおいしさが落ちてしまうリスクがあります。ただ、配送センターから出荷を行うと、短い運送時間で出荷ができるため、新鮮な状態で食材を届けられるというイメージです。 ACM(AWS Certificate Manager) 概要:SSL/TLS証明書を管理できるサービス 例示:公認バッジ ACMは、SSL/TLS証明書を発行・更新・管理することで、安全な通信の一助を担うサービスになっています。 先ほどの配送センターの場合、配送センター自体が本物なのか、或いは悪徳業者が運営しているのかといった見分けが一般市民からは分かりません。そのため公認バッジを発行することで、本物・信頼の証であることを証明でき、安心安全な運送が提供できることを市民へも理解させることができます。 S3(Simple Storage Service) 概要:データを保存・取得できるストレージサービス 例示:倉庫 S3は、静的なデータ(ファイル・画像など)を保存・取得できるストレージサービスです。 実世界では、巨大な倉庫に例えるのが妥当です。 VPC(Virtual Private Cloud) 概要:専用のプライベート仮想ネットワーク 例示:スーパーマーケットの敷地内全体 VPCは、論理的に分離されたプライベートの仮想ネットワークです。この中で、EC2やRDSなどの個人情報が絡むサービスを設計していきます。 今回は、スーパーマーケットの敷地内全体が、プライベートの仮想ネットワークに該当します。 以降のサービスは、VPC内のサービス(スーパーマーケット内)を中心に解説をしていきます。 Internet Gateway 概要:VPCの内外間で通信を行うサービス 例示:スーパーマーケット駐車場出入口(警備員) Internet Gatewayは、VPC内部とインターネット間を通信するためのサービスです。 グローバルIPアドレスをプライベートIPアドレスへ変換し、セキュリティ機能を担保しながら通信する役割を持っています。 実世界に例えると、スーパーマーケットの駐車場の出入口に該当します。この出入口付近で警備員が立っており、怪しい市民を排除することで、スーパーマーケット内の安全性を高めています。 Public Subnet 概要:ブラウザから直接アクセスすることができる領域 例示:スーパーマーケットの商品陳列エリア Public Subnetは、ブラウザから直接アクセスできる領域になります。 実世界では、スーパーマーケットの商品陳列エリアに該当します。ブラウザを世界中の人間の集まりだとした時に、スーパーマーケットで通常の人間が入れるエリアは限られていて商品陳列エリアは入れるものの、従業員専用のバックヤードや有人レジの中には入ることができません。 Private Subnet 概要:ブラウザから直接アクセスすることができない領域 例示:スーパーマーケットのレジ(捜査側)・従業員専用部屋 Public Subnetに対して、Private Subnetはブラウザから直接アクセスできない領域になります。 実世界では、スーパーマーケット内のレジ(操作側)や従業員専用部屋など、一般の人が入れない領域に該当します。 ALB(Application Load Balancer) 概要:サーバに負荷を分散させるためのサービス 例示:レジの案内係 ALBは、サーバに負荷がかからないように適切に通信量を分散するサービスになります。 実世界では、レジの案内係に例えることができます。買い物客が一つのレジに集中的に並んでしまった場合、レジが混んでパンクしてしまいます。それを防ぐために、レジの案内係を用意して、レジへ均等に人が並ぶように調整することで、人の流れを最適化しています。 ECS(Elastic Container Service) 概要:完全管理型のコンテナオーケストレーションサービス 例示:レジ管理人 ※私の調べた限りだと、AWS学習ロードマップの各Private Subnetに置かれているECSはEC2インスタンスであり、それらのコンテナを管理するサービスがECSだったので、それを基に解説します。スーパーマーケット例では修正しています。 ECSは、アプリケーションを動かすためのコンテナを効率的に自動管理してくれるサービスです。 EC2インスタンスへの通信量に応じて、必要なコンテナ(タスク数)を自動増減してくれる役割を持っています。 スーパーマーケットでは、レジの管理人に例えることができて、レジに待つ人に応じて、稼働するレジの台数を増減する指揮官のような役割を果たします。 EC2(Elastic Compute Cloud) 概要:クラウド上の仮想サーバサービス 例示:レジ本体 EC2は、クラウド上の仮想サーバサービスで、アプリケーション本体を動かす根幹を担っています。 スーパーマーケットでは、レジ本体に例えることができて、店舗自体もレジ(売上収集)が存在するからこそ営業することができます。 RDS(Amazon Relational Database Service) 概要:クラウド上の仮想データベースサービス 例示:PC上での売上管理 EC2がサーバであれば、RDSはデータベースサービスになります。 スーパーマーケットでは、レジの売上データに例えることができて、一般人が入れない場所(今回の例では本社オフィスに置きました)で管理しています。 IAM(Identity and Access Management) 概要:役割に対する権限を管理するサービス 例示:スタッフの従業員証 IAMは、役割に対する権限を管理するサービスで、統合管理にあたってセキュリティを強固にする役割を持っています。 実世界では、スタッフの従業員証が該当します。有人レジの操作や従業員更衣室、本社オフィス内部など、一般の人が立ち入ることが禁止されているエリアにて、スタッフの従業員証(IAMロール)が付与されていれば、そのエリアへ入ることができるイメージです。 NAT Gateway(Network Address Translation) 概要:プライベートサブネット内から外部へ通信をするためのサービス 例示:従業員専用部屋(バックヤード)の出入口 NAT Gatewayとは、プライベートサブネットから外部へ通信するためのサービスになり、EC2インスタンスで構築されたアプリケーションから外部APIの接続など、インターネット側で通信したい時に使われます。 実世界では、バックヤードの出入口に該当します。お店の開店前に、レジでの売上金をATMへ入金する時や、発注商品の受け取りなどを行うイメージです。 CodePipeline 概要:CI/CDを自動化するためのサービス 例示:製品組立の現場監督 CodeDeployとは、アプリケーションを自動化するための管理サービスです。GitHubでソースコードの変更を検知したときに、ビルド・デプロイを一貫して自動で行ってくれる役割を持っています。 これを実世界に例えると、依頼された製品の組み立て・取り付けを監督する現場監督員が妥当です。製品の組み立てから取り付けまで一貫してサポートします。 CodeBuild 概要:自動テストやビルドを実行してくれるサービス 例示:製品の組み立て CodeBuildとは、ソースコードの自動テストやビルドを実行してくれるサービスです。 実世界では、現場監督管理のもとで、依頼分の製品の組み立てを行います。 ECR(Elastic Container Registry) 概要:コンテナイメージの保存・共有ができるサービス 例示:完成製品の保管庫 ECRとは、ビルドが完了したイメージの保存や共有ができるサービスになっています。 実世界では、完成製品の保管庫が近いかなと思います。AWS学習ロードマップでは、NAT GatewayとECRがつながっていることより、従業員がバックヤードから出て製品を確認できるようなイメージです。 CodeDeploy 概要:ソースコードの反映を行うサービス 例示:製品の取り付け CodeDeployとは、ソースコードの反映を行うサービスです。 上記のスーパーマーケットの図の例だと、顔認証システムの製品を取り付けているイメージです。 余談ですが、最近AI顔認証決済というものが出てきていて、事前に登録した本人の顔にクレジットカードを登録しておくと、財布やスマートフォンを出さずに登録したクレカで会計ができるみたいです…笑 世の中の進化で、どんどんデジタル化が進むなあと思い知らされます。 https://jpn.nec.com/fintech/face_settlement/index.html CloudWatch alerm 概要:AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービス 例示:異常検知センサー CloudWatch Alermとは、AWSサービス監視にて使用率が閾値を超えた場合にアラートを検知するサービスです。 実世界では、異常検知センサーが近いと思います。レジが混んできて待ち時間が長くなってきた場合に、スーパマーケット内の異常検知のセンサーの作動・放送が行われるイメージです。作動後は次で説明する「SNS」にて解説します。 SNS(Simple Notification Service) 概要:ユーザへメールを送信するサービス 例示:緊急連絡先センター SNSとは、ユーザへメールを送信するサービスを表しており、対策メンバーへの周知を行う役割を担っています。本ケースでは、Cloudwatch alermからアラートを受け取ったタイミングで、メールを送信するような流れになっています。 実世界では、レジの待ち時間が長くなってきた時にセンサーが発動し、緊急連絡先センターに連絡が届き、当該店舗の従業員へ応援を要請するようなイメージです。 Terraform 概要:オープンソースのインフラコード 例示:街を再現する設計図 Terraformとは、Hashicorp社が開発したオープンソースのインフラコードで、AWSの構築内容をコードで管理するサービスです。 具体的には、街を再現するための設計図のようなイメージです。仮に街で災害が発生して建物や周辺の道路が損壊してしまった時に、設計図が無いと元に戻すことはできません。そこで設計書があることで、万が一街が壊れてしまっても、構築内容を元通りに戻すことができます(ただし、ECSやRDSといった中身のデータは復元できないので注意してください)。 サーバレスなサービス導入(〜 Section 10) AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例 (サービスはめ込み版) 解説 Section7までで説明した基本構成より、オフィス内で分業化をしました。これまでオフィスにあったサービスはシステム部へ、今回説明する部署を総務部へそれぞれ部署を分割しました。総務部の中で、Lambdaを用いたサーバレスなサービスの解説をしていきます。 API Gateway 概要:APIリクエストの集中管理・ルーティング制御を行うサービス 例示:受付窓口スタッフ API Gatewayは、APIリクエストの集中管理やルーティング制御を行うサービスで、どのサービスにアクセスするかを振り分ける役割を担っています。 実世界では、総務部で働いている受付窓口スタッフに該当します。ここで受け取ったお問合せ内容について、誰に仕分けてもらうかを振り分けるのと同等になります。 WAF (Web Application Firewall) 概要:攻撃と思われる通信を遮断するサービス 例示:受付窓口スタッフ (門番役) WAFは、SQLインジェクションやXSSなどの攻撃などと思われる通信を遮断するサービスで、脆弱性を狙った攻撃攻撃に防ぐ役割を持っています。 先ほど説明した受付窓口スタッフは、お問い合わせ内容の仕分けだけでなく、怪しい人が入ってきた場合はオフィスへの侵入を阻止させることで、内部処理を安全に実行することができます。 Lambda 概要:サーバレスでプログラムを実行できるサービス 例示:作業者 Lambdaは、クラウド上に直接プログラムを定義・実行するサービスです。サーバ構築も不要であり、複雑化した機能ではなく1つの機能を実行するときに役立ちます。 今回の例では、作業者(仕分け人、実行者、回答作成者、感謝文面作成+手紙送付者)に例えることができます。このように1つの作業の橋渡し役となる大事な役割を担っています。 DynamoDB 概要:高速なNoSQLデータベース(RDSと対で使われる) 例示:問い合わせ内容の記録簿 DynamoDBは、高速なNoSQLデータベースであり、RDS(高度なMySQLデータベース)とは対で使われる。RDSは高度なSQL操作ができるが取得に時間がかかり、DynamoDBはキーバリュー型(具体例として後述)で高度なSQL操作ができないものの、高速(数ms単位)で取得可能です。 今回の例では、スーパーマーケット利用者から頂いた問い合わせ内容の記録簿として機能を果たします。問い合わせ内容は、名前(キー)と問い合わせ内容(バリュー)で紐づけることができるため、検索が容易で高速に取り出すことができます。 SQS(Simple Queue Service) 概要:メッセージを受信・保存し、順番に送信するサービス 例示:お問い合わせ書類 SQSは、メッセージを受信・保存し、順番に送信するサービスです。 今回の例では、作業者(仕分け人)が仕分けたお問い合わせ書類が保管されており、作業者(実行者)によって処理されるイメージです。 Step Functions 概要:実行対象のワークフローを自動化できるサービス 例示:現場マネージャー Step Functionsは、実行対象のワークフローを自動化できるサービスで、今回はLambda関数を順番に実行する処理を管理しています。 オフィス(総務部)の例では、作業者(回答作成)→作業者(感謝の文面作成+送付)の流れが問題なく動いているかを、現場マネージャーが監視しています。 Bedrock 概要:高機能な基盤モデル(FM)を搭載したサーバレス生成AIサービス 例示:専門家 Bedrockとは、高機能な基盤モデル(FM)に基づいて、サーバレスな生成AIを実現するサービスです。RAGと呼ばれる最新・関連情報を優先的に検索できるデータベースを使い、その知識を基に学習をしています。 実際には、作業者の回答作成の手助けをする専門家が妥当だと思います。専門家の長年培ってきた知識情報を駆使できるため、生成AIに近い表現ができると考えられます。 SES(Simple Email Service) 概要:クラウド型のメール送信・受信サービス 例示:郵便ポスト SESとは、クラウド型のメール送信・受信サービスで、受け取った回答情報を問い合わせをしたユーザへメールを送信する役割を果たしています。 今回の例では郵便ポストに例えられて、回答作成した内容を郵便ポストに投函し、やがて利用者の手元へ届く流れとなっています。 分析・マルチアカウント対応 (〜 Section 12) AWSの学習ロードマップ スーパーマーケット例 スーパーマーケット例(サービスはめ込み版) 解説 Section10の段階から新たに赤枠の部分である、データの分析・マルチアカウント対応・監視体制の強化が加わったことで、活用かつ堅牢であるサービス構成になったのかなという感じがしています。実際にスーパーマーケット版でも、本社オフィスのシステム部が追加されて、それぞれシステム部内で部署が新たに新設されたことで対応できていることが確認できると思います。このように、データの利活用・監視を市街地でも実施していくことで、安全なまちづくりを行える意向が伺えます。 また、追加した部署の概要は下記になります。 データ管理部 :データの分析・可視化を行う部署(Glue, Athena, QuickSight) 店舗監視部 :店舗の設備情報・利用者の動向を監視する部署(AWS Config, CloudTrail, GuardDuty, SecurityHub) 統制部 :店舗全体のルール作成を行う部署(AWS Organizations, ControlTower, Terraform) Glue 概要:DBに登録されているデータの収集・変換を行うサービス 例示:スーパーマーケットの売上データの収集・変換 Glueとは、DBに登録されているデータの収集・変換を行うサービスで、データの分析や可視化をしやすい状態にする役割を持っています(=SQL実行できる状態にします)。 今回の例では、DB=スーパーマーケットの売上データになっており、分析・可視化しやすい状態にします。 Athena 概要:変換されたデータに対して、SQL実行を行うサービス 例示:売上データ(売上高・購買率など...)の分析 Athenaとは、Glueによって変換されたデータに対して、SQL実行を行うことで、データ分析ができるサービスです。 今回の例では、スーパーマーケットでの売上データをデータ単位で見やすくするようにします(例:利用者Aさんは今月10万円お買い物した、利用者Bさんの今月の購買率は40%だったなど...)。これにより、スーパーマーケットの運営改善を行うことができます。 QuickSight 概要:変換されたデータに対して、データの可視化を行うサービス 例示:売上データ(売上高・購買率など...)の可視化 QuickSightとは、変換データに対して、データの可視化を実施できるサービスです。AthenaはSQL実行して指定したデータを抽出するのに対して、QuickSightはグラフを用いて可視化する役割を持っています。 今回の例では、スーパーマーケットの利用者単位での売上高・購買率の可視化などが挙げられます。 AWS Config 概要:AWSの構成情報を管理するサービス 例示:スーパーマーケット内のレジ台数・従業員数の管理 AWS Configでは、EC2やRDSなどのサービスの設定を管理するサービスで、変更履歴も検知しています。 スーパーマーケットの例では、本社オフィスの店舗監視部が店舗内のレジ台数・従業員数を管理しており、変更をした場合は、具体的な日時まで記録しておくイメージです。 CloudTrail 概要:AWS内の操作を記録・保存するサービス 例示:店舗でのレジ利用者の行動監視 CloudTrailとは、AWSの中で行われた操作を「いつ・誰がしたか」という形式で記録・保存するサービスです。 スーパーマーケットの例では、各店舗でのレジ会計時に、利用者のログを記録して監視している表現が近いかなと思います。 GuardDuty 概要:AWS上のセキュリティの脅威を継続的に検出するサービス 例示:店舗の不審者・侵入者検知 GuardDutyとは、AWS上にてセキュリティの脅威がないかを継続的に検出し続けるサービスです。 スーパーマーケットの例では、店舗内で不審者・侵入者がいないかを継続的に検知し続け、発見次第アラートを鳴らすイメージが近いかなと思います。上記で説明した「CloudWatch Alerm」と一定の基準でアラート発動という観点で同一なのですが、それぞれ検知する種類が違いがあります。 GuardDuty:「悪意あるアクセス」を検知(=侵入者を検知) CloudWatch Alerm:「リソースの逼迫」を検知(=混雑状況を検知) SecurityHub 概要:セキュリティ設定・監視を一元管理するサービス 例示:店舗監視部の一覧表示モニター SecurityHubとは、セキュリティ設定・監視を一元管理するサービスを表します。 本社オフィスの例では、店舗監視部が確認している設定情報の管理(AWS config)、利用者の行動監視(CloudTrail)、不審者検知(GuardDuty)を、一覧でモニターに映し出すのと同等になります。 AWS Organizations 概要:複数のアカウントを一元管理するサービス 例示:各店舗リストの保管 AWS Organizationsは、複数のアカウントを一元管理するサービスになっています。 本社オフィスの例では、各店舗(本店舗だけでなく、A店、B店、C店など)のアカウント情報を一元管理するイメージです。 AWS ControlTower 概要:複数のアカウント管理にあたって、AWSのセットアップをしてくれるサービス 例示:各店舗のマニュアルブック AWS ControlTowerは、複数のアカウント管理にあたってAWSのセットアップを行うことで、ベースラインが構築できるサービスです。 本社オフィスの例では、各店舗に対応したマニュアルブックを指します。マニュアルがあることで、スーパーマーケットの規範が成り立つので、本サービスと同等の役割を果たします。 最後に 本記事では、約40のサービスを載せていたAWSの全体像に対して、スーパーマーケットを中心とした街で例えてみました。 それぞれのサービスについての説明もしましたが、各サービスの概要・役割のみの説明で、技術的な詳細な説明はしていないので、気になるサービスは調べていただけたらと思います。 僕もこの記事執筆から、ここで紹介しきれていないサービス含め、さらなるAWSサービスへの理解を深めていけたらと思います! 最後に、スーパーマーケット図示完成版を下記に共有いたします。
法人ソリューション開発課のS・Sです。 マイナビBiz / LIVING の新規開発 / 保守運用を行っております。 私は、前々職で、キャリアアドバイザーを経験しており、 強み弱みを理解し、活かすことで楽しく、結果も出しやすくなる ということを学び、エンジニアという職種でも、この考え方は同様かなと思うので、強み弱みの発見の仕方から、活かし方/対処方法をご共有できればと思います。 関連記事: 開発タスクは、こなせるようになってきたけど、頭打ち感でモヤモヤしているあなたへ | マイナビエンジニアブログ この記事では、 自分の 強み弱みを理解したい 日々の業務で 自分の強みが活かせていない 気がする 強み弱みは把握してるけど、その後の 活かし方がよくわからない という方に向けて、 【得意で戦う、苦手は運用で回避】エンジニアの強み弱み分析と活用術 について、ご紹介します。 先んじて、内容をご理解頂きやすいように、今回の内容の全体像を図に示します。 この図をイメージしつつ、読み進めて頂けますと幸いです。 そもそも、強み弱みとは? 仕事における、強み・弱みとは、何だと思いますか? ↓ ↓ ↓ ↓ ↓ ↓ 強み・弱みは、私なりの解釈では下記だと考えています。 ※ 仕事における強み弱み 強み = 再現可能な行動で、(他者)顧客や組織に対して価値提供できるもの 先天的な性質/性格(活発な性格等) 後天的に身についた習慣(家庭環境や学校環境、会社環境、交友関係等) 組織内での相対的に優れる能力 弱み = 強みの反対(一定の価値提供できる状態にするために、人よりも労力や疲弊を著しく伴うもの) 抽象的かつ漢字が多めで、イメージが湧きづらいかもしれないので、ポケモンで例えてみます。 (ポケモンは、ゲームで少しやっていた程度なので、細かいツッコミは目を瞑ってください🙇‍♂️) くさ、ほのお、みずタイプを用いて考えると、それぞれこんな感じです。 先天的な性質/性格: くさタイプポケモンのくさ技、ほのおタイプのほのお技、みずタイプのみず技 → 通常の1.5倍になる 後天的に身についた習慣: くさタイプだけど、レベルアップで覚えたじめんタイプの技 → くさタイプの弱点のほのおタイプに対抗できる 組織内での相対的に優れる能力: ほのおタイプ5匹の中にいる、くさタイプ → ほのおの弱点のみずタイプに強く、重宝される ここで重要なのは、下記です。 強み弱みは、 絶対的な優劣はなく、相対的 なもの 強み弱みは、 補い合うもの 強み・弱みの見つけ方 次に、強み弱みを活かすには、そもそも、自分が何が 強みなのか? 弱みなのか? を知る必要があります。 強み・弱み分析の3つの方法 方法としては、中長期の過去の経験 × 他者視点 × 短期のログです。 ※ ポイントとしては、主観ましましの「自己評価」だけで決めないこと Step 1:成果3つ/詰まり3つを書き出す(過去1〜2年) 過去の仕事の中での成果、詰まったことなどを3つずつ書き出してみましょう。 出来事ではなく、なるべく「 自分の行動」に寄せて、書き出してみるのがポイント です。 成果が出た仕事: 何が効いた?なぜ再現できた?といった問いをしてみる。 ex) API設計で、エッジケースを事前に洗い出し、手戻りゼロで実装完了 詰まった仕事: どの条件で崩れた?何が不足していた?といった問いをしてみる ex) 複数タスクの並行で、優先度判断を誤り、納期遅延 Step 2:周囲にいるあなたをよく知っている3人に聞いてみる エンジニアであれば、PJ で一緒にお仕事をしているメンバーがあなたのことをよく見てくれているかと思いますので、お力をお借りするのがおすすめです。 質問時に、あまり難しく考えすぎると率直なものが出づらくなります。 なので、 簡単で答えやすい質問をしてみることがポイント です。 ex) 「率直な印象や特徴はなんですか?」 「私に、任せたい仕事の特徴や内容は、何ですか?」 「逆に、任せると心配なポイントってありますか?」 Step 3:直近、1〜2週間の業務ログを取る 下記のような観点で、ログを書いていきましょう。 ex) ・集中できた作業/消耗した作業 ・見積もりが当たった/外れた ・パフォーマンスが発揮できた状況(時間帯、割り込み、前提の曖昧さ、など) ・ミスが出た状況(時間帯、割り込み、前提の曖昧さ、など) Step 仕上げ:3Stepでわかった共通パターンを見つけて言語化する この3つ(実際のデータ、あなたをよく知る他者からの客観的な意見)を行った上で、 共通するパターンを探して、自分がイメージしやすく言語化 しましょう。 ex) 強み: 構造化して考えるのが得意 臨機応変に柔軟な対応が得意 弱み: 集中力の波がある 一人で黙々と作業をすると捗らない 強みの活かし方 ~ 私の強み(共感性・調和性/継続力)と活かした事例 ~ 強み・弱みを理解した上で、それをどのように活かしていくか、について、私の事例をもとに、イメージをしやすくしていただければと思います。 私の強みは、共感性・調和性、1対1 の対話力でした。 意見が割れたり、温度感がズレたりする場面で、相手の背景や意図を拾って言語化する 摩擦を増やさずに論点へ戻す 双方が納得できる落とし所を作る といった形で、チームの安心感(心理的安全)を作ったり、チームの底上げの役割を担うことが多かったです。 もう一つは、継続力・安定性。 短期的な爆発力はあまりないですが、長期的な課題を計画に落とし、期限と品質を安定させて 淡々と前に進めることが強みでした。 それぞれ分かりやすく目立つものではないですが、前職では、さまざまなPJ に参画をしてきて、口を揃えて言ってもらえていたかなと思います。 弱みの対処法 ~ 私の弱み(瞬発判断が苦手)と対処した事例 ~ 一方で弱みは、その場で瞬発的に考えて判断することでした。 会議中に急に結論を求められる、想定外の論点が飛ぶ、といった場面で無理に即答すると精度が落ちやすいです。 実際に、焦って回答しようとしてオドオドしたり、思考が深めきれていない状態で曖昧な回答をして、後で訂正ややり直しが発生してしまうなどの失敗をしたことも多くありました。 そこで私は、この弱みを「克服」ではなく、どうしたら、顧客やチームに対して、悪影響のない形にできるか、最小限に損失を抑えられるかを考えました。 具体的には、下記のように工夫しました。 質問や相談がある場合は、事前に概要をもらっておく その場で解を出さず、宿題化する 自分の時間を確保して整理し、早めに相談・提案する (原則、その日に結論や過程の共有は最低限行う) このような感じで、 なるべく弱みが出ないような仕組みやルールづくりをすることで、対策を行う ことで、スムーズに仕事を進めやすくなったかと思います。 この例では書いていないですが、仕組みやルールに加えて、 チームメンバーがあなたの弱みを補ってくれることも多々あると思いますので、チームメンバーの強みを理解し、協力を仰ぐことも効果的 です。(反対に、自分の強みを活かし、ある人の弱みを補うのは大前提) まとめ ここで、書いた通りですが、自分の強み弱み分析をして、 強みを活かし、弱みを対策することで、お客様やチームに貢献しやすく、日々の業務が楽しく、成果も出しやすくなる んじゃないかなと思います。 私自身、まだまだ模索中ですし、身をもって実験中ですが、もし、今の働き方に行き詰まりを感じていたり、努力しているけれど空回りしてしまっているのであれば、一つの解決策として、お試しになられてみてはと思います。 まず、少しでもやってみることが大切かなと思います。 完璧ではなくてもいいので、できるもの、気乗りするものからお試ししてみて頂けたら嬉しいです。
法人ソリューション開発課のS・Sです。 マイナビBiz / LIVING の新規開発 / 保守運用を行っております。 「開発タスクは、こなせるようになってきたけど、モヤモヤしている」 というあなたに向けて、お悩みやモヤモヤを解消するきっかけになればと思い、この記事を書いています。 自分自身、過去にモヤモヤ期を経験していて、なんとなく改善に向かえている感覚が見えてきたので、 ぜひ、体験談や考えていたことを知っていただくことで、あなたのモヤモヤの解決の一助になれれば幸いです。 内容は、モヤモヤを感じるまで、感じた最中、どう改善したかを思い出しつつ、書いておりますので、もし似たような境遇の方に届いたら嬉しいです。 かっこいい先輩エンジニアをがむしゃらに追いかけていた1~2年目 誰しもが、エンジニアの実務未経験から、右も左も分からない中、諸先輩方にサポートいただきながら、数年ほど、なんとか食らいついて、開発を進めていたのかなと思います。 とにかく、この時期は、先輩方のPJ進行、会議やスーパーコーディング、レビュー、顧客折衝など、 あらゆる点において、圧倒的に推し進める姿に感動し、純粋な気持ちで「かっこいいなぁ。。ああなれるように頑張ろう!!」 というモチベーションで、がむしゃらにも楽しくやっていたものだなと思います。 業務はもちろん、プライベートでアプリを作ってみたり、新しい技術を Udemy や技術書を見てはワクワクが止まらなかったですね。(React? わくわく⭐︎、Next? わくわく⭐︎) この時期は、良い意味で、ほぼほぼエンジニアとしてできることがないので、とにかく勉強、実践の繰り返しだったので、悩みやモヤモヤはほとんどなく、初心者エンジニア期を過ごしていたかなと思います。 1人称開発できるようになるも、次の一手に悩み、モヤモヤ期に突入した3~4年目 PJメンバーとして、新規開発〜リリース、運用保守、新規メンバーメンター等、エンジニアとしての一通りの業務経験を積んで、基本的なエンジニア業務は、1人称で対応できるようになってきたのが、だいたい3年目前後だったかと思います。 (あまり飲み込みの良いタイプではなかったけれど、なんとかおかげさまで) この時期になってくると、そこそこの専門性を出しつつ、開発業務やメンバーサポートなどもできるようになってきて、イメージを形にできるようになって楽しくもありましたね。 その反面、あの頃、憧れていたかっこいい先輩との距離や、そこに至るまでの大変さ、自分のできないことの多さについても、以前より良くも悪くも鮮明になってきました。 「あのかっこいい先輩に近づくためには。。」 ・チームメンバーをリードできるレベルのフロントエンドの知識、実践経験 ・チームメンバーをリードできるレベルのバックエンドの知識、実践経験 ・チームメンバーをリードできるレベルのインフラの知識、実践経験 ・PJマネジメントの知識、実践経験 ・メンバーのヒューマンマネジメントの知識、経験 ・PJ進行や保守運用するためのドメイン、サービスの熟知 ・関連部署との折衝、関係構築力 ・明るさ、前向きさ、エネルギッシュな振る舞い ・精神的/肉体的な体力 他にもあれやこれや、、、 といった感じで、新米エンジニア時代に、ざっくりとかっこいい、と思っていた先輩を構成している要素には、あげればきりがないほどの内容と、それに満たない自分が浮き彫りになり、一人で打ちひしがれてしまってしまいました。 自分で言うのもなんですが、目標達成のために、コツコツと少しずつ努力していくことはわりと得意な方だったのですが、目標の大きさと難しさに、この時は、どうやって良いのか分からなくなってしまいましたね。 とはいえ、先ほど挙げたように、客観的に見れば、足りていないもの、やるべきことは明確なんですけど、主観モードの当時は、本当に絶望に近い状態でしたね。 (そもそも、努力では埋められなさそうなものもあるし...) 落ち込んでいても仕方ないと思い、1つ1つ突破していこうと動き始めるも、モヤモヤが止まらないし、憧れの先輩にも近づけない 一瞬は落ち込みましたが、落ち込んだままでは前に進めないので、少しずつでも良いから、憧れの先輩と自分の差を埋められるように、動き始めました。 技術面に関しては、聞ける先輩や教材、実践させて頂ける環境等に恵まれていたので、自分なりのチャレンジを続けて、ゆっくりとではありますが、憧れの先輩に近づいている感覚は掴めていました。 苦手意識の強かったPJ面でも、サブリーダーや顧客折衝などを少しずつチャレンジさせて頂き、経験を積ませていただきました。 うーん、でもなんだかずっとモヤモヤはあって、常に憧れの先輩のようなエネルギッシュでガンガンと、業務を推し進めていくことはいつまで経っても、埋まっていかないなと感じ続けていました。 これまた、落ち込みましたね。。 うーん。 うーん。。 うーん。。。 あ゛ー。(天を仰ぐ) うーん。。。 ん...!?いや、待てよ。 できたとして、それは継続できるのか? 多分無理。むしろ、そこは弱み。 強みで戦った方がよくない? 自分の強みってなんだ? よく周りから言われることってなんだろう.o0O ・穏やか ・安定感 ・丁寧さ ・傾聴力 ・誠実さ ・共感力 ・継続力 わりと、ここら辺を言われることが多いなと。 憧れてる先輩とは、かなり違った方向性だなと。 憧れの先輩が、攻撃型のミッドフィルダー型なら、自分は、ディフェンス型かなと。 サッカーには、チームとしてどのポジションも必要ですし、どちらも試合に勝つ(敵より1点以上多く取る)、と言う同じゴールを目指してプレーすると言う意味では、適切なところで活躍することが重要ですよね。 この考えに、気づくことができたタイミングで、モヤモヤがパッと晴れて、それまでモヤモヤを抱えながら努力していた他のことに関しても、身が入るようになって、とても良い方向に進んでいきました。 先ほどの性質の部分と同様に、技術面にも強み弱みがあることに気づきました(正確には頭ではわかっていたけれど、腑に落ちた感じです)。 インフラ・バック・フロント・マーケ・デザイン・営業などを全てを100%の超人になる必要はなくて、 例えば、得意がフロント・マーケ・デザイン領域なら、そこを武器として、反対に、インフラ・バックが武器の人と一緒に協力して、PJ開発を進めればいいんですよね。 (なんだか、いつの間にか、全てを完璧にこなせる神を目指そうとしちゃっていることに気づきました) 自分の強みに気づき、強みをチームに還元し、チームからは自分の弱みを補ってもらおう 私がお伝えしたいことをまとめると、ある程度の経験を積んできて、次のステージや更なる成長を目指したい場合は、 無意識的に外に目が向いてしまいますが、ぜひ、自分に目を向けて、自分の強みってなんだろうか、を認識して、その強みを発揮させて業務に活かすにはどうしたら良いか、を考えてみるのが良いのかなと思います。 嘘みたいな本当の話ですが、強みを生かして、チームの力を借りて働くことができると、周りにも感謝されますし、反対に、自分の弱みである点が得意なチームメンバーへの感謝もより強く持てるなと思います。 それでいて、不要なストレスも軽減して、パフォーマンスを発揮しやすいので、本当に良いとこ尽くめだなと感じています。 もちろん、業務をする上で、苦手なことや弱みの部分が出てしまうケースはありますが、そこは、変に焦りすぎずに、業務に最低限必要なレベルをまずは目指して、コツコツ努力や経験で埋めたり、それでも至らない所は、人の力をお借りするのがよいのかなと思います。 最後に この記事は、昔の自分と似た境遇の方に向けて書いた記事なので、もし同じような境遇でお悩みの方の改善のきっかけに少しでもなれたら嬉しいです。 参照元メモ 【得意で戦う、苦手は運用で回避】エンジニアの強み弱み分析と活用術 | マイナビエンジニアブログ
このシリーズでは、当社のデジタルテクノロジー戦略本部(デジ戦)の職場環境やチームの雰囲気、日常のコミュニケーションを社員の視点で紹介します。大切にしている価値観やサポート体制、チームの多様性をお伝えし、働く日常を具体的にイメージしていただける内容です。 コンテンツプランニング統括部2部2課のT.Mです。 マイナビ転職のSEO記事の制作を担当しています。 今の部署に異動してから、もうすぐ1年が経ちます。 振り返ってみて、私が一番強く感じているのは 「とても安心して働けている」ということです。 今回は、その理由を日常のエピソードを交えながらお話ししたいと思います。 定例ミーティングに流れる、穏やかな空気 日々の業務の中で「雰囲気がいいな」と感じる瞬間は、いくつもありますが、 私が特にそれを実感するのが、週に一度の課の定例ミーティングです。 定例には、終始とても穏やかな空気が流れています。 ギスギスした感じは一切なく、仕事の話はもちろん、 ちょっとした雑談も自然に交わされる雰囲気です。 「会議だから身構える」というより、 「みんなで状況を共有する時間」という感覚に近いかもしれません。 失敗を責めない、共有を大切にする文化 定例では、全体数字や成果、各自の進捗状況だけでなく、 思い通りにいかなかったことや、想定外の結果に着地したことについても、 積極的に共有されています。 「良いことも、うまくいかなかったことも、きちんと共有しよう」 このスタンスが、課の共通認識として強く根付いていると感じています。 もちろん共有したからといって、責められることはありません。 結果だけでなく、そこに至るまでのプロセスや背景を大切にしてくれるからこそ、 失敗も隠さず話すことができ、次につながる前向きな議論が生まれているのだと思います。 上長・先輩との距離が近く、相談しやすい環境 私が所属している部署では上長との距離がとても近いです。 相談するとすぐにレスポンスをいただけて、 アドバイスもとても具体的。 アドバイスを踏まえて自分なりに検討し、実行してみた結果、数字がしっかり改善した。 そんな経験を、これまで何度もしてきました。 先輩方も同じで、質問すると気さくに、そして丁寧に答えてくれます。 「怖くない」「一人で抱え込まなくていい」と思えることは、 日々働くうえで、想像以上に大きな安心材料になっています。 提案を「まず受け止める」姿勢 定例は、進捗を共有するだけでなく、 自分なりの考えやアイデアを提案する場でもあります。 どんな内容であっても、 提案を最初から「難しいから無理」と切り捨てられることはありません。 まずはきちんと聞いてもらえる。 だからこそ、「せっかくだから発表してみよう」と、 自然と積極的にプレゼンできるようになります。 この「まず受け止める」空気は、 この課だけでなく、デジ戦全体に共通している雰囲気だと感じています。 柔軟な働き方が、日々の安心感につながる デジ戦では、月の半分を在宅勤務にすることが可能です。 また、課内では時差出勤を活用しているメンバーもいます。 私自身も、将来通勤ラッシュが厳しい路線に引っ越した場合などは、 迷わず制度を使うと思います。 無理をせず、自分の生活に合わせて働き方を選べること。 それが、日々の安心感につながっていると感じています。 安心できるチームで、自分の考えを生かしたい人へ 自分なりの考えはあるけれど、 これまでトップダウンの環境でなかなか提案できなかった人。 そもそも、意見を出す機会がなかった人。 そんな人にとって、 人の意見を否定せず、前向きに受け止めてくれるデジ戦は、 とても相性のいい職場だと思います。 「安心できるチームで、自分の考えをちゃんと仕事に生かしたい」 そう思っている方には、ぜひ一度知ってほしい職場です。 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。
このシリーズでは、当社のデジタルテクノロジー戦略本部(デジ戦)に所属する社員が、「なぜ当社を選んだのか」「入社して何を感じたのか」を率直にお届けします。入社前の期待や不安、入社後のギャップや魅力を通じて、働く環境を具体的にイメージしていただける内容です。 ■執筆者プロフィール職業:PdM,PjM社会人歴:7年目(※2026年現在)マイナビ歴:1年目(※2026年現在)所属組織:プロダクトマネジメント統括本部前職:フードデリバリープラットフォーム運営会社 はじめに PdMやPjM・デジタルサービスの企画・ディレクション職種の希望者向け マイナビへの転職を検討されている方に気になるだろうポイントを載せていきます 結論 デジ戦を選んでよかったなと思っている なんで転職しようとしたの? 仕事をするからには社会に良い影響を与えたい。 良い影響を与えるからには、より大きなインパクトを出したい。 そんな動機から、toC向けデジタルサービスの企画・ディレクション職からキャリアをスタートしました。 ステークホルダー(社内外)やデザイン・開発者等と協業して、成果物が世に出て、直接的に数値で結果を確認でき、 スキルが伸びればそのサイクルがどんどん大きくなる、領域が深まり広がっていく...という、 短期のやりがい、中長期の成長実感や明確なキャリアパス(企画→ディレクション→PJM→PdM)がなんだかゲーム感覚で、世の同職種の皆さんは程度の差はあれそういったポイントモチベに業務を楽しんでいるのかなと思います。 私としては、PdMとして残りの仕事人生どんなキャリアを描こうか迷っている時期で、 プライベートの転機、前職の転機など、さまざまなファクターが重なったこともあり、転職を考えた次第でした。 転職の軸は? メインテーマ 前職を継続して、より上位職(マネジメント等)や経営サイド等の別領域へのチャレンジなど考えましたが、 より大きいプロダクトを担当したい・できるようになりたい気持ちが大きな軸でした。 ここでいう大きなプロダクトとは、 より利用者が多く、利用シーンも多く、総合的にユーザーの人生に与える影響が大きいサービスを指します。 例えばGoogleで言えば、検索も音楽も動画も、端末や企業のクラウド、企業の各サービスの機能など様々シーンで活用され、多くの方に影響しています(Amazonとか色々ありますよね。日本だと楽天、LINEヤフー、リクルートなど様々)(いわゆるスーパーアプリ)。 こういったサービスの特徴としては、1個のプロダクトにとどまらず、シナジーのある他プロダクトも続々立ち上げて、連携、総合的で連続したサービスをユーザーに提供しています。 一個のプロダクトを磨きこむことも当然大事ですが、頭打ちは必ずあります。(最終的にボタンの大きさとか色味のABテストくらいしかやることなくなるな...とかは常々思っていた) より大きな価値を生み出すためのプロダクト間連携、シナジーの創出は今後のトレンドになるだろうな、そういったシナジー創出の経験は一PdMとしての将来的な生き残り戦略として大事だなという目論見と、単純に複雑で面白そう+よりインパクト出したい自分の仕事軸とも合うため、志向するポイントでした。 サブテーマ もう一個、こちらはサブ的なテーマですが、 AIの活用がトレンドの今、業務内にとどまらず、AIを活用した新規プロダクト・既存プロダクトの機能の改善を志向し、実践している企業に飛び込んで、知見を吸収、あわよくば実践・経験を詰めることも志向ポイントでした。 色々な職業のAIによる代替可能性が示唆、文字通り日進月歩で変わるAIトレンドなどなど、日々目の前の業務に取り組んでいる中で、AIに触ったり・業務・サービス活用を考える時間は前職だと環境的にあまり取れませんでしたから、焦燥感は募るばかりでした。 AI活用の専門部署があって、昨今のAIトレンドを専属でキャッチアップし、ナレッジを組織横断でシェア、場合によっては業務で関係できるような企業は大きな魅力を感じました。 なんでデジ戦を選んだの? 大きなプロダクトの0→1を経験できること AI関連の専門部門がありナレッジが組織を跨いで共有・協業できること 仕事環境が良いこと 1.大きなプロダクトの0→1を経験できる プロダクト統括部では、toBのプロダクトをメインに大小さまざまな規模の案件を扱っています。 それらの特徴は、新規の立ち上げ・運営改善、そして各種マイナビサービスとの連携によるシナジー創出にあります。 例えば、担当しているマイナビ TalentBaseというサービスは、SmartHRに代表されるようなHR総合プラットフォームです。 企業の人材管理および、それに派生した教育研修、採用等に派生し、各種マイナビサービスとの連携創出を目下の目標としています。 (その他にも、将来的なマイナビサービスの非連続的成長の糧として、先進的な事例の研究開発・PoCを実施、結果如何で新規実装などの、ボトムアップ型の0→1案件なども担当しています) 就職や転職、アルバイトや医療福祉、採用管理、教育研修など、マイナビグループは事業の軸をなす複数のプロダクトがあり、それらの非連続的な成長のため、グループ間のシナジー創出は中長期計画の柱の一つです。 多様なステークホルダーと協業して、複雑かつ影響の大きな案件を担当できることは、大きな魅力でした。 2.AI関連の専門部門がありナレッジが組織を跨いで共有・協業できる AI戦略室という部門があり、日夜AIのトレンドを追いつつ、各種マイナビサービスに取り込んだり、業務に取り入れたりなど実践している部門です。 同じデジ戦内の部門であり、距離感も近く、ナレッジを得る機会、そもそもナレッジが蓄積される環境でもあって、非常に貴重です。 そもそも、全社的にAIツールの導入、利活用の推進、ガバナンス・運用ルールの策定浸透と、かなりの熱量で取り組んでいることも大きなポイント。 3.仕事環境が良い 現実味な話ですが、仕事環境も外せない要素ですね。 定時は7時間30分なので、8時間の企業と比べると毎日30分短いことはとんでもないことです。 給与水準は同職種・職能帯でも高水準にあたると思いました。 リモートワークもあり、かつ取得も容易。在宅比率50%の目安こそあれ、子育て世代の突発的な事由などにおいては柔軟に調整可能なため、運用ルールの見た目の堅さに対して実態は非常に優しいです。 とはいえ、職場環境は非常に充実している(デュアルモニター、モニターアーム、個人ブース多数でオンライン会議容易)ので、むしろ業務効率向上のため意欲的に出社できる下地は整っています。 福利厚生が前職・前々職比較ですが、非常に多く、色々活用させてもらっています。 大規模ECプラットフォームを運営する他社とも、最後まで迷いましたが、最終的にデジ戦を選びました。 入社前の不安は?(典型的なJTCで、システムはレガシーだよと又聞きしていて不安だった) 入社を決めてから、前職の上長に言われたこと 「とはいえ、マイナビは結構レガシーだよ(上長のかつての部下がマイナビ出身だったそう)」の言葉はかなり響いて、最後まで悩んだポイントでした。 国内大手のチャットサービス企業での経験を持つ上長の助言もあり、不安に感じる点はありました。 あなた程の人が言うなら...と 仕事の進行等で前職とは比にならない開発面、企画面でのハードルがあり、大変なのかな... ちゃんと能力を発揮したり、キャリアを積んでいけるだろうか...と不安でした。 とはいえ、ビジネスサイドに寄って、経営レイヤーの能力を強化していきたい思惑もあり、 上述の仕事内容や環境面から、マイナビに飛び込むことを決意。 結果、 実際そうだけれども、全社的に課題と捉え、解決に向けて絶賛稼働している過程だったとわかりました。 今この瞬間、名だたるテックカンパニーのような超モダンな環境、とは言えないですが、 経営層レベルで問題意識をもち、現場レベルで解決に向かい実行段階にあることは、不安を抱えてジョインした一中途入社人間として非常に安心できる材料です。 システム 一例として、システム面について。 今までは一個のプロダクトをそれぞれ担当の部門が磨きこむという経営方針の都合、 プロダクト数がとても多く、かつマスタがプロダクトごとに独立しているなど、あるあるな特徴があります。 また、開発におけるベンダー依存の構造(今までの経営合理性に基づく話なので、課題というよりか前提)など。 これについては、エンジニアブログの記事等がより参考となるのでざっくり申し上げると、 それを解消し、よりマイナビサービスの成長に貢献することがデジ戦の存在理由です。 現在進行形で様々な取り組みがラインナップされ、着実に強力に実行されているところです。 組織風土 また、組織風土的な面ですが、 社員1万人をかかえる大企業特有の特徴かなと思い、 むしろ中途入社社員においては、他企業での経験を求められるシーンかなと思ってます。 例えばステークホルダーが単純に多いです。 これについては、新卒入社から長年貢献して在籍されている社員の比率が多いため、 ある事象の確認・承認については誰に決裁・浸透を図るべきかサポートいただけます。 さらに、マイナビでの経験が長く、他企業のやり方を知らない社員が多いということは、 旧来のやり方の踏襲が多いということで、 そういったシーンに中途入社社員の経験を絡めてアップデートしていくような、 まさに組織の変化を求められているなと感じることが多いです。 なので、体制や組織文化的にも既存社員と中途入社社員で二人三脚で頑張っていこう! リスペクトしています!な空気を肌身に感じます。 統括 マイナビは全社・組織レベルで、ポジティブな変化を望み、実際に変化していると感じます。 停滞感や固執といった空気はなく、唾棄されます。 むしろ、レガシーをモダナイズする過程にノーリスク(ボトムアップで個人のリソース頼りではないという意味)でジョインできる環境は、むしろ一社員として大きな糧になるのではと皮算用しちゃうくらいです。 マイナビはそういった、意欲旺盛でチャレンジングなあなたのエントリーを心待ちにしています。 是非、一緒に働きましょう! (他にも気になる点、深堀りしたい点ありましたら、人事の方経由で質問いただいても構いません。気軽にアプローチしてくださいね!) おまけ - 入社しておどろいたこと 社内コミュニケーションがかなり豊富です。 社内報、teamsのエンゲージ機能、懇親会、組織・組織横断の勉強会など。 懇親会が四半期レベルで1回以上あり、2個上のレイヤー層との接点も豊富です。 1万人ほどの社員がいますが、さまざまなチャンネルで組織を超えた交流の機会があるので、様々な知見を吸収できる風通しの良さはすごく驚きました。 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。
このシリーズでは、当社のデジタルテクノロジー戦略本部(デジ戦)の社員が、業務やプロジェクトを通じて感じている「仕事の価値」と「社会的意義」を紹介します。顧客や社会への貢献実感、手応えを覚えた瞬間を取り上げ、働く意味をより具体的にお伝えします。 はじめに 筆者がこのブログを執筆しているのは1月下旬。 ”そんなに雪が降らない方”の岐阜にある実家の両親からは、どこか自慢げに「雪降ったわ」とLINEメッセージを頂く季節となりました。 私はマイナビにデータサイエンティストとして新卒入社し、雪解けの頃にはデジ戦在籍歴が丸4年になる人間です。 「私がデジ戦で見つけたやりがい」というテーマに併せて、やりがいって?生み出す価値って?に対する現時点での考えを共有できればと思います。 筆者プロフィール 所属:デジタルテクノロジー戦略本部 AI戦略室 AIソリューション部 入社時期:2022年4月 新卒入社 職種:データサイエンティスト 業務内容: 主にマーケティング領域のAI・データ活用プロジェクト推進・実装を担当。 その他、社内データ利用ユーザ向けの技術支援・生成AI関連のガバナンス整備に関する業務も行った経験がある。 その他特記事項: 一般社団法人データサイエンティスト協会 スキル定義委員会に所属。 社外イベント・大学講義での登壇頻度が高く、過去は四半期に1回ほど。 価値の定義 「私がデジ戦で見つけたやりがい」シリーズでは、デジ戦メンバーが「自分の仕事が社会や顧客にどんな価値を生み出していると感じるか」をアウトプットしています。 どんな価値、の前に業務上の価値は何なのか?について私の考えを共有します。 よく「IT職は成果が売上に直結しないから業績評価が難しい・評価されない」と言われると思います。これは営業職などの目標が定量的に示しやすい職種との比較で語られる話ですが、売上が何によって生まれているかについて考えると、価値に近づく気がします。 営業職は顧客の「購入判断」によって「売上」が生まれる ↓抽象化 業務は対象者の「ビジネス上ポジティブなアクション」を引き出せたら「価値」になる 営業職は、顧客の心を動かして「買う」という行動を引き出し、その対価として売上を得ていると考えられます。 そう考えれば、我々の仕事も全く同じです。 「すごいモデルを作った」「分析レポートを出した」こと自体が価値なのではありません。それを見た社内の誰かが「計画を変更しよう」「この施策を始めよう」と意思決定し、具体的なアクションを起こした瞬間にこそ、価値が生まれるのではないかと考えます。 つまり、「対象者のポジティブなアクションを引き出すこと」。 これこそが、職種を問わず共通するビジネスの価値であると定義できると私は考えます。 「イメージのしやすさ」 では、どうすれば相手のアクションを引き出せるのでしょうか? 最近、そのヒントになる出来事がありました。冒頭でも少し触れた「雪」の話です。 ちなみに導入の小噺を読んだ皆さんは、「雪降ったわ」がどれくらいの降雪量だったと想像しましたか? そんなに降らない方なら、5㎝? そんなにとは言っても、白川郷はめっちゃ(3mとか)積もるから1m? このテキストでは降雪量を具体的にイメージすることは難しいように感じます。 一方、私が最近見かけたJR東日本の運転計画の案内を見ていただきたいです。 出典:『JR東日本なるほどQ&A Guide 自然災害(雪)』 https://www.jreast.co.jp/saferelief/operationguide/pdf/snow.pdf 降雪はみられるがすぐ溶ける程度・地面にうっすら積もる程度といった「程度」の表現 2つのケースを示す「パターン」の提示 イラストで雪による地面の透過度を見せる「可視化」 があることによって、私たちは瞬時に降雪の状態をイメージすることができます。 イメージができると、リモートワークへの切り替え判断などのアクションも取ることができます。 この話と同じく、マイナビのデータサイエンティストとしては、 社内ユーザの「状況をイメージできる状態」を引き出せたら「価値」になる という場面が多いように私は感じています。ユーザが担当しているサービスの状態や施策の効果、直近の未来といった見えていない状況を晴らすことが役割のひとつであり、それができたら価値になるというのが、私の現状の回答です。 前提整理が長くなりましたが、マイナビDSの価値をイメージできたでしょうか? ここからは私の業務を紹介し、価値を求める上での意識とやりがいを共有できればと思います。 業務紹介 この章では 太字 はすべて「イメージ→価値」に繋がる要素になるように記載しています。 MMMのモデル構築による広告運用最適化 Web広告やTVCMなど、多岐にわたる広告施策の中で「本当に効いている広告はどれか?」というのは、意外と見えにくいものです。 そこで私は、MMM(マーケティング・ミックス・モデリング)を用いて、 広告効果 の推定を行いました。 具体的には、メディアごとの 貢献度 を数値で可視化し、さらに「来月、予算配分をこう変えればKPIはこれくらい伸びる」というシミュレーション提示を行いました。 ※このプロジェクトに関して登壇した過去のイベントレポートは こちら 結果として、マーケティング担当者が「なんとなく」ではなく「根拠を持って」予算配分を変更するという、アクションを引き出す足がかりにはなったのではと思います。 社内生成AI利用ガイドラインの更新 生成AIは強力なツールですが、セキュリティリスクや社会的責任があるため、現場は利用に二の足を踏みがちでした。私は、ガイドラインの策定を通じて「どんなケースなら利用していいのか」「どのツールなら業務利用OKか」という 境界線 を明確に定義しました。 ※この業務に関して振り返ったブログは こちら 「この条件なら利用可能」という 基準 をクリアにしたことで、社員が迷わず安全に生成AIを活用できる環境(アクションできる状態)を整えることができました。 日々のデータ活用に関する問い合わせ 社内からは日々、「データを使ってこんなことがしたい」という相談が寄せられます。 (過去を遡ると100回以上相談会を実施したと思います。) しかし、初期段階ではアイデアが抽象的で、実現可能かどうかも分からないことがほとんどです。 これに対し、 そのデータは取得できていないから、まずは計測から始めましょう その目的であれば、AIではなく集計で十分です といったアドバイスを行い、 実現への道筋 を具体化します。 相談者の頭の中にあったイメージを「 実行可能な計画 」へと解像度を高めることで、プロジェクトの着手や、あるいは早期の撤退判断といった次の一歩を後押ししています。 まとめ ここまで、私の考える「価値」と具体的な業務についてお話ししてきました。 ビジネスの世界は、まるで雪の日のように視界が悪く不確実なことばかりです。 (上手いこと言った風) 「本当にこれでいいのか」と誰もが判断に迷い、立ち止まりそうになる瞬間があります。 私たちデータサイエンティストの仕事は、データによって「今の状況」や「進むべき道」を、誰もがイメージできる形にして届けることではないかと思います。 そしてイメージを受け取った相手のアクションが見えたとき、それは価値となり、成果であり、やりがいに繋がると思います。 ここまでの話が、マイナビDSのキャリア”イメージ”に繋がれば幸いです。 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。
このシリーズでは、当社のデジタルテクノロジー戦略本部(通称:デジ戦)で働く社員が、どのようにスキルを伸ばし、キャリアの幅を広げてきたのかを紹介します。キャリアチェンジの背景や挑戦のプロセス、日々の学びを通じて、デジ戦で描けるキャリアの可能性をお伝えします。 「スキルアップをしよう」 近年よく耳にする言葉ですよね。 VUCAの時代と呼ばれる変化の激しい現代において、ますます重要視されるようになっています。 これを読んでくださっている方の中には、スキルアップのためにデジ戦への転職を考えている方もいるかもしれません。 でも、よく考えるとスキルアップって結局なんのためにするんだったっけ?とふと思います。 業務を効率化するため。仕事の幅を広げるため。キャリアの選択肢を増やすため…… 理由は人それぞれですが、私にとっては 「自分の世界が広がっていく面白さを感じるため」 なのではないかと思い始めています。 今回は、私がそう思えるようになったきっかけとなった、あるプロジェクトに挑戦したお話をしてみたいと思います。 この記事で分かること デジ戦にある「挑戦を歓迎する」風土 部門をまたいだプロジェクトで、どんな仕事に触れられるのか 未経験でも挑戦してみたら「意外とできた!」になる話 スキルアップを「義務」ではなく「世界が広がる体験」と捉えられるようになったプロセス プロジェクトに挑戦したきっかけ 私は通常業務でWEBディレクター職として、自分の担当サイトの応募数向上を目的に、メールマガジンやサイトのUI/UX改善に向けた施策の企画・設計および改善に携わっています。 毎日PCと向き合いながら自サイトと数値やデータを見比べながら、施策を練る日々。 そんな日々を過ごしながらも、私の頭の中にはじわじわと違和感が広がっていきました。 「このサイトを使うユーザーの顔を、私は見たことがない……」 数字だけ見て判断して良いのだろうか? 数字が上がったことを喜んで、それで本当にユーザーのためになっているのだろうか? ずっと前に作られたペルソナを頼りに、なんとなく施策を進めてしまっていないだろうか……。 そんなことをぐるぐる考えていた頃、CXマーケティング統括本部の全体会議で「ユーザーリサーチを行うプロジェクトを立ち上げるのでメンバーを募集します」という案内を聞きました。 気が付いた時には、 勢いで手を上げていました 。 プロジェクト概要 このプロジェクトは、「 インタビューやアンケートを通したユーザーの生の声を聞き、ユーザーが本当に求めているものを探ることで、サービス改善につなげること 」を目的として発足しました。 最終的にはデジ戦全体にリサーチの風土を根づかせることもゴールとしています。 メンバーは課長1名+一般メンバー2〜3名の少人数。 全員が自ら手を挙げて参加し、約1年活動しました。 実施内容(一部抜粋) ■インタビュー 設問設計 リクルーティング オンラインインタビュー:27名 オフラインインタビュー:1名 結果の社内共有 ■アンケート 設問設計 アンケート:3回 結果分析・共有 ■KSF策定・分析 3C / PEST / 5Forces KSFの策定 ■風土醸成 勉強会・ワークショップ開催 事例共有(社内記事) インタビュー伴走支援 ※上記はチーム全体での実績になります 手探りで進むプロジェクト 私を含め、メンバー全員がリサーチは未経験。 それでも、誰かがやり方を教えてくれるわけではなく、 自分たちで調べて、やってみて、改善する という進め方でした。 活動内容は多岐にわたり、3〜4人という体制でそのすべてに関われるのは大きなやりがいでした。 勘違いから始まるユーザーインタビュー この活動範囲の中でも特に自分にとっての大きな挑戦となったのが、ユーザーインタビューでした。 実は、プロジェクトに立候補した時点では、このプロジェクトをアンケート調査だけをやるものだと勘違いしていました。 プロジェクト開始後に「どうやらインタビューもやるらしい。むしろインタビューがメインらしい……」と気がついたのです。 もともと人見知りで話すことに自信がない私は、場をリードする必要のあるインタビューに戦々恐々。 なぜプロジェクトに自薦したんだろうと後悔した時期もありました。 しかしながら自薦した手前、怖気づいてやらない訳にもいきません。 社内で練習相手を探し、Youtubeで学び、原稿をつくり、緊張で震えながら第1回目のインタビューに臨みました。 未知の自分との遭遇 初回は緊張で言葉がつっかえながらも、なんとか乗り切った…という感じで、自分がインタビューしている動画を見返すのもかなり苦痛でした。 ですが、プロジェクトメンバーと毎回振り返りをし、学びを共有しあい、2回目、3回目と重ねるうちに不思議と慣れていきました。 そして次第に「 あれ?これ意外と自分に合っているのかも……? 」と思い始めたのでした。 ユーザーインタビューを通して数字やデータでは分かりきらない生の声に触れられることや、相手の話を聞きながらユーザーが潜在的に何を望んでいるのか、今の自分たちのサービスに足りないものは何かを考えながら深掘りしていくプロセスは、非常に興味深いものでした。 そして、こうやってユーザーと向き合うことで、競合の後追いをするだけではないサービスを作っていくことができるのではないか、とわくわくしたのでした。 プロジェクトへの挑戦を経た学び ①苦手と思い込んで避けがちなものに、面白さがあるかもしれない 私は、仕事において新しいことに挑戦してみたいという欲がある一方、これまでは自分ができそうだと事前に確信できる範囲のことに挑戦してきたように思います。 ですが今回は、「ユーザーインタビュー」という、本来なら自分の苦手意識から避けていそうな領域に、思いがけず飛び込むことになりました。 それが、結果的にたまたま新しく面白いと思えるものに出会えることになったのです。 「自分はこれが得意」「自分はこれが苦手」と思い込んでいるだけなのかもしれない。 思い込みで、まだ見ぬ面白いものに出会えないのは勿体ない 、と思えるようになりました。 ②挑戦は一人でやらなくてもいい このプロジェクトを一人でできたかというと、やはり難しかったと思います。 ユーザーインタビュー以外にも、アンケートや社内ワークショップなど全てが初めてのことでしたし、何よりユーザーインタビューがあまりにも自分にとって心理的にハードルに思えたからです。 その中でも、同じプロジェクトのメンバーと共に勉強し改善点を共有しあい進めていくことで、一人で挑戦しているわけではない、と思えました。 自分から学び実践する動きは大事ですが、でもすべてを一人でやろうと思う必要はない。 むしろ、個人個人の挑戦を軸に互いに共有しあうことで、チーム全体で助け合って進むことができる。 組織で働くということは、互いの得意分野を発揮しながら、一人ではできないことを協力しあって成し遂げていくこと だということに、改めて気が付く機会となりました。 ③キャリアは気になったことに手を伸ばしていたら自然と形になるもの 以前はこの先のキャリアを明確に決めなくてはならないのではないか、という気持ちがありました。 そして、何をやればいいか、何をやりたいか上手く決めきれない状態にもどかしさを感じていました。 しかし、今回、自分が苦手だと思っていたことに面白さを見出す、という経験をして、 今この先のキャリアを明確に決める必要などないのではないか と思い始めました。 「キャリアは、気になったことに手を伸ばしていたら自然と形になるもの」という感覚に変わったことで、これからも自分の「やってみたい」という気持ちを大事にしていければそれで良いような気がしています。 VUCA時代に、楽しみながら自分だけのキャリアを築く 「自分ひとりでスキルアップができるのか」 これは、私が中途入社して1週間ほどの頃、OneNoteに残した言葉です。 当時は、変化が激しい時代の中で自律的に学び続けなければならないという、静かな焦燥感のようなものがあったのかもしれません。 しかし今思うのは、スキルアップは必ずしも「自分ひとり」でやるものではないということ。 だから私はいま、「とにかく自分が面白くて楽しいと思える仕事をしていきたい」というシンプルな気持ちを軸にしています。 自分の興味を軸に楽しみながら仕事をすれば、いつの間にかスキルはついてくるし、これまでやったことのない業務や関わったことのない人と仕事ができることが、純粋に嬉しいです。 そうやって自分の世界が少しずつ広がっていくことを楽しんでいれば、いつの間にかその積み重ねが、自分にしかないキャリアになっていくと信じています。 最後に 私の例が、「デジ戦で挑戦してみたい」と思っている方の参考になれば嬉しいです。 あなたの世界が広がるきっかけが、デジ戦にあることを願っています。 お待ちしております! ■執筆者プロフィール職業:WEBディレクター社会人歴:5年目(※2026年現在)マイナビ歴:3年目(※2026年現在)所属組織:CXマーケティング統括本部前職:WEB制作会社 ■執筆者プロフィール 職業:WEBディレクター 社会人歴:5年目(※2026年現在) マイナビ歴:3年目(※2026年現在) 所属組織:CXマーケティング統括本部 前職:WEB制作会社 採用情報について デジ戦では、現在一緒に働くメンバーを募集しています。 詳細な仕事内容や募集職種、働く環境については、 採用ページ をご確認ください。
このシリーズでは、当社のデジタルテクノロジー戦略本部(デジ戦)の社員が、業務やプロジェクトを通じて感じている「仕事の価値」と「社会的意義」を紹介します。顧客や社会への貢献実感、手応えを覚えた瞬間を取り上げ、働く意味をより具体的にお伝えします。 本記事の対象者 マイナビのSE業務に興味がある方 新卒がどのような業務に取り組んできたのか興味がある方 もちろんそれ以外の方も 大・大・大歓迎 です!! 自己紹介 2023年4月に新卒入社したTです。今は社会人3年目です!(2026年1月時点) 現在は、スカウト系の転職サービスである 「マイナビスカウティング」の運用・保守 を担当しています! ♦ 執筆者による概要 この記事の執筆者は、入社後から現在までの担当業務を振り返りながら入社時の動機を果たすことが出来たのか、についてまとめています。 この記事を読むことで、株式会社マイナビにおける 「裁量を持った仕事への取組み」 や 「具体的な業務内容」 について知ることができ、マイナビでSEとして働くことの魅力をより深く知ることが出来ます。 入社時の動機 ・toC向けのサービスを持つ事業会社でシステム設計・企画に携わりたい ・裁量を持って働きたい 執筆者の業務 ・業務要件→システム要件の作成 ・セキュリティ対応 ・データ可視化 ・社内からの問い合わせ対応 ・ベンダーコントロール マイナビで働くことの魅力 ・裁量をもってto C向けサービスの改善に携われる ・自らが得た知識・経験をもとした提案が歓迎される風土がある ・知識を得るための補助(書籍購入など)もある 👇👇👇👇👇 記事を読んでさらに詳しく知る 👇👇👇👇👇 それではここから入社前~現在に至るまで時系列順に取り組んできたことなどを振り返っていきます。 入社する前 私は23卒の新卒として入社しました。 入社するからには、何かしら会社に入る動機がありますよね? 私が当時掲げていた入社動機は以下2点でした。 ① toC向けサービスにシステム設計・企画として携わることが出来ること ② 年次の若いうちから裁量を持って業務に取り組めること ① toC向けサービスにシステム設計・企画として携わることが出来ること 元々大学時代に、イベント企画などをしていたこともあり、 1人1人のユーザーが使いたくなるようなサービスに関わる業務がしたい という気持ちがありました。 そのため、toB向けよりもtoCのサービスに携わりたいな、と思って就活していました。 また、受託開発をするよりも自社サービスを持つ事業会社で 「 システム担当としてサービスを担当して育てていってみたい」 という気持ちがあったので、どちらも達成できるマイナビに入社を決めました。 (当時就活で使っていたマイナビ2023が使いやすいなぁ、と思ったのもあります) 私が入社したころはエンジニア職はSE職とプログラマー職がありました。 (データやデザイン職もありますがいったん省略) プログラミングの経験は入社前にもありましたが、個人的には細かいコードの最適化が好きでも得意でもなかったんです。。 そこで、もっと 上流側で範囲広くシステムを設計したり企画するような仕事に携わりたい と思い、SE職を希望していました。 ② 年次の若いうちから裁量を持って業務に取り組めること 私は、ただ言われたことをこなしていくよりも、 自身でどのようにしたらいいのかを自分ごととして考えて改善していく機会がある方が仕事にやりがいを感じる タイプでした そのため、ユーザー目線で考えた際に「もっとこうだったらいいのに...」と思ったことを、能動的に提案・実行できるような環境を求めて就活していました。 その時に、マイナビの就活生向けの記事を読んでみると、新卒数年目の先輩方が取り組んでいる業務内容が自身のやってみたいシステムの企画・提案業務だったんです...! 「この会社なら自分のやりたいことが出来るかも!?」と思って入社を決めました。 果たして「この2つの動機(期待)が現在達成できているのか」については、後ほど触れさせていただこうと思います! ちなみに、入社前の不安は私はほとんどありませんでした。 (プログラミング経験の無い同期もいましたが、新卒研修で教えてくれるので心配はしなくて良いと思います!) 現在の業務について ここからは、私が新卒入社してから現在に至るまでの業務を振り返っていこうと思います。 1年目 ~ システムへの理解を深める ~ 新卒研修後の2023年8月に、転職スカウトサービスである「マイナビスカウティング」の担当として配属させていただきました。 研修中にデジタル部門本部長と面談する機会があり、その中で 「toC向けのシステム設計や企画に携わりたい」という意志を反映 して頂けたのかな...と思っています さて、配属後早々にしてですが、 「マイナビスカウティング」のリニューアル業務 に携わらせていただきました。 といっても、開発自体はほとんど終わっていて、受入テスト(マイナビ側の要件が満たされているかの確認)をメインに担当していました。 受入テストでは、 UX部分の指摘が実際にサービスに指摘・提案内容が反映されていく体験 を早速しました。 特に印象に残っているのが、スマホ用画面の下部メニューサイズへの提案です。 (Androidの場合、iPhoneに比べて画面が大きく、メニューが小さいと操作がしづらいんですよね...) 所属している課ではシステム設計以外にもインフラ周り(AWS)の運用保守も担当しています。 (おそらく他の課と比べても業務範囲は広いと思います) そのためAWSの理解を深めるためにAWS SAAの資格取得もしました。 当時の期末評価においてこの資格取得が評価されたことで 「正当に頑張りが認められる会社なんだな」 と思ったのを覚えています。 2年目 ~ 頼るのではなく頼られる提案をする ~ リニューアル対応も一段落したので、今度は同サービスの 月次リリースにおけるシステム要件の作成 を担当していました。 (マイナビスカウティングは毎月リリースしています) 主に、営業サイドから上がって来る 「○○をしたい!」という要望を元に、どのような機能を実装するか を考えていました。 最終的にはExcelなどで資料の形に落とし込み、開発会社にシステム改修を依頼しています。 ただ、営業サイドの要望をただ鵜呑みすると、パフォーマンス低下などのシステム影響が起きたりします... そのため、 「本当に営業サイドの要望として求めていることは何か」 「システム機能と要望との着地点はどうするべきか」 「システム担当として追加で機能提案できることは無いか」 を考え提案することにやりがいをもって業務に取り組んでいました (部内でも「営業の御用聞きにはならないようにしよう」という話は度々上がっています) また、開発会社にも頼りっきりにならないように、javaやSQLのソースコードを自ら確認・理解することにも注力していました。 これにより、バグが起きても 調査を開発会社に依頼する前にバグの箇所を推測・改善案を提案 することが出来るようになったことで成長を実感していました。 3年目 ~ さらに広い範囲での提案と実装 ~ 3年目からサービスのメイン担当となりました。 サービスのメイン担当となったことで、 ベンダーコントロールといったマネジメント業務 にも携わっています。 スケジュール遅延や工数超過が起きないように、開発会社と密にコミュニケーションを取ったり、営業サイドとの要件のすり合わせにも積極的に関わることでマネジメント力も付いてきているかな、と思っています。 また、システム企画業務に加えて、 インフラ周りやデータ可視化の業務 についても携わるようになりました。 特に、印象的な業務はAWS WAFルールの最適化です。 サービスをDoS攻撃(大量アクセスによるサイバー攻撃)から防御するためにWAFルールの最適化をしました。 AWS SAAの資格取得で得た知識や1年目からの経験がシステムの実装へうまく活用出来た 例かな、と自負しています。 (この後、大量アクセスによるサーバダウンは起きていないです!) データ可視化の業務ではTableauというデータ可視化ツールを用いて、 未活用のまま埋もれているデータを活用したり、営業の方々が必要なタイミングでいつでもデータ活用できる環境を整備 しています。 なんと、これにより月次のデータ抽出業務が無くなりました! システムも営業もwin-winですね! 3年間を振り返ってみて... 改めて 「新卒で入ったころからサービスへの提案をしやすい環境だったなぁ」 としみじみと感じています。 ただ、これってどこの会社でもある環境でも無いんじゃないかな、とも思うんです (新卒なのに他の会社を語るのも変な話ですが...) これは、そのような業務に携わらせてもらえたこともありますし、 デジ戦(マイナビのシステム部門)が「提案や挑戦を積極的に受け入れる」 風土があるからじゃないかな、と... 提案をする→良い提案であればサービスに反映→また提案したくなる という環境があるからこそ 「こんな機能が必要じゃないか」 「システムでこの観点が必要じゃないか」 「このようなデータを連携した方がいいんじゃないか」 といった提案を能動的に発信することが出来た のかな、と思うんです。 もちろん新人の頃は「最初は分からないことだらけで提案とかできないよ!」と人もいますよね。 ただ、私の課では質問を拒否されたりしたことは無かった(周りでも質問して怒られている人は見ていない)ので、最初は徐々に仕事に慣れていきつつ提案とかしていけばいいんじゃないかなぁ、と思っています。 入社前の期待は満たされたのか? ① toC向けサービスにシステム設計・企画として携わることが出来ること → 満たせています! 2年目から現在に至るまで、 非常に広範囲(UX、セキュリティ対応、バックエンド処理、データ可視化....)にいたるシステム設計や企画に携わる ことが出来ています。 まだ足りない知識は無限にあるので、貪欲に知識・経験の取得に取り組んでいきたいです! ② 年次の若いうちから裁量を持って業務に取り組めること → 満たせています! 配属直後から「もっとサービスをよくするにはどのようにしたらいいのか」を考え提案 することが出来る環境にいさせてもらっています。 これからも積極的に業務に取り組んでいきますし、後輩が出来た際には取り組みやすい環境を作っていきたいと思います。 まとめ 「ユーザー視点に立ったシステム業務に裁量をもって取り組みたい」という自分の入社時の動機とガッチリ合った仕事 をさせてもらっています! もちろん私自身のマインドや知識によるものもあるかもしれないですが、 ・自ら提案することをよしとする風土 ・幅広い業務範囲と個人の裁量の大きさ ・自主学習しやすい環境 など、環境面としての影響も大きかったなぁ...と改めて振り返って気付きました笑 (勉強する際には書籍購入制度を利用したり、デジ戦社員用のUdemyを活用しています!) ここまで読んでくれたあなたへ 読んでくれてありがとうございました! マイナビは 「ただ与えられた業務をこなす日々は嫌だ!」 「私ならもっといいサービスにできるのに!」 「自分で課題を見つけて改善していきたい!」 という方にはぴったりな会社だと思います。 それは、事業会社として自社サービスを持っているからということもありますが、 「提案や挑戦を受け入れる」という風土 があるからだと思います。 自ら担当しているサービスに課題感を持って自分ごととして改善案を考えていくことで、より知識・経験が身についていきますし、マイナビにはその環境があります。 自分から積極的に取り組んだことが認められると仕事も楽しくなってくるし、そういう人が世の中に増えていけばいいなぁ、と思っています。 この記事がマイナビに応募・入社しようか迷っている方々の背中を押してあげるような記事になっていれば幸いです。
このシリーズでは、当社のデジタルテクノロジー戦略本部(通称:デジ戦)で働く社員が、どのようにスキルを伸ばし、キャリアの幅を広げてきたのかを紹介します。キャリアチェンジの背景や挑戦のプロセス、日々の学びを通じて、デジ戦で描けるキャリアの可能性をお伝えします。 はじめに エンジニアとして様々な業務を経験してみたい方 エンジニア以外の職種の経験をお持ちの方 向けになります。ぜひ参考になれば嬉しいです。 ──────────────────  筆者プロフィール ────────────────── 所属:ビジネスイノベーション統括本部 ITソリューション第4統括部 ディレクション1部 入社時期:2019年 新卒入社 職種:システムエンジニア 経歴: 営業として新卒入社。入社半年後からはキャリアアドバイザーとして学生の就職活動を支援。 2023年10月に社内公募を利用し、システムエンジニアへ異動。 理系学生の専門性に触れ、痛感した「手に職」の重要性 私のキャリアのスタートは、エンジニアとは少し離れた場所にありました。 以前は「理系学生担当のキャリアアドバイザー」として、就職活動を行う学生さんの支援をしていました。 理系の学生さんは、自身の専攻や研究分野という確固たる「武器」を持っています。彼らのキャリアと向き合い、「どんな技術で社会に貢献したいか」という熱い話を聞いているうちに、私自身もこう思うようになりました。 「彼らのように、私自身もこれからの時代を生き抜くための『手に職』をつけたい」 「技術を使って、サービスを裏側から支える側に回ってみたい」 私自身も理系出身だったため今の仕事でも経験や知識を活かすことはできていましたが、 CAとして人のキャリアを考える日々が、結果として自分自身のキャリアを見つめ直すきっかけとなり、社内の制度を利用してデジ戦への異動を決意しました。 会議が「宇宙語」に聞こえ、何も頭に入ってこなかった日々 意気揚々とエンジニアの世界に飛び込んだ私ですが、現実は想像以上に過酷でした。 異動して最初にぶつかった壁、 それは 「圧倒的な知識不足」 でした。 会議に参加しても、飛び交う単語が全くわからない。 「API」「カラム」「クエリ」……まるで宇宙語を聞いているような気分でした。 さらに辛かったのは、知識が追いついていない状態で、部長や事業部長といった上のレイヤーの方々へ説明する機会が増えたことです。 準備をしても不安が消えず、緊張しっぱなしでした。 開発会社様との会議でも、自分の理解が浅いためにその場で適切な回答ができず、持ち帰りになってしまう。 「CA時代はあんなにスムーズに仕事ができていたのに」 と、あまりの不甲斐なさに落ち込むこともありました。 それでも心が折れなかったのは、周囲の粘り強いサポートがあったからです。 初歩的な質問にも丁寧に答えてくれる周囲の存在に加え、 「悔しい、次は絶対に答えられるようになりたい」という思いが原動力となり、 必死に技術を吸収していきました。 別のSFA開発で基礎を築き、希望を出して「古巣」のシステムへ デジ戦に異動してすぐ、私が現在の担当業務に就いたわけではありません。 最初は全く別の営業支援システム(SFA)のチームに配属され、そこでゼロからエンジニアとしての基礎を叩き込まれました。 数年が経ち、設計や実装の基礎体力がついてきた頃、自分の中で一つの思いが強くなりました。 「エンジニアとしてのスキルと、元CAとしての業務知識。  この2つを掛け合わせれば、もっと大きな価値が出せるはずだ」 そこで私は、「かつて自分がCA時代に使っていた業務システム」を担当したいと自ら希望を出し、デジ戦内での異動を叶えました。 自分の強みが活かせる場所へ手を挙げれば、チャンスをもらえる。 これもデジ戦の魅力的な風土の一つです。 「元ユーザー」だからこそ、守れるシステムがある 念願叶って担当することになった「古巣」のシステム保守運用。 ここで、私の狙いは的中しました。 システムの保守運用では、現場(CA)から「エラーが出た」といった問い合わせが届きます。 純粋なエンジニア視点だけでは「仕様通り動いています」で終わってしまうようなことでも、私には「その向こう側の景色」が見えていました。 「現場の業務フロー的にここの情報は必ず必要だと思う」 「取引先の企業側はこういうことで不安を感じているはず」 業務の流れや、ユーザー(CA)の焦り・痛みが手に取るようにわかる。 だからこそ、「どこを優先的に直すべきか」「どう改修すれば喜ばれるか」を、解像度高く判断することができました。 異動してまだ3か月ほどですが、新たなプロジェクトのリーダーとして業務を進めています。 異動直後のあの「不甲斐なさ」を感じた経験があったからこそ、今、自信を持ってプロジェクトを推進できているのだと思います。 これからの挑戦 現場の営業やCA、学生、企業様と様々なユーザーが利用するシステムを担当し、 以下の技術に触れながら業務を行っています。 言語・フレームワーク: SQL インフラ・クラウド: AWS ツール: Tableau 、Dify CAとしての業務理解をベースに、今後はさらに技術力を磨き、 システムの「守り(保守)」だけでなく「攻め(新規機能開発)」にも積極的に関わっていきたいと考えています。 現場の声を一番理解しているエンジニアとして、本当に使われる機能を自分の手で実装することが今の目標です。 デジ戦は、私のように全く異なる職種からの挑戦も温かく受け入れ、成長を待ってくれる組織です。 最初は知識不足で悔しい思いをするかもしれません。しかし、これまでのキャリアで培ってきた「業務知識」や「顧客視点」は、エンジニアになっても決して無駄にはなりません。 一度エンジニアとしての基礎を身につければ、社内の多様なプロジェクトの中から、あなたの過去の経験が最も輝く場所を自ら選び取ることも可能です。 ぜひチャレンジしてみてください!
はじめに ITディベロップメント第1統括部1部開発3課のS.Kです! 普段は HugWag というトリミングサロンと飼い主のマッチングアプリの内製開発をしています! この度、ラスベガスにて開催されたAWS re:Inentにデジ戦メンバー4人で参加してきましたのでレポートします! 前の記事 では概要に関しての説明をしました。 ここでは、セッションに関してまとめてみようと思います。 セッションについて re:Inventでは期間中に2500以上のセッションが行われます。 セッションは複数の会場で並行して行われていて、会場間の移動には遠いと30分以上かかるので、どのようにセッションを受けていくかの戦略が大事になってきます。 セッションはその属性ごとに以下のようなSession Typeが設定されています。 Bootcamp Breakout session Builders' session Chalk talk Code talk Event service Examp prep Expo Featured experience Gamified talk Interactive training Keynote Lightning talk Meetup Self-paced training Workshop この中で、今回僕は主にBreakout Session, Builders' session Gamified talk, Workshopのセッションに参加しました。(Keynoteは動画で視聴) 会場 re:Inventでは以下の会場にてセッションが行われます。 Caesars Forum Mandalay Bay MGM Grand Venetian Wynn 隣り合う会場でも歩いて10~20分かかるイメージです。 他の会場と離れているMGM Grand, Mandalay Bayはシャトルバスかモノレールで移動します。 どちらもre:Invent参加者は無料です。 シャトルバスは会場内の案内に従っていけば特に苦労なく乗れて、5分刻みくらいの短い間隔で出発するのでかなり便利でした。 モノレールは駅によっては入り口の場所が分かりにくかったりしますが、駅に入りさえすれば駅員さんにre:Inventのパスを見せるだけで入れてくれます。 シャトルバス モノレール 事前の予約 各セッションは事前に予約することができます。 基本どのセッションにも当日参加の枠があって事前に並ぶことで予約なしでも参加することができますが、人気のセッションでは30分前とかには並んでいる必要がありそうなので、予約するのが確実です。 今年の場合は10/15の早朝2時からセッションの予約が開始されたので、参加メンバーでリモート会議しながら予約をしました。 人気なセッションだと5分後にはすでに予約が締め切られていたりするので予約開始と同時に予約するのがオススメです。 なお、予約するセッションの検索には こちらのサイト を使用しました。 ここら辺に関しては O.Kさんの記事 に詳しく書かれています。 各セッションについて 僕が参加したセッションについてまとめていきます。 せっかくなので求められる英語レベル、求められる技術レベル、総合おオススメレベルを5段階で書いてみます。 僕の英語レベル(読むのは少しできる、聴くのは苦手)と技術レベルを基準にした時の評価です。 どのセッションタイプに関しても難易度によって違うので一概には言えないのですが、何となくのイメージを掴んでもらえればと思います。 Breakout Session 求められる英語レベル: ⭐️⭐️⭐️⭐️(4/5) 求められる技術レベル:⭐️(1/5) 総合オススメレベル:⭐️⭐️(2/5) 講義形式で発表者のプレゼンを聞く形式のセッションです。 時間は大抵1時間程度です。 会場によっては1つの大部屋の中で同時に複数のセッションが行われるので、その際はヘッドフォンをして話を聞きます。 英語を聞き取る必要があるので求められる英語レベルは高いですが、スライド見てるだけで内容結構分かるものもあります。 会場内でリアルタイムで文字起こししてくれるモニターがあるのですが、ちょっとラグがあって話を聴きながらだと混乱して僕はあまり上手に使えなかったです。 また、後日録画映像がyoutubeにアップされるので、そちらを確認すれば内容を確認できるし、文字起こしも見やすいです。 後述のハンズオン系のセッションと比べて現地で受けるメリットは少ないですが、1時間と短く疲労感も少ないので、空いた時間などに入れていく形が良いかと思います。 (とはいえ、僕はもうちょっとハンズオン系のセッション増やした方が良かったなと思っています。。) 参加したセッション What’s new in fullstack AWS app development (DVT204) Building Enterprise-Ready Agentic Speech AI Pipelines on AWS (sponsored by NVIDIA) (AIM280-S) Lucid Motors: Building an AI-native Finance Function to Power Growth (sponsored by PwC) (AIM274-S) Session Details Long-Horizon Coding Agents: Complex Software Projects with Claude (sponsored by Anthropic) (AIM3316-S) Building Production-Grade Workflow Patterns with AWS Step Functions (API313) Anthology boosts contact center efficiency with AI (BIZ212) From Punch Cards to Pair Programming and Beyond: The Future of Copilot (sponsored by GitHub) (AIM294-S) Generative AI, agents, MCP, and the future of AI-powered software development (DVT217) Building software like never before with Agentic AI (DVT220) ヘッドフォンなし ヘッドフォンあり Builders' Session 求められる英語レベル: ⭐️⭐️⭐️(3/5) 求められる技術レベル:⭐️⭐(2/5) 総合オススメレベル:⭐️⭐️⭐️⭐️⭐️(5/5) 8~10人くらいの卓ごとに一人のメンターがつき、メンターの全体に向けての簡単な説明の後にドキュメントを見ながら各々で作業をする形式のセッションです。 時間は1時間のものが多いです。 作業の進捗が確認されることなどはないので、のびのびと作業に集中できます。 メンターの説明や質問をするときには英語のリスニング・スピーキングが必要ですが、それらがなくてもドキュメントを読んで作業さえできれば良いので求められる英語レベルは3としました。 技術レベルは3としました。レベルの高いセッションだと何も分からないということもあるかもしれませんが、だからと言って何か晒されるということもないと思うので全然大丈夫です! 参加したセッション Session Details Automate your software tasks with agent hooks [REPEAT] (DVT302-R) Learn new development skills with Kiro [REPEAT] (DVT201-R) Workshop 求められる英語レベル: ⭐️⭐️(2/5) 求められる技術レベル:⭐️⭐️⭐️(3/5) 総合オススメレベル:⭐️⭐️⭐️⭐️⭐(4/5) 全体に向けての簡単な説明の後にドキュメントを見ながら各々で作業をする形式のセッションです。 時間は2時間が多いです。 こちらから積極的にメンターに質問しなければ、黙々と作業をすることになります。 Builders' sessionと同様で、進捗を管理されることもないのでのびのびと作業することができます。 黙々と作業している時間が長すぎてラスベガスに来ていることを忘れかけた瞬間があったのでオススメレベルは4としました。 参加したセッション Building generative AI-powered full-stack applications [REPEAT] (ARC201-R) Rapid prototyping with Kiro CLI [REPEAT] (ARC308-R1) Create secure, production-ready code with Amazon Q Developer (DVT309) GameDay 知らない人との混合チームで参加する場合 求められる英語レベル: ⭐️⭐️⭐️⭐️(4/5) 求められる技術レベル:⭐️⭐️⭐️⭐️(4/5) 総合オススメレベル:⭐️⭐️⭐️⭐️⭐️(3/5) 知り合いでチームを作って参加する場合 求められる英語レベル: ⭐️⭐️(2/5) 求められる技術レベル:⭐️⭐️(2/5) 総合オススメレベル:⭐️⭐️⭐️⭐️⭐️(5/5) タスクを達成するたびにポイントが加算されていき、チームごとに順位を競う形式のセッションです。 時間は3時間程度のものが多いです。 知り合い同士でチームを作ることも、1人で行って知らない人との混合チームを作ってもらうことも可能です。 知り合い同士だったら出来なくてもなんでもないし、日本語で会話すれば良いので敷居はかなり低いです。 一方1人で参加して知らない人との混合チームになる場合は英語でメンバーと会話する必要があるので敷居がちょっと高いかなと思います。 ただタスクを達成される度にポイントが入ってランクが上がっていく感覚はかなり楽しいので、ぜひ経験してみていただきたいです! 参加したセッション AWS Jam: DevOps & Modernization - Sponsored by LaunchDarkly (GHJ303) 終わりに 各セッションのイメージ分かりましたでしょうか? 行ってみて初めて分かることも多々ありますが、事前の計画が大切です! re:inventを100%楽しめるように、事前に調査してしっかり計画立てていきましょう! 参照元メモ 【AWS re:Invent 2025】AWS re:Invent 2025 に参加してきました! | マイナビエンジニアブログ
イベント概要とこの記事の目的 法人ディベロップ課のS.Sです! 日々、アプリケーションエンジニアとして、法人ソリューション事業部向き合いで、サービスの開発・保守を行なっております。 先日、AWS のセキュリティイベント 「Security for App Builders @ Loft #1」  に参加してきました。 私は、セキュリティ専門ではないアプリケーションエンジニアですが、 このイベントで、セキュリティへの関心がよりより湧き、 未然に防ぐ具体的なアクションに取り組まねばな、と改めて思わされました。 この記事では、 「Security for App Builders @ Loft #1」 で、何を学んだのかを記すとともに、 「アプリケーションエンジニアで、セキュリティについて気にはなっている」という方の参考になれば幸いです。 改めて、この記事の内容・目的は、以下の 4 点です。 イベント内セッションの概要を記載しつつ、学びと理解を整理する アプリケーションエンジニアのセキュリティ意識や理解を深めてもらう セッション内容の共有と、背景知識やちょっぴりの深掘り情報の共有 セキュリティ専門じゃないアプリエンジニアとして、「これから試してみたい脅威の洗い出しのやり方」のたたき台をまとめる そこそこの分量になっているので、気になるタイトルをポチポチとかいつまんで見ていただけると幸いです。 なぜ、今、アプリケーションエンジニアがセキュリティを強く意識すべきなのか OWASP Top 10 とアクセス制御の不備 冒頭で触れられていたのが  OWASP Top 10  です。 OWASP Top 10 は、Web アプリケーションの代表的なリスクを 10 項目に整理したもの 直近の正式版は  OWASP Top 10: 2021  で、たとえば A01:2021 – Broken Access Control(アクセス制御の不備) A02:2021 – Cryptographic Failures… といった分類があります セッションでは、 OWASP のデータに基づき、「アクセス制御の不備」が一定割合(3.73%)で見つかっている という話がありました。 プロのエンジニアの手で開発されたサービスにおいて、アクセス制御の不備という重大な脆弱性が、およそ4%(100件に4件)も起こり得てしまうという点に驚いたとともに、エンジニアとしてお仕事を続けていれば、誰しも1度は発生させてしまうくらいの可能性があるなと背筋が伸びました。 参考: OWASP Top 10:2021 (英語) https://owasp.org/Top10/ Broken Access Control の解説 (英語) https://owasp.org/Top10/A01_2021-Broken_Access_Control/ シフトレフト:後になるほどコストが跳ね上がる 工数やスケジュールが限られた中での開発で、往々にしてセキュリティ対応は後回しにされてしまいます。 けれども、セキュリティ対応は、 開発ライフサイクルの早い段階で取り込むほど「コストは低い」「被害は小さい」 ので、むしろ開発サイクルのはやい段階で取り組むべしというお話でした。 仕様検討(要件定義)で気づく → 仕様の一部修正で対処可能 実装中に気づく → 実装の修正で対応可能 リリース後に顧客やインシデントで気づく → 影響調査、データ復旧、顧客への説明、信用回復など大きなコスト 絵にするとこんな感じです。 この「セキュリティを開発プロセスの左側に寄せる」考え方が 、 Shift-left(シフトレフト)  です。 矛盾しているように聞こえますが、工数やスケジュールが限られているからこそ、開発サイクルの中でも、なるったけ早くに、セキュリティ対応をすべしということですね。 参考: DevSecOps とは何ですか? https://aws.amazon.com/jp/what-is/devsecops/ AWS Well-Architected Framework – Security Pillar https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/welcome.html ビルダーのための脅威モデリング さて、ここからが、今回のタイトルに直結する部分です。 (サビです) 「脅威モデリング」とは何か こちらのセッションでは、まず「脅威モデリング」の定義から整理されました。 脅威モデリングとは システムに対する脅威を特定・列挙し、 それぞれにどう対応するかを検討し、優先順位をつけるプロセス 開発ライフサイクルで置く場所は、 計画 → 設計(ここで脅威モデリング) → ビルド → テスト → デプロイ → 保守 です。 絵にするとこうです。 参考: OWASP Threat Modeling Cheat Sheet (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html AWS Prescriptive Guidance – Threat modeling on AWS (英語) https://docs.aws.amazon.com/prescriptive-guidance/latest/security-reference-architecture/threat-modeling.html 脅威モデリングの進め方 セッションで紹介されていた流れは、以下の 4 ステップでした。 「何を作っているか」を明確にする アーキテクチャ図 データフロー図 何が問題になり得るか洗い出す チームで脅威を議論する 対応方針を決め、優先順位をつける ここでのポイントは、 可視化をして、PJメンバー全員で前提・問題の認識を揃えること → 図がないと、どこに攻撃面があるか議論できない 1 回きりではあまり意味がなく、ライフサイクルに組み込む必要がある という点です。 絵にするとこうです。 STRIDE など、代表的なフレームワーク 脅威モデリングでは、次のようなフレームワークが紹介されました。 STRIDE DREAD PASTA(Process for Attack Simulation and Threat Analysis) Trike VAST(Visual, Agile, and Simple Threat) OCTAVE(Operationally Critical Threat, Asset, and Vulnerability Evaluation) 今回、取り上げられていたのは  STRIDE  でした。 網羅性が高く、チームでの議論の「型」として使いやすい のが理由です。 STRIDE の 6 要素 S: Spoofing identity(なりすまし) 攻撃者が正当なユーザーやシステムであるかのように振る舞うこと 例: 攻撃者が他人のIDとパスワードを不正に入手し、そのユーザーになりすましてシステムにログインする 例: 偽のWi-Fiアクセスポイントを設置し、正規のネットワークであるかのように見せかけて接続させる T: Tampering with data(改ざん) データや通信内容を許可なく変更すること 例: オンラインバンキングの通信を傍受し、送金金額や送金先口座番号を書き換える 例: Webサイトの設定ファイルを書き換え、訪問者を悪意のあるサイトへリダイレクトさせる R: Repudiation(否認) ユーザーが行った操作やアクションを「やっていない」と主張できる状態、またはその証拠がないこと 例: ログ機能が不十分なシステムで、従業員が不正なデータ削除を行ったが、「自分はやっていない」としらを切られ、証拠が出せない 例: 電子署名がないメールで契約の承認を行い、後になって「そのようなメールは送っていない」と主張される I: Information disclosure(情報漏えい) 機密情報が権限のない人間に閲覧・公開されること 例: データベースの設定ミスにより、顧客のクレジットカード情報がインターネット上で誰でも閲覧できる状態になる 例: エラーメッセージに詳細なシステム内部情報(パスやDB構造など)が表示され、攻撃者にヒントを与えてしまう D: Denial of service(サービス拒否) 正当なユーザーがサービスやリソースを利用できない状態にすること 例: Webサーバーに大量のアクセス(DDoS攻撃)を送りつけ、サーバーをダウンさせて一般ユーザーが閲覧できないようにする 例: アカウントロック機能を悪用し、わざとパスワードを何度も間違えて特定ユーザーのアカウントをロックさせる E: Elevation of privilege(権限昇格) 本来持っている権限以上の操作ができるようになること 例: 一般ユーザーとしてログインした攻撃者が、システムの脆弱性を突いて管理者(root/admin)権限を奪取する 例: URLのパラメータを書き換えることで、本来アクセスできない他人の注文履歴ページを閲覧・操作する これを「自分たちのシステム構成図・データフロー図」に対して当てはめていくことで、脅威モデリングができます。 参考: Microsoft – The STRIDE Threat Model (英語) https://learn.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats OWASP Threat Modeling Cheat Sheet 内の STRIDE 解説 (英語) https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html#stride ドメイン特有の脅威に目を向ける 一般的に、下記のような 共通の脆弱性  は見つけやすいですが、 SQL インジェクション XSS 典型的な認証バイパス ビジネス/ドメイン特有の脅威  は見逃されがちです。 例: EC サイト 在庫数や価格の改ざん ポイント/クーポンの不正利用 B2B SaaS テナント分離の不備による他社データ閲覧 管理権限の誤委譲・誤設定 サブスクリプションサービス 無料トライアルの不正延長 請求先のなりすまし 脅威モデリングでは、こういった「そのサービス特有のリスク」を意識的に洗い出せる点が大きな価値です。(ドメイン理解の深い事業会社のエンジニアの価値発揮できるポイントですね) チームでやることの意味 脅威モデリングは、セキュリティ専門家だけの作業ではない、「チームでやるべきことである」ということが強調されていました。 プロダクトオーナー アプリケーションエンジニア インフラ/SRE セキュリティ担当 など複数ロールで実施することで、 「多様なペルソナ(攻撃者像・利用者像)」を出し合える 見落としが減る という効果があります。(今の時代は、更に、AI というもう一人の存在の力も借りるのも有効ですね) セキュリティ専門じゃない自分が「脅威の洗い出し」をどう始めたいか 正直な所、私はまだ、日々の開発の中で、 本格的な脅威モデリングを回せていないです。 (新規開発や保守をしていく上での脆弱性診断や対策は行ってはいますが) このセッションを聞いて、「まずはこのくらいのスコープからなら試せそう」と感じたものがあったので、簡単に流れを書いておこうと思います。 新しい機能や API を作るときだけでもよいので対象を絞る ざっくりした構成図・データフロー図を描く(ホワイトボードや Miro 等の書き出せるものでOK) STRIDE の 6 つを観点にして 、「なりすましは?」「改ざんは?」「情報漏えいは?」… を見ていく 出てきた脅威のうち 「すぐ直せそうなもの」 「影響が大きいもの」 を対策に落とす AI を活用した脅威モデリング支援 後半戦では、 AI を活用して脅威モデリングの手間を減らす という話が出ていました。 登場したのは「AI エージェント」的なコーディング/解析支援のイメージで、AWS でいえば  Amazon Q Developer  ですね。(今は、 kiro  ですね) AI にやらせる部分 vs 人間がやる部分 スピードや網羅性に関しては、AI の方が人間よりも優れていることが多いので、うまくAIと人間で分業をして協業することが重要そうだなと感じました。 AI に任せやすい部分: ワークロードの図式化 アーキテクチャ説明文から簡易図を生成させる 想定される脅威の洗い出し 「この構成に対して STRIDE 観点で脅威を列挙して」 想定される脅威への一般的な対応策の候補出し リスク評価のたたき台 「影響度が高そうな順に並べて」 人間が担うべき部分: 脅威モデリングそのものの意義と目的の理解 事業やサービスのドメイン周りの脅威洗い出し 「何を対象に、何のために」脅威モデリングするかの設定 事業戦略・リスク許容度に基づく  優先順位付けと最終判断 「 AI は“脅威のたたき台”を出してもらうところまで 」と割り切り、 最後の判断と、プロダクト側への落とし込みは人間がやる といった線引きで使っていきたいと感じました。 セキュリティのシフトレフトと AI 活用 攻撃は 100% 防げないが、被害は限定できる このセッションは、 「リスクをゼロにはできないが、 被害を限定し、復旧を容易にすることはできる」 という前提から出発していました。 例として挙げられたランサムウェア攻撃の典型フロー: ネットワークスキャン 脆弱性の調査・悪用 ランサムウェアの設置 ランサムウェアがターゲットシステムで動作 情報の窃取や暗号化 どこか一段階でも早く検知・防御できれば、 「完全な被害」から 「一部のシステムだけ」「一部データだけ」で済む可能性が高まる という話です。 DevSecOps と AI の進化 2015年ごろから、セキュアコーディングについて、叫ばれていたが、業務に落とし込むことが物理的な制約のため難しかったけれど、2025年現在のAI の進歩により、実現可能になったので、今こそ改めて、セキュアコーディングへチャレンジをしていけるのではないかというお話でした。 2015 年ごろ DevSecOps という言葉が広がり始める ただしセキュアコーディングの学習コストが大きい 静的解析ツールなどから出る大量のアラートを人力でさばくのは現実的でない 2025 年 AI コーディングエージェントが静的解析結果を解釈し、「どこをどう直すか」まで提案 AWS の例では Amazon Q Developer による 調査(現状のコード理解、セキュリティチェック) ビルド(修正案の提案・コード生成) テスト(テストコード生成) デプロイ(PR レビュー支援、ドキュメント生成) といったフローが紹介されていました。 確かに、やりたい気持ちはあれど、なかなか手を出せていなかったですが、AI エージェントの誕生によって、良い意味で、もうそんな言い訳もできなくなったなと思いました。(← もうやってないは、怠慢かも?) 参考: DevSecOps とは何ですか? https://aws.amazon.com/jp/what-is/devsecops/ Amazon Q Developer でのコード解説や修正の例 https://docs.aws.amazon.com/amazonq/latest/qdeveloper-ug/what-is-q-developer.html セキュリティトレーニングのテーマ アプリケーションエンジニア向けに、特に挙げられていたテーマは、 ガバナンスとコンプライアンス セキュアコーディング リスクマネジメント ここでも AI を「学びの相棒」として使う例として、紹介されていました。 利用 OSS やライブラリについて 「このライブラリに既知の脆弱性はあるか?」 「この CVE(脆弱性)の影響度と対策を教えて」 自分のコードに対して 「ハードコードされたパスワードやシークレットがないか探して」 「この関数にセキュリティ上の問題はありそうか?」 これについては、既に行なっていましたが、すぐに試せて、かつ、有効な使い方だなと改めて思いました。 IAM 権限設計と IAM Access Analyzer IAM の権限設計に関しても重要なポイントがありました。 「最小権限を人間だけで完全に設計しきろうとすると、どうしても穴が出やすい」 そこで活用が推奨されていた AWS サービスが  IAM Access Analyzer  です。 AWS Identity and Access Management Access Analyzer https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html 機能の例: IAM ポリシーを解析し、「外部アカウントからアクセス可能なリソース」を検出 ポリシーの提案(Policy generation) 実際のアクセスログを分析して、「このロールに必要な最小権限」のポリシー案を生成 ここでも AI を組み合わせると、 「このポリシー JSON はどの権限をどこまで許可しているか、自然言語で説明して」 「最小権限化するために、削れそうなアクションはどれか?」 といった質問を投げることで  理解と設計の速度を上げられる 、という話でした。 自分自身、インフラ側への苦手意識が強いですが、こういった活用法を用いることで、AIエージェントの力を借りつつ、知識習得と堅牢な実装の両方を猛スピードで行なっていけるのでは?とワクワクしました。 マネージドサービスと認証・認可はビジネス差別化になり得る AI が書いたコードのセキュリティオーナーは誰か? 登壇者の方の問いかけ: 「AI が生成したコードをそのまま本番投入してよいのか? その結果に対するセキュリティの責任は誰が持つのか?」 結論としては、 「 全員がセキュリティのオーナー 」 あくまで、AI は「候補」を出してくれる 存在 それを採用するかどうか、どうレビューするかは人間と組織の責任 ということでした。 本当にこの通りで、最後に出す判断を下すのは我々人間なので、これまで以上に、出すものは、本当にこれで問題がないのかは、厳格に見極める必要があるなと感じました。 Culture of Security AWS では、社内外で継続的に、 セキュリティに関する発信 勉強会 事例共有 インシデントからの学びの共有 を行い、トップダウンで  「Culture of Security」  を作っているという紹介がありました。 組織やPJ のトップが、セキュリティへの関心や発信を積極的に行うことが、セキュリティへの意識・行動を想起するには重要とのことでした。 参考: AWS セキュリティ文化 https://aws.amazon.com/jp/security/culture-of-security/ AWS Security Blog 一覧 https://aws.amazon.com/blogs/security/ 認証・認可設計は「ビジネス差別化」にもなる 特に印象に残ったのが、 「優れた認証・認可の仕組みは、 セキュリティ対策であると同時に、ビジネスの差別化要因になる」 というお話でした。 各サービスごとにバラバラなユーザー管理をしている ユーザー体験:ログインが面倒、アカウントが分散 事業側:サービス横断の体験・クロスセルが難しい 統合された認証・認可基盤がある 一度ログインすれば複数サービスをシームレスに利用可能 ユーザー行動を横断的に把握できる セキュリティ設計がそのまま UX と事業戦略に効いてくるという例ですね。 認可アーキテクチャの用語整理 認可ロジックをアプリコードにべた書きせず、外部の仕組みに任せやすくするための概念として、以下の用語が紹介されていました。 PEP: Policy Enforcement Point 実際のアクセス要求をブロック/許可する「ゲート」 PDP: Policy Decision Point ポリシーに基づき「許可/拒否」の判定を行うコンポーネント PAP: Policy Administration Point ポリシー(ルール)を管理・編集するコンポーネント PIP: Policy Information Point 判定に必要な属性情報(ユーザー属性、リソース属性など)を提供するコンポーネント この分離により、アプリ側コードは「PEP と対話するだけ」で済み、 認可ルール自体は外部で一元管理しやすくなるとのことでした。 参考: AWS – Amazon Verified Permissions(ポリシーベースの認可サービス) https://aws.amazon.com/jp/verified-permissions/ セキュリティ専門じゃないアプリケーションエンジニアとして、始めてみたい「脅威の洗い出し」(+AI 活用) 最後に、これまでのセッション内容を踏まえて、 実際に現場で「脅威の洗い出し」をどう始めてみたいか を、具体的な手順として書いてみます。 これから試してみたい「ざっくり手順」 まず、 自分用の「脅威の洗い出し」のざっくり手順(案) はこんなイメージです。 対象を決める いきなり全システムではなく、「これから作る 1 機能 / 1 API」くらいにスコープを絞る ざっくり図を描く 画面遷移 or API と外部サービスの関係、データフローを簡単に図にする 守りたいものを挙げる ユーザー情報、決済情報、社内の機密データ、ポイント残高 など STRIDE を観点に「脅威のたたき台」を AI に出してもらう AI の結果を見ながら、チームで 60〜90 分だけ議論する 「今すぐ対応するもの」を 2〜3 個だけ決めて、実装・レビューに反映する 仕様書を AI に渡して「脅威のたたき台」を作る 要件定義書・仕様書・画面遷移図などを AI に渡して、 「この仕様から想定されるセキュリティリスクを、STRIDE の観点で列挙して」  と依頼する その出力をもとに、チームで 60〜90 分の脅威モデリングミーティングを行う 「AI は“思いつきの網羅”担当、人間は評価と意思決定担当」  くらいに役割分担するイメージで進められたらと思います。 依存ライブラリの脆弱性を AI に要約させる これもすぐにできて、セキュリティリスクを抑える有効な手段なので、書いておきます。 npm audit ​ などの結果や、SCA ツールのレポートを AI に渡し、 「特に優先度が高いものはどれか?」 「どのライブラリは自分たちのアーキテクチャでは影響が小さそうか?」 を整理してもらう これにより、 「アラートの山」から「今すぐ直すべき山」を特定 して、優先度の高い脆弱性を潰せる可能性を高めます。 既存コードベースの「簡易セキュリティ健診」 重要なモジュールや API ハンドラを中心に、AI に次のような観点で探してもらう ハードコードされたパスワード/API キー 認証・認可チェックが抜けていそうなエンドポイント 危険な関数( eval ​ など)の利用 その結果から「怪しい箇所リスト」を作り、 人間が一つずつレビューしていく AI には広く粗く見てもらって、最後の判断は人間で、という分業で進められたらと思います。 セキュリティ文化を根付かせる動き 脅威の洗い出しを 一度きりのイベントにしない ために、 次のような小さな仕掛けをチーム内で提案してみたいと思っています。 大きな機能追加のたびに 「脅威モデリングをやったか?」をチェックリストに入れる 月 1 回程度の 「インシデント/ヒヤリハット共有会」を開く 上長に、セキュリティ文化を根付かせる発信やアクションを提案する (この記事を読んで頂こう) ここにあげた手段を提案し、発信や実際に定期的イベントを行う いきなり、大きく完璧にやろうとすると、大抵続かない、うまくいかないので、まずは 「新しい機能を作るタイミングで、脅威モデリングを行う」 ところから始めてみたいと考えています。 ゆくゆくは、組織単位で、例えば上記のようなことが浸透していけることが最終ゴールにできればなと思います。 現時点では、ここに書いた「脅威の洗い出しのやり方」はあくまで これから試してみたい案 です。 実際に回してみてうまくいった点・うまくいかなかった点が見えてきたら、続編としてアップデートしていきたいと思います。 追記 開発で携わっているPJ で、早速、新規API を作成する機会ができたので、早速、脅威モデリングをお試しでやってみようとなりました。 初回なので、あまりに厳密にやりすぎず、脅威モデリングにおいて、重要な要素をシンプルに抽出して、進めていきます。 「実際に、やってみた」の記事も書けたら、書きます。
はじめに 2025年はAIエージェントによるコーディングがかなり浸透した1年だったのではないでしょうか。Claude Code、GitHub Copilot、Cursor をはじめとするAIエージェントによるコード生成ツールが普及する中、現場のエンジニアは実際にどのような効果を実感し、どのような課題に直面しているのでしょうか。 本レポートでは、2025年12月末に社内のエンジニア・マネージャー約100名を対象に実施したアンケート調査の結果をもとに、 満足度・生産性・コード品質・スキル向上 の4つの観点からAIツールの活用実態を分析します。 主な発見 観点 結果 満足度 約9割が満足、NPS +32と高い推奨意向 生産性 約65%が1日1時間以上を節約、バグ対応・コード理解で特に効果を実感 コード品質 「やや高い」が最多だが、約9割が何らかの修正を実施 スキル 新技術習得は加速する一方、「自力で書く力」への懸念も約4割 経験年数による傾向 若手〜中堅層(1〜5年) :満足度・生産性向上の実感が高い一方、スキル低下への懸念も強い ベテラン層(10年以上) :慎重な評価だが、確立されたスキルの上でAIを活用 以下、各セクションで詳細を見ていきます。 回答者の基本情報 社内エンジニア・マネージャー約100名から回答を得ました。 項目 概要 職種 バックエンド・フロントエンド中心、インフラ・マネジメント・モバイルも多数 経験年数 1〜10年がボリュームゾーン(詳細は下図) 使用言語 TypeScript/JavaScript最多、Ruby・PHP・Pythonが続く 利用ツール GitHub Copilot と Q Developer/Kiro で約8割 利用頻度 約7割が「ほぼ毎日」、週3〜4日含め9割超が日常的に活用 経験年数 使用言語 利用頻度 AIツールへの満足度 AIツールに対する満足度を「全体満足度」「期待との比較」「同僚への推奨度(NPS)」の3軸で調査しました。結果として、 全体的に高い満足度 が確認されましたが、一部に注意すべき声も見られました。 約9割が「満足」と回答 全体満足度では、 合計約90%が満足 と回答しました。「非常に不満」はゼロであり、AIツールが日常業務に定着していることを裏付けています。 期待を上回る効果を実感 導入前の期待と比較して、 約65%が期待以上の効果を実感 しています。「期待通り」を含めると96%以上がポジティブな評価であり、導入判断が正しかったと言えます。 NPS +32:高い推奨意向 同僚への推奨度を問うNPS調査では、平均スコアが 約8.0 、NPSは +32 となりました。これは「良好」とされる水準であり、多くのエンジニアが同僚にも利用を勧めたいと考えています。 推奨の声と懸念の声 推奨する理由(抜粋) 壁打ち相手として最適 AIツールがなかった時代にはもう戻れない 懸念・注意点(抜粋) 使い方を誤ると逆効果。リテラシーが必要 自分で考える時間が減り、成長が滞る可能性 PRが増えてレビュー負荷が高まっている これらの声から、AIツールは 「使いこなせば強力な武器」 である一方、 組織としての運用ガイドラインや教育 が求められていることが読み取れます。 経験年数による回答の傾向 経験年数 平均スコア 推奨者(9-10) 中立者(7-8) 批判者(0-6) 1年未満 8.4 50% 43% 7% 1〜3年 8.2 50% 35% 15% 3〜5年 8.3 45% 45% 10% 5〜10年 8.0 42% 46% 12% 10年以上 6.9 22% 45% 33% 経験年数別に観察しますと、 若手〜中堅層(1〜5年)は特に高い満足度 を示していました。「非常に満足」の割合は38〜43%、NPS平均も8.0〜8.4と高水準でした。学習効率の向上や開発スピードの改善を実感している声が多く見られました。 ベテラン層(10年以上)はやや慎重な評価 となりました。「非常に満足」は22%にとどまり、NPS平均も6.9と他層より低い結果です。自由記述では「AIの出力を見抜く力が必要」「本人ができないことをAIで補う使い方には懐疑的」といった声があり、 AIツールの限界を理解した上での活用 を重視していることがうかがえます。 生産性への影響 AIツールの導入により、エンジニアの日常業務はどのように変化したのでしょうか。時間節約効果、業務品質の変化、そして残された課題について詳しく見ていきます。 1日1〜2時間の節約が最多、「2時間以上」も4人に1人 「AIツールにより1日あたりどの程度の時間を節約できているか」を尋ねたところ、 最も多かったのは「1〜2時間」で約38% でした。さらに 「2時間以上」と回答した人も約24% に達し、AIツールが単なる補助ではなく、業務時間を大幅に短縮する「生産性を向上させるツール」として機能しています。 ただし「ほとんど節約できていない」という回答も存在し、ツールの活用度合いや業務内容によって効果に差があることも示唆されています。 5つの業務指標すべてで改善傾向 導入前後の変化を5段階評価で調査した結果、 すべての項目で「向上」「やや向上」が過半数 を占めました。 ただし「集中状態(フロー)への入りやすさ」は改善効果が限定的 で、「向上」は約45%にとどまり、「やや悪化」も約12%存在します。AIとの対話や提案の確認作業が集中を中断させること、また生成待ち時間に別作業を行うようになったことが要因と考えられます。 課題の中心は「AIの限界」と「検証コスト」 AIツール利用時に感じる課題を複数選択で尋ねたところ、 上位3つは以下の通り でした。 コンテキストの理解が不十分 (約45%) AIの出力を検証する負担が大きい (約40%) セキュリティ面での不安 (約38%) これらの課題は相互に関連しています。AIがプロジェクト固有の文脈を十分に理解できないと、ロジックの誤りや不適切なコードが生成されやすくなります。その結果、開発者はAI出力の検証に多くの時間を割く必要があり、見落としによるセキュリティリスクへの不安にもつながっていると考えられます。 AIが最も力を発揮するのは「バグ対応」と「コード理解」 「生産性向上に最も貢献している作業」を上位3つまで選択してもらった結果、 問題解決(バグ対応)や理解支援 といった「思考を補助する」用途で高く評価されています。エンジニアがAIを「コードを書かせる道具」ではなく、 「一緒に考えるパートナー」 として活用し始めていることを示しています。 コード品質への影響 生産性の向上が確認された一方で、「品質は犠牲になっていないか?」という懸念もあります。本セクションでは、AIツールが生成するコードの品質評価と、導入後の品質指標の変化を詳しく見ていきます。 品質評価は「やや高い」が最多——ただし検証は必須 AIが生成するコードの品質について、 「やや高い」が約50% で最多となりました。一方で「普通」も約40%を占め、 「非常に高い」はわずか約3% にとどまっています。 この評価を裏付けるように、出力の検証・修正状況では 約9割が何らかの修正を加えている と回答。「ほぼそのまま使用」はわずか2%でした。 注目すべきは、 「大幅な修正が必要」がゼロ だった点です。AIの出力は「使い物にならない」レベルではなく、 「手直しすれば十分使える」品質 といえます。エンジニアはAIを「完璧なコードを生成する」ものではなく、 「たたき台を素早く作るツール」 として活用しているようです。 経験年数による傾向:若手ほど「改善」を実感 経験年数別に品質評価を分析すると、 若手〜中堅層(1〜5年)は「やや高い」の割合が高く 、AIツールの品質に対して好意的な評価を示しています。一方、 ベテラン層(10年以上)は「普通」「やや低い」の割合が相対的に高く 、より厳しい目で品質を評価していることがうかがえます。 これは満足度セクションで確認された傾向と一致しており、ベテラン層が 「AIの出力を見抜く力が必要」 と考えていることの表れと考えております。 学習・スキルへの影響 AIツールの活用は、エンジニアのスキル向上にどのような影響を与えているのでしょうか。本セクションでは、スキルへの影響、依存への懸念、そして今後の利用意向について詳しく見ていきます。 新技術の習得速度が最も向上、一方で「自力で書く力」には懸念 スキル向上への影響を4つの観点から調査した結果、 項目によって明暗が分かれる 結果となりました。AIツールが「学習のハードルを下げる」役割を果たす一方で、頼りすぎによる基礎力低下のリスクが懸念されています。 自由記述では以下のような声が見られました。 学習効率向上を実感する声: 他チームメンバーに聞かなくても、壁打ち相手になってくれるので、自身の理解向上やチームの生産性向上に大きく貢献しているため スキル低下への懸念を示す声: 仕事自体は進むが、成長の側面で考えると良くないと感じる部分も多いため スピードや品質は向上するが、深く理解しないままAIで一定のコードや正解らしき情報が出力されるため、自分で深く考えたり調査したりする時間が減り、技術的な成長が滞るため 約4割が依存に「懸念あり」——ただし意見は二分 AIツールへの依存について尋ねたところ、 約45%が何らかの懸念を示しました 。一方で、 「あまり懸念なし」「全く懸念なし」も約39% と拮抗しており、エンジニアの間で意見が分かれています。 自由記述では、懸念の有無にかかわらず 「使い方次第」 という認識が共通して見られました。 利用できるのであれば、使わない理由はないと思っている。ただし、エンジニアとしての今後の成長を考えるのであれば、利用範囲、パターンは考えた方が良いとは思っている また、経験年数による活用の違いを指摘する声もありました。 エンジニア歴が非常に浅い人には鵜呑みにしてほしくないと思っています。理由は書いたコードの説明ができない程、自分の頭を使わないようになってコードに責任を持てない可能性がある為です。歴が長い人であれば生成されたコードが期待通りなのかそうではないのか判断がつくのでお勧めできます 一見万能に見えるが、正しい使い方を知らなければかえって効率が悪くなる。また、手作業の方が早いタスクもある。ただ使うだけで他メンバーに迷惑をかけるような人材には勧めない。リスクやデメリットもしっかりあるものだと理解している人だけに勧めたい 経験年数による傾向:若手ほど「自力で書く力」への悪影響を実感 経験年数 自力で書く力に「悪影響」「やや悪影響」と回答した割合 1年未満 約40% 1〜3年 約50% 3〜5年 約55% 5〜10年 約40% 10年以上 約35% 興味深いのは、 1〜5年目の若手〜中堅層で「自力で書く力への悪影響」を感じる割合が高い 点です。基礎スキルを習得・定着させる時期にAIツールに頼りすぎることへの自覚があると考えられます。 一方、ベテラン層(10年以上)は「悪影響」の割合が相対的に低く、 すでに確立されたスキルの上にAIを活用している ため、悪影響を感じにくい傾向がうかがえます。 継続利用意向は97%——「なくてはならないツール」へ 今後の継続利用意向を尋ねたところ、約97%が継続利用を希望しています。スキルへの懸念がありながらも継続利用を希望する声が圧倒的多数であることから、AIツールは 「課題を認識しつつも手放せない存在」 になっていることがわかります。 組織への要望:「ガイドライン整備」が最優先 AIツールの活用促進のために組織に取り組んでほしいことを尋ねた結果、 上位は以下の通り でした。 順位 取り組み内容 選択率 1位 利用ガイドライン/ベストプラクティスの整備 約55% 2位 セキュリティポリシーの明確化 約40% 3位 効果的な活用事例の共有 約38% 4位 社内勉強会・ナレッジ共有の機会 約32% 5位 ライセンスの追加付与 約30% 6位 新しいツールの試験導入 約28% 「利用ガイドライン/ベストプラクティスの整備」が過半数を超え、最も強く求められている ことがわかります。これは生産性セクションで確認された「社内ルール/ガイドラインとの整合性」への課題意識と一致しています。 自由記述でも、組織としての取り組みを求める声が見られました。 間違いなくAIを使った方がいいが、各個人単位ではなくPJや組織としてのAIを活用する前提での開発フローの共有が欲しい 今後に向けて AIツールの効果を最大化し、リスクを最小化するためには、以下の取り組みが求められます。 重点施策 1. 利用ガイドラインの整備 サイボウズ株式会社の新人研修資料 では、「裏取りは必ず行うこと」と明記し、AI出力を盲信しない姿勢を研修段階からエンジニアに伝えています。 弊社でも、セキュリティポリシーの明確化に加え、AI出力の検証プロセスをガイドラインとして整備していきます。 2. ナレッジ共有の促進 READYFOR株式会社のアンケート では、組織に求めるサポートとして「チーム内での経験・課題共有の場」が67%と高い割合となっています。 弊社のアンケートでも同様の声が見られました 。 また、 株式会社エブリー では、AIツールを用いた開発効率化の勉強会を開催し、知見を共有しています。 弊社でも、効果的な活用事例や失敗事例を共有する場を定期的に設けていければと考えております。 3. スキル育成との両立 本アンケートでは、1〜5年目の若手〜中堅層で「自力で書く力への悪影響」を感じる割合が高い結果となりました。この課題に対し、他社では以下のようなアプローチを取っています。 フリー株式会社 : 新卒研修を「前半6週間はAI禁止」「後半5週間はAI全力活用」の2段階構成とし、基礎スキル習得とAI活用のバランスを設計 クラウドエース株式会社 : AIの出力に対する「なぜこの実装なのか」を問う習慣化を徹底し、AIの言いなりにならない開発者を育成 弊社でも、特に若手層に対する基礎力強化の機会を確保しつつ、AI活用スキルを高める両輪のアプローチを検討していきます。 継続的な改善に向けて 定量的な効果測定 今後はアンケート結果だけでなく、ツールの使い方を定量的にメトリクスをもとに分析していきます。 フリー株式会社のAI駆動開発2025レポート では、トークン消費量やリクエスト数などの定量データを継続的に測定しています。 組織的な推進体制 組織戦略としては、 合同会社DMM.comのAX戦略 や フリー株式会社の組織設計 も参考に、組織全体での利活用を促進する仕組みを整えていきます。 おわりに AIは「完璧なコードを書く」ツールではなく、 「たたき台を素早く作り、一緒に考えるパートナー」 です。この認識のもと、組織として適切な活用体制を整えていきます。 最後までお読みいただき、ありがとうございました。
はじめに ITディベロップメント第1統括部1部開発3課のS・Kです! 普段は HugWag というトリミングサロンと飼い主のマッチングアプリの内製開発をしています! この度、ラスベガスにて開催されたAWS re:Inentにデジ戦メンバー4人で参加してきましたのでレポートします! AWS re:Inventとは AWS re:Invent とは、AWS(Amazon Web Services)がアメリカのラスベガスにて毎年開催する世界最大級の技術カンファレンスです。 今年は12/1から12/5までの5日間(実質的には12/4まで)で開催されました。 講義形式(Keynote, breakout session...etc)で最新情報が取得できたり、演習形式(builders's session, workout session)で実際に手を動かして学ぶことができます。 マイナビからは2023年から参加しており、今年で3年目になります。 参加レポも毎年上がっているので、ぜひ併せてお読みください。 (各記事大変参考になりました、ありがとうございます) 【AWS re:Invent 2024】ラスベガスで開催のAWS re:Invent 2024 に現地参戦してきました! | マイナビエンジニアブログ 【AWS re:Invent2024】S3バケットくん徹底解剖 | マイナビエンジニアブログ ラスベガスにてAWS re:InventのKeynoteに現地参加してきました!!! | マイナビエンジニアブログ スケジュール 大まかなスケジュールを示します。 なお、日本はラスベガスより17時間進んでいることに注意してください。 日本が日曜日の10:00の時、ラスベガスは土曜日の17:00です。 ラスベガス到着まで 移動時間が長いので、どうしてもハードなスケジュールになってしまいます。 飛行機で寝れるかどうかが勝負ですが、席の予約競争に敗れて4列シートの内側だったのもあって全然眠れませんでした。。 時間 説明 羽田空港に到着 11/30 13:00 絶対に遅刻できないので早めに空港に行っておきます。JTBの集合時間までマイナビメンバーでだらだらしてました。 JTB指定の場所に集合、チェックイン 11/30 15:05 JTB指定の場所に集合して、チケットの控えなどもらいます。そのまま流れでチェックインしました 羽田空港発 11/30 18:05 ほぼ定刻通りに出発!機内では事前にダウンロードしたネトフリの映画見てました。機内食は2回出ました。 サンフランシスコ空港着 11/30 10:15(日本時間12/1 03:15) 無事到着!イスが固くてお尻が痛いです、、ここから乗り継ぎでしばらく空港で待機します サンフランシスコ空港発 11/30 17:15 予定より30分遅れて飛行機が出発。さっき乗ったJAL機より今回のアラスカ航空の飛行機の方がイスが良い気がする ラスベガス空港着 11/30 19:00 空港内にスロットがあって、ラスベガスって感じです ホテル着 11/30 20:00 空港からホテルまではJTBのバスで移動します 機内食1 機内食2 サンフランシスコ入国審査 夕焼け ラスベガス空港 ラスベガス滞在中 1~4日目のスケジュールの例です 時間 説明 起床 7:30 時差ボケで浅い眠りだった気がしますが、起床 Venetianに移動 8:30 複数ある会場のホテルのうち、本日はVenetianに滞在します。宿泊しているホテルから10分くらい歩いて移動します 朝食 8:45 各会場では朝食と昼食を食べることができます。ビュッフェ形式です。 breakout sessionに参加 10:00 1時間のbreakout sessionに参加します EXPOをぶらぶら 11:00 中途半端に時間が空いたので、EXPOをぶらぶらします 昼食 12:00 昼食もビュッフェ形式です workshopに参加 13:00 2時間のworkshopに参加します 休憩 15:00 会場内はコーヒーと軽食・おやつが置いてあって食べ放題です builder's session 15:30 1時間のbuilder's sessionに参加します breakout session 17:00 1時間のbreakout sessionに参加します KIROのお化け屋敷(?)に行ってみる 18:00 なんかKIROのお化け屋敷みたいなのがあったので並んで入ってみます 19:00 ラスベガス探索 帰りがてら、周辺をぶらぶら歩いてみます 20:00 夕食 ハンバーガーショップで夜ごはんを食べます 21:00 ホテル到着 ホテルに到着します 24:00 就寝 明日に備えて寝ます 朝食・昼食の雰囲気 コーヒー 軽食・おやつ ラスベガスの街並み 日本帰国 早朝というか深夜に出発なので、re:Play(最終日に夜通しやっているイベント)に参加したらほとんど寝る時間なくなっちゃいます。。 でも、帰りはもう残りの体力について考えなくて良いので気持ちは楽でした。 時間 説明 ホテル出発 12/5 03:50 ホテルの受付あたりで集合 ラスベガス空港発 12/5 07:00 帰りもアラスカ航空 サンフランシスコ着 12/5 08:50 乗り継ぎで3時間ほど待機します サンフランシスコ発 12/5 12:50 アメリカとお別れです 羽田空港着 12/6 17:20(ラスベガス時間 12/6 0:20 ) 行きよりも2時間くらい長くて11時間くらいのフライトでした。帰りも2回機内食が出ました よく分かんない機械で検査されます めっちゃ砂漠 機内食 セッションなどについて 会場にいる時間の大部分はセッションを受けていました。 事前に予約しているセッションを軸にしながら、当日参加のセッションも詰め込んでいく感じです。 また、セッションの予約に関してはO.K.さんがまとめてくださっているので、 そちら もご確認ください! セッション以外の展示 セッション以外にもいろいろな展示があって、それをみているだけでもかなりの時間を取られてしまいます! EXPO AWSに関連した様々な企業の展示ブースがあります。 ブースではバッジやシールなどが配られているので、それを集めてお土産にしても良いかもです。 時間帯によっては軽食・おやつなども置いてあります。 KIROのお化け屋敷 KIROのお化け屋敷みたいなのがありました。 音で驚かすとかはなく、メカめかしい雰囲気でたまにKIROの説明が書かれたモニターがあるみたいな感じです。 外観 滑り台 re:Invent名物(?)のDATADOGの滑り台にも行ってきました! 横から 正面から Self-placed Training 開いた時間にBuilders Labsなどで学習を行うことができるエリアとかもありました。 場所の雰囲気 モニター re:Play 最終日の12/4にはre:Playという大規模なパーティ(?)イベントが行われます! DJやバンドの演奏、滑り台などのアトラクションやゲーム、食事・飲み物などが提供されてお祭り騒ぎって感じです。 ただ、ここで調子のって騒ぎすぎるとそのまま寝ずに長時間にフライトとなってしんどいので注意が必要です。 ブランコ DJ その他 開いた時間にいろいろ見てきました! サブウェイ 調子乗ってサブウェイ行ってみました! 全然注文の仕方が分からなくてめちゃくちゃ妥協したサンドイッチが出来上がりました、、 関係ないけど、英語が分からないのかサブウェイの注文が分からないのかっていうのは、cdkが分からないのかawsが分からないのかっていうのと同じ構造だと思いません? スタバ ラスベガスには日本以上にあちらこちらにスタバがありました。 せっかくなので注文してみました。 意外とサイズは大きくない(そして値段は高い)。 N.Yさんが「オススメで」って注文して抹茶ラテを飲んでました、絶対にそのチョイスは間違っている。 謎のプリクラ awsとは多分関係ないですが、会場のホテルの入り口近くにプリクラみたいなのがあったので撮ってみました($10)(ソロ) 外観 内観 おわりに 5日間、エンジニアとして、あるいは人間として、とても貴重な体験をさせていただきました。 決して少なくない金額を出していただいた会社、いない期間の仕事の調整に協力していただいた皆様、参加を許可していただいた上長の皆様にはこの場を借りてあらためて感謝させてください。ありがとうございました。 今後より一層僕が仕事に励むことによって、re:Inventへの投資が価値あるものだと思ってもらえるように頑張ります! ここまで記事をご覧いただいていただきありがとうございました。 もう何本か記事を書くと思うので、そちらもぜひどうぞ!