作る力から、見極める力へ — AI時代に広がるエンジニアの価値と役割

2026/06/28 ＠きのこカンファレンス2026

AIで実装が速くなったとき、エンジニアの価値と役割はどう広がるのでしょうか。

コードを書く、調査する、設計案を整理する、プロトタイプを作る。
こうした作業はAIによって以前よりも速く実現できるようになりました。
一方で、プロダクト開発で本当に難しいのは、決まったものを速く作ることだけではありません。
ユーザーにとって価値ある課題を見極め、何を検証すべきかを考え、最速で学び、作るべきものを判断することです。

本セッションでは、AI時代にエンジニアの価値が「作る力」から「何を作るべきかを見極め、学習速度を上げる力」へ広がっていくという視点を共有します。
エンジニアがプロダクトディスカバリーに積極的に関与することで、技術力をどう価値探索につなげられるのか。
そして、この先もエンジニアとして生きのこるために、どのように役割を広げていくべきかを考えます。

Transcript

1. 2026/06/28 きのこカンファレンス2026 rince (@kazumax1218) 作る力から、見極める力へ — AI時代に広がるエンジニアの価値と役割
2. 鈴木 和真 rince (@kazumax1218) 株式会社マイベスト 取締役 CTO • 2011- カカクコム（食べログ → キナリノ） • 2018- メルカリ（ソウゾウ → メルペイ） • 2020- マイベスト • 旅とキャンプとサウナが好き⛺ • 3歳の息子がいます👶 自己紹介
3. 月間利用者数 3,000 ユーザーの“選択”を サポートする 商品比較サービス 万人 約
4. 商品を自社で購入し、専門性を持ったメンバーが徹底検証 倉庫やラボ、撮影スタジオなどの環境を完備したオフィスで、各領域の専門性を持ったメンバーが商品を比較検証
5. • 話すこと ◦ AI時代にエンジニアの価値と役割はどう広がるか？ ◦ 「作る速度」ではなく「学習速度」を上げる考え方 ◦ エンジニアがプロダクトディスカバリーに関わる価値 • 話さないこと ◦ AIのアウトプットを見極め、最適な設計や実装を判断する方法 （重要だけど今回はスコープ外） 今日の話
6. 目次 AIで加速する開発とそのリスク 1 プロダクトディスカバリーとは 2 エンジニアがプロダクトディスカバリーで発揮する価値 3 マイベストでの事例 4 AI時代に広がるエンジニアの価値と役割 5
7. AIで加速する開発とそのリスク 1
8. • コードを書く • 調査する • 設計案を整理する • プロトタイプを作る • テストを書く • リファクタリングする （※単に「動く」ものではなく「動き続ける」ものを作るためには依然として考慮すべき点は多い） AIの進化によって、単に動くものを作るだけであれば以前よりも速く実現できるようになった AIによって「作る」は速くなった
9. アウトプットは2倍になったけれど、 アウトカムは2倍になったか？
10. “ビルドトラップとは、組織がアウトカムではなくアウトプットで成功を計測 しようとして、行き詰まっている状況のことです。実際に生み出された価値で はなく、機能の開発とリリースに集中してしまっている状況です。” AI時代のビルドトラップ AIは「増幅器」（DORAレポート2025） → 作るコストが下がることで、ユーザーが求めていないものを 速く、大量に作ってしまうリスクも高まる AIで速く楽に作れることで、ビルドトラップも加速する
11. AIで作るコストが下がっても、保守・運用するコストがゼロになるわけでない 機能は作った瞬間から運用コストが発生する • バグ修正 • 仕様変更・機能追加 • 問い合わせ対応 • テスト・QA • 他機能との整合性維持 • コンテキストの増大 • ユーザーの認知負荷 機能が増えるほど、プロダクトは複雑になり、開発スピードは低下する
12. • 何を作るべきか • ユーザーの課題は何か • どうすればそれを解決できるか どれだけ作ってもユーザー価値（アウトカム）に結び付かなければコストが増えるだけ プロダクト開発で難しいのは、作るべきものを見極めること AI時代において、「作るべきものを見極める力」がますます重要になる → そのための鍵が、エンジニアがユーザー課題にDeep Diveし、 プロダクトディスカバリーに積極的に関与すること
13. プロダクトディスカバリーとは 2
14. プロダクトディスカバリーとプロダクトデリバリー プロダクトディスカバリーとは、問題と解決策を探索し、何を作るかを見極めるフェーズ ＝ 良いアイデアと悪いアイデアを迅速に判別すること Discovery Delivery フェーズの役割 何を作るかを見極める 決めたものを作る 重視すること 迅速な学習が重要 安定性・スケーラビリティ が必要 目的 不確実性を下げる ユーザーに届ける 主導する人 主にPdM・デザイナー 主にエンジニア
15. なぜプロダクトディスカバリーが必要なのか プロダクト開発が失敗する根本原因はユーザーが求めていないものを時間をかけて作ってしまうこと 開発（ビルド）はアジャイルだが、全体はウォーターフォールになっている → リスクが最後に来る アイデアの少なくとも 半分はうまくいかない アジャイル
16. • 価値のリスク ◦ 顧客はこれを買ったり、これを使うことを選んでくれるだろうか？ • ユーザビリティのリスク ◦ ユーザーはこれの使い方がわかるだろうか？ • 実現可能性のリスク ◦ 私たちはこれを作れるだろうか？ • 事業実現性のリスク ◦ このソリューションは私たちのビジネスに貢献するだろうか？ 次の重要なリスクに対処し、できる限り迅速にアイデアの妥当性を立証すること プロダクトディスカバリーの目的
17. 正しい問題を見つける ユーザーインタビュー、データ分析 カスタマージャーニーマップ、etc. プロダクトディスカバリーの2つのフェーズ 正しい解決策を見つける ブレインストーミング、コンセプトテスト プロトタイピング、A/Bテスト、etc. ディスカバリーには問題の探索と解決策の探索の2つのフェーズがある（ダブルダイヤモンド） プロダクトディスカバリー
18. エンジニアがプロダクトディスカバリー で発揮する価値 3
19. • 以前は、ディスカバリーにおいて作らず済むにこしたことはなかった ◦ コンシェルジュ実験、オズの魔法使い、コンセプトテスト、モックアップ、etc. • が、AIの進化により、作るコストが劇的に下がった ◦ 「作らず検証するコスト ≒ 作って検証するコスト」になることも • 「作るべきか/作らないべきか、どう作るか」を判断できるのはエンジニア ◦ 「作る力」があるからこそ、適切な判断ができる ◦ 「コンテキスト」を漏れなく把握することで、適切な判断ができる • エンジニアがディスカバリーで発揮できる価値が以前にも増して大きくなった ディスカバリーでは、迅速な学習が最重要 AI時代においてディスカバリーで「作る」という選択肢が有力に
20. ディスカバリーフェーズにエンジニアが積極的に関与する 従来は主にPdMとデザイナーやリサーチャーがディスカバリーを主導することが多かったが、 エンジニアも積極的に関与する・主導することで価値を発揮できる プロダクト マネージャー デザイナー/ リサーチャー エンジニア プロダクト ディスカバリー テックリード/ プロダクトエンジニア
21. 1. 課題を深く理解して解決策を考えられる 2. 実現可能性を早期に見極められる 3. 作るかどうかの判断の精度が上がる 4. 仮説検証のための最適な落とし所がわかる 5. AIのアウトプットが適切か判断できる 6. 分析結果から即座に次の仮説検証を回せる ディスカバリーにおける価値探索のスピードを上げることができる ディスカバリーにエンジニアがいることの価値
22. ディスカバリーの各プロセスにエンジニアが関わることで、最速で価値ある機能に辿り着ける ディスカバリーの開発プロセス
23. マイベストでの事例 4
24. • 事例①：Web接客機能 • 事例②：favlist（新規事業） • 事例③：AI-DLC マイベストでの3つの事例をご紹介 マイベストでの事例
25. 事例① Web接客機能 オフラインでの接客体験（ex. 家電量販店）をオンラインで実現する 質問にポチポチ 答えていくと、 自分に最適な 商品がわかる
26. エンジニアがディスカバリーを主導 以下の流れでプロジェクトを進行 1. 問題を見つける ◦ ユーザーインタビューを実施 ◦ 背景・課題を深く理解する 2. 解決策を考える ◦ 社内の元販売員（接客経験者）にヒアリング ◦ 実現可能性の観点も含める 3. 検証方法と仕様を決める ◦ ワイヤレスイヤホンと格安SIMにカテゴリを絞って検証 4. 設計・実装する ◦ テーブルを作らず、回答と絞り込みのマッピングを定数で ◦ APIも作らず、Frontendのみで簡易的に実装 5. テスト・分析する ◦ A/Bテストを実施、分析して次の仮説検証へ 実工数：1人日 事例① Web接客機能
27. テスト・分析・改善のループを回す リスクの高い部分から検証を進めて、学習して徐々に精度を高めていく 1. まずは使われるかを検証 ◦ 約22%のユーザーに使われた！ 2. 次にUIを改善して、選びきれるかを検証 ◦ A/Bテストで5%ほどCVRが上がった！ 3. 細かく数値を分析してブラッシュアップ ◦ おすすめ商品のUI変更、理由の追加 ◦ ハーフモーダルの掲出タイミング ◦ 質問と回答の内容改善 事例① Web接客機能 学習のための最小の実装・検証方法を選択し、最速で仮説検証ループを回せる
28. 事例② favlist（新規事業） 専門家やインフルエンサーの愛用品を発見・購入できるプラットフォーム • 新規事業では、会議室でどれだけ議論しても正解は出ない • 内部で完璧な合意を目指すのではなく、ユーザーから学習する 速度を最大化することが重要 ◦ 何を検証するか ◦ どこまで作るか ◦ どこは品質を担保して、どこは割り切るか • 立ち上げ期は事業責任者がPdMを担っていたが、途中から エンジニアがPdMを兼務する形にシフト
29. エンジニアがPdMを兼務することの価値 背景理解や合意形成のためのコミュニケーションコストが減り、コンテキストも集約される 事例② favlist（新規事業） コンテキストが集約されることで、何を作るかの最適な判断をスピーディーに行える
30. 事例③ AI-DLC（AI駆動開発ライフサイクル） AI-DLCとは、AWSが提唱する開発プロセス全体をAI前提で再構築し、AIが実行を主導し、人間が 監督と意思決定を行うアプローチ • Inception（開始） ◦ AIがビジネス意図を詳細な要件・ストーリー・ユニットに変換 ◦ チーム全体がAIの質問を積極的に検証（モブエラボレーション） • Construction（構築） ◦ AIが論理アーキテクチャ、ドメインモデル、コードによる実装、テストを提案 ◦ チームが技術的決定とアーキテクチャの選択について リアルタイムで明確化（モブコンストラクション） • Operation（運用） ◦ チーム監督のもとでIaCとデプロイメントを管理 https://aws.amazon.com/jp/blogs/news/ai-driven-development-life-cycle/
31. Inceptionフェーズにおけるエンジニアの役割 AI-DLCはディスカバリーのMVP構築においても活用できる • Inceptionでは何をどこまで作るかを決める ◦ AIのアウトプットが格段に速いため、多くの要求や機能を詰め込んだ ゴッドPRDになりがち • エンジニアがスコープを抑制する ◦ 何を検証すべきか、どこまで作れば学べるか ◦ 無駄な作りすぎを防ぐことができる • コンテキストを把握し、Constructionに繋げる ◦ 最適な設計・実装を選択できる 事例③ AI-DLC（AI駆動開発ライフサイクル） AIが広げた解決策を、検証のための最適なMVPに絞ることができる
32. 1. 課題を深く理解して解決策を考えられる 2. 実現可能性を早期に見極められる 3. 作るかどうかの判断の精度が上がる 4. 仮説検証のための最適な落とし所がわかる 5. AIのアウトプットが適切か判断できる 6. 分析結果から即座に次の仮説検証を回せる 3つの事例に共通するのは、エンジニアが何を作るべきかを見極め、学習速度を上げていること ディスカバリーにエンジニアがいることの価値【再掲】
33. AI時代に広がるエンジニアの価値と役割 5
34. エンジニアは「何を作るべきかを見極め、学習速度を上げる人」に役割を広げていく 「作る力」から「何を作るべきかを見極め、学習速度を上げる力」へ • 何を作るのか • 作るべきか / 作らないべきか • どう作るか / どこまで作るべきか • 何を捨てるべきか • どの順番で検証すべきか • AIのアウトプットが適切か コンテキスト ユーザー課題にDeep Dive 作る力 技術力が土台 技術力を土台に、ユーザー課題にDeep Diveして、 品質・コスト・スピード・スコープのトレードオフを適切に判断し、 アウトカムに繋げていく
35. • AIで作る速度は上がったが、価値に辿り着く速度はそのままでは上がらない • エンジニアがディスカバリーに入ることによって価値探索のスピードを加速 させることができる • AI時代において、エンジニアは「作る力」を土台に「何を作るべきかを見極 め、学習速度を上げる人」に役割を広げていく • ユーザーの課題を解決し、価値を届け続けるプロダクトを作っていきましょ う！ まとめ
36. PdM・デザイナー・エンジニア大募集中！ https://my-best.com/company/recruitment