はじめまして、情報審査グループの山崎です。
今回は私たち情報審査グループが「データ」を仲介役として、エンジニア部門とともに協働したことをお伝えできればと考えています。
本記事ではコミュニケーションについてを軸にお伝えしますが、一般的な見解では無く私の個人的な感覚だけな点もあるのでご容赦ください。
エンジニアの方々に、私たちのような非エンジニアとのより良いコミュニケーションについて少しでも参考になれば嬉しいです。
関連して、エンジニア視点からの取り組み事例として以下の記事も併せてご覧ください。
情報審査グループの役割
情報審査グループでは「圧倒的な「安心」を提供する。」というビジョンのもと、以下のような業務を行っています。
- ユーザーに向けて：掲載されている物件広告を正確に届ける
- 物件広告を掲載している不動産会社に向けて：正確な物件広告を掲載できるようチェックし問題があれば修正依頼をさせていただく
「募集が終了した物件広告を非掲載にする」という、いわゆる「おとり広告」対策に注力しており、2024年には第三者機関による調査では物件鮮度No.1を獲得しました。
取り組みの背景
LIFULL HOME’Sは「広告を掲載する”場”」を提供する不動産・住宅情報のポータルサイトであり、実際の物件を管理しているわけではないため募集中かどうかの情報を持ち合わせていません。
ユーザー等から「この物件は募集が終了している」という連絡を受けて、情報審査グループが電話で当該物件の管理会社に募集状況の確認をしていました。。
つまり、募集が終了した物件広告は、不動産会社が非掲載にする必要があります。
ですが毎日数百万もある物件に対して、人手のみでは対応できる件数が限られます。
そこで私たちは『データを活用して募集終了した物件を検知できれば、自動非掲載できるのでは！』とデータ活用に取り組むことになりました。
情報審査におけるデータ活用
とはいえ、当初は統一されたデータが無く、まずは物件毎に集計・分析できるデータ作りをゼロベースで始めました。 実際に物件を調査するメンバーと履歴の残し方から試行錯誤し、通報による調査や能動的な調査の結果等をデータ化することに成功した後、 より効率的に募集終了物件を非掲載にしようとエンジニアに協力をお願いする運びになりました。
以下、私たちがこれまでに実施してきた施策となります。
・【ホームズ】管理会社との情報連携によるおとり物件対策
LIFULLが直接不動産の管理会社と物件データを連携することにより、LIFULL HOME'S上の募集終了物件を速やかに非掲載にする仕組みです。
・【LIFULL HOME'S会員さま限定】メンテナンス見える化ツールの詳細 | LIFULL HOME’S Business 仲介・管理
特定の条件により募集終了物件を検知し、物件広告を掲載している不動産会社に確認を促すツールとなります。このメンテナンス見える化ツールを進化させ、募集終了物件をLIFULLが自動で非掲載にするシステムを開発しました。
・LIFULL HOME'S、自社開発AIによる「おとり物件」の検知・自動非掲載を開始 | 株式会社LIFULL(ライフル)
蓄積されている物件広告のデータや、独自に行っている調査結果のデータを自社開発したAIに学習させることで、募集終了物件を検知し自動で非掲載にするシステムを開発しました。
こちらも併せてご覧いただけますと幸いです。
不動産広告におけるDX化とLIFULL HOME’Sの取り組み
このように私たちは以下のような大量のデータを活用し、日々募集終了物件を検知できるようになりました。
- 過去のデータ
- 現時点のデータ
- LIFULLに無いデータは協力会社から入手
部門間連携での紆余曲折
募集終了した物件の検知・自動非掲載を開始するまで、部門間でのさまざまな違いに戸惑いながら歩み続けてきました。
認識のずれ
当初はこんな会話から始まりました。
■例１
開発メンバー：「SQLでデータ出しますね、クエリ教えてもらえますか？」
私たち：「（SQLとは何？）（クエリとは何？）」
■例２
私たち：「これって不具合ですか！？（大変だ！）」
開発メンバー：「●●で■■な事象で起きている不具合ですね・・・！」
私たち：「（意外と落ち着いている！）」
例１の会話は「言葉（専門用語）の違い」、例２の会話は「温度感の違い」になります。
例１のように、システムについての会話では誰もがわかりやすい表現が使われる場合もありますが、専門用語が使われる場合もあります。 システムの専門用語を別の言葉に置き換えたりすると、エンジニアがデータを扱う際に何のことか迷い、かえって工数がかかったり、誤ったデータ処理を行ったりすることも考えられます。 ただ私たちは開発に不慣れなメンバーであったため、当初は認識を合わせるのに苦労しました。
例２についてのポイントは”視点”でしょうか？
（私だけが感じているのかも知れませんが）大量のデータを中心に見ているエンジニアにとっては、私たちが思う以上にバグやエラーといったものに接していると思います。
逆に、私たちは『不具合なんてあり得ない！すぐ解決しないと！』と焦りがちで、エンジニアは『そう慌てないで』と見極める冷静さがあり、温度感の違いを感じることがありました。
タスク管理手法の違い
エンジニア部門に何かお願いする際、簡単な内容でもJIRA等のタスク管理ツールを使ってチケット（証跡）で管理できる形で依頼していますが、私たちは『都度文章書いて、ステータス変更して面倒だな、、、』と思うことも正直いうとありました。
私たちの部署では口頭等でパパっと頼んで、サッと対応して解決ということもあります。 全てをチケット管理することに当初は手間を感じていましたが、この一見面倒なチケット管理が、やってみるとチームで物事を進めるのにいいことが分かりました。
いつ誰が何をどのように等の情報が人によって様々だったり、ずれやすい個々の意図を一致させる意思疎通を、フォーマット化されたチケット（データ管理）で行うことで明確になり、誰がみても同じ認識になるメリットを再認識しました。 記録に残れば言った言わないも防げます。
■チケット管理するメリット
1. 情報の可視化
2. 工数管理がしやすい
3. 進捗確認がしやすい
4. 優先順位を付けやすい
5. 過去案件や類似案件を検索しやすい
6. 担当者が分かりやすい
等々
チーム内での共通言語化
あるエンジニアがチーム内の認識がずれないよう「言葉」について定義付けを行い表にまとめてくれたことがありました。 同様に、私たちもできる限りエンジニアと同じ視点でコミュニケーションできるよう、使う言葉や対応を揃えていくようにしました。
たとえば「賃料」や「面積」といったデータの列を指すとき、わたしたちは「項目」と呼んでいましたがエンジニア部門では
・BigQueryでテーブルのデータ構造を話す時には「カラム名」
・AIモデル開発においては「変数」や「特徴量」
のように文脈に応じて言葉を使い分けていました。
お互いに齟齬が起きないよう、部門間で会話するときは「カラム名」で統一することにしました。
他にも「登録日」という言葉だけですと「物件の登録日」なのか？「データの登録日」なのか？分かりにくくなることがありますが、カラム名では「○○date」や「△△date」という言葉で明確に区別されているため、そちらの言葉を使うことにしました。
役割分担の明確化の重要性
また、私たちも簡単なクエリを書いたり、Excelで集計や分析ができるようスキルアップをしてきました。 そこで私たちは、エンジニアの手間を少しでも少なくするため「そのクエリなら私たちでも大丈夫です」とか「この集計はこちらでやっておきます」としたところ、逆に認識のずれが起こることもありました。
エンジニアが『この人たちは基本的な部分は大丈夫そうだな』と捉えてしまい、私たちが対応できなかったり理解できない部分までも「この点は皆さんであれば大丈夫だと思いますが」と説明を省かれてしまうことがあったのです。 『明確に分担した方がスムーズだったかも』と振り返った次第です。
他職種とのコミュニケーションでの学び
前述のような出来事を経て、あらためて私たちは以下の点について意識するようになりました。
- 専門分野の任せられるところは任せ、ゼロベースで話す
- 正確に伝えるため、使う言葉等の認識を合わせる
- システムやツール等の仕様をできる限り理解する
私は当初、良かれと思ってシステム等について把握している知識をエンジニアに伝えようとしたところ、逆に話がややこしくなってしまうことがありました。
今では専門家に任せられるところは任せ、私自身はゴール（やりたいこと、期日）をしっかり伝えた上で協力していくことが重要と考えるようになりました。
使う言葉については、何を指すか明確になっているシステムの専門用語に揃えるなど、言葉の認識を合わせることにより物事がスムーズにいくことが多かったです。 自分たちが使ってきた言葉の表現を変えることは、慣れないうちは戸惑うこともありましたが、今や「クエリ」という言葉を使わない日は無くなりましたし、慣れればなんてことはありません。
私たちがシステム等の仕様を理解することについては、細かい点まではともかく、システムが「できること」、「できないこと」といったポイントだけは理解すべきと考えています。
私たちのような非エンジニアは『人ができることはシステムもきっとできるはず！』『人ができないからシステムに期待している！』などと勝手な考えを持ちがちではないでしょうか？
そのため私たちは、まずゴール（やりたいこと、期日）を曖昧にせず「しっかり伝え」、
専門外だから理解できないのではと考えるのではなく、お互いに認識が合うように「説明すること」が重要だと思います。
たとえばデータ抽出において「AのテーブルとBのテーブルから必要なデータ自体は結びつけることができます。ただしBのテーブルが膨大な量のため、時間と費用が大幅にかかってしまうんです。」といったエンジニアからの説明を聞いて、私は「技術的には可能だが、事実上できないこと」を理解した場面もありました。
その後チームで次善の策を考え解決させ、お互いできること（それが”説明力”だったり”聞く力”だったりすると思いますが）を丁寧に実行していくことができたと思います。
LIFULL HOME'S、自社開発AIによる「おとり物件」の検知・自動非掲載を開始では、外部ベンダーとして株式会社リーン・ニシカタ様にお力添えいただきました。
その際もコミュニケーションロスが起きた場面がありましたが、使っているテーブルやカラム名を双方が理解できるようリスト化したり、コミュニケーションがうまくいくよう臨機応変に工夫しました。
おかげでリスト化後のミーティングやトラブルが発生した時はスムーズに対応することができるようになりました。
終わりに
このようにチーム内で紆余曲折しながらプロジェクトを進め、前述のような施策を行えるようになりました。
こちらの理解力が至らない場面でも毎回「わかりにくく申し訳ありません」という言葉と共に根気よく説明してくれた方々は、神のように感じました！
「言葉の違い」や「温度感の違い」はそれこそ友人同士でも起き得るものだと思います。 大切なのは双方が歩み寄り、相手が何を伝えようとしているのか？を理解し合うことだと感じています！
最後に、LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。
