トーク

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

バックアップはITシステム運用の基礎中の基礎です。本セッションでは、バックアップの重要性と基本的な概念から、効果的なバックアップ戦略の立案と実施までを解説します。初めてバックアップに取り組む方や、現在のバックアップ方法に不安を感じている方に最適です。本セッションでは実際の事例を交えながら、バックアップの失敗談とその回避策についても触れ、参加者が直面しがちな課題に対する具体的なアドバイスを提供します。セッション後には、信頼性の高いバックアップ戦略を立案し、実行するための自信を持てるようになることを目指します。

内容

• バックアップの基本概念：何をバックアップするべきか？
• バックアップの種類：フルバックアップ、増分バックアップ、差分バックアップの違い
• バックアップのスケジュールと保管方法：適切な頻度と保管場所の選定
• 復旧手順：バックアップデータを利用したリカバリの基本ステップ

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

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

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

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

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

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

現代のソースコードのエラー分析やフォーマットなどの機能はその多くがエディターの拡張機能ではなく、LSP(Language Server Protocol)を介して言語サーバーと通信することで実現しています。
これにより1つの言語サーバーから、様々なエディターでその言語のコード記述の支援機能を提供しています。
言語サーバーは開発しやすさや利用者の開発環境の状況からTypeScriptで書かれることが多いですが、LSPに沿ってさえいればPerlでも実装することができます。

本セッションではPerlを使ってVSCodeで動くPerlの言語サーバーを実装する方法をお話しします。

対象

• 言語サーバーを作ってみたい人
• Perlを触るのが初めての人

話さないこと

• Perlの厳密な文法

プログラム上で非決定的な要素、例えばPromiseなどを扱うことは多いでしょう。非決定的な要素は扱うのは難しい印象がありますが、一方で現在から続いている未来の可能性とも理解できます。この可能性を継続渡しという手法でプログラム上で表現できます。

このセッションでは継続渡しという関数型プログラミングの考えを始めから解説し、try ~ catchやパターンマッチングの面白さを伝えます。また、デザインパターンとの比較を交えつつ、その特徴を探っていきます。

特に初心者の方に、プログラミングで表現できることの広さと、日々の業務では遭遇しないコードを味わっていただけるお話をします。

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

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

話すこと

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

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

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

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

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

perlbrew の開発者です。

perlbrew 1.0以降の未来の世界について紹介します。今までの機能は守りの上、様々の開発環境に合わせるようになる perlbrew は、今回パッケージングツールになります。

perl は十徳チェーンソーと呼ばれであれば、perlbrew はその名に負けないぐらいの機能を持ちべき。あらゆるの方向に進行し、いよいよ環境構築の万能ツールになります。

はったりもあるかも知れないが、未来の話には楽しんでください。

Slide => https://hackmd.io/@gugod/rkPZyOotA#/

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

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

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

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

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

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

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

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

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

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という未来の技術を活かすための知識をみなさんに伝えたいと思います。

本トークではサーバーコンポーネントなど新しい概念が登場しているフロントエンドの今について紹介し、それを元に未来について考えたいと思います。

個々のトピックの技術的な内容についても触れますが、それらがなぜ登場しどういった問題を解決しようとしているのかについてを取り上げることで、フロントエンドの今とこれからについてを「点ではなく線」で捉えられるようになることを本トークの狙いとしています。

取り上げるテーマとしては

• サーバーとフロントエンドの関係はどうなっていくのか
• バンドラが果たす役割
• エコシステムの変化
• Reactの次
• フロントエンドとは何を指すのか
  辺りを想定しています。

フロントエンドエンジニアで普段触れている技術を俯瞰的に捉えたい方や、フロントエンドエンジニアではないけどフロントエンドの最近の技術や変化を把握したい人にとって役に立つ内容にしたいと思います。

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

本セッションでは、分散システムのような複雑な仕様や動作を持つプログラムに対して、様相論理を用いてその仕様を記述し検査する技術について解説します。

我々はシステムの仕様を保証する際、テスト設計や自動化ツールのような、仕様を「テストする」ための方法論を考えがちです。しかし、その前に仕様が「記述できる」ことが前提であり、これは決して自明ではありません。例えば、分散システムに対して「一部のサーバが落ちてもいつか回復する」といった性質なんて一体どうしたら表現できるのでしょうか？

複雑なシステムの仕様を考える上で、自然言語による曖昧性を排した「共通言語」を定義したいという動機は、古くから現在に至るまで、研究と実用が交わる大きなテーマの一つであり続けています。本セッションではこのような「共通言語」としての様相論理について、自分では手を出しづらいあなたのために、しかしできるだけ誤魔化さず解説します。