トーク

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

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

続く・・・

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

私が所属する組織では、レガシーシステムの改善として、マイクロサービス化とフルリアーキテクティングで2回の失敗を経験しました。これらの失敗を間近で見ていた私は、その後ストリームアラインドチームのリーダーとして事業ドメインと向き合う中で、失敗の本質が見えてきました。
どちらも「エンジニアがやりたいこと」を起点にしたプロジェクトで、エンジニアとして綺麗なストーリーを求めて問題領域に目を向けることをおろそかにしていたのです。

現在の組織では、これまでの活動を通して「レガシーシステムのリプレイス」という技術起点の発想から脱却し、「事業として何を実現したいか」を起点とした段階的な改善に転換できました。
技術変化の激しい今だからこそ、「やりたいこと」と「やるべきこと」のバランスについて私の経験をもとに伝えたいです！

AIの進化によりプロダクト開発のあり方が根底から覆る変化の激しい時代、組織や事業の状況によって、リーダーに求められる役割は常に変化します。

エンジニアリングマネージャー（EM）とテックリード（TL）の役割は、明確に分離できるものではなく、互いの領域が重なり合うグラデーションだと考えています。
特にスタートアップのようなリソースが限られる環境では、「EMはピープル、TLは技術」と綺麗に役割分担できることの方が稀ではないでしょうか。

新規開発フェーズではTL色を、メンバーの育成期にはEM色を強めるなど、リーダーには状況に応じて役割の比重を柔軟に変えることが求められます。本発表では、こうした実践例を交え、「今、求められる役割」を見極めるための一つの考え方を共有できればと思います。
また、EM/TLとしてのキャリアについて、皆さんと共に考えるきっかけになればうれしいです。

そのアドバイスは経験による知恵か、認知バイアスか。

50歳を迎え、精神的、肉体的両面で老いとの向き合いを意識するようになりました。
記憶力の低下、かつては苦労せず覚えられていたことが難しくなる瞬間。
肉体的にも無理が効かなくなってくる。
気づかないうちに老害になっていないか。

自戒を込めて同世代と、これからこの世代を迎える皆様に送る「老いとの向き合い方」です。

近年、生成AI周りの発展によって、AIがコードを書く世界観が見えつつあります。
そんな時代にエンジニアは、どのように技術やスキルを身に着け、生き残っていくと良いのでしょうか？
そんな問いに対する一つの仮説として「コミュ力」があると考えています。
このLTでは、「生成AI時代で生き残るために必要なコミュ力」とは何か、「技術・スキルを身に着けるのにどうコミュ力が役に立つのか？」にフォーカスをして、エンジニアにとって必要なコミュ力についての話をしていきます。
具体的には、コミュ力を研ぎ澄ました結果、仕事に活用 → コミュニティ活動に活用 →　コミュニティ活動から技術やスキルを学ぶ機会を得て、それをまた仕事に活かす。
そんな循環を自分なりに模索して作ってみた話などもしていきます

2022年当時、GitHubがリリースした生成AIによるコードの生成機能は未熟であくまで副操縦士でした。
しかし2024年末から複数登場したコーディングエージェントにより、2025年現在、多くのエンジニアが「自分の仕事は奪われるのではないか」と不安を感じています。

この状況はマネージドデータベースの登場により、キャリアを不安視したデータベースエンジニアによく似ています。
実際にはデータベースエンジニアは数を減らしたものの、マネージドデータベースは決してデータベースエンジニアの仕事を奪わず、むしろより本質的で創造的な仕事へ集中することが可能になりました。

このトークでは、新人データベースエンジニアがマネージドデータベース時代にジュニアを卒業した経験から、生成AIがエンジニアの仕事を奪わない理由と、いっけん仕事を奪うように見えるイノベーションとどのように付き合うべきかの示唆を提供します。

「いつか、海外で登壇してみたい」——その夢、一緒に叶えてみませんか。
日本では出会えないエンジニアと直接交流できる場所、海外カンファレンス。多くの人が参加や登壇に興味を持っていることでしょう。しかし立ちはだかる言語の壁を前に、実際に行動に移す人はごくわずかです。
幸いにも、私は海外登壇をする機会に恵まれました。準備の中で、言語の壁を乗り越えるための工夫を数多く試し、誰もが実践できる効果的な方法を見つけてきました。こうしたノウハウを還元したいという思いから、日本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つを提案したいと思います。

「まずは一つの専門性を」。そんな正論を聞くたびに、少し悲しくなりませんか？興味の対象が広く、専門を一つに定められない。そんな私は輝かしいキャリアは歩めないだろうと考えていました。
しかし2025年の今は、そんな広い興味を持つ「マルチポテンシャライト」が輝けるのかもしれません。その理由となった実体験を紹介します。

• 興味の追求：仏教学から着想を得た「大量殺人計画者の説得」という思考実験―o3が私の思考の限界を引き上げてくれた話。
• 空想の実現：突然の起業、知見がほぼない技術スタック、使えるのは本業のスキマ時間という制約下でも、AIの助けで知識を増幅し、プロダクトを作れた話。

「一点に集中しないと」と焦るあなたが持つ広範な興味が、AIにより深化、具現化されることで、強力な武器になります。
正論から外れたキャリアだけど、それでもいいのかもしれない。そう思っていただける15分にします。

資金も人手も限られ、正解のないスタートアップでは、課題抽出と高速な学習ループが生命線です。
本トークでは、会社立ち上げから組織拡大フェーズまで様々なスタートアップフェーズの経験で、実践してきた仮説行動のサイクルを軸に

• “やらないこと”を削ぎ落として真の顧客価値を見抜く方法
• 役割を越えて課題に飛び込む越境行動を実践する方法
• 他者を巻き込み学習ループを定着させる仕組み化の方法
  について、過去の自分の経験談をもとに発表します。
  カオスを恐れず自走し、成長エンジンに変換する方法を共有します。

生成AIによって、膨大な情報の中から必要な情報にアクセスすることは非常に簡単になりました。
私自身も、OSSのコードリーディングには Deep Wiki/Search を、ドキュメントの理解には NotebookLM を多用しています。

そんな時代に、「本を書くこと」にはどんな価値があるのでしょうか？

私自身、技術書典という技術同人誌の販売イベントに参加し、疑問を抱きながら執筆を進めました。そして販売を終えた今、「本を書くこと」には、自分の内面に生まれる価値、情報を整理して伝える価値、読者との間に生まれる価値などが存在すると感じています。

本セッションでは、そんな「本を書くことの価値」について、筆者としての視点からお話しします。
セッションを通じて、「自分の体験も形にしてみようかな」と思ってもらえたら嬉しいです！

私はEM2年生。 2024年4月に新規プロダクトをリリースし、現在はそのプロダクトをなんとか成長させていくべく邁進しています。

新規プロダクトのリリース、そしてその後の成長にあたってはさまざまな進行上の課題がチームに襲い掛かりました。

・ スクラムを解釈した開発イベントがなぜかうまくいかない
・ 社内や社外からのプロダクトへのフィードバックが集まらない
・ プロダクトマネージャーとタスクの温度感がすり合わない
・ プロダクトの課題が無限に積まれ、さばいてもさばいてもなくならない
......

これらの課題が発生した背景には、新規プロダクト開発においてはフェーズごとに求められる立ち回りが大きく変化するというものがありました。

本セッションでは、そのような状況に対応するため繰り返し見直し、変更・改善してきた開発手法の変遷について、良かった点と反省点の両軸から振り返ります。

私は毎日1記事ブログ執筆という"奇行"を続けているのですが、2025年は連続1000日を踏破する年です！（6/21時点で948日）
技術ネタもアニメネタも、体調がすぐれない日も、ストックなしで業務後に勉強会参加という日も、もはや"狂気"といえるくらい、もがいて繋げてきました。
ここまで継続して得たものはいくつもあるのですが、今回は「習慣化」についての学びを共有します。
この発表を聞いても毎日ブログを書けるようにはなりませんが、聞いた方に毎週・毎月何かを継続するヒントがあったら嬉しいです。

モチベーション

• 過去の自分のため
• Today I learned
• 将来のLLMをかしこくするため
• 流入やホッテントリは狙わない

テクニック

• 1日の写真に撮るように
• 小さいは正義（移り気な私対策）
• 生成AIの利用（Copilotによるサジェスト、ネタの提供、検索代行）

マネジメントに興味はあるけど、「完璧にできるか分からない」と二の足を踏んでいませんか？

「開発以外の部分でも組織に貢献したい」
そんな思いからプレイングマネージャーを始めて1年が経ちました。2025年の今、振り返ってみると想像以上に大変でした。

最初の頃は時間の使い方が下手で、マネジメントでは無力感を感じ、プレイヤーとしても中途半端。「何をやっているんだろう」と思った日々もありました。

でも、試行錯誤を重ねるうちに、自分なりの貢献方法が見えてきました。この試行錯誤の1年間で得た経験は、確実に無駄ではなかったと感じています。

「マネジメントに興味はあるけど、一歩踏み出せない」という方に向けて、「私もまだ迷っていますが、挑戦してみて良かったです」という体験談をお届けします。

現在私は受託開発の会社で執行役員として仕事をしています。
会社からは売上や粗利など数字を求められ、数字のための施策に加えて
メンバーが働きやすい環境を作るため日々体制や制度を整えつつ
現場ではプロジェクトマネジメントをしながらも自身もコードをバリバリ書いている日々を過ごしています。

会社としての数字と現場の温度感。
それは必ずしも同じ施策でどちらも解決できるものではありません。
しかしその両方を満たしていかねば会社が回らないのもまた事実。

このトークではどちらにも深く関わるポジションとして
お互いの認識齟齬がなぜ起こるのか、それを解決するためにどうすべきかというものを自身の体験から話していきます。

みなさん。メソッド書いてますか？
生成AIを使ったコーディングの急激な発展を遂げている2025年。
失われていく温もりあるハンドメイドコーディング。
その中でも今回は、メソッドの書き方をお伝えしたいと思います。

トーク内容(予定)
・メソッドと言えばユニットテスト
・メソッドにもあります単一責任
・同じコードは共通化(してはいけない)
・目的メソッドと手段メソッド
・メソッドを安定して繋げる

気づけば、本業ではテックリードを務め、副業では海外の開発メンバーと一緒に開発案件を回すようになっていました。
他にも、不動産会社の立ち上げ、テックカンファレンス（関数型まつり）の主催、そしてランニング（趣味で月200km以上）など、色々な活動やっています。
新卒の頃は、誤字脱字、ケアレスミスが多く、プログラミング言語仕様の意味よくわからないままなんとなく動くコードを書いておりました。
そんな自分を少しずつ変えるきっかけになったのが、2018年に始めた「人にプログラミングを教える」という講師の副業です。
教えることで自分の理解の浅さに気づき、言語化を繰り返すうちにようやく地に足のついた知識が身についていきました。
このトークでは、多動ぎみな自分がどう失敗と向き合いながらキャリアを築いてきたか、率直にお話しします。
同じような失敗をしている方へ、何か伝わると嬉しいです。

組織で成果をあげるには個々人が練度を高めることに加えてコラボレーションが不可欠です。一つには、助けを求める事やそれに応える事がその起点になります。私たちには”助け”を軸に組織の力を増幅させる力がありますが、必ずしもその使い方、使い時に気づいているわけではありません。
ところで昨今AIの台頭により助けを求める先が一部AIに置き換わりつつあるように感じます。AIは私たちをエンパワーする一方でコラボを疎にする危険性を孕んでいるのではないかとも思うのです。
助けを起点としたコラボが生まれるまでには幾つかのハードルがありそうです。例えば、助けを求めるという発想を持てるか否か、自力で解決すべきか否かの判断、支援が必要と周囲に気づかせアクションを起こしてもらうこと等です。
このトークでは、助けを求める側与える側双方の視点からハードルを見つめ直し、如何に立ち向かう事ができるのかを言語化したいと思います。