トーク

「資格を取得しても意味がない」こんな言葉を誰かから聞いたことはありませんか？
取得した資格が履歴書を飾るだけの「お守り」になっているなら確かに「意味がない」かもしれません。

しかし、資格を戦略的に取得すれば、キャリアを指し示す強力な「武器」になります。
私自身、AWS認定15冠を含む24個の資格を取得する中で、「武器」にするための戦略を導き出しました。

このLTでは、その戦略を次の3つのステップで解説します。

• 資格を取得する目的
• 資格の選び方
• 取得後のアクション

せっかく資格を取得するなら「武器」にしましょう！

「とにかく現場に行こう！」っていうの、よくあると思います。
これがなぜそうなのか。
すでに言葉で説明されていることに閉じず、自身で体験することの意味をちょっと考えてみたいと思います。

例えば、目の前にボールがあるとする。
自分は目を閉じていて、このボールを他者に動かしてもらい、静止した手を接触させた場合、触った刺激が得られるが、形状の知覚は成立しない。
一方、「なぞる」という能動的な行為をした場合はどうだろうか？

続く・・・

50代、そろそろエンジニア人生も後半から終盤へ…というところでコロナ禍が終わり、イベント・カンファレンス当日スタッフ参加を少しずつ始めた私から、（だいたい）同世代の皆さんに向けて、あえて主催者でも登壇者でもなく当日スタッフという「裏方」という立場でイベント・カンファレンスに参加してみませんか？という話です。

会社ではキャリアの終盤が近づいてくる中、一回りや二回りも若い主催者・コアメンバーの下で、様々な年代・性別のスタッフ仲間と一緒に働く経験が、今後の人生にプラスの影響を与えるかもしれません（？）

2025年の今、AIや新しいフレームワークなど「やってみたい」技術が溢れています。

私が所属する組織では、レガシーシステムの改善として、マイクロサービス化とフルリアーキテクティングで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年の今だからこそ話します。

私は https://github.com/mackee/tanukirpc というGoのWebフレームワークを作って仕事でも使用しています。このフレームワークは1人でバックエンドとフロントエンド両方を作成することを目的としていて、コードファーストでAPIスキーマを作成し、APIクライアントを出力します。
ところでこのtanukirpcをAIに使わせてみたらどうでしょう、なんかうまいこと使えてる気がする！　というのもAIというのは実装については人間によるコーディングをなくして自分で全部やらした方が上手くいくことが多いように思ってます。APIスキーマを書くのもAIにやらせるならスキーマファーストのメリットが無くなるのでは？　という仮説のもと色々やっていったのを話します

生成 AI が台頭しているこの時代、知りたい情報はチャットで体系的にわかりやすく教えてくれます。技術的な情報ブログに手間ひまかけて書かずとも、 AI に任せれば一瞬で生成してくれる可能性は高いでしょう。実際にコードの生成の多くは AI に任せている人も少なくないでしょう。

AIの方が正確で網羅的な情報を提供できる」「AIに聞けば済むことをわざわざ書く意味がない」といったブログを書くことが躊躇われるような感覚を抱くなかで、なぜ私が技術ブログを書くのかについて話します。

• 導入： なぜブログを書くのをためらうのか？（1分）
• AI時代だからこそのブログの価値（3分）
  • ブログを書くことによる知識の内在化
  • 人間の体験談
• ブログの執筆に AI を活用する（1分）

2025年、 Coding Agent が身近な存在になりました。 Claude Code や Cursor 、 GitHub Copilot など様々なツールが登場し、コーディング作業を大幅に効率化してくれます。
私は様々な Coding Agent を半年程度、直近1ヶ月は Claude Code を使用し、人間が到底追いつくことができない開発速度に驚く一方、明後日の方向への暴走でクレジットをドカ食いするおちゃめな一面も目撃しました。
本LTでは、暴走しがちな Coding Agent を適切にコントロールし、良き相棒として活用するための具体的な手法をお伝えします。

❚ ターゲット
Coding Agent を使い始めた、またはこれから使おうと思っているエンジニア

❚ 話す内容
典型的な暴走パターン（1分）
どうやって暴走を防ぐのか（3分）
良き相棒にするための心構え（1分）

「いつか、海外で登壇してみたい」——その夢、一緒に叶えてみませんか。
日本では出会えないエンジニアと直接交流できる場所、海外カンファレンス。多くの人が参加や登壇に興味を持っていることでしょう。しかし立ちはだかる言語の壁を前に、実際に行動に移す人はごくわずかです。
幸いにも、私は海外登壇をする機会に恵まれました。準備の中で、言語の壁を乗り越えるための工夫を数多く試し、誰もが実践できる効果的な方法を見つけてきました。こうしたノウハウを還元したいという思いから、日本Goコミュニティの海外進出を手助けするプロジェクト「Gophers EX」が生まれたのです。
このセッションでは、今年2月に始まったGophers EXの活動について、主軸となる3つの取り組みとその成果に触れながらご紹介します。海外カンファレンスへの参加・登壇やその支援に興味がある方が、最初の一歩を踏み出すきっかけになれば幸いです。

29歳男性インフラエンジニアです。
第2子の誕生を機に半年の育休を取得し、家事育児に全力投球中です。
家事を担当している中で、「こんなアプリあったらいいな」というアイデアが思い浮かびました。
今までは商用コード製造未経験がなかったので諦めていましたが、「生成AI隆盛の今なら開発できるのでは？」と思い、挑戦しました。

そんな私が「2025年の今、みんなに聞いてほしいこと」は育休や個人開発で得られた知見やそれぞれの素晴らしさです。

このセッションでは、

• 個人開発をするメリット
• 商用コード開発未経験でもできたVibe Codingテクニック
• ぼくのかんがえた最強のWebアプリアーキテクチャ（on AWS）
• Amazon Bedrockを処理に組み込む際の工夫点
• 育休中に考えた、人生をちょっと豊かにするヒント（※ポエム寄り）
  をお話しする予定です。

2025年、PHPは30周年を迎えました。

私は25年間PHPを使い続け、最近は開発やマニュアルにも関わっています。そんな立場から、節目の年にPHPを振り返ります。

テンプレートエンジンから始まり、手続き型、オブジェクト指向と姿を変え、現代のPHPは「言語としては繋がっているのに全く別物にも見える」状態になりました。

WordPressなどレガシースタイル、オートロードや型が整備された"普通の"PHP、独自の流儀を持つフレームワーク環境。それぞれ異なる世界観を持ち、どれも正しく"PHP"です。「いくつものPHP」を通じ、変化の背景や矛盾を許容してきた言語の特性を紹介します。

PHPを書いたことのない方には、この"特異さ"を通じ、普段の言語を見つめ直すヒントを。
最近のPHPユーザーには、歴史を知ることでスキルアップのきっかけを。
古くからのPHPユーザーには、懐かしさを届けます。

私は、勉強会から、そのまま懇親会をする場所では、日本酒🍶を持ち込むことがあります。

建前としては、主催者の金銭的負担の軽減や、懇親会の時に振る舞えるといのもあります。

しかし、別に壮大な理由があります。
それを話します。

50代は、これまでのキャリアで培った知識や経験が最も円熟する時期です。同時に、体力的な変化やライフステージの変化も訪れやすい時期でもあります。
「まだまだ頑張れる！」そう思われる方も多いでしょう。しかし、ここで一度立ち止まって、これからの働き方を「見直す」ことが非常に重要です。なぜなら、私自身が過去に無理をして体を壊し、その大切さを痛感したからです。

寝る間も惜しみ、体調の異変にも気づかないふりをして働き続けた結果、ある日突然、体を壊してしまいました。

そこで初めて、「健康なくして仕事はできない」「無理をすることは、誰のためにもならない」という当たり前のことに気づかされたのです。この経験が、私の働き方を根本から見直すきっかけとなりました。

無理をしない、我慢しない、停滞しない。
この3つを提案したいと思います。