BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//pretalx.com//pyconjp2026//talk//EEDAWD
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
BEGIN:STANDARD
DTSTART:20250822T000000
TZNAME:JST
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
SUMMARY:「なぜこう実装したか」に答えられるリポジトリ
 を作る ── コーディングエージェントと仕様書を同居
 させるPythonプロジェクト設計 - arapower
DTSTART;TZID=Asia/Tokyo:20260822T134500
DTEND;TZID=Asia/Tokyo:20260822T141500
DTSTAMP:20260818T083856Z
UID:pretalx-pyconjp2026-EEDAWD@pretalx.com
DESCRIPTION:「この仕様、なぜこうなっているんですか？
 」──地方自治体を顧客とする私たちのシステムでは
 、こうした問い合わせが後から届くことが珍しくあり
 ません。以前は、答えるためにコードを読み直し、そ
 れでも「なぜ」の部分は担当者の記憶に頼るしかあり
 ませんでした。\n\n根本的な問題は、設計の判断がコー
 ドにもドキュメントにも残らず、Gitリポジトリの外に
 散らばっていたことです。コーディングエージェント
 が実装の実務を担うようになってもこの構造は変わら
 ず、エージェントへの指示はチャットで流れ、判断の
 根拠は他の開発者にもエージェントの別セッションに
 も引き継がれません。「なんとなく動いているが、な
 ぜそうなっているかわからないコード」が増え続けま
 した。\n\nそこで導入したのが「ドキュメントベース開
 発」です。要求仕様書（何をしたいか・なぜ必要か）
 から仕様を抽出し、システム仕様書（最新の実装仕様
 ）として整理します。エージェントへの指示を両仕様
 書に統一し、一過性と恒久の二層をバージョン管理し
 ます。PRマージまでの協業ワークフローを定義し、役割
 分担と文書追加の判断基準を明示しています。\n\n結果
 として、エージェントとの実装段階のやり取りが減り
 、問い合わせへの回答が担当者の記憶に依存しなくな
 りました。\n\n本発表では、医療データ分析というドメ
 イン特性からPythonを採用した3プロダクト（予防医療向
 けシステム）とTerraform/TerragruntによるIaCに、このアプロ
 ーチを横断展開した実践例を紹介します。要求仕様書
 の書き方、システム仕様書への整理方法、コーディン
 グエージェントとの協業ワークフロー設計まで、具体
 的なドキュメント構造とともに解説します。「設計の
 根拠が残らない」課題を感じているチームに、明日か
 ら自分のリポジトリに持ち込める仕組みを持ち帰って
 いただける内容を目指します。
LOCATION:Conference Office
URL:https://pretalx.com/pyconjp2026/talk/EEDAWD/
END:VEVENT
END:VCALENDAR