こんにちは。エンジニアの加藤です。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

はじめに こんにちは！LIFULLのプロダクトエンジニアリング部でフロントエンドエンジニアを担当している竹本です。 今回はチームで初導入した「デザインスプリント」について どのような手法で導入したか 導入して感じた利点と現状の課題 を共有します。 デザインスプリントとは デザインスプリントはサービスの開発を効率よく進めるために各ステップごとにチームメンバーで議論してプロトタイプを作り、高速で価値を検証するプログラムです。 各ステップでは、リサーチ、プロトタイピング、ユーザーテストに則ったプログラムで構成しています。 これを何度も繰り返し研磨することでサービスの理想形を探究し続けるといった点が今回の目標になります。 チームでどのように実施したか まず今回の基本構成としましては、以下のようなプログラムに分けて実施しました。 DAY1 理解...競合調査やデータ分析による課題定義 DAY2 発散...課題を元に解決するHMW(How Might We)を作成する DAY3 決定...書き出したアイデアからプロトタイプを作成するアイデアを選出する DAY4 プロトタイプ...アイデアをベースにプロトタイプを作成する DAY5 検証...プロトタイプをユーザーがどのように使うのかを観察して仮説検証を行う 上記のプログラムを１つずつ簡単に説明していきたいと思います。 DAY1 理解のプログラム このプログラムでは、ユーザーのプロセスを徹底的かつ具体的に追いかけます。 今回はユーザー調査とKA法を用いて人々が求めている本質的ニーズや体験価値を導き出すこととしました。 ユーザー調査 ターゲットにとっての本質的な価値とは何かを探るためにユーザー調査を行います。 今回は、「住まい選びを始める段階の人が、どのように情報に触れて、どのように住まい選びを始めているのか」という題材の元、 デプスインタビューを実施しました。 大まかに分けてユーザー調査前に整理したリサーチ要件は以下になります。 背景 調査が必要な経緯、現在のステータスなど 目的 調査で知りたいこと ゴール どのような結果・状態が達成されていればインタビューは成功か 明確にすること どのようなことを知ることができたら、ゴールを達成できるか こうしたリサーチ要件を元にユーザー調査を行い、得られた結果を元に、KA法を用いて分析していきます。 KA法 KA法を用いたステップとしては以下になります。 「出来事」を読んでなるべく具体的にそのシーンをイメージとして思い浮かべる そのシーンに自分を置いてみて、行動したときの自分の心の動きを感じとる 自分の心の動きを投影して、ユーザーの価値観だったらどうなるか類推する 類推した心の動きから、「出来事」に含まれる価値を捉えて「心の声」として表現する 「出来事」と「心の声」を踏まえて、「〜する価値」というフォーマットにする KA法を用いてできる「出来事」「心の声」「〜する価値」の例 DAY1では様々な価値を発散し、グループ化した上でその価値を提供する既存製品・技術を書き込むまでを行いました。 ここで完成したものは「価値」を整理した価値マップと既存製品、技術マップになります。 DAY2 発散のプログラム このプログラムでは、以下の順序でHMW(How Might We)を作成し、その中から重要なHMWを抽出することがゴールとなります。 DAY1で完成した「価値マップ」を利用し、HMWをチーム内でできる限り作成する HMWの付箋をグループ化する 各メンバーが重要だと思うHMWに投票して、課題をまとめる。 HMW(How Might We)とは、「どうすれば~」から始まる簡潔な言葉で付箋を書いていく手法の１つです。 これにより付箋に書かれるフォーマットの統一と、課題について焦点を当て易くできます。 HMWの例 各メンバーが出したHMWをグループ化した上で重要だと思うHMWを投票により数個選んでDAY2のプログラムは完了となります。 DAY3 決定のプログラム このプログラムではDAY2で選出したHMWを元にアイデアの発散と抽出を行うことがゴールとなります。 課題ごとにアイデアを発散する アイデアを整理し、グループ化する 良いと思ったアイデアにメンバーが投票する どのアイデアをプロトタイピングするか決定する アイデア発散の例（黄色がHMW,オレンジがアイデア） アイデアの整理、グループ化が終わり次第、プロトタイプ作成を行うアイデアを数個選んでDAY3のプログラムは完了となります。 DAY4 プロトタイプのプログラム このプログラムでは採用したアイデアからチーム分けを行い、プロトタイプ作成のために作業時間を取りました。 プロトタイピング手法は最終的にテストできる形であれば良いのでチームごとで最も得意な形式で作成して頂きます。 プロトタイプを完成させた段階でDAY4のプログラムは完了となります。 DAY5 検証のプログラム このプログラムでは各プロトタイプのテストと検証を行いました。 実際にプロトタイプを使っていただくために、今回テスターは社員を協力してもらいました。 各テストが終わり次第、出た意見を元に考察し、反映する内容・次のアクションを決めました。 導入して感じた利点と現状の課題 それでは、デザインスプリントの各プログラムを回して感じた利点や課題について共有します。 利点について 統一された認識の元でのアイデア創出 短い間でプログラムを実施したため、DAY1で固めた認識が定着しプロトタイプを作成するまでに大きくずれることはありませんでした。 メンバーごとで分かれて作業した後もチームとして一体感を持ち、プロトタイプを作り上げられたと感じています。 短時間で密なプログラムによる効率的なコミュニケーション 短い間に長時間チームメンバーとコミュニケーションを取る仕組み上、メンバーの相互理解も並行して進んだように感じました。 これにより、デザインスプリント外でも職種間のやり取りがよりスムーズになりました。 課題について デザインスプリントのスピード感 本来5日間通して行うプログラムですが、今回はデザインスプリントをやりつつ並行して通常施策の作業を進めていたため、プログラムの間は1週間ほど空いてしまったケースもありました。 故にデザインスプリントで重要な要素の１つであるスピード感は意識し切れていなかった可能性があります。 プログラムごとに時間を空いてしまう場合は、前回のプログラムでは何を行ったかログを残しておき、次のプログラムでもすぐ考えられるように準備をしておくとスムーズに思考しつつプログラムを進めることができると感じました。 どんなサービスについてデザインスプリントを実施したか 今回、デザインスプリントを活用したサービスは住まいインデックスというサービスになります。 住まいインデックスは住み替えの予算、ユーザーにあった地域などのような住まい探しにおける悩みを解消するサービスです。 lifullhomes-index.jp まとめ デザインスプリントの初導入した手法と感じた利点、課題などを紹介しました。このように初導入でも挑戦できる環境は整っています。 今後デザインスプリントを導入検討している方々の参考になれば幸いです。 最後になりますが、LIFULL では一緒に働く仲間を募集しています。よろしければこちらも合わせてご覧ください。 hrmos.co hrmos.co

こんにちは！テクノロジー本部事業基盤ユニット改善推進グループ所属の王です。 現在はLIFULL HOME'Sの各種サービスが参照するデータベースをOracleからPostgreSQLに置き換えるDB移行プロジェクトの業務を担当しています。 今回のブログのテーマは、DB移行プロジェクト内の課題を解決するため、PostgreSQLデータベースの拡張機能oracle_fdwの使用検証および検証中の気付きです。 DB移行プロジェクトの詳細については、こちらのブログを参考にしていただけるとうれしいです。 www.lifull.blog www.lifull.blog www.lifull.blog DB移行プロジェクトの課題 oracle_fdwを使用検証するきっかけとしてはDB移行プロジェクトにある課題の解決です。 課題について説明します。 DB移行作業におけるテーブルの依存関係 DB移行プロジェクトで移行する予定のさまざまなSQLの中には、一つのSQLで複数のテーブルにデータ参照している場合があります。例としては複数テーブルの結合があるSELECT文、テーブルの参照結果を別テーブルにINSERTするなどです。 これらのSQLによって、DB移行作業におけるテーブル間の依存関係が発生しています。たとえば、テーブルAとテーブルBが同じSQLに使われる場合、テーブルAへのDB参照を完全に移行するため、テーブルBへのDB参照を変更する必要があります。 複雑なテーブル依存関係が課題 複雑なテーブル依存関係はDB移行作業に支障を与えて移行プロジェクトの課題となっています。 今回DB移行プロジェクトにさまざまな複雑なSQL文を移行する必要があります。SQLに使われるテーブルは数多くあり、DB移行におけるテーブルの依存関係は非常に複雑となっています。 移行する予定テーブルの中で、仮に一つのテーブルのDB参照が移行先に変更することが難しい場合、依存関係を持つほかのテーブルにも影響してしまい移行できなくなります。 上記の状況は実際にプロジェクト内で発生しています。複雑なテーブルの依存関係によって、部分的な移行進捗の遅れはプロジェクト全体の進捗に大きく影響する可能性があるため、現在プロジェクトの一つの課題となっています。 oracle_fdw 上記テーブルの依存関係による影響を減少させるために、oracle_fdwというPostgreSQLの拡張機能を導入することを検討しています。 oracle_fdwとは？ oracle_fdwはPostgreSQLの拡張機能の一つです。 FDWとは、外部データラッパー(Foreign Data Wrapper)の略称です。Postgresにはさまざまな外部データラッパがあり、Postgres以外のデータソースをアクセスする仕組みです。oracle_fdwはその中の一つです。 Oracle上のテーブルやビューをPostgreSQLの外部テーブルにマッピングすることにより、PostgreSQLからOracleデータベースにアクセスして、データを取得することが可能となります。 oracle_fdwに関する詳しい説明は以下の資料が参考になると思います。 外部データとの連携 ～FDWで様々なデータソースとつなぐ～ Oracleデータベースにアクセスする ～oracle_fdwの基本的な使い方～ また、oracle_fdwはOSSとしてGitHubに公開されています。関連情報も以下から取得できると思います。 laurenz/oracle_fdw なぜ課題の解決に役立つ？ oracle_fdwを使用することで一つのSELECTで複数のテーブルをJOINしている場合でも、異なるDBインスタンスにあるテーブルどうしをJOINしてデータを取得できます。 この特性を活かすことによってSQLを移行する時に、SQLに使われるテーブルを全部移行先のPostgreSQLにデータ参照変更が必要という制限はなくなります。 移行する予定テーブルの中で、仮に一つのテーブルのDB参照が移行先に変更することが難しい場合、依存関係を持つほかのテーブルにも影響してしまい移行できなくなります。 すなわち、上記のようにしばらく移行が難しいテーブルが存在する場合でもそのテーブルの参照だけOracleのままにしてほかの依存テーブルはPostgreSQLに参照することとなります。 検証作業での気付き oracle_fdwはまだ現段階使用の検証しており、実際にプロジェクト内で使用するのが始まっていないですが、検証作業をしてみていくつか気付きがあったので共有します。 PostgreSQLにインストール oracle_fdwのインストールは以下のページの記載を参照することがお勧めです。 インストールガイド 注意点は下記となります。 oracle_fdwの使用にはPostgreSQLのバージョンが9.3以上を要求しています。AWS RDSの場合、PostgreSQL 12.7、13.3、14およびその以降のバージョンしか導入できない制限があります。バージョン関連の情報は Amazon RDS でサポートされる PostgreSQL のエクステンション に参照可能です。 OracleへのアクセスにはPostgreSQLサーバにOCI(Oracle Call Interface)ライブラリのインストールが必要です。バージョン11.2以上を要求しています。 使い方 画像引用元: https://www.postgresql.fastware.com/postgresql-insider-fdw-ora-bas 上記の図に示すようにPostgreSQLの外部テーブルとOracleのテーブルのマッピング関係を設定する上で、PostgreSQLからOracleテーブルのデータをアクセスできます。 連携先のOracleデータベースの各種情報を利用して、下記の手順で設定する。 oracle_fdwのエクステンション（EXTENTION）の作成 CREATE EXTENSION oracle_fdw でPostgreSQLのエクステンションを作成する必要があります。 外部サーバの作成 Oracleのホスト、ポート、データベース名を格納する外部サーバを作成する CREATE SERVER ora_sv FOREGIN DATA WRAPPER oracle_fdw ## ホスト、ポート、データベース名を設定する OPTIONS (dbserver 'host_ora:1521/XEPDB1') PostgreSQLユーザーに外部サーバの使用権限をつけることも必要です GRANT USAGE ON FOREIGN SERVER ora_sv TO postgres; ユーザーマップの作成 OracleユーザーとPostgreSQLローカルユーザーとのマッピングする ## Oracleデータベースのユーザー名、パスワードを設定する CREATE USER MAPPING FOR postgres SERVER ora_sv OPTIONS ( USER 'ora_user', PASSWORD 'xxxx'); ユーザーマッピングすることで、Oracleユーザーと同じアクセス権限をもらう 外部テーブルの作成 最後、PostgreSQLに外部テーブルを作成して、Oracleテーブルとのマッピングを設定する CREATE FOREIGN TABLE f_ora_tbl( ## 主キーカラムはkeyオプションで設定する id int OPTIONS (key 'true'), name varchar(64), t_data timestamp) ## スキーマ、テーブルを設定する SERVER ora_sv OPTIONS (SCHEMA 'ORA_USER' , TABLE 'ORA_TBL'); テーブルのマッピングには以下の注意点があります。 テーブルカラム定義は、Oracle側のテーブルカラムと同じ種類のデータ型を定義する必要があります。異なるデータ型を指定する場合、oracle_fdwが自動的にデータ変換が行います。 OracleとPostgreSQLテーブルカラムのマッピングはカラムの順序をそれぞれ対応させる、外部テーブル作成する時はカラムの順番は要注意です。カラムの順番が間違っている場合、正しいデータアクセスが行われない可能性があります。 Oracle側のテーブルデータを更新する場合は、主キーカラムすべてにkeyオプションの設定が必要です SQLパフォーマンスへの影響 oracle_fdwを使うSQLを発行する場合、SQLの実行にOracleとPostgreSQL間の通信が発生します。ローカルのテーブルアクセスと比べて、データベース間の通信速度、通信容量の制限に影響があるため、SQLのパフォーマンスには影響する場合もあります。 連携先のOracleデータベースから大量のデータを取得する場合、SQLのパフォーマンスが落ち、PostgreSQLおよびOracleにも負荷をかける可能性があるため、実際の使用には要注意です。 PostgreSQL外部テーブルへのアクセスがある2つのSQLから説明したいと思います。 SQL A select count(*) from ora_tbl s join tbl g on s.id=g.id and (s.id=952 or s.id=948) Execution Time: 5.935 ms SQL B select count(*) from ora_tbl s join tbl g on s.id=g.id and (g.id=952 or g.id=948) Execution Time: 2656.699 ms * ora_tblは外部テーブル、tblはローカルテーブル。 上記2つのSQLは外部テーブルとローカルテーブルの結合を行い、絞り込み条件にあうレコード数を取得しています。 SQLの実行結果は一致していますが、SQL Aの実行時間はSQL Bより明らかに短いです。 SQLの実行計画から原因を特定すると、以下のことが分かります。 SQL A explain analyze select count(*) from ora_tbl s join tbl g on s.id=g.id and (s.id=952 or s.id=948) "Aggregate (cost=24004.50..24004.51 rows=1 width=8) (actual time=5.837..5.838 rows=1 loops=1)" " -> Nested Loop (cost=10000.29..24002.00 rows=1000 width=0) (actual time=0.430..5.566 rows=1153 loops=1)" " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.407..3.479 rows=1153 loops=1)" " Oracle query: SELECT /*727d818c0e8c5e5fc8c1ba25f14f1951*/ r1."COL_1" FROM "ORA_TBL" r1 WHERE ((r1."ID" = 952) OR (r1."ID" = 948))" " -> Index Only Scan using pk_tbl on tbl g (cost=0.29..4.00 rows=1 width=6) (actual time=0.001..0.001 rows=1 loops=1153)" " Index Cond: (id = s.id)" " Heap Fetches: 706" "Planning Time: 1.569 ms" "Execution Time: 5.935 ms" SQL B explain analyze select count(*) from ora_tbl s join tbl g on s.id=g.id and (g.id=952 or g.id=948) "Aggregate (cost=20019.19..20019.20 rows=1 width=8) (actual time=2656.574..2656.578 rows=1 loops=1)" " -> Hash Join (cost=10016.56..20019.18 rows=1 width=0) (actual time=276.345..2656.376 rows=1153 loops=1)" " Hash Cond: (s.id = g.id)" " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.400..2549.151 rows=717509 loops=1)" " Oracle query: SELECT /*90e1158c8e451061bc34a219bd77fa69*/ r1."ID" FROM "TBL" r1" " -> Hash (cost=16.53..16.53 rows=2 width=6) (actual time=0.028..0.030 rows=2 loops=1)" " Buckets: 1024 Batches: 1 Memory Usage: 9kB" " -> Bitmap Heap Scan on tbl g (cost=8.60..16.53 rows=2 width=6) (actual time=0.023..0.027 rows=2 loops=1)" " Recheck Cond: ((id = '952'::numeric) OR (id = '948'::numeric))" " Heap Blocks: exact=2" " -> BitmapOr (cost=8.60..8.60 rows=2 width=0) (actual time=0.017..0.019 rows=0 loops=1)" " -> Bitmap Index Scan on pk_tbl (cost=0.00..4.30 rows=1 width=0) (actual time=0.013..0.013 rows=1 loops=1)" " Index Cond: (id = '952'::numeric)" " -> Bitmap Index Scan on pk_tbl (cost=0.00..4.30 rows=1 width=0) (actual time=0.004..0.004 rows=1 loops=1)" " Index Cond: (id = '948'::numeric)" "Planning Time: 1.377 ms" "Execution Time: 2656.699 ms" 実行計画のForeign Scanの部分を注目してください。 SQL A " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.407..3.479 rows=1153 loops=1)" " Oracle query: SELECT /*727d818c0e8c5e5fc8c1ba25f14f1951*/ r1."COL_1" FROM "ORA_TBL" r1 WHERE ((r1."ID" = 952) OR (r1."ID" = 948))"" -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.407..3.479 rows=1153 loops=1)" SQL B " -> Foreign Scan on ora_tbl s (cost=10000.00..20000.00 rows=1000 width=14) (actual time=0.400..2549.151 rows=717509 loops=1)" " Oracle query: SELECT /*90e1158c8e451061bc34a219bd77fa69*/ r1."ID" FROM "TBL" r1" 主な実行時間の差はForeign Scanから生じます。 Foreign ScanはOracleのアクセスする時に発生します。SQL Aの場合、Foreign Scanから取得するレコード数は1153です。SQL Bの場合、Foreign Scanから取得するレコード数は717509です。 結論として、oracle_fdwの使用する時、OracleとPostgreSQLの通信データ量はSQLのパフォーマンスに大きく影響します。 oracle_fdwを使う時のSQLパフォーマンスが気になる場合、Explain文でSQLの実行計画を分析してSQLチューニングすることがお勧めです。実行結果にあるForeign Scanの回数およびレコード数を抑えるSQLチューニングはSQLパフォーマンスの向上に役立つと思います。 oracle_fdwを使うSQLの性能を影響する要因はほかにもあるため、気になる方は下記の記事を参考できると思います。 Oracleデータベースにアクセスする ～oracle_fdwを使いこなすために～ まとめ 以上PostgreSQLのoracle_fdw拡張機能を検証してみた話でした。読んでいただきありがとうございます。 まだ実際にDB移行プロジェクトには導入していないため、導入後のメリットとデメリットまたはプロジェクトへの影響はまだ不明です。今後また機会があればブログを書いて共有したいと思います。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

こんにちは、LIFULLでエンジニアとして働いている中島です。 私は2010年入社なので現時点で12年程同社で働いています。 長い方ではありますが、LIFULL社はそれよりずっと長く歴史のある会社で、多種多様なメンバーがいます。 その中には自分の意思で職種変更をしたメンバーや、自身の職種がそもそも時の流れとともに無くなり、変わらざるをえなかった方々もいます。 本記事では、フロントエンド領域に関わる職種変更に伴い、LIFULLではどのような課題があったか、また、メンバーの技術ギャップを埋めるためにどのようなサポートを行ったかについて紹介させていただきます。 コーダー職種からフロントエンド職種へ 育成を現場へ サポートの内容 その後の会社への影響 最後に one more thing コーダー職種からフロントエンド職種へ 5年程前、世の中のフロントエンドエンジニアに求められる技術スタックが大きく様変わりし、それまでマークアップ、CSSコーディングを生業にしていた方々はその際に大きな転換期を迎えたのではないでしょうか。 その世の中の転換が正しかったのかは私には分かりませんが、弊社でも同じように世の流れに沿う形でコーダー(マークアップを主とする)職種がなくなり、フロントエンドエンジニアという職種(あるいはもう少しプランナー、デザイナー寄りの職種)への変更の話がでて職種の新設、廃設がおきました。 会社としては移行対象者に対してはそれぞれサポートを試みましたが自学自習がベースにあり、業務時間を利用した学習の許可や、学ぶためのオンライン講座等の提供といった感じのものが多く、本人のモチベーションに依存している側面があり、人によっては中々厳しそうな現実が見えていました。 育成を現場へ 人事規定の変更なので人事側と技術マネージャーが主体となって動くわけですが、そこからのアプローチだと工夫しなければ既出の課題を抱えてしまうので、もともと自分の業務時間の数割を割いて行っていた技術育成の枠を使って移行メンバーのサポートをさせてもらないかと打診してみました。 (対等な同僚で且つ自分から望んだわけではない職種変更にあったメンバーにサポートという表現を使うのは随分と偉そうですが表現が難しいのでサポートという表現で記述していきます) 移行メンバーは10人程なので有志のメンバーで数人ずつ担当すれば現実的に対応可能なのかなと思っての提案だったのですが願ったり叶ったりということですぐにその運用が開始されました。 サポートの内容 弊社の場合、コーダー職からフロントエンド職への移行にあたっての最大の難所はJavaScriptなわけですが、幸い技術育成のためのドキュメントや理解度を図るための課題はもともと別の方々を対象にした技術育成を行っていた際に作っていたのでそれを再利用した方法で行うことができました。 JavaScriptそのものに対する学習カリキュラム 目的と内容については以下の通りです。 言語特性の理解(初級) 変数 式 値の種類 関数宣言 関数式 スコープ if for Array 言語特性の理解(中級) スコープチェイン クロージャ functionが一級オブジェクトであることの理解と意識の植込み 高階関数 再帰 コンテキストの理解 thisの決定原理 thisの束縛 call/apply classical実装パターンの理解 constructor/new prototype inherit class syntax DOM Modelおよび周辺技術の理解 DOM Scripting イベント バブリング・キャプチャリング 非同期について Ajax/JSONP 設計パターンの理解 オブザーバーパターン メディエイターパターン ストアパターン 各種ライブラリの再実装 10人もいれば全員に向けて会を開くのが最小コストにも見えますが、もともと興味があったメンバーが集まってるという前提があるわけでもないので個別に時間をもうけてお互いのマインドを理解しあい、心理的安全性を高めることに重きをおきながら毎週行いました。(今年で2年、それ以前から受けてた方もいらっしゃるので長い方は4年ほど) HTMLコーディングをバックグラウンドにもつ方々が多かったので、最近ではある程度言語理解が深まった後はJavaScriptのツールチェインとかaltJSの分野ではなくアクセシビリティを高めるために付随して必要になってくるJavaScriptを学ぶという方向性で授業内容を組み立てるようにしました。 具体的にはWAI-ARIA Authoring Practices 1.1(現在は1.2)で取り扱われているUIパターンの読み込み、実装練習になります。 www.w3.org WAI-ARIA Authoring Practicesで紹介されるUIパターンのうち、カリキュラムとして採用したもの Alert Disclosure Dialog Tabs Feed Listbox MenuButton Menu or Menubar Carousel Combobox Grid そのほかのUIパターンについてはこれらを履修後に読み込みだけを実施 これはそれまでの言語理解のための授業に比べると、自身のもともとある強みを拡張する方向の内容になるのでモチベーションの高まりを感じることができてとてもいい選択でした。 (人によってはその後サーバサイドに興味を持ちRubyやNodeでのアプリケーション制作の演習などに進んだケースもあります) その後の会社への影響 今LIFULLではいくつかのWG(ワーキンググループ)があります。 その中にはLIFULL HOME'S全てのフロントエンド開発をより良くしていこうというWG、全サービスを対象にアクセシビリティ向上を推進していこうというWGなどもあります。 私はその両方に所属しているのですが、フロントエンドを改善していく方のWGでは、デザイナーからこのサポートを経てフロントエンドエンジニアに転身された方が活躍してくれていたりします。 彼ら・彼女らにしかないバックグラウンドを生かした取り組みもあり、デザイナーとの橋渡しやスタイルガイドの作成など幅広く成果を出してくれています。 アクセシビリティの推進活動を行うWGにおいては、会社の全サービスを対象に推進活動を行うため、もともと数人のWGメンバーでは当然各PJに参入して実装支援を行う...とまではいかない現実がありました。 しかし、それぞれのPJには代わりにこのサポートをうけてくださった方々が入っていることが多く、そこで得た知識を実務に生かしてくれており、WGとしてはアクセシビリティレビューの請負や啓蒙活動、相談対応を、現場の転身組は実装でそれを力強く支えるという関係性ができつつあります。 最初は単純に移行をサポートしたいという気持ちだけで始まったものですが、それが回り回って波状的に会社を前進させる力となっているのを感じます。 最後に 近年フロントエンドエンジニアの採用事情はかなり厳しいと聞きます。 採用ばかりではなく内側に眠っている多くの才能にも目を向けていきたいですね。 one more thing LIFULLでは共に成長できるような仲間を募っています。 よろしければこちらのページもご覧ください。 hrmos.co hrmos.co

エンジニアの内藤です。LIFULL HOME'Sの売買領域を支えるエンジニアチームのマネジメントを担当しています。 弊社エンジニア部門では 強い個人・最高のチームになることで価値創造を加速させ続ける というビジョンを掲げています。 これは新しいサービスの開発や機能改善による足元での価値提供だけでなく、開発生産性を向上させることで長中期的により多くの施策をまわせるようになり価値提供を最大化させることを目指してのものです。 そこで私たちのグループは個人のスキル（テクニカル・ポータブル）・環境（プロダクト・ツール）・体制（チーム・業務フロー）を改善していくことにも取り組んでいます。 自分たちの開発生産性を向上させるのに何をしたら良いのか、自分事として捉えてもらうためにもグループのメンバー全員でディスカッションしました。 その中でメンバーから発案があったものの１つが 裏HOME'S斬り と名付けたものでした。 「HOME'S斬り」とは 裏HOME'S斬り の前に、LIFULLでの HOME'S斬り の取り組みについて説明します。 弊社では HOME'S斬り と称して、入社したての社員にLIFULL HOME'Sを使い倒してもらい、課題を見つけてその改善アイデアを発表してもらうことをよくやっています。 これは主に下記の目的のためにおこなっています。 サイトにどんなページや機能があるのか把握してもらう まだ慣れていなので、第三者的視点でサイトの課題を見つけてもらう サイトを長く運用・改修していると機能や見た目に慣れてしまい、課題に気付かなかったり課題と思えなくなってしまうことが多々あります。 社歴が長い社員にとっても新鮮な気付きを得られる機会で、非常に有益な場となっています。 「裏HOME'S斬り」とは 裏HOME'S斬り とは、この HOME'S斬り をHOME'Sの裏側であるプロダクトのソースコードを対象としてエンジニア目線でおこなうことです。 取り組みのねらい 裏HOME'S斬り を実施することは下記のようなメリットがあると考え、実行することにしました。 システムの負債に対する意識のレベルが共通化される ⇒　若手のスキル向上 改善案を実施すればリファクタリングが行なえる ⇒　プロダクトの負債の解消 メンバー発案なので自分事と捉えて活動できるのではないか ⇒　主体性発揮の機会・経験（チーム力向上） 実行における工夫 エンジニアがソースコードの課題を見つけて改善案を出すことは、下手するとディスるだけになってしまう懸念がありました。 ※その場に実装した人がいるかもしれないのに・・・ また、業務の負荷になる作業が増えてしまうと本末転倒なので下記のようなルールを定めました。 既存のコードには敬意を持って接しましょう 斬るべき対象はエンジニア目線であればいい ここのロジックもっとスマートにできないか データ構造が気持ち悪い これもう不要だよね アクセシビリティもっと考えられるはず etc がっつりプレゼン資料は作らなくてもいい 対象の場所がわかればOK 発表後、「直したほうがよいか」「すぐにできるか」あたりの軸を参加者で評価する 評価した結果 ふりかえり 通常業務に影響がでないように2ヶ月に1回ぐらいのペースで数回実施してきましたが、良かった点・改善すべき点がそれぞれ幾つかありました。 良かった点 ソースコードの負債に対する意識が強くなった 普段の業務でソースコードを見る際に改善点をより気にするようになった どう直すのが良いか議論が白熱することもあり、より深く本質的に捉えるようになった アクセシビリティの課題など一部のものは改善実施までおこなえた 純粋に楽しんで活動できた 改善すべき点 開発効率の向上を意識し過ぎたせいで「すぐにできるか」という点で該当するものが少なくなり、実施に移せないものが多かった 実施できそうなものも誰がいつやるかという点で曖昧になってしまい、実施まで進められないものもあった 期待していた自主性発揮についてはあまり効果がなかった 途中で「直したほうがよいか」に該当するものは規模に関わらずタスクチケットを作っておき、後ほど余裕がある時に対応できるようにするなどブラッシュアップしながら実施していました。 しかし、改善実施まで完了させるにはまだまだ工夫が必要なことが見えてきました。 例えば、すぐできそうにない規模のものでも負債解消度の高いものはプロジェクト化を検討したりすることで、実行まで進めることができそうです。 まとめ 上記のように 担当者を決める ・ 改善実施に使える時間を確保する ための仕組み化をできるだけ通常業務に影響を与えない形で構築できれば、より多くの改善実施の成果まで辿り着けると考えています。 引き続き 楽しんで活動できる利点を活かしたまま 、成果を出すために 裏HOME'S斬り の改善を続けていきたいと思います。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

テクノロジー本部のyoshikawaです。 最近のLIFULLでは、自社が所有するデータの活用を目的に数多くの取り組みが実施されています。 今回はデータの発見可能性(Data Discovery)を向上させるための基盤構築を目指して実施したPoC(Proof of Concept)とそのOSSの選定について紹介します。 当初は「自社データの再利用性を高めたい」という広い意味を持った要件で開始したプロジェクトでしたが、 Data Discoveryがボトルネックになっていると判明し、解決策としての基盤構築に向けてPoCを実施することとなりました。 現場の課題調査からOSSの選定と試験運用まで一連のトピックをまとめていきます。 初期フェーズ: 現場調査と課題抽出 FAIR原則 データ利用の現場から抽出した課題 ボトルネックの特定と解決策の選定 PoCの開始 OSSの選定 Datahubとは Metadata ingestion PoCの評価指標 PoCの結果 Data Discovery Platform導入への期待 Data Discovery Platformはあくまでも必要条件 これからの展開 求人情報 初期フェーズ: 現場調査と課題抽出 昨年秋、「自社データの再利用性を高めたい」という目的とともにプロジェクトがスタートしました。 筆者をはじめ、プロジェクトメンバーにはデータエンジニア的なバックグラウンドを持つ人はおらず、まずは現場調査を通じ探索的に解決策を導出することとなりました。 ディスカッションや調査の際には記録を手続き的なドキュメントとして残すのではなく、 IBIS(Issue Based Information System) という手法と オンラインホワイトボードのMiroを活用することで、議事録作成をDialogue mapping化しDAGとして残しました。 miro.com 現場調査のフェーズは2ヵ月にわたり、なおかつ多くのステークホルダーに対して実施したため、 過去のやりとりと現在の関心事との関連を視覚的に把握しやすい形式で議論を行うことで議論の発散と収束を視覚化できたのは効果的でした。 MiroでのDialogue Mapping: 議論の現在地や目的を可視化 FAIR原則 データの再利用性を高めたいという観点でスタートしたものの、この時点ではデータエンジニアリングの観点が不足していたこともあり最終的な成果の定義に難儀してしまいました。 民間企業だけではなくアカデミックにおいてもデータ活用の問題は存在していると考えリサーチを行ったところ、データ共有の原則であるFAIR原則を発見しました。 biosciencedbc.jp FAIR原則を知り、これまでに自分たちが焦点を当てていたデータの再利用性とは、相互に関連する4つの原則のうち1つに関連するものでしかないと認識しました。 これ以降は、データ活用にまつわる複数の問題を念頭に置きつつ、ディスカッションや後続となるインタビュー調査を実施しました。 データ利用の現場から抽出した課題 データ分析者やAIエンジニア、プロダクト開発を行うアプリケーションエンジニアや企画職などデータに関連する職種の方々に協力いただきインタビュー調査を行いました。 その結果を要約すると、下記のような課題が得られました。 データの格納場所やデータの情報(メタデータ)あるいはデータの存在自体が不明、または特定のチームや個人のナレッジとして埋没している データの派生系が多く、利用価値のあるデータ・起源となるデータなどユニークなデータが発見できない 発見したデータが更新されているのか、誰が管理しているのかが不明で利用開始するまでに問い合わせが発生する いわゆるデータのサイロ化に起因する問題が目につきます。 これらインタビュー調査の結果を踏まえ、あるべき解決策は静的なドキュメンテーションや属人的な助け合いの仕組みの強化ではなく、 「自動で最新の状態に追従可能で、統一された形式に沿って管理・運用されたデータが入手可能な基盤」であると結論づけました。 ボトルネックの特定と解決策の選定 ここまでの調査は現場の開発者・分析者へのインタビューなどを通じてボトムアップ的に行われてきました。 調査で得られた生の課題の集まりに対して優先的に取り組むべき課題と解決策を選ぶために、書籍"The Self-Service Roadmap"にて導入されていた考え方を取り入れました。 The Self-Service Roadmapにおいては、データ活用の主たる指標とも言える"Time to insight"(知見を得るまでの時間)を "Discover", "Prep", "Build", "Operationalize"の4つのフェーズに分割することが提唱されています。 自分たちの調査によって集められた課題は、Discoverのフェーズ、特にデータセットあるいはそのメタデータの検索の課題に該当すると判断しました。 つまり"Data Discovery"こそが開発・分析現場のボトルネックとなっており、優先的に取り組むべき課題であると判明したのです。 PoCの開始 The Self-Service Roadmapにおいてself-service data platformが立ち行かなくなるアンチパターンとして、 問題を理解しないまま技術にだけ投資してしまうことと、一度に多くの問題を解こうとすることが挙げられています。 アンチパターンに陥らないためにも今回のプロジェクトではData Discoveryに焦点を当て、 これを持続的に解決可能な基盤を導入すべく、技術選定とそのPoC(Proof of Concept)から始めていきます。 OSSの選定 近年、海外を中心としてModern Data Stackという言葉とともに最新のデータ基盤周辺技術に注目が集まっています。 日本でも注目されているdbtのブログにて、Modern Data Stackの来歴とともに展望を読み取ることができます。 blog.getdbt.com Data Discoveryの分野だけでなく、Modern Data Stackを構成する技術は多岐に渡り、 解決したい問題領域や抱えるデータセットの量、事業フェーズなどの制約条件に沿って適切な技術を選定する必要があります。 今回の場合は「 "多様なデータソース" に対して "Data Discovery" を向上させるための "基盤(Platform)" の "PoC" を行いたい」という制約に基づき、 LinkedInとAcryl DataによるOSSである "Datahub" を選びました。 datahubproject.io Data Discoveryの向上を目指せるMetadata Platform系のOSSにはAmundsenやApache Atlas、Open Metadataなどがありますが、 PoC期間内での構築しやすさ・運用可能性、利用者(社内開発者・分析者)向けのUXや機能性を考慮した結果、Datahubを選定しました。 OSSの採用以外の選択肢には、社内で利用しているGoogle CloudのData Catalogを充実させるという選択肢もありましたが、 LIFULLのデータセットはAWSやGCPなど複数のインフラで稼働しているため、中立的なDatahubを試用することとなりました。 Datahubとは 公式ドキュメントでは下記のように説明されており、多様で複雑なデータエコシステムにおけるMetadata PlatformとしてData Discovery, Data Observability, Federated Governanceを実現させることが特徴として挙げられています。 Data ecosystems are diverse — too diverse. DataHub's extensible metadata platform enables data discovery, data observability and federated governance that helps you tame this complexity. Data Discoveryという点ではElastic Searchによるメタデータの検索やWebブラウザのようなUI、Datahub独自のシンプルで拡張性のあるメタデータスキーマによって実現されています。 このようにしてプロダクト開発者や分析者などデータ利用者にとってはシンプルな機能を提供しつつも、 Push型のデータ更新アーキテクチャによる最新のデータへの追従やData Lineageの取得によるObservabilityの確保と、 AWSのIAMのようなRBACによりFederated Governanceの実現を目指すことができ、継続的な運用に耐えうるカタログスペックを有しています。 また、DatahubではQuick Start用のDocker Imageやhelm chartsも用意されており、ローカル環境での試用やPoCが容易に実現可能です。 今回のPoC期間中でもhelm chartsを利用し、LIFULLの検証用Kubernetes環境上に1日程度でデプロイできました。 デプロイしたDatahubのトップ画面 Metadata ingestion RDB(MySQL,Postgres,etc),DWH(BigQuery,Snowflake,etc),BI(Tableau, Looker)など多岐にわたるデータソースから、カラムの物理名やスキーマ情報などのmetadataのingestionが可能です。 ingestされたmetadataに対してはUIやAPI経由で編集することが可能で、データに関するナレッジなどTeam Metadataも集約することが実現できます。 PoC期間中ではFederated Governanceの観点を検証しきれませんでしたが、基盤の管理者がingestionを中央集権的に管理・実行するのではなく データソースに近いプロダクト開発エンジニアやデータソース運用者がDatahub上のmetadataのOwnerとなることで、 自分達のTeam Metadataは自分達で管理しつつ横断的なプラットフォームで第三者が入手・検索可能にし、self-serviceなデータ基盤を実現できるのではないかと考えています。 例えば、DDDにおけるユビキタス言語を制定した後はDatahub上に載せて、チーム内外の認識の齟齬を減らせることが期待できます。 Metadata ingestionの実行後イメージ: タグやTermsからmetadataが検索できる PoCの評価指標 Datahubによって実現されるData Discovery Platformが本当に現場のData Discoveryを実現するかを評価することに加え、 大元の課題であったデータ活用の促進を実現できるかを検証するために、いくつか設問を用意しData Discovery Platformの利用者にアンケートをお願いしました。 例えば以下の2つです。 設問1. Datahubで構築したData Discovery Platformは、欲しいデータを発見するまでの時間を短縮するか？ 設問2. Datahubで構築したData Discovery Platformは、データを発見してからデータを活用開始するまでの時間を短縮するか？ The Self-Service Data RoadmapにおけるDiscoverにおけるメトリクス:"Time to find"への貢献度を設問1で収集し、 Discoverというmilestoneを含めたデータ活用開始までの時間短縮への貢献度を設問2として収集しています。 別途、性能評価やマシンリソースの消費度合い、費用など非機能的な要件の評価も行います。 PoCの結果 社内のデータ基盤エンジニア・データ分析者・アプリケーション開発者・技術マネージャーなどにData Discovery Platformは利用され、アンケートを実施いただけました。 その結果、設問1については9割が好意的な回答で、設問2については好意的な回答が5割、否定的orわからないという回答が5割でした。 Data Discovery Platform導入への期待 設問1で好意的な回答が大半を占めたことから、Data Discovery Platformを意図して構築されたプラットフォームが 現場のData Discovery向上に寄与することが立証できたと言えます。 データ発見という観点で既存の社内ツールや技術基盤に対する競合優位性があったことは確かですが、 今後全社的に運用する場合、ingestするデータセットが増加し玉石混合なmetadataを持ってしまうリスクもあるので注意は必要です。 Data Discovery Platformはあくまでも必要条件 一方、設問2では半数が「いいえ」あるいは「わからない」など好意的とは言えない回答であったことから、 Data Discovery Platformの実現はあくまでデータ活用のための必要条件であり、十分にデータを活用するには他にも解決すべき課題があると考えています。 ただし好意的な回答が少なかった外部要因として、PoC期間に十分なmetadataを用意できなかったという要因もあるので、 ingest自体を効率化するような仕組みを検証していきたいと考えています。 これからの展開 今回のPoCを経てData Discovery Platformの導入が開発現場・分析現場のデータ活用を促進する一歩となることを立証できました。 ただ、あくまでPoCが成功したに過ぎず本格的な稼働に向けては運用面での課題も存在します。 魅力的な技術や目新しい技術の多いModern Data Stackですが、"right tool for the right job"を原則としてこれからの基盤構築を行っていきたいところです。 求人情報 LIFULLではエンジニアの募集をしており、カジュアル面談も実施中です。 募集中の職種など詳細は下記をご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の佐野です。 LIFULLでは2020年3月頃からリモートワークが主体の働き方になっています。 出社して働いていた頃と比較すると、同じグループのメンバーとは日々業務を進める上でコミュニケーションは取っているものの、他部署のメンバーとのコミュニケーションが少なくなった...という話もちらほらと。 偶発的なコミュニケーションも必要だ！とのことで社内サークル活動を推奨する制度が出来上がりました。 2022年1月末でサークルは74。多い！ どこかのサークルに入っている人は747人。めっちゃ多い！！ 上記の通り社内サークルは沢山存在していますが、その中でも今回は、私が主催者となって活動している映画サークルについてご紹介します。 映画サークルについて 映画サークルといっても、敷居は限りなく低く（ここ重要）、私の主催しているサークルは基本月1回の活動です（多いと疲れてしまうので）。 リモートワークが主体の働き方に合わせて、活動もオンラインで行っています。 基本メンバーは7名で活動しており、職種・部署はバラバラです。 このサークルで初めて知り合った方が多数で、対面で会ったことのないメンバーも中にはいます。 普段だと、同じ部署や同じ職種の人と知り合うことがほとんどなので、色々な職種・部署のメンバーと気軽にコミュニケーションが取れるのはサークル活動の強みだと感じています。 サークルで観る作品は、Netflixの中からメンバーが面白いと思ったものを観る形をとっています。 Netflixはたくさん作品があるので飽きません。 「映画」とサークル名についていますが、実際には映画に限らずドキュメンタリーなど色々な作品を観ています。 サークル開催 開催日が決まったらオンラインで集合して、速攻番組を観る…というせっかちスタイルではなく、大体の時間帯にオンラインで集合します。 業務ではないのでここはゆるく始めます。 作品を観る前後30分くらいは雑談タイムを設けていまして、その時にみんなで観る作品を雑談しながら決める形にしています。 こんなものを観たい、どんな番組が面白かった、スタートレックが好きだ、等の雑談を和やかにしています。 普段自分では観ない作品も観れますし、みんなの趣味趣向が知れて大変面白いです。 作品との偶発的な出会いが期待できます。 ちなみに作品を見るときは、「再生しまーす」で同タイミングで再生ボタンを押すようにして、各人の環境で作品を観ています。 また、サークル活動にはサークル活動費として会社から補助が出ます。 そのためサークル開催日には予算内で思い思いの飲食物を購入して、サークルでの時間を楽しんでいます。 1月の活動日には、エンジニアの青木さんも飛び入りで参加して和やかに過ごしました。 そのときは、「ミッドナイトアジア」というドキュメンタリーを観ました。 サークルに飛び入り参加してみての感想 今回飛び入り参加させていただいた青木です。 リモートワーク中心となる前は社内ですれ違えば会話していた面々と、 本当に久しぶりにお話しすることができました。 社員数が増えても、業務だけだと接点って増えるわけではないんだな、こういう機会があるのって大事なんだな、と実感しました。 「ミッドナイトアジア」は、まぁ自分では手を伸ばさない作品でサークルならではのチョイスで楽しめました。 まとめ 今回は私が主催する映画サークルについての紹介でしたが、先述した通り多種多様なサークルが存在しています。 ゲームや数学、エンジニアが他職種の方にプログラムを教えるサークルもあります。 サークル活動を通して普段の業務で関わることのない他部署の知り合いも作れますし、コミュニケーションも取りやすくなると思います。 自分で主催するもよし、サークルに入るもよし。 リモートワーク主体の働き方になりましたが、今回紹介したサークル活動以外にもコミュニケーションを取りやすくするための取り組みが盛んに行われています。 1日誰とも会話していない...なんてことも解決するかも！？ LIFULLでは一緒に働く仲間を募集しております。 もし興味を持っていただけたら、募集求人やカジュアル面談のページもご覧ください。 hrmos.co hrmos.co

こんにちは、エンジニアの加藤です。LIFULL HOME'Sの注文住宅領域を支えるエンジニアチームのマネジメントを担当しています。 皆さん、技術的負債の解消やリファクタリングなどどのように行っていますか？ 長年の開発業務により蓄積された技術的負債は、開発生産性を低下させる要因として多くの方の頭を悩ませているかと思います。 私の所属する部署では開発生産性の向上をミッションとして掲げており、技術的負債の解消はミッションを達成するための重要な要素となっています。 そのような中、私たちのチームでは「リファクタDays」という取り組みを通じ、約半年間技術的負債の解消を含むシステム改善に努めてきたので、今回はそちらについて紹介したいと思います。 技術的負債の解消を行う上での課題 開発生産性を上げるため技術的負債の解消が重要である一方、LIFULL HOME'S 注文住宅の機能開発を担当するエンジニアであるため、常にプロジェクトに配置されておりサービス開発を行う必要があります。 そのため、負債解消とサービス開発を両立させるためには、限られた時間の中でバランスよく実行することが重要となります。 昨期以前は組織で技術的負債の解消計画を立てつつ、実行は担当するプロジェクトの状況を加味しつつ各メンバーの裁量に任せておりました。 しかし、ときにはプロジェクトを優先して負債解消への取り組みを劣後せざるを得ない状況もあり、計画に対し思うように進捗させるのが難しい場面もありました。 上記の結果を踏まえ、一番の課題は負債解消に取り組む時間を十分に確保できないことであると捉え、仕組み化により課題解決を図る方法を検討しました。 リファクタDaysという取り組み プロジェクトと両立させるための仕組み 前述の通り、サービスを成長させるためプロジェクトを遂行することも重要な職務であるため、プロジェクトと両立させることは不可欠です。 そのため、どのように負債解消に取り組む時間を確保するかが重要となります。 プロジェクトを計画する上で、不確定な要素はなるべく排除しておきたいものです。 エンジニアがプロジェクト外の開発をいつどれだけ行うか不明瞭である状態では計画も立てづらく、プロジェクトの遂行にも影響を及ぼします。 これらの影響を抑えるよう、負債解消への取り組みは一定周期ごと一定期間実施することとし、あらかじめ半期分時間を確保することとしました。 また、負債解消に取り組む上でも効率化は重要です。 タスクにより粒度や規模は異なるため、1日で完遂するものもあれば数日に及ぶものもあります。 開発途中で手を止めることは開発効率を低下させる要因となるため、連続した数日間を集中して取り組むことができる期間として確保することとしました。 これらをもとに以下のルールを定め、この期間を「リファクタDays」と名付けました。 3週毎3日間利用し実施 実施日は水、木、金の連続した3日間 開始日の朝11時にキックオフを実施し、期間内で実施するタスクを各自ピックアップする 原則この期間はプロジェクトに纏わる活動（開発・MTGなど）は行わない 原則スケジュールの変更は行わない（休暇・祝日が被る場合も） 目的は開発生産性を上げること 開発生産性を上げるためには技術的負債の解消以外にも様々なアプローチがあります。 例えば、運用業務の効率化やリファクタリングによりソースコードの保守性を高めること、システムコストを削減することで人的リソースのコストに回すなど。 リファクタDaysの目的は開発生産性を向上させることであるため、技術的負債の解消に限定せず上記を含めたシステム改善全般を取り組むべきものとして位置付けています。 周囲の協力を得ることが重要 これらの取り組みを考えても周囲の関係者の理解と協力を得ることなしに実行はできません。 特にプロジェクトをともに遂行するプロダクトマネージャーや企画職のメンバーの協力は不可欠です。 リファクタDaysの目的や効果を伝えるだけでなく、ルールのすり合わせや実施後のヒアリング、実施内容の見える化など様々な取り組みを行いました。 これらにより理解を得られ快く協力してもらえたことが、リファクタDaysを遂行するための大きな後押しとなっています。 リファクタDaysでの効果 現在約半年間リファクタDaysを実施してきましたが、時間確保の課題は解消され、プロジェクトと両立しつつ一定のペースでシステム改善を積み上げることができています。 システム改善数の推移 また、LIFULL HOME'S 注文住宅へのリリース数も昨期半年間と比較して一月あたり平均約1.5倍に増加し、高い水準で安定していることから開発生産性向上への効果も感じられます。 LIFULL HOME'S 注文住宅 月別リリース数 まとめ 技術的負債の解消や開発生産性向上は多くの組織で抱える課題であり、重要な取り組みの一つであると思います。 今回紹介させていただいたリファクタDaysの事例が、皆さんの課題解決に少しでもお役に立てたら嬉しいです。 また最後にLIFULLでは一緒に働く仲間も募集しているので、よろしければこちらも併せてご覧ください。 hrmos.co hrmos.co

プロダクトエンジニアリング部の二宮です。 LIFULL では「エンジニアいつでも相談」という名前で、 GitHub Discussions を使った社内向けの Q&A フォーラムを有志で運営しています 🙌 このフォーラムは「あるシステムについて誰か詳しい人に相談したい」とか「設計についてチーム外にも相談したい」とか、エンジニアリングで困ったことをなんでも聞ける窓口になることを目指しています。最近ではアーキテクトチームや QA チームなどの公式の窓口としても利用でき、質問の内容に応じて適切な部署や人がアサインされる体制も整い始めました。 従来は相談相手を見つけるのにも苦労したり、そもそも窓口が用意されていなかったりすることもあり、社内アンケート調査等でよく情報共有が課題に挙がっていました。そこで、社内向けの Q&A フォーラムを用意することで、その問題の一部を解消しつつあります。 エンジニアいつでも相談の利用方法 まず利用方法を紹介します。エンジニアいつでも相談の GitHub リポジトリが用意されていて、その Discussions にフォーラムが用意されています。 ここで過去の質問を検索・起票できます。詳しい案内はトップのハウスルールが掲載されており、初めての人でもあまり迷わずに操作できると思います。ハウスルールには次のような内容が記載されています。 GitHub Discussion 上で過去の質問の検索を行う 解決した場合、Vote をする 既存の質問で解決しなかった場合、「Q&A🙏 」カテゴリで起票する フォーラムに質問が投稿されると、質問の回答者となるチームに通知されます。GitHub Actions によって、タイトルや内容によって各チームにメンションを付けたり、Slack 通知を飛ばす機能が実装されています。もちろん、それ以外の社員も回答できます。 質問者は、問題が解決したら、回答の中からベストアンサー（Mark as answer）を選んでクローズします。 このように、一般的に想像するフォーラムの機能はそろっており、通知の自動化なども必要に応じてすぐに実装できます。 GitHub Discussions を利用するメリット 過去のツールの変遷 実は、エンジニアいつでも相談は、発足当初から以下のような思いは一貫しています。しかし、ツール面ではいくつかのものを渡り歩いてきました。 社内のドメイン知識や社内ルールが分からず悩んでほしくない 将来的にエンジニアの共助・評価・成長につなげたい 具体的には以下のような変遷がありました。 Google グループをフォーラムとして利用する フォーラムを使わずに有志でチャット上で質問・回答をする GitHub Discussions でストック化を促進 まず、Google グループではなかなか質問自体が集まりませんでした。これは、普段利用しているツールではなく、業務の導線にないからだったと思っています。 （ただし、Google グループは、 GitHub アカウントを持っていない社員からの質問も受け付けられる点でメリットがあると思います。発足当初は職種からエンジニアへの質問も想定していて、現在はそこのコミットメントは諦めた形になります） また今から考えると、アサインや通知の自動化がやりづらく、この状態でスケールさせることも難しかったと思います。 次に「普段利用しているサービス上なら質問・回答がやりやすい」という仮説のもと、専用のチャットルームを用意して、有志でそこで質問・回答するようにしました。これはコンスタントに質問が行われるようにはなったものの、「あれ？どれが回答済みなんだっけ？」というやや混乱した状態にもなっていました。またせっかく回答しても、その場限りでナレッジにならないという歯がゆさもありました。 Discussions を利用するメリット それらと比較して、Discussions を利用することについて、以下のメリットを感じています。 業務で普段利用しているサービスであること Q&A が直接ナレッジとして蓄積できること GitHub Actions で自動化ができ、Pull Request で変更を受け入れられること 内容がオープンであること 1, 2 は、ほかのツールとの比較で自然にわかると思います。3 について補足すると、たとえば「GitHub Actions によって各チームに通知を飛ばす」機能は、Discussions 起票時に以下のようなシェルスクリプトを起動することで実現しています。 if [[ "$CATEGORY" = "Q&A" ]]; then ( regexp="([kK]eel|KEEL|[dD]ocker|[kK]ubernetes|ECS|EKS|[pP]rometheus|[gG]rafana|[vV]irtual[[:space:]]?[sS]ervice|[dD]ev[oO]ps|[vV]1[cC]luster[bB]ootstrap|[sS]pinnaker|[sS]elf([-]|[[:space:]])?[hH]osted([-]|[[:space:]])?[rR]unner|J-?SOX)" if [[ "$TITLE" =~ $regexp ]] || [[ "$BODY" =~ $regexp ]]; then addDiscussionComment "$ID" "KEEL: ${KEEL_TEAM}" fi ) ( regexp="([aA]rchitect|アーキ|設計相談|[bB]ff|BFF|[nN]c[aA]pp|[nN]ext[cC]ore|lhv5|[pP]roject[xX]|PJX|pjx|[fF]ront|ベストプラクティス)" if [[ "$TITLE" =~ $regexp ]] || [[ "$BODY" =~ $regexp ]]; then addDiscussionComment "$ID" "Architect: ${ARCHITECT_TEAM}" fi ) # 以下略 この通知スクリプトに各チームが通知内容を設定するようにしています。チーム側からこれらの修正を Pull Request として送ってもらうことで、運営チームはあまり負荷を感じることなくメンテナンスできます。 また、一度の投稿で、複数のチームに相談できるというメリットもあります。たとえば「何かのプログラムの問題について QA とアーキテクトに相談したい」というとき、以前はそれぞれの jira で起票する必要があったのですが、今では統一されたフォーラム上で一度に相談できます。 今後の展望とまとめ このように、GitHub Discussions を利用することで、あまり負担なく便利な社内フォーラムが用意できます。 当初は何人かで集まって「誰に質問すればよいか分からんから俺らで作ろうぜ」と勝手にやっていただけなのですが、投稿されたほとんどの質問は何らかの形で解決でき、上記のような便利な状態を実現できました。これは、運営メンバー外で質問をチェックや運営へのフィードバックをしてくれている社員も多くいてくれたおかげだと思っています。 また、従来はチーム内で閉じていた技術的な議論がチーム外も巻き込んだ形で行われているなど、想定していた以外のところでもうれしい事例も生まれています。引き続きよりよい開発文化のために貢献できればうれしいです。 最後に、LIFULL では一緒に働くエンジニアの募集をしています。この記事だけでは普段の開発の様子は分からないと思いますが、ぜひほかの記事も読んで興味を持っていただけたらうれしいです。カジュアル面談もあります。 hrmos.co hrmos.co

プロダクトエンジニアリング3Uの二宮です。 LIFULLにはチームビルディングの制度があり、半年〜1年に一度、同じチームのメンバーで半日〜1日単位で交流の機会を設けています。内容も各部署内で決めることができ、多種多様な企画が行われています。クリエイターズブログでも、過去に「 エンジニアのためのチームビルディング！コードで語れ 頭を使って 謎を解け 」や「 独自企画「浅草BINGO鬼ごっこ」でチームビルディングしてみた！ 」などが紹介されています。 LIFULLでは新型コロナウイルスの流行をきっかけにリモートワーク主体の働き方になっており、チームビルディングもリモートで行うようになり、自分たちのチームでもいろいろ苦慮しながら実施しました。おそらく他の会社の方もそうなのではないでしょうか？ そこで、この記事では私たちのチームではどう企画して、どう実施・今後に活かしていこうと考えたかをまとめました。ぜひ一つの知見として役立てて頂けると嬉しいです🙌 チームの現状と目的 我々のユニットでは、その中にあるグループ（下位チーム）が別々のプロダクトを担当していて、普段の業務での関わりは多くありません。ただ、現在は極端にチーム外とのコミュニケーションが薄くなり、サポートも得られづらい状態なのでなんとかしたいと考えていました。特徴的なエピソードとして、ある新卒に「直属の上司とは実際に会ったことがあるが、2つ上の上司とはネット越しでしか会話したことがない」とか「社内でもグループ外の知り合いがほとんどいない」と言われ、コミュニケーションのやり方や密度が以前と大きく違うことにショックを受けたことがあります。 9月にもチームビルディングを実施したのですが、その時は都合によって限られた時間で自己紹介と簡単なゲームをすることしかできませんでした。また、それからメンバーの入れ替わりもあって、はじめましての人も何人かいました。 ユニット全体では11人在籍していて、各グループは次のようなプロダクトを見ています。 同一プロダクトを見ているチームほど密に連携する必要はないが、各々小さなプロダクトを見ているので悩み事の相談などはできるはずだと考え、以下のゴールと方向性に決めました。 ゴール: 普段からグループ間で相談（実装面、スキル面など）ができるような信頼関係が作られている 方向性: 相談や意見を交わしながら「一緒に共通のゴールを目指す」ようなアクティビティを実施する 実施準備 結果として、1日を使って、次のようなアクティビティを実施することになりました。 アイスブレイク: 共通点探しゲーム メインコンテンツ: オンラインリアル脱出ゲーム×サマーウォーズ「AIによる世界支配からの脱出」 オンライン懇親会 まずアイスブレイクとして自己紹介を兼ねたゲームを行い、次にいくつかのチームに分かれて、「一緒に共通のゴールを目指す」ことのできるオンラインリアル脱出ゲームを実施しました。 「AIによる世界支配からの脱出」 を選んだのは、他のチームから「以前やってみてプログラマー向けな内容で面白かった」という評判を聞いたことが一番の要因です。また、運営チームで他のゲームやコンテンツもできるだけ探して検討したのですが、オンラインで11人が一緒にできるものが見つからなったという理由もあります。 また、懇親会ではフードデリバリーサービスの nonpi を利用しました。今までは、各々が別々に用意するやり方だったのですが、「オフラインの懇親会と同じく同じメニューのものを食べればチームの一体感にもつながるんじゃないか」と「食事の準備をなくして気楽に楽しめるようにしよう」ということを期待して試してみました。 当日の様子 ①アイスブレイク アイスブレイクで行った「共通点探しゲーム」は次のようなものです。『 リモートワークでの相互理解を深める（共通点探しゲーム） 』という記事から引用させていただきます。 「共通点探しゲーム」とは、その名の通り、制限時間内に対話を通してグループの仲間と共通点を見つけるゲームです。またコミュニケーション能力で重要な共通点を探す力を養うことができるグループワークでもあります。ゲームの目的は共通点を知ることではなく、内容を伝え合うことで、一体感を感じて相手の特徴をより知ることを目的としています。結果としてチームの協力（コラボレーション）を生まれやすくし、相互に助け合える環境を築くことを目標とした、チームビルディングのための一つの手段でもあります。 今回は「脱出ゲームを行うチームに分かれ、20分で『意外な共通点』を見つけよう」という形式で実施しました。 とあるチームは、途中で読書が共通してそうだと気づき、そこから本の共通点を探したところ全員がミステリ小説が好きということがわかり、チーム内でミステリ小説の話をしていたそうです。 運営側は「せっかく自己紹介をするなら、ゲームにしたほうが楽しくない？」という軽い理由だったのですが、後述するように、後日実施したアンケートでは予想以上に評判がよく驚きました。 ②メインコンテンツ: オンラインリアル脱出ゲーム メインコンテンツのオンラインリアル脱出ゲームは、うまく裏をついて問題を解いていくような内容で、前評判の通りたしかにエンジニア向けだったように思います。 ただ、どこまで解答をメンバー間で共有していいか分からなくて困惑したチームがあったり、完答するまでの時間がチームごとにバラツキが大きかったりして、運営側としてはもう少しうまくファシリテーションできたんじゃないかと反省点はありました。 ③オンライン懇親会 オンライン懇親会では、nonpiのフードとお酒を楽しみながら、 ボードゲームアリーナ で遊びました。自分たちは他のオンライン懇親会でもボードゲームアリーナを利用していて、特に「 イラストリー 」が恒例になりつつあります。これはイラストにこじつけて言葉を考える"しりとり"で、「よくこれ思いついたね」とか「いやこれは無理やりでしょ」とか会話も盛り上がるゲームです。 結果・振り返り 最後に、次回の実施内容やチームのあり方に活かせることが無いか、後日アンケートを取って振り返りを行いました。 メインコンテンツでは、楽しかったという意見は多かったものの、次のような課題も挙げられ「一緒に共通のゴールを目指す」というところから外れてしまっていた部分もあったようです。 解くことに集中して無言になってしまった どこまで解答をやり取りしていいか分からなかった 一部メンバーが解きまくって後からついていくことが多かった この辺りは運営に課題があったように思います。次回は次のように対処しようと考えています。 「積極的に話し合ってほしい」みたいに期待することを明確に案内する 他の脱出ゲームの中には人の案内役がいるものや、「AさんとBさんが別々の問題を解かなければ脱出できない」というコンテンツもある。それらを検討してもいいかも また、運営側の予想からは外れ、「共通点探しゲーム」の評判が良かったことです。「コミュニケーションが取れて良かった」という意見が多くありました。 おそらくリモート以前の時代より、我々が思っていた以上に「普段の雑談」とか「同じ開発チーム外の会話の機会」が減っていて、特に新規メンバーは他の人の人となりを知る機会が減っているからなんじゃないかと推測しています。こういうような「ゲームをしながら楽しくお互いを知る」のは他のチームでも需要が大きいのかもしれません。 フードデリバリーはやはり準備の手間が省ける点や、「どのメニュー選んだ？」というような話題で話が生まれる点が喜ばれていました。実は運営メンバーが共通している全社のイベントでもフードデリバリーを利用されるようです。ただ、飲み会向けのメニューが多いので、事情があって飲めない人はメニュー選びに困っていたようでした。 また懇親会では「同時に1人しかしゃべれないので会話に困る」という回答が複数あり、もっと積極的にブレイクアウトセッションを利用し、話題のためにコンテンツを用意して…というように、オフラインより事前の準備が必要な印象があります。また、他の社内イベントで使われていた oVice や Gather などのツールも検討してもいいのかもしれません。 このチームの個別の話でいうと、総じて「共通のゴールを目指そう」というよりは、まずは相互理解を目指すような内容がよかったんじゃないかと思います。例えば、他のチームで行われていた中では「 カラーバリューカード 」や「 アンガーマネジメントゲーム 」などがそういった選択肢になりそうだと思っています。 まとめ 他のチームでも共通するような知見をまとめると、次のようなものがあるかなと思います。 「共通点探しゲーム」のように、楽しく自己開示するゲームは、リモート時代のコミュニケーション不足の補完にいいのかもしれない コミュニケーションがスムーズに行われるように準備が大事だ。特にファシリテーション方法や部屋分けはもっと工夫の余地がありそうだ フードデリバリーは各々の準備の手間が省けるのが嬉しい また、今の所はユニット内でチャットでの会話が多少は生まれてきて、チームビルディングがそのきっかけにはなっていると思うものの、「普段からグループ間で相談（実装面、スキル面など）ができるような信頼関係が作られている」というゴールを見返すとまだまだな点も多いと感じています。チームビルディング以外でも、普段からどうコミュニケーションを取ればいいのか試行錯誤が必要そうです。 そして、企画時からオンラインでの交流の難しさは感じていたのですが、企画メンバー以外からも「やっぱりオフラインのほうが仲良くなれそう。今はムリだが、コロナが収束したら、せめてチームビルディングのときは集まりたい」という意見も出ました。 オンライン主体のチームのあり方は難しいですが、試行錯誤しながらがんばっていきましょう🙌 最後になりますが、LIFULLでは一緒に働く仲間を募集しております。もし興味を持っていただけたら、募集求人やカジュアル面談のページもご覧ください。 hrmos.co hrmos.co

エンジニアの島です。AI戦略室でバックエンドシステムの開発をしています。 本記事ではPrometheusを利用して、独自のメトリクスを計測することで監視を効率よく行えることを紹介します。 背景 チームで作っているもの 社内共通基盤の活用 効果的な監視で得られるもの 問題の予兆に気付けるようになる 問題の原因特定につながる 時系列での傾向を把握できる Prometheusとは 思想 メトリクスの公開 custom metricsを追加しよう Prometheusで監視しよう custom metricsで計測すると嬉しいもの 外部IOに関して 内部状態に関して 外部起因ではないアプリケーションのエラーの数 有効データのうち、モデルが値を返せている割合 機械学習モデルのスコア(histogramを利用) そのほか 終わりに 最後に宣伝 背景 チームで作っているもの LIFULLのAIチームでは、いくつかの機械学習プロダクトを本番運用しています。 2022年2月にAIホームズくんᴮᴱᵀᴬをリリースしました！(SPサイトのみです) https://www.homes.co.jp/ai-homeskun/ また、3D間取りも2021年にリリースしています。 https://www.homes.co.jp/3dmadori/ その他には、LIFULL HOME'Sのレコメンド機能でも機械学習を活用しています。 https://www.homes.co.jp/chintai/tokyo/list/ それ以外の開発プロジェクトもいくつか進行中です！ 社内共通基盤の活用 これらのプロダクトは社内共通基盤チームが開発したKEELという、 In-house PaaSとして各種機能を提供するKubernetesベースのアプリケーション実行基盤で動いています。 www.lifull.blog KEELチームが開発しているコードジェネレータ（keelctl）によって、Production Readyなアラートが自動的に設定されます。 例えば下記が監視され、しきい値を検知すると通知されます。 サクセスレート低下 レスポンスタイム CPU・メモリ使用量 www.lifull.blog success rateやresponse timeなどの基本的な指標は、ダッシュボードで閲覧できます。また、それらの通知も生成されるため、基本的な指標の悪化に気付けます。 そしてKEELチームが運用するPrometheus,AlertManager,Grafanaといったソフトウェアからアラートの受け取り、収集したメトリクスを確認できます。 www.lifull.blog アプリケーション開発者はこの仕組みを活用しながら、 DevOpsの考え方に従い、自分たちでアプリケーション固有のエラー対応や監視を行うことが出来ます。 開発したプロダクトが増えていくにつれ、運用コストも増えていくため、自動化できるところは自動化したいモチベーションがあります。 効果的な監視で得られるもの 問題の予兆に気付けるようになる 監視の恩恵としてここが一番大きいです。 本番サーバが突然落ちて、それにより割り込み対応や残業を余儀なくされるというのは、開発者体験として最悪ですよね。 バグの早期発見により対応コストが劇的に下がるのと同様、障害対応も早期解決・顕在化前の解決が最も効率的です。 適切に監視をすることで、サービス利用者への価値提供を継続できるだけでなく、あなたや同僚の時間を守る事にもつながります。 問題の原因特定につながる custom metricsを作成することの恩恵はこちらになります。 問題が発生したときに、手がかりがないと調査から始めないといけません。 custom metricsが手がかりとなれば、問題を迅速に切り分けることができます。 仮に問題がなかったとしても、「問題はそこではない」という貴重な情報が得られます。 結果的に初動が早くなり、問題を迅速に解決できるでしょう。 時系列での傾向を把握できる こちらはメトリクス値を蓄積することの恩恵になります。 通知を設定しなかったとしても、蓄積したデータを調べることで、システムの長期的な傾向を知ることができます。 リリースしてから、サーバのメモリは増加していないか 依存サービスのタイムアウトは一時的なのか周期的なのか catchして握りつぶしている例外の数は規定内に収まっているか 機械学習スコアの傾向に変わりはないか さまざまな情報を知ることで、サービス開発・運用に役立てることができます。 Prometheusとは 一言でいうとシステム状態の収集・可視化と監視ができるOSSです。 prometheus.io 元はCNCF(Cloud Native Computing Foundation)プロジェクトとして始まりました。 今ではAWSマネージドサービスも出ており、監視標準と言って良いでしょう。 aws.amazon.com 思想 Zen of Prometheus が分かりやすいので紹介します。(非公式サイトですが) https://the-zen-of-prometheus.netlify.app/ ３行でまとめると、 メトリクス取得は安価に行えるので、どんどん取得しよう。 ログを取ったり、可視化をしたりするのであれば、そのメトリクスを計測してアラートさせるように作っておこう。 やっかいな問題へと深刻化する前に、すぐ気付いて早期対処しよう。 といったところでしょうか メトリクスの公開 Prometheus公式にて、いくつかのプログラミング言語用のライブラリがサポートされています。 こちらを利用するだけで、簡単に実装できます。 github.com PythonのFastAPIフレームワークであれば、例えば以下のように記載するだけでデフォルトのメトリクスを公開できます。 import prometheus_client ... @app.get('/my_prometheus_metrics') def prometheus_metrics(): return fastapi.responses.PlainTextResponse( prometheus_client.generate_latest() ) その上で設定したパス /my_prometheus_metrics にアクセスすると、計測しているメトリクスを次のようなプレーンテキストで取得できます。 # HELP process_start_time_seconds Start time of the process since unix epoch in seconds. # TYPE process_start_time_seconds gauge process_start_time_seconds 1.64446715949e+09 # HELP process_cpu_seconds_total Total user and system CPU time spent in seconds. # TYPE process_cpu_seconds_total counter process_cpu_seconds_total 260.51 custom metricsをプログラム側で追加すると、このプレーンテキストに行が追加されていくことになります。 Prometheusが設定したエンドポイントをポーリングし、メトリクスを読み込みます。したがって追加されたcustom metricsも連携することができます。 custom metricsを追加しよう 利用方法もPrometheusのライブラリ側に書いてあるので、非常に親切です。 たとえば下記のように記載するとタイムアウトがどれくらい起きているかのメトリクスを追加できます。 ※異なるアプリケーション間でのメトリクス名を明確に区別するために、プレフィックスを付けています。 PREFIX = 'your_awesome_app' TIMEOUT_REDIS_COUNTER = prometheus_client.Counter(f'{PREFIX}_timeout_redis_counter', 'redis timeout counts') try: # some redis execution ... except redis.exceptions.TimeoutError: my_prometheus.TIMEOUT_REDIS_COUNTER.inc() Prometheusで監視しよう PrometheusではPromQLという記法で条件式を表現できます。 例えば下記のように割合を表現できます。入力から機械学習モデルのイレギュラー値の割合を、モデルに渡さない除外データの数を除外して計算しています。 これにより「有効データのうち、モデルが値を返せている割合」を監視できます。 (sum(increase(your_awesome_app_zero_score{app="your-awesome-app"}[10m])) - sum(increase(your_awesome_app_exclude{app="your-awesome-app"}[10m]))) / (sum(increase(your_awesome_app_input_records{app="your-awesome-app"}[10m])) - sum(increase(your_awesome_app_exclude{app="your-awesome-app"}[10m]))) < 0.0025 このPromQLによる検知がPrometheusのAlertmanagerに渡され、事前に設定した通知設定でSlackに通知されます。 custom metricsで計測すると嬉しいもの 以下のように外部IOや、アプリケーションの内部状態を計測しています。 外部IOに関して 複数の外部IOに接続して、レスポンス低下が起こっている場合に、どこで問題が起きているかが特定できて便利です。 response time(histogramを利用)やnetwork timeout数を計測しています。 分散トレーシングに関してはJaegerが得意なので、そちらで可視化しても良いです。 Prometheusで取得することで、PromQLで他メトリクスと同じように扱えたり、アラート通知が行えたりとメリットがあるのでこちらで計測しています。 内部状態に関して 注視しておきたい値を計測しておくと、時系列で追えるので便利です。 外部起因ではないアプリケーションのエラーの数 単純なsuccess rateだと外部起因エラーと内部起因エラーが交じるため、分離して監視しています。 今の所、安定して値を返せています。このような安定した数値は手動確認だと見なくなる傾向があるため、自動監視の恩恵が大きいです。 有効データのうち、モデルが値を返せている割合 単純なsuccess rateだと異常値は0点スコアとして200 OKで返すため、このメトリクスを監視しています。 監視することでモデルや入力データの異常に気付くことができます。 こちらも同様に普段発生しないため、自動監視に任せています。 機械学習モデルのスコア(histogramを利用) GrafanaでPromQLを記述し、Prometheusのメトリクスを可視化できます。 機械学習スコアの推移 こちらは問題が発生した場合の調査用に計測しています。 ※スコア自体は、相対的な順序が正しければそれでよく、絶対的な数値で正常・異常を測ることができないと判断しています。 機械学習スコアの比率は、細かなブレはありますが長期で見て変動ないことを確認できます。 ※年末年始に不動産会社がお休みのタイミングのみ微減しており、これは新鮮な物件広告の供給が途絶えていたためと考えられます。 モデルの継続的な品質担保は別の方法で行う必要があり、ABテストによるサイトのCTRやCVRを目視しています。 ※これはPrometheusで監視していませんが、サイトパフォーマンスのデータは別系統で集計されているためです。 Google Analyticsで計測されたものを、Data Studioのダッシュボードに表示しています。 そのほか こういうメトリクスを計測すると良いというものがあれば、ぜひブコメなどで教えてください！ 終わりに Prometheusのcustom metricsを計測して通知すると、監視を効率よく行えることを紹介しました。 問題がやっかいなものになる前に、早めの対処で良いサービスを提供していきましょう！ 最後に宣伝 このようにバックエンドサービスの開発から共通基盤開発まで、さまざまな職種を募集しています！よろしければぜひこちらのページもご覧ください！ hrmos.co カジュアル面談もお待ちしております！ぜひぜひどうぞ！ hrmos.co

プロダクトエンジニアリング部の海老澤です。 LIFULLでは2020年3月頃から自宅からのリモートワークが主体の働き方となっていますが、弊社が運営しているコミュニティ 「LivingAnywhere Commons」 の全国の拠点での就業も可能です。 これは従業員自らが働き方や働く場所を選択でき自分らしい働き方を実現することが、一人ひとりのWell-Beingやパフォーマンスの向上・イノベーションの種の発見に繋がると考えられているためです。 自宅だけでなく旅先の遊休施設で仕事をする、いわゆるワーケーションも行えます。 lifull.com 今回は 「LivingAnywhere Commons」 で二泊三日のワーケーションをしてきました。 控えめに言って最高だったので紹介させてください。 「LivingAnywhere Commons」 とは LIFULLは「あらゆるLIFEを、FULLに。」をコーポレートメッセージとして掲げ、さまざまな社会課題に取り組んでいます。 その中でも「自分らしくを、もっと自由に」をテーマに、ライフラインの限界から解放された本当の意味での自由な生き方を目指す取り組みが「LivingAnywhere」です。 そういった生き方を実践するコミュニティとして2019年に 「LivingAnywhere Commons」 の運営が開始されました。 コミュニティにはコワーキングスペース・レジデンススペースが完備されており、全国に拠点があるため自分の好きな場所で仕事・したい暮らしができます。（2022年1月現在29拠点・続々増えてます！） LIFULLの社員はこれらの拠点を格安・あるいは無料で利用でき、中には毎月利用されている方もいます。 ワーケーションレポート 今回は山梨県にある 「八ヶ岳北杜」 拠点を利用しました。 最寄は小淵沢駅、JR新宿駅から特急で2時間です。 ホームズくんも一緒にワーケーションしてきました 周辺のようす 駅から車で20分ほどの場所に拠点があります。 八ヶ岳北杜拠点 周辺 八ヶ岳北杜拠点 エントランス もともとは民間企業の研修施設だったようで、会議室や大浴場など設備はとても充実していました。 山の上（標高1000m）にあるため開放感がすごいです。富士山もバッチリ見られます🗻 個人的に夕暮れのオレンジと山々の青のコントラストが最高でした。 夕方の富士山 放し飼いにされているヤギもいます。 ヤギのニーナちゃん ワーキング 拠点はWi-Fiがしっかり飛んでいるのでどこでも自由にお仕事ができます。 コワーキングスペースも充実しており、各々作業環境を整えておりました。 二面ディスプレイの作業環境 分割キーボード勢の作業環境 ホームズくんの作業環境 バケーション 業務後はバケーションも楽しめます。 弊社はフレックスタイムを導入しているため、早めに退勤してお買い物にいったりサウナを楽しむメンバーもいました。 サウナーホームズくん 拠点にはサウナカーがあり、セルフロウリュも可能です。 ととのい環境も完璧で、水風呂はなんと 近くの川に飛び込むスタイル です。ワイルド〜！ 晴れている日は満天の星空を眺めながら完全優勝しましょう。 圧倒的星空 サウナ後にバーベキューもできます。天才！ 11月下旬の山でバーベキューは寒かった 感想 わくわくしながら働ける 普段と違う環境にそわそわすると思いきや、意外と集中して業務に取り組めました。 いつものリモートワークだと1日外に出ないこともよくあるのですが、 業務前の早朝にお散歩したり、地元のお店のおいしいケーキを食べたりQOLが爆上がりしました💣。 最高の朝 合宿で利用したい 今回は「Living Anywhere Commons 行ってみたい！」という好奇心からさまざまな部署の有志が集まって利用したのですが、チームビルディングや開発合宿にも最適な環境だと感じました。 働くのにはまったく不自由しない環境ですし、普段とは違うアクティビティも楽しめるので次回は部署単位で利用してみたいです。 自分らしくを、もっと自由に LIFULLではともに働く仲間を募集しています。 「自分らしくを、もっと自由に」を実現したい方、カジュアル面談という形で気軽にお話をさせていただくということも可能ですので、ご興味がある方は以下のページをご覧ください。 hrmos.co hrmos.co

エンジニアの松尾です。LIFULL HOME'Sの売買領域を支えるエンジニアチームのマネジメントを担当しています。 私の部署を始め、LIFULLでは複数の部門でエンジニア採用を行っています。人事部門の採用担当と現場で連携し、書類審査と複数回の面接により選考を行います。 今回はエンジニア採用を進める上で感じた課題とその解決への取り組みについて紹介したいと思います。 採用において抱えていたモヤモヤ いくつかの書類審査と面接を終えて、日々似たような作業を繰り返しながらいくつかのモヤモヤを抱えていました。 モヤ1: 書類審査に時間がかかる 打率よりもまずは打数。より良い候補者様を見つけ出すために、できるだけ多くの書類に目を通すようにしています。ただしどの方も真剣に経歴を書いてくださっており、すべてに目を通すにはなかなか時間がかかります。 採用以外にもやるべき仕事は多くあります。書類審査に時間をかけすぎることで、ほかの業務の質を下げてしまうリスクもあります。 モヤ2: 面接の時間を有効に使えない 実際に候補者様と対面する面接は、時間を無駄にしないよう慎重に行います。しかし結果を出すためには聞き出したい情報が多くあり、すべてを質問しているとすぐに終了時刻になります。 事前に職務経歴書内の掘り下げたい箇所については確認しつつも、自分の中で要点が定まっていない状態でした。 モヤ3: 自分で評価した結果が腹に落ちない 全力で書類チェックと面接をした結果として、手元には多くの判断材料があります。ですが「この点は物足りないけど、この部分がすごく良いからOKにしようかなあ…」と評価ポイントや基準が定まっておらず、結論を出すのに時間がかかります。そしてほかの評価者とすり合わせると意見が割れ、合議での結果出しにまた時間を要します。 最終的には合議で正しい結論を出せていると思っていますが、個人での評価には不備があり、納得に至るまでのプロセスに時間がかかりすぎている状況でした。 取り組んだこと 何かもう少しうまくやれる方法を模索できないか…と人事や上司に相談しようかと考えていたときに、 下記リンクの記事を発見しました。 現場メンバーの知識を人材要件定義に活かす手法「Job Analysis」の紹介 参考文献をもとに選考プロセスの設計について記載されていますが、私の部署の採用では以下の2点がまだ不十分である印象を持ちました。 採用したい人の人材要件を定義する 人材要件のうち、見極めたい能力を特定する そこで、ブログの内容を参考に求める人材の像を明らかにし、求人ページの応募資格を再設定するための取り組みを進めました。 業務上発生するタスクの洗い出し 採用したい人材とポジションが似たメンバーに協力してもらい、業務内でどのようなタスクを行っているかを洗い出しました。エンジニアにとっては設計、プログラミング、テストなどが主たる業務ですが、ほかの職種とのやりとりやメンバー育成など、タスクは多岐に渡ります。 私は比較的現場に近いポジションなのである程度は把握していましたが、あらためて眺めてみると気付きがあります。 実装よりもレビューの比重が大きそう 他のメンバーに何かを教えたり協力したりするタスクが多い ネットワークやDBの設定をスクラッチで行う機会は少ない 求められている能力（コンピテンシー）の洗い出し タスクとは別に、どのようなスキル/経験を求めているかを洗い出します。 言語、OSS、専門分野などのリファレンスとして、 Qiita の人気のタグを抽出して使用しました。これらからノイズを除去し、残った項目から現場で必要になり得る項目をまとめていきました。 弊社には新旧含めて多くのシステムが存在するため関わる技術は多く、項目全体で見るとなかなかの数になります。重要度の低いものはこのあとの工程で削ぎ落とされるため、現段階ではすべて含めておきます。 スコアリングと文章化 ブログの内容を参考に、タスクとコンピテンシーのそれぞれにスコアをつけていきます。頻度や重要度などの観点で点数を付け、それぞれに序列ができます。スコアリングはほかのマネージャーと相談しながらプランニングポーカーのような要領で進めました。 タスクとコンピテンシーの上位項目を突き合わせて、結果をもとに徹底的に議論します。 「今いるメンバーの立ち回りを考慮すると、PJ管理経験は必須だね」 「言語の具体的な知識より、設計力を優先したいですね」 「〇〇は面接で質問してたけど、入社してから覚えるでも問題ないね」 というようなやりとりを経て、人材要件が新しく定義されました。結果として、応募資格に記載していたスキルを下記のように変更しています。 応募資格の変更 人材要件を見直して改善したこと 実際に現場で必要としているタスクや求めている能力を見つめ直すことで、以前とは違った人材要件ができました。洗い出しただけではなくそれぞれの優先度も確認したため、採用活動の中で候補者様を評価する順序や観点も違ってきます。 見直し前のモヤモヤと比較して、改善した点についてまとめます。 書類選考でチェックできる人数が増える 要件ごとの優先度が決まったことで、書類の中で確認する箇所が明確になり、チェックの所要時間が削減できました。優先度の高い要件を満たしていない場合は早めに候補から外したり、なんとなく魅力的に見えてしまうスキルに目移りしなくなったことで、書類選考の量と質の両方が改善したと感じています。 面接が時間内に完了しやすくなる 優先度の高い要件から早めに質問していくことで、面接内で過不足なくヒアリングを終えられることが多くなりました。要件ごとの重要度が頭に入っているおかげで、質問ごとにかける時間の判断がしやすくなります。また我々からの質問が手短に終えられることで、候補者様からの質問も多く受け付けられます。 評価時のすり合わせがスムーズになる ターゲットとなる人材の像を文書化して認識を合わせたため、複数の評価者で議論して結論を出す場合にも意見が割れづらくなりました。「評価項目Aは文句なしですが、Bは満たしていないですよね」という項目ごとの評価に関する会話もしやすくなり、合否の理由付けも以前より明確になっています。 まとめ 採用活動は非常に重要な仕事ですが、本業務であるエンジニアリングと同時に進めるためには効率化が必須であると感じています。今回はスタート地点にあたる人材要件の作成に手間をかけることで、数ある書類選考や面接をスムーズに迷いなく進められるようになりました。 結果をすばやく正確に出せることは、採用をする我々だけではなく候補者様の転職活動のためにも有意義です。今後もより多くの方とお話をし、ともに働く仲間をみつけるために、妥協のない採用を続けていきたいと思います。 このように選考内容の改善も考えながら、一緒に働く仲間を募集してます。よろしければぜひこちらのページもご覧ください。 hrmos.co hrmos.co