私たち準委任PdEは2つのプロダクトに挑戦する ～ソフトウェア、開発支援という”二重”のプロダクトエンジニアリングの実践～ / 20260212 Naoki Takahashi

2026/02/12 Product Engineering Night #12 〜LT大会！〜
https://product-engineer.connpass.com/event/379165/

株式会社SHIFT 製造ソリューションサービス部
髙橋 直規

Transcript

1. #PdENight 髙橋直規 株式会社SHIFT Copyright SHIFT Inc, All Rights Reserved. 2026.2.12 Product Engineering Night #12 〜LT大会！〜 私たち準委任PdEは2つのプロダクトに挑戦する 〜ソフトウェア、開発支援という”二重”のプロダクトエンジニアリングの実践〜
2. 自己紹介 髙橋直規（幡ヶ谷亭直吉） x:@asagayanaoki • エンジニア歴：18年11か月（20代：SES、30代以降：準委任） • 役割：プロジェクトマネージャー、エンジニア • 楽しみなカンファレンス：Product Engineering Conference • 主催コミュニティ：多摩.dev • 土日の過ごし方：6歳の娘ととにかく遊ぶ
3. 準委任とは 準委任とは システム開発や運用保守において、 成果物の完成ではなく、業務の遂行（労働力や技術の提供）を 目的とする契約形態。 目的：成果物ではなく、業務の遂行（時間・スキル提供） 報酬：成果物よりも、稼働（工数）に紐づきやすい 準委任の前提だと、エンジニアの思考が 価値実現（アウトカム）から離れやすい
4. 考える人／作る人の固定化 準委任などの受発注の構造では、顧客とエンジニアの役割が 「考える人／作る人」に固定化されやすい。 構造上、作る側は仕様充足に引っ張られやすく、 「ユーザーへの価値提供」ではなく、 「仕様通りの機能をリリースすること」に寄っていく。 準委任のエンジニアリング 準委任は機能の完成が目的化しやすく、 プロダクト志向に壁が生まれる。
5. 「仕様通り」でも価値の実現ではない 発注者の考えることがいつも最適とは限らない。 要件の整理不足や想定外は起きる。 結果、「仕様通りの機能」でも価値につながらないことがある。 価値が実現されなければ、契約の継続が難しくなる。 準委任のエンジニアリング 仕様通りでも、価値があるとは限らない。 プロダクトの価値実現が重要。
6. 準委任のエンジニアリング 準委任という制約があっても、 プロダクトの価値実現に 向き合う必要がある。 なぜ必要か、どう使われるかを言語化し、 作って触って確かめ、育て続ける。
7. チームの現在地 プロダクトやその先にいるユーザーを 意識しながら開発を進めていく。 フルサイクル寄りの現状 期待される役割：開発〜運用・サポートまで（フルサイクル寄り） 役割上での課題：企画・要件に、エンジニアが後追いになりやすい だからこそ、企画・要件に踏み込む。
8. プロダクトに対する距離を埋める プロダクト志向の実践 考える人／作る人の境界を越え、プロダクトの価値実現のために 私たちが実践している4つの取り組みを紹介します。 この4つは相互に作用し、サイクルを回していきます。 作る前に、ユーザーに どう使われるかを考える 何の価値を生むかを、 納得できるまで議論する ドメインを理解し、 機能を育て続ける 作った機能を触って、 検証する
9. プロダクトに対する距離を埋める 「なぜこの機能が必要か」、 「ユーザーがどのように利用するか」を考える。 作り方だけではなく、使われ方を理解する。 要件定義や設計段階においても、 利用シナリオ（いつ／誰が／何のために）を想定して作る。 結果、過剰実装を避け、必要最小限で最大の価値を作れる。 仕様書の向こうのユーザーとの距離を縮める。 どう使われるかを考える
10. プロダクトに対する距離を埋める 納得できるまで議論する 必要性が分からないまま作らない。 表現しきれていない要件があるかもしれないし、 本当はいらない機能かもしれない。 議論をすることで意図を持って作ることができるようになる。 自分ごととして開発をすることで、 ドキュメントではなくユーザーに向き合った開発ができる。 納得が開発者のプロダクトへの主体性を育む。
11. プロダクトに対する距離を埋める 機能を育て続ける ただ機能を積み上げていくのではなく、 ドメインを理解し、機能同士の有機的な繋がりを実現する。 重要な機能ほど時間をかけて持続可能に開発し、 そうではない機能ほど簡易的な実装でも開発速度を上げる。 ドメインを理解して開発をすることで、 プロダクトに何が求められるかを考えるようになる。 ドメイン理解がプロダクトへの紐づきを強くする。
12. プロダクトに対する距離を埋める 検証する リリース前に作った機能を ステークホルダー全員で触って確かめる。 プロダクトを通した会話でお互いの認知をすりあわせる。 プロダクトを触ることで経験知を増やし、 会話を通して共有知を養い、 全員でプロダクトリリースに対する合意を形成する。 手触りがユーザーに対する当事者意識を育てる。
13. プロダクトに対する距離を埋める エンジニアがプロダクトを主体的に育てていく どう使われるかを 考える 納得できるまで 議論する 機能を育て続ける 検証する
14. 準委任のプロダクトエンジニアリング 顧客のプロダクトを成功させる実践は、 価値実現のための開発プロセスを作っていく。 結果、我々自身の開発支援サービスも磨かれていく。
15. 準委任のプロダクトエンジニアリング 2つのプロダクトの成功に挑戦するエンジニア ①顧客のソフトウェア →ユーザーに価値を提供する。 ②我々の開発支援サービス →顧客に価値を提供する。 私たち準委任プロダクトエンジニアは 2つのプロダクトの価値実現に挑戦する。