こんにちは、ゴーレム採用チームです！

現在、ゴーレムではプロダクトマネージャー（PdM）を募集しています。

今回は、なぜゴーレムが今PdMを募集しているのか、実際にどのような仕事を担うのか、入社後の数か月で何を期待しているのかをまとめました。

ゴーレムのPdMという仕事が、自分の経験やこれから取り組みたいことに合っているかを考える材料として、読んでいただければと思います。

なぜ今、このポジションを採用するのか

事業が大きくなるほど、増えていく難しさ

ゴーレムは今、複数の大手ゼネコン・デベロッパーとのプロジェクトが同時並行で走っています。プロジェクトが増えるということは、それだけ「この会社ではこう困っている」「この業務をこう変えたい」という声が、いろいろな場所から集まってくるということでもあります。

その一つひとつの声を、開発チームが実際に手を動かせるところまで具体化していきます。この上流工程の重要性は、事業の拡大とともにどんどん増しています。ゴーレムにはすでにPdMとして働くメンバーがおり、周囲のメンバーもプロダクトマネジメントを支えています。

今回の採用は、顧客課題からプロダクトの方向性を決める役割をさらに厚くするためのものです。

解決したいのは、「個別対応の積み重ね」から抜け出すこと

今回のポジションで解決したいのは、個別顧客の要望をそのまま開発するのではなく、複数顧客に共通する課題・価値へと変換し、プロダクトの優先順位と要件を専任で判断できる状態をつくることです。

採用後は、個別の顧客要望を共通のプロダクト価値へ変換し、要件・優先順位・リリース判断を継続的に担える体制を厚くしていきます。

ゴーレムのプロダクトが今後も複数の顧客・複数の機能にまたがって育っていくために、避けて通れない一歩だと考えています。

ゴーレムの事業とPdMのミッション

バラバラなデータという、業界の悩みのタネ

建設業界のデータは、会社ごと、担当者ごとに書き方も単位もバラバラです。同じ「鉄骨100本」という発注でも、種類によって発注先が違い、その判断根拠は担当者の頭の中に留まってしまっている、ということが日常的に起きています。

ゴーレムがやっているのは、このバラバラな情報をAIで読み取り、誰もが使える形に整えること。そうして整った1つのデータ基盤の上で、CO2排出量の算定、購買仕分、長期修繕算定、図面チェック、施工計画といった複数のアプリケーションが動いているんです。

つまりゴーレムは、1種類のプロダクトを1社に売るのではなく、1つのデータ基盤の上に複数のプロダクトを乗せ、それを複数の大手顧客に使ってもらう、という事業構造をしています。PdMの仕事の難しさも面白さも、実はこの構造から来ているんです。

PdMのミッション「個別の要望を、共通の価値に変える」

ゴーレムのPdMのミッションは、顧客や事業側から得られた情報をもとに、解決すべきユーザー課題を定義し、開発チームが判断・設計・実装できる状態までプロダクト要件を具体化することです。

ゴーレムの顧客は、大手ゼネコンやデベロッパーを中心に、それぞれ異なる業務フローと商習慣を抱えています。顧客からの要望をそのまま個別対応の機能として作ってしまうと、他の顧客には使われない機能が増え続け、プロダクトはどんどん複雑になっていきます。1つのデータ基盤の上に複数のプロダクトを乗せているゴーレムにとって、これは避けたいことです。

だからゴーレムのPdMに求められているのは、個別の要望の背景にある業務課題を捉え、複数の顧客に共通するプロダクト価値へと変換すること。具体的には、次の5点に責任を持ちます。

• どのユーザーの、どの課題を解決するのか
• なぜプロダクトとして取り組むのか
• 何を作り、何を作らないのか
• どの順番で開発するのか
• リリースによって課題が解決されたか

PdMの具体的な仕事と、まわりとの関係

4つのサイクルで回る、日々の仕事

日々の仕事としては、大きく4つの領域に分かれます。

1つ目はプロダクト課題の定義です。
ITPMや営業、カスタマーサクセスが集めてきた顧客要望・業務情報を整理し、ユーザーインタビューや利用状況を確認しながら、表面的な要望と本質的に解決すべき課題を切り分けます。この案件は個別対応で済ませるべきか、プロダクト開発として取り組むべきかを見極めるのも、この段階の仕事です。

2つ目は、プロダクト要件・仕様の策定です。
プロダクト要件、機能要件、非機能要件を整理し、ユーザーストーリーや業務フロー、受け入れ条件に落とし込みます。画面・データ・権限・処理フローといった仕様の整理や、エンジニア・機械学習エンジニアとの実現方法の検討、開発中に出てくる論点や仕様変更の判断も担います。

3つ目は、優先順位と開発計画です。
プロダクトバックログを作成・管理し、顧客価値・事業価値・開発コストを踏まえて優先順位を決めます。プロダクトロードマップの策定・更新、リリース範囲と段階的な提供計画の整理、経営・事業・開発チームとの合意形成まで含みます。

4つ目は、リリース後の検証です。
利用状況や顧客フィードバックを集め、リリース前に立てた仮説や指標を検証します。そこから見えた改善課題をバックログに反映し、要件定義・仕様策定のプロセス自体を標準化していきます。ここまでが1つのサイクルです。

どんな力が、特に求められるの？

ゴーレムのPdMは、UIよりもシステムロジックの方を重視される傾向にあります。

理由は、ゴーレムのプロダクトの成り立ちそのものにあります。

見積書や発注データといった建設業特有の生データを、複数のマスターデータベースにまたがって処理し、CO2算定・購買仕分・長期修繕算定など複数の機能で使い回す構造になっているため、どの機能がどのデータとどう連携しているかを設計し整理することが、そのままユーザーが得る価値に直結します。画面の見せ方よりも先に、データをどう処理し構造化するかという設計が、仕事の中心になってきます。

この特性上、Webサービスの画面設計を中心にキャリアを積んできた人よりも、社内の業務管理システムや生産管理システムの人、あるいは金融系のように大量のデータが相互に連携するプロダクトを見てきたPdMの方のほうが、経験を活かしやすい傾向があると考えております。

ITPMとの役割の違いは？

ゴーレムには、PdMと近い立場でありながら役割が異なる「ITPM（ITプロジェクトマネージャー）」という職種があります。

ゴーレムのITPMは、顧客との対話を通じて業務上の課題や要望を整理し、プロジェクトのゴールを明確にする役割です。顧客との合意形成や、個別プロジェクトの進行・納期管理を担います。いわば、顧客の一番近くに立つ人たちです。

PdMは、ITPMが整理した個々の顧客課題や、複数のプロジェクトから見えてくるニーズをもとに、プロダクトとして提供すべき価値を定義します。そのうえで、開発する機能の要件や優先順位を整理し、プロダクト全体の方針やリリース判断を担います。必要に応じてPdMが顧客との対話に参加することもありますが、個別案件の導入や進行管理ではなく、顧客の声をプロダクトの改善や開発方針に反映することが主な役割です。

エンジニア・テックリードとはどう分担するの？

エンジニア・テックリードとの関係も、同じ考え方です。PdMは、顧客や事業の課題を踏まえて、誰にどのような価値を提供するのか、どの課題から優先して解決するのかを整理します。エンジニアやテックリードは、PdMが示した方針や要件をもとに、技術的な実現方法やシステム設計を検討します。

ただし、具体的な仕様や実現方法は、どちらか一方だけで決めるものではありません。顧客にとっての価値、開発コスト、技術的な実現可能性、保守性や拡張性。これらを踏まえて、PdMとエンジニアが議論しながら決めていきます。

入社後に期待すること

ここでは、入社後どんな順番で仕事に慣れていくことになりそうか、大まかなイメージをお伝えします。

1〜2ヶ月目：ゴーレムという会社を、体で理解する

最初の1〜2ヶ月で目指すのは、次の3つです。

• 建設業界の業務構造と、主要顧客が抱える課題を理解する
• 既存プロダクト、データ構造、開発プロセスを把握する
• 既存案件に参加し、要件が開発へ渡るまでの流れを実際に見て理解する

座学だけでなく、分かりやすく切り出した1つの実務を実際に手を動かしながら覚え、壁打ちの頻度を高くしながら早い段階から実際の仕事に触れていく形での立ち上がりを想定しています。本人のこれまでの経験やスキルに合わせて、都度すり合わせていきましょう。

3〜6ヶ月目：小さくても、自分の持ち場を持つ

3〜6ヶ月目からは、動き方が少し変わってきます。

• 一つのプロダクトまたは課題領域の要件整理を担当する
• プロダクト要件、受け入れ条件、優先順位を自ら整理する
• エンジニアと連携し、開発からリリースまでを進める
• 要件整理から生まれる手戻りを、少しずつ減らしていく

「見て学ぶ」段階から一歩進んで、自分の担当領域を任されるようになっていきます。まずは一つの領域で安心して力を発揮できるようになることを目指します。

その先で、目指してほしい姿

一つの領域を回せるようになった先には、その範囲を少しずつ広げていくことになります。

プロダクトバックログとロードマップを継続的に管理しながら、個別の顧客要望を再現性のあるプロダクト価値へと変換していきます。

属人的になりがちな要件定義・仕様策定のプロセスも、少しずつ標準化していきます。こうした一連の流れを、これまでの経験や担当領域に合わせて少しずつご自身のものにしていってもらえたらと思います。

このポジションだから得られる経験

業界特有の複雑な課題を、プロダクトに変えていく面白さ

建設業界では、企業やプロジェクトごとに業務、データ、管理方法が異なります。個別性の高い課題から共通構造を見いだし、業界で継続的に使われるプロダクトへ変換していくことの難しさと面白さは、他の業界のPdM経験だけではなかなか味わえないのではないかと思います。

上流工程の仕組み自体を、自分でつくれる

すでに完成したプロダクト組織に入るのではなく、顧客課題をどう収集し、どう要件化し、どう開発へ渡すか、というプロセス自体をこれから整備していく立場になります。用意されたレールの上を走るのではなく、レールそのものを敷く仕事です。

大手企業と組みながら、ユーザーとの距離は近いまま

大手ゼネコンやデベロッパーと一緒に仕事ができるのは、シンプルに面白い経験です。ユーザー数が膨大になりすぎて一人ひとりのユーザーが見えなくなる、という一般的な大規模SaaSにありがちな悩みとは無縁で、顧客との距離が近いままプロダクトをつくれることが、今のゴーレムの特徴です。

「作って終わり」ではなく、何年も使われる前提でつくれる

ゴーレムのプロダクトは高単価・長期契約が中心のため、1年で使い捨てるような短期のリリースサイクルではなく、何年も使われ続けることを前提に、腰を据えて計画を立てられます。とりあえずリリースして反応を見る、という進め方よりも、じっくり作り込む長期的な視点が持てるのは、ゴーレムならではの環境です。

複雑な業務とデータを扱う専門性を積み上げる

建設業務への理解と、データ・システムロジックへの理解。その両方を持ちながら、顧客課題をプロダクトへ変換する経験を積めることも、このポジションの特徴です。データや機械学習を含むプロダクトに関わりながら、複雑な業務を整理し、実装と検証までつなげる専門性を深められます。

どんな人に合う／合わないか

こんな人に向いています

実際の仕事は、顧客から言われたことをそのまま形にするのではなく、その背景にある課題から考えていく仕事です。曖昧な情報を、論点や判断基準が見える形に整理し、顧客価値・事業性・開発コストのバランスを見ながら決めていきます。そうした進め方が自然と身についている方だと、早くなじめると思います。

エンジニアや事業側と議論しながら物事を決めていく場面も多いので、自分の考えに固執せず、根拠を持って意見を交わせる方が向いています。仕様書を作ることそのものより、ユーザーの課題が実際に解決されたかどうかを大事にしたい方には、特に楽しんでもらえる仕事なのではないでしょうか。

この「議論できる」という点は、社風とも深く関わっていると感じます。ゴーレムでは、役職や部署の垣根を越えて、率直に意見をぶつけ合うことが当たり前になっています。言われたことをそのままやる、という進め方が心地よい方より、根拠を持って自分の意見を言える方の方が、ゴーレムでは働きやすいはずです。

必須となるご経験

具体的なご経験でいうと、次のようなものが必須と考えております。

• BtoB向けWebサービス、SaaSまたは業務システムにおけるプロダクトマネジメント経験
• 顧客や事業部門の曖昧な要求を整理し、プロダクト要件・機能要件へ落とし込んだ経験
• エンジニアと連携し、要件定義から開発、リリースまでを進めた経験
• 複数の要求に対し、優先順位や開発範囲を判断した経験
• 要件、仕様、判断理由をドキュメントとして整理した経験

あると、より活躍しやすいご経験

この上に、次のようなご経験があると、より早く力を発揮しやすくなるのではと考えております。

• エンタープライズ向けSaaSまたは業務システムの開発経験
• 複雑な業務フローやデータ構造を扱った経験
• 新規プロダクトまたは新機能の立ち上げ経験
• プロダクトロードマップ、バックログを管理した経験
• SQLなどを用いて利用状況やデータを確認した経験
• 機械学習、生成AI、データプロダクトの企画・開発経験
• 建設、建築、不動産、サステナビリティ領域に関する知見

こんな方には、もしかするとギャップを感じるかも

次のような形でお仕事をされてきた方だと、ゴーレムのPdMとは少しギャップを感じるかもしれません。ご判断の参考になればと思うので、正直にお伝えします。

• プロジェクトの進行管理を中心にお仕事をされてきた方：ゴーレムのPdMは進行管理よりも、複数の要望から何を作るべきかを判断していく役割になります
• 仕様書を作成することが主な役割だった方：仕様に落とす前段階で、何を優先すべきかを判断していくことが、この仕事の中心になります
• 新規事業の構想には関わったものの、開発・リリースまでは担当されていない方：構想だけでなく、エンジニアと連携しながら実際にリリースまで進めていくことが求められます

いずれも、それぞれの現場で活きる立派なご経験です。ただ、ゴーレムのPdMの仕事では、「決まったことを整理する力」よりも、「何を優先すべきかを自分で判断し、その判断に責任を持つ力」が大事になると考えております。そこに強みや面白さを感じられる方であれば、力を存分に発揮できる環境だと思います。

いかがでしたか？

ゴーレムのPdMは、建設業界のバラバラなデータと向き合い、複数の顧客に共通するプロダクト価値をつくる仕事です。

少しでも興味を持っていただけたら、まずはカジュアルにお話ししましょう！