エンジニアの市川と申します。 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

エンジニアの松尾と申します。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回 開催頻度：３ヵ月に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