プロポーザル

■発表概要
エンジニアにとって「評価」は、「主観的で不透明なブラックボックス」になりがちです。これが個人の成長を妨げ、組織への不信感を生むバグとなります。
本セッションでは、評価者の感情を徹底的に排除し、エンジニアが納得せざるを得ない「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エンジニアの皆さんに聞いて頂きたいです。

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

5年前まではエンジニアとして特に対外的な活動を行ってこなかった、いわゆる「何者でもなかった自分」。
しかし、推しと出会い、推し活動を続ける中で、

• コミッターになる
• カンファレンスで登壇する
• 薄い本を出す

など、エンジニアとしての幅が広がりました。
振り返ってみると、アウトプットのモチベーションにはキャリアやライフステージの変化が大きく影響していたと感じます。
本セッションでは、私自身の経験を交えながら、エンジニアの生き残り戦略とキャリアやライフステージの変化への向き合い方についてお話しします。

発表概要
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技術体系が生まれたことを伝えたい。 変化の激しい時代における最強の生存戦略であることを、迷えるエンジニアたちにメッセージとして届けたいと思います。