AI時代の理解アプローチ

Transcript

1. AI時代の 理解アプローチ 自分なりの理解を置き去りにしない、タスク分割と自己レビュー ひなたいLT会#2「AIなんでも持ち寄り会」 2026年9月11日 三浦 壱生
2. 自己紹介 三浦 壱生 KDDIアジャイル開発センター / ソフトウェアエンジニア X: @abIOELEsEfu6Os0 住んでいる場所 宮崎県 延岡市 最近読んだ本 エンジニアリング組織論への招待
3. アジェンダ 1 理解を落としたときの失敗談 2 主張 3 やり方 4 それでも理解に時間を使う理由 何が起きたか / なぜ起きたか 理解が追いつく大きさに分割し、自己レビューを2段にする 仕様 / 分割 / 実行 / PR自己レビュー / レビュー依頼 の5ステップ やってみた実感とまとめ
4. いま自分が出しているPR、 全部説明できますか。 私は答えられなかった
5. 何が起きたか 仕様駆動開発で進めていた。計画書と仕様ドキュメントが増え、生成されたコードも大量になった。 理解できないままタスクを進めた 出てきたコードを読み切らずに、次のタスクへ進んでいた 把握していない箇所に、コメントが返ってくる 自分が書かせたコードなのに、指摘に答えられない 理解できていない感じが、気持ち悪かった
6. なぜ起きたか 1 2 分割の単位を AI の生成能力に合わせていた。自分の理解速度 が、分割の条件に入っていなかった。 分からないまま次のタスクに進んでいた。見逃していた側だっ た。 分割の単位を間違えていた 理解できていない状態を放置していた
7. 見逃していた側だった 自分が理解できてない状態を絶対に 見逃さず、会議でも打ち合わせでも 時間をかけて「理解できていない」 点を解決する 牛尾剛『部下としてのAI 世界一流エンジニアの進化術』P34 私は分からないまま次のタスクに進んでいた。見逃していた側 だった。
8. 主張 PBIを、理解が追いつく大きさのサブタスクに 分割する 自己レビューは2段。 サブタスク単位は小さく繰り返し、PR提出単位に 時間をかける
9. やり方 1 仕様を詰めきる 2 自己レビューできる粒度でサブタスクに分割する 3 サブタスクを実行し、自己レビューを繰り返す 4 PR提出単位で自己レビュー 5 レビュー依頼 詰めきるまでコードを書かせない 分割案はAI、採否は自分 小さく、短く回す ここに時間を使う どこを指摘されても答えられる状態で出す
10. やり方の流れ 1 仕様を詰めきる 2 サブタスクに 分割する 完了条件が曖昧なら 1 に戻る（仕様の問題）／言えない なら分割し直す（粒度の問題） 3 4 サブタスク単位は小さ く、短く繰り返す 時間を使うのはここ。どこを指摘されても答えられる状 態で出す 実行し、 自己レビュー PR提出単位で 自己レビュー 5 レビュー依頼
11. 1 仕様を詰めきる 1 いまここ 仕様を詰めきる 2 サブタスクに 分割する 3 実行し、 自己レビュー 詰めきるまでコードを書かせない grilling スキルで、AI に質問攻めにさせる 仕様の穴を先に潰すと、後段の分割と完了条件がぶれない ここで手を抜くと、完了条件が曖昧になる 分割も自己レビューも成り立たない 4 PR提出単位で 自己レビュー 5 レビュー依頼
12. 2 自己レビューできる粒度に分割する 1 仕様を詰めきる 2 いまここ サブタスクに 分割する 3 実行し、 自己レビュー 分割案を出すのはAI、採否とやり直しは自分 サブタスクと完了条件をまとめて出させる サブタスクは、完了条件を自分の言葉で確認できるか 「満たされたことをどう確認するか」を自分で言えるかどうかで判断する 確認方法を言えるなら、そのまま通す 粒度は理解に追いついている。そのまま実行に移る 4 PR提出単位で 自己レビュー 5 レビュー依頼
13. 3 実行し、自己レビューを繰り返す 1 仕様を詰めきる 2 サブタスクに 分割する 3 いまここ 実行し、 自己レビュー 見るのは、完了条件を満たしたかだけ 1サブタスクずつ実行し、終わったらその場で自己レビュー 小さく、短くループする タスクごとにセッションをクリアにする 前の文脈が残ると、AI が違う挙動をすることがある 1サブタスク＝1セッションで区切る 4 PR提出単位で 自己レビュー 5 レビュー依頼
14. 4 PR提出単位で自己レビュー 1 仕様を詰めきる 2 サブタスクに 分割する 3 実行し、 自己レビュー 4 いまここ PR提出単位で 自己レビュー 5 レビュー依頼 レビューを依頼する前に、PR全体を自分で通して読む 時間はここに使う 合格条件は「なぜこうした？」に説明できること 最低ライン : スクラムマスターやPOに説明できる 目指すライン : エンジニアに説明できる 説明できるを基準にする理由 : 「学ぶために教えること」— 教えようとすると、分かっていないところが自分に見える（『シンプリシテ ィ』P47） 説明できないら、徹底的に理解に努める AIに説明をして合っているかを確認する 図やフロー中心で説明する自作スキルで、解説HTMLに書き起こして理解を促進する
15. 5 レビュー依頼 1 仕様を詰めきる 2 サブタスクに 分割する 3 実行し、 自己レビュー どこを指摘されても答えられる状態で出す 冒頭の問いに、いまは答えられる 失敗していたときとの違い 分割の基準 : AI の生成能力 から 自分の理解速度 へ 自己レビュー : やっていない から サブタスク単位＋PR単位の2段 へ 4 PR提出単位で 自己レビュー 5 いまここ レビュー依頼
16. それでも理解に時間を使う理由 地味だし時間はかかる。そのかわり腹落ちした感覚になり、どんな質問が来ても答えられる状態になる。 1 2 3 理解に時間を使うことで、その後の仕事の加 速度と応用範囲が高まる。 一番理解できている内容は、説明のたびに調 べ直さずに済む。結果として時間を効率よく 使えた。 実装方針が変わったとき、後続のサブタスク を捨てられる。先にまとめて作り込んでいた ら捨てられない。 後の仕事が速くなる 『部下としてのAI』P87 説明責任を果たせる 捨てられるようになる
17. 職場にも別の対策をしている人がいる 仮説と答えの差分を測る AI に投げる前に、自分の実装方針を先に書き出す 出てきた答えとのズレが、そのまま理解が足りない箇所になる CLAUDE.md で学習モードと実装モードを切り替える 学習モード : 答えを出させず、問いと解説で伴走させる 実装モード : 手を動かさせる。切り替えを明示的に宣言する ドメインを深めるための勉強会 チームで業務ドメインを読み合わせる場を作る 結局、ドメイン理解はコミュニケーションでしか解決できないという結論になった
18. まとめ 今回のやり方がベストだとは思っていない。理解の落としど ころは人それぞれ 理解について、一度立ち止まって考えてほしい 理解と学習に対する自分なりの最適解を見つける そこへ近づくやり方を探し続ける
19. 参照リソース 1 部下としてのAI 世界一流エンジニアの進化術 2 シンプリシティ 牛尾剛 / 文藝春秋, 2026-06-11 — 引用: P34, P87 Dave Thomas / オライリー・ジャパン, 2026-06-02 — 引用: P47