作り直せるコードは迅速に作り直せないDBは慎重に - AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話

Embed

Start on current slide

Slide 1

Slide 1 text

作り直せるコードは迅速に作り直せないDBは慎重に AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話⻄⽥貴之 (@kinosuke01) / GMOペパボ Product Engineering Conference 2026 1

Slide 2

Slide 2 text

⾃⼰紹介ロリポップ‧ムームードメイン事業部⻄⽥貴之 Takayuki Nishida 2020年中途⼊社 ● エンジニアリングリード ● Webホスティング、ドメイン登録サービス、ホームページ作成サービス、新規事業開発を担当 ● 担当サービスを育てながら、⼈もAIも⼒を発揮できる開発のしくみづくりに取り組んでいる ● X : @kinosuke01 2

Slide 3

Slide 3 text

今⽇話すサービスロリポップ！ AIホームページ（旧：AIサイトエージェント） ● Webサイト制作サービス ● AIがヒアリング → 構成‧テーマ‧コンテンツを⼀括⽣成 → サイト公開 ● ⽣成後も「トップのキャッチを変えて」など伝えれば、AIが編集を代⾏ ● 2026年リリース。現在サービスを育てているフェーズ。 3

Slide 4

Slide 4 text

今⽇話すサービスロリポップ！レンタルサーバー、ゲームサーバー、VPN、AIネイティブなインフラ環境などを展開 4

Slide 5

Slide 5 text

アジェンダ 1. 判断の不可逆性 2. 可逆な領域 3. 不可逆な領域 4. 判断の不可逆性をリリースフローに組み込む 5

Slide 6

Slide 6 text

1. 判断の不可逆性 6

Slide 7

Slide 7 text

１．判断の不可逆性 Amazon社 2015年度株主への⼿紙（ジェフ‧ベゾス⽒）⼀⽅通⾏のドア / Type 1 decision (=不可逆) 重⼤で後戻りができない意思決定。熟考と協議を重ねて体系的に決めるべき。⼆⽅通⾏のドア / Type 2 decision (=可逆) 変更が可能な意思決定。個⼈や少⼈数で迅速に下されるべき。 https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm 7

Slide 8

Slide 8 text

１．判断の不可逆性サービス開発での判断も、可逆と不可逆の2つに仕分ける可逆な判断不可逆な判断例 UIの⽂⾔、画⾯遷移、アルゴリズム、実装⽅式 DBスキーマ、外部公開API、課⾦の状態遷移、ID体系間違えたら直せばいい既存データの移⾏が必要外部利⽤者の追従が必要等コストやり直しコスト ≒ 実装コストやり直しコスト >> 実装コスト AI時代の変化実装コストが下がる＝⼤きく効率化実装以外のコストが⽀配的＝効率化が限定的 8

Slide 9

Slide 9 text

１．判断の不可逆性可逆か不可逆か判断して、進め⽅を変える可逆か不可逆の判断軸 ● データ構造を変更したいとき、現実的にマイグレーションが可能か ● 変更したいときに、他チームやユーザーへの調整が不要か ● 取り消しできない事実が発⽣しないか（課⾦、インシデントなど） → ひとつでも No がついたら、不可逆。可逆な領域：分析も実装も⾼速に回して、策を打つ不可逆な領域：観測した事実から未来を⾒通して、策を打つ 9

Slide 10

Slide 10 text

2. 可逆な領域ファネル分析と仮説検証 10

Slide 11

Slide 11 text

２．可逆な領域エンジニア1名で、ユーザーの躓きを⾒つけて改善したい [お申込み] → [ヒアリング] → [サイト⽣成] → [エディタで調整] → [公開] → [ご契約] Q. ユーザーはどこで⼿が⽌まってしまうのか？ 11

Slide 12

Slide 12 text

２．可逆な領域集計分析を可能にする準備 Claude Code とデータソースの接続 • 本番DBの分析⽤リードレプリカ + Metabase MCP サーバー • • ウェブサイトのデータがどこまでできたか Datadog MCP サーバー • どのページまでアクセスしたか集計分析 • Claude Code に専⽤スキルを作成 (Skill Creator Pluginで作成) データへの接続さえ確⽴できれば、Claude Code で分析できる 12

Slide 13

Slide 13 text

２．可逆な領域ファネル分析：ユーザーの躓きは「ヒアリング」 ※ グラフの⼤きさはイメージです申込ヒアリング開始サイト⽣成 ★ ここで最も⼤きく落ちる編集開始公開ご契約ヒアリングのページには多くの⽅がたどり着いているが、ヒアリングフェーズを完了せずに抜けている⽅が多い。 13

Slide 14

Slide 14 text

２．可逆な領域仮説：チャット形式のヒアリングは⼿間なのでは？当時のヒアリングはチャットUIだった。 ● 何をどう書けばいいか分からない ● 打つのが⼿間（スマホだと特に） ● 問い返しが続いて完了が⾒えない選択肢から選ぶウィザードUIなら、⼿が動くのでは？ 14

Slide 15

Slide 15 text

２．可逆な領域判断軸と⾒合わせる ● データ構造を変更したいとき、現実的にマイグレーションが可能か ● 変更したいときに、他チームやユーザーへの調整が不要か ● 取り消しできない事実が発⽣しないか（課⾦、インシデントなど）リリース間もないサービス。仮に失敗(通過率が悪化)しても戻せばいい。 → ウィザードUIを当⽇実装。当⽇リリース。A/Bテストで確かめる。

Slide 16

Slide 16 text

２．可逆な領域結果：チャットUIとウィザードUIでは統計的な有意差なし ● 意外な結果ではあった ● 最終的には、社内利⽤者のフィードバックを踏まえてウィザードUIにした ● とはいえ、観測 → 仮説 → 実装 → 検定を、 AIを駆使してエンジニア1⼈で迅速にまわすことができた AIとデータを接続して、高速に仮説検証 16

Slide 17

Slide 17 text

3. 不可逆な領域先を⾒通したデータモデル 17

Slide 18

Slide 18 text

３．不可逆な領域⽤語の整理：データモデル層決めること概念データモデル何が登場し、どう関係するかユビキタス⾔語の定義と、その関係を明確にしたもの論理データモデル属性‧キー‧正規化物理データモデルテーブル定義‧型‧インデックスデータモデル：上記の3段階を包括したものとして話を進めたい。 18

Slide 19

Slide 19 text

３．不可逆な領域まずは、YAGNI原則について You Aren't Gonna Need It = 必要になるまで作らない将来必要になるかもしれないものを、先回りして作らない。 ● 「必要になるかも」の予測は、だいたい外れる。 ● 使われないコードは、そのまま保守コストになる。ずっと。 ● 要件は変わる。先に作ったものは、変わったときに邪魔になる。 → たしかに、それはそう。 19

Slide 20

Slide 20 text

３．不可逆な領域 YAGNI原則は、不可逆な領域でも有効か？必ずしも有効とは⾔えない • YAGNIの前提：「必要になったときに作る」が容易。 • 変更発⽣時のコストが⾮対称に⼤きい場合に限り、変更しやすい設計を最初から埋め込んでおくことが有効ではないか。 YAGNI原則を緩め、先を⾒通すポイント • 変更のコストが⼤きいか（実質変更できなくなるか） • 将来実装する可能性が⾼い機能か 20

Slide 21

Slide 21 text

３．不可逆な領域変更のコストが⼤きいところは？多数の依存が発⽣しうるエンティティ #例 User ├─ LoginService • Gravitating to rigidity: Patterns of schema evolution ‒ and its absence ‒ in the lives of tables での⾔及。 • 多数の依存が発⽣するエンティティは変更するコストが⾼すぎて変更できない。 ├─ AccountService ├─ BillingService ├─ Analytics ├─ Admin └─ Reporting ... https://www.sciencedirect.com/science/article/abs/pii/S030643791630120X 21

Slide 22

Slide 22 text

３．不可逆な領域将来実装する可能性が⾼い機能か？マーケティングの概念で考えてみる • • Point of Parity（POP）： • 競合と同等であるべき要素「最低限これがないと選択肢に⼊らない」 • ≒ 必須機能 Point of Diﬀerence（POD）： • 競合と明確に違い、選ばれる理由になる要素 • ≒ 差別化機能 22

Slide 23

Slide 23 text

３．不可逆な領域将来実装する可能性が⾼い機能か？必須機能(POP)と差別化機能(POD)を⾒つける A社 B社 C社 D社機能 α ● ● ● ● 必須機能(POP)候補機能 β ● ● ● ● 必須機能(POP)候補機能 γ ● ● ● ✖ 必須機能(POP)に近い機能 Δ ✖ ● ✖ ✖ B社の差別化機能(POD)候補 ※ 本来はユーザーリサーチ等のデータも含めて総合的に判断 23

Slide 24

Slide 24 text

３．不可逆な領域将来実装する可能性が⾼い機能か？必須機能(POP) • 最低限これがないと、選択肢に⼊らない機能なので、将来ではなく、いま設計して実装する • ロリポップ！AIホームページの例 • 独⾃ドメイン設定 • アクセス解析 • お問い合わせフォームなど 24

Slide 25

Slide 25 text

３．不可逆な領域将来実装する可能性が⾼い機能か？必須機能(POP)に近い機能 • 必須機能(POP)に変化していくものと考えられる。 • 企業は模倣し合うバイアスがあるため。 • Why Do Firms Imitate Each Other? → 模倣されやすい条件について⾔及。 • いずれ実装が必要になる可能性が⾼い。 • 実装時の変更コストが⾮対称に⼤きい場合に限り、変更しやすい設計を最初から埋め込んでおくことが有効。 https://www.anderson.ucla.edu/faculty_pages/marvin.lieberman/docs/Why_Do_Firms_Imitate-AMR2 006.pdf 25

Slide 26

Slide 26 text

３．不可逆な領域将来実装する可能性が⾼い機能か？必須機能(POP)に近い機能 - AIホームページの例 • ドラフトファースト • 公開済みコンテンツを編集したら、その内容は⾮公開状態として保存され、明⽰的に公開操作するまで本番を上書きしない。 • ⾃動保存機能 • ドラフトファーストを前提に、明⽰的に保存操作しなくても、コンテンツ編集したら⾮公開状態として保存する。 • 履歴から復元 • ⾮公開状態として保存した過去の履歴からサイトを復元ができる。 26

Slide 27

Slide 27 text

３．不可逆な領域将来実装する可能性が⾼い機能か？必須機能(POP)に近い機能 - AIホームページの例 • ウェブサイトという中核のエンティティ。多数の依存が発⽣しうる。 • ドラフトファースト / ⾃動保存機能 / 履歴から復元を実装する前提でデータモデリングした。 • ドラフトファースト機能に関しては、実際に実装した。 27

Slide 28

Slide 28 text

３．不可逆な領域将来実装する可能性が⾼い機能か？必須機能(POP)に近い機能 - AIホームページの例 28

Slide 29

Slide 29 text

３．不可逆な領域将来実装する可能性が⾼い機能か？差別化機能(POD)のデータモデル • 不確実性が⾼く、仮説検証で⾒出していく。 • 狙った指標を改善する変更は10〜20%程度しかない。 • A/Bテストの話。Online Experimentation: Beneﬁts, Operational and Methodological Challenges, and Scaling Guide での⾔及。 • 先を⾒通すことが困難なので、YAGNI原則に従う。 https://hdsr.mitpress.mit.edu/pub/aj31wj81/release/1 29

Slide 30

Slide 30 text

３．不可逆な領域将来実装する可能性が⾼い機能か？種別将来の実装可能性備考必須機能(POP) - ないと選ばれない最初からデータモデリングも実装もする必須機能(POP)に近い⾼模倣バイアスで必須機能になりうる実装しやすいように、データモデリングしておく差別化機能(POD) 低不確実性が高い YAGNI原則に従う 30

Slide 31

Slide 31 text

３．不可逆な領域データモデリングで先を⾒通すまとめ • 基本的にYAGNI原則に従う。 • 例外的に、実装可能性が⾼い機能に紐づき、変更発⽣時のコストが⾮対称に⼤きい場合に限り、実装が容易なデータモデルを最初から埋め込んでおくことが有効。 • 実装可能性が⾼い機能： • • 必須機能(POP)に近いもの。変更発⽣時のコストが⾮対称に⼤きいもの： • 多数の依存が発⽣しうるエンティティ 31

Slide 32

Slide 32 text

4. 判断の不可逆性をリリースフローに組み込む AIレビュー + オートマージ 32

Slide 33

Slide 33 text

４．判断の不可逆性をリリースフローに組み込むまずは、可逆な領域の進め⽅をアップデート変更が可能な意思決定。個⼈や少⼈数で迅速に下されるべき。 ↓ 個⼈や少⼈数がAIを駆使して迅速に意思決定。 ↓ ⼈は介在せず、AIが⾃律的に迅速に意思決定。 33

Slide 34

Slide 34 text

４．判断の不可逆性をリリースフローに組み込む可逆 / 不可逆の観点を、リリースフローに組み込む ● ● 可逆な領域： ○ ⼈は介在せず、AIが⾃律的に迅速に意思決定。 ○ → Claude Code Action にレビューさせ、approve されれば⾃動マージ。不可逆な領域： ○ 熟考と協議を重ねて体系的に決める。 ○ → ⼈間レビューを必須。 ※ 前提として、CIによる lint‧test のチェックは全PRで通している。 34

Slide 35

Slide 35 text

４．判断の不可逆性をリリースフローに組み込むリリースフローの事例の紹介可逆なもの PR feature ▶ release PR ▶ develop AIがレビュー‧承認してオートマージ main 複数のfeatureを⼈間が確認してマージ ▶ 本番環境 GitHub Actionsで本番デプロイ不可逆なもの（従来と同じ） feature ▶ ⼈間がレビューしてマージ main ▶ 本番環境 GitHub Actionsで本番デプロイ ※ 従来のリリースフローは維持したまま、拡張的な構成とした。 35

Slide 36

Slide 36 text

４．判断の不可逆性をリリースフローに組み込む可逆/不可逆の区別は、ファイルパスで判断 Claude Code にコンテキストを与えて判断させている簡略化したコンテキスト PRは、別途指⽰がない限り、baseをdevelopブランチとして作成する。例外：以下のリスクパスを含むPRの場合は、baseをmainとする。 - path/to リスクパスの例なぜ不可逆か terraform/ k8s/ 壊すとインシデントにつながる prisma/ db/ データの消失リスク現実的にマイグレーションが不可能になるリスク 36

Slide 37

Slide 37 text

４．判断の不可逆性をリリースフローに組み込む可逆のフロー (1) 1. developをbaseとしたPRが作られる。 2. 上記をトリガーとして、レビュー⽤のカスタムアクションを実⾏。 ○ リスクパスが含まれている場合は、⼈間レビューをリクエスト。 ○ そうでない場合は、Claude Code Actions (CCA) がレビューを実施。 ■ CCAを呼び出し時に、レビュー観点をコンテキストとして与える。 3. レビュー結果がOKであれば、CCA が approve。 4. approve をトリガーに、カスタムアクションがdevelopブランチへマージ。 37

Slide 38

Slide 38 text

４．判断の不可逆性をリリースフローに組み込む可逆のフロー (1’) CCAに与えているレビュー観点 ● FrontierCodeを拡張して作成。 ● FrontierCodeとは、Cognition社が公開した「AI製のPRをOSSメンテナがマージしたいと思うか？」を測るベンチマーク。既存機能を壊していないか、テストが適切か等の複数の観点で評価する。 38

Slide 39

Slide 39 text

４．判断の不可逆性をリリースフローに組み込む可逆のフロー (2) 1. developに複数のPRがマージされる。 2. developブランチ作成や更新をトリガーに、 Github Actionsが develop->main 宛のPRを作成。 3. ⼈間が任意のタイミングでPRを確認してマージ(=リリース)。 39

Slide 40

Slide 40 text

４．判断の不可逆性をリリースフローに組み込むどう推進したか：デフォルトをAIレビュー/オートマージとした ● ● デフォルトをAIレビュー/AIオートマージにした。 ○ “PRは、別途指⽰がない限り、baseをdevelopブランチとして作成する” ○ デフォルトを⼈間レビューにしたままだと、推進されない。それで困る部分が出てきたら、困らない仕組み作りをする。 ○ 機械的に良し悪しを判定 / レビュー観点の更新 / リスクパスの変更など → 2026年8⽉のAI⾃律マージ率：おおむね 60％ (AIホームページ) 40

Slide 41

Slide 41 text

まとめ 41

Slide 42

Slide 42 text

まとめ 1. 判断の不可逆性 • 可逆か不可逆か判断し、進め⽅を変える。 2. 可逆な領域 • AIとデータを接続して、⾼速に仮説検証。 3. 不可逆な領域 • 先を⾒通したデータモデリングの考え⽅。 4. 判断の不可逆性をリリースフローに組み込む • 可逆な領域でAIレビュー/オートマージする事例。ご清聴ありがとうございました！！ 42