トーク

私の所属する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
• おわりに

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

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

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

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

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

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年ぶりに現場に戻ったからこそ感じるこの先のエンジニアに必要なことをお伝えできればと思います。

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

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

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

[概要]
生成AI市場は非常に変化が早く高速なデリバリーが求められる環境下のため、必然的に開発速度の向上を目指す必要があります。
そのため弊チームでは、より良いものを取り入れるための技術選定の工夫や、エンジニアがより開発のしやすい環境を整えるための取り組みを積極的に行なっています。

そんな0->1の新規サービスの開発チームで、エンジニア一丸となり様々な取り組みを始めてから約1年経ちました。
(3ヶ月時点での記事: https://zenn.dev/aishift/articles/ce9783a0d7acd0)

[話すこと]
下記の事柄について良かったこと、つらみを沢山話します。

• 頻繁に変化する仕様とそれに耐えうる設計
• 新しいものを積極的に取り入れた技術選定とその後
• バックエンド/インフラのアーキテクチャとつらみ
• 実際開発体験どんなもん？

業務に関する大規模ソースコードから趣味レベルのものまで、基本的に全ての開発作業をNeoVimで行っています。
LspやDap、FuzzyFinder等々の機能を自前で入れる必要があるNeoVimですが、それ故の良さに「カスタマイズ性の高さ」があります。要は自分が求める機能を自分で実装できます。
今回はNeoVimをさらに強化する為にIDEであるIntelliJを実際に使用したりVimMasterの動画を見て便利機能を取り込んだ話や、なぜ自分で実装する工数を使ってまでNeoVimなのかについて話すセッションになります。

また、Vim系エディタでチーム開発を進める上で重要になるのがTUI（terminal User interface）の話です。
最近の「Rust製」の勢いを踏まえて、VimやTUIを活用した「Terminal IDE」（個人的命名）についても話します！

本トークでは、私たちが Architecture Decision Record (ADR) を導入してからの 3 年間の経験と学びを振り返ります。今では社内の複数の開発チームに導入されている手法です。
ADR を導入する前の期待と、実際の成果、また運用中にどのような課題が生じ、どのように対処してきたかを共有します。

• ADR 導入の背景と目的
• ADR 運用の実践
  • ADR のテンプレート
  • 記録のツールやプロセス
  • チーム内でのレビュー方法や共有方法
• ADR の成果
  • 意思決定の記録が残ることの意義
  • コミュニケーション面の改善
• 直面した課題と解決
  • いろいろある
• 今後の展望

ADR を運用してきた実際の経験を共有することで、ADR の運用に対する理解を深め、他の開発チームが同様の手法を導入する助けになることを目指しています。

今から約50年前、カール・ヒューイットによって提唱されたアクターモデルは、
50年の時を経て再び現代のシステム設計において世界中で脚光を浴びています。

このセッションでは、まずアクターモデルの歴史的背景に触れ、その基本的な考え方を理解しながら、
50年後の現在において、当時の並行計算の限界を克服するための革新的なアイデアが、
どのように現代の複雑なシステムにおいて役立っているのか、どのような影響を及ぼしているのかを探ります。

アクターモデルの歴史的背景から現代への応用までの道のりを、
まるで未知の大陸を再発見する旅のように感じ、
過去の知識を新たな視点で理解し、未来のシステム設計に活かすための冒険に一緒に出かけましょう。
この旅を通じて、アクターモデルの奥深さと、その持つ無限の可能性に触れることができれば幸いです！

AWSにおいて「サーバーレスアーキテクチャ」は非常にメジャー、かつ多くのアプリケーションで採用されいるアーキテクチャです。
そしてその中核を担っているのはAWS Lambdaで、数多くの処理をLambdaで行っていると思います。

しかしその結果、Lambdaの数が膨大になり、金銭コストや単体テストなどの管理コストが負担になってしまうという問題もあるのも事実です。

そこでこのセッションでは「Lambdaレス」という、「あえてLambdaを使わない」というサーバーレスアーキテクチャを紹介するとともに、
「Lambdaレス」を採用することでどのようなメリットがあるのか？逆にどのような点がデメリットなのか、そして「Lambdaレス」のユースケースは？などをお話ししたいと思います。

また、もちろんAWSだけではなく、AzureやGoogle Cloudにも適用できる内容になります。

CloudbaseではCNAPP(クラウドネイティブアプリケーション保護プラットフォーム)製品を提供しており、発表者も日々脆弱性スキャンの機能を開発運用しています。
このセッションでは一般的にtrivy、vuls、syft/grypeなどに代表される脆弱性スキャナのソフトウェアのバージョンから脆弱性データベースを突合し、ライブラリやパッケージの脆弱性を検知する仕組み、実装方法を解説します。

話すこと

• 脆弱性データベースについて
• 脆弱性スキャナの仕組み、作り方

昨今、政治資金に関する問題が世間を賑わせている。政治資金に関しては我が国に政治資金規正法という法律があり、これに基づき政党や政治家個人の政治資金の支出入はすべて政治資金収支報告書という形で総務省のHPなどで多くが公開されている。しかしその中身は紙の書類をスキャンしただけのPDFデータで、政治資金の詳細な集計や分析は困難な状況となっている。

この問題を解決するために発表者は趣味のプログラミングの一環として、オープンソースのOCRエンジンなどを用いて政治資金収支報告書の解析・分析プログラムを実装し、これらを最終的に【政治資金データベース】というWEBサービスの形にまとめて公開した。
本発表では政治資金の問題の背景や先人たちの取り組み、そして政治資金データベースの今後の開発の方向性やプロジェクトのオープン化、コミュニティー活動化の可能性を探り、実現したい未来の政治活動や政治資金の姿を示したい。

マネジメント未経験から20人ぐらいの開発組織のCTOになれた経験を通じて、将来、CTOやEMを目指す方が「自分でもできるかも？」と思ってもらえるような内容をお話しします。

コロナ禍に社会人になり今年で5年目です。
キャリアの半分以上をCTOとして過ごしてきているので技術以外ゼロからのスタートでした。
そんな僕でもマネジメントを学び、採用を学び、リファラルで集まった数名の開発組織から20人ほどの開発組織にまで成長させることができました。
その経験を経て学ぶべきことやマインドについてお伝えします。

下記のような内容を具体的にはお話ししようと思っています。

• コミュニティに入っていろんな人と仲良くなる
• CTOの師匠となる人を見つける
• マネジメント研修を受ける
• 採用は採用が詳しい人に聞く
• 苦手意識があることも全部やってみる

動画配信サービスには、ユーザーが快適に使用するための多くの工夫が凝らされています。再生ボタンを押してからの素早い再生、効率的な動画のエンコード処理などがその一例です。今回、自宅サーバーで1から個人開発した動画配信サービス「YuoVision」では、これらの課題に取り組みました。

この発表では、本サービスの作成において工夫した点や苦労した点についてご紹介します。

対象者

• 動画配信の仕組みに興味がある方
• 動画処理技術に興味がある方
• 本サービスの運用体制や開発体制に興味がある方

エンジニアがフルスタックに開発するだけではなく、デザインやビジネスの領域に越境して顧客課題を中心に開発することでプロダクトの提供価値は飛躍的に向上します。
本トークではプロダクト志向を持つエンジニア達が未来を切り開くために「プロダクトエンジニア」という向き合い方を紹介します。
日本で最もデジタル化の遅れた物流産業で業務系SaaSのPMFをするまで試行錯誤を含めてプロダクトエンジニアの開発方法を説明します。
これにより、多くのエンジニアが事業の成功や顧客の喜びの声を得られるようにすることを目指します。

お話しすること

• プロダクトエンジニアの役割
• 活躍するための５つのコンピテンシー（好奇心、越境、仮説思考、アンラーン、オーナーシップ）
• プロダクト価値を上げるための組織設計、技術選定、開発プロセス
• プロダクトエンジニアコミュニティの立ち上げ

新規事業や新規プロジェクトは多くの会社が取り組んでいると思います。
私はエンジニアとして、テックリードとしてなど役割を変化させつつ事業やプロジェクトに関わってきました。
その中には立ち上がってすぐに撤退したものや、プロトタイプの時点で終わったもの、構想だけで終わったものなどもありました。
今回は、過去の異なる失敗の中で自分が悩み学んだことから何を次につなげて今どのように新しい事業に挑んでいるのかをお話ししたいと思います。

あなたは最近「顧客提供価値が大事」とかいう言葉のもとに、新しい技術や攻めた設計をあきらめていませんか？
私たちエンジニアにとって、顧客の要望に応えることはもちろん重要です。
しかし、それが理由で自分たちの技術的な理想を諦めるべきなのでしょうか？
私はそうは思いません。

このセッションでは、誰になんと言われても「いい開発環境」を作りたくて頑張っている私の取り組みと、その成果についてお話しします。
このセッションを通じて、最新の技術トレンドを追いかけることと、堅牢な設計を維持することのバランスをどう取ってきたか、そしてそれがチームやプロジェクトにどのように役立ったかを共有します。

このセッションで触れる内容
・devcontainersを活用した開発環境構築
・PlanetScaleなどのサーバーレスDB
・なにより「エンジニアにとって楽しいことってなに？」ということ

Ruby on Railsがリリースされたのは2004年。Perlで馴染みのあるCatalystは2005年です。かたやNext.jsは2016年。では、今、Webフレームワークを作るとしたらどのようなフレームワークをつくるでしょうか？

僕にとってその答えがHonoです。実はHonoはPerlのMojoliciousから強く影響を受けています。一方で強力なTypeScriptサポートやReact互換を入れたりと攻めています。

今回はHonoを題材に、この時代にWebフレームワークを作るとしたら過去から何を学び、未来に何を提案できるのかを考えます。

• Web StandardsとPSGI/Plack
• ORMはいるのかどうか
• バリデータを移譲する
• ミドルウェアとヘルパー
• 型をRPCとして使う
• Rooter::Boomは速い
• テンプレートエンジンの代わりにJSX

皆さんモブプロやってますか？私の所属する企業では週に2,3回モブプロを行っています。
主な目的は以下の3つです。

1. チーム内のコミュニケーション量の増加
2. 技術の共有
3. プロダクトの仕様の共有

それぞれを簡単に説明すると、
1つ目はフルリモートなのでコミュニケーション機会を増やしたい
2つ目は技術力に幅のあるチームなのでモブプロを通して技術の共有をしたい
3つ目は関わっていないプロダクトの仕様を知る機会を作ってサービスの全体を把握したい
ということを目的としています。

一定の効果を感じ、1年以上継続して行っております。
これらの詳細について、お話しさせていただきます。