テクノロジー本部の 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

こんにちは。テクノロジー本部の福留です。4 月に新卒入社しました。好きなものは 合唱 と 篩型 です。 目標管理に関するフレームワークとして、 OKR(Objectives and Key Results) が Google や Facebook などの企業で取り入れられ、注目を集めています。 OKR フレームワークにおいては、挑戦しがいのある高い目標(Objective)を設定し、主要な結果(Key Results)も 60〜70%の達成度で成功とみなされるような、高い成果に設定します。 チームのモチベーションが高くなるような高い目標を掲げる一方で、日々の業務ではできなかったことのほうが多くなり、徐々にメンバーのモチベーションが低下する原因になりえます。 この問題を解決する取り組みが WinSession です。この場では、逆に「できたこと」に注目し、メンバーどうしが承認・称賛しながら情報共有を行います。 resily.com 今回は、私が所属するアーキテクトグループで実際に行った WinSession の中で、成果を共有をすることでよりよい成果を出せた事例を、新卒の目線から紹介します。 目次 目次 アーキテクトグループの主な仕事 WinSession Win: テストを高速化した！ Vitest でテストを高速化 ビルドも速くしたい！ Session: Node.js の専門家に相談 WinSession 当日 あと一歩！ After: 協力してビルドの高速化にも成功 実行順序の担保 再び専門家に仰ぐ 終わりに 一緒に働きませんか？ アーキテクトグループの主な仕事 本題へ入る前に、私が所属しているアーキテクトグループの主な仕事を紹介します。 アーキテクトグループは過去に、BFF 層アプリケーションを刷新するためのプロジェクトとして、TypeScript 製の新しい Backend For Frontend アプリケーションを作成していました。 www.lifull.blog このアプリケーションを、以下では「新 BFF」と呼びます。 現在はこのアプリケーションの GitHub リポジトリを Template Repository に指定しています。さらに新しく BFF アプリケーションを作る際には、Template Repository から Generate することで作成することを推奨しています。 この方法で作られたアプリケーションを、以下では「派生アプリケーション」と呼びます。 これを踏まえて、現在のアーキテクトグループは次の取り組みを行っています。 新 BFF から Generate された派生アプリケーション作成時のアーキテクチャの相談受け付け 新 BFF の保守や生産性向上のためのリファクタリング・ビルド設定等の最適化 そのほか、レガシーなアプリケーションに対する生産性向上や刷新の取り組み 各派生アプリケーションは新 BFF から Generate されているため、新 BFF に行われた改善を受け入れやすい状態です。 新 BFF への改善を行うと全体最適な状態に近付けることができるため、個人的に力を入れている仕事でもあります。 WinSession さて、アーキテクトグループでは WinSession を 2 週間に一度、金曜日に行っています。 新卒として感じる WinSession の効果は以下の 3 つです。 冒頭で述べたモチベーション維持の効果 共有された成果がよりよくなるような提案をいただける 他の人の成果からアイデアをふくらませることができる 以下では、WinSession の効果のうち、特に 2 つ目 が効力を発揮して、よりよい成果を出せた事例を紹介します。 Win: テストを高速化した！ Vitest でテストを高速化 ある日私は、新 BFF のユニットテストフレームワークを Jest から Vitest に乗り換えることで、ユニットテスト全体に 1 分かかっていたものを 約半分の 30 秒 に短縮する成果を上げました。 vitest.dev 新 BFF は、TypeScript 製フレームワークである LoopBack を採用しています。LoopBack は decorator に型情報を持たせるため、トランスパイル時に型情報を保存する、 tsc でいうところの emitDecoratorMetadata オプション に相当する機能が必要です。 一方、Vitest はトランスパイルに esbuild を使用しています。 esbuild.github.io esbuild は速度を重視する思想から、 emitDecoratorMetadata のような TypeScript の型システムに関する機能を サポートしません 。 有志が プラグイン を作成しているものの、対応する esbuild のバージョンが 古く 、Vitest をそのまま使うことはできませんでした。 そこで、esbuild と同じく、速さが売りの SWC に目をつけました。 swc.rs SWC は tsc を書き換えることも目的としている ので、 emitDecoratorMetadata に相当する機能 をもっています。 Vitest に対しては rollup-plugin-swc3 を使うことで導入できました。 ここまでたどり着くのに少し時間がかかったので、WinSession で自慢したい！と息巻いていました。 ビルドも速くしたい！ テストが速くなったので、ビルドも tsc から SWC に乗り換えれば、もっと生産性を上げることができないかと考えました。 しかし、SWC を使って TypeScript をトランスパイルする場合には、次の課題がありました。 SWC は通常 ESModule のコードを出力するため、CommonJS を用いる LoopBack がビルド後のコードを読み込めない 開発時に使う tsc-watch を廃止したいが、SWC には tsc-watch の onSuccess 相当の機能がなく、「差分ビルドが終わってからサーバを再起動する」ことができない 課題はさておき、Vitest を使えるようになったのはうれしい！ということで、WinSession にネタを持っていきました。 Session: Node.js の専門家に相談 WinSession 当日 さて WinSession 当日、Vitest の成果を共有しました。そして、ビルドにも SWC を使えないか目論んでいることも話しました。 すると、同じアーキテクトグループの相馬さんから、esbuild や SWC の速さの秘訣について教えていただくことができました。 相馬さんは自他共に認める Node.js の専門家で、過去にこんな記事も書いていらっしゃる方です。 www.lifull.blog www.lifull.blog 相馬さんなら SWC の設定にも詳しそうだと思ったので、ビルド高速化について抱えている課題を話してみました。 すると、なんとその日のうちに、SWC によるビルドを行えるようにする Pull Request を作っていただくことができました。 この Pull Request には、SWC によるトランスパイルで CommonJS を出力する設定のほか、トランスパイルと型チェックを並列に行うスクリプトも含まれていました。 あと一歩！ ところが、これで解決、めでたしめでたし…とはなりませんでした。開発用サーバを起動する場合に、トランスパイルとサーバ起動を並列に行っている状態でした。 これだと最初に起動する際は 以前のビルド結果を削除 SWC の全体トランスパイルとサーバの再起動を同時に行う となるのはよいのですが、この後 SWC がファイルの変更を検知 SWC が変更されたファイルだけを再トランスパイル サーバはファイルの変更を検知しないため、 再起動しない となる場合がありました。3 を解決するには、「トランスパイルが行われた後にサーバを再起動する」という、順序関係を担保するしくみが必要です。 After: 協力してビルドの高速化にも成功 実行順序の担保 私は、この問題に対して、SWC の watch モードを使う代わりに nodemon で解決を図りました。ファイルの変更を検知し、指定されたスクリプトを動作させるツールです。 nodemon.io このツールを使うことで、 nodemon が任意の ts ファイルを監視 変更を検知したら、トランスパイルとサーバの起動を順に行う とし、トランスパイルとサーバ起動の順序関係は担保しました。 しかし、これでは SWC の差分トランスパイル機能が使えないため、毎回すべてのファイルをトランスパイルし直す必要があります。 パフォーマンス的には片手落ちになってしまいました。 再び専門家に仰ぐ もう一度相馬さんに相談し、nodemon の監視対象の制限方法と、delay 機能を教えていただくことができ、次の構成になりました。 SWC のトランスパイル結果が出力される js ファイルが出力されたら、500ms 後にサーバを起動する 結果、実行順としては SWC のトランスパイル開始と同時に、nodemon が出力先ディレクトリを監視 js ファイルが出力されたら、500ms 後にサーバを再起動する となり、すべての問題が解決しました。 最終的に、全体のビルド速度は、tsc を使っていたころに約 24 秒かかっていたのが 約 8 倍の 3 秒 となりました。 開発サーバのファイル変更検知による再起動も、SWC のトランスパイルによって、tsc 時代より大幅に短縮された速度で行われるようになりました。 結果、テストだけではなく、ビルドも高速になり、生産性向上に大きく貢献できました。 終わりに 今回は、WinSession で成果を共有することで、よりよい成果につながった事例を紹介しました。 WinSession で成果を称え合う文化があることで、モチベーションを高く保ちながら働くことができています。さらに、WinSession で成果を共有できたことで、新卒でも専門家の教えを受けながら働ける、貴重な機会に恵まれました。 LIFULL 社員の行動規範である ガイドライン には、「真のチームワークを築く」という節があります。個人的に WinSession は、これをよく表す、LIFULL らしい取り組みだと感じています。 一緒に働きませんか？ LIFULL には、Node.js 以外にも数多の専門家がいます。新卒、中途問わず、一緒に働いてみたい！という方、ぜひこちらも合わせてご覧ください。 hrmos.co hrmos.co

こんにちは、LIFULLでUXリサーチャーをしている小川です。 5月28日(土)に開催された、リサーチをテーマとした日本発のカンファレンス「 RESEARCH Conference 2022 」に、スポンサーセッション枠で登壇させていただきました。 この記事では、当日お話ししたテーマについて紹介してまいります。 UXリサーチに関わる2つのスタート RESEARCH Conference の今回のテーマが「 START 」ということで、LIFULLからは UXリサーチを推進するグループを立ち上げた背景 ユーザー理解の文化を醸成するために行った取り組み の2つをテーマとして選びました。 www.docswell.com 「UXリサーチを推進するグループの立ち上げ」は、いくつかの偶然が重なり実現しました。 今回のカンファレンスでは「偶然を作り出した土台」と「偶然を掴んだマインドチェンジ」の2つを紹介しています。 「ユーザー理解の文化の醸成」は、まだまだ着手しはじめたばかりではありますが、UX成熟度モデルの取り組みなどを紹介しています。 UXの浸透に取り組まれている方の参考になれば幸いです。 発表の内容については、 RESEARCH Conferenceのnote でまとめてくださっています。 note.com 動画でご覧になりたい方は、こちらをご覧ください。 www.youtube.com LIFULL は一緒に働けるクリエイターを募集しています。ユーザーファースト推進グループへの取り組みが良いね👍と思ったら、求人をぜひご確認ください。 hrmos.co hrmos.co hrmos.co hrmos.co

テクノロジーマネジメントUの鈴木( @szk3 )です。 普段は クラウドアーキテクトとして、組織を横断してクラウド(主にAWSとGoogle Cloud)の利用を改善するための取り組みをしています。 この記事では、弊社における Cloud Center of Excellence(CCoE) の活動について紹介します。 Cloud Center of Excellence（CCoE) とは まず、CCoEとは一言でいうと「 クラウドの利用を推進させる全社横断型の組織 」です。 会社の規模により組織化の形態や役割は変わると思いますが、大枠としては「 クラウド利用の組織的な最適化 」を目指す組織だと思います。 具体的にやることは、組織的なクラウド利用の相談・ルール化・啓蒙・教育、ガードレール構築、リソース集約化などを行うことが多いと思います。 CCoEに関しては、AWS, Microsoft, Google Cloud 各社それぞれが、CCoEについて言及しているので参考にしてください。Google Cloud には分科会があるようです。 docs.aws.amazon.com docs.microsoft.com cloud.google.com 弊社における、CCoE の定義 弊社では、CCoE をひとつのプロジェクトとして捉え、メンバーはインフラやセキュリティの有識者にワーキンググループの形で参加してもらっています。 組織化にあたり、上記の AWSによるCCoEの構築のための6つの原則 を参考にしています。 また、実際の活動においては、利用の推進といった漠然とした目標では推進力が生まれないので、 プロジェクトとして取り組むべきことを言語化 しました。 CCoE立ち上げ時に、ビジネス的な観点(コスト・セキュリティ・アカウント台帳管理等)に対する課題意識があったため、そこを強化・啓蒙するように、以下の３つを達成したいこととして定めています。 コスト・セキュリティ・台帳管理の3軸で、クラウドに関わるガバナンスを持続的に実施できる環境・文化の構築を目指す 統制実施にかかる人的負荷を軽減し、安全性・生産性ともに高水準で健全にクラウドを利用し続けられる状態を作る CCoE チームを組織することで、横断的なクラウドへの関心事について状況を整理し遂行をサポートする バランスト・スコアカード 上記を元に、最終的に バランスト・スコアカード に落としてこんで、やることを整理しています。 ja.wikipedia.org 実際に作成したバランスト・スコアカードの概要がこちらです。（※ こちらは大項目のみ抽出してあるもので、実際はもっと細かくやることが定義されています。あくまでイメージとしてご参照ください) バランスト・スコアカード 一点補足しておくと、監査という言葉がやや強く感じますが、ここでいう監査とは「クラウド利用状況のコスト・セキュリティ面における健全性を判断する」くらいの感覚で記述してあります。 CCoE プロジェクトでの取り組み 上記バランスト・スコアカードには細かく書いてありますが、CCoEプロジェクトで行っていることはすごく大雑把にまとめると システム開発 と チーム運営 です。 システム開発では 「改善の一歩目は可視化」と捉え、まずは 利用料とセキュリティについて組織別に可視化する為の仕組みを構築しました。 チーム運営では、クラウド利用に関する横断的な意思決定と告知、ドキュメンテーション、研修の案内、予算化ルールの策定などを行っています。 本記事では、システム開発の部分について紹介します。 CCoE システム システムとして２つの機能を実装しています。 予算管理者向けのダッシュボード と、 コスト変動・異常通知 です。 システムは、 AWS Cloud Development Kit（CDK） を利用し、TypeScriptでCI/CD含めインフラ周りをまるっとInfrastructure as Code（IaC）として実装しています。 docs.aws.amazon.com 全体的な構成は、以下のような感じです。これらをCCoE用のAWSアカウントにプロビジョニング/デプロイしています。 CCoEシステム概要 CCoE ダッシュボード 弊社では、100以上ある 各AWSアカウントの管理・運用は各組織で管轄する ことになっていますが、１つの組織が主管するAWSアカウントの数にはバラつきがあり、多いところでは１つの組織で10個以上のアカウントを管理しています。 そうなってくると、 組織の観点でアカウントの健全性を把握しようとした際に、判断基準や確認するためのコストが変わってくる という課題がでてきます。 そこで、 可視化の形を共通化することで、クラウド利用の健全性を確認するための認知コストを下げ、情報粒度を整える ことを目的にダッシュボードを設計しました。 アーキテクチャ ダッシュボードのアーキテクチャは、Amazon Elastic Container Service (Amazon ECS) + AWS Fargate で metabase タスクを実行し、データストアに AWS RDS Postgres を採用しています。 データの更新は、CloudWatch Events でスケジュールし lambda functions でデータを書き込んでいます。 データ取得 デイリーのコストの情報に関しては、バージニアリージョンの CloudWatch Metrics から取得しています。 俯瞰して傾向を見る程度であれば、CostExplorerやCURほど細かいデータの取得が必要がないので CloudWatch Metrics の情報で必要十分だと割り切っています。 各AWSアカウントの情報はOrganizationsから基本的なAWSアカウントの一覧情報を取得し、各AWSアカウントからしか取れない情報（アカウントエイリアスなど）は、それぞれのアカウントにAssumeRoleして取得しています。 また、Organizationsからダウンロードして取得したTrustedAdvisorレポートをRDSに書き込み、各組織や各アカウントといった粒度で可視化しています。 ダッシュボード いろんなダッシュボードがありますが、いくつか主要なものを紹介します。(※ 画像に使っているデータはダミーです。） １つ目は組織ごとのTotalEstimatedChargesのグラフになります。 上部のグラフはユニット組織としての単月合計利用料で一括で比較できます。 下部のグラフは、ユニット配下のグループが管理するAWSアカウントごとの利用料で、1日始まりで固定し直近三ヶ月＋昨年同月で比較しています。 これにより、 昨対や昨月でどれくらいのペースでコストが変動しているのかが誰でも同じ見方で理解できる ようにしています。 TotalEstimatedCharges 以下は、組織ごとのTrustedAdvisorのエラー状態の積み上げグラフで、 月毎に時系列で TrustedAdvisorのエラー数を経過観測できる ようにしています。 TAエラー数 時系列変化 以下は、AWSアカウントごとのコスト最適化余地を示すグラフです。 各AWSアカウントの先月の利用料（黄色）とTrustedAdvisorが提示するコスト最適化額（紫）の比較になります。 このグラフを見ることで、 どのアカウントにコスト最適化余地があるのかが一目瞭然 です。（もちろん全て最適化できるわけではありませんが。。。） 先月利用料とTAコスト最適化額の比較 これらのダッシュボードの活用については、組織長が集まるミーティングの中で定期的にダッシュボードを確認し確認するような運用モデルをドキュメンテーションし、セットにして展開しています。 また、コストコントロールのため、夜間や土日は停止するように、 Instance Scheduler でRDSやNatの起動管理をしています。 ECSのtask数の調整に関しては、Instance Scheduler は非対応のため lambdaでタスク数のスケジューリングを実装しています。 aws.amazon.com CCoE コスト変動通知 各AWSアカウントの中で、過去24時間のコスト増加額と増加率の上位10アカウントについて、Slack経由で定期的にレポートする通知です。 CloudWatch Event で 12時間毎に Scheduleされるので、いち早く問題に気づける ようにしています。 こちらは、独自のフォーマットで送信しているので、Chatbotとの連携はせずにWebhook経由でSlackと連携させています。 メッセージのフォーマットはこのような形です（内容はダミーです） 24h コスト増加額・変動率 Slackメッセージ 実際に、このアラートで週末のコスト変動異常を検知するなど一定の有用性を発揮しています。 しかし、この通知には問題点も存在します。お察しの通り、変動率や増加額を元にアラートを設定するにしても敷居値の設計が難しく、自動的なメンションを設計しづらいという点です。 なので、こちらの通知は「コスト変動・増加率の異常検出までのリードタイム」に有益性を見出し、CCoEチームがAWSアカウント全体の健全性を定常的に確認する目的で運用しています。 CCoE コスト異常検出 これは、コスト変動通知とは目的を別とし、 各AWSアカウント主管の管理者が確認するものとして設計 してあります。 弊社の場合、管理アカウントに請求をコンソリデートしているため、管理アカウントにて 全AWSアカウントの Cost Anomaly Detection モニター(Linked Accountタイプ) および、アラートサブスクリプション を設定しています。それらの結果は、クロスアカウントでCCoEアカウントのSNSにpublishされ、AWS ChatbotにてSlack連携させています。 コストの異常検出は組織ごとにモニターしたいとも考えたのですが、組織変更に対するモニター再作成の運用コストが高くつきそうなのと、主管するAWSアカウントがLinkedAccountsの上限10個を超えるような組織も存在するため、シンプルに1つのモニターで1つのAWSアカウントという構成にすることにしました。 しかし、モニターは 100リソースまでしか作れない 為、dev, prod 系のアカウントは同じモニターとしてまとめて、モニターの数を減らしています。 こちらのリソース作成用CFnテンプレートについては、管理アカウントへのCloudFormation実行のため、CCoEシステムのリポジトリとは別に管理し、動的にCFnテンプレートを作り上げる仕組みを整えています。 ハマった点としては、CloudFormation経由でリソースを作成した際に、一気に100近くのリソースを作成しようとしたため、CostExplorerのRate limit exceededに引っかかりました。そのため、各モニターとアラートサブスリプションの作成時に DependsOn属性を追加して、Rate limit を回避しています。 また、異常検出を ChatBotと連携させると、アカウントを特定する情報が AccountId しか表示されずに、パッと見でどのアカウントなのか判別が付きません。そこで、モニターと対になるアラートサブスリプションの名前に、アカウント名を追加することでどのアカウントなのか判別しやすくなるような工夫をしています。 コスト異常検出Slackメッセージ まとめ 弊社における、CCoEの取り組みの一部を紹介しました。 クラウドは利用しつづけることで、 最初はよかったとしても時間の経過とともに利用状態が負債に変化する ことが多々あります。例えば、時間の経過とともに意味をなさなくなったDR用のバックアップや、依存関係の問題でメンテが難しく、古いインスタンスタイプのまま運用しつづけているEC2などです。 これらの事例からもわかるとおり、 クラウドの健全性は、外部環境が常に変化することを意識し、それらの進化に追従しながらコスト・セキュリティコントロールをしつづけられる状態をどのように作れるかにかかっている と思います。 CCoEへの取り組みは千差万別で、組織のサイズによってはToo muchかもしれません。しかし、 逆に小さな組織であるほど、最初に整備しておくことで将来へのレバレッジが効かせられるという見方もできます。 自分が考えるCCoEとは、ただルールを作って共有するだけの組織ではなく、 可能な限り自動化を推進し、ビジネスの意思決定のスピードを早めるためにテクノロジーを活用できる組織 です。 こういった取り組みは、直接的には利益を産まずコストセンターとして見られがちですが、 組織のサイズに関係なく長期的な視点で有益である と自分は考えます。 本記事が、どこかの新しいCCoE立ち上げの参考になりましたら幸いです。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。フロントエンドエンジニアの根本です。 LIFULL HOME'S事業本部でtoB領域のプロダクト開発と、スポーツ関連の新規事業立ち上げに携わっています。 早速ですが、皆さんはUXエンジニアという職種をご存知でしょうか？ この記事では、UXエンジニアのスキルを身につけるため、新規事業開発の中でどのような取り組みをしているか紹介したいと思います。 目次 UXエンジニアとは？ そもそもなぜUXエンジニア？ 実際の取り組み データ分析しユーザー行動を可視化する GA(UA) / GA4を用いた定量分析 LogRocket / Clarityなどを用いた定性分析 インタビューやアンケート、コンセプトテスト 課題や仮説に対してプロトタイプを作成 開発を行い最終的な仕様を決定する 最後に UXエンジニアとは？ Jobs - Google Design によるとUXエンジニアとは下記と言われています。 You’ll partner with researchers and designers to define and deliver new features, translate concepts into living, breathing prototypes, and iterate on interactions, animations, and details to deliver the perfect experience. UX Engineers also collaborate closely with UX Researchers to user-test new concepts and assist engineering. 以下、Google翻訳 研究者やデザイナーと協力して、新しい機能を定義して提供し、コンセプトを生き生きとしたプロトタイプに変換し、インタラクション、アニメーション、詳細を繰り返して完璧なエクスペリエンスを提供します。 また、UX エンジニアは UX リサーチャーと緊密に協力して、新しいコンセプトのユーザー テストを行い、エンジニアリングを支援します。 上記のように、 リサーチ、デザイン、エンジニアリングといった幅広い領域を横断的に取り組む役割のようです。 企業によっても細かい定義など異なると思いますが、下記のようなスキルが必要になると言われることが多いように思います。 プログラミング・コーディングスキル Webデザインスキル マーケティングスキル ディレクションスキル コミュニケーションスキル etc... そもそもなぜUXエンジニア？ 実際の取り組み内容を紹介する前に、なぜUXエンジニアのスキルを身につけていきたいと考えたのかきっかけに触れたいと思います。 そもそもこの業界に入るときエンジニアではなくデザイナーとしてプロダクト開発に携わっていきたいと考えていましたし、デザインにはプロダクトを劇的に変える力があり、想像もしていなかったユーザー体験を生み出すこともできると思っています。 一方で、デザインを実装するスキルを身につけたり、エンジニアリングの仕組みをしっかり理解することで、デザインを考える上での可能性が広がるのではという考えもありエンジニアになったという背景があります。 とはいえ、エンジニアになってからもUI/UXへの関心が深まり、その中でUXエンジニアとはエンジニアとしてのキャリアと自分の興味関心を活かせる分野なのではと気づいたのがきっかけです。 LIFULLでは現在、UXエンジニアという職種は存在しませんがフロントエンドエンジニアとして、エンジニアリング分野の領域を超えどのように実践的にUXエンジニアとしてのスキルを身につけているのかここからは新規事業での取り組みにフォーカスして紹介したいと思います。 実際の取り組み データ分析しユーザー行動を可視化する どのようなサービスにするのか、ターゲットは誰なのか、といった施策立案の段階で現状分析を自ら行います。 普段データ分析は、マーケターや企画が主体で進めることが多いですが現状課題を把握するためにデータ分析のスキルを身につけて損はないと思います。 GA(UA) / GA4を用いた定量分析 GA(UA)を用いたセッション軸のデータ分析に加え、現在はGA4を用いたイベント軸のデータ蓄積も行っています。 サイト内のユーザー行動をイベントとして取得することでCVユーザーに多くみられる行動は何かという行動ベースでの分析が可能になりました。 施策立案時、現状はどのようにユーザーが行動しているかという分析を必ず数値にまとめています。 LogRocket / Clarityなどを用いた定性分析 定量分析と併せ、セッションリプレイツールを導入しユーザーの行動を観察することで課題発見するケースもあります。 実際、定性データから課題発見しCVRが向上した事例もあります。 GA4などでは連続的なユーザーの動きが追いづらいですがセッションリプレイツールでは、最初から最後まで実際にユーザーがどのような行動をとっているのかを観察できるため有用です。 インタビューやアンケート、コンセプトテスト その他、会員向けにアンケートやインタビューなどを実施することで会員の満足度向上やサイト改善に向けて取り組んでいます。 企画立案時、過去のインタビュー結果を参考にしながら解決策を検討することもあります。 課題や仮説に対してプロトタイプを作成 現状分析から見えてきた課題や仮説をもとに企画を立案しますが、その際必要であればカスタマージャーニーマップ、共感マップ、ペルソナなどの手段を取り入れながら検討しています。 自分はまだまだ上手く活用できておらず学習中の段階です...！ 求められるスキルとしてWebデザインスキルも上げていましたが、ワイヤーフレームなどを作成する際は、XDやIllustratorやPhotoshopなどのツールを積極的に利用しています。 デザイナーとコミュニケーションを取る際にこれらのツールを使えた方がスムーズにやりとりできるというメリットを感じています。 また、施策によってはプロトタイプ段階のものをUTしリリースするまでにプロダクトの品質を高める時もあります。 こういった場面ではUXリサーチのスキルが必要になるので修行が必要だと痛感しています。 開発を行い最終的な仕様を決定する UXエンジニアはデザイナーやエンジニアの間に立ちサポートする体制のところも多いと思いますが、新規事業ではリソースが限られているので最終的な開発まで自分で担当しています。 実際に動くものでデザイナーと最終的なインタラクションまで認識合わせできるので自分は積極的に開発にも参加していきたいと考えています。 最後に このように、UXエンジニアとしてのスキルを身につけていくためにはエンジニアの領域を超え、企画、デザイナー、リサーチャーなどさまざまな職種のスキルを横断的に身につけていく必要があります。 自分はまだまだ見よう見まねで実践している部分が多いので場数と成功体験を積み上げることで、UXエンジニアとしてのスキルを身につけていきたいと思っています。 また、LIFULLには企画、デザイナー、UXリサーチャー、データアナリスト、マーケターなどのプロフェッショナルが在籍しており、各専門職の方から色々アドバイスを頂いたり、時には協力しながら進める体制が整っています。 UI / UXを追求したプロダクト開発をエンジニアサイドから今後も推し進めていきたいと思います！ LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの松尾です。LIFULL HOME'Sの売買領域を支えるエンジニアチームのマネジメントを担当しています。 私はプロダクト開発チームでのコミュニケーションに関心があり、以前は プロダクト開発に関わる3職種の連携 についての記事を書きました。現在も有志メンバーで、プロダクト/チーム作りを「いい感じ」にする活動を行っています。 今回はその活動の中で、輪読会を通してプロダクト開発を振り返った話を紹介します。 輪読会で実現したかったこと 職種間での意見交換 前述の記事でも紹介したように、現在LIFULLのプロダクト開発組織は職能別に分かれており、各領域の専門性を高めやすい構造になっています。相対的に職種間での連携が希薄になる懸念もあるため、議論の場を積極的に設けるようにしています。輪読会の設計や書籍の選定においても「職種間での対話が増えること」という部分は重視しました。 担当マーケット間での意見交換 私の部署の担当領域は「売買」ですが、その中にも「新築一戸建て」「中古マンション」「注文住宅」などの区分があり、プロダクト開発チームも分かれて存在します。それぞれが異なるコンテキストで成長してきたチームですので、チーム間で意見交換するのも有意義だと考えました。 「プロダクトマネジメント」の理解 LIFULLではプロダクトマネジメントの教科書的な立ち位置で「 INSPIRED 熱狂させる製品を生み出すプロダクトマネジメント 」（以下、「INSPIRED」）を参考にしています。多くのマネージャーがこの書籍を読んだうえでプロダクト開発の改善に取り組んでいますが、現場では未読のメンバーも多かったため、輪読会をして考えをすり合わせようという話になりました。 輪読会の作り 参加者 職種、所属チーム、年次、入社区分の多様な14名で実施しました。 当日までの準備 自主的に参加を決めてくれたメンバーのみでの実施でしたので、全員が事前に書籍を読んできてくれることが期待できました。そのため、全員に各章で「印象に残ったところ」や「現場とのギャップ」を事前に記入してもらいました。万一事前に読めなかった場合でも、これらを読むことで議論に参加できます。 当日の議論 事前記入の内容を元に「改善できそうなこと」について議論しました。各回を区切りの良い50ページ程度に分け、全9回での読了となりました。 議事録のフォーマット: 事前記入部分と当日記入部分で分ける 輪読会を終えての気付き プロダクト開発組織としての課題 書籍の内容と現在の組織でのプロダクト開発とではギャップがある部分も多々あり、いくつかの課題（＝伸びしろ）を発見できました。議論の中では下記のような声が多かった印象です。 製品のビジョンを常に頭に置いて、長期的な視点での価値提供を心がけたい 顧客やエンドユーザーの理解にうまく時間を使っていきたい 1週間に10個くらいのペースでアイデアを検証できるしくみを目指したい LIFULLでのプロダクト開発 一方で、「他部署にあるノウハウを活用すれば、効率的により良いプロダクト開発に近付いていけるのでは」という意見もありました。 弊社には UXリサーチを専門とする部署 があり、いつでもユーザーテストやインタビューについての相談ができます。また、オンラインでインタビューができる uniiリサーチ というサービスも提供しており、社内でも活用されています。新規事業を専門に扱う部署では、日々高速にアイデアが検証されています。 今後は社内ももちろんのこと、社外とも積極的に意見を交換することでより良いプロダクト開発を目指していきたいと感じました。 まとめ 「INSPIRED」から多くの学びを得つつ、LIFULLのプロダクト開発に伸びしろを感じられた輪読会となりました。今回議論したことを具体的にアクションに移しつつ、より良いプロダクト開発チームを目指していきます。 最後に、LIFULLではともに成長していける仲間を募集しています。詳細は募集求人やカジュアル面談のページをご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング3Uの二宮です。 リモートワークでは、ふとした時に便利なツールやTipsを教えてもらうことって減ってしまってませんか？ そこで私たちは「個人的に生産性向上のためにやっていることをなんでも共有する」という内容のグループワークを実施し、実際にいくつかの面白いツールや方法論をいくつか知ることができました。今回はその内容を紹介します。 グループワークの目的や経緯 私たちの月次定例では毎回30分のグループワークの時間を取っていて、そこで様々なワークを行なっています。 以前のチームビルディングの記事 でも書いたように、私たちのユニットは複数のプロダクトを担当するグループに分かれています。そのプロダクトの状況やフェーズが異なるため、コミュニケーションの必要性は感じつつも、こうした機会をどう活かすかを試行錯誤しています。 今回「個人の生産性向上」に注目し、「個人的に生産性向上のためにやっていることをなんでも共有する」というテーマのグループワークをやってみました。その経緯を詳しく説明すると、次のようなものです。 私たちは普段、生産性向上の取り組みとして、PRのマージ数等のいくつかの指標を見ながら、それぞれのチーム（グループ）で改善活動を行なっており、一定の成果が上がっている 一方で、リモートワーク中は個人の開発ノウハウは伝えづらい。それを補完するものが欲しい ちなみに、他には次のようなワークをやりました。 新卒から他のメンバーへの質問（たとえば会社のことや、仕事の心構え、趣味のことなど） ECRSフレームワーク を使ってみて、自分たちの無くせる仕事を考えてみよう（これは他部署でやってよかったものを取り入れました💪） LT大会 繰り返しにはなりますが、メンバー個人の意見としても、リモートワークでは一人で集中して仕事するような時間は確保しやすい代わりに、隣の同僚に便利なコツを教えてもらうようなタイミングは減っているように感じます。100%のリモートではなく週に何回かは出社しているのですが、結局それぞれのグループ（プロダクトチーム）内でしかコミュニケーションできないことが多く、新型コロナウィルスの感染状況によって出社できない時期もあります。 そのため、こうした機会は久しぶりで新鮮な感覚でした。 実施した内容 やったことはすごくシンプルで、要約すると「ブレイクアウトルームに分かれ、個人的にやっていることをひたすら出して共有する」という内容です。 全体説明: 2分 チーム（ブレイクアウトルーム）に分かれて、JamBoardにひたすら挙げる: 3分 各チーム内で共有する: 20分 各チームから「これは是非ともみんなに共有したい！」というベストプラクティスを選んで共有する: 5分×3チーム 実際のJamBoardはこんな感じです。 話題に挙がったもの 次に、実際に薦められたものを紹介します。 ウルトラワイドモニター 私にとって特に衝撃的だったのが、 こちらのウルトラワイドモニター です。「画面を6分割(!)できるから快適だ」という話をしていて、普通サイズのデュアルディスプレイより快適さは増しそうです。 ただ、私の使っている机のサイズには大きすぎるので、個人的な採用は見送りました😅 また、机の上のスペースの有効活用のために、モニターアームを薦めている人も何人かいました。 WEBサービス すぐ使い始めたのは Google Cloud Search というサービスです。LIFULLではGoogle DriveやGmail、公式のアナウンスにはGoogle Groupsを使っていて、それらを一括で検索できます。 例えば、 以前このブログでも紹介されたLIFULL Tech Hubという社内カンファレンスイベント について調べてみると、次のように、公式アナウンスや当日の発表資料が一括で検索できることがわかります。 開発ツール ユニット内ではVSCodeの利用者が多く、当然そのプラグインも紹介されていました。レビューや相談時には、Open in GitHubは役立ちそうです。 Open in GitHub （GitHubの該当箇所のURLが取得できる） Edit csv （csvの中身をスプレッドシートのように編集できる） Jupyter Notebook （分析ツールのJupyter NotebookをVSCode内で利用できる。remote sshとの組み合わせ可） Awesome Emacs Keymap （キーバインドをemacsにする） 他にもツール関連では、次のようなものを挙げられてました。 fish shell を使う Karabiner-Elements を使って、US配列 Macのコマンドキー単体で英数/かなを切り替えられるようにする Scroll To Text Fragment Bookmarklet（指定の箇所までスクロールするURLを作るブックマークレット）を使う これは素のGoogle Chromeの右クリックで可能になっていました。便利〜！ Chromeの別ユーザーを作成して、複数のAWSアカウントにログインする 仕事術やTipsなど 「6~7割くらいで一旦レビューを出す」とか「一通り作ったら見せてみる」など、いわゆる仕事術もいくつか挙げられていました。 できるだけ早く終わらせる。6~7割くらいで一旦レビューを出す できるだけキーボードのショートカットを使う。そのためにマウスを禁止する！ 文章や言葉の前に、手書きで図を描いて考える VSCodeでお気に入りの画像を背景にすることで業務効率をアップさせる 3つ目は私も実践しています。これがそのまま人に共有できると便利なので、もっとホワイトボードっぽいツールが発展してきてほしいですよね…。 まとめ 自分が当たり前だと思っていたツールや方法も、意外と他の人から見ると知らないもので、「え、そんな便利なものあったの」と思うこともあります。こうしたグループワークを行うことで、簡単に棚卸し&共有できそうです。 また、この定例の後でもしばらくチャットで雑談が盛り上がっていて、便利ツールの紹介や自慢話は、エンジニアならいつでも盛り上がる鉄板ネタなんじゃないかとも感じました。もしかすると初対面同士のアイスブレイクにも向いているテーマなのかもしれません。 最後に、LIFULLでは一緒に働く仲間を募集しております。興味を持っていただけた方は、募集求人やカジュアル面談のページもご覧ください。 hrmos.co hrmos.co

　こんにちは！LIFULLプロダクトエンジニアリング部の 鄭 在淳（ジョン・ジェスン） です。 2022年4月1日に新卒で入社して、4月末に日本に入国したLIFULLの韓国人エンジニアです。 　この記事ではコロナパンデミックの中で、どのような過程を通じて外国から入社し、リモートワークでどのように研修と業務に取り組んでいるのかについてお話したいと思います。始まる前に 中村さんの LIFULLの新卒エンジニア研修 in 2020 趙さんの 外国人が日本に来た３年間の生活×お仕事 のような記事もありますので、関心がある方は是非一緒にご覧ください。 目次 目次 入社前 外国から入社することに対する不安感 入社1ヵ月前に日本入国制限解除 リモートで参加した入社式と新卒研修 入社後 LIFULLでのリモートワーク リモートワークのための様々なツール 配属後 自由なチームコミュニケーション 多様に協業する開発カルチャー 最後に 入社前 外国から入社することに対する不安感 　私のように日本または海外で就職を考えている方々が最も不安に思っている部分が「もし、色々な事情で入社日前に入国できなかったらどうしよう」ということだと思います。 　特に、まだコロナパンデミックが流行っているので、さらに不安を感じると思います。 昨年、私も韓国に住んでいましたので、すべての選考をオンラインで行って内定を受けましたが、「もし入国できなくなったらどうしよう？」という不安感がありました。 　しかし、LIFULLにはリモートワークのための社内システムやツールなどが導入されており、私のような外国人社員がCOVID-19のような特別な事情で日本に入国ができなくなってしまったとしても、海外にいながら入社し業務を開始できたり、日本の銀行口座がなくても給与を国際送金で受け取れる仕組み等をパンデミックが発生した後に急ぎ整えてくれていました。 　こういった入社前の不安に対して、新卒採用担当者から内定後の労働条件の説明と共に詳しく説明して貰えたので、韓国から日本の会社に入社することに対して安心できました。 入社1ヵ月前に日本入国制限解除 　幸い入社1ヶ月前、ビジネス目的の日本入国制限が解除され、入社日に合わせて日本に入国できるようになりました。 入社前に連絡を取り合っていた同期たちと会えるというときめき、新しい場所での新生活を始めるというドキドキ感などがあったので、初めて入国制限解除ニュースを見た時はとても嬉しかったです。 　しかし一方で、1カ月以内に両替や家探し、書類申請や発給などの入国に必要な準備をすべて終えられるかという悩みがありました。そのように一人で悩んでいたところ、新入社員教育を担当する人事担当者が先に連絡をいただき、「入国を急がなくてもいいので、必要な手続きや準備が終わった後に入国日程をゆっくり調整しましょう」とおっしゃってくださいました。 　このように配慮して頂いたおかげで、私は焦りを感じずに少しずつ入国準備をすることができ、入社日以後に行われた新卒研修にも集中して参加できました。 リモートで参加した入社式と新卒研修 　LIFULLでは新入社員がリモートワークに関係なく、スムーズに入社準備ができるよう業務に必要なPC（エンジニアとデザイナーはWindowsとMacの中で自由に選択可能）と教材を自宅に送ってくれます。私も韓国に配送して頂いてスムーズに入社準備ができました。 　また、オンラインとオフラインで並行して行われた入社式でも、両会場の状況をリアルタイムで共有して頂いたおかげで、リアル感と満足感を感じながら入社式を楽しめました。その後、オンラインで行われた新卒研修を受けていたところ、連休のゴールデンウィーク中に日本に入国し、約3ヶ月間生活を続けています。 入社後 LIFULLでのリモートワーク 　最近、コロナウイルスによって多くの方がリモートワークを経験したことがあると思いますが、「リモートワークの方がかえって不便だ」と思っている方もいらっしゃると思います。特に、私のように引っ越し直後にインターネット環境が整っていない状態で、すぐにリモートワークをすることが難しくなるかもしれません。 　しかし、LIFULLでは、業務用として全社員に支給されているiPhoneのデータテザリングを活用すれば、場所の制約なしに（周辺のセキュリティ対策が完備しているという前提の下で）リモート勤務ができます。 私も入国直後、約3週間問題なく業務ができました。そして、社内では様々な地域に拠点がある LAC （自社の地域創生サービス）に行ってDigital nomadを追求している方もいらっしゃいます。 　また、フレックスタイム制度があり、コアタイム11～16時は勤務する必要がありますが、1ヵ月の所定労働時間を満たせば、始業と終業時刻を規定の範囲内で自分で決められます。規定の中で、自由に勤務時間帯を決定できるので、リモートワークとシナジー効果が発揮され、最高の業務効率を上げることができます。 リモートワークのための様々なツール 　LIFULLではコミュニケーションによく使われるメール以外にも、全社コミュニケーションツールとしてSlackを導入しています。その他にもGoogle WorkspaceやJira・Confluenceなどのツールも多様に導入していて、全社員とコミュニケーションを取ったり、業務に必要な各種申請や資料検索をオンラインで簡単に行うことができます。 　特に、うちの部署では「Gather Town」を導入しており、リモート勤務中にもリアルタイムで自然にコミュニケーションができます。また、スクラムを効率よく進めるためにMiro、Plapoなども幅広く導入しているので、リモート勤務の生産性が向上しています。 配属後 自由なチームコミュニケーション 　現在、LIFULL HOME'Sのプロダクトエンジニアリング部に配属され、主に LIFULL HOME'S 不動産アーカイブ の開発業務を担当しています。LIFULLにはメンター制度があり、配属後の技術的なオンボーディングをサポートしたり、「コミュニケーションシート」や「基礎力チェックシート」などを活用した毎週の振り返りを通じて、考え方やキャリアなど幅広い視点について交流ができます。 　そして、週1日はコミュニケーションデイ（コミュデイ）に指定されていて、オフィス勤務（上長の承認で調整可能）をしています。コミュデイには各グループまたは部門のメンバーが対面業務を進めることで、関係の強化を図ることができます。私は初出社日にコミュデイを終えて、先輩社員たちと一緒に会社の近くの居酒屋で楽しく飲み会をしました。 　また、チームビルディングには社員1名あたりの部内コミュニケーション費が支援され、私が配属されている部署では先日の6月、 高尾山LAC に行ってきました。同じ部署の組織員たちがお互いに知り合うプログラムを実施し、BBQや懇親会などを楽しみながらメンバー間の距離感を縮めることができました。 多様に協業する開発カルチャー 　私が部署に配属され初めて実装した施策は、新機能である 物件の画像一覧ページ でした。新機能を実装して、既存のプロダクトに追加することでしたので、基本プロダクトの仕組みを損なうことなく機能仕様書に合わせて実装することが重要でした。 　ただ、ドキュメントで作成する機能の仕様書だけを見て実装するのではなく、エンジニアと企画者、デザイナーが１つのチームになってプロダクトを運営しているため、開発中に困ったり大変だったりする点があれば、いつでもチームメンバーと相談できます。特に、うちのチーム内で導入している「Gather Town」を通じて気になることがあれば、簡単に声をかけて素早く解決できました。 　また、チーム内にはプロダクト管理のためのスクラムフレームワークを導入しています。スプリントを開始する際、チームメンバー全員が期間内に創出しようとする価値について計画（スプリントプランニング）を立てます。スプリント終了前にはお互いに成果物についてレビュー・称賛し（Winセッション）、KPT方式で振り返り（レトロスペクティブ）しています。このようなスクラムイベント以外にもソースコードレビュー・テストなどを行い、持続的な改善による柔軟でスピーディーな成果を出しています。 最後に 　LIFULLのエンジニア組織は エンジニアとして経営をリードする ことで活躍するというスローガンを掲げています。短期的に技術の幅を広げるだけでなく、技術を手段として中長期的に社会課題解決に貢献していくことを目指しています。 　LIFULLのコーポレートメッセージである「あらゆるLIFEを、FULLに。」を実現することには国籍、年齢などの制限はないと思います。私と一緒にLIFULLの同志になって、価値創出を最大化して行きませんか？ hrmos.co hrmos.co

いつもお世話になっております。検索エンジンチームの秀野です。 試験的な取り組みとして、社内通貨LIFULL COINを使って新規事業提案制度の審査会で投げ銭投票を行いました。結構時間が開いてしまったのですが、その時の紹介をしたいと思います。 LIFULL COINについては、過去に紹介したことがあるので、よろしければこちらの記事もご覧ください。 社内通貨LIFULL COIN x Slackでピアボーナス - LIFULL Creators Blog 新規事業提案制度SWITCHとは LIFULLには、SWITCHという新規事業提案制度があります。年間150件以上の提案があり、そのいくつかは事業化もされています。 事業化フロー中に何回か審査があり、最終審査会では従業員も発表を聴くことができます。その最終審査会で、LIFULL COINを使って従業員に投げ銭投票をしてもらいました。 投げ銭投票を導入することで、従業員も評価に参加することができるようになります。 それによって、従業員はより当事者意識を持って自社の新規事業提案を聞くことができますし、発表者にとってもより多くの人の関心度や評価を知ることができるのではないかと思います。 SWITCH - LIFULLの社内新規事業提案制度 | LIFULL STARTUP STUDIO LIFULL COINで出来たこと 投げ銭投票の説明をする前に、簡単にLIFULL COINで何が出来るか説明します。LIFULL COINには通貨として基本的な機能があります。 社内通貨として コインの発行（Mint） コインの焼却（Burn） Webベースの口座管理アプリケーション 口座の開設 残高確認 送金 送金履歴 コインの分配（クールダウン型ベーシックインカム） Slack bot リアクションに連動したコイン付与（ピアボーナス） ピアボーナス受信通知 残高確認 ピアボーナスランキング なので、投げ銭投票を行うには、下記のような手順を踏めば比較的簡単に実現できると思っていました。この時までは。 発表者の口座、聴衆（従業員）の各口座、を作成 聴衆の口座にコインを投票用に分配 聴衆が自身の口座から、発表者の口座にコインを送金（投げ銭投票） 発表者の口座ごとに投票金額を集計 最初の投げ銭投票 審査会での投げ銭投票は何度か行われました。 聴衆はスマホ片手に発表を聴き、任意のタイミングでコインを投げ銭します。投げ銭は、手元の10000コインから定額（100コイン/500コイン/1000コイン）をボタン1つで送ることができます。 発表を聞いていて感心したら、そのタイミングで1000コインボタンを3回押して3000コイン投げ銭する、そんなイメージです。 出金を行えるのは、秘密鍵を使って振込先となるスマートコントラクトをデプロイした発表者のみです。期間指定で着金と出金を制御して、投げ銭と総取りが可能な期間を制御しました。 不正投票に対する懸念点 LIFULL COINはブロックチェーンで管理しているので、送金を行う場合は秘密鍵での署名が必要になります。当時かぶれていた私は秘密鍵をユーザー側で管理したいと思い、ブラウザのローカルストレージに保存するという罪を犯してしまいました。ダメなことは分かっていたのですが、社内システムだし、鍵が盗まれても実害はないし、一旦いいだろうという判断(？)です。 その結果、良くも悪くもブラウザのプロファイル単位で口座開設が可能になり、投げ銭投票の際に複数口座を開設し不正投票を行える、という懸念がありました。 LIFULL COINには、利用者全体の価値観で評価された価値にコインを発行するという目標もあったので、話し合いの結果従業員の価値観に任せてみることにしました。不正投票があったらあったで、そういうことだったというだけです。 ド直球の不正投票 審査会での投げ銭投票自体はつつがなく行われ、投票結果の発表、表彰まで無事に行われました。 しかし、結論から言ってしまうと、ここで優勝した発表者に対して不正投票が行われていました。複数の口座を開設し、コインを受け取り、短時間で大量に投げ銭するというド直球のものでした。いい負荷テストになりました（半壊した）。 ちなみに、投げ銭投票で優勝した発表者は、不正がなくても優勝していました。不正分のコインを差し引いても、最もコインを獲得していたのです。そのため、表彰は結果通りに行われました。 残念ながら人間はそんなに強くないようです。今回の件は次回への課題となりました。 最後の投げ銭投票 しばらくして、またSWITCHの審査会と投げ銭投票が行われました。前回の投票から基本的な仕組みは変わっていません。 前回、不正投票があったことから何らかの対策を考える必要がありました。いくつか案がでたものの、どれもコストがかかりそうだったので今回は「クアドラティックボーティング（ Quadratic voting ）」という投票方法を参考にして対策を考えてみました。以下QVと略します。 クアドラティックボーティング（Quadratic voting）とは 一言でいうと「金で票を買えるが、1票買うごとに価格がえらく高騰していく投票方法」です。 また、下記のような運用ルールがあります。 投票者は一定のコインを付与される 票を購入して投票できるし、買わずに蓄積することもできる 票を購入するのに必要なコインは となる 1票買うと1コイン、2票買うと4コイン、3票買うと9コイン、・・・というように合計 票を購入するのに必要なコインは となる仕組みです。 言い方を変えると、1票目は1コイン、2票目は3コイン、3票目は5コイン、・・・となります（これをMarginal Costと言います）。 QVについてはこちらの記事が詳しいです。 「個人が公共財に影響を及ぼすために支払うコストは、個人がもつ影響の割合ではなく、その二乗（quadratic）に基づく必要がある」というなぜ票数の二乗なのか、といった説明がなされています。 alis.to 不正投票防止の工夫と欠点 QVにはいくつか欠点もあるようです。 コインを配布し蓄積ができることで、談合によりコインの融通や買収が行われやすい点です。 こういった問題は既存の投票でも起こりうるものの、1票目が安いことからコインの融通より投票者の買収のほうが行われやすそうです。 不正をなくす仕組みのせいで不正されては元も子もないので、投票者にはQVを導入することを伏せたまま投票してもらいました。 投票者は投票したコイン数がそのまま発表者の得票数になっていると思っているはずです（コイン数＝得票数）。 実際は、投票されたコイン数の平方根を得票数として計算しました（ ＝得票数）。 この仕組みでも、大量の投票があった場合は少なくない得票数に換算されてしまうのですが、前回の経験からその前にシステムが高負荷で全壊するはず、という確信がありました。 結果 まず、不正自体が行われませんでした・・・いや、それでよかったのですが。 発表から集計、表彰までつつがなく行われ無事に終了することができました。 QV自体の感想としては、今回の仕組みだと元々QVのメリットの1つである「投票者個人の思いの丈」を乗せるような投票はできなくなるのですが、優先順位付けを行う投票では有効なのではないかなと思いました。 今回のように様々な社会課題に対する解決策が並び評価される場では、やはり投票者の関心度を票に乗せられるQV本来の仕組みが活きるように思います。 また、いずれ機会があれば集計処理だけでなく、票をNFT化して購入から投票まで実装することで、社会課題解決への共感や関心の高さを票に乗せられるような仕組みを作りたいと感じました。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

こんにちは。エンジニアの加藤です。LIFULL HOME'Sの注文住宅領域を支えるエンジニアチームのマネジメントを担当しています。 弊社では昨年度よりKPIマネジメントを導入し、さまざまな組織課題の解決や目標達成に向け活用しています。 私がマネジメントするエンジニアチームでも同様に開発生産性向上を目標とし、KPIマネジメントの手法を用いて実現への取り組みを実施してきました。 そのような中、今回はこの半期においての私のチームでの取り組みについて紹介したいと思います。 KPIマネジメントの概要や今までの取り組みについては以前 こちら のブログでも投稿いたしましたので、よければ併せてご覧ください。 www.lifull.blog CSF・KPIの選定 KPIマネジメントは4MCと呼ばれる4つの主な要素（Goal, KGI, CSF, KPI）から成り立っています。 そのうち、GoalとKGIはエンジニア組織全体で目線をそろえるため、共通的な目標・指標を設定しています。 Goal 開発生産性の向上 KGI 一人当たりのPullRequestマージ数（前期比115%UP） そのため、各チームでは今期を通して一人当たりのPRマージ数を115%増加させるために必要なCSF、KPIの選定を行います。 私のチームではこれらの選定にあたりまずはデータを元に現状を把握するところから取り掛かりました。 現状把握 「時間」に焦点を当て、総業務の内どれだけの時間を開発またはそれ以外の業務に費やしているのか、実装プロセスの内どの工程にどれだけの時間を費やしているかを整理したものが以下の表となります。 構成要素 コントロール可否 計測可否 前期の状況 総業務時間 全体 × ◯ 開発時間 ◯ ◯ 54% 運用時間 ◯ ◯ 3.6% MTG時間（組織系） △ ◯ 前期までは測定不能 MTG時間（開発系） ◯ ◯ 1タスクあたりの開発時間 全体 ◯ × 開発着手からPRマージ ◯ × 1stコミットからPRマージ ◯ △ 平均：254.27時間（約10.6日） 開発着手からPR作成 ◯ × 1stコミットからPR作成 ◯ ◯ 平均：130.94時間（約5.5日） PR作成から1stレビュー ◯ ◯ 平均：54.95時間（約2.3日） PR作成からマージ ◯ ◯ 平均：123.33時間（約5.1日） CSFとKPIを選定する上でのポイントとして、KPIマネジメントでは以下のことが言われています。 CSFは現場でコントロールでき、努力で変化するプロセスであること KPIは即座に計測・入手できる指標であること これらから、各データに対してはコントロール可能であるか、計測可能であるかどうかも併せてまとめました。 選定 データを見える化したことで意外な事実に気付きました。 これまでは主観的に社内関係者からの質問・相談対応や定期・不定期問わずの運用業務が多く、開発時間を逼迫する要因だと思っておりました。 しかし、実際のデータを確認することで運用業務にかかる時間は4%弱しかなく、50%以上の時間は開発業務に充てられていたのです。 そこで、今改善すべきプロセスは開発に充ている時間を増やすことではなく、開発工程の中にあると想定し一つの時間に着目しました。 それが「 PR作成からマージ 」の時間です。 この時間は主にコードレビューにかかる時間を表していますが、平均約5.1日かかっており、実装時間（1stコミットからPR作成）とほぼ同等の時間を要していることが分かりました。 そのためコードレビューにかかる時間を短縮することが、開発生産性を高めるための最も重要なプロセスであるとしてCSFに選定しました。 CSF コードレビュー時間の短縮 KPI PullRequest作成からマージまでのリードタイム PDDSサイクルを回す 4MCが決定したら日々の業務の中で実行し改善サイクルを回すことが重要です。 PDCAが普段よく耳にする言葉であるかと思いますが、 最高の結果を出すKPIマネジメント の中では PDDSサイクル が提唱されています。 PDDSサイクルは Plan （よく考え）- Decide （すばやく絞り込み）- Do （徹底的に実行し）- See （きちんと振り返る）で構成されます。 私のチームでもPDDSサイクルを意識し日々の改善活動に取り組んでいます。 具体的なアクションに落とし込んで実行する CSFはKGIの達成のため最も重要なプロセスとなりますが、それだけ決まっていれば日々の業務の中で行動を変えられるわけではありません。 そのため私のチームでは、CSFの実現につながる具体的なアクションを 一つ 週次で決め、実行しています。 今まで実行したアクションの実例を少し紹介します。 長期間残っているPullRequestの整理 改善活動を実行するためには、正しくデータを計測できることが重要です。 しかし、現状長い時間コードレビューされず放置または後回しにされたPullRequestが存在し、それらがあるタイミングでマージされることで直近のリードタイムが正しく計測できない問題がありました。 そのため、まずはそのような長期間残っているPullRequestをすべて洗い出し、不要な修正はClose、必要な修正は優先的にコードレビューすることですべてのPullRequestの整理を行いました。 その結果、計測結果にノイズを発生させるようなPullRequestはすべてなくなり、正しく計測できる状態へと変化しました。 コードレビュー期限の明確化 コードレビューの時間を引き伸ばす次なる要因としては、プロジェクトチーム横断的なタスクにありました。 基本的にチームの各メンバーはプロジェクトに参画し、主にプロジェクト内で開発活動を行うことになります。 一方で突発的な開発作業やリファクタリングなどのコード修正が発生することもあり、これらの実装およびコードレビューはプロジェクトとは切り離して実施されます。 そのため、このようなタスクはついつい後回しにされがちで結果PullRequestを作成してから放置される傾向にありました。 これらの課題を解決すべく、コードレビュー依頼者はあらかじめレビュー期限を明確化し、期限内にレビュー可能なメンバーが引き受けることとしました。 レビュアーの指定 レビュー期限を明確化することで、横断的なタスクであっても長期間PullRequestが残り続けることはなくなりましたが、次なる課題も見えてきました。 コードレビューを依頼する際Slackでメンバー全体に投げかけているのですが、お見合いが発生しレビュアー決定まで無駄な時間が発生していたのです。 そのため、依頼者がレビュアーを指定し、直接調整することでほかのメンバーとのお見合いを防ぎました。 定期的に計測し振り返る アクションを実行することで日々状況が変化するため、その変化を計測し振り返り、次なる打ち手を検討することが重要となります。 私達は毎週の定例ミーティングにて以下の枠組みで計測・振り返りを実施しています。 KPI・KGIの計測結果確認 今週のアクションに対しての振り返り 次週のアクション決定 これらPDDSサイクルを実行することで、コードレビューにかかる時間は徐々に短縮され結果として表れてきています。（PR作成からマージ：123.33 → 36.55） KPI計測結果（投稿時の直近数週間） まとめ 今回はKPIマネジメントを活用した開発生産性向上への取り組みを共有させていただきました。 組織課題について同様に頭を悩ます方も多くいらっしゃるかと思います。この記事がそういった方々の一つのヒントになれば幸いです。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

はじめに こんにちは！AI戦略室の曽迪(ｿﾃｷ)です。LIFULL社内の技術や知見を集結させて議論するイベント: LIFULL Tech Hubの運営リーダーを担当しています。今回はLIFULL Tech Hubについて紹介します。 LIFULL Tech Hubとは LIFULL Tech Hubとは、過去に「AI戦略室成果展示会」という名称で開催されたイベントをさらに発展させた全社カンファレンスです。 そもそも私が所属するAI戦略室は、事業部とは独立した組織であるため事業部との距離感が生じやすく、研究開発組織として活動や成果を発信し会社全体に存在意義を認知してもらう必要がありました。「AI戦略室成果展示会」はその流れで開催されたものとして、以来定期的に全社イベントとして開催してまいりました（ 過去のAI戦略室成果展示会の紹介 ）。 これらのイベントを開催する過程において、社内には私たちと同じ課題を持っている部署やメンバーがいることに気づきました。つまり、近視眼的なプロジェクトにおいては日の目を浴びないような、埋もれがちな技術や知見を持っている社員が想像以上に多いということです。 そこで「AI戦略室成果展示会」という名称を、LIFULLのコアな技術や知見が集まる場という意味を込めて「LIFULL Tech Hub」という名称に変更し、職種を問わずに誰もが社内の技術を発信・傾聴できる社内カンファレンスとして開催することになりました。 今期の開催状況 今期のLIFULL Tech Hubは6月7日にオンラインで開催されて、来場者が合計140名の大盛況となりました。今期は15件の発表があり、エンジニアだけではなく企画職も登壇され、幅広いテーマで発表が行われました。発表はZoomのブレイクアウトルーム機能を利用したポスターセッションで行われました。 発表テーマ 発表は合計15件ありましたが、今回はその中の３つをピックアップして紹介したいと思います。 3D間取りの現状と今後の活用 こちらはAI戦略室が担当しているプロジェクトです。 LIFULLでは物件の間取り図から3Dイメージを作成する技術に取り組んでおり、2021年3月より、「LIFULL HOME'S 3D間取り」としてサービスを公開しました。このサービスでは、3Dの物件イメージを構築することで、まるで実際に物件の内見ができるかのような体験ができるサービスとなっています。3D間取りの現状と今後の活用について紹介しました。 開催中の様子 過去に投稿した3D間取に関する記事： 間取り図をディープラーニングで解析して3Dモデルをつくる - LIFULL Creators Blog KEELチームと話そう KEELチームは全社アプリケーション実行基盤 KEELを開発したチームです。 エンジニアと何でもカジュアルに相談や疑問、リクエストなどはここで話せます。エンジニア向けのKEEL導入の相談、インフラ周りで困ったことなどの相談する場です。 KEELの資料 過去で公開したKEELに関する記事： Ltech#20 Kubernetesを用いたアプリケーション実行基盤の取り組み 開催レポート - LIFULL Creators Blog LIFULLの全社アプリケーション実行基盤 KEEL について - LIFULL Creators Blog RSpecの技術的負債をチームで解消した話 RSpecの技術的負債をチームで解消した話の内容を中心に、運用しやすいテストコードのあり方やテストコードの悩みについて議論しました。そのほか、売却査定のチームで行ったCodeBuildによるCI導入やフロントエンド領域のVite導入についてや、開発スピードを上げるためのチーム作り方の秘訣など、盛り上がりそうなテーマで話しました。 開催中の様子 過去で公開した関連記事： RSpecの技術的負債をチームで解消した話 - LIFULL Creators Blog Vite Backend Integration 👋 レガシーJS - LIFULL Creators Blog 特別講演 LIFULL Tech Hubは通常の発表後、特別講演も設置しています。特別講演は他社から研究者を招待しています。特別講演は技術の話以外に、働き方の話も紹介しています。 AI戦略室データサイエンスパートナーの鹿内 学氏に「データではじめようイノベーションを目指す組織開発」というテーマで話していただきました。 HRの分野に精通した同氏が、イノベーションを起こす組織に共通する「信頼」を構築するために、日々のデータをどのように見るべきかを事例を交えつつ紹介していただきました 人事組織の社員のみならず、ものづくりに携わる私たちにもたいへん参考になりました。 開催中の様子 運営上の工夫 誰でも気軽に参加できる環境作り 全社イベントにおいては心理的な負担・作業的な負担を最小限にするために、発表形式としてポスターセッションを選択しました。発表テーマ不問、ポスター（スライド）1枚あれば誰でも発表できます。自分の都合に合わせていつでも入退場可能な形式を整えました。運営側としては最小限のコストで最大限の効果を目指して運営できました。 案内と集客 発表者として参加する場合、エントリの方法からイベント当日の発表までの流れなどの情報を簡潔に準備しました。発表者は資料一枚を見れば、イベントの参加方法が分かります。 聴講者に関しても、全社広報で頻繁に開催の案内を出しました。多くの部署に参加していただき交流を活性化させたいので、上位層の承認を得てカレンダーに予定を追加し、全社的な交流を図りました。 部署間で交流することで知見を共有できるような環境作り 技術と成果物などの紹介だけではなく、アイデアベースの議論などさまざまなテーマの情報発信が可能です。コミュニケーションが活性化するのため、発表形式をポスターセッションにしています。聴講者と発表者間のコミュニケーションがしやすくになります。普段は拾えない他部署からの声を拾うことによって、部署間の横断的な交流による知見の共有ができる場を作りました。 開催後の反響・影響 LIFULL Tech Hubは社内からさまざまな反響がありました。開催後のアンケートの結果、4.3点の高い満足度（5点満点）になりました。参加者からの声としては、 「プロジェクトの技術共有を期待していました。実際、期待通りの共有を受けることができて満足です。」 「技術で解決できそうなアイデア出しをするような場所にもなっていたので、とても楽しかったですー！」 というポジティブフィードバックがありました。 一方で、課題としては、 「社内の多くの部署に参加してもらうためには、さまざまなSlackチャンネルで広報して欲しかった。」 「LIFULL Tech Hubに参加できなかったという方から、当日の各発表内容、動画で見れないかご要望をいただきました。」 といったような集客や運営方法に関するフィードバックをもらいました。次回以降を開催する際には、より多くのメンバーが気軽に参加できるような運営体制を整えていきたいです。 終わりに このような誰でも技術やアイデアを発信できる場は、全社的に必要かと思い、これからも継続的に開催していく予定です。LIFULL Tech Hubが社内にさらに良い影響を大きくするために、今後は開催後に部署間の連携が促進されるようなカンファレンスにしていきたいと思います。 hrmos.co hrmos.co

こんにちは！ LIFULLエンジニアの吉永です。 本日はエンジニアの自己研鑽について、自分はどんなことをやってきたかを紹介します。 ソフトウェアエンジニアを目指している人や、ソフトウェアエンジニアとして今後のキャリアプランに悩んでいる人の参考になれば幸いです。 私については、以前noteへ投稿した下記の記事に自己紹介と略歴が記載されているので、宜しければご参照ください。 note.com アジェンダ 自己研鑽の方法と変遷について 2007年～2009年頃 2010年～2014年頃 2015年～2019年頃 2020年～現在（LIFULLに入社してから現在） まとめ 最後に 自己研鑽の方法と変遷について 私は2007年4月にソフトウェアエンジニアとしてのキャリアをスタートし、2015年3月までは放送機器の組込ソフトウェアエンジニアとして働いていました。 思い返してみると、自己研鑽の為のインプット手法や内容がだいぶ変わってきたので、それぞれの年代ごとにざっくりと内容をまとめます。 2007年～2009年頃 新卒で配属されてからの3年間はひたすら先輩の作成したプロダクトのコードや設計資料を読み漁り、 ドメイン知識を身に付けることに重きを置いてました。 よって、自己研鑽もドメイン知識に役立つ事柄が多く、例えば書籍で言うとマスタリングTCP/IPの 入門編 と 応用編 、 C言語による標準アルゴリズム事典 などを購入して読んでました。 当時は組込ソフトウェアエンジニアなので、メインの開発言語はC言語、組込機器でもネットワークに接続することが必須となり、システムインテグレーターの方々が放送システムに採用する際にSNMPによるステータス監視に対応できているか？ファームウェアアップデートなどのメンテナンスはFTPやHTTPを用いて、ネットワーク越しにできるように考慮されているか？などが求められており、パケットキャプチャソフトでTCP/IPパケットをキャプチャして、デバッグ時にどちら側の問題かの切り分けをする必要もあり、 これらの知識を得る為にネットワーク知識をつけました。 また組込機器はROMサイズがかなりシビアでC言語のサードパーティーライブラリを採用することが難しく、世の中一般的にはOSSで公開されている、 枯れた技術でも自分たちで実装する必要 （例えばJPEG画像のデコードとかトゥルータイプフォントの展開処理とか）もよくあったのでアルゴリズム事典のコードを参考にしたり、 玄人の書いた難解なコードも読み解けるよう にしていました。 また、チーム内でトレンド情報にアンテナを貼ろうという施策を実施していた時期は毎日チームメンバーが日替わりで気になったIT系のニュース記事をメールで共有していたので、 IT系のプレスリリースはこの頃から良く見るようになっていた と思います。 2010年～2014年頃 この頃辺りから組込機器だけでなく、Windows GUI開発を行う機会も増え、Windows GUI開発ではVisual C++というMSが独自に作ったC++ベースの言語を使っていたので、学生時代に少しだけ勉強して、 雰囲気で理解したつもりになっていたオブジェクト指向についてを再度勉強しなおしていました。 なので、独習シリーズの C++ / Java / C# と 独習UML を購入して良く読んでいました。 結果的にはC++で開発する時だけでなく、組込機器の開発時にC言語でも オブジェクト指向を意識してプログラミングできるようになっていた り、UMLのアクティビティ図やステートマシン図、コンポジット構造図はWindows GUIだけでなく、組込機器の設計資料などにも採用するようになりました。 ※それまではわりとフリーフォーマットで図を描いていて、フローチャートぐらいしか規定された図がなかったのでUMLである程度のフォーマットを規定してくれていることが先輩方からも好評でした。 あとは2014年頃にAndoroidとiOSのアプリをプライベートで作成したりして、直接当時の業務と関りはないが、色々な知見を得るってこともやったりするようになりました。 2015年～2019年頃 2015年4月からはWebアプリケーションエンジニアに転身したので、インプット方法はそれまでの書籍メインから、 Webで検索するというのがメインになっていきました。 ※組込系はそもそも環境依存系の問題なので、ググっても情報が見つからないことが多く、Windows GUIもその当時は既にC#がメインの開発言語になっており、C++関連の情報はヒットしても古い情報ばかりみたいな感じだったので・・・ 2016年からは新入社員向けのプログラミング研修講師をやるようになったことで、インプット中心だった自己研鑽ですが、 プライベートでのアウトプット機会が増えていきました。 講師をやるうえで、自分が理解していることを目の前にいる受講生にどのようにして伝えたら分かりやすいだろう？この人はどんな個所でつまずいているんだろう？ということを考えるようになったので、 アウトプットして、自分で見返してみることで客観的に見れるようになっていった と思います。 アウトプットの代表的なものでいうと、Webで新しい言語に取り組む際によくやっていたのは、学生時代に作ったLinuxで動作するGUIのオセロアプリケーションをその習得対象の言語で書きなおし、言語の基本的な書き方を習得するようになりました。 github.com 上のリンクは個人のGitHubアカウントですが、色々な言語でオセロを実装しています。 コードは正直、自分で見返してみてもイマイチなのですが、手っ取り早くその言語に慣れるのに都合がよかったので、この手法をよくとっていましたね。 2020年～現在（LIFULLに入社してから現在） LIFULLに入社してからは資格取得奨励制度があり、 会社としても資格取得を応援してくれている ので、IPAのスペシャリスト試験を受験して資格を取得することにも取り組むようになりました。 IPAのスペシャリスト試験は自分自身の理解度の確認、理解したつもりだった事柄を再度復習できることから、継続的に取り組んでいます。 下記はその取り組みの結果です。 2020年10月・・・情報処理安全確保支援士試験 合格 2021年04月・・・ネットワークスペシャリスト試験 不合格 2021年10月・・・データベーススペシャリスト試験 合格 2022年04月・・・ネットワークスペシャリスト試験 不合格 勉強方法は始業前か終業後に30分～60分くらい参考書を読んだり、過去問を解いたりを試験の2ヶ月前くらいから継続的に行うようにしています。 ネットワークスペシャリスト試験が自分としては難関なのですが、諦めずに来年もまた受験しようと思っています！ また、LIFULLに入ってからは エンジニアの発信を組織が奨励してくれている こともあり、Qiitaに投稿する機会が増えました。 qiita.com Qittaにアウトプットすることで自分自身の備忘録にもなり、普段の業務で作成する設計資料類を作成するスピードが向上した気がするので、アウトプットを定期的に行うことはとても良いと思います。 まとめ インプットは大事だがアウトプットも重要なので、 学んで満足の状態からは早めに脱した方がいい と思います。 私自身、組込エンジニア時代はインプット中心であり、業務外でのアウトプット機会はあまりありませんでした。 今思うとこの頃にもアウトプットをしていたら、きっとインプットした内容をより早く深い理解の状態へ持っていくことができていたのではないかなと思います。 ソフトウェアエンジニアは常に勉強をし続け、自己研鑽することを求められますが、大事なのは質や量よりも、 継続していくこと だと思っています。 私自身気分が乗らない日もありますし、毎日勉強し続けているわけではありませんが、 継続するコツは、自身のキャリアビジョンを解像度高く持っておく ことだと思います。 ゆくゆくはこういうスキルを身に付けたい、こんなエンジニアになっていたい、などなるべく具体的なイメージを持ち、 そのイメージと現在の自分とのギャップを埋める為に必要なことは？というように思考できると、おのずと行動に繋がっていく と思いますので、ご自身の将来像を具体的にイメージしてみてください。 ちなみに私のキャリアビジョンは、抽象度が高い状態の内容では 「あいつに任せとけばなんとかしてくれる」と周囲から思ってもらえるエンジニアになりたい でして、新卒研修受講後の決意表明で上司や先輩に宣言しました。 これは今でも私のベースにありますが、もう少し具体的なキャリアビジョンとしては、自分自身のスキルや知見は引き続き身に付け続けていくが、得た物をチームメイトにもフィードバックしていき、チームメイトだけでなく将来エンジニアになりたい人のサポートができるような 縁の下の力持ち的な役割 と、 開発チームを牽引していくテックリード 的な両面の働きができるエンジニアになりたいと思っています！ 最後に 最後まで読んでいただきありがとうございます。 LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

どうも エンジニアの「市場価値」を向上する をキーワードにLIUFLLで活動している @サム です。 今回は「LINEやメールなどを通じてリテンションに繋げていくエンジニアチーム」の紹介をしようと思います。 そもそもリテンションとはなにか？ Webマーケティングにおいて「1:5の法則／5:25の法則 *1 」というのがあり、いかに既存顧客を維持しつつ離脱させないかが重要だと言えます。 1:5の法則とは、新規で顧客を獲得するには既存の顧客の5倍はコストがかかる 5:25の法則とは、顧客離れを5%改善すればその利益率は25%改善される リテンションとは既存顧客との関係を維持していくためのマーケティング活動のこと *2 で、継続的にリテンションを続けることによってコストと利益率の改善をおこないます。 リテンションとエンジニアの関係 リテンションとはマーケティングにおけるプロセスの１つで、既存顧客との安定的な関係性を継続していくための手法をリテンション・マーケティングと言います。リテンション・マーケティングを実施するには、膨大な顧客情報のセグメントとパーソナライズが必要になり、それを人がこなすには限界があります。そのため基本はMA（マーケティング・オートメーション）ツールを利用するのが一般的です。 MAツールはSalesforce Marketing CloudやAdobe Marketing Cloud、国内だとSATORIなどがあります。数ある中からMAツールを選ぶ際、コストや使いやすさ、サポートの有無などの判断軸で選ぶと思います。新規でサービスを始める際は問題はありませんが、既存から継続されているサービスにMAツールを導入するには、現状のサイト構成をふまえた上で適切なものを選択する必要があります。どんなにコストが安く使い勝手がよいMAツールでも導入するサービスとの相性が悪ければ、その効果を最大限発揮することはできず、結局売上の最大化には繋がりません。 現状のシステム構成を理解し、分析までを視野に入れてMAツールを導入・利用できる人が重要となってきます。リテンションとエンジニアの関係は、マーケティングとエンジニアリング、２つのスキルを兼ね備えた人が携わることでリテンション・マーケティングの効果を最大限発揮できると思います。 LINEやメールなどを通じてリテンションに繋げていくエンジニアチーム LIFULL HOME'Sでもリテンション・マーケティングは重要な戦略の１つとして捉えており、冒頭で記載してあるとおりリテンションに関わるエンジニアをインタビュー形式で紹介していこうと思います。 Interviewee Profiles キム 　Application Engineer 2020年1月に中途入社、前職では社内向けAPIシステムの開発やインフラ構築など幅広く担当。今はメール配信システムのフルリニューアルに従事。 吉永 　Application Engineer 2020年8月に中途入社、入社後はメール関係のCRM、MAツールの連携、リテンション施策に従事。今後はより連携を強化し、パーソナライズした配信システムの構築を行いたい。 河西 　Application Engineer 2021年4月に中途入社、入社後すぐにコロナ禍で在宅勤務に。これまでLINEを活用したアプリケーション開発やMAツールを使ったメール配信システムの開発に従事。 チームの魅力について教えてください キム ：Webと同じくエンドユーザーに近い所で、色々チャレンジができる環境だと思います。これまではシステムのリニューアルなどを担当することが多かったですが、これからはサービスの改善にチャレンジしていきたいです。 吉永 ：Goをつかったモダンな開発環境で、技術選定から入れたことだと思います。エンジニアでも企画職と同じく、ユーザ目線で企画の上流工程から携わることができ、LIFULLのエンジニア像である「テクノロジーで経営をリードする」を体現できる・発信できるところだと思います。 河西 ：発言・検討したことを実際にチャレンジできるところだと思います。またテクニカルスキルを磨く制度が会社として用意されているところなど、エンジニアの活躍・育成の場が風土として整っているところですね。 エンジニアでも表立ってチャレンジできる風土と制度、そして上流工程から関わっていくことでシステムだけでなくサービスの成長も感じることができるのが、チームの魅力ってかんじでした。 チームが抱えている課題があれば教えてください キム ：最近は新規開発が多く、プロダクト・サービスのメンテナンスが出来ているかどうかが気になりますね。今のシステムをリニューアルした際はパフォーマンス周りの議論もありましたが、最近はリファクタリングにかける時間が無いのも感じました。 吉永 ：開発した機能の効果測定は出来ていますが、１つ１つのPDCAまでは手を伸ばせていないと感じました。既存機能の改修よりも新規機能の開発、現状のリソース内でできることを選んでしまっています。 河西 ：いまは規模が大きな施策が動いているので開発期間が長くなってしまうのが大変ですね。吉永さんと同じ意見ですが、PDCAをまわすようにもっとサービスを育てていくような熱いものがあってもいいかも。 開発の割合が既存の改修よりも新規開発に寄ってしまっていることが課題ですね。逆に言えばリソースさえあれば新規開発は進めつつ、既存のリファクタリングやPDCAをまわす余裕も生まれるということですね。 転職して思ったこと 今回のインタビューした方は1〜2年に以内に入社した人が多かったので、転職した感想を教えてください。 キム ：転職は色々なものにチャレンジする機会だとおもってください。これまでは難しいことが多かったですが、現職だとやりたいことばっかりやれています。 吉永 ：前職ではバグ対応等のリカバリなど、押し付けられてしまう状況が多かったです。LIFULLは社是に「利他主義」を掲げているためか、だれか拾ってくれる、一緒に考えてくれることが多くチームとして動けています。 河西 ：上場企業ということで堅いイメージがありましたが、実際はフランクな風通しでした。挑戦できる文化、支える制度も充実していて、身構えなくてもやりたいことが見つかるといった印象をうけました。 会社としての考え方や風土、制度がエンジニアを成長させるキッカケになっていることがわかりました。 まとめ 今回は「LINEやメールなどを通じてリテンションに繋げていくエンジニアチーム」の紹介をインタビュー形式で書かせてもらいました。 本来であれば仕事の詳細も含めお伝えできればと思いましたが、表に出せる内容が少なく本来の魅力をすべて伝えきれないのが残念です。 ただ、このチームでは　 アプリケーションエンジニア【LIFULL HOME'S（ユーザーコミュニケーション領域）】 　の中途採用を募集しており、より詳しい話を聞く機会がありますのでぜひご一読頂ければと思います。 hrmos.co hrmos.co *1 : 「 1:5の法則／5:25の法則 」Mitsue-Links Co.,Ltd. *2 : 「 リテンションとは？ 」Synergy Marketing, Inc.

フロントエンドエンジニアの嶌田です。2022 年 4 月からアクセシビリティ推進グループ（以下推進グループ）に在籍しています。今回はこの新しくできた部署について簡単に紹介します。また、会社や私がアクセシビリティに取り組む理由を語ってみようと思います。 弊社プロダクトのアクセシビリティを推進する取り組みは、これまでも有志が集まるワーキンググループの形で存在していました。ワーキンググループについては以前に Ltech という社外イベントで紹介しました。今年度からの新設部署はワーキンググループの流れを汲んでおり、推進活動に本腰を入れてコミットしていくために新設された部署です。 参考： Ltech#14 「LIFULL HOME'S」のフロントエンドについて語り尽くします！ 開催レポート - LIFULL Creators Blog 推進グループは上長１名に、ほぼフルタイムでアクセシビリティにコミットするメンバー２名で構成されています。 アクセシビリティ推進グループの取り組み 推進グループのミッションは大きく２つに分かれます。プロダクト改善活動と、啓蒙・教育活動です。 プロダクト改善活動は、いまある LIFULL のプロダクトに手を入れてアクセシビリティ品質を改善していく活動です。現在の LIFULL のプロダクトには、キーボードやスクリーンリーダーで利用しづらい箇所が数多くあります。アクセシビリティを念頭に設計・実装されていなかったためです。そのため、このような問題を検出し、修正していく活動をしています。また、事業部やプロジェクトチームから持ち込まれる相談に乗ったり、デザインや実装のレビューを実施したりしています。 もう一方の啓蒙・教育活動は、プロダクト開発においてアクセシビリティが担保されるしくみを作っていく取り組みです。アクセシビリティの必要性や実践方法をレクチャーしたり、ガイドラインを策定し開発プロセスに組み込むといったことをしています。 このプロダクト改善活動と啓蒙・教育活動はどちらも重要と考えています。プロダクト改善活動に偏っては、新しくアクセシブルでないプロダクトが生み出されていく流れをとめられません。反対に啓蒙活動に偏っては、既存のプロダクトがはらむ問題点を解消しないまま先送りし続けることになってしまいます。 LIFULL とアクセシビリティ 専門部署を作る程度にはアクセシビリティに本気の姿勢をみせている弊社ですが、そもそも LIFULL はなぜアクセシビリティに取り組むのでしょうか？ LIFULL は「あらゆるLIFEを、FULLに。」というメッセージを対外的に発信しています。世界中のあらゆる人々の人生を、安心と喜びで満たそうというメッセージです。「あらゆる」という言葉に込められているのは文字通り、能力や属性によって分け隔てすることのない、すべての人というニュアンスです。くわえて ACTION FOR ALL や LIFULL STORIES など、住宅弱者を支援するサービスや、多様な価値観や暮らしを応援するメディアを運営してします。 このようなサービスを展開する会社として、アクセシビリティに取り組まない理由はありません。 私とアクセシビリティ ここからは私のごく個人的な話になります。筆者は現在、企業でアクセシビリティを牽引していく役割を務めていますが、キャリアはこれまで一貫してウェブのフロントエンドを担当するエンジニアでした。私はいったいどういう経緯でアクセシビリティに興味をもち、何が楽しくて今の業務に携わっているのでしょうか？ アクセシブルな UI との出会い 私のアクセシビリティへの興味は、元をたどってみるとネイティブ UI に対する劣等感が根底にあったように思います。OS やブラウザーが備えている UI がキーボードによる操作性や一貫性・堅牢性を備えていることは肌で感じていました。くわえて、キーボードショートカットを駆使することで、マウスの時よりずっと効率的な作業もできる。一方で、自分が実装するウェブの UI は、見た目だけそれらしく見せたハリボテを作っているような違和感を持っていました。中身が伴っていなくて、ネイティブ UI に対して劣ったものを作っている…と感じていたのです。 ところがウェブにも、堅牢でキーボード操作に対応した UI が存在していることに気付きました。Adobe AIR や Dojo Toolkit、jQuery UI といったプロダクトへのあこがれを通じて、WAI-ARIA というものの存在を知りました。ウェブアプリケーションをアクセシブルにするための仕様です。WAI-ARIA に準拠した実装をすれば、ウェブでもキーボード操作に対応した UI を実装できるのだと知りました。「私が作りたいものの指針はここにあったんだ」と思いました。 いつもよいものを作りたい デザインと実装が別々の価値基準で作られる制作体制にあまり満足していませんでした。「デザインを実装で再現する」とか、逆に「実装都合をデザイナーに飲んでもらう」ような作り方にモヤモヤしていたのです。一見、お互いの価値観をすり合わせをしていて素敵な制作チームだとも思えます。しかし相手が主張してくる内容によっては必ずしも同意できることばかりではなかったりして、最終的に納得のいかないまま渋々ながら一方が折れる…といったことにもなりかねません。 キーボード操作を実装したいという私の思いも、プロジェクトの目的と照らしたら「エンジニアの自己満足」と一蹴されてしまっていたかもしれません。 デザインと実装とは、そういう緊張関係の間に成り立つものではなかったはずです。何かお互いが「これはよい」と思えるものを共有しながらものづくりができればよいのに…と思っていました。 アクセシビリティに向き合い始めてから、アクセシビリティが自分の求めていたものじゃないかと思えるようになりました。アクセシビリティこそが、ウェブサイトを作るためにデザイナーと実装者とで共有できる品質の指針や価値基準になりうるのではないか…と。 アクセシビリティを中心に据えると、私があこがれていたキーボード操作できる UI も大手を振って実装できるようになるし、私の劣等感もぬぐい去られるような気がしました。 ウェブへの恩返し 小学校のころに初めてホームページを作って以来、ゲームのコミュニティサイトの運営などを通じていろいろな人と出会い、貴重な経験もしてきました。「ウェブにおける自分」の人格は自分の中でも今も大きな比重を占めています。多感な時期に私の創作意欲の受け皿になってくれたことも、今ウェブの仕事をして食べていけていることも、感謝してもしきれないくらいの恩がウェブにはあるのです。 自分にはこれしかできないから…というのはまあそうですが、私はウェブに恩返しをしていきたい。では、どういう形で恩返しができるか？ と考えた結果、自分が関われる範囲において、ウェブがウェブらしくあるように貢献していきたいと考えるようになりました。 「ウェブらしさ」とはなんでしょうか？ 十人十色答えは違いそうですが、アクセシビリティこそがウェブらしさなのだと私は考えます。ウェブサイトを作るとき、アクセシブルにしてくれというウェブの声が聞こえてくる気がするのです。 そんなこんながあり、私にアクセシビリティを推進していく気概ができあがってきたようです。 LIFULL はアクセシビリティ「やっていき」 ２年前に入社した時から細々と社内でアクセシビリティを推し進めてきました。ワーキンググループでいくつか実績を積み上げて、100 人以上のエンジニア組織の中に運よく専門部署が立ち上がるまでになりました。 この実績は明らかに私だけのものではありません。私が入社する前にもアクセシビリティを重要視してデザイン・実装をしていたメンバーがいます。旗振り役としての経験の乏しい私の背中を押してくれたメンバーや上長がいます。ほかの会社で同じく推進役をしている先輩諸氏、そのアドバイスや実績、アウトプットにも大いに助けられています。そもそも、LIFULL という会社が社是として「利他主義」を掲げている会社であることも推進しやすさに大きく影響しているのだと思います。 しかも、私たちの活動はまだまだこれからというところです。コミュニティから受け取ったものをしっかりと成果にかえつつ、私もまたコミュニティに還元できるように努めてゆこうとあらためて感じています。 LIFULL はプロダクトのアクセシビリティを重要と考えています。継続的にプロダクトや制作プロセスを改善してまいります。今後も LIFULL のアクセシビリティにご期待ください。 🙂 LIFULL は一緒に働けるクリエイターを募集しています。アクセシビリティへの取り組みが良いね👍と思ったら、求人をぜひご確認ください。 hrmos.co hrmos.co hrmos.co hrmos.co

はじめに エンジニア二年目、寺井です。 先日行われた AWS JumpStart というAWS初学者向けイベントに参加した際のレポート記事になります。 ■ イベント概要 AWS JumpStart はAWS初学者のエンジニアの方々を対象とした、実践的な研修プログラムです 将来的にAWS活用をリードする人材になるための第一歩をスムーズに踏み出せるようなプログラムをご提供します 単なるAWSサービスの学習だけでなく、要件に合わせて適切なアーキテクチャを検討・設計する経験を積む部分にフォーカスした内容となっております 例えば、以下のような方々にもオススメです！ ・AWSの名前は知ってるが使ったことは無い ・EC2等の単体サービスは触ったことあるが、全体のアーキテクティングは経験がない ・クラウドネイティブなアプリケーションを設計する上で重要な観点を知りたい 例によって初心者エンジニア向けな記事となっておりますよろしくお願いします。 この記事が参考になりそうなレベル感 AWS未経験 ~ AWSﾁｮｯﾄﾜｶﾙ なエンジニアのみなさん 後述しますが、AWSを全く触ったことがなかったり、エンジニア関連の技術を何も触ったことがないという方にはかなりキツめなイベントでした。内容についてもレポートをしていきますので、参加してみたいけど今の自分のレベルでは不安...という方もぜひ読んでレベル感を察していただけたらと思います。 全体のスケジュール 完全オンラインでのスケジュールです。画像だと文字が潰れてしまっているかもしれませんが、朝9時から夕方6時までぎっしりと詰まった内容ということが伝わると幸いです。 朝9時集合はキツかったです。 1日目前半 ~グループワークではじめまして~ まずは全体説明とウォーミングアップを兼ねたチャットでの自己紹介がありました。内容を見ていると職種はけっこう様々なエンジニア職が集まっていて、年齢層は幅広め、ただAWSサービスを利用した経験があまりないと言った人が多かったです。社会人向けのイベントでしたが、インターンをしている学生さんもいました。参加者は全体で80名程度、サポートをしてくれるAWSの方が3名でした。 その後は簡単なAWSサービスの紹介LTがありましたが、事前学習用動画として一時間程度の入門動画を観るよう指示があったので、その内容の復習になります。 そして二日間の日程を通じて行われるアーキテクチャ設計のお題を出されました。お題はこちら、 グループワークお題 こんな要件を満たすサービスのアーキテクチャ設計をしてくれというお題ですね。納期は翌日です。ちなみにこのお題を出される際にちょっとしたシナリオも一緒に用意されていたのですが、要約すると「ブラック企業に就職してしまった新人エンジニアの俺たちが、入社二日で会社の命運を握るサービスのアーキテクチャ設計を任された件」って感じです。気になった方はぜひ参加してみてください。 その後、各チームに分かれてグループワークが始まりました。 私と一緒のチームになったのは全員同じくらいのエンジニアレベルで、バックボーンは様々だったのですが全員がエンジニア歴1〜2年のグループでした（他のチームもいくつか見ましたがレベル感としてはほとんどの人が同じくらいだと思います。たまに初心者か...？って感じの強そうな人がいたような気もしますが）。 お互いはじめましてでしたが、全員が同じくらいの初学者ということもあり特に緊張することもなくグループワークに入っていくことができました。 さて、今回のように初心者エンジニアが集まると「誰も正解がわからない」、「何をどうしたらいいのかが全くわからない」という状況になりがちです。 そんな時でも安心なのが、グループワーク全体日程を通じて三回、オフィスアワーというAWSの人に直接相談できる機会が設けられていたことです。 初回の相談時はどうしたらいいのかが全くわからず、設計図もそれっぽいものを並べただけという悲惨な状況でしたが、「この要件を満たすためには例えばこういった機能が必要そうで、これを調べてみるといいかも」といったアドバイスをいただくことができ、無事に軌道に乗るところまで持っていくことができました。 少しでも知見のある分野ではそれぞれが積極的に意見を出すといったチームワークも発揮しつつ、それっぽい設計図ができてきたところで初日のグループワークの時間が終了。作業時間は三時間ほどあったはずですが、一瞬で過ぎ去っていった印象です。 普段の業務もこれくらいの速さで時間過ぎればいいのに。 1日目後半 ~スケーラブルなWebアプリを作るハンズオン~ 1日目後半はグループワークを中断して、実際にAWSサービスを使ったハンズオンを行いました。 内容としては、「複数のアベイラビリティーゾーンを作成、それぞれのパブリックサブネットにECSとFargateタスクを設定してELBを接続、最後にそれぞれのプライベートサブネットにRDSをリーダーとプルレプリカ1台ずつ起動」というものです。図にすると以下のような設計になります。 ハンズオン完成図 ここまで書いてある意味がよくわからないといった方には中々やりごたえのある内容だったのではないでしょうか。とはいえ丁寧な解説手順書があり、わからない人向けに個別フォローまでやってくれるので迷子になってしまうといったこともなく安心です。 一方で、ここまで書いてある意味がそれなりにわかる方には正直あまり効果の無い内容だと感じました。リソースの作成や設定まで全て手順書に細かく書いてあるので自分で特に設計等を考える必要もなく、あーこの設定ね、とポチポチするだけで完成してしまいます。また、基本的にそれ以上突っ込んだ内容は取り扱わず、AWSの方々も途中の設定で詰まってしまった方のフォローにずっと回っていたので、早く終わってしまった人は各々好きなことをしていてください状態でした。その間に設計の課題を考えることができたのでありがたかったのですが、私にとってはこのハンズオンではあまり得られるものがなかったかなと感じます（理屈はわかっていても実際に自分の手で一から作成した経験は無かったので学びになったといえばそうかもしれませんが）。 という内容を最後のアンケートで書いたのでもしかしたらこの後の回では内容が変わっているかもしれません。 2日目 ~グループワーク追い込み編~ たった二日間の日程ですが、納期が目前に迫っている（という設定）ので朝からグループワークの続きです。 着々と要件を満たした設計を実装しつつ、オフィスアワーの質問も活用して一通り設計が完成してきました。 初日はボロボロだった設計もこの段階になるとさらなるブラッシュアップのために機能を追加するといったフェーズになってきます。 そんなこんなで出来上がった最終的な成果物はこちら。 アーキテクチャ設計完成図 オ ー ル サ ー バ レ ス にしました。やはりサーバレス...サーバレスは全てを解決する...！ちなみに発表会では全部サーバレスだと...！？みたいな感じでちょっとざわついていました。 ※この設計図で全要件が担保されているのかと、そもそもこの構成で動くWebサービスができるのかは未検証です。もし何か不備に気付いてしまったベテランのみなさまは寛大な心でスルーしてください。 この構成に仕上げるまでの流れとしては、 チャット機能でリアルタイム性を実現するためにWebSocketをAPI Gatewayで実装 API Gatewayの後ろにつける実行部分としてはメンバーが使用経験があって、かつスケーリングできてAZ等の設定も考える必要のないLambdaで実装 それに合わせてDynamoDBにデータ保存 + OpenSearchを使った検索機能 その他仕様に合わせて調整 といった段階を踏みました。 発表会では質疑応答の時間があり、その後講評をいただきました。それぞれの主な内容としては、 質問： サーバレスに振り切ったモチベーションとしてはどういったものがあったのか。 -> 上述の構成に仕上げるまでの流れの内容をそのまま回答。 想定されるアクセス流量はこの設計で耐えられるのか。 -> 我々の見立てではLambdaのスケーリング機能でなんとかなる想定。同時実行数に関しても上限緩和申請をして対応すればなんとかなりそうという見込み。 講評： 今回のようなサーバレスの多い設計だと短期間での実装には非常に適しているが、Managedなサービス部分が増えるほど自由にカスタマイズできる部分が少なくなっていくのでそういった部分まで考えられると良いかも。 Lambdaの実装部分に関してはもう少し考慮の余地があって、例えばアクセスに耐えられるかの部分は平均だけではなくピーク時の流量を想定して耐えられる設計なのか、関数の実行時間がどれくらいかかりそうなのかまで考えられるとより適した設計が見えてくるかもしれない。 討論を重ねてグループ内ではそれなりに納得のいく形に仕上げたつもりでしたが、深い部分まで考えを巡らせることが十分にできなかったなと感じました。 また、仕様書を表面的になぞっただけの設計にとどまらず、実際に運用した際に生じてくる問題部分まで考えを及ばせる必要があることに改めて気づかされました。 企業がプロダクトとして出すものとしてはかなりお粗末なものになってしまったと痛感しましたが、実際の業務でやらかしてしまう前に経験を積むことができたのは大きな収穫だったと思います。 おまけ ~別チームの設計~ 発表会では4チームごとに分かれて発表を行ったのですが、チームによって設計方法から粒度までかなり異なっていたのが面白かったです。例を挙げるとキリがないので少しだけ紹介すると、 チャット部分のリアルタイム性はAWS AppSyncで実装 処理部分をECS+ASGの設定で実装（ハンズオンでやった内容を応用） セキュリティ部分に注力して認証やIAM設定をガチガチに設定していたチーム 実運用まで想定したリソース選択まで踏み込めていたチーム などが見られました。 所感 二日間フルタイムの日程だったのですが、終わってみるとあっという間のプログラムでした。グループワークの時間だけでも合計で7〜8時間程度はあったのですが全然話し足りないという感想でした。 また、グループ全員がほとんど同じレベルだったのがかなり良かったと感じます。誰かに任せてやってもらえばいいやではなく、自分が全力で参加しないと完成しないという気持ちになりましたし、他のメンバーも同じような思いで参加していたのではないでしょうか。結果としては全員が何かしらの部分で活躍できる機会があったように思います。 また、発表会を通じて自分たちの設計したアーキテクチャへのFBをいただけたことと、別グループの設計の発表も聞くことができたこと、最後にはAWSの方から実装例の共有もあったりと、短い時間で非常に多くの学びがありました。 おわりに ある程度AWSを触ったことがあるといった人が実務に近い設計の経験を積むといった文脈では非常に有意義なイベントだと感じました。今後の業務で学んだことを活かしていきたいですね。 一方で、全くAWS触ったことないという人にとってはグループワークの話し合いに着いていくのがかなり大変だったと思いますし、吸収できる学び量もけっこう変わりそうな気がします。とはいえ、最低限の講義パートやハンズオンもあったので、少しでもサービスを触ったことがあるなら十分食らいついていけるのではないでしょうか。 今年度は全部で4回同一内容のイベントが開催されるので、本記事を最後まで読んでいただいたみなさんも参加してみてはいかがでしょうか。 最後になりますが、LIFULLでは一緒に働いていただける仲間を募集しています。今回希望してイベント参加をしたように、エンジニアが成長できる機会が盛り沢山の職場です。カジュアル面談もやっていますので、よろしければこちらもご覧ください。 hrmos.co hrmos.co

こんにちは、 LIFULLプロダクトエンジニアリング部の趙(ﾁｮｳ)です。 苗字からわかると思うんですが、国籍は中国です。 中国で大学卒業して一人で日本に来てから3年間になりました。 せっかくの機会なので、外国人が日本に来たこの三年間の生活とお仕事について話したいと思います！ 日本とLIFULLに来るきっかけ 私の大学は中国の大連理工大学で、大連には日本の企業は多いので、日本語専門及び日本語強化の専門が提供する大学が多いです。自分の専門も「ソフトウェア(日本語強化)」です。 日本語強化というのは、専門のソフトウェア以外の英語をやめて、代わりに日本語の授業を受けることです。専門のおかげで卒業してからある程度の日本語を話せます。 そもそも日本語できるから海外に生活するわけではないですが、ある機会でネオキャリアが中国に来て面接会を開催しました。十数社の会社が参加しまして、LIFULLはその一員です。 私は友人から誘われたので、就職会の参加を決め、各会社を回っていって、LIFULLのホームページのデザインが一番良くて(私はフロントエンドに興味ある)、利他主義の経営理念も気に入って、LIFULLの面接を申請しました。日本語で面接受けるのは初めてなので、すごく緊張しました！ そして面接で話もはずみ、LIFULLに入社することができました！ LIFULLのお仕事 入社 入社したばかりの時は使う環境と言語は大学時代に学んだこととは大きく差があり、環境構築や最初のタスクをこなすだけでも大変でした。ありがたくてメンターさんが優しく教えてくれてすぐ慣れてきました。 一年目で物件情報管理のシステムと追客システムを担当させていただき、すごく勉強になった一年でした。 色々触れること 二年目からは組織変更でLIFULL HOME'Sの開発を担当させていただきました！ やったことは主に不動産検索サービスの設計と開発です！ 他には接客力ランキングページの作成とか↓ LIFULLタグの開発にも参加させていただきました！ そして三年目からまた新しい組織に配属されていてB向け領域に行きました！ メインの担当はWEBの設計、開発とメンテナンスです。 その他に、グループで担当しているシステムがKEEL環境で稼働しているので、KEEL環境に関しての調整、メンテ、新しい環境作り、デプロイとかの業務もやらせていただきました！ www.lifull.blog KEELに関しての業務によってKEELチームと基盤チームのメンバーと相談する機会が一気に増えてきました、他部署のみんなの魅力も感じました。 コロナ時代 入社2年目からコロナが流行して、2020年3月の頭から在宅勤務になっていて、業務の進み方は大きく変わりました。 まず在宅になったことで通勤時間がなくなりました。そして家に仕事するなら部屋の明るさと温度調節自由でもっと安心と集中できる環境を作れるようになりました。 最初リモートワークでコミュニケーション不足になると思いましたが、Zoom、oViceとかのサービスを使ってオンライン飲み会とキックオフをやるのも意外と盛り上がれる！MTGとかも会議室予約しなくてもやれるし、コミュニケーションにも特に影響を感じませんでした。 一人で海外に暮らす体験 言語 日本に来る外国人は、日本語学校を申請して日本に来てから日本語を学ぶのが多いですが、私はちょっと違って中国で日本語を学んでから直接に就職するので、まだ慣れてない状態で職場に行く最初は大変でしたQAQ。毎回他メンバーと話す時はすごく集中して、話す前は必ずノートで話したいのを書いて準備してきました。MTG中みんなの話を追いつかない場合もありました。でも部署の皆さんは私と話すときは意識的にゆっくり話してくれたり簡単な単語を使ったりをしてくれてるのはすごくありがたいでした。 みんなのおかげで日本語の職場をだんだん慣れてきました。 住所 日本に来たときはしばらく日本に働いてる友達の家に住んで、仕事しながら部屋探しをしました。小さい１Kでしたが、私の日本の初めての住むところでした、退社して帰宅後毎回愈されます！ 二年間住ませて、その後コロナになっていて、快適な環境で仕事をしたほうが良いと思い家を購入しました。 ちなみに家探しはもちろんLIFULL HOME'Sで！ 興味 日本のアニメと漫画は世界中にも有名で、私も子供時代からジブリとか、ナルトとコナンを見ながら育てられてます。日本に来てからももちろん、漫画、アニメとゲームを楽しんでます！ 最近PS5を購入もできました！ まとめ 素晴らしい三年間でした。 自分がやりたいならすぐやる人間なので（迷えば、敗れる！）日本に来ても、LIFULLに来ても、家を買うとかでも、数日間だけで決まったんです。それが良いのか悪いのか人によってですが、自分がこういう未知×チャレンジだらけの生活が好きです！ 一人で海外で暮らすのは確か勇気が必要ですが、一歩踏み出したら、きっと今まで見たことない風景が見えます！ 新しい世界に踏み出す自分とそのチャンスをくれるLIFULLに感謝します。 hrmos.co hrmos.co

こんにちは、プロダクトエンジニアリング部の鈴木です。 私達のチームでは、 リファクタDays の取り組みとして、APIサーバのテストコード（RSpec）のリファクタリングを行いました。 このリファクタリングにより、テストコードの記述量が大幅に削減され、数年間利用してきたAPIコントローラのテストコードを作業時間にして2週間程度で移行できました。 この記事では、どのようにしてチームでRSpecを改善したのか全体像をお伝えします。 APIサーバが抱えるテスト実装の課題 主な改善内容 ディレクトリ構成を整備・統一する テストの雛形を自動生成する モック・スタブ化をVCRで自動化する テストコードの期待値も自動で作る テストコードから実装の振る舞い以外を追い出す チームでの改善の進め方 まとめ APIサーバが抱えるテスト実装の課題 私達のチームが管理しているサービスでは、バックエンド（APIサーバ）が、RubyのSinatraフレームワークによるBackends For Frontend（BFF）構成となっています。 コントローラのテストは、RSpecで記述しており、APIサーバへの問い合わせ結果を検証しています。 APIサーバでは外部APIへの問い合わせが多く行われており、テストコードでは外部APIには問い合わせないよう、ダミーデータを返すためのモック・スタブ化が多く行われています。 そのため、図のようにサービスの機能追加・改修の度に、モック・スタブ化を行っていました。 これにより、テストコードの実装工数・コード量・管理の負担が増加し、サービス実装の足枷となりつつありました。 また、テストコード全体の構成にも明確なルールはなく、伝統的に書かれている構成を参考に実装している状態には、チームとして課題感を抱えていました。 負債解消前のテスト基盤 主な改善内容 まず、初めに刷新後のAPIコントローラのテスト作成方法を図示します。 刷新後のテストコードの作成は、ツールからテストコードの雛形を生成し、リクエストパラメータやテストコードを追記して作成します。 また、モック・スタブ化や期待値の作成は初回時に自動的に行われるため、実装者は生成された内容が正しいか確認するだけで良いようになっています。 負債解消後のテスト基盤 この仕組みに変更するためどのような対応をしたのか、各章で詳しく解説いたします。 ディレクトリ構成を整備・統一する テスト関連のディレクトリ構成は、実装コードと同じディレクトリ構成になるように変更することで、実装との対応関係を明確にしました。 先に、大まかな実装（src/配下）とテスト関連（spec/配下）のディレクトリ構成のイメージを記します。 ここでは、例として src/app/resource/mansion.rb という、APIのコントローラを対象としたテストのディレクトリ構成を記載しました。 . ├── spec #テスト関連 │ ├── app #テストコード │ │ └── resource │ │ └── mansion │ │ ├── helper.rb #テスト準備コード │ │ └── mansion_spec.rb #テストコード │ ├── fixture #期待値ディレクトリ │ │ └── app │ │ └── resource │ │ └── mansion │ │ └── result.json #mansion_spec.rbで利用する期待値 │ ├── helper #共通テスト準備コード │ ├── tools #テスト作成自動化用のツール群 │ └── vcr_cassettes #モック/スタブ情報（VCRカセット） └── src #実装 └── app └── resource └── mansion.rb spec/app配下にあるテストコードと、fixture/配下のテストコードの期待値ファイルは、実装側のsrc/以降のファイル名までをディレクトリ構造として配置するようにしています。 単純な話のようですが、今まではルールが明確でないなど、独自の共通化により異なるディレクトリ構造が生まれているなど全体像が把握しにくい状態でした。 全体のディレクトリ構成を整備・統一を初めに行うことで、新規実装者でも全体像を把握しやすく、後述の自動化も行いやすくなります。 テストの雛形を自動生成する テストコードを書くために共通で必要なファイルやコードは、自動生成することで実装者が楽をできるように仕組み化しています。 テストコード雛形作成のツールでは、テスト対象のAPIのエンドポイント（/mansion get）を指定して実行すると、適切なディレクトリにspecの雛形ファイルが配置されるようになっています。 雛形作成コマンドの実行例 ruby spec/tools/make_templates.rb /mansion get コマンドによって作成されたテストコードの雛形イメージ #./spec/app/resource/mansion/mansion_spec.rb # frozen_string_literal: true require_relative 'helper' describe Resource::Mansion do let(:params) { {} } # 必要に応じてリクエストパラメータの定義 # リクエストパラメータのバリデーションテストコード describe '#valid?' do it_behaves_like 'valid?', %i[] end # getリクエストのテストコード describe '#get', :vcr do let(:endpoint) { '/mansion' } let(:result_file) { 'mansion.json' } include_context 'expected_result' end end その他も、テストコードの作成に注力できるよう、ファイルの読み込みなどを極力自動化しています。 モック・スタブ化をVCRで自動化する 外部APIのモック・スタブ化には、 VCR を利用することで、モック・スタブ化を自動化しました。 今まで、外部APIに問い合わせる箇所は、テスト実行時には問い合わせないようモックを作成し、ダミーデータを返すスタブを記述していました。 モック・スタブ化にはRSpec標準の RSpec Mocks を用いてきました。 しかし、この方法は下記のような問題が発生しており、実装の負担になっていました。 外部APIのリクエストパターン分だけ、モック・スタブ化用のコード（ allow().to receive().and_return() ）を記述する必要がある モックを共通化するために、テストコードに shared_context()/include_context() が頻出する 外部APIへの問い合わせ結果の代わりとなる、スタブデータを作成する必要がある スタブデータが実際の問い合わせ結果と異なり、テストの問い合わせ結果と実際のAPIの結果が乖離する これらの問題の解決策として、VCRを用いました。 VCRは、Net::HTTPやFaradayといった様々なHTTPライブラリを、外部APIへの問い合わせが発生したタイミングで自動的に WebMock 等にモックします。 更に、問い合わせ結果をファイル（vcr_cassettes/配下）に初回のみ自動的に書き出ます。これをVCRではカセットと呼び、スタブデータとして自動的に利用します。 1度VCRの設定をしてしまえば、テストコードへの記述は、外部APIに問い合わせるコードが含まれるテストコードの context/it ブロックに :vcr を記述するだけで機能します。 describe '#get', :vcr do # このブロック中の外部API問い合わせを自動でモック・スタブ化 end この仕組みにより、下記のメリットが得られました。 モックコード・スタブデータを記述する必要がなくなる モック・スタブの記述がテストケースから無くなり、テストコードが読みやすくなる モック記述漏れにより、外部APIに問い合わせてしまうことがなくなる スタブデータが、実際の問い合わせ結果と同じなため、決定論理的なテストを行える 一方、ファイルを自動生成する都合で、describe/context/itにマルチバイト（日本語）を使いにくくなることが課題としてあがりました。 デフォルト設定のVCRは、 describe/context/it の命名で、スタブデータのディレクトリとファイルを作成します。 それにより、命名に日本語が入っているとディレクトリ・ファイル名の日本語がエンコードされ、CLIやGit操作うまくできなくなりました。 解決方法は、下記が考えられます。 CLIやGitを、マルチバイトでも問題ないように設定する VCRの設定でスタブデータのディレクトリを明示的に指定する describe/context/it を半角英数で記述しする 私達は、汎用性のため describe/context/it を半角英数で記述しすることを選択しました。 それ以外の殆どの課題は、VCR側の設定をカスタマイズすることで吸収できました。VRCは汎用性の高いライブラリだと思います。 テストコードの期待値も自動で作る テストコードの期待値も、初回テスト実行時にAPIのリクエスト結果から自動的に作成されるようにしています。 テストコードの期待値は include_context 'expected_result' の内部で下記のように、初回テスト実行時のみ作成と検証をしています。 fixtureディレクトリ配下に、テストコード用の期待値が存在するか確認する 存在しない場合、テストでのAPI問い合わせ結果を、期待値としてfixtureディレクトリ配下に書き込む 存在する場合、期待値ファイルを読み込み、作成は行わない テストを実行し、期待値とテスト実行結果を検証する 気をつける点として、初回テスト実行時はテスト結果と期待値が同じになるため、APIへの問い合わせ結果はどうであれテストを通過してしまう点です。 これについては、異常な期待値が生成されないよう、APIへの問い合わせ結果に問題があるときは警告を表示するよう対策をしています。 また、期待値が正しい値になっていることは、実装時とレビュー時に確認するようフロー化しました。 テストコードから実装の振る舞い以外を追い出す 最後にテストコードの見通しを良くするために行った対応として、テストコードにはテストコードのパターンごとに、実装の振る舞いに影響する受け取る値（引数）と返す値（期待値）のみを定義するようにしました。 これにより、テストコードから誰が見ても実装の挙動がわかりやすくなるようにしています。 具体的には、実装の振る舞いには関係の無い、テストを実行するのに必要なコード（準備コード）をhelperファイルに切り出しました。 helperファイルに移されるコードの例としては before や after ブロックで行うような、日時の固定や外部API以外（AWSリソース等）モック・スタブ化などの処理です。 準備コードを切り出すためのhelperファイルは2種類の配置方法を用意しました。 各テストコードでしか必要のないhelperのコード：各specファイルと同列のhelper.rbに配置。 日時の固定など、複数のテストコードでも利用するような共通のhelperコード：spec/helper/配下から共通で呼び出されるように配置。 日時固定の共通helper # ./spec/helper/contexts/time.rb # VCRカセットの生成時間で日時を固定する共通準備コード shared_context 'freeze_time' do before do travel_to(VCR.current_cassette&.originally_recorded_at || Time.now) end end 共通helper呼び出し用 # ./spec/helper/spec_helper.rb require './spec/helper/contexts/time' # 共通で読み込む準備コードを定義 def basic include_context 'freeze_time' end 個別helper（S3のモック・スタブ化） # mansion/helper.rb require './spec/helper/spec_helper' # mansion/mansion_spec.rbの実行に必要な、S3バケットのモック・スタブ化 shared_context 'stub_aws_s3' do let(:s3_resources_params) { { region: 'ap-northeast-1' } } let(:s3_resources) { instance_double('s3_resources') } let(:s3_client) { instance_double('s3_client') } before do allow(Aws::S3::Resource).to receive(:new).with(s3_resources_params).and_return(s3_resources) allow(s3_resources).to receive(:client).and_return(s3_client) end end テストケースのコード # mansion/mansion_spec.rb require_relative 'helper' describe Resource::Mansion do basic # 共通準備コードの読み込み describe '#get', :vcr do include_context 'stub_aws_s3' # 個別で必要な準備コードの読み込み let(:params) { { mansion_id: 123 } } let(:endpoint) { '/mansion' } let(:result_file) { 'result.json' } include_context 'expected_result' end end これにより、テストコードからは実装の振る舞いがわかりやすくなり、コードの見通しを良くしています。 これらの対応の結果として、大幅に自動化とテストコードの棲み分けがされたため、実装者が考慮しなければならない点が下記に集約されました。 テストコードごとのリクエストパラメータの記述 外部API以外のモック・スタブ化 期待値が想定される値になっているかの確認 テストコードも、8万行程度あったものが約4千行にまとめられ、20分の1となり大幅に改善できました。 チームでの改善の進め方 改善に向けては、 リファクタDays の時間の時間を使ってチームで進めてきました。 リファクタDaysとは、部署全体で進めている、技術的負債の解消とそれによる価値創造の加速を目的とした取り組みです。 我々のチームでは、月に1日業務とは別にリファクタDays時間を確保し、チームで管理しているサービスの技術的負債の解消をしております。 今回のRSpecリファクタリングは、下記のような流れで進めました。 サービスの課題をブレインストーミング形式で洗い出す テストコードの課題点をブレインストーミング形式で洗い出す テストコードの改善方針を定める チーム全員でリファクタリングを行いながら、改善の障壁を洗い出す チームで障壁について解決案を議論・解消 4から5を繰り返す テストコードの課題洗い出しブレストシート 初めから、RSpecの改修を目的にしていたわけではなく、チームでサービス全体からボトルネックを洗い出すところから始めました。 RSpecの改善が決まってからは負債解消をするにはどうするのがよいか、リファクタリングを実施しながら改善の検証を繰り返しました。 その結果として、チーム全員が納得できる改善結果にできました。 まとめ テストコードは、実装の保守・運用に必要なものですが、テストコードの記述に時間がかかると、実装工数増加に繋がり価値創造の妨げになりかねません。 今回は、テストコード作成の自動化と適切なファイルの棲み分けを行うことで、 次の価値創造の高速化に繋げました。 LIFULLでは、なかなか手を付け辛い技術的負債の解消も、チームのKPIとして掲げることで、精力的に取り組んでおります。 気になった方は求人情報も御覧ください。 hrmos.co hrmos.co