1.発表概要

きのこカンファレンス2025では、「引き際は自分で決める！」というタイトルで発表しました。
そして、「引き際は周囲の人たちと相談して決める」と結論付けました。
その舌の根も乾かぬ昨年末、私は目標を見失い、チームに貢献できない状態になりました。
その背景には、「できることを増やした結果、役割や期待のすり合わせが課題になったこと」がありました。
明らかに引き際を相談するタイミングにも関わらず、想像した通りにはいかず、
「挽回したい」と「潔く辞めるべき」という気持ちが混じり合い、不安定な日々が続きました。
そうした中で、1冊の本に出会い、本来の自分の理想を思い出し、「意義のある行動」を心がけることで、心の中の嵐が静まりました。
そのときの葛藤と、自分の行動の変化、改めて考えた「理想の引き際」についてお話します。
皆さんにもいつか訪れる「引き際」について、少しでも参考になれば幸いです。

2.発表の詳細

皆さんは、引退について考えたご経験はありますか？
私は「きのこカンファレンス2025」で、「引き際は自分で決める！」というタイトルで発表しました。
その時の発表では、「引き際は周囲の人たちと相談して決める」と結論付けました。
その時の私の理想の引き際のイメージは、

• 業務上の問題が発生していない状態かつ自分の判断力にも自信がある状態で
• 予防的な観点で、業務に支障をきたす前に、周囲に相談して引退を検討する

というものでした。
私はキャリア採用されて以来、「できることを増やす」という姿勢で行動してきました。
当初は歓迎されていた行動でしたが、できることが増えるにつれ、役割や期待のすり合わせが課題になる場面がありました。
そして昨年末、私は目標を見失い、冷静さを失い、チームに貢献できない状態になりました。
それを認めたくないという気持ちと、このままではいけないという気持ちが混じり合い、
それまで信じていた価値観が崩れていきました。このままでは、居場所がなくなってしまうと感じたのです。
今が、「引き際」を考えるべきタイミングなのか...？
不安に押しつぶされそうな状態のまま、年末年始の休暇に入りました。

休暇に入って業務から離れたことで、自分のこれからの目標について色々考える時間ができました。
これまで、できることを増やすのは、コンフォートゾーンを抜け出すための一つの手段だと考えていました。
しかし、実はその行動こそが私にとってのコンフォートゾーンであり、やらないことを決めることがコンフォートゾーンを抜けることであると気づきました。

そして1冊の本に出会い、本来の自分の理想を思い出すことができました。
「誰かの成長に役立つこと」その視点に立てば、これからの自分の目標を絞ることは、自然とできるのではないか。と思いました。
「意義のある行動」を心がけるようになり、行動が変化し、自分の心の中の嵐が静まりました。
そこで改めて、「理想の引き際」の条件とは何か？について考えました。

自分の引き際は、逃げではなくポジティブな姿でありたい。

• いざ「引き際」に直面したときの苦しみ
• 本来の姿とのギャップを感じたときの心の葛藤
• その後の視点の変化と、本来の自分の姿を取り戻すまでの過程
• その過程で見つけた「理想の引き際」とは何か？
  この共有が、皆さんが引退を考える際の参考になれば幸いです。

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

• 引退を検討するにはまだ早い段階の方
  • ご自身のライフプランや引き際を検討するきっかけ
  • 行き詰まったときの対処法の参考
  • 自分の成長について考える視点のご紹介
• そろそろ引退を考えるべきか迷っている方
  • 自分にとっての「理想の引き際」とは何か？について検討するための材料
• きのこカンファレンス2025の発表のその後が気になる方
  • その後の私の行動や気持ちの変化

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

昨年の発表時点では、もっとポジティブな形で「自分の引き際」をイメージしていたのですが、実際に引き際を考えたときに、あまりに苦しく簡単ではないことを痛感しました。
そのときのリアルな心の葛藤と気づきを共有することで、皆さんの引退を考える際の参考にしていただければと思いました。
あまりに生々しい記憶なので、発表するかどうか、とても悩みましたが、少しでも誰かの参考になればと思い、プロポーザルを提出します。

【発表の概要】

AI以降、技術の変化が速すぎて「何を学べばいいか分からない」「追うほど疲れる」と感じるエンジニアは増えています。本トークでは、その状況で“生きのこる”ために、あえて「学ぶべき」中心の発想をいったん手放し、好奇心起点の小さな学びを習慣化する方法を提案します。私自身、仕事と無関係に「触ってみたい」だけで始めたRustやElectronが、数年後に短納期案件の解決や実装領域の拡張、キャリアの選択肢に直結しました。未来が読めない時代ほど、最適解探しではなく、好奇心から“技術を楽しむ力”が、長く働き続ける基礎体力になります。

【発表の詳細】

このトークは「学習効率を上げる話」ではなく、変化が前提の時代に“学び続けられる状態”を作る話です。AIの登場で、今日のトレンドがすぐ陳腐化しやすくなり、「正しい学び」を選び続けるほど疲弊しがちです。そこで、私は学ぶべきことに自分の興味や好奇心を優先する選択をすることを勧めます。

私は過去に仕事に関係ないけれども「なんかかっこいい」という理由だけでRustを学んでみたり、「Atomってエディタを作っている技術らしいぞ」だけでElectronを触ってみたりしてきました。職場の仲間からは「なんかやってるわ」ぐらいにしか思われていませんでした。しかし、その後超短納期のデスクトップアプリ開発をElectronで解決し、Rustはwasmなど実装の幅を広げるだけでなく、キャリアの選択肢も増やしてくれました。

具体的な方法はシンプルで、行ってしまえば息抜きです。

1. 個人の勉強時間を好奇心ベースで1日5～30分だけ割り当てる
2. 自分用にメモする。または誰かに話をする

この短時間の息抜きで「自分だったらどう使うかな」や「どうやったら使えるかな」を一緒にメモをすることで、何かあったときの武器にすることができます。

AIを適切にコントロールするためには、概要を知っているだけでもAIが言っていることが正しいかどうかの判断がしやすくなります。自分の技術の幅を広げるのも「好奇心」ですし、根本的に課題を見つけるためにも「好奇心」がカギとなります。

日々のちょっとした息抜きで皆さんもキャリアを広げてみましょう

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

想定する聴衆

• 技術の変化が速く、学び疲れや焦りを感じているエンジニア（特に20〜30代）
• キャリアの方向性が定まらず、「何を武器にすべきか」迷っている人
• AI時代に、学び方そのものをアップデートしたい人

得られるもの

• 点の学びを将来の仕事、キャリアに接続しやすくするマインド
• 明日から試せる形での習慣化とメモの型を持ち帰ってもらいます

【なぜこのトピックを話したいのか】
自分は仕事で必要のないことを多く学びました。
その好奇心だけで学んだことが後から課題解決のカギになったり、実装の幅、キャリアの選択肢として効いてきました。

AIが発展してきた今、これからもエンジニアとして働き続けるために必要なことは好奇心だと言われています。学ぶことはたくさんあるけれども、好奇心だけで学ぶ「余白」がキャリアにかえって良い影響を与えることになるので、この実感を明日から使える形で共有をしたいです。

①発表概要
1999年、高校生の私はWindows98のPCを前に、ダイヤルアップの接続音を聞きながら初めてインターネットに触れました。
掲示板やチャット、アクセスカウンターの“キリ番”など、当時のネットは未知だらけで、失敗も含めて学びの連続でした。
2026年、AIが再び大きな“未知”として現れた今も、私の中ではあの接続音が聞こえます。
インターネットを皮切りに、mixi、iPod、AWA、Netflixと、私の世界は何度も拡張されてきました。
しかし、拡張された世界を味わい、乗りこなすのは人間自身です。
本LTでは、1999年の体験を振り返りながら、AIという未知に直面する今だからこそ「学びの主体を自分に戻す」ための視点を共有します。
「AIで何ができるか」より「AIで何をしたいか」。自分の一歩を選び取るための視点をお届けします。

②なぜこのトピックについて話したいのか
AIの登場で、期待と不安が同時に広がり、何から始めればよいか迷う人も多いと感じます。
一方で、未知に直面するのはAIが初めてではありません。
インターネット前後を体験した世代として、技術の波に学びを委ねるのではなく、学びの主体を自分に戻し、試行錯誤しながら使いこなしてきた経験があります。
その感覚を言葉にして共有することで、聞き手が「いまから・ここから」自分の意思で踏み出す後押しができれば幸いです。

①発表概要
私は40代を迎え、8年ぶりに実装の現場に戻り、チーム開発の壁にぶつかりました。
かつてはスマホアプリのバックエンドを一人で担い、プロダクトに求められる複雑な要件を構築していきました。
その後、マネジメント中心のキャリアに移りながらも、プレイヤーであり続けたい葛藤を抱えていました。
そして、昨年本格的な実装に復帰しました。
そこには想定以上に何もできない自分がいました。言語や領域の違い以上に、チーム開発を知らないことに気づきました。
そこからの学びは、エンジニアとしてやり直しの機会となりました。
現在、AIが開発速度を上げる中で、意図の共有や意思決定を同期しながらチームで開発を進めることが、より難しくなっていると感じます。
そうした経験から、プロダクト価値やチーム成長のためのマネジメントの道を歩みたいと考えることができました。
実装とマネジメントの間で揺れる方が、次の一歩を選ぶ視点を提供できれば幸いです。

② 発表の詳細
私は40代を迎え、マネジメント中心の8年間を経て実装の現場へ復帰しました。
復帰前の私は「昔はバックエンドを一人で担い、複雑な要件も作り切れた」という成功体験を持っていました。
しかし、昨年プロダクト開発で本格的に実装へ戻ったとき、そこには想定以上に「何もできない自分」がいました。
言語や領域の違いだけではなく、「チームで価値を届ける開発」を意識できていなかったことに気づきました。

当時の私は、ボールを持った一人がゴールを決めるように、個人の裁量で設計・実装を進める感覚が残っていました。
一方、新しく担当したプロダクト開発は、バックエンドだけで完結しません。
フロントエンド、インフラ、運用監視、品質、リリース後の改善までを前提に、チームで分担とレビュー、合意形成を繰り返しながら価値を届けます。
バックエンドの強みだけでは通用せず、フロント・インフラの学習コストに圧倒されました。
自分が強みだと思っていた領域だけに閉じていると、チームの前進を阻害してしまうことすらありました。
ここで私は、技術のキャッチアップ以上にチーム開発を学び直す必要があると気づきました。

仕様については誰かが一人で考えて書いていくのではなく、チームで語って作り上げていくことが重要と知りました。
テストから得たフィードバックは次のプロセスに活かしていくことに気がつきました。
誰かひとりが考えるのではなく、チームでプロダクト価値を実現していくことの重要性を学びました。

さらに現在、AIが実装速度を押し上げる中で、意図の共有と意思決定の同期がこれまで以上に難しくなっていると感じています。
各自がAIと対話して速く進められるほど、前提条件や判断軸が個人の中に閉じ、レビューで初めてズレが顕在化することがあります。
何よりもチーム内での対話よりも、個々人でのAIとの会話の方が多くなっていると感じています。
そこにはプレイヤー個々人の意識以上に、より俯瞰した立ち位置での推進が重要になると感じました。

この一連の経験を通じて、私は「強い個になる」よりも、「強いチームを支える」ことに価値を見出すようになりました。
プロダクト価値とチーム成長を両立させるために、私は改めてマネジメント（EM/PM）の道を志しています。

実装とマネジメントの間で揺れる方が、自身の次の一歩を選ぶための判断軸を持ち帰れる内容としてお届けします。

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

• プレイヤーを続けたいが、マネジメント比重が増えて悩んでいるエンジニア
• 実装ブランクからの復帰に不安がある方
• チーム開発で「個の強さ」と「チームの成果」の両立に課題がある方

・得られるもの

• 「復帰直後に失速する理由」を、技術以外（チーム前提・価値の捉え方）まで含めて分解する観点
• AI/仕様駆動開発で“速く作れる”ほど失われやすい連帯を、仕組みで補うための着眼点
• 「プレイヤーを続ける」「支える側に回る」を二項対立にせず、次のキャリアを選び直す判断軸

④ なぜこのトピックについて話したいのか
私は、バックエンド開発で成果を出していた時期を経て、管理中心の役割が長くなりました。
その結果、プレイヤー復帰をした際に「自分はチーム開発を知らなかった」という事実に直面し痛手を経験しました。
一方で、その痛手を起点に、学びと実践を基に、プロダクト／プロセス改善を内側から推進できる状態まで戻すことができました。
いまAIが開発の前提を変える中で、私が得た痛手からの学びを「チームで生きのこる」ための知見として共有したいです。

①発表概要
私は40代で、ようやく「エンジニアになれた」と感じました。
20～30代の私は、業務を確実に果たすことに集中し、学びが自分の環境に閉じていました。
「外に出て学ぶ」という発想を持つことができていませんでした。

転機は40代での0→1プロダクト開発の失敗です。
リリースを果たせた一方で、今までのやり方は、チームを苦しめ、自分も追い詰めました。
今までのやりかたが通用しなくなることを知りました。
「知らないことを知らないままでは前に進めない」と痛感し、そのために外部からの学びが必要と考えました。

その後、勉強会やカンファレンスに参加するようになり、外部の環境から学ぶことで視野と選択肢が広がる体験を得ました。
過去の経験や置かれた環境からだけでなく、今必要なものを判断できる主体性を獲得しました。

本トークでは、外部の学びで世界を拡張し、40代からでも未来を「いまから、ここから」更新した実践を共有します。

② 発表の詳細
本トークは「外に出て学ぶ発想がない状態」から抜け出し、40代からでも未来を更新できることを、失敗と回復のプロセスとして共有します。

まず、学びが自分の環境に閉じていく状態を整理します。
企業では“求められた成果を出す”ことが最優先になり、学びが「必要になったら調べる」に収束しがちです。
その結果、同じ型の判断が強化され、知らないことに気づけない（＝選択肢が増えない／他の可能性に気付けない）状態になります。
また、うまくいったことは成功体験となり、それ以上の未来があっても意識できない状態となります。

その後、40代で経験した0→1プロダクトの失敗を題材に、意思決定の偏りや合意形成の不足、チームの摩耗、属人化のハードワークがどのように連鎖したかを扱います。
“効率化”の名目で担当が細分化して、誰も全体の価値に責任を持てない分断を生んでいました。
学びや成長が実現されない環境で、結局最後は私個人のハードワークで解消しました。
今までのやり方が通用しなくなることを知りました。

そして、「知らないことを知る必要がある」を、行動に落とす転換点として語ります。
改めて、プロダクト開発のマネジメントに携わる上で、必要となる学習を進めました。
書籍の形式知だけでなく、他の人たちがどのように開発に携わっているかを知るため、勉強会・カンファレンスへの参加を継続しました。

そこで得たのは知識以上に、エンジニアリングする人の姿勢、現場ごとの前提、価値観の違いでした。
「自分の常識は唯一の正解ではない」と体感できたことが、学び直しの起点になりました。

また、そうした学びは自分の環境下から解き放ち、エンジニアリングの魅力を楽しむことに繋がりました。
結果、私は業務として開発に携わる自分から、
環境に左右されずに学び、判断し、改善できるひとりのエンジニアになれたと思っています。

最後に、知識の習得と実践を繰り返すことで、過去の経験に縛られず今必要なものを判断する意思決定と主体性を獲得したことをお伝えします。
私はこの変化を通じて、40代になって初めて“エンジニアリングする自分”を獲得できたと感じました。

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

• いまの環境の中で頑張っているが、視野や選択肢を増やしたい方（20～30代）
• 学び直したいが、何から始めればよいか迷っている方（40代以上）
• いつまでエンジニアであることを楽しめるのか悩んでいる方

・得られるもの

• 自分の学びが環境に閉じているかを確認できる
• 失敗を"学び直しの起点"に変換する考え方(痛感を行動へ落とす方法)
• 40代以降も成長し続けるエンジニアとしてのキャリア観

④ なぜこのトピックについて話したいのか
私は「最初から順調に成功したエンジニア」ではありません。
長い間、自分の環境の中に閉じ、外に出て学ぶ発想を持つことができていませんでした。
私自身が外部の学びを通じて救われた経験は、若手世代を勇気づける力があると実感しています。
同時に、同世代の方々にも「いまからでも遅くない」というメッセージを届けたいです。
「いまから、ここから」未来を更新するために、外から学びを得ることの魅力を伝えたいと考えています。

1.発表概要

私は勝ち負けや強弱、失敗や成功といったものにあまり興味がない。いや、辟易していると言った方が正しい。

昔から無欲な人間だったわけではない。
27歳でIT業界に入った。明らかな出遅れは、長年私を技術力への劣等感と、周囲の評価に対する飢えに縛り付けた。しかし不惑を迎え、それらの憑き物が落ちていることに気がついた。

当セッションでは何者でもない私が、何者でもない自分自身を認め、
他者に囚われず、いかにして心の平穏を取り戻したのか。その過程を私を救った書物と共に辿る。

紹介する予定の本は以下である

• 武士道
• 論語
• 欠乏の行動経済学
• ニコマコス倫理学
• 存在と時間
• 死に至る病
• 老子
• 注文の多い料理店　序文

2.発表の詳細

精神の平穏を再構築するに至った書物について記述する。

武士道

新渡戸稲造　1899
日本人の価値観を欧米諸国に伝えるために書かれた一冊
我々日本人の根底に流れる価値観である、義・勇・仁・礼・誠・名誉・忠義、そして切腹の美学について話す。

ひとこと「切腹してはならない」

論語

孔子　だいたい2,500年前　
思想家である孔子の言葉
武士道のベースになった書物。人の普遍性を教えてくれる。あと孔子は生姜をあんまり食べないとか、くだらないことも書いている。

ひとこと「どの時代だろうが人間の本質は変わらない」

欠乏の行動経済学

センディル・ムッライナタン、エルダー・シャフィール　2013
飢えている時は正常な判断ができない。ゆとりの重要さを教えてくれる。
この本によって自身の葛藤や絶望が欠乏のせいだと自覚した。

ひとこと「まずは飢えを解消することだ」

ニコマコス倫理学

アリストテレス　だいたい2,300年前
哲学者アリストテレスの言葉たち。
人間の全ての行動は幸福に向かうためのもの。偏りすぎない中庸という状態が大切。といった普遍的な考えが書かれている。凄すぎる本。

ひとこと「苦痛を排除せよ。幸福を目指せ」

存在と時間

ハイデガー　1927
正直なところ全体的に難解すぎるのだが、それでも「世人（ダス・マン）」という考え方は衝撃的だった。
人は自分の価値観ではなく世間の平均に合わせて振る舞う。平均から抗おうとする行為すらまた別の世人となる。本来的な自分を取り戻すためには、死と向き合うことと良心の呼び声に従うこと。

ひとこと「自身がもう直ぐ死ぬとしたら何を大切にするのか？」

死に至る病

キルケゴール　1849
絶望が与える苦しみは果てしない。そして、絶望にも色々な種類があることを教えてくれる。
絶望していることに気づかない絶望、自分であろうとしない絶望、自分であろうとする絶望。
絶望から抜け出すには自分の中に信じる何かを持たなくてはいけない。

ひとこと「信じるものを持ってほしい」

老子

著者不明　大体2,300年前
水のように自由自在で高いところから低いところへ流れるものが最も善いものである。
富まず尖らず誇らずにいることが平穏を招くということを教えてくれる。

ひとこと「まあ肩の力を抜きなよ」

注文の多い料理店　序文

宮沢賢治　1923
2ページにも満たない文章が、私の人生観を形成している。
この文章についてはただあるがまま読み上げることとする。

私は哲学や文学の専門家ではない。しかし、一人のソフトウェアエンジニアとしてこれらの言葉をどう咀嚼し、どう現実と向き合ったのか。その実践知としての側面を重視して語る。

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

想定する聴衆

30代以上のエンジニア
その中でも主に自身の技術力、社会的地位、収入にコンプレックスを持っている人

得られるもの

絶望を乗り越え心の平穏を保つための考え方および参考となる書籍の情報
周囲の人間や社会に振り回されず、これから何のために仕事を続けるのかを見つめ直すきっかけ

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

IT業界に入って以来コンプレックスにまみれ、技術力の無さに嘆き、周囲の評価に飢えてきた。
SNS上で見かけるエンジニア達に憧れ、そうならなければならないと焦っていた。

きっと似たような人はいると思う。
今苦しみや不安を抱える人、そして未来にそうなるかもしれない人に向けて、
エンジニア人生をどう生きるのか。そして、不安を少しでも和らげ、生きるのが少し楽になれば、私も嬉しい。

■1. 発表概要
時は200X年、大学中退フリーターが時給につられて応募したバイトは、某プロバイダのサポートセンターでした。その後夜勤オペレーターを経てスキルを積み、どうにかITエンジニアを名乗れるようになるも、業界の流行り廃りに乗っているつもりで振り回され、経歴ロンダリングを重ねながらすでに40代半ば。実態のわからない人になりつつ、それでもまだ生き残っています。

どの話も「すごい人の話」に聞こえてしまう方、この先生き残れる気がしていない方、ご安心ください。
自分の失敗と反省、そして同僚たちの現在から考える、変化に適応しつつ自分の軸を持ち、なにより病まずに生き残るTipsを、えらい低い視座からお話します。
生き残れるところまでいっしょに生き残りましょう!

■2. なぜこのトピックについて話したいのか
IT業界では低く見られがちなサポートセンターや監視業務からでも、スキルを積み重ねエンジニアとしてキャリアを築けることを、実体験からお伝えしたいです。
また、コールセンターのオフショア、インフラのクラウドリフト、RPA導入などなど、数々のブームとその揺り戻しに翻弄されてきた経験を元に、流行に乗るメリット・デメリットと、変化に左右されない基礎力についてお話しします。

1. 発表概要

会社員としてのキャリアから独立、法人化を経て、再び会社員に戻るという非線形なキャリア選択について共有します。コミュニティや情報発信を軸にフリーランス・経営者として活動してきた中で、日本市場の構造的な限界やAI領域の急激な成長に直面し、外資系AI企業に社員として参画する決断に至りました。本セッションでは、働き方の形態そのものではなく「どこで価値を最大化できるか」という視点から、独立・起業・再就職をどう判断したのかを整理します。個人のキャリア戦略と市場環境の関係、DevRelという職能の立ち位置を、実体験ベースで解説します。

2. 発表の詳細

私のキャリアは以下のような変遷となっています。

1. 会社員としてのキャリア初期
   技術職として複数社で勤務し、インターネット黎明期の業務経験を積んだ話
2. フリーランスとして独立
   2005年にフリーランスとして独立し、コンサルティングやプロジェクト管理のアウトソースに従事
3. 2013年に法人化（株式会社MOONGIFT）
   DevRel（開発者向けマーケティング）の事業化とコミュニティ作りに尽力し、日本・インドでイベントを運営
4. AI領域の注力
   AI領域での需要増加と外資系企業の成長に注目し、CodeRabbitにフルコミットを決定

学びポイント

• 働き方は時代と市場で変化する
• 自分だけの強みを作る
• 外資企業へリモートワークでのジョイン

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

主な聴衆は「会社員として働く中で、将来的な独立を考えている人」「いつか外資系で働いてみたいと思っている人」「フリーランスで働いている人」です。

得られるポイント

• 会社員・フリーランス・法人経営をすべて経験した視点から、それぞれの働き方のメリットと限界を整理できる
• 「独立＝成功」「会社員＝安定」といった単純化されたキャリア観を見直す材料を得られる
• DevRelのようなマーケティング×技術力というキャリアの実態を理解できる
• 自分が今いる立場に固執せず、「どこで価値を最大化するか」という視点でキャリアを設計するヒントを得られる

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

2026年2月にCodeRabbitへフルコミットを開始し、キャリアの大きな変化が発生しました。法人化していた中で、AI時代の中で個人としての生存戦略を考える中での決断です。記憶が新しいうちにシェアできるものがあると思っています。

■発表概要
エンジニアにとって「評価」は、「主観的で不透明なブラックボックス」になりがちです。これが個人の成長を妨げ、組織への不信感を生むバグとなります。
本セッションでは、評価者の感情を徹底的に排除し、エンジニアが納得せざるを得ない「35,000通りの定義」による合理的評価システムを公開します。
7カテゴリ・100項目のコンピテンシーを5段階で定義し、70以上のロール（職種）ごとに最適化したこの仕組みは、単なる査定ツールではありません。
自分の現在地を正確にサンプリングし、バックエンドからテックリードまで、目指すべきキャリアへの最短経路を導き出す「キャリアの仕様書」です。
若手からベテランまでが、不満ではなく技術研鑽に没頭できる環境をいかに実装したか。
その設計思想と運用から得られた知見を共有し、変化の激しい時代をエンジニアが生きのこるための「共通言語」としての評価の在り方を提案します。

■発表の詳細
本セッションでは、組織のOSとも言える「評価制度」をエンジニアリングの視点で再構築した事例を深掘りします。

1. 評価制度における「主観」という技術負債
   　多くの組織では、評価者の印象や声の大きさに左右される「主観評価」が横行しています。これはエンジニアにとって予測不能なシステムであり、心理的安全性を著しく毀損します。この不確実性を排除するために、我々がどのように「評価の標準化」を試みたかを解説します。

2. 35,000パラメータの設計：コンピテンシーマトリックスの実装
   　評価の核となるのは、7つのカテゴリに分類された約100項目の評価ポイントです。
   　　・各項目にレベル1から5の達成基準を明文化。
   　　・バックエンド、フロントエンド、SRE、テックリードなど、70を超えるロールごとに「期待値」を設定。
   　　・結果として、「100項目 × 5レベル × 70ロール = 35,000通り」の解像度でキャリアを定義しました。
   　　これにより、どの技術を伸ばせば等級が上がるのか、ロール転換時に何が足りないのかが、コードの静的解析のように一目で判別可能になりました。

3. 3軸による多角的なサンプリング 等級だけでなく、以下の3軸を数値化して評価を構成しています。
   　　・スキル評価: マトリックスに基づく「実力」の証明。
   　　・人事評価: 成果だけでなく「行動量」を可視化し、プロセスを評価。
   　　・理念実践度: 抽象的な「会社理念」を具体的な行動へデコードし、定量化。
   　　これらを組み合わせることで、特定の個人への依存や感情を排した「アルゴリズムによる評価」に近い運用を実現しています。

4. 運用結果：ベテランと若手が共存する「生存戦略」
   　この極めてロジカルな仕組みがもたらしたのは、意外にも「温かい納得感」でした。
   　　・ベテラン層: 自身の経験がどの項目に該当するかが明確になり、後進への技術伝承が「評価対象」として可視化された。
   　　・若手層: 35,000の定義が「成長のロードマップ」となり、迷いなく学習に投資できるようになった。 本パートでは、実際に不平不満が消え、組織満足度が向上したデータについても触れます。

想定する聴衆とその人たちが得られるもの
【想定する聴衆】
　・今の評価に納得がいかず、自分の価値をどう証明すべきか悩んでいるエンジニア
　・次に何を学ぶべきか、キャリアの迷路に立ち止まっている方
　・主観的な評価から脱却し、エンジニアが誇りを持てる組織を作りたいリーダー・マネージャー
【得られるもの】
　・自分のキャリアを「項目」と「レベル」で客観的に分析する視点
　・エンジニア特有の「納得感」を生み出すための、具体的な評価項目設計のフレームワーク
　・70以上のロールを定義するための、多様なキャリアパスの考え方

なぜこのトピックについて話したいのか
エンジニアが一生エンジニアとして「生きのこる」ためには、市場価値と組織評価が正しく同期している必要があります。しかし、多くの現場では評価基準が曖昧なために、優秀なエンジニアが疲弊し、去っていく姿を見てきました。 私は、評価を「政治」ではなく「エンジニアリング」の対象にしたいと考えています。35,000もの定義を愚直に作り込み、運用してきた経験は、必ずや現場で戦うエンジニアたちの救いになると確信しています。 「評価制度が変われば、エンジニアの生き方はもっと自由で、もっと強くなる」ということを、実体験に基づいたロジックを伝え、一人でも多くのエンジニアに笑顔でエンジニアリングをしてもらえるきっかけになれればと思っています。

【発表概要】
「エンジニアを辞めてマネジメントに行く」それは片道切符だと思っていませんか？ 私は現在、PdMやデザイナー組織のマネージャーを務めています。名刺上の役割は変わりましたが、アイデンティティは「ずっとエンジニア」であり、軸は一貫して「プロダクトづくり」にあります。

本セッションでは、前半15年のエンジニア経験（設計・アーキテクト視点）がいかにして現在のマネジメント領域で活きているか、そしてAIの台頭によって、なぜ今「再びエンジニアに戻る」という選択肢が現実的になっているのかをお話しします。

役割という「枠」に囚われず、技術とビジネスの間を自由に行き来し、経験を積み重ねて元の場所へより高い視座で戻ってくる。そんな「螺旋（らせん）型キャリア」こそが、境界が融解するAI時代の生存戦略です。エンジニアの「心」を持ち続けるすべての人へ、未来への希望となる「あり方」を提案します。

【発表の詳細】
はじめに：「名刺」は変わっても、「心」は変えなくていい
「名刺の上では部長、頭の中ではPdM。でも、心の中ではエンジニアです」。任天堂・岩田元社長の言葉に共感する人は多いはずです。私もその一人です。コードを書く業務から離れ、PdMやデザイナーの組織を見るようになった今でも、私の判断基準の根底にあるのはエンジニアリング思考です。この「エンジニアマインド」こそが、不確実な時代の最大の武器です。

■セッションの構成

1. 武器の再定義：実装力ではなく「設計力」で戦った15年 私のキャリアの前半は、超人的なコーディング速度で勝負するタイプではありませんでした。
   むしろ、全体俯瞰的な「設計力」、複雑さを整理する「アーキテクト視点」、そしてチームを動かす「リーダーシップ」が強みでした。当時は「手を動かさないこと」への葛藤もありましたが、結果としてこのスキルセットが、後のPdM業務や組織マネジメントにおいて「エンジニアリングの勘所がわかるマネージャー」という強力な差別化要因となりました。

2. 越境するキャリア：職能の「融解」を楽しむ 現在、私は非エンジニア職（PdM/デザイナー）のマネジメントをしています。
   ここで気づいたのは「組織づくりもプロダクト開発と同じ」という事実です。要件定義し、負債を解消し、スケーラビリティを確保する。対象がコードから人・組織に変わっただけで、エンジニアリングの思考法はどこへ行っても通用します。「技術職を離れること」は、スキルの喪失ではなく「適応領域の拡大」だったのです。

3. 螺旋的未来：AIと共に「エンジニア」へ還る (FUTURE) そして今、生成AIの登場により、キャリアは再び面白くなっています。
   コーディングのハードルが下がったことで、私が得意としてきた「設計・アーキテクト」の能力があれば、実装力（腕力）の衰えを補って余りあるパフォーマンスが出せる時代が来ました。「マネジメントの視座」と「最新技術」を携えて、再び現場に戻る。それは後退ではなく、螺旋階段を登るように、より高い視点を持って元の場所に戻ってくる行為です。 AIを前提とした時代、エンジニアのキャリアは「一直線の道」から「自由な往復運動」へと変わります。「いまから、ここから」どう生きのこるか、その具体的な戦略をお話しします。

【想定する聴衆】
・すでにEMやPdMとして活動しているが、技術から離れることに不安や寂しさを感じている方
・「コードを書かなくなったらエンジニアとして終わり」という恐怖心がある20代～30代
・自身のキャリア設計、あるいはメンバーのキャリア支援に悩みを感じている中堅～シニア層

【得られるもの】
・職種名（ロール）に縛られず、自分の「強みの軸（設計力など）」でキャリアを構築する視点
・マネジメントやビジネス領域へ越境することのメリットと、そこから技術職へ戻る際のアドバンテージ
・AI時代の到来を「若手との競争」ではなく「ベテランの復権」と捉えるポジティブなマインドセット

【なぜこのトピックについて話したいのか】
私自身、キャリアの途中で「エンジニアであり続けたい」という想いと「マネジメントへの期待」の間で葛藤した経験があります。しかし、役割（ロール）と心（アイデンティティ）を分けて考え、さらにAIという新しい武器を手に入れたことで、その葛藤は「自由」に変わりました。 「エンジニアは35歳で定年」「マネージャーになったら技術は捨てる」。そんな古い常識を壊し、私たちは何歳になっても、どんな役割についても「エンジニア」であり続けられる。その楽しさと生存戦略を共有し、未来を前向きに捉えるきっかけを作りたいと願っています。

1. 発表概要

多くのITエンジニアは、自身のスキルを「他のエンジニア」と比較して評価する傾向があります。一方、フリーランスとして働き、顧客が経営者や非技術部門になる場合、重視されるのはソースコードの美しさや最新ツールの習熟度ではなく、事業への貢献や課題解決力です。
そこで本セッションでは、「誰から見るか」「どこから見るか」によってスキルの見せ方・伝え方がどのように変わるかを紹介します。

2. 発表の詳細

ITエンジニアの現場では、新しい技術やツールが次々と登場します。そのため、継続的に学び続ける必要があると感じる人が多くいます。高度なスキルを身につけて将来フリーランスになりたいと考える人も多いでしょう。

フリーランスがエージェント経由でSES契約を検討する場合、似たスキルを持つ候補者との競争に直面することが珍しくありません。加えて、生成AIの進化を受けて、自分の仕事が代替されるのではないかと懸念するエンジニアもいます。

しかし、『最新の言語・技術でシステムを開発できる』ことがエンジニアとしての強みであっても、経営者はそれが『事業にどのような効果をもたらすか』が分からなければ価値を感じにくいのが現実です。特に請負契約では、求められる責任や評価軸が変わるため、生き残るための戦略も変化します。

まずは「誰から見るか？」の意識転換が必要です。ターゲットを「同業者」→「クライアント（経営者・事業オーナー）」に変えてみるのです。すると、必要なのは「技術の翻訳」であることがわかります。これは「技術的視点」から「ビジネス・戦略的視点」に変えること、つまり技術を価値に変換して伝える必要があるとわかります。

次に、「どこから見るか？」という場所の変化も必要です。コンピュータの中から見るのではなく、実際の現場や経営陣の立場から見るのです。すると、ITに関する技術を使うだけでなく、他の方法が見えてくるかもしれません。

ITエンジニアの仕事は単なるプログラミングやネットワーク、データベースといった「技術」だけではありません。経営者が真に評価するのは、判断力やドメイン知識、ステークホルダー調整、事業戦略に結びつける思考など、AIに置き換えられにくい能力（総合的な問題解決力）です。本セッションでは、それらをどのようにアピールするかを扱います。

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

• 想定する聴衆
  • フリーランスとして独立を検討しているITエンジニア
  • 社内で経営層や非技術部門に説明する必要があるエンジニア
  • キャリアチェンジを考え、セルフブランディングを改善したいエンジニア
• 参加者が得られるもの
  • 技術を事業価値に翻訳して伝える考え方
  • フリーランスとして差別化するためのキャリア戦略の視点

4. なぜ私がこのトピックについて話すのか

私はフリーランスエンジニアとして10年以上、複数の企業と請負契約で仕事をしてきました。また、技術書の著者として30冊以上の書籍を執筆しており、特定領域に偏らない幅広い実務経験が20年以上あります。その経験から、「優れた技術」と「伝わる技術」は必ずしも一致しないことを何度も目の当たりにしました。

これらの経験をもとに、「誰から見るか」「どこから見るか」によって異なるスキルの見せ方・伝え方を紹介します。

①発表概要
中高一貫の女子校を卒業し、大学へ進学。そこで直面したのは就職氷河期の厳しさでした。学歴が機能しづらくなっていた中で、私はインターネットとオープンソースに世界を変える可能性を感じ、大学を中退しました。 しかし、現実は甘くありませんでした。コミュニティでの評価を市場価値と混同したことによるキャリアの迷走や、リーマンショック後の景気悪化の中での解雇。時代の状況や自らの判断ミスに翻弄されながらも、私はエンジニアであり続けることで生きのこってきました。 本セッションでは、四半世紀にわたり、世界を変える技術への憧れを胸に歩んできた生存術を提示します。失敗を経験として次に活かす考え方、コミュニティとの適切な距離感、そして環境の変化に応じて役割を変えながら生きのこる知恵。 将来に不安を抱く若手へ、生存者の視点から明日を切り拓くための現実的な知恵を共有します。

②発表の詳細
本セッションでは、厳しい時代に世界を変える技術に自らの人生を賭けた決断と、その後のキャリアで得た教訓を振り返ります。

1.時代の状況と大学中退という選択
2000年代前半、大卒就職率が50%台まで落ち込んだ就職氷河期の中でも一番厳しかった時期。中高一貫の女子校から関関同立の一角へと進みましたが、当時の就職状況は極めて厳しく、私の周囲では旧帝大卒でも地方公務員、関関同立でも正規雇用に就けないことが珍しくありませんでした。限界を感じていた私は、インターネットとオープンソースが持つ可能性に賭け、大学を中退しました。これは当時の状況に対する自分なりの対応でしたが、その後の厳しい現実にも直面することになります。若手に対し、たとえ選んだ道で困難に直面しても、原点にある技術への確信をどう守り抜き、どう生きのこるべきか、その姿勢の重要性を伝えます。

2.コミュニティへの依存が招いた教訓
世界を変える技術の象徴であったコミュニティ。しかし、コミュニティでの評価を自身の市場価値と履き違えてしまいました。繋がりを優先して仕事を選んだ結果、年収が落ち込むという経験をしました。この失敗から学んだのは、コミュニティはあくまで自立した個人が関わる場であり、自身の生活基盤やキャリア形成とは切り離して考えるべきであるという教訓です。現代の若手へ、コミュニティとの健全な距離感について提案します。

3.環境の変化に適応し、エンジニアであり続けること
リーマンショック後の景気悪化による解雇など、外部環境の変化にも直面してきました。生きのこるために、その時々の現場で求められる役割を柔軟に引き受けてきました。それはエンジニアとして働き続けることを最優先した結果です。不透明な状況下で、どのように自身の役割を再定義し、キャリアを継続させてきたか、その現実的なアプローチを共有します。

4.四半世紀を経て今思うこと
40代になってもこの先生きのこれるかという問いは続いています。しかし、これまでの失敗や迷走も、現在までエンジニアを続けているという事実の前では、すべて経験の一部となります。 まとめとして、時代の状況や自らの失敗に翻弄されながらも、エンジニアとしての誇りを胸に歩み続けてきた経験から、若手エンジニアに対し、自身のキャリアを長期的に捉え、生きのこるための視点を提示します。

③想定する聴衆とその人たちが得られるもの
想定する聴衆
・自身のキャリアや将来に不安を感じている若手エンジニア
・環境の変化や失敗をどのように乗り越えるべきか悩んでいる方
・成功談ではなく、失敗からの立て直し方を知りたい方
得られるもの
・厳しい環境下でエンジニアとして働き続けるための考え方
・コミュニティや外部評価との適切な距離感についての知見
・失敗しても終わりではないという実例に基づく確信

④ なぜあなたがこのトピックについて話すのか
私は就職氷河期に、オープンソースとインターネットの可能性を信じて大学を中退した当事者です。学歴すら通用しなかった時代に、自らの意志で選んだ道で味わった困難を、エンジニアとしてのキャリアを守るためのプロセスとしてリアルに語ります。 成功談だけでなく、自らの判断ミスや時代の状況によって直面した困難を、事実に基づいて語れることが私の強みです。40代以上の登壇者が若手に知恵を共有するという本カンファレンスの趣旨において、私の四半世紀の生存記録は、若手エンジニアにとって参考事例になると考えています。

参考資料
東京・大阪・コミュニティを渡り歩いた約四半世紀の記録
https://speakerdeck.com/yukio0113/dong-jing-da-ban-komiyuniteiwo-du-ribu-itayue-si-ban-shi-ji-noji-lu

★概要★
ITエンジニア職の多くはデスクワークであり、病気の内容にもよりますが、他の職業に比べれば闘病しながらのお仕事も容易です。とはいえ制約が全く無いかというとそうでもありません。このトークでは、そういった制約事項にこれまでどのように立ち向かってきたのか、そしてこの先どうしていくのかの予定、などについて紹介していきます。

================================
★詳細★
このトークには以下のような内容が含まれる予定です。

▲私の技術的な守備範囲(背景情報の提示)
技術的にはWebアプリのサーバサイドのお仕事をやっていることが多いですが、たまに片手間でインフラやWebフロントエンドも見てます。という話をもうちょっと詳しくします。

▲健康(軽症)だった頃の働きっぷり
プログラミングおよび周辺業務だけではなく、受託開発のお仕事でお客さんのところに出張して商談をすることも多々ありました。ピーク時の月間勤務時間は3……おっと、誰か来たようだ…😅

▲"fail soft"
ここでは、病気でできなくなった業務と、引き続き実施可能な業務を、いくつか紹介します。
実施可能な業務だけではお金を稼げなくなった時、それが引退の時です。

▲正社員 vs 個人事業主 vs 法人設立 ： 病気というリスクに強いのはどれ？！
働く方法というのはご存知の通り複数あります。ネット上では金融・経済の観点からこれらの違いが語られることが多いですが、ここでは「病気の状態での働きやすさ」の観点から働き方を評価していきましょう。

▲FUTURE ～いまから、ここから～ ： 「私が居なくても事業が回るようにする」vs「私もお金を稼がないといけない && 転職激ムズ」
優秀なエンジニアは自分自身の仕事のゴールを「私が居なくても事業が回るようにする」に据える、なんてことが言われることがあります。私もそう思いますし、私が優秀なのかどうかはさておき、仕事上目指すのはここです。でも病気になって転職等が容易ではなくなった現在、自分自身の仕事を継続できる環境づくりも重要です。一見矛盾しているように見えるこれら2つの欲求に悩まされています。エンジニアとしての美しさと自分の稼ぎ口、これらを上手く両立するにはどのようにするのが良いのでしょうか？ 現時点の見通しをお話しします。

================================
★想定聴衆と得られるもの★
(AIではなく)生物である方々は皆さん大なり小なり何かしら病気のリスクを抱えている訳ですから、生物の皆さんがこの先生きのこるための人生設計をする上でお役に立てるだろうと思います。ただし私がITエンジニアということもあってそれに依存した話も多数含まれます。IT以外のエンジニアの皆さんにとってはあまり参考にならないかもしれません。という訳で生物のITエンジニアの皆さんに聞いて頂きたいです。

================================
★私がこれを話す理由★
病気になっても働きたい、ということは多くの人が思っているだろうから。

① 発表概要

「自分には、外に向けて発信できるような特別な強みなんてない」。そう思って過ごした時期が私にもありました。
40代、4度目の転職。コロナ禍で技術的な繋がりが絶たれた閉塞感の中、私の運命を変えたのは一つのOSSツール、そしてその作者という「推し」との出会いでした。
本セッションでは、地方在住・子育て世代のエンジニアである私が、いかにして40代から「OSSコミッター」「カンファレンス登壇者」「技術書著者」へと変貌を遂げたのか、その舞台裏を明かします。
キーワードは「推し」です。特定の技術や人、コミュニティへの情熱を、いかにして自身の成長サイクル（OSS貢献、登壇、フィードバックの循環）へ昇華させたのか。ライフステージの変化を「活動の制限」ではなく「好機の到来」と捉え直す考え方と、2026年という未来を自分らしく生き抜くための、泥臭くも再現性のある戦略をお伝えします。

② 発表の詳細

1. 「何者でもなかった」自分と、沈黙の数年間
かつてはメガベンチャーで社内発表などを経験していましたが、転職とコロナ禍が重なり、対外的な接点はゼロに。自分なりに社内でSlack Bot Officerを名乗るなどの活動はしていましたが、心のどこかで「外の世界で活躍するエンジニア」への憧れと、動けていない自分への焦りがありました。

2. 運命の出会い：OSSツール「runn」と作者k1LoW氏
転機は、一つのツールを「推し」始めたことでした。コードが追える規模だったそのOSSにPRを送り続け、気づけばコミッターに。さらに、チームメイトが繋いでくれた縁で作者のk1LoW氏とリアルで出会います。地方カンファレンスという「廊下」での熱い議論。その圧倒的な熱量に触れ、私のエンジニア人生は「再起動」ではなく、40代にして初めて「本格始動」しました。

3. 「推し」を追って全国へ：フィードバック・サイクルの構築
「推しに会いたい」「もっと話したい」という純粋な動機が、私を各地のカンファレンス登壇へと駆り立てました。

• 登壇することでFBを貰い、それを業務やOSS改善に活かす。
• 改善した取り組みをまたOSS化し、次の登壇ネタにする。
  この「推し駆動」のサイクルが、自分でも驚くほどの成長スピードを生み出しました。

4. ライフステージの変化を「味方」にする戦略
「若いうちに頑張らないと手遅れ」という言説がありますが、現実は違います。

• 子育てのフェーズ変化： 手がかからなくなった時間を自分の活動へ。
• 技術的障壁の低下： AIやDeepLの活用で、英語やコードの壁を突破。
• コミュニティの成熟： 地方カンファレンスの増加が、地方エンジニアのチャンスに。
  「今が一番動ける」という確信のもと、ライフステージに合わせた「戦い方」を選択する重要性を説きます。

5. 結論：推しは推せるときに推せ！
コミュニティも、憧れのエンジニアも、そして自分自身の「動ける状況」も、永遠ではありません。PHPカンファレンス福岡の節目に象徴されるように、機会は一期一会です。「FUTURE ～いまから、ここから～」のテーマ通り、何歳からでも、どんな環境からでも、熱量さえあれば未来は変えられる。本登壇を通じて、参加者の一歩を踏み出す勇気を後押しします。

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

• 想定する聴衆：

• 30代〜40代で、キャリアの停滞感や将来への不安を感じているエンジニア

• OSSやコミュニティ活動に興味はあるが、家庭や年齢を理由に一歩踏み出せずにいる方

• 「自分には語れるネタがない」と思い込んでいる若手エンジニア

• 得られるもの：

• ライフステージの変化をポジティブに捉え、活動に繋げるための具体的なマインドセット

• 「推し」という感情を技術的成長やキャリア形成に結びつける「推し駆動開発」のステップ

• アウトプットが次のアウトプットを呼ぶ、フィードバック・サイクルの作り方

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

私自身が、40代に入るまで「外の世界」とは無縁な、ごく普通のエンジニアだったからです。地方在住で子育て中という、一見すると「エンジニアとしての活動量が落ちる」はずの条件下で、なぜ今が人生で最もアウトプットできているのか。その実体験には、キラキラした若手スターエンジニアの言葉よりも、多くのベテランや悩める中堅層に響く「泥臭い真実」と「再現性」があると信じているからです。6年間の沈黙を破って「遅咲きのデビュー」を果たした私だからこそ、2026年のテーマである「いまから、ここから」を体現して伝えることができます。

発表概要
2001年、PlayStation 2全盛期。私はC++とアセンブラでハードウェアの限界に挑むゲーム開発者でした。しかし、ブロードバンドの普及とともに「Web」が世界を変えようとしていたその時、私は一つの決断を下しました。閉じたハードウェアの世界を離れ、PerlとPHPが支配するWebシステム開発の世界へ飛び込むことでした。

本発表では、メモリ管理とポインタ演算が全ての「硬い開発」から、テキスト処理の王様であるPerlと、爆発的に普及し始めていたPHPという「柔らかい（そして緩い）開発」へ移行した際の強烈なカルチャーショックについてお話しします。そして25年経った今、あの時学んだ「Webの基礎（LAMP）」とスクリプト言語特有の柔軟性が、現代のクラウド時代にどう活きているのか、技術の変遷を超えたエンジニアの生存戦略を共有します。

発表の詳細
本セッションでは、25年前のWeb黎明期の空気を振り返りつつ、ゲーム開発とWeb開発の狭間で見た景色をお話しします。

1. 25年前の決断：ハードウェア職人から、LAMPの住人へ 当時は「IT革命」という言葉が踊り、iモードが社会現象化していました。ゲーム開発現場ではC++による厳密なメモリ管理と、終わりのないデバッグの日々。 「このまま特定のハードウェア心中していいのか？」という危機感から、私は当時Webのバックエンドを支えていたPerl、そして新星のごとく現れたPHPの世界へジョブチェンジしました。

2. 黎明期IT業界への適応：型のない世界への戸惑い 転職先は、Linux、Apache、MySQL、そしてPerl/PHPで構成された、いわゆる「LAMP環境」でした。

「型」がない恐怖と快感: C++出身の私にとって、変数の型宣言がなく、いきなり使えてしまうPerlやPHPは「無法地帯」に見えました。「コンパイルエラーが出ない＝実行するまでバグが分からない」という恐怖。しかし、慣れてくると「書いてすぐ動く」という圧倒的な開発スピード（PDCAサイクルの速さ）に魅了されました。

Perlの魔術とPHPの実用主義: テキスト処理やバッチ処理ではPerlの正規表現が火を噴き、Web画面構築ではHTMLに直接ロジックを書けるPHPの生産性が革命的でした。

スパゲッティコードとの戦い: 一方で、当時のPHPやPerlはフレームワークも未成熟。「コピー＆ペースト」や「巨大なif文」が乱立する現場で、ゲーム開発で培った「構造化」のスキルをどう適用するか、泥臭い戦いがありました。

3. 伏線回収：25年間の生存戦略の答え 当時「所詮はスクリプト」と揶揄されることもあったPerlとPHPですが、この経験がその後のキャリアの土台となりました。

言語の壁を越える: C++（静的）とPerl/PHP（動的）の両極端を知ったことで、その後登場したPython、Ruby、Goなど、どんな言語が来ても「どちらかの系譜」として理解できるようになりました。

「厳密さ」と「柔軟さ」。
この両方の武器を持てたことが、四半世紀生き残れた最大の要因です。

想定する聴衆とその人たちが得られるもの
想定する聴衆
・昔からWeb業界にいて、PerlのCGIやPHPのレガシーコードと戦ってきた歴戦のエンジニア
・最新のモダンなフレームワークしか知らないが、Web技術のルーツや「生のHTTP/HTML」を扱う感覚を知りたい若手層
・jQueryはJavaScriptを楽にする魔法だよ

得られるもの
・技術の温故知新: Perl/PHPの黎明期を知ることで、なぜ今のフレームワークがこういう設計になっているのか（MVCの必然性など）が腑に落ちる
・適応力の実例: 異なるパラダイム（コンパイル言語 vs スクリプト言語）への移行プロセスと、そこから得られる複眼的な視点
・キャリアの自信: 「流行りの技術」が変わっても、「Webの仕組み」と「プログラミングの基礎」さえあれば25年戦えるという確信

なぜこのトピックについて話したいのか？
25年前、PerlとPHPは「Webを民主化」しました。誰でもメモ帳一つで動的なサイトが作れる——その敷居の低さが、現在のWebサービスの爆発的な発展の原点です。

PerlやPHPが教えてくれた「多少汚くても、動いて価値を出すものが偉い」というプラグマティズム（実用主義）に救われました。 「あの頃のコードはひどかった」と笑い話にしつつも、そのカオスの中から現代のWeb技術体系が生まれたことを伝えたい。 変化の激しい時代における最強の生存戦略であることを、迷えるエンジニアたちにメッセージとして届けたいと思います。