はじめに
タイミーでは、世界中で開催される技術系カンファレンスの参加を支援する「Kaigi Pass」という制度があります。今回は、2026年9月5日(土)に中野セントラルパークカンファレンスにて行われた、Product Engineering Conference 2026に5名が現地参加してきました。 本レポートでは、参加したエンジニアが注目したセッションごとに、参加者自身の視点で学びや気づきをまとめました。読者の皆様にとって、今後の学びの参考になれば幸いです。
営業・CSを「開発の当事者」にする — 少人数チームで複数プロダクトを動かすDev<>Ops連携の方法
こちらのセッションは、estieの山本龍平さん・北村大助さんによる、少人数で複数プロダクトを動かすなかで、営業・CSがプロダクト開発の当事者になる取り組みについての共同発表でした。
Ops（営業やCS）は、要望をDev（開発）に渡して実装を待たない。AIでモックを作り顧客に当て、課題と解決策の仮説を磨き込んでからDevに渡す。現場に近いOpsが仮説検証を一定担うことで、質と速度を上げる、というのが主題でした。
印象的だったのは、Opsの北村さんの話です。小さく早く検証することを前提に、動くものを用意して顧客とのコミュニケーションコストを下げ、検証精度を上げていることでした。
仮説検証はDevの役割だと思い込んでいた私にとって、Opsが回せるよう検証環境で支えるという体制は、前提を覆される話でした。また、仮説検証に対する「小さく、早く」といった姿勢をどのようにOpsに共有しているのかという疑問が浮かびました。
そういったプロダクト開発に対する理解向上の取り組みとしてタッグ開発 Nightが紹介されていました。社内のハッカソンに近いイベントで、Opsが顧客要望をもとにAIでプルリクエスト（PR）を出す。仮説を試す部分をDevと進める場でした。
このほか、Preview環境でPRごとに専用DBを用意する取り組みなど、Opsの越境を助ける具体事例も紹介されていました。自社でも、まずは「動くものを顧客に当ててからDevに渡す」ところから試せそうです。自身の役割を越境するだけでなく、担当領域への越境を助ける環境づくりまで含めて、組織としてプロダクト開発を進める視点を得た発表でした。
津守（@ytsumori59）
エンジニアリングは、どこまで拡大解釈できるか 心技体をつないだままで事業責任者になった話
speakerdeck.com 柳川さんのセッションでは、エンジニアリングを「責任を引き受ける営み」として捉え、技術の実装にとどまらず、プロダクトのアウトカムまで責任範囲を広げる考え方が語られていました。
責任範囲を広げる鍵として示されたのが、責任を負う実感（心）、スキル（技）、現場感覚（体）です。3要素を切り離さずに育てることが重要だと、私は受け取りました。
AIはスキルを伸ばす助けになります。一方、責任を引き受ける実感は、組織環境にも左右されます。そのため、個人プロダクトのリリースなど、社外で自ら意思決定と結果を引き受ける経験も有用だと提示されていました。
技術や知識の活用をAIが支援する範囲は、今後さらに広がっていきます。だからこそ、アウトカムに責任を持つ姿勢の重要性は増すのではないかと感じました。
私は、「プロダクトエンジニア」という言葉には、アウトカムへコミットする姿勢が含まれると考えています。その延長線上に事業責任者という役割がある、という捉え方には納得感がありました。
この話を聞き、仕事で大切にしている「ジブンゴト」という言葉を思い出しました。物事を自分の責任として捉え、行動する姿勢です。今回のテーマにも通じると感じました。
発表では、「エンジニアは元来ラストマンである」という問いかけもありました。ここでいう「ラストマン」とは、成果物の最終責任を引き受ける立場を指します。また、組織の中に暗黙的な親子関係が生まれる、という経営学的な視点も印象に残りました。
AIが成果物の生成を支援する範囲が広がるほど、最終的な責任を誰が担うのかを意識する必要があります。自分はどこまで責任を引き受けるのか。改めて考える機会になりました。
また、また、柳川さんの発表そのものも素晴らしいものでした。「責任」を起点に話を展開し、帰納的にセッションのテーマへ収束させる構成や、洗練された言葉選びが強く印象に残りました。
これまで聴講したセッションの中でも、特に心を動かされました。エンジニアとして、職業人として、こんなふうに生きたいと思わせてくれるセッションでした。
志賀（@akitoshiga）
その機能が使われないのは、業務の捉え方を間違えたから？─プロダクトエンジニアのメタモデル設計論
特に印象に残ったのは、機能をリリースするというアウトプットがあっても、顧客の業務が良くなるというアウトカムにはつながらないことがある、という話です。その原因が機能の不足ではなく、そもそもの業務の捉え方にあったという点が、日々の開発を振り返るきっかけになりました。
このセッションで紹介されたのが、業務をどのような概念や関係性で捉えるかという「メタモデル」の考え方です。その土台には、一次情報から業務の流れを理解することがあります。データがどう移動するかに加えて、誰が何を判断し、どのように仕事を進めているのかを捉える。現場を観察し、可能であれば体験し、専門家との対話で判断の背景を確かめる。業務モデルは会議室の議論だけでは完成しない、という話が心に残っています。
業務の中心となる概念を見極める観点も参考になりました。例えば契約であれば、さまざまな処理の軸に、顧客と交わした約束があります。個々の処理やデータ項目を整理するだけでなく、それらが何を軸につながっているのかを考えることが、モデルの土台になるのだと受け取りました。
また、良い業務モデルは、顧客が業務の進め方を組み立て、運用する負担を吸収するという話もありました。柔軟な機能を用意しても、その組み合わせや使い分けを顧客が一から考える必要があれば、負担は残ります。業務理解をモデルに反映することは、コードの構造だけでなく、顧客がどれだけ無理なく使えるかにも関わるのだと思いました。
ここからは、タイミーの身近な機能を題材に、この考え方を自分なりに当てはめてみます。
例えば求人を公開する際には、募集人数が定員に達していない場合に、設定に応じて公開範囲を自動で広げる仕組みがあります。詳しくは、求人の公開範囲についてをご覧ください。
この仕組みを単なる機能拡張ではなく「業務の流れ」として捉え直してみます。すると、応募状況や残り時間を踏まえて「どのタイミングで求人を届ける相手を広げるか」という事業者の判断を支えていることが見えてきます。 言われてみれば当然のことですが、日々の開発に追われているとつい見落としがちな視点です。機能が裏で支えている判断や作業にまで解像度を戻してこそ、本質的な設計や検証ができるのだと改めてハッとさせられました。
効果を確かめる際も、自動で公開範囲が広がったかというシステム挙動だけでなく、事業者様の手間が減り必要な人数の確保につながったかを見る必要があると思います。同時に、ワーカーさんにとっても希望や条件に合う仕事との出会いにつながったかも重要です。「募集が埋まる」という数値だけでなく、その先の就業が双方の期待に沿う体験になったかまで視野を広げることが、まさにセッションで聞いた「業務を捉える」ということなのだと感じました。今後の自分の開発でも、この視点を忘れずに向き合っていきたいです。
細野
越境負債：称賛されるほど、負債は返済されない
「越境をしても、越境が必要になってしまう状況そのものは越境では改善されない」という内容。越境が越えている境界を組織のそれであるとし、プロダクトの価値最大化のために越境は必要だが、一方でそういう境界を最適化する手法として組織再編を挙げていた。つまり、プロダクト価値の創出のために越境が必要だという状況は、組織の境界が最適でないということを意味する。もちろん越境は組織再編行為ではないため、最適でない状況そのものは、越境では改善されない。
たしかにそういう状況ならそう言えるかもしれない。組織の境界を越える行為を越境と呼ぶならば、組織再編が根本解決手段の一つであり得る。またそれを役割の境界であるとするなら、職務記述やロールの定義を更新すべきなのかもしれない。
ただどうしても、境界があれば越境が可能になる。境界を意識させないために私達は、これまでにも「何でも屋」、「遊撃部隊」、「フルスタックエンジニア」、「FDE」などを生み出してきた。実際のところ何でもできる人の手が空いているのなら何でも幅広く任せるほうが、少なくとも短期的なプロダクト価値の最大化にとっては最適だと言える。境界がある限り、越えたくなる。そして価値を創出している限り、越境は称賛されなければならない。
個人的には、どこかに線を引く限り越境はなくならないと思うし、それは称賛されるべきだとも思う。
口藏（@mizunokura）
おわりに
Product Engineering Conferenceは初開催ながら、多くの参加者が集まり、皆さんのプロダクトエンジニアリングに対する熱量を感じました。 各セッションを通じて、プロダクトエンジニアリングについて改めて考える機会になりました。今回得た学びはタイミーでのプロダクト開発にも活かしていきたいと思います。
次回の開催については未定とのことですが、開催される際はぜひ次回も参加したいと思います。
