意図通りに実装 させるということ

ハーネスの整備をしていく流れがあるが、実際に開発に適用していくなかで抽象度の高い外側のハーネスだけでなく具体にフォーカスして、ズレにくいのはなんだろうという観点で、ゆるくLTしたときの資料

Transcript

1. H A R N E S S E N G I N E E R I N G / L T 意図通りに実装させるということ @t_pori418 · 5 min talk
2. 自 己 紹 介 Takashi Hori Engineering Manager ボードゲーム — 最近、犬（トイプー）を飼い始めました — ギターを弾くのが趣味になるかもしれないです — ヘルニア診断されました — 業務では Cursor、個人では Claude Code を使っています —
3. ま ず 、 こ と ば の 整 理 ハーネスって何？ ツール・ルール・ワークフローなど、AIの周りに組む実行環境。 今日は、そのうち利用者側で組める部分の話をします。 ハーネス ＝ 先回りしてズレを止め、 必要なものを渡す足場
4. や っ て い る こ と 調査からテストまでを、ワークフロー化する 実装系 テスト系 01 /research 調査・前提の把握 02 /checklist チェックリスト＋ 調査結果を出力 03 /plan 確認事項を渡して プラン設計 04 /implement 実装・単体テスト CI・レビュー対応 05 /e2e-case テストケース作成 （E2E） 06 /e2e E2E 実行 （Playwright） 差分手動テスト 受け入れ依頼 各工程を slash command（スキル）にして、実装系とテスト系（E2Eの準備）を並列で走らせる。 山場は下流の自動化ではなく、上流の ①調査 と ②チェックリスト。
5. 中 身 の 話 slash command には、何を書くか .claude/commands/research.md ## Goal このフェーズで何を出せたら完了か ## Steps 手順 ── どこを見て、何を調べるか ## Constraints ドメイン固有の条件 ── 過去のズレを列挙 ## Output 出力フォーマット ── 次の工程に渡す型 大半は、ふつうの手順書。 価値の8割は 固有の条件。 「前はここでズレた」を条件として盛っていく。 出力の型を固定すると、次の工程の入力が安定する。
6. 今 日 い ち ば ん 言 い た い こ と "広く効かせる層" だけだと、足りない 入り口の定石 AGENTS.md 的なもの その先 ＝ 治具 フェーズ特化のスキル ※ 呼び方はツールによりますが、要はプロジェクト直下の指示ファイル、くらいの温度で。 プロジェクト全体の知識・設計思想 — 常に効く／汎用的 — 粒度を上げると他工程のノイズになりがち — 調査・チェックリストに固有の条件を盛る — 判断がズレそうな所を先に補正 — 汎用性は捨て、狭く深く —
7. 正 直 な 適 用 範 囲 効くのは「型がある開発」だけ 効く 効きにくい 効かないのは「過去のズレを先回りする」部分。ワークフロー化そのものは新規開発でも回る。 新規開発は「ズレどころを探す」フェーズで、この手法は「分かった後」を高速化するもの。 既存実装を踏襲する横展開開発 ◦ コンポーネントのバージョンアップ ◦ 前例からズレどころを抽出できる開発 ◦ 完全に新規のロジックを組む開発 × ズレどころ自体が探索対象 × 先回りしようがない領域 ×
8. ま と め ズレ止めは、"広く浅く" では効かない AGENTS.md 的な広い層に加えて、フェーズごとに条件を盛った治具を。 型のある開発なら、上流のズレを先回りして止められる。