ソフトウェアエンジニア、特にWebエンジニアは若い職業で、若いエンジニアがどんどん活躍する業界です。
そんな中で50歳を超えたエンジニアはまだまだ少数派ですが、少しずつ増えてきました。

このトークは、YAPC::Hiroshima 2024では52歳を少し超えている予定の私が、50歳を超えてからキャリア・健康・マインドセットにどんな変化があったのか、これからどうしていくのかを、実体験もりもりでお話しします。

以下のようなキーワードに関連する内容を取り上げます。

• 老眼と更年期障害
• ライフステージとバーンアウト
• 結晶性知能と流動性知能
• プロティアンとモダンエルダー

データベースの寿命はアプリケーションより長い。
そんなサービスのコアにあるデータベースですが、日々進化しています。

NewDBと呼ばれる新しいデータベースソフトウェアの躍進が注目される中、多くの現場ではRDBMSを使っているのではないでしょうか？
そこで今回は、皆さんの身近にあるRDBMSのこれまでの進化と未来の姿を紹介します。

話すこと

• PostgreSQLの進化と便利機能
• ChatGPTに連携するためのベクトルデータ
• PostgreSQLの拡張の世界
• 明日から使えるPostgreSQLのTips

話さないこと

• MySQLをはじめとした別のRDBMSついて
• NoSQL、NewSQLについて
• データベース設計
• アプリケーション設計

テストコードを実装しない開発を当たり前のように行っていた組織が今日ではテストコード文化が醸成され、開発にテストコードを自発的に拡張していくようになりました。ここまで行ってきた数々の話をします。
PHPが多く採用されているプロジェクトで、個人の裁量程度で設けられていたPHPUnitのテスト。ローカルの実行方法でさえフローが浸透していなかった状態から、 全コードにテストコード設置を目指すために環境立ち上げからカバレッジやスキルを上げていった話、後にテストを整備したアプリケーションを立ち上げて開発や保守運用にどう影響を与えたか。
今ではエンジニア自身からテストを拡張し、実行環境、CI、スキル、体制構築と整備をアップグレードし続ける状態になってきましたが、そこまでに奮闘し、組織の考えや開発の仕方が変わってきた記録を話します。

皆さんは「無理」に挑戦していますか？

自身のキャリアとしても、自己実現しやすい環境、しづらい環境はあると思います。
例として「権限」が原因で「不可能」である状態です。
「自分で予算を管理してプロダクトやチームを運営したいなど様々な権限がある中で、
「権限がないからしょうがない」と捉えるのではなく、「権限をもらえるためにどう行動するか」や「権限がもらえる環境はどこか」を考えることが重要です。
なぜなら、この環境を受容してしまうと「権限がないので無理」と言う免罪符のもと働くことになり、いつしかこれが当たり前となり成長機会の損失につながる恐れがあるからです。

上記のように自身のキャリアとして、今の環境が本当に自身の自己実現に寄与しているのかを図るための指標として
「無理に挑戦できる環境か」
を提案させていただきたいです。

変化の速いスタートアップでEM (Engineering Manager) になった頃、組織課題を洗い出すため、以下に取り組みました。

・組織: 大規模スクラム (Scrum@Scale) の図をベースに組織構造を図化
・プロダクト: 複数マイクロサービスの相関関係を図化
・スキル: スキルマップ (星取表) でチームの強み・弱みを見える化 (Scrum Master の方がワークショップを開催)
・マネジメント: 上記を元にマネジメント領域ごとの課題をマインドマップ化

これらは「システム思考」でパターンを見出し、構造に働きかけるための土台作りでした。
そして、今追求している「プロダクト志向のエンジニア組織」の土台作りでもありました。

「システム思考」でどのように構造を見える化し課題を洗い出したか。
そして、どのようにエンジニア組織に改善策を適用していったかをお話できればと思います。

2019年の春、大学で情報工学を学ぶか、宇宙物理学を学ぶか迷っていた私が、入学後最初にしたことは、「Perl入学式 in 千歳」の門を叩くことでした。
Perlはもちろん、shellのコマンドもvimの使い方もほとんどわからなかった私が、歴戦のPerlエンジニアたちに囲まれ、はじめて聞く専門用語の波にもまれながら、プログラミングの楽しさを知りました。
私は今、新卒2年目のWebフロントエンドエンジニアをしています。Perl入学式ではありませんが、その後も様々な形の勉強会の主催などで、エンジニアのコミュニティ活動と関わり続けています。
あの日の行動が、出会いが、今の私のキャリアを作ったと確信しています。
あの日のPerl入学式が私のその後のキャリアにどのような影響をあたえてくれたのか、私にHello Worldを教えてくれたあの日の先生たちと、コミュニティへの感謝を伝えるためにお話します。

私たちエンジニアにとって、技術的な意見交換 (以下、これを「技術交流」と呼びます) はいつだって面白くて盛り上がることだと思います。
社内での技術交流であれば、社外公開のために気にするようなこともなく、気心の知れた仲間たちの間で盛り上がりやすいでしょう。社外に向けても技術交流できると更によいですね。
そんな技術交流を、「そそのかし」という観点からより盛り上げていくためのテクニックについてお話しします。

• 「そそのかし」について
• なぜそそのかすのか
• 実践「そそのかし」
  • 「やっていき」と「のっていき」
  • 場を探してくる
  • 場を作る

この発表が、技術交流の促進につなげられれば幸いです。

拡大した会社組織では、個々や組織の役割が専門化してしまい、その間で放置されてしまう課題が多く発生します。
そのような、役割の狭間に落ちたボールを拾い、解決のためにリードしてくれる人材はとても貴重です。
ですが、もしその人が会社を去ったり、他に優先すべき業務が発生したりした場合、課題解決の取り組みが途絶えてることは少なくありません。

バイセルではそのような課題解決を「ワーキンググループ」という少人数の横断組織でカバーしています。
これは、単に複数人で冗長化することでカバーしているというだけの話ではありません。
解決の取り組みを仕組み化し、改善のループを回し続けることで、最終的には組織文化へと昇華させ、リードする人間が不在となっても課題解決が持続することを期待しています。

本トークでは、バイセルでのワーキンググループの起こりから現在に至るまでの取り組み、成果、課題などについてお話しします。

トグルホールディングスは、「まちづくりのためのデジタルインフラ」と称して、不動産・建築・金融を一つにまとめた、新しいデジタル産業インフラを創ることに取り組んでいます。
複数の業界に横断するように表現していますが、ある市場領域に着目すると、これらは一つの産業であると言えます。
とりわけ技術が光る部分としては、不動産・建築であり、業界特有の専門知識が必要不可欠とする中で、ソフトウェアや、数学、AIを駆使して、新しい仕組みの確立に挑んでいます。
これらの取り組みについて紹介するとともに、新しいデジタル産業インフラが出来たのちに、私たちの生活にどのような変化が生まれていくのかについてもお話します。

昨今、スクラムに関する話題は尽きません。
様々な意見が飛び交いますが、2年間スクラムを実践してきた私が言います。
スクラムを取り入れただけでは輝かしいプロダクトは生まれません。スクラムはHOWです。

ではなぜスクラムなのか？
それは良いプロダクト作りをするための1つのフレームワークだからです。

しかしスクラムガイドや入門書だけでは形だけスクラムに陥りやすいです。（私もそうだった）
学習と実践を重ね、開発者/スクラムマスター/プロダクトオーナー、全ての役割を体験した私が「形だけスクラムにならない、良いプロダクト作りをしていくための話」をします。

話すこと
・形だけスクラム/陥るポイント
・スクラムイベントの深掘り
・他のアジャイル開発手法
・スクラムでプロダクト作りを円滑にするには

ターゲット
・スクラムを知っている方
・スクラムがしっくりこなかった方
・なんか話題のやつでしょ？な方

何らかの技術の理解を深めるのに、最も適した方法はなんでしょうか。
私は、その技術のサブセットを実装することだと信じています。
Perl、ひいてはプログラミング言語というものを理解するために、Perl 言語のサブセットを実装しましょう。
機能が少ない言語の言語処理系は、皆さんの想像よりも簡単に作ることができます。

話すこと

Perl で作る Perl 処理系（のサブセット）の作り方
必要なソースコードはすべて公開され、このトークを聞かれた方が同じものを作成できるように構成します。

話さないこと

以下は実用的な言語処理系を支える重要な要素ですが、このトークでは意図的に省き、より実装が簡易な手法で代替します。

• LR 法のような実用的な構文解析手法
• 仮想機械

皆さんは社会人１年目、どんなことを考えてお仕事されていましたか？また、今何のために、どんなお仕事をされていますか？
語弊を恐れず言うと私は、自分の幸せのため「だけ」に仕事をしています。

このセッションでは、（未来を切り開く）22歳の新卒エンジニアである私なりに考える、自分の幸せを構築するための「圧倒的自己中心的主義」と、そのために意識している３つのことについてお話しします。

話すこと

• 今はどんな目標のために、どんなことをしていますか？
• 自分の幸せを構築する「圧倒的自己中心的主義」のすすめ
  • 自己中心的主義を突き詰めることこそが、相手をも幸せにする最強の利他主義へ
• 私が意識している3つのこと
  • まずは与えられた環境で、仕事を全力で
  • いつでも好きなことをするための「プレゼンス」の高め方
  • いつまでも好きなことをするための「身体」の保ち方

「ここ数年、同じような仕事ばかりしていて、野心的な挑戦をできてない」
「プログラマ定年を迎えて、この先も生きていけるか不安」

こうした悩みを抱える方は少なくないと思います。
今回のトークでは、私自身が「開発もできるProduct Manager」になることを目指し、進んできたキャリアについてお話しします。

・決算書が読めないので、事業が儲かっているかわからない。
・機能開発の大きな裁量を任されたら、何から手をつけていいかわからない。
・取捨選択の判断基準がわからない。
・専門領域の異なる人とのコミュニケーションがうまくいかない。
・新規開発と機能改善の優先順位がうまくできない。
...etc

私が実際に直面した課題とそれをどう克服したかについて具体的にお話しします。
「エンジニアリング」と「プロダクトマネジメント」の掛け算で、皆さんが自身の未来を切り拓くヒントになれば幸いです。

FUN Developers Hubは、公立はこだて未来大学に多数存在する学生技術コミュニティの情報が集まるポータルサイトとして、学内の意欲ある学生たちの手によって約1年半前に開発が開始され、正式リリースに向けて開発が続けられています。

本トークでは、このサイトの開発の歴史を振り返りながら、

• このポータルサイトが変える学内技術コミュニティの「未来」
• 学生プロジェクトでの継続的な共同開発のもつ課題とその解決
• 必要十分で良い開発体験を提供する開発基盤
• このプロジェクトが目指す「未来」の学内技術コミュニティ

などについてお話します。

プロジェクトの立ち上げ・開発の停滞など、このプロジェクトの通ってきたさまざまな出来事や、このプロジェクトに懸けるアツい想いなどに触れながら、「未来」の学生技術コミュニティの情報基盤の姿をお見せできればと思っております！

Goは2012年に1.0がリリースされる際に後方互換を保つルールが設定され、毎年2回のペースで後方互換を維持したままリリースされています。またそれに加え、近年では互換を保ちやすくするための機能がいくつか導入され、当面は2.0がリリースされることはないとGoチームが明言しています。例えば、1.22ではfor文の仕様が変わりましたが、1.21ですでに導入されていた互換性の強化によって、破壊的変更には繋がらずリリースできました。

Goに限らず、ソフトウェアを開発する上で互換性を保つことは重要で、ちゃんと意識することで、大胆なアップデートやリリースを行え、よりユーザに高い価値を提供できます。

本セッションでは、Goがどのような意図で1つ1つの機能を積み上げて後方互換性を強化したのかを紹介します。Goに親しんでいる人やそうでない人も、一緒に後方互換性からプロダクトの未来を作る方法を学びましょう。

採用活動を行っている方にとって、優秀な学生や学生コミュニティとの接点を作ることは自社の採用活動を進めるための重要な課題の1つでしょう。また、学生コミュニティを運営している方にとって、コミュニティを持続可能にし、盛り上げるための方法を模索する場面は少なくないはずです。

このような課題を抱える企業と学生コミュニティが関係を築くことができれば、双方にとって継続的なメリットが生まれます。

ただし、そのような関係を一朝一夕に築くことは困難です。

本セッションでは、未来大在学時代に未来大の学生コミュニティを対外的に知ってもらい、盛り上げるために企業を巻き込んで取り組んだ経験や、企業に就職した後の私が採用活動や学生コミュニティと関係を構築するために取り組んだ内容を踏まえて、企業目線と学生目線の両方から企業と学生コミュニティの双方にメリットのある連携について紹介します。

私の所属するNekko Cloud Teamでは、VPNでメンバーの自宅サーバを接続し、プライベートクラウドを構築しています。
ProxmoxでIaaS環境を運用しているのですが、手作業でVMを作成する工程は冗長であり、時間のかかる面倒な作業でした。

そこで、我々は「VMを作成する工程」をトイルとし、VM用プロビジョニングツール「Terrakko」を作成しました。
今回は、Terrakkoプロジェクトを通して、Nekko Cloud TeamにPlatform Engineeringという考え方をもたらす過程を紹介します。

アジェンダ：

• Proxmox VEのVM構築
• Terraformとcloud-initでVM構築を自動化
• IaCツールの導入とFB
• メンバーの認知負荷を下げる工夫
• Terrakkoの仕様設計
• Terrakkoの導入とFB
• おわりに

Rubyはバージョン3.2以降YJITと呼ばれるJIT実装が追加されています。
YJITはRubyのJIT実装としては完成度が高く、実際のプログラムも高速化でき、数%〜数十%の高速化につながります。

発表者はRubyコミッターであり、RubyのXML実装の1つであるREXMLにコントリビュートしています。
REXMLは全体がRubyで書かれているため、YJITで大いに高速化されます。
これは、他のXML実装であるNokogiriがC拡張で、YJITの恩恵をあまり受けられないのとは対照的です。
しかし、REXMLへの修正によっては、YJITを有効にしても高速にならないことや、遅くなってしまうこともありました。

この発表では、RubyのJITの仕組みや、JITのために望ましいコードの書き方など、JITという未来の技術を活かすための知識をみなさんに伝えたいと思います。

自分が初めてPerlに触れたのは、大学での研究室配属に際して出された事前課題でした
確か、類似画像検索システムの構築をするお題で、何らかのスクリプト言語を使用することが条件で、これがPerlとの最初の出会いだったと思います
つまりは、自分のエンジニアとしてのキャリアの起点がPerlといっても過言ではない、ような気がしています

そこで本講演では、エンジニア・リサーチャーとして、大学での3年、企業での7年間のキャリアを積み重ねて、今年でちょうど10年目を迎えるということもあり、これまで携わった研究開発事例を増し増しで、その時に利用した技術スタックベースに振り返りをします
具体的には、生成AIや以下を含む事例について言及します

・ノーコード時系列データ分析ツール：https://nodeai.io/
・ドラレコ映像解析：https://iotnews.jp/maas-case/108219/

約5年間、建築系のSaaS 企業でVPoEとして勤務しました。その間、プロダクションコードは一度も書かず、コード修正は利用規約の修正などの文字列変更のみ。そんな人間が5年振りにSREの現場に戻ってコードを書くようになりました。5年振りに現場に戻って感じたことや進化したなと感じる事を伝えたいと共に、5年ぶりに現場に戻ったからこそ感じるこの先のエンジニアに必要なことをお伝えできればと思います。