ID:83304さん

## 概要 https://pntwhere.com/ WHERE は「衛星 × AI × 不動産」を組み合わせた SaaS プロダクトを提供しています。 衛星データと AI を活用することで、まだマーケットに出ていない不動産を発掘し、良質な物件を誰よりも早く仕入れられるサービスを展開しています。 本事業は、東京大学大学院 (JAXA 宇宙科学研究所) 在学中に、現在の代表と 2 人で立ち上げました。 大学院では「月のクレーターを AI で解析する研究」を行っており、その技術を「月から地球へ」「クレーターから不動産へ」応用したことが、現在のプロダクトの原点になっています。 創業以来 3 年間、プロダクト開発に関わる全領域を統括し、プロダクト・組織の両面を牽引。 2025 年時点で ARR 3 億円規模、社員数 50 名超、エンジニア組織 20 名規模 (うち正社員 10 名) まで成長しました。 現在は、自ら採用・育成したメンバーへ CPO ロールを引き継ぎ、自身は VPoE として技術領域およびエンジニアリング組織にフォーカスしています。 ## プロジェクト経験 ### 1. 衛星 × AI × 不動産 SaaS のプロトタイプ開発 / 最初期の市場検証 **課題** - 不動産業界では、良質な物件をスピーディに仕入れる手段が限定的で、現地調査や口コミに依存していた - 「マーケットに出る前に良質な物件を見つける」という業務に再現性がなく、機会損失が発生していた **工夫** - 大学院での月クレーター解析 AI 研究を応用し、衛星画像から不動産候補地を検出する AI モデルを構築 - TS/React/Next.js (フロントエンド)、Python/FastAPI (バックエンド)、AWS (インフラ) を一人で実装し、1ヶ月半で MVP を提供 - 「衛星から不動産を発掘する」という新概念をユーザーに伝えるため、UI は「触って価値が伝わる」シンプルさを最優先で設計 **成果** - プロトタイプ段階で 3 社導入 (月間 ARPU 50 万円) - 「衛星 × AI × 不動産」というカテゴリ自体の初期 PMF を確認し、その後の資金調達・組織拡大の起点に ### 2. AI 推論結果のデータベース化によるレスポンス改善とインフラ投資の最適化 **課題** - AI モデルの推論時間が長く、ユーザーが探索したいエリアに求める不動産があるかを即座に判断できない - リアルタイム性の欠如が一部ユーザーの Churn 懸念に直結していた - リアルタイム推論基盤に切り替えるには、当初試算で 1,200 万円規模の投資が必要だった **工夫** - 「リアルタイム推論」ではなく「事前推論 + クエリ探索」というアーキテクチャに転換し、推論結果を地理空間データベース化 - 探索のベースラインを DB クエリで完結させ、必要に応じてオンデマンド推論を追加する 2 段構えに - データ収集・推論で利用するインスタンスタイプ (GPU/CPU・Spot 活用) とデータの持ち方 (パーティション設計・圧縮形式・空間インデックス) を見直し、ストレージ・I/O コストを削減 - 結果、当初試算 1,200 万円 → 800 万円弱まで投資コストを圧縮 **成果** - 推論時間: 数十分〜数時間 → 数秒 に短縮 - Churn 懸念のあった複数の主要ユーザーの離脱を阻止 (2〜3 社の Churn 阻止で投資回収できる試算ラインを大きく上回る効果) - 「リアルタイム推論にこだわらない」アーキテクチャ判断により、開発・運用コスト両面で持続可能な仕組みを構築 ### 3. プロダクト品質の改善 (変更障害率の削減) **課題** - リリース後の不具合が多く、変更障害率 (DORA Four Keys) が約 40% に達していた - 単純なテスト不足だけでなく、上流工程 (事業開発・PdM・エンジニア) における要件・仕様の認識ズレが下流の品質に波及していた **工夫** - 短期 (止血): 専任 QA テスターを採用し、まずは手動でのリグレッション検証ラインを整備 - 中期 (自動化): ユニットテストのカバレッジを引き上げ + 人手で行っていたリグレッションを E2E 自動テストに段階的に移行 - 根本対応: 不具合の発生源を遡って分析し、上流のコミュニケーション齟齬が主要因と特定。事業開発 → PdM → エンジニア のコミュニケーションラインと受け渡しドキュメントを再設計 - カルチャー面では「失敗は仕組みで解決する (人を責めない)」をチームに浸透させ、ポストモーテムを定着 **成果** - 変更障害率: 約 40% → 20% 台 に 1 ヶ月で改善 - 手戻りコストが減少し、エンジニアが新規価値創出に使える時間が増加 ### 4. リリース頻度の向上 (GitHub Flow + モノレポ化) **課題** - リリース頻度が低く、ユーザーへの価値提供サイクルが長くなっていた - 各サービスが分散リポジトリで運用されていたが、サービス境界が曖昧な「なんちゃってマイクロサービス」状態になっており、横断変更のコストが高かった **工夫** - 分散していたリポジトリをモノレポ化し、横断変更を 1 PR で完結できる構成に再編 - ブランチ戦略を GitHub Flow に統一し、トランクベース開発に寄せた - CI/CD パイプラインを整備し、レビュー〜デプロイのリードタイムを短縮 **成果** - リリース頻度: 1 回/day 以上 に向上 - 1 リリースあたりのバッチサイズが小さくなり、ロールバック容易性とレビュー精度が向上 → 定性的にも品質が向上 - ユーザー価値を最速で届けられる開発体制を確立 ### 5. エンジニアリング組織の立ち上げ・拡大 (採用・組織作り) **課題** - 創業初期はプロダクト全領域を自分一人で開発しており、事業拡大に対してスケールの限界が見えていた - スタートアップ × 「衛星 × AI × 不動産」というニッチ領域でエンジニア採用の難易度が高く、ターゲット人材にリーチすること自体が難しかった **工夫** - **採用ブランディング・情報発信**: 「衛星 × AI × 不動産」というユニークな技術領域を武器に、イベント開催・登壇・ポッドキャスト出演などを通じて潜在候補者に対する認知を獲得。母集団形成のコストを下げた - **カルチャーフィットを最重視した評価基準**: AI 時代において純粋な技術力の比重は相対的に下がっていると判断し、「一定以上の技術力 / AI 活用力」をクリアした候補者については、Spirit / Mission / Vision / Value への共感度を最大限重視する評価基準に再設計。組織の Agility を高め、入社後のミスマッチを低減 - **技術力・AI 活用力の見極めプロセス**: 自ら設計した口頭ベースの簡易コーディングテストで「一定以上」のラインを判定。質問はテンプレート化して再現性を担保し、選考者ごとの判断ブレを最小化 - **権限委譲を前提とした組織設計**: 自身が CPO 業務を抱え込まず、採用・育成したメンバーが活躍できるロール (CPO / テックリード等) を設計し、段階的に権限委譲 **成果** - エンジニア組織を 20 名規模 (うち正社員 10 名) まで拡大 - 自ら採用・育成したメンバーに CPO ロールを引き継ぎ、自身は VPoE として技術領域へフォーカスできる体制を実現 ## 使用技術 ### バックエンド - **Python / FastAPI**: AI モデルとの地続きの実装、開発速度を理由に選定。FastAPI は 2019 年から利用しており、習熟度が高い ### フロントエンド - **TypeScript / React / Next.js**: WHERE 創業時から採用。最も得意かつトレンドのある技術を採用。 - **UI Framework**: 当初は Material-UI を採用。プロダクト全体の大規模リファクタのタイミングでカスタマイズ性やトレンドを考慮し **shadcn/ui** に移行 ### インフラ - **AWS**: インフラ全般 (ECS on Fargate / Lambda / RDS / S3 / Amplify など)。当初はマネジメントコンソールを利用していたが，プロダクトが安定化してきてからは AWS CDKを採用し，インフラのコード化を進めた． ### AI / 機械学習 - **Python / Jupyter Notebook / PyTorch / Transformers**: 衛星画像解析・物体検出モデルの開発。大学院での月クレーター解析 (CNN / Transformer 系手法) の知見を不動産領域に応用 ### その他 - **Snowflake**: 直近採用。巨大な GIS データの分析・配信基盤として活用 - **Google Maps API**: 地理空間データの可視化・ジオコーディングで利用 ### 技術選定時に重視している観点 - **開発スピード**: 特に PMF 前は最優先 - **ROI / 投資価値**: コストが大きい技術は投資回収シナリオを必ず検討 (例: AI 推論基盤を 1,200 万円 → 800 万円弱に圧縮) - **スケーラビリティ**: データ量・ユーザー数の増加に耐えうるか - **AI との親和性**: ML パイプラインと地続きで扱える言語・基盤を優先 ## 思考プロセス・働き方 ### 意思決定の軸 - **Why → What → How の順で考える**: 目的・背景 (Why) を明確にしてからゴール (What) を定義し、最後に手段 (How) を選ぶ。手段先行の意思決定を避ける - **AI Driven Development**: AI をプロダクトだけでなく開発プロセスにも組み込み、コードレビュー・生成・ドキュメンテーションの効率を最大化 - **再現性・スケーラビリティ・可観測性・透明性**: アーキテクチャ・組織の仕組みを設計する際の 4 観点として常に確認 ### 組織づくり - **失敗は仕組みで解決する (人を責めない)**: インシデントは個人ではなくプロセス・仕組みの課題として扱う - **アジャイル / スクラムの思想を重視**: PDCA が最速かつ健全に回る状態を目指し、スクラムの三本柱 (透明性 / 検査 / 適応) を起点にプロセスを設計。メンバー間の助け合いが自然発生するチームづくりを心がけた - **心理的安全性の確保**: エンジニアが安心して発言・チャレンジできる状態を維持 - **個々が一番活躍できる領域への配置**: メンバーごとに「一番やりたい・活躍できる領域」で力を発揮できるよう、役割・権限委譲を設計