時は大AI開発時代。
Copilotすげえ、と言われていた時代から、たった数年で、ChatGPT、Cline、Cursor、Devinなどと変化し、
応募時点では、Claude Codeがあらゆるものをなぎ倒しています。
これから来るのは大「個人開発サービス」時代なのではないか!?と私は思っています。
そう、2000〜2010年代初頭、個人がWebサービスを量産していたあの時代から、たった10数年で開発現場は大きく変わりました。
ゲームにせよ、アプリにせよ、当たり前の品質がたかくなったことにより、資本力こそが開発競争力になりつつあった、と思いきや、AIがそれを変えるのではないか、と思っています。
それで、なんというか、開発するのが毎日めちゃくちゃ楽しい!!
(今の所。開催時点まであと3ヶ月。この間に仕事なくなってるかもしれないけど)
という話をしたいです。
「資格を取得しても意味がない」こんな言葉を誰かから聞いたことはありませんか?
取得した資格が履歴書を飾るだけの「お守り」になっているなら確かに「意味がない」かもしれません。
しかし、資格を戦略的に取得すれば、キャリアを指し示す強力な「武器」になります。
私自身、AWS認定15冠を含む24個の資格を取得する中で、「武器」にするための戦略を導き出しました。
このLTでは、その戦略を次の3つのステップで解説します。
せっかく資格を取得するなら「武器」にしましょう!
AIで猫も杓子も生成できる時代にブログ https://blog.usuyuki.net を書き続けています。
学生→社会人と続け5年目となったブログ執筆を踏まえて、今伝えたいことを5分に凝縮します。
「とにかく現場に行こう!」っていうの、よくあると思います。
これがなぜそうなのか。
すでに言葉で説明されていることに閉じず、自身で体験することの意味をちょっと考えてみたいと思います。
例えば、目の前にボールがあるとする。
自分は目を閉じていて、このボールを他者に動かしてもらい、静止した手を接触させた場合、触った刺激が得られるが、形状の知覚は成立しない。
一方、「なぞる」という能動的な行為をした場合はどうだろうか?
続く・・・
50代、そろそろエンジニア人生も後半から終盤へ…というところでコロナ禍が終わり、イベント・カンファレンス当日スタッフ参加を少しずつ始めた私から、(だいたい)同世代の皆さんに向けて、あえて主催者でも登壇者でもなく当日スタッフという「裏方」という立場でイベント・カンファレンスに参加してみませんか?という話です。
会社ではキャリアの終盤が近づいてくる中、一回りや二回りも若い主催者・コアメンバーの下で、様々な年代・性別のスタッフ仲間と一緒に働く経験が、今後の人生にプラスの影響を与えるかもしれません(?)
2025年の今、AIや新しいフレームワークなど「やってみたい」技術が溢れています。
私が所属する組織では、レガシーシステムの改善として、マイクロサービス化とフルリアーキテクティングで2回の失敗を経験しました。これらの失敗を間近で見ていた私は、その後ストリームアラインドチームのリーダーとして事業ドメインと向き合う中で、失敗の本質が見えてきました。
どちらも「エンジニアがやりたいこと」を起点にしたプロジェクトで、エンジニアとして綺麗なストーリーを求めて問題領域に目を向けることをおろそかにしていたのです。
現在の組織では、これまでの活動を通して「レガシーシステムのリプレイス」という技術起点の発想から脱却し、「事業として何を実現したいか」を起点とした段階的な改善に転換できました。
技術変化の激しい今だからこそ、「やりたいこと」と「やるべきこと」のバランスについて私の経験をもとに伝えたいです!
皆さん、技術カンファレンスへのプロポーザル、書いていますか?
中には、「登壇するほどのネタもないし…」「わざわざ書くほどのこともないよな…」そう思っている方もいらっしゃるかもしれません。
しかし、プロポーザルを考えて出すことがエンジニアとしての成長を加速させる、様々なメリットが秘められているのです。
この「プロポーザル駆動学習」という考え方を通じて、プロポーザルが登壇するための単なる「提出書類・前提条件」ではなく、皆さんにとっての「学習の機会」であるということをお伝えします。
2022年の末にChatGPTが現れて、はや2年余り。今日では一般の人にも広く普及し、我々の日常に欠かせないツールになりました。Gemini、Claudeなどの類似サービスも登場し、様々な用途に利用されています。
日々これらを使用する中でふと疑問に思ったことがあります。
「なぜ似たような画面なんだろう」
最初は先駆者であるChatGPTを真似しただけと考えていましたが、実は既存のUIを心理学的な根拠に基づいて応用したUIであり、理由があって選択されたものでした。
本トークでは、AIチャットボットのUIにどんな既存のUIが応用されているのか、なぜそれが選ばれたのかを解説します。
❚ ターゲット
UI/UXに興味があるエンジニア
❚ 話す内容
共通のUIパターン(2分)
AIの進化によりプロダクト開発のあり方が根底から覆る変化の激しい時代、組織や事業の状況によって、リーダーに求められる役割は常に変化します。
エンジニアリングマネージャー(EM)とテックリード(TL)の役割は、明確に分離できるものではなく、互いの領域が重なり合うグラデーションだと考えています。
特にスタートアップのようなリソースが限られる環境では、「EMはピープル、TLは技術」と綺麗に役割分担できることの方が稀ではないでしょうか。
新規開発フェーズではTL色を、メンバーの育成期にはEM色を強めるなど、リーダーには状況に応じて役割の比重を柔軟に変えることが求められます。本発表では、こうした実践例を交え、「今、求められる役割」を見極めるための一つの考え方を共有できればと思います。
また、EM/TLとしてのキャリアについて、皆さんと共に考えるきっかけになればうれしいです。
そのアドバイスは経験による知恵か、認知バイアスか。
50歳を迎え、精神的、肉体的両面で老いとの向き合いを意識するようになりました。
記憶力の低下、かつては苦労せず覚えられていたことが難しくなる瞬間。
肉体的にも無理が効かなくなってくる。
気づかないうちに老害になっていないか。
自戒を込めて同世代と、これからこの世代を迎える皆様に送る「老いとの向き合い方」です。
近年、生成AI周りの発展によって、AIがコードを書く世界観が見えつつあります。
そんな時代にエンジニアは、どのように技術やスキルを身に着け、生き残っていくと良いのでしょうか?
そんな問いに対する一つの仮説として「コミュ力」があると考えています。
このLTでは、「生成AI時代で生き残るために必要なコミュ力」とは何か、「技術・スキルを身に着けるのにどうコミュ力が役に立つのか?」にフォーカスをして、エンジニアにとって必要なコミュ力についての話をしていきます。
具体的には、コミュ力を研ぎ澄ました結果、仕事に活用 → コミュニティ活動に活用 → コミュニティ活動から技術やスキルを学ぶ機会を得て、それをまた仕事に活かす。
そんな循環を自分なりに模索して作ってみた話などもしていきます
ちょうど1年ほど前にあった上司との面談で、「もっと周りを巻き込んでほしい」と伝えられました。そこで、「自分ひとりの問題ではないのか。巻き込むと言っても何をすればいいのか」と悩みました。
悩んだ末、自分が続けられそうなこととして、自分が好きなことややりたいと思っていること、感じていることをシンプルに素直に周りに伝えるということを実践しました。
行動した結果、社内Slackで「巻き込みがすごい(意訳)」と言われるまでになりましたが、振り返ってみると自分の行動は小さな波を与えたかもしれませんが、それを大きくしたのは自分の力ではない、と思いました。
このトークでは、自分が周りを巻き込むにあたって考えていたことやマインドセット、結果としてみんなでやっていくには何が必要だったのかを話します。
周りを巻き込むのって難しい!と感じてらっしゃる方にひとりの事例として参考にしていただきたいです。
2025年4月、新しいロールを任されてから、わたしは無力感に押しつぶされていました。
「自分はダメだ、何もできない」と思い込み、立ち止まってしまっていたなと今では思います。
状況を少しずつ好転させるきっかけになったのは、「できない自分」と向き合うことでした。自分を否定せず、感情と事実を切り分け、周囲を頼りながら、前に進む力を取り戻していけたと思います。
このトークでは、自己否定から抜け出し、レジリエンスを育てていく中で取り組んだことや思考の変化を共有します!
やっとスタートラインに立てたかなと思っている「今」をお伝えします。
AIが身近な存在となった今、先輩や上司に頼らずとも知りたい情報を得られるようになりました。各人の生産性は確実に上がっている一方で、チーム内の会話が減って知識やノウハウがサイロ化し、蓄積されてきた暗黙知や文化の継承が困難になっていませんか?
AIは使う人の知識レベルで引き出せる答えの質が大きく変わるため、経験豊富なメンバーと新卒・若手メンバーとの間の知識差をさらに広げてしまう懸念があります。
また、これまで「ちょっといいですか?」と交わされていた相談がAIへの質問に置き換わることで、チーム内では「誰が何に困っているか」が見えにくくなり、偶発的な学びの機会も失われがちです。
本LTでは、これらの課題に対して試行錯誤した結果得られた、AI時代の「共有知」を育むための実践的な知見をお話しします。
AI時代のチームビルディングに悩んでいる方のヒントになればうれしいです。
2022年当時、GitHubがリリースした生成AIによるコードの生成機能は未熟であくまで副操縦士でした。
しかし2024年末から複数登場したコーディングエージェントにより、2025年現在、多くのエンジニアが「自分の仕事は奪われるのではないか」と不安を感じています。
この状況はマネージドデータベースの登場により、キャリアを不安視したデータベースエンジニアによく似ています。
実際にはデータベースエンジニアは数を減らしたものの、マネージドデータベースは決してデータベースエンジニアの仕事を奪わず、むしろより本質的で創造的な仕事へ集中することが可能になりました。
このトークでは、新人データベースエンジニアがマネージドデータベース時代にジュニアを卒業した経験から、生成AIがエンジニアの仕事を奪わない理由と、いっけん仕事を奪うように見えるイノベーションとどのように付き合うべきかの示唆を提供します。
「周り、強すぎない?」そう思ったこと、ありませんか?
技術スキルに自信がない私が選んだ、生き延びるための戦略。
弱くても価値を出す方法、2025年の今だからこそ話します。
ソフトウェアはハードウェアと違って、制約があいまいになりやすく、
それによって意図しない挙動をすることが多々あります。
もはや異なる文脈のソフトウェアとの接続、分散システムが当然のように使われる世の中。
人同士の連携で言っても、異なる文脈で育ってきた人々が連携し、多様性を重んじながら全体の系を実現する世の中。
こういった世界観では、もはやアジャイルだけでなく、カオスエンジニアリングの思想がマストになってきます。
今回は、カオスエンジニアリングの勉強会と、過去にセキュリティカオスエンジニアリングの案件に入って、
薄くなりにも経験を重ねてきて、カオスエンジニアリングを分かった気になったわたし目線で、
5分でコンパクトにカオスエンジニアリングの世界観をお届けします。
私は https://github.com/mackee/tanukirpc というGoのWebフレームワークを作って仕事でも使用しています。このフレームワークは1人でバックエンドとフロントエンド両方を作成することを目的としていて、コードファーストでAPIスキーマを作成し、APIクライアントを出力します。
ところでこのtanukirpcをAIに使わせてみたらどうでしょう、なんかうまいこと使えてる気がする! というのもAIというのは実装については人間によるコーディングをなくして自分で全部やらした方が上手くいくことが多いように思ってます。APIスキーマを書くのもAIにやらせるならスキーマファーストのメリットが無くなるのでは? という仮説のもと色々やっていったのを話します
「気付いたら、エンジニア採用の主担当になっていた」
そんなあなたに届けたい内容です。
本トークでは、私がEMとして採用を引き継いだ際に直面した課題や、初動の取り方、そして採用を成功に導くために意識していることについてお話しします。
「採用はEMの“主戦場”である」という想いについても、熱く語らせてください!
生成 AI が台頭しているこの時代、知りたい情報はチャットで体系的にわかりやすく教えてくれます。技術的な情報ブログに手間ひまかけて書かずとも、 AI に任せれば一瞬で生成してくれる可能性は高いでしょう。実際にコードの生成の多くは AI に任せている人も少なくないでしょう。
AIの方が正確で網羅的な情報を提供できる」「AIに聞けば済むことをわざわざ書く意味がない」といったブログを書くことが躊躇われるような感覚を抱くなかで、なぜ私が技術ブログを書くのかについて話します。