はじめに
こんにちは。estieでプロダクトマネージャー（PM）をしている三橋です。
このブログは「PM Blog Week」第4弾・5日目の記事であり、6月開催予定の estie PM Meetup に向けた連載の一部としてお届けしています。<<前回ブログはこちら>>
estieに入社して約1年半。変わらず毎日ワクワクしながら仕事をしています。estieで働くことの魅力や楽しさをもっと多くの方に伝えたいので、ぜひカジュアル面談やPM Meetupで直接お話できれば嬉しいです。
今回は、最近ようやく一段落したプロジェクトを振り返る中で、「やっぱりこのチームの動き方、いいな」と改めて感じたことがありました。その感覚を言語化し、estieならではのPMスタイルの一つの実例としてご紹介します。
なお、これはestie全体で公式に採用されている方法論ではなく、あくまで裁量ある環境だからこそ実践できている、一つのPM像として捉えてもらえたら嬉しいです。
私のミッションについて
私が所属する事業部のミッションは、SaaSプロダクトを「売ること」そのものではありません。
私たちのチームは、エンタープライズ顧客の不動産領域におけるDXパートナーとして、estieの資産を活用し、顧客の課題解決にフルコミットすることを目指しています。
そのため、完全に個別開発というわけでもなく、
- 汎用性のあるプロダクトを設計・提供しつつ
- 顧客ごとに最適化した価値提供を実現する
というアプローチを同時に走らせる、非常にチャレンジングかつやりがいのあるポジションにいます。
プロダクトを作りながら、それだけではカバーしきれない課題にも踏み込める。そんな「プロダクト」×「コンサルティング」的な面白さがこのチームにはあり、これ以上ないくらい毎日が楽しいです。
プロダクトにスピードは不可欠、でもそれだけでは足りない
そんなチームで一貫して大事にしてきたのが「スピード」です。
もちろん、スピードはどのスタートアップにとっても永遠のテーマであり、私自身も、
早く作って、早く出して、そこから学んでPIVOTする という姿勢を基本にしています。
とはいえ、実際にやってみると「スピードを出す」ことは口で言うほど簡単ではありません。
例えば、
- 関係者が多く何をいつ作るかという意思決定に時間がかかる
- 失敗した際に開発リソースの無駄使いになるのでは？と心配して思考や議論により多くの時間を使う
- プロダクト規模が大きくなり、品質担保が優先される
こうした様々な要因が、日々チームの開発スピードを阻害する要因になり得ます（もちろん、それぞれには意味があるので、一概に悪いというわけでもありません）。
さらに言えば、「スピードが正義」と言い切ってしまうと、見落とすことも多いです。
乱暴にプロトタイプを作っているだけでは、目先の課題の解決はできても、永遠に顧客の本質的な課題の解消には至りません。
スピードを出すために「捨てていい」もの「捨ててはいけない」もの
このチームの進め方が心地よい理由を、自分なりに言語化してみました。
これはチーム発足時から狙ってそうしたわけではなく、結果的にそうなっているものであり、本ブログ執筆時に改めて言語化したものです。あくまでも、現時点における私のチームの状況を記述しています。
スピードのために「捨てていい」もの
| 項目 | 説明 |
|---|---|
| 完璧なUI/UX | 最初から作り込みすぎない。まずは動くもの、価値検証が優先 |
| 万人向け機能 | 一部ターゲットに最適化してでも、早く届ける |
| 技術的エレガンス | 美しさより動作優先。後からリファクタ可能 |
| ドキュメント | 要件や設計は最低限。デザインベースで仕様を共有 |
| 初期のスケーラビリティ | 最初は手作業でOK。効率化は後回し |
| スクラム開発の厳密な運用 | スクラムの形式にとらわれず、個々人が自由に開発を進めることでスピードを確保 |
スピードのために「捨ててはいけない」もの
| 項目 | 説明 |
|---|---|
| 長期的なプロダクトビジョン | 日々の判断を短期最適にさせないための磁場 |
| 顧客の一次情報 | 常にユーザーの現場から学び、仮説をアップデート |
| オフサイトでの議論文化 | 迷ったら集まってホワイトボードで議論。これが一番早い |
この中で、スピードを重視しつつも特に大切にしていることは以下の二つです。
1.長期ビジョンがあるから、小さな判断が速くなる
PMにとっても、チームにとっても、日々大量の意思決定を行う中で、「長期的にどんな未来を目指すか」という方向性の共通認識は不可欠です。
ただし、それは完璧なビジョンでなくても構いません。「なんとなくこの方向に行きたい」という共有感覚があるだけで、チームの判断スピードは段違いに上がります。
実際、私たちのチームでも、つい先日「この先の3つの未来、どれに進むか？」といった議論をしたのですが、答えはまだ出ていません。でも、そういった議論があるからこそ、今自分がやっていることが何につながり得るのか？そのためにはどうしておくのがいいのか？を各自が考えることができるようになり、目の前の意思決定に迷いがなくなると思っています。
2.一次情報に勝る仮説はない
とはいえ、どんなに仮説を立てても、それはただの想像でしかありません。
何よりも重要なのは、「顧客の現場で、リアルタイムで何が起きているのか」を体感すること。
- 現場で見える苦労
- ユーザーが発する一言のトーン
- 表情の動き
こうした「ノイズを含んだ情報」こそが、本当の意味での一次情報になると思っており、私のチームでは最も大切にしています。
言うなれば、PMにとっての一次情報とは、「（議事録などの）記録」ではなく「ユーザーの声を聞くという体験」そのものであり、これに勝る仮説はないと思っています。
「深さ」とは、仕様に書かれていない文脈を読む力
プロダクト開発における「深さ」とは、単なる技術的な網羅性や綺麗なUI設計ではないと、estieでのPM経験から強く感じています。
現場を観察する中で立ち上がる、
- 業界特有の暗黙知
- 歴史や商習慣に根ざした構造的な制約
- 意思決定の背景にある文脈や価値観
こうした「見えない情報」は、仕様書やFigma、あるいはJIRAのチケットの中には書かれていません。しかし、これらを理解しないままでは、ユーザーにとって本質的な価値を持つプロダクトをつくることはできません。
これこそが、estieにおけるPMに求められる「深さ」であり、バーティカルSaaSに携わることの最大の魅力でもあると私は考えています。
やや専門的な例にはなりますが、オフィス不動産領域で、テナントが借りる「貸室（区画）」を管理する機能を開発した際のことです。
当初は「一物件に複数の貸室が存在する」という構造をどうデータモデルとして扱うかという、技術的な課題から着手しました。しかし、現場の担当者と対話を重ね、実際のデータや図面を見せてもらう中で、単なるデータ構造の問題では済まされない、業界特有の複雑な背景が見えてきました。
たとえば、
- 貸室の境界は、テナントの入退去に合わせて頻繁に分割・統合される
- 借り手の要望に応じて、倉庫や空調室のような非典型的スペースも契約対象になる
- 古い物件では図面と現況が一致しないことも多く、現場ベースで運用ルールが変わる
こうした現実を踏まえると、「貸室＝固定的な空間情報」という前提自体が成立しません。結果として、プロダクトも「情報を正規化して一元管理する」ことだけを目指すのではなく、「あえて曖昧さを残し、現場の柔軟な運用に寄り添う」ような設計を採る必要があると判断しました。
バーティカルSaaSの面白さは、上記の例のように、ドメイン理解がプロダクトの成長に直結する点です。
- 業界のリアルを知れば知るほど、プロダクトをより良くできる
- その実感があるから、顧客に会いに行くのが楽しくなる
- 会えばまた学びが増え、プロダクトを進化させたくなる
このスピードと深さの循環こそが、「私」がestieで目指しているプロダクト開発の在り方です。
最後に
estieは「産業の真価を、さらに拓く」というパーパスを掲げています。もしバーティカルSaaSの面白さを一言で表すとしたら、それはまさにこのパーパスに集約されると感じています。
estieは、ただプロダクトを提供するだけではなく、業界の当たり前を見直し、情報の構造そのものを再定義し、標準フォーマットへと昇華させていくことを目指しています。そのプロセスには、業務の深い理解と、プロダクトを通じた未来設計が欠かせません。だからこそ、プロダクトをつくることが、そのまま業界の未来をつくることにつながる。それが、バーティカルSaaSの最大の醍醐味です。
このブログを読んで、少しでもバーティカルSaaSに興味を持ってくださった方へ。
estieでは、ドメイン知識ゼロからスタートしたPMも多く活躍しています。他産業から飛び込んできたメンバーのリアルな経験談を、ぜひカジュアル面談でお話しできればと思います。
お気軽にご連絡ください！
また、6月24日に開催予定のこちらのイベントでは、 estie に加えてログラス様、SmartHR様、BASE様から PM と Bizdev がそれぞれ集まり「新規事業 PdM vs Bizdev どっちが重要？ガチンコ対決」と言う今回の記事の上位概念のようなテーマで徹底議論を行います。
オフレコトーク盛りだくさんの熱いイベントになると思いますので、ぜひお越しください！
