その実装の仕方は、どうして正しいの？

Transcript

1. その実装の仕方は、 どうして正しいの？ - AIにも人にも伝わる設計 - LT登壇資料 1
2. ABOUT ME 自己紹介 渡邉 巽 @tatwatan_dev 所属・役職 株式会社PoliPoli / プロダクトエンジニア 普段の業務 政治・行政のデータを扱うサービスの開発 趣味 ボードゲーム、バドミントン、自作〇〇（OS, プロトコル） 2
3. 01 INTRO ループエンジニアリング モデルが良くなるとともに、設計したものをそのままAIに実装してもらえるようになった。 これまで 要件定義・設計 人が考える → 指示 → 実装 指示 → 実装 指示 → 実装 → 人が見直す → 人が見直す → 人が見直す PR PR PR まとめて届く ここ最近 要件定義・設計 人が考える → 一気に実装してもらう /loop /goal AIが実装・テスト・修正を回し続ける → 最後に見直す PR 1PRあたりのコード量が、一気に増えた 。 3
4. 01 INTRO AIが書く速さに、人のレビューが追いつかない もやもや … 「こんなの、どうやって レビューすればいいんだ ……」 （日が暮れちゃいそう） 「AIも『これ以上、指摘はありません』 って言ってるし ……Approve？（ポチッ） 」 4
5. 01 INTRO レビューする箇所を限定する 「よし！ AIを使って、 会社でやっていること 最強の実装にするぞ〜！！」 ADRやDesign Doc（設計書）を中心にレビューする ↓ 設計が“正しい”なら、その設計通りに振る舞うAI生成物の実装も“正しい”と仮定 できる。（AIに任せられる範囲が広がる。） 5
6. 02 PROBLEM 先輩エンジニアに言われたこと うーん... 「今回の要求は満たせていそうだし、ちゃんと動きそうな気もする。 でも、本当にこの設計でよかったのか……。レビューしにくいなあ。」 「渡邉さんの ADRは、HowやWhatばかりで、 Whyが少ない気がするんだよね」 → 「設計が ”正しい”」かどうかを、レビュアーが確かめられない。 6
7. 03 INSIGHT 何が起きていたか。 大きな金槌を持っていると、何もかもが釘に見える。 データベースに強いチームは重い処理をとにかくSQLに任せようとするものだし、オブジェクト指向に強いチー ムは、複雑だと感じた処理ならなんでもオブジェクト指向で解決したがるものだ。 - 『アジャイルサムライー達人開発者への道』Jonathan Rasmusson 著 （強引にでも） AIに頼めばできてしまうからこそ、気づかないうちに 「自分の知っている方法の中だけで、ベストな How」を探してしまっていた。 7
8. 03 INSIGHT AIも同じ？ 最近、Xで話題になっていたポスト AIに技術的な指示を細かく書き込むと、かえっ て脆弱性が増えるらしい。 Howを細かく渡すほど、 AIもそのほかの最適な実装に 気づけなくなる？ 8
9. 03 INSIGHT どう設計書を書けば良かったのか 自分の判断の正しさをレビューしてもらうには、レビュアーと必要十分な コンテキスト を共有しなければい けなかった。 何をしたのかと同じくらい、 何をしなかったか（そして、それはなぜか） を記録しておくのが大事。 実は、これまでと何も変わっていない。 AIで一気に作れるようになって、その重要性が増しただけ。 レビュアーにも、 AIにも、同じコンテキストが必要。 （こころの叫び） 「でも、そんなこと言われたって ……今から一体どうすればいいのーー 😱」 9
10. 04 ACTION 具体と抽象という考え方 そんなときに出会った一冊 システム開発と「具体と抽象」 細谷 功 著（技術評論社、2026年） gihyo.jp/book/2026/978-4-297-15790-6 実装の “目的”（なぜ、そうしたいのか？）から、考えていく必要がある。 10
11. 04 ACTION 一歩引いて、目的から考える 同じ「なぜ」でも、原因を探るのか、やりたいことから考えるのか。 将来を見通しながら、 Why? 上位の目的（未来）：何のために？ 局所最適 → 全体最適へ 降りる 登る 別の業務課題 ペイン（要求） 同じ目的への別の道 目の前の具体 How（解決） アプローチ 具体的な実装・技術手段 What makes you…? 原因（過去）：何がきっかけで？ Why（目的）へ登る What（原因）を掘る 「なぜ、サーバー費用を下げたいのですか？」 「なぜ、遅刻してしまったのですか？」 →「浮いた予算で、やりたいことがあるから」 →「寝坊したから」 ……原因（真因）を探る 11
12. 04 ACTION 考え方を skillsにして、 AIにも渡す AIに依頼するときも、局所最適なオーバーエンジニアリングにならないように。 上位の目的 問題 Why ↑ • その依頼、全部そのまま対応していいの？ （ペインは問題の断片。すべ 問題 What ↓ 目の前の要求 問題 問題 問題 すぐに思いつく How How How 別のHow て対処すべきとは限らない） • その実装・運用コストは、ビジネス（本来の目的）に見合う？（将来に負債 を残したりやオーバーエンジニアリングになってない？） • Whyで登り、別の枝と比べてから Howへ 12
13. 05 NEXT これからのエンジニア 目的がわからないときは、 → ビジネス側とコミュニケーションをとる！顧客に話を聞きにいく！ 次の論点：目的の次に考えること（設計書に記載すべきコンテキストと判断） • 今回解決すべき課題とその解決方法（実装）のスコープを絞る。（期日と予算は？） • 今回の実装が、将来的な目的を達成する上で、過剰実装や負債（そのほかの継続的な機能実装の大きな妨げ）にな らないかを検討。 → 今回の意思決定で生じるトレードオフは？デメリットをどのようにして許容するの？ • 今回作らないと決めた機能（不確定要素）を曖昧なままにしておけるか？ etc … エンジニアのやることは、まだまだ多いですねっ！ 13