TECH PLAY

株式会社LIFULL

株式会社LIFULL の技術ブログ

660

グループデータ本部データサイエンスグループの嶋村です。 今回は 事業部門と研究開発部門が密に連携 して「おとり物件」と呼ばれる 社会課題の解決に挑んだ取り組み について紹介したいと思います。この記事では主に研究開発部門の視点での発信になりますが、事業部門の視点での発信もありますので、是非下記の記事もご覧いただけると嬉しいです。 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日の売上×インシデントレベルによる係数×障害日数(発生→解消)) 想定損害金額(データはダミーです) 傾向分析 サービス別、リポジトリ別、要因別(コミュニケーションロス、テスト漏れなど)、起因工程別など様々な観点から傾向を探ることで隠れていた傾向や課題が見つかることもあります。 例えば、 ・同じ時期に別々のサービスで同じような事象で障害が発生していた ・〇〇のアップデートをした際に過去に同じような障害起こしてた ・一方のサービスでは監視をおこなっていて気づけたのにもう一方のサービスでは監視が至らず障害に至った ・エンドユーザーへの自動配信メールの記述内容のような監視しにくい部分において検知が遅れる傾向がある など、中には防げたはずの障害が浮き彫りになったりします。 まとめ 上記で計測・分析した結果は月次および半期ごとに社内に公開しています。 障害に関する情報が継続的に集計・可視化されることで、以下のような効果がみられたと感じています。 1.サービスによってややばらつきのあった障害対応の意識改善 2.監視体制強化の意識 3.別々のサービス管轄部署で同じ原因で発生していた障害の課題発見、対応方法の共有 障害が無くなることはありませんが、継続的に見ていくことで地道に対策がおこなわれることで障害発生率やMTTRが減少してきました。 しっかりと障害と向き合えていることで、サービスの質にも良い影響が出ているのではないかと思います。 最後に、LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co
こんにちは。テクノロジー本部の岡より、障害管理運用のより具体的な取り組み内容を紹介していきます。 障害管理に関わる方の参考になれば幸いです。 障害報告のおおまかな流れ 具体的な障害ステータスと報告内容 最近の運用改善事例 まとめ 私たちの部署では、LIFULLのさまざまな事業開発に関する活動や適切性のモニタリングとレポーティングを通して横断・間接的に必要な支援・助言・監督を行う責任を担っています。 事業運営に携わるエンジニアによる、障害分析の取り組みはこちらの記事もぜひ読んでみてください。 www.lifull.blog   障害報告のおおまかな流れ LIFULLでは、専用の障害報告管理ボードを使って障害発生から恒久対応完了までを報告することになっています。 「障害・バグが疑われる事象」「サクセスレートの低下によるエラー通知」などの問題が起きたら、誰でもすぐに報告チケットを起票できます。(起票は一部自動化がされています) その後の調査報告や対応後のステータス更新が行われ、最終的には開発責任者が報告完了まで責任を持ちます。 具体的な障害ステータスと報告内容 障害対応のステータスごとにどんな入力項目を記載することになっているか、具体的に紹介します。 以下に記載している入力項目は必須入力項目です。ステータスを変更する際に未入力の場合は必ず入力を求められ、記載漏れが起きないようにしています。 これらの入力項目以外にも、できるだけ記載に時間をかけず抜け漏れなく記入できるように、選択式の入力項目が多数あり、その時点で判明していることを記載していきます。   報告ステータス 入力項目 1 継続中 不具合が解消しておらず、対応が進行中の状態 報告書タイトル(障害の要約) 検知日時 2 暫定解消 不具合が復旧または自然解消し、正常稼働している状態 概要 発生日時 解消日時 事業領域 影響内容の詳細 対象利用者 対象デバイス 障害起因となった変更内容 対応内容 3 本解消 障害分析と再発防止策が記入され、障害対応が終了した状態 原因 再発防止策(次のいずれか) ・再発防止(恒久対応)完了報告 ・再発防止対応計画の管理資料の明記 ・許容判断(恒久対応不要)理由 開発担当部署の責任者 4 報告完了 障害分析と再発防止策が記入され、障害対応が終了した状態 (担当部署の責任者が確認) 再発防止(恒久対応)内容の最終チェック 5 完了 問題解決プロセスが終了した状態 (モニタリング部署が確認)   分岐する別経路として、以下のようなステータスもあります。この場合モニタリング部署も内容確認を行います。 経過観察 原因不明、一時的エラーで対応保留などの状態 無効 開発担当者が調査後に障害ではないと判断された状態 原因重複(別対応中) 同じ原因の複数障害報告が存在している状態 最近の運用改善事例 開発担当者は、まず不具合解消を最優先に動きますが、解消後はさまざまな要因で報告が完了しないことも起こり得ます。 障害報告の運用は定着してきているものの、対応状況の確認や適切な情報共有に課題感がありました。 そこで、報告が未完了のままとなってしまいがちな主な要因を分類し、改善策を運用ルールに追加しました。 原因不明や再現性がなく調査困難な軽微なエラー - 改善策: 「経過観察」ステータスを追加し、軽微なエラーや再発が少ないものについては一定期間経過を見て問題がなければ、モニタリング部署が完了とする 同じ要因で発生した障害が複数報告される - 改善策: 一つの障害報告に情報集約し、それ以外は「原因重複(別対応中)」ステータスにてモニタリング部署が管理する 不具合解消後、ルーズボールになり情報更新がされにくくなる - 改善策: リマインドを可能な限り自動化、リマインド時に次に取るべき行動も都度伝える 恒久対応の難易度や優先度により恒久対応時期が未定 - 解決策: 恒久対応の課題管理がされていることを条件に完了とする まとめ 必要な対応に集中できるよう報告時の開発者負担を減らしたり状況をわかりやすくするなど、運用改善を少しずつ試みた結果、障害状況の見える化が進み、未完了の障害削減にもつながりました。 全体として障害対応が迅速化し、効率的な管理運用が実現できています。 状況の変化に対応しながら、今後も引き続きより良い運用方法を模索していきたいと思います。 次回は、この障害報告のデータによる障害傾向分析やレポートについて紹介する予定です。 最後に、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
エンジニアの松尾と申します。LIFULL HOME'S で中古住宅売買領域の開発を担当するチームのマネージャーとして働いています。 2024年は新卒1名、中途1名の新入社員が自部署に仲間入りしました。今回はそれらの内容をふりかえり、LIFULLのオンボーディングの工夫や今後の伸びしろについて整理してみたいと思います。 エンジニアのオンボーディング 企業の魅力因子 ふりかえり ⭐️ Philosophy(理念・方針) 1. 会社/上位部門/自部署のビジョンを自分のことばで伝える 2. 会社/上位部門/自部署の目標やミッションを伝える 3. 自部署におけるルールやコミュニケーションのスタンスを伝える 🚀 Profession(活動・成長) 4. 開発環境の構築をサポートする 5. できるだけ早く初リリースをしてもらうサポートをする 6. 成長曲線をイメージするための指針を作る 🧑‍🧑‍🧒 People(人材・風土) 7. 自己紹介をし合う場を作る 8. 業務上で関わりを持ちそうな組織/人と引き合わせる 🎁 Privilege(待遇・特権) 9. 会社のルールや福利厚生を伝える 10. エンジニア職におけるルールや福利厚生を伝える 今後の伸びしろ 完了までのスケジューリング 周囲のメンバーとの分担 まとめ エンジニアのオンボーディング あらためてオンボーディングとは、新しく組織に加わったメンバーの職場への順応を促進することで、早期の戦力化を目指す取り組みです。 エンジニアとしては 開発環境/使用する言語/ドメイン知識/プロジェクト管理方法/ステークホルダー などを理解し、身につける必要があります。 私はLIFULLの魅力を多面的に知ってもらうことで、本人を取り巻く環境に安心を感じ、前向きに取り組んでいける流れを作りたいと考えています。 「採用の過程で伝えてきたLIFULLの魅力を、入社後に再認識してもらえるオンボーディング」について検討してみます。 企業の魅力因子 人が企業に感じる魅力を、下記の4点に分類します。 Philosophy(理念・方針) Profession(活動・成長) People(人材・風土) Privilege(待遇・特権) 人によってどの要素を重視するかは異なりますが、採用の候補者や新入社員には漏れなく伝えていく必要があります。 ここからはオンボーディングにおいて行った取り組みをこれらに分類して整理し、不足がなかったかをふりかえります。 ふりかえり 取り組んだ内容は次回以降やほかのどなたでも活用できるように、チェックリスト風に10項目でまとめてみました。 ⭐️ Philosophy(理念・方針) 1. 会社/上位部門/自部署のビジョンを自分のことばで伝える LIFULLでは経営理念を頂点として、それを落とし込んだビジョンが組織ごとに存在します。「LIFULLエンジニア像」という「エンジニアとしてありたい姿」もインプットする必要があります。これらをどのように体現していくかを自分のことばで伝えます。 note.com ビジョンは半期ごとにふりかえり見直しているため、ふりかえりの場でほかのメンバーのビジョンへの想いも聞いてもらうことで、理念を腹落ちさせていきます。 2. 会社/上位部門/自部署の目標やミッションを伝える 組織の粒度に応じた目標や戦略があるため、会社の方向性を知ってもらう意図でそれぞれを伝える必要があります。社内でのKGIやKPIの定義やとらえ方も合わせて伝えていきます。 戦略については、弊社には「戦略DAY」という各部門が戦略を発表する場があるため、この内容を視聴して理解してもらいます。直接スピーカーに質問することもできますし、必要に応じて1on1などで補足します。 3. 自部署におけるルールやコミュニケーションのスタンスを伝える 下記のようなグループ内で決めているルールを共有します。 グループメンバーの大まかな役割 カレンダーに定例で入っている会議の説明 グループで出社する曜日、リモートワークのお作法 把握していなければ翌日から困ることが多いため、配属初日で必ず伝えるようにします。 🚀 Profession(活動・成長) 4. 開発環境の構築をサポートする 基本的にはドキュメントを参考に進めてもらいますが、ドキュメントのメンテナンス不足により「ここがうまく動きません…」が起こるため、専用のSlackチャンネルを作成して伴走します。 出社時は近くに座っていつでも質問を受けられるようにし、リモートでも声をかけやすいようにSlackのハドルに常駐します。チームで声を掛け合い、新メンバーが1人になる状況をできるだけ作らないようにします。 5. できるだけ早く初リリースをしてもらうサポートをする チームの一員であることを「成果」によって感じてもらうため、軽めのバグ改修などをお願いして短期でリリースしてもらいます。周囲からの歓迎をあらためて伝えるために、リリース直後には「〇〇さんの初リリース完了しました!!!」と全体メンションで発言し、リアクションを集めるようにします。 「案件がない…」とその場で困らないために、普段からGood First Issueを整えておくことが大切だと感じます。 6. 成長曲線をイメージするための指針を作る 入社から1年間のマイルストーンを作成します。「1年後にこの領域の設計ができるようになってほしいです」「この時期にはこの規模の実装ができるようになっていると思います」という階段を作り、本人には具体の部分を埋めて目標設定に臨んでもらいます。 入社段階では、新しい環境で本人の能力が最大限発揮できるかは未知です。まずは焦らず順応してもらうため、活躍は期待していること/ただし直近での大きな成果は計算には入れていないことを伝えます。 🧑‍🧑‍🧒 People(人材・風土) 7. 自己紹介をし合う場を作る 自部署において、既存のメンバーと新メンバーがお互いに経歴や嗜好を語り、気になるところを質問し合う会を設けます。エンタメ好きなメンバーには「好きなYouTuberは?」、中途入社のメンバーには「前職のユニークな社内用語は?」など質問はさまざまです。 また、LIFULLでは4半期に1回の頻度で全エンジニアが集まる総会もあり、新入社員にはその場で自己紹介をしてもらう風土があります。 8. 業務上で関わりを持ちそうな組織/人と引き合わせる 新卒のメンバーには配属前の研修で関わった社員や同期がいますが、中途社員は相対的につながりが少ないです。今年はフロントエンドのメンバーを迎えたため、他部署のフロントエンドエンジニアやデザイナーのメンバーとのランチや飲みを調整しました。バックエンドの場合はインフラやアーキテクトの部門との連携を検討します。 一方で、 START という、別の部署の先輩社員がメンターになる制度もあります。「万一上司の私に言いづらいことがあれば、さらに上司やSTARTのメンターに相談してね」と伝えるようにしています。 🎁 Privilege(待遇・特権) 9. 会社のルールや福利厚生を伝える 大枠は入社時にバックオフィスの社員から伝えられますが、評価制度の詳細や勤務ルールなどは必要に応じて伝えていきます。 社内には 多様な取り組み があり、上司である私が認識していないものもあります。本人に近い属性の人が「こういうのもあるよ」と伝えてくれるとありがたく、そのためにも前述のつながりを増やす取り組みは重要だと思います。 10. エンジニア職におけるルールや福利厚生を伝える LIFULLには keelaiという社内のAIチャットボット や エンジニアいつでも相談 というQ&Aフォーラムなど、利用すると効率的に/安心して開発を進められるしくみがあります。 また アクセシビリティに専門性を持つメンバーの1on1 や エンジニアキャリアクリニック のように本人の成長のために活用すべきものもあり、知らなければもったいない情報が多々あります。 LIFULLでは「入社の手引き」という社内ドキュメントに入社後知っておくべき情報をまとめているため、そちらの継続的な整備を行っていきます。 今後の伸びしろ 完了までのスケジューリング 早期の戦力化を期待しているとはいえ、一気に伝えるには多すぎる情報量だと思っています。 「今伝えないといけないか」を考慮して無理のないスケジュールを組みつつ、なるべく早く戦力になってもらえるように徐々に短縮していきたいと感じています。 周囲のメンバーとの分担 あらためて、これらを上司が1人で抱えるとたいへんだと思いました。 実際にチームメンバーが「Slackハドルに常駐しておくので、開発のフォローは任せてください」「他部署のあのメンバーもランチ誘えるけどどう?」と声をかけてくれて助かっています。 特に「Profession(活動・成長)」と「People(人材・風土)」の部分はチームの総員で行うのが望ましいと感じました。スケジューリングの段階で「誰がやるか」も決めておけば効率的かもしれません。 まとめ 2024年の自部署でのオンボーディングについてふりかえりました。今年の進め方が満点だったかというとそんなことはありませんが、2人とも元気で前向きに開発をすすめてくれていて何よりだと感じています。 これは偶然ですが、先日は他職種(プロダクトマネージャー)においてもオンボーディングの取り組みが共有されました。 note.com LIFULLでは職種を問わず新メンバーを大切にし、ともに成長していく文化があります。一緒に働く仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co
こんにちは。 LIFULL Tech Vietnam (以下、LFTV)CEOの加藤です。 2023年10月にLFTVのCEOに就任し、早1年が経過しました。 この1年LIFULLグループでは「グローバル開発体制強化」を掲げ、その実現に向け多くの検討と取り組みを繰り返してきました。 そうした活動を繰り返す中で、我々は目指すべきグローバル開発を進めるためには以下の「3つの壁」を超えていくことが重要であるという結論に至りました。 「意識・理解」の壁 「仕組み」の壁 「言語」の壁 今回はその中でも主に「意識・理解」の壁を越えるためにLFTVとして行った取り組みを3つ紹介します。 3つの壁については当社CTOの以下の記事でも紹介しています。 note.com また、LFTVにおける今後のビジョンやグローバル開発体制強化の詳細は以下の記事で紹介していますので、よろしければご覧ください。 www.lifull.blog 関心・理解を深める「# times-lftv」 取り組みの概要 ベトナムからの情報発信 双方向のコミュニケーション カルチャーを醸成する「ガイドライン研修」 研修の構成 第1部:全体把握 第2部:ケーススタディ 第3部:プレゼンテーション 研修後の定着に向けた取り組み 深く戦略を理解する「OneTeam OpenTalk」 OneTeam OpenTalkの特徴 質問の事前収集 双方向の対話 隔週30分、継続的な開催 最後に 関心・理解を深める「# times-lftv」 組織の垣根を越え一つのチームとして連携を深めていくためには、お互いの理解が重要です。 物理的な距離が離れた中で、いかに身近な存在として意識できるようになるかが、結束力を強める鍵となると考えています。 そのような機会を生み出すため、ベトナムからの情報発信を行うSlackチャンネル「# times-lftv」を開設し、運用してきました。 # times-lftvでの投稿 取り組みの概要 ベトナムからの情報発信 # times-lftvでは、LFTVでの業務や取り組みに加えて、ベトナムの文化や習慣、日常生活に関する情報も幅広く発信しています。 ベトナムランチの紹介 ベトナムの交通事情 15時のTea Breakの様子 テト休暇のお祝い など こうした日常の話題を通じて、メンバーがベトナムそのものに興味を持ち、親近感を抱くことを狙いとしています。 双方向のコミュニケーション # times-lftvは単なる一方通行の情報発信にとどまらず、双方向のコミュニケーションが生まれる場としても機能しています。 運用を続ける中で、以下のような動きも見られるようになりました。 日本やマレーシアのメンバーからのコメントをきっかけに会話が広がる。 日本のメンバーからベトナムのメンバーへ向けて、日本に関するトピックが投稿される。 こうした交流を通じて、物理的な距離を越えたつながりが築かれ、メンバー間の関心が高まり、それに伴い理解もより深まっています。 カルチャーを醸成する「ガイドライン研修」 プロダクトチームとして高い成果をあげるためには、一人一人が同じ価値観を共有し、同じ行動規範によって判断することが重要です。 LIFULLグループでは社是の「利他主義」や経営理念を始めとし、日々の行動規範を定めたガイドラインなど共通して持つべき価値観が定められています。 ※ガイドライン含む企業理念は以下を参照 lifull.com これら理念を浸透し、組織の文化として定着させるため、LFTVでは「ガイドライン研修」を実施しました。 研修は大きく3部構成となっており、段階的に理解を深めるプログラムが設計されています。 研修の構成 第1部:全体把握 社是や経営理念、ガイドラインそれぞれのつながりについて理解を深めるセッション。 これにより、日々の行動規範として意識すべきガイドラインがLIFULLグループの理念全体とどのようにリンクしているかを把握します。 第2部:ケーススタディ 各ガイドラインごとに実務を想定したケーススタディを実施。 参加者はチームごとに分かれ、特定の状況においてガイドラインに沿った行動を考え、答えを導き出す形式で進行しました。 これにより、抽象的な概念を具体的な行動に結び付けています。 ケーススタディの様子 第3部:プレゼンテーション 各グループに分かれ、代表者が最も好きなガイドライン項目に対し、自身の経験や考えを結び付けたプレゼンテーションを実施。 実際のエピソードと紐づけて深掘りをすることで、ガイドラインが実際の業務や行動にどのように結び付くかを深く理解する機会となりました。 プレゼンテーションの様子 研修後の定着に向けた取り組み 今回の研修終了後も4半期に一度を目安とし、継続してプレゼンテーションの機会を設けることを予定しています。 また、10月より人事評価にガイドラインの要素を組み込んでおり、定期的な振り返りとフィードバックの機会を創出することで定着を図っています。 深く戦略を理解する「OneTeam OpenTalk」 組織全体が一体となって目標を達成するためには、ビジョンや戦略の理解が欠かせません。 しかしながら、従来のビジョンシェアリングだけでは、CEOから社員への一方通行の形式に偏りがちで、細かな部分や背景までは伝わりきらないという課題があります。 そこで、LFTVでは双方向の対話を通じてビジョンや戦略を深く理解し合うための取り組みとして、「OneTeam OpenTalk」を開始しました。 OneTeam OpenTalkの特徴 質問の事前収集 社員がビジョンや戦略に対して持つ疑問を事前に集めることで、具体的なトピックに基づいた対話を実現しています。 これにより、社員一人一人が抱く「なぜ?」や「どうして?」を解消する機会を提供しています。 双方向の対話 当日は集めた質問に対してCEOが回答しながら、テーマについて深掘りする形式で進行。 単なる説明にとどまらず、所々で社員からの追加の質問や対話を交えながらビジョンや戦略の理解を促しています。 隔週30分、継続的な開催 OneTeam OpenTalkは隔週30分という短時間で、1回につき1~2つの質問をテーマに設定して実施しています。 このように小規模なテーマ設定を行うことで、特定の内容に集中して理解を深めることができ、日々の業務に負担をかけることなく継続的な実施が可能となっています。 OneTeam OpenTalkの様子 最後に 我々LIFULLグループではLIFULL本社および海外開発拠点であるLFTV、 LFTM の垣根をなくし、一体となって開発を推進するグローバル開発を目指し日々挑戦しています。 今回はその実現に向けた「意識・理解」の壁を超える取り組みを3つ紹介させていただきましたが、LIFULL、LFTV、LFTMでは一緒に働く仲間を募集しています。 LFTVでは日本とは異なる文化や価値観に触れ、日々刺激を受けながら成長する機会に溢れています。 海外のメンバーと直接連携しプロダクト開発に携わることで、コミュニケーションの取り方や考え方の違いなど多くの面で新たな発見が得られます。 また、ベトナムならではの社内イベントも多数開催しているため、ベトナム文化の中で働きたいと考える方にとっても魅力的に感じていただけるはずです。 そして、グローバル開発を推進する中で、国や所属する開発拠点にとらわれない関わり方を目指し、幅広い領域や役割を担う機会を生み出していきます。 幅広い経験が得られる機会の中から、一人一人に合ったキャリアパスを実現するための支援も行っていきます。 グローバル開発に共感いただき、同じ志のもと挑戦したいと感じて下さった方がいらっしゃいましたらぜひともご応募お待ちしています! hrmos.co hrmos.co lifull-tech.vn lifull-tech.my
こんにちは。テクノロジー本部アーキテクトグループの福留です。最近気になっているものは model-checking/kani です。 アーキテクトグループは、LIFULL のエンジニアの開発生産性を、エンジニアに寄り添いながら向上させていくことをミッションとして活動しています。 そこで今回は、昨年から今年にかけて行った LIFULL HOME'S のリリースフローの改善、通称「即日リリースプロジェクト」について紹介します。 このプロジェクトでは、 LIFULL HOME'S のリリース作業を完全自動化し、リリースにかかる時間を 1/5 に短縮しました。 その取り組みについて、順を追って説明します。 従来の LIFULL HOME'S のリリースフロー リリースフローの課題 課題 1: リリーサーの負担が大きい 課題 2: リリースまでの時間が長い 即日リリースの目標 即日リリースの適用 Phase 1. リリーサーの確認業務自動化 Phase 2. リリース作業の自動化 Phase 3. リリースフローの高速化 まとめ 従来の LIFULL HOME'S のリリースフロー LIFULL HOME'S はいくつかのマイクロサービスで成り立っています。 このマイクロサービスでの機能の公開、いわゆるリリースは「リリースチケット」と呼ばれる Jira チケットと GitHub の PullRequest によって管理されています。 リリースチケットは PullRequest ごとに作成される Jira チケットで、開発グループ長と、担当企画のリリース承認と、リリース状況の管理を行います。 また、LIFULL HOME'S のステージング環境を含めた環境は、テスト環境、プール環境、本番環境の 3 種類があります。 それぞれの環境は以下のような役割を持っています。 テスト環境 develop ブランチの内容が反映される テストデータによる動作確認が可能 プール環境 release ブランチの内容が反映される 個人情報等のセンシティブ情報をマスクした、本番環境相当のデータによる動作確認が可能 本番環境 master ブランチの内容が反映される ユーザーに提供される本番環境 従来のリリースフローでは、これらを用いて以下の流れでリリースが行われていました。 1 日目 (Jira) リリース承認を開発グループ長・企画担当者からもらう (GitHub) PullRequest を develop ブランチにマージし、テスト環境に反映 (テスト環境) テスト環境で動作確認 2 日目 (プール環境) 開発者がプール環境で動作確認 3 日目 (本番環境) 開発者が本番環境で動作確認 以上をまとめると、従来は次の図のようなリリースフローでリリースが行われていました。 従来のリリースフロー このフローの中では、「リリーサー」と呼ばれる人たちが、以下のような作業を行っていました。 PullRequest とリリースチケットの突き合わせ develop ブランチを release ブランチにマージし、プール環境へ反映 release ブランチを master ブランチにマージし、本番環境へ反映 反映された PullRequest に対応するリリースチケットのリリースステータスを「プール反映完了」「本番反映完了」などに変更 リリーサーの作業 リリースフローの課題 このリリースフローには、以下のような課題がありました。 課題 1: リリーサーの負担が大きい リリーサーの作業はすべて手作業で行われている上、上記のリリースフローで運用されているリポジトリは 5 つあります。ゆえに、リリーサーの確認作業はとても煩雑なものでした。 このリリーサーが手作業で行う作業は、月曜から木曜まで、1 日 4 時間ずつ、合計で 16 時間もかかっていました。 しかも、リリーサーはリリースフローと、リリースされるアプリケーションについて大まかな知識を持っている必要がありました。そのため、比較的社歴の長い、経験豊富なエンジニアがリリーサーを担当する傾向にありました。 つまり、 経験豊富なエンジニアの時間がリリーサー業務に、週 16 時間も使わなければならない という、もったいない事態が起こっていました。 課題 2: リリースまでの時間が長い 図の通り、開発者が変更を develop ブランチにマージしてからリリースされるまでには、約 3 日が必要です。 リリースまでのリードタイムは、最短で約 40 時間かかっていました。 本来なら新しい価値をどんどんユーザーに提供していきたいはずが、 価値提供のボトルネックがリリースフローにもある ことは明白でした。 即日リリースの目標 このような課題から、アーキテクトグループでは、以下の目標を立て、リリースフローの改善を行うことにしました。 リリーサー業務を自動化し、リリーサーという存在を不要にすることで、エンジニアが開発に集中できる環境を作る リリースフローを効率化することで、develop マージ後 1 日以内でのリリースを可能にする 2 番目の目標から「即日リリースプロジェクト」と名付け、3 つのフェーズに分けて取り組むことにしました。 即日リリースの適用 Phase 1. リリーサーの確認業務自動化 最初に、リリーサーの作業で最も時間を取られていた確認業務を自動化することから始めました。 ところが、リリーサーはリリースチケットの上で、「リリース承認されていること」以外に何をチェックしているのか、具体的には分かっていませんでした。 というのも、リリーサーは部署をまたいで持ち回りで担当が決まっていたため、公式な引き継ぎ資料がなかったためです。 非公式な引き継ぎ資料はあったものの、あくまでリリーサーが所属する部署内での資料だったため、チェックしている内容はリリーサーによってまちまちになっていました。 たとえば、あるリリーサーは最低限承認されていることをチェックしているが、あるリリーサーは PullRequest の内容まで入念にチェックしているらしい、という状況のようでした。 そこで、リリーサーのチェックを一緒にやってみることで、実際のチェック内容を把握しつつ、標準となるチェック項目を作成しました。 具体的なチェック項目については割愛しますが、人間でなければ判断できないチェック項目はリリーサーやエンジニアとの合意の上で削減しました。そして、自動化しやすく、かつ守るべきところは守れるチェックリストに落とし込みました。 最終的にできたチェック項目について、手元で動かせる cli ツールを作成してリリーサーに使ってもらうことで、作業の負担を大幅に減らしました。 Phase 2. リリース作業の自動化 Phase 1 ではリリース前の確認作業を自動化しました。ここから各環境に反映していく作業、つまりリリース作業も自動化することで、リリーサーの存在を不要にできます。そこで、リリース作業を自動で行ってくれるアプリケーションの開発を計画しました。 リリース作業とは単に GitHub のマージボタンを押すだけかと思いきや、実はそうではありません。 LIFULL HOME'S を構成するアプリケーションは API 層・BFF 層・フロントエンド層に分かれており、それぞれに依存関係があります。 この依存関係を踏まえると、前段のアプリケーションがリリースされたことを確認してから、次のアプリケーションをリリースしなければなりません。 たとえばフロントエンドと BFF に同時に変更を行った場合、BFF の方が先にリリースされてしまうと、フロントエンドの参照部分が壊れてしまい、障害につながります。 つまりリリーサーは、「前段のアプリケーションのリリースが完了したこと」を確認してから、次の段のアプリケーション(リポジトリ)のマージボタンを押さなければなりません。 ところで LIFULL には、 KEEL という全社で横断的に利用しているアプリケーション実行基盤があります。KEEL のワークロード監視ダッシュボードからは、現在のアプリケーションの状態、具体的には Kubernetes の Pod の状態を確認できます。 KEEL については、ぜひ以下をお読みください。 www.lifull.blog KEEL チームに依頼し、Pod の状態として、現在デプロイされている Git のコミットハッシュを追加してもらいました。これで、リポジトリの master ブランチのコミットハッシュと Pod のコミットハッシュを比較できるようになりました。 PodのステータスにSHA-1ハッシュを表示 リポジトリのコミットハッシュと Pod のコミットハッシュが同じになったのを見れば、アプリケーションがリリースされたかどうかを自動で判断できるようになりました。 また、リリースの進捗状況を Slack へ通知するようにしました。 通知内容は以下のようなものがあります。 現在どのアプリケーションをリリースしているのか GitHub の障害などによるマージの失敗 カナリアリリースの失敗 これらの内容を、対処方法も含めて通知することで、リリースの進捗状況をほぼリアルタイムで把握できるようにしました。 slack通知の例 同時に、このアプリケーションに、リリーサーが行っていたチェックを自動化するツールを組み込むことで、リリースのすべてを自動で行えるリリースシステムが完成することになりました。 リリースシステムによって自動化 Phase 3. リリースフローの高速化 リリーサー業務の自動化とは別に、リリースフローの高速化にも取り組みました。 従来のリリースフローをおさらいすると、次の図のようになっていました。 従来のリリースフロー(再掲) プール環境とは、本番環境のデータから個人情報をマスクしたデータを利用できる環境で、主に本番相当の環境としてテストを行うために利用されています。 この反映と確認のために 1 日かけることが、結果としてリリースまでのリードタイムを長くしていました。 そこで、プール環境にテスト環境と同じ develop ブランチを参照させることで、 テスト環境とプール環境へ同じ日に反映を行い 、リードタイムを短くすることを計画しました。 まずエンジニア全体にアイデアの共有を行い、そこで受け取った質問に対して回答や説明をしました。 当時の質問票 そして、機能追加に責任を持つ企画・エンジニアの代表の方にプレゼンを行い、合意を得ることで、リリースフローの変更を行うことに決まりました。 リリースフロー変更のプロポーザルの一部 最終的にできたリリースフローは以下のように、シンプルなものになりました。 新しいリリースフロー 1 日目 (Jira) リリース承認を開発グループ長・企画担当者からもらう (GitHub) 開発者が PullRequest を develop ブランチにマージし、テスト環境とプール環境に反映 (JIRA) リリースシステムがリリースチケットのステータスを変更 開発者がテスト環境とプール環境で動作確認 2 日目 リリースシステムが develop ブランチを master ブランチにマージし、本番環境に反映 (JIRA) リリースシステムがリリースチケットのステータスを変更 開発者が本番環境で動作確認 このリリースフローの変更に合わせて、以下のようなリリースのルールを設けました。 (即日リリース) 当日 11 時までにテスト環境とプール環境で動作確認できていれば、その日のうちにリリース可能 (即時リリース) プール環境での確認が必要なく、KEEL の機能で作成される Ephemeral Environment *1 で十分にテストできていれば、 直接 master ブランチにマージしてもよい ルール 1 によって、従来のリリースフローでリリースされるまでに約 40 時間かかっていたものが、最短 8 時間、つまり 約 5 倍速く リリースできるになりました。 また、ルール 2 に従えば、リリースまでのリードタイムはより短くなり、 もはやリードタイムは存在しません。 これらの改善だけが原因ではないと思いますが、年間のリリース数は、 即日リリース適用以前と比べて約 20 %増加しました 。 まとめ LIFULL HOME'S のリリースフローを改善することで、リリーサー業務を自動化し、リリーサーという存在を不要にできました。その結果、開発者が、開発業務により集中できるようになりました。 また、リリースフローを効率化したことで、リリースまでのリードタイムを大幅短縮し、価値提供が従来よりも速くなりました。 即日リリース PJ は、アーキテクトグループならではの「開発者に寄り添った開発生産性の向上」ができた、良い例だと思います。 今後も、エンジニアの生産性向上に向けて、さまざまな取り組みを行っていきます。 最後に、LIFULL ではともに成長していける仲間を募集しています。 12 月 2 日現在、アーキテクトグループでもメンバーを募集中です!よろしければこちらのページもご覧ください。 hrmos.co hrmos.co hrmos.co *1 : Firebase のプレビュー環境のような、PullRequest に紐づいて作成されるテスト環境
こんにちは。クオリティアーキテクトグループ(以下、QAG)でQAエンジニアをしている片野です。 QAGでは横断組織として自動テストやツール開発、プロセス改善などのしくみ作りに取り組んでいます。 今回は、横断QA組織が開発組織の品質に関する課題を見つけるための取り組みについて紹介します。 QA組織の紹介 背景 やったこと QAサークル QA通信 QA探検隊 まとめ QA組織の紹介 LIFULLでは設計や実装を行っている開発エンジニアがテストも行っています。 ですので、QAエンジニアのプロジェクトの関わり方としては、下記のような開発者への支援活動を行っています。 プロジェクト支援 テスト計画サポート 自動テスト相談 テストのお悩み支援 提供ツール・データ テスト仕様書の共通テンプレート Bucky 開発プロセス・そのたの活動 Bucky Shift-Left 探索的テスト実施・導入支援 組織の成り立ちについてはこちらの記事をご覧ください。 https://www.lifull.blog/entry/2019/12/15/000000 背景 横断QA組織の立場としては次のような課題があります。 社内には、さまざまな開発や保守のプロジェクトが同時に動いているので、QAGがすべてのプロジェクトへ均等な支援を行えない 各プロジェクト・組織の品質面で困っている事や改善したい事がQAGから見えにくい 各プロジェクトの困りごとは相談を受けてから気付くことが多く、QAGは受け身になることが多い やったこと 上記に書いた課題を解消するために、下記の3つの活動を実施しました。 QAサークル QAサークルは、QAGと開発チームのコミュニケーションの機会を増やす事を目的に、チームや個人でたまっている品質に関する課題やモヤモヤとした問題点の意見交換を行う場です。 開催形式はQAGがコンテンツを作成して発表する講義形式やみんなで意見を交わすディスカッション形式など、毎回試行錯誤しています。   ※過去に実施した探索的テストをテーマにした会の目次、チャーター作成ワークの結果 実施データ 開催回数:3回 開催頻度:3ヵ月に1回(1時間)程度 延べ参加人数:26人 開催テーマ:テスト全般、 テスト仕様書の共通テンプレート 、探索的テスト 狙い QAエンジニアと開発者が定期的にコミュニケーションをとり、相談がしやすい下地づくりをする QAGについて知ってもらう QAGが行っている施策の普及 工夫している点 タイムリーな話題をテーマに選定することや地道な広報活動を行った 開催テーマに関する良い事例を持っている方にインタビューし、QAサークル内で事例紹介をした ワークで実際に手を動かしてもらい理解度を高めた 効果 当初は想定していなかったエンジニア以外(企画職)の方の参加 少しずつ着実に、個別の相談や支援につながっている 参加者はイベントを通して、下記のような学びや気付きがあったそうです。 今まで知らなかった新しいテスト手法(探索的テスト)について理解が深まった  困ったらQAに相談しようという心持ちを作れた ※探索的テストについては別の機会にブログを書いてみたいと思います。 QA通信 Slackに最近のQAGの取り組みについての紹介記事を毎月投稿しています。 実施データ 投稿回数::16回 開催頻度:1ヵ月に1回 狙い QAGの認知度向上 QAGへのサポート依頼数増加 工夫している点 Block Kit Builder でフォーマットを統一し可読性を向上させた 絵文字を効果的に使用することで、書き手の感情を読み手に伝えるとともに情報をコンパクトにまとめて伝達した 効果 投稿した記事を読んだ人が、同僚に読むことを薦めているslackメッセージが複数見受けられ、QAGや開発したツールの認知度向上に寄与した QAGのツールやお知らせを気軽に発表できる場になった QA探検隊 Slackに投稿された品質に関するキーワード(たとえば「バグ」、「テスト」)を自動で定期的に検索し、困っている人がいないかを探しました。 実施データ 実施期間:2024/1〜2024/5 不定期に実行(社内イベント開催直後など) 狙い slack上に流れている品質課題に関する情報を能動的に取得する 工夫している点 社内で開発したツールを用いてslack api経由でエゴサーチを実施した 膨大な検索結果を効率的に仕分けするしくみを作成した 効果 テスト仕様書の共通テンプレートについての困り事を素早く拾う事ができ、改修や機能追加の優先度付けに役立った 各組織のSlackチャンネル毎のキーワード発話量を可視化でき、プロジェクト支援先を決める一助となった 下記の理由のため、現在QA探検隊は定期的な活動をしていません。 膨大な検索結果を効率的に仕分けするしくみを作成しましたが、完全な自動化ができていなく、手作業の部分もあるため費用対効果が見合わなかったため。 まとめ 横断QA組織が開発組織の品質に関する課題を見つけるための取り組みについて紹介しました。 活動を通して、課題を見つけるためには定期的に開発組織とコミュニケーションを取ることと、QAGが何をしているかを定期的に広報することが大切だと感じました。 今後も今回説明した活動やブログなどを活用して、QAGが実施している事を広めていきたいと思います。 最後まで読んでいただきありがとうございました。
こんにちは、エンジニアの中島です。 この記事はフロントエンドのパフォーマンス調査の記録を記事にしたものです。 弊社は自社プロダクトのパフォーマンス劣化を検知するために WebPageTest を導入し、数時間に一度自動計測をするようにしています。 そこでとある日から TBT (Total Blocking Time) が劣化しているようなので原因を調査してほしいという依頼が来ました。 現象確認 まずは本当に問題が起きているかの確認です。 WebPageTestのタイムラインを見てみます。 たしかにいくつかのタイミングで大きめのスタイルの再計算が走っていることがわかりました。 しかしながら、これらが"ある日を境に"、TBTの大幅な劣化を引き起こした犯人かどうかはまだわかりません。 数日分のタイムラインをみて確認する必要があります。 タイムライン情報を一つ一つ目でみて確認するのも大変だなと思ったのでこのタイムラインの元になっているjsonファイルをパースして導くことができないかと考えました。 生データを見るとあまり詳しくはわかりませんが以下のように配列で50万行ほどログがつまっているようでした。 { ... " traceEvents ": [ { " args ": { ... } , " name ": " XXXX ", " dur ": 2 , .... } , { " args ": { ... } , " name ": " XXXX ", " dur ": 1 , .... } , { " args ": { ... } , " name ": " XXXX ", " dur ": 3 , .... } , { " args ": { ... } , " name ": " XXXX ", " dur ": 1 , .... } , ... ] } nameにはどういうログなのかが記載されており、具体的にはFunctionCallやUpdateLayoutTree、ResourceFinishといった値がみられました。 またdurはdurationの略のようで1/1000ms単位の数値が入っていることがわかりました。 ざっくりとこのログに対応する モデル を作り、そこから10ms以上のUpdateLayoutTreeだけを抽出してその実行時間を出力してみれば少なくとも発生の根拠になるかなと考えました。 WebPageTestを簡単にスクレイピングして該当日の前後数日のtimeline情報のjsonファイルのurlを抽出し、そのコンテンツを取得してパースしていきます。 records = Performance :: Timeline :: Record .from_timeline( " path/to/timeline.json " ) p ([date, records .select(& :update_layout? ) .select{|record| record.duration > 10 } .map(& :duration )] (タイムラインデータのモデル) Performance::Timeline::Record class Performance :: Timeline :: Record def initialize (record) @record = record.deep_symbolize_keys end def name @record [ :name ] end def duration ( @record [ :dur ] || 0 ) / 1000.0 end def update_layout? name == ' UpdateLayoutTree ' end def self . from_timeline (file) result = JSON .parse( File .read(file)) records = result[ ' traceEvents ' ] records.map {|record| new(record) } end end 実行結果 [YYYY-MM-DD 19:41:43 +0900, [15.948]] [YYYY-MM-DD 19:41:43 +0900, [15.984]] [YYYY-MM-DD 19:41:48 +0900, [20.741]] [YYYY-MM-DD 19:41:09 +0900, [11.888]] [YYYY-MM-DD 19:42:24 +0900, [25.136]] [YYYY-MM-DD 19:41:59 +0900, [14.453]] [YYYY-MM-DD 19:42:15 +0900, [14.962, 13.14, 11.3871, 11.410]] [YYYY-MM-DD 19:41:49 +0900, [15.190, 15.919, 10,873, 11.733]] [YYYY-MM-DD 20:57:31 +0900, [16.211, 10.861, 15.085, 11.209]] [YYYY-MM-DD 20:59:48 +0900, [26.105, 19.971, 17.264, 11.762]] [YYYY-MM-DD 20:55:14 +0900, [18.890, 15.410, 12.570, 14.569]] [YYYY-MM-DD 19:37:16 +0900, [17.059, 11.72, 11.735, 13.011]] [YYYY-MM-DD 19:38:57 +0900, [14.816, 17.057, 13.122, 10.301]] 実行結果を見ると、確かにある日を境にスタイルの再計算が急増してることが確認できました 原因調査 ある日を境にということであれば、リリースだったり、GTMなどのツール経由のタグ挿入などが疑われます。 WebPageTestは数時間に一度回しているので、同じ手順で問題発生の時間を特定します。 まずはその特定された時間にリリースされたものを一つずつ洗っていきます。 しかしながら今回は対象となるページに影響を与えるような実装はどこにも含まれていませんでした。 そうなるとツール経由のタグ挿入の影響の線が濃くなります。 WebPageTestとchromeのdevtoolsで計測したPerformanceのログは中身が基本的に同じなので実際に手元のブラウザでそれらのツールをネットワークブロックした時とそうでない時のログを見比べて判断していきます。 とはいえ、色々なものの影響をうけるためtimelineが完全に安定することはなく、複数回分のログを取得して判断していく必要があります。 その工程が面倒なのでPuppeteerを使って自動化していきます。 require ' puppeteer-ruby ' ... Puppeteer .launch( headless : false ) do |browser| page = browser.new_page block_list = [ # タグ挿入系のサービスのパス (ex: gtm) # ... # ... ] # ネットワークリクエストのインターセプトを有効化 page.request_interception = true page.on( ' request ' ) do |request| if block_list.any? {|uri| request.url.include?(uri) } request.abort # リクエストを中止してブロック else request.continue end end # とありえず10回分計測する ( 1 .. 10 ).each do # トレースの開始 page.tracing.start( path : ' trace.json ' ) # 検証対象のページに移動 page.goto( ' https://www.homes.co.jp/path/to/target/ ' ) # トレースの停止 page.tracing.stop # トレース結果の読み込み trace_data = File .read( ' trace.json ' ) trace_json = JSON .parse(trace_data) records = Performance :: Timeline :: Record .from_timeline( ' trace.json ' ) p records.select(& :update_layout? ) .select{|record| record.duration > 10 } .map(& :duration ) end end このように検証したところ、今回はとあるタグ挿入ツールをブロックすると問題のスタイルの再計算はなくなることが判明しました。 ツールから挿入されてるタグを列挙し、二分探索でブロックしていき原因となるスクリプトを特定します。 今回はこのような手順で現象の確認と原因の特定ができました。 最後に この調査方法が王道的な調査方法かはわかりませんが、生ログを見る調査方法は汎用性の高いアプローチなので何かの参考になれば幸いです。 LIFULL ではともに成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co https://hrmos.co/pages/LIFULL/jobs/010-9999 hrmos.co
こんにちは、エンジニアの中島です。 この記事は2024年10月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。 この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。 目次 目次 サービス改善 LIFULL HOME'S iOSアプリのお気に入り画面のアクセシビリティ対応 アクション操作物件にチェックを入れる例 育成・啓発の取り組み 各開発グループを対象にした勉強会実施 LIFULLアクセシビリティガイドラインのWCAG2.2対応の開始 アクセシビリティ1on1 お知らせ サービス改善 本期間中はアクセシビリティ推進部署による修正はなかったため、各サービス開発部署の取り組みのみを紹介させていただきます。 LIFULL HOME'S iOSアプリのお気に入り画面のアクセシビリティ対応 iOSアプリ開発チームが、お気に入り追加した物件の一覧画面のアクセシビリティ対応を行いました。 修正内容は以下の通りです。 ナビゲーション内の各ボタンの読み上げ内容を意味の伝わるものに修正 お気に入り解除や物件チェックなどの機能をVoiceOverで操作できるように修正 コントラストが不足していた一部テキストのコントラスト調整 各ボタンの十分なタップ領域確保 物件コンテナ内の各機能はアクションに登録することでVoiceOverからも操作ができるようになりました。 アクション操作物件にチェックを入れる例 アクション起動 チェック機能を呼び出し チェック実行 育成・啓発の取り組み 各開発グループを対象にした勉強会実施 もともとフロントエンドエンジニアやデザイナー向けに1対1のアクセシビリティ育成を行っているのですが、それに加えて社内の大半の開発部署がアクセシブルなアプリケーション開発を自力で行っていけるようになることを目的として部署ごとに学習機会を設けることにしました。 対象となる開発部署は20グループ程度で、本期間中は3つのグループに受講いただきました。 内容は スクリーンリーダーを利用している当事者の動画の視聴 動画視聴であらわになった問題点とそれに言及しているWCAG項目の対応確認 どのように実装すれば支援技術でUIの役割や状態を伝えることができるかの学習 となっています。 LIFULLアクセシビリティガイドラインのWCAG2.2対応の開始 現在のLIFULLアクセシビリティガイドラインはWCAG2.1をベースに作っており、新しく認知分野やモバイルデバイスへのサポートを含んだWCAG2.2の内容を取り込めておりませんでした。 ワーキンググループ内で各追加項目の読み込みを行い、各項目をどのように反映させるかを決定し、具体的な作業に入り始めました。 アクセシビリティ1on1 本期間中はフロントエンドエンジニア9人、アプリケーションエンジニア1人、デザイナー1人に対して行いました。 内容はWCAGの解説、APG(aria authoring practices)の解説、coga-usableの解説、実際のアプリケーション開発時でのアクセシビリティ配慮に関する相談などが主なものとなります。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co
グループデータ本部データサイエンスグループの嶋村です。 LIFULLは、2024年10月15日(火)から開催される 国土交通省初となるデータコンペ 「 第1回 国土交通省 地理空間情報データチャレンジ ~国土数値情報編~ 」に対して 協賛 をしており、LIFULLの主力サービスの一つである LIFULL HOME’Sのデータセットを提供 しています。今回、その取り組みを紹介したいと思い記事を書きました。この記事をご覧の皆様も是非コンペにご参加いただけると嬉しいです。 本コンペでの企画運営は一般社団法人不動産建設データ活用推進協会(PCDUA)になりますが、LIFULLはPCDUAに特別会員として加入しており、​不動産および建設分野のデータ活用やデジタル推進のエコシステム構築を目指しています。その一環として、不動産・建設分野におけるデータ活用の活性化になればと思い、LIFULL HOME’Sのデータセットを提供することになりました。 これまで、学術機関向けに対しては、国立情報学研究所(NII)の情報学研究データリポジトリ(IDR)を通じて、「 LIFULL HOME’Sデータセット 」を公開してきました。当時の公開の経緯などは是非下記の過去の記事をご覧いただきたいと思いますが、多くの研究者の方々に利用していただき、たくさんの研究成果の創出にも貢献できたと実感しています。 「HOME'S」の物件・画像データセットを研究者に提供開始します! - LIFULL Creators Blog 「HOME'Sデータセット」に高精細度の間取り図画像データを追加しました - LIFULL Creators Blog 「IDRユーザフォーラム2023」参加報告 - LIFULL Creators Blog 一方で、民間に対して広く公開する取り組みは 今回が初めて となり、どの程度のコンペ参加者が集まるのか、コンペ参加者によってどのようなデータ分析がされるのか、とてもワクワクしています。社内のデータを外部へ提供することはリスクにもなりえるのですが、一方で多くの社外の方々との連携につながる良い機会でもあり、多くの方にデータに触れていただきLIFULLを少しでも知っていただくきっかけになればと願っています。 また、今回他の企業も協賛としてデータセットや分析環境を提供をして下さっており、 オープンデータと複数の民間企業のクローズドなデータを組み合わせて分析できる機会は非常に稀 だと思います。詳細は コンペ特設サイト をご覧下さい。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービスの研究開発」を加速して下さる シニアデータサイエンティストを募集 しています。また、事業部内でもデータ分析で事業に貢献する データアナリストも募集 しております。 興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co hrmos.co
こんにちは、エンジニアの中島です。 この記事は2024年9月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。 この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。 目次 目次 サービス改善 売買物件登録画面の各コントロール・グループへの名前設定 育成・啓発の取り組み LIFULL Creative School WCAG輪読会 アクセシビリティ1on1 お知らせ サービス改善 本期間中の改善取り組みのターゲットはLIFULL HOME'S 賃貸・流通マネージャーサイトです。 こちらはLIFULL HOME'Sをご利用いただいている会員様(不動産会社様)が、物件を掲載する際にお使いになる管理画面になります。 諸事情で発表できないものもありますが公開可能な取り組みを紹介させていただきます。 売買物件登録画面の各コントロール・グループへの名前設定 前回のお知らせでは賃貸の物件登録画面におけるコントロールの名前設定についてご紹介しましたが、売買物件登録画面についても同様の作業を行いました。 名前のないコントロール・及びグループに適切な名前を設定し、支援技術ユーザーにとってもコントロールの目的が理解しやすいように修正を行いました。 育成・啓発の取り組み LIFULL Creative School 弊社のデザイナーや広報・企画職の一部を含むクリエティブ本部のメンバーは、LIFULL Creative Schoolという一回2時間程度の勉強会を不定期で行っています。 9/13に行われた会では、啓蒙活動の一貫としてアクセシビリティ推進WGのメンバーが講師を担当し、アクセシビリティに関する基本的な知識を共有しました。 用語の整理から始まり、弊社ビジョンや品質基準、Design Philosophyとの照らし合わせ、障害当事者のUT動画の視聴、WCAGの簡単な解説、すぐに身につけられるチップスの共有・自社事例を交えた座談会などを行いました。 WCAG輪読会 アクセシビリティやっていき勢向けにWCAGの輪読会を隔週で行っています。 本期間中は9月19日に行われました。 範囲は達成基準1.4.6〜1.4.7です。 アクセシビリティ1on1 本期間中はフロントエンドエンジニア1人、アプリケーションエンジニア1人、デザイナー1人に対して行いました。 過去の育成対象者が育成する側に回るといった循環ができるようになってきました。 内容はWCAGの解説、APG(aria authoring practices)の解説、coga-usableの解説、実際のアプリケーション開発時でのアクセシビリティ配慮に関する相談などが主なものとなり ます。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co
プロダクトエンジニアリング部の海老澤です。 普段は LIFULL HOME'S の 賃貸領域 のフロントエンド開発をしています。 今回はLIFULL HOME'S の UI 構築を手助けするコンポーネントカタログ(以下「カタログ」)を作った取り組みについて紹介します。 最初にお断りしておくと、この「カタログ」はいわゆる 「デザインガイドライン」「デザインシステム」のことではありません🙇 背景 LIFULL では日々プロダクトの改善を行っており、UI の改修もそのひとつです。 しかし以前から複数のフロントエンドエンジニアが開発生産性と品質面での課題を感じていました。 開発生産性の課題 LIFULL HOME'S の UI はすべて、サービスのベースとなる「LIFULL HOME'S デザインガイドライン」をもとに設計されています。 このデザインガイドラインは現在 Adobe XD で公開されており、コードベースのものはありませんでした。 LIFULL HOME'S ではマイクロサービス化が進んでいるため、必然的に各リポジトリで同じような HTML/CSS をゼロから再生産しています。 共通利用できるコードがあれば開発生産性の向上にもつながるのに、それがないのはもったいないと感じました。 品質面の課題 UI の改修のすべてをフロントエンドエンジニアで受け持っているわけではなく、普段あまり HTML/CSS を触らないエンジニアが担当することもあります。 そのためマークアップやスタイリングの品質がまばらでレビュアーの匙加減で決まっているところがありました。 また、アクセシビリティ品質の担保にも課題がありました。 社内ではアクセシビリティを重視する文化が定着しており、 LIFULLアクセシビリティガイドライン に準じてコーディングをしています。 しかしその品質をすべてのエンジニアが担保するのは非常に難易度が高いです。 フロントエンドエンジニアが改修する場合でも、複雑な js とアクセシビリティ要件が絡むコンポーネントの場合は開発に時間がかかってしまいます。 このような問題を解消するため、「誰もが汎用的に使える実装リファレンス集」がほしいと考えました。 実現したいこと このカタログで実現したいことは以下です。 プロダクトの技術スタックに依存せずコピー&ペーストできる マークアップとアクセシビリティの品質を備えていること カスタマイズに制約は設けないこと 1. プロダクトの技術スタックに依存せずコピー&ペーストできる コンポーネントの展開方法には大きく分けて2つあります。 npmパッケージを配布して利用箇所でimportするやり方と、ファイルまたはコードのコピー&ペーストで展開するやり方です。 今回はコピー&ペーストを採用しました。 パッケージ化のデメリット パッケージ化は以下の理由から開発生産性を損ねる可能性が高いと判断しました。 カスタマイズの自由度が制限される サービスごとに多様な意思決定・UI 個別最適を行っているため、微調整がしづらくなる しくみが複雑化する カスタマイズ用のパラメータを追加し続けるとコンポーネント自体の使い勝手が悪くなる 改修の意思決定のためのコストがかかり、スピード感が損なわれる コピー&ペーストであればコードだけ持っていって各サービスへの最適化もしやすいですし、必要な機能だけのせていけるため複雑化も避けられます。 採用技術とコピー&ペーストの親和性の高さ LIFULL HOME'S はマイクロサービスが進んでおり、フロントエンドではさまざまな技術選定がされています。 ただ Tailwind CSS と Stimulus はほとんどのプロダクトで採用されており、既存の技術構成に後載せすることも比較的容易です。 そのためこれらをベースにコードを掲載していくことにしました。 Tailwind CSS は付与されたクラスから自動的に CSS を作成してくれるため、サービスに合わせてスタイリングの微調整が可能です。 Stimulus も以下のような特徴からコピー&ペーストとの親和性がとても高いです。 バックエンドのフレームワークを問わない 依存関係がなくビルドシステムを必要としない アタッチも HTML に data 属性を付与するだけで良い 汎用的な振る舞いを切り出したコントローラの組み合わせで作れる これらの理由からコピー&ペーストの方が開発生産性の向上のアプローチには良いと考えました。 2. マークアップとアクセシビリティの品質を備えていること コンポーネントカタログに掲載されるパーツは、最低限のマークアップとアクセシビリティの品質を備えていなければなりません。 品質の高いものがコピー&ペーストできることで、利用するプロダクトの品質レベルが底上げされます。 アクセシビリティ要件を満たす実装はしばしば難しく知識と経験を要しますが、コピー&ペースト元のコードがアクセシブルであることで、ジュニアレベルのエンジニアでもアクセシブルなプロダクトづくりに貢献することができます。 3. カスタマイズに制約は設けないこと 使用にあたって改変の制限はありません。 このカタログでは 素 HTML + Tailwind CSS + Stimulus をそのまま載せているので、スペーシングや振る舞いの調整も容易です。 そこからコンポーネント化するのは各サービスの開発者に委ねており、特に縛りは設けていません。 このカタログはあくまでも「実装リファレンス集」としての機能のみを提供し、UI 実装の初動を速く正確に行うことを目指しています。 成果物 LIFULL HOME'S Frontend Recipes こうしてできあがったのが LIFULL HOME'S Frontend Recipes です。 開発は社内の有志3名で行いました。 フレームワークは Astro を使っています。 軽量かつ mdx でサクサク書けるためカタログサイトにはぴったりのフレームワークでした。 現在は以下のコンテンツを配信しています。 Foundation カラートークン、アイコン、フォントなど最小限の要素 Objects ボタン、カード、リスト、フォームパーツなどの Component role, aria-* の付与のほか、フォーカス時や強制カラーモード時でも見やすい状態を担保 ちなみに英語で作成されていますが、これは近年海外拠点にある子会社と一緒に開発することが増えているためです。 ポイント コード出力形式の設定が可能 プロダクトに合わせて以下の設定が可能です。 HTML <-> JSX の切り替え インデント形式の指定 タブ or スペース、およびその数 Tailwind CSS の prefix の指定 後から Tailwind CSS を入れたリポジトリで prefix を指定しているパターン があるため コードの出力形式を設定できる機能 アクセシビリティに関する注意事項の記載 コードをコピー&ペーストするだけでなく、見て学べるような作りにしました。 checkbox コンポーネントのアクセシビリティ注意事項 フォーカスリングの可視性や強制カラーモード時の表示など、ピンと来にくいものはサンプルコードで比較できるようにしています。 フォーカスリングの可視性の比較 強制カラーモード時の表示 デザインガイドラインに掲載されていないコンポーネントも掲載 Q&Aコンポーネント たとえばこちらの Q&A 方式のコンポーネントですが、デザインガイドラインには載っていません。 しかし実際の業務ではたびたび見かけるパターンのため、カタログには収録しています。 とにかくあるあるなパターンを集めていくことで開発生産性の向上を狙っています。 ちなみにガイドラインに記載されているコンポーネントについてはラベリングを行っていますので、そこで区別は可能です。 テキストリンクのページ 終わりに カタログの公開後に自分でも使ってみましたが、どんな環境であろうとコピー&ペースト→クラス微調整だけで済むためかなりスピーディなコーディングができました。 既存のプロダクト改修はもちろんですが、新規のプロジェクトでプロトタイプをさっと作る時にも役立ちそうです。 今後は DatePicker などの難易度の高いコンポーネントや、 Behavior としてコンポーネントのスタイルに依存しない Stimulus Controller を拡充していく予定です。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co
こんにちは! LIFULLエンジニアの吉永です。 普段はLIFULL HOME'SのtoC向けCRMチームにてエンジニアリングマネジャーをやっています。 本日は私がCRMチームにジョインしてからの4年間で行ってきたチームとしての技術負債解消活動について紹介します。 技術負債解消活動の変遷、技術負債解消と新規開発がどのようなバランスで進められてきたのか、現状はどうなっているか、今後取り組んでいきたいことについて触れていきます。 アジェンダ 技術負債解消活動の変遷 技術負債解消と新規開発のバランス 現状について 今後取り組んでいきたいこと 最後に 技術負債解消活動の変遷 2020年~2021年ごろ 当時はレコメンド物件をユーザー毎に取得してメールコンテンツを作成するサーバ、LINEサーバからのWebhookで応答するチャットボットサーバ、メールを送る為のマーケティングオートメーションツールなどさまざまなシステムがプログラミング言語もプラットフォームもバラバラな状態で構築されていました。 EC2インスタンスもたくさんあり、デプロイもほとんどが手動対応が必要な状態でした。 これらの課題を解消しようと動き始めたのが2020年ごろの話です。 役割が細かくなりすぎてしまっていたアプリケーションサーバ群を一つにまとめ、プログラミング言語にGoを採用、デプロイはGitHub Actionsで自動的に行えるようにシステムをリニューアルして2021年の初頭にファーストリリースされました。 この時リリースされたシステムの名称がeos(Elastic Omni channel Service)と言います。 その当時の活動については下記の記事にて紹介されています。 www.lifull.blog www.lifull.blog www.lifull.blog 2022年~2023年ごろ eosリリース以降はレガシーシステムをeosへ移植していきました。 さまざまなプラットフォームかつプログラミング言語もバラバラだった状態は少しずつ解消されていき、この頃にはeosの開発時にGo、マーケティングオートメーションツールでは専用のプログラミング言語といったようにサーバサイドに関しては開発時に使用する言語は2種類になりました。 eosはクリーンアーキテクチャを採用したことで初期実装は苦労しました。 しかし機能拡張はしやすく、LINEやメールの動的コンテンツを作成する為の開発はeos上で完結するようになり、生産性が上がって開発速度はどんどんと速くなっていったように思います。 その当時の活動については下記の記事にて紹介されています。 www.lifull.blog www.lifull.blog 技術負債解消と新規開発のバランス 2020年~2022年ごろまではおおむね50:50くらいの比率だったと思います。 個人で見ると、技術負債解消タスクが8割くらい、また別の人は新規開発系が8割くらいなどメンバーによってどちらに比重を重く持っているかの違いはあれど、チーム全体では半分ずつの割合でした。 2023年5月ころからはConventional Commitsを採用して、コミットメッセージベースでの技術活動バランスの可視化ができるようにという取り組みも始めました。 チームによって適切な状態は異なると思いますが、コミットメッセージベースで集計、可視化することで直近の活動は意図した活動になっているか?の一つの判断材料には使えると思っています。 Conventional Commitsを採用してみて得た知見などは下記の記事にて紹介しています。 www.lifull.blog 現状について 重めの技術負債解消タスクはここ数年でだいぶ片付いてきたので、直近だと新規開発の割合が少しずつ増えています。 技術負債解消はシステムリニューアルではなく、リファクタリング系タスクの割合が増えていて、ソースコードの保守性向上を目指した取り組みが多いです。 新たなチャレンジをする機会も増えており、機械学習に挑戦してくれるメンバーがいたり、イベントに参加して新技術のキャッチアップを行ったりができています。 www.lifull.blog www.lifull.blog 今後取り組んでいきたいこと マーケティングオートメーションツールの初期導入から約10年が経過していますが、メールを配信する為の顧客情報連携アーキテクチャは基本的にあまり変わっていません。 配信するコンテンツの内容や、コンテンツを配信する為の仕掛けはマーケティングオートメーションツールのバージョンアップや企画チームの各種施策で改良されていっていますが、ベース部分の改良まで踏み込めていないのが現状です。 ベース部分のところではコンテンツを配信するトリガーとなる情報やトリガーの引き方に制限があり、現状だと「サイトで問合せしてからn日経過した人にこのコンテンツを」という施策はやりやすいのですが、サイトで起こしたアクション(例えばサイトで特定の物件をお気に入り登録してからn日後、サイトの最終訪問からn日後など)を起点としてトリガーに対応させようとするとちょっと工数がかかってしまい、工数がボトルネックとなってそのような施策は優先度が上がりづらい課題があります。 現在はこのベース部分の改良がしやすいようにする為のリファクタリングや一部リニューアルを少しずつ進めており、この活動がゆくゆくはさまざまなコンテンツ配信トリガーを実現することに繋がっていくと思っています。 LIFULLのプロダクトエンジニアリング部 部長の河津は下記インタビューの中で「思いついたらすぐにリリースできるように、開発の速度をもっと速めていきたい」と語っています。 techplay.jp 私達のチームでもこの考え方に沿って各種施策を素早くリリースできるように継続的に技術負債解消と新規開発に取り組んでいきます。 最後に 技術負債解消と新規開発のバランスはそのチームの置かれている状況やフェーズによって最適なものが変わると思います。 このような時間配分になっていることが望ましいというバランスは常に意識し、定性的な面だけでなく定量的なデータを可視化して定期的にチームメンバーと認識合わせをしておくことが必要だと思います。 プロジェクト管理ツールのチケットへ入力した工数、日々創出されていくコミットメッセージなど活動のバランスを可視化する為のデータはあるけど、活用しきれていないというのはどこの組織でも多かれ少なかれあると思いますので、LIFULLで取り組んでみて得た知見を今後もブログなどで共有できればと思います。 最後まで読んでいただきありがとうございました。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co
フロントエンドエンジニアの嶌田です。 アイコンは、UIデザインにおいて欠かせないパーツです。弊社が提供する不動産情報サイトであるLIFULL HOME'Sでも、多数のアイコンが使われています。 ウェブページにアイコンを埋め込む手段は無数にあります。あなたはいくつ言えますか? それぞれのメリットとデメリットについて説明できるでしょうか? この記事では、LIFULL HOME'Sのフロントエンドで選ばれているアイコン表示方法およびその理由を説明します。その後、アイコンの管理や実装にまつわる不便な点をサービス横断的に解消するために作られた社内ツールと配信システムである、 LIFULL Icon CDN を紹介したいと思います。 私たちのアイコン実装方法 無数にあるアイコン実装方法のうち、私たちが選んだ実装方法は極めてシンプルです。 < img src = "assets/icon-star.svg" width = "24" height = "24" alt = "" > そう、 img 要素を使うのです。これまでさまざまなアイコン実装方法を試してきましたが、結局これが一番だろうということになりました。 なぜなのか? いくつかの観点から見てみましょう。 極めて手軽に使える アイコンを使いたい場面で img 要素を埋め込むだけなので、事前の準備や仕組みの構築が不要です。ブラウザがHTMLをパースしながら img 要素に出会うと、外部リソースとして画像データを読みにいき、自動的にその部分にはめ込んで表示してくれるのです。当たり前ですね! SVGスプライト *1 のようなテクニックは、ページ内で使う可能性のあるアイコンをあらかじめひとまとめにしておく必要があります。不要なアイコンを読み込まないようにする等の最適化を想定すると、トリッキーな仕組みを構築しなければならないでしょう。 img 要素を埋め込むだけなら、 どのプロダクトでも 極めて手軽に使えるのです。 十分なパフォーマンス 表示速度は十分に速いです。 img 要素のぶんだけ別々にHTTPリクエストが発行されることから、パフォーマンスがよくない印象を持たれるかもしれませんが、実際に速いです。 リクエスト数が増える問題は、HTTP/2のストリーム多重化により気にする必要がなくなっています。インラインSVG *2 に比べると、画像のデコード処理を別スレッドに逃がすことができるので、メインのHTMLのパースを素早く終えられるというメリットもあります。 標準的なHTTPキャッシュの恩恵を受けられることも大きな利点です。2度目の表示にはブラウザキャッシュが参照され、ネットワークリクエストは発生しません。 また、 loading="lazy" 属性を使った最適化も期待できるでしょう。アイコンは得てして装飾的に使われるので、読み込みを遅延させても問題ない場面が多いでしょう。 誰にとっても分かりやすい どストレートなやり方なので、HTMLのごく基礎的な知識さえあれば仕組みを理解できます。エンジニアと他職種との連携の円滑さにもつながるはずです。 アクセシビリティ アイコンの代替テキストは、 img タグの alt 属性によって提供します。まったくひねりのない方法ですが、問題なく動作します。 アイコンは、実装方法によってはアクセシビリティ上の問題を引き起こしてしまうことがあります。 たとえばアイコンフォントは、フォントデータが読み込めなかったときやユーザーが意図的にフォントを上書きしていた場合、アイコンが表示されなくなってしまう場合があります。SVGスプライトやインラインSVGでのアプローチは、代替テキストの指定に難があり、幅広いサポートを目指すためにWAI-ARIAに頼らざるを得ない場合があります。 他にも、OSのハイコントラストモード(強制カラーモード)への対応や、色反転モードに対する対処が望まれます。それについては記事の後半で触れたいと思います。 色の変更 SVGスプライト、インラインSVG、アイコンフォント *3 の利点は、色変更がCSSで手軽にできることでした。 img 要素に戻るのは、色変更の手軽さを放棄することにならないでしょうか? どうということはなく、私たちはこのようにします。 < img src = "assets/icon-star--red.svg" width = "24" height = "24" alt = "" > 色を変えたアイコンを読み込めばよいのです。 あっ、まだブラウザの戻るボタンは押さないでください。本気か?と思うかもしれませんが、本気です。たしかに手軽とはいえないでしょう。使う色が増えるたびにファイルを増やさなければいけません。 でもたとえば、クエリパラメーターで色が指定できたらどうでしょう? < img src = "assets/icon-star.svg?color=ff0000" width = "24" height = "24" alt = "" > 裏側の仕組みはともかく、少なくとも色の指定はやりやすくなりそうですよね。 アイコンをもっと手軽に使いたい! 正直なことを言うと、マークアップエンジニアにとって、アイコンは非常に面倒くさいです。まじめに取り組むと、アイコンを書き出して最適化し、配信の仕組みに乗せ、アイコン用コンポーネントを実装しなければなりません。いずれの工程もノウハウの塊です。 LIFULLは多数のサービスを提供しています。不動産情報サイトのLIFULL HOME'Sだけをとっても、いくつものサービスの集合体です。これら一つひとつのサービスごとに、別々のエンジニアがアイコンのお決まり手順を踏んでいると考えると、とても非効率な気がしませんか。 そこで私たちは、アイコンにまつわるこれら実装上の課題をサービス横断的に解消するために、 LIFULL Icon CDN と呼ばれる仕組みを構築しました。 LIFULL Icon CDNの特色 LIFULL Icon CDNは大きく分けて2つのコンポーネントで構成されています。 APIと呼ばれるコンポーネントは、ドメイン名を持ち、エンドユーザーからのリクエストに応えます。前段にCDN *4 を配置しており、静的キャッシュを持つことで高速化とオリジンサーバーの負荷軽減をしています。 Appと呼ばれるコンポーネントは、社内向けのアイコン管理アプリケーションです。外部からのアクセスはできません。アイコンを一覧し、必要なアイコンをページに埋め込むためのコードを取得することができます。 ここからは、スクリーンショットをまじえつつ、LIFULL Icon CDNでどんなことができるのかを見ていきます。 定義済みアイコンを一覧できる LIFULL Icon CDNが取り扱うアイコンは、デザインガイドラインで定義されたアイコンです。プロダクト横断的に利用されることが想定されたアイコンがずらっと並んでいます。執筆時点で300余りのアイコンが登録されています。 開発者は、この中から使いたいアイコンを選びます。 埋め込みコードをコピーできる 詳細ページからはエンドユーザーがアイコンにアクセスするためのURLと、埋め込むためのコード(HTML形式およびJSX形式)が取得できます。 アイコンをサービスで利用するための開発者の手順はとてもシンプルです。HTMLのコードをコピーして、コードに貼り付ければ終わりです。アイコン利用のための事前準備は不要です。 色を自由に変更できる アイコンの詳細ページ上からアイコンの色を設定できます。色を変更するとクエリパラメーターに反映され、指定した色のアイコンのURLが取得できます。 たとえば日本地図のアイコンはデフォルトでオレンジと黄色の2色から構成されていますが、黒に塗りつぶしたり、 https://icon.lifull.com/lh/japan-map-twotone?fill=black 2色を別々に塗り替えることも可能です。 https://icon.lifull.com/lh/japan-map-twotone?modify[yellow]=mono-300&modify[orange]=accent-blue 無秩序に使われることを避けるため指定できる色には制約があり、デザインガイドラインで定義された色トークンの中から選定する仕様にしています。 高パフォーマンス 配信用アプリケーションの前段にCDN(Amazon CloudFront)を設け、静的キャッシュを担わせることで、ほとんどすべてのリクエストをCDNから応答するようにしています。そのため動作は非常に軽快です。 各アイコンのSVGデータはオブジェクトストレージ(Amazon S3)に保管されていますが、すべての色指定に対する物理的なSVGデータが準備されているわけではありません。アプリケーション層で応答時に色変換の処理を適用しています。CDNには処理後のSVGレスポンスをキャッシュさせているため、軽快な動作を保っています。 アクセシビリティを高める工夫 いくつかの配慮を加えることでアイコンの使いやすさが向上します。 1つは、 強制カラーモードへの配慮 です。WindowsにはOSレベルの強制カラーモード、いわゆるハイコントラストモードが搭載されています。有効にすると、ウェブページを含むOS全体の配色が事前に定義された色で描画されるようになります。 img 要素を通じて埋め込まれている画像は、デフォルトでは強制色が適用されません。一方、アイコンの背景色は透過されているため、たとえば 黒基調の強制色における黒いアイコンは背景に溶け込んで見えなくなってしまう という問題が起こります。 2点目は、 色反転モードへの配慮 です。特に配慮が必要なのはスマート反転モードと呼ばれるもので、macOSやiOSなどのAppleのOSに搭載されています。スマート反転モードでは、OS全体の色をネガポジ反転しますが、画像や動画は反転されない挙動をとります。 この場合も、たとえば白の背景に置かれた黒のアイコンは、スマート反転モードを適用すると、背景色のみが反転するため、 背景に溶け込んで見えなくなってしまう 状況に陥ってしまいます。 2つの問題に対処するため、各SVGファイルには次のようなCSSを宣言しています。 < svg xmlns= "http://www.w3.org/2000/svg" ...> < style > @media (forced- color s: active) { @media (prefers- color -scheme: dark) { [ fill ] :not([ fill = "none" ]) { fill: #fff !important } } @media (prefers- color -scheme: light) { [ fill ] : not([ fill = "none" ]) { fill: #000 !important } } } </ style > ... </ svg > そして、LIFULL Icon CDNを使用する側には次のようなCSSを適用します。 /* 強制カラーモードが有効なとき、img要素経由で読み込まれるSVGに prefers-color-schemeメディアクエリが引き継がれない問題がある。 SVG側からカラースキーム文脈を取得するために、以下のスタイルを アイコン読み込み元に記述する必要がある。 */ @media (forced- color s: active) { @media (prefers- color -scheme: light) { img [ src ^= "https://icon.lifull.com/" ] { color -scheme: light; } } @media (prefers- color -scheme: dark) { img [ src ^= "https://icon.lifull.com/" ] { color -scheme: dark; } } } /* macOSのスマート反転モードが有効のとき、img要素は反転対象から除外される。 背景が透過されているアイコンが色反転から除外されると意図せずコントラストが 不足する可能性があるため、以下のスタイルにより反転に含まれるようにする。 */ @media (inverted- color s: inverted) { img [ src ^= "https://icon.lifull.com/" ] { filter : invert ( 0 ); } } 細かく書くと1記事分の分量になってしまうため省略しますが、ブラウザ側の不具合に対処しつつ、LIFULL Icon CDNを使う img 要素にだけアクセシビリティの向上のためのスタイルを適用しています。 デザイン上の工夫 LIFULL Icon CDNはエンジニアのデザイナーとエンジニア発案のプロジェクトとして始まりましたが、デザイナーも巻き込み、アイコンの統制や管理の仕組みを含む全体的なプロジェクトになりました。その意味ではアイコンのデザインシステムと呼べるものかもしれません。 デザイナーからみたLIFULL Icon CDNについては、別記事として公開されています。ぜひご一読ください! note.com おまけ 実装方法のバリエーション 以下はLIFULL Icon CDNのドキュメントに記載されている内容で、アクセシビリティに配慮したいろいろな実装パターンを解説しています。 もっとも基本的な使い方 アイコン詳細ページで取得できるHTMLをコピーして、そのままプロダクトのコードに貼り付けます。LIFULL Icon CDNチームはこれが ベストプラクティス であると考えており、推奨しています。 < img src = "https://icon.lifull.com/l/chevron-right" width = "24" height = "24" alt = "" /> 使用例1:ボタン内のアイコンとして使用する(装飾としての利用) テキストラベルの横に配置される場合や、単なる装飾としてのアイコン利用の場合、代替テキストは不要です。 alt 属性は空文字列に設定してください。なお、 alt 属性自体は省略しないでください。 次へ < button class = "flex items-center rounded border border-mono-400 bg-white px-4 py-2" > < span > 次へ </ span > < img src = "https://icon.lifull.com/l/chevron-right" alt = "" width = "24" height = "24" class = "ml-2 size-4" > </ button > 使用例2:ボタン内のアイコンとして使用する(機能ラベルとしての利用) テキストラベルが併記されず、アイコンがボタンやリンク内における唯一の要素である場合、代替テキストが必要です。 alt 属性に機能や状態を表す代替テキストを指定してください。 < button class = "flex items-center rounded border border-mono-400 bg-white p-3" > < img src = "https://icon.lifull.com/lh/star-twotone?fill=orange" alt = "お気に入り" width = "56" height = "56" class = "size-6" > </ button > 使用例3: 背景画像として利用する(非推奨) 背景画像には代替テキストが設定できず、強制カラーモードで非表示になってしまうため非推奨です が、装飾としての用途に限っては使用しても構いません。 次へ < button class = "button" > 次へ </ button > < style > .button { min-height : 24px ; padding-right : 32px ; background : url( 'https://icon.lifull.com/l/chevron-right' ) no-repeat right center / 24px ; } </ style > 使用例4:インタラクションに応じて色を切り替える シンプルさを重視し、切り替え前後のアイコンをあらかじめ埋め込んでおくアプローチを推奨します。 以下は、ボタンへのマウスオーバーで色が若干濃くなるアイコンのコード例です。 < button class = "group flex items-center rounded border border-mono-400 bg-white p-3" > < img src = "https://icon.lifull.com/lh/star-filled" alt = "お気に入り" width = "56" height = "56" class = "size-6 group-hover:hidden" > < img src = "https://icon.lifull.com/lh/star-filled?fill=orange-800" alt = "お気に入り" width = "56" height = "56" class = "hidden size-6 group-hover:block" > </ button > 使用例5:任意の色を使用する 原則として、定義済みのカラートークンを使用します 。どうしても任意の色を使用する場合は、 mask-image プロパティを使うテクニックが使用できます。 < span class = "mask-icon" style = " background-color: rebeccapurple --mask-icon: url('https://icon.lifull.com/lh/star-filled'); " ></ span > < style > .mask-icon { display : block ; width : 24px ; height : 24px ; mask: var( --mask-icon ) no-repeat center / 100% ; } </ style > Tailwind CSSを使う場合は以下のようになります。 < span class = "block size-6 bg-[rebeccapurple] [mask:var(--mask-icon)_no-repeat_center/100%]" style = "--mask-icon: url('https://icon.lifull.com/lh/star-filled')" ></ span > 次期バージョンも進行中 LIFULL Icon CDNはすでに社内エンジニアに便利に使われていますが、社内向けアプリケーションの機能拡充が予定されています。 現在のアイコンの追加・更新作業は、AWSコンソールにログインしS3に直接アップロードする運用フローになっています。かかる手間やヒューマンエラーのリスクに対処するために、管理アプリケーション上から直接アップロードや更新等の作業が行えるようになっていく予定です。 クレジット <LIFULL Icon CDN運営チーム> LIFULL HOME'S事業本部 エンジニア Dongjae Park、Shin Mingyu クリエイティブ本部 デザイン部 ぼこ、URITA RIKI スペシャルサンクス 鄭 在淳、曺 承鉉、そめ お知らせ LIFULLは主体性を重んじる社風で、LIFULL Icon CDNのようなエンジニア発案のプロジェクトが多数進行しています。他職種の協力も手厚いです。転職先に弊社をぜひご検討ください! hrmos.co hrmos.co *1 : SVGスプライト……ページ内で使うアイコンセットを事前にsvg要素でまとめて定義しておき、利用箇所でフラグメント参照を使って手軽にアイコンを使えるようにする仕組み。CSSで色変更がしやすい利点がある。 https://css-tricks.com/svg-sprites-use-better-icon-fonts/ *2 : インラインSVG……svg要素を使いSVG画像をHTMLにインラインで記述すること。CSSで色変更がしやすい。 *3 : アイコンフォント……アイコンデータをフォントファイルの字形データとして格納し、文字としてアイコンを表示するテクニック。CSSで色変更がしやすい。 *4 : CDN……Content Delivery Network。ウェブコンテンツをユーザーに高速で配信するために、世界中の複数のサーバーにデータを分散させる仕組み。
こんにちは、エンジニアの中島です。 この記事は2024年8月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。 この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。 目次 目次 サービス改善 賃貸物件登録画面の各コントロール・グループへの名前設定 取扱物件一覧ページの詳細条件設定ダイアログ内のコントロールの名前設定 育成・啓発の取り組み WCAG輪読会 アクセシビリティ1on1 お知らせ サービス改善 本期間中の改善取り組みのターゲットはLIFULL HOME'S 賃貸・流通マネージャーサイトです。 こちらはLIFULL HOME'Sをご利用いただいている会員様(不動産会社様)が、物件を掲載する際にお使いになる管理画面になります。 諸事情で発表できないものもありますが公開可能な取り組みを紹介させていただきます。 賃貸物件登録画面の各コントロール・グループへの名前設定 賃貸物件登録画面には物件情報を入力するためのフォームがありますが、その中には名前の設定されていないコントロールや、名前は設定されているものの文脈が不明瞭なラジオボタン・チェックボックスを含んだグループなどがありました。 これらのコントロール・及びグループに適切な名前を設定し、支援技術ユーザーにとってもコントロールの目的が理解しやすいように修正を行いました。 取扱物件一覧ページの詳細条件設定ダイアログ内のコントロールの名前設定 不動産会社様がLIFULL HOME'Sに掲載しようと登録した物件の一覧ページには、確認したい物件を絞り込むための検索フォームが設定されていますが、より詳細な条件設定を行えるダイアログが存在しています。 このダイアログ内の各コントロールも名前が未設定のものが多くありましたので適切な名前を指定する修正を行いました。 育成・啓発の取り組み WCAG輪読会 アクセシビリティやっていき勢向けにWCAGの輪読会を隔週で行っています。 本期間中は8月22日に行われました。 範囲は達成基準1.4.4〜1.4.5です。 アクセシビリティ1on1 本期間中は先月と同じくフロントエンドエンジニア6人、デザイナー1人に対して行いました。 内容はWCAGの解説、APG(aria authoring practices)の解説、coga-usableの解説、実際のアプリケーション開発時でのアクセシビリティ配慮に関する相談などが主なものとなります。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co