私は前職はLINEヤフーに研究員として従事しており、2024年3月にイタンジへ入社しました。入社後は、新設されたチームで、イタンジのサービスのフロントエンド開発に使用されるデザインシステム「ITANDI BB UI」の開発を担当しており、イタンジが提供する複数のプロダクトに横断的に関わっています。今回は、私の仕事内容や、研究員からなぜイタンジに入社したのかなどについてお話しします。

研究員時代、作成したシステムがSNSでバズった

前職では研究所に所属し、ユーザインターフェース（UI）の研究を行っていました。学生時代からプログラミングが好きだったので、インターンやアルバイトでエンジニアとして働いたり、GitHubでプログラムを公開したりしていました。大学院を修了するときにエンジニアになるか研究者になるかで悩みましたが、長い目でキャリアを考えた時に研究業績を積むことが最優先だと考え、ファーストキャリアに研究職を選びました。仕事内容は、作成した実験システムを実験参加者に使っていただき、データを集め、それを分析して、論文にすることでした。業務時間の多くは研究に関する論文を読んだり、執筆したりする時間に費やしていました。

あるとき、論文で書いた内容をもとに社内システムを作る機会がありました。Webページを分析できるシステムで、エンジニアやデザイナーだけでなく企画職など、様々な職種の方から好評いただきました。分析できるページは社内ドメインのみに限定していましたが、「外部のWebページも分析できるようにしてほしい」という声が多く、公開すると社外からも好評で、当時SNSでちょっとバズりました。研究者以外の人に貢献できるという機会があまりなかったので純粋に嬉しく、久しぶりにしっかりプログラミングをできてとても楽しかったです。そして、「自分の技術力を発揮して、誰かに貢献したい」と思うようになり、転職を考え始めました。

カジュアル面談で伝えられたことが他社とは一味違った

私はアイドル、アニメ、ゲームが好きだったため、転職活動時は転職エージェントに、エンジニアとしてエンタメ業界に関われる企業を希望として伝えていました。そのため、当初はtoCの企業を紹介していただくことが多かったです。
転職活動を続ける中、「研究について聞きたいと言っている人がいる」と紹介され、カジュアル面談を受けて出会ったのがイタンジCTOの大原さんでした。カジュアル面談では、最近立ち上げた「ITANDI BB UI」のチームでフロントエンドエンジニアを探しているといった話を聞きました。他社のカジュアル面談では、「どういうことがやりたいか」「どういうことができるか」といった希望を聞く質問が多かったのですが、イタンジは、「こういうチームを作るから、そこでこういうことをしてほしい」と具体的な期待役割を伝えてくれたのが新鮮でした。提示された業務内容は、自分の研究やフロントエンドの技術を活かせるものでしたし、自分のスキルを求めてもらえるところで働きたいと思ったため、選考に進むことにしました。

正直、業務内容に興味はありつつ、不動産業界にピンときてはいなかったのですが、最終面接でCEOの永嶋さんから「不動産業界は住まいを決めるという、人生の中でとても大事なことの1つに関わっているのに、面倒な手続きが多いせいで業界で働く人たちはやりがいを感じづらくなっている。それをテクノロジーで解決したい」という思いを聞きました。私の転職先への軸にも「人の幸せに関わりたい」という気持ちがあったため、衣食住のうちの1つに関われることに魅力を感じ、イタンジに入社することを決めました。

UIを浸透させ、開発をより効率的に

Webアプリケーションの画面は、ヘッダーやボタンなどのコンポーネント（※部品、要素などを意味する単語）を組み合わせることで作られます。普段の「ITANDI BB UI」チームは、デザイナーやPdMから既存のコンポーネントの機能追加・修正や新しいコンポーネントの要望をいただき、その開発をしています。リアルタイムな物件情報が見れる業者間サイト「ITANDI BB」を始め、複数プロダクトのユーザインターフェース（UI）に存在する多くのコンポーネントを共通の見た目にすることで、初めて使うプロダクトでも「なんとなく操作がわかる」というユーザ体験を提供できると考えています。

現在、だんだんとコンポーネントは揃ってきており、プロダクトの画面を「ITANDI BB UI」のみでほぼ作れる状況になっています。そのため、今後は新規コンポーネントの開発よりも、今あるコンポーネントをさらにフロントエンド開発に活用してもらいたいと思っています。

そのためには、プロダクトを開発するPdMやエンジニアが、コンポーネントの存在を把握していなければ意味がありません。コンポーネントの使い方が分からなかったり、作成したコンポーネントの存在を知らずに二重にコンポーネントを作成してしまったりしないよう、どう存在を提示したら使うべきコンポーネントが分かりやすいか、仕組みを考えています。また、機能追加や修正によって意図しないバグが生まれないようにテストを作成し、そのバグをリリース前に検知できるよう品質担保をしています。

こうしたいくつかの施策をプロダクト開発のチームに浸透させ、サービス全体のフロントエンド開発体験をより良くしたいです。それによって私自身とチームの存在感を強め、「フロントエンドについて頼るならこのチーム」「ここに聞けばフロントエンドの問題が解決する」という組織を作りたいです。