こんにちは、グループデータ本部データサイエンスグループの清田です。 昨年のDEIM 2023 に引き続き、「 第16回データ工学と情報マネジメントに関するフォーラム（通称DEIM 2024） 」に参加・登壇してきましたので、その様子を報告いたします。 ※昨年の様子はこちら www.lifull.blog 昨年に引き続いての「直列ハイブリッド」開催 コロナ禍の影響が徐々に薄れ、対面形式でのイベントが再開される中、DEIMでは昨年に引き続き「直列ハイブリッド」というユニークな形式で開催されました。 2月28日から3月1日までの3日間はオンライン開催、土日をはさんで3月4日・5日は兵庫県姫路市の会場での現地開催でした。 オンライン開催用に配布されたロゴ入りバーチャル背景。LIFULLも前回に引き続き協賛しております 現地会場のアクリエひめじ（兵庫県姫路市） ハイブリッド開催のイベントは今や一般的になりましたが、どうしてもオンライン参加者と現地参加者の間のコミュニケーションが難しくなってしまうという課題があります。 オンライン開催中には多くの発表を集中して聴講し、現地開催中には多くの参加者との交流をもつことができる開催形態は、参加者としても利点が多いと思います。 開催にご尽力いただいた関係者の方々に、心からの敬意を表したいと思います。 スポンサー企業各社の常設展示会場。今回も多くの方々と交流をもたせていただきました 大規模言語モデル(LLM)のインパクト 2022年11月にリリースされたChatGPT、およびその技術的基盤となる大規模言語モデル（LLM）は、AI、情報処理に関する研究にも大きな影響を与えています。 とくに自然言語処理分野でなされてきた研究課題のうちかなりの部分は、LLMによって解けるようになったこともあり、研究のテーマ設定自体が大きく変わりつつあります。 DEIM 2024でも、40件以上のLLMに関する研究発表が行われており、トレンドの大きな変化を実感しました。 また、3月4日に開催された チュートリアルセッション でも、LLMに関する以下のチュートリアルが企画され、いずれも多くの参加者を集めていました。 クラウド環境で駆動する生成系AIの最先端 LLMと音声理解・生成の最新動向 大規模言語モデルに基づく検索モデル LLMの嘘：ハルシネーション解説 共有データ資源のこれから LLMなどの生成AI技術が飛躍的に発展する中、生成AIが必要とするデータ資源の存在が、あらためて注目されています。 LIFULLでも、 国立情報学研究所（NII） のご協力のもと、 LIFULL HOME’Sデータセット を2015年11月より学術研究用途に提供しています。 現時点で 170件を超える研究成果 が発表されていて、 LIFULL HOME’S 3D間取り などの新たなサービスの実現にもつながっています。 www.lifull.blog AIや情報処理に関する研究は、多くの研究者がアクセスできる共有データ資源の存在に支えられて発展してきました。 Webに蓄積された大量のデータ資源が、自然言語処理や画像処理などの研究の発展を促すとともに、Webを活用したビジネスの発展の基盤となり、さらにWeb上のデータ蓄積を加速するという「好循環」が、AIなどの発展を支えてきました。 一方で、生成AI技術の隆盛は、「データを独占的に保有すること自体が巨大な利益につながる」という状況も生み出しています。 こうした状況で、「好循環」が滞ってしまうのではという懸念も出てきています。 2023年には、Twitter社（現X社）が、これまで学術研究者向けに認めてきたAPIの利用を停止するという出来事もありました。 techcrunch.com こうした流れの中、今後のAI研究を支えるためのデータ資源のあり方を、改めて振り返ることが必要ではないかと考えています。 DEIM 2024では、LIFULLからの技術報告として、「不動産情報サービスの研究開発における研究データ資源」についてのプレゼンテーションを行いました。 この発表では、LIFULLにおけるデータセットの共有と活用の取り組みを紹介するとともに、Webが出現するより前の1990年代からの共有データ資源をとりまく環境の変化を俯瞰した上で、今後の共有データ資源の健全な発展を図るための方策についての考察を行いました。 もしよろしければ、ぜひ発表資料をご覧ください。 speakerdeck.com LIFULLでは、 Webインテリジェンスとインタラクション（WI2）研究会 や、2024年5月に浜松で開催される 人工知能学会全国大会（JSAI 2024） など、複数の学会イベントをこれからもサポートしてまいります。 また、LIFULLでは、共に成長しながら働く仲間を募っております。 現在、以下の職種を募集しております。LIFULL HOME’Sデータセットなど、豊富な研究開発資源を活かしながら、多様な社会課題の解決に向けた研究開発やプロダクト創出に取り組んでみませんか？ hrmos.co hrmos.co ご興味をお持ちの方は、ぜひお問い合わせください！

こんにちは。フロントエンドエンジニアの根本です。 LIFULL HOME'Sのプロダクト開発と、スポーツ関連の新規事業開発に携わっています。 2024年5月18日に開催された「RESEARCH Conference」というリサーチをテーマにしたイベントに登壇いたしました。この記事ではそのイベントや登壇内容についてご紹介します。 RESEARCH Conferenceとは？ researchconf.jp RESEARCH Conferenceは、リサーチをテーマとした日本発のカンファレンスです。 より良いサービスづくりの土壌を育むために、デザインリサーチやUXリサーチの実践知を共有し、リサーチの価値や可能性を広く伝えることを目的としています。 行政、大企業、スタートアップなど立場の違いを超えて活発な議論を重ね、共に学び合うリサーチコミュニティを育てることを目指します。（上記ページより引用） 上記のように、このイベントでは「リサーチ」というテーマに対して組織形成やプロジェクトでの取り組み事例など様々な切り口のセッションが開かれ議論できる場になっています。 LIFULLでは毎年スポンサーとして協賛しており、今回はリサーチを活用した開発プロセスについてエンジニアという立場からお話をする機会をいただきました。 発表内容 今回のカンファレンステーマは「ROOTS」。私たちは「プロダクトに命を吹き込む：UXリサーチとエンジニアリングの共創」と題し、UXリサーチャーと共に登壇しました。特に、本記事では開発プロセスに焦点をあてた内容を紹介します。 チーム構成 今回のプロジェクト事例では、プロダクトオーナー、UXリサーチャー、UXエンジニア、デザイナーの4名で先行リサーチを行い、施策検討段階で開発チームと合流し開発プロセスを進めています。本チームでの開発プロセスについて下記で紹介します。 職種分業体制 私たちのチームで中小規模の開発に取り入れている職種分業体制では、主に企画とデザイナーがバディとなり、リサーチ結果を仕様に落とし込んだ仕様書という形でエンジニアにバトンタッチする進め方を採用しています。 その結果、開発規模が大きくなった時、顧客理解や仕様理解不足が発生し開発停滞や後戻りが発生することも少なくありません。 職種連携体制 新規開発など大きめのPJを進めていく場合、職種分業体制ではなく職種連携体制を採用し開発を進めています。 この体制ではリサーチに携わっている、企画・デザイナー・UXエンジニアの３職種が連携し仕様の落とし込みを実施しています。 UXエンジニアが仕様策定に関わることで、後続の開発フェーズではエンジニアと仕様意図をしっかりと共有しながら技術的な設計のすり合わせが可能になります。 UXエンジニアの介在価値 UXエンジニアが担う仕様作成では、 職種横断チームでのUXエンジニアとしての働き方 - LIFULL Creators Blog でも過去に紹介しているようにテクニカルプロトタイプを用いて仕様のすり合わせを実施します。 その結果、リサーチ内容をプロダクトに昇華していく工程がよりシームレスになり好循環な開発プロセスを実現できるようになっています。 このようにプロジェクト規模や組織体制に合わせて柔軟な開発プロセスを踏み、その中でエンジニアも当事者意識を持ってリサーチに関与していくことが重要であると考えます。 発表資料はこちらからご覧ください。 www.docswell.com イベントに参加した感想 今回登壇するにあたり、自分にとってのリサーチの「ROOTS」とは何かを思い返しました。 元々、大学の研究では認知心理学、認知科学分野を専攻し人の認知的な特性を理解した上で、情報システムはどうあるべきかという点を考えていました。 それらを知るためのリサーチであり、エンジニアとしてプロダクト開発をしている今もその「ROOTS」を持ってリサーチに関わっているのだと振り返ることができました。 今回登壇されていた様々な企業・団体の方のリサーチへの取り組みは興味深いものばかりで、とても勉強になり刺激にもなりました。 また、AI活用などによりリサーチ作業自体の効率化をエンジニアとしてサポートできるという発見もあり今後は様々な形でリサーチを推進していこうと思う機会になりました。 最後に LIFULLではリサーチを活用しながらプロダクト開発を一緒に推進してくれる仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の興津です。私は普段アプリケーションエンジニアとしてLIFULL HOME'Sのサイト改善業務しています。そのかたわらで、社内の制度を利用して、LIFULLのサービスの一つであるACTION FOR ALLの企画もしています。 今回はそんなLIFULLの独自の制度である「キャリフル」と、その経験を通して私が得られたものについて紹介します。 LIFULLの独自制度「キャリフル」について まず初めに、エンジニアの自分が企画に挑戦することを可能にした、LIFULLの独自制度である「キャリフル」を紹介します。 キャリフルとは、LIFULLの社内兼業制度で、業務時間の1割程度を本業とは別の業務ができる制度です。 私のように、普段とは別の職種に挑戦することもできるほか、たとえば同じエンジニアでもLIFULLの別のサービスの開発に携わることも可能です。 キャリフルについては公式Noteでも紹介しているため、もっと詳しく知りたい方はこちらをご参照ください。 corp.LIFULL.com 私がキャリフルに応募した理由 私がACTION FOR ALLの企画職に応募した理由は2つあります。スキルアップとビジョンマッチです。 企画職を体験することでスキルアップをしたい 自分のキャリアビジョンを考えた時、これからはエンジニアの業務だけではなく、一緒にサイト改善を担う企画やデザイナーの業務にも気を配れる存在になりたいと考えました。 特に前職が顧客の社内Webサービスの構築PJに参画することが多かったこともあり、企画職が何をする仕事で、何をエンジニアに期待していることがまったくわからない状態でした。 企画のことを知るためには、実際に企画を経験してみるのが一番よいと考え、企画のキャリフル募集を探し始めました。 ACTION FOR ALLのビジョンに共感し、事業に貢献したい 運が良かったことに、探し始めた時とほぼ同じタイミングで、企画の未経験でも応募可能な募集が始まりました。それがACTION FOR ALLの企画です。 ACTION FOR ALLは国籍や人種、性別、背負うハンディキャップにかかわらず、誰もが自分らしく「したい暮らし」に出会える世界の実現を目指す事業です。 さまざまなバックグラウンドを持つ人が安心して相談できる不動産会社を探すことができるFRIENDLY DOORなどのサービスがあります。 actionforall.homes.co.jp 私がLIFULLに入社を決めたのも、ACTION FOR ALLをはじめとした、社会課題の解決に事業として本気で取り組んでいるところに共感したからでした。 特に、私は長年プライベートでも社会的弱者とされる方々の支援活動を行っていたこともあり、LIFULLの数ある事業の中でもACTION FOR ALLは最も好きな事業です。 いつかACTION FOR ALLに貢献できる仕事ができればと思っていた中で、キャリフルの募集はまたとないチャンスでした。 こうして、企画のキャリフルに応募したいと思った時と同じくして、携わってみたいと考えていた事業の企画が募集をしていたため、応募しました。 挑戦して知った、企画職のたいへんさ 施策案を作ることの難しさ LIFULLにおけるサイト改善の企画職の仕事のメインは、現状のサイトの課題を見つけ、その解決策を立案することです。 言葉にすると簡単ですが、やってみると想像以上に難しいことを痛感しました。 まず、先輩方がアップデートを続けてきたサイトに対して、課題を見つけ出すことすら私にはできませんでした。見慣れて愛着が出てしまっていることもあり、「もう今のサイトが完璧なのでは」と言う気持ちになってしまいました。 先輩方の助けも借りながらなんとか課題を見つけることができても、今度はその解決策を見つけることができませんでした。たとえば、FRIENDLY DOORの会社情報が長すぎるのでは、という課題が出た時に、皆で情報を整理してスッキリできないか案を出し合おうということになりました。しかし、私は考えても「全部の情報が必要！」という思考になってしまい、よい案を思い付くことができませんでした。その時に先輩方からは「ほかの同じようなサイトもよく見て、参考にできるようなものがないと見てみるとよい」というアドバイスをいただきました。企画の人たちは自分たちのサービスだけでなく、競合他社をはじめとした世の中のさまざまなサービスを見ているんだと気付かされた一件です。 さらに、施策を立ち上げた後に行う仕様作成でも、簡単な施策であっても実際にドキュメントに起こしてみると、「こんな細かいところまで考えなければいけないのか」という気付きの連続でした。たとえば、私はFRIENDLY DOORの駅・路線での絞り込み機能を追加する施策の仕様作成を担当しました。この施策も、「複数の路線が通る駅で絞り込まれた時のURL」や「複数の駅が選択された時のH1の文章」など、検討しなければいけないことがたくさんありました。一つ一つの検討事項の結果がサービスの質や売り上げにつながっていくと思うと、いわゆる「決めの問題」となる些細な決定でも責任を感じました。 開発を託すことの不安 無事に仕様が完成し、エンジニアに託した後も、企画はけっして気が抜ける状態ではないということを知ることができました。 エンジニアとして自分が開発者として参画しているときは、現在どんな進捗で、どんな課題があって、計画通りにリリースができそうか否かが簡単にわかりました。それに、何かトラブルが発生したとしても「いざとなれば自分が必死になって頑張る」という最終手段があるという安心感もあります。 企画の場合は、開発中は大きなトラブルなく進むことを祈るしかできません。トラブルを防ぐための打ち手として、事前に仕様を十分に検証するということは可能ですが、開発が始まった後にできることはあまり多くなく、非常にもどかしい気持ちになりました。進捗が遅れた時のリリース日延期の判断や、リソース調整など、企画としてできることにおいても、その判断を早くするためには進捗の把握を積極的に行わなければならないということに気付きました。 最も、私の本業はエンジニアであるため、最終的には自分も開発に入ってなんとかするという判断ができますし、実際にそうした施策もありました。しかし、本業がエンジニアでない企画はそうもいかないので、さらに不安が大きいであろうことは想像にかたくありません。 施策が実を結ばなかったことの悔しさ 企画の先輩方にアドバイスをもらいながら仕様を作り、エンジニアに多くの工数を使って改修してもらった施策が、必ずしもうまくいくとは限りません。 中にはリリース後にビジネス指標が悪くなってしまい、緊急で改修前の状態に戻す判断が必要となった施策もありました。 たくさんの人の協力を得ながら行った改修の結果が悪かったことは、本当に悔しく、皆に対して申し訳ない気持ちになりました。 企画の人たちはこんなプレッシャーとともに施策を打ち出しているのかと思うと、頭が下がる思いです。 エンジニアの自分だからこそできること 企画のたいへんさがよくわかった一方で、エンジニアだからこそ企画業務で活かせることもいくつかありました。 技術観点から策定する仕様 仕様を決めるときに、自分がエンジニアであるため、既存のソースコードやDB構成などを自分で確認できます。 そのため、仕様を決める時に実装のしやすさや性能などを考慮した仕様を考えることができました。 もちろん、そこをエンジニアに相談して一緒に仕様を決めていくことも可能であり、普段の業務でもこうして進めていくことも多いです。 それでもエンジニアのリソースを別のところに使えることは効率的でした。 SQLを用いた分析 先日、FRIENDLY DOORでは住宅弱者フレンドリーな物件一覧のページをリリースしました。 LIFULL.com この一覧ページを作った後に、この一覧に掲載される物件の傾向を分析することになりました。「一覧に掲載される物件はどんな増減をしているのか？」「都道府県ごとに差異はあるのか？」「フレンドリーな物件を多く扱う不動産会社はとは？」ということを知れば、次の打ち手の材料にできると考えたためです。 上記の疑問点は、SQLで件数を調べることで知ることが可能です。 こちらもエンジニアに依頼して調べることも可能ですが、ちょっと気になった件数も自分で簡単に調べられるのはエンジニアならではの強みだと思います。 普段の業務での知見を活かした改善 ACTION FOR ALLではLIFULL HOME'Sとは異なる独自のドメインやリポジトリを有していますが、LIFULLでは技術的に管轄している部署が存在していない状態でした。 開発は施策ごとにベトナムの開発拠点であるLIFULL Tech Vietnam Co.,Ltd.(以下LFTV)に依頼しているため、サービスのリリース当初から保守運用があまり積極的に行われていない現状がありました。 そこで、普段の業務で行っていることを活かし、ライブラリのアップデートの推進やテスト用の環境の整備などのエンジニアとしてできることも積極的に行っています。 キャリフルの経験を、普段の業務に活かしていく 普段の業務の経験をキャリフルで活かすことも可能ですが、逆にキャリフルで得た経験が普段の業務に活きていることも感じています。 企画に寄り添えるエンジニアに 当初の目論み通り、企画が行う業務や企画ならではの困難さを体験したことで、企画に寄り添えるエンジニアとして成長できていると感じています。 たとえば、日々の進捗確認では一見エンジニアどうしで把握しておけばよいかもしれないことも、可能な限りエンジニア以外にもわかりやすい言葉を使って説明するようにしています。開発の進捗が端的にしかわからないことは不安であることを知ったからです。 また、施策の結果が数字としてはうまくいかなかった時こそよかったところを見つけて前向きな言葉を発することを心がけるようになりました。結果が振るわなかった時の企画の悔しさや決断の重圧を身をもって知っているからです。 次の段階としては、より確度の高い施策を作れるように、エンジニアの立場からバックアップできることを考えていきたいと思っています。 エンジニア組織のいないサービスに参画したことで、技術的に強くなった ACTION FOR ALLには専属のエンジニアが存在しないため、障害対応が発生した時は自分しか調査をできる人間がいませんでした。（2024年1月現在は、開発を依頼しているLFTVのメンバーも障害調査ができる権限を付与し、一緒に調査ができるよう整備しています） 普段は同じチームの先輩方に頼れる技術的な判断も、自分に委ねられることになります。 この状況に身を置くことで、技術的にも成長できました。もちろんこの成長は、普段のエンジニア業務の中でも糧になっています。 終わりに このように、LIFULLでは自分の所属以外の業務や職種にも積極的にチャレンジできる環境が整っています。 さまざまなことに挑戦して成長したいと考えているエンジニアの方は、ぜひ以下のページも見ていただけますと幸いです。 hrmos.co hrmos.co

プロダクトエンジニアリング部の二宮です。 次のプレスリリースにある通り、LIFULLでは生成AIを使って20,000時間以上の業務時間削減をしたという大きな成果を上げることができました。数字の根拠が粗い試算ではあるものの、実は社内では1年間で20,000時間の削減を目標としていたため、その半分の期間で目標達成できて関係者が色めき立っています。 lifull.com 私は keelaiという社内用AIのプロジェクト に開発者の一人として関わっていて、生成AIツールの活用を推進する有志のプロジェクト（タスクフォースチーム）にもメンバーの一人として携わっています。そのため、エンジニアの中でもある程度全体が分かる立場として、生成AI技術の社内普及のための取り組みについて共有します。 私は各部署の導入の相談やプロンプトの技術サポートを担当することが多く、社内発表も行っているため、結果的に生成AI関連のチームの中でもいろいろな人から声をかけられたりして情報が集まる立場になりました。その技術と普及活動の両面で話をします。 LIFULLの生成AI活用の現状 現在、keelaiは月間でおよそ580人に利用してもらっています。去年の11月に『 社内向けAI botの運用で学んだ技術コミュニケーションのコツ 』という記事を書いた時点では次のような状態だったので、そこからも大きく伸びました。 keelaiはSlack上で動くAIチャットボットを含んだ "汎用AI(仮)" 技術スタックで、LIFULLグループのSlackユーザーおよそ1000人程度の中で月間200人以上に利用して頂いています。これはけっこうな成功例と言っていいんじゃないでしょうか？ 社内での利用実態を見ても、keelaiはすでに社内で当たり前に使われているツールになったと思います。 内製AI（keelai）の開発・活用方針 ほとんどの内容は、KEELチームの相原さんが以下の記事で紹介している通りです。「なるべく作らない」方針で、Slackで利用できるチャットボットを主軸に社内の汎用的に使える機能を提供するようにして、個々の部署の問題は各部署でプロンプトエンジニアリングやSlackワークフローの設定ができるようイネーブリングしていく作戦で少人数での開発を実現しています。実は私自身もKEELチームに所属しているわけではなく、インナーソースのコミッターとして活動しています。 www.lifull.blog 汎用AIを目指す上でもあらゆる業務上の課題を解決する機能を私達だけで実装することは現実的ではないため、「なるべく作らない」ことでコストとバランスが取れたスケーラビリティだけを素早く示してインナーソースによって成長していくことを目指しました。 この記事の時点からさらに発展した点として、 Slackワークフロー と組み合わせて、ノーコードで生成AIを使った自動化機能を実現できるようになったことが挙げられます。例えば、『 海外の開発拠点メンバーと、受託先ではなくチームメンバーとして協働するための取り組み 』では、海外チームとのやり取りを生成AIで翻訳する使い方が紹介されています。 他にも、Slackワークフローのフォーム投稿を利用して、例えば総務では社内のFAQのRAG（社内情報検索）を使って一次回答をする機能を用意しました。私も便利に利用しています🙇 少し技術的な余談ですが、keelaiの投稿完了後に :keel_complete: という絵文字を付与していて、更に続けて別のSlackワークフローを起動できるように工夫しています。例えばプログラムでkeelaiに多数の問い合わせを投げ、その結果をGoogle Sheetsに収集するなどの使い方もできます。これを利用して、先日 クリエイターの日委員 によってSlackワークフローとkeelaiを使った自動化のハッカソンが実施されました。 生成AIを活用した会社の成功事例として、よく内製生成AIツールのログを徹底的に残して良い事例や注力ポイントを見つけている話を聞きますが、keelaiではプロンプトのログをあえて残していません。その代わりに公開チャンネルでの利用内容を定期的に見ているのと、Slackメッセージ内に誤回答の報告ボタンを用意することで代替しています。これはプライベートチャンネルやダイレクトチャットで、部門外秘の内容まで気兼ねなく利用してもらえるようにするためです。 普及のためにやったこと せっかく便利な機能を用意しても、それに気づいて使ってもらえなければ意味がありません。生成AIの力を普及させるために、各社でいろいろ苦心されていると思います。我々もその点は同様で、あの手この手を考えていろいろなメディアを通してコミュニケーションしています。 社内ゼミ Generative AI Award (GAIA) 相談窓口の準備 ドキュメントの拡充 Slackの広報 各部門の推進リーダーがいること これらの発表の後に「さっき紹介した事例に似たことを自分の部署でもやってみたいんだけど…」と声がかかることが多く、大きな活用促進のきっかけになることも多いです。 また、keelai自体がそうなのですが、これらは戦略的に考えられたものだけでなく、社員の自主的な動きが事後的に公式化したものも多いです。そういうボトムアップな動きがちゃんと合流できてるのもすごい点かもしれません。 社内ゼミ こちらの『 LIFULLの挑戦の機会と制度 』という記事にある通り、LIFULLには社内大学の制度があります。この制度を使って生成AIのプロンプトエンジニアリングのゼミを行いました。 社員が学びたい事をその分野に特化した社員が講師となって教えあう、大学のゼミのような勉強会が実施されています。 このゼミは実は公式の取り組みではなくて、 プロダクトプランニング部の部長の大久保慎さん が自主的に行ったものです。つまり正確にはLIFULLの生成AIチームの公式の取り組みではありません（もちろん内容のチェックや広報などで協力しました）。 このゼミの内容は、「初心者がプロンプトの基礎を学んですぐに中級者になることを目指す」ようなものでした。これは200人を越える社内ゼミ過去最高の参加人数を記録し、事後の内容の評判も良いものでした。実際にこのゼミをきっかけに利用者は大きく伸び、大きな自動化案件のきっかけにもなりました。 Generative AI Award (GAIA) 『 20,000時間以上の業務時間を創出 』にも記載している通り、LIFULLではGenerative AI Award (GAIA)という表彰を行っています。ただし、今のところはインセンティブ提供というより成功事例の普及が主目標で、特に賞品などを用意しているわけではありません。 また、上記診断によって活用度が高い従業員を表彰する「Generative AI Award(通称GAIA)」を月一回実施することで、優良事例の水平展開と共にモチベーション向上にも繋げています。 LIFULLにはThink Togetherという、役員と直接質問や議論できる場があります。そこで会長の井上さんにkeelaiや生成AIの話をしていて「本当はもっと盛り上がる方法があるんじゃないか」と言ったところ、「じゃあ全社総会で時間空けとくから何か発表してみてよ、 長沢翼（CTO） と一緒に！」と言われて突如始まりました。当時私はkeelaiの開発に関わっていたものの、生成AIを推進するタスクフォースに所属しているわけではなかった（後に合流した）ので、事情を知らない人からすると急に始まった謎コンテンツだったと思います😂 そこでアクセシビリティのチーム（『 フロントエンドエンジニアが組織横断のアクセシビリティ専門部署を立ち上げた 』）が既にエンジニア組織内でアクセシビリティに対して勝手に表彰する取り組みを行っていたので、長沢さんのアイデアでそれを生成AIの文脈で真似しました。具体的には生成AIを大きく活用できた事例を見つけ、代表者にインタビューした内容とともに発表しています。 内容は次のようなことを心がけています。 聞いてて面白い内容にする：特にオンラインでの発表になることが多いので、客観的な評価基準を設けるというよりは、本当に自分たち自身が面白いと思う事例を取り上げて、やや大げさなレベルで「ここがすごい」と言って分かりやすくすることを意識しています。 平均値ではなく例外に注目する：例えば「平均的に活用度が高いエンジニアチーム」ではなく「同じ職種の中でも例外的に活用度が高い営業チーム」にインタビューしました。そして普及のために何をしたのか、周囲のメンバーの反応で助かったことはあるのか等を聞いていきました。 「自分だったらこうするだろう」という意識を持って話を聞いて意外な点を見つける：例えば普及率の高い営業チームの人に話を聞く際に、「自分でもSlackや総会発表で積極的にアナウンスすることは思いつくし、他のチームでもそれはやっている。じゃあむしろ共有内容や周りの雰囲気に違いがあるんじゃないか」などと仮説を立ててインタビューしました。その結果、「とにかく新しいものを気軽でおもしろ用途から試して身近に思ってもらう。周囲にもそういう面白さを受け入れる雰囲気がある」ということが分かりました。 これらの指針は、LIFULLで社内導入された 中尾さんのKPIマネジメント の考え方のツールの1つである TTPS（徹底的にパクって進化させる） や、UXリサーチの方々が勧めていた メタファシリテーション の考え方にも影響されている気がします。 こういう普及活用はどうしても「必要なのは分かるけど別に興味は湧かない。ひとまず最低限言われたことをするか」というような減点思考の捉えられ方をされてしまいがちです。そこで加点思考のコンテンツを用意するのは良い雰囲気を作るのに役立つことだったと思います。 相談窓口の準備 サポートとして、Slackに相談窓口を用意しています。各部署でオーナーシップを持ってもらって、複雑なプロンプトの改善やアイデアを相談できるようにしています。最近ではSlackの ハドルミーティング を使ったオフィスアワー方式の相談会も試しています。 ドキュメントの拡充 使い方を説明するドキュメントはしっかり準備しています。特にkeelai Showcaseというプロンプトや利用例を紹介するページがあります。 「誰でも」と言ってはいるものの、それほど関係者外からの投稿は多くなく、ほとんどkeelaiチームの関係者が投稿しています😅 誰かに書いてもらうというよりはむしろ、ここの事例の中から近いものを紹介して別のチームにアドバイスすることや、この内容を見て「似たことができるかも」と声をかけてもらうことに役立っています。他にもSlackワークフローの設定手順や利用方法を動画で説明したり、色々とやり方を試行錯誤しています。 最近は生成AIのタスクフォースチームとして、GAI WIKIという「LIFULL社員が生成AIで知りたいことが大体分かるリンク集」のようなページを用意しました。 Slackの広報 『 社内向けAI botの運用で学んだ技術コミュニケーションのコツ 』にも書いた内容です。「次の行動を喚起する」ことを意識し、大抵はサポートチャンネルへの誘導を目的にしています。 自分自身が受け手になったときのことを思い出しても、この手の広報はほとんど素通りされて、後で「え？こんな便利なツールが用意されてたの？教えてよ！」って思うことが多いはずです。それを防ぐためには、「興味の扉が開く」ようなタイミングを狙って投稿すると良いんじゃないかと感じています。つまり、新しい機能リリースや面白い事例がある度に共有する、オンラインの総会で関連する話題が挙がったときに参考になるドキュメントをコメントするなど、皆の興味が高まるタイミングにすかさずアピールすることを心がけています。 各部門の推進リーダーがいること プレスリリース にもある通り、各部門に推進リーダーを立ててもらっています。 その他にも職種や業務特性に則して各論での利用促進を図るために、部門毎の生成AI活用推進リーダーを31名擁立し、網羅的な利用促進に繋げることができています。 これは実際に生成AIツールを推進する意味でも役立っていて、例えば「GAIAで表彰するときにその人に詳しく話を聞く」とか「活用度診断があるときにその人を通じて広報する」などで連携していて、他の取り組みを支えるベース担っていると思います。また、何か部署内で困りごとがあるときに、その方から連絡が来ることが多いです。 ただ、普段の推進リーダーの活動を、各々の自主性だけにまかせきりになってしまっている部分が多い点は課題だと思っています。もし自分が任命されたとしたら、ひとまずSlackや総会で情報共有はするものの、それ以上のことをどうすればいいか困ってしまうはずです。ただその分、先ほどGAIAの項目でも触れた、営業チームに聞いたおもしろ画像や音楽での盛り上げ方は想定外でビックリしました😂 今後の展望 最後に今後の展望をまとめます。おおまかには、生成AI推進のタスクフォースチームとして引き続き利用開始できていない人やチームに更に普及させていくことような動きをしつつ、特にkeelaiのチームとしては、成功したチームの施策を更に進展させる次のような取り組みを行うつもりです。 keelai APIの提供 keelaiのAPIを準備して、開発組織の中でより便利な効率化を行おうとしています。 まずGitHub Actionsを使って「社内ドキュメントや仕様書をうまく検索してアドバイスする」ような自動レビューを提供しました。LIFULLでは『 コマンド1発でKubernetes上にProduction Readyな環境を手に入れる 』で紹介されているkeelctlというツールが広く使われているので、主要なリポジトリにすぐ導入できます。 他にもプロダクトのエラーログを参照し、エラー発生時に簡単な問題であればそのままプルリクエストを作るなどいろいろな構想があります。これはシステム基盤も含めて内製していることのメリットだと思います。 過去に関わったチームのフォローアップ keelaiの社内での普及率は順調に上がってきたため、ここから大幅に利用者数が増えることは無いと考えています。そこでむしろ、過去に相談したことのあるチームに、プロンプトはきちんと動作しているか、他に困っていることが無いかなどを聞いてより深化させるチャンスが無いか探ろうと思っています。 また、別のSlackワークスペースの子会社からもSlackコネクトされたチャンネルで利用できるようにしているのですが、利用実態がよく分からないまま放置してしまっているので、そこにも取り組む必要を感じています。 社内コミュニティを盛り上げる （これはやや個人的な目標ですが）LIFULLには 社内サークル制度 があり、生成AIについて広く情報共有するサークルが設立されました。もちろん私もメンバーとして参加しています。 今のところ、ランチしながら生成AIのツールや使い方を話すことが活動内容のほとんどですが、更に何かもう少し広く役に立つ勉強会などの企画をしたいと思います。また、サークルには推進リーダーの方も何名か参加しているので、各部署の面白い普及の進め方を吸い上げて展開することもできるかもしれません。ボトムアップの方向からの動きも更に盛り上げるつもりです。 GAIPの知見を広げる またLIFULLには ジェネレーティブAIプロダクト開発ユニット（通称GAIP） という生成AIを使ったプロダクト開発の専門組織（『 さっそく試してみた！国土交通省不動産情報ライブラリAPI x 生成AI！ 』）があります。そこが生成AIのプロダクト開発の多くの知見が溜まっているようで、私の所属するプロダクトエンジニアリング部の注力ポイントとしても生成AIが挙げられているものの、それをつなぐ取り組みはこれからです。 最後に LIFULLでは一緒に自分たちの仕事を良くしていくエンジニアを求めています。これらの取り組みに興味を持っていただけたなら、ぜひ求人情報やカジュアル面談のページもご覧ください🙇 hrmos.co hrmos.co

グループデータ本部データサイエンスグループの嶋村です。 グループデータ本部は、 LIFULLグループで生まれる新たなデータを安全かつ効果的に活用 できるようにし、 事業の変化と持続的な成長を促進 することを目指している組織です。その中で、データサイエンスグループは研究開発組織として、 「活用価値のあるデータを創出」 し、 「データを活用した新たな機能やサービス」の研究開発 に取り組んでいます。 事業を革進し続けて様々な社会課題を解決していくために、 データを最大限に活用できる状態にしていきたい と考えています。その一環として、分析に関わる社員全員に対して、真のドメイン知識獲得、またデータ分析リテラシー向上の機会としてLIFULLファクトブックの作成に取り組んでいます。 LIFULLファクトブックとは LIFULLファクトブックは事業部のアナリストと連携をしてトライアルとして昨年から作成を始めていたのですが、形として完成してきたことから、先日、社内でLIFULLファクトブックの紹介をしました。 トライアルの中で試行錯誤を続け洗練 してきたこともあり、 広く興味を持ってもらえる結果 となりました。その際の資料をお見せできる範囲で用いながら、LIFULLファクトブックとは何か、ご紹介したいと思います。 LIFULLファクトブックに関する取り組みには 2つのねらい があります。1つ目は 「真のドメイン知識の獲得をすること」 で、良質な仮説を作れる状態やドメイン知識が共通化される状態にし、事業革進の効率を高めるということです。2つ目は 「分析リテラシの向上をすること」 で、正しい分析や説明を意思決定層へ届けることで、迅速で正しい意思決定ができる状態にすることです。 たとえば、分析をする際に「代表値」として「平均値」が使われることが多いですが、統計的な知識を持たず、「とりあえず平均値で」という状態だと誤った解釈になり、正しい意思決定にもつながりません。分布の特性次第で平均値が良いのか、中央値や最頻値といった他の代表値が良いのか、変わってくることがあります。また、二峰性など複数の分布が混在している場合では、分布を確認したうえで成分を分ける必要もあります。 LIFULLファクトブックを活用し、 実際のデータがどのような分布になっているのかを確認 するだけでなく、読み会と呼んでいる集まりを通じて 継続的にディスカッション をしています。特定の仮説や目的を持った分析（アドホック分析や深堀り分析と呼んでいます）とは異なり、様々な軸での分布を見ることでファクトを確認します。その際に、 今までの経験から想像していたデータと実際に確認したデータが異なるという気づきを得られることが多く、正しくファクトを定着させることが重要 であると再確認できました。 下図はLIFULLファクトブックのコンテンツ例です。 左側に分布を理解するためのグラフ があり、 右側に要約や説明が記述 されています。左側のグラフでは、需要と供給を表すデータの分布をそれぞれ載せており、 分布の山の違い が一目でわかるように可視化しています。また、 累積分布 を載せることで、分布のビン幅（横幅）に囚われず、 分布の形状を正しく理解 できるようにしています。右側では、各種統計量を載せ、 グラフおよび統計量から読み取れるファクトや考察 が記載できるようにしています。また、どのように作られたデータやグラフなのか、参加者が後からでもわかるように、算出方法の定義や関係資料へのリンクを載せられるようにしています。 LIFULLファクトブックの作成や読み会を通じて、様々な意見をいただきました。 当初は活動の意義がなかなか伝えられず賛同を得られない場面 もありましたが、 現在では読み会の参加者も大幅に増え大盛況 になっており、社内兼業制度「 キャリフル 」を活用して読み会での発表をする社員も増えてきました。最初はグラフやデータの読み方がわからない、という声がありましたが、一つ一つレクチャをすることで 「統計の基本知識がわかるようになった」 や 「ドメイン知識を得る良いきっかけになった」 といった声も多く集まりました。 おわりに 今回は真のドメイン知識を獲得しデータ分析リテラシを向上させる取り組みである「LIFULLファクトブック」の紹介をしました。 お知らせとなりますが、データサイエンス系の自社イベント 「 LIFULL AI Hub 100ミニッツ 」 を計画しており、次回は「LIFULLファクトブック」の取り組みについて紹介をする予定です。少しでも興味を持ってくださった方は、是非、気軽にご参加いただけると嬉しいです。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービス」の研究開発活用を加速して下さる シニアデータサイエンティストを2枠募集 しています。 【研究開発職】データサイエンスで高難易度な技術課題に取り組む研究開発に興味ある方 【実事業への活用促進職】研究開発成果や新たなAI技術を活用し、実プロダクト・システム開発推進に興味ある方 いずれかに興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

こんにちは。 LIFULLのグループデータ本部データサイエンスグループ所属の岩﨑です。 私の所属するグループデータ本部データサイエンスグループは、LIFULLのデータを通じて事業の成長を促す研究開発を担う部門です。 『データ科学と研究開発の成果によってワクワクと喜びを生み出す』をビジョンとして掲げ、AI技術シーズの創出や活用によってデータの価値を最大化し、社会課題の解決に向けて日々革進をし続けています。 2024年2月24日に開催された「第86回 Machine Learning 15minutes! Hybrid」という機械学習関連のLTを行うイベントで登壇いたしました。 この記事ではそのイベントや登壇内容、感想などを書いていきます。 Machine Learning 15minutes!とは machine-learning15minutes.connpass.com 「Machine Learning 15minutes!」は、「機械学習」について「15minutes以内」で語るLTを6～9人程度で行い、DeepLearningなどの先端的な事例、強化学習などの流行している技術、ビジネスへの応用例など、様々な角度から機械学習についての知見を広げ、LT終了後の懇親会でネットワーキングを行うイベントです。（上記ページより引用） 上に記載しているように、このイベントでは機械学習に関するLTを複数人で行います。その中でLIFULLからは、「LLMを用いた住まい探しにおけるユーザー価値観の推定」と題して、不動産業界でのLLMの研究・活用について共有・議論をしました。 同イベントはオンライン開催のみの時期もありましたが、私が登壇させていただいた第86回の前回からLIFULL AI Hubと協賛という形でLIFULL本社でハイブリット開催をしています。 なお、3/30に開催される次回第87回はミイダス社で、4/27（土）開催の次々回第88回は、再度弊社にてハイブリッド開催を予定しています。 私が感じたように第88回イベントも幅広い機械学習に関連する発表を聞いたり、専門の方と議論ができる機会となると思いますのでぜひ、会場へ足をお運びいただければと思います！ 協賛させていただいていますLIFULL AI Hubは、機械学習やデータサイエンスに特化した知見や成果事例などを社内外に発信していくことを目的としたLIFULL主催のイベントとなります。 詳細はこちらをご覧ください。 www.lifull.blog 発表内容 第86回の登壇者や発表内容は下記のページに記載されています。 発表は大きく3つのカテゴリに分けられており、各カテゴリの発表で機械学習分野の最新情報や社会実装例などの情報共有と議論が行われました。 machine-learning15minutes.connpass.com 生成AIの最新業界トレンド 発表1：【生成AI の未来】 14:05～ 発表2：【ニュース、映画、ゲーム、AIアバターまで、動画と世界を生成する。第2の生成AIブームに備えよう】 14:20～ LLMプラットフォーム最新状況 発表3：【LLMOps with Azure Machine Learning prompt flow】 14:35～ 発表4：【IBMの大規模言語モデルGraniteと生成AI Governance 機能のご紹介】 14:55～ 発表5：【自社で70B LLMを事前学習からやって日本最高精度を達成した話】15:10～ AIディスラプティブ 発表6：【ドメイン知識を活用した、薬局における来局予測】 15:25～ 発表7：【LLMを用いた住まい探しにおけるユーザ価値観の推定】 15:40～ 発表8：【画像・動画・音楽・スピーチ生成AIの進歩】 15:55～ 今後の生成AIについての議論（発表1）、LLM向けのプラットフォームの状況（発表3, 4）、日本最高精度を達成したLLM（発表5）など幅広い機械学習関連のお話を聞くことができました。 その中でLIFULLのデータサイエンスグループからは【LLMを用いた住まい探しにおけるユーザ価値観の推定】（発表7）と題して、不動産業界におけるLLMの活用に向けた研究の紹介をしました。 上記の発表資料はこちらからご覧ください。 www.docswell.com LLMは大規模言語モデル（Large Language Model）と名のつく通り、言語モデルとしてチャットボットなどに利用されることが多い印象を受けます。 しかし、今回紹介した研究ではLLMを単なる言語モデルとしてではなく、ユーザ行動のシミュレーションに利用することでユーザの価値観を深く理解したクローン（デジタルクローン）を開発しています。 このデジタルクローンはユーザの価値観に合った物件推薦や、ユーザにより使いやすいUI/UXへの改善に役立てることができると考えています。 現時点ではまだ研究の初期段階ですが、少ないサンプル数においてはLLMを利用したデジタルクローンが人間と近い物件評価（二つの物件の相対評価）が可能なことを確認できています。下のスライドでは、デジタルクローン・人間双方の物件評価の方法とその精度について説明しています。 イベントに参加した感想 このイベントの感想を参加者、登壇者と目線を分けて書いていこうと思います。 まず参加者としては、幅広い機械学習に関連する発表を聞いたり、専門の方と議論ができるというとても有意義な場だったと感じます。 最先端の技術の話はもちろん、実際に社会実装されている技術・システムのお話などもとても興味深いものでした。 また、会場の雰囲気もあまり堅いものではなく、気軽に雑談や質問ができるとても良い環境でした。 次に登壇者としては、LIFULLのデータサイエンスグループで行っている自身の取り組みを紹介し、意見をいただける貴重な機会だったと感じています。 発表の中でコメント・質問をしてくださったり、その後の懇親会で内容について議論ができたりと、研究やプロダクトをより良い方向へ改善していくためのフィードバックをたくさんいただくことができました。 最後に 今後、さまざまな方と研究開発に関して、意見交換や情報共有を行えればと考えております。 この記事を通じてLIFULLの研究開発に関心をお持ちいただけた方は是非こちらからご連絡ください。 hrmos.co

こんにちは、イノベーション開発室ジェネレーティブAIプロダクト開発ユニットの上田です。 2024/4/1に国土交通省の不動産情報ライブラリとAPIが公開されました！このAPIとGPTsを使って、生成AIでの活用を模索してみました。 不動産情報ライブラリとは 不動産情報ライブラリ 不動産情報ライブラリとは、不動産の取引価格、地価公示等の価格情報や防災情報、都市計画情報、周辺施設情報等、不動産に関する情報をご覧になることができる国土交通省のWEBサイトです。 具体的には、以下のように地図上で不動産情報を確認することができます！ 国土交通省不動産情報ライブラリ（千代田区麹町周辺） また、今回のサイトの公開に合わせて、APIも公開されています。 www.reinfolib.mlit.go.jp APIを利用することで、Webサイトで得られる、不動産価格情報（取引価格・成約価格）、国土数値情報（学区・医療施設・福祉施設・保育園・幼稚園など）などがJSON形式で簡単に取得可能です。 今回は、このAPIを使い「ざっくりした住所を伝えれば、その地域の周辺施設や価格情報を解説してくれるGPTs」を構築してみました！ 住所から周辺情報を教えてくれるAI 以下のように動作します。 LIFULLの生成AIチームのエンジニアが、先日4/1にリリースされたばかりの国土交通省の「不動産情報ライブラリ」のAPIを使ってGPTsを作りました！爆速すぎる！ #LIFULL #エンジニア #不動産情報ライブラリ #生成AI #GAI #GenerativeAI pic.twitter.com/WWfV9csvUj — LIFULL Developer (@lifulldeveloper) April 5, 2024 機能的には、住所を入力することで、その地域の周辺施設や価格情報を解説してくれる、以上のものはありません。 しかしながら、これによって不動産業界では以下のように活用できるのではないか、と感じています。 例えば・・ 不動産仲介業者は：物件やエリアの住所を用いての周辺施設や価格情報を手に入れ、物件の購入や賃貸を探すユーザ対して、ニーズに合った物件・エリアをより迅速に、より正確に提供できる。 物件探しを行うユーザは：GPTsなど生成AIのサポートがあることで、複数地域について気になる観点での比較や、そもそものデータの読み解き方についての知識を補うなど、利用ハードルを下げることができる。 と言ったものが想像できます！これらは今回作成したGPTsから想像できますが、さらに他のデータの活用も視野に入れて考えてると 地域密着情報に詳しい不動産アシスタントAI 地域情報をまとめたパンフレットの自動生成 その地域での暮らしのシミュレーション など、多くの活用が考えられます。 まとめ 不動産情報ライブラリは生成AIの領域においても十分活用可能であることが明らかになりました！ API利用の際には、利用申請が必要でしたが、公開初日に申請したためわずか1日ほどで利用可能になりました。 ※追記：2024/04/05時点では以下のような状況とのことです！ 現在、当初の想定を大きく上回るAPI利用申請をいただいております。 大変恐れ入りますが、APIキーが５営業日以内に発行できない場合もございます。 しばらくの間、ご不便をお掛けすることについて、何卒ご了承ください。 APIの利用申請はこちらから可能です！ https://www.reinfolib.mlit.go.jp/api/request/ また、国土交通省の各種のデータを含め、一つのエンドポイントからこれだけの情報を取得できるのはとても革新的です。各種施設の緯度経度も取得できるので、位置情報のデータ処理を加えることでより柔軟な表現で周辺情報などを扱えるため、より活用の幅を感じました！ 私が所属する組織のビジョンは「ジェネレーティブAIの力で、あらゆる住替え体験の次元を変え、誰もが理想の住生活をおくる未来を引き寄せる」です。我々の部署ではこうした生成AIを活用したプロダクト開発を積極的に行っています！このビジョンに共感し、一緒に新しい価値を創出していく仲間を募集しています！ hrmos.co hrmos.co

こんにちは。エンジニアの小林建太です。 今回はフロントエンド業務での課題をChrome拡張機能で解決を試みた事例をご紹介させていただきます。 LINEヤフー Techから2024年1月に公開された「Tappy」というツールにインスパイアされた拡張機能「 Tap Analyzer 」を開発し、公開しました。 chromewebstore.google.com Tappyとは Tappyの課題と着想 開発した機能 技術 技術選定 開発 chrome debugger API LLMの利用 活用のメリット 今後の展望 Tappyとは Tappy（ https://twitter.com/lycorptech_jp/status/1752587301564436593 より） Tappyは、LINEヤフー Techが開発したスマートフォンのウェブサイトでのタップ操作の成功率を可視化するツールです。URLを入力するだけで、そのページに含まれるボタンやリンクなどのタップ可能な要素のサイズを分析し、指で操作しやすいかどうかを判定して可視化します。現在はiOS端末の解像度のみ対応しています。 tappy.yahoo.co.jp Tappyの課題と着想 私はLIFULLにおいて認証が必要なページを開発していますが、UIについてはデザイナーが作成するデザインを実現するのみで定量的な評価ができていません。特にモバイルの利用者が多いため、ユーザビリティの分析を定量的に行えないかと考えていました。 Tappyで提供される「ウェブサイトでのタップ操作の成功率」はユーザビリティ（使いやすさ）とアクセシビリティ（情報に到達できるか）のどちらにも関わる指標としてある程度有用でしょう。 しかし、サーバー側で処理を行うため、動作にCookieやセッション情報が必要なページでは使用できません。 そこで、Tappyと同様の機能をクライアントサイドで実現するChrome拡張機能を開発することにしました。 ユーザビリティについては以下のIPAの資料が参考になります。 www.ipa.go.jp アクセシビリティについては以下のMDNの資料が参考になります。 developer.mozilla.org 開発した機能 作成したChrome拡張機能は、以下の機能を備えています。 拡張機能「Tap Analyzer」が動作している様子 ウェブページ上のタップ可能な要素(ボタン、リンクなど)の大きさを解析 要素のサイズからタップの成功率を算出 タップ成功率に応じてタップ可能な要素に色付けして可視化 技術 技術選定 拡張機能の作成には Plasmo を利用しました。 Plasmoはブラウザ拡張機能専用のReactフレームワークです。 テストや自動デプロイするための機能なども提供しておりオールインワンなフレームワークです。 Chrome拡張機能はクセが強いChrome APIを利用して作成する必要がありますが、Plasmoはそれらの面倒なポイントを抽象化してくれます。 主な特徴は以下の通り。 React＋Typescript ライブリローディング + React HMR .env ファイルサポート ゼロコンフィグで開発できる 競合としてCRXJSなども挙げられますが、こちらはViteをBundlerにした開発をスムーズにしてくれるもので、Chrome APIの抽象化などはしてくれません。 crxjs.dev 開発 chrome debugger API 私はこれまでに Webpack + Vue.js、CRXJS + Reactなどの構成で拡張機能を作成した経験はあるため、概ね苦労することはありませんでした。 その中で今回初めて触れたのがchrome debugger APIです。 chrome.debugger  |  API  |  Chrome for Developers 大雑把に説明するとChrome Dev Toolsで提供している機能をAPI経由で利用するものになります。 1 つ以上のタブにアタッチし、ネットワーク インタラクションの測定、JavaScript のデバッグ、DOM や CSS の変更などを行います。 今回の拡張機能のウィンドウサイズの変更に利用しています。 chrome.tabs.query ( { active: true , currentWindow: true } , ( tabs ) => { if ( tabs [ 0 ] ?.id ) { chrome. debugger .attach ( { tabId: tabs [ 0 ] .id } , "1.3" , function () { void chrome. debugger .sendCommand ( { tabId: tabs [ 0 ] ?.id } , "Emulation.setDeviceMetricsOverride" , { width: newDevice.getWidth (), height: newDevice.getHeight (), deviceScaleFactor: newDevice.getViewport () .deviceScaleFactor , mobile: true , fitWindow: true } ) } ) } ︙ } ) このように chrome.tab で現在のタブの情報を取得し、そのtab idに対してchrome.debuggerをアタッチしてウィンドウサイズを変更しています。 また、スクリーンショットの取得もchrome.debuggerを利用しています。 chrome. debugger .sendCommand ( { tabId: tabs [ 0 ] ?.id } , "Page.captureScreenshot" , params , ( result ) => { if ( result ) { // 画像保存 const downloadEle = document .createElement ( "a" ) downloadEle.href = "data:image/png;base64," + result.data downloadEle.download = "screenshot.png" downloadEle.click () } } ) LLMの利用 拡張機能開発の本筋ではありませんが、こういった試験的な開発を行いたい時に困るのがデザイン面です。 今回の開発においては拡張機能アイコンとポップアップウィンドウのUIのデザインをどう解決するか迷いました。 結果的に拡張機能アイコンはChatGPTのデザイン系のGPTsで作成し、UIのCSSはCopilotで適当なものを作成してもらい、完成としました。 ChatGPTで作成したアイコン画像 活用のメリット この拡張機能を活用することで、以下のようなメリットが期待できます。 モバイル向けUIのタップ領域の適切なサイズを検討できる 既存のページについて操作性を重視してUIを最適化できる アクセシビリティの観点からも適切な設計ができる Cookieやセッションが必要なページでもTappyの機能を利用可能 今後の展望 現在は一部の機能しか実装されていませんが、利便性を高めていきたいと思っています。 様々な解像度の端末への対応（現在はChrome Dev Toolsでデフォルト設定されたモバイル端末にのみ対応） UIの色分け以外の可視化方法の検討 ユーザビリティの向上 個人で開発したため、個人のRepositoryとして公開しております。 是非、皆さまの貴重な知見やコードをコントリビュートしていただき、一緒にモバイルUIの改善に貢献していきましょう。 github.com LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの江口です。 普段はLIFULLの海外拠点の一つである、LIFULL Tech VietnamのメンバーとともにLIFULL HOME'Sの賃貸領域でサイト改善業務をしています。 今回は、物件の詳細ページを閲覧したユーザー数を集計、取得するシステム（以下rent-pv-counter）を構築したので、その取り組みについて紹介します。 背景 賃貸領域では、A/Bテストによるサイト改善を行っています。特に私の所属するチームでは、より多くの検証を実施し、ユーザーの行動理解を深めることをミッションとしています。しかし、実装工数を削減し、速やかに検証を進められるコストパフォーマンスに優れた施策が主流となる中で、結果的に検証可能な仮説の範囲も限定されてきていました。 その中で、閲覧中の物件の閲覧人数を可視化することが、問合せへの後押しにつながるかの検証を行うことになりました。この施策はバックログとしてはあったのですが、工数の観点で見送られていたものの一つです。今回は、リリースまでどのようなことを意識して開発したのかを共有できればと思います。 システム構成 以下の図は、rent-pv-counter の大まかな構成図です。 rent-pv-counterのシステム構成図 APIはExtensible Service Proxy V2 (ESPv2) をAPIゲートウェイとするCloud Runで稼働しています。OpenAPIに準拠したyamlファイルを元に、ESPv2がすべてのリクエストを受け取り、認証等を行ってくれます。さくっと認証付きのAPIを作るにはとても便利でした。 また、DBはDatastoreを利用しており、ユーザーの閲覧ログを格納しています。 言語はGoで、WebフレームワークはGin を利用しています。APIはユーザーIDと物件IDを受け取り、その物件IDを閲覧したユーザー数を過去7日間、過去30日間で集計します。 集計結果の取得だけでなく、閲覧データの書き込みも同じエンドポイントで行っています。APIは受け取ったユーザーIDと物件IDをキューに格納し、キューにあるデータは定期的にDBに書き込まれます。こうすることで、DBへの書き込み負荷を軽減しつつ、かつ大きなタイムラグを発生させずに集計結果を返せます。 開発していて意識したポイント この施策がバックログに留まっていた原因である、開発工数がかかるという懸念について、以下3点を意識しながら削減に取り組み、結果的に企画職（プランナー）に短期間で実装できる可能性を提示することができました。 積極的にマネージドサービスを使う 今回はCloud Run、Datastoreを利用し、基本的にはアプリケーションの実装のみに注力しました。Cloud Runではデプロイ、スケールアウトなどさまざまな処理を行ってくれます。また、Datastoreではエンティティの有効期限を設定し、古くなったデータを自動的に削除されるようにしました。こうすることで、エンティティを削除する処理を作ることなく、ストレージの費用も削減できます。 できるだけ過去の実装を再利用する 以前、物件の詳細ページにレコメンド機能を導入した際、類似のアーキテクチャを採用しました。その時もDatastoreを活用していたため、DBクライアントやWebフレームワークなどの基本構成をほぼそのまま使用しました。 拡張性を意識した設計 今後新たな機能を追加することも考え、アプリケーションはクリーンアーキテクチャを意識した設計にしました。検証の結果がプラスに終わり今後も提供を続けていくとなると、ある程度の拡張性は持たせておきたいと思ったためです。また、閲覧数で集計したり、別のアクション (お気に入り追加など) でも利用できるような設計にすることで、今後の改修の実装工数を下げることを意識しました。 終わりに 今回は、物件の詳細ページの閲覧ユーザー数を集計、取得するシステムの構築について紹介しました。現在検証中ですが、CVRは良好となっています。エンジニアとして実現可能性を提示し、施策化、リリースまで行う良い経験になりました。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。 プロダクトエンジニアリング部の辰巳です。 私はLIFULL HOME'Sの賃貸領域のエンジニアリーダーとして、LIFULLのベトナム海外拠点であるLIFULL Tech Vietnam(以下LFTV)のメンバーとともに開発を行っています。 海外の方と仕事をしてみたいけど不安がある、そのような方に向けてLIFULLでの海外拠点メンバーとの仕事の取り組みを現場目線でお伝えします。 LFTVと2017年から開発をともにしてきた私から見たLIFULLグローバル開発チームとの働きやすさについて紹介します。 LIFULLとグローバル開発 私は2015年にLIFULL(当時の社名はネクスト)に入社しました。 入社3年目の2017年にLFTVのメンバーと業務をともにしました。 当時のLIFULLはLFTVの母体となる企業の子会社化を行った直後で、海外子会社とオフショア開発を行うにあたっても社内に知見が少ない時期でした。 -6年前- 初めての"オフショア請負開発" 6年前、2017年当時はグローバル開発に不慣れで手探り状態でした。 当時、LIFULL HOME'Sの不動産会社情報を掲載するページを運用するチームで、LFTVとの開発を私に任せてもらいました。 LIFULLとしてはLFTVと連携した開発がまだ3件目の開発案件で暗中模索の色が強かったです。 LFTVとしてもLIFULL以外のオフショア案件が多く、LIFULLの案件を受けるのは社内でも小規模なチームでした。 当時は以下のようなチーム体制でした。 LIFULLの正社員エンジニアのリーダー（私） ブリッジエンジニアLFTVの通訳兼リーダーのエンジニア（以下ブリッジエンジニア） LFTVの開発メンバー2名 私が開発指示を出し、LFTVとしては開発した成果物を納品するいわゆる「オフショア請負開発」として稼働していたのが当時です。 外注開発の色が強く、チームは業務の指示側と受け側できれいに別れており、開発責任とテストはLIFULLが負う形でした。 権限の影響で開発環境がLIFULLとLFTVで別れており、不具合があっても何が原因か分からず開発が止まるといった事態も多かったです。 品質面でもLIFULL HOME'Sへの知見がなかったために開発品質が低く、レビュー回数が多くなったりする事は日常茶飯事でした。 そのため現在と比べてLFTVとの連携がうまく回っていなかったのが2017年当時の内情でした。 -海外拠点との働き方改善- 2024年現在は整備が進み、「オフショア請負開発」の色は抜けました。 LFTVの設立の目的はLIFULLグループで優秀なエンジニアリソースの確保にあります。 彼らがより能力を発揮でき、LIFULLとチームで開発を行えるようにさまざまな改善活動が行われました。 オフショアという言葉を使わず１チームであることを意識づける 海外拠点メンバーの権限の拡張 開発ドキュメントの整備 LIFULL HOME'Sサービスの勉強資料の準備 言語の壁を越えるようにLIFULL側も英語などで積極的にコミュニケーションを行う 定期的なアンケートで働きやすい環境をヒアリングする 他にもありますが代表的なものは上記に挙げた通りです。 私もLFTVと一緒に業務を行い始めた最初期から関わっていたので、ドキュメント整備や業務フローの改善を行ってきました。 このような活動を行い、社内に海外拠点との開発機会が増え、知見がたまることでさらに改善につながります。 良いスパイラルが生まれて、現在では当たり前のように海外拠点メンバーとチームを組んで業務を行うようになりました。 開発品質の向上 現在はLFTV内の品質管理チームがサポートしてくれるようになったりと開発品質も大幅に向上しています。 現場に近いところだと、LIFULLの正社員に近い権限をLFTVメンバーが持っているため開発環境の差がなくなりました。 連携当時はLFTVのセキュリティレベルが低く、日本の法律やLIFULLのレベルと合わせるのに時間がかかったため開発環境に差がある状態でした。 当時の例を挙げると、LIFULL HOME'Sの開発環境がインフラごと分かれており、LFTVでは日本の環境をクローンした環境で開発を行っていました。 DBから別の環境であるため、LIFULLでほかのチームがDBやインフラリソースに変更を加えた場合、そこに差分が出てしまいアプリケーション開発ができないなど頻繁に発生していました。 他にもサービスアカウントが分かれているためLIFULLの機密性の薄いドキュメントすら参照できないのでコピーしてメールで送付したりと業務進行に影響が出ていました。 これらがなかなか解決できずにモヤモヤしながら業務をしており、海外拠点との業務は今後大丈夫なのか？と考えていたのを覚えています。 ただ、これも克服してLFTVでは日本の正社員と同じように業務を行える環境が整いました。 現在の私のチームでもLFTVメンバーが活躍しており、開発スピードがLIFULLのエンジニアに迫る勢いで施策のリリースが行えています。 2017年当時からは信じられないほど海外拠点と働きやすくなっています。 ワンチームでの開発 LIFULLの開発メンバーとLFTVの開発メンバーの権限差分が払拭されたり、開発にあたってLIFULL流の知見がたまっていったりと、１つのチームで開発する色が強くなっています。 LIFULLとしてもグローバル開発では各国の拠点を跨いで1つのチームを編成したり、必ずしもLIFULLのメンバーがリーダーを担うとは限らないといった、各国メンバーが同じ立場でのチームを想定しています。 もっと目の前、現場を見るとLFTVとLIFULLのメンバーで意識が変わりました。 請負開発ではなく１つのチームであるという意識が強まりました。 積極的に開発要件に質問をしてくれたり、LIFULL側の指示に不備がある場合は訂正をしてくれたりと意識が変わってきています。 たとえば私とプランナーが見逃した仕様の不備をLFTVで実装初期に発見し、ドキュメントにまとめて共有してもらえたことで仕様漏れが回避できたこともあります。 このように海外拠点のメンバーとの業務が日本のメンバーと遜色なく行えるようになったと感じています。 さらに現在ではマレーシアのLIFULL Tech Malaysia(LFTM)も仲間に加わり、チームの国際色がどんどん豊かになっています。 LFTVとLFTMとの開発機会が増え、今後さらにLIFULL内で国際色が豊かになっていくと思います。 彼らの開発手法やマインドは日本人とは違う部分もあります。 そういった点をLIFULLのエンジニアも吸収して、エンジニアとしてお互いに切磋琢磨できる環境となってほしいと思います。 最後に LIFULL・LFTV・LFTMではそれぞれ一緒に働いてくれるメンバーを募集しています。 日本にいながら海外の方と仕事ができる貴重な環境でもあります、興味のある方はぜひカジュアル面談のページをご覧ください。 https://hrmos.co/pages/LIFULL/jobs/010 https://hrmos.co/pages/LIFULL/jobs/010-9998 https://lifull-tech.vn/careers/

こんにちは、プロダクトエンジニアリング部の山﨑です。 私は LIFULL HOME'S 賃貸マーケットのプロダクト開発を行うグループに属しており、その中でも技術負債解消に取り組むエンジニアリングチームのリーダーをしています。 本記事では、LIFULL HOME'S の賃貸マーケットにおける技術負債の現状と、本チームの具体的な取り組み内容を紹介します。 LIFULL HOME'S の技術負債解消への取り組みを知っていただくことで、LIFULL HOME'S でのエンジニアリングに興味を持っていただけたら幸いです。 LIFULL HOME'S の賃貸マーケットにおける技術負債の現状 さっそくですが、現状、賃貸マーケットの基盤刷新後のアプリケーションは 刷新前のアプリケーションへリクエストを送ることで一部機能の実行を担保している という課題があります。 以前別の記事でも紹介させていただいた通り、賃貸マーケットでは現在アプリケーション基盤の刷新を行っており、物件詳細ページなどページ単位で機能の移植を進めていました。 www.lifull.blog 着々と機能移植が進んでいった一方で、移植することが工数的に難しい機能もあり、そういった機能は苦渋の決断で刷新前のアプリケーションへリクエストを送り実行を担保しているということです。 技術負債解消に取り組む理由 このような状況において、技術負債解消に取り組む主な理由としては、技術負債をそのままにしておくと以下のような問題が発生し続けるためです。 刷新前後のアプリケーション間で不要なリクエストが走ってしまうことで、無駄なリソースを消費してしまっている 移植されていない機能は刷新前のアプリケーションを開発して、移植済みの機能は刷新後のアプリケーションを開発するという複雑な開発体制が続いている 一部使われている機能があることで、刷新前のコードを削除しにくい これらの問題は放置し続けられるものではないため、技術負債の解消を優先度高く取り組んでいく必要があるという状況です。 技術負債解消の具体的な取り組みについて 「移植することが工数的に難しかった機能」について実際に私たちのチームで機能の移植を進めました。 今回は、いくつかの機能を移植した中でも特に ユーザーの行動ログを送信する機能 と ユーザーが最後に検索した条件を保存する機能 について、移植のポイントや取り組み内容について紹介していきます。 ユーザーの行動ログを送信する機能 1つ目に移行した機能は、ユーザーの行動ログを送信する機能です。 LIFULL HOME'S ではより良いサービスを提供するために、いくつかのタイミングでユーザーの行動ログを収集しています。 イメージとしては、ユーザーが物件詳細ページを閲覧した際にその物件の情報などいくつかの情報を送信します。 送信された情報はバケットにたまっていき、その後定期的に分析レポートを作成するためのバッチで利用されるといった形ですね。 できあがったレポートは掲載されている物件の状況把握のために活用されていたりと重要な役割を持っています。 この機能を移植するにあたってのポイント この機能に関しては約 10 年前に開発されて以降はあまり手を加えられていない状態だったので社内の知見者もほぼおらず、ドキュメントも存在していない、まずソースコードがどこで管理されているのかすらわからないという状況からのスタートでした。 そのため、まずはインスタンスで動いているコードを確認してソースコードの管理されている場所を突き止めた後、コードからしくみを把握していく。さっと全体感を理解したうえで、どこをどういった手順で移植していくかを検討していくところから動き始めました。 モブプロでのコードリーディング 全体感を理解していく初回の調査で、コードリーディングの場面に限ってはモブプロで作業を行いました。 「ここはこういった処理をしているね」「ここの処理は不要そう」「本質から逸れているからここの部分は飛ばそう」など認識のレベルを適宜擦り合わせつつ、各々の視点でこの調査が本質から逸れていないかなど視野を広げながら進めていったことで、滞りなくかつその後も前提知識がある程度そろった状態で話を進めることができたというのは一つの良い知見になりました。 コードリーディングをモブプロで行ったことはなかったのですが、置いてけぼりになる人が出てこず、しっかりと議論をしながら進められました。今後も認識をそろえながら進めたい場面では、状況をみて活用していこうと思えた進め方でした。 調査後に判明した機能の構成 さて、一通り調査をして判明した機能の構成は以下図の通りでした。 システムの全体構成 この機能は主にユーザーの行動ログを処理（バリデーションやネストしたデータをフラットにする整形）するための Fluentd と収集したデータを元にバッチ処理を行う EMR から構成されていました。 ですので、アプリケーション側から移行作業としてやることはシンプルで必要なデータを Fluentd に送信するという処理があれば良いということが分かりました。 やること自体はシンプルなのですが、実際にいざ作業を始めてみると開発の活発だったころからは月日が経ってしまっていて、すでに使われていないであろうデータも送信されている状況でした。 不要な値は削除してしまおうということで、まずは不要であることを確認する調査から始めるのですが、不要なデータを削除するということは、どのデータがどのような処理を経ているのかを理解する必要があります。 そのためには、Fluentd のファイルや EMR のジョブのファイルなど複数のシステム跨いでデータの流れを読み解く必要がありました。 このように不要であることの証明は工数のかかることが多いので、ある程度調査はしつつ残りはテストで担保するか、ほかの部署に確認を行ったりしながらなるべく工数をかけすぎないように削除を進めていきました。 結局、多くの不要データを削除することはできたものの、すべての（不要そうな）データを削除することはやはり難しかったです。 ただ、移植するだけではなくリファクタリングも行うという意識は、このプロジェクトを進めるうえで良い意識だったと思っています。 テストのやり方 テストに関しては、新旧のアプリケーションで同じデータを送信して、Fluentd が吐き出したそれぞれのデータを比較するという方法を取りました。 システムの構成としては Fluentd の送信したデータを元に EMR がバッチ処理を行います。 つまり、Fluentd が吐き出すデータ（= EMR にインプットされるデータ）を移植前後で変わっていないかを比較すると最終的なアウトプットの差分もないということで、この方法を取っています。 テスト構成 テストの構成イメージとしては上記のような形です。 基本的には Fluentd のタグでデータを区別して送信しているので、該当するタグの場合は比較用のバケットへデータを送信する様にしている形です。 なお、テスト用バケットにたまった新旧データを比較するためには、新しいアプリケーションからのデータと同タイミングで作成された旧アプリケーションのデータを紐付ける何かが必要です。 紐づけるものがないと比較すること自体ができないので、紐付けをどうするかということはテストの重要なポイントとなります。 今回のテストではリクエストヘッダに載っている TraceId という値を使って紐付けを行いました。この値は LIFULL の共通実行基盤である KEEL 上で動いているアプリケーションが利用できる値で、アプリケーションを跨ぐ一つのリクエストを紐づけるための値として使われています。 www.lifull.blog www.lifull.blog この値をデータに含ませておくことで同一リクエストのデータを比較できるので、テストスクリプト実行時はこの値を見て新旧データを比較することを実現しています。 ユーザーが最後に検索した条件を保存する機能 二つ目に移行した機能は、ユーザーが最後に検索した条件を保存するという機能です。 機能自体はシンプルで、特定のタイミングでユーザーが検索した条件を memcached に保存しておくというものでした。 この機能を移植するにあたってのポイント 今回保存する検索条件は様々なアプリケーションで活用される値なので、基本的に書き込みおよび読み込みの処理は共通の API から行っています。 しかし、この共通の API （以降 V1 API）というのがすでに開発が終了したもので、新規利用が非推奨となっているため刷新後のアプリケーションからは新共通 API （以降 V2 API）を利用する必要がありました。 ただし、V2 API には memcached に対して検索条件保存のためのエンドポイントが存在していないので新たに作成する必要があります。 ここが一つのポイントで、問題は V1 API と V2 API で利用している言語が異なるということです。V1 API は PHP で動いているのに対して V2 API は Ruby で動いていました。 それに加えて、利用している memcached のクライアントライブラリのデータのシリアライズと圧縮のアルゴリズムが異なっており、この部分の整合性を取るのが難しいという問題がありました。 保存するだけであれば問題ではないのですが、保存したものはもちろん取得がされます。 全ての取得したい箇所で V2 API を通して取得される様に統一されているのであればまだ問題にはなりません。V1 API 側に手を入れる必要がありませんからね。 しかし、現状はまだ V1 API から取得している箇所もあるというのと V1 API を通して取得している箇所を特定するのにそのしくみ上工数がかかるため、コストパフォーマンスを鑑みても全ての取得箇所を V2 API に置き換えるのは厳しそうでした。 そのため、V1 API から取得されても V2 API で保存されたものをデシリアライズと解凍出来る様にする必要があるということがこの機能を移植するにあたってのポイントとなっています。 データの圧縮と解凍をどうするか まずは、なるべく開発を終了している V1 API 側に手を加えることはしたくなかったため、V2 API 側の保存の仕方を調整する形で実装が完結出来ないかと調査を始めることにしました。 V1 API 側では PHP の pecl-memcache ライブラリを利用しており、このライブラリは内部的に zlib の uncompress 関数を使って解凍したあと php_var_unselialize することで検索条件を取得していることがわかりました。 V2 API ではそのまま解凍出来る様にデータ圧縮を行いたかったので、Ruby に組み込まれている Zlib クラスの実装やいくつかの gem のコードを読み漁っていたのですが... 結局 V2 API 側だけでは調整できず、調査ばかりに時間もかけてはいられない状況であったので泣く泣く V1 API 側でも問題なく解凍出来る様に手を加えることで落ち着きました。 リリースに向けて 今回は書き込み機能であり、全社の様々なアプリケーションで活用される値ということで影響範囲も広いため、リリースまでにいくつかのリスクヘッジをしました。 一つは、V2 API を通してデータが保存されるユーザーの割合を徐々に増やすという方法です。 初回は 10 %、3 日ほど経って問題なければ 30 %といった感じですね。 もう一つは memcached に保存するデータの TTL を短くしておくという方法です。 これも万が一問題が起きた時に、ユーザーへの影響を最小限にするために極端に短くしていました。 次のステップ・展望 今回私のチームでは 3 つの機能移植を行うことで刷新前アプリケーションへの依存を取り除くことに注力しました。 加えて、今回の機能移植はデリバリに寄せて進めたところもあり、ベストな選択肢が取れなかった箇所も大いにあるのは心残りな部分でした。 やはり一度に大きな変更（たとえば今回みたいに大きな機能の移植をまとめて行うなど）を行うことはリスクが高かったりさまざまな制約から思う通りに進められないことが多かったです。 今後はメインのミッションを進めつつも、周辺のエンジニアを巻き込んで小さな技術負債解消を積み重ねていく取り組みを行っていきたいと考えています。 終わりに ここまで LIFULL HOME'S の賃貸マーケットにおける技術負債解消チームの取り組み内容について紹介してきました。 LIFULL HOME'S のような長年稼働しているサービスでは技術負債が蓄積されがちです。だからこそ負債を解消したときのインパクトがあるし、解消するためには多くの知識やスキルを発揮できる環境だと思っています。 このように、LIFULL ではユーザーを始め社内の開発者など多様なステークホルダーの体験を考えたものづくりを行い、ともに成長していける仲間を募集しています。 興味を持っていただけた方は、ぜひ以下のページもご覧ください。 hrmos.co hrmos.co

こんにちは。 LIFULL Tech Vietnam （以下、LFTV）CEOの加藤です。 2016年よりLIFULLへ中途入社し、主にLIFULL HOME'S 注文住宅領域のエンジニアチームのマネジメントを経験したのち、2023年10月よりLFTVのCEOへ就任致しました。 就任し約半年が経過しましたが、今回はこれからのLFTVが目指す未来について紹介したいと思います。 LFTVについて まずLFTVについてですが、ベトナムホーチミンに拠点を構えるLIFULLグループの機能子会社です。 主にアプリケーション開発業務を担い、LFTVで担う業務の大部分をLIFULL HOME'Sのプロダクト開発が占めています。 従業員は2024年3月時点にて全社で約90名程度在籍しています。 2017年に設立し、これまで右肩上がりで規模を拡大してきましたが、次なる成長を見据え私が就任した今期よりLFTVの第二フェーズと位置付け、新たな戦略のもと走り始めることとなりました。 オフショア開発からグローバル開発へ これまでもLFTVはLIFULL HOME'Sを中心とするLIFULL本社のプロダクト開発を多く担ってきましたが、その関係はいわゆる「オフショア開発」としての関わりでした。 単純に海外で開発することをオフショア開発と呼ぶこともありますが、ここではソフトウェアやシステム開発を海外企業へ「委託」することとして表現します。 受託開発としての関わりのもと、LIFULL本社をクライアントとして認識し、開発してできた成果物をリリースすることを納品として表現していました。 また、役割も分断されていることが多く、日本側で設計までの上流工程を担い、下流工程をベトナム側が担うという体制が主流でした。 こうしたオフショア開発としての体制のもと順調に規模を拡大してきましたが、新たなビジョンを掲げ転換期を迎えることとなりました。 LFTV設立の目的 新たなビジョンの話の前にLFTV設立の目的についてお話したいと思います。 LFTV設立の大目的は「中長期的な事業成長のためのLIFULLグループ全体の開発リソース確保であり、"優秀な人材を確保・増員し、生産性を上げながらコスト削減を実現する"こと」です。 つまりは単にコスト削減のため低単価な海外へ開発業務を外注するのではなく、LIFULLグループの一員として優秀なベトナム国内の人材を確保し、さらなる事業成長につなげることが目的となります。 この目的はLFTV設立以降一貫して変わっておらず、サービス規模が拡大する一方、日本国内のIT人材不足は今後も続く見込みであることから、ベトナム国内の優秀な人材をLIFULLグループの一員として迎えることの重要性はますます高まっています。 IT人材需給に関する主な試算結果 引用元： 経済産業省 IT人材需給に関する調査 グローバル開発の実現 2023年3月には第二の海外開発拠点である LIFULL Tech Malaysia （以下、LFTM）が設立し、LIFULLグループ全体として海外との協力開発の推進がさらに加速することとなります。 このような背景と目的のもと、LIFULLグループ全体として新たに「グローバル開発構想」が掲げられました。 このグローバル開発構想の大きなポイントの一つは日本・ベトナム・マレーシアの各開発拠点間の垣根をなくすことにあります。 今までLIFULL本社とLFTVはシステム開発の委託先として関係性を築いてきましたが、これからは「同じチームの一員」として新たな関係性を築くことを目指していきます。 また、携わる領域や役割においてもLIFULL本社とLFTVとで切り分けがされ、チームもそれぞれ分断されているケースが多く存在していましたが、今後は所属に捉われない体制構築も目指していきます。 これはたとえば、各国跨いで1つのチームを構成することや、必ずしもLIFULL本社のメンバーがリーダーや上流工程を担うとは限らないといったことなどを想定し、各開発拠点のメンバーそれぞれの特性を活かした役割やチーム編成を行うことをイメージしています。 このようなLIFULLグループ全体のビジョンを実現すべく、LFTVとしても新たな戦略を打ち立て走り出すこととなります。 LFTVエンジニアのあり方 ビジョンを実現する上で、「どのようにあるべきか」を明確にすることはとても重要です。 そこで私はLFTVエンジニアの「あり方」として以下のように定義しました。 一人一人がLIFULLグループのプロダクトチームの一員として、プロダクト開発にコミットしている。 ここで重要なポイントは「プロダクトチームの一員」であるという点です。 LIFULLは2021年よりプロダクト開発の方針としてプロダクトマネジメントを導入しました。 corp.lifull.com プロダクトマネジメントの大枠としては、プロダクトマネージャー、テックリード、プロダクトデザイナーを中心として構成されるプロダクトチームが、それぞれの専門性を活かし三位一体で連携し、ビジョン実現や成果の創出といったアウトカムを重視しプロダクト開発を行うといったものです。 グローバル開発というビジョンを実現するためには、このプロダクトマネジメントの考えに基づき、プロダクトチームの一員としての振る舞いが重要であると考えます。 そこでさらに深掘りをし、このプロダクトチームの一員としての振る舞いを実現するために必要な意識を「目的」「チーム」「エンジニア」の3つの観点より定義しました。 目的に対する意識：「アウトプット志向」から「アウトカム志向」へ LIFULLでプロダクトマネジメントを導入するにあたって参考とした書籍「 INSPIRED 」および「 EMPOWERED 」では次のように言われています。 有名なベンチャーキャピタリストのジョン・ドーアは、次のように好んで説明している。「私たちが求めているのは伝道師のチームだ。傭兵のチームではない」 ここでいう伝道師のチームが目指すべきプロダクトチームを指します。 伝道師のチームではプロダクトビジョン、原則、戦略が共有され、チーム全員がプロダクトに対して深い理解を持ち、ビジョン実現に向けて情熱を持って取り組むことが求められます。 また、伝道師のチーム（= プロダクトチーム）となるためには従来の機能開発チームから脱却することが必要であると表現されています。 機能開発チーム：従来型組織で、個々のチームのアウトプット重視で動いているようなチーム プロダクトチーム：一流テクノロジー企業にあるようなアウトカム重視のチーム 今までのプロダクト開発においては、決められた機能を仕様通り正しく期日を守って開発することに最もフォーカスして取り組んできました。 この先目指すべきプロダクトチームの一員となるためには、これらの目的をしっかり遂行することに加え、その先にあるアウトカムにも意識を向けることが求められます。 つまりは、事業の推進やプロダクトビジョンの実現を見据え、与えられたミッションを達成するためにプロダクト開発を行う意識がこれからは重要となるのです。 チームとしての意識：オフショアからの脱却 これからはLFTVエンジニアがLIFULL本社や日本人エンジニアと区別された「オフショアメンバー」ではなく、同じプロダクトチームの一員であるという意識が重要となります。 このような意識を醸成すべく、LIFULLグループ全体として「オフショア」という言葉を使わないことを決めました。 オフショアという言葉には、前述の通り業務の委託先という関係性を想起させるニュアンスを持つことがあります。 このような言葉の持つイメージがお互いの関係性を作り上げ、目指すべきチームの形を作り上げる上での障壁となると考えました。 また、国内では現在、東京本社のほかに札幌と福岡に開発拠点が存在します。 札幌、福岡の開発拠点に所属するエンジニアメンバーも本社エンジニアとともにプロダクト開発を行っていますが、それぞれが同じプロダクトチームの一員であるということに誰も違和感を覚えるメンバーは存在しません。 これはプロダクトチームの形成において、物理的な距離や所属先の拠点ではなく、お互いの意識や関わり方が重要であるということを表していると思います。 これらより、LFTVも「オフショア先」ではなく、札幌、福岡と同様に海外に拠点を置く「開発拠点」として捉え、チームメンバー双方の意識も同じプロダクトを開発する同志として変えていくこととなります。 エンジニアとしての意識：サービスを実現するエンジニアへ これから目指すLFTVのエンジニア像として以下のように定義しました。 テクノロジーを駆使してプロダクトやサービスを実現するエンジニアとなる。 システムを開発するという手段を目的としてとらえるのではなく、「目指すべきサービスを実現するという目的を達成するためにテクノロジーという手段を用いる」という思いがこのエンジニア像には込められています。 このような意識を持つことで、エンジニアとしての役割や活躍の場は今まで以上に広がります。 例を挙げると、以下のような場面でもその役割を担うことが考えられます。 アイデアに対し開発実現性の判断を行う アイデアを実現するための最適な手段を検討する システム的なリスクや懸念事項への判断、対処を行う このようにシステムの実開発を行うというのはエンジニアの役割の一部であり、プロダクト開発の活動全体に活躍の場があることが分かると思います。 大事なことはプロダクトチームの一員としてエンジニアリングという専門性を活かし、プロダクトの成長やサービスの実現を果たすという意識であると考えます。 「あり方」を実現する「なり方」 ここまでグローバル開発というビジョンを実現する上でのLFTVエンジニアの「あり方」について紹介してきましたが、最後にその「なり方」について紹介します。 あり方を実現する要素を分解して考えた際、大きく4つの取り組みが重要であることにたどり着きました。 LFTVエンジニアのあり方実現のための全体像 本社・開発拠点間の連携強化 グローバル開発を実現する上で「意識」と「言語」の壁を超えることは重要な要素であると考えます。 そのため、まずはこの2つの壁を超えることを中心に本社および開発拠点間の連携強化を図ります。 意識の壁 意識の壁を超えるための手段としては主に2つのアプローチにて実行しています。 ビジョンシェアリングなどを通じたトップダウンでの発信 各国の文化やイベント、知識などの情報発信 1つ目のトップダウンでの発信は、私自らがCEOの言葉として目指すべきビジョンや思いなどを継続して伝え続けることで、社員全員が同じ方向へ意識を向けることを期待しています。 2つ目の情報発信では、各国の情報に触れる機会を増やすことでお互いを理解し、身近な存在へと近付けることで垣根をなくすことを狙いとしています。 言語の壁 異なる母国語を持つメンバーで仕事を行う場合、言語の問題は避けては通れない課題かと思います。 我々も日本語、ベトナム語、英語を母国語とするメンバーで協業し、プロダクト開発を行うことを目指しているため、この課題に向き合い解決することはとても大きな意味を持ちます。 この言語の壁を超えるべく、チームの状況に合わせ英語でのトライアルやツールの活用など試行錯誤しながら取り組んでいます。 具体的な取り組みについては以下の記事で詳しく紹介しているため、ぜひご覧ください。 www.lifull.blog エンジニア育成強化 従来の関わり方とこれから目指すべき関わり方を比較した際、LFTVエンジニアが担う領域やエンジニアとして求められる振る舞いが拡大することとなります。 例に挙げると今までアプリケーションの機能実装が主な役割であったものが、インフラやデータストア、セキュリティなど担当する技術領域の幅が広がります。 また、開発工程だけでなくプロダクト開発における活動全体において、専門性を発揮しながらほかのメンバーと密に連携することが求められるのです。 これらの要求に対処し、理想的なエンジニアとしてのあり方を実現するためには個々のエンジニアスキルを向上させることは必要不可欠です。 これらを実行するにあたり、まずはLFTVエンジニアとして身につけるべきスキルの方向性をLIFULLグループ全体と統一させるところから始めました。 方向性をそろえ、そこに向けて技術レベルを上げていくことで、LIFULLグループのプロダクト開発に必要な技術力を身につけたエンジニアへと成長することを目指しています。 ミドル層強化 エンジニア育成を行う上で、その体制を構築することも重要な要素のひとつかと思います。 その際、鍵となるのは優秀なミドルマネージャーの存在であると考えます。 今後エンジニア育成をより拡大していくためには、そのドライバーとなるミドルマネジメントが大きな役割を担います。 この考えに基づき、マネジメント教育を強化し、マネジメント力の向上と次世代のミドルマネージャーの創出を目指しています。 制度・環境整備 これらの取り組みを実行するためには仕組み化がとても重要です。 その中でも会社全体としてみた際、社内の制度や環境が戦略と整合し噛み合っている状態がとても重要であると考えます。 この考えに基づき、必要に応じて戦略に合わせた制度の見直しや環境の整備を継続的に実施します。 以下で紹介するのはこれらに関する取り組みの一部です。 組織構造の明確化 現在のLFTVでは組織構造を細部まで示し社内へ公開しているものがなく、社員による認識もあいまいなものとなっていました。 前述した通り、エンジニア育成を行う上では体制が重要となります。 そのため、あらためて組織構造を明確化し組織図に表すことで、所属する組織や組織の階層、上司・部下、組織やポジションによる役割等を明確に表現することとしました。 組織文化の醸成 本社・開発拠点を跨ぐプロダクトチームとして働くためには、同じ価値観を共有し、同じ行動規範によって判断することが重要であると考えます。 LIFULLグループでは社是の「利他主義」や経営理念を始めとし、日々の行動規範を定めたガイドラインなど共通して持つべき価値観が定められています。 これらの重要性をあらためて説き、組織の文化として定着させることがこれからのLFTVにはますます必要となると考えます。 最後に ここまでLFTVの目指す未来について紹介させていただきましたが、LIFULL、LFTV、LFTMでは一緒に働く仲間を募集しています。 LFTVでは日本とは異なる文化や価値観に触れ、日々刺激を受けながら成長する機会に溢れています。 海外のメンバーと直接連携しプロダクト開発に携わることで、コミュニケーションの取り方や考え方の違いなど多くの面で新たな発見が得られると思います。 また、ベトナムならではの社内イベントも多数開催しているため、ベトナム文化の中で働きたいと考える方にとっても魅力的に感じていただけると思います。 そして、グローバル開発を推進する中で、国や所属する開発拠点にとらわれない関わり方を目指し、幅広い領域や役割を担う機会を生み出していきます。 幅広い経験が得られる機会の中から、一人一人に合ったキャリアパスを実現するための支援も行なっていきます。 今回紹介したグローバル開発に共感いただき、同じ志のもと挑戦したいと感じて下さった方がいらっしゃいましたらぜひともご応募お待ちしています！ hrmos.co hrmos.co lifull-tech.vn lifull-tech.my

エンジニアの市川と申します。 LIFULL HOME'S の売買領域の開発を担当しています。 さて、さっそくではありますが、読者の皆さんは普段ABテストを実施しているでしょうか。 私たちの開発しているLIFULL HOME'Sでも、日々多くのABテストが実施されています。 ABテストの実施によって市場学習回数を増やし、より良いプロダクトを作り上げることが目的です。 その中で私たちエンジニアが貢献できる点といえば、市場学習のスピードを上げることです。 LIFULL HOME'Sでは長年ABテストを実施してきていますが、いくつかの問題がありました。 今回はその問題と、どのように解決に向けて動いたのかという点について紹介します。 ※LIFULL HOME'SでのABテストにつきましては、以下のリンクをご参照ください。 A/Bテストは事前準備で決まる！？LIFULLのA/Bテスト事前設計の取り組み｜LIFULL Product Growth ABテストにまつわる問題 ABテストを実施する1サイクルの期間が長い 各マイクロサービスを開発する度にABのテストの仕組みが必要になる 解決のための取り組み 共通のABテスト基盤の開発 設定情報の独立化 まとめ ABテストにまつわる問題 ABテストを実施する1サイクルの期間が長い まず、1点目の問題としては、ABテストを1回実施するまでの期間が長いことでした。 LIFULL HOME'Sのプロダクトには、独自のABテストの仕組みが実装されています。 そのABテストの仕組みを使うと下記のような手順と、期間がかかります。 gantt axisFormat %m/%d title 従来のABテスト section ABテスト実装 ABテストの設定情報を設定ファイルに追記 :active, des1, 01/01,1d 各パターンの挙動を実装 :active, des2, after des1, 3d テスト :active, des3, after des2, 1d リリース :active, des4, after des3, 1d 計測期間 :active, des5, after des4, 7d section Bパターン100%適用対応 設定ファイルに記載されている比率を修正 :crit, des6, after des5,1d テスト :crit, des7, after des6, 1d リリース :crit, des8, after des7, 1d Aパターン50%, Bパターン50%で設定し、計測期間が1週間という短めの例です。 ABテストを実装し、Bパターンに有意差ありと判断した場合は、なるべく早くBパターンを100%にしたいです。 しかし、設定ファイルの比率を書き換えるだけでもプロダクトコードのリリースが発生するため、最短でも翌日のリリースとなってしまいます。 1日とはいえ、LIFULL HOME'Sのトラフィックを考えるとなるべく即時反映させたいです。 各マイクロサービスを開発する度にABのテストの仕組みが必要になる 2点目の問題です。 弊社ではLIFULL HOME'Sというプロダクトをメインに開発・運用していますが、このプロダクトはいくつかのマイクロサービスに分かれています。 そして、各サービスにABテストの仕組みが実装されています。 例： LIFULL HOME'S 賃貸基盤刷新におけるABテスト実施システムの構築 - LIFULL Creators Blog graph TD A("ABテスト") B("ABテスト") C("※ABテスト") D("ABテスト") L --- S L --- R L --- M subgraph L["LIFULL HOME'S"] A end subgraph R["賃貸"] B end subgraph S["売買"] C end subgraph M["マイページ"] D end 今後もプロダクトの成長に伴い、新たにマイクロサービスが生まれる可能性はあります。 その度にABテストの仕組みを実装していてはコストが高いです。 現に売買領域のアーキテクチャリプレイスのプロジェクトでは、新しくマイクロサービス化されたアプリケーションが存在しますが、初期段階ではABテストの仕組みを実装していませんでした。 www.lifull.blog ※突貫的に外部サービスを利用し、画面の表示要素を差し替えてABテストを行っていた時期もありましたが、開発体験の良いものではありませんでした。 解決のための取り組み 共通のABテスト基盤の開発 前述した問題を解消するために、各マイクロサービス共通で利用できるpackageを開発しました。 弊社で基盤刷新を目的としたマイクロサービスのアプリケーションは、Node.jsを利用するよう統一化が図られています。 従って、npm packageとしてABテストの仕組みを提供すれば各アプリケーションで利用可能になります。 graph TD 売買-->ABテスト 賃貸-.->ABテスト マイページ-.->ABテスト 現在は売買のアプリケーションでのみ利用している状況ですが、ゆくゆくは統一していきたいと考えています。 設定情報の独立化 また、ABテストの設定情報に関しては、従来のアプリケーション内のファイルに追加する方法ではなく、独立したリポジトリで管理するようにしました。 graph TD A(ABテスト package) -->|read| S[(S3)] R[GitHub ab setting repository] -->|upload| S R -->|PR merge| R ABテストの設定情報を管理するためのGitHub repositoryを用意し、PRをマージするとその設定情報がS3にアップロードされるような仕組みです。 S3にアップロードされると、その設定情報がアプリケーション側に即時適用されます。 このように独立化させることで、本プロダクトへの影響を気にすることなくレビューや承認が行えるほか、プロダクト側のリリースフローに乗せる必要がなくなります。 結果的に、Bパターン採用の意思決定をしてから早ければ数分で100%適用を実現できます。 gantt axisFormat %m/%d title 現在のABテスト section ABテスト実装 ABテストの設定情報を設定ファイルに追記 :active, des1, 01/01,1d 各パターンの挙動を実装 :active, des2, after des1, 3d テスト :active, des3, after des2, 1d リリース :active, des4, after des3, 1d 計測期間 :active, des5, after des4, 7d section Bパターン100%適用対応 設定ファイルに記載されている比率を修正 :crit, des6, after des5,1d まとめ 今回は共通のABテストの仕組みについて紹介しました。 この共通のABテスト基盤を通して、開発プロセスの効率化を図り、よりすばやく市場のニーズに応えるプロダクトを提供できるようになりました。 まだ導入フェーズですので、作ったものを最大限生かせるように働きかけていこうと思います。 ともに良いプロダクト作りをしてくれる仲間を募集しています。 hrmos.co hrmos.co

賃貸領域でフロントエンドエンジニアをしている齋藤です。 今回はここ数年取り組んでいたフロントエンド領域における自動テスト導入とテスト工数削減について、書いていきたいと思います。 なぜ導入したのか、導入して見えた課題、そしてその課題を解決するためにどうしていったのか、という流れで書いていきます。 目次 目次 なぜ導入したのか たびたび障害が発生 開発効率が悪い 自動テストを導入する 自動テストの導入 導入して見えてきたもの ほぼコードを書かない解決策 まとめ お知らせ なぜ導入したのか まず弊社では日々の機能開発は基本的にABテストを実施して効果を検証しながら進めていきます。 そのため、対象となるページが見られたか、対象となる要素が表示されたか・使われたかなどを計測する必要があります。 静的な単一ページであればそれほど問題はありませんが、動的であったり複数のページでそれを行うとなると正しく計測できているかをテストするケースが膨れ上がっていきます。 LIFULL HOME'Sにおいては、物件の検索結果ページがまさにその典型例で、さまざまな切り口で検索でき、またその切り口によって表示されるものが異なります。 意図した切り口で表示されていること、意図しない切り口では表示されないこと、ちゃんと使えるか、計測が正しく行えているかなどをABテストのパターン数×切り口数×テスト項目数でテストする必要があります。 ちなみに切り口は以下のようなものがあります。 マーケット（賃貸・マンション・一戸建て等） エリアの指定方法（都道府県、市区町村、路線・駅等） テーマ（条件を組み合わせたもの） タグ（物件に付けられたタグ） などなど、さまざまな切り口およびその組み合わせで表示できます。 そういった中、弊社で機能開発時にどんなテストをしているかというと、基本的にはスプレッドシート等で作ったテストケースを元に、 デバイス・ブラウザの組み合わせで手動テストを実施しています。 このテスト方法自体はシンプルで、テストを書くのはもちろん、実施するのも誰でもできるという面があります。 一方でテストするページが増えるなどテストケースが増えるとそれだけテスト工数が増えるという一面もあります。 日々機能開発・改修が行われているので、このテスト工数が開発効率に大きな影響を及ぼしてきます。 たびたび障害が発生 上記の通り、切り口の組み合わせで出るものが変わるような複雑なページにさらにABテストが組み合わさるというのは、障害が発生しやすいということでもあります。 当然というとおかしいですが、意図しないページに改修したものが影響していたということが何度も起こりました。 事前調査やコードレビュー等で影響範囲等を見ていても網羅することは難しいのです。 開発効率が悪い 複雑で障害発生しやすいとなると、調査も時間が掛かりますし、テストも手を抜けません。 結果として、物件の検索結果ページに機能追加等改修をかける際には、非常に多くのURLでテストを実施する必要があります。 精神衛生的にもストレスが掛かって良くないですね。 自動テストを導入する ではどうしていくかというと、設計やコード面での複雑性を解消していくというのが一つの方法です。 当然そういう活動も大小行われていますがそれらは一朝一夕では終わりません。 そこで、別の切り口として自動テストを導入し、開発効率を上げていこうということになりました。 自動テストの導入 導入に際しては、まずは開発効率が上がるのかが重要ですので、お手軽にできることから始めることにしました。 実はこれ以前からPuppeteerを使って要素の存在確認やスクリーンショットを撮るなどしていたということがありました。 ですので、使い慣れているということもあってPuppeteerを使った自動テストを行うことにしました。 ※ PuppeteerとはChromeを操作するためのAPIを提供するNode.jsのライブラリです。 導入して見えてきたもの いくつかの機能開発PJで自動テストを書いたのち、それらを共有して導入を進めていきました。 そこで見えてきたのは、テスト実施は効率化されるが、テストを書くということの障壁でした。 PuppeteerはNode.jsのライブラリであるため、普段JavaScriptを書かないエンジニアにとっては障壁があります。 また、テスト項目が増えればそれだけコードも増えるため、テスト作成だけでなくそのコードレビューにも時間が掛かるということもわかりました。 使い捨てに近いテストですので、テストを書くこと自体に対しての障壁があるということは、非常に大きな問題でした。 ほぼコードを書かない解決策 導入して見えてきたものは課題だけではありません。 いくつもの施策でテストを書いてきたことで、何をテストしたいかはおおむね見えてきました。 そこで、テストしたい内容ごとにコードを共通化しました。 ただしそれだけだと共通化したテストコード以外の部分のコードはまだ書かなくてはいけない。 なのでさらに踏み込んで、設定ファイルを読み込んで共通化したテストコードを実行できる様にしました。 const testCase = [ path , status: 200 , specs: [ ... { type : 'hasStyle' , title : 'ダイアログが表示されていないこと' , selector : '.dialog[aria-hidden="true"]' , styleValue : [ 'display' , 'none' ] , } , { type : 'click' , title : `ボタンをクリックする` , selector : 'button[data-target="xxx"]' , } , { type : 'waitForResponses' , title : `レスポンスが返ってくること` , waitForResponses : [ `https:// ${ domain } /result/` , ] , } , { type : 'hasElement' , title : `ダイアログが表示されていること` , selector : '.dialog[aria-hidden="false"]' , expected : true , } , ... ] , ] ; 設定の一例は上記の通りで、テストタイプとセレクタや値などを記載していく様な感じです。 見ての通り、テストしたいことも明確になりましたし、何よりもテストを書くことが楽になりました。 そのほかにもテスト設定をテンプレート化し、headlessモード設定、Cookieの設定、assets読み込みオンオフなどを別に切り出した設定ファイルで管理しています。 サーバレスポンスのHTMLのみでテスト可能な場合には、assets読み込みオフで非常に高速にテストが実行できるなど、テストの実行速度も向上しました。 まとめ 自動テストに取り組み始めてから2年、テストコードの共通化を図ってから約1年が経ちました。 この1年もテストできることを増やしたり、安定して実行できる様にするなど改善を続けてきました。 その結果として、誰でも気軽に自動テストを書ける環境が整い、自動テストを活用した開発がチーム全体に広がったと感じています。 副次効果として、テストだけではなく事前調査での活用にもつながり、非常に効率的な開発が進められるようにもなってきました。 当然、デバイスやブラウザの違いが気になる様な実装に関しては手動テストも行います。 それでもそれらは最低限に抑え、できるものは自動テストで行うというスタンスを今は取っています。 自動テストの活用により以前より安心して開発ができる様になりました。 今後も改善を続けつつ、より安心した開発に向けても取り組んでいきたいと思います。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、エンジニアの中島です。 この記事は2024年2月〜3月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。 この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。 さっそく2月と3月の合算記事となりました。 目次 目次 サービス改善 トップのフリーワード検索の入力欄に設定された誤ったroleの除去 物件情報の編集画面のフォームのアクセシビリティ対応 駅選択ページ内の絞り込み機能のフォーカス改善 物件一覧(ブランド名による検索)ページ内の絞り込み機能のフォーカス改善 物件画像一覧ページ内の「画像をもっと見る」ボタンのアクセシビリティ対応 売却査定フォームのバリデーションを改善 育成・啓発の取り組み アクセシビリティ1on1 WCAG解説書 輪読会 外部発表および発信 お知らせ サービス改善 本期間中の改善取り組みのターゲットはLIFULL HOME'S 不動産アーカイブのPCページです。 諸事情で発表できないものもありますが公開可能な取り組みを紹介させていただきます。 トップのフリーワード検索の入力欄に設定された誤ったroleの除去 アーカイブサイトのトップページにはフリーワードで物件を検索できる入力欄があります。 現在の仕様を確認したところ、comboboxではないただの入力フィールドなのですがcombobox風のroleが誤って設定されていました。 不要なroleを除去し、普通のtextboxとして扱う修正をしました。 物件情報の編集画面のフォームのアクセシビリティ対応 アーカイブサイトでは物件の所有者や詳しい方などが物件情報を編集リクエストするための投稿フォームが存在しています。 そちらのフォームを確認したところ、いくつかのアクセシビリティ要件上の問題が発見されました。 いくつかのフォームコントロールに適切な名前が設定されていない いくつかのフォームコントロールのフォーカスインジケータが見えない(あるいは見づらい) 入力エラーと項目の関連付け 全体エラーの読み上げ 入力ステップ表示に適切な現在地を示すマークアップがされていない これらの問題を解消する修正を実装しました。 ※仕様の調整がつかず全体エラーは現在のところ読み上げのみの対応となります。 駅選択ページ内の絞り込み機能のフォーカス改善 路線・駅から物件を絞り込む検索フロー中の駅を選ぶステップで、駅が所属する都道府県ごとに表示を切り替えるUIがあります。 そちらのUIのトリガとなるボタンにフォーカスが当たらない不具合がありました。 こちらもフォーカスがあたるよう、またそのフォーカスインジケータが視認できるよう修正を加えました。 物件一覧(ブランド名による検索)ページ内の絞り込み機能のフォーカス改善 ブランド名から物件を絞り込んだ際の検索結果ページに、表示された物件を都道府県で絞り込むためのUIがあります。 そのUIのトリガとなるボタンにフォーカスが当たらなかったり、開閉状態を正しく支援技術に伝えられたない等の問題の対応を行いました。 物件画像一覧ページ内の「画像をもっと見る」ボタンのアクセシビリティ対応 物件の画像をギャラリー形式で一覧表示できるページ内に存在する「画像をもっと見る」という表示ボタンがあるのですが、そちらがフォーカス不能・押下時にボタンが消滅するにもかかわらずフォーカスが表示されたコンテンツに移動しないといった問題がありました。 フォーカスを可能にし、フォーカス管理を行う修正をしました。 売却査定フォームのバリデーションを改善 物件の詳細画面内に、その物件を売却査定するフォーム(所有者向け)が存在します。 入力に不備がある際に、入力エラーについて記載がでるよう実装されていますが、支援技術でそれを検知することが難しい実装になっていました。 また、入力エラー時にボタンがdisabledになり、フォーカスができなくなるといった問題も合わせて確認できました。 これらを修正し、フォーカスは可能にしたまま、ボタンが有効でないことを伝え、押下時にエラー内容をフィードバックするように修正しました。 また個別のコントロールにも入力エラーの内容を関連付けるようにしました。 育成・啓発の取り組み アクセシビリティ1on1 本期間中は先月と同じくフロントエンドエンジニア6人、デザイナー1人に対して行いました。 内容はWCAGの解説、APG(aria authoring practices)の解説、coga-usableの解説、実際のアプリケーション開発時でのアクセシビリティ配慮に関する相談などが主なものとなります。 WCAG解説書 輪読会 アクセシビリティやっていき勢向けにWCAGの輪読会を隔週で行っています。 本期間中は別イベントとバッティングが何度かあったため、2024/02/05, 同03/18の2回のみ開催でした。 外部発表および発信 以前の月報記事でも触れましたが、昨年12月8日に行われた「アクセシビリティチームの立ち上げと成長する組織づくり」という勉強会で弊社嶌田が登壇しました。 その際の発表が記事になりました。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの渡邉です。普段はLIFULL HOME'Sの売買領域のエンジニアチームにて技術リーダーとして開発を担当しています。好きなNginxのモジュールはngx_small_lightです。 ここ数年、LIFULLの開発部門では「開発生産性」と「品質担保」の重要性が再注目されています。 LIFULL HOME'Sの主要なリポジトリは、10年以上にわたり運用され続けており、数多くの開発者が日々の改善に尽力しています。 しかし、長年にわたる蓄積によって、アプリケーションの要件を満たすための実装が複雑化し、現在では実装時に調査、開発、レビュー、テストのすべての工程でそれぞれ必要以上に時間がかかる結果となっており、開発の生産性を低下させています。 この問題に対処するため、LIFULL HOME'Sでは既存のアプリケーションから必要に応じてシステムを切り出し、部門ごとでの運用管理を行っています。 売買部門もこのアプローチでの分割を進め、不動産の「売買」に関わるアプリケーションを新基盤に移行しました。 そこで、今回はアプリケーションをリプレイスする際に考慮したことその成果についてお話させていただきます。 リニューアル前後のLIFULL HOME'S ユーザー体験の改善 物件詳細ページ 物件一覧ページ パフォーマンスの改善 LIFULL HOME'Sの抱えていた課題とその対応 開発プロセスやコードを簡素化したい 設計思想をわかりやすく伝達したい データ構造を把握しやすくしたい 成果 リリース速度の改善 設計意図の伝達の容易化 開発プロセスの工数削減 今後の課題 複数アプリケーションに適用したい処理の取り扱い クリーンアーキテクチャの依存関係保護の仕組み アプリケーションをどこまで分割して基盤刷新するか 終わりに リニューアル前後のLIFULL HOME'S ユーザー体験の改善 基盤刷新のタイミングでUI/UXの改善に踏み切り、レスポンシブデザイン化による体験の統一、アクセシビリティに配慮し、スクリーンリーダーやキーボードでも利用可能にするなど、WAI-ARIAを使用したUIマークアップやAccessible Perceptual Contrast Algorithm（APCA）の値が60を超えた高いコントラスト比を適用した結果、アクセシビリティスコアが改善されました。 物件詳細ページ 物件詳細 旧UI 物件詳細 新UI 物件一覧ページ 物件一覧 旧UI 物件一覧 新UI ※ 画像は開発中のものです。 パフォーマンスの改善 レスポンススピードの改善により、スムーズにページが閲覧できるようになりました。またページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性が向上し、Core Web Vitalsのスコアも改善しています。 リプレイスしたアプリケーションには以下の技術を採用しています。 項目 技術 アーキテクチャ Clean Architecture フレームワーク Express, LoopBack x TypeScript HTML Preact x TypeScript CSS Tailwind CSS JavaScript Stimulus, Catalyst インフラ基盤 　　　　 Kubernetes LIFULL HOME'Sの抱えていた課題とその対応 開発プロセスやコードを簡素化したい 現在、LIFULL HOME'Sは50人以上のエンジニアによって運営され、年間1000件以上のリリースが行われています。 開発が始まって10年以上が経過し、プロジェクトが成熟するにつれ、ソースコードの複雑性が高まってきました。この複雑性は、リリースの速度を落とし、ソースコードの品質を年々劣化させる原因の一つです。 開発プロセスには、調査、設計、実装、レビュー、テスト、リリースという一連の段階が含まれます。しかし、10年以上の開発を経る中で増大したコードの複雑さは、過去の仕様が入り組んでいることや、古い技術を使用しているため、各工程の進行を妨げ、プロジェクトの期間を不必要に延ばしています。 これに対処するために、効率的な開発プロセスとコードの簡素化に向けた取り組みが求められています。 元々、LIFULL HOME'Sは賃貸と売買の領域が共存するアプリケーションでした。これらの領域は表面的に似ているように感じられるかもしれませんが、実際には多くの点で異なっていました。それにもかかわらず、無理な共通化を進めた結果、賃貸と売買の領域での差異を吸収するようなコードが増加し、システムの複雑性が時間とともに増していきました。これにより、少しの変更が多くの部分に影響を及ぼし、売買領域の機能改修が賃貸領域に予期せぬ影響を与えることが頻繁に発生しました。この結果、リリースごとに他部署との調整や、調査、実装、テストの工数が増大しました。 そこで、新しい基盤への移行に当たり、元々同一のプロダクトとして扱っていたものを分離し、賃貸と売買を別々のプロダクトとして扱うことで、無理な共通化を排除しました。 設計思想をわかりやすく伝達したい LIFULL HOME'SはもともとMVCモデルで開発されていたアプリケーションでしたが、開始時は少人数であったため、設計方針が適切に伝達されていました。 しかし、時間が経過するにつれて開発者の数が増加し、初期の設計思想の伝達が不十分となりました。 この結果、レビュアーと開発者間の合意が優先されるようになり、当初の設計方針と異なる実装が増加しました。 これにより、多様な思想が混在したアプリケーションが形成されました。 この問題に対処するために、実装者とレビュアーの合意のみに頼らず、アプリケーションデザインを重視して設計方針を徹底的に管理し、見通しの良いアプリケーションを目指す方針に切り替えました。 その実現手段として、レイヤードアーキテクチャの一種であるクリーンアーキテクチャを採用し、責務を適切に設定し、依存関係を明確化しました。 また、既存のLIFULL HOME'Sでは似たようなドメインロジックの再実装が多くの箇所で頻繁に行われており、仕様変更時に多数の実装箇所を変更する必要がありました。 この問題に対応するため、不動産という扱いやすいドメイン特性を活かし、ドメイン層にドメインロジックを集約し、再利用可能なクリーンアーキテクチャを採用しました。 データ構造を把握しやすくしたい LIFULL HOME'SはもともとPHP、Rubyを主言語として開発されていたアプリケーションでした。 年数を重ねソースコードの量が増加していく中で、非常に多くのデータフローをたどり、さまざまなデータが変数に入ることが懸念される状況でした。 また不動産にまつわる情報も多岐に渡るため、正規化しづらく、余計にデータの内容に対する信頼は低い状態でした。 したがって、実装時にも型やデータ形式等の可能性をひとつずつ検証し、レビュー時も実際のデータを見てみないとわからないなど、調査、設計、実装、テストそれぞれの工数が大きくなり、品質的にも良くない状況にありました。 そこで、静的型付け言語であるTypeScriptを採用しました。 数ある静的型付け言語の中でもTypeScriptを採用したのは、フロントエンドとバックエンドの両方を同一の言語で実装できる利点と、全社の技術方針をTypeScriptに寄せようという動きがあったためです。 TypeScriptを採用した理由などの詳細な内容については、 以前寄稿されたこちらの記事に詳細が記載されていますので、気になる方はぜひこちらもご覧ください。 www.lifull.blog 成果 リリース速度の改善 アプリケーションを領域ごとに分割することで、アプリケーション内での責任範囲が明確になり、他のマーケットへの影響を避け、リグレッションチェックが不要となりました。 これにより、テスト時に考慮すべきポイントが減少しました。 さらに、自治権を自部署内で完結させたことで、調整コストの削減やリリースタイミングの管理が容易になり、最短でリリース承認から本番リリースまでを一日で完了できるようになりました。そのため、ユーザーへのプロダクト提供までの時間を短縮できました。 設計意図の伝達の容易化 厳格な制約を課すクリーンアーキテクチャを取り入れることで、独自の思想を持つアプリケーションの意図を理解するのが容易になりました。 クリーンアーキテクチャの採用により、後からプロジェクトに参加した開発者も迷わず開発を進めることができます。 開発プロセスの工数削減 クリーンアーキテクチャや静的型付け言語の採用により、強い設計思想やデータ構造の明確化が促され、設計に関する相談が減少しました。 また、データ構造の明確化やドメインロジックのドメイン層への集約化により、既存仕様の理解やバグ修正の工数が短縮されました。 静的型付け言語を採用したメリットも大きく型定義がしっかりしていることで実装者もレビュアーもデータを正しく認識したうえでソースコードが追えるようになり、工数の軽減に成功しました。 さらに、基盤の刷新により、パソコンとスマートフォンでの見た目を統一するレスポンシブデザインを採用して開発工数を削減しました。 今後の課題 複数アプリケーションに適用したい処理の取り扱い アプリケーションを分割することで、新たな課題が生まれました。 特定のドメインロジックを共通で利用したいといった要望や、ABテストを行うための方法などのどのアプリケーションにも必要になりそうなものをそれぞれのアプリケーションごとに実装したくないといった課題です。 このような状況に対応するため、効率的なリソースの活用を目指し、再利用可能なコンポーネントを慎重に選択し、パッケージ化による再開発の回避を進めています。 パッケージ化は一定の調整を必要としますが、このプロセスにより、多くのアプリケーションが一貫性を持つ方法で利益を受けることが可能になります。 完全にパッケージ化されたソリューションを提供するための調整はありますが、これは品質の向上と開発プロセスの高速化に向けての積極的な取り組みの一環です。 私たちは、必要なアップデートを定期的に行い、より少ない工数で高品質な成果を提供することに努めています。 クリーンアーキテクチャの依存関係保護の仕組み クリーンアーキテクチャに触れたことがある人なら、最初はどのレイヤーがどのレイヤーに依存して良いのかなど、覚えるべきことが多く苦労したことがあるでしょう。 クリーンアーキテクチャは強い制約があるため設計方針が崩れにくい一方で、最初に全体感を把握することは難しいです。 当初はCodeOwnerによるレビューを必須化し、依存関係の保全に努めていましたが、人間の目だけではどうしても抜け漏れが出てしまい、この方法が厳しいという結論に至りました。 そこで、dependency-cruiserによる制御を導入し、CodeOwnerのレビューに加えてシステマティックな保全を図りました。この方法では、dependency-cruiserの設定を徹底的に検証することで、違反が発生する可能性を格段に減らし、開発者がクリーンアーキテクチャを正確に理解していなくても、レイヤー間の依存関係による破壊を避けることができ、目標であったソースコードの品質保証を実現しました。 クリーンアーキテクチャを人の目だけで管理するのは困難です。したがって、このシステム化された保全方法を今後も積極的に導入していく予定です。 アプリケーションをどこまで分割して基盤刷新するか 新規に売買領域のアプリケーションを切り出すことになった際、2つの分割方法を検討しました。 それは以下の二つです。 BFF層とフロントエンド用アプリケーションのパターン 売買領域を一まとめにし、モノリスアプリケーションとして運用するパターン これらのアプリケーションを運用した経験から、それぞれに特有のメリットとデメリットが明らかになりました。 BFFとフロントエンドを分離したアプリケーションでは、フロントエンドのみの変更を行いたい場合、最小限の調査と実装コストでリリースが可能です。 また、バックエンドエンジニアとフロントエンドエンジニアの担当領域が完全に分かれているため、開発のしやすさとコンフリクトのリスク低減のメリットがあります。 I/Oの仕様が合意されていれば、各エンジニアが得意な方法で実装することが可能です。 さらに、BFF層を分けることで他のアプリケーションからのリクエストに柔軟に対応できる利点もあります。 ただし、リリース時には二度手間がかかるデメリットがあり、二つのアプリケーションに関わる修正を行う場合、リリースタイミングによるデータ不整合のリスクが常にありました。 そのため、データが変更されても問題なく機能するように実装する必要がありました。 また、BFFとフロントエンド間のデータ交換はすべてプリミティブな値で行われるため、フロントエンド側でも型定義が必要な二度手間が生じました。 モノリス形態のアプリケーションのメリットは、リリースの頻度が一度で済むため、リリースのタイミングを気にする必要がないです。 また、ドメイン層のValueObjectをフロントエンドでも利用できる設計にしているため、フロントエンド側で新たに型定義を作成することなく使用でき、ドメインロジックの利用が可能になりました。 これにより、フロントエンドでのロジック実装が削減できます。 しかし、このアプローチではフロントエンドエンジニアとバックエンドエンジニアの作業領域が衝突する頻度が増え、レイヤードアーキテクチャ内での役割分担の明確化が必要となりました。 以上のように、どちらのアプリケーションにも運用面、実装面での明確なメリットとデメリットがありました。 そのため、今後も最適な形を追求しながらアップデートを続けていく予定です。 終わりに アプリケーションの再構築には、我々に大きな変化をもたらす可能性が秘められています。課題感を徹底的に分析し、アプリケーションの役割を明確にすることで、そのシンプル性が増すことが期待されます。時には、既存のアプリケーションを思い切って捨て去り、新たな軌道に乗ることで、画期的な進化を遂げるチャンスをつかむこともあります。 当然、新しいアプリケーションへの移行プロセスは、時間がかかり非常に困難なものです。知られざる仕様や対応の漏れなど、予想外の障壁に直面することも少なくありません。 しかし、長期的な視野に立てば、ソースコードの知識を未来世代に継承するとともに、開発生産性を飛躍的に高める絶好の機会であるとも言えます。これは、時に勇気を持ってアプリケーションの全面的なリプレイスを決断する理由となります。 本稿では、技術的な詳細には深く踏み込んでいませんが、その点については今後別の機会で詳しく掘り下げていく予定です。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは！ LIFULLエンジニアの吉永です。 普段はLIFULL HOME'SのtoC向けCRMチームにてエンジニアリングマネジャーをやっています。 マネジャーとなり、未経験分野へチャレンジしてくれるメンバーと接する機会が増えました。 自身が経験や知見のある分野であれば相談にのったりサポートはしやすいですが、未経験の分野となるとどのようにしてメンバーと接していくかは悩むことが多いと思います。 メンバーに「これお願い」と丸投げできると楽ですが、現実問題なかなか難しい場面も多いと思います。 マネジャーは自身がレビュアーになるか、レビュー対応できない場合は、他部署の有識者を募ってレビュアーやアドバイスをくれる人を確保する必要もあるでしょう。 本日はこんな悩みを抱えているマネジャーの方向けに、私なりにどんな風にメンバーと接したか、その結果どうだったかについて共有したいと思います。 アジェンダ プレイングマネジャーとして意識していることと不安や悩みについて 施策はどのようにして進行したか 施策の結果はどうだったか まとめ 最後に プレイングマネジャーとして意識していることと不安や悩みについて 意識していること 私はプレイヤー比重が少し多めのプレイングマネジャーをさせていただいておりまして、なるべく現場で自身の手も動かしていたいとは思っています。 一方、マネジャーに求められているのはチームとしての成果を最大化することですので、自身の手を動かすことが最適解ではない時はメンバーへ任せる、お願いすることも重要だと認識しています。 よって、プレイヤーとマネジャーとしてのバランスは常に意識しています。 どんな不安があったか プレイヤーとマネジャーとしてのバランスを考慮しつつ立ち回っていくと、おのずとチーム内でこぼれ球となった施策を拾って対応するということも多くなります。 もしこのこぼれ球が自分で対応できないものだったらどうしよう？という漠然とした不安はありました。 どんな悩みがあったか 実際にメンバーにも未経験分野へチャレンジしてもらう機会も増えてきたことから、マネジャーは未経験分野の技術をどこまでキャッチアップしたらよいか？という悩みがありました。 どこまでキャッチアップすべきか？ メンバーで対応しきれない不測の事態が起きた際に自身で巻き取って対応ができる状態にまでキャッチアップできていることは理想だと思います。 ただ、自身の業務とマネジメント業務の傍らで詳細な部分までキャッチアップするのはなかなか大変です。 よってどこまでキャッチアップすべきか？についての線引きが非常に重要だと思います。 線引きはケースバイケースだと思うので、以降で紹介する機械学習を用いて物件をレコメンドするモデルを構築する施策をメンバーへお願いした際の話を通して、その施策でどこまでキャッチアップしたかを紹介します。 施策はどのようにして進行したか お互い手探り状態で施策はスタート メンバーも機械学習は未経験だったので、そもそもどこから手をつけようか？という状態で施策はスタートしました。 まずは二人で定期的にMTGを行い、お互いにインプットした情報を共有しあい、メモ書きにどんどんと追記していきました。 調査は分担しながら進行 機械学習にチャレンジしてみようというきっかけはBigQuery MLでした。 ※SQLでモデル構築が完結するので、学習用のデータをセレクトして各パラメータの調整を行うことでレコメンドモデルを簡単に構築できそうだという理由で選定。 メンバーにはBigQuery MLの詳細な利用方法の調査を、私は物件をレコメンドするモデルを構築する為にどんなデータを用意すればよいか？どんな手法で機械学習させたら良いか？を調査するように分担しました。 幸いBigQuery MLのチュートリアルではコンテンツをレコメンドするモデル構築の流れを公開してくれていました。 cloud.google.com 行列分解という手法を用いれば何かしらのレコメンドはできそうだというところまではスムーズに行きつき、ある程度具体的な実現までの道筋も見えました。 なお、その際にインプットした内容はQiitaの下記記事へアウトプット済みです。 qiita.com 方向性が決まった後は動作検証サイクルを回しながら進行 メンバーの方ではLIFULLが保有している各種データをBigQuery MLに学習させる手段も分かってきたところで、お互いの調査結果や知識をマージし、以降のモデル構築の為のSQL作成はメンバーに担当してもらいました。 私は作ってもらったSQLのレビューや学習させるデータの組み合わせのアイデアをメンバーに伝え、そのアイデアを実現する中間テーブル作成やSQLをくみ上げてもらい、レビューおよび動作検証をするというサイクルを回しながら開発は進行していきました。 最終的にキャッチアップはどの程度まで行ったか 私はBigQuery MLで構築した物件レコメンドモデルについてはある程度細部までキャッチアップできている状態でした。 ですが、BigQuery MLで他にどんなことができる？まではキャッチアップしきれておらず、あくまで今回の要件を満たす為に必要だった上流工程で得た知識止まりではあったと思います。 施策の結果はどうだったか 無事にリリース 無事にモデルは構築し終わり、ルールベースで構築された物件レコメンドとのABテストを行うことができました。 ABテストの結果は残念ながら優劣が付くほどの差はつかずでしたが、大幅に負けることがなかっただけでもある程度の収穫はあったと思いました。 リリース後の振り返り リリース後、メンバー含めた振り返り会を実施しました。 次回以降での改善点から今回のテーマと関連していたものを一部抜粋して紹介します。 今回は機械学習、BigQuery MLともに初挑戦だったのでひたすら自分たちでキャッチアップ、少々強引に実装してしまった感はあった。もっと社内の有識者に相談する。 「何がわからないのかもわからない、何を質問すればよいのかもわからない」というフェーズを脱した段階で有識者へ早めに相談する。 まとめ 未経験分野へチャレンジしてくれるメンバーにマネジャーとしてどう接していくべきか？について、私なりにまとめました。 ※まとめ部分に関しては、正直まだ私の中でも試行錯誤を今後も繰り返していく部分は多いと思っています。 ※よって、適宜アップデートされる可能性は高いですが、あくまで現時点での私なりのまとめだと思っていただけますと幸いです。 メンバーと頻度高くコミュニケーションを取り、いつでも気軽に相談できる環境にする メンバーと頻度高くコミュニケーションを取っていくことに合意が取れている前提ですが、メンバーが孤独感を感じないように、1日15分でもよいので施策についてコミュニケーションを取る時間を取った方が良いと思います。 特に試行錯誤している時期は、オフィスへ出社しているなら近い席に座って話しやすいようにする、リモートであれば定期的にSlackのハドルでコミュニケーションを取るなどが有効だったかなと思います。 メンバーや有識者と会話できる程度には未経験分野のキャッチアップを行っておく 今回の具体例だと「行列分解」や「BigQuery ML」の概要を他者へ説明できる程度にはキャッチアップしておいたことは、後工程でレビューや実装の一部を手伝ったりもできたので良かったと思っています。 でしゃばりすぎないように気を付ける あくまで主役はメンバーであり、自身はサポートすることが役目だということは意識しておかないと、メンバーの成長の機会を奪ってしまうこともあるので注意が必要です。 チャレンジしてくれるメンバーへの敬意を持って接することが大切だと思います。 社内有識者へ相談できる経路はあらかじめ確保しておく LIFULLには機械学習のエキスパートや、BigQuery MLを用いてモデルを構築しているスペシャリストの方がすでに在籍しています。 この人たちへ相談できるようにあらかじめ社内調整を進めておくことはマネジャーとしての責務だと思います。 最後に 最後まで読んでいただきありがとうございました。 最後に、LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの菊地です。 今回は LIFULL HOME'S アプリでおこなっている Kotlin Multiplatform（以下、KMP）の 導入についてご紹介させていただきます。 LIFULL HOME'S アプリでは、2022年10月頃に KMPの導入の検討を開始しました。他の技術を含めて KMP 発表当時から簡単な調査や検討は行われていましたが、ちょうどこの頃に KMP が β版となったことにより本格的にプロダクトへの導入を検討することが可能となりました。 KMP とは 簡単に説明すると、Kotlin で書かれたコードを Android / iOS 両方で実行できるようにする技術になります。 KMP にする対象は？ LIFULL HOME'S アプリでは、下記の図にある Business / Domain、Data / Core の領域で KMP の導入をおこなっています。 導入するにあたって KMP の導入にあたり、既存の LIFULL HOME'S アプリ（Android、iOS）とは別リポジトリで開発を行い、ライブラリとしてそれぞれ取り込んでもらう形を取りました。 ちなみに、LIFULL HOME'S アプリ（Android、iOS）で使用する社内ライブラリなどは別リポジトリで OS 別に存在しており、それらもゆくゆくは KMP に集約されるという構想になっています。 Compose Multiplatform の存在 LIFULL HOME'S アプリ（Android、iOS）では、UI 部分について Jetpack Compose（Android）や Swift UI（iOS）の導入をしていますが、全ての UI について移行できているわけではありません。 そのためコスト面を最適化するために Compose Multiplatform などもこのタイミングで検討することはできましたが、KMP と UI については分けて進めることができるため、現段階では Jetpack Compose（Android）や Swift UI（iOS）といったネイティブの部品を使うという選択をおこなっており、UI 部分は順次 Jetpack Compose（Android）、Swift UI（iOS）への移行を進めています。 どんな課題があったか ドメイン知識の壁 LIFULL HOME'S は Android および iOS 向けのアプリのみを提供しているわけではなく、PC 向けやスマートフォン向けの Webサイトとしても提供されています。 取り扱っている物件の情報は LIFULL が提供しているものではなく、物件の情報を提供いただいて掲載しているものとなるため、物件を探しているサービスの利用ユーザーに対して提供する部分の開発だけではなく物件を掲載してくれているクライアント向けのシステムを含めて知識として知っておく必要があります。 LIFULL HOME'S アプリの開発・運用をしているだけではこれらを把握することは正直難しい部分もあるのですが、部署を横断して連携するようなシステムの開発となった際にはどうしてもこのドメイン知識が必要となってきます。LIFULL HOME'S アプリの開発をしたいのに、アプリ外のドメイン知識が少ないことで開発コストが膨れ上がってしまったり、意図せずバグを生んでしまう可能性もあったりしてアプリ開発の難易度が上がってきてしまっていました。 長年の積み重ね（技術的負債） LIFULL HOME'S アプリは 2009年12月の iPhoneアプリの最初のリリースからこれまで長年にわたり運用しているため、蓄積された機能やノウハウと同じだけ負債も溜まっていました。 技術的な負債については、日々の運用業務の中で改善活動をおこなっているおかげもあり、負債が増え続けてどうしようもなくなるというような状態とはならずに運用ができています。 ただし今後も LIFULL HOME'S アプリの運用が同じようにできるとは限らず、どこかのタイミングで開発に割くコストよりも改善に割くコストの方が膨れ上がる可能性があり続けるため、さまざまなリスクが考えられました。 参考までに検討の中で挙がったリスクは下記のようなものです。 新しい機能を提供する際に、様々な負債と付き合い続けてきたがために先に負債を返済しないと開発に取り掛かれなくなり、ユーザーへの価値提供が遅れてしまう チームメンバーの入れ替わりにより、ドメイン知識を持つ人が減るとどうしてこうなっているのか？がわからないままメンテナンスせざるを得なくなる 開発規模が大きくなればなるほどメンテナンスする量も増えてしまうため、機能開発ではなくメンテナンスをし続ける人員が出てきてしまう どのサービスでも運用していく上で避けて通れないことばかりでありますが、サービスを健全に運営し成長させ続けていくためには向き合わなければならないことになるため、何か方法がないか？とずっと KMP 以外の選択肢も含めて検討を続けてきました。 リソースの問題 LIFULL HOME'S アプリでは、アプリチームとして Android および iOS アプリの開発をおこなっていますが、基本的にはそれぞれがメインとなる OS を持って業務をおこなっているため、Android チームと iOS チームの２つのチームでアプリチームが成り立っています。 普段の開発ではアプリのプラットフォームが別なのでそれぞれのチームで個別で進められていきます。アプリとしては同じサービスとなるため共通となる API等の開発ももちろん行いますが、そこに割くリソースの割合はそこまで大きくはありません。 この時、チーム間でこれまでの経験の差などにより、どちらかの OS の開発が遅れてしまうといった際にもう一方のチームのリソースは空きがあるのに知識がないため、手伝うことができずどちらか一方のチームだけ残業が増えたりといったことが起きていました。 テストなど分担できるようなものは問題がないのですが、Android と iOS を横断して開発している人は少ない（一部いる）ため、チームとしてリソースの最適化が難しいという課題を長年抱えておりました。 この状態になってしまうと、どちらもしっかりと仕事をしているのに同じアプリチーム内で極端に業務量に差があるように見えてしまうため、健全な開発はしにくくなってしまいます。 なぜ KMP を選んだのか まず選択肢としては KMP 以外も含めて検討を繰り返してきました。Web ベースにしてしまうことも検討されたことはありますし、近年では有力な候補として Flutter で書き直すという検討もありました。 ではなぜそれらの候補の中から KMP を選んだか？についてですが、いくつかの理由があります。 自社開発のアプリチームが存在している 仮に Flutter に移行した場合を検討した際に下記のようなことが懸念事項としてありました。 ネイティブアプリエンジニアから Flutter へは実質的なスキルチェンジが必要となるため、それぞれのキャリアにも影響がある Flutter にしたとしてもコアとなる部分はネイティブコードを理解する必要が出てくる LIFULL では社内で開発チームを持ってアプリを作っているので、これまでの運用に培った運用のノウハウなどのかけがえのない経験やネイティブアプリのコードが書けるエンジニアもチームには揃っています。 その資産（ノウハウや人）をチームとして活かしていくことを考えると、Flutter ではなく KMP を選び、ネイティブアプリを書きたいエンジニアが書ける環境を残した方が良いと判断しました。 コードの共通化 開発効率を向上させるためには、サービスとしては共通なのに OS 毎で実装してしまっているビジネスロジックやライブラリを共通化する必要がありました。これは開発だけでなくメンテナンスコストも含めて純粋にコストの削減につながります。 これは KMP に限らず解決する手段はありますが、Android エンジニアが Kotlin の知識をそのまま活用して開発することができるというメリットが大きいと考えました。 ドメイン知識のハードルを下げることができる LIFULL HOME'S のアプリを開発・運用していく上で悩まされることの一つとして膨大な量のドメイン知識の問題があります。 この問題について、ドメイン知識が必要となるビジネスロジック部分などの開発に経験豊富なメンバーを当てて開発を行いライブラリとして提供することで、経験が浅い若手がドメイン知識のハードルを気にすることなく UI 部分の開発などが行えるようになると考えました。 UI 部分の自由さ 今回のような KMP の導入の仕方であれば、UI については Jetpack Compose（Android）、Swift UI（iOS）といったネイティブで提供されるものをエンジニアが自由に選択できるというメリットがあり、ネイティブエンジニアの楽しみを奪うことがありません。 新技術への挑戦のしやすさ Flutter などでも新しい技術は早い段階で導入が行われますが、安定性などを考慮するとネイティブに軍配が上がります。 LIFULL HOME'S アプリでは、かざして検索といった AR を駆使した機能などを比較的早い段階で導入してリリースすることがあるため、そういった観点でもビジネスロジックのみを共通化できる KMP の方が向いていると考えました。 lifull.com エンジニアのキャリア LIFULL HOME'S のアプリチームでは、全社で利用する共通的な API を呼び出すために自分達のチームで管理しているマイクロサービスとなる API を運用しています。このマイクロサービスの開発を行うためには共通的な API を理解する必要があり、ドメイン知識が必要となってきます。 これまではアプリエンジニアのキャリアとして、アプリを作りながらある程度慣れてくるとドメイン知識が必要となるマイクロサービスの開発を行うということがあり、調査だけでなく理解するのも一苦労となるため、結果としてアプリを作りたいのにサーバーサイドの開発に時間がかかるようになってしまうということがありました。 KMP の導入にあたりマイクロサービスに集約されていたビジネスロジックを KMP に移行していくため、マイクロサービスの開発の負荷を減らすこともでき、何よりビジネスロジックを作るのはアプリ側となるため、純粋にアプリ側の開発をする機会が多くなりました。 そして何よりも、これまでは難しかった片方の OS のアプリチームの手が空いているのにもう片方の OS のアプリチームのタスクを手伝うことができないといった課題について、KMP 部分でビジネスロジックの開発を請け負うことや、設計周りが共通化されることで相談やレビューもしやすくなるというメリットも生まれてきており、Android エンジニアや iOS エンジニアという枠組みではなく純粋にネイティブアプリエンジニアとしてのキャリアを模索することができるようになりました。 KMP 導入における課題 iOS エンジニアの Kotlin に対する恐怖心 Android と iOS のどちらの経験もあると Swift がかければ Kotlin もそんなに怖がることないと思うのですが（あくまで個人的な感想です）、やはり未知の環境での開発に急に移行するとなると不安の声はありました。 こちらについては、KMP 導入を進める際に私が先行して調査などもしていたため、Android エンジニアと iOS エンジニアそれぞれから KMP 開発に人員を当ててもらい、開発しやすいところからお試しで体験してもらうといった形で慣れていってもらいました。 実際に、Kotlin の経験がなかった iOS エンジニアも特に違和感なく KMP の開発ができるようになっています。 プラットフォームごとに考慮が必要なことが意外とある これは KMP で開発を進めていくと、プラットフォームごとにそれぞれのコードを書く必要が出てきた場合や、KMP として提供するライブラリをネイティブ側で取り込んで使おうとした際に躓くケースがいくつかありました。 ですが、LIFULL よりも先に KMP の導入をおこなっている方々が多くいるため、先人の知恵をお借りしてあまり苦労せずに切り抜けることができました。 移行する対象が膨大 当たり前ですが長年の積み重ねでアプリ内に存在するビジネスロジックは膨大なものになっています。これを開発サイクルをできるだけ止めずに移植していくのを考えるというのが非常に大変でした。 LIFULL HOME'S アプリでは、Android 側のロジックを優先的に移植していき、iOS では機能開発する際に取り込めるものがあれば取り込んで徐々に KMP を導入するという形をとっています。 そのため、ビジネスロジックについては Android の方が先に KMP への移行が完了する見込みですが、KMP を導入した機能の開発は iOS 側で行なわれることが多く相互的に補完することができています。 まとめ 今回は、LIFULL HOME'S アプリにおける Kotlin Multiplatform の導入についてご紹介させていただきました。 LIFULL では長年運用されている LIFULL HOME'S アプリにおいて様々な課題に対する一つの答えとして、KMP を導入するという選択を行いました。 完全な移行はこれからでまだまだ時間がかかりますが、KMP 導入という判断を行ったことでチーム内でこれまで Android と iOS でビジネスロジックは同じであるにも関わらず、それぞれのプラットフォーム向けに開発やテストを行う必要があること、膨れ上がった負債についてのメンテナンスコストは仕方のないことなど、半ば諦めながら開発をおこなってきたところが解決できる兆しが見え、やりたかったことができるようになるのではないか？という感覚をチームのみんなが持つようになりました。同じような課題で悩まれている方々や KMP の導入を検討している方々に対して、選択肢の一つとして KMP を検討しても問題ないと自信を言える状況になっています。 またこのタイミングでこれまでやれていなかったこと、やりたかったことも併せて検討してやっていこうというチーム内の雰囲気も出てきているため、さらに様々な改善が行われていくことになると思います。 KMP 導入により様々な課題の解決が見えてきていますが、UI であったりテストであったり、運用面の改善含めてまだまだやることはたくさんあるため、継続的に検討を行い続けることでチームとしてサービス開発・運用を楽しみながら成果が出せる環境作りを進めていこうと思います。 最後に、LIFULL では LIFULL HOME'S アプリの KMP 導入を一緒にしてくれる仲間を募集しております。ご興味ある方はぜひご応募ください。 hrmos.co ※ 今回、ご紹介した LIFULL HOME'S アプリはこちらになります 賃貸物件検索 ホームズ 不動産・部屋探しHOME'S LIFULL Co., Ltd ナビゲーション 無料 apps.apple.com play.google.com

こんにちは！LIFULLクリエイターの日運営委員のいしやまです。 社内のモノづくりイベント『創民祭』が開催されましたので、その様子を共有させていただきます。 記念すべき第10回の創民祭ですが、今回は３年ぶり、オフラインとしては４年ぶりのイベント開催となりました！ 創民祭とは？ 創民祭（そうみんさい）とは、業務や「クリエイターの日」、プライベートで創った物など、LIFULL社員が作ったプロダクトをお酒を飲み、ピザ・寿司を食べながらお披露目するイベントです。近年はWebに限らず、VRやイラスト等、多種多様なプロダクトが展示されています。今回はブース出展とLT（ライトニングトーク）の２本だてで開催いたしました！ 前回の様子はこちら https://www.lifull.blog/entry/2019/06/13/125358 クリエイターの日とは LIFULLでは、マーケティング能力や技術開発能力を高めてイノベーションを創造するため、通常業務の枠を離れて、新たな技術や手法に取り組む機会を設けています。 希望者は、3ヵ月ごとに最大7営業日を使って、好きなものを開発できます。 展示内容 前回同様、Webに限らずいろんなプロダクトが展示されました。以下に展示内容を紹介します。 ここでは選抜された受賞４作品を紹介していきます。 ハンドジェスチャーとラズパイで光を制御する新しいアプローチ VRゴーグルを装着した目の前に表示されている9つの球体をR, B, Yの形になぞって指パッチンをすると、ライトの色が変わります。 VRでこんなに魔法みたいなおもしろく、便利なことができるということに感動しました！ 3Dでつくるセルルックアニメーション blenderという3Dソフトを用いて、セルルック(=手書きのような質感にレンダリングすること)のアニメーションを個人で制作しています。 3Dを用いることで、動きやカメラワークが多いアニメーションでも、手書きに比べて少ない労力で作品を作ったり、安定した作画にできます。 2Dイラストと3DCGのいいとこ取りができます。 かわいいイラストが自在に動いてアニメーションの可能性が広がりますね！ Icon CDN プロトタイプ 現在、フロントエンドエンジニアがアイコンを利用する場合には、デザインデータからアイコンを手動でSVGファイルとして書き出し、最適化し、アプリケーションに配置するという作業が繰り返されています。この手作業はアプリケーションごとに行われるため、工数が多くかかります。 そこでIconをCDNで一元管理・配信できるCDNの構築を有志メンバーで進めています。 このプロジェクトによって、全社の生産性の向上間違いなしですね！ スキルアップを目指してFlutterでチーム開発 ネット麻雀と違い、対面で麻雀では点数計算がハードルとなります。 実践においてはパターン化されたものを覚えれば、7−8割はカバーできると言われています。 そこで、専用カリキュラムを講義・クイズの形式にしたアプリを、Flutterで開発しています。 こちらは同期エンジニアのみで結成された勉強会チームの取り組みだそうです。 こういう取り組みはたのしそうですね、僕もやってみたいです。 ライトニングトーク ライトニングトーク（LT）は3～5分程度の短い時間で発表するプレゼンテーションで、今回の創民祭でも実施されました！ LIFULL Tech Malaysia こちらはLFTMの代表取締役社長の方に、即興でプレゼンしていただきました。 カレーの作り方を例に挙げて、マレーシアの方々との関わり方をユーモアたっぷりに紹介していただきました。 コミュニケーションというものについて考えさせられました。 マレーシアの方々がとても身近に感じられました！ LIFULL Tech Vietnam 弊社ではLFTVを通して、ベトナムのエンジニアも開発に携わっています。 当日の急な参加でしたが、快く発表していただきました。 ベトナムのことが急に身近な存在に感じられました！ 最後に 創民祭、その一部をちょっとだけお伝えしました！ そんなLIFULLでは、一緒に働くメンバーを募集中！新卒も中途も絶賛採用中です。ご応募お待ちしてますので、ぜひみてください！ hrmos.co hrmos.co

プロダクトエンジニアリング部の興津です。 私は現在、LIFULLの海外拠点の一つである、LIFULL Tech Malaysia Sdn. Bhd.（以下LFTM）のメンバーとともにLIFULL HOME'Sの賃貸領域でサイト改善業務をしています。 今回は、言語や文化の違う私たちがどのようにコミュニケーションをとりながら働いているのかを紹介します。 LIFULLの海外拠点の紹介 2024年現在、LIFULLにはベトナム（LIFULL Tech Vietnam Co.,Ltd.以下LFTV）とマレーシアにグループ会社があります。 さらなる事業拡大を目指すために、より優秀な開発リソースを確保したいという考えから行き着いたのが、これらのグローバルな開発拠点の設立でした。 それぞれの現地で採用されたエンジニア達が本社メンバーと協働しながら、開発業務を担っています。 本社メンバーが現地に駐在したり、短期で各拠点に滞在して仕事をすることも可能です。 しかし、普段は現地で採用された各国のエンジニアが中心となって業務を行っています。 なお、LIFULL社内では、LFTVとLFTMを総称して「LFTx」と呼んでいるため、本稿でもこの2つを合わせて指す時はこちらの表現を使用させていただきます。 場所に捉われない１つのチームへ 2023年にLIFULLでは、「LFTxに対してオフショアという言葉を使わない」という宣言をしました。 それは「オフショア」という言葉に、以下のようなイメージが想起されやすいことを懸念したからです。 本社からの発注を納品すればよしとされる状態 業務が固定化してエンジニアが一定以上のレベルから成長できない環境 本社と距離感のある主従関係と不活性なコミュニケーション 先述のように、LFTxが設立された理由は、優秀な開発リソースの確保です。場所に捉われず優秀なエンジニアがいたら一緒に働きたいという気持ちで LFTxは作られました。 LFTxがより能力を発揮できる環境作りや、今後のさらなる発展と増員を目指すにあたって、上記のようなイメージは妨げになると考えました。 目指す方向性に即したLFTxとの関係性を、私たちは以下のようにとらえています。 継続的な開発を続けていく一体感のあるチーム さまざまな業務に挑戦する機会の提供と成長の促進 会社の違いによる距離を感じないフラットなコミュニケーション すなわち、LFTxであることや海外拠点であることは特に意識をしない、1つのチームを作っていく存在としていきたいと考えています。 そのための第一歩として、「オフショア」という言葉を使わないことで、意識の醸成を作ることから始めました。 この宣言をする前のLFTxは、LIFULLから発注した開発業務を受託し、設計からテストまでを一貫して作業してできた成果物を納品する形での協働が中心でした。 つまり、冒頭で書いた「オフショア」という言葉で想起しやすい関係性であったと言えます。 しかし、この宣言と同時に、意識や言葉の扱いだけではなく、体制的にも積極的に理想の実現に向けて取り組んでいます。 本稿では、現在、実施しているさまざまな取り組みを紹介できればと思います。 チーム発足時の状況 上述の通り、2023年の10月から、私が所属するチームにLFTMメンバーがアサインされました。 当時の私は、場所に捉われない1つのチームになりたいという会社の思いに強く共感していました。その一方で、言語や文化が違うマレーシアの人たちと働くことは日本国内で暮らす人と働くことよりは難易度が高く、自分では力不足なのでは、と不安も大きかったです。 その当時のチームメンバーとLFTMがそれぞれどのような状況であったのかを簡単に説明します。 LIFULLのチームメンバー LFTMと協働することが決まった時、私はチームメンバーの一人一人に英語の経験やLFTMとコミュニケーションを取りながら仕事をすることの意向について簡単にヒアリングをしました。 その結果、全員が「これを機にLFTMとのコミュニケーションを取りながら英語力も上げていきたいが、英会話経験はほとんどなく、自信がない。マレーシアの文化もよく知らない」という回答でした。 スキル面は若干心許ないものの、一番大切な意欲は十分にある、という状態です。 これはチームのエンジニアリーダーである筆者も含まれています。 LFTMのメンバー LFTMは2023年3月に設立されたばかりで、10月の時点ではあまりLIFULLとも連携をしていませんでした。 特に、我々のチームである賃貸領域との連携経験はまったくなく、LIFULL HOME'Sを開発する環境やドメイン知識もありませんでした。 また、LFTMの求人要項では、特に日本語のスキルは求めていません。当然、メンバーは日本語がわからない状態です。（なお、LFTMでは2023年12月から日本語のレッスンが受けられる制度を発足しました） LIFULL-tech.my つまり、エンジニアとしてのスキルはあるもののLIFULLの知識は少なく、日本語でのコミュニケーションも難しい状態でした。 LFTMと協働するための取り組み そんな私たち本社メンバーとLFTMメンバーが、どのようにコミュニケーションを取り、協働しているのか具体的な方法を紹介します。 コンセプトは、「言語と文化は尊重しつつ、チーム内の役割は会社の垣根をなくした開発チームを組成する」 同じチームのメンバーとして受け入れるからには、「LIFULLだから」「LFTMだから」という考えを極力捨てることにしました。 ドキュメント類は日英併記で記載するようにして、MTGの多くをLFTMと一緒に行い、重要事項は日本語と英語を交えて会話するようにしています。 PJのアサインも、まとまった単位の仕事をLFTMに任せ、LIFULLは納品されるのを待つといった、受託らしいスタイルは廃止しました。 作業のアサインは会社の垣根をなくし、LIFULLに新入社員が参画した時と同じように行っています。たとえば、コーディングはLFTMメンバーでレビューは本社メンバーが行ったり、LFTMメンバーが作成したテスト仕様書をもとに本社メンバーがテストを行うというスタイルも採用しています。 また、従来ではブリッジSEと呼ばれる日本語が堪能な現地社員を仲介してコミュニケーションを取っていましたが、それを撤廃し、担当者と直接やりとりをするスタイルをとっています。 MTGへの参加を積極的に促していく中で、LFTMメンバーからも仕様やサイト改善施策の提案をしてくれる機会も少なくありません。私たちだけでなく、LFTMも自分たちが受託したことをやるだけではない、ともにLIFULL HOME'Sをよくしていくメンバーであるという意識を持っていることが伺えます。 ただし、現時点でも不十分な点はまだ多いです。たとえば、施策のブレストなど、すべてのMTGをLFTMと行っているわけではありません。今後も改善を繰り返しながら、理想に近付いていきたいと考えています。 言語の壁を越えるためのツール利用 最初の高い壁である言語の差を解消すべく、私たちは以下に挙げるような多くのツールを使用しています。 Meet 私たちは状況に応じてさまざまなWeb MTGのツールを使用していますが、LFTMも交えたMTGではMeetを使用するようにしています。 字幕を各々で設定ができることと、画面共有中も特に設定が不要で相手の顔が同時に表示される状態になっているためです。 私たちは字幕に頼りながら、時にはボディランゲージやリアクション機能も交えて会話をしています。 Googleスプレッドシート ドキュメントを作成する際、私たちはGoogleスプレッドシートを積極的に使用しています。 なぜなら、googletranslate関数を使うことで、容易に翻訳ができるためです。 support.google.com 私たちはサイト改善施策の仕様書や、テスト仕様書などさまざまな場面でこの関数を使って翻訳することで、翻訳コストを削減しています。 Chrome拡張機能「DeepL翻訳」 www.deepl.com GitHubのレビューなど、スプレッドシートを介入することが難しい場所ではChrome拡張機能のDeepL翻訳を使用しています。 書いたものをワンクリックで簡単に訳してくれるので重宝しています。自分の書いた日本語を英語に変換する時やLFTMの書いた英語を日本語に変換する時だけでなく、自動翻訳した英語を日本語に再度翻訳することで、意図しない意味に変換されていないかのチェックにも使用しています。 Slackアプリケーション「Kiara」 www.getkiara.com 私たちは普段の非同期コミュニケーションはSlackで行っています。 このSlackのチームチャンネルに、それぞれの投稿に返信する形で自動翻訳を投稿してくれる「Kiara」を導入しています。 日英どちらで書いても自動で判定し、日本語なら英語に、英語なら日本語に変換してくれるため、Slackのやりとりは言語をまったく意識することなくコミュニケーションが取れている状態です。 Slackワークフロービルダーとkeelai keelaiとは、社内で開発・運用されているAIチャットbotです。詳しくはこちらの記事をご参照ください。 www.LIFULL.blog このkeelaiとSlackワークフロービルダーを掛け合わせることで、自動翻訳を行うこともあります。 たとえば、Slackで任意の投稿に特定のリアクションをつけた時、keelaiにその投稿を翻訳するように指示をする、というワークフローを作成します。 Kiaraではチャンネルすべての投稿を自動的に翻訳するのに対し、この方法では任意の投稿に対して翻訳できるため、チャンネルの特性に応じて使い分けをしています。 さらに、keelaiには「この文章を翻訳しやすい言葉に添削してください」という指示を与えることも可能です。複雑なことを伝える時は、一度翻訳しやすい日本語にしてから英語に翻訳をすることもあります。 自動翻訳を活用するために気を付けていること このツールの使い方からわかる通り、私たちは無理に言語を合わせるのではなく、それぞれの言語を自動翻訳することを主としてコミュニケーションを取っています。しかし、何も考慮せず自動翻訳に頼りきってしまうと、思わぬところで認識の相違が生まれてしまいます。 そのため、私たちは以下のような工夫をすることで、より精度の高いコミュニケーションを目指しています。 一つの文で伝えることは一つにする ×「レビューをしたので確認をお願いします。」⚪︎「レビューをしました。確認をお願いします。」 言葉はシンプルにする ×「教えていただけないでしょうか？」⚪︎「教えてください」 ×「チャレンジパターンが優勢です」⚪︎「チャレンジパターンが勝っています」 主語や目的語を明確にする 日本語は主語や目的語を省略しても伝わってしまう言語です。これらを意識的につけることで自動翻訳のミスを防ぐことができます。 ×「今日は欠席します」⚪︎「私は今日のMTGを欠席します」 動詞は漢字で表現する ひらがなの動詞は変換でミスしやすいので、翻訳の選択肢を狭めるためにも漢字にした方がうまくいきやすいです。 ×「ひらがなの動詞は変換でミスしやすいので」⚪︎「ひらがなの動詞は変換でミスが発生することが多いので」 感情は絵文字で伝える 感情を伝える文章は、特に自動翻訳が失敗しやすいです。 また、翻訳された言葉自体が意図した通りだったとしても、褒めているつもりで言ったコメントが、否定的な印象を与えてしまうこともありました。 そのため、私たちは感情は絵文字を多用して伝えています。 日本語に自動翻訳されたもので、複雑な表現があるものはネイティブチェックを入れる 私たちはLFTMメンバーが作成したテスト仕様書を日本語に自動翻訳して、それを使って本社メンバーがテストを実施することがあります。 テスト手順などは複雑なものも多く、自動翻訳では仕様を把握していないテスト実施者にはうまく伝わらない部分も発生してしまいます。 そこで、仕様を把握している本社メンバーが自動翻訳をネイティブチェックをすることで、テスト手順にミスが発生しないようにしています。 文化の違いを越えるための取り組み 言語は機械的に解決する方法がある一方で、文化的な違いはツールなどで解決することは不可能です。 そこで私たちは、以下のような手段で互いの文化を紹介しています。 Slackで日常を紹介 LFTVとLFTMでは、それぞれが自社の日常を紹介する専用チャンネルを作成しています。 内容は社内イベントや、社員の紹介など多岐にわたっています。 それぞれのチャンネルは本社メンバーも投稿が可能です。 日本で行われたベトナムフェスに行ったレポートなども投稿されていたり、時にはお互いの飼い猫の写真を投稿するだけのスレッドができた日もありました。 このSlackチャンネルは所属するチームも関係なく交流できるツールの一つとなっています。 互いのことを紹介する時間を作る 私たちのチームでは互いの文化を知るための一環として、週に一度それぞれが自由に自分たちの趣味や体験などを紹介する時間を持ち回りで作っています。 内容は最近行った旅行の話や、自分の住んでいる街のことなどその日によってさまざまです。担当者の話をコメントやリアクションも使いながら、楽しんで聞いています。 「この写真に写っているものは何？」「マレーシアと違って日本ではこんな感じです」など、担当者以外が話を膨らませることも多いです。 これはLFTMのメンバーが紹介した、旧正月の過ごし方について書かれたスライドの一部です。 最初は「自分の英語が通じるだろうか」ということばかりが気がかりだったのが、回を重ねるごとに「この話題は向こうの文化だとどう映るだろうか？」ということも考えられるようになりました。 具体的には、私はLIFULLのダイバーシティ＆インクルージョンを推進する委員会のLGBTQ＋チームに所属し、性的指向やジェンダー・アイデンティティに捉われない環境づくりを推進しています。この取り組みを紹介したいと考えた一方で、「ムスリムが多いマレーシアではLGBTQ+に対してどのような考え方を持っているのか？」と立ち止まることができました。 最終的にはLFTMの代表取締役社長である松尾さんにも相談の上、「あくまでLIFULLではこのような取り組みを推進している」という表現で伝えることにしました。まったく違う話題にすることもできましたが、文化の違いを見せないようにするのではなく、見せた上で受け入れ合うことを目指したいと考えたためです。幸いにも、LFTMメンバーは特に拒否反応を示すことなく話を聞いてくれました。 すべての人・事柄が同じようにはならないだろうということは念頭におきつつ、これからも少しずつ互いの文化を受け入れ合えたらと考えています。 LIFULLのサービスに触れる時間を作る お互いのことを紹介している中で発覚したことですが、日本とマレーシアでは住み替えの方法が大きく異なります。 私たちが当たり前に利用しているLIFULLのサービスが、LFTxのメンバーにとっては当たり前ではないのです。 そこで、LIFULLのサービスを一通り触って見てもらう時間を作ることにしました。 また、LIFULLがこのサービスでどのように利益を得ているのかを簡単に説明する時間も設けました。 その結果、LFTMメンバーは自分たちから「ユーザーだけではなく、クライアント(LIFULL HOME'Sに情報を入稿する不動産会社)が触れるサービスも見たい」と提案してくれました。私たちの説明も真剣に聞いてくれました。 自分たちが作っているサービスを理解しながら開発することで、高いモチベーションと品質を維持できていると感じています。 最後に LIFULL・LFTV・LFTMではそれぞれ一緒に働いてくれるメンバーを募集しています。 語学力に自信がないけれど、海外の人と仕事がしたいと考えている人には良い体験を提供できる組織だと思います。当てはまる方はぜひカジュアル面談などのページを見ていただけたら幸いです。 日本人の方でも現地で暮らすことができるのであれば、LFTVやLFTMで働くことも可能です。 hrmos.co hrmos.co LIFULL-tech.vn LIFULL-tech.my