プロダクト責任者／PdM の求人一覧 - 株式会社ゴーレム

▍事業内容／企業紹介 ゴーレムは、建設業界に蓄積されてきた見積・設計・施工・維持管理などのデータと、実務の中で培われてきた判断基準を構造化し、企業の業務効率化や意思決定を支援する建設業界特化型のデータプラットフォームを開発しています。 建設業界では、企業・プロジェクトごとに見積書の形式、業務フロー、管理方法、判断基準が異なり、重要な情報がExcelやPDF、担当者の経験に分散しているケースが少なくありません。ゴーレムでは、こうした非構造・属人的な情報をデータとして扱える状態へ変換し、CO2排出量の算定をはじめ、見積・購買・業務分析など、複数の業務テーマへ展開しています。 単一の作業を効率化するツールを提供するだけではなく、顧客企業の既存業務やデータ環境を理解し、現場で継続利用できる業務・システムとして実装することを重視しています。 ▍ポジションのミッション（募集背景） 事業・顧客プロジェクトが拡大するなかで、顧客から寄せられる要望を「そのまま開発へ渡す」のではなく、現行業務、課題が生じている背景、制約条件、実現したい状態を整理し、プロダクト・システムとして解決すべき範囲を定義する上流工程の重要性が高まっています。 現在は、顧客折衝、業務整理、要件定義、社内調整を複数のメンバーが兼務しています。その結果、案件数が増えるほど、特定メンバーへの負荷集中、案件ごとの要件整理の粒度差、顧客と開発チームの認識差、開発着手後の仕様変更・手戻りが発生しやすい状態になっています。 今回採用するITPMには、顧客の曖昧な要望を受け取って進行管理するのではなく、「何が本当の業務課題なのか」「誰のどの業務をどう変えるのか」「どこまでを今回のプロジェクトで解くのか」を明確にし、顧客・PdM・エンジニアが同じ前提で判断できる状態をつくっていただきます。 ミッションは、顧客の業務・要望を構造化し、解決すべき課題とビジネス要件を定義したうえで、顧客と社内の関係者が共通認識を持ってプロジェクトを進められる状態をつくることです。 個別案件を完遂するだけではなく、ヒアリング項目、要件整理方法、ドキュメント、開発への引き渡し方法まで標準化し、案件数が増えても品質が落ちない上流工程の仕組みを構築することまで期待しています。 ▍仕事内容 ■ 1. 顧客業務・課題の構造化 ・顧客の経営層、推進責任者、実務担当者へのヒアリング ・現行業務（As-Is）の業務フロー、担当者、利用データ、システム、意思決定ポイントの整理 ・顧客から提示された要望と、その背景にある業務課題・原因・制約条件の切り分け ・対象ユーザー、利用場面、発生頻度、業務上の影響、実現したい状態の明確化 ・現行業務と導入後業務（To-Be）の差分整理 ・今回のプロジェクトで解決する課題／解決しない課題の整理 ■ 2. ビジネス要件・プロジェクトスコープの定義 ・課題を解決するために必要な業務要件・ビジネス要件の整理 ・対象業務、対象ユーザー、対象データ、利用シーン、期待成果の定義 ・必須要件と追加要望の切り分け ・プロダクト標準機能で対応する範囲、設定・運用で対応する範囲、個別開発が必要な範囲の整理 ・PdM、エンジニア、機械学習エンジニアと実現可能性・開発コスト・運用負荷を検討 ・プロジェクトのゴール、スコープ、前提条件、制約、役割分担の明文化 ■ 3. 顧客・社内の合意形成 ・複数の対応案がある場合の選択肢、メリット／デメリット、影響範囲の整理 ・顧客要望、プロダクト方針、技術的制約を踏まえた推奨方針の提示 ・顧客と社内関係者への方針説明および意思決定支援 ・要件、スコープ、役割、スケジュール、未決事項に関する合意形成 ・仕様変更・追加要望が発生した際の影響分析と変更管理 ■ 4. プロジェクト推進 ・プロジェクト計画、マイルストーン、意思決定ポイントの整理 ・顧客側／社内側のタスク、課題、リスク、依存関係の可視化 ・定例会議の設計・ファシリテーション、議事・決定事項・未決事項の管理 ・PdM、エンジニア、MLエンジニア、営業、CSなどとの横断調整 ・課題やリスクの早期エスカレーションと解決方針の整理 ・導入・受入・リリースに向けた顧客との調整 ■ 5. 上流工程の標準化 ・顧客ヒアリング項目、要件整理フォーマット、確認観点の標準化 ・業務フロー、要件定義、論点表、決定事項、リスク管理等のテンプレート整備 ・プロジェクト開始からPdM／開発チームへの引き渡しまでの標準フロー構築 ・過去案件の要件、判断、失敗、手戻り要因の蓄積 ・類似案件で再利用できる業務パターン・要件パターンの整理 【役割分担】 ITPMは、顧客の業務課題・ビジネス要件・個別プロジェクトの合意形成と進行に責任を持ちます。PdMは、複数顧客の課題をもとに、プロダクトとして何を解くか、要件・優先順位・仕様・リリースを判断します。エンジニア／テックリードは、整理された要件に対する技術的な実現方法・システム設計を担います。ITPMが技術仕様を単独で決めるのではなく、顧客価値、プロダクト方針、開発コスト、保守性を踏まえ、PdM・エンジニアと議論しながら実現方針を決定します。 ▍やりがい・魅力など ■ 顧客から「何を作ってほしいか」を聞く前の段階から関われる 仕様が決まった後に進行管理するPMではなく、顧客の業務を理解し、そもそも何を解決すべきか、今回どこまで解くべきかを定義するところから関われます。 ■ 顧客とプロダクト開発の双方に影響を与えられる 顧客折衝だけ、開発管理だけに閉じず、顧客課題がプロダクトや個別システムへどのように反映されるかまで継続して関与できます。個別案件で得た知見をPdMへ還元し、複数顧客へ共通するプロダクト価値へ変えることもできます。 ■ 上流工程の仕組みそのものをつくれる 要件整理や開発への引き渡し方法は、今後さらに標準化していく段階です。既存フローを運用するだけでなく、ヒアリング項目、要件定義、会議体、テンプレート、意思決定ルールなど、プロジェクトを安定させる仕組み自体を設計できます。 ■ 複雑な業務を構造化する専門性が身につく 建設業界は企業・案件ごとに業務やデータが異なり、正解が一つではありません。複数の関係者から断片的な情報を集め、本質的な課題と解決範囲を構造化する経験を積むことができます。 ■ 将来的にPdM・業務DX・プロジェクト責任者へキャリアを広げられる 顧客業務、プロダクト、開発の接点に立つため、志向に応じてプロダクトマネジメント、業務DXコンサルティング、複数プロジェクトを束ねるリードなどへ専門性を広げられます。 ▍組織名／体制 顧客プロジェクトを横断して推進するポジションとして、PdM、エンジニア、機械学習エンジニア、営業、カスタマーサクセス等と連携します。 ▍開発体制 顧客プロジェクトごとに、ITPMが顧客課題・ビジネス要件・スコープを整理し、PdMがプロダクトとしての対応方針・優先順位を判断、エンジニア／テックリードが技術設計・実装を担当します体制を想定します。 案件によっては機械学習エンジニア、営業、CS、サステナビリティコンサルタント等も参加します。ITPMはそれぞれの専門領域を代替するのではなく、関係者が判断できる前提と論点を整理し、顧客との合意形成とプロジェクト全体の前進を担います。 ▍技術スタック ITPM自身が実装を行うことは必須ではありません。 一方で、Webアプリケーション、API、データベース、クラウド、認証・権限、データ連携などの基本的な仕組みを理解し、エンジニアと実現可能性・制約を議論できることを重視します。

▍事業内容／企業紹介 ゴーレムでは、建設業界に蓄積された多様なデータを活用し、CO2排出量の算定をはじめとした業務効率化や意思決定を支援する、建設業界特化型のデータプラットフォームを開発しています。 ▍ポジションのミッション（募集背景） 事業や顧客プロジェクトが拡大するなかで、顧客や事業側から寄せられる要求を整理し、エンジニアが設計・実装できるプロダクト要件へ落とし込む上流工程の重要性が高まっています。 現在は代表や複数のメンバーが連携しながらこの役割を担っていますが、組織とプロジェクトの拡大に伴い、要件整理や仕様策定を専任で担う体制が必要になっています。 今回募集するPdMには、顧客の個別要望をそのまま機能化するのではなく、背景にある業務課題を捉え、複数の顧客に共通するプロダクト価値へ変換していただきます。 【ミッション】 顧客や事業側から得られた情報をもとに、解決すべきユーザー課題を定義し、開発チームが判断・設計・実装できる状態までプロダクト要件を具体化することがミッションです。 PdMは、以下について責任を持っていただくことを想定しています。 ● どのユーザーの、どの課題を解決するのか ● なぜプロダクトとして取り組むのか ● 何を作り、何を作らないのか ● どの順番で開発するのか ● リリースによって課題が解決されたか ▍仕事内容 プロダクト課題の定義 ● ITPM、営業、カスタマーサクセスなどが収集した顧客要望・業務情報の整理 ● ユーザーインタビューや利用状況の確認 ● 表面的な要望と、本質的に解決すべき課題の切り分け ● 対象ユーザー、利用場面、提供価値の定義 ● 個別対応とプロダクト開発の切り分け プロダクト要件・仕様の策定 ● プロダクト要件、機能要件、非機能要件の整理 ● ユーザーストーリー、業務フロー、受け入れ条件の作成 ● 画面、データ、権限、処理フローなどの仕様整理 ● エンジニア、機械学習エンジニアとの実現方法の検討 ● 開発中に発生した論点や仕様変更の判断 優先順位と開発計画 ● プロダクトバックログの作成・管理 ● 顧客価値、事業価値、開発コストを踏まえた優先順位の決定 ● プロダクトロードマップの策定・更新 ● リリース範囲と段階的な提供計画の整理 ● 経営、事業、開発チームとの合意形成 リリース後の検証 ● 利用状況や顧客フィードバックの収集 ● リリース前に設定した仮説・指標の検証 ● 改善課題の抽出とバックログへの反映 ● 要件定義・仕様策定プロセスの標準化 【ITPMとの役割分担】 ITPMは、顧客との対話を通じて業務上の課題や要望を整理し、プロジェクトのゴールや解決すべき課題を明確にします。また、顧客との合意形成や、個別プロジェクトの進行・納期管理を担います。 PdMは、ITPMが整理した顧客課題や、複数のプロジェクトから得られるニーズをもとに、プロダクトとして提供すべき価値を定義します。そのうえで、開発する機能の要件や優先順位を整理し、プロダクト全体の方針やリリース判断を担います。 必要に応じてPdMが顧客との対話に参加することもありますが、個別案件の導入や進行管理ではなく、顧客の声をプロダクトの改善や開発方針に反映することが主な役割です。 【エンジニア・テックリードとの役割分担】 PdMは、顧客や事業の課題を踏まえ、誰にどのような価値を提供するのか、どの課題から優先して解決するのかを整理します。 エンジニアやテックリードは、PdMが示した方針や要件をもとに、技術的な実現方法やシステム設計を検討します。 具体的な仕様や実現方法は、いずれか一方だけで決めるものではありません。顧客にとっての価値、開発コスト、技術的な実現可能性、保守性や拡張性を踏まえ、PdMとエンジニアが議論しながら決定します。 【入社後に期待すること】 入社後1〜2か月 ● 建設業界の業務構造と主要顧客の課題を理解する ● 既存プロダクト、データ構造、開発プロセスを把握する ● 既存案件に参加し、要件が開発へ渡るまでの流れを理解する 入社後3〜6か月 ● 一つのプロダクトまたは課題領域の要件整理を担当する ● プロダクト要件、受け入れ条件、優先順位を自ら整理する ● エンジニアと連携し、開発からリリースまでを進める ● 要件整理に起因する手戻りを減らす その後 ● プロダクトバックログとロードマップを継続的に管理する ● 個別顧客の要望を、再現性のあるプロダクト価値へ変換する ● 要件定義・仕様策定の標準プロセスを構築する ▍やりがい・魅力など 業界特有の複雑な課題をプロダクト化できる 建設業界では、企業やプロジェクトごとに業務、データ、管理方法が異なります。個別性の高い課題から共通構造を見いだし、業界で継続的に使われるプロダクトへ変換する難しさと面白さがあります。 上流工程の仕組み自体を設計できる 完成したプロダクト組織へ入るのではなく、顧客課題をどのように収集し、要件化し、開発へ渡すかというプロセス自体を整備できます。 データと機械学習を含むプロダクトに関われる Web機能だけでなく、建設データの解析や機械学習を活用したプロダクト開発にも関わります。 ▍組織名／体制 ITPM、エンジニア、テックリード、事業側と連携。 ▍開発体制 PdMが価値・優先順位、ITPMが顧客案件、エンジニアが技術設計を担当します。

▍事業内容／企業紹介 ゴーレムは、建設業界に蓄積されてきた見積・設計・施工・維持管理などのデータと、実務の中で培われてきた判断基準を構造化し、企業の業務効率化や意思決定を支援する建設業界特化型のデータプラットフォームを開発しています。 建設業界では、企業・プロジェクトごとに業務、データ、管理方法が異なり、重要な情報がExcelやPDF、担当者の経験に分散しています。ゴーレムでは、こうした非構造・属人的な情報をデータとして扱える状態へ変換し、CO2排出量の算定をはじめ、見積・購買・業務分析など複数のテーマへ展開しています。 ▍ポジションのミッション（募集背景） 顧客固有の要望と複数の開発機会が増える中、個別対応を積み重ねるだけでは、共通プロダクトの価値と投資効率が低下します。個別プロダクトの判断と、複数プロダクト・事業全体の投資判断を分ける必要があります。 今回募集するのは、複数プロダクト・顧客案件を横断し、戦略、ポートフォリオ、投資配分、事業KPI、PdM組織を担っていただくポジションです。具体的には、市場・顧客・競合・技術を踏まえた戦略、複数プロダクトの投資優先順位、事業KPI・プロダクトKPI・検証方法設計、経営・営業・CS・コンサル・開発との合意などを通じて、担当領域を前に進めます。 ▍仕事内容 プロダクト戦略・ポートフォリオ ● 事業戦略・顧客課題・市場環境を踏まえ、複数プロダクトの中長期方針を策定 ● 各プロダクトの役割・対象顧客・提供価値・KPIを整理 ● 新規開発、改善、技術投資等の優先順位と投資配分を判断 ● 個別顧客対応と共通プロダクト投資のバランスを設計 事業KPI・投資判断 ● 利用、継続、売上、粗利等の指標を確認し、プロダクト成果を事業KPIと接続 ● 重要テーマについて期待効果・開発コスト・リスクを比較し、意思決定案を作成 ● 経営会議等でプロダクト戦略・投資方針・成果を説明 PdM組織・意思決定プロセス ● PdMの担当領域・責任範囲・目標を設計し、レビュー・育成を実施 ● ロードマップ、バックログ、リリース判断のレビュー方法を整備 ● PdM間・開発間で優先順位が競合するテーマを整理し、判断を前に進める ● 採用要件・面接・オンボーディングを通じてPdM組織を強化 顧客・事業・開発との連携 ● 営業・CS・ITPMから集まる顧客課題を構造化し、共通課題を抽出 ● Tech Lead・EM等と中長期の技術投資・開発能力を踏まえた計画を策定 ● プロダクト成果を継続的に検証し、戦略・投資配分を見直す ▍やりがい・魅力など ● 複数プロダクトの戦略・投資優先順位を、事業KPIとつなげて判断できる ● PdM組織の採用・育成・判断基準づくりまで含め、プロダクト組織を設計できる ● 建設×データ×AIの領域で、事業とプロダクト双方の成長をつくる経験を積める ▍組織名／体制 プロダクト責任者／PdM／業務委託で3〜4名の組織化を目指す ▍開発体制 ITPM、エンジニア・PdM等と連携。