株式会社ゴーレム の求人｜ITPM

業務詳細

▍事業内容／企業紹介
ゴーレムは、建設業界に蓄積されてきた見積・設計・施工・維持管理などのデータと、実務の中で培われてきた判断基準を構造化し、企業の業務効率化や意思決定を支援する建設業界特化型のデータプラットフォームを開発しています。

建設業界では、企業・プロジェクトごとに見積書の形式、業務フロー、管理方法、判断基準が異なり、重要な情報が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、データベース、クラウド、認証・権限、データ連携などの基本的な仕組みを理解し、エンジニアと実現可能性・制約を議論できることを重視します。

求める人物像

▼必須スキル
● BtoB向けWebシステム、業務システム、SaaS等のITプロジェクト推進経験（目安3年以上）
● 顧客または業務部門へのヒアリングを自ら行い、現行業務・課題・要望を整理した経験
● 曖昧な要求を、ビジネス要件、スコープ、業務フロー、確認事項などへ具体化した経験
● エンジニアと協働し、要件定義から開発・導入・リリースまでのいずれかを主体的に推進した経験
● 顧客、開発、事業など複数のステークホルダー間で、論点整理・合意形成を行った経験
● 要件、業務フロー、論点、決定事項、リスク等をドキュメントとして残した経験

※プログラミング経験は必須ではありませんが、Webシステムの基本構造を理解し、エンジニアと会話できることを求めます。

▼歓迎スキル
● エンタープライズ企業向けの大規模・長期プロジェクト経験
● ITコンサルタント、システムコンサルタント、PM／PL、導入コンサルタントとしての経験
● BPR、業務分析、As-Is／To-Be設計、業務プロセス改善の経験
● ERP、基幹システム、BtoB SaaS等の導入・定着プロジェクト経験
● 複数部門・複数拠点・経営層を含むステークホルダーとの合意形成経験
● 要件定義・プロジェクト推進方法をテンプレートや標準プロセスとして仕組み化した経験
● API、データ連携、データベース、クラウド等に関する基礎知識
● AI・機械学習・データプロダクトの導入／開発プロジェクト経験
● 建設、建築、不動産、積算、サステナビリティ領域の知見

▼求める人物像
● 顧客の要望をそのまま仕様にせず、「なぜ必要なのか」「何が変われば成功なのか」まで掘り下げられる方
● 情報が不足している状況でも、事実・仮説・未確認事項を分けて論点を整理できる方
● 顧客に寄り添いながらも、実現不可能・優先度が低い要望については理由を示して調整できる方
● 顧客・事業・PdM・エンジニアそれぞれの立場を理解し、一方に偏らず合意点をつくれる方
● スケジュールを守ること自体ではなく、プロジェクトの目的・成果・ユーザー価値から逆算できる方
● 変更や不確実性を避けるのではなく、影響範囲と選択肢を整理して意思決定を前に進められる方
● 自分だけが分かる状態を作らず、判断背景や決定事項をドキュメントとして残せる方
● 個別案件で得た学びを、次の案件で再利用できる仕組み・プロセスへ変えることに関心がある方

募集情報