こんにちは！いい生活エンジニア採用・広報の黒江です🌰
11月になり冬の足音が聞こえてくる季節となりましたが、みなさまいかがお過ごしでしょうか？

今回はいい生活屈指の競プロerである、データプラットフォーム本部の中山さん、森恒さんのお二人にインタビューをしました！

当社エンジニアの実際の業務内容を中心に、「競技プログラミングと実際の業務はどのような関係があるのか？」というお話もしてもらいました👂

不動産×テクノロジーで「心地いいくらしが循環する、社会のしくみをつくる」

ーーー改めて、いい生活とはどのようなことをしている会社なのでしょうか？

中山：
いい生活は、不動産市場のIT化を推進する「不動産×テクノロジー」にフォーカスしたVertical SaaSを提供している企業です。
「テクノロジーと心で、たくさんのいい生活を」をミッションとして掲げ、「心地いいくらしが循環する、社会のしくみをつくる」というビジョンのもと、不動産市場におけるDXの推進に注力しています。

当社の説明をする前に、当社がターゲットとしている不動産会社の仕事について、実際に家を借りるときを例に簡単にご紹介します。
新しい家を借りたいときはSUUMOやホームズといったサイトで探すと思います。こうしたサイトに空き家の情報を整理して掲載しているのは不動産会社です。
サイトを見て借りたい家を見つけたら、不動産会社に問い合わせ、内見（下見）に行きます。そして、気に入ったら賃貸借契約を締結します。

この賃貸借契約は法律上の手続きが決まっていて、やるべきフローが定型化されています。不動産業界にはその他にも家の売買契約、家賃が毎月正しい金額で振り込まれているかを確認する管理業務など定型的で面倒な作業が多いです。

一方、一般消費者の立場にたつと、不動産取引は一生に数回しか行わない、つまり妥当性がわかりづらい業界です。

まとめると、不動産業界は定型的で面倒な作業で構成されており、一般消費者からすると情報の非対称性が強い市場になっています。
このような特性があるとITシステムの介入メリットが大きくなります。
当社は、不動産会社に対して標準の業務を提供するシステムを開発・運用し、不動産会社の業務だけでなく消費者や市場すべてを良くしようとしています。

このように不動産市場をカバーするプロダクト群を作成している当社で、実際にどのように開発しているか説明します。

こちらの図では、いい生活のプロダクトではどのような技術を使っているかを簡単に列挙しています。
特にバックエンドは、APIは多くがPythonで書かれていて、もう一つ大きなプロダクトではRustも使っています。
インフラはAWSを採用しています。

続いて、いい生活のシステムにはどのような業務のデータが入り、流れてるかを簡単に説明します。
まずかなりインパクトがある数字として年間の入出金額が挙げられます。
先ほど家賃が振り込まれているかを確認する業務があると説明しましたが、僕らのシステムを通して年間5,600億円超の出入金があります。

また、僕らのシステムに登録されている物件の数は大体500万建物、1,000万戸です。
集合住宅マンションやアパートの集合住宅もたくさん登録されているので、建物の数と戸数で分けて書いていますが「1,000万戸＝10の7乗オーダー」は情報量として多いと感じてもらえると思います。

その他にも消費者と不動産会社がメッセージでやり取りする機能もあり、メッセージのやり取りが大体1日に6万件あります。
ストックされてる情報としては画像が大体5億枚、70TBぐらい保存されています。

上流から下流まで携われるエンジニアの開発環境

ーーーこのような規模感のサービスを提供している当社のエンジニアは、実際にどのようなお仕事をされているのでしょうか。

中山：
エンジニアは全体的にコードを書く仕事がかなり多いです。TypeScriptでWebアプリを作ったり、PythonでAPIを作ったり、C#でデスクトップアプリを作ったりしています。
その他の業務としては、市場調査やデータ分析などもありますが、やはりコードを書く時間が長いです。

僕の担当している当社のプロダクトの共通のデータ基盤・API基盤であるOne API Platformの業務としては、
・プラットフォーム機能の開発
・API利用者が欲しい機能の開発
・ バグの修正、リファクタリング
・コードを読む→理解→テスト作成
等をしています。
その他にもメンテナンス業務と呼ばれる様々なバージョンアップや、処理のチューニングを行っています。

処理のチューニングに関しては、競プロ勢の方により興味をお持ちいただけるような内容だと思いますので、もう少し具体的に説明します。
先ほど物件数が10の7乗オーダーのデータだと言いましたが、コアとなる情報は概ね100万〜10億のオーダーがあります。
不動産会社の業務ではざっくり言うと「検索→編集→保存する」という操作が多く発生します。
この検索に3秒かかると遅いと感じてしまうので、1秒以内に検索結果が表示されるようにSQLをチューニングします。
他にも物件の情報、家を借りたい人の情報、契約の情報、メッセージでのやり取りの情報、色々な情報が連携して全体の機能を構成しているので、その連携がうまく流れるようにするチューニングも存在します。

ーーーいい生活のエンジニアがどのようなことをしているかが理解できました！より具体的なアプリケーション開発業務の内容もお聞きしたいです。

森恒：
僕たちの業務の具体例として、いい生活賃貸/売買クラウド 営業支援というアプリの開発について紹介します。

営業支援は不動産会社の営業活動を支援するアプリです。
具体的には、不動産会社が行う多数のお客様の管理や、お客様とのやり取りをスムーズにします。
また、やり取り以外にもお客様からの問い合わせがSUUMOを経由して来たときに、自動で「お問い合わせありがとうございます」という内容のメールを送信したり、来店予約を管理したりする機能もあります。

使用している技術として、画面はTypeScriptとReact、データベースはMySQL、APIは他のプロダクトと共通のAPIをPythonで実装しています。
開発のルーチンとしては、まず不動産会社が解決したい課題を顧客ヒアリングなどから導き出します。そして、その課題を解決するための機能を考え、機能を実現するDB構造を考え、ロジックをPythonで実装します。

図は実際のDB構造から持ってきたER図です。上記の図では長方形一つ一つがデータベースのテーブルに対応します。
見やすさのために比較的小さいデータベースの図を持ってきましたが、それでもテーブル数が多いことが見て取れるかと思います。
テーブル間の矢印はテーブル関係を表しています。

新しく機能を実装したい場合は、その新しい機能を実現するテーブル構造を考えて、こちらのデータベースに追加してPythonでロジックを実装するという流れになります。

例えば、部屋を借りたい人の希望条件に合う物件を紹介する機能を作る場合を考えます。
希望条件には「こういうエリアの家賃何万円以下で徒歩何分以内の物件を借りたい」のように、エリア・家賃・駅からの距離などがあります。
まずは、希望条件を保存しておくテーブルを設計します。1つの希望条件に複数の希望エリアが登録できるように、メインの希望条件テーブルとは別に希望エリアのテーブルを子テーブルとして作る、といった設計を考えます。
テーブル構造が決まったら、データベースにテーブルを追加し、Pythonでロジックを実装します。

次に1日の業務の流れの例をご紹介します。
まず朝はSlackを確認したり、プロダクトやサーバーでエラーが発生していないかを監視したりしています。
それから、デイリースクラムという1日1回チームで行うミーティングで、その日のタスクをメンバーに共有します。

その後はコードリーディングをしたり、実装をしたり、テストをしたり、途中で昼休憩が入ったりします。
コードリーディングやテストも含めると実装の時間は多めです。

少し余談ですが、右側の1日のスケジュールを見ると、水曜日にプロダクトのアップデートであるリリースがあります。
なぜ水曜日にリリースが行われるかというと、不動産会社が水曜日が定休日であることが多く、システム利用が少ないときにリリースをしたいからです。
水曜日のリリースに合わせて、実装やリリースの準備を行っています。

競プロのスキルが開発速度と品質を飛躍的に向上させる

ーーー競技プログラミングのスキルは、実際の業務でどのように活かせるのでしょうか？

森恒：
業務と競プロのマッチングに関しては、まず、競プロができる人（＝AtCoderアルゴ緑以上程度を想定）は、「処理量に対する実行時間の感覚がある」「実装をバグを発生させずに素早くできる」という特徴があると考えます。
自社でプロダクトの企画・開発・販売・サポートをしている当社では、「不動産会社のニーズを満たす最小限のプロダクトを作成・提供し、ヒアリングなどを通して検証する」という流れを素早く繰り返すことが重要です。

これを素早く繰り返すには、バグを発生させずに実装を素早く行うことが必要です。
競プロができる人は、そういう実装をバグを発生させずに素早く行うことが得意だと思うので、全体の開発速度が圧倒的に向上し、かなり力になります。

また、不動産会社の抱えるデータは量が多くて複雑です。
テーブルの行数でいうと、10万から10億行（10^9。10^9というとAtCoder だと O(N)で間に合うかどうかくらい）あります。
また、テーブル数だと数百テーブル、項目数だと合計数万あり、愚直に戦うにはしんどいですが、正しく戦うと勝負になるくらいのオーダーのデータ量になってます。

次に競プロでの経験が業務に活かされた例をご紹介します。
CSV形式のテーブルを1システムに一括インポートするツールの話です。
そのツールは数百件のデータ登録では問題なく利用できていたのですが、10万件(10^5件)のデータを登録しようとしたら極端に遅くなる問題が発生しました。

プロファイリングをして遅い場所を特定したところ、CSVデータの重複チェックをするロジックが、二重ループで書かれてたことがその問題の原因でした。
例えば、上記図の右のテーブルの物件管理番号という番号が赤い1236で重複しているのですが、このような重複チェックするロジックが二重ループで書かれていました。

データの数が10^5 の場合、2重ループをすると10^10回程度の計算をすることになってしまうので、TLEしてしまいますね。
こちらをHashSetを使った実装に変更し、無事に解決しました。
要約すると、問題がありそうなコードを見つけて、「ひと目見てN^2のオーダーになってるじゃん」と突っ込める能力が発揮できたと思っています。

ーーー競プロの中でも、アルゴリズムとヒューリスティックのどちらの経験が実務に活きていますか？

中山：
その場で素早く実装するのにはアルゴリズムが活きると思います。
ですが、長期間にわたってどんどん改修を加えていく作業についてはヒューリスティックの方が向いているかなと個人的には思っています。

普段の業務の中でもさっとコードを書く作業は頻繁に発生します。
そういうときにABCのBやCぐらいの問題を特に苦もなく数分で書いて、解決することはたくさんあります。
ですので、そういうときにコードを書くハードルが低いことは大事かなと思います。

それはそれとして、プロダクトのコードはどんどん積み重ねていくものです。そういう積み重ねていく巨大なコードを書くという体験としてはヒューリスティックも、とてもいいんじゃないかなと思っています。

ーーー競プロのスキルは、業務でも活躍の場が非常に多いですね。

中山：
いい生活では競プロをやってる人との親和性が高いと僕も思っています。
そして会社としても、競プロ関連のコミュニティへの貢献活動を行っています。
例えばイベントスポンサーとして代表的なところでは、ICPCや日本情報オリンピック、SupercomputingContest、ISUCON、CodeQUEENなどに協賛させていただいています。

また、社員自身も競プロなどのプログラミングイベントには積極的に参加しています。
例えばICFPプログラミングコンテストでは、chirijakoというチームで毎年参加しています。
他にも、当社も協賛しているISUCONに社内でチームを作って参加したり、個人でAtCoderコンテストに参加するエンジニアも多くいます。

ここまで読んでいただき、ありがとうございました。
次のインタビュー記事もお楽しみに！

この記事を読んで私たちいい生活にご興味を持っていただいた方は、ぜひ下記から気軽にご応募ください！

また、これからもいい生活のエンジニアのことを発信していきますので、いい生活公式noteの「いいnote」のフォローもお願いいたします！

それでは今回はこちらで失礼します！