「AIがあれば越境できる」と思ったら、 AI Slopの山ができた

リンクアンドモチベーション登壇資料（2026/9/5）
「AIがあれば越境できる」と思ったら、AI Slopの山ができた

#リンモチ #PdEConf #プロダクトエンジニアリング
===========================================
【株式会社リンクアンドモチベーション】
■イベントページ
　https://product-engineering.jp/2026/
■お問合せ先
　engineer_pr@lmi.ne.jp
■テックブログ
　https://link-and-motivation.hatenablog.com/
■開発組織の公式X
　https://x.com/LinkandM_dev
=============================================

Transcript

1. 「AIがあれば越境できる」と思ったら、 AI Slopの山ができた 株式会社リンクアンドモチベーション 小宮 慎ノ介 © Link and Motivation Group
2. 自己紹介 小宮 慎ノ介 株式会社リンクアンドモチベーション ブランド統合開発ユニット AI駆動開発推進グループ 最近1歳の娘が道端の草を指して、「ぱぱ！ぱぱ！」と言ってます。 今日はパパとして大きな背中を見せられたらと思います！
3. 現在のチーム 新規プロダクトの立ち上げからリリースまで、 4人体制で進めた。 コミュニケーションコストを抑えてスピードを優先するため、少人数チームの構成をとっている。 今日お話する内容は初期リリース後の機能開発に関する話です。 PdM エンジニア（自分） エンジニア EM
4. PdMは企画、エンジニアが開発を主導すると決めた PdM エンジニア 「何をつくるか」を決める 「今つくるもの」を主導する • 顧客ヒアリング・市場調査 • 事業要求の決定 • 開発物への関与は「判断」と「レビュー」に絞る • 要件定義（ユーザー要求以降） • デザイン • 実装・リリース
5. とはいえ、要件定義もデザインも 自分がやったことはほぼ無い デザインはデザイナーに、要件定義はPdMに分担するのが当然だと思っていた 「専門性が無いと出来ないこと」だから、 そもそも自分でやろうと思っていなかった
6. AI を使えば、要件定義もデザインも出来るでしょ 上司 …やったことないけど、AI があるならやってみるか 自分
7. AI を使えば、要件定義もデザインも出来るでしょ 上司 …やったことないけど、AI があるならやってみるか 自分 ここから大量の AI Slopを生むことに 😨
8. 課題編 ── 試行錯誤期
9. 前提: エンジニアが受け持つのは「ユーザー要求」以降 PdM ① 課題 Eng ① 事業要求 事業要求を踏まえ、 開発アイテムを決める → 課題仮説と ソリューション仮説をま とめる ② ユーザー要求 → ユーザーストーリー・プ ロダクト機能に 落とす → ③ プロダクト要件 要件定義書にまとめ、 合意する ここから先の話をします → デザインフェーズへ ② ③
10. 要件定義フェーズの失敗 ① 課題 ② AIに作らせてみたけど、何か良い感じに書けてるな。 レビューをお願いします！ わたし この記述、なぜこうなってるの？ 前提と違う気がするけど PdM 確かによくよく見たら、矛盾しているな・・・ わたし この前提だと、ウチの運用で成り立たないです その観点は考えてなかったです・・・ わたし 書き直しが続き、人がやった場合よりむしろ遅くなった ドメイン エキスパート ③
11. 何故遅くなったのか ① 課題 人間がやっていたとき AI に任せたとき 1 つ 1 つ考えて、 すり合わせながら進めていた それっぽいアウトプットが出てきて、 そこをすっ飛ばした 考える過程で 論点が出てくる → 専門家と 擦り合わせて 決める → 決まったことを 書 く AIが一気に 完成物を出す → 本来は各工程で出ていた論点が、レビューで初めて出てくる。 書いた本人もその場で考えるから思考が浅く、手戻りが多く発生する。 レビューで 初めて論点が大量発 生 ② ③
12. デザインフェーズの失敗 ① 課題 1. どこかで見た配色 ▪ ブランドカラーが反映されない 2. AIが考えた文言 ▪ 既存画面と用語がズレる 3. 意味のないアイコン ▪ 密度だけ上がって読みにくい プロダクトの前提を渡さずに作らせるので、 AIの平均的なデザインがそのまま出てくる ② ③
13. 何が難しかったのか ① 課題 1. アウトプットが基準を満たすまでのリードタイムが長い ▪ 成果物を一発で出すので、どこまで決まったかが曖昧になり手戻りが発生する ▪ 書いた本人も根拠を十分に説明できず、結果的に遅くなる 合意形成に 時間がかかる クオリティが 上がらない 2. クオリティが上がらない ▪ AIに渡している前提が薄く、ドメイン知識が反映されない ▪ 専門家のレビュータイミングが遅く、価値が最大化されない ② ③
14. 解決編 ── 要件定義
15. インプット ── 仕様書とペルソナをモノレポで資産化する ① ② 解決（要件定義） AI に渡す前提を、コードと同じ場所に置く PJTごとに作成される要求仕様書・要件定義書 フロー情報として扱い、リリース後は更新しない 境界づけられたコンテキスト単位の ADR・機能仕様書 機能の変更時は、一緒に更新する サービス全体のペルソナ情報・ユビキタス言語 射程距離の長い意思決定情報が蓄積されている ③
16. 論点になりうるポイントを全て洗い出す ① ② 解決（要件定義） 「決めるべき論点」を発散が得意な AIに全部出させる 前提を固定する ドメインエキスパートにヒアリングして変数を減らす モノレポの資産を読ませて論点を列挙する 前述の資料を参照させて、決めるべき論点を出す 論点ごとに選択肢を複数出す 自分で決められないものは考えを添えて、次工程に回す ③
17. 決めきれない論点だけ、専門家と決める ① 論点をスプレッドシートに全部並べて、 PdM・ドメインエキスパートと mtgでガッツリ決める ② 解決（要件定義） ③
18. 決定済みの論点から、要件定義書を AI に書かせる ① ② 解決（要件定義） 最後に確認するのは「決めたことが、そのまま文章になっているか？」だけ 合意済みの論点 要件定義書 ③
19. 解決編 ── デザイン
20. 要件定義で作った資料がそのままインプットになる 01 インプット 02 /design 03 03レビュー レビュー ① 04 フロントのみ実装 ② ③ 解決（デザイン） 05 先行リリース 課題・目的・意図は要件定義で使った資料を使う 要件定義フェーズで使った資料がそのまま使える ClaudeCodeの /design を活用する 既存画面のトークンやコンポーネントを参考にしながら、 画面を作成してくれる
21. デザイナーには「描いてもらう」のではなく、 動くものを触って判断してもらう 01 インプット 02 /design 03 レビュー ① 04 フロントのみ実装 ② ③ 解決（デザイン） 05 先行リリース この artifact からデザインレビューをお願いします！ わたし この遷移、戻ったときに入力が消えるのは困る。 あとこのラベル、既存画面と用語が違う。 デザイナー 直しました！もう一度触ってもらえますか？ わたし これなら OK！実装お願いします！ デザイナー
22. 合意した artifact は残さず、実装がそのまま仕様書になる 01 インプット 02 /design 03 03レビュー レビュー 04 フロントのみ実装 ① ② 05 先行リリース 合意した artifact は保持しない 合意したら、すぐに実装に進むため、 実装されている内容がそのまま仕様書になる 実装が完了したら、テスト環境でも確認可能 テスト環境で他画面を併せた体験を PdMやドメインエキスパートが直接確認することも出来る テスト環境でも確認可能になる ③ 解決（デザイン）
23. 先行リリースして、リードタイムを縮める 01 インプット 02 /design 03 レビュー ① 04 フロントのみ実装 フロントだけユーザー影響が出ないようにして、先行リリース。 APIの実装が終わった段階でオープンするだけにする。 ② ③ 解決（デザイン） 05 先行リリース
24. まとめ
25. 解決編まとめ
26. 結果的に、自分の責任範囲が増えた • • Before After 要件定義もデザインも、やったことがなかった 専門家の力は借りる。でも責任は自分が持つ 「専門性が無いと出来ないこと」だと思っていた デザイナーと PdM に分担するのが当然だった • • 決めきれない一部だけ専門家に借りる ユーザー要求からリリースまで、自分が主導する
27. 専門外の工程も、工夫次第でやれる！ 専門性が要るのは事実 でもそれは「自分がやらない理由」にはならない —— やってみると、越境はここから始まる