■ 1. 概要・問題意識
- 発表者: 和田卓人（@t_wada）、2025/05/14
- JavaScript fatigue（変化が速すぎるフロントエンドのキャッチアップに疲れる）と AI fatigue（AI周りのキャッチアップに疲れる）が背景にある
- 「限界集落」として停滞し若者のいないプロダクトと、変化が速すぎて疲弊するプロダクトの極端なコントラストが存在する
- 核心的問題: 重要な変化と重要でない変化を見分けられない
- 軽微な変化をスルーできずに消耗する
- 重要な変化をスルーして先行者利益を取りこぼす
■ 2. 変わるものと変わらないものの基本的な考え方
- 変化が予想できないことだけは予想できる
- 技術の歴史から学び、近未来の予測を試みる
- 近未来より先は予想しようがないので、身軽であることが最大の備え
- 技術の変化の歴史は一見すると振り子に見えるが、実は螺旋構造であり同じところには戻ってこない
- 差分と、それを可能にした技術が重要
- 技術の世界は基本的に若者有利であり、螺旋の差分が見えるのがベテランの数少ないアドバンテージ
■ 3. 変わらないもの: 長生きしている技術に学ぶ
- 長生きしている代表的技術: Unix、REST/Web、RDBMS/SQL
- Unix哲学:
- Small is Beautiful（小さいのは良いことだ）
- 一つのことをうまくやる（Make each program do one thing well）
- KISS（Keep It Small and Simple）
- すべてはファイルであり、そのほぼすべてがプレーンテキスト
- プログラムは標準入力と標準出力でプレーンテキストを扱うフィルタ
- 成功失敗は終了ステータスで示す
- パイプを介して40年前のコードと今書いたコードがあっさりと連携できる
- REST/Web:
- すべてはURLで示されるリソース（Adressable）
- 少なく、統一された振る舞い（HTTP Method, Uniform Interface）
- 状態を持たない（Stateless）
- ハイパーリンクで状態遷移（Connectedness）
- 多様な名詞と少ない（制約のある）動詞
- 良くできた分散システムとしてのWeb
- RDBMS/SQL:
- 強固で数学的な背景を持つ閉じた系
- すべてが関係/集合（テーブルも、クエリの結果も関係/集合）
- 少なく、統一された操作（SELECT, INSERT, UPDATE, DELETE）
- SQLはRDBMSだけのものではなくなった
- 技術の螺旋はNoSQLを回りNewSQLへ
- 3技術に共通するもの: 制約がもたらす共有と相互接続性の高さ
- インタフェースが狭く限定的
- 振る舞いの種類が少ない
- 実装に依存しない
- 接続と再利用が時間をまたいでいる
- 「すべては○○○である」という抽象化と閉包性:
- Unix: すべてはファイルとフィルタである
- REST/Web: すべてはリソースである
- RDBMS/SQL: すべては集合である
- 閉包性とは結果も○○○に閉じるような系の強さであり、ファイルの中身とコマンド実行結果の同一視、SQLの結果とテーブルの同一視がその例
■ 4. 変わるもの: アーキテクチャの螺旋の例（7つの時代）
- クライアント・サーバー時代（1990年代前半〜2000年）:
- LAN上でのClient/Serverアーキテクチャが確立（TCP/IP、NetBIOS）
- 2層アーキテクチャ（クライアントがUI担当、データベースサーバーがデータ保存・処理）
- Visual Basic（VB）やDelphiがビジネスアプリ開発の主流に
- 課題: デプロイの複雑さ、スケーラビリティの限界、ビジネスロジックの分散による保守性の低下、ストアドプロシージャの移植性の課題
- 初期WebとエンタープライズJava時代（1995年〜2004年）:
- PHP、ASP、JSP、Java Servletなどのサーバーサイド技術が急速に発展し動的なWebページ生成が可能に
- J2EE、EJBといった企業向け技術スタックと、XML、SOAPプロトコル、WSDLの標準化
- SOA（Service-Oriented Architecture）の考え方が広まり再利用可能なサービスコンポーネントの概念が確立
- 以前の課題の解決: デプロイの複雑さの解決（ブラウザベースへ移行）、スケーラビリティの改善（3層アーキテクチャ）、ビジネスロジックの集約、移植性の向上
- 新たな課題: ユーザー体験の制限（完全リロード）、ステートフル設計の課題、クライアント側の表現力の限界、エンタープライズ開発の複雑性（XML設定の複雑化）、SOAの重量級実装（ESBが複雑で運用コスト高）
- 動的WebとREST APIの台頭期（2004年〜2010年）:
- Ajaxがきっかけになりボタンで JavaScriptの再発見につながる（2005年）
- Adobe FlashやMicrosoft Silverlightなどのプラグイン技術によるリッチインタフェース
- Ruby on Railsが「設定より規約」を提唱し、開発者体験（DX）という概念の先駆けに
- RESTful Web設計の理解が広まり、Rails以後のフレームワークによる事業の早期立ち上げが可能に
- 以前の課題の解決: Ajax非同期通信でページ遷移問題の解決、jQueryによるDOM操作の簡素化、開発生産性の向上、ステートフル設計の課題緩和
- 新たな課題: ブラウザ間の互換性の問題（IE vs. 他ブラウザ）、JavaScriptの構造化標準の不在、セキュリティ懸念（XSS、CSRF）、プラグイン依存、インフラ調達・運用の硬直性
- モバイル&クラウド革命期（2008年〜2015年）:
- iPhone（2007年）とAndroid（2008年）登場によるモバイルアプリ開発の新時代
- RESTful JSON APIの一般化とXMLからJSONへのデータ形式の移行
- APIファーストの考え方の普及とフロントエンド/バックエンド分離の明確化
- AWS、Azure、Google Cloudなどクラウドプラットフォームの台頭
- NoSQLデータベースの台頭による大規模データ処理と水平スケーリング
- IaC（Infrastructure as Code）の普及（PuppetやChefなど）
- 初期SPA（Backbone.js 2010年, AngularJS 2010年）の登場
- 以前の課題の解決: プラグイン依存からの脱却（HTML5へのシフト）、レスポンシブWebデザインによるマルチデバイス対応、クラウドによるオンデマンド消費へのシフト、水平スケーリングモデルの実現
- 新たな課題: モバイルプラットフォーム間の互換性の欠如（iOS/Android個別開発）、REST APIの設計と管理の複雑さ、REST APIのフェッチング問題（オーバーフェッチング・アンダーフェッチング）、クラウド環境での運用・デプロイの複雑さ、環境依存性の問題、アプリ審査プロセスのボトルネック
- モダンWebフロントエンド期（2013年〜2018年）:
- React、Angular、Vue.jsなどモダンJavaScriptフレームワークの登場
- VDOMによるDOM操作の効率化と宣言的UIプログラミングの実現
- コンポーネントベースアーキテクチャによるUI再利用性と保守性の向上
- HTML5の標準化（2014年）とPWA（2015年）の登場によるネイティブアプリに近い体験の実現
- Node.jsとnpmの普及によるフロントエンド開発ツールチェーンの強化
- TypeScriptの成長による大規模フロントエンド開発での型安全性の向上
- BFF（Backend For Frontend）パターンの普及
- GraphQL（2015年オープンソース化）によるクライアント主導のデータ取得パラダイムの登場
- 以前の課題の解決: SPAによるページ遷移なしのシームレスなインタラクション実現、ES6の標準化とCJSバンドラーによるJavaScriptの構造化・モジュール化手法の確立、GraphQLによりREST APIのフェッチング問題を解決、アプリ審査プロセスのバイパスが可能に
- 新たな課題: フレームワークとツールの急速な変化（JavaScript疲れ）、初期ロード時間の長さ（バンドルサイズ肥大化）、SEO対応の難しさ（クライアントサイドレンダリング）、状態管理の複雑さ（Reduxなどのボイラープレートコード）、APIの設計と統合の複雑化、ビルドプロセスの複雑化
- マイクロサービス&分散システム期（2014年〜2020年）:
- NetflixやAmazonの成功事例に基づくマイクロサービスアーキテクチャの定義化と普及
- Docker（2013年）とKubernetes（2014年〜）によるコンテナ化とオーケストレーションの標準化
- Terraform（2014年）登場によるクラウドインフラのプロビジョニング自動化
- OpenAPI/Swagger、gRPCなどAPI設計・ドキュメント化ツールの普及
- DevOps文化とCI/CDの普及: 開発と運用の融合、自律的な小規模チーム編成、継続的な自動デプロイの標準化
- ドメイン駆動設計（DDD）と「逆コンウェイ戦略」によるビジネス変化への迅速な対応とチーム自律性の両立
- 以前の課題の解決: マイクロサービスによるドメイン分割とチーム自律性の実現、Dockerコンテナによる「開発環境と本番環境の一致」の実現、Kubernetesによるコンテナオーケストレーションの標準化、OpenAPI/Swagger・gRPCによるRESTful API管理改善
- 新たな課題: 分散システムの複雑さ（結果整合性、サービス間連携、トランザクション管理、障害検出の困難さ）、開発者の認知負荷の増大（クラウドネイティブ技術、Kubernetes、CI/CDなど多数のツールの習得と管理が必要）
- 再統合と最適化模索期（2020年〜）:
- マイクロサービスからモジュラモノリスへの揺り戻しと適切なバランスの追求
- プラットフォームエンジニアリングの台頭
- NewSQLデータベースの実用化と普及（分散環境でもSQLとACID特性を提供）
- JAMstack（JavaScript、API、Markup）アーキテクチャによる静的サイト生成とクライアントサイドの動的機能の組み合わせ
- Core Web Vitalsの標準化によるユーザー体験指標に基づく最適化
- アイランドアーキテクチャによる部分的ハイドレーションと最適なJS配信
- エッジコンピューティングの台頭によるCDNから計算処理への発展
- WebAssembly（Wasm）の登場と広がり
- React Server Componentsによるクライアントとサーバーの境界再定義
- 以前の課題の解決（現在進行形）: マイクロサービスとモノリスの中間の探求、NewSQLデータベースによる分散環境でのACID特性の実現、レンダリングパラダイムの再進化（クライアント・エッジ・サーバーの適切な役割分担）、プラットフォームエンジニアリングによる開発者向け内部プラットフォーム（IDP）の構築、AI支援型開発ツールによるコード生成の登場
- 新たな課題（生煮え）: 既存マイクロサービスシステムから新たなアプローチへの移行の複雑さ、フロントエンドとバックエンドの境界のあいまい化による責任分界の再定義の必要性、エッジコンピューティングとサーバーレス技術の最適な組み合わせの模索、WebAssemblyの適切なユースケースの見極め、AIとの共存による開発プロセスとスキルセットの再定義の必要性
■ 5. 技術の螺旋の具体例: 集中と分散の循環
- 集中・シンプル（初期Web）→分散・複雑（エンタープライズJava/SOA）→集中・シンプル（動的WebとREST API/Rails）→分散・複雑（マイクロサービス）→再集中・シンプル（モジュラモノリス）という螺旋
- 初期WebからエンタープライズJava/SOAへ向かった理由: 初期WebのシンプルなモノリシックなアプリケーションはSpring規模のエンタープライズアプリケーションに必要な再利用性・スケーラビリティ・分散トランザクションを扱う能力に欠けていた
- 動的Web/RailsからマイクロサービスへRails移行した理由: Railsなどの集中アーキテクチャはスタートアップ期には理想的だったが、事業規模の拡大とともに組織スケーリング・チームの自律性・優先的スケーリングの課題が生じた
■ 6. Game Changerたち
- 決定的な違いをもたらした技術: Ruby on Rails、Cloud Computing、Smartphone、Docker、React、LLM・Agentic Coding
- 量的な変化が質的な変化をもたらす:
- Railsの生産性はスタートアップ企業に必要な初期速度と仮説検証を可能にした
- クラウドはシステム開発のコスト構造やボトルネックを大きく変え、開発と運用の関係の変革を促した（DevOps）
- DockerはコンテナStartupの圧倒的な速さと再現性の高さでコンテナ時代の扉を開いた
- LLMの出現自体が量的→質的変化であり、結果出現した世界も量的→質的変化
- 圧倒的な安さ/早さ/速さの獲得で不可能が可能になり、新たなものが見えてくる
- 考えることを大きく減らした変化:
- ReactによりVDOMで富豪的にデータを更新してもレンダリングコストの心配をしなくて良くなった
- データ更新の方向が一方通行なので状態が一意に定まり混乱しない（Single source of truth）
- チャット型AIは一手目を考えるコストを劇的に下げた
- スルーするか、しないかの判断基準:
- Game Changerそのものを採用する必要は必ずしもないが、それらが変えた後の世界は知っておく必要がある
- 開発に関わる労力（コスト、心的コスト）を矢印で表した際に、矢印を圧倒的に短くしてコスト構造を大きく変えるもの、あるいは矢印を折るようなジャンルそのものを不要にするものはスルーしがたい
- そこまでではない変化は「お好みで」となる
- その技術が何のために出てきて、何をどのくらい変化させるのか見切れればスルーできる
■ 7. LLMとAgentic Codingはスルーできない
- LLMはスルーできない:
- 今まさに世界を不可逆に変えているGame Changer
- 人間とAIが互いの強みを活かし、協力して新しい価値を創造する
- 道具としてのLLM、壁打ち相手としてのLLM
- 「愚者は知識を問い、賢者は議論をする」
- 「AIは知識の代替ではなく増幅器」
- 労力は外注できるが、能力は外注できない
- Agentic Codingはスルーできない:
- AIが助手席から運転席へ、人間が運転席から助手席へ
- 広義のVibe Codingと狭義のVibe Codingがある
- 個人的にはClaude Codeを月額固定額にしてからプログラミング観が変わった
- Claude CodeはCLIだからUnix哲学との連続性がある
- 従量課金から月額固定額になることで「試行回数を増やして積極的に使い倒さないと損」という心理状態に変化し、無視できない効果が生まれた
- 自動化（Automation）から自働化（Autonomation）へ:
- Agentic CodingとはReconciliation Loopであり、望ましい状態を宣言的に定義し評価関数（適応度関数）を与えることでエージェントがその状態に収束するよう自律的に働く
- AIは自走するが暴走/迷走もする→ガードレール設計としてのソフトウェアエンジニアリングや技術の3本柱（バージョン管理、テスティング、自動化）の重要性がさらに増している
- 人間と複数のエージェントが互いに独立/並列で仕事を行い、問題があるときだけエージェントから人間に伝えるという形態へ
■ 8. まとめ
- 変わらないもの: 生き残る技術には特徴がある→その背後にある抽象の力を理解する
- 変わるもの: 技術の変化は螺旋状→螺旋の差分と、それを可能にした技術を理解する
- Game Changerを見抜く目を養い、ビッグウェーブにはしっかり乗る
- LLM / Agentic Codingはスルーできない