はてなブックマーク

フロントエンドエンジニアの嶌田です。 アイコンは、UIデザインにおいて欠かせないパーツです。弊社が提供する不動産情報サイトであるLIFULL HOME'Sでも、多数のアイコンが使われています。 ウェブページにアイコンを埋め込む手段は無数にあります。あなたはいくつ言えますか？　それぞれのメリットとデメリットについて説明できるでしょうか？ この記事では、LIFULL HOME'Sのフロントエンドで選ばれているアイコン表示方法およびその理由を説明します。その後、アイコンの管理や実装にまつわる不便な点をサービス横断的に解消するために作られた社内ツールと配信システムである、LIFULL Icon CDNを紹介したいと思います。 私たちのアイコン実装方法 無数にあるアイコン実装方法のうち、私たちが選んだ実装方法は極めてシンプルです。 <img src="assets/icon-star.svg" wi

KEELチームの相原です。 前回のエントリは「LLMを利用したPlatform Engineering」でした。 www.lifull.blog 今回は、小さい経路最適化ミドルウェアを実装してAZ間通信を削減した話を書きたいと思います。 背景 我々KEELチームはKubernetsベースの内製PaaSであるKEELを開発しており、LIFULLのほとんどのサービスがこのKEEL上で動いています。 www.lifull.blog そして、KEELは巨大なマルチテナントのKubernetesクラスタとしてAWSの複数のAvailability Zone(以下AZ)に展開されていて、多くのmicroservicesが互いに通信しあっています。 そのためAZ間通信はプラットフォームとして重要な関心事の一つです。 レイテンシやAWSのAZ間通信に対する課金を最小限に抑えるため、なるべくAZ間通信を減ら

QAの山下です。 QAグループという名前で横断組織として手動&自動テストやツール開発、プロセス改善など仕組みづくりに取り組んでいます。 今回は LIFULL HOME'S の開発で実行されているE2Eテスト（リグレッションテスト）をシフトレフトし、実行時間を80％短縮した話を紹介します。 ざっくり何をやったのか 大規模なリポジトリでのdevelopマージ後のE2Eテストの9割をPR上で実行可能にした コードのpushからE2Eテスト完了まで5～8分で完了できる 運用上の課題も頑張って解消した 目次 ざっくり何をやったのか 目次 結論 前提情報 E2Eテストとは リグレッションテストとは LIFULL HOMESでのE2Eテストの位置付け シフトレフトとは EEとは 対象のプロダクトの規模 起こっていた課題 テストの削除とリファクタを行い、テストケースを3割削減した デプロイ後のアプリケーシ

こんにちは。クオリティアーキテクトグループでQAエンジニアをしている星野です。 元々はQAグループという名前で横断組織として社内のテストプロジェクト支援などを嗜んでいましたが、 組織が統合・再編成され、より自動テストやツール開発、プロセス改善などエンジニアリングに寄った仕組みづくりに取り組んでいます。 ３行まとめ 共通のフォーマットを開発したよ 抵抗感なく浸透させるように工夫したよ こっそり横断的なメトリクスも取ったら便利っぽかったよ ３行まとめ 背景 課題 対策 やったこと 当たり前品質編 : 満たさないと論外 魅力品質編: 乗り換える理由をつくる 横断部署が常にぶちあたる浸透の課題 ロガー 広報 効果と現状とこれから 終わりに 背景 課題 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 のスマートフォンサイトにおいて、過去半年間で実施したアクセシビリティ向上施策をご紹介します。ご紹介する施策のうちいくつかは、内容を掘り下げて実装コードを交えて解説をしていきます。 それでは、早速アクセシビリティ向上のために実施した施策を見ていきましょう。 ボタンを正しくボタンにする 追加コンテンツを読み込む機能のフォーカス管理 チェックボックスに適切な名前を付ける カルーセルをアクセシブルにする スクリーンリーダーによる検索結果の件数の読み上げ そのほかの改善点 おわりに ボタンを正しくボタンにする ウェブサイトにおいて、ユーザーがアクションを実行するためにボタンが用いられます。ボタンは通

検索エンジンチームにいながら外部公開APIのメンテナンスもしている加藤宏脩です。 この記事では、毎日大量に書き込まれ膨れ上がったMySQLのテーブルを、 テーブルローテーションさせることで不要なデータを継続的かつ安全に削除する処理の実装をしたのでそれについてお話したいと思います。 利用している技術 Amazon RDS for MySQL Engine version: 5.7.41 Amazon ElastiCache for Redis Engine version: 6.2.6 起きていた問題 LIFULLのとあるサービスは、アプリケーションとMySQL、DBの結果をキャッシュするRedisがあるというよくみる一般的なアーキテクチャで運用しています。 このMySQLのテーブルは毎日100万件以上のレコードが追加されていく状態になっており、 総レコード数は６億件を超え、容量は2TBを超

こんにちは！ 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 です。この場では、逆に「できたこと」に注目し、メンバーどうしが承認・称賛しながら情報共有を行い

こんにちは！ 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 推進グループは上長１名に、ほぼフルタイムでアクセシビリティにコミッ

こんにちは！KEELチームの花塚です。 最近一番驚いたことは、OPA Gatekeeperの「OPA」を「オーパ」と発音するらしいということです。 さて今回は、OPA GatekeeperやConftestなどを用いてKubernetesのセキュリティ面を強化した話です。 以前からチームメンバー全員がセキュリティに気を配っているものの、今まで対策していることが妥当なのか、考慮漏れはないだろうかということを定期的に確認する機会がありませんでした。 闇雲に対策せず一度自分たちの対策を見直し、継続的にセキュリティを向上していける仕組み作りの過程をお伝えできればと思います。 目次 目次 解決したかった課題 OPA Gatekeeperとは Pod Security Policyの廃止 Kubernetesへの脅威 本番環境に導入するまで GatekeeperとConftestで使用するRegoを同

事業基盤ユニットアーキテクトグループの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 フォーラムを用意することで、その問題の一部を解消しつつあります。 エンジニアい