時代とともにITエンジニアに求められる能力は変化しています。
今やさまざまな業界がIT技術を導入し、かつての商流にあった課題を解決するためのサービスが生まれました。提供サービスの多様化、細分化にともなって、その業界のプロセスを理解し、ユーザーニーズを捉えられる人材が求められています。ITエンジニアも例外ではなく、技術力に加えてその業界への深い知識も必要になりました。
この記事では、不動産会社向けのSaaS事業を手掛けるイタンジ株式会社の執行役員VPoE 福崎元樹さんに、Vertical SaaSを開発するエンジニアに必要な資質や組織づくりについてイタンジでのご経験をもとに解説していただきます。
不動産賃貸における課題をテクノロジーの力で解決したい
イタンジでは、不動産会社向けのSaaS事業をメインに扱っています。引越しの経験がある方はご存じかもしれませんが、不動産所有者の多くは、不動産管理会社に物件の管理や運用を委託しています。それらの物件に空きが出ると国土交通省のデータベースに物件情報を登録します。このデータベースは不動産会社しか閲覧できないようになっていて、わたしたちが引っ越し先を探すときに閲覧できるのは、不動産仲介会社がユーザー向けに物件を公開している物件情報サイトです。
この一連の商流における大きな問題として、国土交通省のデータベースの更新がリアルタイムでないことがあげられます。そのため、登録されている情報は正しい最新のものと古い間違ったものが混在しています。その情報は物件情報サイトにそのまま掲載されますが、情報量が多くメンテナンスコストがかかるため、多くが週に1回程度しかメンテナンスされず更に情報が劣化していきます。結果的に引っ越し先を探している人は、Web上で正しい情報にアクセスしての部屋探しができない状態になっています。正しい情報にアクセスしようと思うと、結局は不動産仲介会社に電話で問い合わせたり、来店して情報を出してもらうしかありません。そして、空室状況を聞かれた不動産仲介会社は、不動産管理会社に電話で空室情報を確認する、というアナログで非効率な世界になっています。
わたしたちはこの課題を解決するために、リアルタイムに更新される物件データベースを新たに作って公開することで、オンラインでも正確な情報にアクセスして部屋探しができる世界を作りたいと考えています。これを実現するため、不動産管理会社向けに、部屋探しや入居における各工程を電子化するサービスを作っています。たとえば入居申込時、従来は個人情報を紙に書いてFAXをしていた工程がスマートフォンひとつでできるWeb入居申込サービス。これを管理会社に導入していただくことで、物件に入居申し込みが入れば、その情報をトランザクションで検知します。不動産会社が手動で空室情報を書き換えなくても、情報が自動で更新されていき裏側にリアルタイムな物件データベースができてきています。こちらのサービスは現在年間50万件（※）の入居申込に使われる業界No.1のサービスに成長し、急速に普及しています。今後は契約の電子化、更新退去の電子化も進めて不動産会社の業務を電子化し、部屋探しと入居後の体験を変えていきます。
※2020年12月1日～2021年11月30日
Vertical SaaS開発企業のエンジニアに求められること
以上のように、当社のサービスは不動産分野の課題を解決するためのもので、まさにVertical SaaSと呼ばれるものです。当然ながら不動産分野に深い知識がなければ作っていくことができません。
ここからはこのようなサービスを作っていくために、当社がどのようなエンジニアを採用しているかについてお話しします。
一般的に、エンジニアの採用においては募集ポジションにふさわしいスキルを持っているかどうかが重要です。あとで詳しくお話ししますが、実際に当社でも技術力を最重要視して採用していた時期がありました。
一方、現在当社では「プログラミングだけやっていきたい」という方よりは「エンジニアとして事業にもしっかりコミットしたい」「作るからには意味のあるものを作りたい」というマインドのある方を積極的に採用しています。必然的に技術面だけでなくビジネス面を理解する意欲がある方ということでもあります。
当社ではプロダクトオーナーをエンジニアが担っており、エンジニア自身が不動産業界や事業について理解したうえで、タスクや顧客からの要望に対して、優先順位をつけ、事業を進めていきます。プロダクトごとにエンジニアが2〜3人でやっておりチームが小さいというのもありますが、技術領域にしろ、業務の領域にしろ、広く大きな裁量でやっていきたい方を求めています。
企業によっては、営業がとってきた案件をそのまま作ったり、プランナーに言われたものをそのまま作ったりする場合もあるかと思います。しかし、背景や目的が分からないまま「作れ」と言われたからとりあえず作る……という状況では、なかなかやりがいを感じられません。作るものが顧客のどんな課題を解決していて、どんなインパクトを与えるのかエンジニア自身が理解し、それを最大化するためにはどうすれば良いか考えながら作るのと、言われたまま作るのでは、できるプロダクトの質がまったく違うと思っています。
特に当社のようなVertical SaaSを提供する企業であれば、顧客の業務に深く食い込むプロダクトを作るために、エンジニアも不動産ドメインの理解が欠かせません。入社時に不動産知識がある方はなかなかいませんが、入社後、積極的に不動産ドメインをキャッチアップし、顧客課題を理解してプロダクトを作れる人が活躍していますし、そのような方に来ていただきたいと考えています。
HRT（謙虚/尊敬/信頼）の精神の重要性
また、技術以外で特に大事にしているのが、『Team Geek』で広まった「HRT（謙虚/尊敬/信頼）の精神」です。一緒に働く仲間を信頼して、尊重しあいながら学び合うことに共感していただける方を求めています。
チームビルディングにおいて、組織としてHRTの精神を大事にするようになったのは初期のチーム作りに失敗した経験がきっかけになっています。立ち上げたばかりの人数が少ないスタートアップ企業は、とにかく技術要件のみに注目しそれを満たすエンジニアを求めがちです。当社も初期のころに、技術要件のみでエンジニアを採用していたことがありました。
そうすると、人当たりが強いというか、チームとして仲間と開発する部分がやや不得手な方が出てきます。「エンジニアなのだから、技術があればほかの部分には目をつむってもいいのでは」と思われる人もいるかもしれません。しかし、チームで物作りを行う時点でソフトウェア開発もチームでアウトプットを出していく必要があります。周囲に無関心だったり、攻撃的な人が増えるとチームの心理的安全性が下がりうまく回らなくなってしまいます。実際に当社においてそのような事があり、わたしの力不足もあって離職が増えたこともありました。
そんな背景があって、同じことを繰り返さないためにもHRTの精神を大事にするようになりました。同じ目標に向かって、誰でも率直に議論できるチームにしていくためにはベースにお互いの信頼関係が欠かせません。現在は技術的にいくら優れた方でも、一緒に働く仲間を信頼して尊敬できる方でないとチームに入っていただくのは難しいと考えています。
エンジニアの評価に関する課題感
これらの基準を大切にしていくときに、採用とともに課題となるのがエンジニアの評価です。
以前は規模も小さく全員の動きが見えていたので、それほど言語化や定義づけがなくても評価に困る場面はありませんでした。ただ、当然規模が大きくなればそれも難しくなります。当社も現在社員数が150名を超える規模になっているので、どうしても「こんな人が評価されるべき」という指標をしっかり言語化して明文化していかないといけなくなりました。
エンジニアの評価については、事業への貢献度と技術力の両軸で考える必要があります。このバランスは難しく、当社でも常に検討を重ねています。評価基準は採用も含めてすべての軸になるので、社員の育成のためにもしっかりと決めていかなければなりません。リーダーから「この定義に基づくと、今はこの部分が足りないよね」とフィードバックができるようになると、メンバーの成長につながり、それが結果として良いプロダクトが作られる源泉になると思っています。
また、ビジネス分野への理解は必須とはいえ、エンジニアですからスペシャリストのためのルートも必要だと考えます。よりマネジメント寄り・ビジネス寄りのキャリアに進みたいエンジニアもいますから、本人が選べるような形が理想です。これら両方のルートを整えるとともに、どちらも評価できる体制づくりを進めています。
これからもVPoEとして、エンジニアが作っているプロダクトにこだわり、チームで率直に議論しながら挑戦/成長できる文化を作り。良いプロダクトを生み出して行きたいと思っています。
そして当社では、よりよいプロダクトを作っていくための仲間を募集しています。ここまでお読みになって、イタンジに興味を持ってくださったエンジニアの方、気軽に一度お話ししませんか？ ぜひ下のリンクよりご応募をお待ちしています。
