QAの山下です。 QAグループという名前で横断組織として手動&自動テストやツール開発、プロセス改善など仕組みづくりに取り組んでいます。 今回は LIFULL HOME'S の開発で実行されているE2Eテスト（リグレッションテスト）をシフトレフトし、実行時間を80％短縮した話を紹介します。 ざっくり何をやったのか 大規模なリポジトリでのdevelopマージ後のE2Eテストの9割をPR上で実行可能にした コードのpushからE2Eテスト完了まで5～8分で完了できる 運用上の課題も頑張って解消した 目次 ざっくり何をやったのか 目次 結論 前提情報 E2Eテストとは リグレッションテストとは LIFULL HOMESでのE2Eテストの位置付け シフトレフトとは EEとは 対象のプロダクトの規模 起こっていた課題 テストの削除とリファクタを行い、テストケースを3割削減した デプロイ後のアプリケーションに対してe2eテストを実行できるようにした 開発チームとのコミュニケーションを積極的に行い、運用課題の発見と改善を実施した テスト結果通知のコメントが量産されPRが見づらくなる 問題の概要 検討事項 解決法 マージ要件を満たせない 問題の概要 解決法 検討事項 テストの再実行がやりづらい 問題の概要 解決法 これからやりたいこと 結論 以下の図の通りです。 Git-Flow をベースとしたフローに則り開発されていたリポジトリで、developマージ後に実施されていたE2Eテストの9割をPR上で実⾏できるようにシフトレフトしました。 コードのpushからE2Eテスト完了まで5～8分で完了します。 シフトレフト前後の図 前提情報 今回のPJの紹介にあたって前提となる情報を記載します。 E2Eテストとは 本番相当の環境で、ビジネスプロセスを最初から最後まで実⾏するテストの⼀種です。（ISTQBより） LIFULL HOME'Sでは内製の⾃動テストフレームワーク「 Bucky 」を使ってE2Eテストを実施しています。 リグレッションテストとは ソフトウェアの変更されていない領域の欠陥を検出するためテストの⼀種。（ISTQBより） Aの機能に手を加えたのにBの機能でバグが出た！のような現象を検知するテストです。 LIFULL HOMESでのE2Eテストの位置付け 重大な問題点がないことを(回帰テスト観点で主要機能の動作)を保証する。 テストした結果、不具合が発見された場合は修正を行う。修正が完了しない限り、本番へリリースすることはできない。 テストスコープは以下です 動かなくなると重大な被害を被る機能群 物件の検索や資料請求等 過去に障害が起こった機能群 確認が漏れそうな機能群 シフトレフトとは テストおよび品質保証の活動の実施を、ソフトウェア開発ライフサイクル内で可能な限り早く⾏うためのアプローチ。（ISTQBより） 今回はdevelopブランチで実施されていたテストをPR上で実行するようにしたことでシフトレフトを実現しています。 シフトレフトするメリットは以下が挙げられます 早期にフィードバックできることで大きな手戻りやバグを未然に防ぎ、全体のテスト時間を短縮しソフトウェアの品質向上が期待できます。 EEとは 瞬時に検証環境が手に入るEphemeral Environmentの略称。 Pull Requestの内容をもとに一定期間アクセス可能な環境の複製をデプロイする機能。 Vercelのpreview環境のようなもの 弊社の全社アプリケーション実行基盤である KEEL の1つの機能です。 対象のプロダクトの規模 今回実施した対象のリポジトリの規模を記載します。 LIFULLの看板サービスであるLIFULL HOME'Sの主要機能が実装されているリポジトリ 1ヶ月間のauthor数: 約100人、Merged PR数: 約200 起こっていた課題 developブランチマージから本番環境反映まで8.5時間かかっていた QAGの工数が1~4時間/日かかっていた 基本的に朝9時からdevelopブランチに対して自動テストを実行 実行後の結果を確認、バグが検知されれば開発チームに仕様確認 14時くらいに本番環境反映 E2Eテストでバグを検知した時の手戻りの多さ Revert対応率は3年連続で50%を超えていた QAGと開発チームのコミュニケーションに時間がかかる 弊社QAGは横断組織で、機能開発チームに常駐しているわけではありません。そのためE2Eテストが失敗した際に、E2Eテストのメンテナンスが必要なのか、バグなのかがすぐに判断できませんでした。 都度開発チームに調査依頼を投げていたので、両チームの負担となっていました。 ここまではこのPJに関する前提状況を書きました。ここからはPJの中で実施したことを時系列順で書いていきます。 テストの削除とリファクタを行い、テストケースを3割削減した 前述 したdevelopブランチマージ後に実施していたテストは、合計400ケースほどありました。これらをそのまますべてシフトレフトすると以下の懸念がありました。 ※後述のリファクタは保証したい内容は変えずにシナリオを変えることを指してます。例えば元々1ケース1アサート*2 だったシナリオを1ケースで2アサーションするように変更する等です。 実行時間が長いことで開発者体験が悪くなる 最悪の場合、QAと開発者の対立の原因になる 再実行数が増えコストが上がる これらの問題を解決するため、テストの再設計を実施しました。結果としてテストケース数を3割削減、またテストの実行時間も削減できました。 この項目で実施したことは以下です。 テストを実行時間順にソートする 実行時間が長いものから削除、リファクタ、再設計箇所の洗い出し テスト技法を用いて検討 該当のテストケースが追加された時の意図(バグチケット等)を基に、現在でも同じテストケースが必要か検討 レビュー実施 開発者との合意形成 テストの削除、リファクタ、再設計を実施したことによりステークホルダーに影響があるため合意を形成する必要がありました。 ステークホルダーは機能開発のエンジニア、企画職 合意は以下の内容で形成しました 対象テストケース 削除対象とした理由 実装 デプロイ後のアプリケーションに対してe2eテストを実行できるようにした 本題とは離れるので詳しくは割愛しますが、Helmにおける Chart Hooks を編集し、前述のEEデプロイ後にEEに対して E2Eテストを実行するようにデプロイパイプラインを修正しました。 開発チームとのコミュニケーションを積極的に行い、運用課題の発見と改善を実施した ここまでで「リモートブランチにPushされる度にPR上でE2Eテストが実行される」状態にはできました。しかし作ったら終わりではありません。ここから運用課題とどう向き合ったのかを書いていきます。 挙がっていた運用課題は以下です。 テスト結果通知のコメントが量産されPRが見づらくなる E2Eテスト特有の不安定さ故にマージ要件を満たせない テストの再実行がやりづらい それぞれについて問題の概要、検討事項、解決法を書いていきます。 テスト結果通知のコメントが量産されPRが見づらくなる 問題の概要 現状E2Eテストが完了した際に以下のようなコメントがされます。 画像 E2Eテスト結果確認コメント 開発している時には気づけなかったのですが、コミット数が多くなってくるとコメントがその分量産されPRの見渡しが悪くなるとのフィードバックをもらいました。 検討事項 「PR内に存在する過去のE2E結果コメントを削除→新規のテスト結果コメントを投稿」の処理に変えれば良いのでは？と考えました。 懸念としては、PR内で過去のテスト結果を見ることができなくなることでした。 しかし 過去のテスト結果を見ることはユースケースとして多くない 別のマネジメントツールがあり、過去の結果を見たくなった時はそこからPRの番号で閲覧できる ので問題無しと判断しました。 解決法 以下の処理に変更しました。 PR内に存在する過去のE2E結果コメントを削除 新規のテスト結果コメントを投稿 マージ要件を満たせない 問題の概要 このE2EテストはCIとしてPushの度に実行されます。またリグレッションテストとしての役割も持っているので、当然全てのテストが成功してからdevelopブランチに反映されるべきです。 そのため導入時はテストが100%成功していないとマージができないようにしていました。 しかし、このルールでは開発者体験が悪化してしまいました。原因は以下です。 E2Eテストは他のテストレベルと比較して不安定さが高い ネットワークの問題等で1個でも失敗してしまうとマージができない 後述の「テストの再実行がやりづらい」問題のため、テストの再実行に10分かかってしまう。 ABテストが多い LIFULL HOME'Sでは多くのプロジェクトが並行して進んでおり、それに比例してABテストも数多く存在します。 基本的にはE2Eテストシナリオではメインに採用されている方を期待していますが、自動テスト時に期待していない方を引いてしまった場合、UIやロケーターが変わるので失敗してしまいます。 開発者も他チームのABテスト事情を全て把握しているわけではない 解決法 マージ要件に閾値を設ける手段を取りました。 具体的には自動テストのpass率が90%を超えている場合にはマージ可能としました。 検討事項 チーム内で話し合った結果、避けたかったこととしては以下が列挙されました。 バグの流出 自動テストで検知されているバグを無視してマージした結果本番で障害が出る E2Eテストの形骸化 テストが失敗してもマージ可能なため自動テストのメンテナンスをせずに放置される可能性がある。 自動テストのメンテナンス不足で失敗が増え、テスト結果が信頼できなくなる等が起こる傾向にある 開発者体験が悪くなること プロダクトコードに問題が無く、flakyテストによってマージが阻まれる事 他チームで実施されているABテストによってテストが失敗し、マージが阻まれる事 テスト成功率100%を求め続けることで開発者のストレスになる 最悪の場合QAと開発者で対立が生まれる 上記の「バグの流出」と「E2Eテストの形骸化」は自動テスト成功率を100%を強いることで解決できますが、3つ目に関しては自動テスト成功率を100%を強いると起こり得てしまう問題です。 過去の自動テストの結果を見て、flakyテストとABテストで期待していないパターンを引いた場合でも90%は下回らないということが分かりました。 そのためマージ要件をE2Eテストのpass率100%→90%に変更しました。 テストの再実行がやりづらい 問題の概要 テストの再実行を行いたい場合、以下の手順を踏む必要がありました。 EEの再起動 E2Eテストの実行 E2Eテストの結果 特にコードの修正をしていない場合の再実行では、E2Eを再実行したいだけのためにEEの再構築も行わなければなりません。 EE再構築からテスト完了まで10分を超えることもあり、これはユーザーにとってストレスでした。 解決法 GitHub Actionsの workflow_dispatch を使い、E2Eテストの再実行を楽にしました。 以下の流れでテストの再実行が実施されます。 workflow_dispatchでPR番号を入力する 入力されたPR番号から再実行すべきテストケースを取得 入力されたPR番号から再実行対象のFQDNを取得 WorkflowでE2Eテストの再実行用スクリプトを実行 これによってコードの変更をしていない場合でのE2Eテスト再実行の手間が軽減され、時間としては10分→5分ほどにまで削減できました。 これからやりたいこと シフトレフトすることでE2Eテストの実行時間を80%短縮することができ、早期にフィードバックができるようになりましたが、まだまだ改善できる部分があります。 e2eテストの安定化 現在はUIの変更や改修に対して脆いテストが存在しています。これを解消するために data-testid のような自動テスト用の属性をプロダクトコードに導入し、テストの安定化を図りたいです。 アラートの仕組み化 前述の通り閾値を設けてマージの可否を決めています。そのため本来メンテが必要なテストケースが放置されてしまう可能性があります。 現在はQAGが定期的にテスト結果をモニタリングし、担当部署にアナウンスしていますが今後はアラートの仕組みを導入して一定の条件で担当部署に通知するようにしたいです。 ABテストに対応するためのcookie固定化 前述の通りLIFULL HOME'Sでは多くのプロジェクトが並行して進んでおり、ABテストも数多く存在し、この数に比例して「自動テストで期待していないパターンを引いてしまう」という問題が発生しやすくなります。 これを解消するために「e2eテストからのリクエストだった場合はABテストのcookieを固定化する」ような仕組みを開発者と協力し導入したいです。 これからもQAとして品質改善、開発スピード、開発者体験向上に貢献していきたいと考えています。

グループデータ本部データサイエンスグループの嶋村です。 グループデータ本部は、 LIFULLグループで生まれる新たなデータを安全かつ効果的に活用 できるようにし、 事業の変化と持続的な成長を促進 することを目指している組織です。その中で、データサイエンスグループは研究開発組織として、「 活用価値のあるデータを創出 」し、「 データを活用した新たな機能やサービス 」の研究開発に取り組んでいます。 事業を革進し続けて様々な社会課題を解決していくために、 データを最大限に活用できる状態にしていきたい と考えています。その一環として、不動産情報・住宅サイトである LIFULL HOME'S に掲載される 不動産広告画像を定量的に評価（数値化） し、その評価結果をプロダクトの改善に活用できる状態にするための取り組みを続けています。 2024年4月27日に弊社が協賛している「 第88回 Machine Learning 15minutes! Hybrid 」が開催され、今回の取り組みについて登壇をしました。 基盤モデルCLIPを活用した不動産広告画像品質評価 by @LIFULL 画像品質の定量評価とは 画像品質の定量評価をするためには、画像品質の良し悪しを数値で表現する必要があります。しかし、感覚的に画像品質の良さがわかったとしても、その 品質を厳密に数値化することは簡単ではありません 。 たとえば、以下の2つの画像は生成AIを用いて作成した架空の物件の内観写真です。2つの画像を見比べてみて下さい。 室内写真の比較 おそらく多くの方は、左の写真①の方が右の写真②よりも、以下の観点で「良い」と感じるのではないでしょうか。 画像の明るさが適切である（暗すぎない、明るすぎない） 画像がぼやけておらず鮮明に見える 画像の撮影画角が良く広々と見える など しかし、それらを点数（数値）で表現しようとすると、100点満点中、100点なのか、50点なのか、0点なのか、点数を付けるのは難しいと感じるのではないでしょうか。 そこで、データサイエンスグループは 深層学習や画像処理技術を用いて不動産広告画像の見栄えの定量化 を試みました。 画像品質情報の算出と蓄積、そして活用 画像品質に関する情報を作成する取り組みの詳細は前述したスライドでご説明していますが、画像品質の定量化には基盤モデルCLIP（Contrastive Language-Image Pre-Training）の派生であるCLIP-IQA（Image Quality Assessment）を用いました。CLIP-IQAはテキストラベルで指定した品質評価の観点に対して、品質評価結果を数値で出力する仕組みです。 ここでの難しさは どのような評価観点を定め 、 どのようなテキストラベルで評価値を算出するか 、でした。 まず、弊社のコラムで公開している 写真撮影のコツ などを参考に、評価観点を定めました。そして、テキストラベルは様々な表現方法があるため、生成AIを用いて半自動的にベストなラベルを決定する仕組みを作りました。 実験時は膨大な写真画像に対して評価値算出の処理を実行しましたが、弊社の アプリケーション実行基盤KEEL を最大限に活用することで、効率良く実験環境を構築し実験を進めることができました。 画像品質の定量評価は以下のように活用できるのではないかと考えており、今後も新たなデータを創出してサービスを革進させていきたいと熱意を持って取り組んでいます。 画像品質評価結果が良い画像を優先的に表示する 画像品質評価結果に基づいて自動で画像を修正する など おわりに 今回は不動産広告画像を定量的に評価する取り組みを紹介しました。今後も研究開発に関する取り組みをどんどん発信していきたいと思います。 その一環として、データサイエンス系の自社イベント「 LIFULL AI Hub 100ミニッツ 」を定期的に開催しています。当日の様子は togetterでのまとめ をご覧下さい。 次回は7月頃の実施を予定 しており、少しでも興味を持ってくださった方は、 弊社のconnpassアカウント に登録していただけるとイベントのご案内をお届けできます。是非、気軽にご参加いただけると嬉しいです。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービス」の研究開発を加速して下さる シニアデータサイエンティストを募集 しています。 hrmos.co 興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。

データサイエンスグループの島です。 普段は機械学習システムバックエンドの開発や運用を行っております。 2024年5月25日に半蔵門の本社2Fにて機械学習(AI・人工知能)に関するライトニングトーク(LT)会が開かれました。 素晴らしいLT会でしたので、内容をいくつかシェアさせてください。 第89回 Machine Learning 15minutes! Hybrid - connpass 「Machine Learning 15minutes!」というコミュニティを運営している 門前さん が主催するLT会です。 以前の開催 に引き続き、 LIFULL AI Hub が協賛という形での開催となりました。 現地参加とオンラインのハイブリッド開催で、会場20名、オンライン100名ほどがいらっしゃいました。 様々な方が発表してくださり非常に盛り上がりました。豪華な内容でとても示唆に富んでいました。関係者の皆様、参加いただいた皆様ありがとうございました。 LIFULLからは分析に関わる社員向けのデータ活用施策である ファクトブック に関する発表を行っております。 とても盛りだくさんなLT会ですべてをご紹介できないのですが、LIFULLのような事業会社でのAI活用という視点で心に残ったものを共有させてください。 元木 大介さん【２週間で世界１万ダウンロード 自然言語プログラミングの衝撃】 吉崎亮介さん【仕事の対話をAIでハックする考え方とプロセス】 森 正弥さん 【AIは人の仕事を奪うのか？ AI時代の新たな哲学】 懇親会 元木 大介さん【２週間で世界１万ダウンロード 自然言語プログラミングの衝撃】 元木さん が開発されている自然言語プログラミングフレームワークに関する発表でした。 Zoltraakとniwatokoという２つのプロジェクトが説明されました。 （Zoltraakの名称は『葬送のフリーレン』から引用されています。） github.com github.com Zoltraakはプロンプトとして与えた曖昧な要求から、ドキュメントを生成するためのフレームワークです。例えば要件定義書などを生成できます。 niwatokoでの自然言語からのプログラム生成も検証中のようです。Zoltraakで生成した要件定義書を入力にする使い方があります。汎用的に実現できるとすごそうな予感がします！ 自然言語でのプログラミングが可能になると、開発者の数が10倍くらいになるのでは？というようなお話もありました。ゲームチェンジ感をひしひしと感じます。 2つのプロジェクトを統合すると、プロダクトが一瞬で出来上がるというような世界観ですね。まさに魔法のようです。 Zoltraakを使ってみるとわかるのですが、CLIでの操作が魔法を扱っているようなワクワク感を感じさせるUXになっています。 プロダクト開発においては、ワクワク感を持って勢いで作ってしまうことは地味に重要なんじゃないかと思っています。ワクワクさせる仕掛けを私も大切にしていきたいです。 また今回のLTには含まれていませんが、Zoltraakの価値観や使命感については、元木さんによるツイートがありました。 熱い想いが語られており、生成AI活用を盛り上げていくぞ！という勢いが滲み出ており、非常に共感します！ #自然言語プログラミングZoltraak の使命、将来像、価値観をまとめます ＊ 俗に言うミッション、ビジョン、バリューですが、Zoltraak開発の中心的存在である私たちは日本人なので「日本語」を特に大切にします ちなみにこれはグローバリズムとの対立を生む思想ではありません。後述します。 将来像:… pic.twitter.com/rgL9MEBhaB — 元木大介@生成AI塾&抽象プログラミング言語: ゾルトラーク、にわとこ (@ai_syacho) 2024年4月26日 吉崎亮介さん【仕事の対話をAIでハックする考え方とプロセス】 吉崎さん からはAIを介して成果物を出す人間をどう増やすかというお話を頂きました。 スライドはこちらをご覧ください。 speakerdeck.com ボリュームのあるスライドですので、かいつまんで説明いたします。 まず、「AIから目的とする出力を引き出すためには、十分な量の入力が必要である」という話が前提になっています(下記スライドP17までの議論です)。 短いプロンプトでふわっとした指示をした場合に、意図通りにAIが動いてくれない経験は皆様もお有りだと思います。 業務にAIを活用したい場合、業務固有のデータやノウハウをAIに与えることが重要です。 したがって、 業務経験データベースに業務固有のデータを入力する準備ができていること が重要で、これに 「高度な論理的思考力というフィルタ」としてのAI活用 をかけ合わせると、仕事で使えるAIとなります。 では、業務固有のデータ、業務経験を蓄積する際に、どういうことに気をつければよいのでしょうか。 業務経験をここでは、「本質的な情報(x)」から「表現(y)」への写像として捉えています。 AIとの協業では「本質」をいかにうまく扱うかが重要であるという話の流れになります。 下記スライドでは本質的な情報からアウトプットを生み出すためのプロセスにおいて、AIとの協働がうまく行っている状態の例を示しています。暗黙知としてのナレッジが表出化され、AIへの入力として組み込める状態だということですね。 「AIによるx→yへの変換を人間が修正した結果」を自動的にDBに集積し、それをAIに渡す入力をアップデートすることでAIの表現を洗練させていく、というアイディアがこの図のポイントだと思います。 弊社の話題に移すと、LIFULLでもkeelaiというSlack Botを社内用に運用しております。 生成AIによる20,000時間の業務効率化を支える取り組み - LIFULL Creators Blog keelaiでもRAG(Retrieval-Augmented Generation)を用い、既存のバックオフィスFAQの内容を情報の取得元の1つとしています。 いかにしてkeelaiを活用できる場面を増やすかという点を考えており、吉崎さんの発表の「業務経験の集積」という考え方が参考になりそうです。 興味深い発表をしていただきありがとうございました！ 森 正弥さん 【AIは人の仕事を奪うのか？ AI時代の新たな哲学】 森さん は博報堂のChief AI Officerの方で、AI倫理に関するお話をいただきました。 発表は主にこちらのnoteの内容でしたので、noteをご覧いただくのが良いかと思います。 note.com 主張としては『「リアル VS ネット」または「現実 VS 仮想」といった二項対立に陥らないようにする』というような内容で、両極のベストを組み合わせた第三の方法を見つけるような考え方を身につける必要があるということでした。 これはまさにその通りだと思っていて、AI時代になっていくと一人の人間の意思による力がAIによって増幅されていくので、それを争いに使うと被害が大きくなってしまいます。 AIによって生まれた実務能力によって様々なものが加速していくので、AIを使って何がしたいのかをよくよく議論しておかないと、AかBかのどちらかに寄ってバランスが悪くなっただけになりかねないと思います。 プロダクトマネジメントの文脈で、プロダクトビジョンの制定とその実現に向けた継続的な議論が重要だというような話があります。 弊社LIFULLでは プロダクトマネジメントの活用 を近年意識しており、 昔よりはプロダクトのあり方について議論する場は増えてきていると感じています。 様々な人たちと様々な議論を行うことで、より多様な視点を包含した方法につながるのではないかと思います。 懇親会 懇親会もとても盛り上がりました。 オンラインのzoomをプロジェクターで投影しながら、オフラインの会場と繋いで雑談するというハイブリッドで行われました。 話題としては様々なお話があったのですが1つだけ挙げると、さきほどの森さんにEUのAI法案について解説いただいたのが興味深かったです。 EU AI法案が加盟国に承認され成立 規制は2026年に適用の見通し | NHK | EU こちらは2026年から本格的に適用予定の規制なのですが、これはEUが基本的人権をどう考えているかのメッセージだというお話をされました。 規制とは単に守るべきものと捉えがちですが、規制があるからこそ、その領域に対して人々がリテラシー意識を持つようになるとも言えます。 AI法案の罰則の上限はGDPRの罰則の上限よりも高いので、EUはAIと人権の問題を重く見ており、 それは(GDPRすなわちデータの問題よりも)議論されるべきものだと考えていると言えるのかもしれません。 AI開発者はAIにバラ色の未来を投影しがちですが、インターネットにもフェイクニュースやフィルターバブルの問題はあるので、技術がもたらす様々な副作用に目を向けていかないといけないということですね。 （もちろん、バラ色の未来を実現させることもとても重要です） 「Machine Learning 15minutes!」には様々なバックグラウンドの方が集まり、とても熱気がある会でした。弊社も協賛という形でのご協力ができて嬉しいです。 最後に LIFULLでは生成AIを積極活用する方針があり、共に成長できる仲間を募集しています。 media.lifull.com ご興味のある方はこちらの採用ページからぜひご応募ください。 hrmos.co hrmos.co hrmos.co hrmos.co

こんにちは。クオリティアーキテクトグループでQAエンジニアをしている星野です。 元々はQAグループという名前で横断組織として社内のテストプロジェクト支援などを嗜んでいましたが、 組織が統合・再編成され、より自動テストやツール開発、プロセス改善などエンジニアリングに寄った仕組みづくりに取り組んでいます。   ３行まとめ 共通のフォーマットを開発したよ 抵抗感なく浸透させるように工夫したよ こっそり横断的なメトリクスも取ったら便利っぽかったよ ３行まとめ 背景 課題 対策 やったこと 当たり前品質編 : 満たさないと論外 魅力品質編: 乗り換える理由をつくる 横断部署が常にぶちあたる浸透の課題 ロガー 広報 効果と現状とこれから 終わりに 背景 課題 LIFULLではチームごとにやりやすい開発体制を選択しています。 奇抜な開発スタイルをとっているわけではありませんが、それぞれに特色があり独自に改善活動を行って進化しています。 改善の進めやすさなど柔軟性のメリットもありますが、一方で次のような課題が出てきます。 ナレッジの横展開がむずかしい フォーマットが異なるためツールやノウハウをそのまま再利用できないことがある 部署異動や新人の学習コストが高い 学び直しが必要になる 他部署の成果物を読み解く際にフォーマットの理解から必要になる 我々のような横断的なQA組織の立場としては次のような課題があります。 測定・調査が難しい チームごとにテスト成果物のフォーマット（ここではテスト仕様書・項目書）が異なるためメトリクスを活用しにくい, 状況を把握しにくい 非同期で変化するためそれぞれの形に合わせて自動化しても追跡が難しい 改善施策を広めにくい 上記の「ナレッジの横展開」と同様 １チームの閉じた単位で改善を行うためスピードが出ず再開発する必要もある 加えて最近では特に海外の開発拠点とこれまで以上に密な連携を行って開発するようになりました。 覚えることが多い状況の中、テスト部分で海外拠点メンバーが困らないように「とりあえずこれまで通り自分たちのフォーマットを使って進めましょう。どんな形がいいかはみんなで検討しよう。」の方針となるチームも多く、フォーマット迷子になっている状況でした。   対策 ここまでの流れでおわかりの通り、標準となるテスト仕様書のテンプレートを開発しました。 シンプルに言うとそれだけなのですが、会社のテックブログなのでそれらしいことを書きます。   やったこと もちろんですが、チームの外にいる人から「急だけど今日からこのテンプレートでテスト書いてね！じゃ！」と言われても圧倒的なパワー差による主従関係でもない限り通りません。   ではどんなテンプレートを用意すれば既存のやりかたと勝負できるか。 品質分野の人間なのでみんな大好きな狩野モデルを出して説明します。   （引用 : ナレッジ - 品質管理なら日本科学技術連盟 ）   狩野モデルについての詳細な説明は割愛します。 要は利用者の目線で見たときに、当たり前に揃っていて欲しいものがないと不満を感じるし、魅力に感じるような要素がないと満足度は上がらない、というざっくり説明で進行します。 このモデルをもとにどんなテンプレートが必要かを考えると、以下を満たす必要がありました。 当たり前品質（満たさないと論外） 現在使っているテンプレートでできることはできる テストケースの書き方を極力変える必要がない 一元的品質（あればあるほどいい） サポートの手厚さ 魅力品質（これだけでも使う理由あるやん） 開発チームの未解決課題にアプローチした機能 当たり前品質編 : 満たさないと論外 まずはじめに行ったのは既存フォーマットの調査です。 基本的にはチーム単位で独自にツールベンダーと契約することは予算的にも現実的ではないため、スプレッドシートを用いることが主です。 スプレッドシートは自由度が高いため独自進化しやすく、GASや式を用いた機能拡張が進んだチームも見られました。 機能の不足で乗り換えを躊躇するチームは限られているので充足は徐々に行っていくとして、まずは元となるテストケースの書き方（カラムなど）に焦点を当てます。   よく使われるカラムや書き方を調べ、代替や統合ができそうかを考え、プロトタイプを作ってはヒアリングを行い（海外拠点メンバーを含む）利用者の声を聞きにいってました。 特に奇抜なフォーマットが出来上がるわけもなく、よくある一般的な内容に落ち着いたため詳細は省略しますが、  PMなど進捗が気になる人に一目で状況がわかるようにテスト進捗メトリクスのグラフをつけたり、 複数端末で同時にテストする需要があるのでテスト結果を入力するカラムを複数個並べるといった小さな気配りを機能ごとに想定ユーザーとシチュエーションを設定していっぱいちりばめた記憶があります。 もちろんですが、想定は想定でしかないため、実際に見てもらってユースケースと食い違ったり噛み合わせが悪い部分はアップデートを重ねています。   その後は不足している機能の拡充で、既に進化しているチームのシートを参考にしながら機能を汎化させ取り込んでいきます。 具体的には、スマートフォンの実機でテストする際の効率をよくするためにQRコードを自動で生成したり、テスト環境を切り替える際にテストケース内のドメインを一括で切り替えたりといったあるある機能群なのでこちらも割愛します。 つまるところは「この機能がないと不便なんだよなぁ〜」をなくす運動です。「その機能、別になくていいのに必須入力なんだよなぁ〜」も生み出さないよう、利用者以外には影響を及ぼさないような設計を意識しました。   魅力品質編: 乗り換える理由をつくる いま現在利用されているテンプレートでは叶っていない機能、抱えている・またはこれから抱える問題の解決につながるような機能を考えます。 背景でも述べていますが、ここは明らかでした。海外開発拠点との連携が密になり、言語の壁が課題となっています。 DeepLのような翻訳サービスが進歩していても、都度都度テストケースの中身を翻訳にかけるのはとても手間です（ましてやスプレッドシートなのでセル単位）。 メンバーも元々英語が必要な環境だと言われて入社しているわけではないですし、自分もそうですが全員が全員、語学が堪能ではありませんし全員が急に上達するのも現実的ではありません。   そこで、指定したシートのテストケースをボタンひとつで翻訳してくれる機能を用意しました。ありがとうGoogleTranslate関数くん。 他にも共通テンプレートとなると複製の手間が発生することが目に見えているため、GASでAPIを用意し常に最新版のテンプレートを生成してくれる仕組みを用意したり、それをgithub actionsに組み込んでPR作成時にトレースも取れた状態でつくれるようにしたりと開発者体験の向上を進めました。 これで「今まで使ってたGoogleDriveから複製して使ってたこれまでのテンプレートより全然楽じゃん...」な状況が手に入ったわけです。   横断部署が常にぶちあたる浸透の課題 ヒアリングを重ねて使いやすい形を手に入れ、既存機能にも追いつき、他にない機能も搭載されました。 プロダクトを作った後に課題となるのは「浸透」です。使ってもらえなければこの新テンプレートは存在しているだけで何の価値も出せていません。   ロガー そこで、まずは利用状況を追跡し可視化する機能を実装しました。 利用時に必ず操作するボタンをトリガーに、利用しているチーム、github actionsから生成されていればPR番号などをログとして蓄積し、見える化を行いました。 これにより、一度使っていてもその後に利用が見られなければ、なにか問題・課題を見つけてくれていると考えられるのでヒアリングをする、といった動き方ができます。 また、よく使ってくれているチームや一度も使っていない（知らない or 乗り換えるメリットを得られない）チームなどが明らかになります。ターゲットが明確になることで次の打ち手の確度が上がります。 実際はクチコミで「なんかQAがつくったテンプレがいい感じらしい」と自然に広がってくれたようで、じわじわ増えていく様子が見られました。   リリースした新機能が活用されているのかどうかだったり、サポートの問い合わせがあったときにログの利用者情報からシートをすぐ特定できるため重宝しています。   広報 次に、定期的に丁寧なアナウンスです。 読み手にとって価値の薄い「つかってくださ〜い」の広報を何度行っても響きません。むしろノイズとなり煙たがられます。 そこで、魅力となる便利機能が搭載されたタイミングで、その機能の概要と使い方を1~2分の動画説明を添えて広報しました。   使い方もほぼ誤解なく伝わっているようで、利用数に対して機能の使い方に関する質問はほとんどありません（バグの報告や新機能の提案、感謝の声などがフォームやDMに届いてます）。 使われていなくて質問がないのか、使われている上で質問がないのか、これには大きな違いがありますが、前述の利用状況を見える化したことでその判別ができます（ちなみに独自の名前をつけたことでslackにてエゴサがとてもしやすい）。   効果と現状とこれから 定量的なアウトカムについては恐縮ながらまだ計測できていません。 取り組み自体、半期で計画・調査・実装・展開・浸透を行なっているためデータを蓄積している最中になります。 また、このテンプレートは裏でこれまたこっそりとメトリクスを収集できるようにしており、利用されたすべてのシートでテストケース総数や実施した環境数、テストタイプの数や実施期間などが取得できています。 これらのデータを既存テンプレート利用時の実態と比較できればよかったのですが、背景で述べたようにチームごとに実態が異なっており、また詳細なデータも取れるかわからないのが現状です。   整理しやすくなった、見やすくなった、翻訳機能が助かっている、などの定性的なフィードバックはもらえるようになったものの、定量的なアウトカムはやはり難しいため、 新たに取得しているメトリクスから、新機能リリース後の変化や改善施策実施後の効果計測、チームごとの健康状態可視化、ベストプラクティスの発見と横展開などの取り組みに繋げていく基盤として機能させていこうと構想しています。   終わりに ただただ共通テンプレートをつくった話を長々と述べました。 たかが共通テンプレートですが、利用するだけで恩恵を得られるような仕組みを用意したり、改善を誘導するような仕込み（本記事では割愛しました）ができたりと、工夫の余地は結構ありました。 たかが共通テンプレートですが、浸透させるのも頭を悩まされ、たくさんの方に協力していただきました。 たかが共通テンプレート。されど共通テンプレート。   以上です。 お読み頂きありがとうございました。

こんにちは、グループデータ本部データサイエンスグループの清田です。 昨年のDEIM 2023 に引き続き、「 第16回データ工学と情報マネジメントに関するフォーラム（通称DEIM 2024） 」に参加・登壇してきましたので、その様子を報告いたします。 ※昨年の様子はこちら www.lifull.blog 昨年に引き続いての「直列ハイブリッド」開催 コロナ禍の影響が徐々に薄れ、対面形式でのイベントが再開される中、DEIMでは昨年に引き続き「直列ハイブリッド」というユニークな形式で開催されました。 2月28日から3月1日までの3日間はオンライン開催、土日をはさんで3月4日・5日は兵庫県姫路市の会場での現地開催でした。 オンライン開催用に配布されたロゴ入りバーチャル背景。LIFULLも前回に引き続き協賛しております 現地会場のアクリエひめじ（兵庫県姫路市） ハイブリッド開催のイベントは今や一般的になりましたが、どうしてもオンライン参加者と現地参加者の間のコミュニケーションが難しくなってしまうという課題があります。 オンライン開催中には多くの発表を集中して聴講し、現地開催中には多くの参加者との交流をもつことができる開催形態は、参加者としても利点が多いと思います。 開催にご尽力いただいた関係者の方々に、心からの敬意を表したいと思います。 スポンサー企業各社の常設展示会場。今回も多くの方々と交流をもたせていただきました 大規模言語モデル(LLM)のインパクト 2022年11月にリリースされたChatGPT、およびその技術的基盤となる大規模言語モデル（LLM）は、AI、情報処理に関する研究にも大きな影響を与えています。 とくに自然言語処理分野でなされてきた研究課題のうちかなりの部分は、LLMによって解けるようになったこともあり、研究のテーマ設定自体が大きく変わりつつあります。 DEIM 2024でも、40件以上のLLMに関する研究発表が行われており、トレンドの大きな変化を実感しました。 また、3月4日に開催された チュートリアルセッション でも、LLMに関する以下のチュートリアルが企画され、いずれも多くの参加者を集めていました。 クラウド環境で駆動する生成系AIの最先端 LLMと音声理解・生成の最新動向 大規模言語モデルに基づく検索モデル LLMの嘘：ハルシネーション解説 共有データ資源のこれから LLMなどの生成AI技術が飛躍的に発展する中、生成AIが必要とするデータ資源の存在が、あらためて注目されています。 LIFULLでも、 国立情報学研究所（NII） のご協力のもと、 LIFULL HOME’Sデータセット を2015年11月より学術研究用途に提供しています。 現時点で 170件を超える研究成果 が発表されていて、 LIFULL HOME’S 3D間取り などの新たなサービスの実現にもつながっています。 www.lifull.blog AIや情報処理に関する研究は、多くの研究者がアクセスできる共有データ資源の存在に支えられて発展してきました。 Webに蓄積された大量のデータ資源が、自然言語処理や画像処理などの研究の発展を促すとともに、Webを活用したビジネスの発展の基盤となり、さらにWeb上のデータ蓄積を加速するという「好循環」が、AIなどの発展を支えてきました。 一方で、生成AI技術の隆盛は、「データを独占的に保有すること自体が巨大な利益につながる」という状況も生み出しています。 こうした状況で、「好循環」が滞ってしまうのではという懸念も出てきています。 2023年には、Twitter社（現X社）が、これまで学術研究者向けに認めてきたAPIの利用を停止するという出来事もありました。 techcrunch.com こうした流れの中、今後のAI研究を支えるためのデータ資源のあり方を、改めて振り返ることが必要ではないかと考えています。 DEIM 2024では、LIFULLからの技術報告として、「不動産情報サービスの研究開発における研究データ資源」についてのプレゼンテーションを行いました。 この発表では、LIFULLにおけるデータセットの共有と活用の取り組みを紹介するとともに、Webが出現するより前の1990年代からの共有データ資源をとりまく環境の変化を俯瞰した上で、今後の共有データ資源の健全な発展を図るための方策についての考察を行いました。 もしよろしければ、ぜひ発表資料をご覧ください。 speakerdeck.com LIFULLでは、 Webインテリジェンスとインタラクション（WI2）研究会 や、2024年5月に浜松で開催される 人工知能学会全国大会（JSAI 2024） など、複数の学会イベントをこれからもサポートしてまいります。 また、LIFULLでは、共に成長しながら働く仲間を募っております。 現在、以下の職種を募集しております。LIFULL HOME’Sデータセットなど、豊富な研究開発資源を活かしながら、多様な社会課題の解決に向けた研究開発やプロダクト創出に取り組んでみませんか？ hrmos.co hrmos.co ご興味をお持ちの方は、ぜひお問い合わせください！

こんにちは。フロントエンドエンジニアの根本です。 LIFULL HOME'Sのプロダクト開発と、スポーツ関連の新規事業開発に携わっています。 2024年5月18日に開催された「RESEARCH Conference」というリサーチをテーマにしたイベントに登壇いたしました。この記事ではそのイベントや登壇内容についてご紹介します。 RESEARCH Conferenceとは？ researchconf.jp RESEARCH Conferenceは、リサーチをテーマとした日本発のカンファレンスです。 より良いサービスづくりの土壌を育むために、デザインリサーチやUXリサーチの実践知を共有し、リサーチの価値や可能性を広く伝えることを目的としています。 行政、大企業、スタートアップなど立場の違いを超えて活発な議論を重ね、共に学び合うリサーチコミュニティを育てることを目指します。（上記ページより引用） 上記のように、このイベントでは「リサーチ」というテーマに対して組織形成やプロジェクトでの取り組み事例など様々な切り口のセッションが開かれ議論できる場になっています。 LIFULLでは毎年スポンサーとして協賛しており、今回はリサーチを活用した開発プロセスについてエンジニアという立場からお話をする機会をいただきました。 発表内容 今回のカンファレンステーマは「ROOTS」。私たちは「プロダクトに命を吹き込む：UXリサーチとエンジニアリングの共創」と題し、UXリサーチャーと共に登壇しました。特に、本記事では開発プロセスに焦点をあてた内容を紹介します。 チーム構成 今回のプロジェクト事例では、プロダクトオーナー、UXリサーチャー、UXエンジニア、デザイナーの4名で先行リサーチを行い、施策検討段階で開発チームと合流し開発プロセスを進めています。本チームでの開発プロセスについて下記で紹介します。 職種分業体制 私たちのチームで中小規模の開発に取り入れている職種分業体制では、主に企画とデザイナーがバディとなり、リサーチ結果を仕様に落とし込んだ仕様書という形でエンジニアにバトンタッチする進め方を採用しています。 その結果、開発規模が大きくなった時、顧客理解や仕様理解不足が発生し開発停滞や後戻りが発生することも少なくありません。 職種連携体制 新規開発など大きめのPJを進めていく場合、職種分業体制ではなく職種連携体制を採用し開発を進めています。 この体制ではリサーチに携わっている、企画・デザイナー・UXエンジニアの３職種が連携し仕様の落とし込みを実施しています。 UXエンジニアが仕様策定に関わることで、後続の開発フェーズではエンジニアと仕様意図をしっかりと共有しながら技術的な設計のすり合わせが可能になります。 UXエンジニアの介在価値 UXエンジニアが担う仕様作成では、 職種横断チームでのUXエンジニアとしての働き方 - LIFULL Creators Blog でも過去に紹介しているようにテクニカルプロトタイプを用いて仕様のすり合わせを実施します。 その結果、リサーチ内容をプロダクトに昇華していく工程がよりシームレスになり好循環な開発プロセスを実現できるようになっています。 このようにプロジェクト規模や組織体制に合わせて柔軟な開発プロセスを踏み、その中でエンジニアも当事者意識を持ってリサーチに関与していくことが重要であると考えます。 発表資料はこちらからご覧ください。 www.docswell.com イベントに参加した感想 今回登壇するにあたり、自分にとってのリサーチの「ROOTS」とは何かを思い返しました。 元々、大学の研究では認知心理学、認知科学分野を専攻し人の認知的な特性を理解した上で、情報システムはどうあるべきかという点を考えていました。 それらを知るためのリサーチであり、エンジニアとしてプロダクト開発をしている今もその「ROOTS」を持ってリサーチに関わっているのだと振り返ることができました。 今回登壇されていた様々な企業・団体の方のリサーチへの取り組みは興味深いものばかりで、とても勉強になり刺激にもなりました。 また、AI活用などによりリサーチ作業自体の効率化をエンジニアとしてサポートできるという発見もあり今後は様々な形でリサーチを推進していこうと思う機会になりました。 最後に LIFULLではリサーチを活用しながらプロダクト開発を一緒に推進してくれる仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の興津です。私は普段アプリケーションエンジニアとしてLIFULL HOME'Sのサイト改善業務しています。そのかたわらで、社内の制度を利用して、LIFULLのサービスの一つであるACTION FOR ALLの企画もしています。 今回はそんなLIFULLの独自の制度である「キャリフル」と、その経験を通して私が得られたものについて紹介します。 LIFULLの独自制度「キャリフル」について まず初めに、エンジニアの自分が企画に挑戦することを可能にした、LIFULLの独自制度である「キャリフル」を紹介します。 キャリフルとは、LIFULLの社内兼業制度で、業務時間の1割程度を本業とは別の業務ができる制度です。 私のように、普段とは別の職種に挑戦することもできるほか、たとえば同じエンジニアでもLIFULLの別のサービスの開発に携わることも可能です。 キャリフルについては公式Noteでも紹介しているため、もっと詳しく知りたい方はこちらをご参照ください。 corp.LIFULL.com 私がキャリフルに応募した理由 私がACTION FOR ALLの企画職に応募した理由は2つあります。スキルアップとビジョンマッチです。 企画職を体験することでスキルアップをしたい 自分のキャリアビジョンを考えた時、これからはエンジニアの業務だけではなく、一緒にサイト改善を担う企画やデザイナーの業務にも気を配れる存在になりたいと考えました。 特に前職が顧客の社内Webサービスの構築PJに参画することが多かったこともあり、企画職が何をする仕事で、何をエンジニアに期待していることがまったくわからない状態でした。 企画のことを知るためには、実際に企画を経験してみるのが一番よいと考え、企画のキャリフル募集を探し始めました。 ACTION FOR ALLのビジョンに共感し、事業に貢献したい 運が良かったことに、探し始めた時とほぼ同じタイミングで、企画の未経験でも応募可能な募集が始まりました。それがACTION FOR ALLの企画です。 ACTION FOR ALLは国籍や人種、性別、背負うハンディキャップにかかわらず、誰もが自分らしく「したい暮らし」に出会える世界の実現を目指す事業です。 さまざまなバックグラウンドを持つ人が安心して相談できる不動産会社を探すことができるFRIENDLY DOORなどのサービスがあります。 actionforall.homes.co.jp 私がLIFULLに入社を決めたのも、ACTION FOR ALLをはじめとした、社会課題の解決に事業として本気で取り組んでいるところに共感したからでした。 特に、私は長年プライベートでも社会的弱者とされる方々の支援活動を行っていたこともあり、LIFULLの数ある事業の中でもACTION FOR ALLは最も好きな事業です。 いつかACTION FOR ALLに貢献できる仕事ができればと思っていた中で、キャリフルの募集はまたとないチャンスでした。 こうして、企画のキャリフルに応募したいと思った時と同じくして、携わってみたいと考えていた事業の企画が募集をしていたため、応募しました。 挑戦して知った、企画職のたいへんさ 施策案を作ることの難しさ LIFULLにおけるサイト改善の企画職の仕事のメインは、現状のサイトの課題を見つけ、その解決策を立案することです。 言葉にすると簡単ですが、やってみると想像以上に難しいことを痛感しました。 まず、先輩方がアップデートを続けてきたサイトに対して、課題を見つけ出すことすら私にはできませんでした。見慣れて愛着が出てしまっていることもあり、「もう今のサイトが完璧なのでは」と言う気持ちになってしまいました。 先輩方の助けも借りながらなんとか課題を見つけることができても、今度はその解決策を見つけることができませんでした。たとえば、FRIENDLY DOORの会社情報が長すぎるのでは、という課題が出た時に、皆で情報を整理してスッキリできないか案を出し合おうということになりました。しかし、私は考えても「全部の情報が必要！」という思考になってしまい、よい案を思い付くことができませんでした。その時に先輩方からは「ほかの同じようなサイトもよく見て、参考にできるようなものがないと見てみるとよい」というアドバイスをいただきました。企画の人たちは自分たちのサービスだけでなく、競合他社をはじめとした世の中のさまざまなサービスを見ているんだと気付かされた一件です。 さらに、施策を立ち上げた後に行う仕様作成でも、簡単な施策であっても実際にドキュメントに起こしてみると、「こんな細かいところまで考えなければいけないのか」という気付きの連続でした。たとえば、私はFRIENDLY DOORの駅・路線での絞り込み機能を追加する施策の仕様作成を担当しました。この施策も、「複数の路線が通る駅で絞り込まれた時のURL」や「複数の駅が選択された時のH1の文章」など、検討しなければいけないことがたくさんありました。一つ一つの検討事項の結果がサービスの質や売り上げにつながっていくと思うと、いわゆる「決めの問題」となる些細な決定でも責任を感じました。 開発を託すことの不安 無事に仕様が完成し、エンジニアに託した後も、企画はけっして気が抜ける状態ではないということを知ることができました。 エンジニアとして自分が開発者として参画しているときは、現在どんな進捗で、どんな課題があって、計画通りにリリースができそうか否かが簡単にわかりました。それに、何かトラブルが発生したとしても「いざとなれば自分が必死になって頑張る」という最終手段があるという安心感もあります。 企画の場合は、開発中は大きなトラブルなく進むことを祈るしかできません。トラブルを防ぐための打ち手として、事前に仕様を十分に検証するということは可能ですが、開発が始まった後にできることはあまり多くなく、非常にもどかしい気持ちになりました。進捗が遅れた時のリリース日延期の判断や、リソース調整など、企画としてできることにおいても、その判断を早くするためには進捗の把握を積極的に行わなければならないということに気付きました。 最も、私の本業はエンジニアであるため、最終的には自分も開発に入ってなんとかするという判断ができますし、実際にそうした施策もありました。しかし、本業がエンジニアでない企画はそうもいかないので、さらに不安が大きいであろうことは想像にかたくありません。 施策が実を結ばなかったことの悔しさ 企画の先輩方にアドバイスをもらいながら仕様を作り、エンジニアに多くの工数を使って改修してもらった施策が、必ずしもうまくいくとは限りません。 中にはリリース後にビジネス指標が悪くなってしまい、緊急で改修前の状態に戻す判断が必要となった施策もありました。 たくさんの人の協力を得ながら行った改修の結果が悪かったことは、本当に悔しく、皆に対して申し訳ない気持ちになりました。 企画の人たちはこんなプレッシャーとともに施策を打ち出しているのかと思うと、頭が下がる思いです。 エンジニアの自分だからこそできること 企画のたいへんさがよくわかった一方で、エンジニアだからこそ企画業務で活かせることもいくつかありました。 技術観点から策定する仕様 仕様を決めるときに、自分がエンジニアであるため、既存のソースコードやDB構成などを自分で確認できます。 そのため、仕様を決める時に実装のしやすさや性能などを考慮した仕様を考えることができました。 もちろん、そこをエンジニアに相談して一緒に仕様を決めていくことも可能であり、普段の業務でもこうして進めていくことも多いです。 それでもエンジニアのリソースを別のところに使えることは効率的でした。 SQLを用いた分析 先日、FRIENDLY DOORでは住宅弱者フレンドリーな物件一覧のページをリリースしました。 LIFULL.com この一覧ページを作った後に、この一覧に掲載される物件の傾向を分析することになりました。「一覧に掲載される物件はどんな増減をしているのか？」「都道府県ごとに差異はあるのか？」「フレンドリーな物件を多く扱う不動産会社はとは？」ということを知れば、次の打ち手の材料にできると考えたためです。 上記の疑問点は、SQLで件数を調べることで知ることが可能です。 こちらもエンジニアに依頼して調べることも可能ですが、ちょっと気になった件数も自分で簡単に調べられるのはエンジニアならではの強みだと思います。 普段の業務での知見を活かした改善 ACTION FOR ALLではLIFULL HOME'Sとは異なる独自のドメインやリポジトリを有していますが、LIFULLでは技術的に管轄している部署が存在していない状態でした。 開発は施策ごとにベトナムの開発拠点であるLIFULL Tech Vietnam Co.,Ltd.(以下LFTV)に依頼しているため、サービスのリリース当初から保守運用があまり積極的に行われていない現状がありました。 そこで、普段の業務で行っていることを活かし、ライブラリのアップデートの推進やテスト用の環境の整備などのエンジニアとしてできることも積極的に行っています。 キャリフルの経験を、普段の業務に活かしていく 普段の業務の経験をキャリフルで活かすことも可能ですが、逆にキャリフルで得た経験が普段の業務に活きていることも感じています。 企画に寄り添えるエンジニアに 当初の目論み通り、企画が行う業務や企画ならではの困難さを体験したことで、企画に寄り添えるエンジニアとして成長できていると感じています。 たとえば、日々の進捗確認では一見エンジニアどうしで把握しておけばよいかもしれないことも、可能な限りエンジニア以外にもわかりやすい言葉を使って説明するようにしています。開発の進捗が端的にしかわからないことは不安であることを知ったからです。 また、施策の結果が数字としてはうまくいかなかった時こそよかったところを見つけて前向きな言葉を発することを心がけるようになりました。結果が振るわなかった時の企画の悔しさや決断の重圧を身をもって知っているからです。 次の段階としては、より確度の高い施策を作れるように、エンジニアの立場からバックアップできることを考えていきたいと思っています。 エンジニア組織のいないサービスに参画したことで、技術的に強くなった ACTION FOR ALLには専属のエンジニアが存在しないため、障害対応が発生した時は自分しか調査をできる人間がいませんでした。（2024年1月現在は、開発を依頼しているLFTVのメンバーも障害調査ができる権限を付与し、一緒に調査ができるよう整備しています） 普段は同じチームの先輩方に頼れる技術的な判断も、自分に委ねられることになります。 この状況に身を置くことで、技術的にも成長できました。もちろんこの成長は、普段のエンジニア業務の中でも糧になっています。 終わりに このように、LIFULLでは自分の所属以外の業務や職種にも積極的にチャレンジできる環境が整っています。 さまざまなことに挑戦して成長したいと考えているエンジニアの方は、ぜひ以下のページも見ていただけますと幸いです。 hrmos.co hrmos.co

プロダクトエンジニアリング部の二宮です。 次のプレスリリースにある通り、LIFULLでは生成AIを使って20,000時間以上の業務時間削減をしたという大きな成果を上げることができました。数字の根拠が粗い試算ではあるものの、実は社内では1年間で20,000時間の削減を目標としていたため、その半分の期間で目標達成できて関係者が色めき立っています。 lifull.com 私は keelaiという社内用AIのプロジェクト に開発者の一人として関わっていて、生成AIツールの活用を推進する有志のプロジェクト（タスクフォースチーム）にもメンバーの一人として携わっています。そのため、エンジニアの中でもある程度全体が分かる立場として、生成AI技術の社内普及のための取り組みについて共有します。 私は各部署の導入の相談やプロンプトの技術サポートを担当することが多く、社内発表も行っているため、結果的に生成AI関連のチームの中でもいろいろな人から声をかけられたりして情報が集まる立場になりました。その技術と普及活動の両面で話をします。 LIFULLの生成AI活用の現状 現在、keelaiは月間でおよそ580人に利用してもらっています。去年の11月に『 社内向けAI botの運用で学んだ技術コミュニケーションのコツ 』という記事を書いた時点では次のような状態だったので、そこからも大きく伸びました。 keelaiはSlack上で動くAIチャットボットを含んだ "汎用AI(仮)" 技術スタックで、LIFULLグループのSlackユーザーおよそ1000人程度の中で月間200人以上に利用して頂いています。これはけっこうな成功例と言っていいんじゃないでしょうか？ 社内での利用実態を見ても、keelaiはすでに社内で当たり前に使われているツールになったと思います。 内製AI（keelai）の開発・活用方針 ほとんどの内容は、KEELチームの相原さんが以下の記事で紹介している通りです。「なるべく作らない」方針で、Slackで利用できるチャットボットを主軸に社内の汎用的に使える機能を提供するようにして、個々の部署の問題は各部署でプロンプトエンジニアリングやSlackワークフローの設定ができるようイネーブリングしていく作戦で少人数での開発を実現しています。実は私自身もKEELチームに所属しているわけではなく、インナーソースのコミッターとして活動しています。 www.lifull.blog 汎用AIを目指す上でもあらゆる業務上の課題を解決する機能を私達だけで実装することは現実的ではないため、「なるべく作らない」ことでコストとバランスが取れたスケーラビリティだけを素早く示してインナーソースによって成長していくことを目指しました。 この記事の時点からさらに発展した点として、 Slackワークフロー と組み合わせて、ノーコードで生成AIを使った自動化機能を実現できるようになったことが挙げられます。例えば、『 海外の開発拠点メンバーと、受託先ではなくチームメンバーとして協働するための取り組み 』では、海外チームとのやり取りを生成AIで翻訳する使い方が紹介されています。 他にも、Slackワークフローのフォーム投稿を利用して、例えば総務では社内のFAQのRAG（社内情報検索）を使って一次回答をする機能を用意しました。私も便利に利用しています🙇 少し技術的な余談ですが、keelaiの投稿完了後に :keel_complete: という絵文字を付与していて、更に続けて別のSlackワークフローを起動できるように工夫しています。例えばプログラムでkeelaiに多数の問い合わせを投げ、その結果をGoogle Sheetsに収集するなどの使い方もできます。これを利用して、先日 クリエイターの日委員 によってSlackワークフローとkeelaiを使った自動化のハッカソンが実施されました。 生成AIを活用した会社の成功事例として、よく内製生成AIツールのログを徹底的に残して良い事例や注力ポイントを見つけている話を聞きますが、keelaiではプロンプトのログをあえて残していません。その代わりに公開チャンネルでの利用内容を定期的に見ているのと、Slackメッセージ内に誤回答の報告ボタンを用意することで代替しています。これはプライベートチャンネルやダイレクトチャットで、部門外秘の内容まで気兼ねなく利用してもらえるようにするためです。 普及のためにやったこと せっかく便利な機能を用意しても、それに気づいて使ってもらえなければ意味がありません。生成AIの力を普及させるために、各社でいろいろ苦心されていると思います。我々もその点は同様で、あの手この手を考えていろいろなメディアを通してコミュニケーションしています。 社内ゼミ Generative AI Award (GAIA) 相談窓口の準備 ドキュメントの拡充 Slackの広報 各部門の推進リーダーがいること これらの発表の後に「さっき紹介した事例に似たことを自分の部署でもやってみたいんだけど…」と声がかかることが多く、大きな活用促進のきっかけになることも多いです。 また、keelai自体がそうなのですが、これらは戦略的に考えられたものだけでなく、社員の自主的な動きが事後的に公式化したものも多いです。そういうボトムアップな動きがちゃんと合流できてるのもすごい点かもしれません。 社内ゼミ こちらの『 LIFULLの挑戦の機会と制度 』という記事にある通り、LIFULLには社内大学の制度があります。この制度を使って生成AIのプロンプトエンジニアリングのゼミを行いました。 社員が学びたい事をその分野に特化した社員が講師となって教えあう、大学のゼミのような勉強会が実施されています。 このゼミは実は公式の取り組みではなくて、 プロダクトプランニング部の部長の大久保慎さん が自主的に行ったものです。つまり正確にはLIFULLの生成AIチームの公式の取り組みではありません（もちろん内容のチェックや広報などで協力しました）。 このゼミの内容は、「初心者がプロンプトの基礎を学んですぐに中級者になることを目指す」ようなものでした。これは200人を越える社内ゼミ過去最高の参加人数を記録し、事後の内容の評判も良いものでした。実際にこのゼミをきっかけに利用者は大きく伸び、大きな自動化案件のきっかけにもなりました。 Generative AI Award (GAIA) 『 20,000時間以上の業務時間を創出 』にも記載している通り、LIFULLではGenerative AI Award (GAIA)という表彰を行っています。ただし、今のところはインセンティブ提供というより成功事例の普及が主目標で、特に賞品などを用意しているわけではありません。 また、上記診断によって活用度が高い従業員を表彰する「Generative AI Award(通称GAIA)」を月一回実施することで、優良事例の水平展開と共にモチベーション向上にも繋げています。 LIFULLにはThink Togetherという、役員と直接質問や議論できる場があります。そこで会長の井上さんにkeelaiや生成AIの話をしていて「本当はもっと盛り上がる方法があるんじゃないか」と言ったところ、「じゃあ全社総会で時間空けとくから何か発表してみてよ、 長沢翼（CTO） と一緒に！」と言われて突如始まりました。当時私はkeelaiの開発に関わっていたものの、生成AIを推進するタスクフォースに所属しているわけではなかった（後に合流した）ので、事情を知らない人からすると急に始まった謎コンテンツだったと思います😂 そこでアクセシビリティのチーム（『 フロントエンドエンジニアが組織横断のアクセシビリティ専門部署を立ち上げた 』）が既にエンジニア組織内でアクセシビリティに対して勝手に表彰する取り組みを行っていたので、長沢さんのアイデアでそれを生成AIの文脈で真似しました。具体的には生成AIを大きく活用できた事例を見つけ、代表者にインタビューした内容とともに発表しています。 内容は次のようなことを心がけています。 聞いてて面白い内容にする：特にオンラインでの発表になることが多いので、客観的な評価基準を設けるというよりは、本当に自分たち自身が面白いと思う事例を取り上げて、やや大げさなレベルで「ここがすごい」と言って分かりやすくすることを意識しています。 平均値ではなく例外に注目する：例えば「平均的に活用度が高いエンジニアチーム」ではなく「同じ職種の中でも例外的に活用度が高い営業チーム」にインタビューしました。そして普及のために何をしたのか、周囲のメンバーの反応で助かったことはあるのか等を聞いていきました。 「自分だったらこうするだろう」という意識を持って話を聞いて意外な点を見つける：例えば普及率の高い営業チームの人に話を聞く際に、「自分でもSlackや総会発表で積極的にアナウンスすることは思いつくし、他のチームでもそれはやっている。じゃあむしろ共有内容や周りの雰囲気に違いがあるんじゃないか」などと仮説を立ててインタビューしました。その結果、「とにかく新しいものを気軽でおもしろ用途から試して身近に思ってもらう。周囲にもそういう面白さを受け入れる雰囲気がある」ということが分かりました。 これらの指針は、LIFULLで社内導入された 中尾さんのKPIマネジメント の考え方のツールの1つである TTPS（徹底的にパクって進化させる） や、UXリサーチの方々が勧めていた メタファシリテーション の考え方にも影響されている気がします。 こういう普及活用はどうしても「必要なのは分かるけど別に興味は湧かない。ひとまず最低限言われたことをするか」というような減点思考の捉えられ方をされてしまいがちです。そこで加点思考のコンテンツを用意するのは良い雰囲気を作るのに役立つことだったと思います。 相談窓口の準備 サポートとして、Slackに相談窓口を用意しています。各部署でオーナーシップを持ってもらって、複雑なプロンプトの改善やアイデアを相談できるようにしています。最近ではSlackの ハドルミーティング を使ったオフィスアワー方式の相談会も試しています。 ドキュメントの拡充 使い方を説明するドキュメントはしっかり準備しています。特にkeelai Showcaseというプロンプトや利用例を紹介するページがあります。 「誰でも」と言ってはいるものの、それほど関係者外からの投稿は多くなく、ほとんどkeelaiチームの関係者が投稿しています😅 誰かに書いてもらうというよりはむしろ、ここの事例の中から近いものを紹介して別のチームにアドバイスすることや、この内容を見て「似たことができるかも」と声をかけてもらうことに役立っています。他にもSlackワークフローの設定手順や利用方法を動画で説明したり、色々とやり方を試行錯誤しています。 最近は生成AIのタスクフォースチームとして、GAI WIKIという「LIFULL社員が生成AIで知りたいことが大体分かるリンク集」のようなページを用意しました。 Slackの広報 『 社内向けAI botの運用で学んだ技術コミュニケーションのコツ 』にも書いた内容です。「次の行動を喚起する」ことを意識し、大抵はサポートチャンネルへの誘導を目的にしています。 自分自身が受け手になったときのことを思い出しても、この手の広報はほとんど素通りされて、後で「え？こんな便利なツールが用意されてたの？教えてよ！」って思うことが多いはずです。それを防ぐためには、「興味の扉が開く」ようなタイミングを狙って投稿すると良いんじゃないかと感じています。つまり、新しい機能リリースや面白い事例がある度に共有する、オンラインの総会で関連する話題が挙がったときに参考になるドキュメントをコメントするなど、皆の興味が高まるタイミングにすかさずアピールすることを心がけています。 各部門の推進リーダーがいること プレスリリース にもある通り、各部門に推進リーダーを立ててもらっています。 その他にも職種や業務特性に則して各論での利用促進を図るために、部門毎の生成AI活用推進リーダーを31名擁立し、網羅的な利用促進に繋げることができています。 これは実際に生成AIツールを推進する意味でも役立っていて、例えば「GAIAで表彰するときにその人に詳しく話を聞く」とか「活用度診断があるときにその人を通じて広報する」などで連携していて、他の取り組みを支えるベース担っていると思います。また、何か部署内で困りごとがあるときに、その方から連絡が来ることが多いです。 ただ、普段の推進リーダーの活動を、各々の自主性だけにまかせきりになってしまっている部分が多い点は課題だと思っています。もし自分が任命されたとしたら、ひとまずSlackや総会で情報共有はするものの、それ以上のことをどうすればいいか困ってしまうはずです。ただその分、先ほどGAIAの項目でも触れた、営業チームに聞いたおもしろ画像や音楽での盛り上げ方は想定外でビックリしました😂 今後の展望 最後に今後の展望をまとめます。おおまかには、生成AI推進のタスクフォースチームとして引き続き利用開始できていない人やチームに更に普及させていくことような動きをしつつ、特にkeelaiのチームとしては、成功したチームの施策を更に進展させる次のような取り組みを行うつもりです。 keelai APIの提供 keelaiのAPIを準備して、開発組織の中でより便利な効率化を行おうとしています。 まずGitHub Actionsを使って「社内ドキュメントや仕様書をうまく検索してアドバイスする」ような自動レビューを提供しました。LIFULLでは『 コマンド1発でKubernetes上にProduction Readyな環境を手に入れる 』で紹介されているkeelctlというツールが広く使われているので、主要なリポジトリにすぐ導入できます。 他にもプロダクトのエラーログを参照し、エラー発生時に簡単な問題であればそのままプルリクエストを作るなどいろいろな構想があります。これはシステム基盤も含めて内製していることのメリットだと思います。 過去に関わったチームのフォローアップ keelaiの社内での普及率は順調に上がってきたため、ここから大幅に利用者数が増えることは無いと考えています。そこでむしろ、過去に相談したことのあるチームに、プロンプトはきちんと動作しているか、他に困っていることが無いかなどを聞いてより深化させるチャンスが無いか探ろうと思っています。 また、別のSlackワークスペースの子会社からもSlackコネクトされたチャンネルで利用できるようにしているのですが、利用実態がよく分からないまま放置してしまっているので、そこにも取り組む必要を感じています。 社内コミュニティを盛り上げる （これはやや個人的な目標ですが）LIFULLには 社内サークル制度 があり、生成AIについて広く情報共有するサークルが設立されました。もちろん私もメンバーとして参加しています。 今のところ、ランチしながら生成AIのツールや使い方を話すことが活動内容のほとんどですが、更に何かもう少し広く役に立つ勉強会などの企画をしたいと思います。また、サークルには推進リーダーの方も何名か参加しているので、各部署の面白い普及の進め方を吸い上げて展開することもできるかもしれません。ボトムアップの方向からの動きも更に盛り上げるつもりです。 GAIPの知見を広げる またLIFULLには ジェネレーティブAIプロダクト開発ユニット（通称GAIP） という生成AIを使ったプロダクト開発の専門組織（『 さっそく試してみた！国土交通省不動産情報ライブラリAPI x 生成AI！ 』）があります。そこが生成AIのプロダクト開発の多くの知見が溜まっているようで、私の所属するプロダクトエンジニアリング部の注力ポイントとしても生成AIが挙げられているものの、それをつなぐ取り組みはこれからです。 最後に LIFULLでは一緒に自分たちの仕事を良くしていくエンジニアを求めています。これらの取り組みに興味を持っていただけたなら、ぜひ求人情報やカジュアル面談のページもご覧ください🙇 hrmos.co hrmos.co

グループデータ本部データサイエンスグループの嶋村です。 グループデータ本部は、 LIFULLグループで生まれる新たなデータを安全かつ効果的に活用 できるようにし、 事業の変化と持続的な成長を促進 することを目指している組織です。その中で、データサイエンスグループは研究開発組織として、 「活用価値のあるデータを創出」 し、 「データを活用した新たな機能やサービス」の研究開発 に取り組んでいます。 事業を革進し続けて様々な社会課題を解決していくために、 データを最大限に活用できる状態にしていきたい と考えています。その一環として、分析に関わる社員全員に対して、真のドメイン知識獲得、またデータ分析リテラシー向上の機会としてLIFULLファクトブックの作成に取り組んでいます。 LIFULLファクトブックとは LIFULLファクトブックは事業部のアナリストと連携をしてトライアルとして昨年から作成を始めていたのですが、形として完成してきたことから、先日、社内でLIFULLファクトブックの紹介をしました。 トライアルの中で試行錯誤を続け洗練 してきたこともあり、 広く興味を持ってもらえる結果 となりました。その際の資料をお見せできる範囲で用いながら、LIFULLファクトブックとは何か、ご紹介したいと思います。 LIFULLファクトブックに関する取り組みには 2つのねらい があります。1つ目は 「真のドメイン知識の獲得をすること」 で、良質な仮説を作れる状態やドメイン知識が共通化される状態にし、事業革進の効率を高めるということです。2つ目は 「分析リテラシの向上をすること」 で、正しい分析や説明を意思決定層へ届けることで、迅速で正しい意思決定ができる状態にすることです。 たとえば、分析をする際に「代表値」として「平均値」が使われることが多いですが、統計的な知識を持たず、「とりあえず平均値で」という状態だと誤った解釈になり、正しい意思決定にもつながりません。分布の特性次第で平均値が良いのか、中央値や最頻値といった他の代表値が良いのか、変わってくることがあります。また、二峰性など複数の分布が混在している場合では、分布を確認したうえで成分を分ける必要もあります。 LIFULLファクトブックを活用し、 実際のデータがどのような分布になっているのかを確認 するだけでなく、読み会と呼んでいる集まりを通じて 継続的にディスカッション をしています。特定の仮説や目的を持った分析（アドホック分析や深堀り分析と呼んでいます）とは異なり、様々な軸での分布を見ることでファクトを確認します。その際に、 今までの経験から想像していたデータと実際に確認したデータが異なるという気づきを得られることが多く、正しくファクトを定着させることが重要 であると再確認できました。 下図はLIFULLファクトブックのコンテンツ例です。 左側に分布を理解するためのグラフ があり、 右側に要約や説明が記述 されています。左側のグラフでは、需要と供給を表すデータの分布をそれぞれ載せており、 分布の山の違い が一目でわかるように可視化しています。また、 累積分布 を載せることで、分布のビン幅（横幅）に囚われず、 分布の形状を正しく理解 できるようにしています。右側では、各種統計量を載せ、 グラフおよび統計量から読み取れるファクトや考察 が記載できるようにしています。また、どのように作られたデータやグラフなのか、参加者が後からでもわかるように、算出方法の定義や関係資料へのリンクを載せられるようにしています。 LIFULLファクトブックの作成や読み会を通じて、様々な意見をいただきました。 当初は活動の意義がなかなか伝えられず賛同を得られない場面 もありましたが、 現在では読み会の参加者も大幅に増え大盛況 になっており、社内兼業制度「 キャリフル 」を活用して読み会での発表をする社員も増えてきました。最初はグラフやデータの読み方がわからない、という声がありましたが、一つ一つレクチャをすることで 「統計の基本知識がわかるようになった」 や 「ドメイン知識を得る良いきっかけになった」 といった声も多く集まりました。 おわりに 今回は真のドメイン知識を獲得しデータ分析リテラシを向上させる取り組みである「LIFULLファクトブック」の紹介をしました。 お知らせとなりますが、データサイエンス系の自社イベント 「 LIFULL AI Hub 100ミニッツ 」 を計画しており、次回は「LIFULLファクトブック」の取り組みについて紹介をする予定です。少しでも興味を持ってくださった方は、是非、気軽にご参加いただけると嬉しいです。 最後になりますが、データサイエンスグループでは「活用価値のあるデータを創出」し「データを活用した新たな機能やサービス」の研究開発活用を加速して下さる シニアデータサイエンティストを2枠募集 しています。 【研究開発職】データサイエンスで高難易度な技術課題に取り組む研究開発に興味ある方 【実事業への活用促進職】研究開発成果や新たなAI技術を活用し、実プロダクト・システム開発推進に興味ある方 いずれかに興味お持ちいただける方は、 カジュアル面談 も行っていますのでお気軽にご連絡ください。 hrmos.co

こんにちは。 LIFULLのグループデータ本部データサイエンスグループ所属の岩﨑です。 私の所属するグループデータ本部データサイエンスグループは、LIFULLのデータを通じて事業の成長を促す研究開発を担う部門です。 『データ科学と研究開発の成果によってワクワクと喜びを生み出す』をビジョンとして掲げ、AI技術シーズの創出や活用によってデータの価値を最大化し、社会課題の解決に向けて日々革進をし続けています。 2024年2月24日に開催された「第86回 Machine Learning 15minutes! Hybrid」という機械学習関連のLTを行うイベントで登壇いたしました。 この記事ではそのイベントや登壇内容、感想などを書いていきます。 Machine Learning 15minutes!とは machine-learning15minutes.connpass.com 「Machine Learning 15minutes!」は、「機械学習」について「15minutes以内」で語るLTを6～9人程度で行い、DeepLearningなどの先端的な事例、強化学習などの流行している技術、ビジネスへの応用例など、様々な角度から機械学習についての知見を広げ、LT終了後の懇親会でネットワーキングを行うイベントです。（上記ページより引用） 上に記載しているように、このイベントでは機械学習に関するLTを複数人で行います。その中でLIFULLからは、「LLMを用いた住まい探しにおけるユーザー価値観の推定」と題して、不動産業界でのLLMの研究・活用について共有・議論をしました。 同イベントはオンライン開催のみの時期もありましたが、私が登壇させていただいた第86回の前回からLIFULL AI Hubと協賛という形でLIFULL本社でハイブリット開催をしています。 なお、3/30に開催される次回第87回はミイダス社で、4/27（土）開催の次々回第88回は、再度弊社にてハイブリッド開催を予定しています。 私が感じたように第88回イベントも幅広い機械学習に関連する発表を聞いたり、専門の方と議論ができる機会となると思いますのでぜひ、会場へ足をお運びいただければと思います！ 協賛させていただいていますLIFULL AI Hubは、機械学習やデータサイエンスに特化した知見や成果事例などを社内外に発信していくことを目的としたLIFULL主催のイベントとなります。 詳細はこちらをご覧ください。 www.lifull.blog 発表内容 第86回の登壇者や発表内容は下記のページに記載されています。 発表は大きく3つのカテゴリに分けられており、各カテゴリの発表で機械学習分野の最新情報や社会実装例などの情報共有と議論が行われました。 machine-learning15minutes.connpass.com 生成AIの最新業界トレンド 発表1：【生成AI の未来】 14:05～ 発表2：【ニュース、映画、ゲーム、AIアバターまで、動画と世界を生成する。第2の生成AIブームに備えよう】 14:20～ LLMプラットフォーム最新状況 発表3：【LLMOps with Azure Machine Learning prompt flow】 14:35～ 発表4：【IBMの大規模言語モデルGraniteと生成AI Governance 機能のご紹介】 14:55～ 発表5：【自社で70B LLMを事前学習からやって日本最高精度を達成した話】15:10～ AIディスラプティブ 発表6：【ドメイン知識を活用した、薬局における来局予測】 15:25～ 発表7：【LLMを用いた住まい探しにおけるユーザ価値観の推定】 15:40～ 発表8：【画像・動画・音楽・スピーチ生成AIの進歩】 15:55～ 今後の生成AIについての議論（発表1）、LLM向けのプラットフォームの状況（発表3, 4）、日本最高精度を達成したLLM（発表5）など幅広い機械学習関連のお話を聞くことができました。 その中でLIFULLのデータサイエンスグループからは【LLMを用いた住まい探しにおけるユーザ価値観の推定】（発表7）と題して、不動産業界におけるLLMの活用に向けた研究の紹介をしました。 上記の発表資料はこちらからご覧ください。 www.docswell.com LLMは大規模言語モデル（Large Language Model）と名のつく通り、言語モデルとしてチャットボットなどに利用されることが多い印象を受けます。 しかし、今回紹介した研究ではLLMを単なる言語モデルとしてではなく、ユーザ行動のシミュレーションに利用することでユーザの価値観を深く理解したクローン（デジタルクローン）を開発しています。 このデジタルクローンはユーザの価値観に合った物件推薦や、ユーザにより使いやすいUI/UXへの改善に役立てることができると考えています。 現時点ではまだ研究の初期段階ですが、少ないサンプル数においてはLLMを利用したデジタルクローンが人間と近い物件評価（二つの物件の相対評価）が可能なことを確認できています。下のスライドでは、デジタルクローン・人間双方の物件評価の方法とその精度について説明しています。 イベントに参加した感想 このイベントの感想を参加者、登壇者と目線を分けて書いていこうと思います。 まず参加者としては、幅広い機械学習に関連する発表を聞いたり、専門の方と議論ができるというとても有意義な場だったと感じます。 最先端の技術の話はもちろん、実際に社会実装されている技術・システムのお話などもとても興味深いものでした。 また、会場の雰囲気もあまり堅いものではなく、気軽に雑談や質問ができるとても良い環境でした。 次に登壇者としては、LIFULLのデータサイエンスグループで行っている自身の取り組みを紹介し、意見をいただける貴重な機会だったと感じています。 発表の中でコメント・質問をしてくださったり、その後の懇親会で内容について議論ができたりと、研究やプロダクトをより良い方向へ改善していくためのフィードバックをたくさんいただくことができました。 最後に 今後、さまざまな方と研究開発に関して、意見交換や情報共有を行えればと考えております。 この記事を通じてLIFULLの研究開発に関心をお持ちいただけた方は是非こちらからご連絡ください。 hrmos.co

こんにちは、イノベーション開発室ジェネレーティブAIプロダクト開発ユニットの上田です。 2024/4/1に国土交通省の不動産情報ライブラリとAPIが公開されました！このAPIとGPTsを使って、生成AIでの活用を模索してみました。 不動産情報ライブラリとは 不動産情報ライブラリ 不動産情報ライブラリとは、不動産の取引価格、地価公示等の価格情報や防災情報、都市計画情報、周辺施設情報等、不動産に関する情報をご覧になることができる国土交通省のWEBサイトです。 具体的には、以下のように地図上で不動産情報を確認することができます！ 国土交通省不動産情報ライブラリ（千代田区麹町周辺） また、今回のサイトの公開に合わせて、APIも公開されています。 www.reinfolib.mlit.go.jp APIを利用することで、Webサイトで得られる、不動産価格情報（取引価格・成約価格）、国土数値情報（学区・医療施設・福祉施設・保育園・幼稚園など）などがJSON形式で簡単に取得可能です。 今回は、このAPIを使い「ざっくりした住所を伝えれば、その地域の周辺施設や価格情報を解説してくれるGPTs」を構築してみました！ 住所から周辺情報を教えてくれるAI 以下のように動作します。 LIFULLの生成AIチームのエンジニアが、先日4/1にリリースされたばかりの国土交通省の「不動産情報ライブラリ」のAPIを使ってGPTsを作りました！爆速すぎる！ #LIFULL #エンジニア #不動産情報ライブラリ #生成AI #GAI #GenerativeAI pic.twitter.com/WWfV9csvUj — LIFULL Developer (@lifulldeveloper) April 5, 2024 機能的には、住所を入力することで、その地域の周辺施設や価格情報を解説してくれる、以上のものはありません。 しかしながら、これによって不動産業界では以下のように活用できるのではないか、と感じています。 例えば・・ 不動産仲介業者は：物件やエリアの住所を用いての周辺施設や価格情報を手に入れ、物件の購入や賃貸を探すユーザ対して、ニーズに合った物件・エリアをより迅速に、より正確に提供できる。 物件探しを行うユーザは：GPTsなど生成AIのサポートがあることで、複数地域について気になる観点での比較や、そもそものデータの読み解き方についての知識を補うなど、利用ハードルを下げることができる。 と言ったものが想像できます！これらは今回作成したGPTsから想像できますが、さらに他のデータの活用も視野に入れて考えてると 地域密着情報に詳しい不動産アシスタントAI 地域情報をまとめたパンフレットの自動生成 その地域での暮らしのシミュレーション など、多くの活用が考えられます。 まとめ 不動産情報ライブラリは生成AIの領域においても十分活用可能であることが明らかになりました！ API利用の際には、利用申請が必要でしたが、公開初日に申請したためわずか1日ほどで利用可能になりました。 ※追記：2024/04/05時点では以下のような状況とのことです！ 現在、当初の想定を大きく上回るAPI利用申請をいただいております。 大変恐れ入りますが、APIキーが５営業日以内に発行できない場合もございます。 しばらくの間、ご不便をお掛けすることについて、何卒ご了承ください。 APIの利用申請はこちらから可能です！ https://www.reinfolib.mlit.go.jp/api/request/ また、国土交通省の各種のデータを含め、一つのエンドポイントからこれだけの情報を取得できるのはとても革新的です。各種施設の緯度経度も取得できるので、位置情報のデータ処理を加えることでより柔軟な表現で周辺情報などを扱えるため、より活用の幅を感じました！ 私が所属する組織のビジョンは「ジェネレーティブAIの力で、あらゆる住替え体験の次元を変え、誰もが理想の住生活をおくる未来を引き寄せる」です。我々の部署ではこうした生成AIを活用したプロダクト開発を積極的に行っています！このビジョンに共感し、一緒に新しい価値を創出していく仲間を募集しています！ hrmos.co hrmos.co

こんにちは。エンジニアの小林建太です。 今回はフロントエンド業務での課題をChrome拡張機能で解決を試みた事例をご紹介させていただきます。 LINEヤフー Techから2024年1月に公開された「Tappy」というツールにインスパイアされた拡張機能「 Tap Analyzer 」を開発し、公開しました。 chromewebstore.google.com Tappyとは Tappyの課題と着想 開発した機能 技術 技術選定 開発 chrome debugger API LLMの利用 活用のメリット 今後の展望 Tappyとは Tappy（ https://twitter.com/lycorptech_jp/status/1752587301564436593 より） Tappyは、LINEヤフー Techが開発したスマートフォンのウェブサイトでのタップ操作の成功率を可視化するツールです。URLを入力するだけで、そのページに含まれるボタンやリンクなどのタップ可能な要素のサイズを分析し、指で操作しやすいかどうかを判定して可視化します。現在はiOS端末の解像度のみ対応しています。 tappy.yahoo.co.jp Tappyの課題と着想 私はLIFULLにおいて認証が必要なページを開発していますが、UIについてはデザイナーが作成するデザインを実現するのみで定量的な評価ができていません。特にモバイルの利用者が多いため、ユーザビリティの分析を定量的に行えないかと考えていました。 Tappyで提供される「ウェブサイトでのタップ操作の成功率」はユーザビリティ（使いやすさ）とアクセシビリティ（情報に到達できるか）のどちらにも関わる指標としてある程度有用でしょう。 しかし、サーバー側で処理を行うため、動作にCookieやセッション情報が必要なページでは使用できません。 そこで、Tappyと同様の機能をクライアントサイドで実現するChrome拡張機能を開発することにしました。 ユーザビリティについては以下のIPAの資料が参考になります。 www.ipa.go.jp アクセシビリティについては以下のMDNの資料が参考になります。 developer.mozilla.org 開発した機能 作成したChrome拡張機能は、以下の機能を備えています。 拡張機能「Tap Analyzer」が動作している様子 ウェブページ上のタップ可能な要素(ボタン、リンクなど)の大きさを解析 要素のサイズからタップの成功率を算出 タップ成功率に応じてタップ可能な要素に色付けして可視化 技術 技術選定 拡張機能の作成には Plasmo を利用しました。 Plasmoはブラウザ拡張機能専用のReactフレームワークです。 テストや自動デプロイするための機能なども提供しておりオールインワンなフレームワークです。 Chrome拡張機能はクセが強いChrome APIを利用して作成する必要がありますが、Plasmoはそれらの面倒なポイントを抽象化してくれます。 主な特徴は以下の通り。 React＋Typescript ライブリローディング + React HMR .env ファイルサポート ゼロコンフィグで開発できる 競合としてCRXJSなども挙げられますが、こちらはViteをBundlerにした開発をスムーズにしてくれるもので、Chrome APIの抽象化などはしてくれません。 crxjs.dev 開発 chrome debugger API 私はこれまでに Webpack + Vue.js、CRXJS + Reactなどの構成で拡張機能を作成した経験はあるため、概ね苦労することはありませんでした。 その中で今回初めて触れたのがchrome debugger APIです。 chrome.debugger  |  API  |  Chrome for Developers 大雑把に説明するとChrome Dev Toolsで提供している機能をAPI経由で利用するものになります。 1 つ以上のタブにアタッチし、ネットワーク インタラクションの測定、JavaScript のデバッグ、DOM や CSS の変更などを行います。 今回の拡張機能のウィンドウサイズの変更に利用しています。 chrome.tabs.query ( { active: true , currentWindow: true } , ( tabs ) => { if ( tabs [ 0 ] ?.id ) { chrome. debugger .attach ( { tabId: tabs [ 0 ] .id } , "1.3" , function () { void chrome. debugger .sendCommand ( { tabId: tabs [ 0 ] ?.id } , "Emulation.setDeviceMetricsOverride" , { width: newDevice.getWidth (), height: newDevice.getHeight (), deviceScaleFactor: newDevice.getViewport () .deviceScaleFactor , mobile: true , fitWindow: true } ) } ) } ︙ } ) このように chrome.tab で現在のタブの情報を取得し、そのtab idに対してchrome.debuggerをアタッチしてウィンドウサイズを変更しています。 また、スクリーンショットの取得もchrome.debuggerを利用しています。 chrome. debugger .sendCommand ( { tabId: tabs [ 0 ] ?.id } , "Page.captureScreenshot" , params , ( result ) => { if ( result ) { // 画像保存 const downloadEle = document .createElement ( "a" ) downloadEle.href = "data:image/png;base64," + result.data downloadEle.download = "screenshot.png" downloadEle.click () } } ) LLMの利用 拡張機能開発の本筋ではありませんが、こういった試験的な開発を行いたい時に困るのがデザイン面です。 今回の開発においては拡張機能アイコンとポップアップウィンドウのUIのデザインをどう解決するか迷いました。 結果的に拡張機能アイコンはChatGPTのデザイン系のGPTsで作成し、UIのCSSはCopilotで適当なものを作成してもらい、完成としました。 ChatGPTで作成したアイコン画像 活用のメリット この拡張機能を活用することで、以下のようなメリットが期待できます。 モバイル向けUIのタップ領域の適切なサイズを検討できる 既存のページについて操作性を重視してUIを最適化できる アクセシビリティの観点からも適切な設計ができる Cookieやセッションが必要なページでもTappyの機能を利用可能 今後の展望 現在は一部の機能しか実装されていませんが、利便性を高めていきたいと思っています。 様々な解像度の端末への対応（現在はChrome Dev Toolsでデフォルト設定されたモバイル端末にのみ対応） UIの色分け以外の可視化方法の検討 ユーザビリティの向上 個人で開発したため、個人のRepositoryとして公開しております。 是非、皆さまの貴重な知見やコードをコントリビュートしていただき、一緒にモバイルUIの改善に貢献していきましょう。 github.com LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの江口です。 普段はLIFULLの海外拠点の一つである、LIFULL Tech VietnamのメンバーとともにLIFULL HOME'Sの賃貸領域でサイト改善業務をしています。 今回は、物件の詳細ページを閲覧したユーザー数を集計、取得するシステム（以下rent-pv-counter）を構築したので、その取り組みについて紹介します。 背景 賃貸領域では、A/Bテストによるサイト改善を行っています。特に私の所属するチームでは、より多くの検証を実施し、ユーザーの行動理解を深めることをミッションとしています。しかし、実装工数を削減し、速やかに検証を進められるコストパフォーマンスに優れた施策が主流となる中で、結果的に検証可能な仮説の範囲も限定されてきていました。 その中で、閲覧中の物件の閲覧人数を可視化することが、問合せへの後押しにつながるかの検証を行うことになりました。この施策はバックログとしてはあったのですが、工数の観点で見送られていたものの一つです。今回は、リリースまでどのようなことを意識して開発したのかを共有できればと思います。 システム構成 以下の図は、rent-pv-counter の大まかな構成図です。 rent-pv-counterのシステム構成図 APIはExtensible Service Proxy V2 (ESPv2) をAPIゲートウェイとするCloud Runで稼働しています。OpenAPIに準拠したyamlファイルを元に、ESPv2がすべてのリクエストを受け取り、認証等を行ってくれます。さくっと認証付きのAPIを作るにはとても便利でした。 また、DBはDatastoreを利用しており、ユーザーの閲覧ログを格納しています。 言語はGoで、WebフレームワークはGin を利用しています。APIはユーザーIDと物件IDを受け取り、その物件IDを閲覧したユーザー数を過去7日間、過去30日間で集計します。 集計結果の取得だけでなく、閲覧データの書き込みも同じエンドポイントで行っています。APIは受け取ったユーザーIDと物件IDをキューに格納し、キューにあるデータは定期的にDBに書き込まれます。こうすることで、DBへの書き込み負荷を軽減しつつ、かつ大きなタイムラグを発生させずに集計結果を返せます。 開発していて意識したポイント この施策がバックログに留まっていた原因である、開発工数がかかるという懸念について、以下3点を意識しながら削減に取り組み、結果的に企画職（プランナー）に短期間で実装できる可能性を提示することができました。 積極的にマネージドサービスを使う 今回はCloud Run、Datastoreを利用し、基本的にはアプリケーションの実装のみに注力しました。Cloud Runではデプロイ、スケールアウトなどさまざまな処理を行ってくれます。また、Datastoreではエンティティの有効期限を設定し、古くなったデータを自動的に削除されるようにしました。こうすることで、エンティティを削除する処理を作ることなく、ストレージの費用も削減できます。 できるだけ過去の実装を再利用する 以前、物件の詳細ページにレコメンド機能を導入した際、類似のアーキテクチャを採用しました。その時もDatastoreを活用していたため、DBクライアントやWebフレームワークなどの基本構成をほぼそのまま使用しました。 拡張性を意識した設計 今後新たな機能を追加することも考え、アプリケーションはクリーンアーキテクチャを意識した設計にしました。検証の結果がプラスに終わり今後も提供を続けていくとなると、ある程度の拡張性は持たせておきたいと思ったためです。また、閲覧数で集計したり、別のアクション (お気に入り追加など) でも利用できるような設計にすることで、今後の改修の実装工数を下げることを意識しました。 終わりに 今回は、物件の詳細ページの閲覧ユーザー数を集計、取得するシステムの構築について紹介しました。現在検証中ですが、CVRは良好となっています。エンジニアとして実現可能性を提示し、施策化、リリースまで行う良い経験になりました。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。 プロダクトエンジニアリング部の辰巳です。 私はLIFULL HOME'Sの賃貸領域のエンジニアリーダーとして、LIFULLのベトナム海外拠点であるLIFULL Tech Vietnam(以下LFTV)のメンバーとともに開発を行っています。 海外の方と仕事をしてみたいけど不安がある、そのような方に向けてLIFULLでの海外拠点メンバーとの仕事の取り組みを現場目線でお伝えします。 LFTVと2017年から開発をともにしてきた私から見たLIFULLグローバル開発チームとの働きやすさについて紹介します。 LIFULLとグローバル開発 私は2015年にLIFULL(当時の社名はネクスト)に入社しました。 入社3年目の2017年にLFTVのメンバーと業務をともにしました。 当時のLIFULLはLFTVの母体となる企業の子会社化を行った直後で、海外子会社とオフショア開発を行うにあたっても社内に知見が少ない時期でした。 -6年前- 初めての"オフショア請負開発" 6年前、2017年当時はグローバル開発に不慣れで手探り状態でした。 当時、LIFULL HOME'Sの不動産会社情報を掲載するページを運用するチームで、LFTVとの開発を私に任せてもらいました。 LIFULLとしてはLFTVと連携した開発がまだ3件目の開発案件で暗中模索の色が強かったです。 LFTVとしてもLIFULL以外のオフショア案件が多く、LIFULLの案件を受けるのは社内でも小規模なチームでした。 当時は以下のようなチーム体制でした。 LIFULLの正社員エンジニアのリーダー（私） ブリッジエンジニアLFTVの通訳兼リーダーのエンジニア（以下ブリッジエンジニア） LFTVの開発メンバー2名 私が開発指示を出し、LFTVとしては開発した成果物を納品するいわゆる「オフショア請負開発」として稼働していたのが当時です。 外注開発の色が強く、チームは業務の指示側と受け側できれいに別れており、開発責任とテストはLIFULLが負う形でした。 権限の影響で開発環境がLIFULLとLFTVで別れており、不具合があっても何が原因か分からず開発が止まるといった事態も多かったです。 品質面でもLIFULL HOME'Sへの知見がなかったために開発品質が低く、レビュー回数が多くなったりする事は日常茶飯事でした。 そのため現在と比べてLFTVとの連携がうまく回っていなかったのが2017年当時の内情でした。 -海外拠点との働き方改善- 2024年現在は整備が進み、「オフショア請負開発」の色は抜けました。 LFTVの設立の目的はLIFULLグループで優秀なエンジニアリソースの確保にあります。 彼らがより能力を発揮でき、LIFULLとチームで開発を行えるようにさまざまな改善活動が行われました。 オフショアという言葉を使わず１チームであることを意識づける 海外拠点メンバーの権限の拡張 開発ドキュメントの整備 LIFULL HOME'Sサービスの勉強資料の準備 言語の壁を越えるようにLIFULL側も英語などで積極的にコミュニケーションを行う 定期的なアンケートで働きやすい環境をヒアリングする 他にもありますが代表的なものは上記に挙げた通りです。 私もLFTVと一緒に業務を行い始めた最初期から関わっていたので、ドキュメント整備や業務フローの改善を行ってきました。 このような活動を行い、社内に海外拠点との開発機会が増え、知見がたまることでさらに改善につながります。 良いスパイラルが生まれて、現在では当たり前のように海外拠点メンバーとチームを組んで業務を行うようになりました。 開発品質の向上 現在はLFTV内の品質管理チームがサポートしてくれるようになったりと開発品質も大幅に向上しています。 現場に近いところだと、LIFULLの正社員に近い権限をLFTVメンバーが持っているため開発環境の差がなくなりました。 連携当時はLFTVのセキュリティレベルが低く、日本の法律やLIFULLのレベルと合わせるのに時間がかかったため開発環境に差がある状態でした。 当時の例を挙げると、LIFULL HOME'Sの開発環境がインフラごと分かれており、LFTVでは日本の環境をクローンした環境で開発を行っていました。 DBから別の環境であるため、LIFULLでほかのチームがDBやインフラリソースに変更を加えた場合、そこに差分が出てしまいアプリケーション開発ができないなど頻繁に発生していました。 他にもサービスアカウントが分かれているためLIFULLの機密性の薄いドキュメントすら参照できないのでコピーしてメールで送付したりと業務進行に影響が出ていました。 これらがなかなか解決できずにモヤモヤしながら業務をしており、海外拠点との業務は今後大丈夫なのか？と考えていたのを覚えています。 ただ、これも克服してLFTVでは日本の正社員と同じように業務を行える環境が整いました。 現在の私のチームでもLFTVメンバーが活躍しており、開発スピードがLIFULLのエンジニアに迫る勢いで施策のリリースが行えています。 2017年当時からは信じられないほど海外拠点と働きやすくなっています。 ワンチームでの開発 LIFULLの開発メンバーとLFTVの開発メンバーの権限差分が払拭されたり、開発にあたってLIFULL流の知見がたまっていったりと、１つのチームで開発する色が強くなっています。 LIFULLとしてもグローバル開発では各国の拠点を跨いで1つのチームを編成したり、必ずしもLIFULLのメンバーがリーダーを担うとは限らないといった、各国メンバーが同じ立場でのチームを想定しています。 もっと目の前、現場を見るとLFTVとLIFULLのメンバーで意識が変わりました。 請負開発ではなく１つのチームであるという意識が強まりました。 積極的に開発要件に質問をしてくれたり、LIFULL側の指示に不備がある場合は訂正をしてくれたりと意識が変わってきています。 たとえば私とプランナーが見逃した仕様の不備をLFTVで実装初期に発見し、ドキュメントにまとめて共有してもらえたことで仕様漏れが回避できたこともあります。 このように海外拠点のメンバーとの業務が日本のメンバーと遜色なく行えるようになったと感じています。 さらに現在ではマレーシアのLIFULL Tech Malaysia(LFTM)も仲間に加わり、チームの国際色がどんどん豊かになっています。 LFTVとLFTMとの開発機会が増え、今後さらにLIFULL内で国際色が豊かになっていくと思います。 彼らの開発手法やマインドは日本人とは違う部分もあります。 そういった点をLIFULLのエンジニアも吸収して、エンジニアとしてお互いに切磋琢磨できる環境となってほしいと思います。 最後に LIFULL・LFTV・LFTMではそれぞれ一緒に働いてくれるメンバーを募集しています。 日本にいながら海外の方と仕事ができる貴重な環境でもあります、興味のある方はぜひカジュアル面談のページをご覧ください。 https://hrmos.co/pages/LIFULL/jobs/010 https://hrmos.co/pages/LIFULL/jobs/010-9998 https://lifull-tech.vn/careers/

こんにちは、プロダクトエンジニアリング部の山﨑です。 私は LIFULL HOME'S 賃貸マーケットのプロダクト開発を行うグループに属しており、その中でも技術負債解消に取り組むエンジニアリングチームのリーダーをしています。 本記事では、LIFULL HOME'S の賃貸マーケットにおける技術負債の現状と、本チームの具体的な取り組み内容を紹介します。 LIFULL HOME'S の技術負債解消への取り組みを知っていただくことで、LIFULL HOME'S でのエンジニアリングに興味を持っていただけたら幸いです。 LIFULL HOME'S の賃貸マーケットにおける技術負債の現状 さっそくですが、現状、賃貸マーケットの基盤刷新後のアプリケーションは 刷新前のアプリケーションへリクエストを送ることで一部機能の実行を担保している という課題があります。 以前別の記事でも紹介させていただいた通り、賃貸マーケットでは現在アプリケーション基盤の刷新を行っており、物件詳細ページなどページ単位で機能の移植を進めていました。 www.lifull.blog 着々と機能移植が進んでいった一方で、移植することが工数的に難しい機能もあり、そういった機能は苦渋の決断で刷新前のアプリケーションへリクエストを送り実行を担保しているということです。 技術負債解消に取り組む理由 このような状況において、技術負債解消に取り組む主な理由としては、技術負債をそのままにしておくと以下のような問題が発生し続けるためです。 刷新前後のアプリケーション間で不要なリクエストが走ってしまうことで、無駄なリソースを消費してしまっている 移植されていない機能は刷新前のアプリケーションを開発して、移植済みの機能は刷新後のアプリケーションを開発するという複雑な開発体制が続いている 一部使われている機能があることで、刷新前のコードを削除しにくい これらの問題は放置し続けられるものではないため、技術負債の解消を優先度高く取り組んでいく必要があるという状況です。 技術負債解消の具体的な取り組みについて 「移植することが工数的に難しかった機能」について実際に私たちのチームで機能の移植を進めました。 今回は、いくつかの機能を移植した中でも特に ユーザーの行動ログを送信する機能 と ユーザーが最後に検索した条件を保存する機能 について、移植のポイントや取り組み内容について紹介していきます。 ユーザーの行動ログを送信する機能 1つ目に移行した機能は、ユーザーの行動ログを送信する機能です。 LIFULL HOME'S ではより良いサービスを提供するために、いくつかのタイミングでユーザーの行動ログを収集しています。 イメージとしては、ユーザーが物件詳細ページを閲覧した際にその物件の情報などいくつかの情報を送信します。 送信された情報はバケットにたまっていき、その後定期的に分析レポートを作成するためのバッチで利用されるといった形ですね。 できあがったレポートは掲載されている物件の状況把握のために活用されていたりと重要な役割を持っています。 この機能を移植するにあたってのポイント この機能に関しては約 10 年前に開発されて以降はあまり手を加えられていない状態だったので社内の知見者もほぼおらず、ドキュメントも存在していない、まずソースコードがどこで管理されているのかすらわからないという状況からのスタートでした。 そのため、まずはインスタンスで動いているコードを確認してソースコードの管理されている場所を突き止めた後、コードからしくみを把握していく。さっと全体感を理解したうえで、どこをどういった手順で移植していくかを検討していくところから動き始めました。 モブプロでのコードリーディング 全体感を理解していく初回の調査で、コードリーディングの場面に限ってはモブプロで作業を行いました。 「ここはこういった処理をしているね」「ここの処理は不要そう」「本質から逸れているからここの部分は飛ばそう」など認識のレベルを適宜擦り合わせつつ、各々の視点でこの調査が本質から逸れていないかなど視野を広げながら進めていったことで、滞りなくかつその後も前提知識がある程度そろった状態で話を進めることができたというのは一つの良い知見になりました。 コードリーディングをモブプロで行ったことはなかったのですが、置いてけぼりになる人が出てこず、しっかりと議論をしながら進められました。今後も認識をそろえながら進めたい場面では、状況をみて活用していこうと思えた進め方でした。 調査後に判明した機能の構成 さて、一通り調査をして判明した機能の構成は以下図の通りでした。 システムの全体構成 この機能は主にユーザーの行動ログを処理（バリデーションやネストしたデータをフラットにする整形）するための Fluentd と収集したデータを元にバッチ処理を行う EMR から構成されていました。 ですので、アプリケーション側から移行作業としてやることはシンプルで必要なデータを Fluentd に送信するという処理があれば良いということが分かりました。 やること自体はシンプルなのですが、実際にいざ作業を始めてみると開発の活発だったころからは月日が経ってしまっていて、すでに使われていないであろうデータも送信されている状況でした。 不要な値は削除してしまおうということで、まずは不要であることを確認する調査から始めるのですが、不要なデータを削除するということは、どのデータがどのような処理を経ているのかを理解する必要があります。 そのためには、Fluentd のファイルや EMR のジョブのファイルなど複数のシステム跨いでデータの流れを読み解く必要がありました。 このように不要であることの証明は工数のかかることが多いので、ある程度調査はしつつ残りはテストで担保するか、ほかの部署に確認を行ったりしながらなるべく工数をかけすぎないように削除を進めていきました。 結局、多くの不要データを削除することはできたものの、すべての（不要そうな）データを削除することはやはり難しかったです。 ただ、移植するだけではなくリファクタリングも行うという意識は、このプロジェクトを進めるうえで良い意識だったと思っています。 テストのやり方 テストに関しては、新旧のアプリケーションで同じデータを送信して、Fluentd が吐き出したそれぞれのデータを比較するという方法を取りました。 システムの構成としては Fluentd の送信したデータを元に EMR がバッチ処理を行います。 つまり、Fluentd が吐き出すデータ（= EMR にインプットされるデータ）を移植前後で変わっていないかを比較すると最終的なアウトプットの差分もないということで、この方法を取っています。 テスト構成 テストの構成イメージとしては上記のような形です。 基本的には Fluentd のタグでデータを区別して送信しているので、該当するタグの場合は比較用のバケットへデータを送信する様にしている形です。 なお、テスト用バケットにたまった新旧データを比較するためには、新しいアプリケーションからのデータと同タイミングで作成された旧アプリケーションのデータを紐付ける何かが必要です。 紐づけるものがないと比較すること自体ができないので、紐付けをどうするかということはテストの重要なポイントとなります。 今回のテストではリクエストヘッダに載っている TraceId という値を使って紐付けを行いました。この値は LIFULL の共通実行基盤である KEEL 上で動いているアプリケーションが利用できる値で、アプリケーションを跨ぐ一つのリクエストを紐づけるための値として使われています。 www.lifull.blog www.lifull.blog この値をデータに含ませておくことで同一リクエストのデータを比較できるので、テストスクリプト実行時はこの値を見て新旧データを比較することを実現しています。 ユーザーが最後に検索した条件を保存する機能 二つ目に移行した機能は、ユーザーが最後に検索した条件を保存するという機能です。 機能自体はシンプルで、特定のタイミングでユーザーが検索した条件を memcached に保存しておくというものでした。 この機能を移植するにあたってのポイント 今回保存する検索条件は様々なアプリケーションで活用される値なので、基本的に書き込みおよび読み込みの処理は共通の API から行っています。 しかし、この共通の API （以降 V1 API）というのがすでに開発が終了したもので、新規利用が非推奨となっているため刷新後のアプリケーションからは新共通 API （以降 V2 API）を利用する必要がありました。 ただし、V2 API には memcached に対して検索条件保存のためのエンドポイントが存在していないので新たに作成する必要があります。 ここが一つのポイントで、問題は V1 API と V2 API で利用している言語が異なるということです。V1 API は PHP で動いているのに対して V2 API は Ruby で動いていました。 それに加えて、利用している memcached のクライアントライブラリのデータのシリアライズと圧縮のアルゴリズムが異なっており、この部分の整合性を取るのが難しいという問題がありました。 保存するだけであれば問題ではないのですが、保存したものはもちろん取得がされます。 全ての取得したい箇所で V2 API を通して取得される様に統一されているのであればまだ問題にはなりません。V1 API 側に手を入れる必要がありませんからね。 しかし、現状はまだ V1 API から取得している箇所もあるというのと V1 API を通して取得している箇所を特定するのにそのしくみ上工数がかかるため、コストパフォーマンスを鑑みても全ての取得箇所を V2 API に置き換えるのは厳しそうでした。 そのため、V1 API から取得されても V2 API で保存されたものをデシリアライズと解凍出来る様にする必要があるということがこの機能を移植するにあたってのポイントとなっています。 データの圧縮と解凍をどうするか まずは、なるべく開発を終了している V1 API 側に手を加えることはしたくなかったため、V2 API 側の保存の仕方を調整する形で実装が完結出来ないかと調査を始めることにしました。 V1 API 側では PHP の pecl-memcache ライブラリを利用しており、このライブラリは内部的に zlib の uncompress 関数を使って解凍したあと php_var_unselialize することで検索条件を取得していることがわかりました。 V2 API ではそのまま解凍出来る様にデータ圧縮を行いたかったので、Ruby に組み込まれている Zlib クラスの実装やいくつかの gem のコードを読み漁っていたのですが... 結局 V2 API 側だけでは調整できず、調査ばかりに時間もかけてはいられない状況であったので泣く泣く V1 API 側でも問題なく解凍出来る様に手を加えることで落ち着きました。 リリースに向けて 今回は書き込み機能であり、全社の様々なアプリケーションで活用される値ということで影響範囲も広いため、リリースまでにいくつかのリスクヘッジをしました。 一つは、V2 API を通してデータが保存されるユーザーの割合を徐々に増やすという方法です。 初回は 10 %、3 日ほど経って問題なければ 30 %といった感じですね。 もう一つは memcached に保存するデータの TTL を短くしておくという方法です。 これも万が一問題が起きた時に、ユーザーへの影響を最小限にするために極端に短くしていました。 次のステップ・展望 今回私のチームでは 3 つの機能移植を行うことで刷新前アプリケーションへの依存を取り除くことに注力しました。 加えて、今回の機能移植はデリバリに寄せて進めたところもあり、ベストな選択肢が取れなかった箇所も大いにあるのは心残りな部分でした。 やはり一度に大きな変更（たとえば今回みたいに大きな機能の移植をまとめて行うなど）を行うことはリスクが高かったりさまざまな制約から思う通りに進められないことが多かったです。 今後はメインのミッションを進めつつも、周辺のエンジニアを巻き込んで小さな技術負債解消を積み重ねていく取り組みを行っていきたいと考えています。 終わりに ここまで LIFULL HOME'S の賃貸マーケットにおける技術負債解消チームの取り組み内容について紹介してきました。 LIFULL HOME'S のような長年稼働しているサービスでは技術負債が蓄積されがちです。だからこそ負債を解消したときのインパクトがあるし、解消するためには多くの知識やスキルを発揮できる環境だと思っています。 このように、LIFULL ではユーザーを始め社内の開発者など多様なステークホルダーの体験を考えたものづくりを行い、ともに成長していける仲間を募集しています。 興味を持っていただけた方は、ぜひ以下のページもご覧ください。 hrmos.co hrmos.co

こんにちは。 LIFULL Tech Vietnam （以下、LFTV）CEOの加藤です。 2016年よりLIFULLへ中途入社し、主にLIFULL HOME'S 注文住宅領域のエンジニアチームのマネジメントを経験したのち、2023年10月よりLFTVのCEOへ就任致しました。 就任し約半年が経過しましたが、今回はこれからのLFTVが目指す未来について紹介したいと思います。 LFTVについて まずLFTVについてですが、ベトナムホーチミンに拠点を構えるLIFULLグループの機能子会社です。 主にアプリケーション開発業務を担い、LFTVで担う業務の大部分をLIFULL HOME'Sのプロダクト開発が占めています。 従業員は2024年3月時点にて全社で約90名程度在籍しています。 2017年に設立し、これまで右肩上がりで規模を拡大してきましたが、次なる成長を見据え私が就任した今期よりLFTVの第二フェーズと位置付け、新たな戦略のもと走り始めることとなりました。 オフショア開発からグローバル開発へ これまでもLFTVはLIFULL HOME'Sを中心とするLIFULL本社のプロダクト開発を多く担ってきましたが、その関係はいわゆる「オフショア開発」としての関わりでした。 単純に海外で開発することをオフショア開発と呼ぶこともありますが、ここではソフトウェアやシステム開発を海外企業へ「委託」することとして表現します。 受託開発としての関わりのもと、LIFULL本社をクライアントとして認識し、開発してできた成果物をリリースすることを納品として表現していました。 また、役割も分断されていることが多く、日本側で設計までの上流工程を担い、下流工程をベトナム側が担うという体制が主流でした。 こうしたオフショア開発としての体制のもと順調に規模を拡大してきましたが、新たなビジョンを掲げ転換期を迎えることとなりました。 LFTV設立の目的 新たなビジョンの話の前にLFTV設立の目的についてお話したいと思います。 LFTV設立の大目的は「中長期的な事業成長のためのLIFULLグループ全体の開発リソース確保であり、"優秀な人材を確保・増員し、生産性を上げながらコスト削減を実現する"こと」です。 つまりは単にコスト削減のため低単価な海外へ開発業務を外注するのではなく、LIFULLグループの一員として優秀なベトナム国内の人材を確保し、さらなる事業成長につなげることが目的となります。 この目的はLFTV設立以降一貫して変わっておらず、サービス規模が拡大する一方、日本国内のIT人材不足は今後も続く見込みであることから、ベトナム国内の優秀な人材をLIFULLグループの一員として迎えることの重要性はますます高まっています。 IT人材需給に関する主な試算結果 引用元： 経済産業省 IT人材需給に関する調査 グローバル開発の実現 2023年3月には第二の海外開発拠点である LIFULL Tech Malaysia （以下、LFTM）が設立し、LIFULLグループ全体として海外との協力開発の推進がさらに加速することとなります。 このような背景と目的のもと、LIFULLグループ全体として新たに「グローバル開発構想」が掲げられました。 このグローバル開発構想の大きなポイントの一つは日本・ベトナム・マレーシアの各開発拠点間の垣根をなくすことにあります。 今までLIFULL本社とLFTVはシステム開発の委託先として関係性を築いてきましたが、これからは「同じチームの一員」として新たな関係性を築くことを目指していきます。 また、携わる領域や役割においてもLIFULL本社とLFTVとで切り分けがされ、チームもそれぞれ分断されているケースが多く存在していましたが、今後は所属に捉われない体制構築も目指していきます。 これはたとえば、各国跨いで1つのチームを構成することや、必ずしもLIFULL本社のメンバーがリーダーや上流工程を担うとは限らないといったことなどを想定し、各開発拠点のメンバーそれぞれの特性を活かした役割やチーム編成を行うことをイメージしています。 このようなLIFULLグループ全体のビジョンを実現すべく、LFTVとしても新たな戦略を打ち立て走り出すこととなります。 LFTVエンジニアのあり方 ビジョンを実現する上で、「どのようにあるべきか」を明確にすることはとても重要です。 そこで私はLFTVエンジニアの「あり方」として以下のように定義しました。 一人一人がLIFULLグループのプロダクトチームの一員として、プロダクト開発にコミットしている。 ここで重要なポイントは「プロダクトチームの一員」であるという点です。 LIFULLは2021年よりプロダクト開発の方針としてプロダクトマネジメントを導入しました。 corp.lifull.com プロダクトマネジメントの大枠としては、プロダクトマネージャー、テックリード、プロダクトデザイナーを中心として構成されるプロダクトチームが、それぞれの専門性を活かし三位一体で連携し、ビジョン実現や成果の創出といったアウトカムを重視しプロダクト開発を行うといったものです。 グローバル開発というビジョンを実現するためには、このプロダクトマネジメントの考えに基づき、プロダクトチームの一員としての振る舞いが重要であると考えます。 そこでさらに深掘りをし、このプロダクトチームの一員としての振る舞いを実現するために必要な意識を「目的」「チーム」「エンジニア」の3つの観点より定義しました。 目的に対する意識：「アウトプット志向」から「アウトカム志向」へ LIFULLでプロダクトマネジメントを導入するにあたって参考とした書籍「 INSPIRED 」および「 EMPOWERED 」では次のように言われています。 有名なベンチャーキャピタリストのジョン・ドーアは、次のように好んで説明している。「私たちが求めているのは伝道師のチームだ。傭兵のチームではない」 ここでいう伝道師のチームが目指すべきプロダクトチームを指します。 伝道師のチームではプロダクトビジョン、原則、戦略が共有され、チーム全員がプロダクトに対して深い理解を持ち、ビジョン実現に向けて情熱を持って取り組むことが求められます。 また、伝道師のチーム（= プロダクトチーム）となるためには従来の機能開発チームから脱却することが必要であると表現されています。 機能開発チーム：従来型組織で、個々のチームのアウトプット重視で動いているようなチーム プロダクトチーム：一流テクノロジー企業にあるようなアウトカム重視のチーム 今までのプロダクト開発においては、決められた機能を仕様通り正しく期日を守って開発することに最もフォーカスして取り組んできました。 この先目指すべきプロダクトチームの一員となるためには、これらの目的をしっかり遂行することに加え、その先にあるアウトカムにも意識を向けることが求められます。 つまりは、事業の推進やプロダクトビジョンの実現を見据え、与えられたミッションを達成するためにプロダクト開発を行う意識がこれからは重要となるのです。 チームとしての意識：オフショアからの脱却 これからはLFTVエンジニアがLIFULL本社や日本人エンジニアと区別された「オフショアメンバー」ではなく、同じプロダクトチームの一員であるという意識が重要となります。 このような意識を醸成すべく、LIFULLグループ全体として「オフショア」という言葉を使わないことを決めました。 オフショアという言葉には、前述の通り業務の委託先という関係性を想起させるニュアンスを持つことがあります。 このような言葉の持つイメージがお互いの関係性を作り上げ、目指すべきチームの形を作り上げる上での障壁となると考えました。 また、国内では現在、東京本社のほかに札幌と福岡に開発拠点が存在します。 札幌、福岡の開発拠点に所属するエンジニアメンバーも本社エンジニアとともにプロダクト開発を行っていますが、それぞれが同じプロダクトチームの一員であるということに誰も違和感を覚えるメンバーは存在しません。 これはプロダクトチームの形成において、物理的な距離や所属先の拠点ではなく、お互いの意識や関わり方が重要であるということを表していると思います。 これらより、LFTVも「オフショア先」ではなく、札幌、福岡と同様に海外に拠点を置く「開発拠点」として捉え、チームメンバー双方の意識も同じプロダクトを開発する同志として変えていくこととなります。 エンジニアとしての意識：サービスを実現するエンジニアへ これから目指すLFTVのエンジニア像として以下のように定義しました。 テクノロジーを駆使してプロダクトやサービスを実現するエンジニアとなる。 システムを開発するという手段を目的としてとらえるのではなく、「目指すべきサービスを実現するという目的を達成するためにテクノロジーという手段を用いる」という思いがこのエンジニア像には込められています。 このような意識を持つことで、エンジニアとしての役割や活躍の場は今まで以上に広がります。 例を挙げると、以下のような場面でもその役割を担うことが考えられます。 アイデアに対し開発実現性の判断を行う アイデアを実現するための最適な手段を検討する システム的なリスクや懸念事項への判断、対処を行う このようにシステムの実開発を行うというのはエンジニアの役割の一部であり、プロダクト開発の活動全体に活躍の場があることが分かると思います。 大事なことはプロダクトチームの一員としてエンジニアリングという専門性を活かし、プロダクトの成長やサービスの実現を果たすという意識であると考えます。 「あり方」を実現する「なり方」 ここまでグローバル開発というビジョンを実現する上でのLFTVエンジニアの「あり方」について紹介してきましたが、最後にその「なり方」について紹介します。 あり方を実現する要素を分解して考えた際、大きく4つの取り組みが重要であることにたどり着きました。 LFTVエンジニアのあり方実現のための全体像 本社・開発拠点間の連携強化 グローバル開発を実現する上で「意識」と「言語」の壁を超えることは重要な要素であると考えます。 そのため、まずはこの2つの壁を超えることを中心に本社および開発拠点間の連携強化を図ります。 意識の壁 意識の壁を超えるための手段としては主に2つのアプローチにて実行しています。 ビジョンシェアリングなどを通じたトップダウンでの発信 各国の文化やイベント、知識などの情報発信 1つ目のトップダウンでの発信は、私自らがCEOの言葉として目指すべきビジョンや思いなどを継続して伝え続けることで、社員全員が同じ方向へ意識を向けることを期待しています。 2つ目の情報発信では、各国の情報に触れる機会を増やすことでお互いを理解し、身近な存在へと近付けることで垣根をなくすことを狙いとしています。 言語の壁 異なる母国語を持つメンバーで仕事を行う場合、言語の問題は避けては通れない課題かと思います。 我々も日本語、ベトナム語、英語を母国語とするメンバーで協業し、プロダクト開発を行うことを目指しているため、この課題に向き合い解決することはとても大きな意味を持ちます。 この言語の壁を超えるべく、チームの状況に合わせ英語でのトライアルやツールの活用など試行錯誤しながら取り組んでいます。 具体的な取り組みについては以下の記事で詳しく紹介しているため、ぜひご覧ください。 www.lifull.blog エンジニア育成強化 従来の関わり方とこれから目指すべき関わり方を比較した際、LFTVエンジニアが担う領域やエンジニアとして求められる振る舞いが拡大することとなります。 例に挙げると今までアプリケーションの機能実装が主な役割であったものが、インフラやデータストア、セキュリティなど担当する技術領域の幅が広がります。 また、開発工程だけでなくプロダクト開発における活動全体において、専門性を発揮しながらほかのメンバーと密に連携することが求められるのです。 これらの要求に対処し、理想的なエンジニアとしてのあり方を実現するためには個々のエンジニアスキルを向上させることは必要不可欠です。 これらを実行するにあたり、まずはLFTVエンジニアとして身につけるべきスキルの方向性をLIFULLグループ全体と統一させるところから始めました。 方向性をそろえ、そこに向けて技術レベルを上げていくことで、LIFULLグループのプロダクト開発に必要な技術力を身につけたエンジニアへと成長することを目指しています。 ミドル層強化 エンジニア育成を行う上で、その体制を構築することも重要な要素のひとつかと思います。 その際、鍵となるのは優秀なミドルマネージャーの存在であると考えます。 今後エンジニア育成をより拡大していくためには、そのドライバーとなるミドルマネジメントが大きな役割を担います。 この考えに基づき、マネジメント教育を強化し、マネジメント力の向上と次世代のミドルマネージャーの創出を目指しています。 制度・環境整備 これらの取り組みを実行するためには仕組み化がとても重要です。 その中でも会社全体としてみた際、社内の制度や環境が戦略と整合し噛み合っている状態がとても重要であると考えます。 この考えに基づき、必要に応じて戦略に合わせた制度の見直しや環境の整備を継続的に実施します。 以下で紹介するのはこれらに関する取り組みの一部です。 組織構造の明確化 現在のLFTVでは組織構造を細部まで示し社内へ公開しているものがなく、社員による認識もあいまいなものとなっていました。 前述した通り、エンジニア育成を行う上では体制が重要となります。 そのため、あらためて組織構造を明確化し組織図に表すことで、所属する組織や組織の階層、上司・部下、組織やポジションによる役割等を明確に表現することとしました。 組織文化の醸成 本社・開発拠点を跨ぐプロダクトチームとして働くためには、同じ価値観を共有し、同じ行動規範によって判断することが重要であると考えます。 LIFULLグループでは社是の「利他主義」や経営理念を始めとし、日々の行動規範を定めたガイドラインなど共通して持つべき価値観が定められています。 これらの重要性をあらためて説き、組織の文化として定着させることがこれからのLFTVにはますます必要となると考えます。 最後に ここまでLFTVの目指す未来について紹介させていただきましたが、LIFULL、LFTV、LFTMでは一緒に働く仲間を募集しています。 LFTVでは日本とは異なる文化や価値観に触れ、日々刺激を受けながら成長する機会に溢れています。 海外のメンバーと直接連携しプロダクト開発に携わることで、コミュニケーションの取り方や考え方の違いなど多くの面で新たな発見が得られると思います。 また、ベトナムならではの社内イベントも多数開催しているため、ベトナム文化の中で働きたいと考える方にとっても魅力的に感じていただけると思います。 そして、グローバル開発を推進する中で、国や所属する開発拠点にとらわれない関わり方を目指し、幅広い領域や役割を担う機会を生み出していきます。 幅広い経験が得られる機会の中から、一人一人に合ったキャリアパスを実現するための支援も行なっていきます。 今回紹介したグローバル開発に共感いただき、同じ志のもと挑戦したいと感じて下さった方がいらっしゃいましたらぜひともご応募お待ちしています！ hrmos.co hrmos.co lifull-tech.vn lifull-tech.my

エンジニアの市川と申します。 LIFULL HOME'S の売買領域の開発を担当しています。 さて、さっそくではありますが、読者の皆さんは普段ABテストを実施しているでしょうか。 私たちの開発しているLIFULL HOME'Sでも、日々多くのABテストが実施されています。 ABテストの実施によって市場学習回数を増やし、より良いプロダクトを作り上げることが目的です。 その中で私たちエンジニアが貢献できる点といえば、市場学習のスピードを上げることです。 LIFULL HOME'Sでは長年ABテストを実施してきていますが、いくつかの問題がありました。 今回はその問題と、どのように解決に向けて動いたのかという点について紹介します。 ※LIFULL HOME'SでのABテストにつきましては、以下のリンクをご参照ください。 A/Bテストは事前準備で決まる！？LIFULLのA/Bテスト事前設計の取り組み｜LIFULL Product Growth ABテストにまつわる問題 ABテストを実施する1サイクルの期間が長い 各マイクロサービスを開発する度にABのテストの仕組みが必要になる 解決のための取り組み 共通のABテスト基盤の開発 設定情報の独立化 まとめ ABテストにまつわる問題 ABテストを実施する1サイクルの期間が長い まず、1点目の問題としては、ABテストを1回実施するまでの期間が長いことでした。 LIFULL HOME'Sのプロダクトには、独自のABテストの仕組みが実装されています。 そのABテストの仕組みを使うと下記のような手順と、期間がかかります。 gantt axisFormat %m/%d title 従来のABテスト section ABテスト実装 ABテストの設定情報を設定ファイルに追記 :active, des1, 01/01,1d 各パターンの挙動を実装 :active, des2, after des1, 3d テスト :active, des3, after des2, 1d リリース :active, des4, after des3, 1d 計測期間 :active, des5, after des4, 7d section Bパターン100%適用対応 設定ファイルに記載されている比率を修正 :crit, des6, after des5,1d テスト :crit, des7, after des6, 1d リリース :crit, des8, after des7, 1d Aパターン50%, Bパターン50%で設定し、計測期間が1週間という短めの例です。 ABテストを実装し、Bパターンに有意差ありと判断した場合は、なるべく早くBパターンを100%にしたいです。 しかし、設定ファイルの比率を書き換えるだけでもプロダクトコードのリリースが発生するため、最短でも翌日のリリースとなってしまいます。 1日とはいえ、LIFULL HOME'Sのトラフィックを考えるとなるべく即時反映させたいです。 各マイクロサービスを開発する度にABのテストの仕組みが必要になる 2点目の問題です。 弊社ではLIFULL HOME'Sというプロダクトをメインに開発・運用していますが、このプロダクトはいくつかのマイクロサービスに分かれています。 そして、各サービスにABテストの仕組みが実装されています。 例： LIFULL HOME'S 賃貸基盤刷新におけるABテスト実施システムの構築 - LIFULL Creators Blog graph TD A("ABテスト") B("ABテスト") C("※ABテスト") D("ABテスト") L --- S L --- R L --- M subgraph L["LIFULL HOME'S"] A end subgraph R["賃貸"] B end subgraph S["売買"] C end subgraph M["マイページ"] D end 今後もプロダクトの成長に伴い、新たにマイクロサービスが生まれる可能性はあります。 その度にABテストの仕組みを実装していてはコストが高いです。 現に売買領域のアーキテクチャリプレイスのプロジェクトでは、新しくマイクロサービス化されたアプリケーションが存在しますが、初期段階ではABテストの仕組みを実装していませんでした。 www.lifull.blog ※突貫的に外部サービスを利用し、画面の表示要素を差し替えてABテストを行っていた時期もありましたが、開発体験の良いものではありませんでした。 解決のための取り組み 共通のABテスト基盤の開発 前述した問題を解消するために、各マイクロサービス共通で利用できるpackageを開発しました。 弊社で基盤刷新を目的としたマイクロサービスのアプリケーションは、Node.jsを利用するよう統一化が図られています。 従って、npm packageとしてABテストの仕組みを提供すれば各アプリケーションで利用可能になります。 graph TD 売買-->ABテスト 賃貸-.->ABテスト マイページ-.->ABテスト 現在は売買のアプリケーションでのみ利用している状況ですが、ゆくゆくは統一していきたいと考えています。 設定情報の独立化 また、ABテストの設定情報に関しては、従来のアプリケーション内のファイルに追加する方法ではなく、独立したリポジトリで管理するようにしました。 graph TD A(ABテスト package) -->|read| S[(S3)] R[GitHub ab setting repository] -->|upload| S R -->|PR merge| R ABテストの設定情報を管理するためのGitHub repositoryを用意し、PRをマージするとその設定情報がS3にアップロードされるような仕組みです。 S3にアップロードされると、その設定情報がアプリケーション側に即時適用されます。 このように独立化させることで、本プロダクトへの影響を気にすることなくレビューや承認が行えるほか、プロダクト側のリリースフローに乗せる必要がなくなります。 結果的に、Bパターン採用の意思決定をしてから早ければ数分で100%適用を実現できます。 gantt axisFormat %m/%d title 現在のABテスト section ABテスト実装 ABテストの設定情報を設定ファイルに追記 :active, des1, 01/01,1d 各パターンの挙動を実装 :active, des2, after des1, 3d テスト :active, des3, after des2, 1d リリース :active, des4, after des3, 1d 計測期間 :active, des5, after des4, 7d section Bパターン100%適用対応 設定ファイルに記載されている比率を修正 :crit, des6, after des5,1d まとめ 今回は共通のABテストの仕組みについて紹介しました。 この共通のABテスト基盤を通して、開発プロセスの効率化を図り、よりすばやく市場のニーズに応えるプロダクトを提供できるようになりました。 まだ導入フェーズですので、作ったものを最大限生かせるように働きかけていこうと思います。 ともに良いプロダクト作りをしてくれる仲間を募集しています。 hrmos.co hrmos.co

賃貸領域でフロントエンドエンジニアをしている齋藤です。 今回はここ数年取り組んでいたフロントエンド領域における自動テスト導入とテスト工数削減について、書いていきたいと思います。 なぜ導入したのか、導入して見えた課題、そしてその課題を解決するためにどうしていったのか、という流れで書いていきます。 目次 目次 なぜ導入したのか たびたび障害が発生 開発効率が悪い 自動テストを導入する 自動テストの導入 導入して見えてきたもの ほぼコードを書かない解決策 まとめ お知らせ なぜ導入したのか まず弊社では日々の機能開発は基本的にABテストを実施して効果を検証しながら進めていきます。 そのため、対象となるページが見られたか、対象となる要素が表示されたか・使われたかなどを計測する必要があります。 静的な単一ページであればそれほど問題はありませんが、動的であったり複数のページでそれを行うとなると正しく計測できているかをテストするケースが膨れ上がっていきます。 LIFULL HOME'Sにおいては、物件の検索結果ページがまさにその典型例で、さまざまな切り口で検索でき、またその切り口によって表示されるものが異なります。 意図した切り口で表示されていること、意図しない切り口では表示されないこと、ちゃんと使えるか、計測が正しく行えているかなどをABテストのパターン数×切り口数×テスト項目数でテストする必要があります。 ちなみに切り口は以下のようなものがあります。 マーケット（賃貸・マンション・一戸建て等） エリアの指定方法（都道府県、市区町村、路線・駅等） テーマ（条件を組み合わせたもの） タグ（物件に付けられたタグ） などなど、さまざまな切り口およびその組み合わせで表示できます。 そういった中、弊社で機能開発時にどんなテストをしているかというと、基本的にはスプレッドシート等で作ったテストケースを元に、 デバイス・ブラウザの組み合わせで手動テストを実施しています。 このテスト方法自体はシンプルで、テストを書くのはもちろん、実施するのも誰でもできるという面があります。 一方でテストするページが増えるなどテストケースが増えるとそれだけテスト工数が増えるという一面もあります。 日々機能開発・改修が行われているので、このテスト工数が開発効率に大きな影響を及ぼしてきます。 たびたび障害が発生 上記の通り、切り口の組み合わせで出るものが変わるような複雑なページにさらにABテストが組み合わさるというのは、障害が発生しやすいということでもあります。 当然というとおかしいですが、意図しないページに改修したものが影響していたということが何度も起こりました。 事前調査やコードレビュー等で影響範囲等を見ていても網羅することは難しいのです。 開発効率が悪い 複雑で障害発生しやすいとなると、調査も時間が掛かりますし、テストも手を抜けません。 結果として、物件の検索結果ページに機能追加等改修をかける際には、非常に多くのURLでテストを実施する必要があります。 精神衛生的にもストレスが掛かって良くないですね。 自動テストを導入する ではどうしていくかというと、設計やコード面での複雑性を解消していくというのが一つの方法です。 当然そういう活動も大小行われていますがそれらは一朝一夕では終わりません。 そこで、別の切り口として自動テストを導入し、開発効率を上げていこうということになりました。 自動テストの導入 導入に際しては、まずは開発効率が上がるのかが重要ですので、お手軽にできることから始めることにしました。 実はこれ以前からPuppeteerを使って要素の存在確認やスクリーンショットを撮るなどしていたということがありました。 ですので、使い慣れているということもあってPuppeteerを使った自動テストを行うことにしました。 ※ PuppeteerとはChromeを操作するためのAPIを提供するNode.jsのライブラリです。 導入して見えてきたもの いくつかの機能開発PJで自動テストを書いたのち、それらを共有して導入を進めていきました。 そこで見えてきたのは、テスト実施は効率化されるが、テストを書くということの障壁でした。 PuppeteerはNode.jsのライブラリであるため、普段JavaScriptを書かないエンジニアにとっては障壁があります。 また、テスト項目が増えればそれだけコードも増えるため、テスト作成だけでなくそのコードレビューにも時間が掛かるということもわかりました。 使い捨てに近いテストですので、テストを書くこと自体に対しての障壁があるということは、非常に大きな問題でした。 ほぼコードを書かない解決策 導入して見えてきたものは課題だけではありません。 いくつもの施策でテストを書いてきたことで、何をテストしたいかはおおむね見えてきました。 そこで、テストしたい内容ごとにコードを共通化しました。 ただしそれだけだと共通化したテストコード以外の部分のコードはまだ書かなくてはいけない。 なのでさらに踏み込んで、設定ファイルを読み込んで共通化したテストコードを実行できる様にしました。 const testCase = [ path , status: 200 , specs: [ ... { type : 'hasStyle' , title : 'ダイアログが表示されていないこと' , selector : '.dialog[aria-hidden="true"]' , styleValue : [ 'display' , 'none' ] , } , { type : 'click' , title : `ボタンをクリックする` , selector : 'button[data-target="xxx"]' , } , { type : 'waitForResponses' , title : `レスポンスが返ってくること` , waitForResponses : [ `https:// ${ domain } /result/` , ] , } , { type : 'hasElement' , title : `ダイアログが表示されていること` , selector : '.dialog[aria-hidden="false"]' , expected : true , } , ... ] , ] ; 設定の一例は上記の通りで、テストタイプとセレクタや値などを記載していく様な感じです。 見ての通り、テストしたいことも明確になりましたし、何よりもテストを書くことが楽になりました。 そのほかにもテスト設定をテンプレート化し、headlessモード設定、Cookieの設定、assets読み込みオンオフなどを別に切り出した設定ファイルで管理しています。 サーバレスポンスのHTMLのみでテスト可能な場合には、assets読み込みオフで非常に高速にテストが実行できるなど、テストの実行速度も向上しました。 まとめ 自動テストに取り組み始めてから2年、テストコードの共通化を図ってから約1年が経ちました。 この1年もテストできることを増やしたり、安定して実行できる様にするなど改善を続けてきました。 その結果として、誰でも気軽に自動テストを書ける環境が整い、自動テストを活用した開発がチーム全体に広がったと感じています。 副次効果として、テストだけではなく事前調査での活用にもつながり、非常に効率的な開発が進められるようにもなってきました。 当然、デバイスやブラウザの違いが気になる様な実装に関しては手動テストも行います。 それでもそれらは最低限に抑え、できるものは自動テストで行うというスタンスを今は取っています。 自動テストの活用により以前より安心して開発ができる様になりました。 今後も改善を続けつつ、より安心した開発に向けても取り組んでいきたいと思います。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは、エンジニアの中島です。 この記事は2024年2月〜3月のLIFULL社でのアクセシビリティ改善およびやっていき活動の報告です。 この活動報告は月次で出すかもしれないし出さないかもしれないくらいの温度感で運用されています。 さっそく2月と3月の合算記事となりました。 目次 目次 サービス改善 トップのフリーワード検索の入力欄に設定された誤ったroleの除去 物件情報の編集画面のフォームのアクセシビリティ対応 駅選択ページ内の絞り込み機能のフォーカス改善 物件一覧(ブランド名による検索)ページ内の絞り込み機能のフォーカス改善 物件画像一覧ページ内の「画像をもっと見る」ボタンのアクセシビリティ対応 売却査定フォームのバリデーションを改善 育成・啓発の取り組み アクセシビリティ1on1 WCAG解説書 輪読会 外部発表および発信 お知らせ サービス改善 本期間中の改善取り組みのターゲットはLIFULL HOME'S 不動産アーカイブのPCページです。 諸事情で発表できないものもありますが公開可能な取り組みを紹介させていただきます。 トップのフリーワード検索の入力欄に設定された誤ったroleの除去 アーカイブサイトのトップページにはフリーワードで物件を検索できる入力欄があります。 現在の仕様を確認したところ、comboboxではないただの入力フィールドなのですがcombobox風のroleが誤って設定されていました。 不要なroleを除去し、普通のtextboxとして扱う修正をしました。 物件情報の編集画面のフォームのアクセシビリティ対応 アーカイブサイトでは物件の所有者や詳しい方などが物件情報を編集リクエストするための投稿フォームが存在しています。 そちらのフォームを確認したところ、いくつかのアクセシビリティ要件上の問題が発見されました。 いくつかのフォームコントロールに適切な名前が設定されていない いくつかのフォームコントロールのフォーカスインジケータが見えない(あるいは見づらい) 入力エラーと項目の関連付け 全体エラーの読み上げ 入力ステップ表示に適切な現在地を示すマークアップがされていない これらの問題を解消する修正を実装しました。 ※仕様の調整がつかず全体エラーは現在のところ読み上げのみの対応となります。 駅選択ページ内の絞り込み機能のフォーカス改善 路線・駅から物件を絞り込む検索フロー中の駅を選ぶステップで、駅が所属する都道府県ごとに表示を切り替えるUIがあります。 そちらのUIのトリガとなるボタンにフォーカスが当たらない不具合がありました。 こちらもフォーカスがあたるよう、またそのフォーカスインジケータが視認できるよう修正を加えました。 物件一覧(ブランド名による検索)ページ内の絞り込み機能のフォーカス改善 ブランド名から物件を絞り込んだ際の検索結果ページに、表示された物件を都道府県で絞り込むためのUIがあります。 そのUIのトリガとなるボタンにフォーカスが当たらなかったり、開閉状態を正しく支援技術に伝えられたない等の問題の対応を行いました。 物件画像一覧ページ内の「画像をもっと見る」ボタンのアクセシビリティ対応 物件の画像をギャラリー形式で一覧表示できるページ内に存在する「画像をもっと見る」という表示ボタンがあるのですが、そちらがフォーカス不能・押下時にボタンが消滅するにもかかわらずフォーカスが表示されたコンテンツに移動しないといった問題がありました。 フォーカスを可能にし、フォーカス管理を行う修正をしました。 売却査定フォームのバリデーションを改善 物件の詳細画面内に、その物件を売却査定するフォーム(所有者向け)が存在します。 入力に不備がある際に、入力エラーについて記載がでるよう実装されていますが、支援技術でそれを検知することが難しい実装になっていました。 また、入力エラー時にボタンがdisabledになり、フォーカスができなくなるといった問題も合わせて確認できました。 これらを修正し、フォーカスは可能にしたまま、ボタンが有効でないことを伝え、押下時にエラー内容をフィードバックするように修正しました。 また個別のコントロールにも入力エラーの内容を関連付けるようにしました。 育成・啓発の取り組み アクセシビリティ1on1 本期間中は先月と同じくフロントエンドエンジニア6人、デザイナー1人に対して行いました。 内容はWCAGの解説、APG(aria authoring practices)の解説、coga-usableの解説、実際のアプリケーション開発時でのアクセシビリティ配慮に関する相談などが主なものとなります。 WCAG解説書 輪読会 アクセシビリティやっていき勢向けにWCAGの輪読会を隔週で行っています。 本期間中は別イベントとバッティングが何度かあったため、2024/02/05, 同03/18の2回のみ開催でした。 外部発表および発信 以前の月報記事でも触れましたが、昨年12月8日に行われた「アクセシビリティチームの立ち上げと成長する組織づくり」という勉強会で弊社嶌田が登壇しました。 その際の発表が記事になりました。 お知らせ LIFULLではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの渡邉です。普段はLIFULL HOME'Sの売買領域のエンジニアチームにて技術リーダーとして開発を担当しています。好きなNginxのモジュールはngx_small_lightです。 ここ数年、LIFULLの開発部門では「開発生産性」と「品質担保」の重要性が再注目されています。 LIFULL HOME'Sの主要なリポジトリは、10年以上にわたり運用され続けており、数多くの開発者が日々の改善に尽力しています。 しかし、長年にわたる蓄積によって、アプリケーションの要件を満たすための実装が複雑化し、現在では実装時に調査、開発、レビュー、テストのすべての工程でそれぞれ必要以上に時間がかかる結果となっており、開発の生産性を低下させています。 この問題に対処するため、LIFULL HOME'Sでは既存のアプリケーションから必要に応じてシステムを切り出し、部門ごとでの運用管理を行っています。 売買部門もこのアプローチでの分割を進め、不動産の「売買」に関わるアプリケーションを新基盤に移行しました。 そこで、今回はアプリケーションをリプレイスする際に考慮したことその成果についてお話させていただきます。 リニューアル前後のLIFULL HOME'S ユーザー体験の改善 物件詳細ページ 物件一覧ページ パフォーマンスの改善 LIFULL HOME'Sの抱えていた課題とその対応 開発プロセスやコードを簡素化したい 設計思想をわかりやすく伝達したい データ構造を把握しやすくしたい 成果 リリース速度の改善 設計意図の伝達の容易化 開発プロセスの工数削減 今後の課題 複数アプリケーションに適用したい処理の取り扱い クリーンアーキテクチャの依存関係保護の仕組み アプリケーションをどこまで分割して基盤刷新するか 終わりに リニューアル前後のLIFULL HOME'S ユーザー体験の改善 基盤刷新のタイミングでUI/UXの改善に踏み切り、レスポンシブデザイン化による体験の統一、アクセシビリティに配慮し、スクリーンリーダーやキーボードでも利用可能にするなど、WAI-ARIAを使用したUIマークアップやAccessible Perceptual Contrast Algorithm（APCA）の値が60を超えた高いコントラスト比を適用した結果、アクセシビリティスコアが改善されました。 物件詳細ページ 物件詳細 旧UI 物件詳細 新UI 物件一覧ページ 物件一覧 旧UI 物件一覧 新UI ※ 画像は開発中のものです。 パフォーマンスの改善 レスポンススピードの改善により、スムーズにページが閲覧できるようになりました。またページの読み込みパフォーマンス、インタラクティブ性、視覚的安定性が向上し、Core Web Vitalsのスコアも改善しています。 リプレイスしたアプリケーションには以下の技術を採用しています。 項目 技術 アーキテクチャ Clean Architecture フレームワーク Express, LoopBack x TypeScript HTML Preact x TypeScript CSS Tailwind CSS JavaScript Stimulus, Catalyst インフラ基盤 　　　　 Kubernetes LIFULL HOME'Sの抱えていた課題とその対応 開発プロセスやコードを簡素化したい 現在、LIFULL HOME'Sは50人以上のエンジニアによって運営され、年間1000件以上のリリースが行われています。 開発が始まって10年以上が経過し、プロジェクトが成熟するにつれ、ソースコードの複雑性が高まってきました。この複雑性は、リリースの速度を落とし、ソースコードの品質を年々劣化させる原因の一つです。 開発プロセスには、調査、設計、実装、レビュー、テスト、リリースという一連の段階が含まれます。しかし、10年以上の開発を経る中で増大したコードの複雑さは、過去の仕様が入り組んでいることや、古い技術を使用しているため、各工程の進行を妨げ、プロジェクトの期間を不必要に延ばしています。 これに対処するために、効率的な開発プロセスとコードの簡素化に向けた取り組みが求められています。 元々、LIFULL HOME'Sは賃貸と売買の領域が共存するアプリケーションでした。これらの領域は表面的に似ているように感じられるかもしれませんが、実際には多くの点で異なっていました。それにもかかわらず、無理な共通化を進めた結果、賃貸と売買の領域での差異を吸収するようなコードが増加し、システムの複雑性が時間とともに増していきました。これにより、少しの変更が多くの部分に影響を及ぼし、売買領域の機能改修が賃貸領域に予期せぬ影響を与えることが頻繁に発生しました。この結果、リリースごとに他部署との調整や、調査、実装、テストの工数が増大しました。 そこで、新しい基盤への移行に当たり、元々同一のプロダクトとして扱っていたものを分離し、賃貸と売買を別々のプロダクトとして扱うことで、無理な共通化を排除しました。 設計思想をわかりやすく伝達したい LIFULL HOME'SはもともとMVCモデルで開発されていたアプリケーションでしたが、開始時は少人数であったため、設計方針が適切に伝達されていました。 しかし、時間が経過するにつれて開発者の数が増加し、初期の設計思想の伝達が不十分となりました。 この結果、レビュアーと開発者間の合意が優先されるようになり、当初の設計方針と異なる実装が増加しました。 これにより、多様な思想が混在したアプリケーションが形成されました。 この問題に対処するために、実装者とレビュアーの合意のみに頼らず、アプリケーションデザインを重視して設計方針を徹底的に管理し、見通しの良いアプリケーションを目指す方針に切り替えました。 その実現手段として、レイヤードアーキテクチャの一種であるクリーンアーキテクチャを採用し、責務を適切に設定し、依存関係を明確化しました。 また、既存のLIFULL HOME'Sでは似たようなドメインロジックの再実装が多くの箇所で頻繁に行われており、仕様変更時に多数の実装箇所を変更する必要がありました。 この問題に対応するため、不動産という扱いやすいドメイン特性を活かし、ドメイン層にドメインロジックを集約し、再利用可能なクリーンアーキテクチャを採用しました。 データ構造を把握しやすくしたい LIFULL HOME'SはもともとPHP、Rubyを主言語として開発されていたアプリケーションでした。 年数を重ねソースコードの量が増加していく中で、非常に多くのデータフローをたどり、さまざまなデータが変数に入ることが懸念される状況でした。 また不動産にまつわる情報も多岐に渡るため、正規化しづらく、余計にデータの内容に対する信頼は低い状態でした。 したがって、実装時にも型やデータ形式等の可能性をひとつずつ検証し、レビュー時も実際のデータを見てみないとわからないなど、調査、設計、実装、テストそれぞれの工数が大きくなり、品質的にも良くない状況にありました。 そこで、静的型付け言語であるTypeScriptを採用しました。 数ある静的型付け言語の中でもTypeScriptを採用したのは、フロントエンドとバックエンドの両方を同一の言語で実装できる利点と、全社の技術方針をTypeScriptに寄せようという動きがあったためです。 TypeScriptを採用した理由などの詳細な内容については、 以前寄稿されたこちらの記事に詳細が記載されていますので、気になる方はぜひこちらもご覧ください。 www.lifull.blog 成果 リリース速度の改善 アプリケーションを領域ごとに分割することで、アプリケーション内での責任範囲が明確になり、他のマーケットへの影響を避け、リグレッションチェックが不要となりました。 これにより、テスト時に考慮すべきポイントが減少しました。 さらに、自治権を自部署内で完結させたことで、調整コストの削減やリリースタイミングの管理が容易になり、最短でリリース承認から本番リリースまでを一日で完了できるようになりました。そのため、ユーザーへのプロダクト提供までの時間を短縮できました。 設計意図の伝達の容易化 厳格な制約を課すクリーンアーキテクチャを取り入れることで、独自の思想を持つアプリケーションの意図を理解するのが容易になりました。 クリーンアーキテクチャの採用により、後からプロジェクトに参加した開発者も迷わず開発を進めることができます。 開発プロセスの工数削減 クリーンアーキテクチャや静的型付け言語の採用により、強い設計思想やデータ構造の明確化が促され、設計に関する相談が減少しました。 また、データ構造の明確化やドメインロジックのドメイン層への集約化により、既存仕様の理解やバグ修正の工数が短縮されました。 静的型付け言語を採用したメリットも大きく型定義がしっかりしていることで実装者もレビュアーもデータを正しく認識したうえでソースコードが追えるようになり、工数の軽減に成功しました。 さらに、基盤の刷新により、パソコンとスマートフォンでの見た目を統一するレスポンシブデザインを採用して開発工数を削減しました。 今後の課題 複数アプリケーションに適用したい処理の取り扱い アプリケーションを分割することで、新たな課題が生まれました。 特定のドメインロジックを共通で利用したいといった要望や、ABテストを行うための方法などのどのアプリケーションにも必要になりそうなものをそれぞれのアプリケーションごとに実装したくないといった課題です。 このような状況に対応するため、効率的なリソースの活用を目指し、再利用可能なコンポーネントを慎重に選択し、パッケージ化による再開発の回避を進めています。 パッケージ化は一定の調整を必要としますが、このプロセスにより、多くのアプリケーションが一貫性を持つ方法で利益を受けることが可能になります。 完全にパッケージ化されたソリューションを提供するための調整はありますが、これは品質の向上と開発プロセスの高速化に向けての積極的な取り組みの一環です。 私たちは、必要なアップデートを定期的に行い、より少ない工数で高品質な成果を提供することに努めています。 クリーンアーキテクチャの依存関係保護の仕組み クリーンアーキテクチャに触れたことがある人なら、最初はどのレイヤーがどのレイヤーに依存して良いのかなど、覚えるべきことが多く苦労したことがあるでしょう。 クリーンアーキテクチャは強い制約があるため設計方針が崩れにくい一方で、最初に全体感を把握することは難しいです。 当初はCodeOwnerによるレビューを必須化し、依存関係の保全に努めていましたが、人間の目だけではどうしても抜け漏れが出てしまい、この方法が厳しいという結論に至りました。 そこで、dependency-cruiserによる制御を導入し、CodeOwnerのレビューに加えてシステマティックな保全を図りました。この方法では、dependency-cruiserの設定を徹底的に検証することで、違反が発生する可能性を格段に減らし、開発者がクリーンアーキテクチャを正確に理解していなくても、レイヤー間の依存関係による破壊を避けることができ、目標であったソースコードの品質保証を実現しました。 クリーンアーキテクチャを人の目だけで管理するのは困難です。したがって、このシステム化された保全方法を今後も積極的に導入していく予定です。 アプリケーションをどこまで分割して基盤刷新するか 新規に売買領域のアプリケーションを切り出すことになった際、2つの分割方法を検討しました。 それは以下の二つです。 BFF層とフロントエンド用アプリケーションのパターン 売買領域を一まとめにし、モノリスアプリケーションとして運用するパターン これらのアプリケーションを運用した経験から、それぞれに特有のメリットとデメリットが明らかになりました。 BFFとフロントエンドを分離したアプリケーションでは、フロントエンドのみの変更を行いたい場合、最小限の調査と実装コストでリリースが可能です。 また、バックエンドエンジニアとフロントエンドエンジニアの担当領域が完全に分かれているため、開発のしやすさとコンフリクトのリスク低減のメリットがあります。 I/Oの仕様が合意されていれば、各エンジニアが得意な方法で実装することが可能です。 さらに、BFF層を分けることで他のアプリケーションからのリクエストに柔軟に対応できる利点もあります。 ただし、リリース時には二度手間がかかるデメリットがあり、二つのアプリケーションに関わる修正を行う場合、リリースタイミングによるデータ不整合のリスクが常にありました。 そのため、データが変更されても問題なく機能するように実装する必要がありました。 また、BFFとフロントエンド間のデータ交換はすべてプリミティブな値で行われるため、フロントエンド側でも型定義が必要な二度手間が生じました。 モノリス形態のアプリケーションのメリットは、リリースの頻度が一度で済むため、リリースのタイミングを気にする必要がないです。 また、ドメイン層のValueObjectをフロントエンドでも利用できる設計にしているため、フロントエンド側で新たに型定義を作成することなく使用でき、ドメインロジックの利用が可能になりました。 これにより、フロントエンドでのロジック実装が削減できます。 しかし、このアプローチではフロントエンドエンジニアとバックエンドエンジニアの作業領域が衝突する頻度が増え、レイヤードアーキテクチャ内での役割分担の明確化が必要となりました。 以上のように、どちらのアプリケーションにも運用面、実装面での明確なメリットとデメリットがありました。 そのため、今後も最適な形を追求しながらアップデートを続けていく予定です。 終わりに アプリケーションの再構築には、我々に大きな変化をもたらす可能性が秘められています。課題感を徹底的に分析し、アプリケーションの役割を明確にすることで、そのシンプル性が増すことが期待されます。時には、既存のアプリケーションを思い切って捨て去り、新たな軌道に乗ることで、画期的な進化を遂げるチャンスをつかむこともあります。 当然、新しいアプリケーションへの移行プロセスは、時間がかかり非常に困難なものです。知られざる仕様や対応の漏れなど、予想外の障壁に直面することも少なくありません。 しかし、長期的な視野に立てば、ソースコードの知識を未来世代に継承するとともに、開発生産性を飛躍的に高める絶好の機会であるとも言えます。これは、時に勇気を持ってアプリケーションの全面的なリプレイスを決断する理由となります。 本稿では、技術的な詳細には深く踏み込んでいませんが、その点については今後別の機会で詳しく掘り下げていく予定です。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co