Product Engineering Conference 2026

セッション概要 「プロダクトエンジニア」という言葉は、エンジニアの拡大解釈です。コードを書く人から、プロダクトに責任を持つ人へ。では、その解釈はどこまで拡大できるのか。私はエンジニアとして金融プロダクト「YELL BANK」を立ち上げ、PdMを経て、いまは事業責任者をやっています。エンジニアリングを事業の責任まで拡大解釈した、ひとつの極端な例です。 拡大解釈する利点を、私は「心技体」で捉えています。技＝スキル、体＝現場感覚（手を動かすこと）、心＝実感（自分が何を知り、何を判断できるかの解像度）。この3つがつながった状態を、規模が大きくなっても手放さないことが大切です。 組織は、大きくなると役割を分けます。でも他の職能を知らないまま分けると、心技体は別々の人に割れていく。調整役としてのPdMも、この分断の副作用だと考えています。かといって、分業が悪いわけではありません。いちばん強いのは「全部できる人が集まって、知った上で分業する」組織。拡大解釈は、その前提条件です。一度心技体をつないだ人どうしが組むから、分業が機能する。 現場感覚を持ったまま事業を見るから判断の解像度が上がり、意思決定が「決める」より「決まる」に近づく。短期の数字と長期の組織のような矛盾も、一人の中で統合されているから両取りの打ち手が見える。AI時代は、手を動かして自分の判断の解像度を上げられる人が、さらに強くなります。 このセッションは、領域を広げようとしている人へのエールでもあります。領域を広げるのは正直大変です。それゆえに「その方向で合っている」と伝えたい。立ち上げからグロースまでの実体験を通して、広げることの大変さと、それでも心技体をつなぎ続ける価値を話します。 Learning Outcome - 対象: エンジニアリングを事業まで広げたいプロダクトエンジニア、分業のあり方に悩むPdM・テックリード、組織構造を考えるマネージャー - 得られるもの: 1. 「拡大解釈」を心技体（スキル・現場感覚・実感）の統合として捉える枠組み 2. 「知らないままの分業」と「全部できる人が集まる分業」を分ける、組織構造の見方 3. 手を動かし続けることが、AI時代の意思決定の解像度を上げるという視点 4. 領域を広げる大変さは間違いじゃない、その方向で合っている、という確信（エール）

AIで開発スピードがコモディティ化した今、プロダクトの競争力は「どれだけ速く作れるか」から「顧客がお金を払ってでも解決したい課題を、いかにシャープに見極めて作れるか」へ移りつつあります。一方で、現場では「営業・CSから上がる要望をどう開発に活かすか」「作ったものが本当に刺さるのか」が見えづらい、という悩みは少なくないはずです。 estieの私たちが所属する開発チームではPdMを置かず、少人数で複数プロダクトを開発しています。この体制では、Dev（開発）とOps（営業・CS）が同じ目的を共有し、議論を通じて「何を作るか」を決められるかが、プロダクトの価値に直結します。 本セッションでは、営業・CSが「開発の当事者」になるために私たちが設計した仕組みを、明日から取り入れられる粒度で紹介します。一方的な共有で終わらせず議論の時間を明示的に設ける「Dev<>Ops定例」、preview環境とAIで爆速に作ったプロトタイプをその場でOpsに当てる検証、Dev側メンバーの商談同席、CS含めたVoCの棚卸方法、等々。Dev視点では価値がないと思った機能が顧客に刺さったり、Ops視点で難しいと思った要望が実は簡単に作れたり。議論の場だからこそ生まれる発見と、「Devが売上に」「Opsが開発に」コミットする当事者意識がどう育つかを、具体的な運用とともにお話しします。 営業、CSメンバーからも、実際の変化も具体的にお話しします。営業は「言っても変わらない」と諦めていた要望が、商談同席→その場で議論→AIで爆速プロトタイプ→顧客のWOW、を経て「届ければ形になる」へと変わりました。CS側でも、プロセスを通した迅速な開発と早期デリバリによって、顧客との信頼醸成に繋がったり、VoCシートの文言だけでは埋もれていた声が「より温度感が高い課題」「複数顧客に共通する課題」だと判明して優先順位を組み替える、といった発見が生まれています。 こういった発見や変化の積み重ねで、dev、opsともに、要望を集めるだけではなく、顧客課題そのものを見るといった意識に変化しています。

【概要】 ユーザーに価値を届け、事業を成長させる——これはプロダクトエンジニアの大きな醍醐味ですよね。でも一歩立ち止まって、「プロダクトが止まらないようにするには?」 を考えたことはありますか? UPSIDERは、法人カードやベンチャーファンドなど複数の事業を展開しています。 その根幹を支えるのが与信機能で、複数の経路から銀行データを連携し、継続的に与信計算・モニタリングを行っています。 この銀行連携が止まると、与信機能が停止し、どのプロダクトもユーザーに価値を届けられなくなります。 昨今のAIの進化により、恩恵を受けることがある一方で、サプライチェーン攻撃など日々攻撃も加速しています。こうした攻撃から与信機能を守り、可用性と信頼を継続させること自体が、"止めない"与信領域での、最大のプロダクト価値になります。 本セッションでは、セキュリティ対策のtipsや組織体制の紹介ではなく、与信基盤を「止めない」ために行った意思決定のプロセスをお話しします。 理想を言えば、複数の銀行データ経路は完全に分離し、ひとつが汚染されても他に影響しない状態を作るべきです。しかし、少人数のチームでそれをそのまま運用しようとすると、コストや運用負荷が大きくなり、結果としてプロダクト開発のスピードを落としてしまいます。 では、どこまで分離し、どこからは現実解を選ぶのか。 私たちが選んだのは、完全分離ではなく「論理的な分離」です。実行環境を接続先ごとに分け、秘匿情報の参照範囲を絞り、暗号鍵を接続先ごとに分ける。ひとつが漏洩しても被害が波及せず、影響範囲をすぐ特定できる構成です。 経営・事業・開発チームの制約を踏まえながら、現実解の線をどこに引いたか。その判断とトレードオフを共有します。 【Learning Outcome】 想定参加者 : 言語やフロントエンドバックエンドといった職能関係なく、プロダクト価値やアウトカムに興味があるエンジニア ・自分のプロダクトにおいて「止まると事業影響が大きい機能」を見極める観点 ・理想的な分離設計と、現実的な運用コストのバランスを取るための判断基準 ・攻撃・漏洩・障害が起きる前提で、被害の爆発半径を小さくする設計の考え方 ・可用性・セキュリティ・開発スピードのトレードオフを、事業と合意しながら進める方法

セッション概要 「プロダクトエンジニアは現場に行け」とよく言われます。 しかし、同じ接点を持っても、その業務を経験した人とそうでない人とでは、観察できる情報量が大きく異なります。 私は機械加工の現場で働き、その後エンジニアになり、現在は製造業向けSaaSを開発しています。この経験から、現場経験の有無が「観察の解像度」を大きく左右すると考えています。 例えば、現場の機械を見る場面。未経験者は「これは何をする機械か」に目が向きます。一方で業務経験者は、図面や道具がどこに置かれ、完成品がどこへ運ばれるか、という作業の動線と業務の流れに目が向きます。この視点こそが、要件定義やドメインモデル設計の精度を左右します。 本セッションでは、この「業務の流れを捉える視点」を分解し、何が観察を変えているのかを具体例で示します。 この視点は、AIを用いた開発でも土台になります。例えばAIエージェントの設計では、業務がどう流れるかを理解していなければ、適切な振る舞いを定義できません。どの順序で何を判断し、どこで人に委ねるか——その設計判断は、業務の流れを捉える視点があって初めて下せます。 弊社では、プロダクトエンジニアがCSを兼ね、自ら顧客接点を持つ仕組みをとっています。意図的に接点を増やすことで、経験のない領域でも観察の機会を作り出せます。 その上で、現場経験のある私は同じ接点からより深く業務の流れを読み取っています。つまり観察の解像度は、組織設計から生まれる接点と、個人が持つ経験の掛け算で決まると考えています。 言葉にできる業務知識はチームへ共有できますが、現場の流れをイメージする力は経験に根ざし、接点を増やすだけでは引き継ぎきれません。その境界がどこにあるのか——現時点での知見をお話しします。 Learning Outcome 対象の聴衆 - 専門ドメインのSaaS・AI機能を開発するPdE・PdM - ドメインエキスパートと協働する開発者。 得られるもの - 現場・顧客MTG・資料のどの接点でも、"モノ"ではなく業務の動線と時間軸に目を向ける、具体的な観点を持って臨めるようになる。 - 自社のAI機能やエージェントについて、出力や振る舞いが業務上妥当かを判断できる人がチームにいるかを見直し、いなければ補うための議論を始められる。

概要 AIによってプロダクトを「作る」スピードは大きく加速し、事業ごとに新しいプロダクトが生まれ、その数は今後ますます増えていきます。一方で、プロダクトが増えるほど、それを所有し価値を提供し続けるコストは、プロダクト数に応じてリニアに積み上がっていきます。 atama plusのプロダクト組織は、事業部ごとにエンジニア自身が顧客に会い、プロトを作り、FBを得るプロダクトエンジニアリングのサイクルを回しており、AIの活用によりさらに加速しています。 一方で、コアプロダクトが複数事業に共有される構造のなか、事業ごとの新規プロダクトも次々に生まれ、増え拡がるプロダクト群をどう所有し続けるかが、横断技術組織の中心テーマになっています。 本セッションでは、横断技術組織側で取り組む「プロダクト所有のエンジニアリング」について、3つの側面から設計と試行錯誤を共有します。 ① プロダクトの運用所有：DevOps責務をどう分担するか 横断組織がインフラ・監視・デプロイ・QAをコントロールプレーンとして持ち、各事業チームが自律的に開発・運用する体制への移行と、DevOps原則の再浸透に取り組んでいます。 ② 既存プロダクトのコード所有：所有権の境界をどう引くか モノレポを複数事業で共有する構造ではコードの所有コストが増大します。共通基盤を横断組織が、事業領域のコードを事業チームが所有する所有権分離を、大規模再構築なしで進めています。 ③ 新規プロダクトの所有設計：プロダクトをどう増やすか 事業ごとのプロダクト追加が進むと、技術スタック分散と連携複雑化により所有コストは指数的に増大します。それを防ぐ横断組織のゲートと支援の設計を紹介します。 Learning Outcome 対象 - 複数プロダクト・複数事業を抱える組織で戦略を描くEM・CTO・技術統括 - 事業の自律性と構造健全性のバランスに取り組むPlatform Engineer・シニアエンジニア 得られるもの - 「プロダクト所有」というフレームでエンジニアリングを捉え直す視点 - 複数事業で共有する既存プロダクトの、運用とコードの所有設計アプローチ - 新規プロダクト追加時に所有コスト爆発を防ぐ、横断組織のゲートと支援設計

セッション概要 プロダクトが成長し組織のサイロ化が進むほど、プロダクト開発メンバーは顧客やドメインから遠くなりがちです。役職や職能を越えて全員でプロダクトへ向き合う組織をつくりたい——そう願っても、何から手をつけ、どのように取り組みを広げていけば良いのか。確かな地図はなかなか見つからず、打った施策が点のまま終わってしまうこともままあります。 本セッションにあたって、私がプロダクト組織のマネージャーとしてこの3年で打ってきた20数個の組織づくり施策を棚卸しし、「マインドか仕組みか」「トップダウンかボトムアップか」の2軸で整理しました。2軸が構成する4象限を【啓蒙活動】【アラインメント】【協働の仕組み化】【制度の整備】に分類し、代表的な施策のWhy/What/Howと定量面・定性面の変化を具体的に共有します。 そして、整理から見えてきた結論をお伝えします。改善に効いた施策は点で独立しておらず、互いに増幅し合う一つのループ（＝フライホイール）として繋がっていました。その回り方はプロダクトのグロースとよく似ています。 信念を持ってビジョンを示し、まず少数の共感者を得る。ビジョンに向けたアクションを振り返り、改善を重ねる。最初は属人的な力が必要ですが、繰り返しながら仕組みへ落とし込むことで、アクションのハードルが下がっていく。定量・定性問わず好材料を見つけて周知することで、新たな賛同者が増え、次の推進が回り始める。やがてアクションは委譲され、ひとりでは到達できなかった変革へつながる。 周回を重ねることで個人への依存は減り、組織の自律的かつ持続的な成長への道が開けます。 組織づくりに唯一の正解はありません。規模・フェーズ・文化によって効く施策は変わります。だからこそ、個別の成功事例ではなく、自分の組織を診断し「次の一手」を検討するための地図と、改善ループの回し方を話したいと思います。 Learning Outcome 対象の聴衆: - 役職や職能を越えたプロダクト志向な組織を作りたいマネージャーやリーダー - 組織づくりの施策に行き詰まりを感じているマネージャーやリーダー 得られるもの: - 自組織の組織づくり施策を4象限で俯瞰し、偏りや空白の象限を診断する方法 - 点在する施策を互いに繋ぎ、自組織に合わせた改善ループの回し方

プロダクトエンジニアリングを推進するうえで、DevExを改善しようとするとき、多くの組織はまずツールやプロセスに手を入れます。しかし私たちが2年間の実践で辿り着いた答えは「コンテキストの設計」でした。 エンジニアが「何を作るか」は知っている。でも「なぜ作るか」「誰が本当に困っているのか」「この機能はどの判断から生まれたのか」を知らないまま実装に入ることが、手戻り・提案の少なさ・開発体験の悪さを生んでいました。ラクスのプロダクト部では、PdM・デザイナー・エンジニアが一つの組織として約40名が動いています。この2年間で、エンジニアが顧客課題や意思決定の背景を持った状態で開発に入れる仕組みを設計し、実践してきました。職能の壁を越えた協働は容易ではなく、失敗も多くありましたが、コンテキストを持ったエンジニアが動く組織は確実に速くなりました。 本セッションでは以下の流れで実践を紹介します。 ① なぜ「ツール」よりも「コンテキスト」がDevExを変えるのか ② 上流参加を実現するための仕組みをどう設計したか ③ 失敗したこと・変化として見えてきたこと 【Learning Outcome】 対象聴衆：プロダクトエンジニアリングに携わるエンジニア・EM・スクラムマスター。「仕様が降ってくる」「事業に近い開発がしたい」と感じている方。 得られること： ・DevExを「ツール改善」ではなく「コンテキスト設計」として捉え直す視点 ・エンジニアが上流から関わるための仕組みの設計手順と注意点 ・職能横断型チームでよくある失敗パターンと回避策

私のチームでは2026年4月から、職能固定の体制を廃止し「1人1案件・AIを活用して全員が全部できるプロダクトエンジニア」体制に2ヶ月間チャレンジしました。 体制の変化は大きく3つです。 ①エンジニア全員が専門外の領域も実装する ②プロジェクト計画書を開発のハブに置く ③QAは「プロセス監督」として進行管理・品質担保・障壁除去を担う 私はプロセス監督として3案件の同時進行を追いました。 最大の課題は「情報の分散と追跡コスト」。 これを解決するために、以下の工夫を行いました。 ・計画書を「正の情報源」とし、レビュアー・QA・PdM・AIが同じドキュメントを見る運用 ・仕様の空白（TBD・未定義）に気づき、決定を促す動き ・計画書の差分をAIで追跡するSkillと、エスカレーション基準のアラート化 やってみて気づいたのは、体制が変わっても「仕様の空白を埋める・ボトルネックを検出する・情報を届ける」というQAの本質は変わらないということでした。 結果、1案件あたりのリードタイムは旧体制と同等（平均32日）のまま、スループットは約3倍に。 品質面でも大きな不具合は発生しませんでした。 一方で「チームとして動く」ことの再定義やコンテキストスイッチの負荷など、未解決の課題も残っています。 職能の壁が溶ける時代こそ、プロセス全体を見る役割が効く。 その実践を、具体的な数字と仕組みでお話しします。 【Learning Outcome】 対象： ・プロダクトエンジニア体制や1人1案件運用を検討しているEM・PdE、AI時代のQAの関わり方を模索しているQAエンジニア ・AI前提の開発で、スピードと品質の両立に悩んでいる方 得られるもの： ・職能固定からプロダクトエンジニア体制へ移行したときの具体的な仕組みと課題 ・1人1案件体制を2ヶ月運用した実測値（リードタイム・スループット・品質）と、機能した仕組み ・計画書ハブ＋AI Skillで文脈共有コストを下げる具体的な運用方法

AIは、いまや"デザイン"を出力します。画面も、コンポーネントも、その実装も、プロンプト一つでそれらしいものが一瞬で出てくる。生成はすでにコモディティになり、ボトルネックは「作れるかどうか」ではなくなりました。 それでも、現場の品質はなかなか安定しません。"それらしい"と"正しい"のあいだには、まだ大きな溝があります。速く出せることと、妥当であることは別の問題です。では、出てきたものが妥当だと、いったい誰が、何を根拠に言えるのでしょうか。 AIが出力した画面を、私は"デザイン"だとは思っていません。デザインと呼ぶべきものは、その生成を正しい方向へ導き、検証する構造の側にあるのではないか。このトークで一番話したいのは、その問いです。 この構造は、テストハーネスに近いと思っています。コードの正しさはテストで担保する。それと同じで、生成物の妥当性を担保する仕組みがあっていい。私はそれを「デザインハーネス」と呼んでいます。捉え方は4つの層に分けています。生成に効く型としての制約、何を渡すかというコンテキスト、デザイン版のCIにあたる検証、結果を制約へ還すフィードバックループです。どれも抽象論で終わらせず、Figma・Storybook・コーディングエージェントをつないだ実際のワークフローとしてお見せします。 この仕組みは、デザイナーだけのものではありません。制約も検証も、エンジニアと一緒に決めるものです。それが「職能の壁を越える」の中身だと思っています。 【Learning Outcome】 対象： ・AI生成を実務に取り入れ始めたプロダクト開発者 ・デザインとエンジニアリングの境界で仕事をしている方 ・デザイナーがいない組織で、デザインを担当している開発者 得られるもの： ・AIの生成物を「妥当かどうか」で見るための観点 ・その結果として期待できる効果 　・制約を最小から育て、AIの出力を狙った方向に寄せられる 　・デザイナーとエンジニアが同じ言葉で品質を語り、責任の分担を決められる

「インシデントがなかった月の成果って、どう説明していますか？」 SRE・セキュリティ・社内情報システムを担うエンジニアが一度は直面する問いです。 予算を消費するが売上を生まない、インシデントがなければ成果が見えない、社内会議や経営報告の場で肩身が狭い、「守り」の組織が抱えるこの構造的な課題を本セッションでは正面から扱います。 EM of EMsとして3領域（SRE・セキュリティ・社内情報システム）を横断統括し、グループ会社の執行役員として成果を創出し、経営に伝えていった経験から、「守り」の組織がプロダクト成長に貢献するための組織設計と、経営・PdMへの翻訳手法をお伝えします。 ■「守り」組織が評価されない構造的な理由と突破口 コストセンターから「リスク管理・事業継続の担い手」への再定義がなぜ難しいのか。 組織の立ち位置を変えるための具体的なアプローチを論じます。 ■SRE・セキュリティのプラクティスを経営指標に変換した実例 ・エラーバジェット管理を経営のリスク判断に翻訳し、意思決定スピードが5日→2日に改善した事例 ・監査指摘件数の削減を事業KPIとして経営会議で語った手法 ・Cloud Operator Days Tokyo最優秀オペレーター賞を受賞するチームを作るまでの人材育成設計 ■専門領域が異なる3チームを束ねるEM of EMsの優先順位設計 SRE・セキュリティ・社内情報システムの専門性が異なる3チームを横断管理するときの難しさと、機能させるための具体的な組織設計を紹介します。 【Learning Outcome】 ・守りの組織の成果を経営・PdMに伝える翻訳フレームワークを明日から使える形で持ち帰れる ・SRE・セキュリティ・社内情報システムを横断するEM of EMsの優先順位設計手法を具体的に学べる ・コストセンターと見られているチームが事業貢献として認められるための3つのアクションを得られる

生成AIの導入が進む中、KPIだけでは評価が難しくなり、「Evals（評価セット）」が重要だと言われるようになりました。Evalsとは、AIの出力品質を継続的に評価するための仕組みです。しかし、実際に企業でEvalsを作ろうとすると思わぬ壁にぶつかります。 ある企業では、カスタマーサポートの問い合わせを集めて「正しい対応」をベテラン社員に書いてもらったところ、ベテラン同士で回答が食い違いました。そして「どちらが正解なのか」という問いに、誰も答えられませんでした。結局突き詰めれば、AIによって新たな評価設計が必要になったのではなく、これまで人間の暗黙知や属人的な判断によって成立していた品質管理の曖昧さ（自社独自の「良さ」の指標の欠如）がAI導入によって可視化されたと言えます。 世の中的によく言われるのは、「AIは非決定的だからEvalsが必要」ということでしょう。しかし本セッションではもう一歩踏み込み、Evalsを単なるAI品質評価の仕組みとしてではなく「組織が何を良い仕事と考えているのかを言語化する仕組み」として捉え直します。 ・なぜAI時代にEvalsが注目されるのか ・KPIだけでは管理できない品質とは何か ・人間が持っていた独自の評価系とは何か ・Evals設計によって露呈する組織課題とは何か ・AI時代の競争優位はどこに生まれるのか AIと付き合うことの本質的な難しさと、プロダクト開発組織に求められる新しい品質管理について考察します。 対象者 ・プロダクトエンジニア ・テックリード、EM、VPoEなど ・プロダクトマネージャー ・AI機能を持つプロダクトを開発・運用している方 ・AI導入や業務変革に取り組む方 参加者が得られること ・Evalsがなぜ必要なのかを技術以外の観点から理解できる ・KPIとEvalsの役割の違いを理解できる ・AI導入で発生する組織課題の構造を理解できる ・「良い仕事」を言語化する重要性を理解できる ・AI時代の品質管理と競争優位について新しい視点を得られる 参考記事： KPIで測りきれないものを技術者ぶってEvalsでどうにかしようとしたらベテラン同士で正解が割れた https://note.com/ak_iii/n/n10c58a145b05

クロスボーダーM&Aでグループインした米国企業のValue Up施策の一つとして、日米混成チームでtoCモバイルアプリをゼロから立ち上げています。これまでにない顧客体験と来店動線を生むと同時に、顧客起点の最適なマーケティングを可能にする、事業価値に直結するプロダクトです。 開発には技術以前の難しさがありました。デザインでは日本側に専門性の蓄積、現地メンバーに市場の肌感覚と事業ドメインの深い理解があり、どちらが正しいかではなく双方の強みを活かす折り合いが求められました。機能開発では、州ごとに法規制が異なる米国ならではの難しさに直面し、そこに時差と言語の壁が重なります。 本セッションでは、現地に身を置き日米双方を理解できる立場にいた私が、何を意識してハブを担ったかをお話しします。鍵は二つ。一つは、ドキュメントが常に日英ペアで生まれ続ける仕組みづくりです。文書化自体は当たり前ですが、翻訳と維持をAIのスキルやメモリとして開発ワークフローに組み込み、日本語を正とした設計書約100本が常に両言語で更新され、言語と時差の壁は構造的に下がりました。もう一つは、最後に物事を動かすのは直接のコミュニケーションだということです。北米メンバーとは現地で顔を合わせ、相手の文脈を学ぶ姿勢で対話を重ねて信頼を構築。その上で実店舗やオペレーションを共に見て回ると、来店動線や機能の仕様判断は速く確かになりました。デザインも、構造と一貫性は日本のデザインシステムが、トーンや言葉選びは現地が担う形に整理し、現地ユーザーに自然に届く体験へと磨き上げました。このような意思決定の積み重ねをプロダクトの価値へ変換する過程を、どのチームにも持ち帰れる原則に一般化して共有します。 【Learning Outcome】 対象： ・多拠点・多文化のチームでプロダクトを作るすべての人 ・職能や組織の間に立つエンジニア・PdM・デザイナー ・AIをチームの仕組みに組み込みたいエンジニア・EM ・事業文脈でプロダクトを推進したい人 得られるもの： ・強みが異なるメンバー間で折り合いをつける意思決定の考え方 ・非同期でも開発を最大限加速させる仕組みと直接対話の使いどころ ・M&AのValue Upという経営文脈でプロダクトエンジニアが発揮できる価値

■セッション概要 AIは実装の経済を変えました。動くコードを書くコストは下がり続け、エンジニア個人の生産量は確かに増えました。それでも、プロダクトが価値を届ける速度はほとんど変わっていません。増えた生産量はどこに消えているのか。 チームでコミットからリリースまでの時間を計測したことがあります。実作業は全体の10%、残りの90%は判断待ち、レビュー待ち、他チーム待ちでした。この構造のまま実作業をAIで半分にしても、全体は5%しか縮みません。制約は手を動かす速度ではなく、職能の間の合意と判断の待ち時間にあります。 計測には罠もある。生産量やPR数といった測りやすい数字は、AIで伸びます。しかしそれは作った量であって、価値が届いたのではありません。測りやすいものを測ると、速く作れるほど速く、使われない機能が積み上がります。 では「作るべきか」は何を基準に判断するのか。ユーザーは機能を買っているのではなく、片付けたい用事のためにプロダクトを雇っています。作れるものがいくら増えても、ユーザーの用事は増えません。コアだと信じた領域がマネージドサービス数十行に置き換わった誤算も、半年計画の大規模刷新を4ヶ月目にロールバックした失敗も、振り返れば「誰のどの用事を片付けるのか」を問わないまま、作れるものを作っていました。 本セッションでは、この構造を設計し直す方法を話します。価値が届くまでの流れを測って制約の位置を特定する。職能ごとに違う風景を見ているPM・エンジニア・SREの前提を、一枚の絵で揃える。そして機能ではなくユーザーの用事を起点に「作るべきか」「いつやめるか」を判断する。「作れるか」にはAIが答えてくれる。「作るべきか」には誰も代わりに答えてくれない。その判断を計測と用事の理解で支えることが、プロダクトエンジニアの中心的な仕事になると考えています。 ■Learning Outcome 対象: エンジニアを中心に、PM・デザイナー・SREなど、プロダクト開発の意思決定に関わるすべての職種 - AIで実装が速くなってもプロダクトが速くならない、構造的な理由 - 測りやすい生産量ではなく、価値が届くまでの流れを測って制約を見つける方法 - 「作るべきか」「いつやめるか」をユーザーの用事から判断するための基準

営業から設計、開発までやる中で、ずっと引っかかっていることがあります。アウトカムを優先して作ったはずの機能が、なぜか使われない。数日後、こんな声が届きました。「〜できるようにはなったんですが、そのための入力が増えて大変で…」。業務全体で見ると、むしろ作業は増えていました。 なぜか。多くの業務ソフトは"リソース（モノ）の一覧管理"を中心に作られているのに、現実の仕事は"フロー（コト）"、つまり申請して、承認を得て、次の人へ手渡すで進む。原因はそのズレではないか。 機能を比べても答えは出ません。承認も通知もAPIもカスタム項目も、成熟市場ではいずれ横並びです。「設定すれば何でもできる」もよく聞きますが、あれは組み込みのコストと工数を顧客に押し付けているだけ。業務を分かったうえで最初から備わっている／カスタムできることとの差は、思っているより大きいです。 たどり着いたのは、業務ソフトの競争優位は機能の数ではなく、その業務をどんな概念と関係性で捉えるか—メタモデル—に宿る、という考えです。何を中心に世界を切り取るかで製品の世界観が決まり、最適な形はドメインごとに全く違う。だから業務を「作る・変える・関連付ける・派生させる・責任を移す・判断する・通知する」に分解し、自分の領域で中心に据えるべき概念を見極める必要があります。商習慣の違いも、税制や帳票ではなく「誰が決め、誰が責任を持つか」だと思っています。 DDDがドメインエキスパートの知識を正確にモデルへ写す技法だとすれば、話したいのはその一歩先、プロダクトエンジニア自身がエキスパートになることです。Scalebaseの実例も出しますが、一つの業界の例として、自分のドメインに置き換えられる形で話します。 Learning Outcome 想定：業務系・BtoB SaaSのプロダクトエンジニア／PdM／アーキテクト／EM。機能比較や曖昧な「アウトカム」論から抜け出したい方。 持ち帰れること： ・「設定すれば何でもできる」と「業務を分かった設計」の差を見抜く視点 ・自分のドメインで中心に据えるべき概念を見極め、メタモデルとして設計する考え方 ・商習慣を「誰が決め、誰が責任を持つか」で捉え直す視点 ・業務をアクションに分解し、機能ではなく構造で価値を捉える視点

株式会社hacomonoでは2023年末に「プロダクトエンジニア（PdE）」という職種を設け、「プロダクトの成長を軸に越境していくエンジニア」と定義しました。職種の認知は浸透しましたが、次の壁が立ちはだかりました。フルリモート環境では、先輩の背中からこだわりを盗む機会が極端に少ない。意を決して始めた「業務外×6ヶ月×要件定義からリリースまで」の施策は、日々のタスクに押されて中だるみし、リリース0件で頓挫しました。 この失敗を血肉に変えて開発したのが、映画『スター・ウォーズ』の師匠（ジェダイ）と弟子（パダワン）の構図をモデルにした「プロダクトエンジニアJEDIプログラム」です。「通常業務のタスクをそのまま材料にする」「2ヶ月の短期集中サイクル」へ大転換し、フルリモートでも職人の技術と思考（秘伝のタレ）を地続きで伝承する仕組みを作りました。AI時代においても変わらない、むしろ重要度が増した「顧客価値を考える力」。開始して4ヶ月の運用の中でも参加者には「PRDを越えた顧客視点での仕様提案」など確かな変化が生まれています。 このセッションでは、「業務外×長期」で失敗した育成施策の反省から、通常業務を教材にした2ヶ月短期集中サイクルへ転換した背景と設計思想、師匠と弟子（JEDI）モデルでリモートでも技術と思考を伝承する具体策、そして参加者に起きた変化の実例までを、失敗と学びを軸に共有します。 【想定する聴衆】 ・育成施策が中だるみ・形骸化してしまった経験のあるマネージャー ・リモート環境でメンバーのプロダクト思考や越境マインドを育みたい方 ・エンジニア組織の育成プログラム設計に悩んでいる方 【お話しすること】 ・「業務外×6ヶ月」がなぜリリース0件で頓挫したのか——リモートの罠 ・日々の業務を教材にする「地続き感」と「2ヶ月集中」の設計思想 ・「技術（テクニカル）」と「プロダクト（マインド）」の2軸による壁打ち ・アンケートから見えた弟子たちのリアルな変化と成長の収穫 【持ち帰れること】 ・育成の「中だるみ」「後回し」を防ぐ実践的なアンチパターン ・業務負荷を上げずに技術とマインドを引き上げる仕組みの作り方 ・「動くコード」の先にある「顧客価値」へ目を向けさせるフィードバック手法

【セッション概要】 私は過去に検索・推薦ドメインのチームで、ドメインに閉じた権限と責任を持って開発をしていました。人数を増やさずに四半期で数十本のA/Bテストを回し、2020年にはこの体制を「フルサイクルエンジニア」として登壇・紹介しています（ https://youtu.be/fh0PC06ky-U ）。 一方で、ユーザー体験を大きく変える改善は、関連ドメインの他チームのヘッドカウントの交渉が必須でした。よくできた体制でしたが、境界の外に出るには毎回、越境が必要でした。 越境とは、 **「本来引き直すべき境界を、個人の善意で覆い隠す対処療法」** ではないかと考えています。私はこの、引き直されずに積まれた境界の歪みを「越境負債」と呼んでいます。 技術的負債はコードに溜まり、リファクタリングで返済できます。越境負債は責任の境界に積まれ、組織とプロダクトの輪郭を引き直すことでしか返済できません。そして、越境が称賛されるほど、この負債は計上されにくくなります。 本セッションでは、越境負債という考え方を以下の構成で紹介します。 ・個人のタスクと組織構造：越境が常態化するチームの構造 ・構造と役割の整合性：職能とロールの分離。その実践と、まだ解けていない課題 ・プロダクトの輪郭：プロダクト定義の狭さが、越境負債を決める 越境を否定するものではありません。探索としての越境は、境界の歪みに気づくシグナルです。区別したいのは、それが探索なのか、設計の失敗の常態化なのか、です。 AIの普及でコードを書くコストが下がり、境界の設計判断がかつてなく問われています。壁を越える前に「なぜ、ここに壁があるのか」を確認する。本セッションが、自身のチームの境界を見直すきっかけになれば幸いです。 【Learning Outcome】 ◆対象の聴衆 ・越境が習慣化しているプロダクトエンジニア ・プロダクト組織を再考したいEM・テックリード・PdM ◆得られるもの ・越境を「境界設計」の問題として捉え直す視点 ・探索の越境と、設計の失敗の常態化を見分ける判断軸 ・確認のための問い「なぜ、ここに壁があるのか」

コードを書く時間も、データを分析する時間も、AIにより劇的に短縮されました。では、何でも速く作れる時代に、あえて速度を落とすべきなのはどこでしょうか。本セッションでは「対話するだけでWebサイトが完成する」新規AIプロダクトを0→1で立ち上げ、成長を模索してきた実体験から、意思決定の「不可逆性」を現場のコードとDB設計に落とし込んだ実践を紹介します。 私たちは2つの異なる観点で意思決定しています。ひとつは可逆な領域。本番データの分析・改善策の決定・実装・効果の観測を、Claude Code や Skills を活用してエンジニアだけで回しきります。離脱箇所をAIに分析させて見極め、その場で実装し、リリースしてユーザー行動の変化を観測し、また次の手を打つ。間違えてもすぐ戻せるから、走りながら考えます。 もうひとつは不可逆な領域、とりわけDB設計です。スキーマのマイグレーションはデータ消失や機会損失のリスクを伴い、現実的にやりなおしが困難です。簡単な例をあげると「サイトは一人のユーザーが所有する」と初期要件に従い素直に設計すれば1対多で済みますが、複数人での共同編集(いまや多くのWebサービスで「あって当然」として定着した体験)を後から足すには、所有者前提のスキーマを多対多へ作り直すことになります。ここで考慮するのが「今必要なものだけ作る」というYAGNI原則を"あえて緩める"判断です。すべてを先回りするのではなく、ユーザーが「あって当然」と期待する前提を観測し、確度が高い未来だけをスキーマに織り込む。観測された事実から賭けどころを見極めてきた進め方を紹介します。 可逆も不可逆も、共通するのは「観測した事実から確率的に判断する」こと。これこそがAI時代のプロダクトエンジニアの判断のポイントだと考えています。 Learning Outcome - 目の前のタスクを「可逆/不可逆」で仕分け、かけるべき慎重さを判断する視点 - 不可逆な設計判断で「どこまで先を見通すか」を、データから根拠づける具体的な手順 - 可逆な領域で、分析も実装もAIに高速に回させて打ち手にたどり着く進め方

メルカリのクレジットカード「メルカード」の入会促進キャンペーンを、PdMである登壇者がClaude Codeとともに調査・設計・実装・QA・本番リリースまで一人で完遂した記録です。通常ならPM・Backend・BFF・iOS・Android・QAの最低6名で組成するプロジェクトを、6領域(BE/BFF/iOS/Android/Infra/Data)・9リポジトリ・22のマージ済みPRで本番稼働まで届けました。 本セッションの主役はAIの使い方ではなく、「職能を越えた先で何が起きたか」です。PdM経験が技術判断にそのまま効いた場面(リリース日から逆算して実装先を早期に決めた方針判断、複数リポジトリのレビューを並行処理するマルチタスク)、レビュアーから「仕様面の判断はPdMの強み」と評価された点と逆に頻発した指摘の中身、Specが「事前合意書」から「実装に追従する記録」へ変わった、といったプロセス・成果物の変化を、実体験に即して紹介します。 AIだけでは超えられなかった壁も率直に共有します。ドキュメントにない開発慣習に何度も阻まれ、リリース後のlatency悪化はTLの判断なしに対応できず、レビュアーからは「まだ自分たちでやる方が圧倒的に速い」と率直に評価されました。毎日が未知の連続で、自信のあった領域でも初心者の感覚に戻る——それを支えたのはコードスキルではなく、「自力で分析し選択肢を整理してTLに判断を仰ぐ相談の型」「完全理解より要点把握の都度学習」「失敗を次の資産に変換する姿勢」でした。

◼️セッション概要 「Compound Engineering」とは、書いたコードや作った仕組みが、次の開発を加速させる資産として複利のように積み上がっていく開発のあり方です。線形ではなく指数関数的にアウトプットが伸びる状態を指します。 プロダクト思考だけでも、基盤思考だけでも、この複利は生まれません。「ユーザーに届ける機能」を起点に「将来の自分たちの開発速度」まで設計に織り込み、AIで実装コストを圧縮する。この三位一体が揃った時、エンジニアのアウトプットは跳ね上がります。 多くの現場で、プロダクト開発と基盤改善は別レーンとして扱われ、「機能を出すか、負債を返すか」の二者択一になりがちです。しかし AI が実装コストを下げた今、この前提は崩れています。プロダクト要求から逆算した基盤設計を、AI と共に高速に積み上げる——これが Compound Engineering の実装方法です。 本セッションでは、長年運用されてきた Pairs の開発を題材に、事業要件から逆算してテスト基盤を再設計し、AI を活用して大規模に展開していった事例を共有します。「いま書いているコードは、自分たちの未来の速度を上げているか？」 という問いに、明日から使える観点を持ち帰ってもらえるはずです。 ◼️Learning Outcome（対象の聴衆と、その人たちが得られるもの） 対象は、プロダクト開発と基盤改善の両立に課題を感じているエンジニア、テックリード、EMです。 参加者は、以下を持ち帰ることができます。 - 書いたコードや仕組みを「次の開発を加速させる資産」として設計する、Compound Engineeringの考え方 - 事業要件やユーザー価値を起点に、開発基盤へ落とし込む視点 - AIによって実装コストが下がった今、基盤改善をプロダクト開発の中に組み込む方法 - 「機能開発か負債返済か」の二項対立を超え、未来の開発速度を上げるための判断軸