不動産バーティカルSaaSに見るアーキテクチャーと開発体制の変革、意思決定・実行プロセス

今回は「不動産バーティカルSaaSに見るアーキテクチャーと開発体制の変革、意思決定・実行プロセス」についてご紹介します。

関連ワード （ソフトウェア等） についても参考にしながら、ぜひ本記事について議論していってくださいね。

本記事は、ZDNet Japan様で掲載されている内容を参考にしておりますので、より詳しく内容を知りたい方は、ページ下の元記事リンクより参照ください。

　顧客への持続的な価値提供が事業展開と密接に結び付くSaaSビジネス。その性格上、長期的な事業戦略を組み立てながら開発環境や組織体制を適宜見直していくことが重要です。

　中でも、特定の業界・業種に特化したバーティカルSaaSにおいて、一連の業務を細分化して支援するプロダクトを個別に開発し、それらを複数導入することで総体的な業務課題の解決を図る――というビジネスモデルになるケースが多いです。そのため、複数のプロダクトが個々に存在しながら強く連携していく必要があり、プロダクトの成長過程において組織やシステム設計も合わせて見直していかなければなりません。

　とはいえ、これまで積み上げてきた開発環境や組織体制を変えることは、大きな負担を伴います。私が執行役員 CTO（最高技術責任者）を務めるイタンジも、不動産業界におけるバーティカルSaaS企業です。今まさに意思決定を行い、2015年の初代プロダクトを端緒とする体制に対して変革を進めているところです。

　事業展開に伴って見えてきた課題とその背景をひもといた前回に続き、今回は実際にどのように変革に着手して進めているのか、具体的にお伝えできればと思います。

　最初に、私たちイタンジのビジネスや体制について、簡単にご説明します。当社は賃貸・売買、実需・投資、仲介・分譲・管理など、多くの領域が存在する不動産業界において、各領域の業務フローを細分化する形で複数のSaaSプロダクトを展開しています。2015年にリリースしたファーストプロダクトである「ぶっかくん」を皮切りに事業を拡大し、単一チーム・単一システムでの開発から複数チームで別個のシステムを開発する体制へと変更しました。意思決定や開発スピードを最優先事項として選択したこのアーキテクチャーと組織編成は、事業成長に寄与しました。一方で、事業全体として足並みがそろいづらくなる、本来一貫した業務改善体験を届けるべきところが、各システムの連携が複雑になってしまうといった課題が見られるようになってきました（詳しい意思決定プロセスや背景については、前回の記事をご覧ください）。

　今回、変革に踏み切った点は、大きく2つです。1つ目はシステムのアーキテクチャーの変更、2つ目は開発体制の改善です。2023年の春ごろに意思決定を行い、本格的に実施していくことになりました。

　それまで組織として課題感を持ちつつも、プロジェクトの期間が長くなることから効果がすぐに見られない上に、方針転換は、日々行われる通常の開発業務への負担を一時的に増やす可能性もありますので、意思決定は非常にハードルの高いものでした。それでも、このタイミングで行うことを決断した理由は具体的に3つあります。

　1つ目の理由は、今後の事業展開を考えるに当たり、いずれは行わないといけないという強い課題認識があったためです。当社の事業モデルとして、1社のお客さまに複数プロダクトを導入いただけることで事業を伸ばしていくという大きな流れがあります。お客さまの事業規模に関わらず、本来シームレスに連携しているべき各プロダクトが個別最適化されてきたため、例えば、同じデータを連携するにも非常に多くの時間を要するという事情がありました。この点を改善することでの効果は、エンジニアだけでなく、社内のプロダクト導入担当などの関係者にとっても期待できるものでした。

　2つ目の理由は、エンジニア組織の拡大です。当社には多数のプロダクトがあり、従来はそれぞれのプロダクトを担当する独立した小さな開発チームが10チームほど存在していました。極端に言えば、組織がサイロ化しかけていたのです。技術構成などは近しいにも関わらずナレッジが共有されづらく、本来技術的に再利用可能な部分も個別に異なる形で作られていました。今後の事業展開に合わせて組織を拡大したいとなった際に、プロダクト開発体制の再現性が高くない状況だったのです。一方で、この点を改善できればより安定的に一定の品質が担保されたプロダクトを今後も生み出し続けることが可能になると考えていました。

　では、それをいつどのタイミングで行うのか。重い判断を下すきっかけになったのが、3番目の理由です。折しも、社内全体でフルコミットするレベルの大型案件のプロジェクトが完了したタイミングでした。私自身もそのプロジェクトの間は、現場サイドで開発に携わっていました。一年がかりだったプロジェクトが終わり、これからの事業とプロダクトの展開として全体最適を考えるフェーズであることを再認識したことなどから、これを契機として、いよいよ改革に踏み切ることになったのです。