【インフラエンジニア】設計構築に挑戦/残業月11時間/案件により在宅可

昨今、CloudflareはCDNやR2だけでなく、Cloudflare Workersを中心に、エッジ環境でWebアプリケーションやAIワークロードを実行できるプラットフォームとして急速に存在感を高めています。個人開発で触ったことのある方は増えてきましたが、「プロダクションで本格的に使っている」となると、まだまだ少ないのが現状ではないでしょうか。 また、AWSやGCPとは設計思想や開発体験が大きく異なるため、「興味はあるが、既存のインフラにどう導入すればいいのかわからない」「Workersで何がどこまでできるのかイメージしきれない」という声も耳にします。 そこで本イベントでは、Honoの作者でありCloudflareのDeveloper AdvocateであるYusuke Wada氏と、『Cloudflare Workers 実践ガイド』の著者の一人であるchimame氏をお迎えし、Cloudflare Workersの全体像から実践的なユースケースまでを紐解きます。 Cloudflareが気になり始めた方から、AWS/GCPメインの環境にCloudflareを取り入れたい方まで、幅広いエンジニアのご参加をお待ちしています。

AIコーディングエージェントの進化により、コードだけでなくUIデザインの領域でもAIに任せられる範囲が広がりつつあります。しかし、「AIが出力したデザインを人間のレビューなしでそのまま出せるか？」と問われると、まだ自信を持ってイエスと言える方は少ないのではないでしょうか。 そうした中、AIに「デザイナーの脳内」を型として渡し、デザインの実装だけでなく、評価や改善までを自動化していく「デザインハーネス」という考え方があります。AIにデザインをつくらせて終わりではなく、その出力を評価し、改善するサイクルをできるだけ自律的に回していくことで、AIに任せられる範囲をさらに広げていくアプローチです。しかし、デザインハーネスとは具体的に何を整備すればいいのか、実際にどこまでの品質が出せるのかを体系的に語れる事例はまだ多くありません。そこで本イベントでは、デザインシステムの構築やAIワークフローの実践に豊富な経験を持つこぎそ氏をお迎えし、デザインハーネスの基礎から、具体的な実践事例までを紐解きます。 前半のLTでは、こぎそ氏よりデザインハーネスの基礎的な考え方を整理いただいた上で、Design.mdやMCP連携、デザインシステムとの接続といった実際のワークフローに落とし込んだ実践事例、そして「デザイナーの脳内をどう型化していくか」という方法論をお話しいただきます。 後半のディスカッションでは、AIが出力するデザインの評価軸や、人間が介在すべき領域の見極め、実作業のメイン環境の選び方など、デザインエンジニアの現場目線でさらに深掘りしていきます。 AIを活用したデザインワークフローに関心がある方から、デザインハーネスの導入を検討されている方まで、幅広いデザインエンジニアのご参加をお待ちしています。

AIコーディングエージェントの進化により、コードを書くスピードはかつてないほど速くなりました。しかし、いくらAIで早くたくさん開発できたとしても、初手の要求・要件定義が十分にできていなければ、結局は使われない機能を量産してしまうのではないでしょうか。 AI時代において、設計や実装の多くはAIに置き換わりつつあります。だからこそ、人間の価値は「問題を定義し、発見する」ことにシフトしていく——そう考えると、要求・要件定義の重要度はこれまで以上に増してきています。しかし、普段の業務で要求・要件定義に本格的に取り組んだ経験がないエンジニアの方も多いのが現状です。 そこで本イベントでは、前回ご好評いただいた「AI時代×ドメイン駆動設計」に続く第2弾として、ミノ駆動氏を再びお迎えし、AI時代だからこそ向き合うべき要求・要件定義の考え方と実践を紐解きます。 前半のLTでは、ミノ駆動氏より、エンジニアに今後求められる「具体→抽象」の思考力、目的を起点とした設計の考え方、そして明日から始められる要求・要件定義の第一歩についてお話しいただきます。 後半のディスカッションでは、「Claude Codeに頼めばよしなにやってくれるのでは？」という率直な疑問から、要求・要件定義は誰が書くべきか、優秀なエンジニアの要求・要件定義は何が違うのかなど、現場目線でさらに深掘りしていきます。 「AIにコードは任せられるようになったけど、その前段階をどうすればいいかわからない」という方にこそ参加いただきたいイベントです。

AIの進化によってプロダクト開発のハードルが下がった今、企業の関心は「いかに良いものを作るか」から「どうやって市場に届け、ユーザーに使ってもらうか（Go-To-Market）」へとシフトしています。 こうした変化の中で、海外のAIスタートアップを中心に急速に注目を集めているのが「GTM（Go-To-Market）エンジニア」です。 営業でも、マーケターでも、単なる開発エンジニアでもない。 かつて10人のチームで回していた営業・マーケティング・オペレーションの設計からAIによる自動化までを、1人で主導する新たな役割です。 しかし、日本ではまだ認知が広まっておらず、「GTMエンジニアって具体的に何をしているのか」をイメージできている方はほとんどいないのが現状です。 そこで本イベントでは、GTMエンジニアリングの研究・発信を行う中村氏と、GTMエンジニアとして実践されているnumashi氏をお迎えし、海外での動向から日本での実態まで、GTMエンジニアという仕事の全体像を紐解きます。 前半のLTでは、お二人にそれぞれの視点からGTMエンジニアの役割や実際の業務内容、海外と日本での位置づけの違いについてお話しいただきます。 後半のディスカッションでは、どんな方がGTMエンジニアに向いているのか、単なる効率化で終わらせず売上に繋げるには、日本の組織での最初の一歩など、現場目線でさらに深掘りしていきます。 エンジニアとしての新たなキャリアの可能性を探している方から、GTMエンジニアリングに興味がある方まで、幅広いご参加をお待ちしています。

AIコーディングエージェントの活用が進み、多くの実装や技術選定をAIに委ねられる場面が増えてきました。そうしたなかでも、データベースを扱うORMの選定については「さすがにここだけは自分の手で決めておこう」と考えているエンジニアの方も多いのではないでしょうか。 しかし、従来の選定理由を振り返ってみると、その多くは「型補完がどこまで効くか」「どれだけ直感的にコードが書けるか」といった書き味（DX）や手厚い型サポートにあったのではないでしょうか。AIがコードを書くことが当たり前になった今、「人間にとっての書きやすさ」を軸にした技術選定のあり方には、少しずつ変化が生じ始めています。 では、もし仮にORMの選定すらもAIに任せてみようとしたとき、エンジニアとして最後まで人間が判断しなければいけない業務とは、一体どこにあるのでしょうか。 そこで本イベントでは、Drizzleを活用されているKenn Ejima氏と、Kyselyを使われている溝口（coji）氏をお迎えし、AI時代におけるORM選定の考え方と、「本当に考えなくていいこと」と「実はまだ考えるべきこと」の境界を紐解きます。 前半のLTでは、お二人にそれぞれのORM選定の背景や、AIとの付き合い方を含めた現在の開発スタイルについてお話しいただきます。 後半のディスカッションでは、DBスキーマをAIにどこまで任せるか、マイグレーションの管理、DB選定の重要性など、現場目線でさらに深掘りしていきます。 「ORMは自分が選ぶもの」と自然に思っていた方にこそ、これからの技術選定の軸を一度立ち止まって考えるきっかけになるイベントです。