リーン開発は2008年頃から注目され、高い失敗率に悩むスタートアップ界に科学的アプローチによる解決策を提示し、現在でも非常に有効な手法です。しかし、AI普及によりプロダクトへ求める需要が変化し、開発スピードへの期待が急激に高まる中、この優れた基盤にプラス要素を加えた「半歩ずらし」のアプローチが求められています。
本セッションでは、リーン開発の本質的価値である「無駄の排除」と「科学的な仮説検証」を活かしつつ、AI時代にフィットする実践法を紹介します。大企業やスタートアップが基本的なAIサービスを日々提供する中で、PMFを確認するために何をプロダクトで作るべきか、作らないべきか。変化に対応するためにプロダクトをどう構築すべきか。
優れた従来手法をベースとした進化版リーン開発戦略を一緒に考えてみませんか。

概要

Cコンパイラと言えば、世界三大自作したいソフトウェアの一角ですよね。
せっかく作るならセルフホストくらいできてほしいものです。
そんなものを作るのは難しいと思われるかもしれませんが、実装する言語機能を適切に制限することにより、2000行弱で書くことができます。

話すこと

• コンパイラの基本構造
• アセンブリ言語基礎
• 簡易化のための実装上の工夫
• 一部言語機能についての個別の実装詳細
• ハマりポイント
• 言語処理系実装の楽しさ

話さないこと

今回作るコンパイラはC言語のソースコードからアセンブリ言語への変換をおこないます。アセンブラ・リンカは実装しておらず、トークの対象外です。

皆さんはSREを知っていますか？「うちのプロダクト、このままの運用で大丈夫かな？」と不安な方、そんな方は是非SREに触れてみてください！

本セッションでは"SREとは何か？"という説明を交えつつ、『Fansta』というスタートして間もないプロジェクトでSREポジションを立ち上げ、数年間で思案し実践してきたことをSREの始め方の一つの実例としてお伝えします。

■ お伝えする具体的なこと
　・ SREとは何か？
・ 運用開始したばかりのプロジェクトで何故SREが必要になったか？
・ SREポジションを立ち上げる際に考えたこと
・ 一人でSREを実行する際に考えなければいけないこと
・ 実際に３年半やってきて実現出来たこと/失敗したこと

■ 対象とする方
　・ SREを知らない方
　・ SREは気になっているけどまだチームへ導入できていない方

Copilot や Cursor など生成 AI の普及により、コードを書くコストは劇的に下がりました。しかし、出力されたコードのレビューが開発の新たなボトルネックになっています。AIの出力を日々ひたすらレビューをしていて、生成AI登場以前より大変だと感じる方もいらっしゃるのではないでしょうか。
そこで本トークでは、レビュー負荷を低減する試みとして「AI による仕様と実装の一貫性チェック」の検証結果を共有します。
まず、仕様と実装のズレの原因を「仕様の解釈ミス」「情報漏れ」などのいくつかのパターンに分類します。サンプルプロジェクトにそれらのズレを仕込み、Cursor等のコーディングエージェントがどこまで自動検出できるかを比較します。
トークを通じて、皆さんのプロジェクトでも一貫性チェックを組み込むべきか、その判断材料を提供します。

時代の移り変わりに伴い、当然、ソフトウェアの設計・開発手法も変化・進化が続いていきます。
当時の開発現場で妥当とされた、あるいはベターと判断された設計・開発上の選択が、今となっては技術的負債、忌避すべき一手に変わっているものも少なくありません。

このセッションでは、発表者が新卒後20年間Webシステム開発に携わる中で進めた「当時はよかれと思って選んだ設計・実装の判断」が、時を経て、どのような技術的負債や後悔を生んだのか、蔵出しできる範囲で赤裸々に共有します。

「こうなるとは思っていなかった」「当時に今の知識やノウハウがあれば…」「自分でも実はちょっとどうかと思ってた（けど仕方がなかったんだ...）」と感じた瞬間の数々を、皆さんと一緒に振り返りつつ、未来の自分や誰かが幸せに開発できるような選択のための勘所や視座を、少しでも皆さんとともに掴んでいける場にできればと思います。

Webフロントエンド開発では、そのほとんどがnpmモジュールを中心としたエコシステム上で今でも変わらず開発されています。
npmエコシステムにおいて重要なのが、依存解決（ディペンデンシィレゾリューション）と呼ばれるどのnpmモジュールを使うか、npmモジュール間の依存をどう整理して解決しているのかを決める処理です。

今回のトークでは、Webフロントエンド開発でもう１つ重要なnpmモジュールを１つのアプリケーションにまとめ配布可能な形にするバンドラーがどう依存解決をして、そのアプリケーションをバンドルしているか、バンドラーの気持ちになって依存解決（ディペンデンシィレゾリューション）を深ぼっていきます。

Webフロントエンド開発では、そのほとんどがnpmモジュールを中心としたエコシステム上で今でも変わらず開発されています。
npmエコシステムにおいて重要なのが、依存解決（ディペンデンシィレゾリューション）と呼ばれるどのnpmモジュールを使うか、npmモジュール間の依存をどう整理して解決しているのかを決める処理です。

今回のトークでは、Webフロントエンド開発の型システムを支える重要なライブラリであるTypeScriptがnpmモジュールの型解決をどう行い整合性をとっているのか、VSCodeの型補完Intellisenseはどう機能しているのか、d.tsとは何か？ TypeScriptの気持ちになって依存解決（ディペンデンシィレゾリューション）を深ぼっていきます。

CPUアーキテクチャの話って、難しそうで遠い存在に感じませんか？

macOSの歴史をたどると、そこにはCPUの都合・設計思想・気持ちが現れています。
本セッションでは、AppleがPowerPCからIntel、さらにApple Siliconへと至るまでのCPUアーキテクチャの変遷を軸に、各時代のOS設計やハードウェアとの関係性を探ります。

• なぜPowerPCではマルチコア・省電力が難しかったのか
• なぜIntel移行が行われたのか
• NeXTSTEPの精神とClassic Mac OSの“心”の融合
• なぜAppleは自前でチップを作る決断をしたのか

macOSの歴史を通して、CPUとお友だちになりましょう！

一生で一番大きい買い物
　　　
「家」

しかし、これは自分の一生を大きく左右するにもかかわらず
・専門用語が多く
・慣習慣例も多く
・提供元によってルールが異なり
・「やってはいけないこと」をやれてしまい
・決めなければいけない要素数が多すぎ
・しかも短期間で決めなければいけないタイミングが突然やってくる
・運要素もある

と、まじめに取り組めば子育てと並び生涯最高難度を誇るイベントといっても過言ではないでしょう。

ここで登場するのが生成AI。
膨大なルールをうまく取りまとめてわかりやすく説明することが得意です。
うまく使って一生のイベントを乗り切って後悔のない家づくりをする方法を皆さんと共有できればと思います。

深夜の静寂。ディスプレイの光だけが、顔を照らす。
以前に自分が書いたコードが、まるで他人の書いた暗号のように見える。
「ここを直したら、どこが壊れる…?」
震える指でコードを書き換え、動作確認を繰り返す。時間は溶け、自信は削られていく。

「単体テストを書く時間さえあれば…」
いつからかそれが僕の口癖になっていた。

でもある日、ふと気づいたんだ。
テストがないから、この恐怖が生まれる。テストがないから、この無駄な時間が生まれる。

…逆だったんだ、と。

このセッションでは、テストに守られた安心で高い生産性を誇る開発体験を無理なく獲得するための、明日からでも始められる3つの動機づけを皆さんに提案します。
将来、テストなしでどうやって開発してたんだろう、と思ってもらえるようになればうれしいです。

テストはコストじゃない。未来のあなたを、恐怖から解放するための翼なんだ。

※1 発表は英語で行いますが、字幕翻訳システムを活用して、発表を日本語翻訳できるよう準備中です。
※2 日本語での質疑応答やコミュニケーションについては、同席する日本人の同僚がサポートします。
　
このセッションでは、AIをフル活用してソフトウェア開発を一気に加速させる「Hypervelocity Engineering（HVE）」という新しいアプローチを紹介します。HVEは、企画から設計、プロトタイプ制作、実装、テストまで、開発のすべての工程にAIを組み込むことで、速さだけじゃなく、クオリティやビジネスへのインパクトも大きく高められます。最近話題の「Vibe Coding」との違いや、それぞれのメリット・デメリットを比較しながら、HVEがどう優れているのかをわかりやすく解説します。価値、コスト、スピード、失敗率といった観点から、実際の現場にどんな変化があるのかを紹介し、導入のためにまず何をすればいいのか、すぐに使えるヒントもお届けします。

Web/iOS/Androidのマルチプラットフォームで、女性専用SNS「tipsys」を8年前、「食品表示印刷」を5年前、業務用ワイン管理アプリ「winecode」を3年前から開発運営しています。

これらはいずれも、プライベートプロダクトとして開発運営をスタートし、ユーザーの声や運用の中でUI/UXを何度も見直してきました。今回の登壇では、特に「なぜUIを変えたのか」にフォーカスし、0→1の立ち上げフェーズで見えた課題、そして運用中に直面した“変えざるを得なかった理由”をお話しします。

「tipsys」で考えたゼロスタートのSNS、「食品表示印刷」での現場ユーザーの声、「winecode」での業務効率とのせめぎ合い。それぞれのアプリが抱えた背景とUIのアップデートを、数字やスクリーンショットとともにお話します。

[技術レベル]
不要です。