古いは恥だが役に立つ ~それでも私はissue駆動開発を推す~

Transcript

1. 古いは恥だが役に立つ それでも私は issue駆動開発推し 山ちゃん＠AWS好きすぎて滅 古いは恥だが役に立つ 01 / 16
2. 自己紹介 山ちゃん ／ X: @nekorobi_aws 鹿児島のフリーランスエンジニア AWSが好きすぎて、インフラにも手を出し始める。 古いは恥だが役に立つ 02 / 16
3. 界隈、新しい概念が 出るの早すぎません？ 古いは恥だが役に立つ 03 / 16
4. 増えた「〇〇エンジニアリング」と「〇〇駆動開発」 プロンプト エンジニアリング スペック 駆動開発 コンテキスト エンジニアリング ドメイン 駆動開発 ハーネス エンジニアリング AI 駆動開発 この1年ちょっとで、何個増えたんでしょうか。 古いは恥だが役に立つ 04 / 16 テスト 駆動開発 ループ エンジニアリング ユーザー 駆動開発 グラフ エンジニアリング
5. 昔も今も 私の推しは issue駆動開発 issue駆動開発、担降りしません。 古いは恥だが役に立つ 05 / 16
6. 「それ20年前くらいに 流行ったやつでは？」 はい、そうです。 古いは恥だが役に立つ 06 / 16
7. やっていることは、これだけです issueにやることを書いて、1枚ずつ潰していく。 ボードに並べて、左から右に流す。 目新しさは1ミリもありません。 古いは恥だが役に立つ 07 / 16
8. よく書けたissueは 「コンテキストの缶詰」 目的、背景、制約、完了条件。 AIに仕事を頼むときに渡したい情報が、最初から1パッケージになっています。 古いは恥だが役に立つ 08 / 16
9. issue駆動開発推しポイント 1 「理解負債」に、コードが生まれる前に気づける issueの型に落とし込めないのは、 理解が追いついていない証拠 「よくわからんけど、なんか動いたw」を先に封じる 古いは恥だが役に立つ 09 / 16
10. ボトルネックは、検証する速度に移った だから、意図の先払い。 コードは秒で出てきます。 それが意図どおりかを判定する人間が、いちばん遅い。 目的と完了条件を先に書いてあるから、 照合する基準が最初から手元にあります。 古いは恥だが役に立つ 10 / 16
11. issue駆動開発推しポイント 2 状態が、コンテキストウィンドウの外にある セッションは揮発する。 issueは残る。 コンテキストウィンドウはいつか溢れます。人間の頭も同じです。 古いは恥だが役に立つ 11 / 16
12. issue駆動開発推しポイント 3 issueをつなげると（Relationships）、線路になる つなげることで、 継続した開発ができる issueは単独では、ただの作業カード1枚です。 線路が敷いてあれば脱線しないし、途中で降りてもまた同じ場所から乗れます。 古いは恥だが役に立つ 12 / 16
13. issue駆動開発で改善を重ねていたら、 行き着いた先は、 Graphエンジニアリングでした Node Edge State Router ※ ＝ issue ＝ issue依存関係 ノード間で引き継ぐ状態 ＝ 共通issue 次の行き先を決める条件 ＝ issueの依存関係と人間の指示 仕事の単位 流れと依存関係 厳密には違いますが、概念が似ている部分があります 古いは恥だが役に立つ 13 / 16 （Blocked by / Blocking）
14. 枯れたのではなく、 進化に耐えた 意図を言語化する 状態を外部に置く 依存を構造化する 人間のチームでもAIエージェントでも変わらない、仕事の骨格です。 古いは恥だが役に立つ 14 / 16
15. そのうえで。 決め手は結局、 「自分に合っているか」 同じやり方が、同じように効くわけがないんですよね。 流行っているから乗り換える、古いから降りる。 それ、推し活としてどうなんでしょう。 古いは恥だが役に立つ 15 / 16
16. 自分の作業スタイルに刺さったなら、 それが推しです。 山ちゃん ／ X: @nekorobi_aws 古いは恥だが役に立つ 16 / 16