AIに任せる、ではなく。 AIと進める。

freee 技術の日 2026のセッション資料です。

Transcript

2. AIに任せる、ではなく。 AIと進める。 nanora 2026年10⽉04⽇
3. 個⼈‧法⼈プロダクト開発 個⼈Web開発 PdL nanora freee歴 6年目 freee会計を扱っていたことが多い 主にグロース開発を行う。 中学の時にハマっていたLPレコードを 集めるのが趣味。
4. 01 PROLOGUE リサーチも、設計も、実装も、QAも。AIで⼀⼈ずつ速くなった。 とはよく⾔うけれど チームとしては、前に進んでいるか ― まだ、パーティーは組まれていない ―
5. 01 PROBLEM ─ ソロ加速の落とし⽳ ⼀⼈ずつ速くなった。チームは速くなった？ MYTH 各⼯程でAIを使えば、チーム全体が速くなる TRUTH 速い所の出⼒が、遅い所に積み上がる。 ソロで加速した結果、どこで詰まるか 企画 枯渇 判断と要件が、実装の速さに追いつかない 実装 急増 AIで、PR が⼀気に増える レビュー QA 焼き切れ 逼迫 PR の数だけ、コンテキストスイッチが増える ⽬指すべきAIとの距離 AI-Assisted ─ ⼀⼈ずつ速くなる（ソロプレイ） AI-DLC ─ パーティーで進む。AIが進⾏、⼈が判断 検証が溢れて、待ち⾏列になる AI-Managed ─ 丸投げ。説明と責任が消える 運⽤ 後追い 問い合わせと障害対応が、後から押し寄せる ▸ どこか⼀つが速くなるほど、隣の⼯程が詰まる ⼀⼈ずつのレベル上げでは、パーティーは前に進まない。 PROBLEM ▸ 必要なのは、ソロの加速ではなくパーティーの編成
6. 02 PARTY ─ だからパーティーを組む 同じ場⾯に、全員が別の問いを投げる TRPG のセッション プロダクト開発 GM「⽬の前に、閉じた扉がある」 仕様「オンボーディング体験を改善する」 僧侶 「そもそも⼊る必要ある？」 PdM 「そもそも価値ある？」 吟遊詩⼈ 「この話、皆にどう伝わる？」 Design 「利⽤者にどう伝わる？」 戦⼠ 「壊せる厚さか？」 Eng 「制約は？ 実現できる？」 盗賊 「罠は？ 鍵は開く？」 QA 「どこで壊れる？」 レンジャー 「帰り道は確保してる？」 Ops 「出した後、戻せる？」 魔法使い 「この紋章、前にも⾒た」 CS 「お客様は前にここで詰まった」 ≡ 同じ構造 ⼀⼈では扉の全体像が⾒えない。AIは扉を開けない。問いを揃え、判定を回し、ログに残す。
7. 02 SPINE ─ 今⽇の背⾻ AI-DLCは、AIに仕事を任せる仕組みではない MYTH AI-DLCは、AIに仕事を任せる最強のフレームワーク TRUTH 全職種の問いをログに残し、ゲートとして毎回問い直す仕組み。 AIはプレイヤーではない。GM補佐 兼 ログ係 企画から運⽤まで、同じキャンペーンを続ける AI-DLC / セッションログ PdM Design Eng 価値‧優先順位 体験‧理解 実現性‧制約 INCEPTION CONSTRUCTION QA OPERATIONS 何を‧なぜ どう作る 渡せる状態か 実案件でどうか Pitch PRD UX / Mock Design Doc Story / Code QA Ops CS Test / Evidence リスク‧境界 運⽤‧観測 顧客の現実 Metrics / Feedback ▸ 成果物は、次のシーンへ渡すセッションログ SPINE
8. 03 SCENE パーティーは組めた。AIで、実装は⼀気に進む。 153 PR / 11万⾏を回した卓 量が増えるほど、⼈は全部を⾒きれない このシーンで主導する Eng PdM Design QA Ops ― 全員が同席している。問う⾓度が違うだけ ― CS
9. 03 SCENE ─ 量と品質 このシーンで主導する 全部は⾒きれない。分かっている問いは、機械に問わせる MYTH AIでPRを量産すれば、その分だけ前に進む TRUTH 量が増えるほど、⼈の注意は薄まる。 機械ゲートが、毎回同じ問いを投げる 設計との照合 実機 I/O 検査 AIの反証レビュー ある機能の v1 → v2 の卓 QA 引き渡し判定 分かっている問いは、漏らさず機械が問う PASS BLOCK SCENE QA 11万⾏ 64件 マージした PR 変更⾏数 +9.6万 / −1.5万 着⼿前に機械が⽌めた 設計と実装の⾷い違い ⼈へ返す ▸ ⼈は、ゲートが知らない問いに集中する 同席者の問い 153 「ゲートが知らない問いは、私が探す」 ▸ ⾷い違いは、実装に⼊る前に直した PdM 「その⾷い違い、仕様側を直そう」 Eng
10. 04 AFTER SESSION ─ 感想戦をハウスルールへ AI-DLCは、卓ごとのハウスルールで育てる 基本ルールは採⽤する。ハウスルールはチームで育てる 01 基本ルールブック 卓の事情 ハウスルール AWS Labs AI-DLC の考え⽅ 責任分界‧業務判断‧品質‧運⽤ チーム⽤の AI ⼿順とチェックに実装 実⾏ 02 実案件でセッションを回す 観測 03 詰まり‧振り直し‧レビュー 感想戦 04 次も効く判断基準へ 注⼊ AI⼿順‧機械チェック‧ひな形 次のセッションでは、同じ観点が最初から効く 感想を残すのではなく、次の判定で使われるルールに変える。 ▸ 公式ルールをそのまま使わない。卓ごとに、適⽤すべきAI-DLCの形は変わる 同席者の問い OPS / FEEDBACK PdM 「この数字、次の企画の問いにしよう」 Eng 「この詰まり、機械チェックにして防ごう」
11. 04 AFTER SESSION ─ 感想戦がハウスルールになった実例 このシーンで主導する QA 「これ仕様？」が 13 → 0 になるまで MYTH 最強のフレームワークを⼊れれば、数字は勝⼿に良くなる TRUTH 気づいた瞬間に⾔語化し、ゲートにしたから数字が動いた。 ある機能の v1 → v2 で回した⼀周 気づく 8/4 v1 ⾔語化 8/6 ゲート化 8/3〜8/28 結果 9/2 v2 実装完了からQA開始まで13⽇待ち。 実装完了からQAに渡すまでの間に、 QA引き渡し判定をAIの⼿順に。 実装完了と同⽇に QA に引き渡し。 QA 指摘 38件の55%は、渡す前に⽌めら テスト計画を基準にする防波堤を置く 基準はテスト計画から読む アクセシビリティの⽋陥2件を渡す前に検 れた 出 「これ仕様？」の QA 指摘 QA 指摘率（チケット1件あたり） 設計起因の⼿戻り（件数ベース） 13 → 0 0.48 → 0.29 29.9% → 11.5% ▸ v1 と v2 は規模が違うため、指摘率でも⽐較。設計起因の⼿戻りは、設計書の実在チェックを機械化した別の⼀周 確認作業が消えたのではない。QA が実⾏中に気づく場所から、渡す前に全員で問う場所へ移った。 OPS / FEEDBACK
12. NEXT SESSION ─ 次の扉の前で 全部を変えなくていい。⼀つの引き渡しから 01 02 03 詰まりやすい引き渡しを⼀つ選ぶ ⼊⼒‧出⼒‧⼈が判断する場所を決める ⼀度回し、感想戦で学びをルールへ変える AIに任せる、ではなく。 AIと進める。 次の扉の前で、全員が問える卓をつくる。判定は⼈が下し、学びをルールに返す。
13. APPENDIX ─ セッションゼロ: 何から始めるか 企画‧設計で先にやって、後からの出戻りが消えたこと TOP3 本番の前に、全員で⽬線を合わせる 1 イベントストーミング 2 UML モデリング 3 QA シナリオ作成 企画の最初に イベントストーミング確定後 設計の段階で ▸ 詰まりやすい引き渡しを⼀つ選ぶときの起点にしてください APPENDIX ユーザーがどんな体験をするのか、全職種で⽬線を合わせる。 出来事を時系列に並べるので、職種が違っても同じ絵を⾒られる 関連するドメインを網羅的に調査し、 validation を⼀つも残さない設計を⽬指す 単純な操作はあらかじめスクリプト化しておき、 どこまでを Eng の QA で実施してよいかを QA と合意する