• 発表概要（400字程度）
  ドキュメント文化の中で働く中で実感したのは、「書くことは、自分をアップデートすること」だということです。
  書くという行為は、書くことと書かないことを取捨選択する、意思決定の連続です。
  つまり書くという行為を通して、過去の自分を客観視することができます。
  客観視できれば、自分の思考の癖に気づき、学びの再利用が可能になります。
  そして、考えを外に出してくれる個人が増えれば、組織の学びは加速し、アップデートのサイクルが回ります。
  書くことで自分が所属する組織（会社でもコミュニティでも）を育てることができます。
  これはキャリアのどの段階においても、極めて有効な武器になることを遅まきながら気がつけました。

• なぜこのトピックについて話したいのか
  生成AIという強力なツールがあるからこそ、この書くという行為に含まれる意思決定の価値が高まっています。
  現職でのドキュメント文化の中で磨かれた、アウトプットを通じて自分に立ち返る習慣を共有したいと思っています。

発表概要（400字程度）

ガラケーアプリ、スマホゲーム、Webアプリ、そしてプレイヤーからPM・マネージャーへ。25年のキャリアで技術もポジションも大きく変わりました。しかし振り返ると、私がやってきたことの本質は「システムを考えて実装する」であり、それは一度も変わっていません。変わったのは、具体化するときに必要な知識の領域だけでした。

ただし「CPUと人間は違う」。オブジェクト指向の最小知識の原則をチーム運営に持ち込んで組織を壊しかけたり、PM失敗やFXの大損で心が体に影響したことが、人間の心理への興味を開き、組織開発という新たな領域につながりました。

必要に迫られて知識を得る。知識を得たから新しい景色が見える。この循環を25年回し続けた結果、私は「生きのこる方法」ではなく「形が変わっていくエンジニアリングを楽しめるかどうか」が本質だと考えるに至りました。

発表詳細（1000字程度）

本セッションでは、エンジニア歴25年・47歳の私が経験した技術変遷とキャリア変化を通じて、「生きのこる」ことの本質を考えます。

1. ずっと同じことをしている

ガラケーのツールやミニゲーム開発に始まり、スマホゲーム、WebアプリのFE/BE/インフラと、扱う技術は次々に変わりました。しかし、どの時代も「システムを考えて実装する」という行為は同じでした。具体化に必要な知識領域が変わるだけで、その知識への興味は具体化しようとした時に自然と湧いてくるものでした。

2. でもCPUと人間は違った

開発リーダー、PMとキャリアが進む中で、ソフトウェア設計の原則を人間の組織にそのまま適用する過ちを犯しました。たとえばオブジェクト指向の「最小知識の原則（デメテルの法則）」をチーム間コミュニケーションに適用した結果、各チームが最小限のアウトプットだけを出す「社内外注」状態に陥り、対立が生まれました。システム思考は万能ではなく、対象が変われば「正解」も変わるという当たり前のことを、痛みをもって学びました。

3. 壊れたから見えた景色

PM時代の失敗に加え、プライベートでのFX大損という出来事が転機になりました。精神的ショックが頭痛・目眩・発汗・不眠といった身体症状として現れ、「人間の心はこんなに身体に影響するのか」と衝撃を受けました。この体験から人間の心理に強い興味が湧き、それが後に組織開発・チームビルディングへの関心につながっていきました。まさに「知識を得たから新しい景色が見えて、興味が湧く」循環の実例です。

4. 形が変わるエンジニアリングを楽しめるか

25年を振り返って思うのは、「生きのこる方法」というハウツーは存在しないということです。技術は変わる。ポジションも変わる。でも「システムを考えて実装する」という軸は変わらず、具体的な知識は必要になった時についてくる。AI時代の今もそれは同じです。「いまから、ここから」新しい知識領域に踏み出せばいい。25年間それを繰り返してきた実感があります。結局のところ、形が変わっていくエンジニアリングそのものを楽しめるかどうか。それが、この先も生きのこるための唯一の本質ではないかと考えています。

想定聴衆と得られるもの

想定聴衆: キャリアの方向性に迷っているエンジニア、技術変化やマネジメントへの転身に不安を感じている方、「自分はこの先やっていけるのか」と漠然とした不安を抱えている方。

得られるもの: 「特別な戦略がなくても生きのこれる」という安心感と、技術・ポジションが変わっても不変の軸があるという視点。また、ソフトウェア設計原則を人間組織に適用する際の具体的な落とし穴と、予期しない経験が新たなキャリアを開くという実例。

話す理由

ガラケー時代からエンジニアとして働き、プラットフォームの世代交代を複数回経験してきました。その中で技術選択やキャリアの分岐点で悩んだことも、失敗して痛い思いをしたことも多々あります。しかし振り返ると、そのすべてが「形が変わるエンジニアリングを楽しむ」という一本の線でつながっていました。この実感を、同じように不安を感じている方に共有したいと思い、応募します。

1. 発表概要（400字程度）

「一生エンジニアでいたい」と願うなら、まず現在の自分を一度捨てなければなりません。
成長することを、一皮剥けると表現をすることがありますが、エンジニアにとってもそのプロセスは必要不可欠です。過去の成功体験、積み上げたプライド、無理のきいた不健康な働き方。これらはかつて自分を守った「皮」ですが、時が経てば自分を締め付け、成長を阻む「牢獄」に変わります。
本セッションでは、フルリモートワークの開発組織でエンジニアリングマネージャーとして働く傍ら、地方でエンジニアコミュニティを主催している登壇者が、自身の「破壊と再生」のプロセスを共有します。執着を捨てる勇気と、その先に手に入れた健康・仲間・発信という新たな生存基盤。自分の中で凝り固まった古いOSを脱ぎ捨て、再び純粋な好奇心で未来を愉しむためのアップデートに必要なリブートの作法をお伝えします。

2. 発表の詳細（1000字程度）

破壊 ── 古い皮を脱ぎ捨て、窒息を防ぐ
成長に伴う痛みは、脱皮のサインです。

• 成功体験という「いかだ」を捨てる
  禅の教えに、河を渡った後にいかだを担いで歩く愚かさを説くものがあります。
  過去に評価された技術領域や「自分はこういうエンジニアだ」という自己像に、無意識にしがみついていました。
  しかしマネージャーとしての役割が増える中で、そのアイデンティティはむしろ自分を縛るものになっていました。
  プライドの破壊こそが、役割拡張の第一歩でした。身軽になることで初めて次のフェーズへ進めます。
• 不健康という負債の償還
  長時間労働や気合いによる突破は、若い頃は機能しました。
  しかしそれは未来の自分からの借金でしかありません。
  睡眠時間の固定、定期的な運動の習慣化、仕事量の意図的な制限を徹底しました。
  これは甘えではなく、長期稼働するための設計変更です。

再生 ── 新しいOSを構成する3つの基盤
破壊の後に必要なのは、持続可能な構造です。

• 物理レイヤー / 健康を基盤化する
  睡眠・食事・運動は趣味ではなく、アウトプット品質を支えるインフラです。
  エンジニア寿命は、体力寿命と連動しています。
• 社会レイヤー / 孤立を防ぐコミュニティ
  コミュニティは単なる刺激ではなく、思考の循環装置です。
  独力での生存戦略は、変化の激しい現代では通用しません。
  社内、社外に資産ともいうべきコミュニティを育てることは必要不可欠です。
• 認知レイヤー / 外形化によるメモリ解放
  ドキュメント文化の中で働く中で実感したのは、「書くことは、自分をアップデートすること」だということです。
  考えを外に出すことで、過去の自分を客観視することができます。
  自分の思考の癖に気づき、学びを再利用可能にすることができます。
  現職でのドキュメント文化の中で磨かれた、アウトプットを通じて「自分に立ち返る」習慣を提案します 。

結論 ── 空のカップに注がれる未来
すでに満たされたカップには、新しい茶は注げません。
過去の自分を破壊することは敗北ではありません。
それは「アップデート」です。
破壊と再生を繰り返すことで、エンジニアは年齢とともに劣化するのではなく、深化していきます。

3. 想定する聴衆とその人たちが得られるもの

• 30代後半〜40代で役割変化に戸惑っているエンジニア
• EMやテックリードに移行し始めた人
• これからの10年に漠然とした不安を抱えている人

4. なぜこのトピックについて話したいのか
   私は過去、自分の成功体験に固執し、新しい役割を受け入れられずに停滞した時期がありました。
   しかし、プライドを手放し、健康管理とコミュニティ参加、そして言語化習慣を意識的に取り入れたことで、エンジニアとしての楽しさを取り戻しました。
   捨てることは敗北ではないという実体験があるからこそ、このテーマを語りたいと考えています。

1. 発表概要
   技術革新が激しく、生成系AIの台頭など未来への不安やわくわくがいり混じった現代。エンジニアはどう日々、進んでいくのがよいでしょうか？そのひとつの答えとして私が思うのは、外側のトレンドではなく「自分」の内側に目を向ける、そして自分で決めて行動すること。
   本セッションでは、組み込みからWeb、そしてコーチングの経験を歩んできた私が、「自分のやりたいこと」を原動力に、主体的に進んでいくにはどうしたらよいかをお伝えします。
   自分の「やりたいことをどうみつけていくか」や、日々の葛藤、辛さや顧客・チームメンバーなど周りとどう向き合うか、そして「学び続ける」ための自然体な向き合い方について、自身の知見を交えて共有します。 エンジニアにこだわらず、自分らしい人生を歩むためのヒントを一緒にみなさんと考える時間になればうれしいです！

2. 発表の詳細
   ①導入：「自分」に矢印を向けていますか？

技術革新のスピード、生成AIの台頭、迫る納期。
私たちは常に「外側」のトレンドや正解を追いかけることに必死で、自分自身の内側に矢印を向けることを後回しにしていないでしょうか。

このセッションでは、生存戦略の起点を「自分」に置きます。
やるべきことや正解をいったん脇に置き、「自分はどうありたいのか」「何を大切にしたいのか」を考える時間にしたいと思います。

②自分に焦点をあてる：「やりたいこと」を探す

主体的に進むための原動力となるのが「やりたいこと」だと思います。
ただし、やりたいことは最初から明確にあるものではありません。探し続け、変化していくものです。だからこそ、「自分は何をやりたいのだろう」と問い続ける姿勢が大切です。

感情が高まる瞬間はありませんか。
何かに心が動いたとき、それは自分の大切な価値観に触れたサインかもしれません。ネガティブな感情も同じです。「なぜ自分は引っかかったのか」と問い直すことで、自分の輪郭が見えてきます。

また、自分にとって当たり前にできることを、他人から「すごい」と言われた経験はないでしょうか。日々自然に出ている行動や思考の中に、あなたの才能の種が眠っているかもしれません。

③周りと向き合う：葛藤の中で主体性を持つ

エンジニアの仕事は、顧客やチーム、バグやスケジュールとの葛藤の連続です。

顧客に対しては、「本当にそれが最善か」「本当に求めているものか」と自問し、ともに向かう先を考える姿勢。
チームに対しては、違和感を飲み込まず、敬意を持ちながら声に出す勇気。
障害が起きたときは、まず影響を最小限にし、その後チームで根本原因を探る姿勢。
予定通りに進まないスケジュールの中でも、どう行動を選ぶのか。

葛藤の中でこそ、自分の在り方が問われます。

④学び続ける：自然体で積み重ねる

最後に「学び」についてお話しします。
あなたにとって学びとは何でしょうか。会社に求められるから学ぶのか、自分の興味から学ぶのか。迷いながらでも、「これをやってみたいかも」と思える方向に一歩踏み出すことが、未来の自分への贈り物になります。

これを学べば一生安泰、という時代ではありません。
だからこそ、1日1日の小さな積み重ねが、いつか点と点をつなぎます。

そして、共に学ぶ仲間やコミュニティの存在。
何かをインプットし続けている状態そのものが、「この先もきっと大丈夫」という静かな安心感につながるのだと、私は感じています。

本セッションが、自分らしいエンジニア人生を考えるきっかけになれば幸いです。

3. 想定する聴衆とその人たちが得られるもの
   技術の変化やAIの進化に刺激や不安を感じながらも、「このままでいいのか？」と自分のキャリアや在り方を考え始めているエンジニア。
   AI時代に振り回されないための「自分の軸」を見つめ直す時間になります。やりたいことの探し方、日々の葛藤との向き合い方、学びを積み重ねる考え方を持ち帰れます。

4. なぜこのトピックについて話したいのか
   私はこれまで約20年、組み込み、メインフレーム、パッケージ、Web開発など、いろいろな現場を経験しました。ずっと「自分のやりたいこと」を軸に選んできましたが、正直、きれいなキャリアではありません。

そんな中で、コーチング、クリフトンストレングスやコンパッションの考え方、そしてコミュニティとのつながりに救われました。もしそれがなかったら・・・

今感じているのは、「自分を知ること」は技術力と同じくらい、いやそれ以上に強い“生存戦略”になるということです。

エンジニアは、可能性のある職業だと思っています。だからこそ、これまでの失敗や葛藤も含めて共有し、自分らしい未来を描くきっかけを届けたいと思い、このテーマでお話しします。

私は時々、自分が何者かわからなくなります。
役割が揺れたとき、肩書きが変わりそうになったとき、私は焦って「自分とは何か」を言葉で固定しようとします。でも、人は変わります。完成形の思想を持とうとすると、変化に耐えられなくなる。
そんな私が本当に怖かったのは「何者でもないこと」ではなく、「思考を省略されること」だと気づきました。
人が考える存在として扱われない瞬間に、私は怒り、その奥で悲しみを感じ、やがてその場から離れてしまうことを感じています。

そこで始めたのが「役割を外す」再定義ワークです。
肩書きをすべて外し、それでも残る“態度”を探すことです。
私の場合、それは「人の思考を省略しない」という態度でした。

安心とは、揺れないことではなく、揺れても再定義できる自分への信頼ではないだろうかと考えました。
このLTでは、何者かわからなくなったときの自己再設計の方法を共有します。

もし同じように揺れている人がいたら、一緒に探せたらうれしいです。

1. 発表概要
   「AIに仕事を奪われるのでは？」と不安を抱えるすべてのエンジニアへ。
   私は23年間、いわゆる「凄腕のエンジニア」ではありません。大企業のSEとして様々な調整に追われ、属人化を防ぎ「いつでも引き継げるように（自分を守るために）」と仕様書を書き、オフショア開発で「曖昧さをなくす指示」を出し続けてきました。

しかしLLM時代が到来した今、その「守りの技術」がAIコーディングツールを操る最強の武器へと一変しました。コーディングの実務経験が浅くても、的確な仕様化能力さえあれば、片手間の2週間で一人でプロダクトのプロトタイプを作り上げられる時代になったのです。

本セッションでは、キャリアの荒波を「半分信じて、半分疑う」精神でサバイブしてきた私が、旧来のSEスキルがAI時代にどう輝くのか、そして組織的バグを見極めて「戦略的に逃げる（損切りする）」ためのマインドシフトの極意をお話しします。

2. 発表の詳細
   エンジニアのキャリアは、決してきれいごとだけでは進みません。「10年後も生き残れるか？」という不安に対する私の答えは、「波に乗り、不要な抱え込みを防ぎ、過去の遺産を思わぬ形で再利用する」という泥臭いサバイバル術です。

本セッションでは、以下の3つのテーマを軸に、明日から使える「生き残り方」をお伝えします。

① 「守りのドキュメント」が「最強のプロンプト」に変わるパラダイムシフト
私は長年、オフショア開発（中国、インド、ベトナム）のマネジメントや、属人化を防ぐため（＝いつでも自分が引き継げる状態にして身を守るため）の仕様書作成に注力してきました。
しかし、LLM時代において「曖昧さを排除し、簡潔に仕様を定義する力」は、AIに精緻なコードを書かせるためのプロンプト技術へと昇華しました。自分自身で2週間でフルスタックのプロトタイプを完成させるに至った実践例を通し、これまでの「レガシー」と思われがちなSEのスキルがいかに大きな価値（攻めの武器）を持つかを示します。

② 組織の「構造的バグ」から速やかに離れる嗅覚
システム障害による徹夜対応よりも一番辛いのは、「組織構造や契約関係に起因する問題」です。
「ミーティングや承認ばかりで前へ進まない」「マネージャーが『君に期待する役割だよ』と丸投げする」「熱意よりも政治的理由で決まる」。これらは自分がどれだけ頑張っても解決できない「組織的バグ」のサインです。自分を守るためには、このサインをどう察知し、いかに速やかに「離れる（損切りする）」か。その明確な判断基準をお話しします。

③ Slackの「お辞儀」を「いいね！」に変えるマインドセット
元々は変化を嫌う性格でしたが、多国籍環境への転職で「英語」の持つ前向きなコミュニケーションに影響を受けました。日本のビジネスチャットで多用される「お辞儀」アイコンの同調圧力から抜け出し、ポジティブに「いいね！」と変化を受け入れるマインド。「半分信じて半分疑う（常にPlan Bを持つ）」というスタンスを持つことで、予期せぬ技術の波を「ピンチ」ではなく「チャンス」として乗りこなす方法を共有します。

3. 想定する聴衆とその人たちが得られるもの
   【想定する聴衆】
   • 凄腕プログラマーではないことにコンプレックスやキャリアの不安を感じている中堅エンジニア
   • 現場の理不尽な人間関係や「組織的バグ」に疲弊し、辞めるべきか悩んでいる若手エンジニア
   • AIの進化に対して「自分のこれまでのスキルがどう活かせるか」を探している方

【得られるもの】

• 自分がこれまで培ってきた「仕様化」「ドキュメント化」のスキルが、AI時代にいかに強力な武器になるかという自信と気づき。
• 自分が抱え込むべき技術的課題と、速やかに「離れるべき」問題（組織的欠陥）を切り分けるための客観的な視点。
• 変化を恐れず、「Plan B」を持ちながら新しい波を面白がるための実践的なマインドセット。

4. なぜあなたがこのトピックについて話すのか
   2003年のSE入社から、大規模Webサービスの立ち上げ・運用での経験、グローバルなアパレル企業での多国籍チームでのエンジニア、そして現在のデータベンチャーでのPdMと生成AI案件リードに至るまで、約23年間にわたり「技術の変遷」と「組織の形」の変化の最前線でサバイブし続けてきたからです。
   私は決して天才肌のエンジニアではありません。だからこそ、絶え間ないキャッチアップと、「属人化を防ぐ守りのドキュメント化」「組織のバグからの回避」といった生存術を磨いてきました。未来に不安を抱える多くのエンジニアにとって、リアルで再現性のある「明日からの道標」になると確信しています。

①発表概要（400字程度）

私は組み込みソフトウェアエンジニアからAndroidアプリエンジニアにキャリアチェンジしました。プロダクトの「価値の提供方法」が、発売して終わりのハードウェアから、継続的なアップデートが前提のソフトウェアへと、時代とともに変化したからです。
組み込みソフトウェアとAndroidアプリはまったく異なる技術領域に見えるかもしれません。しかし、私がエンジニアとしてこだわりを持って取り組んできたことを振り返り、抽象化して共通点を探してみると、エンジニアとしての自分の「好き」なことが見えてきました。そして、この先も好きなことに取り組んでいけると思えるようになりました。
このセッションでは、プロダクトの価値の提供方法に焦点を当て、その変化に追従するために自分の「好き」を抽象化するステップを話します。そして、次の変化を見据えて、自分がどこで価値を出せるかを考えるためのヒントを提供します。

②発表の詳細（1000字程度）

私は以前、組み込みソフトウェアエンジニアとして音響機器のファームウェアを開発していました。ICのレジスタをたたいて思い通りにハードウェアを動かし、使いやすい製品を作ることに情熱を注いでいました。
エンジニアのキャリアを開始した当初は、まだハードウェアが価値の中心で、開発のゴールはリリースしてユーザーに買ってもらうことでした。
しかし価値の中心がWebやモバイルのソフトウェアに移動し、リリースはゴールではなくスタートになりました。ユーザーに価値を提供するために、ソフトウェアを継続的にアップデートすることが当たり前になりました。

そんな時代の変化に追従するため、私はAndroidアプリエンジニアにキャリアチェンジしました。
UIの開発が好きで、現在は本業のアプリ開発に加えて、OSSのUIライブラリを開発したり、UI開発に関する技術書を執筆したりしています。

しかし今また時代が変化しようとしています。AIが発展した5年後、10年後にAndroidエンジニアの仕事は存在しているでしょうか。人間用のUIの重要性が下がって、私の好きなUI開発の仕事も無くなってしまうのでしょうか？
そんな不安を乗り越えるために、これまでの世の中の変化と自分のキャリアを振り返り、これから起こる変化に向き合う戦略を立てました。

その時代にあった形で価値を提供し続けられる状態で居続ける

• 以前はできるだけ品質の高い状態で完成させてリリースすることが重要だった
• 現在はアジャイルな開発が主流で、継続的なアップデートで価値を届けることが重視されている
• 今後はますます開発サイクルが早くなり、1つ1つの機能やUIを作り込むのではなく、AIを前提とした価値提供に移行していく

自分の好きを抽象化する

• これまでのキャリアで情熱を持って取り組んだこと、大切にしていたこと、意思決定を振り返る
• 共通点を探し、自分の「好き」や「得意」の抽象度を上げる

エンジニアに求められるスキルは、時代とともに抽象度が上がっていきます。それにあわせて、自分の「好き」の抽象度も上げていくことで、この先も自分が熱意を持って取り組める領域を見つけることができると考えています。みなさんも自分のこれまでの歩みを振り返り、自分の好きを抽象化して今後の武器に変えてみませんか？

③想定する聴衆とその人たちが得られるもの

想定する聴衆

• 変化が激しい環境の中で自分の仕事の価値がなくなってしまうのではないかと不安を感じている方
• 自分の好きな仕事をAIに取られてしまうことに対して寂しさを感じている方

得られるもの

• エンジニア個人や組織として価値を提供し続けるための視点
• エンジニアとしての自身の軸をみつけるきっかけ

④なぜあなたがこのトピックについて話すのか

私は自分自身のキャリアの中で、世の中に価値を提供できていないのではないか、このままエンジニアとして終わってしまうのではないかと悩んでいた期間がありました。試行錯誤の結果としてキャリアチェンジを実現し、いまはエンジニアとして充実した活動ができています。一度苦しみ、乗り越えた経験があるからこそ見つけることができた、私ならではの生きのこり戦略を共有できると考えています。

1. 発表概要

キャリアの節目にはいつも「信頼している人」がいました。憧れの人がいる会社に飛び込み、コミュニティで信頼する先輩の姿に惹かれて転職し、「あなたがやるべき」という提案を受けてマネジメントの道へ。どれも自分で計画したものではありません。
いま44歳。生成AIの台頭をはじめ、これまでとはまったく違うレベルの変化がエンジニアの世界に起きています。私自身、組織全体をAIエージェントと協働できる状態にする「Agent Ready」という構想に取り組んでいる最中です。40歳で技術責任者を引き受けたときは不安が8割でしたが、いまも変化の渦中にいます。
このトークでは、変化の激しい時代の中で「信頼している人の提案に乗る」ことでキャリアを切り拓いてきた経験と、いまその渦中で考えていることをお話しします。

2. 発表の詳細

まず、私のキャリアの転機をふりかえります。学生時代に憧れた人がいる会社に入り、Rubyとアジャイルのコミュニティでたくさんのよい出会いがありました。その中で信頼する方々が楽しそうに働いている姿を見てGMOペパボに転職、マネジメント職への抜擢、40歳での技術責任者就任と、いずれも信頼している人からの提案がきっかけでした。

次に、「信頼できる人にどう出会うのか」について話します。これは運ではなく、再現可能なプロセスだと考えています。コミュニティに出ることで相手のアウトプットや考え方を先に知れること。同じ現場で日常の判断の積み重ねを観察する中で信頼が醸成されること。そして自分自身がアウトプットし責任を引き受けることで、今度は自分に提案が届く側になること。この3つの循環が信頼の基盤になっています。

そして、いまの挑戦について話します。生成AIの台頭によって、エンジニアの働き方そのものが問い直されています。私自身、2023年から全社での生成AI活用を推進し、2026年のいまは「Agent Ready」——組織全体がAIエージェントと協働できる状態への転換に取り組んでいます。44歳になったいまも、信頼する人たちとの対話の中から生まれた新しい提案に乗り続けています。

最後に、これらの経験を踏まえて「流れに乗るための準備」を整理します。外に出ること、観察すること、信頼される側になること、そして提案が来たら不安でもまず乗ってみること。計画通りにいかないキャリアの中でも、この循環を回し続けることが「いまから、ここから」未来をつくる方法だと伝えます。

3. 想定する聴衆とその人たちが得られるもの

キャリアの方向性に漠然とした不安を持つ20代〜30代のエンジニアを主な対象としています。「何を学ぶべきか」「次にどこへ行くべきか」を自分で計画しなければならないというプレッシャーを感じている方に、計画とは違うキャリアの作り方があることを知ってもらえます。また、信頼できる人との関係をどう築くかという具体的な行動指針を持ち帰れます。

4. なぜこのトピックについて話したいのか

受託開発を生業としている企業からWeb系への転職、ICからマネジメントへの転向、組織の責任者へ、そしていまAgent Readyという新たな組織変革への挑戦。すべてが信頼する人の提案から始まりました。計画的にキャリアを設計したのではなく、信頼の循環に乗り続けた結果としていまここにいます。この「流れに乗る」というアプローチを、まさにいま実践し続けている当事者として話したいと考えています。

発表概要

私はいわゆるスペシャリストと呼ばれるタイプでも、最新の技術を即座にキャッチアップするアーリーアダプターのようなタイプでもありません。
むしろ、自分はなぜこんなに出来ないのだろうと感じ続けてきたエンジニアです。

そういった卑下はありつつ不思議なもので、40歳を迎えた現在でもプレイングマネージャーとして仕事はいただけてる状態でなんとか生きのこっています。

そんなどこにでもいる私がなぜ生きのこれているのかを考えてみると、常々ギリギリのタイミングではあったかなと思うのですが、
「このままではヤバい」となんとか動いてもがいてサバイブしてきたということに気づきました。

明確なキャリアプランがあったわけではありません。
業界の変化、働き方の限界、自身の成長停滞。
そのたびにギリギリで方向転換し、ジタバタしながら生き延びてきました。

本発表では、計画的なキャリア設計ではなく、危機を検知し、致命傷になる前に動いてきた私の嗅覚と行動パターンを共有します。

同じように焦りながらも動けずにいる方に、
「ギリギリでも動けば生きのこれる」という一つの選択肢を届けられればと思います。

発表の詳細

中学校不登校でヤバい

中学校は不登校、卒業してからフリーター。
そんな自分が同世代の子たちをみて、何を思い高校にいきなおし社会人になるに至ったのか。

ゲーム業界不況でヤバい

晴れて就職。小さいころから好きだったTVゲームという憧れの業界でプログラマ。
しかし時は2009年。前年末にはリーマンショックという大事件。
毎月見せられたキャッシュフロー。
コンシューマゲームの売上が不調な中、自分はどう行動していたのか。

メンタルがヤバい（第一回）

世はスマートフォン向けソーシャルゲーム時代。
弊社でも開発。誰もやったことないサーバーサイド。
作りが悪く、負荷集中。
メンタル崩壊からの初転職。

身内の金銭トラブルでヤバい

予想外の方向からの金銭トラブル巻き込み案件。
銭を失う恐怖。自身の価値観、キャリアに大きく影響を与えた大事件。

子供と仕事のデスマーチでメンタルもヤバい（第二回）

事件も落ち着き、バックエンドもだいぶ板についてきた。
いよいよ誕生、第一子。
そんな中プロジェクトは絶賛デスマーチ。
子が起きる前に出勤、帰ったら寝てる、そんな日々。
そうこうしてればコロナの緊急事態宣言。働き方も大変化。
カウンセリングで身につけたメンタルのオブザーバビリティ。
ストレッサーでログをとって自分を修復。
メタ認知も向上して、いざ自分を救う大転職。

まわりみんな活躍しててヤバい

転職1年半、そろそろ活躍しないとね。
社内賞発表。自分の名前はナッシング。
はてさて30代も後半、このままの自分はどうなるのか。
焦りから始まる、自分磨きのアウトプット大促進時代

管理職経験ないとヤバい

もうすぐ40も見えてきた。
観測範囲の近しい年齢の人はみーんな管理職やってる。
やってないのお前だけ。
どうする、どうするよオレ。

（これから）AIかしこすぎてヤバい

来年自分の仕事は果たしてあるのか！？
ヤバすぎる進化のスピードに振り落とされないために、何する？どうする？

想定する聴衆とその人たちが得られるもの

想定する聴衆

• 焦りを感じてる人
• 不安で動けない人
• メンタル壊しかけてる人
• 「自分は大したことない」と思ってる人

得られること

• 「壊れる前」に気づくためのセルフモニタリング術
• 不安を“ログ化”して客観視する方法
• アウトプットを続けることの効力
• 成長型マインドセットへの思考転換

なぜあなたがこのトピックについて話すのか

昔の自分を救いたいんじゃないかなと思います。
色々躓いてなんとか生きてるんですが、やはりだいぶ遠回りをしてきたなと感じる部分も非常に多いです。
ギリギリでも生きてはこれてきましたが、早いにこしたことはないと思う場面も多々あります。
自分と同じような苦しみは出来れば避けて、人生の幸福な時間の密度を少しでも高める一助にならないかなという気持ちです。

1. 発表概要

この一年で、エージェントがさらに多くのコードを書くようになり、その割合はGitHub Copilot Statisticsによると50％近くになりました。当然の流れかもしれませんが「エンジニアがこの先生きのこるためにどうしたらいいか」の議論はさらに加速しているように見えます。

この状況だからこそ、私は「生き残ることを考えることに意味はない」と言い切ります。我々が憧れるような世の中を変えてきた技術はすべからく、「自身が生き残れるかどうか」とは真逆の観点から生まれてきました。それゆえになおさらエンジニアリングにはワクワクさせられるし、より知的に深く探求したくなるというものです。

生存戦略を語る気はさらさら無く、カンファレンスそのものを真っ向から否定するような内容を投げかけますが、この発表によりむしろカンファレンスの視座を一段引き上げることができ、参加者の認知資源配分の最適化に一役買えるはずです。

2. 発表の詳細

「エンジニアが生き残る」というコンテキストの中にはいくつかの問いが含まれています。

• まずは「生き残らないといけない」という暗黙の前提、それは本当でしょうか？
• そもそも「この市場が淘汰的である」というのも事実でしょうか？
• また仮に、生き残るという状態が存在するとして、生き残りを考えること自体が長期的には競争の罠を強化していないか？
• 「自分が生き残る」ということは「自分以外の誰かが生き残らない」ことを意味しないか？

既にお気づきかと思いますが、我々エンジニアが普段とても嫌っている、サイロ思考や局所最適、視野狭窄の影が見えます。もしかすると生存を脅かされることで、これらの罠に嵌ってしまっているのかもしれません。エンジニアリングからの微妙な逸脱の始まりです。
気づいたら、他者を競争相手と見なし、短期的に有利そうなスキルへ飛びつき、価値創造への集中力を失っている。技術は好奇心の対象ではなくなっている。

長い人類史を見ればわかるように、生存のための行動は短期適応であり、その勢力に抗ってコトを成し遂げてきた人が科学者であり、技術者でした。いま話している「エンジニアとして生き残ること」はどっちを指すのでしょうか？

問題を構造化し、制約の中でよりよい解を探り、他者と協働しながら価値を実装していく営みがエンジニアリングです。未来のポジションに不安を感じるのなら、むしろその不安をもたらす課題を深く理解し、より良い構造を作ろうとする行為に向かえばよいのではないか。 なんなら、ひょっとすると、そんな問題は最初から存在せず、虚構により防衛本能を刺激され、それによる心理的揺さぶりを利用されているだけかもしれません。少なくともエンジニアは怯えながらやるもんじゃない。楽しく課題解決をできるから続けてきてるんじゃなかったっけ？

本セッションでは、不安や恐怖に駆動されるキャリア思考がもたらす副作用を整理し、エンジニアリングの本質に立ち戻る視点を提示します。また昨今の「エンジニアはビジネスについて考えるべき」論への全肯定傾向にも警鐘を鳴らします。その後、最初の問いに立ち返っていくことで、聴いた方たちの霧が晴れていくことを目的としています。

3. 想定する聴衆

• AI時代のキャリアに不安を感じているエンジニア
• 「何を学べば安全か」を探し続けている人
• 生存論に違和感を持ちつつ言語化できていない人
• 組織の中でメンバーの不安に向き合っているリーダー層

  その人たちが得られるもの

• 生存戦略というフレームを相対化する思考
• エンジニアリングの本質に立ち戻る言語

4. なぜこのトピックについて話したいのか

私が大学でソフトウェア工学を学んでいた頃や、エンジニアとして仕事を始めた頃と比べると、確実にソフトウェアエンジニアの裾野は広がっていると感じます。そして、ソフトウェアエンジニアの絶対数が増えることは社会にとって有益であり、多くの可能性を秘めているという確信があります。それなのに、先を見ずに、足元のことばかり気にしている論調に身悶えしています。

もちろん人間には損失回避バイアスがあるので、どうしても不安に目がいきがちになるところはある。しかし、それを逆手にとってエンジニアの不安を無闇矢鱈に煽ることで自分たちの利益に転換するような喧伝に対しては真っ向から斬りあいたい。

1. 発表概要

転職とはキャリアアップである。
少なくとも、そう説明されることが多い。
エンジニアの世界では、「上に行く」ことが成長の証として語られてきた。

シニア、スタッフ、プリンシパル、そしてCTO。
しかしキャリアを重ねるにつれて、誰もがどこかで限界や天井の感覚と向き合うことになる。

それは本当に能力の問題なのだろうか。
努力で越えられる壁なのだろうか。
あるいは、運・機会・タイミングという別の要素なのか。

本セッションでは、転職活動を通じて見えてきた市場評価と自己評価のズレ、肩書きと実態の乖離、そして人生100年時代におけるキャリア観の誤解を軸に、
「諦め」を敗北ではなく再定義の契機として捉え、
「成熟」という別の視点からキャリアを問い直す。

2. 発表の詳細

多くのエンジニアは、キャリアを階段のように捉えがちです。経験を積み、スキルを磨き、より上位のポジションへ到達する。その延長線上にCTOやVPoEといった役職がある──少なくとも、そう説明されることが多い。この構図はあまりにも自然に共有され、疑う機会が少ないまま、私たちのキャリア観の土台になってきました。

しかし、転職市場や組織の現実は、その物語をいつも綺麗には支持しません。役職や評価は能力だけで決まるものではなく、企業のフェーズ、期待される役割、偶発的な機会、そしてタイミングに左右されます。努力は重要ですが、努力だけで同じ到達点に辿り着けるわけではありません。この不確実性は、スポーツ選手やアーティストのキャリアにも似ています。実力だけでは語れない要素が、確かに存在します。

さらに「人生100年時代」という言葉が、この幻想を静かに補強しているようにも見えます。就労期間が伸びる可能性はあっても、キャリアサイクルそのものが同じ割合で延長されるわけではありません。出世トラックの時間構造や、リーダー職に求められる適合条件が劇的に変わるわけでもない。むしろ伸びているのは、キャリアの“後”なのかもしれません。

そして自分を含め多くの人は、必ずしもトップになれないと悟った時に、どのように振る舞うべきなのかという問いと向き合うことになります。

「なれなかった自分」は失敗なのでしょうか。本セッションでは、市場評価と自己評価のズレ、能力神話の解体、肩書きと実態の乖離といった構造を丁寧に分解しながら、「諦め」を敗北ではなく再定義の契機として捉え直します。そして「成熟」という別のキャリアモデル──上昇の物語ではなく、役割と価値を更新していく物語──を提示します。

本セッションは成功論ではありません。むしろキャリアに潜む暗黙の前提をほどき、自分自身の評価軸を再設計するための思考材料を共有する試みです。

3. 想定する聴衆とその人たちが得られるもの

想定する聴衆

・30代以降のエンジニア
・キャリアの方向性や成長の定義に迷いを感じている人
・転職、評価、役職に対して葛藤や違和感を抱えている人
・キャリアアップという言葉に、うっすら疑問を持ち始めた人
・「このままでよいのか？」という感覚をどこかで経験した人

聴衆が得られるもの

・キャリアラダーや「上昇モデル」を相対化する視点
・市場評価と自己評価がズレる構造の理解
・能力だけでは語れないキャリア要因（役割適合・運・タイミング）の認識
・限界や天井意識と向き合うための思考フレーム
・「諦め」を敗北ではなく再定義として捉える視点
・「成熟」という別のキャリアモデルへの気づき

4. なぜこのトピックについて話したいのか

私はキャリアの後半に差し掛かってから転職を経験し、その過程で自己評価と市場評価のズレ、期待される役割と実際の評価の不一致と向き合ってきました。技術的実績やマネジメント経験があっても、それだけでは説明しきれない評価構造の存在を実感しています。また「限界」や「天井」といった感覚は、特定の世代だけの問題ではなく、多くのエンジニアがいずれ直面し得る普遍的なテーマでもあります。本発表は個人的な経験を出発点としながら、キャリアに潜む構造的な前提や暗黙の物語を言語化する試みです。キャリアを上昇の物語だけで語らないための視点を共有したいと考えています。

地方で勉強会を立ち上げて調子よく見えていても、気が付くと運営メンバーが減っている事はありませんか？
また、勉強会の段取りは上手になっていくのに参加者が減っていくこともありませんか？

これら現象を「そういうもの」として最初から前提に組み込んでしまえば、運営者として取りうる選択肢は逆に増えるかもしれません。

北海道でVR・ARの技術者コミュニティを始め、初期の運営メンバーを自分以外全員転職で失いながらも細々と活動を続け、
8年間全国各地のコミュニティ活動を支えてきました。

運営者としての負荷を大きくしないために、色々なものを溜め込まないという姿勢で気楽に続ける体制を構築するとよいでしょう。
北海道の一例として、「あらゆる機会をおすそ分け」することで、外部コミュニティと物事を共有して仲間を作り、
イベントコストを下げながら運営者同士のネットワークを作りました。

講演では、運営者・講演者・参加者の視点それぞれでできるおすそ分けについて整理してみたいと思います。

【なぜこのトピックについて話したいのか】
新型コロナウイルスの感染拡大が緩やかになった事で地方カンファレンスがワッと増えました。
各地のいろいろな技術領域で盛り上がりが感じられ、いい事のように思います。
半面、運営者の役割を持った方が地元の複数カンファレンスの掛け持ちをしている構造が見受けられ、個人個人が疲れて燃え尽きる未来もうっすらと見え始めています。
去ってしまった運営者は多くの場合戻ってきませんので、運営に関わる作業が苦にならないようなトリックを文化に組み込むとよいのではないかと考えます。
このような背景から、参加者が出来る運営協力を意識づけてもらえるようなテーマを選んでみました。
（とかっこよく書いてはみたものの、「Xの表示アルゴリズムの変更のせいでイベント告知が本来の参加者にぜーんぜん届いてない助けて～」という気持ちも含まれています）

エンジニアとして積み重ねてきた豊富な経験やノウハウを、ただ自分の中に留めておくのはもったいない。せっかく培った知識を、次世代のエンジニアやコミュニティに還元する手段の一つとして、技術同人誌を書いてみませんか？
技術同人誌は、通常の商業出版とは違い、自由な形式とペースで執筆できるのが大きな特徴です。あなたが本当に伝えたいことを形にできるのです。技術同人誌は、自分が書きたい内容を自由に表現できるのが最大のメリットです。特定の技術について深く掘り下げたり、自分自身の専門分野や経験にフォーカスすることも可能です。こういった知見は、シニアエンジニアとして次世代に伝えるべきものでしょう。
さらに、技術同人誌を書くことで、知識の共有のみならず、自分自身のプレゼンスを高める手段にもなります。技術同人誌を発表する機会は多く存在します。新しい技術コミュニティやコネクション、フィードバックを得てみませんか？
恩送りという観点もありますね！レッツアウトプット！

①発表概要（400字程度）
AIがコードを書く時代になりました。若手開発者がAIと組んで驚くほど速くソフトウェアを作れるようになった一方で、「速く作れること」と「正しいものを作れること」は別の能力です。

私はアジャイルに20年近く向き合い続けてきました。バリバリの実践者というよりは、長期プロジェクトの支援や研修の企画・運営を通じて、多くの実践者の言葉を鍋に入れてきた側です。いつしかエンジニアとしてコードを書くことは諦めていました。ところが生成AIと出会い、「AIと一緒ならもう一度エンジニアを目指せるかもしれない」とドタバタし始めた結果、AIの出力を鵜呑みにして品質を失い、逆に力みすぎて目的を見失う、という両方の失敗を経験しました。
その試行錯誤の中で気づいたのは、歩幅の調節、探究、対話、技術的卓越、規律と自由──私がアジャイルから学んできたことが、AI時代にもそのまま効くということです。

本セッションでは、20年分の鍋の中身がAI時代にどう繋がったかを語り、若手開発者の育成研修コンセプトとして言語化した過程を共有します。先輩世代の経験が、これからの開発者にどう届きうるかを一緒に考えたいです。

▪️話すこと
まず自分のことを話します。研修の企画・運営やプロジェクト支援が中心になり、いつの間にかコードを書くことを諦めていました。ところが生成AIと出会い、「これなら自分にもまたコードが書けるかもしれない」と歩き始めました。AIに任せたら「すごい、でも自分が何をしたのか分からない」。制御しようとしすぎて手段と目的が入れ替わる。諦めていた人間が再挑戦したからこその、素直な失敗を共有します。

次に、その失敗から見えてきた「AI時代に開発者が担う3つの役割」を紹介します。何を作るべきかを宣言する「始める」、成果物に責任を持つ「引き受ける」、AIが安全に動ける開発基盤を育て続ける「整える」。AIは「作る」を担えるようになったが、この3つは人間の仕事であるという考え方です。
そして、この3つの役割を支える5つの能力──探究・対話・技術的卓越・規律・自由──がアジャイルの実践知とどう繋がっているかを示します。

話すこと
まず自分自身の話から始めます。研修の企画・運営やプロジェクト支援が中心になり、いつの間にかコードを書くことを諦めていました。ところが生成AIと出会い、「これなら自分にもまたコードが書けるかもしれない」と歩き始めました。AIに任せたら「すごい、でも自分が何をしたのか分からない」。制御しようとしすぎて手段と目的が入れ替わる。諦めていた人間が再挑戦したからこその、素直な失敗を共有します。

次に、その失敗から見えてきた「AI時代に開発者が担う3つの役割」を紹介します。何を作るべきかを宣言する「始める」、成果物に責任を持つ「引き受ける」、AIが安全に動ける開発基盤を育て続ける「整える」。AIは「作る」を担えるようになったが、この3つは人間の仕事であるという考え方です。
そして、この3つの役割を支える5つの能力──探究・対話・技術的卓越・規律・自由──がアジャイルの実践知とどう繋がっているかを示します。歩幅の調節はTDDから、帽子のかぶり分けはKent Beckから、「はやめに・こまめに」は角谷信太郎氏から、伴走と委託は和田卓人氏から。プロジェクト支援や研修運営の中で間近に見た判断や言葉も含めて、20年かけて鍋に入れてきたものが、「AIとの協働で人間がすべきこと」を考えた時にひとつにまとまりました。

最後に、これを若手育成の研修コンセプトとしてまとめた経緯を共有します。

話さないこと
∙特定のAIツールの使い方やプロンプトエンジニアリングのテクニック
∙AI技術そのものの解説
∙完成した研修プログラムの紹介

③想定する聴衆とその人たちが得られるもの
想定する聴衆
∙コードを書くことから離れ、エンジニアとしての自分を諦めかけているベテラン
∙AI時代に自分のスキルや経験がどう活きるのか不安を感じているエンジニア
∙若手にAIとの付き合い方をどう教えればいいか悩んでいるリーダー・マネージャー

得られるもの
∙「アジャイル実践者たちの知見はAI時代にも有効である」という実感と具体的な接続点
∙「諦めかけていたけど、まだやれるかもしれない」という前向きな気持ち

④なぜあなたがこのトピックについて話すのか
歳をとり次に渡すことができるものはなんだろうと考えた時、偉大な習慣を身につけた開発者、あの姿ではないかと思いました。開発者不要という話題も出てくる中で不安を持つ同世代の方や、これからAIと歩見続ける若い世代の方と、この先も開発者として続けていくためにどうすれば良いか、一緒に考えることができればと思います。

①発表概要

所属する会社の口座残高が800円になったことがありますか？　私はあります。

大学卒業後、満を持して起業したものの、創業わずか半年で会社の口座残高が800円という危機に陥りました。エンジニアとして歩んできた道のりはそんな困難の連続でした。それでも生きのこれた理由をお話しします。ひとつの仕事や収入源に依存しない構造が、どん底の局面での生命線になったのです。

「生き残る」とは、技術を磨くことだけではありません。スキルの掛け合わせがエンジニアの生存確率を上げることにつながります。あなたの「第2の柱」は何ですか？

②なぜあなたがこのトピックについて話すのか

修羅場をくぐり抜けてきた当事者として、きれいごとではない生存戦略を、同じ道を歩むエンジニアたちと共有したいと思っています。

発表概要

IT業界では、数年前の常識があっという間に時代遅れになります。「周囲の会話についていけない」「情報収集はしているのに活かせていない」、こういった状況を放置した先は、エンジニアとしての静かな"詰み"が待っています。

そのような未来を避けるためには、継続的に最新の技術情報をキャッチアップし続けるしかありません。キャッチアップは単なる情報収集にとどまらない、エンジニアとして長くキャリアを続けるための生存戦略です。信頼できる情報を集め、整理し、自分のものとして吸収していかなければなりません。そこに必要なのは努力や気合ではなく、日常的に続けることができる確かな「仕組み」です。

本セッションでは、IT業界で25年以上にわたって技術ライターとして最新情報の発信を続けてきた経験をもとに、エンジニアが変化の波に乗り続けるためのキャッチアップ戦略をお伝えします。

発表の詳細

IT業界の変化のスピードは、他の業界と比べても際立っています。この10数年だけでも、クラウド、コンテナ技術、サーバーレス、ローコード／ノーコード、そして生成AIと、次々と新しい技術が登場し、そのたびに「知らないと乗り遅れる」というプレッシャーを感じてきたエンジニアは多いはずです。

しかし、すべての技術を完璧に追い続けることは現実的ではありません。大切なのは、必要な情報を効率よく取り入れ、学び続ける仕組みを自分の中に作ることです。セッションでは、私自身が長年実践してきたキャッチアップ術を、インプット／フィルタリング／アウトプットの3つのステップに整理して紹介します。

• インプット: 情報源の種類と特性を整理しながら、信頼できる情報源をどう見極めるかを取り上げます。
• フィルタリング: 膨大な情報の中から自分に必要なものを選ぶ考え方を取り上げます。
• アウトプット: 学んだことをアウトプットすることで、自分の血肉として定着させることを目指します。

さて、情報のキャッチアップを続ける上でAIはどのような位置付けになるでしょうか。上記の3ステップを実践する上でAIは非常に強力な武器になります。知らない技術の概要を素早く把握したり、情報を整理する補助ツールとして活用することで、キャッチアップの効率は大きく上がります。

しかし見方を変えれば、キャッチアップ術を持つことこそが、実はAIを効果的に活用する上で大きなアドバンテージにもなるのです。「何が自分に必要か」「この情報が信頼できるか」を判断する軸は、日頃からキャッチアップを続けてきたエンジニア自身の中にしか育ちません。「どうせAIが教えてくれる」という姿勢に潜むリスクについても考えるべきポイントです。

セッションでは自分なりのキャッチアップ術を構築するポイントに加えて、キャッチアップがうまく続けられないケースやその対策などについてもお話しします。継続のための仕組みをどう作るか、そのヒントを持ち帰っていただきたいと思います。

想定する聴衆

• 技術トレンドの多さに圧倒され、何から手をつければよいかわからなくなっているエンジニア
• 情報収集は続けているのに、知識がうまく活かせていないと感じている方
• 「わからないことはAIに聞けばいい」と思い込んでしまっている方
• 中長期のキャリアを見据えて、学び続ける習慣を整えたいと思っている方

聴衆が得られるもの

• 長期間継続できるキャッチアップ術の実践イメージ
• 情報の見極め方、整理の仕方など、今日から使えるノウハウ
• 努力や気合に頼らない、「仕組みで続ける」という考え方の転換

なぜあなたがこのトピックについて話すのか

カンファレンスの場や日常的なコミュニティ活動を通じて、多くのエンジニアとも言葉を交わす中で繰り返し耳にするのが、「技術の進化が速すぎてついていけない」「何を学べばいいかわからなくなってきた」といった声です。こうした悩みは、キャリアの浅いエンジニアだけでなく、10年以上の経験を持つベテランからも聞かれます。技術のキャッチアップに対する不安は、エンジニアのキャリアのあらゆるステージに共通する課題だと実感しています。

私はエンジニアとして現役でシステム開発に携わるかたわら、書籍や雑誌連載、ブログ、イベント登壇など、さまざまな形で技術情報を発信し続ける中で、自分なりの情報収集の方法を磨いてきました。技術ライターとして私が取り上げてきた題材は、特定の専門技術だけでなく、日々のITニュースや、ツールの使い方、サービスのレビュー、エンジニアのキャリアや働き方など多岐にわたります。その経験を通じて培ってきたノウハウは、エンジニアとしての生きのこりを掛ける多くの人にも役立つものだと考えています。

1. 発表概要（400字程度）

大学で就職活動をしていたころ、多くの同級生が有名企業を選ぶ中、私はあえて周りが選ばない独立系SIerを選びました。理由は、「有名な会社であること」よりも「プログラミングがしたい」という自分のやりたいことを優先したかったからです。
その後も、事業会社の内製開発組織、そして組織づくりに深く関わる現在の会社へと、3社を渡り歩いてきましたが、一貫して大事にしてきたのは「自分は何に時間を使いたいのか」と「その時間の使い方でどう貢献できるのか」という問いでした。
本セッションでは、3社それぞれのロールでの経験を振り返りながら、会社やロールを選ぶ際にどのような軸で判断してきたのか、社会的な評価や条件とどう折り合いをつけてきたのかを率直に共有します。
「人生の半分は仕事に費やすなら、楽しくないともったいない」と考え、会社の“名前”ではなく、自分のやりたいことと貢献のイメージでキャリアを選んできたプロセスが、これからエンジニアの皆さんが生きのこるためのヒントになれば幸いです。

2. 発表の詳細（1000字程度）

1. 導入：エンジニアのキャリアを「何をやりたいか」から考える

就職率の高い大学で、多くの同級生が有名企業に進む中、「本当に自分は何をやりたいのか」を起点に会社選びをしたエピソードを紹介します。
「会社の名前」「待遇」「安定」といった分かりやすい指標ではなく、「自分の時間を何に使いたいか」を軸にするとはどういうことか、本セッション全体の問いを提示します。

2. 1社目 ─ 「プログラミングがしたい」から始まったキャリア

「プログラミングがしたい」というシンプルな動機から、周りが知らなかった独立系SIerを選んだ背景をお話しします。
有名企業に進めば、若いうちからプロジェクトマネジメントなど上流を任される可能性もあった中で、選んだ道は間違っていなかったのか？
そして入社後にどのように考えながらプログラマ→SE→PMというキャリアを歩み生きのこったのかを共有したいと思います。

3. 2社目ー 「事業をつくる側に回りたい」という欲求の芽生え

1社目で事業会社のお客様と関わる中で、「もっと事業に近いところで開発したい」と感じるようになり、2社目に事業会社の内製開発組織を選んだ経緯をお話します。
2社目では内製開発組織のスクラムマスターというポジションで働いていました。
エンジニアリングから離れ、事業会社の中でどのように生きのこったのかをお伝えしたいと思います。

4. 3社目 ─ 「組織に関わる」ことを選んだ理由

事業会社での経験を通じて、プロダクトやコードだけでなく、「組織のあり方」が事業や個々のエンジニアに与える影響の大きさを実感したことを振り返ります。
「組織というものに大きく関わりたい」という新しい「やりたいこと」が生まれた経緯と、その想いから現在の会社を選んだ理由をお話しします。
拠点立ち上げやマネジメントといったロールを通じて、「人や組織を通じて価値を生み出す」という今の自分のやりたいことに近づいている感覚を共有します。

5. まとめ：やりたいことで生きのこるには

キャリアを振り返ったとき、やりたいことを選びながらも生きのこってこれた考えを整理します。
色々な場面での考え方を共有しながら、1つでも「これなら！」と共感いただけるものがあれば嬉しいです。

3. 想定する聴衆とその人たちが得られるもの

想定する聴衆

• 就職活動や転職活動を考えている方
• 会社やロールをどう選べばいいか悩んでいる人
• 「このままでいいのか」という漠然とした不安はあるが、自分のやりたいことがうまく言語化できていない人

得られるもの

• キャリアを考えるときのヒント
• エンジニアから始まる他ロールへの転身例
• やりたいことを選択しながら生きのこるためのマインドセット

4. なぜこのトピックについて話したいのか

きのこカンファレンスのテーマである「エンジニアが生きのこる」を見たとき、テクノロジーの話だけでなく、こうしたキャリアの選び方やそのときの考え方をあまり聞く機会は多くないのではと感じました。特にAIが登場し大きな変化を遂げようとしている業界に生きるエンジニアにとって、「自分は何をやりたいのか」を言語化し、会社の名前や周りの空気に流されすぎずに選択することは、生きのこるための重要なスキルだと思います。
自分自身が迷いながらも選んできたプロセスを共有することで、同じように悩んでいる誰かが少しだけ楽になったり、一歩踏み出すきっかけになればと思い、このトピックで応募しました。

発表概要

40代で6人のVertical SaaSスタートアップに1人目エンジニアとして飛び込み、プロダクトの再構築と開発組織づくりを担っています。
若い頃はスペシャリスト志向で、「できるだけ長く技術に触れていたい」と考えていました。そんな自分が、組織と技術の両方に向き合う立場を選んだのは、生き残るためではなく、一番面白そうだったからです。
社会貢献性の高い領域での挑戦、PMF済みプロダクトを10年保守できる設計へと再構築する技術チャレンジ、大きな裁量と責任。
不安もありましたが、それ以上にワクワクが勝ちました。本トークでは、40代で飛び込んだ当事者として、変化の激しい時代にエンジニアが持ち続けたい姿勢についてお話します。

発表詳細

若い頃の私は、典型的なスペシャリスト志向のエンジニアでした。
技術に触れていること、深掘りすることが好きで、マネジメントは全く興味がなく「できるだけ長く技術に触れていたい」と思っていました。

そんな自分が40代で選んだのは、6人のVertical SaaSスタートアップに1人目エンジニアとして参画するという挑戦でした。
プロダクトはPMFがある程度検証されている一方、技術的負債や構造的な限界も抱えている状態。そこからプロダクトを再設計し、10年保守できる基盤を作り直す。
そして同時に、完全内製化しスケールする開発組織の土台を設計する。責任も裁量も大きい環境でした。

もちろん不安も大きかったです。自分の能力がプロダクトや組織のキャップになってしまうのではないか、という恐れはありました。
一方、それ以上に強かったのは「面白い」という感覚でした。
社会的意義のある領域で大きな価値を出せること、事業と技術の両面からその構造を作り直せること、そしてゼロに近い状態から未来を設計できること。そのワクワクが、不安を上回りました。

振り返ってみると、「生き残るための戦略」というより、「面白い方を選び続けた結果」だったのだと思います。
AIの進化や技術の変化が加速する現在、個別のスキルの寿命はどんどん短くなっています。
しかし、好奇心を持ち続けること、変化を素直に受け入れること、自分の役割を固定しないこと。これらは時代が変わっても価値を失いません。

本トークでは、40代で挑戦の渦中にいる当事者として、キャリアを積み上げではなくチャレンジと捉える視点、そして若い頃の自分に伝えたいメッセージを共有します。
年齢に関係なく、面白いと感じた方へチャレンジし続けられる人が、この先も生き残るのではないか、と考えています。

想定する聴衆とその人たちが得られるもの

想定する聴衆

• 20代〜30代のエンジニア
• スペシャリスト志向でありつつも将来に漠然と不安がある方
• マネジメントやスタートアップに興味はあるが踏み出せない方
• AI時代に自分の市場価値を再考されている方

得られるもの

• キャリアを「一本道」で考えなくてよいという視点
• スペシャリスト志向のままでも越境できるという実例
• ハードスキル以外に持つべき普遍的な資質
• 「生き残る」ためではなく「面白い方を選ぶ」という考え方

なぜこのトピックについて話したいのか

私は現在進行形で、40代でのチャレンジの渦中にいるため、成功事例としではなく挑戦中の当事者として語ることができます。
若い頃はマネジメントには距離を置いていましたが、今は開発統括責任者として、経営と技術の両方に向き合っています。
理論ではなく、実際に不安とワクワクの両方を抱えながら意思決定し続けており、「完成されたキャリア」ではなく、「変化の途中にあるキャリア」を共有できることが、今の時代に価値があると考えています。

発表概要

エンジニアとして長く生きのこるためには、時代や環境の変化に左右されにくい「基礎となる技術の柱」を持つことが重要です。
AIの普及によりアプリケーションコードは高速に生成・破棄を繰り返す"消耗品"へと変わりつつありますが、
データとスキーマは依然としてプロダクトの根幹であり、設計変更のコストも大きく長寿命のままです。
その基盤を支えるSQLは、方言の違いこそあれ基本構文はほぼ変わらず、技術寿命の観点でも安定した汎用性の高い言語です。

本セッションでは、AIがORMやDSLよりも生SQLを得意とする背景、最適なスキーマやクエリ設計にSQLの理解が不可欠であること、そして実際の現場でSQLが品質や障害対応に直結した経験を紹介します。
また、SQLの弱点であるテストや型サポートを補う手法や、日常作業でSQLを活用する事例も提示します。
AIとデータが中心となるこれからの時代に向けて、「今こそSQLに立ち返る」具体的な技術的指針を提供します。

発表の詳細

エンジニアとして長くキャリアを続けるには、時代や環境に左右されにくい「基礎技術の柱」を持つことが重要です。AI生成コードが一般化し、アプリケーションコードはますます使い捨てに近づいています。一方で、データ構造やスキーマはプロダクトの根幹として長寿命であり、設計の誤りは長く残って柔軟性や性能を制約します。この「長寿命レイヤー」を扱う基盤技術として、SQLの価値が改めて高まっています。

SQLの歴史は長く、方言はあれど基本構文やデータモデルは大きく変わりません。そのため学習データが膨大で、さらに構文が英語に近いため自然言語モデルとの親和性が高く、AIにとってはORMやDSLより生SQLのほうが曖昧さが少なく扱いやすい言語です。AIがコードを書く時代では、人間は「生成されたSQLの妥当性を評価できる力」がより重要になります。

本セッションでは、私がモバイルオンラインゲームのバックエンドを担当してきた中で、SQLの理解が問題解決に直結した事例を紹介します。リリース直後にDB負荷が急増した際にはオンラインでのインデックス追加を行いましたが、ロックの影響やクエリ特性の変化を判断するにはSQLの知識が不可欠でした。また、単一レコードに書き込みが集中する仕様をクエリの工夫で解決した事例などもありました。

次に、SQLの弱点とされる「テストしづらさ」「型の薄さ」への対処法も示します。Dockerにより複数DBを容易に立てられるようになり、Go言語ではMySQL互換のインプロセスDB（go-mysql-server）などを使ってクエリ自体をユニットテストできます。また、sqlcのようにSQLから型安全なコードを生成するツールにより型サポートを補うこともできますし、AIにクエリとモデルを同時生成させる開発フローも実用段階にあります。

さらに、日常的な開発でもSQLは強力です。データ集計や検証は依然としてSQLが効率的であり、インプロセスDBを組み込んだGo製CLIを作ってみたところ環境依存も少なく扱いやすいという体験を得られました。また、SQLとは異なりますが.NETのLINQのようにSQL的操作モデルが長年支持されている点も、データ操作としての普遍性を示しています。

AIによってアプリケーションが高速に流動化する今こそ、変わらない基盤技術としてSQLに立ち返る、その具体的な技術的視点を提示します。

想想定する聴衆とその人たちが得られるもの

自身の強みとなる技術を確立したい人やAI時代にどんな技術を学ぶべきか迷っている人
技術の寿命から考えるという視点と、SQLという現実的な選択肢

なぜこのトピックについて話したいのか

長年モバイルオンラインゲーム（ソーシャルゲーム、スマホゲーム）のバックエンド開発に携わり、様々な技術や障害に触れてきたなかで、データベースとSQLの重要性を実感してきました。
AIが普及してきたこれからの時代では、さらにSQLの重要性が増していると感じています。そんな時代だからこそ、これからに向けてSQLに立ち返るという視点を多くのエンジニアに共有したいと考えています。

①発表概要（400字程度）
「水を運ぶ人」という言葉があります。サッカー日本代表監督だったオシム氏が献身的に走ってパスをつなぐような「目立たないけれどチームを支えている選手」を称えて使った表現です。
私は今チームのリーダーをしていますが、自分は率先して得点を決めるような目立つポジションでもなければ、これだけは絶対に負けないという尖った強みをもっているスター選手でもありません。
そんな自分のリーダーとしてのスタイルが「水を運ぶ人」でした。
優秀なメンバーが活躍するには、裏で潤滑油となり支える役割が必要です。本セッションでは、目立たないリーダーシップの価値と、「得意なことがない」と感じる人が担える尊い役割についてお話しします。

②発表の詳細（1000字程度）

本発表では、「年齢のわりに得意なことがない」と感じている人が、それをコンプレックスではなく、ひとつのリーダーシップスタイルとしてどうチームに貢献できるのかをオシム監督の「水を運ぶ人」という言葉を軸に考えます。

【リーダー像への違和感】
チームで目立つのは「先頭に立って引っ張る人」「点を決める人」のような華々しい存在であり、「リーダー」と聞くとこのような人物像が想起されます。
自分はこういうタイプではなく、「得意なことを見つけましょう」と言われるたびに違和感を感じていました。

【「水を運ぶ人」という言葉との出会い】
転機となったのが、オシム監督の言葉「水を運ぶ人」でした。
（自分は「サッカー全くわからん勢」で、むしろこの言葉をきっかけにオシム監督の存在を知ったようなものです。）
もともとは戦時下で命を守るために働く尊い人を指す言葉ですが、オシム監督は「目立たないが献身的にチームを支える人」への称賛としてこの言葉を使っていました。
花形選手でなくてもチームに貢献できることがあり、それが実はチームをチームたらしめるために重要であるということに気づきました

【自分が目指したリーダーシップ】
「自分が点を決めるのではなく、点を決められる状態をつくる」
「調整、支援、裏方、地味な仕事を引き受けることでチームを前に進める」
現在チームのリーダーを務める中で、私は「水を運ぶ人」のようなリーダー像を目指すようになりました。
優秀な人だけを集めたチームが最強なのではなく、潤滑油という「つなぐ存在」があることでチームは力を発揮できるものだと気づきました。
つなぐ存在として自分が磨いたスキルは観察力、傾聴力、対話力、そして地味な作業を楽しむ力です。

【「得意なことがない」人にこそある役割】
最後に、「得意なことがない」と感じる人へのメッセージを提示します。
尖った強みがない＝価値がない、ではありません。全員がスターである必要はないのです。
そして水を運ぶことは立派な才能です。それは地味ですが尊いリーダーシップだと思います。
自分と同じように感じている人がいるのであれば、支えるリーダーシップを磨いてみてはどうでしょう。
この発表を通じて、目立つリーダー像に馴染めない人が、「水を運ぶ人」としての役割を肯定し、自分なりのリーダーシップを見つけるきっかけになれば幸いです。

③想定する聴衆とその人たちが得られるもの
想定する聴衆
・年齢の割に自分には強みがないと感じている人
・組織やコミュニティの「支える役割」に関心がある人
得られるもの
・個人ではなくチームで成果を出していくリーダーシップ
・「得意なことがない」ことを肯定的にとらえる観点
・「水を運ぶ」ために必要なスキル

④なぜあなたがこのトピックについて話すのか
40歳を越えるとリーダーやマネージャーという役職につくことが多くなりますが、同時に「得意なことを身につけるとよいですよ」「あなたの強みはなんですか」ということを問われることが多くありました。自分はこの質問を受けるたびに違和感を感じていました。
同時に得意なことがこれだと言えない自分、強みをアピールできない自分がダメなように感じることがありました。
しかしリーダーシップにもいろんなスタイルがあること、活躍するべき人が存分に力を発揮できるよう裏で水を運び続けるような目立たない活動が、自分の得意領域だということに気づきました。
同じように「得意なことがない」と感じる人へ「水を運ぶ人」という言葉に救われ、このリーダーシップを実践してきた当事者としての経験を伝えたいと思います