こんにちは！ LIFULLエンジニアの吉永です。 普段はLIFULL HOME'SのtoC向けのCRMチームにてエンジニアリングマネージャをやっています。 本日はクリーンアーキテクチャで構築したプロダクトが初版リリースから2年経過した現在、どうなっているか？について紹介したいと思います。 これから新規プロダクトにクリーンアーキテクチャを採用しようとしている方々の参考になれば幸いです。 アジェンダ クリーンアーキテクチャで構築したプロダクトの概要 クリーンアーキテクチャを採用して得られたメリットやデメリットについて 2年経過してみて今どうなの？ まとめ クリーンアーキテクチャで構築したプロダクトの概要 今回のブログで紹介する我々のプロダクトですが、オムニチャネル戦略を推進する為の各種機能を提供するAPIサーバーとなり、下記のような機能を持っています。 LINE/Mailでその日の新着物件情報をユーザーが希望した検索条件に応じて通知する機能 LINE/Mailでユーザーが問合せた物件に近い条件の物件をレコメンドする機能 LINE公式アカウントでユーザーとトークルームでインタラクティブなやりとりを行い、シナリオ配信やレコメンド物件配信を行う機能 各種サービスとSalesforce社のService CloudやMarketing CloudとのAPI通信を仲介する機能 言語はGoを採用 これらの機能を構成するにあたりクリーンアーキテクチャを採用しており、有名な下記の図にならった形で各レイヤーを構成しています。 出典：The Clean Code Blog https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html なお、このプロダクトにクリーンアーキテクチャを採用した当時はチーム内でクリーンアーキテクチャ及びGoの実装を経験したメンバーはおらず、書籍やWeb、社内で先行採用されていたプロダクトの実装を参考に見様見真似で実装しました。 開発初期は実装もレビューもキャッチアップに時間がかかっており、新しい言語、新しいアーキテクチャによる実装で非常に苦労したことを覚えています。 クリーンアーキテクチャを採用して得られたメリットやデメリットについて どんなアーキテクチャにもメリット・デメリットはありますが、クリーンアーキテクチャにおいても同様で、実際に採用してみて個人的に感じたことを紹介します。 メリット 各レイヤーの責務をアーキテクチャで示してくれているのと、各レイヤーはインターフェースに依存するように設計するので自ずと各レイヤーが疎結合になり、ユニットテストを行いやすい。 ユニットテストを行いやすいので、テストコードを実装するのがあまり面倒にならず、結果的に変更に対する品質の担保をしやすい為、安心して変更できる。 レイヤー間の独立性が高いので、インタフェースさえ設計してしまえば、各レイヤーの実装を別々の担当で並行に作業を進めやすい。 クラス設計に迷ったときにクリーンアーキテクチャという指針があるので、チーム内での議論があまり散らばらず収束しやすい。 指針は示してくれているが、かと言ってガチガチに固まっているアーキテクチャではないので、ある程度は自分たちの開発に特化している形に実装してしまっても、大枠のレイヤー構成や依存ルールさえ守れていれば拡張性と保守性を高く保つことができる。 レイヤーが疎結合になることで、各レイヤーの実装のシンプルさが保たれるので、ソースレビューしやすい。 デメリット 小さな機能追加でもアーキテクチャ内の登場人物が多いので、クラス数が増え、煩雑になりやすい。 基本的にインターフェースに依存するので、IDEでメソッドの「定義へ移動する」際に、たいていのIDEでは定義だとインタフェースに飛んでしまい、メソッドの実態へ飛ぶには「実装へ移動する」を選択する必要があるので、コード内の移動に少しだけストレスを感じることがある。※それはあなたのIDE環境の問題でしょうというご意見もありそうですが エンティティレイヤーは「ビジネスルールをカプセル化したメソッドのあるオブジェクトやデータ構造と関数の集合」を実装するレイヤーなので、DBの1レコード分のデータをマッピングするだけで、アクセッサー以外のメソッドを持たない単純なオブジェクトと複雑なビジネスロジックを実装したオブジェクトが混在することもあり、適切にパッケージなどで分けないと煩雑になりやすい。 2年経過してみて今どうなの？ ステップ数 初版リリース後、様々な機能を追加していったので、リポジトリ内のステップ数は2年間で約3倍になりました。 テストカバレッジ 初版リリース時は自動テストコードのカバレッジは80%程度でしたが、初版リリース後3ヶ月ほどかけて98%まで上昇させ、その後現在に至るまでこの水準を維持しています。 これは、新規追加ファイルのテストコードもなるべくカバレッジは100%を目指そうという方針で開発を進めてきたので、チームの皆で意識して取り組んでいる結果、維持できていると思います。 レビュー 新しくエンドポイントを実装する際はまずクラス図をクリーンアーキテクチャの各レイヤー図にあてはめて作成し、各レイヤー間のインタフェース仕様と追加・変更するクラスを設計レビューしています。 この時点で大枠の設計を固めており、以降の実装フェーズでは基本的にどのレイヤーから実装しても良いようになっている為、実装者が手を付けやすい個所から実装することが出来ています。 メリットでもあげましたが、レビュアーからすると各レイヤーが疎結合でシンプルに実装されている為、レビューはしやすいと思います。 まだ本格的には運用できていないのですが、直近ではPRの変更行数をなるべく抑え、レビューしやすい粒度にPRを分割しようという取り組みもあり、以前だと新規エンドポイント実装時はコントローラー層からドメイン層まで一気に実装してからまとめてレビュー依頼をしていましたが、今後はコントローラーとコントローラーのテストコード、テストコード内で利用するユースケースのモックで1PR、それが終わったらユースケースとユースケースのテストコード、テストコード内で利用するリポジトリやドメインのモックで1PRというようにある程度レイヤーで区切ってのレビューを試してみて、レビュー負荷の軽減ができそうかを検証していこうと思っています。 ※もともとクリーンアーキテクチャで実装されたソースはレビューしやすいと感じていたので、1PRで確認する対象が減ると見逃しも減り、対象へより集中してレビューできると思うので、PRサイズの削減を検討しています 改修のしやすさ 改修はしやすいです。 理由としてはメリットでも挙げた、単体テストを実装しやすい為、既存のコード変更があまり怖くなくなっていることと、各レイヤーが独立している為、例えば新規でエンドポイントを追加する際にも、既存のリポジトリやユースケースのインタラクターを再利用しやすく、コントローラーだけを新規で作成すれば良いといった場面もあり（もちろんその逆もありますが）、インタフェースに依存するようにプログラミングしておくことのメリットを最大限享受できていると思っています。 また、言語も静的型付けであるGoを採用していることもあり、各レイヤー間のインタフェース変更も型が一致しなくなってコンパイルエラーになってくれるので、改修漏れが発生しないことは良いことだと思います。 直近だと、分散トレーシング対応をする為に、コントローラーからエクスターナルまでContextオブジェクトを伝搬させる為のリファクタリングを進めているのですが、コンパイルエラー除去と単体テストの修正を行えば安心してリリースできる状態であることが、開発者がストレスなく開発できていて、開発者体験向上にも一役買ってくれていると実感しています。 余談になりますが、LIFULLではKEELというプラットフォームで分散トレーシングする為の基盤を提供してくれていて、アプリケーションレイヤーで少しだけコードをいじるだけ簡単に複数サービスのログを統合して閲覧できるようになっているので、下記の記事も良かったら見てください。 www.lifull.blog qiita.com まとめ クリーンアーキテクチャを採用したプロダクトが2年経過してみて今どうか？について紹介しました。 正直ネガティブな感想はあまりなく、今後数年に渡って改修を続けていってもあまりゆがまずに済むのではないか？と思っています。 もちろん、初期構想時と比べると、いくつかパッケージ分けが適切じゃないかもとか細かい個所で修正したい個所はあるものの、大枠でみていくとクリーンアーキテクチャで実装したからこそカオスにならずにある程度秩序が保たれていると思います。 また、クリーンアーキテクチャで実装することで、 SOLID原則 に自然と準拠していき、今まで理解があやふやだったSOLID原則が少し理解が深まったと思うので、そういった面でも一度触れてみることは良いと思います。 これからクリーンアーキテクチャを採用してプロダクトを開発しようとしている方々へ少しでも参考になれば幸いです。 最後に、LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

LIFULLでフロントエンドエンジニアをしている齋藤です。 2008年入社なので15年目ぐらいの古株です。今は LIFULL HOME'S の賃貸部門でフロントエンド開発をしています。 いきなりですが、みなさんはアイコンをどう実装していますか？ アイコンフォント、スプライト、一つ一つ切り出す。フォーマットもSVG、PNG、Fontなどなど。 実装方法はいろいろありますし、サイト規模や運用体制などでどれが扱いやすいかは変わってきますよね。 たかがアイコン、されどアイコン。 利用頻度が高く、大きさや色が微妙に違ったりすることも多くてこれまでいろいろと試行錯誤してきました。 そこで今回はLIFULL HOME'Sでどんなアイコン実装が行われてきたかを振り返ってみたいと思います。 これまでの歩み。 都度一つ一つ切り出しての対応 スプライト画像での対応 SVG symbolを利用した対応 data-url化したSVGをimgタグのsrcに埋める対応 番外編：SASSでSVGをdata-url化してbackground-imageで読み込む 終わりに これまでの歩み。 都度一つ一つ切り出しての対応 15年ぐらい前、このころはデザインが上がってきたら一つ一つ切り出して対応していました。 共通化はしていても色が違う、大きさが違うとなれば都度切り出して作成が必要でした。 すでにあるこの大きさじゃダメなのなんて思いながら渋々切り出して対応していたものでした。 スプライト画像での対応 11年ぐらい前、リニューアルを機に新たに設計していく中でアイコンはスプライト画像化を選択しました。 ui-icon という汎用classを作り、アイコンの指定にはもう一つ ui-icon-hoge のように一意のclassを作って対応しました。 すでに作られた画像であれば <span class="ui-icon ui-icon-hoge"/> という感じでHTMLを書けば良かったので格段に楽になりました。 大きさも文字サイズ連動するように作っていたのでフォントと同じように扱えたのも良かった点でした。 また、画像置換の手法を入れていたので空要素としてだけでなくテキストを含めることもできたので、アクセシブルな作りでもありました。 難点は色が違うアイコンだけはスプライト画像を修正して追加しなくてはいけなかったことでした。 // CSS .ui-icon { display : inline-block ; width : 1em ; height : 1em ; line-height : 1 ; background : url( 'sprite_icon.png' ) no-repeat 0 0 / 1em 54em ; text-indent : 1em ; overflow : hidden ; white-space : nowrap ; } .ui-icon-history { background-position : 0 0 } .ui-icon-favorite { background-position : 0 -1em } SVG symbolを利用した対応 7年ぐらい前、このころになるとブラウザのSVG対応も安定してきたのでSVGを活用し始めました。 具体的には、 <body> 直下に利用するSVGのsymbolを置き、利用する箇所でSVG useして利用するというものでした。 SVGなので大きさだけでなく色に関しても可変性があり、ここでついに色・サイズ違いの再作成という呪縛から解き放たれました。 利用する場合にはSymbol IDと色、大きさを指定するだけのtwig macroを準備したのでそれを利用するだけとお手軽になりました。 inline SVGだからこそできるCSSからの色指定も重宝しましたね。 今現在もこれが現役で利用されています。 // Twig 内での利用方法 {{ svg.use('history', '32', '#000', 'title') }} // Twig macro {% macro use(id, size, fill, title) %} {% if title %} {% set aria %}role="img"{% endset %} {% else %} {% set aria %}aria-hidden="true"{% endset %} {% endif %} <svg width="{{ size }}" height="{{ size }}" {{ aria }} focusable="false"> {% if title %} <title>{{ title }}</title> {% endif %} <use xlink:href="#{{ id }}" aria-hidden="true" {{- fill -}}></use> </svg> {% endmacro %} とはいえ課題も出てきました。 運用としては必要なsymbolのみを必要なページで埋めるということをしてきました。 ところが、ページも増え、長年の運用による複雑さも増してきた中でどこのページにどのsymbolが必要なのかが把握できなくなってきたのです。 symbolを置く場所と利用する場所の距離が離れているのが一つの原因でした。 利用しているコンポーネントが読み込まれたらsymbolを埋め込む等ができたら良かったのですが、それもそう簡単ではないので別の方法を準備することにしました。 data-url化したSVGをimgタグのsrcに埋める対応 そして今。上記課題を解決しつつ、作り上げた資産（SVG）も有効活用できる方法として、SVGをdata-urlに変換してimgタグのsrcに埋めるmacroを新たに作りました。 これによりsymbolの読み込みが不要になり、上で挙げた課題解決への一助となる狙いです。 課題解決への一助と書いたのは、既存のsymbol利用をやめるわけではなく併用するからです。 当初は既存macroを書き換えてしまおうと考えていたのですが、symbol利用で書いた通りCSSからの色指定は重宝しているのでこれをなくすことはせず、併用という道を取りました。 // Twig macro {% macro img(id, size, color, alt) %} {% import _self as svg -%} {% set replaceMap = { '<': '%3C', '>': '%3E', '#': '%23', '{': '%7B', '}': '%7D', ' ': '%20', '"': "'", } -%} {% set src = 'data:image/svg+xml,' ~ svg.svg(id, size, color)|replace(replaceMap) %} <img src="{{ src }}" width="{{ size }}" height="{{ size }}" alt="{{ alt }}"> {% endmacro %} {% macro svg(id, size, fill) %} <svg xmlns="http://www.w3.org/2000/svg" width="{{ size }}" height="{{ size }}"> <def> {% include 'Bundle:Assets:svg/icon/_' ~ id ~ '.svg.twig' %}{# svg symbol file #} </def> <use href="#{{ id }}" {{- fill|raw -}}></use> </svg> {% endmacro %} 番外編：SASSでSVGをdata-url化してbackground-imageで読み込む 実はこのdata-url化という手法は以前からSassで利用していました。 Twig同様にSVGコードを渡したらdata-urlに変換して返す関数を作って実現しています。 SVGコードをencodeして data:image/svg+xml で返す。 TwigでもSassでもやっていることは一緒ですね。 // Sass @function svgUrlEncode( $svg ) { $replaceMap : ( '<' : '%3C' , '>' : '%3E' , '#' : '%23' , '{' : '%7B' , '}' : '%7D' , ' ' : '%20' , "'" : '"' , ); @each $s , $r in $replaceMap { $encode : string.str-replace( $s , $r , $svg , true); } @return $encode ; } @function svgDataUri( $svg ) { $svg : svgUrlEncode( $svg ); @return url( 'data:image/svg+xml;charset=utf-8, #{ $svg } ' ); } 終わりに いかがでしたでしょうか？ やり方はほかにもいろいろありますが、言語やブラウザの対応状況等のタイミング、使える時間というのもあってこういった変遷をたどってきました。 技術の進歩やその時の課題・状況に合わせ最適解を探す。 今後も課題解決をしながらサイト機能や開発効率などの改善に取り組んでいきたいと思います。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の海老澤です。 普段は LIFULL HOME'S の賃貸部門のフロントエンド開発をしています。 近年、LIFULL の開発部門では「開発生産性」という言葉が取り沙汰されるようになりました。 LIFULL HOME'Sの主要リポジトリは10年以上運用され続け、今も多くの開発者によって日々改修され続けています。 長い年月の中で小さな設計ミスも積み重なって大きくなり、ちょっとした実装でも入念な調査が必要となり開発生産低下の要因となっていました。 また10年以上前に採用したフレームワークで稼働しているため、今ではドキュメントを探すのも一苦労という具合です。 そこで主要開発部門では「自部門の機能はマイクロサービスへと切り離し、各々で面倒を見る」という方針になりました。 賃貸部門も同様に機能の切り離しを始め、先日「物件詳細ページ」のマイクロサービス化を行いました。 今回はマイクロサービス化にあたり新基盤の技術選定をしたので、実際触ってみた感想などを交えながら紹介していければと思います。 画面のビフォーアフター マイクロサービス化と同時にUIのリニューアルも検討、開発中です。 旧UI 新UI ※キャプチャは開発中の画面です。 旧基盤ではダイナミックサービングでPC/Tab用・SP用のレイアウトを切り替えていましたが、新基盤ではレスポンシブデザインへと変更しました。 デバイス間のデザインルール・トンマナの差分をなくすこと、開発生産性を上げ改善スピードを上げるのが狙いです。 新基盤の全体構成 今回は Web アプリケーション部分のみ刷新を行いました。API は全社で使っている既存のものを使っています。 新基盤の構成図 ここからは技術選定についての詳細を書いていきます。 バックエンド バックエンド 技術選定のモチベーション 社内で標準採用されている言語・技術であること これは組織の課題でもあるのですが、LIFULL はエンジニアの部署異動がそこそこあります。 社内では技術集約の観点で標準技術が定められてるのでそれに従いました。 技術選定で「挑戦」しないこと LIFULL HOME'S の賃貸部門は LIFULL の中でも中核を担う組織で、ほかの開発チームに比べて規模が大きいです。 それゆえに人員の入れ替えも顕著で、さまざまな技術スタックを持った人がいます。 そういった中で目新しいフレームワークを用いるとドキュメントや知見不足に悩むことがあります。 有識者がチームに必ずいるのであれば良いのですが、チーム編成の都合上難しい場合もあります。 そうなってしまった場合、開発はつまずきがちになりますしコードの品質も落ちることが過去の経験則から容易に想像できました。 このような事態を避けるために我々は技術選定で「挑戦」するのをやめ、学習コストの低いフレームワークを採用することを選びました。 採用技術 上記のモチベーションを踏まえ、バックエンドは以下を採用しています。 アーキテクチャ: Clean Architecture フレームワーク: Express x TypeScript アプリケーション実行基盤: 内製ライブラリ「KEEL」 アーキテクチャ: Clean Architecture LIFULL のバックエンド刷新プロジェクトで採用されたアーキテクチャです。 それが社内に広まっていて知見も溜まっているため、今回 Clean Architecture を採用しました。 www.lifull.blog 情報を表示するだけの Web アプリケーションで Clean Architecture は冗長ではないかという意見もありましたが、レイヤごとの責務・規約がはっきりしており制約が厳しいことから開発者によるブレが少なくなることが見込めます。 実際業務で触ってみたときも「どこに何を書けばいいのか」というのが分かりやすく、設計しやすいのは魅力だと感じました。（実装の「詳細」「抽象化」まわりの理解はちょっと大変でしたが……😇） フレームワーク: Express x TypeScript 言わずと知れたバックエンドフレームワークです。 日本語ドキュメントや記事、ライブラリも充実しているため学習コストを低く抑えることができます。 型の恩恵は受けたかったため TypeScript も導入しています。 TypeScript は社内でも導入事例が多くすんなり決まりました。 今の所は複雑な型推論は必要としておらず、素直にコードを追えば型がわかるため安心感があります。 バックエンドとフロントエンドで言語を共通にできるのも良い点だと感じました。 アプリケーション実行基盤: 内製ライブラリ「KEEL」 実行基盤は全社で利用している内製ライブラリ「KEEL」を活用しています。 デプロイやログ吐き出しなど日々の運用タスクを吸収してくれるすばらしい基盤で、 KEEL のおかげでアプリケーション開発に集中できています。 当ブログでもよく記事があがっていますので詳細は割愛しますが、ぜひご覧ください。 www.lifull.blog フロントエンド フロントエンド 技術選定のモチベーション メンテナンスコストが軽いこと まず第一に、LIFULL HOME'S は複雑な操作やインタラクションを必要としないポータルサイトです。 クライアントが入稿した情報の表示がメインで、ユーザーの操作によって画面が大きく変わるということがほとんどありません。 そういったサイトを開発していくうえで React や Vue を用いるのは冗長だと考えました。 実際アップデートの頻度も高くメンテナンスコストが嵩みますし、ビルドプロセスも必須です。 今後さらにイケているフロントエンド技術が出てきた際に引き剥がしにくいという欠点もあります。 前身のメインリポジトリは10年以上稼働していますが、 ソースコードの規模が膨大すぎること、依存関係が大きいことからアップデートが非常に困難になっています。 今回の新基盤は何年稼働するか分かりませんが、少なくとも5年以上は開発されるでしょう。 そうなった時にメンテナンスコストが軽いというのは大きなメリットとなります。 開発者のスキルに左右されないこと バックエンドの技術選定でも触れましたが、賃貸開発部門は規模が大きく人員の入れ替えも顕著です。 常に複数のチームが稼働しており、同じページを並行開発していることもあります。 HTML/CSS/JavaScript に明るくないコーダーやバックエンドエンジニアがフロントを触ることも多々あります。 そういった際に学習コストの高い React や Vue だと逆に開発の遅れを招いたりレビューコストが高まるという懸念もありました。 そのため、なるべく平易で学習コストの低い技術を採用しています。 後述する Tailwind CSS や Stimulus は比較的最近のフレームワークですが、ドキュメントが簡潔かつできることも限られているため1日あれば手に馴染む技術です。 フロントエンド 採用技術 これらのモチベーションを踏まえ、フロントエンドは以下を採用しました。 HTML: Preact x TypeScript で HTML を生成し Express でサーバサイドレンダリング CSS: Tailwind CSS JavaScript: Stimulus HTML: Preact x TypeScript Preact x TypeScript で Express から素の HTML を返却しています。 Preact の選定理由としては軽量であること、型が使えることです。 我々は HTML をレンダリングしたいだけなので React のような重いライブラリは冗長でした。 とはいえ型情報は付与したかったので、 tsx 形式が使える Preact を採用しています。 クライアントサイドの振る舞いは前述の Stimulus を利用するので Preact はテンプレートエンジンとしてのみ利用しています。 これは別のテンプレートエンジンに差し替えたくなったときに載せ替えを容易にするためでもあります。 CSS: Tailwind CSS Tailwind CSS はユーティリティファーストな CSS フレームワークで、非常に小さい単位の CSS クラスを HTML に直接書いて組み合わせることでスタイリングをします。 従来の課題として、HTML と CSS の概念的距離が遠いという問題がありました。 普通にコーディングを行おうとすると HTML に適当なクラス名を振って別途 CSS でそのクラスに応じたスタイルを書き、HTML 側でその CSS を読み込むという手間が発生します。 Sass の登場で CSS を書くのはいくらか楽になりましたが、概念的距離の圧縮まではいきませんでした。 Vue のように SFC でやるという手もありますが、それでもクラスの命名という一番面倒で退屈な作業は残ってしまいます。 Tailwind CSS はすでに用意されているクラスを組み合わせて使うので命名という概念がなく、 HTML にガンガン書いていけるので概念的距離をゼロにできます。 また、クラスの単位が非常に小さいのでカスタマイズ性も高く、デザインの再現も容易です。 HTML を見るだけである程度見た目が想起できるというのも魅力的ですね。 頻出スタイル（ex: ボタンデザイン）は @layer component へ切り出して使っていますが、ごく少数ですし1ファイルにまとめているので何個も CSS ファイルを開くこともありません。 体感ですが CSS を書いていたころよりも倍以上のスピードでコーディングできるようになったと感じています。 素 CSS/Sass を書くときは少し憂鬱になります。 JavaScript: Stimulus 前述したように、LIFULL HOME'S は物件情報を載せるポータルサイトでありユーザーの複雑な操作を必要としません。 そのため js で与えるべき振る舞いも少なく、再利用できる動きがとても多いです。 そういった振る舞いを共通化する際、React や Vue でコンポーネント化して再利用するというのが考えられます。 しかし表示箇所によって少しデザインが変わるだけで HTML や CSS クラスの分岐が発生してコンポーネントが肥大化していくという問題があります。 Slot や Mixin を使いこなせばそんなことにはならないかもしれませんが、大規模な開発組織でそれらの統率をとっていくのは非常に困難です。 そこで我々は 37signals 謹製の JavaScript ライブラリ Stimulus を採用しました。 ドキュメント にもあるように、Stimulus はちょっとした振る舞いを HTML に与えるライブラリです。 HTML に data-controller とそれに付随するデータ、アクションを書くことでイベントを貼り付けることができます。 Stimulus の旨味は Controller を複数アタッチできること、DOM 構造に縛られないこと、イベントアタッチの処理が不要なこと です。 再利用性の高い小さな Controller を作っておけば HTML がどんな構造・デザインであろうとアタッチすれば動きますし、複数組み合わせると複雑な動きも作れます。 また、HTML と js の結合で一番面倒なのが addEventListener の処理かと思いますが、 Stimulus は MutationObserver で DOM を監視しており HTML が画面に出現するだけで 自動で該当の Controller のイベントがアタッチされます。 これは非常に強力で、サーバサイドから Stimulus Controller が設定された HTML を返却すれば Ajax で画面を一部更新しようと勝手にイベントがアタッチされるため js の読み込み忘れで画面が壊れた〜という心配もありません。 同様に DOM が消えれば removeEventListener されるのも安心ポイントです。 今回の新基盤ではオートローダーの仕組みも導入しているためページごとに読み込む js を bundle する必要もありません。たいへん快適です。 弊社エンジニアの Qiita 記事でも紹介しております。 qiita.com 再利用性の高い Stimulus Controller が充実してくると HTML に既存 Controller を書いていくだけで振る舞いの実装が終了するため、js を書くことがほぼなくなります。 実際、新基盤が稼働してから数ヵ月機能追加・画面改修をしていましたが、ほとんど js は書いていません。 コードは書くほど負債になると言いますが、きちんと設計すればするほど資産になっていくのも Stimulus の魅力だと感じます。 過去の記事でも話題にしていますので、ぜひこちらもご覧ください。 www.lifull.blog テスティング テスティング 技術選定のモチベーション テスティングに関してはそこまで大きい課題感はなかったのですが、 UnitTest を速く実行できること、E2E テストを書きやすくするのは意識しました。 テスティング 採用技術 UnitTest: Vitest E2E: Playwright UnitTest: Vitest Vitest は Vite の設定をそのまま使えるテスティングライブラリです。 今まで弊社の TypeScript 環境では Jest を採用していて最初はそれに倣っていましたが、 開発中に Vitest がよいぞとなり乗り換えをしました。 書き味は Jest とほぼ同様ですが実行速度が桁違いで、爆速で UnitTest を回せます。また、config も非常にシンプルで設定がとても楽ちんです。 Vite を使っているわけではないので全恩恵を授かっているわけではないのですが、実行速度が速いというだけで爆アドだと思います。 乗り換え自体もとても簡単にできたので、Jest を使っている方はぜひ Vitest もご検討ください。 E2E: Playwright Playwright は Microsoft 謹製の E2E ライブラリです。 TypeScript に標準対応しているのが魅力的で、難しいセットアップをせずとも導入が可能です。 公式ドキュメント も充実しており、「こういうことがやりたいな〜」というのはたいてい Guide にそろっているので安心感があります。 主に旧基盤と新基盤の情報の表示差分確認や package bump 時のビジュアルリグレッションで活用していて、テスト工数の削減に役立っています。 まとめ まだ新基盤が稼働して数ヵ月しか経っておりませんが、旧基盤と比べて圧倒的に開発しやすく生産性が高まっているのを感じています。 実際稼働から何名か新規メンバーが入りましたが、そこまで苦労せず開発できているようです。 LIFULL HOME'S はまだまだ成長していくプロダクトです。 今回の基盤刷新をきっかけにより良い価値をユーザーに届けてまいります💪 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの加藤です。LIFULL HOME'Sの注文住宅領域を支えるエンジニアチームのマネジメントを担当しています。 LIFULLでは定期的に エンゲージメントサーベイ を実施し、組織の状況把握を行っています。 しかし、エンゲージメントサーベイは全職種共通のフォーマットとなるため、「開発のしやすさ」や「プロジェクト進行」などエンジニア特有の課題までは特定しづらく、さらに深掘った分析が重要です。 こうしたエンジニア特有の課題発見や課題の深掘りを効率的に行うため、「ネガティブミーティング」を企画し実施したので、そちらを紹介したいと思います。 ネガティブミーティングとは 弊社では課題を出し合う話し合いを「ネガティブミーティング」と称して実施しています。 ここでは解決策などは議論せず、ひたすら「コト」に向けて率直な課題を挙げることに集中します。 また、ネガティブミーティングで出た課題の打ち手は別途「ポジティブミーティング」と呼ばれる話し合いで議論し、課題解決の実行まで落とし込みます。 我々はこれら2つを組み合わせて「ネガポジミーティング」と称し、セットで実施しています。 ネガティブミーティングの特徴 ネガティブミーティングは、課題だけを挙げるミーティング 課題を出すことだけに集中するため、普段だと言いづらい反対意見や代替意見も思い切って伝えることができる ネガティブな内容でも、意見を出すことを楽しむ ポジティブミーティングの特徴 ネガティブミーティングで出た課題の解決策を決めるミーティング 実行する解決策を決めたら「誰が」「なにを」「いつまでに」を決める ワークの流れ 今回のワークでは3, 4名ずつのチームに分かれ、以下の流れに沿ってネガティブミーティングを実施しました。 誰かが「ここがつらいよ〇〇」を決める（例：ここがつらいよ目標設定） みんなで「その心は〜」をひたすら出す（例：その心は、エンジニアの成果の定量化がキツい） 意見を出し切ったら1に戻る 今回のようなワークではより多くの観点で課題を出し合うことと、チームメンバー全員が話し合いに参加することが重要です。 そのため、1のテーマ設定は一人ずつ持ち回りで行うよう工夫しました。 また、ネガティブミーティングでは出てきた課題に対し悲観的になるのではなく、むしろ課題が浮き彫りになったことを前向きにとらえることも重要です。 最後は笑顔で終えられるしくみとして、チーム内で最も共感された課題を川柳（または短歌）にまとめ、全体へ共有してもらうこととしました。 やってみた結果 今回は約30分のワークにて実施しましたが、50を超える課題を発散したチームもあり想像以上の結果が得られました。 大きく分けると「開発プロセス」、「プロジェクト進行」、「技術的負債」、「プロダクト」、「目標・評価・キャリアパス」についての課題が多く挙がり、狙いであったエンジニア特有の課題発見と深掘りが実施できたと感じています。 また、どのチームも楽しみながら課題を出し合えていたように見受けられ、この後実施する課題解決にも前向きに取り組んでいける印象を抱きました。 組織課題のようなネガティブな意見は心理的安全性が担保された環境でなければなかなか言いづらいものです。 ネガティブミーティングのフレームでは課題を出し合うことだけに集中することが前提となるため、そういった環境づくりに効果的であると感じます。 まとめ 今回はネガティブミーティングを通じて組織課題を発散する取り組みについての紹介でした。 今後はポジティブミーティングを開催し、今回出てきた課題への打ち手を考え、解決に導くための取り組みも実行してきたいと思います。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは！LIFULLのエンジニアで、Ltech運営チームの河西です！今回は 2023年2月21日（火）に開催した『Ltech#23 LIFULLにおけるSalesforce活用事例について語ります』についてレポートします。 Ltechとは 株式会社LIFULL主催の、技術（エンジニアリング・テクノロジー）をテーマにしたイベントの総称です。 特定の技術に偏らず、様々な技術をピックアップしていきます。 Session1 Salesforceのシステム構成と最近の開発施策の共有 www.docswell.com このセッションでは、LIFULLにおけるSalesforceの利活用による目指す世界、そのために直近で行った施策について紹介いただきました。 最初に、Salesforceの利活用によって実現される世界として、「オムニチャネルの実現」を掲げ 一箇所にデータを集めて、オムニチャネルを実現。 LIFULLのエンドユーザ様へ最高のユーザ体験をご提供したい。 そのために、LIFULL HOME'S等LIFULLの各サービスや社内システムを繋ぎ、CRM(Customer Relationship Management)を実現する。という世界観を語っていただきました。 続いて、様々な具体的な取り組み事例として PIS(Personal Information System)というお問い合わせ情報を一元管理するためのAPIを開発 ログイン画面でユーザ登録した、ログインユーザ認証情報を格納・管理するための仕組みを構築 Salesforce Marketing Cloudと連携し、エンドユーザに対して、物件案内のメールを配信する仕組み 不動産会社様向けLIFULL HOME'S PROサイトで閲覧できるレポート機能 商談・注文情報など各種情報や売上金額が確認できる社内システム Pardotを利用した不動産会社様向けツールの利用 などなど、様々な事例をご紹介いただきました。 今回は時間の都合上、全てを細かく紹介できませんでしたが、まさしくCRMを実現するために、様々な取り組みをされている印象でした！ Session2 Salesforce Field Service Lightningによる不動産相談窓口サイトの開発立上げ www.docswell.com このセッションでは、Field Service Lightningを利用して、不動産相談窓口サイトの立ち上げを行った話について紹介いただきました。 LIFULL HOME'S住まいの窓口の相談予約ページでは、高いNPS（Net Promoter Score）を実現するために、手動による管理が多くの工数を占めており、運用負荷が高い状態でした。 その状況を打開するために、Field Service Lightning（以下FSL）に着目し、 テクニカルナレッジは公式のわずかなものだけ 国内導入事例が皆無の新製品での挑戦 という状況下のなか、如何にして改善を行ったのかをご紹介いただきました。 当日の発表を聞きに来ていただいた方からも、FSLについてのQAが多く、 ・Field Service Lightning は使ったことがないのですが、導入にあたってハマったポイントや苦労した点はありますか？ ・Field Service Lightningを選んだ理由はなんですか ・Field Service Lightningはチャット機能等、ほかにもいくつかありそうですが予約受付以外ではどのような機能をつかっていますか？ といった様に、実例が少ない中、実際に導入・運用をされた経験を聞けた貴重なセッションでした！ Session3 SalesforceのデータをもとにTableauで月ごとの売上金額を表示 www.docswell.com このセッションでは、最初のセッションで紹介されていた「商談・注文情報など各種情報や売上金額が確認できる社内システム」についての具体的なお話について紹介いただきました。 LIFULLにおける商談の流れの中で、それぞれ商品情報の持ち方が異なるため、月ごとの売上がいくらなのか集計しずらいといった課題がありました。 こちらの課題を解決するために、 SalesforceのApexバッチやApexトリガで売上金額を分割 BigQueryに連携 BigQueryに連携したデータをTableauで可視化 といった手法を用いて解決した事例を紹介いただきました。 QAでは、以下の様な質問もしていただき、 ・Salesforceの標準レポートやダッシュボードの機能とTableau?の機能に差はありますか？ 回答として、「Salesforceで補えない部分を他のサービスを組み合わせて解決していく」といった、実務でないと聞けない貴重なお話を聞くことができました！ まとめ 今回はLIFULLにおけるSalesforce活用事例としてSalesforceに関する話を3名のエンジニアに発表いただきました。この他にもLIFULL HOME'Sではメンバーが随時 LIFULL Creators Blog にて情報を発信しています。 www.lifull.blog Ltechでは、LIFULLのエンジニアが中心になって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。今後も Ltech を積極的に開催していきますので、ぜひ気になった方は、connpass で LIFULL のメンバー登録をよろしくお願いします！ lifull.connpass.com また、LIFULLでは、数多くの職種の仲間を募集しています。 よろしければこちらのページもご覧ください。 【エンジニア】募集求人一覧 | 株式会社LIFULL 【エンジニア】カジュアル面談 | 株式会社LIFULL

プロダクトエンジニアリング部の二宮です。 我々のプロダクトエンジニアリング部では「強い個人・最高のチームになることで価値創造を加速させ続ける」というビジョンを掲げています。そして、その「強い個人」を目指して、週に数時間程度、普段できないチャレンジングな技術の探索など、ある程度自由に時間を使うことが推奨されています。 その一つのやり方として、最近は社内で技術書の輪読会をすることが流行ってます（以前、LIFULLクリエイターズブログにも「 "INSPIRED"の輪読会を通してふりかえるプロダクト開発 」という記事も共有されています）。 今回は、2つのチーム合同で『 システム運用アンチパターン 』を読み終わり、その輪読会がなかなか好感触だったので紹介します。ある程度ベテランのエンジニアが持つ知識を身につけるとともに、本の内容に触発された議論も同時に行えたと思っています。 輪読会とは まず、輪読会とはなにかに説明します。 weblio辞書 から引用します。 人々が集まって、同じ教科書などの本を読み、その内容について意見を交わすことを意味する語。 事前に決められた担当者が、本の内容を訳したりまとめたりしてから、他の参加者が理解できるように発表する形式がとられることも多い。 ちょっと話を先取りすると、個人で勉強するより「質問ができる」「その場で自分たちの文脈での議論ができる」などのメリットが感じられました。 輪読会の実施方法 輪読会には様々なやり方があるのですが、私たちが実際にどのように実施したのか紹介します。これ以外の方法を幅広く知りたい方は「 輪読会のすゝめ。全8回の開催で学んだ失敗パターンと成功のコツ 」などの記事が参考になると思います。 参加者 担当プロダクトが別の2つのチームが合同で行いました。人数は6人で、全員がソフトウェア開発がメインのエンジニアです。 本の選定 候補に挙がったのは次の3つの本です。 システム運用アンチパターン Googleのソフトウェアエンジニアリング 仕事ではじめる機械学習 「主管システムに関わらず共通しているシステム運用の実務に関して学べそうな内容で、比較的短期間で読み終わりそう」という理由で『システム運用アンチパターン』を選びました。 重厚な承認プロセス、可視化されていない運用、プロセスの最後でのみ行われるソフトウェアテスト、ノイズだらけのアラート、インシデントから学習しない習慣、時間外のデプロイ、情報のため込みなどを取り上げ、ソフトウェアシステムの開発運用が滞るチームや組織に共通してみられる陥りがちな状況や犯しがちな間違いをアンチパターンとして紹介します。そして管理職やマネージャでなく、エンジニアが実行し、繰り返すことで改善できる具体的な行動を解説します。 本の内容もけっこう面白く、後述する「過去の失敗談をフラットに共有できた」「開発文化について考える機会となった」みたいな感触は、この本のテーマのおかげが大きかったんじゃないかと思います。 実施方法 「各章の担当者を決め、毎週輪読会の時間を取り、1章ずつ担当者が内容をまとめて発表する」というオーソドックスな方法で行いました。輪読会本編は前半で発表を聞きながら質問やコメントを表に書いていき、後半でそれを元に話をする形式です。 第3章の「盲目状態での運用」で会話した跡の表 このように、「社内の文脈に置き換えるとどうなのか？」とか「実は本の内容と近い失敗をして後悔してるんだ」とか話が広がりました。 輪読会をやりながら、工夫して変えた点は2点あります。自分たちにとって輪読会ははじめての経験だったため、途中で一度振り返りの時間を用意していました。 輪読会の時間を15分に設定していたが、めちゃめちゃ駆け足になってしまったため30分に延長した まとめ方は完全に自由だったが、「どこまでまとめればよいかが分からなくて大変じゃない？」「自分の経験も絡めた話もあったほうが面白そうだ」みたいな声が上がり、簡単な推奨フォーマットを用意した フォーマットといっても、要約や章のポイントを箇条書きし、関連するエピソードや自分なりの解釈 をコメントするという簡単なものです。 実施した実感 輪読会の後に振り返りでは、次のようなメリットが感じられたという意見が出ました。 本の内容に触発され、ベテランの過去の経験を聞くことができた。過去の失敗談をフラットに共有できた 他の人に説明する必要があるので、担当した章の内容を、分かったつもりにならずに理解できた 社内の開発文化について自分の立場から貢献できることはないか考える機会となった 共通認識ができて、その場で現状改善のアイデアの議論ができた 会話が弾んだ。単純に楽しかった 特にこの本の内容はネガティブさとポジティブさのバランスが絶妙だったと思います。例えば「 第10章 ブレントだけが知っている 」には次のような話がありました。 意識しないとキーパーソン（『 The Phoenix Project 』の登場人物のブレント）に知識が集まる 情報を積極的に共有すればいい？→公開するだけでは興味を持てるわけではない ひどいと誰も全体を見なくなる 私自身もそうだったことがあるように、「せっかく情報共有のドキュメントを書いたのにみんなが興味を持ってくれない」「組織文化がドキュメントの重要度を理解してない」という、自分自身のモチベーションを下げ、冷静な議論を妨げてしまう形で悩んでしまうことも多いと思います。 ただ、そのような失敗例を共有するだけでなく、「実はドキュメントだけでなく別のコミュニケーションの方法もあったんじゃないか」とか「情報共有を習慣づけするためにこういう方法もあったんじゃないか」という紹介があり、そこでポジティブで建設的な話に自然に繋がったように思います。 おそらくDevOpsやアジャイル手法の本は、特にエンジニア経験の違いに関わらず発展的な議論ができ、同様の感触が得られるものも多いんじゃないかと思ってます。特にベテランから若手へと、数々の失敗で学んだ暗黙知を共有するのにも役立つかもしれません。 そして次の輪読会へ 今回の輪読会では、きちんと本を最後まで読み終わり、2チーム合同の輪読会の形では解散ということになりました。 次に、自分たちのチームでは『 仕事ではじめる機械学習 』を読み始めています。自分たちはBigQueryにあるデータを扱うことが多く、機械学習も絡めたシステムを作れれば、より有用な機能を実装するチャンスを広げられると考えているためです。今度は本の内容に合わせて「全員が軽く事前に読んでいて、それぞれが気づいた点や質問したい点をまとめて発表する」という別のやり方で工夫しています。 仕事ではじめる機械学習の輪読会の様子 こちらも、また機会があればブログで報告します。 最後に 最後に、募集求人やカジュアル面談のページを紹介します。一緒に成長しながら、前向きにチーム文化を作っていける方に来ていただけると嬉しいです🙇‍♂️ hrmos.co hrmos.co

こんにちは！LIFULLプロダクトエンジニアリング部の 鄭 在淳（ジョン・ジェスン） です。2022年に新卒で入社して、主に 不動産アーカイブ や 住まいインデックス の開発・運用を担当しています。 今年、新卒2年目のエンジニアとなり、ますます幅広い分野の業務に取り組んでいます。そして、自分が担当するタスクをより効率良くこなすためには、 個人の「情報力」を成長させることが非常に重要 だと感じています。 「情報力」とは、エンジニアが最新技術や良いコードの書き方、アーキテクチャ設計などの 情報を習得（Input） し、これらの情報を 実際の業務で活用（Output） する一連の流れと定義します。つまり、エンジニアたちの情報との向き合い方を意味します。 「情報力」を向上させるためには、自己学習などを通してエンジニア自身が一人で頑張れば、十分成長できるかもしれません。一人ではなく、 多くの人が集まって一緒にすれば、より大きな価値を出すこと ができます。 LIFULLではエンジニアの「情報力」向上のため、様々な取り組みを行っているので、今回の記事でいくつかの活動を紹介します。 目次 目次 LIFULLの活動紹介 Qiita Blog LIFULL Creators Blog LIFULL Developer Channel エンジニアいつでも相談 エンジニア向けの社外・社内イベント まとめ LIFULLの活動紹介 Qiita Blog 主にLIFULLのエンジニアたちが Qiita organizations にアカウントを登録して 誰でも自由に作成できる技術ブログ です。技術的な内容以外にも、プロジェクト運用・効率的なツールの使い方・開発環揃えなど様々なカテゴリーの記事を投稿しております。 Qiita Advent Calendarに参加し、LIFULLは全てのカテゴリーの中で7位となるほど大盛況でした。その中でも、 @pal4de が投稿した2件の正規表現式記事は、合計で500件を超えるいいねを獲得しました。正規表現でお困りの方は是非ご覧になってください。 たった４文字でコード検索の精度がブチあがる正規表現 シンプル図解: 正規表現の (?= ) とか (?! ) とか (?<= ) とか (?<! ) とか LIFULL Creators Blog この記事が掲載されているHatena blogです。LIFULLのビジョン実現につながる価値提供への取り組みを発信しております。 LIFULLのコーポレートメッセージ LIFULLのビジョン Qiitaとは異なり、エンジニアではなく「LIFULLのものつくり」に取り組んでいる社員なら、職種と関係なく記事を投稿できます。主にLIFULLのサービスを発展させるため、取り組んでいる内容が投稿されていて実際のプロダクトを事例としているので、 記事を通してLIFULLの文化や雰囲気などを知ること ができるのが特徴です。 例えば、LIFULLへ入社を考えている方が気になる「リモートワーク化での働き方やコミュニケーションの取り方」や リモートワーク化でも大切にするオフラインコミュニケーション リモートワーク時代におけるサークル活動の取り組み 「LIFULLのプロダクトどのようなシステムで運用されているのか？」等の入社前に知ることができない情報を記事を通して確認することができます。 LIFULLの全社アプリケーション実行基盤 KEEL について LIFULLのプロダクトの可観測性の向上について LIFULL Developer Channel 自分自身も運営メンバーとして参加している YouTubeチャンネル です。 LIFULLのエンジニアたちがYouTubeを通して、QiitaやCreators Blog 等のようにテキストに加え動画といった より多様な形式での情報の発信ができる環境を創る ために運営メンバーとして参加しています。 昨年9月頃に 「情報セキュリティ対策を行う意義」 という最初の映像を投稿させていただきました。3月上旬頃に2本目のLIFULLエンジニアのキーボードを紹介する動画を投稿することを目指しています。 LIFULLの文化や雰囲気をよりリアルで伝えていきたいと思いますのでよろしくお願いします。 エンジニアいつでも相談 1年ほど前にエンジニアの二宮が投稿したブログでも紹介させていただいた、GitHub Discussionsを使った社内向けのQ&Aフォーラムです。エンジニアが 誰でも気軽に技術相談やプロダクト仕様に関する質問など行えるようにすること を目的として作られたのが「エンジニアいつでも相談」です。 GitHub Discussionsで社内のQ&Aフォーラムを開設する 例えば、誰かが「設計の方針を決定することで〇〇が気になります。」、「実装で〇〇を迷っています。」、「〇〇に関して知見がある方がいらっしゃったら、教えていただけますか？」のような 質問を投げると、LIFULLエンジニアの皆が回答 してくれます。 このように相談しやすい環境ができているので、いつでも心理的安全性を保ちながら働くことができます。複数の人がDiscussions内で議論して解決策を探っていく様子がOSS活動にも似ていると感じており、課題に対して皆が協力して一緒に解決するという開発文化が社内で作られています。 エンジニア向けの社外・社内イベント 「カイゼン・ジャーニー」という書籍でも紹介されたことがありますが、 チームから会社へ越境して社内改善の場を作る のはエンジニアリングで非常に重要なところです。それを実現するため、LIFULLではLtech、LIFULL Tech Hub、ハンガーフライト、フリートーク勉強会等のエンジニア向けの多様な社外・社内イベントを開催しています。 LIFULL主催の技術勉強会 Ltech 『#21 LIFULL HOME’Sを支える検索技術』開催レポート （社外向け） 社内テックカンファレンスLIFULL Tech Hubを開催しました （社内向け） 毎月、技術的な話からチームのプロジェクト管理方法など様々なテーマでイベントが開催されており、自部署で担当している業務範囲以外の分野の技術・知識も得ることができます。経歴や担当業務に限らず、希望すれば誰でも手を挙げて発表できるので、小さな改善でも全社的に拡大していくことができます。私も入社して2回程度自分が改善のため取り組んだことを発表したことがあります。 まとめ 今回紹介した活動以外にもLIFULLでは エンジニアの情報力を成長させることができる様々な活動 をしています。こうした活動が「エンジニアとしてみんなを幸せにしたい」という想いの実現につながり、LIFULLの社是である「利他主義」とも繋がっていると思います。 LIFULLのエンジニア組織は エンジニアとして経営をリードする ことで活躍するというスローガンを掲げています。短期的に技術の幅を広げるだけでなく、技術を手段として中長期的に社会課題解決に貢献していくことを目指しています。 LIFULLではコーポレートメッセージである「あらゆるLIFEを、FULLに。」の実現を目指して、国籍、年齢に関係なく共に働いていただける仲間を募集しています。興味がある方は以下のページをご覧ください。 hrmos.co hrmos.co

エンジニアの松尾です。LIFULL HOME'S の売買領域を支えるエンジニアチームのマネジメントを担当しています。 私が所属する組織ではLIFULL HOME'Sからより良い価値を提供していくために、エンジニアの「業務効率化」と「コミュニケーション活性化」が課題となっています。今回はこれらを効率良く進めるために取り組んだ内容を紹介します。 組織の課題 業務効率化 コミュニケーション活性化 両立のための取り組み 開催の準備 コンペ当日の流れ その後の取り組み まとめ 組織の課題 業務効率化 プロダクトエンジニアリング部では、ユーザーへの価値をより早くより良く提供するために、常に業務プロセスの効率化を検討しています。 KPIマネジメント を元に、どのような作業がボトルネックになっているかを適宜洗い出しながら着実に進めていきます。 ボトルネックの分析から「データベースからのデータ取得業務（SQL作成）に割いている時間が長そう」という結果が見えており、削減を検討していました。 コミュニケーション活性化 LIFULLでは部署やチームの結束を高めるために「総会」という形での場作りを行っており、プロダクトエンジニアリング部2ユニットでも月に一度のユニット総会を開催しています。 リモートワーク中心での業務では直接会話する機会も少なくなっているため、グループを超えたコミュニケーションの活性化は組織の課題となっています。 両立のための取り組み そこで、（「業務効率化」につながる）SQLを作成するコンペを、（「コミュニケーション活性化」のために）ユニット総会の場で行うことにしました。 チームに分かれて、制限時間内に完成したSQLの数で競ってもらうことにします。 開催の準備 過去にあったデータ抽出の依頼やほかの職種のメンバーへのヒアリングを元に、「あれば今後の業務が楽になりそうなSQL」をイメージして作問しました。問題として成果物に期待される条件と、カラム名を与えるようにしています。 問題のサンプル 最終的に30問程度の問題を用意しましたが、すべての回答を用意するのは難しく（むしろ用意すると開催の意味がなくなるため）、正解は成果物の内容から軽いチェックで判断することにしました。※成果物のレビューについては後述します。 コンペ当日の流れ 開催が12月後半だったこともあり、グループを紅組と白組の2チームに分けて競ってもらう形式で実施しました。 参加者は人数が多かったため、チーム内でMeetでの部屋の分割やSlackのハドルを活用した分担を行いながら進めてくれていたようです。社歴でバランスを取ってペアを決めたり、「新築マンション関連は詳しいので任せてください」というような強みでチームをリードしたり、各チームで効率を考えながら取り組めていました。 開催の成果として多くのSQLができあがり、隣の部署のメンバーとの会話の機会も作れたことで、当初の目的は達成できたと感じています。 その後の取り組み さまざまなデータを取得できるようにはなりましたが、「なぜこのテーブルから取得するのか」「なぜこの条件を絞るのか」という疑問が解消しきれていない箇所もあります。 そのため週に一度有志のメンバーが集まり、完成したSQLを一つずつ紐解きながらLIFULL HOME'Sの知識を蓄積していく勉強会を行っています。この会はレビューも兼ねており、これにより正確にデータを抽出できるしくみが整ってきています。 まとめ SQL作成のコンペを通して、「業務効率化」と「コミュニケーション活性化」の両立に取り組んだ事例について紹介しました。今後もより良くユーザーへの価値提供を行っていくために、無駄を省き本質に集中できるしくみを作っていきたいと思います。 最後に、LIFULL ではともに成長していける仲間を募集しています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの中島です。 現在はアクセシビリティ推進グループ（以下推進グループ）に在籍しています。 以前同組織の紹介記事をいくつかあげましたが、その通り弊社は自社の運営するサービスをアクセシブルにするため日々奮闘しています。 www.lifull.blog www.lifull.blog 以前の記事ではどういったマインドで同組織ができたか、どのように推進しているかについて話ました。 今回は、そういった活動の中でいくつか技術的な副産物が生まれたのでその話をしようと思います。 キーボード操作編 CSSの概念距離 さいごに キーボード操作編 アクセシビリティ対応にあたって、基本的なやることの一つにUIをキーボード操作可能にするという作業があります。 自社のサービスにもキーボード操作不能ないくつかのUIの存在を認識しており、それらを実際に直していくということをしています。 修正時、場合によってはJavaScriptを記述する必要があるのですが、それにあたって我々の採用しているStimulusというライブラリに若干の不満がありました。(概ね気に入っています) それはHTML側からみて宣言的に記述することを良しとする同ライブラリの指針に対してキーボードイベントのハンドラを宣言的に記述することが難しいというところにあります。 Stimulus3.1まではキーボードイベントにフックして何らかの処理を記述する場合、以下のように書きます。 < button type = "button" role = "tab" data - action = "keydown->tab#moveLeft keydowon->tab#moveRight" > タブ1 </ button > // tab_controller.js ... moveLeft(evt) { if (evt.key !== 'ArrowLeft' ) { return ; } // タブを一個左に切り替える } moveRight(evt) { if (evt.key !== 'ArrowRight' ) { return ; } // タブを一個右に切り替える } keydownが発生した時にmoveLeftとmoveRightが動くというところまではHTML側から理解できますが、この実装では、"どのキー"を押した時に動作するふるまいなのかまで説明されておらず、読み手の関心はJavaScriptの実装にまで到達してしまいます。 これに不満を感じていたのでStimulus自身に本件のIssueとPRをなげて3.2で取り込んでもらうに至りました。 github.com stimulus.hotwired.dev これによりStimulusでも今までより宣言的に記述できるようになり、UIのふるまいに対する関心をHTMLに封じ込めることができるようになりました。 < button type = "button" role = "tab" data - action = "keydown.left->tab#moveLeft keydowon.right->tab#moveRight" > タブ1 </ button > CSSの概念距離 UIの修正は時にはHTML, JavaScriptだけでは完結せず、CSSの修正が必要なケースもあります。 ただ、長年運用され続けている巨大なサービスにおいては、思いもよらぬ依存と向き合わなければならないこともあります。 AというUIを直そうとしたら、それがBというCSSに依存していて、さらにそのBはCという別のページのよく似たUIにも適応されていて...といった厄介な依存です。 少しの深さの依存なら把握できても、とても深い依存になるとなかなか一筋縄ではいきません。 これはHTMLとCSSの概念距離が開いているが故に起きる問題です。 world.hey.com qiita.com 両者の距離が開くことで片方がまた別の何かとの依存を起こしやすくなっているのです。 恥ずかしながらいくつかの実装にあたってこの依存起因で表示崩れを起こしてしまい、緊急対応を行いました。 そうしたことをしているうちに、継続的に直していくには(これはアクセシビリティ対応だけにとどまらず)この概念距離をなくしていかないとニッチもサッチもいかないなと感じました。 そこでこの概念距離をなくしてHTMLとCSSがぴったり一対一で対応するようにTailwind CSS(UtilityCSSのライブラリ)を導入しました。 tailwindcss.com こぼれ話のこぼれ話ですが、導入にあたり、サイト内でベースとなるfont-sizeが100%だったり62.5%だったりと揺れていた問題が浮き彫りになりました。 その問題はテンプレートを再起的にパースして62.5%の適用されたテンプレートで参照されているCSS、そうじゃないCSSを分類し、CSSパーサでtransformをかけて単位を合わせるといったことをして乗り越えました。 Tailwind CSSはスタンドアロンでも動作するようになっており、わざわざ利用者側がPostCSSを導入しなくても、内包しているPostCSSを利用して動作させることができます。 メンテナンスコストの面から考えて、なるべくパーサ系ライブラリとの依存を小さくしたいと考え、このスタンドアロンな挙動にのっかりたいと考えました。 しかし、リリースにあたって、キャッシュバスティングの機構も同時に必要だったので、Tailwind CSSが内包しているPostCSSにキャッシュバスティングの手製プラグインを適応させたところうまく動作しないことがわかりました。 キャッシュバスティングとは ブラウザがキャッシュされた古いファイルを参照し続けないようにするための機構 (パスやクエリにファイルのダイジェスト値を入れたりするケースが多い) ソースを読んでみたところ、どうやらTailwind CSSは内部でPostCSSを利用しているものの、そこで最終的に生成されるファイル名情報に関しては破棄して動くようになっているようでした。 そこで、Tailwind CSSに対して内包するPostCSSで生成されたファイル名情報を尊重する実装をPRで提案したところ、数日のうちに取り込んでいただけました。 github.com こちらはTailwind CSS 3.2.5で搭載される予定になっています。 さいごに 何か作業するにあたっていくつかの困難と向き合い、そちらに作業がスライドしていくyak shavingはエンジニアの宿命なのかもしれません。 いろんな作業を通してスパイラル的によりよい改善が行えるとよいなと思います。 最後までお読みいただきありがとうございました。LIFULL では共に働く仲間を募集しています！ hrmos.co hrmos.co

AI戦略室の嶋村です。私はAI戦略室のエンジニアマネージャを担っておりますが、 イノベーションマネジメント委員会（IM委員会） という委員会活動にも参加しています。今回は、IM委員会で取り組んでおります 新規技術の蓄積を促進するための活動 について、投稿したいと思います。 弊社LIFULLは社是で「 利他主義 」を掲げている 社会課題解決型企業 であり、コーポレートメッセージで表明している「 あらゆるLIFEを、FULLに。 」の実現を目指しています。その実現に向けて、どのような社会課題を解決していくのか、弊社の取り組みを「 LIFULLアジェンダ 」として公開しています。複雑な社会課題を解決していくためには、社会課題が生まれる社会構造や原因を深く理解することはもちろんのこと、 解決に必要な技術を適用 していく必要があると考えています。必要な技術は一朝一夕で獲得できるものではないため、 継続的に新たな技術を獲得・蓄積 していき、イノベーション創出につなげていく必要があると考えています。 イノベーションマネジメント委員会「技術蓄積チーム」とは イノベーションマネジメント委員会（IM委員会）は「 イノベーション創出サイクルを加速させるエンジン 」の役割を担っており、小さな改善のみならず 非連続的な大きな革新・革進 をもたらすイノベーションを創出する文化の醸成に取り組んでいます。 そのIM委員会では幾つかのチームが連携をして イノベーションマネジメント体制の構築 を進めており、私は新規技術の蓄積を進めるための「 技術蓄積チーム 」を担当しております。この「技術蓄積チーム」は、 　 「社会課題や事業課題の解決につながる新規技術を獲得・蓄積・共有する文化を醸成する」 ことを目的として、新規技術の蓄積を促進するための活動に取り組んでいます。 多くの社員が新規技術を実際に触ってみて獲得し、それを事業で使える形で蓄積し、他の社員がその技術を利用できるように共有していく、という流れを作っていきたいです。 Social Innovation Forumで注目された技術 弊社では、社員一人ひとりが社会課題について向き合い、 課題解決に向けたアイデアを技術と掛け合わせて発想するための知的交配の場 となる「 SOCIAL INNOVATION FORUM 」（ SIF ）を開催しています。 技術蓄積チームは、このSIFの中で社員のアイディエーションを促進するために、 社内外の新規技術をまとめた「テクタスシート」 と呼ぶシートを作成して社内公開しました。どのような技術なのか、 その技術で何ができるのか 、を平易にまとめており、非エンジニアでも理解できるように仕上げました。 SIFのアイディエーションで、社員が課題解決するために活用する技術を選ぶワークがあるのですが、その際に選ばれた技術がどのようなものか簡単にですが紹介します。 前々回で 主に注目が集まっていた技術 は下記の通りです。 AI技術 レコメンド技術 これらの技術に注目が集まるのは AI戦略室の一員としては嬉しい結果 ですが、"AI"や"レコメンド"という広い言葉に 過度な期待が集まっている表れ でもあり、何でもできる魔法のツールとして考えられていないかと複雑な心境もありました。 一方で前回のSIFでは前々回と異なり下記の 新たな技術に注目 が集まりました。 Web3技術 XR技術 ヘルステック技術 Web3技術 や XR技術 については、メタバース・DAO（Decentralized Autonomous Organization）・NFT（Non Fungible Token）といった 新しい概念への期待 が高まっていると感じます。仮想現実が当たり前のようになると、物理的な制約に縛られることなく、 いつでもどこでも誰とでもつながることができる世の中 になるかもしれません。 ヘルステック技術 については、私自身もコロナ禍で在宅勤務が中心となった後、運動不足・体力不足に陥り、ヘルステックへの興味が強くなりました。私事で恐縮ですが、現在はウェアラブルデバイスを身に着けて運動量を計測し、1日の目標消費カロリーを決めて、それを超えるようにウォーキングを継続しています。健康第一という言葉があるくらい、健康は重要なテーマであるため、 健康維持は大きな社会課題の一つ だと感じています。 IM技術蓄積レポート もう一つの取り組みとして、 社会課題や事業課題に関連する新規技術 について、IM技術蓄積チームが 週1回の頻度で社内発信 する「 IM技術蓄積レポート 」を始めています。上で述べたSIFというイベントの時のみならず、普段から新規技術に触れていただき、技術蓄積を促進するねらいです。 なお、ここで記載した「 新規技術 」とは、 世の中でも新しめの先進的な技術 世の中では既に活用されている技術だがLIFULLやLIFULL HOME'Sにはまだ取り入れられていない技術 の両方を指しています。 週1回の頻度で新たな投稿ネタを探すのは大変でもありますが、IM技術蓄積チームのメンバが交代で、 社会課題×新規技術 、 事業課題×新規技術 、 他社の最新技術情報 などなど、バラエティに富んだ発信をしています。また、継続性を重視するために毎回のレポートでは短めでも発信することを優先しています。「 継続は力なり 」とも言いますので、発信を絶やさずに興味を惹くレポートを増やしていきたいと思い、2022年12月上旬時点では Vol.11まで発行 しています。 これまで私は「SIFで注目が集まった技術の紹介」・「新規技術に関する情報源の紹介」・「サッカーW杯のVAR（Video Assistant Referee）を支える技術に関する考察」というテーマで発信をしてきました。私は社会課題解決への興味が強いため、今後は社会課題に対してどのような技術が使われているのか新規技術活用の事例を中心に紹介していく予定です。 IM技術蓄積レポート おわりに 今回は イノベーションマネジメント委員会 の 技術蓄積チーム での取り組みを紹介しました。 社員の一人ひとりが新規技術に目を向けて技術を獲得・蓄積・共有し、その技術を社会課題や事業課題に適用することで課題解決をする、という イノベーション創出の仕組み化 に向けて革進を続けていきたいと思います。 最後になりますが、LIFULLでは共に成長できるような仲間を募っております。AI戦略室では データサイエンティスト や MLOpsエンジニア を募集中です。 カジュアル面談もありますのでご興味ある方は是非ご応募ください！ hrmos.co hrmos.co

LIFULL札幌開発拠点で働くエンジニアの村田です。 札幌では本格的に雪が降り始め、寒さが非常に厳しい時期になってきました。 本エントリーは、 LIFULL Advent Calendar 2022 、12月22日の記事であり、LIFULLのプロダクトの可観測性を向上させた話をさせていただきます。 背景 LIFULLではマイクロサービスプラットフォームとして内製の「KEEL」というPaaSを用意し、それを利用してアプリケーションを開発することで開発者の生産性の向上を図ってきました。 KEELについての詳しい話は以下を参考にしてください。 www.lifull.blog ログ基盤もKEELが提供する機能の一つで、当時はAWSのフルマネージドサービスであるCloudWatch Logsを利用していました。 特にCloudWatch Logs Insightの体験が良く、これを利用してアプリケーションのログを柔軟に検索することができていました。 しかし、当時のログ基盤周りでは以下の問題点がありました。 ログはCloudWatch Logs、メトリクスはGrafanaで閲覧と、ツールが2つに分かれて利用している状況だった マイクロサービス毎のログに共通IDが割り振られておらず、特定のリクエストに関連するログの調査コストが高かった CloudWatch Logsにかかる費用が増大しつつあった これらの状況を鑑みて、KEELチームはGrafana Lokiを利用し、より利便性の高いログ基盤を再構築する決断に至りました。 Grafana LokiとはGrafana Labが提供するスケーラブルで高可用性なログ集約システムです。 集約されたログはLogQLと呼ばれるクエリで柔軟に検索・集計することが可能であり、ストレージはS3などを利用して費用面でも安く抑えることができます。 grafana.com CloudWatch Logsとの比較検証 いきなりGrafana Lokiに移行しても、開発者体験が失われてしまっては意味がありません。 KEELチームでは、Grafana Lokiによるログ検索体験がCloudWatch Logsを利用していた時と変わらないか、それ以上のものを提供できるか検証する必要がありました。 まず最初のステップとして、従来のログ基盤に加え、検証対象であるGrafana Lokiにもログを書き込み、KEELチームでその体験を検証することにしました。 たとえばCloudWatch Logs Insightの以下のようなクエリは fields @timestamp, @message, @logStream | filter structural_log.status >= 499 | sort @timestamp desc | limit 20 Grafana Lokiでは、LogQLを用いて以下のように同様の表現をすることができます。 {grouping="kubernetes.ns.svc"} | json | structural_log_status >= 499 CloudWatch Logs Insightでできる以下のような集計については stats count(*) by @logStream | filter structural_log.status >= 499 検索したログから、アドホックスタティクスアイコンをクリックすることで簡単な集計結果を得ることができますし 以下のようなクエリで代替する結果を得ることができます。 sum( rate( {grouping="kubernetes.ns.svc"} | json | structural_log_status >= 499 [1m] ) ) by (metadata_pod_name) 上記のようにCloudWatch Logs Insightによるログ検索は、LogQLでほぼ代替することができ、これらの体験はGrafana Lokiでもほとんど損なわれることはないと判断しました。 Chrome ExtentionによるGrafana Lokiの体験向上 CloudWatch Logs Insightでは、fieldに@logStreamを指定することで、該当ログ付近のログを表示するリンクが生成されます。 Grafana Logにも対象ログの前後のログを表示する機能はありますが、少々使い勝手が悪く利用しづらい状態でした。 そこでKEELチームはChrome Extentionを独自に開発して、Grafana LokiのHTMLを書き換え、同等のリンクを作成することに成功しました。 具体的には、Grafana Lokiに表示されるログのtimestampをクリッカブルにして、その前後の時間帯をクエリに加えたログの検索結果に遷移できるようにしました。こうすることでCloudWatch Logs Insightの@logStreamと同じ体験を実現することができました。 このChrome Extentionはこれだけの利用にとどまらず、後述するTraceIDを利用したログ検索への導線を作成したり、エラーログに書かれるスタックトレースからGitHub上の該当コードに飛べるようにするなど、色々応用することができました。 TraceIdの埋め込み さらなる体験向上を目指し、KEELチームが次に行ったのは、LIFULL HOME'Sへのリクエストに共通のID(TraceId)を割り振り、後続のマイクロサービスにそれを伝播させることでした。 LIFULL HOME'Sは複数のマイクロサービスで構築されており、それぞれのマイクロサービス毎にロググループができていたため、マイクロサービスを横断した関連ログの検索が非常に手間のかかる作業でした。 特定のリクエストに関連したログ全てにTraceIdを付与することで、複数のサービスに散らばったログを横断で絞り込むことができるようになります。 KEELでは、以前からログに共通IDを付与する運用を開発者に推奨してきましたが、LIFULLの主要サービス含めあまり徹底されていませんでした。結果、ログの検索に手間がかかることに繋がっており、これは従来のログ基盤自体の問題というよりは、ログの運用方法の問題といった方が正しいです。 今回のログ基盤刷新を機に、この辺りの運用もしっかりと整備することにしました。 OpenTelemetryを導入することで、比較的容易にTraceIdの伝播を行うことができます。 opentelemetry.io アクセスログだけでなくエラーログにも可能な限りTraceId等を埋め込み、特定のリクエストと紐付けられるようにしました。 対象となるマイクロサービスの数は少なくはなかったものの、各部署の開発者と協力し作業を進めることで、ほぼ主要なサービスへのTraceIdの導入が終わり、IDによる関連ログを横断検索する体験を提供できるようになりました。 ここでも前述したChrome Extentionを利用し、ログに記載されているTraceIdをクリッカブルにして、TraceIdのリンクを辿るだけで容易にログの絞り込みが行えるようにしました。 リクエストのトレーシング TraceIdを導入した副産物として、リクエストの分散トレーシングも可能になりました。 以下は、とあるリクエストをトレースした結果になります。ツールはGrafana Tempoを利用しています。 特定のリクエストに対して、裏ではどのサービスが何回呼び出されてそれぞれどの程度時間がかかっているかが視覚的にわかるようになりました。 リクエストのトレーシングができるようになったことで、ボトルネックとなっているサービスが特定しやすくなり、サイトのパフォーマンスチューニングが捗るようになります。 実際、サイトの高速化をはかるPJのメンバーがこの機能を利用することでパフォーマンス改善に役に立ててくれていました。 ログ基盤の切り替えの障壁を下げるために ある程度ログ基盤の並行運用期間を経て検証を重ね、十分に代替できると判断したタイミングで、CloudWatch Logsへのログの転送をストップし、ログ基盤を切り替えました。 CloudWatch Logsから新しいログ基盤に切り替わることで多少なりとも開発者に学習の負担がかかるので、そのコストを最小限にするためにKEELチームではチュートリアル動画を用意しました 1-2分程度の動画の中で、ログ基盤の検索のチュートリアルを行うことで、すぐに開発者がGrafana Lokiを使いこなせるイメージがわくようにしたのです。 この工夫もあってか、特に大きな混乱もなく開発者は新しいログ基盤を利用してもらえることができています。 加えて、ログ基盤を切り替えたことにより従来のログ基盤にかかっていた費用の約70%を削減することができました。 CloudWatch Logs関連費用のうち、その大半を占めるのがPutLogEventsであり、今回のログ基盤の移行でこのあたりの費用がすべてカットできたのが大きな要因です。 これは年間で換算するとかなり大きなコストカットになり、LIFULLのビジネスにも大きなインパクトを与えることになりました。 まとめ CloudWatch Logsによる従来のログ基盤をGrafana Lokiに移行した話を紹介させていただきました。 移行後は、Observabilityを構成する要素である、メトリクス、ログ、トレーシングの全ての情報がGrafanaで参照できるようになりました。 さらにGrafana LokiとChrome Extentionを組み合わせることで、CloudWatch Logsと同等、それ以上の体験を開発者に提供できるようになり、LIFULLのプロダクトの可観測性が向上しました。 フルマネージドサービスに比べるとGrafana Lokiを自前で運用する必要があるため、その分の運用コストは増加したものの、上記の体験に加え金額面での大きなコストカットメリットもあり、ログ基盤の移行は大きな価値があったと思っています。 今回お話しさせていただいたログ基盤だけでなく、KEELチームの様々な取り組みを別エントリーで紹介させていただいていますので、ご興味のある方は以下のエントリー一覧をご覧ください。 www.lifull.blog 最後に告知です。LIFULLでは、「あらゆるLIFEを、FULLに。」に実現を目指して共に働いていただける仲間を募集しています。 カジュアル面談という形で、まずは気軽に情報交換、ということも可能ですので、ご興味がある方は以下のページをご覧ください。 hrmos.co hrmos.co

フロントエンドエンジニアの嶌田です。アクセシビリティ推進グループに所属し、社内のプロダクトのアクセシビリティを高めるために日々奮闘しています。 LIFULL HOME'S は不動産・住宅情報の総合サービスです。住宅や住み替えに関する多くの情報を取り扱っており、サービス全体の規模はかなり大きいといえます。 レスポンシブデザインに対応したヘッダ・フッタの制作については以前に公開した記事で取り上げました。2022年5月から10月にかけて行われた今回のプロジェクトは、このヘッダ・フッタを LIFULL HOME'S サービス全体に展開することで、四散しているヘッダ・フッタを統合・刷新する ことを目的としたものです。 www.lifull.blog ヘッダ・フッタの統合・刷新により、サービス全体のアクセシビリティが向上し、キーボードやスクリーンリーダーのユーザーにとって利用しやすくなりました 。改善の内容をいくつか取り上げて解説します。また、追いかけているアクセシビリティスコアが向上し、コードレベルの内部品質も高まりました。 よくなったところ 1. レスポンシブデザインへの対応 2. キーボード操作・スクリーンリーダー対応 3. スキップリンク機能の搭載 4. ランドマークによるジャンプが可能に 効果測定 たいへんだったところ 根気の A/B テスト SEO リスクとの闘い 膨大な作業量 刷新を終えて よくなったところ 1. レスポンシブデザインへの対応 旧デザインと新デザインの比較。旧デザインは構成が何パターンもあり、デスクトップとモバイルでは体験も異なっていた。 現時点では、LIFULL HOME'S の多くのページはデスクトップとモバイル向けに別々の HTML を出力しています。ヘッダとフッタも別々のものが使われており、ナビゲーションの項目や使い勝手はデバイスやサービスごとに異なっていました。 新しいヘッダ・フッタはレスポンシブデザインを前提にデザイン・実装されたため、一貫性のあるユーザー体験が提供されるようになりました。 2. キーボード操作・スクリーンリーダー対応 これまでのヘッダ・フッタは一部の機能がキーボードやスクリーンリーダーだけでは利用できないことがありました。 旧デザインのヘッダをキーボード操作している様子。閉じられているはずのハンバーガーメニューの中身にフォーカスがあたり、フォーカスが見えなくなっている。 非表示のコンテンツにフォーカスが当たってしまう クリックできるボタンにフォーカスが当たらない メニューを開いたときにフォーカスがどこに行ったか分からなくなる ページ下部の「ページトップへ戻る」ボタンを選択したときにフォーカスがページ下部に残り続けてしまう これらの問題は新しいヘッダ・フッタで解消され、キーボードやスクリーンリーダーでも不自由なく操作できるようになりました。 3. スキップリンク機能の搭載 スキップリンク機能 新しいヘッダにスキップリンク機能を実装しました。スキップリンクは初期状態では隠されていて、ページを開いたあとキーボードの Tab キーを１回押すと表示されます。キーボードやスクリーンリーダーの利用者はページを開いた後、ナビゲーションを順番にたどってメインの領域にたどり着く必要があります。スキップリンクがあることでその手間を大きく省略でき、利用しやすさが向上します。 4. ランドマークによるジャンプが可能に スクリーンリーダー NVDA のランドマークを一覧する機能のスクリーンショット。ヘッダ・メイン・フッタの領域が検出されている。 ランドマークとは、ページの主要な領域を特定の役割として明示したものです。新しいヘッダ・フッタにランドマークが付与されています。これにより、スクリーンリーダーのジャンプ機能を使うと、ランドマークとして示された領域までショートカットしてアクセスできるようになりました。 効果測定 私が所属する組織はアクセシビリティ推進グループといい、LIFULL のプロダクトのアクセシビリティを高めることをミッションとしています。取り組みの効果を測るため、部署で独自に定めた採点基準を用いて、プロダクトのアクセシビリティスコアを定期的に計測しています。 スコアリングは Lighthouse による自動テストに加え、自動化できない項目を手動で検査した結果を用いて算出しています。スコアリングの詳細については中島による記事を参照してください。 www.lifull.blog ヘッダ・フッタを統合・刷新した結果、サービス全体のアクセシビリティスコアが底上げされ、平均スコアが向上しました。 サイト 導入前スコア 導入後スコア スコア増減 モバイルサイト 68.3 81.4 +13.1 デスクトップサイト 72.6 79.7 +7.1 あくまでも効果を定量化するための指標ですので、スコア向上の割合が使い勝手の向上の割合とは必ずしも一致しない点には注意が必要です。 たいへんだったところ 根気の A/B テスト 入居希望者からの問合せ数の上下は弊社のビジネスにおける重大な関心事項です。ヘッダ・フッタの改修は影響範囲が非常に大きいため、もし問合せ数が下がった場合の売り上げへのインパクトもまた大きいものになります。 リスクを避けるため、A/B テストを通じて問合せ数への影響を慎重に判断することになりました。A/B テストは必然的にコード上に条件分岐を増やすものであり、テストの項目数も膨れ上がるため、特に今回のような影響範囲の広い改修では極めて根気のいる作業になります。にもかかわらず、担当だった中島は苦しみながらも完遂してくれました。 A/B テストの結果は「特に良くも悪くもなっていない」でした。忘れずに A/B テストの後片付けをして正式リリースにこぎつけました。 SEO リスクとの闘い 問合せ数と同じくらい重要視されているのが検索エンジンでの表示順位です。LIFULL HOME'S には多くのユーザーが検索エンジンから訪れるため、平均でひとつ表示順位が下がるだけでも訪問者数には多大な影響があるのです。 ページ全体の文書構造に変化があったため、今回の改修にはリスクがあるとみなされていました。これまでは原則として、ページあたりひとつの h1 要素を持っていました。新しいヘッダではロゴが h1 要素でマークアップされたため、ページあたり 2 つの h1 要素を持つことになります。h1 要素は検索ロボットによるページの評価に影響を及ぼすと考えられているため、リスクだと考えられました。 ハンバーガーメニューの中身が構造化されており見出し要素を使いたかったために、ロゴを h1 にする必要があったのですが、潜在的な影響の大きさを考えると慎重になる必要がありました。SEO の専門知識のある方に意見を伺い、問題なさそうだというお墨付きをもらったうえで、リリース後は１ヵ月ほど検索結果を監視し順位の大幅な変動がないことを確認しました。 膨大な作業量 これまでのヘッダは長年の運用の結果、表示パターンが増殖し一元管理とは程遠い状態でした。表示パターンを洗い出し、新しくどのパターンに当てはめるかを判断し、必要に応じて該当の事業部との調整を根気強く積み重ねる必要がありました。ここは企画の鈴木が途中心折れそうになりながらも完遂してくださりました。感謝しかありません。 コード上の変更箇所もおびただしい量にのぼりました。特に、フッタに並ぶ多数のリンクは一部、サービスによってはリンク項目とリンク先が変動するという地味に HP を削ってくる要件がありました。目視によるレビュー、手動によるテストをやりつくすには限界があったため、アドホックな自動テストスクリプトを書き、変更前後の HTML を比較することで切り抜けました。 刷新を終えて 今回展開された新しいヘッダ・フッタはもともとサービス全体に展開する予定はありませんでした。部署としてプロダクトのアクセシビリティを向上していくモチベーションがあり、タイミングよくサービスのユーザー認証基盤が新しくなったことで推進力を得て、ヘッダ・フッタを展開することになりました。 全体に手を入れるならば今こそと、ついでにほかのアクセシビリティ改善やコード上の負債も改善できました。結果としてユーザーのみなさまには、これまでよりアクセシブルで一貫性のあるユーザー体験を提供できるようになったと考えています。 置き換え作業は一筋縄ではいきませんでした。調整コスト・実装コストがかさんだ要因の一つに、長年引き継いできた SEO 由来の要件から脱却できなかったことが挙げられそうです。これまでサービスに投入されてきた SEO 施策群は、数年経た後にその効果が振り返られることはなく、リスクを恐れて取り下げられることもありませんでした。SEO 要件は、積み重なってアンタッチャブル化してしまわないように、少しずつ効果を再検証しながら固着を引きはがしていく地道な作業が必要なのだと感じました。 今回のリプレイスで私（嶌田）はコードレビューとしてのみ参加し、調整や実装の大半は企画の鈴木、エンジニアの中島によって行われました。💗をこめて実装したヘッダ・フッタを、会社の目玉サービスに展開してくださったお二人には感謝してもしきれません。 お読みいただきありがとうございました。LIFULL では共に働く仲間を募集しています！ hrmos.co hrmos.co

はじめに こんにちは。 今年の4月からLIFULLでエンジニアとして働いている佐藤です。 お題にもある通り、僕は 文系出身 プログラミングスクール出身 です。そして、まだプログラミングに対して苦手意識があります。 前提としてスクールに通うまではプログラミングスキルの土台はゼロでした。スクールでは平日10時間を半年間勉強し、たくさんプログラミングを学びましたが、理解も遅く、ずっと苦手意識がありました。 しかし、「どうしてもやってみたい」という思いと、将来やりたいことを実現するためにはプログラミングスキルが必要だと思ったので今も続けています。 技術力が高い先輩・同期の中でついていけるか、その中で大切なプライベートの時間を取れるか不安なところもたくさんありました。 そんな僕が、LIFULLで6ヶ月間働いて体感したことを感じた通りに書いていきたいと思います。 結論から言うと、LIFULLはとても良い会社です。良いと思ったポイントを紹介していきます。 安心できる環境 ■ 入社前の定期的な集まり 会社側の企画として、人事の方＆同期と月1くらいで集まってワークショップや懇親会をやっていました。 互いのことを全く知らない状態からだったので、自己紹介・目指していることなど幅広く互いの中身を共有していました。 ワークショップを通して、同期それぞれの特性もわかるようになり、信頼と仲の良さが少しずつ増していったと思います。 入社以降は、それまでの生活環境・リズムが変わり、ストレスが掛かることは間違いない中で、同期との関係性が少しずつ築けていたのは安心を得る上でとても大きかったです。 ■ 研修 初めの数ヶ月は研修（人事研修とエンジニア研修）がありました。 エンジニア研修では、毎日朝会で1人、自由なテーマで発表する時間がありました。 テーマの中には、好きな自己分析の手法、自己流の健康法、麻雀の勧誘などの発表がありました。笑　 その人の仕事以外の興味関心・人となりが発表を通してより深く知ることができました。 技術的な部分では、僕が一番理解が遅く質問をたくさんしていた自負がありますが、研修担当の方が本当に教えるのが丁寧で、わからないところが無くなるように一つ一つ教えてくださいました。 配属前に同期との関係性も深まり、技術面は少し自信がつくようになり、安心してスタートできる準備期間が過ごせていました。 ■ コミュニケーションの機会（業務以外のことも話す機会） LIFULL は社員同士でのコミュニケーションの機会が非常に多いと感じます。業務内容に限らないコミュニケーションの機会がたくさんあるため、関係性が築きやすく、業務における心理的安全性が高まると感じています。 以下は、具体的な例です。 ↓ 集まりの名称(人数・人、頻度) 朝会（10人、週2） 1on1（メンターの方、週2~3） 1on1（上長の方、週1） 新卒 START（自部署以外の先輩エンジニア2 人(ご飯)。全3回） コミュデイ（グループの約6人、週1(オフィスで対面で仕事)） グループの定例（グループの約6人、週1） ユニットの定例（ユニットの約10人、月1） チームビルディング（ユニットの約10人、PJ ごとで開催の有無決める） ※グループは最小単位の組織で、ユニットがその上の段階の組織です。 コミュニケーション予算としてランチ代を会社負担してもらえることもあります。会社の制度として社員同士のコミュニケーションを促進してくれています。 自由な制度 ■ 働く時間 コアタイムの11:00~16:00で働いていれば、7:00~22:00の間で自由に出勤・退勤 その月の 1 日平均が8時間になるようにすれば OK 具体的に自分がやっていたこと（一部） 7:30から勤務開始 16:00退社 LIFULL では、この制度を使って先輩が自由に出勤・退勤しているので、気兼ねなく使うことができました。人との予定も組みやすく、非常に融通のきく働き方ができました。 16:00退社は小学生の下校と同じくらいです。笑 ■ 働く環境 リモートワーク週4＆週1出社 リモートワークは、自分好みにできるので良い環境を作れます。 リモートワークが多いので、他県の実家で働く日も多くありました。場所の制約がないことはとてもありがたいです。人によっては数日ごとに旅行気分で働く場所を変えて働いていました。PC1台でできるエンジニアの恩恵がリモートワークと素晴らしくマッチしています。 多様なオフィスの仕事環境(一部)は以下の通りです。 フリーアドレス（社内どこを使っても OK） 高級で座りごごちの良いワークチェア 各座席にモニターが設置 スタンディングデスク 自由に使える会議室 下記リンクよりオフィスの様子が見られます。 https://recruit.lifull.com/office/ リモートワークするのが勿体無いくらいに、オフィスの働く環境は整っていると感じます。 週1の出社がちょうど良いリフレッシュになります。 「人が良い」という噂は本当だった 入社前に「LIFULL で働いて良いと思うことはなんですか？」と質問すると、体感100%の皆さんが「人が良い」と言っていました。 実際に働いてみて、「本当に人が良いんだな〜」と体感するようになりました。 具体的にどう人が良いかというと 感情的に怒る人がいない 先輩が細かく助けてくださる 質問したらガッツリ時間出してくださる 率直な発言の裏に「もっと良くするために」と言う思いを感じる そして、こういう人たちが集まっているのは何故かと考えた時に、「上層部の人たちが本気で経営理念、社是、ガイドラインを大切にしているからだ」と思うようになりました。 lifull.com 上長も、上層部の人たちも、「経営理念・社是・ガイドライン」を本当に大切にされていることを業務でのアドバイス、1on1、総会などを通して感じます。 だからこそ、会社全体として「経営理念・社是・ガイドライン」を大切にするようになり、採用される人（周りのLIFULL社員）もそれに相応しい人になるのだなと理解するようになりました。 さいごに まだたったの6ヶ月＆LIFULLしか知らない側面はありますが、とても良い環境で働かせていただいているなと思います。スキルも浅い僕ですがなんとかついて行かせてもらってます。 「経営理念・社是・ガイドライン」を本気で大切にしている企業だからこそ、社員を大切にして制度も環境も改善しているのだと感じました。「根本的に何を大事にしているか」によって、集まる人もつくられる制度も雰囲気も変わっていくのだなと思います。 LIFULLのガイドラインには、社会人だけでなく人として大切な要素がぎっしり詰まっています。1つ僕が好きなものを紹介させていただきます。 「真理を追求する」 ー私たちが考える真理とは、あらゆる人が心から良いと共感できることです。その真理を問い、考え、行動し続けます。ー 僕はこのガイドラインの実践を通して、スキルはもちろんですが、誠実さ・真実さを磨き人間としての成長を第一にしていきたいです。具体的には、目の前の仕事に対していつも「本当にこれが最善か？」と問い続けて、自分の心に嘘をつく事なく働いていきたいです。そのように働くならば必然的に必要なスキルもついてくると信じています。 少し成長した頃に、またブログを書けたらと思います。 読んでいただきありがとうございました！ 一緒に働きませんか？ LIFULLでは共に成長できるような仲間を募っています。よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

LIFULL で 売却査定サイト の開発をしている、ジョン ヨンソクです。 この記事では、15 年間稼働しているメール配信バッチから非同期メール配信システムへのリプレイスをどのように行ったかについての共有をします。 また記事の最後では、この開発に挑むときの自分の考え方、感想なども記しました。 リプレイス背景 使用技術 Serverless Framework 設計図 処理の流れ 匿名査定完了 → AWS SNS → AWS SQS → AWS Lambda(メール配信) 同一メールの複数回配信の防止 匿名査定完了したら、Amazon SNS トピックにメッセージを発行 SNS 経由で SQS にキューを投入 SQS をトリガで Lambda を実行 SQS のメッセージの情報で、社内 API サーバからメール本文に必要な情報を抽出 メール送信サービス　 Customers Mail Cloud（CMC） 査定可能会社ごとにメールの本文を作成する パラメータ to の使用例 メール文面の使用例 メール送信失敗 cmc にリクエストするときのパラメータが不正の場合 cmc 側での配信失敗 結果 挑戦 開発に臨む時の考え方、意識したこと まとめ PR リプレイス背景 既存では不動産匿名査定 *1 依頼がユーザーからあった際、その通知を査定依頼受付している各不動産会社に通知している仕組みが、1 時間に 1 回起動するバッチアプリケーションとして稼働していました。 不動産匿名査定の通知メール配信バッチは今から 15 年ほど前に作られたものです。 そこからほぼ手を入れられずに運用していたため、 インフラメンテナンスの度に再実行を手動で行う必要があり、運用負荷の高いものとなっていました。 運用コスト削減や、不動産会社が依頼後即配信となり対応しやすくなるメリットを見込んで、 1 時間に 1 回送信だったものを依頼後即送信するようにリプレイスをしました。 使用技術 Email 送信サービス: Customers Mail Cloud 言語: JavaScript AWS アーキテクチャ: SNS, SQS, Lambda, CloudWatch Deploy Tool: Serverless Framework Test: jest 静的コード分析: ESLint ci/cd: GitHub actions Serverless Framework Serverless Framework （以下 sls）は、Node.js を使用して記述された無料のオープンソース Web フレームワークです。 sls でコード化すると AWS アーキテクチャを AWS 管理画面から設定をする必要が無くなるので、テストと本番環境で設定が異なる状態になりにくいメリットがあります。 インフラ開発と運用コスト面でもメリットがあって、すべての AWS アーキテクチャは sls で開発を行いました。 設計図 設計図 処理の流れ 匿名査定完了 → AWS SNS → AWS SQS → AWS Lambda(メール配信) 一般的な Amazon SNS シナリオで実装しました。 docs.aws.amazon.com 匿名査定が完了した場合、ユーザーはメール送信処理を待たずに完了画面へ遷移されます。 裏側では、非同期的にメール送信処理が lambda で行われる仕組みにしました。 同一メールの複数回配信の防止 今回は、複数回同一のメールが配信されないようにする要件がありました。重複不可の場合は SQS の標準形式よりも FIFO の方が適切でした。 SQS を FIFO で使用する場合は SNS も FIFO である必要があるため、SNS、SQS 両方 FIFO で作成しました。 うまく重複除外が行われるためには、ユニークな値を重複除外 ID に指定する必要があります。 今回は査定情報にあるユニークな ID を重複除外 ID に指定して、重複送信が防止できるようにしました。 docs.aws.amazon.com 匿名査定完了したら、Amazon SNS トピックにメッセージを発行 ユーザーが 不動産売却匿名査定サイト で査定依頼を完了した時の SNS に渡す各メッセージは、 最大 256 KB のデータを含める ことができるため、社内 API サーバへのリクエストに必要な最低限の情報のみ渡すようにしました。 SNS 経由で SQS にキューを投入 SNS 経由で SQS にキューを投入するためには SNS トピックへサブスクライブをする必要があります。 以下のように SQS の ARN を設定すると、サブスクライブを設定できます。 # SNS resources: Resources: Topic: Type: AWS::SNS::Topic Properties: FifoTopic: true Subscription: - Endpoint: ${ SQSのARN } Protocol: sqs TopicName: ${ TopicName } docs.aws.amazon.com SQS をトリガで Lambda を実行 Lambda は SQS をトリガするようにします。 SQS をトリガにするとメッセージが入り次第、Lambda が実行され、メールで通知ができます。 sls で Lambda のトリガを設定する場合は SQS の arn を指定する以外も複数の方法がありますので、詳細は docs をご参考ください。 functions: sendAnonymousOrderMail: # SQSをトリガにする events: - sqs: arn:aws:sqs:region:XXXXXX:MyFirstQueue www.serverless.com SQS のメッセージの情報で、社内 API サーバからメール本文に必要な情報を抽出 メール送信に必要な情報を SQS から得た情報を利用して、社内 API サーバから必要な情報を抽出する必要がありました。 社内の API サーバと疎通ができるように VPC、subnet の設定を行いました。 以下は sls 上で VPC、subnet の設定例を簡単に記載しました。 詳細は docs をご参考ください。 functions: sendAnonymousOrderMail: handler: functions/sendAnonymousOrderMail.handler vpc: subnetIds: [ subnetIdをArray形式で入れる ] securityGroupIds: [ securityGroupIdをArray形式で入れる ] events: ... www.serverless.com メール送信サービス　 Customers Mail Cloud（CMC） 差込み文字 を使用して、宛先ごとにパーソナライズされたメールを生成し、一括送信するしくみを提供する、Emails/bulk を使用しました。 パラメータ to に指定できる最大メールアドレス数は 1000 となっているので、一回のリクエストでメールを 1000 回分送信できます。 そのため、email 数を 1000 を基準で loop をかけてリクエストをするように実装しました。 smtps.jp 査定可能会社ごとにメールの本文を作成する 各不動産ごとにパーソナライズされたメール文面を作成して送信する処理は CMC の差込み文字を使用しました。 CMC の差込み文字は Lambda 内で実装するより工数が減り、CMC 側でロジックの処理するためリソース的にもメリットがあります。 パラメータ to の使用例 [ { "name" : "たろ不動産会社", "address" : "user1@example.com", "memberId" : "00000001" }, { "name" : "まろ不動産会社", "address" : "user2@example.com", "memberId" : "00000002" } ] メール文面の使用例 ((#name#))様（ ID ((#memberId#)) ） いつもご利用ありがとうございます。 ... メール送信失敗 設計図 の 5~9 番の内容です。 SQS キューのメッセージを 3 回数正しく処理できなかった場合、以下のように設定をしてデッドレターキュー(以下 DLQ)へ移動されるようにしました。 # SQS resources: Resources: SQSQueue: Type: AWS::SQS::Queue DependsOn: - DeadLetterQueue Properties: ... RedrivePolicy: deadLetterTargetArn: ${ DLQのarn } maxReceiveCount: 3 DLQ にメッセージが入ったことを通知用の SNS トピックにメッセージを発行するため、 マトリックス生成時に ApproximateNumberOfMessagesVisible を選択し、閾値は 1 にします。 指定した閾値を超えると CloudWatch Alarm にて SNS に publish されます。 通知用の SNS をトリガで実行される Lambda では、DLQ の障害情報メッセージを slack へ通知します。 次は、どんな場合メール送信が失敗するかについて洗い出してみました。 cmc にリクエストするときのパラメータが不正の場合 メール送信に必要な情報として空のような不正のパラメータが渡されて Lambda の処理が失敗した場合、3 回まで Lambda は再実行されるようにしました。3 回数再実行したうえ、正しく処理ができなかった場合、SQS のメッセージが DLQ に入ります。 パラメータエラー DLQ に入ったメッセージに対して、メール再送自動処理が必要な場合は DLQ をトリガにした失敗メール再送用の Lambda を実装することも可能です。しかし、追加実装せずとも、失敗時の再実行数やタイムアウトを適宜に変更することで、一時的なエラーは防げられると思います。 cmc 側での配信失敗 lambda では正常に処理が完了されたとしても、CMC 側で SMTP 通信に失敗や宛先サーバから一時的なエラーにより送信できない場合があります。 基本的に CMC では失敗時の再送機能を提供しているため、一時的なエラーなどはちゃんと再送されるようで、今現在は問題なく送信されています。 smtps.jp 結果 メール配信システムのリプレイスをしたことで、 インフラメンテナンスの度に再実行を手動で行う必要がなくなって、運用負荷が大きく削減されました。 また、不動産会社の体験としても、これまでは 1 時間に一度のメール配信だったものが、依頼後即配信となり対応がしやすくなりました。 挑戦 今まではリーダーのサポートを受けて仕様に基づいたコーディング業務をメインにしてきました。 一方、今回の開発に必要な aws と serverless framework の経験もありませんでしたし、具体的な設計した経験も独力でプロジェクトを推進していく経験もありませんでした。 また、これまでやってきたプロジェクトは 1 ヵ月以内で完了する小さなものがほとんどでしたが、今回のリプレイスは 4 ヵ月程度の比較的大きなプロジェクトでした。 今回の案件は開発経験、規模的に私にとって新しい領域への良い挑戦となりました。 開発に臨む時の考え方、意識したこと 開発難易度がこれまでに比べて上がったので、スムーズに進めるために、設計に必要な AWS アーキテクチャの知識を得られる SAA 試験の勉強をしました。 結果、試験には合格し、実際にプロジェクト途中で大きく設計が変わることもなく、順調に開発する助けになりました。 また、今回はアーキテクチャや api を選定して推進する必要があったので、非機能要件として最も意識した部分はリソース的な側面です。 たとえば、既存の処理ではバッチアプリケーションでリソースを使用してメール文面文字置換ロジックを処理していました。 既存の処理をそのまま従うのではなく、Lambda のリソースを最小限で使用するため、CMC のリソースを活用する文字置換方式に変えました。 さらに、既存の要件どおりならメール送信時に cc の設定をする必要があるため、リクエスト 1 回に 1 回送信する api を使用しなければなりませんでした。 今回の案件は大量にメールを送信するので、リクエスト回数と比例してリソース消費も増えると考えました。 問題のない範囲で既存の仕様を一部変更することにより、大量送信に向いている api に変更できました。 まとめ 本記事では 15 年間稼働しているメール配信バッチから非同期メール配信システムへのリプレイスを、どのように実装したのかについて共有しました。 LIFULL では、やってみたいと言う人の支援や背中を押してくれる風土があって、このようなアプリケーション構築において基本設計から担当し、最後まですべての改修案件を独自に推進する挑戦ができました。 加えて、周りにはプロフェッショナルな人が多く多方面で意見を求めることができて、コミュニケーションを取りやすい環境のおかげで、ただ挑戦で終わるのではなくしっかり成果を出して成長につながる経験ができました。 最後に、LIFULL では一緒に働く仲間を募集しています。この記事を読んで LIFULL に興味ができた方は求人情報も御覧ください。 hrmos.co hrmos.co PR 不動産売却の時も LIFULL HOME'S へ！ lifullhomes-satei.jp *1 : 不動産匿名査定：個人情報いらずで匿名で不動産の査定ができるサービス

はじめに Android アプリエンジニアの石井・七尾です。 今回、 DroidKaig2022 というカンファレンスに参加してきました。 この記事では 2 日間で行われたセッションの中から特に印象に残ったセッションに関してご紹介させていだきます。 DroidKaigi 2022 について DroidKaigi はエンジニアが主役の Android カンファレンスです。 Android 技術情報の共有とコミュニケーションを目的に、2022 年 10 月 5 日(水) 〜 7 日(金)の 3 日間開催します。 DroidKaigi2022 ではオンラインとオフライン両方での参加が可能になっています。オフライン会場ではスポンサー企業のブースなどがあり、セッション以外でも楽しめるところが盛りだくさんとなっています。 LINE株式会社様のブースのご紹介です！ ブースでは、「Code Review Challenge」を行っていました！ チャレンジするとグッツも貰えるみたいです🗨️ 14時からまた新たな問題が出題されるそうなのでまだチャレンジしていない方はチャレンジしてみてはいかがでしょうか✨ #DroidKaigi pic.twitter.com/4Ld4EYGm8y — DroidKaigi (@DroidKaigi) 2022年10月6日 twitter.com 株式会社メルカリ様のブースのご紹介です！ ブースで解くことができるクイズは難しいようでまだ全問正解者がいないようです😯 我こそは全問正解してみせる！という方は是非ブースでチャレンジしてみて下さい！ #DroidKaigi pic.twitter.com/Z17pY3IC7D — DroidKaigi (@DroidKaigi) 2022年10月6日 twitter.com 印象に残ったセッション 漫画アプリのメモリ改善とメモリ解析方法 speakerdeck.com OutOfMemoryException というのは積み重なって発生するため、原因解明が非常に難しいです。LINE マンガでは MemoryProfiler や leakcanary などのツールを利用した解析や監視、 MemoryUtils 等の独自クラスを作成し実装側からの都度監視することで原因の解明をしていきました。 また Android7 以下では bitmap の保持に native heap ではなく JVM heap を使う特性があることや、bitmap をメモリ上で持つ場合に ARGB_8888 方式であれば height x width x 4byte 必要になるため圧縮アルゴリズムが適用されている jpg, png 形式のファイルサイズがそのままメモリ上に乗るわけではないなど、メモリ周りで自分の知らないことがあり勉強になりました。 (石井) 社内でのモバイルアクセシビリティ推進 speakerdeck.com アクセシビリティがなぜ大切なのか、どのように開発に組み込んでいけるか、という 2 点にフォーカスした内容でした。 特に印象に残っているのが「健常者であっても一時的にアクセシビリティを要する場合がある」という点です。例えば、指を怪我した場合はボタンがうまく押せない状況になりますが、アクセシビリティを考慮した設計ならば問題になりません。また、目を開けられない状況下でも音声読み上げの機能などは十分に活用できます。 LIFULL では「利他主義」の観点からアクセシビリティが度外視されることはなく、真剣に取り組んでいると思います。このセッションを通して自分も LIFULL のエンジニアとして、もっとアクセシビリティを推進して行こうと思いました。 (石井) Jetpack Compose で Material Design 3 speakerdeck.com Material Design 3 の説明、tonal palette, Design Token などの新しく登場した概念についての解説、Material Design 2 からの移行手順と移行する際の考慮点がわかりやすくまとまった内容でした。特に tonal palette に関してはその解説だけでなく Material Theme Builder を用いて実装時の色を決めていく手順まで解説されていました。実際のプロダクトに導入をしようとしたときにも役立つものになっていました。 また、Material Design 3 への移行についてもアプリ全てを一度に移行する必要はなく、大規模なアプリはコンポーネントごとに分けて移行していくのがおすすめだと述べていて、その手順がサンプルコードをベースに解説されていたので、実際のプロダクトに導入をしようとしたときにも役立つものでした。 全体を通して Material Design 3 の導入を推進したくなるような内容になっていました。 (七尾) Compose for Desktop で始める Android 開発効率化ツールの作成 speakerdeck.com Compose for Desktop という Jetpack Compose の記述方法そのままに Desktop アプリを作ることができる UI フレームワークを用いた開発効率化の紹介とその実装解説についての内容でした。開発効率化については Compose for Desktop を用いてアプリを作成し、それによって Android エンジニアが日々の開発で抱える繰り返し作業の効率化についてでした。Compose for Desktop を選択した理由については、Jetpack Compose とほぼ同様の記述方法で Desktop アプリを開発することができるため、技術の学び直しがなく属人化も防ぐことができるためだと述べていました。 日々の開発の中で効率化のために簡単なコマンドラインツールを用いることはありましたが、UI まで作り込むような開発効率化ツールを作ることまではしたことがありませんでした。登壇者の方が Compose for Desktop はドキュメントが少なく、問題が発生しても GitHub の Issue を見て解決することがほとんどだと述べていましたが、セッションで実際のサンプルコードを用いた丁寧な実装解説がされていたので、今後開発効率化ツールの作成にチャレンジしてみようと思いました。 (七尾) Anatomy of Dynamic Colors blog.smartbank.co.jp MaterialDesign3 の一部である Dynamic color 関しての内容でした。アクセシビリティの観点から、カラースキームの生成には輝度が重要になってきます。従来の輝度を表現する色空間では色相の影響で、人間が感じる輝度は変わってしまう問題があります。そこで Google は新しく「色相、彩度、トーン」で構成される HCT 色空間を開発し、Dynamic color はこれに基づいて生成されます。 Dynamic color をアプリに適用することでユーザーに最適な色を動的に提供できますが、動的に変更して欲しくない色もあると思います。それらの意味ある色(Semantic color)は Dynamic color と組み合わせると浮いた色になってしまいます。そこで色相を Dynamic color に少し寄せて調整した Custom color を利用することでバランスの良いデザインを可能にしています。 LIFULL ではブランドカラーとしてオレンジが使われているため、実際に Dynamic color を導入していくことを考えるときに勉強になる内容でした。 (石井) Deep dive into Jetpack Compose Text AppCompatTextView や MaterialTextView などの場合 TextView に依存しています。対して JetpackCompose の場合 TextView に依存していません。 そのため TextView で実装されていてる textIsSelectable や textAllCaps などの一部 API がなくなっていたり、 includeFontPadding などの動作が不安定なものがなくなっています。そのため JetpackCompose でこれらを実現する場合にどのような実装になるのか、というところを軸に TextView , JetpackCompose Text , Layout API でそれぞれ実現したいことに対しての実装比較や、どのように実装されいるかを深ぼって聞ける内容でした。 こちらのセッションは Youtube に LIVE 配信されていて、アーカイブも残っているため興味ある方は是非見てみてください。 (石井) www.youtube.com Optimize your app for large screens droidkaigi.jp 昨今 Google が推進している Tablet, Foldable 等の大画面デバイスをサポートする上で考慮しなければならないこと、サポートするための技術的な選択肢についての内容でした。大画面デバイス対応をするには Phone アプリの体験の仮定（操作はタッチのみ、アプリが 1 画面を全て占有できる等）を考え直す必要があるため、UI も画面サイズに合わせて最適なものを配置することが求められているとのことでした。そのための段階的な対応の基準についてや WindowSizeClasses で取得できる画面サイズの状態を元にした UI の変更方法など、実装の手順まで詳しく述べられていました。 LIFULL HOME'S App に関しては Tablet に対応はしていますが、まだまだ画面サイズごとに UI を変えたり、ユーザの体験そのものが変わるような最適化までは進められていないため、今後の大画面デバイスでの使用感向上を目指す上で非常に参考になる内容でした。 実例から学ぶ Jetpack Compose のパフォーマンス改善 speakerdeck.com Jetpack Compose を導入した際に発生するパフォーマンスの低下に対する調査方法とその対策方法について解説する内容でした。パフォーマンス低下には不要な Recompose（Compose の再描画）が原因となっていることが多く、それを解決するための対策として derivedStateOf 、Compose の skippable 化、State の監視場所の変更の 3 つを挙げると共に、それぞれの適切な使用タイミングについても述べられていました。 Recompoes の発見と原因の対策についてサンプルコードを用いながらきれいにまとめられていたので、実際に Jetpack Compose を導入した際にも非常に役立つ内容になっていました。今後 Jetpack Compose のパフォーマンス低下の解消でハマった時には見直したいです。 (七尾) まとめ 初の現地での参加でした。セッション・スポンサーブースを通して最新技術やトレンド技術に触れることができ、よい刺激を受けることができました。 Jetpack Compose は LiveEdit やマルチプレビューなど開発効率がより向上する機能があります、これからもそういった機能はどんどん出てくると思います。Material Design 3, 大画面デバイス対応では、より多くの人へ UI/UX 向上という価値を提供していけます。 これらの Jetpack Compose, Material Design 3, 大画面デバイス対応は、以前から情報のピックアップはチームでできているものの、まだ取り組めていない現状です。今回の DroidKaigi では大画面デバイス対応のアプリを触る機会があったり、セッションやデモを通じて Jetpack Compose と密接に触れ合う中で、より一層導入を推進していきたいなと感じました。 最後になりますが、LIFULL では一緒に働いていただける仲間を募集しています。今回希望してイベント参加をしたように、エンジニアが成長できる機会が盛りだくさんの職場です。カジュアル面談もやっていますので、よろしければこちらもご覧ください。 hrmos.co hrmos.co

エンジニアの内藤です。LIFULL HOME'Sの売買領域を支えるエンジニアチームのマネジメントを担当しています。 私の所属している部署は職能別組織となって3年程経ちます。 専門性を高め開発力を向上させることで、価値提供を最大化させる土台をしっかり作ることを目的としています。 新しい技術を取り入れやすくなったり、Pull Requestをマージするまでの時間をKPIとして計測・改善したりと組織として開発力向上の動きがしやすく、タスクの生産性の向上に一定の効果が出ています。 一方、職種混合で動いていたときより企画職やデザイナー職など他の職種との接点が少なくなったのも事実です。 また、この期間に新卒入社した社員はコロナ禍も重なり、他職種の業務がどういったものなのか実際に目で見る機会がない人もいます。 職能別組織であっても各職種間で連携して施策を進めています。 各種施策の質やスピードも高めるためには、仲間の業務について知っておくことが重要だと考えました。 そこで、「グループを超えたコミュニケーション」・「越境力 ～ 越境して企画を知ってみよう ～」というテーマを掲げ、企画立案を体験するワークを実施して他職種の業務を知ろうと試みました。 開催の工夫 時間がかかると想定されましたが「制限時間内でできるところまで」だと業務の一部までしか知れない懸念もあり最後まで通して体験できるよう工夫しました。 間隔をあけて3回に分けて実施 各回のゴールを定め、ゴールまで進めなかった場合は次回までの宿題とする（その為の期間を設ける） グループワークで実施 3人寄れば文殊の知恵ではないですが、普段一緒に働いてるチームのメンバーと相談しながら進めれば案も出やすいし調査なども分担できる 解決したい課題は予め割り当てておき、普段企画職が使っている企画書の細かい部分を省略した簡易版のテンプレートを用意する 課題発見については対象外とし、主要な項目の立案を対象とする（企画の主となる業務を体感することにフォーカス） 企画職にもエンジニアがこのワークを実施していることを共有し、質問に回答してもらうなど協力を仰ぐ 宿題を円滑に進められるようなフォロー体制を用意 1回目はブレスト的にアイデアを出してその中から効果が高そうに思われるいくつかに絞り込むことをゴールに1時間程で開催しました。 2回目は1日かけて企画の裏付けデータの確認やブラッシュアップ、成果見込みの算出を行いました。 3回目で作った企画内容の発表会を行ないました。 タイムテーブルの例 実施してみて 日頃からテクニカルスキルを活用して課題解決、価値を生み出すことを意識して開発しているメンバーも多く、結果として真剣に企画立案に取り組んでもらえました。 やはり、やり慣れていない業務だからなのか、エンジニアらしくロジカルな面に拘ってしまうのか、時間内にゴールまで達するグループは少なかったです。 しかし、各回の合間にはGAやamplitudeなどの解析ツール、Google Search Consoleや宅市場動向調査報告書のデータなど複数の情報・ツールを用い、多角的に解析・検証するなど次回のワークの準備はしっかり整えてくれました。 3回目の発表会では各グループとも企画職の体験ワークとして実施した企画案とは思えないほど裏付けに基づいた企画が発表されました。 質問に対しても「そこはこういうデータが根拠にあってそういう風にしています」など、細部まで作り込まれていて驚きました。 参加者の集中の仕方や発表内容を見て、テーマに掲げた「越境力」のベースとなる力は持っているなと感じました。 企画書の例 また、ワークの振り返りとして気付いたことの共有なども行ないました。 その中では下記のような意見が出ました。 ちゃんと仮説立ててファクトを集めて方向を定めていく大切さ 新しい施策や機能については、データがないことが多いから根拠を示すことが難しい この類の施策に関してはある程度の裏付けが取れたら最速でリリースして反応を見る方が効率が良い 数字の根拠出すのが大変 企画書について、目的にたいして明確な数値目標を設定するのが難しかった 工数とインパクトの兼ね合いをどうつけるかが難しい この検討には、エンジニアと話すと良さそう 企画にエンジニアから働きかけたいことが見えてきた 企画の業務の何が大変なのか、どこが重要なのかなどある程度把握できてワークの目的は達成できたと思います。 振り返りの例 まとめ 企画の業務を知るという目的を達成できただけでなく、どのタイミングで企画に働きかければより円滑に連携できるかにも目を向けられた人がいるなど、目的以上の成果のあったワークだと感じています。 次のステップは、ここで知ったこと・気付いたことを忘れずに業務に活かして各種施策の質やスピードの向上につなげることです。 まだまだやるべきことはありますが、この経験を活かしてLIFULLのサービスの改善速度を加速していきたいと思います。 最後に、LIFULLではともに成長していける仲間を募集しています。詳細は募集求人やカジュアル面談のページをご覧ください。 hrmos.co hrmos.co

テクノロジー本部の yoshikawa です。普段の業務では LIFULLのデータに関するエンジニアリングを行っています。 今回の LIFULL Creators Blog ではデータリネージや(メタ)データカタログの整備など、データの活用を促進するような取り組みについて紹介します。 ここ数年で、LIFULL が保有するデータの活用に関する問題点が顕著になり、その解決に向けて今回紹介する取り組みを実施しました。 社内データ活用に対する課題と要望 解決策としてのデータリネージとデータカタログ データリネージの整備 BigQuery の INFORMATION_SCHEMA から情報収集 Streamlit と pyvis による可視化 将来的には SQL を集約してリネージ生成を データカタログの整備 タグテンプレートの作成とタグ付け データ利用状況の可視化 SSOT としての機能に期待 新バッチ実行基盤の構築と検証 まとめ 社内データ活用に対する課題と要望 問題を明らかにするため、社内のデータアナリストにヒアリングしたところ下記のような課題と要望があると判明しました。 機密情報があるテーブル由来のデータを削除したい場合など、機密情報など特定の情報があるテーブルとその派生テーブルを一発で見たい データの仕様書がないこともあり、そのときは生データを見るしかデータを知る方法がないので、データの品質を調べたり探索的な調査を実施する工数が大きい アドホック分析などでは、利用頻度の高いテーブルであれば利用しても問題ないと判断して使うことが多いので、利用頻度の高いテーブルを簡単に知りたい 総じて、データ間の関係性や派生先が不明瞭であることによる問題と、データの利用方法や利用状況が不明瞭であることに問題があると判断しました。 解決策としてのデータリネージとデータカタログ 課題と要望の解決を実現するために以下を満たすプラットフォーム構築を行うと決定しました。 データの関連性を明らかにするデータリネージにより、データ間の関係性や派生先を明確にする SSOT(Single Source of Truth)としてデータカタログの構築により、データの利用方法や利用状況を明確にする 以下ではそれぞれについて、実現に至るまでの方法と今後の展望を交えて紹介していきます。 データリネージの整備 データの探索コスト緩和のための解決策としてデータリネージの整備を行います。 まず考えたのは実現手段(ツール)についてですが、OSS である OpenLineage や dbt の docs 機能などの OSS が候補として挙がりました。 他には Google Cloud の下記ソリューションに倣って Data Catalog(Google Cloud)のタグとして表現することも検討しましたが、テキストのみで表現すると全体像が把握しづらいというデメリットもあります。 cloud.google.com 今回は LIFULL のデータ基盤として利用している BigQuery のメタデータ(INFORMATION_SCHEMA)をもとにして内製データリネージ可視化 Web アプリケーションを作成することでデータリネージを実現しました。 BigQuery の INFORMATION_SCHEMA から情報収集 データリネージの元となる情報は BigQuery の INFORMATION_SCHEMA から収集しています。 cloud.google.com 具体的な収集方法は単純なもので、INFORMATION_SCHEMA.JOBS_BY_PROJECT から referenced_tables と destination_table を SELECT し、job を実行している service account で絞り込むというのが大枠です。 INFORMATION_SCHEMA は過去 180 日間のジョブの履歴を保持しているため、その間に参照と更新どちらも行われなかったテーブルはリネージ情報として取得されません。 しかし、そのようなテーブルは後述のデータ利用状況と突合することでもはや利用されていない非アクティブなテーブルであると判断できます。 データリネージ情報収集の副産物として、不要なテーブルを発見しコストカットにも寄与できるのは嬉しい点の一つです。 Streamlit と pyvis による可視化 このようにして入手したデータリネージの元情報は、有向グラフとして可視化しインタラクティブにリネージ情報を閲覧できる Web アプリケーションとして提供しています。 データリネージ可視化Webアプリケーション 有向グラフの作成には pyvis を利用し、Web アプリケーションフレームワークとして手軽にデータ可視化が行える Streamlit を利用しています。 pyvis.readthedocs.io streamlit.io Web アプリケーションとして工夫した点には、 エッジ(辺)の数は 1000 件近くあるため、UI 上での入力や GET リクエスト時に絞り込めるようにする 注目したいノードを選択することで上位・下位の階層(先祖、子孫ノード)も一覧できるようにする などがあります。 まだ導入して間もないですが、このデータリネージ Web アプリケーションはさまざまな恩恵をもたらすことが期待できます。 たとえば、データアナリストなどデータ利用者は、再利用すべき一次情報は何かといった判断をデータの仕様書からデータの関係性を調査したり有識者へのヒアリングをせずとも判断できるようになります。 また、エンジニアなどデータ運用者は、非依存関係が多く変更による影響の大きいテーブル・ビューが一目瞭然となり調査の工数が減るというメリットがあります。 将来的には SQL を集約してリネージ生成を BigQuery の INFORMATION_SCHEMA からジョブ実行履歴を収集・加工し可視化するというアプローチでデータリネージの可視化を実現できました。 しかし、このアプローチは多くのジョブ実行履歴の中からリネージ情報のみを抽出するやや遠回しなものであるため、メンテナンス性や費用対効果という面で改善の余地があります。 他の有力なアプローチとしては、BigQuery のジョブとして実行される前の SQL を一ヵ所に集約しパースすることでテーブル・ビュー・データセット間のリネージを生成するというものがあります。 その最たるものとして注目しているのが dbt(data build tool)による dbt docs 機能です。 docs.getdbt.com dbt models(テーブル・ビュー)どうしの関係性を可視化することリネージ情報を生成可能なことに加え、データに関するドキュメンテーション機能という側面もあるため、 カタログ機能も備えた Data Discovery Platform として機能することも期待できます。 そんな dbt ですが社内での利用に際しては、社内の SQL あるいは SQL 実行の基盤を dbt に集約することが必要になると考えています。 社内での dbt 利用は筆者が属するプロジェクトなど一部の業務においてのみ利用されているのが現状ですが、 これまでの開発においてその有用性は実感できているため、データリネージ機能を含め更なるデータ活用の促進を実現するためにも推進していきたいところです。 データカタログの整備 以前、データ利用の現場からどのような課題意識あるか調査し、Datahub というデータカタログ(データディスカバリー)OSS による解決策の PoC を行いました。 www.lifull.blog PoC が成功したため Datahub を本格運用することも検討しました。 しかし、今回の要件では分析用データベース(BigQuery)のみを対象としたカタログ作成を行うため、Google Cloud(GCP) で完結できるように、Data Catalog を利用することに決定しました。 cloud.google.com (今年の夏に Data Catalog は Dataplex に統合されています) タグテンプレートの作成とタグ付け Data Catalog では、エンティティ(BigQuery データセット、テーブル、ビューなど)に対してタグ付けを行うことでデータにメタ情報を付与し GitHub issues の Label のように任意の文字列を付与することでタグ付けするというアプローチとはやや異なり、 Data Catalog では、文字列型や数値型などの型のある複数のフィールドを持ったタグの定義(タグテンプレート)をあらかじめ作成し、 フィールドに値を入れることでタグのインスタンスを生成する、というアプローチでタグ付けを行います。 この特性上、タグテンプレートの定義はかなり自由度が高く GitHub issues ほどベストプラクティスも定まっていませんが、 今回は汎用的なフィールドを持ちビジネスメタデータを表現するデータディスカバリー用タグと、audit logs から取得したクエリの実行履歴を加工しデータの利用状況の統計値をまとめたタグを付与しています。 前者については運用開始後に利用者のニーズを広く受け入れられるように極力汎用的なタグとして設計し、後者のタグはデータアナリストへのヒアリング結果を基に利用状況データをタグとして付与すると決定しました。 作成したタグの例：汎用的なビジネスメタデータタグと利用状況の統計値のタグ データ利用状況の可視化 前述の利用状況の統計値は一定期間内の情報や抜粋した情報をタグとして付与していますが、全期間のデータの推移は Data Studio(Data Portal)上で可視化しています。 データ利用状況の統計値の推移 SSOT としての機能に期待 タグの整備が実施された Data Catalog ですが、運用やメタデータの集約という点では発展途上な部分もあります。 今後は社内のデータ仕様書を Data Catalog に集約してデータに関する情報源を Data Catalog に集約するという構想を立てています。 その手段として GitHub 上でデータの仕様書のバージョン管理を行い Data Catalog に Push し閲覧できるようにするのが理想的だと考えられます。 しかし、そのためには仕組みの整備や他職種の巻き込みなどの多様な取り組みが必要とされるため、多くのステークホルダーと協力し長期的に実施することになり、実現までは長い道のりとなりそうです。 新バッチ実行基盤の構築と検証 既に社内には Luigi ベースの既存のバッチ実行基盤が存在しています。 しかし、今回構築したデータリネージ Web アプリケーションと Data Catalog、およびデータ利用状況の基となるデータ生成のジョブは、新たにバッチ実行基盤を通じて実行しています。 求められる要件だけを考慮した場合、既存のバッチ実行基盤を利用したり、 Cloud Data Fusion を利用して極力コードを書かずに簡易に作成することも有効な選択肢でした。 しかしながら、今後の拡張性を考慮しデータ基盤への投資的な意味も込めて Argo Workflows で dbt や更新用スクリプトを workflow として実行できるように GKE Autopilot 　による kubernetes cluster の構築を行いました。 argoproj.github.io cloud.google.com まだ数ヶ月ほど運用した所感ですが、Argo Wokrflows については専用 manifest の知識は必要になるもののより多くの用途での運用でも耐え得ると感じています。 既存バッチ基盤のリプレイスなども視野に入れつつ今後も運用していきたいと考えています。 また、現状では toCサービスにあるような急峻な負荷の増加に対応する必要性は無いため、GKE Autopilotによるマネージドなノード管理で間に合っており、kubernetes cluster の運用効率化という恩恵を受けることができています。 まとめ データ活用を促進するためのデータプラットフォーム開発と題して、Google Cloud(GCP)や OSS など幅広い技術を用いた開発について紹介いたしました。 データ活用のためにソフトウェアエンジニアリングが活かせる余地はまだまだあると考えており、今後も引き続き開発や改善を実施していきます。 最後に、LIFULL ではエンジニア職などの募集しています。 募集中の求人やカジュアル面談のご応募などについては、こちらのページをご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの中島です。 2022年 4月からアクセシビリティ推進グループ（以下推進グループ）に在籍しています。 この組織は新設されたばかりで、まだ出来て半年の組織になります。 そのため、部署の目指すべきゴールイメージや、それを図るための指標といったものを作るところから始めることになりました。 本記事はそういったところについて共有させていただこうと思います。 立ち上げにあたっての話については以前同グループの嶌田が投稿した記事があるのでそちらをご参照ください。 www.lifull.blog 部署の目指すべきゴールイメージと行動軸 プロダクトに対する直接的な品質改善活動 新しい負債の発生を低減させるための文化醸成 指標化 プロダクトに対する直接的な品質改善活動の指標化 マニュアルテスト スコアリング 加えたマニュアルテスト項目とその重み Lighthouseの推奨するマニュアルテスト 推進グループで追加したマニュアルテスト 新しい負債の発生を低減させるための文化醸成の指標化 運用してどうか 最後に 部署の目指すべきゴールイメージと行動軸 推進グループ内で話し合った結果、アクセシビリティの推進活動の先のゴールイメージは「LIFULLのすべてのプロダクトがアクセシブルになっている状態」としました。 そしてそれを実現するために、「プロダクトに対する直接的な品質改善活動」と「新しい負債の発生を低減させるための文化醸成」の二本軸で活動していくことに決めました。 プロダクトに対する直接的な品質改善活動 直接的な品質改善活動は単純明快でサイトをアクセシビリティレビューし、検出された問題を自分たちで直接修正してプロダクト品質を改善していく作業です。 推進グループは開発経験の豊富なエンジニア二名(うち一人は勤続年数も長い)で構成されているため、直接的な修正が自部署内のリソースで行えるようになっています。 新しい負債の発生を低減させるための文化醸成 文化醸成はアクセシビリティの勉強会やガイドライン策定、プロジェクトの個別フォローなどによって社内の開発者のアクセシビリティに対する理解を促す取り組みになります。 こちらはヒューマンリソースの少ない推進グループだけでは厳しいものがあるので、有志で構成されたアクセシビリティを推進するワーキンググループと連携を取りながら進めるといったことで足りないリソースを補いながら進めています。 指標化 業務活動の軸が決まり、次にその活動の成果を測る指標について決めることにしました。 プロダクトに対する直接的な品質改善活動の指標化 プロダクト自体にアクセシビリティレビューを行い、スコア化し、そのスコアの推移を見ることでアクセシビリティの品質の改善度合いを図ることにしました。 スコア化というとLighthouseが真っ先に思い浮かぶわけですが、Lighthouseのアクセシビリティスコアにはマニュアルテストを追加で行うことが求められていることをご存知でしょうか？ developer.chrome.com マニュアルテスト Lighthouseで検出可能なアクセシビリティの指摘点はカラーコントラストや適切なロールやステートが指定されているかといった感じで、読み込み時のHTMLやCSSから計算可能な部分に限られます。 それだけでも十分ありがたいのですが、例えばダイアログを開いた時のフォーカス位置やページの読み込みと同時に再生される動画コンテンツなど、動きを伴う問題点を検出することは現時点ではできません。 またボタンをフォーカス可能な <button> で実装されているかどうかについてもそれがそもそもボタンなのかどうかLighthouseが理解することができないため検出できません。 しかし、サイトにはたくさんのボタンや動きを伴うUIが多く存在しており、Lighthouseで高得点を得ていたとしてもそういった部分で致命的な問題があると、実質的には"操作不能"であるといったこともしばしばありえるわけです。 こういったものをフォローするためにLighthouseは追加でマニュアル(手動)テストを推奨しています。 計算が自動で出来ず、ヒューマンリソースを割く必要があるということはメンバー二人の推進グループではかなり苦しいところではありますが、クォータに一度という間隔を空けてでもこれは検出する必要があると考え、Lighthouseによる自動テストに加え、マニュアルテストを加えてスコアリングすることにしました。 スコアリング ところでそもそもLighthouseのアクセシビリティのスコアリングはどのように算出されるかをご存知でしょうか。 Lighthouseはアクセシビリティの各観点をまとめ、それの重要度に応じて重みを設定しています。 developer.chrome.com この定義をもとに、各項目を検査して問題が検出されなかった場合(Passした場合)、その重みを足し上げていきます。 この時の値をすべての重みの和で割ってあげた数字に100をかけると0~100点までのスコアが算出できるというようになっています。 つまり、マニュアルテストにも重みを設定し、この計算に加えてあげることで自動テストとマニュアルテストをすべて通したスコアが算出できるわけです。 我々はこれをスコアリングの方法として採用し計測することにしました。 加えたマニュアルテスト項目とその重み スコアリングの方法が決まったところで、マニュアルテストに含める項目をどうするかをまた話し合いました。 その結果、Lighthouseで推奨されているマニュアルテストに加え、オリジナルのマニュアルテストを含めた以下のテストで運用することに決めました。 Lighthouseの推奨するマニュアルテスト 項目 重み 項目説明 logical-tab-order 3 ページ内のタブ順序が論理的に正しい順になっていること focusable-controls 10 すべてのカスタムコントロールがキーボードフォーカス可能で、フォーカスインジケータが表示されていることを手動で確認します。 フォーカスが当たる順番は、DOMの順番に従うようにする必要があります。 interactive-element-affordance 10 リンクやボタンなどのインタラクティブな要素は、その状態を示し、非インタラクティブな要素と区別できるようにする必要があります。 インタラクティブな要素がその目的と状態を示しているかどうかを確認するために、視覚テストとスクリーンリーダーによるテストの両方を使用します。 managed-focus 10 新しいコンテンツがページに追加されるたびに、ユーザーのフォーカスがそのコンテンツに向けられ、アクションを起こすことができるようにします。 focus-traps 10 キーボードのフォーカスが特定のページ要素に固定されたり、引っかかったりしないようにすること。 ユーザーは、キーボードのみを使用してすべてのページ要素に移動できるようにする必要があります。 custom-control-roles 10 すべてのカスタムコントロールが適切なRoleを持ち、そのプロパティと状態を与える必要なARIA属性があることを確認します。 例えば、カスタムのチェックボックスは、その状態を適切に伝えるために role="checkbox" と aria-checked="true|false" が必要です。 visual-order-follows-dom 3 スクリーンリーダーやその他の支援技術は、DOM順でページをナビゲートします。情報の流れは理にかなっていなければなりません。 offscreen-content-hidden 3 スクリーンリーダーやその他の支援技術には、ページの関連する部分のみが表示されるようにすること。 たとえば、画面外にあるコンテンツや単なる表示上のコンテンツは、支援技術から見えないようにする必要があります。 (≒非表示コンテンツがvisibility:hidden;/display:none;で適切に隠されていること) use-landmarks 3 HTML5のmain、nav、asideなどの要素は、スクリーンリーダーやその他の支援技術がジャンプできるランドマーク、つまりページ上の特別な領域として機能します。 ランドマーク要素を使用することにより、支援技術の利用者のサイトでのナビゲーション体験を劇的に向上させることができます。 推進グループで追加したマニュアルテスト 項目 重み 項目説明 original 10 ホバーで表示されるコンテンツがタッチでも使えること また、キーボードアクセスが可能であること(フォーカスできる＋フォーカスが見える＋Enterやスペースに反応する) 対象となるホバーコンテンツがない場合は重みを0とする original 10 動画キャプションが設定されていること video要素のkind=captionsで検出できないケース(Youtubeなど) 対象となる動画がない場合は重みを0とする original 10 点滅やスクロールを伴うコンテンツがない original 10 自動更新されるコンテンツがない original 10 フォーカスやフォームの値変更でページ内容の書き換え、ページ遷移、ポップアップの表示がされていない original 10 フォームバリデーション等のエラーのフィードバックを適切に行う 対象となるフォーム等がない場合は重みを0とする 新しい負債の発生を低減させるための文化醸成の指標化 次に文化醸成の度合いの指標化です。 こちらは単純に定性調査をとることにしました。 各組織の組織長に、おもにフロント領域に携わった開発者を抽出してもらい、その方々になるべく回答負荷が少なくなるように作った簡単なアンケートにクォータに一度回答してもらいスコア化しています。 以下は実際になげてるアンケートの項目です 質問内容 回答項目 重み 補足 プロダクト開発においてフロントエンド関連業務を行いましたか？　文言修正やリンク先修正レベルのみであれば「いいえ」でご回答ください。 はい、いいえ 0 誤抽出された開発者の除外 企画やデザインに対してアクセシビリティ観点でチェックやフィードバックを行ったか 1. まったくやらなかった ... 5. とてもよくやった 25 - フロントエンド関連業務を通してアクセシビリティを考慮した実装をしたか 1.まったくやらなかった ... 5.とてもよくやった 25 - フロントエンド関連業務を通して開発メンバーへのレビューや育成等でアクセシビリティ観点で適切な指導をしたか 1.まったくやらなかった ... 5.とてもよくやった 25 - アクセシビリティ推進G(あるいは推進WG)との連携でアクセシビリティ設計への知見は深まりましたか 1.まったく深まらなかった ... 5.とてもよく深まった 25 - 対象職種はフロントエンドエンジニアとしています。 アクセシビリティは企画・デザイナー・エンジニアが一体となって考えるものであることは重々承知した上で、フォローアップするスコープをリソース的に狭める必要があったため、三職種への喚起をフロントエンドエンジニアの責務と定義してここでは回答職種を絞ることにしました。 (これに関しては運用経過を見て方針を変えるかもしれません) 運用してどうか 部署立ち上げから半年色々と試行錯誤してここまできましたが、今のところ活動の成果は目に見えるものとして現れており定量・定性両方のスコアにそこそこの改善が見られています。 マニュアルテストはヒューマンリソースの限られた推進グループとしては運用破綻するかどうか気にしていたところではありますが、だいたい1サイトをテストしきるのに1.5~2人日程度であり、現実的なラインであることがわかってきて安心しているところです (工数的な観点でサイトとページを絞って運用しています) 定性調査の結果はただの定点観測としてだけでなく、そこの回答内容をみて回答してくれた開発者と直接連携をとるきっかけとしてもうまくワークしています。 開発者全員と連携をとるのはひどく難しいように感じますが、弊社程度の規模であればフロントエンドエンジニアが数十人程度なので非力なりにもマンパワーで連携をとることが可能でした。 一度連携をとって知識をつけた開発者が開発リーダーとして現場のメンバーにレビューしたりしてくれることも実際散見されるので初期コストをおしまず投資することへのモチベーションにつながっています。 最後に それぞれのスコアが改善して、その改善結果が実際的な使いやすさにつながっているかを検証する仕組みをつくることが次の我々の課題です。 これからもLIFULLプロダクトのアクセシビリティ向上のために尽力していこうと思います。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは！LIFULLのエンジニアで、Ltech運営チームの１人 サム (@samukaak) / Twitter です！今回は 2020年9月15日（木）に開催した『Ltech#21 LIFULL HOME’Sを支える検索技術』についてレポートします。 Ltechとは 株式会社LIFULL主催の、技術（エンジニアリング・テクノロジー）をテーマにしたイベントの総称です。 特定の技術に偏らず、様々な技術をピックアップしていきます。 Session1 LIFULL HOME'SのAI施策におけるSolr活用 www.docswell.com このセッションでは、SolrをつかったAI施策の事例とその際に出た課題と解決方法が紹介されました。ここで紹介されたAI施策とは「 AIホームズくんᴮᴱᵀᴬ 」というサービスで、住まい探しをするユーザーとの対話を通して学習しぴったりの物件を提案してくれるものです。 SolrとAIチームは別で、一緒に進めるにあたりAIチームからリクエスト ドキュメントごとにベクトルデータを格納、クエリでベクトルを指定してクエリ毎に異なるスコアを計算、並び替えを行いたい これに対して出した案が『Solr9からはいるKnnの機能を使えば実現できそう！』しかし進めるにあたり課題も見つかる。 課題① Solr9からはいるKnnとは違い、検索ではなく並び替えに使いたい 並び替えに利用したいが、全てを対象にしてしまうと計算量が多くなってしまうが、ReRankで上位のみベクトル計算して並び替えることで解決した。 課題② そもそもSolr8だった ベクトルのプラグイン（ https://github.com/DmitryKey/solr-vector-scoring ）を使うことで解決した。 課題③ ベクトルデータをドキュメントに含まない場合も、並び順をコントロールしたい ベクトルデータの生成はAIチームの担当だが、API経由でリクエストするため高スループットになってしまいスケールアウトが間に合わずリクエストが失敗することがあった。リクエストに失敗するとベクトルデータをSolrに格納できない。そのため、リクエストに成功したがベクトルデータが無いものやリクエストに失敗した際に下駄を履かせることで、計算結果がプラスになるように調整して解決した。 課題④ Solrへの負荷がどうなるか予想できない 本番環境のSolrへのクエリからログを抽出し、検証用にクエリを変換。Solrへリクエストをおこない分析を重ねることで負荷への対策を考えることで解決した。 今後としては「ベクトルデータを圧縮できないか？」「Solr9のKnnの機能を使って実現できないか？」について模索しています。 Session2 コピー&カスタマイズできるSolr環境構築のためにEC2 Image builderを活用した話 www.docswell.com このセッションでは、開発者が容易に検証等をおこなえるために個別の開発環境を用意したい、しかし現行のデプロイフローだと管理等に問題が出てくる、その問題を解決するためにEC2 Image builderを活用した話でした。 導入に当たり次の３点について苦労されておりました。 バージョン管理 テスト schemaやクラスタごとに異なる設定 実際に導入してみると、現行のSolrと同じAMIを利用してデプロイするだけで容易に環境を構築できるようになったり、Solrのカスタマイズが容易になったりしました。 Session3 不動産広告と名寄せ www.docswell.com このセッションでは、LIFULL HOME'Sにおける名寄せの話でした。 そもそも名寄せとは「複数の物件データをいくつかの属性を見て同一物件として扱うこと」で、LIFULL HOME'Sでも「同じアパートやマンション」「同じ部屋」を１つの物件としてまとめております。 不動産屋はコンビニの数より多いと言われており、その不動産（管理／仲介）会社が扱う物件数を考えると膨大な数になります。名寄せ以前は同一物件でもそのまま表示されていたため、条件によっては同じ物件が数件並ぶこともありました。 LIFULL HOME'Sでは、これまでいくつかのフェーズで名寄せをおこなってきました。 まずフェーズ１「アプリケーションによる名寄せ」では、共通属性によるハッシュ化をおこなうことで名寄せを実現しました。しかし性能や件数の差異による問題が発生しました。 そこで「名寄せを事前におこなった上で検索エンジンに登録」する方法を考案しましたが、様々な理由からLIFULL HOME'Sでは事前名寄せの方法は採用されませんでした。 しかしLIFULL HOME'Sではサイト側のリニューアルのタイミングで全文検索エンジンからSolrに移行、ResultGroupingによる名寄せをおこなうことで住戸単位だけではなく棟単位による名寄せも実現しました。 Solrを導入することで検索エンジンで名寄せができるようになり、その次に名寄せの精度向上や高速化などにも取り組んでいます。 まとめ 今回はLIFULL HOME’Sを支える検索技術としてSolrに関する話を3名のエンジニアに発表いただきました。この他にもLIFULL HOME'Sではメンバーが随時 LIFULL Creators Blog にて情報を発信しています。興味を持っていただいた方にはぜひ1度ご覧いただきたい記事ばかりになっています！ www.lifull.blog Ltechでは、LIFULLのエンジニアが中心になって皆様の技術欲を満たすよう実例を交えた勉強会を開催しています。今後も Ltech を積極的に開催していきますので、ぜひ気になった方は、connpass で LIFULL のメンバー登録をよろしくお願いします！ lifull.connpass.com また、LIFULLでは今回紹介した検索基盤に関わるものを含め、数多くの職種の仲間を募集しています。 よろしければこちらのページもご覧ください。 【エンジニア】募集求人一覧 | 株式会社LIFULL 【エンジニア】カジュアル面談 | 株式会社LIFULL

はじめに みなさんこんにちは、 LIFULL HOME'S事業本部プロダクトエンジニアリング部プロダクトエンジニアリング3ユニットの吉次です。 新型コロナウィルス感染症が発生したことにより、従来の勤務場所から離れて自宅などで仕事を行うリモートワークが全国的に増えてきました。 私たちLIFULLでも同じように、リモートワークがメインとなりました。 リモートワークは通勤時間の削減による通勤時のストレス軽減や空いたリソースを家族や自分のために使用できるようになるなどメリットは大きいのですが、外出が減って運動不足になった、プライベートと仕事の切り替えが難しくなった、仕事中でも子供やペットの世話をしなければならなくなり集中する時間が取れなくなったなどデメリットも少なくありません。 またリモートワークとなることにより直接同僚と会うことが減り、コミュニケーションの絶対量が減ってきました。私たちの部署ではコミュニケーションの減少が長期的には大きな問題となってくることを懸念しています。 その問題を解決するべく私たちLIFULLではコミュニケーションデイ、通称「コミュデイ」という制度を導入しているので紹介します。 コミュデイの説明 私たちLIFULLでは原則週1日オフィス勤務となっております。 ※ 新型コロナウィルスの感染状況によっては、勤務場所任意（週5日リモートワークも可能）となる場合もあります。 コミュデイとは週1回はグループ等部門メンバーの出社日を揃え対面で仕事を進めて関係の強化を図ることです。 具体的にどのようなことをコミュデイで実施したのか紹介します。 コミュデイ実例紹介 LIFULL Tableにてカジュアルにコミュニケーションをとりながら勤務 LIFULLにはLIFULL Table( https://table.lifull.com/ )という半蔵門本社1Fに併設された、ギャラリー&オープンスペースがあります。 table.lifull.com ここでは撮影や展示会、プレス発表会、ワークショップ等の様々な用途での使用が可能で、社員開放されている際には誰でも自由に使用することができます。 ※ 新型コロナウィルスの感染状況によっては使用不可、または使用人数の制限などが入るケースがあります。 私たちのグループのコミュデイでは、LIFULL Tableが自由に使用できる際にグループのメンバーで集まって持ち寄ったお菓子やコーヒーなどを嗜みながら仕事を行いました。 リモートワーク化では入社したばかりの人や、PJにアサインしたばかりの人とカジュアルにコミュニケーションをとる量が圧倒的に低く、結果、チームとしての心理的安全性が上がらず不安に感じてしまう人が多いです。 LIFULL Tableでお菓子やコーヒーを嗜み、軽く雑談しながら仕事することでメンバー同士の心理的なハードルが下がり、心理的安全性を高めることができました。 ブレストルームで設計レビュー LIFULLの執務室にはブレストルームと言って壁全体がホワイトボードになっている会議室があります。 そこでグループのメンバーで設計レビューを行いました。 クリーンアーキテクチャを用いるかどうか、満たさなければならない機能要件と非機能要件がさまざまあったりなど難しい設計だったので議論が白熱しました。 アナログのホワイトボードは気軽に書いては消しができるので、文章では表現が難しい概念も気軽に図示して共有できるという利点があります。 図を書いて話し合うことでレビューをする側も自分の考えをまとめることができ、レビューをされる側も比較的短時間でレビュアーの意図を汲むことができたので、 オンラインに比べて設計を洗練させていく時間が短縮できました。 まとめ リモートワークの機会が増えたことで直接的なコミュニケーションの絶対量が減ってきましたが、私たちはコミュデイを通してグループのコミュニケーション量を高めることができました。 また、気軽にコミュニケーションを取れる機会が増えたことで、心理的安全性、生産性も向上しました。 チームビルディングやレトロスペクティブ等のスクラムのイベントなど、他のグループ行事でもお菓子を食べながらカジュアルな空気で実施していくのもいいかもしれません。 最後に、LIFULLでは一緒に働く仲間を募集しております。興味を持っていただけた方は、募集求人やカジュアル面談のページもご覧ください。 https://hrmos.co/pages/lifull/jobs/010 https://hrmos.co/pages/lifull/jobs/010-9998