PdEConf 2026で考えた「越境」とプロダクトエンジニアリング

AgileCo-Creation StartupEvents-tonaka

こんにちは。チームCOSTAの渡仲です。

先日、Product Engineering Conference 2026（PdEConf） に参加してきました。「プロダクトエンジニアリング」をテーマに、開発の現場からデジタル庁まで、多様な立場の方が知見を持ち寄るカンファレンスです。

ところで、そもそも「プロダクトエンジニアリング」とは何でしょうか。

個人的には、この言葉はまだ定義が定まりきっていないと思っています。
イベントの中でも登壇者それぞれが自分の現場の言葉で語っていたことからもそのように感じました。しかし不思議なことに、会場のあちこちで同じ言葉たちが飛び交っていました。

越境、ドメイン知識、コンテキスト、アウトカム、責任、対話……

まるで、示し合わせたかのような頻出ワードたち。あの日から、私の頭にはこれらの単語が渦巻いています。
さて、あの日の印象に残ったセッションを振り返りながら、大きなテーマとなっている「プロダクトエンジニアリング」について紐解いていこうと思います。

セッションを振り返る

1. AIで実装は速くなった。では、人は何をするのか

今回のカンファレンス全体を通して、最も強く残った問いはこれでした。

AIによって生まれた時間や能力を、私たちは何に使うのか。

AIを使えば、コードを書く、資料を作る、調査を整理するといった作業は確実に速くなります。一方で、実装が速くなったからといって、プロダクトが同じ割合で速く価値を生むとは限りません。何を作るのか。なぜ作るのか。誰の何が変われば成功なのか。こうした問いに答えないまま実装だけを高速化すると、目的地が分からないまま乗り物だけが速くなります。到着した場所が目的地とは限りません。

「AIで実装は速くなった。なのにプロダクトは速くならない。」というセッションは、まさにこの状況を扱っていました。AIがコードを爆速で吐き出しても、その成果物が職能ごとの「待ち」を巡るうちに、リリースまでの時間はさほど速くならない。
だからこそ、職能の壁を越えて価値のフローを設計する必要がある、という指摘です。AIで短くしたいのは、コードを書き終えるまでの時間ではなく、ユーザーに届け、反応を確かめ、次の学びを得るまでの時間なのだと思います。

2. エンジニアが「なぜ作るか」を知っている組織は速い

前章の問いに答えていたのが、このタイトルのセッションです。

ポイントは、開発の速さ＝「何を作るかを決める側」の質と速さ、という視点の転換です。セッションでは、プロダクト理解が3つの階層で整理されていました。

  1. プロダクト仕様：今の製品が何をするかという「答え」
  2. STP：誰に、どの立ち位置で届けるかという「軸」
  3. ドメイン：市場や顧客を理解し、自ら立て続ける「問い」

このうち、全職種が持つべきなのは3のドメイン、つまり「問い」のレベル。
仕様という「答え」だけ渡されて作るのではなく、どんな問いに向き合っているのかを全員が知っている状態が「なぜ作るかを知っている組織」です。そしてそれは、エンジニア個人が気合いで情報を集めることではなく、一次情報に触れられる・意思決定の背景が残っている・上流の対話に参加できる・効果を確認できるという「仕組み」で実現するものだ、という話でした。

なお、AI時代のWhy情報とHow情報の扱いについて、個人的には、Whyは攻め（プロダクトの価値に繋げるための情報）、Howは守り（保守面など、プロダクトの構築情報を残しておくことに意義がある情報）として、どちらも重要だと考えています。
WhyかHowかの取捨選択ではなく、それぞれをどう残し、どう使い分けるか。
COSTAでも今、効果的なコンテキスト設計の検証を進めているところです（この話はいずれ別の記事で）。

「なぜ作るか」が言語化された好例：行政の使命

「なぜ作るかを知っている組織」の分かりやすい実例が、デジタル庁のセッションにありました。セッションの中で、行政の使命として語られていた「国民の可処分時間を創出する」です。

この使命、社内の他の参加者との振り返りでも話題に上がりました。
リチャード・ルメルトの『良い戦略、悪い戦略』では、悪い戦略の典型は、聞こえは良いものの具体的な行動を何も導かない空疎なスローガンだとされています。

では「国民の可処分時間を創出する」はどうか。
私は、この言葉は判断基準として機能すると考えます。「この機能は国民の時間を増やすか？減らすか？」と問えば、やること・やらないことを仕分けられる。方針から具体的な行動や判断を導き出すことができるわけです。
空疎なスローガンとの分かれ目はまさにここで、組織全体で向かうべき方向がこのレベルで言語化されていれば、現場の一つひとつの判断は迷子になりにくいはずです。

しかもこの使命は、作った機能ではなく、その先で人に起きる変化を示しています。機能をリリースした。処理速度を上げた。AIで作業時間を減らした。これらは重要ですが、それだけではユーザーの生活や仕事が良くなったかは分かりません。作ったものの先で、誰の行動や状態がどう変わったのか。
そこまで見て初めて、プロダクトの仕事が一周します。

そして、AIでHow（作り方・進め方）がどれだけ変わっても、この「方針を定義する仕事」は人と組織に残ります。むしろHowが自動化・効率化されてスピードが上がったときこそ重要です。進む方向が少しズレたまま高速で走れば、間違った場所により速く、より遠くまで到達してしまうからです。
組織の形が変わっても、やるべきこと・向かう方向性は鮮明であるべき。デジタル庁の使命は、その「変わらない部分」のお手本のように感じました。

3. 価値に近づくために、境界を越える

では、これまで職能の壁の向こうにあった情報や判断へ、どう近づけばよいのか。ここで繋がるのが、イベント全体の大きなテーマ「越境」です。

境界を越えると言われると万能人材を想像してしまいますが、職能の壁を低くしようとして「何でもできなければならない」という高い壁を建ててしまっては本末転倒です。今回のセッションや感想戦を通して、私は越境を次のように捉えました。

越境とは、他の職能を奪うことではなく、プロダクトの価値に必要な場所まで、関心・対話・判断の範囲を広げること。

全員が同じ仕事をするのではなく、それぞれの専門性を持ったまま、境界の部分を少し重ねる。その「染み出し」が、判断の手戻りや伝言ゲームを減らし、組織を速くするのだと思います。

ただし、越境のために情報を増やし続けると、別の問題が起きます。全員をすべての会議に呼べば情報は共有されますが、同時に全員が順調に疲弊します。そこで印象に残ったのが、コンテキストは引き算でもあるという考え方です。意思決定の背景や一次情報をストックしつつ、誰にとって・どの判断に必要な情報かを選び直す。コンテキスト設計とは、情報の倉庫を大きくすることではなく、必要なものを取り出せる棚を作ること。AI活用も、ツールを配るより先にこの棚を設計する。これはAIに限らず、人間のオンボーディングにもそのまま効く話です。

越境で価値を見る範囲を広げ、コンテキスト設計で判断できる状態をつくる。次に必要なのは、判断のよりどころとなる「何を良いとするか」の共通認識です。

4. 「良い仕事」を考えたら、自分たちの仕事が見えてきた——Evalsという第2の評価系

次に、AIプロダクトの評価に関するセッションです。

ここで、何やら怪しい単語が出てきます。Evals。ほぼDevilです。
響きが怖いので、字面で理解するために辞書を引いておきましょう。

【辞書検索結果】

Devil（デビル）
 1. 悪魔、魔物。
 2. （the Devil）魔王、サタン。

さて、AIを組み込んだプロダクトは、従来のKPIだけでは品質を評価しきれません。そこで必要になるのがEvalsなのですが、このセッションの核心はテクニカルな話ではありませんでした。

【辞書検索結果】

Evals（イーバルズ）
 Evaluations（評価）の略。AIやLLM（大規模言語モデル）の出力品質を
 データセットと採点基準を用いて再現可能に測定・検証する仕組み。

Evalsを設計するとは、「良い仕事とは何か」を決めること。

Evalsを作ろうとすると、その前に大きな問いへぶつかります。そもそも、私たちは何を「良い仕事」と呼んでいるのでしょうか。
例えば、カスタマーサポートの良い回答とは、短い回答でしょうか。正確な回答でしょうか。相手が次に困らないところまで先回りする回答でしょうか。状況によって例外があるなら、どこまでをAIに任せ、どこからを人が判断するのでしょうか。

そしてEvalsを作ろうとすると、多くの組織でこれが露呈するそうです。
「あれ、うちの会社、『良い仕事』を定義してなくない…？」
会場のあちこちから、心のざわめきが聞こえた気がしました。

Evalsを作るためのステップとして紹介されていたのは以下です。

  • 業務の棚卸し
  • 期待値の言語化
  • 合意形成
  • 例外処理・線引きの明文化

これって、AIがなくても本来やるべきだったことのリストに見えませんか。
AIを評価するために始めたはずが、組織としての自己理解を深める作業になっている。AIを導入しようとしたことで、先送りにしてきた宿題が目の前に現れました。

AI活用がうまく動かないとき、その原因の多くはAIの性能ではなく、自分たちが「良い仕事」を言語化できていないことにあります。だから、うまくいかなかったときの受け止め方が分かれ道になります。

  • 「AIの問題」として諦めるか
  • 「自分たちの言語化の問題」として向き合うか

後者を選べる組織だけが、失敗を学習に変えられます。
KPIよりもEvals、そしてその根っこにある「良い仕事の定義」。

ここで、自分の仕事について振り返ってみました。
例えば提案書を作る際。
顧客の要望、作業内容、体制、費用は書かれていても、私たちが関わることで、顧客やユーザーにどのような変化が起きるのかが十分に書かれていないことはないか。

システムを作ることや機能を提供することが契約上のゴールになると、その先のアウトカムは「大事だとは思うけれど、後で考えるもの」になりがちです。しかし、最初に期待する変化を言葉にできなければ、途中で何を優先し、何を作らないかを決める基準も弱くなります。

そこで、まずは提案やバックログに、次の問いを置いてみたいと考えています。

  • 誰の、どのような困りごとを減らしたいのか
  • この取り組みによって、どのような行動や状態の変化を期待するのか
  • その変化を、どのように確かめるのか
  • 結果から、ドメインについて何を学び直すのか

イベントで聞いたEvalsの話は、AIの評価方法だけでなく、自分たちの提案や開発が何を目指しているのかを問い直すきっかけになりました。

付箋で辿る、変化の連鎖

ここからは、カンファレンス後に自分のメモを広げて整理した考察です。付箋をぺたぺた貼りながら、変化の連鎖をたどってみました。（※ここでガリレオのBGM）

AIによる変化 → 作業領域の拡大

出発点はAIによる変化です。作業の効率化・時間短縮、レビューの省力化、専門知識がなくてもAIを使えばある程度できてしまう、など。その結果、個人が使える時間と、遂行できる作業領域が増えました。

バトンパスゾーン＝「染み出ししろ」が広がった

もうひとつの変化が、コンテキストの共有です。AIネイティブな組織を作ろうとすると、コンテキストが全体に共有され、情報が役割に閉じなくなっていきます。

すると何が起きるか。リレーで例えると、隣の職種とのテイクオーバーゾーン（バトンパスゾーン）が広がるイメージです。これまでは自分の走路だけ見ていればよかったのが、バトンを渡す・受け取る区間が長くなり、隣の走者の領域が見えるようになる。

  • これまでの担当領域よりも外側の情報によって、内側で発生していた課題が解決できそう
  • 外側の課題も見えるようになった

この広がったゾーンこそが「染み出ししろ」（糊しろの「しろ」）なのだと思います。染み出せる余白が構造的に生まれた、ということです。

越境の先で、エンジニアの役割が変わる

作業領域の拡大と染み出ししろの拡大が合わさると、組織・職能間の越境が起きます。まず一部のエンジニアの作業領域が広がり、やがてエンジニア全体に求められる役割が変わっていく。

あるセッションでは、これからのエンジニア像について言及されていました。

  • ユーザー視点・ビジネス視点を持つのが当たり前になる
  • アウトカムに重点が置かれる
  • 責任の範囲がコードからプロダクトにまで広がる

この能力は座学で簡単に身につくものではありません。とのことです。（受け身）
発表の中で勧められていたのは、事業を立ち上げるなどの経験です。個人事業でもOK。
例えば、副業で八百屋をやるとドメイン知識と在庫管理の痛みが同時に学べます。

「越境」は過渡期の言葉かもしれない

さて、ここで少し立ち止まりたいのが「越境」という言葉そのものです。

越境という言葉は、過去の基準（役割分担）と今の基準の差分を表現しています。つまり「境界がある」前提の言葉です。ということは、越境が当たり前になった世界では、この言葉は使われなくなるのでは？ 過渡期にしか使われない言葉のような気がしています。

実際、現場ではすでにそれぞれの立場で担当する領域が曖昧になってきています。曖昧になっているのに、組織の役割地図がまだ更新されていない。ここに今のモヤモヤの正体があるように思います。

もし組織構造を具体的に再定義するとしたら、どんな絵が描けるでしょうか。

  • 既存職種の定義が変わる
  • 境界領域を担う新しい役割・表現が生まれる
  • 職種より、成果を担う単位が中心になる

拙者絵が苦手なもんで、字で書いてみました。

「プロダクトエンジニアとは？」を言語化する

この流れの先にあるのが、カンファレンスの主役「プロダクトエンジニア」です。ここまでの整理を踏まえて、私は今こう捉えています。

プロダクトエンジニアとは、何でも一人で作れる人ではなく、技術を起点にしながら、価値を生むために必要な問い・対話・検証へ、責任の範囲を広げられる人。

求められる能力に分解すると、こんな感じです。

  • プロダクトによって生じる影響全てに責任を持つ／持とうとする
  • ユーザーやステークホルダーとコミュニケーションを取れる
  • 機能を作って終わりではなく、検証しながら改善できる
  • ユーザーが得る価値と実装判断を繋げて考えられる

この4つを並べて眺めていると、段々と点と点がピースで繋がり…点と点が線でつながり始め、胸ポケットから、欠けていたピースが現れました。

ユーザーへの価値にフォーカスする。作って終わりではなく、検証しながら改善する。ステークホルダーとの対話を重ねる。
そう、アジャイルやスクラムが大切にしてきた価値観と、かなり重なるのです。
「プロダクトエンジニア」という言葉は新しくても、その中身はアジャイルの実践と地続きなのかもしれません。アジャイルに強みを持つクリエーションラインとしては、これまで積み重ねてきたものがそのまま活きる領域だと感じました。

AIとの関係にも、ここにヒントがあります。AIは一発で正解を出す装置というより、試すためのコストを下げる存在です。
判断する。小さく作る。結果を見る。学ぶ。そして次の判断を変える。
スクラムが持つ透明性・検査・適応のサイクルと組み合わせれば、AIで速くした作業を、速い学習へ変えられます。

そして大事なのは、これを各組織の中で言語化・定義しておくことだと思います。「プロダクトエンジニアリングをしよう！」と号令だけかけられても、何をすれば良いか分からないからです。

具体的には、この4点を組織の中で決めておくと良さそうです。

  • 何を「良い仕事」とするか（良い仕事の定義と共通認識）
  • 誰が何を決めるか（責任の所在の明確化）
  • その結果からどう判断を変えるか
  • これらをフィードバックループで検証するための設計

あれ、これ、Evalsの話と繋がりましたね。やはり黒幕は、Evalsだったわけだ。
ここで胸ポケットからもう一つピースが現れました。手先の器用なDevilめ。
指を鳴らすと、ピースの上に「プロダクトエンジニア」という手書きの文字が浮かび上がりました。

二つのピースは、こう並べると綺麗にはまります。

Evalsとは、AIに「良い仕事」をさせるための言語化。
プロダクトエンジニアリングとは、人と組織が「良い仕事（プロダクト）」に向かうための言語化。

任せる相手がAIか、人か。その違いだけで、組織に要求されるものは同じでした。何を「良い仕事」とするかを決め、責任の所在を明らかにし、結果から判断を変え、それをフィードバックループで検証し続けること。

こうして振り返ると、この記事で辿ってきた流れも一本の線になります。AIが作業を速くし、染み出ししろが生まれ、越境が起きる。越境した先で判断するには、コンテキストの棚と、判断のよりどころが要る。そして、その拠り所こそが、言語化された「良い仕事」でした。

冒頭で挙げた頻出ワードたち「越境」、「コンテキスト」、「アウトカム」…。
示し合わせたかのように揃っていたのは、偶然ではありません。どのセッションも、立場や現場は違えど、この同じ一点に向かって語っていたのです。

まとめ：AIで空いた手を、価値へ伸ばす

今回の参加で得たことを一言でまとめると、こうなります。

AIによって「作る」が速くなった今、問われているのは「何の作業までできるか」よりも、「どこまで価値に向き合えるか」。勝負は「なぜ作るか」「何が良い仕事か」を言語化し、職能の境界を越えて共有できるかに移っている。
（一言とは。を定義したい。）

職能の境界がなくなるのではなく、価値に合わせて境界の重なり方が更新されていく。
そして「越境」という言葉が使われなくなる頃には、職種ではなく「成果を担う単位」を中心とした組織の姿が、当たり前になっているのかもしれません。

私たちCOSTAは、顧客と目標を共有し、ビジネスの成功度合いに応じて報酬が変動する「成果報酬型」で案件に取り組むチームです。
アウトプット（作ったもの）だけでなく、アウトカム（ユーザーへの影響）、さらにはインパクト（ビジネスへの影響）まで責任範囲を広げることを前提にプロダクト開発に携わっています。

そのため、今回議論されていた「プロダクトエンジニア」像は、私たちにとって「いつか目指す理想像」というより、すでに日々実践している働き方にかなり近いものでした。
カンファレンス全体を通して、普段の仕事の答え合わせができたと同時に、「良い仕事の言語化」やコンテキスト設計など、まだまだ磨けるところも見つかった一日でした。

コードはAIが書ける。では、人は何をするのか。
私の今の答えは、「なぜ」を共有し、価値に向かう越境と検証の仕組みをつくることです。
まずは、自分たちの提案やバックログに「誰に、どんな変化を届けたいのか」を一行加えるところから始めてみたいと思います。

皆さんの組織では、「良い仕事」を言語化できていますか？ ぜひ一度、チームで話し合ってみてください！

参考（一部のセッション資料）

✨ このカテゴリーのAIまとめ記事を見る

新規CTA