サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
買ってよかったもの
www.lifull.blog
QAの山下です。 QAグループという名前で横断組織として手動&自動テストやツール開発、プロセス改善など仕組みづくりに取り組んでいます。 今回は LIFULL HOME'S の開発で実行されているE2Eテスト(リグレッションテスト)をシフトレフトし、実行時間を80%短縮した話を紹介します。 ざっくり何をやったのか 大規模なリポジトリでのdevelopマージ後のE2Eテストの9割をPR上で実行可能にした コードのpushからE2Eテスト完了まで5~8分で完了できる 運用上の課題も頑張って解消した 目次 ざっくり何をやったのか 目次 結論 前提情報 E2Eテストとは リグレッションテストとは LIFULL HOMESでのE2Eテストの位置付け シフトレフトとは EEとは 対象のプロダクトの規模 起こっていた課題 テストの削除とリファクタを行い、テストケースを3割削減した デプロイ後のアプリケーシ
こんにちは。クオリティアーキテクトグループでQAエンジニアをしている星野です。 元々はQAグループという名前で横断組織として社内のテストプロジェクト支援などを嗜んでいましたが、 組織が統合・再編成され、より自動テストやツール開発、プロセス改善などエンジニアリングに寄った仕組みづくりに取り組んでいます。 3行まとめ 共通のフォーマットを開発したよ 抵抗感なく浸透させるように工夫したよ こっそり横断的なメトリクスも取ったら便利っぽかったよ 3行まとめ 背景 課題 対策 やったこと 当たり前品質編 : 満たさないと論外 魅力品質編: 乗り換える理由をつくる 横断部署が常にぶちあたる浸透の課題 ロガー 広報 効果と現状とこれから 終わりに 背景 課題 LIFULLではチームごとにやりやすい開発体制を選択しています。 奇抜な開発スタイルをとっているわけではありませんが、それぞれに特色があり独自に改善
KEELチームの相原です。 今回はeBPFを利用してKubernetesクラスタの可観測性の隙間を埋めている話です。 前回のエントリではLLMにうつつを抜かしていたので本業(?)の話をしようと思います。 www.lifull.blog LIFULLの可観測性の現在地 eBPFとは 可観測性の隙間 NAT Loopback eBPFを実行するには BPF CO-RE libbpf-rsを利用したNAT Loopbackの検知 1. (ユーザ空間) コマンドライン引数として受け取ったDNSをTTLごとに名前解決してIPアドレスを取得する 2. (ユーザ空間) IPアドレスに変化がある度にカーネル空間で動くBPFプログラムにそのIPアドレスのリストを渡す 3. (カーネル空間) Kprobesで tcp_v4_connect/tcp_v6_connect にフックを仕込む 4. (カーネル空間)
KEELチーム の相原です。 前回のエントリ で我々KEELチームはKubernetesベースの内製PaaSであるKEELを開発・運用する傍ら、LLMという新たなパラダイムの台頭にあわせてベクトルデータベースの提供や周辺ソフトウェアを社内向けに開発していることを紹介しました。 www.lifull.blog あれから数ヶ月が経ち、現在私達はLIFULLのグループ会社全体に向けて汎用AI(仮)を提供しています。 もともと我々KEELチームはPlatform Engineeringの一環として、Kubernetesベースの内製PaaSであるKEELのほかにコードジェネレータによる一貫したPaaS体験を中心に様々なユーティリティをコマンドラインから提供するkeelctl, KEELが提供するプラットフォームのユーザ体験を向上させるブラウザ拡張のkeelextを開発してきました。 Platform
プロダクトエンジニアリング部の吉田と申します。 普段はRubyやTypeScriptといった言語を使ったサーバサイドエンジニアをしています。 今回、サイトの閲覧障害をきっかけに行ったポストモーテム会が個人的にとても有意義だと感じたので紹介させてください。 障害分析レポートの紹介 弊社では障害が起きた場合、障害分析レポートを書くという決まりがあります。 この障害分析レポートというものは、一般的にはSREの用語でポストモーテムとして知られている障害対応時のことを記録する文書のことです。 弊社では品質管理を行っている部署がテンプレートやフォーマットを整えてくれており、内容としてはオライリーのSRE本の付録Dに記載してある「ポストモーテムの例」にかなり似通った内容です。 かいつまんで紹介すると下記のような内容を記載するものです。 障害の概要 影響範囲 タイムライン 水面下で起きていた問題(根本の問
プロダクトエンジニアリング部の千葉です。 LIFULL HOME'S不動産査定とホームズマンション売却の開発に携わっています。 この記事では、売却査定サービスにおけるアクセシビリティ対応の取り組みについて紹介していきます。 マンション査定シミュレーション input要素 コンボボックス 所在地選択ダイアログ キーボードフォーカス リストボックス 最後に マンション査定シミュレーション マンション査定シミュレーションは、インターネット上でマンションの価格を調べることができる簡易査定の機能です。 売却計画を立てる際や、不動産一括査定サービス利用時の参考として使用することができます。 LIFULL HOME'Sのマンション査定シミュレーションではマンション名、所在階、専有面積、間取りを入力すると参考価格を算出することができます。 まずは、ここの入力欄要素での取り組みについて紹介します。 inpu
こんにちは、フロントエンドエンジニアの嶌田です。 アクセシビリティは今まで以上に大きな関心を寄せられるトピックになってきたように思います。個人で関心がある人、企業のなかで周りを巻き込み推進しようとしている人、すでに組織全体での取組みに変わりつつある企業など、状況は様々だと思います。弊社はというと、内側からの推進活動は広がりを見せつつも、まだ組織一丸となった取組みには至っていない、といったところです。 そんな状況の私たちですが、社外のアクセシビリティを推進する同志たちに、ほんの少しでも力を分け与えられたらと思い、このたび「LIFULLアクセシビリティガイドライン」を公開しました。取組み状況が様々ある中でどのように活かしていけるか、まずは一度ご覧いただければ幸いです! lifull.github.io アクセシビリティとは? アクセシビリティとは、高齢者や障害者を含むできるだけ多くの人々に対し
フロントエンドエンジニアの嶌田です。株式会社 LIFULL でプロダクトのアクセシビリティ向上をミッションとして活動しています。 本日は、不動産・住宅情報の総合サービスである LIFULL HOME'S のスマートフォンサイトにおいて、過去半年間で実施したアクセシビリティ向上施策をご紹介します。ご紹介する施策のうちいくつかは、内容を掘り下げて実装コードを交えて解説をしていきます。 それでは、早速アクセシビリティ向上のために実施した施策を見ていきましょう。 ボタンを正しくボタンにする 追加コンテンツを読み込む機能のフォーカス管理 チェックボックスに適切な名前を付ける カルーセルをアクセシブルにする スクリーンリーダーによる検索結果の件数の読み上げ そのほかの改善点 おわりに ボタンを正しくボタンにする ウェブサイトにおいて、ユーザーがアクションを実行するためにボタンが用いられます。ボタンは通
こんにちは! LIFULLエンジニアの吉永です。 普段はLIFULL HOME'SのtoC向けのCRMチームにてエンジニアリングマネージャをやっています。 本日はクリーンアーキテクチャで構築したプロダクトが初版リリースから2年経過した現在、どうなっているか?について紹介したいと思います。 これから新規プロダクトにクリーンアーキテクチャを採用しようとしている方々の参考になれば幸いです。 アジェンダ クリーンアーキテクチャで構築したプロダクトの概要 クリーンアーキテクチャを採用して得られたメリットやデメリットについて 2年経過してみて今どうなの? まとめ クリーンアーキテクチャで構築したプロダクトの概要 今回のブログで紹介する我々のプロダクトですが、オムニチャネル戦略を推進する為の各種機能を提供するAPIサーバーとなり、下記のような機能を持っています。 LINE/Mailでその日の新着物件情報
プロダクトエンジニアリング部の海老澤です。 普段は LIFULL HOME'S の賃貸部門のフロントエンド開発をしています。 近年、LIFULL の開発部門では「開発生産性」という言葉が取り沙汰されるようになりました。 LIFULL HOME'Sの主要リポジトリは10年以上運用され続け、今も多くの開発者によって日々改修され続けています。 長い年月の中で小さな設計ミスも積み重なって大きくなり、ちょっとした実装でも入念な調査が必要となり開発生産低下の要因となっていました。 また10年以上前に採用したフレームワークで稼働しているため、今ではドキュメントを探すのも一苦労という具合です。 そこで主要開発部門では「自部門の機能はマイクロサービスへと切り離し、各々で面倒を見る」という方針になりました。 賃貸部門も同様に機能の切り離しを始め、先日「物件詳細ページ」のマイクロサービス化を行いました。 今回は
こんにちは。エンジニアの中島です。 現在はアクセシビリティ推進グループ(以下推進グループ)に在籍しています。 以前同組織の紹介記事をいくつかあげましたが、その通り弊社は自社の運営するサービスをアクセシブルにするため日々奮闘しています。 www.lifull.blog www.lifull.blog 以前の記事ではどういったマインドで同組織ができたか、どのように推進しているかについて話ました。 今回は、そういった活動の中でいくつか技術的な副産物が生まれたのでその話をしようと思います。 キーボード操作編 CSSの概念距離 さいごに キーボード操作編 アクセシビリティ対応にあたって、基本的なやることの一つにUIをキーボード操作可能にするという作業があります。 自社のサービスにもキーボード操作不能ないくつかのUIの存在を認識しており、それらを実際に直していくということをしています。 修正時、場合に
フロントエンドエンジニアの嶌田です。アクセシビリティ推進グループに所属し、社内のプロダクトのアクセシビリティを高めるために日々奮闘しています。 LIFULL HOME'S は不動産・住宅情報の総合サービスです。住宅や住み替えに関する多くの情報を取り扱っており、サービス全体の規模はかなり大きいといえます。 レスポンシブデザインに対応したヘッダ・フッタの制作については以前に公開した記事で取り上げました。2022年5月から10月にかけて行われた今回のプロジェクトは、このヘッダ・フッタを LIFULL HOME'S サービス全体に展開することで、四散しているヘッダ・フッタを統合・刷新することを目的としたものです。 www.lifull.blog ヘッダ・フッタの統合・刷新により、サービス全体のアクセシビリティが向上し、キーボードやスクリーンリーダーのユーザーにとって利用しやすくなりました。改善の内
こんにちは。エンジニアの中島です。 2022年 4月からアクセシビリティ推進グループ(以下推進グループ)に在籍しています。 この組織は新設されたばかりで、まだ出来て半年の組織になります。 そのため、部署の目指すべきゴールイメージや、それを図るための指標といったものを作るところから始めることになりました。 本記事はそういったところについて共有させていただこうと思います。 立ち上げにあたっての話については以前同グループの嶌田が投稿した記事があるのでそちらをご参照ください。 www.lifull.blog 部署の目指すべきゴールイメージと行動軸 プロダクトに対する直接的な品質改善活動 新しい負債の発生を低減させるための文化醸成 指標化 プロダクトに対する直接的な品質改善活動の指標化 マニュアルテスト スコアリング 加えたマニュアルテスト項目とその重み Lighthouseの推奨するマニュアルテス
こんにちは。テクノロジー本部の福留です。4 月に新卒入社しました。好きなものは合唱と篩型です。 目標管理に関するフレームワークとして、OKR(Objectives and Key Results)が Google や Facebook などの企業で取り入れられ、注目を集めています。 OKR フレームワークにおいては、挑戦しがいのある高い目標(Objective)を設定し、主要な結果(Key Results)も 60〜70%の達成度で成功とみなされるような、高い成果に設定します。 チームのモチベーションが高くなるような高い目標を掲げる一方で、日々の業務ではできなかったことのほうが多くなり、徐々にメンバーのモチベーションが低下する原因になりえます。 この問題を解決する取り組みが WinSession です。この場では、逆に「できたこと」に注目し、メンバーどうしが承認・称賛しながら情報共有を行い
はじめに こんにちは!AI戦略室の曽迪(ソテキ)です。LIFULL社内の技術や知見を集結させて議論するイベント: LIFULL Tech Hubの運営リーダーを担当しています。今回はLIFULL Tech Hubについて紹介します。 LIFULL Tech Hubとは LIFULL Tech Hubとは、過去に「AI戦略室成果展示会」という名称で開催されたイベントをさらに発展させた全社カンファレンスです。 そもそも私が所属するAI戦略室は、事業部とは独立した組織であるため事業部との距離感が生じやすく、研究開発組織として活動や成果を発信し会社全体に存在意義を認知してもらう必要がありました。「AI戦略室成果展示会」はその流れで開催されたものとして、以来定期的に全社イベントとして開催してまいりました(過去のAI戦略室成果展示会の紹介)。 これらのイベントを開催する過程において、社内には私たちと同
こんにちは! LIFULLエンジニアの吉永です。 本日はエンジニアの自己研鑽について、自分はどんなことをやってきたかを紹介します。 ソフトウェアエンジニアを目指している人や、ソフトウェアエンジニアとして今後のキャリアプランに悩んでいる人の参考になれば幸いです。 私については、以前noteへ投稿した下記の記事に自己紹介と略歴が記載されているので、宜しければご参照ください。 note.com アジェンダ 自己研鑽の方法と変遷について 2007年~2009年頃 2010年~2014年頃 2015年~2019年頃 2020年~現在(LIFULLに入社してから現在) まとめ 最後に 自己研鑽の方法と変遷について 私は2007年4月にソフトウェアエンジニアとしてのキャリアをスタートし、2015年3月までは放送機器の組込ソフトウェアエンジニアとして働いていました。 思い返してみると、自己研鑽の為のインプ
フロントエンドエンジニアの嶌田です。2022 年 4 月からアクセシビリティ推進グループ(以下推進グループ)に在籍しています。今回はこの新しくできた部署について簡単に紹介します。また、会社や私がアクセシビリティに取り組む理由を語ってみようと思います。 弊社プロダクトのアクセシビリティを推進する取り組みは、これまでも有志が集まるワーキンググループの形で存在していました。ワーキンググループについては以前に Ltech という社外イベントで紹介しました。今年度からの新設部署はワーキンググループの流れを汲んでおり、推進活動に本腰を入れてコミットしていくために新設された部署です。 参考:Ltech#14 「LIFULL HOME'S」のフロントエンドについて語り尽くします! 開催レポート - LIFULL Creators Blog 推進グループは上長1名に、ほぼフルタイムでアクセシビリティにコミッ
エンジニアの島です。AI戦略室でバックエンドシステムの開発をしています。 本記事ではPrometheusを利用して、独自のメトリクスを計測することで監視を効率よく行えることを紹介します。 背景 チームで作っているもの 社内共通基盤の活用 効果的な監視で得られるもの 問題の予兆に気付けるようになる 問題の原因特定につながる 時系列での傾向を把握できる Prometheusとは 思想 メトリクスの公開 custom metricsを追加しよう Prometheusで監視しよう custom metricsで計測すると嬉しいもの 外部IOに関して 内部状態に関して 外部起因ではないアプリケーションのエラーの数 有効データのうち、モデルが値を返せている割合 機械学習モデルのスコア(histogramを利用) そのほか 終わりに 最後に宣伝 背景 チームで作っているもの LIFULLのAIチームでは
事業基盤ユニットアーキテクトグループのyoshikawaです。 今回のブログではLIFULL HOME'Sを構成するレガシーシステムのリアーキテクティングについて書いていきます。 2年前にリアーキテクティングプロジェクトが発足し、ソフトウェアアーキテクチャのベースにClean Architecture、言語にTypeScriptを採用し 新たなAPI(Backend For Frontend)を開発してきました。 「コードの品質」と「プロダクト開発エンジニアとのコミュニケーション」が鍵となっていた本プロジェクトですが、 このブログ記事では「コードの品質」を主題として取り組みをオムニバス的に紹介していきます。 この記事で伝えること 想定する対象読者 過去のブログの紹介 データフローに注目したLIFULL HOME'Sのシステム概観 リアーキテクティングプロジェクトについて アーキテクトチーム
こんにちは、プロダクトエンジニアリング部の鈴木です。 私達のチームでは、リファクタDaysの取り組みとして、APIサーバのテストコード(RSpec)のリファクタリングを行いました。 このリファクタリングにより、テストコードの記述量が大幅に削減され、数年間利用してきたAPIコントローラのテストコードを作業時間にして2週間程度で移行できました。 この記事では、どのようにしてチームでRSpecを改善したのか全体像をお伝えします。 APIサーバが抱えるテスト実装の課題 主な改善内容 ディレクトリ構成を整備・統一する テストの雛形を自動生成する モック・スタブ化をVCRで自動化する テストコードの期待値も自動で作る テストコードから実装の振る舞い以外を追い出す チームでの改善の進め方 まとめ APIサーバが抱えるテスト実装の課題 私達のチームが管理しているサービスでは、バックエンド(APIサーバ)が
はじめに こんにちは!LIFULLのプロダクトエンジニアリング部でフロントエンドエンジニアを担当している竹本です。 今回はチームで初導入した「デザインスプリント」について どのような手法で導入したか 導入して感じた利点と現状の課題 を共有します。 デザインスプリントとは デザインスプリントはサービスの開発を効率よく進めるために各ステップごとにチームメンバーで議論してプロトタイプを作り、高速で価値を検証するプログラムです。 各ステップでは、リサーチ、プロトタイピング、ユーザーテストに則ったプログラムで構成しています。 これを何度も繰り返し研磨することでサービスの理想形を探究し続けるといった点が今回の目標になります。 チームでどのように実施したか まず今回の基本構成としましては、以下のようなプログラムに分けて実施しました。 DAY1 理解...競合調査やデータ分析による課題定義 DAY2 発散
テクノロジー本部のyoshikawaです。 最近のLIFULLでは、自社が所有するデータの活用を目的に数多くの取り組みが実施されています。 今回はデータの発見可能性(Data Discovery)を向上させるための基盤構築を目指して実施したPoC(Proof of Concept)とそのOSSの選定について紹介します。 当初は「自社データの再利用性を高めたい」という広い意味を持った要件で開始したプロジェクトでしたが、 Data Discoveryがボトルネックになっていると判明し、解決策としての基盤構築に向けてPoCを実施することとなりました。 現場の課題調査からOSSの選定と試験運用まで一連のトピックをまとめていきます。 初期フェーズ: 現場調査と課題抽出 FAIR原則 データ利用の現場から抽出した課題 ボトルネックの特定と解決策の選定 PoCの開始 OSSの選定 Datahubとは M
こんにちは、エンジニアの加藤です。LIFULL HOME'Sの注文住宅領域を支えるエンジニアチームのマネジメントを担当しています。 皆さん、技術的負債の解消やリファクタリングなどどのように行っていますか? 長年の開発業務により蓄積された技術的負債は、開発生産性を低下させる要因として多くの方の頭を悩ませているかと思います。 私の所属する部署では開発生産性の向上をミッションとして掲げており、技術的負債の解消はミッションを達成するための重要な要素となっています。 そのような中、私たちのチームでは「リファクタDays」という取り組みを通じ、約半年間技術的負債の解消を含むシステム改善に努めてきたので、今回はそちらについて紹介したいと思います。 技術的負債の解消を行う上での課題 開発生産性を上げるため技術的負債の解消が重要である一方、LIFULL HOME'S 注文住宅の機能開発を担当するエンジニアで
プロダクトエンジニアリング部の二宮です。 LIFULL では「エンジニアいつでも相談」という名前で、GitHub Discussionsを使った社内向けの Q&A フォーラムを有志で運営しています 🙌 このフォーラムは「あるシステムについて誰か詳しい人に相談したい」とか「設計についてチーム外にも相談したい」とか、エンジニアリングで困ったことをなんでも聞ける窓口になることを目指しています。最近ではアーキテクトチームや QA チームなどの公式の窓口としても利用でき、質問の内容に応じて適切な部署や人がアサインされる体制も整い始めました。 従来は相談相手を見つけるのにも苦労したり、そもそも窓口が用意されていなかったりすることもあり、社内アンケート調査等でよく情報共有が課題に挙がっていました。そこで、社内向けの Q&A フォーラムを用意することで、その問題の一部を解消しつつあります。 エンジニアい
プロダクトエンジニアリング3Uの二宮です。 LIFULLにはチームビルディングの制度があり、半年〜1年に一度、同じチームのメンバーで半日〜1日単位で交流の機会を設けています。内容も各部署内で決めることができ、多種多様な企画が行われています。クリエイターズブログでも、過去に「エンジニアのためのチームビルディング!コードで語れ 頭を使って 謎を解け」や「独自企画「浅草BINGO鬼ごっこ」でチームビルディングしてみた!」などが紹介されています。 LIFULLでは新型コロナウイルスの流行をきっかけにリモートワーク主体の働き方になっており、チームビルディングもリモートで行うようになり、自分たちのチームでもいろいろ苦慮しながら実施しました。おそらく他の会社の方もそうなのではないでしょうか? そこで、この記事では私たちのチームではどう企画して、どう実施・今後に活かしていこうと考えたかをまとめました。ぜひ
エンジニアの松尾です。LIFULL HOME'Sの売買領域を支えるエンジニアチームのマネジメントを担当しています。 私の部署を始め、LIFULLでは複数の部門でエンジニア採用を行っています。人事部門の採用担当と現場で連携し、書類審査と複数回の面接により選考を行います。 今回はエンジニア採用を進める上で感じた課題とその解決への取り組みについて紹介したいと思います。 採用において抱えていたモヤモヤ いくつかの書類審査と面接を終えて、日々似たような作業を繰り返しながらいくつかのモヤモヤを抱えていました。 モヤ1: 書類審査に時間がかかる 打率よりもまずは打数。より良い候補者様を見つけ出すために、できるだけ多くの書類に目を通すようにしています。ただしどの方も真剣に経歴を書いてくださっており、すべてに目を通すにはなかなか時間がかかります。 採用以外にもやるべき仕事は多くあります。書類審査に時間をかけ
検索エンジンチームの宮崎です。 今日は、Solr内部でも使用されている全文検索アルゴリズムの転置インデックスについて話をしようと思います。 転置インデックスの仕組みについてざっくり理解したい人の手助けになれば幸いです。 全文検索アルゴリズム 全文検索の方法として大まかに 「grep型」と「インデックス型」があります。 多くの検索エンジンや全文検索ライブラリでは、インデックス型が使われています。 これはgrep型が都度すべての文書を検索するのに対して、インデックス型はその名の通り索引を用いて効率的に検索を行うことができるためです。 インデックスのアルゴリズムもいくつもありますが、今回は apache/solr・apache/luceneでも使用されている転置インデックスについて、簡単な例を用いて解説しようと思います。 今回は転置インデックスを使用した簡単な例として、「google/codes
次のページ
このページを最初にブックマークしてみませんか?
『LIFULL Creators Blog』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く