プロダクトエンジニアリング部の二宮です。 「 Qiita Night～企業における生成AI活用～ 」というオンラインイベントで、LIFULLの軽量化GAIチームとして、 リーダーの廣瀬さん と登壇させていただきました。 YouTubeも公開されているので、ぜひご覧ください！ www.youtube.com 私は「LIFULLの内製生成AI基盤keelaiと普及戦略」というLT発表を担当しました。 www.docswell.com 個人的には、パネルディスカッションの中のみずほフィナンシャルグループのWiz Chatお悩み相談所の取り組みが気になりました。本部ビル内の食堂やカフェの中にプロンプトの悩みを相談をしているということで、自分たちも似た取り組みをした際に盛り上げ方を難しく感じていたので、細かいノウハウもお聞きしたかったなと思ってます。 その後の発展 実は発表の後にもいろいろと進展しています。発表前後に完成した機能で、発表できずに悔しい思いをしたものを書き残します。詳細な内容は、いつか各開発者から投稿してくれるはずです。 1つ目は小林さんの書いた記事の中の「今後の展望と課題」の部分にある内容です。ファイルごとにコーディングガイドラインを読み込んでレビューできるようになりました。これはコーディングエージェントと共通した設定ができ、一気通貫した開発体験が実現できています。「コアドメインでない部分はガイドラインを整備してAIエージェントに任せ、自分たちはコアドメインの開発に専念する」という未来を目指しての布石を打っています。 www.lifull.blog また2つ目として、まだ現時点で生成AIを利用しているわけではないのですが、browser-runnerというE2Eテスト機能も実装されています。これはChrome DevTools Recorder等で誰でも作れるテストケースが、リリースフローの各タイミングで自動で高速に実行されるというものです。将来的には自然言語でのテストケースの自動作成機能や、テスト失敗時の自動修復PRなどを構想しています。 LIFULLでは戦略DAYという、全体戦略や各部署の戦略を共有するイベントがあります。その中で、ほぼ全部署が生成AIを使った何かしらの取り組みを行おうとしていて、「もうこんなに時代は進んだのか」と驚きました。また、スライドの中の参考画像で、GPT-4oの画像生成も自然に使われるようになっていました。 最後に 最後に、LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、プロダクトエンジニアリング部の鈴木です。普段はLIFULL HOME'Sの不動産会社向けプロダクト開発エンジニアのマネジメントを担当しています。 先日、社内ゼミ（勉強会）にて、障害対応時の心構えと障害対応訓練について共有しました。 このゼミは、プロダクトの開発・運用に関わるメンバーが抱える「もしシステム障害が起きたら、どのように対処すればよいのだろう？」という不安を解消し、適切な対応方法を学ぶ機会として開催したものです。 長年稼働しているシステムで有識者が少ない中、いくつかの障害を乗り越えてきた私たちチームの経験に基づいた障害対応について紹介します。 前編では障害対応についての基礎知識や心得について触れました。 www.lifull.blog 後編では、それらのスキルを実際にどのように身につけていくかに焦点を当て、チームで実施した障害対応訓練について話した内容をお届けします。 障害対応をどのように学んでいけば良いのか LIFULLでは様々な障害対応のマニュアルが用意されています。私たちのチームではこれらのマニュアルの読み合わせを行ってきましたが、実際の障害対応ではスムーズに動けないという課題がありました。これには主に3つの理由が考えられます。 障害対応のプロセスを頭で理解していても、実際に行動できるようになるには多くの課題があります。これらのスキルは実践を通じて習得できますが、実際のところ障害対応の場から学ぶことは簡単ではありません。 障害対応はあくまで問題を解決することが目的であり、学習の場ではないからです。さらに、緊迫した状況下での経験のみで全てのメンバーが成長できるとは限らず、全ての人が一定のレベルで障害対応ができるようになることは難しいと言えます。 実際にメンバーからも、「障害発生時にマニュアルを確認しようとは思い至らなかった」、「経験のない自分が役にたつと思えなかった」という声があがっていました。 それでは、障害対応はどのように学んでいけば良いのでしょうか。 障害対応訓練をやってみた 障害対応訓練とは『SRE サイトリライトアビリティエンジニアリング』では次のように説明されています。 新人は、ドキュメンテーションやポストモーテムを読んだり、トレーニングを受けることによってSREに関する多くのことを学べます。 本物のプロダクションシステムを実際に壊したり直したりすることで得られる経験はそれらに勝ります 私たちのチームでは、実践的なシナリオを通じて知識だけでなく、現場での対応力を高めることを目指し、障害対応訓練を実施しました。 障害対応訓練の流れ 事前準備 事前準備では訓練の目的、シナリオ、体制を決めます。 訓練の目的・概要： チームの課題に基づいて設定します シナリオ：発生する事象とその対応方法を事前に設定します 体制：障害対応メンバーと訓練運営メンバーに分け、役割を明確にします 訓練の目的は、日頃の障害対応や振り返りを観察し、チームが直面している課題に焦点を当てることをおすすめします。チームメンバーから何を課題に感じているかをヒアリングすることも効果的です。 例えば、私たちのチームでは以下のように目的を設定しました。 目的を設定した後は、訓練の概要を決めます。発生する事象の原因や影響範囲、訓練で対応をカバーする範囲を明確にします。私たちのチームが担当するプロダクトでは、障害対応時にはデータのリカバリが必要になることが多いため、それらを訓練に含めるかなどを検討していきました。 シナリオでは、発生し得る事象とそれに対して期待される対応を設定します。リアリティを出すために、実際と同等の開発環境で障害を起こし、訓練を行いました。 本番に近い流れができるように準備することで、実践的な訓練を実施することができます。 当日の実施 当日は、運営側からの不具合報告をきっかけとして、対応メンバーには普段どおりに、事象の確認・調査から対応を進めてもらいました。 訓練終了時間は先に決めておき、時間内にできるところまでとしたのもポイントのひとつです。 営業や広報部署なども社内ステークホルダー役は運営側で疑似役を担いました。 上長への報告・相談はもちろんですが、対応メンバーは社内ステークホルダーへの報告も行い、本番さながらの条件で訓練を実施しました。 また、記録係りは当日は休日をとっているという設定のもと、記録に徹するようにしました。 訓練中は、メンバーの様子をみながら、必要に応じて訓練運営側からサポートを行いました。 事後振り返り 訓練当日に記録した内容を元に、事実に基づいて振り返りを行いました。振り返りはKPTの形式で、障害対応と訓練自体とで振り返りの観点を分けて実施しました。 障害対応自体の振り返りの観点 いつ、なにが起きて、だれにどのような影響があったか チームの体制は適切だったか 適切に影響と原因の調査ができていたか 情報のキャッチアップ・共有・相談・報告は適切にできていたか ステークホルダーへの共有・連絡・相談は適切にできていたか 訓練のやり方・体制の振り返りの観点 役割の振り分けは適正だったか 記録係の動き方はどうだったか 障害対応の基本フローは体験できたと感じるか 振り返りを通じて改善点を明確にし、次回の訓練や実際の障害対応に役立てていきます。 まとめ 今回の社内ゼミ（勉強会）では、全体を通して障害対応時に重要なポイントとそれらをチームで実践できるようになるための訓練方法について共有しました。 訓練に参加したメンバーからは、「一度実施したことで自信になり、いざという時の対応力が向上した」「有事の際に自主性と積極性が高まった」などのポジティブなフィードバックがありました。 実際に、訓練以降に起きた障害対応でメンバーの対応スピードや自主性がアップしたことを私も実感しました。障害対応訓練を通じて、個人のスキルだけでなくチーム全体の結束も強化することができたと感じています。 障害対応の目的は、システムを直すことではなく、顧客への影響の低減・早期回復をすることです。特にエンジニアの場合、まずシステムを直すことに目が向きがちになると思いますが、大事なのは顧客のビジネスやユーザーに与える影響を軽減することです。 そのためには、企画とエンジニアが協力して対応していく必要があります。チームとして安定した障害対応を進めるために、ぜひ障害対応訓練を活用してみてください。 最後に、LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。フロントエンドエンジニアの根本です。 LIFULL HOME'Sのプロダクト開発とスポーツ関連の新規事業開発に携わっています。 今回、2024年度の人間中心設計専門資格認定制度に挑戦し無事にスペシャリスト資格を取得しました。 ここでは、試験のための事前準備とエンジニアとしてこの試験に挑戦した理由および人間中心設計（Human Centered Design＝HCD）に取り組む意義について考えを整理しました。 人間中心設計専門資格認定制度とは？ HCD-Net（人間中心設計推進機構）が人間中心設計に関して一定水準の能力を有する人材を専門家、スペシャリストとして認定する制度です。 その中で、HCDスペシャリストの受験資格は下記を想定されています。 人間中心設計の基本的な実務能力を持つ実務担当者 人間中心設計・ユーザビリティ関連の実務経験が2年以上 人間中心設計が主業務で5年未満の方や、デザイナーやエンジニアなどで兼務の方 このように、私のようなエンジニアも対象とされた認定資格であり、人間中心設計はエンジニアにとって必要なスキルの一つであることがわかります。 なぜ受験したのか 以前、 RESEARCH Conference 2024に登壇しました - LIFULL Creators Blog でも述べたように、UXエンジニアとして数年間にわたってHCDの取り組みを実践してきました。 この経験を第三者に評価されることにより、自分の知識とスキルの客観的な位置を確認し、キャリアの指針として信頼性を築きたいという思いから受験を決めました。 やっておくべきこと HCDスペシャリストの試験については公に多くの情報が出回っているため詳細は省きますが、私が試験準備として特に役立ったことを紹介します。 それは過去のプロジェクトの取り組みを「詳細に」記録しておくことです。受験時に提出するコンピタンスシートには、各大項目のコンピタンスを、3つの観点に分けて具体的かつ体系的に記述する必要があります。 目的と調査・評価設計の対象 体制と実施内容 工夫とアウトプット これまで参加してきたプロジェクトでは、HCDの目的や設計、その成果や課題を具体的な手法と関連付けて整理していました。具体的には以下の観点でドキュメント化し、管理していました。 調査設計（調査背景・目的、検証手法、検証対象、検証人数、検証期間） 分析設計（採用した分析手法、分析結果） ユーザー定義（採用したモデル化手法、活用したフレームワーク） デザイン設計（プロトタイプ・情報設計の考え方） 詳細にドキュメントを残していた理由は2点あります。   1. HCDの取り組みを正確に伝える 私たちの開発チームは多くのプロジェクト関係者が携わり、時にはメンバーが入れ替わることもあるため、情報共有が非常に重要です。   各種検証や分析プロセスを整理することで、チーム全体が一貫した一次情報を共有し、統一した理解を持つことを目指しました。   これにより、プロジェクト進行におけるコミュニケーションギャップを減らし、効率的な協力体制を築けるようになります。   2. 他チームへのHCDプロセスの伝達 具体的な手法や成果を整理しドキュメント化することで、他のプロジェクトや組織がこれを学び、参考にできることを期待しました。   私たちの開発チームはHCDプロセスにおいてまだ未熟な部分もあるため、基本的なステップも省略せず詳細に整理することを心がけました。   こうしたオープンな情報共有が、HCDプロセスの促進に少しでも寄与できればと考えています。   このようにドキュメントは他者への情報共有目的で作成しましたが、結果的に自身にとっても貴重な資産であることを改めて実感しました。 受けてよかったこと 受験を通して一番良かったことは、過去のプロジェクトでの経験を振り返ることで習得してきたスキルの確認と不足している知識の棚卸しができた点です。 具体的には、A6・A13のコンピタンスについて過去のプロジェクトでは十分に実践できず経験不足を実感しました。 A6. 新製品・新規事業の企画提案力（基本コンピタンス） ユーザー理解から生まれた視点、価値から生まれた新たなコンセプトを、関係者に提案し実現に向けて合意をとれる企画提案能力のこと アウトプットの例：ビジネスモデルキャンバス、ビジョン提案型デザイン手法、ピッチ資料、事業企画書、リサーチ分析結果 今回、ユーザーリサーチの結果を用いて企画提案する力もHCDの一部であることを初めて認識しました。直近の3ヶ月で実施した新規機能開発に向けたユーザーリサーチでは、このコンピタンスを意識し、ユーザーリサーチの結果を活用して提案を行うことに注力しました。 A13.　専門知識に基づく評価実施能力（基本コンピタンス） 人間中心設計（HCD）および関連する専門知識を用いて、製品・システム・サービスのユーザビリティ、ユーザーエクスペリエンス、ユーザーインタフェースなどの良し悪しの判断・指摘ができる能力のこと アウトプットの例：ヒューリスティック法、ウォークスルー法、タスク分析 A13に関しては、過去にユーザビリティ検証を何度も行ってきましたが、ヒューリスティック法やタスク分析などの体系的な方法論に基づいた分析には不十分であったと認識しました。今後は、ユーザーリサーチを進める際に最適な評価手法を事前に考慮し、実践していきたいと考えています。 エンジニアが取り組む意義 最後に、エンジニアとしてHCDに関する知識を持ちプロダクト開発に参加することの意義を考えてみました。 エンジニアは「どうやって作るか」という役割を担う上で、「なぜそれが必要なのか」という点を深く理解することが重要だと考えます。 ただ指示されたものを形にするのではなく、機能要件の本質を理解し、適切に足し算・引き算の提案を行うべきです。 足し算の提案：他にどのような実現方法があるかを提示する 引き算の提案：特定の機能が過剰な開発である可能性を示す そして、「なぜそれが必要なのか」という根拠を示すプロセスとしてHCDが存在すると考えています。「人間にとって使いやすいシステムとは何か」と考えていくプロセスに寄り添うことで、エンジニアはその過程で最適な解決手段を提案することができます。 結果として、ユーザー中心のプロダクト開発においてエンジニアが真の価値を創造する重要な役割を果たすことができるのではないでしょうか。 最後に LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

はじめまして、情報審査グループの山崎です。 今回は私たち情報審査グループが「データ」を仲介役として、エンジニア部門とともに協働したことをお伝えできればと考えています。 本記事ではコミュニケーションについてを軸にお伝えしますが、一般的な見解では無く私の個人的な感覚だけな点もあるのでご容赦ください。 エンジニアの方々に、私たちのような非エンジニアとのより良いコミュニケーションについて少しでも参考になれば嬉しいです。 関連して、エンジニア視点からの取り組み事例として以下の記事も併せてご覧ください。 情報審査グループの役割 取り組みの背景 情報審査におけるデータ活用 部門間連携での紆余曲折 認識のずれ タスク管理手法の違い チーム内での共通言語化 役割分担の明確化の重要性 他職種とのコミュニケーションでの学び 終わりに 情報審査グループの役割 情報審査グループでは「圧倒的な「安心」を提供する。」というビジョンのもと、以下のような業務を行っています。 ユーザーに向けて：掲載されている物件広告を正確に届ける 物件広告を掲載している不動産会社に向けて：正確な物件広告を掲載できるようチェックし問題があれば修正依頼をさせていただく 「募集が終了した物件広告を非掲載にする」という、いわゆる「おとり広告」対策に注力しており、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では共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の千葉です。 LIFULL HOME'S不動産査定 と ホームズマンション売却 の開発に携わっています。 この記事では、売却査定サービスにおけるE2Eテスト高速化の取り組みについて紹介していきます。 売却査定サービスにおけるE2Eテストについて 環境 テスト観点 高速化の取り組み 背景 取り組み1 - 項目の精査と方法の最適化 取り組み2 - 処理の共通化 取り組み3 - ジョブの最適化 取り組み4 - 実行の並列化 取り組み5 - タイムアウト設定 結果 全体 Botでページを開いた際のHTTPステータスコード200の検証 モバイル端末でページを開いた際のHTTPステータスコード200の検証 PC端末での主要導線の確認 モバイル端末での主要導線の確認 まとめ 売却査定サービスにおけるE2Eテストについて 環境 売却査定サービスではE2Eテストを自動化するためのフレームワークであるTestCafeを使用したテストがデプロイ時と毎朝定時に実行され、実行結果がSlackに通知されます。 詳細については、こちらの記事をご覧ください。 www.lifull.blog テスト観点 以下の4項目についてテストを行っています。 Botでページを開いた際のHTTPステータスコード200の検証 モバイル端末でページを開いた際のHTTPステータスコード200の検証 PC端末での主要導線の確認 モバイル端末での主要導線の確認 高速化の取り組み 背景 E2Eテストの課題として、デプロイからテスト終了までの待ち時間の長さが挙げられました。 通常、テストの実行には30分以上かかり、場合によっては60分を要することもありました。 取り組み1 - 項目の精査と方法の最適化 主要導線の確認では通常、物件種別と所在地の入力から入力画面、会社選択画面、確認画面を経て、完了画面までの一連の流れをテストし、完了画面に遷移できることでテストの成功としていました。 この一連のフローで、各ステップにおいて次の項目を確認していることになります。 物件種別と所在地の入力を行うことで入力画面に遷移できること 入力画面で入力を行うことで会社選択画面に遷移できること 会社選択画面で会社選択を行うことで確認画面に遷移できること 確認画面から完了画面に遷移できること 物件種別や所在地に応じて入力画面の入力項目が変わるため、それに応じたテストをそれぞれ実施していました。 しかし、会社選択画面以降のプロセスは同じにもかかわらず、それぞれ完了画面までのテストを行っていたため、同様のテストを繰り返すことになっていました。 また、プロダクトコードの不備や画面読み込みの遅延で、必須項目が入力できず会社選択画面に進めない場合、以降のテストが実行できないという問題がありました。 さらに、TestCafeではユーザーの操作を模倣し、カーソルの移動、クリック、文字入力といった動作を通じてテストを行います。 そのため、1つのフォームの入力にも時間がかかります。 この問題を解決するために、以下のようにテストの役割を分割しました。 入力画面のテスト 入力画面で入力を行うことで会社選択画面に遷移できることを確認 会社選択画面のテスト 会社選択画面で会社選択を行うことで確認画面に遷移できることを確認 また、 会社選択画面のテストでは、入力画面での入力はDOM操作で行い、核心的なテストプロセスである会社選択画面ではUIテストを行うことで実行時間を削減しました。 各観点を独立したUIテストで実行することにより、物件種別と所在地の入力から完了画面に至る一連のフローテストはDOM操作を活用することにしました。 これにより、不必要なテストを排除するとともに、ユーザー操作のステップを省略し直接変更を行うことで、テスト実行時間の大幅な削減を実現しました。 取り組み2 - 処理の共通化 物件種別と所在地の入力では、たとえば「査定可能な会社が1社しか存在しないエリアにおいて、会社を選択しなくても確認画面に進める」というテストを実施したい場合、査定可能な会社が1社のみの所在地を入力する必要があります。 LIFULL HOME'Sをご利用の会員様（不動産会社様）の状況に応じて、各エリアの会社数は常に変動します。 このテストを実行するため、所在地の入力時には東京都⚪︎⚪︎区を入力し、会社数が2社以上の場合は次のエリア（東京都△△区）を入力し、さらに2社以上であればほかのエリア（東京都♢♢区）へと、期待した結果が得られるまで繰り返していました。 その結果、核心的なテストプロセス開始前の段階で削減可能な不要なコストがかかっていました。 さらに、この方法を複数のテストケースで同様に行っていたため、時間とリソースが無駄に消費されていました。 そこで、テスト開始前に会社が1社のエリアを特定し、そのうえでテストを行う処理を追加することでこの問題を解決しました。 取り組み3 - ジョブの最適化 4項目のテスト観点に対して、それぞれ1ジョブずつ合計4ジョブで実行していました。 ページを開いた際のHTTPステータスコード200の検証については、各3ジョブに分割し、主要な導線の確認は、UIテストとDOM操作によるテストの各2ジョブに分割しました。 これにより、全体で10ジョブとすることで1ジョブあたりの実行時間が削減され、全体の実行時間を削減しました。 一方で、ジョブが増えることでSlack通知が増えるという懸念もありました。 ジョブ1つにつき1つのメッセージがSlackチャンネルに投稿されていたため、自動テスト実行1回につき4つのメッセージが投稿されていましたが、これが10個になると情報を見逃してしまうリスクもありました。 そこで通知を改善しました。方法は以下の通りです。 CodeBuildのDOWNLOAD_SOURCEビルドフェーズ（テスト開始前にソースコードを取得するフェーズ）開始時に親メッセージを投稿する 各ジョブ終了時にそのメッセージのスレッドに返信を行う 失敗の場合はSlackの機能を用いて返信をチャンネルにも投稿する すべてのジョブが終了したら親メッセージを完了を示した文言で上書きする これにより、Slackチャンネルに流れるメッセージの数は減りつつも、自動テストの終了と失敗を見逃さないようなしくみにしました。 取り組み4 - 実行の並列化 1ジョブあたりの実行時間をさらに削減するために実行の並列化を行いました。 TestCafeの並列機能を使用して、複数のインスタンスを起動し、これらのインスタンス間でテストの作業負荷を分担することで実行時間を削減しました。 取り組み5 - タイムアウト設定 予期しない理由でビルドが途中停止してしまった際に60分経過するまで失敗通知が送信されないという問題がありました。 これはCodeBuildのタイムアウト設定を行っていなかったためです。 CodeBuildには設定した時間内にビルドが完了していない場合にビルドを停止する機能がありますが、何も設定していない場合はデフォルトで60分に設定されます。 タイムアウトを20分に設定することで、失敗が発生した場合でも迅速に結果を把握できるようにしました。 これにより、CodeBuildの実行にかかった時間に基づいた課金が軽減され、コストカットにもつながりました。 結果 取り組みの結果は以下の通りです。 実行時間には多少のばらつきがありますが、おおむね一定の時間で完了します。 実行時間を大幅に削減でき、高速化を実現しました。 また、E2EテストにかかるCodeBuildの月々のコストも約100ドルから約50ドルへと削減できました。 全体 改善前：31分0秒 改善後：11分45秒 Botでページを開いた際のHTTPステータスコード200の検証 改善前：13分23秒 改善後：7分59秒 モバイル端末でページを開いた際のHTTPステータスコード200の検証 改善前：13分53秒 改善後：8分2秒 PC端末での主要導線の確認 改善前：29分56秒 改善後：5分53秒 モバイル端末での主要導線の確認 改善前：20分6秒 改善後：5分39秒 まとめ 売却査定サービスにおけるE2Eテスト高速化の取り組みについて紹介しました。 最後に、LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの小林です。 LIFULLで社内ABテスト基盤を開発しています。その開発の中で社内の生成AI基盤「keelai」を活用した取り組みを紹介します。 www.lifull.blog LIFULLではkeelaiという社内向けの生成AI基盤プロジェクトを運用しており、今回はこのkeelaiを利用したコードレビュー用のGitHub Actionsを実装した事例を紹介します。 www.lifull.blog 内製AI Agentによるコードレビュー GitHub Actionsを活用して実現したAIレビューのワークフローは以下の通りです。 コードレビューの概要 GPTやClaudeなどのAPIを利用せず、内製AI Agent「keelai」を活用した理由は以下のとおりです。 社内固有の知識を活用可能 - 社内ドメイン知識を持ったレビューが可能です 継続的な改善サイクル - レビューActionsとAI基盤の両方を社内で改良できます 柔軟なモデル選択 - 用途に応じて複数のAIモデルを使い分けるなど高度なカスタマイズが可能です 以上の点から、内製のAI Agentを利用することに価値があると思っています。 keelaiは社内向けアプリケーションとしてSlack botとしての利用と各システムからAPIとして呼び出せる2つのインタフェースを提供しています。 今回の記事では、GitHub ActionsからAPIとして呼び出して活用する方法に焦点を当てています。 弊社ではkeelaiを中心にして、社内ドキュメント参照機能や営業支援など幅広い活用を進めています。 この社内エコシステムと各種モデルの進化を組み合わせることで、LIFULLの技術スタックやドメイン知識に最適化されたレビューを期待しています。 keelaiについての詳細は以下を御覧ください。 www.lifull.blog 開発の背景 端的に述べると「 人が足りなかった 」からです。 当時所属しているチームの開発を行いながら、サブタスクとしてABテスト基盤のデモ実装を行っていました。 同期エンジニア3名でフロントエンド、バックエンド、集計バッチの3領域を得意分野で分担実装していましたが、以下の課題がありました。 本業務の合間を縫っての開発作業 チームメンバーの得意分野が異なるため、不得意分野のレビューに時間を要する すべての変更を人間が詳細にレビューする時間的余裕がない そこで、生成AIを使って最低限の品質維持のヒントになるようなレビューをできないかと考えました。 2024年秋ごろから話題になっていたCode Rabbitという生成AIレビューのSaaSを個人開発で利用していたこともあり、技術的な好奇心からも実装に踏み切りました。 実装プロセス 2024年3月時点でGitHub ActionsからkeelaiのAPIを呼び出せる環境が整備されていました。 当時所属していたチームで簡単な実験を行いました。 サンプルコードのレビュー実験 しかし先述した通り、個人的にCodeRabbitを利用していたため物足りなさを感じていました。 CodeRabbitの特徴としては以下の点が挙げられます。 日本語によるレビューコメント コード内インラインコメント機能 ただのコメントで複数のレビューが並べられてしまうと、どのファイル・どの行に対するレビューコメントなのかが追いづらくなってしまいます。 そのため、インラインコメントでレビューが返ってくることは被レビュー者にとって大きなメリットです。 そこでOSSを利用して手早く高機能なレビュー機能を用意することにしました。 Code Rabbitが旧バージョンのAIレビューシステムを ai-pr-revewer としてMITライセンスで公開していたため、これをフォークしてkeelai対応版として再構築しました。 keelaiは社内からの利用を前提とした認証になっています。 そのため、エンドポイントとAPI Keyの組み合わせでは利用できず、認証を含むクライアントを自作して差し替え、社内リポジトリで利用できるActionsとしてリリースしました。 社内普及まで 2024年8月にリリースを行い、ABテスト基盤チームの中で利用を開始しましたが、この時はまだgpt-4oがリリースされたばかりのころでした。 micro serviceが大量に存在する弊社全体での利用はコスト面でまだ現実的ではないとして数個のリポジトリで利用されるにとどまりました。 しかし、2025年2月にgpt-o3-miniがリリースされ、安い！賢い！早い！の3拍子であったため、弊社のkubernetes基盤KEEL用CLIであるkeelctlで全社配布することになりました。 keelctlについては以下を参照ください。 www.lifull.blog 機能 現状 PR要約 PRの内容を要約することで、レビュー者の認知負荷を下げます。 PRの要約 インラインレビューコメント コード内の該当箇所に直接コメントを付与し、メンションを付けて返信するとチャット形式で対話可能です。 インラインレビューコメント 社内の評価 実際の運用から得られた評価をいくつか紹介します。 指摘内容：タイムアウト実装の漏れ 「リリース後の運用中に発生した障害で気付くことが多いものなので助かりました」 指摘内容：200レスポンス処理の重複 「人間が指摘するときは手間な気分になるので機械的に指摘してもらえた方が楽」 指摘内容：Goの型キャスト 「Goでinterface型の変数をキャストして利用する際の注意点を指摘してくれました。Goに慣れてない人でも危険なコードに気付けるのが良いと思いました！」 今後の展望と課題 LIFULLにおけるAIコードレビューの実装までの流れと、現状の機能について紹介しました。 現在のシステムをさらに発展させるため、以下の機能拡張を計画しています。 リポジトリ固有のコーディング規約対応 各チームのスタイルガイドに沿ったレビューの実現 リポジトリごとの設定ファイルによるカスタマイズ 言語・フレームワークに特化したレビュー 各技術スタック特有の「ベストプラクティス」に基づく指摘 新しいバージョンのAPIや推奨パターンの提案 クロスファイル分析 複数ファイル間の整合性チェック アーキテクチャレベルの設計レビュー この記事ではAIによるコードレビューについて触れましたが、keelaiや関連プロダクトは社内コードがオープンであるため、新機能を思いついたらすばやく拡張できる環境にあります。 KEELチーム（プラットフォーム）、keelaiチーム、プロダクトチームの有志が一緒になって自分たちのニーズを考え、既存コードを活かして最小限の修正で対応可能な環境が整っています。 最後に、LIFULLではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

2024 年中途入社の福原です。 私の所属しているグループでは、毎週チーム全員で時間を設けて、メインとなるページのサイトパフォーマンスを監視・改善する活動を行っています。 今回はその活動の一環で、新築分譲戸建の物件詳細ページの LCP について、改善を行った結果を共有します。 LCP は、ビューポート内に表示される最大の画像、テキスト ブロック、または動画のレンダリング時間 課題特定 まずは Chrome の Lighthouse を使って計測し、数値の劣化原因を探りました。 指摘の中で最も影響が大きそうだったのは「適切なサイズの画像を使用していない」という点でした。 今回のページでは、カルーセル内に比較的大きい画像とサムネイル用の小さい画像を表示しています。 適切な画像サイズに修正することで、大きな効果が得られると考えました。 改善内容 適切な画像サイズの指定 LIFULL HOME'S には画像を適切なサイズに圧縮したり、WebP 形式に自動変換するしくみがありますが、 今回の対象ページでは使用されていませんでした。 www.LIFULL.blog 修正内容としては変数名の変更だけでしたが、それぞれに適切なサイズの画像を読み込むようになりました。 preload の削減 LCP の改善策として頻出する「 preload 」ですが、カルーセル内のすべての画像を優先的に読み込んでいたため、逆にページの初期表示が遅くなるケースがありました。 preload は 要素の rel 属性の値で、その HTML の の中で読み取りリクエストを宣言し、ページのライフサイクルの早期の、ブラウザーの主なレンダリング機構が起動する前に読み取りを始めたい、すぐに必要なリソースを指定することができます。 物件によっては 30 ～ 40 枚という大量の画像が表示されることもあるため、 優先して読み込むのは LCP の対象となる画像のみに絞ることにしました。 結果 今回の対応により、LCP が約 42%改善しました。 データ可視化ツールの Grafana で LCP を確認すると、ガクッと下がっていることがわかります www.LIFULL.blog 実際の画面を見ても画像の表示が速くなったと体感できるレベルでした。 まとめ 今回紹介した事例は、すでに提供されていた画像最適化に合わせたことが大きな改善要因のため、負債解消の意味合いが強いと感じています。 サイトパフォーマンスの改善はまだまだ継続していく予定のため、 次回は再現性のある事例を紹介できるよう、日々の業務に努めてまいります。 LIFULL ではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの高詰です。 LIFULLでは新卒入社2年目のエンジニアを対象にしたSET研修が開催されます。 SET研修は2年目の若手エンジニアが中心となりプロダクトをスクラッチから自分の手で開発することでWebエンジニアとしてステップアップすることを目的としています。 この記事では、研修での取り組みや研修中に直面した問題や学びについて紹介します。 SET研修とは 個人の目標設定 作成するサービスの検討 サービスの設計および実装 アプリケーション インフラ デプロイ 実装期間中のプロジェクト進行 実装期間を終えての反省点 学び 終わりに SET研修とは SET(Sophomore Engineers Training)は新卒2年目のエンジニア3〜4人チームでAWSや外部サービスを利用し、16営業日内に1つのプロダクトを作る研修です。期間及び予算は決まっていますが、それ以外はすべてチーム内で決める必要があります。 研修中のサポートは先輩エンジニアがメンターとなり開発相談やコードレビューを行います。他にも社内に数人いるベテランのスペシャリストエンジニアにいつでも相談できるようになっています。 SETは下記を目的として毎年行われています。 プロダクトを作る全段階を経験することでwebサービスの全体像を把握し、エンジニアとしての引き出しを増やす 業務では携わる機会がなかった分野に触れて幅広い能力を身につける 自分の苦手分野を正しく認識し、スキルセットのバランスを整える サポートメンバーのフォローを受けつつ、プロのエンジニアとしての知識を効率よく得る 研修の全体の流れは下記になっています。また、第一実装期間および第二実装期間は通常業務から外してもらえるので開発に集中できます。 個人の目標設定 作成するサービスの検討 サービスの全体設計 第一実装期間（8営業日） 第二実装期間（8営業日） 研修成果の社内発表 個人の目標設定 SET研修ではまず最初にメンバーそれぞれが研修を通して覚えたいことの目標を決めます。研修の目的に書いてある通り、通常業務では携わる機会がない分野や苦手な分野を中心に目標を設定することが推奨されています。 私の場合、通常バックエンドエンジニアとして既存のHOME'Sのプロダクトの改修や機能追加をメイン業務として行なっているので、個人目標には開発のベースとなる技術選定やインフラ部分に力を入れるような以下の項目を目標として設定しました。 技術選定及びインフラ設計の経験を積む デプロイの設定ができる サーバーの仕組みと設定が理解できる ミドルウェアを正しく実装できる 作成するサービスの検討 私たちのチームは交換日記サービスを選びました。 このテーマを選んだ理由としてはCRUDが満たせること、認証機能が必要であること、設計が複雑すぎないこと、メンバー全員の目標を満たせるテーマだったことです。 チームメンバーが3人いたので開発はそれぞれの個人目標を考慮し、インフラ及びサーバー担当、インフラ及びアプリケーション担当、アプリケーション担当の3つに分けました。私はインフラ及びサーバーを担当したので、開発期間前からサービス全体の設計の検討を行なっていました。 サービスの設計および実装 アプリケーション 今回開発したアプリケーションはMVC2パターンを採用しており、Expressを使用したモノリシックアーキテクチャで動作しています。 URLのルーティングに関してはDHH流のルーティングを参考にし、Controllerもそれに合わせて設計しました。 ModelはActiveRecordの考え方を参考にして開発しています。 View周りはPreactを採用しています。 今回はフロントエンド部分の開発を個人目標に入れているメンバーはいなかったので、View周りの設計やライブラリは最小限に抑えて他部分の開発により多くのリソースを割けるように調整しました。 データベースへのアクセスはTypeORMを利用することで型安全なデータ操作できるようにし、認証・認可には AWS Cognitoを活用してユーザー管理と認証を実装しました。また頻繁に必要になるデータはRedisを使ってアクセスすることでレスポンス速度を上げるように心がけてプロダクトを作りました。 インフラ AWS構成 インスタンスはシステム全体の管理のしやすさ及び再現性を担保するためCloudFormationを用いてリソースを構築しました。 サポートチームへ相談する際もgithub上でのコードを確認してもらうだけで済んだので効率よく開発を進めることができました。 設計面ではウェブサーバとアプリケーションサーバを分けることで、ウェブサーバのキャッシュ機能やプロキシ機能を使って効率よくリクエストをさばき、アプリケーションサーバに不要な負荷がかからないように注意しました。 静的ファイルはS3を使ってクライアントに返すことで高速化も図っています。 AWS CloudFrontを使う案もありましたが、時間の関係で今回は実装していません。 アプリケーションはDockerを使って開発していますが、勉強のためあえて便利なECSは使っていません。 ログ周りやインスタンスが落ちた際の設定、セキュアな環境変数の渡し方などの工夫が必要なEC2を用いてデプロイしました。 EC2で実行されているDockerが何らかの原因で止まってしまった時に再実行できるような設定や、CodeDeployなどのAWSサービスに対応できるように設定したAMIを作成し、インスタンスが落ちてしまった際も自動で早く立ち上がるための工夫もしています。 デプロイ 研修期間が短いので効率よく開発サイクルを回せるようにAWSのCode Pipelineを用いて自動デプロイを実現しました。 EC2を使っているためデプロイは以下の手順で進行します。 研修用に立ち上げたリポジトリにmainへのpushを検知すると自動的にコードをビルド ビルドに問題がなければECRへDockerイメージをプッシュ EC2インスタンスを新しく立ち上げ、Dockerイメージ及びAWS Secret Manager環境変数を取得し、イメージを実行 Blue/Greenデプロイで旧インスタンスと新インスタンスを入れ替える 上記手順に何か問題があった場合はデプロイ開始前のバージョンに切り戻す デプロイ結果はSlackに通知が届くように設定したので、研修中はコードの実装に集中できるようなりました。 実装期間中のプロジェクト進行 Github Projectの画面 プロジェクト進行のマネジメントはGithub Projectでやるべきことをissue化し、ガントを引いて管理しました。 実装期間前にひとり一人が担当する実装箇所や設計のすり合わせを行うことでスムーズに研修開始時と同時に開発を始めることができました。 実装期間中は毎日チームメンバーで10分ほどの朝礼を行いました。 前日の進捗及び当日やることについて報告を行うことで、何か困っているメンバーがいないかを確認し、期間中に終わらなさそうなものがあれば優先順位の変更を行い、メンバー全員の目標を満たしつつ最低限動くものを提出できるようにタスク調整しました。 また、第一実装期間と第二実装期間の間にメンバー内で振り返り会を行うことで開発中に起こった問題点を洗い出し、改善策を一緒に考えることで第二実装期間のタスクマネジメントをより良い方法で行えたと思います。 実装期間を終えての反省点 個人的な反省点は大まかに以下の3つです。 要件定義や画面構成の認識合わせが足りていなかった点があったので、詳細なところまで文章化するべきだった 何を決めるにしても明確な数字を出すべきだった タスク見積もりが甘く、思ったより時間がかかることが多かった ①に対しては口頭で話し合っていても各自のイメージが違っている可能性を考慮していなかったことです。 忘れることや記憶違い、認識違いが発生していたので実装開始前のサービスの検討のフェーズでメモだけではなく詳細にプロダクトのイメージを文章化すれば避けられた問題だと思いました。 ②については①の問題と関わってくるのですが、何か依頼する際には明確な数字を示さなかったことが原因でチーム内で問題が起きました。 「多め」や「なるはや」などの曖昧な言葉の解釈は人によって違うので、定量や日時を明確にした上で進めるべきでした。 ③に関してはお互いに初めて使うツールや設計で開発したので、開発期間で実際手を動かしてみると想定した以上に時間がかかることが多発しました。 タスク分割が大きいということに気づけないまま実装期間に進んでしまったので、極端に負担がかかり過ぎているメンバーが生じたり、期間内に終わらせることができないことが途中で発覚するなどの問題が起きました。 この問題についてはプロダクトマネジメントを経験しないとわからない部分だと思うので今回は大変貴重な勉強機会でした。 研修で問題点に気がつけたことで本業務ではもっと精度が高いスケジュールの見積もりができるようになると思います。 学び 本業務ではあまり携わる機会のなかったAWSの各種サービスを活用し、インフラ構築やデプロイフローの設計を経験することができました。 これによりWEBシステム全体の管理や運用、プロジェクト進行の経験と知識を身につけることができました。 また、普段の業務ではどれだけ整備された環境で開発しているのかを体感することができました。 結果としては最初に目標で設定していたことは研修を通してすべて達成できました。 開発のベースとなる部分の設計と実装を担っていたので、他のメンバーの実装に支障が出ないように速度と正確さを求められるポジションだったと感じました。 特に技術選定に関しては最後まで悩むことが多く、自身のアプリケーションの特性を深く理解した上で各技術のメリット・デメリットを考慮し、選択する必要があることを痛感しました。どんな技術を選んでもデメリットは必ずついてくるものなので、与えるインパクトを十分に理解した上で許容するのか、対策を考えるかなどのアクションが必要になってくると思います。 AIが発達し、自動でコードを生成してくれる今ではエンジニアは自分が作っているアプリケーションが持ちうるリスクを想定し、考慮した上で対処方法の設計できるかが大切なんだろうなと思った次第です。 終わりに この記事ではSET研修で取り組んだことや反省点と学びについて振り返りました。 周りについて行くことに必死だった1年目が終わり、ようやく自分が好きなことや興味があることが明確になってきた2年目のタイミングでSET研修に参加できたのは大変貴重な経験でした。 メンターとサポートチームに幾度も助けられながら大幅に成長できた２週間超でした。個人的には設計や実装に悩む時間を思う存分に楽しめたのでSETに参加して本当に良かったです。 一人前のエンジニアとして活躍できるようにこれからもインプットとアウトプットを重ねてスキルアップしていきたいです。 最後になりますが、LIFULLでは一緒に働く仲間を募集しております。よろしければぜひこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの市川と申します。 LIFULL HOME'S の売買領域の開発を担当しています。 さて、皆さんは普段からコードレビューをしているでしょうか。 私たちLIFULL HOME'Sのエンジニア組織では、他者のコードレビューを通過しないとリリースできないというルールを設けています。 そんな中、コードレビューがボトルネックになってしまったアプリケーションがあり、それを解決するために行った取り組みを3点紹介します。 課題 1. 昇格ルールの明文化 問題点: コードオーナーに求められるスキルレベルがわからない 解決策 2. 昇格状況の可視化 問題点: 昇格プロセスの進捗が不明確 解決策 3. 昇格課題の用意 問題点: レビュー経験を積む機会が少ない 解決策 まとめ 最後に 課題 今回対象としたのは、近年基盤を刷新したアプリケーションのコードレビューです。 www.lifull.blog リプレイスによってアーキテクチャや言語、フレームワークが刷新されたことで、開発しやすくなりました。しかし、設計思想を深く理解しレビューできるメンバーが限られてしまいました。 初期段階では開発メンバーが少なく、レビューの頻度も低く問題になることはありませんでした。しかし、開発案件の増加や組織拡大に伴い、レビュー待ちのプルリクエストが目立つようになってきました。 また、弊社でも GitHubのコードオーナー機能 を利用しており、重要なビジネスロジックを追加・変更するような箇所についてはコードオーナーによるレビューを必須化することで品質を管理しています。 したがって、人数を増やせば良いというわけではなく、人数と質の両面のバランスを考慮した対策が必要になりました。 ここからは、メンバーがコードオーナーに昇格するまでのプロセスの見直しと改善について説明します。 1. 昇格ルールの明文化 問題点: コードオーナーに求められるスキルレベルがわからない まず、どのような状態になればコードオーナーになれるのかが不明確でした。 これまで初期の実装に関わったエンジニアをそのままコードオーナーとしていたため、明文化する機会がありませんでした。 解決策 現コードオーナーと開発リーダー間で議論し昇格ルールを作成しました。 そしてその昇格ルールを、開発しているGithubリポジトリのドキュメントに追加しました。 コードオーナーに求められるのは「実装能力」 だけでなく、「設計思想から逸脱した実装を見逃さず指摘できる能力」 です。その点を満たしているかを確認できるプロセスにしました。 昇格ルール（一部） 結果、いつでも確認できる場所に昇格ルールがあることで、昇格候補者にとって目指すべきゴールが明確になりました。 2. 昇格状況の可視化 問題点: 昇格プロセスの進捗が不明確 次に、現状自分や周囲が昇格プロセスの中でどの段階にいるのかが不明確でした。 そのため、あとどの領域のレビューを何回経験したら良いかがわからず、ネクストアクションが立てづらい状態でした。 解決策 現状自分がどの段階にいるのかを可視化するため、昇格状況のチェックリストを作成しました。 下記のように、各自の状況を一覧にした表を作成しました。 コードオーナー昇格に向けたチェックリスト 私の担当するアプリケーションでは、クリーンアーキテクチャやDDDといった手法を採用しているため、それらの経験を積むことが重要です。 また、LIFULL HOME'Sの知識もドメイン知識として必要ですので、項目に入れています。 導入してみた結果、自身に必要な経験やスキル不足が明確になっただけでなく、誰にどのレビュー案件を担当させるべきか、管理側としても判断しやすくなりました。 3. 昇格課題の用意 問題点: レビュー経験を積む機会が少ない ルールの明文化と自身の現状が可視化されたため、あとはレビュー経験を積むだけです。 しかし、都合よくレビュー依頼が来るとは限らないため、待っているだけではレビュー経験を積むのに時間がかかりすぎます。 解決策 レビューの経験を積むという観点では、対象が新規実装である必要はありません。そのため、リリース済みのプルリクエストの中から学びの多そうなものを選定し、それらをレビューの課題として再利用することにしました。 再利用したいプルリクエストの番号と、レビューコメントの直前のコミットハッシュさえわかれば、当時のプルリクエストと同じものを作成できるスクリプトを用意しました。 # 引数でPR番号とレビューを始める前のコミットハッシュを受け取る PR_NUMBER = $1 END_COMMIT_HASH = $2 # 一時ディレクトリを作成し、そこにクローン TMP_DIR = $( mktemp -d ) git clone $REPO_URL $TMP_DIR cd $TMP_DIR # PRの最初のコミットハッシュを取得します FIRST_COMMIT_HASH = $( gh pr view $PR_NUMBER --json commits --jq ' .commits[0].oid ' ) # 親のコミットハッシュを取得します PARENT_COMMIT_HASH = $( git rev-parse ${FIRST_COMMIT_HASH} ^ ) # 日時をフォーマットします（例: YYYYMMDDHHMMSS） TIMESTAMP = $( date + " %Y%m%d%H%M%S " ) # ベースブランチと子ブランチの名前を作成 BASE_BRANCH = " practice-base- ${TIMESTAMP} " CHILD_BRANCH = " practice-child- ${TIMESTAMP} " # ベースブランチを作成してプッシュ git checkout -b $BASE_BRANCH $PARENT_COMMIT_HASH git push origin $BASE_BRANCH # 子ブランチを作成してプッシュ git checkout -b $CHILD_BRANCH $END_COMMIT_HASH git push origin $CHILD_BRANCH # 新しいPRを作成 gh pr create --base $BASE_BRANCH --head $CHILD_BRANCH --draft --title " Practice PR ${TIMESTAMP} " --body " This is a practice PR. Based on PR # ${PR_NUMBER} . " こちらを昇格課題として利用し、コードオーナーがピアレビューを行うことで、昇格候補者が経験を積むことができます。 結果、事業状況により改修案件の頻度や粒度が異なる中で、昇格候補者が均等に経験を積める環境を整えられました。 また、「中規模以上のレビューを経験する」というルールにしても定義が難しいですが、コードオーナーが選定したプルリクエストを使うことで問題は解決されます。 まとめ 今回は、設計やコードの品質を保ちながら開発スピードを維持するための、コードオーナー増員の取り組みを紹介しました。 このしくみを活用して昇格課題に取り組み、私は先日コードオーナーに昇格しました。 また、もう1名昇格間近な若手メンバーがいます。 年次や役職によって役割を与えるのではなく、明確な道筋を整えて若手でもコードオーナーを目指せるようにしたいと考えています。 そして、このようなしくみはコードオーナーだけでなくレビュアー育成にも応用できると考えています。 最後に 最近ではAIによるコードレビューの精度も高くなり、そのうち人によるレビューがほぼ不要になるかもしれません。 そうなればレビューする機会が減るだけでなく開発者が実装に集中する時間が増えるので、より開発サイクルが早くなりそうですね。 最後に、ともに開発フロー改善に取り組んでくださる仲間を募集しています。 hrmos.co hrmos.co

こんにちは！LIFULLクリエイターの日運営委員のホです。 社内のモノづくりイベント『創民祭』が開催されましたので、その様子を共有させていただきます。 創民祭とは？ 創民祭（そうみんさい）とは、業務や「クリエイターの日」、プライベートで創った物など、LIFULL社員が作ったプロダクトをお酒を飲み、ピザ・寿司を食べながらお披露目するイベントです。近年はWebに限らず、VRやイラスト等、多種多様なプロダクトが展示されています。今回はブース出展とLT（ライトニングトーク）の２本だてで開催いたしました！ 前回の様子はこちら https://www.lifull.blog/entry/2024/03/18/170000 展示内容 前回同様、Webに限らずいろんなプロダクトが展示されました。以下に展示内容をご紹介します。 ここでは選抜された受賞２作品を紹介していきます。 ChatGPTと作った生活管理アプリ こちらのアプリは成果生活習慣を管理するアプリです。現代社会において生活を乱す一番の要因はスマホでしょう。スマートフォンの使用の管理＆身につけたい習慣を達成できた日を可視化することで利用者により良い習慣を持たせることが可能なアプリです。開発では画面設計をしスクリーンショットをChatGPTに渡しただけでほぼ全て作ってくれたそうです。 iOS VoiceOver対応 VoiceOver機能を使ってお気に入り画面で以下の機能を提供できました。 物件カードの内容が読み上げられる ボタンの位置が見えなくても、VoiceOverを頼りにお気に入りボタンやチェックボタンをタップした時と同じ操作ができる VoiceOverはアプリのアクセシビリティを向上する上で欠かせない機能ですが、HOME'Sアプリではほぼ対応されていないのが現状でした。そこでVoiceOverについて学習し、実際に対応することでアプリのアクセシビリティ向上へ向けて動き出せました。 ライトニングトーク ライトニングトーク（LT）は3～5分程度の短い時間で発表するプレゼンテーションで、今回の創民祭でも実施されました！ 世界のA/Bテスト基盤 こちらは社内のA/Bテスト基盤の担当の方に世界のA/Bテスト基盤の主流や動向について共有させてもらいました。 ChatGPTで作る生活管理アプリ ブース出展の担当者 から作った背景や今まで使った生活管理アプリについて共有させてもらいました。 keelaiでチームのどこを効率化できる こちらはLIFULL内製のAIツールであるkeelaiについて簡単な紹介と事例について共有させてもらいました。社内情報検索効率化や定型作業の自動化の事例を紹介いただきました。 最後に 創民祭、その一部をちょっとだけお伝えしました！ そんなLIFULLでは、一緒に働くメンバーを募集中！新卒も中途も絶賛採用中です。ご応募お待ちしてますので、ぜひみてください！ hrmos.co hrmos.co

こんにちは、LIFULLでシニアエンジニアをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにて、マネジメントをしています。好きなE2EライブラリはPlaywrightです。 今回は、LIFULLで取り組んでいるリリース承認の仕組みを変更し、自動化を図った取り組みについてお伝えします。 はじめに 皆さんは、普段の開発フローを一度俯瞰してみたことはあるでしょうか？ 開発からリリースまでを通して見直してみると、思いがけないフローがボトルネックになっていることはありませんか？ 普段やっている決まった手順が「会社の規定だから」「昔からやってきた習慣だから」と、そのまま受け継いでいるプロセスほど、意外な手間やムダが潜んでいるものです。 そこで今回は、LIFULLにおける課題感を踏まえつつ、私たちが開発フロー全体を見返す中で明らかになったリリースフローの課題に注目し、我々がサイクルタイム改善に向けてどのように手順の変更、自動化へ向けて改善を行ったのかを紹介します。ご自身やチームのリリースプロセスを見直すきっかけになれば幸いです。 前提の説明 まず、変更前のLIFULLのリリースフローについて簡単に紹介します。 リリースフローの流れ 開発者はレビューやテストなどすべての手続きを終えたタイミングでチケットを作成し、そこからリリース承認を依頼します。 リリースには上長の承認とPJ管理者の承認が必要です。 承認されたチケットをリリーサーが最終確認し、開発者以外の視点で内容をチェックしてリリースを行います。 JIRAでのチケット管理 開発、レビュー、デザインチェック、テストなど全作業工程をJIRAで管理していました。 開発者はGitHubとJIRAの両方を併用していた形です。 適用前のリリースフロー 開発フローの変更にどう踏み切ったか 我々はサイクルタイムを加速させるべく、VSM（バリューストリームマッピング）で普段の開発フローを客観的に可視化しました。すると、開発終了からリリースまでの間に時間がかかっていることが分かったのです。 バリューストリームマッピングの結果 リリースチケットの課題 リリース承認時に作成していたリリースチケットには、リリース対象のPRのURLしか記載されておらず、テストやデザインチェックの状況など、関連するチケットへ遷移できる情報がありませんでした。 PJ承認を行う企画チームはGitHubのアカウントを持っていなかったため、実際にリリースされるパッケージが何なのか分からない状態に陥っていました。 手作業確認の負担 承認者はリリースに必要な情報を、チケットやPR、時にはSlackをたどりながら、目視で確認しなければなりませんでした。そのためチェックに大きな手間と時間がかかっていました。 余計な業務の発生 弊社ではリリースチェックをリリースチケットに記載する運用を行っており、チケットに不備があった場合、リリーサーが開発者へリマインドしていました。 さらに、実際のリリースはGitHubで行うものの、確認はチケットで行うなど状況がチグハグでした。 リリーサーは当日のリリース対象PRすべてについて上記作業を行う必要があり、非常に時間と手間がかかっていました。 解決策とその効果 これらの問題を解決するために、私たちはリリースに関わる一連の作業をGitHubへ集約することにしました。 実施したこと チケットを廃止し、すべての情報をPRとIssueにより管理 リリースチケットを廃止し、GitHubに集約することで、リリースに関係する情報がすべてPR上で確認できるようになりました。 PR作成時に自動的に関連Issueが作成され、リリースに必要なテスト仕様書などのプロジェクト管理のものをまとめてタスク化でき、開発者の手順漏れがなくなりました。 今までサービス企画職(PJ承認者)はGitHubアカウントを持っていないため、リリースパッケージが何かわからない状況でリリースすることになっていましたが、集約に伴い作成していただき、すべての情報が開示できる状態になりました。 GitHub Actionsを使ってリリースに必要な情報のチェックを自動化 自動的にチェックをしてくれることで、開発者はリリースに必要な情報やコメントがそろっているかを事前に確認したうえで、承認者へ確認を依頼可能に。承認者のチェックに要する時間が減りました。 正しい承認者からの承認であることを、GitHub ActionsとGitHubのチームを用いて検証を行い、権限のある人からの承認であることを担保できるようになりました。 Issue側に用意したタスクがすべて完了しているかもCIで担保できるので、承認者は開発者が手順にのっとって開発をしていたことが一目で分かります。 GitHub Actionsにより定刻チェックを自動的に実施し、不備があれば開発者へ連絡できるようになりました。そのため、リリーサーの作業が大幅に削減されました。 具体的には、CIで一部の人間が行う確認を自動化し、人間の思考に頼る部分を最小化するフローに変更しています。 GitHub集約後のリリースフロー 承認者やリリーサーは、作業やチェックに責任が伴うので、作業量以上に心理的な労力を要します。特に、情報が一ヵ所に集約されていないと、必要な情報をたどるだけでも予想以上に時間を費やしてしまいます。しかし今回の変更により、その一部を機械的に事前確認できるようになり、心理的ハードルを下げられました。 その結果、2024年10月時点と比較して、リリースまでのリードタイムの中央値と平均値に効果が現れ始めました。特にリリース中央値はもともと50時間ほどかかっていたものが安定して20時間台にまで削減されています。 リードタイム可視化 また、リリース回数についても2024年10月から2025年2月末までの結果を見るとリリース回数が純増できました。 リリースデプロイ回数 リードタイムの平均値は休日を挟むリリースパッケージが多くなると待機時間が増えがちになり、まばらな結果になりますが、さらなる開発の数が増えれば改善がよく見えるようになると想定されています。 まだまだ、改善点や指標の取り方に変更が必要ですので、さらにアップデートを行う予定です。 解決に対して考えることと注意点 このような大規模な開発フローの改善を行う場合には、現行の開発フローがどういう意図で作成されているのかを一つ一つ 紐解き、フローにおける最大要求と最低限の担保方法を洗い出す必要があります。 特に、社内事情には十分に注意しつつ調整しましょう。 我々も、手始めにこのフローを実現するにあたって、社内の有識者への担保事項やフロー変更に基づく注意点の確認やものづくりを行うすべてのメンバーへの事情説明を行った上で理解を得て進めています。 こういった会社の常識を変える時には常に守破離を意識して丁寧に実施しましょう。 今後の展望 今回のリリースフローの改変によって、GitHubへの集約を実現し、リリースを加速する基盤を整えることができました。次の段階としては、ここで得られた自動化の基盤を活用し、リリーサーを不要にするリリースの自動化へと進める計画です。今後さらにリリースを高速化し、サイクルタイムを短縮していきたいと考えています。 終わりに 私たちは「価値創造を加速させ続ける」ことをビジョンの一部に掲げ、その実現に向けて開発フローの可視化と数値化に取り組んできました。今回メスを入れたのはリリースフローでしたが、実際にはほかにも多くの課題が隠れているはずです。 「しかたがない」と思っているポイントこそ、変化の余地があるかもしれません。 開発フローにおけるそれぞれの構成要素をあらためて見直し、最低要件を確認してみることで思わぬ改善の糸口が見つかる可能性があります。 今後も一歩ずつ改善を積み上げることで、リリースのさらなる加速化につなげていければと思います。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、LIFULL HOME'S事業本部CSユニットサービス開発グループの吉田です。 先日、社内ゼミ（勉強会）にて、障害対応時の心構えと障害対応訓練について共有しました。 このゼミは、プロダクトの開発・運用に関わるメンバーが抱える「もしシステム障害が起きたら、どのように対処すればよいのだろう？」という不安を解消し、適切な対応方法を学ぶ機会として開催したものです。 長年稼働しているシステムで有識者が少ない中、いくつかの障害を乗り越えてきた私たちチームの経験に基づいた障害対応について紹介します。 全体の理解を深めていただくために、本ブログは前編・後編の2つに分かれています。 まずは障害対応についての基礎知識や心得をお話した前編をお届けします。 障害対応はなぜ重要か 障害対応は初動が大事 障害対応の初動をスムーズに進めるための4つの心得 1. 体制をつくる 2. 情報をオープンな場に集約する 3. 適切なコミュニケーション 4. ステークホルダーへの連携 まとめ 障害対応はなぜ重要か プロダクト開発において障害は、ユーザー体験やサービス品質に大きな影響を与える重要な課題です。 障害をゼロにすることは理想的な目標ではあるものの、現実的には避けられません。 では、なぜ障害対応は重要なのでしょうか。私たちが考える以下の3つのポイントを改めて伝えました。 第一に「顧客満足度の向上と維持」です。 障害が発生し不利益を受けるのはサービスを利用しているユーザー、つまり私たちの顧客です。迅速にサービス復旧の対応をし、顧客不満を少しでも抑えることが必要不可欠となります。 次に「信頼の確保とブランドイメージ」の保護です。 障害時の対応が良ければ、顧客はその対応力を評価し、企業への信頼を深めます。個人ではなく、企業として適切に対応することが大切です。 最後に「成長と改善の機会」です。 障害対応のスキルはもちろんですが、起きたことを振り返り、同じ問題が再発しないように次につなげていくことで、組織としての知見も溜まりLIFULL全体の成長につながっていきます。 組織の成長の機会であると考え、前向きに取り組む姿勢も大切な観点となります。 障害対応の目的はシステムを直すことではなく、顧客への影響の低減・早期回復をすることです。 不具合の先に顧客がいることを忘れず、組織として適切に対応する必要があります。 ゼミでは他社事例も紹介しながら、障害が発生したときにどう対応するべきかを説明していきました。 障害対応は初動が大事 LIFULLでは障害対応のマニュアルがあり、基本的な対応フローや緊急度の判断フローが用意されています。 ※関連して、障害管理の詳細ついてはこちらの記事にも紹介していますので関心のある方はぜひご一読ください。 www.lifull.blog このゼミでは障害対応マニュアルに沿った基本的な対応フローを改めて紹介しました。検知・報告受領からふりかえりと再発防止策までの7ステップが障害対応の基本的な流れとなります。 この中でも障害対応はステップ1～5までの初動が非常に重要となります。 まずは影響を最小限に留めるために止血する（＝システムを正常に戻す）ところまでが時間との勝負です。 通常のPJよりも冷静かつ的確な対応を求められるので難易度も高くなります。 障害が起きると、つい原因を追求しがちですが、最初に把握するべきは顧客にどのような不具合が起きているか？です。 システム目線ではなく顧客目線での影響範囲の把握が重要となります。 また、サービス停止などを伴う大規模なシステム障害の際は、原因追求よりも早期復旧が最重要であることを意識しておく必要があります。 障害対応の初動をスムーズに進めるための4つの心得 障害対応を円滑に進めるために注意するべきことは何でしょうか。 わたしたちのチームが数々の障害を乗り越え、ふりかえりを実施してきた中で大事にしている4つのポイント（心得）があります。 1. 体制をつくる 特に大規模な障害対応では、明確な役割分担が不可欠です。 障害発生時に迅速に対応チームを編成し、作業者と報告者、最終意思決定者などを区分けしていきます。最初に役割を決めて明確にすることで各メンバーが自分の役割に専念し、全体の対応スピードをを高めることができます。 TODOを整理してタイムラインを決めると、より効率的に対応できるようになります。 統制役がいないと各自がバラバラに動いてしまうので、緊急度の判断がうまくできず、結果、対応に時間がかかったりしてしまいます。 障害対応はサービス目線での判断や広報も必要になるため、企画とエンジニアがワンチームとなって対応していくことが重要です。 2. 情報をオープンな場に集約する 情報の透明性を保ち、一元化することが鍵です。 LIFULLではSlackを利用していますが、影響範囲の広い障害発生時には専用のSlackチャンネルを作成し、全関係者がリアルタイムで最新情報にアクセスできるようにします。 障害の緊急度合いや影響範囲などの情報を集中的に管理して、どのメンバーもすぐに情報をキャッチアップできる状態を作ることで、無駄なコミュニケーションコストを削減します。 一部の人だけが知っている状態を避けるためにも、情報はできるだけオープンな場でひとつに集約することが大切です。 3. 適切なコミュニケーション 障害対応は時間との戦いであり、都度の状況変化を適時に共有することが求められます。 定期的に状況を共有することで、情報伝達の遅延を防ぎます。 そのため誰でも発言しやすいような雰囲気作りも重要となります。 障害対応は焦りや不安から思考がネガティブになりがちですし、普段よりも判断力が落ちることが発生しやすいです。 前向きに障害対応に向き合えるマインドを保つためにポジティブワードを発信することを心がけながら、気軽に相談できる雰囲気づくりを意識しています。 また、テキストコミュニケーションは負荷も高くなるため、Slackのハドルミーティングも積極的に活用するようにしています。 職種間コミュニケーションにおける注意点としては、「サービス目線で話す・聞くことを心がける」です。 不具合の調査や復旧にあたるエンジニアはシステム目線でプロダクトの対応にあたります。 企画はエンジニアからの報告や相談をサービス目線で話し・聞くことで、ユーザーや顧客目線で何が重要か？の認識を揃えていくことができます。 私はエンジニアではなく企画職のため、特にこの視点は大切で、障害対応において意識しているポイントであることを話しました。 4. ステークホルダーへの連携 不具合が発生していることをステークホルダーへ共有することは重要なポイントとなります。 影響を受けている顧客はもちろんですが、営業部門など直接顧客と接する社内ステークホルダーへの報告も忘れてはいけません。 迅速で的確な連携が、ステークホルダーからの信頼を維持するための鍵となります。特に、影響の大きい障害が発生した際には、障害検知の第一報を即座に関係者に知らせることが大切です。 広報や共有が後回しになっては、顧客だけでなく社内からの信頼を失うことに繋がりかねません。 まとめ 私たちのチームでは以上のことをチームメンバー全員が意識し、障害対応に取り組んできました。こうした体験や取り組みの紹介を通じて、組織全体の対応力の向上を目指していきたいと思います。 ゼミの参加者からも「障害対応について深く学びを得ました。」「障害対応の意義や意味について改めて認識することができた。」というような声をいただきました。 今回の学びが実務における障害対応に活かされることを期待しています。 私たちは常に顧客満足度の向上を目指しています。今後も積極的に対応力強化に取り組んでいき、サービスの質をさらに高めていきます。 後編は、実践編として、「障害対応訓練」についてご紹介予定です！お楽しみに。 最後に、LIFULLではともに成長していける仲間を募集しています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

グループデータ本部データサイエンスグループの嶋村です。 今回は 事業部門と研究開発部門が密に連携 して「おとり物件」と呼ばれる 社会課題の解決に挑んだ取り組み について紹介したいと思います。この記事では主に研究開発部門の視点での発信になりますが、事業部門の視点での発信もありますので、是非下記の記事もご覧いただけると嬉しいです。 note.com 物件鮮度向上のための取り組み 適用イメージと評価指標のすりあわせ データの収集と理解 精度向上に向けたアイデア出し 機械学習モデル作成のためのワークフロー整備 機械学習モデルの作成とチューニング おわりに 物件鮮度向上のための取り組み LIFULLが運営する日本最大級の不動産・住宅情報サービス「 LIFULL HOME'S 」では物件鮮度の向上を目指しており、過去の第三者機関による調査では 物件鮮度No.1を獲得 しました。物件広告の中には「 おとり物件 」と呼ばれる「既に募集終了したが掲載され続けている物件広告」や「実在しない架空物件の広告」が存在し、 物件鮮度を低下させる要因 となっています。LIFULLには 情報審査グループ という広告審査の専門部署があり、正しい情報を利用者の方に届けるために、日々物件鮮度を維持・向上させるための取り組みを続けています。 おとり物件を見つけることは容易ではなく、本施策の検討以前は、エンドユーザや不動産会社からの通報を受け、情報審査グループが募集中の物件広告かどうか電話確認をする方法が中心でした。通報前におとり物件を検知しようと調査スタッフによる人手での検知を試みましたが、人手のみの対応では網羅性が下がってしまう点と検知精度も低く、かつ検知できる物件数も増やせないという課題がありました。その課題に対する一つの取り組みとして、機械学習等のAI技術を活用して自社開発AIを作り、 自動でおとり物件を検知、そして自動非掲載する ことを目指す取り組みが始まりました。 今回の取り組みは研究開発部門が事業部門と 密に連携してデータサイエンス業務を丁寧に遂行 したという事例になります。取り組みを進めるにあたり、大小さまざまな障壁があり、それらを一つ一つ連携して解決していきました。事業部門もしくは研究開発部門だけでは解決が難しいこともあり、改めて同じゴールを目指して密に連携することの大切さを実感しました。その結果として、2025年1月9日より、『 自社開発AIによる「おとり物件」の検知・自動非掲載を開始 』することができました。 lifull.com 適用イメージと評価指標のすりあわせ まず、最初に重要だと感じたことは、おとり物件を自動で検知できたとして どのように業務に組み込むのか適用イメージのすりあわせ と、その適用イメージに合わせた 評価指標の設計 でした。初期段階では「AI技術（機械学習）を適用すると精度が劇的に向上するのではないか」という期待が事業部門にありましたが、その「 精度 」とは何かのすりあわせを丁寧にしていきました。 精度という用語は良く使われますが、その定義次第では目指すものが全く異なってしまいます。データサイエンスにおいて 有名な精度指標 としては、以下の2つがあり、それぞれは トレードオフの関係性 になります。 適合率 : おとり物件と予測した物件が実際におとり物件だった割合 再現率 : 真のおとり物件をどれだけおとり物件として検知できたかの割合 また、検知対象とする 母集団 をどのように捉えるのか、というすりあわせも重要だと感じました。初期段階では 全国の物件に対して再現率をどこまで高められるのか を試しており、人手よりも機械学習の方が再現率は向上していきました。ただ、どこまで続けると再現率が100%に近づくのか見通しを立てづらく、また地域毎に物件数が異なるため検知しやすい地域と検知しづらい地域にばらつきがあることもわかってきました。 そこで中盤以降は「 おとり物件を自動非掲載することを前提とし、確度高くおとり物件として検知できること 」を重視することに切り替えました。そして、対象の物件を 特定の地域に掲載されている物件 に絞り、 適合率を一定水準に維持 し、その上で再現率を向上させていこう、という方針にしました。この方針では、見逃し（False Negative、偽陰性）は増えてしまうのですが、誤検知（False Positive、偽陽性）が発生すると広告掲載している不動産会社に迷惑をおかけしてしまうため、適合率の維持を最重視しました。 データの収集と理解 機械学習を適用するにあたり、 学習データの収集がとても重要なプロセス であることは間違いありません。ここでは2つの面で苦労がありました。 既存のデータが学習データとして使いやすい形式ではなかったこと 学習データが少なかったこと 1について、従来はAI適用を前提とせず人手で電話確認をしていたため、電話確認した結果がスプレッドシートで記録されており、また記録形式も統一化されていませんでした。LIFULLではデータ基盤としてGoogle CloudのBigQueryを利用しているため、それらの既存データを 学習データとして活用しやすいように加工 してBigQueryへ格納するデータフローを作成しました。 2について、人手での電話調査で収集できる数が限られていました。そのため初期段階では少数データで試しながらも、学習データを増やすために継続して電話調査で学習データを収集しました。また、自社開発AIの精度が向上するにつれて、「 自社開発AIがおとり物件と検知した物件だけを電話調査した方が良いのではないか 」という議論もありましたが、 学習データに偏り（バイアス）が生じてしまう ため、 無作為に抽出した物件に対する電話調査も継続 し、バイアスの影響を軽減する方針にしました。 上記2点の対応をし、収集・蓄積された学習データの特性を理解するため、 探索的データ分析（EDA: Explanatory Data Analysis） を実施しました。BIツールやスプレッドシートで各カラムの分布を可視化し、おとり物件に寄与しうる特徴量は何か、ということを継続的に議論しました。可視化することで、事業部門でも気付いていない傾向を発見するなど、新たな学びにつながりました。 精度向上に向けたアイデア出し どのように精度を向上させるか、 事業部門と研究開発部門の視点 で、様々なアイデアを考えていきました。事業部門は事業ドメインに関する知識や経験が豊富であり、研究開発部門はデータサイエンスに関する知識や経験が豊富であるため、 お互いの視点で忌憚なく意見を出し合う ことが重要でした。 アイデアの中には「それは過学習につながってしまうのではないか」というアイデアや、「面白そうだけど現状の前提だと実現が難しいのではないか」というアイデアもありましたが、実際に試すことができるアイデアも蓄積されていきました。それらの中から、効果が見込めそうか、すぐに試せそうか、コストはどれくらいかかるか、という視点で優先度を付けていき、一つ一つ試していきました。 試してみてうまくいかないことも当然あったのですが、その際に「 うまくいかなかったという発見は妥当な結論なのか 」という視点を大事にしました。本来だとうまくいくはずなのに、実験方法が誤っている場合や、実験方法が不十分だった場合もありえます。そのため、結果も重要ですが、 プロセスや考察（論理的な結論付け）を重要視 しました。いくつものアイデアがあると、試すことを重視して駄目なら次へとなることもありますが、そこであえて立ち止まりじっくり思考を巡らせることも重要だと改めて感じました。 機械学習モデル作成のためのワークフロー整備 初期段階では 事業部門で非エンジニアが運用 できるようにと、Google Colaboratoryを使用して、学習や推論処理をしていました。ノートブック一つでWebで気軽に操作できるため、手作業は伴いましたが、定常的な処理や軽微な実験であれば十分対応できました。 一方、機械学習モデルの作成が本格化してくるとColaboratoryでは厳しく、中盤から ワークフロー整備 に取り掛かりました。事業部門での学習コストは大きくはなりますが、自社開発AIによる自動非掲載を実現するためには、避けては通れない道と考えました。今回はGoogle CloudのVertex AIを活用することで、学習パイプラインや推論パイプラインを作成し、 手動対応が半自動化されて検証速度が向上 し、効率的に様々な実験をできるようになりました。初期段階と比較すると、検証したモデル数が5倍程度と大幅増加したため、思いついたアイデアを迅速に試せるようになりました。 機械学習モデルの作成とチューニング 機械学習モデルはBigQuery ML・深層学習モデル・決定木モデルなど様々なモデルを試しました。学習処理や推論処理に要する コストと結果の解釈性などの観点 で使用するモデルを選定していきました。 精度向上のために試したこととして、まず、それまでに使っているデータ以外に 有用なデータが他にあるか調査 をしました。別データを追加することで効果的な場合もあれば、ノイズとなって逆効果となってしまう場合もありました。 次に、 特徴量（カラム）の加工 や、 特徴量の定義の見直し をしました。初期段階で暫定的に定義した特徴量もありましたので、改めてどのような定義が適切なのか考え、再定義をしました。また、 おとり物件検知について早稲田大学と共同研究を実施 しているのですが、 共同研究で得た知見 をもとに、特徴量を新規追加する試みもしました。 データの特徴として、 正例と負例の比率が不均衡なデータ だったため、正例であるおとり物件を検知しづらい難しさがありました。正例と負例の重みを変更する、アンダーサンプリングで負例を減らして正例と負例の比率を一定にする、といった工夫をしました。データ量は日が進むにつれて増えていき、正例と負例の比率も変化するため、 定期的に候補となる手法の副作用が大きくないか慎重に確認 し、適用する手法を選定していきました。 最後に、 ハイパーパラメータチューニング（パラメータ探索） を実施し、精度向上につながりました。初期段階からハイパーパラメータチューニングは試して効果はあったのですが、結果を可視化して深く考察しているとパラメータ探索の範囲や刻み幅が限定的で改善の余地がまだまだあることに気付きました。ハイパーパラメータチューニングは時間や計算処理コストを要するため、できれば手軽に済ませたい手法ではありますが、しっかりと結果を考察し、 どこまでパラメータ探索をするか見極めることが重要 だと感じました。 おわりに ここまで研究開発部門の視点で、 自社開発AIによる「おとり物件」検知・自動非掲載機能の実用化に向けた取り組み に、どう向かったのか紹介しました。 今回記載した内容は決して最先端の技術を使った訳ではなく、 データサイエンスの基本に沿って地道にAI技術を用いた検知の精度向上に向き合った という事例になります。しかし、一足飛びでの精度向上は難しく、丁寧にデータサイエンス業務を継続することで精度向上が実現できる、と改めて実感しました。また、そのためにも、研究開発部門だけでは気付けない視点も多々ありますので、 研究開発部門と事業部門との密な連携が必要不可欠 であることは間違いありません。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービスの研究開発」を加速して下さる シニアデータサイエンティスト（R&D） を募集しています。 興味を持っていただけた方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

こんにちは、事業基盤ユニットプラットフォームGの宮崎です。 LIFULL HOME’Sは昨年8月に「物件鮮度NO.1」を獲得しました。 今回はこのプロジェクトへのアプローチをエンジニア視点でふりかえってみます。 プロジェクトのきっかけ 背景 処理高速化のアプローチ 具体的な取り組み リポジトリの分離 専用のリードレプリカを作成 プログラムの実行頻度変更 PHPのバージョンアップ & OSのバージョンアップ s3 syncの同期方法変更 成果 物件情報の鮮度向上: 運用効率向上 まとめ プロジェクトのきっかけ 「SNSの投稿みたいに、入力された物件がリアルタイムに検索できればいいのに」 入社して間もない頃から入力された情報の反映を高速化したいと思っていました。 弊社の海外研修で、自部署の上長が情報審査部門の担当者と話す機会があったこともきっかけとなり、物件更新の高速化対応の検討が本格的に始まりました。 （弊社には海外研修制度があり、現地の文化や革新的な取り組みを学ぶことを目的に選抜メンバーが海外に派遣されます。） 物件情報更新の高速化によって、新規の賃貸物件情報がいち早く掲載されるのはもちろん、契約が決まった物件を非掲載にできます。 これは意図しない「おとり物件」を掲載にしないことに繋がります。 背景 今回高速化した該当のシステムは、長年稼働していたものの主な担当部署は明確には無く、細やかに管理されていませんでした。 また、表面的には問題なく稼働していたのもあり、データベースや外部環境の変化への対応などは優先度が低い状況が続いていました。 処理高速化のアプローチ 目指したのは反映スピードの高速化で、そのための手段は技術的には単純なことでした。 しかし、その高速化に必要な手段が持つリスクを洗い出した結果、そのリスク回避のためあらかじめ別の対応が必要となり、その対応のためにさらに別の対応が必要ということが芋づる式に分かってきました。 そこで、ユーザー視点での改善につなげることと合わせて、なかなか手を付けられていなかったシステム自体の改善にも取り組むことになりました。 具体的な取り組み リポジトリの分離 該当システムは歴史的な背景があり、別システムと同一リポジトリで管理されていました。 その結果としてリリースの手順が複雑であったり、別システムとの間で言語のバージョンが異なっていることで、思いも寄らないところで障害が起きたりといった問題が起きていました。 そこで該当部分のリポジトリを分離させ、設定ファイルの依存関係やリリースのフローをシンプル化しました。 その結果、他のシステムへの影響を抑えて障害のリスクを回避し、リリース負荷が下がったことでリリース頻度が向上しました。 高速化の後に不要コードの削除を行ったことで、調査コストも低減することができています。 専用のリードレプリカを作成 専用のリードレプリカを新たに作成し、接続先を変更しました。 これにより他のシステムのDB負荷をほとんど気にせずに高速化を行える状態になりました。 プログラムの実行頻度変更 できるだけ多くのプロセスが実行され続ける状態にするようにプログラムを改修したうえで、プログラムのトリガー頻度を1時間から20分に変更しました。 結果として情報の反映がより素早く行われるようになりました。 PHPのバージョンアップ & OSのバージョンアップ PHPのバージョンが5.6でOSがAmazonLinuxでした。PHPのバージョンを8.3に、OSをAmazonLinux 2023に変更して速度の検証をした結果、速度が向上したためバージョンアップを行いました。 バージョンアップによって、生成されるデータに変更が行われていないかを確認するためにデータの比較を再帰的に行うためのツールを開発しました。 詳細は 再帰的なツリーハッシュ | ドクセル という勉強会の資料を御覧ください。 実はPHPのバージョンアップを行ったことによりプロセスの処理が高速になり過ぎてしまい、リードレプリカのレプリカラグが悪化してしまったため、あえてプログラムを遅くしたりしています。 s3 syncの同期方法変更 物件データの生成後にデータをバケットBとバケットWという2つのS3 バケットに保存しているのですが「バケットへの同期が直列」、「バケットWはデータを削除せずに貯める」という特徴がある影響で、同期が非常に遅くなっていました。 そこで、バケットWへの同期をインスタンスからの s3 sync ではなく、バケットBからのS3 Replicationに変更しました。 その結果同期速度が10倍ほど高速化しました。 成果 物件情報の鮮度向上: 当初の目的通り、物件の反映時間が平均1時間41分から35分に短縮され、ユーザー体験の向上に繋がりました。 その後は不動産ポータルサイトとしても好評価をいただいています。 lifull.com lifull.com 運用効率向上 技術的負債解消になり、その後は以下のようなメリットがありました。 調査コストの削減 影響範囲が小さくなった リリース作業の自動化 リポジトリを分離したことで影響範囲が限定的になったため、リリースを比較的かんたんに自動化することができました。これにより業務効率が向上しました。 まとめ 単に高度な技術を追求するだけでなく、一つ一つの問題に丁寧に向き合う姿勢から、ユーザーに直結する価値を提供できた良い事例でした。 そして、根本的な見直しによってより良い開発環境を整えることができ、高速に効果的に開発が行える様になったと実感しています。 最後に、LIFULLではともに成長していける仲間を募集しています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

グループデータ本部データサイエンスグループの嶋村です。 先日、別の記事『 データ分析コンペ「第1回 国土交通省 地理空間情報データチャレンジ」への協賛の取り組み 』で、LIFULLがデータ分析コンペに 協賛企業として参画 しており、LIFULLの主力サービスの一つである LIFULL HOME’Sのデータセットを提供 していることをお伝えしました。 データ分析コンペは2024年10月15日（火）から2024年12月13日（金）までの約2ヶ月間で開催され、2025年1月31日（金）には G空間EXPO というイベントの中で表彰式が開催されました。 今回の記事ではデータ分析コンペや表彰式の様子をお伝えできればと思います。なお、表彰式の様子については、データ分析コンペを主催した 国土交通省でも発信 されておりますので、是非ご覧いただければと思います。 データ分析コンペでは、不動産の賃料を予測するモデルを構築する「 モデリング部門 」と、不動産市場の物件価値を高めるためのアイデアを提案する「 アイデア部門 」の2つが開催されました。 総参加者数は1,532名 で、 総投稿数は9,709件 と、たくさんの方々にご参加いただくことができました。 データ分析コンペ参加者の方々は専用のSlackチャンネルに参加することができ、運営側や参加者同士でコミュニケーションできる仕組みがありました。とても印象的だったのは、参加者同士は競い合う関係性であるものの、お互いに助け合い励まし合うコミュニケーションが多く、 利他精神にあふれている と感じたことでした。また、提供データに関する問い合わせもあり、 より使いやすいデータ にするためにはどのようにしたら良いか、と気付きを得られる貴重な場にもなりました。 表彰式にはとても多くの方が参加して下さり、改めて注目度の大きいデータ分析コンペだと感じ、 地理空間情報や国土数値情報への関心 が高まっている現れなのではないかと感じました。表彰式の冒頭挨拶で𠮷井大臣政務官が「国土数値情報を含む様々なデータを掛け合わせて 社会課題の解決に活用 して欲しい」という旨の発言をされていました。事業を通じて社会課題の解決を目指すソーシャルエンタープライズ（社会課題解決型企業）であるLIFULLとしても、今回のデータ分析コンペが社会課題の解決へのきっかけになれば嬉しい限りです。 表彰されていた方々は、データサイエンティストやエンジニアとして働く方、学生の方、と様々でした。表彰式の待合室の中で、今回のデータ分析コンペで特にどのあたりで苦労や工夫をしたか、という話もあり興味深かったです。2025年2月21日（金）に モデリング部門の上位入賞者から取り組み内容の解説や報告 をしていただく ふりかえりイベント が企画されていますので、是非ご参加下さい。 データ分析コンペ「第1回 国土交通省 地理空間情報データチャレンジ」表彰式の様子 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービスの研究開発」を加速して下さる シニアデータサイエンティストを募集 しています。 興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

こんにちは、テクノロジー本部の木村です。障害報告のデータによる障害傾向分析やレポーティングの取り組みについてご紹介します。 障害管理の改善を目指す方々に参考になれば幸いです。 障害報告の入力項目 集計項目とツール 障害発生率（当月の開発系起因の障害件数/当月のリリース件数） 検出時間・対応時間・復旧時間の月平均推移 想定損害金額 傾向分析 まとめ 障害管理の運用事例についての記事は以下をご覧ください。 www.lifull.blog LIFULLでは様々なサービスを開発していますが、主要サービスで発生した障害は発生から再発防止までの経緯を報告するルールが定着しています。 一つひとつの障害分析の情報はそれだけでも価値があるのですが、私たちは品質管理部門としてそれをさらに分析する取り組みを始めました。 情報をまとめて整理すれば障害の傾向やサービス横断での共通課題なども見えてくることがありますし、再発防止や改善に向けた大きな対策の必要性が見えてきたりもします。 障害報告の入力項目 分析に利用している障害報告の入力項目は以下のようなものがあります。 入力項目 入力形式 入力内容 障害の内容 テキスト形式 その時点でわかる範囲の障害の箇所・影響・対応予定など 検知時間 発生時間 解消時間 テキスト形式 おおよその日時 起票優先のため曖昧さを許容。 正確な時間は別項目として用意 主管部署・担当者 テキスト形式 障害対応の担当部署 原因 テキスト形式 原因となった変更内容・現象など 対象ユーザー 複数選択：エンドユーザー/クライアント/社内 影響を受けたユーザー 影響範囲 テキスト形式 影響を受けた時期・条件・データなど 起因工程 複数選択：基盤/開発・設計・テスト/運用/外部要因/その他 原因となった変更などの工程 起因となった変更内容 テキスト形式 変更チケットのURLなど 対応内容 テキスト形式 暫定対応・恒久対応の実施情報・予定など サイト・サービス停止時間 数値 停止に至った具体的な時間（分単位） 再発防止策 テキスト形式 再発させないための根本原因対応 集計項目とツール 集計に使用しているツールは以下のとおりです。 障害報告：JIRA 障害情報データ蓄積：BigQuery 可視化：スプレッドシート、LookerStudio 障害報告に入力されたデータはデイリーでBigQueryへ送り、集計内容に応じてスプレッドシートからアクセスして必要な形にして取得しています。 可視化ツールのLookerStudioではそのスプレッドシートの情報を参照していますので、前日の状態が自動でデータ反映されて可視化されます。 LookerStudioのダッシュボードでは様々な集計を行っていますが、例えば4keysの指標にもなっている障害発生率やMTTR（平均復旧時間）があります。 集計している項目をいくつか抜粋して紹介します。 障害発生率（当月の開発系起因の障害件数/当月のリリース件数） 当月の開発リリース件数（別集計）と、当月発生した開発系起因の障害件数から、障害発生率を算出しています。例えば外部環境が要因の障害などは集計対象に含めていません。 障害が発生した月で集計しているので過去から発生していた障害が新たに見つかった場合、過去の結果が変わることがあります。 報告月で集計した場合は、過去から発生していたものが今月の結果に影響するため、発生した月で集計することにしました。 障害が発生した月で集計すれば、その月にリリースされた件数と比較することで発生率として意味のある数値になります。 障害発生率ダッシュボード（データはダミーです） 検出時間・対応時間・復旧時間の月平均推移 障害の発生日時・検知日時・復旧日時から、検出・対応・復旧時間を算出しています。 サービスに大きな影響のある障害だけでなく軽微なものについても算出対象としました。 このうち開発系起因の障害に関する復旧時間の平均を4keysのMTTRとして使用しています。 平均検出時間・対応時間・復旧時間推移（データはダミーです） 想定損害金額 想定損害金額としていますが、実際の損害金額ではなく損害規模を相対的に推し量るための数値を独自の計算式で算出しています。 障害のあったサービスのマーケット売り上げに対して、障害レベルに応じた係数と発生から解消までの時間で算出しています。 （該当サービスの1日の売上×インシデントレベルによる係数×障害日数（発生→解消）） 想定損害金額（データはダミーです） 傾向分析 サービス別、リポジトリ別、要因別（コミュニケーションロス、テスト漏れなど）、起因工程別など様々な観点から傾向を探ることで隠れていた傾向や課題が見つかることもあります。 例えば、 ・同じ時期に別々のサービスで同じような事象で障害が発生していた ・〇〇のアップデートをした際に過去に同じような障害起こしてた ・一方のサービスでは監視をおこなっていて気づけたのにもう一方のサービスでは監視が至らず障害に至った ・エンドユーザーへの自動配信メールの記述内容のような監視しにくい部分において検知が遅れる傾向がある など、中には防げたはずの障害が浮き彫りになったりします。 まとめ 上記で計測・分析した結果は月次および半期ごとに社内に公開しています。 障害に関する情報が継続的に集計・可視化されることで、以下のような効果がみられたと感じています。 １．サービスによってややばらつきのあった障害対応の意識改善 ２．監視体制強化の意識 ３．別々のサービス管轄部署で同じ原因で発生していた障害の課題発見、対応方法の共有 障害が無くなることはありませんが、継続的に見ていくことで地道に対策がおこなわれることで障害発生率やMTTRが減少してきました。 しっかりと障害と向き合えていることで、サービスの質にも良い影響が出ているのではないかと思います。 最後に、LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。テクノロジー本部の岡より、障害管理運用のより具体的な取り組み内容を紹介していきます。 障害管理に関わる方の参考になれば幸いです。 障害報告のおおまかな流れ 具体的な障害ステータスと報告内容 最近の運用改善事例 まとめ 私たちの部署では、LIFULLのさまざまな事業開発に関する活動や適切性のモニタリングとレポーティングを通して横断・間接的に必要な支援・助言・監督を行う責任を担っています。 事業運営に携わるエンジニアによる、障害分析の取り組みはこちらの記事もぜひ読んでみてください。 www.lifull.blog   障害報告のおおまかな流れ LIFULLでは、専用の障害報告管理ボードを使って障害発生から恒久対応完了までを報告することになっています。 「障害・バグが疑われる事象」「サクセスレートの低下によるエラー通知」などの問題が起きたら、誰でもすぐに報告チケットを起票できます。（起票は一部自動化がされています） その後の調査報告や対応後のステータス更新が行われ、最終的には開発責任者が報告完了まで責任を持ちます。 具体的な障害ステータスと報告内容 障害対応のステータスごとにどんな入力項目を記載することになっているか、具体的に紹介します。 以下に記載している入力項目は必須入力項目です。ステータスを変更する際に未入力の場合は必ず入力を求められ、記載漏れが起きないようにしています。 これらの入力項目以外にも、できるだけ記載に時間をかけず抜け漏れなく記入できるように、選択式の入力項目が多数あり、その時点で判明していることを記載していきます。   報告ステータス 入力項目 １ 継続中 不具合が解消しておらず、対応が進行中の状態 報告書タイトル（障害の要約） 検知日時 ２ 暫定解消 不具合が復旧または自然解消し、正常稼働している状態 概要 発生日時 解消日時 事業領域 影響内容の詳細 対象利用者 対象デバイス 障害起因となった変更内容 対応内容 ３ 本解消 障害分析と再発防止策が記入され、障害対応が終了した状態 原因 再発防止策（次のいずれか） ・再発防止（恒久対応）完了報告 ・再発防止対応計画の管理資料の明記 ・許容判断（恒久対応不要）理由 開発担当部署の責任者 ４ 報告完了 障害分析と再発防止策が記入され、障害対応が終了した状態 （担当部署の責任者が確認） 再発防止（恒久対応）内容の最終チェック ５ 完了 問題解決プロセスが終了した状態 （モニタリング部署が確認）   分岐する別経路として、以下のようなステータスもあります。この場合モニタリング部署も内容確認を行います。 経過観察 原因不明、一時的エラーで対応保留などの状態 無効 開発担当者が調査後に障害ではないと判断された状態 原因重複（別対応中） 同じ原因の複数障害報告が存在している状態 最近の運用改善事例 開発担当者は、まず不具合解消を最優先に動きますが、解消後はさまざまな要因で報告が完了しないことも起こり得ます。 障害報告の運用は定着してきているものの、対応状況の確認や適切な情報共有に課題感がありました。 そこで、報告が未完了のままとなってしまいがちな主な要因を分類し、改善策を運用ルールに追加しました。 原因不明や再現性がなく調査困難な軽微なエラー - 改善策: 「経過観察」ステータスを追加し、軽微なエラーや再発が少ないものについては一定期間経過を見て問題がなければ、モニタリング部署が完了とする 同じ要因で発生した障害が複数報告される - 改善策: 一つの障害報告に情報集約し、それ以外は「原因重複（別対応中）」ステータスにてモニタリング部署が管理する 不具合解消後、ルーズボールになり情報更新がされにくくなる - 改善策: リマインドを可能な限り自動化、リマインド時に次に取るべき行動も都度伝える 恒久対応の難易度や優先度により恒久対応時期が未定 - 解決策: 恒久対応の課題管理がされていることを条件に完了とする まとめ 必要な対応に集中できるよう報告時の開発者負担を減らしたり状況をわかりやすくするなど、運用改善を少しずつ試みた結果、障害状況の見える化が進み、未完了の障害削減にもつながりました。 全体として障害対応が迅速化し、効率的な管理運用が実現できています。 状況の変化に対応しながら、今後も引き続きより良い運用方法を模索していきたいと思います。 次回は、この障害報告のデータによる障害傾向分析やレポートについて紹介する予定です。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、クオリティアーキテクトグループ（以下、QAG）の鐘です。 この記事では、E2Eテスト用物件のデータの正確性を維持するために、定期的にCSV形式の正しいデータを取り込むことで復旧する仕組みをご紹介したいと思います。 1. 結論 2. 背景 3. 解決したい問題 主要問題：物件データが意図せず変更されることで、テストが失敗してしまう 対応コストの増加 テスト信頼性の低下 副次問題：テスト用の物件が最適化・管理されていない 一つの物件が数種類のテストで使用されている 物件データがテスト用に最適化しづらい 4. やったこと 問題解決までの流れ 副次問題に対して：物件データの最適化 主要問題に対して：CSVでデータを復元できるのツール「DataKeeper」を提供 5. さらなる改善 1. 結論 物件データの不備が原因でテストが失敗することは運用開始以来発生していません。データが変更されても、毎日正常な値に修正されるため、テストケースに影響しません。 E2Eテスト用の物件が管理コストを削減するように工夫されました。また、各物件のデータを必要最低限の情報に整理し、どのテストケースで使用されているかが一目でわかるようになっています。 2. 背景 今回のテスト対象はLIFULL HOME'Sです。 開発中のプルリクエストでは 自動的にE2Eテスト が実行されます。 E2Eテストではユーザーのブラウザ操作を再現して物件問合せ、お気に入り登録などの機能を検証するため、40件ほどのテスト用物件が使用されています。 例： 賃貸物件リスト からテスト用物件を選択し、お気に入り追加ボタンを押下し、お気に入りリストの存在するかを検証するE2Eテスト 3. 解決したい問題 主要問題：物件データが意図せず変更されることで、テストが失敗してしまう 開発用環境とE2Eテスト用環境で同じデータストア（DBやXMLファイル）を使用しているため、開発で物件データを変更する際、E2Eテスト用の物件データも一括で変更されることがあります。 その結果、物件の名称や価格などにズレが生じ、テスト結果が失敗してしまうことがあります。 このような事象が発生すると、次の2つの悪影響があります。 対応コストの増加 テスト失敗の原因を調査する必要が生じます。 物件データに問題があると判明した場合、修正（または修正依頼）を行い、その反映や対応を待つことになります。場合によっては復旧までに最大で2時間かかることもあります。 テスト信頼性の低下 プロダクトに問題がないにもかかわらず、物件データの不備でテストが頻繁に失敗し、誤報が多発してテストの信頼性が低下します。 副次問題：テスト用の物件が最適化・管理されていない 具体的に： 一つの物件が数種類のテストで使用されている 例えば、問合せ機能のテストと一覧機能のテストで同じ物件を使用している。 デメリット：一つの物件に不具合が生じると、複数の機能のテストが失敗し、調査範囲が広がる。 物件データがテスト用に最適化しづらい 物件データがランダムで、不要なデータも含まれている 物件名が必要以上に長く、テストとの関連性が不明瞭 セールスポイントやこだわり条件など、テストに不要なデータが含まれている 1つのマーケット（賃貸など物件種別のこと）で複数の不動産会社の物件が使用されて管理しにくい、どの物件がどのテストで使われているかが分かりにくいなどの問題があります。 4. やったこと 問題解決までの流れ 物件データの最適化 CSVでデータを復元できるのツール「DataKeeper」を提供 副次問題に対して：物件データの最適化 1マーケットに3〜6の不動産会社が混在している状態を1マーケット1不動産会社に統一し、運用コストを削減しました。 1機能に対し1つの物件のみを使用するようにテストケースを調整しました。 これにより、1つの物件が壊れても影響はその機能のテストに限定され、調査が容易になります。 Before * 問合せのテスト: 物件A, 物件B * 物件検索のテスト: 物件A, 物件C * リスト表示のテスト: 物件A After * 問合せのテスト: 物件A * 物件検索のテスト: 物件B * リスト表示のテスト: 物件C テストに不要な冗長なデータを削除し、必要最低限のデータのみを残しました。さらに、物件名のフォーマットを統一し、マーケット、テスト目的、デバイスが一目でわかるようにしました。 例：品質管理テスト 変更禁止 b_mansion_inquire_sp 主要問題に対して：CSVでデータを復元できるのツール「DataKeeper」を提供 4つのマーケットの物件データを、それぞれ1つのCSVファイルにまとめてリポジトリで管理しています。 DataKeeperの実装： DataKeeperは、CSV形式で定義した物件データを元に正しい値に更新するためのツールです。 Jenkinsでマーケットごとのジョブを実行します。 各ジョブの手順は以下の通りです。 リポジトリから対象マーケットの物件データCSVを取得 CSVファイル内の日付（最終変更日、掲載期限など）を実行日に合わせてスクリプトで書き換え CSVをサーバーにアップロードし、データベースに反映 実行が完了したら、Slackに結果を通知 DataKeeperの運用： 平日朝に自動実行されるよう設定し、テスト用物件データに変更があってもなくても、定期的に正しいデータを書き込みます。 もし自動実行後にデータが正しい値以外に変更されても、不備を発見した人が手動でジョブを実行すれば、数分で正しい状態に戻せます。 5. さらなる改善 ここまでで、E2Eテスト用の物件データが最適化・管理されるようになり、データの不備によるテスト失敗の問題が解決されました。しかし、以下のような改善点がまだあります。 必要最小限のデータ以外、他のテストで必要なデータはまだ対応されていませんが、将来的に対応したいです。 E2Eテスト用以外のテスト物件にも正しいデータを書き込む対応を提供 他のテストレベル、テストタイプのテスト用物件データもDataKeeperで正確に保てるようにしたいと考えています。

グループデータ本部データサイエンスグループの嶋村です。 LIFULLでは、不動産や住まい探しに関する研究の活性化や、人工知能（AI）・情報学分野での人材育成への貢献を目的として、 2015年から学術研究者向けに LIFULL HOME’Sデータセット を提供 しています。 このデータセット提供は 国立情報学研究所（NII） が運営する 情報学研究データリポジトリ（IDR） の枠組みを活用した取り組みです。LIFULL HOME'Sデータセット利用者は年々増えており、これまで 171件の研究成果が公開 されています。 本記事では、2024年12月13日に開催されたIDRユーザフォーラム2024の様子をお伝えします。 IDRユーザフォーラム2024での発表 IDRユーザフォーラムについては過去の投稿でも紹介しておりますので、是非下記をご覧下さい。 「IDRユーザフォーラム2023」参加報告 - LIFULL Creators Blog 集会報告 NII-IDRユーザフォーラム2016 2020年初頭からのコロナ禍により、過去3回（2020、2021、2022）のIDRユーザフォーラムはオンラインのみで開催されました。今年は昨年2023と同様に 現地会場での開催 となりました。オンライン配信も組み合わせたハイブリッド形式だったのですが、現地会場での参加者がとても多く約150名規模となり、オンライン参加者は約50名規模となりました。 データ利用者の発表 として、各社のデータセットを利用した研究発表が32件、研究アイデアの発表が21件、合わせて53件の発表がありました。また、 データ提供者の発表 として、弊社LIFULLを含む民間企業から14件、研究者から8件、合わせて22件の発表がありました。 発表プログラムについては、以下のページをご参照下さい。 情報学研究データリポジトリ ユーザフォーラム LIFULL HOME'Sデータセットを活用した研究発表 LIFULL HOME'Sデータセットを利用した住まいに関する研究発表について、いくつか紹介したいと思います。今回は合計4件の発表がありました。 関西学院大学の福地さんらによる研究発表「 地域に対するレビューと地図画像を用いた地域特性学習モデルの提案 」は、地域に対するレビュー情報と地図画像を組み合わせることで、様々な地域が持つ独特な特性を把握するという取り組みです。レビュー情報を集めるのは手間がかかるため、もし地図画像のみから地域特性が把握できると、とても有用なのではないかと感じました。 東京科学大学の藤田さんらによる研究発表「 東京都における低層賃貸住宅の外観に対する印象と建築年代・空間分布・賃料の関係 」は、外観画像から建物の印象を定量評価し、その建物が存在する地域の印象を定量評価する取り組みです。物理的に近い地域であっても、地域の印象が大きく異なることはあるため、印象の定量評価がされていると住まい探しでも有用ではないかと感じました。 電気通信大学の綾部さんらによる研究発表「 築年代推定におけるViTとCNNモデルの比較 」は、外観画像から築年代を推定する取り組みです。850万枚もの画像データを学習データとして用いて、複数の画像認識モデルで比較評価をしており、とても興味深い結果でした。 東京科学大学のLiuさんらによる研究アイデア発表「 Assessing the 'Openness' of Real Estate Properties based on Diverse Perspectives 」は、不動産物件の開放感を定量評価する取り組みです。間取り図から得られる構造情報や、内観画像から得られる空間情報を組み合わせて定量評価を試みるアイデアであり、今後の発展がとても楽しみです。 様々な研究発表がありとても興味深かったです。また、データセットに関する要望など、利用者から直に声を聞くこともできたため、貴重な場となりました。 LIFULL HOME’Sデータセットのこれから LIFULL HOME'Sデータセットは 2015年の公開から9年が経過 し、「 LIFULL HOME'S 3D間取り 」など、サービス価値の向上につながる研究成果を生み出しています。 今後も 公開済みデータセットの更新 や 新たなデータセットの追加 等さらなる拡充をしていき、不動産や住まい探しに関する研究の発展に寄与できればと考えています。 最後になりますが、データサイエンスグループでは「 活用価値のあるデータを創出 」し「 データを活用した新たな機能やサービスの研究開発 」を加速して下さる シニアデータサイエンティストを募集 しています。 興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

プロダクトエンジニアリング部の二宮です。この記事は LIFULL Advent Calendar 2024 Part2の20日目です。 LIFULLにはkeelaiという社内向けの生成AI基盤プロジェクトがあり、私はその開発にコミットしています。今のところ特に社内用Slack botとして最もよく使われています。 www.lifull.blog keelaiの基本的なコンセプトを私達はマルチエージェントと呼んでいて、サブタスクを解決するために自律的に動くエージェントを複数組み合わせて協調させることで無限にスケールすることを目指します。 このエコシステムを土台に、エンジニア以外のメンバーからの改善リクエストや新しいアイデアをうまく取り込んでいます。その中から、生成AIヘビーユーザーの営業職メンバーから「営業日報を簡単に作りたい」というアイデアをいただいて、内製AIを使ってうまく機能提供した様子を紹介します。 営業サイドからのニーズヒアリング 既存機能の再利用で短期間開発 開発後の効果とフィードバック まとめ 営業サイドからのニーズヒアリング keelaiの開発チームでは、全社の活用方法の相談窓口となる サポート用のSlackチャンネル を設けています。そこで、営業職メンバーからプロンプトの相談を受けていました。 そこで何度かやり取りしていて、この2つ面白いフィードバックがありました。 Chrome拡張機能（keelext）で提供しているメール返信文作成機能に対する好評 営業日報作成を自動生成して省力化したいという要望 keelextとは生成AI（keelai）以前からあった内製Chrome拡張です。ここ最近はkeelaiとの連携機能も増えていて、その中の一機能として次の画像のようなGmailの返信文の作成機能を提供していました。これは半ばkeelaiのAPI連携機能のデモとして作ったつもりのものだったのですが、私たち開発チーム側が考えていた以上に需要が大きかったようです。 ※画像にあるメールの内容は架空のものです もう一つは営業日報の作成が負担で、生成AIで自動化したいという話です。 Slack AutomationsによるLLMノーコードツールの提供 にあるやり方を紹介しました。 既存機能の再利用で短期間開発 そのまましばらく動けてなかったんですが、更にしばらくして開発チーム内で「やっぱり営業職への普及促進は重要なんじゃないか」と課題が挙がります。そこで日報作成の省力化として、日報作成機能のkeelext組み込みにトライしてみることにしました。 最初に作った機能を紹介します。次のようになぐり書きに近いメモ書きから、ボタン一発で必要な項目に整理します。 私はkeelextのリポジトリを…というよりChrome拡張機能を実装したことが無く、フロントエンドやJavaScriptの経験に乏しいので当初は心配でした。しかし実際にやってみると、うまく機能がテンプレート化されていて、いくつかの箇所を触るだけで実現できました。 まずはmanifest.jsonにソースの読み込み設定を書き足します " content_scripts ": [ { " matches ": [ " <all_urls> " ] , " js ": [ ... ] , ... } , { ... } , { " matches ": [ " https://*.salesforce.com/* ", " https://*.lightning.force.com/* " ] , " js ": [ " src/salesforce.js " ] } ] , 次に実行ファイル（ src/salesforce.js ）を実装します。とはいえほとんど実装は使いまわしです。 <DOM要素のセレクタ> と、「保存」ボタンと被ってしまっていたボタンの位置を右側に移動させる設定だけは必要でした。 (() => { const monitor = ( selector , cb ) => { cb ( document . querySelectorAll ( selector )) ; new MutationObserver (( records ) => { records . forEach (( record ) => { record . addedNodes . forEach (( addedNode ) => { if ( addedNode . nodeType === Node . ELEMENT_NODE ) { cb ( addedNode . querySelectorAll ( selector )) ; } }) ; }) ; }) . observe ( document . body , { childList : true , subtree : true , }) ; } ; monitor ( `<DOM要素のセレクタ>` , ( nodes ) => { // ボタンを表示する実装 // ここでボタン押下時にtextboxの内容を取得してAPIを呼び出す実装をする }) ; })() ; そして最後にAPIの呼び出し部分を追加します。ここでプロンプトを修正します。 const response = await fetch ( "https://<keelai APIのエンドポイント>/v1/chat/completions" , { method : "POST" , headers : { "Content-Type" : "application/json" , "Authorization" : `Bearer ${ cookie . value } ` , } , body : JSON . stringify ({ messages : [{ role : "system" , content : `Your task is to create a sales report from the following text in ${ chrome . i18n . getUILanguage ()} . Output it thoroughly and carefully without omissions as a report for the supervisor. Adhere to the following terms. - CL = Sales Closing Structure and organize the report according to the following content. Output these contents in markdown with ### as titles, only the items for which information is available. - <項目A> - <項目B> ... - メモorトピックス ` , } , { role : "user" , content : message . content , }] , stream : true , }) , signal : abortController . signal , }) 更に言うと、これも先程の営業チームで使われていたプロンプトを大幅に参考にしています。「CL = クロージング」というよく使われる略語や、<項目A>などの各項目タイトルはそのまま流用しています。プロンプト全体を英語にして整理し直した点と、内容によっては含まれない項目を only the items for which information is available. とした点は追加で工夫しました。 理想を言うと、文章に必要な追加情報も自動で取ってこれるようにしたいとかは思いつくのですが、すぐ提供できる範囲で実用的な機能は提供できたと思います。 開発後の効果とフィードバック これで営業チームはワンクリックでメモを整理し、日報記入時間を大幅に短縮できるようになりました。協力してもらった方に連絡したところ、次のような嬉しいコメントいただけました。 実際に試してみました～！ 商談メモがワンクリックで整理された日報になるのでは感動しております、、、！！！ その後、営業チーム内の勉強会でSlack botやChrome拡張を紹介していただけたそうです。こんな感じで機能アイデアや対応のやり取りして、各チームのアーリーアダプターといい協力関係を築けてるように思います。 また、既存の機能（Gmail生成）を転用し、個別開発コストをかけずに横展開できることも確認できました。今後は他のツールの転用も視野に入れています。 まとめ このように、keelaiやkeelextは社内コードがオープンであるため、新機能を思いついたら素早く拡張できます。部署をまたいだニーズにも、既存コードを活かして最小限の修正で対応可能な環境が整っていると思います。 この日報支援機能等をきっかけに、他の業務ツールへの適用してみんなで楽できる流れを広げたいなあ…と思ってます。この後、社内向けの生成AIユースケースのデモ目的を半分、素直に自分が使いたい意図半分で、次のような機能も実装してみました。 Jira（プロジェクト管理ツール）やGitHubのPR, Issueなどを要約し、残課題や次のアクションをまとめてくれる機能 ブログを書くときによりわかりやすい書き方をアドバイスしてくれる機能 これをきっかけにユースケースを多くの社員に想像できるようにして、簡単に社内ツールの要約や提案機能をエンジニア全体で作っていけるようにもしたいです。また余談ですが、LIFULLには社内用Chrome拡張機能ストアがあったり、keelextに自動アップデート機能があったりして、こうした活動がスケールする仕組みが整備されていると感じます。 最後に、LIFULLでは一緒に自分たちの仕事を良くしていくエンジニアを求めています。これらの取り組みに興味を持っていただけたら、ぜひ求人情報やカジュアル面談のページもご覧ください🙇 hrmos.co hrmos.co