LIFULL Creators Blog

LIFULL Creators Blogとは、株式会社LIFULLの社員が記事を共有するブログです。自分の役立つ経験や知識を広めることで世界をもっとFULLにしていきます。

AIを活用した画像検索機能の開発裏話

こんにちは。フロントエンドエンジニアの根本です。 LIFULL HOME'Sのプロダクト開発とスポーツ関連の新規事業開発に携わっています。 今回は、PdM兼開発担当として携わった「注文住宅サイトの画像検索機能」について、開発の裏側をご紹介します。

続きを読む

DroidKaigi 2025 参加レポート

はじめに

こんにちは。プロダクトエンジニアリング部でAndroidのネイティブアプリエンジニアをしている久野です。

2025年9月10日から12日にかけて開催された「DroidKaigi 2025」に現地参加してきました。

この記事では、カンファレンスの現地の様子や、特に印象に残ったセッションについてご紹介します。

続きを読む

Amazon Q Developer活用による 業務効率化と多職種展開

はじめに

LIFULLにて基盤グループのマネジメントをしている磯野です。

2025年8月28日に開催された「Amazon Q Developer Meetup #2 Amazon Q Developer を業務で活用した成果共有と最新情報 Update」に参加し、LIFULLでの活用事例について発表させていただきました。

当日は株式会社マイナビ様の事例発表もあり、他社での活用状況を知ることで多くの共通点や共感できる部分がありました。また、懇親会では各社の担当者の方々と直接お話しでき、様々な活用方法や課題について情報交換することができ、今後更にいろいろ試せそうで非常に有意義な時間を過ごさせていただきました。

本記事ではイベントで発表した内容をもとに、Amazon Q Developerの導入から社内展開、そして多職種での活用事例について、LIFULLでの実践例をご紹介します。エンジニアだけでなく、サービス企画やデザイナーまで幅広い職種で活用が広がっている現状と、その具体的な事例をお伝えします。

続きを読む

LIFULL HOME'Sにおけるサーバーサイドパフォーマンス改善 —— 99パーセンタイルを60%改善したボトルネック特定手法

こんにちは。プロダクトエンジニアリング部の江口です。主に賃貸部門の開発を担当しています。

このたび、LIFULL HOME'Sの賃貸詳細ページにおけるサーバーサイドの処理速度を改善し、99パーセンタイルを60%改善しました。 本記事では、このパフォーマンス改善をどのように実現したのか、具体的な技術的アプローチについて解説します。

  • 背景
  • 分析から見えたパフォーマンスボトルネック
  • 改善のためのアプローチ
  • 成果
  • 終わりに
続きを読む

スライドをHTMLで生成するという選択!パワポ風HTMLをLLMに構築させることでスライド作成を自動化した話

こんにちは、LIFULLでシニアエンジニアをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにてマネジメントをしています。

みなさんは業務の中でスライドを作る場面ってどのくらいありますでしょうか?

私は管理職になってから業務上ビジョンシェアリングの機会や総会等での発表の機会が増えました。 それに伴い以前にも増して圧倒的にスライドを作成する作業の時間が増えました。

私の場合、話したいことは思い付くし、文章に起こすこともできるのですが、それをスライドにするのが手間がかかる上スライドを作るセンスにも自信がありません。 これが回り回ってかなりストレスになっていました。 そんな課題感から、この作業をどうにか簡略化できないかを検討し、弊社で主に使われているAmazon Q Developerを使ってスライド作成を自動化するしくみを検討しました。

結果として、従来数時間かかっていた作業が数分で完了するようになり、生産性が大幅に向上しました。

今回は、その具体的な手法と実装について詳しく紹介します。

続きを読む

リリース作業からの完全解放!週2回のリリースが1日2回リリースへ!集約と自動化によりリリースフロー改革を実現したGitHub Actions活用法

こんにちは、LIFULLでシニアエンジニアをしている渡邉です。普段はLIFULL HOME'Sの流通領域のエンジニアチームにて、マネジメントをしています。好きなCI/CDツールはGitHub Actionsです。

以前、こちらの記事で、私たちのリリースフロー改善への取り組みをお話しました。

www.lifull.blog

あれから数ヵ月が経ち、私たちのGitHub Actions集約型リリースフローは想像以上に進化を遂げました。今回は、その変化と新しく追加された機能について、実際の開発現場での体験を交えながらお伝えします。

  • 🚀 何が変わったのか?主要なアップデート
    • 1. セットアップが驚くほど簡単になりました
    • 2. Chrome拡張機能で承認作業が格段に楽になりました
    • 3. 企画担当者の方でも迷わず使えるガイドを作りました
    • 4. リリース忘れを防ぐ機能を追加しました
    • 5. 開発タスクの管理が自動化されました
    • 6. 🎯 自動リリース機能でリリーサーの負荷がほぼゼロに
    • 7.使いやすさへのこだわり
      • 見た目でわかる設計
      • 自動化されたリリースプロセスにおける課題を解決するためのしくみ
      • グローバルチームにも対応
  • 実際の開発現場での変化
    • 導入前の悩み
    • 導入後の声
  • 🎉 実際の導入効果:数字で見る劇的な改善
    • リリース頻度の大幅向上
    • 承認からリリースまでの時間短縮
    • 企画担当者にもわかりやすい
    • 自動マージ機能の効果
    • 通知システムの効果
  • あらゆるリポジトリ形態に対応
  • 柔軟な導入アプローチ
    • ユースケースに合わせた導入方法の提供
  • 自動リリースがもたらした革命的変化
    • リリーサーの役割の変化
    • 組織全体への影響
  • これからの展望
  • まとめ
続きを読む

情報システム部門のKPI(定量効果計測)について

こんにちは、テクノロジー本部コーポレートエンジニアリングユニットの籔田綾一です。今回は、情シス部門におけるKGI・KPIマネジメントの導入と実践について、その経緯と成果を共有します。私たちの試みが、同じ課題を抱える皆さんの参考になれば幸いです。

はじめに:情シス部門の成果を定量的に計測するには

「情報システム部門で、成果を定量的に示すことができるのだろうか?」

これは、多くの情シス部門が抱える課題ではないでしょうか。日々のインフラ運用、ヘルプデスク対応、セキュリティ対策、そして数々のプロジェクト推進など、情シス業務は多岐にわたります。その貢献を経営層や他部門に示す際、定性的な説明に終始してしまうケースも少なくありません。売上のような明確な指標がないため、部門の価値をどのように証明すれば良いのかという悩みがあるかと思います。


このような経緯から、「情シス全体で採用できる定量的指標を自分で作ってみよう」と考えました。

  • はじめに:情シス部門の成果を定量的に計測するには
    • 「情報システム部門で、成果を定量的に示すことができるのだろうか?」
  • 最初のステップ:指標の「物差し」を統一するアイデア
  • 戦略と連動させるための工夫:ウェイト付けの導入
  • とにかく1以上を目指そう!:具体的な行動変化
    • 固定費削減への意識と行動の変化
    • 開発タスク進捗向上への意識と行動の変化
  • 振り返り:やってみて分かったこと、そして今後の課題
  • まとめ:情シス部門の成果は定量的に計測できる
続きを読む