関連スライド
各ページのテキスト
生成AIで爆速？ なら爆速で「学び」を生成しよう やっとむ 合同会社やっとむ屋 2025/11/13 NEC TSSW統括部 Developers Summit
やっとむ / 安井力(やすいつとむ) 2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 連絡先など [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ より詳しくはこちら https://gist.github.com/yattom/b8b0cf059eac389822949d0e5be5c2a8 著書・訳書
本講演の内容 01 02 03 生成AIを開発に 利用するとき、 人間の役割は 説明責任 生成AIに多様な 選択肢を作って もらう 人間は選択肢を 評価、選びつつ 「見る目」を 育てる っていうのがいいんじゃないかな？という 体験にもとづいた提案
悩み: 仕事が楽しくないです
悩み: 生成AIでコーディングが速くなった ↓ しかし100%信用できないので人間がチェック、レビュー ↓ 延々と指示出しとレビューだけ ↓ たいへんだし、楽しくない
和田卓人さん (t-wadaさん) https://agilejourney.uzabase.com/entry/2025/08/29/103000
コードレビュー 外部品質の問題 • 入力の精度を上げて… このコードは 正しく動くか？ NO • テストも生成して… 間違っている (外部品質の問題) • 高額なモデルで… YES このコードは よいコードか？ 内部品質の問題 NO 今日はこっちの話 最適でない (内部品質の問題) YES OK だめ
人間がボトルネック • 責任を持つのは人間 • 実行責任と説明責任 • 実行責任 ― コードを書くこと • 説明責任 ― コードが妥当であるようにすること
そんなコード 拾ってきちゃ ダメでしょ！
AIの言うこと ぜんぶ信じちゃ ダメでしょ！
よいコードを「見る目」を養う • 人間がボトルネック → 人間を改善したい • よいレビューができる「見る目」「観点」 • 内部品質特性 保守性、信頼性、性能、セキュリティ、移植性… ISO/IEC 25010 システム・ソフトウェア製品品質 https://dev.classmethod.jp/articles/quality_characteristic/ 達人プログラマー ―熟達に向けたあなたの旅― 第2版 https://www.amazon.co.jp/dp/B08T9BXSVD
コードレビューはむずかしい • 基準が必要 • 状況による • ルールや標準 • 書きぶりが他のコードと合うか • メンバーやチームのスキルレベル
A B C
比較するのは比較的かんたん • よいものを選べる • なぜよいか、何が悪いか言いやすい • 見るべき点が見つかる
選択肢
選択肢
選択肢があると… • よりよいものを選べる • よい理由を言語化しやすい • 組み合わせてもっとよい選択肢を作れる (かもしれない) • 選ぶのは楽しい！ (「どれもよくない」も忘れずに)
選択肢？ https://ja.wikipedia.org/wiki/%E6%B1%BA%E5%AE%9A%E7%90%86%E8%AB%96
選択肢を作る • 適当な数がほしい • 適当なバリエーション、バラエティがほしい • 自分たちでは出せない案があるといい • じゃあ生成AIで生成しよう
example.pyを直してください。 処理が重いです example.pyを直してください。 バグがありそうです example.pyを直してください。理解しにくいです
選択
ETC原則 (『達人プログラマー 第2版』) 我々はETC原則を信じています―― 「Easier To Change」（変更をしやすく する）。これがETC原則です。 David Thomas; Andrew Hunt. 達人プログラマー ―熟達に向けたあなたの旅 ― 第2版 (p.91). 株式会社オーム社. Kindle 版. er に注目 より変更しやすくする 変更しやすいほうが よい設計
変更しやすいコードを書くとき 意識すべきことベスト3は？
『Tidy First?』 Kent Beck著、吉羽 龍太郎、永瀬 美穂、細澤 あゆみ訳 2024年12月 • 新しい本 • 古くから言われていること 古くても変わらない大事なこと プラス、新たな展開 • 「リファクタリング」の誤解が広まった 続刊が2027年1月発売予定！ (英語原書) https://www.oreilly.co.jp/books/9784814400911/
Tidy = 整頓 • 小さくてふわふわして可愛い変更 • ちい〇わ • 将来の仕事をやりやすくする • 次の作業をやりやすくする
紹介されている整頓の例 ガード節 説明変数 説明定数 よくない よくない よくない よい だいぶよくない よい デッドコード よい デッドコード＝実行されないコード 消せ。以上。おわり。
整頓の経済性 • この機能追加で1億円もうかる • 追加するのに3億円かかるなら、損だからやらない • 追加するのに300円なら、おおもうけだからやる • 「どんな追加変更も300円でできる」 • この状態にはいくらの価値がある？ • そのためにどのくらい投資してよい？ • 「より変更しやすい設計」の価値
新しい機能や仕様変更には価値がある 新しい機能や 仕様変更 価値がある
新しい機能や仕様変更が できることには価値がある…よね 新しい機能や 仕様変更 価値がある これができる 価値がある…？
どんな追加変更も簡単にできる ことの価値は？？？ 価値がある かどうか まだ不明 どれでもできる どれだけ 価値がある ？？？
• 振る舞いの変更の価値が変動する可能性は高ければ高いほど よい。 • 開発を長く続けられるほどよい。 • 将来もっと安く開発できるに越したことはないが、 価値に占める割合は少ない。 • オプションを作るために行う開発は少なければ少ないほどよい。 (『Tidy First?』Kent Beck, 2024, オライリー・ジャパン)
お前はなにを 言ってるんだ 翻訳者のみなさんごめんなさい。。。！！！ でも難しいっす。。。！ Kent Beck独特の言い回し、Kentぶしですね
• 振る舞いの変更の価値が変動する可能性は高ければ高いほど よい。 新しい機能や変更の価値が、想定以上に高くなるならオトク (想定内なら予定通りにしかならない) 上振れは大勝利。下振れなら作らなければいいだけ。 • 開発を長く続けられるほどよい。 終了してしまったら「できる」こと＝未来の可能性の価値はゼロ • 将来もっと安く開発できるに越したことはないが、 新しい機能や変更の価値がだいじ 価値に占める割合は少ない。 「できる」ことの価値は相対的に小さいので、 投資投資とがんばるのは考えもの • オプションを作るために行う開発は少なければ少ないほどよい。 オプションを作る＝「できる」ように準備すること (『Tidy First?』Kent Beck, 2024, オライリー・ジャパン) 少ないほどよい＝少ない工数のほうがよい やらないほうがよい、という意味ではない (と思います)
とつぜんですが宣伝です https://tdd-reading.connpass.com/event/371654/
整頓は積み重ね • 常に整頓して、変更しやすくしてあれば、常に変更しやすい → 300円 • 長年放置して乱雑になっていたら、ちまちま整頓したって無意味 → おおがかりな設計変更になって3億円
よりよく選べるようになる ＝ 見る目を育てる • どうしたら変更しやすいのか？ → 整頓を学ぶ • どっちが変更しやすいのか？ → 実験してみる • 知識・スキル・ノウハウが前提 → 学びたい • 言語の機能や仕様 • 設計のいろいろなパターンやベストプラクティス • 使うと便利なツール、サービス、ライブラリ • 「生成AIと一緒に開発」するとき、 どうしたら変更しやすいのか？
どんな「見る目」？
どんな選択肢を作ってもらうか • この処理をRustっぽく/Pythonぽく/TypeScriptぽく書くにはどうした らいいんだろう… • どんなデザインパターンが当てはめられるかな… • 関数型で書いてみたいけどどうしたら… • AWSのセキュリティのことなんもわからんのだけど… • 生成AIとテスト駆動開発するにはどうしたら… • 好奇心を原動力に！
私の場合 • ゴリゴリ書いて動くようになったものをきれいにしたい • よく知らないこと、初心者の分野 • よく知ってるつもりけど何か違うの出ないかな？ • 最新で話題のなにか • 教わったばかりのやり方 • 思ったように動かないとき、新たな観点がほしいとき • など… • ※本当に新しい、斬新・画期的はことはできないので注意
コードレビュー このコードは 正しく動くか？ NO YES maybe このコードは よいコードか？ YES 学び！ OK NO 正しいかどうかは、 Yesかそれ以外 (あいまいは不可) よいコードかどうかは、 常に比較 (ETC原則＝ より変更しやすいか) ＝ 常に学び！
作業ステップやアプローチの選択肢 アプローチ1：一気に変更してすぐ確認 観点 1.一気 2.リファク 3.最適化 タ 所要時間 15-30分 1-2時間 45-60分 リスク 高 低 中 アプローチ2：リファクタリング優先 コード品質 変化なし 大幅改善 改善 • 既存コードを整理してから機能追加。最も安全で構造的。 テスト 手動のみ E2E完備 包括的 • ヘルパー関数抽出 → テーブルクラス拡張 → distribute実装 → E2Eテスト追加 将来価値 低 高 中～高 デバッグ 困難 容易 中程度 アプローチ3：戦略的最適化 ロールバッ ク 全か無か 段階的 戦略的 • 最小限の戦略的変更で既存コードを拡張しやすく。バランス型。 適用場面 試作・時間 制約 本番・チー ム開発 ソロ・保守 性重視 • 一気に全部変更して動作確認。最速だがリスク高。 • 翻訳追加 → distribute操作実装 → 手動テスト → 不具合修正 • パターン分析 → featsContext拡張 → 共通処理統合 → distribute 実装 → 包括的テスト ※Claude Codeにチャット内で生成してもらったもの
AWSサービス構成の選択肢 ※draw.io形式で 生成してもらって ツールで表示した もの
AWSサービス構成の選択肢
AWSサービス構成の選択肢
AWSサービス構成の選択肢 C A B • 変更しやすいのはどれ？ • 拡張、構成変更、路線変更、縮小・廃止しやすいのは？
UIデザインの選択肢 • 架空のソーシャル読書アプリ ※ClaudeにHTML形式 で生成してもらったもの (Claude Codeではない)
UIデザインの選択肢
生成AIに渡すコンテキストの選択肢 • コードベースを渡す？ • 仕様を渡す？ • テストケースを渡す？ • ADRを渡す？ • 作業ステップやアプローチを渡す？ • なにを渡すと変更しやすい？
おわりに
人間がボトルネック • 人間が上達すればいい • 手を動かさないなら「見る目」 • ETC原則＝変更しやすくする • 「生成AIと一緒に変更しやすくする」とは何なのか？
人間にしかできない仕事 • 筋のよい選択肢 • 要求、ユーザー、ビジネスに踏み込んでいく • 楽しむこと