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

by リンクアンドモチベーション

Embed

Start on current slide

Slide 1

Slide 1 text

「AIがあれば越境できる」と思ったら、 AI Slopの山ができた株式会社リンクアンドモチベーション小宮慎ノ介 © Link and Motivation Group

Slide 2

Slide 2 text

自己紹介小宮慎ノ介株式会社リンクアンドモチベーションブランド統合開発ユニット AI駆動開発推進グループ最近1歳の娘が道端の草を指して、「ぱぱ！ぱぱ！」と言ってます。今日はパパとして大きな背中を見せられたらと思います！

Slide 3

Slide 3 text

現在のチーム新規プロダクトの立ち上げからリリースまで、 4人体制で進めた。コミュニケーションコストを抑えてスピードを優先するため、少人数チームの構成をとっている。今日お話する内容は初期リリース後の機能開発に関する話です。 PdM エンジニア（自分）エンジニア EM

Slide 4

Slide 4 text

PdMは企画、エンジニアが開発を主導すると決めた PdM エンジニア「何をつくるか」を決める「今つくるもの」を主導する • 顧客ヒアリング・市場調査 • 事業要求の決定 • 開発物への関与は「判断」と「レビュー」に絞る • 要件定義（ユーザー要求以降） • デザイン • 実装・リリース

Slide 5

Slide 5 text

とはいえ、要件定義もデザインも自分がやったことはほぼ無いデザインはデザイナーに、要件定義はPdMに分担するのが当然だと思っていた「専門性が無いと出来ないこと」だから、そもそも自分でやろうと思っていなかった

Slide 6

Slide 6 text

AI を使えば、要件定義もデザインも出来るでしょ上司 …やったことないけど、AI があるならやってみるか自分

Slide 7

Slide 7 text

AI を使えば、要件定義もデザインも出来るでしょ上司 …やったことないけど、AI があるならやってみるか自分ここから大量の AI Slopを生むことに 😨

Slide 8

Slide 8 text

課題編 ── 試行錯誤期

Slide 9

Slide 9 text

前提: エンジニアが受け持つのは「ユーザー要求」以降 PdM ① 課題 Eng ① 事業要求事業要求を踏まえ、開発アイテムを決める → 課題仮説とソリューション仮説をまとめる ② ユーザー要求 → ユーザーストーリー・プロダクト機能に落とす → ③ プロダクト要件要件定義書にまとめ、合意するここから先の話をします → デザインフェーズへ ② ③

Slide 10

Slide 10 text

要件定義フェーズの失敗 ① 課題 ② AIに作らせてみたけど、何か良い感じに書けてるな。レビューをお願いします！わたしこの記述、なぜこうなってるの？前提と違う気がするけど PdM 確かによくよく見たら、矛盾しているな・・・わたしこの前提だと、ウチの運用で成り立たないですその観点は考えてなかったです・・・わたし書き直しが続き、人がやった場合よりむしろ遅くなったドメインエキスパート ③

Slide 11

Slide 11 text

何故遅くなったのか ① 課題人間がやっていたとき AI に任せたとき 1 つ 1 つ考えて、すり合わせながら進めていたそれっぽいアウトプットが出てきて、そこをすっ飛ばした考える過程で論点が出てくる → 専門家と擦り合わせて決める → 決まったことを書く AIが一気に完成物を出す → 本来は各工程で出ていた論点が、レビューで初めて出てくる。書いた本人もその場で考えるから思考が浅く、手戻りが多く発生する。レビューで初めて論点が大量発生 ② ③

Slide 12

Slide 12 text

デザインフェーズの失敗 ① 課題 1. どこかで見た配色 ■ ブランドカラーが反映されない 2. AIが考えた文言 ■ 既存画面と用語がズレる 3. 意味のないアイコン ■ 密度だけ上がって読みにくいプロダクトの前提を渡さずに作らせるので、 AIの平均的なデザインがそのまま出てくる ② ③

Slide 13

Slide 13 text

何が難しかったのか ① 課題 1. アウトプットが基準を満たすまでのリードタイムが長い ■ 成果物を一発で出すので、どこまで決まったかが曖昧になり手戻りが発生する ■ 書いた本人も根拠を十分に説明できず、結果的に遅くなる合意形成に時間がかかるクオリティが上がらない 2. クオリティが上がらない ■ AIに渡している前提が薄く、ドメイン知識が反映されない ■ 専門家のレビュータイミングが遅く、価値が最大化されない ② ③

Slide 14

Slide 14 text

解決編 ── 要件定義

Slide 15

Slide 15 text

インプット ── 仕様書とペルソナをモノレポで資産化する ① ② 解決（要件定義） AI に渡す前提を、コードと同じ場所に置く PJTごとに作成される要求仕様書・要件定義書フロー情報として扱い、リリース後は更新しない境界づけられたコンテキスト単位の ADR・機能仕様書機能の変更時は、一緒に更新するサービス全体のペルソナ情報・ユビキタス言語射程距離の長い意思決定情報が蓄積されている ③

Slide 16

Slide 16 text

論点になりうるポイントを全て洗い出す ① ② 解決（要件定義）「決めるべき論点」を発散が得意な AIに全部出させる前提を固定するドメインエキスパートにヒアリングして変数を減らすモノレポの資産を読ませて論点を列挙する前述の資料を参照させて、決めるべき論点を出す論点ごとに選択肢を複数出す自分で決められないものは考えを添えて、次工程に回す ③

Slide 17

Slide 17 text

決めきれない論点だけ、専門家と決める ① 論点をスプレッドシートに全部並べて、 PdM・ドメインエキスパートと mtgでガッツリ決める ② 解決（要件定義） ③

Slide 18

Slide 18 text

決定済みの論点から、要件定義書を AI に書かせる ① ② 解決（要件定義）最後に確認するのは「決めたことが、そのまま文章になっているか？」だけ合意済みの論点要件定義書 ③

Slide 19

Slide 19 text

解決編 ── デザイン

Slide 20

Slide 20 text

要件定義で作った資料がそのままインプットになる 01 インプット 02 /design 03 03レビューレビュー ① 04 フロントのみ実装 ② ③ 解決（デザイン） 05 先行リリース課題・目的・意図は要件定義で使った資料を使う要件定義フェーズで使った資料がそのまま使える ClaudeCodeの /design を活用する既存画面のトークンやコンポーネントを参考にしながら、画面を作成してくれる

Slide 21

Slide 21 text

デザイナーには「描いてもらう」のではなく、動くものを触って判断してもらう 01 インプット 02 /design 03 レビュー ① 04 フロントのみ実装 ② ③ 解決（デザイン） 05 先行リリースこの artifact からデザインレビューをお願いします！わたしこの遷移、戻ったときに入力が消えるのは困る。あとこのラベル、既存画面と用語が違う。デザイナー直しました！もう一度触ってもらえますか？わたしこれなら OK！実装お願いします！デザイナー

Slide 22

Slide 22 text

合意した artifact は残さず、実装がそのまま仕様書になる 01 インプット 02 /design 03 03レビューレビュー 04 フロントのみ実装 ① ② 05 先行リリース合意した artifact は保持しない合意したら、すぐに実装に進むため、実装されている内容がそのまま仕様書になる実装が完了したら、テスト環境でも確認可能テスト環境で他画面を併せた体験を PdMやドメインエキスパートが直接確認することも出来るテスト環境でも確認可能になる ③ 解決（デザイン）

Slide 23

Slide 23 text

先行リリースして、リードタイムを縮める 01 インプット 02 /design 03 レビュー ① 04 フロントのみ実装フロントだけユーザー影響が出ないようにして、先行リリース。 APIの実装が終わった段階でオープンするだけにする。 ② ③ 解決（デザイン） 05 先行リリース

Slide 24

Slide 24 text

まとめ

Slide 25

Slide 25 text

解決編まとめ

Slide 26

Slide 26 text

結果的に、自分の責任範囲が増えた ● ● Before After 要件定義もデザインも、やったことがなかった専門家の力は借りる。でも責任は自分が持つ「専門性が無いと出来ないこと」だと思っていたデザイナーと PdM に分担するのが当然だった ● ● 決めきれない一部だけ専門家に借りるユーザー要求からリリースまで、自分が主導する

Slide 27

Slide 27 text

専門外の工程も、工夫次第でやれる！専門性が要るのは事実でもそれは「自分がやらない理由」にはならない —— やってみると、越境はここから始まる