こんにちは、ゴーレム採用チームです!
ゴーレムでは現在、ITプロジェクトマネージャー(ITPM)を募集しています。
「プロジェクトマネージャー」と聞くと、スケジュールや進捗を管理する仕事を思い浮かべる方が多いですよね。ゴーレムのITPMは、それより少し手前の段階から関わります。顧客の「こうしたい」を、開発チームが動ける形にするところから担います。
上流PM、ITコンサルティング、業務設計などのご経験がここで活きそうか。それを確かめる材料として読んでいただけたらうれしいです。
目次
01 | なぜ今、このポジションを採用するのか
案件が増えるほど、上流工程が大事になる
ゴーレムでは事業が広がり、顧客と一緒に進めるプロジェクトも増えています。
開発を始める前に、顧客と話し合い、業務を整理し、何を解決し、どこまでを扱うかを顧客や社内と整理する。こうした開発前の段階を「上流工程」と呼びます。
現在は、顧客との折衝、業務の整理、要件定義、社内調整を、複数のメンバーがほかの業務と兼務しています。この形のまま案件が増えると、次のようなことが起きやすくなります。
- 特定のメンバーに負荷が集中する
- 案件によって、要件整理の細かさにばらつきが出る
- 顧客と開発チームの認識がずれ、開発が始まってから仕様変更や手戻り(一度進めた作業のやり直し)が起きる
上流工程を担うITPMを募集する理由
こうした状況を受けて、上流工程を担うITPMを募集しています。
期待しているのは、一つひとつのプロジェクトを前に進めることだけではありません。案件が増えても上流工程の質がぶれにくいよう、進め方そのものを整えていくことも、このポジションに期待している役割です。
02 | ゴーレムの事業とITPMのミッション
現場の知見を、データとして活かすために
ゴーレムは、建設業界に特化したデータプラットフォームを開発しています。対象にしているのは、建設業界に蓄積されてきた見積・設計・施工・維持管理などのデータと、実務の中で培われてきた判断基準です。これらを構造化し、業務の効率化や意思決定を支えることを目指しています。
建設のプロジェクトでは、会社やプロジェクトによって、見積の形式、業務の流れ、管理の方法、判断の基準が異なることがあります。情報がExcelやPDF、担当者の経験に分かれて存在していることもあります。
ゴーレムは、こうした形式がそろっていない情報や、担当者の経験に支えられてきた情報を、データとして扱える状態に変え、CO₂排出量の算定や、見積・購買、業務分析など、複数の業務テーマへ展開しています。担当者が積み重ねてきた知見を、ほかの人も業務や判断に使いやすい形にしていく取り組みです。
ITPMは、顧客の業務とプロダクトの間に立つ
ゴーレムが重視しているのは、顧客の業務とデータの状況を理解したうえで、現場で継続して使える業務・システムとして実装することです。業務の進め方や判断の基準が顧客ごとに異なることがあるため、「この顧客の、この業務で、何を解くのか」は案件ごとに整理する必要があります。
その場所に立つのがITPMです。ミッションは、顧客の業務と要望を整理し、顧客と社内が共通の認識を持ってプロジェクトを進められる状態をつくること。顧客の現場と、ゴーレムのデータ基盤・プロダクトをつなぐ入り口にいる役割です。
03 | ITPMの具体的な仕事
ITPMの仕事は、大きく5つの領域に整理できます。案件の状況に応じて、必要な領域に取り組みます。
顧客業務・課題の構造化 ── 何に困っているのかを分解する
顧客の経営層、推進責任者、実務担当者のそれぞれに話を聞きます。同じ会社でも、立場によって見えている課題は違いますよね。
整理するのは、いまの業務の流れ、担当者、使っているデータやシステム、判断が行われるポイントです。そのうえで、「こういう機能が欲しい」という要望と、その裏にある原因や制約を分けて考えます。判断の材料になるのは、たとえば次のような点です。
- 誰が、どんな場面で、どのくらいの頻度でその業務をしているか
- いまの業務にどんな影響が出ているか
- 導入の前と後で、何がどう変わればよいか
これをもとに、顧客や社内の関係者と、今回のプロジェクトで「解く課題」と「解かない課題」を整理します。
ビジネス要件・プロジェクトスコープの定義 ── どこまでやるかを明確にする
スコープとは、プロジェクトで扱う範囲のことです。対象の業務と利用者、期待する成果を明確にし、「必ず必要な要件」と「追加の要望」を切り分けます。ビジネス要件とは、その業務で何ができれば成果といえるか、ということです。
ある要望に、どの方法で応えるかを考えるのもこの領域です。
- プロダクトにもともとある標準機能で対応する
- 設定や運用の工夫で対応する
- 個別に開発する
この判断は、プロダクトマネージャー(PdM)、エンジニア、機械学習エンジニアと一緒に、実現できるか、費用はどのくらいか、運用の負担はどうか、という観点で検討します。最後に、プロジェクトのゴール、前提、制約、役割分担をはっきりさせます。
顧客・社内の合意形成 ── 選択肢を示して、決めるのを支える
対応のしかたが複数あるときは、それぞれの良い点・悪い点・影響を整理し、おすすめの方針を示して、顧客や社内の意思決定を支えます。要件、範囲、役割、スケジュール、まだ決まっていないことについて合意をつくります。途中で仕様の変更や追加の要望が出たら、ほかにどんな影響が出るかを分析して管理します。
プロジェクト推進 ── 止まらないように先回りする
計画と節目、意思決定が必要なタイミングを整理します。顧客側・社内側のタスク、課題、リスク、作業同士の依存関係(「Aが終わらないとBに進めない」といったつながり)を見える化します。
会議を設計して進行し、記録を残しながら、部門をまたいで調整します。問題は小さいうちに共有して解決につなげ、導入、受け入れ確認、リリースに向けて顧客と調整します。
上流工程の標準化 ── 次の案件で使える形に残す
ヒアリングや要件整理の進め方をそろえ、業務フロー、要件、論点、決定事項、リスクをまとめるテンプレートを整えます。プロジェクトの開始から開発への引き継ぎまでの標準的な流れもつくります。過去の案件での判断、失敗、手戻りの原因をためていき、似た案件で使い回せる業務・要件のパターンとして整理します。
04 | 他のポジションとの関係
顧客・PdM・エンジニアと、誰が何を決めるのか
顧客のプロジェクトでは、PdM、エンジニア、機械学習エンジニア、営業、カスタマーサクセスなど、多くのメンバーと一緒に動きます。ITPMは、それぞれの専門分野を代わりに担うわけではありません。判断に必要な前提をそろえて、プロジェクトを前に進める役割です。
想定している役割分担は次のとおりです。
- ITPM:顧客の課題とビジネス要件を整理し、個別プロジェクトの合意形成と進行を担う
- PdM(プロダクトマネージャー):複数の顧客の課題をふまえて、プロダクトとして何を解くかを考え、要件・優先順位・仕様・リリースを判断する
- エンジニア・テックリード:技術的にどう実現するか、システムをどう設計するかを担う
ただし、きれいに線を引いた分業ではありません。ITPMが一人で仕様を決めることはなく、顧客にとっての価値、プロダクトの方針、開発コスト、保守のしやすさをふまえて、PdMやエンジニアと話し合いながら対応方針をまとめます。たとえば「この要望を標準機能で受けるか、個別開発にするか」は、ITPMが整理した顧客の業務課題、PdMのプロダクトとしての判断、エンジニアの技術的な見通しを持ち寄って決めていきます。
05 | 入社後に期待すること
入社後の流れを、目安としてご紹介します。実際の進め方や時期、担当範囲は、案件の状況とご本人の経験に応じて調整していきます。
入社後約3か月:既存案件に入り、現場から理解する
入社後は、まず進行中のプロジェクトに入り、既存メンバーやほかのPMと一緒に動きながらキャッチアップしていくことを想定しています。ひとつのプロダクトの、ひとつのプロジェクトを、まずしっかり進めていただくところから始めるイメージです。キャッチアップには約3か月を想定しています。担当する案件やこれまでの経験に応じて、必要な期間は変わります。
立ち上がり後:経験と案件に応じて、担当を広げる
その後、少し長めに立ち上がりの期間をとるのか、次のプロジェクトを担当していくのかは、案件の規模やご本人の経験に応じて調整していきます。
担当するプロジェクトでは、顧客の課題整理や要件定義、合意形成、プロジェクト推進を、PdMやエンジニアと協力しながら担っていくことになります。どこまでを受け持つかは一律に決まっておらず、案件の規模やご本人の経験を見ながら検討していきます。
その先:案件の学びを、チームの仕事の型にする
担当する案件で得た学びや手戻りの原因を、上流工程の標準化へつなげていくことも期待しています。顧客の要望をプロダクト開発へつなぐ流れを、案件を進めながら少しずつ形にしていくイメージです。あわせて、「なぜそれが必要なのか」まで掘り下げて合意をつくり、次の判断へつなげる進め方を、ご自身の仕事の型にしていってもらえたらと考えています。
06 | このポジションだから得られる経験
「何を解くか」を整理する段階から関われる
どんなに上手に進めても、ゴールがずれていたら成果にはつながりませんよね。このポジションでは、要望が出てくる前段から顧客の業務を理解し、何を解き、どこまでを対象にするかを、顧客や社内の関係者と一緒に整理する段階を担当します。複雑な業務から課題と範囲を構造化する視点を、実際の案件の中で鍛えられる経験です。
目の前の顧客の先にある、プロダクトの判断に触れられる
個別の案件で見えた課題や知見をPdMに伝え、複数の顧客に共通する価値として、プロダクトで何を解くべきかを一緒に考えることもあります。もちろん、すべての要望がプロダクトに入るわけではありません。それでも、顧客と開発の双方に関わりながら、「この課題は、ほかの顧客にも効くだろうか」という視野で物事を見られるのは、このポジションならではの経験です。
自分の進め方を、チームの仕組みにできる
案件ごとに得た判断や学びを、次の案件でほかのメンバーも使える形にしていく。自分の中にだけある「うまく進めるコツ」を言葉にして仕組みに変えていくことは、個人のスキルをチームの力に変える経験になります。
07 | どんな人に合う/合わないか
曖昧な状況から、論点を整理していきたい方へ
この仕事では、情報がそろっていない中で判断を進める場面があります。そんなときに、次のような進め方を自然にとれる方には、なじみやすい仕事だと思います。
- 要望をそのまま受け取らず、「なぜ必要か」「何が変われば成功か」を確かめたくなる
- 情報が足りなくても、事実・仮説・まだ確認できていないことを分けて考える
- 目的や成果、使う人にとっての価値から考えて、次の判断をつくる
- 先が見えない部分は、その影響と選択肢を整理して示す
- 相手に寄り添いながらも、難しいことや優先度の低いことは理由を示して調整する
- 顧客、事業、PdM、エンジニアそれぞれの視点を理解し、合意できる点を探す
- 判断の経緯を文書に残し、学んだことを次に使える仕組みにする
活かしやすい経験と、正式な応募要件
現在の求人票に記載している応募要件は、次のとおりです。内容は更新されることがあるので、最新の情報は求人票でご確認ください。
必須要件
- BtoB向けWebシステム、業務システム、SaaSなどのITプロジェクトを推進した経験(目安3年以上)
- 顧客や業務部門へのヒアリングを自ら行い、現状・課題・要望を整理した経験
- 曖昧な要求を、ビジネス要件、スコープ、業務フロー、確認事項などに具体化した経験
- エンジニアと協力し、要件定義から開発・導入・リリースまでのいずれかを主体的に進めた経験
- 複数の関係者の間で論点を整理し、合意をつくった経験
- 要件、業務フロー、論点、決定事項、リスクなどを文書にまとめた経験
プログラミングの実務経験は必須ではありません。ただし、Webシステムの基本的な仕組みを理解し、エンジニアと会話できることは求めています。エンジニアと対応方針を検討するときに、実現できるかどうかや制約について話し合える理解が必要だからです。
歓迎要件
- エンタープライズ(大企業)向けの大規模・長期プロジェクトの経験
- ITコンサルタント、システムコンサルタント、PM/PL、導入コンサルタントとしての経験
- 業務分析や業務プロセス設計(BPR、As-Is/To-Be設計)の経験
- ERP、基幹システム、BtoB SaaSなどの導入・定着プロジェクトの経験
- 複数の部門・拠点や経営層との合意形成の経験
- 要件定義やプロジェクト推進の進め方を標準化した経験
- API、データ連携、データベース、クラウドに関する基礎知識
- AI、機械学習、データプロダクトに関わるプロジェクトの経験
- 建設、建築、不動産、積算、サステナビリティ分野の知見
歓迎要件は、あると活かしやすい経験・知識です。応募の必須条件ではありません。
進め方によってはギャップを感じるかもしれません
判断の材料として、仕事の進め方の違いも正直にお伝えします。次のような働き方をしてきた方は、ゴーレムのITPMとの間にギャップを感じるかもしれません。
- 進捗管理、会議運営、レポート作成が中心だった方:ここでは計画を管理するだけでなく、計画の前提となる「何を解くか」を整理するところから関わります。
- 仕様が決まった後の工程が中心だった方:顧客との対話を通じて、業務課題や要件を自分で整理することが仕事の出発点になります。
- 役割や手順がはっきり決まった環境を好む方:前提がそろっていない状況でも、論点や次の一手を自分で見つけ、関係者を巻き込みながら進める場面があります。
どれも、それぞれの現場で求められる大切な経験や働き方です。ここに挙げたのは優劣ではなく、仕事の始まり方や進め方の違いです。ご自身の経験とどこが重なり、どこが新しい挑戦になりそうかを考える手がかりにしていただければと思います。
いかがでしたか?
ゴーレムのITPMは、顧客の業務や課題を整理し、顧客と開発チームの合意をつくりながら、プロジェクトを前に進める仕事です。
この記事が、ゴーレムで働く姿を具体的にイメージするきっかけになればうれしいです!