1. For any sizable new implementation or refactor, create a folder under .specs/ named YYYYMMDD_task-name and keep the work inside that folder. Track status as Draft → Review → Approved → Implementing → QA → Done.
2. In each folder, author requirements.md, design.md, and tasks.md in this order. Get user approval for requirements before moving to design; get design approval before creating tasks and implementing.
3. Do not maintain a root-level TODO. Track granular steps per spec in its tasks.md, and map each task to the corresponding acceptance criteria and tests.
4. Record specification approvals as milestones (date, approvers, key decisions) inside the spec folder. Log deltas/changes in a small “Change Log” section if the spec is revised.
5. Before execution, review requirements.md (purpose, scope, non-scope, acceptance criteria, dependencies, risks, performance/SLI, rollout/metrics). If updates are needed, apply them and re-seek approval, then explicitly

これはpyspa Advent Calendar 2025の6日目のエントリーである。

会社のブログに、いままでのプログラミングの慣習とかプラクティスを全部取り払って、新規で構築するとどうなるだろうか、というのを考えてパターンランゲージ化した記事を投稿した。eXtreme Programmingのスタイルを真似て書いてみた。

• ラジカルAIプログラミング

これを書いた時は、ある程度、熟練の開発者の方ができるだろう、という想定ではあったが、先日Opus-4.5を使ってみたら、バグの原因を探るのに、ライブラリのリポジトリのissueを探索して該当のバグを見つけてきて、修正されていないのを確認した上で回避策を実装するということをやってきた。人間なら1日、もしくは1週間ぐらいかかったかもしれない。それが10分である。

動くように正しく作る、という能力は並列で疲れ知らずというのをおいても、メモリが高くなりすぎてAIの価格が10倍とかにならない限りは勝負するフィールドを変えるしかないな、という気持ちが強くなったのを感じた。

現代のソフトウェアエンジニアリングにおいて、ソースコードの組織化—すなわちディレクトリ構造やパッケージ構成—は、単なる美的嗜好の問題ではなく、システムの保守性、拡張性、そして開発チームの認知負荷に直結する重要なアーキテクチャ上の決定事項です。かつてRuby on RailsやSpring Frameworkの初期バージョンが普及させた「Package by Layer（レイヤーによるパッケージング）」は、技術的な役割分担（MVC：Model-View-Controller）に基づく明確な構造を提供し、Web開発の標準化に大きく貢献しました。しかし、システムが複雑化し、ビジネスドメインが高度化するにつれ、この伝統的な構造が抱える「凝集度の低さ」と「結合度の高さ」という構造的欠陥が顕在化してきました。

本レポートは、ユーザーから提起された「なぜ最近はドメインごとに分割するPackage by Feature（機能によるパッケージング）が主流となってきたのか」という問いに対し、歴史的背景、理論的根拠、および主要エコシステム（Java/Spring、Ruby on Rails、Frontend）における具体的な実装パターンを徹底的に調査・分析したものです。

ソフトウェアエンジニアリングの歴史は、本質的に「複雑性」との闘争の歴史であると言えます。過去20年以上にわたり、業界はこの複雑性を管理するための主要な戦略として「水平方向のレイヤー化（Horizontal Layering）」を採用してきました。これは、プレゼンテーション、ビジネスロジック、データアクセスといった技術的関心事に基づいてコードを物理的に分離する手法であり、C#のN階層アーキテクチャや初期のWebフロントエンド開発において支配的なパラダイムでした。しかし、アプリケーションのインタラクティビティが増大し、ビジネス要件の変化の速度が加速するにつれて、この水平方向の境界線は開発の速度を妨げる要因となりつつあります。

本報告書は、バックエンド（特にC#/.NETエコシステム）、Webフロントエンド、そしてスタイリング（CSS）という3つの主要な領域において、アーキテクチャのトレンドがどのように変化しているかを包括的に調査・分析したものです。調査の結果、これら全ての領域において、「技術的な種類の分離」から「機能的な意味の凝集（Locality of Behavior）」への巨大なパラダイムシフトが進行していることが明らかになりました。

バックエンドでは、厳格な抽象化を重視するクリーンアーキテクチャから、機能単位でコードを垂直に切り出す「垂直スライスアーキテクチャ（Vertical Slice Architecture: VSA）」への移行が見られます。フロントエンドでは、jQuery時代の技術別分離（HTML/JS/CSS）から、React/Vueに代表されるコンポーネント指向（機能単位の統合）へと移行し、さらにディレクトリ構造も「機能ベース（Feature-based）」が標準化しつつあります。スタイリングにおいては、Atomic Designのような階層的分類から、Tailwind CSSに代表される「ユーティリティファースト」への移行が進み、コンポーネントとスタイルがかつてないほど密結合する傾向にあります。

趣味でインラインスケートをかれこれ21年ぐらいやっています。人生の半分です。子供も3歳からやらせており、家族全員で行う趣味となっています。自分がスケートを始めた時に、家族ぐるみで公園に来ている家族が何組もあり、将来こんな家庭を作りたいな、と思っていたところ、その夢がかなったという感じです。

インラインスケートにも何種類もあり、スラローム、ロングラン（クルージング、シティランetc）、マラソン、ショートトラック（スプリント）、ホッケー、アグレッシブなどなどです。僕が普段やっているのはスラロームですが、20年ぐらい前には5kmレースとかにも出たこともあります。これはマラソン。まあ本格的だと42kmとか100kmとかになるんですが。あと近年出ている練馬区民大会は100mが5周で500m。これはスプリントですね。

今日はその中のショートトラック（スプリント）のお話です。

今年は夏が暑くて6月から9月末ぐらいまではほぼ練習できず、公園の日陰の道を一周まわる程度しかできず全般的に練習不足ではありましたが、いただいた賞は過去最高の個数ではありました。

Inspired by https://www.industrialempathy.com/posts/design-docs-at-google/

[作りたいもの、あるいは解決したい問題の両方・どちらかがはっきりしている場合はDesign Docを書く必要がない]

[プロトタイピングで代替したり、プロトタイプを設計ドキュメントと組み合わせることも可能]